Análisis profundo de AWS IAM: guía práctica de diseño de permisos y Zero Trust, comparado con GCP IAM y Azure AD / Entra ID

Introducción (resumen de ideas clave)

En esta guía veremos AWS Identity and Access Management (IAM) y lo compararemos con GCP IAM (Cloud IAM) y Azure AD / Microsoft Entra ID + Azure RBAC para construir un modelo mental sólido sobre “usuarios, permisos y autenticación en la nube”.

Resumen en una frase:

• AWS – Un motor de autorización basado en JSON que combina usuarios IAM, roles, políticas y SCPs.
• GCP – Un modelo basado en roles (Cloud IAM) usando principal + role + resource más Org Policy como carriles de seguridad.
• Azure – Entra ID para identidad, con Azure RBAC / Azure Policy para vincular de forma estricta identidades y recursos.

En las tres nubes, el juego real está en diseñar:

1. Una separación limpia entre usuarios humanos y sistemas.
2. Un modelo centrado en roles donde se conceden permisos temporales vía roles, no claves de larga duración.
3. Reglas operativas que mantengan privilegios mínimos (least privilege) con el paso del tiempo.
4. Carriles de seguridad en niveles superiores (organizaciones, carpetas, management groups) pensando en multi-cuenta / multi-cloud.
5. Una postura arquitectónica que pase de “redes protegidas” a “identidades protegidas” (pensamiento Zero Trust).

Esta guía está pensada para:

• Equipos de TI / infraestructura corporativa que migran a la nube
• Desarrolladores de SaaS / aplicaciones de negocio
• SREs y equipos de plataforma / infraestructura
• Equipos de seguridad / gobernanza
• Tech leads / CTOs de startups

Al final deberías tener un “marco mental de diseño de permisos” reutilizable que empieza en AWS IAM pero se transfiere directamente a GCP IAM y Azure AD / Entra ID + Azure RBAC.

1. Qué hace realmente IAM: roles y fronteras de responsabilidad

Dicho de forma laxa, IAM es el servicio donde defines “quién puede hacer qué, sobre qué recurso”.

• Quién (Principal) – Personas, apps, microservicios, jobs batch, otras nubes, partners…
• Qué (Resource) – Buckets S3, instancias EC2, RDS, Lambda, VPC, CloudWatch: cualquier recurso AWS.
• Hasta dónde (Action / Scope) – Solo s3:GetObject, solo ec2:Describe*, denegar rds:*, etc., a nivel de acciones de API.

IAM expresa estas reglas con políticas JSON (sentencias allow/deny) y las evalúa en cada petición para decidir “Allow” (permitir) o “Deny” (denegar).

1.1 Mapeo rápido de componentes

AWS IAM

• Identidades: usuarios IAM, roles IAM, grupos IAM
• Políticas: políticas administradas por AWS, administradas por el cliente, políticas inline, SCPs, permission boundaries

GCP IAM (Cloud IAM)

• principal (usuario / service account) + role (asignado al principal) + resource

Azure (Entra ID + Azure RBAC)

• Identidades: usuarios, service principals, managed identities
• Permisos: roles (integrados / personalizados) asignados a un scope (suscripción / resource group / recurso)

En las tres nubes, terminas combinando:

Principal + Rol/Política + Recurso

La sintaxis cambia, pero el modelo conceptual es el mismo.

2. Separar personas, sistemas e identidades externas

El primer paso en el diseño de IAM es listar “quién toca realmente la nube”.

2.1 Identidades humanas

Perfiles típicos:

• Administradores (equipos de plataforma / seguridad)
• Desarrolladores (app, datos, ML, etc.)
• Operadores (monitorización, NOC / operaciones)
• Ejecutivos / auditores (solo lectura, paneles, exportaciones)

En AWS, el patrón recomendado no es “iniciar sesión con usuarios IAM”, sino:

IdP externo + roles IAM

Ejemplo:

• Gestionar empleados en Entra ID / Okta / Google Workspace
• Usar SSO hacia AWS
• Los usuarios luego asumen roles IAM vía consola o CLI

Flujo similar en cada nube:

• GCP – Los usuarios en Cloud Identity / Workspace entran en la consola; los roles de Cloud IAM otorgan permisos a nivel de proyecto/carpeta/org.
• Azure – Los usuarios en Entra ID entran en el portal; los roles de Azure RBAC dan acceso a nivel de suscripción / resource group / recurso.

2.2 Identidades de sistema

Los actores no humanos también necesitan identidades y permisos:

• Aplicaciones (APIs desde EC2, cargas ECS/EKS, funciones Lambda)
• Jobs batch / ETL
• Clientes en otras nubes o on-prem que hablan con AWS
• Plataformas SaaS que acceden a tu entorno AWS

En AWS, casi siempre se expresan como roles IAM:

• EC2 – instance profiles (roles)
• ECS/EKS – roles de tarea o de pod
• Lambda – roles de ejecución

Vinculas “qué programa usa qué rol” en el despliegue.

Conceptos análogos:

• GCP – service accounts
• Azure – service principals y managed identities

2.3 Identidades externas (federación)

Fuentes externas de identidad incluyen:

• Tu IdP corporativo
• Organizaciones partner
• SaaS de terceros

Se federan mediante SAML / OIDC / web identity federation / IAM Identity Center (AWS SSO) hacia credenciales temporales de rol:

Identidad externa → credenciales temporales emitidas por STS → rol IAM

Así evitas mantener secretos estáticos de larga duración en AWS.

3. Leer y escribir políticas: familiarizarse con JSON

En esencia, una política IAM es:

SI se cumplen ciertas condiciones, ENTONCES Allow / Deny acciones específicas sobre recursos específicos.

3.1 El ejemplo más simple

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": ["arn:aws:s3:::my-bucket/*"]
    }
  ]
}

Bloques clave:

• Effect – Allow o Deny
• Action – acciones de API (con comodines como s3:* si hace falta)
• Resource – ARNs de los recursos a los que aplica la regla

Modelo mental de evaluación:

1. Todo empieza como “Implicit Deny”.
2. Si alguna política aplicable dice Allow, la petición pasa a ser potencialmente permitida.
3. Si alguna política dice Deny, el resultado final es Deny gana.

GCP IAM:

• Vinculas roles como roles/storage.objectViewer a un principal en un resource (proyecto/carpeta/org).
• La evaluación es similar: permiso efectivo = unión de roles, restringida por Org Policies / denies.

Azure RBAC:

• Asignas roles a identidades en distintos scopes (management group / suscripción / resource group / recurso).
• Los denies / policies en scopes superiores limitan lo que finalmente puede permitirse.

3.2 Políticas de identidad, de recurso, SCPs y permission boundaries (AWS)

AWS tiene cuatro tipos de políticas, cada una para un propósito distinto:

1. Identity-based policies

   • Adjuntas a usuarios, roles o grupos IAM.
   • Son las que más redactas y revisas.

2. Resource-based policies

   • Adjuntas directamente al recurso (políticas de bucket S3, colas SQS, claves KMS, etc.).
   • Muy usadas para acceso entre cuentas y para exponer recursos selectivamente.

3. SCP (Service Control Policy)

   • Parte de AWS Organizations.
   • Define un límite máximo de permisos para cuentas u OUs.
   • Ej.: “No iam:* en esta OU” o “No usar regiones fuera de eu-west-* en esta OU”.
   • Se parecen a GCP Org Policy o a Azure Policy con denies a nivel de management group.

4. Permission boundaries

   • Límite superior por identidad: “Este usuario/rol nunca puede recibir más que X”.

Juntas te dan carriles de seguridad multinivel:

• Permisos del día a día – identity-based policies
• Cómo se exponen recursos compartidos – resource-based policies
• Reglas de seguridad a nivel organización – SCPs / org policies
• Topes duros por usuario – permission boundaries

4. Patrones de diseño prácticos: roles, privilegios mínimos y credenciales temporales

Veamos patrones que realmente usarás.

4.1 Roles de Admin, Developer y Read-Only

En entornos con varias cuentas, estandarizar nombres de roles y conjuntos de permisos simplifica muchísimo las operaciones.

Distribución típica:

• OrganizationAdminRole

  • Muy potente; puede gestionar cuentas / org / SCPs.
  • Restringido a muy pocas personas con controles estrictos.

• PlatformAdminRole

  • Gestiona infraestructura compartida: VPCs, IAM, CloudWatch, servicios de seguridad.

• AppDeveloperRole

  • Gestiona EC2/ECS/EKS/Lambda/S3/etc. dentro de su proyecto.
  • Sin poderes sobre IAM / org / billing / guardrails de seguridad.

• ReadOnlyRole

  • Acceso de solo lectura a toda la organización para investigación, auditoría y troubleshooting.

En GCP, idealmente no dependes solo de roles/owner, roles/editor, roles/viewer. Defines roles personalizados con alcances similares.

En Azure, igual: vas más allá de Owner, Contributor, Reader y defines roles personalizados por perfil de trabajo.

4.2 Personas vía IdP → roles; sistemas vía roles → servicios

Patrón:

• Personas

  • Autenticación en el IdP (Entra ID / Okta / Workspace / etc.).
  • Usan AWS IAM Identity Center como punto de entrada SSO.
  • Eligen / asumen roles por cuenta (admin, dev, read-only).

• Sistemas

  • EC2/ECS/EKS/Lambda configurados con roles de ejecución.
  • El código nunca ve claves de larga duración; usa credenciales temporales STS vía metadata de instancia, tokens de identidad, etc.

Principio clave:

Evita claves de acceso de larga duración para personas y hosts.
Empuja todo hacia credenciales temporales basadas en roles.

Eso es comportamiento fundamental de Zero Trust.

4.3 Ejemplo: política de rol de solo lectura

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescribeAndList",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "rds:Describe*",
        "s3:ListAllMyBuckets",
        "s3:ListBucket",
        "cloudwatch:Describe*",
        "cloudwatch:Get*",
        "cloudwatch:List*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "S3ReadOnlyLogs",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-org-logs-*/*"
    }
  ]
}

Adjunta esto a un rol dedicado de auditoría/investigación y tendrás una manera segura de inspeccionar infraestructura sin riesgo de cambios accidentales.

5. IAM en un mundo multi-cuenta y multi-cloud

5.1 Multi-cuenta (AWS Organizations)

En AWS, el patrón estándar es:

• Usar AWS Organizations para agrupar cuentas.
• Usar OUs (organizational units) para estructurarlas lógicamente.
• Aplicar SCPs a las OUs.
• Armonizar los roles IAM entre cuentas.

Ejemplo de estructura de OUs:

• OU security – cuenta de logging central, cuentas para herramientas de seguridad.
• OU shared-services – VPC compartida, IAM Identity Center, etc.
• OU workloads – cuentas de prod / staging / dev para aplicaciones.

El equivalente en GCP es Organization → Folder → Project.
En Azure es Tenant (Entra ID) → Management Group → Subscription → Resource Group.

5.2 Estrategia de identidad para multi-cloud

Meta: una única fuente de verdad para identidades humanas (por ej., Entra ID).

Patrón:

• Coloca todas las identidades humanas en un IdP.
• Cada nube confía en ese IdP y mapea grupos/claims del IdP a roles/asignaciones de rol.
• MFA, políticas de contraseña, acceso condicional y ciclo de vida (altas/bajas/cambios) viven en el IdP.

Beneficios:

• En alta o baja de personal, los cambios en el IdP se propagan a todas las nubes.
• Gobernanza, auditoría y certificación pueden señalar un solo sitio como fuente de identidades.

6. Zero Trust e IAM: proteger por “quién” en lugar de “desde dónde”

Pensamiento legado: “Dentro de la red es seguro, fuera es peligroso”.

Pensamiento Zero Trust:

1. No hay un “dentro” totalmente seguro: trata cada petición como no confiable.
2. Para cada acceso, verifica quién pide, a qué recurso, bajo qué condiciones.
3. Por defecto, privilegios mínimos, tokens de corta duración y MFA.
4. Centraliza y monitoriza logs para detectar y responder rápido a comportamientos anómalos.

AWS IAM apoya este modelo con:

• Roles IAM + tokens STS (de corta duración)
• IAM Identity Center integrado con IdPs
• Condiciones de política (por ejemplo aws:MultiFactorAuthPresent == true)

Puedes escribir políticas como:

“Permite esta operación de alto riesgo solo cuando la petición tenga MFA válido y cumpla determinadas condiciones de dispositivo o red”.

GCP y Azure permiten enfoques similares combinando roles IAM con acceso condicional, estado de dispositivo y otras señales.

7. Cómo las operaciones pueden reforzar o romper IAM

7.1 Reglas de casa que escalan

Reglas concretas que puedes adoptar como estándar:

• No entregues claves de acceso AWS a usuarios humanos por defecto.
• Si tienes que emitir claves, documenta políticas de emisión y rotación (caducidad, frecuencia de rotación, almacenamiento).
• Los roles de admin deben exigir MFA y tener duraciones de sesión cortas.
• Minimiza el uso de la política administrada AdministratorAccess; resérvala para muy pocos roles fuertemente controlados.
• Para cada proyecto, ofrece un trío estándar de roles: Ops, Dev, Read-Only.
• Divide las políticas IAM por servicio/función (p. ej. políticas solo S3, solo EC2) en lugar de un enorme “catch-all”.

7.2 Checklist de diseño (decisiones de la primera semana)

1. Fuente de verdad de identidades – Entra ID / Google Workspace / AD on-prem / etc.
2. Estructura de cuentas – AWS Organizations / estructura de organización GCP / management groups y suscripciones en Azure.
3. Convención de nombres – para roles y políticas, por ej. {org}-{env}-{rol-uso}.
4. Conjuntos estándar de roles – Admin / Developer / Read-Only / Automation / Audit.
5. Gestión de secretos de larga duración – políticas para claves de acceso, claves de service account, client secrets.
6. MFA y políticas de contraseñas – quién debe tener MFA y con qué nivel de garantía.
7. Carriles de seguridad a nivel organización – SCPs, GCP Org Policies, Azure Policies.
8. Logs de auditoría – agregación, retención y alertas de CloudTrail, Cloud Logging, Azure Activity Logs.
9. Cadencia de revisión de acceso – revisión periódica (ej., trimestral) de roles y memberships.
10. Runbooks – cómo responder a errores de acceso, cómo otorgar y revocar acceso elevado de emergencia.

8. Casos de uso: tres escenarios reales frecuentes

8.1 Startup pequeña, mayormente en AWS

Contexto

• Equipo pequeño, AWS como nube principal; algo de uso de GCP/Azure empezando a aparecer.

Acciones

• Elegir Entra ID o Google Workspace como IdP; SSO hacia AWS con IAM Identity Center.
• Definir solo tres roles en AWS: Admin / Dev / ReadOnly.
• Permitir claves de acceso de larga duración solo para CI o integraciones específicas, almacenadas en Secrets Manager.

Resultado

• Al incorporar o dar de baja personas, tocas el IdP y su acceso a todas las nubes se ajusta automáticamente.
• Obtienes un diseño de permisos ligero pero seguro que aguanta el crecimiento.

8.2 Gran empresa, muchas cuentas

Contexto

• Varios departamentos, muchas cuentas AWS, además de GCP y Azure por división.

Acciones

• Usar AWS Organizations con OUs para security, shared-services, workloads.
• Aplicar SCPs para imponer reglas como “sin logins con root”, “no detener CloudTrail”, “solo regiones aprobadas”, etc.
• Centralizar identidad en Entra ID y conectar GCP, Azure y AWS para SSO.

Resultado

• Cada departamento puede ir a su ritmo mientras siguen vigentes reglas y monitorización globales.
• En respuesta a incidentes, puedes responder a “quién hizo qué, dónde y cuándo” en todas las nubes.

8.3 SaaS multi-tenant en AWS

Contexto

• Una plataforma SaaS aloja múltiples tenants en una sola cuenta AWS.

Acciones

• No crees un rol IAM por tenant: no escala.
• Implementa control de acceso por tenant en la aplicación, usando IDs de tenant.
• Da a la app un rol IAM mínimo limitado a sus prefijos S3, tablas, colas, etc.

Resultado

• IAM se mantiene relativamente simple; el aislamiento entre tenants se impone en la capa de aplicación.
• Al expandirte a GCP/Azure, puedes reutilizar el mismo modelo de tenancy a nivel de app.

9. Resultados objetivo por tipo de lector

9.1 TI / Gobernanza / Infra corporativa

Meta

• Una plataforma de identidad unificada para empleados, contratistas y partners, con políticas consistentes en todas las nubes.

Qué sacas de aquí

• Una comprensión cross-cloud de AWS IAM, GCP IAM y Azure RBAC.
• Guía concreta sobre qué gobernar de forma centralizada y qué delegar.

9.2 Desarrolladores, SREs, ingenieros de infraestructura

Meta

• Que al lanzar un nuevo servicio, empieces instintivamente por el diseño de roles, no por “dame admin”.

Qué sacas de aquí

• El patrón “Personas vía IdP + roles; sistemas vía roles + credenciales temporales”.
• Ejemplos de políticas que puedes adaptar directamente a tu proyecto.

9.3 Equipos de seguridad y auditoría

Meta

• Responder con confianza a “Quién tenía qué, cuándo y dónde” ante cualquier incidente.

Qué sacas de aquí

• Una visión de SCPs, permission boundaries, logs y revisiones de acceso.
• Un camino hacia Zero Trust / Zero Standing Privilege (nadie posee poderes de admin permanentes).

9.4 CTOs y tech leads de startups

Meta

• Incluso con un equipo mínimo, montar un control de acceso “serio” desde el día uno para que no se rompa al escalar.

Qué sacas de aquí

• Un kit inicial minimalista pero robusto:
  • Roles estándar
  • SSO basado en IdP
  • MFA
  • Logs centralizados
  • Guardrails a nivel organización

10. Tres cosas que puedes hacer hoy mismo

1. Lista todas las identidades “humanas” y “de sistema”

   • Admins, devs, operadores, jobs batch, apps, SaaS externos, etc.

2. Declara el principio:

   • Personas = IdP + rol
   • Sistemas = solo rol
   • Ir eliminando la entrega de claves de acceso siempre que sea posible.

3. Define un conjunto mínimo de roles estándar

   • Empieza con Admin / Developer / ReadOnly.
   • Implémentalos como políticas personalizadas y comparte las definiciones con tu equipo.

11. Conclusión: IAM es la base bajo cada servicio cloud

IAM puede parecer poco “emocionante” en la lista de servicios, pero en realidad sostiene todos los demás servicios de AWS:

• S3 / EC2 / RDS / Lambda
• VPC / CloudFront
• CloudWatch / herramientas de seguridad
• Y todo lo que despliegues.

Diseñar con cuidado “Quién, Qué, Hasta dónde” implica que:

• Las identidades humanas están centralizadas en el IdP, con permisos concedidos vía roles.
• Los sistemas reciben solo roles y credenciales temporales.
• Los carriles de seguridad a nivel organización (SCP/Policy) limitan lo posible incluso si alguien configura mal un rol.
• Los logs y las revisiones periódicas forman un chequeo continuo de la salud de tus permisos.

Una vez que tengas este bucle en marcha, tu nube puede crecer en escala y abarcar varios proveedores mientras tu modelo mental sigue siendo el mismo.

En temas posteriores, tiene sentido pasar a servicios estrechamente relacionados como AWS Organizations (gestión de cuentas y SCPs) o capas más cercanas a la aplicación como Amazon ECS/EKS —de nuevo comparándolos con GCP (GKE/Cloud Run) y Azure (AKS/App Service).

Paso a paso, estarás construyendo no solo servicios sueltos, sino una base cloud resistente y segura que es mucho más difícil de romper por accidente.