Salesforce: un script de base de datos sin alcance definido abrió todos los datos de Pardot y dejó a oscuras 105 instancias

El 17 de mayo de 2019, Salesforce ejecutó un script de base de datos vinculado a su producto de marketing Pardot que «tuvo como resultado otorgar a los usuarios un acceso a los datos más amplio de lo previsto»: los usuarios actuales y anteriores de Pardot podían leer y editar todo en sus organizaciones, ignorando la configuración de permisos. Para contener la exposición, Salesforce bloqueó el acceso a todas las instancias que contenían un cliente afectado —105 instancias en total—, dejando caídas a organizaciones que no tenían nada que ver con Pardot.

La interrupción completa duró 15 horas y 8 minutos, y terminó a las 01:04 PDT del 18 de mayo, y una nueva interrupción comenzó en ese mismo minuto. Para que las instancias fueran seguras de reabrir, Salesforce borró los permisos de los usuarios afectados y restauró solo las cuentas de administrador, indicando a los clientes que reasignaran los permisos de usuario a mano. Durante el fin de semana creó un script para restaurar los permisos desde las copias de seguridad, pero para el domingo informó de una tasa de éxito del 89 %, por lo que aproximadamente una de cada diez organizaciones seguía con los derechos de usuario borrados, y en algunas ejecuciones el script volvió a conceder el acceso amplio que debía eliminar.

Las reparaciones se prolongaron hasta la semana siguiente: para el lunes 20 de mayo había miles de tickets abiertos, las instancias de sandbox seguían caídas y el vicepresidente sénior de ingeniería, Anmol Bhasin, se disculpó en llamadas con clientes, diciendo que la primera corrección «no había tenido éxito» y que todos los recursos de ingeniería disponibles estaban dedicados al problema. La corrección se convirtió en una segunda interrupción, más larga que la avería original.

105 instancias fuera de línea; unas 15 horas de interrupción total y luego días de limpieza en modo de solo lectura; el script de restauración del fin de semana falló en aproximadamente 1 de cada 10 organizaciones

El cambio se ejecutó mucho más allá de su alcance previsto: una corrección de permisos para un subconjunto de organizaciones de Pardot afectó a toda la plataforma, y ninguna salvaguarda detectó la ampliación antes de que los usuarios vieran datos que nunca deberían haber visto.

La única contención segura era desconectar instancias enteras, de modo que un error de un equipo de producto se convirtió en una interrupción compartida para clientes no relacionados en la misma infraestructura.

La reversión nunca se diseñó: el script de restauración se escribió durante el fin de semana bajo presión, falló en aproximadamente el 11 % de las organizaciones y a veces volvió a conceder el acceso que debía eliminar.

La recuperación trasladó trabajo a los clientes —los administradores reconstruyeron los permisos de usuario a mano—, prolongando un incidente de un día en una semana de limpieza y carga de soporte.

Los scripts de base de datos sin alcance definido son un riesgo a nivel de empresa. Define el alcance de cada cambio, despliega por etapas y prepara primero la reversión; de lo contrario, el remedio deja fuera a más clientes que la enfermedad.

El acceso se fue restableciendo gradualmente desde el 18 de mayo; la mayoría de las organizaciones volvieron a funcionar para el lunes 20 de mayo, y los sandbox y los casos rezagados tardaron varios días más mientras Salesforce ejecutaba su script de restauración instancia por instancia. Salesforce dijo que la mayoría de los clientes no necesitaba hacer nada más allá de comprobar los permisos, pero el incidente se convirtió en un caso de estudio estándar sobre la definición del alcance de los cambios y el control del radio de impacto en el SaaS multiinquilino, y en una razón por la que los equipos de plataforma tratan los scripts de base de datos en producción con la misma cautela que los despliegues de código.