Zero Trust jest strategią bezpieczeństwa jest jedną z wielu różnych architektur, z których mogą korzystać przedsiębiorstwa w oparciu o ich specyficzne środowiska biznesowe, sieciowe i technologiczne. Ważne jest, aby architekci bezpieczeństwa dobrze rozumieli swoją obecną architekturę korporacyjną, aby podejmować świadome decyzje dotyczące niezbędnych zmian w inicjatywach Zero Trust.
Uważamy, że architektura korporacyjna ma szeroki zakres, w tym aplikacje, metody dostępu i przepływy danych, a także podstawową infrastrukturę sieciową i topologię sieci. Topologię sieci definiujemy jako logiczne spojrzenie na urządzenia i systemy oraz sposób ich wzajemnego połączenia. Sieci korporacyjne są zazwyczaj złożone, z wieloma współzależnymi częściami, takimi jak DNS, zarządzanie adresami IP i routing w sieciach LAN, WAN, chmurze i segmentach SD-WAN. Mogą również obejmować nowsze typy sieci, zwłaszcza środowiska IaaS.
Projekt Zero Trust Network Access (ZTNA) wymaga dobrego zrozumienia swojej sieci; gdzie działają prywatne zasoby przedsiębiorstwa; co jest z czym połączone (tj. jego topologia) i jak działają te współzależne systemy. ZTNA wymaga przemyślanych zmian w sposobie, w jaki użytkownicy uzyskują dostęp do zasobów w sieci, a także zmian w samej sieci. Korzyści płynące z ZTNA są znaczące, ale muszą być wdrażane w oparciu o dobrze opracowaną strategię.
Jakie są dwa podstawowe modele topologii sieci Zero Trust?
Istnieją dwa podstawowe modele topologii sieci Zero Trust, które nazywamy rutowalnymi w chmurze i rutowalnymi bezpośrednio. Firma Gartner określa je jako inicjowane przez usługi i inicjowane przez punkty końcowe, podczas gdy inni analitycy używają terminów „software-defined perimeter” i „identity-aware proxies”. Są one przedstawione na poniższych diagramach, gdzie używamy standardowych terminów Zero Trust: Policy Decision Point (PDP) do reprezentowania płaszczyzny sterowania i Policy Enforcement Point (PEP) do reprezentowania płaszczyzny danych. Należy również pamiętać, że w tej dyskusji skupiamy się tylko na dostępie użytkowników do prywatnych zasobów przedsiębiorstwa. Nie analizujemy dostępu użytkowników do publicznych zasobów sieciowych.
W obu przypadkach płaszczyzna sterowania znajduje się w infrastrukturze chmury bezpieczeństwa dostawcy. W ten sposób dostawcy dostarczają to jako usługę, zapewniając klientom zarządzanie, monitorowanie i aktualizacje, upraszczając w ten sposób operacje i zmniejszając złożoność.
Modele topologii sieci rutowanej w chmurze a modele sieci rutowanej bezpośrednio
W modelu rutowanym w chmurze, chmura dostawcy działa jako scentralizowane miejsce, w którym połączenia „spotykają się w środku”. Użytkownicy zdalni łączą się z najbliższym PEP dostawcy, aby kontrolować swój dostęp sieciowy do prywatnych zasobów przedsiębiorstwa. Zasoby, które mogą być aplikacjami biznesowymi lub danymi, mogą być uruchomione w lokalnym centrum danych, środowisku chmury IaaS lub w obu. Oprogramowanie konektora dostawcy działa obok zasobów i ustanawia połączenie wychodzące z najbliższym PEP w chmurze dostawcy. Ponieważ konektor nawiązuje połączenie wychodzące, zazwyczaj upraszcza wdrażanie, ale często ogranicza przypadki użycia do zdalnego dostępu użytkownika tylko do aplikacji internetowych.
Konsekwencje modelu rutingu w chmurze są takie, że cały ruch użytkownika musi przechodzić przez chmurę dostawcy, potencjalnie przez wiele przeskoków, ponieważ użytkownik i zasób przedsiębiorstwa łączą się z różnymi PEP dostawcy. Zwiększa to opóźnienia i wymaga od przedsiębiorstwa zaufania do dostawcy w zakresie tego ruchu. Sprawia to również, że architektura rutowana w chmurze jest nieodpowiednia dla użytkowników lokalnych uzyskujących dostęp do zasobów lokalnych. W takim przypadku ruch użytkownika jest kierowany w górę przez chmurę dostawcy i z powrotem do lokalizacji użytkownika, dlatego model ten jest często używany tylko do zdalnego dostępu, a nie do dostępu uniwersalnego. (Aby być uczciwym, niektórzy dostawcy wykorzystujący to podejście dodali lokalny routing dla użytkowników lokalnych, aby uniknąć tego problemu). Kolejną wadą jest brak możliwości obsługi wszystkich protokołów sieciowych lub połączeń inicjowanych przez serwer. Może obsługiwać aplikacje internetowe, ale boryka się z aplikacjami, które wymagają innych protokołów TCP, UDP lub ICMP, lub wymagają połączenia zainicjowanego z urządzeniem użytkownika, takim jak VOIP lub oprogramowanie do zdalnego sterowania IT.
Porównajmy to z modelem bezpośredniego rutingu. W tej architekturze chmura dostawcy jest używana tylko jako płaszczyzna sterowania. Płaszczyzna danych nigdy nie jest widoczna ani dostępna dla dostawcy, ponieważ przedsiębiorstwa wdrażają PEP dostawcy w swoich środowiskach, aby działały wraz z ich zasobami. Po uwierzytelnieniu użytkownicy uzyskują token bezpieczeństwa, który umożliwia im bezpieczne nawiązywanie połączeń bezpośrednio z PEP – stąd nazwa direct-routed. Ruch sieciowy przepływa między urządzeniem użytkownika a zasobem za pośrednictwem PEP. Minimalizuje to przeskoki sieciowe i zmniejsza opóźnienia. Ponadto routing ruchu jest kontrolowany przez przedsiębiorstwo, umożliwiając mu na przykład zarządzanie wymaganiami dotyczącymi rezydencji danych.
Model bezpośredniego rutingu obsługuje wszystkie protokoły sieciowe (internetowe, inne niż internetowe, dowolne protokoły TCP, UDP i ICMP) i płynnie obsługuje połączenia inicjowane przez serwer. Obsługuje również uniwersalną koncepcję ZTNA, ponieważ użytkownicy lokalni uzyskujący dostęp do zasobów lokalnych będą mieli ruch sieciowy pozostający całkowicie w lokalnej sieci korporacyjnej. Ponieważ PEP musi zostać wdrożony tam, gdzie znajdują się zasoby, zwykle wymagane są pewne zmiany w zaporze sieciowej. Ta architektura jest bardziej odpowiednia do obsługi najbardziej złożonych i wyrafinowanych środowisk korporacyjnych.
Dlaczego Appgate?
W Appgate mocno wierzymy w uniwersalne ZTNA i wybór klienta. W związku z tym zaprojektowaliśmy naszą natywną, dostarczaną w chmurze platformę Zero Trust dla modelu bezpośredniego rutingu oraz do obsługi wszystkich protokołów sieciowych i typów połączeń. Umożliwia to naszym klientom definiowanie całościowych zasad dostępu mających zastosowanie do wszystkich użytkowników na wszystkich urządzeniach, we wszystkich sieciach i środowiskach korporacyjnych. I akceptujemy fakt, że niektórzy użytkownicy mogą mieć agenta uruchomionego na swoim urządzeniu, podczas gdy inni nie mogą.
Bezpieczeństwo w przedsiębiorstwie jest trudne – sieci są złożone, aplikacje i wymagania stale się zmieniają, a wymagania biznesowe często kolidują z potrzebami w zakresie zgodności i bezpieczeństwa. Wierzymy, że dostęp Zero Trust jest lepszym sposobem na osiągnięcie celów związanych z bezpieczeństwem i biznesem oraz że potrzebujesz architektury, która będzie Cię wspierać, a nie ograniczać.
W tym celu Appgate SDP, najbardziej kompleksowe rozwiązanie ZTNA w branży, jest potężnym, niezwykle elastycznym rozwiązaniem, które można skonfigurować tak, aby spełniało dokładne wymagania bezpieczeństwa i zgodności, niezależnie od topologii sieci lub złożoności. Pięć filarów, na których opiera się konstrukcja systemu Appgate SDP to:
- Ukryta infrastruktura
- Zorientowanie na tożsamość
- Dynamiczność i ciągłość
- Mikro granice
- Progamowalność i adaptowalność
Filary te zapewniają, że klienci korporacyjni mogą wdrożyć platformę Zero Trust, która jest bezpieczna, adaptacyjna i skuteczna oraz która wykorzystuje wszystkie zalety modelu bezpośredniego routingu.
Na podstawie bloga naszego partnera, firmy Appgate: https://www.appgate.com/blog/zero-trust-network-topology-and-why-it-matters