Aprovisionamiento y desaprovisionamiento: de la decisión de acceso a la cuenta real

Un token que sobrevivió a su dueño

Daniel dejó una empresa de software en febrero. Su último día fue de manual: RR. HH. cerró su ficha, el proveedor de identidad deshabilitó su cuenta en minutos y esa misma tarde devolvió el portátil a TI. En octubre, investigando una clonación inesperada de un repositorio privado, el equipo de seguridad descubre que la petición salió de un token de acceso personal que Daniel había creado dos años antes para un script de compilación. Nadie lo había revocado, porque el repositorio de código no consulta al proveedor de identidad antes de aceptar un token. Daniel no había hecho nada con él; alguien lo encontró en un script viejo de una unidad compartida. Durante ocho meses, una persona que ya no trabajaba allí tuvo una llave válida al código fuente de la empresa, y todos los paneles decían que su acceso había desaparecido.

Donde las decisiones se encuentran con los sistemas

Todo lo visto en este módulo hasta aquí trata de decisiones. Se aprueba una solicitud. Una certificación revoca algo. Cambia un rol. Una política coincide con los atributos de una persona nueva. Nada de eso cambia el mundo hasta que alguien se lo comunica a un sistema destino: una cuenta creada en el ERP, una pertenencia a un grupo añadida en el directorio, un usuario dado de baja en el CRM. Ese último paso es el aprovisionamiento, y su inverso, el desaprovisionamiento.

Es tentador tratarlo como fontanería, algo que la plataforma hace sola una vez tomadas las decisiones de gobierno interesantes. En la práctica, buena parte de los fallos reales de IGA ocurren aquí. El acceso aprobado nunca llega, así que la gente usa el usuario de un compañero. El acceso revocado sigue en su sitio porque un conector falló en silencio a las dos de la mañana. A una persona que se fue le deshabilitan a tiempo la cuenta del proveedor de identidad, pero su token personal de API del repositorio de código sigue funcionando ocho meses más, que es exactamente la historia de Daniel. Los auditores lo saben, y por eso rara vez se quedan en el registro de aprobación: casi siempre piden la prueba de que el cambio ocurrió en el sistema.

El artículo de JML defendió que un flujo que reporta éxito hace una afirmación, no demuestra un hecho, y que la reconciliación es lo que la convierte en evidencia. Este artículo baja un nivel más: cómo llega realmente el aprovisionamiento a los sistemas, dónde se rompe y qué hace un programa al respecto.

Qué hace en realidad el aprovisionamiento

Aprovisionar a alguien en un sistema suele ser más de una operación. La plataforma tiene que asegurarse de que exista una cuenta, lo que implica encontrar una que ya pertenezca a la persona o crear una nueva. Fija los atributos de la cuenta: nombre, correo, área, jefatura, a veces un centro de costo o una ubicación que la aplicación usa para sus propias reglas. Añade los entitlements que la persona debe tener, que pueden ser pertenencias a grupos, roles de la aplicación, conjuntos de permisos o asignaciones de licencia. Y en algunos sistemas tiene que entregar una primera credencial, aunque en la mayoría de los entornos modernos la cuenta está federada y la persona entra por inicio de sesión único.

Cada uno de esos pasos puede fallar por separado. Se crea la cuenta pero falla el alta en el grupo. Se añaden los grupos pero el atributo que la aplicación usa para limitar los datos está mal, y la persona ve los registros de otra región. La cuenta ya existía de un puesto anterior, nadie la correlacionó y ahora la persona tiene dos. Pensar el aprovisionamiento como una secuencia de operaciones separadas y verificables, y no como una sola acción de “dar acceso”, es el primer paso para hacerlo bien.

Los cambios durante la vida de una persona en la organización siguen el mismo patrón en piezas más pequeñas. A un mover se le añaden y quitan entitlements, se le actualizan atributos y a veces se le crea una cuenta en un sistema nuevo. Un cambio de nombre actualiza atributos en todas partes y, en principio, nada más. Esas actualizaciones importan más de lo que parece: una aplicación que limita el acceso por área seguirá mostrándole a un mover los datos de su área anterior hasta que se actualice ese atributo en la aplicación, aunque todas las pertenencias a grupos se hayan cambiado bien.

Antes de crear nada: buscar lo que ya existe

El error de aprovisionamiento más evitable es crear una cuenta que la persona ya tiene. Una recontratación, un contratista que pasó a plantilla o alguien que usó un sistema hace años en otro puesto pueden tener ya una cuenta en el destino, y crear una segunda parte su historial en dos y deja la vieja activa y sin dueño. Antes de crear nada, la plataforma debería intentar emparejar las cuentas existentes con la identidad usando las mismas reglas de correlación que describió el artículo del modelo de datos de identidad, y mandar las coincidencias dudosas a una persona en lugar de adivinar.

Los nombres también piden una decisión. Los nombres de usuario y las direcciones de correo necesitan una convención que resuelva las coincidencias (la segunda Sara López de la empresa) y una política de reutilización. Reasignarle a una persona nueva la dirección de correo de alguien que se fue es una forma silenciosa de hacerle llegar los restablecimientos de contraseña, las notificaciones de proveedores y, a veces, respuestas delicadas dirigidas a la persona anterior. Por eso muchas organizaciones nunca reutilizan direcciones, o esperan años para hacerlo.

Orden y dependencias

El aprovisionamiento entre sistemas tiene un orden, y equivocarse produce fallos que parecen aleatorios. La cuenta del directorio suele tener que existir antes que cualquier cosa que lea de él. Una aplicación SaaS federada a través del proveedor de identidad puede necesitar que el usuario esté asignado a la aplicación en el proveedor antes de que SCIM lo envíe. Un buzón necesita una licencia antes de poder crearse. Las pertenencias a grupos que deciden el acceso en aplicaciones posteriores tienen que estar antes de que esas aplicaciones se sincronicen.

Los buenos diseños hacen explícitas esas dependencias, de modo que una operación espera lo que necesita en lugar de fallar y reintentarse hasta que por casualidad sale bien. Las mismas dependencias funcionan al revés en la baja: una aplicación que toma sus usuarios de un grupo del directorio solo verá desaparecer a la persona cuando se quite la pertenencia y la aplicación se sincronice, lo que puede tardar horas salvo que el conector la dé de baja directamente.

Las vías por las que una plataforma de IGA llega a un sistema

A cada sistema destino se llega por algún tipo de conector, y ese tipo decide qué tan rápido, qué tan confiable y qué tan verificable será el aprovisionamiento en ese sistema.

SCIM es lo más parecido a un estándar universal. Una aplicación que soporta SCIM expone una API REST con un esquema común para usuarios y grupos, y cualquier plataforma de IGA o proveedor de identidad que hable SCIM puede crear, actualizar, deshabilitar y leer cuentas sin código a medida. La mayoría de las aplicaciones SaaS modernas lo soportan, aunque muchas veces solo en sus planes más caros, y el soporte varía: algunas manejan usuarios pero no grupos, otras ignoran los atributos personalizados, otras aceptan una “desactivación” pero no permiten leerla de vuelta para confirmarla.

Los conectores de directorio y LDAP cubren Active Directory, Entra ID y otros directorios. Son maduros y rápidos, y para muchas organizaciones el directorio es el destino más importante de todos, porque muchísimas aplicaciones deciden el acceso según la pertenencia a grupos del directorio.

Las API propias de cada aplicación cubren sistemas con su propia interfaz REST o SOAP pero sin SCIM. Necesitan un conector escrito para esa API concreta, lo traiga el proveedor de IGA o lo construya el programa. Funcionan bien y se rompen cuando el fabricante cambia la API.

Los conectores de base de datos escriben directamente en las tablas de usuarios y permisos de una aplicación. Son habituales en aplicaciones antiguas desarrolladas en casa. También son arriesgados, porque se saltan la lógica de la propia aplicación: una inserción directa puede crear un usuario que la aplicación considera inválido u omitir un registro de auditoría que la aplicación habría escrito.

Los intercambios por archivo envían un CSV o similar que la aplicación importa según un calendario, y leen una exportación para reconciliar. Son lentos y frágiles, pero a veces la única opción para sistemas viejos.

La ejecución manual, por último, significa que no hay conector. La plataforma crea una tarea para una persona, normalmente el administrador del sistema, que hace el cambio a mano y marca la tarea como completada.

flowchart LR
  accTitle: Tipos de conector entre la plataforma de IGA y los sistemas destino
  accDescr: La plataforma de IGA aprovisiona el acceso mediante varios tipos de conector. Los conectores SCIM llegan a las aplicaciones SaaS modernas. Los conectores de directorio llegan a Active Directory y Entra ID. Los conectores de API a medida llegan a aplicaciones con interfaz propia. Los conectores de base de datos y de archivos llegan a sistemas antiguos desarrollados en casa. Los sistemas sin interfaz reciben tareas manuales para un administrador. La reconciliación lee el acceso de todos los sistemas, incluidos los manuales mediante exportaciones.
  IGA[Plataforma de IGA] --> S[SCIM<br/>SaaS moderno]
  IGA --> D[Directorio<br/>AD, Entra ID]
  IGA --> A[Conectores<br/>de API a medida]
  IGA --> F[Base de datos o archivo<br/>sistemas antiguos]
  IGA --> M[Tarea manual<br/>sin interfaz]

Aplicaciones desconectadas

La mayoría de las organizaciones tienen muchas más aplicaciones que conectores. Una empresa mediana puede usar 200 aplicaciones y tener conectores automatizados para 40. El resto están desconectadas: aprovisionarlas significa un ticket o una tarea para una persona, y nadie sabe con certeza qué acceso existe en ellas salvo que alguien lo exporte.

Es tentador dejarlas fuera del alcance. Suelen ser justo donde está el riesgo. Las herramientas financieras viejas, los portales de proveedores, los sistemas clínicos de nicho y el SaaS de un área pagado con tarjeta de crédito tienden a quedar fuera de la lista de conectores, y son exactamente los lugares donde una persona que se fue conserva acceso durante meses.

Un enfoque realista ordena las aplicaciones desconectadas por riesgo y avanza por la lista. Para las de mayor riesgo, construir un conector, o pagar el plan del SaaS que incluye SCIM, suele valer la pena. Para el siguiente nivel, una exportación programada de usuarios y permisos, cargada en la plataforma de IGA, le da a la reconciliación algo con qué comparar aunque el aprovisionamiento siga siendo manual. Para el resto, tareas manuales con un nivel de servicio y una revisión mensual suelen bastar. Lo que no funciona es dejar una aplicación completamente fuera del programa porque no tiene API; que no haya conector no dice nada sobre si hay acceso.

Las tareas manuales necesitan la misma disciplina que cualquier otra vía de aprovisionamiento. Deben llevar exactamente lo que se aprobó, no un resumen en texto libre. Deben tener fecha de vencimiento, y las vencidas deben escalarse. Y que el administrador cierre la tarea no debería ser la única prueba de que se hizo; la siguiente exportación o reconciliación debería confirmarlo.

Desaprovisionar es más difícil que aprovisionar

Cuando falla un aprovisionamiento, alguien se da cuenta rápido, porque no puede trabajar y lo dice. Cuando falla un desaprovisionamiento, nadie se da cuenta, porque la persona que conserva el acceso casi nunca tiene motivos para quejarse. Esa asimetría es la razón por la que la mayor parte de la atención en el diseño debería ir al retiro.

La primera decisión es qué significa “retirar”. Quitar un solo entitlement, a un mover o tras una certificación, suele ser sencillo. Retirar a una persona entera, cuando se va, es una secuencia con decisiones dentro. Deshabilitar una cuenta corta su uso de inmediato pero conserva sus datos y su historial. Borrarla libera la licencia y el nombre, pero puede destruir buzones, archivos y registros de auditoría que la organización todavía necesita. La mayoría de los programas deshabilita de inmediato en la fecha de baja, o en el momento en que RR. HH. registra un despido, y borra más adelante, tras un plazo de retención definido y una vez que la titularidad de los archivos, buzones compartidos y tareas programadas de la persona se ha pasado a otra.

Ese traspaso es fácil de olvidar. Quien se va puede ser dueño de una carpeta compartida que usa todo el equipo, de un reporte programado del que depende finanzas, de una integración que corre con sus credenciales o de la cuenta de administración de una herramienta SaaS que compró su área. Borrar su cuenta rompe todo eso; dejarla activa deja el acceso abierto. La solución es una tarea de traspaso, normalmente para la jefatura, con una fecha límite anterior al borrado.

El inicio de sesión único no es desaprovisionamiento

Deshabilitar la cuenta de la persona en el proveedor de identidad es el paso más rápido e importante de una baja, y corta de una vez los nuevos inicios de sesión por SSO en todas las aplicaciones federadas. No es el final del trabajo. Muchas aplicaciones mantienen las sesiones vivas durante horas o días después del último inicio de sesión. Muchas siguen teniendo cuentas locales con contraseña propia, creadas antes de configurar el SSO o conservadas como respaldo. Los desarrolladores crean tokens de acceso personal y claves de API en repositorios de código y consolas cloud que funcionan sin ningún SSO. Las apps móviles guardan refresh tokens.

Por eso un proceso de baja completo deshabilita primero la cuenta del proveedor de identidad y después entra en cada aplicación de alto riesgo para deshabilitar la cuenta local, revocar sesiones y revocar tokens, mediante su conector donde exista y mediante una tarea donde no. El artículo de gestión de sesiones explicó por qué las sesiones sobreviven a los inicios de sesión; aquí es donde eso se convierte en un problema de desaprovisionamiento.

Cuando las operaciones fallan

Los conectores fallan todo el tiempo, y un programa que da por hecho que no fallarán acumula poco a poco accesos que nadie quería. Los sistemas destino entran en mantenimiento. Las API limitan la cantidad de llamadas. Caducan las contraseñas de las cuentas de servicio. Una validación de campo rechaza un valor. Un fabricante cambia un endpoint sin avisar.

Un motor de aprovisionamiento bien hecho trata cada operación como algo que puede fallar y reintentarse. Las operaciones entran en una cola. Los fallos temporales se reintentan con esperas cada vez más largas, y los permanentes, como un valor rechazado, se envían a una persona en lugar de reintentarse para siempre. Las operaciones se escriben de forma que ejecutarlas dos veces no haga daño, algo importante porque un reintento tras un tiempo de espera agotado puede repetir una operación que en realidad funcionó la primera vez. Y los resultados parciales se registran con honestidad: si se creó la cuenta pero fallaron dos de cinco grupos, el registro debería decir exactamente eso, no “falló” ni “salió bien”.

Las bajas merecen el mayor cuidado. Un alta fallida aparece como una queja. Una baja fallida no aparece como nada, así que las operaciones de desaprovisionamiento fallidas deberían alertar a alguien y quedar visibles en un panel hasta resolverse, con un nivel de servicio más estricto para el acceso privilegiado y las bajas de personal.

Las fechas de fin solo funcionan si algo actúa sobre ellas

El artículo de solicitud de acceso defendió que casi todo acceso lleve fecha de fin, y el de políticas sumó reglas de ciclo de vida para contratistas y personal de temporada. Las dos cosas dependen de que el aprovisionamiento haga algo cuando llega la fecha. Suena automático y falla de varias formas previsibles.

El proceso de vencimiento corre a medianoche en la zona horaria de la plataforma, que es mitad de la jornada para un equipo al otro lado del mundo, y el acceso desaparece mientras alguien lo está usando o, al revés, dura un día entero más de lo previsto. El conector del destino está caído el día del vencimiento, la baja falla y nada la reintenta, porque el proceso de vencimiento solo mira los accesos que vencen hoy. El acceso con fecha de fin se quita de la asignación de rol en la plataforma de IGA pero nadie avisa al sistema destino, así que la plataforma dice que ya no está mientras el sistema sigue teniéndolo.

Las soluciones no tienen nada de vistoso. El vencimiento debería generar operaciones de baja que pasen por la misma cola con reintentos que cualquier otro desaprovisionamiento, no un proceso de un solo intento. La hora de vencimiento debería definirse en la zona horaria de la propia persona, o al final de su jornada. Los recordatorios de renovación deberían salir varios días antes, para que las renovaciones legítimas no dependan de que alguien note que el acceso desapareció. Y la reconciliación debería buscar específicamente accesos vencidos que siguen presentes en el destino, que es justo el hueco que deja un vencimiento fallido.

Reconciliación y deriva

La reconciliación, presentada en el artículo de JML, es el proceso periódico de leer las cuentas y entitlements reales de cada sistema destino, lo que se suele llamar agregación, y compararlos con lo que la plataforma de IGA cree que debería haber. Las diferencias se llaman deriva (drift) y vienen en unas pocas formas reconocibles.

Una parte de la deriva es aprovisionamiento que no ocurrió: un alta aprobada que falta en el sistema o un entitlement revocado que sigue ahí. Eso apunta a una operación fallida o a una tarea manual cerrada sin hacerse, y la solución es reintentar o escalar.

Otra parte es acceso que apareció sin pasar por el programa: alguien añadió un usuario a un grupo directamente en el directorio, o un administrador de la aplicación otorgó un permiso desde la consola. Es la “puerta lateral” del artículo de solicitud de acceso, y necesita una decisión. El acceso puede revocarse, si nadie puede justificarlo. Puede adoptarse, si resulta ser legítimo, y entonces debería registrarse como una asignación aprobada con owner en lugar de aceptarse sin más. O puede marcarse para investigar, si es privilegiado o parece sospechoso.

Y otra parte son cuentas que no corresponden a ninguna identidad: cuentas huérfanas de personas que se fueron antes de que existiera el programa, cuentas de prueba, cuentas creadas para un proveedor hace años. Cada una necesita que se le encuentre un owner o que se deshabilite.

flowchart TD
  accTitle: Qué hacer con la deriva que encuentra la reconciliación
  accDescr: La reconciliación compara el acceso que espera la plataforma de IGA con el que encuentra en cada sistema destino. Si falta un acceso esperado o sigue presente uno revocado, la operación de aprovisionamiento se reintenta o se escala. Si existe un acceso que la plataforma nunca otorgó, su owner decide si revocarlo, adoptarlo como asignación aprobada o investigarlo. Si una cuenta no corresponde a ninguna identidad, se trata como huérfana: se le busca owner o se deshabilita.
  R[La reconciliación encuentra una diferencia] --> Q{¿De qué tipo?}
  Q -->|Cambio esperado<br/>que no está en el sistema| RT[Reintentar o escalar<br/>la operación]
  Q -->|Acceso que la plataforma<br/>nunca otorgó| DEC{Decide el owner}
  DEC --> RV[Revocar]
  DEC --> AD[Adoptar como<br/>asignación aprobada]
  DEC --> IN[Investigar]
  Q -->|Cuenta sin<br/>identidad| OR[Huérfana: buscar owner<br/>o deshabilitar]

Con qué frecuencia reconciliar depende del riesgo y de lo que permita el sistema. Los directorios y el SaaS principal suelen poder agregarse a diario o incluso más seguido. Los ERP grandes a veces se agregan cada semana porque una lectura completa es costosa. Las aplicaciones desconectadas se reconcilian cada vez que llega su exportación, a menudo una vez al mes. Lo importante es que los sistemas de alto riesgo se reconcilien con la frecuencia suficiente para que una baja fallida o un acceso por la puerta lateral se detecte en días, no en la siguiente auditoría.

Algunos programas van más allá y dejan que la plataforma corrija la deriva sola, quitando cualquier acceso que no otorgó en cuanto lo ve. Es eficaz y también tosco: quitará el arreglo de emergencia que hizo un administrador durante una caída. La corrección automática funciona mejor con entitlements de alto riesgo y bien entendidos, como la pertenencia a grupos privilegiados del directorio, donde cualquier miembro sin explicación debe salir de inmediato, con una alerta que explique por qué.

Licencias: la parte que le importa a finanzas

La mayoría de las aplicaciones SaaS cobran por cuenta, así que el desaprovisionamiento tiene una cara de costos que sirve de argumento para el trabajo. Una cuenta que sigue activa después de que su usuario se fue sigue consumiendo una licencia, igual que una cuenta cuyo usuario simplemente dejó de usar la aplicación. Los datos de reconciliación, combinados con la fecha del último inicio de sesión en cada aplicación, muestran las dos cosas.

Los programas que reportan licencias recuperadas junto a las métricas de seguridad suelen conseguir presupuesto para conectores con más facilidad. Un conector para una aplicación SaaS con unos cuantos cientos de puestos pagados a menudo se paga solo el primer año, simplemente dando de baja a tiempo a quienes se van y recuperando los puestos que llevan 90 días sin uso. Y les da a los owners de aplicación un motivo para interesarse por el desaprovisionamiento que no tiene nada que ver con las auditorías.

Mantener sanos los conectores

Un conector es software que depende del sistema de otro, y se degrada sin que nadie lo toque. El fabricante retira una versión de la API. La cuenta de servicio que usa el conector ve caducar su contraseña o recortar sus permisos. Aparece un campo obligatorio nuevo en la aplicación y todas las altas empiezan a fallar. El sistema destino se migra a otra URL.

Los síntomas suelen ser silenciosos. La señal más útil es el tiempo transcurrido desde la última agregación correcta de cada conector: un conector que lleva cuatro días sin leer su destino casi seguro también está fallando al aprovisionar. Junto a eso, la tasa de errores por conector y el tamaño de cada cola de reintentos dicen dónde mirar primero.

Los cambios en los conectores merecen pruebas contra una copia no productiva del destino, con identidades de prueba que cubran los casos incómodos (una recontratación, un cambio de nombre, un mover con un rol en conflicto). Y las credenciales del propio conector necesitan el mismo cuidado que cualquier otra cuenta privilegiada, porque un conector de IGA suele tener permisos para crear y borrar usuarios en el sistema que gestiona. Una cuenta de conector comprometida es una vía directa para otorgar acceso en cualquier lugar al que llegue el programa.

Cuentas no humanas

Las cuentas de servicio, los usuarios de integración y los clientes de API también se aprovisionan, a menudo fuera de todo proceso. Un desarrollador crea una cuenta de servicio en la consola cloud para una integración nueva, le da permisos amplios para que funcione y sigue con lo suyo. Nadie la aprovisionó por IGA y nadie la desaprovisionará cuando se retire la integración.

Incorporarlas al programa empieza por la reconciliación, que las encuentra como cuentas sin identidad humana. Cada una necesita un owner, un propósito y, a ser posible, un rol técnico acotado, como proponía el artículo de ingeniería de roles. Las nuevas deberían solicitarse por el mismo proceso que el acceso humano, con owner y fecha de revisión. Y cuando se retira una aplicación, sus cuentas de servicio necesitan un desaprovisionamiento explícito, porque ningún evento de RR. HH. lo va a disparar.

Ejemplo trabajado: las bajas en una empresa de software

Una empresa de software con 900 personas usa unas 130 aplicaciones. Su proveedor de identidad gestiona el SSO de 95 y su plataforma de IGA tiene conectores SCIM o de API para 35. Una revisión de seguridad tras un incidente descubre que antiguos empleados seguían teniendo acceso funcional a 11 aplicaciones meses después de irse, sobre todo mediante cuentas locales y tokens personales.

El equipo de IAM empieza clasificando las 130 aplicaciones. Para cada una registra si usa SSO, si permite inicios de sesión locales, si los usuarios pueden crear tokens, cuánto duran las sesiones y si hay conector. Esa clasificación, armada con cada owner de aplicación, da tres grupos. Veintidós aplicaciones de alto riesgo (el repositorio de código, las consolas cloud, la herramienta de administración de la base de clientes, el sistema de facturación, la plataforma de soporte con datos de clientes) reciben un paso de desaprovisionamiento propio. Sesenta de riesgo medio se apoyan en el SSO más una reconciliación semanal. El resto, solo en el SSO.

Para el grupo de alto riesgo, el equipo construye o habilita conectores donde se puede, lo que cubre 15 de las 22. El flujo de bajas ahora deshabilita la cuenta del proveedor de identidad a la hora de la baja y luego, mediante esos conectores, deshabilita cuentas locales, revoca sesiones y revoca tokens personales. Para las siete restantes, el flujo crea tareas manuales para los administradores con un nivel de servicio de cuatro horas en los despidos y de un día hábil en los demás casos.

La reconciliación corre a diario para las 22 de alto riesgo y cada semana para el nivel siguiente. En su primera ejecución encuentra 140 cuentas de personas que ya se habían ido, entre ellas 9 tokens personales activos en el repositorio de código y 3 usuarios de consola cloud con derechos de administrador. Todas se deshabilitan ese mismo día y los tokens se revocan.

Seis meses después, el tiempo entre la baja y el retiro completo en las aplicaciones de alto riesgo es de menos de cuatro horas para todas las personas que se van, la reconciliación lleva dos meses seguidos sin encontrar a ningún exempleado con acceso y el incidente que originó el trabajo tiene un control documentado que lo resuelve.

Un ejemplo más corto: un sistema heredado sin API

El sistema bancario central de una cooperativa de ahorro y crédito es de los años noventa y no tiene API. La administración de usuarios la hacen dos operadores en una pantalla de terminal. El aprovisionamiento siempre se ha pedido por correo.

El programa no intenta construir un conector. Envía los cambios aprobados a los operadores como tareas con el perfil exacto que hay que dar o quitar, controla un nivel de servicio de dos días y escala las tareas vencidas a la jefatura de operaciones. Además consigue una exportación nocturna de la tabla de usuarios, que el sistema ya sabía producir para sus propios reportes, y la carga en la plataforma de IGA. La reconciliación contra esa exportación confirma cada tarea al día siguiente de completarse y atrapa algún cambio ocasional hecho sin tarea. Es más lento que una API, y alcanza para darles a los auditores evidencia de que cada cambio se aprobó, se ejecutó y se confirmó.

Errores frecuentes

El mayor es tratar la lista de conectores como si fuera el alcance del programa. Las aplicaciones sin conector suelen ser las de más riesgo y menos supervisión.

Confiar en el SSO para desaprovisionar deja atrás cuentas locales, sesiones y tokens. Borrar las cuentas el día de la baja destruye datos que la organización necesitaba y rompe lo que la persona tenía a su nombre; primero se deshabilita, luego se traspasa y después se borra.

Cerrar tareas manuales sin confirmación convierte el aprovisionamiento en un sistema de palabra de honor. Reintentar en silencio las bajas fallidas, o no reintentarlas, deja vivo un acceso que todos creen desaparecido.

Y correr la reconciliación sin actuar sobre lo que encuentra produce largos reportes de deriva que no son de nadie. Cada tipo de diferencia necesita una respuesta definida y alguien responsable de ella.

Qué medir

La segunda fila merece la mayor atención. Auditores y reguladores preguntan por ella directamente, y es la cifra que mejor refleja si una persona que se va realmente se va.

Cómo se relaciona con los estándares

El estándar técnico aquí es SCIM 2.0, definido en la RFC 7643 para el esquema y la RFC 7644 para el protocolo, la forma abierta de aprovisionar usuarios y grupos entre dominios. Los marcos de control piden lo mismo con otras palabras. La NIST SP 800-53 Rev. 5 cubre en AC-2 la creación, modificación, deshabilitación y eliminación de cuentas, y sus mejoras AC-2(2), AC-2(3) y AC-2(4) añaden el retiro automático de cuentas temporales, la deshabilitación de las inactivas y la auditoría de las acciones sobre cuentas. PCI DSS v4.0 es la más directa: el requisito 8.2.5 quiere que el acceso de los usuarios dados de baja se revoque de inmediato, y el 8.2.6, que las cuentas inactivas se eliminen o deshabiliten en un plazo de 90 días. ISO/IEC 27001:2022, en el control 5.18 de su Anexo A, exige que los derechos de acceso se otorguen, modifiquen y retiren según reglas definidas. Y los criterios de SOC 2, en CC6.2, esperan que el acceso se retire cuando deja de hacer falta, algo que los auditores comprueban eligiendo una muestra de bajas y revisando cada una, tokens incluidos.

Cerrando el ciclo

El aprovisionamiento es donde trabaja la mitad administrativa de IGA que describió el primer artículo de este dominio, y la reconciliación es donde el gobierno comprueba que ese trabajo se hizo. Todas las decisiones de este módulo, desde las aprobaciones hasta las certificaciones y los cambios de reglas, dependen de esta capa para hacerse realidad. Un programa con políticas excelentes y un aprovisionamiento débil produce decisiones muy bien documentadas de las que los sistemas nunca se enteraron.

Resumen

El aprovisionamiento convierte decisiones en cambios en sistemas reales, cuentas, atributos y entitlements, y cada uno de esos pasos puede fallar por su cuenta; antes de crear algo, hay que buscar lo que ya existe. Las vías van desde SCIM y los directorios hasta API a medida, bases de datos, archivos y tareas manuales, y cuanto menos automatizada es la vía, más depende el programa de la reconciliación. Las aplicaciones desconectadas concentran buena parte del riesgo, así que se ordenan, se conectan las más riesgosas, el siguiente nivel se reconcilia con exportaciones y ninguna se deja fuera solo porque no tiene API. Retirar acceso es más difícil que darlo porque sus fallos son silenciosos: primero se deshabilita, después se traspasa lo que la persona poseía y al final se borra, sin confiar nunca en que el inicio de sesión único cierre las cuentas locales, las sesiones y los tokens como el que dejó Daniel. Las operaciones deben poder reintentarse, poder repetirse sin efectos secundarios y registrarse con honestidad, con una alerta cada vez que falle una baja, y las fechas de fin necesitan bajas que pasen por esa misma cola de reintentos, en la zona horaria de la persona, además de una reconciliación que busque expresamente accesos caducados que siguen ahí. Los conectores hay que vigilarlos, sobre todo el tiempo desde su última lectura correcta, y sus credenciales merecen la misma protección que cualquier cuenta privilegiada. Y como la reconciliación siempre encuentra deriva, cada tipo de deriva necesita una respuesta decidida de antemano: reintentar, revocar, adoptar, investigar o buscar owner.

Tres preguntas para ponerte a prueba

1. La cuenta del proveedor de identidad de una persona que se fue se deshabilitó diez minutos después de la baja. Enumera tres formas en que podría seguir teniendo acceso a sistemas de la empresa una semana después.
2. La reconciliación encuentra un usuario en un grupo privilegiado del directorio que ninguna solicitud ni regla otorgó. Describe las tres decisiones posibles y qué evidencia te llevaría a cada una.
3. ¿Por qué borrar todas las cuentas de una persona el día que se va suele ser peor opción que deshabilitarlas?

Ejercicio práctico

Toma cinco aplicaciones que uses, en el trabajo o a título personal.

1. Para cada una, averigua (o estima) si usa SSO, si permite inicios de sesión locales, si puedes crear tokens personales o claves de API y cuánto dura una sesión.
2. Clasifica cada una como de riesgo alto, medio o bajo e indica qué tipo de conector usarías para aprovisionarla.
3. Escribe en orden los pasos de desaprovisionamiento que necesitaría un proceso de baja para la de mayor riesgo, incluido todo lo que el SSO por sí solo no cerraría.
4. Decide con qué frecuencia reconciliarías cada aplicación y qué harías con una cuenta que encontraras sin que nadie la hubiera aprobado.