Guía práctica de Organizations, SCP y gobernanza multi-cuenta para SCS-C03
_Category: Governance_
Cuando un entorno cloud madura, los límites de operar con una única cuenta AWS empiezan a crujir. Equipos de desarrollo, operaciones y seguridad compartiendo el mismo espacio generan fronteras de permisos difusas, y un error en un entorno puede propagarse y afectar a toda la organización. La estrategia multi-cuenta no es opcional: en operaciones cloud de nivel empresarial es el punto de partida. En esta guía repasamos la arquitectura completa de la gobernanza multi-cuenta con AWS Organizations, SCP, Control Tower y Resource Access Manager, siempre desde una perspectiva práctica.
---
Por qué multi-cuenta: la cuenta AWS como frontera de aislamiento
Una cuenta AWS es mucho más que una unidad de facturación. Es una frontera de aislamiento robusta donde las políticas IAM, los grupos de seguridad, las VPC y las cuotas de servicio operan de forma completamente independiente. Los recursos de cuentas distintas no pueden comunicarse sin políticas de acceso cruzado explícitas.
Hay cuatro razones de peso para adoptar una estrategia multi-cuenta. La primera es el aislamiento de seguridad: si una cuenta se ve comprometida, el impacto no se extiende a las demás. La segunda es la delimitación del cumplimiento normativo, permitiendo aislar cargas de trabajo PCI-DSS en cuentas dedicadas. La tercera es la visibilidad de costos, atribuyendo el gasto a cada equipo o proyecto con claridad. La cuarta es la separación de cuotas de servicio, de modo que si un equipo agota un límite, los demás no se ven afectados. La complejidad de gestión que implica el modelo multi-cuenta se resuelve precisamente con AWS Organizations y Control Tower.
---
AWS Organizations y patrones de diseño de OU
AWS Organizations es el servicio que agrupa múltiples cuentas AWS bajo una sola organización y permite gestionarlas de forma centralizada. Dentro de la organización, las cuentas se clasifican en una estructura de árbol usando OU (Organizational Unit). Puedes visualizarlo como el organigrama de una empresa: la sede central (raíz) tiene divisiones (OU) y debajo de cada división hay cuentas por equipo.
El patrón de diseño de OU más recomendado en entornos empresariales es el siguiente:
| OU | Cuentas incluidas | Propósito | |---|---|---| | Security OU | Log Archive, Security Tooling | Centralización de logs, herramientas de seguridad (administrador delegado de Security Hub, etc.) | | Infrastructure OU | Shared Services, Network | VPC compartida, Transit Gateway, DNS | | Sandbox OU | Cuentas de experimentación para desarrolladores | Entorno de pruebas con políticas más relajadas | | Workloads OU | Dev, Staging, Prod | Cargas de trabajo reales de los servicios | | Suspended OU | Cuentas inactivas | Aislamiento previo al cierre |
La cuenta Log Archive es una cuenta dedicada que centraliza los logs de CloudTrail y Config de todas las cuentas, aislada para que ninguna otra cuenta pueda borrar o alterar esos registros. La cuenta Security Tooling actúa como administrador delegado de Security Hub y GuardDuty, centralizando las alertas de seguridad de toda la organización.
---
El significado exacto de SCP: límite máximo, no permiso
SCP (Service Control Policy) es el concepto que más confusiones genera dentro de Organizations. Es fundamental tenerlo claro: SCP no otorga permisos. SCP define el límite máximo de permisos que pueden existir en una cuenta u OU. Funciona como el código de conducta corporativo: solo dentro de lo que ese código permite puede actuar cada persona (política IAM).
Entender con precisión la diferencia entre SCP y política IAM es clave para el examen.
| Aspecto | SCP | Política IAM | |---|---|---| | Ámbito de aplicación | Toda la cuenta u OU (incluida la raíz) | Usuario, rol o grupo individual | | ¿Puede otorgar permisos? | No (solo define el límite) | Sí, otorga permisos directamente | | ¿Puede desactivarla el admin de la cuenta? | No | Sí | | Cobertura | Todas las entidades IAM dentro de la cuenta miembro | Solo la entidad vinculada | | Aplicación a la cuenta de administración | No se aplica | Sí se aplica |
La evaluación de SCP sigue el orden de herencia: raíz → OU superior → OU inferior → cuenta. Para que una acción sea permitida, todos los SCP de cada nivel y la política IAM deben permitirla. Si cualquier nivel incluye un Deny explícito, la acción queda bloqueada.
Los tres patrones de SCP más habituales en la práctica son: restricción de región (condición aws:RequestedRegion), protección de la cuenta raíz y prevención de desactivación de servicios de seguridad. Al restringir regiones, los servicios globales como IAM, CloudFront, Route 53 o STS deben quedar exentos usando NotAction.
---
Control Tower y Landing Zone: automatización de la gobernanza
Control Tower es como el manual de apertura de una nueva sucursal. Para equipos que construyen su entorno multi-cuenta por primera vez, automatiza la configuración de una estructura de referencia basada en buenas prácticas (Landing Zone). Elimina la repetición de crear OU manualmente, asociar SCP y aprovisionar cuentas una a una.
Los componentes clave que Control Tower configura automáticamente en la Landing Zone son los siguientes:
| Componente | Descripción | |---|---| | Root OU | Nivel superior de la organización, donde reside la cuenta de administración | | Security OU | Crea automáticamente la cuenta Log Archive y la cuenta Audit | | Sandbox OU | Aislamiento de cuentas de experimentación | | Guardrails (Controls) | Aplicación automática de reglas de gobernanza preventivas y de detección | | Account Factory | Aprovisionamiento automatizado de nuevas cuentas con configuración estándar | | Dashboard | Vista centralizada del estado de cumplimiento de todas las cuentas |
Existen dos tipos de Guardrail. Los Guardrails preventivos se implementan mediante SCP y bloquean directamente la creación de recursos que incumplan las reglas. Los Guardrails de detección se implementan mediante reglas de AWS Config, detectan estados de incumplimiento y envían notificaciones.
Account Factory opera sobre Service Catalog. Cuando llega una solicitud de nueva cuenta, aplica automáticamente una plantilla predefinida (configuración de VPC, roles IAM, etiquetas, conexión de logs, etc.) para generar una cuenta estándar. Con Account Factory for Terraform (AFT), el ciclo de vida completo de cuentas puede gestionarse como código con Terraform.
Otros tipos de políticas de Organizations que conviene conocer: Tag Policy fuerza estándares de etiquetado a nivel organizacional. AI Services Opt-out Policy impide que servicios como Amazon Rekognition o Comprehend usen datos de los usuarios para entrenar modelos, aplicándolo de forma masiva. Backup Policy impone planes de AWS Backup desde el centro.
---
Servicios de seguridad a escala organizacional: Security Hub, GuardDuty, Config y Macie
En un entorno multi-cuenta, activar los servicios de seguridad cuenta por cuenta genera una carga de gestión insostenible. AWS ofrece integración con Organizations en cada servicio de seguridad para activarlo automáticamente en todas las cuentas con una sola configuración y gestionarlo de forma centralizada desde una única cuenta. Esa cuenta central es el Delegated Administrator.
El orden correcto para activar los servicios de seguridad a escala organizacional es importante. Primero debe activarse AWS Config, ya que Security Hub solo funciona si Config está previamente habilitado: los estándares de seguridad de Security Hub (CIS, AWS Foundational) utilizan directamente los resultados de evaluación de las reglas de Config. A continuación se configura GuardDuty con activación automática para toda la organización, y al habilitar Security Hub, los hallazgos de GuardDuty se agregan automáticamente sin necesidad de EventBridge. Macie sigue el mismo patrón y se activa de forma masiva desde la cuenta del administrador delegado.
La cuenta Delegated Administrator es la cuenta Security Tooling. Delegar la operación de seguridad en una cuenta especializada, en lugar de gestionarla desde la cuenta de administración, minimiza la exposición de permisos de esa cuenta privilegiada.
Resumen de integración organizacional por servicio de seguridad:
| Servicio | Delegated Administrator | Activación automática | Agregación centralizada | |---|---|---|---| | Security Hub | Sí | Sí | Agrega hallazgos de todas las regiones en la Aggregation Region | | GuardDuty | Sí | Sí | La cuenta de administración puede consultar los hallazgos de las cuentas miembro | | AWS Config | Sí | Requiere configuración adicional | Agregación multi-cuenta con Config Aggregator | | Amazon Macie | Sí | Sí | La cuenta de administración puede consultar los hallazgos de las cuentas miembro | | IAM Access Analyzer | Sí | Sí | Crea un analizador con alcance organizacional |
---
Resource Access Manager y el intercambio de recursos entre cuentas
Resource Access Manager (RAM) permite compartir recursos AWS con otras cuentas o con toda una organización. Se usa cuando resulta más eficiente en costos y gestión compartir un único recurso en lugar de replicarlo en cada cuenta.
Los recursos más habituales que se comparten con RAM son subredes de VPC, Transit Gateway, reglas de Route 53 Resolver y licencias de License Manager. El patrón más común es la subred de VPC compartida: la cuenta de networking central crea una VPC compartida y las cuentas de carga de trabajo despliegan instancias EC2 en esas subredes, manteniendo así fronteras independientes de IAM y seguridad mientras comparten la infraestructura de red.
Cuando se comparte dentro de Organizations, el destinatario no necesita aceptar una invitación: se aplica automáticamente. Compartir con cuentas externas a la organización sí requiere aceptación explícita.
Otro pilar del modelo de permisos entre cuentas es IAM Identity Center (antes SSO). Integrado con Organizations, permi