Die Wahl einer Cloud-Plattform für Verteidigungsworkloads ist in erster Linie keine Technologieentscheidung — es ist eine Compliance- und Datensouveränitätsentscheidung. Die zugrundeliegende Recheninfrastruktur von Azure Government und AWS GovCloud ist ihren kommerziellen Äquivalenten weitgehend ähnlich. Was sich unterscheidet, ist die regulatorische Compliance-Haltung, die physische und logische Isolierung von kommerziellen Mietern, das Support-Modell und das maximal unterstützbare Klassifizierungsniveau.

Eine falsche Entscheidung hat Konsequenzen, die schwer rückgängig zu machen sind. Eine Verteidigungsanwendung nach der Bereitstellung im Produktivbetrieb von einer Cloud-Plattform auf eine andere zu migrieren, ist ein erhebliches Unterfangen auf Programmebene. Die Plattformauswahlentscheidung, früh getroffen, beschränkt die Architektur für die Lebensdauer des Programms.

Compliance-Rahmenwerke: FedRAMP, IL-Stufen und NATO-Anforderungen

Das primäre US-Compliance-Rahmenwerk für Cloud-Workloads ist FedRAMP (Federal Risk and Authorization Management Program), das drei Auswirkungsstufen definiert: Niedrig, Mittel und Hoch. FedRAMP High ist der Ausgangspunkt für sensible, aber nicht klassifizierte Regierungsdaten. Sowohl Azure Government als auch AWS GovCloud verfügen für die meisten Dienste über FedRAMP-High-Autorisierungen.

Über FedRAMP hinaus definiert der DoD Cloud Computing Security Requirements Guide (CC SRG) die Auswirkungsstufen 4 bis 6. IL4 umfasst kontrollierte, nicht klassifizierte Informationen (CUI) mit einer nationalen Sicherheitseinstufung. IL5 umfasst nationale Sicherheitssysteme (NSS) und klassifizierte DoD-Informationen bis SECRET. IL6 umfasst SECRET-Daten. Nur bestimmte, physisch isolierte Cloud-Regionen qualifizieren sich für IL5- und IL6-Workloads — nicht die Standard-GovCloud-Regionen.

Für NATO-Mitgliedsnationen außerhalb der USA sind die relevanten Rahmenwerke die Cloud-Sicherheitsanforderungen der NATO NCIA (Communications and Information Agency) und nationale Äquivalente. NATO NCIA hat nach eigenen Prüfprozessen bestimmte Cloud-Service-Angebote für NATO RESTRICTED und NATO CONFIDENTIAL-Daten genehmigt. Diese Genehmigungen werden nicht automatisch durch FedRAMP verliehen — eine separate Bewertung ist erforderlich.

Azure Government vs. AWS GovCloud: Wesentliche Unterschiede

Physische Isolierung. Beide Plattformen betreiben physisch getrennte Infrastruktur von ihren kommerziellen Clouds, die ausschließlich von überprüften US-Bürgern (für US-Programme) oder gleichwertigen nationalen Überprüfungsanforderungen betrieben wird. Beide bieten logische Trennung durch dedizierte Infrastrukturoptionen (dedizierte Hosts, Bare-Metal-Computing).

Verfügbarkeitsparität bei Diensten. Kommerzielle Cloud-Dienste erscheinen in GovCloud oft mit einer Verzögerung von 12–24 Monaten. AWS GovCloud hat historisch eine breitere Dienstkatalog-Parität mit kommerzialem AWS. Azure Government hat eine starke Parität in seinen Kern-IaaS- und PaaS-Diensten und hat die Abdeckung von KI/ML-Diensten erheblich verbessert, obwohl einige kommerzielle Azure-Dienste in der Government Cloud noch nicht verfügbar sind.

DoD-spezifische Dienste. Microsoft hält den DoD JEDI/JWCC-Vertrag und hat erhebliche Investitionen in IL5-fähige Azure Government-Regionen getätigt. AWS betreibt die C2S-Umgebung (Commercial Cloud Services) für die IC-Community und verfügt über IL5-fähige GovCloud East- und West-Regionen. Für Programme, die IL5 erfordern, sind beide geeignet — die spezifische Dienstverfügbarkeit bei IL5 variiert je nach Region und muss anhand der aktuellen Anbieterdokumentation überprüft werden.

Support-Modell. Beide Anbieter bieten dedizierte Government-Support-Stufen mit überprüftem Support-Personal an. Für Programme mit strengen operativen Sicherheitsanforderungen ist die Überprüfung, dass der Support-Zugang auf angemessen überprüftes Personal beschränkt und prüfbar ist, eine Vertragsanforderung, keine Annahme.

Hybrid-Cloud für klassifizierte Workloads

Die meisten Verteidigungsprogramme oberhalb der SECRET-Klassifizierung können keine Workloads in einer kommerziellen Cloud platzieren — nicht einmal in einer akkreditierten GovCloud-Region. Klassifizierte Workloads auf SECRET-Niveau und darüber müssen in akkreditierten, staatlich betriebenen oder auftragnehmerisch betriebenen Einrichtungen mit physischen Sicherheitskontrollen und SCIF-Niveau-Personalzugangsanforderungen laufen. Die Cloud ist für diese Workloads entweder eine private Cloud-Bereitstellung (staatseigene Hardware mit Cloud-ähnlicher IaaS) oder eine klassifizierte Cloud-Umgebung wie C2S oder Azure Government Top Secret.

Die praktische Architektur für die meisten Programme ist hybrid: nicht klassifizierte und CUI-Komponenten laufen in GovCloud, klassifizierte Komponenten laufen in einer privaten oder klassifizierten Cloud-Umgebung, und Cross-Domain-Lösungen (CDS) vermitteln den Datentransfer zwischen den beiden Umgebungen. Das CDS korrekt zu entwerfen — einschließlich der Datenvalidierungs-, Formatkonvertierungs- und Neuklassifizierungslogik — ist typischerweise eines der komplexesten und terminlich kritischsten Elemente der Architektur.

Datenspeicherort-Anforderungen

Viele Verteidigungsprogramme haben vertragliche oder rechtliche Anforderungen, die festlegen, wo Daten gespeichert und verarbeitet werden dürfen. Klassifizierte Daten von EU-Mitgliedstaaten können Einschränkungen unterliegen, die eine Speicherung in von den USA betriebener Infrastruktur (auch in US-eigenen europäischen Rechenzentren) verhindern. NATO-klassifizierte Daten unterliegen spezifischen Handhabungsanforderungen, die die Verarbeitungsorte einschränken.

Sowohl Azure als auch AWS haben Government-Cloud-Regionen in Europa (Niederlande, Deutschland) mit spezifischen Compliance-Haltungen für EU-Souveränitätsdatenanforderungen. Die Bewertung dieser Optionen erfordert eine rechtliche Prüfung der spezifischen Klassifizierungsanweisungen und nationalen Gesetze des Programms — nicht nur der Marketingmaterialien des Cloud-Anbieters.

Zentrale Erkenntnis: Zero-Trust-Architektur ist eine Anforderung, keine Wahl, für Cloud-Bereitstellungen im Verteidigungsbereich. Perimeter-basierte Sicherheitsannahmen (interner Datenverkehr ist vertrauenswürdig) sind architektonisch unvereinbar mit Multi-Tenant-Cloud- und Hybridumgebungen. Planen Sie von Beginn an für Authentifizierung pro Anfrage, Mikrosegmentierung und kontinuierliche Autorisierungsüberprüfung.

Zero-Trust-Baseline für Verteidigungs-Cloud

Die Zero-Trust-Referenzarchitektur des DoD definiert sieben Säulen: Nutzer, Gerät, Netzwerk, Anwendung/Workload, Daten, Automatisierung/Orchestrierung und Sichtbarkeit/Analytik. Für eine GovCloud-Bereitstellung bedeutet die Implementierung einer Zero-Trust-Baseline: identitätsbasierter Zugriff (Microsoft Entra ID / AWS IAM mit MFA und bedingtem Zugriff), Gerätehaltungsdurchsetzung (kein Zugriff von nicht verwalteten oder nicht konformen Geräten), Netzwerk-Mikrosegmentierung (Firewalling auf Anwendungsschicht, kein implizites Vertrauen zwischen Diensten im gleichen VNet/VPC) und datensklassifizierungsbasierte Zugriffskontrollen (Verschlüsselung im Ruhezustand mit kundenverwalteten Schlüsseln, Klassifizierungsbezeichnungen auf Anwendungsschicht durchgesetzt).

Multi-Tenant-Isolierung auf Infrastrukturebene — sicherstellend, dass der Workload eines Mieters nicht auf Daten oder Infrastruktur eines anderen Mieters zugreifen kann — wird vom Cloud-Anbieter garantiert. Was nicht garantiert wird, ist die Isolierung auf Anwendungsebene. Eine Multi-Tenant-Verteidigungsanwendung, die alle Mieterdaten in einer gemeinsamen Datenbank mit Zeilenebenensicherheit speichert, ist unabhängig von der verwendeten Cloud-Plattform nicht Zero-Trust-konform. Die Mieter-Isolierung muss auf Anwendungsebene implementiert und überprüft werden.