Venimos con buen ritmo: aseguramos la cuenta root, entendimos IAM con sus usuarios, policies y roles, usamos S3, configuramos alertas con Budgets y en el post anterior creamos nuestra primera Organización con AWS Organizations. Ahora que sabemos que lo profesional es trabajar con múltiples cuentas, aparece una pregunta incómoda: ¿cómo hacemos para entrar a todas esas cuentas sin volvernos locos creando un usuario IAM en cada una? Para eso existe IAM Identity Center (antes llamado AWS SSO). En este post vamos a ver qué es, por qué es la forma recomendada de acceder a AWS y cómo configurarlo paso a paso.
El problema de manejar múltiples cuentas
Imaginate que tenés tres cuentas: una de administración, una de desarrollo y una de producción. Si usáramos usuarios IAM tradicionales, cada persona necesitaría:
- Un usuario y una contraseña distintos en cada cuenta.
- Configurar MFA por separado en cada una.
- Recordar en qué cuenta está cada cosa y cambiar de sesión constantemente.
Y cuando alguien se suma o se va del equipo, habría que crear o borrar su usuario en todas las cuentas, una por una. Es tedioso, propenso a errores y una pesadilla de seguridad. IAM Identity Center resuelve exactamente esto.
¿Qué es IAM Identity Center?
IAM Identity Center es un servicio gratuito que nos da un único punto de acceso (Single Sign-On) a todas las cuentas de nuestra Organización y, si queremos, a aplicaciones externas. Con un solo usuario, una sola contraseña y un solo MFA, cada persona puede entrar a las cuentas que tenga asignadas.
Lo más importante desde el punto de vista de seguridad: no crea usuarios IAM permanentes en cada cuenta. En su lugar, cuando alguien entra a una cuenta, IAM Identity Center le entrega credenciales temporales a través de un rol. Menos secretos de larga vida dando vueltas significa menos superficie de ataque.
Nota sobre costos: IAM Identity Center no tiene costo adicional. El directorio interno, los usuarios, los grupos, los permission sets y hasta el MFA integrado están incluidos sin cargo. Solo pagarías extra si conectaras un proveedor de identidad externo de pago, pero eso es totalmente opcional.
Conceptos clave
Antes de configurarlo, entendamos las piezas principales:
Origen de identidad (Identity Source)
Es el lugar donde “viven” nuestros usuarios. Tenemos tres opciones:
- Identity Center directory: un directorio interno que provee el propio servicio. Es la opción más simple y gratuita, y es la que vamos a usar.
- Active Directory: conectar un directorio corporativo de Microsoft ya existente.
- Proveedor de identidad externo (External IdP): integrar un IdP como Okta o Microsoft Entra ID vía SAML.
Usuarios y Grupos
Los usuarios son las personas que van a acceder. Los grupos nos permiten agruparlos (por ejemplo, Administradores o Desarrolladores) para asignarles permisos en conjunto, en vez de uno por uno.
Permission sets (Conjuntos de permisos)
Son plantillas de permisos que definen qué puede hacer alguien dentro de una cuenta. Un permission set es básicamente una colección de policies IAM (por ejemplo, AdministratorAccess o ReadOnlyAccess). Cuando lo asignamos a una cuenta, IAM Identity Center crea automáticamente un rol IAM detrás de escena con esos permisos.
Asignaciones (Account assignments)
Es la relación que une las tres cosas: quién (usuario o grupo) tiene qué permisos (permission set) en cuál cuenta. Esta es la magia que nos deja gobernar el acceso a toda la Organización desde un solo lugar.
Portal de acceso (AWS access portal)
Es la URL única donde cada persona se loguea. Una vez adentro, ve las cuentas y roles que tiene asignados y entra a cualquiera con un clic, sin manejar credenciales por cuenta.
Requisito previo: para seguir este post necesitás tener una Organización creada (lo hicimos en el post anterior) y estar operando desde la Management Account.
Paso 1: Buscar IAM Identity Center
Desde la consola de AWS, buscamos IAM Identity Center en la barra de búsqueda y hacemos clic en el resultado.
Paso 2: Habilitar el servicio
En la página del servicio, AWS nos explica que IAM Identity Center sirve para centralizar el acceso de los usuarios a múltiples cuentas y aplicaciones de AWS. A la derecha vemos el botón Enable. Un detalle importante: IAM Identity Center es un servicio regional, así que fijate que arriba a la derecha esté seleccionada la región donde querés alojarlo (en el ejemplo, US East / N. Virginia). Conviene elegirla con criterio, porque moverla después implica reconfigurar todo. Hacemos clic en Enable.
Paso 3: Confirmar la región y la instancia de organización
AWS nos lleva a la pantalla de confirmación, donde aparece un detalle clave: como ya tenemos una Organización (la creamos en el post anterior), vamos a usar una organization instance de IAM Identity Center. Este tipo de instancia soporta todas las funcionalidades, incluida la gestión de permisos para múltiples cuentas de la Organización.
También nos pide confirmar la región (en nuestro caso, US East N. Virginia) y, dentro de Advanced configuration, la clave para cifrar los datos en reposo. Dejamos la opción por defecto, Use AWS owned key (una clave gestionada por el propio AWS), que es suficiente para empezar. Hacemos clic en Enable.
Paso 4: Dashboard y portal de acceso
Una vez habilitado, AWS nos confirma con un banner verde que se creó la organization instance y nos lleva al dashboard del servicio. En la sección IAM Identity Center setup tenemos los pasos recomendados para terminar la configuración: confirmar el origen de identidad y asignar permisos a las cuentas. A la derecha, en Settings summary, hay un resumen muy útil: el origen de identidad (Identity Center directory), la Primary Region (us-east-1), el Organization ID y, muy importante, las URLs del portal de acceso (algo como https://d-xxxxxxxxxx.awsapps.com/start). Esa es la dirección que van a usar los usuarios para loguearse, y más adelante podemos personalizarla.
Paso 5: Confirmar el origen de identidad
Vamos a Settings y entramos a la pestaña Identity source. Por defecto viene configurado como Identity Center directory, el directorio interno del servicio, con Authentication method: Password y Provisioning method: Direct. Para nuestro caso es perfecto: no necesitamos conectar Active Directory ni un IdP externo, así que lo dejamos tal cual. Si algún día quisiéramos cambiarlo, se hace desde el botón Actions.
Paso 6: Crear un usuario
En el menú izquierdo vamos a Users. Como todavía no tenemos ninguno, la lista aparece vacía. Hacemos clic en Add user.
Se abre un asistente de tres pasos. En el Step 1 (Specify user details) completamos la información principal: el Username (ojo, no se puede cambiar después y es el que la persona va a usar para entrar al portal). En Password dejamos la opción Send an email to this user with password setup instructions, así el propio usuario define su contraseña y nosotros no la manejamos nunca. Después cargamos el email, el First name, el Last name y el Display name.
Más abajo hay varias secciones opcionales (Contact methods, Job-related information, Address, etc.) que podemos ignorar por ahora. Hacemos clic en Next.
En el Step 2 (Add user to groups) podríamos sumar el usuario a un grupo, pero como todavía no creamos ninguno, la lista aparece vacía. Lo dejamos así y hacemos clic en Next.
Por último, en el Step 3 (Review and add user) revisamos que todo esté correcto y hacemos clic en Add user para crear el usuario.
Con el usuario ya creado, en el siguiente paso armamos un grupo y lo sumamos ahí.
Paso 7: Crear un grupo
Aunque por ahora tengamos un solo usuario, la buena práctica es asignar permisos a grupos, no a personas sueltas. Vamos a Groups y, como todavía no hay ninguno, hacemos clic en Create group.
En el formulario le ponemos un Group name (en nuestro caso Administradores) y, en la sección Add users to group, seleccionamos el usuario que creamos antes (leonardo). Confirmamos con Create group. De esta forma, cualquier permiso que le demos al grupo lo va a heredar automáticamente el usuario. El día de mañana, sumar a alguien nuevo es tan simple como meterlo en el grupo.
Paso 8: Crear un permission set
Ahora definimos qué van a poder hacer. Vamos a Permission sets y, como todavía no hay ninguno, hacemos clic en Create permission set.
En el Step 1 elegimos el tipo. AWS nos ofrece dos opciones: Predefined permission set (una plantilla lista, basada en una policy administrada por AWS) o Custom permission set (a medida). Elegimos Predefined y, en la lista de policies, seleccionamos AdministratorAccess, que otorga acceso total.
Si bajamos un poco vemos la lista completa de policies predefinidas: además de AdministratorAccess, hay opciones más acotadas como ReadOnlyAccess, PowerUserAccess, Billing o ViewOnlyAccess, ideales cuando querés aplicar privilegio mínimo. Con AdministratorAccess marcado, hacemos clic en Next.
En el Step 2 le ponemos el nombre al permission set (dejamos AdministratorAccess) y definimos la Session duration, es decir, cuánto dura la sesión antes de tener que volver a autenticarse (por defecto, 1 hour). El resto de los campos son opcionales. Hacemos clic en Next.
Por último, en el Step 3 revisamos el resumen y hacemos clic en Create.
Paso 9: Asignar el acceso a la cuenta
Ya tenemos el quién (el grupo) y el qué (el permission set). Falta el dónde. Vamos a AWS accounts, seleccionamos la cuenta a la que queremos dar acceso y hacemos clic en Assign users or groups.
En el Step 1 vamos a la pestaña Groups y seleccionamos nuestro grupo Administradores. Hacemos clic en Next.
En el Step 2 elegimos el permission set que creamos, AdministratorAccess. Hacemos clic en Next.
En el Step 3 revisamos que esté todo bien (el grupo Administradores con el permission set AdministratorAccess) y hacemos clic en Submit. IAM Identity Center crea automáticamente el rol IAM correspondiente en la cuenta.
Paso 10: Entrar por el portal de acceso
¡Momento de la verdad! Abrimos la URL del portal de acceso que vimos en el dashboard. La primera vez, el usuario acepta la invitación que le llegó por email, configura su contraseña y registra su MFA. Ya adentro, en la pestaña Cuentas el portal muestra las cuentas a las que tenemos acceso. Al desplegar nuestra cuenta aparece el rol AdministratorAccess: con un clic entramos a la consola de esa cuenta, o con Claves de acceso obtenemos credenciales temporales para usar el CLI.
MFA y buenas prácticas
Ahora que tenemos el acceso centralizado funcionando, algunas recomendaciones importantes:
- Activá MFA para todos: el MFA integrado es gratuito y soporta apps de autenticación, llaves de seguridad y passkeys. En un entorno serio debería ser obligatorio.
- Aplicá el privilegio mínimo: no le des
AdministratorAccessa todo el mundo. Creá permission sets más acotados (por ejemplo,ReadOnlyAccesso uno custom) según lo que cada rol necesite. - Asigná a grupos, no a personas: facilita el alta y baja de gente y mantiene el acceso ordenado.
- Personalizá la URL del portal: en Settings podés cambiar el subdominio por uno más fácil de recordar para tu equipo.
- Dejá de usar usuarios IAM de larga vida: una vez que tenés Identity Center, es la puerta de entrada recomendada. Los usuarios IAM con credenciales permanentes deberían ser la excepción, no la regla.
Conclusiones
En este post configuramos IAM Identity Center y logramos algo clave para trabajar de forma profesional en AWS: un acceso centralizado, seguro y sin costo a todas nuestras cuentas. Entendimos el origen de identidad, creamos usuarios y grupos, definimos permisos con permission sets y los asignamos a una cuenta, todo desde un único lugar. Además, dijimos adiós a las credenciales de larga vida gracias a los accesos temporales.
En el próximo post vamos a activar AWS CloudTrail a nivel de Organización, para tener un registro de auditoría centralizado de todo lo que pasa en nuestras cuentas. Si controlamos quién entra (Identity Center), el siguiente paso lógico es registrar qué hace cada uno.