Los clientes grandes de AWS rara vez ejecutan todo en una sola cuenta. Las cuentas separadas ofrecen límites firmes de seguridad, facturación y cuotas de servicio: un error o una brecha en una cuenta de desarrollo no puede afectar a producción, y el gasto de cada equipo es fácil de ver. AWS Organizations es el servicio que agrupa las cuentas. Una cuenta de administración (management account) crea o invita cuentas miembro, las organiza en unidades organizativas (OUs) como Security, Infrastructure, Production y Sandbox, y paga una sola factura consolidada, que además combina el uso para obtener descuentos por volumen. Las service control policies (SCPs) son políticas de Organizations que se adjuntan a la raíz, a una OU o a una cuenta. Definen los permisos máximos disponibles para los usuarios y roles de IAM en las cuentas miembro afectadas, incluido el usuario raíz de cada cuenta. Las SCPs nunca otorgan permisos; una identidad sigue necesitando una política de IAM que permita la acción. Son barreras de protección (guardrails): denegar que una cuenta abandone la organización, denegar que se desactive CloudTrail o GuardDuty, o denegar cualquier acción fuera de las regiones aprobadas mediante la condición aws:RequestedRegion. Las SCPs adjuntas más arriba en el árbol se heredan, por lo que una acción debe estar permitida en cada nivel, desde la raíz hasta la cuenta. Las SCPs no afectan a la cuenta de administración, que es una de las razones por las que AWS recomienda no ejecutar cargas de trabajo allí, y tampoco restringen los roles vinculados a servicios (service-linked roles). Un tipo de política más reciente y relacionado, las resource control policies (RCPs), establece permisos máximos sobre recursos como buckets de S3 y claves de KMS, lo que ayuda a construir un perímetro de datos que también se aplica a principales fuera de tu organización.
AWS IAM Identity Center (el sucesor de AWS Single Sign-On) es la forma recomendada para que las personas inicien sesión en muchas cuentas. Conectas una fuente de identidad, como el directorio integrado de Identity Center, Active Directory o un proveedor de identidad externo (IdP) como Okta o Microsoft Entra ID, a menudo con aprovisionamiento automático de usuarios mediante el estándar System for Cross-domain Identity Management (SCIM). Luego defines conjuntos de permisos (permission sets). Un permission set es una plantilla de políticas; cuando asignas a un usuario o grupo un permission set en una cuenta, Identity Center crea el rol correspondiente en esa cuenta. Los usuarios inician sesión una sola vez en el portal de acceso, eligen una cuenta y un rol, y reciben credenciales temporales. No hay que crear usuarios de IAM en cada cuenta.
Para cargas de trabajo y automatización, el acceso entre cuentas usa roles de IAM. En la cuenta de destino creas un rol cuya trust policy nombra como principal a la cuenta de origen, o a un rol específico de ella. En la cuenta de origen, la identidad que hace la llamada necesita permiso para sts:AssumeRole sobre el ARN de ese rol. Ambos lados deben estar de acuerdo. Cuando un tercero, como un proveedor de monitoreo, asume un rol en tu cuenta, agregas una condición de ID externo (external ID) a la trust policy para evitar el problema del suplente confundido (confused deputy), en el que se engaña al proveedor para que use su acceso a tu cuenta en nombre de otro cliente.
aws sts assume-role \
--role-arn arn:aws:iam::222233334444:role/AuditReadOnly \
--role-session-name audit-runEn las preguntas aparecen otras herramientas multicuenta. AWS Control Tower configura y gobierna una landing zone: una estructura de OUs recomendada, una cuenta de archivo de registros (log archive), una cuenta de auditoría, CloudTrail centralizado y controles preventivos y de detección construidos con SCPs y reglas de AWS Config. Account Factory, dentro de Control Tower, crea cuentas nuevas que ya cumplen la configuración base. AWS Resource Access Manager (RAM) comparte recursos como subredes de VPC, Transit Gateways o reglas de Route 53 Resolver entre cuentas. El administrador delegado (delegated administrator) permite que una cuenta miembro, normalmente una cuenta de herramientas de seguridad, gestione un servicio como GuardDuty, Security Hub o la agregación de AWS Config para toda la organización, en lugar de la cuenta de administración.
Veamos un ejemplo práctico. Una empresa debe garantizar que nadie en sus cuentas de cargas de trabajo pueda crear recursos fuera de dos regiones aprobadas, y sus auditores deben leer los registros de CloudTrail de todas las cuentas. Usa Control Tower para crear la landing zone, adjunta a la OU Workloads una SCP que deniega todas las acciones cuando aws:RequestedRegion no es una de las dos regiones aprobadas, con excepciones para servicios globales como IAM, y asigna a los auditores un permission set de solo lectura mediante IAM Identity Center. Ni siquiera un administrador de una cuenta miembro puede crear una instancia en una tercera región, y los auditores nunca necesitan usuarios de IAM separados.
Errores comunes: esperar que una SCP otorgue acceso; olvidar que las SCPs no se aplican a la cuenta de administración; crear usuarios de IAM en cada cuenta para las personas en lugar de usar Identity Center; y omitir el external ID en los roles para terceros. Otro es ejecutar cargas de trabajo en la cuenta de administración, donde las barreras de las SCPs no llegan.
Las preguntas del examen suelen describir un objetivo de gobierno. 'Barrera central para todas las cuentas' o 'impedir incluso a los administradores' apunta a una SCP. 'Inicio de sesión único para los empleados en muchas cuentas' apunta a IAM Identity Center. 'Una aplicación en la cuenta A debe actuar en la cuenta B' apunta a un rol entre cuentas con una trust policy, y 'acceso de un proveedor externo' agrega un external ID. 'Configurar rápidamente un entorno multicuenta gobernado' apunta a Control Tower.
Términos clave
- AWS Organizations
- El servicio que agrupa cuentas de AWS para su administración central, políticas y facturación consolidada.
- Unidad organizativa (organizational unit, OU)
- Un contenedor de cuentas dentro de AWS Organizations al que se pueden adjuntar políticas como las SCPs.
- Service control policy (SCP)
- Una política de Organizations que establece los permisos máximos para las identidades de las cuentas miembro; nunca otorga acceso.
- Conjunto de permisos (permission set)
- Una plantilla de políticas de IAM Identity Center que se convierte en un rol en cada cuenta a la que se asigna.
- ID externo (external ID)
- Un valor secreto exigido en la trust policy de un rol entre cuentas para protegerse del problema del suplente confundido (confused deputy).
- AWS Control Tower
- Un servicio que configura y gobierna una landing zone multicuenta con cuentas y controles de base.
Una empresa de pagos adquiere una startup con 12 cuentas de AWS. Las invita a su organización, las coloca en una OU Workloads que hereda SCPs que deniegan cambios en CloudTrail y el uso de regiones no aprobadas, conecta IAM Identity Center a su IdP corporativo para que los ingenieros inicien sesión con sus cuentas existentes y convierte la cuenta de seguridad en administrador delegado de GuardDuty, de modo que los hallazgos de las 12 cuentas llegan a un solo lugar.
Comprueba lo que sabes
Una SCP permite solo acciones de EC2 y S3. Un usuario de una cuenta miembro tiene AdministratorAccess. ¿Puede crear una tabla de DynamoDB?
No. La SCP establece los permisos máximos disponibles, así que las acciones fuera de EC2 y S3 quedan bloqueadas sin importar la política de IAM.
¿Qué dos cosas se requieren para que una identidad de la cuenta A asuma un rol en la cuenta B?
El rol de la cuenta B debe confiar en la cuenta A (o en esa identidad) en su trust policy, y la identidad de la cuenta A debe tener permitido sts:AssumeRole sobre el ARN del rol.
¿Por qué el rol entre cuentas de un proveedor debe incluir una condición de external ID?
Evita el problema del suplente confundido, en el que otro cliente del proveedor podría engañarlo para que use su acceso a tu cuenta.
¿Una SCP restringe las acciones realizadas en la cuenta de administración?
No. Las SCPs no afectan a la cuenta de administración, por eso las cargas de trabajo deben ejecutarse en cuentas miembro.