ZTNA dla obronności: zero trust, silnik polityk i proxy tożsamości

Obwodowy VPN przez trzy dekady był podstawową kontrolą zdalnego dostępu w sieciach obronnych. Użytkownik uwierzytelnia się w bramie VPN, zestawiany jest tunel, a użytkownik uzyskuje szeroki dostęp na poziomie sieciowym do zasobów wewnątrz obwodu. Ten model zaprojektowano dla świata, w którym aplikacje hostowano w jednym centrum danych, a użytkownicy łączyli się z lokalizacji kontrolowanych przez organizację. We współczesnym środowisku obronnym — gdzie obciążenia rozciągają się na chmurę suwerenną, krawędź taktyczną i odseparowane (air-gapped) enklawy tajne, a użytkownicy łączą się z urządzeń zarządzanych i częściowo zarządzanych z wielu lokalizacji — architektura VPN wprowadza ryzyko, którego jej projektanci nigdy nie przewidzieli. Zero trust network access (ZTNA) jest architektonicznym następcą: dostęp na poziomie aplikacji, pośredniczony przez proxy świadome tożsamości i warunkowany ciągłą weryfikacją tego, kto się łączy i jakiego urządzenia używa. Ten artykuł analizuje inżynierską mechanikę ZTNA dla obrony: jak zbierane i oceniane są sygnały tożsamości i urządzenia, jak silnik polityk wytwarza decyzje dostępowe oraz jak wdrożyć ZTNA w całym spektrum — od sieci nieklasyfikowanych po odseparowane enklawy tajne.

Dlaczego klasyczny VPN zawodzi w obronnym zero trust

Fundamentalnym problemem VPN w kontekście zero trust nie jest szyfrowanie — tunele VPN są kryptograficznie poprawne. Problem polega na tym, co VPN nadaje po zestawieniu szyfrowania. Gdy użytkownik uwierzytelnia się w bramie VPN i tunel powstaje, urządzenie użytkownika otrzymuje adres sieciowy wewnątrz enklawy obronnej i może osiągnąć dowolny zasób w tej podsieci, który nie ma osobnej zapory opartej na hoście. VPN wykonał pojedyncze zdarzenie uwierzytelnienia przy zestawianiu tunelu i podjął dorozumianą, trwałą decyzję o zaufaniu: ten użytkownik i to urządzenie mogą korzystać z całego segmentu sieci przez cały czas trwania sesji.

Dorozumiane zaufanie po uwierzytelnieniu. Uwierzytelnienie VPN jest bramą, a nie ciągłą oceną. Po przejściu bramy zaufanie nie jest ponownie oceniane aż do zakończenia sesji lub przekroczenia limitu czasu. Jeśli konto użytkownika zostanie skompromitowane w trakcie sesji, jeśli urządzenie zostanie w trakcie sesji zainfekowane złośliwym oprogramowaniem albo jeśli użytkownik zostawi urządzenie bez nadzoru z aktywnym tunelem, VPN nadal zapewnia dostęp na poziomie enklawy, dopóki administrator ręcznie nie zakończy sesji lub tunel nie wygaśnie. W środowisku obronnym, gdzie sesje często trwają cały dzień pracy, oznacza to wydłużone okno niewykrytego ryzyka.

Zasięg rażenia płaskiej sieci. VPN umieszcza użytkownika w segmencie sieci. Płaska łączność wschód–zachód w tym segmencie oznacza, że skompromitowana sesja VPN może sięgnąć nie tylko do aplikacji, którą użytkownik zamierzał użyć, lecz do każdej usługi, bazy danych i interfejsu zarządzania w tej podsieci. Atakujący, który kradnie poświadczenie VPN, zyskuje przyczółek o takim samym zasięgu sieciowym jak legalny użytkownik — lub szerszym, ponieważ polityka VPN rzadko ogranicza ruch wewnątrz podsieci. To jest problem zasięgu rażenia: skompromitowanie jednego poświadczenia obnaża cały płaski segment sieci.

Niemożność egzekwowania drobnoziarnistej polityki dostępu. Polityka dostępu VPN jest zgrubna: użytkownik albo może połączyć się z profilem VPN, albo nie. Profil może przypisywać VLAN lub podsieć, ale egzekwowanie polityki per aplikacja, per zasób lub per akcja wewnątrz tunelu nie jest zdolnością VPN. Kontrola dostępu wewnątrz tunelu jest delegowana do własnego mechanizmu uwierzytelniania każdej aplikacji — którego rygor może się w portfelu aplikacji bardzo szeroko różnić. ZTNA przenosi politykę dostępu do scentralizowanego silnika polityk, który stosuje spójne reguły w każdej aplikacji, oceniane w punkcie każdego żądania dostępu, a nie raz przy zestawieniu sesji. Pokrewne pojęcie mikrosegmentacji zero trust w obronie zajmuje się ruchem poprzecznym w sieci po decyzji dostępowej, uzupełniając warstwę ZTNA na obwodzie.

Architektura ZTNA: model proxy a model agenta na urządzeniu końcowym

Wdrożenia ZTNA dzielą się na dwa podstawowe wzorce architektoniczne w zależności od sposobu przechwytywania ruchu: model odwrotnego proxy (bez klienta, clientless) oraz model agenta na urządzeniu końcowym. Oba modele mają wspólną strukturę logiczną — punkt egzekwowania polityk, brokera tożsamości, usługę zaufania urządzenia i proxy sesji — ale różnią się miejscem przechwytywania i poziomem widoczności urządzenia, jaki mogą osiągnąć.

ZTNA z odwrotnym proxy (bez klienta)

W modelu odwrotnego proxy na urządzeniu końcowym nie instaluje się żadnego oprogramowania. Usługa ZTNA publikuje punkt końcowy proxy — zazwyczaj adres URL w domenie organizacji — który stoi przed każdą chronioną aplikacją. Użytkownik przechodzi do adresu URL proxy w przeglądarce, uwierzytelnia się przez brokera tożsamości (prezentując poświadczenia CAC/PIV i kończąc MFA) i otrzymuje krótkotrwały token sesji. Proxy waliduje token przy każdym żądaniu i przekazuje uwierzytelnione, autoryzowane żądania do zaplecza aplikacji. Urządzenie użytkownika nigdy nie zostaje umieszczone w sieci aplikacji; tylko proxy ma ścieżkę sieciową do zaplecza.

Głównym ograniczeniem modelu bez klienta jest pokrycie protokołów: naturalnie działa dla aplikacji HTTPS i może obsługiwać RDP oraz SSH przez klienty oparte na przeglądarce (bramy RDP/SSH w HTML5), ale nie obsługuje dowolnych protokołów TCP/UDP ani aplikacji z grubym klientem komunikujących się protokołami własnościowymi. Widoczność zaufania urządzenia jest bez agenta także bardziej ograniczona: proxy może badać certyfikaty klienta TLS i ciągi user-agent przeglądarki, ale nie może zweryfikować stanu zdrowia EDR ani atestacji TPM bez pomocy lokalnego agenta.

ZTNA z agentem na urządzeniu końcowym

Model agenta instaluje lekki demon na zarządzanym urządzeniu końcowym. Agent działa ciągle, przechwytuje ruch przeznaczony dla adresów chronionych aplikacji (przez lokalny wirtualny adapter sieciowy lub filtr pakietów na poziomie systemu operacyjnego), wykonuje lokalnie kontrole zaufania urządzenia i zestawia szyfrowany tunel do krawędzi usługi ZTNA. Ruch chronionych aplikacji przebiega tym tunelem zamiast otwartym internetem czy VPN. Zaplecze aplikacji otrzymuje połączenia od proxy ZTNA, a nie bezpośrednio od urządzenia końcowego — sieciowy adres zaplecza nigdy nie jest obnażany wobec urządzenia końcowego.

ZTNA oparty na agencie obsługuje dowolny protokół aplikacyjny, umożliwia bogate sygnały zaufania urządzenia (integracja EDR, atestacja TPM, zgodność łatek) oraz pozwala na trasowanie split-tunnel, w którym tylko ruch chronionych aplikacji przechodzi przez tunel ZTNA, podczas gdy ogólny ruch internetowy wychodzi bezpośrednio. Dla zarządzanych urządzeń końcowych w obronie model agenta jest standardowym wyborem, ponieważ wymagań dotyczących postawy urządzenia dla dostępu do aplikacji tajnych nie można spełnić bez widoczności na poziomie lokalnego agenta.

ZTNA z chmury a ZTNA lokalne

ZTNA dostarczany z chmury uruchamia płaszczyznę kontroli i proxy sesji w wielodostępnej usłudze chmurowej. Model ten pasuje do programów nieklasyfikowanych, w których aplikacje hostowane są w komercyjnych lub rządowych środowiskach chmurowych. Dla programów tajnych — IL4, IL5 oraz odseparowanego IL6 — płaszczyzna kontroli ZTNA musi zostać wdrożona w granicach akredytowanej strefy. Lokalne ZTNA (on-premises) umieszcza silnik polityk, brokera tożsamości i proxy sesji wewnątrz enklawy tajnej. Ruch aplikacji nigdy nie opuszcza granic strefy tajnej. Zewnętrzne zależności płaszczyzny kontroli — walidacja certyfikatów, zapytania o stan EDR, wyszukiwania u dostawcy tożsamości — muszą się wszystkie rozstrzygać w sieci akredytowanej bez dostępu do internetu.

Sygnały tożsamości: kto się łączy

Decyzje dostępowe ZTNA są warunkowane tożsamością łączącego się użytkownika. Dla personelu obronnego weryfikacja tożsamości zakotwiczona jest w fizycznym poświadczeniu wydawanym przez system kadr organizacji — karcie inteligentnej CAC lub PIV — i wzbogacana o atrybuty roli i grupy pochodzące z katalogu.

Weryfikacja certyfikatów CAC/PIV

Karta CAC (Common Access Card) i karta PIV (Personal Identity Verification) zawierają certyfikat tożsamości X.509 wydany przez zatwierdzone PKI organizacji. Weryfikacja certyfikatu w ZTNA obejmuje: prezentację certyfikatu brokerowi tożsamości ZTNA przez uwierzytelnienie klienta TLS; walidację łańcucha certyfikatu względem zatwierdzonego punktu zaufania (główne i pośrednie CA w magazynie zaufania organizacji); sprawdzenie certyfikatu względem listy odwołanych certyfikatów (CRL) lub respondenta OCSP w celu potwierdzenia, że nie został odwołany; oraz wyodrębnienie wyróżniającej nazwy podmiotu lub UPN z certyfikatu w celu identyfikacji konta użytkownika.

Dostępność CRL i OCSP w środowisku odseparowanym to częsty punkt awarii operacyjnej. Jeśli punkt dystrybucji CRL jest osiągalny tylko z sieci nieklasyfikowanej, a wdrożenie ZTNA znajduje się w sieci tajnej, kontrole odwołania certyfikatów zawodzą lub przekraczają limit czasu. Wdrożenia ZTNA w odseparowaniu wymagają proxy buforującego CRL wewnątrz granic strefy tajnej, które okresowo synchronizuje aktualizacje CRL przez mechanizm transferu międzydomenowego.

Uwierzytelnianie wieloczynnikowe dla dostępu ZTNA

Wpisanie PIN-u karty CAC spełnia wymóg MFA „coś, co masz, plus coś, co wiesz” dla większości programów. Jednak aplikacje uznane za wysoce wrażliwe mogą wymagać dodatkowego czynnika poza kartą CAC — kodu TOTP, powiadomienia push do zarejestrowanej aplikacji uwierzytelniającej lub sprzętowego klucza bezpieczeństwa. Silnik polityk ZTNA może egzekwować wymagania poziomu MFA per aplikacja: standardowe CAC-PIN dla aplikacji ogólnych, CAC-PIN plus TOTP dla wrażliwych aplikacji dowodzenia oraz ograniczony czasowo przepływ zatwierdzania poza pasmem dla uprzywilejowanego dostępu administracyjnego. Takie poziomowanie MFA per aplikacja nie jest osiągalne przy płaskiej polityce VPN.

Integracja z dostawcą tożsamości: LDAP i Active Directory

Uwierzytelnienie certyfikatem identyfikuje konto użytkownika, ale nie przenosi bieżącej roli ani przynależności do grup — są one zarządzane w katalogu i mogą zmieniać się niezależnie od wystawiania certyfikatów. Silnik polityk ZTNA odpytuje dostawcę tożsamości — LDAP lub Active Directory — w chwili każdego żądania dostępu, aby rozstrzygnąć bieżące członkostwa w grupach i przypisania ról użytkownika. Rozstrzygnięte atrybuty stają się wejściami polityki: użytkownik musi być członkiem grupy Active Directory „analysts-secret”, aby uzyskać dostęp do tajnej aplikacji analitycznej, niezależnie od tego, co mówi jego certyfikat. Jeśli użytkownik zostanie usunięty z grupy w Active Directory, jego następne żądanie dostępu do aplikacji analitycznej zostanie odrzucone przez silnik polityk ZTNA bez konieczności odwołania certyfikatu czy zmiany polityki VPN. Ta kontrola dostępu oparta na atrybutach, wsparta zapytaniami do katalogu w czasie rzeczywistym, jest podstawową zdolnością nadzoru nad tożsamością w organizacjach obronnych, stosowaną, aby zacieśnić cykl życia kontroli dostępu.

Sygnały zaufania urządzenia: jakie urządzenie się łączy

Tożsamość użytkownika jest koniecznym, ale niewystarczającym warunkiem dostępu w obronnym modelu ZTNA. Legalny użytkownik na skompromitowanym lub niezgodnym urządzeniu stwarza ryzyko, którego sama tożsamość użytkownika nie może zredukować. Ocena zaufania urządzenia zbiera i ocenia sygnały o łączącym się urządzeniu niezależnie od deklaracji tożsamości użytkownika.

Certyfikat urządzenia

Pierwszym sygnałem zaufania urządzenia jest certyfikat maszynowy: certyfikat wydany przez PKI urządzeń organizacji dla urządzenia końcowego w chwili rejestracji. Certyfikat maszynowy dowodzi, że urządzenie zostało zarejestrowane przez autoryzowany MDM lub system zarządzania urządzeniami i było wówczas zarządzanym zasobem. Agent ZTNA prezentuje certyfikat urządzenia obok certyfikatu użytkownika przy zestawianiu sesji. Silnik polityk waliduje łańcuch certyfikatu urządzenia względem punktu zaufania PKI urządzeń, sprawdza stan odwołania i potwierdza, że identyfikator urządzenia w certyfikacie odpowiada tożsamości urządzenia zapisanej w inwentarzu MDM.

Stan zdrowia EDR

Agent EDR (endpoint detection and response) działający na urządzeniu utrzymuje bieżącą ocenę stanu zagrożeń urządzenia. Agent ZTNA odpytuje lokalnego agenta EDR lub API platformy zarządzania EDR o atestację stanu zdrowia: czy agent EDR działa, czy jego baza danych wywiadu o zagrożeniach jest aktualna oraz czy istnieją aktywne zagrożenia w kwarantannie lub remediacji. Urządzenie z nieaktualną bazą sygnatur EDR jest w praktyce ślepe na najnowsze rodziny zagrożeń — polityka ZTNA powinna traktować takie urządzenie jako niezgodne i albo odmawiać dostępu, albo ograniczać go do warstwy dostępu ograniczonego do czasu aktualizacji EDR. Zdarzenie kwarantanny aktywnego zagrożenia w trakcie sesji uruchamia zdarzenie ciągłej oceny, które może skutkować natychmiastowym zawieszeniem sesji.

Kontrola zgodności łatek

Poziom łatek systemu operacyjnego i aplikacji jest odpytywany z platformy MDM lub z lokalnego inwentarza zainstalowanych łatek agenta ZTNA. Silnik polityk ZTNA porównuje stan łatek urządzenia z określonym minimum: na przykład wszystkie podatności CVE o krytycznym i wysokim poziomie ryzyka opublikowane w ciągu ostatnich 30 dni muszą być załatane, zanim zostanie pozwolony dostęp do aplikacji tajnych. Urządzenia zalegające z łatkami są przekierowywane do powiadomienia o remediacji zamiast do żądanej aplikacji. Kontrola zgodności łatek obejmuje też aplikacje firm trzecich w zarządzanym inwentarzu oprogramowania urządzenia — niezałatana przeglądarka internetowa lub czytnik PDF na zarządzanym urządzeniu stanowi wektor eksploitacji, nawet jeśli system operacyjny jest w pełni załatany.

Atestacja sprzętowa przez TPM 2.0

Dla zarządzanych urządzeń końcowych wyposażonych w moduł TPM 2.0 agent ZTNA może zażądać cytatu atestacyjnego TPM — kryptograficznie podpisanego pomiaru łańcucha rozruchowego urządzenia, wytworzonego przez TPM i weryfikowalnego względem znanego dobrego manifestu odniesienia. Atestacja dowodzi, że urządzenie uruchomiło się z autoryzowanego obrazu firmware i systemu operacyjnego oraz że łańcuch rozruchowy nie został naruszony od ostatniej atestacji. Kontrola ta jest istotna dla wykrywania złośliwego oprogramowania na poziomie rozruchu — rootkitów i bootkitów, które utrzymują się poniżej systemu operacyjnego i nie zostaną wykryte przez agenta EDR na poziomie systemu operacyjnego. Atestacja TPM wymaga, aby płaszczyzna kontroli ZTNA posiadała manifest odniesienia dla każdego modelu urządzenia w zarządzanej flocie; manifest jest wypełniany podczas rejestracji urządzenia i aktualizowany, gdy wdrażane są autoryzowane zmiany firmware.

Silnik ciągłej oceny polityk

Silnik polityk jest rdzeniem decyzyjnym architektury ZTNA. Otrzymuje żądania dostępu — od proxy sesji, gdy użytkownik inicjuje połączenie, oraz od pętli ciągłej oceny w trakcie aktywnej sesji — i zwraca decyzję dostępową: pozwól, odmów lub podwyższ poziom (wymagaj dodatkowego uwierzytelnienia przed pozwoleniem).

Policy-as-code z OPA i Rego

Wdrożenia ZTNA w obronie zyskują na wyrażaniu polityki dostępu jako kodu, a nie reguł konfigurowanych w GUI. Open Policy Agent (OPA) z językiem polityk Rego jest dominującym frameworkiem tego wzorca. Polityka Rego dla ZTNA deklaratywnie koduje wszystkie warunki dostępu: wymagane grupy użytkowników, minimalny poziom zgodności urządzenia, dozwolone godziny dostępu, wymagany poziom MFA oraz próg wyniku ryzyka. Polityki są wersjonowane w repozytorium źródłowym, przeglądane w tym samym procesie kontroli zmian co kod aplikacji i wdrażane do silnika OPA przez potok CI/CD. Każda zmiana polityki ma autora, zapis przeglądu, znacznik czasu wdrożenia i może zostać wycofana do poprzedniej wersji pojedynczym cofnięciem w potoku. Ta audytowalność jest wymierną przewagą nad regułami zapory per aplikacja, które kumulują się bez kontroli wersji.

Decyzje dostępowe świadome kontekstu

Decyzje polityki ZTNA mogą uwzględniać sygnały kontekstowe wykraczające poza tożsamość i zaufanie urządzenia. Polityka czasu dostępu ogranicza dostęp do wrażliwych aplikacji do zdefiniowanych okien godzin pracy, skracając okno narażenia na nadużycie poświadczeń poza normalnymi godzinami pracy. Geolokalizację lub źródło sieciowe — skąd łączy się użytkownik — silnik polityk również może oceniać: aplikacja tajna może pozwalać na dostęp wyłącznie z zarządzanych przez organizację punktów wyjścia do sieci lub z określonych zatwierdzonych lokalizacji zdalnego dostępu. Integracja wyniku ryzyka pozwala silnikowi polityk konsumować numeryczny sygnał ryzyka wytwarzany przez platformę analizy behawioralnej użytkowników i podmiotów (UEBA): jeśli wzorzec dostępu użytkownika w ostatnich 24 godzinach wygenerował wysoki wynik ryzyka anomalii, silnik polityk podnosi próg dostępu, wymagając MFA typu step-up przed dopuszczeniem dostępu do wrażliwych aplikacji.

Ponowna ocena ryzyka sesji

Tradycyjna kontrola dostępu podejmuje decyzję na początku sesji i nie wraca do niej. Ciągła ocena ZTNA ponownie ocenia decyzję dostępową w trakcie całej sesji w konfigurowalnym interwale odpytywania. Pętla oceny odpytuje dostawcę tożsamości o zmiany stanu konta (blokada konta lub odwołanie członkostwa w grupie od początku sesji), platformę EDR o nowe zdarzenia zagrożeń na urządzeniu, usługę zgodności urządzeń o zmiany stanu łatek oraz usługę oceny ryzyka o zmiany wyniku anomalii. Gdy zmiana przekroczy próg polityki, silnik reaguje proporcjonalnie: umiarkowany wzrost ryzyka wyzwala wyzwanie MFA typu step-up bez kończenia sesji; zdarzenie krytyczne — blokada konta, aktywne zagrożenie EDR, odwołanie certyfikatu — wyzwala natychmiastowe zakończenie sesji. Model ciągłej oceny oznacza, że atakujący, który kompromituje urządzenie w trakcie sesji, ma okno detekcji ograniczone interwałem odpytywania, a nie całym czasem życia sesji. Te same zasady, którymi rządzą się programy zarządzania dostępem uprzywilejowanym w obronie — dostęp just-in-time, nagrywanie sesji i ponowna ocena ryzyka w czasie rzeczywistym — mają bezpośrednie zastosowanie w projekcie ciągłej oceny ZTNA dla sesji o wysokich uprawnieniach.

ZTNA dla sieci tajnych: wdrożenie IL4/IL5

Komercyjne usługi ZTNA dostarczane z chmury działają w wielodostępnej współdzielonej infrastrukturze, która nie jest autoryzowana do obciążeń tajnych. Programy obronne na poziomach oddziaływania IL4 (Controlled Unclassified Information) i IL5 (National Security Systems) wymagają modelu wdrożenia ZTNA, który utrzymuje operacje płaszczyzny kontroli i ruch aplikacji w granicach akredytowanej strefy.

Lokalne ZTNA dla odseparowanych środowisk tajnych

Wdrożenie lokalne ZTNA dla sieci tajnej replikuje funkcjonalne komponenty usługi ZTNA z chmury wewnątrz enklawy tajnej. Silnik polityk, broker tożsamości, proxy sesji i usługa zaufania urządzenia są wdrażane jako lokalne obciążenia obliczeniowe — na dedykowanym sprzęcie lub w tajnym klastrze Kubernetes. Wszystkie zależności płaszczyzny kontroli rozstrzygają się w enklawie: dostawcą tożsamości jest tajna instancja Active Directory, konsola zarządzania EDR jest wdrożona lokalnie, urząd certyfikacji i usługa CRL działają wewnątrz odseparowania, a żadne wywołanie oceny polityki nie opuszcza granic sieci tajnej.

Wyzwaniem operacyjnym unikalnym dla odseparowanego ZTNA jest dystrybucja aktualizacji polityk. W usłudze ZTNA z chmury zmiany polityk wdrażane są centralnie i propagują w ciągu sekund. W środowisku odseparowanym aktualizacje polityk muszą być dostarczane przez autoryzowany mechanizm transferu oprogramowania — zazwyczaj proces transferu nośników przez granicę akredytacji. Oznacza to, że zmiany polityk ZTNA wymagają planowania z wyprzedzeniem i nie mogą być stosowane z opóźnieniem poniżej minuty dostępnym we wdrożeniach chmurowych. Proces kontroli zmian dla polityk odseparowanego ZTNA musi uwzględniać ten czas wyprzedzenia, a nagłe zmiany polityk (na przykład natychmiastowe odwołanie dostępu skompromitowanego użytkownika) muszą mieć przyspieszoną ścieżkę przez proces kontroli zmian określoną w planie bezpieczeństwa programu.

Projekt międzydomenowego proxy ZTNA

Niektóre przypadki użycia w obronie wymagają, aby użytkownicy w sieci o niższej klasyfikacji uzyskiwali dostęp do określonego, filtrowanego widoku danych wytwarzanych przez system o wyższej klasyfikacji — sanityzowanego obrazu operacyjnego, zdezklasyfikowanego podsumowania wywiadowczego lub strumienia danych tylko do odczytu. Międzydomenowe proxy ZTNA rozwiązuje to, łącząc kontrolę dostępu ZTNA z międzydomenową inspekcją treści na granicy klasyfikacji. Proxy odbiera żądanie dostępu użytkownika z sieci nieklasyfikowanej, weryfikuje tożsamość i zaufanie urządzenia względem nieklasyfikowanego silnika polityk ZTNA, a następnie odpytuje tajną aplikację w imieniu użytkownika przez rozwiązanie międzydomenowe. Komponent CDS bada treść odpowiedzi aplikacji, stosuje reguły zwolnienia dla klasyfikacji danych i filtruje lub redaguje elementy nieautoryzowane do zwolnienia dla występującego o dostęp z sieci nieklasyfikowanej. Tylko przefiltrowana odpowiedź wraca do sesji użytkownika w sieci nieklasyfikowanej. Proxy musi być akredytowane w ramach obu ATO sieci oraz autoryzacji międzydomenowej, z architekturą ZTNA + CDS opisaną wprost jako kontrola łączona.

Migracja z klasycznego VPN do ZTNA

Migracja z VPN do ZTNA w programie obronnym to przejście operacyjne, które musi zachować ciągłość dostępu do aplikacji krytycznych dla misji, przy stopniowym zaostrzaniu kontroli dostępu. Standardowym podejściem jest strategia migracji fazowej, w której VPN i ZTNA działają równolegle w okresie przejściowym.

Strategia migracji fazowej

Migracja przebiega w trzech fazach. W pierwszej fazie infrastruktura ZTNA jest wdrażana i walidowana pod kątem integracji tożsamości i zaufania urządzeń, ale żadne aplikacje nie są podłączane, a użytkownicy nadal korzystają ze wszystkich aplikacji przez VPN. Grupa pilotażowa użytkowników — zazwyczaj zespół IT i bezpieczeństwa — testuje dostęp ZTNA do aplikacji o niskiej krytyczności, aby zweryfikować przepływ końcowy od początku do końca, zanim zaangażowani zostaną użytkownicy misji. W drugiej fazie aplikacje są podłączane do ZTNA w kolejności priorytetów. W tej fazie VPN pozostaje dostępny jako ścieżka awaryjna dla aplikacji jeszcze niepodłączonych. Użytkownicy są szkoleni z portalu dostępu ZTNA i agenta, zanim ich podstawowe aplikacje przejdą na ZTNA. W trzeciej fazie, po podłączeniu wszystkich aplikacji w zakresie i zwalidowaniu dostępu przez populację pilotażową, dostęp VPN jest odwoływany dla zmigrowanej populacji użytkowników. Brama VPN pozostaje dostępna tylko dla aplikacji wyłączonych z zakresu ZTNA (jeśli takie są) w fazie końcowej, a następnie jest wycofywana z eksploatacji, gdy pozostałe aplikacje zakończą podłączanie.

Sekwencja podłączania aplikacji

Aplikacje są podłączane do ZTNA w sekwencji zaprojektowanej tak, aby minimalizować ryzyko i czerpać wnioski z wczesnych podłączeń, zanim podejmie się przypadki złożone. Zacznij od wewnętrznych portali i pulpitów internetowych — aplikacji HTTPS z interfejsami opartymi na przeglądarce, które naturalnie współpracują z ZTNA opartym na odwrotnym proxy i mają szerokie populacje użytkowników zdolne szybko przekazać opinię. Przejdź następnie do aplikacji produktywności: internetowych interfejsów poczty, portali zarządzania dokumentami, wewnętrznych wiki. Potem podejmij kategorie aplikacji wymagające modelu agenta: serwery Windows dostępne przez RDP, systemy Linux dostępne przez SSH, systemy C2 lub misyjne z grubym klientem. Na koniec zostaw najbardziej złożone integracje: aplikacje z niestandardowymi mechanizmami uwierzytelniania, systemy czasu rzeczywistego o wysokiej krytyczności oraz każdą aplikację, która obecnie polega na kontroli dostępu opartej na IP VPN zamiast na uwierzytelnieniu warstwy aplikacji.

Szkolenie użytkowników wzorców dostępu ZTNA

Doświadczenie użytkownika ZTNA różni się istotnie od VPN. Użytkownicy przyzwyczajeni do VPN łączą się raz na początku dnia i przez resztę dnia korzystają ze wszystkich aplikacji w sposób przezroczysty. W ZTNA użytkownik uzyskuje dostęp do aplikacji przez portal ZTNA lub przez połączenia przechwytywane przez agenta i może w ciągu dnia napotykać wyzwania MFA typu step-up, gdy ciągła ocena wykryje zmianę ryzyka. Szkolenie musi objąć trzy zmiany zachowań. Po pierwsze, portal dostępu: gdzie nawigować, aby znaleźć aplikacje, i jak uwierzytelnić się kartą CAC. Po drugie, agent: jak agent ZTNA wygląda w zasobniku systemowym, co znaczą jego wskaźniki stanu i jak zgłaszać problemy. Po trzecie, uwierzytelnienie step-up: jak wygląda wyzwanie MFA w trakcie sesji (aby użytkownicy nie brali legalnego monitu step-up za próbę phishingu) i jak je zrealizować. Programy, które inwestują w szkolenie użytkowników przed podłączeniem pierwszego użytkownika misji, notują znacząco mniejszą liczbę zgłoszeń do helpdesku i szybszą adopcję niż programy, które wdrażają ZTNA bez programu szkoleniowego.