Registro y Security Lake

No puedes detectar lo que no registras, ni investigar lo que no guardaste. El registro es la capa detectiva de la defensa en profundidad: la que te salva cuando la prevención ya falló. Pero cada fuente de AWS ve una parte distinta del mundo, y ninguna lo ve todo. Esta nota recorre las tres fuentes base —CloudTrailAWS CloudTrailServicio de AWS que registra las llamadas a la API (quién, qué, cuándo, desde dónde) como eventos de gestión y, opcionalmente, de datos., VPC Flow LogsVPC Flow LogRegistro de los flujos de red (metadatos de la 5-tupla) de una VPC en AWS; indica origen, destino, puertos y si el tráfico fue ACCEPT o REJECT, pero no ve el payload. y DNS query logs— con especial cuidado en qué registra y qué NO cada una, y cómo las unifica Amazon Security LakeAmazon Security LakeLago de datos de seguridad gestionado que centraliza fuentes de AWS y de terceros en tu cuenta y las normaliza al esquema OCSF en Parquet. en formato OCSFOCSFEsquema abierto y agnóstico de proveedor para normalizar eventos de seguridad a una estructura común, usado por Amazon Security Lake..

Si vienes de captura de tráfico y técnicas cloud y logs en AWS, esto es el siguiente nivel: pasar de leer un log suelto a construir una cadena de registro completa.

CloudTrail: el plano de control#

CloudTrail responde a la pregunta forense más importante en la nube: quién llamó a qué API, cuándo y desde dónde. Es la base de casi toda investigación en AWS.

• Eventos de gestión (crear, modificar o borrar recursos: RunInstances, CreateUser, AuthorizeSecurityGroupIngress). Se registran por defecto; el historial guarda 90 días.
• Eventos de datos (operaciones sobre el contenido: GetObject/PutObject en S3, Invoke en Lambda). Son de alto volumen, NO se registran por defecto, tienen coste y hay que activarlos explícitamente en un trail o event data store.

Para una detección seria, el patrón es un trail organizacional que entrega a la cuenta log-archive aislada:

resource "aws_cloudtrail" "org" {
  name                          = "citas-org-trail"
  s3_bucket_name                = aws_s3_bucket.log_archive.id
  is_organization_trail         = true # [!code highlight]
  is_multi_region_trail         = true
  enable_log_file_validation    = true # [!code highlight]

  event_selector {
    read_write_type           = "All"
    include_management_events = true
  }
}

Dos piezas que no debes olvidar:

• Validación de integridad (enable_log_file_validation): CloudTrail genera digest files firmados cada hora, con hashes SHA-256 de los logs encadenados entre sí. Si alguien altera o borra un log, la cadena de validación lo delata.
• Object Lock en el bucket de log-archive: modo WORM (write-once-read-many). Ni un administrador de producción comprometido —ni el root de esa cuenta en modo compliance— puede borrar la evidencia durante la retención.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "NoApagarAuditoria",
      "Effect": "Deny",
      "Action": ["cloudtrail:StopLogging", "cloudtrail:DeleteTrail"],
      "Resource": "*"
    }
  ]
}

VPC Flow Logs: metadatos de red#

Los Flow Logs registran los metadatos del tráfico IP de una ENI, subred o VPC: la 5-tupla (origen/destino, puertos, protocolo), bytes, paquetes y, lo más útil, la acción ACCEPT o REJECT.

Para qué sirven en la práctica: ver intentos de conexión bloqueados por un security group (REJECT repetidos a un puerto), detectar un pico de egreso hacia una IP desconocida (posible exfiltración), o confirmar qué habló con qué durante un incidente.

DNS query logs: qué dominios se resolvieron#

Los Route 53 Resolver query logs registran las consultas DNS que originan los recursos de tu VPC: el dominio consultado, el tipo de registro (A, AAAA…), el código de respuesta y la IP devuelta, junto con qué instancia preguntó. También registran la acción del DNS Firewall sobre esa consulta.

Su valor es detectar lo que la red por sí sola no ve: malware que resuelve dominios de command and control, tunelización por DNS (muchas consultas a subdominios largos de un mismo dominio) o un recurso que de pronto resuelve dominios que nunca debería tocar. Complementan al DNS Firewall de la nota de red segura: el firewall bloquea, los query logs registran. Un detalle: solo se registran las consultas únicas (no cacheadas).

Tres fuentes, tres huecos distintos#

La tabla deja claro por qué necesitas las tres —y por qué ninguna sustituye a otra:

Amazon Security Lake y OCSF#

Tienes tres formatos distintos en tres sitios distintos. Correlacionar “este evento de CloudTrail, con este flujo de Flow Logs, con esta consulta DNS” a mano es inviable. Ese es el problema que resuelve Amazon Security Lake:

En resumen#

• CloudTrail registra llamadas a la API: management events por defecto, data events opt-in, de alto volumen y con coste. Úsalo con trail organizacional, validación de integridad y Object Lock.
• VPC Flow Logs capturan metadatos de red (5-tupla, ACCEPT/REJECT), no el payload ni el tráfico a DNS/metadatos.
• DNS query logs registran qué dominios se resolvieron: clave contra C2 y tunelización por DNS. Solo consultas únicas.
• Ninguna fuente lo ve todo: combínalas porque sus huecos son distintos.
• Security Lake centraliza todo en tu S3 y lo normaliza a OCSF/Parquet, para consultas unificadas con Athena, OpenSearch o tu SIEM.

Referencias#

• AWS CloudTrail: management and data events↗
• CloudTrail log file integrity validation↗
• Amazon S3 Object Lock (WORM)↗
• VPC Flow Logs↗
• Route 53 Resolver query logging↗
• Amazon Security Lake↗
• Open Cybersecurity Schema Framework (OCSF)↗