Um backup que nunca restaurou nada é uma aposta, não um controle. Quando o ransomware criptografa o ambiente, a diferença entre uma interrupção de horas e uma paralisia de semanas depende de dois números que muitas equipes nunca mediram de verdade: o RTO, tempo máximo aceitável para voltar a operar, e o RPO, volume máximo de dados que o negócio tolera perder. Quem administra nuvem, identidade ou aplicações críticas precisa transformar esses dois objetivos em requisitos verificados, com evidência documentada, antes do incidente. A ação prioritária é simples e adiável há tempo demais: agendar, ainda esta semana, um teste de restauração completo em ambiente isolado.
Por que backups falham na crise
A CISA trata o assunto como controle de preparação obrigatório. A orientação oficial do guia StopRansomware é manter backups offline e criptografados dos dados críticos e testar regularmente a disponibilidade e a integridade dessas cópias em um cenário de recuperação de desastres. A recomendação não é retórica: atores de ransomware procuram os repositórios de backup acessíveis na rede, coletam credenciais armazenadas no ambiente para alcançar as soluções de proteção e usam exploits públicos contra plataformas de backup sem correção. O alvo preferencial do ataque é justamente o mecanismo que deveria salvar a operação.
O padrão se repete em campanhas distintas. Grupos que praticam extorsão dupla sabem que a negociação perde força quando a vítima consegue restaurar sem pagar, então a primeira movimentação pós-intrusão costuma ser a caçada aos servidores de backup, às contas de administração da ferramenta de proteção e aos repositórios montados com credenciais reutilizadas. A negociação de resgate só vira arma quando a recuperação falhou, como mostrou a anatomia de ataques em que a conversa com a gangue era a única saída deixada pela vítima, no caso do grupo Medusa.
Definindo RTO e RPO
RTO e RPO não se escolhem no palpite. Eles derivam da análise de impacto: para cada processo de negócio, pergunta-se quanto tempo a operação sobrevive sem o sistema e quantos dados perdidos são aceitáveis antes de o processo deixar de ser confiável. Um ERP fiscal pode exigir RPO de minutos; um repositório de documentação interna tolera um dia. Sem essa separação por criticidade, a equipe trata tudo como urgente, gasta demais com storage e ainda assim não garante o que importa.
O erro comum é declarar objetivos no documento de continuidade e nunca confrontá-los com a realidade medida. Um RTO de quatro horas só existe se a restauração completa, incluindo validação de dados e checagens de integridade, já foi cronometrada dentro desse intervalo em ambiente comparável ao de produção. O mesmo vale para o RPO: se a janela de replicação é de seis horas, o objetivo declarado de uma hora é ficção. O guia de contingência do NIST, referência clássica da área, estrutura o plano em fases de ativação, recuperação e reconstituição, com teste, treinamento e exercício como etapa permanente do ciclo, não como evento único de assinatura do documento.
Imutabilidade com retenção verificável
Impedir que o invasor apague as cópias é a outra metade do problema. No S3 Object Lock da AWS, o modelo é de escrita única e leitura múltipla, e o modo de conformidade é o mais rígido: nesse modo, nem o usuário root da conta consegue apagar a versão protegida durante o período de retenção. A consequência operacional é direta: credenciais comprometidas, mesmo com privilégio máximo, não destroem a cópia que sustenta a recuperação. O modo de governança, mais flexível, admite bypass com permissão específica, o que o torna útil para validar a configuração antes de endurecer a retenção de verdade.
Imutabilidade, porém, não substitui teste. Uma cópia inalterável mas corrompida, incompleta ou sem as chaves de descriptografia acessíveis de forma independente continua sendo um fracasso de recuperação. A própria CISA recomenda cautela com storage imutável: configurado errado, gera custo relevante e pode não atender critérios de conformidade específicos. Quem opera múltiplas contas de nuvem deve ainda combinar a retenção com controles de perímetro, para que a conta de backup não seja alcançável pelo mesmo conjunto de credenciais comprometido na produção, uma extensão natural do perímetro de dados na AWS.
O teste que prova o plano
O teste de recuperação é o único momento em que o plano deixa de ser documento. A orientação da CISA para empresas é realizar testes agendados de recuperação para verificar a integridade dos backups, identificar comprometimentos possíveis e refinar os Recovery Time Objectives e os Recovery Point Objectives até que as necessidades do negócio estejam atendidas. Ou seja: o teste não valida só a cópia, valida o objetivo. Se a restauração cronometrada estoura o RTO declarado, o número que está errado é o do documento, e a decisão é investir em mais capacidade, reduzir o escopo do sistema ou renegociar a expectativa com o negócio.
Um ciclo mínimo de verificação tem cara de tabela, não de projeto:
| Frequência | Verificação | Critério de aprovação |
|---|---|---|
| Semanal | Conclusão dos jobs e checksum das cópias | Sem falha silenciosa; alerta disparado se faltar cópia |
| Mensal | Restauração pontual de amostra em ambiente isolado | Arquivo íntegro e legível por aplicação real |
| Trimestral | Recuperação parcial de um serviço crítico | Tempo medido dentro do RTO do serviço |
| Anual | Exercício completo com equipe de plantão | RTO e RPO globais cumpridos e lacunas registradas |
Durante o exercício, a restauração acontece em VLAN limpa, com sistemas verificados antes de entrarem na rede de recuperação, para não reintroduzir o agente que causou o incidente. O acesso às cópias precisa funcionar sem depender da rede comprometida: procedimento impresso, credenciais em cofre separado e chave de descriptografia guardada fora do alcance das contas administrativas de produção.
Prioridades de ação P1 e P2
P1: inventariar quais sistemas têm RTO e RPO declarados; cronometrar uma restauração real do serviço mais crítico; habilitar retenção imutável em modo de conformidade para as cópias de nível mais alto; e separar as credenciais da plataforma de backup das contas administrativas de produção.
P2: automatizar a verificação semanal de integridade com alerta de falha; incluir a recuperação nos exercícios de resposta a incidentes já existentes; revisar a análise de impacto a cada mudança relevante de arquitetura; e documentar cada teste com tempo medido, responsável e desvios encontrados, formando o histórico que fiscalizações e auditores passam a exigir.
Sinais a verificar
Antes do incidente, três sinais indicam fragilidade: jobs de backup sem verificação de restauração desde a criação; contas de backup com permissões administrativas compartilhadas com a produção; e objetivos de recuperação declarados que nunca foram cronometrados. Durante a resposta, o sinal crítico é a descoberta de que a cópia mais recente está criptografada ou ausente, o que caracteriza falha de isolamento. Depois da recuperação, o indicador que importa é a distância entre o tempo medido e o objetivo prometido ao negócio.