PAM a účty „break glass“ podľa ISO 27001 v roku 2026

O 02:14 v nedeľu ráno dostane veliteľ incidentu správu, ktorej sa obáva každý CISO: „Autentifikácia v produkčnom prostredí zlyháva. Administrátorská konzola je nedostupná. Prepnutie databázy do záložného prostredia sa zaseklo.“

Cloudový inžinier v pohotovosti problém vidí, ale nevie ho odstrániť. Jeho bežná privilegovaná rola závisí od toho istého poskytovateľa identít, ktorý je práve degradovaný. Vedúci prevádzky žiada núdzové administrátorské poverenie. Manažér súladu sa pýta, či bol účet „break glass“ niekedy testovaný. DPO sa pýta, či prístup k produkčnej databáze môže sprístupniť osobné údaje. CISO položí otázku, ktorá rozhodne, či pôjde o riadenú obnovu alebo auditnú nočnú moru:

„Vieme preukázať, kto použil núdzový prístup, prečo, čo vykonal a že účet bol následne resetovaný?“

Iná organizácia môže čeliť rovnakému problému v tichšej miestnosti. CISO fintech spoločnosti sedí oproti externým audítorom po chybnej konfigurácii cloudovej databázy. Incident bol rýchlo odstránený, no koreňová príčina nebola upokojujúca. Externý vývojár mal trvalé administrátorské oprávnenia. Keď primárny administrátor nebol dostupný, vývojár použil účet „break glass“ založený na zdieľanom hesle uloženom v „bezpečnej“ poznámke dostupnej tímu DevOps.

Audítori sa nezamerali len na chybnú konfiguráciu. Pýtali sa, či bol prístup časovo obmedzený, či existovala individuálna zodpovednosť za vykonané úkony, či boli príkazy logované, či boli osobné údaje chránené podľa GDPR Article 32, či boli splnené povinnosti DORA v oblasti rizík IKT a či boli preukázateľne naplnené očakávania NIS2 v oblasti kybernetickej hygieny.

Toto je skutočný tlakový bod správy privilegovaného prístupu a účtov „break glass“ v roku 2026. PAM už nie je úzko zameraný projekt bezpečnosti identít. Je to miesto, kde sa stretávajú ransomvér, kompromitácia cloudu, dodávateľské riziko, ochrana údajov, prevádzková odolnosť a auditné dôkazy.

Privilegovaný prístup je miesto, kde sa útočníci snažia zvíťaziť. Prístup „break glass“ je miesto, kde sa obrancovia snažia obnoviť prevádzku. Oba sa opierajú o tú istú nebezpečnú schopnosť: zvýšený prístup, ktorý dokáže obísť kontroly, meniť konfigurácie, čítať citlivé údaje, rotovať kľúče, vypnúť logovanie, obnovovať zálohy, nasadzovať kód alebo ničiť dôkazy.

Praktický postoj Clarysec je jednoduchý: núdzový prístup je potrebný, ale neriadený núdzový prístup je neriadené riziko. Správnou odpoveďou nie je „žiadne účty break glass“. Správnou odpoveďou je riadený model PAM s inventárom, schvaľovaním, časovými limitmi, silnou autentifikáciou, logovaním relácií, preskúmaním po použití, resetom poverení a auditnými dôkazmi.

Prečo je privilegovaný prístup otázkou súladu na úrovni predstavenstva

V prostrediach s nižšou zrelosťou sa privilegovaný prístup často považuje za úlohu správy IT. Niekto potrebuje administrátorské práva, otvorí sa ticket, pridelí sa rola a organizácia pokračuje ďalej. Tento model neobstojí pri modernom ransomvéri, cloud-native infraštruktúre, zodpovednosti podľa NIS2, prevádzkovej odolnosti podľa DORA ani pri preverovaní porušenia ochrany osobných údajov podľa GDPR.

Smernica NIS2 presúva riadenie kybernetickej bezpečnosti do zasadacej miestnosti predstavenstva. Article 20 vyžaduje, aby riadiace orgány základných a dôležitých subjektov schvaľovali opatrenia riadenia rizík kybernetickej bezpečnosti, dohliadali na ich implementáciu a absolvovali školenie v oblasti kybernetickej bezpečnosti. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia vrátane analýzy rizík, riešenia incidentov, kontinuity činností, bezpečnosti dodávateľského reťazca, účinnosti kontrol, kybernetickej hygieny, bezpečnosti ľudských zdrojov, riadenia prístupu, správy aktív a MFA alebo priebežnej autentifikácie, ak je to vhodné.

Pre poskytovateľov SaaS, poskytovateľov spravovaných služieb, poskytovateľov spravovanej bezpečnosti, cloudové služby, dátové centrá a ďalšie organizácie digitálnej infraštruktúry závisí uplatniteľnosť NIS2 od odvetvia, veľkosti, roly, cezhraničného dopadu a usadenia v EÚ. Prevádzkové ponaučenie je priame: riadenie prístupu už nie je ukryté v technickej prílohe. Je súčasťou základnej úrovne kybernetickej hygieny, ktorú musí manažment schvaľovať, monitorovať a napravovať.

Pre finančné subjekty mení Nariadenie o digitálnej prevádzkovej odolnosti jazyk, nie však základné riziko. DORA sa uplatňuje od 17. januára 2025 a zavádza jednotný rámec pre riadenie rizík IKT, oznamovanie významných incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti a riadenie rizík externých poskytovateľov IKT. Article 5 vyžaduje mechanizmy správy a kontroly rizík IKT, pričom riadiaci orgán definuje, schvaľuje a dohliada na nastavenie riadenia rizík IKT a nesie zaň zodpovednosť. Article 6 vyžaduje zdokumentovaný rámec riadenia rizík IKT s politikami, postupmi, protokolmi a nástrojmi na ochranu aktív IKT. Article 17 vyžaduje proces riadenia incidentov súvisiacich s IKT, ktorý incidenty deteguje, zaznamenáva, klasifikuje, eskaluje a obnovuje bezpečnú prevádzku.

GDPR pridáva pohľad ochrany súkromia a preukázateľnej zodpovednosti. Article 5(1)(f) vyžaduje, aby sa osobné údaje spracúvali spôsobom zabezpečujúcim ich integritu a dôvernosť. Article 5(2) vyžaduje preukázateľnú zodpovednosť. Article 25 vyžaduje ochranu údajov už od návrhu a štandardne. Article 32 vyžaduje primerané technické a organizačné opatrenia na bezpečnosť spracúvania. Ak privilegovaný používateľ môže exportovať záznamy zákazníkov, pristupovať k osobitným kategóriám údajov, vypnúť auditné logy alebo meniť nastavenia uchovávania bez preskúmania, organizácia neurobila iba chybu v IAM. Nemusí byť schopná preukázať primeranú bezpečnosť.

ISO/IEC 27001:2022 je chrbtovou kosťou systému manažérstva, ktorá umožňuje riešiť tieto povinnosti v jednom integrovanom programe. Kapitola 4.2 vyžaduje, aby organizácia porozumela zainteresovaným stranám a ich požiadavkám vrátane zákonných, regulačných a zmluvných povinností. Kapitola 5.1 vyžaduje vodcovstvo a záväzok. Kapitola 6.1.2 vyžaduje posúdenie rizík informačnej bezpečnosti. Kapitola 6.1.3 vyžaduje ošetrenie rizík. Kapitola 8 vyžaduje prevádzkové plánovanie a riadenie.

Pri privilegovanom prístupe sa tým diskusia posúva od otázky „ktorý nástroj PAM máme kúpiť?“ k otázke „ktoré riziká ošetrujeme, ktoré kontroly sme vybrali, kto ich vlastní, ako sa prevádzkujú a aké dôkazy preukazujú, že fungujú?“

PAM nie je jedna kontrola, ale reťazec dôkazov

Nástroj PAM môže ukladať heslá do trezora, sprostredkovať relácie, zaznamenávať stlačenia klávesov, rotovať poverenia a vynucovať just-in-time prístup. Na týchto schopnostiach záleží. Ak však organizácia nedefinovala privilegované roly, neschválila núdzový prístup, nenamapovala prístup na aktíva, nepreskúmala práva, neochránila logy a nevyškolila administrátorov, nástroj sa stáva čiastkovou kontrolou so slabou auditnou obhájiteľnosťou.

Najužitočnejší spôsob riadenia privilegovaného prístupu je premýšľať v očakávaných výsledkoch kontrol, nie v názvoch nástrojov.

Zenith Controls: The Cross-Compliance Guide Zenith Controls považuje kontrolu ISO/IEC 27002:2022 8.2, práva privilegovaného prístupu, za ťažisko PAM. Klasifikuje túto kontrolu ako preventívnu, podporujúcu dôvernosť, integritu a dostupnosť, zosúladenú s funkciou kybernetickej bezpečnosti Protect, prevádzkovou spôsobilosťou správy identít a prístupov a bezpečnostnou doménou Protection.

Kontrola 8.2 je silná, pretože sa prepája s okolitými kontrolami, ktoré robia privilegovaný prístup auditovateľným:

Preto sa audítor zriedka zastaví pri otázke: „Máte systém PAM?“ Silnejšie auditné otázky znejú: Máte inventár privilegovaných účtov? Sú privilegované roly schválené? Sú práva časovo obmedzené? Sú núdzové poverenia zabezpečené? Viete preukázať, kto ich použil? Sú príkazy logované? Sú zahrnutí administrátori dodávateľov? Sú prístupové práva preskúmavané? Boli poverenia resetované? Boli výnimky akceptované na základe rizika?

Mapovanie prístupových práv v Zenith Controls vyjadruje podstatu priamo: riadenie prístupových práv prevádza princípy riadenia prístupu, ako sú zásada minimálnych oprávnení, zásada potreby poznať a autorizácia, do prevádzkovej praxe, pričom privilegované účty vyžadujú osobitnú kontrolu a promptné odobratie, keď už nie sú potrebné.

Požiadavky politiky na dôveryhodný prístup „break glass“

Účet „break glass“ nie je zdieľané administrátorské heslo v zapečatenej obálke. V roku 2026 je takýto model príliš slabý pre cloud, fintech, SaaS, zdravotníctvo, spravované služby a regulované digitálne prevádzky.

Obhájiteľný model „break glass“ potrebuje sedem minimálnych pravidiel politiky:

1. Účet musí byť zdokumentovaný.
2. Účet musí byť schválený.
3. Použitie musí byť technicky podľa možnosti jednoznačne priraditeľné konkrétnej osobe.
4. Použitie musí byť obmedzené na skutočné núdzové situácie.
5. Použitie musí byť logované a preskúmané.
6. Poverenia alebo autentifikačné faktory musia byť po použití resetované alebo rotované.
7. Účet musí byť testovaný a zahrnutý do rozsahu auditu.

Knižnica politík Clarysec premieňa tieto princípy na použiteľný jazyk správy a riadenia.

Politika správy používateľských účtov a oprávnení - SME Politika správy používateľských účtov a oprávnení - SME uvádza:

„Núdzový prístup (napr. administrátorské účty „break glass“) musí byť jasne zdokumentovaný, zabezpečený a používaný iba vtedy, keď je to absolútne nevyhnutné.“

Zo sekcie „Ošetrenie rizík a výnimky“, bod politiky 7.3.1.

Tá istá politika pre SME pokračuje:

„Takéto účty musia byť logované, po použití preskúmané a po každej núdzovej udalosti resetované.“

Zo sekcie „Ošetrenie rizík a výnimky“, bod politiky 7.3.2.

Pre každodenné zvýšenie oprávnení politika pre SME vyžaduje aj toto:

„Zvýšené alebo administrátorské oprávnenia vyžadujú dodatočné schválenie generálnym manažérom alebo vedúcim IT a musia byť zdokumentované, časovo obmedzené a podliehať pravidelnému preskúmaniu.“

Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.2.2.

Pre väčšie organizácie ide podnikový súbor politík ďalej. Politika správy používateľských účtov a oprávnení Politika správy používateľských účtov a oprávnení vyžaduje, aby:

„Privilegované relácie boli úplne logované vrátane vydaných príkazov a vykonaných činností. Logy musia pravidelne preskúmavať určení preskúmavatelia.“

Zo sekcie „Požiadavky na implementáciu politiky“, bod politiky 6.4.2.

Tá istá politika vyžaduje, aby dočasné alebo núdzové účty s privilegovaným prístupom postupovali podľa zdokumentovaného postupu „break glass“ v bode 6.2.5, zatiaľ čo bod 7.4 stanovuje požiadavky na tento postup.

Politika riadenia prístupu Politika riadenia prístupu posilňuje uchovávanie na auditné účely:

„Rozhodnutia o schválení musia byť logované a uchovávané na auditné účely minimálne 2 roky.“

Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.3.2.

Politika logovania a monitorovania - SME Politika logovania a monitorovania - SME stanovuje očakávania pre autentifikačné logovanie:

„Autentifikačné logy: úspešné a neúspešné pokusy o prihlásenie, trvanie relácie, použitie MFA“

Zo sekcie „Požiadavky na správu a riadenie“, bod politiky 5.4.2.

Spoločne tieto ustanovenia menia núdzový prístup z hrdinského náhradného postupu na riadenú udalosť. Účet je výnimočný, no správa a riadenie nie.

Prístup Zenith Blueprint k implementácii PAM

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint pristupuje k privilegovanému prístupu ako k praktickému problému implementácie, nie ako k teoretickému vyhláseniu kontroly. Vo fáze Controls in Action, kroku 19, Technological Controls I, uvádza:

„V každom informačnom systéme je privilegovaný prístup moc a s touto mocou prichádza riziko.“

Z fázy Controls in Action, krok 19: Technological Controls I.

Krok 19 vyžaduje, aby organizácie identifikovali privilegované účty naprieč on-premises prostrediami, cloudom, SaaS, vývojom a infraštruktúrou. Zahŕňa doménových administrátorov, používateľov root, administrátorov cloudových tenantov, databázových superpoužívateľov a správcov CI/CD pipeline. Zdôrazňuje tiež minimalizáciu privilegovaného prístupu prostredníctvom riadenia prístupu na základe rolí, just-in-time zvýšenia oprávnení a schvaľovacích pracovných tokov.

Je to dôležité, pretože mnohé závažné incidenty nezačínajú formálnym účtom „break glass“. Začínajú trvalým oprávnením. Cloudový inžinier si ponechá vlastnícke práva „pre každý prípad“. Databázový administrátor si ponechá prístup do produkčného prostredia po presune do iného tímu. Servisný účet CI/CD má široké oprávnenia naprieč prostrediami. Účet poskytovateľa spravovaných služieb je vyňatý z MFA, pretože „potrebujú rýchly prístup“.

Krok 20 Zenith Blueprint rozširuje rovnaké uvažovanie na privilegované obslužné nástroje. Inštruuje organizácie, aby vytvorili alebo aktualizovali inventár privilegovaných obslužných nástrojov, obmedzili ich spúšťanie na autorizovaných administrátorov, overili, že použitie je logované a podporené upozorneniami, a zvážili logovanie skriptov, napríklad logovanie PowerShell prostredníctvom skupinovej politiky. Je to kritické, pretože privilegovaný účet je často iba vstupným bodom. Škoda vzniká vtedy, keď útočník spustí nástroje, ktoré vypínajú kontroly, získavajú poverenia alebo umožňujú laterálny pohyb.

Krok 22 formalizuje životný cyklus riadenia prístupu. Vyžaduje štruktúrované zriaďovanie a odoberanie prístupu, ideálne integrované s HR a podporené pracovnými tokmi žiadostí o prístup, so štvrťročnými zdokumentovanými revíziami prístupových práv. Krok 16 prepája životný cyklus s offboardingom tým, že vyžaduje kontrolný zoznam ukončenia pracovného pomeru, ktorý HR a IT používajú spoločne, vrátane deaktivácie účtov, vrátenia aktív a pripomenutia NDA.

Zenith Blueprint robí z PAM prepojený prevádzkový model: identita, HR, privilegované obslužné nástroje, logovanie, reakcia na incidenty, revízia prístupových práv a auditné dôkazy sa navzájom posilňujú.

Praktický model správy a riadenia „break glass“ na rok 2026

Dobre navrhnutý proces „break glass“ musí fungovať počas zlyhania. Ak závisí od toho istého poskytovateľa identít, ticketovacieho systému a chatovacej služby, ktoré sú počas výpadku nedostupné, je to iba ilúzia kontroly.

Zároveň sa núdzový prístup nesmie stať pohodlným obchádzacím kanálom. Clarysec typicky navrhuje správu a riadenie „break glass“ okolo štyroch vrstiev: prevencia, aktivácia, pozorovanie a obnova.

Pre cloudové prostredia zahrňte administrátorov na úrovni tenanta, cloudové root účty, núdzových administrátorov poskytovateľa identít, privilegované servisné účty, databázových master používateľov, roly Kubernetes cluster-admin, deploy kľúče CI/CD, administrátorov trezora tajomstiev a účty podpory tretích strán.

Pre hybridné prostredia zahrňte doménových administrátorov, administrátorov zálohovania, administrátorov hypervízorov, administrátorov firewallov, administrátorov konzoly EDR a používateľov privilegovaných obslužných nástrojov.

Pre prostredia citlivé na ochranu súkromia zahrňte administrátorov, ktorí môžu pristupovať k databázam obsahujúcim osobné údaje, logom obsahujúcim identifikátory, HR záznamom, údajom biometrického overenia identity, systémom monitorovania podvodov alebo nástrojom zákazníckej podpory.

Cieľový stav sa dá opísať jednoducho a ťažko predstierať: každá núdzová cesta je známa, schválená, zabezpečená, pozorovateľná, vratná a preskúmaná.

60-minútové cvičenie dôkazov pre „break glass“

CISO alebo manažér súladu môže tento týždeň vykonať užitočné cvičenie „break glass“ bez nákupu nového nástroja. Cieľom nie je iba potvrdiť, že účet funguje. Cieľom je preukázať, že kontrola vytvára dôkazy.

Scenár

Predpokladajte, že primárny poskytovateľ identít je degradovaný. Bežné just-in-time zvýšenie oprávnení nie je dostupné. Produkčný databázový klaster potrebuje núdzové konfiguračné zmeny na obnovenie služby. Musí byť aktivovaný cloudový administrátorský účet „break glass“.

Krok 1: Potvrďte, že účet je v inventári privilegovaných účtov

Použite Zenith Blueprint, fázu Controls in Action, krok 19, na overenie, že účet sa nachádza v inventári privilegovaných účtov. Zaznamenajte názov účtu a prostredie, organizačného vlastníka, technického vlastníka, dostupné systémy, dopad na osobné údaje, autentifikačnú metódu, umiestnenie trezora, metódu rotácie a dátum posledného testu.

Ak účet chýba, považujte to za medzeru v kontrolách a pridajte ju do registra rizík.

Krok 2: Skontrolujte súlad s politikou

Namapujte udalosť na požiadavky Politiky správy používateľských účtov a oprávnení pre zdokumentované postupy „break glass“ a logovanie privilegovaných relácií. Ak ste SME, použite body 7.3.1 a 7.3.2 Politiky správy používateľských účtov a oprávnení - SME ako minimálnu základnú úroveň: zdokumentované, zabezpečené, nevyhnutné, logované, preskúmané a resetované.

Namapujte uchovávanie schválení na bod 5.3.2 Politiky riadenia prístupu, ktorý vyžaduje, aby rozhodnutia o schválení boli logované a uchovávané aspoň 2 roky.

Krok 3: Otvorte záznam núdzového prístupu

Vytvorte ticket alebo záznam incidentu pred aktiváciou alebo pri aktivácii. Uveďte:

• Dôvod núdzovej situácie
• Dotknutú službu
• Požadovaný účet
• Žiadateľa
• Schvaľovateľa
• Čas začiatku
• Očakávaný čas ukončenia
• Dopad na zákazníkov alebo regulačný dopad
• Dopad na osobné údaje podľa GDPR
• Príznak sledovania oznamovania podľa NIS2 alebo DORA

Nečakajte do konca, aby ste spätne rekonštruovali príbeh. Auditná hodnota je najsilnejšia vtedy, keď záznam vznikne ešte pred použitím prístupu.

Krok 4: Aktivujte a pozorujte

Aktivujte účet „break glass“. Potvrďte, že sa používa MFA alebo kompenzačná autentifikácia, relácia sa zaznamenáva, príkazy alebo administrátorské činnosti sa logujú, logy sa odosielajú do centralizovaného logovania, synchronizácia času podporuje rekonštrukciu časovej osi a pri použití núdzového účtu sa generuje upozornenie.

Toto je v súlade s Zenith Controls pre 8.15 Logovanie, ktoré opisuje logovanie ako základnú dátovú vrstvu pre monitorovanie a uvádza, že privilegovaní používatelia a spúšťanie privilegovaných obslužných nástrojov musia byť komplexne logované.

Krok 5: Uzavrite, resetujte a preskúmajte

Po núdzovej úlohe deaktivujte účet alebo ho vráťte do zapečateného stavu, rotujte poverenia alebo resetujte autentifikačný faktor, preskúmajte logy relácie, zdokumentujte príkazy a konfiguračné zmeny, potvrďte, že nedošlo k zbytočnému prístupu k údajom, aktualizujte záznam incidentu, zaznamenajte získané ponaučenia a rozhodnite, či sú spustené prahové hodnoty oznamovania podľa NIS2, DORA alebo GDPR.

Ak sa pristupovalo k osobným údajom, zapojte DPO. Ak udalosť spôsobila prerušenie služieb alebo mohla spôsobiť významný dopad, zapojte vlastníka oznamovania podľa NIS2 alebo DORA. Ak účet „break glass“ zlyhal, zdokumentujte to ako zistenie prevádzkovej odolnosti, nie iba ako problém IAM.

Mapovanie PAM a kontrol „break glass“ naprieč rámcami súladu

Najsilnejší model správy a riadenia neduplikuje kontroly pre každý predpis. Buduje jeden reťazec dôkazov, ktorý podporuje viacero povinností.

NIST CSF 2.0 je obzvlášť užitočný pri premene PAM na aktuálny profil a cieľový profil. Jeho profilová metóda začína rozsahom, potom zhromažďuje politiky, priority rizík, registre, požiadavky, praktiky a pracovné roly, až následne vytvára prioritizovaný akčný plán. Pri privilegovanom prístupe to znamená vymedziť profil okolo bezpečnosti identít, cloudovej administrácie, odolnosti voči ransomvéru, kritických finančných systémov alebo dodávateľského prístupu.

Pre finančné subjekty spadajúce pod DORA funguje DORA ako odvetvový režim kybernetickej odolnosti EÚ pre ekvivalentné povinnosti podľa NIS2 v oblasti rizík a incidentov. Neznamená to, že NIS2 je irelevantná. Znamená to, že finančný subjekt má používať DORA ako riadiaci režim pre požiadavky na riziká IKT a incidenty, pričom má udržiavať koordináciu s národnými stratégiami kybernetickej bezpečnosti, príslušnými orgánmi a tímami CSIRT, ak je to uplatniteľné.

Ako audítori testujú dôkazy privilegovaného prístupu

Audítori neposudzujú PAM iba čítaním politiky. Triangulujú politiku, konfiguráciu, logy, tickety, rozhovory a pozorovanú prax.

Auditná metodika Zenith Controls pre práva privilegovaného prístupu odkazuje na auditné postupy ISO/IEC 19011:2018. Audítori preskúmavajú politiky definujúce zvýšené práva, postupy zriaďovania prístupu, monitorovania a odoberania prístupových oprávnení. Skúmajú inventáre používateľských účtov, záznamy o pridelení oprávnení a logy. Dôkazy potvrdzujú prostredníctvom rozhovorov, nástrojov PAM, adresárových služieb a vzoriek logov.

Pri prístupových právach Zenith Controls uvádza, že audítori vzorkujú žiadosti používateľov o prístup, overujú zdokumentované schválenia a potvrdzujú, že IT pridelilo iba schválený prístup. Porovnávajú tiež používateľské roly so skutočnými právami a kontrolujú, či sa uplatňuje zásada minimálnych oprávnení. Pri logovaní audítori skúmajú rozsah logovania, typy udalostí, lehoty uchovávania, ochranné opatrenia a skutočné záznamy logov. Posudzujú, či sú zachytené a preskúmavané neúspešné prihlásenia, prístup k citlivým údajom a konfiguračné zmeny.

Dobrý balík dôkazov pre „break glass“ obsahuje:

• Schválenú žiadosť o núdzový prístup
• Kontext incidentu alebo výpadku
• Identitu používateľa aktivujúceho prístup
• Identitu schvaľovateľa
• Čas začiatku a konca
• Dôkaz o MFA alebo autentifikácii
• Záznam relácie alebo log príkazov
• Systémové logy a upozornenie SIEM
• Vykonané zmeny
• Potvrdenie resetu poverenia
• Preskúmanie po použití
• Posúdenie prístupu k údajom
• Posúdenie regulačnej notifikácie
• Nápravné opatrenia, ak niečo zlyhalo

Ak vaše cvičenie nevie vytvoriť tento balík, kontrola nie je pripravená na audit.

Skryté zlyhanie: privilegovaný prístup tretích strán

Mnohé organizácie riadia administrátorov z radov zamestnancov lepšie než administrátorov dodávateľov. Pre cloud, SaaS, fintech a prostredia spravovaných služieb je to presne opačne, ako by malo byť.

NIS2 Article 21 zahŕňa bezpečnosť dodávateľského reťazca a vzťahy s priamymi dodávateľmi a poskytovateľmi služieb. DORA Articles 28 až 30 idú pri finančných subjektoch ďalej a vyžadujú stratégiu riadenia rizík externých poskytovateľov IKT, registre zmlúv o službách IKT, náležitú starostlivosť, posúdenie rizika koncentrácie, práva na audit, práva na ukončenie, exit stratégie a zmluvné bezpečnostné opatrenia.

Privilegovaný dodávateľský prístup má byť v rozsahu PAM, ak dodávateľ môže spravovať produkciu, podporovať kritické alebo dôležité funkcie, pristupovať k osobným údajom, meniť bezpečnostné konfigurácie, spravovať zálohy, nasadzovať kód alebo prevádzkovať monitorovacie nástroje.

Clarysec typicky očakáva, že kontroly privilegovaného dodávateľského prístupu zahŕňajú:

• Menovitých používateľov dodávateľa, nie zdieľané dodávateľské účty
• Zmluvné bezpečnostné požiadavky na privilegovaný prístup
• MFA a bezpečný vzdialený prístup
• Časovo obmedzené prístupové okná
• Schválenie zákazníkom pre núdzový prístup
• Logovanie relácií alebo rovnocenné auditné stopy
• Okamžité odobratie prístupových oprávnení pri zmene personálu
• Povinnosti spolupráce pri incidente
• Uchovávanie dôkazov zosúladené s auditnými potrebami zákazníka
• Exit plán na odstránenie dodávateľského prístupu

Výstupy dodávateľského reťazca v NIST CSF 2.0 sú s tým silno zosúladené. Vyžadujú roly a zodpovednosti dodávateľov, prioritizáciu dodávateľov podľa kritickosti, požiadavky v zmluvách, náležitú starostlivosť, priebežné monitorovanie, zapojenie dodávateľov do plánovania incidentov a plány rizík po ukončení zmluvy.

Ak je účet poskytovateľa spravovaných služieb vyňatý z vášho interného pracovného toku PAM, nejde o pohodlie. Ide o vysokorizikovú výnimku, ktorá patrí do registra rizík, registra dodávateľov a revízie prístupových práv.

Bežné zistenia k PAM a „break glass“ v roku 2026

V zákazkách Clarysec sú zistenia zriedka prekvapivé. Zvyčajne ide o kombináciu dobrých úmyslov, prevádzkového tlaku a neúplných dôkazov.

Najčastejšie zistenia sú:

• Účty „break glass“ existujú, ale nie sú uvedené v inventári privilegovaných účtov.
• Núdzové účty sú vylúčené z bežných revízií prístupových práv.
• Organizácia nevie preukázať, kto použil núdzový účet.
• Účet nebol po použití resetovaný.
• Privilegované relácie sú logované, ale príkazy nie.
• Logy existujú lokálne, ale nie sú chránené pred privilegovanými používateľmi.
• Cloudové root účty nie sú testované.
• Procesy obnovy MFA nie sú zdokumentované.
• Privilegovaný prístup pre CI/CD pipeline a servisné účty sa ignoruje.
• Prístup podpory tretích strán obchádza interné schvaľovanie.
• Schválenie prístupu existuje v chatových správach, ale neuchováva sa ako auditný dôkaz.
• Offboarding odstráni e-mail a VPN, ale nie administrátorské práva v SaaS.
• DPO nie je zapojený, keď privilegovaný prístup môže sprístupniť osobné údaje.
• Playbooky incidentov neobsahujú rozhodovacie body notifikácie podľa NIS2, DORA alebo GDPR.

Každé zistenie možno riešiť prostredníctvom ošetrenia rizík podľa ISO/IEC 27001:2022. Identifikujte riziko, priraďte vlastníka, vyberte kontroly, aktualizujte vyhlásenie o uplatniteľnosti, implementujte plán ošetrenia rizík a uchovajte zdokumentované dôkazy. To je sila používania ISMS namiesto rozptýlenej množiny bezpečnostných úloh.

Ako vyzerá dobrý stav

Zrelý prevádzkový model PAM a „break glass“ má päť opakujúcich sa rutín.

Po prvé, inventarizujte privilegovaný prístup mesačne alebo priebežne. Zahrňte ľudských administrátorov, servisné účty, núdzové účty, cloudové roly, identity CI/CD, databázových používateľov, privilegované obslužné nástroje a administrátorov tretích strán.

Po druhé, uplatňujte zásadu minimálnych oprávnení prostredníctvom rolí, just-in-time zvýšenia oprávnení a schvaľovaní. Trvalé oprávnenia majú byť zriedkavé, odôvodnené a preskúmavané častejšie než prístup štandardných používateľov.

Po tretie, monitorujte správanie s privilegovaným prístupom. Logujte autentifikáciu, trvanie relácie, použitie MFA, príkazy, konfiguračné zmeny, exporty údajov, neúspešné pokusy, eskaláciu oprávnení a spúšťanie privilegovaných obslužných nástrojov.

Po štvrté, testujte účty „break glass“ pred núdzovou situáciou. Účet „break glass“, ktorý nikdy nebol testovaný, je predpoklad, nie kontrola.

Po piate, reportujte manažmentu. NIS2 aj DORA posúvajú kybernetickú bezpečnosť a riziká IKT na úroveň zodpovednosti riadiaceho orgánu. Predstavenstvo nepotrebuje každý log príkazu, ale potrebuje metriky: počet privilegovaných účtov, oneskorené preskúmania, núdzové aktivácie, administrátorské účty dodávateľov, neúspešné testy, kritické výnimky a stav nápravy.

Tu sa nástroje Clarysec stávajú praktickými. Knižnica politík poskytuje jazyk správy a riadenia. Zenith Blueprint poskytuje postupnosť implementácie. Zenith Controls poskytuje mapovanie naprieč rámcami súladu, vzťahy kontrol, podporné normy a auditnú metodiku.

Ďalšie kroky: premeňte núdzový prístup na odolnosť pripravenú na audit

Ak vaša organizácia netestovala prístup „break glass“ za posledných 90 dní, začnite tam. Nezačínajte workshopom výberu nástroja. Začnite dôkazmi.

1. Vytvorte alebo aktualizujte inventár privilegovaných účtov.
2. Identifikujte každý účet „break glass“ a každú núdzovú administrátorskú cestu.
3. Namapujte každý účet na organizačného vlastníka, vlastníka systému a dopad na údaje.
4. Potvrďte pokrytie politikou pomocou Politiky správy používateľských účtov a oprávnení Politika správy používateľských účtov a oprávnení od Clarysec alebo Politiky správy používateľských účtov a oprávnení - SME Politika správy používateľských účtov a oprávnení - SME.
5. Použite Zenith Blueprint Zenith Blueprint, fázu Controls in Action, kroky 19, 20, 22 a 16, na prepojenie privilegovaného prístupu, privilegovaných obslužných nástrojov, revízií životného cyklu a offboardingu.
6. Použite Zenith Controls Zenith Controls na mapovanie kontrol ISO/IEC 27002:2022 8.2, 5.18 a 8.15 na očakávania dôkazov podľa NIS2, DORA, GDPR a NIST.
7. Vykonajte cvičenie dôkazov pre „break glass“ a zaznamenajte výsledky.
8. Pridajte medzery do plánu ošetrenia rizík a sledujte nápravu až do uzavretia.

Privilegovaný prístup je moc. Prístup „break glass“ je núdzová moc. V roku 2026 sa z ransomvéru, cloudových výpadkov a zlyhaní identít bez strát zotavia tie organizácie, ktoré vedia preukázať, že núdzový prístup bol riadený pred krízou, počas nej aj po nej.

Clarysec vám pomôže vybudovať tento dôkaz — od politiky cez mapovanie kontrol až po dôkazy pripravené na audit. Začnite s Zenith Blueprint, spojte ho s Politikou správy používateľských účtov a oprávnení a Politikou riadenia prístupu, potom použite Zenith Controls na preukázanie, ako váš program PAM podporuje ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 a COBIT 2019.