Dónde se guardan los registros

CloudTrail registra la actividad de la cuenta, y el historial de eventos está disponible sin crear nada: es una vista de los últimos 90 días de eventos de gestión (crear un usuario, cambiar una política, iniciar una sesión de consola), región por región y sin cargo por consultarlo. Sirve para una primera mirada, pero no para una investigación larga: no muestra eventos de datos, no cruza regiones y solo deja filtrar por un atributo a la vez.

Para conservar más tiempo, o para registrar más tipos de evento, se crea un trail, que entrega los archivos a un bucket de S3 (y, si se quiere, a un grupo de registros de CloudWatch).

Otros registros no existen hasta que alguien los activa. Los eventos de datos (quién leyó o escribió un objeto de S3, quién invocó una función) se piden aparte en el trail. Los registros de flujo de la red se crean para una red virtual, una subred o una interfaz. Los registros de acceso del balanceador y los del servidor de un bucket vienen desactivados y se activan hacia un bucket de destino.

La consola de la derecha trae el inventario de Salinas del Tordo. Ábrelo y busca la fuente que se quedó sin activar.

Cada destino tiene su propio plazo. Un trail puede guardarse más de un año en S3, mientras que los registros de acceso a un bucket suelen dejarse poco tiempo porque nadie los mira hasta que hacen falta. El plazo importa más que el formato: una investigación llega tarde casi siempre, y lo que ya se borró no se consulta.

Ordena el inventario por retención para ver quién vive menos.

Lo habitual en una investigación es que la pregunta llegue semanas después del hecho. Por eso la lectura del inventario se hace antes del incidente y no durante: qué se puede responder con lo que hay hoy.

Un auditor, con autorización, pregunta si alguien descargó objetos del bucket de facturas hace 45 días. Con el inventario delante, la respuesta depende de dos filas.