Backup e Recuperação contra Ransomware: versionamento e cópias limpas (pontos de restauração confiáveis)

O que é versionamento de backup e por que ele evita “backup do problema”

Versionamento é manter múltiplas cópias históricas do mesmo conjunto de dados, cada uma representando um ponto no tempo (ponto de restauração). Em ransomware, isso é essencial porque a criptografia e a corrupção lógica podem acontecer de forma silenciosa: o dado “parece” normal no dia a dia, mas já está comprometido. Se você mantiver apenas o backup mais recente, existe o risco de ele já conter arquivos criptografados, registros alterados ou dados corrompidos — e você terá apenas uma cópia “do problema”.

Na prática, versionamento significa: (1) gerar pontos de restauração frequentes, (2) reter esses pontos por um período suficiente, (3) conseguir identificar a “última cópia boa” (last known good) e (4) impedir que cópias suspeitas substituam ou contaminem as boas.

Termos práticos que você vai usar

• Ponto de restauração: backup de um momento específico (ex.: 02:00 de hoje).
• Janela de exposição: tempo entre o início do comprometimento e a detecção. O versionamento precisa cobrir essa janela.
• Última cópia boa: ponto de restauração anterior ao início da criptografia/corrupção.
• Backup “limpo”: ponto de restauração com evidências de integridade e sem indicadores de comprometimento.

Estratégias de múltiplos pontos de restauração

1) Retenção baseada em tempo (time-based)

Você define por quanto tempo manter versões. É útil quando a detecção pode demorar (ex.: 14, 30, 60, 90 dias). Exemplo típico:

• Diários: manter 30 dias
• Semanais: manter 12 semanas
• Mensais: manter 12 meses

Vantagem: cobre melhor ataques silenciosos. Atenção: custo de armazenamento cresce com o tempo de retenção.

2) Retenção baseada em quantidade (count-based)

Você define quantas versões manter (ex.: manter os últimos 60 pontos). É útil quando a frequência é alta e você quer previsibilidade de consumo.

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

• Exemplo: backups a cada 2 horas, manter os últimos 120 pontos (≈ 10 dias).

Risco: se a frequência mudar (mais backups por dia), a cobertura em dias diminui sem você perceber.

3) Estratégia combinada (recomendável)

Combinar tempo + quantidade reduz surpresas. Exemplo:

• Manter no mínimo 30 dias e no mínimo 60 versões (o que for maior).

4) “Escada” de retenção (GFS simplificado)

Uma forma didática de organizar pontos de restauração é usar uma escada: muitos pontos recentes e poucos pontos antigos.

Como identificar a “última cópia boa” (ponto de restauração confiável)

Identificar a última cópia boa é um processo de evidências, não de “achismo”. Você cruza sinais do ambiente com validações do backup.

Sinais comuns de que um ponto pode estar comprometido

• Picos de alteração de arquivos (muitos arquivos modificados em pouco tempo).
• Extensões incomuns ou troca massiva de extensões.
• Arquivos com alta entropia (indicativo de criptografia) em volume anormal.
• Logs de segurança indicando execução de binários suspeitos, criação de tarefas agendadas, alterações em GPO, etc.
• Banco de dados com crescimento/queda abrupta, tabelas “zeradas”, ou inconsistências após restore de teste.

Validações práticas para classificar um ponto como “limpo”

• Verificação de integridade do backup: checagem de hashes/manifestos quando disponível.
• Restore de amostra: restaurar um conjunto pequeno e representativo (ex.: 1% dos diretórios críticos) em ambiente isolado.
• Varredura antimalware no restore: executar varredura no conteúdo restaurado (principalmente executáveis, scripts, documentos com macros).
• Teste funcional: abrir documentos, validar permissões, rodar consultas básicas em banco restaurado.

Regra prática: um ponto de restauração só vira “confiável” depois de passar por pelo menos uma validação técnica (integridade) e uma validação de uso (teste funcional).

Passo a passo: definindo versionamento e retenção para resistir a criptografia silenciosa

Passo 1 — Defina a janela de exposição provável

Liste quanto tempo você pode ficar sem perceber um comprometimento (ex.: finais de semana, feriados, baixa observabilidade). Use um valor conservador.

• Exemplo: “Podemos demorar até 21 dias para detectar corrupção lógica em arquivos compartilhados”.

Passo 2 — Escolha a frequência de pontos de restauração por tipo de dado

• Arquivos compartilhados: a cada 4–12 horas (depende do volume de mudança).
• Servidores de aplicação: diário (e antes de mudanças planejadas).
• Bancos de dados: combinar full + incrementais + logs (ver seção específica).

Passo 3 — Defina retenção em camadas

Monte a “escada” (quente/morna/fria) para cobrir a janela de exposição.

• Exemplo: quente 7 dias (a cada 4h), morna 45 dias (diário), fria 6 meses (semanal).

Passo 4 — Imponha regra de “não sobrescrever versões boas”

Garanta que a política de retenção não apague as versões antigas antes do tempo. Evite configurações do tipo “manter apenas o último backup bem-sucedido”.

Passo 5 — Crie um processo de “promoção” de pontos confiáveis

Em vez de tratar todo backup como igualmente confiável, crie um rótulo operacional:

• Estado: Novo (ainda não validado)
• Estado: Validado (passou checagens)
• Estado: Suspeito (indicadores de comprometimento)
• Estado: Isolado (acesso restrito, não usado para restore padrão)

Isso pode ser feito via tags/labels no repositório, via planilha de controle, ou via sistema de tickets — o importante é existir um registro rastreável.

Como lidar com dados que mudam rapidamente (bancos e arquivos compartilhados)

Arquivos compartilhados: evitar propagação de criptografia

Em compartilhamentos, ransomware costuma criptografar em massa e rapidamente. O risco é o backup incremental capturar a criptografia como “mudança legítima”. Para reduzir isso:

• Aumente a frequência de pontos (mais chances de ter um ponto imediatamente anterior ao início).
• Use detecção de anomalia por volume de alterações: se houver um salto de arquivos alterados, o job deve ser sinalizado para revisão antes de “promover” o ponto.
• Separe por criticidade: diretórios críticos com políticas mais agressivas (mais versões, retenção maior).

Exemplo de regra simples (conceitual) para sinalizar suspeita:

Se (arquivos_modificados_no_job > média_7_dias * 5) OU (extensões_novas > limiar) então marcar backup como SUSPEITO

Bancos de dados: consistência e ponto no tempo

Para bancos, o objetivo é restaurar com consistência e, quando possível, voltar para um ponto no tempo anterior ao ataque.

• Full: base para restauração.
• Incrementais/diferenciais: reduzem janela de perda.
• Logs (quando aplicável): permitem point-in-time restore (parar “antes” do evento).

Cuidados para não “carregar” corrupção lógica:

• Validação pós-backup: executar checagens de consistência (quando suportado) em janela controlada.
• Restore de teste: restaurar em ambiente isolado e rodar consultas de sanidade (contagens, integridade referencial, amostras de tabelas críticas).
• Separar credenciais: o processo de backup não deve ter permissões desnecessárias no ambiente de produção além do mínimo para leitura/backup.

Como evitar backups propagando dados criptografados

1) “Quarentena” operacional para pontos recentes

Trate backups recém-criados como potencialmente contaminados até validação mínima. Na prática:

• O ponto entra como Novo.
• Ele só vira Validado após checagens automáticas + amostragem.
• Restores padrão (em incidente) priorizam pontos Validados.

2) Bloqueio por anomalia (sem depender de ferramenta específica)

Mesmo sem recursos avançados, você pode implementar um controle simples:

• Registrar por job: total de arquivos, arquivos alterados, volume transferido, tempo de execução.
• Definir limiares por tipo de dado (ex.: compartilhamento A vs B).
• Se exceder limiar, o job não é apagado, mas o ponto é marcado como Suspeito e não entra na lista de “últimos bons”.

3) Separação de conjuntos de backup (blast radius menor)

Evite um único job gigantesco para tudo. Separe por:

• Criticidade (financeiro, ERP, engenharia)
• Tipo (arquivos, banco, VMs)
• Unidade/área

Isso ajuda a impedir que um evento em um compartilhamento “contamine” a percepção de que todos os pontos recentes são ruins.

Procedimento: marcar e isolar cópias suspeitas

A seguir, um procedimento operacional simples para lidar com suspeita de criptografia/corrupção sem destruir evidências e sem perder pontos potencialmente úteis.

Passo a passo (runbook)

1. Congelar a rotação automática (somente para o conjunto afetado)
   Suspenda a expiração/apagamento automático temporariamente para evitar que versões antigas sejam removidas enquanto você investiga.

2. Identificar o intervalo suspeito
   Defina T0 (último momento conhecido normal) e T1 (primeiro sinal de problema). Liste todos os pontos de restauração entre T0 e T1.

3. Marcar pontos como SUSPEITOS
   Aplique tag/label “SUSPEITO” em todos os pontos no intervalo e registre: data/hora, origem, job, motivo (ex.: pico de alterações, alerta de segurança).

4. Isolar o acesso aos pontos suspeitos
   Restrinja quem pode restaurar/baixar esses pontos. Objetivo: evitar que alguém restaure “sem querer” um ponto contaminado para produção.

5. Selecionar candidatos a “última cópia boa”
   Escolha 2–3 pontos imediatamente anteriores a T0 (por exemplo: T0-4h, T0-12h, T0-24h) para teste.

6. Restaurar em ambiente isolado (sandbox)
   Restaure os candidatos em rede segregada, sem credenciais de produção, e com logging habilitado.

7. Executar validações
   Checklist mínimo: (a) varredura antimalware, (b) amostragem de arquivos/tabelas críticas, (c) verificação de extensões/entropia anormal, (d) teste de abertura/consulta.

8. Promover o ponto aprovado
   Se aprovado, marque como “VALIDADO” e registre evidências (logs, checksums, resultados de testes). Se reprovado, mantenha como “SUSPEITO” e teste o próximo candidato.

9. Preservar evidências
   Não apague imediatamente pontos suspeitos. Mantenha-os isolados por um período definido (ex.: 30–90 dias) para auditoria e investigação, conforme política interna.

Modelo de registro (exemplo)

Exemplos práticos de políticas (para adaptar)

Exemplo A — Arquivos compartilhados (alto volume de mudança)

• Pontos a cada 4 horas (6 por dia)
• Retenção: 7 dias (quente) + 45 dias (diário) + 6 meses (semanal)
• Regra de suspeita: >5x média semanal de arquivos alterados OU surgimento de extensões incomuns
• Promoção: validar 1 ponto por dia via amostragem automatizada + revisão quando houver alerta

Exemplo B — Banco de dados transacional

• Full diário
• Incremental a cada 6 horas
• Logs a cada 15 minutos (quando aplicável)
• Retenção: 30 dias (full) + 7 dias (logs) + semanais por 3 meses
• Validação: restore semanal em sandbox + checagens de consistência + consultas de sanidade

Exemplo C — Servidor de aplicação com mudanças controladas

• Backup diário
• Backup adicional antes de mudanças (patch, deploy)
• Retenção: 30 dias + 3 mensais
• Validação: restore mensal de amostra + verificação de arquivos de configuração críticos