Salesforce: Ein nicht eingegrenztes Datenbankskript legte alle Pardot-Daten offen und setzte 105 Instanzen außer Betrieb

Am 17. Mai 2019 führte Salesforce ein Datenbankskript aus, das mit seinem Marketingprodukt Pardot verbunden war und „dazu führte, dass Nutzern ein breiterer Datenzugriff als beabsichtigt gewährt wurde“: Aktuelle und ehemalige Pardot-Nutzer konnten alles in ihren Organisationen lesen und bearbeiten, wobei die Berechtigungseinstellungen ignoriert wurden. Um die Offenlegung einzudämmen, sperrte Salesforce den Zugriff auf jede Instanz mit einem betroffenen Kunden – insgesamt 105 Instanzen – und legte damit auch Mandanten lahm, die nichts mit Pardot zu tun hatten.

Die vollständige Störung dauerte 15 Stunden und 8 Minuten und endete um 01:04 PDT am 18. Mai – und in derselben Minute begann eine neue Störung. Um die Instanzen sicher wieder öffnen zu können, löschte Salesforce die Berechtigungen der betroffenen Nutzer und stellte nur Administratorkonten wieder her; die Kunden wurden aufgefordert, die Benutzerberechtigungen manuell neu zuzuweisen. Über das Wochenende wurde ein Skript entwickelt, um Berechtigungen aus Backups wiederherzustellen, doch am Sonntag meldete das Unternehmen eine Erfolgsquote von 89 %, sodass bei etwa einer von zehn Organisationen die Benutzerrechte weiterhin gelöscht waren – und in einigen Läufen gewährte das Skript erneut den breiten Zugriff, den es eigentlich beseitigen sollte.

Die Reparaturen zogen sich bis in die folgende Woche: Am Montag, dem 20. Mai, waren Tausende Tickets offen, Sandbox-Instanzen waren weiterhin nicht verfügbar, und der SVP of Engineering, Anmol Bhasin, entschuldigte sich in Kundengesprächen und sagte, die erste Korrektur sei „nicht erfolgreich“ gewesen und alle verfügbaren Engineering-Ressourcen arbeiteten an dem Problem. Die Korrektur wurde zu einer zweiten, längeren Störung als der ursprüngliche Fehler.

105 Instanzen offline; etwa 15 Stunden vollständiger Ausfall, danach Tage der Bereinigung im Nur-Lese-Modus; das Wiederherstellungsskript am Wochenende schlug bei etwa 1 von 10 Organisationen fehl

Die Änderung ging weit über ihren beabsichtigten Umfang hinaus: Eine Berechtigungskorrektur für eine Teilmenge von Pardot-Organisationen traf die gesamte Plattform, und keine Schutzvorrichtung fing die Ausweitung ab, bevor Nutzer Daten sahen, die sie niemals hätten sehen dürfen.

Die einzige sichere Eindämmung bestand darin, ganze Instanzen offline zu nehmen, sodass ein Fehler eines Produktteams zu einem gemeinsamen Ausfall für unabhängige Kunden auf derselben Infrastruktur wurde.

Der Rollback war nie geplant: Das Wiederherstellungsskript wurde über das Wochenende unter Druck geschrieben, schlug bei etwa 11 % der Organisationen fehl und gewährte manchmal erneut den Zugriff, den es beseitigen sollte.

Die Wiederherstellung verlagerte Arbeit auf die Kunden – Administratoren bauten die Benutzerberechtigungen von Hand neu auf – und dehnte einen eintägigen Vorfall auf eine Woche Bereinigung und Supportlast aus.

Nicht eingegrenzte Datenbankskripte sind ein Risiko auf Unternehmensebene. Grenzen Sie jede Änderung ein, führen Sie den Rollout schrittweise durch und bauen Sie zuerst den Rollback – sonst sperrt die Heilung mehr Kunden aus als die Krankheit.

Der Zugriff wurde ab dem 18. Mai schrittweise wiederhergestellt; die meisten Organisationen arbeiteten bis Montag, den 20. Mai, wieder, während Sandboxes und Nachzügler mehrere weitere Tage benötigten, da Salesforce sein Wiederherstellungsskript Instanz für Instanz ausführte. Salesforce erklärte, für die Mehrheit der Kunden sei außer der Prüfung der Berechtigungen keine Maßnahme erforderlich, doch der Vorfall wurde zu einem Standard-Fallbeispiel für die Eingrenzung von Änderungen und die Kontrolle des Auswirkungsradius bei Multi-Tenant-SaaS – und zu einem Grund, warum Plattformteams Datenbankskripten in der Produktion mit derselben Vorsicht begegnen wie Code-Deployments.