Decyzja w 30 dni: czy VPN jeszcze dowozi, czy już szkodzi?
Masz działający VPN i pytanie brzmi: czy to nadal wystarczy, czy właśnie stało się cichym źródłem ryzyka, kosztów i frustracji użytkowników? Najprostszy sposób, żeby nie wpaść w spiralę marketingu („SASE rozwiąże wszystko”), to potraktować temat jak decyzję operacyjną: co boli, co chronisz i jaki najmniejszy krok da mierzalny efekt.
Pytania startowe, które odsiewają „fanaberię” od realnej potrzeby
Jeśli w 10 minut odpowiesz na te pytania, zwykle od razu widać, czy modernizacja dostępu ma sens:
Co dokładnie robi VPN w firmie? Dostęp do 1–2 aplikacji, czy „brama do całej sieci” dla setek osób?
Ile czasu support traci na „nie łączy / rozłącza / konflikt z EDR / certyfikat wygasł / nie działa na telefonie”?
Czy po zestawieniu tunelu użytkownik widzi zasoby, których nie potrzebuje? (SMB, RDP, segmenty sieci, usługi infrastrukturalne).
Czy audyt / compliance pyta o MFA, najmniejsze uprawnienia i kontrolę urządzeń? Jeśli tak, VPN rzadko „sam z siebie” dowozi te wymagania.
Jaki odsetek pracy to SaaS (Microsoft 365, Google Workspace, CRM, narzędzia dev), a jaki to aplikacje on‑prem?
Sygnały ostrzegawcze: kiedy VPN robi się drogim kompromisem
VPN jako tunel do sieci jest prosty, ale jego „prostota” bywa iluzją. W praktyce problemy zaczynają się, gdy:
Split tunneling jest ustawiony „żeby działało szybciej”, a nikt nie kontroluje, co idzie przez tunel, a co omija firmowe polityki.
Wszystko opiera się na statycznych regułach sieciowych (IP/subnet), a firma ma hybrydę: chmura + on‑prem + użytkownicy mobilni.
Utrzymujesz kilka równoległych mechanizmów dostępu (VPN dla jednych, RDP przez jump host dla drugich, wyjątki dla kontraktorów, osobne rozwiązanie do SaaS).
Rośnie ryzyko lateral movement: jedno konto/urządzenie po wpięciu do VPN ma „zasięg” po sieci większy, niż powinno.
Minimalny cel na miesiąc: wybór 1–2 użyć i kryteria sukcesu
Zamiast planować rewolucję „od razu SASE”, ustaw cel, który da się obronić przed zarządem i… przed własnym zespołem:
Wybierz 1–2 scenariusze pilota (np. dostęp do jednej aplikacji webowej on‑prem i dostęp do panelu administracyjnego w chmurze).
Zdefiniuj kryteria sukcesu: mniej zgłoszeń do helpdesku, szybsze logowanie, brak dostępu do sieci „na zapas”, lepsze logi, łatwiejszy offboarding.
Ustal minimalny zakres polityk: MFA + grupy/role + podstawowy warunek urządzenia (np. szyfrowanie dysku, EDR aktywny).
Krótki scenariusz, który powtarza się w MŚP
Firma pracuje hybrydowo. VPN jest „OK”, ale helpdesk regularnie gasi pożary: klient VPN po aktualizacji systemu przestaje działać, w terenie na LTE rozłącza, a audyt prosi o dowód, że dostęp jest zgodny z zasadą najmniejszych uprawnień i że MFA jest wymuszone dla zdalnego dostępu. Z jednej strony nikt nie chce wielkiego projektu, z drugiej – widać, że „tunel do sieci” robi się zbyt szerokim narzędziem.
1) Zrób uczciwą diagnozę VPN: gdzie model „tunel do sieci” pęka w 2026
Co nadal jest w VPN sensowne, a co robi się ryzykowne i kosztowne
VPN wciąż bywa dobrym rozwiązaniem, gdy masz małą liczbę użytkowników, przewidywalne zasoby i sprawną segmentację sieci. Problem zaczyna się, gdy VPN staje się domyślną ścieżką do wszystkiego – wtedy płacisz nie tylko licencjami, ale też czasem zespołu: aktualizacje klienta, certyfikaty, diagnostyka po stronie użytkownika, wyjątki dla różnych urządzeń.
Ryzyko bierze się z konstrukcji: VPN daje dostęp do sieci. Nawet jeśli starasz się ograniczać regułami, to nadal myślisz „podsiecami i portami”, a nie „użytkownik ma dostęp do konkretnej aplikacji i niczego więcej”. W realnym świecie to prowadzi do kompromisów: „dajmy mu jeszcze tę podsieć, bo nie działa”, „otwórzmy RDP, bo szybko”, „tymczasowo, na tydzień” – a potem zostaje na lata.
Koszty rosną też przez UX. Użytkownik nie ocenia bezpieczeństwa, tylko to, czy ma dostęp do narzędzi. Jeśli VPN rozłącza, spowalnia, wymaga restartów lub nie działa stabilnie na urządzeniach mobilnych, ludzie szukają obejść: wysyłają pliki prywatnym mailem, używają nieautoryzowanych chmur, trzymają dane lokalnie. To często gorsze niż „średnio skonfigurowany VPN”.
Konkretnie: co zwykle „widać” po VPN i dlaczego to komplikuje segmentację
Po zestawieniu tunelu użytkownik bardzo często dostaje (czasem nieświadomie) dostęp do elementów infrastruktury, które nie są mu potrzebne do pracy, ale są atrakcyjne dla atakującego po przejęciu konta/urządzenia:
Usługi katalogowe i DNS (np. dostęp do domeny/serwerów),
SMB / udziały plików i serwery plików,
RDP/SSH do serwerów lub stacji roboczych,
aplikacje „legacy”, które nie mają nowoczesnej autoryzacji,
panele administracyjne dostępne tylko „z wewnątrz”.
Nawet jeśli to wszystko jest „potrzebne komuś”, problem polega na tym, że VPN zwykle nie rozróżnia tego dobrze na poziomie pojedynczej aplikacji, a segmentacja bywa kosztowna w utrzymaniu: VLAN-y, ACL-e, reguły na firewallach, testy, wyjątki. W efekcie firmy wybierają prostotę: szeroki dostęp, bo „tak działa”.
Operacje i UX: klienci, certyfikaty, EDR i split tunneling
Utrzymanie VPN to często niedoszacowany „podatek”:
Klient VPN wymaga aktualizacji, bywa kapryśny na różnych wersjach OS, potrafi wchodzić w konflikt z agentami EDR lub politykami MDM.
Certyfikaty i ich cykl życia – wygasają w najmniej odpowiednim momencie, a odnowienie bywa procesem ręcznym.
Split tunneling to kompromis: poprawiasz wydajność (SaaS idzie „prosto do internetu”), ale tracisz spójność kontroli i widoczność ruchu, jeśli nie masz innych mechanizmów ochrony.
Mobilność: LTE, hotspoty, roaming – tunel potrafi „rwać” i użytkownik znów szuka obejść.
Jeśli Twoim celem jest bezpieczny dostęp do zasobów firmowych, to pytanie brzmi: czy chcesz dalej „naprawiać tunel”, czy zmienić model tak, aby użytkownik dostawał dostęp do aplikacji w sposób bardziej odporny na warunki sieciowe i z mniejszą liczbą wyjątków.
Szybki krok na start: spis 10 zasobów i 3 atrybuty, które od razu porządkują temat
Zbierz listę 10 najczęściej używanych zasobów przez VPN (aplikacje, serwery, udziały). Przy każdym dopisz:
kto (grupa/rola),
z czego (firmowy laptop, BYOD, urządzenie mobilne),
jakim protokołem (HTTP/S, RDP, SMB, SSH, „gruby klient”).
To ćwiczenie zwykle ujawnia dwa fakty: (1) część dostępu da się przenieść na model per‑app (ZTNA) niemal od ręki, (2) największy bałagan siedzi w „legacy + SMB + RDP” i to tam trzeba planować etapowanie.
2) Ustal, czego naprawdę potrzebujesz: ZTNA jako „per‑app”, SASE jako „pakiet kontrolny”
Definicje, które pomagają w decyzji (i nie brzmią jak folder sprzedażowy)
ZTNA (Zero Trust Network Access) to model dostępu, w którym użytkownik dostaje połączenie nie „do sieci”, tylko do konkretnej aplikacji – na podstawie tożsamości i kontekstu. Kontekst to m.in. stan urządzenia (posture), lokalizacja, ryzyko logowania, typ aplikacji, a czasem też zachowanie (np. nietypowa pora).
SASE (Secure Access Service Edge) to podejście, w którym funkcje sieci i bezpieczeństwa dostarczane są jako usługa, zwykle blisko użytkownika (punkty obecności dostawcy). W praktyce SASE łączy pod jednym „parasolem” elementy takie jak ZTNA, SWG (Secure Web Gateway), CASB (Cloud Access Security Broker), DLP (Data Loss Prevention) oraz często komponenty łączności typu SD‑WAN.
Różnica decyzyjna jest prosta: ZTNA odpowiada na pytanie „jak dać dostęp do aplikacji bez tunelu do sieci”, a SASE na pytanie „jak ujednolicić polityki dla internetu, SaaS i aplikacji firmowych oraz mieć spójne logi i kontrolę”.
ZTNA vs VPN: realna korzyść i realne ograniczenia
Najbardziej odczuwalna korzyść ZTNA to ograniczenie „zasięgu błędu”. Jeśli konto zostanie przejęte albo laptop zostanie zainfekowany, dostęp jest zawężony do aplikacji, a nie do całych segmentów sieci. To nie jest magiczna tarcza, ale praktycznie utrudnia rozprzestrzenianie się problemu.
Ograniczenie: ZTNA nie rozwiązuje wszystkiego. Jeśli masz dużo protokołów niewebowych (SMB, RDP do wielu hostów, grube klienty do ERP), migracja bywa trudniejsza i może wymagać łączników/proxy, jump hostów, przebudowy sposobu publikacji aplikacji albo przynajmniej uporządkowania tego, co jest „naprawdę potrzebne”.
Kiedy samo ZTNA ma sens, a kiedy dopiero SASE daje efekt skali
Samo ZTNA często wystarcza na start, gdy:
chcesz ogarnąć dostęp do 1–5 aplikacji (np. intranet, panel HR, aplikacja do faktur),
masz presję na lepsze MFA i kontrolę urządzeń dla zdalnych użytkowników,
nie chcesz teraz mieszać w całej architekturze sieci i politykach ruchu internetowego.
SASE daje większą wartość, gdy widzisz typowy chaos: ruch do SaaS idzie raz bezpośrednio, raz przez VPN, raz przez proxy w biurze, a polityki są porozrzucane w kilku miejscach. Wtedy spójność polityk (np. blokady, kategorie stron, kontrola uploadu do prywatnych dysków, DLP dla wybranych danych) bywa warta tego, żeby „zebrać klocki” w jedną usługę.
Szybki krok na start: trzy strumienie ruchu i mapa luk w politykach
Rozpisz ruch użytkowników na trzy kubełki:
internet ogólny (przeglądanie, aktualizacje, narzędzia),
SaaS (M365, CRM, projekty, repozytoria),
zasoby firmowe (on‑prem i chmura prywatna, aplikacje wewnętrzne).
Przy każdym dopisz: gdzie jest egzekwowana polityka (jeśli w ogóle). Jeśli odpowiedź brzmi „w biurze na firewallu, a poza biurem różnie”, to jest klasyczny argument za modelem SASE albo przynajmniej za etapem pośrednim (ZTNA + kontrola wyjścia do internetu dla zdalnych).
3) Zacznij od tożsamości, bo bez niej SASE/ZTNA będzie protezą (i kosztem)
Minimalny zestaw „identity ready” dla MŚP
Zero Trust bez porządnej tożsamości kończy się wyjątkami. A wyjątki są drogie, bo ktoś musi je zatwierdzać, opisywać, logować, utrzymywać i tłumaczyć. Minimum, które pozwala ruszyć sensownie:
Centralny IdP (jeden punkt logowania i egzekwowania zasad),
MFA wymuszone dla zdalnego dostępu i paneli administracyjnych,
Role/grupy oparte o funkcje biznesowe, nie o „kto krzyczy najgłośniej”,
Lifecycle kont: onboarding i offboarding (kto zakłada, kto odbiera dostęp, w jakim czasie),
Podstawowe logowanie zdarzeń logowania i odmów dostępu.
Jeśli dziś VPN opiera się na lokalnych kontach, współdzielonych użytkownikach albo „adminach na skróty”, to inwestycja w ZTNA/SASE bez poprawy tożsamości prawie zawsze wyjdzie drożej niż planujesz. Nie dlatego, że technologia jest zła, tylko dlatego, że będziesz łatać procesy licencją.
Kontraktorzy i konta współdzielone: najczęstszy sabotaż dla podejścia Zero Trust
W wielu firmach „zewnętrzni” dostają VPN, bo to najszybsze. Potem zostają na lata, bo nikt nie ma czasu sprzątać. W modelu ZTNA/SASE to nadal możliwe, ale wymaga dyscypliny:
Konta imienne zamiast współdzielonych,
„`html
Konta imienne zamiast współdzielonych,
Dostęp czasowy (konto z datą wygaśnięcia lub automatyczne wyłączenie po zakończeniu zlecenia),
Osobne grupy dla kontraktorów (łatwiej odebrać uprawnienia „hurtowo” i nie mieszać polityk),
Minimalny zakres: tylko aplikacje i tylko role potrzebne do zadania, bez „wejścia do całej podsieci”,
Ślad audytowy: logi dostępu + przypięty właściciel biznesowy, który akceptuje ryzyko i zakres.
Największy problem z kontami współdzielonymi nie jest techniczny, tylko operacyjny: nie wiesz, kto zrobił zmianę, kto wyniósł dane i komu odebrać dostęp. ZTNA/SASE potrafi to ograniczyć, bo łatwiej „zapiąć” dostęp na konkretną aplikację i konkretną tożsamość. Ale jeśli dalej zostawisz jedno konto „vendor/vendor”, to cały model Zero Trust jest tylko nową etykietą na starej praktyce.
Budżetowa wersja porządkowania: zacznij od dwóch typów ról dla zewnętrznych — „read-only” i „ops”. Do tego prosta zasada: bez MFA nie ma dostępu, a bez właściciela biznesowego nie ma wyjątku. Taki zestaw zwykle wystarcza, żeby przestać gasić pożary po weekendzie, gdy „ktoś się zalogował, ale nie wiadomo kto”.
Jeśli masz integratora, który co chwilę prosi o VPN „na pół godziny”, to ZTNA z dostępem per‑app i krótkim TTL (czasem życia sesji) zmniejsza tarcie. W praktyce wygląda to tak: dostaje link/portal do jednej aplikacji lub jednego jump hosta, a reszta jest poza zasięgiem. Działa nawet wtedy, gdy po stronie firmy nikt nie chce otwierać kolejnych tras i wyjątków na firewallu.
Druga typowa sytuacja: wsparcie do systemu finansowego „musi wejść na serwer” i wszyscy idą na skróty przez RDP po VPN. Tu często wygrywa etap pośredni: najpierw wstaw jump host z MFA i logowaniem sesji, a dopiero później myśl o pełnym per‑app do pojedynczych hostów. Efekt koszt/korzyść jest lepszy niż heroiczna migracja wszystkiego naraz.
4) Ustal warunki dostępu na poziomie urządzenia: mniej haseł, więcej kontekstu
Posture check bez polowania na ideał: 5 sygnałów, które realnie robią różnicę
Warunki dostępu oparte o urządzenie nie muszą być od razu „pełnym NAC”. Na start liczy się kilka sygnałów, które da się egzekwować bez wielomiesięcznego projektu:
Urządzenie zarządzane (MDM/Intune/Jamf lub inny mechanizm, który potrafi potwierdzić własność i polityki).
Szyfrowanie dysku włączone i raportowane.
Stan EDR/AV: agent działa, nie jest wyłączony, definicje aktualne.
Ryzyko logowania po stronie IdP (nietypowa lokalizacja, niemożliwy travel, podejrzane urządzenie).
To zestaw, który daje szybkie „odcięcie” oczywistych ryzyk. Bez niego ZTNA zamieni się w kolejną bramkę, którą i tak trzeba otwierać wyjątkami, bo BYOD, bo „w delegacji”, bo „nie działa agent”.
Różne aplikacje, różne progi: zasada dwóch poziomów
Nie każda aplikacja ma ten sam koszt błędu. Dla intranetu czy wiki często wystarczy „IdP + MFA”. Dla finansów, HR, paneli admina i RDP sensowny jest poziom wyżej: MFA + urządzenie zarządzane + zdrowe posture. Dwa progi robią robotę, bo nie blokujesz całej firmy przez jeden problem z agentem, a jednocześnie nie udajesz, że system księgowy jest „jak każda strona”.
„`html
5) Zbuduj MVP SASE bez przepalania budżetu: wybierz elementy, które dadzą efekt w 90 dni
Najpierw wybierz „jeden bolesny” use-case, a nie cały SASE naraz
Jeśli próbujesz wdrożyć ZTNA, SWG, CASB, DLP i do tego przepiąć cały ruch oddziałów, to w praktyce robisz program transformacji, nie „modernizację VPN”. Szybsza ścieżka decyzyjna to MVP oparte o jeden problem, który dziś generuje koszty albo ryzyko:
Chaotyczny dostęp do aplikacji wewnętrznych (VPN daje za szeroki dostęp, brakuje segmentacji).
Ruch do SaaS bez spójnych zasad (upload do prywatnych dysków, brak kontroli nad Shadow IT).
Słaba obserwowalność (nie wiesz, kto i skąd wchodzi, a incydent zaczyna się od „nie mamy logów”).
Przykład praktyczny: jeśli największy ból to „RDP po VPN do wszystkiego”, to MVP może być proste: ZTNA + jeden jump host z MFA i nagrywaniem/logowaniem sesji. To często daje większy efekt niż ambitne „zrobimy SASE dla całej firmy”, które kończy się wyjątkami.
Minimalny zestaw funkcji, który zwykle działa: ZTNA + SWG (a CASB/DLP etapami)
Dla wielu MŚP sensowna kolejność to: najpierw ograniczyć dostęp do aplikacji (ZTNA), a potem ujednolicić wyjście do internetu i SaaS (SWG). CASB i DLP potrafią być bardzo wartościowe, ale wymagają porządku w danych i procesach — inaczej generują alerty, których nikt nie obsłuży.
ZTNA: dostęp per‑app, polityki na podstawie tożsamości i urządzenia, krótsze sesje.
SWG: kategorie stron, blokady ryzykownych usług, ochrona przed phishingiem na poziomie ruchu www.
CASB (etap 2): kontrola użycia SaaS (np. ograniczenie logowania do tenantów firmowych, wykrywanie nieautoryzowanych aplikacji).
DLP (etap 2/3): dopiero gdy wiesz, jakie dane chcesz chronić i gdzie realnie wypływają.
Budżetowa heurystyka: jeśli dziś nie masz nawet prostego podziału danych (np. „publiczne/wewnętrzne/poufne”), to DLP kupione „na zapas” będzie głównie kosztem wdrożenia i utrzymania polityk.
Polityki „dwóch kliknięć”: 3 zasady, które dają efekt, a nie paraliż
Najczęstsza pułapka na starcie to próba opisania całego świata politykami. Lepiej zacząć od kilku zasad, które realnie zmniejszają ryzyko i nie wymagają wojny z biznesem:
Blokuj logowanie do prywatnych tenantów w kluczowych usługach (np. dopuszczaj tylko logowanie do firmowego M365/Google Workspace). Praktyczny sens: mniej wycieków przez „wrzucę na swój dysk, bo szybciej”.
Ogranicz upload z urządzeń niezarządzanych do wybranych kategorii (dyski w chmurze, webmail, paste‑biny). Przykład: na laptopie firmowym upload działa normalnie, na BYOD tylko do zatwierdzonych aplikacji.
Wymuś „wyższy próg” dla aplikacji wrażliwych (finanse/HR/admin): MFA + device posture + krótsza sesja. Efekt: atak na hasło nie daje automatycznie pełnego dostępu.
6) Migracja bez „big bang”: podmień VPN tam, gdzie boli najbardziej
Mapa aplikacji w 2 godziny: trzy kategorie zamiast inwentaryzacji idealnej
Pełna CMDB to luksus. Do decyzji „czy i jak migrować” wystarczy szybka mapa aplikacji, podzielona na trzy koszyki:
Webowe i gotowe (intranet, panele, aplikacje http/https) — najlepsze do pierwszych wdrożeń ZTNA.
„Da się, ale trzeba obejść” (RDP/SSH, pojedyncze serwery, adminowanie) — zwykle przez jump host lub kontrolowany proxy.
Legacy i ciężkie (SMB, grube klienty, wiele zależności sieciowych) — kandydaci na później albo na przebudowę sposobu dostępu.
To podejście od razu pokazuje, czy temat jest na tydzień, czy na kwartały. Jeśli 80% dostępu to SMB i „widzę całą sieć”, to ZTNA nadal ma sens, ale ścieżka startu będzie inna (częściej od segmentacji i jump hostów niż od „publikacji aplikacji webowych”).
Równoległe działanie: zostaw VPN jako plan awaryjny, ale ogranicz jego zasięg
Przy migracji etapowej VPN często musi chwilę zostać — dla pojedynczych przypadków, awarii albo aplikacji, których nie ruszasz w pierwszym etapie. Klucz to nie utrzymywać „starego świata” bez zmian:
Ogranicz trasy w VPN do niezbędnych segmentów (mniej lateral movement, mniej „wszędzie da się wejść”).
Rozdziel profile: osobny profil VPN dla adminów, osobny dla „legacy‑access”, bez mieszania z codzienną pracą.
Włącz wymuszony MFA i krótsze sesje także na VPN, jeśli jeszcze go używasz.
Praktyczny efekt: nawet jeśli VPN zostaje na 10–20% przypadków, nie jest już „złotym kluczem” do całej sieci.
Pilotaż, który ma sens: 20 użytkowników i jedna aplikacja krytyczna
Pilotaż działa tylko wtedy, gdy dotyka czegoś ważnego. „Dajmy ZTNA do testowego intranetu” kończy się wnioskiem, że „wszystko działa”, ale nic nie zmienia. Lepszy zestaw:
Jedna aplikacja krytyczna (np. system finansowy, panel administracyjny) + wysoki próg dostępu.
Jedna aplikacja codzienna (np. intranet/CRM) + niższy próg dostępu.
Grupa mieszana: kilka osób z biura, kilka zdalnie, 2–3 „power userów” i 1–2 osoby z IT.
Po tygodniu masz realne odpowiedzi: gdzie pęka UX, czy polityki urządzeń są gotowe, jak wygląda support, ile jest wyjątków.
7) Policz TCO uczciwie: licencja to zwykle mniejszy problem niż operacje
Pięć kosztów, które najczęściej są pomijane
Przy porównaniu „VPN vs ZTNA/SASE” łatwo wpaść w pułapkę samej ceny per user. Całkowity koszt wychodzi z rzeczy, które w budżecie nie wyglądają jak „produkt bezpieczeństwa”:
Czas zespołu IT na reguły, wyjątki, testy i wsparcie użytkowników.
Porządkowanie tożsamości (grupy, role, offboarding) — jeśli tego nie zrobisz, zapłacisz wyjątkami.
Endpoint management (MDM/EDR) — czasem już jest, tylko nie jest egzekwowany konsekwentnie.
Obsługa incydentów i dochodzenia (logi, korelacja, retencja) — spójne logowanie bywa „ukrytym ROI”.
Szkolenie i komunikacja (co się zmienia, jak się logować, co robić w podróży).
Kryterium „czy to się spina”: mniej wyjątków i mniej „pełnego tunelu”
Jeśli po wdrożeniu nadal masz:
wiele kont współdzielonych,
dużo stałych wyjątków „bo inaczej nie działa”,
tunel do sieci jako domyślny sposób pracy,
to prawdopodobnie kupiłeś nową bramkę, a nie zmieniłeś model dostępu. Z kolei jeśli większość użytkowników przestaje „wchodzić do sieci”, a zaczyna „wchodzić do aplikacji”, koszty operacyjne zwykle spadają: mniej zgłoszeń o VPN, mniej problemów z trasami i split tunnelingiem, łatwiejsze audyty.
8) Sprawdź, czy dostawca nie sprzedaje „SASE z nazwy”: pytania weryfikujące bez slajdów
Osiem pytań, które szybko obnażają marketing
Nie trzeba być architektem, żeby odsiać „ładnie nazwane VPN w chmurze” od sensownego podejścia. Te pytania są proste, a odpowiedzi zwykle mówią wszystko:
Czy polityki są wspólne dla ZTNA i ruchu internetowego (SWG), czy to dwa osobne panele i dwa modele reguł?
Jak wygląda egzekwowanie posture (MDM/EDR/OS) i czy działa dla różnych systemów (Windows/macOS) bez ręcznej akrobatyki?
Czy da się zrobić per‑app dla aplikacji nie-webowych (np. SSH/RDP) i jak jest realizowany dostęp (agent, proxy, jump)?
Co z logami: jeden strumień zdarzeń, sensowna retencja, eksport do SIEM, korelacja tożsamości?
Jak działa segmentacja po zestawieniu dostępu: czy użytkownik widzi sieć, czy tylko aplikacje?
Jaki jest plan awaryjny (fallback), gdy usługa ma problem: czy możesz bezpiecznie utrzymać minimalny dostęp?
Gdzie są punkty egzekwowania (PoP) i czy masz je blisko użytkowników (opóźnienia w praktyce, nie na mapie)?
Jak licencjonowane są wyjątki: konta gościnne, kontraktorzy, urządzenia współdzielone, konta serwisowe.
Mały test jakości: „pokaż odmowę” zamiast „pokaż sukces”
Na demo wszystko działa, bo polityki są łagodne. Poproś o scenariusz odmowy:
użytkownik z poprawnym MFA, ale urządzenie niezarządzane próbuje wejść do aplikacji HR,
kontraktor z ważnym kontem próbuje wejść po dacie wygaśnięcia,
użytkownik próbuje uploadować plik do nieautoryzowanego dysku.
Jeśli odmowy są czytelne, zrozumiałe dla użytkownika i dobrze zalogowane, to jest dobry znak. Jeśli kończy się na „to trzeba dopisać skryptem” albo „nasz partner to skonfiguruje”, licz się z kosztami operacyjnymi.
9) Ustal „twarde” kryteria dostępu: kto, skąd, na jakim urządzeniu i do czego
Czy ZTNA/SASE ma sens w Twojej firmie, widać po tym, czy da się opisać dostęp w prostych warunkach. Jeśli wszystko kończy się na „wszyscy potrzebują wszystkiego”, to problem nie jest w technologii — tylko w braku reguł.
Cztery wymiary polityki, które zastępują 200 wyjątków
Zamiast pisać osobne reguły dla każdej aplikacji, zacznij od czterech osi. Dają szybki efekt i są zrozumiałe dla audytu:
Tożsamość: rola/grupa, a nie „login Kowalskiego”. Przykład: „Finanse” ma dostęp do ERP, „Sprzedaż” do CRM.
Kontekst urządzenia: zarządzane vs niezarządzane, EDR aktywny, szyfrowanie dysku. Praktyczny sens: ten sam użytkownik dostaje inny poziom dostępu na laptopie służbowym i na prywatnym.
Lokalizacja / ryzyko: kraj, adresy IP, nietypowe logowania, brak zgodności z MFA. Przykład: logowanie z nowego kraju = wymuszenie ponownego MFA i krótsza sesja.
Wrażliwość aplikacji: „codzienna” vs „administracyjna” vs „dane poufne”. Efekt: admin i HR nie działają na tych samych zasadach co intranet.
Minimalny model „3 poziomów” zamiast architektury idealnej
Jeśli chcesz ruszyć w 30 dni, nie projektuj tak, jakbyś miał SOC i dedykowany zespół IAM. Wystarczy prosty podział na trzy poziomy:
Poziom A (niski próg): aplikacje codzienne, mniej ryzykowne — SSO + podstawowe warunki, dłuższa sesja.
Poziom B (średni próg): systemy z danymi firmowymi — MFA + urządzenie zgodne (posture), sensowne limity sesji.
Poziom C (wysoki próg): HR/finanse/admin — MFA „silne”, urządzenie zarządzane, restrykcyjna sesja, często też blokady uploadu/clipboard.
To wystarcza, żeby odróżnić „wygodę” od „dostępu do koronnych klejnotów” bez dłubania w setkach reguł.
10) Nie wdrażaj ZTNA w próżni: przygotuj aplikacje i ścieżki dostępu
ZTNA nie naprawi aplikacji, które od lat działały „bo VPN dawał sieć”. Kilka prostych porządków zwykle oszczędza tygodni frustracji.
Oddziel dostęp użytkownika od dostępu administracyjnego
Najwięcej ryzyka (i później kosztów) bierze się z mieszania pracy zwykłej z administracją:
Użytkownicy powinni dostawać dostęp do aplikacji, nie do podsieci.
Admini potrzebują często protokołów (SSH/RDP) — tu lepiej działa model „kontrolowany punkt wejścia”.
Przykład praktyczny: zamiast dawać adminom pełen VPN „bo łatwiej”, ustawiasz jump host (lub broker) i wymuszasz logowanie admina tylko przez niego. Audyt nagle staje się prostszy, a lateral movement trudniejszy.
Zaplanuj „trudne protokoły” zanim obiecasz termin
Nie wszystkie zasoby pasują do pierwszej fali. Dwie pułapki, które regularnie wywracają harmonogram:
SMB/udziały sieciowe: zależności, mapowane dyski, „widoczność sieci” — zwykle wymagają segmentacji, czasem modernizacji podejścia (np. przeniesienia danych do systemu plików w chmurze lub ograniczeń na poziomie urządzeń).
Grube klienty i aplikacje „gadatliwe” po wielu portach: często działają, ale wymagają starannego zdefiniowania aplikacji i testów wydajności.
Jeśli 1–2 takie przypadki trzymasz na VPN jeszcze przez jakiś czas, to nie porażka — pod warunkiem, że reszta ruchu faktycznie z VPN znika.
11) Zadbaj o logi i odpowiedzialność: inaczej „Zero Trust” będzie tylko hasłem
W praktyce bezpieczeństwo kończy się tam, gdzie nie wiadomo: kto dostał dostęp, do czego, na jak długo i dlaczego. SASE/ZTNA może to uporządkować, ale trzeba tego świadomie dopilnować.
Dwa strumienie zdarzeń, które muszą być czytelne
Zdjęcie decyzji dostępowej: kto/rola, aplikacja, wynik (allow/deny), powód (np. posture niespełniony), czas.
Aktywność po dostępie: podstawowe zdarzenia sesji (start/stop), a dla wybranych usług — kategorie (upload, pobranie, nietypowa aktywność).
Praktyczny sens: przy incydencie nie odtwarzasz świata z pamięci i screenów z helpdesku, tylko masz jasny ślad „dlaczego przepuściło” albo „dlaczego zablokowało”.
Właściciel polityk: jedno miejsce, jedna decyzja
W małych i średnich firmach koszt rośnie, gdy polityki są „niczyje” i każdy wyjątek trafia do IT jako bilet na wieczne utrzymanie. Prosty układ działa lepiej:
IT utrzymuje mechanikę (integracje, agent, dostępność).
Właściciele aplikacji (np. HR/finanse) akceptują progi dostępu i wyjątki biznesowe.
12) Zrób „decyzję w 30 dni”: krótka lista kontrolna do zielonego światła
Da się szybko ocenić, czy migracja ma sens, bez przetargu na rok. Ta checklista jest celowo krótka: ma dać decyzję, a nie idealną dokumentację.
Lista kontrolna: jeśli 8/12 jest „tak”, start ma sens
Masz (lub możesz mieć w tydzień) IdP + MFA dla wszystkich kluczowych użytkowników.
Potrafisz wskazać 3–5 aplikacji webowych, które dziś idą przez VPN.
Masz podstawowy podział na aplikacje zwykłe vs wrażliwe (choćby poziomy A/B/C).
Wiesz, kto jest właścicielem tych aplikacji (kto zatwierdzi reguły).
Masz przynajmniej jeden mechanizm posture (MDM lub EDR) dla laptopów firmowych.
Potrafisz wydzielić grupę 20 użytkowników do pilotażu (w tym 2–3 trudnych).
Masz zgodę na to, że VPN zostaje tymczasowo tylko dla „legacy-access”, a nie jako standard.
Jesteś w stanie ustawić blokady oczywistych nadużyć (np. prywatne tenantie, upload z BYOD do wybranych kategorii).
Masz gdzie wysyłać logi (nawet prosty syslog/SIEM/log management), a nie tylko „w konsoli dostawcy”.
Jesteś gotów uzgodnić czas życia sesji i odświeżanie dostępu dla aplikacji wrażliwych.
Masz plan na dostęp administracyjny (jump host/proxy/broker) zamiast „admin na pełnym tunelu”.
Umiesz nazwać 2 metryki sukcesu pilotażu (np. spadek użycia VPN, liczba zgłoszeń, czas dostępu, liczba wyjątków).
Następny rozsądny krok: jedna decyzja budżetowa i jeden use-case
Jeśli checklista wygląda dobrze, najtańszy ruch to nie „kupmy pełne SASE”, tylko wybór jednego scenariusza, który realnie odciąży VPN:
Use-case #1: dostęp do wybranej aplikacji krytycznej przez ZTNA (poziom C) dla pilotażu.
Use-case #2: podstawowy SWG dla ruchu web z minimalnymi politykami (blok prywatnych tenantów + kontrola uploadu z BYOD).
To daje twardą odpowiedź, czy firma zyskuje na modelu „dostęp do aplikacji”, czy nadal jest skazana na „tunel do sieci” — i ile kosztuje zejście z tego przyzwyczajenia.
