Atlassian 2022: script de exclusão derruba 775 clientes (883 sites) por até 14 dias

01 · CONTEXTO

Um site é o container que foi apagado

Em 5 de abril de 2022, a partir das 7:38 UTC, 775 clientes da Atlassian perderam o acesso aos seus produtos, e a interrupção durou até 14 dias para parte deles. O post-incident review público da empresa é a fonte deste caso.

Em uma arquitetura multi-tenant, um único serviço atende vários clientes, e cada data store contém dados de vários clientes. O container que reúne os produtos licenciados de um cliente é o site, e foi o container de site que foi excluído neste incidente.

1. O site é o container que reúne os produtos licenciados de um cliente.

2. Os dados de um site não ficam em um único banco ou repositório: estão distribuídos pela arquitetura.

3. Cada data store guarda dados de vários clientes, e a Atlassian precisou extrair e restaurar manualmente partes individuais dos backups.

02 · A EXCLUSÃO

Um pedido com o tipo de ID errado

A Atlassian precisava remover um aplicativo independente legado, o Insight – Asset Management, dos sites de clientes que o tinham instalado, e a equipe de engenharia usou um script e um processo já existentes para isso.

A empresa descreve dois problemas. O primeiro foi uma falha de comunicação entre a equipe que pediu a exclusão e a que a executou: em vez dos IDs do aplicativo, foram fornecidos os IDs do site inteiro. O segundo foi a API de exclusão, que aceita IDs de site e de aplicativo e presume que a entrada está correta; não havia aviso para confirmar o tipo de exclusão pedido.

A revisão por pares seguiu o processo padrão, focada em qual endpoint era chamado e como, e não cruzou os IDs de site informados para ver se se referiam ao aplicativo ou ao site inteiro. O teste em staging também não teria detectado o erro, porque esses IDs não existiam naquele ambiente.

1. O script exclui os sites em sequência, segundo a lista de entrada que recebeu.

2. Na primeira execução em produção, o script rodou contra 30 sites e apagou o aplicativo desses sites, sem outros efeitos.

3. A API aceita ID de site ou de aplicativo e presume que a entrada está correta, sem aviso sobre o tipo de exclusão.

4. Na execução seguinte, a lista trazia IDs de site no lugar dos IDs do aplicativo, para um conjunto de 883 sites.

5. Os sites foram excluídos de imediato, sem sinal de alerta para as equipes de engenharia.

03 · IMPACTO E DETECÇÃO

O monitoramento interno não viu a exclusão

O script começou a rodar às 7:38 UTC e terminou às 8:01 UTC de 5 de abril, e o resultado foi a exclusão imediata de 883 sites, que representavam 775 clientes.

Ficaram indisponíveis para os clientes afetados a família Jira, o Confluence, o Atlassian Access, o Opsgenie e o Statuspage. A empresa afirma que não foi um ataque cibernético e que não houve acesso não autorizado a dados de clientes.

O primeiro chamado de suporte de um cliente afetado foi criado às 7:46 UTC. O monitoramento interno não detectou problema, porque os sites foram excluídos por um fluxo padrão. O processo de gestão de incidentes maiores foi acionado às 8:17 UTC.

O mesmo script também apagou identificadores e contatos dos clientes, como a URL do site e os administradores. Como resultado, clientes foram impedidos de abrir chamados técnicos pelo canal normal de suporte, e levou dias para obter uma lista confiável de contatos.

04 · RECUPERAÇÃO

Sabia restaurar um site, não um lote grande

Os primeiros clientes foram restaurados em 8 de abril, e todos os sites foram restaurados progressivamente até 18 de abril.

Dois conceitos orientam a análise de recuperação de desastres. O RTO responde a quão rápido os dados podem ser recuperados e devolvidos ao cliente; o RPO, a quão recentes são os dados recuperados do backup. A própria empresa resume que, neste incidente, perdeu o RTO e cumpriu o RPO.

A Atlassian conseguia restaurar um data store individual a um ponto anterior no tempo e sabia recuperar um único site. O que não existia era a capacidade de selecionar um grande conjunto de sites e restaurar, a partir dos backups, todos os produtos interligados deles.

1. Na Restauração 1, cada site excluído exigia a criação de um novo site, e cada produto, serviço e data store precisava restaurar seus dados.

2. O novo site vinha com novos identificadores, considerados imutáveis, e muitos sistemas os embutem nos dados.

3. A Restauração 1, otimizada, levava cerca de 48 horas por lote de sites e recuperou 53% dos usuários afetados em 112 sites.

4. A Restauração 2 recriou os registros do site em todos os sistemas, reutilizando os identificadores antigos, o que removeu mais da metade das etapas de mapeamento.

5. A Restauração 2 levava cerca de 12 horas por site e recuperou 47% dos usuários afetados em 771 sites.

Com a primeira abordagem, restaurar todos os clientes levaria três semanas, e por isso a empresa propôs a segunda. Reusar os identificadores removeu mais da metade das etapas de mapeamento entre identificadores antigos e novos, incluindo a necessidade de coordenar com cada fornecedor de aplicativos de terceiros para cada site.

A validação manual também exigiu mobilização: a empresa precisou mobilizar mais de 450 engenheiros de suporte para executar verificações, com turnos de cobertura 24/7.

05 · PERDA DE DADOS

O ponto de restauração e a ressalva

Os bancos têm backups completos e incrementais que permitem escolher um ponto no tempo dentro do período de retenção de 30 dias. Para os principais data stores, a Atlassian usou como ponto de restauração cinco minutos antes da exclusão dos sites, e esse ponto fixo deu consistência entre todos os data stores. A empresa informa que cumpriu seu RPO de uma hora.

O resumo da empresa diz que nenhum cliente perdeu mais de cinco minutos de dados. A seção sobre dados traz uma ressalva: para 57 clientes restaurados no início, a falta de políticas consistentes e a recuperação manual de snapshots de backup levaram alguns bancos do Confluence e do Insight a serem restaurados a um ponto mais de cinco minutos anterior à exclusão. A inconsistência foi descoberta em uma auditoria posterior à restauração, e a empresa diz ter recuperado o restante dos dados e contatado esses clientes.

06 · LIÇÕES

Exclusão reversível e restauração ensaiada

A principal mudança anunciada é impedir globalmente a exclusão de dados e metadados de clientes que não tenham passado por um processo de soft delete. Nesse modelo, os dados só são removidos da produção depois que um período de retenção expira. A empresa também bloqueou imediatamente exclusões de sites em massa até que as mudanças fossem feitas.

Para o soft delete, a Atlassian prevê rollout em etapas: testar primeiro nos próprios sites e depois mover clientes progressivamente. Também exige teste de restauração dos dados excluídos antes de rodar em produção e um plano de rollback testado.

No programa de DR, a empresa diz que vai usar a automação e o aprendizado do incidente para acelerar o programa até o RTO definido em sua política, e que passará a rodar exercícios regulares de DR que restauram todos os produtos de um grande conjunto de sites.