Políticas, roles de servicio y federación de identidades
El control de acceso en la nube se entiende con tres preguntas: quién pide, qué pide y qué dicen las políticas que aplican. Las claves de larga duración, en cambio, se entienden con una sola: cuándo se van a filtrar.
Para este tema conviene tener claro:Usuarios, grupos, roles y mínimo privilegio
Datos de proveedores verificados contra la documentación oficial el 19 de sept de 2026.
Todo el mundo aprende identidad y accesos de la misma forma: pegándose contra un “acceso denegado” que no se entiende, probando permisos hasta que anda, y dejando el permiso amplio que finalmente funcionó.
El problema es que ese permiso amplio queda, y un año después nadie sabe si se puede sacar. Vale la pena entender el modelo una vez: son tres piezas y se combinan siempre igual.
Las tres piezas
Cómo se arma cualquier permiso
- La identidad: quién hace el pedido. Una persona, una aplicación, un servicio del proveedor.
- La política: un documento que dice qué acciones se permiten o se niegan sobre qué recursos, y bajo qué condiciones.
- El vínculo: qué política aplica a qué identidad. Se conecta a través de grupos y, sobre todo, de roles.
Un rol no es un usuario: es un conjunto de permisos que alguien asume temporalmente y que le devuelve credenciales que vencen. Esa es la pieza central de todo el modelo, y la que permite que una aplicación nunca tenga una clave guardada.
| Concepto | AWS | Google Cloud | Azure |
|---|---|---|---|
| Documento de permisos | Política IAM en JSON | Rol con una lista de permisos | Definición de rol |
| Asignar permisos | Adjuntar política a usuario, grupo o rol | Vinculación: quién + rol + recurso | Asignación de rol sobre un ámbito |
| Identidad de una aplicación | Rol asumido por el servicio | Cuenta de servicio | Identidad administrada |
| Herencia | Por cuenta y por políticas de organización | Por jerarquía: organización, carpeta, proyecto | Por ámbito: grupo de administración, suscripción, grupo de recursos |
Roles de servicio: la aplicación sin contraseña
Una aplicación que corre en la nube no necesita —y no debería tener— una clave de acceso guardada. El proveedor le entrega credenciales temporales por el solo hecho de estar corriendo donde está.
Qué pasa cuando el código pide credenciales
- La instancia, el contenedor o la función tiene un rol asociado.
- El SDK le pide credenciales al servicio de metadatos del entorno, que responde localmente.
- Vuelven credenciales temporales, que vencen en un rato y se renuevan solas.
- Cada llamada a la API se firma con esas credenciales, y la política del rol decide si pasa.
Antes de seguir, predecí
Federación: entrar sin usuarios propios
La federación resuelve el mismo problema una capa más arriba: que las personas y los sistemas de afuera obtengan credenciales temporales sin que haya un usuario creado en la nube.
| Quién entra | Cómo | Qué reemplaza |
|---|---|---|
| Personas del equipo | El proveedor de identidad corporativo, con inicio de sesión único | Usuarios y contraseñas por cuenta |
| Pipelines de integración continua | Confianza en el emisor de tokens del pipeline | Claves de acceso guardadas en el repositorio |
| Cargas en otra nube o servidor propio | Federación con el emisor de esa identidad | Una clave copiada entre entornos |
| Usuarios finales de una aplicación | Un servicio de identidad de clientes | Una tabla de contraseñas propia |
La forma concreta que más cambió el día a día es la del pipeline. Una acción de integración continua puede presentar un token firmado por su propio emisor, y la nube —que confía en ese emisor, para ese repositorio y esa rama— le devuelve credenciales temporales. No hay ninguna clave guardada en ningún lado, y una clave que no existe no se filtra ni hay que rotarla.
Organizar permisos para que se puedan sostener
Cuatro reglas que evitan el desorden
- Permisos a grupos y roles, nunca a personas: alguien que cambia de equipo debería cambiar de grupo, no acumular accesos.
- Separar por cuenta, proyecto o suscripción lo que tiene que estar separado. Es el límite más fuerte que existe: producción y desarrollo no comparten permisos por accidente si no comparten contenedor.
- Barandas arriba de todo: las políticas de organización ponen un techo que ningún permiso de adentro puede superar. Sirven para lo que nunca se hace, como borrar registros de auditoría.
- Acceso elevado y temporal para lo excepcional: en vez de administradores permanentes, un pedido que da permisos por unas horas y queda registrado.
Más a fondo · nivel seniorLos tres caminos por los que se filtra un permiso de más
Las políticas mal escritas rara vez dicen “sos administrador”. Lo dicen de costado:
- Escalada por passRole: quien puede asignar un rol a un recurso que crea, puede darle a ese recurso un rol más poderoso que el suyo y usarlo. Es el permiso más subestimado del modelo.
- Acceso entre cuentas demasiado abierto: una política que confía en una cuenta entera, sin condición de identificador externo ni de origen, convierte cualquier identidad de esa cuenta en una identidad válida de la nuestra.
- El recurso que tiene su propia política: un bucket o una cola pueden otorgar acceso por su lado, independientemente de las políticas de identidad. Auditar sólo las identidades deja la mitad del mapa sin mirar.
Las tres se detectan con los analizadores de acceso de cada proveedor, que responden la pregunta útil: ¿quién, desde afuera, puede llegar a este recurso hoy?
Cierre
Autoevaluación
¿Lo entendiste?
Práctica