Backups seguros na AWS: retenção, criptografia e recuperação contra incidentes
Backup que pode ser apagado pelo atacante não é backup. Veja como tornar a recuperação realmente confiável.
Backup é a última linha de defesa contra perda de dados, falha grave e ransomware. O problema é que muitos backups falham exatamente quando são necessários: porque o atacante conseguiu apagá-los, porque a retenção era curta demais ou porque ninguém nunca testou a restauração. Backup seguro não é só fazer cópias, é garantir que essas cópias sobrevivam a um incidente e possam ser restauradas de fato.
Este guia trata de backups seguros na AWS de forma defensiva, com foco em resiliência: retenção, criptografia, isolamento das cópias, proteção contra exclusão e testes de restauração. O objetivo é que a recuperação seja uma capacidade real, e não uma suposição.
Estratégia, RPO e RTO
Comece definindo objetivos: o RPO indica quanto dado você tolera perder, e o RTO quanto tempo tolera ficar indisponível. Esses números orientam a frequência dos backups e a arquitetura de recuperação. O AWS Backup centraliza políticas para vários serviços, padronizando frequência, retenção e criptografia em um só lugar, o que facilita governança e auditoria.
Adote a lógica de defesa em camadas: backups frequentes para recuperação recente e cópias de retenção mais longa para cenários de comprometimento que só são descobertos depois de semanas. Um incidente de ransomware pode permanecer latente, então depender só de backups muito recentes é arriscado.
Isolamento e proteção contra exclusão
O controle mais importante contra ransomware e contra um atacante com acesso à conta é impedir que os backups sejam apagados. Use cópia para uma conta separada e isolada, com permissões distintas, e mecanismos de imutabilidade ou bloqueio de cofre que impeçam exclusão durante o período de retenção. Se quem compromete a produção também consegue apagar os backups, a proteção é ilusória.
- Copiar backups para uma conta separada e isolada
- Aplicar imutabilidade ou bloqueio durante a retenção
- Separar quem administra produção de quem administra backup
- Criptografar os backups com controle de chave
- Manter retenção longa o suficiente para incidentes latentes
Reforce o isolamento negando, por política, as ações que apagam pontos de recuperação e cofres. Uma SCP aplicada à conta de backup, ou a política de acesso do cofre, impede a exclusão mesmo por quem tem credenciais administrativas, o que é justamente o cenário de um atacante que já comprometeu a conta.
{
"Effect": "Deny",
"Action": [
"backup:DeleteRecoveryPoint",
"backup:DeleteBackupVault",
"backup:PutBackupVaultAccessPolicy"
],
"Resource": "*"
}Vault Lock e imutabilidade na prática
O AWS Backup oferece o Vault Lock para tornar os pontos de recuperação de um cofre imutáveis durante a retenção. Em modo de conformidade, nem a conta raiz consegue apagar um backup antes do prazo, o que é o controle mais forte contra exclusão por ransomware ou por um administrador comprometido. Por ser irreversível, esse modo exige planejamento.
O período de carência antes do bloqueio
O Vault Lock tem uma janela de carência definida na configuração: até o fim dela, dá para ajustar ou remover o bloqueio, o que serve para validar as regras de retenção antes que fiquem definitivas. Depois desse prazo, o modo de conformidade se torna imutável. Escolha a retenção mínima e máxima com cuidado, porque elas passam a valer sem volta.
aws backup put-backup-vault-lock-configuration \
--backup-vault-name cofre-isolado \
--min-retention-days 30 \
--max-retention-days 365 \
--changeable-for-days 3Criptografia e testes de restauração
Criptografe os backups e controle quem pode descriptografar, lembrando que uma cópia em outra conta precisa de acesso adequado à chave para ser restaurada. E, acima de tudo, teste a restauração periodicamente. Um backup que nunca foi restaurado é uma suposição; o teste valida que os dados estão íntegros, que o procedimento funciona e que o RTO é realista. Documente o procedimento de recuperação para que ele não dependa de uma única pessoa.
Cobertura: o que fica sem backup
A falha mais silenciosa não é o backup mal configurado, é o recurso que ninguém incluiu no plano. Um banco novo, um volume criado às pressas ou uma conta recém-adicionada à organização podem passar meses sem nenhuma cópia, e isso só aparece no dia da restauração. Verificar cobertura é tão importante quanto proteger as cópias que já existem.
Planos de backup baseados em tag ajudam: em vez de listar cada recurso, o plano seleciona tudo o que carrega uma tag definida, então recursos novos entram na proteção ao receber a tag na criação. O AWS Backup Audit Manager complementa medindo a aderência, apontando recursos que deveriam ter backup e não têm.
- Selecionar recursos por tag, para novos ativos entrarem no plano
- Auditar cobertura e sinalizar recursos sem backup
- Incluir contas novas da organização na política de backup
- Rever a cobertura após mudanças relevantes de arquitetura
Checklist prático
- Definir RPO e RTO por carga crítica
- Centralizar políticas com AWS Backup quando aplicável
- Manter backups frequentes e cópias de retenção longa
- Copiar backups para uma conta separada e isolada
- Aplicar Vault Lock ou bloqueio durante a retenção
- Negar por política a exclusão de pontos de recuperação e cofres
- Separar administração de produção e de backup
- Criptografar backups com controle de chave
- Garantir acesso à chave para restaurar cópias entre contas
- Selecionar recursos por tag para novos ativos entrarem no plano
- Auditar cobertura e sinalizar recursos sem backup
- Testar restauração periodicamente
- Documentar o procedimento de recuperação
Boas práticas
- Projete backups para sobreviver a quem compromete a conta
- Isole cópias em conta separada com permissões distintas
- Use Vault Lock em modo de conformidade contra exclusão por ransomware
- Combine retenção curta e longa para incidentes latentes
- Selecione recursos por tag e audite a cobertura
- Teste a restauração, não apenas a criação do backup
- Documente a recuperação para não depender de uma pessoa
Erros comuns
Backups na mesma conta, sem proteção contra exclusão
Quem compromete a conta apaga os backups junto com os dados.
Recursos novos que ficam fora do plano de backup
Ativos sem cópia só aparecem no dia da restauração, quando já é tarde.
Retenção curta demais
Incidentes descobertos tarde não têm ponto de recuperação limpo.
Nunca testar a restauração
A recuperação falha no incidente real e o RTO se mostra irreal.
Backups sem criptografia
Uma cópia dos dados fica exposta fora dos controles da produção.
Procedimento de recuperação não documentado
A restauração depende de uma única pessoa e trava sob pressão.
Quando procurar apoio especializado
Projetar backups resilientes a comprometimento e validar a recuperação é parte dos serviços de Segurança AWS e de Monitoramento e Resposta da GUARDIASEC, que avaliam isolamento, retenção e prontidão de restauração.
Perguntas frequentes
Por que copiar backups para outra conta?
Porque um atacante que compromete a conta de produção normalmente tenta apagar os backups para forçar o pagamento de resgate ou impedir a recuperação. Mantendo cópias em uma conta separada e isolada, com permissões distintas e imutabilidade, os backups sobrevivem ao comprometimento da produção. Sem esse isolamento, a proteção é apenas aparente.
O que é imutabilidade de backup e por que importa?
Imutabilidade impede que um backup seja alterado ou excluído durante o período de retenção, mesmo por quem tem permissões administrativas. Isso é crucial contra ransomware e contra um atacante com acesso à conta, que tentaria apagar os pontos de recuperação. Com imutabilidade, fica preservada uma cópia limpa para restaurar.
Com que frequência devo testar a restauração?
Periodicamente, e sempre após mudanças relevantes na arquitetura. Um backup que nunca foi restaurado é uma suposição: o teste confirma que os dados estão íntegros, que o procedimento funciona e que o tempo de recuperação é realista. Sem teste, é comum descobrir no incidente que o backup estava incompleto ou que o RTO planejado era inviável.
Backup recente resolve um ransomware?
Nem sempre. Um comprometimento pode ficar latente por semanas antes de ser percebido, então backups muito recentes podem já conter o problema. Por isso a recomendação é combinar backups frequentes com cópias de retenção mais longa e isoladas, ampliando a chance de existir um ponto de recuperação anterior ao comprometimento.
O que é o Vault Lock do AWS Backup?
É o recurso que torna os pontos de recuperação de um cofre imutáveis durante a retenção. Em modo de conformidade, nem a conta raiz apaga um backup antes do prazo, o que é a proteção mais forte contra exclusão por ransomware ou por um administrador comprometido. Ele tem uma janela de carência inicial, definida na configuração, em que ainda dá para ajustar as regras; depois desse prazo, o bloqueio se torna definitivo, então a retenção mínima e máxima devem ser escolhidas com cuidado.
Como garanto que nenhum recurso ficou sem backup?
Prefira planos de backup que selecionam recursos por tag, em vez de listar cada um. Assim, um ativo novo entra na proteção ao receber a tag definida na criação, sem depender de alguém lembrar de incluí-lo. Complemente com o AWS Backup Audit Manager, que mede a aderência e aponta recursos que deveriam ter backup e não têm, e reveja a cobertura após mudanças relevantes de arquitetura e ao adicionar contas à organização.
Uma SCP negando exclusão de backup atrapalha a operação legítima?
Não, quando bem desenhada. A ideia é vedar apenas ações destrutivas sobre pontos de recuperação e cofres, como apagar recuperações ou alterar a política de acesso do cofre, mantendo intactas as operações normais de criar e restaurar. A expiração dos backups continua acontecendo pela regra de retenção do próprio plano. O que a política impede é a exclusão manual antecipada, exatamente o passo que um atacante tentaria dar.
Guias relacionados
Próximo passo
Vamos avaliar os riscos do seu ambiente?
Conte seu cenário e definimos juntos o escopo certo. O objetivo é reduzir caminhos prováveis de ataque e elevar a maturidade de segurança, sem promessas absolutas.