Architektura i wdrożenie Zero Trust Network Access

Architektura i wdrożenie Zero Trust Network Access

W poprzednim artykule opisaliśmy, czym jest rozwiązanie Zero Trust Network Access oraz z jakich komponentów się składa, w oparciu o produkty firmy Fortinet. Dzisiejszy artykuł stanowi kontynuację opisu architektury ZTNA. Skupimy się w nim na przybliżeniu zasady działania dwóch trybów – z wykorzystaniem agenta i telemetrii ZTNA oraz samego proxy, realizowanego za pomocą FortiGate. Według informacji od Fortinet, rozwiązanie ZTNA jest aktualnie mocno rozwijane, o czym może świadczyć fakt, iż rolę proxy będą mogły pełnić również inne produkty np. FortiWeb, czyli rozwiązanie do ochrony aplikacji webowych typu WAF.

Tagowanie i telemetria ZTNA

Gdy końcówki z agentem FortiClient (zarówno te w sieci wewnętrznej jak i zewnętrznej) rejestrują się w FortiClient EMS, informacje o urządzeniu, dane logowania użytkownika i status urządzenia (ang.device posture) udostępnianie są serwerowi EMS poprzez telemetrię ZTNA. Klienci wysyłają również żądanie podpisania certyfikatu, aby uzyskać certyfikat klienta z EMS, który w tym przypadku działa jako ZTNA Certificate Authority (CA).

Na podstawie informacji od klienta, EMS stosuje odpowiednie tagowanie Zero Trust. Tagi oraz informacje o certyfikacie klienta są synchronizowane w czasie rzeczywistym z FortiGate. Dzięki temu FortiGate może zweryfikować tożsamość klienta za pomocą certyfikatu i przyznać dostęp na podstawie tagów zastosowanych w regule/polityce ZTNA.

Poniższy rysunek przedstawia proces ZTNA, począwszy od identyfikacji użytkownika za pomocą certyfikatów, weryfikację kontekstową oraz przekazywanie informacji pomiędzy FortiClient, serwerem EMS i FortiGate, które stanowią integralną część wspomnianego rozwiązania.

Jaką rolę pełni FortiClient?

Rozwiązanie FortiClient pracujące w formie agenta instalowanego na końcówkach odpowiedzialne jest za przekazywanie następujących informacji do FortiClient EMS:

• Informacje o urządzeniu (informacje o sieci, system operacyjny, model oraz inne)
• Zalogowani użytkownicy
• Weryfikacja stanu bezpieczeństwa (wewnątrz/poza siecią, antywirus, status podatności i inne)

Aby zapewnić bezpieczny dostęp do zasobów, żąda również certyfikatu urządzenia klienta i uzyskuje go od EMS ZTNA Certificate Authority (CA) podczas rejestracji w serwerze EMS. Certyfikat jest następnie wykorzystywany do identyfikacji klienta w FortiGate.

Jaką role pełni FortiClient EMS?

FortiClient EMS wystawia i podpisuje certyfikat klienta za pomocą identyfikatora FortiClient UID i certyfikat z numerem seryjnym EMS. Certyfikat jest następnie synchronizowany z FortiGate. EMS udostępnia również FortiGate swój certyfikat EMS ZTNA CA, dzięki czemu FortiGate może używać go do uwierzytelniania klientów.

FortiClient EMS używa reguł tagowania Zero Trust do oznaczania endpointów na podstawie informacji, które posiada o każdym punkcie końcowym. Tagi są również współdzielone z FortiGate. Na stronie Endpoint Posture Check Reference można sprawdzić dokładnie jakie informacje są zbierane i poddawane weryfikacji na urządzeniu końcowym, które następnie sprawdza EMS.

Co więcej, od wersji EMS 7.0.2 szyfrowana komunikacja pomiędzy FortiClient i EMS została wzbogacona o możliwość wykorzystania również certyfikatów dostarczonych przez klienta, nie tylko od Fortinet. Dostępną opcją są certyfikaty Let’s Encrypt za pośrednictwem protokołu ACME, gdzie wymagany jest dowód witryny lub certyfikat dostarczony przez klienta z CA, które jest zaufane na urządzeniu klienta.

Jaką rolę pełni FortiGate?

FortiGate utrzymuje ciągłe połączenie z serwerem EMS w celu synchronizowania informacji o urządzeniach końcowych, w tym przede wszystkim:

• FortiClient UID
• Certyfikat klienta SN
• EMS SN
• Dane uwierzytelniające urządzenie (użytkownik/domena)
• Szczegóły sieci (adres IP i MAC oraz routing do FortiGate)

W przypadku zmiany informacji o urządzeniu, na przykład w przypadku przejścia klienta z sieci on-net/ off-net lub zmiany stanu zabezpieczeń, system EMS jest aktualizowany o nowe informacje o urządzeniu, a następnie aktualizowany jest FortiGate. Demon WAD (proces odpowiedzialny za proxy) w FortiGate może wykorzystywać te informacje podczas przetwarzania ruchu ZTNA. Jeśli zmiana stanu zabezpieczeń punktu końcowego spowoduje, że nie będzie on już odpowiadał kryteriom reguły ZTNA w istniejącej sesji, taka sesja zostanie zakończona.

Rozwiązanie ZTNA – dostęp proxy

W tym modelu FortiGate może służyć jako proxy protokołów typu HTTP, SSH, RDP, SMB, FTP oraz innego ruchu TCP za pośrednictwem bezpiecznych połączeń z klientem. Umożliwia to bezproblemowy dostęp klienta do chronionych serwerów, bez konieczności tworzenia tuneli IPsec lub SSL VPN.

HTTPS access proxy

FortiGate access proxy działa jako reverse proxy dla serwera HTTP. Gdy klient łączy się ze stroną internetową hostowaną przez chroniony serwer, adres jest przekształcony do adresu VIP FortiGate access proxy (mapowanie adresu). FortiGate realizuje proxy połączenia i podejmuje kroki w celu uwierzytelnienia użytkownika. Odpytuje użytkownika o certyfikat w przeglądarce i weryfikuje to z rekordem endpointa ZTNA, który jest synchronizowany z EMS.

Jeśli skonfigurowano schemat uwierzytelniania (np. SAML), klient jest przekierowywany do captive portal w celu zalogowania się. Jeśli przejdzie proces logowania, ruch jest dozwolony na podstawie reguł ZTNA, a FortiGate zwraca stronę internetową do klienta. Przykładową konfiguracje ZTNA HTTPS access proxy można

TCP forwarding access proxy (TFAP)

TCP forwarding access proxy działa jako specjalny typ reverse proxy HTTPS. Zamiast proxy-owania ruchu do serwera WWW, ruch TCP jest tunelowany między klientem a serwerem proxy (FG) przez HTTPS i przekazywany do chronionego zasobu/serwera. FortiClient na endpoincie konfiguruje połączenie ZTNA, wskazując bramę proxy, a następnie określając host docelowy, z którym chce się połączyć. Nawiązywane jest połączenie HTTPS z FortiGate access proxy VIP, gdzie następuje weryfikacja certyfikatu klienta i przyznanie dostępu na podstawie reguł ZTNA. Ruch TCP jest przekazywany z FortiGate do chronionego zasobu i nawiązywane jest połączenie typu end-to-end.

Aby zmniejszyć narzut (uniknięcie podwójnego szyfrowania), można wyłączyć szyfrowanie po stronie klienckiej, ponieważ niektóre protokoły TCP, takie jak RDP, są już zaszyfrowane. TCP forwarding access proxy obsługuje skanowanie UTM i głęboką inspekcję HTTP, HTTPS, SMTP, SMTPS, IMAP, IMAPS, POP3, POP3S, SMB i CIFS. Przykładową konfiguracje można znaleźć tutaj.

Bezpieczny, zdalny dostęp - Rozwiązanie ZTNA vs. VPN

Z punktu widzenia użytkownika rozwiązanie ZTNA wydaje się być znacznie łatwiejsze w zarządzaniu niż tradycyjny VPN. Użytkownicy nie musza już pamiętać, kiedy korzystać z VPN lub jak nawiązać samo połączenie. Nie ma również zagrożenia, że tunele IPSec lub SSL pozostały przypadkowo otwarte, ponieważ ktoś zapomniał je rozłączyć. Dzięki ZTNA użytkownik po prostu „klika” aplikację i natychmiast uzyskuje bezpieczne połączenie, niezależnie od tego, czy aplikacja jest lokalna, w chmurze publicznej, czy w chmurze prywatnej.

Tunel tworzony jest na żądanie, w sposób niezauważalny dla użytkownika. Ponieważ sieć nie jest już strefą zaufania, taki sam tunel tworzony jest gdy użytkownik jest w sieci korporacyjnej lub poza nią. Tunel może być szyfrowany, w zależności od wykorzystywanego protokołu przesyłania danych. Dzięki temu zyskujemy bezpieczeństwo, bez potrzeby podwójnego szyfrowania w przypadku wykorzystania protokołów, które natywnie wspierają szyfrowanie.

Użytkownik wykorzystuje połączenie proxy, dzięki czemu aplikacja może znajdować się on-prem, w chmurze prywatnej czy publicznej i być w ukryciu przed Internetem. Aplikacja musi jedynie zestawić połączenie z punktem wykonawczym (ang. enforcement point), chroniąc ją przed hackerami lub botami.

Technologia ZTNA - wykorzystanie SASE

Podejście Zero Trust jest procesem, który dotyczy wielu systemów/produktów i może zająć sporo czasu organizacjom do pełnego wdrożenia. Zaadresowanie zdalnego dostępu jest dobrym pierwszym krokiem w kierunku wdrożenia pełnego Zero Trust. W chwili obecnej firmy posiłkują się modelem przejściowym i stosują mix rozwiązań VPN i ZTNA. Wielu dostawców ZTNA robi to w połączeniu z SASE (ang. Secure Access Service Edge). Takie podejście sprawia łatwe zarządzanie aplikacjami chmurowymi z punktu widzenia bezpieczeństwa chmurowego, ale może wiązać się ze kosztownymi opłatami SASE i może być ograniczona co do ilości i rodzaju obsługiwanych aplikacji.

Infrastruktura sieciowa bazująca na cyberbezpieczeństwie

Zbudowanie kompletnego rozwiązania Zero Trust wymaga różnych komponentów: klienta, proxy, uwierzytelniania i bezpieczeństwa. Często te rozwiązania są dostarczane przez różnych dostawców, które z kolei działają na różnych systemach operacyjnych i używają różnych konsol do zarządzania/konfiguracji. Może to prowadzić do tego, że takie multi-vendorowe kombinacje mogą być niemożliwe lub co najmniej skomplikowane.

Wybierając zintegrowane i zautomatyzowane narzędzia, CISO mogą minimalizować wyzwania związane z wdrażaniem ZTNA. Korzystając ze zintegrowanego podejścia opartego na firewall i SASE, mogą wykorzystywać funkcje ZTNA z uproszczonym zarządzaniem przy użyciu tych samych adaptacyjnych zasad dostępu do aplikacji, niezależnie od tego, czy użytkownicy są w sieci, czy poza nią.

ZTNA może być stosowany w przedsiębiorstwach, dla zdalnych i hybrydowych użytkowników z dostępem do sieci niezależnie od lokalizacji, biur domowych czy sklepów detalicznych, oferując kontrolowany zdalny dostęp do aplikacji, który jest łatwiejszy i szybszy do zainicjowania przy jednoczesnym zapewnieniu bardziej szczegółowego zestawu zabezpieczeń niż tradycyjne starsze sieci VPN.