Zero-Trust-Mikrosegmentierung für Verteidigungsnetze: Richtlinie und Durchsetzung

Perimeter-Sicherheit wurde um eine einfache Annahme herum aufgebaut: Verkehr, der innerhalb der Grenze entsteht, könne vertraut werden. In einem Verteidigungsnetz war diese Annahme nie vollständig gültig, und in einer modernen hybriden Cloud- oder Multi-Enklaven-Umgebung ist sie architektonisch unhaltbar. Der Angreifer, der einen einzelnen Endpunkt kompromittiert oder Dienstanmeldeinformationen gestohlen hat, stoppt nicht am Perimeter – er bewegt sich lateral und eskaliert von niedrigwertigen Workloads zu hochwertigen Zielen. Mikrosegmentierung im Rahmen einer Zero-Trust-Architektur ist die Kontrolle, die laterale Bewegung auf die einzelne kompromittierte Workload statt auf die gesamte Enklave begrenzt. Dieser Artikel untersucht, wie identitätsbasierte Mikrosegmentierungsrichtlinien in Verteidigungsnetzen entworfen, durchgesetzt und gepflegt werden, mit besonderem Augenmerk auf Kubernetes-gehostete Workloads, die Bereitstellung der Workload-Identität und Ost-West-Durchsetzungsmechanismen.

Warum reine Perimeter-Kontrollen in Verteidigungsumgebungen versagen

Traditionelle Netzwerksicherheit in Verteidigungsumgebungen stützt sich auf physische und logische Segmentierung in grober Granularität: getrennte Netzwerke für verschiedene Klassifizierungsstufen, VLAN-Grenzen zwischen Funktionsbereichen und Firewall-Regeln am Perimeter jedes Segments. Dieses Modell hat zwei strukturelle Schwächen, die die Mikrosegmentierung adressieren soll.

Flacher Ost-West-Verkehr. Innerhalb eines VLAN oder Subnetzes kommunizieren Workloads typischerweise ohne Einschränkung. Ein kompromittierter Anwendungsserver kann die Datenbank, den Authentifizierungsdienst, das Schlüsselverwaltungssystem und jeden anderen Dienst im selben Subnetz erreichen – nicht weil es eine Richtlinie gibt, die es erlaubt, sondern weil es keine Richtlinie gibt, die es verweigert. Die Kosten der lateralen Bewegung des Angreifers innerhalb eines flachen Segments sind gering.

Anmeldeinformationsbasierte Kompromittierung überschreitet Perimeter. Perimeter-Firewalls inspizieren Paket-Header, nicht die Workload-Identität. Ein gestohlenes Dienstkonto-Token oder Zertifikat, das für die Kommunikation zwischen zwei Diensten gültig war, ist ebenso gültig für die Kommunikation aus dem Prozess des Angreifers, der als dieser Dienst läuft. Die Firewall lässt den Verkehr zu, weil er von der korrekten Quell-IP kommt. Mikrosegmentierung mit kryptografischer Workload-Identität adressiert dies: Der Richtlinien-Prinzipal ist keine IP-Adresse, sondern eine kryptografisch attestierte Workload-Identität, die der Angreifer ohne Zugriff auf das private Schlüsselmaterial – das ephemer und Workload-gebunden ist – nicht nachahmen kann.

Mikrosegmentierungsarchitektur: Vertrauensdomänen und Richtliniengrenzen

Ein Mikrosegmentierungsdesign für ein Verteidigungsnetz beginnt mit der Abbildung von Kommunikationsflüssen und der Gruppierung von Workloads in Vertrauensdomänen. Eine Vertrauensdomäne ist eine Menge von Workloads, die eine gemeinsame Autorisierungsgrenze teilen und innerhalb der Gruppe frei kommunizieren, aber eine explizite Richtlinie benötigen, um außerhalb davon zu kommunizieren. In einem Verteidigungskontext richten sich die natürlichen Grenzen der Vertrauensdomänen sowohl an der Klassifizierungsstufe als auch an der funktionalen Rolle aus.

Für eine typische Verteidigungsanwendung, die auf einem klassifizierten Kubernetes-Cluster gehostet wird, könnten die Vertrauensdomänen folgende sein:

Domänen auf Klassifizierungsebene. Jede Klassifizierungsenklave – nicht klassifiziert, CUI, SECRET – ist eine separate Vertrauensdomäne. Keine Ost-West-Kommunikation überschreitet Klassifizierungsgrenzen innerhalb der Mikrosegmentierungsebene. Die domänenübergreifende Kommunikation wird ausschließlich über eine akkreditierte Cross-Domain-Lösung geleitet, die Inhaltsinspektion und Neukennzeichnung durchführt.

Funktionale Rollendomänen innerhalb einer Klassifizierungsstufe. Innerhalb der SECRET-Enklave erfolgt eine weitere Segmentierung nach Funktion: Ingestion-Dienste (die Daten von externen Sensoren annehmen), Verarbeitungsdienste (Analytik und Anreicherung), Speicherdienste (Datenbanken und Objektspeicher), Command-Plane-Dienste (Orchestrierung und Planung) und Audit-Dienste (unveränderliche Protokollierung). Jede funktionale Domäne kann Verkehr nur von den spezifischen Peer-Domänen empfangen, deren Kommunikationsflüsse dokumentiert und richtlinienseitig genehmigt sind.

Die aus dieser Übung resultierende Kommunikationsflusskarte – jede Quelldomäne, Zieldomäne, Port und Protokoll, das geschäftlich begründet ist – wird zur maßgeblichen Eingabe für die Richtlinienerstellung. Jeder Fluss, der nicht auf der Karte steht, wird standardmäßig verweigert.

Workload-Identität: SPIFFE/SPIRE in Kubernetes-Umgebungen

Identitätsbasierte Mikrosegmentierung erfordert, dass jede Workload eine verifizierbare Identität besitzt, die die Richtliniendurchsetzungsebene authentifizieren kann. IP-adressbasierte Identität ist in dynamischen Container-Umgebungen, in denen Pods ephemer sind und IPs recycelt werden, unzureichend. Der SPIFFE-Standard (Secure Production Identity Framework For Everyone) definiert ein portables, kryptografisches Workload-Identitätsmodell, das unabhängig von der zugrunde liegenden Infrastruktur ist.

Die SPIFFE-Identität wird als URI ausgedrückt: spiffe://trust-domain/path. In einer Kubernetes-Bereitstellung mit SPIRE (der Referenzimplementierung von SPIFFE) erhält jeder Pod ein X.509-SVID (SPIFFE Verifiable Identity Document) – ein kurzlebiges Zertifikat, das seine SPIFFE-ID als Subject Alternative Name enthält. Die Vertrauensdomäne entspricht dem Kubernetes-Cluster oder der Föderationsgrenze. Der Pfad kodiert den Kubernetes-Namespace und das Dienstkonto, z. B. spiffe://defense.cluster/ns/analytics/sa/enrichment-worker.

Die kritische Eigenschaft für Verteidigungsbereitstellungen ist die kurze TTL. SVIDs werden mit einer Lebensdauer von 1 Stunde (oder weniger, konfigurierbar) ausgestellt und vom auf jedem Node laufenden SPIRE-Agenten automatisch rotiert. Wenn ein Zertifikat kompromittiert wird, ist das Expositionsfenster durch die TTL begrenzt. Der private Schlüssel verlässt nie den Speicher der Workload – er wird nicht auf die Festplatte geschrieben und ist für andere Prozesse auf demselben Node nicht zugänglich, selbst in einem gemeinsam genutzten Kubernetes-Cluster-Kontext.

Node-Attestierung in klassifizierten Clustern

Der Node-Attestor von SPIRE ist der Mechanismus, mit dem ein neuer Node, der dem Cluster beitritt, seine Identität nachweist, bevor ihm gestattet wird, SVIDs an Workloads auszustellen. In einer klassifizierten Kubernetes-Umgebung muss der Node-Attestor so gewählt werden, dass er zum Vertrauensmodell passt. Für klassifizierte On-Premises-Hardware ist die TPM-basierte Attestierung – unter Verwendung des Trusted Platform Module des Nodes zum Nachweis der Hardware-Identität – das bevorzugte Modell. Der SPIRE-Server validiert den TPM-Endorsement-Schlüssel anhand eines bekannten guten Manifests, bevor er den Node autorisiert, als SVID-Aussteller zu fungieren. Das bedeutet, dass ein Angreifer, der einen unautorisierten Node bereitstellt, keine gültigen SVIDs vom SPIRE-Server erhalten kann, selbst wenn er Netzwerkzugriff auf den Cluster-API-Server hat.

Ost-West-Durchsetzung: Service Mesh und eBPF

Die Bereitstellung der Workload-Identität ist notwendig, aber nicht ausreichend – die Durchsetzungsebene muss diese Identitäten tatsächlich verwenden, um Verkehr zuzulassen oder zu verweigern. In einer gehärteten Kubernetes-Umgebung wird die Ost-West-Durchsetzung typischerweise über drei sich ergänzende Mechanismen geschichtet.

Kubernetes NetworkPolicy: L3/L4-Basis

Kubernetes-NetworkPolicy-Ressourcen bieten eine deklarative Möglichkeit, festzulegen, welche Pods kommunizieren können, indem sie Pod-Label-Selektoren und Namespace-Selektoren verwenden, um Quelle und Ziel zu identifizieren. Die NetworkPolicy-Durchsetzung wird vom CNI-Plugin (Container Network Interface) gehandhabt. Die wesentliche Einschränkung der Standard-NetworkPolicy ist, dass sie auf L3/L4 operiert – sie kann Verkehr zwischen Pod-Gruppen basierend auf IP und Port zulassen oder verweigern, aber sie kann nicht die Identität der die Verbindung herstellenden Workload, die aufgerufene HTTP-Methode oder den Inhalt der Anfrage inspizieren. Für ein Verteidigungs-Mikrosegmentierungsmodell, das kryptografische Identität erfordert, ist NetworkPolicy eine notwendige Basis, aber nicht die vollständige Kontrolle.

Service Mesh mit Mutual TLS: L7-identitätsbewusste Durchsetzung

Ein im strikten Mutual-TLS-Modus installiertes Service Mesh fügt jeder Ost-West-Verbindung eine kryptografische Identitätsüberprüfung hinzu. Jeder Dienst-zu-Dienst-Aufruf wird auf der Transportebene authentifiziert: Der Client präsentiert sein SVID, der Server präsentiert sein SVID, und jeder verifiziert den anderen anhand des SPIFFE-Trust-Bundles. Die Autorisierungsrichtlinie des Service Mesh bewertet dann den authentifizierten Prinzipal (die verifizierte SPIFFE-ID) anhand einer Richtlinienregel, bevor die Anfrage zugelassen wird.

Für Verteidigungsbereitstellungen muss das Service Mesh mit nach FIPS 140-2 oder FIPS 140-3 validierten kryptografischen Bibliotheken konfiguriert werden. Sowohl Istio als auch Linkerd können gegen BoringCrypto (FIPS-validiert) oder Äquivalente kompiliert werden. Die für mTLS ausgehandelten Cipher-Suites müssen auf den genehmigten Satz beschränkt werden – TLS 1.3 mit AES-256-GCM-SHA384 als Minimum für klassifizierte Umgebungen. Die vollständige Liste der zulässigen Suites muss als Teil der Sicherheitskonfigurations-Baseline des Systems dokumentiert werden.

eBPF-basierte Durchsetzung: Richtlinie auf Kernel-Ebene

Die Service-Mesh-Durchsetzung operiert auf der Sidecar-Proxy-Ebene, die innerhalb des Container-Netzwerk-Namespace läuft. Ein ausreichend privilegierter Angreifer, der die Container-Laufzeit oder den Pod selbst kompromittieren kann, ist möglicherweise in der Lage, Sidecar-Proxys zu umgehen. Die eBPF-basierte Netzwerkdurchsetzung (implementiert durch CNI-Plugins wie Cilium) operiert unterhalb der Container-Laufzeit, auf dem Netzwerkstack des Linux-Kernels. eBPF-Programme, die an Kernel-Hooks angehängt sind, bewerten die Netzwerkrichtlinie, bevor Pakete an einen Userspace-Prozess geliefert werden – einschließlich des Sidecar-Proxys. Eine Workload, die ihren Sidecar-Proxy umgeht, kann unautorisierte Ziele dennoch nicht erreichen, weil die eBPF-Durchsetzungsebene das Paket auf Kernel-Ebene verweigert.

Die Kombination aus NetworkPolicy + Service-Mesh-mTLS + eBPF-Durchsetzung erzeugt einen Defense-in-Depth-Mikrosegmentierungsstapel, in dem jede Ebene die Richtlinie unabhängig durchsetzt. Ein Ausfall einer einzelnen Ebene führt nicht zu uneingeschränkter lateraler Bewegung.

Richtlinienlebenszyklus: Erstellen, Testen und Pflegen von Mikrosegmentierungsregeln

Mikrosegmentierungsrichtlinien sind keine einmalige Konfiguration. Verteidigungsanwendungen entwickeln sich weiter, Workloads werden hinzugefügt und entfernt, und Kommunikationsmuster ändern sich mit der Entwicklung von Funktionen. Ein Mikrosegmentierungsmodell, das bei der Erstbereitstellung korrekt ist, verschlechtert sich im Laufe der Zeit, wenn es nicht aktiv gepflegt wird.

Policy-as-Code. Mikrosegmentierungsrichtlinien sollten zusammen mit dem Anwendungscode versioniert werden. Jede NetworkPolicy-, AuthorizationPolicy- und CiliumNetworkPolicy-Ressource sollte im Bereitstellungs-Repository der Anwendung leben. Änderungen an Richtlinien durchlaufen denselben Überprüfungs- und Genehmigungsprozess wie Codeänderungen – einschließlich einer Sicherheitsüberprüfung für jede Regel, die eine Erlaubnisgrenze erweitert. Dies verhindert, dass sich ad hoc erstellte Firewall-Ausnahmen außerhalb der Versionskontrolle ansammeln.

Shadow-Mode-Tests. Bevor eine neue oder geänderte Richtlinie im Durchsetzungsmodus angewendet wird, testen Sie sie im Shadow-Modus (nur Protokollierung). Sowohl das Service Mesh als auch die eBPF-Durchsetzungsebene können in einem Audit-Modus arbeiten, in dem Richtlinienverletzungen protokolliert, aber nicht blockiert werden. Der Betrieb im Shadow-Modus über einen definierten Zeitraum (typischerweise ein bis zwei Wochen in einer Staging-Umgebung, die Produktionsverkehrsmuster widerspiegelt) bringt undokumentierte Flüsse ans Licht, die die Richtlinie blockieren würde, bevor sie Produktionsausfälle verursachen. Im Shadow-Test entdeckte undokumentierte Flüsse müssen überprüft werden – legitime Flüsse lösen Richtlinienergänzungen aus, während illegitime Flüsse ein Beweis für ein bestehendes Sicherheitsproblem sind.

Automatisierte Richtliniendrift-Erkennung. Service-Mesh-Fluss-Telemetrie (Hubble von Istio, Viz von Linkerd) bietet eine Echtzeitansicht des gesamten Ost-West-Verkehrs. Automatisierte Werkzeuge, die beobachteten Verkehr mit der genehmigten Flusskarte vergleichen und bei Abweichungen alarmieren, sind eine Standard-Betriebsanforderung für eine Verteidigungs-Mikrosegmentierungsbereitstellung. Neue Flüsse, die ohne eine entsprechende Richtlinienaktualisierung auftreten, sind unmittelbare Alarmkandidaten – entweder hat sich die Anwendung geändert, ohne ihre Richtliniendokumentation zu aktualisieren, oder ein unautorisierter Akteur erzeugt unerwarteten Verkehr.

Mikrosegmentierung in Multi-Enklaven- und Air-Gapped-Umgebungen

Verteidigungsnetze erstrecken sich häufig über mehrere Enklaven auf verschiedenen Klassifizierungsstufen, von denen einige vollständig von externen Netzwerken abgeschottet (Air-Gapped) sind. Die Mikrosegmentierungsrichtlinie muss über alle Enklaven hinweg kohärent sein, selbst wenn es keine gemeinsame Verwaltungsebene gibt.

In einem Air-Gapped-klassifizierten Cluster muss der SPIRE-Server vollständig on-premises betrieben werden. Der PKI-Root, der das SVID-Vertrauen verankert, kann sich auf keine externe Zertifizierungsstelle stützen. Die Root-CA und die Intermediate-CAs des SPIRE-Servers werden auf Air-Gapped-HSMs (Hardware Security Modules) innerhalb der klassifizierten Umgebung generiert und verwaltet. Zertifikatssperrlisten und OCSP-Dienste müssen ebenfalls innerhalb des Air Gaps betrieben werden – Netzwerkaufrufe an externe Infrastruktur für PKI-Operationen sind in klassifizierten Netzwerkarchitekturen nicht erlaubt.

Die enklavenübergreifende Mikrosegmentierungskoordination – die Sicherstellung, dass eine Richtlinie, die einen Fluss von der CUI-Enklave zur nicht klassifizierten Enklave erlaubt, in den Richtliniensätzen beider Enklaven gespiegelt wird – ist in den meisten Programmen ein manueller und auditierbarer Prozess. Die Cross-Domain-Lösung, die den enklavenübergreifenden Verkehr vermittelt, ist die maßgebliche Quelle dafür, welche Flüsse über die Grenze erlaubt sind; die Mikrosegmentierungsrichtlinien auf beiden Seiten müssen mit der CDS-Konfiguration konsistent sein und als Einheit während der Richtlinienänderungskontrolle überprüft werden.