☁️ Introducción
En cualquier arquitectura Cloud moderna, la seguridad no comienza en la red… comienza en la identidad.
¿Quién puede acceder?
¿Qué puede hacer?
¿Desde dónde?
Aquí es donde entra en juego IAM (Identity and Access Management), uno de los componentes más críticos y a la vez más subestimados en la nube.
Tanto AWS como GCP ofrecen modelos robustos de IAM, pero con enfoques radicalmente distintos. Y no entender estas diferencias no solo genera problemas de seguridad… puede romper completamente tu arquitectura.
📌 Preámbulo
IAM no es solo gestión de usuarios. Es el motor de control de acceso que define cómo interactúan servicios, aplicaciones y personas dentro de tu entorno Cloud.
Aunque AWS y GCP tienen el mismo objetivo, su forma de implementarlo cambia:
AWS → enfoque granular, distribuido y altamente flexible
GCP → enfoque centralizado, jerárquico y basado en identidad
El mayor error no es técnico, es cognitivo:
al diseñar IAM con el modelo mental equivocado para la nube que estás usando.
Entender esto es clave para diseñar arquitecturas seguras y escalables.
🔐 ¿Qué es IAM?
IAM (Identity and Access Management) permite definir:
- Quién (usuarios, servicios, aplicaciones).
- Puede hacer qué (permisos).
- Sobre qué recursos.
Es, en esencia, el equivalente a los controles de acceso en un data center tradicional, pero llevado a escala Cloud.
🔶 IAM en AWS: Granularidad extrema y control total
AWS adopta un modelo muy flexible, pero también más complejo.
🔍 ¿Cómo funciona IAM en AWS?
No existe jerarquía de recursos como tal (como en GCP)
Todo gira en torno a:
- Usuarios.
- Roles.
- Políticas (Policies).
Las políticas son documentos JSON donde defines permisos de forma explícita.
👉 Ejemplo conceptual:
“Permitir acceso S3 solo a este bucket, desde esta IP, en este horario”
⭐ Ventajas de AWS IAM
- Granularidad extrema: puedes controlar permisos a nivel muy fino.
- Flexibilidad total: múltiples formas de asignar permisos.
- Condiciones avanzadas: IP, tags, tiempo, MFA, etc.
- Madurez: uno de los sistemas más completos del mercado.
⚠️ Riesgos comunes en AWS
- Complejidad alta → fácil cometer errores.
- Políticas difíciles de mantener a escala.
- Over-permissioning (más permisos de los necesarios).
- Difícil trazabilidad en entornos grandes.
🔧 Ideal para:
- Entornos altamente regulados
- Casos donde necesitas control detallado
- Arquitecturas complejas con múltiples excepciones
🔵 IAM en GCP: Simplicidad, jerarquía y modelo basado en identidad
Google adopta un enfoque completamente distinto: todo está organizado jerárquicamente.
🔍 ¿Cómo funciona IAM en GCP?
Estructura jerárquica:
Organización
└── Folder
└── Proyecto
└── Recursos
Los permisos se asignan mediante:
- Roles (predefinidos o custom).
- Bindings (quién tiene ese rol).
👉 Y lo más importante:
- Los permisos se heredan automáticamente hacia abajo.
⭐ Ventajas de GCP IAM
- Modelo más simple e intuitivo.
- Herencia automática de permisos.
- Menor esfuerzo operativo.
- Integración fuerte con identidades (service accounts).
⚠️ Riesgos comunes en GCP
- Exceso de permisos por herencia mal diseñada.
- Menor granularidad en algunos casos.
- Difícil segmentación si no se diseña bien la jerarquía.
- Dependencia fuerte del diseño organizacional.
🔧 Ideal para:
- Organizaciones que priorizan simplicidad.
- Equipos que quieren escalar rápido.
- Entornos con gobierno centralizado.
“La diferencia no está solo en cómo configuras permisos… sino en cómo piensas la arquitectura desde el inicio.”
🚨 Diferencias que rompen arquitecturas
Ejemplo real:
Una organización migra desde AWS a GCP.
En AWS:
- Cada cuenta tenía roles específicos.
- Permisos explícitos por aplicación.
- Nada se heredaba automáticamente.
En GCP:
- Se crea una Organización y un Proyecto único.
- Se asigna Owner a un grupo “plataforma”.
Resultado:
- Servicios internos acceden a recursos productivos sin intención.
- Equipos de dev tienen permisos que nunca tuvieron en AWS.
- Auditoría fallida por exceso de privilegios.
El problema no fue GCP.
Fue migrar el modelo mental de AWS sin rediseñar la jerarquía.
Aquí está lo realmente importante 👇
1. Herencia vs control explícito
En AWS: nada se hereda automáticamente.
En GCP: TODO puede heredarse.
👉 Error típico:
Migrar sin rediseñar → permisos excesivos o insuficientes
2. Roles vs Policies
AWS: defines permisos muy específicos.
GCP: trabajas más con roles predefinidos.
👉 Impacto:
Diseños pensados para AWS pueden no encajar bien en GCP
3. Service Accounts vs Roles
AWS: uso intensivo de roles (STS).
GCP: service accounts como identidad principal.
👉 Error común:
No adaptar autenticación entre servicios → fallos de integración.
4. Gobierno organizacional
AWS: más descentralizado.
GCP: depende fuertemente de la jerarquía.
👉 **Impacto:**
Un mal diseño inicial en GCP afecta TODO el sistema.
🤝 ¿En qué coinciden AWS y GCP IAM?
- Ambos implementan principio de menor privilegio.
- Ambos permiten identidades de servicio bien definidas.
- Ambos fallan cuando: - No hay gobierno. - No hay automatización (IaC). - Se improvisa en producción.
🎯 IAM no falla solo… falla cuando la arquitectura falla.
🧭 ¿Cuál elegir?
Depende de tu enfoque como arquitecto:
✔ Si necesitas control absoluto → AWS
Ideal para entornos complejos y altamente regulados.
✔ Si buscas simplicidad y escalabilidad → GCP
Perfecto para organizaciones modernas y ágiles.
🏁 Conclusión
IAM no es solo un componente más… es la base de la seguridad en la nube.
AWS te da control total, pero exige mayor madurez operativa.
GCP simplifica la gestión, pero requiere buen diseño jerárquico.
La clave no es cuál es mejor, sino:
Cuál se alinea mejor con tu modelo operativo y tu arquitectura.
Porque en Cloud, una mala decisión en IAM no solo genera riesgos…
puede romper toda tu plataforma.
Happy learning on AWS & GCP 🔥
Top comments (0)