Roles asumidos y sesiones

4 tareas · 40 min · Principiante

Un buen tramo de la actividad de una cuenta de AWS no la hacen usuarios con nombre propio sino sesiones de rol. En el registro, el nombre que aparece es el del rol y el de una sesión, y la persona queda en otro evento, el que creó la sesión. Aquí aprendes a ir de una acción a quien asumió el rol, con las tablas de Piscícola Bocachico. Todo es lectura de eventos ya exportados.

0 de 4 · 0%

Objetivo de la sala

Un rol de IAM no tiene contraseña ni claves propias: alguien (una persona, una aplicación, otra cuenta) lo asume pidiendo credenciales temporales al servicio de tokens de seguridad (STS). Esa petición es el evento AssumeRole: dice quién asumió, qué rol, con qué nombre de sesión, desde qué IP y si la autenticación usó segundo factor.

Después, cada acción hecha con esas credenciales aparece con identidad de tipo AssumedRole. Su principal tiene la forma assumed-role/NOMBRE-DEL-ROL/NOMBRE-DE-SESION. El nombre de sesión lo elige quien asume. Por eso, para saber quién está detrás de una acción, se toma el nombre de sesión y se busca el AssumeRole que lo creó.

En el laboratorio, la tabla sts resume esos eventos y la tabla actividad lo que hicieron las sesiones.

Responde para continuar

Una acción aparece con el principal assumed-role/rol-operaciones/ops-7. ¿Cómo averiguas qué persona o aplicación la hizo?

Le preguntas al equipo de red, porque el nombre de sesión es el de una máquina Buscas el nombre del rol en la lista de usuarios de IAM, que dice quién es Buscas el evento que asumió el rol con esa sesión: ahí figura quién asumió

Ver pista de ayuda

Un rol no es una cuenta de nadie; la persona está en el evento que creó la sesión.

Abre la consola. Primero localiza la acción destructiva con SELECT * FROM actividad WHERE evento = 'DeleteSnapshot': el principal trae el nombre de sesión al final. Luego busca esa sesión en sts con SELECT * FROM sts WHERE sesion = 'ops-4471'.

Responde para continuar

¿Quién asumió el rol en la sesión que borró la copia de volumen (DeleteSnapshot)? Escribe el nombre.

Ver pista de ayuda

En la fila de sts, la columna quien_asume es la respuesta; el nombre de sesión sale del principal de la acción.

El tiempo entre asumir el rol y actuar también cuenta. Una sesión que se crea y actúa en segundos suele ser una automatización; una que espera horas es más propia de una persona, o de credenciales guardadas para después. Las horas van en UTC.

Compara la hora de la sesión ops-4471 en sts con la hora del DeleteSnapshot en actividad.

Responde para continuar

¿Cuántos minutos pasaron entre asumir el rol y borrar la copia? Escribe solo el número.

Ver pista de ayuda

Resta las dos horas; las dos terminan en :00 segundos.

SELECT * FROM sts WHERE mfa = 'no' devuelve una sola sesión: la de un usuario de servicio. Las aplicaciones no pueden teclear un código, así que exigirles segundo factor no tiene sentido. Lo que sí se les pide son otras barreras: que el rol solo se pueda asumir desde direcciones conocidas, que tenga los permisos mínimos y que haya un cambio o un propósito escrito que explique lo que hizo.

Responde para continuar

Una aplicación asumió un rol sin segundo factor y luego borró una copia. ¿Qué compruebas primero?

Nada: una sesión de rol es temporal y se acaba sola, así que ya no queda riesgo Que la aplicación pase a usar un código de verificación como las personas, y con eso cerrar el caso Que la aplicación asuma el rol desde su dirección habitual y que borrar copias sea de su función

Ver pista de ayuda

El control a una aplicación es de origen y alcance, no de código por teléfono.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 El rol no es la persona

2 De la acción a quien asumió Lab

3 Cuánto tardó Lab

4 Una sesión sin segundo factor

Whoami-Labs Pro utiliza cookies