JML en un programa de IGA: de los datos de identidad a cambios de acceso gobernados y demostrables

El ascenso de Sara

Sara López lleva tres años como analista de operaciones con clientes en un procesador de pagos en línea. Parte de su trabajo es despejar alertas de fraude que resultan ser falsos positivos: a un cliente le bloquearon la tarjeta, ella revisa el caso y anula la alerta para que el pago pase. En marzo la ascienden a líder del equipo de revisión de fraude, donde su nuevo trabajo es justamente marcar las transacciones sospechosas.

RR. HH. registra el cambio un viernes. Durante el fin de semana, el flujo de altas, cambios y bajas hace lo que tiene que hacer: le otorga a Sara el acceso del equipo de revisión de fraude y deja en cola el retiro de su acceso de operaciones con clientes. El lunes por la mañana, durante unas horas, Sara puede marcar una transacción como sospechosa y también anular esa misma alerta como falso positivo. No pasa nada malo. Pero si hubiera querido marcar una transacción y despejarla ella misma en silencio, el sistema se lo habría permitido, y nadie lo habría notado hasta una revisión meses después. Cuando la auditoría interna encuentra el solapamiento en sus pruebas de primavera, la pregunta no es si Sara hizo algo mal. Es por qué el proceso lo permitió.

Cada paso de ese flujo funcionó. De eso trata este artículo. Un motor de JML puede funcionar a la perfección y aun así producir un resultado en el que nadie debería confiar, y el trabajo de un programa de IGA es encontrar dónde.

Lo que ya cubrió el artículo de fundamentos

El ciclo JML, en el dominio de fundamentos, explica las altas, los traslados y las bajas como un mecanismo operativo: la máquina de estados de la identidad, los cuatro tipos de acceso (birthright, por rol, solicitable y justo a tiempo), por qué el traslado es el paso que los programas hacen mal sin darse cuenta, quién hace qué entre RR. HH., las jefaturas, la plataforma de IAM y los owners de aplicación, y las regulaciones que lo vuelven obligatorio. Este artículo no repite eso.

Hace una pregunta más acotada. Si un flujo de JML existe y funciona, ¿cómo sabe un programa de gobierno que puede confiar en él? El artículo anterior construyó las piezas para responder: una fuente autoritativa, una forma de emparejar registros y la reconciliación. Este artículo las pone a trabajar dentro de los tres eventos.

Lo que un motor de flujos no puede decirte

Un motor de JML es bueno en una cosa: reaccionar a un evento ejecutando pasos de aprovisionamiento o de retiro en los sistemas a los que está conectado. Es un trabajo necesario, y es lo que hace rápidas las altas y las bajas. Pero “el flujo corrió y reportó éxito” no es lo mismo que “el acceso ahora es correcto”, y la distancia entre las dos afirmaciones es donde el gobierno tiene que hacer el trabajo que el motor no puede hacer por sí mismo.

Hay tres huecos que aparecen en casi todos los programas, y cada uno se conecta con algo del artículo anterior. El primero es si el evento llegó a la persona correcta, una pregunta de emparejamiento; el motor confía en el registro que lo disparó y no tiene forma de notar que era un duplicado o el “David de Finanzas” equivocado. El segundo es si el evento llegó a todos los sistemas a los que debía, una pregunta de reconciliación; el motor solo conoce los sistemas para los que tiene conector, y uno sin conector le resulta invisible por definición. El tercero es si el acceso resultante creó un problema nuevo, una pregunta de política que se agudiza con los movers, como muestra el lunes de Sara; el motor puede otorgar y quitar, pero no puede decidir si la combinación que acaba de producir es tolerable para el negocio.

La calidad del emparejamiento decide si se tocan las cuentas correctas

El artículo anterior separó el emparejamiento determinista, con una clave estable y compartida, del probabilístico, con una combinación de atributos puntuada, y repasó los casos en que el emparejamiento sufre: cambios de nombre, recontrataciones, duplicados. Cada uno tiene una consecuencia concreta dentro de un evento de JML, y esa consecuencia depende del evento al que le toque.

Un alta es el evento más tolerante, porque casi siempre crea una identidad nueva en lugar de emparejar una existente. El riesgo principal es que una recontratación se trate como alguien nuevo y se cree un duplicado de un registro que había que reactivar. Una baja es medianamente tolerante por el mismo motivo: incluso con un emparejamiento flojo suele encontrar alguna cuenta que deshabilitar, porque quien la dispara sabe más o menos de quién habla.

Un traslado es donde los errores de emparejamiento hacen daño de verdad, porque depende de encontrar un registro existente y actuar sobre sus dos mitades: el acceso viejo que hay que quitar y el nuevo que hay que dar. Si el cambio de RR. HH. se enlaza con la identidad equivocada, el resultado no es un acceso viejo olvidado. Es una confusión inmediata. Cambia el acceso de la persona equivocada, no cambia el de la correcta, y nadie lo nota hasta que la persona a la que de verdad ascendieron se queja de que sigue sin poder hacer su nuevo trabajo mientras otra, misteriosamente, sí puede.

flowchart TD
  accTitle: La confianza del emparejamiento decide cómo sigue un evento de JML
  accDescr: Un evento de RR. HH. pasa por el emparejamiento de identidades, que clasifica la coincidencia como de alta confianza o como de baja confianza o ambigua. Una coincidencia de alta confianza pasa directamente al flujo de JML. Una de baja confianza o ambigua va primero a revisión manual. Cuando el flujo corre, el peor caso depende del evento: un alta puede crear una identidad duplicada, un traslado puede cambiar el acceso existente de la persona equivocada y una baja puede deshabilitar la cuenta equivocada y dejar la correcta.
  EVENT([Evento de RR. HH.: alta, cambio de puesto, baja]) --> CORR{Confianza del emparejamiento}
  CORR -->|Alta| WF[El flujo sigue solo]
  CORR -->|Baja o ambigua| REVIEW[Primero revisión manual]
  REVIEW --> WF
  WF --> RISK{¿Qué evento?}
  RISK -->|Alta| J[Peor caso: identidad duplicada]
  RISK -->|Traslado| M[Peor caso: cambia el acceso de otra persona]
  RISK -->|Baja| L[Peor caso: se deshabilita la cuenta equivocada]

Dos David en Finanzas

Una cadena de tiendas mediana tiene dos empleados llamados David en finanzas: David Okafor en cuentas por pagar y David Chen en planificación financiera. Ninguno tiene cargado el ID de identidad en el viejo sistema de gastos, anterior a la plataforma de IGA de la empresa. RR. HH. asciende a David Chen a un puesto de jefatura con autoridad de aprobación. Se dispara el evento de traslado, el emparejamiento recurre a una puntuación probabilística en ese sistema porque no hay clave compartida, y la puntuación, basada en el nombre, una inicial de apellido ambigua en una exportación de datos y el área, enlaza el ascenso con la cuenta de David Okafor.

El flujo corre sin un error. Quita lo que cree que es el acceso anterior y otorga la nueva autoridad de aprobación, en la cuenta de David Okafor, y reporta éxito total. David Okafor tiene ahora derechos para aprobar gastos que nunca pidió y no debería tener. David Chen, el que de verdad ascendieron, sigue sin poder aprobar nada y abre un ticket preguntando por qué su ascenso “no funcionó”. Desde el punto de vista del motor no falló nada; cada paso fue correcto para la identidad sobre la que tenía confianza suficiente para actuar. El fallo ocurrió un paso antes, en el emparejamiento, y por eso un programa que solo mira la tasa de éxito de los flujos no puede ver este tipo de error.

La lección no es que el emparejamiento tenga que ser perfecto antes de que JML pueda correr. Ese listón no lo alcanza ningún programa real. Es que el motor debería mostrar la confianza del emparejamiento como parte de cada evento, y que las coincidencias de baja confianza deberían pasar por una persona antes de ejecutar un paso de traslado o de baja, en lugar de dejar que el motor actúe sobre su mejor suposición.

La reconciliación demuestra que un evento terminó de verdad

En el artículo anterior, la reconciliación era la comparación periódica entre el estado gobernado y el real, que detecta la deriva de los cambios hechos por fuera del proceso. Dentro de JML tiene un segundo trabajo: convertir “el flujo reportó éxito” en “podemos mostrar que ocurrió en todas partes”.

Importa porque el reporte del motor solo cubre los sistemas para los que tiene conector. Una baja que deshabilita a la persona en Active Directory, en el sistema de RR. HH. y en todas las aplicaciones SaaS conectadas puede dejarle acceso a un sistema que nadie conectó nunca: una aplicación heredada, un portal de proveedores, una bóveda de contraseñas compartida. El motor reporta éxito total en todo lo que tocó y no tiene forma de reportar sobre lo que nunca supo que existía. La reconciliación, corrida sobre un inventario de sistemas más completo que la lista de conectores del motor, le pregunta a cada sistema si la persona sigue teniendo acceso y marca cualquiera que diga que sí.

Para las altas funciona en el otro sentido. La reconciliación confirma que el acceso que se debía otorgar llegó de verdad, en lugar de dar por hecho que una tarea de aprovisionamiento en cola terminó porque no saltó ningún error. Para los traslados confirma las dos mitades: el acceso viejo ya no está y el nuevo funciona, también en los sistemas sin conector.

El hábito práctico es tratar el estado de finalización del motor como una afirmación en cualquier sistema con riesgo real. La siguiente reconciliación después de una baja, un traslado o un alta de alto riesgo es lo que convierte la afirmación en evidencia, y la distancia entre “el flujo dijo que terminó” y “la reconciliación confirmó que terminó” vale la pena seguirla por sí sola como señal de la salud del programa.

Las altas: alguien tiene que ser owner del paquete

El artículo de fundamentos cubre bien la mecánica de un alta: preparar las cuentas antes de la fecha de ingreso, activarlas el primer día, reservar parte del acceso hasta terminar el periodo de prueba. Lo que da por hecho es el contenido del paquete, los entitlements concretos en los que se convierte “el birthright” o “el acceso estándar de este puesto”. Ese contenido no lo inventó el motor. Es una decisión que alguien tomó una vez, y que se sigue aplicando a cada persona nueva hasta que alguien la cambie.

La mayoría de los programas no ve lo que se sigue de eso. Un paquete birthright o de rol necesita un owner y una fecha de revisión como cualquier otra política, o se desactualiza igual que el acceso de una persona. Un área se reorganiza y su paquete estándar sigue incluyendo una herramienta que el equipo dejó de usar dos reorganizaciones atrás. El paquete de una analista de operaciones con clientes se definió bien una vez y nunca se revisó mientras cambiaban las aplicaciones de debajo, así que cada analista nueva de los últimos dos años recibió algo que no necesita. Nadie aprobó eso en concreto. Nadie tenía el trabajo de notarlo.

La disciplina es fácil de enunciar y fácil de saltarse. Cada paquete necesita un owner con nombre, normalmente el owner de negocio o de aplicación que ya aprueba las solicitudes de ese sistema, y una revisión programada de la definición del paquete, aparte de las revisiones del acceso de cada persona. Un paquete que nadie miró en más de un año es tan hallazgo como un entitlement que nadie puede justificar, multiplicado por todas las personas que entraron con él mientras tanto. Más adelante en este dominio, los artículos sobre ingeniería de roles y políticas y acceso por nacimiento explican cómo se diseñan y se asignan esos paquetes.

Quienes no son empleados: otra fuente y otro ritmo

El artículo anterior trazó una línea entre el sistema de RR. HH. como autoridad para los empleados y un sistema de proveedores o un registro como autoridad para contratistas y demás personas que no son empleados. JML es donde esa línea empieza a cambiar cómo se comporta el ciclo de vida.

El alta de un contratista se parece mucho a la de un empleado: birthright más el acceso propio del puesto, aprovisionado contra una fecha de inicio. La baja es distinta en algo que importa. La salida de un empleado suele dispararla algo que registra RR. HH.: una renuncia, un despido, una jubilación. La de un contratista la dispara más a menudo que no pase nada: el contrato llega a su fecha de fin y no se registra ninguna prórroga. Así que el proceso tiene que tratar “llegó la fecha de fin sin renovación registrada” como un disparador en sí, en lugar de esperar a que alguien avise de que el contratista se fue. Un programa que solo reacciona a bajas explícitas, copiando el patrón de los empleados, se pierde a cada contratista cuyo contrato simplemente vence, que es justo el hueco del que advertía el artículo anterior.

Las renovaciones son donde esto se complica. Los contratos muchas veces se prorrogan tarde, cuando la fecha de fin ya pasó, porque los papeles van más lento que el trabajo. Si la fecha de fin dispara el retiro a tiempo, un contratista que sigue trabajando pierde el acceso un lunes y pasa un día esperando mientras compras registra la prórroga. Algunos programas aceptan esa fricción como el precio de un control confiable. Otros avisan a la persona responsable del contratista dos semanas antes de la fecha de fin, para que las prórrogas se registren a tiempo, y le permiten otorgar una extensión corta y registrada de unos pocos días mientras se ponen al día los papeles. Lo que no funciona es desactivar en silencio el disparador de la fecha de fin para los contratistas que se quejan, porque eso recrea el problema original una excepción a la vez.

Los usuarios de socios que entran por federación quedan casi por completo fuera del proceso de JML de esta organización. Sus altas, traslados y bajas los gestiona su propio empleador. La única palanca aquí es reaccionar rápido cuando la aserción de federación del socio deja de llegar o se revoca. No hay ningún traslado que diseñar, porque esta organización nunca fue la autoridad sobre el puesto de esa persona; la pregunta de gobierno se reduce a qué tan rápido se corta de verdad el acceso cuando se corta la señal del socio.

Los traslados: una pregunta de política escondida en un paso del flujo

El artículo de fundamentos explica por qué el traslado es el evento más difícil en lo operativo: la mitad del retiro se salta porque nada la obliga, y los retiros saltados se acumulan como acumulación de privilegios. IGA suma un segundo problema al mismo evento, el que muestra el lunes de Sara. Durante el tiempo en que alguien que cambia de puesto tiene piezas del puesto viejo y del nuevo, ¿esa combinación es algo que el negocio puede tolerar?

En el caso de Sara, los dos entitlements, marcar una transacción sospechosa y anular una alerta como falso positivo, son perfectamente razonables por separado. Juntos le permiten a una sola persona abrir y cerrar en silencio el mismo caso. Un analista de compras que pasa a tesorería produce el mismo tipo de problema con otros nombres: crear proveedores desde el puesto anterior y aprobar pagos a proveedores en el nuevo. El módulo de separación de funciones, más adelante en este dominio, construye la lógica de detección de estas combinaciones por completo. Lo que importa aquí es más acotado: un traslado es uno de los momentos concretos en que se crea un conflicto nuevo, y eso lo convierte en el lugar natural para buscarlo.

Un programa que solo busca conflictos en una revisión trimestral terminará encontrando el de Sara. “Terminará” puede significar tres meses en los que pudo marcar y despejar el mismo caso. Un programa que lo comprueba en el momento del traslado, evaluando lo que queda del acceso viejo junto con el nuevo antes de otorgarlo, cierra esa ventana por completo.

Eso es lo que pasa en la mejor versión del ascenso de Sara. Se dispara el traslado y, antes de otorgar el acceso de revisión de fraude, el flujo lo evalúa junto con lo que le queda de acceso de operaciones con clientes. La verificación encuentra el conflicto y lo envía a la owner de la aplicación de revisión de fraude, el lado de mayor riesgo. La owner elige el camino más seguro: primero se quita el acceso de Sara para anular alertas, la reconciliación confirma que ya no está y solo entonces se activa el acceso nuevo, un día más tarde de lo que habría tardado un otorgamiento sin condiciones y sin ningún momento en que el conflicto existiera.

No todo conflicto que encuentra una verificación de traslado debe bloquear el cambio. A veces el negocio necesita de verdad que alguien tenga las dos piezas durante un traspaso, o un equipo chico tiene un rol que abarca legítimamente lo que la política prohibiría. Lo que cambia la verificación es cómo se maneja. En lugar de existir en silencio, el conflicto aparece en el momento en que es más barato resolverlo, y o se resuelve quitando el acceso viejo que ya no hace falta o se acepta de forma explícita, con un control compensatorio y el nombre de un owner en la decisión.

sequenceDiagram
    accTitle: Un traslado dispara una verificación de separación de funciones antes de otorgar el acceso nuevo
    accDescr: El sistema de RR. HH. envía un evento de traslado al flujo de JML. Antes de otorgar el acceso nuevo, el flujo contrasta lo que queda del acceso anterior más el acceso nuevo con la política de separación de funciones. Si no hay conflicto, el otorgamiento sigue adelante. Si lo hay, pasa a una persona que aprueba excepciones, que lo aprueba con un control compensatorio o lo rechaza. En cualquier caso, el hallazgo queda registrado para la siguiente certificación.
    participant HRIS as Sistema de RR. HH.
    participant WF as Flujo de JML
    participant SOD as Verificación de SoD
    participant APR as Aprobación de excepciones
    HRIS->>WF: Evento de traslado
    WF->>SOD: Acceso anterior restante + acceso nuevo
    alt Sin conflicto
        SOD->>WF: Sin objeciones
        WF->>WF: Otorgar acceso nuevo
    else Hay conflicto
        SOD->>APR: Revisión de excepción
        APR->>WF: Aprobar con control compensatorio, o rechazar
    end
    WF->>WF: Registrar el hallazgo para la certificación

Cuando JML necesita a una persona

Casi todo un proceso de JML bien llevado es automático, pero algunos pasos necesitan a una persona a propósito: una jefatura que confirma qué acceso diferido debe recibir alguien nuevo al terminar el periodo de prueba, una owner que decide sobre un conflicto como el de Sara, alguien que resuelve un emparejamiento de baja confianza. Esos pasos son donde se atascan los eventos de JML, y cómo los maneja un programa importa.

Cada paso humano necesita un nivel de servicio, un recordatorio y una vía de escalamiento, igual que una solicitud de acceso. Y cada uno necesita un resultado definido cuando nadie responde. Para los otorgamientos, lo seguro por defecto es esperar o escalar, nunca aprobar solo; un evento que otorga acceso porque una jefatura no respondió en tres días ha convertido el silencio en una aprobación. Para los retiros, lo por defecto debería ser lo contrario: si una owner no responde sobre si el acceso viejo de alguien que se trasladó sigue haciendo falta, el acceso se quita, y se puede volver a pedir por el proceso normal si de verdad hacía falta.

Vale la pena mirar cuántos eventos de JML están esperando a una persona en cada momento, y desde hace cuánto. Una cola creciente de traslados atascados suele ser la primera señal de que se está dejando acceso viejo en su sitio sin que nadie lo diga.

Las bajas: de rápidas a demostrables

La velocidad es el titular correcto de una baja, y el artículo de fundamentos cubre bien los niveles de urgencia y la secuencia de deshabilitar y luego borrar. La pregunta de gobierno que va encima es distinta. Cuando un auditor, un regulador o un cuestionario de un seguro de ciberriesgo te pide demostrar que el acceso de una persona se retiró en todas partes antes de cierta fecha, ¿qué le entregas?

En un programa sin reconciliación, la respuesta honesta es un registro del flujo con los sistemas a los que llegó el motor, más la suposición de que no se escapó nada. Un programa con la reconciliación incorporada al proceso de bajas tiene una segunda confirmación, independiente: después se revisaron todos los sistemas conectados y el acceso ya no está, con una marca de tiempo distinta de la del disparador original. Esa segunda marca es lo que un programa maduro reporta como su verdadero tiempo de retiro, porque la primera puede verse excelente mientras esconde los sistemas a los que el flujo nunca llegó.

Un prestador de salud, el mismo de las 340 cuentas sin coincidencia del artículo anterior, hace su primera revisión de bajas basada en reconciliación. De las últimas 200 bajas procesadas por su flujo, 187 muestran un retiro limpio de todos los sistemas reconciliados en menos de 24 horas. Las otras 13 tienen la misma causa: una aplicación de programación clínica, anterior a la plataforma de IGA, que nunca tuvo conector, así que todas las bajas se la saltaban. Los reportes del propio motor no marcaron ninguna de las 13, porque hasta donde él sabía había hecho todo lo que le pidieron. La reconciliación convirtió una tasa de fallo invisible del 6,5% en un hueco con nombre y, al final, en el argumento de negocio para construir el conector que faltaba.

“Demuéstrame que el acceso de esta persona se retiró” suena a un solo hecho, pero la evidencia que hay detrás tiene varias partes, y un programa sin reconciliación suele tener solo las dos primeras.

Un programa que solo puede presentar las dos primeras filas está describiendo lo que intentó, no lo que consiguió. Los auditores con experiencia buscan justo esa diferencia, porque “disparamos el proceso” y “el acceso ya no está” son las dos afirmaciones que se separan cuando la cobertura de conectores es incompleta.

Qué se otorga y se quita en realidad

Todos los eventos de este artículo, el birthright y los paquetes por rol del alta, el retiro y el otorgamiento del traslado, el retiro completo de la baja, actúan sobre entitlements. Hasta aquí, este artículo, igual que el de fundamentos, ha tratado “el paquete estándar de este puesto” y “el acceso del puesto anterior” como si estuvieran obviamente bien definidos. En un programa real muchas veces no lo están. Los nombres no son coherentes entre sistemas, nadie es owner de la mitad de los entitlements de un paquete típico y “rol” suele ser una etiqueta informal y no un objeto gobernado con una definición vigente.

JML es el proceso; el catálogo de entitlements es el inventario de lo que ese proceso mueve, y un flujo de JML es tan confiable como el catálogo que tiene debajo. Un traslado perfectamente rápido, bien emparejado y reconciliado que otorga “el paquete estándar de revisión de fraude” solo significa algo si hay una definición vigente y con owner de lo que contiene ese paquete. El siguiente artículo construye ese catálogo.

Muchas implementaciones reales construyen primero el catálogo y después conectan el ciclo de vida. Este módulo va al revés a propósito: los fallos descritos aquí, un traslado que se salta un retiro, un paquete sin owner, un hueco en las bajas que solo detecta la reconciliación, son los que vuelven concreta la necesidad de un catálogo riguroso, en lugar de un ejercicio de inventario por sí mismo.

La certificación atrapa lo que JML no ve en tiempo real

La confianza del emparejamiento, las verificaciones en los traslados y la reconciliación cierran casi todos los huecos en tiempo real. Lo que queda es la deriva más lenta, que solo se ve cuando alguien con contexto de negocio mira el acceso de una persona y se pregunta si sigue teniendo sentido. Eso es la certificación de accesos, que trata el próximo módulo.

Un proceso de JML bien instrumentado hace más fácil la certificación, no solo la deja para después. Un traslado que registró su verificación de conflictos, lo que encontró y cómo se resolvió le da a quien revisa algo concreto que mirar en lugar de una lista pelada de entitlements. Una baja con la hora de finalización confirmada por la reconciliación hace que una revisión nunca tenga que preguntarse si la persona de verdad se fue y quedó limpia; eso ya está respondido.

JML es además una de las mejores fuentes para saber cuándo vale la pena una revisión dirigida. Algunos programas envían un traslado con un conflicto aceptado directamente a la owner de la aplicación para una confirmación rápida, del tipo “esta persona ahora tiene estos dos entitlements, con este control compensatorio, ¿te sigue pareciendo bien?”, y cierran el ciclo en días en lugar de esperar al siguiente ciclo trimestral. El momento en que el acceso cambió de verdad es un disparador de revisión mucho mejor que una fecha cualquiera del calendario. La excepción de Sara, si la owner hubiera elegido aceptarla, habría sido exactamente uno de esos casos: una revisión corta y dirigida un mes después de su traslado, para preguntar si el control compensatorio seguía en pie.

Medir la confianza, no solo la velocidad

El artículo de fundamentos enumera las medidas operativas que vale la pena seguir: tiempo de aprovisionamiento, tiempo de retiro, tasa de automatización, tasa de cuentas huérfanas, señales de acumulación de privilegios, número de conflictos. El gobierno suma algunas que miden si el proceso es confiable y no qué tan rápido corre.

La proporción de eventos de JML con una coincidencia de alta confianza muestra sobre cuánta población puede actuar el proceso sin revisión manual; un flujo rápido con poca confianza en el emparejamiento es rápido en tocar, quizá, a la persona equivocada. La distancia entre la finalización del flujo y la confirmación de la reconciliación muestra cuánto tiempo pasa sin verificar una afirmación de “terminado”; el tiempo de retiro se ve excelente si se mide contra la marca de tiempo del propio flujo. La proporción de traslados con una verificación de conflictos registrada muestra si el evento más riesgoso se comprueba cuando importa. Y el número de sistemas reconciliados frente al de sistemas conectados muestra cuánto del entorno real puede respaldar el programa, porque una tasa de éxito perfecta sobre una lista de conectores parcial no es cobertura completa.

Recontrataciones, licencias y otros casos raros

Un puñado de situaciones rompen los procesos de JML pensados para el empleado típico, y cada una merece una regla antes de que ocurra en lugar de un arreglo improvisado después.

Alguien recontratado que se fue hace dieciocho meses puede volver con un registro nuevo en RR. HH. o con el anterior reactivado, según cómo trabaje RR. HH. Si se reactiva el anterior, el flujo puede devolverle el acceso de su puesto previo; si se crea uno nuevo, el emparejamiento puede fallar y dejarlo con dos identidades. En cualquier caso la decisión debe tomarse a propósito, y el acceso viejo no debería volver nunca solo porque se reactivó un registro.

Las licencias largas, de maternidad o paternidad, médicas o sabáticas, no son bajas, pero tampoco deberían dejar todo el acceso activo durante meses. Muchos programas suspenden todo salvo el correo y el autoservicio de RR. HH. mientras dura la licencia y lo restituyen a la vuelta por el mismo proceso gobernado, para que quien vuelve reciba el acceso de su puesto actual y no una foto congelada.

Los traslados internos entre entidades legales, habituales después de una adquisición, pueden verse en RR. HH. como una baja en una empresa y un alta en otra el mismo día. Si se manejan de forma ingenua, la persona pierde todo el viernes y espera una semana su acceso el lunes. Si se manejan bien, el programa reconoce el par como un traslado y aplica las reglas de traslado, incluida la verificación de conflictos.

El ciclo del artículo 1, aplicado a un solo evento

El primer artículo de este dominio describió IGA como un ciclo: la administración ejecuta los cambios y el gobierno decide y verifica. Un motor de JML es administración pura, la maquinaria que aprovisiona, asigna y quita según calendario y según disparador. Todo lo que añadió este artículo, la confianza del emparejamiento decidiendo sobre qué puede actuar el motor, una verificación de conflictos en el momento del traslado, la reconciliación confirmando lo que pasó, la certificación usando el rastro de evidencia, es gobierno envuelto alrededor de esos mismos tres eventos. Convierte “el flujo corrió” en algo que un programa puede respaldar cuando le piden demostrarlo.

Ninguna mitad reemplaza a la otra. El artículo de fundamentos es lo que hace rápidas las altas y las bajas y les da a los traslados una oportunidad. Este es lo que vuelve el resultado lo bastante confiable como para aguantar una auditoría o el escrutinio honesto de quien revisa. Un programa que solo invierte en administración entrega un proceso de JML que parece rápido y se desarma la primera vez que alguien pide pruebas; uno que solo invierte en gobierno diseña políticas excelentes sobre un flujo que no puede ejecutarlas.

Resumen

• Un motor de flujos de JML ejecuta los cambios de acceso, pero no puede confirmar por sí solo que llegó a la persona correcta, a todos los sistemas, ni que no creó un problema nuevo.
• La confianza del emparejamiento debería filtrar los eventos, sobre todo los traslados, donde un emparejamiento malo cambia el acceso de la persona equivocada en lugar de dejar acceso viejo olvidado.
• La reconciliación convierte “el flujo reportó éxito” en evidencia, sobre todo en los sistemas que quedan fuera de la lista de conectores.
• Los paquetes necesitan owners y revisiones; en los contratistas, la fecha de fin es un disparador, con un aviso previo a su responsable para que las prórrogas se registren a tiempo.
• Los pasos humanos de JML necesitan niveles de servicio y valores por defecto seguros: los otorgamientos esperan o se escalan cuando nadie responde, los retiros siguen adelante.
• Los traslados son el momento natural para verificar la separación de funciones sobre el acceso viejo y el nuevo combinados, como en el paso de Sara a revisión de fraude.
• Un proceso de JML bien instrumentado alimenta la certificación con evidencia y buenos momentos para revisar, y debería medirse por su confianza además de por su velocidad.

Tres preguntas para ponerte a prueba

1. Un traslado termina con el motor de flujos reportando éxito total. Nombra dos cosas que podrían seguir mal sin que el motor lo note nunca, y qué mecanismo de este artículo detecta cada una.
2. ¿Por qué este artículo sostiene que la verificación de conflictos corresponde al momento del traslado y no a la siguiente revisión programada, y qué cuesta realmente esperar?
3. Una organización reporta un tiempo excelente para retirar el acceso en las bajas, basado por completo en las marcas de tiempo del flujo. ¿Qué preguntarías antes de confiar en esa cifra?

Ejercicio práctico

Toma un cambio de puesto que conozcas, el tuyo o el de alguien cercano, real o imaginario.

1. Enumera el acceso que la persona tenía en el puesto anterior y el que necesita el nuevo, en al menos tres sistemas.
2. Marca cualquier par, uno de cada lista, que sería un problema si una misma persona tuviera los dos, y decide si el acceso viejo debe quitarse antes o después de otorgar el nuevo.
3. Describe qué evidencia querrías después para demostrar que el acceso viejo se retiró de verdad en todas partes.
4. Anota un caso raro de este artículo (una recontratación, una licencia larga, un traslado entre entidades) y la regla que fijarías para él.