Identidad y permisos en la nube, pedido por pedido
Quién puede hacer qué sobre qué recurso. Entender cómo AWS, Google Cloud y Azure deciden cada pedido es la diferencia entre el mínimo privilegio y una credencial que abre toda la cuenta.
Para este tema conviene tener claro:Modelo de responsabilidad compartida
Datos de proveedores verificados contra la documentación oficial el 15 de sept de 2026.
La mayoría de los incidentes graves en la nube no empiezan con un ataque sofisticado: empiezan con permisos de más. Una clave de acceso con permiso de administrador que quedó en un repositorio, una aplicación que sólo necesitaba leer un bucket y podía borrar la base. Cada pedido que llega a la nube se decide con reglas precisas, y conocerlas es la mejor defensa.
Quién puede hacer qué sobre qué
Toda regla de permisos, en cualquier proveedor, contesta cuatro preguntas:
- Quién: el principal, que puede ser una persona, un grupo o una aplicación.
- Qué: la acción, como leer un objeto o apagar una máquina.
- Sobre qué: el recurso, como un bucket, una base o un proyecto entero.
- Con qué efecto: permitir o denegar.
Cambia dónde se escribe esa regla y cómo se hereda:
| AWS | Google Cloud | Azure | |
|---|---|---|---|
| Dónde vive la regla | Políticas JSON adjuntas a identidades o a recursos | Políticas que asignan roles a principales sobre un recurso | Asignaciones de rol sobre un ámbito |
| Unidad de permiso | Acción, como s3:GetObject | Permiso dentro de un rol, como storage.objects.get | Acción dentro de un rol, como Microsoft.Storage/storageAccounts/read |
| Herencia | Por cuenta; Organizations agrega límites por unidad organizativa | Organización → carpetas → proyecto → recurso | Grupo de administración → suscripción → grupo de recursos → recurso |
| Denegar | Deny explícito en cualquier política | Políticas de denegación, separadas de las de permiso | Deny assignments, en casos acotados |
Personas, grupos y cargas de trabajo
Las personas entran con su usuario, idealmente federado con el proveedor de identidad de la empresa y con MFA. Los permisos se dan a grupos, no a personas sueltas: cuando alguien cambia de equipo, cambia de grupo y listo.
Las aplicaciones también necesitan identidad, y ahí está el error más común. Una aplicación que corre en la nube no debería usar claves fijas: debería usar la identidad que el proveedor le asigna al recurso donde corre. Es un rol de IAM en AWS, una cuenta de servicio en Google Cloud y una identidad administrada en Azure. Las credenciales que recibe son temporales y rotan solas.
Cómo se decide un pedido
En AWS, cada pedido se evalúa contra todas las reglas que aplican, sin importar en qué orden están escritas. La lógica, simplificada, son tres preguntas:
La evaluación de un pedido
- ¿Alguna regla que coincide deniega explícitamente? Entonces se deniega, y no importa nada más.
- Si no, ¿alguna regla que coincide permite? Entonces se permite.
- Si ninguna coincide, se deniega por defecto. Todo lo que no está permitido está prohibido.
Antes de seguir, predecí
Probá la política
Esta política deja leer los reportes y prohíbe borrar cualquier cosa. A la derecha, cinco pedidos con su resultado y la regla que lo decidió. Probá:
- Agregar
"s3:PutObject"a la lista de acciones deLeerReportesy ver qué pedido cambia. - Borrar la regla
NuncaBorrarentera. El borrado no pasa a estar permitido: pasa a estar denegado por defecto. - Cambiar los recursos de
LeerReportespor"*"y ver qué más quedó abierto. - Escribir tus propios pedidos abajo.
Escena 1 — Una política contra cinco pedidos
probala
Cargando la escena…
Comodines que abren de más
Las acciones y los recursos aceptan comodines: * es cualquier cantidad de caracteres y
? es exactamente uno. s3:Get* cubre s3:GetObject, s3:GetBucketPolicy y varias más.
Las acciones no distinguen mayúsculas: iam:ListAccessKeys es lo mismo que
IAM:listaccesskeys. En los recursos no conviene contar con eso: hay partes, como el nombre
de un usuario de IAM, que sí las distinguen.
Un detalle que confunde a todos: en S3, el bucket y sus objetos son recursos distintos.
s3:ListBucket se evalúa contra arn:aws:s3:::reportes, y s3:GetObject contra
arn:aws:s3:::reportes/2026/agosto.csv. Por eso la política de ejemplo lista los dos
recursos: con sólo reportes/*, listar el bucket queda denegado.
Herencia en Google Cloud y Azure
En Google Cloud y en Azure los permisos se heredan hacia abajo. Un rol dado en una carpeta vale para todos sus proyectos; uno dado en una suscripción vale para todos sus grupos de recursos. Y las asignaciones se suman: una política más abajo puede dar más permisos, pero no puede quitar los que vienen de arriba.
Para quitar hacen falta mecanismos aparte. Google Cloud tiene políticas de denegación, que se evalúan antes que las de permiso. Azure tiene deny assignments, pero no se pueden crear directamente: las crea la plataforma, por ejemplo al proteger los recursos de un deployment stack.
Mínimo privilegio sin frenar al equipo
Nadie escribe la política perfecta de entrada. Lo que funciona es empezar acotado y ajustar con datos de uso real:
- AWS: IAM Access Analyzer puede generar una política a partir de las acciones que una identidad usó de verdad, según CloudTrail.
- Google Cloud: las recomendaciones de roles miran los permisos usados en los últimos 90 días y sugieren quitar el rol o cambiarlo por uno más acotado.
- Azure: Privileged Identity Management da los roles sensibles sólo por un rato y con aprobación, en vez de dejarlos asignados para siempre.
Más a fondo · nivel seniorLas capas de permisos en AWS
En una organización real, la decisión no depende sólo de la política de la identidad. AWS evalúa varias capas, y un pedido se permite sólo si ninguna lo deniega y las que corresponden lo permiten:
- Políticas de control de servicios de Organizations: fijan el máximo de lo que se puede hacer en una cuenta, aunque la identidad sea administradora.
- Políticas de control de recursos, también de Organizations: el mismo tipo de techo, aplicado a los recursos de las cuentas.
- Límites de permisos: el máximo que puede tener una identidad, útil para dejar que un equipo cree sus propios roles sin que se escalen permisos.
- Políticas de sesión: acotan una sesión temporal por debajo de lo que tiene el rol.
- Políticas de recursos, como la de un bucket: permiten dar acceso a otras cuentas.
Para el acceso entre cuentas hacen falta los dos lados: la identidad tiene que tener permiso en su cuenta y el recurso, o el rol que se asume, tiene que aceptarla en la otra. Es la fuente más común de un “acceso denegado” que nadie entiende mirando una sola política.
Lo que preguntan sobre esto
Cierre
Autoevaluación
¿Lo entendiste?
Práctica