Módulo 2: Domain 1 Secure Architectures

2. Task 1.1: acceso seguro — IAM, Identity Center y multi-cuenta

Descripción

Task 1.1 —Design secure access to AWS resources— es, según la documentación oficial de AWS, la primera de las tres preguntas que Domain 1 evalúa: quién puede actuar sobre un recurso de AWS, y cómo se lo demuestra. Su lista oficial de conocimiento nombra, entre otras cosas, "access controls and management across multiple accounts", "AWS federated access and identity services (for example, IAM, AWS IAM Identity Center)" y "AWS security best practices (for example, the principle of least privilege)" — y su lista de habilidades pide explícitamente "designing a security strategy for multiple AWS accounts (for example, AWS Control Tower, service control policies [SCPs])". Esta lección cubre la primera mitad de ese task statement: el modelo de IAM de una sola cuenta (relectura), permission boundaries (relectura), IAM Identity Center (nuevo) y el vocabulario de multi-cuenta (relectura-nombrado). La lección 3 cierra la segunda mitad: federación, STS y roles cross-account.

Conexión con el módulo

La lección 1 te mostró el mapa: esta lección toma la columna de Task 1.1 y la desarrolla en profundidad. Vas a reconocer casi todo el vocabulario de IAM de una sola cuenta — lo construiste en aws-core-services-guide M3 y lo endureciste en cloud-security-and-guardrails-guide M2 y M7. Lo nuevo de esta lección es una sola pieza, pero importante: IAM Identity Center, el servicio que el examen espera que sepas cuándo usar en vez de crear un usuario de IAM por cada persona de tu organización.

Analogía: la llave maestra vs. la tarjeta de acceso temporal del edificio

Imagina un edificio corporativo con dos formas de dar acceso a la gente. La primera: cortar una llave física nueva para cada persona que necesita entrar, guardar un registro manual de quién tiene cuál llave, y —si alguien pierde la suya, o deja la empresa— cambiar la cerradura entera para invalidarla. La segunda: un sistema de tarjetas centralizado, conectado al directorio de empleados de la empresa, donde cada tarjeta se emite, se revoca y se audita desde un solo panel, y ningún empleado necesita una llave física propia para entrar a ningún edificio de la organización — solo necesita que el panel central lo autorice.

La primera opción es, con precisión, un usuario de IAM por persona, en cada cuenta de AWS que esa persona necesita tocar — funciona, pero no escala: diez personas en cinco cuentas son potencialmente cincuenta identidades que administrar por separado. La segunda opción es IAM Identity Center: un punto único de identidad —tu propio directorio, o uno federado desde tu proveedor corporativo— que asigna acceso a las cuentas de AWS que una persona necesita, sin que esa persona tenga jamás una credencial de IAM propia en ninguna cuenta individual.

El modelo de IAM de una sola cuenta, releído

Repaso rápido, sin volver a construir nada: en una sola cuenta de AWS, la identidad vive en cuatro piezas. Los usuarios (ana-dev) son identidades de larga duración, para personas. Los grupos (Developers) agrupan usuarios para administrar permisos en bloque, nunca reciben permisos que apliquen a un servicio, solo a las personas que los integran. Los roles (AppServerRole, LambdaManifestProcessorRole) son identidades temporales, asumidas — nunca tienen credenciales de larga duración propias, y siempre tienen una trust policy que dice, con precisión, quién puede asumirlos. Las políticas son el documento JSON que define qué puede hacer una identidad, evaluadas bajo el principio de mínimo privilegio: nunca más permiso del que la tarea exige, el mismo criterio que gobernó cada línea de AndesCargoManifestUploaderPolicy.

La decisión de examen que Task 1.1 prueba con más frecuencia: usuario vs. rol. Un usuario de IAM tiene sentido para una identidad humana de larga duración dentro de una sola cuenta, con MFA activado — la propia lista de habilidades oficial de AWS nombra "applying AWS security best practices to IAM users and root users (for example, multi-factor authentication [MFA])" como una habilidad explícita del examen. Un rol tiene sentido en cualquier otro caso: un servicio de AWS que necesita actuar (AppServerRole, con trust a ec2.amazonaws.com), una persona que necesita acceso temporal a otra cuenta, o una identidad externa federada. El error más común en un examen real es elegir "crear un usuario de IAM" para un caso donde un rol asumido temporalmente resuelve el mismo problema con una superficie de ataque mucho menor —una credencial de rol expira sola; una credencial de usuario de larga duración, filtrada, es un riesgo permanente hasta que alguien la rota a mano—.

Políticas basadas en identidad vs. políticas basadas en recurso

Esta es una distinción que el examen prueba con precisión, y que ya usaste sin nombrarla explícitamente: en el Módulo 4 de aws-core-services-guide, andes-cargo-shipment-docs recibió una bucket policy —una política basada en recurso— que vive pegada al propio bucket, no a ningún usuario ni rol. La diferencia con una política basada en identidad (como AndesCargoManifestUploaderPolicy, adjunta a ana-dev) no es solo dónde vive el documento — es qué necesita decir explícitamente:

	Política basada en identidad	Política basada en recurso
Dónde vive	Adjunta a un usuario, grupo o rol	Adjunta al propio recurso (bucket S3, cola SQS, tema SNS, cuenta de KMS)
Campo `Principal`	No lo necesita — ya está "adjunta" a alguien	Obligatorio — debe decir explícitamente quién puede actuar
Puede otorgar acceso cross-account	No, por sí sola	Sí — es el mecanismo que permite que un principal de otra cuenta acceda sin asumir un rol
Ejemplo real de Andes Cargo	`AndesCargoManifestUploaderPolicy` en `ana-dev`	La bucket policy de `andes-cargo-shipment-docs` que deniega tráfico sin HTTPS

La decisión de examen: cuando un escenario pide acceso cross-account sin que la cuenta que recibe el acceso tenga que asumir un rol explícito —por ejemplo, una cola SQS que otra cuenta necesita poder escribir directamente—, la respuesta casi siempre es una política de recurso con un Principal que nombra la cuenta externa, no un rol nuevo. Cuando el escenario pide que una identidad de una cuenta actúe como una identidad temporal dentro de otra cuenta, la respuesta es un rol cross-account (lección 3).

Permission boundaries: el techo que nunca otorga, solo limita

cloud-security-and-guardrails-guide M7 construyó, en HCL real, un permission boundary para AppServerRole. La documentación oficial de AWS lo define con precisión: "a permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity's permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries". Dos palabras hacen todo el trabajo ahí: "allowed by both" — un permission boundary nunca otorga permiso por sí solo, es una intersección. Si la política de permisos de un rol dice "puede hacer X" y el boundary no incluye X, el resultado es que el rol no puede hacer X, sin importar cuán generosa sea la política de permisos.

   PERMISSION BOUNDARY — LA INTERSECCIÓN, NO LA SUMA

   Política de permisos de AppServerRole:  { s3:GetObject, s3:PutObject, s3:DeleteObject }
   Permission boundary adjunto:            { s3:GetObject, s3:PutObject }
                                                        │
                                                        ▼
   Permisos EFECTIVOS de AppServerRole:    { s3:GetObject, s3:PutObject }
                                            (s3:DeleteObject queda fuera — no está en el boundary,
                                             sin importar que la política de permisos sí lo incluya)

La decisión de examen: un permission boundary es la herramienta correcta cuando necesitas delegar la creación de roles o usuarios a alguien más, sin arriesgarte a que esa persona se otorgue a sí misma (o a lo que cree) más permiso del que deberías permitir — la propia documentación de AWS usa exactamente ese escenario de delegación como su ejemplo canónico. No es la herramienta correcta para el caso simple de "quiero que este rol tenga exactamente estos permisos y nada más" — eso ya lo resuelve, sin ninguna pieza adicional, una política de permisos bien escrita bajo mínimo privilegio.

IAM Identity Center: la pieza nueva de esta lección

Qué es, con la fuente oficial: "AWS IAM Identity Center is the AWS solution for connecting your workforce users to AWS managed applications (...) and other AWS resources. You can connect your existing identity provider and synchronize users and groups from your directory, or create and manage your users directly in IAM Identity Center." Fue renombrado el 26 de julio de 2022 — su nombre anterior, que todavía vas a encontrar en comandos de CLI y ARNs por compatibilidad, era AWS Single Sign-On (AWS SSO). El examen usa el nombre nuevo; si ves "SSO" en una pregunta, es el mismo servicio.

El problema que resuelve, con precisión: sin Identity Center, dar acceso a diez personas sobre cinco cuentas de AWS significa, en el peor caso, cincuenta identidades de IAM administradas por separado — cada una con su propio ciclo de vida, su propia rotación de credenciales, su propio riesgo si alguien deja la empresa y una cuenta queda con una credencial huérfana. Con Identity Center, cada persona tiene una sola identidad, y un administrador le asigna permission sets —el equivalente de Identity Center a una política de permisos, pero aplicable a varias cuentas a la vez— sobre las cuentas específicas que necesita. Es, con exactitud, la solución al problema que el propio AndesCargoManifestUploaderPolicy nunca tuvo que resolver, porque Andes Cargo, en el ecosistema, siempre fue una sola cuenta (000000000000).

Requisito de arquitectura: Identity Center gestiona identidad de la fuerza de trabajo a través de cuentas cuando esas cuentas viven dentro de una AWS Organizations — su forma recomendada, la "organization instance", es la única que habilita el uso a través de múltiples cuentas de AWS. Sobre una sola cuenta aislada, sin Organizations, Identity Center sigue funcionando (una "account instance"), pero pierde la razón principal de existir: centralizar acceso a varias cuentas.

La decisión de examen: cuando un escenario describe una organización con múltiples cuentas de AWS y personas humanas que necesitan acceso a varias de ellas, la respuesta correcta casi siempre es IAM Identity Center con permission sets — no "crear un usuario de IAM en cada cuenta", ni "crear un rol cross-account por cada persona" (eso funciona, pero no escala ni se audita tan bien como un punto único de identidad).

Multi-cuenta: AWS Organizations, Control Tower y SCPs, con precisión de vocabulario

cloud-security-and-guardrails-guide M7.6 nombró este terreno sin construirlo — Andes Cargo, tal como existe en el ecosistema, es una sola cuenta, así que una jerarquía de cuentas habría sido alcance inventado. El examen sí lo prueba, así que esta lección fija el vocabulario exacto:

AWS Organizations es la estructura raíz: una cuenta de administración (management account) que agrupa cuentas miembro en unidades organizativas (organizational units, OUs) — piensa en carpetas dentro de carpetas, con cuentas individuales como los archivos.
Service Control Policies (SCPs) son, conceptualmente, el mismo mecanismo que un permission boundary —un techo, nunca un otorgamiento— pero aplicado a una cuenta completa, o a una OU entera, en vez de a un solo rol. Una SCP que deniega ec2:RunInstances fuera de us-east-1 aplica a todos los usuarios y roles de esa cuenta, sin excepción, incluido el usuario raíz.
AWS Control Tower es la capa de automatización sobre Organizations: aprovisiona una landing zone con SCPs preventivos y guardrails detectivos ya configurados según las mejores prácticas de AWS, en vez de que un equipo escriba esas SCPs desde cero.

La decisión de examen: cuando un escenario describe una regla que debe aplicar sin excepción, a toda una cuenta o a un grupo de cuentas —"ninguna cuenta de la OU Sandbox puede lanzar instancias fuera de us-east-1", por ejemplo—, la herramienta es una SCP, no un permission boundary (que solo limita un rol o usuario específico) ni una política de IAM (que un administrador de la cuenta miembro podría, en teoría, cambiar).

Errores comunes

Confundir un permission boundary con una política de permisos (de terminología). Qué pasa: alguien describe un permission boundary como "el conjunto de permisos que tiene un rol". Cómo detectarlo: si tu explicación de un boundary no incluye la palabra "intersección" o "techo". Cómo corregirlo: un boundary nunca otorga nada por sí solo — es el límite máximo que una política de permisos, adjunta por separado, puede conceder. Sin una política de permisos que también lo permita, el boundary solo permitiendo una acción no le da a nadie esa acción.

Elegir crear usuarios de IAM en cada cuenta cuando el escenario describe multi-cuenta con personas humanas (de default a lo conocido). Qué pasa: alguien que dominó IAM de una sola cuenta con Andes Cargo aplica el mismo patrón —usuario + grupo + política— a un escenario con cinco cuentas de AWS. Cómo detectarlo: si tu solución para "dar acceso a un equipo de diez personas sobre cinco cuentas" no menciona Identity Center. Cómo corregirlo: multi-cuenta con identidades humanas es, casi siempre, la señal de que el examen quiere IAM Identity Center con permission sets — no cincuenta usuarios de IAM administrados a mano.

❓ Pregunta de práctica — Dominio 1 (Secure)

Escenario: Andes Cargo va a separar su infraestructura en tres cuentas de AWS —andes-cargo-prod, andes-cargo-staging y andes-cargo-sandbox— dentro de una AWS Organizations recién creada. El equipo tiene ocho ingenieros que necesitan acceso a distintas combinaciones de esas cuentas (algunos solo a sandbox, el equipo de plataforma a las tres), y la dueña de Andes Cargo quiere un único lugar donde dar de baja el acceso completo de un ingeniero el día que deje el equipo, sin tener que recordar en cuántas cuentas tenía credenciales.

Pregunta: ¿Cuál es la forma más adecuada de diseñar el acceso humano a las tres cuentas?

A. Crear un usuario de IAM para cada ingeniero en cada cuenta que necesite tocar, con una política de mínimo privilegio por cuenta. B. Habilitar AWS IAM Identity Center sobre la Organizations, con una identidad por ingeniero y permission sets asignados por cuenta según lo que cada uno necesita. C. Crear un rol cross-account en cada cuenta con una trust policy que confíe en la cuenta andes-cargo-prod, y que cada ingeniero asuma el rol correspondiente manualmente. D. Compartir un único usuario de IAM con acceso administrativo completo en las tres cuentas, y dar la contraseña solo a los ingenieros que la necesiten.

✅ Respuesta correcta: B

Por qué es correcta: IAM Identity Center, con una organization instance sobre AWS Organizations, resuelve exactamente los dos requisitos del escenario: una identidad por persona (no una por cuenta), y permission sets que definen, de forma centralizada, qué puede hacer cada persona en cada cuenta. Dar de baja a un ingeniero es una sola acción —deshabilitar su identidad en Identity Center— en vez de recordar y revocar credenciales en tres cuentas distintas.

Por qué las demás fallan:

A: funciona técnicamente, pero multiplica el trabajo de administración por el número de cuentas y de personas —hasta 24 identidades separadas para ocho ingenieros en tres cuentas—, y dar de baja a alguien exige encontrar y eliminar cada una por separado, exactamente el problema que el escenario pide resolver.
C: los roles cross-account son la herramienta correcta para acceso de servicio a servicio o cuando una identidad ya autenticada en una cuenta necesita actuar en otra (lección 3) — pero seguirían exigiendo que cada ingeniero tenga primero una identidad de IAM de origen en alguna cuenta, sin resolver el problema de "una identidad, múltiples cuentas" de raíz.
D: viola directamente el principio de mínimo privilegio y elimina cualquier posibilidad de auditoría individual —CloudTrail registraría todas las acciones bajo el mismo usuario compartido, sin poder distinguir quién hizo qué—, además de que revocar el acceso de un solo ingeniero exigiría cambiar la contraseña para todo el equipo.

Recursos

AWS Docs — What is IAM Identity Center? — fuente oficial del servicio, incluido el detalle de su renombre desde AWS SSO (26 de julio de 2022).
AWS Docs — Permissions boundaries for IAM entities — la fuente oficial de la lógica de intersección, con el ejemplo completo de delegación que usa esta lección.
AWS Docs — Policies and permissions in IAM — la distinción completa entre políticas basadas en identidad y basadas en recurso.
AWS Docs — Service control policies (SCPs) — el mecanismo de techo a nivel de cuenta u OU.

← Anterior1. Introducción: por qué Secure pesa más que ningún otro dominio Siguiente →3. Task 1.1 cont.: federación, STS y roles cross-account