CloudTrail: quién hizo qué en AWS

En tu compu, el perímetro es la red: un firewall, una IP. En la nube eso se desdibuja. Lo que define qué puede pasar es la identidad: un usuario, un rol, una access key. Y la herramienta que registra qué hizo cada identidad es CloudTrail.

Qué registra (y qué no)

CloudTrail registra llamadas a la API de AWS: el plano de control. “Alguien asumió este rol”, “alguien creó una access key”, “alguien cambió esta policy”. Lo que no registra por defecto es el contenido: no te dice qué bytes se leyeron de un objeto S3, solo que se llamó a la API. Para ese nivel hace falta logging de datos aparte.

Anatomía de un evento

Cada evento es un JSON. Estos son los campos que mirás primero:

{
  "eventTime": "2026-03-14T09:42:11Z",
  "eventName": "CreateAccessKey",
  "userIdentity": {
    "type": "IAMUser",
    "arn": "arn:aws:iam::1234:user/deploy-bot",
    "accessKeyId": "AKIAEXAMPLE000"
  },
  "sourceIPAddress": "203.0.113.50",
  "requestParameters": { "userName": "deploy-bot" },
  "responseElements": { "accessKey": { "accessKeyId": "AKIAEXAMPLE999" } }
}

• eventTime: cuándo. Tu línea de tiempo se arma con esto.
• eventName: qué acción (AssumeRole, CreateAccessKey, AttachUserPolicy…).
• userIdentity.arn: quién. La identidad que hizo la llamada.
• sourceIPAddress: desde dónde. Una IP rara es una señal.
• requestParameters / responseElements: sobre qué recurso y con qué resultado.

jq '.Records[] | {time: .eventTime, who: .userIdentity.arn, action: .eventName, ip: .sourceIPAddress}' trail.json

El caso: un dataset sintético

Estos eventos son falsos, solo para practicar. Leelos y reconstruí la historia.

1) 09:40  ConsoleLogin       arn:.../user/deploy-bot     ip 203.0.113.50   MFA: no
2) 09:42  CreateAccessKey    arn:.../user/deploy-bot     ip 203.0.113.50   nueva key AKIA...999
3) 09:55  AssumeRole         arn:.../user/deploy-bot     ip 198.51.100.7   rol: ops-admin
4) 10:01  AttachRolePolicy   arn:.../assumed-role/ops    ip 198.51.100.7   policy: AdministratorAccess
5) 10:06  PutBucketPolicy    arn:.../assumed-role/ops    ip 198.51.100.7   bucket: backups-prod (público)

Las tres preguntas de investigación

Respondé con el dataset de arriba (las respuestas están implícitas en los eventos):

1. ¿Qué identidad inició la actividad sospechosa y qué la hace rara?
2. ¿Cómo consiguió más permisos de los que tenía al principio?
3. ¿Cuál fue la acción de mayor impacto y qué recurso quedó expuesto?

Qué pondrías a alertar

No alcanza con tener CloudTrail prendido si nadie lo mira. Un mínimo razonable es alertar sobre eventos de identidad de alto riesgo:

CreateAccessKey        → ¿quién crea credenciales nuevas, y para quién?
AssumeRole (sensible)  → asumir roles con permisos amplios
AttachUserPolicy /
  AttachRolePolicy      → cambios de permisos, sobre todo Administrator*
ConsoleLogin sin MFA   → logins humanos sin segundo factor
PutBucketPolicy        → un bucket que pasa a ser público

CloudTrail no es decoración que se prende para una auditoría. Es la cámara de seguridad de tu cuenta. El día del incidente, o sabés leerla, o estás adivinando.