La lógica de evaluación de IAM

Tarde o temprano te pasa: una política que parece correcta devuelve AccessDenied, o peor, un rol puede hacer algo que jurarías haber prohibido. Casi siempre la explicación no está en una política suelta, sino en cómo AWS las combina todas. Entender la lógica de evaluación de IAM es lo que separa «añadir otro Allow a ver si funciona» de razonar con precisión sobre quién puede hacer qué. Es la pieza central de todo el control de acceso en AWS, así que vale la pena hacerla bien.

Lógica de evaluación de IAM: la tubería de decisión

Identidad · IAM

Paso 1 de 5La petición

Un principal (un rol o usuario) firma una petición a una API de AWS, por ejemplo s3:GetObject. El punto de partida es siempre deny implícito: nada se permite salvo que algo lo permita.

El punto de partida: deny implícito#

Toda petición firmada a una API de AWS empieza denegada. Es el deny implícito: si ninguna política aplicable concede la acción, la respuesta es Deny. La única excepción es el usuario root de la cuenta, que tiene acceso total (una razón más para no usarlo nunca). Para que una petición se autorice tiene que estar explícitamente permitida por alguna política y no estar denegada por ninguna.

Esa asimetría es deliberada: equivocarte «hacia cerrado» es seguro; equivocarte «hacia abierto» es un incidente.

Las políticas que entran en juego#

En una misma cuenta, hasta seis tipos de política pueden aplicar a una petición. Dos conceden permisos; el resto solo recorta:

Tipo de política	¿Concede?	Alcance
RCP (Organizations)	No, limita	Máximo sobre los recursos de la cuenta
SCP (Organizations)	No, limita	Máximo para los principals de la cuenta
Política basada en recurso	Sí	Adjunta al recurso (bucket policy, key policy…)
Política basada en identidad	Sí	Adjunta al rol o usuario
Permission boundary	No, limita	Techo de permisos de esa identidad
Session policy	No, limita	Pasada al crear una sesión temporal (`AssumeRole`)

Las SCP y las RCP son barandillas de AWS Organizations: nunca conceden nada, solo definen el máximo posible. Las permission boundaries hacen lo mismo pero para una identidad concreta. Y las session policies acotan una sesión temporal sin cambiar el rol subyacente.

El algoritmo de decisión#

Cuando llega la petición, el motor de autorización de AWS evalúa, en este orden, el conjunto de políticas aplicables:

Barrido de Deny explícito: AWS mira todas las políticas a la vez (SCP, RCP, recurso, identidad, boundary, session) buscando un Deny que aplique. Si encuentra uno solo, la decisión final es Deny y no sigue.
RCP: ¿permiten los recursos de la cuenta esta acción? Si ninguna RCP aplicable concede, Deny implícito.
SCP: ¿permiten los principals de la cuenta esta acción? Si no, Deny implícito.
Política basada en recurso: un Allow aquí puede bastar por sí solo (con matices, abajo).
Política basada en identidad: si ninguna permite la acción, Deny implícito (salvo que ya la concediera el recurso).
Permission boundary: si la boundary no permite la acción, Deny implícito.
Session policy: si la petición usa una sesión y la session policy no permite la acción, Deny. Si todo lo anterior concede y nada deniega, el resultado final es Allow.

Fíjate en la forma: cada capa que limita solo puede empeorar la respuesta, nunca mejorarla. El permiso efectivo es la intersección de todas las capas aplicables.

Intersección, no unión#

El error mental más común es pensar en permisos como una suma: «le doy este Allow y aquel otro». Con las capas limitantes es justo al revés. Imagina un rol cuya política de identidad concede s3:GetObject y s3:PutObject, pero su permission boundary solo permite s3:GetObject:

Lo que parece

Lo que de verdad puede

identidad:  GetObject + PutObject
boundary:   GetObject
───────────────────────────────
¿efectivo?  GetObject + PutObject   ✕ falso

identidad:  GetObject + PutObject
boundary:   GetObject
───────────────────────────────
efectivo:   GetObject              ✓ la boundary recorta

PutObject está en la política pero no en la boundary, así que se deniega. La boundary no concede nada: solo recorta. Lo mismo vale para SCP y RCP respecto a la cuenta entera.

El caso especial de las políticas basadas en recurso#

Dentro de la misma cuenta, una política basada en recurso puede conceder acceso aunque la política de identidad del principal no lo permita explícitamente (es decir, aunque haya un deny implícito en la identidad). Un bucket que, en su bucket policy, permite s3:GetObject a un rol de la misma cuenta, le da acceso aunque el rol no tenga ninguna política de S3.

Hay excepciones importantes que siempre exigen un Allow explícito también en el lado del recurso:

Las trust policies de los roles (sts:AssumeRole debe permitirse explícitamente).
Las key policies de KMS: sin una declaración en la key policy, los permisos IAM por sí solos no bastan.

Cross-account: permiso en las dos cuentas#

Cuando el principal está en la cuenta A y el recurso en la cuenta B, AWS realiza dos evaluaciones independientes y solo autoriza si ambas devuelven Allow:

En la cuenta A (la del principal): su política de identidad debe permitirle actuar sobre el recurso de B, y sus capas limitantes (boundary, SCP) no deben denegar.
En la cuenta B (la del recurso): la política basada en recurso debe nombrar y permitir al principal de A, y las capas de B (RCP, SCP) no deben denegar.

Dicho de otra forma: necesitas permiso en las dos cuentas a la vez. Un Deny en cualquiera de ellas deniega toda la petición. Por eso dar acceso cross-account siempre son dos cambios: uno en el recurso y otro en la identidad.

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111111111111:role/citas-analytics" },
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::citas-informes/*"
}

{
  "Effect": "Allow",
  "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::citas-informes/*"
}

Errores comunes#

Tu turno

Reconstruye la decisión de una petición real

Elige una petición de tu entorno (o de tu lab) que haya devuelto AccessDenied o que te sorprenda que funcione.

Enumera todas las políticas que aplican: ¿hay SCP o RCP en la cuenta? ¿boundary en el rol? ¿es una sesión con session policy? ¿política de recurso?
Busca primero un Deny explícito en cualquiera de ellas. ¿Lo hay?
Si no, comprueba que exista un Allow en cada capa requerida. ¿Cuál falta?
Si es cross-account, verifica las dos cuentas por separado.
Contrasta tu conclusión con el Policy Simulator.

Reto

Un rol tiene una política de identidad que permite s3:DeleteObject, pero una SCP de la cuenta deniega s3:Delete* para todos. ¿Puede borrar?

▸Mostrar solución

No. La SCP tiene un Deny explícito que aplica a la acción, y un Deny explícito vence a cualquier Allow. Da igual lo permisiva que sea la política de identidad: la respuesta final es Deny. Para permitirlo habría que cambiar la SCP, no la política del rol.