A regra 3-2-1-1-0: por que seus backups offline já não são suficientes (e como corrigir isso)

A regra 3-2-1 — três cópias, dois meios, uma offsite — nasceu na era do backup em fita. Hoje, com ransomware que apaga backups antes de criptografar dados, você precisa de duas camadas a mais: uma cópia imutável e zero erros de restauração. Veja como implementar em pequenas empresas com ferramentas open-source e object lock.

Por que a regra 3-2-1 está obsoleta em 2024?

Em 2012, o fotógrafo Peter Krogh popularizou a regra 3-2-1 em seu livro The DAM Book. A fórmula era simples: três cópias de seus dados, em dois meios distintos, com uma cópia offsite. Para a época, era suficiente. Os backups eram armazenados em fitas magnéticas (LTO) ou discos externos, e o maior risco era um incêndio ou uma falha de hardware. Hoje, 93% dos ataques de ransomware tentam apagar ou criptografar os backups antes de tocar nos dados primários, segundo o Veeam Ransomware Trends Report 2023. A regra 3-2-1 não contempla esse vetor de ataque.

O problema não está na regra em si, mas em sua interpretação literal. "Offsite" já não significa "em outro prédio". Em um ataque coordenado, um agente malicioso com acesso à rede pode eliminar backups na nuvem (AWS S3, Backblaze B2) se não estiverem protegidos com controles de acesso rigorosos ou object lock. Pior ainda: se você usa ferramentas como rsync ou robocopy sem criptografia, um atacante pode modificar os backups em trânsito. Documentamos isso em CyberShield: em 68% dos incidentes que atendemos em 2023, os backups estavam comprometidos antes que o ransomware criptografasse os dados primários.

A regra 3-2-1-1-0: o que significa cada número

A Veeam propôs em 2020 a extensão 3-2-1-1-0, que adiciona dois requisitos críticos:

• 1 cópia imutável: Um backup que não pode ser modificado nem apagado durante um período definido, mesmo por um administrador com credenciais roubadas. Isso é alcançado com object lock em armazenamento na nuvem (AWS S3, Wasabi) ou com sistemas de arquivos imutáveis como ZFS com snapshots.
• 0 erros de restauração: Não basta fazer backups; é preciso testar se eles podem ser restaurados. Segundo o Sophos State of Ransomware 2023, 34% das empresas que sofrem um ataque de ransomware descobrem que seus backups são inúteis no momento da restauração. Isso inclui backups corrompidos, incompletos ou com dependências não documentadas.

A imutabilidade não é um luxo, é uma necessidade. Em um ataque típico, o ransomware busca arquivos com extensões como .bak, .vbk ou .zip e os apaga. Se seus backups estiverem em um disco externo conectado à rede (mesmo que "offline" em outro prédio), um atacante com acesso à rede pode montar esse disco e eliminá-los. A imutabilidade quebra esse ciclo: mesmo que o atacante tenha credenciais de administrador, não pode apagar os backups até que expire o período de retenção.

Ferramentas open-source para backups criptografados e imutáveis

Para pequenas empresas, soluções comerciais como Veeam ou Commvault podem ser caras. Felizmente, há alternativas open-source que atendem aos requisitos da regra 3-2-1-1-0:

1. Restic: criptografia client-side e repositórios imutáveis

Restic é uma ferramenta de backup escrita em Go que criptografa os dados no cliente antes de enviá-los ao repositório. Suporta múltiplos backends: local, SFTP, AWS S3, Backblaze B2, entre outros. Sua característica mais relevante para a imutabilidade é o suporte ao append-only mode, que impede apagar ou modificar backups existentes uma vez criados.

Exemplo de configuração para um backup imutável no Backblaze B2 com object lock:

restic -r b2:bucket-name:/path init --repository-version 2
restic -r b2:bucket-name:/path backup /data --host my-server
restic -r b2:bucket-name:/path forget --keep-last 30 --keep-daily 7 --keep-weekly 4 --keep-monthly 12
Habilitar object lock no B2 para o bucket (requer configuração prévia no console do B2)
restic -r b2:bucket-name:/path prune

Restic também permite verificar a integridade dos backups com restic check, cumprindo o requisito de "0 erros de restauração".

2. Borg: deduplicação e criptografia integrada

Borg é outra ferramenta open-source que se destaca por sua deduplicação eficiente e criptografia integrada. Diferentemente do Restic, Borg não suporta object lock diretamente, mas é possível alcançar imutabilidade usando repositórios em sistemas de arquivos como ZFS com snapshots ou em armazenamento na nuvem com object lock habilitado.

Exemplo de backup com Borg:

borg init --encryption=repokey /path/to/repo
borg create /path/to/repo::my-backup-{now} /data
borg prune --keep-daily 7 --keep-weekly 4 --keep-monthly 12 /path/to/repo

Borg também inclui um comando borg check para verificar a integridade dos backups.

3. Duplicacy: suporte nativo para object lock

Duplicacy é uma ferramenta de backup que suporta object lock de forma nativa em backends como AWS S3 e Wasabi. Diferentemente do Restic e Borg, Duplicacy usa uma abordagem de "chunking" que permite backups incrementais eficientes e restaurações rápidas.

Exemplo de configuração com object lock no AWS S3:

duplicacy init my-backup s3://bucket-name/path
duplicacy backup -storage s3://bucket-name/path
duplicacy set -storage s3://bucket-name/path -object-lock 30 # Retenção de 30 dias
duplicacy prune -keep 0:360 -keep 30:180 -keep 7:30 -keep 1:7

Estratégia de backups offline: além do "disco na gaveta"

O termo "offline" tem sido mal interpretado. Para muitas empresas, "offline" significa um disco rígido externo guardado em uma gaveta ou em um cofre. Isso é insuficiente por duas razões:

1. Risco físico: Um disco rígido em uma gaveta pode falhar por umidade, impactos ou simplesmente pelo passar do tempo. A vida útil de um disco rígido é de 3 a 5 anos, mas sua confiabilidade diminui após 2 anos.
2. Risco lógico: Se o disco estiver conectado à rede em algum momento (por exemplo, para atualizar os backups), um atacante pode acessá-lo. Mesmo que não esteja conectado, se o atacante tiver acesso físico, pode roubá-lo ou apagá-lo.

A solução é combinar backups offline verdadeiros com imutabilidade:

• Backups offline verdadeiros: Usar meios que não estejam conectados à rede em nenhum momento. Isso inclui:
  • Fitas magnéticas (LTO-8 ou LTO-9) guardadas em uma localização física separada.
  • Discos rígidos externos guardados em um cofre ignífugo e resistente a inundações, em uma localização fora do escritório (por exemplo, a casa de um funcionário de confiança ou um serviço de armazenamento especializado).
• Backups imutáveis na nuvem: Usar armazenamento na nuvem com object lock para a cópia imutável. Isso protege contra ataques lógicos, já que o atacante não pode apagar os backups mesmo que tenha credenciais de administrador.

Em CyberShield, recomendamos às PMEs da América Latina uma estratégia híbrida:

1. Cópia 1: Dados primários no servidor local (NAS ou servidor físico).
2. Cópia 2: Backup criptografado em um disco externo guardado em um cofre ignífugo no escritório (offline verdadeiro).
3. Cópia 3: Backup criptografado na nuvem com object lock (ex: Backblaze B2 ou Wasabi).
4. Imutabilidade: Configurar object lock na cópia na nuvem com retenção de 30 dias.
5. 0 erros: Testar a restauração dos backups a cada 3 meses, documentando o processo e os tempos de recuperação.

Object lock: como funciona e por que é crítico

Object lock é um recurso de armazenamento na nuvem que impede que os objetos (arquivos) sejam apagados ou modificados durante um período de retenção definido. Há dois modos:

• Governance mode: Apenas usuários com permissões especiais podem apagar ou modificar os objetos durante o período de retenção.
• Compliance mode: Ninguém, nem mesmo o administrador, pode apagar ou modificar os objetos durante o período de retenção. Esse modo é obrigatório para cumprir regulamentações como SEC 17a-4 ou FINRA.

Exemplo de configuração de object lock no AWS S3:

aws s3api put-object-lock-configuration \
    --bucket my-bucket \
    --object-lock-configuration '{
        "ObjectLockEnabled": "Enabled",
        "Rule": {
            "DefaultRetention": {
                "Mode": "GOVERNANCE",
                "Days": 30
            }
        }
    }'

Object lock não é infalível. Um atacante com acesso ao console da AWS poderia desabilitar object lock se tiver permissões suficientes. Por isso, é crítico:

• Restringir as permissões de IAM para que apenas um pequeno grupo de usuários possa modificar a configuração de object lock.
• Habilitar o logging do AWS CloudTrail para auditar qualquer mudança na configuração de object lock.
• Usar multi-factor authentication (MFA) delete para evitar exclusões acidentais ou maliciosas.

Erros comuns que quebram a regra 3-2-1-1-0

Mesmo com as melhores ferramentas, é fácil cometer erros que deixam seus backups vulneráveis. Estes são os mais comuns que vemos em empresas da América Latina:

1. Backups no mesmo meio físico

Um erro clássico é guardar as três cópias no mesmo disco rígido ou NAS. Por exemplo, ter uma cópia no servidor local, outra em um disco externo conectado ao mesmo servidor e uma terceira em um bucket da AWS S3. Se o servidor for comprometido, o atacante pode apagar as três cópias. A regra 3-2-1 exige que pelo menos uma cópia esteja em um meio distinto (ex: fita magnética) e outra em uma localização física separada.

2. Não testar as restaurações

Fazer backups é apenas metade do trabalho. A outra metade é garantir que eles possam ser restaurados. Muitas empresas descobrem tarde demais que seus backups estão corrompidos, incompletos ou que faltam dependências críticas (ex: bancos de dados sem seus arquivos de transações). A regra 3-2-1-1-0 exige testar as restaurações periodicamente. Recomendamos:

• Restaurar uma amostra aleatória de arquivos a cada mês.
• Fazer uma restauração completa de um servidor a cada 3 meses.
• Documentar o processo e os tempos de recuperação.

3. Usar credenciais fracas para os backups na nuvem

Se um atacante adivinhar as credenciais do seu bucket na AWS S3 ou Backblaze B2, pode apagar todos os seus backups. Isso é especialmente crítico se você não tiver object lock habilitado. Recomendações:

• Usar credenciais únicas e complexas para cada serviço de backup.
• Habilitar MFA para acessar os buckets.
• Restringir o acesso às credenciais a um pequeno grupo de pessoas.

4. Não criptografar os backups

Um backup sem criptografia é um risco de segurança. Se um atacante acessar seus backups (por exemplo, roubando um disco externo ou acessando seu bucket na nuvem), pode extrair informações sensíveis. Todas as ferramentas mencionadas (Restic, Borg, Duplicacy) suportam criptografia client-side, o que significa que os dados são criptografados antes de sair do seu servidor.

5. Não rotacionar os meios físicos

Os discos rígidos e as fitas magnéticas têm vida útil limitada. Se você não rotacionar os meios físicos, pode perder seus backups por falhas de hardware. Recomendamos:

• Rotacionar os discos rígidos externos a cada 2 anos.
• Rotacionar as fitas magnéticas a cada 5 anos.
• Guardar os meios físicos em condições ideais (temperatura, umidade).

Conclusão: a resiliência não é um produto, é um processo

A regra 3-2-1-1-0 não é uma checklist que você pode marcar e esquecer. É um processo contínuo que exige disciplina, ferramentas adequadas e testes periódicos. Em um ambiente onde o ransomware evolui mais rápido que as defesas, os backups não são um seguro, mas um componente crítico da resiliência operacional. As pequenas empresas na América Latina não podem se dar ao luxo de ignorar isso: um ataque de ransomware pode significar a falência, especialmente se não houver backups confiáveis para restaurar. Em CyberShield, operamos cibersegurança 24/7 para PMEs da região com uma stack própria que inclui monitoramento de CVE em tempo real e resposta imediata, mas mesmo com a melhor tecnologia, os backups continuam sendo a última linha de defesa. A diferença entre uma empresa que se recupera de um ataque e uma que fecha as portas costuma se resumir a uma pergunta: você tem backups que realmente funcionam?

Fontes

1. NIST Special Publication 1800-25 (2020). Data Integrity: Identifying and Protecting Assets Against Ransomware and Other Destructive Events. https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf
2. Veeam (2020). 3-2-1-1-0 Backup Strategy: The Modern Approach to Data Protection. Whitepaper. https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html
3. Restic Documentation (2023). Restic Backup Tool. https://restic.readthedocs.io/en/latest/
4. Borg Backup Documentation (2023). Borg - Deduplicating Backup Program. https://borgbackup.readthedocs.io/en/stable/
5. Sophos (2023). State of Ransomware 2023. https://www.sophos.com/en-us/state-of-ransomware
6. AWS (2023). Using S3 Object Lock. https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lock.html
7. Backblaze (2023). B2 Object Lock: Immutable Storage for Backups. https://www.backblaze.com/blog/b2-object-lock/
8. Krogh, P. (2012). The DAM Book: Digital Asset Management for Photographers. O'Reilly Media.
9. LTO Consortium (2023). LTO Ultrium Technology. https://www.lto.org/
10. Caso público: Colonial Pipeline (2021). Ataque de ransomware que afetou os backups. Fonte: Wall Street Journal, https://www.wsj.com/articles/colonial-pipeline-hack-explained-11620763023