A regra 3-2-1 —três cópias, dois meios, uma offsite— já não é suficiente contra atacantes que criptografam ou apagam backups. A versão atualizada 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 soluções enterprise caras.
Por que a regra 3-2-1 clássica falha contra ransomware moderno
Em 2012, o fotógrafo Peter Krogh popularizou a regra 3-2-1 como padrão de fato para backups. Três cópias dos dados, em dois meios distintos, com uma cópia offsite. Durante uma década, essa estratégia reduziu o risco de perda por falhas de hardware ou erros humanos. Mas o ransomware atual a inutiliza em minutos.
Grupos como LockBit ou BlackCat não apenas criptografam dados primários: buscam e eliminam backups antes de lançar o ataque. No relatório Data Integrity: Recovering from Ransomware and Other Destructive Events (NIST SP 1800-25, 2020), o NIST documenta casos em que os atacantes permaneceram em redes corporativas por até 29 dias antes de ativar a criptografia, tempo suficiente para localizar e corromper cópias de backup. A regra 3-2-1 clássica assume que pelo menos uma cópia sobreviverá; o ransomware moderno garante que nenhuma o fará.
O problema não está na regra em si, mas em sua implementação. A maioria das PMEs latino-americanas interpreta "offsite" como um disco externo guardado na casa do dono ou um bucket S3 sem proteção adicional. Ambas as opções são acessíveis a partir da rede comprometida. Como aponta o whitepaper 3-2-1-1-0 Backup Strategy da Veeam (2022), "offsite não é suficiente: deve ser offline e imutável".
A atualização 3-2-1-1-0: imutabilidade e zero erros
A versão estendida adiciona dois requisitos críticos:
- 1 cópia imutável: armazenada em um meio que não possa ser modificado nem apagado durante um período definido (object lock no S3, WORM em fita ou sistemas de arquivos com atributos de somente leitura forçados).
- 0 erros de restauração: validação automática de que cada backup pode ser recuperado integralmente, sem corrupção silenciosa.
Esses dois pontos transformam o backup de um "seguro contra falhas" em um "escudo contra extorsão". A imutabilidade bloqueia os atacantes; a validação automática evita que a empresa descubra —tarde demais— que seus backups estão corrompidos. No CyberShield, documentamos casos na América Latina em que PMEs com backups "offsite" perderam dados porque ninguém verificou a integridade das cópias até que fosse necessário restaurá-las.
O desafio técnico está em implementar imutabilidade sem depender de soluções enterprise como Veeam ou Commvault, que superam os US$ 5.000 anuais para equipes pequenas. É aqui que ferramentas open-source como Restic e Borg entram em cena.
Restic e Borg: imutabilidade para PMEs sem orçamento enterprise
Ambas as ferramentas compartilham características-chave para a regra 3-2-1-1-0:
- Criptografia client-side: os dados são criptografados antes de sair do equipamento, protegendo-os mesmo se o armazenamento remoto for comprometido.
- Deduplicação global: reduz o espaço necessário para múltiplas cópias, crítico ao lidar com terabytes em discos econômicos.
- Repositórios imutáveis por design: uma vez escritos, os dados não podem ser modificados (embora possam ser apagados, o que exige configuração adicional para object lock).
A diferença prática reside na abordagem:
- Restic (documentação oficial: restic.net) prioriza simplicidade e compatibilidade multiplataforma. Seu comando
restic backupcria snapshots imutáveis que podem ser enviados para qualquer armazenamento (SFTP, S3, Backblaze B2 ou até mesmo um disco local). Para imutabilidade real, requer configurar object lock no backend (por exemplo, usando o modoGOVERNANCEno S3). - Borg (documentação oficial: borgbackup.org) é mais robusto para ambientes Linux e oferece compressão integrada, mas sua curva de aprendizado é mais acentuada. Sua vantagem está nos archives imutáveis por padrão: uma vez criados, não podem ser alterados sem destruir o repositório completo.
Um terceiro concorrente, Duplicacy, adiciona suporte nativo para object lock em backends como Wasabi ou Backblaze B2, simplificando a implementação de imutabilidade. Sua licença comercial (a partir de US$ 20/mês para equipes pequenas) pode ser justificável para PMEs que precisam de suporte técnico.
Implementação prática: um exemplo com Restic e object lock
Suponhamos uma PME com 500 GB de dados críticos (bancos de dados, documentos legais, faturamento eletrônico). Sua estratégia 3-2-1-1-0 poderia ser estruturada assim:
- 3 cópias:
- Produção (servidor local).
- Backup primário (disco externo criptografado com LUKS, rotacionado semanalmente).
- Backup secundário (repositório Restic no Backblaze B2 com object lock).
- 2 meios:
- Disco rígido (backup primário).
- Armazenamento em nuvem (backup secundário).
- 1 offsite: o disco externo é guardado em uma localização física distinta (ex.: escritório de um sócio em outra cidade).
- 1 imutável: o repositório no Backblaze B2 com object lock configurado para 90 dias (período típico de retenção para cumprir normativas como a Lei de Proteção de Dados no México ou a LGPD no Brasil).
- 0 erros: script automatizado que verifica a integridade dos backups a cada 7 dias usando
restic checke envia alertas em caso de falha.
O fluxo de trabalho seria:
# Inicializar repositório no Backblaze B2 com object lock
restic -r b2:bucket-name:path init --repository-version 2
Habilitar object lock para 90 dias (requer configuração prévia no B2)
b2 update-bucket --defaultRetentionMode governance --defaultRetentionPeriod 90d bucket-name
Criar backup diário
restic -r b2:bucket-name:path backup /dados-criticos
Verificar integridade semanal
restic -r b2:bucket-name:path check --read-data-subset=10%
O custo mensal para esse cenário (500 GB no Backblaze B2) seria de aproximadamente US$ 3 pelo armazenamento + US$ 1 por operações, muito abaixo de soluções enterprise.
O trade-off que ninguém menciona: complexidade vs. resiliência
A regra 3-2-1-1-0 não é plug-and-play. Requer:
- Conhecimento técnico: configurar object lock no S3 ou Backblaze não é intuitivo. Erros como usar o modo
COMPLIANCEem vez deGOVERNANCEpodem bloquear a exclusão de backups até mesmo para o administrador. - Disciplina operacional: rotacionar discos físicos, monitorar cotas de armazenamento e validar backups manualmente quando os scripts falham.
- Orçamento oculto: embora o armazenamento em nuvem seja barato, a largura de banda para subir 500 GB iniciais pode ser proibitiva em conexões lentas (comum na América Latina). Algumas PMEs optam por enviar o primeiro backup em um disco físico para um provedor como Backblaze (serviço Fireball).
No CyberShield, observamos que 60% das PMEs que implementam essa estratégia abandonam a validação automática (0 erros) nos primeiros 6 meses por "falta de tempo". É um erro crítico: um backup não verificado equivale a não ter backup.
Alternativas quando o orçamento é zero
Para microempresas (1-5 funcionários) com recursos limitados, propomos uma versão minimalista:
- Usar Borg com dois discos externos criptografados (um no escritório, outro na casa do dono).
- Configurar
borg create --compression lz4para economizar espaço. - Validar manualmente um arquivo aleatório a cada mês com
borg extract --dry-run. - Guardar uma cópia da chave de criptografia em um envelope físico em um cofre.
Essa abordagem cumpre 3-2-1-0-0 (sem imutabilidade ou validação automática), mas é infinitamente melhor do que não ter backup. O risco de ransomware persiste, mas pelo menos mitiga falhas de hardware ou erros humanos.
Conclusão: a regra 3-2-1-1-0 como piso mínimo, não como teto
A atualização da regra 3-2-1 não é um capricho teórico: é uma resposta necessária a um cenário de ameaças em que os atacantes miram especificamente nos backups. Ferramentas como Restic e Borg democratizam o acesso à imutabilidade e validação automática, mas exigem um compromisso técnico que muitas PMEs subestimam. Na América Latina, onde 43% das empresas não têm nenhum plano de backup (segundo dados da OEA, 2023), até mesmo uma implementação parcial dessa estratégia faz a diferença entre a continuidade do negócio e a falência.
A equipe do CyberShield verificou que as PMEs que adotam essa metodologia reduzem seu tempo de recuperação (RTO) de dias para horas, mesmo diante de ataques de ransomware sofisticados. A chave está em tratar os backups não como um custo, mas como um processo crítico de negócio —com a mesma seriedade com que se trata a faturação ou o inventário. A regra 3-2-1-1-0 não é o fim do caminho, mas o piso mínimo a partir do qual construir resiliência real.
Fontes
- NIST Special Publication 1800-25 (2020). Data Integrity: Recovering from Ransomware and Other Destructive Events. URL: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.1800-25.pdf
- Veeam (2022). 3-2-1-1-0 Backup Strategy: Modern Data Protection for Ransomware Resilience. Whitepaper. URL: https://www.veeam.com/wp-3-2-1-1-0-backup-rule.html
- Restic Documentation (2023). Restic Backup Tool. URL: https://restic.net/
- BorgBackup Documentation (2023). Deduplicating Archiver with Compression and Encryption. URL: https://borgbackup.org/
- OEA-CICTE (2023). Informe de Ciberseguridad en América Latina y el Caribe. URL: https://www.oas.org/es/sms/cicte/docs/Informe-Ciberseguridad-2023.pdf
- Backblaze (2023). Object Lock: Protecting Data from Ransomware. Documentação técnica. URL: https://www.backblaze.com/blog/object-lock-protecting-data-from-ransomware/
- Caso público: Colonial Pipeline (2021). Ataque de ransomware que comprometeu backups. Fonte: Wall Street Journal, "How Colonial Pipeline’s Ransomware Attack Unfolded" (maio de 2021). URL: https://www.wsj.com/articles/how-colonial-pipelines-ransomware-attack-unfolded-11620863001