Los cinco dominios de IAM

Un recorrido por los cinco dominios que forman el IAM moderno, gestión de accesos, IGA, PAM, CIAM e ITDR, con lo que hace cada uno, a quién sirve, cómo se ve en la práctica y dónde se solapan.

Cinco conversaciones que suenan a una

Sara pasa su primer mes en el equipo de seguridad de un banco regional asistiendo a reuniones, y nota algo raro. En una reunión “IAM” significa la pantalla de inicio de sesión y el MFA. En la siguiente, las revisiones de accesos trimestrales que piden los auditores. En una tercera, la bóveda donde los administradores de bases de datos sacan las contraseñas. Producto lo usa para el registro de la app móvil, y el SOC para las alertas de inicios de sesión extraños de madrugada. Todo el mundo dice “IAM”, y están hablando de cinco cosas distintas.


Lo están, y el sector tiene nombres para ellas. Los artículos anteriores mencionaron la gestión de accesos, el IGA, el PAM, el CIAM y el ITDR varias veces, casi siempre de pasada. Este los abre uno a uno, por una razón práctica: el mercado se organiza así. Una oferta de trabajo de “ingeniero de IAM” suele referirse a uno o dos de estos dominios, no a los cinco. Un consultor define el alcance de un proyecto en estos términos. Y una herramienta que se presenta como “líder de Gartner” siempre lo es en un cuadrante concreto. Sin esta división acabas en conversaciones cruzadas, hablando de MFA cuando el problema real es la certificación, o de cuentas privilegiadas cuando lo que hace falta es detectar fraude. Cada dominio responde a preguntas distintas, con sus propias herramientas, su propio vocabulario y a menudo su propio equipo. Averiguar en qué dominio está una conversación antes de responder ahorra mucha credibilidad.


Un edificio sirve de imagen. La gestión de accesos son los vigilantes de la entrada principal, que comprueban las acreditaciones y dejan pasar. El IGA es la oficina que mantiene la lista de quién puede entrar y comprueba que esté bien. El PAM son los vigilantes especializados de las plantas restringidas, las salas de servidores y de máquinas, con sus propias normas. El CIAM es la recepción para visitas y clientes. Y el ITDR son las cámaras y los sensores que vigilan a todos en tiempo real y dan la alarma cuando algo no cuadra.


flowchart TB
  accTitle: Mapa de los cinco dominios de IAM
  accDescr: La identidad es el nodo central, con aristas dirigidas hacia cinco dominios: 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
La identidad es el eje. Cada dominio toma esa identidad y la mira de una forma distinta: autenticarla, gobernarla, elevarla, atenderla, vigilarla.

No son cinco productos para el mismo problema; son cinco preguntas distintas sobre el mismo sujeto. La gestión de accesos pregunta si eres quien dices ser y si puedes entrar. El IGA, si tienes el acceso correcto, hoy y a lo largo del tiempo. El PAM, quién tocó qué con privilegios elevados. El CIAM, cómo dar acceso a millones de personas sin estropearles la experiencia. Y el ITDR, si alguien se está comportando de forma rara en la capa de identidad ahora mismo.


Gestión de accesos: la puerta de entrada

La gestión de accesos, AM por sus siglas en inglés, responde a la pregunta más básica: ¿puede entrar esta identidad? Cuando abres la app de tu banco, escribes tu usuario y tu contraseña, te pide un segundo factor y entras, eso es AM. Es la cara del IAM que todo usuario ve a diario.


Su núcleo son cuatro capacidades. La autenticación comprueba la identidad con uno o varios factores, una contraseña, un código de un solo uso, una passkey, una huella. El inicio de sesión único permite que una sola autenticación abra muchas aplicaciones relacionadas. La federación confía en el proveedor de identidad de otra organización, normalmente por SAML u OIDC, para autenticar a usuarios de fuera. Y la gestión de sesiones decide cuánto dura una sesión, cuándo caduca y cómo se revoca. AM se aplica a toda identidad que se autentica, humana o de máquina: empleados que entran en el ERP, clientes que abren la app móvil, microservicios que llaman a APIs internas. Si hay un inicio de sesión, ahí está AM.


David, contable en una empresa mediana, llega el lunes a las ocho. Abre Microsoft 365 en el portátil de la empresa, y el proveedor de identidad de la empresa, Microsoft Entra ID, le pide la contraseña y después que apruebe una notificación en el teléfono. En los noventa minutos siguientes abre Salesforce, SAP y un panel interno de BI sin volver a iniciar sesión, porque todos están conectados al mismo proveedor de identidad con inicio de sesión único. A las cinco y media cierra sesión, y la sesión termina en todas las aplicaciones a la vez. Una autenticación al principio, una sesión que se mantiene y un cierre coordinado: eso es AM funcionando como debe.


Los grandes nombres son Microsoft con Entra ID, antes Azure AD, dominante allí donde ya está Microsoft 365; Okta, con Workforce Identity Cloud, el líder independiente de siempre; Ping Identity, con PingOne y PingFederate, fuerte en grandes empresas muy reguladas, que compró ForgeRock en 2023, y Auth0, pensado para desarrolladores y comprado por Okta en 2021.


AM produce los eventos que usa el ITDR para detectar anomalías. El proveedor de identidad es también donde se reflejan los cambios del ciclo de vida que gestiona el IGA: un empleado nuevo, una cuenta creada, la posibilidad de entrar. Y la frontera con el CIAM es difusa, porque técnicamente el CIAM también hace AM, para un público de clientes y a otra escala. Cuando alguien dice “vamos a desplegar Okta”, suele referirse a un proyecto de AM, pero Okta también vende funciones de gobierno, lo que confunde. La pregunta útil es “¿qué problema resolvemos primero?”. Si es “que todo el mundo entre con MFA”, es AM. Si es “saber quién tiene acceso a qué”, es IGA.


IGA: el guardián

Si AM se ocupa de la autenticación del momento, el gobierno y la administración de identidades, IGA, se ocupa del acceso a lo largo del tiempo. Su pregunta es: ¿tiene la identidad correcta el acceso correcto hoy, y se lo quitamos el día que deja de necesitarlo?


Hace seis cosas. La gestión del ciclo de vida automatiza las altas, los cambios y las bajas, el ciclo JML. Las solicitudes de acceso ofrecen un catálogo donde la gente pide accesos con un flujo de aprobación. La certificación de accesos revisa cada cierto tiempo lo concedido, y los jefes o los responsables de aplicación deciden si sigue siendo válido. La gestión de roles agrupa permisos en roles de negocio para manejarlos a escala. La separación de funciones detecta combinaciones tóxicas, como “crear un proveedor” más “aprobar un pago” en SAP. Y la auditoría y los informes generan pruebas que aceptan los auditores para SOX, HIPAA, PCI DSS y similares. El IGA se construyó pensando en la plantilla, empleados, contratistas y socios, en entornos donde RR. HH. dispara el ciclo de vida y los jefes aprueban los accesos. En los últimos años ha empezado a extenderse a las identidades no humanas, pero su corazón sigue siendo la plantilla.


Sara entra en un banco regional como analista de crédito. RR. HH. crea su ficha en Workday el martes. Esa noche, la plataforma de IGA del banco, SailPoint, detecta el evento y lanza sus flujos: crea su cuenta en Active Directory y le asigna el rol “analista de crédito”, que le da automáticamente la aplicación de scoring, el CRM y la intranet. El miércoles por la mañana todo funciona desde el primer clic, sin tickets ni esperas. Tres meses después la ascienden a analista sénior, un rol que puede aprobar préstamos hasta cierto importe. El cambio dispara una alerta de separación de funciones, porque el rol nuevo más un permiso que le quedó del anterior le permitirían crear y aprobar la misma operación. El sistema retiene el cambio hasta que su jefe quita el permiso sobrante, y Sara recibe su rol nuevo limpio. Un año después dimite. RR. HH. cierra su ficha, el IGA ve que su estado pasa a “baja” y lo retira todo en cascada: su cuenta del directorio, sus roles, sus sesiones abiertas, con un aviso a TI. En menos de treinta minutos no puede entrar en nada del banco. Ese es el IGA en su mejor versión, invisible cuando funciona e implacable cuando hace falta.


SailPoint, con IdentityIQ e Identity Security Cloud, es el líder histórico. Saviynt nació en la nube y es fuerte en empresas que trabajan sobre todo con SaaS. Omada es fuerte en Europa y conocida por su sencillez. One Identity vende una suite integrada. Y Microsoft ofrece gobierno dentro de su propio ecosistema con Entra ID Governance. Para seguir el mercado están Gartner Peer Insights para IGA, el Magic Quadrant anual de Gartner, el KuppingerCole Leadership Compass y la Forrester Wave.


El IGA es la fuente de verdad sobre quién debería tener acceso a qué, así que se conecta con AM, que aplica ese acceso al iniciar sesión, y con el PAM, que toma las identidades elevadas y las somete a un control más estricto. Con el ITDR la frontera es interesante: el IGA detecta combinaciones tóxicas que están quietas, mientras que el ITDR detecta comportamientos raros mientras ocurren. El error más caro de los proyectos de IGA es subestimar el diseño de roles. Con roles mal diseñados, una herramienta de gobierno cara se convierte en una máquina de aprobarlo todo en bloque, justo lo que se compró para evitar. Un programa de IGA triunfa en años, no en meses, y depende más de los analistas de negocio que de la tecnología.


PAM: la caja fuerte

La gestión del acceso privilegiado, PAM, se ocupa de un subconjunto crítico: las cuentas con privilegios elevados. El root de Linux, los administradores de dominio de Windows, la cuenta raíz de AWS, los administradores de bases de datos, las cuentas de servicio con permisos amplios. Son distintas porque perder una significa perder toda la organización, así que reciben controles mucho más fuertes que el resto. La pregunta del PAM es ¿cómo controlo, vigilo y audito cada uso de una credencial privilegiada?


Hace cinco cosas. Una bóveda de credenciales guarda cifradas las contraseñas de administración, de modo que nadie se las sabe de memoria y se sacan y se devuelven bajo demanda. La rotación automática cambia las contraseñas privilegiadas después de cada uso o según un calendario. La gestión de sesiones privilegiadas hace pasar las sesiones de administración por un proxy que graba la pantalla y las pulsaciones para investigar después. El acceso justo a tiempo concede privilegios solo cuando hacen falta, durante el menor tiempo posible, y los retira automáticamente. Y la gestión de privilegios en el endpoint quita a los usuarios los derechos de administrador local y eleva comandos concretos en lugar de toda la sesión. El PAM cubre a toda identidad con privilegios, humana o no: los administradores de sistemas, claro, pero también las cuentas de servicio que ejecutan procesos por lotes, los certificados que firman versiones de software, los tokens de API con derechos de administración en la nube y los agentes de IA con scopes amplios.


Daniel es ingeniero de plataforma en una fintech y necesita entrar en el clúster de Kubernetes de producción para investigar un incidente. No tiene una cuenta kubectl-admin permanente. En su lugar abre el portal de PAM, CyberArk en este caso, y pide acceso justo a tiempo con un motivo, “investigando el incidente INC-4521”. Su jefa lo aprueba cuatro minutos después. El PAM emite credenciales temporales válidas durante sesenta minutos, Daniel se conecta y toda la sesión queda grabada. Encuentra el problema, lo arregla y cierra la sesión. Cuando pasan los sesenta minutos las credenciales caducan, el PAM cierra el ticket y la grabación queda disponible para auditoría. Si un atacante hubiera usado las credenciales personales de Daniel, habría necesitado una aprobación humana, no habría podido quedarse indefinidamente y todo lo que hiciera habría quedado grabado. Esos tres controles reducen muchísimo el daño posible.


CyberArk es el líder histórico, al que a veces llaman el Microsoft del PAM. BeyondTrust es fuerte en la gestión de privilegios en el endpoint. Delinea nació de la fusión de Thycotic y Centrify. HashiCorp Vault, de código abierto, es fuerte en DevOps y en secretos de identidades no humanas. Y One Identity ofrece Safeguard junto a su suite de gobierno.


El PAM se solapa mucho con el IGA en el gobierno de las cuentas privilegiadas: ¿quién debería tener acceso de administrador y quién lo certifica? Se solapa con AM en la autenticación reforzada, con MFA específico para administradores. Y se solapa con el ITDR en la vigilancia de comportamientos raros en las sesiones privilegiadas; un administrador que de repente exporta una base de datos entera a las tres de la madrugada debería hacer saltar las alarmas.


CIAM: la cara que ven los clientes

El IAM de clientes, CIAM, es la identidad para un público externo: clientes, posibles clientes y suscriptores. El IAM de empleados mide su éxito en eficiencia y cumplimiento; el CIAM lo mide en conversión, retención y experiencia. Cada paso de más en un registro pierde a una parte de los usuarios, y cada inicio de sesión fallido resta satisfacción. La economía es dura y muy distinta de la del mundo de los empleados. La pregunta del CIAM es ¿cómo doy a millones de usuarios externos un acceso seguro sin estropearles la experiencia?


Eso exige un abanico amplio de capacidades. El autorregistro, en el que los usuarios crean su cuenta, confirman su correo o su teléfono y completan su perfil poco a poco. Una autenticación pensada para la experiencia: passkeys, inicio de sesión con redes sociales, enlaces mágicos y biometría en el teléfono. La verificación de identidad y el KYC, comprobar que la persona es real con un documento, un selfie y una prueba de vida, algo regulado en la banca y en el juego en línea. Una gestión del consentimiento granular, revocable y auditable según el RGPD, la CCPA o la LGPD. El perfilado progresivo, pedir lo mínimo al registrarse y más a medida que crece la relación. La detección de fraude contra el robo de cuentas, el credential stuffing, los bots, el SIM swapping y el phishing. Y una identidad que acompaña al cliente por la web, la app móvil, los quioscos y la atención telefónica. Lo necesita cualquier negocio digital con clientes externos, banca, comercio, streaming, telecomunicaciones, administración pública, sanidad y juego, y la escala importa: una app con 10.000 usuarios puede apañarse con un proveedor de identidad genérico, pero una con 10 millones necesita un CIAM de verdad.


Imagina al equipo que diseña el registro de una tienda en línea nueva. Cada decisión toca la conversión. ¿Correo y contraseña, o solo un correo con enlace mágico? Eligen el enlace mágico para reducir fricción. ¿Verificar el correo antes de la primera compra? No, solo antes del primer pedido de más de 50 dólares. ¿Pedir documento y foto el primer día? No, solo cuando alguien intente enviar dinero a otro usuario. ¿Permitir entrar con Apple y Google? Sí, para no perder a quienes odian crear cuentas. ¿MFA obligatorio? Solo para acciones sensibles, cambiar la contraseña, añadir una tarjeta, un pedido de más de 200 dólares. Cada decisión es una negociación entre seguridad y conversión, y el equipo mide cada cohorte: “el flujo con enlace mágico convierte un 14 % más que el de contraseña, pero crea un 2 % más de cuentas duplicadas”. Ese tipo de medición no existe en un proyecto de empleados, y es la esencia del CIAM.


El Customer Identity Cloud de Okta, construido sobre Auth0, lidera en experiencia para desarrolladores. Microsoft Entra External ID es el sucesor de Azure AD B2C. PingOne for Customers de Ping Identity es fuerte en empresas reguladas. Transmit Security se centra en el acceso sin contraseña y en el fraude. Y el Identity Server de Curity hace OIDC y OAuth a nivel profesional.


El CIAM hace técnicamente todo lo que hace AM, inicio de sesión, MFA e inicio de sesión único, pero con la prioridad contraria, la experiencia por encima del control. Se solapa mucho con el ITDR en la detección de fraude, aunque las amenazas son distintas de las del lado de los empleados: robo masivo de cuentas y bots, no escalada de privilegios. Por eso un mismo fabricante puede vender dos productos. Okta Workforce Identity Cloud está pensado para empleados y Auth0 para clientes, y usar el primero en una app de clientes les da una experiencia de empleado, lo que mata la conversión.


ITDR: el centinela

La detección y respuesta a amenazas de identidad, ITDR, es el dominio más reciente, al que Gartner puso nombre hacia 2022. Su trabajo es vigilar a los otros cuatro en tiempo real, detectar amenazas y responder de forma automática, como hace el EDR con los endpoints. Su pregunta es ¿alguien se está comportando de forma sospechosa en mi capa de identidad ahora mismo?


Hace cuatro cosas. Encuentra exposiciones, caminos de ataque ocultos como golden tickets de Kerberos falsificados, caminos de Kerberoasting, administradores ocultos y cuentas con permisos inflados. Detecta en tiempo real, aplicando analítica y aprendizaje automático a los eventos de identidad para pillar lo que las reglas fijas no ven. Responde, revocando sesiones, desactivando cuentas, obligando a volver a iniciar sesión y avisando al SOC. Y apoya la investigación, permitiendo reconstruir después qué identidad hizo qué y cuándo. El ITDR cubre a toda identidad que vigila, sobre todo a las de más riesgo, administradores, cuentas de servicio e identidades federadas. Atraviesa todo; no protege a un grupo concreto, vigila la capa entera.


A las 2:14 de la madrugada, el ITDR de una fintech, Microsoft Defender for Identity, ve tres señales en treinta segundos. Una cuenta de administración, admin_db_prod, inicia sesión desde un país en el que nunca había aparecido. Esa misma cuenta lanza una consulta enorme contra la tabla customers. Y a la jefa de ese administrador le están haciendo MFA bombing, quince notificaciones en un minuto. El motor une las tres en una sola alerta de gravedad alta y actúa por su cuenta: revoca la sesión de admin_db_prod, bloquea la cuenta hasta que alguien la revise, cancela las notificaciones pendientes de la jefa, abre un ticket en el SOC con una cronología detallada y avisa por SMS al CISO. A las 2:18, cuatro minutos después, el SOC tiene contexto suficiente para confirmar un intento de intrusión real. La contención ya está hecha, y lo que queda es la investigación y cerrar la vía de entrada original. Sin ITDR, esos tres eventos habrían quedado en registros separados, el de la base de datos, el del proveedor de identidad y el del proveedor de MFA, para que alguien los relacionara al día siguiente, demasiado tarde.


Microsoft Defender for Identity es fuerte allí donde hay Active Directory y Entra ID. CrowdStrike Falcon Identity Protection ha crecido muy deprisa desde 2022. Silverfort funciona sin agentes y cubre sistemas heredados. Semperis está especializada en Active Directory. Y Quest, con One Identity, es veterana en la vigilancia de AD. Forrester publicó su primera Wave de la categoría en 2024, y la definición de ITDR de Gartner es de 2022.


El ITDR es transversal por definición. Recibe señales de AM (eventos de autenticación), del PAM (sesiones privilegiadas), del IGA (cambios sospechosos en los accesos) y del CIAM (intentos de fraude). En términos de SOC, es una capa especializada entre el mundo del IAM y la detección general.


Cómo encajan los cinco

Hay confusiones que aparecen una y otra vez. “AM e IGA son lo mismo”: no, AM autentica en el momento y el IGA gobierna en el tiempo; AM dice “puedes entrar”, el IGA dice “deberías poder entrar”. “El PAM es parte del IGA”: en concepto sí, pero el PAM tiene capacidades operativas, la bóveda, la grabación de sesiones, el acceso justo a tiempo, que el IGA no tiene, y en la práctica son productos distintos. “El CIAM es IAM de empleados con otra etiqueta”: comparten protocolos, pero sus prioridades son opuestas, y confundirlos lleva a malos diseños. “El ITDR es un SIEM con otra etiqueta”: un SIEM recibe todos los registros, mientras que el ITDR se especializa en la capa de identidad y conoce su contexto, Active Directory, Kerberos, OIDC, golden tickets.


Una pregunta frecuente en consultoría es qué dominio financiar primero con un presupuesto limitado. Una guía práctica según la madurez:


MadurezSíntoma típicoDominio a priorizar
0, caosContraseñas en hojas de cálculo, sin inicio de sesión únicoAM: desplegar un proveedor de identidad central
1, básicaHay AM, pero las altas y las bajas son manualesIGA: poner en marcha un JML básico
2, intermediaEl IGA funciona, pero los administradores no están controladosPAM: bóveda y rotación para las cuentas privilegiadas
3, avanzadaPAM y MFA en todas partes, pero sin detecciónITDR: vigilar la capa de identidad
En paraleloEl negocio depende de clientes externosCIAM: separado de los empleados desde el primer día

El CIAM va aparte porque avanza en paralelo, no en secuencia. Un negocio de consumo necesita CIAM desde el principio, sea cual sea su madurez en los otros cuatro. Mezclar la identidad de empleados y la de clientes en una misma plataforma, algo habitual en startups que crecen deprisa, suele acabar en una migración cara unos años después.


Cinco dominios en un viernes cualquiera

Sigue una tarde de viernes en una fintech regional con 800 empleados y 1,2 millones de clientes. En menos de dos horas actúan los cinco dominios.


sequenceDiagram
  accTitle: Los cinco dominios de IAM trabajando juntos un viernes cualquiera
  accDescr: Una jefa y cinco participantes de dominio intercambian 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 inicios de sesión de Black Friday, una solicitud de acceso justo a tiempo y un inicio de sesión desde un país inusual.
  actor M as Jefa
  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 sénior para Sara
  IGA->>AM: 14:01 sincroniza el rol nuevo
  CIAM->>CIAM: 14:32 entran 200k clientes (Black Friday)
  CIAM->>ITDR: 14:33 3k intentos de credential stuffing
  ITDR->>CIAM: 14:33 activa CAPTCHA y límite de peticiones
  PAM->>PAM: 15:10 Daniel pide JIT al clúster K8s
  PAM->>M: 15:10 pide aprobación
  M->>PAM: 15:14 aprueba
  PAM->>AM: 15:14 emite credenciales temporales
  ITDR->>ITDR: 15:42 un admin entra desde un país nuevo
  ITDR->>AM: 15:42 revoca la sesión
  ITDR->>M: 15:42 avisa al SOC
Cinco dominios, cinco eventos distintos, todos dentro de la misma capa de identidad en menos de dos horas.

A las 14:00 una jefa aprueba el ascenso de Sara, y el IGA hace el cambio y empuja el rol nuevo a AM, que ahora la deja entrar en sistemas a los que antes no llegaba. A las 14:32 empieza una campaña de Black Friday y 200.000 clientes intentan entrar a la vez, el CIAM trabajando a escala. Un minuto después, 3.000 de esos intentos resultan ser credential stuffing, atacantes probando contraseñas filtradas; el ITDR reconoce el patrón y pide al CIAM que active el CAPTCHA y el límite de peticiones. Los clientes reales notan 200 milisegundos más de fricción; los bots se quedan fuera. A las 15:10 Daniel pide acceso justo a tiempo al clúster de Kubernetes, el PAM gestiona la aprobación y emite credenciales temporales, y AM las acepta durante sesenta minutos. A las 15:42 el ITDR ve a un administrador de bases de datos entrar desde un país inusual y, sin esperar a una persona, revoca la sesión a través de AM y avisa al SOC.


Cinco dominios, cinco eventos, una sola capa de identidad, cada uno con su lógica, sus prioridades y sus tiempos. Ninguna plataforma cubriría bien todo eso por sí sola, y por eso hay cinco dominios.


Resumen

Los cinco dominios son las cinco preguntas que tiene que responder a la vez una organización que se toma en serio la identidad. 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 con qué controles? CIAM: ¿cómo dejo entrar a millones de clientes sin dañar la conversión? ITDR: ¿alguien se está portando mal en mi capa de identidad? Una organización que solo se hace una o dos de esas preguntas tiene huecos enormes. Pero intentar resolver las cinco a la vez también es un error habitual, porque nunca hay presupuesto, gente ni atención de la dirección para todo. La madurez es cuestión de orden, y conocer ese orden te hace útil en cualquier conversación de IAM, que es más o menos lo que entendió Sara tras su primer mes de reuniones.


Para saber quién lidera cada dominio, el sector consulta cuatro fuentes. El Magic Quadrant de Gartner es un informe anual por dominio que sitúa a los fabricantes como líderes, visionarios, aspirantes o de nicho; es de pago, pero los fabricantes líderes suelen regalarlo si se lo pides. Gartner Peer Insights recoge opiniones verificadas de usuarios reales y es gratuito con registro. El KuppingerCole Leadership Compass es un análisis europeo independiente, en parte gratuito. Y la Forrester Wave es la principal alternativa a Gartner, de pago pero a menudo compartida por los fabricantes. Cuando un fabricante te diga “somos líderes de Gartner”, pide el informe y su fecha. Ser líder en 2021 no significa serlo en 2024, y los cuadrantes se mueven más de lo que se piensa, sobre todo en categorías jóvenes como el ITDR.



Tres preguntas para ponerte a prueba

  1. Una cadena con tiendas físicas y app móvil te contrata para “modernizar el IAM”. Tiene 600 empleados y 2 millones de clientes. ¿En qué orden abordarías los cinco dominios y por qué?
  2. Alguien te dice “ya tenemos IGA, no necesitamos PAM, porque el IGA gobierna nuestras cuentas privilegiadas”. ¿Qué le respondes, en menos de un minuto?
  3. Tu CISO te pregunta “¿qué problema concreto resuelve el ITDR que no resuelva nuestro SIEM?”. ¿Qué tres ejemplos le darías?

Preguntas frecuentes

¿Cuáles son los cinco dominios de IAM?

La gestión de accesos (AM) se ocupa de la autenticación y el inicio de sesión; el gobierno y la administración de identidades (IGA), de quién debe tener acceso a lo largo del tiempo; la gestión del acceso privilegiado (PAM) controla las cuentas de administración y otras cuentas elevadas; el IAM de clientes (CIAM) atiende a clientes externos a gran escala, y la detección y respuesta a amenazas de identidad (ITDR) vigila toda la capa de identidad.

¿Cuál es la diferencia entre Access Management e IGA?

AM trabaja en el momento: decide si puedes iniciar sesión ahora mismo. IGA trabaja en el tiempo: decide si deberías tener ese acceso y te lo quita cuando ya no lo necesitas. AM dice 'puedes entrar'; IGA dice 'deberías poder entrar'.

¿PAM es solo una parte de IGA?

En concepto, PAM se solapa con IGA, pero PAM tiene capacidades operativas que IGA no tiene: una bóveda de credenciales, rotación automática, grabación de sesiones privilegiadas y acceso justo a tiempo. En la práctica son productos distintos que resuelven problemas distintos de las cuentas privilegiadas.

¿En qué se diferencia CIAM del IAM de empleados (workforce)?

Comparten protocolos pero persiguen objetivos opuestos. El IAM de empleados busca control y cumplimiento; el CIAM busca experiencia y conversión con millones de clientes externos. Usar una herramienta pensada para empleados en una app de clientes suele hundir la conversión.

¿Qué hace ITDR que un SIEM no hace?

Un SIEM recibe todo tipo de registros de forma genérica. ITDR se especializa en la capa de identidad y entiende su contexto, Active Directory, Kerberos, OIDC, golden tickets, administradores ocultos, así que detecta y responde a ataques de identidad que un SIEM general pasaría por alto o no sabría relacionar.