Implementación de una Arquitectura Multicuenta en AWS

Este documento detalla paso a paso cómo implementar una infraestructura multicuenta segura y bien gobernada en AWS, basada en servicios probados de AWS como AWS IAM Identity Center, AWS Organization, Control Tower, …,etc. Incluye todos los componentes críticos, mejores prácticas y lecciones aprendidas.

🔷 0. Fundamentos de la Arquitectura Multicuenta

0.1 ¿Qué es una cuenta?

Una cuenta de AWS es una unidad aislada con recursos, políticas de seguridad, límites de servicio y facturación propios. Cada cuenta tiene un único usuario root, que posee acceso completo y sin restricciones.

0.2 ¿Qué es una Arquitectura Multicuenta?

Una infraestructura multicuenta en AWS (Multiple AWS accounts) es un modelo de diseño que organiza recursos, cargas de trabajo y equipos en cuentas AWS separadas pero interconectadas, bajo un paraguas centralizado de gobierno y seguridad.

Definición Técnica:

Es una implementación del principio de «aislamiento de responsabilidades», donde:

  • Cada cuenta AWS (Account) funciona como un entorno lógico independiente con sus propios recursos, permisos y límites de servicio.
  • Una cuenta maestra (management account) actúa como centro de control para políticas organizacionales, identidad y cumplimiento.

Arquitectura de Referencia

Multiples cuentas (Member accounts) son gestionadas de forma centralizada desde una cuenta de administración (Management account). Las cuentas miembros se agrupan por características en común, para aplicar políticas en común. Un conjunto de cuentas miembros formaran una unidad organizativa (OU), varias OUs pueden crear una OU superior según conveniencia, así hasta llegar a la raíz de la organización. Tal como se muestra en el gráfico de abajo.

Ejemplo de una estructura jerárquica de niveles de administración.

0.3 ¿Por qué Implementar Multicuenta?

Beneficios Clave:

  1. Aislamiento de Riesgos:
    • Un incidente de seguridad (ej: compromiso de credenciales) no afecta a toda la organización.
    • Ejemplo: Si un atacante compromete la cuenta de Desarrollo, no podrá acceder a Producción.
  2. Gobernanza Centralizada:
    • Políticas de seguridad (SCPs) y guardrails aplicados consistentemente.
    • Cumplimiento regulatorio simplificado (ISO 27001, PCI DSS).
  3. Optimización de Costos:
    • Límites de servicio independientes por cuenta (ej: 5,000 instancias EC2 por cuenta).
    • Consolidación de facturación con AWS Organizations.
  4. Separación Lógica de Entornos:
    • Producción, Desarrollo, QA y Sandbox en cuentas distintas.
    • Equipos autónomos sin interferencias.
  5. Seguridad Jerárquica:
    • Cuentas especializadas para funciones críticas:
      • Log Archive: Almacenamiento inmutable de logs.
      • Audit: Monitoreo centralizado de seguridad.

Caso de Uso Real:

Una empresa FinTech usa:

  • Cuenta Producción para aplicaciones bancarias.
  • Cuenta Desarrollo para pruebas de nuevas features.
  • Cuenta SecOps para herramientas de seguridad (GuardDuty, Security Hub).
  • Log Archive con retención de 7 años para cumplir con regulaciones financieras.

🔷 1. Elección y Configuración de la Cuenta de administración (Management account)

1.1 ¿Qué es la Cuenta de administración (Management account)?

La cuenta de administración (o cuenta «cuenta root«) es:

  • La primera cuenta creada al abrir una cuenta AWS. Si es que se esta empezando y se tiene el objetivo ir a multicuenta. En caso que se tiene muchas cuentas, la cuenta de administracion será la que tendrá que cumplir ciertos criterios como la de no debe tener workloads ni recursos críticos, …,etc.
  • La única con acceso administrativo a AWS. Tiene acceso irrestricto a todos los recursos de la organización.
  • El punto central para gestionar identidades (IAM Identity Center), políticas (SCPs) y servicios compartidos.

1.2 Criterios para Elegirla

  1. Dedicación Exclusiva:
    • No debe ejecutar cargas de trabajo (EC2, RDS, etc.).
    • Solo alberga servicios de gobierno (Control Tower, AWS Organizations).
    • Consolidated Billing
    • Creación de cuentas a través de Control Tower (Si es de forma automatizada).
  2. Protección Reforzada:
    • MFA hardware obligatorio (YubiKey, FIDO2).
    • Sin claves de acceso API permanentes.
  3. Estructura de Usuarios.
    • Federación con Idp externos
    • Gestion de usuarios centralizados

1.3 Configuración Inicial

Pasos Críticos:

  1. Habilitar MFA para el usuario root y configurar la rotación de la clave (Este usuario no se debe de usar)
  2. Crear usuario administrativo: Con permiso «AdministratorAccess»
  3. Bloquear acciones peligrosas con SCPs (cuidado donde se aplica)
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": *,
      "Resource": "*",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      }
    }
  ]
}

🔷 2. Configuración de la Arquitectura Multicuenta

La configuración de la arquitectura multicuenta inicia con la selección de una cuenta de administración (ya definida en el punto 1). A continuación, se debe establecer la estructura de unidades organizativas (OUs) dentro de AWS, que servirá como base para la gestión centralizada de cuentas. Esta se puede hacer de forma manual o de forma automática, antes veamos los servicios claves con la que se puede acometer este apartado.

2.1 Servicios AWS Clave

2.1.1. AWS Organizations

  • Servicio global
  • Servicio base para gestión de cuentas.
  • Agrupa cuentas en Unidades Organizativas (OUs).
  • Aplica Service Control Policies (SCPs) a nivel de OU o cuenta.
  • Establecer zonas seguras para producción, desarrollo, pruebas, etc.
  • Delegar permisos específicos a administradores de cuentas o equipos.
Componentes clave:
  • Cuenta raíz (root account): La primera cuenta creada; actúa como cuenta «madre» o de facturación.
  • Cuentas miembro: Otras cuentas agregadas a la organización, gestionadas desde la raíz.
  • Unidades Organizativas (OUs): Grupos jerárquicos de cuentas. Se pueden aplicar SCPs a nivel de OU.
  • SCPs (Service Control Policies): Políticas que establecen el marco máximo de permisos para cuentas y OUs.
Ventajas:
  • Aislamiento y organización por equipos, entornos o proyectos.
  • Delegación segura del acceso.
  • Aplicación de políticas centralizadas.
  • Integración nativa con otros servicios (AWS SSO/Identity Center, Config, Control Tower, etc.).

2.1.2. AWS Identity Center

AWS Identity Center es un servicio de AWS que permite gestionar identidades y accesos de forma centralizada en múltiples cuentas y aplicaciones de AWS.

  • Centraliza la autenticación y autorización.
  • Se integra con Entra ID vía SAML para SSO corporativo.
  • Ventajas:
    • Control centralizado de acceso.
    • Delegación por grupo de AD a roles IAM en cuentas específicas.
    • Auditoría y trazabilidad desde Entra ID.

2.1.3. AWS Control Tower

  • Solución para desplegar una arquitectura multicuenta estándar con buenas prácticas.
  • Beneficios:
    • Crea landing zones preconfiguradas.
    • Provisiona cuentas con baseline de seguridad (guardrails).
    • Integra AWS Organizations, IAM Identity Center, CloudTrail, Config.
    • Automatiza la gobernanza y compliance desde el inicio.

Control Tower crea estas cuentas automáticamente:

  • Cuenta de Auditoría (Audit Account): para seguridad.
  • Cuenta de Log (Log Archive): para almacenar CloudTrail y Config centralizados.

2.1.4. Resumen

ServicioFunciónConfiguración Específica
AWS OrganizationsJerarquía de cuentas– OUs iniciales: Production, Development, Sandbox
– SCPs aplicadas a nivel raíz
IAM Identity CenterGestión centralizada de accesos– Federado con Microsoft Entra ID
– Grupos sincronizados: AWS-Admins, AWS-Developers
AWS Control TowerGobierno automatizado– Landing Zone v3.0
– Guardrails habilitados: AWS-GR_RESTRICT_ROOT_USER, AWS-GR_ENCRYPTED_VOLUMES

2.2 Estructura creada manualmente

Crear una arquitectura multicuenta utilizando únicamente AWS Organizations (sin herramientas adicionales como AWS Control Tower) ofrece flexibilidad, pero también implica asumir cierta responsabilidad en la gestión manual. A continuación, los pros y contras clave:

✅ Ventajas (Pros)

1. Máxima Flexibilidad
  • Puedes diseñar una jerarquía de OUs (Unidades Organizativas) totalmente personalizada según tus necesidades (ej.: /Root/Prod/Dev/Shared).
  • No estás limitado por plantillas predefinidas (a diferencia de AWS Control Tower).
2. Control Granular con SCPs
  • Puedes aplicar Service Control Policies (SCPs) para restringir permisos a nivel de cuenta u OU (ej.: bloquear regiones no permitidas o servicios riesgosos).
  • Útil para cumplimiento normativo (ej.: HIPAA, GDPR) sin capas adicionales de automatización.
3. Integración Directa con Servicios AWS
  • Funciona nativamente con:
    • AWS IAM Identity Center (gestión de usuarios/roles multicuenta).
    • AWS Config & CloudTrail (monitoreo centralizado).
    • AWS Resource Access Manager (RAM) para compartir recursos entre cuentas.
4. Costo Cero
  • AWS Organizations no tiene costo adicional (solo pagas por los recursos usados en las cuentas).

❌ Desventajas (Contras)

1. Gestión Manual Compleja
  • Debes configurar manualmente:
    • SCPs, políticas de backup, logging (CloudTrail), y monitoreo (AWS Config) en cada cuenta.
    • Plantillas de CFN o Terraform para estandarizar recursos (sin automatización nativa como en Control Tower).
2. Sin «Guardrails» Automatizados
  • AWS Control Tower ofrece guardrails (protecciones predefinidas contra configuraciones inseguras), mientras que en Organizations debes crearlos manualmente vía SCPs.
3. Mayor Riesgo de Errores Humanos
  • Sin automatización, es fácil:
    • Olvidar habilitar CloudTrail en una cuenta nueva.
    • Aplicar SCPs demasiado restrictivas/permisivas por error.
4. No Incluye «Landing Zone» Preconfigurada
  • En Organizations, debes configurar desde cero:
    • Cuentas VPC compartidas.
    • Roles IAM para acceso entre cuentas.
    • Estándares de seguridad (ej.: AWS Config rules).

📌 ¿Cuándo Usar Solo AWS Organizations?

  • Escenarios ideales:
    • Empresas con equipos DevOps maduros que prefieren control total.
    • Entornos donde Control Tower no es compatible (ej.: cuentas existentes con configuraciones complejas).
    • Requisitos de personalización extrema que superan las plantillas de Control Tower.
  • Alternativa recomendada:
    Si buscas gobernanza automatizada y cumplimiento rápido, combina Organizations con AWS Control Tower (para guardrails + automatización).

Conclusión

AWS Organizations es poderoso pero requiere más esfuerzo manual. Si tu prioridad es rapidez y estandarización, considera Control Tower. Si prefieres flexibilidad absoluta, Organizations es suficiente.

2.3 Estructura Creada automáticamente

AWS Control Tower es la solución de AWS para implementar y gestionar un entorno multicuenta de manera automatizada y estandarizada, siguiendo las mejores prácticas de AWS (Landing Zone). A continuación, sus principales ventajas y desventajas:

✅ Ventajas (Pros)

1. Implementación Rápida y Automatizada («Landing Zone»)
  • Configuración predefinida:
    • Crea automáticamente cuentas centrales (Log Archive, Audit, Shared Services).
    • Establece VPC compartidos, roles IAM entre cuentas y políticas de guardrails.
  • Ahorra tiempo: Elimina la necesidad de configurar manualmente SCPs, CloudTrail, AWS Config, etc.
2. Gobernanza Automatizada con Guardrails
  • Guardrails preventivos y detectivos:
    • Bloquean acciones inseguras (ej.: desactivar cifrado en S3, crear recursos en regiones no permitidas).
    • Basados en SCPs y AWS Config rules.
  • Cumplimiento estándar: Ideal para regulaciones como GDPR, HIPAA, CIS Benchmark.
3. Gestión Centralizada desde un Solo Lugar
  • Dashboard único para:
    • Registrar nuevas cuentas.
    • Aplicar guardrails y políticas.
    • Monitorear el cumplimiento.
  • Integración nativa con AWS Organizations y IAM Identity Center.
4. Fácil Escalabilidad
  • Automatización de creación de cuentas:
    • Usa Account Factory para generar cuentas preconfiguradas con estándares.
    • Soporta customizaciones vía AWS Service Catalog.

❌ Desventajas (Contras)

1. Menor Flexibilidad en Personalización
  • Limitado por plantillas predefinidas:
    • Difícil modificar la Landing Zone después de su implementación.
    • Algunas empresas necesitan ajustes fuera de los estándares de AWS.
2. No Cubre Todos los Escenarios de Cumplimiento
  • Guardrails genéricos: Pueden no ser suficientes para requisitos altamente especializados.
  • Requiere herramientas adicionales (ej.: AWS Security Hub, Custom Config Rules) para necesidades avanzadas.
3. Complejidad en Entornos ya Existentes
  • Migrar cuentas existentes a Control Tower puede ser complicado (requiere «enrollment»).
  • Algunos recursos preexistentes pueden entrar en conflicto con los guardrails.
4. Costos Adicionales
  • AWS Config, CloudTrail, Service Catalog, y otros servicios subyacentes generan costos.
  • No recomendado para organizaciones muy pequeñas (menos de 5 cuentas).

📌 ¿Cuándo Usar AWS Control Tower?

  • Escenarios ideales:
    • Empresas que necesitan estandarización rápida y cumplimiento con mínima configuración manual.
    • Equipos con poca experiencia en AWS que quieren evitar errores comunes.
    • Entornos que requieren gobernanza fuerte desde el primer día (ej.: sector financiero, salud).
  • Alternativa:
    Si necesitas máxima flexibilidad, usa AWS Organizations + Custom SCPs (pero con más trabajo manual).

Conclusión

AWS Control Tower es la mejor opción para implementar una arquitectura multicuenta segura y estandarizada en poco tiempo, pero puede ser rígido para necesidades muy personalizadas.

2.3.1 Comportamiento de Control Tower

🔍 Comportamiento de Control Tower en Cuentas Vírgenes

Cuando implementas AWS Control Tower en una cuenta AWS que no tiene preconfigurados AWS Organizations o IAM Identity Center, el servicio activa y configura automáticamente estos componentes.

1. Si NO tienes AWS Organizations activado:

  • Control Tower lo activará automáticamente al ejecutar el proceso de configuración inicial (Set Up Landing Zone).
  • Creará una organización con estructura básica:
    • OU raíz (Root OU).
    • OU «Core»: Contendrá las cuentas especiales (Log Archive y Audit).
    • OU «Custom»: Para cuentas creadas posteriormente.

2. Si NO tienes IAM Identity Center (AWS SSO) activado:

  • Control Tower lo despliega y configura como parte de la Landing Zone.
  • Configuración automática:
    • Directorio interno administrado por AWS (si no hay integración existente).
    • Creación de grupos básicos (AWSControlTowerAdmins, AWSControlTowerAuditors).
⚠️ Caso Específico; AWS Organization y IAM Identity Center ya activados y configurados.

La instalación de Control Tower no es disruptivo:

  1. Control Tower detectará la configuración existente.
  2. Intentará integrarse con ellos, pero hay consideraciones críticas:
    • IAM Identity Center:
      • Si ya está federado con Microsoft Entra ID, Control Tower mantendrá la federación.
      • Los grupos y usuarios existentes no se modificarán, pero se añadirán los roles/grupos propios de Control Tower.
    • AWS Organizations:
      • Si ya tienes OUs creadas, Control Tower no las eliminará, pero:
        • Creará sus OUs predeterminadas (Core, Custom).
        • Recomienda mover cuentas existentes a estas OUs para un gobierno óptimo.

2.3.2 OUs (Unidades Organizativas) por Defecto

  1. Core: Cuentas de gestión central.
    • Log Archive: Almacenamiento centralizado de logs (CloudTrail, Config).
    • Audit: Monitoreo de seguridad y cumplimiento.
  2. Custom: Para cuentas creadas manualmente.

2.3.3 Cuentas Automáticas

CuentaPropósitoConfiguración
Log ArchiveAlmacena logs organizacionales– Retención configurada a 7 años
– Política S3: WORM (Write Once Read Many)
AuditCentraliza hallazgos de seguridad– AWS Security Hub delegado
– Amazon GuardDuty habilitado

🔷 3. Flujo de Administración

Este punto se enfoca en cómo gestionar operativamente una estructura multicuenta de manera eficiente, segura y escalable. Incluye procesos para creación de cuentas, asignación de permisos, gobernanza centralizada y monitoreo.

3.1 Establecer un Modelo de Administración Centralizada

Objetivo: Evitar gestión fragmentada y reducir riesgos de seguridad.

  • Cuenta Maestra de Administración (definida en el punto 1):
    • Único punto para gestionar AWS Organizations, IAM Identity Center y Control Tower.
    • Acceso restringido a roles break-glass (ej.: AdminEmergency) con MFA obligatorio.
  • Herramientas clave:
    • AWS Organizations: Para crear OUs, aplicar SCPs y agrupar cuentas.
    • IAM Identity Center: SSO centralizado con asignación de permisos basados en grupos (ej.: DevOps, Auditors).

3.2 Proceso de Creación y Onboarding de Cuentas

Flujo estándar para nuevas cuentas:

  1. Solicitud:
    • Formulario automatizado (ej.: ServiceNow, Jira) con datos requeridos:
      • Nombre de cuenta, OU destino (ej.: /Prod o /Dev), tags obligatorios (CostCenter, Owner).
  2. Aprobación:
    • Validación por equipo de cloud governance.
  3. Provisioning:
    • Automático: Usar AWS Control Tower Account Factory (recomendado para estandarización).
    • Manual: Vía AWS Organizations + CloudFormation/Terraform si se requiere personalización extrema.
  4. Configuración inicial:
    • Asignar guardrails (SCPs), roles IAM cross-account y VPC templates.

3.3 Gestión de Accesos y Permisos

Modelo recomendado:

  • Jerarquía de permisos basada en OUs:
    • Ejemplo: Cuentas en /Prod tienen SCPs restrictivas (ej.: bloquear regiones no aprobadas).
  • IAM Identity Center para SSO:
    • Grupos como Developers-Prod (acceso solo a cuentas en /Prod con políticas predefinidas).
  • Mínimos privilegios:
    • Evitar el uso de AdministratorAccess; en su lugar, usar roles como PowerUser o custom policies.

3.4 Monitoreo y Auditoría Centralizada

Herramientas y prácticas:

  • AWS CloudTrail:
    • Habilitado en todas las regiones con logs centralizados en la cuenta Log Archive.
  • AWS Config:
    • Reglas globales para detectar configuraciones inseguras (ej.: S3 públicos, security groups abiertos).
  • AWS Security Hub:
    • Agregar hallazgos de seguridad en un solo dashboard.
  • Alertas proactivas:
    • Usar Amazon SNS + Lambda para notificar sobre actividades sospechosas (ej.: login sin MFA, cambios en SCPs).

3.5 Automatización y Escalabilidad

Cómo optimizar operaciones:

  • Infraestructura como Código (IaC):
    • Plantillas de CloudFormation/Terraform para recursos repetibles (ej.: VPCs, roles IAM).
  • AWS Service Catalog:
    • Catálogo de productos preaprobados (ej.: entornos EKS, buckets S3 cifrados) para equipos internos.
  • EventBridge + Lambda:
    • Automatizar respuestas a eventos (ej.: cerrar cuentas no usadas, aplicar tags faltantes).

Diagrama de Flujo (Ejemplo)

Errores Comunes a Evitar

  1. SCPs demasiado restrictivas: Pueden bloquear operaciones legítimas (ej.: impedir que CloudFormation cree roles necesarios).
  2. Falta de tagging: Dificulta la gestión de costos y atribución de recursos.
  3. Accesos compartidos: Evitar uso de credenciales IAM de larga duración; preferir roles temporales.

🔷 4. Componentes Adicionales Clave

4.1 Seguridad Centralizada

ServicioConfiguración
AWS Security Hub– Centraliza hallazgos en la cuenta de auditoría.
– Agrega resultados de servicios como GuardDuty, Inspector, Macie.
– Define controles de seguridad alineados con CIS/AWS Foundational Security Best Practices.
AWS Config– Agregador organizacional habilitado
– Auditoría de configuraciones.
– Historial de cambios.
– Activar a nivel organizacional para trazabilidad completa.
Amazon GuardDuty– Habilitado en todas las regiones
– Detección de amenazas (IAM abuse, comportamiento anómalo, escaneo de puertos, etc.).
– Se activa en todas las cuentas y se centraliza en la cuenta de seguridad.
CloudTrail– Registro de actividades API.
– Configurar con trail organizacional hacia la cuenta de log.
IAM Access Analyzer– Detecta políticas demasiado permisivas.
– Recomendado habilitar en todas las cuentas.

4.2 Automatización

  • AWS Service Catalog: Plantillas preaprobadas para:
    • VPCs compartidas (usando RAM).
    • Buckets S3 con encriptación obligatoria.
  • AWS Control Tower Account Factory: Creación automatizada de cuentas con configuraciones estándar.

🔷 5. Diagrama de Arquitectura Completo

🔷 6. Checklist de Implementación

6.1 Pasos Obligatorios

  1. Habilitar MFA en el usuario root.
  2. Crear política restrictiva para el usuario admin.
  3. Implementar Control Tower con OUs iniciales.
  4. Configurar federación con Entra ID (SCIM).
  5. Habilitar guardrails críticos (DISALLOW_ROOT_ACTIONS).

6.2 Pasos Recomendados

  1. Configurar notificaciones para acciones root (via CloudTrail + SNS).
  2. Establecer revisión trimestral de SCPs.
  3. Implementar acceso temporal para cuentas Log Archive/Audit.

🔷 7. Solución de Problemas Comunes

7.1 Error al Crear Cuentas

  • Síntoma: «Cannot assume role in target account».
  • Solución: Verificar que el rol AWSControlTowerExecution existe en la cuenta management.

7.2 Sincronización Fallida de Usuarios

  • Síntoma: Usuarios no aparecen en IAM Identity Center.
  • Solución: Revisar el provisioning en Entra ID → AWS IAM Identity Center.

🔷 8. Conclusión

Esta arquitectura proporciona:

  • Gobierno centralizado mediante Control Tower.
  • Seguridad mejorada con guardrails y SCPs.
  • Gestión simplificada de identidades via IAM Identity Center.
  • Escalabilidad para cientos de cuentas.
Funciona gracias a WordPress