Auditoría y Seguimiento de Configuración con CloudTrail, Config y Logging Centralizado en AWS
_Category: Logging & Monitoring_
Cuando ocurre un incidente de seguridad, la primera pregunta que escucha cualquier equipo es: "¿tienen los logs?". Sin logs, es imposible saber qué pasó; si fueron alterados, no se puede confiar en ellos. El examen SCS-C03 pregunta repetidamente cómo registrar, proteger y aprovechar la evidencia de auditoría. Recorremos toda la arquitectura de auditoría y logging: CloudTrail, Config, CloudWatch Logs, EventBridge, Kinesis Data Firehose, Athena, VPC Flow Logs y Audit Manager.
---
El Significado de la Auditabilidad y lo que Pregunta el SCS-C03
Auditabilidad significa poder demostrar, incluso tiempo después, quién hizo qué, cuándo, dónde y de qué manera. Un registro de auditoría confiable debe reunir tres cualidades: integridad (sin omisiones), inmutabilidad (resistente a modificaciones) y disponibilidad (accesible cuando se necesita).
Estos son los patrones de escenario más representativos del SCS-C03.
"Registrar todas las llamadas a la API y detectar cualquier alteración" → CloudTrail + Log File Integrity Validation + S3 Object Lock "Rastrear el estado anterior y posterior cuando cambia la configuración de un recurso" → AWS Config Configuration Item "Notificar al equipo de seguridad en el instante en que ocurra una llamada a la API específica" → CloudTrail + EventBridge + SNS "Concentrar los logs de múltiples cuentas en un solo lugar" → Log Archive Account + Kinesis Data Firehose
CloudTrail y Config responden preguntas distintas. CloudTrail responde "¿qué ocurrió?" (historial de llamadas a la API), mientras que Config responde "¿en qué estado está este recurso ahora?" (instantánea de configuración e historial de cambios). El examen presenta escenarios similares para inducir confusión entre ambos servicios, por lo que es imprescindible tener clara la división de responsabilidades.
---
Los Tres Tipos de Eventos de CloudTrail: Management, Data e Insights
Pensar en CloudTrail como el libro de registro de accesos de un edificio ayuda a entender su función. Ese libro tiene tres tipos de anotaciones distintas.
| Tipo de evento | Qué registra | Activo por defecto | Ejemplos | |---------------|-------------|-------------------|----------| | Management Events | APIs de administración de recursos AWS (plano de control) | Sí (Event History: 90 días) | CreateBucket, RunInstances, AuthorizeSecurityGroupIngress | | Data Events | Acceso a datos dentro de los recursos (plano de datos) | No (requiere configuración manual) | S3 GetObject/PutObject, Lambda Invoke, DynamoDB GetItem | | Insights Events | Detección automática de patrones de actividad de API anómalos | No (requiere activación manual) | Pico repentino en llamadas a TerminateInstances |
Los Management Events se pueden consultar gratuitamente en la consola durante 90 días a través del Event History, sin necesidad de crear un Trail. Sin embargo, los registros se eliminan después de ese período, de modo que para conservarlos a largo plazo hay que crear un Trail y almacenarlo en S3.
Los Data Events se habilitan de forma selectiva por bucket de S3, función Lambda o tabla de DynamoDB. Si no se activan los Data Events de S3, las operaciones GetObject y PutObject no quedarán registradas. En entornos con alto volumen de tráfico, el volumen de logs puede crecer de forma exponencial, por lo que hay que evaluar el equilibrio entre visibilidad y costo.
Los Insights Events utilizan los Management Events de los últimos siete días como línea base para detectar automáticamente actividad de API inusual. Si una llamada que normalmente ocurre diez veces al día de repente escala a miles, se genera un Insights Event. Son muy útiles para la detección temprana de amenazas internas o de credenciales comprometidas.
Comparación entre Event History y Trail: Event History es gratuito, pero tiene un límite de 90 días y se limita a una sola región. Un Trail permite retención a largo plazo en S3, análisis con Athena y, con la configuración Multi-Region, concentra los eventos de todas las regiones en un único bucket.
!Los 3 tipos de eventos de CloudTrail
Diseño de Trails: Patrones Multi-Region, Org-wide y Tamper-proof
Cualquier diseño completo de Trail requiere tomar tres decisiones clave.
Activar "Apply trail to all regions" convierte el Trail en Multi-Region, de modo que todos los eventos de cada región se concentran en un único bucket de S3. Para capturar también los eventos de servicios globales como IAM, STS o CloudFront, es necesario habilitar adicionalmente "Include global service events".
Crear un Trail Org-wide desde la cuenta de administración de Organizations lo aplica automáticamente a todas las cuentas miembro.
El núcleo del diseño es el bloque de protección contra manipulaciones (Tamper-proof).
| Mecanismo de protección | Función | |------------------------|--------| | Log File Integrity Validation | Genera un archivo Digest por hora (SHA-256 + firma RSA); se valida con aws cloudtrail validate-logs | | S3 Object Lock modo Compliance | Nadie, ni siquiera la cuenta raíz, puede eliminar los logs durante el período de retención — equivale a una caja de seguridad notariada | | S3 Object Lock modo Governance | Solo quien tenga el permiso BypassGovernanceRetention puede desactivarlo | | S3 MFA Delete | Exige autenticación MFA para eliminar versiones de objetos en S3 | | Cross-Account Log Archive | La cuenta operativa solo tiene permiso PutObject en el bucket de logs; no puede eliminar | | KMS SSE-KMS | Protege la confidencialidad del contenido de los logs; la política de clave controla quién puede descifrar |
La esencia del patrón Log Archive Account es la separación de cuentas. Todos los logs de las cuentas miembro se concentran en el bucket S3 de una cuenta Log Archive dedicada, y las cuentas miembro solo tienen permiso PutObject. Si una cuenta operativa se ve comprometida, el atacante no podrá eliminar ni alterar los logs.
---
AWS Config: Seguimiento de Cambios de Configuración y Cumplimiento Automatizado
AWS Config se puede comparar con el diario de cambios de mobiliario de una habitación: registra dónde estaba el sofá, quién lo movió y si actualmente se encuentra en la posición reglamentaria.
El Configuration Item (CI) es una instantánea del estado de un recurso. Contiene el tipo de recurso, sus valores de atributos, los recursos relacionados y la marca de tiempo del cambio. Cada vez que el recurso se modifica se genera un nuevo CI, lo que permite consultar el historial en formato de línea de tiempo. El Configuration Recorder es el motor que rastrea automáticamente los recursos compatibles; debe crearse uno por región.
Config Aggregator recopila datos de Config de múltiples cuentas y regiones en una cuenta de agregación, permitiendo una visión centralizada desde la cuenta de administración.
Las Config Rules evalúan automáticamente si la configuración cumple con las políticas establecidas. Existen tres categorías: Managed Rules (más de 150 reglas provistas por AWS, como "restricted-ssh" o "s3-bucket-public-read-prohibited"), Custom Rules (políticas personalizadas mediante funciones Lambda) y Conformance Pack (conjuntos de reglas agrupadas por marco regulatorio, como PCI-DSS, HIPAA o NIST 800-53).
Las Remediation Actions vinculan los recursos en incumplimiento con documentos de AWS Systems Manager Automation para aplicar correcciones de forma automática.
| Pregunta | Servicio que responde | |---------|----------------------| | ¿Quién modificó este recurso? | CloudTrail (responsable de la llamada, UserAgent, IP) | | ¿Cuándo y cómo cambió este recurso? | Config (línea de tiempo de CIs) | | ¿Este recurso cumple actualmente con la política? | Config Rules |
---
CloudWatch Logs y EventBridge para Alertas en Tiempo Real y Automatización
Enviar los logs de CloudTrail solo a S3 implica una demora de hasta 15 minutos. Para reaccionar en tiempo real existen dos rutas complementarias.
La primera es la ruta de CloudWatch Logs. Al activar "Enviar a CloudWatch Logs" en el Trail, los eventos se entregan al grupo de logs casi en tiempo real. Un Metric Filter detecta patrones específicos para generar una CloudWatch Alarm que envía notificaciones por SNS. Por ejemplo, el patrón para detectar intentos de inicio de sesión fallidos en la consola es . Un Subscription Filter reenvía en tiempo real el flujo del grupo de logs a Kinesis Data Firehose, Kinesis Data Streams o Lambda.
La segunda es la ruta de EventBridge. EventBridge funciona como una sirena que suena en el instante en que ocurre el evento: genera eventos pocos segundos después de la llamada a la API y dispara Lambda, SNS, SQS, Step Functions y otros destinos. No requiere configurar el envío de CloudTrail a CloudWatch Logs.
Criterios de selección en el examen: para detectar cambios de API en tiempo real, la respuesta es CloudTrail + EventBridge. Una Config rule puede tardar varios minutos en completar la evaluación tras el cambio de configuración y no genera alerta si el estado de cumplimiento no cambia. Un Metric Filter de CloudWatch Logs requiere configurar adicionalmente el envío de CloudTrail a CloudWatch Logs.
CloudWatch Logs Insights permite analizar los logs de forma interactiva con consultas similares a SQL. Las consultas guardadas pueden incluirse en paneles de control o ejecutarse periódicamente mediante consultas programadas.
---
Arquitectura de Agregación Centralizada de Logs: Log Archive Account, Firehose, OpenSearch y Athena
Cuando decenas o cientos de cuentas acumulan logs de forma independiente, obtener una visión global se vuelve muy difícil. El patrón Log Archive Account es la solución. Se concentran todos los logs en el bucket S3 de una cuenta dedicada y las cuentas miembro solo tienen permiso PutObject. La combinación de S3 Object Lock (modo Compliance) con un Trail Org-wide garantiza la preservación de los logs incluso si una cu