Tipos de políticas y cómo decide AWS

Las políticas que se adjuntan a identidades son de tres tipos:

• Administradas por AWS (AWS managed): las escribe y actualiza AWS, como ReadOnlyAccess del laboratorio de la Sesión 4. Buen punto de partida, pero suelen dar más de lo justo.
• Administradas por el cliente (customer managed): las escribes tú y las adjuntas a varias identidades; así te acercas al mínimo privilegio.
• En línea (inline): viven dentro de una sola identidad y se borran con ella.

AWS decide cada petición en tres pasos. Por defecto, todo está negado implícitamente: un usuario nuevo no puede nada. Un Allow aplicable convierte esa negación en permiso. Y un Deny explícito en cualquier política aplicable niega la acción, haya los Allow que haya.

Roles de IAM

Qué es: un rol es una identidad de IAM con permisos, pero sin contraseña ni claves de acceso propias. Quien lo asume recibe credenciales temporales, que caducan en minutos u horas. Las entrega AWS STS (Security Token Service), el servicio que ya usaste para preguntar quién eres.

• Política de confianza (trust policy): quién puede asumirlo y con qué condición, por ejemplo con MFA.
• Política de permisos: qué puede hacer quien lo asume.
• Quién lo asume: usuarios de tu cuenta, usuarios de otra cuenta (acceso entre cuentas), servicios de AWS y personas que entran con un sistema de identidad externo, como verás en “Federación”.

Analogía: el gafete de visitante de un edificio de oficinas. Recepción revisa si tienes cita y te presta un gafete que abre ciertos pisos y se desactiva al final del día. Dónde falla la analogía: con el gafete sigues siendo tú. En AWS, mientras usas un rol dejas a un lado tus propios permisos: solo tienes los del rol, y recuperas los tuyos al salir.

Ejemplo real: Laboratorios Orión tiene una aplicación en una máquina virtual de AWS que lee los resultados de los análisis. En lugar de guardar una clave en el código, le asigna un rol: AWS entrega y renueva sus credenciales temporales. Así se responde la pregunta 2 del inicio: si alguien copia el código, no se lleva ninguna credencial.

Úsalo cuando: una aplicación o un servicio de AWS necesita permisos, alguien de otra cuenta necesita entrar a la tuya, o una persona necesita más permisos solo por un rato. No lo uses cuando: buscas la identidad diaria de una persona en una cuenta suelta: ahí va un usuario, como estudio-diario, que asume roles cuando hace falta.