Configurar mal un permiso en AWS puede costarte caro. Un pasante con accesos abiertos cambió las credenciales del admin de un banco y extrajo datos sensibles. Aprender AWS IAM (Identity and Access Management) es lo que separa una cuenta segura de una catástrofe, y aquí te explico cómo aplicarlo paso a paso si te preparas para la certificación de Solutions Architect.

Qué es IAM en AWS y por qué es tan crítico

IAM es el módulo donde defines quién entra a tu cuenta de AWS y qué puede hacer adentro. Sus siglas significan Identity and Access Management y funciona como el portero, el guardia y el reglamento de tu infraestructura, todo en uno [0:32].

Desde ahí controlas usuarios, permisos y políticas para que cada persona o servicio acceda solo a lo que necesita. Ni más, ni menos.

¿Qué hace IAM en AWS? Gestiona identidades y permisos dentro de tu cuenta. Define usuarios, grupos, roles y políticas para controlar quién accede a qué recursos y bajo qué condiciones.

Cuáles son los tipos de usuarios en AWS

AWS distingue dos grandes categorías de usuarios, y entender la diferencia es la primera línea de defensa de tu cuenta [0:51].

Por qué no debes usar el usuario root en el día a día

El usuario root es con el que creaste la cuenta. Tiene permisos absolutos sobre todo, por eso se le llama superusuario. La recomendación es clara:

• Asígnale una contraseña muy fuerte.
• Activa doble factor de autenticación (MFA).
• Guárdalo y olvídate de él para tareas diarias.

Usarlo a diario es como andar con la llave maestra del edificio en el bolsillo.

Cuándo conviene usar un usuario IAM

El usuario IAM es el que sí debes usar. Es controlado, limitado y le defines exactamente qué permisos tiene. Puedes crear uno por persona, por rol o por función dentro de la organización [1:25].

Qué tipos de identidades existen dentro de IAM

Dentro de los usuarios IAM hay cuatro tipos de identidades, y cada una resuelve un problema distinto [1:43].

• Usuarios: la unidad básica. Uno por persona o por función.
• Grupos: agrupan permisos por rol, por ejemplo developers, admins o finanzas. Si alguien cambia de equipo, mueves al usuario de grupo y los permisos se ajustan solos.
• Usuarios federados: conectan AWS con plataformas externas como Azure Active Directory o Google Workspace, evitando duplicar credenciales.
• Roles: identidades sin credenciales permanentes. Sus credenciales son temporales y se asignan para acciones específicas o para que un servicio de AWS se comunique con otro.

Los roles son especialmente útiles cuando una instancia EC2 o una función Lambda necesita acceder a un archivo en S3. En lugar de exponer access keys de un usuario, AWS asigna credenciales temporales que duran minutos. Más seguro y más limpio [2:42].

Cómo se conectan los usuarios IAM en la práctica

Un usuario humano como Bob suele tener dos vías de acceso: usuario y contraseña para la consola web, y access keys para conectarse vía CLI, SDK o aplicaciones [3:09].

En cambio, un usuario para CI/CD, al ser puramente programático, solo necesita access keys. Nada de consola.

Cómo funcionan las políticas de IAM

Las políticas son el documento que dice quién puede hacer qué sobre cuáles recursos. Conceden permisos basados en identidad o en recursos, y son el corazón del control de accesos en AWS [3:38].

Qué tipos de políticas puedes crear en AWS

Dentro de IAM encuentras tres tipos principales:

• Políticas manejadas por AWS: preconfiguradas para casos comunes, como S3 Full Access. Útiles, pero suelen ser demasiado amplias.
• Políticas custom: las creas tú y puedes reutilizarlas entre usuarios, grupos y roles.
• Políticas inline: viven solo dentro de un usuario o rol específico. No se reutilizan, por eso no son recomendadas.

La buena práctica es dar el mínimo privilegio posible. Si un rol solo necesita listar buckets, no le des full access a S3 [5:30].

¿Qué es una política inline en IAM? Es una política asociada exclusivamente a una identidad específica. No se puede reutilizar en otros usuarios o roles, lo que la hace difícil de mantener.

Cómo se estructura una política en JSON

Una política IAM en JSON tiene secciones bien definidas [6:52]:

• Version: la versión del lenguaje de políticas.
• Statement: uno o más bloques de permisos.
• Effect: puede ser Allow o Deny.
• Action: la acción permitida, por ejemplo s3:ListBucket o s3:GetObject.
• Resource: sobre qué recursos aplica. Un asterisco * significa todos.

Puedes crear políticas con el editor visual seleccionando servicio, acciones y recursos, o escribiendo el JSON directamente. El editor visual es más rápido si no recuerdas los nombres exactos de las acciones.

Cómo crear un rol para que EC2 acceda a S3

Este es uno de los casos más frecuentes en arquitecturas AWS: una instancia EC2 que necesita leer o escribir en un bucket de S3 [4:50].

El flujo en consola es directo:

1. Entras a la sección Roles dentro de IAM.
2. Eliges el caso de uso, en este ejemplo EC2.
3. Asignas una política, por ejemplo una manejada por AWS para S3.
4. Le das un nombre claro como EC2AccessS3.
5. Creas el rol y lo asocias a la instancia.

Así evitas pegar access keys dentro del código o en variables de entorno. Las credenciales temporales se manejan automáticamente.

Cuáles son las mejores prácticas de seguridad en IAM

Las reglas básicas que evitan el 90% de los incidentes son simples [9:21]:

• Activa doble factor de autenticación en todos los usuarios.
• Usa siempre usuarios IAM, nunca el root para tareas diarias.
• Aplica el principio de mínimo privilegio en cada política.
• Prefiere roles temporales sobre access keys cuando sea un servicio AWS hablando con otro.
• Crea políticas custom reutilizables en lugar de inline.

¿Recuerdas el caso del pasante que escaló privilegios al admin? La política que tenía esa cuenta queda en los recursos. Cuéntame en los comentarios qué error encuentras y cómo lo corregirías.