El ciclo operativo de IAM

De los conceptos a la maquinaria que los ejecuta

En los artículos anteriores construimos los conceptos: qué es una identidad digital, los cuatro tipos modernos, cómo se inserta IAM en ciberseguridad, las cuatro olas históricas, y los cinco dominios. Si te lo aprendiste de memoria pero nunca viste cómo se ve eso en operación, te falta lo más importante.

Los conceptos no flotan en el aire — viven dentro de una maquinaria que se ejecuta cada día, sin pausa. Cada vez que un empleado nuevo entra a la empresa, cada vez que alguien cambia de equipo, cada vez que un contrato se renueva, cada vez que un cliente borra su cuenta, hay un proceso IAM operando en segundo plano. Si esa maquinaria está bien aceitada, todo fluye sin que nadie lo note. Si está rota, aparecen los problemas: cuentas huérfanas, accesos que sobreviven al egreso, certificaciones que llegan vacías, auditorías reprobadas.

Este artículo abre el módulo «IAM en Acción»: vamos a abrir esa maquinaria y verla por dentro. Recorreremos los seis procesos operativos centrales — agregación, registro maestro, correlación, reconciliación de huérfanas, JML, mapeo — y los aterrizaremos en un caso completo del sector salud, donde la complejidad operativa es de las más altas que existen.

Vista general del ciclo

El ciclo operativo de IAM ejecuta seis procesos continuos: agregación desde fuentes autoritativas, construcción del registro maestro, correlación de identidades con cuentas, reconciliación de huérfanas, el ciclo Joiner-Mover-Leaver y el mapeo de cuentas. Es un bucle, no una línea — la salida de cada proceso alimenta al siguiente.

Antes de entrar al detalle de cada proceso, mira el ciclo completo. Lo importante de este esquema es entender que no es lineal sino continuo: los datos entran, se transforman, salen, y la salida se vuelve insumo de la siguiente iteración.

flowchart LR
  accTitle: El ciclo operativo de IAM
  accDescr: Las fuentes autoritativas alimentan la agregación, que construye el registro maestro en el identity warehouse. La correlación conecta ese registro con las cuentas de las aplicaciones downstream; la reconciliación devuelve las cuentas existentes al warehouse; y los workflows JML empujan los cambios de lifecycle de vuelta a las aplicaciones, formando un bucle continuo.
  SOURCES[Fuentes autoritativas<br/>HRIS, CRM, contratistas] --> AGG[Agregación]
  AGG --> WAREHOUSE[(Registro maestro<br/>Identity Warehouse)]
  WAREHOUSE --> CORR[Correlación<br/>identidades ↔ cuentas]
  CORR --> APPS[Aplicaciones<br/>downstream]
  APPS -.cuentas existentes.-> RECON[Reconciliación]
  RECON --> WAREHOUSE
  WAREHOUSE --> JML[Workflows JML]
  JML --> APPS

Lectura del diagrama: las fuentes autoritativas alimentan el proceso de agregación, que produce el registro maestro de identidad. Ese registro se conecta con las cuentas reales en cada aplicación vía correlación. Las apps reportan de vuelta sus cuentas, y la reconciliación detecta inconsistencias (huérfanas, no reclamadas) que vuelven al warehouse. Sobre el warehouse corren los workflows JML que disparan acciones automáticas en las apps. Es un ciclo: lo que sale por un lado regresa por otro.

1. Agregación de datos desde fuentes autoritativas

Qué es una fuente autoritativa

Una fuente autoritativa es el sistema que tiene la versión “verdadera” de un atributo. Si quieres saber el nombre legal de María, lo correcto es preguntárselo al sistema de RR. HH., no a Salesforce. Si quieres saber su número de teléfono actualizado, también es RR. HH. Si quieres saber qué tarjetas tiene asignadas, es probablemente la herramienta de IT Service Management. Cada atributo tiene una fuente que es la “única autoridad” sobre él.

Esto importa porque sin una fuente declarada, los atributos viven en estado de Schrödinger: si tu directorio dice “ext. 4521” y SAP dice “ext. 4530”, ¿cuál es la verdad? Sin autoridad, ninguna. Y eso significa que el dato es básicamente inservible para tomar decisiones.

Tipos de fuentes autoritativas comunes

Patrones de integración

Hay dos formas básicas de mover datos desde la fuente al sistema IAM:

• Pull (consultas agendadas): el sistema IAM consulta la fuente cada cierto tiempo (cada 15 minutos, cada hora, cada noche). Es simple pero introduce latencia — un empleado puede aparecer en la consulta de las 6:00 AM si su contrato comenzó a las 5:55 AM, o quedarse fuera y aparecer hasta el día siguiente.
• Push (eventos en tiempo real): la fuente notifica al sistema IAM cuando algo cambia, mediante webhook o cola de mensajes. Es más complejo de implementar pero baja la latencia a segundos.

Desafíos típicos

• Calidad de datos: si RR. HH. ingresa nombres con typos o emails inconsistentes, esos errores se propagan a todo el resto.
• Latencia entre fuentes: el HRIS puede tardar 24 horas en reflejar un nuevo ingreso, mientras el manager ya quiere darle acceso al sistema. La presión por “saltarse el proceso” es enorme.
• Múltiples sistemas autoritativos para el mismo dato: ¿quién es la autoridad sobre el email — RR. HH. o Active Directory? Si no se decide explícitamente, los dos pelean en silencio.
• Datos faltantes en la fuente: el HRIS puede no tener el grupo de seguridad correcto para el nuevo empleado, así que lo crean con valores por defecto que después no se corrigen.

2. Creación del registro maestro de identidad

Qué es y por qué importa

El registro maestro de identidad (o identity warehouse) es la representación canónica unificada de cada identidad en la organización. Es un solo lugar donde, para cada identidad, viven todos los atributos que importan, con sus respectivas fuentes y fechas de actualización.

Sin este registro, las apps tendrían que ir cada una a las fuentes originales, lo que generaría caos: cada app preguntando lo mismo, cada una con su lógica de cómo combinar datos cuando vienen de varios lugares, cada una con su propio retraso. El warehouse centraliza esa lógica una sola vez.

Estructura típica de un registro

Un registro maestro típicamente tiene:

• Identificador único interno (un GUID, un número, un email canonicalizado): nunca cambia, aunque cambien los demás atributos.
• Atributos primarios: nombre, apellido, email, teléfono, fecha de ingreso, manager.
• Atributos derivados: nivel de antigüedad, ubicación, idioma preferido (calculados a partir de los primarios).
• Estado del lifecycle: activo, suspendido, terminado.
• Historial de cambios (audit log): quién cambió qué, cuándo, desde qué fuente.

Cómo se mantiene actualizado

El warehouse no es estático. Cada vez que la fuente autoritativa empuja un cambio, el warehouse lo procesa a través de un pipeline corto: el evento llega y se normaliza (por ejemplo, “Maria Garcia” se vuelve “MARIA GARCIA”); luego se valida (¿el email tiene el formato correcto? ¿el manager existe?); si pasa, se actualiza el registro maestro y se notifica a las apps consumidoras; si no pasa, cae en una cola de errores para que un humano lo resuelva.

3. Correlación entre identidades y cuentas

El problema que resuelve la correlación

Cuando una identidad existe en el warehouse, la pregunta inmediata es: ¿qué cuentas reales en aplicaciones le pertenecen?. María García en el warehouse podría tener cuenta en Active Directory como mgarcia, en Salesforce como maria.garcia@empresa.com, en SAP como MGARCIA01, en GitHub como mgarciapro. Todas son ella, pero los identificadores son distintos en cada sistema.

La correlación es el proceso que conecta cada identidad maestra con sus cuentas reales en las distintas aplicaciones. Sin correlación, no puedes responder “todos los accesos de María” — solo “todas las cuentas del nombre mgarcia”, lo que no es lo mismo.

Estrategias de correlación

Cómo se ve en la práctica

Imagina el warehouse con María (identidad maestra EMP-08531). El proceso de correlación recorre las apps conectadas:

• Active Directory: encuentra cuenta mgarcia con employeeID=EMP-08531. Match directo. ✓
• Salesforce: encuentra cuenta maria.garcia@empresa.com sin employeeID. Usa email para hacer match. ✓
• SAP: encuentra MGARCIA01 con campo de personnel number 08531. Match con regla. ✓
• GitHub: encuentra usuario mgarciapro que no tiene email corporativo. No match automático. Genera caso para revisión manual.

El resultado de la correlación se guarda en el warehouse como un mapa explícito: identidad EMP-08531 → cuentas en N apps. A partir de ese mapa, todo es más fácil — buscar accesos, certificar, deprovisionar, auditar.

Confianza en la correlación

No toda correlación es igualmente confiable. Una buena plataforma IGA asigna un score:

• Alta confianza (employeeID exacto): 100%, automatizable.
• Media confianza (email + nombre): 70-90%, automatizable con auditoría.
• Baja confianza (solo nombre): <70%, requiere validación humana.

Esta granularidad importa porque a veces es preferible dejar una cuenta como “no correlacionada” antes que correlacionarla mal — una correlación incorrecta puede otorgar accesos a la persona equivocada.

4. Cuentas huérfanas: detección y reconciliación

Qué es una cuenta huérfana

Una cuenta huérfana es una cuenta que existe en una aplicación pero no tiene una identidad maestra correspondiente en el warehouse. Es la cuenta de alguien que ya no existe (o nunca existió formalmente) en la organización pero cuyo acceso sigue vivo.

Las cuentas huérfanas son el cáncer silencioso de cualquier programa IAM. Son la materia prima de los breaches: un exempleado que se llevó sus credenciales, un contratista cuyo contrato terminó pero su cuenta no se desactivó, un usuario de prueba creado por un consultor que se fue.

Por qué se acumulan

Las huérfanas aparecen por razones predecibles:

• Deprovisioning manual fallido: alguien se va, IT olvida desactivar una cuenta.
• Cuentas creadas fuera del flujo formal: un admin las crea directamente en la app, saltándose IGA.
• Apps que se conectan tarde al programa IGA: si una app fue integrada después de su lanzamiento, las cuentas existentes pueden no haberse correlacionado.
• Migraciones sin limpieza: cuando una empresa cambia de plataforma, a veces se migran todas las cuentas sin verificar cuáles son válidas.
• Cambios de email/employeeID sin actualizar los enlaces: si el atributo correlacionado cambia, la conexión se rompe.

Cómo detectarlas

El proceso de reconciliación es la contraparte automática de la correlación. Cada cierto tiempo (típicamente diaria o semanalmente):

1. El sistema IAM extrae todas las cuentas de cada app conectada.
2. Para cada cuenta intenta correlacionarla con una identidad del warehouse.
3. Las que no hacen match se marcan como candidatas a huérfanas.
4. Se genera un reporte que va a los dueños de aplicación o al equipo IAM.

Las candidatas a huérfanas pasan por revisión: a veces son verdaderas huérfanas (deprovisioning olvidado), a veces son cuentas legítimas que solo necesitan correlación manual (un admin de la app, un usuario que cambió de email).

Qué hacer con ellas

5. El ciclo Joiner-Mover-Leaver (JML)

Qué es y por qué es el motor del IAM operativo

El ciclo JML es la versión operativa de “una persona llega → cambia → se va”. Es el motor que ejecuta los cambios de acceso en respuesta a eventos del lifecycle. Sin JML automatizado, todo el resto del programa IAM colapsa: las identidades quedan atrapadas en estados anteriores, los accesos sobreviven a los cambios de rol, y las huérfanas se acumulan. Esta sección es el panorama; el artículo dedicado al ciclo JML abre cada movimiento por completo.

Los tres movimientos

flowchart LR
  accTitle: Los tres movimientos del ciclo JML
  accDescr: Tres eventos de lifecycle alimentan el identity warehouse. Un Joiner dispara el onboarding que crea cuentas y roles; un Mover dispara un cambio que asigna roles nuevos y retira los antiguos; y un Leaver dispara el offboarding que desactiva cuentas.
  J[Joiner<br/>nuevo ingreso] --> ON[Onboarding<br/>crear cuentas + roles]
  M[Mover<br/>cambio interno] --> CHG[Cambio<br/>roles nuevos + retirar antiguos]
  L[Leaver<br/>egreso] --> OFF[Offboarding<br/>desactivar cuentas]
  ON --> WAREHOUSE[(Identity<br/>Warehouse)]
  CHG --> WAREHOUSE
  OFF --> WAREHOUSE

Joiner (nuevo ingreso)

• HRIS dispara el evento de “nuevo empleado” antes del primer día.
• IGA crea identidad en el warehouse.
• Por reglas (basadas en cargo, departamento, ubicación), IGA asigna roles base — los llamados birthright accesses.
• Los workflows aprovisionan cuentas en AD, email, sistemas core — muchas apps modernas vía el estándar de aprovisionamiento SCIM.
• El día del ingreso, todo le funciona desde el primer click.

Mover (cambio interno)

Este es el más subestimado y donde más fallan los programas. Cuando alguien cambia de equipo, idealmente:

• IGA detecta el cambio en HRIS (nuevo manager, nuevo departamento).
• Calcula el nuevo conjunto de roles esperados.
• Retira los roles antiguos que ya no aplican (este paso es el que más se omite, generando privilege creep).
• Asigna los nuevos roles.
• Detecta SoD si el cambio crea conflictos.

Leaver (egreso)

• HRIS dispara “terminated” en una fecha.
• IGA desactiva la identidad en el warehouse.
• Workflows desactivan cuentas en cascada en cada app.
• Sesiones activas se revocan inmediatamente.
• Buzones de email entran en estado de retención según política.
• Después de N días, las cuentas se eliminan (no solo se desactivan) según política de retención.

Casos especiales que rompen JML simple

JML se ve fácil en el papel pero se complica en la realidad:

6. Mapeo de cuentas: el pegamento que conecta todo

El mapeo de cuentas (account mapping, también llamado correlación de cuentas) es el resultado persistente de los procesos anteriores: una tabla viva que dice “identidad X tiene cuentas A, B, C en sistemas 1, 2, 3”.

Esta tabla es el insumo de prácticamente todo lo demás:

• Certificación: cuando un manager certifica los accesos de su gente, está revisando este mapa.
• Reportes para auditoría: mostrar quién tiene acceso a qué requiere que el mapa sea consistente y completo.
• Deprovisioning: cuando una identidad se va, el mapa nos dice qué cuentas hay que desactivar.
• Análisis de riesgo: medir la “exposición” de una identidad implica sumar el riesgo de todas sus cuentas.

Sin un mapa de cuentas confiable, el programa IAM es ciego. Por eso los procesos previos (agregación, correlación, reconciliación) existen — todos alimentan ese mapa.

Caso integrado: el Hospital San Rafael, una semana cualquiera

Para aterrizar todo lo anterior, sigamos una semana en un hospital regional ficticio, “San Rafael”, con 1,200 empleados, 350 médicos rotativos, 80 contratistas (limpieza, seguridad, mantenimiento) y unos 4,500 pacientes registrados al año en su portal. Es un sector donde la complejidad operativa de IAM es de las más altas: regulación HIPAA, médicos que rotan entre múltiples hospitales, dispositivos médicos como identidades, y una mezcla de sistemas legacy y modernos.

Fuentes autoritativas en el hospital

San Rafael tiene tres fuentes autoritativas distintas, no una:

Cada fuente publica eventos a un bus de mensajes (Apache Kafka) que la plataforma IGA del hospital (SailPoint) consume.

Lunes: nuevo médico

Dr. Pablo Méndez, cardiólogo, comienza a trabajar en San Rafael. Ya está acreditado en otros dos hospitales, pero es nuevo aquí. El proceso:

sequenceDiagram
  accTitle: Onboarding de un nuevo médico en el Hospital San Rafael
  accDescr: A las 6:00 AM el sistema de credenciamiento notifica a SailPoint que el Dr. Méndez está activo. SailPoint crea la identidad MD-04127 en el warehouse, aplica el rol de cardiólogo afiliado, y aprovisiona cuentas en Active Directory, Epic y el sistema de laboratorio, de modo que a las 7:30 AM ya puede entrar.
  participant CRED as Sistema credenciamiento
  participant IGA as SailPoint
  participant WH as Identity Warehouse
  participant AD as Active Directory
  participant EPIC as Epic (EMR)
  participant LAB as Sistema laboratorio
  CRED->>IGA: Lunes 6:00 AM — Dr. Méndez activado
  IGA->>WH: Crea identidad MD-04127
  WH->>WH: Aplica reglas: rol "cardiólogo afiliado"
  IGA->>AD: Crea cuenta pmendez con grupos
  IGA->>EPIC: Provisiona acceso a expedientes de cardiología
  IGA->>LAB: Provisiona acceso a resultados de laboratorio
  Note over WH: Lunes 7:30 AM — Dr. Méndez puede entrar

Lectura: a las 6 AM el sistema de credenciamiento publica un evento al bus. SailPoint lo consume, crea la identidad maestra MD-04127, aplica reglas que le dan el rol “cardiólogo afiliado” — un rol que agrupa los accesos típicos para esta función en este hospital. Los workflows ejecutan provisioning en cascada. A las 7:30 AM, cuando el Dr. Méndez llega al hospital, su badge funciona, su login en Epic funciona, y puede ver resultados de laboratorio.

Miércoles: el atributo crítico cambia

A media semana, el sistema de credenciamiento detecta que la licencia del Dr. Méndez se vencerá en 30 días si no la renueva. Publica un evento. SailPoint lo consume y dispara un workflow:

• Notifica al Dr. Méndez por email.
• Notifica al departamento de credenciamiento.
• Programa una alerta para el día 25 si todavía no se ha renovado.
• Si llega el día 30 sin renovación, desactiva automáticamente los accesos a Epic y al laboratorio (porque la regulación HIPAA exige que solo personal con licencia activa acceda a expedientes médicos).

Este es un ejemplo donde el ciclo operativo evita un riesgo regulatorio sin intervención humana. Sin esa automatización, dependeríamos de que alguien recuerde verificar las licencias de 350 médicos cada mes — humanamente imposible.

Jueves: detección de cuenta huérfana

El proceso nocturno de reconciliación detecta una cuenta lcastillo en Epic que no correlaciona con ninguna identidad del warehouse. Genera un caso. Una analista de IAM investiga al día siguiente:

• La cuenta tiene 11 meses sin actividad.
• El nombre coincide con una enfermera que dejó San Rafael hace un año.
• Su lifecycle en Workday se cerró pero por algún error la cuenta de Epic quedó activa.

Acción inmediata: desactivación de la cuenta + reporte forense para revisar si hubo accesos sospechosos en los últimos 11 meses. En este caso no los hubo, pero la auditoría queda en el expediente del programa de cumplimiento HIPAA.

Viernes: contratista que termina

El contrato de la empresa de limpieza vence un viernes. Beeline empuja eventos de “terminated” para 12 contratistas a las 18:00 — incluyendo a Roberto, Marta y Luis, todos los cuales tenían acceso a sistemas de turnos y reportes.

A las 18:01, SailPoint procesa los eventos en cascada:

• Desactiva las 12 identidades en el warehouse.
• Revoca cuentas en el sistema de turnos, en el portal de seguridad, en el sistema de reportes.
• Cierra sesiones activas (uno de ellos seguía con sesión abierta en su tablet).
• Genera reporte para el equipo de seguridad física para que recoja los badges físicos al pasar por la salida.

A las 18:15, los 12 ya no pueden entrar a nada digital. Si alguno intenta volver el lunes, el badge no funciona y los sistemas no le abren.

Lo que muestra el caso

San Rafael ilustra cinco cosas que cualquier programa IAM operacional bien diseñado tiene:

1. Múltiples fuentes autoritativas coordinadas — no una sola, varias según el tipo de identidad.
2. Eventos en tiempo real, no procesos batch del día siguiente.
3. Reglas que se ejecutan automáticamente (vencimiento de licencia, ingreso, egreso) sin requerir aprobaciones manuales en cada caso.
4. Reconciliación regular que encuentra y resuelve huérfanas.
5. Trazabilidad completa para que auditores HIPAA puedan reconstruir cualquier evento meses después.

Recapitulación

El ciclo operativo de IAM es lo que vuelve a los conceptos en realidad funcional. Sus seis procesos principales son:

Sin estos seis procesos operando bien, ningún proyecto IAM produce valor sostenido. Los conceptos de los artículos anteriores son la teoría; el ciclo operativo es la práctica que la sostiene día a día.

Tres preguntas para autoevaluarte

1. Te asignan diagnosticar el ciclo operativo de IAM en una empresa. ¿Qué cinco preguntas haces primero y por qué?
2. Una organización dice “no tenemos cuentas huérfanas porque todo está automatizado”. ¿Qué tres formas hay de que esa afirmación sea falsa aunque ellos crean que es verdadera?
3. Diseña el flujo JML para un caso de “empleado regular pasa a ser contratista del mismo equipo”. ¿Qué pasos son automáticos, cuáles requieren aprobación humana, y por qué?