El problema no es la sofisticación del atacante
Cuando un incidente en AWS se investiga con retraso, la conversación suele girar en torno a la complejidad del ataque. En muchos casos, la limitación real es otra: no hay suficiente telemetría para reconstruir lo ocurrido.
CloudTrail, VPC Flow Logs y los data events no son perfectos. No revelan intención ni capturan payloads. Su valor está en preservar piezas independientes de evidencia que, juntas, permiten responder preguntas básicas: qué identidad actuó, cuándo, desde dónde, sobre qué recurso y con qué resultado.
Cómo desaparece el rastro
En entornos multi-cuenta, el volumen de eventos crece con rapidez. Alguien mira la factura de almacenamiento, indexación o SIEM y aparece la pregunta inevitable: ¿hace falta tanto logging?
Las optimizaciones suelen llegar por partes:
- se descartan eventos de lectura por “ruido”
- los Flow Logs quedan limitados a producción o solo a tráfico rechazado
- se desactivan data events de S3 por volumen
- la retención se reduce a 30 o 90 días
Cada decisión puede parecer razonable. En conjunto, pueden eliminar el contexto necesario para entender un compromiso.
La fase de reconocimiento también es actividad
Tras obtener credenciales válidas, un atacante no empieza necesariamente borrando datos. Pregunta. Enumera. Mapea.
En lenguaje de API de AWS, eso se traduce en operaciones legítimas de tipo Get*, List* y Describe*. Para un equipo de producto pueden parecer ruido. Para un atacante son cartografía.
Si la telemetría de lectura desaparece del pipeline de seguridad, es posible que aún se vea una acción posterior (por ejemplo, un cambio de política). Lo que se pierde es el inicio de la historia: los minutos de enumeración previos.
El patrón inverso también existe: conservar lecturas y filtrar escrituras. Entonces se observa la exploración… y el momento en que cambian roles, trust policies o security groups queda incompleto.
Lectura y escritura describen fases distintas. Elegir solo una no es “optimizar visibilidad”; es aceptar una ceguera asimétrica.
Qué debe preservar una arquitectura de logging útil
Una postura sensata no consiste en registrarlo todo sin criterio. Consiste en definir señales mínimas que se puedan pagar y que sirvan en forense y detección:
- CloudTrail de management events con retención alineada al riesgo
- cobertura de cuentas y regiones relevantes, no solo del entorno “principal”
- Flow Logs donde aporten contexto de red
- data events selectivos sobre recursos de alto valor
- un camino claro desde el almacenamiento de logs hasta quien investiga
El objetivo no es un museo de eventos. Es poder responder, con evidencia, a preguntas de negocio y de seguridad cuando llegue el momento.
Relación con el trabajo de TechRebel
En engagements de AWS Security y observabilidad partimos de esta premisa: la visibilidad es una decisión de arquitectura, no un complemento opcional. Evaluamos qué se registra, qué se retiene y qué se puede reconstruir antes de hablar de controles adicionales.
Si quiere revisar la postura de logging y detección en su organización AWS, puede agendar una reunión o consultar AWS & Cloud Security.