Zero Trust Architecture - od koncepcji do wdrożenia w środowiskach IT i OT

W grudniu 2020 roku SolarWinds ujawnił, że aktualizacja platformy Orion zawierała backdoor zainstalowany przez grupę APT powiązaną z rosyjskim wywiadem. Malware SUNBURST działał wewnątrz sieci ponad 18 000 organizacji - w tym agencji rządowych USA, firm technologicznych i operatorów infrastruktury krytycznej. Firewalle, IDS-y i VPN-y nie pomogły, bo atakujący byli już w środku, poruszając się lateralnie między systemami z uprawnieniami zaufanego oprogramowania.

Ten incydent potwierdził to, co John Kindervag opisał w 2010 roku, a NIST sformalizował w SP 800-207 w 2020: model bezpieczeństwa oparty na granicach sieci jest fundamentalnie wadliwy. Nie dlatego, że firewalle nie działają - ale dlatego, że zakładają coś, czego nie da się zagwarantować: że wszystko wewnątrz sieci jest godne zaufania.

W tym artykule rozkładamy architekturę Zero Trust na części pierwsze - od siedmiu zasad NIST, przez model dojrzałości CISA, po konkretne wyzwania wdrożenia w środowiskach OT, gdzie protokoły Modbus i PROFINET nie wspierają uwierzytelniania.

Źródło: Gartner (2024), DoD CIO (2025)

Czym jest Zero Trust Architecture

Zero Trust to nie produkt ani technologia - to model bezpieczeństwa, który eliminuje domniemane zaufanie (implicit trust) z architektury sieciowej. Każdy dostęp - niezależnie od tego, czy pochodzi z wewnątrz sieci, czy z zewnątrz - musi być uwierzytelniony, autoryzowany i stale walidowany.

NIST SP 800-207 definiuje architekturę ZTA w dwóch płaszczyznach: control plane (płaszczyzna sterowania) i data plane (płaszczyzna danych). To rozdzielenie jest fundamentalne - decyzje o dostępie podejmowane są w innej warstwie niż sam przepływ danych.

Control Plane - mózg architektury

Control plane składa się z trzech logicznych komponentów, które współpracują przy każdym żądaniu dostępu:

Policy Engine (PE) - mózg systemu. Otrzymuje żądanie dostępu i podejmuje decyzję (grant/deny/revoke) na podstawie trust algorithm - algorytmu, który waży wiele sygnałów jednocześnie:

Źródło sygnału	Przykład	Wpływ na decyzję
Tożsamość użytkownika	MFA potwierdzone, konto aktywne, rola	Kto prosi o dostęp?
Postawa urządzenia	EDR aktywny, OS aktualny, dysk zaszyfrowany	Czy urządzenie jest godne zaufania?
Lokalizacja i kontekst	IP, geolokalizacja, pora dnia, sieć	Czy kontekst jest normalny?
Zachowanie	Anomalie vs baseline (np. impossible travel)	Czy zachowanie jest podejrzane?
Threat intelligence	Znane złośliwe IP, IOC, kampanie aktywne	Czy środowisko jest bezpieczne?
Polityki organizacji	Reguły dostępu per zasób, klasyfikacja danych	Co wolno, a co nie?

Policy Administrator (PA) - tłumacz. Otrzymuje decyzję PE i konfiguruje mechanizmy egzekwujące: generuje tokeny sesji, definiuje parametry połączenia (IP, port, klucz), otwiera lub zamyka kanał komunikacji.

Policy Enforcement Point (PEP) - strażnik na data plane. Fizycznie blokuje lub przepuszcza ruch. PEP to jedyny komponent, który “dotyka” danych - może to być agent na urządzeniu, brama sieciowa, reverse proxy lub firewall.

Data Plane - przepływ danych

Data plane to płaszczyzna, w której odbywa się faktyczna komunikacja między użytkownikiem/urządzeniem a zasobem. PEP działa na granicy data plane - przepuszcza tylko ruch autoryzowany przez control plane.

Jak działa żądanie dostępu - krok po kroku

Użytkownik/urządzenie → PEP [blokuje domyślnie]
                         ↓
                    PA (przekazuje żądanie do PE)
                         ↓
                    PE [trust algorithm]:
                    ├── Sprawdź tożsamość (IdP/MFA)
                    ├── Sprawdź posturę urządzenia (EDR/MDM)
                    ├── Sprawdź kontekst (lokalizacja, czas, sieć)
                    ├── Sprawdź threat intelligence
                    ├── Sprawdź polityki dostępu
                    └── Oblicz risk score
                         ↓
                    Decyzja: GRANT (risk score < próg)
                         ↓
                    PA → konfiguruje PEP (otwórz kanał, sesja X, timeout Y)
                         ↓
                    PEP [przepuszcza] → Zasób
                         ↓
                    [Ciągła walidacja - PE monitoruje sesję]
                    Jeśli risk score wzrośnie → PA → PEP [terminuj sesję]

Mechanizmy kontrolne realizowane przez komponenty ZTA

Każdy komponent realizuje konkretne mechanizmy kontrolne:

Komponent	Mechanizm kontrolny	Jak działa
PE	Continuous authentication	Weryfikacja tożsamości nie tylko przy logowaniu, ale przez całą sesję
PE	Risk-based access	Decyzja zależy od kontekstu, nie tylko od hasła i roli
PE	Adaptive policies	Różne wymagania dla tego samego zasobu w zależności od ryzyka (np. biuro vs kawiarnia)
PA	Session binding	Sesja powiązana z konkretnym urządzeniem i tożsamością - nie da się przenieść tokenu
PA	Just-in-time access	Uprawnienia przyznawane na czas zadania, automatycznie wygasają
PEP	Default deny	Każde połączenie domyślnie zablokowane, dopóki PE nie wyda decyzji
PEP	Microsegmentation	Granularne polityki per workload/urządzenie/protokół
PEP	Protocol-aware filtering	W OT: zezwolenie na Modbus Read, blokada Modbus Write z nieautoryzowanych źródeł

W praktyce PE, PA i PEP mogą być zaimplementowane jako osobne systemy (np. SIEM/SOAR jako PE, NAC jako PA, firewall jako PEP) lub jako zintegrowana platforma (SASE/SSE, Microsoft Entra + Defender + Intune).

Siedem zasad NIST SP 800-207

NIST sformułował siedem fundamentalnych zasad, na których opiera się każda implementacja Zero Trust:

#	Zasada	Implikacja praktyczna
1	Wszystkie źródła danych i usługi obliczeniowe są zasobami	Nie tylko serwery - także drukarki, kamery IP, sterowniki PLC, czujniki IoT
2	Cała komunikacja jest zabezpieczona niezależnie od lokalizacji sieciowej	Ruch wewnątrz sieci firmowej wymaga takiego samego szyfrowania jak ruch z internetu
3	Dostęp do zasobów jest przyznawany per sesja	Każde połączenie wymaga osobnej autoryzacji - brak stałych “zaufanych” tuneli
4	Dostęp jest determinowany przez dynamiczną politykę	Decyzja uwzględnia tożsamość, stan urządzenia, lokalizację, porę dnia, zachowanie
5	Organizacja monitoruje integralność i postawę bezpieczeństwa wszystkich zasobów	Ciągła diagnostyka, nie jednorazowy audyt - CDM (Continuous Diagnostics and Mitigation)
6	Uwierzytelnianie i autoryzacja są dynamiczne i ściśle egzekwowane	Nie wystarczy MFA przy logowaniu - walidacja trwa przez całą sesję
7	Organizacja zbiera maksymalną ilość informacji o stanie zasobów i komunikacji	Telemetria z sieci, endpointów, aplikacji i tożsamości zasila model decyzyjny

Trzy modele wdrożeniowe NIST

NIST opisuje trzy wzorcowe modele wdrożeniowe, które różnią się sposobem implementacji PEP:

Model agentowy (Device Agent/Gateway) - oprogramowanie agenta na każdym urządzeniu współpracuje z bramą zasobów. Najlepsza granularność kontroli, ale wymaga możliwości instalacji agenta - co w środowiskach OT bywa niemożliwe.

Model bramki enklawowej (Enclave Gateway) - chroni grupy powiązanych zasobów za wspólną bramą. Odpowiednik koncepcji stref i korytarzy z IEC 62443 - dobrze pasuje do segmentacji sieci OT.

Model portalu zasobów (Resource Portal) - pojedynczy punkt dostępu do wielu zasobów, działający jako reverse proxy. Stosowany w scenariuszach zdalnego dostępu do systemów ICS, gdzie technicy serwisowi łączą się przez centralną bramę.

CISA Zero Trust Maturity Model v2.0

W kwietniu 2023 CISA opublikowała zaktualizowany model dojrzałości Zero Trust (ZTMM v2.0), który definiuje pięć filarów i cztery poziomy dojrzałości. Model ten jest obowiązkowy dla agencji federalnych USA (OMB M-22-09), ale stanowi praktyczną mapę drogową dla każdej organizacji.

Pięć filarów i cztery poziomy

Filar	Traditional	Initial	Advanced	Optimal
Tożsamość	Hasła, lokalne konta	MFA, centralny IdP	Ciągła weryfikacja, analiza ryzyka sesji	Phishing-resistant MFA, just-in-time access, pełna automatyzacja
Urządzenia	Brak inwentaryzacji	Podstawowy MDM, antywirus	EDR/XDR, sprawdzanie compliance przed dostępem	Ciągła walidacja postawy, izolacja zagrożonych urządzeń w czasie rzeczywistym
Sieci	Płaska sieć, firewall perymetryczny	Makrosegmentacja IT/OT	Mikrosegmentacja, szyfrowanie east-west	Dynamiczna segmentacja, adaptacyjne polityki na podstawie zachowań
Aplikacje	Brak inwentaryzacji, brak testów	Podstawowe skanowanie podatności	DAST/SAST w CI/CD, WAF	Ciągłe testowanie, runtime protection, service mesh z mTLS
Dane	Brak klasyfikacji	Podstawowa klasyfikacja, DLP na peryferiach	Automatyczna klasyfikacja, szyfrowanie at-rest i in-transit	Zarządzanie prawami (DRM), audyt dostępu w czasie rzeczywistym, tokenizacja

Trzy zdolności przekrojowe

Oprócz pięciu filarów, CISA definiuje trzy zdolności (capabilities), które przenikają każdy filar:

1. Widoczność i analityka - telemetria z każdego filaru zasila wspólny model decyzyjny (SIEM/SOAR/XDR)
2. Automatyzacja i orkiestracja - polityki egzekwowane automatycznie, bez manualnej interwencji
3. Zarządzanie (Governance) - polityki, procedury, role i odpowiedzialność zdefiniowane i mierzone

Zero Trust w środowiskach OT - specyfika i wyzwania

Zasady Zero Trust powstały w kontekście środowisk IT, gdzie każde urządzenie ma system operacyjny zdolny do uruchomienia agenta, a protokoły komunikacji wspierają szyfrowanie i uwierzytelnianie. Środowiska OT to inny świat.

Dlaczego OT jest trudniejsze

Wyzwanie	Opis	Wpływ na Zero Trust
Brak uwierzytelniania w protokołach	Modbus, S7comm, EtherNet/IP nie mają mechanizmów auth	Nie można weryfikować tożsamości na poziomie protokołu
Cykl życia 15-25 lat	Sterowniki PLC, RTU, DCS pracują dekady bez aktualizacji	Brak możliwości instalacji agentów, brak wsparcia TLS
Wymogi czasu rzeczywistego	Opóźnienia >10ms mogą powodować awarie procesów	Inline inspection i szyfrowanie mogą zaburzać determinizm
Brak agentów	Wiele urządzeń poziomu 0-1 nie ma zasobów obliczeniowych na agenta	Wymusza podejście network-centric zamiast agent-based
Dostępność > poufność	Priorytet: proces musi działać, nawet kosztem bezpieczeństwa	Mechanizmy ZT nie mogą blokować komunikacji krytycznej

DoD Zero Trust for OT (listopad 2025)

W listopadzie 2025 Pentagon opublikował pierwszy kompleksowy przewodnik wdrożenia Zero Trust w środowiskach OT - “Zero Trust for Operational Technology Activities and Outcomes”. Dokument definiuje:

• 105 aktywności ZT podzielonych na 7 filarów (users, devices, applications & workloads, data, networks & environments, automation & orchestration, visibility & analytics)
• 84 aktywności docelowe (target level) - minimum wymagane od każdego komponentu DoD
• 21 aktywności zaawansowanych (advanced level) - dla systemów o najwyższym poziomie ryzyka

Kluczowe wymaganie DoD: model Purdue, IEC 62443 i UFC 4-010-06 pozostają autorytatywnymi ramami klasyfikacji systemów OT. Zero Trust to nadbudowa, nie zamiennik - wzmacnia kontrolę na granicach stref, które Purdue definiuje.

Purdue 2.0 - adaptacja modelu do Zero Trust

Klasyczny model Purdue zakłada hierarchiczną segmentację (Poziom 0-5) z kontrolą na granicach poziomów. Purdue 2.0 zachowuje tę hierarchię, ale dodaje:

• Mikrosegmentacja wewnątrz poziomów - nie tylko granice między Level 2 (supervision) a Level 1 (control), ale granularne polityki w obrębie każdego poziomu
• Kontrola lateralnego ruchu - ograniczenie komunikacji east-west między urządzeniami na tym samym poziomie
• Integracja chmury i XIoT - czujniki IIoT, bramki edge computing i połączenia chmurowe wkomponowane w model bezpieczeństwa
• Kompensacyjne kontrole dla urządzeń bez auth - protocol-aware allowlisting, unidirectional gateways, anomaly detection

CISA Microsegmentation Guidance (lipiec 2025)

W lipcu 2025 CISA opublikowała przewodnik “Journey to Zero Trust: Microsegmentation”, w którym wskazuje mikrosegmentację jako fundament architektury Zero Trust - również w środowiskach OT. Kluczowe rekomendacje:

• Rozpocznij od makrosegmentacji (oddzielenie sieci IT od OT), a następnie przejdź do mikrosegmentacji wewnątrz strefy OT
• Segmentuj na poziomie funkcji biznesowych (cell/area zones z IEC 62443), nie tylko VLAN-ów
• Stosuj protocol-aware enforcement - filtrowanie po function codes protokołu, np. zezwolenie na Modbus Read (FC 03/04) przy jednoczesnym blokowaniu Write (FC 05/06/16) z nieautoryzowanych źródeł

Szczegółowe podejście do segmentacji opisujemy w osobnym artykule: Segmentacja sieci OT - jak chronić systemy przemysłowe.

Gdzie Zero Trust nie działa - ograniczenia i kompensacje

ZTA nie jest uniwersalnym rozwiązaniem. Są środowiska i scenariusze, w których pełne wdrożenie zasad Zero Trust jest niemożliwe lub niebezpieczne. CISO musi wiedzieć, gdzie stosować ZTA, gdzie adaptować, a gdzie kompensować innymi kontrolami.

Systemy bezpieczeństwa funkcjonalnego (SIS)

Safety Instrumented Systems (SIS) - systemy realizujące funkcje bezpieczeństwa procesowego (ESD, F&G, SIL 2+) - mają nadrzędne wymaganie: muszą działać zawsze. Dodanie inline mechanizmów ZTA (szyfrowanie, uwierzytelnianie per-sesja) wprowadza:

• Latencję - dodatkowe milisekundy mogą przekroczyć wymagania czasowe pętli bezpieczeństwa
• Single point of failure - awaria komponentu ZTA (np. PE niedostępny) może uniemożliwić komunikację safety
• Złożoność certyfikacji - zmiany w ścieżce komunikacji SIS wymagają ponownej walidacji SIL

Rekomendacja: SIS powinien być fizycznie izolowany od sieci objętej ZTA. Kontrole kompensacyjne: unidirectional gateway (data diode), hardcoded ACL na dedykowanym firewallu, monitoring anomalii pasywny (OT NDR w trybie tap).

Legacy OT bez uwierzytelniania

Sterowniki PLC i RTU na poziomach 0-1 Purdue (np. Modbus RTU, starsze S7-300) nie wspierają żadnych mechanizmów uwierzytelniania ani szyfrowania. Nie możesz zainstalować agenta na sterowniku z 64 KB pamięci.

Rekomendacja: Model enklawowy (Enclave Gateway) - PEP obudowuje grupę urządzeń legacy, realizując kontrolę na granicy enklawy:

Kontrola	Jak realizować bez agenta
Uwierzytelnianie	Na bramie enklawy (PEP), nie na urządzeniu końcowym
Autoryzacja	Protocol-aware allowlisting: zezwolenie na konkretne function codes z konkretnych IP
Monitoring	Pasywne NDR (Nozomi, Claroty) w trybie tap - zero wpływu na latencję
Szyfrowanie	Tunel IPSec między bramami enklaw, nie end-to-end do PLC

Komunikacja real-time i determinizm

Protokoły z wymaganiami determinizmu (PROFINET IRT, EtherCAT, Time-Sensitive Networking) nie tolerują dodatkowych opóźnień. Inline inspection lub szyfrowanie per-pakiet zaburzy cykl komunikacji.

Rekomendacja: Nie wdrażaj inline ZTA na ścieżce real-time. Zamiast tego: mikrosegmentacja na poziomie przełącznika (VLAN + ACL), monitoring pasywny, kontrola dostępu do sieci zarządzającej (nie do sieci real-time).

Fail-open vs fail-closed

Kluczowe pytanie: co się dzieje, gdy Policy Engine jest niedostępny?

Strategia	Kiedy stosować	Ryzyko
Fail-closed	Sieci IT, dostęp do danych wrażliwych	Dostępność - użytkownicy nie mogą pracować
Fail-open	Procesy safety-critical, gdzie brak komunikacji = zagrożenie życia	Bezpieczeństwo - potencjalnie nieautoryzowany dostęp
Cached decision	Kompromis - ostatnia znana decyzja PE obowiązuje przez określony czas (np. 5 min)	Zależy od TTL cache’a i zmiany ryzyka

Koszty i bariera organizacyjna

ZTA wymaga nie tylko technologii, ale zmiany kultury organizacyjnej. Najczęstsze bariery:

• Inwentaryzacja - nie możesz zdefiniować polityk dla zasobów, których nie znasz. Organizacje z niekompletną inwentaryzacją muszą ją uzupełnić przed wdrożeniem ZTA
• Opór użytkowników - MFA, ograniczenia dostępu, sprawdzanie compliance urządzenia. Wymaga komunikacji i buy-in od zarządu
• Koszty integracji - ZTA łączy wiele systemów (IdP + EDR + NAC + SIEM + firewalle). Integracja wymaga czasu i kompetencji
• Brak kompetencji - SANS 2025: tylko 14% organizacji OT czuje się w pełni przygotowane na nowe zagrożenia

Stos technologiczny Zero Trust - mapowanie na filary

Architektura Zero Trust to nie jedno narzędzie, ale ekosystem technologii. Poniższa tabela mapuje kategorie rozwiązań na filary CISA ZTMM:

Kategoria technologii	Filar CISA	Funkcja w architekturze ZT
IAM / IdP (Entra ID, Okta)	Tożsamość	Centralny punkt uwierzytelniania, SSO, polityki dostępu warunkowego
MFA / phishing-resistant auth (FIDO2, passkeys)	Tożsamość	Eliminacja wektora credential theft
PAM (CyberArk, Delinea)	Tożsamość	Zarządzanie kontami uprzywilejowanymi, nagrywanie sesji, JIT access
EDR/XDR (CrowdStrike, Microsoft Defender)	Urządzenia	Ciągła walidacja postawy, wykrywanie zagrożeń, izolacja
MDM/UEM (Intune, Jamf)	Urządzenia	Sprawdzanie compliance przed dostępem, wymuszanie konfiguracji
Mikrosegmentacja (Illumio, Guardicore, Zero Networks)	Sieci	Granularne polityki east-west, ograniczenie ruchu lateralnego
ZTNA (Zscaler Private Access, Cloudflare Access)	Sieci	Zastępuje VPN - dostęp per-sesja, bez wystawiania sieci
SASE/SSE (Zscaler, Palo Alto Prisma, Netskope)	Sieci + Aplikacje	Konsolidacja SWG, CASB, ZTNA, FWaaS w jedną platformę
CASB (Netskope, Microsoft Defender for Cloud Apps)	Aplikacje + Dane	Kontrola dostępu do SaaS, shadow IT discovery, DLP
DLP / klasyfikacja danych (Purview, Forcepoint)	Dane	Automatyczna klasyfikacja, blokowanie eksfiltracji
SIEM/SOAR (Sentinel, Splunk, Chronicle)	Widoczność	Korelacja telemetrii, automatyczna reakcja na incydenty
OT NDR (Nozomi, Claroty, Dragos)	Sieci (OT)	Pasywny monitoring protokołów OT, wykrywanie anomalii bez agentów

Zaawansowane mechanizmy detekcji w architekturze ZTA

Atakujący adaptują się do ZTA. Kradzież tokenów sesji (token theft), ataki AiTM (Adversary-in-the-Middle) i kompromitacja MFA fatigue to techniki omijania mechanizmów Zero Trust. Dojrzała architektura musi uwzględniać te wektory.

UEBA - behawioralna analiza użytkowników

User and Entity Behavior Analytics (UEBA) to kluczowy komponent trust algorithm w Policy Engine. UEBA buduje profil normalnego zachowania każdego użytkownika i urządzenia, a następnie przypisuje risk score na podstawie odchyleń:

Anomalia behawioralna	Risk score impact	Akcja ZTA
Logowanie o nietypowej porze	Niski-średni	Step-up authentication (dodatkowe MFA)
Impossible travel (Warszawa → Singapur w 30 min)	Wysoki	Blokada sesji, alert SOC
Masowe pobieranie plików ponad baseline	Średni-wysoki	Ograniczenie dostępu, alert DLP
Użycie nowego urządzenia dla konta uprzywilejowanego	Wysoki	Wymaganie re-authentication + device enrollment
Lateral movement pattern (sequential access to many systems)	Krytyczny	Natychmiastowa izolacja, IR playbook

Obrona przed kradzieżą tokenów i AiTM

Ataki AiTM (Adversary-in-the-Middle) przechwytują tokeny sesji po udanym MFA - omijając tym samym uwierzytelnianie. W 2025 roku ten wektor stał się jednym z głównych sposobów kompromitacji kont mimo MFA.

Kontrole kompensacyjne:

• Token binding - powiązanie tokenu sesji z konkretnym urządzeniem (IP, device fingerprint). Token przechwycony na innym urządzeniu jest odrzucany
• Continuous Access Evaluation (CAE) - Microsoft Entra ID pozwala na natychmiastowe unieważnienie tokenów (bez czekania na wygaśnięcie TTL) po wykryciu anomalii
• Phishing-resistant MFA - FIDO2/passkeys nie wysyłają sekretów przez sieć, więc AiTM proxy nie ma czego przechwycić
• Compliant Network check - dostęp tylko z sieci firmowej lub przez ZTNA (nawet z ważnym tokenem, próba z nieznanej sieci jest blokowana)

AI w obronie ZTA (2025+)

AI-powered SIEM i SOAR wzmacniają ZTA poprzez:

• Automatyczną korelację sygnałów z wielu filarów (tożsamość + urządzenie + sieć + dane)
• Predykcyjną analizę ryzyka (identyfikacja kompromitacji przed jej materializacją)
• Autonomiczną reakcję (izolacja urządzenia, rewokacja tokenów, zamknięcie sesji bez interwencji człowieka)

Case studies - lekcje z wdrożeń

Google BeyondCorp - 10+ lat doświadczeń

Google BeyondCorp to najstarsze i najszerzej udokumentowane wdrożenie ZTA. Kluczowe lekcje:

• Brak VPN - 130 000+ pracowników Google uzyskuje dostęp do zasobów bez VPN, przez BeyondCorp proxy weryfikujący tożsamość i posturę urządzenia
• Long tail problem - migracja 80% zasobów zajęła stosunkowo krótko, ale ostatnie 20% wymagało nieproporcjonalnie dużo wysiłku (specyficzne aplikacje, legacy systemy, edge cases)
• Iteracyjność - Google publikuje BeyondCorp papers od 2014 roku i wciąż iteruje; ZTA nie jest projektem z datą zakończenia
• Device Trust - Google wymaga, aby urządzenie było zarządzane i miało aktualny certyfikat trust, zanim Policy Engine w ogóle rozważy żądanie dostępu

DoD - Zero Trust na skalę państwową

Departament Obrony USA wdraża ZTA na wszystkich systemach - niejawnych i jawnych:

• 91 aktywności Target Level - minimum wymagane od każdego komponentu DoD do końca FY2027
• 61 aktywności Advanced Level - dla systemów o najwyższym ryzyku, do FY2032
• Wynik pilotażu Navy - podczas testów z Microsoft Security, personel Navy osiągnął 100% sukces w 91 aktywnościach Target Level
• Strategia 2.0 - Pentagon planuje publikację zaktualizowanej strategii ZT na początku 2026

Droga wdrożenia - od quick wins do pełnej architektury

Wdrożenie Zero Trust to projekt wieloletni. Poniższa mapa drogowa opisuje trzy fazy, od działań, które można podjąć w ciągu tygodni, po transformację architektury trwającą 2-3 lata.

Faza 1: Fundamenty (0-6 miesięcy)

Cel: eliminacja najczęstszych wektorów wejścia bez rewolucji w infrastrukturze.

• Wymuszenie MFA na wszystkich kontach z dostępem zdalnym i uprzywilejowanym - phishing-resistant (FIDO2/passkeys) tam, gdzie to możliwe
• Inwentaryzacja zasobów - nie można chronić tego, czego nie widać; pełna inwentaryzacja zasobów ICS jest punktem wyjścia dla środowisk OT
• Makrosegmentacja IT/OT - jeśli nie istnieje, firewall na granicy strefy IT i OT z DMZ to priorytet numer jeden
• Wdrożenie centralnego IdP - konsolidacja zarządzania tożsamością (Entra ID, Okta) z politykami dostępu warunkowego
• Wyłączenie nieaktywnych kont - przegląd i dezaktywacja kont, które nie były używane >90 dni

Faza 2: Rozbudowa kontroli (6-18 miesięcy)

Cel: przejście od makrosegmentacji do mikrosegmentacji, wdrożenie ciągłego monitoringu.

• Mikrosegmentacja sieci IT - polityki east-west na poziomie workloadów i aplikacji
• EDR/XDR na wszystkich endpointach IT i stacjach inżynierskich OT (Level 2-3)
• ZTNA zamiast VPN dla dostępu zdalnego - weryfikacja użytkownika i urządzenia przed każdym połączeniem
• PAM dla kont uprzywilejowanych - nagrywanie sesji, rotacja haseł, just-in-time elevation
• OT NDR - pasywny monitoring w sieci OT bez wpływu na proces; wykrywanie anomalii w protokołach przemysłowych
• Klasyfikacja danych i wdrożenie DLP na granicach strefy IT/OT

Faza 3: Optymalizacja i automatyzacja (18-36 miesięcy)

Cel: dynamiczne polityki, automatyczna reakcja, ciągłe doskonalenie.

• Mikrosegmentacja w OT - granularne polityki na poziomie cell/area zones z IEC 62443
• Automatyzacja orkiestracji - SOAR playbooki reagujące na incydenty bez interwencji manualnej
• Ciągła walidacja - breach and attack simulation (BAS), regularne testy penetracyjne red team
• Integracja threat intelligence - zasilanie Policy Engine aktualnymi danymi o zagrożeniach OT
• Zero Trust na warstwie aplikacji OT - mTLS dla nowych protokołów (OPC UA), protocol-aware allowlisting dla legacy

Checklist: ocena gotowości organizacji do Zero Trust

Poniższa lista pozwala ocenić, na jakim etapie wdrożenia jest Twoja organizacja. Każdy niezaznaczony punkt to potencjalny wektor ataku, który Zero Trust ma wyeliminować:

Tożsamość

• Centralny IdP (Entra ID, Okta) dla wszystkich użytkowników
• MFA na wszystkich kontach z dostępem zdalnym
• Phishing-resistant MFA (FIDO2/passkeys) dla kont uprzywilejowanych
• Automatyczna dezaktywacja nieaktywnych kont (>90 dni)
• Just-in-time access dla operacji administracyjnych

Urządzenia

• Pełna inwentaryzacja urządzeń IT i OT z aktualnymi metadanymi
• EDR/XDR na stacjach roboczych i serwerach
• Sprawdzanie compliance urządzenia przed przyznaniem dostępu
• Polityka BYOD z separacją danych firmowych

Sieci

• Makrosegmentacja IT/OT z DMZ
• Mikrosegmentacja sieci IT (east-west)
• Szyfrowanie ruchu wewnętrznego (mTLS, IPsec)
• ZTNA zamiast klasycznego VPN dla dostępu zdalnego
• Mikrosegmentacja w OT na poziomie cell/area zones

Aplikacje i dane

• Inwentaryzacja i klasyfikacja aplikacji (sanctioned vs shadow IT)
• WAF i DAST/SAST w pipeline CI/CD
• Klasyfikacja danych i polityki DLP
• Szyfrowanie danych at-rest i in-transit

Widoczność

• Centralna platforma SIEM/XDR zbierająca logi z IT i OT
• OT NDR monitorujący protokoły przemysłowe
• Automatyczne alerty i playbooki SOAR
• Regularne testy penetracyjne i BAS

Jak zacząć

Zero Trust to nie projekt jednorazowy, ale zmiana filozofii bezpieczeństwa. SolarWinds, Colonial Pipeline, FrostyGoop - każdy z tych incydentów potwierdził, że model perymetryczny nie chroni organizacji przed zdeterminowanym przeciwnikiem. Organizacje, które podchodzą do Zero Trust fazowo - zaczynając od tożsamości i segmentacji, a kończąc na automatyzacji i ciągłej walidacji - osiągają mierzalne rezultaty bez paraliżu decyzyjnego.

Jeśli Twoja organizacja zarządza infrastrukturą OT, warto zacząć od oceny obecnego stanu segmentacji i kontroli dostępu. SEQRED realizuje audyty zgodności z IEC 62443, projektowanie architektury bezpieczeństwa i wdrożenia mikrosegmentacji w środowiskach przemysłowych. Pomagamy przejść od modelu perymetrycznego do Zero Trust bez zakłócania procesów produkcyjnych - umów bezpłatną rozmowę wstępną, podczas której ocenimy Twój punkt wyjścia.

Dodatkowe materiały na temat bezpieczeństwa pracy zdalnej i modelu Defense in Depth w systemach DCS znajdziesz w naszych powiązanych artykułach.

Źródła

• NIST SP 800-207 - Zero Trust Architecture (2020)
• CISA Zero Trust Maturity Model v2.0 (2023)
• CISA - Journey to Zero Trust: Microsegmentation Guidance (2025)
• DoD Zero Trust for Operational Technology Activities and Outcomes (2025)
• Gartner: 63% of Organizations Have Implemented Zero-Trust Strategy (2024)
• Gartner Predicts 10% of Large Enterprises Will Have Mature Zero-Trust Program by 2026 (2023)
• IBM Cost of a Data Breach Report 2025
• NIST SP 800-207A - Zero Trust Architecture Model for Cloud-Native Applications (2023)