Was geschah, als Google Cloud die Private Cloud von UniSuper löschte?

Was geschah beim UniSuper-Vorfall in Google Cloud?

Google Cloud hat versehentlich das Private-Cloud-Abonnement gelöscht, auf dem die Kernsysteme von UniSuper liefen. Das war kein Cyberangriff, sondern ein Konfigurationsfehler auf Seiten des Anbieters, und er entfernte die gesamte Umgebung auf einmal.

UniSuper ist einer der größten Pensionsfonds Australiens. Laut der gemeinsamen Erklärung von UniSuper und Google Cloud vom 8. Mai 2024 investiert der Fonds „über 135 Milliarden Dollar im Auftrag von mehr als 647.000 Mitgliedern“. In der Erklärung, die zusammen mit Google-Cloud-CEO Thomas Kurian abgegeben wurde, heißt es, „eine unbeabsichtigte Fehlkonfiguration bei der Bereitstellung der Private-Cloud-Dienste von UniSuper führte letztlich zur Löschung des Private-Cloud-Abonnements von UniSuper“. Die Erklärung nennt den Vorfall ein isoliertes, „einmaliges Ereignis“, das keinem anderen Google-Cloud-Kunden je passiert sei.

Der Vorfall betrifft weit mehr als Australien. Er ist das klarste öffentliche Beispiel dafür, warum wir Cloud-Workloads als Teil einer Strategie mit Backup as a Service behandeln, statt anzunehmen, dass die Ausfallsicherheit des Anbieters Ihre Daten abdeckt. Wer auf einem Hyperscaler läuft, kann denselben Fehler erleben, so selten er auch ist.

Warum hat Google Cloud die Private Cloud von UniSuper gelöscht?

Weil in einem internen Google-Tool ein Eingabefeld leer blieb. Das System wies dem Abonnement daraufhin eine feste Standardlaufzeit zu und löschte es, als diese endete.

In seiner Erläuterung nach dem Vorfall, Details of Google Cloud GCVE incident, schrieb Google, dass „bei der Bereitstellung der Private Cloud des Kunden mit einem internen Tool ein Eingabeparameter leer blieb“. Der leere Parameter führte dazu, dass das System „eine damals unbekannte, standardmäßig feste Laufzeit von einem Jahr“ vergab. Als das Jahr endete, wurde die Private Cloud gelöscht. Es ging keine Benachrichtigung an den Kunden, weil die Löschung von Google-Mitarbeitenden im Betrieb ausgelöst wurde, die das Tool nutzten, und nicht von einer Kundenanfrage.

Google sagt, es habe das interne Tool inzwischen außer Betrieb genommen, jede GCVE-Private-Cloud auf dasselbe Risiko geprüft und das Löschverhalten korrigiert. Das ist eine vernünftige Reaktion. Sie bestätigt aber auch, dass das Risiko für den Kunden bis zu dem Tag unsichtbar war, an dem es eintrat.

Warum hat die geografische Redundanz UniSuper nicht geschützt?

Weil Redundanz eine einzelne Umgebung an mehr Orte kopiert. Wird die Umgebung selbst auf Abonnementebene gelöscht, verschwinden alle Replikate mit.

Die gemeinsame Erklärung ist eindeutig: UniSuper „hatte als Schutz vor Ausfällen und Verlust eine Duplizierung in zwei geografischen Regionen“, doch die Löschung des Abonnements „führte zur Löschung in beiden dieser Regionen“. Googles späterer Beitrag beschreibt die Auswirkung als „einen Kunden in einer Cloud-Region“. Die beiden Darstellungen fassen den Umfang unterschiedlich, stimmen aber im Kern überein: Die replizierte Umgebung war weg.

Genau darin liegt der Kernunterschied zwischen Redundanz und Backup. Redundanz schützt vor Hardware- oder Standortausfällen. Vor einem gelöschten Abonnement, einem kompromittierten Administratorkonto oder einem falschen Befehl schützt sie nicht, weil das Replikat derselben Steuerungsebene gehorcht. Googles eigener Leitfaden zur geteilten Verantwortung legt Daten und Zugriffsrichtlinien aus genau diesem Grund auf die Kundenseite. Dieselbe Falle behandeln wir in Ist Multicloud eine Backup-Strategie?

Welche Rolle spielten Backups bei Dritten für die Wiederherstellung von UniSuper?

Eine entscheidende. Sowohl UniSuper als auch Google führen die Wiederherstellung auf Backups zurück, die die Löschung nicht berührte, darunter Kopien außerhalb der Google-Umgebung.

In der gemeinsamen Erklärung heißt es: „UniSuper hatte Backups bei einem zusätzlichen Dienstleister eingerichtet. Diese Backups haben den Datenverlust minimiert und die Möglichkeiten von UniSuper und Google Cloud, die Wiederherstellung abzuschließen, erheblich verbessert.“ Googles Beitrag ergänzt, dass Backups in Google Cloud Storage in derselben Region von der Löschung nicht betroffen waren und „zusammen mit Backup-Software von Drittanbietern entscheidend für die schnelle Wiederherstellung waren“.

Schnell ging es trotzdem nicht. Die Analyse des Ausfalls von InformationWeek datiert den Beginn auf den 2. Mai 2024, der Zugang der Mitglieder kehrte um den 9. Mai zurück. DatacenterDynamics berichtete, dass sich Mitglieder am 13. Mai wieder anmelden und Kontostände einsehen konnten. Die Teams arbeiteten rund um die Uhr daran, Netzwerk, Sicherheitskonfiguration, Hunderte virtuelle Maschinen und Datenbanken neu aufzubauen. Die Daten zu haben war notwendig; die Umgebung darum herum neu aufzubauen kostete die Zeit.

Welche Lehren ziehen europäische Organisationen daraus?

Bewahren Sie eine Kopie auf, die Ihr Anbieter nicht löschen kann, und stellen Sie sicher, dass Sie daraus schnell wieder eine funktionierende Umgebung machen können. Fünf Lehren stechen heraus.

1. Ein Fehler des Anbieters ist ein reales Risiko, auch wenn er selten ist. Geteilte Verantwortung heißt nicht, dass der Anbieter nie Fehler macht. Sie heißt, dass Ihre Wiederherstellung nicht davon abhängen darf, dass er keine macht.
2. Das Abonnement ist eine einzige Ausfalldomäne. Regionen, Zonen und Replikate innerhalb eines Kontos oder Vertrags können gemeinsam verschwinden.
3. Backups außerhalb der Ausfalldomäne entscheiden über das Ergebnis. Idealerweise liegen sie bei einem anderen Betreiber, mit anderen Zugangsdaten und auf unveränderlichem Speicher.
4. Daten sind nicht dasselbe wie ein laufender Dienst. Eine ganze Umgebung wiederherzustellen dauert Tage, wenn Standby-Infrastruktur und Notfallhandbücher nicht bereitstehen. Was die Dauer bestimmt, steht in Wie lange dauert die Wiederherstellung nach einem Ransomware-Angriff?
5. Sie bekommen nicht immer eine Warnung. UniSuper erhielt vor der Löschung keine Benachrichtigung. Überwachen Sie Ihre eigene Umgebung und Ihre Backups.

Für Organisationen im Anwendungsbereich von NIS2 passen diese Lehren direkt zu Art. 21 Abs. 2 lit. c NIS2-Richtlinie (EU) 2022/2555, der die Aufrechterhaltung des Betriebs nennt, etwa Backup-Management und Wiederherstellung nach einem Notfall, und zu Art. 21 Abs. 2 lit. d, der Sicherheit der Lieferkette. Unser Artikel zu den NIS2-Anforderungen an die Sicherheit der Lieferkette zeigt, wie Sie Cloud-Anbieter als Lieferanten bewerten.

Wie wenden Sie die UniSuper-Lehren auf Ihre eigene Cloud an?

Gehen Sie davon aus, dass Ihr Cloud-Abonnement verschwinden kann, und planen Sie von dort rückwärts. Fünf Schritte machen aus der Lehre Praxis.

1. Erfassen Sie Ihre Anbieterabhängigkeiten. Listen Sie auf, welche Systeme stoppen würden, wenn ein Cloud-Konto oder -Abonnement verschwindet.
2. Ergänzen Sie eine externe, unveränderliche Kopie. Folgen Sie der 3-2-1-1-0-Regel mit mindestens einer Kopie außerhalb Ihres primären Anbieters.
3. Beziehen Sie auch SaaS ein. Microsoft 365 und Google Workspace haben dieselbe Abhängigkeit; siehe Was passiert, wenn Ihr SaaS-Anbieter ausfällt?
4. Planen Sie, wohin Sie wiederherstellen. Ist die primäre Umgebung weg, brauchen Sie einen anderen Ort, an dem Ihre Systeme laufen.
5. Testen Sie ein Szenario mit Totalverlust. Testen Sie keine einzelne Datei, sondern einen ganzen Anwendungsstack, mindestens einmal im Jahr.

Unser Google-Cloud-Backup bewahrt diese externe Kopie in unseren eigenen Tier-III-Rechenzentren in Deutschland und den Niederlanden auf, unabhängig von großen US-Cloud-Anbietern, unveränderlich mit Object Lock plus einer Air-Gap-Kopie. Mit Disaster Recovery erhalten Sie zusätzlich eine Standby-Infrastruktur, den sofortigen Start von VMs in einer isolierten Wiederherstellungsumgebung in einem separaten, sauberen Netzwerk und eine Wiederherstellung kritischer Workloads mit einem SLA von 4 Stunden. Ein zertifizierter Engineer prüft den ersten Test-Failover, in der Regel innerhalb von 10 Tagen, und jedes Quartal laufen automatisierte DR-Tests mit Nachweisen für Prüfer.

Ihre nächsten Schritte

UniSuper hat vieles richtig gemacht: Es hatte Redundanz und, entscheidend, Backups außerhalb der Umgebung, die gelöscht wurde. Deshalb konnte es sich erholen. Der Vorfall zeigt, dass die Ausfallsicherheit Ihres Anbieters seine Plattform schützt, nicht Ihr Konto, und dass nur eine unabhängige Kopie plus eine geprobte Wiederherstellung den seltenen Tag abdeckt, an dem der Anbieter die Ursache ist.

Beantworten Sie diese Woche eine Frage: Wenn Ihr wichtigstes Cloud-Abonnement heute Nacht verschwände, woraus würden Sie wiederherstellen, und wohin? Ist die Antwort unklar, beginnen Sie mit den Grundlagen von Backup as a Service und unserem Ratgeber zur geteilten Verantwortung bei Google Cloud.

Vereinbaren Sie eine kostenlose 15-minütige Demo und sehen Sie eine isolierte Wiederherstellung aus einer Kopie außerhalb der Plattform.

Dieser Artikel ist eine allgemeine Information und keine Rechtsberatung.