PAM a účty pro nouzový přístup „break-glass“ pro ISO 27001 v roce 2026

V neděli ráno ve 02:14 obdrží velitel incidentu zprávu, které se obává každý CISO: „Autentizace v produkčním prostředí selhává. Administrátorská konzole je nedostupná. Přepnutí databáze na záložní instanci se zaseklo.“

Cloudový inženýr ve službě problém vidí, ale nemůže jej opravit. Jeho běžná privilegovaná role závisí na stejném poskytovateli identit, který je nyní degradovaný. Vedoucí provozu žádá o nouzový administrátorský přihlašovací údaj. Manažer compliance se ptá, zda byl účet pro nouzový přístup „break-glass“ někdy testován. Pověřenec pro ochranu osobních údajů se ptá, zda přístup k produkční databázi může zpřístupnit osobní údaje. CISO položí otázku, která rozhodne, zda půjde o řízenou obnovu, nebo auditní noční můru:

„Dokážeme doložit, kdo nouzový přístup použil, proč, co provedl a že byl účet následně resetován?“

Jiná organizace může stejnému problému čelit v klidnější místnosti. CISO ve fintech společnosti sedí po chybné konfiguraci cloudové databáze naproti externím auditorům. Incident byl rychle odstraněn, ale kořenová příčina nebyla uklidňující. Vývojář třetí strany měl trvalá administrátorská oprávnění. Když primární administrátor nebyl dostupný, vývojář použil účet pro nouzový přístup „break-glass“ založený na sdíleném hesle uloženém v „zabezpečené“ poznámce dostupné týmu DevOps.

Auditoři se nezaměřili pouze na chybnou konfiguraci. Ptali se, zda byl přístup časově omezený, zda existovala individuální odpovědnost, zda byly protokolovány příkazy, zda byly osobní údaje chráněny podle článku 32 GDPR, zda byly splněny povinnosti DORA v oblasti rizik ICT a zda bylo možné doložit očekávání NIS2 v oblasti kybernetické hygieny.

To je praktický tlakový bod správy privilegovaných přístupů (PAM) a účtů pro nouzový přístup „break-glass“ v roce 2026. PAM už není úzce vymezený projekt bezpečnosti identit. Je to místo, kde se sbíhají ransomware, kompromitace cloudu, dodavatelské riziko, ochrana údajů, provozní odolnost a auditní důkazy.

Privilegovaný přístup je místo, kde se útočníci snaží zvítězit. Nouzový přístup „break-glass“ je místo, kde se obránci snaží obnovit provoz. Oba spoléhají na stejnou nebezpečnou schopnost: zvýšený přístup, který může obejít opatření, měnit konfigurace, číst citlivá data, rotovat klíče, vypnout protokolování, obnovovat zálohy, nasazovat kód nebo ničit důkazy.

Praktický postoj Clarysec je jednoduchý: nouzový přístup je nezbytný, ale neřízený nouzový přístup je neřízené riziko. Správnou odpovědí není „žádné účty pro nouzový přístup „break-glass““. Správnou odpovědí je řízený model správy privilegovaných přístupů (PAM) s evidencí, schvalováním, časovými limity, silnou autentizací, protokolováním relací, přezkumem po použití, resetem přihlašovacích údajů a auditními důkazy.

Proč je privilegovaný přístup otázkou compliance na úrovni správních orgánů

V prostředích s nižší vyspělostí se privilegovaný přístup často bere jako úloha IT administrace. Někdo potřebuje administrátorská práva, otevře se tiket, přidělí se role a provoz pokračuje. Tento model neobstojí proti modernímu ransomwaru, cloud-native infrastruktuře, odpovědnosti podle NIS2, provozní odolnosti podle DORA ani kontrole porušení zabezpečení podle GDPR.

Směrnice NIS2 přesouvá správu a řízení kybernetické bezpečnosti na úroveň správních orgánů. Článek 20 vyžaduje, aby řídicí orgány základních a důležitých subjektů schvalovaly opatření pro řízení rizik kybernetické bezpečnosti, dohlížely na jejich implementaci a absolvovaly školení v oblasti kybernetické bezpečnosti. Článek 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření, včetně analýzy rizik, zvládání incidentů, kontinuity činností, zabezpečení dodavatelského řetězce, účinnosti kontrol, kybernetické hygieny, bezpečnosti HR, řízení přístupu, správy aktiv a MFA nebo průběžné autentizace, je-li to vhodné.

U poskytovatelů SaaS, poskytovatelů řízených služeb (MSP), poskytovatelů řízených bezpečnostních služeb (MSSP), cloudových služeb, datových center a dalších organizací digitální infrastruktury závisí použitelnost NIS2 na sektoru, velikosti, roli, přeshraničním dopadu a usazení v EU. Provozní poučení je přímé: řízení přístupu už není ukryto v technické příloze. Je součástí základního rámce kybernetické hygieny, který musí vedení schvalovat, monitorovat a korigovat.

U finančních subjektů mění akt o digitální provozní odolnosti slovník, nikoli podkladové riziko. DORA se použije od 17. ledna 2025 a zavádí jednotný rámec pro řízení rizik v oblasti ICT, hlášení významných incidentů souvisejících s ICT, testování digitální provozní odolnosti a řízení rizik třetích stran v oblasti ICT. Článek 5 vyžaduje uspořádání správy a kontrol pro rizika ICT, přičemž řídicí orgán definuje, schvaluje, dohlíží na ně a odpovídá za uspořádání řízení rizik ICT. Článek 6 vyžaduje dokumentovaný rámec řízení rizik ICT s politikami, postupy, protokoly a nástroji k ochraně aktiv ICT. Článek 17 vyžaduje proces řízení incidentů souvisejících s ICT, který detekuje, zaznamenává, klasifikuje, eskaluje a obnovuje bezpečný provoz.

GDPR přidává hledisko ochrany soukromí a odpovědnosti. Článek 5(1)(f) vyžaduje, aby osobní údaje byly zpracovávány s integritou a důvěrností. Článek 5(2) vyžaduje odpovědnost. Článek 25 vyžaduje záměrnou a standardní ochranu osobních údajů. Článek 32 vyžaduje vhodná technická a organizační opatření pro zabezpečení zpracování. Pokud privilegovaný uživatel může bez přezkumu exportovat záznamy zákazníků, přistupovat ke zvláštním kategoriím údajů, vypnout auditní logy nebo změnit nastavení uchovávání, organizace neudělala pouze chybu v IAM. Nemusí být schopna doložit odpovídající zabezpečení.

ISO/IEC 27001:2022 je páteří systému řízení, která umožňuje tyto povinnosti řídit v jednom integrovaném programu. Kapitola 4.2 vyžaduje, aby organizace porozuměla zainteresovaným stranám a jejich požadavkům, včetně právních, regulačních a smluvních povinností. Kapitola 5.1 vyžaduje vedení a závazek. Kapitola 6.1.2 vyžaduje posouzení rizik bezpečnosti informací. Kapitola 6.1.3 vyžaduje ošetření rizik. Kapitola 8 vyžaduje provozní plánování a řízení.

U privilegovaného přístupu se tím diskuse posouvá od otázky „který nástroj PAM máme koupit?“ k otázce „která rizika ošetřujeme, která opatření jsou vybrána, kdo je vlastní, jak se provozují a jaké důkazy prokazují, že fungují?“

PAM není jedno opatření, ale řetězec důkazů

Nástroj PAM může ukládat hesla do trezoru, zprostředkovávat relace, zaznamenávat stisky kláves, rotovat přihlašovací údaje a vynucovat just-in-time přístup. Tyto schopnosti jsou důležité. Pokud však organizace nedefinovala privilegované role, neschválila nouzový přístup, nenamapovala přístup na aktiva, nepřezkoumala práva, neochránila logy a nevyškolila administrátory, stává se nástroj pouze dílčím opatřením se slabou auditní obhajitelností.

Nejužitečnější způsob, jak řídit privilegovaný přístup, je uvažovat v cílových stavech opatření, nikoli v názvech nástrojů.

Zenith Controls: průvodce napříč požadavky compliance Zenith Controls považuje opatření ISO/IEC 27002:2022 8.2 Privilegovaná přístupová práva za těžiště PAM. Klasifikuje toto opatření jako preventivní, podporující důvěrnost, integritu a dostupnost, sladěné s konceptem kybernetické bezpečnosti Protect, provozní schopností řízení identit a přístupů a bezpečnostní doménou Protection.

Opatření 8.2 je silné, protože se propojuje s okolními opatřeními, která činí privilegovaný přístup auditovatelným:

Proto se auditor zřídka zastaví u otázky: „Máte systém PAM?“ Silnější auditní otázky zní: Máte evidenci privilegovaných účtů? Jsou privilegované role schválené? Jsou práva časově omezená? Jsou nouzové přihlašovací údaje zabezpečené? Dokážete doložit, kdo je použil? Jsou příkazy protokolovány? Jsou zahrnuti administrátoři dodavatelů? Jsou přístupová práva přezkoumávána? Byly přihlašovací údaje resetovány? Byly výjimky akceptovány jako riziko?

Mapování přístupových práv v Zenith Controls to říká přímo: správa přístupových práv operacionalizuje zásady řízení přístupu, jako jsou zásada minimálních oprávnění, princip „need-to-know“ a autorizace, zatímco privilegované účty vyžadují zvláštní dohled a rychlé odebrání, jakmile již nejsou nezbytné.

Požadavky politiky na důvěryhodný nouzový přístup „break-glass“

Účet pro nouzový přístup „break-glass“ není sdílené administrátorské heslo v zapečetěné obálce. V roce 2026 je tento model příliš slabý pro cloud, fintech, SaaS, zdravotnictví, řízené služby a regulovaný digitální provoz.

Obhajitelný model „break-glass“ potřebuje sedm minimálních pravidel politiky:

1. Účet musí být dokumentován.
2. Účet musí být schválen.
3. Použití musí být technicky proveditelným způsobem jednoznačně přiřaditelné konkrétní osobě.
4. Použití musí být omezeno na skutečné nouzové situace.
5. Použití musí být protokolováno a přezkoumáno.
6. Přihlašovací údaje nebo autentizační faktory musí být po použití resetovány nebo rotovány.
7. Účet musí být testován a zahrnut do rozsahu auditu.

Knihovna politik Clarysec převádí tyto zásady do použitelného jazyka správy a řízení.

Politika správy uživatelských účtů a oprávnění pro SME Politika správy uživatelských účtů a oprávnění – SME stanoví:

„Nouzový přístup (např. administrátorské účty „break glass“) musí být jasně dokumentován, zabezpečen a používán pouze tehdy, když je to absolutně nezbytné.“

Ze sekce „Ošetření rizik a výjimky“, ustanovení politiky 7.3.1.

Stejná politika pro SME pokračuje:

„Takové účty musí být protokolovány, po použití přezkoumány a po každé nouzové události resetovány.“

Ze sekce „Ošetření rizik a výjimky“, ustanovení politiky 7.3.2.

Pro každodenní zvýšení oprávnění politika pro SME také vyžaduje:

„Zvýšená nebo administrátorská oprávnění vyžadují dodatečné schválení generálním ředitelem nebo vedoucím IT a musí být dokumentována, časově omezena a podléhat pravidelnému přezkumu.“

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.2.2.

U větších organizací jde podniková sada politik hlouběji. Politika správy uživatelských účtů a oprávnění Politika správy uživatelských účtů a oprávnění vyžaduje, aby:

„Privilegované relace byly plně protokolovány, včetně vydaných příkazů a provedených akcí. Logy musí být pravidelně přezkoumávány určenými přezkoumávajícími osobami.“

Ze sekce „Požadavky na implementaci politiky“, ustanovení politiky 6.4.2.

Stejná politika vyžaduje, aby dočasné nebo nouzové účty s privilegovaným přístupem dodržovaly dokumentovaný postup „break-glass“ v ustanovení 6.2.5, zatímco ustanovení 7.4 vymezuje požadavky na tento postup.

Politika řízení přístupu Politika řízení přístupu posiluje uchovávání pro účely auditu:

„Rozhodnutí o schválení musí být protokolována a uchovávána pro účely auditu po dobu nejméně 2 let.“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.3.2.

Politika protokolování a monitorování pro SME Politika protokolování a monitorování – SME definuje očekávání pro protokolování autentizace:

„Autentizační logy: úspěšné a neúspěšné pokusy o přihlášení, doba trvání relace, použití MFA“

Ze sekce „Požadavky na správu a řízení“, ustanovení politiky 5.4.2.

Společně tato ustanovení mění nouzový přístup z hrdinského obcházení procesu na řízenou událost. Účet je výjimečný, ale správa a řízení výjimečné nejsou.

Přístup Zenith Blueprint k implementaci PAM

Zenith Blueprint: 30krokový plán auditora Zenith Blueprint chápe privilegovaný přístup jako praktický implementační problém, nikoli jako teoretické prohlášení o opatření. Ve fázi Controls in Action, krok 19, Technologická opatření I, uvádí:

„V každém informačním systému je privilegovaný přístup moc a s touto mocí přichází riziko.“

Z fáze Controls in Action, krok 19: Technologická opatření I.

Krok 19 vyžaduje, aby organizace identifikovaly privilegované účty napříč on-premise, cloudovými, SaaS, vývojovými a infrastrukturními prostředími. Zahrnuje doménové administrátory, uživatele root, administrátory cloudových tenantů, databázové superuživatele a kontrolery CI/CD pipeline. Zdůrazňuje také minimalizaci privilegovaného přístupu prostřednictvím řízení přístupu na základě rolí (RBAC), just-in-time zvýšení oprávnění a schvalovacích workflow.

To je důležité, protože mnoho závažných incidentů nezačíná formálním účtem pro nouzový přístup „break-glass“. Začínají trvalým oprávněním. Cloudový inženýr si ponechá práva vlastníka „pro jistotu“. Databázový administrátor si po přesunu do jiného týmu ponechá přístup do produkčního prostředí. Servisní účet CI/CD má široká oprávnění napříč prostředími. Účet poskytovatele řízených služeb je vyňat z MFA, protože „potřebují rychlý přístup“.

Krok 20 Zenith Blueprint rozšiřuje stejnou logiku na privilegované utility. Ukládá organizacím vytvořit nebo aktualizovat evidenci privilegovaných utilit, omezit jejich spouštění na autorizované administrátory, ověřit, že použití je protokolováno a napojeno na upozornění, a zvážit protokolování skriptů, například protokolování PowerShell prostřednictvím skupinové politiky. To je kritické, protože privilegovaný účet je často pouze vstupní bod. Škoda vzniká tehdy, když útočník spustí nástroje, které vypnou opatření, extrahují přihlašovací údaje nebo umožní laterální pohyb.

Krok 22 formalizuje životní cyklus řízení přístupu. Vyžaduje strukturované zřizování a rušení přístupů, ideálně integrované s HR a podporované workflow žádostí o přístup, s čtvrtletně dokumentovanými přezkumy přístupových práv. Krok 16 propojuje životní cyklus s offboardingem tím, že vyžaduje kontrolní seznam pro ukončení pracovního poměru, který HR a IT společně používají, včetně deaktivace účtů, vrácení aktiv a připomenutí dohod o mlčenlivosti.

Zenith Blueprint z PAM vytváří propojený provozní model: identita, HR, privilegované utility, protokolování, reakce na incidenty, přezkum přístupových práv a auditní důkazy se navzájem posilují.

Praktický model řízení účtů „break-glass“ pro rok 2026

Dobře navržený proces „break-glass“ musí fungovat i během selhání. Pokud závisí na stejném poskytovateli identit, ticketovací platformě a chatovací službě, které jsou během výpadku nedostupné, jde jen o divadlo.

Současně se nouzový přístup nesmí stát pohodlným obchvatným kanálem. Clarysec obvykle navrhuje řízení „break-glass“ kolem čtyř vrstev: prevence, aktivace, pozorování a obnova.

U cloudových prostředí zahrňte administrátory na úrovni tenantů, cloudové účty root, nouzové administrátory poskytovatele identit, privilegované servisní účty, hlavní databázové uživatele, role Kubernetes cluster-admin, nasazovací klíče CI/CD, administrátory trezorů tajemství a účty podpory třetích stran.

U hybridních prostředí zahrňte doménové administrátory, administrátory zálohování, administrátory hypervizorů, administrátory firewallů, administrátory konzole EDR a uživatele privilegovaných utilit.

U prostředí citlivých z hlediska ochrany soukromí zahrňte administrátory, kteří mohou přistupovat k databázím obsahujícím osobní údaje, logům obsahujícím identifikátory, HR záznamům, údajům ověřování biometrické identity, systémům monitorování podvodů nebo nástrojům zákaznické podpory.

Cílový stav se popisuje jednoduše a obtížně se předstírá: každá nouzová cesta je známá, schválená, zabezpečená, pozorovatelná, vratná a přezkoumaná.

60minutové cvičení důkazů pro „break-glass“

CISO nebo manažer compliance může tento týden provést užitečné cvičení „break-glass“ bez nákupu nového nástroje. Cílem není jen potvrdit, že účet funguje. Cílem je prokázat, že opatření vytváří důkazy.

Scénář

Předpokládejme, že primární poskytovatel identit je degradovaný. Běžné just-in-time zvýšení oprávnění není dostupné. Produkční databázový cluster potřebuje nouzové změny konfigurace k obnovení služby. Musí být aktivován cloudový administrátorský účet pro nouzový přístup „break-glass“.

Krok 1: Potvrďte, že účet je v evidenci privilegovaných účtů

Použijte Zenith Blueprint, fázi Controls in Action, krok 19, k ověření, že účet je uveden v evidenci privilegovaných účtů. Zaznamenejte název účtu a prostředí, vlastníka za byznys, technického vlastníka, dosažitelné systémy, dopad na osobní údaje, metodu autentizace, umístění v trezoru, metodu rotace a datum posledního testu.

Pokud účet chybí, považujte to za nedostatek v kontrolách a přidejte jej do registru rizik.

Krok 2: Ověřte soulad s politikou

Namapujte událost na požadavky Politiky správy uživatelských účtů a oprávnění pro dokumentované postupy „break-glass“ a protokolování privilegovaných relací. Pokud jste SME, použijte ustanovení Politiky správy uživatelských účtů a oprávnění pro SME 7.3.1 a 7.3.2 jako minimální základ: dokumentováno, zabezpečeno, nezbytné, protokolováno, přezkoumáno a resetováno.

Namapujte uchovávání schválení na ustanovení 5.3.2 Politiky řízení přístupu, které vyžaduje, aby rozhodnutí o schválení byla protokolována a uchovávána alespoň 2 roky.

Krok 3: Otevřete záznam o nouzovém přístupu

Vytvořte tiket nebo záznam incidentu před aktivací nebo při aktivaci. Uveďte:

• Důvod nouzového přístupu
• Dotčená služba
• Požadovaný účet
• Žadatel
• Schvalovatel
• Čas zahájení
• Očekávaný čas ukončení
• Dopad na zákazníky nebo regulační dopad
• Dopad na osobní údaje podle GDPR
• Příznak sledování oznamovací povinnosti podle NIS2 nebo DORA

Nečekejte až na konec, abyste rekonstruovali příběh. Auditní hodnota je nejsilnější, když záznam vznikne před použitím přístupu.

Krok 4: Aktivujte a pozorujte

Aktivujte účet pro nouzový přístup „break-glass“. Potvrďte, že se používá MFA nebo kompenzační autentizace, že se relace zaznamenává, že příkazy nebo administrátorské akce jsou protokolovány, že logy jsou předávány do centralizovaného protokolování, že synchronizace času podporuje rekonstrukci časové osy a že se generuje upozornění na použití nouzového účtu.

To je v souladu se Zenith Controls pro 8.15 Protokolování, které popisuje protokolování jako základní datovou vrstvu pro monitorování a uvádí, že privilegovaní uživatelé a spouštění privilegovaných utilit musí být protokolováni komplexně.

Krok 5: Uzavřete, resetujte a přezkoumejte

Po dokončení nouzové úlohy deaktivujte účet nebo jej vraťte do zapečetěného stavu, rotujte přihlašovací údaje nebo resetujte autentizační faktor, přezkoumejte logy relace, zdokumentujte příkazy a změny konfigurace, potvrďte, že nedošlo ke zbytečnému přístupu k datům, aktualizujte záznam incidentu, zaznamenejte získané poznatky a rozhodněte, zda byly dosaženy oznamovací prahové hodnoty podle NIS2, DORA nebo GDPR.

Pokud došlo k přístupu k osobním údajům, zapojte pověřence pro ochranu osobních údajů. Pokud událost způsobila přerušení služby nebo mohla mít významný dopad, zapojte vlastníka oznamování podle NIS2 nebo DORA. Pokud účet pro nouzový přístup „break-glass“ selhal, zdokumentujte to jako zjištění provozní odolnosti, nikoli pouze jako problém IAM.

Mapování compliance pro PAM a opatření „break-glass“

Nejsilnější model správy a řízení neduplikuje opatření pro každý právní předpis. Vytváří jeden řetězec důkazů, který podporuje více povinností.

NIST CSF 2.0 je zvláště užitečný při převodu PAM do aktuálního profilu a cílového profilu. Jeho profilová metoda začíná rozsahem, poté shromažďuje politiky, rizikové priority, registry, požadavky, postupy a pracovní role a následně vytváří prioritizovaný akční plán. U privilegovaného přístupu to znamená vymezit profil kolem bezpečnosti identit, správy cloudu, odolnosti proti ransomwaru, kritických finančních systémů nebo dodavatelského přístupu.

U finančních subjektů spadajících pod DORA funguje DORA jako sektorově specifický režim kybernetické odolnosti EU pro ekvivalentní povinnosti NIS2 v oblasti rizik a incidentů. To neznamená, že NIS2 není relevantní. Znamená to, že finanční subjekt má používat DORA jako řídicí režim pro požadavky na rizika ICT a incidenty, a zároveň udržovat koordinaci s národními strategiemi kybernetické bezpečnosti, příslušnými orgány a CSIRTy tam, kde je to relevantní.

Jak auditoři testují důkazy privilegovaného přístupu

Auditoři neposuzují PAM pouze čtením politiky. Porovnávají politiku, konfiguraci, logy, tikety, rozhovory a pozorovanou praxi.

Auditní metodika Zenith Controls pro privilegovaná přístupová práva odkazuje na auditní postupy ISO/IEC 19011:2018. Auditoři přezkoumávají politiky definující zvýšená práva, zřizování, monitorování a postupy odebrání. Prověřují evidence uživatelských účtů, záznamy přiřazování oprávnění a logy. Důkazy ověřují prostřednictvím rozhovorů, nástrojů PAM, adresářových služeb a vzorků logů.

U přístupových práv Zenith Controls uvádí, že auditoři vzorkují žádosti o přístup uživatelů, ověřují dokumentovaná schválení a potvrzují, že IT udělilo pouze schválený přístup. Také porovnávají uživatelské role se skutečnými právy a kontrolují, zda je prosazována zásada minimálních oprávnění. U protokolování auditoři kontrolují rozsah protokolování, typy událostí, doby uchovávání, ochranná opatření a skutečné položky logů. Posuzují, zda jsou zachycovány a přezkoumávány neúspěšná přihlášení, přístup k citlivým datům a změny konfigurace.

Dobrý balíček důkazů pro „break-glass“ obsahuje:

• Schválenou žádost o nouzový přístup
• Kontext incidentu nebo výpadku
• Identitu uživatele aktivujícího přístup
• Identitu schvalovatele
• Čas zahájení a ukončení
• Důkazy MFA nebo autentizace
• Záznam relace nebo log příkazů
• Systémové logy a upozornění SIEM
• Provedené změny
• Potvrzení resetu přihlašovacích údajů
• Přezkum po použití
• Posouzení přístupu k datům
• Posouzení regulační oznamovací povinnosti
• Nápravná opatření, pokud cokoli selhalo

Pokud vaše cvičení tento balíček nevytvoří, opatření není připravené na audit.

Skryté selhání: privilegovaný přístup třetích stran

Mnoho organizací řídí zaměstnanecké administrátory lépe než administrátory dodavatelů. Pro cloud, SaaS, fintech a prostředí řízených služeb je to přesně opačně, než by mělo být.

Článek 21 NIS2 zahrnuje zabezpečení dodavatelského řetězce a vztahy s přímými dodavateli a poskytovateli služeb. Články 28 až 30 DORA jdou u finančních subjektů dále a vyžadují strategii řízení rizik třetích stran v oblasti ICT, registry smluv o službách ICT, náležitou péči, posouzení rizika koncentrace, práva na audit, práva ukončení, výstupní strategie a smluvní bezpečnostní opatření.

Privilegovaný dodavatelský přístup má být v rozsahu PAM, pokud dodavatel může spravovat produkční prostředí, podporovat kritické nebo důležité funkce, přistupovat k osobním údajům, měnit bezpečnostní konfigurace, spravovat zálohy, nasazovat kód nebo provozovat monitorovací nástroje.

Clarysec obvykle očekává, že opatření pro privilegovaný přístup dodavatelů zahrnují:

• Jmenované uživatele dodavatele, nikoli sdílené účty dodavatele
• Smluvní bezpečnostní požadavky na privilegovaný přístup
• MFA a bezpečný vzdálený přístup
• Časově omezená přístupová okna
• Schválení zákazníkem pro nouzový přístup
• Protokolování relací nebo rovnocenné auditní stopy
• Okamžité odebrání při změně personálu
• Povinnosti spolupráce při incidentech
• Uchovávání důkazů sladěné s auditními potřebami zákazníka
• Výstupní plán pro odstranění přístupu dodavatele

Výstupy dodavatelského řetězce v NIST CSF 2.0 zde silně odpovídají. Vyžadují role a odpovědnosti dodavatelů, prioritizaci dodavatelů podle kritičnosti, požadavky ve smlouvách, náležitou péči, průběžné monitorování, zapojení dodavatelů do plánování incidentů a plány rizik po ukončení smlouvy.

Pokud je účet poskytovatele řízených služeb vyňat z vašeho interního workflow PAM, nejde o pohodlí. Jde o vysoce rizikovou výjimku, která patří do registru rizik, registru dodavatelů a přezkumu přístupových práv.

Běžná zjištění k PAM a „break-glass“ v roce 2026

V projektech Clarysec jsou zjištění zřídka překvapivá. Obvykle jde o kombinaci dobrých úmyslů, provozního tlaku a neúplných důkazů.

Nejběžnější zjištění jsou:

• Účty pro nouzový přístup „break-glass“ existují, ale nejsou uvedeny v evidenci privilegovaných účtů.
• Nouzové účty jsou vyňaty z běžných přezkumů přístupových práv.
• Organizace nedokáže doložit, kdo nouzový účet použil.
• Účet nebyl po použití resetován.
• Privilegované relace jsou protokolovány, ale příkazy nikoli.
• Logy existují lokálně, ale nejsou chráněny před privilegovanými uživateli.
• Cloudové účty root nejsou testovány.
• Procesy obnovy MFA nejsou dokumentovány.
• Privilegovaný přístup pro CI/CD pipeline a servisní účty je ignorován.
• Přístup podpory třetí strany obchází interní schvalování.
• Schválení přístupu existuje v chatových zprávách, ale není uchováno jako auditní důkaz.
• Offboarding odebere e-mail a VPN, ale ne administrátorská práva v SaaS.
• Pověřenec pro ochranu osobních údajů není zapojen, když privilegovaný přístup může zpřístupnit osobní údaje.
• Playbooky incidentů neobsahují rozhodovací body pro oznamování podle NIS2, DORA nebo GDPR.

Každé zjištění lze řešit prostřednictvím ošetření rizik podle ISO/IEC 27001:2022. Identifikujte riziko, přiřaďte vlastníka, vyberte opatření, aktualizujte Prohlášení o použitelnosti, implementujte plán ošetření a uchovávejte dokumentované důkazy. To je síla používání ISMS namísto roztříštěné sady bezpečnostních úkolů.

Jak vypadá dobrý stav

Vyspělý provozní model PAM a „break-glass“ má pět opakujících se rutin.

Zaprvé, inventarizujte privilegovaný přístup měsíčně nebo průběžně. Zahrňte lidské administrátory, servisní účty, nouzové účty, cloudové role, identity CI/CD, databázové uživatele, privilegované utility a administrátory třetích stran.

Zadruhé, prosazujte zásadu minimálních oprávnění prostřednictvím rolí, just-in-time zvýšení oprávnění a schvalování. Trvalá oprávnění musí být výjimečná, odůvodněná a přezkoumávaná častěji než běžný uživatelský přístup.

Zatřetí, monitorujte privilegované chování. Protokolujte autentizaci, dobu trvání relace, použití MFA, příkazy, změny konfigurace, exporty dat, neúspěšné pokusy, eskalaci oprávnění a spouštění privilegovaných utilit.

Začtvrté, testujte účty pro nouzový přístup „break-glass“ před nouzovou situací. Účet pro nouzový přístup „break-glass“, který nebyl nikdy testován, je předpoklad, nikoli opatření.

Zapáté, reportujte vedení. NIS2 i DORA zvyšují kybernetickou bezpečnost a rizika ICT na odpovědnost řídicích orgánů. Správní orgán nepotřebuje každý log příkazu, ale potřebuje metriky: počet privilegovaných účtů, opožděné přezkumy, nouzové aktivace, administrátorské účty dodavatelů, neúspěšné testy, kritické výjimky a stav nápravy.

Zde se sada nástrojů Clarysec stává praktickou. Knihovna politik poskytuje jazyk správy a řízení. Zenith Blueprint poskytuje implementační posloupnost. Zenith Controls poskytuje mapování napříč požadavky compliance, vztahy opatření, podpůrné normy a auditní metodiku.

Další kroky: proměňte nouzový přístup v odolnost připravenou na audit

Pokud vaše organizace v posledních 90 dnech netestovala nouzový přístup „break-glass“, začněte tím. Nezačínejte workshopem pro výběr nástroje. Začněte důkazy.

1. Vytvořte nebo aktualizujte evidenci privilegovaných účtů.
2. Identifikujte každý účet pro nouzový přístup „break-glass“ a každou nouzovou administrátorskou cestu.
3. Namapujte každý účet na vlastníka za byznys, vlastníka systému a dopad na data.
4. Potvrďte pokrytí politikou pomocí Politiky správy uživatelských účtů a oprávnění Politika správy uživatelských účtů a oprávnění nebo Politiky správy uživatelských účtů a oprávnění pro SME Politika správy uživatelských účtů a oprávnění – SME.
5. Použijte Zenith Blueprint Zenith Blueprint, fázi Controls in Action, kroky 19, 20, 22 a 16, k propojení privilegovaného přístupu, privilegovaných utilit, přezkumů životního cyklu a offboardingu.
6. Použijte Zenith Controls Zenith Controls k mapování opatření ISO/IEC 27002:2022 8.2, 5.18 a 8.15 na důkazní očekávání NIS2, DORA, GDPR a NIST.
7. Proveďte cvičení důkazů pro „break-glass“ a zaznamenejte výsledky.
8. Přidejte mezery do plánu ošetření rizik a sledujte nápravu až do uzavření.

Privilegovaný přístup je moc. Nouzový přístup „break-glass“ je nouzová moc. V roce 2026 se z ransomwaru, výpadků cloudu a selhání identity čistě zotaví ty organizace, které dokážou prokázat, že nouzový přístup byl řízen před krizí, během ní i po ní.

Clarysec vám může pomoci tento důkaz vybudovat – od politik přes mapování opatření až po důkazy připravené na audit. Začněte s Zenith Blueprint, propojte jej s Politikou správy uživatelských účtů a oprávnění a Politikou řízení přístupu a poté použijte Zenith Controls k prokázání, jak váš program PAM podporuje ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.