Resiliência cibernética: backup não é recuperação

23/10/2026 mindsecblog Artigos, Notícias 0

Backup não é recuperação — imagem interna

Ter backup e conseguir recuperar o negócio são coisas diferentes. A diferença costuma aparecer no pior momento possível: quando a equipe descobre que a cópia existe, mas restaurar aplicações, identidades, configurações e dependências leva muito mais tempo do que o negócio consegue suportar.

Backup responde uma pergunta importante: existe uma cópia dos dados? Resiliência precisa responder várias outras. Essa cópia está íntegra? O atacante consegue apagá-la? Quanto tempo leva para restaurar? Em que ordem os serviços voltam? Qual ambiente será usado? As credenciais de administração continuam confiáveis?

Ransomware mudou a conversa sobre backup

Ataques modernos não se limitam a criptografar arquivos locais. Em muitos casos, o invasor procura consoles de backup, repositórios, credenciais administrativas e mecanismos de recuperação antes de disparar a etapa mais visível.

Faz sentido para o atacante. Se a vítima consegue restaurar rapidamente, a pressão da extorsão diminui. Destruir ou corromper a capacidade de recuperação aumenta o poder de negociação.

Além disso, a extorsão dupla continua relevante. Mesmo com backup perfeito, dados exfiltrados podem ser usados para pressionar a empresa.

Relatórios verdes de backup provam que uma tarefa rodou. Não provam que o serviço inteiro volta.

Uma aplicação depende de banco, DNS, certificados, secrets, identidade, storage, rede, filas e integrações. Restaurar apenas a base de dados pode resultar em um sistema tecnicamente “recuperado” que ainda não funciona para o usuário.

O teste que vale é o de restauração, de preferência com medição de tempo e validação do serviço completo.

RTO e RPO são fáceis de definir em documento. O desafio é comprovar que são atingíveis.

Se o negócio diz que o ERP pode ficar quatro horas fora, mas o último exercício de recuperação levou 14, existe uma diferença que precisa ser tratada. O número oficial não muda a física da recuperação.

Da mesma forma, um RPO de 15 minutos exige arquitetura, frequência de cópia e processo capazes de entregar isso. Não é uma intenção.

Notícias Relacionadas

Imutabilidade ajuda, mas não substitui isolamento

Cópias imutáveis reduzem a possibilidade de alteração ou exclusão durante uma janela definida. É um controle muito importante. Ainda assim, o desenho precisa considerar credenciais, console de administração, retenção e capacidade de restaurar em um ambiente limpo.

Se a mesma identidade administrativa controla produção e backup, o comprometimento de uma conta pode alcançar os dois lados. Separação de funções e domínios de confiança ajuda a reduzir esse risco.

Uma restauração apressada pode devolver dados para infraestrutura que ainda contém persistência do atacante. Por isso, recuperação e resposta a incidentes precisam trabalhar juntas.

Antes de voltar serviços críticos, a equipe precisa ter um nível razoável de confiança de que identidade, endpoints, servidores e caminhos administrativos foram tratados. Em certos casos, isso exige reconstrução em ambiente novo, não simples restauração sobre a mesma base.

O que precisa ser testado de verdade

Integridade da cópia. O dado restaurado precisa ser utilizável, não apenas existir.
Tempo total. Medir recuperação completa, incluindo dependências e validação.
Credenciais de emergência. Saber como administrar backup se o diretório corporativo estiver indisponível.
Ambiente limpo. Definir onde reconstruir serviços caso a infraestrutura original esteja comprometida.
Ordem de recuperação. Identidade, DNS e serviços básicos normalmente precedem aplicações de negócio.
Comunicação e decisão. Tecnologia não é a única parte do exercício; o negócio também precisa participar.

Falhas de backup, redução súbita de retenção, exclusão de jobs, mudança de política e login administrativo incomum deveriam gerar sinais de segurança. Não faz sentido tratar o ambiente de backup como operação silenciosa até o dia em que alguém precisa dele.

Essa talvez seja a mudança de mentalidade mais importante. Resiliência não está armazenada no repositório de backup. Ela existe na capacidade conjunta de pessoas, processos e tecnologia de voltar a operar.

O NIST, ao atualizar seu perfil de ransomware para o CSF 2.0, reforça essa visão mais ampla: governança, proteção, detecção, resposta e recuperação fazem parte do mesmo ciclo.

Um restore técnico pode ser perfeito e ainda não responder ao que a empresa realmente precisa. Durante um incidente, alguém terá de decidir quais serviços voltam primeiro, que dados podem ser aceitos com alguma perda, quais integrações podem permanecer desligadas e quando o risco de retornar à operação é aceitável.

Por isso, tabletop e testes de restauração funcionam melhor quando incluem tecnologia, negócio, jurídico e comunicação. O objetivo não é apenas provar que o backup abre. É ensaiar as decisões que normalmente aparecem sob pressão, com informação incompleta e tempo curto.

Conclusão

Backup continua indispensável. Só não deve ser confundido com garantia de recuperação.

Uma organização resiliente sabe quais serviços precisa recuperar primeiro, quanto tempo isso realmente leva, onde estão as dependências e como evitar que o atacante destrua ou contamine a própria recuperação.

O momento de descobrir se o backup funciona é durante o exercício. Não durante o ransomware.