Salesforce: um script de banco de dados sem escopo abriu todos os dados do Pardot e derrubou 105 instâncias

Em 17 de maio de 2019, a Salesforce executou um script de banco de dados vinculado ao seu produto de marketing Pardot que "resultou na concessão aos usuários de acesso a dados mais amplo do que o pretendido": usuários atuais e antigos do Pardot podiam ler e editar tudo em suas orgs, ignorando as configurações de permissão. Para conter a exposição, a Salesforce bloqueou o acesso a todas as instâncias que continham um cliente afetado — 105 instâncias no total —, derrubando tenants que nada tinham a ver com o Pardot.

A interrupção total durou 15 horas e 8 minutos, terminando às 01h04 PDT de 18 de maio — e uma nova interrupção começou no mesmo minuto. Para tornar as instâncias seguras para reabertura, a Salesforce apagou as permissões dos usuários afetados e restaurou apenas as contas de administrador, instruindo os clientes a reatribuir as permissões de usuário manualmente. Ao longo do fim de semana, criou um script para restaurar permissões a partir de backups, mas, até domingo, relatou uma taxa de sucesso de 89%, de modo que aproximadamente uma organização em cada dez ainda tinha os direitos de usuário apagados — e, em algumas execuções, o script reconcedeu o acesso amplo que deveria remover.

Os reparos se estenderam pela semana seguinte: até segunda-feira, 20 de maio, milhares de tickets estavam abertos, instâncias de sandbox ainda estavam fora do ar, e o vice-presidente sênior de engenharia, Anmol Bhasin, pediu desculpas em ligações com clientes, dizendo que a primeira correção "não teve sucesso" e que todos os recursos de engenharia disponíveis estavam dedicados ao problema. A correção tornou-se uma segunda interrupção, mais longa que a original.

105 instâncias offline; cerca de 15 horas de interrupção total, seguidas de dias de limpeza em modo somente leitura; o script de restauração do fim de semana falhou para aproximadamente 1 em cada 10 orgs

A mudança foi muito além do escopo pretendido: uma correção de permissões para um subconjunto de orgs do Pardot atingiu toda a plataforma, e nenhuma proteção detectou a ampliação antes que os usuários vissem dados que jamais deveriam ter visto.

A única contenção segura era colocar instâncias inteiras offline, de modo que um erro de uma equipe de produto se tornou uma interrupção compartilhada para clientes não relacionados na mesma infraestrutura.

A reversão nunca foi planejada: o script de restauração foi escrito durante o fim de semana sob pressão, falhou em cerca de 11% das orgs e, por vezes, reconcedeu o acesso que deveria remover.

A recuperação transferiu trabalho para os clientes — administradores reconstruíram permissões de usuário manualmente —, estendendo um incidente de um dia para uma semana de limpeza e carga de suporte.

Scripts de banco de dados sem escopo são um risco de nível empresarial. Defina o escopo de cada mudança, faça a implantação em etapas e construa a reversão primeiro — ou a cura bloqueará mais clientes do que a doença.

O acesso foi gradualmente restaurado a partir de 18 de maio; a maioria das organizações voltou a funcionar até segunda-feira, 20 de maio, com sandboxes e casos remanescentes levando vários dias mais, à medida que a Salesforce executava seu script de restauração instância por instância. A Salesforce afirmou que nenhuma ação era necessária além de verificações de permissão para a maioria dos clientes, mas o incidente tornou-se um estudo de caso padrão em definição de escopo de mudanças e controle de raio de impacto para SaaS multi-tenant — e um motivo para as equipes de plataforma tratarem scripts de banco de dados em produção com a mesma cautela que implantações de código.