Souveräne Cloud für Verteidigungsministerien: Datenresidenz, Kontrollebenen und nationale Cloud-Architektur

Von Corvus Intelligence Engineering Team · Über das Team →

25. Juni 2026 Aktualisiert: 25. Juni 2026 12 Min. Lesezeit

Jedes Verteidigungsministerium, das Workloads in die Cloud verlagert hat, sieht sich schließlich derselben Spannung gegenüber: Kommerzielle Hyperscaler bieten Fähigkeiten — verwaltete Datenbanken, KI/ML-Plattformen, globales Networking —, die kein nationaler Anbieter erreichen kann, doch dieselben Hyperscaler sind ausländische Unternehmen, die dem Rechtsverfahren, den Exportkontrollen und den Zugriffsverlangen des Nachrichtendienstes ihrer Heimatregierung unterliegen. Der Begriff „souveräne Cloud“ beschreibt den Versuch, diese Spannung aufzulösen, ohne einen der Extreme zu akzeptieren: weder die volle Abhängigkeit vom Hyperscaler noch einen technologisch eingefrorenen nationalen Großrechner. Die daraus entstehende Architektur ist nie einfach, und die Abwägungen sind selten offensichtlich, bevor sie in der Produktion getroffen wurden.

Dieser Artikel untersucht die technische Architektur der souveränen Cloud für Verteidigungsministerien — nicht als Beschaffungscheckliste, sondern als Ingenieursproblem. Wir behandeln, was Souveränität in jeder ihrer drei Dimensionen tatsächlich bedeutet, wie man eine nationale Kontrollebene entwirft, die eine Erschütterung des Anbieters übersteht, welche Hyperscaler-Komponenten ein inakzeptables Souveränitätsrisiko einführen, wie der souveräne Open-Source-Stack in der Produktion aussieht und wie man Souveränitätsbeschränkungen mit den operativen Fähigkeitsanforderungen der modernen Verteidigung in Balance bringt. Zum Kontext der breiteren Sicherheitsanforderungen für Workloads siehe unseren Leitfaden zur Cloud-Sicherheit militärischer Workloads.

1. Was Cloud-Souveränität für ein Verteidigungsministerium bedeutet

Den Begriff „souveräne Cloud“ nutzen Anbieter für nahezu alles — ein In-Land-Rechenzentrum, eine vertragliche Datenresidenzzusage, eine lokale Rechtsträgerin —, und fast nichts davon, was er im Anbietermarketing bedeutet, genügt einer ernsthaften Architekturprüfung eines Verteidigungsministeriums. Echte Cloud-Souveränität für die Verteidigung umfasst drei unterschiedliche Anforderungen, die unabhängig voneinander bewertet werden müssen, weil die Erfüllung der einen nicht die Erfüllung der anderen impliziert.

Datenresidenz ist die Garantie, dass klassifizierte oder sensible Daten ausschließlich im nationalen Hoheitsgebiet oder innerhalb einer genehmigten rechtlichen Grenze gespeichert, verarbeitet und übertragen werden — und dass das Ministerium, nicht der Cloud-Anbieter, die Verschlüsselungsschlüssel kontrolliert, die sie schützen. Datenresidenz ist die am häufigsten diskutierte Souveränitätsanforderung und die am leichtesten vorzutäuschende: Eine vertragliche Zusage, dass Daten im Land bleiben, ist gegen einen nachrichtendienstlichen Vorladungsbeschluss einer ausländischen Regierung rechtlich nicht durchsetzbar und bietet keinen technischen Schutz gegen einen falsch konfigurierten Replikationsjob, der Daten in eine Verfügbarkeitszone außerhalb des Landes kopiert.

Operationelle Souveränität ist die Fähigkeit, die Cloud-Plattform ohne die fortgesetzte Kooperation eines ausländischen Anbieters weiterzubetreiben — einschließlich der Fähigkeit, eine Insolvenz des Anbieters, kommerzielle Sanktionen, Änderungen der Exportkontrollen oder die erzwungene Dienstverweigerung oder -verschlechterung durch eine ausländische Regierung zu überstehen. Operationelle Souveränität erfordert, dass das Ministerium jede Komponente der Plattform allein aus Dokumentation und Quellcode betreiben kann, ohne laufende Abhängigkeit von proprietärem Anbietersupport, der zurückgezogen werden könnte.

Lieferkettensouveränität ist die Kontrolle über die Software- und Hardwarekomponenten, mit denen die Cloud aufgebaut und betrieben wird. Eine Plattform aus auditierbarer Open-Source-Software auf Servern eines nicht verbündeten Herstellers erfüllt keine der beiden Dimensionen: Die Softwareschicht mag auditierbar sein, die Hardware-Firmware aber möglicherweise nicht. Eine vollständige Analyse der Lieferkettensouveränität deckt Prozessor-Firmware, Betriebssysteme von Netzwerkgeräten, Storage-Controller-Firmware und die Softwarebibliotheks-Abhängigkeiten jeder Komponente des souveränen Stacks ab.

Die meisten souveränen Cloud-Architekturen von Verteidigungsministerien erfüllen heute die Datenresidenz teilweise, die operationelle Souveränität teilweise und die Lieferkettensouveränität minimal. Der Sinn der drei expliziten Dimensionen ist eine ehrliche Risikobewertung statt falscher Zusicherung durch eine „souveräne Cloud“-Zertifizierung, die nur die sichtbarste Dimension adressiert.

2. Durchsetzung der Datenresidenz

Technische Datenresidenz-Kontrollen wirken auf drei Ebenen: Schlüsselresidenz, Durchsetzung von Datenort-Policies sowie Audit und Verifikation. Alle drei sind erforderlich; jede allein genügt nicht.

Schlüsselresidenz ist die wichtigste technische Kontrolle, weil sie bestimmt, ob Daten außerhalb der genehmigten Grenze entschlüsselt werden können, selbst wenn sie physisch exfiltriert werden. Die Anforderung ist, dass das Hardware-Sicherheitsmodul (HSM) oder der Schlüsselverwaltungsdienst (KMS), der die Datenverschlüsselungsschlüssel hält, physisch im nationalen Hoheitsgebiet und unter der operativen Kontrolle des Ministeriums oder einer national akkreditierten Organisation steht — nicht der verwaltete KMS eines ausländischen Cloud-Anbieters, bei dem das letztliche Schlüsselmaterial in Hardware liegt, die der Anbieter kontrolliert. In der Praxis bedeutet das:

On-premises HSM (Thales Luna, Utimaco SecurityServer oder ein Äquivalent) für die höchsten Einstufungsstufen, wobei das HSM physisch gesichert und unter der physischen Sicherheitspolitik des Ministeriums geprüft wird
KMS eines nationalen Cloud-Anbieters mit In-Land-HSM-Hardware für niedrigere Einstufungsstufen, wo verwaltete Schlüsseldienste akzeptabel sind
Umschlagverschlüsselung (Envelope Encryption): Datenverschlüsselungsschlüssel (DEKs) werden pro Objekt oder pro Volume erzeugt und mit Schlüsselverschlüsselungsschlüsseln (KEKs) verschlüsselt, die im HSM liegen — das HSM hält niemals Rohdaten, nur Schlüsselmaterial
Schlüsselzugriffs-Protokollierung, die vom Audit-Log des Speichersystems getrennt und unabhängig ist, sodass unautorisierte Schlüsselzugriffsversuche sichtbar bleiben, selbst wenn die Speicherschicht kompromittiert ist

Durchsetzung von Datenort-Policies erfordert, dass Speicherdienste — Objektspeicher, Block-Volumes, Datenbankinstanzen — auf der Ebene der Plattformkonfiguration auf In-Land-Verfügbarkeitszonen beschränkt sind, nicht bloß durch eine Policy-Erklärung. In einer OpenStack-Bereitstellung bedeutet das die Konfiguration von Verfügbarkeitszonen-Affinitätsregeln in Cinder und Swift, die die Platzierung von Replikaten außerhalb der definierten Zone verhindern. In einer Hyperscaler-Bereitstellung bedeutet das die Nutzung von Service Control Policies (AWS) oder Azure-Policy-Definitionen, die die Erstellung jeglicher Speicherressource in Regionen außerhalb des Landes verweigern, angewendet auf der Ebene des Management-Accounts oder der Management-Group, damit einzelne Workload-Teams sie nicht außer Kraft setzen können.

Audit und Verifikation ist der kontinuierliche operative Prozess, der bestätigt, dass Datenresidenz-Kontrollen wie vorgesehen funktionieren. Die Audit-Schicht muss von der Speicherschicht unabhängig sein — die Entität, die Daten speichert, kann nicht die einzige Entität sein, die verifiziert, wo Daten gespeichert sind. Erforderliche Komponenten:

Automatisierte tägliche Verifikation, dass alle von Workloads genutzten Speicher-Endpunkte auf In-Land-IP-Adressen auflösen, mit Alarmierung bei jedem neuen Endpunkt
Netzwerkfluss-Überwachung, die jeglichen Egress-Verkehr von Speicherdiensten in IP-Bereiche außerhalb des Landes kennzeichnet
Vierteljährliches technisches Audit der Datenresidenz-Kontrollen durch Dritte, mit Befunden an die Sicherheitsbehörde des Ministeriums
Configuration-as-code für alle Datenort-Policies, versioniert in einem unveränderlichen Repository, sodass Policy-Änderungen vor ihrer Wirkung einen erkennbaren Diff erzeugen

Vertragliche Kontrollen — Datenverarbeitungsvereinbarungen, Datenlokalisierungsklauseln — sind eine notwendige Ergänzung technischer Kontrollen, sollten aber niemals der primäre Mechanismus sein. Verträge begrenzen, was ein kooperativer Anbieter tun wird; sie begrenzen nicht, was ein Anbieter unter gesetzlichem Zwang seiner Heimatregierung tut, und sie bieten keinen Schutz gegen technische Fehlkonfiguration.

3. Entwurf der nationalen Kontrollebene

Die Kontrollebene einer Cloud-Plattform — die Menge der Dienste, die Orchestrierung, Identität und Secrets verwalten — ist der Ort des wirkungsvollsten Souveränitätsrisikos. In einer Kubernetes-Umgebung sind die Komponenten der Kontrollebene der API-Server, der etcd-Cluster, der Scheduler, der Controller-Manager und die Admission-Webhooks, die zur Zeit der Workload-Erstellung Policies durchsetzen. Läuft eine dieser Komponenten auf Infrastruktur, die vom Betriebspersonal eines ausländischen Hyperscalers verwaltet wird, hat dieses Personal die technische Fähigkeit (selbst wenn vertraglich untersagt), Workload-Konfigurationen zu ändern, Secrets aus etcd zu extrahieren oder das Scheduling auf Anweisung der Heimatregierung zu stören.

Ein Entwurf der nationalen Kontrollebene bringt alle diese Komponenten auf Infrastruktur, die physisch und organisatorisch unter der Kontrolle des Ministeriums steht. Die praktische Architektur:

Kubernetes-API-Server und etcd. Stellen Sie eine selbstbetriebene Kubernetes-Distribution bereit — kubeadm für maximale Flexibilität, k0s für vereinfachten Betrieb oder Talos Linux für einen immutable-OS-Ansatz — auf Bare-Metal oder VMs auf ministeriell kontrollierten Hypervisoren. Der etcd-Cluster erfordert drei oder fünf Nodes für Quorum, auf dedizierter Hardware, die nicht mit Workload-Nodes geteilt wird. Etcd-Daten müssen über das KMS-Provider-Plugin, das an das nationale HSM angebunden ist, in Ruhe verschlüsselt sein. Sichern Sie etcd-Snapshots in verschlüsselten In-Land-Objektspeicher mit automatisierten Wiederherstellungstests.

# Example kube-apiserver flag for national KMS encryption provider
--encryption-provider-config=/etc/kubernetes/encryption-config.yaml

# encryption-config.yaml (excerpt)
resources:
  - resources: [secrets, configmaps]
    providers:
      - kms:
          name: national-hsm-kms
          endpoint: unix:///var/run/kmsplugin/socket.sock
          cachesize: 1000
          timeout: 3s
      - identity: {}

Identitätsanbieter. Keycloak ist der standardmäßige Open-Source-OIDC/SAML-Identitätsanbieter für souveräne Cloud-Bereitstellungen. Stellen Sie Keycloak auf dedizierter nationaler Infrastruktur bereit, integriert mit dem bestehenden Verzeichnis des Ministeriums (Active Directory oder LDAP über Keycloaks Föderations-Konnektoren). Konfigurieren Sie den Kubernetes-API-Server so, dass er Keycloak als OIDC-Authenticator nutzt:

# kube-apiserver OIDC flags
--oidc-issuer-url=https://keycloak.national.mil/realms/defense
--oidc-client-id=kubernetes
--oidc-username-claim=preferred_username
--oidc-groups-claim=groups
--oidc-ca-file=/etc/kubernetes/pki/keycloak-ca.crt

Die Verfügbarkeit von Keycloak ist nun der kritische Pfad für die Cluster-Authentifizierung. Stellen Sie es im Hochverfügbarkeitsmodus bereit (mindestens drei Keycloak-Instanzen hinter einem internen Load Balancer, mit verteiltem Cache für den Sitzungszustand) und dokumentieren Sie das Notfallverfahren (Break-Glass) für den API-Server-Zugriff, wenn Keycloak nicht verfügbar ist — typischerweise eine lokale kubeconfig mit einem Client-Zertifikat für den Notfall-Cluster-Admin-Zugriff, an einem physisch gesicherten Ort aufbewahrt.

Secrets-Management. HashiCorp Vault (oder sein Open-Source-Fork OpenBao), auf nationaler Infrastruktur betrieben, stellt die Secrets-Management-Schicht. Vault entsiegelt sich automatisch über das nationale HSM und eliminiert den manuellen Entsigelprozess, der sonst ein Single Point of Failure für die Wiederherstellung der Kontrollebene wäre. Das Audit-Log von Vault — jedes Lesen und Schreiben eines Secrets — wird in Echtzeit an das nationale SIEM übermittelt, außerhalb des Wirkungsradius einer kompromittierten Vault-Bereitstellung.

4. Bewertung der Hyperscaler-Abhängigkeiten

Die meisten Cloud-Umgebungen von Verteidigungsministerien nutzen mindestens einen Hyperscaler für eine Stufe ihrer Infrastruktur — sei es für eine souverän verbundene Topologie, eine Disaster-Recovery-Zone oder noch nicht migrierte Alt-Workloads. Zu verstehen, welche Hyperscaler-Komponenten Souveränitätsrisiko einführen, ist entscheidend für die Entscheidung verwaltet vs. selbstbetrieben je Komponente.

Hohes Souveränitätsrisiko — sollte ersetzt oder unabhängig betrieben werden:

Verwaltete Kubernetes-Kontrollebenen (EKS, AKS, GKE) — API-Server und etcd werden von Hyperscaler-Personal mit privilegiertem Zugriff betrieben; ersetzen durch selbstbetriebenes Kubernetes auf IaaS-Primitiven
Verwaltete Identitätsanbieter (AWS IAM, Azure Active Directory als primärer IdP) — maßgebliche Identitätsaussagen durch ausländisch betriebene Dienste; ersetzen durch Keycloak oder ein Äquivalent auf nationaler Infrastruktur
Verwaltete Secret-Stores (AWS Secrets Manager, Azure Key Vault mit Hyperscaler-kontrollierten HSMs) — Schlüsselmaterial in ausländischen HSMs; ersetzen durch selbstbetriebtes Vault auf nationalem HSM
Globale CDN- und Edge-Netzwerke — Datenverkehr über Points of Presence außerhalb des Landes geleitet; deaktivieren oder auf In-Land-Edge-Nodes beschränken

Mittleres Souveränitätsrisiko — mit zusätzlichen Kontrollen akzeptabel:

Hyperscaler-Objektspeicher in einer In-Land-Verfügbarkeitszone — akzeptabel, wenn mit ministeriell kontrollierten Schlüsseln aus einem nationalen HSM verschlüsselt und die Replikation auf In-Land-Zonen festgelegt ist
Hyperscaler-verwaltete Datenbanken in In-Land-Zonen — akzeptabel für nicht klassifizierte Daten, wenn das Verschlüsselungsschlüsselmanagement national ist und die regionsübergreifende Replikation deaktiviert ist
Hyperscaler-virtuelles Netzwerk — VPCs, Subnetze und Security Groups sind risikoarme IaaS-Primitive; das Souveränitätsrisiko liegt in der Kontrollebene, die sie verwaltet, nicht in den Primitiven selbst

Geringeres Souveränitätsrisiko:

IaaS-Compute (VMs) ohne verwaltete Agent-Frameworks — der Hyperscaler stellt die Hardware; das Ministerium betreibt den Software-Stack und kontrolliert die gesamte Verschlüsselung
Block-Speicher mit kundenverwalteten Schlüsseln aus einem nationalen KMS — der Hyperscaler hält verschlüsselte Blöcke, die ohne den Schlüssel des Ministeriums nicht entschlüsselt werden können

Das Ergebnis der Bewertung ist eine Komponenten-Risikokarte, keine binäre Entscheidung „Hyperscaler nutzen“ oder „Hyperscaler nicht nutzen“. Die meisten souveränen Cloud-Architekturen werden einige Hyperscaler-Komponenten auf der IaaS-Schicht behalten, während sie Kontrollebenen- und Identitätskomponenten durch nationale Alternativen ersetzen. Für eine breitere Sicht auf Bereitstellungsmodelle und ihre Einstufungsimplikationen siehe unseren Artikel zu Bereitstellungsmodellen für klassifizierte Clouds.

5. Architekturmuster: souverän verbunden vs. air-gapped souverän

Für souveräne Cloud-Bereitstellungen existieren zwei primäre Architekturmuster mit deutlich unterschiedlichen Kosten-, Fähigkeits- und operationellen Komplexitätsprofilen.

Die souverän verbundene Topologie nutzt die In-Land-Verfügbarkeitszone eines Hyperscaler-Rechenzentrums als IaaS-Schicht, wobei das Ministerium seine eigene Kontrollebene (Kubernetes, Keycloak, Vault) über den Compute- und Speicher-Primitiven des Hyperscalers betreibt. Der Hyperscaler stellt Hardware-Erneuerungszyklen, Rechenzentrumsbetrieb und physische Sicherheit; das Ministerium stellt Softwarebetrieb, Verschlüsselungsschlüsselmanagement und alle Kontrollebenen-Komponenten.

Diese Topologie gibt dem Ministerium Zugang zu den Skalenvorteilen, der Hardware-Zuverlässigkeit und den verwalteten Speicher- und Datenbankdiensten des Hyperscalers (mit entsprechenden Kontrollen), während die operationelle Souveränität auf der Softwareschicht erhalten bleibt. Die Souveränitätslücke liegt auf der physischen Hardware-Schicht: Die Rechenzentrumstechniker des Hyperscalers haben physischen Zugriff auf die Server, und die Lieferkette des Hyperscalers bestimmt, welche Hardware verfügbar ist. Für die meisten Verteidigungsministerien außerhalb der risikoreichsten Bedrohungsumgebungen ist das ein akzeptables Restrisiko — vorausgesetzt, die Verschlüsselungs- und Kontrollebenen-Architektur sorgt dafür, dass physischer Hardware-Zugriff weder Klartextdaten noch Kontrollebenen-Zugriff liefert.

Die souverän verbundene Topologie ermöglicht auch Burst-Kapazität: Ist die nationale Cloud-Infrastruktur des Ministeriums ausgelastet, können Workloads in die In-Land-Zone des Hyperscalers überlaufen, ohne Rechtsräume zu überschreiten. Das macht sie zur praktischen Wahl für Ministerien, die sowohl Souveränitätsanforderungen als auch moderne Fähigkeitsanforderungen erfüllen müssen, ohne die Kapitalausgaben einer Nationalinfrastruktur, die auf Spitzenlast ausgelegt ist.

Die vollständig nationale Cloud beseitigt die Hyperscaler-Abhängigkeit vollständig. Die gesamte physische Infrastruktur — Server, Netzwerkausrüstung, Storage-Arrays und das Rechenzentrum, das sie beherbergt — wird vom Ministerium oder einer national akkreditierten Organisation beschafft, besessen und betrieben. OpenStack stellt die IaaS-Schicht über dieser Hardware; Ceph stellt verteilten Speicher; Kubernetes stellt Orchestrierung.

Die Abwägungen sind erheblich. Die Kapitalausgaben liegen deutlich über denen einer souverän verbundenen Topologie. Beschaffungszyklen für Server und Netzwerkausrüstung sind lang — typischerweise 12-24 Monate von der Anforderung zur operationellen Fähigkeit. Hardware-Erneuerung erfordert neue Beschaffungszyklen. Der Bedarf an Betriebspersonal ist deutlich größer: OpenStack, Ceph, Kubernetes und Keycloak in Produktion zu betreiben, erfordert ein Team mit tiefem Fachwissen in allen vier Komponenten, das auf Vergütungsniveau des öffentlichen Dienstes sehr schwer zu besetzen ist. Und die Funktionslücke gegenüber Hyperscalern weitet sich mit der Zeit aus, da Hyperscaler stark in verwaltete KI/ML, Datenanalytik und Serverless-Plattformen investieren.

Die vollständig nationale Cloud ist die richtige Wahl für die Workloads der höchsten Einstufung, für Workloads mit harten Air-Gap-Anforderungen (keine physische oder Netzwerkverbindung zu kommerzieller Infrastruktur) und für Fähigkeiten, bei denen Lieferkettensouveränität auf der Hardware-Schicht eine feste Anforderung ist. Sie ist nicht die richtige Wahl für das allgemeine Workload-Portfolio eines modernen Verteidigungsministeriums — die operationelle Komplexität und die Funktionslücke sind zu hoher Preis für Souveränitätsanforderungen, die eine gut entworfene souverän verbundene Topologie erfüllen kann.

6. Souveräner Open-Source-Stack

Der kanonische Open-Source-Stack einer souveränen Cloud für die Verteidigung baut auf vier Komponenten auf, die zusammen die vollständige IaaS-, Speicher-, Orchestrierungs- und Identitätsplattform ohne proprietäre Abhängigkeiten und mit vollständig auditierbarem Quellcode bereitstellen.

OpenStack ist die IaaS-Schicht: Nova für Compute, Neutron für virtuelles Netzwerk, Cinder für Block-Speicher, Swift für Objektspeicher, Glance für Image-Verwaltung, Keystone für Dienstidentität und Katalog. OpenStack hat eine 15-jährige Produktionsgeschichte in Telco-, Regierungs- und wissenschaftlichen Rechenumgebungen. Die operationelle Komplexität ist real — OpenStack-Bereitstellungen erfordern ein dediziertes Plattformteam und sorgfältiges Change Management —, aber das Ökosystem aus Betreibern, Integratoren und Dokumentation ist gereift. Das Kolla-Ansible-Bereitstellungswerkzeug macht die Ersteinführung beherrschbar; die laufende operationelle Herausforderung ist das Upgrade-Management, das in einer Verteidigungsumgebung mit langsamen Change-Control-Prozessen sorgfältig geplant werden muss.

Ceph ist das verteilte Speicher-Backend. Es stellt Block-Speicher (RBD) für Cinder-Volumes, Objektspeicher (RGW) für Swift-kompatible APIs und ein gemeinsames Dateisystem (CephFS) für Workloads bereit, die POSIX-Semantik benötigen. Cephs Architektur verteilt Daten über alle Nodes des Clusters mit konfigurierbaren Replikationsfaktoren und bietet so Ausfallsicherheit gegen einzelne Node- oder Datenträgerausfälle ohne proprietäre Storage-Arrays. Die operationelle Komplexität liegt im Performance-Tuning — Ceph erfordert sorgfältige Hardware-Auswahl (NVMe-SSDs für OSD-Journale, Breitband-Netzwerk zwischen Nodes) und laufende Performance-Überwachung, um die „langsamen OSD“-Kaskaden zu vermeiden, die die Clusterleistung unter hoher Schreiblast beeinträchtigen können.

Keycloak ist der Identitätsanbieter. Es unterstützt OIDC, SAML 2.0, OAuth 2.0 und LDAP/AD-Föderation und ist damit die Integrationsstelle für die gesamte Authentifizierung im souveränen Stack: Kubernetes-API-Server-Authentifizierung, OpenStack-Keystone-Identitätsföderation, Vault-JWT-Authentifizierung und die Authentifizierung menschlicher Benutzer. Keycloaks Administrations-UI und REST-API stellen das operative Werkzeug für Benutzerverwaltung, Gruppenverwaltung und Client-(Anwendungs-)Registrierung. Das Hochverfügbarkeits-Bereitstellungsmodell — mehrere Keycloak-Instanzen mit gemeinsamem Infinispan-Verteil-Cache und einer gemeinsamen PostgreSQL-Datenbank — ist gut dokumentiert und produktionserprobt.

Kubernetes ist die Container-Orchestrierungsschicht. Mit kubeadm oder Talos Linux auf OpenStack-Nova-Compute-Instanzen bereitgestellt, liefert Kubernetes die Workload-Scheduling-, Service-Discovery- und Konfigurationsverwaltungsschicht, die Anwendungsteams konsumieren. Die zentrale Architekturanforderung des souveränen Stacks ist, dass die Kubernetes-Distribution upstream-kompatibel sein muss — keine verwaltete Hyperscaler-Variante —, damit die Kontrollebene unter ministerieller Kontrolle bleibt. Für Container-Netzwerk ist Cilium das bevorzugte CNI für Verteidigungsumgebungen wegen seiner eBPF-basierten Policy-Durchsetzung und tiefen Beobachtbarkeit ohne Sidecar-Proxy. Für die Speicherintegration stellt der Ceph-CSI-Treiber die Verbindung zwischen Kubernetes-PersistentVolumes und Ceph-RBD her.

Die operationelle Komplexität dieses Stacks darf nicht unterschätzt werden. OpenStack, Ceph, Kubernetes und Keycloak in Produktion zu betreiben, erfordert Spezialistenwissen in allen vier Komponenten, das in Regierungsorganisationen schwer zu gewinnen und zu halten ist. Realistisch braucht ein Ministerium, das diesen Stack einführt, entweder ein großes internes Plattformteam (20+ Ingenieure für eine mittelgroße Bereitstellung) oder einen beauftragten souveränen Integrator mit tiefem Fachwissen in allen vier Komponenten. Die Alternative — die operationelle Komplexität durch die Übernahme eines verwalteten Hyperscaler-Dienstes für einige Komponenten zu senken — muss gegen die Souveränitätsanforderungen abgewogen werden, die sie aufgibt. Für die Sicherheitskontrollen, die über diesem Stack laufen müssen, siehe unseren Artikel zu CSPM für Verteidigungs-Clouds.

7. Souveränität mit modernen Cloud-Fähigkeiten in Balance bringen

Das schwierigste Architekturproblem der souveränen Cloud für Verteidigungsministerien sind nicht die Souveränitätskontrollen selbst — es ist, diese Kontrollen aufrechtzuerhalten und zugleich die modernen Cloud-Fähigkeiten bereitzustellen, die Verteidigungsorganisationen zunehmend brauchen: Training und Inferenz von KI/ML-Modellen, Echtzeit-Datenanalytik, serverlose ereignisgesteuerte Architekturen und globale Kollaborationsplattformen. Hyperscaler haben Milliarden in verwaltete Versionen dieser Fähigkeiten investiert, die der souveräne Open-Source-Stack auf einer Dekaden-Zeitskala nicht erreichen kann.

IaC-Portabilität durch Terraform-Provider-Abstraktion ist der praktischste Mechanismus, diese Spannung zu steuern. Die Strategie: die gesamte Infrastruktur in providerneutralen Terraform-Modulen zu definieren — interne Abstraktionen, die konsistente Eingaben akzeptieren und konsistente Ausgaben erzeugen, unabhängig davon, ob der zugrunde liegende Provider OpenStack, AWS oder Azure ist. Die Modulschnittstelle eines „Compute-Clusters“ ist dieselbe, ob er auf OpenStack Nova oder AWS EC2 bereitgestellt wird; nur die Provider-Bindung ändert sich. Diese Abstraktion erhält die Option, Workloads zwischen dem souveränen nationalen Stack und einer souverän verbundenen Hyperscaler-Zone zu migrieren, ohne die Anwendungsinfrastruktur neu zu architektieren.

# Example provider-agnostic compute module interface
module "compute_cluster" {
  source        = "internal/modules/compute-cluster"
  name          = "sensor-processing"
  instance_type = "c5.4xlarge"  # resolved per provider
  count         = 3
  subnet_id     = module.network.private_subnet_id
  security_groups = [module.security.workload_sg_id]
  user_data     = file("cloud-init/sensor-processor.yaml")
}

# Bind to provider via workspace variable
# terraform.tfvars.national:  provider = "openstack"
# terraform.tfvars.govcloud:  provider = "aws-govcloud"

Alternativen zu verwalteten Diensten für die strategisch wichtigsten Funktionslücken:

KI/ML-Training: On-Premises-GPU-Cluster mit Kubeflow oder MLflow, beschafft bei Anbietern mit akzeptabler Lieferkettenposition; souverän verbundener Burst auf Hyperscaler-In-Land-GPU-Instanzen für Trainingsjobs, die die On-Premises-Kapazität übersteigen
Datenanalytik: Apache Spark auf Kubernetes (über den Spark-Operator) ersetzt verwaltete Analytics-Dienste; ClickHouse oder Apache Druid für Echtzeit-Analytik-Abfrageworkloads
Verwaltete Datenbanken: Operatoren für PostgreSQL (CloudNativePG), Redis (Redis Operator) und Kafka (Strimzi) bieten ein verwalteten Diensten ähnliches Betriebserlebnis auf selbstbetriebenem Kubernetes
Beobachtbarkeit: Prometheus, Loki und Grafana stellen den Metrik-, Loggings- und Visualisierungs-Stack ohne proprietäre verwaltete Observability-Abhängigkeiten

Die Fähigkeits-Roadmap für die souveräne Cloud muss als lebendes Programm behandelt werden, nicht als einmalige Bereitstellung. Die Lücke zwischen den Fähigkeiten des souveränen Stacks und verwalteten Hyperscaler-Diensten ist real, aber nicht statisch — das Open-Source-Ökosystem erzeugt kontinuierlich neue souveräne Alternativen zu proprietären verwalteten Diensten. Eine strukturierte Fähigkeitsüberprüfung alle sechs Monate — ein Abgleich der aktuellen Fähigkeiten des souveränen Stacks mit den aktuellen operativen Anforderungen und den aktuellen Hyperscaler-Alternativen — erlaubt dem Ministerium zu priorisieren, welche Lücken durch Open-Source-Übernahme geschlossen werden, welche durch souverän verbundenen Zugang zu Hyperscaler-In-Land-Diensten und welche als verbleibende Fähigkeitsbeschränkungen gegen Souveränitätsgarantien akzeptiert werden.

Zentrale Erkenntnis: Die souveräne Cloud für Verteidigungsministerien ist kein Produkt, das man kaufen kann — sie ist eine architektonische Haltung, die entworfen, gebaut, betrieben und laufend gepflegt werden muss. Die Ministerien, die darin erfolgreich sind, behandeln Souveränität als gleichrangige Ingenieuranforderung neben Performance, Zuverlässigkeit und Kosten, treffen explizite Abwägungen zwischen Souveränitätsdimensionen und Fähigkeit und bauen die operationelle Kompetenz auf, den souveränen Stack in Produktionsqualität zu betreiben. Wer sie als Compliance-Checkbox behandelt — eine „souveräne Cloud“-Anbieterzertifizierung erwirbt, ohne zu prüfen, ob die technischen Kontrollen Datenresidenz, operationelle Souveränität und Lieferkettensouveränität tatsächlich liefern —, wird die Lücke entdecken, wenn eine geopolitische Erschütterung oder eine Anbieterpolitikänderung sie offenlegt.

Die souveräne Cloud für Verteidigungsministerien ist letztlich eine Risikomanagement-Entscheidung, keine Technologieentscheidung. Die hier beschriebene Architektur — nationale Kontrollebene, technische Datenresidenz-Kontrollen, souveräner Open-Source-Stack, Terraform-Provider-Abstraktion für Portabilität — ist ein Satz von Werkzeugen zur Steuerung eines spezifischen Risikosatzes. Die richtige Architektur für ein gegebenes Ministerium hängt davon ab, welche Risiken in seiner Bedrohungsumgebung am trächtigsten sind, welche operationelle Fähigkeit mit dem verfügbaren Personal und Budget realistisch haltbar ist und wo auf der Abwägungskurve zwischen Souveränität und Fähigkeit seine Anforderungen für klassifizierte Workloads liegen. Diese Kalibrierung richtig zu treffen, erfordert ehrliche Bedrohungsbewertung und Ingenieursurteil — keine Anbieterzusicherung.

Ihr Projekt besprechen

Wir entwerfen und bauen souveräne Cloud-Architekturen für Verteidigungsministerien — von der Bereitstellung der nationalen Kontrollebene und der Durchsetzung der Datenresidenz bis zum Betrieb des Open-Source-Stacks und der IaC-Portabilität.

Sichere Cloud-Services → Briefing buchen

Diese Analyse wurde von Ingenieurinnen und Ingenieuren von Corvus Intelligence erstellt, die einsatzkritische Software für Verteidigungs- und Regierungsorganisationen entwickeln. Lernen Sie unser Team kennen →

Häufig gestellte Fragen

Was ist Cloud-Souveränität für ein Verteidigungsministerium?

Cloud-Souveränität für ein Verteidigungsministerium umfasst drei unterschiedliche, aber zusammenhängende Anforderungen. Datenresidenz ist die rechtliche und technische Garantie, dass klassifizierte oder sensible Daten ausschließlich im nationalen Hoheitsgebiet oder in genehmigten Rechtsräumen gespeichert, verarbeitet und übertragen werden — und dass das Ministerium, nicht ein Anbieter, die Verschlüsselungsschlüssel kontrolliert. Operationelle Souveränität ist die Fähigkeit, die Cloud-Plattform unabhängig von der weiteren Kooperation, Lizenzierung oder Dienstverfügbarkeit eines ausländischen Anbieters zu betreiben, einschließlich der Fähigkeit, Sanktionen, eine Insolvenz des Anbieters oder geopolitische Erschütterungen zu überstehen. Lieferkettensouveränität ist die Kontrolle über die Software- und Hardwarekomponenten, mit denen die Cloud aufgebaut und betrieben wird — sie stellt sicher, dass keine ausländische Regierung einen Anbieter zur Einfügung von Hintertüren oder zur Dienstverweigerung zwingen kann. Eine wirklich souveräne Cloud für die Verteidigung muss alle drei Dimensionen gleichzeitig adressieren; Architekturentscheidungen, die die Datenresidenz erfüllen, aber die operationelle oder Lieferkettensouveränität opfern, bieten schwächeren Schutz, als sie auf dem Papier erscheinen.

Was ist die Durchsetzung der Datenresidenz im Kontext einer Verteidigungs-Cloud?

Die Durchsetzung der Datenresidenz in der Verteidigungs-Cloud bedeutet, technische Kontrollen zu implementieren, die es physisch und kryptografisch unmöglich machen — nicht lediglich vertraglich untersagen —, dass Daten die definierte geografische oder rechtliche Grenze verlassen. Die wichtigsten Ebenen sind: Schlüsselresidenz (das HSM oder KMS, das die Datenverschlüsselungsschlüssel hält, muss physisch im Land und unter nationaler Kontrolle stehen, damit mit diesen Schlüsseln verschlüsselte Daten außerhalb der Grenze nicht entschlüsselt werden können, selbst wenn sie physisch exfiltriert werden); Datenort-Policies, die auf der Speicherebene durchgesetzt werden (Objektspeicher, Block-Volumes und Datenbank-Replikate müssen auf Inlands-Verfügbarkeitszonen beschränkt sein); Netzwerk-Egress-Kontrollen (Firewallregeln und DNS-Policies, die Datenpfade zu Endpunkten außerhalb des Landes blockieren); sowie Audit und Verifikation (kontinuierliche Überwachung, dass Kontrollen für ruhende und übertragene Daten nicht umgangen wurden, mit manipulationssicheren Protokollen, die vom eigenen Security-Operations-Team des Ministeriums geprüft werden statt vom Team des Anbieters).

Was ist eine nationale Kontrollebene und warum ist sie wichtig?

Die Kontrollebene einer Cloud-Plattform ist die Menge der Dienste, die Workload-Orchestrierung, Identität und Secrets verwalten — in einer Kubernetes-Umgebung sind dies der API-Server, etcd, der Scheduler und der Controller-Manager; im weiteren Cloud-Kontext gehören dazu der Identitätsanbieter, das Secrets-Management-System und die Verwaltungs-APIs. Läuft die Kontrollebene auf Infrastruktur, die ein ausländischer Hyperscaler verwaltet, kann das Betriebspersonal des Hyperscalers im Prinzip Workload-Konfigurationen ändern, Secrets extrahieren oder Operationen auf Anweisung der Heimatregierung stören. Eine nationale Kontrollebene betreibt diese Komponenten auf Infrastruktur, die physisch und organisatorisch unter der Kontrolle des Ministeriums steht, und beseitigt damit diese Abhängigkeit. Selbst bei Nutzung eines In-Land-Rechenzentrums eines Hyperscalers bedeutet eine nationale Kontrollebene, dass Kubernetes-API-Server, etcd-Cluster und Identitätsanbieter auf Hardware laufen, die dem Ministerium gehört oder vom Ministerium kontrolliert wird, während der Hyperscaler nur Compute-, Netzwerk- und Speicher-Primitive bereitstellt.

Welche Hyperscaler-Komponenten bringen das größte Souveränitätsrisiko mit sich?

Die Hyperscaler-Komponenten mit dem höchsten Risiko für ein Verteidigungsministerium sind: verwaltete Kubernetes-Kontrollebenen (EKS, AKS, GKE), bei denen API-Server und etcd auf Hyperscaler-Infrastruktur laufen und das Betriebspersonal des Hyperscalers privilegierten Zugriff hat; verwaltete Identitätsanbieter, bei denen die maßgebliche Identitätsaussage von Hyperscaler-kontrollierten Diensten getroffen wird; globale CDN- und Edge-Caching-Schichten, die Datenverkehr über Points of Presence außerhalb des Landes leiten; regionsübergreifende Replikationsfunktionen, die Daten in Verfügbarkeitszonen außerhalb des genehmigten Rechtsraums kopieren können; und verwaltete Secret-Stores, deren Schlüsselmaterial letztlich in Hyperscaler-kontrollierten HSMs liegt. Hyperscaler-IaaS-Komponenten — reines Compute, Block-Speicher und virtuelle Netzwerke ohne verwaltete Kontrollebene — bringen ein deutlich geringeres Souveränitätsrisiko mit sich, weil das Ministerium den Software-Stack darüber selbst betreibt und alle Verschlüsselungsschlüssel unabhängig kontrolliert.

Worin unterscheidet sich eine souverän angebundene Cloud von einer vollständig nationalen Cloud?

Die souverän verbundene Topologie nutzt ein In-Land-Rechenzentrum eines Hyperscalers mit einer ministeriell kontrollierten Kontrollebene darauf. Der Hyperscaler stellt IaaS bereit — Compute, Speicher, Netzwerk —, aber alle Orchestrierungs-, Identitäts- und Secrets-Management-Ebenen werden vom Ministerium oder einem vertrauenswürdigen nationalen Integrator betrieben. Das verschafft Zugang zu den Skalenvorteilen und verwalteten Diensten des Hyperscalers zum Preis der fortlaufenden Abhängigkeit von Hardwarebetrieb und Lieferkette des Hyperscalers. Eine vollständig nationale Cloud beseitigt die Hyperscaler-Abhängigkeit vollständig — die gesamte physische Infrastruktur wird vom Ministerium oder einem nationalen souveränen Anbieter beschafft, besessen und betrieben. Die Abwägungen sind deutlich höhere Kapitalausgaben, längere Beschaffungszyklen, größere operationelle Komplexität und eine Funktionslücke gegenüber verwalteten Hyperscaler-Diensten — aber maximale operationelle und Lieferkettensouveränität.

Welche Open-Source-Komponenten bilden den Kern eines souveränen Cloud-Stacks?

Der kanonische Open-Source-Stack einer souveränen Cloud besteht aus: OpenStack für IaaS (Compute über Nova, Objektspeicher über Swift, Block-Speicher über Cinder, Netzwerk über Neutron, Image-Verwaltung über Glance, Identität über Keystone); Ceph als verteilte Speicherschicht, die OpenStack-Cinder-Volumes und Swift-Objektspeicher unterlegt; Kubernetes als Container-Orchestrierungsschicht, bereitgestellt mit einer Upstream-Distribution (keiner verwalteten Hyperscaler-Variante), sodass API-Server und etcd unter ministerieller Kontrolle bleiben; und Keycloak als Identitätsanbieter sowohl für menschliche Benutzer (über OpenID Connect und SAML) als auch für Workloads (über OAuth 2.0 Client Credentials). Zusammen stellen diese vier Komponenten den vollständigen Cloud-Plattform-Stack ohne proprietäre Abhängigkeiten bereit. Die operationelle Komplexität ist deutlich höher als bei verwalteten Hyperscaler-Diensten, und das Ministerium muss das Fachwissen vorhalten, jede Komponente zu betreiben und zu patchen — aber die Souveränitätsgarantien sind absolut, weil der Quellcode jeder Komponente auditierbar ist und kein ausländischer Anbieter privilegierten operationellen Zugriff hat.

Wie unterstützt Terraform die Portabilität zwischen souveränen Cloud-Umgebungen?

Die Provider-Abstraktion von Terraform erlaubt es, Infrastruktur in providerneutralen Modulen zu beschreiben, wobei providerspezifische Implementierungen auf der Ebene des Root-Moduls ausgetauscht werden. Ein Portabilitätsmuster für souveräne Clouds definiert interne Modulschnittstellen — ein Compute-Cluster-Modul, ein verwaltetes Datenbank-Modul, ein Objektspeicher-Bucket-Modul —, die dieselben Eingaben akzeptieren und dieselben Ausgaben erzeugen, unabhängig davon, ob der zugrunde liegende Provider eine OpenStack-Bereitstellung, ein nationaler Cloud-Anbieter oder eine In-Land-Zone eines Hyperscalers ist. Muss das Ministerium wegen Anbieterrisiko, regulatorischer Änderung oder Fähigkeitsevolution von einer zugrunde liegenden Plattform auf eine andere migrieren, ändert sich nur die Provider-Bindung — die Workload-Moduldefinitionen, Deployment-Pipelines und Infrastrukturtests bleiben unverändert. Die praktische Grenze dieser Portabilität sind verwaltete Dienste: Ein Modul, das einen Hyperscaler-spezifischen verwalteten Datenbankdienst kapselt, lässt sich nicht trivial auf OpenStack portieren, ohne den zugrunde liegenden Dienst durch eine äquivalente selbstbetriebene Bereitstellung zu ersetzen.

Welche zentralen Risiken birgt eine souveräne Cloud für ein Verteidigungsministerium?

Die primären Risiken sind: Funktionslücke (nationale Cloud-Anbieter und Open-Source-Stacks liegen bei verwalteten KI/ML-Diensten, Serverless-Plattformen und globaler Netzwerkleistung oft mehrere Jahre hinter Hyperscalern zurück — das schränkt die moderne Fähigkeits-Roadmap ein); operationelle Komplexität (OpenStack, Ceph, Kubernetes und Keycloak intern zu betreiben, erfordert tiefes Fachwissen, das in der Verwaltung schwer zu gewinnen und zu halten ist); Lieferkettenrisiko in der Hardware (Server, Netzwerkausrüstung und Storage-Hardware von nicht-nationalen Lieferanten tragen eigene Risiken für die Lieferkettensouveränität — selbst eine vollständig nationale Cloud kann auf der Hardware-Ebene kompromittiert werden); und Scheinsouveränität (eine Cloud, die die Datenresidenz auf dem Papier erfüllt, aber Betriebspersonal des Hyperscalers mit privilegiertem Zugriff hat oder ausländische HSMs für das Schlüsselmanagement nutzt, liefert schwächere Garantien, als ihre Architekturdokumentation nahelegt). Risikomanagement erfordert, Souveränität als Spektrum mit mehreren unabhängig überprüfbaren Dimensionen zu behandeln statt als binäre Zertifizierung.

Wie sollten klassifizierte und nicht klassifizierte Workloads in einer souveränen Cloud getrennt werden?

Klassifizierte und nicht klassifizierte Workloads müssen auf der physischen Ebene getrennt werden — separate Kubernetes-Cluster auf separaten Node-Pools ohne gemeinsames etcd, ohne gemeinsame Kontrollebene und ohne gemeinsame Netzwerkinfrastruktur zwischen den Einstufungsstufen. Logische Trennung innerhalb eines einzelnen Clusters (Namespace-Isolation, NetworkPolicy) genügt nicht für Workloads unterschiedlicher Einstufungsstufen, weil eine Kontrollebenen-Schwachstelle oder ein Container-Ausbruch Namespace-Grenzen überschreiten kann. In der Praxis bedeutet das: separate OpenStack-Tenants mit physisch getrennten Ceph-Speicherclustern je Einstufungsstufe, separate Keycloak-Realms oder völlig getrennte Identitätsanbieter und separate CI/CD-Pipelines mit getrennten Signaturschlüsseln, sodass eine Kompromittierung der nicht klassifizierten Build-Pipeline keine bösartigen Images in die klassifizierte Stufe einschleusen kann. Datenübertragung zwischen den Stufen muss über eine formal evaluierte Cross-Domain-Lösung laufen, nicht über Netzwerkkonnektivität.

Wie sollte die Fähigkeiten-Roadmap eines Verteidigungsministeriums für souveräne Cloud aussehen?

Eine realistische Fähigkeits-Roadmap für eine souveräne Cloud eines Verteidigungsministeriums hat drei Phasen. Phase 1 (Jahre 1-2) legt das Fundament: Bereitstellen der nationalen IaaS-Schicht (OpenStack oder ein Äquivalent), Migrieren von Workloads von der kommerziellen Cloud auf In-Land-Infrastruktur, Implementieren von Datenresidenz-Kontrollen und nationalem Schlüsselmanagement sowie Bereitstellen der nationalen Kubernetes-Kontrollebene. Phase 2 (Jahre 2-4) baut die Plattformschicht: Keycloak für föderierte Identität, Terraform-basiertes IaC mit Provider-Abstraktion, eine interne Container-Registry mit Lieferkettenkontrollen (Image-Signierung, Schwachstellenscanning) und eine souverän verbundene Topologie mit einer Hyperscaler-In-Land-Zone für Burst und Resilienz. Phase 3 (Jahre 4+) zielt auf Fähigkeitsparität: souveräne verwaltete Datenbank- und Analytics-Dienste aufbauen oder beschaffen, KI/ML-Trainings-Infrastruktur on-premises bereitstellen, eine Zero-Trust-Architektur über alle Stufen hinweg implementieren und ein Framework für durchgehende Compliance-Automatisierung über alle Komponenten des souveränen Stacks etablieren.

Was ist der Unterschied zwischen einer souverän verbundenen und einer vollständig nationalen Cloud?