Durante quanto tempo deve guardar as versões dos ficheiros após um ataque de ransomware?

Mantenha versões diárias de ficheiros por pelo menos 30 a 90 dias como um intervalo prático de partida após um ataque de ransomware, mas não trate isso como um prazo universal de eliminação. A retenção deve estender-se além da data de compromisso mais plausível e precoce, preservar pontos limpos semanais ou mensais selecionados e manter as evidências do incidente separadamente até que a recuperação, investigação, seguro, questões legais e de conformidade estejam concluídas.

Um Intervalo Prático de Partida é de 30 a 90 Dias

Muitos designs de backup usam de 30 a 90 dias de histórico diário imutável para recuperação operacional de ransomware. Uma visão geral de backup imutável nota que 30 a 90 dias é um intervalo comum de retenção diária para proteção contra ransomware. Considere isto como um ponto de partida, não uma garantia de que a versão mais antiga retida está limpa.

O limite inferior só é razoável quando a infeção é detetada rapidamente, cópias antigas estão isoladas e uma restauração limpa já foi comprovada.

Comece a Contagem Antes de Aparecer a Nota de Resgate

O evento de encriptação visível pode ocorrer dias ou semanas após o acesso inicial. Uma estratégia de backup contra ransomware deve ter em conta o tempo de permanência entre o compromisso inicial e o evento visível de ransomware. Se o primeiro login suspeito, script, uso de credenciais ou alteração de ficheiro ocorreu 45 dias antes da encriptação, uma janela de versões de 30 dias pode não conter nenhum ponto limpo.

Use a data de compromisso mais plausível e precoce a partir dos registos, alertas de endpoint, registos de identidade e descobertas da resposta a incidentes. Depois, adicione uma margem de segurança para evidências incompletas. A janela de retenção deve cobrir essa data, não apenas a data em que os utilizadores viram os ficheiros encriptados pela primeira vez.

Use Retenção em Camadas em Vez de Uma Janela Única Rolante

Uma janela móvel plana pode eliminar todos os pontos limpos mais antigos no mesmo cronograma. A retenção em camadas mantém versões recentes densas enquanto preserva menos pontos de verificação de longo prazo.

Uma análise recente de retenção mostra por que pontos de restauração semanais e mensais selecionados podem estender a recuperação para além de uma janela curta comprometida. Os níveis exatos devem seguir o valor dos seus dados, orçamento de armazenamento e capacidade de deteção.

Preserve Cópias da Época do Incidente Fora da Rotação Normal

Não permita que a poda normal elimine as versões, registos, catálogos de backup, notas de resgate, amostras de ficheiros afetados e registos de configuração necessários para compreender o evento. Crie uma retenção de incidente ou exporte esses artefactos para um local protegido com acesso documentado.

A retenção de evidências de incidentes e a retenção de backups operacionais resolvem problemas diferentes. O histórico de backups fornece opções de recuperação; a retenção de incidentes apoia a análise do âmbito, seguros, revisão legal e lições aprendidas. Coordene a eliminação com as pessoas responsáveis por essas obrigações. Este artigo é uma orientação operacional, não um conselho legal.

Reter por Mais Tempo para Ficheiros que Mudam Lentamente e São Raramente Abertos

O ransomware pode modificar um ficheiro muito antes de alguém notar, se esse ficheiro for raramente aberto. Arquivos, registos fiscais, ativos de design, mestres de projetos, fotos de família e documentos históricos frequentemente necessitam de um histórico de versões mais longo do que pastas de trabalho ativas.

Encontre a Versão Limpa Mais Recente Antes de Eliminar as Mais Antigas

A versão mais recente antes da encriptação não é automaticamente segura. A recuperação cibernética requer identificar um ponto livre de indicadores de comprometimento e que possa funcionar sem reconectar o atacante. Um fluxo de trabalho de recuperação deve assumir que o backup limpo mais recente é desconhecido até que os pontos de restauração sejam analisados e validados.

Valide as versões candidatas num local isolado. Verifique a legibilidade dos ficheiros, hashes quando relevantes, consistência da aplicação, indicadores de malware, permissões de utilizador e a capacidade de abrir ficheiros antigos representativos. Mantenha versões antigas até que pelo menos um ponto limpo tenha passado nesses testes.

O teste de restauração define o verdadeiro limiar de retenção

Uma política de retenção só é útil se as versões puderem ser restauradas. As orientações para planeamento de recuperação recomendam testes de restauração agendados para provar que a recuperação de ficheiros é realmente possível.

Teste pelo menos três pontos: uma versão recente, uma próxima do limite suspeito de comprometimento e uma âncora semanal ou mensal mais antiga. Se apenas o ponto mais recente for testado, não se sabe se as versões a longo prazo necessárias para a recuperação de ransomware estão completas, descodificáveis e indexadas corretamente.

Certifique-se de que as versões antigas sobrevivem ao caminho de ataque

A retenção prolongada numa partilha gravável não oferece proteção a longo prazo se a mesma conta comprometida puder eliminá-la. Versões mais antigas devem ser separadas por permissões, conta de armazenamento, domínio administrativo, caminho de rede ou rotação offline. A imutabilidade impede a eliminação precoce durante um período configurado, enquanto as cópias offline removem o caminho de ataque ativo.

O guia ZimaSpace para proteger planos de controlo de backup e cópias de recuperação imutáveis explica por que as definições de retenção, repositórios, credenciais e consolas de backup devem ser protegidos em conjunto.

Verifique se o armazenamento pode sustentar o plano de retenção

Estime a capacidade a partir da taxa de alteração diária, não apenas do tamanho dos ficheiros ativos. Um modelo simples de planeamento é:

Capacidade de versão necessária ≈ cópia base + alterações diárias retidas + âncoras semanais/mensais + espaço temporário para restauração e verificação.

Meça o crescimento real do repositório por várias semanas. Inclua compressão, desduplicação, churn da base de dados, retenção de ficheiros eliminados, períodos de bloqueio imutável e o espaço de trabalho necessário para fusões ou testes de restauração. Se a capacidade for muito pequena, reduza a frequência de versões para pastas de baixo valor antes de encurtar toda a janela de pontos limpos.

Reduza a retenção apenas depois de cumprir condições específicas

Pode considerar reduzir o histórico diário denso depois que todas as seguintes condições forem verdadeiras:

• A data mais antiga plausível de comprometimento foi estabelecida com confiança razoável.
• Pelo menos um ponto de recuperação limpo foi validado isoladamente.
• Evidências do incidente foram preservadas fora da rotação normal de backups.
• Sistemas e ficheiros críticos foram restaurados e verificados pelos seus proprietários.
• Stakeholders de segurança, legais, seguros e conformidade liberaram a exclusão normal.
• Âncoras semanais e mensais ainda cobrem descobertas tardias e dados sazonais.

Se alguma condição não estiver resolvida, preserve os pontos mais antigos. Pressão de armazenamento não é motivo seguro para apagar as únicas versões que podem ser anteriores ao ataque.

Aja rapidamente quando versões são armazenadas por um serviço de sincronização na cloud

As janelas de histórico de ficheiros e da reciclagem na cloud podem ser mais curtas que a sua política de backup, e alterações por ransomware podem sincronizar para a cloud. As orientações de recuperação avisam que versões antigas de ficheiros e itens eliminados podem desaparecer quando o limite de retenção do serviço expira.

A partir de um dispositivo limpo, congele a sincronização onde for apropriado, preserve a conta, exporte versões críticas e documente o ponto limpo mais antigo disponível. Não presuma que o fornecedor da cloud mantém histórico ilimitado.

Perguntas Frequentes

Quando pode apagar versões que podem conter ficheiros encriptados?

Apague-as apenas depois de entender o escopo do incidente, restaurar e testar versões limpas, preservar evidências e liberar qualquer bloqueio legal ou de seguro. Isole versões suspeitas em vez de misturá-las novamente na produção.

Mais versões são sempre mais seguras?

Não. Mais versões ajudam apenas quando são completas, protegidas contra exclusão, indexadas, descriptografáveis e testadas regularmente. Centenas de versões controladas pela mesma conta comprometida ainda podem falhar em conjunto.

Snapshots e backups independentes devem usar o mesmo período de retenção?

Normalmente não. Snapshots locais são úteis para rollback denso a curto prazo, enquanto backups independentes ou imutáveis devem cobrir janelas mais longas contra ransomware e desastres. Use diferentes níveis de retenção para que uma falha de armazenamento ou comprometimento de conta não apague todos os pontos de recuperação.