Ingeniería de roles: top-down, bottom-up, híbrido y minería de roles

Once auxiliares y un perfil copiado

Sara López dirige las operaciones de finanzas de una aseguradora regional, y su última auditoría trajo un hallazgo que no sabe explicar. Varias personas de cuentas por pagar pueden crear un proveedor en el ERP y además aprobar los pagos a ese proveedor. Nadie recuerda haber otorgado esa combinación. A cada persona nueva de su equipo se le da acceso copiando el de un compañero, ese compañero lo recibió igual, y después de suficientes años de copias el acceso ya no describe ningún puesto que alguien haya diseñado. La recomendación del auditor cabe en una línea: “definir roles”. Hacerlo bien ocupa casi todo este artículo, y volveremos al equipo de Sara cuando tengamos las piezas.

Lo primero es aclarar la palabra, porque hasta aquí este dominio ha usado “rol” de dos maneras. El artículo del catálogo de entitlements definió el rol como un paquete de entitlements con nombre, asignado a una población: Auxiliar de cuentas por pagar, con su registro de facturas, su conciliación de órdenes de compra y su consulta de proveedores. El artículo siguiente, sobre los roles en un programa de IGA, dejó ese sentido a un lado a propósito y usó la palabra como la usa todo el mundo fuera de IAM: el puesto de una persona. La arquitecta, el analista de negocio, la owner de la aplicación, el oficial de cumplimiento.

La ingeniería de roles es el punto donde esos dos sentidos se encuentran. Los roles que se diseñan aquí son paquetes, en el sentido del catálogo. Pero cada paquete pretende reflejar un puesto real de la organización, y quienes lo construyen son las personas del artículo 5. El analista de negocio hace las entrevistas. La owner de cada aplicación decide qué entra en su parte del paquete. La arquitecta define la estructura, cumplimiento lo contrasta con las reglas de separación de funciones y el foro de gobierno lo aprueba. Un rol, en el sentido de acceso, termina siendo una respuesta por escrito a la pregunta “¿qué necesita este puesto?”, producida por gente cuyos propios puestos define el programa.

Tener presentes los dos sentidos ayuda a seguir el resto del artículo. Cuando un diseño de roles sale mal, la causa casi siempre es un desajuste entre el paquete y el puesto que dice representar, o un hueco en quién debía mantenerlos alineados. El hallazgo de Sara es ese desajuste en estado puro: paquetes que se alejaron de cualquier puesto porque nadie era su owner.

De RBAC como modelo a los roles como programa

El dominio de gestión de accesos ya explicó el control de acceso basado en roles como modelo: a los usuarios se les asignan roles, los roles llevan permisos y comprobar un acceso se reduce a comprobar la pertenencia a un rol. Aquel artículo contaba cómo funcionan los roles. Un programa de IGA se topa en su primer mes con otra pregunta: ¿cuáles deberían ser, en concreto, nuestros roles?

Parece un ejercicio de diseño que se hace una vez. En la práctica no termina nunca. Alguien tiene que decidir qué cuarenta entitlements entran en el rol de auxiliar, si el auxiliar de la oficina de Monterrey necesita el mismo rol que el de San Salvador, quién aprueba un cambio en el rol y qué hacer con los once auxiliares que tienen permisos de edición de proveedores que nadie sabe explicar. Después se actualiza el ERP, se renombran dos entitlements, llega una herramienta de reportes nueva y las preguntas vuelven a empezar. Ese trabajo continuo es la ingeniería de roles.

Importa porque los roles cargan con buena parte del peso del resto de este módulo. JML los usa como el paquete birthright que recibe quien entra. La solicitud de acceso puede ofrecer un rol en lugar de doce entitlements sueltos. La certificación puede revisar una sola vez el contenido de un rol en vez de revisar los mismos cuarenta entitlements para cada uno de sus miembros. Si los roles están bien, todos esos procesos se achican. Si están mal, el error se copia a todos los que tienen el rol, y cuesta más verlo que antes porque ahora se esconde detrás de un nombre razonable.

Roles de negocio y roles técnicos

Casi todas las organizaciones que pasan de unas pocas decenas de roles acaban con dos capas, porque quienes entienden los puestos y quienes entienden los sistemas rara vez son las mismas personas.

Un rol técnico agrupa entitlements dentro de un único sistema. “ERP: procesamiento de cuentas por pagar” reúne exactamente los entitlements del ERP necesarios para registrar y conciliar facturas, y su owner es la owner del ERP, que sabe qué permite en realidad cada uno. Un rol de negocio nombra un puesto y se arma con roles técnicos de varios sistemas. “Auxiliar de cuentas por pagar” contiene el rol técnico del ERP, uno del archivo documental, uno de reportes y el acceso al espacio compartido del equipo de finanzas. Su owner es quien dirige la función, en este caso la dirección de operaciones de finanzas, que sabe lo que exige el puesto sin necesidad de conocer el modelo de permisos del ERP.

flowchart TD
  accTitle: Un rol de negocio armado con roles técnicos
  accDescr: El rol de negocio Auxiliar de cuentas por pagar, cuyo owner es la dirección de operaciones de finanzas, se compone de tres roles técnicos. El rol de procesamiento de cuentas por pagar del ERP, cuyo owner es la owner del ERP, contiene los entitlements para registrar facturas, conciliar órdenes de compra y consultar los datos maestros de proveedores. Un rol documental da lectura al archivo de facturas y un rol de reportes da acceso al dashboard de cuentas por pagar.
  BR[Rol de negocio<br/>Auxiliar de CxP<br/>owner: dir. de operaciones]
  BR --> TR1[Rol técnico<br/>ERP: procesamiento CxP<br/>owner: owner del ERP]
  BR --> TR2[Rol técnico<br/>Documentos: archivo de facturas]
  BR --> TR3[Rol técnico<br/>Reportes: dashboard de CxP]
  TR1 --> E1[Registrar facturas]
  TR1 --> E2[Conciliar órdenes de compra]
  TR1 --> E3[Consultar datos maestros<br/>de proveedores]
  TR2 --> E4[Leer archivo de facturas]
  TR3 --> E5[Ver dashboard de CxP]

La separación se paga sola la primera vez que algo cambia. Si el proveedor del ERP parte un entitlement en dos, la owner del ERP corrige el rol técnico y todos los roles de negocio que lo usan quedan corregidos a la vez. El rol del dashboard de CxP puede vivir dentro de los roles de auxiliar, supervisor y contralor sin definirse tres veces. Y cada decisión cae en quien puede tomarla: finanzas decide quién es auxiliar, la owner del ERP decide qué puede hacer un auxiliar dentro del ERP.

Una organización pequeña puede saltarse la segunda capa durante un tiempo. Con cinco o seis sistemas centrales, un rol de negocio puede apuntar directamente a los entitlements sin que nadie se pierda. El modelo de dos capas empieza a compensar cuando hay más sistemas de los que una persona de negocio puede tener en la cabeza, cosa que suele pasar antes de lo que se espera.

Jerarquías, pero poco profundas

El estándar RBAC permite además jerarquías de roles: un rol superior hereda todo lo que otorga uno inferior y le suma lo suyo. Supervisor de CxP hereda Auxiliar de CxP y añade la aprobación de pagos hasta cierto límite. Ahorra repetición y encaja con cómo se piensan las carreras dentro de una empresa.

También esconde acceso. Quien certifica el rol de supervisor ve sus entitlements propios y puede no darse cuenta de que debajo viaja todo el rol de auxiliar, más lo que ese rol herede a su vez. Con cuatro o cinco niveles, nadie sabe qué otorga un rol sin una herramienta que lo aplane. La herencia incluso puede armar un conflicto de separación de funciones que nadie diseñó: el supervisor hereda “registrar factura” del auxiliar, suma “aprobar pago”, y una sola persona queda con las dos mitades de un conflicto de manual. Conviene quedarse en uno o dos niveles, mostrar a los revisores el contenido ya aplanado y correr las verificaciones de conflictos sobre esa vista.

Empezar por el negocio: top-down

La ingeniería de roles top-down arranca de cómo describe la organización su propio trabajo. Un analista de negocio se sienta con quien dirige una función, dibuja los procesos que lleva el equipo, los descompone en los puestos que los ejecutan y luego trabaja con los owners de aplicación para listar lo que cada puesto necesita en cada sistema.

En un departamento de finanzas, eso puede significar mapear compra-a-pago, registro-a-reporte y tesorería, y nombrar los puestos que viven dentro: auxiliar de CxP, supervisor de CxP, contador de libro mayor, analista de tesorería. Para cada puesto, el analista hace las mismas preguntas en cada sistema que toca el equipo. ¿Qué necesita ver esta persona? ¿Qué necesita modificar? ¿Qué no debería poder aprobar nunca?

El resultado se lee como una mezcla de organigrama y mapa de procesos, y esa es su virtud. Quien certifica “Analista de tesorería” sabe de qué se trata. La separación de funciones se puede diseñar desde el principio, porque el analista trabaja sobre los pasos del proceso y ve que crear un proveedor y aprobar su pago corresponden a puestos distintos. Y los roles describen cómo se supone que debe ser el acceso, no cómo quedó después de años de copiar y pegar.

Sus debilidades son igual de previsibles. Las entrevistas llevan semanas y dependen de agendas muy ocupadas. Nadie recuerda todos los sistemas que usa un puesto, así que el rol se olvida de la herramienta de reportes de nicho, del portal de proveedores, de la carpeta compartida de la que vive todo el mundo. Y el rol describe el puesto tal como lo imagina su jefatura. Si despliegas un rol puramente top-down, es habitual que la mitad de sus miembros pidan los mismos tres entitlements faltantes la primera semana.

Empezar por los datos: bottom-up y minería de roles

La ingeniería de roles bottom-up parte de lo que la gente ya tiene. El programa extrae todas las asignaciones de entitlements a usuarios de los sistemas conectados, con el mismo descubrimiento y la misma agregación que describió el artículo del catálogo, y busca conjuntos de entitlements que mucha gente comparte. La técnica que hace esto a escala es la minería de roles (role mining).

Imagina una cuadrícula enorme con una fila por persona, una columna por entitlement y una marca donde la persona tiene ese entitlement. Los algoritmos de minería buscan grupos de filas que comparten casi las mismas columnas, y las columnas comunes de cada grupo se convierten en un rol candidato. Las matemáticas cambian de un producto a otro, pero la idea no pasa de ahí.

flowchart TD
  accTitle: De las asignaciones en bruto a los roles candidatos revisados
  accDescr: Las asignaciones en bruto de entitlements a personas se limpian quitando cuentas huérfanas e inactivas y el acceso que ya se gobierna como birthright. Un paso de clustering agrupa a las personas que comparten conjuntos parecidos de entitlements. Cada grupo se contrasta con atributos de RR. HH. como el área y el puesto. Los candidatos que superan los umbrales de calidad pasan a un owner de negocio, que los aprueba, los ajusta o los rechaza.
  A[Asignaciones<br/>persona x entitlement] --> C[Limpiar los datos<br/>sin huérfanas, inactivas<br/>ni birthright]
  C --> K[Agrupar personas<br/>por entitlements compartidos]
  K --> AT[Contrastar con RR. HH.<br/>área, puesto, ubicación]
  AT --> Q[Aplicar umbrales de calidad]
  Q --> R[El owner de negocio revisa:<br/>aprobar, ajustar, rechazar]

Unas pocas decisiones prácticas determinan si la minería entrega algo aprovechable. Primero, limpiar la entrada: las cuentas huérfanas, la gente inactiva y las cuentas de servicio deforman los grupos, y el acceso birthright aparece en todos si no lo sacas. Segundo, minar un departamento o una aplicación a la vez, porque minar una empresa entera de golpe suele dar o un puñado de megarroles sin sentido o miles de roles diminutos. Tercero, fijar con cuidado dos umbrales: a cuántas personas tiene que cubrir un candidato para merecer un rol, y qué proporción de los miembros de un grupo debe tener un entitlement para incluirlo. Con umbrales bajos salen más roles, más chicos y más ajustados; con umbrales altos salen menos roles, más amplios y con más excepciones.

Después hay que usar los atributos de RR. HH. para explicar lo que salió. Un grupo cuyos miembros comparten área y puesto probablemente es un puesto real. Uno sin nada evidente en común es, o un equipo informal que vale la pena conversar, o el rastro de alguien que copió su propio acceso a cada persona nueva.

Ese último caso es el que hay que vigilar. La minería describe el presente y no tiene forma de saber si el presente está bien. Si una supervisora pasó años dándole a cada auxiliar nuevo permisos de edición de proveedores, la minería propondrá un rol de auxiliar que los incluye, y ese rol le entregará automáticamente un conflicto de separación de funciones a cada auxiliar futuro. Por eso los candidatos minados siempre pasan por alguien capaz de distinguir “todos tienen esto” de “todos deberían tener esto”, y por eso un candidato llamado “Cluster 47” no es un rol hasta que alguien le pone un nombre de negocio y se hace responsable de él.

Donde convergen los dos enfoques

Casi todos los programas de roles que funcionan en la práctica son híbridos. El top-down aporta intención y estructura; el bottom-up aporta evidencia y cobertura. Lo interesante pasa donde no coinciden, porque cada desacuerdo dice algo.

Una secuencia que funciona en la mayoría de las organizaciones es esta. Se arma un esqueleto top-down de un área del negocio: los puestos, sus owners y una idea aproximada de lo que necesita cada uno, sin intentar todavía listar cada entitlement. Luego se mina el acceso real de esa misma área y se ponen los grupos al lado del esqueleto.

Donde un grupo coincide con un puesto, sus entitlements pasan a ser el contenido borrador del rol, ya con nombre de negocio y owner. Donde el puesto prevé un acceso que los datos no muestran, hay que preguntar si de verdad lo necesita; a veces la entrevista describía un trabajo que pasó a otro equipo hace dos años. Donde los datos muestran un acceso que el puesto no preveía, alguien tiene que decidir si es legítimo, y entonces entra en el rol, o si es exceso acumulado, y entonces queda fuera y la certificación se encarga de retirarlo.

Antes de activar cualquier rol borrador, hay que pasarlo por las reglas de separación de funciones, ya aplanado por si hay jerarquía, porque un rol con un conflicto dentro se lo asigna a todos sus miembros de una vez. Después se prueba con un equipo durante unas semanas, se observan las excepciones y las solicitudes de acceso que faltaba, se ajusta y se amplía.

Casi todo el valor sale de esa conciliación. Cada diferencia entre la imagen que el negocio tiene de su propio trabajo y el acceso que la gente tiene de verdad es, o algo que el negocio no sabía de sí mismo, o un acceso que no debería existir. Las dos cosas vale la pena encontrarlas, y solo aparecen si se hacen las dos mitades.

Es también el segundo lugar donde convergen los dos sentidos de “rol”. Las personas sentadas en esa conciliación son exactamente las del artículo 5: el analista que hizo las entrevistas, los owners de aplicación que saben qué hace cada entitlement, la arquitecta dueña de la estructura y cumplimiento revisando el resultado contra la política. Un programa de roles que solo tiene ingenieros de IAM puede correr la minería. No puede hacer la conciliación.

Además lleva más tiempo de lo que la minería hace pensar. El clustering de una función de 60 u 80 personas corre en una tarde. Las entrevistas, las reuniones de conciliación, las verificaciones de conflictos y el piloto suelen llevar de cuatro a ocho semanas para esa misma función, casi todo esperando el tiempo de los owners de negocio. Planificar el programa alrededor de la parte lenta, y reservar las agendas de los owners antes de empezar con los datos, evita lo de siempre: una pila de candidatos minados esperando revisión durante meses y caducando a medida que la gente cambia de puesto.

Cómo es un buen rol

Ayuda ponerse de acuerdo en criterios de calidad antes de crear roles, porque sin ellos se aprueba cada pedido de “un rol solo para nosotros” y el catálogo empieza a desbordarse.

Un rol debería cubrir casi todo lo que necesitan sus miembros. Si cada Ajustador de siniestros sigue pidiendo ocho entitlements por su cuenta, al rol le falta algo. Sus miembros tampoco deberían cargar muchas excepciones; una excepción es acceso que alguien tiene fuera de sus roles, y aunque unas pocas son normales (un proyecto, una asignación temporal), un rol cuyos miembros promedian diez excepciones probablemente tiene el contenido equivocado.

Debería tener miembros suficientes como para que valga la pena gestionarlo. Un rol con dos personas es un perfil de acceso individual con nombre. Muchos programas fijan un mínimo de cinco a diez miembros y permiten excepciones explícitas para puestos únicos y de alto riesgo, como un firmante de tesorería.

No puede contener un conflicto de separación de funciones. Si un puesto necesita de verdad las dos mitades de un conflicto, eso es un problema del proceso que se resuelve con un control compensatorio, no algo para enterrar en la definición de un rol donde nadie volverá a mirarlo.

Y necesita un owner y un nombre que se entienda. “Ajustador de siniestros, hogar, autoridad hasta $25.000” le dice algo a quien aprueba y a quien certifica. “CLM_ADJ_GRP_3” no les dice nada.

La explosión de roles

La explosión de roles ocurre cuando una organización termina con más roles de los que puede entender, certificar o mantener. Hay empresas que llegan a tener más roles que empleados. Nadie lo planea. Se acumula pedido razonable tras pedido razonable.

La causa más común es convertir cada variante de un puesto en un rol propio. Cajeros en cuatro regiones, con tres niveles de antigüedad y dos turnos, se convierten en 24 roles de cajero. Otra causa es crear un rol nuevo cada vez que alguien necesita un acceso un poco distinto, porque es más rápido que discutir si el rol existente está bien. Los roles creados para una reorganización o un proyecto puntual casi nunca se retiran, así que siguen asignables y siguen apareciendo en las campañas de certificación. Y la minería con umbrales flojos produce un candidato por cada grupito de los datos.

Normalmente se ve venir. El número de roles crece más rápido que la plantilla, muchos roles tienen menos de cinco miembros, hay pares de roles que se diferencian en uno o dos entitlements, algunas personas acumulan diez roles o más, y los certificadores no saben explicar la diferencia entre dos roles que les toca revisar.

El arreglo de fondo es dejar de codificar la variación como roles. Se mantiene un único rol de Cajero y lo demás lo resuelven los atributos y las políticas: el atributo de sucursal decide qué cuentas puede ver el cajero y su nivel de autoridad fija el límite de cada transacción. Es el control de acceso basado en atributos trabajando junto a los roles en lugar de reemplazarlos. El rol dice qué tipo de trabajo hace la persona; los atributos dicen qué recursos y qué límites concretos aplican dentro de ese trabajo. La mayoría de las organizaciones que controlan la explosión de roles terminan con un diseño híbrido de este tipo, RBAC con ABAC.

Lo demás es proceso, y le corresponde al foro de gobierno del artículo 5: umbrales de calidad antes de aprobar un rol nuevo, una revisión periódica del catálogo de roles, alertas automáticas para los roles que bajan de su mínimo de miembros y una forma definida de retirarlos.

Roles para quienes no son empleados

El artículo del modelo de datos de identidad separó a los empleados de los contratistas, los proveedores y las identidades no humanas, cada uno con su fuente autoritativa. El diseño de roles tiene que respetar esa separación.

Un contratista que hace el trabajo de un auxiliar de CxP puede necesitar el acceso operativo del auxiliar pero ninguno de los entitlements reservados a empleados que excluye la elegibilidad por población del catálogo, y su rol debería terminar junto con el contrato. Se puede resolver con una versión más acotada del rol de negocio para contratistas, o con un único rol cuyos entitlements se filtran por población al asignarse. La segunda opción evita duplicar el número de roles, algo importante después de todo lo dicho sobre la explosión.

Las cuentas de servicio y demás identidades no humanas casi nunca encajan en roles de negocio. No tienen un puesto; tienen una integración que ejecutar. Darle a una cuenta de servicio un rol de negocio pensado para personas es una forma habitual de que termine con mucho más acceso del que necesita la integración. Funciona mucho mejor un rol técnico acotado por integración, cuyo owner sea el equipo de la aplicación responsable y que se revise en las revisiones de cuentas del artículo de certificación.

El ciclo de vida del rol y sus dos revisiones

Los roles envejecen igual que los entitlements, así que pasan por los mismos estados que describió el artículo del catálogo: propuesto, activo, revisado, obsoleto y retirado. La diferencia es que un rol necesita dos revisiones distintas, y muchos programas solo hacen una.

La primera revisa la pertenencia: ¿cada persona del rol debería seguir en él? Para los roles de negocio que se asignan solos a partir de RR. HH. (todo el que tiene el código de puesto 4410 recibe Auxiliar de CxP), la pertenencia depende sobre todo de que el dato de RR. HH. sea correcto y del proceso JML, y revisarla persona por persona aporta poco. Para los roles que se piden, la revisión de pertenencia funciona como cualquier otra certificación.

La segunda revisa el contenido: ¿el rol sigue teniendo los entitlements correctos? Es la que detecta un rol que absorbió en silencio un entitlement de más, o uno cuyos roles técnicos cambiaron al actualizarse una aplicación. La hace el owner del rol, normalmente una vez al año y cada vez que cambia el contenido. En los roles asignados a cientos de personas pesa más que la de pertenencia, porque un rol con los miembros correctos y el contenido equivocado da el acceso equivocado a todos a la vez.

De ahí se sigue que cambiar el contenido de un rol merece el mismo cuidado que otorgar un acceso. Sumar un entitlement a un rol de 300 miembros equivale a otorgárselo a 300 personas. Ese cambio debería pedirse, justificarse, aprobarlo el owner del rol y el del entitlement, verificarse contra conflictos con el resto del rol y quedar registrado.

De vuelta al equipo de Sara

Cuentas por pagar, el área de Sara, tiene 64 personas en tres oficinas, y todas recibieron su acceso copiando el de alguien más.

El analista de negocio empieza top-down con Sara, y acuerdan tres puestos. Los auxiliares registran y concilian facturas. Los supervisores aprueban pagos hasta su límite de autoridad y resuelven excepciones. Un equipo pequeño de datos maestros crea y mantiene los proveedores, separado a propósito de los otros dos por separación de funciones.

El ingeniero de IAM mina después las asignaciones de las 64 personas en el ERP, el sistema documental y la herramienta de reportes, tras apartar el acceso birthright y tres cuentas huérfanas. Salen cuatro grupos claros. Tres coinciden con los puestos de Sara. El cuarto son once personas, todas de la misma oficina, con acceso de auxiliar más permisos de edición de proveedores.

Ese cuarto grupo es el hallazgo de auditoría, ahora visible en los datos. Resulta que un antiguo supervisor de esa oficina copió durante años su propio acceso a cada persona nueva. El grupo se descarta como rol, las once personas pasan al rol de auxiliar y sus permisos de edición de proveedores le llegan a la owner del ERP en una certificación dirigida, que los retira.

Las diferencias pequeñas también sirven. Casi todos los auxiliares tienen lectura sobre un reporte de antigüedad de saldos que nadie mencionó en las entrevistas; Sara confirma que lo usan a diario y entra en el rol de auxiliar. El borrador del rol de supervisor incluía un entitlement de conciliación bancaria que casi ningún supervisor tiene; ese trabajo pasó a tesorería hace dos años, así que se quita.

Los tres roles pasan la verificación de conflictos, porque los datos maestros de proveedores viven en su propio rol y ninguno los combina con la aprobación de pagos. Las oficinas trabajan con libros de siniestros distintos, y eso se resuelve con un atributo de región en lugar de tres copias regionales de cada rol. Después de un mes de piloto en una oficina, los roles se activan en todas. La cobertura de roles en CxP pasa de cero al 87% de su acceso, las excepciones por persona bajan de catorce a dos, las personas nuevas reciben el acceso correcto el primer día a través de su código de puesto y el hallazgo de auditoría se cierra con evidencia de que ningún rol de CxP puede otorgar las dos mitades del conflicto.

Un ejemplo más corto: cuando minar es prematuro

Una startup de 70 personas le pide a su primer ingeniero de IAM, Daniel, que “arme los roles”. Daniel encuentra 70 personas, 14 sistemas y un acceso otorgado casi siempre a mano, a medida que la gente lo pedía.

Aquí la minería daría ruido. Hay muy poca gente por puesto como para que los grupos sean estables, y la empresa se reorganiza cada pocos meses, así que cualquier rol definido hoy estará mal el trimestre que viene. Daniel propone algo más liviano: un paquete birthright para todos, cuatro o cinco roles amplios por departamento acordados en una tarde con cada responsable de área, y solicitudes de acceso con fecha de fin para todo lo demás. La minería queda en la hoja de ruta para cuando la empresa pase de unos cientos de personas y sus puestos se asienten.

La idea general es que el esfuerzo de ingeniería de roles debe crecer con el número de personas que hacen un trabajo parecido. Donde ese número es chico, unos pocos roles amplios más buenos procesos de solicitud y certificación rinden más que un modelo de roles elaborado.

Errores frecuentes

Convertir el estado actual en roles sin que lo revise un owner es el más caro, porque toma el exceso acumulado, conflictos incluidos, y lo reparte automáticamente a cada miembro futuro.

Crear un rol por cada variante de un puesto lleva directo a la explosión. Los roles sin owner se desvían: el contenido crece, la pertenencia cambia y nadie revisa ni lo uno ni lo otro. Intentar diseñar los roles de toda la organización en un solo proyecto produce un diseño viejo antes de desplegarse; mejor avanzar función por función.

Las excepciones son fáciles de ignorar y están llenas de información. Si cada vez más gente necesita la misma excepción, al rol le falta algo. Si las excepciones son todas distintas, puede que el rol tenga la forma equivocada. Y revisar la pertenencia sin revisar nunca el contenido confirma que las personas correctas están en el rol, pero no que el rol les dé el acceso correcto.

Medir la salud de los roles

Un indicador único bastante útil es la relación entre roles y personas. No hay un objetivo universal, pero un catálogo de roles que crece más rápido que la plantilla casi siempre va camino de la explosión.

Cómo se relaciona con los estándares

La base formal de casi todo esto es ANSI/INCITS 359, el estándar RBAC, que define el RBAC central, las jerarquías de roles y las restricciones estáticas y dinámicas de separación de funciones que mantienen los conflictos fuera de las definiciones de roles. El proyecto RBAC del NIST reúne la historia del modelo y su literatura sobre ingeniería de roles, incluido el modelo de Ferraiolo, Sandhu y Kuhn del que salió el estándar. Para los diseños híbridos que absorben la variación sin roles nuevos, la referencia es la NIST SP 800-162, la guía de ABAC. Los auditores suelen citar la NIST SP 800-53 Rev. 5, cuyos controles AC-2 y AC-6(7) exigen revisar los privilegios asignados a los roles, que es la revisión de contenido de la que hablamos más arriba. Y el IDPro Body of Knowledge trata la gestión y la minería de roles como disciplina profesional, un buen lugar para leer cómo lo han hecho otros programas.

Cerrando el ciclo

Este módulo empezó con la solicitud de acceso y la certificación, dos procesos que trabajan entitlement por entitlement. Los roles son lo que les permite funcionar a escala. Y son el lugar más claro del dominio donde se encuentran las personas del programa y su modelo de acceso: cada rol es un paquete en el sentido del catálogo, ajustado a un puesto, construido y mantenido por la gente que nombró el artículo 5. Mientras esas tres cosas sigan alineadas, JML, la solicitud de acceso y la certificación se simplifican. Cuando se separan, los problemas se reparten en silencio a todos los que tienen el rol.

Resumen

La ingeniería de roles es el trabajo continuo de decidir qué roles existen, qué contienen, quién los recibe y quién es su owner; RBAC es el modelo, y la ingeniería de roles es el programa que lo mantiene fiel a la realidad. Es donde se juntan los dos sentidos de “rol” de este dominio, porque cada rol es un paquete de entitlements que pretende reflejar un puesto real y lo diseñan y mantienen las personas del artículo 5. Los roles de negocio nombran puestos y pertenecen al negocio, los técnicos cubren un solo sistema y pertenecen al owner de esa aplicación, y las jerarquías se mantienen poco profundas para que nadie pierda de vista lo que un rol otorga de verdad. El diseño top-down es ordenado pero incompleto, la minería bottom-up es completa pero copia con fidelidad los errores que ya existen, y el valor sale de conciliar ambos donde no coinciden, que es justo como aparecieron los once auxiliares de Sara. La minería encuentra lo común y no lo correcto, así que cada candidato necesita un owner y una verificación de conflictos antes de convertirse en rol. Y la explosión de roles se contiene con roles amplios, atributos para la variación y revisiones de lo que contienen los roles, no solo de quién los tiene.

Tres preguntas para ponerte a prueba

1. La minería propone un rol candidato para 40 personas que incluye “crear proveedor” y “aprobar pago”. ¿Qué te dice eso de los datos y qué debería pasar con el candidato?
2. Un banco quiere roles de cajero separados para cada una de sus 30 sucursales y con tres niveles de antigüedad. ¿Por qué es un problema y cómo lo rediseñarías?
3. En un rol de negocio que se asigna solo a partir de los códigos de puesto de RR. HH., ¿por qué importa más revisar su contenido que su pertenencia?

Ejercicio práctico

Elige un equipo de al menos diez personas que conozcas bien, el tuyo o uno de operaciones imaginario.

1. Define de dos a cuatro puestos top-down, con una descripción de una línea y un owner para cada uno.
2. Anota lo que necesita cada puesto en al menos tres sistemas, agrupado en roles técnicos por sistema y roles de negocio por puesto.
3. Decide qué variantes (ubicación, antigüedad, turno) resolverías con atributos en vez de roles nuevos, y cómo.
4. Contrasta tus roles con una regla de separación de funciones y escribe el mínimo de miembros y el máximo de excepciones que debería cumplir un rol nuevo en ese equipo antes de aprobarse.