Consultas SQL sobre CloudTrail

Athena no guarda los datos: lee los archivos de S3 cada vez que se le pregunta y cobra según los datos que tuvo que escanear. Por eso una tabla de CloudTrail suele declararse con particiones (cuenta, región, año, mes, día): si la consulta filtra por esos campos, Athena solo abre las carpetas que corresponden; si no filtra, lee todo.

Las columnas que más se usan son eventtime, eventname, eventsource, useridentity.arn (quién), sourceipaddress (desde dónde) y errorcode (si la nube rechazó la llamada).

Un errorcode de AccessDenied significa que la identidad intentó algo y la nube no se lo permitió. Un rechazo aislado es un error de permisos; una ráfaga de rechazos sobre servicios distintos, en pocos segundos, es alguien probando qué puede hacer.

Ejecuta primero la consulta de las llamadas rechazadas y luego la que las agrupa por identidad.

Los cambios en el servicio de identidades (crear un usuario, adjuntar una política, listar claves) son los eventos que más interesa conservar y los que más conviene mirar. Se filtran por eventsource, no por el nombre del evento, para no olvidar ninguno.

Cuenta cuántos eventos del día pasaron por ese servicio, contando los que salieron bien y los rechazados.

La llamada que detiene un trail aparece como evento del servicio de CloudTrail, con quién y desde dónde. Es una de las pocas llamadas que siempre merecen una pregunta, incluso cuando tiene explicación. Mira qué eventos del propio servicio de registro hay en la tabla.

La consulta mostró que el registro estuvo detenido 88 segundos y que el mismo rol lo reanudó. Eso es un dato, no una conclusión. Entre la detención y el reinicio no hay eventos: lo que pasó en esa ventana no está registrado.

Un analista maduro no escribe «sabotaje» ni «falsa alarma»: cruza el dato con una fuente que explique el cambio, como un ticket de mantenimiento, y anota la ventana ciega.