El ciclo JML: Joiner, Mover, Leaver en profundidad

Diez años, cinco equipos, un hallazgo de auditoría

Daniel lleva diez años en la misma empresa de distribución. Empezó en compras, pasó a planificación de almacén, estuvo dos años en cuentas a pagar, cubrió una temporada a un jefe en logística y ahora dirige un pequeño equipo de analítica. Cada cambio trajo accesos nuevos, que pidió su nuevo jefe y se aprobaron en un día. Ninguno le quitó nada. Durante una auditoría de SOX, una consulta rutinaria encuentra algo que nadie pretendía: Daniel puede dar de alta un proveedor en el ERP, un permiso que le quedó de compras, y aprobar pagos a proveedores, que le quedó de cuentas a pagar. Nadie decidió nunca que pudiera hacer las dos cosas. Simplemente se fue acumulando.

El ciclo operativo de IAM presentó los seis procesos que mantienen en marcha un programa de IAM, y el JML era uno de ellos, visto de lejos. Este artículo abre esa caja del todo, porque en el JML está la mayor parte del valor de un programa de IAM, y también la mayoría de sus fallos. Todos los demás procesos existen para servirle. La agregación y el registro maestro existen para que el JML sepa quién ha cambiado. La correlación y la reconciliación, para que sepa qué cuentas tocar. La certificación, para pillar lo que se le escapó. Si el JML funciona, el resto del programa tiene una oportunidad; si falla, ningún panel ni ninguna auditoría te salvará, porque te pasarás la vida limpiando accesos que ya no se corresponden con la realidad.

En una frase, el JML es la disciplina de mantener el acceso de una persona igual a lo que justifica su relación actual con la organización, ni más ni menos, en cada momento desde antes de su primer día hasta después del último.

El ciclo de vida como máquina de estados

Antes de los tres movimientos, hace falta ver el camino por el que se mueven. Una identidad no está simplemente “activa” o “fuera”. Pasa por una serie de estados bien definidos, y cada cambio de estado es un evento al que el JML tiene que reaccionar. Pensar en estados es lo que separa un programa sólido de uno que solo resuelve el camino fácil.

stateDiagram-v2
  accTitle: El ciclo de vida de la identidad como máquina de estados
  accDescr: Una identidad empieza como prospecto cuando se aprueba la contratación, pasa a activa en la fecha de inicio con el flujo de alta, puede volver a activa una y otra vez con los cambios de puesto, puede pasar a suspendida durante una licencia y volver a activa al regresar, pasa a terminada al irse con el flujo de baja y, desde terminada, vuelve a activa si se la recontrata o pasa a eliminada cuando termina el periodo de retención.
  [*] --> Prospecto: contratación aprobada
  Prospecto --> Activa: fecha de inicio (Joiner)
  Activa --> Activa: cambio de rol (Mover)
  Activa --> Suspendida: licencia
  Suspendida --> Activa: regreso
  Activa --> Terminada: salida (Leaver)
  Terminada --> Activa: recontratación
  Terminada --> Eliminada: termina la retención
  Eliminada --> [*]

Una persona pasa a ser prospecto en cuanto se aprueba su contratación, a menudo días o semanas antes de empezar. En la fecha de inicio, el flujo de alta la convierte en activa. Mientras está activa puede pasar muchas veces por el bucle de cambio de puesto. Una licencia la deja suspendida, un estado en el que el acceso queda congelado pero no destruido. Irse dispara el flujo de baja hacia terminada, pero ese no es el final: una recontratación puede devolverla a activa, y solo después de un periodo de retención que fija la política llega la identidad a eliminada.

Los dos estados que la gente olvida son el de suspendida y el hueco entre terminada y eliminada. Un programa que trata “terminada” como “borrar ya” pierde pruebas forenses y rompe la propiedad de los datos. Un programa sin estado de suspensión, o quita todo durante una baja por maternidad o, peor, deja el acceso completo a alguien que no está.

Los tipos de acceso que mueve el JML

El JML mueve accesos de un lado a otro, así que no se puede razonar sobre él sin saber qué tipos de acceso existen. Los programas modernos usan cuatro, y el arte está en poner cada permiso en el cajón correcto.

La diferencia importa mucho. El acceso de nacimiento y el acceso por rol son los que los flujos de alta y de cambio automatizan; se calculan a partir de atributos, así que el sistema puede darlos y quitarlos sin intervención humana. El solicitable es el que esos flujos no pueden suponer, porque necesita la intención de alguien y una aprobación. Y el acceso justo a tiempo es la vía de escape que impide que lo solicitable se convierta en deuda permanente: en lugar de conceder un acceso fijo que alguien olvidará retirar en el próximo cambio de puesto, lo concedes mientras hace falta y dejas que caduque. En un programa sano, alrededor del 60 % de los accesos de un usuario típico son de nacimiento o por rol, cerca del 30 % son solicitables y están gobernados por aprobaciones y certificaciones, y el pequeño resto es justo a tiempo para las operaciones de verdad sensibles. Cuando casi todo es solicitable, la automatización se queda corta; cuando casi todo es de nacimiento, se ha concedido de más y se ha perdido el mínimo privilegio.

Altas: acertar el primer día

El flujo de alta tiene un objetivo engañosamente difícil: que la persona nueva sea productiva desde el primer clic y que tenga solo los accesos que justifica su puesto. Las dos mitades importan. Si das de menos, el jefe empieza a abrir tickets urgentes y la primera impresión de quien llega es la fricción; si das de más, has sembrado la acumulación de privilegios antes de que haya iniciado sesión.

Un flujo de alta maduro no es un evento sino tres. Antes de la fecha de inicio, en cuanto se acepta la oferta, el sistema de RR. HH. crea una identidad en estado de prospecto, y el IGA puede preparar las cuentas desactivadas, pedir el equipo y programar la formación, para que nada se cree con prisas esa misma mañana. El primer día, la identidad pasa a activa, las cuentas preparadas se encienden, se aplican los accesos de nacimiento y por rol, y se entregan las credenciales; como el trabajo pesado ya estaba hecho, este paso es rápido y de poco riesgo. Y durante el periodo de prueba, algunos accesos se retienen a propósito, el acceso a producción, la capacidad de firma, los sistemas sensibles, hasta que la persona supera el periodo de prueba o completa la formación obligatoria. Programarlo como un cambio con fecha y no como un recordatorio manual es lo que impide que se olvide.

La ventana previa al inicio es cómoda y a la vez arriesgada, porque las cuentas existen antes que la persona. Tienen que crearse desactivadas, con la activación ligada a la fecha de inicio real. Una cuenta preparada que se activa antes de tiempo, o que un atacante encuentra y usa en ese hueco, es una forma discreta de entrar en el entorno con una identidad de apariencia legítima.

La peor costumbre en las altas es copiar accesos: “dale a Sara lo mismo que a Daniel, que están en el mismo equipo”. Parece eficiente y es un desastre. Daniel, como hemos visto, acumula diez años de concesiones puntuales, y Sara las heredaría todas el primer día. El acceso de nacimiento tiene que calcularse a partir de atributos, el puesto, el departamento, la ubicación, el tipo de contrato, no copiarse de una persona que es un montón de excepciones históricas. Llevar ese acceso a las aplicaciones se apoya cada vez más en SCIM, el System for Cross-domain Identity Management, que da al IGA una API estándar para crear, actualizar y desactivar cuentas en el SaaS moderno y sustituye a los frágiles conectores por aplicación de hace una década.

Cambios de puesto: donde los programas fallan en silencio

Si te quedas con una sola cosa de este artículo, que sea esta: el cambio de puesto es la parte más difícil y más descuidada del JML, y se descuida por un motivo estructural. Cuando alguien cambia de puesto, darle los accesos nuevos es visible: los necesita, los pide, alguien celebra el ascenso. Quitarle los que ya no necesita es invisible: no se rompe nada si te lo saltas, nadie se queja y la persona sigue trabajando. Así que se salta, y cada vez que se salta, el acceso se acumula.

El resultado es la acumulación de privilegios, la historia de Daniel: alguien que ha pasado por cinco equipos acaba con la suma de los accesos de los cinco. Nadie decidió que los tuviera; son sedimentos. Y no es solo desorden. Los accesos que se solapan entre funciones distintas son justo la forma en que nacen las violaciones de separación de funciones. A Daniel no le dieron a propósito el poder de crear un proveedor y pagarle; recogió una mitad hace años y la otra en un cambio posterior.

flowchart TB
  accTitle: El flujo de decisión del cambio de puesto
  accDescr: Un evento de cambio en el sistema de RR. HH., de departamento, jefe o puesto, dispara el recálculo del conjunto de roles esperado. El sistema compara lo esperado con el acceso actual y se divide en tres ramas: se aprovisionan los roles nuevos que hacen falta, se retiran los que ya no se justifican y se deja igual lo que no cambia. Los accesos añadidos se comprueban contra la separación de funciones; un conflicto exige una excepción o una aprobación, y en todos los casos el cambio se registra y se programa una recertificación.
  EVENT[Evento de cambio en HRIS<br/>depto / manager / puesto] --> CALC[Recalcular conjunto de roles esperado]
  CALC --> DIFF{Comparar con acceso actual}
  DIFF -->|roles nuevos necesarios| ADD[Aprovisionar roles nuevos]
  DIFF -->|ya no justificados| REMOVE[Retirar roles viejos]
  DIFF -->|sin cambios| KEEP[Dejar igual]
  ADD --> SOD{¿Conflicto SoD?}
  SOD -->|sí| EXC[Exigir excepción + aprobación]
  SOD -->|no| CERT[Registrar + programar recertificación]
  EXC --> CERT
  REMOVE --> CERT
  KEEP --> CERT

La rama que importa es la del medio, retirar los roles viejos, porque es la que se saltan los procesos que dependen de personas. Un cambio de puesto correcto recalcula todo el conjunto de roles esperado a partir de los atributos nuevos y concilia con él el acceso actual en las dos direcciones: añade lo que falta y quita lo que ya no se justifica. Añadir sin quitar no es un cambio de puesto; es una segunda alta apilada encima de la primera. La forma más limpia de pensarlo es que un cambio de puesto es una pequeña baja del puesto antiguo y una pequeña alta en el nuevo, ejecutadas a la vez. Visto así, quitar el acceso antiguo no es opcional; es la mitad de la operación.

Los cambios laterales sencillos son fáciles. Los casos que muestran la calidad real de un programa son otros. Un ascenso dentro del mismo equipo conserva unos accesos, eleva otros y quita algunos, y un solapamiento parcial es más difícil que un intercambio limpio. Un traslado a otro departamento trae dos conjuntos de roles que pueden chocar, así que la separación de funciones hay que revisarla desde cero. Una asignación temporal o comisión de servicio debería ver caducar sus accesos automáticamente al volver, que es justo para lo que existe el acceso justo a tiempo. Un paso de empleado a contratista, o al revés, cambia toda la base del acceso e incluso su fuente autoritativa. Y un puesto en funciones o interino trae un acceso elevado que tiene que estar claramente limitado en el tiempo y ser reversible.

Bajas: quitar el acceso antes de que sea un problema

El flujo de baja es donde IAM protege a la organización de forma más visible, y donde la rapidez es una propiedad de seguridad. Cada minuto que alguien que se ha ido conserva su acceso es un minuto de exposición: a una salida enfadada, a un dispositivo personal comprometido o simplemente a una cuenta que ya nadie vigila.

No todas las bajas son iguales, y el flujo tiene que distinguirlas. Una salida planificada, una dimisión o una jubilación con preaviso, puede ejecutarse el último día previsto, con el traspaso del buzón y de los datos organizado de antemano. Una salida inmediata, un despido disciplinario o cualquier situación en la que el acceso tiene que desaparecer ya, no puede esperar a un lote nocturno. Necesita un camino en tiempo real que desactive las cuentas y corte las sesiones activas en minutos. Un programa que solo tiene el camino planificado es peligroso, porque el caso en el que la rapidez más importa es justo el que no sabe resolver.

El error más común en las bajas es tratar “quitar el acceso” y “borrar la cuenta” como lo mismo. No lo son, y mezclarlos destruye pruebas. De inmediato, se desactiva la cuenta, se revocan las sesiones y los tokens activos y se saca a la persona de los grupos, de modo que el acceso desaparece en minutos. Durante el periodo de retención, la cuenta desactivada se conserva intacta, el buzón pasa a retención o a conservación legal, el jefe recibe acceso delegado para el traspaso y los datos de la persona se reasignan. Solo después del periodo de retención se borra la cuenta, según el reloj que marcan la política y la normativa. Borrar el primer día parece limpio pero es un error: has borrado el rastro que podría necesitar un investigador, has dejado huérfanos los documentos de la persona y has hecho que rebote cualquier correo que le envíen.

Las bajas no son la única fuente de accesos muertos. Las cuentas durmientes, cuentas activas que nadie usa desde hace meses, son un riesgo con forma de baja escondido a la vista: un contratista cuyo encargo terminó sin ruido, una cuenta de servicio de una aplicación que se apagó, un empleado con una licencia larga. Un programa maduro ejecuta la detección de cuentas durmientes junto al JML y cuestiona todo lo que lleve inactivo más de un umbral, porque una cuenta activa olvidada es, a efectos prácticos, una baja sin procesar. Los contratistas son el mayor punto ciego. Su salida muchas veces no es un evento limpio de “baja” en RR. HH.; el contrato simplemente vence y el proveedor puede no avisarte a tiempo. Sin una fecha de fin de contrato autoritativa que alimente el flujo de baja, los accesos de los contratistas sobreviven una y otra vez al encargo, así que cada identidad de contratista necesita una fecha de fin firme, y una fecha que falta o que se alarga debe tratarse como una excepción que hay que revisar.

Quién es responsable de qué

El JML falla tanto por responsabilidades poco claras como por malas herramientas. Cada movimiento toca varias funciones, y cuando todo el mundo es responsable, nadie lo es.

RR. HH. es dueño de los hechos autoritativos: la contratación y la fecha de inicio en un alta, el cambio de puesto registrado que dispara un cambio, la fecha de baja cuando alguien se va. El jefe pide los accesos propios del puesto cuando alguien entra, confirma lo que la persona sigue necesitando cuando cambia y avisa de las salidas urgentes. La plataforma de IAM o IGA calcula los accesos de nacimiento y por rol y los aprovisiona, recalcula y concilia los accesos en cada cambio, y desactiva cuentas, revoca sesiones y programa el borrado cuando alguien se va. Los responsables de las aplicaciones aprueban los permisos sensibles, los vuelven a aprobar tras un cambio y confirman la retirada en su aplicación. Y seguridad revisa las excepciones de separación de funciones en los cambios e investiga las salidas urgentes.

El fallo que se repite está en la parte del jefe en los cambios de puesto. Los jefes piden encantados accesos nuevos para su gente y guardan un silencio fiable sobre lo que habría que quitar. Por eso es la plataforma de IGA, y no el jefe, quien tiene que encargarse de “retirar los roles viejos”, a partir de un recálculo y no de que alguien se acuerde de pedirlo. En la empresa de Daniel, cada jefe que tuvo hizo su trabajo tal como lo entendía, y el hueco era justamente que nadie era responsable de quitar.

Qué madurez tiene y cómo saberlo

La madurez del JML es una escalera, y la mayoría de las organizaciones pueden situarse en ella con honestidad. En el nivel 1 todo es manual: tickets de TI, hojas de cálculo y conocimiento en la cabeza de la gente, y las bajas se arrastran durante semanas con cuentas huérfanas por todas partes. En el nivel 2 funciona con tickets: formularios y aprobaciones estándar, todavía ejecutados por personas, coherente pero lento, con los cambios de puesto a medias. En el nivel 3 funciona por eventos: los eventos de RR. HH. disparan el aprovisionamiento y la retirada automáticos, las altas y las bajas son rápidas y los cambios se concilian. Y en el nivel 4 es continuo: el acceso fijo se reduce al mínimo, se concede justo a tiempo y caduca solo, de modo que la acumulación de privilegios queda impedida por diseño.

La mayoría de las organizaciones están en el nivel 2 y creen estar en el 3. La prueba honesta es el cambio de puesto. Si retirar roles en un traslado es automático y fiable, estás en el nivel 3; si depende de que alguien se acuerde, estás en el 2, por muy pulido que parezca el flujo de alta.

Unas pocas cifras cuentan la verdad deprisa. El tiempo hasta aprovisionar, de la fecha de inicio al acceso que funciona, debería medirse en horas, no en días. El tiempo hasta retirar, del evento de baja al acceso completamente eliminado, debería ser de minutos en los casos urgentes. La tasa de automatización, la parte de los cambios de acceso que se ejecutan sin que los toque una persona, es el mejor indicador único de madurez. La tasa de huérfanas, las cuentas sin identidad que encuentra la reconciliación, mide directamente los fallos de las bajas. Un indicador de acumulación de privilegios, la media de permisos por usuario subiendo con el tiempo o el número de personas con más roles de los que justifica su puesto actual, es el boletín de notas del cambio de puesto. Y el número de violaciones de separación de funciones es, sobre todo, deuda acumulada de cambios de puesto. Si solo puedes medir una, mide el tiempo hasta retirar el acceso en las bajas, con pruebas. Es lo que más les importa a los reguladores, lo que más examinará el análisis posterior a una brecha y la señal más clara de que tu flujo de baja es real y no un deseo.

Cómo se rompe el JML

Los mismos fallos aparecen en una organización tras otra, y conocerlos por su nombre permite buscarlos a propósito. La acumulación de privilegios viene de cambios de puesto que añaden y nunca quitan, y lleva a conflictos de separación de funciones y a un radio de impacto mucho mayor. Las cuentas huérfanas vienen de bajas que no llegan a todas las aplicaciones, y se convierten en accesos durmientes y en materia prima para brechas. Una baja urgente lenta viene de no tener un camino de retirada en tiempo real, y deja una ventana de exposición tras una salida de riesgo. La fricción del primer día viene de un flujo de alta demasiado lento o que da demasiado poco, y lleva al shadow IT y a concesiones de emergencia excesivas. La copia de accesos viene de clonar el acceso de nacimiento de un compañero, y transmite años de excesos históricos. Los contratistas que se quedan de más vienen de no tener una fecha de fin de contrato autoritativa. Y el acceso privilegiado fijo viene de no tener una opción justo a tiempo para los permisos sensibles, lo que deja objetivos de alto valor permanentes.

Fíjate en cuántos de esos fallos vuelven al cambio de puesto y a la baja, el lado de la retirada del ciclo de vida. Dar acceso es la mitad fácil y popular; la disciplina de un programa de IAM está casi entera en quitarlo.

Por qué el JML no es opcional

El JML no es solo buena higiene; todos los marcos de control serios lo exigen, de forma explícita o implícita. La NIST SP 800-53, en su control de gestión de cuentas AC-2, exige crear, habilitar, modificar, deshabilitar y eliminar cuentas ante disparadores definidos, que es el JML en el lenguaje de los controles. SOX exige que el acceso a los sistemas financieros se corresponda con las responsabilidades actuales, algo imposible sin cambios de puesto y bajas que funcionen, y justo lo que comprobó la auditoría de Daniel. La regla de seguridad de HIPAA exige que el acceso a la información sanitaria protegida se conceda y se termine según el puesto, el flujo de baja como obligación legal. PCI DSS exige revocar de inmediato el acceso de los usuarios dados de baja y revisar los accesos periódicamente. E ISO/IEC 27001, con los objetivos de control de acceso de su anexo A, espera que el aprovisionamiento y la retirada sean procesos formales y documentados.

El hilo común es que a los reguladores no les basta con que el acceso se conceda bien; les obsesiona que se retire bien y a tiempo. Esa es precisamente la mitad del JML que las organizaciones descuidan, y precisamente por eso las auditorías la siguen encontrando.

Resumen

El JML es el motor del IAM operativo, y su dificultad está descompensada. El ciclo de vida es una máquina de estados, no un interruptor: prospecto, activa, suspendida, terminada y eliminada, con las recontrataciones y la retención complicando los bordes. Debajo hay cuatro tipos de acceso: el de nacimiento y el de rol, automatizados; el solicitable, gobernado, y el justo a tiempo, el antídoto contra el acceso fijo. Las altas tratan de un primer día rápido y correcto: preparar de antemano, calcular el acceso de nacimiento a partir de atributos y retener el acceso sensible. Los cambios de puesto son el paso más difícil porque la retirada es invisible, así que recalculas todo el conjunto y quitas lo que ya no se justifica, o acumulas privilegios y deuda de separación de funciones como Daniel. Las bajas tratan de rapidez y orden: desactivar y revocar de inmediato, borrar solo tras la retención y no dar nunca por hecho que los contratistas se irán limpiamente. Y las responsabilidades, las métricas y la madurez deciden si algo de esto es real, con la prueba honesta siempre del lado de la retirada.

Tres preguntas para ponerte a prueba

1. Se descubre que un empleado con muchos años conserva accesos de tres puestos anteriores. ¿Qué paso del JML falló, por qué es el que suele fallar y qué control habría evitado la acumulación?
2. Diseña el flujo de baja de un empleado despedido por motivos disciplinarios a las tres de la tarde. ¿Qué tiene que pasar en los primeros cinco minutos, qué durante el periodo de retención y qué, si es que hay algo, no debería borrarse nunca?
3. Una organización insiste en que está “totalmente automatizada” porque las altas reciben acceso al instante. ¿Qué única pregunta te diría si de verdad está en el nivel 3 de madurez o solo en el 2, y qué respuesta lo demostraría?