VPN czy dostęp zero trust: co wybrać w firmie?

VPN czy dostęp zero trust: wybór zależy od zasobu i kontroli dostępu

VPN jest przydatny, gdy uprawniona osoba potrzebuje kontrolowanego dostępu technicznego do sieci lub wydzielonego segmentu. Dostęp zero trust, często realizowany przez ZTNA, lepiej pasuje do udostępniania konkretnych aplikacji według tożsamości, urządzenia i polityki. W wielu firmach oba modele współistnieją; decyzja zaczyna się od tego, do czego użytkownik ma mieć dostęp i dlaczego.

Zero trust nie jest pojedynczym produktem ani automatyczną gwarancją bezpieczeństwa. NIST opisuje ten model jako zestaw koncepcji ograniczających niepewność przy egzekwowaniu precyzyjnych decyzji o dostępie do zasobów. [1] To wymaga znanych kont, właścicieli aplikacji, zasad uwierzytelniania oraz procesu obsługi wyjątków.

Materiał pomaga przygotować decyzję o dostępie zdalnym. Nie stanowi gotowej konfiguracji, deklaracji zgodności, oferty licencji ani obietnicy ciągłości działania.

Najpierw rozdziel dostęp do aplikacji od dostępu do sieci

Pytanie „VPN czy zero trust” bywa nieprecyzyjne, ponieważ miesza dwa potrzeby. Użytkownik systemu ERP, CRM albo poczty zwykle potrzebuje konkretnej aplikacji. Administrator starszego serwera, urządzenia sieciowego lub systemu działającego wyłącznie wewnątrz firmy może potrzebować technicznej ścieżki do wydzielonego segmentu. Nadanie całej sieci dlatego, że potrzebna jest jedna aplikacja, zwiększa zakres, który należy kontrolować.

VPN tworzy szyfrowane połączenie urządzenia z infrastrukturą firmy. Sam tunel nie określa jednak, czy użytkownik może widzieć każdy host, korzystać z każdego portu albo wykonywać działania administracyjne. Te granice wynikają z segmentacji, reguł zapory, kont, grup i uprawnień. NIST zwraca uwagę, że bezpieczeństwo pracy zdalnej wymaga łączenia kontroli dostępu, urządzeń i polityk, a nie wyłącznie wyboru kanału połączenia. [3]

W modelu aplikacyjnym decyzja może być podejmowana dla konkretnej usługi: użytkownik, metoda MFA, stan urządzenia, grupa i wymagany poziom ryzyka. Nie oznacza to, że każda starsza aplikacja da się od razu przenieść do takiego modelu. Warto więc zacząć od mapy zasobów, a nie od masowej migracji.

Kiedy VPN pozostaje uzasadniony

VPN może być proporcjonalnym rozwiązaniem, gdy firma korzysta z lokalnych usług, urządzeń sieciowych lub specjalistycznych aplikacji klienckich, których nie można bezpiecznie udostępnić jako pojedynczej aplikacji. Dotyczy to również części prac administracyjnych, ale dostęp administracyjny wymaga odrębnych reguł niż codzienna praca biurowa.

Warunkiem jest znany zakres. Imienne konto, MFA tam, gdzie jest możliwe i uzasadnione, ograniczenie do potrzebnych segmentów, rejestr nadanych dostępów oraz okresowy przegląd są ważniejsze niż sama nazwa klienta VPN. Konto współdzielone, jedna szeroka grupa dla wszystkich i pozostawiony dostęp po zakończeniu współpracy tworzą ryzyko niezależnie od użytego tunelu.

Nie należy zakładać, że VPN daje automatycznie bezpieczny dostęp z każdego prywatnego urządzenia. Stan urządzenia, aktualizacje, ochrona ekranu, sposób przechowywania danych i proces zgłoszenia utraty sprzętu także wpływają na ryzyko. CISA opisuje zero trust jako stopniową zmianę dojrzałości; podobnie porządkowanie VPN można prowadzić etapami. [2]

Co zmienia dostęp zero trust i ZTNA

W podejściu zero trust dostęp nie wynika z samego faktu, że urządzenie połączyło się z „wewnętrzną” siecią. Polityka ocenia żądanie dostępu do zasobu i może uwzględnić tożsamość, rolę, stan urządzenia, kontekst logowania oraz wymaganie dodatkowego uwierzytelnienia. Dzięki temu pracownik może otrzymać dostęp do wskazanej aplikacji bez widoczności pozostałej sieci.

Największą wartością nie jest dodatkowy panel administracyjny, lecz możliwość odpowiedzi na pytania: kto ma dostęp do aplikacji, jaki jest cel tego dostępu, na jakim urządzeniu pracuje i kto zatwierdza wyjątek. Bez aktualnej ewidencji kont i właścicieli usług nowa technologia może tylko przenieść nieuporządkowane reguły do innego miejsca.

Zmiana powinna uwzględnić doświadczenie użytkownika. Zbyt szeroka blokada, nieuwzględnione konto techniczne lub brak procedury odzyskania dostępu mogą zatrzymać proces biznesowy. Dlatego polityki warto testować na reprezentatywnej grupie, zapisać warunek rozszerzenia i wskazać drogę wycofania zmiany.

Dostęp administracyjny wymaga osobnych zasad

Największy wpływ na środowisko mają zwykle konta administracyjne, a nie zwykły dostęp do poczty lub CRM. Administrator nie powinien wykonywać zadań uprzywilejowanych stale na tym samym koncie, którego używa do poczty i codziennej pracy. Rozdzielenie kont ogranicza liczbę sytuacji, w których przejęcie zwykłej sesji prowadzi bezpośrednio do szerokiego dostępu.

Dla działań administracyjnych ustal osobno: dopuszczone źródła połączeń, silne uwierzytelnianie, segment docelowy, rejestrowanie działań, osobę zatwierdzającą dostęp i termin jego przeglądu. VPN może być jedną z warstw kontrolowanej ścieżki, a mechanizmy tożsamości mogą ograniczać, kto z niej skorzysta. Żadna pojedyncza kontrola nie zastępuje pozostałych.

Przy aktywnym podejrzeniu przejęcia konta priorytetem jest ograniczenie skutków i zabezpieczenie dowodów zgodnie z procedurą incydentową. Nie należy wtedy traktować standardowego projektu dostępu jako substytutu reakcji na incydent.

Checklista: co ustalić przed zmianą modelu dostępu

Checklista nie wybiera rozwiązania za firmę. Pomaga jednak odsłonić różnicę między wymaganiem użytkownika a technicznym skrótem myślowym „dajmy VPN”. Każdy punkt warto potwierdzić właścicielem usługi, konfiguracją lub wynikiem testu, a nie wyłącznie deklaracją.

Po pilotażu zapisz otwarte ryzyka, wyjątki i decyzję o rozszerzeniu albo wycofaniu. W ten sposób zmiana jest odwracalnym procesem, a nie jednorazową konfiguracją bez właściciela.

• Wskaż aplikacje, systemy i segmenty, do których dostęp jest faktycznie potrzebny.
• Rozdziel role użytkowników zwykłych, zewnętrznych, technicznych i administracyjnych.
• Ustal właściciela aplikacji lub segmentu, który zatwierdza potrzebę dostępu.
• Sprawdź MFA, sposób odzyskania dostępu oraz konta awaryjne i techniczne.
• Określ wymagania dla urządzenia oraz jawne wyjątki z terminem przeglądu.
• Przygotuj pilotaż, scenariusze testowe, kanał wsparcia i warunek wycofania.
• Ustal, jakie logowania i działania administracyjne mają być rejestrowane.
• Przeglądaj aktywne dostępy po zmianie roli, urządzenia lub dostawcy.

Ograniczenia i ryzyka

VPN, ZTNA i polityki zero trust mogą ograniczać część ryzyka, lecz nie gwarantują pełnego bezpieczeństwa, braku incydentu, zgodności prawnej, dostępności aplikacji ani odzyskania danych. Wynik zależy od architektury, konfiguracji, tożsamości, urządzeń, wyjątków, aktualności dokumentacji i codziennego utrzymania.

Nie zakładaj przed rozpoznaniem środowiska konkretnego SLA, pracy całodobowej, licencji, wsparcia każdego systemu, bezprzerwowej migracji ani przejęcia administracji. Zakres i odpowiedzialności wymagają pisemnego uzgodnienia po sprawdzeniu zależności.

Kiedy potrzebna jest pomoc przy uporządkowaniu modelu dostępu

Pomoc może być potrzebna, gdy firma nie wie, kto ma aktywny VPN, udostępnia szeroki dostęp do sieci dla pojedynczej aplikacji, nie potrafi wskazać właścicieli wyjątków albo chce połączyć tożsamość, urządzenia i segmentację w jeden proces. Pierwszym rezultatem powinny być potwierdzone fakty, granice dostępu i plan pilotażu, a nie automatyczna wymiana wszystkich narzędzi.

Do pierwszej rozmowy przygotuj niesensytywny opis usług, ról użytkowników, rodzaju urządzeń i celu biznesowego. Nie przesyłaj haseł, tokenów, kodów MFA, kluczy odzyskiwania, eksportów konfiguracji, surowych logów ani szczegółów aktywnej podatności.

Źródła

Źródła zewnętrzne zweryfikowane podczas aktualizacji 2026-10-22. Przed działaniem sprawdź ich bieżącą wersję.

• NIST SP 800-207: Zero Trust Architecture
• CISA: Zero Trust Maturity Model
• NIST SP 800-46 Rev. 2: Guide to Enterprise Telework, Remote Access, and BYOD Security