Imutabilidade, Air Gap e Isolamento: três camadas que não são a mesma coisa
Perai, não são a mesma coisa? 🙂 Hoje vamos falar sobre três termos que aparecem em praticamente toda conversa sobre proteção contra ransomware: imutabilidade, air gap e isolamento. É muito comum ver os três sendo usados como sinônimos, como se ter um deles resolvesse o problema inteiro, mas na prática são camadas diferentes, que protegem contra coisas diferentes. E entender essa diferença é o que separa um backup que simplesmente existe de um backup que vai estar lá quando você realmente precisar.
Segundo a Veeam, a regra 3-2-1-1-0 é a evolução da velha 3-2-1: três cópias dos dados, em dois tipos de mídia diferentes, uma cópia fora do site, mais uma cópia imutável ou em local air gapped, e zero erros na verificação da recuperação. Repare que aquele segundo “1” já coloca dois conceitos no mesmo lugar (“imutável ou air gapped”), e é justamente aí que muita gente para de pensar: habilitei a imutabilidade no repositório, então estou coberto. Não é bem assim. Basicamente, cada camada responde a uma pergunta diferente:
- Imutabilidade: o dado não pode ser alterado nem apagado durante um período definido, nem mesmo pelo administrador do backup. No Veeam Backup & Replication isso aparece, por exemplo, no Hardened Repository. Já expliquei com mais detalhes no post Criptografia e Imutabilidade no Veeam Backup & Replication
- Air gap: uma cópia desconectada do ambiente. Pode ser física, como a fita que sai do site ou lógica, quando a cópia fica num local sem conexão permanente e sem caminho de acesso a partir da produção
- Isolamento: credenciais, rede e domínio da infraestrutura de backup separados do ambiente de produção, ou seja, quem compromete a produção não chega ao backup com a mesma chave
Dito tudo isso, acredito que fica claro que uma camada não substitui a outra, e é fácil ver por que. A imutabilidade protege o arquivo de backup, mas se o atacante tem a conta de administrador do Veeam Backup & Replication e do vCenter, ele não precisa apagar o backup: basta desabilitar os jobs, apagar a produção e esperar. O backup imutável vai estar lá, só que cada vez mais antigo. O air gap protege contra quase tudo que vem pela rede, mas normalmente tem um RPO maior e um custo operacional que não dá para ignorar. E o isolamento, sozinho, é uma barreira e não uma garantia: se um dia ela for ultrapassada, quem segura são as outras duas. O cenário que mais me preocupa é justamente o mais comum: repositório imutável configurado e o servidor de backup no mesmo domínio e na mesma rede da produção, com acesso fácil ao SO (exemplo: ssh habilitado e credencial fraca) e sem cópias adicionais.
A própria Veeam, na seção Securing Backup Infrastructure do guia, recomenda colocar o servidor de backup e os demais componentes num domínio de gerenciamento, em uma floresta separada do Active Directory, nos ambientes grandes, ou em um workgroup nos ambientes médios e pequenos, sempre numa rede separada quando possível, além de MFA no console e do Hardened Repository. Para o air gap, o mesmo guia cita mídias offline, como o suporte a fita e os repositórios com discos rotacionados. E não esqueça do “0” da regra: o SureBackup está aí exatamente para provar que aquele backup imutável e isolado realmente restaura.
No fim das contas, imutabilidade, air gap e isolamento se complementam: a primeira garante que o dado não muda, a segunda que existe uma cópia fora do alcance e a terceira que o problema da produção não vira automaticamente o problema do backup. Se o seu ambiente tem só uma delas, vale olhar com calma para as outras duas.
É isso ai. Até a próxima!