Az amerikai Kiberbiztonsági és Infrastruktúra-biztonsági Ügynökség, a CISA és a Nemzeti Szabványügyi és Technológiai Intézet, a NIST átfogó útmutatót tett közzé a modern hitelesítési rendszerekben használt digitális tokenek védelméről.
A 2026. szeptember 15-én véglegesített NIST IR 8587 azt mutatja be, hogyan csökkenthetik a szövetségi intézmények és felhőszolgáltatóik a tokenek ellopásának, meghamisításának és jogosulatlan felhasználásának kockázatát.
A Protecting Tokens and Assertions from Forgery, Theft, and Misuse című jelentés az identitástokenekre, hozzáférési tokenekre, föderációs állításokra, kriptográfiai aláírókulcsokra, valamint az ezeket létrehozó és ellenőrző rendszerekre is kiterjed.
Az ajánlások egy alapvető problémát kezelnek: ha a támadó megszerez egy használható tokent, nem feltétlenül kell ellopnia a felhasználó jelszavát vagy újra teljesítenie a többtényezős hitelesítést. Egy aláírókulcs kompromittálása pedig olyan hamis tokenek létrehozását is lehetővé teheti, amelyek kriptográfiai aláírása érvényesnek látszik.
Ilyenkor maga a token válik a hozzáférést biztosító hitelesítő adattá. Segítségével a támadó felhasználót személyesíthet meg, felhőalkalmazásokat érhet el, védett API-kat hívhat meg, vagy fenntarthat egy munkamenetet.
Az 55 oldalas dokumentum a NIST, a CISA és az NSA együttműködésével, valamint a CISA Joint Cyber Defense Collaborative kezdeményezésének szakmai közreműködésével készült. A NIST SP 800-53 korábbi, identitásszolgáltatókra és tokenvédelemre vonatkozó kiegészítéseire épül. A végleges NIST IR 8587 jelentés
Bár elsődleges célközönsége az amerikai szövetségi szektor és annak felhőszolgáltatói, a NIST szerint más szervezetek is felhasználhatják az ajánlásokat. Ryan Galluzzo, a NIST digitális identitással foglalkozó programjának vezetője kiemelte, hogy az útmutató minden olyan intézménynek hasznos lehet, amely tokeneket alkalmaz a hozzáférés-kezelésben. A NIST bejelentése
A tokenek kiemelt értékű célponttá váltak
A tokenek a korszerű identitáskezelés alapvető elemei. Egy felhőszolgáltatásba történő bejelentkezés után az identitásszolgáltató vagy az engedélyezési kiszolgáló olyan tokent bocsáthat ki, amely a felhasználóról, a hitelesítésről vagy a megengedett hozzáférésről hordoz információt.
A konkrét szerep a token típusától függ. Az identitástoken elsősorban a hitelesített személyre és az eseményre vonatkozó állításokat közvetíti, a hozzáférési token pedig egy erőforrás elérésének engedélyezésében vesz részt. A két típus nem használható automatikusan egymás helyett.
Az alkalmazások a megfelelő token ellenőrzésével biztosíthatják a hozzáférést anélkül, hogy minden kérésnél újra elkérnék a felhasználó jelszavát. Erre épül az egyszeri bejelentkezés, az identitásföderáció és számos delegált API-hozzáférési folyamat.
Tokeneket nem csak emberek használnak. Alkalmazások, automatizált szolgáltatások, felhős munkaterhelések és AI-ügynökök is kaphatnak ilyen hitelesítő adatokat.
Egy aktív munkamenethez tartozó token ellopása közvetlen hozzáférést nyithat a felhasználó számára engedélyezett erőforrásokhoz. Egy tokenaláíró kulcs megszerzése ennél is súlyosabb következményekkel járhat, mert több hamis token előállítását teheti lehetővé.
Az érvényes aláírás önmagában nem elegendő a bizalomhoz. Vizsgálni kell a kibocsátót, a címzettet, az érvényességi időt és azt is, hogy az adott kulcsot valóban használhatták-e ebben a környezetben erre a célra.
A kockázatot jól szemléltette a 2023-ban feltárt Storm-0558 kampány. A Microsoft elemzése szerint a támadó egy fogyasztói Microsoft-fiókokhoz használt aláírókulccsal hamisított tokeneket. Egy ellenőrzési hiba lehetővé tette, hogy ezeket vállalati levelezési szolgáltatások is elfogadják.
A NIST az eset kapcsán arra emlékeztetett, hogy egyetlen amerikai kormányzati intézménytől több mint 60 ezer e-mailt tulajdonítottak el. Az incidens megmutatta, hogyan erősítheti fel egymás hatását egy kulcs kompromittálása és a tokenellenőrzés hiányossága.
A szolgáltató és az ügyfél közösen felel a védelemért
Az útmutató egyik központi megállapítása, hogy a tokenbiztonság nem hárítható kizárólag a felhőszolgáltatóra vagy az ügyfélre.
A szolgáltató általában a tokenkibocsátás és az aláírás infrastruktúráját, az alapvető identitásszolgáltatásokat, a titokkezelést, a kulcsvédelmi megoldásokat és a platformszintű megfigyelést kezeli.
Az ügyfél felelősségi körébe tartozik többek között az identitásházirendek beállítása, a felhasználók és alkalmazások kezelése, a jogosultságok felülvizsgálata, az erős hitelesítés megkövetelése és a szükséges naplózás bekapcsolása.
Az incidenskezelés, a folyamatos felügyelet és a hozzáférés visszavonása gyakran mindkét fél összehangolt munkáját igényli.
A jelentés ezért azt ajánlja, hogy a szolgáltatók már a tervezés során építsék be a biztonságot, és a fontos védelmeket alapértelmezetten is tegyék elérhetővé.
Az ügyfeleknek megfelelő rálátásra van szükségük az architektúrára, az alkalmazott biztonsági mechanizmusokra és a tokenekkel kapcsolatos eseményekre. Enélkül nehéz megalapozott kockázati döntést hozni.
A beállíthatóság szintén lényeges. Egy érzékeny kormányzati rendszer rövidebb tokenélettartamot, erősebb kulcselkülönítést és részletesebb naplózást igényelhet, mint egy kisebb kockázatú alkalmazás.
A NIST a szabványalapú együttműködést is támogatja hibrid és többfelhős környezetben. A SAML, az OpenID Connect és az OAuth csökkentheti az egyedi integrációktól való függést, de egy ismert protokoll használata önmagában nem garantál biztonságos megvalósítást.
A szolgáltatásokat igénybe vevő intézmények számára a jelentés a NIST Risk Management Framework és az SP 800-63-4 digitálisidentitás-kockázatértékelésének alkalmazását javasolja. Az intézkedéseket a rendszer érzékenységéhez, a tranzakciók jelentőségéhez és a jogosulatlan hozzáférés következményeihez kell igazítani.
Az aláírókulcsokat a bizalmi lánc alapjaként kell védeni
Az aszimmetrikus aláírást használó tokenrendszerekben a kibocsátó egy magánkulccsal írja alá a tokent. A fogadó alkalmazás a hozzá tartozó nyilvános kulccsal ellenőrzi az aláírást.
Ha a támadó megszerzi a magánkulcsot, olyan hamis tokeneket hozhat létre, amelyek aláírása matematikailag helyes. A puszta aláírás-ellenőrzés ilyen esetben nem tudja megállapítani, hogy a tokent valóban az engedélyezett kibocsátási folyamat hozta-e létre.
A NIST IR 8587 ezért a kockázathoz igazított elkülönítést és kulcsvédelmet ajánl. Ennek eszköze lehet hardveres biztonsági modul, hardverrel védett kulcstároló, virtualizált elkülönítés vagy megfelelően ellenőrzött szoftveres megoldás.
A végleges dokumentum külön kezeli a kulcs biztonságos tárolását és biztonságos használatát. Egy védett tároló önmagában nem rendezi azt a kérdést, hogy mely folyamatok és milyen feltételek mellett kérhetnek aláírást a kulccsal.
Minden kulcshoz hozzá kell rendelni a rendeltetését, az érintett rendszert és a használatra jogosult összetevőket. A nyilvántartásnak tartalmaznia kell a tárolás helyét és a tervezett aktív használati időt is.
A magán- és titkos kulcsok titkosítatlan továbbítása vagy exportálása kerülendő. Az átadásnak hitelesített, bizalmasságot és sértetlenséget biztosító csatornán kell történnie.
Kézzel végzett, érzékeny kulcskezelési műveleteknél két vagy több személy bevonása csökkentheti a véletlen és szándékos visszaélés lehetőségét.
A mentett és nyilvános kulcsok védelme is számít
A kulcs biztonsági másolata nem lehet gyengébben védett, mint az éles példány.
Korlátozott értéke van annak, ha a termelési kulcs hardveres biztonsági modulban található, miközben egy védtelen másolata bekerül egy mentési archívumba.
A jelentés szerint a magán- és titkos kulcsok mentéseit olyan kulcstitkosító kulccsal célszerű védeni, amely megfelelően elkülönített, hardverrel védett mechanizmusban található.
A helyreállításhoz és archiváláshoz kapcsolódó hozzáféréseket szigorúan korlátozni és naplózni kell. A szervezetnek azt is tudnia kell, kik és mely rendszerek kaphatnak ilyen másolatokat.
A nyilvános kulcsoknál nincs szükség titkosságra, a hitelességük és sértetlenségük azonban alapvető.
Ha valaki egy kulcsközzétételi végponton, bizalmi tárolóban vagy metaadat-dokumentumban saját kulcsra cserélheti a valódit, elérheti, hogy a fogadó alkalmazás a támadó által aláírt tokeneket fogadja el.
A JSON Web Key Set, azaz JWKS-végpontokat, az OpenID Connect felderítési dokumentumait és a SAML-metaadatokat ezért hitelesített és sértetlenségvédett módon kell közzétenni. A fogadó oldalon a kulcs eredetét és megengedett felhasználását is ellenőrizni kell.
Automatizált kulcscserére van szükség
A NIST szerint az aláírókulcsokat meghatározott használati idővel rendelkező, kezelt biztonsági eszközökként kell kezelni.
A végleges jelentés a kulcsok használati időszakát inkább a rendszer besorolásához és a tranzakciók érzékenységéhez köti, mint merev telepítési kategóriákhoz.
Nem minden környezetben indokolt ugyanaz a cseregyakoriság. Egy kritikus kormányzati adatvagyonhoz biztosított adminisztrátori hozzáférés más kockázatot jelent, mint egy alacsonyabb jelentőségű szolgáltatás.
A cél ugyanakkor közös: csökkenteni kell azt az időt, ameddig egy kompromittált kulcs használható, és lehetővé kell tenni a rendkívüli kulcscserét elfogadhatatlan szolgáltatáskiesés nélkül.
A kulcs létrehozását, közzétételét, aktiválását, cseréjét, deaktiválását és eltávolítását lehetőség szerint automatizálni kell.
Dokumentálni kell az átállás teljes menetét, beleértve azt az időszakot is, amikor a régi és az új ellenőrzőkulcs párhuzamosan használható. Tervezett csere esetén ez lehetővé teheti a korábban kiadott tokenek szabályos lejáratát.
Kompromittálás gyanújakor viszont a bizalom gyors megszüntetése válhat szükségessé. Ennek része lehet az érintett nyilvános kulcs eltávolítása a JWKS-végpontról, SAML-metaadatból vagy más megbízható közzétételi csatornából.
A visszavont magánkulcs minden példányát — az éles, mentett és archivált változatokat is — megfelelően törölni kell. Az elavult kulcsazonosítók további használata konfigurációs hibára vagy visszaélési kísérletre utalhat.
Az alkalmazásoknak az aláíráson túl is ellenőrizniük kell a tokent
Egy helyes digitális aláírás azt mutatja, hogy a tokent az adott kulccsal írták alá, és az aláírt tartalom azóta nem változott meg.
Azt azonban nem bizonyítja, hogy a token bármely alkalmazásban, bármilyen környezetben és minden művelethez elfogadható.
A NIST ezért jelentős felelősséget helyez a tokeneket fogadó alkalmazásokra, API-átjárókra és erőforrás-kiszolgálókra.
A hozzáférés engedélyezése előtt ellenőrizni kell többek között:
- a kibocsátót;
- az aláírás érvényességét és az aláírókulcs megengedett használatát;
- a token célközönségét, vagyis az
audienceértékét; - az érvényességi időt;
- a felhasználóra, kliensre és hitelesítésre vonatkozó releváns állításokat;
- az adott folyamat visszajátszás elleni követelményeit.
A célközönség ellenőrzése akadályozza meg, hogy egy alkalmazásnak kibocsátott tokent másik szolgáltatásban használjanak fel.
Ennek hiányában egy kevésbé érzékeny szolgáltatáshoz megszerzett, egyébként szabályos token veszélyesebb erőforrás elérésére is alkalmas lehet, ha mindkettő ugyanabban a kibocsátóban bízik.
A tokenek és állítások egyedi azonosítója vagy az adott folyamathoz kötött egyszeri értéke segítheti a visszajátszás felismerését. Az ellenőrzést ugyanakkor a protokoll működéséhez kell igazítani: nem minden hozzáférési token rendeltetésszerűen egyszer használatos.
A hozzáférési döntést a tokenellenőrzésen túl kockázati jeleknek is támogatniuk kell. Ilyen lehet az eszköz regisztrációja, a hálózati eredet, a fiók állapota, a tranzakciós viselkedés, az erőforrás érzékenysége vagy egy ismert kompromittálási jel.
Ez különösen fontos ellopott, de változatlan tokennél. Annak aláírása és tartalma továbbra is szabályosnak látszhat, miközben már a támadó küldi a kérést.
A küldőhöz kötött token nehezebben használható fel máshonnan
A hagyományos bearer token birtoklásalapú hitelesítő adat: aki megszerzi és bemutatja, az megfelelő további korlátozások hiányában használhatja is.
Egy böngészőből, végpontról, alkalmazásnaplóból vagy más kompromittált rendszerből kimásolt token így másik készülékről is újrafelhasználható lehet a lejáratáig vagy hatékony visszavonásáig.
A NIST ezért támogatja a küldőhöz kötött tokenek alkalmazását. Ezek a tokent egy meghatározott klienshez vagy kriptográfiai kulcshoz kapcsolják.
A jelentés példaként említi a kölcsönös TLS-hitelesítést és a DPoP, vagyis Demonstrating Proof of Possession megoldást.
Ilyenkor a token bemutatása önmagában nem elég. A kliensnek a hozzá kötött magánkulcs feletti rendelkezést is igazolnia kell.
A megoldás korlátozza azt a gyakori támadási lehetőséget, hogy a megszerzett tokent egyszerűen átmásolják egy másik gépre.
Nem jelent azonban teljes védelmet egy kompromittált végpont ellen. Ha a támadó a kulcsot is megszerzi, vagy a legitim folyamaton keresztül tud kéréseket végrehajtani, a kötés védelmi értéke csökkenhet.
A dokumentum az eszközhöz kötött munkamenet-hitelesítő adatokat, a Device-Bound Session Credentials, röviden DBSC technológiát is tárgyalja.
Ez az eszközön védett kulcs segítségével kapcsolja a böngészős munkamenetet a készülékhez. Célja a lopott sütik és munkamenet-adatok másik végponton történő használatának korlátozása. A tényleges védelem a megvalósítástól és a munkamenet-kezeléstől függ; nem minden ellopott süti válik automatikusan azonnal használhatatlanná.
A rövid tokenélettartam szűkíti a támadó lehetőségeit
A rövid élettartamú hozzáférési token csökkenti azt az időablakot, amelyben egy ellopott hitelesítő adat használható.
A hosszú munkamenet kényelmesebb lehet, és mérsékelheti az ismételt bejelentkezések számát. Ugyanakkor a támadónak is több időt adhat.
A megfelelő érvényességi időt a rendszer, a felhasználó, a tranzakció és a kiegészítő védelmek alapján kell meghatározni.
Erős eszközkötés, kulcsbirtoklás-igazolás, folyamatos kockázatértékelés és gyors visszavonás mellett indokolható lehet hosszabb időszak. Magas kockázatú vagy gyengén felügyelt helyzetben rövidebb élettartam szükséges.
A frissítési token, vagyis refresh token külön figyelmet igényel. Segítségével a kliens új hozzáférési tokent kérhet anélkül, hogy a felhasználó ismét bejelentkezne.
Ha a támadó ezt szerzi meg, és újra meg újra használhatja, hosszabb ideig fenntarthatja a hozzáférését.
A jelentés ezért a frissítési tokenek visszajátszás elleni védelmét írja le, például küldőhöz kötés vagy rotáció alkalmazásával.
Rotáció esetén a felhasznált frissítési tokent új váltja fel, a korábbi pedig érvénytelenné válik. Egy már felhasznált példány ismételt bemutatása lopásra utaló jel lehet.
Különösen magas biztonsági igényű műveleteknél a szervezet mellőzheti a frissítést, és a token lejártakor vagy a kockázat változásakor teljes újrahitelesítést követelhet meg.
A visszavonás elosztott környezetben nehéz feladat
Állapotmentes tokenrendszerben a fogadó alkalmazás helyben is ellenőrizheti a tokenben található adatokat és aláírást. Nem feltétlenül kérdez rá minden műveletnél az identitásszolgáltatónál a fiók aktuális állapotára.
Ez kedvez a skálázhatóságnak és a rendelkezésre állásnak, de megnehezíti a már kiadott tokenek azonnali érvénytelenítését.
Ha egy fiókot letiltanak vagy kompromittáltnak minősítenek, a korábban kibocsátott token egyes rendszerekben továbbra is elfogadható maradhat a lejáratáig.
A NIST elismeri, hogy az azonnali, minden rendszerre kiterjedő visszavonás nem mindig valósítható meg.
Ezért a rövid élettartamot, a kontrollált frissítést és az újrahitelesítést együtt kell alkalmazni a fennmaradó kockázat csökkentésére.
A szolgáltatóknak ennek ellenére biztosítaniuk kell a technikailag megvalósítható visszavonási lehetőségeket, és továbbítaniuk kell az állapotváltozásokat a kapcsolódó alkalmazásoknak. A fogadó rendszereknek az érvényes visszavonási jelzés alapján el kell utasítaniuk a tokent és meg kell szüntetniük a kapcsolódó munkamenetet.
A jelentés az OpenID Foundation Shared Signals Framework és Continuous Access Evaluation Profile megoldásait emeli ki a biztonsági események megosztására.
Ezek segítségével egy fiók kompromittálása vagy más kockázati esemény több kapcsolódó rendszerben is intézkedést válthat ki, anélkül hogy mindenhol külön meg kellene várni a tokenek lejáratát.
A tokenállapot-listák és a globális tokenvisszavonás fejlesztés alatt álló specifikációi további lehetőségeket kínálnak. A dokumentum ezek követését javasolja, miközben jelzi, hogy nem minden hivatkozott megoldás végleges szabvány.
A naplózásnak az incidens rekonstruálását kell segítenie
A tokenekkel való visszaélés nehezen felismerhető, mert a támadó kérései hitelesített felhasználótól származónak tűnhetnek.
A gyanús tevékenység gyakran csak az identitásnaplók, felhőszolgáltatási adatok és alkalmazásnaplók összevetésével válik láthatóvá.
A NIST ezért manipulációval szemben védett eseményrögzítést javasol. Hasznos adat lehet a kibocsátó, az érintett identitás, a célközönség, a token- és kulcsazonosító, a kibocsátási és lejárati idő, a kliens jellemzői, a hitelesítés körülményei és az ellenőrzés eredménye.
A cél annak rekonstruálása, hogy mikor és hogyan adták ki a tokent, hol használták, mely erőforrás fogadta el, és milyen biztonsági ellenőrzések történtek.
Ehhez a szolgáltató és az ügyfél együttműködése szükséges. A szolgáltatónál lehetnek olyan platformszintű adatok, amelyeket az ügyfél nem lát; az ügyfél viszont olyan üzleti környezetet és alkalmazásnaplókat ismerhet, amelyek a szolgáltató számára nem hozzáférhetők.
A szerződéseknek és incidenskezelési eljárásoknak tisztázniuk kell az elérhető adatokat, azok megőrzési idejét és átadásuk sebességét.
A jelentés azt is elvárja a szolgáltatóktól, hogy megfelelően gyorsan értesítsék ügyfeleiket, ha azonosítják vagy megalapozottan feltételezik az ügyféladatok jogosulatlan elérését, közlését, módosítását vagy elvesztését.
Az értesítésnek elegendő információt kell tartalmaznia a kitettség felméréséhez és a szükséges korlátozó intézkedések megkezdéséhez.
A munkaterhelések és az AI-ügynökök identitása is ide tartozik
A 2025. decemberi tervezethez képest a végleges jelentés részletesebben foglalkozik a gépi munkaterhelések identitásával.
Felhőalkalmazások, konténerek, automatizálási rendszerek és szolgáltatásfiókok gyakran emberi bejelentkezés nélkül kommunikálnak egymással.
Ezekben a helyzetekben sok szervezet tartós API-kulcsokra vagy kódban, konfigurációban és telepítési rendszerekben tárolt titkokra támaszkodik.
A NIST ehelyett rövid élettartamú, szűk jogosultságú és meghatározott címzetthez kötött tokeneket ajánl.
A kibocsátásnál és használatnál a munkaterheléshez illeszkedő körülményeket is vizsgálni kell: regisztrált szolgáltatásról van-e szó, jóváhagyott hálózatból érkezik-e a kérés, és igazolható-e a megfelelő kulcs birtoklása.
Az AI-ügynökök eszközöket, adatkészleteket, API-kat és üzleti alkalmazásokat érhetnek el. A hozzáférési jogosultság ezért alapvetően meghatározza, milyen műveleteket végezhetnek.
Ha az ügynök aláírt tokeneket használ, az útmutató védelmi intézkedései rá is alkalmazhatók.
A dokumentum ugyanakkor nem teljes AI-ügynök-identitásbiztonsági keretrendszer. A delegált felhatalmazás, a megszemélyesítés, a dinamikus eszközhasználat és az önálló döntéshozatal további kérdéseket vet fel, amelyekhez külön szabványok és útmutatók szükségesek.
A posztkvantum-átállás az identitáskezelést is érinti
A NIST IR 8587 magas szintű szempontokat ad a posztkvantum-kriptográfiára való későbbi átálláshoz is.
A tokenek és identitásállítások védelme jelentős részben nyilvános kulcsú algoritmusokra épül. A hosszú élettartamú rendszereknél ezért ismerni kell, hol és milyen algoritmusokat használnak, illetve hogyan lehet azokat lecserélni.
Ehhez az aláíró- és ellenőrzőkulcsok, algoritmusok, kriptográfiai könyvtárak és függő alkalmazások teljes nyilvántartása szükséges.
Az egyedi formátumok, a kódba mereven beépített algoritmusválasztások és a dokumentálatlan bizalmi kapcsolatok megnehezíthetik a migrációt.
A jelentés nem ír elő teljes posztkvantum-architektúrát. Az automatizálásra, átjárhatóságra és kulcséletciklus-kezelésre helyezett hangsúly azonban előkészíti a későbbi változtatásokat.
Közel 250 szakmai észrevétel alapján véglegesítették
A NIST IR 8587 első nyilvános tervezete 2025 decemberében jelent meg.
A végleges kiadáshoz a NIST és a CISA több mint húsz közreműködőtől közel 250 külön észrevételt kapott. A JCDC-n keresztüli visszajelzéseket és egy 2026. januári nyilvános webinárium tapasztalatait is feldolgozták.
A végleges szöveg nagyobb rugalmasságot biztosít a kulcsvédelmi megoldások kiválasztásában, és inkább az elérendő biztonsági eredményekre összpontosít.
Különválasztja a biztonságos tárolást és használatot, módosítja a kulcsok aktív használati idejére vonatkozó megközelítést, bővíti a gépi identitások kezelését, és további szabványokra hivatkozik. A NIST összefoglalója a véglegesítésről
A dokumentum a „MUST” és „SHOULD” kifejezésekkel különíti el a megfelelőséghez szükséges követelményeket és az ajánlott gyakorlatokat.
Ez azonban nem jelenti azt, hogy az útmutató minden szervezetre automatikusan kötelező. A megfelelés önkéntes, amíg valamely alkalmazandó szabályzat, szerződés, támogatási feltétel vagy más kötelező rendelkezés elő nem írja.
A sikeres bejelentkezés után is folytatni kell az ellenőrzést
A szövetségi intézmények az útmutatót felhasználhatják felhőbeszerzéseknél, biztonsági értékeléseknél és identitáskezelési követelmények kialakításánál.
Vizsgálhatják például, hogy a szolgáltató képes-e megfelelően elkülöníteni az aláírókulcsokat, végrehajtani egy rendkívüli kulcscserét, használható naplókat biztosítani, korlátozni a tokenek címzettjeit és továbbítani a visszavonási jelzéseket.
A magánszektor számára a jelentés részletes viszonyítási alapot ad olyan rendszerek felméréséhez, amelyek titkosítást, egyszeri bejelentkezést és többtényezős hitelesítést használnak, de a munkamenetek védelme kevésbé átgondolt.
A tokeneket teljes életciklusuk alatt védeni kell: a létrehozástól és aláírástól a tároláson, bemutatáson és ellenőrzésen át a frissítésig, visszavonásig és megsemmisítésig.
Ahogy a támadók egyre inkább a már hitelesített munkameneteket veszik célba, a tokenek és aláírókulcsok kezelése központi biztonsági feladattá válik.
Egy érvényesnek látszó token a hozzáférési döntés egyik bemenete. Elfogadásához a megfelelő kibocsátót, címzettet, érvényességet, jogosultságot és használati környezetet is igazolni kell.
Az eredeti angol cikk címe: CISA & NIST Issue New Security Guidance To Counter Token Theft and Forgery Attacks.
