Google Cloud veröffentlicht Details zum GCVE-Vorfall

 (cloud.google.com)
1 Punkte von GN⁺ 2024-05-26 | 1 Kommentare | Auf WhatsApp teilen
  • Der Vorfall bei Google Cloud im Mai 2024 betraf die Löschung eines Teils der GCVE-Umgebung des australischen Kunden UniSuper; nach einer internen Überprüfung wurden Ursache und Wiederherstellungsmaßnahmen offengelegt
  • Der Auswirkungsbereich war auf einen Kunden, eine Region, einen Dienst sowie auf eine von mehreren GCVE Private Clouds des Kunden begrenzt; andere Kunden und Google-Cloud-Dienste waren nicht betroffen
  • Während der ursprünglichen Bereitstellung blieb ein Eingabewert in einem internen Tool leer, und das System behandelte dies als festen Zeitraum von einem Jahr, wodurch die Private Cloud nach Ablauf dieses Zeitraums automatisch gelöscht wurde
  • Der Kunde und die Google-Teams arbeiteten mehrere Tage lang an einer 24x7-Wiederherstellung; Backups in GCS und Backup-Software von Drittanbietern wurden für die Wiederherstellung genutzt
  • Google Cloud hat das betreffende interne Tool stillgelegt, alle GCVE Private Clouds manuell überprüft und das Löschverhalten geändert, um zu verhindern, dass sich ein Vorfall dieses Typs wiederholt

Umfang des Vorfalls

  • Dieser Vorfall betraf den Google-Cloud-Kunden UniSuper; Google Cloud schloss die interne Überprüfung ab, nachdem die Systeme des Kunden wiederhergestellt worden waren
  • Die Auswirkungen waren bezogen auf von Google verwaltete Dienste begrenzt auf
    • einen Kunden
    • eine Cloud-Region
    • die Nutzung von Google Cloud VMware Engine (GCVE) durch den Kunden
    • eine Private Cloud über zwei Zonen hinweg unter den mehreren GCVE Private Clouds des Kunden
  • Es wurde auch abgegrenzt, was nicht betroffen war
    • andere Google-Cloud-Dienste
    • andere Kunden, die GCVE oder andere Google-Cloud-Dienste nutzen
    • andere GCVE Private Clouds des Kunden, Google Account, Orgs, Folders, Projects
    • Daten-Backups in Google Cloud Storage (GCS) in derselben Region

Ursache: leerer Parameter in einem internen Tool

  • Anfang 2023 stellte ein Google-Betreiber mit einem internen Tool eine der GCVE Private Clouds des Kunden bereit, um eine bestimmte Anforderung an die Kapazitätszuweisung zu erfüllen
  • Dieses Tool wurde für einen Ausnahmeprozess im Kapazitätsmanagement verwendet und im 4. Quartal 2023 stillgelegt sowie vollständig automatisiert, sodass kein menschliches Eingreifen mehr nötig war
  • Der Betreiber hielt sich an die internen Kontrollverfahren, doch während des Provisionierungsprozesses der Private Cloud blieb ein Eingabeparameter leer
  • Aufgrund dieses leeren Parameters wies das System dem betreffenden Parameter einen damals unbekannten Standardwert von einem festen Zeitraum von einem Jahr zu
  • Als der vom System zugewiesene Einjahreszeitraum endete, wurde die GCVE Private Cloud des Kunden gelöscht

Warum es keine Benachrichtigung an den Kunden gab

  • Die Löschung ging nicht auf eine Anfrage des Kunden zurück, sondern auf den leeren Parameter, der entstand, als ein Google-Betreiber das interne Tool verwendete
  • Hätte der Kunde die Löschung selbst angefordert, hätte es eine vorherige Benachrichtigung gegeben; bei dieser Löschung wurde jedoch keine Kundenbenachrichtigung versendet
  • Google Cloud erklärte, dass die auslösenden Bedingungen des Vorfalls und das Verhalten der beteiligten Untersysteme geändert wurden, damit sich so etwas nicht wiederholt

Wiederherstellungsprozess

  • Der Kunde und die Google-Teams arbeiteten mehrere Tage lang 24x7 zusammen, um die Wiederherstellung durchzuführen
    • Wiederherstellung der GCVE Private Cloud des Kunden
    • Wiederherstellung der Netzwerk- und Sicherheitskonfiguration
    • Wiederherstellung der Anwendungen
    • Datenwiederherstellung zur vollständigen Wiederaufnahme des Betriebs
  • Der robuste und resiliente Architekturansatz des Kunden half bei der Wiederherstellung
  • Die in Google Cloud Storage in derselben Region gespeicherten Daten-Backups waren von der Löschung nicht betroffen
  • Diese Backups und Backup-Software von Drittanbietern spielten eine wichtige Rolle bei der schnellen Wiederherstellung

Maßnahmen zur Verhinderung eines erneuten Auftretens

  • Google Cloud hat mehrere Maßnahmen umgesetzt, um ein erneutes Auftreten des Vorfalls zu verhindern
    • Das interne Tool, das den Ablauf des Vorfalls ausgelöst hatte, wurde stillgelegt
    • Selbst wenn spezielles Kapazitätsmanagement erforderlich ist, erfolgt die Steuerung nun durch den Kunden über die Benutzeroberfläche; die betreffenden Teile sind vollständig automatisiert
    • Die Systemdatenbank wurde bereinigt, und alle GCVE Private Clouds wurden manuell überprüft, um sicherzustellen, dass keine anderen GCVE-Bereitstellungen einem Risiko ausgesetzt sind
    • Das Systemverhalten im betreffenden Bereitstellungs-Workflow, das GCVE Private Clouds als Löschziel markierte, wurde geändert
  • Google Cloud bewertete den Vorfall als beispiellos und nicht als systemisches Problem
  • Google-Cloud-Dienste verfügen je nach Bedarf über Schutzmechanismen wie Soft Delete, Vorabbenachrichtigungen und Human-in-the-loop-Kombinationen; es wurde bestätigt, dass diese Schutzmechanismen weiterhin bestehen
  • Die enge Zusammenarbeit mit dem Kunden war wichtig für die schnelle Wiederherstellung, und resilientes Risikomanagement sowie Fail-safes für unerwartete Vorfälle sind entscheidend für eine rasche Wiederherstellung
  • Google Cloud erklärte, dass die eigene Uptime und Resilienz trotz dieses einmaligen Vorfalls laut unabhängiger Validierung weiterhin zu den besten unter den großen Cloud-Anbietern gehören

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-05-26
Hacker-News-Kommentare

  • Wenn man sich das Ausmaß der Auswirkungen dieses Vorfalls ansieht, ist es erstaunlich, dass die Gegenmaßnahmen nicht tiefgreifender sind. Im Grunde wurde nur sichergestellt, dass genau dasselbe Problem nicht noch einmal auf genau dieselbe Weise auftritt; falls später irgendwo ein gleichwertiger Fehler entsteht, könnte das zu ähnlichen oder noch schlimmeren Folgen führen
    Man hätte zum Beispiel Daten bei einer Dienstabschaltung nicht sofort löschen dürfen, sondern sie einige Tage aufbewahren und per Knopfdruck wiederherstellbar machen können, oder die Löschabläufe aller Dienste auditieren müssen, damit Kunden aus welchem Grund auch immer vor einer Abschaltung benachrichtigt werden, oder bei der Abschaltung aktiver Dienste ab einer gewissen Größenordnung eine manuelle Prüfung einbauen müssen
    Ohne solche breiter angelegten Maßnahmen beruhigt mich diese Postmortem-Analyse überhaupt nicht. Bei einem derart absurden Vorfall hätte ein Anbieter mit auch nur etwas Stolz auf den eigenen Dienst oder mit dem Wunsch, seinen Ruf zu schützen, geradezu demonstrativ zeigen müssen, dass so etwas nie wieder passieren kann, aber Google Cloud scheint nur das Minimum getan zu haben

    • Daten bei einer Dienstabschaltung nicht sofort zu löschen, ist so ein offensichtliches Grundprinzip von Enterprise-Software, dass es viel darüber aussagt, dass Google das 2024 nicht umgesetzt hatte
      Schon als Berufseinsteiger ergab die Vorstellung keinen Sinn, nicht mehr benötigte Daten sofort zu löschen. In Datenbanken war Soft Delete mit einer Spalte zum Markieren als gelöscht Standard, und Daten auf Festplatten wurden verschoben oder umbenannt, bis man sicher war, dass sie wirklich gelöscht werden konnten, während Backups ohnehin erhalten blieben
    • Stimme stark zu. Es wirkte eher so, als sei man mehr daran interessiert zu betonen, dass es kein systemisches Problem in der Art gebe, wie GCP-Betreiber die Plattform verwalten, und genau deshalb liest es sich umso mehr so, als gäbe es ein systemisches Problem, was beunruhigend ist. Dass in der Postmortem-Analyse naheliegende Maßnahmen fehlen, wirkt so, als habe man nicht vor, es wirklich zu beheben
    • Wenn man echte Löschungen in ein Lösch-Flag umwandelt, könnte das einen anderen interessanten Bug erzeugen, etwa „Google Cloud konnte Kundendaten nicht löschen und hat damit gegen EU-Vorschriften verstoßen“. Google würde sich vermutlich eher für versehentliche Nichtlöschung als für versehentliche Löschung entscheiden, und zumindest in der EU klingt das plausibel
    • Dass man so etwas nicht tut, wirkt wie ein Witz. Es ergibt keinen Sinn, dass ein riesiger Cloud-Anbieter nicht daran denkt, Schutzmechanismen für das Löschen von Daten einzubauen. Realistisch gesehen wurde sicher mehrfach darüber nachgedacht, aber vermutlich wegen der Kosten nicht umgesetzt
    • Ich verstehe Googles „Postmortem“ wirklich nicht. Jeder, der schon einmal einen Online-Dienst betrieben hat, erkennt nicht nur, dass es offensichtlich unzureichend ist, auch der Ton des Fazits ist voller Arroganz. Es klingt nach „Das war ein einmaliger Vorfall, wird nie wieder passieren, es tut uns wirklich leid, aber wir sind großartig und bleiben großartig“, und macht den Moment, in dem man sich bei Google Cloud nur noch an den Kopf fassen kann, überhaupt nicht wieder wett

  • Wenn man GCP-Kunde ist und einen TAM hat, sollte man unbedingt diese unangenehme Frage stellen: Welche Schutzmechanismen gibt es, damit GCP bei einem Verwaltungsfehler nicht versehentlich massenhaft Ressourcen in meinem Konto löschen kann?
    Wahrscheinlich wird man antworten, dass dieses konkrete Problem durch die Abschaffung des betreffenden Tools und mehr Automatisierung entschärft wurde, aber dann kann man nachhaken: „Ich weiß, dass genau das behoben wurde. Gibt es also vor großflächigen Löschungen eine menschliche Prüfung?“
    Aus Sicht von jemandem, der früher bei GCP gearbeitet und AWS noch länger intensiv genutzt hat, scheint es bei GCP fast keine menschengestützten Schutzmaßnahmen zu geben, jedenfalls deutlich weniger als bei AWS. Es lohnt sich auf jeden Fall, den TAM nach diesem realen Risiko zu fragen

    • Man sollte wirklich Druck machen. Dann lernen die TAMs, besser mit den internen Systemen umzugehen. Allein werden sie es nicht ändern können, aber manchmal kann man eine Zusage für einen Eskalationsweg nach oben oder eine informelle Vereinbarung bekommen
      Wenn genug TAMs laut genug Alarm schlagen, bewegt sich irgendwann vielleicht jemand weiter oben
    • Intern könnte es besser ankommen, wenn Google-Mitarbeiter bei anstehender Löschung von Kundenressourcen Kontakt aufnehmen und es als Chance zur Kundenbindung darstellen. Als Nebeneffekt wäre dann für alle klar ersichtlich, dass bald etwas verschwindet

  • Da steht, das „Google-Team habe mehrere Tage lang 24x7 gearbeitet“, aber offenbar weiß man dort nicht, wofür die 7 steht

    • Wahrscheinlich heißt das, dass 24 Ingenieure täglich 7 Stunden gearbeitet haben. Einschließlich Massagen und kostenloser, vom Chefkoch zubereiteter Kantinenkost
    • Wörtlich genommen ergibt das tatsächlich nicht ganz Sinn. Aber x7 bedeutet natürlich sieben Tage die Woche, also kann man auch von Donnerstag Nachmittag bis Dienstag Morgen 24x7 arbeiten. Gemeint ist, dass man das Wochenende nicht freigenommen hat
    • Vielleicht haben sie so viel gearbeitet, dass sich ein paar Tage wie ein paar Wochen angefühlt haben
    • Wenn die Gegenmaßnahmen über das Wochenende liefen, kann es schon Sinn ergeben
    • Es könnte auch heißen, dass Teammitglieder sich abgewechselt haben und nachts oder am Wochenende ohne Unterbrechung weitergearbeitet wurde. Persönlich finde ich, dass das bei einem solchen Großprojekt ohnehin Standard sein sollte

  • Wow, ich lag falsch. Ich dachte, standardmäßig würde irgendwo wie in Terraform sofort gelöscht, ohne Wiederherstellungsfrist, und jemand bei UniSuper habe beim Testen den Löschumfang falsch gesetzt. Dann wäre es immer noch ein Problem mit schlechten Defaults gewesen, aber ich ging von einem Fehler eines Drittanbieter-Tools und eines Fehlers auf Seiten von UniSuper aus
    Dass es tatsächlich ein Problem auf Google-Seite war, ist verrückt. Bei UniSuper muss man sich gedacht haben: „Was zur Hölle?“

    • Im Artikel steht, was passiert ist, und es hatte nichts mit UniSuper zu tun. Google hat mit einem internen Tool eine Private Cloud bereitgestellt, und dieses interne Google-Tool war so konfiguriert, dass nach einem Jahr automatisch gelöscht wird
    • Ich nehme an, Google hat große Gutschriften auf die GCP-Rechnung gegeben oder sogar eine separate Entschädigung gezahlt

  • Verwandte Beiträge: UniSuper members go a week with no account access after Google Cloud misconfig[0](186 points, 16 days ago, 42 comments), Google Cloud accidentally deletes customer's account [1](128 points, 15 days ago, 32 comments)
    [0]: https://news.ycombinator.com/item?id=40304666
    [1]: https://news.ycombinator.com/item?id=40313171

  • Es wirkt ziemlich gründlich, dass man nicht bei der Untersuchung eines bestimmten Tools oder Verfahrens stehen geblieben ist, sondern auch geprüft hat, ob es anderswo Probleme mit automatischer Löschung gibt, und das Verhalten beim Soft Delete verifiziert hat.
    Man hätte noch einen Schritt weitergehen und alle Standardfall-Szenarien darauf prüfen können, ob es überraschende Standardverhalten gibt. Allerdings kann es schwierig sein zu beurteilen, was „überraschend“ ist. Denn oft sind es gerade die Leute, die ein Tool oder eine API am wenigsten kennen, die einfach die Defaults verwenden.

    • Wo genau steht eigentlich der Teil „das Verhalten beim Soft Delete wurde ebenfalls geprüft“? Dort steht nur, dass sichergestellt wurde, dass dieses spezielle automatische Löschszenario nicht mehr auftreten kann, und der Hauptgrund scheint zu sein: „Die Bereitstellung ist jetzt automatisiert.“
      Früher war es auch schon automatisiert, und jetzt ist es eben noch stärker automatisiert — das gibt überhaupt keine Sicherheit, dass der Löschmechanismus durchgängig sicher ist. Es bedeutet nur, dass kein Operator mehr am Steuer sitzt.
    • Solche Vorfälle sind einfach ein hervorragender Grund, stattdessen AWS zu nutzen; intern dürfte man sich also ziemlich erschrocken haben.
      „Die GCVE Private Cloud des Kunden wurde gelöscht, nachdem der vom System gesetzte Zeitraum von einem Jahr abgelaufen war. Die Löschung wurde ausgelöst, weil ein Google-Mitarbeiter, der ein internes Tool verwendete, einen Parameter leer ließ; da es sich nicht um eine vom Kunden angeforderte Löschung handelte, wurde keine Kundenbenachrichtigung versendet. Bei einer vom Kunden initiierten Löschung hätte es eine Vorabbenachrichtigung gegeben.“
      Tadaa! Wir sind so unfähig, dass wir eine riesige Löschung ohne menschliche Prüfung zulassen. Zum Glück hat uns dieser Kunde nicht vertraut und Backups außerhalb von GCP gehabt, sodass nicht alles komplett verloren war.
      „Einen Vorfall dieser Art hat es bei Google Cloud zuvor nicht gegeben. Es handelt sich nicht um ein systemisches Problem.“
      Übersetzt heißt das: „Mein Gott, die AWS- und Azure-Vertriebsleute haben allen potenziellen Kunden jeweils drei E-Mails geschickt und dabei auf unser gigantisches Versagen verwiesen.“

  • Es ist schwer zu glauben, dass der erste Betroffene eines solchen Vorfalls ein Milliarden-Dollar-Mutual-Fund war. Gut, dass das Problem bei UniSuper gelöst wurde, aber vermutlich gab es wohl schon andere, kleinere Fälle, die man ignorieren konnte.
    Ich kann nur hoffen, dass das für GCP der nötige Weckruf ist.

    • GCVE, also Managed VMware, ist ein ziemlich obskurer Service. Das ist etwas, das nur Unternehmen mit Milliardenumsatz nutzen, die ihre bestehende VMware-Landschaft 1:1 in die Cloud heben und verschieben wollen.
    • Der Kern dieses Vorfalls ist, dass es eine spezielle kundenspezifische Konfiguration gab, die die meisten Kunden nicht haben oder nicht nutzen, und dass dadurch einige Sicherheitsprüfungen umgangen wurden. Deshalb konnte ein „normaler“ kleiner Kunde davon nicht betroffen sein.
    • Selbst ein kleiner Kunde hätte das wohl an die Presse gegeben, und die Presse hätte sicher darüber berichtet; deshalb überzeugt mich diese Sicht nicht.
      „Google hat unseren Cloud-Service gelöscht“ ist für Unternehmen jeder Größe eine große Nachricht.

  • Dort heißt es, „der CIO des Kunden und das Technikteam verdienen Lob dafür, dass sie in enger Zusammenarbeit mit dem Google-Cloud-Team die 24x7-Wiederherstellung schnell und präzise durchgeführt haben“ — da frage ich mich, ob sie im Blogpost nur gelobt wurden oder ob sie auch einen riesigen Batzen Google-Cloud-Credits herausgeholt haben.

    • Bei einem kompetenten Kunden gibt es keine realistische Möglichkeit, dass Google diese Kosten nicht tragen muss. Es würde mich nicht wundern, wenn die Rechnung für dieses Jahr komplett entfiele.
    • Es hätte auch Strafschadensersatz geben müssen.

  • Ich bin Kunde des australischen UniSuper. Damals wusste ich nicht, was los war, aber ich bekam während der Behebung jeden Tag E-Mails. Was tatsächlich passiert war, habe ich erst aus den Nachrichten erfahren. Es wirkte, als hätte man das Ganze auf bloßen Systemausfall heruntergespielt.
    Wenn man sich vorstellt, was tatsächlich mit Milliarden Dollar passiert ist, die aus dem Geld und den Pensionsfonds der Leute stammen, wird einem ganz anders.

    • Hast du dieselben E-Mails bekommen wie die anderen? Es kamen fast täglich E-Mails, und Wörter wie „disruption“, „apologies“ und „frustration“ wurden mehrfach verwendet.
      Ein paar Tage später kam auch eine E-Mail mit dem Betreff „A letter from the CEO“.
      „Wir möchten Ihnen ein Update zur Serviceunterbrechung geben.“
      „Zunächst möchte ich mich persönlich für diesen Ausfall entschuldigen und Ihnen dafür danken, dass Sie gewartet haben, während unser Team Tag und Nacht daran gearbeitet hat, die Systeme schrittweise wieder online zu bringen.“
      Ich glaube nicht, dass man in dieser Situation deutlichere Kommunikation oder eine klarere Erklärung dessen, was intern bei Google Cloud passiert war, realistischerweise hätte verlangen können.

  • Die erste Ankündigung zu diesem Vorfall war ziemlich irreführend. Es klang so, als hätte Google versehentlich das komplette GCP-Konto gelöscht. Nachdem ich diesen Beitrag gelesen habe, bin ich etwas beruhigt. Es scheint, als seien nur die virtuellen Maschinen im Umfang einer Region verloren gegangen, und so etwas kann tatsächlich passieren; ich denke, mein System könnte das ohne große Probleme verkraften.
    Im ursprünglichen Text klang es so, als wären GCS-Buckets, SQL-Datenbanken usw. in allen Regionen komplett verschwunden — das wäre ein völlig anderes Problem, und ich hoffe, man kann darauf vertrauen, dass Google so etwas nicht tut.

    • Als UniSuper sagte, dass nicht das Konto, sondern das Abonnement gelöscht worden sei, war das bereits ein Warnsignal. Viele Leute haben daraus vorschnell Schlüsse gezogen.