Autenticação em Bancos de Dados RDS

O acesso a bancos de dados no Amazon RDS (PostgreSQL, MySQL, SQL Server, etc.) envolve duas camadas distintas: a camada de rede (o banco precisa estar acessível via security groups, VPC e subnet) e a camada de autenticação (o banco precisa reconhecer quem está se conectando). Este artigo foca na segunda camada, onde existem dois modelos fundamentalmente diferentes.

Modelo 1: Usuário Nativo do Banco de Dados

O modelo tradicional. Você cria um usuário diretamente dentro do banco de dados com CREATE USER e define permissões com GRANT.

-- Criar usuário no PostgreSQL
CREATE USER engenheiro_joao WITH PASSWORD 'SenhaForte123!';

-- Conceder permissões em tabelas específicas
GRANT SELECT, INSERT ON schema_app.tabela_clientes TO engenheiro_joao;
GRANT SELECT ON schema_app.tabela_pedidos TO engenheiro_joao;

Características:

• O usuário e a senha existem dentro do banco de dados — são independentes do IAM da AWS.
• A senha é estática e precisa ser rotacionada manualmente (ou via Secrets Manager).
• Cada banco de dados tem seus próprios usuários — não há centralização.
• Revogar o acesso exige conectar no banco e executar DROP USER ou REVOKE.

Problemas:

• Senhas compartilhadas: Na prática, equipes acabam compartilhando credenciais de um "usuário genérico" em vez de criar usuários individuais.
• Senhas eternas: Uma vez criada, a senha raramente é rotacionada.
• Auditoria fraca: Saber quem fez qual query é difícil quando vários engenheiros usam o mesmo usuário.
• Sprawl de credenciais: Cada banco tem seus próprios usuários, multiplicando o problema em ambientes com dezenas de bancos.

Modelo 2: Autenticação IAM no RDS

A AWS permite que bancos RDS (PostgreSQL e MySQL) utilizem tokens IAM em vez de senhas para autenticar conexões. Nesse modelo, o usuário existe no banco de dados, mas a autenticação é feita via IAM — o banco valida um token temporário gerado pela AWS em vez de uma senha estática.

Configuração

Para habilitar autenticação IAM no RDS, são necessários os seguintes passos:

1. Habilitar IAM Authentication no RDS:

aws rds modify-db-instance \
  --db-instance-identifier meu-banco \
  --enable-iam-database-authentication \
  --apply-immediately

2. Criar o usuário no banco com grant de autenticação IAM:

-- PostgreSQL
CREATE USER engenheiro_joao;
GRANT rds_iam TO engenheiro_joao;

O GRANT rds_iam diz ao PostgreSQL que esse usuário se autentica via token IAM em vez de senha.

3. Conceder permissão IAM ao usuário AWS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds-db:<região>:<conta>:dbuser:<dbi-resource-id>/engenheiro_joao"
    }
  ]
}

4. Conectar usando o token:

# Gerar token de autenticação
TOKEN=$(aws rds generate-db-auth-token \
  --hostname meu-banco.abc123.us-east-1.rds.amazonaws.com \
  --port 5432 \
  --username engenheiro_joao)

# Conectar ao banco com o token
psql "host=meu-banco.abc123.us-east-1.rds.amazonaws.com \
      port=5432 \
      dbname=minha_base \
      user=engenheiro_joao \
      password=$TOKEN \
      sslmode=require"

Vantagens do IAM Auth

Aspecto	Senha Nativa	IAM Auth
Tipo de credencial	Senha estática	Token temporário (15 min)
Onde a autenticação mora	Dentro do banco	AWS IAM
Rotação	Manual ou via Secrets Manager	Automática (token expira)
Auditoria	Logs do banco apenas	CloudTrail + logs do banco
Centralização	Cada banco é independente	Centralizada no IAM
Revogação	Conectar no banco e remover	Remover policy IAM

Limitações do IAM Auth

• Disponível apenas para PostgreSQL e MySQL no RDS (e Aurora).
• Limite de 20 conexões por segundo usando IAM Auth por instância RDS — não é adequado para aplicações de alta frequência.
• O token tem validade de 15 minutos — adequado para sessões interativas, mas exige renovação automática em conexões de longa duração.
• SQL Server, Oracle e MariaDB no RDS não suportam IAM Auth — nesses casos, o modelo de usuário nativo (com possível integração via Secrets Manager) é a única opção.

Na Prática: Qual Modelo Usar?

Na maioria das organizações, os dois modelos coexistem:

• Aplicações geralmente usam usuários nativos com senhas gerenciadas pelo AWS Secrets Manager (com rotação automática). O volume de conexões por segundo em produção frequentemente excede o limite do IAM Auth.
• Engenheiros e acesso humano são o cenário ideal para IAM Auth — conexões esporádicas, duração curta e necessidade de auditoria granular.

Essa separação é exatamente o ponto onde ferramentas de gerenciamento de acesso Just-in-Time como o Apono atuam com mais eficiência — controlando quem recebe a policy rds-db:connect e por quanto tempo (para IAM Auth) ou criando e removendo usuários temporários diretamente no banco (para autenticação nativa).