Proteção contra ransomware: backup 3-2-1 com cópia imutável e teste de restauração

Proteção contra ransomware com backup 3-2-1: cópia imutável com PBS em modo pull ou restic append-only, credenciais separadas e teste de restauração.

Para que serve

Grupos de ransomware procuram e apagam os backups antes de criptografar os servidores. Se a única cópia fica no mesmo servidor, no mesmo storage ou acessível com a mesma senha de administrador, ela vai junto. Este artigo explica como montar a proteção contra ransomware com uma estratégia 3-2-1 e uma cópia que o atacante não consegue apagar e como provar, com testes periódicos, que a restauração funciona.

A regra 3-2-1 (e o "1-0" extra)

Pré-requisitos

• Inventário do que precisa voltar: VMs, bancos de dados, arquivos, configurações.
• Definição de RPO (quanto dado você aceita perder) e RTO (em quanto tempo precisa voltar).
• Um destino de backup fora deste servidor, com credenciais próprias: outro servidor seu ou um provedor de armazenamento de objetos (a E-Consulters não oferece storage de backup). Para definir frequência e retenção, veja também o artigo «Como montar a política de backup do seu servidor dedicado: regra 3-2-1, retenção GFS e testes de restauração».

Como montar a proteção contra ransomware passo a passo

1. Separe as credenciais. O servidor de produção nunca deve ter senha de administrador do servidor de backup. Crie no destino um usuário que só consegue gravar backups, sem permissão para apagar ou fazer prune. Não ingresse o servidor de backup no mesmo domínio Active Directory da produção.
2. Primeira cópia (local, para restauração rápida). No Proxmox VE, agende backups das VMs em Datacenter > Backup, de preferência para um Proxmox Backup Server (PBS), que faz deduplicação e backups incrementais (veja também o artigo «Como fazer backup no Proxmox: VMs com vzdump e Proxmox Backup Server»). Use um usuário/token no PBS com papel DatastoreBackup, que cria backups mas não apaga os existentes.
3. Segunda cópia (fora do local e protegida). Escolha uma das abordagens:
   • PBS remoto em modo pull: instale um segundo PBS em outro local e crie nele um Sync Job que puxa os backups do PBS principal. Como quem inicia a conexão é o servidor remoto, um invasor no ambiente de produção não tem credenciais para apagar a cópia remota. Defina a retenção (prune) apenas no PBS remoto.
   • restic com rest-server em modo append-only: no servidor de destino, rode o rest-server com --append-only. O cliente consegue criar novos snapshots, mas não apagar nem alterar os antigos. A limpeza (restic forget --prune) é feita no próprio servidor de backup, nunca a partir da produção. Veja também o artigo «Backup com restic: como enviar backups criptografados para Backblaze B2, Wasabi ou Amazon S3».
   • Armazenamento de objetos com bloqueio (Object Lock / WORM): alguns provedores S3 oferecem retenção imutável por prazo definido. Confirme que a sua ferramenta de backup é compatível antes de adotar.
   • Mídia offline: um disco externo conectado apenas durante a cópia e guardado desligado. O PBS suporta datastores removíveis que sincronizam ao montar o disco.
4. Criptografe os backups que saem do servidor. No PBS e no restic, a criptografia é feita no cliente; guarde a chave/senha em pelo menos dois lugares seguros fora do servidor. Sem ela, o backup é inútil.
5. Defina retenção suficiente para detectar o ataque. Invasores podem ficar semanas no ambiente antes de agir. Um modelo comum: 7 diários, 4 semanais, 6 a 12 mensais. Com apenas 2 ou 3 dias de retenção, todas as cópias podem já estar contaminadas.
6. Cubra também os bancos de dados. Backup de VM ligada de um banco transacional pode não ser consistente. Gere dumps antes do backup (mysqldump --single-transaction, pg_dump) ou use o agente QEMU (qemu-guest-agent) com freeze do sistema de arquivos.
7. Monitore. Configure notificações de falha em Datacenter > Notificações no Proxmox e no PBS. Backup que falha em silêncio por semanas é um dos achados mais comuns após um ataque.

Como saber se funcionou: teste de restauração

Faça um teste ao menos uma vez por mês e sempre depois de mudanças grandes. Registre data, o que foi restaurado e quanto tempo levou.

1. Verifique a integridade. No PBS, agende um Verify Job no datastore. No restic:

   restic check --read-data-subset=10%

2. Restaure uma VM com outro ID. No Proxmox VE: selecione o storage de backup > Backups > escolha o backup > Restore, informe um VM ID livre (por exemplo, 999) e marque Unique para gerar novos endereços MAC.
3. Antes de ligar a VM restaurada, desconecte a placa de rede (Hardware > Network Device > Disconnect) para evitar conflito de IP com a produção.
4. Ligue e confira: o sistema inicia, a aplicação abre, o banco de dados tem os registros mais recentes esperados.
5. Para arquivos, restaure para um diretório temporário e compare:

   restic restore latest --target /srv/teste-restore --include /var/www
   diff -rq /var/www /srv/teste-restore/var/www | head

6. Teste a cópia remota também, não só a local. Simule o pior caso: a produção e o PBS local foram perdidos.
7. Apague a VM e os arquivos de teste ao final.

Problemas comuns

O backup existe, mas a restauração é muito lenta

Restaurar terabytes pela internet pode levar horas ou dias. Meça o tempo no teste e compare com o seu RTO. Se não couber, mantenha uma cópia local para restauração rápida e use a remota como última linha de defesa.

Perdi a chave de criptografia

Não há como recuperar. Por isso a chave precisa estar guardada fora do servidor (gerenciador de senhas e uma cópia impressa ou em cofre).

O prune está apagando backups do servidor remoto

No modo pull do PBS, revise a opção Remove vanished do Sync Job: se ativa, snapshots apagados no PBS principal também somem no remoto, o que anula a proteção. Desative-a e controle a retenção no próprio remoto.

Uso snapshot do Proxmox como backup

Snapshot fica no mesmo storage da VM. Se o servidor for perdido ou o host comprometido, o snapshot vai junto. Use-o para rollback rápido antes de atualizações, nunca como backup.

Perguntas frequentes

Backup protege contra ransomware?

Só se o atacante não conseguir alcançá-lo. É preciso ao menos uma cópia fora do servidor, com credenciais separadas e imutável ou offline, além de testes de restauração.

O que é backup imutável?

É uma cópia que não pode ser apagada nem alterada a partir do servidor de produção, como um PBS remoto em modo pull, um rest-server em modo append-only ou um bucket com Object Lock.

RAID protege contra ransomware?

Não. O RAID protege contra falha de disco; se os dados forem criptografados, o RAID espelha a criptografia.

Quantos dias de backup devo guardar?

O suficiente para perceber o ataque, que pode levar semanas. Um modelo comum é 7 diários, 4 semanais e 6 a 12 mensais.

Snapshot do Proxmox serve como backup?

Não. O snapshot fica no mesmo storage da VM e se perde junto com o servidor. Use-o só para rollback rápido antes de atualizações.

Precisa de ajuda?

Se tiver dúvidas sobre a rede ou os recursos do seu servidor para montar o ambiente de backup, abra um ticket pela área do cliente.