Módulo 7: Detective Vs Preventive Guardrails
6. SCPs y multi-cuenta, nombrados
Descripción
Esta lección nombra, sin construir, el escalón que sigue naturalmente después de todo lo que este módulo construyó: Service Control Policies aplicadas de verdad a una jerarquía de cuentas, orquestadas por AWS Organizations y, opcionalmente, AWS Control Tower. No es una omisión escondida — es, con precisión, un faltante documentado de nivel ecosistema, no solo de esta guía, y esta lección explica exactamente por qué Andes Cargo, tal como existe hoy, no lo necesita todavía.
Conexión con el módulo
La lección 2 de este módulo ya adelantó la mitad del vocabulario: una SCP es, conceptualmente, el mismo mecanismo que un permission boundary (un techo, nunca un otorgamiento) aplicado a una escala distinta — una cuenta completa, o varias, en vez de un solo rol. Esta lección retoma esa comparación y la extiende a la pregunta que realmente importa para Andes Cargo: ¿cuándo, si alguna vez, tendría sentido construir esto de verdad?
Por qué esto es un faltante de ecosistema, citado con su propia fuente
src/paths/aws-cloud-ecosystem/VALIDACION.md — la misma auditoría de mercado que fijó el peso relativo de cada módulo de esta guía desde el Módulo 1 — lo dice sin rodeos: "AWS multi-cuenta a fondo (Organizations, Control Tower, Landing Zone construidos de punta a punta) es un faltante ALTA de VALIDACION.md sin guía asignada en el ecosistema todavía". Esta guía nombra el patrón —porque es el guardrail preventivo natural que sigue a IAM de una sola cuenta, el mismo tema central de todo este módulo— pero no lo construye, por dos razones independientes, no una sola:
- LocalStack Hobby/Community no sostiene Organizations ni Control Tower de forma completa. Ninguno de los dos aparece confirmado en la cobertura del plan gratuito que usa todo este ecosistema, la misma razón exacta que ya explicó la lección 4 de este módulo para GuardDuty y Config.
- Andes Cargo, tal como está definida en las cuatro guías de este ecosistema, es una sola cuenta AWS (
000000000000). Construir una jerarquía de cuentas para un caso que no la necesita significaría inventar alcance que el caso de estudio nunca tuvo — exactamente el tipo de sobre-ingeniería que esta guía evita en cada uno de sus módulos anteriores.
AWS Organizations: la estructura que hace posible una SCP
Una SCP no existe en el vacío — necesita, como precondición, una organización. La documentación oficial de AWS Organizations lo resume así: "AWS Organizations helps you centrally manage and govern your environment as you grow and scale your AWS resources. Using Organizations, you can create accounts and allocate resources, group accounts to organize your workflows, apply policies for governance, and simplify billing by using a single payment method for all of your accounts".
ESTRUCTURA MÍNIMA QUE HARÍA POSIBLE UNA SCP (que Andes Cargo NO tiene hoy)
┌───────────────────────────┐
│ Management Account │
│ (la cuenta que crea la │
│ organización) │
└─────────────┬─────────────┘
│
┌───────────────────┼───────────────────┐
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ OU: Prod │ │ OU: Staging │ │ OU: Sandbox │
│ (SCP aquí: │ │ (SCP aquí: │ │ (SCP aquí: │
│ deny region │ │ allow todo │ │ deny costos │
│ fuera de │ │ dentro de │ │ fuera de un │
│ us-east-1) │ │ staging) │ │ presupuesto) │
└────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘
│ │ │
▼ ▼ ▼
cuenta de producción cuenta de staging cuenta de pruebas
de Andes Cargo de Andes Cargo de un desarrollador
Andes Cargo, HOY: una sola cuenta (000000000000), sin Management Account,
sin organización, sin OUs — ninguna SCP tiene dónde adjuntarse todavía.Cada rama de este diagrama —Prod, Staging, Sandbox— podría tener una SCP distinta, aplicada por AWS Organizations a todos los usuarios y roles de esa rama a la vez, sin que nadie tenga que replicar la misma regla cuenta por cuenta. Es exactamente el mismo principio de escala que ya viste en conftest (una regla, evaluada contra cualquier plan) y en Trivy/Checkov (una base de reglas, aplicada a cualquier proyecto) — solo que aplicado a cuentas completas en vez de a código.
AWS Control Tower: la capa de orquestación, no un mecanismo nuevo
Vale la pena una precisión que evita un error común: Control Tower no es un mecanismo de política distinto de una SCP — es una capa de orquestación sobre Organizations. La documentación oficial lo confirma: "AWS Control Tower orchestrates the capabilities of several other AWS services, including AWS Organizations, AWS Service Catalog, and AWS IAM Identity Center, to build a landing zone in less than an hour", y añade una definición precisa de lo que llama "controls": "A control (sometimes called a guardrail) is a high-level rule that provides ongoing governance for your overall AWS environment [...] Three kinds of controls exist: preventive, detective, and proactive".
Fíjate en algo que conecta directamente con la lección 1 de este módulo: la propia documentación de AWS usa, textualmente, el vocabulario preventivo/detectivo que gobierna esta guía entera — y agrega una tercera categoría, proactivo, que vale la pena nombrar aunque esta guía no la desarrolle: un control proactivo de Control Tower evalúa un recurso antes de que se cree, de forma similar a como conftest evalúa un plan (Módulo 4), pero integrado directamente en el flujo de aprovisionamiento de cuentas de Control Tower, no como un paso separado de CI/CD.
| AWS Organizations | Service Control Policies (SCP) | AWS Control Tower | |
|---|---|---|---|
| Qué es | El servicio que agrupa cuentas y permite políticas centralizadas | El mecanismo de política — un techo aplicado a una cuenta, OU, o toda la organización | Una capa de orquestación sobre Organizations — automatiza la creación de cuentas con SCPs y otros controles ya aplicados |
| Relación entre los tres | Precondición de los otros dos | Vive dentro de Organizations | Usa Organizations y SCPs por debajo, sin ser un mecanismo nuevo |
| En esta guía | Nombrado | Nombrado (introducido en la lección 2, retomado aquí) | Nombrado |
Cuándo Andes Cargo lo necesitaría, y dónde viviría
Este es el criterio concreto, no una respuesta genérica de "cuando crezca": Andes Cargo tendría una razón real de construir esto el día que dejara de ser una sola cuenta con un solo entorno. Los escenarios de mercado más comunes que justifican dar ese paso —ninguno presente hoy en el caso de estudio de este ecosistema— son:
- Separar entornos por cuenta, no por tag o prefijo. Hoy, Andes Cargo no distingue producción de staging con ninguna cuenta separada — todo vive en
000000000000. Si esa separación llegara a existir, una SCP en la OU de "Sandbox" podría, por ejemplo, denegar cualquieriam:CreateUserfuera de un rol de solo lectura, sin depender de que cada desarrollador recuerde no crear usuarios en un entorno de pruebas. - Aislar radio de explosión entre equipos o clientes. Si Andes Cargo alguna vez operara infraestructura para múltiples clientes de logística (multi-tenant a nivel de cuenta, no solo a nivel de aplicación), una cuenta por cliente, gobernada por SCPs comunes, limitaría que un incidente en la infraestructura de un cliente pudiera, siquiera en teoría, tocar los recursos de otro.
- Cumplir un requisito regulatorio de segregación. Algunos estándares de cumplimiento (no citados aquí porque no aplican al caso de estudio de esta guía) exigen, explícitamente, cuentas AWS separadas para ciertos tipos de datos — un requisito que ninguna política dentro de una sola cuenta, por bien diseñada que esté, puede satisfacer por sí sola.
Cuando cualquiera de estos escenarios aplicara, el mecanismo que resolvería el problema es exactamente el de esta lección: una organización con all features enabled, estructurada en OUs por entorno o por cliente, con SCPs adjuntas a cada OU — nunca sustituyendo los permission boundaries de la lección 3 (que siguen siendo necesarios dentro de cada cuenta), sino sumándose como una capa adicional, por encima de ellos.
Errores comunes
Pensar que una SCP reemplaza a los permission boundaries de la lección 3, en vez de sumarse a ellos (de jerarquía equivocada). Qué pasa: alguien, después de esta lección, asume que si Andes Cargo alguna vez construyera SCPs, el boundary de AppServerRole (lección 3) dejaría de ser necesario. Cómo detectarlo: si tu plan de migración hacia multi-cuenta incluye "eliminar los permission boundaries existentes". Cómo corregirlo: la propia documentación de AWS ya lo confirmó en la lección 2 de este módulo: "If both a permissions boundary [...] and an SCP are present, then the boundary, the SCP, and the identity-based policy must all allow the action" — son capas independientes que se intersectan, no una sustituyendo a la otra. Una SCP protege a nivel de cuenta; un boundary protege a nivel de rol individual dentro de esa cuenta; ambos siguen siendo necesarios a la vez.
Confundir "Control Tower" con "un tercer tipo de política", en vez de una capa de orquestación (de vocabulario). Qué pasa: alguien, leyendo sobre los tres tipos de "controls" de Control Tower (preventivo, detectivo, proactivo), asume que Control Tower introduce un mecanismo de aplicación técnicamente nuevo, distinto de las SCPs. Cómo detectarlo: si tu explicación de Control Tower no menciona, en ningún momento, que se apoya en Organizations por debajo. Cómo corregirlo: Control Tower automatiza la aplicación de controles que, en su mayoría, siguen siendo SCPs (para los preventivos) u otros mecanismos ya existentes de AWS (Config para los detectivos) — su valor no es un mecanismo nuevo, es la orquestación de crear una cuenta nueva con esos controles ya aplicados desde el primer minuto, en vez de configurarlos manualmente cada vez.
Concluir que "esta guía no cubre multi-cuenta" significa que nadie en el ecosistema lo cubre (de alcance del ecosistema). Qué pasa: alguien, después de leer que esto es un faltante de VALIDACION.md, asume que ninguna guía futura de este ecosistema jamás lo construirá. Cómo detectarlo: si tu conclusión es "multi-cuenta simplemente no es parte de este ecosistema". Cómo corregirlo: VALIDACION.md lo documenta explícitamente como faltante ALTA sin guía asignada todavía — una decisión de diseño abierta, no una omisión permanente. Es exactamente el mismo tipo de honestidad que esta guía practica en su propia frontera (ver el Módulo 1, lección 1): nombrar lo que falta, con precisión, en vez de fingir que el alcance actual ya cubre todo lo que un lector podría necesitar.
Ejercicios
Ejercicio 1 — Decide si cada escenario justifica multi-cuenta, usando el criterio de esta lección. Para cada uno, decide si es una razón real para que Andes Cargo construyera Organizations/SCPs, o si el problema se resuelve mejor con lo que esta guía ya construyó (M2-M7, una sola cuenta): (a) Andes Cargo quiere que el equipo de desarrollo no pueda tocar la tabla Shipments de producción; (b) Andes Cargo empieza a operar infraestructura separada para un segundo cliente de logística, con sus propios datos; (c) Andes Cargo quiere que ningún rol tenga permisos más amplios de los que su código realmente usa.
Ver solución
(a) No es, por sí sola, una razón para multi-cuenta. El Módulo 4 de esta guía (no-destroy-shipments.rego) ya resuelve exactamente este problema dentro de una sola cuenta, evaluando el plan antes del apply — no hace falta una cuenta separada para bloquear un cambio destructivo específico. (b) Sí es una razón real, y de las más comunes en la práctica: separar clientes con sus propios datos es exactamente el escenario de "aislar radio de explosión entre clientes" que esta lección nombró — una cuenta por cliente, gobernada por SCPs comunes, es el patrón de mercado estándar para este caso. (c) No es una razón para multi-cuenta. Es, literalmente, el problema que el Módulo 2 (recorte de roles a mínimo privilegio) y la lección 3 de este módulo (permission boundaries) ya resuelven dentro de una sola cuenta — mínimo privilegio es un problema de diseño de políticas IAM, no de arquitectura de cuentas.
Ejercicio 2 — Explica la relación entre los tres conceptos de esta lección sin usar ningún diagrama. En dos o tres frases, sin dibujar nada, explica la relación de dependencia entre AWS Organizations, las SCPs, y AWS Control Tower.
Ver solución
Una explicación completa suena, más o menos, así: "AWS Organizations es la base — sin una organización con todas las features activas, ninguna SCP tiene dónde adjuntarse. Las SCPs son el mecanismo de política que vive dentro de esa organización: techos aplicados a cuentas individuales o a grupos de cuentas (OUs). AWS Control Tower no es un tercer mecanismo independiente — es una capa de automatización que usa Organizations y SCPs (junto con otros servicios como Config) por debajo, para que crear una cuenta nueva, ya gobernada por esos controles, tome minutos en vez de configurarse manualmente cada vez."
Ejercicio 3 — Defiende, frente a un entrevistador técnico, por qué esta guía no construye multi-cuenta, sin sonar como si estuvieras evitando el tema. Un entrevistador te pregunta: "¿por qué tu proyecto de portfolio no incluye Organizations ni SCPs, si claramente sabes que existen?". Responde usando el criterio de esta lección.
Ver solución
Una respuesta sólida distingue conocimiento de alcance aplicado: "Conozco el mecanismo —Organizations como precondición, SCPs como el techo de política a nivel de cuenta, Control Tower como la capa de orquestación sobre ambos— y sé exactamente cuándo se justifica: cuando un caso de negocio necesita separar entornos o clientes por cuenta completa, no solo por rol o por tag. El proyecto de este portfolio es una sola cuenta, con un solo cliente y un solo entorno operativo, así que construir multi-cuenta ahí habría sido inventar complejidad que el caso no pedía — la misma disciplina de alcance que apliqué en cada módulo anterior de este proyecto, donde cada control se construyó porque un riesgo concreto lo justificaba, documentado en un THREAT-MODEL.md real, no porque la herramienta existiera." Esta respuesta demuestra criterio de ingeniería, no una laguna de conocimiento.
Resumen y siguiente paso
En esta lección nombraste, sin construir, AWS Organizations (la estructura que agrupa cuentas), las Service Control Policies (el mecanismo de techo aplicado a esa estructura, primo de escala mayor del permission boundary de la lección 3) y AWS Control Tower (la capa de orquestación sobre ambos, con su propio vocabulario oficial de controles preventivos/detectivos/proactivos). Confirmaste, con la fuente exacta de VALIDACION.md, por qué esto es un faltante de nivel ecosistema y no una omisión de esta guía, y con qué criterio concreto —separación de entornos, aislamiento entre clientes, requisitos regulatorios— sabrías cuándo Andes Cargo, o cualquier proyecto real, debería dar este paso.
Antes de avanzar deberías poder: explicar la relación de dependencia entre Organizations, SCPs y Control Tower sin ningún diagrama; distinguir, con un ejemplo concreto, cuándo un problema se resuelve dentro de una sola cuenta (como ya hizo esta guía) y cuándo necesita multi-cuenta; y defender, frente a una pregunta directa, por qué esta guía no construye lo que nombra aquí.
La lección 7 vuelve a terreno completamente ejecutable: una alarma real, con terraform validate/plan, sobre un evento sensible de IAM — el último recurso nuevo de este módulo antes del proyecto que lo cierra.
Recursos
- AWS Docs — What is AWS Organizations? — la fuente oficial completa citada en esta lección.
- AWS Docs — Service control policies (SCPs) — ya citada en la lección 2 de este módulo, retomada aquí para la interacción SCP + permission boundary.
- AWS Docs — What Is AWS Control Tower? — la fuente oficial completa citada en esta lección, incluida la definición de "controls" preventivo/detectivo/proactivo.
src/paths/aws-cloud-ecosystem/VALIDACION.md— la fuente exacta del faltanteALTAsin guía asignada, citada al inicio de esta lección.- Este curso, Módulo 7, lección 2 — el permission boundary de
AppServerRole, la capa que una SCP complementaría, nunca reemplazaría.