Gestión de identidad y acceso

Una sola contraseña, toda la cuenta

Una empresa le da a cada desarrollador nuevo la contraseña del root user de la cuenta de AWS para que nadie tenga que esperar a que TI le otorgue acceso. Es rápido, y durante meses nada sale mal. Después roban una laptop con esa contraseña guardada en el navegador desde una cafetería. Quien la tenga ya puede lanzar instancias, leer cada archivo guardado, borrar cada respaldo y cambiar los datos de facturación, porque el root user no tiene ningún límite.

La gestión de identidad y acceso existe para achicar mucho ese escenario. En vez de una sola credencial compartida y todopoderosa, IAM deja que un equipo le dé a cada persona y a cada aplicación su propia identidad, limitada exactamente a lo que esa identidad necesita hacer. Una laptop robada expone entonces una porción angosta de la cuenta, no toda.

Root user, usuarios de IAM y roles

Toda cuenta de AWS arranca con un solo root user, creado de forma automática, con acceso sin restricciones a todo. La propia guía de AWS es directa al respecto: no uses el root user para tareas diarias, guarda sus credenciales bajo llave, y configura otras identidades para el trabajo real.

De esas otras identidades, 2 importan más. Un usuario de IAM es una identidad persistente, típicamente de una persona específica o de una aplicación que necesita acceso permanente, con credenciales que duran hasta que alguien las rota o las revoca. Un rol es distinto: es una identidad sin credenciales propias, que un usuario, una aplicación o un servicio de AWS asume de forma temporal, y que recibe credenciales de corta duración que expiran solas mientras dure esa sesión. La práctica moderna se inclina fuerte hacia los roles justo porque no dejan nada de larga duración que se pueda filtrar.

2 revisiones separadas: primero autenticación, después autorización

Imagina a un desarrollador iniciando sesión con contraseña y un código MFA, y después pidiendo lanzar una nueva máquina virtual. AWS corre 2 revisiones distintas, en orden, no una sola combinada.

Primero, autenticación: ¿esta contraseña y este código MFA coinciden con una identidad real de confianza para esta cuenta? Si sí, la identidad queda confirmada. Segundo, y por separado, autorización: ¿la política asignada a esa identidad confirmada realmente permite lanzar una instancia? Un usuario puede pasar la autenticación perfectamente, con contraseña correcta y código MFA válido, y aun así quedar denegado en la autorización si su política no otorga esa acción. Las 2 revisiones protegen contra fallas distintas: una contraseña robada vence a la autenticación, mientras que una política que otorga de más vence a la autorización incluso cuando la autenticación funciona exactamente como debe.

Mínimo privilegio: empezar angosto, no amplio

Digamos que el rol de un desarrollador necesita leer archivos de un solo bucket de reportes y nada más. Una política de mínimo privilegio otorga exactamente eso: la acción s3:GetObject, limitada a ese único bucket, ni una más. Compara eso con una política amplia que otorga acceso total a S3 "por si acaso": si alguna vez usan mal esas credenciales, la política angosta limita el daño al acceso de lectura de un bucket, mientras que la amplia entrega cada bucket de la cuenta.

Mínimo privilegio es una dirección hacia la que moverse, no una configuración de una sola vez. La propia guía de AWS recomienda empezar con una política administrada más amplia mientras un equipo explora qué necesita en verdad una carga de trabajo nueva, y después achicarla a medida que los patrones de uso quedan claros, usando herramientas que analizan la actividad de acceso real para generar una política más ajustada de forma automática. Los equipos que nunca vuelven a revisar esa primera política amplia son los que una auditoría termina marcando.

El límite: grupos frente a roles

Estos 2 se confunden porque ambos dejan que más de una entidad comparta un conjunto de permisos, pero resuelven problemas distintos. Un grupo es una colección de usuarios de IAM, útil para otorgar las mismas políticas a, digamos, todo un equipo de datos, sin asignarle esa política a cada usuario uno por uno. Un rol no es una colección de nada; es una sola identidad que distintos principales pueden asumir de forma temporal, uno a la vez, y que recibe credenciales que expiran. Pregúntate qué está pidiendo el escenario: "otorgar los mismos permisos permanentes a varias personas" apunta a un grupo; "dejar que esta aplicación o esta persona actúe temporalmente como una identidad específica" apunta a un rol.

Error de concepto: una contraseña fuerte basta

Es tentador pensar que una contraseña larga y única es protección suficiente para una cuenta. No lo es: las contraseñas se roban por phishing, se reutilizan de sitios filtrados o las captura un malware sin importar qué tan fuertes sean. MFA cierra ese vacío al exigir un segundo factor, algo que el dueño de la cuenta tiene o genera, que una contraseña robada por sí sola no puede satisfacer. AWS recomienda específicamente MFA resistente a phishing, como llaves de seguridad o passkeys, por encima de códigos de un solo uso enviados por mensaje de texto, porque incluso ese código a veces se puede interceptar o el flujo se puede engañar.

Pistas de examen: unir el escenario con la herramienta

Dónde te deja esto

La identidad es la fila de la tabla de responsabilidad compartida que nunca pasa al proveedor, e IAM es el conjunto de herramientas que te deja hacerte cargo de verdad: confirmar quién pregunta con la autenticación, decidir qué puede hacer con la autorización, y mantener las 2 angostas con mínimo privilegio y roles en vez de credenciales permanentes y todopoderosas. Saber quién puede tocar tus datos resuelve la mitad del problema. La siguiente lección cubre qué protege esos datos incluso si alguien logra pasar cada una de estas revisiones: el cifrado.