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:StartInstancesyec2:StopInstancesen 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:PutObjecta 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:RunInstancesen cualquier región que no seaus-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.
Top comments (0)