Los cinco dominios de IAM

Por qué dividir IAM en cinco dominios

En los artículos anteriores te encontraste con AM, IGA, PAM, CIAM e ITDR varias veces, casi siempre de pasada. Ahora toca abrirlos uno por uno. La razón es práctica: en el mercado real las plataformas y los equipos están organizados así. Cuando una empresa publica una vacante de “ingeniero IAM”, la descripción muy probablemente menciona uno o dos de estos dominios, no los cinco. Cuando un consultor vende un proyecto, el alcance se define en estos términos. Y cuando una herramienta dice ser “líder Gartner”, aclara siempre en cuál cuadrante.

Si no manejas esta partición vas a confundir conversaciones. Vas a hablar de “MFA” cuando el problema es de “certificación”, o de “cuentas privilegiadas” cuando lo que se necesita es “detección de fraude”. Cada dominio resuelve preguntas diferentes con herramientas y vocabulario propios.

Una analogía útil antes de entrar al detalle: piensa en una empresa como un edificio con varias zonas. AM son los vigilantes de la puerta principal — verifican credenciales y dan acceso. IGA es el departamento administrativo que mantiene la lista de quiénes pueden entrar y revisa que esa lista esté correcta. PAM son los vigilantes especializados de las áreas restringidas (servidores, salas de máquinas) con sus propios protocolos. CIAM es el equipo de recepción para visitantes y clientes externos. ITDR son las cámaras y sensores que vigilan a todos en tiempo real y disparan alarmas cuando ven algo raro.

Vista general: el mapa de los cinco dominios

Antes de entrar a cada uno, mira el mapa. Los cinco dominios giran alrededor de la identidad como concepto central que ya cubrimos en artículos anteriores. Cada uno aborda una dimensión distinta de cómo se gestiona esa identidad.

flowchart TB
  accTitle: Mapa de los cinco dominios de IAM
  accDescr: La identidad es el nodo central con aristas dirigidas hacia cinco dominios hijos: Access Management, Identity Governance, Privileged Access, Customer IAM e Identity Threat Detection.
  ID([Identidad])
  AM[Access Management<br/>La puerta de entrada]
  IGA[Identity Governance<br/>El guardián]
  PAM[Privileged Access<br/>La caja fuerte]
  CIAM[Customer IAM<br/>La cara al cliente]
  ITDR[Identity Threat<br/>El centinela]
  ID --> AM
  ID --> IGA
  ID --> PAM
  ID --> CIAM
  ID --> ITDR

No son cinco productos distintos del mismo problema; son cinco preguntas distintas sobre el mismo sujeto.

Resumen comparativo en una tabla

Con este mapa en mente, vamos a cada dominio uno por uno.

1. Access Management (AM): la puerta de entrada

Qué hace AM

Access Management es el dominio que responde a la pregunta más básica: ¿esta identidad puede entrar?. Cuando abres tu app de banco, escribes usuario y contraseña, te piden segundo factor y entras — todo eso es AM en acción. Es la cara visible de IAM, la que cualquier usuario percibe a diario.

Las capacidades core son cuatro:

• Autenticación: validar la identidad con uno o más factores (contraseña, OTP, passkey, biometría).
• Single Sign-On (SSO): una sola autenticación da acceso a múltiples apps relacionadas.
• Federación: confiar en el IdP de otra organización (típicamente vía SAML u OIDC) para autenticar usuarios externos.
• Sesiones: gestionar cuánto dura la sesión, cuándo expira, cómo se revoca.

Quién lo usa

AM aplica a toda identidad humana o de máquina que se autentica. Empleados que entran al ERP, clientes que entran a la app móvil, microservicios que llaman a APIs internas. Si hay un login involucrado, AM está ahí.

Ejemplo concreto

David, contador de una mediana empresa, llega un lunes a las 8 AM. Abre Microsoft 365 desde su laptop corporativa. El IdP de la empresa (Microsoft Entra ID) le pide su contraseña, después le pide aprobar una notificación push en su celular. Una vez dentro, en los siguientes 90 minutos abre Salesforce, SAP y un dashboard interno de BI sin volver a autenticarse — todos están conectados al mismo IdP vía SSO. A las 17:30 cierra sesión y la cookie de sesión se invalida en todas las apps al mismo tiempo.

Eso es AM operando correctamente: una sola autenticación inicial, sesión persistente, logout coordinado.

Vendors emblemáticos

Fuentes para tracking del mercado AM: Gartner Peer Insights — Access Management (reseñas verificadas y comparativas), KuppingerCole Leadership Compass: Access Management (busca “Access Management” en su listado), Forrester Wave: Identity-As-A-Service.

Dónde se solapa con otros dominios

AM produce los logs y eventos que ITDR consume para detectar anomalías. El IdP también es la fuente que IGA usa para reflejar los cambios de lifecycle (nuevo empleado → cuenta creada → puede loguearse). Y la frontera con CIAM es difusa: técnicamente CIAM también hace AM, solo que para audiencia de clientes y a una escala distinta.

2. Identity Governance and Administration (IGA): el guardián

Qué hace IGA

Mientras AM se preocupa de la autenticación del momento, IGA se preocupa del acceso a lo largo del tiempo. Su pregunta central es: ¿la identidad correcta tiene los accesos correctos hoy y se los quitamos el día que ya no los necesite?.

Las capacidades core son seis:

• Lifecycle management (JML): automatizar el alta (Joiner), los cambios (Mover) y la baja (Leaver) de identidades.
• Access request: catálogo donde los usuarios pueden solicitar accesos con flujo de aprobación.
• Access certification (recertification): revisión periódica de los accesos otorgados, donde managers o dueños de aplicación deciden si siguen siendo válidos.
• Role management: agrupar permisos en roles funcionales para gestionar a escala.
• Separation of Duties (SoD): detectar combinaciones tóxicas de permisos (ej. “crear vendor + aprobar pago” en SAP).
• Audit & reporting: evidencia exportable a auditores para cumplir SOX, HIPAA, PCI-DSS, etc.

Quién lo usa

Históricamente IGA se construyó pensando en workforce (empleados, contratistas, partners). Está optimizado para entornos donde RR. HH. dispara los eventos de lifecycle y donde los managers son los que aprueban accesos. En los últimos años IGA empezó a expandirse a identidades no humanas, pero su núcleo conceptual sigue siendo workforce.

Ejemplo concreto

Sara entra como nueva analista de crédito a un banco regional. RR. HH. crea su registro en Workday el martes. Esa misma noche, la plataforma IGA de la empresa (SailPoint) detecta el evento y dispara los workflows: crea cuenta en Active Directory, le asigna el rol “analista de crédito” que automáticamente le otorga acceso a la app de scoring, al CRM y al portal interno. Sara llega el miércoles por la mañana y todo le funciona desde el primer click — sin tickets, sin esperas.

Tres meses después, Sara cambia a “analista senior”. El nuevo rol incluye permisos adicionales (aprobar préstamos hasta cierto monto). Pero también detona una alerta SoD: el rol senior + un permiso heredado del rol previo crean una combinación tóxica (puede crear y aprobar la misma operación). El sistema bloquea el cambio hasta que su manager remueva el permiso heredado. Sara obtiene su nuevo rol limpio, sin acumular privilegios.

Un año después, Sara renuncia. RR. HH. cierra su registro en Workday. IGA detecta el cambio de estado a “terminated” y dispara la deprovisioning en cascada: revoca la cuenta de AD, retira los roles, cierra las sesiones activas y notifica a IT. En menos de 30 minutos, Sara no puede entrar a nada de la empresa.

Eso es IGA en su mejor versión: invisible cuando funciona, brutal cuando se necesita.

Vendors emblemáticos

Fuentes para tracking del mercado IGA: Gartner Peer Insights — Identity Governance and Administration, Gartner Magic Quadrant for Identity Governance and Administration (anual, paywall), KuppingerCole Leadership Compass: Identity Governance and Administration, Forrester Wave: Identity Governance and Administration.

Dónde se solapa con otros dominios

IGA es la fuente de verdad sobre “quién debería tener acceso a qué”, y por eso se conecta con AM (que aplica esos accesos en el momento del login) y con PAM (que toma identidades elevadas y las gestiona bajo controles más estrictos). Con ITDR la frontera es interesante: IGA detecta combinaciones tóxicas estáticas (SoD), mientras que ITDR detecta comportamiento anómalo en tiempo real.

3. Privileged Access Management (PAM): la caja fuerte

Qué hace PAM

PAM se enfoca en un subconjunto crítico: las cuentas con privilegios elevados. Root en Linux, Domain Admin en Windows, AWS root, DBA accounts, service accounts con permisos amplios. Estas cuentas son distintas porque su compromiso significa game over para una organización entera, así que merecen controles desproporcionadamente fuertes.

Su pregunta central: ¿cómo controlo, monitoreo y audito todo uso de credenciales privilegiadas?.

Las capacidades core son cinco:

• Bóveda de credenciales (vault): las contraseñas administrativas se guardan cifradas, nadie las conoce de memoria, se sacan bajo demanda con check-out/check-in.
• Rotación automática: tras cada uso o de forma programada, las contraseñas privilegiadas se cambian automáticamente.
• Privileged Session Management (PSM): las sesiones administrativas se hacen a través de un proxy que graba video/keystrokes para forensia.
• Just-In-Time (JIT) access: los privilegios se otorgan solo cuando se necesitan, por el tiempo mínimo, y se revocan automáticamente.
• Endpoint Privilege Management (EPM): quitar el “local admin” a los usuarios y elevar comandos específicos en lugar de toda la sesión.

Quién lo usa

PAM cubre toda identidad con privilegios, sea humana o no humana. Los administradores de sistemas son los usuarios obvios. Pero también las cuentas de servicio que ejecutan procesos batch, los certificados de máquina que firman releases, los tokens de API con permisos de admin sobre cloud, los agentes IA con scopes amplios.

Ejemplo concreto

Daniel es ingeniero de plataforma en una fintech. Necesita acceder al cluster de producción de Kubernetes para investigar un incidente. En lugar de tener un usuario kubectl-admin permanente, hace lo siguiente:

1. Abre el portal PAM (CyberArk en este caso) y solicita acceso JIT al cluster con justificación: “investigando el incidente INC-4521”.
2. La solicitud requiere aprobación de un manager. El manager aprueba en 4 minutos.
3. PAM emite credenciales temporales con TTL de 60 minutos. Daniel las recibe y se conecta. Toda su sesión queda grabada en video.
4. Daniel depura el problema, lo soluciona y cierra la sesión.
5. Las credenciales expiran a los 60 minutos. PAM cierra el ticket. La grabación queda disponible para auditoría.

Si en lugar de Daniel hubiera entrado un atacante con sus credenciales personales, habría tenido que pasar por aprobación humana, no habría podido permanecer indefinidamente, y todo lo que hubiera hecho habría sido grabado. Esos tres controles bajan radicalmente el daño posible.

Vendors emblemáticos

Fuentes para tracking del mercado PAM: Gartner Peer Insights — Privileged Access Management, Gartner Magic Quadrant for Privileged Access Management (anual), KuppingerCole Leadership Compass: Privileged Access Management, Forrester Wave: Privileged Identity Management.

Dónde se solapa con otros dominios

PAM se solapa fuertemente con IGA en governance de cuentas privilegiadas (¿quién debe tener acceso admin? ¿lo certifica alguien?). Se solapa con AM en autenticación reforzada (MFA específico para admins). Y se solapa con ITDR en monitoreo de comportamiento anómalo en sesiones privilegiadas — un admin que de repente exporta toda una base de datos a las 3 AM debería levantar alarmas.

4. Customer IAM (CIAM): la cara al cliente

Qué hace CIAM

CIAM es identidad para audiencia externa: clientes, prospects, suscriptores. Mientras workforce IAM mide su éxito en eficiencia operativa y compliance, CIAM lo mide en conversión, retención y experiencia. Cada paso adicional en el flujo de signup pierde un porcentaje de usuarios; cada login fallido baja la satisfacción. La economía es brutal y muy distinta a la de empleados.

Su pregunta central: ¿cómo doy acceso seguro a millones de usuarios externos sin sacrificar UX?.

Las capacidades core son siete:

• Autoregistro y onboarding: el usuario crea su cuenta, valida email/teléfono, completa perfil progresivamente.
• Autenticación con UX optimizada: passkeys, login social, magic links, biometría móvil.
• Identity proofing y KYC: verificar que la persona es real (documento + selfie + liveness), especialmente regulado en banca y juego online.
• Gestión de consentimiento: granular, revocable, auditable (GDPR, CCPA, LGPD).
• Perfilamiento progresivo: pedir el mínimo en signup, ampliar conforme aumenta el engagement.
• Detección de fraude: ATO, credential stuffing, bots, SIM swapping, phishing.
• Omnicanalidad: la identidad sigue al cliente entre web, móvil, kiosko, IVR.

Quién lo usa

Cualquier negocio digital con clientes externos: banca, retail, streaming, telco, gobierno, salud, juego. La escala importa: una app con 10,000 usuarios puede sobrevivir con un IdP genérico; una con 10 millones necesita un CIAM dedicado.

Ejemplo concreto

Una nueva plataforma de comercio electrónico está por lanzar. El diseñador del flujo de registro tiene que tomar decisiones que afectan directamente la conversión:

• ¿Email + contraseña, o solo email con magic link? Eligen magic link para reducir fricción.
• ¿Verificar email antes de comprar? No, lo difieren a la primera transacción superior a $50.
• ¿Pedir DUI + foto desde el día uno? No, solo cuando intenta hacer una transferencia P2P.
• ¿Permitir login con Apple/Google? Sí, para no perder usuarios que detestan crear cuentas nuevas.
• ¿MFA obligatorio? Solo para acciones sensibles (cambio de contraseña, agregar tarjeta, transacción > $200).

Cada decisión es una negociación entre seguridad y conversión. El equipo mide cada cohorte: “el flujo con magic link convierte 14% mejor que con contraseña, pero genera 2% más de cuentas duplicadas”. Esa medición es algo que jamás existiría en un proyecto de workforce IAM, y es la esencia de CIAM.

Vendors emblemáticos

Fuentes para tracking del mercado CIAM: Gartner Peer Insights — Customer Identity and Access Management, Gartner Magic Quadrant for Customer Identity and Access Management (anual), KuppingerCole Leadership Compass: Consumer Identity and Access Management, Forrester Wave: Customer Identity and Access Management.

Dónde se solapa con otros dominios

CIAM hace técnicamente todo lo de AM (login, MFA, SSO) pero con prioridades opuestas — UX sobre control. Se solapa con ITDR muy fuerte en detección de fraude, pero ITDR de CIAM es distinto al de workforce: aquí la amenaza son ATOs masivos y bots, no privilege escalation.

5. Identity Threat Detection and Response (ITDR): el centinela

Qué hace ITDR

ITDR es el dominio más nuevo, formalizado por Gartner alrededor de 2022. Su rol es vigilar todos los dominios anteriores en tiempo real, detectar amenazas y responder automáticamente. Es el equivalente identidad de lo que EDR (Endpoint Detection and Response) es para los endpoints.

Su pregunta central: ¿hay alguien comportándose de forma sospechosa en mi plano de identidad, ahora mismo?.

Las capacidades core son cuatro:

• Discovery de exposiciones: encuentra rutas de ataque latentes — golden tickets, paths de Kerberoasting, shadow admins, cuentas con permisos inflados.
• Detección en tiempo real: aplica analytics y ML sobre eventos de identidad para detectar anomalías que reglas estáticas no atrapan.
• Respuesta orquestada: ante una alerta puede revocar sesiones, deshabilitar cuentas, forzar re-autenticación, alertar al SOC.
• Investigación forense: cuando el incidente termina, permite reconstruir qué identidad hizo qué y cuándo, con timeline y trazabilidad.

Quién lo usa

ITDR cubre todas las identidades bajo monitoreo, especialmente las de mayor riesgo: administradores, cuentas de servicio, identidades federadas. Es transversal — no protege un grupo específico de identidades, sino que vigila el plano completo.

Ejemplo concreto

A las 2:14 AM, el ITDR de una fintech (Microsoft Defender for Identity) detecta tres señales correlacionadas en menos de 30 segundos:

1. Un usuario administrador (admin_db_prod) inicia sesión desde una IP de un país donde nunca había aparecido antes.
2. El mismo usuario intenta hacer una consulta masiva sobre la tabla customers en la base de datos.
3. La cuenta del manager de ese administrador tiene un MFA bombing en proceso (15 push en 60 segundos).

El motor ITDR correlaciona los tres eventos en una sola alerta de severidad alta. Automáticamente:

• Revoca la sesión activa de admin_db_prod.
• Bloquea la cuenta hasta intervención manual.
• Cierra todos los push de MFA pendientes del manager.
• Genera ticket en el SOC con timeline detallado.
• Notifica por SMS al CISO.

A las 2:18 AM (4 minutos después), el SOC tiene contexto suficiente para confirmar que se trata de un intento real de breach. La acción ya está tomada; solo queda investigación forense y cerrar la puerta de entrada original.

Sin ITDR, esos mismos eventos habrían quedado en logs separados de la base de datos, del IdP y del MFA provider. Un humano habría tenido que correlacionarlos al día siguiente — demasiado tarde.

Vendors emblemáticos

Fuentes para tracking del mercado ITDR: Forrester Wave: Identity Threat Detection and Response (publicada por primera vez en 2024), Gartner research sobre ITDR (categoría formalizada en 2022), KuppingerCole Leadership Compass — buscar “Identity Threat Detection” y reportes de Identity Security.

Dónde se solapa con otros dominios

ITDR es por definición transversal. Consume señales de AM (eventos de auth), de PAM (sesiones privilegiadas), de IGA (cambios sospechosos en accesos), y de CIAM (intentos de fraude). En términos de SIEM/SOC, ITDR puede pensarse como una capa especializada que vive entre el plano IAM y el plano de detección general.

Cómo se relacionan los cinco dominios

Hasta aquí los vimos individualmente. Ahora veamos cómo interactúan en la realidad.

Confusiones frecuentes y cómo resolverlas

Qué dominio invertir primero según madurez

Una pregunta común en consultoría: si una organización tiene presupuesto limitado, ¿en qué dominio invertir primero? Una guía práctica:

Caso integrado: cinco dominios en un viernes común

Para cerrar, sigamos un viernes típico en una fintech regional con 800 empleados y 1.2 millones de clientes. En las próximas dos horas, los cinco dominios actúan.

sequenceDiagram
  accTitle: Los cinco dominios de IAM interactuando un viernes común
  accDescr: Un manager y cinco participantes de dominio intercambian once mensajes entre las 14:00 y las 15:42, mostrando cómo IGA, AM, PAM, CIAM e ITDR colaboran durante una aprobación de acceso, un pico de logins de Black Friday, una solicitud JIT y un login anómalo desde una nueva geo.
  actor M as Manager
  participant IGA as IGA
  participant AM as AM
  participant PAM as PAM
  participant CIAM as CIAM
  participant ITDR as ITDR
  M->>IGA: 14:00 — Aprueba acceso senior para Sara
  IGA->>AM: 14:01 — Sincroniza nuevo rol
  Note over CIAM: 14:32 — 200k clientes intentan login (Black Friday)
  CIAM->>ITDR: 14:33 — Detecta 3k intentos de credential stuffing
  ITDR->>CIAM: 14:33 — Activa CAPTCHA + rate limit
  Note over PAM: 15:10 — Daniel pide JIT al cluster K8s
  PAM->>M: 15:10 — Solicita aprobación
  M->>PAM: 15:14 — Aprueba
  PAM->>AM: 15:14 — Emite credenciales temporales
  Note over ITDR: 15:42 — Anomalía: admin loguea desde geo nueva
  ITDR->>AM: 15:42 — Revoca sesión
  ITDR->>M: 15:42 — Notifica al SOC

Lectura del viaje:

• 14:00: Un manager aprueba el ascenso de Sara. IGA ejecuta el cambio y propaga el nuevo rol a AM, que ahora deja a Sara entrar a sistemas que antes no podía.
• 14:32: Inicia campaña de Black Friday. 200,000 clientes intentan loguearse simultáneamente — eso es CIAM operando a escala.
• 14:33: De esos intentos, 3,000 vienen de credential stuffing (atacantes probando credenciales filtradas). ITDR detecta el patrón y le pide a CIAM activar mitigaciones (CAPTCHA, rate limit). Los clientes legítimos ven 200 ms de fricción extra; los bots se quedan fuera.
• 15:10: Daniel solicita acceso JIT al cluster Kubernetes. PAM orquesta aprobación y emisión de credenciales temporales. AM las acepta como válidas por 60 minutos.
• 15:42: ITDR detecta que un admin de bases de datos se loguea desde un país inusual. Sin esperar humano, revoca la sesión vía AM y notifica al SOC.

Cinco dominios, cinco eventos distintos, todos ocurriendo dentro del mismo plano de identidad en menos de dos horas. Cada uno con su lógica, su prioridad, su tiempo de respuesta. Una sola plataforma jamás cubriría todo eso bien — por eso existen cinco dominios.

Recapitulación

Los cinco dominios de IAM son las cinco preguntas que una organización seria sobre identidad necesita responder simultáneamente:

• AM: ¿quién está entrando ahora mismo?
• IGA: ¿quién debería tener acceso a qué a lo largo del tiempo?
• PAM: ¿quién está usando privilegios elevados y bajo qué controles?
• CIAM: ¿cómo le doy acceso a millones de clientes sin sacrificar conversión?
• ITDR: ¿hay alguien comportándose mal en mi plano de identidad?

Una organización que solo se pregunta uno o dos de estos puntos tiene huecos enormes. Pero también, intentar resolver los cinco al mismo tiempo es un error común: no hay presupuesto, ni equipo, ni atención ejecutiva para todo a la vez. La madurez es el orden — y conocer ese orden te convierte en alguien útil en cualquier conversación de programa IAM.

Cómo seguir el pulso del mercado IAM

Si quieres mantenerte al día con quién está liderando cada dominio, estas son las cuatro fuentes que la industria consulta de forma rutinaria:

Tres preguntas para autoevaluarte

1. Una empresa de retail con tienda física y app móvil te contrata para “modernizar IAM”. Tienen 600 empleados internos y 2 millones de clientes. ¿En qué orden abordarías los cinco dominios y por qué?
2. Te dicen “ya tenemos IGA, no necesitamos PAM porque IGA gobierna nuestras cuentas privilegiadas”. ¿Cuál es tu contraargumento en menos de un minuto?
3. Tu CISO pregunta: “¿qué problema concreto resuelve ITDR que no resuelva nuestro SIEM?”. ¿Qué tres ejemplos das?