Quem decide sobre infraestrutura de TI em empresas de médio e grande porte já percebeu que o backup tradicional deixou de ser suficiente. O ransomware moderno não ataca apenas os servidores de produção: ele vai primeiro atrás das cópias de segurança, das credenciais de serviço e do console de administração. Quando isso acontece, a organização descobre tarde demais que tinha backup, mas não tinha recuperação. É nesse ponto que o backup anti ransomware para empresas deixa de ser um item de checklist e passa a ser uma decisão de arquitetura.
Este artigo foi escrito para times de tecnologia, segurança da informação e compliance que precisam avaliar, comparar e contratar uma solução com critérios técnicos verificáveis — não com base em listas genéricas de boas práticas. Ao longo do texto, você encontra os elementos que definem uma proteção real contra ransomware: imutabilidade e WORM, air gap lógico, separação de credenciais, criptografia com gestão de chaves independente, detecção de anomalia e definição mensurável de RTO e RPO por sistema.
Também são abordados os pontos que costumam ficar de fora das propostas comerciais: perguntas contratuais e de SLA a fazer ao fornecedor, roteiro de prova de conceito com critérios de aprovação e teste de restauração real, custo total de propriedade comparado ao custo de um dia de parada e evidências exigidas em resposta a incidente e notificação à ANPD. O objetivo é dar ao decisor base para escolher com critério, reduzir risco e manter conformidade.
O que é backup anti ransomware e por que ele é diferente do backup comum
Backup anti ransomware é uma arquitetura de proteção de dados projetada para continuar íntegra mesmo quando o ambiente de produção foi totalmente comprometido. Diferente do backup convencional — que existe para recuperar arquivos apagados ou corrigir falhas pontuais —, ele parte da premissa de que o atacante conhece a infraestrutura, tem acesso a credenciais privilegiadas e tentará destruir as cópias antes de executar a criptografia. A diferença central não está no software que copia os dados, mas na forma como as cópias são isoladas do plano de controle que administra a produção.
Em um ambiente corporativo com transações Pix, dados cadastrais e informações reguladas, a perda do backup equivale à perda da capacidade de negociação com o atacante. Sem uma cópia íntegra, a organização fica refém do pagamento de resgate — e ainda assim não há garantia de que a chave de descriptografia será entregue ou funcionará. O backup anti ransomware reduz esse cenário ao garantir que, mesmo com o domínio comprometido, exista uma versão dos dados que o atacante não consegue alcançar, alterar ou apagar.
Como o ransomware moderno ataca primeiro as cópias de backup
Grupos de ransomware atuais não disparam a criptografia assim que entram na rede. O padrão observado em incidentes desde 2023 é um período de reconhecimento que dura dias ou semanas, durante o qual o invasor mapeia a topologia, identifica o software de backup, localiza o repositório e descobre as credenciais da conta de serviço que executa as rotinas de cópia. O objetivo é claro: neutralizar a recuperação antes de tornar a extorsão visível.
Os vetores de ataque ao backup incluem o console de administração acessível com a mesma senha do administrador de domínio, tokens de API armazenados em scripts sem proteção, snapshots em storage conectado à rede corporativa e repositórios de destino que aceitam comandos de exclusão sem segundo fator. Há registros de incidentes em que o atacante alterou a política de retenção para zero, forçou a expiração das cópias e só então executou o ransomware nos servidores de produção. Por isso, a pergunta correta não é "o backup roda todos os dias?", mas "o que acontece com o backup se o domínio inteiro for comprometido?".
Backup tradicional, backup imutável e air gap: o que muda na prática
O backup tradicional grava cópias em um destino que aceita sobrescrita, exclusão e alteração por qualquer usuário com privilégio suficiente — e esse privilégio é exatamente o que o ransomware sequestra. O backup imutável, por outro lado, grava os dados em um estado WORM (write once, read many): durante o período de retenção definido, nenhuma operação de modificação ou exclusão é aceita, nem mesmo pelo administrador do sistema. O air gap adiciona uma camada física ou lógica de desconexão entre a produção e a cópia.
Na prática, as três abordagens se diferenciam pelo que resiste a um ataque. Uma cópia tradicional resiste a falha de disco, mas não a credencial roubada. Uma cópia imutável resiste à tentativa de exclusão via console, mas pode ficar inacessível se a conta de administração do repositório for comprometida e usada para desligar o serviço. O air gap lógico — com credenciais separadas, rede isolada e janelas de sincronização controladas — resiste ao comprometimento do plano de controle, porque o atacante não alcança o destino nem com as credenciais da produção. A combinação dos três é o que caracteriza uma arquitetura anti ransomware de fato.
Critérios técnicos para avaliar uma solução de backup anti ransomware
Comparar soluções de backup anti ransomware exige ir além do preço por terabyte e da lista de integrações. Os critérios que determinam se a cópia sobreviverá a um ataque real são técnicos e mensuráveis: imutabilidade, isolamento de credenciais, criptografia, detecção de anomalia e tempos de recuperação. Cada um deles precisa ser verificado em contrato, em teste e na arquitetura proposta — não apenas no material comercial do fornecedor.
Imutabilidade e WORM: a cópia que o atacante não consegue apagar
Imutabilidade é a capacidade de marcar um conjunto de dados como não alterável por um período definido. Em storage compatível com object lock, como buckets S3 com retenção WORM, nem a conta raiz do provedor consegue remover o objeto antes do prazo. Em soluções como Acronis Cyber Protect, a imutabilidade é aplicada no destino de armazenamento e impede que comandos de exclusão — mesmo os emitidos por um console comprometido — afetem as cópias retidas.
O ponto de atenção é que imutabilidade não é um atributo mágico do software de backup: ela depende do storage de destino suportar o recurso. Um repositório local em disco NTFS não oferece WORM real, apenas permissões de arquivo que um atacante com privilégio administrativo consegue contornar. Ao avaliar propostas, o decisor deve perguntar em qual camada a imutabilidade é aplicada, por quanto tempo ela pode ser configurada e se existe alguma forma administrativa de revogá-la antes do prazo.
Air gap lógico, cópias offline e separação de credenciais
Air gap lógico significa que o repositório de backup não participa do mesmo domínio, da mesma floresta do Active Directory nem do mesmo plano de autenticação da produção. A conta que administra o backup não pode ser a mesma que administra os servidores; idealmente, ela reside em um diretório separado, com MFA obrigatório e sem relação de confiança com o domínio corporativo. Isso impede que o roubo de uma credencial de administrador de domínio dê acesso ao repositório.
Cópias offline — em fita, disco removível ou storage que só é ligado durante a janela de cópia — adicionam um isolamento físico que nenhuma credencial remota alcança. O custo operacional é maior, mas para dados críticos de ambientes financeiros, a prática de manter uma cópia offline semanal ou mensal é uma das defesas mais robustas contra ransomware. O equilíbrio entre air gap lógico e físico depende do RPO aceitável para cada sistema.
Criptografia em trânsito e em repouso, gestão de chaves e MFA no console
Os dados de backup precisam ser criptografados em trânsito com TLS 1.2 ou superior e em repouso com AES-256. Mas o fator que diferencia uma solução madura é a gestão das chaves: se a chave de criptografia do repositório estiver armazenada no mesmo cofre de senhas que o atacante comprometeu, a criptografia em repouso perde o valor. Chaves gerenciadas em HSM, cofre separado ou com controle de acesso independente reduzem esse risco.
O console de administração do backup precisa exigir MFA para todas as contas, sem exceção para contas de serviço. Também é recomendável que o console registre cada login, cada alteração de política e cada tentativa de restauração em trilha imutável. Em ambientes Microsoft, a integração com Microsoft Entra ID e políticas de acesso condicional permite bloquear logins de localizações incomuns ou dispositivos não gerenciados no console de backup, fechando um vetor comum de ataque.
Detecção de anomalia e alerta de alteração em massa de arquivos
Backup sem detecção de anomalia é uma cópia cega: ela registra fielmente a criptografia do ransomware como se fosse uma alteração legítima, corrompendo as versões retidas antes que alguém perceba. Soluções com detecção de anomalia monitoram a taxa de alteração de arquivos, a entropia dos dados e padrões de renomeação em massa, emitindo alertas quando um comportamento compatível com criptografia é identificado.
Esse recurso permite interromper a rotina de backup antes que as cópias boas sejam sobrescritas por versões criptografadas. Em uma arquitetura com retenção versionada, a detecção precoce preserva os pontos de restauração íntegros. Vale verificar se a detecção é baseada em heurística no agente, em análise no repositório ou em ambos, e se o alerta é integrado ao SIEM ou ao canal de resposta a incidentes da empresa.
RTO e RPO reais: quanto tempo sua operação aguenta parada
RTO (Recovery Time Objective) é o tempo máximo aceitável entre o incidente e a restauração do serviço. RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa aceita perder, medida em tempo entre o último backup íntegro e o incidente. Esses dois números precisam ser definidos por sistema antes de escolher a solução — um banco de dados de transações Pix pode exigir RPO de minutos, enquanto um file server de documentos internos tolera RPO de 24 horas.
- RPO de 15 minutos: exige replicação contínua ou snapshot frequente, com custo mais alto
- RPO de 4 horas: compatível com backups incrementais programados ao longo do dia
- RPO de 24 horas: backup diário noturno, suficiente para dados de baixa criticidade
- RTO de 1 hora: requer restauração em infraestrutura alternativa ou virtualização de emergência
- RTO de 8 horas: permite restauração em hardware original após contenção do incidente
O erro mais comum é aceitar o RTO e o RPO genéricos que o fornecedor promete no contrato sem testar se são alcançáveis no ambiente real. Um RTO de 4 horas não significa nada se a restauração de um banco de 5 TB leva 14 horas na prática. A única forma de validar é medir em exercício de restauração documentado, com o ambiente de produção simulado.
Ransomware não é o único cenário: o que mais o backup precisa cobrir
Embora o ransomware domine as manchetes, a maioria dos incidentes de perda de dados em empresas ainda vem de causas não maliciosas. Uma arquitetura de backup que só se protege contra criptografia maliciosa deixa lacunas para exclusão acidental, conta comprometida, sabotagem interna, falha de hardware e corrupção silenciosa. O backup anti ransomware precisa ser, antes de tudo, um backup completo.
Exclusão acidental, conta comprometida e sabotagem interna
Um funcionário que apaga uma pasta inteira por engano, um ex-colaborador que mantém acesso a um compartilhamento ou um atacante que usa uma conta legítima para exfiltrar e apagar dados são cenários que não envolvem ransomware, mas exigem as mesmas defesas: retenção versionada, imutabilidade e trilha de auditoria. A diferença é que, nesses casos, a cópia precisa permitir restauração granular de itens específicos, não apenas recuperação completa do servidor.
A separação de credenciais também protege contra o insider: se o administrador do backup é uma pessoa diferente do administrador da produção, a sabotagem exige conluio de dois papéis, o que reduz drasticamente a probabilidade. Para ambientes com dados sensíveis e transações financeiras, a revisão periódica de quem tem acesso ao repositório de backup é tão importante quanto a revisão de acesso à produção.
Falha de hardware, corrupção de banco de dados e erro de aplicação
Discos falham, controladoras de storage queimam, uma atualização mal aplicada corrompe um banco de dados inteiro. O backup precisa cobrir esses cenários com a mesma seriedade com que cobre o ransomware, e isso significa testar a restauração de bancos como SQL Server, Oracle ou PostgreSQL em cenários de corrupção lógica — não apenas de perda física do volume. A corrupção lógica é insidiosa porque o backup pode estar copiando dados já corrompidos há semanas sem que ninguém perceba.
Para bancos de dados transacionais, o backup precisa ser consistente com a aplicação — snapshots sem quiescência podem gerar cópias que não sobem após a restauração. Soluções com integração nativa a VSS no Windows ou com agentes específicos para cada banco reduzem esse risco. A verificação periódica de integridade das cópias, com restauração automatizada em ambiente de teste, é o único controle que detecta corrupção antes do incidente.
Backup de Microsoft 365, Google Workspace e ambientes virtualizados
Existe uma crença persistente de que dados em SaaS como Microsoft 365 e Google Workspace não precisam de backup, porque o provedor "já cuida disso". A realidade é que a responsabilidade do provedor se limita à disponibilidade da plataforma, não à proteção contra exclusão, corrupção ou conta comprometida dentro do tenant. A lixeira do SharePoint e do OneDrive tem retenção limitada, e a exclusão definitiva por um administrador comprometido não é recuperável pelos recursos nativos. Para entender essa distinção, vale consultar quando o backup de Microsoft 365 é necessário.
Ambientes virtualizados em VMware ou Hyper-V exigem backup com integração a hypervisor para captura consistente das VMs, além de restauração granular de arquivos dentro da VM sem precisar subir a máquina inteira. Para dados de Teams e SharePoint, a proteção de sites, bibliotecas e conversas exige solução específica de backup de SaaS, com retenção própria e restauração item a item. A cobertura precisa ser mapeada por workload, não por uma promessa genérica de "backup completo".
LGPD, soberania de dados e o peso de escolher data center no Brasil
Para empresas brasileiras que lidam com dados pessoais e transações financeiras, a localização do armazenamento de backup não é um detalhe técnico — é uma decisão de conformidade. A LGPD não proíbe transferência internacional de dados, mas exige que ela ocorra com base legal adequada e com garantias contratuais. Em setores regulados, como o financeiro, normas do Banco Central adicionam requisitos específicos de armazenamento e comunicação de incidentes.
Onde os dados ficam armazenados e quem tem acesso a eles
Um repositório de backup em data center no Brasil reduz a complexidade de conformidade com a LGPD e com regulações setoriais, além de diminuir a latência para restauração em cenários de desastre. Mas a localização geográfica não é suficiente: é preciso verificar quem tem acesso operacional aos dados, se o provedor de nuvem é submetido a leis estrangeiras que possam obrigar a entrega de informações e se existe criptografia com chave controlada pelo cliente.
Para ambientes que processam Pix e dados bancários, a Resolução CMN nº 4.893 e normas complementares do Banco Central impõem requisitos de segurança cibernética e de contratação de serviços de nuvem que devem ser observados na escolha do repositório de backup. O contrato com o fornecedor precisa prever onde os dados residem, como são segregados e o que acontece com as cópias em caso de encerramento do contrato.
Retenção, trilha de auditoria e evidências para resposta a incidentes
Em um incidente de ransomware, a trilha de auditoria do backup é uma das evidências mais valiosas para a resposta e para a eventual notificação à ANPD. Ela mostra o que foi alterado, quando, por qual conta e a partir de qual endereço — elementos que ajudam a dimensionar o incidente e a cumprir o prazo de comunicação exigido pela regulação. Uma solução que não registra esses eventos de forma imutável compromete a capacidade de defesa jurídica e regulatória da empresa.
A política de retenção precisa estar alinhada com obrigações legais e contratuais: dados de transações financeiras podem exigir retenção de anos, enquanto dados de funcionários demitidos devem ser eliminados conforme a LGPD. O backup não pode ser o depósito eterno que impede o atendimento a pedidos de eliminação de dados pessoais — é necessário que a solução permita expurgos seletivos sem quebrar a imutabilidade das demais cópias. Esse equilíbrio entre retenção para segurança e eliminação para conformidade é um critério técnico que poucas soluções endereçam bem.
Perguntas para fazer ao fornecedor antes de assinar
A proposta comercial raramente responde às perguntas que importam em um incidente real. Antes de assinar contrato, o decisor de TI deve conduzir uma sessão técnica com o fornecedor e registrar as respostas por escrito. As perguntas abaixo separam fornecedores que entregam arquitetura anti ransomware de fornecedores que apenas vendem licenças de backup.
Como é feito o teste de restauração e com que frequência
Pergunte se o fornecedor executa testes de restauração periódicos e se eles estão inclusos no contrato ou são cobrados à parte. Um teste válido restaura dados reais em ambiente isolado, valida a integridade da aplicação e documenta o tempo medido — não basta um relatório automático de "verificação de backup". A frequência mínima recomendada é mensal para sistemas críticos e trimestral para os demais.
Exija que o teste cubra os cenários que importam: restauração granular de um e-mail do Microsoft 365, restauração de um banco de dados SQL com consistência transacional e restauração completa de uma VM em hardware diferente. Se o fornecedor nunca executou uma restauração completa em ambiente de cliente, trate isso como sinal de alerta. A proteção contra ransomware com backup só se comprova na restauração, não na cópia.
O que está incluso no suporte e qual o SLA de recuperação
O suporte em um incidente ativo é diferente do suporte em operação normal. Pergunte qual é o tempo de resposta garantido quando há um ransomware em curso, se o fornecedor disponibiliza engenheiro dedicado durante a recuperação e se o SLA prevê penalidade em caso de descumprimento. Um SLA de "melhor esforço" não é aceitável para sistemas que sustentam transações financeiras.
- Tempo de resposta em incidente: quanto tempo até um técnico sênior entrar na chamada
- Disponibilidade do suporte: 24x7 ou apenas horário comercial
- Escalonamento: quem assume quando o primeiro nível não resolve
- Penalidades: o que o fornecedor paga se o SLA não for cumprido
- Retrospectiva: o fornecedor entrega relatório pós-incidente com causa raiz
Também é relevante saber se o suporte cobre apenas o software de backup ou se inclui auxílio na reconstrução do ambiente — reconfiguração de domínio, restauração do Active Directory e validação de que o ambiente está limpo antes de religar a produção. Em um incidente real, a restauração dos dados é apenas metade do trabalho.
Modelo de cobrança: capacidade, licença por workload ou por consumo
Os modelos de cobrança variam entre licença por terabyte protegido, por workload (cada VM, cada banco, cada usuário de SaaS) ou por consumo de armazenamento no repositório. Cada modelo tem implicações de custo total diferentes conforme o crescimento dos dados. O modelo por terabyte protegido tende a ser previsível, mas pode encarecer ambientes com muitos dados pouco alterados; o modelo por consumo pode gerar surpresas quando a retenção aumenta.
Peça uma simulação de custo para três cenários: crescimento de 30% ao ano, aumento de retenção de 30 para 90 dias e adição de um novo workload (como backup de Microsoft 365 para 500 usuários). A resposta revela se o modelo é transparente ou se esconde custos em taxas de saída de dados, restauração cobrada à parte ou armazenamento de versões antigas. O custo do backup deve ser comparado ao custo de um dia de parada — para muitas operações, o valor de um único incidente supera anos de contrato de backup.
Erros que anulam o investimento em backup anti ransomware
Mesmo com uma solução tecnicamente adequada, erros de arquitetura e de operação podem tornar o investimento inútil no momento do ataque. Esses erros são recorrentes em ambientes corporativos e geralmente só aparecem quando o backup é chamado a funcionar de verdade.
Backup conectado ao domínio e com as mesmas credenciais do ambiente
O erro mais grave — e mais comum — é instalar o servidor de backup dentro do mesmo domínio do Active Directory que protege a produção, usando a mesma conta de administrador para ambos. Quando o atacante compromete o domínio, ele ganha acesso ao backup no mesmo movimento. A correção é estrutural: repositório fora do domínio, credenciais separadas, MFA obrigatório e nenhuma relação de confiança entre os dois planos de controle.
Essa separação precisa ser verificada na prática, não apenas no desenho. Um teste simples é simular o comprometimento da conta de administrador de domínio e verificar se, com ela, é possível acessar o console de backup, alterar políticas ou apagar cópias. Se a resposta for sim, a arquitetura não é anti ransomware, independentemente do que o material do fornecedor diga.
Nunca testar a restauração até precisar dela de verdade
Backup que nunca foi restaurado é uma promessa, não uma proteção. Fitas ilegíveis, snapshots corrompidos, agentes que pararam de rodar silenciosamente, políticas de retenção que expiraram antes do esperado — tudo isso só aparece no teste. Empresas que descobrem esses problemas durante um incidente real enfrentam o pior cenário: o atacante já criptografou a produção e a cópia que deveria salvar a operação não funciona.
O teste de restauração precisa ser automatizado, periódico e documentado. Algumas soluções oferecem restauração de verificação em sandbox, que sobe as VMs em ambiente isolado, valida o boot e executa checks básicos de integridade. Isso reduz o custo operacional do teste e aumenta a frequência com que ele é executado. O relatório de cada teste deve ser arquivado como evidência de que o controle funciona.
Escolher pelo preço por TB e ignorar RTO, suporte e localização dos dados
O preço por terabyte é a métrica mais fácil de comparar e a que menos diz sobre o valor da solução. Um fornecedor barato pode ter repositório em data center fora do Brasil, suporte apenas em horário comercial, RTO de dias em vez de horas e nenhuma imutabilidade real. O custo total de propriedade inclui o tempo de recuperação, o custo regulatório da localização dos dados e o risco de não ter suporte adequado durante um incidente.
Uma análise honesta compara o custo anual do backup com o custo estimado de um dia de indisponibilidade — que, para operações com transações Pix, pode envolver perda de receita, multas regulatórias, dano reputacional e custos de notificação. Nessa equação, a diferença de preço entre fornecedores frequentemente se torna irrelevante diante do custo de uma recuperação lenta ou de uma cópia que não restaura. Para médias empresas, vale consultar critérios de escolha de backup em nuvem antes de decidir apenas por preço.
Checklist de decisão: como comparar propostas lado a lado
Com critérios técnicos definidos, a comparação entre fornecedores deixa de ser subjetiva. Uma matriz de avaliação com pesos por criticidade do ambiente permite ranquear propostas com base no que importa para a operação, não no que o vendedor destacou na apresentação. E a prova de conceito transforma promessas comerciais em evidências mensuráveis antes do contrato.
Matriz de avaliação com pesos por criticidade do seu ambiente
A matriz começa com a classificação dos sistemas por criticidade: transacionais (Pix, banco de dados de produção), operacionais (ERP, e-mail, file server) e administrativos (documentos internos, arquivos de baixa sensibilidade). Cada critério recebe um peso diferente conforme a criticidade. Para sistemas transacionais, RTO e imutabilidade pesam mais; para administrativos, custo e simplicidade podem ter peso maior.
- Imutabilidade real no destino: peso 20% para transacionais, 10% para administrativos
- RTO medido em teste: peso 25% para transacionais, 10% para administrativos
- RPO alcançável: peso 20% para transacionais, 15% para administrativos
- Localização do data center no Brasil: peso 15% uniforme para dados pessoais
- Custo total em 3 anos: peso 10% para transacionais, 30% para administrativos
- SLA de suporte em incidente: peso 10% uniforme
Cada fornecedor recebe nota de 1 a 5 em cada critério, multiplicada pelo peso, gerando um score final comparável. A matriz não elimina o julgamento técnico, mas o torna explícito e auditável — o que é especialmente útil quando a decisão precisa ser justificada para diretoria ou comitê de compliance. Para ambientes financeiros, a escolha de consultoria de cibersegurança deve seguir o mesmo rigor de critérios ponderados.
Prova de conceito: o que exigir antes de fechar contrato
A prova de conceito (PoC) é a etapa que separa a decisão baseada em evidência da decisão baseada em apresentação. Defina antes os critérios de aprovação: restauração de um banco de dados de produção em tempo medido, restauração granular de um e-mail e de um arquivo de SharePoint, simulação de tentativa de exclusão das cópias com credencial comprometida e verificação de que a imutabilidade bloqueou a operação.
A PoC deve incluir um teste de ataque simulado ao console de backup: tente apagar as cópias usando a conta de administrador do domínio de produção e registre o resultado. Se a solução permitir a exclusão, ela não atende ao requisito central de backup anti ransomware. Também exija a documentação da arquitetura proposta, com a localização dos repositórios, a gestão de chaves e o fluxo de credenciais. A PoC deve envolver a equipe de segurança, não apenas a de infraestrutura. Ao final, a decisão de contratação estará apoiada em evidências técnicas — o que reduz o risco de descobrir, durante um incidente real, que o backup não protege contra aquilo que justificou a compra.
