O backup que você nunca testou não é um backup
Grupos de ransomware miram os backups primeiro, justamente porque uma restauração que funciona tira a alavanca deles. A maioria das organizações descobre seu tempo de recuperação durante o incidente.
One stopwatch, nothing else
A single mechanical stopwatch on a seamless bone-white surface, viewed slightly from above. Vast empty space around it. Nothing else in frame.
2400×1350 · WebP · <350KB
Toda organização que ajudamos a atravessar um incidente de ransomware tinha backups. Não é isso que faz diferença. O que faz diferença é se alguém já tinha restaurado a partir deles sob pressão de tempo, com a pessoa que normalmente faz isso indisponível, enquanto o controlador de domínio também estava criptografado.
Atacantes miram backups deliberadamente
Operadores modernos de ransomware não são oportunistas que por acaso criptografam um compartilhamento. Eles passam dias dentro da rede primeiro, e um dos primeiros objetivos é sua infraestrutura de backup — porque um cliente que consegue restaurar não paga. Apagam snapshots, corrompem repositórios e, se o seu servidor de backup está no domínio com uma conta de serviço admin de domínio, fazem isso com as suas próprias credenciais.
Se um atacante com admin de domínio consegue apagar seus backups, você não tem backups. Você tem cópias.
3-2-1-1-0, e a parte que todo mundo pula
- 3 cópias dos dados
- 2 tipos diferentes de mídia
- 1 cópia fora do site
- 1 cópia imutável ou isolada — armazenamento com object lock que um atacante com controle total ainda assim não apaga
- 0 erros na verificação de restauração
O zero final é o que cai fora, porque é o único que exige esforço contínuo em vez de uma compra. Tudo antes dele é arquitetura. Esse último dígito é hábito.
Como é um teste de restauração de verdade
Não um job de backup que reportou sucesso. Uma recuperação real, para infraestrutura isolada, de um sistema que importa, cronometrada, conduzida por alguém que não é quem a construiu. Você testa três coisas ao mesmo tempo: que os dados estão íntegros, que o runbook está correto e que um membro comum do time consegue segui-lo.
Faça com o runbook impresso. Durante um incidente real, seu wiki pode estar criptografado, seu SSO fora do ar e seu gerenciador de senhas ser um dos sistemas que você está tentando restaurar.
Os números que você deveria saber dizer
Para cada camada de sistema: quantos dados você pode perder (RPO), quanto tempo pode ficar fora (RTO) e — separadamente — o tempo de recuperação que você realmente mediu. A distância entre os dois últimos é sua exposição real, e é o único número deste texto que merece ir ao conselho.
A maioria das organizações que avaliamos encontra uma distância de três vezes ou mais. Não porque a tecnologia esteja errada, mas porque ninguém contou as horas para restaurar o Active Directory antes dos servidores de aplicação, nem percebeu que a cópia externa é restaurada por um link que leva onze horas para mover um terabyte.