Anatomía de un evento de CloudTrail

Un evento de CloudTrail trae las respuestas en campos concretos. El campo userIdentity dice quién hizo la llamada y con qué credencial: su tipo (un usuario de IAM, un rol asumido, la cuenta raíz, otro servicio de AWS) y, si la credencial era temporal, un bloque sessionContext que cuenta cómo se obtuvo. Los campos eventSource y eventName dicen qué se pidió y a qué servicio. Los campos sourceIPAddress y userAgent dicen desde dónde y con qué herramienta, y awsRegion, en qué región. Y eventTime lleva la hora en UTC.

Hay un detalle que confunde al principio. Cuando el tipo es AssumedRole, el evento no trae el campo userName: la llamada la hizo una sesión temporal, no un usuario. El último tramo del ARN de la sesión es el nombre que alguien le puso al pedirla, y el rol del que salió la sesión se describe en otro sitio del bloque userIdentity.

Abre evento-01.json en el laboratorio y recorre los campos con esa lista en la mano.

Dentro de sessionContext hay un bloque attributes con dos datos que se pasan por alto. Uno es mfaAuthenticated, que cuenta si quien obtuvo las credenciales usó un segundo factor. El otro es creationDate, el momento en que se emitieron las credenciales temporales, escrito en la notación básica de ISO 8601, sin guiones ni dos puntos.

Ese dato permite medir la edad de la sesión: la diferencia entre eventTime y creationDate dice cuánto llevaba viva la credencial cuando hizo la llamada. Una sesión de una hora que sigue llamando a las 23 horas de vida es una pregunta que hacer, y una credencial emitida hace tres minutos que ya recorre media cuenta es otra.

Cuando una llamada falla, CloudTrail la registra igual y añade al evento dos campos: errorCode, con el código del error, y errorMessage, con la descripción. Una denegación no es ruido: es evidencia de una intención. Quien pidió una acción que no podía hacer dejó anotado qué quería hacer, con qué identidad y desde dónde, aunque el servicio no lo ejecutara.

Por eso un extracto se lee dos veces: primero lo que ocurrió, y después lo que se intentó y no ocurrió. En un extracto de pocas líneas la forma más rápida es buscar el nombre del campo, porque solo los eventos con error lo llevan.

Cada evento lleva readOnly, que vale true si la llamada solo leyó y false si pudo cambiar algo. Cuando la pregunta es «qué cambió en la cuenta durante la revisión», esa bandera es el primer filtro: se descartan las lecturas. Pero no basta: una escritura que terminó con errorCode no cambió nada, y contarla como cambio es un error de lectura clásico.

La cuenta correcta de cambios reales sale de dos condiciones a la vez: readOnly en false y ninguna señal de error. Con doce eventos se puede hacer a mano, y con doce millones se hace con una consulta, pero el razonamiento es el mismo.