Multi-Cloud-Strategie für die Verteidigung: Vendor-Lock-in in militärischen Systemen vermeiden

Die Abhängigkeit von einem einzigen Cloud-Anbieter ist ein strategisches Risiko für Verteidigungssysteme, das analytisch der Abhängigkeit von einem einzigen Anbieter in jedem anderen kritischen Fähigkeitsbereich ähnelt. Wenn die gesamte Cloud-Infrastruktur eines Verteidigungsprogramms bei einem Anbieter betrieben wird, kann dieser Anbieter durch Preisgestaltung, Serviceeinstellung oder Vertragsänderungen bei der Programmverlängerung Druck ausüben. Geopolitische Entwicklungen können den Zugang zu ausländischer Cloud-Infrastruktur erschweren oder verhindern. Ein großer Cloud-Ausfall kann Verteidigungsbetriebsfähigkeiten, die von dieser Infrastruktur abhängen, beeinträchtigen oder beseitigen.

Die Multi-Cloud-Strategie begegnet diesem strategischen Risiko durch die Verteilung von Workloads auf mehrere Anbieter, die Aufrechterhaltung der Portabilität auf Architekturebene und die Vermeidung einer tiefen Verflechtung mit proprietären Cloud-Services, die eine Migration prohibitiv teuer machen würden. Dieser Artikel untersucht, wie Multi-Cloud-Deployment-Muster funktionieren, wie Cloud-agnostische Infrastructure-as-Code-Tools die Portabilität unterstützen und wie die Compliance-Komplexität bei der Aufrechterhaltung von Klassifizierungskontrollen bei mehreren Anbietern gemanagt wird.

Strategisches Risiko der Abhängigkeit von einem einzigen Cloud-Anbieter

Geopolitisches Risiko ist das am deutlichsten verteidigungsrelevante Risiko bei der Cloud-Anbieterabhängigkeit. Die Beziehung zwischen Verteidigungsorganisationen und Cloud-Anbietern wird durch politische und rechtliche Strukturen vermittelt, die sich ändern können. EU-Datensouveränitätsgesetzgebung (DSGVO, nationale Sicherheitsausnahmen, EUCS) schafft anhaltende Rechtsunsicherheit über die langfristige Legalität der Speicherung von Verteidigungsdaten auf der Infrastruktur von US-amerikanischen Anbietern.

Operatives Risiko durch Ausfälle ist ein unmittelbareres Anliegen. Große Cloud-Anbieter erleiden erhebliche Ausfälle: AWS us-east-1-Ausfälle in 2021 und 2023 störten große Teile des kommerziellen Internets für Stunden. Für Verteidigungssysteme mit Verfügbarkeitsanforderungen ist die Abhängigkeit von einem einzigen Cloud-Anbieter ohne Ausweichmöglichkeiten operativ inakzeptabel.

Preishebel ist ein kommerzielles Risiko mit strategischen Implikationen. Cloud-Anbieter können die Preise bei Vertragsverlängerung erhöhen; Wechselkosten bei tief verflochtenen Architekturen erschweren die Reaktion. DoDs Erfahrung mit den JEDI- und JWCC-Cloud-Vertragswettbewerben spiegelte das Bewusstsein für dieses Risiko wider.

Multi-Cloud-Deployment-Muster

Aktiv-aktive geteilte Workloads verteilen verschiedene Workload-Typen auf verschiedene Cloud-Anbieter basierend auf den komparativen Vorteilen jedes Anbieters: Ein Verteidigungsprogramm könnte klassifizierte Anwendungen beim Anbieter mit den stärksten Akkreditierungen für klassifizierte Cloud betreiben, Analyse- und ML-Workloads beim Anbieter mit der besten ML-Infrastruktur, und Kollaborationstools bei einem dritten EU-souveränen Anbieter aus Datenschutzgründen.

Primär-Sekundär-Notfallwiederherstellung betreibt Produktions-Workloads bei einem primären Anbieter mit einer Warm-Standby-Umgebung bei einem sekundären Anbieter. Die sekundäre Umgebung wird in ausreichender Bereitschaft gehalten, um innerhalb einer definierten RTO (Recovery Time Objective) zu übernehmen, wenn der primäre Anbieter ausfällt. Dieses Muster ist operativ einfacher, erfordert jedoch regelmäßige Failover-Tests.

Cloud-agnostisches IaC: Terraform und Crossplane

Terraform (von HashiCorp, jetzt ein BSL-lizenziertes Produkt mit einem Open-Source-Fork bei OpenTofu) ist das Standard-Infrastructure-as-Code-Tool für Cloud-agnostische Ressourcenbereitstellung. Terraform-Provider existieren für alle großen Cloud-Plattformen (AWS, Azure, GCP, OVHcloud und Dutzende anderer), und die Terraform-Konfigurationssyntax ist Cloud-agnostisch.

Für Multi-Cloud-Architekturen ermöglicht Terraforms Workspace- und Modulsystem die Instanziierung derselben Anwendungsinfrastruktur bei verschiedenen Anbietern: Ein Terraform-Modul für eine „dreischichtige Webanwendung" kann anbieterspezifische Implementierungen haben (eine für AWS, eine für Azure, eine für OVHcloud), die dieselbe Schnittstelle bereitstellen.

Crossplane ist ein CNCF-graduiertes Projekt, das eine Kubernetes-basierte Control Plane für die Cloud-Ressourcenbereitstellung bietet. Das Crossplane-Composition-System ermöglicht Cloud-Ressourcenabstraktion: Eine Composition definiert einen zusammengesetzten Ressourcentyp (z.B. eine „DefenceDatabase"), der auf anbieterspezifische Ressourcen abbildet, sodass Anwendungsteams eine DefenceDatabase anfordern können, ohne zu wissen, ob sie von AWS RDS, Azure Database for PostgreSQL oder einer lokalen PostgreSQL-Instanz unterstützt wird.

Crossplane ist besonders wertvoll für Verteidigungsprogramme, die ein Platform-Engineering-Modell einführen: Ein zentrales Plattformteam verwaltet die Crossplane-Compositions und Provider-Konfigurationen, und Anwendungsteams konsumieren Cloud-Ressourcen durch Self-Service.

Datenportabilität: Offene Formate und S3-kompatibler Speicher

Vendor-Lock-in auf Datenebene — wo Daten in proprietären Formaten oder Diensten ohne Standardexportmechanismus gespeichert sind — ist die schwierigste Form des Lock-in. Die Vermeidung erfordert explizites Datenportabilitätsdesign:

S3-kompatibler Objektspeicher ist der praktische Standard für Cloud-agnostische Datenspeicherung. Amazons S3-API ist zum De-facto-Standard für Objektspeicherung geworden, mit S3-kompatiblen APIs von Azure Blob Storage, GCP Cloud Storage, OVHcloud Object Storage und On-Premises-Lösungen wie MinIO.

Standard-SQL über verwaltete PostgreSQL-kompatible Datenbanken vermeidet den Lock-in proprietärer Datenbankdienste. Anwendungen, die Standard-SQL und das PostgreSQL-Protokoll verwenden, können bei Anbieterwechseln mit nur Konfigurationsänderungen migrieren.

Compliance-Komplexität: Klassifizierungskontrollen bei mehreren Anbietern

Die bedeutsamste betriebliche Herausforderung bei Multi-Cloud-Verteidigungsarchitekturen ist die konsistente Aufrechterhaltung von Klassifizierungskontrollen bei mehreren Anbietern, jeder mit verschiedenen Service-Fähigkeiten, verschiedenen Compliance-Zertifizierungen und verschiedenen Tools zur Implementierung von Sicherheitskontrollen.

Klassifizierungskontrollen — Zugriffskontrollen nach Freigabeberechtigung, Audit-Protokollierung jedes Zugriffs auf klassifizierte Daten, Verschlüsselungsschlüsselverwaltung, Datenschutzerzwingung — müssen äquivalent bei jedem Anbieter implementiert werden, der für klassifizierte Workloads verwendet wird.

Der praktische Ansatz besteht darin, eine anbieteragnostische Compliance-Schicht aufzubauen: einen Satz von Terraform/Crossplane-Modulen und Kubernetes-Admission-Controller-Richtlinien, die die erforderlichen Compliance-Kontrollen unabhängig davon implementieren, welcher Cloud-Anbieter die zugrundeliegenden Ressourcen bereitstellt.