Sovereign-Cloud-Washing: Fünf Fragen

“Sovereign Cloud” steht auf den Marketing-Seiten von AWS, Microsoft, Google und einer langen Liste europäischer Anbieter gleichermaßen. Die Aussage “Sovereign Cloud” kommt selten mit einer Definition — das macht es leicht, sie theoretisch zu erfüllen, und schwer zu verifizieren, was genau mit der Aussage gemeint ist. Ich habe fünf konkrete Fragen zu der Aussage erarbeitet, um zumindest einen Ansatz zu haben, mit dem sich die Aussage aus verschiedenen Blickwinkeln verifizieren lässt.

Das ist die deutsche Ausgabe von Teil 1 der Serie Digital Sovereignty in Practice.

Serien-Navigation: Die restlichen Teile dieser Serie sind aktuell nur auf Englisch verfügbar.

• Vollständiger Guide: Digital Sovereignty in Practice: The Complete Guide
• Teil 1 — Die fünf Fragen (dieser Beitrag)
• Teil 2 — Who Builds the Platform? Ownership vs. Stack
• Teil 3 — Who — or What — Has Access?
• Teil 4 — Legally-Enforced vs. Technically-Enforced: A Framework
• Teil 5 — Can You Leave? Data Portability, API Openness, and Egress in Practice
• Teil 6 — What Does It Cost to Leave — or Arrive? Switching Cost in Practice

Frage 1: Wem gehört das rechtlich und wie ist die Gesetzeslage?🔗

Eine Souveränitätsaussage beginnt meistens mit einer rechtlichen Zusicherung: In der EU registriert, Daten in einem EU-Rechenzentrum gespeichert. Das deckt nur die oberflächliche rechtliche Seite ab — nicht, wie die Eigentümerkette ist: eine Muttergesellschaft, ein Private-Equity-Eigentümer oder eine Holdingstruktur mehrere Ebenen höher — das wird auf der Marketing-Seite nie erwähnt.

Das konkret zu beantworten ist eine juristische Frage, keine technische — eine Eigentümerkette nachzuverfolgen und zu beurteilen, ist eine Gesellschaftsrechts- und Compliance-Frage, nicht etwas, wofür dieser Blog die Expertise hat. Was dieser Blog verantwortungsvoll tun kann, ist, die Rechtsfragen zu stellen, damit man diese einer Rechtsberatung weitergeben kann, statt dem Marketing zu glauben. Ein paar Eigentümerketten, die bei der Recherche zu Infrastrukturanbietern für einen unabhängigen technischen Vergleich gefunden wurden, machen den Punkt deutlich — vermutlich wäre keiner dieser Punkte auf einer Marketing-Seite offengelegt worden:

Quellen: OVHcloud-Newsroom zur Gridscale-Übernahme, One Equity Partners zur Gründung von CloudOne Digital, Oakley Capital zum Contabo-Exit an KKR, Telekom Austrias Übernahme von Exoscale 2018, und América Móvils 60,8-%-Anteil an A1 Telekom Austria.

Frage 2: Wie sieht die Technologie-Lieferkette aus, und wer — oder was — hat Zugriff darauf?🔗

Die rechtliche Sichtweise ist eine Ebene; der Technologie-Stack, der darunter läuft, und wer tatsächlich darauf zugreifen kann, sind zwei weitere Ebenen — und die drei müssen nicht deckungsgleich sein.

Die Lieferketten-Ebene. Open Telekom Cloud ist ein Beispiel dafür: Rechtlich im Besitz und Betrieb der Deutschen Telekom, was die Eigentumsfrage sauber beantwortet, während die Plattform selbst startete als OpenStack-basierter Dienst, der explizit als “powered by” Huawei vermarktet wurde, mit einem Huawei-Whitepaper, das FusionSphere als zugrunde liegende Plattform benennt. Die Deutsche Telekom betreibt den Dienst, aber der genaue aktuelle Hardware-/Software-Stack ist nicht öffentlich — ein Presseinterview aus 2025 zeigt, dass das Thema in diesem Jahr weiterhin öffentlich diskutiert wurde. Sauberes rechtliches Eigentum beantwortet für sich genommen nicht, worauf die Plattform aufgebaut ist. Weitere Beispiele desselben Musters bei anderen Anbietern sind Thema von Teil 2 dieser Serie.

Die Zugriffs-Ebene. Dieselbe Frage stellt sich eine Ebene tiefer: Wer oder was im Tagesgeschäft tatsächlich an das System herankommt — Support-Personal des Anbieters mit Notfallzugriff an den regulären Berechtigungen vorbei (Break-Glass), Drittanbieter-Dienstleister im Managed-Service, und zunehmend KI-Agenten mit API- oder Konsolen-Credentials, um Infrastruktur im Auftrag von jemandem zu betreiben. Eine Souveränitätsaussage darüber, wo Daten rechtlich liegen, sagt nichts darüber aus, ob dieser Zugriff dokumentiert ist, ob er geloggt und auditierbar ist, oder ob er technisch eingeschränkt ist — zeitlich begrenzte Credentials, Least-Privilege-Rollen, Einschränkungen dessen, worauf ein autonomer Agent zugreifen kann — statt sich auf eine Policy zu stützen, die sagt, Zugriff “sollte” eingeschränkt sein. Eine Plattform kann vollständig EU-eigen, EU-gebaut sein, und diese Frage trotzdem offenlassen.

Frage 3: Ist der Schutz rechtlich oder technisch durchgesetzt?🔗

Das ist die technische Umsetzungs-Seite der Zugriffsfrage oben: nicht nur, wer Zugriff haben sollte, sondern was tatsächlich verhindert, dass es passiert — und wie, falls die Policy-Antwort je versagt.

Die rechtliche Zusicherung ist eine rechtliche Aussage: “wir sind in der EU eingetragen, also unterliegen diese Daten nicht dem Zugriff einer ausländischen Regierung.” Rechtliche Aussagen haben Gewicht, aber sie beschreiben nur eine Policy-Position — eine, die durch künftige Gesetzgebung, Konzernumstrukturierung, oder ein Gerichtsurteil, das der Anbieter nicht vorhergesehen hat, getestet, neu interpretiert oder außer Kraft gesetzt werden kann. Die extraterritoriale Reichweite des US CLOUD Act, und vergleichbarer Regime wie FISA Section 702, ist in der Praxis unklar genug, dass Anbieter sich vernünftigerweise darüber uneinig sind, wie viel Schutz der Unternehmenssitz tatsächlich bringt.

Eine technische Garantie ist eine andere Art von Aussage: der Anbieter ist architektonisch unfähig, die Daten zu lesen — unabhängig davon, was ein Gericht anordnet. Vom Kunden gehaltene Verschlüsselungsschlüssel (BYOK — bring your own key) sind die klarste Version davon. Ein Vergleich der BYOK-Unterstützung von AWS, GCP, Azure und OVH — durchgeführt für einen unabhängigen Kosten- und Sicherheitsvergleich zur Log-Archivierung — fand bei allen vier eine Form von kundenverwalteten Schlüsseln, mit deutlich unterschiedlichen Betriebsmodellen. AWS KMS und Azure Key Vault halten den Schlüssel innerhalb eines Managed Service, dessen Lebenszyklus der Kunde kontrolliert. OVHs SSE-C-Modell geht weiter: der Kunde liefert den rohen Verschlüsselungsschlüssel bei jeder einzelnen API-Anfrage mit, und OVHs eigene Dokumentation sagt unmissverständlich, dass die Daten dauerhaft unlesbar werden, wenn der Schlüssel verloren geht — weil OVH ihn selbst nie speichert.

Das ist der Unterschied in der Praxis: nicht “wir versprechen, nicht hinzuschauen”, sondern “wir können nicht hinschauen, weil wir den Schlüssel nicht haben.” Ein rechtlich durchgesetztes Versprechen hängt davon ab, dass das Versprechen hält; ein technisch durchgesetztes hängt von gar keinem Versprechen ab. Der vollständige Anbieter-für-Anbieter-BYOK-Vergleich steht in Log Archiving Security & Compliance — Teil 4.

Frage 4: Kann man gehen?🔗

Die ersten drei Fragen prüfen die Souveränitätsaussage, wie sie heute steht. Diese hier prüft, was passiert, sobald sich eine dieser Antworten ändert — eine Übernahme, ein Wechsel des rechtlichen Firmensitzes, eine Änderung eines Exportkontrollregimes. Ein Anbieter, dessen Datenmodell in einem Standardformat exportiert, dessen Ingest- und Query-APIs nicht proprietär sind, und dessen Egress-Preise nicht so strukturiert sind, dass sie das Herausbewegen von Daten bestrafen, gibt einem Kunden einen echten Exit-Pfad, falls sich das Souveränitätsbild später ändert. Ein Anbieter, der die ersten drei Fragen gut beantwortet, die Daten aber hinter einem proprietären Format oder möglicherweise hohen Egress-Gebühren einsperrt, bietet Souveränität als Momentaufnahme an, nicht als dauerhafte Eigenschaft — gut, bis zu dem Tag, an dem “Gehen” zum eigentlichen Punkt wird.

Diese Frage bekommt in Teil 5 dieser Serie einen eigenen vertiefenden Beitrag; hier bleibt sie bewusst allgemein.

Frage 5: Was kostet es, zu gehen — oder anzukommen?🔗

On-Premises-Infrastruktur ist weitgehend souverän: es gibt keine dritte Partei. Die Ausnahmen sind allfällige Herstellerfirmen, die eventuell Zugriff auf die Systeme verlangen. Das macht es verlockend, bei der Frage “Cloud oder nicht Cloud” die Standardantwort “auf On-Prem bleiben” zu geben — aber das gilt nur, solange man sich die laufenden Kosten dieser Wahl auch weiter leisten kann oder will oder sogar muss. Das ist keine Theorie: Broadcoms Übernahme von VMware hat in den letzten Monaten und Jahren genau bei dieser weit verbreiteten Virtualisierungsplattform die Lizenzkosten drastisch angehoben. Die Kosten des Umzugs selbst werden meist unterschätzt — in beide Richtungen. Der Wechsel in eine Cloud, zwischen Clouds oder der teilweise Verbleib On-Premises bringt jeweils echte Kosten mit sich: Engineering-Zeit für die Neu-Architektur auf die Grundbausteine einer neuen Plattform, Prozessänderungen bei Deployments, Backups und Incident Response, und noch gar nicht bekannte Kosten, die erst während des Umzugs ersichtlich werden — etwa wenn eine Lock-in-Klausel oder eine Egress-Gebühr den Wechsel zu einem anderen Anbieter schwer einschätzbar macht.

Die menschliche Komponente gehört zu dieser Frage, sie ist kein separates Thema: Ein Wechsel ist nur so schnell und gut wie das Team, das die Zielplattform betreiben soll. Eine Souveränitätsentscheidung, die theoretisch sauber aussieht, kann in der Praxis monatelang an fehlendem Betriebs-Know-how hängen, das niemand eingeplant hat. Ein Anbieter, der bei den ersten vier Fragen gut abschneidet, aber den Aufbau operativer Kompetenz von Grund auf neu verlangt, macht den Wechsel nicht billiger — die Kosten, bekannte und unbekannte, verschieben sich auf die Zeit nach der Umsetzung beziehungsweise werden erst mitten in der Umsetzung ersichtlich.

Wie Frage 4 bekommt auch diese Frage einen eigenen vertiefenden Beitrag — in Teil 6 dieser Serie; hier bleibt sie bewusst allgemein.

Eine Checkliste, kein Ranking🔗

Die fünf Fragen, verdichtet zu etwas, das man auf jeden Anbieter mit einer Souveränitätsaussage anwenden kann — eine Checkliste, kein Ranking konkreter Anbieter:

“M&A” steht für “Mergers and Acquisitions” (Fusionen und Übernahmen).

Wenn man die fünf Fragen nun als eine Art Checkliste nutzt, kann man sich seine eigene Scorecard bauen und den oder die Cloud-Anbieter seiner Wahl damit abklopfen. Das ist dann etwas Handfestes, das man als verantwortliche Person sowohl für sich als auch für das Management nehmen kann, um zu checken, wie und ob ein bestimmter Anbieter zur eigenen Organisation und Risikolage passt.

Keine dieser fünf Fragen hat eine einzige richtige Antwort, die für jede Organisation gleichermaßen gilt. Eine Workload ganz ohne US-Berührung braucht möglicherweise keine technische Garantie zusätzlich zu einer rechtlichen; eine regulierte Workload unter Audit braucht typischerweise beides. Was das Ergebnis verändert, ist, die konkreten Fragen zu stellen und die Antworten ehrlich zu handhaben, statt Marketingaussagen einfach zu akzeptieren. Was das Ganze natürlich konterkariert, sind bereits getroffene Aussagen wie “Wir gehen zu Anbieter X.”

Weiter in dieser Serie: Teil 2 — Who Builds the Platform? Ownership vs. Stack → (aktuell nur auf Englisch verfügbar)

Verwandte Beiträge🔗

• Log Archiving Security & Compliance — Teil 4 — der BYOK- und Verschlüsselungsschlüssel-Vergleich hinter Frage 3
• AWS vs. GCP vs. Azure vs. OVHcloud: Managed Log Archiving — Teil 1 — wo die CLOUD-Act-/FISA-Rechtsunterscheidung erstmals im Kontext eines Kostenvergleichs auftauchte