PAM in računi »break-glass« za ISO 27001 v letu 2026

Ob 02:14 v nedeljo zjutraj vodja obravnave incidenta prejme sporočilo, ki se ga boji vsak CISO: »Avtentikacija v produkciji odpoveduje. Administratorska konzola ni dosegljiva. Preklop podatkovne baze na rezervno okolje je obstal.«

Dežurni inženir za oblak vidi težavo, vendar je ne more odpraviti. Njegova običajna privilegirana vloga je odvisna od istega ponudnika identitet, ki je trenutno degradiran. Vodja operacij zahteva nujno administratorsko poverilnico. Vodja skladnosti vpraša, ali je bil račun »break-glass« kdaj testiran. DPO vpraša, ali bi dostop do produkcijske podatkovne baze lahko razkril osebne podatke. CISO zastavi vprašanje, ki določi, ali bo šlo za nadzorovano obnovitev ali za nočno moro pri presoji:

»Ali lahko dokažemo, kdo je uporabil nujni dostop, zakaj ga je uporabil, kaj je storil in da je bil račun po uporabi ponastavljen?«

Druga organizacija se lahko z enako težavo sooči v tišji sobi. CISO v FinTech podjetju sedi nasproti zunanjim presojevalcem po napačni konfiguraciji podatkovne baze v oblaku. Incident je bil hitro odpravljen, vendar temeljni vzrok ni bil pomirjujoč. Zunanji razvijalec je imel trajne administratorske privilegije. Ko primarni administrator ni bil dosegljiv, je razvijalec uporabil račun »break-glass« na podlagi deljenega gesla, shranjenega v »varni« opombi, dostopni ekipi DevOps.

Presojevalci se niso osredotočili samo na napačno konfiguracijo. Vprašali so, ali je bil dostop časovno omejen, ali je obstajala individualna odgovornost, ali so bili ukazi zabeleženi, ali so bili osebni podatki zaščiteni v skladu z GDPR Article 32, ali so bile izpolnjene obveznosti DORA glede tveganj IKT in ali so bila pričakovanja NIS2 glede kibernetske higiene dokazljiva.

To je dejanska točka pritiska za upravljanje privilegiranih dostopov in računov »break-glass« v letu 2026. PAM ni več nišni projekt varnosti identitet. Je stičišče izsiljevalske programske opreme, kompromitacije oblaka, tveganj pri dobaviteljih, varstva podatkov, operativne odpornosti in revizijskih dokazil.

Privilegirani dostop je področje, kjer napadalci poskušajo zmagati. Dostop »break-glass« je področje, kjer se branilci poskušajo obnoviti. Oba temeljita na isti nevarni zmožnosti: povišanem dostopu, ki lahko obide kontrole, spremeni konfiguracije, bere občutljive podatke, zamenja ključe, onemogoči beleženje, obnovi varnostne kopije, uvede kodo ali uniči dokazila.

Praktično stališče Clarysec je preprosto: nujni dostop je potreben, vendar je neupravljan nujni dostop neupravljano tveganje. Pravi odgovor ni »brez računov break-glass«. Pravi odgovor je upravljan model PAM z evidenco, odobritvijo, časovnimi omejitvami, močno avtentikacijo, beleženjem sej, pregledom po uporabi, ponastavitvijo poverilnic in dokazili, pripravljenimi za presojo.

Zakaj je privilegirani dostop vprašanje skladnosti na ravni poslovodstva

V okoljih z nižjo zrelostjo se privilegirani dostop pogosto obravnava kot naloga administracije IT. Nekdo potrebuje administratorske pravice, odpre se zahtevek, dodeli se vloga in poslovanje se nadaljuje. Tak model ne vzdrži sodobne izsiljevalske programske opreme, izvorno oblačne infrastrukture, odgovornosti po NIS2, operativne odpornosti po DORA ali preverjanja kršitev po GDPR.

Direktiva NIS2 postavlja upravljanje kibernetske varnosti na raven poslovodstva. Article 20 od poslovodnih organov bistvenih in pomembnih subjektov zahteva, da odobrijo ukrepe za obvladovanje tveganj kibernetske varnosti, nadzorujejo njihovo izvajanje in se udeležujejo usposabljanja s področja kibernetske varnosti. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, vključno z analizo tveganj, obravnavanjem incidentov, neprekinjenim poslovanjem, varnostjo dobavne verige, učinkovitostjo kontrol, kibernetsko higieno, kadrovsko varnostjo, nadzorom dostopa, upravljanjem sredstev ter MFA ali neprekinjeno avtentikacijo, kadar je to primerno.

Za ponudnike SaaS, ponudnike upravljanih storitev, ponudnike upravljanih varnostnih storitev, storitve v oblaku, podatkovne centre in druge organizacije digitalne infrastrukture je uporaba NIS2 odvisna od sektorja, velikosti, vloge, čezmejnega vpliva in ustanovitve v EU. Operativna lekcija je neposredna: nadzor dostopa ni več skrit v tehnični prilogi. Je del osnovne kibernetske higiene, ki jo mora vodstvo odobriti, spremljati in popravljati.

Za finančne subjekte Uredba o digitalni operativni odpornosti spremeni izrazoslovje, ne pa tudi osnovnega tveganja. DORA se uporablja od 17. januarja 2025 in vzpostavlja enoten okvir za obvladovanje tveganj IKT, poročanje o večjih incidentih, povezanih z IKT, testiranje digitalne operativne odpornosti in upravljanje tveganj tretjih oseb na področju IKT. Article 5 zahteva ureditev upravljanja in kontrol za tveganja IKT, pri čemer poslovodni organ opredeli, odobri in nadzoruje ureditve za tveganja IKT ter zanje odgovarja. Article 6 zahteva dokumentiran okvir upravljanja tveganj IKT s politikami, postopki, protokoli in orodji za zaščito sredstev IKT. Article 17 zahteva proces upravljanja incidentov, povezanih z IKT, ki zazna, zabeleži, razvrsti in eskalira incidente ter obnovi varno delovanje.

GDPR dodaja vidik zasebnosti in odgovornosti. Article 5(1)(f) zahteva, da se osebni podatki obdelujejo z zagotovljeno celovitostjo in zaupnostjo. Article 5(2) zahteva odgovornost. Article 25 zahteva vgrajeno in privzeto varstvo podatkov. Article 32 zahteva ustrezne tehnične in organizacijske ukrepe za varnost obdelave. Če lahko privilegirani uporabnik izvozi evidence o strankah, dostopa do posebnih vrst osebnih podatkov, onemogoči revizijske dnevnike ali spremeni nastavitve hrambe brez pregleda, organizacija ni zgolj naredila napake v IAM. Morda ne bo mogla dokazati ustrezne varnosti.

ISO/IEC 27001:2022 je hrbtenica sistema upravljanja, ki omogoča obravnavo teh obveznosti v enem integriranem programu. Točka 4.2 zahteva, da organizacija razume zainteresirane strani in njihove zahteve, vključno z zakonskimi, regulativnimi in pogodbenimi obveznostmi. Točka 5.1 zahteva voditeljstvo in zavezanost. Točka 6.1.2 zahteva ocenjevanje tveganj informacijske varnosti. Točka 6.1.3 zahteva obravnavo tveganj. Točka 8 zahteva operativno načrtovanje in nadzor.

Pri privilegiranem dostopu to premakne razpravo z vprašanja »katero orodje PAM naj kupimo?« na vprašanja »katera tveganja obravnavamo, katere kontrole smo izbrali, kdo jih lastniško upravlja, kako se izvajajo in katera dokazila potrjujejo, da delujejo?«

PAM ni ena kontrola, temveč veriga dokazil

Orodje PAM lahko shrani gesla v varovani trezor, posreduje seje, beleži pritiske tipk, menja poverilnice in uveljavlja just-in-time dostop. Te zmožnosti so pomembne. Toda če organizacija ni opredelila privilegiranih vlog, odobrila nujnega dostopa, povezala dostopa s sredstvi, pregledala pravic, zaščitila dnevnikov in usposobila administratorjev, orodje postane delna kontrola s šibko revizijsko zagovornostjo.

Najkoristnejši način upravljanja privilegiranega dostopa je razmišljanje v rezultatih kontrol, ne v imenih orodij.

Zenith Controls: The Cross-Compliance Guide Zenith Controls obravnava kontrolo ISO/IEC 27002:2022 8.2, pravice privilegiranega dostopa, kot težišče PAM. To kontrolo razvršča kot preventivno kontrolo, ki podpira zaupnost, celovitost in razpoložljivost, je usklajena s konceptom kibernetske varnosti Protect, operativno zmožnostjo upravljanja identitet in dostopa ter varnostnim področjem Protection.

Kontrola 8.2 je pomembna, ker se povezuje z okoliškimi kontrolami, ki privilegirani dostop naredijo preverljiv:

Zato se presojevalec redko ustavi pri vprašanju: »Ali imate sistem PAM?« Močnejša revizijska vprašanja so: Ali imate evidenco privilegiranih računov? Ali so privilegirane vloge odobrene? Ali so pravice časovno omejene? Ali so nujne poverilnice zavarovane? Ali lahko dokažete, kdo jih je uporabil? Ali so ukazi zabeleženi? Ali so vključeni administratorji dobaviteljev? Ali se pravice dostopa pregledujejo? Ali so bile poverilnice ponastavljene? Ali so bile izjeme sprejete na podlagi tveganja?

Preslikava pravic dostopa v Zenith Controls to pove neposredno: upravljanje pravic dostopa operacionalizira načela nadzora dostopa, kot so načelo najmanjših privilegijev, potreba po seznanitvi in pooblastitev, privilegirani računi pa zahtevajo posebno skrbnost in hiter preklic, ko niso več potrebni.

Zahteve politike za zaupanja vreden dostop »break-glass«

Račun »break-glass« ni deljeno administratorsko geslo v zapečateni ovojnici. V letu 2026 je tak model prešibek za oblak, fintech, SaaS, zdravstvo, upravljane storitve in regulirane digitalne operacije.

Zagovorljiv model »break-glass« potrebuje sedem minimalnih pravil politike:

1. Račun mora biti dokumentiran.
2. Račun mora biti odobren.
3. Uporaba mora biti, kjer je to tehnično mogoče, enolično pripisljiva.
4. Uporaba mora biti omejena na dejanske nujne primere.
5. Uporaba mora biti zabeležena in pregledana.
6. Poverilnice ali avtentikacijski faktorji morajo biti po uporabi ponastavljeni ali zamenjani.
7. Račun mora biti testiran in vključen v obseg presoje.

Knjižnica politik Clarysec ta načela pretvori v uporabno upravljavsko besedilo.

Politika upravljanja uporabniških računov in privilegijev za SME Politika upravljanja uporabniških računov in privilegijev - SME določa:

»Nujni dostop (npr. administratorski računi »break glass«) mora biti jasno dokumentiran, zavarovan in uporabljen le, kadar je to nujno potrebno.«

Iz razdelka »Obravnava tveganj in izjeme«, klavzula politike 7.3.1.

Ista politika za SME nadaljuje:

»Takšni računi morajo biti zabeleženi, pregledani po uporabi in ponastavljeni po vsakem nujnem dogodku.«

Iz razdelka »Obravnava tveganj in izjeme«, klavzula politike 7.3.2.

Za vsakodnevno povišanje privilegijev politika za SME zahteva tudi:

»Povišani ali administrativni privilegiji zahtevajo dodatno odobritev generalnega direktorja ali vodje IT ter morajo biti dokumentirani, časovno omejeni in predmet periodičnega pregleda.«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.2.2.

Za večje organizacije gre nabor politik za podjetja globlje. Politika upravljanja uporabniških računov in privilegijev Politika upravljanja uporabniških računov in privilegijev zahteva:

»Privilegirane seje morajo biti v celoti zabeležene, vključno z izdanimi ukazi in izvedenimi dejanji. Dnevnike morajo periodično pregledovati imenovani pregledovalci.«

Iz razdelka »Zahteve za izvajanje politike«, klavzula politike 6.4.2.

Ista politika zahteva, da začasni ali nujni računi za privilegirani dostop sledijo dokumentiranemu postopku »break-glass« v klavzuli 6.2.5, medtem ko klavzula 7.4 opredeljuje zahteve za ta postopek.

Politika nadzora dostopa Politika nadzora dostopa krepi hrambo za namene presoje:

»Odločitve o odobritvi morajo biti zabeležene in hranjene za namene revizije najmanj 2 leti.«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.3.2.

Politika beleženja in spremljanja za SME Politika beleženja in spremljanja - SME opredeljuje pričakovanja glede dnevnikov avtentikacije:

»Dnevniki avtentikacije: uspešni in neuspešni poskusi prijave, trajanje seje, uporaba MFA«

Iz razdelka »Zahteve upravljanja«, klavzula politike 5.4.2.

Skupaj te klavzule spremenijo nujni dostop iz junaškega nadomestnega postopka v nadzorovan dogodek. Račun je izjemen, upravljanje pa ne.

Pristop Zenith Blueprint k implementaciji PAM

Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint obravnava privilegirani dostop kot praktičen implementacijski problem, ne kot teoretično izjavo o kontroli. V fazi Controls in Action, korak 19, Technological Controls I, navaja:

»V vsakem informacijskem sistemu je privilegirani dostop moč, z močjo pa pride tveganje.«

Iz faze Controls in Action, korak 19: Technological Controls I.

Korak 19 od organizacij zahteva identifikacijo privilegiranih računov v lokalnih okoljih, oblaku, SaaS, razvojnih in infrastrukturnih okoljih. Vključuje domenske administratorje, uporabnike root, administratorje najemnikov v oblaku, superuporabnike podatkovnih baz in upravljavce CI/CD cevovodov. Poudarja tudi zmanjševanje privilegiranega dostopa z nadzorom dostopa na podlagi vlog, just-in-time povišanjem pravic in odobritvenimi delovnimi tokovi.

To je pomembno, ker se številni resni incidenti ne začnejo s formalnim računom »break-glass«. Začnejo se s trajnimi privilegiji. Inženir za oblak obdrži pravice lastnika »za vsak primer«. Administrator podatkovne baze ohrani dostop do produkcije po premestitvi v drugo ekipo. Storitveni račun CI/CD ima široka dovoljenja v več okoljih. Račun ponudnika upravljanih storitev je izvzet iz MFA, ker »potrebujejo hiter dostop«.

Korak 20 v Zenith Blueprint isto razmišljanje razširi na privilegirane pomožne programe. Organizacijam naroča, naj ustvarijo ali posodobijo evidenco privilegiranih pomožnih programov, omejijo izvajanje na pooblaščene administratorje, preverijo, da je uporaba zabeležena in podprta z opozorili, ter razmislijo o beleženju skript, na primer beleženju PowerShell prek skupinske politike. To je ključno, ker je privilegirani račun pogosto le vstopna točka. Škoda nastane, ko napadalec zažene orodja, ki onemogočijo kontrole, izpišejo poverilnice ali omogočijo lateralno gibanje.

Korak 22 formalizira življenjski cikel nadzora dostopa. Zahteva strukturirano dodeljevanje in odvzem dostopa, idealno integrirano s kadrovsko službo in podprto z delovnimi tokovi za zahteve za dostop, s četrtletnimi dokumentiranimi pregledi pravic dostopa. Korak 16 poveže življenjski cikel s postopkom izstopa, saj zahteva kontrolni seznam ob prenehanju zaposlitve, ki ga skupaj uporabljata HR in IT, vključno z onemogočanjem računov, vračilom sredstev in opomniki glede NDA.

Zenith Blueprint iz PAM oblikuje povezan operativni model: identiteta, HR, privilegirani pomožni programi, beleženje, odziv na incidente, pregledi pravic dostopa in dokazila za presojo se medsebojno krepijo.

Praktičen model upravljanja »break-glass« za leto 2026

Dobro zasnovan proces »break-glass« mora delovati med odpovedjo. Če je odvisen od istega ponudnika identitet, sistema za upravljanje zahtevkov in storitve klepeta, ki med izpadom niso na voljo, je to le predstava.

Hkrati nujni dostop ne sme postati obvodni kanal zaradi udobja. Clarysec upravljanje »break-glass« običajno zasnuje okoli štirih plasti: preprečevanje, aktivacija, opazovanje in obnovitev.

Za okolja v oblaku vključite administratorje na ravni najemnika, račune root v oblaku, nujne administratorje ponudnika identitet, privilegirane storitvene račune, glavne uporabnike podatkovnih baz, vloge Kubernetes cluster-admin, ključe za uvajanje CI/CD, administratorje trezorjev skrivnosti in račune podpore tretjih oseb.

Za hibridna okolja vključite domenske administratorje, administratorje varnostnega kopiranja, administratorje hipervizorjev, administratorje požarnih zidov, administratorje konzol EDR in uporabnike privilegiranih pomožnih programov.

Za okolja, občutljiva z vidika zasebnosti, vključite administratorje, ki lahko dostopajo do podatkovnih baz z osebnimi podatki, dnevnikov z identifikatorji, kadrovskih evidenc, podatkov za biometrično preverjanje identitete, sistemov za spremljanje goljufij ali orodij za podporo strankam.

Ciljno stanje je preprosto opisati in težko ponarediti: vsaka nujna pot je znana, odobrena, zavarovana, opazljiva, reverzibilna in pregledana.

60-minutna vaja dokazil za »break-glass«

CISO ali vodja skladnosti lahko že ta teden izvede koristno vajo »break-glass« brez nakupa novega orodja. Cilj ni le potrditi, da račun deluje. Cilj je dokazati, da kontrola ustvarja dokazila.

Scenarij

Predpostavite, da je primarni ponudnik identitet degradiran. Običajno just-in-time povišanje pravic ni na voljo. Za obnovitev storitve so potrebne nujne konfiguracijske spremembe v produkcijskem gručišču podatkovnih baz. Aktivirati je treba administratorski račun »break-glass« v oblaku.

Korak 1: Potrdite, da je račun v evidenci privilegiranih računov

Uporabite Zenith Blueprint, faza Controls in Action, korak 19, da preverite, ali je račun naveden v evidenci privilegiranih računov. Zabeležite ime računa in okolje, poslovnega lastnika, tehničnega lastnika, dosegljive sisteme, vpliv na osebne podatke, metodo avtentikacije, lokacijo v trezorju poverilnic, metodo menjave poverilnic in datum zadnjega testa.

Če račun manjka, to obravnavajte kot vrzel v kontrolah in jo dodajte v register tveganj.

Korak 2: Preverite usklajenost s politiko

Dogodek preslikajte na zahteve Politike upravljanja uporabniških računov in privilegijev za dokumentirane postopke »break-glass« in beleženje privilegiranih sej. Če ste SME, uporabite klavzuli 7.3.1 in 7.3.2 Politike upravljanja uporabniških računov in privilegijev za SME kot minimalno izhodišče: dokumentirano, zavarovano, potrebno, zabeleženo, pregledano in ponastavljeno.

Hrambo odobritev preslikajte na klavzulo 5.3.2 Politike nadzora dostopa, ki zahteva, da se odločitve o odobritvi zabeležijo in hranijo najmanj 2 leti.

Korak 3: Odprite zapis o nujnem dostopu

Pred aktivacijo ali ob njej ustvarite zahtevek ali zapis incidenta. Vključite:

• razlog za nujni primer
• prizadeto storitev
• zahtevani račun
• vlagatelja zahteve
• odobritelja
• čas začetka
• pričakovani čas konca
• vpliv na stranke ali regulatorni vpliv
• vpliv na osebne podatke po GDPR
• oznako za spremljanje poročanja po NIS2 ali DORA

Ne čakajte do konca, da bi naknadno rekonstruirali zgodbo. Revizijska vrednost je najmočnejša, kadar se zapis začne pred uporabo dostopa.

Korak 4: Aktivirajte in opazujte

Aktivirajte račun »break-glass«. Potrdite, da se uporablja MFA ali kompenzacijska avtentikacija, da je seja posneta, da so ukazi ali administrativna dejanja zabeleženi, da se dnevniki posredujejo v centralizirano beleženje, da sinhronizacija časa podpira rekonstrukcijo časovnice in da se ob uporabi nujnega računa ustvari opozorilo.

To je skladno z Zenith Controls za 8.15 Beleženje, ki opisuje beleženje kot temeljno podatkovno plast za spremljanje in ugotavlja, da morajo biti privilegirani uporabniki in izvajanje privilegiranih pomožnih programov celovito zabeleženi.

Korak 5: Zaprite, ponastavite in preglejte

Po nujni nalogi onemogočite račun ali ga vrnite v zapečateno stanje, zamenjajte poverilnice ali ponastavite avtentikacijski faktor, preglejte dnevnike sej, dokumentirajte ukaze in konfiguracijske spremembe, potrdite, da ni prišlo do nepotrebnega dostopa do podatkov, posodobite zapis incidenta, zabeležite naučene lekcije in odločite, ali so sproženi pragovi za obveščanje po NIS2, DORA ali GDPR.

Če je bil dostopan osebni podatek, vključite DPO. Če je dogodek povzročil motnjo storitve ali bi lahko povzročil pomemben vpliv, vključite lastnika poročanja po NIS2 ali DORA. Če račun »break-glass« ni deloval, to dokumentirajte kot ugotovitev operativne odpornosti, ne zgolj kot vprašanje IAM.

Medregulativna preslikava kontrol PAM in »break-glass«

Najmočnejši model upravljanja ne podvaja kontrol za vsak predpis. Zgradi eno verigo dokazil, ki podpira več obveznosti.

NIST CSF 2.0 je posebej uporaben pri prevajanju PAM v trenutni profil in ciljni profil. Njegova metoda profilov se začne z obsegom, nato zbere politike, prioritete tveganj, registre, zahteve, prakse in delovne vloge ter nato pripravi prednostni akcijski načrt. Za privilegirani dostop to pomeni določitev obsega profila okoli varnosti identitet, administracije oblaka, odpornosti proti izsiljevalski programski opremi, kritičnih finančnih sistemov ali dostopa dobaviteljev.

Za finančne subjekte, ki jih zajema DORA, DORA deluje kot sektorsko specifičen režim kibernetske odpornosti EU za enakovredne obveznosti NIS2 glede tveganj in incidentov. To ne pomeni, da NIS2 ni relevanten. Pomeni, da mora finančni subjekt uporabljati DORA kot vodilni režim za zahteve glede tveganj IKT in incidentov, hkrati pa ohranjati usklajevanje z nacionalnimi strategijami kibernetske varnosti, pristojnimi organi in CSIRT, kjer je to primerno.

Kako presojevalci preverjajo dokazila o privilegiranem dostopu

Presojevalci PAM ne ocenjujejo le z branjem politike. Povežejo politiko, konfiguracijo, dnevnike, zahtevke, intervjuje in opazovano prakso.

Revizijska metodologija Zenith Controls za pravice privilegiranega dostopa se sklicuje na revizijske prakse ISO/IEC 19011:2018. Presojevalci pregledajo politike, ki opredeljujejo povišane pravice, dodeljevanje dostopa, spremljanje in postopke preklica. Preučijo evidence uporabniških računov, zapise o dodelitvi privilegijev in dnevnike. Dokazila potrdijo z intervjuji, orodji PAM, imeniškimi storitvami in vzorci dnevnikov.

Za pravice dostopa Zenith Controls navaja, da presojevalci vzorčijo zahteve za uporabniški dostop, preverijo dokumentirane odobritve in potrdijo, da je IT dodelil samo odobren dostop. Primerjajo tudi uporabniške vloge z dejanskimi pravicami in preverjajo, ali se uveljavlja načelo najmanjših privilegijev. Pri beleženju presojevalci pregledajo obseg beleženja, vrste dogodkov, roke hrambe, zaščite in dejanske vnose v dnevnike. Ocenijo, ali so neuspešne prijave, dostop do občutljivih podatkov in konfiguracijske spremembe zajeti in pregledani.

Dober paket dokazil za »break-glass« vključuje:

• odobreno zahtevo za nujni dostop
• kontekst incidenta ali izpada
• identiteto uporabnika, ki aktivira dostop
• identiteto odobritelja
• čas začetka in konca
• dokazilo MFA ali avtentikacije
• snemanje seje ali dnevnik ukazov
• sistemske dnevnike in opozorilo SIEM
• izvedene spremembe
• potrditev ponastavitve poverilnic
• pregled po uporabi
• oceno dostopa do podatkov
• oceno regulatornega obveščanja
• korektivne ukrepe, če je karkoli odpovedalo

Če vaša vaja ne more ustvariti tega paketa, kontrola ni pripravljena na presojo.

Skrita odpoved: privilegirani dostop tretjih oseb

Številne organizacije bolje upravljajo administratorje zaposlenih kot administratorje dobaviteljev. Za okolja v oblaku, SaaS, fintech in upravljane storitve je to napačen pristop.

NIS2 Article 21 vključuje varnost dobavne verige in odnose z neposrednimi dobavitelji ter ponudniki storitev. DORA Articles 28 do 30 gredo pri finančnih subjektih dlje in zahtevajo strategijo tveganj tretjih oseb na področju IKT, registre pogodb o storitvah IKT, skrbni pregled, oceno tveganja koncentracije, pravice do revizije, pravice do odpovedi, izstopne strategije in pogodbene varnostne ukrepe.

Privilegirani dostop dobaviteljev mora biti v obsegu PAM, če dobavitelj lahko administrira produkcijo, podpira kritične ali pomembne funkcije, dostopa do osebnih podatkov, spreminja varnostne konfiguracije, upravlja varnostne kopije, uvaja kodo ali upravlja orodja za spremljanje.

Clarysec običajno pričakuje, da kontrole privilegiranega dostopa dobaviteljev vključujejo:

• imenovane uporabnike dobavitelja, ne skupnih računov dobavitelja
• pogodbene varnostne zahteve za privilegirani dostop
• MFA in varen oddaljeni dostop
• časovno omejena okna dostopa
• odobritev stranke za nujni dostop
• beleženje sej ali enakovredne revizijske sledi
• takojšen preklic ob spremembah osebja
• obveznosti sodelovanja pri incidentih
• hrambo dokazil, usklajeno z revizijskimi potrebami stranke
• izstopni načrt za odstranitev dostopa dobavitelja

Rezultati NIST CSF 2.0 za dobavno verigo se s tem močno ujemajo. Zahtevajo vloge in odgovornosti dobaviteljev, prednostno razvrščanje dobaviteljev po kritičnosti, zahteve v pogodbah, skrbni pregled, stalno spremljanje, vključenost dobaviteljev v načrtovanje incidentov in načrte tveganj po pogodbi.

Če je račun ponudnika upravljanih storitev izvzet iz vašega notranjega delovnega toka PAM, to ni priročnost. Je izjema z visokim tveganjem, ki spada v register tveganj, evidenco dobaviteljev in pregled pravic dostopa.

Pogoste ugotovitve PAM in »break-glass« v letu 2026

Pri sodelovanjih Clarysec ugotovitve redko presenetijo. Običajno so kombinacija dobrih namenov, operativnega pritiska in nepopolnih dokazil.

Najpogostejše ugotovitve so:

• Računi »break-glass« obstajajo, vendar niso navedeni v evidenci privilegiranih računov.
• Nujni računi so izključeni iz običajnih pregledov pravic dostopa.
• Organizacija ne more dokazati, kdo je uporabil nujni račun.
• Račun po uporabi ni bil ponastavljen.
• Privilegirane seje so zabeležene, ukazi pa ne.
• Dnevniki obstajajo lokalno, vendar niso zaščiteni pred privilegiranimi uporabniki.
• Računi root v oblaku niso testirani.
• Procesi obnove MFA niso dokumentirani.
• Privilegirani dostop za CI/CD cevovode in storitvene račune je prezrt.
• Dostop podpore tretjih oseb obide notranjo odobritev.
• Odobritev dostopa obstaja v sporočilih klepeta, vendar ni hranjena kot revizijsko dokazilo.
• Postopek izstopa odstrani e-pošto in VPN, ne pa administratorskih pravic v SaaS.
• DPO ni vključen, kadar privilegirani dostop lahko razkrije osebne podatke.
• Odzivni priročniki za incidente ne vključujejo odločitvenih točk za obveščanje po NIS2, DORA ali GDPR.

Vsako ugotovitev je mogoče obravnavati prek obravnave tveganj po ISO/IEC 27001:2022. Identificirajte tveganje, dodelite lastnika, izberite kontrole, posodobite izjavo o uporabnosti, izvedite načrt obravnave tveganj in hranite dokumentirana dokazila. To je moč uporabe ISMS namesto razpršenega nabora varnostnih nalog.

Kako je videti dobro stanje

Zrel operativni model PAM in »break-glass« ima pet ponavljajočih se rutin.

Prvič, mesečno ali neprekinjeno popisujte privilegirani dostop. Vključite človeške administratorje, storitvene račune, nujne račune, vloge v oblaku, identitete CI/CD, uporabnike podatkovnih baz, privilegirane pomožne programe in administratorje tretjih oseb.

Drugič, uveljavljajte načelo najmanjših privilegijev z vlogami, just-in-time povišanjem pravic in odobritvami. Trajni privilegiji morajo biti redki, utemeljeni in pregledani pogosteje kot standardni uporabniški dostop.

Tretjič, spremljajte vedenje privilegiranih uporabnikov. Beležite avtentikacijo, trajanje seje, uporabo MFA, ukaze, konfiguracijske spremembe, izvoze podatkov, neuspešne poskuse, povišanje privilegijev in izvajanje privilegiranih pomožnih programov.

Četrtič, testirajte račune »break-glass« pred nujnim primerom. Račun »break-glass«, ki ni bil nikoli testiran, je predpostavka, ne kontrola.

Petič, poročajte vodstvu. NIS2 in DORA kibernetsko varnost in tveganja IKT dvigujeta na raven odgovornosti poslovodnega organa. Upravni odbor ne potrebuje vsakega dnevnika ukazov, potrebuje pa metrike: število privilegiranih računov, zapadle preglede, nujne aktivacije, administratorske račune dobaviteljev, neuspešne teste, kritične izjeme in status odprave pomanjkljivosti.

Tukaj postane nabor orodij Clarysec praktičen. Knjižnica politik zagotavlja upravljavsko besedilo. Zenith Blueprint zagotavlja zaporedje implementacije. Zenith Controls zagotavlja medregulativno preslikavo, povezave kontrol, podporne standarde in revizijsko metodologijo.

Naslednji koraki: pretvorite nujni dostop v odpornost, pripravljeno za presojo

Če vaša organizacija v zadnjih 90 dneh ni testirala dostopa »break-glass«, začnite tam. Ne začnite z delavnico za izbiro orodja. Začnite z dokazili.

1. Vzpostavite ali posodobite evidenco privilegiranih računov.
2. Identificirajte vsak račun »break-glass« in vsako pot nujne administracije.
3. Vsak račun preslikajte na poslovnega lastnika, lastnika sistema in vpliv na podatke.
4. Potrdite pokritost s politiko z uporabo Clarysecove Politike upravljanja uporabniških računov in privilegijev Politika upravljanja uporabniških računov in privilegijev ali Politike upravljanja uporabniških računov in privilegijev za SME Politika upravljanja uporabniških računov in privilegijev - SME.
5. Uporabite Zenith Blueprint Zenith Blueprint, faza Controls in Action, koraki 19, 20, 22 in 16, da povežete privilegirani dostop, privilegirane pomožne programe, preglede življenjskega cikla in postopek izstopa.
6. Uporabite Zenith Controls Zenith Controls za preslikavo kontrol ISO/IEC 27002:2022 8.2, 5.18 in 8.15 na pričakovanja glede dokazil po NIS2, DORA, GDPR in NIST.
7. Izvedite vajo dokazil za »break-glass« in zabeležite rezultate.
8. Dodajte vrzeli v načrt obravnave tveganj in spremljajte odpravo do zaključka.

Privilegirani dostop je moč. Dostop »break-glass« je nujna moč. V letu 2026 se bodo od izsiljevalske programske opreme, izpadov oblaka in odpovedi identitet čisto obnovile tiste organizacije, ki lahko dokažejo, da je bil nujni dostop nadzorovan pred krizo, med njo in po njej.

Clarysec vam lahko pomaga zgraditi ta dokaz, od politike do preslikave kontrol in dokazil, pripravljenih za presojo. Začnite z Zenith Blueprint, povežite ga s Politiko upravljanja uporabniških računov in privilegijev ter Politiko nadzora dostopa, nato uporabite Zenith Controls, da pokažete, kako vaš program PAM podpira ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 in COBIT 2019.