O ransomware aprendeu a atacar o backup antes de atacar a produção. A defesa que está mudando esse jogo não tenta reagir mais rápido — ela simplesmente faz a cópia de recuperação desaparecer dos olhos do invasor.
Durante décadas, a estratégia de proteção de dados girou em torno de uma ideia simples: ter uma cópia. Hoje isso não basta. Os grupos de ransomware modernos sabem que a forma mais lucrativa de extorquir uma empresa é primeiro destruir a capacidade de recuperação — ou seja, comprometer os repositórios de backup — e só então criptografar o ambiente de produção. Sem backup confiável, a vítima fica sem alternativa de negociação.
Os números confirmam que essa mudança de comportamento já é regra, não exceção. No relatório Ransomware Trends 2025, a maioria das organizações relatou que seus repositórios de backup foram alvo direto dos ataques, e uma parcela significativa desses repositórios acabou alterada ou apagada. Quando a sua última linha de defesa vira o primeiro alvo, o custo e a complexidade do incidente se multiplicam.
O air gap precisou evoluir
O conceito de air gap é um dos mais antigos da proteção de dados: manter os backups isolados — física ou logicamente — dos sistemas que poderiam comprometê-los. Na era da fita, isso significava enviar mídias para um cofre externo. No mundo on-premises, manter um array de armazenamento desconectado da rede de produção.
Na nuvem, esse "ar" entre o dado e o atacante deixou de ser físico. Ele passou a ser lógico, sustentado por permissões, controles de acesso e APIs. Para recriar o isolamento, muitos fornecedores oferecem um "air gap faça-você-mesmo": camadas de MFA, configuração manual de rede, regras de IAM e scripts personalizados que simulam a separação. Outros transformam isso em um serviço gerenciado caro, em que alguém precisa executar manualmente cada etapa.
Cada etapa manual cria mais um momento em que algo pode ser mal interpretado ou feito às pressas, justamente numa semana corrida ou no meio de um incidente sob pressão. Estudos de mercado mostram que erro de configuração e falha humana estão entre as principais causas de vazamento de dados em nuvem. O resultado é um air gap tecnicamente possível, mas operacionalmente frágil.
A pergunta certa, então, é outra: e se o air gap mais seguro fosse também o mais simples de implementar e o mais difícil de desfazer?
Uma nova abordagem: a cópia oculta e imutável
A resposta que vem ganhando espaço no mercado de object storage é uma nova classe de proteção embutida na própria plataforma de armazenamento — não um produto adicional, não um add-on de terceiros. A ideia é deixar o administrador criar, com poucos cliques, uma cópia espelhada do dado que fica invisível e imutável dentro da própria conta.
Na prática, é um novo tipo de bucket projetado para guardar uma cópia air-gapped com visibilidade mínima e acesso rigorosamente controlado. Você escolhe o conjunto de dados crítico que quer proteger e a plataforma copia o conteúdo — essa é a parte "cópia". O bucket é automaticamente removido das requisições padrão de listagem do S3, e os objetos também ficam ocultos, a menos que um acesso temporário seja explicitamente concedido — essa é a parte "oculta".
É como ativar um modo de camuflagem para o seu dado mais importante: o invasor não consegue criptografar, apagar ou roubar aquilo que ele sequer enxerga. E, quando você precisa recuperar, um processo de autorização com múltiplos aprovadores libera o acesso de forma controlada.
Air gap "faça-você-mesmo" vs. cópia oculta nativa
A diferença não está só no nível de proteção, mas em quem carrega o esforço operacional e onde mora o risco de falha. A tabela abaixo resume o contraste entre montar o isolamento manualmente e usar um recurso nativo da plataforma de armazenamento:
| Critério | Air gap DIY | Cópia oculta nativa |
|---|---|---|
| Implementação | Manual: scripts, regras de IAM, configuração de rede e políticas em múltiplas ferramentas. | Poucos cliques no console; o recurso já faz parte da plataforma. |
| Visibilidade da cópia | O repositório continua listável pelas APIs — o atacante consegue enumerá-lo. | Bucket e objetos removidos das listagens padrão do S3; invisíveis por padrão. |
| Imutabilidade | Depende de configuração correta de Object Lock e de renovação manual da retenção. | Object Lock aplicado a todos os objetos, com auto-renovação automática a cada 30 dias. |
| Controle de acesso | Em geral baseado em credenciais e MFA — sujeito a ponto único de falha. | MFA somado à autorização multiusuário (MUA): nenhum usuário acessa sozinho. |
| Risco de erro humano | Alto — cada etapa manual é uma chance de configuração incorreta sob pressão. | Baixo — o processo é automatizado, removendo o espaço para falha operacional. |
| Recuperação | Procedimentos ad hoc, muitas vezes não testados até o momento do incidente. | Caminhos definidos: restauração pontual com aprovação MUA e modo de recuperação "quebrar o vidro". |
| Custo e dependência | Tempo de equipe especializada ou serviço gerenciado caro de terceiros. | Recurso embutido no armazenamento; sem infraestrutura adicional para manter. |
| Resultado | Isolamento tecnicamente possível, porém operacionalmente frágil. | Isolamento lógico real, sustentado pela própria camada de armazenamento. |
Os pilares por trás da proteção
Esse tipo de cópia oculta combina cinco camadas que trabalham juntas para entregar um isolamento real:
Invisível
O atacante não mira o que não vê. O bucket e os objetos ficam fora das listagens padrão da API.
Réplica fiel
Uma cópia ponto-no-tempo do dado, sempre disponível e recuperável quando necessário.
Imutável
Travada via Object Lock — não pode ser alterada, apagada ou criptografada durante a retenção.
Inacessível
Mesmo com a rede comprometida, o acesso exige aprovação por autorização multiusuário (MUA).
Conta protegida
O MUA protege dado e conta de armazenamento ao mesmo tempo, eliminando ponto único de falha.
Como funciona na prática
Cada cópia oculta é uma captura ponto-no-tempo do conjunto de dados escolhido — um retrato congelado, guardado em um bucket separado, que não pode ser modificado pelo tempo que você decidir mantê-lo. O fluxo é deliberadamente direto:
- Você parte do bucket que contém o dado a proteger e seleciona a opção de cópia oculta no menu de ações.
- A plataforma verifica se o MFA está habilitado e se as atividades de autorização multiusuário (MUA) estão configuradas; se faltar algo, o console aponta exatamente o que ajustar.
- Você confirma com o código MFA e dispara a criação. Por trás dos panos, inicia-se uma replicação que copia os dados, de forma silenciosa e segura, para o bucket oculto.
- Em minutos, o dado está duplicado em um bucket invisível, perpetuamente imutável e acessível apenas ao usuário root.
Como a configuração é self-service, você mantém total controle sobre o que está sendo protegido — mas o processo em si é automatizado, o que remove o espaço para erro humano. Tecnicamente, o isolamento é sustentado por um conjunto pequeno de controles atuando em conjunto: isolamento de API S3 (bloqueio de escrita/exclusão e restrição de listagem), MFA obrigatório para qualquer alteração administrativa, fluxo de aprovação por MUA, integração com Object Lock e controles de visibilidade que mantêm o bucket fora das APIs públicas.
Auto-renovação: imutabilidade que se mantém sozinha
A retenção não depende de você lembrar de renová-la. Um mecanismo de auto-renovação reaplica o Object Lock sobre cada objeto do bucket periodicamente — em ciclos de 30 dias — até que você decida, de fato, descartar a cópia. Enquanto a auto-renovação estiver ativa, o bucket não pode ser apagado. Ao desativá-la, o ciclo para e o bucket entra em estado de "ação requerida", sinalizando que poderá ser removido (com aprovação MUA) quando a retenção expirar. Mesmo nesse cenário, os objetos permanecem imutáveis até a exclusão efetiva.
Recuperação quando você realmente precisa
Um air gap só vale alguma coisa se você conseguir trazer o dado de volta sob pressão. Por isso existem dois caminhos de recuperação, conforme a gravidade da situação:
| Cenário | Como funciona | Janela |
|---|---|---|
| Restauração pontual | Para recuperar alguns objetos ou pastas, você solicita acesso via self-service. Os contatos de segurança designados (MUA) recebem um alerta e têm um tempo curto para aprovar. Operações de leitura são liberadas temporariamente, mantendo a imutabilidade de escrita. | ~15 min para aprovar; acesso por 24h, depois o air gap se sela sozinho |
| Modo de recuperação | Para restaurar todo o conjunto ou reconectar a aplicação de backup, aciona-se um modo emergencial do tipo "quebrar o vidro", que torna o bucket e os objetos visíveis e acessíveis à aplicação. Mesmo nesse modo, o dado continua imutável. | Sob demanda; o bucket volta ao estado oculto após a recuperação |
Trate a cópia oculta como um cofre, não como um bucket de uso diário: coloque o que é realmente crítico, valide que consegue recuperar e deixe selado. Recomendamos manter pelo menos uma cópia oculta atualizada dos conjuntos mais sensíveis e refrescá-la periodicamente (a cada 90–120 dias), desativando a auto-renovação das cópias antigas antes de removê-las.
Onde essa proteção faz diferença
Esse modelo se encaixa em qualquer cenário em que a cópia de recuperação precisa ser intencionalmente difícil de descobrir, alterar ou apagar:
- Backups resilientes a ransomware: mais do que mitigar o ataque, a cópia oculta o previne — o invasor não encontra o repositório para comprometê-lo.
- Arquivamento e conformidade: proteção de subconjuntos sensíveis — propriedade intelectual, dados pessoais, registros médicos e financeiros — sujeitos a mandatos regulatórios como LGPD, ISO 27001, HIPAA e GDPR.
- Mitigação de ameaça interna: nenhum usuário, sozinho, consegue acessar ou modificar a cópia, o que neutraliza tanto o invasor externo quanto o colaborador mal-intencionado.
- Cofre de recuperação: guarda de planos de DR, topologias de ambiente, licenças e dados confidenciais essenciais para reconstruir a operação.
Reguladores estão endurecendo as exigências de imutabilidade e seguradoras cibernéticas já cobram prova de proteção de última linha para renovar apólices. Se o seu plano de recuperação depende de um backup que o atacante consegue enxergar, ele depende de algo que o atacante também consegue destruir.
A proteção mais poderosa é a que você não percebe
Em um cenário saturado de alertas, dashboards piscando e respostas a incidentes sob pressão, a jogada mais inteligente não é reagir mais rápido — é estar pronto antes. Uma cópia tão bem guardada que nem o invasor mais determinado consegue encontrá-la transforma a recuperação de uma corrida contra o tempo em uma operação previsível e confiável.
Na SafeLevel, ajudamos empresas a desenhar essa última linha de defesa de ponta a ponta — combinando imutabilidade, isolamento real no nível do armazenamento e governança por múltiplos aprovadores dentro da sua estratégia de continuidade de negócios. O melhor air gap é aquele em que você não precisa pensar todos os dias. Você só precisa saber que ele está lá.