Zero‑trust w praktyce: czy klasyczny VPN ma jeszcze sens w nowoczesnych środowiskach chmurowych

Dlaczego klasyczny VPN zaczyna uwierać w świecie chmury

Jak działa tradycyjny VPN i skąd wziął się jego sukces

Klasyczny VPN powstał w czasach, gdy większość zasobów była w jednym miejscu: w serwerowni firmy, za firewallem. Model był prosty: zbudować bezpieczny „tunel” z laptopa pracownika do sieci firmowej, tak jakby siedział przy biurku w biurze. Resztą miał zająć się wewnętrzny firewall, ACL‑e i segmenty sieci.

Technicznie VPN zestawia szyfrowany kanał (IPsec, SSL/TLS) między klientem a bramą. Po nawiązaniu tunelu użytkownik dostaje adres IP z puli firmowej i widzi sieć korporacyjną jakby był lokalnie. W większości wdrożeń VPN daje dostęp:

• do całych podsieci (np. 10.0.0.0/16),
• do wszystkich serwerów w segmentach „korporacyjnych”,
• czasem również do innych lokalizacji połączonych site‑to‑site.

Ten model, oparty na zaufaniu do wnętrza sieci, długo działał całkiem dobrze. Użytkowników było relatywnie mało, pracowali głównie z biura, a zdalny dostęp był „dodatkiem” dla kilku handlowców i kadry zarządzającej. W takim świecie VPN był rozsądnym kompromisem.

Nowa rzeczywistość: praca zdalna, SaaS i multi‑cloud

W ciągu ostatniej dekady zmieniło się praktycznie wszystko. Zespoły pracują hybrydowo, wiele firm w ogóle nie ma „głównego biura”, a krytyczne aplikacje działają w chmurach publicznych i SaaS. Użytkownicy łączą się z:

• aplikacjami SaaS (Office 365, Google Workspace, CRM, systemy HR),
• środowiskami IaaS/PaaS (AWS, Azure, GCP),
• klastrami Kubernetes, serwerless, bazami zarządzanymi,
• nielicznymi już systemami on‑premises, które nie migrowały do chmury.

Co więcej, pracownicy korzystają z wielu urządzeń – służbowych i prywatnych, z różnych lokalizacji i sieci, często także z mobilnych łączy. Zaufanie do samej sieci (np. „jeśli ktoś jest w sieci firmowej, to jest OK”) przestaje mieć sens, bo użytkownik może być:

• w domu,
• w kawiarni,
• w sieci gościnnej klienta,
• na LTE lub 5G.

W takim środowisku klasyczny VPN staje się coraz większym obciążeniem: funkcjonalnym, wydajnościowym i – przede wszystkim – bezpieczeństwa.

Problem „grubego tunelu”: za dużo, za szeroko, za łatwo

Największą wadą klasycznego VPN jest jego „grubość”. Użytkownik, który potrzebuje jednej aplikacji, dostaje często dostęp do całej sieci lub dużej jej części. To trochę jak dać klucz do wszystkich drzwi biura osobie, która powinna wejść tylko do jednego pokoju konferencyjnego.

Z tego wynika kilka bardzo konkretnych problemów:

• zbyt szeroki dostęp – użytkownik widzi serwery i usługi, o których istnieniu w ogóle nie powinien wiedzieć,
• łatwy lateral movement – jeśli konto zostanie przejęte, atakujący może się „rozlać” po całym środowisku, skanując porty, szukając słabych punktów,
• trudna segmentacja – każda zmiana w topologii, segmentach sieci czy regułach wymaga żmudnej pracy, a polityki szybko stają się nieczytelne,
• zależność od IP – wiele rozwiązań bezpieczeństwa opiera się na adresie IP z VPN, co utrudnia finezyjną kontrolę na poziomie aplikacji.

Efekt? VPN staje się jedną wielką „wtyczką do środka” – zarówno dla pracowników, jak i partnerów. Im dłużej taki model żyje, tym bardziej złożona staje się jego administracja i tym trudniej przejść do nowocześniejszej architektury.

Prozaiczny przykład: wszyscy na tym samym VPN, choć każdy potrzebuje czego innego

W wielu firmach schemat wygląda identycznie: każdy pracownik ma tego samego klienta VPN, te same profile, te same zakresy adresów po drugiej stronie. Administratorzy zakładają, że „przecież i tak nie zna haseł do baz danych”, więc nic złego się nie stanie. Do czasu.

Wyobraź sobie sytuację: nowy stażysta w dziale marketingu dostaje dostęp VPN, bo musi wejść do jednego panelu CMS. Po zalogowaniu do VPN widzi całą sieć firmową: serwery plików, wewnętrzne systemy, hosty administracyjne. Nie ma teoretycznie uprawnień, ale może:

• skanować porty,
• łapać bannery usług (np. wersje serwerów),
• szukać źle skonfigurowanych serwisów www,
• podglądać zachowanie sieci, jeśli ma minimum technicznej ciekawości.

Sam stażysta może nic złego nie zrobić, ale jeśli jego konto zostanie przejęte (phishing, malware na laptopie), atakujący ma gotowy trampolinowy punkt wejścia. Z poziomu jednego „niewinnego” profilu VPN przenika głęboko w sieć.

Zero‑trust jako odpowiedź na „zamek z jednym kluczem”

Klasyczny VPN zakłada mniej więcej tyle: jeśli użytkownik uwierzytelni się poprawnie i wejdzie do sieci, jest „nasz”. To trochę jak zamek, który wpuszcza każdego, kto ma klucz – a potem może chodzić po całym budynku, bez dalszych kontroli.

Zero‑trust idzie w zupełnie inną stronę. Zamiast ufać, że „środek sieci” jest bezpieczny, zakłada, że atakujący może być wszędzie: w biurze, w domu użytkownika, w chmurze, a nawet w środku segmentu serwerów. Dlatego zamiast jednego dużego klucza, pojawia się tysiące drobnych decyzji: kto, z jakiego urządzenia, w jakim kontekście, do jakiego konkretnego zasobu ma dostęp – i to tylko na czas, gdy jest to potrzebne.

W tym świetle klasyczny VPN wygląda jak narzędzie z innej epoki: nadal użyteczne w wybranych scenariuszach, ale coraz mniej pasujące do krajobrazu chmury, pracy zdalnej i mikrosegmentacji.

Podstawy zero‑trust: o co tak naprawdę chodzi

Zasada „never trust, always verify” kontra zaufana sieć firmowa

Kluczowa myśl zero‑trust brzmi: nie ufaj domyślnie żadnemu elementowi infrastruktury – sieci, urządzeniu, lokalizacji, a nawet użytkownikowi. Zaufanie jest przyznawane na chwilę, w oparciu o kontekst, i ciągle weryfikowane. To odwrotność klasycznego modelu, w którym sieć firmowa była domyślnie zaufana, a VPN był biletem do środka.

W praktyce oznacza to kilka przełomowych zmian:

• adres IP przestaje być podstawą decyzji o dostępie,
• sieć jest traktowana jak nieufne medium transportowe (nawet sieć lokalna w biurze),
• każde żądanie dostępu jest rozpatrywane w kontekście: kto, z czego, do czego, w jakim stanie bezpieczeństwa.

Z perspektywy użytkownika może to wyglądać jak „więcej kontroli i MFA”, ale dobrze zaprojektowane zero‑trust potrafi być paradoksalnie wygodniejsze niż stary VPN: zamiast odpalać klienta VPN, wystarczy wejść w portal z aplikacjami, gdzie dostęp jest nadawany i odbierany automatycznie.

Trzy filary zero‑trust: tożsamość, kontekst i ciągła weryfikacja

Zero‑trust opiera się zwykle na trzech filarach, które muszą współgrać, by model miał sens.

Tożsamość jako nowy perymetr

Pierwszy filar to tożsamość. Kluczowe pytanie nie brzmi już „z jakiej sieci pochodzi ruch?”, ale „kto jest po drugiej stronie i jaką ma relację z organizacją?”. Chodzi nie tylko o pracowników etatowych, ale też:

• podwykonawców,
• partnerów biznesowych,
• kontenerowe workloady i serwisy maszynowe,
• kont użytkowników zewnętrznych (np. w portalach B2B).

Stąd rola systemów IAM i IdP (Identity Provider), takich jak Azure AD / Entra ID, Okta, Keycloak, Ping Identity i innych. To one stają się „bramkarzem”, który wystawia tokeny dostępu, integruje się z MFA, grupami, rolami, a często także z HR (cykl życia pracownika).

Kontekst: urządzenie, lokalizacja, ryzyko

Drugi filar to kontekst. Sama nazwa użytkownika i hasło to za mało. Liczy się też:

• stan urządzenia (czy jest zarządzane przez MDM, czy ma aktualne łatki, czy EDR nie zgłasza incydentów),
• lokalizacja i sieć (nietypowy kraj, TOR, domeny z czarnych list),
• czas i wzorce zachowania (logowanie o 3 w nocy z drugiego końca świata),
• poziom wrażliwości danego zasobu (CRM vs publiczny intranet).

Na tej podstawie system podejmuje decyzję: czy wpuszczać, czy wymusić dodatkowy krok (MFA, dopuszczenie tylko do części funkcji), czy w ogóle zablokować i wysłać alert.

Ciągła weryfikacja zamiast jednorazowego logowania

Trzeci filar to ciągła weryfikacja. W klasycznym modelu użytkownik loguje się raz (do VPN lub domeny) i ma „święty spokój” przez wiele godzin. W zero‑trust zaufanie jest krótkotrwałe:

• tokenu dostępu mają ograniczoną ważność,
• polityka może się zmieniać w czasie sesji (np. gdy EDR wykryje malware na urządzeniu),
• dostępy są przyznawane „just‑in‑time” do konkretnych akcji.

Jeżeli więc sytuacja się zmieni (nagle pojawia się logowanie z innego kraju lub urządzenie przechodzi w stan niezgodności), system może odciąć dostęp w trakcie pracy, a nie dopiero przy kolejnym logowaniu do VPN.

Zaufana sieć vs zaufane połączenie do konkretnego zasobu

Kluczowa różnica między starym a nowym podejściem sprowadza się do skali:

• w modelu perymetrowym zaufana jest cała sieć firmowa,
• w modelu zero‑trust zaufane jest konkretne połączenie użytkownika (lub serwisu) do konkretnego zasobu, w konkretnym momencie.

Zamiast „wpuść użytkownika do VLAN‑u X i Y”, myślimy raczej: „pozwól temu użytkownikowi, z tego urządzenia, w tym kontekście, wykonać takie a takie operacje na tej konkretnej aplikacji lub API”. Sieć jest jedynie narzędziem transportowym, a nie granicą bezpieczeństwa.

Zero‑trust w praktyce często oznacza „zamykanie” aplikacji za proxy lub brokerami, które:

• uwierzytelniają użytkownika względem IdP,
• wymuszają polityki bezpieczeństwa (MFA, stan urządzenia, lokalizacja),
• terminują ruch i przekazują go dalej do aplikacji dopiero po pozytywnej decyzji.

Ekosystem zero‑trust: z czego składa się cała układanka

Zero‑trust nie jest pojedynczym produktem. To raczej architektura, w której kilka kategorii narzędzi musi ze sobą współpracować:

• IdP / IAM – zarządzanie tożsamościami, SSO, MFA, grupy, role (Azure AD, Okta, itp.),
• MDM/EDR – kontrola stanu urządzeń końcowych (Intune, Jamf, CrowdStrike, SentinelOne),
• CASB / SSE – kontrola dostępu do aplikacji SaaS i ruchu webowego,
• ZTNA – Zero Trust Network Access, czyli dostęp do aplikacji prywatnych bez klasycznego VPN,
• SIEM/SOAR – centralne zbieranie logów, korelacja zdarzeń, automatyzacja reakcji.

Dopiero złożenie tych elementów daje spójny efekt: od logowania, przez decyzję o dostępie, po reakcję na incydent. Klasyczny VPN w tym świecie może być co najwyżej jednym z kanałów transportowych – a nie głównym mechanizmem kontroli.

Zmiana myślenia: od „kto jest w sieci” do „kto ma prawo w tej chwili”

Najtrudniejszy w zero‑trust nie jest sam produkt, ale zmiana sposobu myślenia. W wielu zespołach IT wciąż dominuje pytanie: „kto ma dostęp do sieci produkcyjnej?”. W architekturze zero‑trust znacznie ważniejsze staje się pytanie:
„kto, do czego i na jakiej podstawie ma dostęp w tej chwili, z tego konkretnego urządzenia?”

Zamiast listy sieci i VLAN‑ów pojawia się mapa relacji:

• rola użytkownika (np. developer backendu),
• konkretny zasób (np. API do mikroserwisu A w środowisku testowym),
• warunki dostępu (np. tylko z urządzeń zarządzanych, z MFA, poza godzinami nocnymi ograniczony dostęp).

Taka zmiana upraszcza życie w dłuższej perspektywie, bo polityki są bliżej języka biznesu i audytów. Trudniej jednak ją wdrożyć, jeśli całe bezpieczeństwo opiera się nadal na jednym grubym tunelu VPN.

VPN a zero‑trust: podobieństwa, różnice i obszary wspólne

Gdzie VPN udaje zero‑trust, a gdzie kończy mu się paliwo

Klasyczny VPN często bywa „podrasowany”, żeby wyglądał bardziej nowocześnie: dorzucamy MFA, integrujemy z katalogiem użytkowników, wprowadzamy split‑tunneling. Z zewnątrz zaczyna przypominać komponent zero‑trust, ale pod spodem mechanika pozostaje ta sama: po uwierzytelnieniu użytkownik dostaje szeroki dostęp sieciowy, który trudno precyzyjnie kontrolować.

Pewne elementy zbliżają VPN do świata zero‑trust:

• użycie silnego uwierzytelniania (MFA, klucze sprzętowe),
• integracja z IdP – logowanie tym samym kontem co do aplikacji SaaS,
• granulowane reguły firewall (np. różne grupy VPN o różnym zakresie adresów).

Jednak kluczowe różnice zostają:

• VPN myśli w kategoriach adresów IP i portów, zero‑trust w kategoriach tożsamości i aplikacji,
• w VPN dostęp jest zwykle ciągły (sesja trwa, dopóki jej nie zerwiemy), w zero‑trust – kontekstowy i krótkotrwały,
• w VPN trudniej jest wymusić warunki dostępu (stan urządzenia, ryzyko logowania) przy każdej transakcji.

Zdarza się, że organizacja dokłada kolejne warstwy wokół VPN (Network Access Control, skan stanu urządzenia, segmentacja), próbując „dokręcić” go do poziomu zero‑trust. Często jednak kończy się to złożoną, drogą w utrzymaniu układanką, która i tak przegrywa prostotą i elastycznością z natywnymi rozwiązaniami ZTNA.

VPN jako część układanki zero‑trust, a nie jej fundament

VPN nie musi być wyrzucony za burtę. W wielu organizacjach sensowne jest podejście: VPN zostaje, ale zmienia rolę. Zamiast centralnego mechanizmu decydującego o dostępie, staje się jednym z kilku kanałów transportowych, zarządzanych już z poziomu polityk zero‑trust.

Przykładowo:

• użytkownik loguje się do IdP, które wydaje token z odpowiednimi atrybutami,
• brama VPN korzysta z tych atrybutów (grupy, rola, poziom ryzyka) do przydzielenia konkretnego profilu dostępu,
• ruch i tak trafia następnie do reverse proxy, brokerów ZTNA lub WAF‑ów, które ponownie weryfikują uprawnienia do danej aplikacji.

Wtedy VPN nie jest już jedyną barierą między „światem zewnętrznym” a serwerami, ale raczej szyfrowanym kanałem do kilku wybranych stref technicznych – np. do zarządzania infrastrukturą, starszymi systemami czy narzędziami administratorskimi, które trudno inaczej „opiąć” kontrolą dostępu.

Główne podobieństwa: tunel, szyfrowanie i centralny punkt przejścia

Nie ma sensu udawać, że VPN i zero‑trust to dwa różne wszechświaty. Kilka cech mają wspólnych i dlatego ludzie często je mylą.

Po pierwsze, oba podejścia tworzą centralny punkt przejścia. W VPN jest to brama, w zero‑trust – zwykle broker lub zestaw proxy. W obu przypadkach tam właśnie egzekwujemy wiele decyzji o dostępie i tam lądują logi.

Po drugie, zarówno VPN, jak i wiele wdrożeń ZTNA zapewnia szyfrowany tunel przez sieci publiczne. Dla użytkownika efekt wizualny bywa podobny: jest klient, jest „połączenie” i nagle z domu widać zasoby firmy.

Po trzecie, oba modele opierają się na uwierzytelnieniu. Problem polega na tym, co dzieje się po uwierzytelnieniu. VPN zazwyczaj przestaje być wymagający – zero‑trust dopiero się rozkręca, bo wtedy zaczyna mikro‑decyzje o konkretnych połączeniach.

Nowoczesne środowiska chmurowe: co najbardziej psuje stary model VPN

Przejście do chmury nie psuje VPN jako technologii szyfrowania, ale mocno uderza w jego sens jako głównego narzędzia dostępowego. Chmurowe środowiska produkują kilka zjawisk, z którymi klasyczny VPN radzi sobie bardzo słabo.

Dynamiczna infrastruktura: adresy IP, które nie chcą stać w miejscu

Gdy serwery były „żelazne” i stały latami w tej samej szafie, statyczna lista adresów IP dostępnych przez VPN miała sens. W chmurze wygląda to zupełnie inaczej:

• maszyny są tworzone i kasowane automatycznie (autoscaling, ephemeral VMs),
• adresy IP zmieniają się przy każdym redeployu,
• aplikacje dzielą się na dziesiątki mikroserwisów, każdy z własnym życiem.

Utrzymanie sensownej, granularnej kontroli „po IP” wymagałoby ciągłej automatyzacji wokół VPN i firewalli. Tymczasem w architekturze zero‑trust łatwiej jest powiedzieć: „użytkownik X ma dostęp do aplikacji Y”, a szczegóły, gdzie dokładnie stoi aplikacja w danym momencie, obsługują warstwy automatyzacji i service discovery.

Wielochmurowość i hybryda: z ilu miejsc jeszcze trzeba będzie „wbić tunel”?

Coraz częściej organizacje mają środowiska:

• on‑premises,
• w co najmniej jednym hyperskalerze,
• w dodatkowej chmurze (np. dla DR lub konkretnych usług),
• u dostawców SaaS, którzy wystawiają własne API i panele.

Budowanie jednego centralnego VPN‑a, który ma „dogadać się” ze wszystkimi tymi światem, bywa koszmarem: trasy, BGP, połączenia site‑to‑site, NAT‑y, overlapping IP. A gdy dochodzi kolejny region lub nowy provider – całą układankę trzeba ostrożnie przebudowywać.

Zero‑trust w naturalny sposób zachęca do innego myślenia: zamiast jednego, globalnego tunelu, tworzymy punkty dostępu bliżej aplikacji, najczęściej w formie reverse‑proxy / brokerów podłączonych do IdP. Użytkownik nie musi „wchodzić do sieci projektu w Azure”, żeby użyć konkretnego narzędzia DevOps – widzi je po prostu jako kolejną aplikację w portalu SSO.

Praca zdalna i BYOD: urządzenia, których nie da się „wciągnąć do domeny”

Większość klasycznych wdrożeń VPN zakłada, że po drugiej stronie jest w miarę dobrze kontrolowany laptop firmowy, wpięty do domeny, z zainstalowanym klientem i politykami GPO. Świat BYOD i zewnętrznych kontraktorów brutalnie rozprawia się z tym założeniem.

Jeżeli:

• użytkownicy łączą się z prywatnych komputerów,
• pracują krótkoterminowi konsultanci, których nie chcemy wpuszczać do pełnej sieci,
• część pracy dzieje się z poziomu tabletów czy telefonów,

to model „pełnego tunelu VPN do sieci firmowej” robi się ryzykowny. Zero‑trust pozwala o wiele precyzyjniej podejść do tematu: na przykład dopuścić zewnętrznego konsultanta tylko do jednej konkretnej aplikacji webowej, z wymuszoną kontrolą copy‑paste, bez prawa pobierania plików, z logowaniem wszystkich akcji. Z klasycznym VPN‑em próba zrobienia tego kończy się karkołomnymi kombinacjami po stronie aplikacji i firewalli.

Ekspozycja usług przez Internet: od „VPN albo nic” do „bezpiecznego frontu”

Jeszcze dekadę temu typowe było założenie: „panel administracyjny jest bezpieczny, bo dostępny tylko z VPN”. Dzisiaj sami dostawcy chmurowi pokazują inną drogę: panele i API są widoczne w Internecie, ale chronione silnym uwierzytelnianiem, rolami, czasem dodatkowymi warstwami (privileged access, just‑in‑time).

To samo podejście można zastosować do własnych aplikacji prywatnych. Zamiast:

• zamykać wszystko za VPN‑em i liczyć, że nikt nie przejmie konta użytkownika z szerokim dostępem,

lepiej:

• wystawić aplikację przez broker ZTNA / reverse‑proxy,
• zabezpieczyć ją IdP, MFA, polityką warunkową,
• logować dokładnie, kto, skąd i do czego się dostaje.

VPN przestaje być wtedy jedyną metodą dotarcia do panelu admina – staje się co najwyżej dodatkowym kanałem dla osób, które z jakiegoś powodu nie mogą użyć standardowej ścieżki (np. dostęp awaryjny z serwerowni, praca offline przez zestawiony wcześniej tunel site‑to‑site itp.).

Kiedy klasyczny VPN nadal ma sens

Scenariusze administratorskie i dostęp do niskopoziomowej infrastruktury

Są obszary, gdzie klasyczny VPN wciąż sprawdza się bardzo dobrze. Typowym przykładem jest dostęp administratorów do infrastruktury na poziomie sieci: routery, firewalle, przełączniki, konsola hypervisora czy urządzenia out‑of‑band.

Te systemy często nie „umieją” w nowoczesne standardy uwierzytelniania aplikacyjnego (OIDC, SAML). Potrzebują dostępu do portu SSH, RDP lub interfejsu webowego na prywatnym IP. Tutaj VPN nadal bywa:

• relatywnie prosty do wdrożenia,
• łatwy do zintegrowania z istniejącą topologią sieciową,
• kompatybilny z narzędziami, które administratorzy już znają.

Nawet w takim scenariuszu warto jednak wprowadzić kilka „ukłonów” w stronę zero‑trust: silne MFA, ścisłe przypisanie zakresów IP do ról (np. osobne profile VPN dla sieci produkcyjnej i testowej), sesje krótkotrwałe i pełne logowanie ruchu.

Dostęp w trudnych warunkach sieciowych i scenariusze offline

VPN nadal bywa niezastąpiony tam, gdzie sieć jest niestabilna, a ruch musi być prosty i odporny na utratę łączności. Np. technicy terenowi podłączający się z maszyn przemysłowych, z łączy satelitarnych, z okrętów czy z odciętych geograficznie lokalizacji.

W takich miejscach nie zawsze uda się wdrożyć całe środowisko brokerów ZTNA, reverse‑proxy, integracji z IdP i pełnego SSO. Zestawienie stabilnego tunelu IPsec lub SSL VPN między dwoma punktami bywa wówczas najpraktyczniejszym rozwiązaniem – oczywiście przy założeniu, że zakres dostępu jest możliwie wąski, a nad ruchem czuwa porządna inspekcja i monitoring.

Integracja z systemami legacy, których nie da się przerobić

Nie wszystkie aplikacje doczekają do emerytury w blasku refaktoryzacji i nowego frontu webowego. Część systemów legacy:

• korzysta z własnych, starych protokołów,
• wymaga stałego połączenia sieciowego do serwera,
• nie ma sensownego sposobu na integrację z IdP i nowoczesnymi metodami logowania.

W takich miejscach VPN bywa „mostem” między światem starego a nowego: z jednej strony mamy użytkownika uwierzytelnionego nowocześnie (MFA, IdP), z drugiej – aplikację, która „widzi” tylko połączenie z zaufanego zakresu IP. To nie jest idealny model zero‑trust, ale często jedyny realny w danym roku budżetowym.

Proste połączenia site‑to‑site między sieciami prywatnymi

Kolejnym sensownym scenariuszem są VPN‑y site‑to‑site między prywatnymi sieciami: np. między data center a VPC w chmurze, albo między dwoma oddziałami firmy w różnych krajach. Dla ruchu maszyn‑do‑maszyn, przy dobrej segmentacji po obu stronach, takie tunele nadal są tanie i skuteczne.

Warunek: nie można traktować „po drugiej stronie tunelu” jako w pełni zaufanego świata. Segmentacja, kontrola ruchu między subnetami, a najlepiej także uwierzytelnianie warstwy aplikacyjnej – nadal są potrzebne, żeby pojedynczy błąd konfiguracyjny w jednym oddziale nie otworzył drogi do całej organizacji.

Organizacje o niskiej złożoności i prostym modelem pracy

Są wreszcie firmy, w których większość zespołu:

• pracuje z jednego kraju,
• używa głównie kilku systemów on‑premises,
• ma niewielką liczbę aplikacji w chmurze,
• raczej nie korzysta z BYOD, kontraktorów i globalnych partnerstw.

Dla nich klasyczny VPN, dobrze „dokręcony” (MFA, segmentacja, aktualizacje, monitoring), może być przez jakiś czas wystarczający. Inwestycja w pełne zero‑trust i ZTNA będzie miała sens dopiero, gdy pojawi się więcej chmury, złożoności i różnorodności urządzeń. Tu również da się jednak stopniowo wprowadzać elementy nowego podejścia, zamiast czekać na moment wielkiej rewolucji.

Kiedy VPN szkodzi: typowe anty‑wzorce w nowoczesnej infrastrukturze

„Jeden gruby tunel do wszystkiego”

Najbardziej klasyczny błąd to pojedynczy profil VPN, który:

• przydziela wszystkim użytkownikom ten sam zakres IP,
• pozwala na ruch praktycznie do wszystkich sieci wewnętrznych,
• jest zabezpieczony tylko hasłem (w lepszej wersji także MFA).

Brak segmentacji po stronie klienta i sieci wewnętrznej

Drugi klasyczny anty‑wzorzec to VPN „wpinający” użytkownika w środek płaskiej sieci. Po zestawieniu tunelu laptop widzi:

• serwery plików,
• panele administracyjne,
• bazy danych,
• sieci deweloperskie i produkcyjne,
• drukarki, skanery, czasem nawet kamery czy sterowniki HVAC.

Efekt? Każde przejęte konto VPN (albo zainfekowany laptop) staje się wehikułem do „wycieczki” po całym środowisku. Tymczasem zero‑trust podpowiada coś innego: użytkownik nie musi widzieć całej sieci, żeby zrobić swoją pracę, często potrzebuje dostępu tylko do kilku konkretnych usług.

Zamiast więc jednego, płaskiego segmentu przypiętego do profilu VPN, lepiej:

• podzielić sieć na strefy (np. biurowa, produkcyjna, administracyjna, OT),
• zdefiniować osobne profile VPN z jasnym zakresem tras dla każdej roli,
• ograniczyć ruch lateralny między hostami po stronie VPN (np. blokada ruchu „VPN‑klient do VPN‑klient”).

W praktyce często wystarczy, że klient VPN „widzi” tylko:

• adres brokera jump‑host / bastionu SSH,
• kilka usług niezbędnych do pracy (np. repozytorium kodu, system zgłoszeniowy),
• narzędzia bezpieczeństwa (proxy, EDR, system aktualizacji).

Reszta powinna być osiągalna już z wewnętrznych stref, po dodatkowym uwierzytelnieniu i kontroli, a nie bezpośrednio z domowego Wi‑Fi użytkownika.

Split‑tunneling „na pałę”

Split‑tunneling sam w sobie nie jest zły. Problem zaczyna się, gdy:

• cały ruch do Internetu leci poza VPN,
• jednocześnie klient ma pełny dostęp do sieci wewnętrznej,
• na stacji roboczej nie ma solidnej ochrony (EDR, filtracja DNS, kontrola aplikacji).

Takie ustawienie bywa wygodne dla użytkowników i oszczędza łącze w centrali, ale z perspektywy bezpieczeństwa przypomina wpuszczenie do serwerowni kogoś wprost z ulicy, w zabłoconych butach. Malware pobrane z Internetu może od razu próbować infekować zasoby wewnętrzne.

Jeżeli split‑tunnel ma zostać, przyda się kilka zabezpieczeń:

• silny agent bezpieczeństwa na endpointach (EDR + hardening),
• centralnie wymuszany DNS/SWG dla ruchu internetowego (np. przez agentowy proxy),
• ograniczenie zakresu tras VPN tylko do faktycznie potrzebnych podsieci.

Z perspektywy zero‑trust lepszym kierunkiem jest stopniowe przechodzenie na model, w którym ruch do aplikacji biznesowych i tak idzie przez warstwę pośrednią (broker ZTNA, reverse‑proxy z polityką dostępu), a tunel IP widzi jak najmniej.

VPN jako „protezowa” autoryzacja aplikacji

Częsty anty‑wzorzec: aplikacja nie ma własnego, sensownego modelu autoryzacji, więc rolę „bramki” pełni VPN. Dopóki ktoś ma dostęp do profilu VPN, aplikacja ufa mu bez dodatkowych pytań. W skrócie: „jak jesteś w sieci, to znaczy, że możesz”.

W takim modelu każda kompromitacja konta VPN (lub konta domenowego używanego do logowania) automatycznie otwiera dostęp do wielu usług. Trudno też zapanować nad zasadą minimalnych uprawnień – „odcięcie” konkretnej aplikacji wymaga dłubania w firewallu, a nie w konfiguracji samej aplikacji czy IdP.

Bezpieczniej jest, gdy:

• VPN odpowiada głównie za bezpieczny transport (szyfrowanie, ochrona przed podsłuchem),
• a o tym „kto do czego może” decyduje warstwa aplikacyjna i IdP (role, atrybuty, grupy, kontekst ryzyka),
• aplikacje nie ufają samemu faktowi bycia w określonej podsieci IP.

Przykład z życia: firma, która przestawiła wewnętrzny system HR z „dostępny tylko z VPN + login/hasło w bazie” na „dostępny przez broker ZTNA + SSO + role z Azure AD”. VPN przestał być krytycznym elementem kontroli, a jedynie dodatkiem dla kilku scenariuszy administratorskich.

Brak widoczności i logowania sesji VPN

Zaskakująco wiele organizacji traktuje logi VPN jako „coś, co się gdzieś tam zapisuje”, ale nikt tego realnie nie używa. Dopóki nie wydarzy się incydent, nikt nie umie odpowiedzieć na proste pytania:

• kto był zalogowany przez VPN w momencie ataku,
• z jakich krajów łączą się użytkownicy,
• które konta logują się o dziwnych porach,
• ile jest nieudanych prób logowania i z jakich adresów.

To kolejny punkt zderzenia klasycznego podejścia z zero‑trust. Skoro w zero‑trust zaufanie jest dynamiczne, dane o sesjach muszą być na wyciągnięcie ręki. Brak spójnej telemetrii z VPN (połączonej z IdP, EDR, SIEM) sprawia, że tunel staje się ślepym punktem infrastruktury.

Dobrą praktyką jest:

• wysyłanie logów VPN do centralnego SIEM / data lake,
• korelacja sesji VPN z tożsamością z IdP (nawet jeśli logowanie do VPN odbywa się osobno),
• definiowanie alertów behawioralnych (np. równoczesne logowanie tego samego konta z dwóch odległych geograficznie lokalizacji).

Z czasem te dane mogą posłużyć nie tylko do reagowania na incydenty, ale też do oceny, które grupy użytkowników nadal realnie potrzebują klasycznego VPN‑a, a które można przełączyć na rozwiązania zero‑trust.

„Tymczasowe” wyjątki, które zostają na zawsze

Każda większa organizacja zna taki scenariusz: na szybko dopuszczono dodatkową trasę w VPN, ustawiono regułę „allow any” dla konkretnej grupy albo utworzono profil „dla kontrahenta na tydzień”. Tydzień zamienił się w miesiąc, potem w rok, ludzie się pozmieniali – a szeroki dostęp pozostał.

Klasyczny VPN, szczególnie w modelu scentralizowanym, sprzyja takim „tymczasowym” obejściom. Przy dużej liczbie wyjątków i zmian reguły stają się nieczytelne, a każda próba porządków wywołuje lęk: „a jeśli coś komuś przestanie działać?”.

Podejście zero‑trust sugeruje inną strategię:

• profil VPN (albo reguła dostępu) zawsze powiązany z konkretną grupą w IdP,
• czasowo ograniczone członkostwo w grupach (np. access reviews, just‑in‑time),
• okresowe przeglądy wszystkich tras i zakresów dostępnych przez VPN, z udziałem właścicieli systemów.

W praktyce dobrze sprawdzają się proste mechanizmy „wygaszania” wyjątków – np. jeśli nikt z danej grupy nie korzystał z profilu VPN przez 90 dni, reguła jest automatycznie odznaczana i wymaga jawnego odtworzenia przez właściciela usługi.

Rozjechane polityki między VPN, IdP i resztą świata

Jeszcze jeden anty‑wzorzec to całkowite oderwanie polityk VPN od reszty ekosystemu tożsamości. Inne grupy w IdP, inne w AD, jeszcze inne w samym urządzeniu VPN. Każda zmiana w strukturze organizacyjnej wymaga ręcznej synchronizacji w trzech miejscach.

W takim układzie nie da się spójnie egzekwować podstawowych zasad zero‑trust, np.:

• „wszyscy administratorzy logują się tylko z zarządzanych urządzeń” – bo VPN tego nie wie,
• „konto z podwyższonymi rolami wymaga silniejszego MFA” – ale profil VPN ma MFA globalne dla wszystkich,
• „kontraktorzy nie mogą widzieć sieci produkcyjnej” – a w VPN nadal mają profil „pracownik”.

Kierunek docelowy jest prosty: VPN powinien być klientem IdP, a nie osobną wyspą. Czyli:

• identyfikacja użytkownika przez IdP (OIDC/SAML/RADIUS z atrybutami),
• mapowanie grup/claimów z IdP na konkretne profile i trasy w VPN,
• spójne wymuszanie polityk warunkowych (np. blokada logowania, gdy IdP oznaczy konto jako ryzykowne).

Dzięki temu VPN staje się jednym z wielu kanałów dostępu, a nie równoległym, trudnym do ogarnięcia światem uprawnień.

ZTNA i inne alternatywy dla klasycznego VPN

Zero‑Trust Network Access – główne założenia

ZTNA można traktować jako „VPN odwrócony do góry nogami”. Zamiast:

• wpuszczać użytkownika do sieci i liczyć, że resztę załatwi segmentacja,

lepiej:

• udostępnić mu tylko konkretną aplikację lub usługę,
• zweryfikować tożsamość, stan urządzenia i kontekst (lokalizacja, ryzyko),
• zbudować połączenie punkt‑punkt, niewidoczne dla reszty Internetu.

Typowe wdrożenie ZTNA składa się z trzech elementów:

• connectora/brokera blisko aplikacji (w sieci prywatnej lub VPC),
• usługi pośredniczącej (chmurowej lub on‑prem), która spina użytkownika z brokerem,
• klienta lub przeglądarki po stronie użytkownika, zintegrowanych z IdP.

Z zewnątrz aplikacja często nawet nie ma publicznego adresu IP – dostęp do niej uzyskuje wyłącznie ruch przechodzący przez platformę ZTNA. To mocno utrudnia skanowanie i masowe ataki typu „szukamy otwartego RDP/SSH gdziekolwiek w Internecie”.

Modele ZTNA: agentowy i bezagentowy

Na rynku widać dwa główne podejścia do ZTNA.

Pierwsze to model agentowy. Na urządzeniu użytkownika działa lekki klient, który:

• integruje się z IdP,
• ocenia stan urządzenia (np. wersję systemu, obecność EDR, szyfrowanie dysku),
• buduje zaszyfrowane połączenie do chmurowego brokera, a ten dopiero do aplikacji.

Taki agent daje precyzyjną kontrolę nad ruchem, może też wymuszać polityki lokalne (np. blokada dostępu z niezabezpieczonego Wi‑Fi). Minusem bywa konieczność instalacji oprogramowania, co nie zawsze jest realne w świecie BYOD.

Drugie podejście to model bezagentowy, przeglądarkowy. Użytkownik otwiera stronę portalu aplikacji, loguje się przez IdP, po czym:

• otrzymuje listę dozwolonych aplikacji,
• każda z nich działa przez reverse‑proxy (często z dodatkowymi funkcjami: DLP, kontrola sesji, blokada downloadów).

Tu ograniczeniem jest rodzaj ruchu – świetnie sprawdza się dla aplikacji webowych i paneli admina, ale gorzej dla „grubych” klientów wymagających specyficznych protokołów czy portów.

Zalety ZTNA w porównaniu z klasycznym VPN

W wielu nowoczesnych środowiskach ZTNA wygrywa z klasycznym VPN‑em w kilku kluczowych obszarach.

Po pierwsze, zasięg widoczności: użytkownik widzi tylko te aplikacje, do których ma dostęp. Nie „odkrywa” reszty sieci, nie może skanować hostów, nawet jeśli ma złe intencje.

Po drugie, kontrola kontekstu. Decyzja „wpuścić/nie wpuścić” może brać pod uwagę:

• stan urządzenia (compliance, EDR, szyfrowanie),
• ryzyko logowania (kraj, IP, nietypowa pora),
• rodzaj docelowej aplikacji (np. bardziej restrykcyjne zasady dla systemu finansowego).

Po trzecie, granularność uprawnień. Łatwiej zbudować dostęp typu:

• „konsultant X może wejść tylko do tej jednej aplikacji przez 30 dni”

niż odcinać/ przycinać całe zakresy sieci w firewallu i profilach VPN.

Na koniec dochodzi obniżenie powierzchni ataku. Aplikacje nie są wystawione bezpośrednio do Internetu, nie ma otwartych portów RDP/SSH, a nawet jeśli ktoś zna URL, bez poprawnej sesji ZTNA niczego nie zobaczy.

Ograniczenia i wyzwania ZTNA

ZTNA nie jest srebrną kulą. Ma swoje słabsze strony, o których lepiej pamiętać przed wdrożeniem.

Najczęstsze wyzwania to:

• aplikacje nie‑webowe – systemy korzystające z własnych protokołów, tunelowanie RDP/SSH, narzędzia inżynierskie; część rozwiązań ZTNA to wspiera, ale bywa to bardziej złożone niż zwykły VPN,

Najczęściej zadawane pytania (FAQ)

Czy klasyczny VPN jest jeszcze potrzebny, jeśli przechodzę na zero‑trust?

W wielu firmach klasyczny VPN wciąż będzie potrzebny, ale w znacznie mniejszym zakresie niż kiedyś. Sprawdza się głównie tam, gdzie musisz dać dostęp do całych segmentów sieci on‑premises (np. starsze systemy, które nie obsługują nowoczesnych metod uwierzytelniania czy publikacji aplikacji).

W modelu zero‑trust VPN nie jest już „główną bramą do wszystkiego”, ale jednym z kanałów dostępu – często przejściowym. Docelowo większość ruchu do aplikacji biznesowych idzie przez rozwiązania typu ZTNA/SDP, proxy aplikacyjne lub bezpośrednio przez Internet z silnym uwierzytelnianiem i kontrolą kontekstu.

Na czym polega różnica między klasycznym VPN a podejściem zero‑trust?

VPN daje dostęp przede wszystkim do sieci: po zalogowaniu widzisz podsieci, serwery, adresy IP. Logika jest prosta: „jak już jesteś w środku, to domyślnie ci ufamy”. Zero‑trust odwraca ten paradygmat – nie interesuje go, w jakiej jesteś sieci, tylko kim jesteś, z jakiego urządzenia korzystasz i do jakiej konkretnej aplikacji chcesz wejść.

W praktyce oznacza to, że w zero‑trust użytkownik nie dostaje „rury” do całej sieci, tylko ściśle ograniczony dostęp do określonych usług. Nawet będąc „w środku”, nadal musi przejść kontrolę tożsamości i kontekstu przy każdym istotnym żądaniu.

Dlaczego klasyczny VPN jest uznawany za mniej bezpieczny w środowiskach chmurowych?

Główny problem to tzw. „gruby tunel”: jeden profil VPN często otwiera użytkownikowi dostęp do całych podsieci, których wcale nie potrzebuje. W efekcie konto przejęte przez atakującego staje się idealnym punktem startu do skanowania sieci, szukania słabych punktów i lateral movement.

W chmurze i modelu hybrydowym dochodzi jeszcze złożoność – te same tunelowane zakresy IP są widoczne z różnych lokalizacji i środowisk (on‑premises, kilka chmur, SaaS zintegrowane po IP). Utrzymanie spójnych, drobiazgowych polityk bezpieczeństwa w takim układzie jest trudne i podatne na błędy.

Kiedy klasyczny VPN nadal ma sens, a kiedy lepiej przejść na ZTNA/zero‑trust?

VPN ma sens, gdy:

• masz sporo systemów on‑premises, które nie obsługują nowoczesnych metod publikacji (np. stare aplikacje klienckie, protokoły własne),
• musisz zapewnić dostęp do całych sieci np. administratorom infrastruktury,
• masz ograniczone zasoby, a liczba użytkowników zdalnych jest niewielka i przewidywalna.

Rozwiązania zero‑trust/ZTNA są lepsze, gdy pracownicy korzystają z wielu aplikacji SaaS, kilku chmur, pracują hybrydowo i często z urządzeń mobilnych. Wtedy bardziej opłaca się „dowozić” dostęp do aplikacji niż do sieci, z silnym naciskiem na tożsamość, MFA i stan urządzenia.

Jak zacząć przechodzenie z klasycznego VPN na architekturę zero‑trust?

Dobry start to inwentaryzacja: jakie aplikacje masz, gdzie działają (on‑prem, chmura, SaaS), kto z nich korzysta i w jaki sposób się łączy. Zazwyczaj najszybciej „odcina się” od VPN aplikacje webowe i SaaS, publikując je przez portal dostępu zintegrowany z IdP (Azure AD/Entra, Okta itd.) i MFA.

Kolejny krok to wprowadzenie polityk dostępu opartych na tożsamości i kontekście urządzenia. Część systemów – zwłaszcza starszych – może przez jakiś czas dalej działać za VPN, ale już z dużo ciaśniejszymi regułami (np. osobne profile dla adminów, podwykonawców, konkretnych zespołów).

Czy zero‑trust zastępuje szyfrowanie ruchu, które daje VPN?

Nie, zero‑trust nie znosi potrzeby szyfrowania – raczej zmienia miejsce, w którym się ono odbywa. Zamiast jednego dużego tunelu IPsec/SSL do sieci firmowej, masz wiele „mniejszych” kanałów: HTTPS/TLS do konkretnych aplikacji, tunele agentów ZTNA, szyfrowane połączenia między usługami.

Szyfrowanie nadal jest podstawą, ale przestaje być jedyną linią obrony. Dochodzą do niego: silne uwierzytelnianie, ciągła ocena ryzyka, mikrosegmentacja i zasada „minimalnych uprawnień” wdrożona na poziomie aplikacji, a nie tylko adresów IP.

Czy zero‑trust jest wygodniejsze dla użytkownika niż VPN?

Dobrze wdrożone zero‑trust może być wręcz wygodniejsze. Zamiast odpalać klienta VPN, czekać, aż tunel się zestawi, i dopiero wtedy szukać aplikacji, użytkownik ma portal lub launcher z listą swoich usług. Klik i jest w środku – a resztą (MFA, sprawdzenie urządzenia, routing) zajmuje się platforma.

Problem pojawia się wtedy, gdy polityki są zbyt agresywne lub chaotyczne: zbyt częste MFA, różne zasady dla podobnych aplikacji, brak jasnych komunikatów. Dlatego technologia to jedno, a projekt doświadczenia użytkownika i sensowne reguły dostępu – drugie, równie ważne zadanie.

Najważniejsze punkty

• Klasyczny VPN powstał z myślą o scentralizowanej infrastrukturze w serwerowni i dobrze sprawdzał się, gdy zdalny dostęp był wyjątkiem, a nie standardem pracy.
• W świecie pracy hybrydowej, SaaS i multi‑cloud użytkownicy łączą się z wieloma, rozproszonymi zasobami z dowolnych sieci i urządzeń, więc zaufanie „bo ktoś jest w sieci firmowej” przestaje mieć sens.
• „Gruby tunel” VPN daje zbyt szeroki dostęp – użytkownik potrzebujący jednej aplikacji często widzi całą sieć, co zwiększa powierzchnię ataku i ułatwia lateral movement po przejęciu konta.
• Utrzymanie bezpiecznej segmentacji przy klasycznym VPN jest trudne i pracochłonne; polityki oparte na adresach IP szybko się komplikują i nie nadążają za zmianami w architekturze.
• Jednolity profil VPN dla wszystkich (stażysta, administrator, marketing) powoduje, że nawet „niewinne” konto może stać się świetnym punktem startowym dla atakującego po udanym phishingu czy infekcji.
• Zero‑trust odwraca logikę klasycznego VPN: zamiast jednego dużego zaufania do sieci wprowadza drobnoziarniste decyzje – kto, z jakiego urządzenia, w jakim kontekście i tylko do konkretnego zasobu ma dostęp.
• W nowoczesnych środowiskach chmurowych tradycyjny VPN zaczyna przypominać stary zamek z jednym kluczem – nadal może się przydać w niszowych scenariuszach, ale nie pasuje do modelu opartego na mikrosegmentacji i ciągłej weryfikacji.

Bibliografia

• Zero Trust Architecture. National Institute of Standards and Technology (NIST) (2020) – Podstawowy dokument definiujący architekturę zero‑trust (SP 800‑207).
• Guide to IPsec VPNs. National Institute of Standards and Technology (NIST) (2005) – Szczegółowy opis działania i bezpieczeństwa IPsec VPN (SP 800‑77).
• Zero Trust Security: An Enterprise Guide. O’Reilly Media (2021) – Praktyczne wprowadzenie do wdrażania zero‑trust w organizacjach.
• Zero Trust Architecture Design Principles. Cybersecurity and Infrastructure Security Agency (CISA) (2021) – Zalecenia projektowe zero‑trust dla środowisk chmurowych i hybrydowych.
• NIS 2 Directive – Cybersecurity Requirements. European Union (2022) – Wymogi bezpieczeństwa sieci i systemów, istotne dla dostępu zdalnego i VPN.
• Security Guidance for Critical Areas of Focus in Cloud Computing v4.0. Cloud Security Alliance (2017) – Najlepsze praktyki bezpieczeństwa w chmurze, w tym dostęp zdalny i tożsamość.
• Microsoft Zero Trust Adoption Report. Microsoft (2021) – Opis trendów przejścia z klasycznego VPN do modeli zero‑trust w firmach.
• BeyondCorp: A New Approach to Enterprise Security. Google (2014) – Model dostępu bez VPN, oparty na tożsamości i kontekście urządzenia.