Por que isso virou assunto de segurança

Durante quase toda a história da computação, backup era sobre acidente: um disco que falha, um diretório apagado, uma migração ruim. O modelo de ameaça era indiferente. Nada estava tentando derrotar o backup.

O mudou isso, e a mudança é estrutural, não de grau. Um invasor competente hoje ataca os backups primeiro, porque destruir o caminho de recuperação é o que converte uma queda em pagamento. A ordem das operações numa invasão moderna é: entrar, escalar, achar a infraestrutura de backup, apagá-la ou cifrá-la, e então cifrar a produção. Quando alguém percebe o problema de produção, a resposta para ele já foi embora.

É por isso que o desenho de backup virou um controle de segurança com adversário, e por que um plano escrito para falha de disco em geral não sobrevive ao contato com um deles.

Origens: um problema de mídia antes de ser de segurança

O backup nasce como consequência de o armazenamento ser pouco confiável e caro. A prática e o vocabulário vêm da fita, e vários hábitos que hoje parecem estranhos são a lógica da fita sobrevivendo num mundo de discos e de armazenamento de objetos.

Avô-pai-filho. Conjuntos diários, semanais e mensais em rodízio, que é de onde vêm as camadas de retenção: guardavam-se poucas cópias recentes e menos ainda antigas porque fita custava dinheiro e armário tem tamanho.

Completo, incremental, diferencial. Uma cópia completa é lenta de fazer e rápida de restaurar; a incremental copia só o que mudou desde o último backup, sendo rápida de fazer e lenta de restaurar porque é preciso reproduzir uma cadeia; a diferencial copia tudo desde o último completo, dividindo a diferença. A troca não mudou - só migrou para sistemas de deduplicação e snapshot, onde um "completo" hoje costuma ser sintético, montado de blocos que nunca foram copiados duas vezes.

Fora do local como proteção contra incêndio. A razão original de uma cópia remota não era um atacante. Era incêndio, enchente e roubo - e a van do correio levando fitas ao cofre era o air gap original, e é por isso que a discussão moderna sobre imutabilidade fica redescobrindo que separação física é incomumente difícil de derrotar à distância.

A regra 3-2-1 foi formulada nesse mundo, por um fotógrafo escrevendo sobre proteger imagens, e se espalhou porque é memorável e quase sempre certa. O que ela nunca contemplou foi um adversário que se autentica como administrador e apaga as três cópias de um console só.

A evolução da mídia, e o que cada virada mudou

Da fita para o disco (anos 2000). As restaurações ficaram mais rápidas e o acesso aleatório tornou prática a recuperação granular. Também removeu a propriedade de estar offline que a fita tinha por acidente, o que ninguém percebeu como perda até o ransomware transformá-la numa.

Deduplicação e completos sintéticos. Guardar só blocos únicos tornou a retenção longa acessível, e acoplou cada ponto de restauração a um repositório de blocos compartilhado - então a corrupção ou exclusão desse repositório afeta todos os pontos de uma vez, concentração que ninguém enxerga num gráfico de retenção.

Snapshots. Instantâneos, baratos e vizinhos da produção, o que os torna excelentes para recuperação operacional e insuficientes como defesa única: um snapshot no mesmo storage ou na mesma conta de nuvem que o dado está dentro do mesmo domínio de falha e, com frequência, da mesma credencial.

Armazenamento de objetos com trava. A resposta atual ao problema que a fita resolvia por acidente: um período de retenção que a própria plataforma se recusa a encurtar, aplicado independentemente de quem pede.

O backup como alvo. No fim dos anos 2010 os atacantes já apagavam snapshots, cifravam repositórios de backup e revogavam credenciais de nuvem antes de tocar na produção - foi isso que transformou o tema de infraestrutura em tema de segurança.

A regra, e a cláusula que faltava

A orientação tradicional é 3-2-1: três cópias dos dados, em dois tipos de mídia, uma delas fora do local. É bom conselho e não é suficiente, porque toda cópia que ela descreve pode ser alcançável pela mesma conta administrativa comprometida.

A cláusula que importa hoje é a quarta: uma cópia que não possa ser modificada nem apagada, nem por um administrador. Na prática isso significa uma destas:

  • Imutabilidade na camada de armazenamento - trava de objeto ou retenção do tipo grava-uma-vez, em que o pedido de exclusão é recusado pela plataforma por um período definido, seja quem for que o faça.
  • Uma cópia genuinamente offline - fita, ou mídia removível fisicamente desconectada. Fora de moda e extremamente eficaz, porque credencial não alcança prateleira.
  • Um domínio de confiança separado - uma conta ou tenant de backup com identidade própria, administradores próprios, e nenhuma relação de confiança com a produção.

A ideia que unifica as três merece ser dita sozinha: o backup não pode estar dentro do raio de explosão das credenciais que administram a produção. Se o seu administrador de domínio consegue apagar os backups, então um comprometimento de administrador de domínio apaga os backups, e o fato de eles estarem em três lugares é irrelevante.

A retenção precisa durar mais que o tempo de permanência

Um atacante que está dentro há semanas pode ter corrompido ou cifrado dados muito antes do evento visível. Se sua janela de retenção for menor que o tempo de permanência do invasor, toda cópia sobrevivente contém o problema.

Este é o argumento para manter pontos de restauração que alcancem mais para trás que o pior tempo de permanência plausível, e para manter alguns deles imutáveis. É também o argumento para conhecer o seu tempo de permanência, coisa que a maioria das organizações não mede.

Restauração não testada é boato

A falha mais comum não é backup ausente. É backup que existe e não restaura, ou restaura devagar demais para importar.

Concretamente, o que dá errado na hora da necessidade:

  • A restauração leva dias porque ninguém mediu a vazão contra o volume real de dados.
  • O sistema restaura mas não sobe, porque uma dependência - um banco, um certificado, um servidor de licenças, um provedor de identidade - nunca esteve no escopo.
  • Ninguém consegue se autenticar no console de backup, porque o provedor de identidade faz parte do que está fora.
  • O runbook mora no wiki, e o wiki está cifrado.
  • As chaves de cifragem dos backups estão no cofre de senhas, e o cofre de senhas está no ambiente que caiu.

A disciplina que corrige todos esses casos é a mesma: restaure com regularidade, com data marcada, e cronometre. Uma restauração que não foi feita neste trimestre é uma hipótese. Objetivos de recuperação - quanto de dado se pode perder, e quanto tempo se pode ficar fora - só são reais se uma restauração medida os sustenta; caso contrário são números num documento.

Arquitetura, e o vocabulário que a descreve

Com agente ou sem agente. Um agente na carga de trabalho entende a aplicação e consegue silenciar um banco antes de copiar; abordagens sem agente fazem snapshot no hipervisor ou no storage e são mais simples de operar, ao custo de consciência da aplicação. A maioria dos parques precisa das duas, e a falha costuma ser um banco copiado no meio de uma transação.

Consistência é o jogo inteiro. Uma cópia consistente com falha é o que você teria se a energia caísse; uma cópia consistente com a aplicação é aquela em que a aplicação foi avisada para descarregar e pausar antes. Restaurar um banco consistente só com falha às vezes funciona, e às vezes não é estratégia de recuperação.

Onde mora a aplicação da regra. A imutabilidade pode ser implementada no software de backup, na plataforma de armazenamento, ou na política de retenção do provedor de nuvem - e só as duas últimas sobrevivem ao comprometimento do próprio software de backup. Vale confirmar essa distinção com o fabricante em vez de presumir.

A reformulação 3-2-1-1-0. A formulação atualizada da indústria acrescenta uma cópia imutável ou offline e zero erros na verificação, que é um jeito compacto de enunciar as duas cláusulas que este artigo defende.

Os objetivos de recuperação - quanto de dado se aceita perder e quanto tempo se aceita ficar fora - são o contrato entre o desenho e o negócio. Só significam algo quando uma restauração cronometrada os demonstrou.

O cenário de fabricantes, por categoria

  • Plataformas corporativas de backup - Veeam, Commvault, Veritas, Rubrik, Cohesity. Cobertura ampla de hipervisores, bancos e nuvem, com recursos de imutabilidade que diferem em onde são aplicados. É essa a pergunta a apertar: aplicada pelo software ou pelo armazenamento.
  • Serviços nativos de nuvem - backup e snapshot dos provedores, os mais baratos de adotar e em geral dentro da mesma conta e fronteira de identidade que o dado. Configuração entre contas ou entre tenants é o que os transforma em controle de verdade.
  • Imutabilidade na camada de armazenamento - trava de objeto em armazenamento de objetos, modos grava-uma-vez em appliances dedicados. É onde mora a garantia mais forte, porque a recusa em apagar vem da plataforma.
  • Fita, ainda - para retenção muito grande a custo baixo e separação offline genuína. Fora de moda, e a única mídia em que uma credencial não alcança o meio físico.
  • Backup de software como serviço - Microsoft 365, Salesforce e similares. A lacuna que a maioria descobre tarde: o provedor protege a infraestrutura dele, e não você das suas próprias exclusões nem de um atacante com sessão válida, e a linha de responsabilidade compartilhada fica exatamente onde as pessoas presumem que não fica.

A pergunta de compra, como em toda esta série: em qual domínio de falha a cópia mora, e quem consegue apagá-la.

O que o backup não resolve

Esta é a parte que se pula, e ela muda a decisão.

A extorsão moderna costuma ser dupla: os dados são cifrados e copiados para fora antes. O backup responde à cifragem por completo - você restaura e recusa pagar por uma chave. Não responde nada à cópia. O atacante continua com os dados, e a ameaça de publicá-los não é afetada pela qualidade da sua recuperação.

Então um plano só de restauração trata o problema de disponibilidade e deixa o de divulgação inteiramente aberto. Isso significa que a decisão depois de um incidente não é uma, e sim duas, e a segunda pertence ao jurídico, à comunicação e aos reguladores tanto quanto à engenharia - com obrigações de notificação que correm no próprio relógio, independentemente de como vai a recuperação.

A formulação honesta: backup significa que você não precisa pagar para ter seus dados de volta. Não significa que você não está tendo uma semana péssima.

Uma lista que vale de fato executar

  • Uma cópia imutável ou offline, fora do raio de explosão administrativo da produção.
  • Retenção maior que o seu tempo de permanência plausível, e não só maior que a sua janela de conveniência.
  • Infraestrutura de backup com credenciais separadas e, de preferência, provedor de identidade separado.
  • Restauração testada com data marcada, cronometrada, com o resultado escrito e comparado ao objetivo.
  • O runbook, a lista de contatos e as credenciais disponíveis fora do ambiente que protegem - impressos, ou em outro tenant.
  • Um caminho de decisão nomeado para a metade da divulgação, acordado antes do dia em que for preciso.

O princípio geral é o mesmo que atravessa todos os pontos de estrangulamento deste site: um controle que divide domínio de falha com aquilo que protege não é um controle. O backup é o caso mais claro, porque o domínio de falha em geral é uma conta de administrador, e quase ninguém o desenha assim no diagrama.