Architektúra Zero Trust 2026: dôkazy pripravené na audit

Pondelkový ranný audit Zero Trust, ktorý nikto neplánoval

V pondelok o 08:12 dostane CISO európskej SaaS fintech spoločnosti v priebehu piatich minút tri správy.

Prvá je od bankového zákazníka: „Prosíme o poskytnutie balíka dôkazov k vašej architektúre Zero Trust pre naše ročné preverenie dodávateľa v oblasti IKT.“

Druhá je z právneho oddelenia: „V jednom členskom štáte môžeme byť podľa NIS2 klasifikovaní ako dôležitý subjekt a niektorí zákazníci sa pýtajú, či sa na nás ako poskytovateľa IKT služieb vzťahujú požiadavky DORA.“

Tretia je od vedúceho vývoja: „Máme MFA, SSO, EDR, sieťové politiky Kubernetes a upozornenia SIEM. Je to Zero Trust?“

Práve tu sa mnohé organizácie zaseknú. Majú bezpečnostné nástroje, ale nie prevádzkový model súladu pre Zero Trust. Vedia ukázať snímky obrazovky MFA, ale nevedia vysvetliť, ako do seba zapadajú identita, bezpečnostný stav zariadenia, zásada minimálnych oprávnení, segmentácia, monitorovanie, nahlasovanie incidentov, opatrenia na ochranu súkromia a závislosti od dodávateľov. Vedia ukázať kontroly, ale nie ich sledovateľnosť.

V roku 2026 musí byť architektúra Zero Trust založená na NIST SP 800-207 viac než len „nikdy nedôveruj, vždy overuj“. Pre CISO, manažérov súladu, audítorov a vlastníkov organizácie je praktická otázka presnejšia:

Ako premeniť Zero Trust na dôkazy, ktoré uspokoja ISO/IEC 27001:2022, očakávania NIS2 v oblasti kybernetickej hygieny, riadenie rizík IKT podľa DORA, bezpečnosť spracúvania podľa GDPR Article 32, zákaznícke due diligence a dohľad riadiaceho orgánu?

Odpoveďou nie je ďalší nástroj. Je ňou dôkazový model založený na riziku, ktorý prepája politiku, kontroly, technickú implementáciu, monitorovanie a zodpovednosť manažmentu.

Zero Trust v roku 2026: od bezpečnostnej stratégie k dôkazom súladu

NIST SP 800-207 definuje Zero Trust ako súbor princípov pre návrh a prevádzku bezpečných systémov, v ktorých dôvera nie je nikdy implicitná. Prístup sa udeľuje na základe identity, kontextu, politiky, bezpečnostného stavu aktíva a priebežného vyhodnocovania.

Sedem princípov Zero Trust podľa NIST je obzvlášť užitočných, pretože neurčitý bezpečnostný slogan premieňajú na niečo, čo možno mapovať, testovať a auditovať:

1. Všetky zdroje údajov a výpočtové služby sa považujú za zdroje.
2. Všetka komunikácia je zabezpečená bez ohľadu na sieťové umiestnenie.
3. Prístup k jednotlivým podnikovým zdrojom sa udeľuje na úrovni relácie.
4. Prístup k zdrojom určuje dynamická politika vrátane atribútov identity, zariadenia, aplikácie a správania.
5. Organizácia monitoruje a meria integritu a bezpečnostný stav všetkých vlastnených a pridružených aktív.
6. Autentifikácia a autorizácia všetkých zdrojov sú dynamické a prísne vynucované pred povolením prístupu.
7. Organizácia zhromažďuje informácie o aktívach, infraštruktúre a komunikácii a používa ich na zlepšovanie bezpečnostného stavu.

Pre moderného poskytovateľa SaaS, digitálnu banku, poskytovateľa riadených služieb alebo natívne cloudovú platformu sa tieto princípy premietajú do praktických oblastí kontrol:

• Identita sa overuje a riadi.
• Zariadenia sa posudzujú pred udelením prístupu.
• Privilegovaný prístup sa minimalizuje a preskúmava.
• Sieťové cesty sa segmentujú a riadia.
• Aplikácie, API a dátové úložiská vynucujú autorizáciu.
• Logy a telemetria podporujú priebežné monitorovanie.
• Incidenty spúšťajú zamedzenie šírenia, nahlasovanie a obnovu.
• Dôkazy preukazujú, že kontroly fungujú, nielen že boli navrhnuté.

Práve v poslednom bode vstupuje do hry súlad.

ISO/IEC 27001:2022 vyžaduje, aby organizácie definovali kontext, zainteresované strany, uplatniteľné právne a zmluvné požiadavky, rozsah, rozhrania a závislosti. Vyžaduje aj posúdenie rizík, ošetrenie rizík, vyhlásenie o aplikovateľnosti, zodpovednosť vedenia, interný audit, preskúmanie manažmentom a neustále zlepšovanie.

Zero Trust do tejto štruktúry prirodzene zapadá, ak sa k nemu pristupuje ako ku kontrolnému systému. Nemá stáť mimo ISMS ako výlučne technická iniciatíva. Má byť súčasťou posúdenia rizík, výberu kontrol, správy politík, riadenia dodávateľov, ochrany súkromia, reakcie na incidenty a reportovania riadiacemu orgánu.

Regulačný tlak na dôkazy Zero Trust

Tlak na dôkazy Zero Trust zvyčajne vyplýva z prekrývajúcich sa povinností, nie z jednej samostatnej normy.

NIS2 sa môže vzťahovať na verejné alebo súkromné subjekty v odvetviach prílohy I alebo prílohy II, ktoré spĺňajú veľkostné a činnostné prahové hodnoty, a môže sa vzťahovať aj na určité menšie, ale kritické subjekty. Príloha I zahŕňa poskytovateľov cloudových výpočtových služieb, poskytovateľov služieb dátových centier, poskytovateľov sietí na doručovanie obsahu, poskytovateľov dôveryhodných služieb, poskytovateľov riadených služieb, poskytovateľov riadených bezpečnostných služieb, bankové subjekty a subjekty infraštruktúry finančných trhov. Príloha II zahŕňa digitálnych poskytovateľov, ako sú online trhoviská, internetové vyhľadávače a platformy služieb sociálnych sietí.

NIS2 Article 20 robí z kybernetickej bezpečnosti zodpovednosť riadiaceho orgánu. Riadiaci orgán musí schvaľovať opatrenia riadenia rizík kybernetickej bezpečnosti, dohliadať na ich implementáciu a absolvovať školenie o kybernetickej bezpečnosti. Article 21 vyžaduje primerané a proporcionálne technické, prevádzkové a organizačné opatrenia pokrývajúce analýzu rizík, riešenie incidentov, kontinuitu činností, bezpečnosť dodávateľského reťazca, bezpečný vývoj, riešenie zraniteľností, posudzovanie účinnosti, kybernetickú hygienu, školenia, kryptografiu, personálnu bezpečnosť, riadenie prístupu, správu aktív a podľa potreby MFA alebo priebežnú autentifikáciu. Article 23 zavádza fázované nahlasovanie významných incidentov vrátane 24-hodinového včasného varovania, 72-hodinového oznámenia a záverečnej správy.

DORA sa uplatňuje od 17. januára 2025 a vytvára jednotný režim digitálnej prevádzkovej odolnosti pre finančné subjekty. Pokrýva riadenie rizík IKT, nahlasovanie závažných incidentov súvisiacich s IKT, testovanie digitálnej prevádzkovej odolnosti, zdieľanie informácií o hrozbách a riziko tretích strán v oblasti IKT. DORA Articles 5 and 6 vyžadujú správu a riadenie a zdokumentovaný rámec riadenia rizík IKT. Article 9 sa venuje ochrane a prevencii vrátane politík, postupov, protokolov a nástrojov na ochranu systémov IKT. Article 17 vyžaduje proces riadenia incidentov súvisiacich s IKT.

GDPR sa vzťahuje na spracúvanie v kontexte prevádzkarne v EÚ a aj na prevádzkovateľov alebo sprostredkovateľov mimo EÚ, ktorí ponúkajú tovar alebo služby jednotlivcom v EÚ alebo monitorujú ich správanie. GDPR Article 5 vyžaduje preukázateľnú zodpovednosť. Article 32 vyžaduje primerané technické a organizačné opatrenia na zabezpečenie úrovne bezpečnosti primeranej riziku. Article 33 vyžaduje oznámenie porušenia ochrany osobných údajov dozornému orgánu bez zbytočného odkladu a, ak je to možné, do 72 hodín od zistenia porušenia.

Dôkazový model Zero Trust pomáha preto, že rovnaká kontrola môže podporovať viacero rámcov. MFA môže podporiť riadenie prístupu podľa ISO/IEC 27001:2022, autentifikačné opatrenia podľa NIS2, požiadavky DORA na ochranu a bezpečnosť spracúvania podľa GDPR. Platí to však iba vtedy, ak organizácia vie preukázať rozsah, vlastníctvo, implementáciu, monitorovanie a preskúmanie.

Mapovanie princípov Zero Trust podľa NIST na kontroly ISO/IEC 27001:2022

Kontroly prílohy A ISO/IEC 27001:2022 podporené implementačnými usmerneniami ISO/IEC 27002:2022 poskytujú auditný jazyk, ktorý potrebuje väčšina organizácií. Nasledujúca tabuľka premieta princípy Zero Trust podľa NIST do oblastí kontrol ISO, ktoré audítori poznajú.

Toto mapovanie nie je iba technické návrhové cvičenie. Stáva sa štruktúrou pre register rizík, vyhlásenie o aplikovateľnosti, balík dôkazov a agendu preskúmania manažmentom.

Napríklad rizikový scenár „kompromitovaný účet vývojára mení produkčný kód a pristupuje k údajom zákazníkov“ by sa mal mapovať na správu identít, MFA, privilegovaný prístup, segregáciu sietí, logovanie, monitorovanie, bezpečný vývoj, riadenie zmien a reakciu na incidenty. Tento jediný scenár môže podporiť ISO/IEC 27001:2022, NIS2 Article 21, riadenie rizík IKT podľa DORA a GDPR Article 32.

Súbor kontrol Zero Trust spoločnosti Clarysec

Clarysec buduje Zero Trust okolo piatich dôkazových oblastí: identita, zariadenie, sieť, aplikácia a údaje, pričom monitorovanie a správa a riadenie prebiehajú naprieč všetkými piatimi oblasťami.

Základom je riadenie prístupu a správa identít. V dokumente Zenith Controls: The Cross-Compliance Guide je kontrola ISO/IEC 27002:2022 5.15, Riadenie prístupu, klasifikovaná ako preventívna kontrola podporujúca dôvernosť, integritu a dostupnosť, zosúladená s konceptom kybernetickej bezpečnosti Protect a schopnosťou správy identít a prístupu. Kontrola 5.16, Správa identít, je tiež preventívna a viaže sa na rovnaké vlastnosti CIA a schopnosť IAM. Kontrola 8.16, Monitorovacie činnosti, je klasifikovaná ako detekčná a nápravná, podporujúca Detect a Respond prostredníctvom riadenia udalostí informačnej bezpečnosti.

Na tejto kombinácii záleží. Zero Trust nie je iba riadenie prístupu. Je to riadenie prístupu plus životný cyklus identít plus bezpečnostný stav zariadenia plus segregácia sietí plus monitorovanie plus reakcia.

Ustanovenia politík Clarysec premieňajú tento model na vynútiteľnú správu a riadenie.

Z podnikovej Politiky riadenia prístupu, časť Ciele, bod 3.4:

Podporovať princípy nulovej dôvery tým, že prístup sa predvolene odmieta, pokiaľ nie je výslovne schválený a odôvodnený.

Z podnikovej Politiky správy používateľských účtov a oprávnení, časť Požiadavky na implementáciu politiky, bod 6.2.1:

Všetkým používateľom musí byť pridelená minimálna úroveň prístupu potrebná na vykonávanie ich pracovných úloh.

Z podnikovej Politiky bezpečnosti sietí, časť Požiadavky na správu a riadenie, bod 5.2:

Všetka prevádzka medzi zónami musí byť riadená firewallmi alebo softvérovo definovanými perimetrovými riešeniami s explicitnými konfiguráciami predvoleného zamietnutia.

Z podnikovej Politiky logovania a monitorovania, časť Ciele, bod 3.4:

Zaviesť centralizované systémy logovania a upozorňovania (napr. SIEM) na agregáciu, koreláciu a eskaláciu podozrivej aktivity takmer v reálnom čase.

Z podnikovej Politiky informačnej bezpečnosti, časť Požiadavky na implementáciu politiky, bod 6.6.1:

Všetky implementované kontroly musia byť vhodné na audit, podporené zdokumentovanými postupmi a uchovávanými dôkazmi o prevádzke.

Pre MSP možno rovnaký zámer správy a riadenia implementovať s jednoduchšou dokumentáciou politík. Politika správy používateľských účtov a oprávnení - MSP, časť Ciele, bod 3.2 uvádza:

Presadzovať zásadu minimálnych oprávnení tak, aby používatelia dostávali iba minimálnu úroveň prístupu potrebnú na plnenie svojich povinností.

Politika riadenia prístupu - MSP, časť Požiadavky na správu a riadenie, bod 5.4.3 dopĺňa:

Privilegované účty musia používať viacfaktorovú autentifikáciu (MFA), ak je podporovaná.

Politika bezpečnosti sietí - MSP, časť Požiadavky na implementáciu politiky, bod 6.2.3 uvádza:

Prevádzka medzi segmentmi musí byť filtrovaná a prístup medzi segmentmi sa musí riadiť zásadou minimálnych oprávnení.

Politika logovania a monitorovania - MSP, časť Účel, bod 1.3 vysvetľuje:

Logovanie a monitorovanie podporujú detekciu hrozieb, dodržiavanie predpisov, nahlasovanie a riadenie incidentov a forenznú analýzu.

Pre Zero Trust riadený ochranou súkromia Politika ochrany údajov a súkromia - MSP, časť Požiadavky na správu a riadenie, bod 5.3.2 uvádza:

Prístup používateľov k osobným údajom musí byť obmedzený na roly so zdokumentovanou prevádzkovou potrebou.

Tieto ustanovenia vytvárajú auditné kotvy. Audítor môže overiť, či je prístup predvolene odmietaný, oprávnenia minimalizované, prevádzka medzi zónami riadená, logy centralizované a dôkazy uchovávané.

Mapa dôkazov Zero Trust naprieč rámcami

Silný dôkazový model Zero Trust sa má vyhnúť roztriešteným snímkam obrazovky. Dôkazy majú preukazovať správu a riadenie, návrh, implementáciu, monitorovanie a preskúmanie.

Táto tabuľka je jadrom programu Zero Trust pripraveného pre riadiaci orgán. Ukazuje, ako môže jedno kontrolné prostredie podporiť viacero požiadaviek na uistenie bez vytvárania samostatných balíkov dôkazov pre každý rámec.

Použitie Zenith Blueprint na vytvorenie sledovateľnosti

Zenith Blueprint: An Auditor’s 30-Step Roadmap od Clarysec je navrhnutý tak, aby sa Zero Trust nestal nezdokumentovanou technickou filozofiou. Vo fáze Riadenie rizík, v kroku 13, Plánovanie ošetrenia rizík a vyhlásenie o aplikovateľnosti, vysvetľuje:

SoA je v skutočnosti prepájací dokument: spája vaše posúdenie/ošetrenie rizík so
skutočnými kontrolami, ktoré máte. Jeho vyplnením si zároveň overíte, či vám nechýbajú nejaké kontroly.

Ten istý krok odporúča mapovať kontroly na riziká, pridávať odkazy na kontroly prílohy A do položiek ošetrenia rizík a krížovo odkazovať na predpisy, ako sú GDPR, NIS2 alebo DORA, ak sa kontroly implementujú na splnenie týchto povinností.

Pre Zero Trust je to chýbajúci most. Ak sa audítor opýta, prečo ste implementovali podmienený prístup, odpoveď nemá znieť „pretože to hovorí Zero Trust“. Lepšia odpoveď je:

• Rizikový scenár je neoprávnený prístup k údajom zákazníkov prostredníctvom kompromitovaných poverení.
• Vlastníkom rizika je CTO alebo vedúci vývoja.
• Ošetrenie zahŕňa SSO, MFA, podmienený prístup, overenie bezpečnostného stavu koncových bodov, zásadu minimálnych oprávnení, segmentáciu a monitorovanie.
• SoA mapuje ošetrenie na riadenie prístupu, správu identít, logovanie, monitorovanie, kryptografiu, riadenie zraniteľností a správu cloudových služieb.
• To isté ošetrenie podporuje NIS2 Article 21, riadenie rizík IKT podľa DORA a GDPR Article 32.
• Dôkazy zahŕňajú ustanovenia politík, preskúmania prístupových práv, upozornenia SIEM, reporty bezpečnostného stavu EDR, pravidlá firewallu, exporty IAM, cvičenia incidentov a zápisnice z preskúmaní manažmentom.

Takto sa architektúra Zero Trust stáva pripravenou na audit.

Dôveryhodnosť koncových bodov, API a sieťová segregácia v praxi

Zero Trust často zlyháva, pretože organizácie sa sústreďujú na identitu a ignorujú kontext zariadenia, pracovnej záťaže, údajov a siete.

Krok 19 dokumentu Zenith Blueprint, Technologické kontrolné opatrenia I, jasne vysvetľuje požiadavku na bezpečnostný stav koncových bodov:

Prístup k informáciám prostredníctvom koncových bodov musí byť kontextový. Napríklad: spĺňa zariadenie
minimálne bezpečnostné štandardy pred prístupom k zdrojom spoločnosti? Prešlo nedávno
skenom na malvér? Pripája sa z nezvyčajnej lokality alebo siete? V súlade s princípmi
Zero Trust môže bezpečnostný stav koncového bodu vstupovať do podmieneného prístupu a odmietnuť vstup, kým
zariadenie nepreukáže, že je bezpečné.

Tým sa zariadenie stáva súčasťou autorizačného rozhodnutia. Platné heslo z nespravovaného notebooku sa nemá posudzovať rovnako ako platné prihlásenie z vyhovujúceho, šifrovaného a monitorovaného podnikového koncového bodu.

Ten istý krok zdôrazňuje, že obmedzenia prístupu sa vzťahujú na aplikácie, služby a API, nielen na používateľov:

Obmedzenia prístupu sa majú uplatňovať aj na aplikácie, služby a API, nielen na osoby.
Napríklad mikroslužba môže potrebovať iba prístup na čítanie k databázovej tabuľke, nie úplné práva CRUD.
Nástroj zálohovania môže potrebovať prístup iba ku konkrétnym vedrám cloudového úložiska, nie ku všetkým zdrojom tenantov.

Toto usmernenie je kritické pre natívne cloudové prostredia. Rozsahy API, servisné účty, identity pracovných záťaží, roly Kubernetes a cloudové politiky IAM sa musia riadiť zásadou minimálnych oprávnení. Ľudský prístup je iba jednou časťou kontrolnej plochy.

Krok 20 dokumentu Zenith Blueprint sa venuje segregácii sietí:

Segregácia je jedným z najstarších a najúčinnejších princípov kybernetickej bezpečnosti: obmedziť
šírenie, znížiť riziko a zadržať škodu. Kontrola 8.22 sa zameriava na sieťovú
segregáciu, teda na prax oddeľovania systémov, služieb a používateľov do rôznych logických alebo
fyzických zón s cieľom zabrániť neoprávnenému prístupu a obmedziť laterálny pohyb v prípade
kompromitácie.

Toto je kritické pre odolnosť podľa DORA a NIS2. Sieť Zero Trust má vychádzať z predpokladu, že jeden účet, pracovná záťaž alebo koncový bod môže byť kompromitovaný. Segmentácia bráni tomu, aby sa lokálna udalosť zmenila na systémový incident.

Desaťdňový balík dôkazov Zero Trust

Predstavte si SaaS fintech spoločnosť, ktorá bankám poskytuje analytiku podvodov. Spracúva osobné údaje, používa cloudovú infraštruktúru, spolieha sa na spravovaný Kubernetes, integruje sa so zákazníckymi API a používa poskytovateľa identít tretej strany. Zákazník požiada o dôkazy Zero Trust a spoločnosť má desať pracovných dní.

Praktický dôkazový sprint Clarysec by vyzeral takto.

Cieľom nie je predstierať, že organizácia dosiahla dokonalý Zero Trust za desať dní. Cieľom je vytvoriť obhájiteľný dôkazový reťazec pre najdôležitejšie riziká a preukázať, že program je riadený, merateľný a zlepšuje sa.

Ako budú rôzni audítori testovať Zero Trust

Bežnou chybou je pripraviť jeden technický príbeh a predpokladať, že každý audítor položí rovnaké otázky. Nepoloží.

Audítor ISO/IEC 27001:2022 bude hľadať systém manažérstva. Bude sa pýtať, či sú riziká Zero Trust zahrnuté v posúdení rizík, či sú ošetrenia schválené, či je SoA úplné, či sú politiky riadenými dokumentmi, či prebiehajú preskúmania prístupových práv, či interné audity testujú kontroly a či preskúmania manažmentom sledujú výkonnosť.

Posudzovateľ DORA sa opýta, či sú kontroly Zero Trust súčasťou zdokumentovaného rámca riadenia rizík IKT. Očakávať bude evidenciu aktív a závislostí, mapovanie kritických alebo dôležitých funkcií, klasifikáciu incidentov, eskaláciu na riadiaci orgán, testovanie, zmluvné požiadavky na tretie strany, práva na audit, stratégie ukončenia a sledovanie nápravných opatrení.

Posudzovateľ NIS2 sa zameria na zodpovednosť riadiaceho orgánu, opatrenia riadenia rizík kybernetickej bezpečnosti podľa Article 21 a pripravenosť na nahlasovanie incidentov podľa Article 23. Očakávať bude aj dôkazy, že sú riadené bezpečnosť dodávateľského reťazca, kontinuita činností, riešenie zraniteľností, riadenie prístupu a kybernetická hygiena.

Posudzovateľ GDPR alebo audítor ochrany súkromia sa opýta, či je prístup k osobným údajom nevyhnutný, zdokumentovaný, obmedzený, monitorovaný a zosúladený s účelmi spracúvania. Preskúma roly prevádzkovateľa a sprostredkovateľa, detekciu porušenia ochrany osobných údajov, prístup na základe rolí, šifrovanie, pseudonymizáciu tam, kde je vhodná, uchovávanie a preukázateľnú zodpovednosť.

Rovnaká kontrola môže zodpovedať viacero otázok, ale iba vtedy, ak sú dôkazy usporiadané.

Dodávatelia, cloud a riziko tretích strán v oblasti IKT

Zero Trust sa nekončí na firewalle a v cloudových prostrediach tradičná hranica firewallu nemusí existovať vôbec. Poskytovatelia identít, cloudové platformy, nástroje CI/CD, poskytovatelia riadenej detekcie, spracovatelia platieb, API brány a tímy outsourcovaného vývoja sa všetky stávajú súčasťou štruktúry dôvery.

NIS2 Article 21 výslovne zahŕňa bezpečnosť dodávateľského reťazca pre priamych dodávateľov a poskytovateľov služieb vrátane zraniteľností dodávateľov, odolnosti produktov a služieb, kybernetických bezpečnostných postupov dodávateľov a postupov bezpečného vývoja.

DORA vyžaduje, aby sa riziko tretích strán v oblasti IKT riadilo ako súčasť rámca riadenia rizík IKT, s registrom zmlúv o službách IKT, predzmluvným due diligence, posúdením kritickosti, rizikom koncentrácie, zmluvnými bezpečnostnými požiadavkami, asistenciou pri incidentoch, spoluprácou s orgánmi, právami na audit, právami na ukončenie, stratégiami ukončenia a plánmi prechodu.

Pre Zero Trust je praktické pravidlo jednoduché: nedôverujte dodávateľskému pripojeniu len preto, že je zmluvné. Vyžadujte technické kontroly a dôkazy.

Zákaznícka API integrácia má mať tokeny s vymedzeným rozsahom, obmedzenia rýchlosti požiadaviek, monitorovanie, rotáciu, vlastníctvo a revokáciu. Poskytovateľ riadených služieb má používať MFA, pomenované používateľské účty, zásadu minimálnych oprávnení, logovanie relácií a časovo obmedzený prístup. Vzťah s cloudovým poskytovateľom má zahŕňať mapovanie zdieľanej zodpovednosti, konfiguráciu šifrovania, uchovávanie logov, testovanie záloh a plánovanie ukončenia.

Preto dôkazy o dodávateľoch a cloude patria do modelu Zero Trust, nie do samostatného priečinka obstarávania.

Metriky, ktoré preukazujú, že Zero Trust funguje

Riadiace orgány a audítori nechcú iba architektonické diagramy. Chcú dôkazy o prevádzke a trendy zlepšovania.

Užitočné metriky Zero Trust zahŕňajú:

• Percento privilegovaných účtov chránených MFA.
• Percento používateľov pokrytých podmieneným prístupom.
• Počet trvalých privilegovaných účtov v porovnaní s účtami just-in-time.
• Počet oneskorených preskúmaní prístupových práv.
• Percento koncových bodov spĺňajúcich požiadavky na bezpečnostný stav.
• Pokrytie EDR naprieč kritickými aktívami.
• Počet odmietnutých pokusov o prístup z dôvodu rizika zariadenia alebo lokality.
• Priemerný čas do zistenia podozrivej privilegovanej aktivity.
• Priemerný čas do zrušenia prístupu po ukončení.
• Percento pravidiel firewallu medzi zónami preskúmaných za posledný štvrťrok.
• Počet kritických dodávateľov s aktuálnymi bezpečnostnými dôkazmi.
• Počet výnimiek Zero Trust po dátume nápravy.
• Percento kritických aplikácií odosielajúcich logy do SIEM.
• Výsledky simulácií incidentov pri kompromitácii poverení.

Tieto metriky podporujú neustále zlepšovanie podľa ISO/IEC 27001:2022, posudzovanie účinnosti podľa NIS2, očakávania DORA v oblasti testovania a nápravy a preukázateľnú zodpovednosť podľa GDPR.

Bežné zlyhania dôkazov Zero Trust

Najčastejšie zlyhania nespôsobuje nedostatok nástrojov. Spôsobuje ich slabá sledovateľnosť.

Po prvé, organizácie implementujú MFA, ale nevedia preukázať úplné pokrytie privilegovaných účtov. Servisné účty, núdzové účty („break glass“) a lokálne administrátorské účty často zostávajú mimo kontroly.

Po druhé, preskúmania prístupových práv sa vykonávajú manuálne, ale nie sú previazané s podnikovými rolami, citlivosťou údajov alebo vlastníkmi rizík. Dôkazy ukazujú, že niekto klikol na „preskúmané“, nie že bol odstránený nepotrebný prístup.

Po tretie, segmentácia siete existuje v diagramoch, ale nie v otestovaných pravidlách. Audítori sa budú pýtať, či je prístup medzi segmentmi predvolene odmietaný a či sú výnimky schválené.

Po štvrté, logy sa zhromažďujú, ale nie sú použiteľné na reakciu. SIEM bez definovaných prípadov použitia, triedenia upozornení a postupov reakcie nepreukazuje priebežné monitorovanie.

Po piate, prístup dodávateľov nie je riadený. Dodávatelia môžu používať zdieľané účty, trvalý VPN prístup alebo široké cloudové roly bez monitorovania relácií.

Po šieste, dôkazy ochrany súkromia sú oddelené od bezpečnostných dôkazov. GDPR vyžaduje preukázateľnú ochranu osobných údajov, preto sa kontroly identity a prístupu musia prepájať s kategóriami údajov a účelmi spracúvania.

Napokon, výnimky nie sú zdokumentované. Zero Trust môže tolerovať výnimky, ak sú posúdené z hľadiska rizika, schválené, časovo obmedzené a monitorované. Nemôže tolerovať neviditeľné výnimky.

Vytvorte svoj balík dôkazov Zero Trust s Clarysec

Architektúra Zero Trust v roku 2026 nie je slogan. Je to prevádzkový model súladu, ktorý prepája identitu, zariadenia, aplikácie, sieťovú segmentáciu, zásadu minimálnych oprávnení, priebežné monitorovanie, riadenie dodávateľov a ochranné opatrenia súkromia do jedného auditovateľného systému.

Ak sa pripravujete na certifikáciu ISO/IEC 27001:2022, odpovedáte na zákaznícke otázky k NIS2, zosúlaďujete sa s riadením rizík IKT podľa DORA alebo preukazujete bezpečnosť spracúvania podľa GDPR Article 32, začnite sledovateľnosťou.

Použite Zenith Blueprint: An Auditor’s 30-Step Roadmap na mapovanie rizík Zero Trust do vášho registra rizík, plánu ošetrenia rizík a SoA. Použite Zenith Controls: The Cross-Compliance Guide na zosúladenie riadenia prístupu, správy identít a monitorovania s očakávaniami naprieč rámcami. Použite knižnicu politík Clarysec vrátane podnikovej Politiky riadenia prístupu, podnikovej Politiky správy používateľských účtov a oprávnení, podnikovej Politiky bezpečnosti sietí, podnikovej Politiky logovania a monitorovania, podnikovej Politiky informačnej bezpečnosti a Politiky ochrany údajov a súkromia - MSP, aby ste architektúru premenili na vynútiteľnú správu a riadenie.

Vaším ďalším praktickým krokom je vybrať jeden vysokorizikový scenár, napríklad kompromitovaný privilegovaný prístup k údajom zákazníkov, a vybudovať okolo neho úplný dôkazový reťazec Zero Trust. Ak viete tento scenár preukázať od začiatku do konca, máte základ pre škálovateľný, auditovateľný program Zero Trust pripravený na regulačné preskúmanie.

Stiahnite si balíky politík Clarysec alebo si naplánujte strategický hovor a zistite, ako môžu Zenith Blueprint a Zenith Controls premeniť Zero Trust z auditného rizika na výhodu v oblasti súladu.