Criar backups resilientes a ransomware

Porque é que o ransomware transforma os backups no alvo, e não na rede de segurança

Durante anos, o backup foi a exceção que tornava o ransomware sobrevivível: encriptar a produção, restaurar a partir do backup e seguir em frente. Os atacantes evoluíram. No inquérito Ransomware Trends 2025 da Veeam, realizado junto de 1300 organizações que tinham sido atacadas, 89% viram os seus repositórios de backup visados como parte do ataque — não como uma reflexão tardia, mas como um objetivo de primeira linha na kill chain. Destruir ou corromper o plano de recurso antes de encriptar a produção é atualmente prática operacional padrão, porque retira à vítima qualquer margem de negociação antes de a nota de resgate sequer chegar.

O resultado reflete-se nos números de recuperação. O relatório State of Ransomware 2025 da Sophos concluiu que apenas 54% das organizações usaram backups para restaurar dados após um ataque — a taxa mais baixa nos seis anos em que o estudo é realizado. Entre as organizações que acabaram por pagar mais do que a exigência inicial do atacante, 38% apontaram falhas ou avarias nos backups como o motivo de não terem tido melhor alternativa. Um backup que existe apenas no papel não é o mesmo que um backup que restaura de forma limpa sob pressão.

Essa diferença — entre "temos backups" e "temos backups resilientes a ransomware" — resume-se a três pilares: imutabilidade, isolamento e recuperação testada. Não são controlos independentes que se possam combinar à vontade. Se faltar um deles, os outros dois não compensam: um backup imutável que o atacante não consegue alcançar só é útil se de facto restaurar, e um plano de restauro bem testado não vale nada se o backup de que depende tiver sido eliminado antes de o exercício sequer começar.

Os três pilares, em detalhe

1. Imutabilidade: backups que o atacante não consegue tocar

Imutabilidade significa que um backup não pode ser alterado nem eliminado dentro da sua janela de retenção — nem por um script de retenção mal configurado, nem por uma conta de administrador comprometida, nem pelo atacante que já obteve credenciais de administrador de domínio. Na prática, é imposta através de object lock em armazenamento cloud ou de objetos, hardware Write Once Read Many (WORM), ou um repositório Linux reforçado com bloqueios de retenção aplicados ao nível do armazenamento, independentemente dos próprios controlos de acesso da aplicação de backup.

Esta distinção é importante porque os operadores de ransomware atuais procuram ativamente repositórios de backup acessíveis com credenciais de produção e eliminam-nos ou encriptam-nos primeiro, antes de tocar nos dados primários. Se a mesma conta administrativa que gere o software de backup também conseguir eliminar os pontos de restauro do mês anterior, a imutabilidade não está de facto implementada — é apenas uma definição que um atacante com privilégios suficientes consegue desativar em minutos.

As orientações da CISA sobre ransomware são explícitas quanto a este ponto: manter backups offline, encriptados e imutáveis, verificá-los regularmente e tratá-los como a última linha de defesa, e não como a primeira coisa que um atacante tem de vencer.

2. Isolamento: um plano de identidade separado, e uma cópia à qual os atacantes não conseguem sequer chegar

A imutabilidade protege um backup de ser alterado. O isolamento protege-o de sequer ser alcançado. Os dois são complementares, não intermutáveis, e as empresas que implementam apenas um deles tendem a descobrir a lacuna durante um incidente real, e não durante uma revisão de arquitetura.

O isolamento tem duas componentes. A primeira é um plano de identidade separado — a infraestrutura de backup não deve confiar no mesmo domínio Active Directory, nas mesmas credenciais administrativas, nem no mesmo segmento de rede plano da produção. Um controlador de domínio comprometido não deveria significar automaticamente um ambiente de backup comprometido; se significar, o atacante só precisou de comprometer uma coisa, não duas. A segunda é uma cópia genuinamente offline ou com air gap — no mínimo, uma cópia dos dados críticos sem qualquer caminho de rede permanente a partir da produção, seja através de rotação de fitas offline, de um destino de replicação desligado que só fica brevemente online para receber dados, ou de um nível cloud sem credenciais persistentes guardadas em cache em qualquer ponto acessível a partir do parque de produção.

A investigação da Veeam concluiu que as organizações que priorizam este tipo de resiliência isolada e em camadas recuperam de ataques de ransomware até sete vezes mais depressa do que as que não o fazem, com uma perda de dados substancialmente menor pelo caminho. É o isolamento que torna essa diferença possível: é a distinção entre um atacante que tem de fazer trabalho adicional real para alcançar o seu ponto de recuperação, e um que já tem uma sessão aberta para lá porque partilha um plano de identidade com os sistemas que acabou de comprometer.

3. Recuperação testada: provar a capacidade de restauro antes de precisar dela

O menos glamoroso dos três pilares é também aquele que as organizações mais vezes negligenciam — e isso reflete-se nos resultados. Num inquérito ao setor realizado em 2025, 62% das organizações reportaram não efetuar regularmente exercícios de teste de backup e restauro, e 37% afirmaram não conseguir recuperar dentro do seu recovery time objective (RTO) exigido, especificamente porque os backups estavam em falta ou nunca tinham sido validados. A confiança e a realidade divergem aqui de forma acentuada: mais de 60% das organizações acreditam que conseguem recuperar de uma indisponibilidade em poucas horas, mas apenas cerca de um terço consegue efetivamente fazê-lo quando testado.

Os restauros nunca testados falham de formas que permanecem invisíveis até ao momento em que mais importam: cadeias de backup quebradas, dependências de consistência de aplicação em falta, credenciais de contas de serviço expiradas há meses, ou runbooks escritos para uma topologia de infraestrutura que já não existe. Negligenciar a validação acarreta também um risco mais grave do que uma simples indisponibilidade — estima-se que 63% das organizações correm o risco de reintroduzir uma infeção durante o restauro, por saltarem a verificação de integridade e a análise de malware sob pressão de tempo, acabando por recuperar exatamente a mesma carga maliciosa que causou a interrupção.

Um verdadeiro programa de recuperação testada implica exercícios de restauro completos e agendados para um ambiente de recuperação isolado — e não apenas notificações de "tarefa de backup concluída com sucesso" — validados face aos RTOs que o negócio realmente necessita, e não a valores que apenas parecem tranquilizadores num slide.

Como é quando os três pilares se mantêm firmes

Os dados de 2025 da Sophos oferecem um contraexemplo útil às estatísticas mais alarmantes: entre as organizações que tiveram efetivamente dados encriptados por um atacante, 97% ainda assim conseguiram recuperá-los. A diferença entre esse grupo e a pequena minoria que não conseguiu remonta quase sempre a um dos três pilares ser, na prática, mais fraco do que parecia no papel — um bloqueio de retenção que podia ser anulado pela função errada, uma rede de backup "separada" que continuava a confiar no mesmo domínio, ou um restauro que nunca tinha sido efetivamente ensaiado de ponta a ponta.

O custo de errar nisto

Os três pilares não são uma checklist abstrata de boas práticas — traduzem-se diretamente no custo e na duração de um incidente de ransomware. O custo médio para recuperar de um ataque de ransomware, excluindo qualquer resgate pago, ronda os 1,53 milhões de dólares. Apenas 53% das vítimas ficaram totalmente recuperadas dentro de uma semana; as restantes passaram mais de sete dias nalgum estado de disrupção, com a indisponibilidade, a perda de produtividade e o esforço de resposta a incidentes a acumularem-se dia após dia.

A postura de backup é uma das poucas variáveis dessa equação que uma organização controla por completo. O êxito ou fracasso do primeiro movimento de um atacante contra o seu repositório de backup é determinado inteiramente por decisões tomadas meses antes — não durante o próprio incidente. Quando um agente de ameaça já tem credenciais de administrador de domínio e está a sondar a sua plataforma de backup, a imutabilidade, o isolamento e a recuperação testada já estão implementados ou não estão; não há oportunidade de os implementar retroativamente sob pressão.

Erros comuns que comprometem silenciosamente os três pilares

Um punhado de padrões surge repetidamente nas análises pós-incidente:

• Confundir snapshots com backups. Um snapshot da VMware é uma diferença pontual guardada no mesmo datastore da VM que protege — não é uma cópia independente. Cresce sem limite, degrada o desempenho e desaparece no momento em que o datastore desaparece. Os snapshots são uma funcionalidade de conveniência para reversões de curta duração, não uma estratégia de recuperação.
• Tratar "imutável" como uma checkbox em vez de uma propriedade verificada. O object lock e as políticas de retenção têm de ser testados contra a função administrativa exata que gere a plataforma de backup, e não apenas documentados num guia de configuração.
• Chamar "isolada" a uma segunda cópia no mesmo domínio de identidade. Se as mesmas credenciais comprometidas na produção conseguirem autenticar-se no repositório de backup, a separação geográfica ou de plataforma não constitui isolamento real.
• Medir o sucesso pela conclusão do backup, e não pela verificação do restauro. Um visto verde na tarefa da noite anterior diz-lhe que os dados foram escritos nalgum lado. Não lhe diz que esses dados são recuperáveis, consistentes ao nível da aplicação, e livres do malware que motivou o restauro em primeiro lugar.

Onde entra a BackupSec

Na BackupSec, ajudamos as equipas empresariais a operar os seus ambientes de backup exatamente segundo estes três pilares — não substituindo a sua plataforma de backup, mas tornando a segurança do backup observável, aconselhável e demonstrável.

A nossa abordagem combina três camadas:

• O ZeroMON proporciona observabilidade contínua sobre todo o parque de backup — monitorização pronta para Veeam, com acompanhamento de tarefas em tempo real, verificações de segurança automatizadas, trilhos de auditoria forense para detetar desvios de configuração, e relatórios de conformidade num só clique. É esta camada que transforma "a imutabilidade está configurada" de um pressuposto em prova.
• O ZeroTAM fornece aconselhamento especializado dedicado para a arquitetura de backup, o desenho de isolamento e o planeamento de recuperação de ransomware — a camada humana de que a maioria das empresas precisa para interpretar o que o seu ambiente de backup está realmente a dizer-lhes, e para desenhar um isolamento que sobrevive ao contacto com um incidente real.
• O ZeroPEN testa a sua infraestrutura de backup da forma como um adversário real o faria — visando os planos de gestão, os controlos de acesso e as definições de imutabilidade — e depois executa cenários de restauro reais para validar que consegue recuperar de forma limpa, completa e dentro do RTO declarado, e não apenas que uma tarefa de backup reportou sucesso.

A BackupSec é implementada on-premise, liga-se às suas aplicações de backup através de acesso API só de leitura, e nunca move dados de backup para fora do seu ambiente.

Fale com a BackupSec sobre a postura de segurança dos seus backups →

Pronto para descobrir se os seus próprios backups aguentariam a pressão? Avalie o seu ambiente com a Avaliação Gratuita de Segurança de Backup.