Ya tenemos una organización con muchas cuentas (subcapítulo 30.1), creadas y gobernadas con Control Tower (subcapítulo 30.2). Pero esa estructura multi-cuenta crea un nuevo reto: si tienes la seguridad y los registros (logs) repartidos en decenas de cuentas, ¿cómo los vigilas y gestionas de forma conjunta? Revisar cuenta por cuenta sería imposible. La solución es centralizar la seguridad y los logs: reunir todo en un sitio común para verlo y controlarlo de forma global. En este subcapítulo vemos por qué y cómo.

Recuerda toda la seguridad y observabilidad que vimos (Capítulos 23 y 24): logs de actividad, hallazgos de amenazas, registros de auditoría... Si cada una de tus 50 cuentas genera su propia seguridad y sus propios logs por separado, vigilarlo todo se vuelve inviable:

Necesitas una visión y gestión central de la seguridad y los logs de toda la organización, no fragmentada cuenta por cuenta.

La práctica recomendada es centralizar la seguridad y los logs en cuentas dedicadas. Es muy habitual tener:

• Una cuenta de logs (log archive): donde se reúnen los registros de todas las cuentas, guardados de forma segura.
• Una cuenta de seguridad (security/audit): desde donde el equipo de seguridad vigila y gestiona la seguridad de toda la organización.

Recuerda que Control Tower (subcapítulo 30.2) suele crear estas cuentas especializadas automáticamente como parte de la landing zone.

Analogía: centralizar la seguridad y los logs es como tener una central de seguridad y un archivo central para toda una cadena de tiendas. En lugar de que cada tienda guarde sus propias grabaciones de cámaras y tenga su propio vigilante aislado (sin que nadie vea el conjunto), todas las cámaras envían su señal a una central de seguridad única, y todas las grabaciones se guardan en un archivo central protegido. Así, un equipo central vigila todas las tiendas a la vez, detecta patrones que cruzan varias, y las grabaciones están a salvo aunque alguien manipule una tienda concreta.

Reunir los logs de todas las cuentas en una cuenta de logs dedicada aporta:

Tienes todos los registros en un sitio, lo que permite analizar la actividad de toda la organización de forma conjunta (por ejemplo, con las herramientas de observabilidad del Capítulo 24, o un data lake de logs, recuerda el Capítulo 29).

Si los logs de cada cuenta se guardan fuera de esa cuenta (en la cuenta central de logs, a la que los equipos normales no tienen acceso de borrado), nadie puede manipular o borrar los registros de su propia cuenta para ocultar algo. Esto es clave para la auditoría y la seguridad: los logs son fiables e intactos.

Tener todos los registros centralizados y protegidos facilita enormemente demostrar cumplimiento a auditores y reguladores (enlaza con el Capítulo 23): hay un único lugar, seguro, con todo el rastro.

Gestionar la seguridad desde una cuenta de seguridad central permite:

El equipo de seguridad ve y gestiona la seguridad de todas las cuentas desde un punto. Recuerda Security Hub (subcapítulo 23.4) y GuardDuty (subcapítulo 23.3): se pueden configurar para agregar los hallazgos de toda la organización en la cuenta de seguridad, dando esa visión central que vimos como tan valiosa.

Algunos ataques tocan varias cuentas. Solo viéndolas de forma conjunta (desde la cuenta central) se detectan esos patrones que, cuenta por cuenta, pasarían desapercibidos.

Ante un incidente, el equipo de seguridad central puede coordinar la respuesta a través de las cuentas afectadas, en lugar de actuar a ciegas en cada una.

El modelo que emerge es muy potente: cada equipo opera de forma autónoma en su cuenta (libertad para trabajar), pero la seguridad y los logs se gobiernan de forma central (control y visión global). Lo mejor de ambos mundos: autonomía para los equipos y control para la organización.

Ejemplo del mundo real: una empresa con 40 cuentas centraliza su seguridad y logs. Todos los registros de las 40 cuentas se envían a una cuenta de logs protegida, a la que los equipos de producto no tienen acceso de borrado. Toda la detección de amenazas (GuardDuty, Security Hub) de las 40 cuentas se agrega en la cuenta de seguridad, donde el equipo de seguridad vigila el conjunto. Un día, un atacante compromete las credenciales de un equipo e intenta moverse hacia otras cuentas. Como la seguridad está centralizada, el equipo detecta el patrón (actividad sospechosa cruzando cuentas) que en cuentas aisladas habría pasado inadvertido, y responde de forma coordinada. Además, el atacante no puede borrar los logs de la cuenta que comprometió (están en la cuenta central), así que queda todo el rastro para investigar. La centralización fue decisiva.

• Con muchas cuentas, tener la seguridad y los logs dispersos en cada una hace imposible vigilarlos en conjunto, detectar ataques que cruzan cuentas o demostrar el cumplimiento global.
• La solución es centralizar en cuentas dedicadas: una cuenta de logs (reúne los registros de todas las cuentas) y una cuenta de seguridad (desde donde se vigila toda la organización). Las crea Control Tower (subcap. 30.2). Como una central de seguridad y archivo central para una cadena de tiendas.
• Centralizar logs da: visión completa, protección a prueba de manipulación (nadie borra los logs de su propia cuenta, quedan a salvo como prueba) y cumplimiento más fácil.
• Centralizar seguridad da: vigilancia global (GuardDuty/Security Hub agregados, Cap. 23), detección de amenazas que cruzan cuentas y respuesta coordinada.
• El modelo resultante: gobierno central (seguridad y logs) + operación distribuida (equipos autónomos en sus cuentas) = libertad y control a la vez.

En el último subcapítulo del capítulo veremos cómo gestionar toda esta estructura multi-cuenta con Terraform, es decir, Terraform a escala multi-cuenta.