Cuando una organización empieza a crecer en AWS, los mayores riesgos no suelen ser solo ataques externos, sino configuraciones incorrectas, uso indebido de privilegios y explosiones de costos.
Para mitigar esos riesgos, AWS Organizations ofrece una herramienta clave: Service Control Policies (SCPs).

Además, las SCPs juegan un rol fundamental dentro del AWS Cloud Adoption Framework (CAF), específicamente en el dominio de Seguridad, ayudando a implementar gobierno, control preventivo y seguridad por diseño.

---

¿Qué son las SCP (Service Control Policies)?

Las Service Control Policies permiten definir guardrails obligatorios que determinan qué acciones pueden o no ejecutarse dentro de una cuenta de AWS, sin importar los permisos IAM configurados.

✅ Se aplican a nivel Organización / OU / Cuenta
✅ No otorgan permisos, solo los restringen
✅ Afectan a usuarios, roles y root
✅ Son evaluadas antes que IAM

Concepto clave:

Una SCP define el límite máximo de lo que una cuenta puede hacer.

---

Relación entre SCPs e IAM

El modelo mental correcto es:

SCP (Organizations)
   ↓
IAM Policies (Account)
   ↓
Permiso final efectivo

Aunque una IAM policy permita una acción, si la SCP la niega, la acción jamás se ejecuta.

---

SCPs y el AWS Cloud Adoption Framework (CAF)

Dentro del AWS CAF, las SCPs impactan directamente en el pilar de Seguridad, principalmente en:

• Preventive Controls

• Identity and Access Management

• Governance

• Cost Control (shared responsibility)

Las SCPs permiten aplicar controles preventivos, evitando incidentes antes de que ocurran, en lugar de detectarlos después.

---

🧱 SCP #1 — Identity Guardrails

🏷️ Name

identity-guardrails

📝 Description

Prevent IAM users and access keys creation. Enforce IAM Identity Center usage.

🎯 Objetivo

Forzar un modelo moderno y seguro de identidad:

• ❌ No más usuarios IAM

• ❌ No más access keys permanentes

• ✅ Solo IAM Identity Center (SSO) y roles temporales

---

📄 Policy (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyIAMUserAndAccessKeyManagement",
      "Effect": "Deny",
      "Action": [
        "iam:CreateUser",
        "iam:DeleteUser",
        "iam:CreateAccessKey",
        "iam:UpdateAccessKey",
        "iam:DeleteAccessKey"
      ],
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Identity & Access Management

• Least Privilege

• Preventive Controls

---

🧱 SCP #2 — Region Guardrails

🏷️ Name

region-guardrails

📝 Description

Restrict AWS usage to approved regions only.

🎯 Objetivo

Evitar:

• Recursos creados en regiones no aprobadas

• Costos inesperados

• Problemas de compliance

---

✅ Solo us-east-1 permitido

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyAllRegionsExceptUSEast1",
      "Effect": "Deny",
      "NotAction": [
        "account:*",
        "billing:*",
        "iam:*",
        "organizations:*",
        "support:*"
      ],
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      },
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Governance

• Compliance

• Data residency controls

---

🧱 SCP #3 — Root Guardrails

🏷️ Name

root-guardrails

📝 Description

Deny root account usage except for billing and support operations.

🎯 Objetivo

Eliminar el uso operativo del usuario root.

---

📄 Policy (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyRootAccountUsage",
      "Effect": "Deny",
      "Condition": {
        "StringLike": {
          "aws:PrincipalArn": "arn:aws:iam::*:root"
        }
      },
      "NotAction": [
        "account:*",
        "billing:*",
        "payments:*",
        "support:*",
        "tax:*"
      ],
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Account Protection

• Identity Hardening

• Blast Radius Reduction

---

🧱 SCP #4 — Cost Explosion Prevention ✅

🏷️ Name

cost-explosion-prevention

📝 Description

Prevent cost explosions by blocking high-cost EC2 instances, uncontrolled Auto Scaling, and Lambda functions without concurrency limits.

---

📄 Policy (JSON)

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyHighCostEC2InstanceTypes",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Condition": {
        "ForAnyValue:StringLike": {
          "ec2:InstanceType": [
            "p*",
            "g*",
            "inf*",
            "trn*",
            "hpc*"
          ]
        }
      },
      "Resource": "*"
    },
    {
      "Sid": "LimitAutoScalingCapacity",
      "Effect": "Deny",
      "Action": [
        "autoscaling:SetDesiredCapacity",
        "autoscaling:UpdateAutoScalingGroup"
      ],
      "Condition": {
        "NumericGreaterThan": {
          "autoscaling:DesiredCapacity": "5"
        }
      },
      "Resource": "*"
    },
    {
      "Sid": "RequireLambdaConcurrencyLimit",
      "Effect": "Deny",
      "Action": [
        "lambda:CreateFunction",
        "lambda:UpdateFunctionConfiguration"
      ],
      "Condition": {
        "Null": {
          "lambda:ReservedConcurrentExecutions": "true"
        }
      },
      "Resource": "*"
    }
  ]
}

✅ Alineación CAF – Seguridad

• Financial Governance

• Preventive Technical Controls

• Shared Responsibility (Security & Cost)

---

¿Dónde aplicar estas SCPs?

📸 (ACÁ PONER CAPTURA — Organizational Units con SCPs asociadas)

Ejemplo recomendado:

Root OU
 ├─ Security
 ├─ Shared-Services
 ├─ Production
 └─ Sandbox

---

Conclusión

Las Service Control Policies no solo refuerzan la seguridad técnica, sino que también:

• ✅ Alinean la cuenta con el AWS CAF

• ✅ Implementan controles preventivos reales

• ✅ Reducen riesgos técnicos y financieros

• ✅ Profesionalizan el gobierno de AWS

En AWS, la seguridad madura empieza por los guardrails.