Reconstruir una sesión con el JSON de auditoría

Cuando una identidad asume un rol, CloudTrail anota la llamada AssumeRole. En esa llamada el campo userIdentity dice quién pidió la sesión, requestParameters dice qué rol y qué nombre de sesión se pidieron, y responseElements entrega las credenciales temporales: un accessKeyId nuevo, que empieza por ASIA, y su caducidad.

Desde ese momento todo lo que haga la sesión lleva ese accessKeyId dentro de su propio userIdentity, y su sessionContext apunta al rol. Esa llave es el hilo. Se busca en todas las regiones, porque la sesión puede llamar donde quiera, y en todos los servicios. Nombre de sesión y rol sirven de apoyo, pero la llave es el identificador exacto.

El primer paso de la reconstrucción es sacar el hilo. Busca en los eventos la llamada AssumeRole que hace el inventario dudar: la que la identidad de servicio hizo desde una dirección que no es la de su servidor. Su respuesta trae las credenciales con el accessKeyId de la sesión, que es el dato con el que seguirás el resto.

Una buena práctica: anota la llave, la hora de la llamada y el nombre de sesión en la misma línea del informe, porque son los tres datos que se piden al equipo de identidad para revocarla.

Con la llave en la mano se busca en las dos regiones del extracto. Cada línea que la lleva en su propio userIdentity es una llamada hecha con esa sesión. Ojo con un detalle: la línea de la propia llamada AssumeRole también contiene la llave, pero dentro de la respuesta, porque ahí nace; esa llamada no la hizo la sesión, la hizo quien la pidió.

El conteo importa porque dimensiona la sesión: no es lo mismo una llamada suelta que una docena repartida en varias regiones. Cuenta solo las llamadas hechas con la llave, en las dos regiones, sin la que la creó.

Una sesión legítima suele llamar desde un solo lugar, el de quien la pidió. Si la misma llave temporal aparece usada desde dos direcciones distintas, hay dos posibilidades: la credencial se compartió o se copió, o alguien la reenvía a través de otro equipo. En cualquiera de los dos casos, el hecho que importa es que la dirección que la pidió no es la única que la usa.

Compara la dirección de la llamada AssumeRole con las direcciones de las llamadas que siguieron. Una de ellas, en la segunda mitad de la sesión, es distinta.

Una sesión no aparece de la nada: la pidió una identidad concreta, y esa identidad está en el userIdentity de la llamada AssumeRole. Esa es la pieza que conecta el registro con el inventario: si la identidad que pidió el rol tiene dueño y un lugar habitual de trabajo, se puede decir con precisión qué no encaja, y a quién preguntar.

Cruza la identidad de la llamada AssumeRole con el inventario de identidades de Arrayán. Después de esto el informe puede decir quién pidió la sesión, desde dónde la usó y qué hizo, con la hora de cada paso.