Na czym polega model „nigdy nie ufaj, zawsze weryfikuj”
Model zero trust opiera się na prostym założeniu: brak domyślnego zaufania do użytkowników, urządzeń i aplikacji – bez względu na to, czy są „w środku” sieci firmowej, czy „na zewnątrz”. Każdy dostęp do zasobu jest traktowany jak potencjalnie ryzykowny i musi zostać zweryfikowany na wielu poziomach.
W praktyce oznacza to odchodzenie od myślenia: „jak ktoś jest w VPN-ie lub biurze, to jest zaufany”. Zamiast tego:
użytkownik jest weryfikowany za każdym razem, gdy chce uzyskać dostęp do konkretnej aplikacji,
urządzenie jest oceniane pod kątem stanu bezpieczeństwa (aktualne łatki, szyfrowanie dysku, antywirus),
dostęp jest ograniczony tylko do niezbędnego minimum – jednej aplikacji, jednego portu, jednego API.
Zero trust nie zakłada, że sieć lokalna jest „dobra”, a Internet „zły”. Zakłada, że atakujący może już być w środku – na laptopie pracownika, w przejętym koncie VPN albo w webowej aplikacji. Zabezpieczenia muszą więc utrudniać poruszanie się wewnątrz sieci tak samo mocno, jak wejście do niej.
Tradycyjny perymetr kontra zero trust
W tradycyjnym modelu bezpieczeństwa sieć firmy przypomina zamek z fosą: wysoka zapora na granicy (firewall, VPN), a w środku dość swobodne poruszanie się. Logowanie do VPN-u lub podłączenie do Wi-Fi w biurze jest traktowane jako główna bariera – dalej już „ufamy”.
W podejściu zero trust fosa przestaje być jedyną linią obrony. Zamiast jednej grubej ściany na brzegu powstaje wiele mniejszych murków między poszczególnymi aplikacjami, sieciami i danymi. Każda usługa:
ma własne reguły dostępu oparte na tożsamości użytkownika i urządzenia,
nie ufa innym segmentom sieci domyślnie,
jest chroniona przez dodatkowe warstwy (proxy, MFA, logowanie i korelacja zdarzeń).
Mit, który ciągle się przewija: „mamy dobry firewall, więc jesteśmy bezpieczni”. Rzeczywistość jest inna: jedno przejęte konto VPN lub jedna podatna aplikacja www za firewallem często wystarczy, by poruszać się po całej sieci. Zero trust mocno ogranicza zasięg takiego włamania.
Dlaczego narzędzia open source dobrze pasują do zero trust
Zero trust to nie jest pojedynczy produkt, który można „kupić i zainstalować”. To zestaw zasad, wzorców i komponentów: uwierzytelnianie, proxy, segmentacja, monitoring, automatyzacja. Tu właśnie widać siłę open source w bezpieczeństwie sieci.
Kluczowe korzyści z używania narzędzi open source w tym modelu:
Przejrzystość kodu – można sprawdzić, co dokładnie robi narzędzie, czy są w nim „tylne drzwi” i jak obsługuje dane.
Szeroka społeczność – błędy są wykrywane i łatane przez tysiące użytkowników, a nie tylko przez zamknięty zespół producenta.
Elastyczność – możliwość dostosowania konfiguracji i integracji „pod siebie”, zamiast sztywnego pudełkowego rozwiązania.
Brak lub niższe koszty licencji – szczególnie istotne w małych i średnich firmach, gdzie budżet jest ograniczony.
Brak vendor lock-in – łatwiej wymienić jeden komponent na inny, bo standardy (OAuth2, OIDC, SAML, mTLS) są powszechne.
Częsty mit brzmi: „open source jest mniej bezpieczne, bo każdy widzi kod”. W praktyce otwarty kod oznacza, że błędy mogą zobaczyć zarówno atakujący, jak i specjaliści bezpieczeństwa. Komercyjne, zamknięte rozwiązania też mają podatności – tylko zamiast społeczności polegają na jednym zespole producenta. Różnica polega na dojrzałości projektu, sposobie zarządzania łatkami i praktyce jego konfiguracji, a nie na samym fakcie bycia open source.
Kiedy open source wystarczy, a kiedy łączyć je z komercją
Dobrze dobrany zestaw narzędzi open source pozwala zbudować pełny łańcuch zero trust: od tożsamości i MFA, przez proxy i segmentację sieci, aż po monitoring zdarzeń. W wielu środowiskach MŚP to w zupełności wystarcza, o ile:
zespół ma podstawowe umiejętności adminsko–devopsowe,
konfiguracja jest traktowana poważnie (testy, kopie zapasowe, automatyzacja),
są procedury reagowania na incydenty i regularne przeglądy uprawnień.
Są jednak obszary, gdzie sensowne jest połączenie open source z komercją:
Zaawansowana korelacja zdarzeń i UEBA (User and Entity Behavior Analytics) – tu często wchodzi komercyjny SIEM lub platforma analityczna.
Wsparcie 24/7 i SLA – krytyczne systemy czasem wymagają komercyjnego wsparcia producenta.
Specyficzne regulacje branżowe – np. rozwiązania certyfikowane przez konkretne instytucje nadzorcze.
W wielu firmach zdrowy kompromis wygląda tak: rdzeń technologii zero trust (IdP, MFA, proxy, segmentacja) jest budowany na open source, a warstwa „nad” – SIEM, raportowanie, integracje z systemami compliance – może być komercyjna. Decyzję warto opierać na realnym ryzyku i kosztach utrzymania, a nie na marketingu producentów.
Podstawowe założenia zero trust bez marketingowego żargonu
Trzy filary: tożsamość, urządzenie, kontekst
Zero trust korzysta z trzech głównych źródeł informacji, zanim przyzna dostęp do zasobu:
Tożsamość – kto się łączy? Konkretny użytkownik z przypisanymi rolami, a nie tylko adres IP lub konto serwisowe.
Urządzenie – z czego się łączy? Służbowy laptop, prywatny telefon, serwer w data center, kontener w chmurze.
Kontekst – w jakich warunkach? Lokalizacja, czas, sposób połączenia (VPN, WWW, tunel), poziom ryzyka.
Dostęp jest przyznawany dopiero wtedy, gdy wszystkie trzy elementy są zgodne z polityką:
znana i poprawnie uwierzytelniona tożsamość (SSO + MFA),
kontekst zgodny z oczekiwaniami (np. godziny pracy, kraj, typ sieci).
Mit: „zero trust = uwierzytelnianie wieloskładnikowe i tyle”. W rzeczywistości MFA jest jednym z elementów filaru „tożsamość”. Bez danych o urządzeniu i kontekście łatwo dochodzi do sytuacji, w której przejęte konto z poprawnie wpisanym kodem TOTP wciąż daje atakującemu pełny dostęp do sieci.
Minimalne uprawnienia i mikrosegmentacja w praktyce
Zasada least privilege mówi, że użytkownik (lub aplikacja) powinien mieć tylko takie uprawnienia, jakie są potrzebne do wykonania konkretnej pracy – nic więcej. Dla małej lub średniej firmy przekłada się to na:
role oparte na funkcjach (np. „sprzedaż”, „księgowość”, „dev”, „admin systemowy”),
dostęp użytkownika do konkretnych aplikacji (CRM, system finansowy, Git) zamiast ogólnego „dostępu do sieci wewnętrznej”,
ograniczenie ruchu sieciowego między segmentami (user → aplikacja, a nie user → cały VLAN serwerowy).
Mikrosegmentacja oznacza podział sieci na mniejsze, logicznie odseparowane części, pomiędzy którymi ruch jest kontrolowany:
oddzielenie stacji roboczych pracowników od serwerów,
oddzielenie środowisk dev, test i produkcji,
wydzielenie strefy dla IoT i innych urządzeń o podwyższonym ryzyku.
Wbrew obiegowej opinii mikrosegmentacja nie musi oznaczać setek VLAN-ów i skomplikowanej konfiguracji SDN. W wielu firmach wystarczą 3–4 dobrze przemyślane segmenty połączone z prostym firewallem i regułami „deny by default”.
Silne uwierzytelnianie i ciągła walidacja
W modelu perymetrowym użytkownik raz loguje się do VPN-u lub do domeny, a potem porusza się swobodnie po sieci. Zero trust odrzuca takie myślenie: logowanie nie jest wydarzeniem jednorazowym, tylko ciągłym procesem oceny.
W praktyce oznacza to:
MFA (np. TOTP, WebAuthn/U2F) dla wszystkich krytycznych aplikacji oraz kont z podwyższonymi uprawnieniami.
Sesje o ograniczonym czasie ważności i wymuszane ponowne uwierzytelnienie przy wrażliwych operacjach (np. zmiana danych finansowych, dostęp do panelu admina).
Dodatkowe kontrole przy zmianie kontekstu – np. logowanie z innego kraju, nowego urządzenia lub adresu IP.
Warstwa techniczna to m.in. protokoły OAuth2, OIDC i SAML, które pozwalają centralnemu dostawcy tożsamości (IdP) wystawiać tokeny dostępu z określonym czasem życia i zakresem uprawnień. Jeśli IdP wykryje podejrzaną aktywność (np. zbyt wiele nieudanych logowań, dziwną lokalizację), może zaostrzyć wymagania – wymusić ponowne MFA lub zablokować sesję.
Zero trust jako zestaw zasad, a nie jeden produkt
Częsta iluzja rynkowa: „kupimy rozwiązanie X, które wdroży zero trust”. W praktyce zero trust to:
zbiór zasad i polityk (least privilege, deny by default, ciągła walidacja, oparcie na tożsamości),
architektura oparta na segmentacji, proxy i centralnym zarządzaniu tożsamością,
zachowania organizacyjne – przeglądy uprawnień, zarządzanie ryzykiem, szkolenia użytkowników.
Produkty – zarówno open source, jak i komercyjne – są tylko narzędziami do realizacji tych zasad. Ten mit jest jednym z głównych powodów rozczarowań: firmy instalują nową „platformę bezpieczeństwa”, ale nie zmieniają sposobu przydzielania uprawnień, pracy z danymi ani procesów operacyjnych. Efekt: dużo marketingu, mało realnego zero trust.
Prosty scenariusz: pracownik łączy się z aplikacją spoza biura
Dobry, przyziemny przykład: handlowiec chce uzyskać dostęp do CRM z laptopa w domu lub z hotelu. W podejściu zero trust przepływ wygląda następująco:
Użytkownik otwiera przeglądarkę i wchodzi na adres CRM.
Żądanie trafia do reverse proxy, które wymusza logowanie przez centralny IdP (np. Keycloak).
Użytkownik podaje login/hasło, a następnie potwierdza dostęp kodem TOTP z aplikacji lub kluczem U2F.
IdP sprawdza:
tożsamość (poprawne dane logowania + MFA),
czy urządzenie jest zaufane (np. certyfikat klienta, zapisany fingerprint),
czy kontekst jest OK (np. dozwolony kraj, godziny, brak podejrzanej historii logowań).
Jeśli wszystko jest poprawne, IdP wystawia token dostępu z zakresem „CRM / rola: sprzedaż”.
Reverse proxy przepuszcza ruch tylko do konkretnej aplikacji CRM, bez ogólnego dostępu do sieci wewnętrznej.
W tym scenariuszu cała reszta sieci – serwery plików, bazy danych, inne aplikacje – pozostaje niewidoczna. Nawet jeśli laptop zostanie skompromitowany, atakujący musi dodatkowo złamać MFA, a potem i tak widzi tylko to, co pozwalają uprawnienia roli „sprzedaż”.
Źródło: Pexels | Autor: Pixabay
Od inwentaryzacji do polityk: jak zacząć bez paraliżu analitycznego
Szybka inwentaryzacja: ludzie, aplikacje, urządzenia, dane
Pierwszy krok do zero trust jest bardzo przyziemny: spisanie tego, co faktycznie istnieje. Bez tej wiedzy polityki bezpieczeństwa będą teoretyczne. Celem nie jest idealny CMDB, tylko mapa „wystarczająco dobra”, która pozwoli ustalić priorytety.
Zakres minimalny:
Ludzie – działy, role, typowe obowiązki (np. support, dev, administracja systemowa, zarząd).
Aplikacje – kluczowe systemy biznesowe: CRM, ERP, system finansowo–księgowy, intranet, repozytorium kodu, system helpdesk.
Urządzenia – stacje robocze, laptopy, serwery, routery, switche, urządzenia IoT, środowiska chmurowe.
Dane – zbiory danych wrażliwych: dane klientów, dane finansowe, kody źródłowe, dokumentacja, tajemnice handlowe.
Praktyczny sposób działania:
spis z głowy + krótkie wywiady z liderami działów,
Od ogólnej mapy do priorytetów: co chronić najpierw
Po wstępnej inwentaryzacji pojawia się klasyczny problem: „mamy listę wszystkiego, ale co teraz?”. Zero trust nie wymaga, aby od razu objąć ochroną całą organizację. Sensowniejsze jest wybranie kilku kluczowych obszarów i zbudowanie wokół nich pierwszych polityk.
Dobrze sprawdza się prosty filtr:
Krytyczność biznesowa – bez czego firma realnie nie może pracować (np. system fakturowania, CRM, repozytorium kodu).
Wrażliwość danych – gdzie znajdują się dane osobowe, finansowe, tajemnice handlowe.
Ekspozycja – co jest dostępne z internetu lub z wielu lokalizacji (aplikacje webowe, zdalny dostęp).
Krzyżując te trzy kryteria, można stworzyć krótką listę 3–5 systemów „na start”. Dla każdego z nich definiuje się:
kto faktycznie musi mieć dostęp (konkretne role, nie nazwiska),
z jakich urządzeń (tylko służbowych, również prywatnych, z jakim poziomem kontroli),
w jakim kontekście (np. tylko z UE, tylko w godzinach pracy, tylko po VPN lub przez konkretne proxy).
Mit: „żeby budować zero trust, trzeba najpierw skończyć perfekcyjną inwentaryzację”. W praktyce kompletna i wiecznie aktualna lista zasobów to utopia. Lepiej ruszyć z politykami dla najważniejszych systemów i sukcesywnie rozwijać mapę w tle.
Definiowanie prostych polityk: język biznesu, nie firewallowe regułki
Polityki zero trust nie muszą zaczynać się od narzędzi. Na początek wystarczy zwykły dokument (nawet arkusz kalkulacyjny), w którym opisane są zasady typu:
„Dział sprzedaży ma dostęp do CRM i systemu ofertowego przez SSO + MFA z laptopów służbowych.”
„Administratorzy mają dostęp do paneli zarządzania wyłącznie przez bastion/Jump host, z uwierzytelnianiem kluczem sprzętowym.”
„Dostęp zdalny do systemu finansowego jest możliwy wyłącznie z sieci biurowej lub przez tunel VPN zarządzany centralnie.”
Takie reguły są zrozumiałe dla ludzi spoza IT, co ułatwia uzgadnianie wyjątków i odpowiedzialności. Dopiero na ich podstawie przekłada się wymagania na:
polityki w reverse proxy lub VPN (kto może się połączyć i dokąd),
reguły firewalli między segmentami.
W praktyce dużo problemów wynika z odwrotnego podejścia: ktoś konfiguruje skomplikowaną politykę w narzędziu, której nikt poza nim nie rozumie, a potem nikt nie chce jej ruszać z obawy przed awarią.
Minimalny cykl życia uprawnień: nadawanie, przegląd, cofanie
Zero trust bez regularnego sprzątania uprawnień szybko zamienia się w „zero trust na papierze”. Wystarczy prosty cykl:
Nadanie – każde nowe uprawnienie przypisuje się do konkretnej roli, a nie osoby. Osoby dostają role.
Przegląd – co 3–6 miesięcy właściciele systemów otrzymują listę użytkowników i akceptują lub cofają dostęp.
Cofnięcie – przy odejściu pracownika lub zmianie roli dostęp jest wyłączany z jednego centralnego miejsca (IdP / katalog).
Technicznie da się to wspierać narzędziami open source (np. skryptami korzystającymi z API Keycloak, LDAP, GitLab), ale sednem jest dyscyplina procesowa. Narzędzie nie zdecyduje, czy handlowiec, który pół roku niczego nie sprzedał, nadal powinien widzieć wszystkie leady.
Tożsamość i uwierzytelnianie: fundament zero trust z narzędziami open source
Centralny dostawca tożsamości (IdP) jako punkt startu
Bez centralnej tożsamości zero trust szybko się rozjeżdża. Konta lokalne w każdej aplikacji, osobne hasła, osobne role – to przepis na chaos. Sensowniejsze jest podejście, w którym:
użytkownik ma jedno konto w katalogu (np. LDAP, FreeIPA, AD),
IdP (np. Keycloak, Authentik, WSO2) korzysta z tego katalogu jako źródła prawdy,
aplikacje ufają IdP w zakresie uwierzytelnienia i ról (OIDC/SAML).
Przykładowy stack open source:
Keycloak – do SSO, MFA, zarządzania rolami i tokenami OIDC/SAML.
FreeIPA lub OpenLDAP – katalog użytkowników i grup.
Authelia lub Authentik – lżejsze rozwiązania IdP, często łatwiejsze do wpięcia w Nginx/Traefik.
Mit: „SSO jest tylko dla dużych korporacji”. W małych i średnich firmach centralne SSO wręcz szybciej zwraca się w czasie – mniej resetów haseł, mniej kombinowania z uprawnieniami w każdej aplikacji osobno.
Projektowanie ról i grup pod zero trust
Dobrze zaprojektowane role to połowa sukcesu. W modelu zero trust lepiej unikać grup typu „wszyscy” dla dostępu do czegokolwiek krytycznego. Zamiast tego:
tworzy się role biznesowe (np. sprzedaz_user, finanse_user, dev_readonly),
tworzy się role techniczne (np. admin_k8s, admin_db, infra_readonly),
łączenie ról technicznych i biznesowych następuje na poziomie IdP, a nie w każdej aplikacji oddzielnie.
Przykładowa praktyka:
w katalogu (FreeIPA/LDAP) są grupy odzwierciedlające działy i podstawowe poziomy dostępu,
Keycloak mapuje te grupy na role w konkretnych klientach (aplikacjach),
aplikacja otrzymuje w tokenie OIDC listę ról i na tej podstawie ustala, co użytkownik widzi.
Dobrym nawykiem jest wprowadzenie rozróżnienia na konta zwykłe i administracyjne (np. jan.nowak do codziennej pracy, jan.nowak.admin do czynności wymagających uprzywilejowania) oraz wymuszenie silniejszego MFA na tych drugich.
MFA po ludzku: TOTP, WebAuthn, klucze sprzętowe
MFA często jest wdrażane w sposób, który sam prosi się o obchodzenie: SMS-y, aplikacje bez backupu, wymuszanie MFA do absolutnie wszystkiego bez wyjątku. Przy narzędziach open source da się to zrobić rozsądniej.
Sensowne opcje:
TOTP (Google Authenticator, FreeOTP, Aegis) – łatwe do wdrożenia, obsługiwane przez Keycloak, Authelia i inne IdP.
WebAuthn/U2F – wsparcie dla kluczy sprzętowych (np. YubiKey) lub zabezpieczeń systemowych (Windows Hello, Touch ID).
Certyfikaty klienta – szczególnie dla serwerów i urządzeń nienależących do użytkowników końcowych.
Dobry kompromis:
MFA wymagane zawsze dla administracji i dostępu do systemów z danymi wrażliwymi.
MFA adaptacyjne dla reszty – np. przy logowaniu z nowego urządzenia, innego kraju, poza standardowymi godzinami.
Mit: „użytkownicy znienawidzą MFA”. Zwykle opór wynika z chaotycznej komunikacji i złego doboru narzędzi (np. wymuszanie jednej konkretnej aplikacji na prywatnych telefonach). Jeśli użytkownik ma wybór (TOTP na telefonie służbowym, klucz U2F, aplikacja desktopowa), akceptacja rośnie.
Integracja z aplikacjami: OIDC i SAML w praktyce
Kiedy IdP działa, kolejnym krokiem jest wpinanie do niego aplikacji. Kolejność bywa kluczowa:
Na początek systemy wewnętrzne, gdzie zmiana logowania jest najmniej kontrowersyjna (np. Git, Jira, Wiki).
Później systemy krytyczne biznesowo (CRM, ERP), po przetestowaniu procesów awaryjnych.
Na końcu aplikacje udostępniane partnerom lub klientom, gdzie każdy błąd boli najbardziej.
Technicznie wygląda to najczęściej tak:
Aplikacja jest konfigurowana jako „client” w IdP (OIDC) lub „service provider” (SAML).
W IdP definiowane są mapowania grup/atrybutów na role w aplikacji.
Aplikacja przy logowaniu przekierowuje użytkownika do IdP i później akceptuje token zawierający informacje o użytkowniku.
Jeśli aplikacja nie wspiera żadnego standardu federacyjnego, nadal można ją „otulić” reverse proxy (np. Nginx z oauth2-proxy, Traefik z middleware OIDC) i uwierzytelniać ruch przed wejściem do aplikacji.
Kontrola dostępu na poziomie sesji i tokenów
Centralny IdP to nie tylko logowanie, ale też sposób zarządzania czasem trwania dostępu. Tokeny OIDC i SAML mogą mieć krótki czas życia, a odświeżenie dostępu może wymagać ponownej weryfikacji:
krótki access token (np. 5–15 minut) do działania aplikacji,
dłużej żyjący refresh token, który przy zmianie kontekstu może zostać unieważniony.
Dzięki temu:
blokada konta w IdP przestaje działające sesje po krótkim czasie unieważniać,
zmiana uprawnień użytkownika zaczyna obowiązywać relatywnie szybko, a nie po tygodniu działania sesji „bez końca”.
Źródło: Pexels | Autor: Pixabay
Segmentacja sieci i kontrola dostępu: praktyczne podejście krok po kroku
Minimalny podział sieci: prosty model na start
Rozbudowane SDN i polityki „microsegmentation everywhere” brzmią imponująco, ale dla większości firm to zbyt duży skok. Prościej zacząć od kilku podstawowych stref:
USER – stacje robocze użytkowników (biuro, laptopy, Wi-Fi pracownicze).
SERVER – serwery aplikacyjne, bazy danych, usługi wewnętrzne.
MGMT – strefa zarządzania: panele admina, bastiony, systemy monitoringu.
DMZ – serwery wystawione do internetu (reverse proxy, publiczne API).
IoT/GUEST – urządzenia o niższym zaufaniu: kamery, drukarki, Wi-Fi dla gości.
Między tymi strefami stoi firewall (sprzętowy lub wirtualny), który domyślnie blokuje ruch, a przepuszcza tylko konkretne, opisane przypadki (np. USER → HTTPS → reverse proxy w DMZ, DMZ → HTTPS → serwer aplikacji w SERVER).
Open source jako silnik segmentacji
W wielu małych i średnich środowiskach wystarczą klasyczne narzędzia:
iptables/nftables na routerach Linuxowych lub w bramach wirtualnych,
pfSense lub OPNsense jako firewall z GUI i możliwością tworzenia segmentów/VLAN,
WireGuard lub OpenVPN jako kanał bezpiecznego dostępu między segmentami a zdalnymi lokalizacjami.
Segmentacja może być realizowana zarówno fizycznie (oddzielne switche/porty), jak i logicznie (VLAN-y na jednym fizycznym sprzęcie). Klucz nie leży w liczbie VLAN-ów, ale w spójnym modelu „kto może się łączyć z kim i po co”.
Od mapy przepływów do reguł firewall: prosta procedura
Zamiast pisać reguły „z głowy”, lepiej podejść do tego jak do projektu:
Dla każdej krytycznej aplikacji spisać, jakie połączenia są naprawdę potrzebne (np. CRM → DB, CRM → LDAP/IdP, użytkownicy → CRM przez proxy).
Na tej podstawie zdefiniować minimalny zestaw reguł między strefami (np. DMZ:proxy → SERVER:crm po porcie 443).
Wprowadzić domyślną blokadę całej reszty ruchu między strefami.
Mit: „jak włączymy deny by default, to wszyscy przestaną pracować”. W praktyce, jeśli model segmentacji powstaje na bazie realnych przepływów i jest wdrażany etapami (najpierw logowanie i monitorowanie, potem blokowanie), przerwy w działaniu da się ograniczyć do minimum.
Host-based firewall i agenci: dodatkowa warstwa ochrony
Segmentacja sieciowa nie wystarczy, gdy atakujący znajdzie się wewnątrz jednego segmentu. Dlatego warto wykorzystywać także firewalle na samych hostach:
ufw/firewalld na serwerach Linux – ograniczenie połączeń przychodzących do absolutnego minimum.
Windows Defender Firewall w stacjach roboczych – z politykami centralnie zarządzanymi (np. przez Ansible, Salt, Puppet).
Network policy w świecie Kubernetes i kontenerów
Środowiska kontenerowe często są „dziurą” w modelu zero trust – wszystko z wszystkim może się łączyć, bo „przecież to tylko wewnętrzny klaster”. To klasyczny błąd: atak z jednej wadliwej aplikacji może przejść do całej reszty usług w klastrze.
W praktyce w kubernetesowych środowiskach można całkiem skutecznie zaostrzyć zasady, korzystając z open source:
Calico, Cilium – sieć i polityki bezpieczeństwa na poziomie podów (Kubernetes NetworkPolicy + rozszerzenia).
Kubernetes NetworkPolicy – wbudowany mechanizm ograniczania ruchu między przestrzeniami nazw i usługami.
Minimalny zestaw kroków:
Włączyć plugin sieciowy wspierający egzekwowanie NetworkPolicy (np. Calico).
Utworzyć domyślną politykę deny all w każdym namespace, który przechowuje dane istotne dla biznesu.
Stopniowo dopisywać reguły typu „allow” dla konkretnych usług (np. frontend → backend → baza).
Mit: „NetworkPolicy jest zbyt skomplikowane, lepiej tego nie dotykać”. Trudne robi się dopiero wtedy, gdy próbuje się odwzorować pełną sieć za jednym zamachem. Jeżeli polityki powstają przy każdej nowej aplikacji lub przy większych zmianach, da się to utrzymać w ryzach.
Segmentacja użytkowników zdalnych: od „VPN dla wszystkich” do precyzyjnego dostępu
Klasyczny model: jeden duży VPN, po zalogowaniu każdy pracownik widzi prawie całą sieć. Zero trust podchodzi do tego inaczej – najpierw tożsamość i kontekst, potem dostęp do pojedynczych usług.
Osiągnięcie tego z użyciem open source nie wymaga od razu pełnego ZTNA z katalogu Gartnera. Wystarczą:
WireGuard z centralnym serwerem,
OpenVPN z integracją z IdP (np. Keycloak przez RADIUS/OAuth2),
lub narzędzia typu Headscale (open source’owy serwer kompatybilny z Tailscale).
Model docelowy wygląda następująco:
Użytkownik łączy się klientem VPN, ale po zestawieniu tunelu nie widzi pełnej sieci, tylko konkretne adresy/podsieci.
Mapowanie „kto do czego” wynika z ról w IdP (np. grupa dev → dostęp do mgmt-vpn i hostów w strefie DEV).
Dodatkowo zasady różni się dla pracowników, kontraktorów i vendorów.
W praktyce:
OpenVPN może korzystać z pluginów auth-ldap albo integracji z Keycloak (OIDC/SAML) oraz atrybutów RADIUS do wymuszania konkretnych tras (tzw. push routes).
WireGuard sam w sobie nie ma RADIUS-a, ale można użyć narzędzi zarządzających, takich jak firezone czy wg-access-server, połączonych z IdP.
Rzeczywistość jest zwykle taka, że „VPN dla wszystkich” zostaje z przyzwyczajenia, a nie z potrzeby. Najczęściej wystarczy zdefiniować 2–3 profile (np. wsparcie, developerzy, administracja) i już znika większość zbędnej ekspozycji sieci.
Secure access i proxy: jak dobudowywać zero trust do istniejącej infrastruktury
Główna przewaga podejścia proxy polega na tym, że nie trzeba od razu przerabiać wszystkich aplikacji. Dostęp jest kontrolowany przed aplikacją, a sama aplikacja rzadko wymaga modyfikacji.
Najczęściej wykorzystywane klocki open source:
oauth2-proxy – pośrednik między IdP a aplikacją HTTP(S),
Nginx z modułami auth_request lub lua,
Traefik z middleware OIDC,
Envoy lub Istio jako część service mesh, głównie w Kubernetes.
Typowy scenariusz:
Użytkownik otwiera adres aplikacji (np. https://crm.example.com).
Reverse proxy sprawdza, czy jest ważna sesja (cookie z oauth2-proxy / token w nagłówku).
Jeżeli nie – przekierowuje do IdP (Keycloak/Authelia), gdzie następuje logowanie i MFA.
Po udanym logowaniu proxy dostaje token, mapuje role i dopuszcza ruch dalej.
Dostęp może być dodatkowo ograniczony:
na podstawie ról (np. tylko finanse_user),
adresów IP lub kraju pochodzenia,
atrybutów urządzenia (przeglądarka, system, sygnatura klienta).
Mit: „żeby mieć zero trust, trzeba migrować do chmury i service mesh”. W wielu środowiskach wystarczy dobrze ustawiony Nginx/Traefik z oauth2-proxy, spięty z IdP i sensownie zaprojektowane reguły dostępu.
Proxy SSH i RDP: kontrolowany dostęp do serwerów i pulpitów
Użytkownicy często mają bezpośredni dostęp SSH/RDP do serwerów, byle tylko „było wygodnie”. Zero trust zakłada, że każde takie połączenie przechodzi przez warstwę, która weryfikuje tożsamość, rejestruje aktywność i ogranicza prawa.
Do realizacji tego modelu można wykorzystać:
Teleport (community edition) – bastion SSH/RDP/Kubernetes z SSO, nagrywaniem sesji i RBAC.
OpenSSH + bastion – jeden lub kilka serwerów pośredniczących, z wymuszonym ProxyJump i kluczami indywidualnymi.
Guacamole – bramka RDP/VNC/SSH przez WWW, spięta z IdP.
Przykładowy proces:
Pracownik loguje się do Teleporta z użyciem SSO (Keycloak, GitHub, LDAP) i MFA.
Teleport przydziela mu dostęp tylko do hostów i klastrów przypisanych do ról użytkownika.
Każda sesja jest logowana, a komendy mogą być audytowane.
W prostszej wersji:
Wszystkie serwery produkcyjne akceptują połączenia SSH tylko z podsieci bastionu.
Użytkownicy nie mogą logować się hasłem, wyłącznie kluczem lub certyfikatem SSH.
Bastion wymaga wcześniejszego uwierzytelnienia (VPN + IdP, proxy SSH).
Rzeczywistość pokazuje, że nawet jeden poprawnie skonfigurowany bastion z logowaniem zdarzeń jest dużym krokiem naprzód w stosunku do modelu „każdy ma klucz na każdy serwer”.
Integracja secure access z IdP i rolami
Pełny sens secure access widać dopiero wtedy, gdy spina się go z IdP i wspólnymi rolami. Duplikowanie grup i uprawnień w każdym narzędziu kończy się bałaganem i niespójnym modelem dostępu.
Spójny wariant:
Keycloak/FreeIPA przechowuje centralne grupy i role (biznesowe i techniczne).
Teleport, Guacamole, VPN i proxy HTTP używają tych samych grup do decydowania, kto co może robić.
Zmiana zespołu użytkownika w jednym miejscu (katalog) automatycznie zmienia jego dostęp do serwerów, aplikacji i VPN.
Przykład z praktyki: zespół supportu ma dostęp do serwerów staging, do panelu CRM i do kilka mniej wrażliwych usług. Po zmianie działu na „dział finansów” te uprawnienia muszą zniknąć, a pojawić się dostęp do ERP i systemu fakturowania. Jeżeli jest to rozproszone po wielu plikach sudoers, sshd_config, grupach VPN i własnych bazach aplikacji, utrzymanie staje się nierealne.
Warstwa aplikacyjna: enforcement w samej aplikacji
Proxy i firewalle zatrzymują część problemów, ale zero trust w pełni „zaskakuje” dopiero wtedy, gdy sama aplikacja rozumie kontekst użytkownika. Dotyczy to szczególnie sytuacji, gdy:
reguły zależą od atrybutów spoza standardowych ról (np. kraj zatrudnienia, typ urządzenia),
decyzje podejmowane są w trakcie sesji (np. dostęp do wrażliwych operacji wymaga potwierdzenia MFA).
Po stronie open source można podejść do tego na kilka sposobów:
W aplikacjach webowych używać bibliotek OIDC/SAML, które potrafią parsować tokeny i atrybuty (w Pythonie, Go, Javie itd.).
Przyjąć prosty model: „aplikacja ufa tylko nagłówkom ustawionym przez zaufane proxy” (np. X-User-Id, X-User-Roles), a proxy zdejmuje token z użytkownika i waliduje go.
W przypadku starszych aplikacji – dodać cienką warstwę „adaptera”, która mapuje atrybuty z IdP na wewnętrzny model użytkowników.
Mit: „żeby robić zero trust w aplikacjach, trzeba mieć gotową platformę policy engine”. W małych i średnich organizacjach często wystarczy, że aplikacja rozumie pojęcie ról i kilku prostych atrybutów (np. dział, poziom zaufania urządzenia), a cała reszta jest egzekwowana przez proxy.
Dynamiczne decyzje: Open Policy Agent i friends
W bardziej złożonych środowiskach sens ma wyciągnięcie logiki dostępu do osobnej usługi. Umożliwia to m.in. Open Policy Agent (OPA) lub jego warianty (np. Gatekeeper w Kubernetes).
Model działania:
Aplikacja lub proxy wysyła zapytanie do OPA, opisując kontekst: użytkownika, zasób, akcję, atrybuty urządzenia.
OPA, bazując na politykach w języku Rego, zwraca „allow” lub „deny” plus ewentualne dodatkowe dane.
Polityki są przechowywane w repozytoriach Git i można je testować automatycznie (CI/CD).
Przykładowe reguły:
„Użytkownicy z grupy finanse_admin mogą zatwierdzać płatności tylko z sieci firmowej lub przez VPN z MFA”.
„Dostęp do endpointu API z danymi osobowymi wymaga, aby urządzenie miało określony poziom compliance (np. z MDM)”.
Włączenie OPA nie musi oznaczać totalnej rewolucji. Może obsługiwać jeden krytyczny system, gdzie potrzeba bardziej elastycznych reguł niż „rola = dostęp”.
Monitorowanie i sygnały ryzyka jako element decyzji dostępowych
Zero trust nie kończy się na „czy token jest ważny”. Trzeba jeszcze odpowiedzieć na pytanie: „czy kontekst sesji nadal ma sens?”. Do wykorzystania nadają się:
logi z IdP (nietypowe lokalizacje logowań, wiele nieudanych prób),
dane z systemów EDR/antywirusów (kompromitacja stacji roboczej),
wycofywać aktywne sesje po oznaczeniu konta jako „podejrzane” przez system monitoringu,
wymuszać ponowne MFA przy wykryciu istotnej zmiany IP/geolokalizacji,
przekierowywać użytkownika do trybu „tylko odczyt”, gdy urządzenie nie spełnia wymagań bezpieczeństwa.
Open source w tej warstwie to m.in.:
Wazuh/OSSEC – HIDS z korelacją zdarzeń,
Zeek – analiza ruchu sieciowego,
Prometheus + Loki + Grafana – zbieranie i wizualizacja metryk oraz logów.
Mit: „monitoring to tylko wykresy i alarmy na e‑mail”. W modelu zero trust monitoring wchodzi w pętlę decyzyjną – na podstawie sygnałów z logów i agentów podejmowane są działania wobec sesji i uprawnień, a nie tylko generowane raporty.
Stopniowe wdrażanie secure access bez wywracania firmy do góry nogami
Największym ryzykiem przy wdrażaniu secure access jest próba zrobienia wszystkiego naraz: pełne SSO, nowe proxy, VPN, polityki, MFA i do tego migracja DNS. Dużo bezpieczniejsze (i zwykle szybsze) jest podejście iteracyjne.
Przykładowa sekwencja kroków:
Wdrożenie IdP z SSO i MFA, bez zmiany sposobu dostępu do większości aplikacji.
Wpięcie pierwszych aplikacji webowych za proxy typu oauth2-proxy (wewnętrzne narzędzia, wiki, Git).
Zastąpienie „tunelu VPN do wszystkiego” – profilami per rola użytkownika.
Wprowadzenie bastionu SSH/RDP i wyłączenie bezpośrednich połączeń spoza strefy zarządzania.
Stopniowe zaostrzanie polityk sieciowych między strefami (i w Kubernetes, jeśli jest używany).
Po każdym etapie:
zbierane są dane z logów (co faktycznie jest blokowane, kto zgłasza problemy),
Opracowano na podstawie
Zero Trust Architecture (SP 800-207). National Institute of Standards and Technology (2020) – Oficjalna definicja i model architektury zero trust
Zero Trust Security Playbook. Microsoft (2021) – Praktyczne omówienie filarów zero trust i wdrożeń w firmach
Zero Trust Security: An Enterprise Guide. O'Reilly Media (2021) – Książka opisująca zasady, segmentację i praktyczne scenariusze ZT
The Zero Trust eXtended Ecosystem. Forrester Research (2018) – Raport analityczny, który spopularyzował koncepcję zero trust
