Zero trust vs VPN: jak dziś powinien działać dostęp zdalny?

Co naprawdę robi tradycyjny VPN

VPN, czyli virtual private network, buduje szyfrowany tunel między zdalnym urządzeniem a siecią firmową. Pierwotnie jego zadaniem była poufność: utrzymywał ruch prywatny, gdy przechodził przez otwarty internet, więc ktoś pracujący z hotelu albo domowego biura mógł dotrzeć do systemów wewnętrznych tak, jakby był w biurowym LAN.

Ważna część to to, co dzieje się po połączeniu tunelu. Zdalne urządzenie zostaje umieszczone w sieci wewnętrznej, albo w jej wycinku, i od tego momentu traktowane jako insider. Gdy już jesteś w środku, sieć w dużej mierze zakłada, że tam należysz. Często widzisz i możesz dotrzeć do szerokiego zakresu systemów wewnętrznych, nie tylko do jednej aplikacji, do której się logowałeś. VPN uwierzytelnia cię przy drzwiach, a potem w większości przestaje zadawać pytania.

To model „zaufany w środku". Bezpieczeństwo żyje na obwodzie, jak mur wokół budynku. Przejdź przez mur, a możesz poruszać się w środku dość swobodnie. Przez lata był to akceptowalny kompromis, bo mur był trudny do wspięcia, a większość ataków przychodziła z zewnątrz.

Czemu „zaufany w środku" stał się zagrożeniem

Problem w tym, że mur to już nie jest trudna część. Atakujący rzadko łamią szyfrowanie VPN. Logują się danymi uwierzytelniającymi, które już działają, wyłudzonymi ze strony phishingowej, kupionymi od brokera albo wyciągniętymi z maszyny zainfekowanej złodziejem informacji. Gdy te dane uwierzytelniające przeprowadzą ich przez tunel, model „zaufany w środku" robi za nich resztę pracy. Dziedziczą taki sam szeroki zasięg, jaki miałby legalny pracownik.

Ten szeroki zasięg to główne zagrożenie. W płaskiej albo słabo posegmentowanej sieci jedna ważna sesja VPN może być ścieżką do udziałów plikowych, aplikacji wewnętrznych, paneli administracyjnych i systemów backupu. Pojedynczy skradziony login nie odblokowuje jednych drzwi. Odblokowuje cały budynek.

To nie jest obawa teoretyczna. Skompromitowane dane uwierzytelniające VPN były wektorem początkowego dostępu w 48% ataków ransomware odnotowanych w trzecim kwartale 2025 roku, wobec 38% w drugim kwartale, według kwartalnego raportu zagrożeń Beazley Security. Ten sam raport odnotował, że najaktywniejsze grupy ransomware tego kwartału rutynowo celowały w publiczne bramy VPN, często przez credential stuffing, brute-force zgadywanie słabych haseł i wykorzystywanie znanych podatności urządzeń VPN. Wzorzec jest spójny w danych o incydentach z całej branży: dostęp zdalny, który daje sieć, a nie aplikację, to powtarzający się punkt wejścia.

Dwa trendy pogarszają sytuację. Po pierwsze, rzeczy warte kradzieży się przeniosły. Dużo biznesu działa dziś w aplikacjach chmurowych, których VPN nigdy nie był zaprojektowany chronić, więc VPN często chroni coraz bardziej pusty budynek, podczas gdy wartościowe rzeczy siedzą gdzie indziej. Po drugie, populacja tożsamości się przesunęła. Konta serwisowe, klucze API i zautomatyzowane obciążenia proszą dziś o dostęp obok ludzi, a model zbudowany wokół człowieka łączącego się z siecią radzi sobie z nimi słabo.

Co zmienia zero trust

Zero trust zaczyna od przeciwnego założenia. Zamiast ufać żądaniu, bo przyszło z wewnątrz sieci, nie daje żadnego domyślnego zaufania na podstawie tego, skąd żądanie pochodzi. NIST przedstawia to w Special Publication 800-207, swoim dokumencie referencyjnym dla architektury zero trust, który stwierdza, że żadne zaufanie nie jest przyznawane urządzeniu ani kontu wyłącznie na podstawie jego fizycznej albo sieciowej lokalizacji, ani tego, kto jest właścicielem zasobu. Robocze streszczenie brzmi: nigdy nie ufaj, zawsze weryfikuj.

W praktyce, zastosowane do dostępu zdalnego, staje się to zero trust network access, ZTNA. Różnice względem VPN są konkretne:

• Dostęp jest przyznawany do konkretnej aplikacji, nie do sieci. Użytkownik uprawniony do jednego wewnętrznego narzędzia dociera do tego narzędzia i niczego więcej. Nie ma ogólnego przyczółka w LAN, z którego można się poruszać.
• Tożsamość i urządzenie są sprawdzane przy każdym żądaniu, nie tylko przy głównych drzwiach. Kim jesteś i w jakim stanie jest urządzenie, którego używasz, jest oceniane w sposób ciągły, więc sesja, która zaczęła się czysto, może zostać ponownie oceniona.
• Aplikacje są ukryte przed każdym, kto nie ma do nich uprawnień. Przy VPN usługi wewnętrzne są często wykrywalne, gdy jesteś już w sieci. Przy ZTNA aplikacja, do której użytkownik nie ma prawa, w ogóle nie jest dla niego widoczna, żeby ją zaatakować.
• Domyślną zasadą jest odmowa. Nic nie jest osiągalne, chyba że polityka wyraźnie na to zezwala dla tej tożsamości, tego urządzenia i tej aplikacji.

Efekt na skradzione dane uwierzytelniające to najważniejsza część. Przy VPN skompromitowany login może dotrzeć do sieci i wszystkiego, co jest w niej słabo posegmentowane. Przy ZTNA ten sam skompromitowany login dociera tylko do konkretnych aplikacji, do których ta jedna tożsamość była uprawniona, i tylko dopóki urządzenie i sesja wciąż spełniają politykę. Szkoda z pojedynczego skradzionego loginu zostaje zamknięta w znacznie mniejszym obszarze. To właśnie ludzie mają na myśli, mówiąc o zawężaniu blast radius.

ZTNA jest zwykle dostarczane z chmury jako część szerszego pakietu nazywanego security service edge, SSE, który dokłada wokół niego filtrowanie ruchu webowego i kontrolę aplikacji chmurowych. Nie musisz kupować całego pakietu, żeby zacząć. Zamiennik dostępu zdalnego, ZTNA, to element, który bezpośrednio adresuje problem VPN.

Porównanie: VPN kontra zero trust network access

• Podstawowe założenie · Tradycyjny VPN: Zaufaj użytkownikowi, gdy jest już w sieci · Zero trust network access (ZTNA): Domyślnie nie ufaj nikomu, weryfikuj każde żądanie
• Do czego masz dostęp · Tradycyjny VPN: Do sieci albo jej szerokiego wycinka · Zero trust network access (ZTNA): Do konkretnych aplikacji, do których masz uprawnienia
• Kiedy sprawdzane jest zaufanie · Tradycyjny VPN: Głównie w momencie połączenia · Zero trust network access (ZTNA): Ciągle, przy każdym żądaniu i sesji
• Efekt skradzionych danych uwierzytelniających · Tradycyjny VPN: Zasięg w całej sieci, szeroki blast radius · Zero trust network access (ZTNA): Zasięg tylko do uprawnionych aplikacji, zawężony blast radius
• Sprawdzanie stanu urządzenia · Tradycyjny VPN: Często minimalne albo nieobecne · Zero trust network access (ZTNA): Wbudowane, stan urządzenia to warunek dostępu
• Czy aplikacje wewnętrzne są widoczne dla atakujących · Tradycyjny VPN: Często wykrywalne, gdy jesteś w sieci · Zero trust network access (ZTNA): Ukryte przed każdym, kto nie ma do nich uprawnień
• Dopasowanie do aplikacji chmurowych · Tradycyjny VPN: Słabe, zaprojektowane pod wewnętrzny LAN · Zero trust network access (ZTNA): Naturalne, dostęp jest per aplikacja, gdziekolwiek żyje
• Ruch boczny · Tradycyjny VPN: Stosunkowo łatwy w płaskich sieciach · Zero trust network access (ZTNA): Trudniejszy, brak ogólnego przyczółka sieciowego
• Model referencyjny · Tradycyjny VPN: Bezpieczeństwo obwodowe · Zero trust network access (ZTNA): NIST SP 800-207, architektura zero trust

Tabela pokazuje kompromis, ale można ją odczytać tak, jakby VPN był po prostu przestarzały. Sytuacja nie jest aż tak jednoznaczna. VPN wciąż jest rozsądnym narzędziem do wąskiego zadania, na przykład małego zespołu docierającego do jednego wewnętrznego środowiska, gdzie koszt i wysiłek pełnego wdrożenia ZTNA by się nie zwrócił. Argument za przejściem jest najsilniejszy tam, gdzie VPN daje szeroki dostęp wielu ludziom, gdzie stoją za nim wrażliwe systemy i gdzie skradziony login byłby kosztowny.

Jak zespoły faktycznie przechodzą z jednego na drugie

Odejście od VPN rzadko jest jednorazowym przełączeniem. Realistyczna ścieżka to aplikacja po aplikacji. Identyfikujesz systemy, które zabolałyby najbardziej po ujawnieniu, umieszczasz je jako pierwsze za dostępem per aplikacja, a resztę zostawiasz na VPN, dopóki do nich nie dojdziesz. To mniej zakłóca pracę i pozwala udowodnić model na małym zakresie, zanim się go rozszerzy.

Kilka rzeczy zwykle decyduje, czy przejście przebiega gładko. Wiedza, jakie aplikacje faktycznie macie i kto ma do której uprawnienia, liczy się bardziej niż wybrany produkt, bo ZTNA egzekwuje politykę, a nie da się napisać dobrej polityki dla systemów i uprawnień, których się nie zmapowało. Uwierzytelnianie wieloskładnikowe musi być na miejscu, bo tożsamość staje się tym, czemu ufasz, gdy przestajesz ufać sieci. A stan urządzenia, czyli reguły dotyczące tego, w jakim stanie musi być maszyna, żeby się połączyć, trzeba zdefiniować świadomie, a nie zostawić na ustawieniach domyślnych.

Nic z tego nie zdejmuje z ciebie podstaw. Zero trust zawęża to, do czego może dotrzeć skradziony login. Nie powstrzymuje samej kradzieży, więc uwierzytelnianie odporne na phishing, szybki offboarding osób odchodzących i ścisła kontrola nad tym, jakie tożsamości istnieją, wciąż mają swoją wagę. Model ogranicza szkody. Nie daje ci odporności na przyczynę.

Źródła

• NIST Special Publication 800-207, Zero Trust Architecture · https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf (definicja zero trust, brak domyślnego zaufania opartego na lokalizacji sieciowej)
• Beazley Security, Quarterly Threat Report: Third Quarter 2025 · https://beazley.security/insights/quarterly-threat-report-third-quarter-2025 (skompromitowane dane uwierzytelniające VPN jako wektor początkowego dostępu w 48% ataków ransomware w Q3 2025, wobec 38% w Q2)
• Infosecurity Magazine, Half of Ransomware Access Due to Hijacked VPN Credentials · https://www.infosecurity-magazine.com/news/half-ransomware-access-hijacked/ (wtórne doniesienia o danych Beazley i najaktywniejszych grupach ransomware celujących w VPN)
• SC Media, Q3 ransomware activity dominated by three groups, stolen VPN credential use · https://www.scworld.com/brief/q3-ransomware-activity-dominated-by-three-groups-stolen-vpn-credential-use (potwierdzające doniesienia o danych uwierzytelniających VPN i aktywnych grupach)