Cuando creas tu cuenta de AWS naces con un usuario que puede hacer todo. Borrar todo, gastar sin límite, cerrar la cuenta.
Y el primer consejo de AWS sobre ese usuario es que casi nunca lo uses.
Eso no es una contradicción, es el resumen de cómo funciona la seguridad en AWS. El sistema que decide quién puede hacer qué se llama IAM (Identity and Access Management), es gratis, y es lo que separa "me borraron un archivo" de "me borraron la empresa".
Aquí te explico cómo funciona, cuál es la regla que explica todo lo demás, y por qué casi todos los tutoriales de IAM que vas a encontrar te van a dar un consejo que AWS ya dejó de recomendar.
Si no sabes qué es AWS, empieza por aquí.
El problema: el usuario que puede todo
Al abrir la cuenta te dan el usuario root, que es el dueño absoluto. No hay nada que no pueda hacer.
Si alguien se roba esas credenciales, se acabó. Te vacían la cuenta, te generan una factura de terror o borran todo lo que tengas.
Y si trabajas en equipo el problema es otro: no quieres que veinte personas anden con el poder de borrarlo todo, aunque confíes en las veinte. Basta con que una se equivoque.
Qué es IAM
IAM es el sistema que decide quién puede hacer qué sobre cuáles recursos de tu cuenta. Tiene cuatro piezas y no son complicadas:
- Usuarios: una persona o una aplicación.
- Grupos: un montón de usuarios juntos, por ejemplo "desarrollo".
- Roles: un sombrero temporal que alguien se pone para tener ciertos permisos un rato, y luego se lo quita.
- Políticas: el documento que dice qué se permite y qué se prohíbe.
Los roles son la pieza que menos se entiende al principio y la más importante, así que guárdala. Vamos a volver a ella.
La regla que explica todo lo demás
Una política es un archivo JSON, o sea un formato de texto con una estructura fija. Esta, por ejemplo, deja leer los archivos de un solo lugar y nada más:
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::mi-bucket/*"
}
Se lee casi como se ve: permite la acción de leer objetos, sobre ese bucket, y ya.
Ahora, lo que de verdad hay que entender es cómo decide AWS. Son tres reglas y con ellas se explica el 90% de los "¿por qué no me deja?":
- Por defecto todo está prohibido. En palabras de la documentación de AWS, todas las peticiones se niegan de forma implícita. La única excepción es el usuario root, que tiene acceso completo.
- Para que algo se permita, una política tiene que permitirlo explícitamente. No existe el "pues como nadie lo prohibió, adelante".
- Un "deny" explícito le gana a cualquier "allow". Aunque diez políticas digan que sí, si una dice que no, es no.
Suena molesto hasta que te toca el día en que alguien se equivoca y no pasa nada, porque el permiso nunca estuvo dado.
De ahí sale la regla que vas a leer en todos lados: mínimo privilegio. Da solo el permiso que se necesita para la tarea, nada más, para que si alguien se roba una llave el daño sea del tamaño de esa llave y no del tamaño de tu cuenta.
Lo que cambió: ya no se recomienda crear usuarios con llaves
Aquí está la parte que casi ningún tutorial en español tiene actualizada.
El consejo clásico era: no uses root, créate un usuario IAM, genera sus llaves de acceso y trabaja con eso. Esas llaves son un par de textos que sirven para entrar desde la terminal o desde tu código, y no caducan.
Hoy la primera recomendación de seguridad de AWS ya no es esa. Es que las personas entren con credenciales temporales, a través de IAM Identity Center o de un proveedor de identidad. Los usuarios con llaves permanentes quedaron para casos específicos, como herramientas de terceros que no soportan otra cosa.
¿Por qué el cambio? Porque una llave que no caduca es una llave que alguien puede robar hoy y usar en un año. Es exactamente el tipo de credencial que termina subida a GitHub por error y minando cripto en tu cuenta durante la noche.
Los roles resuelven eso. Cuando un servidor necesita leer tus archivos, en vez de guardarle unas llaves eternas adentro, le pones un rol y AWS le entrega credenciales temporales que se vencen solas. No hay llave permanente que robar porque no existe.
Ojo con esto si vas empezando: montar Identity Center es más pasos que crear un usuario y copiar dos textos. No te voy a decir que es igual de rápido, porque no lo es. Pero es gratis y es la diferencia entre tener una llave que caduca y una que no.
MFA en el root ya no es un consejo, es un requisito
El otro cambio que sorprende a quien vuelve a AWS después de un tiempo.
Antes, prender la verificación en dos pasos (MFA) en el usuario root era la recomendación número uno y mucha gente la ignoraba. Desde 2025 AWS la volvió obligatoria para todos los tipos de cuenta: si no la tienes registrada, tienes 35 días desde tu primer intento de entrar a la consola para hacerlo.
O sea que ya no es opcional, solo es cuestión de si lo haces con calma o contra reloj.
AWS recomienda usar una passkey o una llave de seguridad física en vez de los códigos de la app, porque son resistentes a phishing. Si alguien te engaña para que entregues tu código, el código se puede reenviar; una passkey no.
Qué hacer si apenas estás empezando
Aunque estés solo en tu cuenta y nadie más la toque:
- Prende MFA en el root y guárdalo en el cajón. Ese usuario es para un puñado de tareas que solo él puede hacer, no para el día a día.
- No trabajes desde root. Crea una identidad aparte con los permisos que de verdad necesitas.
- Prefiere roles y credenciales temporales sobre llaves permanentes, siempre que la herramienta te lo permita.
- Si acabas usando llaves, trátalas como una contraseña. Nunca en el código, nunca en GitHub, ni siquiera en un repo privado.
Y lo mejor de todo: IAM, Identity Center y las credenciales temporales no cuestan nada extra. Son parte de tu cuenta. El candado más importante de AWS es gratis y aun así es el que más gente se salta.
Es la diferencia entre "me hackearon la cuenta" y "lo intentaron y no pudieron".
Fuentes
- AWS, buenas prácticas de seguridad en IAM: la primera recomendación es que las personas usen credenciales temporales con un proveedor de identidad
- AWS, lógica de evaluación de políticas: negación implícita por defecto, allow explícito necesario, deny que anula cualquier allow
- AWS, qué es IAM: IAM, Identity Center y STS no tienen costo adicional
- AWS, MFA obligatorio en el root para todos los tipos de cuenta: el requisito y el plazo de 35 días
- AWS, buenas prácticas del usuario root: qué tareas requieren root y cómo protegerlo