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
Criptografia 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.
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 imutabilidade ou bloqueio durante a retenção
- Separar administração de produção e de backup
- Criptografar backups com controle de chave
- Garantir acesso à chave para restaurar cópias entre contas
- 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 imutabilidade contra exclusão por ransomware
- Combine retenção curta e longa para incidentes latentes
- 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.
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.
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.