PAM i računi za izvanredni pristup za ISO 27001 u 2026.
U 02:14 u nedjelju ujutro voditelj upravljanja incidentom prima poruku koje se svaki CISO pribojava: „Autentifikacija u produkciji ne radi. Administratorska konzola nije dostupna. Prebacivanje baze podataka na pričuvnu lokaciju je zapelo.”
Dežurni inženjer za oblak vidi problem, ali ga ne može otkloniti. Njegova redovna privilegirana uloga ovisi o istom pružatelju identiteta koji je sada degradiran. Voditelj operacija traži administratorsku vjerodajnicu za izvanredne situacije. Voditelj usklađenosti pita je li račun za izvanredni pristup ikada testiran. DPO pita može li pristup produkcijskoj bazi podataka izložiti osobne podatke. CISO postavlja pitanje koje određuje hoće li ovo biti kontrolirani oporavak ili revizijska noćna mora:
„Možemo li dokazati tko je koristio izvanredni pristup, zašto, što je učinio i da je račun nakon toga resetiran?”
Druga organizacija može se suočiti s istim problemom u mirnijoj prostoriji. CISO jedne fintech organizacije sjedi pred vanjskim revizorima nakon pogrešne konfiguracije baze podataka u oblaku. Incident je brzo riješen, ali temeljni uzrok nije bio ohrabrujući. Vanjski razvojni inženjer imao je trajne administratorske privilegije. Kada primarni administrator nije bio dostupan, razvojni inženjer upotrijebio je račun za izvanredni pristup temeljen na dijeljenoj lozinki pohranjenoj u „sigurnoj” bilješci dostupnoj DevOps timu.
Revizori se nisu usredotočili samo na pogrešnu konfiguraciju. Pitali su je li pristup bio vremenski ograničen, postoji li individualna odgovornost, jesu li naredbe evidentirane u dnevničkim zapisima, jesu li osobni podaci zaštićeni prema GDPR Article 32, jesu li ispunjene obveze upravljanja IKT rizicima prema DORA te mogu li se dokazati očekivanja NIS2 u pogledu kibernetičke higijene.
To je stvarna točka pritiska za upravljanje privilegiranim pristupom i račune za izvanredni pristup u 2026. PAM više nije uski projekt sigurnosti identiteta. To je mjesto na kojem se susreću ransomware, kompromitacija oblaka, rizik dobavljača, zaštita podataka, operativna otpornost i revizijski dokazi.
Pristup s povišenim ovlastima mjesto je na kojem napadači pokušavaju pobijediti. Izvanredni pristup mjesto je na kojem se branitelji pokušavaju oporaviti. Oba se oslanjaju na istu opasnu sposobnost: povišena prava pristupa koja mogu zaobići kontrole, mijenjati konfiguracije, čitati osjetljive podatke, rotirati ključeve, onemogućiti dnevničko bilježenje, obnoviti sigurnosne kopije, implementirati kod ili uništiti dokaze.
Clarysecovo praktično stajalište je jednostavno: izvanredni pristup je nužan, ali neupravljani izvanredni pristup je neupravljani rizik. Ispravan odgovor nije „bez računa za izvanredni pristup”. Ispravan odgovor je upravljani model upravljanja privilegiranim pristupom koji obuhvaća popis imovine, odobrenje, vremenska ograničenja, snažnu autentifikaciju, zapisivanje sesija, pregled nakon uporabe, resetiranje vjerodajnica i revizijske dokaze.
Zašto je privilegirani pristup pitanje usklađenosti na razini upravnog odbora
U okruženjima niže zrelosti pristup s povišenim ovlastima često se tretira kao zadatak IT administracije. Nekome trebaju administratorska prava, otvara se zahtjev, dodjeljuje se uloga i poslovanje se nastavlja. Taj model ne izdržava suvremeni ransomware, infrastrukturu u oblaku, odgovornost prema NIS2, operativnu otpornost prema DORA ni procjenu povrede prema GDPR-u.
Direktiva NIS2 uvodi upravljanje kibernetičkom sigurnošću u upravu. Article 20 zahtijeva da upravljačka tijela bitnih i važnih subjekata odobravaju mjere upravljanja rizicima kibernetičke sigurnosti, nadziru njihovu provedbu i pohađaju osposobljavanje iz kibernetičke sigurnosti. Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere, uključujući analizu rizika, postupanje s incidentima, kontinuitet poslovanja, sigurnost opskrbnog lanca, djelotvornost kontrola, kibernetičku higijenu, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom te MFA ili kontinuiranu autentikaciju gdje je primjereno.
Za pružatelje SaaS usluga, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, usluge u oblaku, podatkovne centre i druge organizacije digitalne infrastrukture primjenjivost NIS2 ovisi o sektoru, veličini, ulozi, prekograničnom učinku i poslovnom nastanu u EU. Operativna pouka je izravna: kontrola pristupa više nije skrivena u tehničkom prilogu. Ona je dio osnovne razine kibernetičke higijene koju uprava mora odobriti, pratiti i ispravljati.
Za financijske subjekte Akt o digitalnoj operativnoj otpornosti mijenja terminologiju, ali ne i temeljni rizik. DORA se primjenjuje od 17. siječnja 2025. i uspostavlja jedinstveni okvir za upravljanje IKT rizicima, prijavljivanje većih incidenata povezanih s IKT-om, testiranje digitalne operativne otpornosti i upravljanje rizicima trećih strana u području IKT-a. Article 5 zahtijeva upravljačke i kontrolne aranžmane za IKT rizik, pri čemu upravljačko tijelo definira, odobrava, nadzire i odgovorno je za aranžmane IKT rizika. Article 6 zahtijeva dokumentirani okvir upravljanja IKT rizicima s politikama, postupcima, protokolima i alatima za zaštitu IKT imovine. Article 17 zahtijeva proces upravljanja incidentima povezanima s IKT-om koji otkriva, bilježi, klasificira, eskalira i omogućuje siguran oporavak poslovanja.
GDPR dodaje perspektivu privatnosti i odgovornosti. Article 5(1)(f) zahtijeva obradu osobnih podataka uz cjelovitost i povjerljivost. Article 5(2) zahtijeva odgovornost. Article 25 zahtijeva ugrađenu i zadanu zaštitu podataka. Article 32 zahtijeva odgovarajuće tehničke i organizacijske mjere za sigurnost obrade. Ako privilegirani korisnik može izvesti evidencije klijenata, pristupiti posebnim kategorijama podataka, onemogućiti revizijske zapise ili promijeniti postavke zadržavanja bez pregleda, organizacija nije samo napravila IAM pogrešku. Možda neće moći dokazati odgovarajuću sigurnost.
ISO/IEC 27001:2022 je okosnica sustava upravljanja koja omogućuje da se te obveze obrađuju kroz jedan integrirani program. Točka 4.2 zahtijeva da organizacija razumije zainteresirane strane i njihove zahtjeve, uključujući pravne, regulatorne i ugovorne obveze. Točka 5.1 zahtijeva vodstvo i predanost. Točka 6.1.2 zahtijeva procjenu rizika informacijske sigurnosti. Točka 6.1.3 zahtijeva obradu rizika. Točka 8 zahtijeva operativno planiranje i kontrolu.
Za pristup s povišenim ovlastima to mijenja razgovor iz „koji PAM alat trebamo kupiti?” u „koje rizike obrađujemo, koje su kontrole odabrane, tko je njihov vlasnik, kako se provode i koji dokazi potvrđuju da djeluju?”
PAM nije jedna kontrola, nego lanac dokaza
PAM alat može pohranjivati lozinke u trezor, posredovati sesije, snimati pritiske tipki, rotirati vjerodajnice i provoditi JIT pristup. Te su mogućnosti važne. No ako organizacija nije definirala privilegirane uloge, odobrila izvanredni pristup, mapirala pristup na imovinu, pregledala prava, zaštitila dnevničke zapise i osposobila administratore, alat postaje djelomična kontrola sa slabom revizijskom dokazivošću.
Najkorisniji način upravljanja privilegiranim pristupom jest razmišljati o ishodima kontrola, a ne o nazivima alata.
Zenith Controls: Vodič za međuregulatornu usklađenost Zenith Controls tretira kontrolu ISO/IEC 27002:2022 8.2, prava privilegiranog pristupa, kao središte PAM-a. Klasificira tu kontrolu kao preventivnu, uz potporu povjerljivosti, cjelovitosti i dostupnosti, usklađenu s konceptom kibernetičke sigurnosti Protect, operativnom sposobnošću upravljanja identitetom i pristupom te sigurnosnom domenom Protection.
Kontrola 8.2 snažna je jer se povezuje s okolnim kontrolama koje privilegirani pristup čine provjerljivim u reviziji:
| Kontrola ISO/IEC 27002:2022 | Zašto je važna za PAM i račune za izvanredni pristup |
|---|---|
| 5.16 Upravljanje identitetom | Svaki privilegirani korisnik mora imati provjeren, jedinstven identitet prije nego što se povišeni pristup može kontrolirati. |
| 5.18 Prava pristupa | Dodjela, pregled, izmjena i opoziv moraju obuhvatiti privilegirana i izvanredna prava. |
| 8.3 Ograničenje pristupa informacijama | Privilegirani računi ne smiju postati nekontrolirani zaobilazni put do osjetljivih podataka. |
| 8.5 Sigurna autentifikacija | Administratorski računi i računi za izvanredni pristup zahtijevaju snažniju autentifikaciju, kao što su MFA ili ekvivalentno jamstvo. |
| 6.7 Rad na daljinu | Udaljena privilegirana administracija zahtijeva sigurne kanale, nadzor i ograničene uvjete. |
| 8.15 Dnevničko bilježenje | Privilegirane radnje moraju se evidentirati, zaštititi i pregledavati. |
| 8.16 Aktivnosti nadzora | Dnevnički zapisi moraju podržavati otkrivanje, analizu anomalija i odgovor. |
| 8.18 Uporaba privilegiranih pomoćnih programa | Administratorski alati koji mogu zaobići kontrole moraju biti popisani, ograničeni i evidentirani u dnevničkim zapisima. |
Zato se revizor rijetko zaustavlja na pitanju: „Imate li PAM sustav?” Snažnija revizijska pitanja glase: Imate li popis privilegiranih računa? Jesu li privilegirane uloge odobrene? Jesu li prava vremenski ograničena? Jesu li vjerodajnice za izvanredne situacije zaštićene? Možete li dokazati tko ih je koristio? Jesu li naredbe evidentirane? Jesu li uključeni administratori dobavljača? Pregledavaju li se prava pristupa? Jesu li vjerodajnice resetirane? Jesu li iznimke prihvaćene na temelju rizika?
Mapiranje prava pristupa u Zenith Controls to izravno potvrđuje: upravljanje pravima pristupa provodi načela kontrole pristupa kao što su načelo najmanjih privilegija, načelo nužnog poznavanja i autorizacija, dok privilegirani računi zahtijevaju posebnu pozornost i brz opoziv kada više nisu potrebni.
Zahtjevi politike za pouzdan izvanredni pristup
Račun za izvanredni pristup nije dijeljena administratorska lozinka u zapečaćenoj omotnici. U 2026. taj je model preslab za oblak, fintech, SaaS, zdravstvo, upravljane usluge i regulirane digitalne operacije.
Dokaziv model izvanrednog pristupa treba sedam minimalnih pravila politike:
- Račun mora biti dokumentiran.
- Račun mora biti odobren.
- Uporaba mora biti jedinstveno pripisiva gdje je to tehnički moguće.
- Uporaba mora biti ograničena na stvarne izvanredne situacije.
- Uporaba mora biti evidentirana u dnevničkim zapisima i pregledana.
- Vjerodajnice ili autentifikacijski faktori moraju se resetirati ili rotirati nakon uporabe.
- Račun mora biti testiran i uključen u opseg revizije.
Clarysecova biblioteka politika pretvara ta načela u primjenjiv jezik upravljanja.
Politika upravljanja korisničkim računima i privilegijama - SME Politika upravljanja korisničkim računima i privilegijama - SME navodi:
„Izvanredni pristup (npr. administratorski računi za izvanredni pristup) mora biti jasno dokumentiran, zaštićen i koristiti se samo kada je apsolutno nužno.”
Iz odjeljka „Obrada rizika i iznimke”, točka politike 7.3.1.
Ista SME politika nastavlja:
„Takvi računi moraju biti evidentirani u dnevničkim zapisima, pregledani nakon uporabe i resetirani nakon svakog izvanrednog događaja.”
Iz odjeljka „Obrada rizika i iznimke”, točka politike 7.3.2.
Za svakodnevno povećanje privilegija SME politika također zahtijeva:
„Povišene ili administratorske privilegije zahtijevaju dodatno odobrenje glavnog direktora ili voditelja IT-a te moraju biti dokumentirane, vremenski ograničene i podložne periodičnom pregledu.”
Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.2.2.
Za veće organizacije skup korporativnih politika ide dublje. Politika upravljanja korisničkim računima i privilegijama Politika upravljanja korisničkim računima i privilegijama zahtijeva:
„Privilegirane sesije moraju se u cijelosti evidentirati u dnevničkim zapisima, uključujući izdane naredbe i provedene radnje. Dnevničke zapise moraju periodično pregledavati imenovani pregledavatelji.”
Iz odjeljka „Zahtjevi za provedbu politike”, točka politike 6.4.2.
Ista politika zahtijeva da privremeni računi ili računi za izvanredni privilegirani pristup slijede dokumentirani postupak izvanrednog pristupa u točki 6.2.5, dok točka 7.4 opisuje zahtjeve za taj postupak.
Politika kontrole pristupa Politika kontrole pristupa pojačava zadržavanje za potrebe revizije:
„Odluke o odobrenju moraju se evidentirati u dnevničkim zapisima i čuvati za potrebe revizije najmanje 2 godine.”
Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.3.2.
Politika dnevničkog bilježenja i nadzora - SME Politika dnevničkog bilježenja i nadzora - SME utvrđuje očekivanja za autentikacijske zapise:
„Autentikacijski zapisi: uspješni i neuspješni pokušaji prijave, trajanje sesije, uporaba MFA”
Iz odjeljka „Zahtjevi upravljanja”, točka politike 5.4.2.
Zajedno, te točke pretvaraju izvanredni pristup iz herojskog zaobilaznog rješenja u kontrolirani događaj. Račun je izniman, ali upravljanje nije.
Pristup Zenith Blueprinta provedbi PAM-a
Zenith Blueprint: revizorov plan puta u 30 koraka Zenith Blueprint tretira pristup s povišenim ovlastima kao praktičan provedbeni problem, a ne kao teorijsku izjavu kontrole. U fazi Controls in Action, korak 19, Tehnološke kontrole I, navodi:
„U svakom informacijskom sustavu pristup s povišenim ovlastima je moć, a s tom moći dolazi rizik.”
Iz faze Controls in Action, korak 19: Tehnološke kontrole I.
Korak 19 zahtijeva da organizacije identificiraju privilegirane račune u lokalnim okruženjima, oblaku, SaaS-u, razvojnim i infrastrukturnim okruženjima. Obuhvaća administratore domene, root korisnike, administratore cloud tenanta, superskorisnike baza podataka i upravljače CI/CD cjevovoda. Također naglašava minimiziranje privilegiranog pristupa kroz kontrolu pristupa na temelju uloga, JIT eskalaciju ovlasti i radne tokove odobravanja.
To je važno jer mnogi ozbiljni incidenti ne počinju formalnim računom za izvanredni pristup. Počinju trajnom privilegijom. Inženjer za oblak zadržava vlasnička prava „za svaki slučaj”. Administrator baze podataka zadržava pristup produkcijskom okruženju nakon premještaja u drugi tim. CI/CD servisni račun ima široka ovlaštenja kroz više okruženja. Račun pružatelja upravljanih usluga izuzet je od MFA jer „im treba brz pristup”.
Korak 20 Zenith Blueprinta proširuje istu logiku na privilegirane pomoćne alate. Upućuje organizacije da izrade ili ažuriraju popis privilegiranih pomoćnih alata, ograniče izvršavanje na ovlaštene administratore, provjere da je uporaba evidentirana u dnevničkim zapisima i da generira upozorenja te razmotre zapisivanje skripti, primjerice PowerShell zapisivanje kroz pravila grupe. To je kritično jer je privilegirani račun često samo ulazna točka. Šteta nastaje kada napadač pokrene alate koji onemogućuju kontrole, izvlače vjerodajnice ili se lateralno kreću.
Korak 22 formalizira životni ciklus kontrole pristupa. Zahtijeva strukturiranu dodjelu i ukidanje pristupa, idealno integrirano s HR-om i podržano radnim tokovima zahtjeva za pristup, uz tromjesečne dokumentirane preglede pristupa. Korak 16 povezuje životni ciklus s izlaznim procesom zahtijevajući kontrolni popis za prestanak radnog odnosa koji HR i IT zajednički koriste, uključujući deaktivaciju računa, povrat imovine i podsjetnike na NDA.
Zenith Blueprint čini PAM povezanim operativnim modelom: identitet, HR, privilegirani pomoćni alati, dnevničko bilježenje, odgovor na incidente, pregledi pristupa i revizijski dokazi međusobno se podupiru.
Praktičan model upravljanja izvanrednim pristupom za 2026.
Dobro osmišljen proces izvanrednog pristupa mora raditi tijekom otkaza. Ako ovisi o istom pružatelju identiteta, sustavu za zahtjeve i chat usluzi koji nisu dostupni tijekom prekida, riječ je o prividu kontrole.
Istodobno, izvanredni pristup ne smije postati kanal zaobilaženja radi praktičnosti. Clarysec obično oblikuje upravljanje izvanrednim pristupom oko četiri sloja: prevencija, aktivacija, promatranje i oporavak.
| Sloj | Cilj kontrole | Praktični dokazi |
|---|---|---|
| Prevencija | Smanjiti potrebu za izvanrednim pristupom kroz načelo najmanjih privilegija, JIT pristup, redundanciju i testirane postupke oporavka. | PAM evidencija, RBAC model, zapisi pregleda pristupa, testovi otpornosti, plan obrade rizika. |
| Aktivacija | Osigurati da se izvanredni pristup koristi samo za odobrene izvanredne situacije i da je vremenski ograničen. | Postupak izvanrednog pristupa, zapis odobrenja, proglašenje incidenta, imenovani odobravatelj, vremenska oznaka aktivacije. |
| Promatranje | Zabilježiti što se dogodilo tijekom privilegirane aktivnosti. | Snimanje sesije, zapisi naredbi, autentikacijski zapisi, MFA dokazi, SIEM upozorenja, dokazi o sinkronizaciji vremena. |
| Oporavak | Ukloniti preostali rizik nakon uporabe izvanrednog pristupa. | Rotacija vjerodajnica, resetiranje računa, pregled nakon uporabe, vremenski slijed incidenta, naučene lekcije, ažuriranje registra rizika. |
Za okruženja u oblaku uključite administratore na razini tenanta, root račune u oblaku, izvanredne administratore pružatelja identiteta, privilegirane servisne račune, glavne korisnike baza podataka, Kubernetes cluster-admin uloge, CI/CD ključeve za uvođenje, administratore trezora tajni i račune podrške trećih strana.
Za hibridna okruženja uključite administratore domene, administratore sigurnosnog kopiranja, administratore hipervizora, administratore vatrozida, administratore EDR konzole i korisnike privilegiranih pomoćnih alata.
Za okruženja osjetljiva na privatnost uključite administratore koji mogu pristupiti bazama podataka s osobnim podacima, dnevničkim zapisima koji sadrže identifikatore, evidencijama HR-a, podacima biometrijske provjere identiteta, sustavima za praćenje prijevara ili alatima korisničke podrške.
Ciljno stanje jednostavno je opisati, a teško lažirati: svaki izvanredni put je poznat, odobren, zaštićen, promatran, reverzibilan i pregledan.
Šezdesetominutna vježba dokaza za izvanredni pristup
CISO ili voditelj usklađenosti može ovaj tjedan provesti korisnu vježbu izvanrednog pristupa bez kupnje novog alata. Cilj nije samo potvrditi da račun radi. Cilj je dokazati da kontrola proizvodi dokaze.
Scenarij
Pretpostavite da je primarni pružatelj identiteta degradiran. Redovna JIT eskalacija ovlasti nije dostupna. Klaster produkcijske baze podataka zahtijeva izvanredne konfiguracijske promjene radi obnove usluge. Izvanredni administratorski račun za oblak mora se aktivirati.
Korak 1: Potvrdite da je račun u popisu privilegiranih računa
Upotrijebite Zenith Blueprint, fazu Controls in Action, korak 19, kako biste provjerili da se račun nalazi u popisu privilegiranih računa. Zabilježite naziv računa i okruženje, poslovnog vlasnika, tehničkog vlasnika, dostupne sustave, utjecaj na osobne podatke, metodu autentifikacije, lokaciju trezora, metodu rotacije i datum posljednjeg testa.
Ako račun nedostaje, tretirajte to kao nedostatak kontrole i dodajte ga u registar rizika.
Korak 2: Provjerite usklađenost s politikom
Mapirajte događaj na zahtjeve Politike upravljanja korisničkim računima i privilegijama za dokumentirane postupke izvanrednog pristupa i zapisivanje privilegiranih sesija. Ako ste SME, koristite točke 7.3.1 i 7.3.2 Politike upravljanja korisničkim računima i privilegijama - SME kao minimalnu osnovnu razinu: dokumentirano, zaštićeno, nužno, evidentirano u dnevničkim zapisima, pregledano i resetirano.
Mapirajte zadržavanje odobrenja na točku 5.3.2 Politike kontrole pristupa, koja zahtijeva da odluke o odobrenju budu evidentirane u dnevničkim zapisima i čuvane najmanje 2 godine.
Korak 3: Otvorite zapis o izvanrednom pristupu
Izradite zahtjev ili zapis incidenta prije aktivacije ili u trenutku aktivacije. Uključite:
- Razlog izvanredne situacije
- Zahvaćenu uslugu
- Traženi račun
- Podnositelja zahtjeva
- Odobravatelja
- Vrijeme početka
- Očekivano vrijeme završetka
- Utjecaj na klijente ili regulatorni utjecaj
- Utjecaj na osobne podatke prema GDPR-u
- Oznaku za praćenje obveze izvješćivanja prema NIS2 ili DORA
Nemojte čekati kraj kako biste rekonstruirali priču. Revizijska vrijednost najjača je kada zapis počne prije uporabe pristupa.
Korak 4: Aktivirajte i promatrajte
Aktivirajte račun za izvanredni pristup. Potvrdite da se koristi MFA ili kompenzacijska autentifikacija, da se sesija snima, da su naredbe ili administrativne radnje evidentirane u dnevničkim zapisima, da se dnevnički zapisi prosljeđuju u centralizirano zapisivanje, da sinkronizacija vremena podržava rekonstrukciju vremenskog slijeda i da se generira upozorenje za uporabu izvanrednog računa.
To je usklađeno s Zenith Controls za 8.15 Dnevničko bilježenje, koje zapisivanje opisuje kao temeljni podatkovni sloj za nadzor i navodi da privilegirani korisnici i izvršavanje privilegiranih pomoćnih alata moraju biti sveobuhvatno evidentirani.
Korak 5: Zatvorite, resetirajte i pregledajte
Nakon izvanrednog zadatka onemogućite račun ili ga vratite u zapečaćeni status, rotirajte vjerodajnice ili resetirajte autentifikacijski faktor, pregledajte dnevničke zapise sesije, dokumentirajte naredbe i konfiguracijske promjene, potvrdite da nije došlo do nepotrebnog pristupa podacima, ažurirajte zapis incidenta, zabilježite naučene lekcije i odlučite jesu li aktivirani pragovi obavješćivanja prema NIS2, DORA ili GDPR.
Ako se pristupalo osobnim podacima, uključite DPO-a. Ako je događaj uzrokovao prekid usluge ili bi mogao uzrokovati značajan utjecaj, uključite vlasnika izvješćivanja prema NIS2 ili DORA. Ako račun za izvanredni pristup nije radio, dokumentirajte to kao nalaz operativne otpornosti, a ne samo kao IAM problem.
Mapiranje usklađenosti za PAM i kontrole izvanrednog pristupa
Najsnažniji model upravljanja ne duplicira kontrole za svaki propis. On gradi jedan lanac dokaza koji podupire više obveza.
| Okvir | Relevantnost PAM-a i izvanrednog pristupa | Dokazi koje revizori i regulatori očekuju |
|---|---|---|
| ISO/IEC 27001:2022 | Procjena rizika, obrada rizika, Izjava o primjenjivosti, operativna kontrola i kontrole iz Priloga A za prava pristupa, pristup s povišenim ovlastima, dnevničko bilježenje, nadzor, upravljanje incidentima i kontinuitet poslovanja. | Opseg ISMS-a, registar rizika, SoA, politike, pregledi pristupa, PAM konfiguracija, dnevnički zapisi, zapisi incidenata, korektivne radnje. |
| NIS2 | Article 21 zahtijeva odgovarajuće tehničke, operativne i organizacijske mjere, uključujući kontrolu pristupa, upravljanje imovinom, MFA ili kontinuiranu autentikaciju, postupanje s incidentima i kibernetičku higijenu. Article 20 izričito uvodi nadzor uprave. | Odobrenje upravnog odbora, osnovna razina kibernetičke higijene, politika privilegiranog pristupa, dokazi pregleda pristupa, operativne upute za prijavljivanje incidenata, kontrole administratorskog pristupa dobavljača. |
| DORA | Articles 5 i 6 zahtijevaju upravljano upravljanje IKT rizicima. Article 17 zahtijeva otkrivanje, bilježenje, klasifikaciju, eskalaciju i siguran oporavak incidenata. Articles 28 do 30 zahtijevaju upravljanje IKT rizicima trećih strana i ugovorne kontrole. | Okvir IKT rizika, izvješćivanje uprave, PAM za kritične funkcije, kontrole administratorskog pristupa trećih strana, dnevnički zapisi incidenata, analiza temeljnog uzroka, testovi otpornosti. |
| GDPR | Articles 5(1)(f), 5(2), 25 i 32 zahtijevaju cjelovitost, povjerljivost, odgovornost, ugrađenu zaštitu podataka i odgovarajuće sigurnosne mjere. | Minimizacija pristupa, pregledi administratorskih uloga, dnevnički zapisi pristupa osobnim podacima, reference na DPIA gdje je relevantno, dokazi procjene povrede. |
| NIST CSF 2.0 | Ishodi GOVERN povezuju pravne obveze, apetit za rizik, uloge, politike i nadzor. Ishodi PROTECT, DETECT, RESPOND i RECOVER podupiru kontrolu pristupa, dnevničke zapise, nadzor, odgovor na incidente i oporavak. | Trenutačni i ciljni profili, plan nedostataka, upravljački zapisi, nadzor dnevničkih zapisa, vježbe odgovora na incidente, dokumentacija oporavka. |
| COBIT 2019 | Perspektiva upravljanja i rukovođenja usmjerena je na vrijednost, rizik, resurse, vlasništvo nad procesima, ciljeve kontrola i osiguranje pristupa s povišenim ovlastima. | Vlasništvo nad procesima, RACI, pokazatelji učinkovitosti kontrola, izvješćivanje uprave, nalazi osiguranja, praćenje korektivnih mjera. |
NIST CSF 2.0 osobito je koristan pri prevođenju PAM-a u trenutačni profil i ciljni profil. Njegova metoda profila počinje opsegom, zatim prikuplja politike, prioritete rizika, registre, zahtjeve, prakse i radne uloge, prije izrade prioritiziranog akcijskog plana. Za pristup s povišenim ovlastima to znači opseg profila oko sigurnosti identiteta, administracije oblaka, otpornosti na ransomware, kritičnih financijskih sustava ili pristupa dobavljača.
Za financijske subjekte obuhvaćene DORA-om, DORA djeluje kao sektorski specifičan režim kibernetičke otpornosti EU za ekvivalentne obveze rizika i incidenata prema NIS2. To ne čini NIS2 nevažnim. To znači da financijski subjekt treba koristiti DORA kao upravljački režim za IKT rizik i zahtjeve za incidente, uz održavanje koordinacije s nacionalnim strategijama kibernetičke sigurnosti, nadležnim tijelima i CSIRT-ovima gdje je primjenjivo.
Kako revizori testiraju dokaze o privilegiranom pristupu
Revizori ne procjenjuju PAM samo čitanjem politike. Oni uspoređuju politiku, konfiguraciju, dnevničke zapise, zahtjeve, intervjue i promatranu praksu.
Revizijska metodologija Zenith Controls za prava privilegiranog pristupa upućuje na revizijske prakse ISO/IEC 19011:2018. Revizori pregledavaju politike koje definiraju povišena prava, dodjelu, nadzor i postupke opoziva. Ispituju popise korisničkih računa, zapise dodjele privilegija i dnevničke zapise. Potvrđuju dokaze kroz intervjue, PAM alate, usluge imenika i uzorke dnevničkih zapisa.
| Profil revizora | Tipična PAM pitanja | Slabi dokazi koji uzrokuju nalaze |
|---|---|---|
| Revizor ISO sustava upravljanja | Je li pristup s povišenim ovlastima uključen u procjenu rizika, obradu, SoA, politiku, operativnu kontrolu i internu reviziju? | Politika postoji, ali nema odobrenja vlasnika rizika, nema zapisa pregleda pristupa, nema praćenja korektivnih radnji. |
| Tehnički procjenitelj kontrola ISO/IEC 27002:2022 | Jesu li privilegirani računi jedinstveno identificirani, odobreni, vremenski ograničeni, snažno autentificirani, evidentirani i pregledani? | Dijeljeni administratorski računi, neaktivna administratorska prava, nema dnevničkih zapisa sesije, nema dokaza pregleda. |
| Nadležno tijelo za NIS2 | Može li organizacija dokazati kontrolu pristupa, upravljanje imovinom, kibernetičku higijenu, MFA gdje je primjereno i spremnost za incidente? | Izvanredni pristup nije testiran, administratorski pristup dobavljača nije upravljan, dokazi incidenta su slabi. |
| Revizor IKT rizika prema DORA | Može li financijski subjekt pokazati nadzor uprave, mapiranje kritičnih funkcija, klasifikaciju incidenata, upravljanje administratorskim pristupom trećih strana i testiranje otpornosti? | Administratori trećih strana izvan PAM-a, nema dokaza temeljnog uzroka, nema veze s kritičnim ili važnim funkcijama. |
| Revizor za GDPR ili DPO pregledavatelj | Može li organizacija dokazati da je privilegirani pristup osobnim podacima minimiziran, opravdan, evidentiran i uključen u procjenu povrede? | Administratori mogu široko pristupati osobnim podacima, dnevnički zapisi su nepotpuni, procjena povrede nema dokaze o pristupu. |
| Revizor usmjeren na ISACA ili COBIT | Tko je vlasnik procesa, kako se proces mjeri, kako se iznimke odobravaju i kako uprava zna da proces djeluje? | Nema RACI-ja, nema metrika, iznimke nisu upravljane, izvješćivanje uprave je slabo. |
Za prava pristupa Zenith Controls navodi da revizori uzorkuju zahtjeve za pristup korisnika, provjeravaju dokumentirana odobrenja i potvrđuju da je IT dodijelio samo odobreni pristup. Također uspoređuju korisničke uloge sa stvarnim pravima, provjeravajući provodi li se načelo najmanjih privilegija. Za dnevničko bilježenje revizori pregledavaju opseg zapisivanja, vrste događaja, razdoblja zadržavanja, zaštite i stvarne dnevničke zapise. Procjenjuju bilježe li se i pregledavaju neuspjele prijave, pristup osjetljivim podacima i konfiguracijske promjene.
Dobar paket dokaza za izvanredni pristup uključuje:
- Odobreni zahtjev za izvanredni pristup
- Kontekst incidenta ili prekida
- Identitet korisnika koji aktivira pristup
- Identitet odobravatelja
- Vrijeme početka i završetka
- MFA ili dokaz autentifikacije
- Snimku sesije ili zapis naredbi
- Sistemske dnevničke zapise i SIEM upozorenje
- Izvršene promjene
- Potvrdu resetiranja vjerodajnica
- Pregled nakon uporabe
- Procjenu pristupa podacima
- Procjenu regulatornog obavješćivanja
- Korektivne radnje ako nešto nije uspjelo
Ako vaša vježba ne može proizvesti ovaj paket, kontrola nije spremna za reviziju.
Skriveni neuspjeh: privilegirani pristup trećih strana
Mnoge organizacije bolje upravljaju administratorima zaposlenicima nego administratorima dobavljača. Za okruženja oblaka, SaaS-a, fintecha i upravljanih usluga to je suprotno od onoga što treba biti.
NIS2 Article 21 uključuje sigurnost opskrbnog lanca i odnose s izravnim dobavljačima i pružateljima usluga. DORA Articles 28 do 30 idu dalje za financijske subjekte, zahtijevajući strategiju upravljanja IKT rizicima trećih strana, registre ugovora o IKT uslugama, dubinsku analizu dobavljača, procjenu rizika koncentracije, prava na reviziju, prava raskida, izlazne strategije i ugovorne sigurnosne mjere.
Privilegirani pristup dobavljača treba biti u opsegu PAM-a ako dobavljač može administrirati produkcijsko okruženje, podržavati kritične ili važne funkcije, pristupiti osobnim podacima, mijenjati sigurnosne konfiguracije, upravljati sigurnosnim kopijama, implementirati kod ili koristiti alate za nadzor.
Clarysec obično očekuje da kontrole privilegiranog pristupa dobavljača uključuju:
- Imenovane korisnike dobavljača, a ne dijeljene račune dobavljača
- Ugovorne sigurnosne zahtjeve za pristup s povišenim ovlastima
- MFA i siguran udaljeni pristup
- Vremenski ograničene prozore pristupa
- Odobrenje klijenta za izvanredni pristup
- Zapisivanje sesija ili ekvivalentne revizijske tragove
- Trenutačni opoziv kada se osoblje promijeni
- Obveze suradnje u incidentima
- Zadržavanje dokaza usklađeno s revizijskim potrebama klijenta
- Izlazni plan za uklanjanje pristupa dobavljača
Ishodi opskrbnog lanca iz NIST CSF 2.0 ovdje su snažno usklađeni. Oni zahtijevaju uloge i odgovornosti dobavljača, prioritizaciju dobavljača prema kritičnosti, zahtjeve u ugovorima, dubinsku analizu dobavljača, kontinuirani nadzor, uključivanje dobavljača u planiranje incidenata i planove rizika nakon isteka ugovora.
Ako je račun pružatelja upravljanih usluga izuzet iz vašeg internog PAM radnog toka, to nije praktičnost. To je visokorizična iznimka koja pripada u registar rizika, registar dobavljača i pregled pristupa.
Uobičajeni nalazi za PAM i izvanredni pristup u 2026.
U Clarysec angažmanima nalazi rijetko iznenađuju. Obično su kombinacija dobrih namjera, operativnog pritiska i nepotpunih dokaza.
Najčešći nalazi su:
- Računi za izvanredni pristup postoje, ali nisu navedeni u popisu privilegiranih računa.
- Računi za izvanredne situacije izuzeti su iz redovnih pregleda pristupa.
- Organizacija ne može dokazati tko je koristio račun za izvanredne situacije.
- Račun nije resetiran nakon uporabe.
- Privilegirane sesije evidentiraju se u dnevničkim zapisima, ali naredbe ne.
- Dnevnički zapisi postoje lokalno, ali nisu zaštićeni od privilegiranih korisnika.
- Root računi u oblaku nisu testirani.
- Procesi oporavka MFA nisu dokumentirani.
- Privilegirani pristup za CI/CD cjevovode i servisne račune se zanemaruje.
- Pristup podrške trećih strana zaobilazi interno odobrenje.
- Odobrenje pristupa postoji u chat porukama, ali se ne čuva kao revizijski dokaz.
- Izlazni proces uklanja e-poštu i VPN, ali ne i administratorska prava za SaaS.
- DPO nije uključen kada pristup s povišenim ovlastima može izložiti osobne podatke.
- Operativne upute za incidente ne uključuju točke odlučivanja o obavješćivanju prema NIS2, DORA ili GDPR.
Svaki nalaz može se obraditi kroz obradu rizika prema ISO/IEC 27001:2022. Identificirajte rizik, dodijelite vlasnika, odaberite kontrole, ažurirajte Izjavu o primjenjivosti, provedite plan obrade rizika i čuvajte dokumentirane dokaze. To je snaga korištenja ISMS-a umjesto raspršenog skupa sigurnosnih zadataka.
Kako izgleda dobro stanje
Zreo operativni model PAM-a i izvanrednog pristupa ima pet ponavljajućih rutina.
Prvo, popisujte privilegirani pristup mjesečno ili kontinuirano. Uključite ljudske administratore, servisne račune, račune za izvanredne situacije, uloge u oblaku, CI/CD identitete, korisnike baza podataka, privilegirane pomoćne alate i administratore trećih strana.
Drugo, provodite načelo najmanjih privilegija kroz uloge, JIT eskalaciju ovlasti i odobrenja. Trajne privilegije trebaju biti rijetke, opravdane i pregledavane češće od pristupa standardnih korisnika.
Treće, nadzirite privilegirano ponašanje. Evidentirajte autentifikaciju, trajanje sesije, uporabu MFA, naredbe, konfiguracijske promjene, izvoze podataka, neuspjele pokušaje, eskalaciju privilegija i izvršavanje privilegiranih pomoćnih alata.
Četvrto, testirajte račune za izvanredni pristup prije izvanredne situacije. Račun za izvanredni pristup koji nikada nije testiran pretpostavka je, a ne kontrola.
Peto, izvješćujte upravu. NIS2 i DORA podižu kibernetičku sigurnost i IKT rizik na odgovornost upravljačkog tijela. Upravnom odboru nije potreban svaki zapis naredbe, ali su mu potrebne metrike: broj privilegiranih računa, zakašnjeli pregledi, izvanredne aktivacije, administratorski računi dobavljača, neuspjeli testovi, kritične iznimke i status korektivnih mjera.
Tu Clarysecov komplet alata postaje praktičan. Biblioteka politika daje jezik upravljanja. Zenith Blueprint daje redoslijed provedbe. Zenith Controls daje mapiranje međuregulatorne usklađenosti, odnose kontrola, pripadajuće standarde i revizijsku metodologiju.
Sljedeći koraci: pretvorite izvanredni pristup u otpornost spremnu za reviziju
Ako vaša organizacija nije testirala izvanredni pristup u posljednjih 90 dana, počnite od toga. Nemojte počinjati radionicom za odabir alata. Počnite s dokazima.
- Izradite ili ažurirajte popis privilegiranih računa.
- Identificirajte svaki račun za izvanredni pristup i svaki administratorski put za izvanredne situacije.
- Mapirajte svaki račun na poslovnog vlasnika, vlasnika sustava i utjecaj na podatke.
- Potvrdite pokrivenost politikom koristeći Clarysecovu Politiku upravljanja korisničkim računima i privilegijama Politika upravljanja korisničkim računima i privilegijama ili Politiku upravljanja korisničkim računima i privilegijama - SME Politika upravljanja korisničkim računima i privilegijama - SME.
- Upotrijebite Zenith Blueprint Zenith Blueprint, fazu Controls in Action, korake 19, 20, 22 i 16, kako biste povezali pristup s povišenim ovlastima, privilegirane pomoćne alate, preglede životnog ciklusa i izlazni proces.
- Upotrijebite Zenith Controls Zenith Controls za mapiranje kontrola ISO/IEC 27002:2022 8.2, 5.18 i 8.15 na očekivanja dokaza prema NIS2, DORA, GDPR i NIST.
- Provedite vježbu dokaza za izvanredni pristup i zabilježite rezultate.
- Dodajte nedostatke u plan obrade rizika i pratite korektivne mjere do zatvaranja.
Pristup s povišenim ovlastima je moć. Izvanredni pristup je izvanredna moć. U 2026. organizacije koje se uredno oporave od ransomwarea, prekida usluga u oblaku i otkaza identiteta bit će one koje mogu dokazati da je izvanredni pristup bio kontroliran prije, tijekom i nakon krize.
Clarysec vam može pomoći izgraditi taj dokaz, od politike do mapiranja kontrola i dokaza spremnih za reviziju. Počnite sa Zenith Blueprint, uparite ga s Politikom upravljanja korisničkim računima i privilegijama i Politikom kontrole pristupa, zatim upotrijebite Zenith Controls kako biste pokazali kako vaš PAM program podržava ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST CSF 2.0 i COBIT 2019.
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
