SCP en AWS Organizations: patrones de diseño para gobernanza segura en entornos multi-cuenta

Cuando tu organización crece y empieza a utilizar múltiples cuentas de AWS para separar entornos (desarrollo, pruebas, producción), equipos o proyectos, surge un desafío crítico: ¿cómo aplicar de manera consistente políticas de seguridad, cumplimiento y gobernanza en todas esas cuentas sin depender de la disciplina individual de cada equipo?

AWS Organizations responde a este desafío permitiéndote consolidar múltiples cuentas bajo una estructura jerárquica, y las Service Control Policies (SCP) son la herramienta principal para aplicar guardrails de seguridad a nivel de organización. Los SCP actúan como filtros que definen qué acciones están permitidas o denegadas en las cuentas afectadas, actuando como un límite superior de permisos que no pueden ser sobrepasados ni siquiera por usuarios con privilegios de administrador en la cuenta.

En este artículo exploraremos patrones de diseño probados para SCP que te ayudarán a implementar una gobernanza efectiva en entornos multi-cuenta de AWS, enfocándonos en escenarios prácticos relevantes para organizaciones en LATAM que buscan maximizar la seguridad sin sacrificar la agilidad operativa.

¿Cómo funcionan los SCP? Conceptos clave

Antes de entrar en los patrones, es fundamental entender cómo se aplican los SCP en la estructura de AWS Organizations:

• Cuenta de gestión (Management account): La cuenta que crea la organización y desde donde se administran las políticas.
• Unidades Organizacionales (OUs): Grupos lógicos de cuentas donde puedes aplicar SCP de manera heredada.
• Herencia: Los SCP aplicados a una OU se heredan por todas las cuentas y OUs hijas.
• Evaluación: Para que una acción sea permitida, debe estar permitida por todos los SCP que afectan a la cuenta (desde la raíz hasta la cuenta específica). Un solo explícito deny en cualquier nivel bloquea la acción.
• Explicito deny vs allow: Los SCP solo pueden usar explícito deny o explícito allow. Por defecto, todo está denegado si no se permite explícitamente.

Patrón 1: Bloquear el uso del usuario root

El usuario root de una cuenta AWS tiene permisos ilimitados y no puede ser restringido por políticas de IAM. Sin embargo, los SCP sí pueden restringir sus acciones, lo que lo convierte en un control crítico de seguridad.

Este SCP impide que el usuario root realice casi cualquier acción, excepto aquellas necesarias para recuperación de cuenta (como cambiar la contraseña o acceder al soporte de AWS).

Ejemplo de SCP: Bloqueo del usuario root (excepto acciones de recuperación)

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllExceptRootRecovery",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalArn": "arn:aws:iam::*:root"
                }
            }
        },
        {
            "Sid": "AllowRootRecoveryActions",
            "Effect": "Allow",
            "Action": [
                "iam:ChangePassword",
                "iam:*AccessKey*",
                "iam:*LoginProfile*",
                "aws-portal:*",
                "support:*"
            ],
            "Resource": "*"
        }
    ]
}

Cuándo usarlo: Como línea de defensa básica en prácticamente todas las organizaciones. Especialmente importante en cuentas de producción o que contienen datos sensibles.
Consideraciones: Asegúrate de tener un procedimiento de break-glass establecido para emergencias donde se necesite usar el usuario root (aunque esto debería ser extremadamente raro).
Patrón 2: Restringir operaciones a regiones aprobadas
Muchas organizaciones tienen requisitos de residencia de datos o desean limitar el gasto a regiones específicas donde tienen acuerdos empresariales o donde operan principalmente. Este patrón deniega todas las acciones en regiones no aprobadas.
Ejemplo de SCP: Permitir solo regiones específicas (us-east-1, eu-west-1)
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyNonApprovedRegions",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "StringNotEquals": {
                    "aws:RequestedRegion": [
                        "us-east-1",
                        "eu-west-1"
                    ]
                }
            }
        }
    ]
}

Cuándo usarlo: Cuando necesitas cumplir con requisitos de soberanía de datos, reducir superficie de ataque o controlar costos limitando el uso a regiones específicas.
Alternativa: Si prefieres una lista de regiones denegadas (más corta), puedes usar StringEquals con Effect: Deny para las regiones que quieres bloquear explícitamente.

    
💡 Nota
    Algunos servicios globales como IAM, Route 53, CloudFront y WAF no respetan el parámetro aws:RequestedRegion. Para estos, necesitarás reglas adicionales o aceptar que operen desde cualquier región.

Patrón 3: Denegar servicios costosos o no autorizados
Para evitar sorpresas en la factura o cumplir con políticas de uso aceptable, puedes bloquear explícitamente ciertos servicios de AWS que son conocidos por generar altos costos o que no están autorizados para usar en tu organización.
Ejemplo de SCP: Bloquear instancias GPU y servicios de streaming de medios
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyExpensiveServices",
            "Effect": "Deny",
            "Action": [
                "ec2:RunInstances",
                "elasticmapreduce:RunJobFlow",
                "sagemaker:CreateTrainingJob",
                "sagemaker:CreateTransformJob",
                "kinesisvideo:CreateStream",
                "mediaconvert:CreateJob",
                "medialive:CreateChannel",
                "mediapackage:CreateChannel",
                "mediastore:CreateContainer"
            ],
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "ec2:InstanceType": [
                        "p*",
                        "g*",
                        "inf*"
                    ]
                }
            }
        }
    ]
}

Nota importante: El ejemplo anterior muestra cómo combinar múltiples acciones con condiciones específicas. Para bloquear completamente un servicio, a veces es más sencillo denegar todas sus acciones:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyBitcoinMining",
            "Effect": "Deny",
            "Action": "ec2:RunInstances",
            "Resource": "*",
            "Condition": {
                "StringLike": {
                    "ec2:InstanceType": "p*"
                }
            }
        },
        {
            "Sid": "DenyMediaServices",
            "Effect": "Deny",
            "Action": [
                "mediaconvert:*",
                "medialive:*",
                "mediapackage:*",
                "mediastore:*"
            ],
            "Resource": "*"
        }
    ]
}

Cuándo usarlo: Para controlar costos, cumplir con políticas internas de uso de tecnología o prevenir actividades no autorizadas como minería de criptomonedas.
Patrón 4: Prevenir la desactivación de servicios de seguridad críticos
Una táctica común de atacantes es desactivar los servicios de monitoreo y alerta (como CloudTrail, Config o GuardDuty) para operar sin ser detectados. Este patrón protege estos servicios críticos asegurando que no puedan ser deshabilitados o modificados.
Ejemplo de SCP: Proteger CloudTrail de ser detenido o eliminado
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ProtectCloudTrail",
            "Effect": "Deny",
            "Action": [
                "cloudtrail:DeleteTrail",
                "cloudtrail:StopLogging",
                "cloudtrail:UpdateTrail"
            ],
            "Resource": "*"
        }
    ]
}

Extensión para otros servicios: Puedes aplicar el mismo principio a AWS Config (config:Delete*, config:StopConfigurationRecorder), GuardDuty (guardduty:DeleteDetector, guardduty:StopMonitoringMembers) y Security Hub (securityhub:DisableStandards, securityhub:DisableImportFindingsForProduct).
Cuándo usarlo: En cualquier organización que valore la detección y respuesta a incidentes. Es particularmente valiente en entornos donde múltiples equipos tienen acceso administrativo.
Patrón 5: Exigir autenticación multifactor (MFA) para operaciones sensibles
Aunque IAM puede exigir MFA para usuarios específicos, los SCP permiten aplicar este requisito a nivel de organización, asegurando que incluso si alguien olvida configurar MFA en una cuenta, la política organizacional lo exigirá.
Ejemplo de SCP: Requerir MFA para eliminar buckets S3 o instancias EC2
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RequireMFAForDeletions",
            "Effect": "Deny",
            "Action": [
                "s3:DeleteBucket",
                "ec2:TerminateInstances",
                "rds:DeleteDBInstance",
                "iam:DeleteUser",
                "iam:DeleteRole"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

Cómo funciona: La condición aws:MultiFactorAuthPresent verifica si la solicitud fue autenticada con MFA. Si no lo está (false), la acción es denegada.
Cuándo usarlo: Para proteger operaciones destructivas o de alto impacto, asegurando que siempre requieran una segunda forma de autenticación.
Patrón 6: Lista de permitidos (Allowlist) de servicios aprobados
En lugar de denegar servicios específicos (lista de denegados), algunas organizaciones prefieren el enfoque más restrictivo de permitir únicamente un conjunto de servicios aprobados y denegar todo lo demás. Este enfoque ofrece mayor control pero requiere más mantenimiento.
Ejemplo de SCP: Permitir solo servicios de cómputo, almacenamiento y bases de datos básicos
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DenyAllByDefault",
            "Effect": "Deny",
            "Action": "*",
            "Resource": "*"
        },
        {
            "Sid": "AllowApprovedServices",
            "Effect": "Allow",
            "Action": [
                "s3:*",
                "ec2:*",
                "rds:*",
                "lambda:*",
                "dynamodb:*",
                "sns:*",
                "sqs:*",
                "cloudwatch:*",
                "logs:*",
                "iam:Get*",
                "iam:List*"
            ],
            "Resource": "*"
        }
    ]
}

Cuándo usarlo: En entornos altamente regulados donde se necesita un control estricto sobre qué servicios pueden usar los equipos, como en instituciones financieras o gubernamentales.
Advertencia: Este enfoque puede bloquear inesperadamente servicios que los equipos necesitan para tareas legítimas. Requiere un proceso claro para solicitar y aprobar nuevos servicios.

    
⚠️ Atención
    Al usar listas de permitidos, recuerda incluir acciones esenciales de IAM como iam:Get* y iam:List* para que los usuarios puedan ver sus propios permisos y credenciales sin necesidad de escalar a administradores. Olvidar esto genera llamadas de soporte innecesarias.

Mejores prácticas para diseñar e implementar SCP

    
Comienza con una estrategia de denegación mínima: Empezar con pocos SCP de alta impacto (como bloquear root o regiones no aprobadas) y añadir más gradualmente según necesites.
    
Utiliza los SCP administrados de AWS como base: AWS ofrece políticas administradas comunes que puedes adjuntar directamente (ej: FullAWSAccess, ReadOnlyAccess, políticas para PCI o HIPAA).
    
Prueba rigurosamente en OUs de no producción: Nunca apliques un SCP directamente a la raíz de la organización o a OUs productivas sin primero validarlo en un entorno de prueba con cuentas que imiten tu uso real.
    
Documenta claramente el propósito de cada SCP: Incluye en la descripción del SCP qué problema intenta resolver y qué exenciones pueden ser necesarias.
    
Implementa un procedimiento de exención: Define cómo los equipos pueden solicitar acceso temporal a servicios bloqueados para proyectos legítimos.
    
Monitorea los eventos de denegación: Usa CloudTrail para detectar cuando acciones sejam bloqueadas por SCP, lo que puede indicar tanto intentos maliciosos como necesidades legítimas no cubiertas.
    
Revisa y actualiza periódicamente: A medida que tu organización adopta nuevos servicios o cambia sus requisitos, revisa tus SCP para asegurar que sigan siendo relevantes y efectivos.

Bloque de código: Gestionar SCP con AWS CLI
A continuación, algunos ejemplos prácticos de cómo crear, listar y aplicar SCP usando la AWS CLI:
1. Crear un nuevo SCP desde un archivo JSON
aws organizations create-policy \
    --name "BlockRootUsage" \
    --description "Impide el uso del usuario root excepto para acciones de recuperación" \
    --type SERVICE_CONTROL_POLICY \
    --content file://block-root-scp.json

2. Listar todos los SCP en la organización
aws organizations list-policies --filter SERVICE_CONTROL_POLICY

3. Adjuntar un SCP a una Unidad Organizacional (OU)
aws organizations attach-policy \
    --policy-id p-example1234567890 \
    --target-id ou-example12345

4. Listar los objetivos (cuentas/OUs) a los que está adjuntado un SCP
aws organizations list-targets-for-policy --policy-id p-example1234567890

5. Vista previa del efecto de un SCP (sin aplicarlo)
aws organizations test-organizational-policy-service-access \
    --policy-id p-example1234567890 \
    --arn-to-test arn:aws:iam::123456789012:role/TestRole \
    --action-path ec2:DescribeInstances

Nota: El comando test-organizational-policy-service-access es invaluable para validar que tu SCP bloquea o permite las acciones esperadas antes de aplicarlo en producción.
Resultado esperado: lista de verificación de diseño de SCP efectivo
Antes de considerar un SCP listo para producción, verifica que cumple con estos criterios:

    
Objetivo claro: ¿Qué riesgo específico o requisito de gobernanza intenta abordar?
    
Prueba de impacto: ¿Has validado en un entorno de prueba que no bloquea operaciones legítimas esenciales?
    
Excepciones documentadas: ¿Está claro cuándo y cómo se pueden otorgar exenciones?
    
Mensajes de error claros: ¿Los usuarios recibirán mensajes de denegación que les ayuden a entender qué está bloqueado y por qué?
    
Alineación con estrategia general: ¿El SCP encaja dentro de tu modelo de gobernanza multi-cuenta y tus políticas de IAM existentes?
    
Revisión periódica programada: ¿Tienes un calendario para revisar el SCP cada trimestre o cada seis meses?

Conclusión
Las Service Control Policies (SCP) son una herramienta poderosa pero a menudo subutilizada para establecer una gobernanza de seguridad sólida en entornos multi-cuenta de AWS. Al aplicar patrones de diseño probados como el bloqueo del usuario root, la restricción de regiones aprobadas, la protección de servicios de seguridad críticos y la exigencia de MFA para operaciones sensibles, puedes crear guardrails que protejan a tu organización sin impedir la innovación y la agilidad operativa.
Recuerda que la efectividad de los SCP depende tanto de su diseño cuidadoso como de un proceso continuo de prueba, monitoreo y ajuste. Comienza con políticas de alto impacto y bajo riesgo de interferir con operaciones legítimas, valida exhaustivamente en entornos de no producción, y gradualmente construye tu conjunto de SCP según las necesidades específicas de tu organización.
Con un enfoque estratégico en SCP, no solo estarás cumpliendo con requisitos de seguridad y cumplimiento, sino que estarás construyendo una base para una adopção de la nube verdaderamente segura y escalable — un diferenciador clave para cualquier profesional de AWS que aspire a liderar en el espacio de la seguridad en la nube, especialmente en entornos de LATAM donde los recursos pueden ser limitados pero la necesidad de gobernanza es tan crítica como en cualquier otra parte del mundo.