Autenticación en Bases de Datos RDS

El acceso a bases de datos en Amazon RDS (PostgreSQL, MySQL, SQL Server, etc.) involucra dos capas distintas: la capa de red (la base necesita ser accesible vía security groups, VPC y subnet) y la capa de autenticación (la base necesita reconocer quién se está conectando). Este artículo se enfoca en la segunda capa — donde existen dos modelos fundamentalmente diferentes.

Modelo 1: Usuario Nativo de la Base de Datos

El modelo tradicional. Creas un usuario directamente dentro de la base de datos con CREATE USER y defines permisos con GRANT.

-- Crear usuario en PostgreSQL
CREATE USER ingeniero_joao WITH PASSWORD 'ContraseñaFuerte123!';

-- Conceder permisos en tablas específicas
GRANT SELECT, INSERT ON schema_app.tabla_clientes TO ingeniero_joao;
GRANT SELECT ON schema_app.tabla_pedidos TO ingeniero_joao;

Características:

• El usuario y la contraseña existen dentro de la base de datos — son independientes del IAM de AWS.
• La contraseña es estática y necesita ser rotada manualmente (o vía Secrets Manager).
• Cada base de datos tiene sus propios usuarios — no hay centralización.
• Revocar el acceso requiere conectarse a la base y ejecutar DROP USER o REVOKE.

Problemas:

• Contraseñas compartidas: En la práctica, los equipos terminan compartiendo credenciales de un "usuario genérico" en lugar de crear usuarios individuales.
• Contraseñas eternas: Una vez creada, la contraseña rara vez se rota.
• Auditoría débil: Saber quién hizo qué query es difícil cuando varios ingenieros usan el mismo usuario.
• Sprawl de credenciales: Cada base tiene sus propios usuarios, multiplicando el problema en entornos con decenas de bases.

Modelo 2: Autenticación IAM en RDS

AWS permite que bases RDS (PostgreSQL y MySQL) utilicen tokens IAM en lugar de contraseñas para autenticar conexiones. En este modelo, el usuario existe en la base de datos, pero la autenticación se hace vía IAM — la base valida un token temporal generado por AWS en lugar de una contraseña estática.

Configuración

Para habilitar autenticación IAM en RDS, son necesarios los siguientes pasos:

1. Habilitar IAM Authentication en RDS:

aws rds modify-db-instance \
  --db-instance-identifier mi-base \
  --enable-iam-database-authentication \
  --apply-immediately

2. Crear el usuario en la base con grant de autenticación IAM:

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

El GRANT rds_iam le dice a PostgreSQL que este usuario se autentica vía token IAM en lugar de contraseña.

3. Conceder permiso IAM al usuario AWS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "rds-db:connect",
      "Resource": "arn:aws:rds-db:<región>:<cuenta>:dbuser:<dbi-resource-id>/ingeniero_joao"
    }
  ]
}

4. Conectar usando el token:

# Generar token de autenticación
TOKEN=$(aws rds generate-db-auth-token \
  --hostname mi-base.abc123.us-east-1.rds.amazonaws.com \
  --port 5432 \
  --username ingeniero_joao)

# Conectar a la base con el token
psql "host=mi-base.abc123.us-east-1.rds.amazonaws.com \
      port=5432 \
      dbname=mi_base \
      user=ingeniero_joao \
      password=$TOKEN \
      sslmode=require"

Ventajas del IAM Auth

Aspecto	Contraseña Nativa	IAM Auth
Tipo de credencial	Contraseña estática	Token temporal (15 min)
Dónde vive la autenticación	Dentro de la base	AWS IAM
Rotación	Manual o vía Secrets Manager	Automática (token expira)
Auditoría	Logs de la base solamente	CloudTrail + logs de la base
Centralización	Cada base es independiente	Centralizada en IAM
Revocación	Conectar a la base y eliminar	Eliminar policy IAM

Limitaciones del IAM Auth

• Disponible solo para PostgreSQL y MySQL en RDS (y Aurora).
• Límite de 20 conexiones por segundo usando IAM Auth por instancia RDS — no es adecuado para aplicaciones de alta frecuencia.
• El token tiene validez de 15 minutos — adecuado para sesiones interactivas, pero requiere renovación automática en conexiones de larga duración.
• SQL Server, Oracle y MariaDB en RDS no soportan IAM Auth — en esos casos, el modelo de usuario nativo (con posible integración vía Secrets Manager) es la única opción.

En la Práctica: ¿Qué Modelo Usar?

En la mayoría de las organizaciones, ambos modelos coexisten:

• Aplicaciones generalmente usan usuarios nativos con contraseñas gestionadas por AWS Secrets Manager (con rotación automática). El volumen de conexiones por segundo en producción frecuentemente excede el límite del IAM Auth.
• Ingenieros y acceso humano son el escenario ideal para IAM Auth — conexiones esporádicas, duración corta y necesidad de auditoría granular.

Esta separación es exactamente el punto donde herramientas de gestión de acceso Just-in-Time como Apono actúan con más eficiencia — controlando quién recibe la policy rds-db:connect y por cuánto tiempo (para IAM Auth) o creando y eliminando usuarios temporales directamente en la base (para autenticación nativa).