NIST SP 800-63-4: důkazy k heslům, MFA a přístupovým klíčům (passkeys)

V pondělí v 08:10 dostává CISO ve fintech společnosti zprávu, které se obává každý vedoucí bezpečnosti: „Evidujeme podezřelá přihlášení do finančního administrátorského portálu. MFA byla schválena, ale uživatel tvrdí, že to nebyl on.“
V 08:25 už SOC vidí vzorec. Útočník neprolomil šifrování, nezneužil zranitelnost zero-day ani neobešel firewall. Vylákal heslo phishingem, vyvolal push výzvu a čekal na únavu uživatele. Jedno schválení stačilo. Účet měl zvýšená oprávnění k exportům zákaznické fakturace, auditním logům a řídicímu panelu třetí strany pro vypořádání.
V 09:00 se právní oddělení ptá, zda jde o porušení zabezpečení osobních údajů podle GDPR. Tým řízení rizik řeší, zda událost spouští regulační oznamovací povinnost podle DORA. Správní rada chce vědět, zda tvrzení společnosti „MFA všude“ skutečně odpovídalo realitě. Auditor ISO 27001, jehož audit je již naplánován na příští měsíc, nyní požaduje důkazy o bezpečné autentizaci, řízení přístupu, protokolování a nápravném opatření.
Proto je NIST SP 800-63-4 v roce 2026 důležitý.
Pro CISO, manažery souladu a vlastníky procesů není NIST SP 800-63-4 jen dalším dokumentem k digitální identitě. Stává se praktickou referencí pro moderní politiku hesel, MFA odolnou vůči phishingu, přístupové klíče (passkeys), autentizaci bez hesla a řízení životního cyklu autentizátorů. Skutečnou výzvou není pokyny přečíst. Skutečnou výzvou je doložit implementaci napříč ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 a očekáváními interního auditu.
Pozice Clarysec je jednoduchá: opatření v oblasti identit selhávají, pokud se považují za pouhá nastavení, nikoli za součást správy a řízení. Hesla, MFA, přístupové klíče (passkeys), toky obnovy, tokeny relací, privilegovaný přístup, servisní účty a autentizační logy musí být navrženy jako jeden systém bezpečnostních opatření, který vytváří důkazy.
Právě touto optikou pracuje Zenith Blueprint: 30krokový plán auditora, knihovna politik Clarysec i Zenith Controls: průvodce napříč požadavky na soulad. Zenith Controls nevytváří nová opatření. Mapuje očekávání bezpečnostních opatření podle ISO/IEC 27001:2022 a ISO/IEC 27002:2022 napříč dalšími normami, právními předpisy a auditními pohledy, aby se organizace vyhnuly roztříštěným důkazům a duplicitní práci v oblasti souladu.
„MFA je zapnutá“ není auditní odpověď
Mnoho organizací v posledních letech věřilo, že nasazení MFA uzavírá diskusi o rizicích identit. V roce 2026 je tento předpoklad nebezpečný.
Auditoři a regulační orgány nyní kladou přesnější otázky:
- Je MFA vynucována pro veškerý privilegovaný, vzdálený a vysoce rizikový přístup?
- Je autentizace odolná vůči phishingu tam, kde to riziko vyžaduje?
- Jsou přístupové klíče (passkeys) nebo autentizátory FIDO2 řízeny v rámci registrace, obnovy, revokace a životního cyklu zařízení?
- Jsou hesla kontrolována vůči seznamům uniklých a běžných přihlašovacích údajů?
- Jsou změny hesel vyvolány kompromitací, nikoli libovolnou kalendářní rotací?
- Mohou uživatelé vkládat hesla ze správců hesel?
- Jsou události autentizátorů protokolovány a přezkoumávány?
- Jsou toky obnovy účtu stejně silné jako toky přihlášení?
- Jsou tajné údaje API, tokeny OAuth, klíče SSH a přihlašovací údaje servisních účtů řízeny se stejnou disciplínou?
NIST SP 800-63-4 posouvá organizace k digitálním identitám založeným na riziku, síle autentizátorů a důkazech o životním cyklu. U modernizace hesel to znamená odklon od zastaralých návyků, jako jsou vynucené pravidelné změny hesel bez známek kompromitace, a zároveň posílení délky, kontroly vůči uniklým heslům, omezení četnosti požadavků, bezpečného ukládání a opatření pro obnovu. U MFA a přístupových klíčů (passkeys) to znamená zaměřit se na záruku autentizátoru, odolnost vůči phishingu, bezpečnou registraci, navázání na účet, revokaci a auditovatelnost.
Zenith Blueprint tento posun zachycuje v části Controls in Action, krok 19, Technická opatření I, při popisu bezpečné autentizace:
Autentizace je první a nejkritičtější linie obrany mezi aktérem hrozby a vašimi systémy, daty a službami. Pokud je autentizace slabá, vše ostatní — šifrování, monitorování, segmentaci — lze obejít. Opatření 8.5 zajišťuje, že autentizační mechanismy jsou bezpečně navrženy, konzistentně uplatňovány a odolné vůči známým metodám útoku.
Tato věta je jádrem auditu identit v roce 2026. Otázka už nezní: „Máte hesla a MFA?“ Otázka zní: „Dokážete prokázat, že vaše autentizační architektura je založená na riziku, odolná vůči známým metodám útoku, konzistentně vynucovaná a monitorovaná?“
Postavte systém opatření na identitě, autentizačních informacích a bezpečné autentizaci
Nejužitečnější způsob, jak převést NIST SP 800-63-4 do důkazů pro ISO/IEC 27001:2022, je vnímat identitu jako propojený systém bezpečnostních opatření.
Prostřednictvím Zenith Controls identifikuje Clarysec tři klíčové oblasti opatření ISO/IEC 27002:2022 pro sladění s NIST SP 800-63-4: 5.16 Správa identit, 5.17 Autentizační informace a 8.5 Bezpečná autentizace. V příloze A ISO/IEC 27001:2022 jde o A.5.16, A.5.17 a A.8.5.
| Oblast opatření | Co řídí | Téma důkazů podle NIST SP 800-63-4 | Typické auditní důkazy |
|---|---|---|---|
| ISO/IEC 27002:2022 5.16 Správa identit | Životní cyklus identity, jedinečnost, procesy nástupu, změny role a odchodu, vlastnictví účtu | Důkaz, že identity jsou jedinečné, ověřené, přiřazené, přezkoumávané a odstraňované | Exporty z IdP, HR tikety k nástupům, změnám rolí a odchodům, přezkumy přístupových práv, pracovní postupy ověřování identity |
| ISO/IEC 27002:2022 5.17 Autentizační informace | Hesla, PINy, klíče, certifikáty, tokeny, tajné údaje API, kódy pro obnovu | Životní cyklus autentizátoru, ukládání, přenos, rotace, revokace a obnova | Politika hesel, záznamy z trezoru tajných údajů, logy revokace tokenů, logy registrace přístupových klíčů (passkeys), postupy resetování |
| ISO/IEC 27002:2022 8.5 Bezpečná autentizace | Návrh autentizace, MFA, řízení relací, požadavky specifické pro systémy | MFA založená na riziku, přístupové klíče (passkeys), odolnost vůči phishingu, vynucování přístupu bez hesla, ochrana relací | Politiky podmíněného přístupu, výkazy pokrytí MFA, nastavení WebAuthn a FIDO2, konfigurace časového limitu relace |
Rozdíl je podstatný. A.5.16 se ptá: „Kdo má identitu?“ A.5.17 se ptá: „Jak je chráněn důkaz této identity?“ A.8.5 se ptá: „Jak se autentizace v systémech bezpečně provádí?“
Když organizace v auditech selhávají, často je to proto, že implementují jednu vrstvu bez ostatních. Nasadí přístupové klíče (passkeys), ale nedokážou doložit důkazy o revokaci. Vynucují MFA, ale ne pro starší administrátorskou konzoli. Nastaví pravidla hesel, ale nekontrolují hesla vůči uniklým heslům. Deaktivují uživatelský účet, ale zapomenou na aktivní relace nebo tokeny pro obnovu.
V Zenith Blueprint, části Controls in Action, krok 22, Organizační opatření, vysvětluje Clarysec A.5.17 jako otázku životního cyklu:
Pokud je identita otázkou „Kdo jste?“, pak je autentizace důkazem. Opatření 5.17 je místem, kde se teorie setkává s důvěrou. Vyžaduje, aby autentizační informace byly bezpečně spravovány po celý svůj životní cyklus a aby metody a přihlašovací údaje používané k ověření identity samy o sobě nepředstavovaly nejslabší článek.
Přístupový klíč (passkey) není v souladu jen proto, že existuje. Obhajitelným se stává tehdy, když dokážete doložit, jak je registrován, navázán, chráněn, obnoven, revokován, protokolován a přezkoumáván.
Modernizujte hesla bez ztráty auditní dohledatelnosti
Mnoho společností má stále politiky hesel napsané pro jiný model hrozeb. „Dvanáct znaků, symboly, změna každých 90 dní“ je známé pravidlo, ale známost není totéž co odolnost.
NIST SP 800-63-4 posiluje modernější přístup: delší hesla a heslové fráze, kontrola vůči uniklým nebo běžně používaným heslům, omezení četnosti požadavků, bezpečný reset, žádné libovolné pravidelné změny, pokud není podezření na kompromitaci, a uživatelsky přívětivá opatření podporující správce hesel. Neznamená to, že každá organizace musí přes noc přepsat každou politiku. Znamená to, že požadavky na hesla mají být založené na riziku, technicky vynucené a sladěné s důkazy pro ISO 27001.
Knihovna politik Clarysec pro SME poskytuje menším organizacím praktický základní soubor požadavků, který lze s rostoucí vyspělostí zlepšovat. Politika správy uživatelských účtů a oprávnění - SME stanoví:
Hesla musí splňovat požadavky na složitost (např. alespoň 12 znaků, alfanumerické znaky se symboly) a musí být měněna alespoň každých 90 dní.
Pro SME je to užitečný a vymahatelný výchozí bod. Modernizační projekt podle NIST SP 800-63-4 v roce 2026 by však měl přezkoumat, zda je pevná 90denní expirace pro každý systém stále vhodná, zejména pokud jsou zavedena MFA, kontrola vůči uniklým heslům, dostatečná délka hesla a pracovní postup resetování vyvolaného kompromitací. V praxi mnoho organizací ponechá základní požadavek během přechodu a následně doplní dodatek k modernizaci hesel schválený v rámci ošetření rizik a Prohlášení o použitelnosti.
Pro podniková prostředí poskytuje Clarysec Politiku správy uživatelských účtů a oprávnění, která vytváří vazbu na správu a řízení namísto pevného zakódování každého pravidla pro hesla:
Všechny uživatelské účty musí vynucovat složitost a expiraci hesel v souladu s Politikou hesel organizace.
Tato formulace umožňuje CISO aktualizovat politiku hesel v souladu s NIST SP 800-63-4 bez přepisování celého rámce řízení přístupu.
Praktická důkazní sada k modernizaci hesel by měla obsahovat:
- Aktuální politiku hesel a schválený dodatek k modernizaci.
- Konfiguraci IdP ukazující minimální délku, maximální délku a povolené znaky.
- Důkazy, že jsou povoleni správci hesel, včetně funkcionality vložení, pokud je relevantní.
- Konfiguraci kontroly vůči uniklým, slabým a běžným heslům.
- Politiku omezení četnosti požadavků nebo uzamčení při online hádacích útocích.
- Pracovní postup resetování hesla vyžadující odpovídající ověření identity.
- Architekturu ukládání hashů hesel pro aplikace, které ukládají přihlašovací údaje.
- Registr výjimek pro starší systémy, které nepodporují moderní nastavení.
- Postup resetování vyvolaného kompromitací s vazbou na reakci na incidenty.
- Důkazy o komunikaci s uživateli a školení.
Cílem není vyhrát debatu o jedné délce hesla. Cílem je doložit, že autentizace heslem je řízená, měřitelná a integrovaná do ISMS.
Posuňte MFA a přístupové klíče (passkeys) od „druhého faktoru“ k záruce
Pondělní ranní incident začal únavou z MFA. Právě proto se auditoři stále častěji ptají, zda je MFA odolná vůči phishingu, nikoli jen zda existuje.
Tradiční metody MFA, jako jsou SMS, e-mailový OTP, aplikace TOTP a push oznámení, mohou snížit riziko, ale nejsou rovnocenné. Přístupové klíče (passkeys) a autentizátory FIDO2/WebAuthn poskytují vyšší odolnost vůči phishingu, protože autentizace je navázána na legitimní origin a využívá kryptografii veřejného klíče. U vysoce rizikových uživatelů, privilegovaných správců, schvalovatelů ve financích, vývojářů s přístupem do produkčního prostředí a cest vzdáleného přístupu by MFA odolná vůči phishingu měla být cílovým stavem, pokud neexistuje dokumentovaná a schválená výjimka.
Podniková Politika bezpečné komunikace a vícefaktorové autentizace (MFA) od Clarysec nastavuje základní požadavek:
Vícefaktorová autentizace (MFA): Veškerý přístup k síti a informačním systémům organizace, zejména privilegovaný přístup nebo vzdálený přístup, musí vyžadovat vícefaktorovou autentizaci (MFA) (např. heslo plus jednorázový token OTP nebo biometrický faktor). Řešení vícefaktorové autentizace (MFA) musí být v souladu s osvědčenými postupy v odvětví (např. časově založené jednorázové kódy nebo hardwarové klíče) a musí být nakonfigurována tak, aby chránila před neoprávněným přístupem.
Pro SME stanoví Politika řízení přístupu - SME:
Privilegované účty musí používat vícefaktorovou autentizaci (MFA), pokud je podporována.
Formulace „pokud je podporována“ dává SME realistickou implementační cestu, ale zároveň vytváří auditní povinnost. Pokud privilegovaný systém MFA nepodporuje, organizace musí dokumentovat kompenzační opatření, jako jsou síťová omezení, správa privilegovaných přístupů (PAM), jump hosty, kratší relace, monitorování, ukládání do trezoru a migrační plán.
Zenith Blueprint, Controls in Action, krok 19, popisuje směr vývoje přímo:
Kde je to možné, autentizaci pouze heslem je třeba se vyhnout, zejména u administrátorských účtů, cloudových konzolí, nástrojů vzdáleného přístupu a jakéhokoli systému dostupného z internetu. MFA využívající druhý faktor, například hardwarový klíč, mobilní aplikaci nebo biometrii, je dnes základním požadavkem, nikoli nadstandardem.
Přístupové klíče (passkeys) do tohoto rámce přirozeně zapadají. Zavedení přístupových klíčů (passkeys) by nemělo být prezentováno pouze jako technologická modernizace. Mělo by být dokumentováno jako ošetření rizik pro phishing, credential stuffing, únavu z MFA, opakované používání hesel a převzetí účtu.
Model důkazů k přístupovým klíčům (passkeys), který auditoři potřebují
Přístupové klíče (passkeys) mohou být synchronizovatelné, vázané na zařízení, hardwarově podporované, platformové nebo roamingové v závislosti na autentizátoru a ekosystému. Úroveň záruky závisí na registraci, důvěryhodnosti zařízení, obnově, navázání na účet a revokaci. Projekt přístupových klíčů (passkeys) bez důkazů může vytvořit auditní nejasnosti, i když je technologie silná.
Použijte tento model k přípravě auditně připraveného zavedení přístupových klíčů (passkeys).
| Otázka k důkazům | Co doložit | Artefakt |
|---|---|---|
| Kdo může registrovat přístupové klíče (passkeys)? | Registrace je omezena na ověřené uživatele a schválené kontexty | Politika registrace, pravidla IdP, oprávněnost skupiny uživatelů |
| Jaký typ přístupového klíče (passkey) je povolen? | Typ autentizátoru odpovídá úrovni rizika | Standard záruky autentizátorů, povolený AAGUID nebo politika zařízení, pokud je podporováno |
| Jak je registrace chráněna? | Útočníci nemohou po odcizení hesla přidat vlastní autentizátor | Dodatečné ověření MFA, ověření helpdeskem, upozornění na registraci |
| Jak je řešena obnova? | Obnova není slabší než přihlášení | Postup obnovy, skripty podpory, logy ověření identity |
| Jak se postupuje u ztracených zařízení? | Ztracené autentizátory jsou rychle revokovány | Tikety revokace, evidence zařízení, logy událostí IdP |
| Jak je řešen privilegovaný přístup? | Správci používají metody odolné vůči phishingu tam, kde je to vyžadováno | Politiky podmíněného přístupu, přiřazení privilegovaných rolí |
| Jak je protokolována aktivita uživatelů? | Autentizační události jsou uchovávány a přezkoumávány | Autentizační logy, dotazy SIEM, pravidla upozornění |
| Jak jsou řízeny výjimky? | Starší systémy a vyloučení uživatelé mají schválené ošetření rizik | Registr výjimek, data expirace, kompenzační opatření |
To přímo odpovídá ISO/IEC 27001:2022. Kapitoly 4.1 až 4.4 vyžadují, aby organizace rozuměly kontextu, zainteresovaným stranám, rozsahu ISMS a provozním procesům. Kapitoly 5.1 až 5.3 vyžadují vedení, politiku, organizační role a odpovědnosti. Kapitoly 6.1.2 a 6.1.3 vyžadují opakovatelný proces posouzení rizik bezpečnosti informací a ošetření rizik, včetně výběru opatření, porovnání s přílohou A, Prohlášení o použitelnosti a schválení zbytkového rizika vlastníkem rizika. Kapitola 6.2 vyžaduje měřitelné cíle bezpečnosti informací.
To znamená, že zavedení přístupových klíčů (passkeys) by se mělo v ISMS objevit jako:
- Ošetření rizik krádeže přihlašovacích údajů a phishingu.
- Cíl, například „do konce Q3 migrovat 90 procent privilegovaného přístupu na MFA odolnou vůči phishingu“.
- Odůvodnění v Prohlášení o použitelnosti navázané na A.5.16, A.5.17 a A.8.5.
- Aktualizace politiky řízení přístupu.
- Případ užití pro protokolování a monitorování.
- Auditní důkazní sada.
V Zenith Blueprint, fázi řízení rizik, krok 13, Plánování ošetření rizik a Prohlášení o použitelnosti, popisuje Clarysec SoA jako most:
SoA je ve skutečnosti přemosťující dokument: propojuje vaše posouzení/ošetření rizik se skutečnými opatřeními, která máte. Jeho vyplněním si zároveň ověříte, zda jste některá opatření neopomenuli.
U NIST SP 800-63-4 je právě tento most místem, kde se rozhodnutí o heslech, MFA a přístupových klíčích (passkeys) stávají auditovatelnými.
Mapování napříč požadavky na soulad pro ISO 27001, NIS2, DORA, GDPR, NIST CSF a COBIT
Důkazy k identitám získávají hodnotu tehdy, když jeden soubor opatření plní více povinností.
NIS2 Article 21 vyžaduje, aby základní a důležité subjekty zavedly vhodná a přiměřená technická, provozní a organizační opatření zohledňující riziko, stav techniky, náklady na implementaci, velikost a dopad incidentu. Article 21(2) zahrnuje analýzu rizik, politiky, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečný vývoj, posouzení účinnosti kontrol, kybernetickou hygienu a školení, kryptografii, bezpečnost HR, řízení přístupu, správu aktiv a tam, kde je to vhodné, vícefaktorovou nebo průběžnou autentizaci. Article 20 činí ze schválení vedením, dohledu a školení kybernetické bezpečnosti povinnost v oblasti správy a řízení.
DORA přenáší stejné téma identit do finanční provozní odolnosti. Dotčené finanční subjekty musí udržovat dokumentovaný rámec řízení rizik v oblasti ICT s odpovědností řídicího orgánu, opatřeními ochrany a prevence, řízením přístupu, autentizací, monitorováním, detekcí anomálií, kontinuitou, reakcí, obnovou a školením. Articles 8 až 10 jsou zvláště relevantní pro identifikaci ICT aktiv a závislostí, ochranu ICT systémů, řízení přístupu, silnou autentizaci, monitorování a detekci. Articles 17 až 19 propojují stejné důkazy s řízením a oznamováním incidentů souvisejících s ICT.
GDPR se použije všude, kde jsou osobní údaje zpracovávány v rámci jeho územní a věcné působnosti. Article 5(1)(f) vyžaduje, aby osobní údaje byly zpracovávány s odpovídajícím zabezpečením. Article 5(2) vyžaduje odpovědnost. Article 32 vyžaduje vhodná technická a organizační opatření k zajištění úrovně zabezpečení odpovídající riziku. Odcizené heslo nebo kompromitovaný autentizátor se mohou stát porušením zabezpečení osobních údajů, pokud způsobí neoprávněný přístup k osobním údajům.
NIST CSF 2.0 přidává užitečnou manažerskou vrstvu. Jeho funkce GOVERN vyžaduje, aby byly pochopeny a řízeny právní, regulační a smluvní požadavky na kybernetickou bezpečnost, včetně povinností v oblasti soukromí. Profily CSF pomáhají organizacím porovnat aktuální a cílový stav a vytvořit prioritizované akční plány.
COBIT 2019 a auditní přístupy ISACA se ptají, zda opatření pro identity a řízení přístupu podporují cíle správy a řízení, zda jsou definovány manažerské postupy, zda síla autentizace odpovídá riziku a zda je doložen provoz opatření.
| Téma požadavku | ISO/IEC 27001:2022 a ISO/IEC 27002:2022 | NIS2 | DORA | GDPR | NIST CSF 2.0 |
|---|---|---|---|---|---|
| Odpovědnost v oblasti správy a řízení | Kapitoly 5.1 až 5.3, 6.1.3, opatření přílohy A pro přístup a monitorování | Article 20 schválení vedením a dohled | Articles 5 a 6 odpovědnost řídicího orgánu a rámec řízení rizik v oblasti ICT | Article 5(2) odpovědnost | GV.OC, GV.RM, GV.RR, GV.PO, GV.OV |
| Silná autentizace | A.5.16, A.5.17, A.8.5 | Article 21 řízení přístupu a MFA tam, kde je to vhodné | Article 9 ochrana, prevence a silná autentizace | Article 32 zabezpečení zpracování | PR.AA správa identit, autentizace a řízení přístupu |
| Životní cyklus autentizátoru | A.5.17 autentizační informace | Article 21 opatření založená na riziku | Article 9 ochranná opatření pro řízení přístupu a autentizaci | Articles 5 a 32 ochrana před neoprávněným přístupem | GV.RM, PR.AA |
| Protokolování a detekce | A.8.15 Protokolování, A.8.16 Monitorovací činnosti | Article 21 zvládání incidentů a účinnost kontrol | Articles 10, 17 a 18 detekce a klasifikace incidentů | Detekce porušení podporuje rozhodnutí podle Articles 33 a 34 | DE.CM, RS.MA |
| Hlášení incidentů | A.5.24 až A.5.28 řízení incidentů informační bezpečnosti | Article 23 včasné varování, oznámení incidentu a harmonogram závěrečné zprávy | Articles 17 až 19 proces a reporty incidentů souvisejících s ICT | Articles 33 a 34 oznámení porušení zabezpečení osobních údajů | RS.CO, RC.RP |
| Závislosti identit na třetích stranách | A.5.19 až A.5.23 vztahy s dodavateli a cloudové služby | Article 21 zabezpečení dodavatelského řetězce | Articles 28 až 30 riziko třetích stran v oblasti ICT | Odpovědnost správce a zpracovatele | GV.SC |
Stejný výkaz podmíněného přístupu z IdP může podpořit řízení přístupu podle ISO 27001, MFA podle NIS2, autentizaci podle DORA, odpovědnost za zabezpečení podle GDPR i postup vůči cílovému profilu NIST CSF.
Sestavte důkazní sadu k autentizátorům během jednoho odpoledne
CISO, manažer souladu nebo vedoucí IT může rychle vytvořit vysoce hodnotnou důkazní sadu tím, že se zaměří na jeden vysoce rizikový systém, například cloudovou konzoli, finanční platformu, zákaznický administrátorský portál nebo prostředí pro produkční nasazení.
Nejprve definujte rozsah. Identifikujte vlastníka společnosti nebo procesu, klasifikaci dat, skupiny uživatelů, privilegované role, cesty vzdáleného přístupu, aktuální autentizátory, dotčené osobní údaje a závislosti na třetích stranách. To podporuje ISO/IEC 27001:2022, kapitoly 4.1 až 4.4, protože rozsah, požadavky zainteresovaných stran a závislosti musí být pochopeny.
Zadruhé zachyťte aktuální nastavení autentizace. Exportujte nebo snímkem obrazovky zdokumentujte politiku hesel, vynucování MFA, konfiguraci přístupových klíčů (passkeys) nebo FIDO2, pravidla podmíněného přístupu, časový limit relace, metody obnovy, účty pro nouzový přístup (break-glass) a stav starší autentizace. Pokud systém používá lokální autentizaci, zdokumentujte důvod a stanovte migrační cestu.
Zatřetí porovnejte stav s jasným cílovým stavem:
- Hesla jsou kontrolována vůči slabým, běžným a uniklým přihlašovacím údajům.
- Pro privilegované, vzdálené nebo internetově dostupné systémy neexistuje přístup pouze heslem.
- Pro správce a vysoce rizikové uživatele se používá MFA odolná vůči phishingu.
- Registrace a obnova jsou bezpečné.
- Autentizátory se revokují při ukončení pracovního poměru nebo ztrátě zařízení.
- Protokolují se úspěšné a neúspěšné autentizace, použití MFA a změny autentizátorů.
- Upozornění pokrývají nemožné cestování, opakovaná selhání, novou registraci autentizátoru a riziková přihlášení.
Začtvrté přiložte důkazy z politik. SME Politika řízení přístupu - SME vyžaduje:
Vyžadují se jedinečná uživatelská jména; sdílené účty jsou zakázány.
Pro důkazy o životním cyklu účtu SME Politika správy uživatelských účtů a oprávnění - SME stanoví:
Logy vytvoření účtu, deaktivace účtu a změn oprávnění musí být bezpečně uchovávány alespoň 12 měsíců.
Pro protokolování autentizace stanoví Politika protokolování a monitorování - SME:
Autentizační logy: úspěšné a neúspěšné pokusy o přihlášení, doba trvání relace, použití MFA
Pro podnikové implementace vyžaduje Politika protokolování a monitorování protokolování:
Autentizace uživatelů a pokusy o přístup
Zapáté aktualizujte Prohlášení o použitelnosti. Označte A.5.16, A.5.17 a A.8.5 jako použitelné a doplňte poznámky, například:
- Podporuje očekávání NIST SP 800-63-4 pro životní cyklus autentizátorů.
- Podporuje očekávání NIS2 Article 21 pro řízení přístupu a MFA.
- Podporuje požadavky DORA na autentizaci a monitorování v rámci řízení rizik v oblasti ICT.
- Podporuje GDPR Article 32 v oblasti zabezpečení a odpovědnosti za přístup k osobním údajům.
- Výjimka: starší portál pro vypořádání nepodporuje FIDO2. Kompenzační opatření zahrnují omezení na VPN, monitorování privilegovaných relací, plán nápravy ze strany dodavatele a měsíční přezkum přístupových práv.
Nakonec připravte složku nazvanou „Důkazní sada k autentizaci - Q2 2026“ s výňatky z politik, posouzením rizik, záznamem o ošetření rizik, výňatkem ze SoA, konfigurací IdP, výkazem pokrytí MFA a přístupových klíčů (passkeys), seznamem privilegovaných uživatelů, registrem výjimek, logy registrace a revokace, vzorkem testu ukončení přístupu, dotazy SIEM, snímky upozornění, výňatkem z playbooku reakce na incidenty a komunikací k bezpečnostnímu povědomí uživatelů.
To je rozdíl mezi tvrzením „používáme MFA“ a tvrzením „dokážeme prokázat správu bezpečné autentizace“.
Jak různí auditoři otestují stejná opatření pro identity
Vyspělý program identit počítá s různými auditními pohledy.
Auditor ISO 27001 začne u systému řízení. Bude se ptát, jak byla rizika identit posouzena, proč byla vybrána konkrétní opatření, jak jsou uvedena v SoA, zda jsou politiky schváleny, zda jsou přiděleny odpovědnosti a zda důkazy prokazují provoz v čase. Otestuje konzistenci mezi registrem rizik, politikou řízení přístupu, nastavením IdP a logy.
Zenith Blueprint, fáze Controls in Action, krok 19, kontrolní seznam auditu pro opatření 8.1 až 8.5, popisuje praktický auditní požadavek:
Auditoři se budou ptát na nastavení složitosti hesel a na to, jak jsou vynucována (GPO v Active Directory, politiky IdP atd.). Předložte dokumentaci k nasazení MFA, na koho se vztahuje, kde je vynucováno a které systémy jsou chráněny.
Auditor DORA nebo NIS2 se zaměří na správu a řízení, odolnost a systémové riziko. Může požadovat důkazy o dohledu správní rady nebo řídicího orgánu, pokrytí kritických systémů, povinnostech třetích stran v oblasti autentizace, testech kontinuity a důkazy, že postupy obnovy mohou zahájit pouze autentizované osoby.
Přezkum podle GDPR se zaměří na osobní údaje. Bude se ptát, zda autentizace chrání osobní údaje před neoprávněným přístupem, zda je přístup omezen na nezbytný rozsah, zda logy podporují posouzení porušení zabezpečení a zda organizace dokáže prokázat odpovědnost.
Hodnotitel orientovaný na NIST může použít profily NIST CSF 2.0 k porovnání aktuálního a cílového stavu. Bude chtít prioritizovaný akční plán pokrývající správu a řízení, politiky, řízení přístupu, detekci a výsledky reakce.
Auditor COBIT 2019 nebo ISACA vyhodnotí, zda postupy pro identity a autentizaci podporují cíle správy a řízení, návrh opatření, provoz opatření, oddělení povinností, privilegovaný přístup a monitorování. Nemusí ho zajímat, jakou značku přístupového klíče (passkey) používáte. Bude ho zajímat, zda je opatření řízeno, měřeno, vlastněno a zlepšováno.
Nezapomeňte na ukončení, obnovu a ne-lidské identity
Mnoho autentizačních programů vypadá silně při přihlášení a slabě všude jinde.
Ukončení pracovního poměru je častým bodem selhání. Politika nástupu a ukončení od Clarysec konkrétně zahrnuje:
revokaci tokenů MFA/SSO, čipových karet nebo certifikátů
Toto ustanovení je třeba testovat. Vyberte tři ukončené uživatele a prokažte, že účty, relace, zařízení MFA, přístupové klíče (passkeys), certifikáty a metody obnovy byly včas revokovány. Pokud nedokážete doložit revokaci tokenů, vaše opatření ukončení přístupu je neúplné.
Obnova je další slabé místo. Pokud helpdesk může resetovat MFA po zodpovězení dvou jednoduchých otázek, útočník zacílí na obnovu přes helpdesk místo na přihlášení. Postupy obnovy musí vyžadovat silné ověření, protokolování tiketů, schválení pro privilegované uživatele, oznámení uživateli a monitorování aktivity po obnově.
Ne-lidská identita je třetí slepé místo. Zenith Blueprint krok 22 jasně uvádí, že autentizační informace zahrnují „hesla, PINy, kryptografické klíče, biometrické šablony, čipové karty, tokeny, certifikáty, OAuth tokeny, SSH klíče, API tajné údaje“. Útočníci často využívají API tokeny, klíče servisních účtů a OAuth granty k udržení přístupu. Zacházejte s těmito přihlašovacími údaji podle A.5.17, včetně ukládání do trezoru, vlastnictví, rotace, revokace a protokolování.
Jak vypadá dobrý stav v roce 2026
Vyspělé prostředí opatření pro identity v roce 2026 má tyto charakteristiky:
- Správní rada nebo řídicí orgán rozumí rizikům identit a schvaluje směr.
- Politika hesel je modernizovaná, uživatelsky přívětivá a technicky vynucovaná.
- Přístup pouze heslem je odstraněn u privilegovaných, vzdálených a internetově dostupných systémů.
- Přístupové klíče (passkeys) nebo autentizátory FIDO2 jsou prioritizovány pro vysoce rizikový přístup.
- Výjimky z MFA jsou dokumentované, schválené, časově omezené a kompenzované.
- Registrace, obnova a revokace autentizátorů jsou řízené.
- Ukončení zahrnuje revokaci účtu, tokenu, certifikátu, relace a přístupového klíče (passkey).
- Autentizační logy zahrnují úspěchy, selhání, použití MFA, dobu trvání relace a změny autentizátorů.
- Případy užití SIEM detekují credential stuffing, nemožné cestování, podezřelou registraci a únavu z MFA.
- SoA vysvětluje, proč jsou A.5.16, A.5.17 a A.8.5 použitelné.
- Mapování na NIS2, DORA, GDPR a NIST CSF jsou zaznamenána jednou a opakovaně využívána.
- Důkazy se shromažďují průběžně, nikoli narychlo těsně před auditem.
Tak se NIST SP 800-63-4 stává více než referenčním dokumentem. Stává se živým systémem opatření podporujícím bezpečnost, ochranu soukromí, odolnost a připravenost na audit.
Proměňte opatření pro identity v auditně připravené důkazy
Pokud vaše organizace aktualizuje pravidla hesel, nasazuje MFA odolnou vůči phishingu, zavádí přístupové klíče (passkeys) nebo se připravuje na auditní otázky k ISO 27001, NIS2, DORA nebo GDPR, nezačínejte pouze konfigurací nástrojů.
Začněte důkazním modelem.
Clarysec vám může pomoci:
- Namapovat očekávání NIST SP 800-63-4 pro hesla, MFA a přístupové klíče (passkeys) na ISO/IEC 27001:2022.
- Vytvořit politiku životního cyklu autentizátorů a důkazní sadu.
- Aktualizovat politiky řízení přístupu, MFA, protokolování, onboardingu a ukončení.
- Připravit Prohlášení o použitelnosti, které propojí riziko identit s opatřeními.
- Použít Zenith Blueprint ke strukturování implementačních kroků a připravenosti na audit.
- Použít Zenith Controls k mapování opatření pro identity napříč NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.
Nejlepší čas odhalit slabou obnovu, chybějící revokaci přístupových klíčů (passkeys) nebo neúplné vynucování MFA je před incidentem, před regulačním orgánem a před tím, než se zeptá auditor.
Udělejte z příštího přezkumu přístupových práv přezkum důkazů podle NIST SP 800-63-4. Stáhněte si příslušné politiky Clarysec, prozkoumejte Zenith Blueprint a použijte Zenith Controls k tomu, aby se implementace hesel, MFA a přístupových klíčů (passkeys) proměnila v jeden praktický, přiměřený a auditně připravený příběh souladu.
Frequently Asked Questions
About the Author

Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council


