Forem: Terry Quispe Paniagua

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

Terry Quispe Paniagua — Tue, 02 Dec 2025 03:47:50 +0000

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:
```
 <tuemail_sin_@gmail.com>+labscp@gmail.com
```
Ejemplo: Si tu correo es pepito@gmail.com, tu segunda cuenta deberá ser: pepito+labscp@gmail.com

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 Policy Deep Dive

Terry Quispe Paniagua — Sun, 23 Nov 2025 23:37:11 +0000

Parte 1: ¿Crees que tus datos están seguros solo con IAM? Hablemos de SCPs y RCPs.

🛡️ La seguridad en la nube requiere una estrategia de defensa en profundidad. 🛡️
Cuando empecé en AWS, pensaba que con IAM bastaba. Pero al profundizar, me di cuenta de la importancia de capas adicionales como las SCPs y RCPs.

Entender la diferencia entre Identidad, Recurso y Control Organizacional es vital para proteger nuestros entornos. No es solo "dar permisos", es saber dónde aplicarlos para garantizar el menor privilegio y la máxima seguridad.

Aquí les comparto mi guía mental para no perderse y saber identificar cuando podemos o debemos usar cada una de estas.

1️⃣ Identity-based Policies (IAM Policies)

👉 El "Quién puede hacer qué" Son las más comunes. Se adjuntan a Usuarios, Grupos o Roles.
📝 Ejemplo: Un usuario de operaciones necesita iniciar o detener instancias EC2s, pero no puede crear, terminar ni modificar instancias.

Acción: Crear una Policy que permita ec2:StartInstances y ec2:StopInstances en la tabla de "Productos".
Resultado: Si intenta modificar o eliminar la instancia, AWS le dice "No".

2️⃣ Resource-based Policies

👉 El "Quién puede tocar ESTO" Aquí la regla vive en el recurso mismo (S3 Bucket, SQS, KMS Key), no en el usuario. Son vitales para accesos Cross-Account pero no restringidos a ellos. 📝 Ejemplo: Tienes un Bucket S3 de logs centralizados.

Acción: Colocas una Bucket Policy que dice: "Permitir s3:PutObject a la cuenta de Producción (Account B)".
Resultado: La cuenta B puede escribir logs ahí sin tener un usuario creado en tu cuenta de logs.

3️⃣ Service Control Policies (SCPs)

👉 Las "Reglas de la Casa" (Límites de Identidad, popularmente guardrail o barandilla de seguridad) Aquí es donde muchos se confunden. Las SCPs NO dan permisos. Solo definen el máximo permiso posible. Si la SCP dice "No", no importa si tienes AdminAccess, es un "No". 📝 Ejemplo: Seguridad Compliance.

Acción: Aplicas una SCP en la raíz de tu Organización que niega ec2:RunInstances en cualquier región que no sea us-east-1.

- Resultado: Aunque seas Admin, si intentas levantar un servidor en Tokyo, fallará.

Resource Control Policies (RCPs)

👉 El "Perímetro de Datos" (Límites de Recurso) Funcionan como las SCPs, pero enfocadas en restringir el acceso a tus recursos, sin importar quién sea el que llama (incluso si es externo). 📝 Ejemplo: Data Perimeter estricto.

Acción: Creas una RCP que dice: "Nuestros Buckets S3 solo pueden ser accedidos por Principals que pertenezcan a nuestra Organización (PrincipalOrgID)".
Resultado: Si alguien configura por error un Bucket como "Público" o intenta darle acceso a una cuenta externa de un proveedor, la RCP lo bloquea automáticamente. Ideal para prevenir ataques de exfiltración de datos

Resumen

Tipo de Política	Se aplica a...	Función Principal	¿Cuándo usarlo?
IAM Policy	Usuario/Rol/Grupo	Otorgar permisos	Para otorgar permisos a usuarios, grupos o roles
Resource Policy	S3, SQS, etc.	Otorgar acceso (incluso externo)	Para definir quien puede acceder a un recurso
SCP	Cuenta AWS (excepto cuenta administradora de la organización), Unidades Org	Restringir permisos máximos (Identidad)	Para establecer límites máximos sobre las identidades
RCP	Recursos de la Org, excepto recursos de la cuenta administradora de la organización	Restringir acceso máximo (Recurso)	Para establecer límites máximos sobre sobre quien accede a tus datos

🔥 Bonus: Perspectiva Red Team

Entender IAM, SCPs y RCPs no solo es vital para proteger tu cuenta y organización, también es un componente clave para reducir la superficie de ataque.

Por ejemplo:

Escenario de Red Team: un atacante intenta asumir roles o crear usuarios para escalar privilegios.
SCPs bloquean el movimiento lateral: aunque tenga AdminAccess en una cuenta hija, no podrá ejecutar acciones prohibidas por la SCP a nivel de Organización (ej: organizations:LeaveOrganization, iam:CreateUser).
RCPs evitan exfiltración de datos: un bucket mal configurado no permite accesos de cuentas externas aunque el atacante tenga privilegios en otra parte.
Conclusión: conocer y aplicar correctamente estas políticas es como poner murallas antes de que alguien llegue al nucleo de tu entorno.

💡 Pregunta de reflexión: ¿por qué es un riesgo crítico desplegar recursos productivos o mantener usuarios activos operando directamente en la cuenta administradora de la organización o también llamado Payer Account?

🔜 En el próximo post: Profundizaremos en las SCPs, cuales son las SCPs mas relevantes que toda cuenta debería tener y cómo configurarlas correctamente para dormir tranquilos.