En 04-02 ciframos las copias de seguridad de mercadofresco-pedidos con la clave alias/mercadofresco-datos, y dijimos que KMS registra escrupulosamente cada operación criptográfica. En 04-03 guardamos la contraseña de mfadmin en el secreto mercadofresco/produccion/rds/mfadmin y dijimos que cada lectura queda anotada. En 04-01 creamos el rol rol-mercadofresco-tienda y dijimos que cada AssumeRole deja rastro.

Ninguna de esas tres cosas es mentira. Todas están registradas. Y nadie las ha mirado nunca.

Ese registro se llama AWS CloudTrail, y responde a una pregunta que ni CloudWatch ni X-Ray pueden contestar. CloudWatch sabe lo que tu aplicación dice de sí misma. X-Ray sabe por dónde pasó una petición de un cliente. CloudTrail sabe quién llamó a la API de AWS, cuándo, desde dónde, con qué parámetros y con qué resultado. Es la diferencia entre saber que la tienda va lenta y saber que alguien, a las 03:42 de un martes, desde una IP de un país donde no tienes oficinas, llamó a kms:Decrypt sobre la copia de la base de datos.

Esta lección monta el trail trail-mercadofresco, aprende a leer un evento real, y contesta por fin a la tercera pregunta que dejó abierta el módulo 4.

Aviso de cumplimiento. Los registros de auditoría suelen tener requisitos legales de conservación. Según el sector y el país, pueden ir de 6 meses a 10 años, y en algunos casos deben ser inalterables y estar en custodia separada. Este material es didáctico: las decisiones de retención, inmutabilidad y acceso a los registros de auditoría de un sistema real las debe validar un profesional de cumplimiento o el asesor legal de tu organización. No las tomes tú a partir de un curso.

1. Qué registra CloudTrail y qué no
2. CloudTrail frente a CloudWatch Logs
3. El historial de eventos de 90 días, gratuito
4. Crear el trail trail-mercadofresco
5. El bucket que nadie debe poder borrar
6. Validación de integridad de los ficheros
7. Anatomía de un evento: el JSON comentado
8. userIdentity: los seis tipos y cómo se leen
9. Quién descifró la última copia
10. Eventos de gestión frente a eventos de datos
11. Eventos de Insights
12. Trails multirregión y de organización
13. Enviar el trail a CloudWatch Logs
14. Filtros de métricas y alarmas de seguridad
15. Consultar con Athena
16. Las consultas que responden preguntas reales
17. CloudTrail Lake
18. Investigación de un incidente, paso a paso
19. Relación con IAM Access Analyzer
20. Retención, coste y limpieza

CloudTrail registra llamadas a la API de AWS. Todas. Da igual que las haga una persona en la consola, la CLI, un SDK, un servicio de AWS actuando en tu nombre o una función Lambda: por debajo todo son llamadas HTTPS firmadas a las API de AWS, y CloudTrail las ve todas.

Lo que no registra:

Esa última fila importa: CloudTrail registra que alguien llamó a GetSecretValue sobre mercadofresco/produccion/rds/mfadmin, pero no registra la contraseña. Los campos sensibles se omiten o se ofuscan por diseño. Lo mismo con kms:Decrypt: registra la llamada y el identificador de clave, no el texto claro.

Y una propiedad estructural que hay que entender: CloudTrail está siempre encendido. No es algo que se «activa»: los últimos 90 días de eventos de gestión están disponibles gratis en tu cuenta desde el primer día, incluso si no has creado ningún trail. Lo que se activa es la persistencia.

Es la confusión número uno de este módulo, y merece una tabla:

Un caso concreto para fijarlo. Alguien borra el bucket mercadofresco-registros-web:

• CloudWatch Logs: nada. Tu aplicación no ha escrito nada porque no ha sido tu aplicación.
• CloudTrail: un evento DeleteBucket, con la identidad que lo hizo, la hora exacta, la IP de origen, el agente de usuario (aws-cli/2.15.0 o console.amazonaws.com), y si se hizo con MFA.

Y el caso inverso. La tienda devuelve 500 al confirmar un pedido:

• CloudTrail: nada. Nadie llamó a ninguna API de AWS de forma anómala.
• CloudWatch Logs: la traza completa del error.

No compiten: cubren universos distintos.

Antes de crear nada, hay algo que ya funciona:

Los atributos de búsqueda disponibles son limitados y hay que conocerlos, porque es lo que se puede hacer sin infraestructura: EventId, EventName, EventSource, ReadOnly, ResourceName, ResourceType, Username, AccessKeyId.

Las cinco limitaciones del historial gratuito, que son exactamente las razones para crear un trail:

1. Solo 90 días. Una investigación de un incidente detectado tarde se queda sin datos.
2. Solo eventos de gestión. No hay eventos de datos (accesos a objetos de S3, invocaciones de Lambda).
3. Un solo atributo de búsqueda por consulta. No puedes cruzar «este usuario» y «esta acción».
4. No es exportable ni consultable con SQL. No hay análisis serio posible.
5. No es inmutable ni verificable. No sirve como prueba en una auditoría formal.

Un trail persiste los eventos en un bucket de S3, indefinidamente, y permite todo lo anterior.

Paso 1: el bucket dedicado.

Ese BucketKeyEnabled: true no es cosmético: reduce hasta un 99 % las llamadas a KMS —y su coste— cuando se escriben miles de objetos pequeños, que es exactamente lo que hace CloudTrail. Lo vimos en 04-02.

Paso 2: la política del bucket. CloudTrail necesita permiso para escribir:

Las condiciones aws:SourceArn son importantes y no siempre se ponen: sin ellas, en teoría un trail de otra cuenta podría escribir en tu bucket (el problema del «diputado confuso» que vimos en 04-01).

Paso 3: el trail.

El error del año: create-trail crea el trail pero no empieza a registrar. Hay que llamar a start-logging. Hay cuentas con trails creados hace años que nunca han grabado una línea. Compruébalo siempre:

Las cuatro banderas del comando, explicadas:

La primera es la más importante desde el punto de vista de seguridad. Un trail de una sola región es una cámara que solo enfoca la puerta principal.

Un registro de auditoría que el atacante puede borrar no es un registro de auditoría. Es la primera cosa que hace cualquiera que sabe lo que hace: entrar, borrar el rastro, seguir.

Hay cuatro niveles de protección, y conviene entender qué protege cada uno:

Nivel 3, Object Lock, es el que de verdad cierra la puerta:

Los dos modos, y la diferencia es enorme:

Esos 2.555 días son 7 años. Y ahí está el peligro: con COMPLIANCE, cada objeto que CloudTrail escriba será imborrable durante siete años, y lo pagarás durante siete años. Si te equivocas de valor, no hay marcha atrás.

Esta es exactamente la decisión que debe validar un profesional de cumplimiento. El periodo de retención de los registros de auditoría depende de tu sector, tu país y tus obligaciones contractuales. No lo elijas por intuición, y no copies el 2555 de este curso.

Nivel 2, MFA Delete, solo lo puede activar la cuenta raíz con un dispositivo MFA, y por eso no encaja con el principio de 04-01 de no usar la raíz. MercadoFresco no lo usa; usa Object Lock.

Nivel 4, cuenta separada, es la respuesta profesional completa: el bucket de auditoría vive en una cuenta de registro distinta, a la que la cuenta de producción solo puede escribir. Aunque alguien comprometa por completo 111122223333, los registros están fuera de su alcance. Requiere AWS Organizations, que es la lección 09-04. MercadoFresco lo tiene anotado como el siguiente paso.

Y una defensa complementaria que se monta hoy mismo: una alarma que avise si alguien detiene o borra el trail. Está en la sección de filtros de métricas.

Con --enable-log-file-validation, CloudTrail hace algo elegante: cada hora publica un fichero de resumen (digest) que contiene el hash SHA-256 de cada fichero de registro de esa hora, más el hash del resumen anterior. Es una cadena: cada resumen firma al anterior.

Consecuencia práctica: no se puede alterar un fichero de registro, ni borrarlo, ni sustituir un resumen, sin romper la cadena. Los resúmenes están firmados con la clave privada de CloudTrail, así que tampoco se pueden regenerar.

La verificación:

Una salida sana termina con Results requested for ... Results found for N digest files ... All files verified. Cualquier mención a ficheros modificados o ausentes es un hallazgo de seguridad inmediato.

Marta lo ejecuta el primer lunes de cada mes y guarda la salida. En una auditoría formal, esa salida es lo que demuestra que los registros no se han tocado.

Este es un evento real de kms:Decrypt, que es exactamente el que buscábamos. Comentado campo a campo:

Lectura campo a campo de lo que este evento nos está diciendo:

Tres campos merecen comentario aparte:

• responseElements es null en las operaciones de solo lectura. En una operación de escritura —CreateBucket, RunInstances— contiene lo que devolvió la API: el ID del recurso creado. Es el campo que te dice qué se creó.
• errorCode y errorMessage aparecen solo cuando la llamada falló. AccessDenied, UnauthorizedOperation, Client.InvalidParameterValue. Que CloudTrail registre también las llamadas que fallan es una de sus propiedades más valiosas: un atacante probando puertas deja un reguero de AccessDenied que es la señal más limpia de reconocimiento.
• encryptionContext es lo que en 04-02 explicamos como los «datos adicionales autenticados» del cifrado de sobre. Aquí se ve su verdadero valor: es lo que convierte un evento genérico de Decrypt en «alguien descifró la copia del 27 de julio de mercadofresco-pedidos». Sin él, el evento diría solo que se usó una clave.

El campo userIdentity es donde vive la respuesta a «¿quién?», y tiene seis formas distintas:

El más habitual, y el más confuso, es AssumedRole. La instancia EC2 de MercadoFresco no aparece como «instancia»: aparece como el rol rol-mercadofresco-tienda con un nombre de sesión que es el ID de la instancia. Y cuando Marta asume un rol desde su usuario, aparece como el rol con el nombre de sesión que ella eligió.

De ahí sale una de las prácticas más útiles de todo este módulo: si en AssumeRole no pones un nombre de sesión identificativo, CloudTrail te dirá «alguien con el rol de administración borró el bucket» y no podrás saber quién. Con --role-session-name marta.costa sí:

En 04-01 introdujimos esto de pasada. Aquí se ve por qué importa: el nombre de sesión es lo que convierte un rol compartido en una persona identificable. Con AWS IAM Identity Center esto se hace solo, con el correo del usuario federado como nombre de sesión.

Y una nota sobre AWSService. Muchos eventos legítimos tienen invokedBy con valores como autoscaling.amazonaws.com o dlm.amazonaws.com. Son AWS actuando en tu nombre: el ASG lanzando una instancia, DLM creando una instantánea (02-02). No son alertas; son el sistema funcionando. Filtrarlos correctamente es la mitad del trabajo de reducir el ruido en una investigación.

Ahora sí, la respuesta a la pregunta del módulo 4. La consulta directa contra el historial de 90 días:

Salida real:

Tres líneas y tres lecturas completamente distintas:

1. rds-backup-service a las 03:00: es el propio RDS cifrando la copia automática. Normal, es la ventana de copia que configuramos en 02-04.
2. rol-mercadofresco-tienda desde 10.0.11.24: una instancia del ASG, IP privada de la subred de aplicación (03-01), descifrando datos de la aplicación. Normal.
3. rol-restauracion-copias a las 03:42, desde 198.51.100.77, sin MFA, sobre la copia snapshot-2026-07-27: esto hay que investigarlo.

Y las preguntas que se derivan, en este orden:

• ¿Es 198.51.100.77 una IP conocida? ¿La oficina? ¿La VPN? ¿El domicilio de alguien?
• ¿Quién asumió rol-restauracion-copias? El nombre de sesión dice sesion-marta-copias, pero eso es una cadena que eligió quien hizo la llamada, no una identidad verificada. Hay que buscar el evento AssumeRole correspondiente para ver quién lo asumió de verdad.
• ¿Hay un evento RestoreDBInstanceFromDBSnapshot cerca? ¿Se restauró la copia en algún sitio?
• ¿Hubo un AccessDenied antes, señal de tanteo?

Esto no es una respuesta, es el principio de una investigación. Y esa es precisamente la lección: CloudTrail no dice si algo está mal. Dice qué pasó, con precisión suficiente para que una persona decida. La investigación completa está más abajo.

Es la distinción que decide la factura de CloudTrail:

El cálculo que hay que hacer antes de activar eventos de datos en S3. MercadoFresco sirve unas 40 millones de peticiones al mes a mercadofresco-catalogo-fotos (fotos de producto, aunque CloudFront cachea la mayoría). Registrar todas:

40.000.000 × 0,10 / 100.000 = 40 USD/mes, más el almacenamiento en S3 de un volumen enorme de JSON, más lo que cueste consultarlo con Athena.

Y no aporta casi nada: son lecturas públicas de fotos de tomates.

La regla es: activa eventos de datos con selectores de alcance mínimo, solo sobre lo que importa.

Lo que consigue esta configuración:

De 40 USD a 0,06 USD sin perder nada relevante. Ese readOnly: false sobre el catálogo es la decisión clave: leer una foto de tomate no interesa a nadie; que alguien suba o borre una foto sí, porque es una modificación del contenido del sitio.

Los tipos de recurso disponibles para eventos de datos incluyen AWS::S3::Object, AWS::Lambda::Function, AWS::DynamoDB::Table (módulo 6), AWS::SQS::Queue (07-01) y varios más.

CloudTrail Insights analiza el volumen de llamadas y detecta picos anómalos de actividad de escritura o de errores. No mira el contenido: mira el ritmo.

Casos que detecta bien:

• Un script mal escrito que llama a DescribeInstances 40.000 veces en una hora.
• Un aumento súbito de AccessDenied: alguien probando permisos.
• Un pico de TerminateInstances a las 4 de la mañana.

Coste: 0,35 USD por cada 100.000 eventos de gestión analizados. Con ~150.000 eventos mensuales, MercadoFresco paga unos 0,53 USD/mes. Es de lo más barato de este módulo y de lo que más pronto avisa.

Las dos limitaciones honestas: necesita al menos 7 días de línea base antes de servir para algo, y solo detecta anomalías de volumen, no de intención. Una sola llamada maliciosa perfectamente ejecutada no genera ningún insight. Para eso están las alarmas específicas de la siguiente sección.

Multirregión ya lo activamos con --is-multi-region-trail, y merece insistir en por qué. Un trail de una sola región es como una cámara de seguridad que solo enfoca la puerta principal: un atacante que consiga credenciales creará sus instancias de minado en ap-southeast-2, donde nadie mira nunca. Con el trail multirregión, esas llamadas aparecen en el mismo bucket.

Coste de la multirregión: cero. La primera copia de los eventos de gestión es gratuita en todas las regiones. No hay ninguna razón para no activarla.

Trail de organización: si tienes varias cuentas bajo AWS Organizations, un solo trail creado en la cuenta de gestión registra todas las cuentas miembro, y estas no pueden desactivarlo ni verlo. Es la configuración correcta para cualquier organización con más de una cuenta, y es la lección 09-04. MercadoFresco tiene una sola cuenta hoy; la separación entre producción, preproducción y registro es un objetivo declarado.

El bucket de S3 es el archivo. Para reaccionar en caliente hace falta que los eventos lleguen también a CloudWatch Logs, donde pueden convertirse en métricas y alarmas (05-01).

Fíjate: 90 días en CloudWatch Logs, 7 años en S3. Los dos destinos tienen propósitos distintos y retenciones distintas. Logs es para alarmar y consultar lo reciente; S3 es el archivo legal. Duplicar 7 años en CloudWatch Logs costaría una fortuna sin aportar nada.

El rol que CloudTrail necesita:

Con la política de permisos:

Coste: la ingesta de los eventos de gestión de MercadoFresco son unos 0,4 GB al mes: 0,25 USD. Si activaras eventos de datos de alto volumen, esto se dispararía; es otra razón para los selectores restrictivos.

Aquí es donde CloudTrail y CloudWatch se juntan y se convierten en detección, no solo en registro. Estas son las cinco alarmas que monta MercadoFresco, y las cinco son estándar en cualquier auditoría de seguridad (aparecen en el CIS Benchmark de AWS, que veremos en 05-04).

1. Uso de la cuenta raíz. Después de 04-01, la raíz no debería usarse nunca:

Ese $.userIdentity.invokedBy NOT EXISTS excluye los eventos en los que un servicio de AWS actúa en nombre de la cuenta, que son legítimos y frecuentes. Sin él, la alarma sería puro ruido.

2. Detención o borrado de un trail. La primera acción de cualquiera que quiera ocultar su rastro:

Con su alarma en umbral 0, exactamente igual que la anterior. Esta es la alarma más importante de esta lección: es la que avisa de que el sistema de auditoría está siendo atacado.

3. Uso de KMS sobre las copias de la base de datos. La que responde directamente a la pregunta del módulo 4, pero en caliente:

Ese $.userIdentity.type != "AWSService" excluye al propio RDS cifrando sus copias automáticas cada noche, que es la línea 1 de nuestra investigación. Lo que queda es actividad humana o de script sobre una copia de la base de datos, y eso siempre merece un aviso.

4. Accesos denegados repetidos. El reguero que deja el reconocimiento:

Aquí el umbral no es 0, y la razón es honesta: los AccessDenied son constantes en cualquier cuenta viva. Un desarrollador probando, una herramienta que consulta algo que no puede, un SDK que sondea. 20 en cinco minutos sostenidos durante dos periodos sí es una señal.

5. Cambios en la política de un grupo de seguridad o en IAM.

Con umbral 0 en horario nocturno sería demasiado ruidoso durante un despliegue diurno. MercadoFresco lo pone en umbral 0 con periodo de 5 minutos, aceptando el ruido: prefiere enterarse de todos los cambios de seguridad. Que la alarma sea informativa y no urgente es una decisión válida, siempre que esté documentada y no acabe siendo ignorada por costumbre.

Para investigar en serio hay que consultar los ficheros de S3 con SQL. Amazon Athena ejecuta SQL directamente sobre los objetos de un bucket, sin cargar nada en ninguna base de datos.

Athena se ve con más profundidad en el módulo 6 al hablar de analítica. Aquí usamos lo justo para investigar CloudTrail, que es su caso de uso más común.

Paso 1: la tabla. La forma cómoda de crearla es desde la consola de CloudTrail («Create Athena table»), que genera este DDL. Conviene entenderlo:

Dos cosas que hay que ver en ese DDL:

• requestParameters y responseElements son STRING, no estructuras. Su contenido varía según el evento, así que se consultan con funciones JSON: json_extract_scalar(requestParameters, '$.keyId').
• PARTITIONED BY es lo que decide el coste. Athena cobra 5 USD por TB escaneado. Sin particiones, cada consulta lee todos los ficheros del bucket. Con particiones y un WHERE sobre ellas, lee solo los días que pidas.

Paso 2: registrar las particiones. Con la proyección de particiones se automatiza:

Sin esto habría que ejecutar MSCK REPAIR TABLE o ALTER TABLE ADD PARTITION cada día. Con la proyección, Athena deduce las particiones del patrón de rutas.

1. ¿Quién asumió rol-mercadofresco-tienda, y cuándo?

2. ¿Quién leyó el secreto de mfadmin? La pregunta que dejamos pendiente en 04-03:

Lo esperable en el resultado: el rol de la tienda leyéndolo al arrancar cada instancia, y rol-rotacion-mfadmin cada 30 días haciendo la rotación (04-03). Cualquier otra identidad es un hallazgo.

3. Todas las llamadas denegadas, agrupadas. La consulta de reconocimiento:

Esta consulta tiene un uso doble muy valioso, y conviene subrayarlo:

• Seguridad: una identidad desconocida con 400 AccessDenied sobre 30 servicios distintos en diez minutos es reconocimiento. Alguien está mapeando lo que puede hacer.
• Operación: rol-mercadofresco-tienda con 3.000 AccessDenied sobre s3:GetObject significa que a pol-mercadofresco-tienda le falta un permiso y hay una funcionalidad rota que nadie ha reportado. Los AccessDenied son también un detector de errores de configuración.

4. Actividad fuera de horario, que es la que suele delatar.

Filtrar userIdentity.type != 'AWSService' es imprescindible: si no, la salida se llena de copias automáticas, instantáneas de DLM y actividad del ASG a las 3 de la mañana, que es completamente normal.

5. Todas las IP de origen, para detectar las desconocidas.

Una IP que aparece por primera vez, hace 12 llamadas y desaparece es mucho más sospechosa que una que hace 40.000 desde hace meses.

6. La consulta de la copia descifrada, ahora en SQL.

Control de coste en Athena: cada consulta cobra por TB escaneado. Poner siempre el WHERE de partición (anio, mes, dia) es la diferencia entre 0,01 USD y varios euros por consulta. Y se puede fijar un límite duro por grupo de trabajo:

Diez GiB máximo por consulta. Si alguien escribe un SELECT * sin WHERE, la consulta se cancela sola en lugar de generar una factura.

CloudTrail Lake es la alternativa gestionada a montar Athena a mano: un almacén de datos de eventos gestionado por AWS, con SQL directo desde la consola de CloudTrail y sin tablas que crear.

La decisión de MercadoFresco: se queda con S3 + Athena. Con 0,4 GB mensuales de eventos, Lake costaría 1 USD al mes de ingesta —no es dramático— pero el bucket de S3 ya existe, ya está protegido con Object Lock y ya alimenta el archivo legal de 7 años. Lake se anota como opción a reconsiderar si la cuenta crece y montar particiones a mano empieza a doler.

Con muchas cuentas y equipos que no son de plataforma, Lake gana claramente: nadie tiene que aprender a crear tablas externas en Athena para investigar un incidente.

Volvemos al hallazgo: rol-restauracion-copias descifró la copia snapshot-2026-07-27 a las 03:42 desde 198.51.100.77, sin MFA. Este es el procedimiento completo, y sirve como plantilla para cualquier investigación.

Paso 0. Congelar la evidencia. Antes de nada.

Esto se hace primero y siempre. Si el incidente acaba en un procedimiento formal, lo que importa no es lo que descubriste, sino que puedas demostrar que los datos no cambiaron mientras investigabas.

Paso 1. ¿Quién asumió el rol? El nombre de sesión sesion-marta-copias es texto libre elegido por quien llamó. Hay que buscar el AssumeRole:

Resultado: arn:aws:iam::111122223333:user/luis.dev, a las 03:41:52, desde 198.51.100.77, mfaAuthenticated: false, agente aws-cli/2.15.30.

Paso 2. Reconstruir toda la sesión. El accessKeyId temporal (ASIA...) identifica la sesión completa:

Resultado:

Paso 3. Interpretar. El patrón es coherente y bastante legible: alguien restauró una copia, intentó crear una nueva instantánea (denegado), y a los 45 minutos borró la instancia restaurada. No hay exfiltración visible —ninguna llamada a S3, ningún CreateDBSnapshot con éxito, ninguna instancia dejada corriendo—. Parece trabajo legítimo hecho mal: restaurar una copia para comprobar algo, de madrugada, sin avisar y sin MFA.

Paso 4. Confirmar con la persona. Y aquí una advertencia importante, porque es donde más se equivoca la gente: CloudTrail dice qué pasó, no por qué. Nunca se acusa a nadie con un registro en la mano sin hablar primero. La conversación con Luis aclara que estaba comprobando si una copia era restaurable tras un aviso de Sara, y que lo hizo de madrugada para no cargar la base de datos en horas de producción. Intención correcta, procedimiento incorrecto.

Paso 5. Comprobar que no hay nada más. Aunque la explicación cuadre, se verifica:

Si esa IP solo aparece en horario de trabajo de Luis durante meses, es su casa o su oficina. Si aparece una vez, a las 3 de la mañana, y nunca más, la conversación es otra.

Paso 6. Acciones correctivas. Sin culpables y con fechas, igual que el post-mortem de 04-04:

Fíjate en la última fila y en la anterior: la respuesta correcta a «Luis restauró una copia a escondidas» no es prohibirlo. Es hacer que probar restauraciones sea fácil, visible y rutinario. Una prueba de restauración es una práctica excelente que en 02-04 recomendamos explícitamente; el problema era el procedimiento, no la actividad.

CloudTrail no solo sirve para investigar: sirve para construir permisos correctos. IAM Access Analyzer puede leer tu historial de CloudTrail y generar una política de mínimo privilegio con exactamente las acciones que una identidad ha usado de verdad en un periodo.

Esto cierra el círculo con 04-01. Allí escribimos pol-mercadofresco-tienda a mano, razonando sobre qué debía poder hacer la tienda. Con dos meses de CloudTrail, Access Analyzer dice qué hizo de verdad, y la diferencia entre ambas listas es un regalo:

• Acciones que están en la política y nunca se usan: candidatas a quitar.
• Acciones que la aplicación intenta y le son denegadas: funcionalidad rota que nadie reportó.

Access Analyzer hace más cosas —detectar recursos accesibles desde fuera de la cuenta, validar políticas— pero esa es su relación directa con CloudTrail y con lo aprendido en 04-01.

Es de lo más barato que se puede montar en AWS, y el argumento definitivo: la primera copia de los eventos de gestión multirregión es gratuita. No hay ninguna excusa técnica ni económica para no tener un trail. Que una cuenta de producción no lo tenga es siempre un hallazgo de auditoría.

Ciclo de vida en S3, para que los 7 años no se paguen a precio de almacenamiento estándar:

Cuidado con dos cosas: DEEP_ARCHIVE tarda hasta 12 horas en restaurar, lo que puede ser inaceptable en una investigación urgente —por eso los dos primeros años se quedan en clases de acceso rápido—, y si has activado Object Lock en modo COMPLIANCE, la regla de ciclo de vida no puede expirar objetos antes de que venza la retención. Puede cambiarlos de clase, no borrarlos.

Limpieza, si has montado esto solo para practicar:

El bucket no se borra a la ligera. Si activaste Object Lock en modo COMPLIANCE, los objetos no se pueden borrar hasta que venza la retención —ni tú, ni la cuenta raíz, ni el soporte de AWS—, y el bucket no se puede eliminar mientras contenga objetos. Es una propiedad deseada, no un fallo. Practica Object Lock en una cuenta de pruebas y con retenciones de días, nunca de años.

1. Crear el trail y no llamar a start-logging. create-trail no arranca el registro. Comprueba siempre con get-trail-status que IsLogging es true.

2. Trail de una sola región. Un atacante crea recursos donde nadie mira. La multirregión es gratis y no tiene contrapartida.

3. Un bucket de auditoría que se puede borrar. Sin política de Deny, sin versionado y sin Object Lock, el registro dura lo que tarde alguien en ejecutar un comando. Y el nivel definitivo es una cuenta separada (09-04).

4. Activar eventos de datos sin selectores. Registrar todos los GetObject de un bucket de fotos son decenas de USD al mes por datos inútiles. Selectores por prefijo y readOnly: false.

5. No poner nombre de sesión al asumir un rol. CloudTrail dirá «alguien con este rol», y no habrá forma de saber quién. --role-session-name con el nombre de la persona.

6. Buscar en CloudTrail lo que dice tu aplicación. No está ahí. CloudTrail registra llamadas a la API de AWS; los errores de tu código están en CloudWatch Logs (05-01).

7. Consultas de Athena sin WHERE de partición. Escanean el bucket entero a 5 USD por TB. Pon siempre anio, mes y dia, y fija BytesScannedCutoffPerQuery en el grupo de trabajo.

8. Ignorar los AccessDenied. Son a la vez el detector de reconocimiento y el detector de permisos mal configurados. Revisarlos semanalmente encuentra cosas rotas que nadie reportó.

9. No verificar la integridad nunca. validate-logs una vez al mes, con la salida guardada. Sin eso, la validación está activada pero no sirve de nada.

10. Retención infinita en CloudWatch Logs para los eventos de CloudTrail. El archivo largo va en S3, que cuesta 20 veces menos. En Logs, 90 días.

11. Acusar a alguien con un registro en la mano. CloudTrail dice qué pasó, no por qué. Se investiga, se contrasta y luego se habla con la persona. Un incidente mal gestionado hace más daño que el incidente.

12. Activar Object Lock en modo COMPLIANCE con 7 años «por probar». No hay marcha atrás. Practica con GOVERNANCE y con retenciones de días.

13. Suponer que el nombre de sesión identifica a alguien. Es una cadena libre. La identidad real está en el evento AssumeRole correspondiente.

Consejo final: revisa CloudTrail cuando no hay incidentes. Media hora al mes ejecutando las consultas de IP desconocidas, AccessDenied agrupados y actividad fuera de horario encuentra cosas —permisos rotos, procesos zombis, claves olvidadas de un antiguo proveedor— que de otro modo solo aparecen el día que hay un problema de verdad.

Los tres ejercicios trabajan sobre la tabla auditoria_mercadofresco.cloudtrail_mercadofresco y el trail trail-mercadofresco definidos en esta lección.

MercadoFresco quiere activar eventos de datos, pero con criterio y con un presupuesto de 5 USD al mes. Volumen mensual real:

Requisitos: hay que poder saber siempre quién ha leído o tocado una copia de la base de datos; hay que detectar si alguien descarga masivamente los informes de negocio; hay que detectar si alguien altera las fotos del catálogo; el presupuesto es de 5 USD.

Escribe los selectores avanzados completos en JSON, calcula el coste de cada uno, justifica qué dejas fuera y por qué, y propón qué alarma montarías sobre los eventos de datos que sí registras.

Un lunes por la mañana, la alarma mercadofresco-accesos-denegados ha saltado dos veces durante el fin de semana. Estos son los datos iniciales:

• Sábado 02:14 a 02:31: 340 eventos con errorCode = AccessDenied.
• Todos desde sourceIPAddress = 203.0.113.201.
• Todos con userIdentity.type = "IAMUser", userName = "integracion-proveedor".
• userAgent: aws-cli/2.9.19 Python/3.9.11 Windows/10.
• Los servicios afectados: iam, s3, ec2, rds, secretsmanager, kms, organizations.
• Domingo 22:40: 6 eventos sin errorCode desde la misma IP y el mismo usuario: ListBuckets, GetBucketLocation, ListObjectsV2 sobre mercadofresco-informes-analitica, GetObject × 3.

Escribe: las consultas SQL exactas que ejecutarías y en qué orden; qué conclusión sacas de cada una; qué acciones de contención tomarías y en qué orden exacto; y qué te dice el hecho de que las 340 llamadas fallaran pero 6 tuvieran éxito. Indica también qué información no vas a poder obtener de CloudTrail y dónde la buscarías.

Marta quiere pasar de investigar después a detectar en el momento. Define cinco detecciones adicionales a las cinco alarmas de la lección, orientadas al riesgo real de MercadoFresco:

1. Alguien crea una clave de acceso permanente para un usuario IAM (después de 04-01, nadie debería).
2. Alguien modifica la política de la clave alias/mercadofresco-datos.
3. Un rol de aplicación se usa desde una IP fuera de la VPC.
4. Alguien desactiva el cifrado de un bucket o activa el acceso público.
5. Se crea un recurso en una región que MercadoFresco no usa.

Para cada una: escribe el patrón del filtro de métricas, decide el umbral y los periodos de la alarma, di si debe despertar a alguien de madrugada o solo generar un correo, y explica qué falso positivo esperas y cómo lo evitarías. Para las que no se puedan resolver con un filtro de métricas, indica qué herramienta usarías (y adelanta cuál será la lección que la cubra).

Solución 1

Cálculo de partida. Registrarlo todo:

Diez veces el presupuesto, y con el 97 % del gasto en lecturas de fotos de tomates.

Selectores propuestos:

Coste resultante:

Muy por debajo de los 5 USD y cumpliendo los tres requisitos.

Qué queda fuera y por qué:

• Lecturas del catálogo (40 M): son fotos públicas de producto servidas por CloudFront. Su lectura no tiene ningún valor de seguridad y cuesta 40 USD. Si algún día hiciera falta analizar patrones de acceso, están los registros de acceso de S3 y los de CloudFront, mucho más baratos.
• mercadofresco-registros-web (8 M): es el ALB escribiendo sus propios registros. Registrar que el ALB escribe sus registros es recursivo e inútil: 8 USD por confirmar lo que ya sabemos.
• Invocaciones de Lambda (1,28 M): 1,28 USD, y ya tenemos mejor visibilidad de esas funciones con las métricas de AWS/Lambda, sus registros y las trazas de X-Ray (05-02). CloudTrail solo diría «se invocó», que es lo menos informativo de todo.

Alarmas sobre los eventos de datos que sí registramos:

Con umbral 0: nadie tiene por qué descargar una copia de la base de datos sin que alguien se entere.

Aquí el umbral no puede ser 0: Sara lee informes todos los días, es su trabajo. 500 objetos en cinco minutos no es leer un informe, es descargarse el almacén entero.

Este último es el patrón más valioso de los tres: lista blanca de identidades esperadas, alarma sobre todo lo demás. Es más robusto que enumerar lo malo, porque cubre también lo que no has previsto.

Solución 2

Lectura inicial de los datos. Tres señales muy claras, antes de ejecutar ninguna consulta:

1. 340 AccessDenied en 17 minutos sobre 7 servicios distintos, incluyendo iam y organizations. Eso no es una aplicación con un permiso mal puesto: una aplicación falla siempre en la misma llamada. Esto es enumeración sistemática de permisos.
2. IAMUser con clave permanente, exactamente lo que 04-01 dice que no debe existir. Un usuario de «integración con proveedor» es el vector clásico: clave que se creó una vez, se puso en un fichero de configuración, y nadie ha rotado en tres años.
3. 20 horas de silencio y luego 6 llamadas con éxito, quirúrgicas, sobre los informes de negocio. Ese espaciado es el patrón: primero se mapea qué se puede hacer, luego se vuelve a por lo que funciona.

Consulta 1: toda la actividad de ese usuario, no solo la del fin de semana.

Qué busco: cuándo empezó todo, si esa IP había aparecido antes, y qué hacía este usuario normalmente. Si su actividad legítima es un PutObject diario a las 06:00 desde otra IP, todo lo del fin de semana es intrusión.

Consulta 2: qué tuvo éxito. Es lo único que importa de verdad.

Qué busco: el alcance exacto de la brecha. Los 340 fallos son ruido; los 6 éxitos son el incidente. Aquí sale qué tres objetos concretos se descargaron de mercadofresco-informes-analitica, y eso determina si hay datos personales implicados y si hay obligación de notificar.

Consulta 3: la clave de acceso, para ver si se usó desde más sitios.

Qué busco: si la clave se usa también desde la IP legítima del proveedor, está comprometida pero sigue en uso legítimo, y desactivarla romperá una integración. Si solo se usa desde 203.0.113.201 desde hace un mes, el proveedor ya no la usa y desactivarla no rompe nada.

Consulta 4: de dónde salió esa clave y cuándo.

Qué busco: si la clave se creó hace dos años y nunca se rotó, o si se creó el viernes pasado, en cuyo caso el compromiso es más profundo: alguien ya tenía acceso y se creó una puerta trasera.

Consulta 5: correlación por IP, más allá de este usuario.

Qué busco: si esa IP ha usado otras identidades, el alcance es mucho mayor.

Contención, en este orden exacto:

Qué significa que 340 fallaran y 6 tuvieran éxito. Es la mejor noticia posible: el mínimo privilegio funcionó. El trabajo de 04-01 es lo que impidió que esas 340 llamadas —a IAM, a KMS, a Secrets Manager, a RDS, a Organizations— hicieran daño. La brecha se limitó a los permisos que ese usuario tenía legítimamente, que era leer informes.

Y a la vez es la peor noticia sobre el diseño: ese usuario nunca debió tener una clave permanente. El acceso de un proveedor debe hacerse con un rol asumible con condición de identidad externa (sts:ExternalId, 04-01), con credenciales temporales que caducan solas. Ese es el arreglo de fondo.

Lo que CloudTrail NO puede decirte:

Esa tabla es la lección más importante del ejercicio: CloudTrail es una pieza de la investigación, no la investigación entera. Da el «quién, qué, cuándo, desde dónde» del plano de control de AWS. Todo lo demás está en otras fuentes, y por eso este módulo entero tiene sentido como conjunto.

Solución 3

Detección 1: creación de clave de acceso permanente.

Detección 2: cambio en la política de la clave KMS.

Merece subrayarse: en 04-02 vimos que borrar una clave KMS tiene un periodo de espera de 7 a 30 días precisamente para dar tiempo a reaccionar. Esta alarma es lo que convierte ese periodo de espera en una defensa real: sin ella, la espera pasa sin que nadie se entere.

Detección 3: rol de aplicación usado desde fuera de la VPC.

Un filtro de métricas no puede hacer esto bien. La sintaxis de patrones de CloudWatch Logs no soporta comparaciones de rango de IP ni negación de prefijos de forma fiable. Se puede aproximar:

…pero es frágil y generará falsos positivos, porque las llamadas a través de un endpoint de VPC (vpce-mercadofresco-s3) o desde ciertos servicios aparecen con otras direcciones.

La herramienta correcta es otra, y aquí hay que ser honesto:

• Amazon GuardDuty tiene un hallazgo específico para esto: UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration, que detecta credenciales de rol de instancia usadas desde fuera de AWS. Es exactamente este caso y funciona sin configuración.
• Alternativamente, una condición en la política de confianza del rol con aws:SourceVpc, que directamente impide el uso desde fuera en lugar de detectarlo. Prevenir es mejor que detectar (04-01).

GuardDuty y Security Hub se ven en visión general en 05-04.

Detección 4: cifrado desactivado o acceso público en un bucket.

Pero esta detección tiene un límite serio: solo detecta el cambio, no el estado. Si el cifrado ya estaba desactivado desde antes de crear la alarma, nunca saltará. Y no puede corregirlo.

Para esto existe una herramienta específica, que es la lección siguiente: AWS Config. Config evalúa el estado actual de todos los recursos contra reglas, detecta las desviaciones existentes —no solo las nuevas— y puede corregirlas automáticamente. Es exactamente la quinta pregunta que dejó abierta el módulo 4.

Detección 5: recurso creado en una región no usada.

Esta detección depende por completo de que el trail sea multirregión. Sin --is-multi-region-trail no verías absolutamente nada, y es el argumento definitivo para activarlo.

Y la prevención, mejor que la detección: una política de control de servicios (SCP) que deniegue todo fuera de las regiones permitidas. Requiere Organizations: 09-04.

Resumen de las cinco:

La conclusión del ejercicio: CloudTrail detecta eventos, no estados. Es perfecto para «alguien ha hecho X», e insuficiente para «el bucket Y está mal configurado desde hace tres meses». Esa segunda pregunta necesita otra herramienta, y es la siguiente lección.

MercadoFresco ya sabe quién hizo qué. Tienes clara la diferencia esencial que define este servicio: CloudTrail registra llamadas a la API de AWS; CloudWatch Logs registra lo que dice tu aplicación. Uno responde «¿quién borró el bucket?», el otro «¿por qué falló el pago?». No compiten: cubren universos distintos, y buscar en el equivocado cuesta horas.

Sabes que el historial de eventos de 90 días está siempre ahí, gratis, y conoces sus cinco limitaciones —90 días, solo gestión, un atributo por búsqueda, sin SQL, sin inmutabilidad— que son exactamente las razones para crear un trail. Has creado trail-mercadofresco con las cuatro banderas que importan: multirregión (gratis, y sin ella un atacante crea recursos donde nadie mira), eventos globales, validación de integridad y cifrado con alias/mercadofresco-datos. Y sabes que create-trail no arranca el registro: hay que llamar a start-logging y comprobarlo con get-trail-status.

Has montado el bucket mercadofresco-auditoria-cloudtrail con las cuatro capas de protección —política con Deny de borrado, versionado, Object Lock en modo COMPLIANCE que ni la cuenta raíz puede saltarse, y la cuenta separada como paso pendiente de 09-04— porque un registro de auditoría que el atacante puede borrar no es un registro de auditoría. Y conoces la cadena de resúmenes firmados que hace imposible alterar un fichero sin romperla, con validate-logs ejecutado el primer lunes de cada mes.

Sabes leer un evento completo: eventTime, eventSource, eventName, sourceIPAddress, userAgent, requestParameters, responseElements (nulo en las lecturas) y errorCode, que solo aparece cuando la llamada falla —y que es una de las propiedades más valiosas de CloudTrail, porque un atacante probando puertas deja un reguero de AccessDenied—. Dominas los seis tipos de userIdentity, con AssumedRole como el más frecuente y el más confuso, y sabes que el nombre de sesión es lo único que convierte un rol compartido en una persona identificable, y que es texto libre: la identidad real está en el AssumeRole correspondiente.

Y has respondido a la tercera pregunta del módulo 4. Quién descifró la última copia: tres eventos de Decrypt, dos normales —RDS cifrando su copia automática y una instancia del ASG desde 10.0.11.24— y uno que no lo era: rol-restauracion-copias, a las 03:42, desde 198.51.100.77, sin MFA, sobre snapshot-2026-07-27. Gracias al encryptionContext de 04-02, que es lo que convierte un evento genérico de KMS en «alguien descifró la copia del 27 de julio de mercadofresco-pedidos».

Sabes distinguir eventos de gestión (primera copia gratis) de eventos de datos (0,10 USD por 100.000, y volumen millonario), y has escrito selectores avanzados que bajan la factura de 40 USD a 0,06 USD sin perder nada: todo sobre las copias y los informes, solo escrituras sobre el catálogo, nada sobre los registros web. Conoces Insights por 0,53 USD al mes, y sus dos limitaciones: 7 días de línea base y solo detecta anomalías de volumen.

Has enviado el trail también a CloudWatch Logs —90 días ahí, 7 años en S3, cada destino con su propósito— y has montado las cinco alarmas de seguridad estándar: uso de la cuenta raíz, cambios en el trail (la más importante de todas, porque avisa de que la auditoría está siendo atacada), descifrado de copias excluyendo al propio RDS, picos de AccessDenied con umbral realista, y cambios de configuración de seguridad. Y sabes consultar con Athena —con el WHERE de partición siempre puesto y BytesScannedCutoffPerQuery como red de seguridad— para responder quién asumió un rol, quién leyó el secreto de mfadmin, qué llamadas fallaron y qué IP desconocidas han aparecido; con CloudTrail Lake como alternativa gestionada, evaluada y descartada con criterio.

Has recorrido una investigación completa: congelar la evidencia antes de nada, encontrar el AssumeRole real, reconstruir la sesión entera por accessKeyId, interpretar el patrón, hablar con la persona antes de concluir nada —CloudTrail dice qué pasó, no por qué— y cerrar con acciones correctivas con responsable y fecha, entre ellas la más importante: hacer que probar restauraciones sea fácil y visible en lugar de prohibirlo. Y conoces IAM Access Analyzer generando políticas de mínimo privilegio a partir del uso real, que cierra el círculo con 04-01. Todo por 1,59 USD al mes.

Pero fíjate en lo que este servicio no puede hacer, porque el ejercicio 3 lo dejó claro: CloudTrail detecta eventos, no estados. Sabe que alguien llamó a DeleteBucketEncryption esta mañana. No sabe que el bucket mercadofresco-registros-web lleva cinco meses sin cifrado porque nunca se configuró. No sabe que hay un grupo de seguridad con 0.0.0.0/0 en el puerto 22 desde una prueba de marzo. No puede decir cuántos recursos incumplen la política de etiquetado obligatorio de MercadoFresco. Y desde luego no puede arreglarlo solo.

Esa es la quinta y última pregunta que dejó abierta el módulo 4: nada avisa si alguien desactiva el cifrado de un bucket o abre un grupo de seguridad al mundo. En la lección 05-04, «AWS Config», veremos qué es el elemento de configuración de un recurso y su línea temporal, en qué se diferencia exactamente de CloudTrail —quién hizo la llamada frente a cómo quedó el recurso—, cómo se activa el grabador de configuración con su canal de entrega, las reglas gestionadas que MercadoFresco necesita (s3-bucket-server-side-encryption-enabled, restricted-ssh, required-tags y compañía), las reglas propias con Lambda y con Guard, la remediación automática con documentos de Systems Manager que vuelve a cifrar un bucket o cierra un grupo de seguridad sin que nadie intervenga, los paquetes de conformidad alineados con CIS y PCI DSS, y el coste real por elemento de configuración, que es la partida que más fácilmente se dispara de todo este módulo.