Zero Trust w sieci: od segmentacji po kontrolę dostępu krok po kroku

Dlaczego klasyczny „mur i fosa” już nie działa

Tradycyjny model: zaufane wnętrze kontra zły Internet

Klasyczny model bezpieczeństwa sieci opierał się na prostym założeniu: wnętrze sieci firmowej jest zaufane, a Internet – nie. Budowało się więc solidną „fosę” w postaci zapory ogniowej na brzegu, wieszało IDS/IPS, czasem WAF, i uznawało, że dopóki atakujący nie przebije się przez brzeg, wszystko jest pod kontrolą.

Taki model ma jeden fundamentalny problem: jeśli komuś uda się dostać do środka, ma szerokie możliwości poruszania się. Płaska sieć, jeden lub kilka dużych VLAN-ów, reguły typu „ANY-ANY” dla ruchu wewnętrznego – to przepis na to, aby incydent z jednego komputera szybko stał się problemem całej organizacji.

Nowa rzeczywistość: praca zdalna, chmura i urządzenia wszędzie

Środowisko, dla którego projektowano „mur i fosę”, po prostu przestało istnieć. Użytkownicy łączą się:

• z domu, przez łącza od rozmaitych ISP,
• z laptopów, które wychodzą poza biuro i widziały więcej sieci Wi-Fi niż niejedno urządzenie IoT,
• do aplikacji SaaS, których nie chroni firmowy firewall brzegowy,
• do zasobów w chmurze publicznej, gdzie granica sieci jest umowna,
• z telefonów i tabletów, często prywatnych.

Do tego dochodzą systemy OT/IoT: kamery, sterowniki, panele HMI, „inteligentne” drukarki. Często nieaktualizowane, z domyślnymi hasłami, podpięte prosto do tej samej sieci, z której korzysta księgowość.

Gdy jednolita sieć zawodzi: typowe scenariusze ataku

Wystarczy kilka przykładów z codziennej praktyki:

• Przechwycone konto VPN – użytkownik daje się złapać na phishing, atakujący loguje się na VPN i widzi to samo, co pracownik: katalogi sieciowe, system ERP, drukarki, systemy wewnętrzne. Jeżeli ruch wewnętrzny jest „z definicji zaufany”, nic nie powstrzyma go przed skanowaniem i poruszaniem się w sieci.
• Ransomware na jednym laptopie – zainfekowany komputer użytkownika zaczyna szyfrować nie tylko lokalne dane, ale też wszystko, do czego ma dostęp w sieci: udział sieciowy, serwer plików, bazę danych. W płaskiej sieci ma dziś jedno uprawnienie, jutro kolejne, bo przecież „łatwiej dać dostęp wszystkim”.
• Kompro­mitacja serwera pomocniczego – stary serwer aplikacji, od lat nieaktualizowany, stoi w jednym VLAN-ie z serwerem bazodanowym i nowym CRM. Atakujący wykorzystuje znaną lukę, a po wejściu do środka ma już bezpośrednią drogę do zasobów krytycznych.

Konsekwencje „płaskiej” sieci: mały incydent, duży problem

Jednolita, słabo podzielona sieć sprawia, że zasięg każdego pojedynczego włamania jest nieproporcjonalnie duży. Nawet jeśli atakujący przejmie mało istotny komputer, szybki skan ARP i portów pozwoli mu:

• zlokalizować serwery plików i baz danych,
• namierzyć urządzenia z prostymi interfejsami HTTP (drukarki, kamery),
• odkryć nieudokumentowane serwery testowe,
• wykorzystać lateral movement do przejęcia kont uprzywilejowanych.

Bez segmentacji i ścisłej kontroli dostępu wewnątrz sieci, każda luka staje się furtką do reszty środowiska. To właśnie ten problem rozwiązuje Zero Trust.

„Nigdy nie ufaj, zawsze weryfikuj” jako nowy paradygmat

Zero Trust odwraca klasyczne myślenie: lokalizacja w sieci nie jest podstawą do zaufania. Fakt, że pakiety przychodzą z adresu LAN lub prywatnej podsieci, nie znaczy, że są bezpieczne. Sercem modelu jest zasada:

„Never trust, always verify” – nigdy nie ufaj z góry, zawsze weryfikuj tożsamość, kontekst i stan żądania.

Zero Trust w sieci przekłada się więc na segmentację, precyzyjene polityki dostępu, ciągłe monitorowanie i ograniczanie ruchu do absolutnego minimum potrzebnego do pracy. Zamiast jednej wielkiej strefy „inside” powstaje szereg stref i mikrosegmentów, a ruch pomiędzy nimi jest traktowany jak ruch z zewnątrz – wymaga uzasadnienia i kontroli.

Fundamenty Zero Trust w sieci – o co właściwie chodzi

Definicja z perspektywy sieci

Zero Trust w sieci oznacza, że żaden pakiet, połączenie ani urządzenie nie jest traktowane jako zaufane tylko dlatego, że znajduje się w sieci firmowej. Zaufanie jest budowane dynamicznie na podstawie:

• tożsamości użytkownika lub usługi,
• tożsamości i stanu urządzenia,
• kontekstu – skąd następuje połączenie, o której godzinie, do jakiego zasobu.

Wyrażając to brutalnie: Twoja sieć LAN nie jest siedliskiem dobra. Jest tylko kolejnym medium przesyłania pakietów. Zero Trust traktuje ją bardziej jak niebezpieczny Internet niż jak przytulną, rodzinną sieć domową.

Trzy filary: tożsamość, urządzenie, kontekst

Mówiąc o kontroli dostępu w Zero Trust, zawsze spotykają się trzy elementy:

• Tożsamość – kto lub co próbuje się połączyć? Użytkownik z AD, konto w IdP (Azure AD, Okta), usługa z certyfikatem, konto serwisowe?
• Urządzenie – z jakiego sprzętu korzysta? Komputer zarządzany (w domenie, z agentem EDR), prywatny laptop, smartfon, serwer w chmurze? Czy spełnia wymagania bezpieczeństwa (aktualne łatki, szyfrowanie dysku)?
• Kontekst – kiedy i skąd następuje połączenie? Z Polski o 10:00 czy z innego kontynentu o 3:00 w nocy? Do jakiej aplikacji, jaką metodą?

Polityki w Zero Trust opierają się łącznie na tych danych. Ta sama osoba może mieć inny poziom dostępu:

• z firmowego laptopa w biurze (pełny dostęp do CRM),
• z prywatnego telefonu (tylko odczyt maili przez przeglądarkę),
• z nieznanego urządzenia (brak dostępu do krytycznych systemów).

Zero Trust a „Zero Faith” – gdzie kończy się marketing

Zero Trust nie oznacza magicznego „zerowego zaufania do wszystkiego”, bo system bez żadnego zaufania nie działa w ogóle. W praktyce:

• ustalasz jasne kryteria, kiedy komuś ufasz na określonym poziomie (np. MFA + zarządzane urządzenie + zgodność z polityką),
• zaufanie jest granularne i czasowe – dotyczy konkretnych akcji i może wygasać,
• zaufanie jest weryfikowane przy każdym ważnym kroku, a nie tylko przy pierwszym logowaniu.

Różnica między marketingowym hasłem a realną architekturą jest taka, że w tej drugiej masz:

• konkretne polityki dostępu dla aplikacji i segmentów sieci,
• techniczne mechanizmy wymuszające te polityki (firewalle, NAC, proxy, agenty),
• ciągłe logowanie i monitorowanie, pozwalające oceniać, czy polityki działają.

Kluczowe komponenty Zero Trust w obszarze sieci

Zero Trust w sieci opiera się na kilku grupach narzędzi i technik:

• Segmentacja – logiczny podział sieci na strefy i mikrosegmenty (VLAN, VRF, SDN, host-based firewall).
• Kontrola dostępu – polityki kto/co może się z czym łączyć (firewalle, ACL, NAC, proxy, brokerzy dostępu).
• Inspekcja ruchu – analiza i filtrowanie ruchu między segmentami (NGFW, IDS/IPS, filtrowanie DNS, inspekcja TLS, DLP).
• Rejestrowanie i analiza – zbieranie logów i metadanych ruchu (NetFlow/sFlow, logi firewalli, SIEM, NDR), wykrywanie anomalii.

Model Zero Trust w sieci nie zastępuje firewalli ani VPN, tylko zmienia sposób, w jaki są używane: firewall nie jest już tylko na brzegu, a VPN nie daje „pełnego tunelu do wszystkiego”.

Integracja Zero Trust z istniejącą infrastrukturą

W typowej firmie już funkcjonują:

• firewalle brzegowe,
• VPN dla zdalnych użytkowników,
• przełączniki z obsługą VLAN-ów,
• system katalogowy (AD/LDAP) i/lub IdP w chmurze,
• może NAC, może jakieś EDR/antywirus.

Zero Trust nie polega na wyrzuceniu tego wszystkiego i kupieniu nowego „pudełka Zero Trust”. Zamiast tego:

• wykorzystuje aktualne firewalle do kontroli ruchu między segmentami,
• modyfikuje konfigurację VPN, aby dawał dostęp tylko do niezbędnych zasobów,
• rozszerza rolę AD/LDAP/IdP – tożsamość decyduje o dostępie w sieci,
• wprowadza mikrosegmentację najpierw w krytycznych obszarach – np. na serwerach kluczowych aplikacji.

Diagnoza stanu obecnego – bez mapy sieci nic nie ruszy

Inwentaryzacja zasobów: co właściwie chronisz

Pierwszy krok do Zero Trust w sieci to brutalne pytanie: co tak naprawdę jest w tej sieci? Zazwyczaj odpowiedź „mamy wszystko w CMDB” okazuje się mocno optymistyczna. Aby projekt segmentacji miał sens, potrzebna jest inwentaryzacja:

• Serwerów – fizycznych i wirtualnych, on-prem i w chmurze.
• Aplikacji – biznesowych (ERP, CRM, HR, produkcja), pomocniczych (helpdesk, monitoring), wewnętrznych (API, integracje).
• Urządzeń końcowych – laptopy, desktopy, terminale, mobilne.
• Urządzeń sieciowych – routery, przełączniki, AP, kontrolery.
• OT/IoT – wszystko, co „mówi IP”, a nie jest klasycznym komputerem.
• Zasobów w chmurze – VM-ki, kontenery, usługi PaaS.

Warto zebrać informacje takie jak: nazwa systemu, funkcja, właściciel biznesowy, system operacyjny, lokalizacja (VLAN, lokalizacja fizyczna/chmura), powiązane aplikacje.

Mapowanie przepływów: kto i do czego się łączy

Inwentaryzacja mówi co mamy, ale Zero Trust wymaga jeszcze wiedzy jak to ze sobą rozmawia. Potrzebna jest mapa przepływów:

• jakich systemów używają poszczególne działy (księgowość, HR, sprzedaż, produkcja),
• jakie serwery rozmawiają ze sobą (aplikacja webowa – serwer aplikacyjny – baza danych),
• jakie integracje zewnętrzne istnieją (API partnerów, bramki płatności, usługi pocztowe, SSO),
• które procesy wymagają dostępu między lokalizacjami lub do chmury.

Można zacząć od wywiadu z działami biznesowymi i właścicielami systemów, ale na koniec i tak rzeczywistość trzeba skonfrontować z ruchem w sieci.

Klasyfikacja zasobów: priorytety segmentacji

Zero Trust w sieci nie polega na tym, że wszystko od razu ląduje w mikrosegmentach z regułą „deny all” i modlitwą, że systemy się nie wywrócą. Trzeba ustalić priorytety:

• Zasoby krytyczne – systemy, których utrata lub wyciek zaboli najbardziej: ERP, systemy finansowe, dane klientów, system produkcyjny, AD.
• Zasoby wrażliwe – HR, dokumenty prawne, projekty, repozytoria kodu.
• Zasoby standardowe – mniej wrażliwe systemy użytkowe: intranet, drukarki, system rezerwacji sal.
• Środowiska testowe/dev – ważne, ale zazwyczaj mniej regulowane, za to często zaniedbane.

Na tej podstawie określa się, gdzie Zero Trust musi pojawić się najpierw: zwykle są to strefy z danymi krytycznymi i systemy sterujące dostępem (AD, IdP, PKI).

Narzędzia do mapowania ruchu i zależności

Zaglądanie w konfiguracje bywa niewystarczające. Do zbudowania realnej mapy połączeń przydają się:

Źródła danych: gdzie szukać prawdy o ruchu

Do analizy zależności między systemami przydają się zarówno istniejące logi, jak i dane z samej infrastruktury. W praktyce zwykle miesza się kilka podejść:

• Logi firewalli i proxy – pokazują, kto z kim rozmawia, po jakich portach i protokołach, często również z informacją o użytkowniku (integracja z AD/IdP).
• NetFlow/sFlow/IPFIX z routerów i przełączników – dobry obraz ruchu między podsieciami i serwerami, szczególnie przy większej skali.
• Agentowe rozwiązania na hostach (EDR, monitorowanie aplikacji) – precyzyjna informacja, jakie procesy łączą się z jakimi adresami.
• Logi aplikacyjne – szczególnie przy integracjach HTTP/HTTPS i API, gdzie goły ruch sieciowy nie zawsze powie co to za funkcja biznesowa.

Z samych surowych logów segmentacji się nie zbuduje. Dane trzeba:

• skorelować (SIEM, NDR lub choćby własne skrypty),
• oczyścić z szumu (skanowania, backupy, diagnostyka),
• zderzyć z wiedzą ludzi – architektów, adminów, właścicieli systemów.

Uproszczenie krajobrazu: co można wyłączyć zamiast segmentować

Zanim cokolwiek zacznie się dzielić na segmenty, dobrze jest odpowiedzieć na jedno niewygodne pytanie: czego w ogóle nie trzeba już utrzymywać? Często na mapie wychodzą:

• stare serwery testowe, o których nikt nie pamięta,
• aplikacje używane przez jeden dział „kiedyś”,
• nieużywane integracje do dawnych partnerów,
• duplikaty usług (dwa systemy ticketowe, dwa intranety, itp.).

Każdy wyłączony system to:

• mniej wyjątków w politykach,
• mniej reguł firewalli,
• mniej pracy przy migracjach i testach.

Z reguły praca „segregacyjna” (co wyrzucić, co połączyć, co uprościć) zwraca się wielokrotnie przy późniejszym projektowaniu segmentacji. Zdecydowanie lepiej jest odciąć martwy system, niż heroicznie chronić go w trzech mikrosegmentach.

Projekt segmentacji sieci – od stref do mikrosegmentacji

Strefy bezpieczeństwa: pierwszy podział sieci

Pierwszy krok to zdefiniowanie stref bezpieczeństwa, czyli logicznych obszarów o podobnym poziomie ryzyka i wymaganiach. W większości organizacji naturalnie pojawiają się:

• Strefa użytkowników – laptopy, desktopy, BYOD (jeśli dopuszczone), terminale.
• Strefa serwerów wewnętrznych – systemy biznesowe, bazy danych, usługi integracyjne.
• Strefa DMZ / usług publikowanych – systemy dostępne z Internetu lub partnerów.
• Strefy specjalne – OT/SCADA, laboratoria, środowiska test/dev, segmenty wysokiego poziomu bezpieczeństwa (np. dla kryptografii, PKI).

Dobrze zaprojektowane strefy:

• minimalizują konieczne połączenia między sobą,
• mają zdefiniowaną klasę danych i typowe profile zagrożeń,
• są zrozumiałe dla działu biznesowego (da się wyjaśnić, dlaczego coś trafia do danej strefy).

Model ruchu między strefami: co z czym może rozmawiać

Po zdefiniowaniu stref potrzebna jest matryca ruchu – prosta tabela, która opisuje:

• czy ruch między dwiema strefami jest dozwolony,
• jeśli tak – w jakich kierunkach i po jakich protokołach,
• kto o tym decyduje (właściciele systemów, bezpieczeństwo, sieci).

Przykładowo:

• Strefa użytkowników → serwery wewnętrzne: tylko protokoły aplikacyjne (HTTPS, SSH przez bastion, RDP przez gateway).
• Serwery wewnętrzne → Internet: tylko przez proxy/aplikacyjny firewall, bez „gołego” dostępu.
• Test/dev → produkcja: brak bezpośredniego ruchu, jedynie kontrolowane migracje przez repozytorium/CI/CD.

Taka matryca staje się później fundamentem:

• reguł firewalli,
• polityk NAC,
• konfiguracji SDN/segmentation gateway,
• zasad dostępu w chmurze (Security Groups, Network Policies w Kubernetes itp.).

Mikrosegmentacja: kiedy podsieć to za mało

Podział na VLAN-y i podsieci to dopiero wstęp. W Zero Trust nie zakłada się, że wszystkie hosty w podsieci mogą ze sobą gadać bez ograniczeń. Mikrosegmentacja ogranicza komunikację:

• między serwerami w tej samej podsieci,
• między instancjami tej samej aplikacji w klastrze,
• między usługami w ramach jednego środowiska (np. w Kubernetes).

Do mikrosegmentacji można podejść na kilka sposobów:

• Host-based firewall (Windows Firewall, iptables/nftables, agenty bezpieczeństwa) – reguły na samych serwerach i stacjach końcowych.
• SDN/segmentation gateway – centralne definiowanie polityk komunikacji między workloadami, niezależnie od podsieci.
• Service mesh w środowiskach kontenerowych – kontrola ruchu na poziomie usług, nie adresów IP.

Mikrosegmentacja nie musi od razu objąć wszystkiego. Najrozsądniej jest zacząć od:

• aplikacji krytycznych (ERP, systemy finansowe, produkcja),
• systemów kontroli tożsamości (AD, IdP, PKI),
• systemów administracyjnych (narzędzia zdalnego zarządzania, konsola backupu, monitoring).

Model uprawnień: least privilege w praktyce sieciowej

Zasada least privilege w sieci oznacza, że:

• każdy klient łączy się tylko z usługami, których rzeczywiście potrzebuje,
• serwery widzą tylko tych klientów, którzy są im potrzebni do działania,
• administracja odbywa się przez ograniczone, dedykowane kanały (bastiony, jump hosty, VPN z silną autentykacją).

Dla przykładu:

• pracownik działu HR ma dostęp do aplikacji kadrowej po HTTPS, ale nie do bazy danych tej aplikacji po TCP/1433.
• administrator systemowy łączy się z serwerami tylko przez bastion, a nie bezpośrednio z laptopa.

W praktyce dobrze działa podejście:

• projektowe – nowy system od razu dostaje „wąski” zestaw połączeń,
• iteracyjne – dla istniejących systemów wprowadzanie ograniczeń etapami, z monitoringiem i okresem „alert only”, zanim reguły zaczną blokować.

Strategia wdrożenia: od brzegów do środka czy odwrotnie

Przy projektowaniu segmentacji pojawia się pytanie, od czego zacząć. Zazwyczaj sprawdzają się dwa scenariusze (często łączone):

• Od stref krytycznych – najpierw porządek w segmencie serwerów kluczowych, AD, IdP, DMZ; dopiero potem „biuro” i reszta.
• Od nowych systemów – nowa aplikacja od startu ma segmentację i mikrosegmentację, a stare systemy są migrowane stopniowo.

Podejście „najpierw wszystko przeprojektujmy, potem włączymy” zazwyczaj kończy się albo paraliżem, albo odkładaniem projektu latami. Lepiej wdrażać Zero Trust sieciowy iteracyjnie:

• wybrać 1–2 systemy,
• wypracować na nich podejście do mapowania przepływów i testowania,
• powielić schemat dla kolejnych obszarów.

Techniczne metody segmentacji – VLAN, ACL, firewalle, SDN, NAC

Segmentacja VLAN: klasyk, który dalej ma sens

VLAN-y nadal są podstawowym narzędziem fizyczno-logicznego podziału sieci. Stosuje się je do:

• separacji ruchu użytkowników od serwerów,
• wydzielenia sieci gościnnej, BYOD, urządzeń IoT/OT,
• tworzenia osobnych segmentów dla różnych lokalizacji lub pięter.

Kilka praktycznych zasad:

• Unikaj „wielkich flat VLAN-ów” – 500 urządzeń w jednym segmencie użytkowników nie sprzyja ani bezpieczeństwu, ani zarządzaniu.
• Taguj VLAN-y zgodnie z przeznaczeniem (np. V10_USERS-HR, V30_SERVERS-ERP), żeby z samej nazwy było wiadomo, co to jest.
• Ogranicz trunki i rozsiewanie VLAN-ów – VLAN nie powinien występować na każdym przełączniku „na wszelki wypadek”.

VLAN resolution sam w sobie nie zapewnia jeszcze Zero Trust, ale daje fundament pod egzekwowanie polityk na granicach podsieci (routowanie, firewalle, ACL).

ACL na routerach i przełącznikach: szybka kontrola pierwszej linii

Access Control Lists (ACL) na routerach i przełącznikach warstwy 3 pozwalają:

• blokować lub ograniczać ruch między VLAN-ami,
• realizować proste polityki typu „tylko DNS, DHCP i proxy dozwolone z tego segmentu do reszty sieci”,
• odciąć znane, niepożądane protokoły (np. SMB z sieci gościnnej).

Stosując ACL-e, dobrze jest:

• traktować je jako mechanizm wspomagający segmentację, a nie główny firewall,
• utrzymywać ich konfigurację w repozytorium (Git), z opisem celu każdej listy,
• standaryzować szablony – te same typy segmentów powinny mieć podobne zestawy ACL.

Firewalle: od brzegu do wewnętrznych stref

W modelu Zero Trust firewalle nie żyją tylko na brzegu sieci. Coraz częściej:

• pojawiają się między strefami (user ↔ serwery, serwery ↔ DMZ, produkcja ↔ test/dev),
• kontrolują ruch VLAN ↔ VLAN zamiast prostego routingu L3,
• zapewniają inspekcję aplikacyjną, a nie tylko filtrowanie portów.

Dla firewalli w Zero Trust kluczowe są:

• polityki oparte o tożsamość – integracja z AD/IdP, reguły typu „grupa Finanse → aplikacja ERP” zamiast „IP → port”,
• kontrola aplikacyjna – reguły na poziomie „aplikacja biznesowa X”, „Office 365”, „SSH”, nie tylko „TCP/443”,
• centralne zarządzanie – jeden punkt definiowania i audytowania polityk, szczególnie gdy firewalli jest kilka/kilkanaście.

Ważne, aby nie przerodzić ich w jednego „superfirewalla” z milionem reguł. Lepiej jest mieć:

• kilka logicznych polityk (per strefa, per aplikacja),
• czytelną strukturę (nazwy, opisy, grupowanie),
• proces przeglądu i usuwania starych reguł.

SDN i wirtualne sieci: segmentacja w warstwie abstrakcji

W środowiskach wirtualnych i chmurowych coraz częściej wykorzystuje się rozwiązania typu:

• SDN w data center (NSX, ACI, Contrail, itp.),
• grupy bezpieczeństwa w chmurze (AWS SG, Azure NSG),
• polityki sieciowe w Kubernetes.

Ich wspólna cecha: polityki bezpieczeństwa przestają być przypisane do fizycznych interfejsów i VLAN-ów, a stają się:

• powiązane z maszynami wirtualnymi, tagami, grupami aplikacji,
• dynamicznie zmieniane przy skalowaniu (tworzenie/usuwanie instancji),
• częścią definicji środowiska (Infrastructure as Code).

To idealne miejsce na mikrosegmentację:

• łatwiej opisać politykę „frontend może mówić z backend po HTTPS, backend z bazą tylko po TCP/5432” niż zarządzać stosami adresów IP,
• zmiany w aplikacji (nowe instancje) nie wymagają ręcznego dodawania IP do list firewalli.

NAC: dynamiczne przypisywanie urządzeń do segmentów

Network Access Control (NAC) pozwala podjąć decyzję o wpuszczeniu urządzenia do sieci i przydzielić mu odpowiedni segment na podstawie:

Ocena stanu urządzenia i kontekstu

Typowy system NAC zbiera kilka klas informacji, zanim przydzieli urządzenie do konkretnego VLAN-u lub profilu dostępowego:

• Tożsamość użytkownika – kto się loguje (AD, Azure AD, inne IdP), do jakiej grupy należy, czy używa MFA.
• Typ i właściciel urządzenia – korporacyjny laptop, prywatny telefon, drukarka, kamera IP, sterownik PLC.
• Stan bezpieczeństwa endpointa – aktualny antywirus/EDR, szyfrowanie dysku, włączone aktualizacje, brak znanych zagrożeń.
• Lokalizacja i sposób połączenia – konkretne gniazdo na przełączniku, sieć Wi-Fi gościnna, VPN, zdalne biuro.

Na tej podstawie NAC może:

• przypisać odpowiedni VLAN (produkcyjny, gościnny, kwarantanna),
• zastosować określony zestaw ACL lub profili QoS,
• całkowicie odmówić dostępu lub dopuścić tylko do portalu rejestracji/lecznicy (remediacji).

Tryby działania NAC: od biernego do „bezlitosnego”

Przy planowaniu NAC przydaje się łagodne wejście – inaczej projekt kończy się nerwowym sprintem po biurze z wyłączonym Wi-Fi. Typowy cykl:

• Monitor-only – system tylko zbiera informacje: kto, skąd, z czym się łączy. Żadnego blokowania.
• Partial enforcement – zasady wymuszane na wybranych segmentach (np. goście, sale konferencyjne, nowe piętro biura).
• Full enforcement – polityki obejmują większość sieci przewodowej i Wi-Fi, a dostęp „dziki” jest wyjątkiem, nie regułą.

Ważne, by od początku mieć gotowy plan ratunkowy:

• procedura „wyłączenia” NAC (np. tymczasowe przejście w tryb permissive),
• lista krytycznych urządzeń, których nie wolno odciąć (systemy medyczne, przemysłowe, bezpieczeństwa),
• jasne instrukcje dla servicedesku: co pytać użytkownika i co sprawdzić.

Integracja NAC z segmentacją i tożsamością

NAC ma sens dopiero wtedy, gdy jest spięty z resztą układanki:

• przełączniki i kontrolery Wi-Fi – dynamiczne VLAN-y, ACL per port i per SSID, tagowanie ruchu,
• firewalle – klasyfikacja ruchu na podstawie przydzielonej roli/segmentu,
• IdP / AD – mapowanie użytkowników i grup na polityki dostępu.

Przykładowo: użytkownik z grupy Finanse loguje się na laptop korporacyjny do Wi-Fi w centrali. NAC weryfikuje jego tożsamość, stan stacji i lokalizację, po czym:

• przydziela VLAN „V20_USERS-FIN”,
• nakłada odpowiedni profil ACL (dostęp do ERP, brak dostępu do segmentu OT),
• oznacza ruch tagiem/rolą, którą firewall wykorzystuje do precyzyjnych reguł.

Ograniczenia i pułapki NAC

NAC reklamowany jest często jako magiczne pudełko, które „wszystko rozwiąże”. Rzeczywistość bywa mniej romantyczna:

• urządzenia legacy/OT – brak wsparcia 802.1X, nieprzewidywalne zachowanie przy wymuszaniu polityk; często trzeba korzystać z profili typu MAB (MAC Authentication Bypass) i statycznych reguł.
• skalowalność – zbyt złożone polityki i brak standardów nazewnictwa prowadzą do bałaganu gorszego niż przed wdrożeniem.
• zależność od infrastruktury – stare przełączniki bez obsługi 802.1X, RADIUS CoA czy dynamicznych ACL mocno ograniczają możliwości.

Rozsądne podejście: zbudować kilka szablonowych polityk (korporacyjny laptop, BYOD, IoT, gość, serwer) i dopiero później dopieszczać wyjątki. Odwrotna kolejność kończy się katalogiem wyjątków grubości „Pana Tadeusza”.

Tożsamość jako nowy perymetr – użytkownicy, urządzenia, usługi

Od adresów IP do tożsamości

Sieć Zero Trust przestaje ufać adresowi IP. Kluczowe pytanie brzmi nie „z jakiego IP przychodzisz?”, ale „kim jesteś i z jakiego kontekstu korzystasz?”. Dotyczy to:

• użytkowników (logujących się do laptopa, VPN, aplikacji SaaS),
• urządzeń (komputer zarządzany, BYOD, serwer, IoT),
• usług i mikroserwisów (machine identity, workload identity).

Adres IP staje się jednym z atrybutów kontekstu – przydatnym, ale zdecydowanie niewystarczającym do decyzji o dostępie.

Tożsamość użytkownika: role, grupy, atrybuty

Rdzeniem pozostaje katalog tożsamości (AD, Azure AD, LDAP, inne IdP). Dobrze zorganizowany katalog to połowa sukcesu Zero Trust. Praktyczne elementy:

• grupy oparte o rolę, nie imię – APP_ERP_FINANCE_READ zamiast GRUPA_KASI_I_MAĆKA,
• atrybuty organizacyjne – dział, lokalizacja, typ umowy; przydają się w politykach warunkowego dostępu,
• oddzielenie ról administracyjnych – konta ADM i UPN „zwykłe” nie powinny mieć tych samych praw ani ścieżek dostępu.

Mechanizmy kontroli sieciowej (VPN, ZTNA, firewalle, proxy) powinny rozumieć te tożsamości i atrybuty, a nie tylko IP klienta.

MFA i silne uwierzytelnianie jako warunek wejścia

Bez silnego uwierzytelniania Zero Trust zamienia się w Zero Sense. Zamiast jednego hasła wchodzi:

• MFA – push, TOTP, klucze sprzętowe (FIDO2), certyfikaty klienta,
• kontekst logowania – lokalizacja, typ urządzenia, pora dnia, ryzyko behawioralne.

W sieci widać to np. tak:

• VPN lub ZTNA pozwala na pełny dostęp tylko po poprawnym MFA; bez tego użytkownik trafia do bardzo ograniczonej strefy.
• próba logowania z nowego kraju wymaga silniejszego czynnika (np. fizycznego klucza).

Tożsamość urządzenia: endpoint jako uczestnik polityki

Użytkownik z silną tożsamością i MFA na zainfekowanym laptopie nadal jest problemem. Dlatego do gry wchodzi device identity:

• rejestracja urządzeń w MDM/EDR (Intune, Workspace ONE, itp.),
• certyfikaty maszynowe – wykorzystywane do 802.1X, VPN, TLS mTLS,
• compliance – polityki wymuszające szyfrowanie dysku, blokadę ekranu, podstawowe zabezpieczenia.

Dopiero połączenie tożsamości użytkownika i stanu urządzenia tworzy sensowny warunek:

• „użytkownik z grupy Finanse i zgodny laptop korporacyjny” → pełny dostęp do aplikacji finansowych,
• „użytkownik z grupy Finanse ale prywatny telefon” → dostęp tylko do webowego self-service z ograniczoną funkcjonalnością.

Tożsamość usług i workloadów

Serwery, mikroserwisy, funkcje serverless – wszystkie te elementy też potrzebują tożsamości. Inaczej skończy się na „wszyscy do wszystkich po 1433, bo inaczej nie działa”.

Stosuje się m.in.:

• certyfikaty TLS z unikalnym CN/SAN dla usług i serwerów,
• service accounts w AD/Kubernetes (SPN, managed identities),
• workload identity w chmurach (IAM role, managed identities w Azure, itp.).

Po stronie sieci/surowych polityk widać to jako:

• mTLS między mikroserwisami w service mesh – ruch jest autoryzowany na podstawie certyfikatu podmiotu, nie IP,
• polityki typu „aplikacja A (identity X) może rozmawiać z bazą (identity Y) tylko po TDS/1433”.

ZTNA i „VPN, który nie wpuszcza do sieci”

Zero Trust Network Access (ZTNA) to odpowiedź na klasyczny VPN, który po zalogowaniu robi z użytkownika „lokalnego mieszkańca” sieci. W podejściu ZTNA:

• użytkownik dostaje dostęp per aplikacja, a nie per sieć,
• kanał jest najczęściej proxy’owany (reverse proxy, tunel) do konkretnego serwisu,
• decyzja o dostępie zapada na podstawie tożsamości, urządzenia i kontekstu.

Przykład praktyczny:

• pracownik loguje się z domu do portalu ZTNA, przechodzi MFA,
• w portalu widzi tylko aplikacje, do których ma uprawnienia (ERP, CRM, Intranet),
• nie ma możliwości skanowania sieci wewnętrznej ani łączenia się „po IP” – bo nigdy faktycznie do tej sieci nie wchodzi.

Kontekst i ciągła weryfikacja (continuous verification)

Samo „uwierzytelnij się raz i zapomnij” nie przystaje do Zero Trust. Decyzje o dostępie powinny być odświeżane w czasie:

• zmiana lokalizacji lub adresu IP w trakcie sesji może wymusić ponowne MFA lub zawężenie uprawnień,
• wykrycie incydentu na endpointzie przez EDR może spowodować przeniesienie urządzenia do segmentu kwarantanny (przez NAC/SDN),
• podniesienie poziomu ryzyka (np. niestandardowe zachowanie) może tymczasowo blokować dostęp do krytycznych aplikacji.

Tożsamość, stan urządzenia i zachowanie użytkownika tworzą razem dynamiczny scoring ryzyka, który systemy sieciowe powinny potrafić zrozumieć i wykorzystać.

Mapowanie polityk biznesowych na polityki techniczne

Zero Trust oparty o tożsamość wymaga przełożenia języka biznesu („pracownicy działu sprzedaży nie powinni widzieć danych płacowych”) na język sieci i systemów. Schemat postępowania:

1. Zdefiniuj role – kto jest kim (Sales, HR, Finanse, Admini), jakie mają zadania.
2. Przypisz aplikacje – które systemy są potrzebne danej roli, na jakim poziomie (odczyt, zapis, admin).
3. Zidentyfikuj kanały dostępu – z biura, z domu, z telefonu, przez terminale w fabryce.
4. Przekuj to na polityki – grupy w IdP, role w ZTNA/VPN, tagi w SDN, reguły firewalli.

Dobrze zrobione mapowanie pozwala potem powiedzieć: „Uruchom nową lokalizację dla działu sprzedaży” i sprowadzić to do przypisania użytkowników do roli i segmentu, zamiast tygodni ręcznego pisania ACL-i.

Minimalizacja przywilejów w oparciu o tożsamość

Zasada least privilege w wymiarze tożsamości oznacza, że:

• użytkownik ma domyślnie brak dostępu, a nie „szeroki, żeby nie przeszkadzać w pracy”,
• uprawnienia są wiązką ról (role-based access control), a nie kolekcją indywidualnych wyjątków,
• system ma procedurę tympczasowego podnoszenia uprawnień (just-in-time access) zamiast stałych praw admina.

W sieci przekłada się to np. na:

• dedykowane profile dostępu dla administratorów, ważne aby rozdzielały ruch administracyjny od „użytkowego”,
• brak „any-any” z kont serwisowych – każde konto usługi powinno mieć dokładnie określoną listę dozwolonych połączeń,
• czasowe dostępy do krytycznych systemów logowane i zatwierdzane (np. przez bastion / PAM).

Praktyczne kroki budowy perymetru opartego na tożsamości

Zamiast przebudowywać wszystko w jeden weekend, lepiej podzielić prace na krótsze odcinki:

• Porządek w katalogu – ujednolicenie grup, usunięcie martwych kont, wprowadzenie naming convention.
• MFA „wszędzie, gdzie się da” – od zdalnego dostępu, przez panele administracyjne, po kluczowe aplikacje webowe.
• Segmentacja VPN/ZTNA – koniec z jednym „domyślnym” profilem z pełnym dostępem; profile per rola, per aplikacja.
• Integracja z siecią – mapowanie grup/claimów z IdP na role w NAC, SDN, firewallach.

Opracowano na podstawie

• Zero Trust Architecture. NIST (2020) – Podstawowa definicja i model architektury Zero Trust
• SP 800-41 Revision 1: Guidelines on Firewalls and Firewall Policy. NIST (2009) – Rola zapór sieciowych i polityk w segmentacji i kontroli dostępu
• Zero Trust Security: An Enterprise Guide. O'Reilly Media (2021) – Praktyczne wdrożenia Zero Trust, segmentacja, kontrola dostępu
• Zero Trust Segmentation for Dummies. Wiley (2022) – Wprowadzenie do mikrosegmentacji i ograniczania ruchu lateralnego
• Zero Trust Security Playbook. Microsoft (2021) – Model Zero Trust z perspektywy tożsamości, urządzeń i sieci