Ransomware mudou o cálculo do disaster recovery. Contra incêndio, enchente ou falha de hardware, o backup convencional resolve. Contra ransomware, ele pode ser parte do problema — porque atacante competente procura o backup antes de disparar a criptografia.
Por que o backup convencional falha aqui
Um desastre físico é indiferente aos seus dados: ele destrói e vai embora. Ransomware é adversarial. Existe alguém do outro lado com objetivo, tempo e conhecimento de que a sua capacidade de restaurar é justamente o que anula o poder de barganha dele.
O padrão observado em incidentes é permanência silenciosa: dias ou semanas dentro do ambiente antes de qualquer criptografia. Nesse período, o atacante mapeia a rede, escala privilégio e localiza o repositório de backup. Quando dispara, dispara nos dois.
Backup acessível com a mesma credencial de administrador do ambiente de produção não é uma segunda linha de defesa. É a mesma linha, com nome diferente.
Imutabilidade: o conceito que resolve
Backup imutável não pode ser alterado nem apagado durante um período definido — nem por quem tem credencial de administrador. A retenção é aplicada pelo próprio storage, não por política de software que alguém com privilégio suficiente consegue desligar.
Essa é a diferença que importa: proteção que não depende de o atacante não ter conseguido o acesso que ele provavelmente já tem.
Air gap resolve o mesmo problema por outro caminho — separação real entre a rede de produção e a cópia. Pode ser físico ou lógico. Os dois mecanismos são complementares, não alternativos.
A regra 3-2-1 ganhou dois números
O padrão clássico de três cópias, em duas mídias, com uma offsite, evoluiu para 3-2-1-1-0 justamente por causa de ransomware:
- 1 adicional: uma cópia imutável ou com air gap.
- 0: zero erro na verificação de restore. Não é aspiração, é requisito — backup verificado é o que separa recuperação de esperança.
O que muda no plano de DR
Recuperar de desastre físico é linear: subir o ambiente secundário e retomar. Recuperar de ransomware exige responder antes uma pergunta que não existe no cenário físico: quando a infecção começou?
Se você restaurar de um ponto posterior ao comprometimento inicial, você restaura o ransomware junto. É por isso que retenção curta é perigosa aqui. Se o atacante ficou três semanas no ambiente e você guarda quatorze dias de backup, todos os seus pontos de restauração estão contaminados.
Some a isso a necessidade de ambiente isolado para validar a cópia antes de reconectar à produção, e o RTO real de um incidente de ransomware fica bem acima do RTO de uma falha de hardware. Planos que declaram um número único para “desastre” costumam estar descrevendo apenas o cenário fácil.
Perguntas para fazer ao seu fornecedor
- O backup é imutável de verdade, aplicado pelo storage, ou é política de software?
- Qual é a janela de retenção, e ela cobre um período de permanência silenciosa realista?
- A credencial que acessa o backup é a mesma que administra a produção?
- Existe ambiente isolado para validar a cópia antes de reconectar?
- A verificação de integridade é automática e gera evidência, ou depende de alguém lembrar de conferir?
Onde a Adentro entra
Backup em nuvem e disaster recovery operados fora da sua rede de produção respondem à parte estrutural desse problema: a cópia não compartilha credencial nem perímetro com o ambiente atacado. Nosso time técnico detalha o modelo de retenção e imutabilidade aplicável ao seu caso.