Wie Sie eine wirklich souveräne Cloud in Europa aufbauen: zwei Wege und worauf Sie achten sollten, bevor Sie einem Anbieter vertrauen

Wie Sie eine wirklich souveräne Cloud in Europa aufbauen: zwei Wege und worauf Sie achten sollten, bevor Sie einem Anbieter vertrauen

Da europäische Länder weiterhin die extraterritoriale Reichweite des US-Rechts über die globale digitale Infrastruktur spüren, ist das Thema souveräne Cloud nicht länger theoretisch. Zwar gibt es keine neuen direkten Sanktionen oder Exportbeschränkungen für Technologien, die sich gegen europäische Länder richten, doch der bestehende Rechtsrahmen – insbesondere der Clarifying Lawful Overseas Use of Data Act (CLOUD Act) – verpflichtet US-Cloud-Anbieter weiterhin, Datenanfragen amerikanischer Behörden nachzukommen, selbst wenn diese Daten in der EU gespeichert und verarbeitet werden. In Kombination mit geheimen Regelungen zum Datenzugriff und Haftungsausschlüssen für Anbieter entsteht dadurch eine strukturelle Verwundbarkeit der digitalen Souveränität Europas.

Amerikanische Hyperscaler – Amazon, Microsoft und Google – dominieren weiterhin den europäischen Cloud-Markt. In diesem Artikel werfen wir einen genaueren Blick darauf, wie diese Anbieter die DSGVO einhalten und gleichzeitig vollständig der US-Gerichtsbarkeit unterliegen. Außerdem beleuchten wir mögliche Exit-Strategien für Organisationen, die eine wirklich souveräne Cloud-Infrastruktur aufbauen möchten.

Verwurzelt seit 2018: Der CLOUD Act und das falsche Versprechen der souveränen Cloud

Der Wortlaut des CLOUD Act erlaubt nominell die Berücksichtigung ausländischer Gesetze und rechtlicher Einwände. Er schützt Anbieter jedoch ausdrücklich vor jeglicher rechtlicher Haftung für die Erfüllung von Anfragen der US-Regierung. Unter Section 2705 – „Delayed Notice“ kann die Benachrichtigung von Nutzern nicht nur aufgeschoben, sondern auch vollständig untersagt werden (gag order), sodass Nutzer möglicherweise nie davon erfahren. In solchen Fällen ist es schwierig, vor Gericht zu gehen oder EU-rechtliche Schutzmechanismen geltend zu machen, wenn die US-Regierung eine Anfrage direkt an ein amerikanisches Unternehmen richtet und der Nutzer nie informiert wird.

Darüber hinaus besagt eine zusätzliche Klausel im CLOUD Act, dass der Anbieter keine Haftung für die Zusammenarbeit mit US-Behörden trägt und im Falle eines Rechtsstreits keiner der Hyperscaler Konsequenzen zu befürchten hat:

„(d) No Cause Of Action Against A Provider Disclosing Information Under This Chapter. No cause of action shall lie in any court against any provider… for providing information, facilities, or assistance in accordance with a court order under this chapter…“


Hyperscaler verfügen über enorme Marketingbudgets und sind äußerst effektiv darin, Narrative zum richtigen Zeitpunkt zu prägen. Heute bietet nahezu jeder große US-Cloud-Anbieter irgendeine Form eines „souveränen“ Cloud-Produkts an, das auf den europäischen Markt zugeschnitten ist. Eines der am häufigsten zitierten Beispiele ist: „Die AWS European Sovereign Cloud wird mit einer unabhängigen Governance-Struktur, einem dedizierten Security Operations Centre und unter einer neu gegründeten Muttergesellschaft betrieben, die in der EU lokal kontrolliert wird, von EU-Bürgern geführt wird und lokalen Gesetzen unterliegt.“

Auf den ersten Blick klingt das nach der Einhaltung europäischer Souveränitätsprinzipien. Ein genauerer Blick zeigt jedoch, dass diese Designelemente – wie eine lokal registrierte Gesellschaft, eine EU-basierte Führung und die Einhaltung lokaler Gesetze – in erster Linie darauf ausgelegt sind, die DSGVO und Datenschutzanforderungen zu erfüllen, nicht aber, die US-Gerichtsbarkeit auszuschließen.
Tatsächlich hat sich kein Hyperscaler öffentlich dazu verpflichtet, den Geltungsbereich der US-Rechtsautorität zu verlassen, noch haben sie klargestellt, wie solche „souveränen“ Produkte vor Verpflichtungen aus Gesetzen wie dem CLOUD Act geschützt werden. Der US-Rechtsrahmen gilt weiterhin extraterritorial und erkennt Konflikte mit EU-Recht erst nachträglich an.

Da solche europäischen souveränen Angebote letztlich weiterhin auf US-eigenen Technologiestacks beruhen – einschließlich Cloud-Control-Planes und Infrastruktur –, bleibt der Zugriff auf Daten möglich, wenn auch stärker geschichtet. Wie bereits erwähnt, können Zugriffsanfragen geheim gestellt werden, und Anbieter sind rechtlich vor Haftung geschützt, wenn sie mit US-Behörden kooperieren.

Das schafft eine beunruhigende Asymmetrie: Eine europäische juristische Person kann lokal zur Verantwortung gezogen werden, doch im Falle eines Verstoßes oder verdeckten Zugriffs hat das Unternehmen, dessen Daten kompromittiert wurden, kaum Möglichkeiten, und die US-Muttergesellschaft hat keine rechtlichen Konsequenzen zu befürchten.

Wie kam es zu Europas Abhängigkeit von souveränen Clouds?

Auf den ersten Blick scheint die Rechtslage klar. Nutzen Sie einfach keine US-basierten Cloud-Anbieter mehr. Bis 2026 sollte jedem europäischen Bürger klar sein, dass Goodwill nicht länger der primäre Treiber amerikanischer Politik ist. Und doch erzählen die Zahlen eine andere Geschichte:

„Der europäische Cloud-Markt wird weitgehend von US-Anbietern dominiert, was strukturelle Abhängigkeiten schafft und Risiken für die Vertraulichkeit europäischer Daten birgt. Der Marktanteil europäischer Cloud-Anbieter sank von 29 % im Jahr 2017 auf 15 % im Jahr 2022, ist seitdem jedoch relativ konstant geblieben. Die Hauptprofiteure des Marktwachstums waren Amazon, Microsoft und Google, die inzwischen 70 % des regionalen Marktes ausmachen.“

Obwohl der CLOUD Act seit 2018 seit acht Jahren in Kraft ist, stützen sich 70 % des europäischen Cloud-Marktes weiterhin auf amerikanische Anbieter. Angesichts mangelnder Transparenz und Marketingphrasen wie „selbst wir können nicht darauf zugreifen“ ist es wichtig zu erkennen, dass dies ein bequemes, aber unvollständiges Narrativ ist. Man kann vernünftigerweise annehmen, dass die offizielle Reaktion sorgfältig formuliert wäre, falls ein Hyperscaler jemals öffentlich eines Datenlecks beschuldigt würde: „Wir können nicht auf Ihre Daten zugreifen, also können wir weder etwas bestätigen noch dementieren! Das ist technisch unmöglich!“

Cloud-Souveränität in Public Clouds läuft letztlich auf Vertrauen in eine Blackbox hinaus. Wenn ein großer Anbieter wie AWS sagt: „Nicht einmal wir können auf Ihre Daten zugreifen“, dank Isolation, Verschlüsselung und Architektur, sollen wir das glauben. Kunden haben keine technischen Mittel, um zu verifizieren, wie die internen Mechanismen funktionieren, wie Daten während der Verarbeitung behandelt werden oder wie Zugriffskontrollen durchgesetzt werden. Aber man muss kein Informatikexperte sein, um zu verstehen, dass verschlüsselte Daten während der Verarbeitung irgendwann entschlüsselt werden müssen – konkret im Arbeitsspeicher. Und Daten im Arbeitsspeicher sind per Definition für das System zugänglich, das sie verarbeitet. Diese einfache, aber entscheidende technische Tatsache wird in öffentlichen Aussagen und Marketingmaterialien oft ausgelassen – dabei steht sie im Zentrum der Souveränitätsdebatte.

Rechtlich ist die Lage noch unklarer. Hyperscaler halten die DSGVO ein, erwerben Zertifizierungen (z. B. CISPE), kooperieren mit lokalen Unternehmen und bieten Datenresidenz an. Sie bleiben jedoch der US-Gerichtsbarkeit unterworfen, können den CLOUD Act nicht ignorieren und sind verpflichtet, Datenanfragen der US-Regierung zu erfüllen – selbst wenn die Daten in Frankfurt oder Paris liegen. Unabhängig davon, wie viele technische Zusicherungen Anbieter geben, bleibt die rechtliche Möglichkeit einer Intervention bestehen, sodass Kunden zwischen Vertrauen und einer Infrastruktur wählen müssen, die vollständig unter europäischer Gerichtsbarkeit steht.

Welche Alternative gibt es zur souveränen Cloud?

Alternativen gibt es – auch wenn sie schwierig sind. Hätte Europa vor einem Jahrzehnt gehandelt, sähe die Landschaft heute möglicherweise ganz anders aus. Das Kernproblem ist Kontrolle, und echte Kontrolle entsteht nur, wenn jede Phase der Datenverarbeitung und des Computings verstanden und gesteuert wird.

Heute haben europäische Organisationen Zugang zu einer Reihe echter Alternativen zu US-Hyperscalern, die es ihnen ermöglichen, die Datenkontrolle zu behalten und Souveränitätsanforderungen zu erfüllen. Zu den führenden Anbietern zählen T-Systems, Orange Cloud und andere – unter EU-Gerichtsbarkeit operierend, mit lokalen Rechenzentren und zunehmend zertifiziert nach vertrauenswürdigen Cloud-Standards wie Frankreichs SecNumCloud oder GAIA-X.

Dieses Ökosystem wird zusätzlich durch Open-Source-Technologien unterstützt – vor allem OpenStack (für IaaS), Kubernetes (für Orchestrierung), Ceph (für verteilten Storage) und Plattformen wie FishOS. Viele Nischenanbieter bieten zudem vorintegrierte, unterstützte und gehostete Lösungen an, wodurch Open Source zugänglicher wird. Experten-Support ist hier entscheidend – er ermöglicht eine schnellere Bereitstellung und eine effektivere Nutzung dieser Tools. In der Praxis erweist sich eine Kombination aus Open Source und kommerziellem Support oft als kosteneffizienter und nachhaltiger, als sich ausschließlich auf europäische Hyperscaler zu verlassen.

Verstehen, was Sie kontrollieren: Zwei Wege zur Souveränität

Volle technische Kontrolle: Souveräne Cloud als Architekturentscheidung

Volle technische Kontrolle stellt die höchste Stufe der Cloud-Souveränität dar, bei der die Organisation jede Infrastruktur- und Software-Schicht direkt steuert – ohne Zwischeninstanzen. Dieses Modell ist besonders relevant für Regierungen, Verteidigung, Gesundheitswesen und kritische Industrien.

Zentrale technische Komponenten:

  • Rechenzentrum: In der EU gelegen, betrieben von der Organisation oder einem vertrauenswürdigen lokalen Anbieter, nicht unter fremder Gerichtsbarkeit (z. B. USA, China).
  • Hardware: Von Anbietern mit transparenten Lieferketten bezogen; intern oder durch lokale Teams gewartet.
  • Netzwerk: Volle Kontrolle über Routing, DNS und Telekommunikationsinfrastruktur; keine Traffic-Inspektion durch Dritte oder SaaS-basierte Firewall-Dienste.
  • IaaS-/Container-Plattform: Aufgebaut auf OpenStack (Virtualisierung), Kubernetes (Orchestrierung), Ceph (Storage) und Kata Containers (Isolation).
  • Verschlüsselung: Auf allen Ebenen durchgesetzt – at rest und in transit; Schlüssel werden lokal über HSM oder BYOK/HYOK verwaltet – für den Cloud-Anbieter unzugänglich.
  • Zugriffskontrolle (IAM): Lokale Identity-Plattform, nicht an Azure AD, Okta, AWS IAM gebunden; volle Kontrolle über Tokens, Rollen, Logs und MFA.
  • Control Plane: Inhouse bereitgestellt, unabhängig von SaaS; Tools wie CloudKitty (Abrechnung), VictoriaMetrics/Prometheus/Grafana (Monitoring) und ELK (Logging) werden lokal eingesetzt.
  • CI/CD und DevOps: Self-hosted Pipelines (GitLab, Jenkins, ArgoCD); keine Abhängigkeit von externen APIs.
  • Rechtsstruktur: Cloud wird von einer in der EU registrierten Einheit betrieben und besessen; kein ausländisches Kapital oder Kontrolle.

Das ermöglicht echte Souveränität, bei der selbst theoretischer Zugriff ausgeschlossen ist. Der Nachteil sind höhere Kosten, erforderliche Expertise und die volle operative Verantwortung.

Rechtliche Garantien: Delegierte souveräne Cloud über vertrauenswürdige EU-Anbieter

Der zweite Weg ist delegierte Kontrolle, bei der ein europäischer Cloud-Anbieter genutzt wird und man sich auf rechtliche und technische Zusicherungen zur DSGVO- und Souveränitäts-Compliance stützt. Das ist für die meisten Organisationen, die nicht bereit sind, ihre eigene Cloud aufzubauen, der pragmatischere und kosteneffizientere Ansatz. Zentrale Elemente der Souveränität in diesem Modell:

  • EU-Gerichtsbarkeit: Der Anbieter ist eine in der EU registrierte juristische Person, ohne Verbindungen zu Rechtsräumen mit extraterritorialen Gesetzen.
  • Infrastruktur: Rechenzentren befinden sich innerhalb der EU und werden von europäischen Unternehmen betrieben.
  • Zertifizierung: Anbieter sind nach SecNumCloud (Frankreich), CISPE und EUCS (in Entwicklung) zertifiziert – und erfüllen damit DSGVO sowie nationale Vorgaben.
  • Technologie: Häufig auf OpenStack oder ähnlichen Stacks basierend. So betreiben beispielsweise OVHcloud, 3DS Outscale, GRASS-MERKUR und NumSpot vollständig innerhalb der EU offene Technologien.
  • Verschlüsselung: BYOK- oder HSM-Optionen ermöglichen es Kunden, Verschlüsselungsschlüssel unabhängig zu verwalten.
  • Zugriffskontrolle: Strenge IAM-Regeln, mit Unterstützung für föderierte Identity-Systeme.
  • Verträge: Enthalten Verpflichtungen zur Benachrichtigung von Kunden über Zugriffsanfragen, definieren die Verarbeitung personenbezogener Daten und stellen die DSGVO-Compliance sicher.
  • Transparenz: Anbieter stellen Zugriffslogs, externe Auditberichte und Compliance-Offenlegungen bereit.

Dieses Modell wird bereits in nationalen Cloud-Projekten (Bundescloud in Deutschland, NumSpot in Frankreich) sowie in regulierten Branchen eingesetzt. Es ist zwar technisch nicht absolut, bietet jedoch rechtlich delegierte und gemanagte Souveränität – ein praktikabler Kompromiss zwischen Risiko, Kosten und Bereitstellungsgeschwindigkeit.

Warum sind wir immer noch abhängig?

Der Hauptgrund ist die technologische Reife und die Tiefe des Ökosystems amerikanischer Hyperscaler. AWS, Azure und Google Cloud bieten riesige Servicekataloge – von KI bis DevOps – und „Plug-and-Play“-Lösungen, die keine tiefgehende interne Expertise erfordern.

Hinzu kommt eine Qualifikationslücke. Der Arbeitsmarkt wird von Hyperscaler-Zertifizierungen dominiert, während Ingenieure mit Erfahrung in OpenStack, Ceph oder souveränen Stacks rar sind. Dazu kommt die Marketingmacht der Hyperscaler (großzügige Fördermittel, Trainingsprogramme, Startup-Support und aggressive Partnerschaften). Europäische Alternativen gelten oft als komplexer, teurer und weniger skalierbar – aber das muss nicht so sein.

Schließlich führt der Mangel an starkem regulatorischem Druck in der EU, eine ausschließlich souveräne Cloud-Nutzung vorzuschreiben, dazu, dass viele Organisationen weiterhin auf US-Plattformen setzen und Bequemlichkeit sowie Skalierung langfristiger Autonomie und rechtlicher Sicherheit vorziehen.

1780 1014 Egine Nalbandian
Start Typing