Quase toda empresa tem backup. Bem menos empresas sabem quanto tempo levariam para voltar a operar se o ambiente inteiro ficasse indisponível amanhã. Essa diferença entre ter cópias e conseguir se recuperar é o que separa backup de resiliência cibernética.
Ransomware deixou essa distância evidente. O atacante moderno não se contenta em cifrar servidores de produção: ele procura o console de backup, apaga snapshots e tenta cifrar os próprios repositórios antes de detonar o ataque. Quem descobre no dia do incidente que a cópia estava acessível pela mesma conta de administrador comprometida descobre tarde demais.
Backup não é resiliência
O NIST, no SP 800-160 Vol. 2 Rev. 1, define resiliência cibernética como a capacidade de antecipar, suportar, recuperar e adaptar-se a condições adversas, ataques ou comprometimentos. O backup atende bem a uma dessas quatro metas — recuperar — e só se for feito de forma a sobreviver ao próprio ataque.
Na prática, um backup que existe mas não restaura, ou restaura em três semanas quando o negócio aguenta três dias, não entrega resiliência. Restaurar uma infraestrutura complexa raramente é tão simples quanto parece: dependências entre sistemas, ordem de subida, credenciais, licenças, DNS e serviços de identidade costumam aparecer só na hora do teste — ou da crise. Por isso a pergunta certa não é "temos backup?", e sim "em quanto tempo e com quanta perda de dados voltamos a operar?".
As outras metas dependem de controles que reduzem a chance de o ataque chegar até o backup: conscientização contra phishing, atualização de sistemas e softwares, autenticação multifator e filtragem de e-mail. O guia #StopRansomware da CISA lista essas mesmas medidas como prevenção básica. Para pequenas e médias empresas sem equipe de segurança dedicada, apoiar-se em um parceiro especializado costuma ser a forma realista de manter esses controles e a vigilância sobre o ambiente.
RTO e RPO: os números que o negócio precisa definir
Duas métricas, descritas no NIST SP 800-34 Rev. 1 e usadas também na ISO 22301, traduzem essa pergunta:
- RTO (Recovery Time Objective). Tempo máximo que um sistema pode ficar indisponível antes que o impacto no negócio se torne inaceitável.
- RPO (Recovery Point Objective). Ponto no tempo até o qual os dados precisam ser recuperados — na prática, quanta perda de dados é tolerável. Um RPO de quatro horas exige cópias pelo menos a cada quatro horas.
Esses valores não são decisão da TI. Eles saem da análise de impacto no negócio (BIA), que identifica processos críticos, seus sistemas de suporte e o tempo máximo de interrupção tolerável. Sem BIA, a frequência de backup e a arquitetura de recuperação são escolhidas por hábito, não por necessidade — e é comum descobrir que o sistema de faturamento tem a mesma política de cópia que um servidor de arquivos esquecido.
3-2-1 e 3-2-1-1-0: a regra e sua atualização
A regra 3-2-1 é a referência clássica de redundância: três cópias dos dados, em dois tipos de mídia ou armazenamento diferentes, com uma cópia fora do local principal. Ela protege bem contra falha de hardware, erro humano e desastres físicos.
Contra ransomware, ela é insuficiente se todas as cópias estiverem alcançáveis pela rede e pelas mesmas credenciais. Daí a variação 3-2-1-1-0, popularizada pelo mercado:
- +1 cópia offline, isolada ou imutável. Uma cópia que o atacante não consegue alterar nem apagar, mesmo com privilégios de administrador no ambiente.
- 0 erros na verificação. Backups conferidos automaticamente e restaurações testadas, sem falhas pendentes.
O guia #StopRansomware da CISA vai na mesma direção: manter backups offline e criptografados dos dados críticos e testar regularmente sua disponibilidade e integridade em um cenário de recuperação de desastre.
Imutável, offline, isolado: o que muda na prática
Os termos são usados como sinônimos, mas não são:
- Imutável. O armazenamento impede alteração ou exclusão durante um período de retenção (por exemplo, object lock em armazenamento de objetos ou repositórios com política WORM). Proteção lógica.
- Offline (air gap). A cópia não tem conexão de rede com o ambiente de produção — fita fora do robô, mídia desconectada. Proteção física.
- Isolado (vault). Ambiente separado, com rede, identidade e administração próprias, acessado de forma controlada.
Qualquer que seja a escolha, três cuidados valem sempre: credenciais de backup separadas do domínio corporativo e protegidas com MFA; monitoramento de exclusões em massa, mudanças de retenção e falhas de job, com alertas tratados como evento de segurança; e criptografia das cópias, para que um vazamento do repositório não vire vazamento de dados.
Cópia limpa importa tanto quanto cópia disponível. Atacantes costumam permanecer no ambiente por um tempo antes de agir. Restaurar um backup que já contém o acesso do invasor reinicia o incidente. A retenção precisa cobrir janelas longas o suficiente para voltar a um ponto anterior ao comprometimento, e a restauração deve passar por verificação antes de voltar à produção.
Testar a restauração é o controle mais negligenciado
Job concluído com sucesso não é sinônimo de dado recuperável. Um programa de testes maduro inclui:
- Verificação automática. Integridade das cópias conferida a cada execução, com alerta em caso de falha.
- Restauração periódica de amostras. Arquivos, bancos e máquinas virtuais restaurados em ambiente controlado, com conferência de que a aplicação de fato funciona.
- Teste de recuperação completa. Pelo menos para os sistemas críticos, simular a perda total e medir o tempo real até a operação — e comparar com o RTO definido.
- Exercício com o negócio. Testes de mesa em que gestores tomam decisões sob o cenário de indisponibilidade, como recomendam o NIST SP 800-34 e a ISO 22301.
O resultado de cada teste deve gerar ajustes: runbooks atualizados, dependências documentadas, prioridade de restauração revista. Classificar e segmentar dados sensíveis ajuda a definir essa ordem — o que volta primeiro é o que sustenta os processos críticos.
Do backup ao plano de continuidade
Backup é componente técnico; continuidade é capacidade organizacional. A ISO 22301 trata da gestão de continuidade de negócios como sistema de gestão, com papéis, políticas, BIA, estratégias, planos, exercícios e melhoria contínua. O NIST SP 800-34 detalha o plano de contingência de sistemas, com fases de ativação, recuperação e reconstituição.
Em um incidente de ransomware, o plano de recuperação também precisa conversar com a resposta a incidentes: antes de restaurar, é preciso conter o ataque, entender o vetor de entrada e garantir que o atacante não está mais no ambiente. Da mesma forma, a detecção contínua de um SOC sobre a infraestrutura de backup aumenta a chance de perceber a tentativa de sabotagem antes que ela se complete.
Perguntas frequentes
Backup em nuvem já conta como cópia fora do local?
Conta como cópia em outro local, mas não necessariamente como cópia protegida. Se a nuvem for acessível com as mesmas credenciais do ambiente e permitir exclusão sem restrição, um atacante com privilégio pode apagá-la. Habilite imutabilidade, separe identidades e monitore alterações de retenção.
Qual a diferença entre RTO e RPO?
O RTO mede quanto tempo o sistema pode ficar fora do ar; o RPO mede quanta perda de dados é tolerável. Um sistema pode ter RTO longo e RPO curto (pode demorar a voltar, mas não pode perder transações) ou o inverso.
Com que frequência devo testar a restauração?
Não há um número único. A verificação de integridade deve ser automática e contínua; restaurações de amostra, periódicas; e testes completos dos sistemas críticos, ao menos em ciclo planejado e sempre após mudanças relevantes de infraestrutura. A frequência deve ser proporcional à criticidade definida na BIA.
Backup imutável resolve o problema de ransomware?
Resolve parte dele: garante que haverá uma cópia recuperável. Não impede o vazamento de dados, que hoje acompanha boa parte dos ataques, nem substitui contenção, erradicação e verificação de que a cópia está limpa.
Referências: NIST SP 800-34 Rev. 1, Contingency Planning Guide for Federal Information Systems (BIA, RTO, RPO e plano de contingência); NIST SP 800-160 Vol. 2 Rev. 1, Developing Cyber-Resilient Systems (objetivos de resiliência: antecipar, suportar, recuperar, adaptar); CISA, #StopRansomware Guide (backups offline, criptografados e testados); ISO 22301:2019, Security and resilience — Business continuity management systems — Requirements. A regra 3-2-1-1-0 é uma convenção de mercado, não um padrão normativo. Este artigo é educacional e não descreve um produto específico.