Das Wichtigste zur Google Sovereign Cloud im Überblick

Architektur und Betriebsmodelle

Google differenziert drei zentrale Ausprägungen. Data Boundary begrenzt Speicherung und Verarbeitung von Kerndaten auf ausgewählte Regionen und koppelt diese Einschränkung an Organisationsrichtlinien sowie Compliance-Profile. Die technische Basis bleibt die reguläre Google-Cloud-Infrastruktur. Dedicated-Modelle verlagern Teile des Betriebs in eine regionale Organisation und kombinieren Plattformfunktionen mit lokalem Betreiber. Air-Gapped-Varianten isolieren Infrastruktur vollständig von externen Netzen und verzichten auf direkte Anbindung an die Public Cloud.

Air-Gapped-Varianten realisiert Google über Google Distributed Cloud (GDC). Diese Lösung läuft vollständig On-Premises beim Kunden oder in dedizierten, nicht vernetzten Einrichtungen und entspricht eher einem lokal betriebenen Cloud-Deploymentprivace. Sie eignet sich für Szenarien mit strikten Netzwerkanforderungen, etwa in der Rüstungsindustrie oder bei Behörden mit erhöhtem Schutzbedarf. Der Betrieb erfordert eigene Hardware und eigenes Personal — der Aufwand ist erheblich höher als bei Public-Cloud-Modellen mit Datenresidenz.

Die operative Umsetzung in Deutschland erfolgt über Partnerschaften, insbesondere mit T-Systems. Dieses Modell verschiebt operative Aufgaben, Supportprozesse und Teile der Zugriffskontrolle in eine europäische Organisation. Die zugrunde liegende Plattformarchitektur bleibt jedoch eng mit der globalen Google Cloud verzahnt.

Das Angebot firmiert offiziell unter der Bezeichnung Sovereign Cloud by T-Systems und unterteilt die Verantwortlichkeiten klar: T-Systems übernimmt den Betrieb der Zugriffskontrollschicht, den First- und Second-Level-Support sowie die administrative Hoheit über privilegierte Zugriffe auf die Plattform. Google stellt die zugrunde liegende Infrastruktur und die Plattformdienste bereit. Google verfügt im regulären Betrieb über keinen eigenständigen administrativen Zugriff ohne Beteiligung von T-Systems. Unternehmen sollten prüfen, welche konkreten Zugriffspfade im Einzelfall vertraglich geregelt sind.

Datenresidenz und Datenklassifikation

Google beschränkt im Data-Boundary-Modell die Speicherung sogenannter Core Customer Data auf definierte Regionen. Für Deutschland sind dies primär die Rechenzentren der Region europe-west3 mit Standorten in Frankfurt am Main sowie weiterer Infrastruktur im Rhein-Main-Gebiet. Zusätzlich steht die Region europe-west9 in Paris für europäische Datenresidenz zur Verfügung. Diese Einschränkung greift jedoch nur für Daten, die Google der Kategorie Core Customer Data zuordnet.

Google hat in neueren Vertragsdokumenten und Produktaktualisierungen den Umfang der Datenkategorien, die unter Datenresidenz-Zusagen fallen, schrittweise erweitert. Neben Core Customer Data adressieren aktuelle Vertragswerke zunehmend auch Service Data sowie Technical Support Data. Dennoch verbleiben bestimmte Kategorien — darunter Diagnosedaten, aggregierte Nutzungsstatistiken und Plattformtelemetrie — außerhalb dieser Zusagen. Unternehmen sollten die aktuellen Data Processing Addenda und die Cloud Data Processing Terms ihres Vertrags konkret prüfen und nicht allein auf Produktbeschreibungen vertrauen. Die relevanten Dokumente veröffentlicht Google im Cloud-Kundenbereich und aktualisiert sie regelmäßig.

Unternehmen müssen daher Datenflüsse aktiv klassifizieren und kontrollieren. Eine rein regionale Auswahl genügt nicht, um sämtliche Datenpfade innerhalb einer bestimmten Region zu halten. Die Verantwortung für Datenplatzierung und Datenverarbeitung verbleibt vollständig beim Kunden.

Zugriffskontrolle und Nachvollziehbarkeit

Google integriert mehrere Mechanismen zur Kontrolle von Provider-Zugriffen. Access Transparency protokolliert administrative Zugriffe durch Google-Personal auf Kundendaten. Access Approval erlaubt eine explizite Freigabe durch den Kunden für bestimmte Supportzugriffe. Diese Funktionen gelten nur für unterstützte Dienste und definierte Zugriffsszenarien.

Die Protokollierung liefert verwertbare Auditdaten, setzt jedoch eine aktive Auswertung voraus. Ohne entsprechende Prozesse bleiben Protokolle wirkungslos. Unternehmen müssen Logging, Monitoring und Incident Response so konfigurieren, dass Abweichungen erkannt und bewertet werden.

Verschlüsselung und Schlüsselkontrolle

Google nutzt standardmäßig Verschlüsselung auf Speicher- und Transportebene. Erweiterte Kontrolle lässt sich durch External Key Management umsetzen. In diesem Modell verbleiben Schlüssel außerhalb der Google-Infrastruktur. Jeder Zugriff auf verschlüsselte Daten erfordert eine Interaktion mit dem externen Schlüsselanbieter.

Diese Architektur erhöht die Kontrolle über Datenzugriffe, garantiert jedoch keine vollständige Abschirmung gegenüber externen Zugriffen. Die Wirksamkeit hängt von der konkreten Implementierung, der Trennung von Schlüssel und Daten sowie der Nutzung unterstützter Dienste ab. Fehler in der Integration oder unvollständige Abdeckung einzelner Dienste reduzieren die Schutzwirkung.

Sicherheitsmechanismen und Plattformintegration

Google ergänzt das Modell durch Funktionen wie Confidential Computing und Assured Workloads. Confidential Computing schützt Daten im Arbeitsspeicher durch hardwarebasierte Isolation. Assured Workloads verknüpft Compliance-Anforderungen mit Infrastrukturkonfiguration und beschränkt Ressourcen auf definierte Regionen und Dienste.

Diese Mechanismen greifen aber ebenfalls nur bei konsequenter Nutzung. Fehlkonfiguration oder unvollständige Umsetzung führen dazu, dass Schutzmechanismen ihre Wirkung verlieren. Die Plattform stellt Werkzeuge bereit, ersetzt jedoch keine Governance auf Kundenseite.

Regulatorischer Rahmen in Europa

Cloud-Nutzung in Europa orientiert sich an mehreren Rechtsrahmen. Die DSGVO definiert Anforderungen an den Schutz personenbezogener Daten. Die NIS2-Richtlinie erweitert Vorgaben für Cybersicherheit und Risikomanagement. Der EU Data Act regelt Wechselbarkeit zwischen Cloud-Anbietern und fordert Maßnahmen gegen bestimmte Formen unrechtmäßigen Zugriffs aus Drittstaaten.

Die NIS2-Richtlinie gilt seit Oktober 2024 verbindlich in Deutschland und erfasst Unternehmen ab einer bestimmten Größe in 18 Sektoren, darunter Energie, Transport, Gesundheit, digitale Infrastruktur und Teile des verarbeitenden Gewerbes. Betroffene Einrichtungen müssen Risikomanagementmaßnahmen implementieren, Sicherheitsvorfälle melden und Lieferketten einschließlich Cloud-Dienstleister in ihre Risikobetrachtung einbeziehen. Der EU Data Act ergänzt dies um Anforderungen an die Portabilität und den Wechsel zwischen Anbietern sowie Schutzmechanismen gegen unberechtigte Drittstaatenzugriffe. Für Cloud-Einsatz bedeutet dies: Verträge mit Anbietern müssen explizit auf NIS2-Konformität und Data-Act-Anforderungen geprüft werden.

Das Schrems II-Urteil des Gerichtshof der Europäischen Union aus dem Jahr 2020 verändert die Bewertung internationaler Datentransfers grundlegend und wirkt auch 2026 unverändert fort. Der Gerichtshof hob das EU-US Privacy Shield auf und verschärft die Anforderungen an Datenübermittlungen in Drittstaaten. Standardvertragsklauseln bleiben zulässig, jedoch nur unter der Voraussetzung, dass Unternehmen eigenständig prüfen, ob im Empfängerland ein mit der EU vergleichbares Schutzniveau besteht. Diese Prüfung umfasst insbesondere staatliche Zugriffsbefugnisse und Durchsetzungsmöglichkeiten für betroffene Personen.

Die Europäische Kommission reagiert mit dem EU-US-Data-Privacy-Framework und schafft damit erneut eine formale Grundlage für Datentransfers in die USA. Dieses Rahmenwerk adressiert staatliche Zugriffsbefugnisse und führt neue Kontrollmechanismen sowie Rechtsbehelfe ein. Dennoch bleibt die technische Perspektive unverändert relevant, da rechtliche Garantien keine vollständige Kontrolle über tatsächliche Datenzugriffe sicherstellen.

Im Jahr 2026 ergibt sich daraus ein zweistufiges Bewertungsmodell für Cloud-Nutzung. Unternehmen berücksichtigen rechtliche Mechanismen wie Angemessenheitsbeschlüsse oder Standardvertragsklauseln und kombinieren diese mit technischen Schutzmaßnahmen. Verschlüsselung mit externer Schlüsselverwaltung, restriktive Zugriffskontrollen und transparente Protokollierung gewinnen dadurch eine zentrale Rolle. Cloud-Modelle mit regionaler Datenhaltung und kontrollierten Zugriffspfaden reduzieren Risiken, ersetzen jedoch keine eigenständige Bewertung der Datenflüsse und der zugrunde liegenden Architektur.

Für souveräne Cloud-Konzepte bedeutet dies eine klare Verschiebung der Verantwortung. Anbieter stellen technische Kontrollmechanismen bereit, die rechtliche Anforderungen unterstützen. Die Bewertung der Wirksamkeit dieser Maßnahmen liegt weiterhin beim nutzenden Unternehmen. Dadurch bleibt die Kombination aus juristischer Einordnung und technischer Umsetzung der entscheidende Faktor für die Zulässigkeit internationaler Datenverarbeitung.

Zugriff durch Drittstaaten und rechtliche Grenzen

US-amerikanische Anbieter unterliegen gesetzlichen Verpflichtungen, die auch Daten außerhalb der USA betreffen können. Technische Maßnahmen wie Verschlüsselung und externe Schlüsselverwaltung erschweren den Zugriff auf Klartextdaten. Eine vollständige rechtliche Abschirmung ergibt sich daraus nicht.

Metadaten, operative Informationen oder nicht verschlüsselte Datenbestandteile können weiterhin Gegenstand rechtlicher Anfragen sein. Unternehmen müssen diese Risiken in ihre Gesamtbewertung einbeziehen und technische sowie organisatorische Gegenmaßnahmen kombinieren.

Technische Einschränkungen und Auswirkungen auf Workloads

Sovereign-Modelle unterstützen nicht alle Dienste und Funktionen der globalen Plattform. Bestimmte APIs, Integrationen und Workflows stehen nur eingeschränkt zur Verfügung. Diese Einschränkungen betreffen Datenanalyse, Logging, Automatisierung und KI-Dienste. Workloads müssen an diese Rahmenbedingungen angepasst werden. Architekturentscheidungen müssen Datenflüsse strikt kontrollieren und externe Abhängigkeiten minimieren. Ohne diese Anpassungen verlassen Daten schnell die vorgesehenen Grenzen.

Amazon Web Services hat mit der AWS European Sovereign Cloud einen eigenständigen Cloud-Stack mit organisatorischer Trennung vom globalen AWS-Betrieb angekündigt. Microsoft setzt mit der EU Data Boundary auf geografische Datenbegrenzung innerhalb bestehender Dienste und hat dieses Modell bereits produktiv ausgerollt. Google kombiniert Public Cloud, Partnerbetrieb über T-Systems und technische Zusatzkontrollen. Die Ansätze unterscheiden sich im Grad der organisatorischen Trennung, im Umfang verfügbarer Dienste und im Reifegrad der jeweiligen Lösung — ein direkter Vergleich erfordert eine dienstspezifische Bewertung.

Bewertung für den Einsatz in Deutschland

Google Sovereign Cloud liefert einen technischen Rahmen zur Umsetzung regulatorischer Anforderungen. Datenresidenz, Zugriffskontrolle und Auditierbarkeit verbessern die Nachvollziehbarkeit und reduzieren bestimmte Risiken. Die Wirksamkeit hängt vollständig von Architektur, Konfiguration und Betriebsprozessen ab.

Unternehmen können diese Plattform nutzen, sofern sie Datenklassifikation, Schlüsselverwaltung, Identitätsmanagement und Monitoring konsequent umsetzen. Gleichzeitig bleiben Abhängigkeiten von einem global agierenden Anbieter und dessen rechtlichem Umfeld bestehen. Eine souveräne Cloud reduziert Risiken, ersetzt jedoch keine eigenständige Risikoanalyse und keine technische Umsetzung auf hohem Niveau.