Przewodnik zakupowy ZTNA i SSE

czym te rzeczy naprawdę są

Skróty ukrywają proste idee. ZTNA daje użytkownikowi dostęp do konkretnej aplikacji, po sprawdzeniu jego tożsamości i stanu bezpieczeństwa urządzenia, bez wpuszczania go do sieci: jeśli ma uprawnienia do aplikacji finansowej, dociera do aplikacji finansowej i nic więcej nawet nie jest widoczne, a korzyść dla bezpieczeństwa jest duża, bo skompromitowany użytkownik albo urządzenie nie może poruszać się po sieci wewnętrznej, której po prostu tam nie ma do poruszania się. SWG, secure web gateway, sprawdza i filtruje wychodzący ruch webowy, blokując złośliwe strony i egzekwując politykę akceptowalnego użycia. CASB, cloud access security broker, daje widoczność i kontrolę nad aplikacjami SaaS, z których korzystają ludzie, częściowo pokrywając się z SaaS governance. FWaaS, firewall-as-a-service, dostarcza funkcję firewalla z chmury zamiast ze skrzynki w twoim biurze. SSE, security service edge, to pakiet: ZTNA plus SWG plus CASB i często więcej, dostarczane razem z chmury. SASE to SSE plus warstwa sieciowa, SD-WAN, łącząca bezpieczeństwo i sieć rozległą w jedną rzecz dostarczaną z chmury, co wciąga do gry zespół sieciowy. Wzorzec, który warto zapamiętać: ZTNA to decyzja o dostępie, SSE to pakiet zabezpieczeń wokół niej, SASE dokłada sieć, a kupić można samo pierwsze.

gdzie kupujący popełniają błędy

Pierwszy błąd to myślenie, że ZTNA oznacza gotowy zero trust. ZTNA to jeden z przejawów zero trust, część dotycząca dostępu sieciowego, i to wartościowa, ale nie obejmuje zarządzania tożsamością, rozrostu SaaS, tożsamości maszynowych ani danych, więc kupno ZTNA i ogłoszenie zero trust za osiągnięte zostawia większość modelu niezbudowaną. Drugi to kupno platformy, gdy potrzebne było pojedyncze narzędzie: presja na zakup pełnego pakietu SSE albo SASE jest silna, bo właśnie to dostawcy chcą sprzedać, ale jeśli twoim realnym problemem jest uciążliwy VPN i zespół pracujący głównie z chmury, samo ZTNA może być właściwym zakresem. Trzeci to założenie o agencie: wiele narzędzi ZTNA wymaga oprogramowania zainstalowanego na urządzeniu użytkownika, co jest w porządku dla pracowników na zarządzanych laptopach, a problemem dla kontraktorów i partnerów na urządzeniach, których nie kontrolujesz, więc jeśli spora część dostępu pochodzi z niezarządzanych urządzeń, dostęp bezagentowy albo przez przeglądarkę staje się wymogiem podstawowym. Czwarty to ignorowanie wydajności i tego, gdzie znajduje się infrastruktura dostawcy, bo ZTNA i SSE kierują ruch przez punkty obecności dostawcy, a jeśli są one daleko od twoich użytkowników, wszystko wydaje się wolne, co dla europejskiej firmy jest jednocześnie kwestią wydajności i zgodności. Piąty, cichszy błąd to nierozstrzygnięcie, kto za to odpowiada, bo ZTNA, a zwłaszcza SASE, leżą na styku bezpieczeństwa i sieci, a zakup, którego nikt jasno nie posiada, zwykle utyka. Pod tym wszystkim leży warunek wstępny: nie zaprojektujesz dostępu, którego nie widzisz.

zanim zaczniesz kupować: zmapuj swój dostęp

Zacznij od tego, do czego ludzie faktycznie muszą mieć dostęp. Wypisz aplikacje, które obecnie wymagają dostępu zdalnego, gdzie żyją (twoje własne centrum danych, chmura, którą zarządzasz, czy SaaS) i kto ich potrzebuje. Ten podział ma znaczenie, bo firma, której wszystkie aplikacje są w SaaS, ma dużo lżejszy problem niż firma z krytycznymi aplikacjami w lokalnym centrum danych, do którego dociera VPN. Potem scharakteryzuj sam dostęp: ile z niego to pracownicy na zarządzanych laptopach, a ile to kontraktorzy, partnerzy i osoby na niezarządzanych lub prywatnych urządzeniach, bo ta proporcja decyduje o pytaniu agent kontra bez agenta bardziej niż cokolwiek innego. Potem bądź szczery co do zakresu: zastąpienie VPN to skoncentrowany projekt, podczas gdy szersze przejście do połączonego bezpieczeństwa i sieci to wieloletnie zobowiązanie platformowe, które dotyka zespołu sieciowego, a mylenie tych dwóch rzeczy to sposób, w jaki firmy kupują więcej, niż potrzebują.

co pasuje do twojej wielkości i sytuacji

Dla szczupłej lub małej firmy poniżej około 50 osób, jeśli twoje aplikacje to głównie SaaS, możesz potrzebować bardzo niewiele: single sign-on plus dostęp warunkowy pokrywają dużo, skoncentrowane ZTNA obsłuży kilka aplikacji prywatnych, a twój IdP lub chmura mogą już zawierać proxy aplikacji. Pomiń pełną platformę SSE czy SASE, to zdecydowanie za dużo jak na ten problem. Dla rosnącego mid-marketu 50 do 500 osób: ZTNA zastępujące VPN dla dostępu do aplikacji prywatnych, oparte na tożsamości i urządzeniu, z opcjami bezagentowymi dla kontraktorów, plus secure web gateway lub kontrola chmury tylko tam, gdzie masz konkretną potrzebę. Pomiń kupowanie całego pakietu, żeby rozwiązać problem VPN. Dla większej firmy lub firmy z wieloma podmiotami, 500 do 2000 osób, platforma SSE zaczyna mieć sens, jeśli naprawdę potrzebujesz połączonego bezpieczeństwa web, chmury i aplikacji prywatnych, gdzie stan urządzenia zasila decyzje o dostępie. Pomiń sytuację, w której rozrost pakietu dokłada moduły, których nie będziesz obsługiwać. Dla przedsiębiorstwa lub biznesu z wieloma lokalizacjami powyżej 2000 osób, pełne SASE może być uzasadnione, gdy łączysz bezpieczeństwo i sieć w wielu lokalizacjach i globalnym zespole. Pomiń platformę, której punkty obecności zostawiają część użytkowników ze słabą wydajnością.

Kilka sytuacji zmienia odpowiedź niezależnie od wielkości firmy. Duży udział dostępu kontraktorów i stron trzecich: ZTNA jest tu naprawdę świetne, dając zewnętrznej stronie dostęp do jednej aplikacji na podstawie tożsamości i urządzenia, bez VPN, więc mocno postaw na bezagentowe ZTNA. Głównie SaaS, tylko chmura: możesz potrzebować bardzo mało ZTNA, a większość pracy wykonają single sign-on i dostęp warunkowy. Istotne aplikacje lokalne: zdolność ZTNA do bezpiecznego publikowania ich to sedno wartości, więc dokładnie te aplikacje testuj w każdym pilotażu. Oddziały i rozproszona sieć: to tutaj konwergencja sieciowa SASE zarabia na siebie i rozmowa uzasadnienie poszerza się o świat zespołu sieciowego.

sourcing: cztery drogi do celu

Wykorzystaj to, co już zawiera twój IdP i chmura: dla firmy mocno opartej na SaaS single sign-on plus dostęp warunkowy oraz proxy aplikacji, które twój IdP lub chmura mogą już oferować, potrafią pokryć zaskakująco dużo bez dedykowanego produktu ZTNA, więc sprawdź to najpierw. Kup skoncentrowane ZTNA: właściwy zakres dla wielu firm, zastępujący VPN, bezpiecznie publikujący aplikacje prywatne, wspierający dostęp bezagentowy dla kontraktorów, i kończący się tam, dopóki nie pojawi się powód, żeby dodać więcej. To często ruch o najwyższej wartości i najmniejszym ryzyku żalu. Kup platformę SSE: uzasadnione, gdy naprawdę potrzebujesz połączonego bezpieczeństwa aplikacji prywatnych, web i chmury w jednym miejscu i masz zespół, który to obsłuży. Idź w stronę SASE albo weź pomoc z zewnątrz: pełne SASE to większe zobowiązanie, najlepiej podejmowane razem z zespołem sieciowym i często z pomocą z zewnątrz, a wdrożenie współzarządzane lub prowadzone przez doradcę, przez MSSP lub VAR, pasuje też do typowego przypadku czystego zastąpienia VPN bez blokowania ludzi w trakcie przejścia.

kryteria decyzyjne, które naprawdę się liczą

Pokrycie aplikacji: czy obsługuje wszystkie twoje aplikacje, webowe i niewebowe, nowoczesne i legacy, SaaS i te w twoim własnym centrum danych, testowane na twojej najtrudniejszej aplikacji, a nie na najłatwiejszej? Dostęp bezagentowy: czy daje dostęp z niezarządzanych i prywatnych urządzeń przez przeglądarkę, czy działa tylko z agentem? Integracja z tożsamością i urządzeniem: czy czysto wiąże dostęp z twoim dostawcą tożsamości i odczytuje stan bezpieczeństwa urządzenia? Wydajność i punkty obecności: gdzie znajduje się infrastruktura dostawcy i czy twoi użytkownicy, zwłaszcza w Europie, dostaną dobrą wydajność zamiast opóźnień na poziomie VPN? Dopasowanie pakietu: czy kupujesz tylko to, czego potrzebujesz, czy platformę, której dodatkowych modułów faktycznie użyjesz? Migracja z VPN: jak narzędzie wspiera etapowe wygaszanie VPN bez destrukcyjnego cięcia? Rezydencja danych i UE: czy ruch i metadane zostają w UE? Własność i obsługa: czy jasno wiadomo, kto to prowadzi, i czy pasuje to do danego zespołu? Jeśli miałbyś wybrać jedno kryterium, wybierz pokrycie aplikacji testowane na twoich realnych aplikacjach, zwłaszcza tych niewygodnych, lokalnych, bo ZTNA, które radzi sobie z łatwymi aplikacjami webowymi, a dławi się na krytycznym systemie legacy, w ogóle nie zastąpiło twojego VPN.

jak to jest wyceniane i ile to naprawdę kosztuje

ZTNA i SSE zwykle wycenia się na użytkownika miesięcznie, przy czym SSE, a zwłaszcza SASE, kosztuje więcej wraz z dodawaniem modułów i sieci. Pokusa, i interes dostawcy, to sprzedać cały pakiet, więc wyceniaj względem zakresu, który faktycznie wykorzystasz, a nie platformy, w którą możesz kiedyś dorosnąć. Licencja rzadko jest całym kosztem: zaplanuj budżet na migrację z VPN, która jest prawdziwym projektem i tam idzie wysiłek pierwszego roku; publikowanie aplikacji, bo podłączenie każdej aplikacji prywatnej, zwłaszcza legacy, wymaga pracy, a łączniki trzeba wdrożyć i utrzymywać; rozrost pakietu, gdzie włączane i rozliczane są moduły, których nie potrzebujesz; oraz sieć, w przypadku SASE, która sama w sobie jest kosztem i projektem. Myśl w kategoriach całkowitego kosztu w perspektywie kilku lat dla zakresu, który naprawdę będziesz prowadzić, a argument za zaczęciem od skoncentrowanego ZTNA zamiast pełnej platformy zwykle trzyma się dla każdego, czyim podstawowym problemem jest VPN.

jak przeprowadzić ewaluację

Zrób shortlistę względem swojego faktycznego zakresu, uwzględniając opcję oparcia się na istniejącym single sign-on i dostępie warunkowym, jeśli mocno korzystasz z SaaS, oraz skoncentrowane ZTNA kontra pełna platforma SSE. Zadaj pytania odkrywające zakres: czy możecie opublikować nasze konkretne aplikacje lokalne i legacy, nie tylko webowe; czy wspieracie dostęp bezagentowy dla kontraktorów na niezarządzanych urządzeniach; jak dostęp wiąże się z naszym dostawcą tożsamości i stanem urządzenia; gdzie są wasze punkty obecności i czy nasi europejscy użytkownicy dostaną dobrą wydajność przy danych pozostających w UE; jak wspieracie etapowe wygaszanie VPN? Potem przeprowadź proof of concept na swoim realnym środowisku: opublikuj kilka swoich faktycznych aplikacji prywatnych, w tym jedną trudną, lokalną, przetestuj dostęp kontraktora z niezarządzanego urządzenia przez przeglądarkę, zmierz wydajność stamtąd, gdzie faktycznie są twoi użytkownicy, i przeprowadź małą grupę całkowicie poza VPN, żeby zobaczyć, co się psuje, ustalając z góry kryteria sukcesu, wśród nich dostęp bezagentowy i pokrycie realnych aplikacji. Potem zbierz referencje skupione na migracji: jak przebiegło wygaszanie VPN, co się zepsuło i czy pakiet, który kupili, pasował do tego, czego ostatecznie używają.

pułapki, których nie ujawni pilotaż

Klasyczna porażka to kupno platformy, żeby rozwiązać problem VPN, a potem wykorzystywanie jej ułamka przy płaceniu za całość. Zaraz za tym jest ściana agenta: ZTNA, które działa dla zarządzanych pracowników i nie potrafi czysto obsłużyć kontraktorów i partnerów, którzy okazują się dużą częścią twojego dostępu zdalnego. Jest też niespodzianka wydajnościowa, gdy punkty obecności dostawcy są na tyle daleko od twoich użytkowników, że nowe narzędzie wydaje się tak wolne jak VPN, który zastąpiło; rozrost pakietu, moduły włączane i rozliczane bez faktycznego wdrożenia do użytku; aplikacja legacy, której ZTNA nie potrafi dobrze opublikować, więc VPN nigdy naprawdę nie zostaje wygaszony i prowadzisz oba naraz; oraz próżnia własności, gdzie bezpieczeństwo i sieć zakładają nawzajem, że to ten drugi zespół się tym zajmuje. Najgłębsza pułapka to mylenie ZTNA z ukończonym zero trust i pozostawienie zarządzania tożsamością, SaaS i danych nietkniętymi. Co leży pod nimi wszystkimi: ZTNA zastępuje VPN, i tylko VPN, a wartość bierze się z uczciwego określenia zakresu, nie z kupienia największego dostępnego pakietu.

gdzie to spotyka się z przepisami

Bezpieczny dostęp zdalny wprost mieści się w zakresie regulacji. NIS2 oczekuje kontroli dostępu i bezpiecznej obsługi dostępu zdalnego wśród swoich środków zarządzania ryzykiem, a płaski VPN, który wpuszcza użytkowników wprost do sieci, nie pasuje do tego zbyt dobrze. DORA oczekuje od podmiotów finansowych kontroli dostępu, w tym dostępu zdalnego i uprzywilejowanego, co model ZTNA oparty na aplikacji, tożsamości i urządzeniu wspiera znacznie lepiej niż zaufanie na poziomie sieci. Ubezpieczyciele coraz uważniej przyglądają się dostępowi zdalnemu, bo wykorzystane VPN-y to dobrze przetarta ścieżka ransomware. Żadna z tych regulacji nie wskazuje konkretnego produktu, ale kierunek, odejście od zaufania na poziomie sieci w stronę dostępu opartego na tożsamości per aplikacja, pasuje do tego, na co wskazują zarówno przepisy, jak i zagrożenia. To kontekst do priorytetyzacji, nie porada prawna, a szczegóły zależą od twojego sektora i kraju.

ścieżka etapami

To podejście nagradza precyzyjne określenie zakresu i świadome wygaszanie VPN, zamiast gonienia za pełną platformą pierwszego dnia. Czołganie się: zastąp VPN dla dostępu zdalnego najwyższego ryzyka za pomocą ZTNA, przyznając dostęp per aplikacja na podstawie tożsamości i urządzenia, zaczynając od dostępu, który zaszkodziłby najbardziej, gdyby został nadużyty, i opierając się na istniejącym single sign-on i dostępie warunkowym po stronie SaaS. Chodzenie: rozszerz ZTNA, żeby szeroko pokryć aplikacje prywatne, przenieś kontraktorów na dostęp bezagentowy i wygaś VPN porządnie, zamiast prowadzić oba naraz, dokładając secure web gateway lub kontrolę chmury tylko tam, gdzie masz konkretną potrzebę. Bieganie: jeśli twoja sytuacja naprawdę tego wymaga, zbliż się do pełnej platformy SSE czy SASE, gdzie stan urządzenia zasila każdą decyzję o dostępie, łączność oddziałów i szerokie punkty obecności, spięte z szerszym modelem zero trust, którego ZTNA jest komponentem dostępu sieciowego, a nie całością.

od czego zacząć

ZTNA to jedno z jaśniejszych dostępnych usprawnień bezpieczeństwa, bo zastąpienie zaufania na poziomie sieci dostępem opartym na tożsamości, per aplikacja, usuwa całą klasę ryzyka i jednocześnie rozwiązuje realną, codzienną irytację. Pułapką jest kupienie znacznie więcej platformy, niż wymaga problem. Uczciwym pierwszym krokiem jest więc zmapowanie, do czego ludzie faktycznie muszą mieć dostęp i z jakich urządzeń, dopasowanie zakupu do tego zakresu i potraktowanie zastąpienia VPN jako wygranej, zamiast sięgania po cały pakiet, zanim jest naprawdę potrzebny.