Identidad y roles en CloudTrail

5 tareas · 40 min · Principiante

Casi toda investigación en AWS empieza por una pregunta: quién hizo esto. CloudTrail responde con el bloque userIdentity, pero la respuesta cambia según cómo se firmó la petición: con las credenciales de un usuario, con una sesión de un rol o desde otra cuenta. En esta sala lees ocho eventos de la cuenta de producción de Puerto Cálido: aprendes a seguir una sesión de rol hasta quien la pidió, a reconocer el acceso de otra cuenta, a ver una creación de usuario con permisos amplios y a tratar el uso de la cuenta raíz como lo que es, una señal que se redacta con cuidado.

0 de 5 · 0%

Objetivo de la sala

En un evento hecho con credenciales temporales, userIdentity.type vale AssumedRole. El campo userName no aparece: el rol emisor está en sessionContext.sessionIssuer y el nombre de la sesión va al final del identificador principal. Quien la pidió se ve en el evento AssumeRole anterior, en el mismo rol y la misma sesión.

La tabla eventos_de_identidad trae estos campos con nombres cortos: usuario_o_emisor es el usuario, o el rol emisor cuando la identidad es una sesión; sesion es el nombre de la sesión.

Responde para continuar

Un evento ListBuckets llega con identidad AssumedRole. ¿Cómo se llega a la persona que lo originó?

Se sigue la sesión hasta el AssumeRole que la creó, donde aparece quién pidió ese rol Se lee el campo userName del evento, que siempre trae el nombre de la persona que lo hizo Se asume que fue el rol y se da por cerrado, porque el rol es la identidad final

Cuando una cuenta de otra empresa asume un rol que tu cuenta posee, tu CloudTrail registra el AssumeRole con tipo AWSAccount, y el campo que identifica al emisor es el número de esa cuenta. Es la forma normal de dar acceso a un proveedor, y también la forma en la que un acceso olvidado sigue vivo. Mira el evento de acceso entre cuentas de la tabla.

Responde para continuar

Escribe el número de la cuenta externa que asumió el rol del proveedor de monitoreo.

Ver pista de ayuda

Filtra el tipo de identidad que corresponde a otra cuenta de AWS y lee usuario_o_emisor.

Crear un usuario y adjuntarle una política muy amplia es una operación de administración normal y también el paso típico de quien quiere conservar el acceso. El registro no dice cuál de las dos cosas pasó: dice quién, cuándo, desde qué dirección y si usó MFA. Lee los eventos de usuario creado y de política adjuntada.

Responde para continuar

Escribe el usuario que creó el usuario tmp-soporte.

Ver pista de ayuda

Localiza el evento que crea el usuario y lee quién lo firmó.

La cuenta raíz tiene permisos que ningún rol puede restringir, y las buenas prácticas piden no usarla en el día a día. Por eso su aparición en los registros es siempre un evento de interés: no prueba un ataque, pero exige una explicación. Cuenta las filas con tipo de identidad Root en la tabla.

Responde para continuar

Escribe cuántos eventos de la tabla fueron hechos con identidad Root.

Ver pista de ayuda

Filtra la columna tipo_de_identidad.

Los dos eventos de la cuenta raíz vienen de una dirección que ninguna tabla de la organización reconoce y sin MFA. La cuenta tiene un responsable, que todavía no ha contestado.

Responde para continuar

¿Qué redacción de la nota se sostiene con esta evidencia?

Hubo uso de la cuenta raíz sin MFA desde una dirección no reconocida; se pide al responsable confirmarlo Un atacante tomó la cuenta raíz y hay que borrar todos los usuarios de IAM ahora mismo, sin más pruebas El acceso fue legítimo, porque la cuenta raíz solo la puede usar el dueño de la cuenta, sin excepción

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

Entrar · Registrarse

1 Quién está detrás de un rol

2 Otra cuenta entra por un rol Lab

3 Un usuario nuevo con todos los permisos Lab

4 Cuántas veces habló la cuenta raíz Lab

5 Cómo se redacta el uso de la cuenta raíz

Whoami-Labs Pro utiliza cookies