Zero Trust arhitektura 2026.: revizijski spremni dokazi

Zero Trust revizija u ponedjeljak ujutro koju nitko nije planirao

U ponedjeljak u 08:12 CISO europske SaaS fintech organizacije prima tri poruke u roku od pet minuta.

Prva je od bankarskog klijenta: „Molimo dostavite paket dokaza za vašu Zero Trust arhitekturu za naš godišnji pregled treće strane u području IKT-a.”

Druga je od pravnog odjela: „Mogli bismo biti klasificirani kao važan subjekt prema NIS2 u jednoj državi članici, a neki klijenti pitaju primjenjuje li se DORA posredno i na nas kao pružatelja IKT usluga.”

Treća je od voditelja inženjeringa: „Imamo MFA, jedinstvenu prijavu (SSO), otkrivanje i odgovor na prijetnje na krajnjim uređajima (EDR), Kubernetes mrežne politike i SIEM upozorenja. Je li to Zero Trust?”

Tu mnoge organizacije zastanu. Imaju sigurnosne alate, ali nemaju operativni model usklađenosti za Zero Trust. Mogu pokazati snimke zaslona za MFA, ali ne mogu objasniti kako se identitet, sigurnosno stanje uređaja, načelo najmanjih ovlasti, segmentacija, praćenje, prijavljivanje incidenata, zaštitne mjere privatnosti i ovisnosti o dobavljačima uklapaju u jednu cjelinu. Mogu prikazati kontrole, ali ne i sljedivost.

U 2026. Zero Trust arhitektura utemeljena na NIST SP 800-207 mora biti više od slogana „nikad ne vjeruj, uvijek provjeri”. Za CISO-ove, voditelje usklađenosti, revizore i vlasnike poslovnih procesa praktično je pitanje preciznije:

Kako Zero Trust pretvoriti u dokaze koji zadovoljavaju ISO/IEC 27001:2022, očekivanja NIS2 u pogledu kibernetičke higijene, upravljanje IKT rizicima u okviru DORA, sigurnost obrade iz GDPR Article 32, dubinsku analizu dobavljača koju traže klijenti i nadzor upravljačkog tijela?

Odgovor nije još jedan alat. Odgovor je model dokaza temeljen na riziku koji povezuje politiku, kontrole, tehničku provedbu, praćenje i odgovornost uprave.

Zero Trust u 2026.: od sigurnosne strategije do dokaza usklađenosti

NIST SP 800-207 definira Zero Trust kao skup načela za projektiranje i rad sigurnih sustava u kojima povjerenje nikada nije implicitno. Pristup se odobrava na temelju identiteta, konteksta, politike, stanja imovine i kontinuirane procjene.

Sedam NIST načela za Zero Trust osobito su korisna jer nejasan sigurnosni slogan pretvaraju u nešto što se može mapirati, testirati i revidirati:

1. Svi izvori podataka i računalne usluge smatraju se resursima.
2. Sva komunikacija zaštićena je neovisno o mrežnoj lokaciji.
3. Pristup pojedinačnim resursima organizacije odobrava se na razini sesije.
4. Pristup resursima određuje se dinamičkom politikom, uključujući atribute identiteta, uređaja, aplikacije i ponašanja.
5. Organizacija prati i mjeri cjelovitost i sigurnosni profil sve vlastite i povezane imovine.
6. Autentifikacija i autorizacija svih resursa dinamične su i strogo se provode prije dopuštanja pristupa.
7. Organizacija prikuplja informacije o imovini, infrastrukturi i komunikacijama te ih koristi za poboljšanje sigurnosnog profila.

Za suvremenog pružatelja SaaS usluga, digitalnu banku, pružatelja upravljanih usluga ili platformu izvorno razvijenu za oblak ta se načela prevode u praktične domene kontrola:

• Identitet se provjerava i njime se upravlja.
• Uređaji se procjenjuju prije odobravanja pristupa.
• Privilegirani pristup minimizira se i pregledava.
• Mrežni putovi segmentiraju se i kontroliraju.
• Aplikacije, sučelja za programiranje aplikacija i spremišta podataka provode autorizaciju.
• Zapisi dnevnika i telemetrija podržavaju kontinuirano praćenje.
• Incidenti pokreću ograničavanje, prijavljivanje i oporavak.
• Dokazi potvrđuju da kontrole rade, a ne samo da su osmišljene.

Upravo u toj zadnjoj točki počinje usklađenost.

ISO/IEC 27001:2022 zahtijeva da organizacije definiraju kontekst, zainteresirane strane, primjenjive pravne i ugovorne zahtjeve, opseg, sučelja i ovisnosti. Također zahtijeva procjenu rizika, obradu rizika, Izjavu o primjenjivosti, odgovornost vodstva, internu reviziju, preispitivanje od strane uprave i kontinuirano poboljšanje.

Zero Trust prirodno se uklapa u tu strukturu kada se tretira kao sustav kontrola. Ne smije stajati izvan ISMS-a kao inženjerska inicijativa. Mora biti dio procjene rizika, odabira kontrola, upravljanja politikama, upravljanja dobavljačima, zaštite privatnosti, odgovora na incidente i izvješćivanja upravljačkog tijela.

Regulatorni pritisak iza dokaza za Zero Trust

Pritisak za dokaze o Zero Trustu obično proizlazi iz preklapajućih obveza, a ne iz jednog standarda.

NIS2 se može primjenjivati na javne ili privatne subjekte u sektorima iz Priloga I ili Priloga II koji ispunjavaju pragove veličine i aktivnosti, a može se primjenjivati i na određene manje, ali kritične subjekte. Prilog I uključuje pružatelje usluga računalstva u oblaku, pružatelje podatkovnih centara, pružatelje mreža za isporuku sadržaja, pružatelje usluga povjerenja, pružatelje upravljanih usluga, pružatelje upravljanih sigurnosnih usluga, bankarske subjekte i subjekte infrastrukture financijskog tržišta. Prilog II uključuje digitalne pružatelje, kao što su internetske tržnice, tražilice i platforme društvenih mreža.

NIS2 Article 20 čini kibernetičku sigurnost odgovornošću upravljačkog tijela. Upravljačko tijelo mora odobriti mjere upravljanja rizicima kibernetičke sigurnosti, nadzirati njihovu provedbu i pohađati osposobljavanje iz kibernetičke sigurnosti. Article 21 zahtijeva primjerene i razmjerne tehničke, operativne i organizacijske mjere koje obuhvaćaju analizu rizika, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, siguran razvoj, postupanje s ranjivostima, procjenu učinkovitosti, kibernetičku higijenu, osposobljavanje, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa, upravljanje imovinom i, gdje je primjereno, MFA ili kontinuiranu autentikaciju. Article 23 uvodi fazno prijavljivanje značajnih incidenata, uključujući rano upozorenje u roku od 24 sata, obavijest u roku od 72 sata i završno izvješće.

DORA se primjenjuje od 17. siječnja 2025. i uspostavlja jedinstven režim digitalne operativne otpornosti za financijske subjekte. Obuhvaća upravljanje IKT rizicima, prijavljivanje značajnih incidenata povezanih s IKT-om, testiranje operativne otpornosti, razmjenu informacija o prijetnjama i rizik trećih strana u području IKT-a. DORA Articles 5 i 6 zahtijevaju upravljanje i dokumentirani okvir za upravljanje IKT rizicima. Article 9 odnosi se na zaštitu i prevenciju, uključujući politike, postupke, protokole i alate za zaštitu IKT sustava. Article 17 zahtijeva proces upravljanja incidentima povezanima s IKT-om.

GDPR se primjenjuje na obradu u kontekstu poslovnog nastana u EU, kao i na voditelje obrade ili izvršitelje obrade izvan EU koji nude robu ili usluge pojedincima u EU ili prate njihovo ponašanje. GDPR Article 5 zahtijeva odgovornost. Article 32 zahtijeva odgovarajuće tehničke i organizacijske mjere kako bi se osigurala razina sigurnosti primjerena riziku. Article 33 zahtijeva prijavu povrede osobnih podataka nadzornom tijelu bez nepotrebnog odgađanja i, gdje je izvedivo, u roku od 72 sata nakon saznanja za povredu.

Model dokaza za Zero Trust pomaže jer ista kontrola može podržati više okvira. MFA može podržati kontrolu pristupa prema ISO/IEC 27001:2022, mjere autentifikacije prema NIS2, zahtjeve zaštite prema DORA i sigurnost obrade prema GDPR. Ali samo ako organizacija može dokazati opseg, vlasništvo, provedbu, praćenje i pregled.

Mapiranje NIST Zero Trust načela na kontrole ISO/IEC 27001:2022

Kontrole iz Priloga A standarda ISO/IEC 27001:2022, uz provedbene smjernice ISO/IEC 27002:2022, daju revizijski jezik koji je potreban većini organizacija. Donja tablica prevodi NIST Zero Trust načela u područja ISO kontrola koja revizori prepoznaju.

Ovo mapiranje nije samo vježba tehničkog dizajna. Ono postaje struktura za registar rizika, Izjavu o primjenjivosti, paket dokaza i dnevni red preispitivanja od strane uprave.

Primjerice, scenarij rizika kao što je „kompromitirani račun razvojnog inženjera mijenja produkcijski kod i pristupa podacima klijenata” mora se mapirati na upravljanje identitetom, MFA, privilegirani pristup, razdvajanje mreže, zapisivanje događaja, praćenje, siguran razvoj, upravljanje promjenama i odgovor na incidente. Taj jedan scenarij može podržati ISO/IEC 27001:2022, NIS2 Article 21, upravljanje IKT rizicima u okviru DORA i GDPR Article 32.

Clarysec Zero Trust skup kontrola

Clarysec gradi Zero Trust oko pet domena dokaza: identitet, uređaj, mreža, aplikacija i podaci, uz praćenje i upravljanje kroz svih pet domena.

Temelj čine kontrola pristupa i upravljanje identitetom. U Zenith Controls: vodič za usklađenost kroz više okvira, kontrola ISO/IEC 27002:2022 5.15, kontrola pristupa, klasificirana je kao preventivna kontrola koja podržava povjerljivost, cjelovitost i dostupnost, usklađena je s konceptom kibernetičke sigurnosti Protect i sposobnošću upravljanja identitetom i pristupom. Kontrola 5.16, upravljanje identitetom, također je preventivna i povezana s istim CIA svojstvima i IAM sposobnošću. Kontrola 8.16, aktivnosti praćenja, klasificirana je kao detektivna i korektivna te podržava Detect i Respond kroz upravljanje događajima informacijske sigurnosti.

Ta je kombinacija važna. Zero Trust nije samo kontrola pristupa. To je kontrola pristupa zajedno sa životnim ciklusom identiteta, sigurnosnim stanjem uređaja, razdvajanjem mreže, praćenjem i odgovorom.

Odredbe Clarysec politika pretvaraju taj model u provedivo upravljanje.

Iz Korporativne politike kontrole pristupa, odjeljak Ciljevi, odredba 3.4:

Podržati Zero Trust načela uskraćivanjem pristupa prema zadanim postavkama, osim ako je izričito odobren i obrazložen.

Iz Korporativne politike upravljanja korisničkim računima i privilegijama, odjeljak Zahtjevi provedbe politike, odredba 6.2.1:

Svim korisnicima mora se dodijeliti najniža razina pristupa potrebna za obavljanje njihovih radnih zadataka.

Iz Korporativne politike sigurnosti mreže, odjeljak Zahtjevi upravljanja, odredba 5.2:

Sav promet između zona mora se kontrolirati vatrozidima ili softverski definiranim perimetarskim rješenjima, uz izričite konfiguracije uskraćivanja prema zadanim postavkama.

Iz Korporativne politike zapisivanja događaja i praćenja, odjeljak Ciljevi, odredba 3.4:

Uspostaviti centralizirane sustave za zapisivanje događaja i upozoravanje (npr. SIEM) radi agregiranja, korelacije i eskalacije sumnjivih aktivnosti gotovo u stvarnom vremenu.

Iz Korporativne politike informacijske sigurnosti, odjeljak Zahtjevi provedbe politike, odredba 6.6.1:

Sve implementirane kontrole moraju biti provjerljive u reviziji, podržane dokumentiranim postupcima i zadržanim dokazima o radu.

Za mala i srednja poduzeća ista se upravljačka namjera može provesti uz jednostavniju dokumentaciju politika. Politika upravljanja korisničkim računima i privilegijama - SME, odjeljak Ciljevi, odredba 3.2 navodi:

Provesti načelo najmanjih privilegija, osiguravajući da se korisnicima dodijeli samo najniža razina pristupa potrebna za obavljanje njihovih dužnosti.

Politika kontrole pristupa - SME, odjeljak Zahtjevi upravljanja, odredba 5.4.3 dodaje:

Povlašteni računi moraju koristiti višefaktorsku autentifikaciju (MFA) gdje je podržana.

Politika sigurnosti mreže - SME, odjeljak Zahtjevi provedbe politike, odredba 6.2.3 navodi:

Promet između segmenata mora se filtrirati, a pristup između segmenata mora slijediti načelo najmanjih ovlasti.

Politika zapisivanja događaja i praćenja - SME, odjeljak Svrha, odredba 1.3 objašnjava:

Zapisivanje događaja i praćenje podržavaju otkrivanje prijetnji, usklađenost s regulatornim zahtjevima, prijavljivanje i upravljanje incidentima te forenzičku analizu.

Za Zero Trust vođen privatnošću, Politika zaštite podataka i privatnosti - SME, odjeljak Zahtjevi upravljanja, odredba 5.3.2 navodi:

Korisnički pristup osobnim podacima mora biti ograničen na uloge s dokumentiranom poslovnom potrebom.

Te odredbe stvaraju revizijska uporišta. Revizor može testirati uskraćuje li se pristup prema zadanim postavkama, minimiziraju li se privilegije, kontrolira li se promet između zona, centraliziraju li se zapisi dnevnika i zadržavaju li se dokazi.

Mapa Zero Trust dokaza kroz više okvira

Snažan model dokaza za Zero Trust mora izbjeći fragmentirane snimke zaslona. Dokazi moraju prikazati upravljanje, dizajn, provedbu, praćenje i pregled.

Ova je tablica jezgra Zero Trust programa spremnog za upravljačko tijelo. Pokazuje kako jedno kontrolno okruženje može podržati više zahtjeva za dokazivanjem sigurnosti bez stvaranja zasebnih paketa dokaza za svaki okvir.

Korištenje Zenith Blueprinta za uspostavu sljedivosti

Clarysecov Zenith Blueprint: revizorov plan u 30 koraka osmišljen je kako bi spriječio da Zero Trust postane nedokumentirana inženjerska filozofija. U fazi upravljanja rizicima, korak 13, planiranje obrade rizika i Izjava o primjenjivosti, objašnjava:

SoA je zapravo povezni dokument: povezuje vašu procjenu/obradu rizika sa
stvarnim kontrolama koje imate. Njegovim popunjavanjem dodatno provjeravate jeste li propustili koju kontrolu.

Isti korak preporučuje mapiranje kontrola na rizike, dodavanje referenci na kontrole iz Priloga A u unose obrade rizika i unakrsno povezivanje s propisima kao što su GDPR, NIS2 ili DORA kada se kontrole provode radi ispunjavanja tih obveza.

Za Zero Trust to je veza koja nedostaje. Ako revizor pita zašto ste implementirali uvjetovani pristup, odgovor ne smije biti „zato što Zero Trust to traži”. Bolji odgovor glasi:

• Scenarij rizika jest neovlašteni pristup podacima klijenata putem kompromitiranih vjerodajnica.
• Vlasnik rizika jest CTO ili voditelj inženjeringa.
• Obrada rizika uključuje jedinstvenu prijavu (SSO), MFA, uvjetovani pristup, provjeru sigurnosnog stanja krajnjih uređaja, načelo najmanjih ovlasti, segmentaciju i praćenje.
• SoA mapira obradu rizika na kontrolu pristupa, upravljanje identitetom, zapisivanje događaja, praćenje, kriptografiju, upravljanje ranjivostima i upravljanje uslugama u oblaku.
• Ista obrada rizika podržava NIS2 Article 21, upravljanje IKT rizicima u okviru DORA i GDPR Article 32.
• Dokazi uključuju odredbe politika, preglede pristupa, SIEM upozorenja, EDR izvješća o sigurnosnom stanju, pravila vatrozida, IAM izvoze, vježbe za incidente i zapisnike preispitivanja od strane uprave.

Tako Zero Trust arhitektura postaje revizijski spremna.

Povjerenje u krajnje uređaje, API-ji i razdvajanje mreže u praksi

Zero Trust često ne uspijeva jer se organizacije usredotoče na identitet, a zanemaruju kontekst uređaja, radnog opterećenja, podataka i mreže.

Zenith Blueprint korak 19, Tehnološke kontrole I, jasno objašnjava zahtjev za sigurnosno stanje krajnjih uređaja:

Pristup informacijama putem krajnjih uređaja mora biti kontekstualan. Primjerice, ispunjava li uređaj
minimalne sigurnosne standarde prije pristupa resursima društva? Je li nedavno prošao
skeniranje na zlonamjerni softver? Povezuje li se s neuobičajene lokacije ili mreže? Integracijom sa Zero
Trust načelima sigurnosno stanje krajnjeg uređaja može se koristiti za uvjetovani pristup, pri čemu se ulaz odbija dok
uređaj ne dokaže da je siguran.

Time uređaj postaje dio odluke o autorizaciji. Valjana lozinka s neupravljanog prijenosnog računala ne smije se tretirati jednako kao valjana prijava s usklađenog, šifriranog i nadziranog korporativnog krajnjeg uređaja.

Isti korak naglašava da se ograničenja pristupa primjenjuju na aplikacije, usluge i API-je, a ne samo na korisnike:

Ograničenja pristupa moraju se primjenjivati i na aplikacije, usluge i API-je, ne samo na osobe.
Primjerice, mikroservisu može trebati samo pristup za čitanje tablice baze podataka, a ne potpuna CRUD
prava. Alatu za sigurnosno kopiranje može trebati pristup samo određenim spremnicima za pohranu, a ne svim resursima korisnika.

Ta je smjernica ključna za okruženja izvorno razvijena za oblak. Opsezi API-ja, servisni računi, identiteti radnih opterećenja, Kubernetes uloge i cloud IAM politike moraju slijediti načelo najmanjih ovlasti. Ljudski pristup samo je jedan dio kontrolne površine.

Korak 20 Zenith Blueprinta obrađuje razdvajanje mreža:

Razdvajanje je jedno od najstarijih i najučinkovitijih načela u kibernetičkoj sigurnosti: ograničiti
širenje, smanjiti rizik i obuzdati štetu. Kontrola 8.22 usredotočuje se na razdvajanje mreže,
praksu odvajanja sustava, usluga i korisnika u različite logičke ili
fizičke zone radi sprječavanja neovlaštenog pristupa i ograničavanja lateralnog kretanja u slučaju
kompromitacije.

To je ključno za otpornost prema DORA i NIS2. Zero Trust mreža mora pretpostaviti da jedan račun, radno opterećenje ili krajnji uređaj može biti kompromitiran. Segmentacija sprječava da lokalni događaj postane sistemski incident.

Desetodnevni paket dokaza za Zero Trust

Zamislite SaaS fintech organizaciju koja bankama pruža analitiku prijevara. Obrađuje osobne podatke, koristi infrastrukturu u oblaku, oslanja se na upravljani Kubernetes, integrira se s API-jima klijenata i koristi pružatelja identiteta treće strane. Klijent traži dokaze za Zero Trust, a društvo ima deset radnih dana.

Praktičan Clarysec sprint za dokaze izgledao bi ovako.

Cilj nije pretvarati se da je organizacija u deset dana postigla savršeni Zero Trust. Cilj je izraditi dokaziv lanac dokaza za najvažnije rizike i dokazati da se programom upravlja, da je mjerljiv i da se poboljšava.

Kako će različiti revizori testirati Zero Trust

Česta je pogreška pripremiti jednu tehničku priču i pretpostaviti da će svaki revizor postavljati ista pitanja. Neće.

Revizor ISO/IEC 27001:2022 tražit će sustav upravljanja. Pitat će jesu li Zero Trust rizici uključeni u procjenu rizika, jesu li obrade rizika odobrene, je li SoA potpuna, jesu li politike kontrolirani dokumenti, provode li se pregledi pristupa, testiraju li interne revizije kontrole i prate li preispitivanja od strane uprave učinkovitost.

DORA pregledavatelj pitat će jesu li Zero Trust kontrole dio dokumentiranog okvira za upravljanje IKT rizicima. Očekivat će popise imovine i ovisnosti, mapiranje kritičnih ili važnih funkcija, klasifikaciju incidenata, eskalaciju prema upravljačkom tijelu, testiranje, ugovorne zahtjeve za treće strane, prava na reviziju, strategije izlaska i praćenje korektivnih radnji.

NIS2 procjenitelj usredotočit će se na odgovornost upravljačkog tijela, mjere upravljanja rizicima kibernetičke sigurnosti iz Article 21 i spremnost za prijavljivanje incidenata iz Article 23. Također će očekivati dokaze da se upravlja sigurnošću opskrbnog lanca, neprekidnošću poslovanja, postupanjem s ranjivostima, kontrolom pristupa i kibernetičkom higijenom.

GDPR pregledavatelj ili revizor privatnosti pitat će je li pristup osobnim podacima nužan, dokumentiran, ograničen, praćen i usklađen sa svrhama obrade. Ispitat će uloge voditelja obrade i izvršitelja obrade, otkrivanje povrede osobnih podataka, pristup temeljen na ulogama, šifriranje, pseudonimizaciju gdje je primjereno, zadržavanje i odgovornost.

Ista kontrola može zadovoljiti više pitanja, ali samo ako su dokazi organizirani.

Rizik dobavljača, oblaka i trećih strana u području IKT-a

Zero Trust ne prestaje na vatrozidu, a u okruženjima u oblaku možda uopće nema tradicionalne granice vatrozida. Pružatelji identiteta, platforme u oblaku, CI/CD alati, pružatelji upravljanog otkrivanja, procesori plaćanja, API pristupnici i vanjski razvojni timovi postaju dio tkiva povjerenja.

NIS2 Article 21 izričito uključuje sigurnost opskrbnog lanca za izravne dobavljače i pružatelje usluga, uključujući ranjivosti dobavljača, otpornost proizvoda i usluga, prakse kibernetičke sigurnosti dobavljača i postupke sigurnog razvoja.

DORA zahtijeva upravljanje rizikom trećih strana u području IKT-a kao dijelom okvira za upravljanje IKT rizicima, uz registar ugovora o IKT uslugama, dubinsku analizu dobavljača prije sklapanja ugovora, procjenu kritičnosti, rizik koncentracije, ugovorne sigurnosne zahtjeve, pomoć pri incidentima, suradnju s nadležnim tijelima, prava na reviziju, prava raskida, strategije izlaska i tranzicijske planove.

Za Zero Trust praktično je pravilo jednostavno: ne vjerujte dobavljačkoj vezi samo zato što je ugovorna. Zahtijevajte tehničke kontrole i dokaze.

Integracija API-ja za klijente mora imati ograničene tokene, ograničavanje brzine zahtjeva, praćenje, rotaciju, vlasništvo i opoziv. Pružatelj upravljanih usluga mora koristiti MFA, imenovane korisničke račune, načelo najmanjih ovlasti, zapisivanje sesija i vremenski ograničen pristup. Odnos s pružateljem usluga u oblaku mora imati mapiranje podijeljene odgovornosti, konfiguraciju šifriranja, zadržavanje dnevničkih zapisa, testiranje sigurnosnih kopija i planiranje izlaska.

Zato dokazi o dobavljačima i oblaku pripadaju unutar Zero Trust modela, a ne u zasebnu mapu nabave.

Metrike koje dokazuju da Zero Trust djeluje

Upravljačka tijela i revizori ne žele samo arhitekturne dijagrame. Žele operativne dokaze i trendove poboljšanja.

Korisne Zero Trust metrike uključuju:

• Postotak povlaštenih računa zaštićenih MFA-om.
• Postotak korisnika obuhvaćenih uvjetovanim pristupom.
• Broj trajno aktivnih povlaštenih računa u usporedbi s just-in-time računima.
• Broj zakašnjelih pregleda pristupa.
• Postotak krajnjih uređaja usklađenih sa zahtjevima sigurnosnog stanja.
• Obuhvat EDR-a na kritičnoj imovini.
• Broj odbijenih pokušaja pristupa zbog rizika uređaja ili lokacije.
• Prosječno vrijeme do otkrivanja sumnjive privilegirane aktivnosti.
• Prosječno vrijeme do ukidanja pristupa nakon prestanka radnog odnosa.
• Postotak pravila vatrozida između zona pregledanih u posljednjem tromjesečju.
• Broj kritičnih dobavljača s važećim sigurnosnim dokazima.
• Broj Zero Trust iznimaka nakon datuma predviđenog za korektivnu radnju.
• Postotak kritičnih aplikacija koje šalju zapise dnevnika u SIEM.
• Rezultati simulacija incidenata za kompromitaciju vjerodajnica.

Te metrike podržavaju kontinuirano poboljšanje prema ISO/IEC 27001:2022, procjenu učinkovitosti prema NIS2, očekivanja testiranja i korektivnih radnji prema DORA te odgovornost prema GDPR.

Uobičajeni neuspjesi dokaza za Zero Trust

Najčešći neuspjesi nisu uzrokovani nedostatkom alata. Uzrokovani su slabom sljedivošću.

Prvo, organizacije implementiraju MFA, ali ne mogu dokazati da su povlašteni računi u potpunosti obuhvaćeni. Servisni računi, hitni računi i lokalni administratorski računi često ostaju izvan kontrole.

Drugo, pregledi pristupa provode se ručno, ali nisu povezani s poslovnim ulogama, osjetljivošću podataka ili vlasnicima rizika. Dokaz pokazuje da je netko kliknuo „pregledano”, a ne da je nepotreban pristup uklonjen.

Treće, segmentacija mreže postoji u dijagramima, ali ne i u testiranim pravilima. Revizori će pitati uskraćuje li se pristup između segmenata prema zadanim postavkama i jesu li iznimke odobrene.

Četvrto, zapisi dnevnika prikupljaju se, ali nisu uporabivi. SIEM bez definiranih slučajeva uporabe, trijaže upozorenja i postupaka odgovora ne dokazuje kontinuirano praćenje.

Peto, pristup dobavljača nije upravljan. Dobavljači mogu koristiti zajedničke vjerodajnice, trajni VPN pristup ili široke cloud uloge bez praćenja sesija.

Šesto, dokazi o privatnosti odvojeni su od sigurnosnih dokaza. GDPR zahtijeva dokazivu zaštitu osobnih podataka, pa se kontrole identiteta i pristupa moraju povezati s kategorijama podataka i svrhama obrade.

Naposljetku, iznimke nisu dokumentirane. Zero Trust može tolerirati iznimke ako su procijenjene prema riziku, odobrene, vremenski ograničene i praćene. Ne može tolerirati nevidljive iznimke.

Izradite svoj paket dokaza za Zero Trust uz Clarysec

Zero Trust arhitektura u 2026. nije slogan. To je operativni model usklađenosti koji povezuje identitet, uređaje, aplikacije, segmentaciju mreže, načelo najmanjih ovlasti, kontinuirano praćenje, kontrolu dobavljača i zaštitne mjere privatnosti u jedan sustav provjerljiv u reviziji.

Ako se pripremate za certifikaciju ISO/IEC 27001:2022, odgovarate na NIS2 upite klijenata, usklađujete se s upravljanjem IKT rizicima u okviru DORA ili dokazujete sigurnost obrade iz GDPR Article 32, započnite sa sljedivošću.

Upotrijebite Zenith Blueprint: revizorov plan u 30 koraka za mapiranje Zero Trust rizika u svoj registar rizika, plan obrade rizika i SoA. Upotrijebite Zenith Controls: vodič za usklađenost kroz više okvira za usklađivanje kontrole pristupa, upravljanja identitetom i praćenja s očekivanjima više okvira. Upotrijebite Clarysecovu biblioteku politika, uključujući Korporativnu politiku kontrole pristupa, Korporativnu politiku upravljanja korisničkim računima i privilegijama, Korporativnu politiku sigurnosti mreže, Korporativnu politiku zapisivanja događaja i praćenja, Korporativnu politiku informacijske sigurnosti i Politiku zaštite podataka i privatnosti - SME, kako biste arhitekturu pretvorili u provedivo upravljanje.

Vaš sljedeći praktični korak jest odabrati jedan scenarij visokog rizika, kao što je kompromitirani privilegirani pristup podacima klijenata, i oko njega izgraditi cjelovit lanac dokaza za Zero Trust. Ako taj scenarij možete dokazati od početka do kraja, imate temelj za skalabilan, revizijski provjerljiv i regulatorno spreman Zero Trust program.

Preuzmite Clarysec pakete politika ili dogovorite strateški razgovor kako biste vidjeli kako Zenith Blueprint i Zenith Controls mogu pretvoriti Zero Trust iz revizijskog rizika u prednost usklađenosti.