Salesforce : un script de base de données sans périmètre a ouvert toutes les données Pardot et mis hors service 105 instances

Le 17 mai 2019, Salesforce a exécuté un script de base de données lié à son produit marketing Pardot qui « a eu pour effet d'accorder aux utilisateurs un accès aux données plus large que prévu » : les utilisateurs actuels et anciens de Pardot pouvaient lire et modifier l'intégralité du contenu de leurs orgs, sans tenir compte des paramètres d'autorisation. Pour contenir l'exposition, Salesforce a bloqué l'accès à toutes les instances hébergeant un client concerné — 105 instances au total —, mettant ainsi hors service des tenants qui n'avaient aucun lien avec Pardot.

La perturbation totale a duré 15 heures et 8 minutes, prenant fin à 01 h 04 PDT le 18 mai — et une nouvelle perturbation a commencé à la même minute. Pour rendre les instances sûres à la réouverture, Salesforce a effacé les autorisations des utilisateurs concernés et n'a restauré que les comptes administrateurs, demandant aux clients de réattribuer manuellement les autorisations des utilisateurs. Pendant le week-end, l'entreprise a élaboré un script pour restaurer les autorisations à partir des sauvegardes, mais dimanche, elle a signalé un taux de réussite de 89 %, de sorte qu'environ une organisation sur dix avait encore ses droits d'utilisateur effacés — et, dans certaines exécutions, le script a réaccordé l'accès étendu qu'il était censé supprimer.

Les réparations se sont poursuivies la semaine suivante : lundi 20 mai, des milliers de tickets étaient ouverts, des instances sandbox étaient toujours hors service, et le vice-président senior de l'ingénierie, Anmol Bhasin, s'est excusé lors d'appels avec les clients, déclarant que la première correction n'avait « pas été couronnée de succès » et que toutes les ressources d'ingénierie disponibles étaient mobilisées sur le problème. La correction est devenue une seconde panne, plus longue que la défaillance initiale.

105 instances hors ligne ; environ 15 heures de panne totale, puis plusieurs jours de nettoyage en lecture seule ; le script de restauration du week-end a échoué pour environ 1 organisation sur 10

Le changement a largement dépassé son périmètre prévu : une correction d'autorisations destinée à un sous-ensemble d'orgs Pardot a touché toute la plateforme, et aucun garde-fou n'a détecté l'élargissement avant que les utilisateurs ne voient des données qu'ils n'auraient jamais dû voir.

Le seul confinement sûr consistait à mettre des instances entières hors ligne, si bien qu'une erreur d'une équipe produit est devenue une panne partagée pour des clients sans lien, hébergés sur la même infrastructure.

Le retour arrière n'avait jamais été conçu : le script de restauration a été écrit pendant le week-end sous pression, a échoué sur environ 11 % des orgs et a parfois réaccordé l'accès qu'il était censé supprimer.

La reprise a fait peser le travail sur les clients — les administrateurs ont reconstruit les autorisations des utilisateurs à la main —, transformant un incident d'une journée en une semaine de nettoyage et de charge de support.

Les scripts de base de données sans périmètre constituent un risque à l'échelle de l'entreprise. Délimitez chaque changement, déployez-le par étapes et concevez d'abord le retour arrière — sinon le remède exclut plus de clients que le mal.

L'accès a été progressivement rétabli à partir du 18 mai ; la plupart des organisations fonctionnaient de nouveau le lundi 20 mai, les sandbox et les cas les plus lents nécessitant plusieurs jours de plus, Salesforce exécutant son script de restauration instance par instance. Salesforce a indiqué qu'aucune action n'était nécessaire au-delà de la vérification des autorisations pour la majorité des clients, mais l'incident est devenu une étude de cas classique en matière de délimitation des changements et de maîtrise du rayon d'impact pour le SaaS multi-tenant — et une raison pour laquelle les équipes plateforme traitent les scripts de base de données en production avec la même prudence que les déploiements de code.