Una empresa tiene una estructura de AWS Organizations con cuentas separadas para cada unidad de negocio. Todos los registros de AWS CloudTrail se centralizan en un bucket de Amazon S3 en la cuenta de nivel superior, al que el equipo de gobernanza de TI puede acceder. Un ingeniero de seguridad creó un rol de IAM en la cuenta de nivel superior para cada cuenta de unidad de negocio, otorgando acceso de solo lectura a los objetos del bucket con el prefijo de registro de esa unidad. ¿Qué se debe hacer en cada cuenta de unidad de negocio para permitir que un usuario de IAM de allí lea sus registros de CloudTrail?

La respuesta correcta es adjuntar una política al usuario de IAM que le permita asumir el rol creado en la cuenta de nivel superior, especificando el ARN del rol. Para que un usuario de IAM de una cuenta de unidad de negocio acceda a recursos en otra cuenta (la cuenta de nivel superior en este caso), el usuario debe tener permiso para asumir un rol preconfigurado en la cuenta de destino. La política de confianza del rol en la cuenta de nivel superior debe permitir que la cuenta de la unidad de negocio asuma ese rol, y la política de permisos del rol debe otorgar acceso de solo lectura al bucket de S3. Crear una SCP no es la solución, ya que las SCP se utilizan para establecer límites de permisos máximos para las cuentas, no para otorgar permisos entre cuentas. Usar el usuario root no es una práctica recomendada de seguridad y no es necesario para esta tarea. Compartir credenciales es una práctica insegura y no es el mecanismo adecuado para el acceso entre cuentas en AWS.