El ciclo operativo de IAM

Una cuenta que nadie echó de menos

Un jueves por la mañana, Sara, analista de IAM en un hospital regional, abre el informe de reconciliación de la noche y encuentra una cuenta llamada lcastillo en el sistema de historias clínicas. No pertenece a nadie del registro maestro de identidades. Lleva once meses sin usarse. El nombre coincide con el de una enfermera que dejó el hospital hace un año; RR. HH. cerró su ficha a tiempo, pero en algún punto entre RR. HH. y el sistema clínico el cambio se perdió, y la cuenta siguió activa todo ese tiempo. Nadie la echó de menos, y ese es justo el problema.

Los artículos anteriores construyeron los conceptos: qué es una identidad digital, los cuatro tipos modernos, cómo encaja IAM en la ciberseguridad, las cuatro olas históricas y los cinco dominios. Si sabes todo eso pero nunca lo has visto en marcha, te falta la parte más importante.

Los conceptos no flotan en el aire. Viven dentro de una maquinaria que funciona cada día sin parar. Cada vez que alguien entra, cambia de equipo o renueva un contrato, cada vez que un cliente borra su cuenta, hay un proceso de IAM ejecutándose en segundo plano. Cuando esa maquinaria está bien engrasada, nadie lo nota. Cuando está rota, aparecen los síntomas: cuentas huérfanas como lcastillo, accesos que sobreviven a una baja, campañas de certificación que llegan medio vacías, auditorías suspendidas.

Este artículo abre el módulo de IAM en acción mirando dentro de esa maquinaria. Recorre los procesos centrales, la agregación, el registro maestro, la correlación, la reconciliación, el JML y el mapa de cuentas, y después los sigue durante una semana en un hospital, donde la complejidad diaria de IAM es de las más altas que existen. Si te incorporas a un proyecto de IAM como ingeniero o analista, tu primera pregunta debería ser “¿cuál es aquí la fuente autoritativa de las identidades?”. Si la respuesta es vaga, o varias personas te dan respuestas distintas, ya tienes el diagnóstico: el ciclo está roto de raíz.

El ciclo de un vistazo

El ciclo operativo de IAM ejecuta seis procesos sin parar: la agregación desde las fuentes autoritativas, la construcción del registro maestro, la correlación entre identidades y cuentas, la reconciliación de huérfanas, el ciclo de altas, cambios y bajas y el mapa de cuentas. Es un bucle, no una línea, porque lo que sale de cada proceso alimenta al siguiente.

flowchart LR
  accTitle: El ciclo operativo de IAM
  accDescr: Las fuentes autoritativas alimentan la agregación, que construye el registro maestro en el almacén de identidades. La correlación une ese registro con las cuentas de las aplicaciones; la reconciliación devuelve al almacén las cuentas que existen, y los flujos JML llevan los cambios del ciclo de vida 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

Las fuentes autoritativas alimentan la agregación, que produce el registro maestro de identidades. Ese registro se une a las cuentas reales de cada aplicación mediante la correlación. Las aplicaciones devuelven sus cuentas, y la reconciliación encuentra los desajustes, cuentas huérfanas y cuentas sin reclamar, que vuelven al almacén. Encima del almacén funcionan los flujos JML, que disparan cambios en las aplicaciones. Lo que sale por un lado vuelve a entrar por el otro.

La agregación desde las fuentes autoritativas

Una fuente autoritativa es el sistema que tiene la versión verdadera de un atributo. Si quieres el nombre legal de María, se lo preguntas al sistema de RR. HH., no a Salesforce. Su teléfono actual, también a RR. HH. Qué tarjetas de acceso tiene asignadas, probablemente a la herramienta de gestión de servicios de TI. Cada atributo tiene una fuente que es su autoridad.

Importa porque, sin una autoridad declarada, los atributos quedan en el limbo. Si el directorio dice extensión 4521 y SAP dice 4530, ¿cuál es la buena? Sin autoridad, ninguna, y un dato del que no te puedes fiar no sirve para tomar decisiones.

Cada tipo de identidad viene de una fuente distinta. Los empleados vienen de un sistema de RR. HH. como Workday, BambooHR o SAP SuccessFactors, que manda sobre su nombre, su puesto, su jefe, su departamento y sus fechas de alta y baja. Los contratistas externos vienen de un sistema de gestión de contratistas como Beeline o Fieldglass, que manda sobre el proveedor y la fecha de fin del contrato. Los clientes vienen de un CRM como Salesforce o Dynamics. Los dispositivos y los workloads vienen de una CMDB como ServiceNow, con el nombre de máquina, el responsable y la ubicación. Y en un hospital, los médicos vienen de un sistema de acreditación médica que conoce su licencia, su especialidad y los hospitales a los que están afiliados.

Los datos pasan de la fuente a IAM de dos formas básicas. Con pull, el sistema de IAM consulta la fuente según un calendario, cada quince minutos, cada hora o cada noche. Es sencillo, pero añade retraso: alguien cuyo contrato empieza a las 5:55 puede entrar en la consulta de las seis o no aparecer hasta mañana. Con push, la fuente avisa al sistema de IAM cuando algo cambia, mediante un webhook o una cola de mensajes. Cuesta más construirlo, pero baja el retraso a segundos.

Los problemas habituales son previsibles. La calidad de los datos: si RR. HH. escribe nombres con errores o correos incoherentes, esos errores se extienden a todo lo demás. El retraso entre fuentes: el sistema de RR. HH. puede tardar un día en mostrar una incorporación mientras su jefe ya la quiere dentro de los sistemas, y la presión para “saltarse el proceso” es enorme. Dos autoridades para un mismo campo: ¿quién manda sobre el correo, RR. HH. o Active Directory? Si nadie lo decide de forma explícita, los dos se pelean en silencio. Y los huecos en la fuente: RR. HH. puede no saber qué grupo de seguridad necesita una incorporación, así que recibe valores por defecto que nadie corrige jamás. Decidir y documentar las fuentes autoritativas es una de las decisiones más estratégicas de cualquier programa de IAM. Hacerlo el primer día ahorra años de discusiones; aplazarlo obliga a que cada proyecto nuevo vuelva a negociar lo mismo.

El registro maestro

El registro maestro de identidades, o almacén de identidades, es la versión única y canónica de cada identidad de la organización: un sitio donde, para cada identidad, viven juntos todos los atributos que importan, con sus fuentes y la fecha de su última actualización. Sin él, cada aplicación tendría que ir por su cuenta a las fuentes originales, cada una haciendo las mismas preguntas, cada una con su propia lógica para combinar datos de varios sitios y cada una con su propio retraso. El almacén hace ese trabajo una sola vez.

Un registro maestro suele tener un identificador interno único, un GUID, un número o un correo normalizado, que nunca cambia aunque cambie todo lo demás; atributos primarios como el nombre, el correo, el teléfono, la fecha de alta y el jefe; atributos derivados como la antigüedad, la ubicación o el idioma preferido, calculados a partir de los primarios; un estado del ciclo de vida, activo, suspendido o de baja, y un historial de quién cambió qué, cuándo y desde qué fuente.

No es algo estático. Cada vez que una fuente envía un cambio, el almacén lo pasa por una cadena corta. El evento llega y se normaliza, de modo que “Maria Garcia” pasa a ser “MARIA GARCIA”. Después se valida: ¿el correo tiene buen formato?, ¿existe el jefe? Si pasa, se actualiza el registro y se avisa a las aplicaciones que dependen de él. Si no, va a una cola de errores para que lo resuelva una persona. Tampoco hace falta que el almacén sea una base de datos especial. Muchas organizaciones lo tienen dentro de su plataforma de IGA, lo que SailPoint y Saviynt llaman “identity cube” o “identity profile”. La idea es la misma: una única fuente de verdad para cada identidad.

La correlación entre identidades y cuentas

Una vez que una identidad está en el almacén, la siguiente pregunta es ¿qué cuentas reales de qué aplicaciones le pertenecen? María García en el almacén puede ser mgarcia en Active Directory, maria.garcia@company.com en Salesforce, MGARCIA01 en SAP y mgarciapro en GitHub. Todas son ella, con un identificador distinto en cada sistema. La correlación une cada identidad maestra con sus cuentas reales. Sin ella no puedes responder a “enséñame todos los accesos de María”, solo a “enséñame todas las cuentas llamadas mgarcia”, que no es lo mismo.

Hay varias formas de correlacionar. Por correo, suponiendo que es el mismo en todas partes, lo que funciona en las aplicaciones SaaS modernas que usan inicio de sesión único con el correo. Por identificador de empleado, cuando el identificador de RR. HH. se envió con el aprovisionamiento original y está presente en cada aplicación. Por nombre más otro atributo único, como la fecha de nacimiento, para aplicaciones heredadas sin identificador corporativo. A mano, con un analista emparejando cuentas una a una, para aplicaciones muy heterogéneas y casos especiales. Y por reglas con una puntuación de confianza, combinando varias señales, para grandes volúmenes de datos imperfectos.

Imagina el almacén con María, identidad maestra EMP-08531, y el proceso de correlación recorriendo las aplicaciones conectadas. En Active Directory encuentra mgarcia con employeeID=EMP-08531, una coincidencia directa. En Salesforce encuentra maria.garcia@company.com sin identificador de empleado y empareja por el correo. En SAP encuentra MGARCIA01 con un número de personal 08531 y empareja por regla. En GitHub encuentra mgarciapro sin ningún correo corporativo, así que no hay coincidencia automática y se abre un caso para revisarlo a mano. El resultado se guarda en el almacén como un mapa explícito, la identidad EMP-08531 con sus cuentas en cada aplicación, y a partir de ahí buscar accesos, certificar, retirar accesos y auditar es mucho más fácil.

No todas las correlaciones son igual de fiables, y una buena plataforma de IGA las puntúa. Un identificador de empleado exacto da confianza alta y se puede automatizar. Correo más nombre da confianza media, entre el 70 y el 90 %, y se puede automatizar dejando rastro para auditoría. Solo el nombre queda por debajo del 70 % y necesita que una persona lo confirme. Importa porque a veces es mejor dejar una cuenta sin correlacionar que correlacionarla mal; un emparejamiento equivocado puede darle acceso a la persona equivocada.

Las cuentas huérfanas

Una cuenta huérfana es una cuenta que existe en una aplicación pero no tiene ninguna identidad que le corresponda en el almacén. Pertenece a alguien que ya no existe en la organización, o que nunca existió formalmente, y su acceso sigue vivo. Las cuentas huérfanas son la carcoma silenciosa de cualquier programa de IAM y la materia prima de las brechas: un exempleado que se llevó su contraseña, un contratista cuyo contrato terminó pero cuya cuenta no se desactivó, un usuario de pruebas que creó un consultor antes de irse.

Aparecen por motivos previsibles. Alguien se va y TI olvida una cuenta. Un administrador crea una cuenta directamente en una aplicación, saltándose el IGA. Una aplicación se incorporó al programa de IGA después de ponerse en marcha y sus cuentas existentes nunca se correlacionaron. Una migración de plataforma se llevó todas las cuentas sin comprobar cuáles seguían siendo válidas. O cambió un correo o un identificador de empleado y se rompió el vínculo que dependía de él. lcastillo fue una de esas.

La reconciliación es la contrapartida automática de la correlación. Cada día o cada semana, el sistema de IAM extrae todas las cuentas de cada aplicación conectada, intenta emparejar cada una con una identidad del almacén y marca las que no encajan como candidatas a huérfanas, que van en un informe a los responsables de las aplicaciones o al equipo de IAM. Algunas candidatas son huérfanas de verdad, olvidadas cuando alguien se fue. Otras son cuentas legítimas que solo necesitan un emparejamiento manual, el propio administrador de una aplicación o un usuario que cambió de correo.

Lo que pasa después depende del tipo de huérfana. La cuenta de un exempleado se desactiva de inmediato y alguien revisa qué hizo después de su marcha. La de un contratista se desactiva y se revisa el contrato con el proveedor. Una cuenta de servicio sin responsable recibe uno formalmente o se desactiva. Una cuenta de pruebas o de demostración se documenta o se borra. Y una cuenta válida que simplemente no estaba correlacionada se empareja a mano y se vincula al almacén. Normas como HIPAA, SOX y PCI DSS, y marcos de control como la NIST SP 800-53 con su control de gestión de cuentas AC-2, exigen de forma explícita encontrar y eliminar cuentas huérfanas con regularidad. No tener un proceso de reconciliación documentado es casi una no conformidad de auditoría asegurada.

Altas, cambios y bajas

El ciclo JML, joiner, mover y leaver, es la versión práctica de “alguien llega, cambia y se va”. Es el motor que modifica los accesos en respuesta a los eventos del ciclo de vida, y si no está automatizado el resto del programa se desmorona: las identidades se quedan atascadas en estados antiguos, los accesos sobreviven a los cambios de puesto y las huérfanas se acumulan. Esto es una visión general; el artículo del ciclo JML abre cada paso a fondo.

flowchart LR
  accTitle: Los tres movimientos del ciclo JML
  accDescr: Tres eventos del ciclo de vida alimentan el almacén de identidades. Un alta dispara la incorporación, que crea cuentas y roles; un cambio dispara una modificación que asigna roles nuevos y retira los antiguos, y una baja dispara la salida, que desactiva las 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

En un alta, el sistema de RR. HH. dispara un evento de “empleado nuevo” antes del primer día. El IGA crea la identidad en el almacén y, con reglas basadas en el puesto, el departamento y la ubicación, asigna los roles básicos, los llamados accesos de nacimiento. Después los flujos crean cuentas en el directorio, el correo y los sistemas principales, muchas a través del estándar de aprovisionamiento SCIM, para que el primer día todo funcione desde el primer clic.

El cambio de puesto es el paso más infravalorado y en el que fallan la mayoría de los programas. Cuando alguien cambia de equipo, el IGA debería notar el cambio en RR. HH., un jefe o un departamento nuevos, calcular el nuevo conjunto de roles, retirar los roles antiguos que ya no aplican, añadir los nuevos y comprobar si el cambio crea un conflicto de separación de funciones. La retirada es el paso que más se salta, y de ahí sale la acumulación de privilegios.

En una baja, RR. HH. marca a la persona como dada de baja en una fecha. El IGA desactiva la identidad en el almacén, los flujos desactivan sus cuentas en todas las aplicaciones, las sesiones activas se revocan de inmediato, el buzón pasa a retención según la política y, al cabo de unos días fijados, las cuentas se borran, no solo se desactivan.

El JML parece fácil sobre el papel y se complica enseguida. ¿Qué pasa cuando un empleado pasa a ser contratista en el mismo equipo: se le quita todo y se le dan roles de contratista, y cómo se coordina? Si alguien vuelve a la empresa unos meses después, ¿se reutiliza su identidad antigua o se crea una nueva? Durante una baja médica larga, ¿qué accesos se mantienen? Si alguien se muda de país, ¿exigen las normas locales algo distinto? ¿Cómo se gestiona al personal de temporada que entra y sale en bloque cada año? Y en un despido urgente, ¿cómo se desactiva todo en minutos sin esperar a la ejecución nocturna? Las plataformas de IGA resuelven bien los casos sencillos, un alta normal, una baja planificada. La calidad de un programa se ve en estos casos límite, y un programa que se hunde en el primero está mal diseñado.

El mapa de cuentas

El mapa de cuentas es el resultado duradero de todo lo anterior: una tabla viva que dice “la identidad X tiene las cuentas A, B y C en los sistemas 1, 2 y 3”. Casi todo lo demás se alimenta de ella. Cuando un jefe certifica los accesos de su equipo, está revisando este mapa. Los informes de auditoría que muestran quién tiene acceso a qué necesitan que esté completo y sea coherente. Cuando alguien se va, el mapa dice qué cuentas desactivar. Y medir la exposición de una identidad supone sumar el riesgo de todas sus cuentas. Sin un mapa fiable, el programa de IAM está ciego, y por eso existen la agregación, la correlación y la reconciliación: todas lo alimentan.

Una semana en el hospital San Rafael

Para verlo todo funcionando, sigue una semana en San Rafael, un hospital regional ficticio con 1.200 empleados, 350 médicos que rotan entre hospitales, 80 contratistas de limpieza, seguridad y mantenimiento, y unos 4.500 pacientes que se registran cada año en su portal. Es un sector donde el IAM operativo es de lo más complejo que hay: HIPAA, médicos que trabajan en varios hospitales, equipos médicos como identidades y una mezcla de sistemas antiguos y nuevos.

San Rafael tiene tres fuentes autoritativas, no una. El personal administrativo viene de Workday, con su nombre, su departamento, su jefe y su fecha de alta. Los médicos y el personal de enfermería vienen de un sistema de acreditación médica hecho a medida, con su licencia, su especialidad, la caducidad de la licencia y los hospitales a los que están afiliados. Los contratistas vienen de Beeline, con el proveedor, el contrato, su fecha de fin y su nivel de acceso. Cada fuente publica eventos en un bus de mensajes, Apache Kafka, que lee la plataforma de IGA del hospital, SailPoint.

El lunes, el doctor Pablo Méndez, cardiólogo, empieza en San Rafael. Ya está acreditado en otros dos hospitales, pero aquí es nuevo.

sequenceDiagram
  accTitle: Incorporación de un médico nuevo en el hospital San Rafael
  accDescr: A las 6:00 el sistema de acreditación avisa a SailPoint de que el doctor Méndez está activo. SailPoint crea la identidad MD-04127 en el almacén, 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 ya puede iniciar sesión.
  participant CRED as Acreditación
  participant IGA as SailPoint
  participant WH as Warehouse
  participant AD as AD
  participant EPIC as Epic (EMR)
  participant LAB as Laboratorio
  CRED->>IGA: Lunes 6:00, Dr. Méndez activado
  IGA->>WH: Crea la identidad MD-04127
  WH->>WH: Aplica reglas: rol "cardiólogo afiliado"
  IGA->>AD: Crea la cuenta pmendez con sus grupos
  IGA->>EPIC: Da acceso a historias de cardiología
  IGA->>LAB: Da acceso a resultados de laboratorio
  IGA->>IGA: Lunes 7:30, Dr. Méndez puede entrar

A las seis de la mañana, el sistema de acreditación publica un evento. SailPoint lo lee, crea la identidad maestra MD-04127 y aplica reglas que le dan el rol “cardiólogo afiliado”, que agrupa los accesos habituales de ese puesto en este hospital. Los flujos lo aprovisionan todo en cascada, y cuando el doctor Méndez llega a las siete y media, su tarjeta funciona, puede entrar en Epic y ve los resultados del laboratorio.

El miércoles, el sistema de acreditación detecta que la licencia del doctor Méndez caduca en treinta días si no la renueva, y publica un evento. SailPoint pone en marcha un flujo: le envía un correo al doctor, avisa al departamento de acreditación, programa un recordatorio para el día 25 si no ha renovado y, si llega el día 30 sin renovación, le retira automáticamente el acceso a Epic y al laboratorio, porque HIPAA solo permite ver historias clínicas al personal con licencia vigente. El ciclo evita un riesgo normativo sin que nadie mueva un dedo. Sin esa automatización, alguien tendría que revisar cada mes las licencias de 350 médicos, cosa que sencillamente no pasaría.

El jueves, Sara encuentra lcastillo, la cuenta del principio de este artículo. Investiga: lleva once meses inactiva, el nombre coincide con el de una enfermera que se fue hace un año, y su ficha se cerró en Workday, pero un error dejó activa la cuenta de Epic. Sara la desactiva y pide una revisión forense de cualquier acceso en esos once meses. No hubo ninguno, pero la revisión queda en el expediente de cumplimiento de HIPAA del hospital.

El viernes termina el contrato de la empresa de limpieza. A las seis de la tarde, Beeline envía eventos de “baja” para doce contratistas, entre ellos Roberto, Marta y Luis, que tenían acceso al sistema de turnos y a los informes. A las 18:01 SailPoint los procesa en cascada: desactiva las doce identidades en el almacén, retira sus cuentas en el sistema de turnos, el portal de seguridad y el sistema de informes, cierra sus sesiones activas, una de las cuales seguía abierta en una tableta, y envía al equipo de seguridad física una lista para recoger las tarjetas a la salida. A las 18:15 ninguno de los doce puede entrar en nada digital, y si alguno vuelve el lunes, ni la tarjeta ni los sistemas le dejarán pasar.

San Rafael muestra lo que tiene un programa operativo bien diseñado: varias fuentes autoritativas coordinadas, una por tipo de identidad; eventos en tiempo real en lugar de lotes al día siguiente; reglas que se ejecutan solas para la caducidad de licencias, las altas y las bajas sin una aprobación manual cada vez; una reconciliación periódica que encuentra y limpia huérfanas, y un rastro completo que permite a los auditores de HIPAA reconstruir cualquier evento meses después.

Resumen

El ciclo operativo es lo que convierte los conceptos en algo que funciona. La agregación responde de dónde vienen los datos verdaderos sobre las identidades. El registro maestro, cuál es la versión única y canónica de cada identidad. La correlación, qué cuentas reales pertenecen a cada identidad. La reconciliación, qué cuentas siguen vivas sin un dueño formal. El JML, cómo llegan a los accesos los cambios del ciclo de vida. Y el mapa de cuentas, quién tiene qué, completo. Sin esos seis funcionando bien, ningún proyecto de IAM aporta valor duradero. Los artículos anteriores eran la teoría; este ciclo es la práctica que la sostiene cada día, y la que en San Rafael convirtió una cuenta olvidada en un ticket de jueves por la mañana y no en una brecha.

Tres preguntas para ponerte a prueba

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