Zero-Trust-Architektur ist ein Sicherheitsmodell, das auf der Annahme beruht, dass Vertrauen niemals implizit sein sollte — jede Zugriffsanfrage, von jedem Benutzer, Gerät oder jeder Anwendung, von jedem Netzwerkstandort aus, muss authentifiziert, autorisiert und kontinuierlich validiert werden, bevor der Zugriff gewährt wird. Das Modell entstand als Reaktion auf die Unzulänglichkeit der perimeterbasierter Sicherheit in Umgebungen, in denen der traditionelle Netzwerkperimeter aufgelöst ist: Cloud-Deployments, mobile Benutzer, Partnernetzwerkverbindungen und die Insider-Bedrohung machen das Konzept eines vertrauenswürdigen internen Netzwerks bedeutungslos.

Für militärische Netzwerke ist Zero-Trust keine durch Cloud-Adoption getriebene Wahl — es ist eine grundlegende Sicherheitsanforderung, die durch die Bedrohungslage getrieben wird. Militärische Netzwerke sehen sich Insider-Bedrohungen mit Zugang zu klassifizierten Systemen gegenüber. Sie verbinden sich mit Koalitionspartnernetzwerken unterschiedlicher Vertrauensniveaus. Sie stützen sich auf kommerzielle Endpunkte (Contractor-Laptops, mobile Geräte), die kompromittiert sein könnten. In diesem Umfeld ist jedes Sicherheitsmodell, das implizites Vertrauen auf der Grundlage des Netzwerkstandorts gewährt, gefährlich unzulänglich.

Warum Perimeter-Sicherheit bei der Verteidigung versagt

Das Perimeter-Sicherheitsmodell setzt voraus, dass Traffic, der aus dem Netzwerk-Boundary stammt, vertrauenswürdig ist. Diese Annahme scheitert in Verteidigungsumgebungen auf mehreren Ebenen. Insider-Bedrohungen — böswillige oder erpresste Insider mit legitimem Netzwerkzugang — sind in Hochsicherheitsumgebungen statistisch häufiger, genau weil diese Umgebungen Ziele für feindliche Infiltration sind. Ein Insider mit Zugang zu einem klassifizierten Netzwerksegment kann interne Netzwerkgrenzen überwinden, die Perimeter-Sicherheit nicht schützt.

Kompromittierte Endpunkte stellen ein Perimeter-Versagen auf Geräteebene dar: Eine Workstation innerhalb des Netzwerkperimeters, die durch eine Spear-Phishing-E-Mail kompromittiert wurde, trägt den Code eines Gegners in die vertrauenswürdige Zone. Von diesem kompromittierten Endpunkt aus kann der Angreifer laterale Bewegungen versuchen — auf andere Systeme zugreifen mit den Anmeldeinformationen und dem Netzwerkzugang der kompromittierten Maschine. Perimeter-Sicherheit hat keine Sichtbarkeit in diese lateralen Bewegungen, da sie keinen Traffic zwischen internen Hosts inspiziert.

Koalitionsnetzwerke schaffen Vertrauenskomplexität, mit der Perimeter-Modelle nicht umgehen können. NATO-Mitgliedsnationen teilen operative Netzwerke für spezifische Zwecke — Koalitions-Missionsplanung, gemeinsame Logistik, Luftlagebild-Teilen. Diese Verbindungen zwischen verschiedenen nationalen Netzwerken erfordern einen kontrollierten, policy-gesteuerten Zugang, den Perimeter-Sicherheit nicht mit der erforderlichen Granularität bieten kann. Zero-Trust, mit per-Benutzer- und per-Ressource-Zugriffsrichtlinien, ist der einzige Architekturansatz, der Koalitionsnetzwerkkonnektivität in der erforderlichen Granularität handhaben kann.

Zero-Trust-Kernprinzipien im militärischen Kontext

Explizit verifizieren. Jede Zugriffsanfrage muss mit starken Anmeldeinformationen authentifiziert und gegen Policy autorisiert werden, bevor der Zugriff gewährt wird. Multi-Faktor-Authentifizierung (MFA) ist der Basisstandard; hardware-basierte Authentifizierung (PIV/CAC-Karten) ist der DoD-Standard für Personalauthentifizierung. Maschinenidentität — die Authentifizierung von Computergeräten anstatt menschlicher Benutzer — verwendet Gerätezertifikate, um zu bestätigen, dass eine Anfrage von einem bekannten, verwalteten und konformen Gerät stammt. Eine Anfrage von einer gültigen Benutzeranmeldeinformation auf einem nicht verwalteten Gerät schlägt bei der Gerätepositionsüberprüfung fehl und wird abgelehnt oder quarantänisiert.

Zugang mit minimalen Rechten. Benutzer, Anwendungen und Services erhalten den Mindestzugang, der für ihre Funktion notwendig ist — nicht mehr. In militärischen Netzwerken entspricht dies den Need-to-know- und Need-to-access-Prinzipien, die für die Handhabung klassifizierter Informationen gesetzlich vorgeschrieben sind. Zero-Trust bietet den technischen Durchsetzungsmechanismus für das, was zuvor eine nur policy-basierte Anforderung war: rollenbasierte Zugriffskontrollen, die tatsächlich den Zugang zu Ressourcen verhindern, für die der Benutzer keine Berechtigung hat, durchgesetzt auf Anwendungs- und Datenschicht statt nur auf Netzwerkschicht.

Kompromittierung annehmen. Die Assume-Breach-Denkweise entwirft die Sicherheitsarchitektur unter der Annahme, dass ein Element des Netzwerks bereits kompromittiert ist: Überwachungs-, Erkennungs- und Reaktionsfähigkeiten werden so aufgebaut, als ob ein Angreifer bereits anwesend wäre, anstatt als ergänzende Maßnahmen für den unwahrscheinlichen Fall, dass die Perimeter-Sicherheit versagt. Dies treibt kontinuierliches Monitoring, Mikrosegmentierung (damit ein Breach eines Segments nicht automatisch Zugang zu allen anderen gewährt) und aggressives Logging aller Zugriffsereignisse für forensische Rekonstruktion an.

Implementierung: Identity Provider, mTLS und Mikrosegmentierung

Identity Provider für DoD-Umgebungen umfassen Microsoft Entra ID (ehemals Azure Active Directory) for Government, das FedRAMP-High-Autorisierung hält und CAC/PIV-Smart-Card-Authentifizierung durch seine Identitätsföderation-Fähigkeiten unterstützt. Oktas FedRAMP-autorisierte Plattform ist eine Alternative, die von einigen Defense-Programmen genutzt wird. Beide unterstützen SAML 2.0 und OpenID Connect für Anwendungsintegration und bieten bedingte Zugriffsrichtlinien, die Gerätekonformität, Benutzerrisikosignale und geografischen Kontext vor der Zugriffsgewährung bewerten.

Mutual TLS (mTLS) ist der Service-zu-Service-Authentifizierungsmechanismus in Zero-Trust-Architekturen. Während die benutzerseitige Authentifizierung Identity Provider und MFA verwendet, nutzt die Service-zu-Service-Kommunikation Zertifikate, die von Client und Server präsentiert werden, um beide Parteien zu authentifizieren. In einer Kubernetes-basierten Defense-Anwendung verwaltet ein Service-Mesh (Istio oder Linkerd) automatisch die mTLS-Zertifikatsausstellung und -rotation für die gesamte Inter-Service-Kommunikation und stellt sicher, dass selbst kompromittierte Microservices keine anderen Services im Mesh imitieren können, ohne gültige Zertifikate zu haben.

Mikrosegmentierung teilt das interne Netzwerk in kleine Zonen auf, jede mit ihrer eigenen Zugriffsrichtlinie, und ersetzt das flache interne Netzwerk, in dem East-West-Traffic uneingeschränkt ist. In einer Cloud-Umgebung wird Mikrosegmentierung durch Security-Group-Regeln und Netzwerkrichtlinien implementiert, die einschränken, welche Services mit welchen anderen Services kommunizieren können. In einer physischen militärischen Netzwerkumgebung wird Mikrosegmentierung durch Netzwerkzonendefinitionen, Inter-Zonen-Firewall-Regeln und SDN-Richtlinien (Software-Defined Networking) implementiert, die Traffic-Isolierung zwischen operativen, administrativen und klassifizierten Netzwerksegmenten durchsetzen.

Software-Defined Perimeter: VPN ersetzen

Traditionelles VPN bietet Netzwerk-Level-Zugang: Nach der Authentifizierung hat der VPN-Benutzer Zugang zu einem Netzwerksegment. Dies steht architektonisch im Widerspruch zu Zero-Trust, da Netzwerk-Level-Zugang laterale Bewegungsfähigkeiten gewährt. Software-Defined Perimeter (SDP) ersetzt VPN durch Anwendungs-Level-Zugang: Der Benutzer authentifiziert sich und erhält Zugang zu einer bestimmten Anwendung oder einem Service, nicht zu dem Netzwerksegment, in dem sie sich befinden.

SDP funktioniert durch einen gegenseitigen Authentifizierungs-Handshake, bevor Netzwerkpakete ausgetauscht werden (das „Black-Cloud"-Modell: der Service ist im Netzwerk unsichtbar, bis der Client authentifiziert ist). Nach der Authentifizierung wird eine dedizierte verschlüsselte Verbindung zwischen dem Client und der spezifischen Anwendung hergestellt — der Client kann andere Anwendungen oder Services in derselben Netzwerkzone weder sehen noch erreichen.

Für Verteidigungsorganisationen, die den Fernzugang für Auftragnehmer und Koalitionspartner verwalten, bietet SDP eine deutlich bessere Zugriffskontrolle als traditionelles VPN. Ein Koalitionspartner mit SDP-Zugang sieht nur die spezifischen Systeme, auf die er zugreifen berechtigt ist, ohne laterale Bewegungsfähigkeiten zu anderen Verteidigungssystemen — und eliminiert das Risiko, dass ein kompromittierter Koalitionspartner-Endpunkt zu einem Angriffsvektor in das breitere Verteidigungsnetzwerk wird.

DoD Zero-Trust-Referenzarchitektur und Auswirkungen auf Lieferanten

Die DoD Zero Trust Reference Architecture (ZT RA) definiert sieben Säulen: Benutzer, Gerät, Netzwerk/Umgebung, Anwendung/Workload, Daten, Automatisierung und Orchestrierung sowie Sichtbarkeit und Analytik. Die ZT RA ist keine Produktspezifikation, sondern ein Rahmen zur Bewertung, ob eine vorgeschlagene Architektur Zero-Trust-Prinzipien über alle sieben Dimensionen hinweg erfüllt.

Für Defense-Softwareanbieter hat die ZT RA praktische vertragliche Auswirkungen. Programme, die unter aktuellen DoD-Beschaffungsrichtlinien beschafft werden, müssen die Einhaltung von Zero-Trust-Prinzipien demonstrieren. Konkret: Anwendungen müssen Identitätsföderation mit DoD-genehmigten Identity Providern unterstützen (keine lokalen Benutzerdatenbanken führen, die das zentrale Identitätsmanagement umgehen); Netzwerkkommunikation muss verschlüsselt und gegenseitig authentifiziert sein; der Datenzugriff muss für Sichtbarkeit und Analytik protokolliert sein; und die Anwendung darf für keine ihrer Inter-Komponenten-Kommunikation Netzwerk-Layer-Vertrauen annehmen.

Kernaussage: Das DoD hat ein strategisches Ziel gesetzt, bis GJ2027 ein „gezieltes" Zero-Trust über alle DoD-Systeme zu erreichen und bis GJ2032 ein „erweitertes" Zero-Trust. Defense-Anbieter, die jetzt keine Zero-Trust-kompatiblen Architekturen in ihre Produkte integrieren, werden auf bestehenden Verträgen mit obligatorischer Nachbesserung und bei neuen mit Disqualifikation konfrontiert sein. Zero-Trust ist kein optionales Upgrade — es ist die Basis-Architekturanforderung für alle neuen DoD-Softwareprogramme.