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.
Referencie o grupo da aplicação, não faixas de IP
Um Security Group que libera a porta do banco para uma faixa ampla deixa mais hosts alcançarem o banco do que o necessário. O padrão mais restrito é a regra de entrada referenciar o Security Group da aplicação como origem: só quem está naquele grupo consegue conectar, e a regra continua correta mesmo quando os IPs das cargas mudam.
aws ec2 authorize-security-group-ingress \
--group-id sg-do-banco \
--protocol tcp --port 5432 \
--source-group sg-da-aplicacaoCriptografia, 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.
Autenticação por IAM na prática
Com a autenticação por IAM habilitada no banco, a aplicação gera um token temporário e conecta com ele em vez de uma senha fixa. A permissão de conectar é concedida no IAM, escopada ao usuário de banco correspondente, o que centraliza o controle e elimina uma senha de longa duração de dentro da aplicação.
{
"Effect": "Allow",
"Action": "rds-db:connect",
"Resource": "arn:aws:rds-db:REGIAO:CONTA:dbuser:ID-DO-BANCO/app_leitura"
}Menor privilégio dentro do banco
A segurança de rede e de autenticação controla quem chega ao banco, mas não o que cada um faz depois de conectado. Dentro do banco, aplique menor privilégio criando usuários por função, com apenas os privilégios que cada carga usa. Uma aplicação que só lê e escreve linhas não precisa de privilégio para alterar esquema, criar usuários ou operar como superusuário.
-- Papel de aplicacao apenas com leitura e escrita de dados
CREATE ROLE app_rw LOGIN;
GRANT CONNECT ON DATABASE loja TO app_rw;
GRANT USAGE ON SCHEMA public TO app_rw;
GRANT SELECT, INSERT, UPDATE, DELETE
ON ALL TABLES IN SCHEMA public TO app_rw;
-- Sem DDL, sem criacao de papeis, sem superusuarioSepare também os papéis administrativos dos de aplicação. Uma credencial de migração de esquema, que precisa de DDL, não deve ser a mesma que a aplicação usa em runtime. Assim, o comprometimento da carga de produção não entrega poder de alterar a estrutura do banco.
Detecção de acesso anômalo
Controles preventivos reduzem a chance de acesso indevido, mas não substituem enxergar o que acontece. Exporte os logs do mecanismo para o CloudWatch Logs e defina alertas para sinais de abuso, como uma sequência de falhas de autenticação ou conexões vindas de uma origem inesperada. O GuardDuty tem um plano de proteção para RDS que observa tentativas anômalas de login em bancos gerenciados, útil como camada adicional de detecção.
Vale também acompanhar consultas fora do padrão, como leituras em massa de tabelas sensíveis, que podem indicar exfiltração. Esse tipo de sinal costuma passar despercebido sem log de auditoria exportado e sem alguém observando, então trate a detecção no banco com o mesmo cuidado da rede e da identidade.
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
- Referenciar o grupo da aplicação no Security Group, não faixas de IP
- Avaliar autenticação por IAM com token temporário
- Aplicar menor privilégio dentro do banco, por função
- Separar credenciais administrativas das de aplicação
- Habilitar e exportar logs do mecanismo de banco
- Alertar sobre falhas de login e origens inesperadas
- 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
- Referencie o grupo da aplicação em vez de faixas de IP
- Planeje criptografia em repouso desde a criação
- Reduza senhas fixas com autenticação por IAM quando possível
- Aplique menor privilégio dentro do banco, não só na rede
- 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.
Aplicação conectando como superusuário
Um comprometimento da carga ganha poder de alterar esquema e dados sem limite.
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.
Basta proteger a rede, ou preciso de menor privilégio dentro do banco?
Os dois. A rede controla quem alcança o banco; os privilégios internos controlam o que cada conexão pode fazer depois de autenticada. Se a aplicação conecta como superusuário, qualquer comprometimento da carga ganha poder total sobre esquema e dados. Crie usuários por função, com apenas os privilégios que cada carga usa, e separe credenciais administrativas das de aplicação.
Como restrinjo o Security Group do RDS de forma correta?
Em vez de liberar a porta do banco para uma faixa de IP, faça a regra de entrada referenciar o Security Group da aplicação como origem. Assim, apenas as cargas naquele grupo conectam, e a regra permanece válida mesmo quando os endereços mudam. Faixas amplas costumam deixar mais hosts alcançarem o banco do que o necessário, ampliando a superfície sem ganho.
Como detecto acesso anômalo ao banco?
Exporte os logs do mecanismo, como erro e auditoria, para o CloudWatch Logs e defina alertas para sinais de abuso, como falhas repetidas de autenticação, conexões de origem inesperada e leituras em massa de tabelas sensíveis. O GuardDuty oferece um plano de proteção para RDS que observa tentativas anômalas de login em bancos gerenciados, somando uma camada de detecção sem exigir configuração no próprio banco.
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.