AWS IAM: Gestión de Identidades y Acceso

Lectura
35 min~8 min lectura
CONCEPTO CLAVE: AWS Identity and Access Management (IAM) es el servicio fundamental de AWS que te permite gestionar de forma segura quién puede acceder a tus recursos en la nube. Piensa en IAM como el sistema de control de accesos de un edificio corporativo: determina quién puede entrar, a qué pisos tiene acceso y qué operaciones puede realizar una vez dentro.

¿Qué es AWS IAM?

AWS Identity and Access Management (IAM) es un servicio web que te permite controlar de manera granular los permisos y accesos a los servicios y recursos de AWS. Con IAM, puedes crear usuarios, grupos y roles, asignarles políticas de seguridad, y definir quién tiene permiso para hacer qué en tu cuenta de AWS.

Antes de profundizar, es esencial entender que IAM opera bajo el modelo de privilegio mínimo: a cada usuario, aplicación o servicio se le deben otorgar únicamente los permisos estrictamente necesarios para realizar sus tareas específicas. Este principio es fundamental para mantener la seguridad en la nube.

📌 Nota importante: Por defecto, todos los permisos están denegados en AWS. Esto significa que, a menos que crees explícitamente una política que permita una acción, esta acción será bloqueada. Esta filosofía de "denegar por defecto" proporciona una capa adicional de seguridad.

Componentes Principales de IAM

1. Usuarios de IAM

Un usuario de IAM es una identidad dentro de AWS que representa a una persona específica o una aplicación. Cada usuario tiene su propio conjunto de credenciales (nombre de usuario, contraseña, claves de acceso) que pueden ser gestionadas de forma independiente.

Los usuarios son ideales para:

  • Representar a empleados que necesitan acceder a la consola de AWS
  • Identificar aplicaciones que requieren acceso programático a servicios de AWS
  • Gestionar accesos con auditorías detalladas por usuario
💡 Consejo práctico: Evita usar la cuenta root de AWS para operaciones diarias. En su lugar, crea usuarios individuales con permisos específicos y guarda las credenciales root solo para emergencias o tareas de administración críticas.

2. Grupos de IAM

Los grupos de IAM son colecciones de usuarios que comparten los mismos permisos. Imagina un grupo como un departamento en una empresa: todos los desarrolladores pueden pertenecer al grupo "Desarrolladores", todos los analistas al grupo "Analistas", etc.

Los grupos simplifican la administración porque:

  1. Permiten asignar permisos a múltiples usuarios simultáneamente
  2. Facilitan la auditoría al saber qué permisos tiene cada grupo
  3. Reducen la complejidad al no tener que gestionar permisos individualmente

3. Roles de IAM

Un rol de IAM es una identidad con permisos específicos que puede ser asumida por cualquier persona o servicio que lo necesite. A diferencia de los usuarios, los roles no tienen credenciales permanentes; en su lugar, proporcionan acceso temporal mediante un proceso llamado "asunción de rol".

Los roles son perfectos para:

  • Permitir que un servicio de AWS acceda a otro servicio (por ejemplo, una función Lambda accediendo a S3)
  • Otorgar acceso temporal a usuarios de otra cuenta AWS
  • Habilitar acceso federado desde sistemas externos (como tu proveedor de identidad corporativo)
  • Permitir que aplicaciones EC2 accedan a otros servicios de AWS
⚠️ Advertencia de seguridad: Los roles eliminan la necesidad de almacenar credenciales estáticas en código o configuraciones. Esto es crucial porque las credenciales embebidas en código pueden ser comprometidas accidentalmente si el código se comparte en repositorios públicos.

4. Políticas de IAM

Las políticas de IAM son documentos JSON que definen explícitamente los permisos. Son el mecanismo mediante el cual se otorgan o deniegan permisos a usuarios, grupos y roles.

Una política típica tiene la siguiente estructura:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::mi-bucket/*"
    }
  ]
}

donde:

  • Effect: Puede ser "Allow" (permitir) o "Deny" (denegar)
  • Action: Especifica las acciones permitidas o denegadas
  • Resource: Indica a qué recursos se aplica la política

Tipos de Políticas

Tipo de PolíticaDescripciónCasos de Uso
Gestionada por AWSPolíticas predefinidas por AWS que no puedes modificarPermisos estándar como AdministratorAccess, PowerUserAccess
Gestionada por el clientePolíticas que creas y gestionas tú mismoRequisitos específicos de tu organización
En línea (Inline)Políticas incrustadas directamente en un usuario, grupo o rolPermisos temporales o de un solo uso
💡 Recomendación: Utiliza políticas gestionadas siempre que sea posible. Son más fáciles de mantener, se versionan automáticamente y proporcionan protección contra errores de sintaxis.
Ver más: Ejemplo práctico de política de lectura para S3
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:GetObjectVersion",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::bucket-ejemplo",
        "arn:aws:s3:::bucket-ejemplo/*"
      ]
    }
  ]
}

Esta política permite a un usuario leer objetos y listar el contenido de un bucket específico de S3, pero no permite eliminar, modificar o crear objetos.

Autenticación Multifactor (MFA)

La Autenticación Multifactor (MFA) añade una capa adicional de seguridad requiriendo no solo tu contraseña sino también un código generado por un dispositivo físico o virtual. Es altamente recomendable, especialmente para:

  • La cuenta root de tu cuenta AWS
  • Usuarios con permisos administrativos
  • Acceso programático a recursos sensibles
📌 AWS soporta dispositivos MFA virtuales como Google Authenticator o Authy, además de dispositivos físicos como YubiKey y tokens Gemalto.

Acceso Programático vs Acceso a la Consola

Tipo de AccesoCredencialesUso
Consola de AWSNombre de usuario + contraseñaGestión visual y administrativa
Acceso ProgramáticoAccess Key ID + Secret Access KeyCLI, SDKs, APIs
"La seguridad no es un producto, sino un proceso. IAM te proporciona las herramientas, pero la implementación correcta depende de ti." — Principio de seguridad en la nube.

Mejores Prácticas de Seguridad con IAM

  1. Habilita MFA para todos los usuarios, especialmente para la cuenta root y usuarios con permisos elevados.
  2. Implementa el principio de privilegio mínimo: otorga únicamente los permisos necesarios para cada tarea.
  3. Utiliza grupos para gestionar permisos en lugar de asignar políticas directamente a usuarios individuales.
  4. Rotación regular de credenciales: cambia las claves de acceso periódicamente.
  5. Revisa y audita permisos utilizando AWS Access Analyzer y revisiones de acceso periódicas.
  6. Evita credenciales embebidas: usa roles para acceder a servicios desde instancias EC2, funciones Lambda, etc.
  7. Configura políticas de contraseñas fuertes que requieran longitudes mínimas, mayúsculas, minúsculas, números y caracteres especiales.
⚠️ Peligro común: Nunca compartas claves de acceso en código fuente, emails o mensajes. Si una clave se filtra, rotating credenciales de inmediato y revoca la clave comprometida.

AWS CLI y IAM

Puedes gestionar IAM directamente desde la línea de comandos usando AWS CLI. Aquí tienes algunos comandos esenciales:

# Crear un usuario
aws iam create-user --user-name nombre-usuario

# Agregar usuario a un grupo
aws iam add-user-to-group --user-name nombre-usuario --group-name nombre-grupo

# Crear una clave de acceso
aws iam create-access-key --user-name nombre-usuario

# Listar usuarios
aws iam list-users

# Listar políticas gestionadas
aws iam list-policies
Ver más: Comandos útiles para auditoría
# Listar todos los usuarios con sus claves de acceso
aws iam get-credential-report

# Ver cuándo fue la última vez que se usó una clave
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

# Listar políticas attached a un usuario
aws iam list-attached-user-policies --user-name nombre-usuario

Casos de Uso Comunes

Desarrollo Local

Los desarrolladores suelen necesitar acceso a recursos de AWS durante el desarrollo. La mejor práctica es crear un usuario dedicado con permisos específicos para el entorno de desarrollo, nunca usar la cuenta root.

💡 Herramienta recomendada: AWS Single Sign-On (SSO) se integra con IAM para proporcionar acceso centralizado a múltiples cuentas AWS usando las credenciales corporativas de tu empresa.

Aplicaciones en EC2

En lugar de guardar claves de acceso en una instancia EC2, utiliza roles de IAM. AWS proporcionará automáticamente credenciales temporales a la instancia:

# Crear un rol para una instancia EC2
aws iam create-role --role-name mi-rol-ec2 \
  --assume-role-policy-document file://trust-policy.json

# Adjuntar una política al rol
aws iam attach-role-policy --role-name mi-rol-ec2 \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess

Lambda Functions

Las funciones Lambda también utilizan roles de IAM para acceder a otros servicios AWS. Al crear una función, especificas un rol de ejecución que determina qué recursos puede acceder.

📌 Recuerda: Las políticas de Lambda son evaluadas cada vez que se ejecuta la función. Si necesitas cambiar permisos, simplemente actualiza la política del rol; no necesitas redesplegar la función.

Costos de IAM

IAM es un servicio gratuito. No importa cuántos usuarios, grupos o políticas crees; no se te cobrará por ello. Esta gratuidad hace que no haya excusa para no implementar controles de acceso adecuados.

🧠 Quiz: AWS IAM

¿Cuál es el principio fundamental que aplica AWS a los permisos por defecto?

  • A) Todos los permisos están concedidos por defecto
  • B) Todos los permisos están denegados por defecto
  • C) Los permisos dependen del tipo de cuenta
  • D) Los permisos se heredan del nivel superior
✅ Respuesta correcta: B) Todos los permisos están denegados por defecto. En AWS, cualquier acción que no esté explícitamente permitida está denegada. Este modelo de "denegar por defecto" proporciona seguridad inherente y requiere que los administradores definan explícitamente qué está permitido.
🧠 Quiz: AWS IAM

¿Cuál es la diferencia principal entre un rol de IAM y un usuario de IAM?

  • A) Los roles no tienen políticas, los usuarios sí
  • B) Los roles proporcionan acceso temporal, los usuarios tienen credenciales permanentes
  • C) Los roles son más seguros que los usuarios
  • D) No hay diferencia, son intercambiables
✅ Respuesta correcta: B) Los roles proporcionan acceso temporal mediante "asunción de rol", mientras que los usuarios tienen credenciales (contraseñas, claves de acceso) que persisten hasta que se revogan manualmente. Los roles son ideales para aplicaciones y servicios que necesitan acceder a recursos de AWS sin credenciales embebidas.

Conclusión

AWS IAM es el pilar fundamental de la seguridad en AWS. Dominar sus conceptos te permitirá implementar controles de acceso robustos, cumplir con requisitos de auditoría y proteger tus recursos en la nube de manera efectiva.

Recuerda siempre aplicar el principio de privilegio mínimo, utilizar MFA, preferenciar roles sobre credenciales embebidas, y realizar auditorías periódicas de permisos. Con estos fundamentos, estás preparado para construir arquitecturas seguras en AWS.

CONCEPTO CLAVE FINAL: IAM no es solo un servicio de AWS, es una filosofía de seguridad. Cada decisión de acceso debe responder a la pregunta: "¿Realmente necesita este nivel de acceso para cumplir su función?" Si la respuesta es no, entonces ese permiso no debería existir.