Hay arquitecturas que “pasan” revisiones porque tienen IAM con MFA, redes segmentadas, cifrado y un SIEM conectado. Y aun así, el día que algo ocurre, el equipo se queda sin respuesta a las preguntas básicas: ¿quién hizo qué?, ¿desde dónde?, ¿qué cambió exactamente?, ¿qué tokens se usaron?, ¿qué recursos se tocaron?
El patrón se repite: la seguridad parecía sólida en el diseño, pero al revisar los logs se descubre que el logging es parcial, que CloudTrail/Activity Logs estaban mal configurados, o que la retención y la integridad no permiten confiar en la evidencia. Lo peor no es “no ver”; lo peor es creer que estás viendo.
Qué salió mal: la seguridad estaba en el diagrama, no en la evidencia
En incidentes reales, el primer choque suele ser operativo: el equipo intenta reconstruir una línea temporal y descubre huecos. Por ejemplo, hay registros de acceso a una aplicación, pero no hay trazabilidad del plano de control (quién creó una llave, quién modificó una política, quién deshabilitó un control). El resultado es que el análisis se apoya en hipótesis y no en hechos, y eso alarga la contención.
La causa rara vez es “no hay logging”. Casi siempre hay logging incompleto: CloudTrail habilitado en una sola cuenta pero no a nivel de organización, Activity Logs sin exportación a un workspace central, o logs de recursos críticos (KMS, S3, Key Vault, IAM) sin los eventos que realmente explican un cambio. En empresas esto se traduce en decisiones caras: rotación masiva de credenciales por falta de certeza, paradas preventivas o restricciones excesivas que impactan negocio.
Otro fallo típico es la confianza ciega en que “el SIEM ya lo recoge todo”. Si el pipeline de ingesta falla o filtra, el SIEM puede mostrar una imagen limpia mientras el origen está incompleto. Ese desfase es el caldo de cultivo para una falsa sensación de control: se reporta cumplimiento, pero no se puede responder a un incidente con precisión.
Causas habituales: CloudTrail y Activity Logs configurados “a medias”
CloudTrail suele estar “activado”, pero sin los detalles que importan cuando hay abuso de credenciales o cambios en permisos. El ejemplo clásico: no registrar Data events en S3 o Lambda por coste/volumen sin un análisis de riesgo, y luego no poder demostrar qué objetos se leyeron o exfiltraron. Otro: no habilitar eventos de management en todas las regiones, y descubrir tarde que el atacante operó en una región “olvidada”.
En Azure, el equivalente frecuente es quedarse en el Activity Log “por defecto” sin exportarlo a Log Analytics/Storage/Event Hub con retención adecuada. Cuando hay que investigar una elevación de privilegios o una modificación de policy, el equipo encuentra que la retención era corta o que la exportación no incluía categorías relevantes (por ejemplo, cambios en recursos, RBAC, Key Vault). El incidente no es más grave por falta de control; es más grave porque no puedes probar el alcance.
También hay un componente organizativo: cada equipo habilita logs a su manera. El resultado es una arquitectura con islas: algunos proyectos mandan a un bucket central, otros a un workspace local, otros no exportan nada. En una crisis, coordinar búsquedas en tres sistemas y con formatos distintos es tiempo perdido que se paga con exposición.
- Multi-cuenta/multi-suscripción sin logging unificado
Cuando no hay una estrategia a nivel de organización (AWS Organizations / Management Group), es común que nuevas cuentas/suscripciones nazcan sin el “baseline” de logs. En auditorías se revisa la cuenta principal; en incidentes, el atacante se mueve donde nadie mira.
- Retención insuficiente para investigar
Muchas investigaciones corporativas no empiezan el mismo día del evento: se detectan por indicadores tardíos (fraude, facturación anómala, hallazgos de terceros). Si la retención de logs es de días o pocas semanas, pierdes la ventana para atribuir acciones y delimitar impacto, y terminas aplicando medidas globales “por si acaso”.
Señales tempranas: cuando el logging te miente sin que lo notes
Una señal práctica es la asimetría entre lo que el equipo espera ver y lo que realmente aparece. Por ejemplo: se detecta una IAM policy modificada, pero no hay evento de quién la cambió; o se ve un recurso creado, pero no hay rastro de la sesión/role que lo ejecutó. Ese tipo de huecos suele apuntar a logging deshabilitado en ciertas regiones, cuentas, o a una exportación incompleta.
Otra señal: métricas de volumen de logs “demasiado estables”. En entornos con cambios reales, el plano de control genera variabilidad. Si CloudTrail o Activity Logs se mantienen planos durante semanas mientras hay despliegues, cambios y rotaciones, lo razonable es sospechar que no se está recogiendo todo o que el pipeline está filtrando de más.
En empresa, estas señales se suelen descubrir por accidente: durante un incidente, al preparar evidencias para auditoría, o cuando un analista intenta correlacionar eventos y no encuentra nada. El coste es doble: se compromete la respuesta y además se erosiona la confianza en los controles, lo que suele derivar en “microcontroles” manuales y fricción entre equipos.
- Alertas que no disparan nunca
Si tienes reglas para cambios en Security Groups, creación de access keys, desactivación de MFA o modificaciones de roles, y nunca disparan pese a que esos cambios ocurren, probablemente no es que “todo esté perfecto”: es que el origen no está llegando o llega incompleto.
- Investigaciones que dependen de logs de aplicación
Cuando el equipo se ve obligado a reconstruir acciones del plano de control a partir de logs de aplicación (o de CI/CD), normalmente es porque faltan los logs nativos del proveedor cloud o no están centralizados. Es una dependencia frágil: los logs de aplicación no sustituyen evidencia de IAM, KMS o políticas.
Cómo hacerlo en la práctica: validar que los logs existen, cubren y son confiables
La validación efectiva no es “CloudTrail está ON”. Es comprobar cobertura, centralización, retención e integridad con pruebas controladas. En AWS, una práctica realista es ejecutar una batería de acciones esperables (crear un role, adjuntar una policy, modificar un Security Group, leer un objeto S3 en un bucket sensible) y verificar que cada acción genera el evento correspondiente en el repositorio central, con el actor correcto y el contexto suficiente (sourceIPAddress, userAgent, ARN, requestParameters).
Acciones concretas que suelen dar resultados inmediatos en entornos corporativos: crear un trail a nivel de organización, forzar que sea multi-región, y enviar a un bucket central con políticas de escritura estrictas. Si se decide registrar Data events, hacerlo al menos para “crown jewels” (buckets con datos sensibles, funciones críticas). En Azure, el equivalente operativo es configurar Diagnostic settings para exportar Activity Logs y logs de recursos a un destino central con retención alineada a necesidades de investigación.
Un punto crítico: la confiabilidad. Si un atacante con permisos puede borrar o alterar logs, tu “evidencia” deja de ser evidencia. Por eso, además de recolectar, hay que proteger el almacenamiento y el acceso, y probarlo: intentar borrar objetos de logs con un rol operativo normal y confirmar que falla; validar que los equipos de plataforma no tienen permisos de modificación sobre el repositorio de auditoría salvo un break-glass controlado.
Ejemplo (AWS S3) de política para evitar borrado/alteración de logs en el bucket destino (adaptar a tu caso, aquí el foco es negar borrado y cambios):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyDeleteOnAuditLogs",
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:DeleteObject","s3:DeleteObjectVersion"],
"Resource": "arn:aws:s3:::mi-bucket-auditoria/*"
},
{
"Sid": "DenyBucketPolicyChanges",
"Effect": "Deny",
"Principal": "*",
"Action": ["s3:PutBucketPolicy","s3:DeleteBucketPolicy"],
"Resource": "arn:aws:s3:::mi-bucket-auditoria"
}
]
}
Validación en AWS (operativa, no teórica): en CloudTrail Lake o en el bucket central, busca eventos como AttachRolePolicy, PutRolePolicy, CreateAccessKey, UpdateAssumeRolePolicy, AuthorizeSecurityGroupIngress y confirma que aparecen para tus pruebas. En Azure, valida en Log Analytics que las tablas esperadas reciben eventos tras cambios reales (RBAC, deployments, Key Vault operations) y que el timestamp y el actor coinciden.
Recomendaciones para entornos corporativos
Si una arquitectura “parece segura” pero no permite reconstruir eventos con precisión, en la práctica no lo es: la seguridad sin evidencia operativa se vuelve irrelevante cuando hay que tomar decisiones bajo presión. Los fallos más dañinos no suelen ser la ausencia total de logs, sino la cobertura parcial, la centralización incompleta y la retención insuficiente, que alimentan una falsa sensación de control.
Para evitarlo, el criterio debe ser verificable: ejecutar acciones controladas y confirmar que quedan registradas en un repositorio central, con retención adecuada y con protecciones que impidan borrado o manipulación. Si al revisar CloudTrail/Activity Logs aparecen huecos, no es un detalle: es un riesgo directo para la capacidad de respuesta, para el cumplimiento y para el coste operativo durante un incidente.
¿Te interesa la seguridad en Cloud?
Comparto análisis técnicos, laboratorios prácticos y experiencias reales sobre Cloud Security.