Atualizado em
Ter backup não é o mesmo que ter backup seguro. A maioria das empresas descobre essa diferença no pior momento possível — durante um ataque de ransomware, quando o criminoso apaga ou criptografa as próprias cópias de segurança antes de exigir o resgate.
Por que o backup costuma ser o elo mais fraco
Imagine que você passa anos construindo uma infraestrutura de segurança sólida: firewall bem configurado, EDR nos endpoints, políticas de acesso restritivas, MFA em tudo. E aí um atacante entra pela conta de um administrador comprometida, sobe os privilégios e, antes de acionar o ransomware, passa três semanas mapeando silenciosamente o ambiente — incluindo onde ficam os backups.
Na hora H, ele criptografa os dados de produção e os backups ao mesmo tempo. Ou simplesmente apaga as cópias de segurança. A empresa descobre que tem backup de tudo, mas não tem como restaurar nada.
Esse cenário não é ficção. É o padrão de ataque de grupos de ransomware sofisticados como LockBit, BlackCat e Cl0p. E ele funciona porque backup é historicamente tratado como processo de TI operacional, não como ativo de segurança. O mesmo administrador que gerencia a produção também gerencia o backup. As credenciais de acesso são as mesmas. A rede é a mesma.
O backup seguro exige uma mudança de mentalidade: a cópia de segurança precisa ser protegida como se a produção já estivesse comprometida.
Os 4 requisitos para um backup realmente seguro
1. Criptografia — em trânsito e em repouso
O dado precisa estar criptografado desde o momento em que sai do sistema de origem até o destino final, e precisa permanecer criptografado no destino. Isso parece óbvio, mas muitas soluções de backup mais antigas transmitem em claro ou armazenam sem criptografia por padrão.
O ponto crítico aqui é o gerenciamento das chaves de criptografia. Se a chave está armazenada no mesmo sistema que os dados, a proteção é parcial. O ideal é gerenciamento de chaves externo (HSM ou KMS separado), com controle de quem pode acessar a chave separado de quem acessa o backup.
2. Imutabilidade — o dado que não pode ser apagado
Imutabilidade significa que, depois de gravado, o backup não pode ser modificado ou apagado por nenhum processo ou usuário durante um período definido. Nem pelo administrador de TI. Nem pelo fornecedor de backup. Nem por um atacante com acesso root.
Tecnicamente, isso é implementado via Object Lock em storage S3 ou compatível, com política WORM (Write Once, Read Many). Você define uma janela de retenção — digamos, 30 dias — e nenhum arquivo gravado nesse período pode ser removido antes do prazo.
A imutabilidade é a proteção mais efetiva contra ransomware que tenta apagar backups. O atacante pode ter credenciais de administrador e ainda assim não consegue tocar nos arquivos de backup dentro da janela protegida.
3. Controle de acesso separado — credenciais diferentes, pessoas diferentes
As credenciais de acesso ao backup precisam ser completamente diferentes das credenciais de produção. Esse é o requisito mais fácil de entender e o mais ignorado na prática.
Na prática, significa:
- Contas de serviço dedicadas exclusivamente ao sistema de backup, sem reuso de credenciais de produção
- MFA obrigatório para qualquer acesso à console de administração do backup
- Princípio de menor privilégio: a conta que grava backups não pode apagá-los; a conta que restaura não pode configurar políticas
- Separação de funções: se possível, a pessoa que administra o backup não é a mesma que administra os servidores de produção
- Logs de acesso ao sistema de backup com alertas para qualquer acesso fora do padrão
O objetivo é garantir que comprometer as credenciais de produção não automaticamente comprometa os backups. Estruturar isso corretamente é um exercício de gestão de identidade e acesso (IAM), não apenas de configuração do software de backup.
4. Offsite — cópia em local fisicamente separado
A regra 3-2-1 ainda é o referencial mais sólido do setor: 3 cópias dos dados, em 2 tipos de mídia diferentes, com 1 cópia offsite. A cópia offsite precisa estar em local fisicamente separado — não só em rede diferente, mas em datacenter diferente, preferencialmente em cidade diferente.
Para ameaças físicas (incêndio, enchente, falha elétrica catastrófica) e para ataques que comprometem toda a infraestrutura de uma localidade, a cópia offsite é o que salva o negócio. Uma cópia local e uma em datacenter a poucos quilômetros ainda podem ser afetadas pelo mesmo evento.
Para empresas com dados no Brasil, a cópia offsite precisa também estar no Brasil para conformidade com LGPD — o que descarta soluções que replicam automaticamente para datacenters fora do país sem controle explícito de localidade. Esse é o mesmo raciocínio que sustenta a discussão de soberania de dados.
O que perguntar ao seu fornecedor de backup
Quando avaliar uma solução de backup — seja troca de produto ou contratação de backup gerenciado — essas perguntas separam o serviço real do marketing:
| Pergunta | Por que importa |
|---|---|
| Os dados são criptografados em repouso? Qual algoritmo? | AES-256 é o mínimo aceitável hoje |
| Quem controla as chaves de criptografia? | Chave no fornecedor = fornecedor pode acessar seus dados |
| Existe suporte a Object Lock / WORM? | Imutabilidade é requisito, não diferencial |
| As credenciais de backup são isoladas das de produção? | Pergunta que revela maturidade operacional |
| Onde ficam fisicamente as cópias? | Essencial para LGPD e para estratégia de DR |
| Qual o RTO e RPO garantidos em contrato? | Não basta ter backup — precisa restaurar no tempo necessário |
| Com que frequência vocês testam a restauração? | Backup não testado é backup não confiável |
Como testar a segurança do seu backup
Backup não testado é marketing. O teste de restauração precisa fazer parte do calendário operacional — não só para validar que os dados estão lá, mas para medir o tempo real de recuperação.
Além do teste de restauração convencional, um teste de segurança específico deve verificar:
Tente apagar um arquivo de backup com as credenciais de administrador de produção. Se conseguir, você tem um problema. Tente acessar a console de administração do backup sem MFA. Se conseguir, você tem um problema. Tente modificar um arquivo já gravado dentro da janela de imutabilidade. Se conseguir, a imutabilidade não está configurada corretamente.
Um bom programa de testes inclui restauração parcial mensal (um subconjunto de dados para validar integridade), restauração completa semestral (simulação real de DR) e auditoria anual de acesso (quem tem credenciais de backup, se ainda precisa, e se usou nos últimos 90 dias).
O Backup Gerenciado da Adentro opera com criptografia AES-256, retenção imutável configurável e cópias em datacenters Tier III no Brasil — com testes de restauração incluídos no serviço.
A Adentro oferece Backup Gerenciado com criptografia, imutabilidade e armazenamento Tier III no Brasil. Fale com um especialista para dimensionar sua estratégia — ou estime volume e retenção na Calculadora de Backup Corporativo.