Zero Trust prosto wyjaśniony: ZTNA zamiast klasycznego VPN
Zero Trust nie oznacza, że nikomu już się nie ufa. Oznacza, że dostęp nie jest przyznawany szeroko tylko dlatego, że użytkownik znajduje się w sieci wewnętrznej, w VPN albo w znanej lokalizacji. Każdy dostęp jest świadomie sprawdzany: kto uzyskuje dostęp? Z jakiego urządzenia? Do jakiej aplikacji? W jakich warunkach?
Zero Trust Network Access, czyli ZTNA, to konkretna realizacja tej idei dla remote access i prywatnych aplikacji. Zamiast otwierać całą sieć przez VPN, użytkownik otrzymuje dostęp tylko do aplikacji lub zasobów przewidzianych dla jego roli.
Ten artykuł wyjaśnia podstawy celowo neutralnie wobec producentów. Cloudflare Access, Sophos ZTNA, Microsoft Entra Private Access i inne rozwiązania realizują podobne zasady w różny sposób. Pierwszą decyzją nie jest więc produkt, lecz model dostępu.
Klasyfikacja Zero Trust i ZTNA
Zero Trust jest architekturą bezpieczeństwa. ZTNA jest techniczną ścieżką dostępu w tej architekturze.
Zero Trust jest zasadą
Klasyczne sieci często działają z ukrytym założeniem: wewnątrz jest bardziej zaufane niż na zewnątrz. Dziś to założenie jest niebezpieczne. Użytkownicy pracują mobilnie, aplikacje są w SaaS, centrum danych i cloud, urządzenia stale zmieniają lokalizację, a przejęte dane logowania są realistycznym scenariuszem.
Zero Trust przesuwa uwagę z granic sieci na tożsamość, urządzenie, aplikację, dane i kontekst. NIST opisuje Zero Trust jako architekturę, która redukuje zaufanie domyślne i ocenia dostęp dla każdego żądania. W praktyce samo udane logowanie już nie wystarcza.
ZTNA to dostęp do konkretnych zasobów
ZTNA zastępuje szeroki dostęp sieciowy dostępem opartym na zasobach. Użytkownik nie widzi automatycznie całej podsieci, lecz tylko aplikacje, do których pasuje policy.
Typowe zasoby ZTNA to:
- wewnętrzne aplikacje webowe,
- portale administracyjne,
- dostęp RDP lub SSH przez kontrolowane ścieżki,
- pojedyncze aplikacje TCP,
- dostęp developerski, supportowy lub partnerski,
- aplikacje SaaS z dodatkową kontrolą dostępu.
Dzięki temu remote access jest bardziej precyzyjny. Przejęte konto nie powinno od razu uzyskać dostępu do całej sieci wewnętrznej.
Dlaczego ZTNA różni się od VPN
VPN nie jest automatycznie złe. Wiele środowisk nadal potrzebuje site-to-site VPN, admin VPN, specjalnych protokołów albo dostępu awaryjnego. Różnica leży w modelu zaufania.
VPN często otwiera sieć
Klasyczny remote access VPN łączy urządzenie z siecią wewnętrzną. Potem routing, reguły firewall, DNS i segmentacja decydują, co jest osiągalne. Jeśli środowisko jest dobrze zbudowane, może to działać. W praktyce sieci VPN są często zbyt szerokie, historycznie rozrośnięte albo trudne do przeglądu.
Typowe ryzyka:
- Użytkownicy otrzymują dostęp do większej liczby systemów niż potrzeba.
- Stare grupy VPN pozostają aktywne.
- Split tunnel, DNS i trasy są niejasne.
- Malware na kliencie VPN może dotrzeć do celów wewnętrznych.
- Dostęp admin używa tego samego tunelu co dostęp użytkowników.
ZTNA sprawdza bliżej aplikacji
ZTNA decyduje per aplikacja lub zasób. Policy może uwzględniać grupę użytkownika, MFA, urządzenie, lokalizację, ryzyko, stan klienta i inne warunki. Dopiero gdy warunki pasują, dozwolony jest dostęp dokładnie do tego zasobu.
Zmniejsza to powierzchnię ataku, ale nie zastępuje bezpiecznej aplikacji. Niebezpieczna aplikacja pozostaje niebezpieczna także za ZTNA. ZTNA kontroluje dostęp, nie automatycznie samą aplikację.
Elementy dobrego środowiska Zero Trust
Zero Trust jest słabe, jeśli zostanie wprowadzone tylko jako nowe narzędzie dostępu. Wartość powstaje dopiero wtedy, gdy kilka elementów działa razem.
Tożsamość i MFA
Tożsamość jest najważniejszym punktem wejścia. Użytkownicy, grupy, role i konta zewnętrzne muszą być utrzymane porządnie. MFA powinno być obowiązkowe dla krytycznych dostępów. W środowiskach Microsoft centralnym źródłem tożsamości jest często Microsoft Entra ID; w innych środowiskach tę samą rolę mogą pełnić inni Identity Providers.
Ważny jest także offboarding. Gdy użytkownik odchodzi z firmy, dostęp musi zniknąć nie tylko w jednej aplikacji, lecz także w centralnej tożsamości i wszystkich istotnych policies.
Urządzenie i kontekst
ZTNA staje się silniejsze, gdy oceniany jest nie tylko użytkownik, lecz także urządzenie. W zależności od rozwiązania na decyzję mogą wpływać system operacyjny, stan urządzenia, certyfikat, status EDR, status zarządzania, lokalizacja lub ryzyko.
Jest to szczególnie istotne dla:
- urządzeń prywatnych,
- zewnętrznych usługodawców,
- uprzywilejowanych dostępów admin,
- dostępu do systemów finansowych, HR lub produkcyjnych,
- urządzeń bez aktualnego statusu ochrony.
Gateway, connector lub usługa cloud
ZTNA potrzebuje ścieżki danych między użytkownikiem a aplikacją. W zależności od dostawcy istnieją gateways, connectors, tunele albo cloud PoPs. Ta część decyduje, gdzie wchodzi ruch, kto obsługuje ścieżkę danych oraz jakie reguły DNS, certyfikaty i firewall są potrzebne.
Cloudflare często pracuje z Cloudflare Tunnel i Access Policies. Sophos ZTNA używa Sophos Central, ZTNA Gateways i policies zasobów. Architektura jest różna, ale podstawowe pytanie pozostaje takie samo: jak użytkownik kontrolowanie dociera do aplikacji bez otwierania całej sieci?
Policies, logging i eksploatacja
Policy ZTNA musi być zrozumiała także później. Dlatego nazwy, grupy, warunki i wyjątki powinny być dokumentowane. Logging jest obowiązkowy, bo inaczej nie widać, czy policy jest zbyt szeroka, użytkownicy są blokowani albo dostęp jest używany niespodziewanie często.
Kiedy ZTNA ma sens
ZTNA pasuje szczególnie dobrze, gdy pojedyncze aplikacje mają być dostępne w kontrolowany sposób. Nie jest celem samym w sobie ani automatycznym zamiennikiem każdego połączenia.
Dobre przypadki użycia
ZTNA zwykle ma sens dla:
- wewnętrznych aplikacji webowych dla pracowników,
- dostępów partnerskich lub usługodawców,
- portali admin, które nie powinny być publicznie dostępne,
- RDP lub SSH przez kontrolowane ścieżki dostępu,
- aplikacji z jasnymi grupami użytkowników,
- środowisk, w których dostęp VPN stał się zbyt szeroki,
- stopniowego zastępowania starych modeli remote access.
Dla zewnętrznych usługodawców ZTNA jest często wygodniejsze niż VPN. Nie trzeba udostępniać całej sieci, lecz można opublikować konkretną aplikację z jasną policy.
Gdzie VPN nadal pasuje
VPN pozostaje użyteczne, gdy trzeba połączyć całe sieci, gdy specjalne protokoły nie działają czysto przez ZTNA albo gdy dostęp awaryjny musi być niezależny od usług cloud. Połączenia site-to-site, niektóre środowiska OT, aplikacje legacy i złożone scenariusze admin mogą nadal wymagać VPN.
Właściwe pytanie nie brzmi więc: “VPN czy ZTNA?” Lepiej: “Który zasób potrzebuje której ścieżki dostępu?”
Neutralna ocena dostawców
Rozwiązania ZTNA znacznie się różnią. Niektóre są bardzo dobre dla aplikacji przeglądarkowych, inne dla dostępu klientowego, a jeszcze inne jako część większej platformy SSE lub SASE.
Ważne kryteria wyboru
Przed wyborem produktu warto wyjaśnić:
- Które aplikacje muszą być osiągalne?
- Czy potrzebny jest dostęp przeglądarkowy, klientowy, czy oba?
- Który Identity Provider jest już ustalony?
- Czy urządzenia mają być sprawdzane według posture?
- Gdzie przebiega ścieżka danych: własna lokalizacja, cloud dostawcy czy oba?
- Jak działają logs, eksport SIEM i audit?
- Czy są jasne procesy awaryjne i break-glass?
- Jak dobrze rozwiązanie pasuje do istniejących firewalls, EDR, MDM i DNS?
Cloudflare jest często silne, gdy Access, Tunnel, DNS, web security i globalna infrastruktura edge mają współdziałać. Sophos ZTNA często pasuje do środowisk, które mocno używają już Sophos Central, Sophos Endpoint lub Sophos Firewall. To nie kwestia wiary, lecz architektury.
Nie każde Zero Trust jest automatycznie lepsze
Źle utrzymywane ZTNA to tylko nowocześniejsze ryzyko. Jeśli grupy są zbyt szerokie, stare wyjątki pozostają, nikt nie czyta logów albo kontrola urządzeń istnieje tylko na papierze, nie powstaje silne środowisko Zero Trust.
Wdrażanie w sensownej kolejności
Dobre wdrożenie nie zaczyna się od kliknięcia w produkcie, lecz od małej, dobrze zrozumianej aplikacji.
- Zinwentaryzować aplikacje i posortować według ryzyka.
- Oczyścić grupy użytkowników i role zewnętrzne.
- Ustabilizować Identity Provider i MFA.
- Wybrać aplikację pilotażową, ważną, ale możliwą do opanowania.
- Zaplanować ścieżkę danych, DNS, certyfikat i logging.
- Przetestować policy z małą grupą użytkowników.
- Sprawdzić logs, zebrać przypadki supportowe i poprawić doświadczenie użytkownika.
- Migrować kolejne aplikacje krok po kroku.
- Ograniczać dostępy VPN dopiero wtedy, gdy ZTNA działa w eksploatacji.
Dla środowisk Sophos kolejnym krokiem jest Konfiguracja Sophos ZTNA: przegląd i kolejność. Jeśli konkretnym tematem jest gateway, pomaga Planowanie i tworzenie Sophos ZTNA Gateway.
Typowe błędy
Traktowanie ZTNA jako czystej wymiany VPN
Jeśli zastępowany jest tylko tunel, ale grupy, aplikacje, urządzenia i logs pozostają bez zmian, zysk bezpieczeństwa jest niewielki. ZTNA powinno być planowane per zasób.
Migracja zbyt wielu aplikacji naraz
Duży rollout big-bang jest ryzykowny. Lepszy jest pilot z prawdziwą aplikacją, jasnymi kryteriami sukcesu i czystą ścieżką powrotu.
Zapomnienie o dostępie awaryjnym
Identity Provider, DNS, usługa cloud lub gateway mogą zawieść. Admini potrzebują udokumentowanego dostępu break-glass, silnie chronionego, rzadko używanego i regularnie sprawdzanego.
Brak obsługi logów
ZTNA bez loggingu jest trudne do supportu. Powinno być widać, który użytkownik uzyskuje dostęp do którego zasobu, która policy działa, dlaczego dostęp został zablokowany i czy pojawiają się nietypowe wzorce.
Checklista operacyjna
- Dokumentować aplikacje i ownerów.
- Utrzymywać grupy użytkowników małe i zrozumiałe.
- Wymuszać MFA dla krytycznych dostępów.
- Aktywnie używać kontroli urządzeń, jeśli rozwiązanie wspiera ją czysto.
- Regularnie sprawdzać policies względem rzeczywistego użycia.
- Wysyłać logs do SIEM lub centralnego loggingu, jeśli dostęp jest krytyczny.
- Dokumentować i testować dostęp break-glass.
- Usuwać stare uprawnienia VPN po udanej migracji.
- Nadawać dostępowi usługodawców datę wygaśnięcia lub review.