Si estás iniciando en el mundo de las certificaciones en el ecosistema de AWS, hay un servicio que encontrarás con bastante frecuencia: IAM (Identity and Access Management), por lo que no es menor decir que entender bien IAM te ayudará a comprender mucho mejor casi todo lo demás en AWS.
¿Qué es IAM? 🔐
IAM es el servicio que controla quién puede hacer qué dentro de tu cuenta de AWS. Imagínatelo como el sistema de llaves y permisos de un edificio: no le das la misma llave maestra a todo el mundo, sino que decides quién entra, a qué pisos llega y qué puede hacer una vez esté adentro.
En AWS, ese "quién" y el "qué puede hacer" se define en cuatro elementos principales: usuarios, grupos, roles y políticas.
Las cuatro piezas clave
Usuarios (Users): Puede ser una persona o aplicación específica que necesita acceso a la cuenta de AWS. Cada usuario tiene sus propias credenciales.
Grupos (Groups): Una forma de organizar usuarios que cuentan con permisos similares. En lugar de otorgar permisos uno a uno, creas un grupo (Ej.: "Desarrolladores") y le asignas los permisos al grupo, así cualquier usuario que exista o agregues al grupo tendrá esos permisos automáticamente. Esto simplifica muchísimo la administración cuando tienes varios usuarios.
Roles (Roles): Aquí es donde al iniciar muchos se confunden con los usuarios, así que vale la pena detallarlo. Un rol no pertenece a una persona fija, es un conjunto de permisos temporales que puede "asumir" quien lo necesite, puede ser un usuario, una aplicación, o incluso un servicio de AWS (Ej.: una función Lambda que necesita leer un bucket de S3). Los roles no tienen contraseña ni claves permanentes, se usan mediante credenciales temporales. Son la forma recomendada para dar acceso a servicios de AWS entre sí, en lugar de guardar claves de acceso dentro del código.
Políticas (Policies): Son documentos (en formato JSON) que definen exactamente qué acciones están permitidas o denegadas, y sobre qué recursos. Una política se puede asignar a un usuario, a un grupo o a un rol. Por ejemplo, una política puede ser: "permitir leer objetos del bucket S3 llamado "fotos", pero no borrarlos".
Una buena práctica que los exámenes SAA y CCP suelen preguntar
Actualmente me estoy preparando para presentar la certificación AWS Solutions Architect Associate y un principio que observo constantemente en los materiales de preparación (igual cuando presenté Cloud Practitioner), es el mínimo privilegio (least privilege). Este indica que sean otorgados únicamente los permisos estrictamente necesarios para realizar una tarea, ni uno más. De esta forma es más fácil ampliar permisos después si hace falta que luego enfrentar las consecuencias de haber dado demasiados accesos desde el inicio.
👀 Otras recomendaciones oficiales de AWS que conviene tener presente:
Evitar políticas que otorguen privilegios administrativos completos (el famoso "*").
No asignar políticas directamente a usuarios individuales y procurar siempre usar grupos o roles en su lugar.
Habilitar MFA (autenticación multifactor) para todos los usuarios con acceso a la consola.
Un ejemplo simple para fijar la idea💡
Imagina que tienes una aplicación corriendo en una instancia EC2 y esa aplicación necesita leer archivos de un bucket S3. La forma correcta no es guardar las claves de acceso de un usuario dentro del código de la aplicación. En su lugar, creas un rol de IAM con permisos de lectura sobre ese bucket específico y se lo asignas a la instancia EC2. La aplicación obtiene credenciales temporales automáticamente, sin que nadie tenga que manejar ni rotar claves manualmente.
Cómo seguir aprendiendo
Si quieres profundizar acerca de este importante tema, la documentación oficial de IAM y la guía de mejores prácticas de seguridad son excelente material. También puedes practicar creando usuarios, grupos y roles de prueba en una cuenta gratuita, para ver cómo se comportan los permisos en la práctica, es la mejor forma de que estos conceptos se logren comprender muy bien.
Ahora, ¿tienes mas clara la diferencia entre usuarios, roles, grupos y políticas? Cuéntame en los comentarios qué parte de IAM es mas desafiante para ti, puede ser tema de un próximo artículo.
Top comments (0)