Cuentas múltiples y organización

El historial de eventos de una cuenta muestra solo esa cuenta: iniciar sesión en la de gestión no enseña lo que pasó en las cuentas miembro. Para tenerlo todo en un sitio se crea una trail de organización, que registra la cuenta de gestión y todas las cuentas miembro, y que éstas no pueden borrar ni apagar.

Por defecto, solo la cuenta de gestión accede al bucket donde la trail entrega sus archivos, así que ese bucket es la primera pieza que hay que proteger y copiar.

Cuando un rol se asume desde otra cuenta, el evento AssumeRole queda en la cuenta que lo recibe y anota quién lo pidió: la cuenta de origen aparece en el evento. Es el hilo que permite saltar de una cuenta a otra.

En la tabla hay dos asunciones de ese rol: una desde la cuenta de seguridad y otra desde una cuenta de otra unidad.

Los identificadores de cuenta no dicen nada a quien los lee: se traducen con el inventario de la organización, que también dice en qué unidad vive cada cuenta y qué servicios de seguridad tiene activos. Ese cruce es el que convierte un dato suelto en una pregunta para alguien concreto.

El administrador delegado de GuardDuty ve los hallazgos de las cuentas miembro que lo tienen habilitado. Una cuenta sin detector es un punto ciego: lo que ocurra en ella no genera hallazgos y hay que reconstruirlo solo desde la bitácora.

Cuenta cuántas cuentas de la organización aparecen sin GuardDuty habilitado.

Una política de control de servicios (SCP) fija el máximo de permisos posibles para los usuarios y roles de las cuentas miembro. No concede nada, solo limita, y no afecta a los usuarios ni a los roles de la cuenta de gestión.

Una política así puede impedir, por ejemplo, que alguien desactive una bitácora; pero no sustituye a los permisos de IAM ni cubre la cuenta de gestión.