Git

| Olvasási idő: 4 perc |

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.

3. OIDC / Trusted Publishing – alternatíva pipeline-hoz

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.
2FA hitelesítés	TOTP-alapú (időzített kódos) kétlépcsős azonosítás.	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

1. CI/CD pipeline-ban: amikor a GitHub Actions új verziót publikál npm-re, PAT segítségével hitelesít.
2. Helyi fejlesztéskor: a git push vagy npm publish művelet PAT alapján engedélyezett.
3. 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?

1. Új granularis PAT-eket hozol létre, és minden pipeline-ban lecseréled a régieket.
2. Áttérsz az OIDC-alapú Trusted Publishing használatára, ahol lehetséges.
3. Rendszeresen rotálod a még meglévő PAT-eket.
4. 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.