Seguridad multi-cuenta a escala

Asegurar una cuenta de AWS es un problema que ya sabes resolver: activas CloudTrail, despliegas GuardDuty, revisas tus roles IAM. Pero las empresas no tienen una cuenta: tienen decenas o cientos. Cada equipo quiere la suya, cada entorno (prod, staging, sandbox) vive separado, y las adquisiciones llegan con su propia nube. La pregunta deja de ser «¿cómo aseguro esta cuenta?» y pasa a ser «¿cómo garantizo que las 300 nacen seguras, se mantienen conformes y nadie puede desactivar los controles?». Esta nota trata de la maquinaria que hace eso posible.

Por qué múltiples cuentas#

La cuenta de AWS es el límite de aislamiento más fuerte que existe: separa facturación, cuotas de servicio, radio de explosión y permisos. Una identidad comprometida en la cuenta de sandbox no toca producción si están en cuentas distintas. Por eso la práctica recomendada no es una cuenta gigante con muchas VPC, sino muchas cuentas pequeñas organizadas bajo AWS Organizations, agrupadas en organizational units (OU) por función o entorno.

El problema es operar eso sin volverse loco. Necesitas una forma de crear cuentas con una línea base idéntica, aplicar reglas que ninguna cuenta pueda saltarse y ver la postura de todas desde un sitio.

La landing zone: AWS Control Tower#

AWS Control Tower automatiza el despliegue de una landing zone: el andamiaje multi-cuenta bien construido sobre el que creces. Al configurarlo obtienes una estructura de OU, el inicio de sesión centralizado con IAM Identity Center, el registro organizacional de CloudTrail y Config hacia una cuenta de archivo, y una fábrica de cuentas (Account Factory) que aprovisiona cuentas nuevas ya con la línea base aplicada.

Su mecanismo de gobierno son los controles (el término antiguo era guardrails). Hay tres tipos, y conviene no confundirlos:

Tipo de control	Cómo se implementa	Qué hace
Preventivo	Service Control Policy (SCP)	Impide la acción: la API se rechaza
Detectivo	Regla de AWS Config	Detecta la desviación y la marca como no conforme
Proactivo	CloudFormation Hooks	Bloquea el recurso no conforme antes de crearlo

Cada control viene etiquetado como obligatorio, fuertemente recomendado o electivo, y el panel de Control Tower te dice qué cuentas cumplen cada uno.

El plano completo: AWS Security Reference Architecture#

Control Tower te da el esqueleto; la AWS Security Reference Architecture (SRA) te dice dónde colocar cada órgano. Es la guía prescriptiva de AWS para distribuir los servicios de seguridad en una organización. Su idea central es separar responsabilidades en cuentas dedicadas:

Cuenta de gestión (management): la raíz de la organización. Es la más privilegiada (puede crear cuentas, aplicar SCP), así que se mantiene casi vacía: nada de cargas de trabajo, mínimo acceso humano.
Cuenta de Security Tooling (a veces security o audit): concentra la operación de seguridad. Aquí viven los administradores de Security Hub, GuardDuty, Config y Access Analyzer de toda la org.
Cuenta de Log Archive: recibe de forma centralizada e inmutable los logs de todas las cuentas (CloudTrail organizacional, Config, Flow Logs). Acceso muy restringido, retención larga, idealmente con Object Lock.

En Citas esto se traduce directamente: las cuentas prod y staging son cuentas miembro con cargas; CloudTrail organizacional vuelca a log-archive; y toda la detección se opera desde la cuenta de seguridad, no desde la de gestión.

Administradores delegados#

Aquí está una de las ideas más importantes y peor entendidas. Muchos servicios de seguridad pueden administrarse «para toda la organización» desde una sola cuenta. Por defecto, ese administrador sería la cuenta de gestión, pero no quieres operar seguridad desde la cuenta más privilegiada (cada login ahí es un riesgo). La solución es el administrador delegado: registras la cuenta de Security Tooling como administradora de Security Hub, GuardDuty, Config, Access Analyzer, Macie, Detective, Inspector… y operas desde ahí.

Cuenta de gestión (org root)
  └─ delega administración de ──► Cuenta Security Tooling
                                    ├─ Security Hub (admin de la org)
                                    ├─ GuardDuty (admin de la org)
                                    ├─ AWS Config / agregador
                                    └─ IAM Access Analyzer (org)

Detección centralizada: Security Hub y GuardDuty#

Con el administrador delegado configurado, Security Hub y GuardDuty se activan para toda la organización y agregan sus hallazgos en la cuenta de seguridad. GuardDuty analiza CloudTrail, VPC Flow Logs, DNS y más para detectar amenazas; Security Hub normaliza hallazgos de múltiples servicios (GuardDuty, Inspector, Macie, Access Analyzer) al formato OCSF/ASFF y los puntúa contra estándares como el AWS Foundational Security Best Practices o el CIS AWS Foundations Benchmark.

El resultado operativo: un analista mira un panel y ve la postura de 300 cuentas, en lugar de iniciar sesión en cada una. Las cuentas nuevas creadas por Account Factory quedan inscritas automáticamente, así que el día 1 de una cuenta ya está vigilada.

El perímetro de datos#

Las SCP evitan que tus identidades hagan cosas peligrosas, pero hay una clase de riesgo que necesita su propia defensa: que tus datos salgan de tu organización o que entren actores que no deberían. El perímetro de datos (data perimeter) es un conjunto de barandillas preventivas que garantiza tres cosas a la vez: que solo identidades confiables accedan a tus recursos, que esas identidades solo toquen recursos confiables, y que todo ocurra desde redes confiables.

Perímetro de datos: identidades, recursos y redes confiables

Gobernanza · Escala

Paso 1 de 6El escenario

Una organización de AWS con varias cuentas. El objetivo del perímetro de datos: que solo identidades confiables accedan a recursos confiables desde redes confiables.

Se construye combinando tres tipos de política:

Una Service Control Policy limita lo que las identidades de tu organización pueden hacer. Para el perímetro, la condición clave es aws:ResourceOrgID: deniega cualquier acción sobre recursos que no pertenezcan a tu organización. Así, aunque un rol tenga s3:PutObject, no puede escribir en un bucket de una cuenta ajena.

{
  "Effect": "Deny",
  "Action": ["s3:PutObject", "s3:GetObject"],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:ResourceOrgID": "o-ejemplo123"
    }
  }
}

Las Resource Control Policies son políticas a nivel de organización que se aplican sobre tus recursos (hoy, S3, STS, SQS, KMS, Secrets Manager y algún otro). Garantizan que solo principales de tu organización puedan acceder a ellos, con independencia de lo que diga la política del propio recurso. Resuelven el ángulo que la SCP no cubre: un bucket cuya política por error permitía Principal: "*".

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": ["s3:*"],
  "Resource": "*",
  "Condition": {
    "StringNotEqualsIfExists": {
      "aws:PrincipalOrgID": "o-ejemplo123"
    },
    "BoolIfExists": {
      "aws:PrincipalIsAWSService": "false"
    }
  }
}

Una política de VPC endpoint controla qué principales y recursos pueden alcanzarse cuando el tráfico sale por tus endpoints. Cierra el ángulo de red: que tus cargas solo puedan hablar con recursos de tu organización a través de tu propia red, y que las credenciales robadas no se puedan usar desde Internet. Se combina con condiciones como aws:SourceVpc o aws:SourceVpce en las SCP.

{
  "Effect": "Deny",
  "Principal": "*",
  "Action": "s3:*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:PrincipalOrgID": "o-ejemplo123" }
  }
}

Trampas habituales#

Tu turno

Diseña el perímetro de una organización que conozcas

Piensa en una organización de AWS real (la tuya, tu lab, o Citas con sus cuentas prod / staging / log-archive).

¿Qué cuentas dedicadas tiene o debería tener (gestión, seguridad, log-archive)? ¿Qué vive hoy en la cuenta de gestión que debería moverse?
Elige un servicio de seguridad (Security Hub o GuardDuty) y describe cómo lo delegarías: qué cuenta sería la administradora.
Escribe en una frase cada una de las tres garantías del perímetro de datos para tu bucket más sensible: identidad confiable, recurso confiable, red confiable. ¿Cuál no estás cubriendo hoy?

Reto

¿Por qué necesitas RCP si ya tienes SCP con aws:ResourceOrgID?

▸Mostrar solución

Porque actúan sobre lados distintos. La SCP restringe a tus identidades (no pueden tocar recursos externos). La RCP restringe tus recursos (solo identidades de tu org pueden tocarlos), incluso frente a principales externos o a una política del propio recurso mal configurada. Una SCP no puede proteger tu bucket de un Principal: "*" accidental; una RCP sí. Juntas cierran los dos sentidos del flujo.