Modelo de datos de identidad: fuentes autoritativas, correlación y calidad de datos

Tres listas que no coinciden

Una empresa sin modelo de datos de identidad no parece rota desde afuera. RR. HH. lleva su propia lista de empleados. Active Directory tiene otra, armada durante años con cuentas creadas sobre la marcha, algunas viejas y unas cuantas duplicadas, como la de la empleada que aparece una vez con su apellido de soltera y otra con el de casada. El sistema de tickets tiene una tercera lista de “solicitantes” que se cruza con las otras dos sin coincidir con ninguna. Si preguntas cuántas personas trabajan hoy allí con acceso activo a los sistemas, no hay un único lugar donde mirar. Hay tres listas, no coinciden, y conciliarlas a mano se vuelve un proyecto cada vez que pregunta un auditor.

El artículo anterior describió IGA como un ciclo entre la administración, que ejecuta los cambios, y el gobierno, que decide y verifica. Las dos mitades de ese ciclo dependen de responder con confianza una sola pregunta: ¿quién es esta persona? El aprovisionamiento no puede asignar el entitlement correcto al registro de la persona equivocada. Una revisión no puede pedirle a una jefa que juzgue el acceso de alguien que aparece dos veces, con dos nombres apenas distintos, sin que ella note que algo no cuadra y pierda la confianza en todo el ejercicio.

Todo lo demás en este módulo se apoya en un modelo de datos, y si el modelo está mal, ninguna buena política ni ninguna revisión bien hecha lo arregla. Este artículo trata de esa capa: de dónde saca sus datos una plataforma de IGA y qué se rompe cuando esos datos están mal.

Tres decisiones en el centro

Un modelo de datos de identidad no tiene por qué ser exótico. En el fondo son tres decisiones. Qué sistema tiene la confianza para decir que una persona existe y trabaja aquí: la fuente autoritativa. Cómo se enlazan los registros que describen a la misma persona en sistemas distintos: la correlación. Y cómo se entera la plataforma de que un registro enlazado se alejó de la realidad: la reconciliación.

Si esas tres se resuelven bien y temprano, todas las capacidades de gobierno que se construyen después, revisiones, verificaciones de separación de funciones, roles, heredan una base en la que se puede confiar. Si se resuelven mal o se saltan, cada una de esas capacidades hereda la misma duda de fondo sobre si el registro que tiene delante sigue siendo cierto.

A veces las organizaciones postergan un programa de IGA porque sus datos de identidad “todavía no están lo bastante limpios”, como si hubiera una línea de salida limpia que esperar. En la práctica, el modelo de datos es lo que vuelve visible y corregible el desorden. Esperar datos limpios antes de construir lo que los limpiaría es una forma segura de que el programa nunca empiece.

Qué hace autoritativa a una fuente

Una fuente autoritativa es el sistema cuyo registro de un dato se toma como la verdad para el gobierno: cuando otro sistema no coincide, gana la fuente autoritativa, de forma automática, sin que nadie tenga que arbitrar cada conflicto. Es más que decir “este sistema tiene buenos datos”. Un sistema puede tener datos excelentes y aun así ser la elección equivocada si no es el primer lugar donde se registra el dato.

Para casi todo lo que importa de un empleado, si sigue trabajando aquí, su puesto, su jefatura, su centro de costo, la fuente correcta es el sistema de RR. HH. La razón es estructural, no de calidad de datos. RR. HH. tiene que saber que alguien entró antes de que nómina pueda pagarle, y tiene que saber que se fue antes de que nómina deje de hacerlo. Esa obligación es lo que hace confiable el dato: no se registra como un favor a TI, sino como parte de otro proceso de negocio que se rompería si estuviera mal.

Active Directory se confunde a menudo con una fuente autoritativa porque es central y todo el mundo lo usa. Pero está aguas abajo. Una cuenta se crea ahí porque RR. HH. avisó de una contratación, porque lo pidió una jefatura o, más a menudo de lo que nadie admite, porque alguien de la mesa de ayuda la creó a mano para que una persona nueva pudiera trabajar su primer día. AD es una excelente autoridad sobre un dato acotado, si una cuenta existe y a qué grupos pertenece, y una mala autoridad sobre si la persona sigue trabajando aquí, porque no tiene ninguna razón estructural para saberlo antes ni mejor que RR. HH.

La idea que conviene retener es que la autoridad depende de dónde nace un dato, no de qué sistema parece más completo o más actualizado. Una hoja de cálculo actualizada hace una hora sigue siendo peor fuente que un sistema de RR. HH. actualizado ayer. Nada garantiza que la hoja se siga actualizando, nada registra quién cambió qué y nada impide que para el próximo trimestre dos personas mantengan dos copias distintas de “la” hoja.

Vale la pena dejar las decisiones por escrito y revisarlas con una cadencia fija. Un registro de una página que nombre exactamente un sistema autoritativo para cada atributo gobernado (situación laboral: RR. HH.; jefatura: RR. HH.; existencia de cuentas: AD; pertenencia a grupos: AD; fecha de fin de contrato: sistema de proveedores) resuelve más disputas reales de las que parece. Sin él, cada desacuerdo entre dos sistemas se discute de manera informal por quien lo note primero, con una respuesta distinta cada vez.

Quienes no son empleados necesitan una fuente real, no una excepción

Casi todo modelo que arranca con “RR. HH. es autoritativo” choca con la misma pared en su primera reunión de diseño: RR. HH. solo conoce a los empleados. Contratistas, consultores, personal de proveedores, usuarios de socios y cuentas de servicio necesitan acceso gobernado y necesitan existir en algún lugar del modelo, y ninguno de ellos fue contratado nunca.

El error habitual es parcharlos sobre el modelo de empleados como una pequeña excepción: una lista mantenida a mano, un grupo especial en AD, una hoja de cálculo que alguien promete mantener al día. Falla por la misma razón por la que falla una hoja de cálculo en cualquier otro lugar. Nada obliga a mantenerla exacta, y quienes no son empleados son justamente la población cuyas fechas de fin nadie recuerda.

El enfoque que dura trata a quienes no son empleados como una categoría gobernada propia, con su propia fuente autoritativa. Un sistema de gestión de proveedores, o un registro dedicado, cumple para los contratistas el mismo papel que RR. HH. para los empleados. La existencia y la fecha de fin de un contrato se registran ahí como parte de procesos de compras, legales o financieros que tienen sus propios motivos para saber si el contrato sigue vigente. Cuando ese sistema dice que un contrato terminó, el modelo de identidad tiene un disparador confiable para retirar el acceso sin esperar a que alguien abra un ticket.

Pregúntale a un programa de IGA cuál es su fuente autoritativa para contratistas, y una cantidad sorprendente responde que en realidad no tiene; TI crea la cuenta cuando lo pide una jefatura. Esa respuesta significa que ninguna identidad de contratista de la organización tiene una fecha de fin que se haga cumplir, ni un disparador para retirarla, ni una forma confiable de saber si el contrato sigue en marcha. Es sistemáticamente de lo primero que vale la pena arreglar, porque los contratistas suelen tener mucho acceso en proporción a lo bien que se gobiernan.

flowchart TD
  accTitle: Varias fuentes autoritativas alimentan un único modelo de identidad
  accDescr: El sistema de RR. HH. es la fuente autoritativa de los empleados y envía altas, cambios de puesto y bajas. Un sistema de gestión de proveedores o un registro de no empleados es la fuente autoritativa de contratistas y personal de proveedores y envía el inicio y el fin de cada contrato. Un registro de cuentas de servicio guarda el owner, el propósito y el vencimiento de las identidades no humanas. Las tres alimentan una única capa de correlación y gobierno, que dirige el aprovisionamiento en los sistemas destino.
  HRIS[Sistema de RR. HH.<br/>empleados] -->|alta, cambio de puesto, baja| CORR[Capa de correlación<br/>y gobierno]
  VMS[Sistema de proveedores o registro<br/>contratistas, proveedores] -->|inicio y fin de contrato| CORR
  SVC[Registro de cuentas de servicio<br/>identidades no humanas] -->|owner, propósito, vencimiento| CORR
  CORR --> PROV[Aprovisionamiento en<br/>sistemas destino]

Las cuentas de servicio y demás identidades no humanas necesitan un tercer carril en el mismo esquema. No tienen puesto ni jefatura en el sentido de RR. HH., pero igual necesitan un owner, un propósito documentado y, a ser posible, un vencimiento o una justificación periódica. Sin eso se acumulan igual que las cuentas humanas olvidadas. Una cuenta de servicio sin fuente registrada y sin owner es invisible para el gobierno desde el día en que se crea, no solo olvidada con el tiempo. Más adelante en este dominio, el artículo sobre higiene de identidades trata lo que pasa cuando falta esa titularidad.

Elegir un identificador que no cambie

Emparejar registros de forma confiable depende de la clave con la que se emparejan, y la elección del identificador merece más reflexión de la que suele recibir. Un buen identificador se asigna una sola vez, cuando la persona aparece por primera vez en una fuente autoritativa, y nunca se reasigna ni se reutiliza, ni siquiera años después para una persona nueva sin ninguna relación. La reutilización convierte una clave confiable en un error silencioso: una persona nueva hereda el identificador de otra que ya se fue, y cada sistema que lo tenía guardado apunta un pedazo de acceso viejo a la persona equivocada.

Hay dos opciones cómodas que conviene evitar. Una dirección de correo parece natural porque está en todas partes, pero los correos cambian con un matrimonio, un cambio de marca o una migración de dominio, y una clave que cambia pierde su sentido la primera vez que lo hace. Un identificador oficial, como el número de documento nacional o de seguridad social, es peor por otra razón: es un dato personal sensible que no debería copiarse en cada sistema solo para servir de clave de unión, y las leyes de privacidad consideran ese tipo de dispersión innecesaria justo lo que pretenden evitar.

La mayoría de los programas maduros terminan con un ID de identidad hecho a propósito y opaco, generado una sola vez en la fuente autoritativa y llevado como atributo a cada cuenta de los sistemas destino. No significa nada fuera del sistema de identidad, no cambia durante toda la vida de la identidad y no se recicla nunca, ni siquiera cuando la persona se va. Incorporar esa costumbre antes de que decenas de aplicaciones aprendan a emparejar con algo más débil sale mucho más barato que hacerlo después.

Qué atributos modelar y cuáles dejar fuera

Tienta traer al modelo de identidad todos los campos que ofrece el sistema de RR. HH., con la idea de que más datos no pueden hacer daño. Sí pueden. Cada atributo del modelo hay que mantenerlo exacto, sincronizado y protegido, y algunos crean riesgos propios.

Un núcleo pequeño cubre casi todo lo que necesita el gobierno: el ID de identidad, el nombre legal y el de uso, el correo de trabajo, el tipo de relación (empleado, contratista, becario), el estado, las fechas de alta y de fin, la jefatura, el área o centro de costo, el código de puesto y la ubicación. Esos son los atributos que leen de verdad las políticas, las revisiones y el proceso de altas, cambios y bajas. Todo aquello de lo que dependa una regla de acceso merece un cuidado extra, porque una regla es tan confiable como el campo que la sostiene, algo que el artículo de políticas desarrolla más adelante en este dominio.

Algunos campos conviene dejarlos fuera salvo que un uso concreto los exija. La fecha de nacimiento, los identificadores oficiales, el domicilio y el salario rara vez ayudan a decidir un acceso, y copiarlos en una plataforma de IGA, y desde ahí en cada sistema conectado, multiplica los lugares donde viven datos personales sensibles. Las leyes de privacidad de casi todas las jurisdicciones, desde el RGPD hasta las leyes de protección de datos de América Latina, esperan que las organizaciones recojan solo lo que necesitan para un propósito declarado. Un modelo de identidad es un buen lugar para practicarlo.

También ayuda decidir, para cada atributo, si solo fluye de la fuente autoritativa hacia los demás sistemas o si otros sistemas también pueden escribirlo. El nombre de uso y el teléfono suelen poder editarse por la propia persona en un portal de autoservicio. El área y la jefatura casi nunca deberían poder hacerlo, porque dejar que alguien distinto de RR. HH. los cambie permitiría que la gente cambiara su propio acceso.

La correlación: reconocer a la misma persona en todas partes

Con las fuentes resueltas, el siguiente problema es enlazar registros. La misma persona existe como una fila en RR. HH., una cuenta en AD, un buzón de correo y usuarios en una docena de aplicaciones SaaS, y ninguno de esos sistemas sabe que describen al mismo ser humano. La correlación establece ese vínculo.

La forma limpia es la determinista: emparejar con un identificador estable y único que compartan todos los sistemas, como el ID de identidad de la sección anterior, llevado a cada cuenta como atributo. Cuando la clave existe y está cargada de forma consistente, la correlación se parece mucho a una unión en una base de datos. Por eso los buenos programas invierten temprano en llevar el identificador a las cuentas de cada sistema conectado, incluso a aplicaciones viejas que nunca se diseñaron para eso. Convierte la correlación de un problema de análisis permanente en una tarea de integración que se hace una vez.

La correlación determinista no siempre es posible, sobre todo en sistemas heredados que se aprovisionaron mucho antes de que nadie pensara en ella, o donde las cuentas se crearon a mano sin nada consistente. Entonces se recurre a la correlación probabilística: una combinación de atributos que juntos son un indicio fuerte, como el nombre (tolerando diferencias de formato), el área, la jefatura, la fecha de alta y a veces una extensión telefónica o un número de credencial. Ningún atributo es confiable por sí solo, porque los nombres se repiten, las áreas cambian de nombre y la gente comparte jefaturas, pero una combinación puntuada suele dar una coincidencia o una no coincidencia con confianza. El grupo más pequeño de casos dudosos lo decide una persona.

Esa revisión manual es el tercer método, indispensable para los casos límite y del todo inútil como enfoque principal para una población grande. Un programa sensato usa los tres: el determinista donde puede, el probabilístico para el resto heredado y a las personas para lo que queda.

Los casos que rompen el emparejamiento

Un puñado de situaciones reales rompen los dos métodos y merecen reglas explícitas en lugar de lo que la lógica de emparejamiento haga por defecto.

Los cambios de nombre son los más comunes. Un matrimonio, un divorcio o una transición de género producen un cambio de nombre legal durante el empleo. Un modelo que empareja en parte por nombre tiene que dar más autoridad al identificador estable que al nombre, y necesita un proceso definido para actualizar los demás sistemas sin crear una segunda identidad, huérfana, con el nombre anterior.

Después vienen las recontrataciones. Alguien se va y vuelve dieciocho meses después. Si recibe un registro de identidad nuevo o se reactiva el anterior es una decisión de política con consecuencias reales. Reactivar el anterior puede devolverle acceso viejo de un puesto que ya no existe; crear uno nuevo puede romper la continuidad que esperan los procesos de RR. HH. y de auditoría.

Las identidades duplicadas son registros que deberían ser uno: muchas veces resultado de una fusión, o de dos áreas que dieron de alta al mismo contratista sin saberlo. Si no se unifican, cada registro acumula su propio acceso y ninguna revisión ve el cuadro completo de esa persona.

Las cuentas compartidas y genéricas, como un usuario “escaner-almacen” o “pc-sala-capacitacion”, no pertenecen a una persona a propósito. Hay que marcarlas como tales en lugar de dejar que aparezcan cada mes como fallos de emparejamiento sin explicación que alguien vuelve a investigar.

Y las identidades de socios, personas de otra organización que entran en un portal de proveedores o en una plataforma de derivaciones compartida, no están en el sistema de RR. HH. ni en el de proveedores de esta organización, porque las emplea otra. Emparejarlas suele depender de los datos de federación del proveedor de identidad del socio, una aserción SAML o un claim de OIDC con el identificador estable del propio socio. La pregunta de gobierno cambia en consecuencia. La organización socia es la autoridad sobre si la persona sigue trabajando allí; lo que le toca a la organización que recibe es confiar en esa aserción, retirar el acceso rápido cuando deja de llegar y resistirse a armar una copia local de una población que no tiene forma de mantener al día.

La reconciliación: detectar la deriva antes de que se acumule

La correlación crea un vínculo una vez. La reconciliación lo mantiene honesto comparando con regularidad lo que la plataforma de IGA cree que son las cuentas y el acceso de cada identidad con lo que existe de verdad en los sistemas destino, y mostrando las diferencias.

La deriva suele tener causas muy comunes. Un administrador de base de datos crea un usuario a mano a las dos de la mañana durante un incidente, con la idea de formalizarlo después, y no lo hace. Alguien cambia algo directamente en AD porque es más rápido que abrir una solicitud. Un conector falla en silencio durante tres semanas y deja de transmitir las bajas, así que cuentas que deberían haber desaparecido siguen activas. Nada de esto es malintencionado, y nada aparece a menos que algo compare el estado previsto con el real según un calendario.

flowchart TD
  accTitle: La reconciliación compara el estado gobernado con el real y resuelve la deriva
  accDescr: Según un calendario, el proceso de reconciliación lee las cuentas y el acceso reales de cada sistema destino y los compara con el estado gobernado que la plataforma de identidad considera correcto. Si coinciden, no hace falta nada. Si no, la diferencia se clasifica como un cambio hecho por fuera del proceso, una cuenta sin identidad dueña o un acceso que ya no se justifica, y cada caso va a su propia vía de resolución.
  SCHED([Ejecución programada]) --> PULL[Leer el estado real<br/>de los sistemas destino]
  PULL --> COMPARE{¿Coincide con el estado gobernado?}
  COMPARE -->|Sí| OK([Nada que hacer])
  COMPARE -->|No| CLASSIFY{¿Qué tipo de deriva?}
  CLASSIFY -->|Cambio fuera del proceso| FLAG[Revisar y corregir el proceso]
  CLASSIFY -->|Sin identidad dueña| ORPHAN[Limpieza de cuentas huérfanas]
  CLASSIFY -->|Ya no se justifica| STALE[Enviar a certificación]

Con qué frecuencia se corre la reconciliación importa tanto como su funcionamiento. Una vez al año, encuentra de golpe la deriva de un año entero: cuentas huérfanas, cambios fuera del proceso y conectores caídos, casi siempre justo antes de una auditoría, que es el peor momento posible. Los programas que reconcilian los sistemas de alto riesgo cada día o cada semana mantienen cada hallazgo lo bastante chico como para que sea un arreglo rápido y no un proyecto. El artículo de aprovisionamiento, más adelante en este dominio, profundiza en cómo funciona la reconciliación y qué hacer con cada tipo de deriva.

Cómo los datos malos rompen el gobierno más adelante

Todo esto es invisible mientras funciona. Se vuelve visible en el momento en que falla, porque cada capacidad de gobierno hereda lo que el modelo de datos haya hecho mal, casi siempre de una manera difícil de rastrear hasta la causa.

Las revisiones se rompen primero, y en silencio. Dale a una jefa una revisión en la que tres filas son en realidad el mismo contratista, porque dos altas distintas crearon registros duplicados. Ella no lo sabe. Ve tres entradas desconocidas con nombres apenas distintos y las aprueba las tres, porque rechazar alguna podría dejar sin acceso a un compañero por lo que tal vez sea un detalle de formato. Multiplica eso por cada duplicado y cada fallo de emparejamiento de la población, y una revisión que debía ser un control real se convierte en un trámite de clics. La revisora no es descuidada; los datos que tiene delante no permiten una revisión cuidadosa.

El aprovisionamiento se rompe después, y con ruido. Una solicitud aprobada para “David de Finanzas” se ejecuta para el David equivocado, porque el emparejamiento usó el nombre en un área con dos David y ninguno tenía el identificador cargado en el sistema destino. La persona equivocada de pronto tiene un acceso que no pidió, la correcta sigue sin lo que necesita y todos se enteran. La causa es un hueco de emparejamiento que nadie había priorizado, porque hasta ese día no había provocado un fallo visible.

Un ejemplo trabajado: 340 cuentas que nadie sabía explicar

Un prestador de salud mediano hace su primera revisión completa de accesos dieciocho meses después de implantar una plataforma de IGA. La campaña saca a la luz 340 registros de identidad sin ninguna coincidencia en RR. HH.: sin ID de identidad, sin vínculo con un empleado activo, solo cuentas acumuladas durante años de creación directa en AD.

El equipo pasa la lista a una hoja de cálculo, le suma lo que cada sistema sabe del último inicio de sesión y la fecha de creación, y empieza a preguntar a los owners por cada cuenta. Al investigarlas, se reparten en tres grupos. Alrededor del 60% son cuentas de servicio legítimas que nunca se registraron en ningún lado. Cerca del 30% son cuentas realmente huérfanas de personas que se fueron hace años. El 10% restante son contratistas activos cuyos contratos se seguían en una hoja de cálculo que el equipo de compras dejó de actualizar tras un cambio de personal del que nadie avisó.

Ninguna de las 340 era malintencionada, y todas eran invisibles para el gobierno hasta que alguien buscó cuentas sin coincidencia. Es justo el tipo de hallazgo que la reconciliación debería producir de forma rutinaria. Aquí apareció una sola vez, durante una primera campaña de revisión que se retrasó tres semanas por la limpieza.

Un segundo ejemplo: lo que una fusión le hace al emparejamiento

El ejemplo de salud es deriva que se acumula despacio dentro de una sola organización. Las fusiones producen el mismo problema de golpe y a una escala mucho mayor. Cuando una aseguradora mediana compra a un competidor regional, las dos empresas llegan con dos sistemas de RR. HH., dos bosques de AD y casi siempre algo de superposición: personas que trabajaron en ambas en distintos momentos, contratistas compartidos y convenciones que chocan. En este caso, resultó que las dos empresas numeraban sus IDs de empleado empezando por el 1.

Emparejar la población combinada no consiste en pasar los datos de la empresa adquirida por la lógica que ya usa la compradora. La mayor parte de la correlación da por hecho que hay una fuente autoritativa por dato, y durante un tiempo después de una fusión eso deja de ser cierto: dos fuentes reclaman autoridad sobre dos poblaciones que se superponen. Los programas que lo tratan como un proyecto de datos deliberado, antes de retomar las revisiones, terminan con una imagen realmente unificada de quién es quién. Los que lanzan revisiones directamente sobre el directorio fusionado heredan años de ruido de identidades duplicadas que nadie presupuestó arreglar.

La calidad de los datos es una medida, no una limpieza

La calidad de los datos no es un proyecto de una sola vez con fecha de fin. Es una propiedad permanente del modelo, y hay que medirla de forma continua, con una línea base registrada antes de que nadie se atribuya mejoras. En los programas maduros se repiten tres medidas.

Seguidas como tendencias y reportadas junto a las medidas operativas del artículo anterior, estas cifras hacen dos cosas. Le dan al programa evidencia defendible de que los datos mejoran, o una alerta temprana cuando empeoran, algo que suele pasar después de una fusión, un conector nuevo o un cambio en un proceso de RR. HH. Y les dan a revisores y auditores un motivo para confiar en los reportes construidos sobre esos datos, en lugar de tratar cada revisión como una investigación nueva.

Si todavía no hay línea base, un barrido único es un punto de partida legítimo: intenta emparejar cada cuenta de cada sistema conectado con una persona, aunque sea a mano en una hoja de cálculo y antes de que exista ninguna plataforma, y cuenta lo que no coincide. No escala como proceso permanente, pero te da el número de partida que hace medible cualquier mejora posterior, que es el paso que las organizaciones más se saltan.

Quién es dueño de los datos

Un modelo de datos tiene owners igual que los entitlements y los roles, y la mayoría de los problemas de datos resultan ser problemas de titularidad disfrazados.

RR. HH. es responsable de la exactitud de los registros de empleados, pero sus prioridades son la nómina y el cumplimiento, no el acceso. Un código de puesto cargado con una semana de retraso no le molesta a nómina y sí significa que el acceso de una persona nueva llega con una semana de retraso. La solución suele ser una conversación y un acuerdo, no un cambio técnico: qué campos mueven el acceso, en cuánto tiempo hay que cargar los cambios y a quién de RR. HH. llamar cuando algo no cuadra. Algunos programas van más allá y suman un reporte sencillo de calidad de datos que RR. HH. revisa cada mes, con los registros sin área, las jefaturas que ya se fueron o los códigos de puesto que no existen.

Compras, o quien lleve el sistema de proveedores, es responsable de los registros de contratistas de la misma manera, y suele necesitar la misma conversación, porque la fecha de fin es el campo que más importa para el acceso y el que más a menudo queda vacío.

El equipo de IAM es responsable de la lógica de correlación y del registro de fuentes autoritativas, y le toca llevar los problemas a los owners de cada fuente. Lo que no debería hacer es corregir en silencio los datos de origen dentro de la plataforma de IGA. Una corrección que arregla un área equivocada en la plataforma pero no en RR. HH. se sobrescribirá en la siguiente sincronización o, peor, les ocultará el problema a quienes podrían arreglarlo para siempre.

Cómo se relaciona con los estándares

El modelo descrito aquí refleja la estructura de los estándares que usa la industria para intercambiar datos de identidad:

• SCIM (RFC 7643 y RFC 7644) define un esquema estándar y una API REST para representar y aprovisionar identidades y sus atributos. Es lo más parecido a una respuesta compartida sobre cómo es el esquema básico de un registro de identidad, y vale la pena conocerlo aunque no aprovisiones por SCIM, porque marca cómo piensan los atributos la mayoría de los conectores modernos.
• El capítulo sobre gestión del ciclo de vida de la identidad del IDPro Body of Knowledge trata la elección de fuentes autoritativas y la correlación como bases del ciclo de vida.
• Los estudios de analistas sobre el mercado de IGA mencionan una y otra vez la calidad de los datos de identidad y la cobertura de quienes no son empleados entre las razones más comunes por las que una implantación rinde menos de lo prometido, un argumento útil cuando una línea de trabajo de calidad de datos necesita su propio presupuesto en lugar de quedar como nota al pie de la compra de una plataforma.

Nada de esto exige adoptar SCIM entero antes de empezar. Saber que “primero hay que acertar con el modelo de datos” es consenso documentado entre profesionales ayuda la próxima vez que un calendario de proyecto empuje a un equipo a saltar directo a las campañas de revisión sobre una base sin verificar.

La base del resto del módulo

¿Cómo sabe una plataforma de IGA, con confianza, quién es alguien? Mediante fuentes autoritativas elegidas por razones estructurales y no por comodidad: RR. HH. para los empleados y fuentes propias para todos y todo lo demás. Mediante una correlación que enlaza registros entre sistemas, de forma determinista donde hay una clave común y probabilística, con reglas explícitas para los casos difíciles, donde no la hay. Y mediante una reconciliación que mantiene honestos esos vínculos, con la frecuencia suficiente para que cada hallazgo siga siendo chico.

Nada de esto aparece en una demostración. Un proveedor que muestra una campaña de revisión elegante o un catálogo de solicitudes está mostrando las partes de IGA que se notan. El modelo de datos que hay debajo decide si se puede confiar en todo eso, y muchas veces es lo que separa a los programas que aguantan una auditoría de los que descubren, en plena auditoría, que un tercio de lo que gobernaban nunca fue realmente suyo.

Resumen

• Una fuente autoritativa es donde nace un dato, no solo el sistema con los datos más recientes: RR. HH. para los empleados y fuentes propias para quienes no son empleados y para las identidades no humanas.
• Usa como clave de emparejamiento un ID de identidad estable, opaco y que nunca se reutilice; evita los correos y los identificadores oficiales.
• Modela un núcleo chico de atributos que de verdad usen las decisiones de acceso, deja fuera los campos sensibles que nadie necesita y decide qué atributos solo puede escribir la fuente.
• La correlación enlaza registros de forma determinista mediante esa clave, probabilística mediante atributos puntuados y manual para el resto, con reglas explícitas para cambios de nombre, recontrataciones, duplicados, cuentas compartidas y socios.
• La reconciliación detecta la deriva según un calendario; cuanto más a menudo corre en los sistemas de alto riesgo, más chico es cada hallazgo.
• Los datos malos rompen las revisiones en silencio y el aprovisionamiento con ruido.
• Mide las tasas de coincidencia, huérfanas y duplicados como tendencias, y trata los problemas de datos como problemas de titularidad con los owners de cada fuente.

Tres preguntas para ponerte a prueba

1. AD muestra a una empleada como activa y RR. HH. la muestra de baja desde hace dos semanas. ¿Qué sistema gana y qué te dice eso sobre por qué AD nunca fue una buena autoridad sobre la situación laboral?
2. Un proceso de emparejamiento enlaza cuentas solo por nombre y área. Nombra dos situaciones de este artículo en las que produciría una coincidencia equivocada y qué señal adicional arreglaría cada una.
3. Una campaña de revisión muestra una tasa de aprobación inusualmente alta y casi ninguna revocación. ¿Qué explicación de calidad de datos de este artículo revisarías antes de concluir que todo el acceso es correcto?

Ejercicio práctico

Elige una organización que conozcas y dos o tres sistemas que se usen allí.

1. Escribe el registro de fuentes autoritativas: para la situación laboral, la jefatura, el puesto, la fecha de fin de contrato y la existencia de cuentas, nombra el único sistema que debería ser autoritativo y explica por qué.
2. Para cada sistema, averigua qué identificador llevan las cuentas y si serviría para un emparejamiento determinista.
3. Describe cómo manejarías una recontratación y un cambio de nombre en esa organización.
4. Estima las tasas de coincidencia, huérfanas y duplicados que esperarías encontrar en un primer barrido, y di con qué owner de fuente hablarías primero sobre lo que encuentres.