Cómo Funcionan los Permisos Internamente

Hemos visto que Apono añade y elimina permisos automáticamente, pero una duda frecuente es: ¿qué sucede cuando un ingeniero realiza varias solicitudes de acceso a recursos diferentes? ¿Apono crea una credencial nueva para cada solicitud? ¿Existe un role diferente para cada petición?

La respuesta es no, y entender cómo Apono gestiona esto internamente es importante para no generar expectativas incorrectas sobre el modelo de seguridad.

El Role es Único, los Permisos son Dinámicos

Cuando Apono se integra con una cuenta AWS, no crea un nuevo role IAM para cada solicitud de acceso. En su lugar, trabaja con un PermissionSet único (o un role IAM único) por usuario en cada cuenta AWS.

Lo que cambia en cada solicitud son los permisos asignados a ese role. Cada petición de acceso resulta en la adición de una inline policy específica para el recurso solicitado. Cuando el acceso expira, solo esa inline policy se elimina — las demás permanecen activas hasta que sus propios temporizadores expiren.

En la práctica, esto significa que:

• A las 10:00, el ingeniero solicita acceso a la EC2 i-0abc123 por 4 horas. Apono añade una inline policy de ssm:StartSession para esa instancia.
• A las 11:30, solicita acceso a la EC2 i-0def456 por 4 horas. Apono añade otra inline policy en el mismo role.
• A las 12:00, solicita acceso a la base de datos de producción por 1 hora (vía IAM Auth). Una inline policy más, esta vez con rds-db:connect.
• A las 13:00, la policy de la base de datos expira y se elimina. Las otras dos permanecen activas.
• A las 14:00, la policy de la primera EC2 expira y se elimina. La segunda continúa.
• A las 15:30, la última policy expira. El role del ingeniero queda sin permisos adicionales.

Cada solicitud tiene su propio ciclo de vida: aprobación, concesión, temporizador y revocación son independientes. Pero todas operan sobre la misma identidad IAM.

Apono es una herramienta orientada a organizaciones con un volumen significativo de usuarios y recursos — su costo se justifica en empresas donde el control manual de accesos ya se ha vuelto inviable. Apono funciona tanto con IAM tradicional (usuarios y roles IAM en una cuenta única) como con AWS IAM Identity Center en entornos multi-cuenta. En escenarios con IAM tradicional, el connector manipula inline policies directamente en los usuarios o roles IAM del ingeniero. Con Identity Center, trabaja con PermissionSets. Ambos modelos siguen el mismo principio descrito en este artículo: una identidad por usuario con permisos dinámicos. Sin embargo, para organizaciones con múltiples cuentas AWS, Identity Center es fuertemente recomendado como base de identidad antes de adoptar Apono.

Por Qué Esto Importa

Entender este modelo evita tres malentendidos comunes:

1. "Cada petición crea una credencial diferente"

No. El ingeniero sigue usando el mismo role IAM (o PermissionSet en el caso de AWS IAM Identity Center). Lo que cambia son las policies adjuntas a ese role. En la práctica, el ingeniero no necesita cambiar de credencial, volver a iniciar sesión o cambiar de perfil AWS en cada solicitud. Simplemente gana (y pierde) permisos de forma transparente.

2. "Si tengo dos accesos activos, uno puede interferir con el otro"

No. Las policies son independientes y están aisladas por recurso. La revocación de una solicitud elimina únicamente la policy de esa petición específica. Si el ingeniero tiene acceso simultáneo a tres instancias EC2, la expiración del acceso a una de ellas no afecta a las otras dos.

3. "El role acumula permisos para siempre"

Depende. Cada policy está vinculada a un Access Flow, y es el Access Flow el que define el tiempo de expiración. En la mayoría de los casos, el temporizador expira y el connector elimina la policy automáticamente. Sin embargo, un Access Flow puede configurarse con duración indefinida, es decir, una vez concedido, el acceso permanece activo hasta que sea revocado manualmente por un administrador. En ese escenario, sí, el permiso se acumula en el role mientras nadie lo revoque. Detallaremos las configuraciones de expiración y revocación cuando hablemos sobre Access Flows.

¿Y en el Caso de Bases de Datos?

Para bases de datos con autenticación IAM (PostgreSQL y MySQL en RDS/Aurora), el modelo es idéntico al descrito anteriormente: la policy rds-db:connect se añade y se elimina del mismo role IAM del usuario.

Para bases de datos con autenticación nativa (usuario y contraseña), el principio de identidad única también se aplica. En la primera solicitud de acceso a una instancia de base de datos, Apono crea un usuario en la instancia cuyo nombre se basa en el email del ingeniero en Apono, con una contraseña generada automáticamente. En solicitudes posteriores a la misma instancia, el usuario ya existe — Apono simplemente añade o elimina grants según lo solicitado.

Como una instancia RDS puede alojar varias bases de datos, el ingeniero puede solicitar acceso a diferentes bases de datos en la misma instancia en momentos distintos. Cada solicitud añade grants específicos al mismo usuario, y cada una tiene su propia expiración:

• A las 10:00, el ingeniero solicita acceso a la base de datos clientes. El connector crea el usuario (si aún no existe) y añade GRANT SELECT en las tablas de la base clientes.
• A las 11:00, solicita acceso a la base de datos pedidos en la misma instancia. El connector añade GRANT SELECT en las tablas de la base pedidos en el mismo usuario, con la misma contraseña.
• A las 11:00, el acceso a la base clientes expira. El connector revoca solo los grants de esa base. El acceso a la base pedidos sigue activo.

Cada solicitud tiene su ciclo de vida independiente, pero todas operan sobre el mismo usuario en la instancia — al igual que en IAM, donde todas operan sobre el mismo role.

Resumen del Modelo

Aspecto	IAM (role/PermissionSet)	Base de Datos (nativo)
Identidad del usuario	Única por cuenta AWS	Una por solicitud (usuario temporal)
Lo que cambia en cada petición	Policies en el role existente	Nuevo usuario en la base de datos
Credencial que usa el ingeniero	Siempre la misma (SSO/role)	Diferente en cada petición
Independencia entre peticiones	Sí (policies aisladas)	Sí (usuarios aislados)
Riesgo de acumulación permanente	Ninguno (temporizador por policy)	Ninguno (DROP USER con temporizador)

Apono no multiplica identidades. En AWS, trabaja con el role que el ingeniero ya tiene y ajusta dinámicamente lo que ese role puede hacer. Para bases de datos con autenticación nativa, crea identidades temporales por necesidad del modelo, pero cada una tiene vida corta y se elimina automáticamente. En ambos casos, ningún permiso sobrevive más allá del tiempo aprobado.