Sichert Google Cloud Ihre Daten? Geteilte Verantwortung erklärt

Was ist das Modell der geteilten Verantwortung bei Google Cloud?

Es ist die Aufteilung zwischen dem, was Google sichert, und dem, was Sie sichern. Google ist für das zugrunde liegende Netzwerk und die Infrastruktur verantwortlich. Sie sind für alles verantwortlich, was Sie darauf ablegen, und dafür, wie Sie den Zugriff darauf konfigurieren.

Ein Team hat seine ERP- und Cloud-SQL-Datenbanken nach Google Cloud verlegt. Dann führt ein Entwickler ein Aufräumskript im falschen Projekt aus. Die Infrastruktur von Google arbeitet einwandfrei, und die Daten sind trotzdem weg. Um diese Lücke geht es in diesem Artikel. Deshalb behandeln wir Cloud-Workloads als Teil Ihrer Backup-as-a-Service-Strategie und nicht als etwas, das der Anbieter erledigt.

Googles Architecture-Framework-Seite zu Shared Responsibility und Shared Fate ist eindeutig: Der Anbieter „bleibt immer für das zugrunde liegende Netzwerk und die Infrastruktur verantwortlich“, Kunden „bleiben immer für ihre Zugriffsrichtlinien und Daten verantwortlich“. Googles Ebene „Shared Fate“ ergänzt sichere Vorlagen und Voreinstellungen, überträgt die Verantwortung für Ihre Daten aber nicht zurück an Google.

• Google: Rechenzentren, Hardware, Netzwerk und die Verfügbarkeit der Managed Services.
• Sie: Ihre Daten, IAM-Rollen, Projekteinstellungen, Aufbewahrung und Ihre Fähigkeit zur Wiederherstellung.

Was decken die nativen Schutzfunktionen von Google Cloud tatsächlich ab?

Google bietet mehrere nützliche Sicherheitsnetze, aber jedes schützt vor einem bestimmten Fehler und hat Grenzen. Keines davon ist eine unabhängige Kopie außerhalb der Kontrolle von Google.

Laut der Dokumentation zu Cloud Storage Soft Delete von Google ist Soft Delete standardmäßig mit 7 Tagen Aufbewahrung aktiv. Wird ein Projekt gelöscht, bleiben Buckets nur für die Soft-Delete-Dauer oder das Wiederherstellungsfenster des Projekts erhalten, je nachdem, was kürzer ist. Buckets ohne Soft Delete „können beim Löschen eines Projekts sofort gelöscht werden“. Die Resource-Manager-Dokumentation bestätigt, dass soft-gelöschte Projekte nach 30 Tagen endgültig gelöscht werden.

Diese Fristen passen zu einem Fehler, den Sie in derselben Woche bemerken, nicht zu einem, den Sie erst nach einem Monatsabschluss oder einem langen Einbruch entdecken.

Was kann bei Daten in Google Cloud trotzdem schiefgehen?

Die meisten Datenverluste in der Cloud entstehen oberhalb der Infrastruktur: durch Menschen, Zugangsdaten, Konfiguration und gelegentlich durch die eigenen Prozesse des Anbieters.

1. Menschliche Fehler. Ein gelöschter Bucket oder ein Terraform-Lauf gegen die falsche Umgebung, per Replikation in jede Zone kopiert.
2. Kompromittierte Zugangsdaten. Ein Angreifer mit der Rolle „Owner“ oder dem Schlüssel eines hoch privilegierten Dienstkontos kann über legitime APIs Snapshots löschen, die Aufbewahrung verkürzen und Projekte entfernen. Der Verizon 2025 Data Breach Investigations Report fand Ransomware in 44 % der untersuchten Datenpannen, und Angreifer gehen routinemäßig zuerst gegen die Wiederherstellungsoptionen vor.
3. Fehlkonfiguration. Zu weit gefasste IAM-Bindungen oder eine Lifecycle-Regel, die Objekte zu früh löscht. Keine Verfügbarkeitszusage deckt das ab.
4. Fehler beim Anbieter. Selten, aber real. 2024 erklärte Google Cloud, dass ein leerer Parameter in einem internen Werkzeug dazu führte, dass die Private Cloud eines Kunden in Google Cloud VMware Engine nach einer Standardlaufzeit von einem Jahr gelöscht wurde.

Dieser Kunde war der australische Pensionsfonds UniSuper. Den Vorfall und seine Lehren behandeln wir ausführlich im Artikel Was geschah, als Google Cloud die Private Cloud von UniSuper löschte?

Reicht Google Cloud Backup and DR allein aus?

Für Wiederherstellungen im Alltag ist es ein solides Werkzeug, und Sie sollten es nutzen. Als einzige Kopie macht es Sie aber von einem einzigen Anbieter abhängig, für Produktion und Wiederherstellung zugleich.

Die Backup-and-DR-Übersicht von Google beschreibt einen Managed Service für Compute Engine, Persistent Disk, Filestore, VMware-Engine-VMs, Cloud SQL, AlloyDB und selbst verwaltete Datenbanken. Seine Backup-Vaults sind „von Google verwaltete, isolierte Speicherressourcen“ mit Write-once-read-many-Unveränderlichkeit und einer optionalen erzwungenen Mindestaufbewahrung von bis zu 99 Jahren. Das ist eine echte Verbesserung gegenüber einfachen Snapshots.

Unverändert bleibt, wer es betreibt. Produktion und Backup teilen sich einen Anbieter, einen Vertrag und einen Rechtsraum, ein Ausfall auf dieser Ebene trifft also beide. Bei UniSuper hieß es in der gemeinsamen Erklärung von UniSuper und Google Cloud, Backups „bei einem zusätzlichen Dienstanbieter“ hätten den Datenverlust minimiert und die Möglichkeit zur Wiederherstellung erheblich verbessert.

Dasselbe gilt anderswo: siehe warum Daten in AWS noch kein Backup sind und warum Multicloud keine Backup-Strategie ist.

Macht eine EU-Region Ihre Google-Cloud-Daten souverän?

Nein. Eine EU-Region bietet Ihnen Datenresidenz, die Server stehen also in Europa. Bei Souveränität geht es darum, wer rechtlich zur Herausgabe der Daten gezwungen werden kann, und Google ist ein US-Unternehmen.

Der US-amerikanische CLOUD Act von 2018 hat 18 U.S.C. § 2713 eingefügt. Die Vorschrift verpflichtet US-Anbieter, Daten offenzulegen, die sich in ihrem „Besitz, Gewahrsam oder ihrer Kontrolle“ befinden, „unabhängig davon, ob sich diese Kommunikation, Aufzeichnung oder sonstige Information innerhalb oder außerhalb der Vereinigten Staaten befindet“. Auf EU-Seite besagt Art. 48 DSGVO, dass die Entscheidung eines Gerichts aus einem Drittland zur Übermittlung personenbezogener Daten nur anerkannt oder vollstreckbar ist, wenn sie auf einer internationalen Übereinkunft wie einem Rechtshilfeabkommen beruht. Ein Backup beim selben US-Anbieter teilt das Risiko der Produktion.

Für Organisationen im Anwendungsbereich von NIS2 verlangt Art. 21 Abs. 2 lit. c der NIS2-Richtlinie (EU) 2022/2555 die Aufrechterhaltung des Betriebs, etwa Backup-Management und Wiederherstellung nach einem Notfall. Art. 21 Abs. 2 lit. d ergänzt die Sicherheit der Lieferkette. Eine Kopie bei einem EU-Betreiber außerhalb Ihres primären Anbieters deckt beides ab. Mehr dazu in Was Datensouveränität in der Praxis bedeutet.

Wie bauen Sie ein unabhängiges Backup für Google Cloud auf?

Behalten Sie die nativen Google-Werkzeuge für schnelle operative Wiederherstellungen und ergänzen Sie eine Kopie, die außerhalb von Google Cloud liegt, sich nicht verändern lässt und getestet wird. Fünf Schritte führen dorthin.

1. Erfassen Sie, was zählt. Listen Sie die Projekte, VMs, Datenbanken und Buckets auf, von denen Ihre Dienste abhängen, und legen Sie fest, wie viel Datenverlust und Ausfallzeit jeweils tolerierbar ist. Das RPO gibt an, wie viel Arbeit Sie verlieren dürfen, das RTO, wie lange Sie ausfallen dürfen. Unser Ratgeber zu RTO und RPO zeigt, wie Sie beides festlegen.
2. Härten Sie die native Ebene. Erhöhen Sie die Soft-Delete-Aufbewahrung, nutzen Sie Vaults mit erzwungener Aufbewahrung und beschränken Sie Owner-Rollen.
3. Ergänzen Sie eine Kopie außerhalb der Plattform. Folgen Sie der 3-2-1-1-0-Regel: drei Kopien, zwei Medien, eine außer Haus, eine unveränderlich oder per Air Gap getrennt, null Fehler bei der Überprüfung.
4. Trennen Sie die Zugangsdaten. Das Konto, das die Produktion löschen kann, sollte das Backup nicht löschen können.
5. Testen Sie Wiederherstellungen. Stellen Sie nach Plan eine VM und eine Datenbank in einer isolierten Umgebung wieder her und bewahren Sie die Ergebnisse als Nachweis auf.

Beim Mindtime-Backup für Google Cloud liegt die Kopie außerhalb der Plattform ausschließlich in unseren eigenen Tier-III-Rechenzentren in Deutschland und den Niederlanden, nach EU-Recht und unabhängig von US-Hyperscalern. Die Backups sind per Object Lock unveränderlich, dazu gibt es eine Air-Gap-Kopie. Jeder Backup-Job wird automatisch geprüft, Backups werden auf Malware gescannt, und administrative Aktionen erfordern MFA (Multi-Faktor-Authentifizierung). Wir sind ISO-27001- und NEN-7510-zertifiziert (NEN 7510 ist die niederländische Norm für Informationssicherheit im Gesundheitswesen).

Ihre nächsten Schritte

Google Cloud zu nutzen, ist eine vernünftige Entscheidung. Anzunehmen, dass es Ihre Daten sichert, ist es nicht. Ihre Daten, Zugriffskontrollen und die Fähigkeit zur Wiederherstellung bleiben in Ihrer Verantwortung. Am sichersten erfüllen Sie sie mit einer getesteten, unveränderlichen Kopie außerhalb der Google-Plattform, unter EU-Recht.

Prüfen Sie diese Woche Ihre Soft-Delete-Aufbewahrung, wer Owner-Rechte hält und wann Sie zuletzt aus einer Kopie wiederhergestellt haben, die Google nicht betreibt. Sehen Sie dann, wie sich eine unabhängige Kopie in Ihr Gesamtkonzept für Backup as a Service einfügt.

Möchten Sie das an Ihrer eigenen Umgebung sehen? Vereinbaren Sie eine kostenlose 15-minütige Demo, wir zeigen Ihnen eine Wiederherstellung in Google Cloud.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.