Mikrosegmentacja zero-trust dla sieci obronnych: polityka i egzekwowanie

Bezpieczeństwo obwodowe zbudowano wokół prostego założenia: ruch pochodzący z wewnątrz granicy można uznać za zaufany. W sieci obronnej to założenie nigdy nie było w pełni prawdziwe, a w nowoczesnym środowisku hybrydowej chmury lub wieloenklawowym jest architektonicznie nie do utrzymania. Atakujący, który skompromitował pojedynczy punkt końcowy lub wykradł poświadczenia usługi, nie zatrzymuje się na obwodzie – przemieszcza się bocznie, eskalując od obciążeń o niskiej wartości do celów o wysokiej wartości. Mikrosegmentacja w ramach architektury zero-trust jest kontrolą, która ogranicza ruch boczny do pojedynczego skompromitowanego obciążenia, a nie do całej enklawy. Ten artykuł analizuje, jak projektować, egzekwować i utrzymywać politykę mikrosegmentacji opartą na tożsamości w sieciach obronnych, ze szczególnym uwzględnieniem obciążeń hostowanych w Kubernetes, dostarczania tożsamości obciążeń i mechanizmów egzekwowania wschód-zachód.

Dlaczego kontrole oparte wyłącznie na obwodzie zawodzą w środowiskach obronnych

Tradycyjne bezpieczeństwo sieci w środowiskach obronnych opiera się na segmentacji fizycznej i logicznej o dużej ziarnistości: osobne sieci dla różnych poziomów klasyfikacji, granice VLAN między obszarami funkcjonalnymi oraz reguły zapory na obwodzie każdego segmentu. Model ten ma dwie strukturalne słabości, które mikrosegmentacja ma zaadresować.

Płaski ruch wschód-zachód. W obrębie VLAN lub podsieci obciążenia zwykle komunikują się bez ograniczeń. Skompromitowany serwer aplikacji może dotrzeć do bazy danych, usługi uwierzytelniania, systemu zarządzania kluczami i każdej innej usługi w tej samej podsieci – nie dlatego, że istnieje polityka na to zezwalająca, lecz dlatego, że nie ma polityki tego zabraniającej. Koszt ruchu bocznego atakującego wewnątrz płaskiego segmentu jest niski.

Kompromitacja oparta na poświadczeniach przekracza obwody. Zapory obwodowe sprawdzają nagłówki pakietów, a nie tożsamość obciążenia. Wykradziony token konta usługi lub certyfikat, który był ważny dla komunikacji między dwiema usługami, jest równie ważny dla komunikacji z procesu atakującego działającego jako ta usługa. Zapora zezwala na ruch, ponieważ pochodzi on z poprawnego źródłowego adresu IP. Mikrosegmentacja z kryptograficzną tożsamością obciążenia rozwiązuje ten problem: podmiotem polityki nie jest adres IP, lecz kryptograficznie poświadczona tożsamość obciążenia, której atakujący nie może podszyć się bez dostępu do materiału klucza prywatnego – który jest efemeryczny i powiązany z obciążeniem.

Architektura mikrosegmentacji: domeny zaufania i granice polityki

Projekt mikrosegmentacji dla sieci obronnej zaczyna się od zmapowania przepływów komunikacji i pogrupowania obciążeń w domeny zaufania. Domena zaufania to zbiór obciążeń, które dzielą wspólną granicę autoryzacji i komunikują się swobodnie w obrębie grupy, ale wymagają jawnej polityki do komunikacji poza nią. W kontekście obronnym naturalne granice domen zaufania pokrywają się zarówno z poziomem klasyfikacji, jak i rolą funkcjonalną.

Dla typowej aplikacji obronnej hostowanej w niejawnym klastrze Kubernetes domeny zaufania mogą wyglądać następująco:

Domeny na poziomie klasyfikacji. Każda enklawa klasyfikacji – niejawna, CUI, SECRET – jest osobną domeną zaufania. Żadna komunikacja wschód-zachód nie przekracza granic klasyfikacji w płaszczyźnie mikrosegmentacji. Komunikacja między domenami jest kierowana wyłącznie przez akredytowane rozwiązanie cross-domain, które przeprowadza inspekcję treści i ponowne oznaczanie.

Domeny ról funkcjonalnych w obrębie poziomu klasyfikacji. W obrębie enklawy SECRET dalsza segmentacja według funkcji: usługi pozyskiwania (przyjmujące dane z zewnętrznych czujników), usługi przetwarzania (analityka i wzbogacanie), usługi przechowywania (bazy danych i magazyny obiektów), usługi command-plane (orkiestracja i harmonogramowanie) oraz usługi audytu (niezmienne logowanie). Każda domena funkcjonalna może odbierać ruch tylko z konkretnych domen partnerskich, których przepływy komunikacji są udokumentowane i zatwierdzone polityką.

Mapa przepływów komunikacji wynikająca z tego ćwiczenia – każda domena źródłowa, domena docelowa, port i protokół uzasadniony biznesowo – staje się autorytatywnym wejściem do tworzenia polityki. Każdy przepływ niewystępujący na mapie jest domyślnie odrzucany.

Tożsamość obciążenia: SPIFFE/SPIRE w środowiskach Kubernetes

Mikrosegmentacja oparta na tożsamości wymaga, aby każde obciążenie posiadało weryfikowalną tożsamość, którą płaszczyzna egzekwowania polityki może uwierzytelnić. Tożsamość oparta na adresie IP jest niewystarczająca w dynamicznych środowiskach kontenerowych, gdzie pody są efemeryczne, a adresy IP są poddawane recyklingowi. Standard SPIFFE (Secure Production Identity Framework For Everyone) definiuje przenośny, kryptograficzny model tożsamości obciążenia, który jest niezależny od podstawowej infrastruktury.

Tożsamość SPIFFE jest wyrażona jako URI: spiffe://trust-domain/path. We wdrożeniu Kubernetes z użyciem SPIRE (referencyjnej implementacji SPIFFE) każdy pod otrzymuje X.509 SVID (SPIFFE Verifiable Identity Document) – krótkotrwały certyfikat zawierający jego identyfikator SPIFFE jako Subject Alternative Name. Domena zaufania odpowiada klastrowi Kubernetes lub granicy federacji. Ścieżka koduje przestrzeń nazw Kubernetes i konto usługi, np. spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

Kluczową właściwością dla wdrożeń obronnych jest krótki TTL. SVID-y są wydawane z czasem życia 1 godziny (lub krótszym, konfigurowalnym) i automatycznie rotowane przez agenta SPIRE działającego na każdym węźle. Jeśli certyfikat zostanie skompromitowany, okno narażenia jest ograniczone przez TTL. Klucz prywatny nigdy nie opuszcza pamięci obciążenia – nie jest zapisywany na dysku ani dostępny dla innych procesów na tym samym węźle, nawet w kontekście współdzielonego klastra Kubernetes.

Atestacja węzłów w niejawnych klastrach

Atestor węzłów SPIRE to mechanizm, za pomocą którego nowy węzeł dołączający do klastra dowodzi swojej tożsamości, zanim zostanie mu pozwolone na wydawanie SVID-ów obciążeniom. W niejawnym środowisku Kubernetes atestor węzłów musi być dobrany tak, aby pasował do modelu zaufania. Dla niejawnego sprzętu on-premises preferowanym modelem jest atestacja oparta na TPM – wykorzystująca moduł Trusted Platform Module węzła do udowodnienia tożsamości sprzętowej. Serwer SPIRE waliduje klucz endorsement TPM wobec znanego dobrego manifestu, zanim autoryzuje węzeł do działania jako wydawca SVID. Oznacza to, że atakujący, który prowizjonuje nieautoryzowany węzeł, nie może uzyskać ważnych SVID-ów z serwera SPIRE, nawet jeśli ma dostęp sieciowy do serwera API klastra.

Egzekwowanie wschód-zachód: siatka usług i eBPF

Dostarczanie tożsamości obciążeń jest konieczne, ale niewystarczające – płaszczyzna egzekwowania musi faktycznie używać tych tożsamości do zezwalania na ruch lub jego blokowania. W utwardzonym środowisku Kubernetes egzekwowanie wschód-zachód jest zwykle warstwowane na trzech komplementarnych mechanizmach.

Kubernetes NetworkPolicy: baza L3/L4

Zasoby Kubernetes NetworkPolicy zapewniają deklaratywny sposób określania, które pody mogą się komunikować, używając selektorów etykiet podów i selektorów przestrzeni nazw do identyfikacji źródła i celu. Egzekwowanie NetworkPolicy jest obsługiwane przez wtyczkę CNI (Container Network Interface). Kluczowym ograniczeniem standardowej NetworkPolicy jest to, że działa na poziomie L3/L4 – może zezwalać lub blokować ruch między grupami podów na podstawie IP i portu, ale nie może sprawdzić tożsamości obciążenia nawiązującego połączenie, wywoływanej metody HTTP ani treści żądania. Dla obronnego modelu mikrosegmentacji wymagającego tożsamości kryptograficznej NetworkPolicy jest niezbędną bazą, ale nie kompletną kontrolą.

Siatka usług z wzajemnym TLS: egzekwowanie L7 świadome tożsamości

Siatka usług zainstalowana w trybie ścisłego wzajemnego TLS dodaje kryptograficzną weryfikację tożsamości do każdego połączenia wschód-zachód. Każde wywołanie usługa-usługa jest uwierzytelniane na warstwie transportowej: klient przedstawia swój SVID, serwer przedstawia swój SVID, a każdy weryfikuje drugiego wobec pakietu zaufania SPIFFE. Polityka autoryzacji siatki usług następnie ocenia uwierzytelniony podmiot (zweryfikowany identyfikator SPIFFE) wobec reguły polityki, zanim zezwoli na żądanie.

Dla wdrożeń obronnych siatka usług musi być skonfigurowana z bibliotekami kryptograficznymi zwalidowanymi według FIPS 140-2 lub FIPS 140-3. Zarówno Istio, jak i Linkerd mogą być kompilowane wobec BoringCrypto (zwalidowanego według FIPS) lub równoważnego. Zestawy szyfrów negocjowane dla mTLS muszą być ograniczone do zatwierdzonego zbioru – TLS 1.3 z AES-256-GCM-SHA384 jako minimum dla środowisk niejawnych. Pełna lista dozwolonych zestawów musi być udokumentowana jako część bazowej konfiguracji bezpieczeństwa systemu.

Egzekwowanie oparte na eBPF: polityka na poziomie jądra

Egzekwowanie siatki usług działa na warstwie proxy typu sidecar, który działa wewnątrz przestrzeni nazw sieci kontenera. Wystarczająco uprzywilejowany atakujący, który może skompromitować środowisko uruchomieniowe kontenera lub sam pod, może być w stanie obejść proxy sidecar. Egzekwowanie sieciowe oparte na eBPF (zaimplementowane przez wtyczki CNI takie jak Cilium) działa poniżej środowiska uruchomieniowego kontenera, na stosie sieciowym jądra Linux. Programy eBPF podłączone do haczyków jądra oceniają politykę sieciową, zanim pakiety zostaną dostarczone do jakiegokolwiek procesu w przestrzeni użytkownika – w tym do proxy sidecar. Obciążenie, które omija swoje proxy sidecar, nadal nie może dotrzeć do nieautoryzowanych celów, ponieważ warstwa egzekwowania eBPF odrzuca pakiet na poziomie jądra.

Połączenie NetworkPolicy + mTLS siatki usług + egzekwowania eBPF tworzy stos mikrosegmentacji typu obrona w głąb, w którym każda warstwa niezależnie egzekwuje politykę. Awaria w którejkolwiek pojedynczej warstwie nie skutkuje nieograniczonym ruchem bocznym.

Cykl życia polityki: tworzenie, testowanie i utrzymywanie reguł mikrosegmentacji

Polityka mikrosegmentacji nie jest jednorazową konfiguracją. Aplikacje obronne ewoluują, obciążenia są dodawane i usuwane, a wzorce komunikacji zmieniają się w miarę rozwoju funkcji. Model mikrosegmentacji, który jest poprawny w początkowym wdrożeniu, degraduje się z czasem, jeśli nie jest aktywnie utrzymywany.

Polityka jako kod. Polityka mikrosegmentacji powinna być wersjonowana wraz z kodem aplikacji. Każdy zasób NetworkPolicy, AuthorizationPolicy i CiliumNetworkPolicy powinien znajdować się w repozytorium wdrożeniowym aplikacji. Zmiany w polityce podlegają temu samemu procesowi przeglądu i zatwierdzania co zmiany kodu – w tym przeglądowi bezpieczeństwa dla każdej reguły rozszerzającej granicę zezwalania. Zapobiega to gromadzeniu się doraźnych wyjątków zapory poza kontrolą wersji.

Testowanie w trybie cienia. Przed zastosowaniem nowej lub zmodyfikowanej polityki w trybie egzekwowania przetestuj ją w trybie cienia (tylko logowanie). Zarówno siatka usług, jak i płaszczyzna egzekwowania eBPF mogą działać w trybie audytu, w którym naruszenia polityki są logowane, ale nie blokowane. Działanie w trybie cienia przez określony okres (zwykle jeden do dwóch tygodni w środowisku stagingowym odzwierciedlającym wzorce ruchu produkcyjnego) ujawnia nieudokumentowane przepływy, które polityka zablokowałaby, zanim spowodują awarie produkcyjne. Nieudokumentowane przepływy odkryte w testowaniu cienia muszą zostać przejrzane – uprawnione przepływy wyzwalają dodanie polityki, podczas gdy nieuprawnione przepływy są dowodem istniejącego problemu bezpieczeństwa.

Automatyczne wykrywanie dryfu polityki. Telemetria przepływów siatki usług (Hubble Istio, Viz Linkerd) zapewnia widok w czasie rzeczywistym całego ruchu wschód-zachód. Automatyczne narzędzia porównujące obserwowany ruch z zatwierdzoną mapą przepływów i alarmujące o odchyleniach są standardowym wymogiem operacyjnym dla obronnego wdrożenia mikrosegmentacji. Nowe przepływy pojawiające się bez odpowiadającej aktualizacji polityki są natychmiastowymi kandydatami do alertu – albo aplikacja zmieniła się bez aktualizacji dokumentacji polityki, albo nieautoryzowany podmiot generuje nieoczekiwany ruch.

Mikrosegmentacja w środowiskach wieloenklawowych i odizolowanych (air-gapped)

Sieci obronne często rozciągają się na wiele enklaw na różnych poziomach klasyfikacji, z których niektóre są w pełni odizolowane (air-gapped) od sieci zewnętrznych. Polityka mikrosegmentacji musi być spójna we wszystkich enklawach, nawet gdy nie istnieje współdzielona płaszczyzna zarządzania.

W odizolowanym niejawnym klastrze serwer SPIRE musi działać całkowicie on-premises. Korzeń PKI, który zakotwicza zaufanie SVID, nie może polegać na żadnym zewnętrznym urzędzie certyfikacji. Korzeniowy CA serwera SPIRE i pośrednie CA są generowane i zarządzane na odizolowanych HSM (Hardware Security Modules) w obrębie niejawnego środowiska. Listy unieważnień certyfikatów i usługi OCSP muszą podobnie działać w obrębie izolacji – wywołania sieciowe do zewnętrznej infrastruktury dla operacji PKI nie są dozwolone w niejawnych architekturach sieciowych.

Koordynacja mikrosegmentacji między enklawami – zapewnienie, że polityka zezwalająca na przepływ z enklawy CUI do enklawy niejawnej jest odzwierciedlona w zbiorach polityk obu enklaw – jest w większości programów procesem ręcznym i audytowalnym. Rozwiązanie cross-domain, które pośredniczy w ruchu między enklawami, jest autorytatywnym źródłem tego, jakie przepływy są dozwolone przez granicę; polityki mikrosegmentacji po obu stronach muszą być spójne z konfiguracją CDS i przeglądane jako całość podczas kontroli zmian polityki.