Zero Trust Architecture 2026: dowody gotowe do audytu

Poniedziałkowy audyt Zero Trust, którego nikt nie planował

W poniedziałek o 08:12 CISO europejskiego fintechu SaaS otrzymuje w ciągu pięciu minut trzy wiadomości.

Pierwsza pochodzi od klienta bankowego: „Prosimy o przekazanie pakietu dowodów dotyczących Zero Trust Architecture na potrzeby naszego corocznego przeglądu zewnętrznego dostawcy ICT”.

Druga pochodzi z działu prawnego: „Możemy zostać zaklasyfikowani jako podmiot ważny w rozumieniu NIS2 w jednym państwie członkowskim, a część klientów pyta, czy wymagania DORA przechodzą na nas jako dostawcę usług ICT”.

Trzecia pochodzi od szefa inżynierii: „Mamy MFA, SSO, EDR, polityki sieciowe Kubernetes i alerty SIEM. Czy to jest Zero Trust?”.

W tym miejscu wiele organizacji napotyka problem. Mają narzędzia bezpieczeństwa, ale nie mają operacyjnego modelu zgodności dla Zero Trust. Mogą pokazać zrzuty ekranu z MFA, ale nie potrafią wyjaśnić, jak łączą się tożsamość, stan bezpieczeństwa urządzenia, zasada najmniejszych uprawnień, segmentacja, monitorowanie, zgłaszanie incydentów, środki ochrony prywatności oraz zależności od dostawców. Mogą pokazać środki kontrolne, ale nie ich identyfikowalność.

W 2026 roku Zero Trust Architecture oparta na NIST SP 800-207 musi oznaczać więcej niż „nigdy nie ufaj, zawsze weryfikuj”. Dla CISO, menedżerów zgodności, audytorów i właścicieli biznesowych praktyczne pytanie jest bardziej konkretne:

Jak przekształcić Zero Trust w dowody spełniające ISO/IEC 27001:2022, oczekiwania NIS2 dotyczące cyberhigieny, zarządzanie ryzykiem ICT według DORA, bezpieczeństwo przetwarzania z GDPR Article 32, due diligence klientów oraz nadzór zarządu?

Odpowiedzią nie jest kolejne narzędzie. Jest nią oparty na ryzyku model dowodowy, który łączy polityki, środki kontrolne, wdrożenie techniczne, monitorowanie oraz rozliczalność kierownictwa.

Zero Trust w 2026 roku: od strategii bezpieczeństwa do dowodów zgodności

NIST SP 800-207 definiuje Zero Trust jako zestaw zasad projektowania i eksploatacji bezpiecznych systemów, w których zaufanie nigdy nie jest domyślne. Dostęp jest nadawany na podstawie tożsamości, kontekstu, polityki, stanu aktywów oraz ciągłej oceny.

Siedem założeń Zero Trust według NIST jest szczególnie użytecznych, ponieważ przekształca ogólne hasło bezpieczeństwa w coś, co można zmapować, przetestować i poddać audytowi:

1. Wszystkie źródła danych i usługi obliczeniowe są traktowane jako zasoby.
2. Cała komunikacja jest zabezpieczona niezależnie od lokalizacji sieciowej.
3. Dostęp do poszczególnych zasobów organizacji jest nadawany oddzielnie dla każdej sesji.
4. Dostęp do zasobów jest określany przez dynamiczną politykę obejmującą atrybuty tożsamości, urządzenia, aplikacji i zachowania.
5. Organizacja monitoruje i mierzy integralność oraz profil ryzyka bezpieczeństwa wszystkich własnych i powiązanych aktywów.
6. Uwierzytelnianie i autoryzacja wszystkich zasobów są dynamiczne i rygorystycznie egzekwowane przed dopuszczeniem dostępu.
7. Organizacja gromadzi informacje o aktywach, infrastrukturze i komunikacji, a następnie wykorzystuje je do poprawy profilu ryzyka bezpieczeństwa.

Dla nowoczesnego dostawcy SaaS, banku cyfrowego, dostawcy usług zarządzanych albo platformy natywnej dla chmury obliczeniowej zasady te przekładają się na praktyczne obszary kontroli:

• Tożsamość jest weryfikowana i objęta nadzorem.
• Urządzenia są oceniane przed nadaniem dostępu.
• Dostęp uprzywilejowany jest minimalizowany i poddawany przeglądom.
• Ścieżki sieciowe są segmentowane i kontrolowane.
• Aplikacje, interfejsy API i magazyny danych egzekwują autoryzację.
• Logi i telemetria wspierają ciągłe monitorowanie.
• Incydenty uruchamiają powstrzymanie, zgłaszanie i odtwarzanie.
• Dowody potwierdzają, że środki kontrolne działają, a nie tylko zostały zaprojektowane.

Ten ostatni punkt jest miejscem, w którym zaczyna się zgodność.

ISO/IEC 27001:2022 wymaga od organizacji zdefiniowania kontekstu, stron zainteresowanych, mających zastosowanie wymagań prawnych i umownych, zakresu, interfejsów oraz zależności. Wymaga także oceny ryzyka, postępowania z ryzykiem, Deklaracji stosowania, rozliczalności kierownictwa, audytu wewnętrznego, przeglądu zarządzania oraz ciągłego doskonalenia.

Zero Trust naturalnie wpisuje się w tę strukturę, jeżeli jest traktowane jako system kontroli. Nie powinno funkcjonować poza SZBI jako inicjatywa inżynieryjna. Powinno stanowić część oceny ryzyka, doboru środków kontrolnych, zarządzania politykami, zarządzania dostawcami, ochrony prywatności, reagowania na incydenty i raportowania do zarządu.

Presja regulacyjna stojąca za dowodami Zero Trust

Presja na dowody dotyczące Zero Trust zwykle wynika z nakładających się obowiązków, a nie z jednej normy.

NIS2 może mieć zastosowanie do podmiotów publicznych lub prywatnych z sektorów wskazanych w załączniku I lub załączniku II, które spełniają progi wielkości i działalności, a także do określonych mniejszych, lecz krytycznych podmiotów. Załącznik I obejmuje dostawców usług chmury obliczeniowej, dostawców centrów danych, dostawców sieci dostarczania treści, dostawców usług zaufania, dostawców usług zarządzanych, dostawców zarządzanych usług bezpieczeństwa, banki oraz podmioty infrastruktury rynków finansowych. Załącznik II obejmuje dostawców cyfrowych, takich jak internetowe platformy handlowe, wyszukiwarki i platformy społecznościowe.

NIS2 Article 20 czyni cyberbezpieczeństwo odpowiedzialnością organu zarządzającego. Zarząd musi zatwierdzać środki zarządzania ryzykiem cyberbezpieczeństwa, nadzorować ich wdrożenie oraz odbywać szkolenia z cyberbezpieczeństwa. Article 21 wymaga odpowiednich i proporcjonalnych środków technicznych, operacyjnych i organizacyjnych obejmujących analizę ryzyka, obsługę incydentów, ciągłość działania, bezpieczeństwo łańcucha dostaw, bezpieczny rozwój oprogramowania, obsługę podatności, ocenę skuteczności, cyberhigienę, szkolenia, kryptografię, bezpieczeństwo HR, kontrolę dostępu, zarządzanie aktywami oraz, w stosownych przypadkach, MFA lub ciągłe uwierzytelnianie. Article 23 wprowadza etapowe zgłaszanie istotnych incydentów, w tym wczesne ostrzeżenie w ciągu 24 godzin, zgłoszenie w ciągu 72 godzin oraz raport końcowy.

DORA obowiązuje od 17 stycznia 2025 r. i ustanawia jednolity reżim cyfrowej odporności operacyjnej dla podmiotów finansowych. Obejmuje zarządzanie ryzykiem ICT, zgłaszanie poważnych incydentów związanych z ICT, testowanie odporności operacyjnej, wymianę informacji o zagrożeniach oraz ryzyko związane z zewnętrznymi dostawcami ICT. DORA Articles 5 i 6 wymagają ładu zarządczego oraz udokumentowanych ram zarządzania ryzykiem ICT. Article 9 dotyczy ochrony i zapobiegania, w tym polityk, procedur, protokołów i narzędzi służących ochronie systemów ICT. Article 17 wymaga procesu zarządzania incydentami związanymi z ICT.

GDPR ma zastosowanie do przetwarzania w kontekście jednostki organizacyjnej w UE, a także do administratorów lub podmiotów przetwarzających spoza UE, którzy oferują towary lub usługi osobom fizycznym w UE albo monitorują ich zachowanie. GDPR Article 5 wymaga rozliczalności. Article 32 wymaga odpowiednich środków technicznych i organizacyjnych zapewniających poziom bezpieczeństwa odpowiedni do ryzyka. Article 33 wymaga zgłoszenia naruszenia ochrony danych osobowych organowi nadzorczemu bez zbędnej zwłoki oraz, jeżeli jest to wykonalne, w ciągu 72 godzin od stwierdzenia naruszenia.

Model dowodowy Zero Trust pomaga, ponieważ ten sam środek kontrolny może wspierać wiele ram. MFA może wspierać kontrolę dostępu w ISO/IEC 27001:2022, środki uwierzytelniania w NIS2, wymagania ochronne DORA oraz bezpieczeństwo przetwarzania według GDPR. Jest to jednak możliwe tylko wtedy, gdy organizacja potrafi wykazać zakres, właścicielstwo, wdrożenie, monitorowanie i przegląd.

Mapowanie założeń NIST Zero Trust na środki kontrolne ISO/IEC 27001:2022

Środki kontrolne z załącznika A do ISO/IEC 27001:2022, wspierane przez wytyczne wdrożeniowe ISO/IEC 27002:2022, dostarczają języka audytowego potrzebnego większości organizacji. Poniższa tabela przekłada założenia NIST Zero Trust na obszary środków kontrolnych ISO rozpoznawane przez audytorów.

To mapowanie nie jest wyłącznie ćwiczeniem z projektowania technicznego. Staje się strukturą dla rejestru ryzyk, Deklaracji stosowania, pakietu dowodowego oraz agendy przeglądu zarządzania.

Przykładowo scenariusz ryzyka „naruszone konto programisty modyfikuje kod produkcyjny i uzyskuje dostęp do danych klientów” powinien zostać zmapowany na zarządzanie tożsamością, MFA, dostęp uprzywilejowany, segregację sieci, rejestrowanie, monitorowanie, bezpieczny rozwój oprogramowania, zarządzanie zmianami oraz reagowanie na incydenty. Ten jeden scenariusz może wspierać ISO/IEC 27001:2022, NIS2 Article 21, zarządzanie ryzykiem ICT według DORA oraz GDPR Article 32.

Stos środków kontrolnych Clarysec dla Zero Trust

Clarysec buduje Zero Trust wokół pięciu domen dowodowych: tożsamości, urządzeń, sieci, aplikacji i danych, z monitorowaniem i ładem zarządczym obejmującymi wszystkie pięć domen.

Fundamentem są kontrola dostępu i zarządzanie tożsamością. W Zenith Controls: The Cross-Compliance Guide środek kontrolny 5.15 z ISO/IEC 27002:2022, Kontrola dostępu, jest klasyfikowany jako kontrola zapobiegawcza wspierająca poufność, integralność i dostępność, dostosowana do koncepcji cyberbezpieczeństwa Protect oraz zdolności Identity and Access Management. Środek kontrolny 5.16, Zarządzanie tożsamością, również ma charakter zapobiegawczy i jest powiązany z tymi samymi właściwościami CIA oraz zdolnością IAM. Środek kontrolny 8.16, Monitorowanie działań, jest klasyfikowany jako detekcyjny i korygujący, wspierający Detect i Respond poprzez zarządzanie zdarzeniami bezpieczeństwa informacji.

To połączenie ma znaczenie. Zero Trust nie jest samą kontrolą dostępu. To kontrola dostępu połączona z cyklem życia tożsamości, stanem bezpieczeństwa urządzeń, segregacją sieci, monitorowaniem i reakcją.

Klauzule polityk Clarysec przekształcają ten model w egzekwowalny ład zarządczy.

Z Enterprise Access Control Policy, sekcja Cele, klauzula 3.4:

Wspieranie zasad zero trust poprzez domyślne odmawianie dostępu, chyba że został on jednoznacznie zatwierdzony i uzasadniony.

Z Enterprise User Account and Privilege Management Policy, sekcja Wymagania dotyczące wdrożenia polityki, klauzula 6.2.1:

Wszystkim użytkownikom należy przypisać minimalny poziom dostępu niezbędny do wykonywania ich obowiązków służbowych.

Z Enterprise Network Security Policy, sekcja Wymagania dotyczące ładu zarządczego, klauzula 5.2:

Cały ruch między strefami musi być kontrolowany przez zapory sieciowe lub rozwiązania typu software-defined perimeter, z jawnymi konfiguracjami domyślnej odmowy.

Z Enterprise Logging and Monitoring Policy, sekcja Cele, klauzula 3.4:

Ustanowić scentralizowane systemy rejestrowania i alertowania, np. SIEM, w celu agregowania, korelowania i eskalowania podejrzanej aktywności w czasie zbliżonym do rzeczywistego.

Z Enterprise Information Security Policy, sekcja Wymagania dotyczące wdrożenia polityki, klauzula 6.6.1:

Wszystkie wdrożone środki kontrolne muszą być audytowalnie identyfikowalne, wspierane udokumentowanymi procedurami oraz zachowanymi dowodami ich działania.

W przypadku MŚP ten sam cel ładu zarządczego można wdrożyć przy lżejszej dokumentacji polityk. User Account and Privilege Management Policy - SME, sekcja Cele, klauzula 3.2 stanowi:

Egzekwować zasadę najmniejszych uprawnień, zapewniając, że użytkownicy otrzymują wyłącznie minimalny poziom dostępu niezbędny do wykonywania swoich obowiązków.

Access Control Policy - SME, sekcja Wymagania dotyczące ładu zarządczego, klauzula 5.4.3 dodaje:

Konta uprzywilejowane muszą korzystać z uwierzytelniania wieloskładnikowego (MFA), jeżeli jest obsługiwane.

Network Security Policy - SME, sekcja Wymagania dotyczące wdrożenia polityki, klauzula 6.2.3 stanowi:

Ruch między segmentami musi być filtrowany, a dostęp między segmentami musi być zgodny z zasadą najmniejszych uprawnień.

Logging and Monitoring Policy - SME, sekcja Cel, klauzula 1.3 wyjaśnia:

Rejestrowanie i monitorowanie wspierają wykrywanie zagrożeń, zgodność regulacyjną, zgłaszanie incydentów i zarządzanie nimi oraz analizę kryminalistyczną.

W przypadku Zero Trust ukierunkowanego na prywatność Data Protection and Privacy Policy - SME, sekcja Wymagania dotyczące ładu zarządczego, klauzula 5.3.2 stanowi:

Dostęp użytkowników do danych osobowych musi być ograniczony do ról, dla których udokumentowano biznesową potrzebę dostępu.

Klauzule te tworzą punkty zaczepienia dla audytu. Audytor może sprawdzić, czy dostęp jest domyślnie odmawiany, uprawnienia są minimalizowane, ruch między strefami jest kontrolowany, logi są centralizowane, a dowody zachowywane.

Międzyramowa mapa dowodów Zero Trust

Silny model dowodowy Zero Trust powinien unikać rozproszonych zrzutów ekranu. Dowody powinny pokazywać ład zarządczy, projekt, wdrożenie, monitorowanie i przegląd.

Ta tabela stanowi rdzeń programu Zero Trust gotowego dla zarządu. Pokazuje, jak jedno środowisko kontrolne może wspierać wiele potrzeb atestacyjnych bez tworzenia osobnych pakietów dowodowych dla każdej ramy.

Wykorzystanie Zenith Blueprint do zapewnienia identyfikowalności

Zenith Blueprint: An Auditor’s 30-Step Roadmap firmy Clarysec zaprojektowano po to, aby Zero Trust nie stało się nieudokumentowaną filozofią inżynieryjną. W fazie zarządzania ryzykiem, krok 13, Planowanie postępowania z ryzykiem i Deklaracja stosowania, wyjaśnia:

SoA jest w praktyce dokumentem pomostowym: łączy ocenę ryzyka i postępowanie z ryzykiem z
faktycznie posiadanymi środkami kontrolnymi. Wypełniając ją, dodatkowo sprawdzasz, czy nie pominięto żadnych środków kontrolnych.

Ten sam krok zaleca mapowanie środków kontrolnych na ryzyka, dodawanie odniesień do środków kontrolnych z załącznika A w pozycjach postępowania z ryzykiem oraz krzyżowe odwoływanie się do regulacji takich jak GDPR, NIS2 lub DORA, gdy środki kontrolne są wdrażane w celu spełnienia tych obowiązków.

Dla Zero Trust jest to brakujący pomost. Jeżeli audytor zapyta, dlaczego wdrożono dostęp warunkowy, odpowiedź nie powinna brzmieć: „bo tak mówi Zero Trust”. Lepsza odpowiedź to:

• Scenariuszem ryzyka jest nieuprawniony dostęp do danych klientów z wykorzystaniem naruszonych danych uwierzytelniających.
• Właścicielem ryzyka jest CTO lub szef inżynierii.
• Postępowanie z ryzykiem obejmuje SSO, MFA, dostęp warunkowy, walidację stanu bezpieczeństwa punktów końcowych, zasadę najmniejszych uprawnień, segmentację i monitorowanie.
• SoA mapuje postępowanie z ryzykiem na kontrolę dostępu, zarządzanie tożsamością, rejestrowanie, monitorowanie, kryptografię, zarządzanie podatnościami i zarządzanie usługami chmurowymi.
• To samo postępowanie wspiera NIS2 Article 21, zarządzanie ryzykiem ICT według DORA oraz GDPR Article 32.
• Dowody obejmują klauzule polityk, przeglądy dostępu, alerty SIEM, raporty EDR dotyczące stanu bezpieczeństwa, reguły zapory sieciowej, eksporty IAM, ćwiczenia incydentowe i protokoły z przeglądów zarządzania.

Tak właśnie Zero Trust Architecture staje się gotowa do audytu.

Zaufanie do punktów końcowych, interfejsy API i segregacja sieci w praktyce

Zero Trust często zawodzi, ponieważ organizacje koncentrują się na tożsamości, ignorując kontekst urządzenia, obciążenia, danych i sieci.

Zenith Blueprint krok 19, Zabezpieczenia techniczne I, jasno wyjaśnia wymóg dotyczący stanu bezpieczeństwa punktów końcowych:

Dostęp do informacji przez punkty końcowe musi być kontekstowy. Przykładowo: czy urządzenie
spełnia minimalne standardy bezpieczeństwa przed uzyskaniem dostępu do zasobów organizacji? Czy niedawno
przeszło skanowanie pod kątem złośliwego oprogramowania? Czy łączy się z nietypowej lokalizacji albo sieci? Integracja z zasadami Zero
Trust pozwala wykorzystać stan bezpieczeństwa punktu końcowego w dostępie warunkowym i odmówić wejścia do czasu, aż
urządzenie potwierdzi, że jest bezpieczne.

To czyni urządzenie częścią decyzji autoryzacyjnej. Poprawne hasło użyte z niezarządzanego laptopa nie powinno być traktowane tak samo jak poprawne logowanie ze zgodnego, szyfrowanego i monitorowanego korporacyjnego punktu końcowego.

Ten sam krok podkreśla, że ograniczenia dostępu mają zastosowanie do aplikacji, usług i interfejsów API, a nie tylko do użytkowników:

Ograniczenia dostępu powinny być stosowane także do aplikacji, usług i interfejsów API, a nie wyłącznie do ludzi.
Przykładowo mikrousługa może potrzebować jedynie dostępu do odczytu do tabeli bazy danych, a nie pełnych uprawnień CRUD.
Narzędzie do tworzenia kopii zapasowych może potrzebować dostępu tylko do konkretnych zasobników pamięci masowej, a nie do wszystkich zasobów dzierżawcy.

Wytyczna ta jest krytyczna dla środowisk natywnych dla chmury obliczeniowej. Zakresy API, konta serwisowe, tożsamości obciążeń, role Kubernetes i polityki IAM w chmurze obliczeniowej muszą być zgodne z zasadą najmniejszych uprawnień. Dostęp ludzi jest tylko jedną częścią powierzchni kontrolnej.

Krok 20 Zenith Blueprint dotyczy segregacji sieci:

Segregacja jest jedną z najstarszych i najskuteczniejszych zasad cyberbezpieczeństwa: ogranicz
rozprzestrzenianie, zmniejsz ryzyko i powstrzymaj szkody. Środek kontrolny 8.22 koncentruje się na segregacji
sieci, czyli praktyce rozdzielania systemów, usług i użytkowników między różne strefy logiczne lub
fizyczne w celu zapobiegania nieuprawnionemu dostępowi i ograniczania ruchu lateralnego w przypadku
naruszenia bezpieczeństwa.

Ma to kluczowe znaczenie dla odporności DORA i NIS2. Sieć Zero Trust powinna zakładać, że jedno konto, obciążenie lub punkt końcowy może zostać naruszone. Segmentacja zapobiega przekształceniu lokalnego zdarzenia w incydent systemowy.

Dziesięciodniowy pakiet dowodowy Zero Trust

Wyobraźmy sobie fintech SaaS, który dostarcza bankom analitykę oszustw. Przetwarza dane osobowe, korzysta z infrastruktury chmurowej, opiera się na zarządzanym Kubernetes, integruje się z interfejsami API klientów i korzysta z zewnętrznego dostawcy tożsamości. Klient prosi o dowody dotyczące Zero Trust, a spółka ma dziesięć dni roboczych.

Praktyczny sprint dowodowy Clarysec wyglądałby następująco.

Celem nie jest udawanie, że organizacja osiągnęła doskonałe Zero Trust w dziesięć dni. Celem jest stworzenie możliwego do obrony łańcucha dowodowego dla najważniejszych ryzyk oraz wykazanie, że program jest zarządzany, mierzalny i doskonalony.

Jak różni audytorzy będą testować Zero Trust

Częstym błędem jest przygotowanie jednej historii technicznej i założenie, że każdy audytor zada te same pytania. Tak nie będzie.

Audytor ISO/IEC 27001:2022 będzie szukał systemu zarządzania. Zapyta, czy ryzyka Zero Trust są ujęte w ocenie ryzyka, czy postępowania z ryzykiem zostały zatwierdzone, czy SoA jest kompletna, czy polityki są dokumentami nadzorowanymi, czy odbywają się przeglądy dostępu, czy audyty wewnętrzne testują środki kontrolne oraz czy przeglądy zarządzania śledzą wyniki.

Recenzent DORA zapyta, czy środki kontrolne Zero Trust są częścią udokumentowanych ram zarządzania ryzykiem ICT. Będzie oczekiwać inwentarzy aktywów i zależności, mapowania funkcji krytycznych lub ważnych, klasyfikacji incydentów, eskalacji do zarządu, testowania, wymagań umownych wobec stron trzecich, praw do audytu, strategii wyjścia oraz śledzenia działań naprawczych.

Asesor NIS2 skoncentruje się na odpowiedzialności organu zarządzającego, środkach zarządzania ryzykiem cyberbezpieczeństwa z Article 21 oraz gotowości do zgłaszania incydentów z Article 23. Będzie również oczekiwać dowodów, że bezpieczeństwo łańcucha dostaw, ciągłość działania, obsługa podatności, kontrola dostępu i cyberhigiena są zarządzane.

Recenzent GDPR lub audytor prywatności zapyta, czy dostęp do danych osobowych jest konieczny, udokumentowany, ograniczony, monitorowany i zgodny z celami przetwarzania. Zbada role administratora i podmiotu przetwarzającego, wykrywanie naruszeń ochrony danych osobowych, dostęp oparty na rolach, szyfrowanie, pseudonimizację tam, gdzie jest właściwa, okres przechowywania i rozliczalność.

Ten sam środek kontrolny może odpowiadać na wiele pytań, ale tylko wtedy, gdy dowody są uporządkowane.

Ryzyko dostawców, chmury obliczeniowej i zewnętrznych dostawców ICT

Zero Trust nie kończy się na zaporze sieciowej, a w środowiskach chmurowych tradycyjna granica zapory może w ogóle nie istnieć. Dostawcy tożsamości, platformy chmurowe, narzędzia CI/CD, dostawcy zarządzanego wykrywania, operatorzy płatności, bramy API i zespoły rozwoju realizowanego w modelu outsourcingowym stają się częścią struktury zaufania.

NIS2 Article 21 wprost obejmuje bezpieczeństwo łańcucha dostaw dla bezpośrednich dostawców i dostawców usług, w tym podatności dostawców, odporność produktów i usług, praktyki cyberbezpieczeństwa dostawców oraz procedury bezpiecznego rozwoju oprogramowania.

DORA wymaga, aby ryzyko związane z zewnętrznymi dostawcami ICT było zarządzane jako część ram zarządzania ryzykiem ICT, z rejestrem umów na usługi ICT, due diligence przed zawarciem umowy, oceną krytyczności, ryzykiem koncentracji, umownymi wymaganiami bezpieczeństwa, wsparciem przy incydentach, współpracą z organami, prawami do audytu, prawami wypowiedzenia, strategiami wyjścia i planami przejściowymi.

Dla Zero Trust praktyczna zasada jest prosta: nie należy ufać połączeniu dostawcy tylko dlatego, że wynika z umowy. Należy wymagać technicznych środków kontrolnych i dowodów.

Integracja API klienta powinna mieć zakresowane tokeny, limity żądań, monitorowanie, rotację, właścicielstwo i unieważnianie. Dostawca usług zarządzanych powinien używać MFA, imiennych kont użytkowników, zasady najmniejszych uprawnień, rejestrowania sesji i dostępu ograniczonego czasowo. Relacja z dostawcą usług chmurowych powinna obejmować mapowanie współdzielonej odpowiedzialności, konfigurację szyfrowania, okres przechowywania logów, testowanie kopii zapasowych i planowanie wyjścia.

Dlatego dowody dotyczące dostawców i chmury obliczeniowej powinny znajdować się w modelu Zero Trust, a nie w oddzielnym folderze zakupowym.

Metryki potwierdzające działanie Zero Trust

Zarządy i audytorzy nie oczekują wyłącznie diagramów architektury. Oczekują dowodów działania i trendów doskonalenia.

Przydatne metryki Zero Trust obejmują:

• Odsetek kont uprzywilejowanych chronionych przez MFA.
• Odsetek użytkowników objętych dostępem warunkowym.
• Liczbę stałych kont uprzywilejowanych w porównaniu z kontami just-in-time.
• Liczbę przeterminowanych przeglądów dostępu.
• Odsetek punktów końcowych zgodnych z wymaganiami dotyczącymi stanu bezpieczeństwa.
• Pokrycie EDR dla aktywów krytycznych.
• Liczbę odrzuconych prób dostępu z powodu ryzyka związanego z urządzeniem lub lokalizacją.
• Mean Time to Detect podejrzanej aktywności uprzywilejowanej.
• Średni czas cofnięcia dostępu po zakończeniu współpracy.
• Odsetek reguł zapory sieciowej między strefami poddanych przeglądowi w ostatnim kwartale.
• Liczbę dostawców krytycznych z aktualnymi dowodami bezpieczeństwa.
• Liczbę wyjątków Zero Trust po terminie działań naprawczych.
• Odsetek aplikacji krytycznych wysyłających logi do SIEM.
• Wyniki symulacji incydentów dotyczących naruszenia danych uwierzytelniających.

Metryki te wspierają ciągłe doskonalenie w ISO/IEC 27001:2022, ocenę skuteczności według NIS2, oczekiwania DORA dotyczące testowania i działań naprawczych oraz rozliczalność według GDPR.

Typowe słabości dowodowe Zero Trust

Najczęstsze słabości nie wynikają z braku narzędzi. Wynikają ze słabej identyfikowalności.

Po pierwsze, organizacje wdrażają MFA, ale nie potrafią wykazać pełnego objęcia kont uprzywilejowanych. Konta serwisowe, konta typu „break glass” i lokalne konta administratora często pozostają poza kontrolą.

Po drugie, przeglądy dostępu są wykonywane ręcznie, ale nie są powiązane z rolami biznesowymi, wrażliwością danych ani właścicielami ryzyka. Dowód pokazuje, że ktoś kliknął „sprawdzono”, a nie że usunięto zbędny dostęp.

Po trzecie, segmentacja sieci istnieje na diagramach, ale nie w przetestowanych regułach. Audytorzy zapytają, czy dostęp między segmentami jest domyślnie odmawiany i czy wyjątki są zatwierdzane.

Po czwarte, logi są zbierane, ale nie są operacyjnie użyteczne. SIEM bez zdefiniowanych przypadków użycia, triage alertów i procedur reakcji nie potwierdza ciągłego monitorowania.

Po piąte, dostęp dostawców jest niezarządzany. Dostawcy mogą używać współdzielonych poświadczeń, stałego dostępu VPN albo szerokich ról chmurowych bez monitorowania sesji.

Po szóste, dowody dotyczące prywatności są oddzielone od dowodów bezpieczeństwa. GDPR wymaga możliwej do wykazania ochrony danych osobowych, dlatego środki kontroli tożsamości i dostępu muszą być powiązane z kategoriami danych oraz celami przetwarzania.

Wreszcie, wyjątki nie są udokumentowane. Zero Trust może tolerować wyjątki, jeżeli zostały ocenione pod kątem ryzyka, zatwierdzone, ograniczone czasowo i monitorowane. Nie może tolerować niewidocznych wyjątków.

Zbuduj pakiet dowodowy Zero Trust z Clarysec

Zero Trust Architecture w 2026 roku nie jest hasłem. To operacyjny model zgodności, który łączy tożsamość, urządzenia, aplikacje, segmentację sieci, zasadę najmniejszych uprawnień, ciągłe monitorowanie, kontrolę dostawców i środki ochrony prywatności w jeden audytowalnie identyfikowalny system.

Jeżeli przygotowujesz się do certyfikacji ISO/IEC 27001:2022, odpowiadasz na zapytania klientów dotyczące NIS2, dostosowujesz się do zarządzania ryzykiem ICT według DORA albo wykazujesz bezpieczeństwo przetwarzania z GDPR Article 32, zacznij od identyfikowalności.

Użyj Zenith Blueprint: An Auditor’s 30-Step Roadmap, aby zmapować ryzyka Zero Trust na rejestr ryzyk, plan postępowania z ryzykiem i SoA. Użyj Zenith Controls: The Cross-Compliance Guide, aby dostosować kontrolę dostępu, zarządzanie tożsamością i monitorowanie do oczekiwań międzyramowych. Skorzystaj z biblioteki polityk Clarysec, w tym Enterprise Access Control Policy, Enterprise User Account and Privilege Management Policy, Enterprise Network Security Policy, Enterprise Logging and Monitoring Policy, Enterprise Information Security Policy oraz Data Protection and Privacy Policy - SME, aby przekształcić architekturę w egzekwowalny ład zarządczy.

Kolejnym praktycznym krokiem jest wybór jednego scenariusza wysokiego ryzyka, takiego jak naruszony dostęp uprzywilejowany do danych klientów, i zbudowanie wokół niego kompletnego łańcucha dowodowego Zero Trust. Jeżeli potrafisz wykazać ten scenariusz od początku do końca, masz fundament skalowalnego, audytowalnego i gotowego na wymagania regulatorów programu Zero Trust.

Pobierz pakiety polityk Clarysec albo umów rozmowę strategiczną, aby zobaczyć, jak Zenith Blueprint i Zenith Controls mogą przekształcić Zero Trust z ryzyka audytowego w przewagę w zakresie zgodności.