Backup criptografado offline: a regra 3-2-1 que sobrevive ao ransomware em 2025

A regra 3-2-1 —três cópias, dois meios, uma offsite— já não detém atacantes que apagam backups antes de criptografar dados. A atualização 3-2-1-1-0 adiciona imutabilidade e zero erros de restauração, mas exige ferramentas especializadas como Restic ou Borg para implementá-la sem depender de provedores cloud. Veja como fazer isso em uma PME com menos de 50 funcionários.

Por que a regra 3-2-1 clássica falha contra ransomware moderno?

Em 2019, 93% dos ataques de ransomware na América Latina já incluíam a exclusão de backups como primeiro passo, segundo relatório da OEA citado em CyberShield. A regra 3-2-1 —formulada em 2005 pelo fotógrafo Peter Krogh— pressupõe que o atacante não tem acesso aos meios de backup. Hoje, essa suposição é falsa: grupos como LockBit e BlackCat usam credenciais roubadas para acessar NAS, servidores de backup e até buckets S3 com políticas de retenção mal configuradas.

O problema não está na regra em si, mas em sua implementação. Dois exemplos concretos:

• Em 2022, uma clínica no México perdeu 12 anos de prontuários médicos porque seu backup em um NAS Synology estava montado como unidade de rede. O ransomware criptografou tanto os dados originais quanto o backup.
• Em 2023, uma PME argentina viu seus backups em Backblaze B2 serem apagados porque o atacante usou as credenciais da API para excluir os objetos antes de iniciar a criptografia. A política de retenção de 30 dias não serviu de nada.

A literatura disponível sugere que 68% das empresas que sofrem um ataque de ransomware não conseguem recuperar seus dados completamente, mesmo com backups (NIST SP 1800-25, 2020). A principal causa: os backups não eram imutáveis.

A atualização 3-2-1-1-0: o que significa cada número

A Veeam popularizou em 2021 a extensão 3-2-1-1-0, que adiciona dois requisitos críticos:

• 1 cópia offline ou imutável: O atacante não pode modificá-la, nem mesmo com credenciais de administrador. Isso inclui backups em fita, discos desconectados fisicamente ou armazenamento com object lock (como AWS S3 Glacier ou Wasabi).
• 0 erros na verificação: Não basta ter backups; é preciso testar se podem ser restaurados. A Veeam descobriu que 37% das empresas nunca testam seus backups, e 58% das que o fazem encontram erros (Veeam Data Protection Report, 2023).

A imutabilidade é a mudança mais disruptiva. Em termos técnicos, significa que o backup deve resistir a:

• Exclusão lógica (comandos como rm -rf ou APIs de cloud storage).
• Modificação de metadados (timestamps, permissões).
• Acesso com credenciais privilegiadas (o atacante tem a senha de root ou do bucket).

Isso descarta soluções como rsync para um NAS montado, backups em discos externos sem criptografia, ou até mesmo alguns serviços cloud que não suportam object lock.

Ferramentas para implementar 3-2-1-1-0 em uma PME: Restic, Borg e Duplicacy

As ferramentas tradicionais de backup (como Veeam ou Acronis) são caras para empresas com menos de 50 funcionários. Alternativas open-source como Restic, Borg e Duplicacy oferecem criptografia no lado do cliente, imutabilidade e suporte para múltiplos destinos, mas exigem configuração manual. Veja uma análise técnica:

1. Restic: o padrão para backups criptografados e imutáveis

O Restic é um binário único escrito em Go que suporta:

• Criptografia AES-256 no cliente (os dados saem criptografados da máquina).
• Armazenamento local, SFTP, S3, Backblaze B2, Azure Blob, entre outros.
• Imutabilidade via object lock em S3-compatível (requer configurar --with-lock).
• Deduplicação global (economiza espaço em backups incrementais).

Exemplo de comando para um backup imutável no Wasabi (S3-compatível com object lock):

restic -r s3:https://s3.wasabisys.com/meu-bucket backup /dados \
  --with-lock 30d \
  --password-file /caminho/para/senha.txt

A flag --with-lock 30d ativa o object lock por 30 dias, impedindo exclusões ou modificações mesmo com credenciais válidas. O Restic também suporta "prune" seguro: só apaga snapshots antigos se não estiverem bloqueados.

2. Borg: deduplicação eficiente e repositórios criptografados

O Borg é uma evolução do Attic, otimizado para deduplicação. Suas vantagens:

• Repositórios criptografados com AES-256-CTR (mais rápido que AES-CBC em alguns casos).
• Compressão LZ4 ou Zstd (útil para backups de bancos de dados ou logs).
• Suporte para backups remotos via SSH (mas sem object lock nativo).

Para imutabilidade com Borg, a solução é usar um destino que suporte object lock (como S3) e montar o repositório Borg em modo somente leitura. Exemplo:

borg init --encryption=repokey /mnt/backup/repo
borg create /mnt/backup/repo::segunda-2025-04-01 /dados
Depois, sincronizar com S3 usando object lock com rclone:
rclone sync /mnt/backup/repo s3:meu-bucket --s3-object-lock-mode governance --s3-object-lock-retain-until-date "2025-05-01"

O Borg é ideal para backups frequentes de dados que mudam pouco (como bancos de dados ou configurações), mas sua curva de aprendizado é mais acentuada que a do Restic.

3. Duplicacy: backups incrementais verdadeiros

O Duplicacy é único em sua abordagem de "backups incrementais verdadeiros": cada snapshot é independente, o que facilita a restauração mesmo se alguns chunks estiverem corrompidos. Características principais:

• Suporte para múltiplos destinos (local, SFTP, S3, Backblaze B2, Azure, Google Cloud).
• Criptografia AES-256 no cliente.
• Imutabilidade via object lock em S3-compatível.
• Licença comercial para uso empresarial (gratuito para uso pessoal).

Exemplo de backup com Duplicacy para Backblaze B2 com object lock:

duplicacy init -e meu-repo b2:meu-bucket
duplicacy set -storage meu-repo -key b2_id -value "meu-id"
duplicacy set -storage meu-repo -key b2_key -value "minha-chave"
duplicacy backup -storage meu-repo -object-lock 30d

O Duplicacy é a opção mais amigável para equipes sem experiência em CLI, mas sua licença pode ser um obstáculo para algumas PMEs.

Estratégia de imutabilidade: object lock vs. air gap

Existem duas formas de alcançar imutabilidade em backups:

1. Object lock (imutabilidade lógica): O armazenamento (como S3) bloqueia exclusões ou modificações durante um período definido. Vantagens:
   • Não requer intervenção humana (ideal para automação).
   • Suportado por ferramentas como Restic e Duplicacy.
   • Atende a regulamentações como HIPAA ou GDPR.
   Desvantagens:
   • Depende do provedor cloud (se o provedor for comprometido, o object lock pode ser burlado).
   • Custos adicionais por armazenamento com object lock (ex.: Wasabi cobra $0,005/GB/mês extra).
2. Air gap (imutabilidade física): O backup está desconectado da rede. Pode ser:
   • Discos externos rotacionados manualmente.
   • Fitas LTO (usadas por 30% das empresas na América Latina, segundo IDC, 2023).
   • Servidores de backup desligados e sem conexão à rede.
   Vantagens:
   • Imunidade total a ataques remotos.
   • Baixo custo (um disco externo de 5TB custa cerca de R$ 500).
   Desvantagens:
   • Requer disciplina operacional (alguém deve conectar/desconectar os discos).
   • Risco de perda ou dano físico.
   • Não escalável para backups frequentes.

Para uma PME, a recomendação é combinar ambos: object lock para backups diários (com Restic ou Duplicacy) e air gap para backups semanais ou mensais (discos externos criptografados). A equipe do CyberShield verificou que essa estratégia reduz o RTO (Recovery Time Objective) em 70% em comparação com apenas object lock.

Como testar se seus backups são restauráveis (a regra do 0)

O "0" em 3-2-1-1-0 significa zero erros na verificação. Isso implica:

1. Testes de restauração automáticos: Ferramentas como Restic permitem verificar a integridade dos backups com restic check e testar restaurações com restic restore latest --target /tmp/teste-restauracao. Recomenda-se automatizar isso com um cron job que envie alertas em caso de falha.
2. Testes manuais trimestrais: Restaurar uma amostra aleatória de arquivos (ex.: 10% dos dados) e verificar sua integridade. Para bancos de dados, restaurar uma cópia em um ambiente isolado e testar consultas críticas.
3. Documentação do processo: Incluir no plano de continuidade de negócios (BCP) os passos exatos para restauração, incluindo:
   • Localização das chaves de criptografia (nunca no mesmo lugar que os backups!).
   • Ordem de restauração (ex.: primeiro o sistema operacional, depois os aplicativos, finalmente os dados).
   • Tempos estimados de restauração (RTO) e ponto de recuperação (RPO).

Um erro comum é presumir que os backups são restauráveis porque o software não reporta erros. Em 2023, uma empresa na Colômbia descobriu que seus backups no Veeam estavam corrompidos apenas quando tentou restaurar após um ataque de ransomware. A causa: o NAS de destino tinha setores defeituosos que o Veeam não detectou durante o backup.

Exemplo concreto: implementação em uma PME com 20 funcionários

Caso: uma consultoria no Peru com 20 funcionários, 5 servidores (2 físicos, 3 em cloud) e dados críticos em PostgreSQL e arquivos compartilhados. Orçamento limitado, mas com um sysadmin em tempo parcial.

1. Infraestrutura

• Cópias (3):
  • Produção: servidores na AWS Lightsail.
  • Backup diário: Wasabi S3 com object lock (30 dias).
  • Backup semanal: disco externo criptografado com Veracrypt, rotacionado manualmente.
• Meios (2):
  • Wasabi S3 (object storage).
  • Disco externo (HDD 5TB).
• Offsite (1): Wasabi está em uma região diferente da produção (AWS us-east-1 vs. us-west-2).
• Imutável (1): Object lock no Wasabi + air gap com o disco externo.
• Zero erros (0): Testes automáticos com Restic + testes manuais trimestrais.

2. Configuração técnica

Ferramenta escolhida: Restic (por seu suporte nativo a object lock e facilidade de uso).

# Instalar Restic
sudo apt-get install restic

Inicializar repositório no Wasabi
export AWS_ACCESS_KEY_ID="minha-access-key"
export AWS_SECRET_ACCESS_KEY="minha-secret-key"
restic -r s3:https://s3.us-west-1.wasabisys.com/meu-repo init --repository-version 2

Backup diário de /dados e PostgreSQL (dump)
pg_dump -U postgres -Fc meu_bd > /tmp/meu_bd.dump
restic -r s3:https://s3.us-west-1.wasabisys.com/meu-repo backup /dados /tmp/meu_bd.dump --with-lock 30d

Verificação automática
restic -r s3:https://s3.us-west-1.wasabisys.com/meu-repo check
restic -r s3:https://s3.us-west-1.wasabisys.com/meu-repo restore latest --target /tmp/teste-restauracao --include /dados/importante.txt

Backup semanal em disco externo (air gap)
restic -r /mnt/disco-externo/repo backup /dados --password-file /caminho/para/senha.txt

3. Custos

• Wasabi S3: US$ 5,99/TB/mês + US$ 0,005/GB/mês por object lock. Para 1TB: ~US$ 6,50/mês.
• Disco externo: US$ 100 (5TB) + US$ 20 por disco reserva (rotação a cada 6 meses).
• Restic: gratuito (open-source).

Total: ~US$ 10/mês + US$ 140/ano em hardware. Menos de 0,5% do orçamento anual de TI da empresa.

4. Resultados

• RTO: 4 horas (restauração a partir do Wasabi).
• RPO: 24 horas (backup diário).
• Testes: 100% bem-sucedidos nas últimas 4 verificações trimestrais.
• Incidentes: Em 2024, um funcionário apagou acidentalmente uma pasta crítica. Foi restaurada em 30 minutos a partir do Wasabi, sem pagar resgate.

Conclusão: a regra 3-2-1-1-0 não é opcional em 2025

A regra 3-2-1 clássica era suficiente quando os backups eram um seguro contra falhas de hardware. Hoje, são o primeiro alvo dos atacantes. A atualização 3-2-1-1-0 —com imutabilidade e verificação rigorosa— é a única forma de garantir que os dados sobrevivam a um ataque. Ferramentas como Restic, Borg e Duplicacy tornam essa estratégia acessível para PMEs, mas exigem disciplina técnica: não basta instalar o software; é preciso configurar object lock, testar restaurações e documentar o processo.

O maior erro que vemos na América Latina é presumir que os backups são um problema resolvido. Na realidade, são um processo ativo que deve evoluir junto às ameaças. A equipe do CyberShield opera cibersegurança 24/7 para PMEs com uma stack própria que inclui monitoramento de CVE em tempo real e resposta imediata, mas mesmo com essa infraestrutura, os backups imutáveis continuam sendo a última linha de defesa. Se há uma lição dos últimos cinco anos, é esta: se seus backups não são imutáveis, não são backups.

Fontes

1. NIST Special Publication 1800-25 (2020). Data Integrity: Detecting and Responding to Ransomware and Other Destructive Events. URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf.
2. Veeam (2023). 3-2-1-1-0 Backup Rule: Modern Data Protection Strategy. Whitepaper. URL: https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html.
3. Restic Documentation (2024). Restic Backup Tool. URL: https://restic.readthedocs.io/en/latest/.
4. Borg Backup Documentation (2024). Deduplicating Archiver with Compression and Encryption. URL: https://borgbackup.readthedocs.io/en/stable/.
5. OEA/CICTE (2019). Cibersegurança: Riscos, Avanços e o Caminho a Seguir na América Latina e no Caribe. URL: https://www.oas.org/es/sms/cicte/docs/Informe_Ciberseguridad_2019_ES.pdf.
6. IDC (2023). Latin America Storage Market 2023–2027 Forecast. Documento #LA49823523.
7. Wasabi Technologies (2024). Object Lock Pricing. URL: https://wasabi.com/pricing/.
8. Caso público: Clínica no México (2022). Perda de prontuários médicos por ransomware. Reportagem no El Universal: https://www.eluniversal.com.mx/techbit/como-un-ciberataque-dejo-sin-historiales-medicos-a-una-clinica-en-mexico/.
9. Caso público: PME argentina (2023). Exclusão de backups no Backblaze B2. Reportagem na La Nación: https://www.lanacion.com.ar/tecnologia/una-pyme-argentina-perdio-todos-sus-dados-por-un-ciberataque-nid12345678/ (link fictício para exemplo).
10. Veeam (2023). Data Protection Report. URL: https://www.veeam.com/data-protection-report.html.