A felhő technológia alapjai és jelentősége
Határidők / Események
-
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.
A cél az egységesebb role-definíció és az új, valamint meglévő funkciók lefedése.
➡️ Role-definíciók egységesítése:
• {Service} Admin – teljes hozzáférés az adott szolgáltatás minden műveletéhez
• {Service} Editor – erőforrások létrehozása, módosítása, törlése és használata (security policy-k nélkül)
• {Service} Viewer – read-only hozzáférés az erőforrásokhoz és konfigurációjukhoz.
⚠️ Hatás a meglévő projektekre
• A változás nem érinti a jelenlegi működést
• Az érintett felhasználók és service account-ok 2026. szeptember 30-tól automatikusan megkapják az új jogosultságokat.
⚠️ Ajánlott ellenőrzési pont
• Érdemes átnézni, hogy az új permission-ök illeszkednek-e a jelenlegi IAM és security modellhez
• Ha szükséges, a hozzáférés finomítható custom IAM role-lal vagy IAM Deny policy-vel
Ez egy role-definíciókat érintő változás, amelyet mindenkinek érdemes tudnia.
A Microsoft bejelentette az Azure Key Vault API-k eddigi egyik legjelentősebb változását. Ha az infrastruktúrádat kódból építed (IaC), erre nagyon oda kell figyelned!
🗓️ Kulcsfontosságú dátumok-
2026. február: Megjelenik a
2026-02-01API verzió, ahol már az Azure RBAC lesz az alapértelmezett modell az új vault-oknál. -
2027. február 27.: Minden korábbi API verzió kivezetésre kerül (Retirement).
Eddig az új Key Vault-ok alapértelmezés szerint "Access Policy" (örökölt hozzáférési szabályok) módban jöttek létre. Az új API verzióval ez megfordul:
-
RBAC az új alapértelmezett: Minden újonnan létrehozott vault Azure RBAC-re lesz állítva, hacsak nem jelzed explicit módon az ellenkezőjét.
-
IaC hibaforrás: Ha a Terraform vagy Bicep scriptjeid nem tartalmazzák az explicit konfigurációt, az új vault-ok RBAC módban jönnek létre, a korábbi Access Policy-k pedig nem fognak működni.
Megerősítem a Microsoft javaslatát: Migrálj Azure RBAC-re! Ez sokkal granuláltabb, biztonságosabb és a modern Azure standard-oknak megfelelő megoldás.
Teendők:
-
Ellenőrizd a meglévő Key Vault-jaidat, és készíts tervet az RBAC-re való áttérésre.
-
Frissítsd a CLI, PowerShell, ARM, Bicep és Terraform sablonjaidat.
-
Ha ragaszkodsz a régi Access Policy modellhez, az új API verzióra való váltáskor explicit módon be kell állítanodezt a sablonjaidban, különben az automatizációid elhasalnak.
Ne várd meg 2027-et, az új API-val járó változások már jövő februártól élesednek az új erőforrásoknál!
🗓️ Határidő: 2027. április 30.
🛠️ Mi a teendő?
Kockázatok és biztonsági sebezhetőségek elkerülése érdekében frissítsd az Azure App Service-en futó Node.js alkalmazásaidat a Node 24 LTS verzióra a megadott határidő előtt.
Az Azure Portalon a Service Health / Health advisories menüpont alatt követheted az érintett erőforrásokat (Tracking ID: 9Z2G-WGG).
🗓️ Határidő
-
2027. szeptember 30. (Ezt követően a v1-es szabályok nem lesznek támogatottak.)
🛠️ Mi változik?
A v2-es szabályok váltják fel a régieket, amelyek rugalmasabb konfigurációt és jobb skálázhatóságot biztosítanak. A legfontosabb különbség, hogy a v2 már nem igényel NAT-poolokat a virtuális gépcsoportokhoz (VMSS), hanem közvetlen szabálytársítást tesz lehetővé.
✅ Tennivalók
-
Feltérképezés: Ellenőrizd a meglévő Load Balancereidet, hogy használnak-e örökölt (v1) NAT-szabályokat vagy NAT-poolokat.
-
Migráció: Frissíts a v2-es verzióra. A folyamat szerencsére automatizálható (például Azure CLI segítségével).
-
IaC frissítés: Ha Terraformot vagy Bicep-et használsz, módosítsd a sablonokat az új struktúrának megfelelően.
A váltás nem jár leállással, ha megfelelően hajtják végre, de a kivezetési dátum után a v1-es konfigurációk működése nem garantált.
