Módulo 7: Detective Vs Preventive Guardrails
4. Guardrails detectivos: CloudTrail, Config y GuardDuty, nombrados
Descripción
Las lecciones 2 y 3 cerraron el lado preventivo de este módulo. Esta lección cambia de categoría por completo: presenta los tres guardrails detectivos centrales de AWS —CloudTrail, Config y GuardDuty— con precisión sobre qué hace cada uno, por qué son complementarios entre sí (no intercambiables), y por qué solo uno de los tres se construye, aunque sea parcialmente, en la lección 5. Los otros dos se nombran, con la fuente exacta de por qué.
Conexión con el módulo
Vuelve a THREAT-MODEL.md (Módulo 1): TM-03, Repudiation — "No CloudTrail trail exists", con el impacto documentado: "Manual out-of-band changes (e.g. iam attach-role-policy) leave no queryable record". Esa fila lleva abierta desde el Módulo 1, esperando este módulo. Esta lección explica qué herramienta la resuelve y por qué; la lección 5 la construye hasta donde este laboratorio lo permite.
Analogía: tres cámaras que graban cosas distintas, no la misma cosa tres veces
Vuelve a la cámara de seguridad de la lección 1. Un edificio con seguridad seria no tiene una sola cámara — tiene varias, cada una apuntando a algo distinto, porque ninguna cámara sola responde todas las preguntas que un incidente real plantea. Una cámara en la entrada registra quién entró y cuándo — un registro de eventos, cronológico, por persona. Un sistema de sensores en cada puerta registra el estado actual de cada cerradura — no quién la abrió, sino si está, en este momento, correctamente cerrada o si alguien la dejó entreabierta. Y un analista de seguridad entrenado, mirando ambos sistemas a la vez, puede notar un patrón que ninguno de los dos, por separado, señalaría como sospechoso —tres puertas abiertas por la misma persona en cinco minutos, en tres pisos distintos—.
CloudTrail, Config y GuardDuty son, con bastante precisión, esas tres cámaras:
- CloudTrail registra quién hizo qué, y cuándo — un historial cronológico de llamadas a la API de AWS. Responde: "¿quién llamó a
iam:AttachRolePolicyel martes a las 3pm?". - AWS Config registra el estado de la configuración de un recurso a lo largo del tiempo — no quién lo cambió, sino cómo estaba configurado en cada momento, y si eso cumple una regla. Responde: "¿este bucket tuvo, en algún momento del último mes, acceso público habilitado?".
- GuardDuty analiza patrones sobre los datos de los otros dos (y más) para detectar amenazas — no un registro pasivo, sino un análisis activo con inteligencia de amenazas. Responde: "¿esta secuencia de eventos, tomada en conjunto, parece un ataque en curso?".
Ninguna de las tres reemplaza a las otras dos. Un incidente de seguridad real casi siempre se investiga con las tres a la vez, cada una respondiendo la parte de la pregunta que le corresponde.
CloudTrail: el historial de quién hizo qué
La documentación oficial de AWS lo define así: "AWS CloudTrail is an AWS service that helps you enable operational and risk auditing, governance, and compliance of your AWS account. Actions taken by a user, role, or an AWS service are recorded as events in CloudTrail". Tres formas de trabajar con esos eventos, documentadas oficialmente y con diferencias que importan para lo que viene:
- Event history — "a viewable, searchable, downloadable, and immutable record of the past 90 days of management events", disponible automáticamente, sin ninguna configuración previa, desde el momento en que se crea la cuenta, sin ningún costo.
awslocal cloudtrail lookup-events(lección 5) consulta exactamente esta fuente. - Trails — "capture a record of AWS activities, delivering and storing these events in an Amazon S3 bucket, with optional delivery to CloudWatch Logs and Amazon EventBridge". Un trail es lo que la lección 5 declara en HCL: persistencia de largo plazo (más allá de los 90 días de Event history) y, como vas a usar en la lección 7, la puerta de entrada a EventBridge para reaccionar a eventos en casi tiempo real.
- CloudTrail Lake — un almacén de datos administrado para retención de hasta 10 años, con consultas tipo SQL — fuera del alcance de esta guía, nombrado aquí solo para completar el panorama.
AWS Config: el estado de la configuración en el tiempo
La documentación oficial lo distingue de CloudTrail con precisión: "AWS Config provides a detailed view of the configuration of AWS resources in your AWS account. This includes how the resources are related to one another and how they were configured in the past so that you can see how the configurations and relationships change over time". La diferencia central con CloudTrail, en una frase: CloudTrail responde "¿quién llamó a esta API?"; Config responde "¿cómo estaba configurado este recurso en este momento, y eso cumple una regla?" — sin necesitar reconstruir esa respuesta a partir de un historial de llamadas.
La propia documentación lo aplica directamente al tipo de pregunta que este módulo entero le importa: "To analyze potential security weaknesses, you need detailed historical information about your AWS resource configurations, such as the AWS Identity and Access Management (IAM) permissions that are granted to your users, or the Amazon EC2 security group rules that control access to your resources" — y da un ejemplo casi calcado del caso de esta guía: poder confirmar si un usuario tenía permiso de modificar una VPC en una fecha específica del pasado, sin depender de reconstruir esa respuesta evento por evento desde CloudTrail.
Para Andes Cargo, específicamente, Config respondería preguntas que ni CloudTrail ni un permission boundary responden hoy: "¿el bucket andes-cargo-shipment-docs tuvo, en algún momento, public-access-block deshabilitado?" — exactamente el hallazgo TM-04 de THREAT-MODEL.md, ahora resuelto en el M4 con no-public-buckets.rego (preventivo), pero que Config podría, además, confirmar continuamente que sigue cumpliéndose, no solo en el momento del plan.
GuardDuty: detección de amenazas sobre los datos de los otros dos
La documentación oficial es la más directa de las tres: "Amazon GuardDuty is a threat detection service that continuously monitors, analyzes, and processes AWS data sources and logs in your AWS environment. GuardDuty uses threat intelligence feeds, such as lists of malicious IP addresses and domains, file hashes, and machine learning (ML) models to identify suspicious and potentially malicious activity". La misma fuente confirma exactamente qué ingiere de fábrica, sin configuración adicional: "these data sources include AWS CloudTrail management events, VPC flow logs (from Amazon EC2 instances), and DNS logs" — GuardDuty consume CloudTrail, no lo reemplaza. Es la tercera cámara de la analogía: la que correlaciona lo que las otras dos registran para detectar un patrón que ninguna de las dos, mirada sola, marcaría como sospechoso.
Entre las amenazas que la propia documentación lista que GuardDuty puede ayudar a detectar, dos son directamente relevantes al vector de riesgo que el Módulo 1 de esta guía citó desde VALIDACION.md —"credenciales comprometidas" y "actividad no autorizada"—: "Compromised and exfiltrated AWS credentials" y actividad de minería de criptomonedas no autorizada en cómputo comprometido.
La tabla que resume las tres
| CloudTrail | AWS Config | GuardDuty | |
|---|---|---|---|
| Pregunta que responde | ¿Quién hizo qué, y cuándo? | ¿Cómo estaba configurado esto, en cualquier momento del pasado? | ¿Este patrón de eventos parece una amenaza real? |
| Fuente de datos | Llamadas a la API de AWS | Snapshots de configuración de recursos | CloudTrail + VPC Flow Logs + DNS logs + inteligencia de amenazas |
| Naturaleza | Registro pasivo (log) | Registro de estado + evaluación de reglas | Análisis activo con ML |
| En esta guía | Ejecutado parcialmente (lección 5) — el recurso se declara, el intento de lectura corre de verdad | Nombrado — no confirmado en el plan gratuito de LocalStack | Nombrado — no confirmado en el plan gratuito de LocalStack |
La razón de por qué solo CloudTrail avanza a "ejecutado parcialmente" es específica, no una preferencia arbitraria: es la única de las tres cuya cobertura de API en LocalStack está confirmada con evidencia directa —la propia guía de introducción de LocalStack a CloudTrail demuestra create-trail, start-logging, put-event-selectors y lookup-events como operaciones funcionales—. Ni GuardDuty ni Config aparecen con ese mismo nivel de confirmación dentro del plan gratuito Hobby/Community, que cubre "30+ servicios emulados" frente a los "55+"/"110+" de los planes de pago Base y Ultimate.
Por qué "queda evidencia" es el complemento necesario de "no debería pasar"
Vuelve a la lección 1 de este módulo: ningún control preventivo es perfecto. conftest (M4) solo evalúa las reglas que alguien escribió — un patrón de riesgo que nadie anticipó nunca llega a convertirse en una regla deny. Un permission boundary (lección 3 de este módulo) solo bloquea lo que su Deny explícito menciona — una categoría de riesgo que nadie pensó en incluir en el boundary queda, sin que nadie lo note, fuera de su alcance. Trivy y Checkov (M5) solo detectan lo que sus bases de reglas de la comunidad ya conocen — una técnica de ataque genuinamente nueva no tiene, todavía, ninguna regla que la detecte.
Esta no es una crítica a ninguno de esos controles — es, sencillamente, un límite estructural de cualquier control preventivo: actúa sobre lo que alguien anticipó. Un guardrail detectivo no tiene ese límite de la misma forma: CloudTrail registra toda llamada a la API, sin importar si alguien anticipó ese patrón específico o no. Es la razón por la que un sistema de seguridad real nunca elige entre preventivo y detectivo — necesita ambos, exactamente por esta asimetría: lo preventivo reduce cuántas veces vas a necesitar mirar el registro; lo detectivo es lo único que responde con evidencia las veces que lo preventivo, por la razón que sea, no bastó.
Errores comunes
Pensar que GuardDuty reemplaza a CloudTrail, porque "ya lo incluye" (de lectura superficial). Qué pasa: alguien, leyendo que GuardDuty consume eventos de CloudTrail automáticamente, concluye que activar GuardDuty hace innecesario tener un trail propio. Cómo detectarlo: si tu plan de seguridad incluye GuardDuty pero ningún aws_cloudtrail explícito. Cómo corregirlo: GuardDuty consume los management events de CloudTrail, que están disponibles de fábrica vía Event history (90 días, sin ningún trail) — pero un trail explícito (lección 5) es lo que habilita persistencia de largo plazo y la entrega a EventBridge que la lección 7 necesita. Son servicios complementarios, con retenciones y propósitos distintos, no uno un subconjunto redundante del otro.
Confundir Config con un escáner de IaC como Trivy o Checkov (de categoría equivocada). Qué pasa: alguien, viendo que tanto Config como Trivy/Checkov "evalúan reglas sobre configuración", los trata como intercambiables. Cómo detectarlo: si tu comparación entre Config y Trivy no menciona la diferencia de cuándo actúa cada uno. Cómo corregirlo: Trivy y Checkov (M5) evalúan el HCL antes del apply — son preventivos, evalúan una intención declarada. Config evalúa el recurso real, ya desplegado, de forma continua — es detectivo, evalúa lo que efectivamente existe en la cuenta, incluidos cambios hechos fuera de Terraform (por ejemplo, un cambio manual en la consola de AWS que ningún escaneo de IaC podría ver, porque nunca pasó por un plan).
Esperar que esta lección incluya HCL de GuardDuty o Config (de expectativa). Qué pasa: alguien, después de leer las tres secciones de esta lección, busca un aws_guardduty_detector o aws_config_configuration_recorder en algún archivo de este módulo. Cómo detectarlo: si buscas esos nombres de recurso en cualquier .tf de andes-cargo-infra/. Cómo corregirlo: esta lección los nombra, deliberadamente, sin construirlos — la razón, ya explicada arriba, es que ninguno de los dos está confirmado en el plan gratuito de LocalStack, a diferencia de CloudTrail, cuya cobertura de API sí está documentada y demostrada por LocalStack mismo. Nombrar sin construir, con la razón explícita, es exactamente la disciplina que esta guía practica desde su primera lección — no es una omisión escondida.
Ejercicios
Ejercicio 1 — Asigna cada pregunta a la herramienta correcta. Sin volver a mirar la tabla de esta lección, decide qué herramienta —CloudTrail, Config o GuardDuty— respondería mejor cada una de estas preguntas: (a) "¿quién ejecutó terraform apply la semana pasada, con qué credenciales?"; (b) "¿el rol AppServerRole tuvo, en algún momento del último trimestre, una política con Action: "*"?"; (c) "¿hay una secuencia de eventos, en la última hora, que se parezca a credenciales comprometidas siendo usadas desde una ubicación inusual?".
Ver solución
(a) CloudTrail — es exactamente el tipo de pregunta "quién hizo qué, cuándo" que un historial de llamadas a la API responde directamente. (b) AWS Config — es una pregunta sobre el estado de configuración en el tiempo, no sobre quién hizo una llamada específica; Config mantiene ese historial de configuración incluso si el cambio nunca pasó por una llamada de API que CloudTrail pudiera aislar fácilmente como "la causa". (c) GuardDuty — es, explícitamente, el tipo de detección de patrón/anomalía sobre múltiples fuentes de datos que ni un registro plano de eventos (CloudTrail) ni un registro de configuración (Config) hacen por sí solos; requiere el análisis activo con inteligencia de amenazas que es la característica central de GuardDuty.
Ejercicio 2 — Explica, con la analogía de las tres cámaras, por qué "ya tenemos CloudTrail" no es una respuesta completa a "¿está Andes Cargo bien monitoreado?". Un compañero, después de la lección 5, dice: "ya tenemos CloudTrail corriendo, con eso alcanza". ¿Qué le responderías?
Ver solución
Una respuesta completa reconoce el valor real de CloudTrail sin sobreestimarlo: "CloudTrail resuelve una pregunta específica — quién hizo qué, cuándo — y la resuelve bien. Pero no responde si un recurso, ahora mismo, está configurado de forma insegura sin que nadie lo haya 'llamado' explícitamente para cambiarlo (eso es Config), ni detecta un patrón de eventos que, tomado en conjunto, indique un ataque en curso (eso es GuardDuty). Es exactamente como tener una sola cámara en la entrada de un edificio: sabes quién entró, pero no si dejaron una puerta interior abierta, ni si el patrón de movimientos de las últimas dos horas se parece a un robo en curso. CloudTrail es necesario, pero 'tenerlo' no es lo mismo que 'estar bien monitoreado' — las otras dos cámaras cubren preguntas que CloudTrail, por diseño, no está hecho para responder."
Ejercicio 3 — Justifica, con la fuente exacta de esta lección, por qué CloudTrail avanza a "ejecutado parcialmente" en la lección 5 y Config/GuardDuty no. Sin repetir la tabla de esta lección palabra por palabra, explica la diferencia de evidencia que justifica ese trato distinto entre los tres.
Ver solución
La diferencia no es una preferencia de esta guía — es una diferencia de evidencia documentada. La propia guía de introducción de LocalStack a CloudTrail demuestra, con ejemplos de línea de comandos funcionales, operaciones como create-trail, start-logging, put-event-selectors y lookup-events — esa es evidencia directa, de la propia documentación de LocalStack, de que la cobertura de API de CloudTrail existe y es demostrable. Ni AWS Config ni GuardDuty tienen ese mismo nivel de confirmación documentada dentro del plan gratuito Hobby/Community — la fuente de esta guía sobre cobertura por plan (LocalStack — Pricing) solo confirma que el plan Hobby cubre "30+ servicios emulados" en general, sin confirmar específicamente que Config o GuardDuty estén entre ellos. Avanzar CloudTrail a "ejecutado parcialmente" y dejar los otros dos como "nombrados" es, con precisión, seguir la evidencia disponible, no una elección arbitraria.
Resumen y siguiente paso
En esta lección nombraste y distinguiste los tres guardrails detectivos centrales de AWS: CloudTrail (quién hizo qué, cuándo), AWS Config (cómo estaba configurado esto, en el tiempo) y GuardDuty (¿este patrón parece una amenaza?) — con la fuente oficial exacta de cada uno, y con el criterio explícito de por qué son complementarios, nunca intercambiables. Confirmaste, con evidencia citada, por qué solo CloudTrail avanza a construcción parcial en la lección siguiente, mientras Config y GuardDuty quedan nombrados por falta de confirmación de cobertura en el plan gratuito de LocalStack.
Antes de avanzar deberías poder: explicar la diferencia entre las tres herramientas sin usar la palabra "logs" para las tres por igual; justificar, con la fuente exacta de esta lección, por qué CloudTrail tiene un trato distinto a los otros dos en esta guía; y explicar por qué "queda evidencia" es el complemento necesario de "no debería pasar", no un sustituto de segunda categoría.
La lección 5 construye el aws_cloudtrail real de Andes Cargo — el intento honesto de correr CloudTrail hasta donde la cobertura de LocalStack llega, con el resultado real documentado tal cual salga.
Recursos
- AWS Docs — AWS CloudTrail User Guide — la fuente oficial completa citada en esta lección, incluida la distinción entre Event history, Trails y CloudTrail Lake.
- AWS Docs — What Is AWS Config? — la fuente oficial completa de Config, incluido el ejemplo de auditoría de permisos IAM en el tiempo.
- AWS Docs — What is Amazon GuardDuty? — la fuente oficial completa de GuardDuty, incluidas las fuentes de datos fundacionales (CloudTrail, VPC Flow Logs, DNS logs).
- LocalStack — Pricing — la fuente de cobertura por plan (Hobby/Base/Ultimate) ya citada en el Módulo 1 de esta guía.
- LocalStack Docs — CloudTrail — la guía de introducción que demuestra
create-trail,start-logging,put-event-selectorsylookup-eventscomo operaciones funcionales, la evidencia citada en esta lección. - Este curso, Módulo 1, lección 7 (
THREAT-MODEL.md) — el hallazgoTM-03que esta lección y la siguiente empiezan a resolver.