Souveräne Cloud: Wo bei den Hyperscalern die Kontrolle endet

In Woche 1 ging es um das DORA-Oversight und damit um die Aufsicht über die großen Cloud-Anbieter. Aus der Abhängigkeit von den Hyperscalern ist dort ein offizielles Aufsichtsthema geworden. Diese Woche drehe ich die Perspektive um und schaue auf die Antwort, welche der Markt darauf gibt, nämlich die souveränen Ableger von AWS, Microsoft und Google. „Souverän” steht auf jeder zweiten Folie. Ich gehe der Frage nach, was der Begriff bei diesen Angeboten bedeutet und an welcher Stelle die Kontrolle des Instituts endet.

Was die Hyperscaler heute anbieten

Alle drei großen Anbieter haben seit Anfang 2026 eigene souveräne Angebote am Markt. Die Konstruktionen unterscheiden sich, das Muster ist ähnlich.

Anbieter	Angebot	Konstruktion
AWS	European Sovereign Cloud	Eigene Rechtsperson nach deutschem Recht, ausschließlich in der EU ansässiges Personal, Abrechnung in Euro und ein Rechenzentrum in Brandenburg. Selbst Metadaten verbleiben in der EU.
Microsoft	Sovereign Cloud, Microsoft 365 Local, Delos Cloud	Dienste wie Exchange und SharePoint auf kundeneigener Hardware, dazu die Delos Cloud auf Azure-Basis unter deutschem Betrieb.
Google	Sovereign Cloud	Partnermodelle, in Deutschland mit T-Systems, in Frankreich über S3NS mit Thales. Die Stufen reichen von cloud-controlled bis air-gapped.

Microsoft 365 Local läuft auf kundeneigener Hardware, abgekoppelt von der öffentlichen Cloud. Das bedeutet eine Rückkehr zu den Wurzeln. Bis vor wenigen Jahren waren die Kunden gewohnt, Exchange- und SharePoint-Server im eigenen Rechenzentrum zu betreiben. Diese Rückbesinnung wird jetzt als Souveränitätslösung verkauft. Bei staatlichen Aufträgen und kritischer Infrastruktur wird noch ein Detail wichtig. AWS legt für sein Personal den Wohnsitz in der EU zugrunde, das BSI stellt dagegen auf die Staatsangehörigkeit ab. Für einen Teil der Anwendungsfälle ist dieser Unterschied erheblich.

Drei Fragen, die oft vermischt werden

Wie viel Souveränität in diesen Angeboten steckt, hängt an drei Fragen, die im Marketing gern zu einer verschmelzen. Die erste ist die Datenresidenz, also der Ort, an dem die Daten liegen. Davon zu trennen ist die Betreiberkontrolle: Wer kann technisch und operativ auf die Daten zugreifen, sei es über den laufenden Support oder über den Mutterkonzern? Die dritte ist die Jurisdiktion, die bestimmt, welchem Recht der Anbieter untersteht. Ein belastbares Souveränitätsniveau ergibt sich erst aus allen drei Antworten zusammen.

Die ersten beiden Fragen lassen sich vertraglich und technisch beantworten, und darauf zielen die neuen Angebote mit erheblichem Aufwand. Datenresidenz in Deutschland und operative Autonomie über europäisches Personal bis in die Führungsebene sind machbar. Schwieriger wird es bei der dritten Frage, der nach der Jurisdiktion.

Wo die Kontrolle endet

Bis hierhin klingt das beherrschbar. Die Datenresidenz lässt sich vertraglich zusichern, die Betreiberkontrolle über europäisches Personal organisieren. Sobald ich aber frage, wer technisch auf meine Daten zugreifen kann, verschiebt sich das Bild. Mit jedem Schritt, den ich vom eigenen Server weg in einen gemanagten Dienst mache, gebe ich mehr Zugriff an den Anbieter ab.

Häufig wird dabei das Shared-Responsibility-Modell der Anbieter mit der Souveränitätsfrage verwechselt. Das Modell beantwortet, wer wofür verantwortlich ist. Es klärt, wer das Betriebssystem patcht und wer die Hardware betreibt, und diese Verantwortung wandert nach oben, je mehr der Anbieter für mich übernimmt. Souveränität hängt aber an einer anderen Grenze. Sie entscheidet sich daran, wer im Ernstfall an die Daten herankommt, und diese Grenze fällt mit der Verantwortungsgrenze nicht zusammen.

Ein Beispiel macht das anschaulicher. Ich verfolge denselben Kundenbestand über drei Diensttypen hinweg. Auf einer virtuellen Maschine liegt er in einem verschlüsselten Volume, und das Schlüsselmaterial kann außerhalb der Anbieterumgebung liegen. Der Anbieter betreibt Hypervisor und Hardware, für die Erbringung des Dienstes muss er in die Maschine selbst nicht hineinsehen. Lege ich denselben Bestand in eine gemanagte Datenbank, muss der Dienst die Daten zum Abfragen entschlüsseln, und der Klartext liegt zur Laufzeit in einem Prozess, den der Anbieter betreibt. Bei einem KI-Dienst muss dieser den Inhalt vollständig sehen, sonst kann er ihn nicht verarbeiten.

Jeden Dienst kann ich an einer einzigen Prüffrage messen: Muss er meine Daten im Klartext verarbeiten, um zu funktionieren? Bei einer reinen Infrastruktur lautet die Antwort nein, bei einer gemanagten Datenbank nur teilweise. Sobald ich zu Serverless-Funktionen oder KI-Diensten komme, lautet sie ja. Je höher der Managed-Level, desto häufiger muss der Anbieter den Klartext sehen, und desto weniger nützt mir die Verschlüsselung im Ruhezustand.

Dabei hilft es, zwei Verfahren auseinanderzuhalten, welche oft verwechselt werden. Bei Bring Your Own Key erzeuge ich den Schlüssel selbst, gebe ihn aber in die Schlüsselverwaltung des Anbieters. Dort wird er verwahrt und benutzt, und damit hat der Anbieter ihn technisch in der Hand. Über Speicher-Dumps oder eigene Masterkeys ist ein Zugriff nicht ausgeschlossen. Bei Hold Your Own Key bleibt der Schlüssel dagegen in meinem eigenen Speicher, etwa einem externen Hardware-Sicherheitsmodul. Der Dienst ruft für jede Operation nach außen, das Material selbst verlässt meine Umgebung nie. AWS bietet das als External Key Store an, Microsoft als Double Key Encryption.

Und trotzdem löst auch das eigene Schlüsselmodell das Grundproblem nicht. Hold Your Own Key schützt die Verwahrung des Schlüssels, nicht die Verarbeitung der Daten. In dem Moment, in dem der Dienst rechnet, liegt der Klartext in seinem Arbeitsspeicher, ganz gleich, wo der Schlüssel wohnt. Diese Lücke schließt erst Confidential Computing, also die Verschlüsselung der Daten auch im Arbeitsspeicher über hardwareisolierte Umgebungen. Auch dieses Verfahren stößt an eine Grenze, weil die Steuerungsebene und die Metadaten außen vor bleiben.

Diese Zugänge lassen sich technisch nicht vollständig wegräumen. Auf jeder Ebene behält der Anbieter einen Weg zu den Daten. Über die Steuerungsebene greift der Support im Notfall ein. Die Schlüssel verwahrt oder benutzt er, sofern ich kein eigenes Schlüsselmodell dagegensetze. Und es fallen Protokoll- und Metadaten an, die zeigen, welche Systeme wann miteinander sprechen. Selbst bei reiner Infrastruktur schließt sich vor allem die Metadaten-Ebene nie ganz. Wer die Kontrolle behalten will, senkt diese Zugriffe so weit wie möglich ab. Auf null bringt er sie mit einem Hyperscaler-Dienst nicht.

Wo die Rechtsordnung zugreift

Selbst wenn ich den technischen Zugriff so weit wie möglich absenke, bleibt die dritte Frage offen. Meiner Meinung nach ist sie bei der Einordnung der Souveränität sogar die wichtigste. Es ist die Frage nach der Rechtsordnung der Muttergesellschaft, und die hängt nicht am Standort der Server. Solange ein US-Konzern die Kontrolle über den Betrieb behält, kann ihn das US-Recht zu einer Handlung zwingen, und kein Rechenzentrum in Brandenburg ändert daran etwas.

Der US CLOUD Act verpflichtet amerikanische Unternehmen, angeforderte Daten herauszugeben, unabhängig davon, wo diese gespeichert sind. Dazu kommen FISA Section 702 und die Executive Order 12333, welche US-Nachrichtendiensten den Zugriff auf Daten von Nicht-US-Bürgern im Ausland erlauben, ohne dass die Betroffenen in Europa wirksame Rechtsbehelfe hätten. Diese Gesetze wirken extraterritorial. Sie greifen also unabhängig davon, wo die Daten liegen und wer sie betreibt.

Eine Tochtergesellschaft nach europäischem Recht ändert daran wenig, solange die US-Mutter die Kontrolle behält, und diese Konstruktion ist juristisch bislang ungetestet. Die Pflicht zu einer solchen Unions-Tochter kommt aus DORA (Art. 31 Abs. 12), die ich in Woche 1 behandelt habe. Mit dem CADA hat sie nichts zu tun. Sie schafft einen Anknüpfungspunkt für die Aufsicht. Ein jurisdiktioneller Durchgriff auf den Konzern entsteht dadurch noch nicht.

Einen Ausweg soll die Datentreuhand bieten. Ein europäischer Treuhänder betreibt den Dienst und hat allein den Zugriff auf die Daten, während der US-Anbieter höchstens für Wartung und Support herangezogen wird. Der Gedanke dahinter ist juristisch interessant, denn das US-Recht setzt für einen Zugriff voraus, dass die Daten im Besitz oder unter Kontrolle des Anbieters stehen. Beim Treuhandmodell ist das nicht der Fall. Belastbar erprobt ist dieser Weg allerdings nicht. Das frühe „Microsoft Cloud Deutschland” mit T-Systems als Treuhänder wurde bereits 2018 für Neukunden eingestellt, weil die Abschottung von der globalen Cloud zu viele Funktionen kostete. Heute kehrt die Idee in neuer Form zurück, etwa in der Delos Cloud auf Azure-Basis. Ob die US-Behörden die Treuhandkonstruktion am Ende anerkennen, muss sich erst zeigen.

Das Etikett souverän haben sich meist die Anbieter selbst verliehen. Sie betrachten dabei die Datenresidenz und die Betreiberkontrolle und lassen die rechtliche Ebene aus, obwohl sie sie kennen. Für unkritische Arbeitslasten mag das genügen. Für die öffentliche Verwaltung, für kritische Infrastruktur und besonders schützenswerte Daten überzeugt es mich nicht. Für mich zählt bei der Souveränität, wer einen Zugriff im Ernstfall verhindern kann.

„Souverän” ist kein Ja oder Nein

Damit lässt sich die Kernfrage beantworten, allerdings nicht mit ja oder nein. Wie souverän ein Angebot ist, hängt davon ab, welchen Dienst ich nutze und welcher Rechtsordnung der Betreiber untersteht. Auf der Ebene reiner Infrastruktur mit eigenem Schlüsselmodell komme ich weit, bei gemanagten Diensten und erst recht bei KI wird der Spielraum enger, und die jurisdiktionelle Frage bleibt in jedem Fall.

Seit Oktober 2025 lässt sich das sogar abstufen. Das Cloud Sovereignty Framework der EU-Kommission beschreibt fünf Sovereignty Effectiveness Assurance Levels, kurz SEAL. SEAL-0 bedeutet keine Souveränität, SEAL-4 volle EU-Kontrolle ohne kritische Abhängigkeiten außerhalb der Union. Dazwischen liegen die jurisdiktionelle Stufe SEAL-1, die Datensouveränität SEAL-2 und die digitale Resilienz SEAL-3. Einordnen muss ich das Framework trotzdem, denn es ist ein Instrument für die Beschaffung der Kommission und kein bindendes Recht wie DORA oder der vorgeschlagene CADA. Als Vokabular taugt es dennoch, weil es die Abstufung benennt, um die es hier geht. Die souveränen Ableger der Hyperscaler landen nach diesen Kriterien meist auf SEAL-1 oder SEAL-2, weil die Bindung an die Muttergesellschaft bleibt.

In der kommenden Woche schaue ich mir an, ob eine europäische Cloud die höheren Stufen erreicht und ob ich mir diese Souveränität mit einem Verzicht auf Leistung erkaufe.

Ausblick

Offen bleibt für mich vor allem eine Frage, die sich rechtlich noch nicht beantworten lässt, nämlich was geschieht, wenn eine US-Behörde die Muttergesellschaft anweist, ihre europäische Tochter zu einer bestimmten Handlung zu veranlassen. Solange dieser Fall nicht durch die Gerichte gegangen ist, überzeugt mich die souveräne Cloud der Hyperscaler bei der Datenresidenz und der Betreiberkontrolle, auf der rechtlichen Ebene bleibt sie ein Versprechen. Diese Ebene nehme ich mir als Nächstes im Dossier souveräne Cloud vor.