Ransomware não é apenas um problema de antivírus. É um incidente de continuidade operacional. O atacante busca acesso, eleva privilégios, desativa proteções, identifica servidores e compartilhamentos e, cada vez mais, procura o ambiente de backup antes de criptografar os dados de produção. Se a cópia estiver acessível com as mesmas credenciais da rede, ela pode cair junto com o servidor principal.
Por que um backup comum pode falhar contra ransomware
A ideia de copiar arquivos para um HD externo, um NAS ou uma pasta em nuvem parece suficiente até o momento em que o ataque atinge a empresa. O problema é que ransomware moderno não trabalha apenas na estação de trabalho onde começou. Depois de entrar, ele pode se movimentar lateralmente, atingir compartilhamentos de rede, máquinas virtuais, controladores de domínio e repositórios de backup.
Um backup conectado permanentemente ao ambiente, com permissões excessivas ou sem retenção de versões, é uma extensão da infraestrutura produtiva. Se o invasor obtiver uma conta administrativa, poderá apagar pontos de restauração, alterar políticas de retenção ou criptografar os próprios arquivos de backup. Não basta ter uma cópia: é preciso garantir que ela sobreviva ao incidente.
Outro erro frequente é confundir sincronização com backup. Serviços de sincronização replicam alterações rapidamente. Isso é útil para colaboração, mas pode replicar também arquivos criptografados ou excluídos. Sem versionamento adequado e retenção configurada, a empresa pode sincronizar o problema para todas as cópias.
Há ainda a questão do tempo. Uma cópia íntegra que exige três dias para restaurar um servidor crítico não entrega continuidade aceitável para uma indústria, escritório contábil ou operação jurídica em período de fechamento. Proteção real combina recuperação possível com recuperação dentro do prazo que o negócio tolera.
Backup protege contra ransomware quando segue uma arquitetura de recuperação
A referência mais conhecida é a regra 3-2-1: manter três cópias dos dados, em dois tipos de mídia, com uma cópia fora do ambiente principal. Para riscos atuais, vale evoluir para 3-2-1-1-0. Isso acrescenta ao menos uma cópia offline ou imutável e zero erros verificados nas rotinas de backup e restauração.
Imutabilidade significa que um ponto de recuperação não pode ser alterado ou apagado antes do fim do período definido, mesmo por uma conta administrativa comprometida. Dependendo da solução escolhida, isso pode ser feito em armazenamento de objetos com bloqueio de retenção, appliance dedicado ou mídia desconectada. A tecnologia varia, mas o objetivo é o mesmo: impedir que um invasor apague a última cópia confiável.
A cópia offline também tem valor. Ela fica desconectada da rede depois da execução do backup e, por isso, não está disponível para ser atacada remotamente naquele momento. Existe um trade-off: a operação exige disciplina e pode tornar a recuperação menos imediata. Ainda assim, ela é uma camada relevante para dados que não podem ser perdidos.
A arquitetura deve separar ambientes e credenciais. O administrador do domínio não deve ter automaticamente controle total sobre o repositório de backup. Contas exclusivas, autenticação multifator, princípio do menor privilégio e redes segmentadas reduzem a chance de um único comprometimento destruir produção e recuperação ao mesmo tempo.
O que precisa entrar no plano de backup
A prioridade não é simplesmente salvar o maior volume possível. É identificar o que a empresa precisa para voltar a operar. Em muitas organizações, isso inclui servidores virtuais, banco de dados, ERP, arquivos departamentais, controlador de domínio, configurações de firewall, máquinas críticas e aplicações específicas.
Backups de máquinas virtuais aceleram a recuperação de servidores completos, mas os dados de aplicações precisam de consistência. Um banco de dados copiado em um momento inadequado pode restaurar com falhas ou perda de transações. Por isso, a política deve considerar integrações com aplicativos, janelas de backup e requisitos de cada sistema.
Configurações também são ativos. Restaurar um servidor sem ter a configuração de rede, regras de firewall, documentação de VLANs, credenciais de serviços e parâmetros do sistema pode prolongar uma crise desnecessariamente. Em ambientes com Proxmox VE, pfSense e serviços corporativos integrados, o plano precisa cobrir tanto as máquinas quanto a infraestrutura que permite acessá-las.
RPO e RTO: os números que definem o prejuízo
Dois indicadores tiram o plano de backup do campo da promessa genérica. O RPO, Recovery Point Objective, define quanto dado a empresa aceita perder. Se o backup ocorre uma vez por dia, um ataque às 17h pode exigir a perda das alterações feitas desde a última cópia. Para algumas áreas isso é tolerável; para outras, não.
O RTO, Recovery Time Objective, estabelece em quanto tempo o serviço precisa voltar. Um servidor de arquivos pode suportar algumas horas de indisponibilidade. Já um ERP usado para emissão, estoque e faturamento pode exigir retorno muito mais rápido. Esses objetivos precisam ser definidos com a direção e as áreas operacionais, não apenas pelo fornecedor de TI.
Prometer recuperação total sem discutir RPO e RTO é suporte superficial. A decisão técnica precisa ser proporcional ao impacto financeiro e operacional. Uma empresa com 20 computadores pode precisar de uma arquitetura simples e bem administrada; outra, com o mesmo número de usuários, mas dependente de dados transacionais, pode exigir replicação, retenção maior e recuperação prioritária de servidores.
Testar a restauração é tão necessário quanto executar o backup
Um painel verde informando “backup concluído” não prova que a recuperação funcionará. Arquivos podem estar corrompidos, permissões podem falhar, chaves de criptografia podem estar indisponíveis e a capacidade de armazenamento pode não ser suficiente para restaurar com velocidade.
O teste deve ir além de recuperar um arquivo isolado. A empresa precisa validar periodicamente a restauração de uma máquina virtual, a abertura de bases de dados, o acesso de usuários, a integridade de aplicativos e a ordem correta para reativar serviços. Em um ataque real, restaurar primeiro o servidor errado pode atrasar todo o retorno.
Também é necessário documentar responsabilidades. Quem autoriza desligar sistemas? Quem aciona fornecedores de ERP? Qual é o contato de emergência? Onde estão as chaves, senhas de contingência e inventário dos ativos? Durante um incidente, decisões simples ficam lentas quando dependem de informações dispersas ou de uma única pessoa.
O backup faz parte da defesa, não substitui a segurança
Uma empresa com cópia imutável está mais preparada para não negociar com criminosos, mas isso não elimina a necessidade de prevenção. Atualizações, monitoramento, proteção de endpoints, segmentação de rede, controle de acessos, filtros de e-mail e treinamento de usuários reduzem a probabilidade de o ataque chegar ao estágio de criptografia.
É preciso considerar também o vazamento de dados. Muitos grupos criminosos copiam informações antes de bloquear os sistemas e ameaçam divulgar documentos, dados financeiros ou informações de clientes. O backup restaura a operação, mas não desfaz uma exfiltração. Por isso, investigação, contenção e análise de acessos fazem parte da resposta.
Quando há sinal de ransomware, a prioridade inicial é conter: isolar máquinas afetadas, impedir movimentação lateral, preservar evidências e avaliar o alcance antes de iniciar restaurações. Recuperar um servidor em uma rede ainda comprometida pode reinfectar o ambiente. Em incidentes críticos, velocidade sem método custa caro.
A SuporteDelivery estrutura ambientes corporativos com foco em prevenção, monitoramento e recuperação verificável, porque a empresa não pode depender de improviso quando seus sistemas param. O melhor momento para validar um backup é antes de precisar dele, com objetivos de recuperação definidos, cópias protegidas e um time que saiba exatamente como colocar a operação de volta em funcionamento.
Precisa de ajuda com TI?
Fale conosco e descubra como podemos ajudar sua empresa em Curitiba.
Falar no WhatsAppContinue lendo