Klasyczny VPN projektowano w czasach, gdy firmowa sieć była jak zamek otoczony murem. W środku: serwery, aplikacje, pliki. Na zewnątrz: pracownicy w delegacji, zdalne oddziały, podwykonawcy. VPN miał po prostu „przedłużyć” ten mur do zdalnej lokalizacji, tworząc szyfrowany tunel przez Internet.
Model działania był prosty: użytkownik uruchamia klienta VPN, uwierzytelnia się, a jego laptop dostaje dostęp do firmowej sieci tak, jakby był podłączony w biurze. Ruch jest szyfrowany, a administratorzy czują się względnie spokojni: „pracuje jak w biurze, więc jest w porządku”.
W praktyce oznacza to, że VPN traktuje sieć firmową jako zaufaną całość. Jeśli tylko użytkownik przeszedł wstępne uwierzytelnienie, to sieć „wpuszcza go do środka” – często do całej podsieci, a bywa, że do wielu podsieci. Taki model był akceptowalny, kiedy większość zasobów była zamknięta wewnątrz i rzadko się zmieniała.
Zmiana świata: chmura, SaaS i praca z każdego miejsca
Dziś firmowe zasoby nie siedzą już grzecznie za jednym murem. Aplikacje w chmurze publicznej, systemy typu SaaS (CRM, HR, helpdesk), mikrousługi rozsiane po kilku regionach, do tego pracownicy podłączający się z domu, z pociągu, z telefonu, z prywatnego laptopa. Pojawia się BYOD, partnerzy, freelancerzy, integracje z zewnętrznymi API.
W takim świecie „wewnątrz” i „na zewnątrz” przestają mieć klarowną granicę. Pracownik może w tej samej minucie korzystać z aplikacji w AWS, systemu HR w SaaS, a potem logować się przez VPN do jakiegoś starego systemu on-prem. Sieć firmowa staje się zlepkiem wielu stref i dostawców, a klasyczny VPN nadal próbuje udawać, że jest jednym tunelem do jednego, bezpiecznego miejsca.
Do tego dochodzi skala i dynamika. Zespoły DevOps stawiają i usuwają usługi w ciągu godzin, nie miesięcy. Nowi pracownicy pojawiają się i znikają, role się zmieniają, rośnie liczba integracji między systemami. VPN, zaprojektowany jako gruby korytarz do w miarę statycznej sieci, po prostu nie nadąża za takim tempem zmian.
Typowe problemy klasycznego VPN: „wszystko albo nic”
Największa wada tradycyjnego VPN to zbyt szeroki dostęp. Użytkownik po połączeniu często widzi całą podsieć, a nawet kilka. Nawet jeśli większość serwerów ma dodatkowe uwierzytelnianie, sam fakt widoczności hostów i portów daje atakującemu ogromną przewagę, jeśli przejmie takie konto lub urządzenie.
Pojawiająją się konkretne problemy:
Brak precyzyjnej segmentacji – użytkownik potrzebuje tylko aplikacji HR, ale widzi też serwery finansowe, bazy danych i systemy developerskie.
Trudny audyt – logi z VPN mówią głównie „użytkownik X połączył się do sieci”, ale już niekoniecznie „do jakiej aplikacji dokładnie, jaki zasób odczytał”.
Uproszczone założenia zaufania – jeśli ktoś ma konto VPN i hasło, często zyska realnie większy dostęp niż potrzebuje do swojej roli.
Problemy z integracją chmurową – klasyczne VPN-y radzą sobie słabo z zasobami rozproszonymi między on-prem a kilkoma chmurami.
Administracja takim rozwiązaniem staje się koszmarem: rosną listy firewalli, statyczne trasy, wyjątki, reguły. Każda zmiana działu, migracja systemu czy nowe biuro oznaczają kolejne modyfikacje konfiguracji. To nie tylko spowalnia biznes, ale też generuje błędy – a błąd w regule dostępu to często realna luka w bezpieczeństwie.
Historia z życia: jeden laptop, cała sieć
Wyobraźmy sobie małą firmę usługową z kilkoma serwerami on-prem i kilkunastoma pracownikami zdalnymi. Używają klasycznego VPN: po zalogowaniu pracownik widzi całą sieć biurową, bo „tak jest prościej skonfigurować”. Jeden z pracowników korzysta z prywatnego laptopa z przestarzałym systemem i bez aktualnego antywirusa.
Pewnego dnia klika w załącznik w mailu prywatnym. Złośliwe oprogramowanie pozostaje w ukryciu, czekając, aż użytkownik połączy się z VPN. Gdy tylko tunel jest aktywny, malware zaczyna skanować całą sieć wewnętrzną, szuka otwartych portów, słabych haseł, niezałatanych serwerów. Z punktu widzenia infrastruktury wszystko wygląda „normalnie”: ruch przychodzi z zaufanego adresu wirtualnej sieci VPN.
Efekt: atakujący zyskuje cichy dostęp do wielu systemów, bo jeden laptop został potraktowany jak pełnoprawny element „zaufanej sieci”. W modelu Zero Trust ten scenariusz wygląda zupełnie inaczej – zaufanie do samej sieci nie istnieje, a każdy dostęp jest ściśle limitowany i sprawdzany.
Fundamenty Zero Trust: od „ufaj, ale sprawdzaj” do „nie ufaj nikomu”
Nowa filozofia: brak domyślnego zaufania
Zero Trust odwraca tradycyjne myślenie o bezpieczeństwie sieciowym. Zamiast „wewnątrz jest zaufanie, na zewnątrz nie”, wprowadza prostą zasadę: nie ufaj nikomu i niczemu domyślnie. Ani użytkownikowi w biurze, ani serwerowi w tej samej podsieci, ani nawet własnym aplikacjom, dopóki nie udowodnią, kim są i że ich zachowanie jest zgodne z oczekiwaniami.
Brzmi brutalnie, ale ten realizm wynika z doświadczeń. Ataki wewnętrzne, przejęte konta, malware rozprzestrzeniający się w sieci lokalnej – to wszystko pokazuje, że sama przynależność do „wewnętrznej sieci” nie jest żadną gwarancją uczciwości czy bezpieczeństwa. Zero Trust mówi wprost: sieć traktujemy jak potencjalnie wrogie środowisko, podobnie jak Internet.
W praktyce oznacza to, że każdy dostęp – do aplikacji, API, pliku – wymaga uwierzytelnienia, autoryzacji i często dodatkowych sprawdzeń kontekstu. Zaufanie jest granularne, przyznawane tylko na czas konkretnej operacji i wąskiego zakresu zasobów, zamiast raz na całe połączenie VPN.
Trzy filary Zero Trust: tożsamość, kontekst, ciągła weryfikacja
Model Zero Trust zwykle opiera się na trzech filarach, które warto przekładać na konkretne decyzje techniczne, a nie traktować jako ogólne hasła.
Tożsamość – kluczowe staje się precyzyjne określenie, kto lub co próbuje uzyskać dostęp. Nie chodzi tylko o użytkownika (login/hasło), ale też:
tożsamość urządzenia (certyfikat, zapis w MDM, fingerprint systemu),
tożsamość aplikacji lub usługi (service account, certyfikat mTLS),
tożsamość roli (np. „konsultant HR”, „admin systemowy”).
Kontekst – sama tożsamość to za mało. Liczy się również jak, skąd i w jakich warunkach odbywa się dostęp: czy urządzenie jest aktualne, z jakiego kraju przychodzi ruch, jaka jest pora dnia, czy zachowanie odbiega od normy. Ten kontekst staje się elementem polityk dostępowych.
Ciągła weryfikacja – Zero Trust nie zakłada, że jednorazowe logowanie raz na dzień wystarczy. Autoryzacja może być odnawiana przy każdej próbie dostępu do ważniejszego zasobu, a zmiana kontekstu (np. nowe IP, zmiana lokalizacji, podejrzana aktywność) może automatycznie zaostrzyć wymagania lub odciąć sesję.
Zasada najmniejszych uprawnień i mikrosegmentacja w praktyce
Jednym z praktycznych przejawów Zero Trust jest zasada najmniejszych uprawnień (least privilege). Użytkownik lub usługa dostają tylko taki zakres dostępu, jaki jest absolutnie niezbędny do wykonania pracy – ani trochę więcej. W połączeniu z mikrosegmentacją oznacza to dzielenie infrastruktury na małe, logiczne wycinki, zamiast jednej dużej, „płaskiej” sieci.
Przykład: pracownik działu HR potrzebuje dostępu do aplikacji kadrowej. W klasycznym VPN po połączeniu widzi całą podsieć aplikacyjną, w której oprócz systemu HR są też systemy finansowe i raportowe. W modelu Zero Trust pracownik:
uwierzytelnia się przez SSO z MFA,
otrzymuje token lub kontekst sesji, który pozwala na dostęp wyłącznie do konkretnego URL / hosta systemu HR,
nie ma możliwości skanowania sieci ani komunikacji z innymi serwerami, bo reszta jest dla niego po prostu „niewidzialna”.
Jeśli kiedyś jego urządzenie zostanie skompromitowane, atakujący zobaczy jedynie minimalny wycinek środowiska – jedną aplikację lub wręcz tylko wybrane funkcje w tej aplikacji, jeśli polityki RBAC/ABAC są właściwie skonfigurowane.
Bezpieczeństwo „od aplikacji w górę”, nie „od sieci w dół”
Tradycyjny świat sieciowy myślał od dołu: mamy kable, VLAN-y, routery, firewalle, a na końcu aplikacje. Bezpieczeństwo budowano głównie na poziomie sieci: kto może wejść do danej podsieci, z jakiego IP, na jaki port. Domeną działu IT były adresy, maski i ACL-e.
Zero Trust przesuwa środek ciężkości wyżej: to aplikacje, dane i tożsamości są punktem wyjścia. Zadaje się pytanie: kto powinien mieć dostęp do tego konkretnego API lub tabeli w bazie, a dopiero później planuje się, jak ten dostęp zrealizować sieciowo. Warstwa sieciowa staje się jednym z „transportów”, a nie miejscem, gdzie podejmowane są najważniejsze decyzje.
Takie podejście dobrze współgra z nowoczesnymi architekturami: mikroserwisami, chmurą, kontenerami. Zamiast rozszerzać jedną wielką sieć VPN na kolejne klastry i regiony, wdraża się polityki dostępu do usług, bazujące na tożsamościach (użytkowników, urządzeń, usług) i silnej kryptografii.
Szyfrowanie jako rdzeń Zero Trust, a nie dodatek
VPN jako tunel vs szyfrowanie każdego sensownego przepływu
Klasyczny VPN daje wrażenie: „skoro mam szyfrowany tunel, to problem szyfrowania jest rozwiązany”. Zero Trust mówi: szyfrowanie musi dotyczyć każdego istotnego przepływu danych, niezależnie od tego, czy ruch idzie przez VPN, Internet bezpośrednio, czy wewnętrzną sieć lokalną.
VPN szyfruje całe połączenie między klientem a bramą VPN. Ale co dzieje się dalej? Często ruch między bramą VPN a aplikacją wewnątrz sieci leci już „w czystym tekście” po lokalnych segmentach. W tradycyjnym modelu to „wystarczyło”, bo sieć wewnętrzna była uznawana za zaufaną. W Zero Trust taka logika się nie broni: sieć jest tylko medium, zawsze traktowane jako potencjalnie podsłuchiwane i podatne na kompromitację.
Podejście „szyfrowania każdego sensownego przepływu” oznacza między innymi:
HTTPS/TLS wszędzie – nie tylko na zewnątrz, ale też między serwisami wewnętrznymi,
mTLS (wzajemne uwierzytelnianie TLS) dla komunikacji usług-usługa,
szyfrowanie baz danych „w spoczynku” i „w tranzycie”,
szyfrowanie komunikacji narzędzi administracyjnych (SSH z silnymi kluczami, RDP przez tunelowanie z dodatkowymi warstwami uwierzytelnienia).
Szyfrowanie w spoczynku i w tranzycie – wspólny model
Szyfrowanie danych dzieli się zwykle na dwa główne obszary: w spoczynku (at rest) i w tranzycie (in transit). Zero Trust zakłada, że oba muszą być zorganizowane spójnie, według jednego modelu zarządzania kluczami i politykami dostępu.
Szyfrowanie w tranzycie to wszystkie mechanizmy chroniące dane w ruchu: TLS, IPsec, WireGuard, SSH. Kluczowe decyzje architektoniczne dotyczą tutaj wyboru protokołów (np. HTTPS z TLS 1.3 zamiast własnych rozwiązań), zarządzania certyfikatami, rotacji kluczy oraz wymuszania szyfrowania nawet na wewnętrznych ścieżkach komunikacji.
Szyfrowanie w spoczynku obejmuje dyski serwerowe, bazy danych, snapshoty, backupy, a w niektórych przypadkach także cache i logi. W modelu Zero Trust nie zakłada się, że fizyczny dostęp do sprzętu czy kopii zapasowych jest zawsze pod pełną kontrolą. Dane powinny być zaszyfrowane nawet wtedy, gdy ktoś wyniesie fizyczny dysk lub przejmie obraz maszyny wirtualnej.
Spójność polega na tym, że zarządzanie kluczami szyfrującymi (KMS, HSM, systemy rotacji kluczy, integracja z IdP) jest częścią jednej strategii. Ten sam system tożsamości, który decyduje, kto może się zalogować do aplikacji, współdecyduje także, kto może odszyfrować dane lub uzyskać dostęp do kluczy. VPN może być tylko kanałem transportu – sercem są klucze i polityki oparte na tożsamości.
Algorytmy szyfrowania a decyzje architektoniczne
Nie trzeba być kryptografem, aby projektować rozsądne architektury Zero Trust, ale pewne podstawowe pojęcia z obszaru szyfrowania warto przełożyć na decyzje projektowe.
Dobór protokołów i algorytmów: praktyczne decyzje zamiast kryptograficznej teorii
Najczęstszy błąd przy planowaniu szyfrowania w duchu Zero Trust to skupienie się na egzotycznych algorytmach, a pominięcie prostych, praktycznych wyborów. W większości organizacji wystarczy trzymać się aktualnych standardów branżowych i konsekwentnie je egzekwować.
W praktyce oznacza to kilka prostych zasad projektowych:
TLS 1.2+ lub 1.3 obowiązkowy – wszystkie nowe usługi powinny wymuszać TLS 1.2 z mocnymi zestawami szyfrów, a tam, gdzie to możliwe, przechodzić na TLS 1.3, który upraszcza negocjację i domyślnie eliminuje wiele słabości.
Klucze asymetryczne o bezpiecznej długości – RSA 2048+ lub lepiej krzywe eliptyczne (np. P-256), co przekłada się na krótsze klucze i lepszą wydajność przy tym samym poziomie bezpieczeństwa.
Szyfry symetryczne z rodziny AES – AES-256-GCM lub chociaż AES-128-GCM dla szyfrowania danych w ruchu i w spoczynku, zamiast przestarzałych trybów typu CBC bez uwierzytelnienia.
Nowoczesne VPN-y – przy nowych wdrożeniach rozważyć protokoły takie jak WireGuard, które stawiają na prostotę, nowoczesne prymitywy kryptograficzne i łatwiejsze audyty konfiguracji niż wielkie „kombajny” IPsec.
Różnica między „mamy szyfrowanie” a „mamy sensowne szyfrowanie” nie leży w samym AES-ie, tylko w całym łańcuchu: jak generujemy i przechowujemy klucze, jak często je rotujemy, jak wygląda proces odwoływania certyfikatów. Zero Trust zachęca, aby traktować tę infrastrukturę jako serce bezpieczeństwa – ważniejsze nawet niż pojedynczy firewall.
Kryptografia zorientowana na tożsamość (PKI, certyfikaty, KMS)
Żeby Zero Trust faktycznie działał, szyfrowanie musi być ściśle związane z tożsamością. Sam fakt, że połączenie jest „zaszyfrowane”, nic nie mówi o tym, kto jest po drugiej stronie. Potrzebny jest mechanizm, który powiąże klucze z użytkownikami, urządzeniami i usługami.
Najczęściej realizuje się to przez kombinację:
PKI (Public Key Infrastructure) – wewnętrzna infrastruktura klucza publicznego, wystawiająca certyfikaty dla serwerów, usług, a czasem również urządzeń użytkowników,
KMS (Key Management Service) – centralny system do generowania, przechowywania i rotacji kluczy szyfrujących (w chmurze lub on-prem),
HSM (Hardware Security Module) – sprzętowe moduły zabezpieczające klucze główne, bez możliwości ich „wyjęcia” w postaci surowej.
Dzięki takim klockom można osiągnąć efekt, który jest sednem Zero Trust: „ufam temu połączeniu, ponieważ znam tożsamość po obu stronach i mam ją udokumentowaną w postaci certyfikatów i kluczy, a nie dlatego, że jest to IP z mojej podsieci”.
Przykładowo: mikroserwisy w klastrze Kubernetes nie ufają sobie tylko dlatego, że stoją w tym samym VPC. Każda usługa posiada własny certyfikat (często wystawiony automatycznie przez komponent typu cert-manager), a komunikacja między nimi przebiega po mTLS. Złapanie pakietów sieciowych lub „doklejenie się” do sieci nie wystarczy – napastnik musi jeszcze posiadać ważny certyfikat i klucz prywatny, przypisany do właściwej tożsamości.
Źródło: Pexels | Autor: Brett Sayles
Jak Zero Trust zmienia rolę i projekt klasycznego VPN
Od „rury do środka” do „precyzyjnego dostępu do aplikacji”
W klasycznym ujęciu VPN był po prostu prywatną rurą do wnętrza organizacji. Po jednej stronie użytkownik w domu, po drugiej – cała wewnętrzna sieć. Zero Trust odwraca ten model: zamiast dawać dostęp do sieci, przyznaje się dostęp do konkretnych aplikacji i usług.
W praktyce oznacza to dwie zmiany w roli VPN:
VPN staje się jednym z wielu kanałów transportu – jego zadaniem jest zabezpieczenie ruchu między punktem A i B, ale decyzje dostępu podejmowane są wyżej, na poziomie tożsamości i aplikacji.
VPN nie musi już „wpuszczać” do całej sieci – może tworzyć bardzo wąskie tunele do pojedynczych aplikacji, często przy użyciu rozwiązań typu ZTNA, które działają jak „odwrócony proxy” zamiast klasycznego rozszerzenia LAN-u.
Dobrym obrazem zmiany jest przejście z modelu „mapuję wirtualny dysk do całej sieci plików” na model „otwieram jedną aplikację webową, która udostępnia dokładnie to, czego potrzebuję”. VPN w tym drugim scenariuszu bywa wręcz niewidoczny dla użytkownika – ruch automatycznie przechodzi przez agenta ZTNA lub lekką bramę aplikacyjną.
VPN jako element wielowarstwowej ochrony, a nie „święty firewall”
W środowisku Zero Trust VPN nie stoi już sam na warcie. Staje się jedną z warstw – obok WAF-a, brokera tożsamości, inspekcji ruchu, systemów EDR na końcówkach. Zamiast jednego „świętego” punktu kontroli mamy łańcuch mniejszych kontroli, które razem zmniejszają powierzchnię ataku.
Dla użytkownika oznacza to, że:
samo włączenie VPN nie jest przepustką do całego świata,
część aplikacji będzie dostępna bez VPN (przez Internet, ale z mocną autoryzacją i mTLS),
niektóre operacje mogą wymagać dodatkowego MFA mimo aktywnego tunelu VPN, jeśli kontekst się zmieni (lokalizacja, urządzenie, ryzyko).
Dla administratora sieci oznacza to z kolei inne podejście do projektowania: mniej skupienia na budowaniu ogromnego, redundantnego klastra VPN dla całej firmy, a więcej na modułach zapewniających tożsamość, inspekcję i polityki dostępu na poziomie aplikacji.
Granularność dostępu: od podsieci do pojedynczego endpointu
Gdy VPN przestaje być „wielką bramą do środka”, naturalnym krokiem jest zwiększanie granularności dostępu. W modelu Zero Trust celem jest zejście aż do poziomu pojedynczego endpointu API lub funkcji w aplikacji.
Łańcuch decyzji może wyglądać następująco:
Użytkownik uruchamia klienta (agent ZTNA lub lekki VPN) i uwierzytelnia się z użyciem SSO + MFA.
System przypisuje mu tożsamość, role, informacje o urządzeniu i ryzyku (np. „nowe urządzenie, kraj nietypowy dla tego użytkownika”).
Na podstawie tej kombinacji przyznawany jest dostęp do konkretnych aplikacji, a nie do całych podsieci.
Każda aplikacja dodatkowo egzekwuje własne reguły RBAC/ABAC – użytkownik działu HR widzi inne dane niż menedżer, mimo że korzystają z tego samego URL.
VPN w tym łańcuchu jest po prostu bezpiecznym transportem, który może dodatkowo przekazać kontekst do aplikacji (np. nagłówki z informacją o urządzeniu, poziomie ryzyka, wyniku polityk). Z perspektywy architekta to ogromna zmiana: logika bezpieczeństwa migruje z routerów i firewalli do warstwy tożsamości i aplikacji.
ZTNA, SDP i inne nowe podejścia: co zastępuje „wielkiego VPN-a”
Zero Trust Network Access (ZTNA): VPN „na sterydach” czy coś zupełnie innego?
ZTNA często bywa reklamowane jako „nowy VPN”, ale tak naprawdę różni się od niego zarówno podejściem, jak i architekturą. Zamiast jednej dużej bramy, która wpuszcza użytkownika do sieci, mamy warstwę pośrednią między użytkownikiem a aplikacjami, sterowaną politykami na bazie tożsamości i kontekstu.
Charakterystyczne cechy ZTNA:
Dostęp do aplikacji, nie do sieci – polityki opisuje się w kategoriach „kto do jakiej aplikacji i w jakich warunkach”, a nie „które IP do której podsieci”.
Brak ekspozycji aplikacji do Internetu – aplikacje nie są wystawione bezpośrednio; użytkownik łączy się z chmurową lub on-premową bramą ZTNA, która zestawia połączenie dopiero po weryfikacji.
Granularne polityki oparte na tożsamości – łatwiej zdefiniować zasady typu „konsultanci z firmy X mają tylko read-only do aplikacji Y i tylko z zarządzanych urządzeń”.
Od strony użytkownika często wygląda to bardzo przyjaźnie: loguje się do portalu, widzi katalog „swoich” aplikacji i uruchamia je jak zakładki w przeglądarce, niezależnie od tego, czy stoją one w chmurze, czy w „starym” data center.
Software Defined Perimeter (SDP): czynienie zasobów „niewidzialnymi”
SDP rozwija tę ideę jeszcze dalej. Zasoby firmowe stają się niewidzialne dla kogokolwiek, kto nie przeszedł wstępnej autoryzacji. W praktyce hosty nie odpowiadają na skanowanie portów, DNS zwraca inne informacje, a ruch jest przekierowywany tylko wtedy, gdy użytkownik i jego urządzenie zostały poprawnie zidentyfikowane.
Z perspektywy atakującego oznacza to brak klasycznych punktów zaczepienia. Nie ma listy publicznie widocznych serwerów do „ostrzelania”, bo każdy zasób jest „odkrywany” dynamicznie dopiero po uzyskaniu dostępu. Dla zespołów bezpieczeństwa to bardzo cenny efekt uboczny Zero Trust – znaczące ograniczenie powierzchni ataku pasywnego.
Gdzie ZTNA/SDP, a gdzie wciąż klasyczny VPN?
Nawet najbardziej ambitna strategia Zero Trust nie wyeliminuje klasycznego VPN z dnia na dzień. Są obszary, gdzie tunel sieciowy nadal ma sens, choć i tam zmienia się jego rola.
Przykładowe scenariusze, gdzie klasyczny VPN wciąż bywa potrzebny:
Dostęp do starszych systemów, które nie wspierają SSO, mTLS czy integracji z IdP – wtedy VPN bywa „protezą”, ale można go opakować dodatkowymi kontrolami.
Zdalne zarządzanie infrastrukturą (np. dostęp do konsol sieciowych, IPMI, starych paneli administracyjnych) – często kończy się na wąskich, administratorskich VPN-ach, zabezpieczonych mocnym MFA i segmentacją.
Zastosowania specjalne, np. urządzenia przemysłowe czy medyczne, gdzie wdrożenie nowoczesnych agentów ZTNA jest trudne lub niemożliwe.
Stopniowa ewolucja polega na tym, że większość użytkowników biznesowych i większość aplikacji przenosi się na ZTNA/SDP, a klasyczny VPN zostaje jako narzędzie „dla adminów i wyjątków”. Dzięki temu potencjalne szkody w razie kompromitacji konta VPN są znacząco mniejsze.
Warstwa tożsamości i kontekstu: kto, skąd, na czym i do czego
IdP jako „nowy rdzeń” infrastruktury
W tradycyjnym podejściu centrum świata stanowił katalog AD i sieć lokalna. W modelu Zero Trust ten środek ciężkości przesuwa się w stronę Identity Providerów (IdP) – systemów, które wystawiają tokeny tożsamości (SAML, OIDC) i decydują, kto jest kim.
Dobre IdP w architekturze Zero Trust:
integruje użytkowników z różnych źródeł (AD, LDAP, zewnętrzni partnerzy),
zapewnia SSO do aplikacji SaaS, on-prem, a także do bram ZTNA/VPN,
obsługuje reguły warunkowego dostępu (conditional access) – np. dodatkowe MFA dla logowań spoza zaufanych krajów czy spoza zarządzanych urządzeń,
udostępnia atrybuty, które potem są wykorzystywane w politykach dostępowych (rola, dział, typ konta, poziom ryzyka).
W praktyce IdP staje się „jedynym źródłem prawdy” o użytkowniku. To właśnie jego token jest przepustką do aplikacji, do bramy ZTNA, do systemu ticketowego czy panelu administracyjnego. VPN przestaje posiadać własną, oderwaną bazę użytkowników; opiera się na tym samym IdP co reszta ekosystemu.
Kontekst urządzenia: zarządzane vs „cokolwiek z domu”
Tożsamość użytkownika to tylko połowa układanki. Równie ważne jest to, na jakim urządzeniu działa klient i w jakim jest ono stanie. Czy to laptop zarządzany przez firmowe MDM, czy prywatny komputer z nieznaną historią i oprogramowaniem?
Typowe elementy kontekstu urządzenia, które można uwzględnić w politykach:
status zarządzania (enrolled w MDM vs nieznane urządzenie),
stan zabezpieczeń (aktualny system, włączone szyfrowanie dysku, działające EDR/antywirus),
typ systemu (Windows, macOS, Linux, mobilne OS-y),
poziom zgodności z polityką bezpieczeństwa (compliant / non-compliant, z określonymi szczegółami).
Dzięki temu można budować reguły, które różnicują dostęp. Przykład: z niezarządzanego urządzenia pracownik może wejść tylko na portal HR i odczytać własne dokumenty, ale nie połączy się z wrażliwymi systemami finansowymi czy narzędziami administracyjnymi. Szyfrowanie ruchu nadal jest, ale zakres dostępu jest adekwatny do ryzyka.
Geolokalizacja, czas, anomalie: kontekst „miękki”, ale bardzo użyteczny
Kontekst sesji i zachowania użytkownika
Poza twardymi danymi o urządzeniu i lokalizacji pojawia się jeszcze jeden wymiar: jak użytkownik zachowuje się w czasie konkretnej sesji. To trochę jak z ochroną w galerii handlowej – nie tylko liczy się, kto wszedł, ale też co robi między półkami.
Systemy klasy Zero Trust coraz częściej integrują się z mechanizmami UEBA (User and Entity Behavior Analytics). Obserwują one m.in.:
nietypowe próby dostępu do nowych aplikacji lub danych,
nagłe zrywy aktywności – np. masowe pobieranie plików lub exporty raportów,
zmianę sposobu logowania (nowe przeglądarki, inne agenty, dziwne ciągi błędnych haseł),
niezgodność z „profilem” działania użytkownika – księgowy nagle próbuje dostać się do repozytorium kodu.
Takie sygnały są przetwarzane w locie i zamieniane na ocenę ryzyka sesji. A dalej – przekładane na konkretne działania: podniesienie poziomu uwierzytelnienia, ograniczenie dostępu, a w skrajnym wypadku natychmiastowe rozłączenie tunelu VPN czy sesji ZTNA.
Przykładowo: użytkownik loguje się z typowej lokalizacji, na służbowym laptopie, ale po kilku minutach zaczyna pobierać setki dokumentów z działu prawnego. Silnik UEBA oznacza sesję jako wysokiego ryzyka, ZTNA wymusza dodatkowe MFA, a część aplikacji przechodzi w tryb tylko-do-odczytu. Szyfrowanie ruchu nadal jest, lecz ochrona nie kończy się na TLS; dochodzi inteligencja nad przepływem danych.
Korelacja sygnałów: od „pojedynczych regułek” do polityk opartych na ryzyku
Sam pojedynczy sygnał – np. logowanie z innego kraju – niewiele znaczy. Problemy zaczynają się, gdy kilka takich oznak zbiega się w czasie. Dlatego Zero Trust opiera się na korelacji sygnałów, a nie na pojedynczych, sztywnych regułach.
Typowa polityka warunkowego dostępu nie brzmi: „z USA wpuszczamy, z innych krajów blokujemy”. Bardziej przypomina:
jeśli logowanie pochodzi z nieznanego kraju i z niezarządzanego urządzenia,
i użytkownik próbuje dostać się do aplikacji z danymi finansowymi,
i nie logował się tam od co najmniej 60 dni,
to oznacz sesję jako wysokiego ryzyka, zażądaj silniejszego MFA, a jeśli to się nie uda – nie wpuszczaj w ogóle. Dla pozostałych przypadków zastosuj łagodniejsze zasady. VPN w tym obrazie nie decyduje już sam o niczym – staje się wykonawcą decyzji podjętych na podstawie bogatszego kontekstu.
Widoczność i logowanie jako paliwo dla Zero Trust
Cały ten kontekst nie pojawia się z powietrza. Kluczowa jest spójna widoczność zdarzeń z różnych warstw: IdP, klienta VPN/ZTNA, aplikacji, systemów EDR i chmury. Dopiero po ich złożeniu w całość można realnie ocenić, kto co robi i z jakim ryzykiem.
W praktyce oznacza to kilka kroków:
standaryzację logów i telemetryki (formaty, pola, identyfikatory użytkowników),
zbieranie zdarzeń w jednym miejscu – SIEM lub platformie analitycznej,
powiązanie sesji VPN/ZTNA z konkretnymi akcjami w aplikacjach (np. na podstawie identyfikatora tokenu lub sesji),
budowanie playbooków reagowania – co zrobić, gdy dana kombinacja sygnałów zostanie wykryta.
Dzięki temu zamiast surowych logów „tunel zestawiony / tunel rozłączony” powstaje historia: „użytkownik X z urządzenia Y uzyskał dostęp do aplikacji Z, wykonał operacje A, B, C, a w połowie sesji zmieniła się jego ocena ryzyka”. To zupełnie inny poziom kontroli niż tradycyjny VPN, który widział tylko pakiety IP.
Architektura: jak połączyć VPN, szyfrowanie i Zero Trust w realnej firmie
Od „wielkiego tunelu” do architektury warstwowej
Najczęściej droga do Zero Trust nie polega na wyrzuceniu istniejących rozwiązań, lecz na ich przebudowie w stronę architektury warstwowej. Wygląda to jak przejście z jednego, grubego kabla w biurze do sieci cienkich przewodów, które łączą dokładnie te pokoje, które muszą ze sobą rozmawiać.
Podstawowe warstwy takiego projektu to:
warstwa tożsamości – IdP z MFA i regułami warunkowego dostępu,
warstwa transportu – klasyczny VPN i/lub agenci ZTNA, zapewniający szyfrowanie i tunelowanie ruchu,
warstwa kontroli dostępu – bramy ZTNA, proxy mTLS, WAF/API Gateway,
warstwa aplikacji – systemy z własnym RBAC/ABAC i przemyślanym modelem uprawnień,
Rola VPN staje się wyraźniejsza: nie jest już strażnikiem polityk, a bezpiecznym środkiem transportu, wpiętym w większą całość. Decyzje, kto do czego ma dostęp, zapadają gdzie indziej – w IdP, ZTNA i samej aplikacji.
Migracja etapowa: segmentacja użytkowników i aplikacji
Przełączenie wszystkiego na Zero Trust jednego weekendu często kończy się frustracją i rollbackiem. Zdecydowanie lepiej sprawdza się podejście etapowe, oparte na segmentacji.
Przykładowy scenariusz:
Inwentaryzacja aplikacji – identyfikacja systemów: które są webowe, które wspierają SSO, które da się osadzić za proxy mTLS lub bramą ZTNA.
Podział użytkowników – np. pracownicy biurowi, administratorzy, kontraktorzy, użytkownicy zewnętrzni.
Pierwsza fala – przeniesienie najprostszych aplikacji webowych pracowników biurowych na ZTNA/SSO, z równoczesnym utrzymaniem VPN jako „planu B”.
Stopniowe wyłączanie dostępu sieciowego – aplikacje, które znalazły się za ZTNA, przestają być osiągalne przez klasyczny VPN (lub dostęp jest silnie ograniczony).
Obsługa wyjątków – dla systemów, których nie da się przestawić, powstają specjalne, mocno ograniczone profile VPN, często tylko dla wąskiej grupy adminów.
W praktyce część użytkowników przez długi czas funkcjonuje w modelu hybrydowym: część pracy wykonują „przez katalog aplikacji ZTNA”, a do paru starych narzędzi wchodzą wciąż przez tunel VPN. Ważne, by ten tunel był już w tym momencie ściśle segmentowany, a nie dawał pełnego „wejścia do środka”.
Integracja VPN z IdP i politykami warunkowego dostępu
Jeśli w organizacji istnieje już solidny IdP, największym błędem jest trzymanie przy VPN osobnej bazy użytkowników i osobnych haseł. Pierwszym „szybkim zwycięstwem” bywa zintegrowanie VPN z IdP, tak aby logowanie do tunelu korzystało z SSO i MFA.
Daje to kilka korzyści:
spójne zasady haseł i MFA dla wszystkich usług,
łatwiejsze offboarding – wyłączenie konta w IdP odcina również VPN,
możliwość stosowania reguł warunkowego dostępu przy samym logowaniu do tunelu (lokalizacja, typ urządzenia, ryzyko),
lepsza widoczność – logi logowania do VPN trafiają do tego samego ekosystemu co logowania do SaaS i innych aplikacji.
Z czasem można pójść dalej – VPN przestaje akceptować logowanie, jeśli IdP oznaczy użytkownika jako wysokiego ryzyka (np. przez integrację z systemem wykrywania wycieków poświadczeń lub anomalii behawioralnych). W ten sposób nawet „stary” tunel zaczyna działać zgodnie z filozofią Zero Trust.
Proxy mTLS i bramy aplikacyjne jako „mini VPN-y”
W architekturach Zero Trust coraz częściej kluczową rolę odgrywa mTLS i bramy aplikacyjne, które wyglądają jak „mini VPN-y” dla pojedynczych systemów. Zamiast wpuszczać użytkownika do sieci, zestawiają szyfrowane połączenie dokładnie między nim a daną aplikacją.
Typowy układ wygląda następująco:
użytkownik uwierzytelnia się w IdP i otrzymuje token,
agent ZTNA lub lekki klient ustawia połączenie mTLS do bramy,
brama na podstawie polityk decyduje, czy i jak przekazać ruch do ukrytej aplikacji,
aplikacja ufa certyfikatowi bramy (lub klienta) i tokenowi z IdP, bez potrzeby ekspozycji do Internetu.
W wielu przypadkach takie bramy stopniowo zastępują pełne VPN dla użytkowników biznesowych. Tunel jest węższy, krótszy, obejmuje tylko konkretną aplikację. Sieć wewnętrzna pozostaje „w cieniu”, a jedynym widocznym elementem jest kontrolowana, monitorowana brama.
Mikrosegmentacja sieci a klasyczny VPN
Jeżeli infrastruktura jest jeszcze mocno „sieciocentryczna” – z dużymi VLAN-ami i serwerami na wspólnych podsieciach – sensowne jest wprowadzenie mikrosegmentacji. Chodzi o to, by nawet jeśli ktoś z VPN dostanie się do wnętrza, miał przed sobą dodatkowe bariery.
Rozwiązuje się to na kilka sposobów:
mikrosegmentacja na poziomie hipervisora lub SDN (policy-based routing, firewalle rozproszone),
strefy bezpieczeństwa dla całych klas systemów (np. „strefa baz danych”, „strefa aplikacji”, „strefa administracyjna”),
oddzielenie sieci użytkowników VPN od sieci serwerów, z selektywnym dostępem tylko do ściśle określonych usług.
W tym modelu VPN staje się jedną z wielu „stref brzegowych”, a wewnątrz sieci działają dodatkowe, niezależne od niego kontrole. Jeden błąd w polityce VPN nie oznacza automatycznie katastrofy, bo pakiety nadal muszą pokonać kolejne zapory i reguły, zwykle znacznie bardziej granularne.
Rola szyfrowania danych w spoczynku i w aplikacjach
Jeżeli szyfrowanie ma być rdzeniem Zero Trust, nie może kończyć się na VPN i TLS. Dane powinny być chronione również w spoczynku i na poziomie samych aplikacji. Wtedy nawet kompromitacja tunelu czy pojedynczego serwera nie skutkuje pełnym wyciekiem informacji.
Przy projektowaniu architektury warto zszyć kilka poziomów szyfrowania:
szyfrowanie dysków na stacjach roboczych i serwerach (BitLocker, LUKS, FileVault),
szyfrowanie baz danych i backupów, najlepiej z osobnym zarządzaniem kluczami (KMS, HSM),
szyfrowanie na poziomie aplikacji – np. pola wrażliwe (PESEL, dane finansowe) szyfrowane w samej aplikacji, tak aby baza widziała tylko zaszumione wartości.
Taki układ powoduje, że VPN pełni głównie rolę kanału komunikacyjnego, natomiast prawdziwe bezpieczeństwo danych zależy od kluczy i polityk kryptograficznych. Z perspektywy Zero Trust to spójne: nie ufamy ani sieci, ani pojedynczemu hostowi, ufamy wyłącznie dobrze zarządzanym kluczom i tożsamościom.
Obsługa aplikacji SaaS i chmur publicznych
Klasyczny VPN świetnie łączył użytkowników z własnym data center, ale gorzej radzi sobie ze światem SaaS i wielu chmur. Przy architekturze Zero Trust trzeba pogodzić te dwa światy tak, aby użytkownik nie musiał „skakać” między różnymi sposobami dostępu.
Praktyczne podejście często wygląda tak:
aplikacje SaaS są dostępne bez VPN, lecz zawsze przez IdP z wymuszonym MFA i politykami warunkowego dostępu,
dostęp administracyjny do chmur (AWS, Azure, GCP) bywa chroniony dodatkowo – np. dostęp do konsol tylko przez ZTNA lub dedykowany, mocno ograniczony VPN,
aplikacje migrowane do chmury prywatnej/publicznej są umieszczane za wspólnymi bramami ZTNA, aby zachować spójny sposób dostępu z perspektywy użytkownika.
Użytkownik końcowy widzi jeden katalog aplikacji i jedno logowanie, za którym kryją się zupełnie różne ścieżki techniczne. Czasem ruch leci bezpośrednio po HTTPS do SaaS, czasem przez lekki agent ZTNA, czasem przez wąski tunel VPN. Całość spaja IdP i polityki dostępu, nie adres IP na końcówce.
Procedury awaryjne i „tryb degradacji”
Projektując architekturę, trzeba też zadać nieco niewygodne pytanie: co się stanie, gdy któryś z elementów Zero Trust przestanie działać? IdP jest niedostępne, brama ZTNA ma awarię, agent kliencki się wysypał – a ludzie muszą pracować.
Zdrowym podejściem jest przygotowanie trybów degradacji z jasno opisanymi kompromisami bezpieczeństwa. Przykładowo:
w razie awarii ZTNA część kluczowych aplikacji może zostać tymczasowo udostępniona przez klasyczny VPN, ale tylko użytkownikom z określonych ról,
jeżeli IdP SaaS jest nieosiągalne, organizacja ma zapasowy IdP on-prem z ograniczonym zakresem dostępu,
Najczęściej zadawane pytania (FAQ)
Czym różni się Zero Trust od klasycznego VPN?
Klasyczny VPN zakłada, że po zalogowaniu użytkownik „wpada” do zaufanej sieci i może komunikować się z wieloma zasobami, często z całą podsiecią. To trochę jak wydanie klucza do całego biura, choć ktoś potrzebuje tylko jednego pokoju.
Zero Trust odwraca to podejście: sieć sama w sobie nie jest zaufana, a dostęp przyznaje się nie do „sieci firmowej”, tylko do konkretnych aplikacji czy usług. Każda próba dostępu jest osobno uwierzytelniana i autoryzowana, zgodnie z zasadą najmniejszych uprawnień.
Czy Zero Trust oznacza, że VPN przestaje być potrzebny?
Nie zawsze. W wielu firmach VPN nadal będzie używany, ale raczej jako jedno z narzędzi w szerszej architekturze Zero Trust, a nie jako główna bariera bezpieczeństwa. Tunel VPN może dalej szyfrować ruch, ale o tym, do czego użytkownik ma dostęp, decydują polityki aplikacyjne i tożsamościowe, a nie sam fakt połączenia z VPN.
W części organizacji szczególnie chmurowych klasyczny VPN bywa zastępowany rozwiązaniami typu ZTNA (Zero Trust Network Access), które realizują „VPN do konkretnej aplikacji”, a nie do całej sieci. To przejście raczej ewolucyjne niż jednorazowa rewolucja.
Jak Zero Trust poprawia bezpieczeństwo w porównaniu z tradycyjnym VPN?
W tradycyjnym VPN przejęcie jednego konta lub zainfekowanego laptopa często oznacza dostęp do dużej części sieci wewnętrznej. Atakujący może skanować hosty, szukać słabych haseł i luk w serwerach, bo „jest już w środku”.
W Zero Trust atakujący, nawet z poprawnymi danymi logowania, widzi tylko to, do czego przypisano uprawnienia na poziomie aplikacji. Mikrosegmentacja, ciągła weryfikacja kontekstu (lokalizacja, stan urządzenia, nietypowe zachowanie) oraz dokładne logi działań mocno zawężają pole manewru i przyspieszają wykrycie incydentu.
Na czym polega zasada najmniejszych uprawnień w Zero Trust?
Zasada najmniejszych uprawnień (least privilege) mówi: użytkownik lub usługa dostają tylko tyle dostępu, ile faktycznie potrzebują do pracy – ani kroku dalej. Pracownik HR nie musi widzieć serwerów finansowych, a programista nie potrzebuje dostępu do systemu płac.
Technicznie oznacza to nadawanie dostępów na poziomie konkretnych aplikacji, URL-i, portów czy metod API, a nie całych podsieci. W praktyce: zamiast „wpuszczam cię do sieci 10.0.0.0/16”, mówimy „dopuszczam połączenia tylko do app-hr.firma.pl na określonych portach i tylko z twojego, znanego urządzenia”.
Jak Zero Trust pomaga w środowiskach chmurowych i przy pracy zdalnej?
W chmurze i przy pracy zdalnej znika jasna granica „wewnątrz–na zewnątrz”. Użytkownik jednocześnie korzysta z SaaS, zasobów w AWS czy Azure oraz z kilku systemów on‑prem. Klasyczny VPN próbuje to wszystko „ubrać” w jeden tunel do „sieci firmowej”, co szybko się komplikuje.
Zero Trust opiera się na tożsamości i kontekście, a nie lokalizacji w sieci. Można spójnie egzekwować polityki dostępu niezależnie od tego, czy aplikacja jest w chmurze, centrum danych czy w SaaS. Pracownik w domu loguje się przez SSO z MFA, a silnik polityk decyduje, które konkretne aplikacje zobaczy, zamiast po prostu podłączać go do całej sieci.
Czym jest mikrosegmentacja w Zero Trust i jak zastępuje „jeden duży VPN”?
Mikrosegmentacja to dzielenie infrastruktury na małe, logiczne „wysepki” dostępu zamiast jednej płaskiej sieci. Każda aplikacja lub grupa pokrewnych usług może być osobnym segmentem z własnymi, precyzyjnymi regułami.
Z perspektywy użytkownika wygląda to tak, jakby miał „mini‑VPN” tylko do konkretnej aplikacji: łączy się, uwierzytelnia, a potem widzi wyłącznie ten jeden system. Nie ma możliwości skanowania całej sieci, bo innych segmentów po prostu „nie ma” dla jego tożsamości.
Jak zacząć przechodzenie z klasycznego VPN na model Zero Trust?
Najrozsądniej jest zacząć od inwentaryzacji: kto do czego się łączy i po co. Na tej podstawie można wyodrębnić kilka krytycznych aplikacji (np. HR, finanse, systemy administracyjne) i dla nich wdrożyć dokładniejsze uwierzytelnianie (SSO, MFA) oraz precyzyjne polityki dostępu.
Kolejny krok to stopniowe ograniczanie szerokiego dostępu z VPN: zawężanie podsieci, przenoszenie części ruchu do rozwiązań typu ZTNA, wprowadzenie identyfikacji urządzeń i prostych zasad kontekstowych (np. blokada z nietypowych lokalizacji). Z czasem klasyczny VPN zostaje albo bardzo mocno „wyszczuplony”, albo zastąpiony przez podejście „dostęp tylko do aplikacji”.
Najważniejsze punkty
Klasyczny VPN powstał dla świata „jednego zamku za murem” – dawał zdalnemu użytkownikowi wrażenie, że siedzi w biurze, co w realiach chmury, SaaS i pracy z każdego miejsca przestaje się sprawdzać.
Po połączeniu VPN-em użytkownik zwykle widzi całą podsieć (a czasem kilka), co tworzy model „wszystko albo nic” – przejęty laptop lub konto staje się wygodną windą dla atakującego do wielu zasobów naraz.
Brak precyzyjnej segmentacji, słaby wgląd w to, do jakich konkretnie aplikacji ktoś sięga, oraz skomplikowane, podatne na błędy reguły dostępu sprawiają, że utrzymanie klasycznego VPN jest coraz trudniejsze i mniej bezpieczne.
Rozproszenie środowiska (on‑prem, kilka chmur, SaaS, partnerzy, BYOD) rozmywa granicę między „wewnątrz” a „na zewnątrz”, więc sam tunel sieciowy nie wystarczy do sensownego kontrolowania dostępu.
Model Zero Trust zakłada brak domyślnego zaufania – sam fakt, że urządzenie jest „w sieci firmowej” albo podpięte do VPN, nie daje mu z automatu prawa dostępu do innych systemów.
W Zero Trust każdy dostęp do aplikacji, API czy pliku jest osobno uwierzytelniany i autoryzowany, często z uwzględnieniem kontekstu (kto, skąd, z jakiego urządzenia), dzięki czemu ewentualne włamanie ma o wiele mniejszy zasięg.
