Backup e Recuperação contra Ransomware: regra 3-2-1 aplicada na prática

Regra 3-2-1: o que significa e como aplicar sem complicar

A regra 3-2-1 organiza seu backup para resistir a falhas comuns (erro humano, falha de hardware) e também a ransomware. Ela se resume a:

• 3 cópias: 1 cópia primária (produção) + 2 cópias de backup.
• 2 mídias/tecnologias diferentes: reduzir risco de um mesmo tipo de falha ou ataque afetar tudo (ex.: só disco no mesmo storage).
• 1 cópia fora do ambiente principal: fora do domínio/ambiente que pode ser comprometido (offsite/offline/imutável).

Para ransomware, o ponto crítico é que o atacante tende a buscar e criptografar/excluir backups acessíveis com as mesmas credenciais, na mesma rede ou no mesmo console. Por isso, “fora do ambiente principal” não é apenas “em outro servidor”: é fora do alcance operacional do atacante (isolamento, imutabilidade, credenciais separadas e/ou offline).

Como traduzir 3-2-1 em decisões práticas

Opções de mídia/tecnologia: quando usar e limitações contra ransomware

1) Disco (backup em disco local/NAS/servidor de backup)

Quando faz sentido: recuperação rápida, custo previsível, simplicidade em pequenas empresas, restaurações frequentes (arquivos, VMs, bancos).

Limitações em ransomware: se estiver na mesma rede/domínio e com credenciais acessíveis, pode ser criptografado/excluído. Proteções importantes: rede segregada, contas dedicadas, MFA no console, repositório com imutabilidade (quando suportado), e acesso “pull” (servidor de backup puxa dados) em vez de “push” amplo.

2) Snapshot (storage/hipervisor)

Quando faz sentido: RPO curto e restauração muito rápida (rollback). Útil para VMs e volumes.

Continue em nosso aplicativo e ...

• Ouça o áudio com a tela desligada
• Ganhe Certificado após a conclusão
• + de 5000 cursos para você explorar!

ou continue lendo abaixo...

Baixar o aplicativo

Limitações em ransomware: snapshots podem ser apagados se o atacante obtiver acesso ao storage/hipervisor. Também não substituem backup completo (dependência do mesmo array/cluster). Para endurecer: snapshots imutáveis (quando disponíveis), retenções protegidas, e replicação para outro domínio/conta.

3) Objeto (S3-compatível/on-prem) e Cloud Storage

Quando faz sentido: cópia externa escalável, boa para retenção longa, e forte para ransomware quando há imutabilidade (Object Lock/WORM) e contas separadas.

Limitações em ransomware: chaves/API comprometidas podem permitir exclusão se não houver imutabilidade e políticas corretas. Mitigações: Object Lock com retenção, versionamento, políticas de negação de delete, credenciais segregadas, e “air gap lógico” (conta/tenant separado).

4) Fita (LTO) / WORM

Quando faz sentido: retenção longa, custo por TB baixo, e excelente isolamento (offline). Muito forte como “cópia fora do ambiente principal”.

Limitações em ransomware: recuperação mais lenta (RTO maior), logística (armazenamento/rodízio), e necessidade de processo disciplinado. Ainda assim, é uma das melhores barreiras contra destruição deliberada.

5) Repositório imutável (WORM/retention lock)

Quando faz sentido: qualquer cenário que precise resistir a exclusão/alteração maliciosa. Pode existir em objeto, appliance, ou software de backup com “hardened repository”.

Limitações em ransomware: não elimina risco de indisponibilidade (ex.: ataque DDoS, credenciais do console, falhas de configuração). Exige governança: quem pode reduzir retenção? Quem pode desativar lock? Como auditar?

Passo a passo: desenhando sua 3-2-1 aplicada na prática

Passo 1 — Defina as 3 cópias (produção + 2 backups) com papéis diferentes

• Cópia A (produção): onde o sistema roda.
• Cópia B (backup local): foco em velocidade de restauração (RTO menor). Geralmente em disco e/ou snapshots.
• Cópia C (backup externo): foco em resiliência (sobreviver a comprometimento). Geralmente em objeto/cloud com imutabilidade ou fita offline.

Passo 2 — Garanta “2 tecnologias” de verdade

Evite “duas cópias no mesmo tipo de risco”. Exemplos:

• Disco local + objeto imutável (rápido + resiliente).
• Snapshot local + fita offline (rollback rápido + cofre offline).
• Disco em datacenter + disco em filial pode contar como 2 cópias, mas não necessariamente como 2 tecnologias e pode falhar contra ransomware se o atacante tiver alcance de rede/credenciais.

Passo 3 — Faça a cópia “fora do ambiente principal” ser realmente fora

Checklist prático para a cópia externa:

• Isolamento de credenciais: conta/tenant separado ou, no mínimo, chaves e usuários exclusivos para escrita.
• Imutabilidade: retenção WORM/Object Lock ou fita offline.
• Rede: evitar que o mesmo domínio/AD administre tudo; limitar rotas e acessos.
• Permissões: princípio do menor privilégio; negar exclusão quando possível.
• Auditoria: logs de deleção/alteração e alertas.

Passo 4 — Escolha periodicidade e retenção com base no RPO (critério objetivo)

RPO é o quanto de dados você aceita perder. A periodicidade do backup deve ser menor ou igual ao RPO do dado. Use esta lógica:

• Se RPO = 1 hora, você precisa de backups/snapshots pelo menos a cada 1 hora (ou mecanismos equivalentes, como log shipping/replicação, quando aplicável).
• Se RPO = 24 horas, um backup diário pode bastar.

Uma forma simples de transformar isso em política:

Retenção deve considerar: tempo para detectar ransomware (às vezes dias), tempo para investigação, e necessidade de voltar a um ponto “limpo”. Em ransomware, retenções muito curtas podem falhar se a criptografia/comprometimento for percebido tarde.

Passo 5 — Ajuste janelas de backup e impacto no ambiente

“Janela de backup” é quando o backup roda e quanto tempo ele pode consumir recursos. Critérios práticos:

• Volume de mudança (change rate): quanto mais muda, mais frequente e mais pesado fica o incremental.
• Horários de pico: agendar full e tarefas pesadas fora do pico.
• Limites de I/O e rede: usar throttling e paralelismo controlado.
• Estratégia comum: full semanal + incrementais diários/horários (conforme RPO), com cópia externa assíncrona.

Arquiteturas simples (pequena empresa): rápido local + resiliente externo

Arquitetura A — Pequena empresa (servidores locais + NAS + cloud objeto imutável)

Objetivo: restaurar rápido do NAS e manter uma cópia externa protegida.

• Cópia 1 (produção): servidor/VMs locais.
• Cópia 2 (backup local): repositório em NAS/servidor de backup em rede segregada.
• Cópia 3 (fora): replicação para storage objeto/cloud com imutabilidade e conta separada.

Fluxo recomendado:

• Backup incremental frequente para o repositório local (velocidade).
• Job de cópia/replicação do repositório local para objeto imutável (resiliência), com atraso pequeno (ex.: a cada 1–4 horas) conforme RPO.

Pontos de atenção anti-ransomware:

• Console de backup com MFA e contas separadas.
• Repositório local com acesso restrito (idealmente “hardened/immutable” quando possível).
• Na cópia externa: Object Lock/retention e política que impeça deleção antes do prazo.

Arquitetura B — Pequena empresa com fita (quando RTO permite)

Objetivo: ter um “air gap” físico.

• Cópia 2 (backup local): disco para restauração rápida (últimos 7–14 dias).
• Cópia 3 (fora): fita com rodízio (ex.: semanal/mensal) armazenada fora do site.

Quando escolher: necessidade de retenção longa e proteção máxima contra deleção, aceitando restauração mais lenta.

Arquiteturas para ambiente híbrido (on-prem + cloud)

Arquitetura C — Híbrido com “cópia externa” em outra conta/tenant

Objetivo: mesmo que o ambiente on-prem seja comprometido, a cópia externa não pode ser apagada.

• On-prem: backup local em disco (rápido).
• Cloud: bucket/contêiner em conta separada com imutabilidade e políticas de acesso mínimo.

Prática recomendada: o on-prem só tem permissão de put (gravar) e listar o mínimo necessário; deleção e alteração de retenção ficam restritas a um grupo de segurança separado (break-glass) com MFA e auditoria.

Arquitetura D — Híbrido com snapshots locais + backup para objeto

Objetivo: RPO curto com snapshots e retenção segura com objeto.

• Snapshots: a cada 15–60 min (conforme RPO), retenção curta (ex.: 24–72h) para rollback rápido.
• Backup para objeto imutável: diário/horário (conforme criticidade), retenção maior (30–180 dias).

Limitação importante: snapshot não substitui cópia externa; trate snapshot como camada de velocidade, não como camada de sobrevivência.

Como combinar backup local (velocidade) com cópia externa (resiliência)

Padrão recomendado em camadas

• Camada 1 — Recuperação rápida: backup local em disco e/ou snapshots (restaurações em minutos/horas).
• Camada 2 — Sobrevivência a ransomware: cópia externa imutável/offline (restauração em horas/dias, mas preserva dados).

Exemplo de política (modelo para adaptar)

Escolha os números com base no RPO e no tempo máximo aceitável para detectar e reagir ao ataque. Se sua detecção costuma levar dias, retenções externas muito curtas aumentam o risco de só existirem backups já comprometidos.

Checklist rápido de validação da sua 3-2-1

• Tenho duas cópias de backup além da produção?
• As cópias usam duas tecnologias (ex.: disco + objeto/fita), não apenas dois discos na mesma rede?
• A cópia externa está fora do alcance do mesmo domínio/credenciais?
• Existe imutabilidade (ou offline) na cópia externa?
• Periodicidade atende o RPO dos dados críticos?
• Retenção cobre o tempo de detecção e investigação (dias/semanas)?
• Janelas e limites de I/O/rede não quebram a operação?