Implementación IAM AWS: la guía 2026 en 5 pasos

La implementación IAM en AWS arranca creando grupos con permisos específicos, migrando usuarios desde un CSV con un script, activando MFA obligatorio y aplicando una política de contraseñas fuerte. Es gratis, viene en toda cuenta y es el primer control de seguridad que tenés que dejar fijo antes que cualquier otra cosa.

AWS IAM (Identity and Access Management) es el servicio de AWS que controla quién puede entrar a tu cuenta y qué puede hacer adentro. Maneja usuarios, grupos, roles y políticas de permisos. Es gratuito, está disponible en todas las cuentas desde el primer día y funciona bajo el modelo de responsabilidad compartida: AWS asegura la nube, vos asegurás lo que metés en ella.

¿Qué es AWS IAM y por qué es crítico para la seguridad?

Ponele que abrís una cuenta de AWS, generás las claves del usuario root y empezás a tirar comandos con eso. Todo anda. Hasta que esa clave se filtra en un repo de Git y, de golpe, cualquiera puede levantar instancias, borrar bases y dejarte una factura de cinco cifras. Ese es exactamente el escenario que IAM existe para evitar.

La idea es simple: nadie debería trabajar con el root. En su lugar, creás identidades acotadas (usuarios y roles) y les das solo los permisos que necesitan. Acá entra el modelo de responsabilidad compartida que repite AWS hasta el cansancio: la infraestructura física, los data centers y el hipervisor los cuida AWS; los permisos, las claves y quién accede a qué, los cuidás vos.

Lo bueno es que IAM no cuesta un peso. Está en todas las cuentas y es lo primero que conviene dejar configurado, antes de levantar un solo servidor. Si vas a montar infraestructura cloud para tu proyecto, este es el paso cero. Y si después necesitás hosting o cloud administrado en Argentina, podés mirar las opciones de donweb.com para la capa que no querés gestionar a mano.

Paso 1: ¿Cómo creo grupos IAM con permisos específicos?

Los grupos son la forma de no volverte loco asignando permisos uno por uno. En vez de darle 12 políticas a cada usuario, se las das al grupo y metés a la persona adentro. Si mañana cambia de equipo, la sacás de un grupo y la ponés en otro. Listo. Sobre eso hablamos en gestionar credenciales en integraciones API.

El proyecto base de IAM que circula en la comunidad arranca con cinco grupos que cubren los roles típicos de una empresa:

• Administradores de la cuenta AWS: acceso completo, solo para quienes manejan facturación y configuración global.
• Administradores de servidores Linux: EC2, Systems Manager y poco más.
• Administradores de red: VPC, subnets, security groups, balanceadores.
• Administradores de base de datos: RDS, DynamoDB y backups.
• Acceso limitado para becarios: permisos de solo lectura para que aprendan sin romper nada.

Para crearlos vas a IAM → User groups → Create group en la consola. Un detalle práctico: los nombres de grupo aceptan hasta 128 caracteres, son únicos por cuenta y no diferencian mayúsculas de minúsculas. O sea, “Administradores” y “administradores” son el mismo grupo para AWS. Anotá los nombres exactos que uses, porque el CSV del próximo paso tiene que coincidir letra por letra.

Paso 2: Preparar el archivo CSV para migrar usuarios

El script de migración espera un CSV con exactamente tres columnas: nombre del usuario, el usuario sin el dominio del mail y el equipo (que tiene que ser el nombre del grupo). Nada más, nada menos.

Si arrancás desde una planilla de Excel con los datos de tu gente, hacé estos ajustes antes de exportar:

• Renombrá la columna de mails y sacale el dominio. Si tenés [email protected], dejá solo juan. Usá Buscar y Reemplazar para volar el @empresa.com de un saque.
• Renombrá la columna de equipos y ajustá cada valor para que coincida exacto con los nombres de grupo que creaste en el Paso 1.
• Guardá como CSV separado por coma, en UTF-8. Si lo guardás en otra codificación, las tildes y las ñ te van a saltar como caracteres raros.

Una contraseña inicial estándar tipo AlterarContraseña@123! sirve para todos, porque después la van a tener que cambiar sí o sí en el primer ingreso (eso lo configurás en el Paso 5). El punto fino acá es la columna de equipo: si un nombre no matchea con ningún grupo, el script va a fallar para ese usuario y te vas a comer un error medio críptico. Revisá dos veces. Para más detalles técnicos, mirá configurar permisos en tus pipelines CI/CD.

Paso 3: ¿Cómo automatizo la creación de usuarios con un script?

Crear 40 usuarios a mano en la consola es un castigo. Por eso el proyecto usa un script que lee el CSV y, fila por fila, crea el usuario, le asigna la contraseña temporal y lo mete en su grupo. Los comandos clave de AWS CLI son tres:

• aws iam create-user --user-name NOMBRE: crea la identidad.
• aws iam create-login-profile --user-name NOMBRE --password "AlterarContraseña@123!" --password-reset-required: le da acceso a consola y lo obliga a cambiar la clave al entrar.
• aws iam add-user-to-group --user-name NOMBRE --group-name GRUPO: lo suma al grupo que corresponde.

Un script en Bash o Python recorre el CSV y dispara estos tres comandos por cada fila. ¿Y cómo verificás que salió bien? Corrés aws iam list-users y aws iam get-group --group-name GRUPO para confirmar que cada persona quedó donde tenía que quedar. Si automatizás esto, lo que tardabas una mañana te lo sacás en dos minutos (spoiler: la primera vez igual vas a tener que debuggear el CSV).

Paso 4: ¿Cómo configuro MFA obligatorio en IAM?

MFA (autenticación multifactor) suma un segundo factor además de la contraseña: un código que cambia cada 30 segundos. Aunque te roben la clave, sin ese segundo factor no entran. Para cualquier usuario con permisos administrativos, esto no es opcional.

AWS soporta varios tipos de dispositivo MFA, y conviene elegir según el caso:

Tipo de MFA	Ejemplos	Cuándo conviene
App autenticadora (TOTP virtual)	Google Authenticator, Microsoft Authenticator, Authy	Uso general, gratis, rápido de configurar
Llave de seguridad física (FIDO)	YubiKey y similares	Cuentas root y admins críticos, máxima protección anti-phishing
Passkey / biometría	Touch ID, Windows Hello	Equipos modernos, comodidad sin app aparte

Para activarlo, entrás a IAM → Users → (usuario) → Security credentials → Assign MFA device, escaneás el QR con la app y confirmás dos códigos seguidos. Un dato útil: AWS permite hasta 8 dispositivos MFA por usuario, así que podés registrar el celular y una llave física de respaldo para no quedarte afuera si perdés el teléfono. Empezá por el usuario root y seguí por los administradores.

Paso 5: Aplicar una política de contraseñas fuerte

La política de contraseñas se configura una vez para toda la cuenta, en IAM → Account settings → Password policy. Es la red de seguridad para que nadie ponga “123456” y se quede tranquilo. Relacionado: acceso seguro a bases de datos cloud.

Los requisitos mínimos que conviene dejar:

• Longitud mínima de 12 caracteres. Cuanto más larga, más cuesta romperla por fuerza bruta.
• Mayúsculas, minúsculas, números y símbolos obligatorios todos juntos.
• Cambio forzado en el primer login, que se aplica con el flag --password-reset-required del Paso 3.
• Prohibir reutilizar las últimas contraseñas para que no roten entre dos claves de siempre.

La clave temporal AlterarContraseña@123! que pusiste en el script cumple todos estos requisitos, por eso funciona como inicial. Eso sí: nunca la dejes fija. La gracia es que el usuario la cambie apenas entra.

Errores de seguridad que tenés que evitar en IAM

Estos son los tropezones más comunes en una implementación IAM real, y cómo zafar de cada uno:

• Usar "Action": "*" con "Resource": "*": eso es darle permiso a todo sobre todo. Si esa identidad se compromete, perdiste la cuenta entera. Lo correcto es el privilegio mínimo: solo los permisos que la tarea necesita.
• Trabajar con el usuario root todos los días: el root debería quedar guardado con MFA físico y usarse solo para tareas que ningún otro usuario puede hacer. Para el día a día, usuarios IAM.
• No rotar las access keys: una clave de hace tres años que anduvo dando vueltas en scripts es una bomba de tiempo. Rotalas y borrá las que no se usan.
• Saltarse el MFA “por ahora”: ese “después lo activo” es justo donde entran los ataques. Activalo desde el primer usuario admin.
• No auditar nada: si no tenés CloudTrail prendido, no sabés quién hizo qué. Cuando pasa algo raro, es tu única forma de reconstruir la historia.

Validar que todo funciona: testing de acceso y permisos

Configuraste todo. ¿Cómo sabés que de verdad quedó bien? Probando.

• Entrá con un usuario de prueba de cada grupo y confirmá que puede hacer lo suyo y nada más. El becario no debería poder borrar una instancia.
• Verificá que el MFA es obligatorio: intentá entrar sin el segundo factor y comprobá que te frena.
• Pasá IAM Access Analyzer para detectar recursos que quedaron expuestos a entidades externas sin que te dieras cuenta.
• Confirmá la política de contraseñas creando un usuario nuevo: si te deja poner una clave débil, algo quedó mal.
• Dejá CloudTrail prendido para registrar cada acción. Es tu caja negra cuando hay que investigar.

El testing no es opcional. Una política mal escrita puede dar más permisos de los que creés, y eso solo lo ves probando con un usuario real, no leyendo el JSON.

Preguntas Frecuentes

¿Qué es IAM en AWS?

IAM (Identity and Access Management) es el servicio de AWS que controla quién accede a tu cuenta y qué puede hacer. Administra usuarios, grupos, roles y políticas de permisos. Es gratuito y viene activo en todas las cuentas de AWS.

¿Cómo creo grupos de usuarios en AWS IAM?

Entrás a IAM → User groups → Create group en la consola, le ponés un nombre y le adjuntás las políticas de permisos. Los nombres aceptan hasta 128 caracteres y son únicos por cuenta. Después sumás usuarios al grupo en vez de asignar permisos uno por uno. Te puede servir nuestra cobertura de automatización con control granular de permisos.

¿Cuántos dispositivos MFA puedo asociar a un usuario IAM?

AWS permite hasta 8 dispositivos MFA por usuario IAM. Sirve para tener respaldo: podés registrar la app del celular y una llave física, así no te quedás afuera si perdés uno de los dos.

¿Cómo automatizo la migración de usuarios a IAM?

Con un script de AWS CLI que lee un CSV de tres columnas (nombre, usuario sin dominio, equipo) y ejecuta create-user, create-login-profile y add-user-to-group por cada fila. Validás el resultado con aws iam list-users.

¿Cuál es la mejor práctica de seguridad más importante en IAM?

El privilegio mínimo: darle a cada identidad solo los permisos que necesita para su tarea, nunca Action:* con Resource:*. Combinado con MFA obligatorio y no usar el usuario root para el trabajo diario, cubrís lo esencial.

Conclusión

Una implementación IAM en AWS bien hecha no es un proyecto de meses: son cinco pasos concretos que dejás fijos en una tarde. Grupos con permisos acotados, usuarios migrados por script, MFA obligatorio, política de contraseñas fuerte y validación con Access Analyzer y CloudTrail. Eso te separa de la mayoría de las cuentas que andan dando vueltas con el root abierto y claves sin rotar.

Si recién arrancás, hacé esto antes de levantar un solo servidor. Es gratis, lleva poco y te ahorra el dolor de cabeza de descubrir un acceso indebido cuando ya es tarde. El orden importa: primero los grupos, después los usuarios, y recién ahí lo demás. Empezá por activar MFA en el root hoy mismo.

Fuentes

• Documentación oficial de AWS – Buenas prácticas de seguridad en IAM
• AWS IAM – Cómo crear grupos de usuarios
• AWS IAM – Funcionalidades de autenticación multifactor (MFA)
• Projeto Cloud: Implementação IAM – guía práctica paso a paso
• Guía completa sobre AWS IAM: usuarios, grupos, permisos y buenas prácticas