A felhő technológia alapjai és jelentősége
Határidők / Események
Fontos biztonsági határidő közeledik az AVD környezetek üzemeltetői számára. A Secure Boot 2011-es tanúsítványai hamarosan lejárnak, ami közvetlenül érinti a Trusted Launch funkcióval rendelkező virtuális gépeket.
🗓️ Határidő
-
2026. június: Eddig kell elvégezni a frissítést a Secure Boot 2023-as tanúsítványokra.
🛠️ Kit érint ez a változás?
-
Azokat az Azure Virtual Desktop session hostokat, amelyeknél engedélyezve van a Trusted Launch és a Secure Boot.
-
Azokat a szervezeteket, amelyek egyedi "golden image"-ekből építkeznek.
Kit NEM érint?
-
Akik nem használnak Secure Boot-ot, vagy kikapcsolták a Trusted Launch funkciót (bár biztonsági szempontból ez nem javasolt).
✅ Tennivalók
-
Audit: Mérd fel, hány session host fut az érintett 2011-es tanúsítvánnyal.
-
Frissítés: Telepítsd a Secure Boot 2023-as tanúsítványokat a Microsoft útmutatása alapján.
-
Image management: Ha saját image-eket használsz, frissítsd az alap sablonokat, hogy az új telepítések már a 2023-as tanúsítvánnyal induljanak el.
A frissítés elmaradása esetén a rendszerek védtelenek maradhatnak a boot-szintű fenyegetésekkel szemben, vagy kompatibilitási hibák léphetnek fel az indításkor.
Az alábbi modellek elérése korlátozódik az új vagy inaktív projektek számára: gemini-2.5-flash, gemini-2.5-flash-lite, gemini-3-flash-preview
A legfontosabb szabályok:
-
Aktivitás alapú megtartás: Csak azok a projektek tarthatják meg a hozzáférést, amelyek az adott modellre legalább 1 API hívást indítottak az elmúlt 90 napban. A vizsgálat modellenként külön-külön történik!
-
Új projektek tiltása: Június 15. után teljesen új projektből már nem lehet majd meghívni ezeket a verziókat.
-
Tuning leállítása: A felsorolt modellek finomhangolási (model tuning) lehetősége minden projektben véglegesen leáll, függetlenül attól, hogy aktív-e a projekt vagy sem.
Megjegyzés: A változás nem érinti a Google AI Studio-t, kizárólag az Enterprise Agent Platformra vonatkozik.
Tennivalók-
Meglévő rendszereknél: Ha meg akarod tartani az elérést egy meglévő projektben, indíts legalább egy teszt API hívást a kiszemelt modellre június 15-ig.
-
Új fejlesztéseknél: Az új projekteket már érdemes a legfrissebb, stabil Gemini modellekre tervezni a preview és korábbi verziók helyett.
-
Finomhangolás: Ha tuningoltál valamilyen egyedi feladatra a fenti modellekkel, mentsd le az eredményeket, mert a funkció megszűnik.
A Google 2026 második negyedévében frissíti a végpontjait (köztük a googleapis.com-ot is). A korábbi RSA tanúsítványláncot modern, ECDSA alapú TLS tanúsítványok váltják fel (Google Trust Services WE1).
Az átállás fokozatosan történik a negyedév során.
🛠️ Kit érint ez a változás?
A legtöbb felhasználónál nincs teendő, mert a szabványos operációs rendszerek és böngészők alapból bíznak a szükséges Root CA-kban.
Azonnali ellenőrzés szükséges, ha:
-
"Certificate Pinning"-et alkalmazol a kliensoldali alkalmazásokban az intermediate vagy leaf tanúsítványokra. (Ez a gyakorlat mostantól garantáltan megszakítja a kapcsolatot).
-
"Custom Trust Store"-t használsz a konténerekben, szervereken vagy beágyazott eszközökön, és korlátoztad az elfogadott gyökértanúsítványok listáját.
📋 Tennivalók
-
Trust Store felülvizsgálat: Győződj meg róla, hogy az egyedi környezeteid és klienseid megbíznak a Google Trust Services (GTS) Root CA összes gyökértanúsítványában.
-
Ha lehetséges, távolítsd el az intermediate/leaf szintű kitűzéseket a kódodból.
-
Ha a pinning üzleti követelmény, akkor a teljes GTS Root listát fel kell venned a megengedett elemek közé.
A frissítés elmaradása esetén a kliensalkalmazások nem fognak tudni kapcsolódni a Google szolgáltatásaihoz és API-jaihoz (SSL/TLS kézfogási hiba miatt).
A Google módosítja a kötelezettségvállalási kedvezmények (Commitment Use Discount - CUD) alapértelmezett beállításait. A cél a kihasználatlan kedvezmények minimalizálása és a megtakarítás maximalizálása.
🗓️ Dátum: 2026. június 16.
🛠️ Mi változik?
Eddig a projektalapú (resource-based) CUD-ok alapértelmezés szerint csak az adott projektben voltak felhasználhatók. Júniustól a megosztás (sharing) lesz az alapértelmezett beállítás:
-
Új fiókoknál: Automatikusan bekapcsolt megosztás.
-
Meglévő fiókoknál (aktív CUD nélkül): Szintén aktiválódik a megosztás.
-
Meglévő fiókoknál (aktív CUD-dal): A jelenlegi beállításaid nem változnak, marad minden a régiben.
💰 Mi az előnye?
A megosztással a kedvezmény nem "ragad be" egy projektbe. Ha az egyik projektben csökken az erőforrásigény, a kifizetett kedvezményt a számlázási fiókhoz tartozó bármely más projekt igénybe veheti.
✅ Teendők
-
Pénzügyi izoláció: Ha projektalapú elszámolást (chargeback) alkalmazol, és nem szeretnéd, hogy a kedvezmények "vándoroljanak" a projektek között, a Billing konzolon manuálisan ki kell kapcsolnod a megosztást (Self-serve toggle).
-
Kezelhetőség: Ha eddig manuálisan sakkoztál a kedvezményekkel, most érdemes felülvizsgálni, hogy az automatikus megosztás egyszerűsítené-e az életedet.
Alapvetően ez egy pozitív változás, de a komplexebb költséghely-kezelésnél érdemes körültekintően eljárni.
-
2026. február 16. – február 27.: A migrációs folyamat aktív szakasza.
-
2026. augusztus 31.: A régi metrikák végleges kivezetése. Eddig az időpontig kell frissíteni minden egyedi monitorozást!
-
Regionális kvótaérvényesítés: A forgalom mostantól ott számít bele a kvótába, ahol a feladat fut (még multi-region forgalom esetén is).
-
Új metrika elnevezések: Pontosabb kategóriák érkeznek a védelem típusa szerint (
software_usage,hsm_usage, etc.) és műveleti típusok alapján (read_usage,write_usage). -
"Soft Enforcement": Az új metrikák többségénél a kvóta túllépése esetén is kiszolgálja a rendszer a kéréseket, amennyiben van szabad kapacitás.
-
Monitorozás: Ha saját dashboardokat vagy riasztásokat használtok, augusztus 31-ig írjátok át őket az új metrikákra az adatok folytonossága érdekében.
-
Kvóta túllépések (Overrides): A meglévő override-okat a Google automatikusan migrálja, ezzel nincs teendőtök.
- Számlázás: A változás nem érinti a költségeket, a KMS számlázása továbbra is használat alapú marad.
