Przez ponad dwie dekady VPN (Virtual Private Network) był synonimem bezpiecznego dostępu zdalnego. Pracownik łączył się z firmową siecią, wpisywał login i hasło, a tunel VPN dawał mu dostęp do zasobów korporacyjnych tak, jakby siedział przy biurku w firmie. Ten model działał dobrze w świecie, w którym aplikacje znajdowały się w lokalnym data center, a pracownicy łączyli się z jednego urządzenia firmowego.
Ten świat już nie istnieje. Aplikacje przeniosły się do chmury, pracownicy korzystają z wielu urządzeń w wielu lokalizacjach, a granica sieci korporacyjnej — jeśli jeszcze istnieje — jest nieostra i trudna do obrony. VPN, projektowany dla prostszej rzeczywistości, nie nadąża za tymi zmianami i coraz częściej staje się słabym ogniwem architektury bezpieczeństwa.
W odpowiedzi na te wyzwania powstało podejście ZTNA (Zero Trust Network Access) — model, który zamiast ufać sieci, weryfikuje każde połączenie z osobna. W tym artykule szczegółowo porównamy oba podejścia, wyjaśnimy architekturę ZTNA, przeanalizujemy ofertę wiodących dostawców i przedstawimy praktyczną ścieżkę migracji.
Tradycyjny VPN — jak działa i dlaczego przestaje wystarczać
Architektura klasycznego VPN
VPN tworzy szyfrowany tunel między urządzeniem użytkownika a bramą VPN (concentratorem) w sieci korporacyjnej. Po nawiązaniu połączenia i uwierzytelnieniu użytkownik otrzymuje adres IP z puli firmowej i — z perspektywy sieci — staje się jej pełnoprawnym członkiem. Ruch sieciowy jest tunelowany przez szyfrowane połączenie, co chroni dane przed podsłuchem na trasie.
Najpopularniejsze protokoły VPN to IPsec (z IKEv2), SSL/TLS VPN (OpenVPN, Cisco AnyConnect), WireGuard oraz starsze protokoły jak L2TP/IPsec czy PPTP. Każdy z nich realizuje ten sam cel — tworzy wirtualny tunel łączący urządzenie z siecią docelową.
Problem nr 1: nadmierny dostęp i lateral movement
Fundamentalnym problemem VPN jest model dostępu oparty na przynależności do sieci. Po uwierzytelnieniu użytkownik zazwyczaj widzi całą podsieć lub znaczną jej część — serwery plików, bazy danych, systemy wewnętrzne, drukarki, a nawet urządzenia IoT. To klasyczny model „zamek i fosa” (castle-and-moat): raz przekroczywszy bramę, masz swobodę poruszania się.
Z perspektywy atakującego to idealna sytuacja. Przejęcie jednego konta VPN — przez phishing, kradzież tokena lub exploit na urządzeniu końcowym — daje dostęp do całej sieci. Atakujący może swobodnie przemieszczać się lateralnie (lateral movement), skanować hosty, eskalować uprawnienia i dotrzeć do krytycznych zasobów. Liczne incydenty bezpieczeństwa ostatnich lat — od ataków ransomware po wycieki danych — zaczynały się właśnie od skompromitowanego połączenia VPN.
Problem nr 2: split tunneling i wydajność
VPN wymusza routowanie ruchu przez centralny punkt (bramę VPN), co w przypadku full-tunnel VPN oznacza, że cały ruch internetowy użytkownika — w tym dostęp do aplikacji SaaS jak Microsoft 365, Google Workspace czy Salesforce — przepływa przez infrastrukturę firmy. Przy tysiącach użytkowników pracujących zdalnie staje się to wąskim gardłem wydajnościowym.
Split tunneling — gdzie tylko ruch do sieci firmowej idzie przez tunel, a reszta bezpośrednio do internetu — łagodzi problem wydajności, ale tworzy lukę bezpieczeństwa. Ruch internetowy z urządzenia nie przechodzi przez firmowe zabezpieczenia (firewall, proxy, IPS), co zwiększa powierzchnię ataku.
Problem nr 3: skalowanie i koszty
Infrastruktura VPN skaluje się liniowo — więcej użytkowników oznacza więcej licencji, większe koncentratory, wyższe pasmo na łączach. Pandemia COVID-19 boleśnie obnażyła te ograniczenia, gdy organizacje z VPN-ami zaprojektowanymi na 20-30% pracowników zdalnych musiały nagle obsłużyć 100%. Koncentratory VPN przeciążone, kolejki logowania, rozłączenia — to było doświadczenie wielu firm w 2020 roku.
Sprzętowe rozwiązania VPN (Cisco ASA, Palo Alto GlobalProtect, Fortinet FortiGate) wymagają inwestycji w sprzęt, licencje, utrzymanie i patching. Każda podatność w oprogramowaniu VPN (a jest ich niemało — wystarczy spojrzeć na historię CVE dla Pulse Secure/Ivanti, Fortinet czy Cisco) wymaga pilnego łatania, bo brama VPN jest z definicji wystawiona na internet.
Problem nr 4: brak kontekstu i granulacji
Tradycyjny VPN podejmuje decyzję o dostępie w jednym momencie — podczas logowania. Po uwierzytelnieniu sesja trwa godziny lub dni, bez ponownej weryfikacji stanu urządzenia, lokalizacji czy zachowania użytkownika. Nie ma mechanizmu, który odcinałby dostęp w czasie rzeczywistym, gdy urządzenie zostanie zainfekowane lub użytkownik zachowuje się anomalnie.
VPN również nie rozróżnia aplikacji — daje dostęp sieciowy, a nie aplikacyjny. Nie ma natywnego sposobu, by powiedzieć: „ten użytkownik może korzystać z systemu HR, ale nie z bazy produkcyjnej”, bez dodawania kolejnych warstw kontroli (firewalle wewnętrzne, mikrosegmentacja).
Zero Trust Network Access (ZTNA) — nowy paradygmat
Czym jest ZTNA?
ZTNA (Zero Trust Network Access) to model bezpieczeństwa, w którym dostęp do aplikacji i zasobów przyznawany jest na podstawie ciągłej weryfikacji tożsamości, kontekstu urządzenia i polityk bezpieczeństwa — a nie na podstawie przynależności do sieci. Termin „Zero Trust” nie oznacza braku zaufania do użytkowników, lecz brak domyślnego zaufania do sieci jako warstwy bezpieczeństwa.
Kluczowe zasady ZTNA:
- Nigdy nie ufaj, zawsze weryfikuj — każde żądanie dostępu jest uwierzytelniane i autoryzowane, niezależnie od lokalizacji użytkownika (biuro, dom, kawiarnia).
- Zasada najmniejszego uprawnienia (least privilege) — użytkownik otrzymuje dostęp wyłącznie do konkretnych aplikacji, których potrzebuje, nie do całej sieci.
- Ciągła walidacja — stan urządzenia, lokalizacja, czas, zachowanie użytkownika są monitorowane przez cały czas trwania sesji, a nie tylko w momencie logowania.
- Ukrycie infrastruktury — aplikacje nie są eksponowane w internecie. ZTNA tworzy „ciemną chmurę” (dark cloud), w której zasoby są niewidoczne dla skanowania portów.
Jak działa ZTNA — architektura
Architektura ZTNA składa się z trzech głównych komponentów, które współpracują, aby zapewnić bezpieczny dostęp bez eksponowania sieci:
1. Broker (Trust Broker / Controller)
Centralny punkt decyzyjny działający w chmurze lub w infrastrukturze organizacji. Broker pośredniczy w nawiązywaniu połączeń — użytkownik nigdy nie łączy się bezpośrednio z aplikacją docelową. Zamiast tego broker:
- Przyjmuje żądanie dostępu od klienta
- Weryfikuje tożsamość użytkownika (integracja z IdP — Okta, Azure AD, Ping Identity)
- Sprawdza kontekst urządzenia (wersja OS, status antywirusa, szyfrowanie dysku, obecność agenta EDR)
- Konsultuje polityki bezpieczeństwa z policy engine
- Jeśli warunki są spełnione — nawiązuje mikro-tunel między klientem a konkretną aplikacją
Broker jest jedynym komponentem widocznym z internetu, a i on nie eksponuje żadnych portów nasłuchujących — komunikacja odbywa się poprzez połączenia wychodzące z konektorów.
2. Connector (App Connector / Gateway)
Lekki komponent software’owy instalowany w pobliżu chronionej aplikacji — w tym samym data center, klastrze Kubernetes, VPC w chmurze publicznej lub nawet na tym samym hoście. Connector:
- Nawiązuje trwałe połączenie wychodzące do brokera (reverse tunnel)
- Nie wymaga otwarcia żadnych portów przychodzących na firewallu
- Pośredniczy w ruchu między brokerem a aplikacją
- Może obsługiwać wiele aplikacji jednocześnie
Dzięki temu, że connector inicjuje połączenie do brokera (a nie odwrotnie), aplikacje chronione przez ZTNA są niewidoczne z internetu — nie można ich znaleźć skanowaniem portów czy narzędziami typu Shodan.
3. Policy Engine (silnik polityk)
Komponent odpowiedzialny za podejmowanie decyzji o dostępie na podstawie wielowymiarowego kontekstu. Policy engine przetwarza reguły w formie: „KTO (tożsamość) + SKĄD (lokalizacja, sieć) + CZYM (urządzenie, stan) + KIEDY (czas, dzień) = dostęp do CZEGO (aplikacja, zasób) z jakimi OGRANICZENIAMI (czas sesji, uprawnienia)”.
Polityki mogą uwzględniać:
- Tożsamość: użytkownik, grupa, rola, jednostka organizacyjna
- Urządzenie: system operacyjny, wersja, status zarządzania (MDM), stan zabezpieczeń (firewall, szyfrowanie, patchlevel)
- Sieć: adres IP, geolokalizacja, typ sieci (korporacyjna, domowa, publiczna)
- Ryzyko: ocena ryzyka sesji na podstawie analizy behawioralnej (UEBA), wynik z systemu EDR/XDR
- Czas: okna czasowe dostępu, ograniczenia godzinowe
Decyzja nie jest binarna (tak/nie) — policy engine może wymusić dodatkowe uwierzytelnienie (step-up MFA), ograniczyć zakres uprawnień, włączyć nagrywanie sesji lub zablokować dostęp w zależności od poziomu ryzyka.
ZTNA 1.0 vs ZTNA 2.0
Warto rozróżnić dwie generacje rozwiązań ZTNA:
ZTNA 1.0 (pierwsza generacja, ~2018-2022):
- Kontrola dostępu na poziomie połączenia (allow/deny)
- Brak inspekcji ruchu po nawiązaniu sesji
- Reguły oparte głównie na tożsamości i adresie aplikacji
- Model „zaufaj i pozwól” po autoryzacji
ZTNA 2.0 (obecna generacja):
- Ciągła inspekcja ruchu aplikacyjnego (DLP, threat prevention) nawet po nawiązaniu sesji
- Identyfikacja aplikacji na poziomie App-ID, nie tylko IP/port
- Ochrona wszystkich aplikacji (nie tylko HTTP/HTTPS, ale też SSH, RDP, bazy danych, protokoły legacy)
- Dynamiczna zmiana polityk w trakcie sesji na podstawie zachowania
ZTNA vs VPN — porównanie
| Kryterium | Tradycyjny VPN | ZTNA |
|---|---|---|
| Model dostępu | Dostęp do sieci (network-level) | Dostęp do aplikacji (app-level) |
| Uwierzytelnianie | Jednorazowe, przy logowaniu | Ciągłe, kontekstowe |
| Zasada zaufania | Zaufanie do sieci (implicit trust) | Zero zaufania (explicit verify) |
| Widoczność zasobów | Aplikacje eksponowane w internecie | Aplikacje ukryte (dark cloud) |
| Lateral movement | Możliwy po przejęciu sesji | Zablokowany — dostęp per-aplikacja |
| Skalowalność | Liniowa (sprzęt + licencje) | Elastyczna (chmura, auto-scaling) |
| Wydajność | Bottleneck na koncentratorze | Routing optymalny (edge PoP) |
| Kontekst urządzenia | Ograniczony lub brak | Pełna ocena posture w czasie rzeczywistym |
| Split tunneling | Kompromis bezpieczeństwo vs wydajność | Nie dotyczy — ruch aplikacyjny, nie sieciowy |
| Wdrożenie | Konfiguracja sprzętu, otwieranie portów | Software connector, brak zmian w firewallu |
| Doświadczenie użytkownika | Ręczne łączenie, przerwy, wolne działanie | Transparentne, automatyczne, szybkie |
| Obsługa użytkowników zewnętrznych | Skomplikowana (osobne profile, licencje) | Natywna (dostęp bez agenta, per-link) |
Wiodący dostawcy ZTNA
Rynek ZTNA jest dojrzały i konkurencyjny. Poniżej charakterystyka głównych graczy, ich podejście architektoniczne i wyróżniki.
Zscaler Private Access (ZPA)
Zscaler to pionier modelu security-as-a-service i jeden z dwóch liderów w Gartner Magic Quadrant for SSE. ZPA (Zscaler Private Access) to ich rozwiązanie ZTNA:
- Architektura: w pełni chmurowa, ponad 150 edge locations globalnie. Ruch nigdy nie przechodzi przez data center klienta — broker w chmurze Zscaler łączy użytkownika z konektorem przy aplikacji.
- App Connector: lekki VM lub kontener instalowany w środowisku klienta. Nawiązuje połączenie wychodzące do Zscaler cloud.
- Wyróżnik: Browser Isolation do bezpiecznego dostępu bez agenta, Deception Technology (honeypoty w sieci ZTNA), integracja z Zscaler Internet Access (ZIA) w ramach jednej platformy.
- Wady: vendor lock-in na ekosystem Zscaler, wyższe koszty przy dużej skali.
Cloudflare Access (Cloudflare One)
Cloudflare wykorzystuje swoją globalną sieć (ponad 300 miast) jako punkt pośredniczący dla ZTNA:
- Architektura: sieć Anycast — użytkownik łączy się z najbliższym PoP Cloudflare, co minimalizuje latency. Ruch trafia do konektora (cloudflared tunnel) w sieci klienta.
- Wyróżnik: darmowy tier dla małych zespołów (do 50 użytkowników), wyjątkowo prosty setup, natywna integracja z Cloudflare Workers, Gateway (SWG) i WAF.
- Model bez agenta: Cloudflare Access obsługuje dostęp przez przeglądarkę do aplikacji webowych bez instalowania klienta — idealne dla kontrahentów i BYOD.
- Wady: mniejszy ekosystem enterprise, ograniczona inspekcja ruchu nie-webowego w trybie bez agenta.
Palo Alto Prisma Access
Prisma Access to rozwiązanie SASE od Palo Alto Networks, w którym ZTNA jest jednym z komponentów:
- Architektura: chmura oparta na infrastrukturze Palo Alto z ponad 100 lokalizacjami. Wykorzystuje tę samą technologię firewallową co fizyczne urządzenia PA.
- Wyróżnik: ZTNA 2.0 z pełną inspekcją ruchu App-ID, natywna integracja z Cortex XDR/XSIAM (automatyczna reakcja na zagrożenia), wsparcie dla wszystkich protokołów.
- GlobalProtect: agent VPN/ZTNA Palo Alto, który może działać w obu trybach — ułatwia migrację z istniejących wdrożeń GlobalProtect VPN.
- Wady: złożoność konfiguracji, wysoka cena, wymaga kompetencji w ekosystemie Palo Alto.
Fortinet Universal ZTNA
Fortinet integruje ZTNA bezpośrednio w swoje urządzenia FortiGate:
- Architektura: hybrydowa — ZTNA proxy wbudowany w FortiGate (on-premise lub VM), z opcjonalnym FortiSASE dla wdrożeń chmurowych.
- Wyróżnik: brak dodatkowych kosztów licencyjnych — ZTNA jest częścią FortiOS 7.x, dostępne na każdym FortiGate. Idealne dla organizacji już korzystających z ekosystemu Fortinet.
- Agent: FortiClient pełni rolę agenta ZTNA, VPN i EDR w jednym.
- Wady: model on-premise wymaga zarządzania sprzętem, mniejsza globalność niż rozwiązania cloud-native.
Inni gracze warci uwagi
- Netskope Private Access — lider SSE z silnym DLP i CASB, ZTNA jako element platformy NewEdge.
- Cisco Secure Access (dawniej Duo + AppGate) — integracja z ekosystemem Cisco (ISE, Umbrella, SecureX).
- Akamai Enterprise Application Access — wykorzystuje CDN Akamai jako warstwę ZTNA.
- Twingate — startup celujący w prostotę i developer experience, popularny wśród mniejszych firm.
- Tailscale — mesh VPN oparty na WireGuard z elementami Zero Trust (ACL, SSO), open-source core.
SASE i SSE — szerszy kontekst
ZTNA nie istnieje w próżni — jest częścią szerszych architektur bezpieczeństwa sieciowego. Dwa kluczowe pojęcia to SASE i SSE.
SASE (Secure Access Service Edge)
SASE, termin ukuty przez Gartnera w 2019 roku, to architektura łącząca funkcje sieciowe i bezpieczeństwa w jednej platformie chmurowej:
- Strona sieciowa: SD-WAN, optymalizacja WAN, QoS, routing
- Strona bezpieczeństwa: ZTNA, SWG (Secure Web Gateway), CASB (Cloud Access Security Broker), FWaaS (Firewall as a Service), DLP
Idea SASE: zamiast routować ruch przez centralny data center (hub-and-spoke), zabezpieczenia działają na edge — w chmurze dostawcy, blisko użytkownika. Użytkownik w Krakowie łączący się z aplikacją w Azure West Europe nie musi jechać ruchem przez VPN w Warszawie — łączy się z najbliższym PoP dostawcy SASE, który egzekwuje polityki bezpieczeństwa i kieruje ruch optymalną ścieżką.
SSE (Security Service Edge)
SSE to podzbiór SASE obejmujący wyłącznie komponent bezpieczeństwa — bez SD-WAN. Gartner wyodrębnił tę kategorię, ponieważ wiele organizacji chce wdrożyć bezpieczeństwo chmurowe (ZTNA + SWG + CASB) niezależnie od transformacji sieci (SD-WAN).
SSE obejmuje:
- ZTNA — bezpieczny dostęp do aplikacji prywatnych
- SWG — bezpieczny dostęp do internetu (filtrowanie URL, inspekcja SSL, ochrona przed malware)
- CASB — kontrola dostępu i bezpieczeństwo danych w aplikacjach SaaS
Dla wielu organizacji SSE jest pragmatycznym pierwszym krokiem — wdrożenie ZTNA i SWG bez konieczności jednoczesnej wymiany infrastruktury WAN.
Migracja z VPN na ZTNA — praktyczny przewodnik
Migracja z VPN na ZTNA nie jest operacją typu „wyłącz-włącz”. To proces, który wymaga planowania, etapowości i równoległego działania obu systemów przez okres przejściowy.
Faza 1: Inwentaryzacja i discovery (2-4 tygodnie)
Zanim cokolwiek wdrożysz, musisz wiedzieć, co chronisz:
- Katalog aplikacji: jakie aplikacje są dostępne przez VPN? Webowe, gruby klient, RDP, SSH, bazy danych? Jakie protokoły i porty?
- Katalog użytkowników: kto korzysta z VPN? Pracownicy, kontrahenci, partnerzy? Jakie grupy mają dostęp do jakich zasobów?
- Mapowanie ruchu: analiza logów VPN — kto łączy się z czym, jak często, z jakich lokalizacji i urządzeń?
- Identyfikacja IdP: czy organizacja ma centralny Identity Provider (Azure AD, Okta, Google Workspace)? Czy MFA jest wdrożone?
Faza 2: Pilotaż (2-4 tygodnie)
Wybierz grupę pilotażową i zestaw aplikacji do pierwszego wdrożenia ZTNA:
- Najlepszy kandydat na start: aplikacje webowe (HTTP/HTTPS) — najłatwiejsze do obsłużenia przez ZTNA, nie wymagają agenta na urządzeniu.
- Grupa pilotażowa: zespół IT lub security — znają narzędzia, potrafią zgłaszać problemy, rozumieją cel zmiany.
- Równoległe działanie: VPN działa normalnie, ZTNA jako dodatkowa ścieżka dostępu. Użytkownicy mogą korzystać z obu.
- Metryki sukcesu: czas logowania, stabilność połączeń, feedback użytkowników, liczba ticketów supportu.
Faza 3: Rozszerzenie (1-3 miesiące)
Stopniowe przenoszenie kolejnych aplikacji i grup użytkowników:
- Priorytet: aplikacje w chmurze publicznej (AWS, Azure, GCP) — konektor ZTNA wdrożony natywnie w cloud.
- Następnie: aplikacje w on-premise data center — konektor jako VM lub kontener.
- Na końcu: aplikacje legacy (protokoły nie-HTTP, grube klienty) — mogą wymagać agenta ZTNA na urządzeniu.
Faza 4: Wyłączenie VPN (1-3 miesiące)
Ostatni etap to kontrolowane wyłączenie VPN:
- Monitoring: sprawdź, czy jacyś użytkownicy nadal łączą się przez VPN. Jeśli tak — zidentyfikuj przyczynę (brakująca aplikacja w ZTNA, problem z kompatybilnością).
- Okres karencji: wyłącz nowe sesje VPN, ale utrzymuj tunel przez 2-4 tygodnie jako fallback.
- Decommission: wyłączenie koncentratorów VPN, zwolnienie licencji, zamknięcie portów na firewallu.
Pułapki migracji
- Nie próbuj migrować wszystkiego naraz — etapowość jest kluczowa. Nagłe wyłączenie VPN bez pokrycia 100% aplikacji przez ZTNA to recepta na chaos.
- Nie ignoruj aplikacji legacy — starsze systemy (np. grube klienty Oracle, AS/400, protokoły niestandardowe) mogą nie działać z ZTNA w trybie proxy. Potrzebujesz konektora agent-based.
- Zaplanuj wyjątki — zawsze będą scenariusze, które nie pasują do modelu ZTNA (np. debugowanie sieci, połączenia site-to-site). Miej plan B.
- Komunikacja z użytkownikami — zmiana sposobu dostępu to zmiana nawyków. Jasna komunikacja, szkolenia i responsywny helpdesk są niezbędne.
Scenariusze wdrożenia ZTNA
Praca zdalna i hybrydowa
To najbardziej oczywisty scenariusz. Pracownicy zdalni nie potrzebują dostępu do całej sieci korporacyjnej — potrzebują dostępu do konkretnych aplikacji: systemu HR, CRM, narzędzi deweloperskich, poczty wewnętrznej. ZTNA daje im dokładnie tyle, ile potrzebują, bez ryzyka lateral movement i bez bottlenecku koncentratora VPN.
Dodatkowa korzyść: ZTNA działające w modelu cloud proxy optymalizuje routing — użytkownik w Gdańsku łączy się z PoP we Frankfurcie, a nie tuneluje ruch przez data center w Warszawie, by wrócić do aplikacji w Azure West Europe.
Fuzje i przejęcia (M&A)
Integracja IT po fuzji to koszmar — różne domeny Active Directory, różne sieci, niekompatybilne VPN-y. Tradycyjne podejście (trust między domenami, łączenie sieci) zajmuje miesiące i niesie ogromne ryzyko bezpieczeństwa.
ZTNA upraszcza ten scenariusz radykalnie: instalujesz konektory w sieci przejmowanej firmy, definiujesz polityki dostępu i w ciągu dni — nie miesięcy — pracownicy obu organizacji mają kontrolowany dostęp do wybranych zasobów. Bez łączenia sieci, bez trustów domenowych, bez otwierania portów między sieciami.
Dostęp kontrahentów i dostawców (third-party access)
VPN dla kontrahentów to zawsze problem: osobne konta, osobne profile, agent do zainstalowania na urządzeniu, którego nie kontrolujesz. ZTNA w trybie agentless (dostęp przez przeglądarkę) rozwiązuje to elegancko:
- Kontrahent dostaje link do aplikacji
- Uwierzytelnia się przez swojego IdP (federacja SAML/OIDC) lub jednorazowy kod
- Widzi tylko tę jedną aplikację, do której został zaproszony
- Sesja jest ograniczona czasowo i monitorowana
Brak instalacji agenta, brak dostępu do sieci, pełna kontrola po stronie organizacji.
Ochrona aplikacji OT/ICS
Środowiska przemysłowe (OT — Operational Technology) tradycyjnie izolowane air-gapem coraz częściej potrzebują zdalnego dostępu — do monitoringu, diagnostyki i aktualizacji. VPN do sieci OT to ekstremalne ryzyko: przejęcie sesji VPN daje atakującemu dostęp do systemów sterowania przemysłowego.
ZTNA ogranicza ten wektor — kontraktor serwisowy otrzymuje dostęp wyłącznie do konkretnego interfejsu HMI lub portalu diagnostycznego, z monitorowaniem sesji i nagrywaniem ekranu. Bez możliwości skanowania sieci OT czy łączenia się z innymi urządzeniami.
Best practices wdrożenia ZTNA
1. Zacznij od tożsamości
ZTNA bez solidnego fundamentu tożsamości nie ma sensu. Upewnij się, że masz:
- Centralny Identity Provider (Azure AD/Entra ID, Okta, Google Workspace)
- MFA wdrożone dla wszystkich użytkowników (najlepiej phishing-resistant: FIDO2/WebAuthn)
- Aktualny katalog użytkowników z poprawnymi grupami i rolami
- Proces offboardingu — konto zablokowane natychmiast po odejściu pracownika
2. Mapuj aplikacje, nie sieci
Myśl w kategoriach aplikacji, nie podsieci. Zamiast „daj dostęp do 10.0.1.0/24” definiuj „daj dostęp do systemu CRM (crm.internal.company.com:443)”. To wymaga inwentaryzacji aplikacji, ale daje nieporównywalnie lepszą kontrolę.
3. Wdrażaj device posture
Sam fakt, że użytkownik się uwierzytelnił, nie wystarczy. Sprawdzaj stan urządzenia:
- Czy system operacyjny jest zaktualizowany?
- Czy dysk jest zaszyfrowany?
- Czy agent EDR jest aktywny i zaktualizowany?
- Czy urządzenie jest zarządzane przez MDM (jeśli to urządzenie firmowe)?
Urządzenia niespełniające wymagań mogą otrzymać ograniczony dostęp (np. tylko webmail przez przeglądarkę, bez pełnego dostępu do aplikacji wewnętrznych).
4. Monitoruj i audytuj
ZTNA generuje bogaty strumień telemetrii — kto, kiedy, z jakiego urządzenia, do jakiej aplikacji. Wykorzystaj te dane:
- Integracja z SIEM (Splunk, Microsoft Sentinel, Elastic)
- Alerty na anomalie (logowanie z nieznanej lokalizacji, dostęp poza godzinami, nagły wzrost ruchu)
- Regularne przeglądy dostępów (access reviews) — czy użytkownicy nadal potrzebują dostępów, które mają?
5. Planuj na wyjątki
Nie wszystko da się objąć ZTNA od razu. Miej świadomy plan na:
- Aplikacje legacy z niestandardowymi protokołami
- Scenariusze disaster recovery (co jeśli chmura ZTNA jest niedostępna?)
- Połączenia site-to-site między lokalizacjami
- Debugowanie i troubleshooting sieci (narzędzia wymagające pełnego dostępu sieciowego)
Wyjątki powinny być dokumentowane, ograniczone czasowo i regularnie weryfikowane.
6. Edukuj użytkowników
Zmiana z VPN na ZTNA to zmiana doświadczenia użytkownika — często na lepsze (szybsze połączenia, brak ręcznego logowania do VPN), ale wymaga komunikacji. Użytkownicy muszą wiedzieć:
- Dlaczego zmiana jest wprowadzana
- Jak nowy system działa z ich perspektywy
- Do kogo zwrócić się z problemami
- Że ich produktywność nie ucierpi (a wręcz się poprawi)
Przyszłość: konwergencja ZTNA, SD-WAN i AI
Rynek zmierza w kierunku pełnej konwergencji — ZTNA, SWG, CASB, DLP, SD-WAN i analityka bezpieczeństwa w jednej platformie. Dostawcy tacy jak Zscaler, Palo Alto, Netskope czy Cloudflare już oferują zintegrowane rozwiązania, a granice między kategoriami produktowymi zacierają się.
Kolejnym przełomem będzie zastosowanie AI/ML w politykach dostępu. Zamiast statycznych reguł opartych na grupach i rolach, systemy ZTNA będą dynamicznie dostosowywać poziom dostępu na podstawie analizy behawioralnej — anomalne zachowanie automatycznie obniża zaufanie i wymusza dodatkową weryfikację, normalne zachowanie stopniowo je podnosi. To tzw. adaptive trust — zaufanie nie jest binarne (tak/nie), lecz ciągłe i kontekstowe.
Universal ZTNA — jedno rozwiązanie dla wszystkich scenariuszy (pracownicy zdalni, biurowi, IoT, OT, multi-cloud) — to cel, do którego branża zmierza. Firmy wdrażające ZTNA dziś budują fundament pod architekturę bezpieczeństwa, która będzie dominować przez następną dekadę.
Podsumowanie
VPN spełnił swoją rolę w epoce sieci perymetrowych i scentralizowanych data center. W świecie chmury, pracy hybrydowej i wyrafinowanych zagrożeń jego ograniczenia — nadmierny dostęp, brak kontekstu, problemy ze skalowaniem — stają się nie do zaakceptowania.
ZTNA nie jest modną nazwą marketingową, lecz fundamentalną zmianą podejścia do bezpieczeństwa dostępu. Zamiast ufać sieci i dawać szeroki dostęp po jednorazowym uwierzytelnieniu, weryfikuje każde połączenie, ogranicza dostęp do minimum i monitoruje sesję w czasie rzeczywistym.
Migracja z VPN na ZTNA to proces — nie jednorazowe zdarzenie. Wymaga inwentaryzacji aplikacji, dojrzałego zarządzania tożsamością, etapowego wdrożenia i cierpliwości. Ale organizacje, które tę drogę przeszły, zyskują lepsze bezpieczeństwo, niższe koszty operacyjne i znacząco lepsze doświadczenie użytkowników. W 2026 roku pytanie nie brzmi już „czy migrować z VPN na ZTNA”, lecz „jak szybko to zrobić”.
Tematy powiązane
Zobacz również:
Powiązane terminy
Sprawdź nasze usługi
- Bezpieczeństwo sieci - wdrożenia ZTNA i Zero Trust
Powiązane usługi i produkty
- Managed Detection & Response (MDR)
- Profesjonalne Testy Penetracyjne Sieci Wi-Fi
- Extreme Networks Platform
