Architektura Zero Trust 2026: auditně připravené důkazy

Pondělní ranní audit Zero Trust, který nikdo neplánoval

V pondělí v 08:12 obdrží CISO evropské SaaS fintech společnosti během pěti minut tři zprávy.

První je od bankovního zákazníka: „Zašlete nám prosím balíček důkazů k vaší architektuře Zero Trust pro náš každoroční přezkum ICT třetích stran.“

Druhá je od právního oddělení: „V jednom členském státě můžeme být klasifikováni jako významný subjekt podle NIS2 a někteří zákazníci se ptají, zda se na nás jako poskytovatele ICT služeb nevztahují požadavky DORA.“

Třetí je od vedoucího vývoje: „Máme MFA, SSO, EDR, síťové politiky Kubernetes a upozornění SIEM. Je to Zero Trust?“

Právě zde se mnoho organizací zasekne. Mají bezpečnostní nástroje, ale nemají provozní model Zero Trust pro účely souladu. Mohou ukázat snímky obrazovky MFA, ale nedokážou vysvětlit, jak spolu souvisejí identita, bezpečnostní stav zařízení, zásada minimálních oprávnění, segmentace, monitorování, hlášení incidentů, ochranná opatření pro soukromí a závislosti na dodavatelích. Mohou ukázat opatření, ale ne dohledatelnost.

V roce 2026 musí být architektura Zero Trust založená na NIST SP 800-207 více než jen „nikdy nedůvěřuj, vždy ověřuj“. Pro CISO, manažery souladu, auditory a vlastníky společností je praktická otázka ostřejší:

Jak ze Zero Trust vytvořit důkazy, které obstojí vůči ISO/IEC 27001:2022, očekáváním NIS2 v oblasti kybernetické hygieny, řízení rizik v oblasti ICT podle DORA, zabezpečení zpracování podle GDPR Article 32, náležité péči zákazníků a dohledu orgánů dohledu?

Odpovědí není další nástroj. Je jí důkazní model založený na rizicích, který propojuje politiku, opatření, technickou implementaci, monitorování a odpovědnost vedení.

Zero Trust v roce 2026: od bezpečnostní strategie k důkazům souladu

NIST SP 800-207 definuje Zero Trust jako soubor principů pro návrh a provoz bezpečných systémů, ve kterých důvěra není nikdy implicitní. Přístup je udělován na základě identity, kontextu, politiky, bezpečnostního stavu aktiva a průběžného vyhodnocování.

Sedm principů Zero Trust podle NIST je obzvlášť užitečných, protože mění vágní bezpečnostní slogan v něco, co lze mapovat, testovat a auditovat:

1. Všechny zdroje dat a výpočetní služby jsou považovány za zdroje.
2. Veškerá komunikace je zabezpečena bez ohledu na umístění v síti.
3. Přístup k jednotlivým podnikovým zdrojům je udělován samostatně pro každou relaci.
4. Přístup ke zdrojům je určován dynamickou politikou, včetně atributů identity, zařízení, aplikace a chování.
5. Organizace monitoruje a měří integritu a bezpečnostní stav všech vlastněných a přidružených aktiv.
6. Autentizace a autorizace všech zdrojů jsou dynamické a před povolením přístupu striktně vynucované.
7. Organizace shromažďuje informace o aktivech, infrastruktuře a komunikaci a využívá je ke zlepšování bezpečnostního stavu.

Pro moderního poskytovatele SaaS, digitální banku, poskytovatele řízených služeb nebo cloud-native platformu se tyto principy převádějí do praktických domén opatření:

• Identita je ověřována a řízena.
• Zařízení jsou posuzována před udělením přístupu.
• Privilegovaný přístup je minimalizován a přezkoumáván.
• Síťové cesty jsou segmentovány a řízeny.
• Aplikace, rozhraní API a datová úložiště vynucují autorizaci.
• Logy a telemetrická data podporují průběžné monitorování.
• Incidenty spouštějí omezení šíření, hlášení a obnovu.
• Důkazy prokazují, že opatření fungují, nejen že byla navržena.

Právě poslední bod je místem, kde vstupuje do hry soulad.

ISO/IEC 27001:2022 vyžaduje, aby organizace definovaly kontext, zainteresované strany, použitelné právní a smluvní požadavky, rozsah, rozhraní a závislosti. Vyžaduje také posouzení rizik, ošetření rizik, Prohlášení o použitelnosti, odpovědnost vedení, interní audit, přezkoumání vedením a neustálé zlepšování.

Zero Trust do této struktury přirozeně zapadá, pokud je pojat jako systém opatření. Nemá stát mimo ISMS jako technická iniciativa. Má být součástí posouzení rizik, výběru opatření, správy politik, řízení dodavatelů, ochrany soukromí, reakce na incidenty a reportingu orgánům dohledu.

Regulační tlak na důkazy Zero Trust

Tlak na důkazy Zero Trust obvykle nevychází z jedné normy, ale z překrývajících se povinností.

NIS2 se může vztahovat na veřejné nebo soukromé subjekty v sektorech podle přílohy I nebo přílohy II, které splňují prahové hodnoty velikosti a činnosti, a může se vztahovat také na určité menší, ale kritické subjekty. Příloha I zahrnuje poskytovatele služeb cloud computingu, poskytovatele datových center, poskytovatele sítí pro doručování obsahu, poskytovatele služeb vytvářejících důvěru, poskytovatele řízených služeb, poskytovatele řízených bezpečnostních služeb, bankovní subjekty a subjekty infrastruktury finančních trhů. Příloha II zahrnuje digitální poskytovatele, jako jsou online tržiště, internetové vyhledávače a platformy sociálních sítí.

NIS2 Article 20 činí kybernetickou bezpečnost odpovědností řídicího orgánu. Řídicí orgán musí schvalovat opatření pro řízení kybernetických rizik, dohlížet na jejich implementaci a absolvovat školení v oblasti kybernetické bezpečnosti. Article 21 vyžaduje vhodná a přiměřená technická, provozní a organizační opatření zahrnující analýzu rizik, zvládání incidentů, kontinuitu činností, zabezpečení dodavatelského řetězce, bezpečný vývoj, řízení zranitelností, posuzování účinnosti, kybernetickou hygienu, školení, kryptografii, bezpečnost lidských zdrojů, řízení přístupu, správu aktiv a případně MFA nebo průběžnou autentizaci. Article 23 zavádí postupné hlášení významných incidentů, včetně včasného varování do 24 hodin, oznámení do 72 hodin a závěrečné zprávy.

DORA se použije od 17. ledna 2025 a vytváří jednotný režim digitální provozní odolnosti pro finanční subjekty. Pokrývá řízení rizik v oblasti ICT, hlášení závažných incidentů souvisejících s ICT, testování provozní odolnosti, sdílení informací o hrozbách a riziko třetích stran v oblasti ICT. DORA Articles 5 and 6 vyžadují správu a dokumentovaný rámec řízení rizik v oblasti ICT. Article 9 řeší ochranu a prevenci, včetně politik, postupů, protokolů a nástrojů k ochraně ICT systémů. Article 17 vyžaduje proces řízení incidentů souvisejících s ICT.

GDPR se vztahuje na zpracování v souvislosti s činnostmi provozovny v EU a také na správce nebo zpracovatele mimo EU, kteří nabízejí zboží nebo služby osobám v EU nebo monitorují jejich chování. GDPR Article 5 vyžaduje odpovědnost. Article 32 vyžaduje vhodná technická a organizační opatření k zajištění úrovně zabezpečení odpovídající riziku. Article 33 vyžaduje oznámení porušení zabezpečení osobních údajů dozorovému úřadu bez zbytečného odkladu a, je-li to proveditelné, do 72 hodin poté, co se o porušení dozví.

Důkazní model Zero Trust pomáhá, protože stejné opatření může podporovat více rámců. MFA může podporovat řízení přístupu podle ISO/IEC 27001:2022, autentizační opatření podle NIS2, požadavky ochrany podle DORA a zabezpečení zpracování podle GDPR. Pouze však tehdy, když organizace dokáže doložit rozsah, vlastnictví, implementaci, monitorování a přezkum.

Mapování principů Zero Trust podle NIST na opatření ISO/IEC 27001:2022

Opatření v příloze A ISO/IEC 27001:2022, podporovaná implementačními pokyny ISO/IEC 27002:2022, poskytují auditní jazyk, který většina organizací potřebuje. Níže uvedená tabulka převádí principy Zero Trust podle NIST do oblastí opatření ISO, které auditoři rozpoznávají.

Toto mapování není jen technické návrhové cvičení. Stává se strukturou pro registr rizik, Prohlášení o použitelnosti, balíček důkazů a agendu přezkoumání vedením.

Například rizikový scénář „kompromitovaný účet vývojáře upraví produkční kód a získá přístup k zákaznickým datům“ by měl být namapován na správu identit, MFA, privilegovaný přístup, oddělení sítí, protokolování, monitorování, bezpečný vývoj, řízení změn a reakci na incidenty. Tento jediný scénář může podporovat ISO/IEC 27001:2022, NIS2 Article 21, řízení rizik v oblasti ICT podle DORA a GDPR Article 32.

Clarysec Zero Trust Control Stack

Clarysec staví Zero Trust na pěti důkazních doménách: identita, zařízení, síť, aplikace a data, přičemž napříč všemi pěti probíhá monitorování a správa.

Základem je řízení přístupu a správa identit. V Zenith Controls: průvodce souladem napříč rámci je opatření ISO/IEC 27002:2022 5.15, řízení přístupu, klasifikováno jako preventivní opatření podporující důvěrnost, integritu a dostupnost, sladěné s konceptem kybernetické bezpečnosti Protect a schopností řízení identit a přístupů. Opatření 5.16, Správa identit, je také preventivní a navázané na stejné vlastnosti CIA a schopnost IAM. Opatření 8.16, Monitorovací činnosti, je klasifikováno jako detekční a nápravné a podporuje Detect a Respond prostřednictvím řízení bezpečnostních událostí informací.

Na této kombinaci záleží. Zero Trust není jen řízení přístupu. Je to řízení přístupu plus životní cyklus identity plus bezpečnostní stav zařízení plus oddělení sítí plus monitorování plus reakce.

Ustanovení politik Clarysec převádějí tento model do vymahatelné správy.

Z Podnikové politiky řízení přístupu, část Cíle, ustanovení 3.4:

Podporovat principy zero trust tím, že přístup bude ve výchozím nastavení odepřen, pokud není výslovně schválen a odůvodněn.

Z Podnikové politiky správy uživatelských účtů a oprávnění, část Požadavky na implementaci politiky, ustanovení 6.2.1:

Všem uživatelům musí být přidělena minimální úroveň přístupu nezbytná k výkonu jejich pracovních povinností.

Z Podnikové politiky zabezpečení sítí, část Požadavky na správu a řízení, ustanovení 5.2:

Veškerý provoz mezi zónami musí být řízen firewally nebo řešeními softwarově definovaného perimetru s výslovnou konfigurací implicitního zamítnutí.

Z Podnikové politiky protokolování a monitorování, část Cíle, ustanovení 3.4:

Zavést centralizované systémy protokolování a upozorňování (např. SIEM) pro agregaci, korelaci a eskalaci podezřelé aktivity téměř v reálném čase.

Z Podnikové politiky bezpečnosti informací, část Požadavky na implementaci politiky, ustanovení 6.6.1:

Všechna implementovaná opatření musí být auditovatelná, podložená dokumentovanými postupy a uchovávanými důkazy o jejich fungování.

Pro SME lze stejný záměr správy realizovat s lehčí dokumentací politik. Politika správy uživatelských účtů a oprávnění – SME, část Cíle, ustanovení 3.2 uvádí:

Vynucovat zásadu minimálních oprávnění a zajistit, aby uživatelům byla udělena pouze minimální úroveň přístupu nezbytná k plnění jejich povinností.

Politika řízení přístupu – SME, část Požadavky na správu a řízení, ustanovení 5.4.3 doplňuje:

Privilegované účty musí používat vícefaktorovou autentizaci (MFA), pokud je podporována.

Politika zabezpečení sítí – SME, část Požadavky na implementaci politiky, ustanovení 6.2.3 uvádí:

Provoz mezi segmenty musí být filtrován a přístup mezi segmenty musí dodržovat zásadu minimálních oprávnění.

Politika protokolování a monitorování – SME, část Účel, ustanovení 1.3 vysvětluje:

Protokolování a monitorování podporují detekci hrozeb, regulační soulad, hlášení a řízení incidentů a forenzní analýzu.

Pro Zero Trust řízený ochranou soukromí Politika ochrany dat a soukromí – SME, část Požadavky na správu a řízení, ustanovení 5.3.2 uvádí:

Přístup uživatelů k osobním údajům musí být omezen na role s dokumentovanou obchodní potřebou.

Tato ustanovení vytvářejí auditní kotvy. Auditor může ověřit, zda je přístup ve výchozím nastavení odepřen, oprávnění jsou minimalizována, provoz mezi zónami je řízen, logy jsou centralizovány a důkazy jsou uchovávány.

Mapa důkazů Zero Trust napříč rámci

Silný důkazní model Zero Trust by se měl vyhnout roztříštěným snímkům obrazovky. Důkazy mají ukazovat správu, návrh, implementaci, monitorování a přezkum.

Tato tabulka je jádrem programu Zero Trust připraveného pro orgány dohledu. Ukazuje, jak jedno prostředí opatření může podporovat více požadavků na ujištění, aniž by vznikaly samostatné balíčky důkazů pro každý rámec.

Použití Zenith Blueprint k vytvoření dohledatelnosti

Zenith Blueprint: 30krokový plán auditora od Clarysec je navržen tak, aby zabránil tomu, že se Zero Trust stane nedokumentovanou technickou filozofií. Ve fázi Řízení rizik, krok 13, Plánování ošetření rizik a Prohlášení o použitelnosti, vysvětluje:

SoA je ve skutečnosti propojovací dokument: propojuje vaše posouzení/ošetření rizik se
skutečnými opatřeními, která máte. Jeho dokončením si zároveň ověříte, zda jste některá opatření neopomenuli.

Tentýž krok doporučuje mapovat opatření na rizika, doplnit odkazy na opatření přílohy A do záznamů o ošetření rizik a křížově odkazovat na právní předpisy, jako jsou GDPR, NIS2 nebo DORA, pokud jsou opatření implementována za účelem splnění těchto povinností.

Pro Zero Trust jde o chybějící most. Pokud se auditor zeptá, proč jste implementovali podmíněný přístup, odpověď nemá znít „protože to říká Zero Trust“. Lepší odpověď je:

• Rizikový scénář je neoprávněný přístup k zákaznickým datům prostřednictvím kompromitovaných přihlašovacích údajů.
• Vlastníkem rizika je CTO nebo vedoucí vývoje.
• Ošetření zahrnuje SSO, MFA, podmíněný přístup, ověření bezpečnostního stavu koncových bodů, zásadu minimálních oprávnění, segmentaci a monitorování.
• SoA mapuje ošetření na řízení přístupu, správu identit, protokolování, monitorování, kryptografii, řízení zranitelností a správu cloudových služeb.
• Stejné ošetření podporuje NIS2 Article 21, řízení rizik v oblasti ICT podle DORA a GDPR Article 32.
• Důkazy zahrnují ustanovení politik, přezkumy přístupových práv, upozornění SIEM, reporty bezpečnostního stavu EDR, pravidla firewallu, exporty IAM, cvičení incidentů a zápisy z přezkoumání vedením.

Tak se architektura Zero Trust stává připravenou pro audit.

Důvěryhodnost koncových bodů, rozhraní API a oddělení sítí v praxi

Zero Trust často selhává, protože organizace se soustředí na identitu a ignorují kontext zařízení, pracovních zátěží, dat a sítě.

Zenith Blueprint krok 19, Technická opatření I, jasně vysvětluje požadavek na bezpečnostní stav koncových bodů:

Přístup k informacím prostřednictvím koncových bodů musí být kontextový. Například splňuje zařízení
minimální bezpečnostní standardy před přístupem k firemním zdrojům? Prošlo nedávno
kontrolou na malware? Připojuje se z neobvyklé lokality nebo sítě? V návaznosti na principy Zero
Trust může bezpečnostní stav koncového bodu vstupovat do podmíněného přístupu a odepřít vstup, dokud
zařízení neprokáže, že je bezpečné.

Tím se zařízení stává součástí autorizačního rozhodnutí. Platné heslo z nespravovaného notebooku se nemá posuzovat stejně jako platné přihlášení ze souladného, šifrovaného a monitorovaného firemního koncového bodu.

Tentýž krok zdůrazňuje, že omezení přístupu se vztahují na aplikace, služby a rozhraní API, nejen na uživatele:

Omezení přístupu by měla být uplatňována také na aplikace, služby a rozhraní API, nejen na osoby.
Například mikroslužba může potřebovat pouze čtecí přístup k databázové tabulce, nikoli plná práva CRUD.
Zálohovací nástroj může potřebovat přístup pouze ke konkrétním cloudovým úložištím, nikoli ke všem tenantovým zdrojům.

Toto doporučení je kritické pro cloud-native prostředí. Rozsahy API, servisní účty, identity pracovních zátěží, role Kubernetes a cloudové politiky IAM musí všechny dodržovat zásadu minimálních oprávnění. Lidský přístup je pouze jednou částí kontrolní plochy.

Krok 20 Zenith Blueprint se věnuje oddělení sítí:

Oddělení je jedním z nejstarších a nejúčinnějších principů kybernetické bezpečnosti: omezit
šíření, snížit riziko a zamezit škodám. Opatření 8.22 se zaměřuje na oddělení sítí,
tedy praxi oddělování systémů, služeb a uživatelů do různých logických nebo
fyzických zón s cílem zabránit neoprávněnému přístupu a omezit laterální pohyb v případě
kompromitace.

To je kritické pro odolnost podle DORA a NIS2. Síť Zero Trust má předpokládat, že jeden účet, pracovní zátěž nebo koncový bod mohou být kompromitovány. Segmentace brání tomu, aby se lokální událost změnila v systémový incident.

Desetidenní balíček důkazů Zero Trust

Představte si SaaS fintech společnost, která bankám poskytuje analytiku podvodů. Zpracovává osobní údaje, využívá cloudovou infrastrukturu, spoléhá na spravovaný Kubernetes, integruje se se zákaznickými rozhraními API a používá poskytovatele identit třetí strany. Zákazník požádá o důkazy Zero Trust a společnost má deset pracovních dnů.

Praktický důkazní sprint Clarysec by vypadal takto.

Cílem není předstírat, že organizace dosáhla dokonalého Zero Trust za deset dní. Cílem je vytvořit obhajitelný důkazní řetězec pro nejvýznamnější rizika a doložit, že program je řízený, měřitelný a zlepšuje se.

Jak různí auditoři testují Zero Trust

Častou chybou je připravit jeden technický příběh a předpokládat, že každý auditor položí stejné otázky. Nepoloží.

Auditor ISO/IEC 27001:2022 bude hledat systém řízení. Bude se ptát, zda jsou rizika Zero Trust zahrnuta v posouzení rizik, zda jsou ošetření schválena, zda je SoA kompletní, zda jsou politiky řízenými dokumenty, zda probíhá přezkum přístupových práv, zda interní audity testují opatření a zda přezkoumání vedením sleduje výkonnost.

Přezkoumávající osoba podle DORA se bude ptát, zda jsou opatření Zero Trust součástí dokumentovaného rámce řízení rizik v oblasti ICT. Bude očekávat evidence aktiv a závislostí, mapování kritických nebo důležitých funkcí, klasifikaci incidentů, eskalaci k řídicím orgánům, testování, požadavky smluv s třetími stranami, práva na audit, strategie ukončení a sledování nápravy.

Posuzovatel NIS2 se zaměří na odpovědnost řídicího orgánu, opatření řízení kybernetických rizik podle Article 21 a připravenost na hlášení incidentů podle Article 23. Bude také očekávat důkazy, že jsou řízeny zabezpečení dodavatelského řetězce, kontinuita činností, řízení zranitelností, řízení přístupu a kybernetická hygiena.

Přezkoumávající osoba podle GDPR nebo auditor ochrany soukromí se bude ptát, zda je přístup k osobním údajům nezbytný, zdokumentovaný, omezený, monitorovaný a sladěný s účely zpracování. Bude zkoumat role správce a zpracovatele, detekci porušení zabezpečení osobních údajů, přístup na základě rolí, šifrování, pseudonymizaci tam, kde je vhodná, uchovávání a odpovědnost.

Stejné opatření může zodpovědět více otázek, ale pouze tehdy, když jsou důkazy uspořádány.

Dodavatelé, cloud a riziko ICT třetích stran

Zero Trust nekončí na firewallu a v cloudových prostředích nemusí tradiční hranice firewallu existovat vůbec. Poskytovatelé identit, cloudové platformy, nástroje CI/CD, poskytovatelé řízené detekce, zpracovatelé plateb, API brány a outsourcované vývojové týmy se všechny stávají součástí struktury důvěry.

NIS2 Article 21 výslovně zahrnuje zabezpečení dodavatelského řetězce pro přímé dodavatele a poskytovatele služeb, včetně zranitelností dodavatelů, odolnosti produktů a služeb, postupů kybernetické bezpečnosti dodavatelů a postupů bezpečného vývoje.

DORA vyžaduje, aby bylo riziko třetích stran v oblasti ICT řízeno jako součást rámce řízení rizik v oblasti ICT, včetně registru smluv o ICT službách, předsmluvní náležité péče, posouzení kritičnosti, rizika koncentrace, smluvních bezpečnostních požadavků, podpory při incidentech, spolupráce s orgány, práv na audit, práv na ukončení, strategií ukončení a plánů přechodu.

Pro Zero Trust je praktické pravidlo jednoduché: nedůvěřujte dodavatelskému připojení jen proto, že je smluvní. Vyžadujte technická opatření a důkazy.

Integrace zákaznického API má mít tokeny s vymezeným rozsahem, limity četnosti požadavků, monitorování, rotaci, vlastnictví a revokaci. Poskytovatel řízených služeb má používat MFA, pojmenované uživatelské účty, zásadu minimálních oprávnění, protokolování relací a časově omezený přístup. Vztah s poskytovatelem cloudových služeb má zahrnovat mapování sdílené odpovědnosti, konfiguraci šifrování, uchovávání logů, testování záloh a plánování ukončení.

Proto důkazy o dodavatelích a cloudu patří do modelu Zero Trust, nikoli do samostatné složky pořizování.

Metriky, které prokazují, že Zero Trust funguje

Řídicí orgány a auditoři nechtějí pouze architektonické diagramy. Chtějí provozní důkazy a trendy zlepšování.

Užitečné metriky Zero Trust zahrnují:

• Procento privilegovaných účtů chráněných MFA.
• Procento uživatelů zahrnutých do podmíněného přístupu.
• Počet trvalých privilegovaných účtů ve srovnání s účty just-in-time.
• Počet opožděných přezkumů přístupových práv.
• Procento koncových bodů splňujících požadavky na bezpečnostní stav.
• Pokrytí EDR napříč kritickými aktivy.
• Počet odepřených pokusů o přístup z důvodu rizika zařízení nebo lokality.
• Průměrná doba do detekce podezřelé privilegované aktivity.
• Průměrná doba do odebrání přístupu po ukončení pracovního poměru nebo spolupráce.
• Procento pravidel firewallu mezi zónami přezkoumaných v posledním čtvrtletí.
• Počet kritických dodavatelů s aktuálními bezpečnostními důkazy.
• Počet výjimek ze Zero Trust po termínu nápravy.
• Procento kritických aplikací odesílajících logy do SIEM.
• Výsledky simulací incidentů pro kompromitaci přihlašovacích údajů.

Tyto metriky podporují neustálé zlepšování podle ISO/IEC 27001:2022, posouzení účinnosti podle NIS2, očekávání DORA v oblasti testování a nápravy a odpovědnost podle GDPR.

Častá selhání důkazů Zero Trust

Nejčastější selhání nejsou způsobena nedostatkem nástrojů. Jsou způsobena slabou dohledatelností.

Za prvé, organizace implementují MFA, ale nedokážou doložit plné pokrytí privilegovaných účtů. Servisní účty, účty nouzového přístupu „break-glass“ a místní administrátorské účty často zůstávají mimo opatření.

Za druhé, přezkum přístupových práv se provádí manuálně, ale není navázán na obchodní role, citlivost dat nebo vlastníky rizik. Důkaz ukazuje, že někdo klikl na „přezkoumáno“, nikoli že byl odstraněn zbytečný přístup.

Za třetí, segmentace sítě existuje v diagramech, ale ne v otestovaných pravidlech. Auditoři se zeptají, zda je přístup mezi segmenty ve výchozím nastavení odepřen a zda jsou výjimky schváleny.

Za čtvrté, logy jsou shromažďovány, ale nejsou akční. SIEM bez definovaných use case, triáže upozornění a postupů reakce neprokazuje průběžné monitorování.

Za páté, přístup dodavatelů není řízen. Dodavatelé mohou používat sdílené účty, trvalý VPN přístup nebo široké cloudové role bez monitorování relací.

Za šesté, důkazy o ochraně soukromí jsou odděleny od bezpečnostních důkazů. GDPR vyžaduje prokazatelnou ochranu osobních údajů, takže opatření identity a přístupu musí být propojena s kategoriemi dat a účely zpracování.

Nakonec, výjimky nejsou dokumentovány. Zero Trust může tolerovat výjimky, pokud jsou posouzeny z hlediska rizik, schváleny, časově omezeny a monitorovány. Nemůže tolerovat neviditelné výjimky.

Vytvořte svůj balíček důkazů Zero Trust s Clarysec

Architektura Zero Trust v roce 2026 není slogan. Je to provozní model souladu, který propojuje identitu, zařízení, aplikace, segmentaci sítě, zásadu minimálních oprávnění, průběžné monitorování, kontrolu dodavatelů a ochranná opatření pro soukromí do jednoho auditovatelného systému.

Pokud se připravujete na certifikaci ISO/IEC 27001:2022, odpovídáte na zákaznické dotazy k NIS2, slaďujete se s řízením rizik v oblasti ICT podle DORA nebo prokazujete zabezpečení zpracování podle GDPR Article 32, začněte dohledatelností.

Použijte Zenith Blueprint: 30krokový plán auditora k namapování rizik Zero Trust do svého registru rizik, plánu ošetření rizik a SoA. Použijte Zenith Controls: průvodce souladem napříč rámci ke sladění řízení přístupu, správy identit a monitorování s očekáváními napříč rámci. Použijte knihovnu politik Clarysec, včetně Podnikové politiky řízení přístupu, Podnikové politiky správy uživatelských účtů a oprávnění, Podnikové politiky zabezpečení sítí, Podnikové politiky protokolování a monitorování, Podnikové politiky bezpečnosti informací a Politiky ochrany dat a soukromí – SME, abyste architekturu převedli na vymahatelnou správu.

Vaším dalším praktickým krokem je vybrat jeden vysoce rizikový scénář, například kompromitovaný privilegovaný přístup k zákaznickým datům, a vybudovat kolem něj kompletní důkazní řetězec Zero Trust. Pokud dokážete tento scénář prokázat od začátku do konce, máte základ pro škálovatelný, auditovatelný a na regulaci připravený program Zero Trust.

Stáhněte si balíčky politik Clarysec nebo si naplánujte strategickou konzultaci a zjistěte, jak mohou Zenith Blueprint a Zenith Controls proměnit Zero Trust z auditního rizika v konkurenční výhodu v oblasti souladu.