Dlaczego „Zero Trust” w sieciach firmowych to nie kolejny buzzword
Od twardego perymetru do świata bez granic
Przez lata model bezpieczeństwa sieci firmowych opierał się na prostym założeniu: jest „nasza” sieć wewnętrzna (zaufana) i „zły Internet” (niezaufany). Stawiało się mocny firewall na brzegu, kilka reguł, może IDS/IPS, VPN dla zdalnych i sprawa była załatwiona. W środku sieć LAN często przypominała jedno wielkie osiedle bez ogrodzeń – wszyscy mieszkańcy mogli chodzić, gdzie chcieli.
Ten model działał jako tako, dopóki użytkownicy siedzieli głównie w biurze, aplikacje były w serwerowni, a laptopy nie opuszczały budynku. Dziś sytuacja wygląda inaczej: praca hybrydowa, dostęp z domu, z kawiarni, z telefonu, aplikacje w chmurze, SaaS, integracje z systemami dostawców. Granica sieci rozlała się po świecie i trudno wskazać, gdzie dokładnie przebiega „brzeg”.
Do tego dochodzi fakt, że atakujący nauczyli się genialnie wykorzystywać zaufanie wewnątrz sieci. Klasyczne podejście: jeden skuteczny phishing, jedno zainfekowane urządzenie i zaczyna się lateral movement – powolne, niewidoczne przesuwanie się po sieci, podnoszenie uprawnień, skanowanie, aż w końcu dojście do systemów krytycznych. Perymetr został pokonany, a w środku często nie ma już poważnych barier.
„Zaufana sieć wewnętrzna” kontra rzeczywistość hybrydowa
Hasło „zaufana sieć wewnętrzna” brzmi dziś dość naiwnie. W typowej organizacji urządzenia, użytkownicy i aplikacje są rozproszone:
pracownicy korzystają z laptopów podłączonych raz do LAN, raz do Wi-Fi w domu, raz do hotspotu w telefonie,
krytyczne systemy CRM czy ERP działają w chmurze lub modelu SaaS, poza klasycznym LAN,
część usług hostowana jest u zewnętrznych dostawców, z którymi często integrujemy się przez API,
w sieci pojawiają się urządzenia IoT, drukarki, kamery, systemy OT – często z kiepskim poziomem bezpieczeństwa.
W takim otoczeniu hasło „sieć wewnętrzna jest zaufana” zaczyna przypominać wiarę w to, że w wielkim centrum handlowym wszyscy klienci są mili i uczciwi, więc kamery i ochrona są zbędne. Architektura Zero Trust wychodzi z założenia dokładnie odwrotnego: zaufanie nie wynika z lokalizacji (LAN/WAN/Internet), ale z tożsamości, kontekstu i spełnienia określonych warunków bezpieczeństwa.
Dlaczego sam firewall na brzegu nie wystarcza
Firewall brzegowy wciąż ma sens, ale stał się tylko jednym z elementów szerszej układanki. Ataki z ostatnich lat pokazują wyraźnie kilka bolesnych zjawisk:
Lateral movement – po przejęciu jednego hosta atakujący wielokrotnie wykorzystywali brak segmentacji LAN do przejścia na serwery plików, kontrolery domeny, bazy danych. Jeden otwarty port SMB, jeden wspólny VLAN biurowy, brak kontroli ruchu wschód-zachód i szkody rosną lawinowo.
Ransomware – oprogramowanie szyfrujące bardzo efektywnie wykorzystuje fakt, że wielu użytkowników ma dostęp do dużych udziałów plikowych i że serwery są wzajemnie widoczne w sieci. Bez mikrosegmentacji i kontroli uprawnień ransomware często „widzi” zdecydowanie za dużo.
BYOD i urządzenia niezarządzane – telefony, prywatne laptopy, urządzenia IoT, systemy gości. Nawet jeśli są w osobnych VLAN-ach, często istnieje wiele wyjątków reguł firewalli, które z czasem stają się niekontrolowaną listą „tymczasowych” dziur. Zaufanie oparte na samym adresie IP przestaje być racjonalne.
SaaS i chmura – ruch do Office 365, Salesforce czy innych usług SaaS często omija klasyczny perymetr (np. split-tunneling w VPN, bezpośredni dostęp z domu). W takim scenariuszu koncepcja „wejścia do sieci firmowej przez VPN i firewall” nie ma pokrycia w rzeczywistości użytkownika.
Zero Trust jako sposób myślenia, nie produkt
Zero Trust bywa sprzedawane przez vendorów jako „platforma”, „gateway”, „magiczne rozwiązanie”. Tymczasem to przede wszystkim model myślowy i zestaw zasad, które nakłada się na istniejące procesy, architekturę i narzędzia. Możesz wdrożyć sporo elementów Zero Trust, nie kupując żadnego nowego pudełka – reorganizując segmentację, polityki dostępu, sposób zarządzania tożsamościami.
Kluczowa zmiana polega na tym, że przestajesz zadawać pytanie: „czy ten ruch jest z sieci wewnętrznej?”, a zaczynasz pytać: „kim jest ten użytkownik/usługa?”, „z jakiego urządzenia i w jakim stanie bezpieczeństwa pochodzi ruch?”, „do jakiego zasobu próbuje się dostać i czy to ma sens biznesowy?”.
Zero Trust w sieciach firmowych wymusza inne projektowanie relacji: każdy ruch sieciowy jest potencjalnie podejrzany, dopóki nie zostanie udowodnione, że jest zgodny z polityką. Nie wystarcza jednorazowa weryfikacja przy logowaniu – potrzeba ciągłej kontroli i korelacji sygnałów z różnych systemów.
Krótki, realistyczny przykład z „jednym laptopem z księgowości”
W średniej firmie przemysłowej księgowa otworzyła załącznik w mailu podszywającym się pod kontrahenta. Antywirus nie zareagował, exploit zadziałał. Laptop był w tym samym VLAN-ie, co reszta biura, a serwer plików i system ERP były dostępne przez kilka otwartych portów „bo kiedyś aplikacja tak wymagała”.
Atakujący w ciągu kilkunastu godzin:
wykonał skan sieci lokalnej z zainfekowanego laptopa,
znalazł serwer plików i serwer aplikacji,
wykorzystał słabe hasło lokalnego konta administracyjnego, identyczne na kilku serwerach,
dostał się do środowiska produkcyjnego, gdzie były kolejne połączenia „na skróty” między systemami.
Gdyby wdrożono chociaż podstawowe elementy Zero Trust – segmentację logiczną między biurem a serwerami, kontrolę dostępu opartą na grupach i tożsamości, ograniczone porty i monitorowanie nietypowych przepływów – szkody prawdopodobnie zakończyłyby się na jednym komputerze. To właśnie różnica między buzzwordem z prezentacji a realnym wpływem architektury na incydent.
Źródło: Pexels | Autor: Matias Mango
Fundamenty Zero Trust: zasady, na których opiera się architektura sieci
„Never trust, always verify” – co to znaczy technicznie
Hasło „never trust, always verify” brzmi jak slogan z konferencji, ale w sieci firmowej przekłada się na bardzo konkretne zachowania urządzeń i systemów. Na poziomie pakietów oznacza to, że każda nowa komunikacja jest oceniana pod kątem polityki – nie tylko przy pierwszym wejściu do sieci, ale przy każdym dostępie do zasobu.
Na poziomie sesji TCP oznacza to, że firewall, proxy lub gateway ZTNA nie opiera się wyłącznie na jednorazowym uwierzytelnieniu. Stan sesji jest powiązany z tożsamością użytkownika, urządzenia i dodatkowymi atrybutami. Jeśli w trakcie zmienia się kontekst (np. urządzenie nagle staje się niezgodne z polityką, pojawia się podejrzana aktywność), sesja może być przerwana lub ograniczona.
Na poziomie użytkownika zasada „zawsze weryfikuj” wymaga powiązania dostępu z centralnym repozytorium tożsamości, mechanizmami silnego uwierzytelniania i telemetrią z urządzeń końcowych. Sama obecność hosta w VLAN-ie „PRACOWNICY” przestaje cokolwiek znaczyć – liczy się to, kto jest zalogowany, w jakiej jest roli i w jakim stanie znajduje się jego endpoint.
Zasada najmniejszych uprawnień w kontekście sieci
Zasada najmniejszych uprawnień (least privilege) jest dobrze znana z zarządzania kontami w systemach operacyjnych i aplikacjach, ale w sieci też można ją wdrażać bardzo konkretnie. Chodzi o to, by każdy użytkownik, urządzenie i aplikacja miały dostęp tylko do tych zasobów, które są im rzeczywiście potrzebne i nic ponadto.
W praktyce oznacza to m.in.:
segmentację VLAN-ów według roli i typu zasobów, a nie tylko lokalizacji fizycznej,
stosowanie list kontroli dostępu (ACL) między VLAN-ami, filtrowanie po portach i protokołach,
powiązanie polityk sieciowych z grupami w systemie tożsamości (np. AD),
ograniczenie bezpośredniej komunikacji peer-to-peer między hostami użytkowników,
wydzielenie stref administracyjnych z innymi zasadami dostępu.
Przykład: zamiast jednego VLAN-u „BIURO” dla wszystkich, tworzysz logiczne strefy: „Użytkownicy biurowi”, „Goście”, „Administracja systemów”, „Urządzenia drukujące”, „Systemy finansowe”. Pomiędzy nimi definiujesz proste, czytelne reguły: kto do kogo i na jakich portach ma prawo zaglądać. Użytkownik z księgowości nie łączy się bezpośrednio z systemem produkcyjnym – robi to przez dedykowaną aplikację lub usługę.
Ciągła weryfikacja zamiast jednorazowego „logowania do sieci”
Model „raz zalogowany, zawsze zaufany” jest jednym z głównych wrogów Zero Trust. Użytkownik łączy się rano przez VPN, wpisuje hasło, być może używa MFA i… przez cały dzień jest traktowany jako zaufany, bez względu na to, co dzieje się później z jego urządzeniem czy kontem.
Ciągła weryfikacja wymaga:
regularnego sprawdzania stanu urządzenia (aktualizacje, EDR, szyfrowanie dysku, obecność złośliwego oprogramowania),
analizy zachowania (czy użytkownik nagle nie pobiera ogromnej ilości danych z nietypowego systemu),
reagowania na sygnały z systemów bezpieczeństwa (np. EDR wykrył podejrzane działanie – ogranicz dostęp sieciowy),
czasowego ograniczania sesji wysokiego ryzyka (np. do systemów finansowych wymagających ponownego MFA).
Narzędzia typu ZTNA czy nowoczesne VPN-y potrafią na bieżąco oceniać tzw. risk score połączenia. Jeśli coś się zmieni – np. użytkownik nagle loguje się z innego kraju czy z urządzenia, które nie przechodzi kontroli bezpieczeństwa – polityka dostępu automatycznie się zaostrza.
Decyzje o dostępie oparte na wielu sygnałach
W Zero Trust decyzja „przepuścić / zablokować / wymusić dodatkowe uwierzytelnienie” nie opiera się na jednym kryterium. Łączy się wiele sygnałów z różnych systemów:
Tożsamość – kto próbuje uzyskać dostęp (użytkownik, usługa, konto techniczne), do jakiej grupy i roli należy.
Stan urządzenia – czy jest zarządzane (MDM/EDR), czy ma aktualne łatki, czy jest zaszyfrowane, czy nie jest oznaczone jako skompromitowane.
Lokalizacja i sieć źródłowa – z jakiego kraju/regionu, z jakiej klasy sieci (biuro, dom, kawiarnia, sieć publiczna).
Czas – czy dostęp jest żądany w typowych godzinach pracy, czy nagle w środku nocy.
Typ aplikacji/zasobu – czy to aplikacja niskiego ryzyka (intranet) czy bardzo wrażliwa (system płatności, OT).
Kontekst historyczny – czy to typowe zachowanie dla tego użytkownika czy odstępstwo od normy.
Takie podejście wymaga integracji świata sieci (firewalle, NAC, ZTNA) ze światem tożsamości (AD, Azure AD, IdP) oraz ochrony endpointów (EDR, MDM). Sama sieć nie jest już w stanie podejmować dobrych decyzji, jeśli „widzi” tylko adres IP i port.
Silne uwierzytelnianie i inspekcja ruchu szyfrowanego
Silne uwierzytelnianie (MFA, certyfikaty, klucze sprzętowe) staje się w Zero Trust absolutnym fundamentem. Nie chodzi tylko o logowanie do VPN czy aplikacji webowych, ale także:
uwierzytelnianie do sieci LAN/Wi-Fi (802.1X z certyfikatami lub poświadczeniami z AD),
wzmacnianie dostępu administratorów do krytycznych systemów (MFA, bastiony, PAM),
podpisywanie i autoryzację kont serwisowych i usługowych (certyfikaty, managed identities).
Drugi filar to inspekcja ruchu szyfrowanego. Współczesne ataki w ogromnej części korzystają z TLS. Jeśli firewall czy proxy widzi tylko strumień zaszyfrowanego ruchu, niewiele może zdziałać. Architektura Zero Trust zakłada rozsądne podejście do TLS inspection – z jasno określonym zakresem (np. ruch HTTP/S do Internetu, ruch do SaaS), z respektowaniem prywatności (wykluczenia dla bankowości, prywatnej poczty) i z odpowiednią mocą obliczeniową.
Bez możliwości zajrzenia w ruch (przynajmniej w kluczowych punktach styku) wykrywanie anomalii, wycieku danych czy aktywności C2 (command & control) staje się loterią. Zero Trust nie oznacza ślepego szyfrowania wszystkiego i wszędzie – oznacza świadome zarządzanie tym szyfrowaniem.
Od slajdu do mapy sieci: jak przeanalizować obecną infrastrukturę
Inwentaryzacja bez paraliżowania organizacji
Mapowanie przepływów: od „kto z kim gada” do realnych reguł
Sam spis urządzeń i systemów niewiele zmienia. Kluczowe jest zrozumienie, jakie przepływy sieciowe naprawdę są potrzebne. Bez tego Zero Trust bardzo szybko zamienia się w festiwal zgłoszeń „nie działa, proszę otworzyć wszystko jak było”.
Dobrym punktem startu jest podział na kilka kategorii ruchu:
Użytkownik ⇄ Aplikacja biznesowa – np. pracownik działu kadr łączy się z systemem HR w centrum danych.
Przydaje się tu zarówno wiedza ludzi (architektów, adminów, właścicieli aplikacji), jak i dane z narzędzi. Flow logi z firewalli, NetFlow/sFlow, telemetria z EDR czy proxy – to wszystko pomaga zobaczyć, jak wygląda realny ruch, a nie jak wydaje się, że wygląda.
Praktyczny trik: najpierw zaznaczaj to, co jest oczywiste – ruch do kontrolerów domeny, baz danych, serwerów aplikacyjnych. Dopiero później szukaj „ogonów”: pojedynczych, dziwnych połączeń, które od lat działają „bo tak ktoś skonfigurował”. W tych ogonach często kryją się największe niespodzianki przy segmentacji.
Klasyfikacja zasobów: nie wszystko jest „krytyczne”
Zero Trust łatwiej wdrożyć, gdy infrastruktura nie jest jednym, szarym blokiem. Trzeba nazwać rzeczy po imieniu: które systemy są naprawdę wrażliwe, a które mogą mieć luźniejsze zasady. Bez tego polityki staną się albo zbyt restrykcyjne (i biznes zablokuje projekt), albo zbyt miękkie (i bezpieczeństwo niewiele się poprawi).
Prosty model trójpoziomowy zwykle wystarcza na początek:
Poziom wysoki – systemy finansowe, HR, dane klientów, systemy OT/produkcyjne, repozytoria kodu źródłowego.
Poziom średni – wewnętrzne aplikacje biznesowe, które nie przechowują najbardziej wrażliwych danych.
Poziom niski – intranet, systemy pomocnicze, narzędzia testowe (ale i tak niepubliczne).
Do każdej klasy można przypisać oczekiwania: wymóg MFA, typ szyfrowania, poziom monitoringu, czas retencji logów. Sieć ma potem tylko odzwierciedlić tę klasyfikację w ruchu: dostęp do strefy „wysokiej” jest mocniej broniony, dostęp między strefami jest maksymalnie ograniczony i jawnie zdefiniowany.
Identyfikacja „dzikich” stref zaufania
W niemal każdej organizacji znajdzie się choć jedna „dzika” strefa – fragment sieci, który przez lata rósł sam, bez większego nadzoru. Jeden ogromny VLAN biurowy, laboratorium testowe z dostępem do produkcji, serwerownia z „chwilowo” otwartym RDP do świata. Zero Trust nie lubi takich miejsc.
Podczas analizy infrastruktury warto zadać kilka konkretnych pytań:
Gdzie mamy VLAN-y lub podsieci, które łączą bardzo różne typy urządzeń (użytkownicy, serwery, drukarki, IoT) bez kontroli między nimi?
Które systemy produkcyjne są dostępne z sieci biurowej „bez pośrednika” (np. bez WAF, proxy aplikacyjnego, jump hosta)?
Czy istnieją stare tunelowane połączenia (VPN site-to-site, GRE, IPSec), o których mało kto pamięta, ale nadal są aktywne?
To są miejsca, gdzie w pierwszej kolejności opłaca się wprowadzić choćby podstawową segmentację i kontrolę dostępu. Zamiast planować wieloletni program transformacji, lepiej najpierw „zamknąć furtki w płocie”.
Dokumentowanie tego, co już działa (a nie tego, co powinno działać)
Opisy architektury zwykle pokazują „stan idealny”. Tymczasem Zero Trust wymaga spojrzenia na to, jak systemy naprawdę są używane. Jeżeli dokumentacja mówi, że do aplikacji X dostęp ma tylko dział Y, a logi pokazują kilkanaście innych działów – to logi wygrywają.
Dobrym nawykiem jest tworzenie prostych, zrozumiałych map logicznych:
prostokąty – aplikacje i systemy (z opisem: kto jest właścicielem biznesowym, jakie dane przechowuje),
elipsy – grupy użytkowników (działy, role),
strzałki – kierunki i typy komunikacji (HTTP, RDP, SSH, SMB itd.).
Nie chodzi o piękny diagram na ścianę, tylko o „mapę pola bitwy”, na której widać, gdzie Zero Trust może przynieść największy efekt przy akceptowalnym wysiłku.
Źródło: Pexels | Autor: Pixabay
Projektowanie architektury sieci w modelu Zero Trust
Od perymetru do stref i segmentów
Klasyczna sieć firmowa bywa projektowana wokół jednego, grubego muru – firewalla na granicy z Internetem. W Zero Trust ta koncepcja pęka: zamiast jednego perymetru powstaje wiele mniejszych stref zaufania, oddzielonych od siebie jasno zdefiniowanymi granicami.
Praktycznie wygląda to tak, że buduje się kilka głównych segmentów:
strefy specjalne – OT, laboratoria, systemy partnerskie.
Między tymi segmentami ruch jest ściśle regulowany – nie ma już domyślnego „any-any”. Każdy wyjątek musi mieć opisany cel biznesowy i właściciela. Zamiast „otwórzmy porty do tego serwera”, formułuje się regułę: „użytkownicy z grupy X, na zarządzanych laptopach, przez ZTNA, mogą używać aplikacji Y po HTTPS”.
Mikrosegmentacja: kiedy ACL-e już nie wystarczą
Segmentacja na poziomie VLAN-ów i podsieci to dobry początek, ale bywa zbyt gruboziarnista. Jeśli w jednym VLAN-ie serwerowym są dziesiątki systemów, to kompromitacja jednego z nich ułatwia atakującemu ruch boczny. Tu do gry wchodzi mikrosegmentacja.
Mikrosegmentacja polega na kontrolowaniu ruchu pomiędzy konkretnymi workloadami, a nie tylko pomiędzy całymi podsieciami. Można to osiągnąć kilkoma technikami:
rozbudowanymi ACL-ami na switchach dostępowych (dla prostych środowisk),
regułami na firewallach wewnętrznych (między podsieciami / VLAN-ami),
rozwiązaniami opartymi na agencie, instalowanym na serwerach lub w hypervisorze (policy per workload),
politykami sieciowymi w środowiskach kontenerowych (np. Kubernetes Network Policies).
Wyobraź sobie segment „Systemy finansowe”, w którym działa kilka różnych aplikacji. W modelu Zero Trust poszczególne usługi w tym segmencie nie muszą ufać sobie nawzajem tylko dlatego, że stoją w tej samej szafie. Każde połączenie jest dopuszczane wyłącznie wtedy, gdy wynika z jawnie opisanej zależności biznesowej lub technicznej.
Warstwa dostępu: sieć przewodowa, Wi-Fi i zdalni użytkownicy
Sieć dostępu to miejsce, gdzie Zero Trust musi zderzyć się z codziennością. Pracownicy, goście, kontraktorzy, urządzenia IoT – wszyscy chcą „tylko podłączyć kabel albo Wi-Fi i działać”. Zadanie architekta polega na tym, żeby pod spodem każda z tych grup wylądowała w odpowiedniej strefie z odpowiednią polityką.
Dobrą praktyką jest:
stosowanie 802.1X w sieci przewodowej i bezprzewodowej,
przypisywanie użytkowników/urządzeń do VLAN-ów dynamicznie (na podstawie grup, typu urządzenia, profilu),
oddzielenie ruchu gości od ruchu firmowego na wszystkich poziomach (VLAN, routing, firewall, DNS),
ujednolicenie zasad dla pracy zdalnej i biurowej – ten sam ZTNA/VPN, te same polityki oparte o tożsamość.
W praktyce dobrze zaprojektowana sieć dostępu sprawia, że miejsce fizyczne przestaje mieć znaczenie. Użytkownik z działu sprzedaży, czy siedzi w biurze, czy w domu, czy w hotelu, wpada w tę samą „logikę” polityk. Decyduje jego rola, stan urządzenia i to, do czego próbuje się dostać.
Integracja z chmurą: spójny model pomiędzy on‑prem a SaaS/IaaS
Coraz więcej aplikacji ląduje w chmurze – czasem jako gotowe usługi SaaS, czasem jako własne workloady w IaaS/PaaS. Zero Trust nie może kończyć się na drzwiach do centrum danych. Model tożsamości i dostępu musi być spójny w chmurze i on‑prem.
Przy projektowaniu architektury warto zadbać o kilka rzeczy:
centralny IdP (tożsamość jako źródło prawdy zarówno dla aplikacji lokalnych, jak i SaaS),
ZTNA lub podobny broker, który zapewnia dostęp do aplikacji on‑prem bez „wpuszczania” użytkownika do całej sieci,
wykorzystanie natywnych mechanizmów segmentacji w chmurze (VNet/VPC, NSG, security groups) w podobny sposób, jak segmentacja w sieci lokalnej,
spójne logowanie i monitoring – logi z chmury i z sieci lokalnej lądują w jednym systemie analizy.
Dobrym przykładem są aplikacje wewnętrzne, które udostępnia się użytkownikom zdalnym. Zamiast wystawiać je do Internetu przez klasyczny VPN, stosuje się bramę ZTNA, która publikuje konkretną aplikację (np. HTTP/HTTPS), mapuje ją do użytkownika i jego roli, a reszta sieci pozostaje niewidoczna.
Ścieżka awaryjna: co zrobić, gdy Zero Trust coś „urwie”
Projektując nową architekturę, trzeba założyć, że prędzej czy później jakaś polityka będzie zbyt ostra i odetnie ważny przepływ. Kluczem nie jest unikanie błędów za wszelką cenę, tylko przygotowanie procedury szybkiego, kontrolowanego obejścia.
Dobrze sprawdza się podejście dwustopniowe:
Krótko‑terminowe obejście – świadomie, na czas określony, luzujesz regułę (np. otwierasz dodatkowy port, dopuszczasz ruch z konkretnej podsieci), ale:
Docelowa poprawka – po analizie logów i potrzeb biznesu wprowadzasz precyzyjną regułę, która rozwiązuje problem bez powrotu do „any‑any”.
Taki mechanizm daje organizacji poczucie bezpieczeństwa operacyjnego: można odważniej zaostrzać polityki, bo istnieje sposób na „odkręcenie” problemu bez burzenia całej koncepcji.
Źródło: Pexels | Autor: cottonbro studio
Tożsamość jako nowy perymetr: użytkownicy, urządzenia, usługi
Od adresu IP do użytkownika i urządzenia
Adres IP jako główne kryterium decyzji o dostępie to relikt czasów, gdy każdy siedział przy biurku, a serwery stały w jednym miejscu. W Zero Trust punktem odniesienia stają się tożsamość użytkownika i tożsamość urządzenia. IP jest co najwyżej jednym z dodatkowych sygnałów.
Technicznie oznacza to, że firewall, ZTNA czy NAC przy każdym połączeniu „dopytuje się”: kto jest po drugiej stronie i z jakiego hosta wychodzi ruch. Dane te pochodzą najczęściej z:
Jeśli polityka brzmi: „grupa Finance-Users może łączyć się z aplikacją księgową wyłącznie z zarządzanych laptopów”, sieć musi umieć te dwie informacje powiązać. Inaczej kończy się na „otwarciu portu do IP”, co jest dokładnie tym, od czego Zero Trust próbuje odejść.
Grupy i role zamiast statycznych list adresów
Statyczne listy adresów IP w regułach firewalla szybko stają się nie do utrzymania. Zmieniają się podsieci, użytkownicy przechodzą między działami, nowe aplikacje lądują w chmurze. Dużo lepiej skalują się polityki oparte na grupach i rolach.
Typowy wzorzec to mapowanie:
grup z AD/Azure AD → grup polityk w NAC/ZTNA/firewallu,
ról aplikacyjnych → poziomów uprawnień sieciowych (np. „użytkownik”, „operator”, „administrator”),
klas urządzeń (laptop korporacyjny, BYOD, serwer, IoT) → profili dostępu.
Ocena stanu urządzenia: posture, compliant / non‑compliant
Sama tożsamość użytkownika to za mało. Jeśli Jan z finansów loguje się z domowego, nieszyfrowanego laptopa z wyłączonym antywirusem, to z perspektywy Zero Trust jest to zupełnie inny poziom ryzyka niż ten sam Jan na służbowym, aktualnym sprzęcie.
Tu pojawia się ocena stanu urządzenia (device posture). Systemy MDM/EDR i mechanizmy NAC/ZTNA potrafią przed decyzją o dostępie sprawdzić m.in.:
czy system operacyjny jest wspierany i aktualny,
czy działa agent bezpieczeństwa (EDR, AV, MDM),
czy dysk jest szyfrowany,
czy urządzenie jest zarejestrowane jako korporacyjne, czy to BYOD/gość,
czy nie występują znane wskaźniki kompromitacji.
Na tej podstawie powstają proste, ale skuteczne reguły, typu: „pełny dostęp tylko z urządzeń compliant, ograniczony – z urządzeń częściowo zgodnych, brak dostępu – z urządzeń niespełniających minimum”. Technicznie często wygląda to tak, że ZTNA lub NAC otrzymuje od MDM/EDR wynik oceny („compliant/non‑compliant”) i mapuje go na konkretny profil dostępu sieciowego.
Daje to elastyczność. Można pozwolić pracownikowi zalogować się z prywatnego tabletu do poczty WWW, ale już nie do panelu administracyjnego ERP. Nie trzeba wszystkiego sprowadzać do zero‑jedynkowego „blokuj/zezwalaj”.
Tożsamość usług i komunikacja machine‑to‑machine
Zero Trust nie kończy się na użytkownikach. Ogromna część ruchu w sieci to komunikacja pomiędzy usługami: mikroserwisy, API, integracje ETL, backupy. Jeśli traktuje się je jako „zaufane z definicji”, bo stoją w tym samym VLAN‑ie, cała koncepcja zaczyna się sypać.
Dlatego pojawia się pojęcie tożsamości workloadu. Zamiast ufać adresowi IP serwera, ufa się temu, kim ten serwer jest z perspektywy kontrolera tożsamości lub platformy aplikacyjnej. W praktyce realizuje się to przez:
certyfikaty mTLS wystawiane dla usług i mikroserwisów,
tożsamości zarządzane w chmurze (managed identities, service accounts) używane do uzyskiwania tokenów OAuth2/JWT,
etykiety i nazwy usług w service mesh (np. Istio, Linkerd) powiązane z politykami dostępu.
Jeśli aplikacja A ma rozmawiać z bazą danych B, polityka powinna mówić „ten konkretny workload może wykonać zapytania do tej konkretnej usługi na porcie 5432”, a nie „cokolwiek z podsieci 10.10.10.0/24 może wchodzić na serwer 10.10.20.5”. W efekcie nawet jeśli atakujący przejmie jedną usługę, to nie „przeskoczy” łatwo do kolejnych, bo nie posiada ich tożsamości ani kluczy.
Silne uwierzytelnianie i ciągła weryfikacja
Hasło + VPN to z perspektywy dzisiejszych ataków za mało. Phishing, reuse haseł, malware kradnący cookies – to wszystko sprawia, że wieloskładnikowe uwierzytelnianie (MFA) i ciągła weryfikacja sesji stają się elementem bazowym Zero Trust.
Praktyczny wzorzec wygląda tak:
logowanie do IdP zawsze z MFA (aplikacja mobilna, FIDO2, klucze sprzętowe),
krótkie sesje wysokiego zaufania – po zmianie kontekstu ryzyka (nowy kraj, nietypowa aplikacja, zmiana adresu IP) wymuszane ponowne potwierdzenie,
stosowanie mechanizmów „step‑up” – do działań wrażliwych (np. wypłata środków, zmiana konfiguracji systemu) dodawane jest dodatkowe uwierzytelnienie.
Od strony sieci oznacza to, że ZTNA lub brama aplikacyjna stale „dopytuje się” o aktualny status sesji: czy token jest ważny, czy nie został cofnięty, czy profil ryzyka się nie zmienił. To często bywa niewidoczne dla użytkownika, ale jeśli coś nagle wygląda podejrzanie – pojawia się dodatkowy prompt MFA lub sesja jest rozłączana.
Narzędzia sieciowe w służbie Zero Trust: NAC, ZTNA, firewalle nowej generacji
NAC jako „bramka wstępna” do sieci
Network Access Control to często pierwszy, bardzo namacalny element Zero Trust w infrastrukturze. Zamiast wpuszczać do sieci „cokolwiek, co podepnie się do gniazdka lub Wi‑Fi”, NAC wymusza autoryzację i klasyfikację urządzenia. Trochę jak recepcja w biurze – zanim ktoś wejdzie, musi się przedstawić.
Typowy proces wygląda następująco:
Urządzenie podłącza się do portu switcha lub SSID Wi‑Fi.
Przeprowadzane jest uwierzytelnianie 802.1X (użytkownik, urządzenie lub oba naraz).
NAC, na podstawie danych z IdP, MDM, EDR, przypisuje urządzenie do konkretnego profilu.
Switch lub kontroler Wi‑Fi otrzymuje informację: „ten endpoint to laptop działu HR, zgodny z polityką” i przypisuje odpowiedni VLAN/ACL.
Dobrze skonfigurowany NAC umożliwia budowę wielu „warstw zaufania” bez ręcznego dotykania konfiguracji portów. Gniazdko w sali konferencyjnej może jednego dnia służyć pracownikowi IT, a drugiego – urządzeniu zewnętrznego kontraktora. Każde z nich wyląduje w innej strefie, bo kluczem jest tożsamość, a nie fizyczna lokalizacja.
Guest access, BYOD i urządzenia „dziwne”
Każda większa sieć ma urządzenia, które nie obsługują 802.1X: drukarki, systemy CCTV, panele BMS, różne „pudełka” od dostawców. Do tego goście z własnymi laptopami i telefonami. Zero Trust nie oznacza, że trzeba ich wyrzucić – chodzi o to, by ich obecność była kontrolowana.
W praktyce stosuje się kombinację kilku technik:
MAC Authentication Bypass (MAB) – urządzenia bez 802.1X autoryzowane są po MAC, ale od razu trafiają do odizolowanych VLAN‑ów z ograniczonym ruchem (np. tylko do serwera wydruku),
portale captive – gość loguje się przez portal www, akceptuje regulamin, często otrzymuje krótkotrwałe konto powiązane z osobą zapraszającą,
profilowanie urządzeń – NAC na podstawie DHCP, LLDP, fingerprintu TCP identyfikuje typ urządzenia i przypisuje mu domyślny, bardzo wąski zakres dostępu.
Dzięki temu kamera IP nie „widzi” serwera płacowego, a telefon gościa ma Internet, ale nie ma pojęcia, że gdzieś obok istnieje sieć produkcyjna. W razie incydentu można szybko zidentyfikować, co to było za urządzenie, kto je wpuścił i gdzie jest fizycznie podłączone.
ZTNA zamiast klasycznego VPN‑a
Zero Trust Network Access działa zupełnie inaczej niż znany od lat VPN typu „full tunnel”. Zamiast „wpuszczać” użytkownika do wnętrza sieci, ZTNA wystawia mu konkretne aplikacje lub usługi. Reszta pozostaje niewidoczna – tak, jakby w ogóle nie istniała.
Od strony użytkownika wygląda to zazwyczaj tak:
loguje się do portalu lub klienta ZTNA za pomocą IdP,
widział tylko te aplikacje, do których ma uprawnienia (np. „CRM”, „Helpdesk”, „Intranet”),
po wybraniu aplikacji ruch jest tunelowany do brokera ZTNA, który w jego imieniu łączy się z serwerem on‑prem lub w chmurze.
Od strony sieci kluczowe jest to, że ruch z Internetu nie trafia bezpośrednio do segmentu serwerowego. ZTNA pośredniczy, uwierzytelnia, sprawdza stan urządzenia, wymusza szyfrowanie i loguje każdy dostęp. Nawet jeśli dane poświadczenia wyciekną, atakujący dostaje dostęp co najwyżej do jednego, wąsko wystawionego frontu aplikacji, a nie całej sieci korporacyjnej.
Co ważne, ten sam mechanizm da się stosować zarówno dla pracowników zdalnych, jak i dla dostawców zewnętrznych czy serwisantów. Nie ma osobnych zaszyfrowanych tuneli, „VPN‑ów partnerskich”, przekombinowanych statycznych tras – jest jeden model kontrolujący, kto i do jakiej aplikacji może wejść.
Firewalle nowej generacji jako „silnik polityk”
Nowoczesny firewall to już nie tylko lista reguł „IP‑port‑protokół”. To silnik polityk, który rozumie użytkowników, aplikacje i kontekst. W połączeniu z IdP, NAC i ZTNA staje się jednym z kluczowych elementów enforcementu Zero Trust.
Kilka funkcji NGFW szczególnie dobrze wpisuje się w ten model:
App‑ID / rozpoznawanie aplikacji – reguły mogą odwoływać się do aplikacji (np. „blokuj Dropbox”, „zezwól tylko na HTTPS do aplikacji X”), a nie tylko do portów,
User‑ID / integracja z tożsamością – firewall widzi, że ruch wychodzi od użytkownika „anna.nowak@firma.pl” należącej do grupy „HR”, a nie od „10.12.5.23”,
kontrola TLS – możliwość inspekcji zaszyfrowanego ruchu według jasno określonych zasad (z wyjątkami dla prywatności),
IPS/IDS – wykrywanie prób eksploatacji podatności, nawet jeśli połączenie zostało dopuszczone polityką,
segmentacja z wykorzystaniem tagów – zamiast operować tylko adresacją, reguły mogą korzystać z etykiet przypisanych do serwerów, VLAN‑ów, kontenerów.
Dobrym podejściem jest myślenie o NGFW nie jako o wielkim „murze na brzegu”, ale jako o zestawie mniejszych punktów kontroli. Jeden stoi na styku z Internetem, inne pilnują ruchu między segmentami serwerowymi, jeszcze kolejne – ruchu do stref wrażliwych (OT, systemy finansowe, dane osobowe).
Integracja NAC, ZTNA i NGFW: spójny łańcuch decyzji
Największą wartość przynosi sytuacja, gdy narzędzia nie żyją w silosach. Zero Trust zakłada, że decyzja o dostępie powinna brać pod uwagę jak najwięcej aktualnych informacji, więc NAC, ZTNA, NGFW i IdP muszą ze sobą rozmawiać.
Przykładowy scenariusz z życia:
Użytkownik loguje się do IdP z laptopa służbowego – MDM oznacza go jako „compliant”.
NAC wpuszcza go do VLAN‑u pracowniczego i oznacza sesję odpowiednim tagiem (np. „Employee‑Finance, Device‑Managed”).
Firewall otrzymuje te tagi i na ich podstawie dopuszcza ruch tylko do kilku aplikacji w segmencie serwerowym.
ZTNA wystawia temu samemu użytkownikowi dostęp zdalny dokładnie do tych samych aplikacji, bo od IdP dostaje identyczne atrybuty grup/rol.
Jeżeli w trakcie sesji EDR zgłosi incydent (np. malware na laptopie), MDM może oznaczyć urządzenie jako „non‑compliant”. NAC ogranicza dostęp w sieci lokalnej, ZTNA zrywa sesje zdalne, a firewall przestaje akceptować ruch z tak oznaczonego hosta. Nie trzeba biegać po biurze i odłączać kabla – reakcja jest automatyczna i spójna.
Stopniowanie wdrożenia narzędzi: od widoczności do egzekwowania
Najczęstszy błąd przy wdrażaniu NAC, ZTNA czy NGFW to „włączenie wszystkiego na ostro” w jeden weekend. Lepiej potraktować wdrożenie jako proces, w którym najpierw zdobywa się widoczność, a dopiero później zaciska śrubę.
Rozsądna sekwencja kroków może wyglądać tak:
Tryb monitoringu – NGFW działa w oparciu o dotychczasowe reguły, ale dodatkowo loguje informacje o aplikacjach i użytkownikach; NAC przy 802.1X pracuje w trybie „open mode”, tylko identyfikując urządzenia.
Klasyfikacja i tagowanie – na podstawie zebranych danych tworzone są grupy polityk: rodzaje urządzeń, segmenty biznesowe, typy aplikacji.
Miękkie ograniczenia – w pierwszej kolejności ogranicza się ruch najmniej krytyczny (goście, IoT, dostęp zdalny partnerów), z gęstym logowaniem i obserwacją.
Zaostrzenie polityk w strefach wrażliwych – dopiero na końcu bierze się za segmenty krytyczne dla biznesu, już z dobrym zrozumieniem typowych przepływów.
Taki sposób sprawia, że Zero Trust nie staje się projektem „przewróćmy wszystko do góry nogami i trzymajmy kciuki”, tylko kontrolowaną ewolucją. Narzędzia sieciowe przestają być samotnymi wyspami konfiguracji, a zaczynają pracować jako jeden, spójny system kontroli dostępu oparty na tożsamości i kontekście.
Najczęściej zadawane pytania (FAQ)
Co to jest Zero Trust w sieci firmowej i na czym polega?
Zero Trust to sposób projektowania bezpieczeństwa, w którym z góry zakłada się, że żadna część sieci nie jest „domyślnie zaufana” – nawet sieć wewnętrzna w biurze. Każdy użytkownik, urządzenie i aplikacja musi być na bieżąco weryfikowana, a dostęp do zasobów jest przyznawany wyłącznie wtedy, gdy jest faktycznie potrzebny.
Zamiast pytania „czy to jest z naszej sieci LAN?”, pojawia się inne: „kim jest ten użytkownik, z jakiego urządzenia się łączy, w jakim ono jest stanie i do czego próbuje się dostać?”. To przesunięcie ciężaru z adresu IP i lokalizacji na tożsamość, kontekst i spełnienie warunków bezpieczeństwa.
Dlaczego tradycyjny model „zaufanej sieci wewnętrznej” już nie działa?
Klasyczne podejście zakładało, że w środku firmy wszystko jest bezpieczne, a jedynym miejscem walki jest firewall na brzegu. Tyle że dziś użytkownicy pracują z domu, z hotspotu w telefonie, korzystają z aplikacji SaaS i chmury, a w sieci pojawiają się urządzenia IoT i systemy dostawców. Granica sieci praktycznie się rozmyła.
W takim świecie jeden skuteczny phishing i zainfekowany laptop w „zaufanym” VLAN-ie potrafią otworzyć drogę do serwerów plików, ERP czy kontrolera domeny. Atakujący świetnie wykorzystują brak segmentacji i zbyt szerokie uprawnienia – dokładnie to, co w starym modelu uchodziło za „wygodę administracyjną”.
Czy Zero Trust to konkretne urządzenie lub produkt od vendora?
Zero Trust to przede wszystkim model myślowy i zestaw zasad, a nie jedno pudełko do postawienia w serwerowni. Vendorzy chętnie sprzedają „platformy Zero Trust” czy „ZTNA gateway”, ale bez zmiany sposobu projektowania sieci i dostępu będą to tylko drogie klocki w starej układance.
Wiele elementów da się wdrożyć na tym, co już jest: przeprojektować segmentację VLAN, uporządkować listy ACL, oprzeć dostęp na tożsamości (AD/AAD), wprowadzić silne uwierzytelnianie i monitorować ruch wschód–zachód. Technologia pomaga, ale sama nie zastąpi zmiany podejścia „domyślnie ufam” na „domyślnie sprawdzam”.
Od czego zacząć wdrażanie Zero Trust w istniejącej sieci firmowej?
Najprostszy start to małe, ale konkretne kroki. Zamiast przebudowy całej sieci w pół roku, lepiej wziąć jeden obszar – np. dostęp pracowników biurowych do krytycznych serwerów – i tam zastosować zasady Zero Trust. Dobrze działa podejście: najpierw mapowanie, potem uszczelnianie.
Zrób listę kluczowych zasobów (serwer plików, ERP, CRM, system produkcyjny) i sprawdź, kto i skąd ma do nich dostęp.
Oddziel segmentacyjnie użytkowników biurowych od serwerów i ogranicz porty tylko do tych faktycznie używanych.
Powiąż dostęp z grupami i tożsamością (nie „każdy z VLAN-u biurowego”, tylko konkretne role z AD).
Po takim pilotażu łatwiej przekonać biznes, bo różnica między „był jeden zainfekowany laptop” a „padło pół firmy” staje się bardzo namacalna.
Jak Zero Trust pomaga ograniczyć lateral movement i ransomware?
Ataki ransomware i lateral movement żyją z braku barier wewnątrz sieci. Jeśli wszystkie komputery „widzą się” nawzajem, a serwery otwierają wiele portów „na wszelki wypadek”, zainfekowana stacja robocza staje się idealnym punktem startu do dalszej ekspansji.
Zero Trust wprowadza kilka hamulców: mikrosegmentację (podział sieci na mniejsze, kontrolowane strefy), ścisłe ACL-e między segmentami, dostęp oparty na tożsamości oraz monitorowanie podejrzanych przepływów. W efekcie zainfekowany laptop księgowej nie powinien mieć bezpośredniego, szerokiego dostępu do serwerów produkcyjnych – nawet jeśli nadal jest „w tej samej firmie”.
Co oznacza zasada „never trust, always verify” w praktyce sieciowej?
W praktyce oznacza to, że każdy nowy przepływ jest sprawdzany pod kątem polityki – nie tylko przy pierwszym logowaniu VPN. Sesja sieciowa jest powiązana z konkretnym użytkownikiem, urządzeniem i ich bieżącym stanem. Jeśli nagle laptop staje się niezgodny z polityką (np. wyłączony antivirus), dostęp może być ograniczony lub przerwany.
Nie wystarczy więc „wpuścić” użytkownika do sieci LAN i dać mu wolność. Firewall, proxy lub gateway ZTNA cały czas kontrolują, do jakich zasobów i po jakich portach odbywa się komunikacja, a w tle działa korelacja sygnałów z różnych systemów: tożsamość, endpoint, logi, anomalie.
Jak wdraża się zasadę najmniejszych uprawnień (least privilege) w sieci?
W sieci zasada najmniejszych uprawnień oznacza, że każdy segment, użytkownik i aplikacja mają dostęp tylko do niezbędnych zasobów – nic „na zapas”. Zamiast jednego dużego VLAN-u „BIURO” i otwartych udostępnień, pojawia się bardziej precyzyjna siatka zależności.
Tworzenie VLAN-ów według roli i typu zasobów (np. księgowość, produkcja, goście, IoT), a nie według piętra budynku.
Stosowanie ACL pomiędzy VLAN-ami z precyzyjnymi regułami „kto–do czego–po jakim porcie”, zamiast ogólnego „full access”.
Powiązanie reguł z grupami i tożsamością (AD, Azure AD), a nie tylko z adresami IP, które łatwo podszyć lub zmienić.
Efekt końcowy? Użytkownik widzi tylko te serwery i udziały, które są mu potrzebne do pracy, a malware ma znacznie mniej dróg do rozprzestrzeniania się.
Najważniejsze wnioski
Tradycyjny model „twardego perymetru” przestał działać, bo użytkownicy, urządzenia i aplikacje są dziś rozproszone między biurem, domem, chmurą i usługami SaaS – granica sieci po prostu się rozmyła.
Pojęcie „zaufanej sieci wewnętrznej” jest złudzeniem: w jednym VLAN-ie mieszają się laptopy pracowników, IoT, systemy biurowe i produkcyjne, co sprzyja łatwemu przemieszczaniu się atakującego po środku.
Sam firewall na brzegu nie chroni przed lateral movement, ransomware ani BYOD – bez segmentacji, kontroli ruchu wschód‑zachód i sensownych uprawnień atak z jednego komputera może sparaliżować krytyczne systemy.
Zero Trust nie jest produktem do kupienia, tylko sposobem myślenia: nie ufamy z założenia żadnemu ruchowi, dopóki nie sprawdzimy tożsamości, kontekstu (urządzenie, lokalizacja, stan bezpieczeństwa) i zasadności dostępu do konkretnego zasobu.
Kluczowa zmiana polega na przejściu z pytania „czy to jest z naszej sieci?” na „kto, z czego i do czego się łączy oraz czy to ma sens biznesowy?”, a także na ciągłej, a nie jednorazowej weryfikacji tego zaufania.
Podstawowe elementy Zero Trust – segmentacja logiczna, ograniczenie portów, dostęp oparty na grupach i tożsamości, monitorowanie nietypowych przepływów – mogą realnie zatrzymać atak na poziomie jednego zainfekowanego laptopa, zamiast dopuścić do kompromitacji całej firmy.
