Arhitektura ničelnega zaupanja 2026: dokazila, pripravljena za presojo

Ponedeljkova jutranja presoja ničelnega zaupanja, ki je nihče ni načrtoval

V ponedeljek ob 08:12 vodja informacijske varnosti evropskega SaaS fintech podjetja v petih minutah prejme tri sporočila.

Prvo je od bančne stranke: »Prosimo, posredujte paket dokazil za vašo arhitekturo ničelnega zaupanja za naš letni pregled tretje strani na področju IKT.«

Drugo je od pravne službe: »V eni državi članici smo lahko razvrščeni kot pomemben subjekt po NIS2, nekatere stranke pa sprašujejo, ali se DORA prenese tudi na nas kot ponudnika storitev IKT.«

Tretje je od vodje inženiringa: »Imamo MFA, SSO, EDR, omrežne politike Kubernetes in opozorila SIEM. Je to ničelno zaupanje?«

Tu se številne organizacije ustavijo. Imajo varnostna orodja, nimajo pa operativnega modela skladnosti za ničelno zaupanje. Lahko pokažejo posnetke zaslona MFA, ne morejo pa pojasniti, kako so med seboj povezani identiteta, stanje naprave, načelo najmanjših privilegijev, segmentacija, spremljanje, poročanje o incidentih, varovala zasebnosti in odvisnosti od dobaviteljev. Lahko pokažejo kontrole, ne pa tudi sledljivosti.

Leta 2026 mora biti arhitektura ničelnega zaupanja, ki temelji na NIST SP 800-207, več kot »nikoli ne zaupaj, vedno preveri«. Za vodje informacijske varnosti, vodje skladnosti, presojevalce in lastnike poslovnih procesov je praktično vprašanje ostrejše:

Kako ničelno zaupanje pretvoriti v dokazila, ki zadostijo ISO/IEC 27001:2022, pričakovanjem NIS2 glede kibernetske higiene, upravljanju IKT-tveganj po DORA, varnosti obdelave iz GDPR Article 32, skrbnemu pregledu strank in nadzoru organa upravljanja?

Odgovor ni še eno orodje. Odgovor je model dokazil na podlagi tveganj, ki povezuje politiko, kontrole, tehnično izvedbo, spremljanje in odgovornost vodstva.

Ničelno zaupanje v letu 2026: od varnostne strategije do dokazil o skladnosti

NIST SP 800-207 opredeljuje ničelno zaupanje kot nabor načel za načrtovanje in delovanje varnih sistemov, v katerih zaupanje nikoli ni implicitno. Dostop se dodeli na podlagi identitete, konteksta, politike, stanja sredstva in neprekinjenega vrednotenja.

Sedem načel ničelnega zaupanja po NIST je posebej uporabnih, ker nejasen varnostni slogan pretvorijo v nekaj, kar je mogoče preslikati, testirati in presojati:

1. Vsi podatkovni viri in računalniške storitve se obravnavajo kot viri.
2. Vsa komunikacija je zaščitena ne glede na lokacijo v omrežju.
3. Dostop do posameznih virov podjetja se dodeli za vsako sejo posebej.
4. Dostop do virov določa dinamična politika, vključno z atributi identitete, naprave, aplikacije in vedenja.
5. Podjetje spremlja in meri celovitost ter varnostni profil tveganja vseh sredstev v lasti in povezanih sredstev.
6. Avtentikacija in avtorizacija vseh virov sta dinamični in se strogo uveljavita, preden je dostop dovoljen.
7. Podjetje zbira informacije o sredstvih, infrastrukturi in komunikacijah ter jih uporablja za izboljšanje varnostnega profila tveganja.

Za sodobnega ponudnika SaaS, digitalno banko, ponudnika upravljanih storitev ali izvorno oblačno platformo se ta načela prevedejo v praktična področja kontrol:

• Identiteta je preverjena in upravljana.
• Naprave se ocenijo pred dodelitvijo dostopa.
• Privilegirani dostop je zmanjšan na minimum in pregledan.
• Omrežne poti so segmentirane in nadzorovane.
• Aplikacije, vmesniki API in podatkovne shrambe uveljavljajo avtorizacijo.
• Dnevniki in telemetrija podpirajo stalno spremljanje.
• Incidenti sprožijo zajezitev, poročanje in obnovitev.
• Dokazila potrjujejo, da kontrole delujejo, ne le da so zasnovane.

Pri tej zadnji točki vstopi skladnost.

ISO/IEC 27001:2022 od organizacij zahteva opredelitev konteksta, zainteresiranih strani, veljavnih pravnih in pogodbenih zahtev, obsega, vmesnikov in odvisnosti. Zahteva tudi oceno tveganj, obravnavo tveganj, izjavo o uporabnosti, odgovornost vodstva, notranjo presojo, vodstveni pregled in nenehno izboljševanje.

Ničelno zaupanje se naravno vključi v to strukturo, kadar se obravnava kot sistem kontrol. Ne sme ostati zunaj ISMS kot inženirska pobuda. Biti mora del ocene tveganj, izbire kontrol, upravljanja politik, upravljanja dobaviteljev, varstva zasebnosti, odziva na incidente in poročanja organu upravljanja.

Regulativni pritisk v ozadju dokazil za ničelno zaupanje

Pritisk po dokazilih za ničelno zaupanje običajno izhaja iz prekrivajočih se obveznosti, ne iz enega samega standarda.

NIS2 se lahko uporablja za javne ali zasebne subjekte v sektorjih iz Priloge I ali Priloge II, ki izpolnjujejo pragove glede velikosti in dejavnosti, uporablja pa se lahko tudi za nekatere manjše, vendar kritične subjekte. Priloga I vključuje ponudnike storitev računalništva v oblaku, ponudnike podatkovnih centrov, ponudnike omrežij za dostavo vsebin, ponudnike storitev zaupanja, ponudnike upravljanih storitev, ponudnike upravljanih varnostnih storitev, banke in subjekte infrastrukture finančnih trgov. Priloga II vključuje digitalne ponudnike, kot so spletne tržnice, iskalniki in platforme družbenih omrežij.

NIS2 Article 20 določa, da je kibernetska varnost odgovornost organa upravljanja. Organ upravljanja mora odobriti ukrepe za obvladovanje tveganj kibernetske varnosti, nadzirati njihovo izvajanje in se udeležiti usposabljanja iz kibernetske varnosti. Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe, ki zajemajo analizo tveganj, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varen razvoj, obravnavo ranljivosti, oceno učinkovitosti, kibernetsko higieno, usposabljanje, kriptografijo, kadrovsko varnost, nadzor dostopa, upravljanje sredstev ter, kjer je primerno, MFA ali neprekinjeno avtentikacijo. Article 23 uvaja fazno poročanje o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah, obvestilom v 72 urah in končnim poročilom.

DORA se uporablja od 17. januarja 2025 in vzpostavlja enoten režim digitalne operativne odpornosti za finančne subjekte. Zajema upravljanje IKT-tveganj, poročanje o večjih incidentih, povezanih z IKT, testiranje operativne odpornosti, izmenjavo informacij o grožnjah in tveganjih ter tveganja tretjih oseb na področju IKT. DORA Articles 5 in 6 zahtevata upravljanje in dokumentiran okvir upravljanja IKT-tveganj. Article 9 obravnava zaščito in preprečevanje, vključno s politikami, postopki, protokoli in orodji za zaščito sistemov IKT. Article 17 zahteva proces upravljanja incidentov, povezanih z IKT.

GDPR se uporablja za obdelavo v okviru dejavnosti poslovne enote v EU ter tudi za upravljavce ali obdelovalce zunaj EU, ki posameznikom v EU ponujajo blago ali storitve ali spremljajo njihovo vedenje. GDPR Article 5 zahteva odgovornost. Article 32 zahteva ustrezne tehnične in organizacijske ukrepe za zagotovitev ravni varnosti, ustrezne tveganju. Article 33 zahteva obvestilo o kršitvi varnosti osebnih podatkov nadzornemu organu brez nepotrebnega odlašanja in, kadar je izvedljivo, v 72 urah po seznanitvi s kršitvijo.

Model dokazil za ničelno zaupanje pomaga, ker lahko ista kontrola podpira več okvirov. MFA lahko podpira nadzor dostopa po ISO/IEC 27001:2022, avtentikacijske ukrepe po NIS2, zahteve DORA glede zaščite in varnost obdelave po GDPR. Vendar le, če lahko organizacija dokaže obseg, lastništvo, izvedbo, spremljanje in pregled.

Preslikava načel ničelnega zaupanja po NIST v kontrole ISO/IEC 27001:2022

Kontrole iz Priloge A ISO/IEC 27001:2022, podprte z izvedbenimi usmeritvami iz ISO/IEC 27002:2022, zagotavljajo revizijski jezik, ki ga potrebuje večina organizacij. Spodnja tabela prevaja načela ničelnega zaupanja po NIST v področja kontrol ISO, ki jih presojevalci prepoznajo.

Ta preslikava ni le vaja tehničnega načrtovanja. Postane struktura za register tveganj, izjavo o uporabnosti, paket dokazil in dnevni red vodstvenega pregleda.

Na primer, scenarij tveganja »kompromitiran račun razvijalca spremeni produkcijsko kodo in dostopa do podatkov strank« se mora preslikati v upravljanje identitet, MFA, privilegirani dostop, ločevanje omrežij, beleženje, spremljanje, varen razvoj, upravljanje sprememb in odziv na incidente. Ta en sam scenarij lahko podpira ISO/IEC 27001:2022, NIS2 Article 21, upravljanje IKT-tveganj po DORA in GDPR Article 32.

Clarysec nabor kontrol za ničelno zaupanje

Clarysec gradi ničelno zaupanje okoli petih področij dokazil: identiteta, naprava, omrežje, aplikacija in podatki, pri čemer se spremljanje in upravljanje izvajata prek vseh petih področij.

Temelj sta nadzor dostopa in upravljanje identitet. V Zenith Controls: The Cross-Compliance Guide je kontrola ISO/IEC 27002:2022 5.15, nadzor dostopa, razvrščena kot preventivna kontrola, ki podpira zaupnost, celovitost in razpoložljivost ter je usklajena s konceptom kibernetske varnosti Protect in zmogljivostjo upravljanja identitet in dostopa. Kontrola 5.16, upravljanje identitet, je prav tako preventivna in povezana z istimi lastnostmi CIA ter zmogljivostjo IAM. Kontrola 8.16, dejavnosti spremljanja, je razvrščena kot odkrivalna in korektivna ter prek upravljanja dogodkov informacijske varnosti podpira Detect in Respond.

Ta kombinacija je pomembna. Ničelno zaupanje ni samo nadzor dostopa. Je nadzor dostopa skupaj z življenjskim ciklom identitet, stanjem naprave, ločevanjem omrežij, spremljanjem in odzivom.

Določila politik Clarysec ta model pretvorijo v izvršljivo upravljanje.

Iz Enterprise Access Control Policy, razdelek Cilji, določilo 3.4:

Podpirati načela ničelnega zaupanja z zavrnitvijo dostopa po privzetem, razen če je izrecno odobren in utemeljen.

Iz Enterprise User Account and Privilege Management Policy, razdelek Zahteve za izvajanje politike, določilo 6.2.1:

Vsem uporabnikom mora biti dodeljena najnižja raven dostopa, potrebna za opravljanje njihovih delovnih nalog.

Iz Enterprise Network Security Policy, razdelek Zahteve upravljanja, določilo 5.2:

Ves promet med conami mora biti nadzorovan s požarnimi zidovi ali programsko opredeljenimi perimetrskimi rešitvami, z izrecnimi konfiguracijami privzetega zavračanja.

Iz Enterprise Logging and Monitoring Policy, razdelek Cilji, določilo 3.4:

Vzpostaviti centralizirane sisteme beleženja in opozarjanja (npr. SIEM) za združevanje, korelacijo in eskalacijo sumljivih dejavnosti skoraj v realnem času.

Iz Enterprise Information Security Policy, razdelek Zahteve za izvajanje politike, določilo 6.6.1:

Vse uvedene kontrole morajo biti preverljive, podprte z dokumentiranimi postopki in ohranjenimi dokazili o delovanju.

Za MSP se lahko isti namen upravljanja uvede z lažjo dokumentacijo politik. User Account and Privilege Management Policy - SME, razdelek Cilji, določilo 3.2 določa:

Uveljaviti načelo najmanjših privilegijev in zagotoviti, da je uporabnikom dodeljena samo najnižja raven dostopa, potrebna za opravljanje njihovih nalog.

Access Control Policy - SME, razdelek Zahteve upravljanja, določilo 5.4.3 dodaja:

Privilegirani računi morajo uporabljati večfaktorsko avtentikacijo (MFA), kjer je podprta.

Network Security Policy - SME, razdelek Zahteve za izvajanje politike, določilo 6.2.3 določa:

Promet med segmenti mora biti filtriran, dostop med segmenti pa mora slediti načelu najmanjših privilegijev.

Logging and Monitoring Policy - SME, razdelek Namen, določilo 1.3 pojasnjuje:

Beleženje in spremljanje podpirata zaznavanje groženj, regulativno skladnost, poročanje in upravljanje incidentov ter forenzično analizo.

Za ničelno zaupanje, vodeno z zasebnostjo, Data Protection and Privacy Policy - SME, razdelek Zahteve upravljanja, določilo 5.3.2 določa:

Uporabniški dostop do osebnih podatkov mora biti omejen na vloge z dokumentirano poslovno potrebo.

Ta določila ustvarijo presojevalska sidra. Presojevalec lahko preveri, ali je dostop privzeto zavrnjen, ali so privilegiji minimizirani, ali je promet med conami nadzorovan, ali so dnevniki centralizirani in ali se dokazila hranijo.

Medokvirna preslikava dokazil za ničelno zaupanje

Močan model dokazil za ničelno zaupanje se mora izogniti razdrobljenim posnetkom zaslona. Dokazila morajo prikazati upravljanje, zasnovo, izvedbo, spremljanje in pregled.

Ta tabela je jedro programa ničelnega zaupanja, primernega za organ upravljanja. Pokaže, kako lahko eno kontrolno okolje podpira več zahtev za zagotavljanje zaupanja, ne da bi za vsak okvir ustvarjali ločene pakete dokazil.

Uporaba Zenith Blueprint za vzpostavitev sledljivosti

Clarysecov Zenith Blueprint: An Auditor’s 30-Step Roadmap je zasnovan tako, da prepreči, da bi ničelno zaupanje postalo nedokumentirana inženirska filozofija. V fazi upravljanja tveganj, korak 13, Načrtovanje obravnave tveganj in izjava o uporabnosti, pojasnjuje:

SoA je dejansko povezovalni dokument: poveže vašo oceno/obravnavo tveganj z
dejanskimi kontrolami, ki jih imate. Z njegovo izpolnitvijo tudi ponovno preverite, ali ste spregledali katero od kontrol.

Isti korak priporoča preslikavo kontrol v tveganja, dodajanje sklicev na kontrole iz Priloge A k vnosom obravnave tveganj ter navzkrižno sklicevanje na predpise, kot so GDPR, NIS2 ali DORA, kadar so kontrole uvedene za izpolnitev teh obveznosti.

Za ničelno zaupanje je to manjkajoči most. Če presojevalec vpraša, zakaj ste uvedli pogojni dostop, odgovor ne sme biti »ker tako pravi ničelno zaupanje«. Boljši odgovor je:

• Scenarij tveganja je nepooblaščen dostop do podatkov strank prek kompromitiranih poverilnic.
• Lastnik tveganja je CTO ali vodja inženiringa.
• Obravnava vključuje SSO, MFA, pogojni dostop, preverjanje stanja končne točke, načelo najmanjših privilegijev, segmentacijo in spremljanje.
• SoA preslika obravnavo v nadzor dostopa, upravljanje identitet, beleženje, spremljanje, kriptografijo, upravljanje ranljivosti in upravljanje storitev v oblaku.
• Ista obravnava podpira NIS2 Article 21, upravljanje IKT-tveganj po DORA in GDPR Article 32.
• Dokazila vključujejo določila politik, preglede pravic dostopa, opozorila SIEM, poročila o stanju EDR, pravila požarnega zidu, izvoze IAM, vaje incidentov in zapisnike vodstvenih pregledov.

Tako arhitektura ničelnega zaupanja postane pripravljena za presojo.

Zaupanje končnim točkam, vmesniki API in ločevanje omrežij v praksi

Ničelno zaupanje pogosto odpove, ker se organizacije osredotočijo na identiteto, pri tem pa prezrejo naprave, delovne obremenitve, podatke in omrežni kontekst.

Zenith Blueprint korak 19, Tehnološke kontrole I, jasno pojasnjuje zahtevo glede stanja končne točke:

Dostop do informacij prek končnih točk mora biti kontekstno odvisen. Na primer, ali naprava
izpolnjuje minimalne varnostne standarde pred dostopom do virov podjetja? Ali je nedavno uspešno prestala
pregled zlonamerne programske opreme? Ali se povezuje z nenavadne lokacije ali omrežja? Pri povezovanju z načeli ničelnega
zaupanja lahko stanje končne točke napaja pogojni dostop, ki zavrne vstop, dokler
naprava ne dokaže, da je varna.

S tem naprava postane del odločitve o avtorizaciji. Veljavno geslo iz neupravljanega prenosnika ne sme biti obravnavano enako kot veljavna prijava s skladne, šifrirane in spremljane končne točke podjetja.

Isti korak poudarja, da omejitve dostopa veljajo za aplikacije, storitve in vmesnike API, ne samo za uporabnike:

Omejitve dostopa je treba uporabljati tudi za aplikacije, storitve in vmesnike API, ne le za ljudi.
Na primer, mikrostoritev morda potrebuje samo bralni dostop do tabele podatkovne baze, ne pa polnih pravic CRUD.
Orodje za varnostno kopiranje morda potrebuje dostop samo do določenih veder za shranjevanje, ne pa do vseh virov najemnika.

Ta usmeritev je ključna za izvorno oblačna okolja. Obsegi API, storitveni računi, identitete delovnih obremenitev, vloge Kubernetes in politike IAM v oblaku morajo vsi slediti načelu najmanjših privilegijev. Človeški dostop je le en del kontrolne površine.

Korak 20 v Zenith Blueprint obravnava ločevanje omrežij:

Ločevanje je eno najstarejših in najučinkovitejših načel v kibernetski varnosti: omeji
širjenje, zmanjša tveganje in zameji škodo. Kontrola 8.22 se osredotoča na ločevanje omrežij,
prakso ločevanja sistemov, storitev in uporabnikov v različne logične ali
fizične cone, da se prepreči nepooblaščen dostop in omeji lateralno gibanje v primeru
kompromitacije.

To je ključno za odpornost po DORA in NIS2. Omrežje ničelnega zaupanja mora predpostavljati, da se lahko kompromitira en račun, delovna obremenitev ali končna točka. Segmentacija prepreči, da bi lokalni dogodek postal sistemski incident.

10-dnevni paket dokazil za ničelno zaupanje

Predstavljajte si SaaS fintech podjetje, ki bankam zagotavlja analitiko prevar. Obdeluje osebne podatke, uporablja infrastrukturo v oblaku, se opira na upravljani Kubernetes, se povezuje z vmesniki API strank in uporablja ponudnika identitet tretje osebe. Stranka zahteva dokazila za ničelno zaupanje, podjetje pa ima deset delovnih dni.

Praktični pospešeni cikel dokazil Clarysec bi bil videti takole.

Cilj ni ustvariti vtisa, da je organizacija v desetih dneh dosegla popolno ničelno zaupanje. Cilj je vzpostaviti zagovorljivo verigo dokazil za najpomembnejša tveganja in dokazati, da je program upravljan, merljiv in se izboljšuje.

Kako bodo različni presojevalci testirali ničelno zaupanje

Pogosta napaka je pripraviti eno tehnično zgodbo in predpostaviti, da bodo vsi presojevalci postavili ista vprašanja. Ne bodo.

Presojevalec ISO/IEC 27001:2022 bo iskal sistem upravljanja. Vprašal bo, ali so tveganja ničelnega zaupanja vključena v oceno tveganj, ali so obravnave odobrene, ali je SoA popolna, ali so politike nadzorovani dokumenti, ali se izvajajo pregledi pravic dostopa, ali notranje presoje testirajo kontrole in ali vodstveni pregledi spremljajo uspešnost.

Pregledovalec DORA bo vprašal, ali so kontrole ničelnega zaupanja del dokumentiranega okvira upravljanja IKT-tveganj. Pričakoval bo popise sredstev in odvisnosti, preslikavo kritičnih ali pomembnih funkcij, razvrščanje incidentov, eskalacijo organu upravljanja, testiranje, pogodbene zahteve za tretje osebe, pravice do presoje, izhodne strategije in sledenje odpravi pomanjkljivosti.

Ocenjevalec NIS2 se bo osredotočil na odgovornost organa upravljanja, ukrepe za obvladovanje tveganj kibernetske varnosti iz Article 21 in pripravljenost na poročanje o incidentih iz Article 23. Pričakoval bo tudi dokazila, da se upravljajo varnost dobavne verige, neprekinjeno poslovanje, obravnava ranljivosti, nadzor dostopa in kibernetska higiena.

Pregledovalec GDPR ali presojevalec zasebnosti bo vprašal, ali je dostop do osebnih podatkov potreben, dokumentiran, omejen, spremljan in usklajen z nameni obdelave. Pregledal bo vloge upravljavca in obdelovalca, zaznavanje kršitev varnosti osebnih podatkov, dostop na podlagi vlog, šifriranje, psevdonimizacijo, kjer je primerno, hrambo in odgovornost.

Ista kontrola lahko zadovolji več vprašanj, vendar le, če so dokazila urejena.

Tveganje dobaviteljev, oblaka in tretjih oseb na področju IKT

Ničelno zaupanje se ne konča pri požarnem zidu, v okoljih v oblaku pa tradicionalne meje požarnega zidu pogosto sploh ni. Ponudniki identitet, oblačne platforme, orodja CI/CD, ponudniki upravljanega zaznavanja, obdelovalci plačil, prehodi API in ekipe za zunanji razvoj postanejo del tkiva zaupanja.

NIS2 Article 21 izrecno vključuje varnost dobavne verige za neposredne dobavitelje in ponudnike storitev, vključno z ranljivostmi dobaviteljev, odpornostjo izdelkov in storitev, praksami kibernetske varnosti dobaviteljev in postopki varnega razvoja.

DORA zahteva, da se tveganja tretjih oseb na področju IKT upravljajo kot del okvira upravljanja IKT-tveganj, z registrom pogodb za storitve IKT, predpogodbenim skrbnim pregledom, oceno kritičnosti, tveganjem koncentracije, pogodbenimi varnostnimi zahtevami, pomočjo pri incidentih, sodelovanjem z organi, pravicami do presoje, pravicami do odpovedi, izhodnimi strategijami in prehodnimi načrti.

Za ničelno zaupanje je praktično pravilo preprosto: ne zaupajte povezavi dobavitelja samo zato, ker je pogodbena. Zahtevajte tehnične kontrole in dokazila.

Integracija API za stranke mora imeti omejene žetone, omejitve hitrosti zahtevkov, spremljanje, rotacijo, lastništvo in preklic. Ponudnik upravljanih storitev mora uporabljati MFA, poimenske uporabniške račune, načelo najmanjših privilegijev, beleženje sej in časovno omejen dostop. Odnos s ponudnikom storitev v oblaku mora vključevati preslikavo deljene odgovornosti, konfiguracijo šifriranja, hrambo dnevnikov, testiranje varnostnih kopij in načrtovanje izhoda.

Zato dokazila o dobaviteljih in oblaku sodijo v model ničelnega zaupanja, ne v ločeno mapo nabave.

Kazalniki, ki dokazujejo, da ničelno zaupanje deluje

Organi upravljanja in presojevalci ne želijo samo arhitekturnih diagramov. Želijo dokazila o delovanju in trende izboljševanja.

Uporabni kazalniki ničelnega zaupanja vključujejo:

• Delež privilegiranih računov, zaščitenih z MFA.
• Delež uporabnikov, zajetih s pogojnim dostopom.
• Število stalnih privilegiranih računov v primerjavi z računi za just-in-time dostop.
• Število zapadlih pregledov pravic dostopa.
• Delež končnih točk, skladnih z zahtevami glede stanja.
• Pokritost EDR na kritičnih sredstvih.
• Število zavrnjenih poskusov dostopa zaradi tveganja naprave ali lokacije.
• Povprečni čas do zaznave sumljive privilegirane dejavnosti.
• Povprečni čas do preklica dostopa po prenehanju zaposlitve ali sodelovanja.
• Delež pravil požarnega zidu med conami, pregledanih v zadnjem četrtletju.
• Število kritičnih dobaviteljev z aktualnimi varnostnimi dokazili.
• Število izjem ničelnega zaupanja po datumu odprave.
• Delež kritičnih aplikacij, ki pošiljajo dnevnike v SIEM.
• Rezultati simulacij incidentov za kompromitacijo poverilnic.

Ti kazalniki podpirajo nenehno izboljševanje po ISO/IEC 27001:2022, oceno učinkovitosti po NIS2, pričakovanja DORA glede testiranja in odprave pomanjkljivosti ter odgovornost po GDPR.

Pogoste napake pri dokazilih za ničelno zaupanje

Najpogostejše napake niso posledica pomanjkanja orodij. Povzroča jih šibka sledljivost.

Prvič, organizacije uvedejo MFA, vendar ne morejo dokazati, da so privilegirani računi v celoti zajeti. Storitveni računi, administratorski računi »break glass« in lokalni administratorski računi pogosto ostanejo zunaj kontrole.

Drugič, pregledi pravic dostopa se izvajajo ročno, vendar niso povezani s poslovnimi vlogami, občutljivostjo podatkov ali lastniki tveganj. Dokazila kažejo, da je nekdo kliknil »pregledano«, ne pa, da je bil nepotreben dostop odstranjen.

Tretjič, segmentacija omrežja obstaja v diagramih, ne pa v testiranih pravilih. Presojevalci bodo vprašali, ali je dostop med segmenti privzeto zavrnjen in ali so izjeme odobrene.

Četrtič, dnevniki se zbirajo, vendar niso uporabni za ukrepanje. SIEM brez opredeljenih primerov uporabe, triaže opozoril in postopkov odziva ne dokazuje stalnega spremljanja.

Petič, dostop dobaviteljev ni upravljan. Dobavitelji lahko uporabljajo skupne račune, trajen dostop VPN ali široke vloge v oblaku brez spremljanja sej.

Šestič, dokazila o zasebnosti so ločena od varnostnih dokazil. GDPR zahteva dokazljivo zaščito osebnih podatkov, zato morajo biti kontrole identitete in dostopa povezane s kategorijami podatkov in nameni obdelave.

Nazadnje, izjeme niso dokumentirane. Ničelno zaupanje lahko dopušča izjeme, če so predmet ocene tveganja, odobrene, časovno omejene in spremljane. Ne more pa dopuščati nevidnih izjem.

Zgradite svoj paket dokazil za ničelno zaupanje s Clarysec

Arhitektura ničelnega zaupanja v letu 2026 ni slogan. Je operativni model skladnosti, ki identiteto, naprave, aplikacije, segmentacijo omrežja, načelo najmanjših privilegijev, stalno spremljanje, nadzor dobaviteljev in varovala zasebnosti povezuje v en preverljiv sistem.

Če se pripravljate na certifikacijo ISO/IEC 27001:2022, odgovarjate na poizvedbe strank glede NIS2, se usklajujete z upravljanjem IKT-tveganj po DORA ali dokazujete varnost obdelave iz GDPR Article 32, začnite s sledljivostjo.

Uporabite Zenith Blueprint: An Auditor’s 30-Step Roadmap, da tveganja ničelnega zaupanja preslikate v register tveganj, načrt obravnave tveganj in SoA. Uporabite Zenith Controls: The Cross-Compliance Guide, da nadzor dostopa, upravljanje identitet in spremljanje uskladite z medokvirnimi pričakovanji. Uporabite knjižnico politik Clarysec, vključno z Enterprise Access Control Policy, Enterprise User Account and Privilege Management Policy, Enterprise Network Security Policy, Enterprise Logging and Monitoring Policy, Enterprise Information Security Policy in Data Protection and Privacy Policy - SME, da arhitekturo pretvorite v izvršljivo upravljanje.

Vaš naslednji praktični korak je izbrati en scenarij visokega tveganja, na primer kompromitiran privilegirani dostop do podatkov strank, in okoli njega zgraditi celotno verigo dokazil za ničelno zaupanje. Če lahko ta scenarij dokažete od začetka do konca, imate temelj za razširljiv, preverljiv in regulativno pripravljen program ničelnega zaupanja.

Prenesite pakete politik Clarysec ali se dogovorite za strateški klic, da preverite, kako lahko Zenith Blueprint in Zenith Controls pretvorita ničelno zaupanje iz revizijskega tveganja v prednost pri skladnosti.