Auditoría en toda la organización: un trail organizativo de CloudTrail centrado en la seguridad para 53 cuentas de AWS

Resumen

Construimos las bases de auditoría y gobernanza para una AWS Organization de 53 cuentas sin adoptar Control Tower. Cada llamada a la API, en cada cuenta y región, acaba ahora en un único bucket cifrado e inmutable al que ninguna cuenta de carga de trabajo tiene acceso, y las llamadas importantes llegan a Mattermost en cuestión de minutos.

La clave no está en qué servicios usamos, sino en dónde vive cada cosa. Los logs se escriben en una cuenta, se almacenan en otra y se leen desde una tercera, de modo que comprometer una sola cuenta no basta para reescribir la historia ni para silenciar la alarma.

• Cobertura: un único trail organizativo multirregión para las 53 cuentas, cifrado con una clave KMS gestionada por el cliente.
• Integridad: S3 Object Lock, primero en modo governance durante 30 días y después en modo compliance con una retención de 365 días.
• Acceso: un estado de Terraform por cuenta, aplicado con sesiones de corta duración de IAM Identity Center. Sin usuarios IAM ni claves de larga duración.
• Detección: una Lambda en la cuenta de seguridad convierte una selección de eventos en alertas de Mattermost, con una mediana de unos 3 minutos desde la llamada a la API hasta la alerta y un p95 de unos 6.
• Hallazgos hasta ahora: tres hallazgos reales en las diez primeras semanas. Ninguno era malicioso, y cada uno cambió un proceso.

El reto

La organización había crecido hasta 51 cuentas sin una respuesta común a una pregunta sencilla: ¿quién hizo qué, dónde y cuándo?

• No había un registro de auditoría central. Cada cuenta tenía la configuración de CloudTrail con la que había nacido, si es que tenía alguna. Investigar algo implicaba entrar en las cuentas una a una con la esperanza de que el evento siguiera en el Event history de 90 días.
• No había dónde alojar las herramientas de seguridad. No existía una cuenta de seguridad ni una de archivo de logs. Cualquier cosa que construyéramos habría acabado en la cuenta de gestión, que debe estar lo más vacía posible, o en una cuenta de carga de trabajo, que es precisamente lo que tiene que vigilar.
• Los logs eran tan modificables como los sistemas que describían. Cualquiera con permisos de administrador en una cuenta podía detener el registro o borrar las pruebas. Es justo lo primero que suele hacer un atacante que consigue esos permisos.
• Nadie se enteraba. Incluso donde los eventos quedaban registrados, nadie los leía hasta que algo ya había ido mal.

Este proyecto añadió dos cuentas, seguridad y archivo de logs, con lo que la organización pasó a tener 53: la cuenta de gestión, las dos nuevas y 50 cuentas de carga de trabajo para producción, staging y desarrollo.

Restricciones, y por qué no Control Tower

Control Tower es la respuesta por defecto a este problema, y decidimos no usarlo. Es una landing zone: crea sus propias cuentas de archivo de logs y de auditoría, su propio trail y un conjunto de guardrails, y a partir de ahí espera ser su propietario. Inscribir 50 cuentas de carga de trabajo existentes supone aceptar esas configuraciones base cuenta por cuenta, y aceptar un servicio que reconcilia recursos que, de otro modo, gestionaríamos con Terraform.

Necesitábamos algo más acotado: unas bases de auditoría que entendiéramos por completo, construidas con el mismo Terraform que usamos en todo lo demás y que pudiéramos explicar línea a línea en una revisión. Hacerlo a mano costó más esfuerzo al principio y nos dio exactamente eso.

Las restricciones que nos impusimos:

1. Todo en Terraform. Nada de configuración hecha solo desde la consola, para que todo el diseño se pueda revisar y reproducir.
2. Sin credenciales de larga duración. Personas y pipelines se autentican a través de IAM Identity Center. Sin usuarios IAM ni claves de acceso en disco.
3. La cuenta de gestión se mantiene ligera. Contiene la organización, Identity Center y la definición del trail, y nada que procese o almacene logs.
4. Ninguna cuenta puede reescribir la historia por sí sola. Escribir, almacenar y leer los logs ocurre en cuentas distintas, con personas distintas.
5. Aditivo y reversible hasta que esté probado. Nada irreversible, como la retención en modo compliance, se activa hasta haberlo visto funcionar.

Hubo una restricción más, derivada de dónde operamos. Nuestras cargas de trabajo se ejecutan en Fráncfort (eu-central-1), y el bucket del trail y su clave también están allí. El trail registra todas las regiones, pero los datos de auditoría nunca salen de la UE.

Arquitectura

El diseño sigue una única regla: los logs se escriben en una cuenta, se almacenan en otra y se leen desde una tercera. CloudTrail escribe desde la cuenta de gestión, la cuenta de archivo de logs solo almacena, y la cuenta de seguridad solo lee y alerta.

El recorrido en morado es la vida de un archivo de log: una llamada a la API en cualquier punto de la organización, entregada por el trail organizativo, cifrada con la clave KMS de la cuenta de archivo, bloqueada en el bucket, y después leída por la cuenta de seguridad y convertida en una alerta.

Dos cuentas nuevas, dos funciones distintas

Creamos desde cero una cuenta de archivo de logs y una de seguridad en lugar de reaprovechar alguna existente. Una cuenta existente arrastra historia: usuarios, roles y relaciones de confianza que nadie recuerda del todo. Una cuenta nueva empieza vacía, así que cada permiso que contiene es uno que hemos dejado por escrito.

La separación existe para que el alcance de cualquier compromiso aislado sea pequeño y evidente:

• Cuenta de carga de trabajo comprometida: no puede detener el trail organizativo, porque las cuentas miembro pueden verlo pero no modificarlo. Tampoco puede llegar al bucket, que está en otra cuenta.
• Cuenta de seguridad comprometida: puede leer logs y silenciar alertas, pero no puede alterar ni borrar lo que ya se ha escrito.
• Cuenta de archivo de logs comprometida: Object Lock en modo compliance hace que ni siquiera su usuario root pueda borrar una versión bloqueada antes de que termine la retención.

Dos administradores con nombre y apellidos pueden acceder a la cuenta de gestión, ambos a través de Identity Center. Su usuario root está protegido por un procedimiento de emergencia (break-glass) documentado: MFA por hardware, credenciales en un almacén aparte y un runbook que indica quién puede abrirlo y qué hay que registrar después. Las cuentas miembro no tienen credenciales root en absoluto; la sección de resultados explica por qué.

Un trail para cada cuenta y cada región

Un único trail organizativo sustituyó a la configuración cuenta por cuenta. Los trails organizativos registran los eventos de la cuenta de gestión y de todas las cuentas miembro, y las cuentas nuevas quedan cubiertas en el momento en que se unen. Las cuentas miembro pueden ver el trail, pero no modificarlo ni borrarlo.

Es multirregión a propósito. Un trail de una sola región solo registra las regiones que usamos, y a los atacantes les gustan las que no usamos: una flota de minería de criptomonedas en una región que nadie mira es un clásico. También se capturan los eventos de servicios globales, como IAM e Identity Center.

Cifrado con una clave KMS gestionada por el cliente. El cifrado SSE-S3 por defecto protege el disco; una clave gestionada por el cliente protege los datos frente a las personas. Leer un log requiere ahora dos permisos distintos, s3:GetObject en el bucket y kms:Decrypt en la clave, y cada descifrado queda registrado a su vez. La clave vive en la cuenta de archivo de logs, junto al bucket. Su política:

• permite a CloudTrail generar claves de datos solo cuando la petición procede de nuestro trail, comprobado con la condición aws:SourceArn y el contexto de cifrado de CloudTrail;
• concede kms:Decrypt a un único rol de lectura en la cuenta de seguridad, y a nadie más;
• deja la administración de la clave en manos del rol de despliegue de Terraform de la cuenta de archivo de logs.

La validación de integridad de los archivos de log está activada. CloudTrail escribe cada hora archivos de resumen (digest) firmados, así que podemos demostrar que un archivo de log no ha cambiado desde su entrega, con independencia de Object Lock.

El trail registra todos los eventos de gestión, tanto de lectura como de escritura. La primera copia de los eventos de gestión es gratuita, y las llamadas de lectura como ListBuckets o GetSecretValue suelen ser la primera señal de que alguien está husmeando. Los eventos de datos están desactivados por ahora. Los eventos de datos de S3 en los buckets con datos de clientes son el siguiente paso, una vez que hayamos calculado su coste por cada 100.000 eventos.

Terraform: un estado por cuenta, sin secretos compartidos

Cada cuenta es su propio módulo raíz de Terraform con su propio estado. El estado se guarda en un bucket S3 versionado dentro de la cuenta que describe, con el bloqueo nativo de estado en S3 (use_lockfile), así que tampoco hay una tabla de bloqueo compartida. Un plan en la cuenta de seguridad no puede ver, bloquear ni corromper el estado de la cuenta de archivo de logs, y un error en un stack tiene un alcance de una sola cuenta.

Solo sesiones de corta duración

Cada apply se ejecuta sobre una sesión de IAM Identity Center: aws sso login y después un perfil con nombre por cuenta en el bloque del provider. Las sesiones caducan en horas, no en años. No hay ningún usuario IAM del que olvidarse ni ninguna clave en una variable de CI, y dar de baja a alguien es un único cambio en Identity Center. Un portátil extraviado contiene, como mucho, una sesión a punto de caducar.

Valores pasados explícitamente, no leídos de otros estados

Los stacks dependen unos de otros. El trail necesita el nombre del bucket y el ARN de la clave de la cuenta de archivo; la política de la clave necesita el ARN del trail; el stack de alertas necesita ambos. El atajo habitual es una fuente de datos terraform_remote_state que lee el estado de otra cuenta.

No lo tomamos. Leer un archivo de estado significa leer el archivo entero, no un solo output: todos los atributos de todos los recursos, incluido cualquier dato sensible. Dar a la cuenta de seguridad acceso de lectura al estado de la cuenta de archivo habría reconstruido sin hacer ruido la confianza entre cuentas que acabábamos de separar.

En su lugar, cada stack expone unos pocos outputs, y el stack que los consume los recibe como variables de entrada tipadas en un archivo .tfvars versionado en el repositorio:

Dos valores resuelven lo que parece el problema del huevo y la gallina. El ARN del trail se deduce del ID de la cuenta, la región y el nombre del trail, así que la política de la clave puede referenciarlo antes de que el trail exista. El rol de lectura es más complicado, porque KMS y S3 rechazan políticas que mencionan un principal que todavía no existe. Por eso las políticas confían en la cuenta de seguridad y fijan el rol con una condición aws:PrincipalArn. Así el orden de aplicación va en una sola dirección: archivo de logs, después gestión y después seguridad.

El precio es copiar a mano cada vez que cambia un output, lo que con estos valores no ocurre casi nunca. Las reglas de validación de variables detectan un valor pegado con un formato incorrecto antes de que llegue a un plan.

Object Lock: primero governance, compliance una vez probado

La última línea de defensa es que los logs no se puedan borrar de ningún modo. S3 Object Lock lo ofrece en dos modos, y la diferencia está en si alguien puede deshacerlo:

• Modo governance: un principal con s3:BypassGovernanceRetention puede acortar la retención o borrar una versión bloqueada enviando explícitamente la cabecera de bypass.
• Modo compliance: nadie puede acortar la retención ni borrar una versión bloqueada antes de que caduque. Ni un administrador, ni el usuario root.

El objetivo es el modo compliance, y también es una puerta de un solo sentido. Si configuras un periodo de retención equivocado, o bloqueas objetos que una regla de ciclo de vida debía limpiar, pagas ese almacenamiento durante todo el periodo sin vuelta atrás. Así que empezamos en modo governance y lo tratamos como un ensayo. Durante ese periodo comprobamos que:

1. Los logs de las 53 cuentas y de todas las regiones habilitadas llegaban bajo el prefijo de la organización.
2. La validación de los digest funcionaba de extremo a extremo.
3. Las reglas de ciclo de vida (transición a almacenamiento más frío y expiración tras la retención) se comportaban correctamente con versiones bloqueadas.
4. El rol de lectura de seguridad podía descifrar y leer, y nada más podía hacerlo.
5. El coste de almacenamiento previsto con la retención completa era asumible.
6. El periodo de retención estaba acordado con quien se responsabiliza del cumplimiento normativo, y no lo había elegido el ingeniero de turno.

Después cambiamos el modo por defecto del bucket a compliance. Aquí importa un detalle: cambiar el modo por defecto solo afecta a los objetos escritos a partir de ese momento. Las versiones escritas durante la fase de governance mantienen la retención governance hasta que caducan, salvo que se vuelvan a marcar, por ejemplo con S3 Batch Operations.

La retención es de 365 días. Una regla de ciclo de vida mueve los archivos de log a S3 Glacier Instant Retrieval a los 90 días y los hace caducar cuando termina la retención. La fase de governance duró 30 días. Dejamos que esos objetos caducaran solos en lugar de volver a marcarlos: iban a expirar en menos de un año de todos modos, y un trabajo de Batch Operations habría costado más que el riesgo que eliminaba.

De la llamada a la API a Mattermost

Unos logs que nadie lee son un archivo, no un control. Una función Lambda en la cuenta de seguridad lee cada nuevo archivo de log, compara los eventos con una lista corta y seleccionada, y publica las coincidencias en un canal de Mattermost que el equipo ya vigila.

El flujo: CloudTrail entrega un archivo de log al bucket, el bucket envía una notificación de objeto creado a una cola SQS en la cuenta de seguridad, y la Lambda lee el archivo con el rol de lectura de seguridad, descifrándolo gracias al permiso de KMS descrito antes. SQS nos da reintentos y una cola de mensajes fallidos (dead-letter queue) sin código adicional. La URL del webhook de Mattermost se guarda en Secrets Manager, no en una variable de entorno, y se cachea durante la vida de cada contenedor de Lambda.

Nuestro servidor de Mattermost solo acepta tráfico de IP permitidas, así que la Lambda se ejecuta en una VPC y sale a través de un NAT gateway con una Elastic IP fija que está en la lista de permitidas.

Sobre qué alertamos

Cada alerta tiene que ser algo sobre lo que una persona actuaría. La lista es corta a propósito:

Dos reglas cambiaron tras la primera semana, que generó unas 40 alertas. Los inicios de sesión fallidos aislados eran casi siempre contraseñas mal escritas, así que esa regla ahora solo salta con cinco o más fallos de un mismo usuario en diez minutos. Las llamadas AttachRolePolicy hechas por los roles de despliegue de Terraform se suprimen, porque cada una ya ha pasado por una merge request revisada. Tras el ajuste, el canal recibe entre cuatro y seis alertas a la semana.

¿Cuánto tarda una alerta?

El límite inferior lo marca el propio CloudTrail. AWS indica que CloudTrail suele entregar los logs en una media de unos 5 minutos desde la llamada a la API. La notificación, la cola y la Lambda añaden segundos.

Medimos 58 alertas durante 30 días, desde el eventTime del evento hasta la marca de tiempo de la publicación en Mattermost. La mediana fue de 3 minutos y 10 segundos, el p95 de 6 minutos y 5 segundos, y la más lenta tardó 11 minutos. La Lambda supone entre 2 y 4 segundos; el resto es la entrega de CloudTrail.

Minutos es lo adecuado para un control de auditoría. No lo es para detener un ataque en curso. De eso trata el compromiso sobre EventBridge que explicamos más abajo.

Decisiones clave y compromisos

Quién administra el trail

Los trails organizativos se pueden crear en la cuenta de gestión o, desde finales de 2022, mediante un administrador delegado de CloudTrail, una cuenta miembro como la de seguridad. En ambos casos, la cuenta de gestión sigue siendo la propietaria del trail.

Mantuvimos el trail en la cuenta de gestión. Delegarlo en la cuenta de seguridad habría reducido los inicios de sesión en la cuenta de gestión, pero también habría dado a seguridad el poder de modificar o borrar el trail. Eso rompe la regla sobre la que se apoya todo el diseño: seguridad lee, nunca escribe.

En cualquier caso, la cuenta de gestión sigue pudiendo borrar el trail. Ese riesgo se cubre en dos capas: borrarlo dispara una alerta, y nada de lo que ya se ha escrito se puede eliminar.

Disparador de alertas: notificaciones de S3 frente a EventBridge frente a CloudWatch Logs

• Notificaciones de S3 sobre el archivo (nuestra elección): un único punto de integración para todas las cuentas y regiones, que lee exactamente lo que contiene el archivo. La latencia es el tiempo de entrega de CloudTrail, es decir, minutos.
• EventBridge: casi en tiempo real, pero los eventos de CloudTrail llegan a EventBridge en la cuenta y la región donde se producen. Cubrir toda la organización implica reglas en cada cuenta y cada región que reenvíen a un bus central. Es mucha más fontanería a cambio de alertas más rápidas.
• CloudWatch Logs: los filtros de métricas son cómodos, pero el grupo de logs del trail organizativo está del lado de la cuenta de gestión, lo que habría llevado el procesamiento a la cuenta que queríamos mantener ligera.

Elegimos cobertura y simplicidad antes que segundos. Una vía rápida para un puñado de eventos críticos está en la lista de más abajo.

Detectivo, todavía no preventivo

Empezamos solo con detección. Una SCP que deniegue directamente StopLogging, DeleteTrail y LeaveOrganization sería preventiva, pero una SCP equivocada puede romper producción en todas las cuentas a la vez, y queríamos ver tráfico real primero.

Seis semanas después de la puesta en marcha, el historial de alertas no mostraba ningún uso legítimo de esas llamadas. Entonces vinculamos a todas las cuentas miembro una SCP que deniega StopLogging, DeleteTrail, UpdateTrail, PutEventSelectors y LeaveOrganization. Las SCP no se aplican a la cuenta de gestión, así que allí el control sigue siendo la alerta.

El periodo en modo governance

Empezar en modo governance dejó una ventana en la que un principal con el permiso de bypass podía borrar logs. Lo aceptamos, limitamos ese permiso a un único rol de Terraform y configuramos una alerta ante cualquier bypass. La alternativa era un error que no podríamos deshacer durante todo el periodo de retención.

Una lista seleccionada, no un producto de detección

La Lambda aplica nuestra propia política: por ejemplo, cualquier CreateAccessKey es un hallazgo porque no tenemos usuarios IAM. No es detección de anomalías. Un servicio gestionado como GuardDuty cubre otro terreno y la complementa, no la sustituye.

Qué falló

Durante el despliegue fallaron tres cosas, y cada una cambió el diseño.

• El trail no entregó nada durante la primera hora, y en la consola todo parecía correcto. La política de la clave KMS fijaba aws:SourceArn a un ARN de trail construido con el ID de la cuenta de archivo de logs. El ARN de un trail organizativo lleva el ID de la cuenta de gestión, así que CloudTrail no podía generar claves de datos. Solo aws cloudtrail get-trail-status lo mostraba, en LatestDeliveryError. Corregimos el ARN y añadimos esa comprobación al runbook de despliegue.
• La política del bucket rechazaba los logs de las cuentas miembro. La política permitía escrituras bajo AWSLogs/<management-account-id>/, que solo cubre los eventos propios de la cuenta de gestión. Los trails organizativos escriben los logs de las cuentas miembro bajo AWSLogs/<org-id>/. Añadir la ruta de la organización lo solucionó, y lo detectamos durante el ensayo en modo governance.
• Una caída de Mattermost supuso recibir cada alerta dos veces. Un archivo de log contiene muchos eventos, así que cuando una publicación fallaba, SQS volvía a entregar el archivo entero y las alertas que ya se habían enviado se publicaban de nuevo. Ahora la Lambda registra cada eventID publicado en una pequeña tabla de DynamoDB con un TTL de 24 horas y se salta los repetidos.

Resultados

La organización tiene ahora un único lugar donde responder «quién hizo qué, dónde y cuándo», y sirve para todas las cuentas, incluidas las que todavía no existen.

Los siete usuarios IAM salieron del inventario que hicimos durante el despliegue. La mayoría eran antiguos usuarios de CI y de copias de seguridad; cada uno se sustituyó por un perfil de Identity Center o por un rol IAM.

El inicio de sesión root de un sábado. Tres semanas después de la puesta en marcha, la regla de actividad root saltó en una cuenta de staging un sábado por la mañana. Era un compañero actualizando un contacto de facturación con unas credenciales root guardadas años atrás en un gestor de contraseñas compartido. Nada malicioso, pero demostró que cualquiera con acceso a ese almacén podía seguir usando las credenciales root de las cuentas miembro. Activamos la gestión centralizada del acceso root en AWS Organizations, eliminamos las credenciales root de las 52 cuentas miembro y pusimos el root de la cuenta de gestión tras el procedimiento de emergencia.

Los otros dos hallazgos fueron menores. Un desarrollador había creado una clave de acceso para un script local; se sustituyó por un perfil de Identity Center ese mismo día. Y un permission set de administrador se había asignado al grupo equivocado en Identity Center, cosa que detectamos y corregimos en minutos.

Qué haría de otra manera

• Alertar del silencio, no solo de los eventos. Si el trail deja de entregar, la Lambda de alertas simplemente no tiene nada que decir. Un heartbeat que salte cuando no haya llegado ningún archivo de log en 15 minutos habría detectado nuestro fallo de KMS de la primera hora sin que nadie tuviera que mirar.
• Añadir una vía rápida para los pocos eventos que no pueden esperar. Reglas de EventBridge solo para la manipulación del trail y los inicios de sesión root, junto a la vía de S3, los pasarían de minutos a segundos sin rehacer el flujo.
• Pasar antes de lo detectivo a lo preventivo. La SCP se activó a las seis semanas. Con dos habría bastado: las llamadas que bloquea nunca tuvieron un uso legítimo.
• Hacer que el archivo se pueda consultar desde el primer día. Athena sobre el bucket, o CloudTrail Lake, convierte el «tenemos los logs» en «podemos responder a la pregunta en un minuto» durante una investigación.
• Enviar las alertas de costes al mismo canal. Las alertas de presupuesto como un suscriptor más pondrían el gasto en la misma imagen operativa que la seguridad.

Fuentes

• Creating a trail for an organization
• CloudTrail organization delegated administrator
• Working with CloudTrail log files (delivery time)