Aki régen dolgozik Azure-ban, mint én is, rendszeresen kap értesítő e-maileket, amelyekben biztonsági okokból kérik a felhasználót az infrastruktúra módosítására. Most is jött egy ilyen, október elején: a Microsoft arra figyelmeztet, hogy az Azure Tárfiókoknál 2026. február 3. után már csak a TLS 1.2 vagy újabb verzió lesz támogatott.
Ez az értesítés elsősorban azokat érinti, akiknek a Tárfiókjai még TLS 1.0 vagy 1.1 protokollt is elfogadnak. Ezek a régebbi titkosítási eljárások ma már elavultnak számítanak, és nem támogatják a modern kriptográfiai algoritmusokat, ezért a Microsoft fokozatosan megszünteti a használatukat.
Mi az a TLS és miért fontos?
A TLS (Transport Layer Security) egy biztonsági protokoll, amely az internetes adatátvitel védelmét szolgálja. A korábbi verziók (1.0 és 1.1) több mint 20 évesek, és ma már nem felelnek meg a biztonsági követelményeknek. A TLS 1.2 gyorsabb és biztonságosabb kommunikációt biztosít, amely jobban védi az adatokat a lehallgatás és a manipuláció ellen.
Mi a teendő?
Ha az Azure Tárfiókod TLS 1.0 vagy 1.1 protokollt is enged, akkor 2026. február 3-ig frissítened kell a beállításokat, különben az alkalmazásaid nem fognak tudni biztonságosan csatlakozni a szolgáltatáshoz.
A Microsoft ajánlása egyértelmű:
Állítsd be a Minimális TLS-verziót 1.2-re (vagy újabbra).
Ellenőrizd, hogy az alkalmazásaid és SDK-jaid is támogatják a TLS 1.2-t.
Hogyan lehet beállítani a TLS 1.2-t az Azure portálon?
A beállítás módosítása néhány kattintás az Azure portálon:
Lépj be az Azure Portalba.
Keresd meg a módosítani kívánt Tárfiókot.
A bal oldali menüben válaszd a Beállítások > Konfiguráció (Settings > Configuration) menüpontot.
A Minimális TLS-verzió (Minimum TLS version) beállításnál válaszd ki a TLS 1.2 opciót.
Mentsd el a módosítást (Mentés / Save).
Ha több Tárfiókod van, érdemes Azure Policy-t is használni, hogy központilag kikényszerítsd a TLS 1.2 beállítást minden fiókra.
Meddig van időm ezt elvégezni?
A határidő 2026. február 3., eddig kell minden Tárfiókon elvégezni a frissítést. Ezt követően a TLS 1.0 és 1.1 kapcsolatokat az Azure Tárfiók már nem fogadja el.
Aki addig nem módosítja a beállításokat, annak az alkalmazásai hibát fognak adni, amikor megpróbálnak kapcsolódni a Tárfiókhoz.
Összefoglalás
A változás célja, hogy az Azure-felhasználók biztonságosabb és korszerűbb titkosítási eljárásokat használjanak. A frissítés mindössze néhány percet vesz igénybe, de elengedhetetlen a jövőbeni hibamentes működéshez.
Amikor fejlesztőként program csomagokat publikálunk vagy automatizálunk, a biztonság mindig kulcskérdés. A szoftverellátási lánc támadásai egyre gyakoribbak, ezért a GitHub most javította a hitelesítést és a token-kezelést. Az egész folyamat középpontjában a Personal Access Token (PAT) áll — ez az a digitális kulcs, ami a fejlesztők mindennapjait biztonságosabbá és szabályozottabbá teszi.
Mi az a PAT, és miért fontos?
A Personal Access Token (PAT) egy digitális azonosító, amellyel hitelesítem magam a GitHub-on vagy az npm-en anélkül, hogy jelszót kellene megadnom. Olyan, mint egy személyre szabott kulcs, amivel belépek egy zárt rendszerbe – de csak azokhoz az ajtókhoz, amelyekhez ténylegesen van jogosultságom.
A PAT azért fontos, mert:
Biztonságosabb, mint a jelszó, nem kerül közvetlenül a kódba vagy pipeline-ba.
Automatizált folyamatokhoz (CI/CD, build, deploy) elengedhetetlen, mivel emberi beavatkozás nélkül hitelesít.
Korlátozható és forgatható, így ha kiszivárog, a kár minimalizálható.
Más szóval: minden, amit a fejlesztői rendszerekben „tokenk-ént” használunk — legyen az npm, GitHub vagy API — valójában egy Personal Access Token, csak más néven vagy kontextusban jelenik meg.
A token típusok közötti különbségek
A GitHub háromféle token-mechanizmust használ — ezek közül az első volt a klasszikus PAT, a második a továbbfejlesztett granularis verzió, a harmadik pedig már a PAT nélküli jövő.
1. Klasszikus PAT (Classic Token) – a régi hozzáférés
A klasszikus PAT hatókörös, tehát megadható, milyen tág jogosultságokkal rendelkezik (pl. repo). Ugyanakkor a hatóköre nem elég finom (jellemzően minden repo, amihez a felhasználónak hozzáférése van), és a lejárat nem volt kötelező – emiatt nagyobb a kockázat, ha kiszivárog.
2. Granularis PAT (Fine-grained Access Token) – a finomítás
A granularis PAT bevezetésével a GitHub sokkal precízebb jogosultságkezelést adott a kezünkbe. Beállíthatom, hogy:
pontosan mely repository-hoz fér hozzá,
milyen műveletekre jogosít (pl. olvasás, írás, admin),
és meddig érvényes legyen (alapértelmezés szerint 7 nap, maximum 90).
Ez csökkenti a támadási felületet, és jobban illeszkedik a vállalati biztonsági irányelvekhez is.
A Trusted Publishing nem azt jelenti, hogy megszűnnek a Personal Access Token-ek (PAT) – sok esetben továbbra is szükség van rájuk – hanem azt, hogy egy biztonságosabb alternatívát kínál az automatizált csomag-kezeléshez. Ebben a megközelítésben a CI/CD rendszer (például GitHub Actions vagy GitLab CI/CD) az OpenID Connect (OIDC) protokollt használja, és rövid életű hitelesítést kap az adott csomag-registry (pl. npm) felé. Így a folyamat során nem kell előre létrehozott vagy tárolt PAT-et használnom, mert a futás idejére automatikusan generálódik a jogosultság.
Ez a megközelítés jelentősen csökkenti a token-kezelés kockázatát – nincs olyan hosszú életű kulcs, amit elfelejtek forgatni vagy ami kiszivároghat –, de nem helyettesíti a PAT-eket más típusú műveletekhez vagy API-hívásokhoz. A Trusted Publishing jelenleg támogatott a GitHub Actions és GitLab CI/CD környezetben, és egyre több CI-platform fogja követni ezt az irányt.
Mi változik most konkrétan?
A GitHub az npm ökoszisztémán keresztül vezeti be a PAT-kezelés első nagy változását. A mostani frissítés három fő területet érint, és minden esetben jól látszik, hogyan változik a korábbi működés.
Terület
Korábbi állapot
Új szabály
PAT élettartam
A tokenek alapértelmezett lejárata 30 nap volt, a klasszikus PAT akár korlátlanul is élt.
Az új granularis PAT alapértelmezett lejárata 7 nap, maximum 90 nap.
Klasszikus PAT-ek
Továbbra is használhatók voltak, teljes hozzáféréssel.
Teljes kivezetés: 2025 november közepétől minden klasszikus PAT érvénytelen lesz.
WebAuthn/passkey alapú 2FA váltja, ami ellenáll a phishing-támadásoknak.
Ezek a változások október közepétől indulnak, és november közepéig minden klasszikus token megszűnik.
Példák, ahol PAT-et használunk
CI/CD pipeline-ban: amikor a GitHub Actions új verziót publikál npm-re, PAT segítségével hitelesít.
Helyi fejlesztéskor: a git push vagy npm publish művelet PAT alapján engedélyezett.
Integrációs eszközöknél: például a Dependabot vagy a Renovate PAT-tel fér hozzá a repo-hoz, hogy automatikus frissítéseket küldjön.
Hogyan készülj fel?
Új granularis PAT-eket hozol létre, és minden pipeline-ban lecseréled a régieket.
Áttérsz az OIDC-alapú Trusted Publishing használatára, ahol lehetséges.
Rendszeresen rotálod a még meglévő PAT-eket.
Bevezeted a WebAuthn alapú 2FA-t, hogy megerősítsed a fiókom védelmét.
Összegzés
A Personal Access Token-ek (PAT) a modern fejlesztői hitelesítés alapját jelentik.
Különösen fontos felhő megoldásokkal való integrálásnál (pl. Azure DevOps Pipelines vagy AWS CodePipeline), mert így biztosíthatjuk, hogy csak a szükséges műveletekhez kapunk hozzáférést, és a felhőerőforrásokat is biztonságosan kezelhetjük.
A GitHub most azért változtat, hogy ezek a tokenek rövidebb életűek, korlátozottabb hatókörűek és biztonságosabbak legyenek. Ez az átmenet az automatizált, tokenmentes jövő felé vezet — ahol az azonosítás már teljesen automatizált és emberi beavatkozás nélküli.
Én személy szerint támogatom ezt az irányt. Ez a változás nemcsak engem véd, hanem mindenkit, aki a GitHub-ra és az npm-re épít.
A digitális világban a biztonság mindig is nagy jelentőséggel bírt. Gondoljunk csak az AWS indulásakor (2002), a sikert gátló bizalmatlanságra, amely sokáig nem engedett teret a felhő szolgáltatásoknak. Ez a bizalmatlanság azóta alább hagyott, de még mindig jelen van és kísérti a mindennapjainkat.
Emellett a digitális világ magával hozott egy új fenyegetettséget, ez pedig nem más, mint az adatok (személyes, érzékeny, stb.) eltulajdonítása. Ez többféleképpen történhet (egy technológia sebezhetőségének kihasználása, alacsony biztonságú rendszerek feltörése, stb.)
A leggyakoribb azonban a felhasználók jelszavának eltulajdonítása vagy a felhasználótól való kicsalása. Ugyanis ha megszerezzük egy magas jogosultsággal rendelkező felhasználó bejelentkezési adatait (felhasználónév és jelszó), akkor könnyedén tulajdoníthatunk el olyan adatokat, amelyek másoknak is értékes. Ráadásul anélkül, hogy komolyabb informatikai tudásra lenne szükségünk.
Ezért mindent meg kell tennünk, hogy felhasználói fiókjaink biztonságosak legyenek.
Hogyan?
Erre nagyon sok megoldás létezik. Például: Erőss jelszavak használata (bonyolult jelszavak, amelyek hosszabbak, mint 18 karakter), vagy többtényezős hitelesítés használata a felhasználói név és jelszó mellett.
Mi az a többtényezős hitelesítés?
A többtényezős hitelesítés (MFA) napjaink egyik legfontosabb biztonsági megoldása, amely jelentősen növeli az online fiókok védelmét. Az MFA lényege, hogy nem elég csak egyetlen jelszót megadni a bejelentkezéshez, hanem több különböző tényezőt is be kell vonni, mint például egy SMS-ben kapott kódot, egy hitelesítési alkalmazásban generált számot, vagy egy e-mailen érkező megerősítést. Ez a megközelítés rendkívül hasznos, mert csökkenti annak esélyét, hogy egy fiókot illetéktelenek hozzáférhessenek, még akkor is, ha valahogyan megszerezték a jelszót.
A felhőalapú szolgáltatások elterjedésével az MFA (Multifactor Authentication) különösen fontos szerepet kapott, hiszen a vállalati és személyes adatok egyre nagyobb része a felhőben tárolódik. A felhőben használt többtényezős hitelesítés biztosítja, hogy csak azok férhessenek hozzá az érzékeny adatokhoz, akik ténylegesen jogosultak erre, ezáltal növelve a digitális biztonság szintjét.
Microsoft Azure-ban eddig is javasolt volt ez a beállítás, de mostantól már kötelező is.
2025. első negyedévében pedig a parancssori eszközöknél (Azure-Cli, PowerShell), Mobil alkalmazásnál és az IaC megoldásoknál kell kötelezően bekapcsolnunk.
Mit jelent ez?
A fenti dátumok után be kell kapcsolnunk a felhasználóink számára a többtényezős hitelesítést. Majd a felhasználóinknak be kell állítaniuk valamilyen további hitelesítési formát (SMS-ben kapott kód, egy hitelesítési alkalmazásban generált szám, vagy egy e-mailen érkező megerősítés) az Azure-ba való bejelentkezéshez.
Sokaknak ez az elején kényelmetlenségnek tűnhet, de lássuk be, ez a szükséges rossz az adataink védelmének érdekében. 🙂
Ha a szervezetünknek több időre van szüksége az átálláshoz, akkor még kérhetünk egy rövid haladékot, de ezt nem javaslom, mert előbb-utóbb (inkább előbb) úgysem tudjuk elkerülni ennek használatát.
Én sok-sok éve használom már ezt a kiegészítő biztonsági megoldást és higgyétek el, hamar meg lehet szokni. Ma már ez egy rutin a mindennapjaimban és kifejezetten hiányzik, ha valahol nem tudok ilyen biztonság növelő funkciót igénybe venni. 🙂
Te ugye már használod a többtényezős hitelesítést?
