Acceso a Bases de Datos mediante Apono

Otro escenario fundamental para Apono es el acceso a bases de datos. Los ingenieros necesitan acceder a bases de producción para troubleshooting, análisis de datos, migraciones e investigación de incidentes y, al igual que en el caso de SSM, el modelo tradicional de permisos permanentes genera riesgos significativos.

Antes de entender cómo Apono gestiona este acceso, es importante conocer los dos modelos de autenticación que existen en Amazon RDS. Si aún no conoces la diferencia entre autenticación IAM y usuarios nativos, lee primero el artículo sobre Autenticación en Bases de Datos RDS.

El Problema del Acceso Permanente a Bases de Datos

En la mayoría de las organizaciones, el acceso a bases de datos sufre los mismos problemas que el acceso a instancias EC2:

• Credenciales compartidas: Varios ingenieros usan el mismo usuario genérico (ej: dev_team) para acceder a la base de datos de producción.
• Contraseñas que nunca expiran: Una vez creado el usuario en la base de datos, la contraseña raramente se rota.
• Permisos excesivos: El usuario compartido tiene acceso a todas las tablas, incluso cuando el ingeniero solo necesita consultar una.
• Auditoría imposible: Cuando todos usan el mismo usuario, no hay forma de saber quién ejecutó cada query.

Cómo Apono Resuelve el Problema

Apono soporta ambos modelos de autenticación de RDS y se adapta a lo que ya existe en tu infraestructura.

Escenario 1: IAM Auth en RDS

Cuando la base de datos usa autenticación IAM, Apono gestiona el acceso de la misma forma que gestiona SSM — controlando policies IAM:

1. El ingeniero solicita acceso a la base de datos.
2. Tras la aprobación, el connector de Apono añade la policy rds-db:connect al usuario IAM, con el ARN específico de la base de datos y del usuario de base de datos.
3. El ingeniero genera el token IAM y se conecta.
4. Cuando el tiempo expira, el connector elimina la policy y el usuario ya no puede generar tokens válidos.

En este escenario, el connector no interactúa con la base de datos. Actúa exclusivamente en la capa IAM de AWS, usando los permisos de su propio role (configurado en el deploy) para añadir y eliminar inline policies en el usuario/role del ingeniero. El ingeniero genera el token IAM por su cuenta (aws rds generate-db-auth-token) y se conecta directamente a la base de datos.

Escenario 2: Usuario Nativo de la Base de Datos

Para bases de datos que usan autenticación nativa (contraseña), incluyendo aquellas que no soportan IAM Auth (SQL Server, Oracle, MariaDB), Apono actúa de forma diferente. Gestiona credenciales directamente dentro de la base de datos:

1. El ingeniero solicita acceso a la base de datos.
2. Tras la aprobación, el connector de Apono se conecta a la base de datos usando credenciales administrativas (ej: usuario master de RDS) y crea un usuario temporal con los permisos definidos en el Access Flow.
3. Apono entrega las credenciales temporales al ingeniero.
4. Cuando el tiempo expira, el connector se conecta nuevamente a la base de datos y elimina el acceso completamente.

En este escenario, el connector interactúa directamente con la base de datos. Ejecuta comandos SQL para gestionar el ciclo de vida del usuario temporal:

-- En la concesión de acceso, el connector ejecuta automáticamente:
CREATE USER temp_juan_a1b2c3 WITH PASSWORD 'contraseña-generada-automaticamente';
GRANT SELECT ON schema_app.tabla_clientes TO temp_juan_a1b2c3;
GRANT SELECT ON schema_app.tabla_pedidos TO temp_juan_a1b2c3;

-- En la revocación (cuando el temporizador expira):
REVOKE ALL PRIVILEGES ON ALL TABLES IN SCHEMA schema_app FROM temp_juan_a1b2c3;
DROP USER temp_juan_a1b2c3;

Para que el connector pueda crear y eliminar usuarios en la base de datos, necesita credenciales administrativas de la base de datos — generalmente un usuario master o un usuario con permisos de CREATE USER y GRANT. Estas credenciales se configuran una única vez en la integración de Apono con la base de datos y se almacenan en el connector — nunca se envían al Apono Cloud.

Comparación de los Escenarios

Aspecto	IAM Auth	Usuario Nativo
Lo que Apono gestiona	Policy IAM del usuario	Usuario/credencial dentro de la base de datos
Tipo de credencial entregada	Ninguna (el usuario genera token IAM)	Usuario y contraseña temporales
Bases de datos soportadas	PostgreSQL y MySQL (RDS/Aurora)	Cualquier base soportada por Apono
Revocación	Elimina policy IAM	DROP USER en la base de datos
Requisito del connector	Permisos IAM	Credenciales admin de la base de datos

Lo Que Cambia en la Práctica

Independientemente del modelo de autenticación, el resultado es el mismo:

• Cada ingeniero tiene sus propias credenciales — fin de las contraseñas compartidas.
• Permisos granulares — el Access Flow define exactamente qué tablas y operaciones (SELECT, INSERT, etc.) el ingeniero puede acceder.
• Duración definida — el acceso expira automáticamente, sin depender de acción manual.
• Auditoría individual — Apono registra quién solicitó, para qué base de datos, con qué permisos y por cuánto tiempo. Combinado con los logs de la base de datos, es posible rastrear cada query hasta el ingeniero que la ejecutó.

Apono no reinventa la rueda — automatiza el ciclo de vida de las credenciales que ya existen. Para IAM Auth, gestiona policies IAM. Para autenticación nativa, crea y elimina usuarios directamente en la base de datos. En ambos casos, el resultado es el mismo: acceso temporal, granular, aprobado y auditado.

Connector y Conectividad

El connector es el componente que ejecuta las acciones descritas en los escenarios anteriores. Para entender su arquitectura completa (cómo se despliega, cómo se comunica con el Apono Cloud y cómo funciona el modelo de seguridad), consulta los artículos sobre arquitectura y deploy.

Es el mismo connector que gestiona tanto el acceso IAM (como vimos en el artículo de SSM) como el acceso directo a bases de datos. No existen connectors separados para AWS y para bases de datos. Un único agente, desplegado una vez en la infraestructura, ejecuta diferentes tipos de acciones dependiendo de la integración configurada en el Apono Cloud:

• Integración AWS: el connector usa los permisos IAM de su propio role para manipular policies en IAM (añadir/eliminar ssm:StartSession, rds-db:connect, etc.).
• Integración de base de datos: el mismo connector usa credenciales administrativas de la base de datos (configuradas en la integración) para ejecutar CREATE USER, GRANT, DROP USER directamente en la base de datos.

La diferencia no está en el connector en sí, sino en la integración. Cada integración indica al connector cómo interactuar con ese tipo de recurso, qué credenciales usar y qué acciones ejecutar.

Requisitos de Red del Connector

Esta distinción entre integraciones tiene implicación directa en la red. El connector necesita conectividad con dos destinos diferentes:

1. Apono Cloud (outbound HTTPS) — para el polling de acciones pendientes y reporte de estado. Esto requiere acceso a internet (vía NAT Gateway) o VPC Endpoints para los servicios necesarios.
2. Las bases de datos gestionadas — solo para integraciones de base de datos con autenticación nativa. El connector necesita alcanzar la base de datos en el puerto de conexión (ej: 5432 para PostgreSQL, 3306 para MySQL).

Para la integración AWS (IAM Auth), el connector solo necesita alcanzar las APIs de AWS (IAM, STS). No necesita una ruta de red hacia la base de datos, porque no interactúa directamente con ella.

Para la integración de base de datos (usuario nativo), el connector debe estar en una red que alcance la base de datos. Si el connector está en una VPC y la base de datos en otra, es necesario VPC Peering, Transit Gateway o que el connector se despliegue en la misma VPC de la base de datos. Sin esta conectividad, el connector no puede ejecutar los comandos SQL de creación y eliminación de usuarios.

En la práctica, la ubicación del connector en la red es una decisión arquitectónica importante. En organizaciones con múltiples VPCs y cuentas AWS, es común desplegar el connector en una VPC con conectividad amplia (vía Transit Gateway, por ejemplo) o en la misma VPC de las bases de datos que necesita gestionar.

Si el connector existente no puede alcanzar una determinada base de datos, es posible desplegar un segundo connector en otra VPC o cuenta. Apono soporta múltiples connectors simultáneamente y cada integración se asocia a un connector específico. Por ejemplo, una organización puede tener un connector en la cuenta de gestión (para integraciones AWS/IAM) y otro en la cuenta de producción (para integraciones de base de datos que requieren acceso directo). Cada connector opera de forma independiente, haciendo polling al Apono Cloud y ejecutando solo las acciones de las integraciones vinculadas a él.

El Connector No Es un Proxy

Es importante entender que el connector no es un proxy de conexión. No intermedia el tráfico entre el ingeniero y la base de datos. Su única función es gestionar credenciales: añadir policies IAM, crear usuarios en la base de datos, conceder permisos y revocar accesos.

La conectividad del ingeniero con la base de datos es una responsabilidad completamente separada que Apono no resuelve. Si la base de datos está en una subnet privada sin acceso externo, el ingeniero necesita una ruta de red hacia ella por otros medios — como VPN, Direct Connect, bastion host o SSM port forwarding. Apono garantiza que el ingeniero tendrá credenciales válidas cuando llegue a la base de datos, pero cómo llega es un problema de red que debe resolverse independientemente.

Son dos problemas de conectividad distintos: el connector necesita alcanzar la base de datos para gestionar usuarios, y el ingeniero necesita alcanzar la base de datos para usarla. Apono resuelve el primero, pero no el segundo.

El connector es stateless y hace polling periódico al Apono Cloud para verificar si hay acciones pendientes (concesiones o revocaciones). Toda la lógica de decisión (quién puede acceder a qué, por cuánto tiempo, con qué aprobación) reside en el control plane de Apono. El connector simplemente ejecuta lo que recibe.