El ciclo JML: Joiner, Mover, Leaver en profundidad

El motor bajo el ciclo operativo

En el ciclo operativo de IAM vimos los seis procesos que mantienen en marcha un programa de IAM, y JML fue uno de ellos — descrito de pasada. Este artículo abre esa caja por completo, porque en JML es donde vive la mayor parte del valor, y la mayor parte de los fallos, de un programa de IAM.

Todos los demás procesos existen para servir a JML. La agregación y el registro maestro existen para que JML sepa quién cambió. La correlación y la reconciliación existen para que JML sepa qué cuentas tocar. La certificación existe para atrapar lo que JML dejó pasar. Si haces bien JML, el resto del programa tiene una oportunidad real. Si lo haces mal, ningún tablero ni auditoría te salvará — vivirás limpiando permanentemente accesos que ya no corresponden a la realidad.

Así que vamos a profundizar: el ciclo de vida como máquina de estados, el modelo de acceso que lo sustenta, cada uno de los tres movimientos en detalle (con atención especial al Mover, donde los programas fallan en silencio), quién es responsable de qué, cómo medir si funciona y las regulaciones que lo vuelven obligatorio.

El ciclo de vida de la identidad como máquina de estados

Antes de los tres movimientos, necesitas la forma a través de la cual se mueven. Una identidad no es simplemente “activa” o “ida”. Pasa por una serie de estados bien definidos, y cada transición es un evento al que JML reacciona. Pensar en estados es lo que separa a un programa robusto de uno que solo maneja el camino feliz.

stateDiagram-v2
  accTitle: El ciclo de vida de la identidad como máquina de estados
  accDescr: Una identidad arranca como prospecto cuando se aprueba una contratación, pasa a activa en la fecha de inicio vía el flujo de joiner, puede reentrar a activa repetidamente mediante eventos de mover, puede pasar a suspendida durante una licencia y volver a activa al regresar, transiciona a terminada al irse vía el flujo de leaver, y desde terminada o vuelve a activa por recontratación o pasa a eliminada una vez que 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 --> [*]

Lectura del diagrama: una persona se vuelve Prospecto en cuanto se aprueba su contratación — a menudo días o semanas antes de empezar. En su fecha de inicio, el flujo Joiner la promueve a Activa. Mientras está activa puede recorrer eventos Mover muchas veces. Una licencia la estaciona en Suspendida, un estado donde el acceso se congela pero no se destruye. La salida dispara el flujo Leaver hacia Terminada — pero ojo, esto no es el final: una recontratación puede traerla de vuelta a Activa, y solo tras una ventana de retención definida por política la identidad llega a Eliminada.

Los dos estados que la gente olvida son Suspendida y la brecha entre Terminada y Eliminada. Un programa que trata “terminada” como “eliminar de inmediato” pierde evidencia forense y rompe la propiedad de los datos; un programa sin estado suspendido o sobre-revoca durante una licencia de maternidad o, peor, deja el acceso completo en pie para alguien que no está.

El modelo de acceso bajo JML

JML mueve accesos de un lado a otro, así que no puedes razonarlo sin un modelo de qué tipos de acceso existen. Los programas modernos usan cuatro, y el arte está en poner cada permiso en el bucket correcto.

La distinción importa enormemente para JML. El acceso birthright y por rol es lo que los flujos Joiner y Mover automatizan — se computan a partir de atributos, así que el sistema puede otorgarlos y retirarlos sin un humano. El acceso solicitable es lo que esos flujos no pueden asumir — requiere intención y aprobación. Y el JIT es la válvula de escape que impide que el acceso solicitable se vuelva deuda permanente: en lugar de otorgar acceso fijo que un Mover futuro olvidará quitar, lo otorgas por la ventana en que se necesita y dejas que expire solo.

Joiner: acertar el día uno

El flujo Joiner tiene una meta engañosamente difícil: que la persona nueva sea productiva en su primer clic, y solo con el acceso que su rol justifica. Ambas mitades importan. Otorga muy poco y el manager empieza a abrir tickets de emergencia y la primera impresión del nuevo es de fricción; otorga demasiado y has sembrado privilege creep antes de que siquiera inicie sesión.

Las tres subfases del Joiner

Un flujo Joiner maduro no es un único evento — son tres:

• Pre-contratación (pre-staging): en cuanto se acepta la oferta, el HRIS crea una identidad Prospecto. IGA puede pre-construir cuentas en estado deshabilitado, pedir hardware y encolar capacitación — todo antes del día uno, para que nada se cree con prisas la misma mañana.
• Día uno (activación): en la fecha de inicio la identidad pasa a Activa, las cuentas pre-staged se habilitan, se aplica el acceso birthright y por rol, y se emiten las credenciales. Como el trabajo pesado ocurrió durante el pre-staging, la activación es rápida y de bajo riesgo.
• Periodo de prueba / rampa: parte del acceso se difiere deliberadamente — acceso a producción, autoridad de firma, sistemas sensibles — hasta que la persona supera el periodo de prueba o completa la capacitación requerida. Codificar esto como una transición programada, no como un recordatorio manual, es lo que evita que se olvide.

Birthright por regla, no copiando a un colega

El peor anti-patrón del Joiner es la clonación de acceso: “dale a Sara el mismo acceso que a Daniel porque están en el mismo equipo”. Parece eficiente y es un desastre — Daniel ha acumulado años de permisos puntuales, y ahora Sara los hereda todos el día uno. El birthright debe computarse a partir de atributos (puesto, departamento, ubicación, tipo de empleo), no copiarse de un humano que es él mismo un montón de excepciones históricas.

El aprovisionamiento hacia las apps downstream cada vez más se apoya en el estándar SCIM (System for Cross-domain Identity Management), que le da a IGA una API uniforme para crear, actualizar y desactivar cuentas en el SaaS moderno — reemplazando los frágiles conectores por-app de hace una década.

Mover: el paso donde los programas fallan en silencio

Si recuerdas una sola cosa de este artículo, que sea esta: el Mover es la parte más difícil y más descuidada de JML, y se descuida por una razón estructural. Cuando alguien se mueve, otorgar su acceso nuevo es visible — lo necesita, lo pide, alguien celebra el ascenso. Quitar el acceso que ya no necesita es invisible — nada se rompe al omitirlo, nadie reclama y la persona sigue trabajando. Así que se omite. Cada vez que se omite, el acceso se acumula.

El resultado es el privilege creep: un empleado de diez años que ha rotado por cinco equipos termina con la unión del acceso de los cinco roles. Nadie decidió nunca que debía tenerlo todo; es puro sedimento. Y no es solo desorden — el acceso solapado de funciones distintas es exactamente cómo nacen las violaciones de segregación de funciones (SoD). La persona que puede crear un proveedor y aprobar sus pagos no recibió ese poder a propósito; recolectó una mitad en 2021 y la otra en una transferencia de 2024.

Qué hace realmente un Mover correcto

flowchart TB
  accTitle: El flujo de decisión del Mover
  accDescr: Un evento de cambio en HRIS por departamento, manager o puesto dispara el recálculo del conjunto de roles esperado. El sistema compara la nueva expectativa con el acceso actual y se ramifica de tres maneras: los roles nuevos necesarios se aprovisionan, los roles ya no justificados se retiran y el acceso sin cambios se deja igual. El acceso recién agregado se revisa por conflictos de segregación de funciones; un conflicto exige una excepción o aprobación, y en cualquier caso 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 crítica es la del medio — retirar roles viejos — porque es la que los procesos manuales omiten. Un Mover correcto recalcula el conjunto de roles esperado completo a partir de los nuevos atributos y reconcilia el acceso actual contra él en ambas direcciones: agregar lo que falta, quitar lo que ya no se justifica. Agregar sin quitar no es un Mover; es un segundo Joiner apilado sobre el primero.

Los casos difíciles del Mover

Los movimientos laterales simples son fáciles. Los casos que exponen la calidad real de un programa:

Leaver: quitar el acceso antes de que sea un pasivo

El flujo Leaver es donde IAM protege a la organización de forma más visible, y donde la velocidad es una propiedad de seguridad. Cada minuto que una persona que se fue conserva acceso es un minuto de exposición — a una salida resentida, a un dispositivo personal comprometido o simplemente a una cuenta que ya nadie vigila.

Salidas graduales vs. inmediatas

No todos los leavers son iguales, y el flujo debe distinguirlos:

• Salida planificada (gradual): renuncia o jubilación con preaviso. El flujo Leaver puede correr en el último día programado, con el traspaso del buzón y la transferencia de datos arreglados de antemano.
• Salida inmediata (urgente): despido con causa, o cualquier situación donde el acceso deba cortarse ahora. Esto no puede esperar a un batch nocturno — necesita una vía en tiempo real que desactive cuentas y mate sesiones activas en minutos.

Un programa que solo tiene la vía gradual es peligroso: el caso donde la velocidad más importa es justo el que no puede manejar.

Desactivar primero, eliminar después

El error más común del Leaver es tratar “quitar el acceso” y “eliminar la cuenta” como la misma acción. No lo son, y confundirlos destruye evidencia:

1. De inmediato: desactiva la cuenta, revoca sesiones y tokens activos, y saca a la persona de los grupos. El acceso desaparece en minutos.
2. Durante la retención: mantén la cuenta desactivada intacta. El buzón entra en estado de retención/legal hold; el manager recibe acceso delegado para el traspaso; los datos en propiedad se reasignan.
3. Tras la ventana de retención: solo ahora se elimina la cuenta, según la política y el reloj regulatorio.

Eliminar el día uno se siente limpio pero está mal: acabas de borrar el rastro de auditoría que un investigador podría necesitar, dejar huérfanos los documentos que la persona poseía y rebotar cada correo que alguien le envíe.

La trampa de las cuentas dormidas

Los leavers no son la única fuente de acceso muerto. Las cuentas dormidas — cuentas activas en las que nadie ha iniciado sesión en meses — son riesgo con forma de leaver escondido a plena vista: un contratista cuya colaboración terminó en silencio, una cuenta de servicio de una app dada de baja, un empleado de licencia larga. Un programa maduro corre detección de dormancia junto a JML y cuestiona cualquier cosa inactiva más allá de un umbral, porque una cuenta activa olvidada es funcionalmente idéntica a un leaver sin procesar.

Quién es dueño de qué: la matriz RACI de JML

JML falla tan a menudo por propiedad poco clara como por mal herramental. Cada movimiento toca varias funciones, y cuando “todos” son responsables, no lo es nadie. Una división de trabajo viable:

El fallo recurrente es la columna Mover del manager: los managers solicitan con gusto acceso nuevo para su reporte y callan de forma fiable sobre lo que debería quitarse. Por eso la plataforma IGA — no el manager — debe ser dueña del paso “retirar roles viejos”, impulsada por recálculo y no por que alguien se acuerde de preguntar.

Un modelo de madurez de automatización

La madurez de JML es una escalera, y la mayoría de las organizaciones puede ubicarse en ella con honestidad:

La mayoría de las organizaciones viven en el nivel 2 y creen estar en el 3. La prueba honesta es el Mover: si la remoción de roles en una transferencia es automática y fiable, estás en el nivel 3; si depende de que alguien se acuerde, estás en el nivel 2 por muy pulido que se vea el flujo Joiner.

Medir si JML realmente funciona

No puedes gestionar lo que no mides, y JML tiene un puñado de métricas que revelan la verdad rápido:

• Tiempo de aprovisionamiento (Joiner): desde la fecha de inicio hasta el acceso funcional. Meta: horas, no días.
• Tiempo de desaprovisionamiento (Leaver): desde el evento de terminación hasta el acceso totalmente revocado. Para casos urgentes, minutos.
• Tasa de automatización del aprovisionamiento: porcentaje de cambios de acceso ejecutados sin que un humano los toque. El mejor proxy de madurez.
• Tasa de huérfanos: cuentas sin identidad coincidente, halladas por reconciliación. Una medida directa del fallo del Leaver.
• Indicador de privilege creep: promedio de permisos por usuario en tendencia ascendente, o el conteo de usuarios con más roles de los que su puesto actual implica — la boleta de calificaciones del Mover.
• Conteo de violaciones de SoD: conflictos activos de segregación de funciones, la mayoría deuda acumulada del Mover.

Cómo se rompe JML: el catálogo de fallos

Los mismos fallos se repiten entre organizaciones. Conocerlos por su nombre te permite buscarlos deliberadamente:

Fíjate cuántos rastrean de vuelta al Mover y al Leaver — el lado de remoción del ciclo de vida. Otorgar acceso es la mitad fácil y popular; la disciplina de un programa de IAM está enteramente en el lado de quitar.

Por qué JML no es opcional: los impulsores regulatorios

JML no es solo buena higiene — está mandatado, explícita o implícitamente, por todo marco de control serio:

• NIST SP 800-53 (AC-2, Gestión de Cuentas) exige crear, habilitar, modificar, deshabilitar y remover cuentas ante disparadores definidos — eso es JML, en lenguaje de controles.
• SOX demanda que el acceso a sistemas financieros coincida con las responsabilidades actuales del puesto, lo cual es imposible sin Movers y Leavers que funcionen.
• Regla de Seguridad de HIPAA exige que el acceso a información de salud protegida se otorgue y se termine según el rol — el flujo Leaver como obligación legal.
• PCI-DSS exige que el acceso de usuarios terminados se revoque de inmediato y que el acceso se revise periódicamente.
• ISO/IEC 27001 (objetivos de control de acceso del Anexo A) espera que el aprovisionamiento y el desaprovisionamiento sean procesos formales y documentados.

El hilo común: los reguladores no solo quieren el acceso otorgado correctamente — están obsesionados con que el acceso se remueva correctamente y con prontitud. Que es justo la mitad de JML que las organizaciones descuidan, que es justo por lo que las auditorías la siguen encontrando.

Recapitulación

JML es el motor de la IAM operativa, y su dificultad es asimétrica:

1. El ciclo de vida es una máquina de estados, no un interruptor — prospecto, activa, suspendida, terminada, eliminada, con recontratación y retención complicando los bordes.
2. Cuatro tipos de acceso lo sustentan: birthright y por rol (automatizados), solicitable (gobernado) y JIT (el antídoto contra el acceso fijo).
3. Joiner trata de un día uno rápido y correcto — pre-staging, computar birthright desde atributos, diferir el acceso sensible.
4. Mover es el paso más difícil porque la remoción es invisible; recalcula el conjunto completo y retira lo que ya no se justifica, o acumula privilege creep y deuda de SoD.
5. Leaver trata de velocidad y secuencia — desactivar y revocar de inmediato, eliminar solo tras la retención, y nunca confiar en que los contratistas se irán limpiamente.
6. Propiedad, métricas y madurez determinan si algo de esto es real — y la prueba honesta es siempre el lado de la remoción.

Tres preguntas para autoevaluarte

1. Se descubre que un empleado de muchos años conserva acceso de tres roles previos. ¿Qué paso de JML falló, por qué ese paso es el que suele fallar, y qué control habría prevenido la acumulación?
2. Diseña el flujo Leaver para un empleado despedido con causa a las 3 PM. ¿Qué debe ocurrir en los primeros cinco minutos, qué durante la ventana de retención, y qué — si algo — nunca debería eliminarse?
3. Una organización insiste en que está “totalmente automatizada” porque los Joiners son instantáneos. ¿Qué única pregunta harías para averiguar si de verdad está en el nivel de madurez 3 o solo en el 2, y qué respuesta lo probaría?