🛡️ Entendiendo las Service Control Policies (SCPs) en AWS Organizations

1. Introducción

¿Qué problema resuelven las SCPs?

Las SCPs, a diferencia de los permisos de IAM, no otorgan permisos, sino que los restringen. Popularmente llamados "guardrails" o "barandillas", son una herramienta clave para la gobernanza de AWS, así como también para fijar los lineamientos de seguridad y cumplimiento de la empresa.

Antes de proseguir debemos entender unos conceptos previos:

IAM Policy

Es un tipo de política de IAM que permite otorgar permisos a los usuarios y roles de AWS.

AWS Organizations

AWS Organizations es un servicio que permite administrar y gestionar de forma centralizada múltiples cuentas de AWS. Con Organizations puedes:

• Crear y gestionar cuentas de AWS (Account Management)
• Centralizar los costos de las cuentas de AWS (Billing)
• Gestionar los permisos de las cuentas de AWS junto a IAM Identity Center (Identity and Access Management)
• Aplicar políticas de seguridad a las cuentas de AWS (SCPs)
• Habilitar servicios multicuentas (Multi-account)
• Agrupar cuentas por Unidades Organizativas (Jerarquía de organización)
• Auditar entorno multicuentas (Audit)
• Compartir recursos en múltiples cuentas (Resource sharing)
• Automatizar aprovisionamiento de múltiples cuentas mediante CloudFormation (Multi-account)

2. Service Control Policies (SCPs)

Es un tipo de política de AWS Organizations que permite restringir los permisos de las cuentas de AWS que pertenecen a la organización. Esta es una característica de AWS Organizations; existen otras políticas, pero nos centraremos en el tipo de servicio.

Estructura de una SCP

La estructura de una SCP es la siguiente:

Elementos principales de una SCP:

Elemento	¿Qué hace?
Statement	Es el contenedor principal de una política. Puedes tener varios statements en una SCP (cuidado: hay un límite de caracteres).
Effect	Define si el statement permite (Allow) o bloquea (Deny) acciones. Nota: Allow no permite condicionales.
Action	Especifica qué acciones de AWS se permiten o bloquean (ej: s3:PutObject).
Resource	Indica a qué recursos de AWS aplica la política (ej: un bucket específico).
Condition	(Opcional) Agrega condiciones para que el statement aplique solo en ciertos casos.
NotAction	Lo opuesto a Action: especifica acciones que quedan exentas de la SCP.
NotResource	Lo opuesto a Resource: especifica recursos que quedan exentos de la SCP.
Sid	(Opcional) Un nombre amigable para identificar el statement.
Version	Define la versión del lenguaje de políticas (siempre usa "2012-10-17").

Comportamiento de una SCP

Para entender mejor cómo funcionan las SCPs, podemos agrupar sus comportamientos en cuatro categorías clave:

1. Principios Básicos

• Naturaleza: No otorgan permisos, solo los restringen.
• Evaluación: Un permiso solo se ejecuta si existe una política IAM que lo permita y una SCP que lo permita o no lo deniegue, en el caso de evaluación IAM y SCP. La evaluación final se encuentra en la documentación oficial de AWS.

2. Alcance: ¿A quién afecta?

• Cuentas Miembro: Las SCPs restringen los permisos de todos los usuarios y roles, incluido el usuario root.
• Administradores Delegados: Sí están afectados, ya que residen en cuentas miembro.
• Excepción Clave: La Cuenta de Administración (Management Account) NO se ve afectada por las SCPs.

3. Interacción con otras Políticas

• IAM Deny: Siempre tiene prioridad sobre cualquier SCP.
• SCP Deny: Bloquea la acción explícitamente, incluso si IAM otorga AdministratorAccess.
• Permission Boundaries: La evaluación final requiere: IAM Allow + SCP Allow + Boundary Allow.

4. Excepciones Técnicas

• Service-Linked Roles: No se pueden restringir con SCPs, ya que son necesarios para que los servicios de AWS funcionen correctamente.
• Resource-Based Policies: No se ven afectadas por SCPs; los accesos externos a recursos (como un bucket S3) siguen funcionando si la política del recurso lo permite.
• Usuarios Externos: No se ven afectados, incluso si acceden a recursos dentro de una cuenta restringida.

¿Dónde se aplican las SCPs?

En AWS Organizations, las SCPs se aplican a las cuentas de AWS que pertenecen a la organización y también a las unidades organizativas. Una unidad organizativa es como un folder donde puedes agrupar cuentas de AWS.

A continuación una vista de una jerarquía de organización en AWS Organizations:

Componentes de una jerarquía de organización:

• Cuenta raíz (Root): Es la cuenta principal de la organización, generalmente la cuenta de AWS que se creó al crear la organización. Importante: Aplicar una SCP a la cuenta raíz afecta a todas las cuentas de la organización sin excepción (mucho cuidado con esto).
• Unidades organizativas (OUs): Son como folders donde puedes agrupar cuentas de AWS. Aplicar una SCP a una OU afecta a todas las cuentas que pertenecen a la OU.
• Cuentas: Son las cuentas de AWS que pertenecen a la organización. Aplicar una SCP a una cuenta afecta solo a esa cuenta.

Nota: Las SCPs pueden aplicarse a múltiples cuentas por su característica de herencia.

3. Laboratorio: Creación de SCPs

Costo del laboratorio: $0

⚠️ Advertencia: Nunca debes aplicar una SCP a la cuenta productiva ni a un entorno con cuentas productivas. Siempre usa cuentas de prueba para validar el funcionamiento de la SCP antes de aplicarlo en múltiples cuentas.

A. Armando el laboratorio para probar SCPs

🔐 Requisitos previos

• Tener una cuenta AWS principal (payer) desde la cual crearás la Organización.
• Tener acceso administrativo a esa cuenta.
• No necesitas método de pago adicional para la segunda cuenta.

✅ Paso 1: Crear una Organización en AWS (si aún no está creada)

1.1. Ingresa a la cuenta administradora (payer/root) de AWS.

1.2. Ve al servicio AWS Organizations.

1.3. Si todavía no tienes una organización:

• Haz clic en Create Organization.
• Confirmar creación de la organización.

🎉 Ahora tienes la capacidad de usar SCPs.

✅ Paso 2: Crear una Unidad Organizativa (OU) para pruebas

Las OU te ayudarán a aislar y probar SCPs sin afectar nada productivo o importante.

2.1. En AWS Organizations, ve a AWS accounts.

2.2. Selecciona la OU raíz (root) y haz clic en Actions.

2.3. Clic en Create new organizational unit (OU).

2.4. Pon un nombre claro (ej: lab-scp-test) y acepta.

✅ Paso 3: Crear una cuenta miembro dentro de la OU

Crearás una segunda cuenta AWS desde la cuenta administradora. Esta cuenta será tu "cuenta de pruebas" donde validarás las SCPs.

3.1. Desde AWS Organizations, ve a AWS Accounts → Add an AWS account → Create an AWS account.

3.2. Rellena:

• Account name: lab-scp-member (o el nombre de tu elección, puedes cambiar el nombre a futuro)

• Email address: Te aconsejo usar tu correo con el que creaste la cuenta administradora, pero con un alias de la siguiente manera:
  

   <[e-mail]>[e-mail]
  

  Ejemplo: Si tu correo es [e-mail], tu segunda cuenta deberá ser: [e-mail]

3.3. Clic en Create an AWS account.

✅ Paso 4: Mover la cuenta a la OU creada

4.1. Selecciona la cuenta, clic en Actions → Move AWS account.

4.2. Elige la OU creada.

4.3. Clic en Move AWS account.

🔹 Configuración inicial de la cuenta miembro

AWS enviará un correo para activar la cuenta. Necesitarás entrar a la cuenta para probar las SCPs. Para el primer ingreso lo harás con la cuenta root (podrías generar un ingreso mediante IAM Identity Center, pero se verá en otro artículo) y harás un reset de contraseña. Procura seguir las buenas prácticas de seguridad colocando MFA y una contraseña fuerte.

Adicionalmente, necesitarás crear un usuario IAM con permisos de administrador, solo con propósitos de prueba, ya que no usaremos la root.

Guía para crear un usuario IAM: https://docs.aws.amazon.com/es_es/IAM/latest/UserGuide/id_users_create.html

Luego de crear el usuario IAM, procederás a ingresar a la cuenta miembro con el usuario IAM creado para realizar las pruebas de SCPs. Recuerda: es solo para pruebas. Las SCPs solo se adjuntarán y crearán en la cuenta administradora de la organización; no podrás ver la organización desde la cuenta miembro.

B. Creación de SCPs

✅ Paso 1: Acceder a AWS Organizations

1.1. Desde la consola de AWS, busca y selecciona Organizations.

1.2. Asegúrate de estar en la cuenta raíz de la organización o en una cuenta con permisos de administración de la organización.

✅ Paso 2: Crear la SCP

2.1. En el menú lateral, selecciona Policies → Service control policies.

2.2. Haz clic en Create policy.

2.3. Ingresa un nombre y descripción para tu política.

2.4. Define el contenido de la política en formato JSON (ver ejemplos más adelante).

C. Vincular política SCP a una OU o cuenta

✅ Paso 1: Vincular SCP a la OU de pruebas

1.1. En AWS Organizations → AWS accounts, selecciona la OU objetivo, cuenta o folder raíz.

1.2. Haz clic en Policies → Service control policies → Attach.

1.3. Selecciona la SCP creada y haz clic en Attach policy.

D. Prueba de SCP

1.1. Ve a la cuenta miembro (cuenta de pruebas).

1.2. Accede con el usuario IAM creado.

1.3. Intenta realizar la acción que se definió en la SCP.

4. Ejemplos de SCP para control de recursos en AWS

Nos basamos en una organización con estructura de OUs y cuentas de prueba, donde puedes aplicar estas SCPs para validar su funcionamiento.

Ejemplo de jerarquía organizativa:

Root
└── OU: <root-ou>
    ├── Development
    │   ├── Sandbox Dev 01 (Cuenta)
    │   └── <deepracer-aft1> (Cuenta)
    ├── Management
    │   └── Administrator (Cuenta de administración)
    ├── Network
    │   └── Networking (Cuenta)
    └── Security
        ├── Audit (Cuenta)
        └── Log Archive (Cuenta)

Nota: Estas SCPs se pueden aplicar a la OU raíz, a una OU específica o a cuentas individuales, según el alcance que necesites. Recuerda que las denegaciones prevalecen y no se aplican a la cuenta administradora.

1️⃣ Denegar creación de buckets S3

Evita que cualquier cuenta cree buckets S3:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3BucketCreation",
            "Effect": "Deny",
            "Action": "s3:CreateBucket",
            "Resource": "*"
        }
    ]
}

Aplicación: Colocar en la OU raíz para afectar a todas las cuentas de prueba, bloqueando la creación de buckets S3.

2️⃣ Restringir regiones de despliegue en las cuentas de Development

Evita que se utilicen regiones distintas a la permitida, dejando accesibles solo ciertos servicios esenciales:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "NotAction": [
                "budgets:*",
                "cloudfront:*",
                "config:*",
                "ec2:DescribeRegions",
                "ec2:DescribeTransitGateways",
                "ec2:DescribeVpnGateways",
                "iam:*",
                "networkmanager:*",
                "organizations:*",
                "route53:*",
                "s3:*",
                "shield:*",
                "sts:*",
                "support:*",
                "trustedadvisor:*",
                "waf:*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "${REGION_NAME}"
                    ]
                }
            }
        }
    ]
}

Reemplaza ${REGION_NAME} por la región autorizada (ejemplo: "us-east-1").

Aplicación: Útil para controlar costos y garantizar que recursos solo se desplieguen en regiones aprobadas. Dado que mencionan el alcance hacia las cuentas Development se vinculara a la OU Development que es el folder de esas cuentas.

descripcion: En este caso se uso de NotAction para no afectar ciertos servicios de alcanza global, en este caso servicios como budgets, cloudfront, config, iam, networkmanager, organizations, route53, s3, shield, sts, support, trustedadvisor, waf no se veran afectados pero los demas si.

3️⃣ Restringir tipos de instancias RDS

Evita que se creen instancias RDS que no correspondan a un tipo aprobado:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyUnapprovedRDSTypes",
            "Effect": "Deny",
            "Action": "rds:CreateDBInstance",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "rds:DatabaseClass": "${INSTANCEDBTYPE}"
                }
            }
        }
    ]
}

Reemplaza ${INSTANCEDBTYPE} por el tipo de instancia aprobado (ejemplo: "db.t3.medium").

Aplicación: Garantiza estándares de arquitectura y control de costos en RDS.

4️⃣ Denegar escritura en buckets S3 fuera de la organización

Evita que cualquier cuenta escriba en buckets S3 que no pertenezcan a la organización:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyS3WritesToUnauthorizedBuckets",
            "Effect": "Deny",
            "Action": [
                "s3:Put*"
            ],
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:ResourceOrgID": "[O-XXXXX]"
                }
            }
        }
    ]
}

Reemplaza [O-XXXXX] por el ID de tu organización.

Aplicación: Útil para prevenir que los datos se escriban fuera de los buckets gestionados por tu organización, reforzando la seguridad y gobernanza de S3.

5. SCPs que toda cuenta debería tener

No existen SCPs que toda cuenta debería tener de forma universal, ya que cada organización tiene sus propias necesidades y requisitos. Sin embargo, bajo un modelo de seguridad básico, considero que las cuentas deberían tener al menos las siguientes SCPs:

🔐 5.1. Denegar la utilización de cuentas ROOT

Descripción: Evita que se realicen acciones críticas usando la cuenta raíz de AWS.

Beneficio: Protege la cuenta administrativa principal de accesos accidentales o maliciosos.

---

🚪 5.2. Denegar la acción de salir de la organización

Descripción: Impide que las cuentas miembros abandonen la organización.

Beneficio: Mantiene la gobernanza centralizada y evita pérdidas de control sobre cuentas.

---

👤 5.3. Denegar acciones en IAM que no sean usuarios y roles específicos

Descripción: Restringe la creación o modificación de políticas, roles y permisos que no estén permitidos.

Beneficio: Evita escalación de privilegios no controlada y mantiene la seguridad de la identidad.

---

🌍 5.4. Denegar regiones no utilizadas en la organización

Descripción: Bloquea la creación de recursos fuera de las regiones aprobadas.

Beneficio: Controla costos y asegura consistencia operativa en regiones autorizadas.

---

📝 5.5. Denegar borrado y modificación de registros específicos

Descripción: Protege logs críticos de CloudTrail, Config u otros registros importantes.

Beneficio: Garantiza trazabilidad y cumplimiento normativo.

---

🗄️ 5.6. Denegar borrado de buckets donde se guardan registros de auditoría

Descripción: Impide que se eliminen buckets S3 usados para almacenar logs de auditoría.

Beneficio: Asegura la integridad de los registros y evidencia de auditoría.

---

💰 5.7. Denegar servicios con alto coste no útiles para la organización

Descripción: Bloquea servicios como Redshift, SageMaker u otros que no estén aprobados.

Beneficio: Evita gastos innecesarios y recursos no autorizados.

Aunque muchas de estas SCPs están enfocadas principalmente en gobernanza y control, también actúan como capas adicionales de seguridad, creando barreras que protegen la organización de errores, mal uso o accesos no deseados.

6. Conclusión

Las Service Control Policies (SCPs) son una herramienta fundamental para establecer guardrails de seguridad, cumplimiento y gobernanza en AWS Organizations. A través de este artículo hemos aprendido:

• Qué son las SCPs y cómo se diferencian de las políticas IAM tradicionales
• Cómo funcionan y a quién afectan dentro de la organización
• Dónde aplicarlas en la jerarquía organizativa
• Cómo crear un laboratorio de pruebas sin costo para validar SCPs
• Ejemplos prácticos de políticas comunes para controlar recursos
• Recomendaciones básicas de SCPs que toda organización debería considerar

Recuerda siempre probar tus SCPs en entornos de prueba antes de aplicarlas en producción, ya que una política mal configurada puede bloquear operaciones críticas. Las SCPs son restrictivas por naturaleza: no otorgan permisos, solo los limitan.

Con una implementación cuidadosa, las SCPs te permitirán mantener el control centralizado de tu entorno multi-cuenta, reducir riesgos de seguridad y optimizar costos operativos.

7. Bonus RedTeam

Hemos hablado bastante de SCPs, pero ahora comprendes que tan importante es la management account para controlar todo el entorno. Si alguien tiene acceso no autorizado a la management account es lo mas peligroso que puede pasar, como recordaras estan excentas de las SCPs y puedes tomar acciones en las cuentas miembros desde crearlas, cerrarlas o expulsarlas de la organización. AWS organizations no es solo politicas de organización, es un servicio que integra muchos otro servicio de seguridad que veremos mas adelante.

8. Pregunta de reflexión final

¿Qué tan seguro crees que es tu entorno multi-cuenta? ¿Qué medidas adicionales consideras importantes para mejorar la seguridad de tu organización?

🚀 ¡Ahora es tu turno de implementar SCPs en tu organización!

---

9. Documentación y Referencias

• AWS IAM - Lógica de evaluación de políticas
• AWS Organizations - Tutorial básico
• AWS Organizations - Gestión de Service Control Policies
• AWS Threat Technique Catalog - Técnicas de amenazas en Organizations
• AWS Organizations - Ejemplos de SCPs