Backups em conta separada: isolamento real na nuvem

Um backup guardado na mesma conta de nuvem que a produção morre junto com ela quando um invasor assume as credenciais de administrador: com o mesmo domínio de identidade, ele lista os cofres, apaga as cópias ou destrói a chave que as decifra. Equipes que operam cargas de trabalho na AWS ou no Azure precisam manter ao menos uma cópia em uma conta ou assinatura dedicada à recuperação, com cofre e chave de criptografia próprios, e provar que a restauração funciona sem depender das credenciais do ambiente principal. A ação prioritária é mapear, para cada cópia existente: onde ela reside, quem pode apagá-la e qual chave a decifra.

Por que o backup vizinho falha

O ataque que começa por phishing em um analista ou por um token vazado de pipeline não precisa de privilégio excepcional para destruir backups: basta herdar as permissões de quem administra o ambiente. Quando cofre de origem, cofre de destino e chave de criptografia vivem sob as mesmas políticas de acesso, o invasor executa três ações — apagar o cofre, agendar a exclusão da chave, encerrar a conta — e a organização perde produção e recuperação no mesmo incidente. A defesa aqui não é um produto, é topologia: colocar a cópia fora do alcance das credenciais que o atacante já possui.

Isolamento por conta resolve uma fraqueza específica que a imutabilidade de objeto não cobre. Um cofre com retenção travada ainda depende de a chave de criptografia continuar existindo e de a conta continuar sob controle do dono. As duas nuvens dominantes oferecem mecanismos nativos para essa separação, e todos exigem configuração deliberada: nada disso acontece por padrão de forma completa.

Conta de recuperação na AWS

O AWS Backup suporta cópias entre contas sob demanda ou dentro de um plano agendado. A regra estrutural vem antes da configuração: a cópia entre contas exige que origem e destino pertençam à mesma organização no AWS Organizations, e cada cópia é recriptografada com a chave do cofre de destino — o que significa que a conta de recuperação tem chave e cofre próprios, fora do alcance direto das credenciais da conta de produção.

Três detalhes da documentação da AWS mudam decisões práticas. Primeiro, o cofre de destino não pode ser o cofre padrão, porque ele é cifrado com uma chave que não pode ser compartilhada entre contas; é preciso criar um cofre dedicado com chave gerenciada pelo cliente. Segundo, a política de acesso do cofre de destino deve permitir apenas a ação backup:CopyIntoBackupVault — qualquer outra ação entre contas é rejeitada, o que reduz o que um invasor na conta de origem consegue fazer além de entregar cópias. Terceiro, se a conta de destino deixar a organização, ela leva os backups consigo; a própria documentação da AWS recomenda negar organizations:LeaveOrganization com uma política de controle de serviço anexada à conta de recuperação.

Há ainda uma janela de consistência a conhecer: depois de desabilitar a cópia entre contas, jobs podem continuar rodando por até 15 minutos. Em um incidente real, conte com esse atraso antes de declarar a contenção concluída.

Assinatura dedicada no Azure

No Azure, o equivalente é separar por assinatura dentro do mesmo locatário. O Cross Subscription Restore permite restaurar máquinas virtuais e discos gerenciados em uma assinatura diferente da assinatura protegida, respeitando permissões de RBAC. As condições importam: pontos de restauração do nível de cofre podem ser restaurados na assinatura da VM protegida ou na assinatura do cofre, e a propriedade de Cross Subscription Restore precisa estar habilitada no cofre de Recovery Services; pontos do nível de snapshot só restauram dentro da assinatura original. Restauração no local original e substituição de disco continuam restritas à assinatura protegida.

Dois controles do Key Vault protegem contra exclusão hostil. O soft-delete vem habilitado por padrão em novos cofres e não pode ser desligado depois de ativo. O purge protection é opcional, não vem habilitado e é justamente o que impede que um cofre ou objeto em estado excluído seja purgado antes do fim da retenção — a documentação da Microsoft o recomenda sempre que chaves protegem criptografia de dados. Ative-o no momento da criação do cofre de recuperação, porque o intervalo de retenção só pode ser definido nesse momento e não muda depois.

Chaves: o botão que apaga tudo

Separar a cópia não adianta se o invasor consegue agendar a exclusão da chave que a decifra. Na AWS, excluir uma chave KMS é destrutivo e irreversível: depois que a exclusão acontece, os dados cifrados sob aquela chave tornam-se irrecuperáveis. O freio é a janela obrigatória de 7 a 30 dias, com 30 dias como padrão — um período em que a chave fica em estado de exclusão pendente, inutilizável para operações criptográficas, mas ainda recuperável se alguém cancelar o agendamento. Use essa janela como detector: configure um alarme sobre qualquer tentativa de uso da chave durante o período e trate um agendamento de exclusão não planejado como incidente em andamento, não como rotina de limpeza. Quando houver dúvida sobre a necessidade de uma chave, desabilite em vez de excluir — desabilitar é reversível.

No Azure, a lógica é análoga com números próprios. Um objeto marcado como excluído no Key Vault tem período recuperável de 7 a 90 dias, e a eliminação definitiva exige uma operação adicional de purga com permissão específica. O papel de operador de purga pode ficar com uma pessoa ou pipeline diferente dos administradores do cofre, criando quórum de fato contra exclusão maliciosa. A recomendação prática: nenhuma identidade humana deve acumular, ao mesmo tempo, permissão de excluir chave e permissão de purgar. Se a operação de emergência precisar de acesso total, conceda por processo temporário e auditado, como no modelo de acesso de emergência testável.

Checklist de isolamento

Teste de restauração isolada

Isolamento não testado é hipótese. O teste precisa exercitar a propriedade que você quer provar: que alguém sem credenciais de produção recupera um serviço. Prioridade P1: restaurar, a partir da conta ou assinatura de recuperação, um volume ou disco representativo para um ambiente efêmero, medindo o tempo total até o dado ficar utilizável. Prioridade P2: validar o caminho de decifração — confirmar que a chave do destino decifra a cópia sem contato com a conta de origem e que os papéis de purga não estão atribuídos a quem executa a restauração.

Registre o resultado com data, ponto de recuperação usado, tempo medido e restrições encontradas. Esses números alimentam a análise de impacto de negócio: se o caminho isolado entrega restauração em tempo incompatível com a expectativa da operação, o plano precisa de cópias mais quentes ou de outra conta de recuperação, não de otimismo. Repita o teste a cada mudança relevante de política de acesso — o erro comum é a cópia continuar sendo gerada depois que alguém estreitou uma permissão e o restore silenciosamente parar de funcionar.

Fontes

• AWS Backup — Creating backup copies across AWS accounts
• AWS KMS — Delete an AWS KMS key
• Microsoft Learn — Azure Key Vault soft-delete overview