A Regra de Fibonacci da Segurança de Backup: ampliando o 3-2-1-1-0 para a segurança de backup moderna

Por que estratégias de backup maduras estão falhando em 2026

Durante anos, a regra de backup 3-2-1 foi a base da proteção de dados. O fotógrafo Peter Krogh diz ter cunhado o termo enquanto escrevia a primeira edição de The DAM Book, e o seu guia de backup para o projeto dpBestflow da ASMP a apresenta assim: três cópias de todo arquivo importante, em dois tipos de mídia diferentes, com uma cópia fora do local (offsite). A fórmula se espalhou muito além da fotografia. O documento da CISA sobre opções de backup de dados a repete para dados pessoais e empresariais.

Funcionou. Até deixar de funcionar.

O 2025 Data Breach Investigations Report da Verizon encontrou ransomware em 44% das violações que analisou, contra 32% na edição anterior. Essa edição cobre incidentes de novembro de 2023 a outubro de 2024; a edição de 2026, que cobre de novembro de 2024 a outubro de 2025, coloca a participação em 48%. A equipe de pesquisa da GuidePoint Security, que acompanha as vítimas publicadas pelos grupos de ransomware, registrou um aumento de 58% no número de vítimas de ransomware em 2025 em relação ao ano anterior, o ano mais ativo que ela já acompanhou. Mais relevante para os responsáveis por risco corporativo: nos atendimentos de resposta a incidentes da Mandiant em 2025, o Google Threat Intelligence Group observou roubo de dados, confirmado ou suspeito, em aproximadamente 77% das intrusões de ransomware, contra aproximadamente 57% em 2024. Quando os dados já foram roubados, um restore impecável traz os sistemas de volta, mas não resolve a violação.

A regra 3-2-1 foi criada para falhas de hardware, interrupções regionais e exclusões acidentais. Não foi criada para atacantes que visam especificamente os repositórios de backup, nem para pessoas internas com credenciais administrativas válidas. Os atacantes sabem que destruir os backups tira da vítima a alternativa ao pagamento. O mesmo relatório do Google observa que os operadores de ransomware "often disabled or deleted backups to inhibit and/or limit recovery options" (frequentemente desativavam ou apagavam backups para impedir e/ou limitar as opções de recuperação).

É por isso que a regra foi ampliada. A Veeam descreve a sua própria extensão, 3-2-1-1-0, como o acréscimo de uma cópia imutável e de zero erros de recuperação. Na BackupSec, propomos um passo além, que chamamos de Regra de Fibonacci da Segurança de Backup e escrevemos como 5-3-2-1-1-0. É o nosso framework, não um padrão do setor. Ela se lê como a sequência de Fibonacci ao contrário e acrescenta um sexto elemento: cinco princípios fundamentais de segurança que precisam sustentar cada camada abaixo deles.

Para organizações que operam ambientes de backup maduros, este artigo redefine o que "proteção de dados abrangente" deveria significar em 2026.

De 3-2-1 a 3-2-1-1-0: uma recapitulação rápida

Antes de apresentar a Regra de Fibonacci, vale reconhecer como chegamos até aqui.

A regra 3-2-1 original exigia três cópias dos dados em dois tipos de mídia diferentes, com uma armazenada fora do local. O foco era a redundância, partindo do pressuposto de que nenhum evento físico isolado conseguiria destruir as três cópias ao mesmo tempo.

A regra 3-2-1-1-0, extensão da original criada pela Veeam e hoje amplamente usada, acrescentou dois refinamentos:

• Uma cópia imutável ou com air gap que não pode ser modificada nem apagada, nem mesmo por um atacante com credenciais administrativas.
• Zero erros na verificação dos backups, para que se saiba que cada backup pode ser restaurado, e não apenas que ele existe.

Essa evolução fechou duas lacunas importantes: o ransomware que ataca os backups e a falha silenciosa de backups que nunca são testados até o desastre acontecer. Mas a regra não tenta definir a arquitetura de segurança completa em torno dessas cópias: separação de identidades, acesso privilegiado, segmentação, monitoramento contínuo e contenção do raio de impacto.

É essa lacuna que a Regra de Fibonacci da Segurança de Backup foi criada para fechar.

Por que Fibonacci? A lógica por trás dos números

A sequência de Fibonacci (0, 1, 1, 2, 3, 5, 8, 13...) é um dos padrões mais elegantes da matemática: cada número é a soma dos dois anteriores. Lendo o nosso framework ao contrário (5, 3, 2, 1, 1, 0), vale a mesma lógica cumulativa: cada camada de proteção se apoia nas fundações abaixo dela.

• 5 princípios fundamentais de segurança. Cinco princípios que regem como o backup é arquitetado.
• 3 cópias dos dados. Pelo menos três cópias de cada conjunto de dados crítico.
• 2 tipos diferentes de mídia ou de storage/plataforma. Armazenadas em duas mídias, plataformas de storage ou pilhas tecnológicas diferentes.
• 1 cópia fora do local. Uma cópia em um local geograficamente separado.
• 1 cópia adicional imutável, isolada ou protegida de outra forma. Mais uma cópia protegida contra modificação ou destruição.
• 0 backups não verificados ou erros de recuperação pendentes. Nenhum backup sem verificação, nenhum erro de recuperação em aberto.

A regra 3-2-1-1-0 original respondia à pergunta operacional "Quantas cópias, onde e em que estado?" O "5" que acrescentamos responde a uma pergunta arquitetural mais fundamental: "O que significa, de fato, um backup ser seguro?"

Sem esses cinco princípios, o resto da cadeia é oco. Um backup que existe em três cópias, em duas mídias, em estado imutável, mas que é governado por controles de acesso inadequados ou que pode ser alcançado a partir de uma estação de administração comprometida, não está protegido. É a documentação de uma exposição.

O "5": cinco princípios fundamentais da segurança de backup

Esses cinco princípios devem orientar cada decisão de arquitetura no seu ambiente de backup, da escolha da plataforma à política de retenção e à governança de acesso.

1. Arquitetura ciber-resiliente desde a concepção

Segurança de backup não se adapta depois. Ela precisa ser uma restrição de projeto desde o primeiro dia.

Uma arquitetura de backup ciber-resiliente trata cada componente (o catálogo, a camada de storage, o plano de gerenciamento, o ambiente de recuperação) como um alvo potencial. Ela pressupõe a violação, planeja para o comprometimento e garante que nenhuma falha isolada, seja técnica, humana ou adversarial, possa se propagar até a perda total da capacidade de recuperação.

Na prática, isso significa:

• Defesa em profundidade: vários controles independentes protegem cada camada, de modo que a falha de um não expõe o sistema.
• Contenção do raio de impacto: o comprometimento do ambiente de produção não pode se propagar para a infraestrutura de backup, e o comprometimento de uma camada de backup não pode se propagar para as outras.
• Projeto orientado à recuperação: as arquiteturas são avaliadas não só pela qualidade com que fazem o backup dos dados, mas pela confiabilidade com que conseguem restaurá-los em condições hostis: com o DNS fora do ar, os provedores de identidade comprometidos ou o site principal inacessível.
• Criptografia como elemento básico da arquitetura, e não como recurso: todo backup, em qualquer estado, deve ser protegido com criptografia forte e padrão de mercado em repouso e em trânsito, com as chaves de criptografia governadas de forma independente da infraestrutura de backup sempre que possível, idealmente em um HSM dedicado ou em um serviço de gerenciamento de chaves com responsabilidade administrativa separada. Se as suas chaves ficam junto com os seus dados, você não tem criptografia; tem ofuscação. Para empresas com fluxos de dados entre países, a soberania das chaves (quem pode obrigar a divulgação, sob qual jurisdição e em que prazo) passa a ser uma decisão de projeto, e não um problema de resposta a incidentes.

A segurança acoplada depois a um sistema de backup projetado para um cenário de ameaças mais antigo costuma mostrar suas lacunas no meio de um incidente, quando a própria arquitetura se revela o ponto fraco. A resiliência precisa ser projetada desde o início.

2. Acesso Zero Trust e autenticação forte

O princípio é simples: nunca confie, sempre verifique. Toda solicitação para ler, gravar ou modificar um backup deve ser autenticada e autorizada no momento da solicitação, independentemente da origem na rede.

Na prática, isso exige:

• Autenticação multifator (MFA) para toda identidade administrativa que acesse a infraestrutura de backup, de preferência com métodos resistentes a phishing, como tokens de hardware.
• Controle de acesso baseado em funções (RBAC) que aplique o princípio do menor privilégio em escopo granular.
• Identidades administrativas separadas para os sistemas de produção e de backup. Um administrador de domínio comprometido não deveria ter acesso à sua última linha de defesa.
• Gerenciamento de acesso privilegiado (PAM) com elevação just-in-time, gravação de sessões e fluxos de aprovação para operações sensíveis, como mudanças na política de retenção.

Na pesquisa State of Ransomware 2025 da Sophos, com 3.400 organizações atingidas por ransomware, as vítimas apontaram credenciais comprometidas como causa raiz de 23% dos ataques, a segunda causa raiz técnica mais comum depois das vulnerabilidades exploradas (32%). Se o seu ambiente de backup confia na mesma infraestrutura de identidade que protege a produção, você tem um ponto único de falha disfarçado de defesa em camadas.

3. Imutabilidade e storage WORM

A imutabilidade, a propriedade de que os dados não podem ser alterados nem apagados durante um período de retenção definido depois de gravados, passou de "boa prática" a "inegociável". Seja implementada por Object Lock em storage na nuvem, por mídia Write Once Read Many (WORM) ou por bloqueios de retenção impostos por hardware, a imutabilidade é uma das defesas arquiteturais mais eficazes contra atacantes que caçam especificamente os repositórios de backup.

Para empresas sujeitas a regras de guarda de registros, a imutabilidade também pode apoiar a conformidade. A SEC Rule 17a-4 permite que as corretoras (broker-dealers) mantenham registros eletrônicos com uma trilha de auditoria completa e com carimbo de tempo ou "in a non-rewriteable, non-erasable format" (em formato que não pode ser regravado nem apagado). A HIPAA Security Rule exige um plano de backup de dados que crie e mantenha "retrievable exact copies" (cópias exatas recuperáveis) das informações de saúde protegidas em formato eletrônico. A superfície de controle que protege você contra ransomware muitas vezes é a mesma sobre a qual o seu auditor pergunta.

A CISA é mais cautelosa que a maioria dos fornecedores. O seu #StopRansomware Guide orienta as organizações a "maintain offline, encrypted backups of critical data" (manter backups offline e criptografados dos dados críticos) e a testar regularmente a disponibilidade e a integridade deles. O guia menciona o storage imutável de provedores de nuvem apenas com um alerta: ele "does not meet compliance criteria for certain regulations" (não atende aos critérios de conformidade de certas regulamentações), e erros de configuração podem gerar custos significativos. A imutabilidade mantém os backups intactos diante de um atacante que já tem credenciais administrativas. Ela não substitui uma cópia offline nem um restore testado.

4. Verificação contínua e testes de recuperação

Um backup que você não testou não é um backup. É uma hipótese.

O "0" do 3-2-1-1-0 exige zero erros, mas a única forma de comprovar isso é testar continuamente. Programas maduros implementam verificações automáticas de integridade, exercícios periódicos de restore completo, ambientes de recuperação isolados para validação e exercícios de mesa (tabletop) estruturados que colocam à prova as camadas humana e de processo com o mesmo rigor que a técnica.

A recuperação está ficando mais rápida. Na mesma pesquisa da Sophos, 53% das vítimas de ransomware se recuperaram totalmente em até uma semana, contra 35% em 2024, e 97% haviam se recuperado totalmente em até três meses. A Sophos sugere que a melhora pode refletir investimentos em preparação para incidentes e prontidão para recuperação. A pesquisa não isola o efeito de planos testados, mas a recomendação da própria Sophos é fazer backups de qualidade e praticar regularmente o restore a partir deles.

A lição para os líderes de risco: os testes são o que separa as organizações que têm backups das organizações que conseguem se recuperar.

5. Isolamento e segmentação de rede

A infraestrutura de backup deve ser fortemente segmentada da produção e, sempre que possível, não deve depender das mesmas fronteiras de confiança administrativa que protegem os sistemas de produção.

As boas práticas atuais combinam segmentação lógica (VLANs separadas, sub-redes dedicadas, regras de firewall rígidas, microssegmentação) com arquiteturas com air gap ou quase air gap para pelo menos uma cópia de cada backup. Imutabilidade na nuvem com provedores de identidade separados, rotação de fitas offline, ambientes de recuperação dedicados e isolamento de tenants em infraestrutura compartilhada servem todos ao mesmo objetivo arquitetural: garantir que o raio de impacto de qualquer comprometimento isolado não alcance a camada de recuperação.

Se um atacante no seu controlador de domínio consegue chegar ao seu repositório de backup com as mesmas credenciais, o seu backup faz parte da superfície de ataque, e não está separado dela.

O "3-2-1": a redundância que continua importando

Com os cinco princípios como base, a camada clássica 3-2-1 continua essencial.

• 3 cópias de cada conjunto de dados crítico: os seus dados de produção mais pelo menos dois backups.
• 2 mídias ou plataformas de storage diferentes: disco local e nuvem, ou object storage on-premises e um provedor de nuvem separado. O objetivo é garantir que uma única falha tecnológica, uma indisponibilidade de fornecedor ou uma classe de ataque não consiga destruir todas as cópias ao mesmo tempo.
• 1 cópia fora do local: geograficamente separada do site principal, de preferência em um domínio de ameaça diferente e, quando fizer sentido, em uma jurisdição regulatória diferente.

O que mudou desde que a regra foi formulada é a interpretação. Duas regiões de nuvem do mesmo provedor não constituem "duas mídias diferentes". Um volume de backup em uma SAN ao lado do seu storage de produção não está, na prática, "fora do local". A modelagem de ameaças corporativa moderna exige uma leitura mais rigorosa de cada requisito.

O "1-1": fora do local e imutável ou com air gap

Os dois "1" tratam de domínios de falha diferentes.

O primeiro exige que uma cópia seja armazenada fora do local, geograficamente separada do ambiente principal, para que um incidente no site, uma falha de infraestrutura ou um desastre físico não elimine todas as opções de recuperação de uma vez.

O segundo exige que pelo menos uma cópia adicional seja protegida contra modificação ou destruição por meio de imutabilidade, air gap ou um mecanismo de isolamento equivalente. O propósito é outro: a separação geográfica protege contra a falha de um local, enquanto a imutabilidade ou o isolamento protegem contra um atacante que obteve acesso administrativo.

Na implementação, esses requisitos podem se sobrepor. Uma cópia fora do local também pode ser imutável, e ambientes maduros podem manter tanto uma camada de recuperação imutável quanto uma cópia mais profunda, offline ou com air gap. O que importa é não tratar a geografia, por si só, como isolamento de segurança.

Essa distinção também explica por que a imutabilidade aparece entre os cinco princípios de segurança da Regra de Fibonacci. O "1" numérico define um requisito mínimo de proteção para uma cópia de backup; o princípio de segurança exige que a imutabilidade seja considerada em toda a arquitetura, incluindo controles de retenção, acesso administrativo, separação de identidades e o plano de gerenciamento.

O "0": tolerância zero para backups não verificados

Todo backup verificado. Todo restore testado. Toda lacuna documentada e fechada.

O "0" é a camada de disciplina operacional do framework. Ele exige rigor: checksums automáticos, validação de restore agendada, detecção de anomalias nos metadados dos jobs de backup (um salto repentino no tamanho de um job pode indicar preparação de dados por um atacante antes da criptografia), monitoramento comportamental da atividade administrativa de backup e caminhos claros de escalonamento quando a verificação falha.

O raciocínio é simples. Um atacante que se prepara para destruir os backups precisa mexer primeiro no sistema de backup, e essas mudanças aparecem nas configurações dos jobs, nos valores de retenção e nos logs de auditoria antes de qualquer restore falhar. Zero erros não é uma métrica de vaidade. É a diferença entre confiança e falsa confiança no momento em que essa distinção mais importa.

O que isso significa para os líderes de risco corporativo

Se a sua organização opera com uma estratégia de backup projetada para outro cenário de ameaças, a distância entre o que você tem e o que você precisa deixou de ser acadêmica. Considere a realidade financeira:

• A pesquisa de 2025 da Sophos colocou o pagamento mediano de resgate em US$ 1 milhão e o custo médio de recuperação, sem contar qualquer resgate, em US$ 1,53 milhão.
• O DBIR 2025 da Verizon informa que 64% das organizações vítimas de ransomware não pagaram, contra 50% dois anos antes. A Sophos, com uma amostra diferente, constatou que 49% das vítimas pagaram o resgate para recuperar seus dados. De qualquer forma, pagar deixou de ser o padrão, e uma organização que se recusa a pagar precisa de um caminho de restore que funcione.

Para empresas de setores regulados ou que administram ambientes híbridos complexos, a conta é ainda mais direta. Empresas listadas nos EUA precisam divulgar um incidente de cibersegurança relevante no Form 8-K, em geral em até quatro dias úteis depois de determinar que ele é relevante, e muitas outras jurisdições e setores impõem suas próprias obrigações de notificação. O custo de um incidente sem recuperação deixou de ser apenas operacional. Ele também é reputacional e regulatório.

Implementar a Regra de Fibonacci não exige reconstruir a infraestrutura do zero. Exige uma avaliação honesta da arquitetura, correções priorizadas com base em um conjunto claro de princípios e um compromisso de governança de tratar a segurança de backup como uma disciplina integrada, e não como um item de compra.

Onde a BackupSec entra

Na BackupSec, ajudamos as equipes a operar seus ambientes de backup Veeam de acordo com os princípios acima. Não substituímos a plataforma de backup; tornamos a segurança dela observável, orientada e testada.

• O ZeroMON monitora o Veeam Backup & Replication: saúde dos jobs, mudanças de configuração com trilha de quem/o quê/quando, um checklist do Security Analyzer, relatórios e um honeypot. Ele mostra o status de imutabilidade conforme as configurações de repositório do Veeam o informam; não verifica os bloqueios em nível de objeto no storage. Os alertas são enviados por e-mail e por notificação no próprio aplicativo. É implantado on-premises como OVA, conecta-se com uma conta somente leitura e não envia nada para a BackupSec nem para terceiros.
• O ZeroTAM oferece um consultor dedicado de segurança de backup para arquitetura, capacidade, planejamento de recuperação contra ransomware e suporte prioritário em crises.
• O ZeroPEN é um teste de penetração orientado a ameaças do Veeam Backup & Replication, do Veeam ONE e do Enterprise Manager: oito etapas de kill chain mapeadas no MITRE ATT&CK. O trabalho também inclui verificação da integridade de restore e da imutabilidade. Ele nunca apaga backups reais, nunca executa criptografia real nem interrompe serviços de produção ou de backup. Você recebe evidências prontas para auditoria e um reteste para as descobertas críticas.
• O ZeroVault é um object storage na nuvem, imutável e compatível com S3, com Object Lock, para a cópia imutável fora do local.

Fale com a BackupSec sobre a postura de segurança do seu backup →