Ya sabes que las políticas son los documentos que definen los permisos en AWS. Pero hay dos formas de aplicarlas, según dónde las adjuntes: a una identidad o a un recurso. Entender la diferencia te ayudará a leer y escribir permisos correctamente, y a resolver el clásico misterio de «¿por qué este permiso no funciona?».

Una política IAM es un documento JSON. Su pieza central es la declaración (statement), que responde a:

• Effect: Allow (permitir) o Deny (denegar).
• Action: qué se puede hacer (s3:GetObject = leer objetos de S3).
• Resource: sobre qué recurso (identificado por su ARN, el identificador único de cualquier recurso en AWS).

Esta política dice: «Permitir la acción leer objetos sobre los objetos del bucket informes-2026». No te preocupes por memorizar la sintaxis; lo importante es entender el concepto.

Se adjuntan a una identidad: un usuario, un grupo o un rol. Responden a la pregunta:

«¿Qué puede hacer ESTA identidad?»

Ejemplo: Adjuntas a la usuaria María una política que dice «puede leer del bucket informes-2026». El permiso viaja con María: allá donde actúe, puede leer ese bucket.

Es la forma más común. Cuando das permisos a tus usuarios y roles, normalmente usas políticas basadas en identidad.

Se adjuntan al recurso en sí: un bucket de S3, una cola SQS, una función Lambda… Responden a la pregunta:

«¿Quién puede acceder a ESTE recurso?»

Ejemplo: Adjuntas al bucket informes-2026 una política que dice «la cuenta de la empresa colaboradora puede leer mis objetos». El permiso viaja con el bucket: define quién puede entrar en él.

Ya viste un ejemplo en el Capítulo 5: las bucket policies de S3 son políticas basadas en recurso.

Analogía del edificio:

• Una política basada en identidad es como lo que tu tarjeta de empleado puede abrir. La llevas contigo; define a qué puertas puedes entrar tú.
• Una política basada en recurso es como la lista de personas autorizadas pegada en la puerta de una sala concreta. Define quién puede entrar a esa sala en particular.

A veces, para entrar a una sala, ambas deben coincidir: tu tarjeta debe permitir abrir esa puerta y tu nombre debe estar en la lista de la sala.

El caso estrella de las políticas basadas en recurso es el acceso entre cuentas (cross-account): cuando alguien de otra cuenta de AWS necesita acceder a algo tuyo, la política basada en recurso es la que lo permite, porque se aplica al recurso sin importar de qué cuenta venga quien accede.

Cuando alguien intenta hacer algo, AWS evalúa todas las políticas que aplican (las de identidad y las de recurso) con estas reglas, en este orden:

1. Por defecto, todo está denegado. Si nada lo permite, se deniega.
2. Un Allow explícito concede el permiso (puede venir de la política de identidad o de la de recurso).
3. Un Deny explícito SIEMPRE gana. Si cualquier política dice «denegar», se deniega, aunque otra diga «permitir».

Regla mental: «Deny gana a Allow, y sin Allow no hay permiso.» Esta regla resuelve casi todos los misterios de permisos en AWS.

Ejemplo del misterio típico: «Le di a María permiso para leer el bucket, pero no puede.» Posibles causas: hay un Deny explícito en algún sitio (que gana), o la política del recurso (bucket) no la incluye, o falta el Allow en su identidad. Conociendo la lógica de evaluación, sabes dónde mirar.

Para terminar, dos formas de organizar las políticas (no confundir con identidad/recurso):

• Gestionadas (managed): políticas reutilizables que adjuntas a varias identidades. AWS ofrece muchas predefinidas (como AmazonS3ReadOnlyAccess), y puedes crear las tuyas. Recomendadas por ser reutilizables y fáciles de mantener.
• En línea (inline): políticas escritas directamente dentro de una sola identidad. Útiles para permisos muy específicos de un único usuario o rol.

• Una política define permisos con Effect (allow/deny), Action (qué) y Resource (sobre qué, vía ARN).
• Basada en identidad: se adjunta a un usuario/grupo/rol → «¿qué puede hacer esta identidad?». Es lo más común.
• Basada en recurso: se adjunta al recurso (bucket, cola…) → «¿quién puede acceder a este recurso?». Clave para el acceso entre cuentas.
• Lógica de evaluación: todo denegado por defecto, un Allow concede, y un Deny explícito gana siempre.
• «Deny gana a Allow, y sin Allow no hay permiso» resuelve la mayoría de dudas.

En el siguiente subcapítulo veremos dos pilares de la seguridad de acceso: la autenticación multifactor (MFA) y las credenciales temporales (STS).