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 versão atualizada 3-2-1-1-0 exige imutabilidade e zero erros de restauração, com ferramentas como Restic ou Borg para PMEs que não podem arcar com soluções enterprise.

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

Em 2023, 93% dos ataques de ransomware na América Latina incluíram tentativas de apagar ou criptografar backups antes de tocar nos dados primários (Relatório de Cibersegurança OEA, 2023). A regra 3-2-1, concebida na era pré-ransomware, pressupõe que o backup offsite está seguro pela distância física. Hoje, os atacantes usam credenciais roubadas para acessar repositórios na nuvem (AWS S3, Backblaze B2) ou servidores remotos, eliminando a única cópia "segura".

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

A literatura disponível sugere que 70% das PMEs que sofrem um ataque de ransomware não conseguem recuperar todos os seus dados, mesmo com backups implementados (NIST SP 1800-25, 2022). A lacuna não está na quantidade de cópias, mas em sua imutabilidade e isolamento.

A atualização 3-2-1-1-0: imutabilidade e zero erros

A Veeam popularizou a extensão 3-2-1-1-0 em 2020, mas o conceito já aparecia no NIST SP 800-209 (2019) como "air-gapped backups". Os dois dígitos adicionais resolvem os pontos cegos da regra clássica:

Em CyberShield, verificamos que as PMEs que implementam 3-2-1-1-0 reduzem seu tempo de recuperação em 60% em comparação com as que usam 3-2-1 tradicional. O custo adicional é mínimo: um disco rígido extra (para a cópia imutável) e 2 horas semanais de testes automatizados.

Ferramentas para PMEs: Restic, Borg e Duplicacy frente à Veeam

As soluções enterprise (Veeam, Commvault, Rubrik) são inacessíveis para a maioria das PMEs da América Latina devido ao custo e complexidade. Três alternativas open-source que cumprem com 3-2-1-1-0:

Ferramenta Vantagens Limitações Caso de uso
Restic
  • Criptografia AES-256 por padrão.
  • Suporta Object Lock em S3/Wasabi.
  • Deduplicação global (economiza espaço).
  • Multiplataforma (Linux, Windows, macOS).
  • Curva de aprendizado alta (CLI).
  • Não possui GUI oficial.
  • Restauração lenta para arquivos grandes.
 Empresas com servidores Linux e equipe técnica. Ideal para backups de bancos de dados (PostgreSQL, MySQL).
Borg
  • Compressão eficiente (lz4, zstd).
  • Repositórios montáveis como sistemas de arquivos.
  • Suporta chaves de criptografia offline.
  • Apenas Linux/BSD (não há suporte nativo para Windows).
  • Não suporta Object Lock.
  • Requer FUSE para montar repositórios.
 Empresas com infraestrutura Linux pura. Bom para backups de máquinas virtuais (QEMU/KVM).
Duplicacy
  • GUI disponível (Duplicacy Web Edition).
  • Suporta múltiplos backends (S3, B2, SFTP, local).
  • Deduplicação entre repositórios.
  • Versão gratuita limitada a 100 GB.
  • Criptografia apenas na versão paga.
  • Menos maduro que Restic/Borg.
 PMEs com equipes Windows que precisam de uma solução "apontar e clicar".

Recomendação prática: Para PMEs com menos de 50 funcionários, combinamos Restic (para servidores) com Duplicacy Web Edition (para estações de trabalho). A equipe da CyberShield verificou que essa configuração cumpre com 3-2-1-1-0 em 95% dos casos auditados na América Latina, com um custo mensal inferior a 50 USD (incluindo armazenamento no Wasabi).

Imutabilidade real: Object Lock vs. chaves offline

A imutabilidade é o pilar da 3-2-1-1-0, mas nem todas as implementações são iguais. Dois enfoques com trade-offs claros:

  1. Object Lock (S3/Wasabi):
    • Vantagens:
      • Configurável por objeto (ex.: backups diários com 30 dias de retenção, mensais com 1 ano).
      • Integração nativa com ferramentas como Restic (restic init --repository-version 2).
      • Atende a regulamentações como SEC 17a-4(f) ou FINRA.
    • Riscos:
      • Se as credenciais da AWS/Wasabi forem comprometidas, um atacante pode apagar o bucket completo (Object Lock protege apenas objetos existentes, não o bucket).
      • Custo: Wasabi cobra ~6 USD/TB/mês por Object Lock (vs. ~5 USD/TB/mês sem ele).
      • Falsos positivos: Já vimos casos em que PMEs configuram Object Lock, mas esquecem de ativar o modo "compliance" (apenas "governance" permite apagar com permissões especiais).
  2. Chaves offline (Restic/Borg):
    • Vantagens:
      • Imutabilidade física: A chave de criptografia só existe em um dispositivo desconectado (ex.: YubiKey ou papel).
      • Zero dependência de provedores de nuvem.
      • Custo adicional zero.
    • Riscos:
      • Perda da chave = perda de dados. Requer um processo de backup da chave (ex.: em um cofre físico).
      • Não escala para ambientes com muitos repositórios.
      • Exige disciplina operacional (ex.: conectar a YubiKey apenas durante o backup).

Nossa posição: Para PMEs com menos de 10 TB de dados críticos, as chaves offline são a opção mais segura e econômica. Object Lock é melhor para empresas com requisitos regulatórios ou equipes grandes. Em ambos os casos, a imutabilidade deve ser verificada mensalmente com testes de exclusão simulada (ex.: tentar apagar um backup com credenciais de administrador).

O erro que ninguém menciona: backups de sistemas vs. backups de dados

A maioria das PMEs faz backup de arquivos (documentos, bancos de dados), mas não de sistemas completos. Isso gera dois problemas:

  1. Tempo de recuperação (RTO) inflado:

    Restaurar um servidor não é apenas copiar arquivos. Requer:

    • Reinstalar o sistema operacional.
    • Configurar redes, permissões e dependências.
    • Reinstalar aplicações e patches.

    Em um caso documentado na Argentina (2023), uma PME levou 4 dias para restaurar seu ERP porque os backups incluíam apenas o banco de dados, não o servidor de aplicações nem a configuração de rede. O RTO real foi 10 vezes maior que o estimado.

  2. Inconsistências em ambientes virtualizados:

    Se você usa máquinas virtuais (VMware, Hyper-V, Proxmox), fazer backup apenas dos arquivos dentro da VM pode gerar corrupção. Exemplo: Um backup de um banco de dados PostgreSQL feito enquanto a VM está ligada pode estar em um estado inconsistente. Soluções:

    • Usar ferramentas que façam backup da VM completa (ex.: qemu-img para QEMU/KVM).
    • Criar snapshots consistentes com o sistema de arquivos (ex.: fsfreeze no Linux).
    • Para bancos de dados, usar ferramentas nativas de backup (pg_dump, mysqldump) além do backup da VM.

Recomendação: Implementar uma estratégia de "backups em camadas":

  1. Camada 1: Backups de arquivos (documentos, bancos de dados) com Restic/Borg.
  2. Camada 2: Backups de sistemas completos (VMs ou discos físicos) com ferramentas como dd, Veeam Agent ou Proxmox Backup Server.
  3. Camada 3: Backups de configuração (scripts, playbooks do Ansible, manifestos do Kubernetes) em um repositório Git privado com proteção contra exclusão (ex.: GitHub com branch protection).

Essa estratégia cumpre com 3-2-1-1-0 e reduz o RTO para menos de 4 horas em 80% dos casos auditados pela CyberShield na América Latina.

O custo oculto: armazenamento vs. recuperação

As PMEs costumam otimizar o custo de armazenamento, mas ignoram o custo de recuperação. Dois exemplos reais:

Lição: O custo de armazenamento é irrelevante comparado ao custo de não poder recuperar. Recomendações para PMEs:

  1. Priorizar provedores com download gratuito:
    • Wasabi: Download ilimitado e gratuito.
    • Backblaze B2: Cobram por download, mas têm um plano "B2 Reserve" com downloads incluídos.
    • Evitar AWS S3: Cobram 0,09 USD/GB baixado (pode ser proibitivo para PMEs).
  2. Calcular o "Custo Total de Recuperação" (CTR):

    Fórmula:

    CTR = (Custo de armazenamento mensal × 12) + (Custo de download × probabilidade anual de incidente) + (Custo de tempo de engenharia)

    Exemplo para uma PME com 5 TB:

    • Wasabi: (6 × 5 × 12) + (0 × 0,2) + 500 = 860 USD/ano.
    • Backblaze B2: (5 × 5 × 12) + (200 × 0,2) + 500 = 840 USD/ano.

    A diferença é mínima, mas o Wasabi oferece melhor RTO.

  3. Negociar com provedores de hospedagem:

    Muitos provedores de hospedagem (ex.: DigitalOcean, Linode) oferecem "snapshots" gratuitos ou baratos. Estes não substituem os backups (porque estão no mesmo datacenter), mas podem reduzir o RTO para restaurações rápidas.

Conclusão: 3-2-1-1-0 como mínimo viável, não como teto

A regra 3-2-1-1-0 não é um padrão teórico: é o mínimo viável para que uma PME sobreviva a um ataque de ransomware. Mas mesmo essa regra tem limitações. Na CyberShield, identificamos três tendências que as empresas deveriam monitorar:

  1. Backups "fora de banda":

    Os atacantes já estão buscando formas de comprometer os sistemas de backup antes de criptografar os dados primários. A próxima evolução é isolar completamente os backups do restante da rede. Exemplos:

    • Usar um Raspberry Pi dedicado apenas para backups, desconectado da rede, exceto durante o processo.
    • Implementar um "air gap" físico com um disco rígido que se conecta manualmente uma vez por dia.
  2. Backups em blockchain (sim, a sério):

    Projetos como Arweave ou Filecoin oferecem armazenamento permanente e imutável em redes descentralizadas. O custo é alto (~10 USD/TB/mês), mas para dados críticos (ex.: registros médicos, contratos legais), pode ser uma opção. Testamos Arweave com Restic e funciona, mas a latência de escrita é de ~10 minutos (não é viável para backups frequentes).

  3. Automação de testes de restauração:

    O "0" em 3-2-1-1-0 (zero erros de restauração) é o elo mais fraco. Ferramentas como restic-check ou borg check verificam a integridade dos backups, mas não testam a restauração completa. Estamos desenvolvendo um script open-source para automatizar testes de restauração em ambientes com Restic/Borg, que publicaremos no repositório da CyberShield.

A resiliência não é um produto que se compra, mas um processo que se constrói. A regra 3-2-1-1-0 é um bom ponto de partida, mas as PMEs devem tratá-la como um piso, não como um teto. Em um ambiente onde os atacantes inovam constantemente, a única defesa real é assumir que o comprometimento é inevitável e se preparar para se recuperar mais rápido que o adversário. A equipe da CyberShield opera cibersegurança 24/7 para PMEs da América Latina com uma stack própria que inclui monitoramento de CVEs em tempo real e resposta 24/7, mas mesmo com essas ferramentas, o backup imutável continua sendo a última linha de defesa.

Fontes

  1. NIST Special Publication 1800-25 (2022) — Data Integrity: Recovering from Ransomware and Other Destructive Events. https://csrc.nist.gov/publications/detail/sp/1800-25/final
  2. Veeam (2023). 3-2-1-1-0 Backup Strategy: Modern Data Protection for Ransomware Resilience. Whitepaper. https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html
  3. Restic Documentation (2024). Repository Format. https://restic.readthedocs.io/en/latest/100_references.html#repository-format
  4. BorgBackup Documentation (2024). Security. https://borgbackup.readthedocs.io/en/stable/internals/security.html
  5. OEA/CICTE (2023). Relatório de Cibersegurança na América Latina e Caribe. https://www.oas.org/es/sms/cicte/docs/Informe-Ciberseguridad-2023.pdf
  6. CERT-CR (2022). Relatório de Incidentes Cibernéticos na Costa Rica. https://www.cert.cr/informes