Segurança em RDS: boas práticas para bancos de dados na AWS
O banco guarda os dados mais valiosos. Veja como blindar rede, criptografia, backups e acesso no RDS.
O banco de dados costuma guardar os dados mais sensíveis da organização, o que faz dele um alvo de altíssimo valor. No RDS, segurança envolve várias camadas: onde o banco vive na rede, quem consegue alcançá-lo, como os dados são protegidos em repouso e em trânsito, como o acesso é autenticado e como os backups são guardados. Uma falha em qualquer dessas camadas pode expor tudo.
Este guia trata da segurança do RDS de forma defensiva, organizada pelos pontos de maior impacto: isolamento de rede, exposição, criptografia, autenticação, backups e auditoria. O objetivo é reduzir a superfície e garantir que o acesso ao banco seja controlado e rastreável.
Rede privada e exposição
O banco deve viver em sub-redes privadas, sem acesso direto da internet. Bancos publicamente acessíveis estão entre os achados mais graves em qualquer revisão, porque expõem dados a varredura e ataque contínuos. Os Security Groups devem permitir conexão apenas das cargas que realmente precisam, idealmente referenciando o grupo da aplicação em vez de faixas de IP.
Evite expor o banco para administração direta. Use um bastion controlado ou túneis temporários quando precisar de acesso administrativo, em vez de abrir a porta do banco para a internet.
Criptografia, autenticação e logs
Habilite criptografia em repouso, que protege dados e snapshots, e exija conexões criptografadas em trânsito. A criptografia em repouso precisa ser definida na criação na maioria dos casos, então planeje desde o início. Para autenticação, a autenticação por IAM elimina senhas de banco de longa duração em certos cenários, usando credenciais temporárias.
- Manter o banco em sub-rede privada, sem acesso público
- Permitir conexão apenas das cargas necessárias via Security Group
- Habilitar criptografia em repouso e exigir TLS em trânsito
- Avaliar autenticação por IAM para reduzir senhas fixas
- Habilitar logs de banco para auditoria e investigação
Habilite os logs disponíveis do mecanismo de banco, como logs de erro e de auditoria, e exporte para análise. Eles ajudam a detectar acesso anômalo e a investigar incidentes envolvendo dados.
Backups e snapshots
Backups automáticos e snapshots são parte da segurança, não só da disponibilidade. Defina retenção adequada, mantenha os backups criptografados e proteja contra exclusão. Cuidado com o compartilhamento de snapshots: um snapshot compartilhado de forma ampla ou tornado público expõe uma cópia completa do banco. Teste a restauração periodicamente, porque um backup que nunca foi restaurado é uma suposição, não uma garantia.
Checklist prático
- Manter o banco em sub-rede privada, sem acesso público
- Restringir conexão às cargas necessárias via Security Group
- Evitar exposição do banco para administração direta
- Habilitar criptografia em repouso na criação
- Exigir conexões TLS em trânsito
- Avaliar autenticação por IAM
- Habilitar e exportar logs do mecanismo de banco
- Definir retenção de backups e mantê-los criptografados
- Proteger snapshots contra compartilhamento amplo ou público
- Testar restauração de backups periodicamente
Boas práticas
- Isole o banco em rede privada como regra
- Conceda acesso de rede apenas às cargas que precisam
- Planeje criptografia em repouso desde a criação
- Reduza senhas fixas com autenticação por IAM quando possível
- Proteja e teste backups, não apenas os configure
- Audite acesso ao banco com logs exportados
Erros comuns
Banco publicamente acessível
Expõe dados sensíveis a varredura e ataque contínuos da internet.
Security Group liberando faixas amplas
Mais hosts do que o necessário conseguem alcançar o banco.
Sem criptografia em repouso
Dados e snapshots ficam sem proteção; ativar depois é trabalhoso.
Snapshot compartilhado de forma ampla ou público
Uma cópia completa do banco fica acessível indevidamente.
Backups nunca testados
A restauração falha justamente no momento do incidente.
Quando procurar apoio especializado
Revisar exposição, criptografia e acesso a bancos críticos é parte do serviço de Segurança AWS e Cloud Security da GUARDIASEC, que avalia rede, controles e backups e prioriza a correção dos riscos mais relevantes.
Perguntas frequentes
Posso deixar o RDS publicamente acessível?
Salvo casos muito específicos e bem justificados, não. Um banco público fica exposto a varredura e ataque constantes da internet, e está entre os achados mais graves em revisões de segurança. O recomendado é manter o RDS em sub-rede privada, acessível apenas pelas cargas necessárias, usando bastion ou túnel para administração.
Consigo habilitar criptografia em um banco já criado?
Na maioria dos casos a criptografia em repouso precisa ser definida na criação. Para um banco existente sem criptografia, o caminho costuma envolver criar uma versão criptografada a partir de um snapshot e migrar, o que exige planejamento e janela. Por isso o ideal é habilitar criptografia desde o início, evitando esse esforço posterior.
O que é autenticação por IAM no RDS?
É um mecanismo que permite autenticar no banco usando credenciais temporárias geradas pelo IAM, em cenários suportados, em vez de senhas de longa duração. Isso reduz o risco de senhas fixas vazadas e centraliza o controle de acesso. Não substitui todos os usos de senha, mas é uma camada valiosa onde se aplica.
Snapshots precisam de cuidado de segurança?
Sim. Um snapshot é uma cópia completa do banco, então deve ser criptografado e protegido contra exclusão e contra compartilhamento indevido. Compartilhar um snapshot de forma ampla, ou torná-lo público, expõe todos os dados. Trate snapshots com o mesmo rigor do banco original, inclusive na retenção e no controle de acesso.
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.