DEV Community: Terry Quispe Paniagua

🛡️AWS IAM Access Analyzer — Parte 1/4

Terry Quispe Paniagua — Sun, 21 Jun 2026 01:14:43 +0000

¿Quién puede acceder realmente a tus recursos en AWS?

En el post anterior hablamos de SCPs, RCPs y IAM Policies. Si no lo leíste, te recomiendo empezar por ahí porque este post construye sobre eso.

Hoy quiero hacerte una pregunta incómoda:

"¿Puedes decirme, ahora mismo, qué identidades tienen acceso efectivo a este bucket S3?"

No el acceso que pensaste que configuraste. El acceso real, considerando todas las políticas en juego.

Si tardas más de 30 segundos en responder, este post es para ti.

El problema con el acceso en AWS

Cuando tienes una sola cuenta y cuatro usuarios, responder esa pregunta es fácil. Abres la consola, revisas las políticas y listo.

Pero hay una diferencia importante entre dos cosas que suelen confundirse:

Acceso esperado: lo que crees que configuraste, suponiendo que sea correcto.
Acceso efectivo: lo que AWS realmente permite después de evaluar todas las políticas

La brecha entre estas dos cosas es donde vive la mayoría de los incidentes de seguridad en AWS. No son ataques sofisticados. Son configuraciones que alguien dio por buenas porque "la IAM policy dice que sí" — sin considerar el resto de las capas.

En el mundo real, un entorno AWS medianamente serio se parece más a esto:

10, 20, 50 o más cuentas dentro de una AWS Organization
Decenas de roles que se asumen entre cuentas - en algunas ocasiones he visto miles -.
SCPs aplicadas a nivel de OU que limitan lo que pueden hacer las identidades.
RCPs que controlan quién puede acceder a tus recursos desde fuera.
Resource-based policies en S3, KMS, SQS, SNS, etc.
Permission Boundaries en algunos roles.
Trust policies que definen quién puede asumir cada rol.

Y ahí es donde la cosa se complica de verdad.

¿Qué determina realmente el acceso efectivo?

Cuando AWS evalúa si una acción está permitida, no se queda solo con la IAM policy que ves en el rol o usuario. Revisa todas las capas que aplican a esa solicitud y parte de una regla muy simple: si no hay un Allow, el acceso está denegado; y si aparece un Deny explícito, ese Deny gana siempre.

Dicho de forma simple, en una sola cuenta la evaluación se puede entender así:

¿Existe un Deny explícito aplicable?
    └── Sí → DENEGADO. Fin.
    └── No → continuar

¿Existe algún Allow válido?
    └── Puede venir de una IAM policy o de una resource-based policy
    └── Si no existe → DENEGADO

¿Hay algún límite que recorte ese permiso?
    └── SCP
    └── RCP
    └── Permission Boundary
    └── Session Policy

Si hay Allow y ningún límite lo bloquea → PERMITIDO

La parte importante es esta: IAM policies y resource-based policies pueden conceder permisos, pero SCPs, RCPs, Permission Boundaries y Session Policies funcionan más como límites. No agregan permisos por sí solos; más bien definen hasta dónde puede llegar un permiso que ya existe.

Resumido de forma práctica:

Acceso efectivo =
    permiso concedido
  - denies explícitos
  - límites organizacionales
  - boundaries o session policies aplicables

Si cualquiera de estas capas dice "No", la acción está bloqueada. No importa que las demás capas parezcan permitirlo. Este es el punto que la gente entiende en teoría pero subestima en la práctica. En cross-account hay matices adicionales, porque AWS evalúa tanto la cuenta del principal como la cuenta donde vive el recurso. Pero la idea base se mantiene: cualquier deny explícito aplicable bloquea la acción. Puedes revisar el flujo de evaluación en:

El problema a escala: con múltiples cuentas, cientos o miles de roles, innumerables recursos, varias OUs con diferentes SCPs y RCPs, hacer este análisis a mano para cada recurso crítico es inviable. Y si no lo haces, no sabes realmente qué acceso tienen tus identidades.

Tres escenarios donde el acceso falla aunque "debería" funcionar

Estos son los casos que más se repiten. Si has trabajado en entornos con Organizations, probablemente reconoces alguno.

Escenario 1: El admin que no puede hacer nada

Un usuario tiene la política AdministratorAccess en su cuenta. Intenta crear un bucket S3 en sa-east-1 y le da error de acceso denegado. No cambió nada. Todo funcionaba ayer.

Lo que pasó: alguien en el equipo de plataforma aplicó una SCP a nivel de OU que restringe la creación de recursos a us-east-1 únicamente - algo muy habitual y recomendado -. El admin ve un AccessDenied, pero también el motivo por el cual, ya que en el detalle de error se indica que la acción está vetada por una SCP - a veces no es tan detallado -.

La SCP es un límite máximo. AdministratorAccess dice "puede hacer todo", pero si la SCP dice "solo en us-east-1", el resultado es "puede hacer todo, solo en us-east-1".

Ejemplo: Eliminación de objeto con restricción por SCP

Ejemplo: Eliminación de objeto por CLI

Escenario 2: El bucket "público" que no lo es

Un desarrollador configura un bucket S3 con una bucket policy que permite s3:GetObject a "Principal": "*". Desde su cuenta local, el acceso funciona. Pero desde una cuenta externa de un proveedor, el acceso falla.

Lo que pasó: hay una RCP a nivel de organización que exige que cualquier acceso a recursos de S3 venga de un principal con aws:PrincipalOrgID igual al ID de la organización. El "*" de la bucket policy no se limita a sí mismo — la RCP sí lo limita desde afuera.

La RCP actúa sobre el recurso sin importar lo que diga la bucket policy. El desarrollador configuró el acceso "correctamente" según lo que entiende de S3, pero la capa organizacional lo restringe silenciosamente.

Escenario 3: El rol cross-account que IAM permite pero S3 no

Un rol en la Cuenta B tiene una IAM policy que permite s3:GetObject sobre el bucket arn:aws:s3:::datos-criticos/*. El equipo valida la policy, todo se ve bien. Pero cuando el rol intenta acceder al bucket, falla.

Lo que pasó: la bucket policy en la Cuenta A (donde vive el bucket) no lista el rol de Cuenta B como Principal permitido. En acceso cross-account, tanto la IAM policy del rol como la resource-based policy del recurso deben permitir la acción de forma explícita. Una sola no alcanza.

Este es uno de los errores más comunes con acceso cross-account: el equipo de Cuenta B configura sus políticas IAM perfectamente y asume que eso es suficiente. No lo es.

¿Qué es IAM Access Analyzer y qué tipos existen?

IAM Access Analyzer es el servicio de AWS que ayuda a identificar y revisar accesos sobre recursos e identidades. En vez de revisar políticas manualmente y cruzar capas en tu cabeza — lo que puede ser propenso a errores y muy complicado — , el analizador lo hace por ti y genera findings — hallazgos sobre accesos que merecen revisión.

Hay tres tipos de analizador, y es importante no confundirlos porque resuelven problemas distintos:

Tipo	¿Qué detecta?	¿Tiene costo?	¿Cuándo usarlo?
External Access	Recursos accesibles desde fuera de tu zona de confianza (otra cuenta, internet)	Sin costo adicional	Siempre. Es el punto de partida en cualquier cuenta
Internal Access	Qué principals dentro de tu org tienen acceso a recursos específicos, con permisos efectivos	Pagado ($9 USD/recurso/región/mes)	Recursos críticos: buckets, RDS o cluster snapshots, DynamoDB etc.
Unused Access	Roles y usuarios con permisos concedidos que no han sido utilizados	Pagado ($0.20 USD/rol o usuario/mes)	Revisiones de least privilege, limpieza de accesos obsoletos

La confusión más común es querer usar Internal Access para detectar accesos externos. No hace eso. Para eso existe External Access, que además es gratuito.

La novedad relevante que cubre esta serie es Internal Access, una de las capacidades más recientes de IAM Access Analyzer, que permite analizar el permiso efectivo considerando SCPs, RCPs y resource policies en conjunto.

¿Por qué importa esto para seguridad?

Auditorías y cumplimiento (PCI-DSS, ISO 27001, SOC 2)
En una auditoría, alguien va a pedirte evidencia de quién tiene acceso a tus datos sensibles. Access Analyzer te da eso en formato exportable, con el detalle de qué acciones puede realizar cada identidad. En vez de revisar cien políticas a mano, tienes un reporte automatizado.

Least privilege de verdad
Es fácil escribir "aplicamos least privilege" en un documento de arquitectura. Es difícil demostrarlo. Con análisis de permisos efectivos puedes ver exactamente qué permisos tiene cada identidad sobre cada recurso, y limpiar lo que sobra. No lo que crees que sobra — lo que el analizador te muestra que sobra.

Detección de configuraciones erróneas antes de que las encuentre alguien más
Un rol con "Resource": "*" donde debería tener un ARN específico. Una bucket policy que alguien amplió para una prueba y nunca revirtió. Un acceso cross-account que quedó abierto después de una migración. Estos hallazgos no generan alertas operacionales — el sistema funciona, el acceso existe, y nadie lo nota hasta que hay un incidente o una auditoría.

Esta serie da para más

Mientras armaba este post me di cuenta de que IAM Access Analyzer no se puede explicar bien en una sola publicación sin hacerlo pesado - la verdad los conceptos de acceso en cloud son pesados si no se aterrizan correctamente.

Por eso voy a separar la serie en tres partes mas una cuarta parte opcional como bonus con mcp: External Access, Internal Access y Unused Access. En cada una veremos el concepto, un caso práctico y un pequeño lab con evidencias, para aterrizarlo mejor y no quedarnos solo en la teoría.

ADVERTENCIA.
Algunos de los labs tendrán costos por lo que les pido precaución, lean antes y tengan controlado sus recursos.

¿Qué viene en la Parte 2?

En el siguiente post vamos al laboratorio. Vamos a:

Configurar un analizador Internal Access a nivel de organización
Crear tres roles con distintos niveles de acceso en una cuenta y un bucket en otra
Agregar una SCP que bloquea una acción aunque IAM y la bucket policy la permitan
Ver los findings de Access Analyzer y validar con CLI que el permiso efectivo es exactamente lo que el analizador reporta

💡 Reflexión: ¿Alguna vez encontraste un rol con más acceso del que debería tener, después de creer que todo estaba bien configurado? Es más común de lo que parece — y casi siempre la diferencia está entre el acceso esperado y el acceso efectivo.

🔜 Parte 2: Lab completo de IAM Access Analyzer Internal Access con SCPs, cross-account y validación por CLI.

AWS #CloudSecurity #IAM #AccessAnalyzer #AWSCommunityBuilder #CloudGovernance #AWSOrganizations

Referencias

🛡️ 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.