Como proteger dados contra ransomware com backup?

Quem administra infraestrutura em empresas de médio e grande porte já percebeu que a pergunta sobre backup e proteção de dados contra ransomware deixou de ser técnica e passou a ser estratégica. Não se trata mais de escolher a ferramenta mais popular do mercado, mas de entender se as cópias existentes sobreviveriam a um adversário que planeja, com antecedência, exatamente como destruí-las. Em ambientes que processam dados sensíveis e transações via Pix, essa discussão envolve diretoria, segurança da informação e compliance — e não apenas o time de infraestrutura.

Este artigo parte de uma premissa desconfortável, mas necessária: o backup precisa ser tratado como um sistema que será atacado, e não como um cofre que ninguém encontra. Ao longo do texto, você vai encontrar critérios para definir metas de recuperação antes de contratar tecnologia, formas de isolar e tornar cópias imutáveis, testes que simulam o ataque ao próprio repositório e um checklist de maturidade para avaliar em que estágio a sua operação está. Também abordamos os erros de configuração que anulam a imutabilidade e o que a LGPD e as exigências regulatórias brasileiras pedem desse tipo de controle.

Se a sua dúvida é mais imediata — entender o tamanho do prejuízo quando não há cópia confiável —, vale começar por o que acontece com uma empresa que perde os dados para ransomware sem backup. A partir daí, as decisões de arquitetura ficam mais fáceis de justificar internamente.

O que muda no backup quando o inimigo é o ransomware

Backup sempre foi sinônimo de recuperação contra falhas acidentais: um disco que queima, uma exclusão por engano, uma corrupção silenciosa no banco de dados. O ransomware inverte essa lógica porque o adversário estuda sua infraestrutura antes de agir, mapeia onde estão as cópias e tenta destruí-las no mesmo ataque. A pergunta deixa de ser "consigo restaurar?" e passa a ser "consigo restaurar depois que alguém tentou ativamente impedir a restauração?".

Um ataque moderno de ransomware opera em estágios: infecção inicial, reconhecimento interno, escalada de privilégio, exfiltração seletiva e só então a criptografia em massa. Em ambientes financeiros que processam transações via Pix, o tempo entre o primeiro acesso e a detonação pode ser de dias ou semanas — período em que o atacante também localiza o repositório de backup, as credenciais de administração e as rotinas de cópia. Proteger dados contra ransomware exige tratar o backup como um sistema que será atacado, não como um cofre que ninguém encontra.

Na prática, isso muda três decisões centrais: onde as cópias ficam, quem pode apagá-las e como se prova que elas funcionam. A regra 3-2-1 clássica continua sendo o ponto de partida, mas ganha camadas de imutabilidade, isolamento e verificação contínua. Empresas que tratam backup apenas como rotina operacional — e não como controle de segurança — descobrem a diferença apenas durante o incidente, quando o custo da descoberta é mais alto.

Por que o backup tradicional falha contra ransomware

O backup tradicional foi desenhado para um cenário em que a ameaça é aleatória e não intencional. O ransomware é direcionado, paciente e conhece a arquitetura de TI da vítima. Grupos criminosos documentam há anos as configurações padrão de Veeam, Acronis, Commvault, Veritas e de soluções nativas de nuvem, justamente porque sabem que o backup é o último obstáculo entre o ataque e o pagamento do resgate.

Quando o backup falha contra ransomware, raramente é por defeito técnico da ferramenta. O padrão mais comum é o atacante ter acesso legítimo ao repositório usando credenciais que já estavam comprometidas — e a ferramenta, corretamente, executar o comando de exclusão ou criptografia como se viesse de um administrador autorizado. A falha é de arquitetura e de governança de acesso, não de software.

Ataques que miram o próprio repositório de backup

Grupos como LockBit, BlackCat e Akira incorporaram a destruição de backups ao playbook padrão. Antes de criptografar os servidores de produção, o atacante procura por repositórios de backup conectados à rede, consoles de gerenciamento com sessões ativas e contas de serviço com privilégio de exclusão. A ordem típica é: desabilitar o agendamento, apagar os pontos de recuperação existentes e só então executar o ransomware nos dados primários.

Há também a tática de criptografar o próprio catálogo de backup — o índice que diz quais blocos compõem cada máquina virtual ou banco de dados. Sem o catálogo, os arquivos de backup continuam no disco, mas a restauração se torna um processo forense lento e caro. Por isso, repositórios que aceitam comandos de exclusão vindos da mesma rede de produção são considerados, na prática, uma extensão da superfície de ataque.

Credenciais comprometidas e movimentação lateral

A porta de entrada raramente é o servidor de backup. O vetor inicial costuma ser um e-mail de phishing, uma credencial vazada de funcionário ou uma vulnerabilidade em um sistema periférico. A partir desse ponto, o atacante se movimenta lateralmente usando protocolos legítimos — RDP, SMB, WinRM, PowerShell remoto — até alcançar uma conta com privilégio administrativo no domínio ou no tenant Microsoft 365.

Uma vez com privilégio de administrador de domínio, o atacante não precisa "invadir" o backup: ele se autentica nele. Por isso, a proteção efetiva exige separação de credenciais entre o ambiente de produção e o ambiente de backup, com autenticação multifator obrigatória e sem reuso de senhas. A autenticação multifator é um controle básico, mas ainda ausente em uma parcela relevante de ambientes corporativos brasileiros.

Em ambientes Microsoft, o comprometimento do Entra ID (antigo Azure AD) abre caminho para o backup em nuvem também. Contas com papel de administrador global podem alterar políticas de retenção, revogar bloqueios de exclusão e até remover o tenant inteiro. A segurança de identidade com Microsoft Entra ID precisa ser tratada como pré-requisito do backup, não como projeto paralelo.

A regra 3-2-1-1-0 aplicada à realidade brasileira

A regra 3-2-1 original — três cópias, dois tipos de mídia, uma fora do local — evoluiu para o modelo 3-2-1-1-0: três cópias, duas mídias, uma offsite, uma offline ou imutável e zero erros após verificação. O acréscimo dos dois últimos dígitos responde diretamente ao ransomware: a cópia offsite não adianta se estiver acessível pela mesma rede e com as mesmas credenciais; e nenhuma cópia serve se nunca foi testada.

No contexto brasileiro, a regra precisa considerar a realidade de conectividade e de infraestrutura das empresas médias. Muitas operam com links assimétricos, datacenters próprios modestos e equipes enxutas, o que torna tentador manter tudo em um único storage local "bem configurado". Essa concentração é exatamente o que o ransomware explora. A regra 3-2-1-1-0 não é um luxo de grande corporação; é o mínimo para ambientes que processam dados sensíveis e transações financeiras.

Cópia offline, imutável e verificada: o que cada camada resolve

Cada camada da regra resolve uma falha específica. A cópia offline (air gap físico, como fita ou disco desconectado) protege contra ataque lógico, mas não contra furto, incêndio ou falha de mídia. A cópia imutável protege contra exclusão e criptografia durante o período de retenção, mas depende de configuração correta e de credenciais realmente segregadas. A cópia verificada protege contra a pior das descobertas: descobrir, durante o incidente, que o backup estava corrompido há meses.

3 cópias: dado original + backup local + backup remoto, garantindo sobrevivência a falha dupla.
2 mídias: disco e fita, ou disco e object storage, reduzindo risco de falha comum de tecnologia.
1 offsite: cópia fora do prédio, em nuvem ou datacenter remoto, contra desastre físico.
1 imutável/offline: cópia que não pode ser alterada por ninguém durante a janela de retenção.
0 erros: validação automatizada e periódica de que a restauração realmente funciona.

Nenhuma camada sozinha é suficiente. A combinação é o que eleva a probabilidade de recuperação. Um ambiente que mantém três cópias em disco no mesmo rack, por exemplo, cumpre o número da regra mas viola sua intenção — e o ransomware não se importa com a intenção, apenas com a topologia real.

RPO e RTO: como definir metas antes de escolher a tecnologia

RPO (Recovery Point Objective) é a quantidade máxima de dados que a empresa aceita perder, medida em tempo: um RPO de 15 minutos significa que o backup precisa capturar mudanças a cada 15 minutos. RTO (Recovery Time Objective) é o tempo máximo tolerado para voltar a operar após o incidente. Definir esses números antes de escolher a ferramenta inverte a abordagem comum — comprar software e depois descobrir o que ele entrega.

Para uma empresa que processa transações Pix, o RPO tende a ser agressivo: perder 24 horas de lançamentos pode ser inaceitável do ponto de vista regulatório e de conciliação financeira. Isso exige replicação contínua ou snapshots frequentes, o que tem custo. Para dados de arquivo morto ou de marketing, um RPO de 24 horas pode ser perfeitamente adequado. A maturidade está em classificar os dados por criticidade e aplicar metas diferentes — não em tratar tudo com o mesmo nível de proteção.

RPO ≤ 15 min: bancos transacionais, sistemas de pagamento, dados em tempo real.
RPO ≤ 4 h: ERPs, CRMs, sistemas de backoffice que suportam operação diária.
RPO ≤ 24 h: arquivos de departamento, dados de baixa mutação, repositórios documentais.
RTO ≤ 2 h: sistemas críticos com plano de failover ou restauração em nuvem.
RTO ≤ 24 h: sistemas que podem aguardar restauração completa sem parar o negócio.

Com RPO e RTO definidos, a escolha tecnológica se torna consequência: replicação síncrona para RPO próximo de zero, snapshots frequentes para RPO de minutos, backup diário para RPO de horas. Sem essas metas, qualquer ferramenta parece suficiente — até o dia em que a restauração leva 72 horas e o negócio não sobrevive a três dias parado.

Imutabilidade na prática: WORM, object lock e air gap

Imutabilidade é a propriedade que impede que um dado seja alterado, excluído ou criptografado durante um período definido — nem pelo administrador legítimo, nem por um atacante com credenciais roubadas. Ela se materializa de três formas principais: WORM (Write Once, Read Many) em mídia física ou storage, object lock em armazenamento de objetos na nuvem e air gap lógico ou físico que isola a cópia da rede de produção.

O mecanismo técnico varia, mas o princípio é o mesmo: a política de retenção é aplicada no nível do armazenamento, abaixo da camada do software de backup. Um atacante que comprometa o console de backup não consegue emitir comandos de exclusão que o storage imutável simplesmente recusará. É essa separação de camadas que torna a imutabilidade um controle robusto — ela não depende da integridade do software de gerenciamento.

Armazenamento imutável local, em nuvem ou híbrido

No modelo local, appliances de storage com suporte a WORM ou a snapshots imutáveis criam uma área que rejeita comandos de exclusão até o fim da retenção. A vantagem é a velocidade de restauração — os dados estão na LAN, sem depender de link de internet. A desvantagem é que, se o atacante comprometer fisicamente o equipamento ou o firmware, a imutabilidade pode ser contornada. Por isso, o storage local imutável é camada de recuperação rápida, não a única linha de defesa.

No modelo em nuvem, serviços de object storage como Azure Blob Storage com versioning e retenção por tempo, ou buckets S3 com Object Lock, oferecem imutabilidade gerenciada pelo provedor. A estratégia de backup na nuvem ganha escala e isolamento geográfico, mas depende de conectividade e de configuração cuidadosa das políticas de retenção — um bucket com object lock desabilitado é apenas um bucket comum.

O modelo híbrido combina as duas camadas: cópia local imutável para restauração rápida e cópia em nuvem imutável para sobrevivência a desastre local. É o padrão mais adotado em empresas médias e grandes no Brasil, especialmente as que já operam com Azure ou Microsoft 365 e querem consolidar a proteção de dados em um único ecossistema de gestão.

Período de retenção: por quanto tempo manter cópias imutáveis

O período de retenção imutável precisa cobrir a janela em que o ataque pode ser detectado. Ransomware opera com dwell time — o tempo entre a intrusão inicial e a detonação — que em muitos casos documentados supera 30 dias. Se a cópia imutável retém apenas 7 dias, um atacante que entrou há três semanas pode simplesmente aguardar a expiração da retenção e então apagar as cópias antes de criptografar a produção.

Para dados críticos, a prática recomendada é reter cópias imutáveis por no mínimo 30 a 90 dias, com camadas adicionais de retenção mais longa para conformidade. Empresas do setor financeiro no Brasil precisam considerar também exigências regulatórias do Banco Central e da LGPD, que podem impor prazos de guarda específicos para registros de transações e dados pessoais. A gestão de criptografia e proteção de dados precisa alinhar a janela de imutabilidade com esses requisitos legais — não apenas com a conveniência operacional.

7–14 dias: insuficiente para ransomware; cobre apenas erros operacionais recentes.
30 dias: mínimo aceitável para ambientes com detecção madura e monitoramento ativo.
60–90 dias: faixa recomendada para dados críticos e ambientes financeiros.
6–12 meses: retenção para conformidade, auditoria e investigações forenses.

Como testar se o seu backup realmente sobrevive a um ataque

Backup que nunca foi restaurado é uma promessa, não um ativo. A diferença entre ter backup e ter capacidade de recuperação se revela no teste: ambientes maduros executam restaurações de validação em ciclos regulares, documentam o tempo real de cada etapa e tratam qualquer falha como incidente a ser corrigido. A maioria dos ambientes, porém, descobre a falha apenas quando precisa restaurar de verdade.

O teste precisa simular as condições do ataque, não apenas a restauração em condições ideais. Restaurar uma máquina virtual em um ambiente limpo, com o administrador legítimo logado e a rede funcionando, prova pouco sobre a resiliência real. O teste relevante pergunta: e se o atacante tiver apagado os backups recentes? E se o catálogo estiver comprometido? E se a única cópia disponível for a de 45 dias atrás?

Simulações de recuperação e validação de integridade

Uma simulação eficaz começa pelo cenário mais provável, não pelo mais confortável. O exercício de mesa (tabletop) define um incidente hipotético — por exemplo, "o repositório local foi criptografado e a cópia em nuvem está íntegra" — e a equipe executa a recuperação de ponta a ponta, cronometrando cada fase: identificação do ponto de restauração, restauração do catálogo, restauração dos dados, validação de integridade e retomada dos serviços.

A validação de integridade automatizada complementa o exercício: checksums, verificação de blocos e restaurações de amostra em sandbox detectam corrupção silenciosa antes que ela vire emergência. Ferramentas de backup modernas oferecem verificação programada, mas a configuração padrão muitas vezes a desabilita por impacto de performance. Em ambientes com dados sensíveis, esse custo de performance é investimento, não desperdício.

Métricas que provam a resiliência do ambiente

Resiliência mensurável é aquela que se expressa em números coletados antes do incidente. As métricas mais úteis são: tempo real de restauração (medido em exercício, não estimado em planilha), taxa de sucesso das restaurações de teste, idade do ponto de restauração mais recente disponível e tempo de detecção de falhas de backup. Esses indicadores compõem um painel que a liderança de TI pode acompanhar mensalmente.

Tempo real de restauração: medido em simulação, comparado ao RTO definido.
Taxa de sucesso de restauração: percentual de testes que concluíram sem erro nos últimos 90 dias.
Idade do último backup verificável: distância entre agora e o ponto de restauração mais recente e íntegro.
Tempo médio de detecção de falha: intervalo entre a falha do job de backup e sua identificação.
Cobertura de ativos: percentual de servidores, bancos e endpoints incluídos na política de backup.

Quando essas métricas não existem, a decisão de investir em melhoria se torna política, baseada em percepção de risco. Quando existem, a conversa com a diretoria muda de tom: em vez de "precisamos de mais orçamento para backup", vira "nosso tempo de restauração é 14 horas e o RTO aceitável é 4; aqui está o plano para fechar a lacuna".

Protegendo o Microsoft 365, bancos de dados e endpoints

O Microsoft 365 é uma das maiores lacunas de proteção em empresas brasileiras. A crença de que "está na nuvem, logo está protegido" ignora que a Microsoft opera com modelo de responsabilidade compartilhada. O backup do Microsoft 365 é necessário justamente porque as políticas nativas de retenção não foram desenhadas para recuperação granular contra ameaças.

A proteção do Microsoft 365 exige cobertura de Exchange Online, SharePoint, OneDrive e Teams, com retenção que permita restaurar mensagens, arquivos e permissões em granularidade fina. Em ataques que comprometem a conta de um executivo e criptografam milhares de arquivos no OneDrive, a restauração em lote precisa ser rápida e seletiva — restaurar tudo do zero pode ser tão disruptivo quanto o próprio ataque. A resposta a incidentes no Microsoft 365 depende de backups que existam fora do tenant comprometido.

Bancos de dados exigem atenção específica porque são o alvo preferencial em ataques a sistemas financeiros. SQL Server, Oracle, PostgreSQL e bancos em Azure precisam de backups com consistência transacional, logs em replicação contínua e snapshots imutáveis. A restauração de um banco corrompido por ransomware não é apenas "voltar o arquivo": envolve validar a integridade das transações, reconciliar com sistemas externos e garantir que nenhuma transação Pix foi perdida ou duplicada no processo.

Endpoints — notebooks e desktops de funcionários — são o vetor de entrada mais comum e a camada menos protegida. O ransomware que entra por um notebook comprometido pode se propagar para compartilhamentos de rede e, de lá, para os servidores. Políticas de backup de endpoints com retenção imutável e isolamento do repositório reduzem o impacto do vetor inicial. A prevenção de phishing no Microsoft 365 atua na porta de entrada, mas o backup de endpoints é a rede de segurança quando a prevenção falha — e ela falha.

Erros que anulam a proteção do backup

O erro mais caro é a falsa sensação de proteção: o ambiente tem backup, tem nuvem, tem imutabilidade configurada — mas uma falha silenciosa anula tudo. Identificar esses erros antes do incidente é mais barato do que descobri-los durante a negociação com o atacante. A lista abaixo reúne os padrões mais recorrentes em ambientes corporativos brasileiros.

Credenciais de backup no mesmo domínio da produção: o atacante que domina o AD domina o backup.
Repositório imutável com retenção curta demais: o atacante espera a janela expirar e apaga as cópias.
Backup em nuvem com as mesmas credenciais do tenant: o comprometimento do Entra ID alcança a cópia offsite.
Nenhum teste de restauração em meses: backup corrompido só é descoberto quando necessário.
Catálogo de backup no mesmo volume dos dados: a criptografia do atacante destrói o índice junto com o backup.
Política de retenção alterável pelo administrador de backup: o atacante com essa conta reduz a retenção para zero e apaga tudo.
Endpoints fora da política de backup: o vetor de entrada mais comum fica sem cobertura.
Backup apenas local, sem cópia offsite: um incêndio, inundação ou invasão física elimina todas as cópias.

Cada um desses erros é corrigível com mudança de arquitetura ou de processo, não necessariamente com compra de nova ferramenta. A escolha de uma consultoria de segurança qualificada começa pela capacidade de auditar o ambiente existente e apontar essas falhas estruturais — antes de propor qualquer investimento adicional.

Checklist de maturidade em backup contra ransomware

Maturidade não é binária — é um gradiente que evolui conforme a criticidade dos dados e o apetite de risco da empresa. O checklist abaixo organiza os controles em estágios progressivos, permitindo que cada organização identifique onde está e qual é o próximo passo realista. Empresas do setor financeiro ou que processam dados sensíveis deveriam mirar, no mínimo, o estágio intermediário.

Estágio inicial: fundamentos

Backup automatizado de servidores críticos com agendamento diário.
Uma cópia offsite ou em nuvem, separada fisicamente do datacenter principal.
Teste de restauração executado pelo menos uma vez por trimestre.
Senhas de backup diferentes das senhas de produção.
Inventário atualizado de quais ativos estão cobertos pela política.

Estágio intermediário: imutabilidade e segregação

Repositório imutável com retenção mínima de 30 dias para dados críticos.
Credenciais de backup em domínio separado ou com autenticação dedicada.
Autenticação multifator obrigatória para qualquer acesso ao console de backup.
Validação automatizada de integridade com alertas para falhas silenciosas.
RPO e RTO documentados por classe de dado, não por achismo.
Backup do Microsoft 365 cobrindo Exchange, SharePoint, OneDrive e Teams.

Estágio avançado: resiliência comprovada

Simulação de ataque ao backup executada semestralmente, com métricas documentadas.
Air gap físico ou lógico para uma cópia crítica, além da imutabilidade em nuvem.
Plano de resposta a ransomware integrado ao plano de recuperação de desastres.
Revisão periódica de acessos e privilégios ao ambiente de backup.
Conformidade documentada com LGPD e requisitos regulatórios setoriais.
Métricas de resiliência acompanhadas mensalmente pela liderança de TI.

O checklist não é um fim em si mesmo: ele serve para transformar a conversa sobre backup de "temos ou não temos" em "qual é a próxima lacuna a fechar". A consultoria de cibersegurança para o setor financeiro parte desse tipo de diagnóstico para priorizar investimentos com base em risco real, não em modismo tecnológico.

Perguntas frequentes sobre backup e ransomware

Backup em nuvem é seguro contra ransomware?

Backup em nuvem é seguro quando configurado com imutabilidade, credenciais segregadas e retenção adequada. Sem object lock ou recurso equivalente, a cópia em nuvem pode ser excluída ou criptografada pelo atacante que comprometer as credenciais do tenant. A nuvem não é proteção automática; é uma camada que precisa ser configurada corretamente.

Quanto tempo devo manter cópias imutáveis?

O mínimo recomendado para dados críticos é 30 dias, com faixa ideal de 60 a 90 dias para ambientes financeiros ou que processam dados sensíveis. O período precisa superar o tempo típico de dwell time do ransomware — o intervalo entre a intrusão e a detonação — para que o atacante não consiga aguardar a expiração da retenção e então apagar as cópias.

O backup do Microsoft 365 nativo é suficiente?

Não. As políticas nativas de retenção do Microsoft 365 protegem contra exclusão acidental em cenários limitados, mas não oferecem recuperação granular robusta contra ransomware, comprometimento de conta ou exclusão em massa maliciosa. Um backup de terceiros, armazenado fora do tenant, é necessário para ambientes que dependem de e-mail, SharePoint e OneDrive para operar.

Com que frequência devo testar a restauração?

O mínimo aceitável é trimestral, com teste completo de um cenário realista. Ambientes maduros executam validação automatizada semanal ou mensal e simulações completas de recuperação a cada seis meses. A frequência ideal depende da taxa de mudança do ambiente: quanto mais rápido a infraestrutura muda, mais frequente precisa ser o teste.

Air gap físico ainda é necessário se tenho backup imutável em nuvem?

Depende da criticidade dos dados e do apetite de risco. A imutabilidade em nuvem protege contra exclusão lógica, mas não contra comprometimento total do tenant ou falha do provedor. O air gap físico — fita ou disco desconectado — adiciona uma camada que nenhum atacante remoto alcança. Para dados críticos, a combinação das duas camadas é a prática recomendada.

Quanto custa implementar backup imutável?

O custo varia amplamente conforme o volume de dados, a retenção desejada e a infraestrutura existente. Empresas que já operam com Azure ou storage compatível com WORM podem implementar imutabilidade com custo incremental relativamente baixo. O investimento precisa ser comparado ao custo de um incidente: horas de indisponibilidade, perda de dados, notificação à ANPD e dano reputacional — valores que costumam superar em ordens de grandeza o custo da proteção.