El catálogo de entitlements: inventariar y clasificar el acceso

“Acceso a finanzas”

Una jefa abre su revisión trimestral de accesos y encuentra, junto al nombre de uno de sus analistas, una entrada llamada “Acceso a finanzas”. No tiene idea de qué otorga. Podría ser lectura sobre una carpeta compartida de reportes. Podría ser la capacidad de aprobar pagos. La aprueba, como aprueba las otras cuarenta entradas de la lista, porque rechazar algo que no entiende podría dejar a su analista sin poder trabajar, y la revisión vence el viernes. Tres semanas después, durante una investigación que no tenía nada que ver, se descubre que “Acceso a finanzas” incluía la posibilidad de cambiar los datos bancarios de los proveedores.

Esa entrada, y la revisión que no pudo detectarla, es el problema del que trata este artículo. El artículo anterior construyó el gobierno alrededor de las altas, los traslados y las bajas, y habló todo el tiempo de “el paquete estándar de este puesto” y “el acceso del puesto anterior” como si esos paquetes estuvieran bien definidos. En la mayoría de las organizaciones no lo están. Nadie sabe decir con exactitud qué contienen, los nombres no significan nada fuera del sistema que los creó y la mitad de lo que contienen no tiene owner. El catálogo de entitlements es donde un programa arregla eso: qué se otorga de verdad, cómo debería llamarse y quién responde por ello.

Todo lo anterior en este módulo actúa sobre entitlements: los otorgamientos birthright, el retiro y el otorgamiento de un traslado, el retiro completo de una baja. Todo lo que viene después también depende de ellos. Las reglas de separación de funciones, las revisiones de acceso y el diseño de roles son tan confiables como el catálogo que tienen debajo.

Permiso, entitlement, rol

Pregúntale a casi cualquier organización qué acceso tiene alguien y oirás una mezcla de palabras usadas como si significaran lo mismo: permisos, entitlements, roles, derechos, accesos. IGA necesita que signifiquen cosas distintas, porque las políticas, las revisiones y la automatización dependen de saber en qué capa están trabajando.

Un permiso es la concesión técnica en bruto que aplica un sistema: SELECT sobre la tabla de facturas, un scope concreto de OAuth, una casilla en una consola de administración, la pertenencia a un grupo de Active Directory. Los permisos son lo que el sistema conoce. Rara vez significan algo para quien no forma parte del equipo que construyó el modelo de autorización del sistema.

Un entitlement es la capa de negocio construida encima de uno o varios permisos, y es la unidad que IGA gobierna de verdad. “Aprobar órdenes de compra de hasta $10.000” es un entitlement. Debajo puede haber una asignación de rol en el ERP, un permiso en el motor de flujos y una suscripción en el sistema de notificaciones: tres concesiones técnicas que una persona de negocio nunca necesita ver. Un entitlement se define para que un revisor, una jefatura o un auditor puedan leer su nombre y su descripción y formarse una opinión real sobre si una persona concreta debería tenerlo.

Un rol, en este sentido, es un paquete con nombre de varios entitlements que se asignan juntos a toda una población definida. Es el “paquete estándar” del artículo de JML, hecho explícito. Un rol existe para que dar de alta a una persona nueva o conciliar el acceso de alguien que cambia de puesto sea una sola acción gobernada en lugar de una docena de solicitudes sueltas.

flowchart BT
  accTitle: Los permisos componen entitlements, que se agrupan en roles
  accDescr: Varios permisos técnicos de sistemas distintos se combinan en un único entitlement de negocio, aprobar órdenes de compra de hasta diez mil dólares. Ese entitlement, junto con consultar datos maestros de proveedores y enviar lotes de pago, se agrupa en el rol Auxiliar de cuentas por pagar. Las revisiones y las solicitudes de acceso trabajan sobre todo en la capa de los entitlements.
  P1[Asignación de rol en el ERP<br/>permiso] --> E1[Aprobar órdenes de compra<br/>hasta $10.000<br/>entitlement]
  P2[Permiso del motor de flujos] --> E1
  P3[Suscripción a notificaciones] --> E1
  E1 --> R1[Auxiliar de cuentas por pagar<br/>rol]
  E2[Consultar datos maestros<br/>de proveedores<br/>entitlement] --> R1
  E3[Enviar lote de pagos<br/>entitlement] --> R1

La distinción importa en la práctica porque cada capa cambia por motivos distintos, a otro ritmo y bajo otro owner. Los permisos cambian cada vez que un administrador reconfigura una aplicación: a menudo, de forma técnica y casi invisible para el gobierno. Los entitlements cambian cuando cambia el significado de negocio de una función: de vez en cuando y a propósito. Los roles cambian cuando la organización redefine lo que necesita un puesto: lo menos frecuente de las tres, y el tema del artículo de ingeniería de roles, más adelante en este dominio.

Acertar con la granularidad

Con las capas claras, construir un catálogo se reduce a un juicio que se repite una y otra vez: ¿qué tan fino debe ser cada entitlement? Equivocarse en cualquiera de las dos direcciones debilita justo el gobierno que el catálogo debería sostener.

Si es demasiado fino, el catálogo solo vuelve a mostrar el modelo de permisos en bruto con una traducción delgada encima: cientos de entradas casi idénticas por aplicación, cada una una pequeña variante de la anterior. Un revisor frente a esa lista no la revisa. Hace scroll, porque nadie puede tener en la cabeza doscientos casi duplicados el tiempo suficiente para juzgar cada uno. Es el mismo cansancio que el artículo del modelo de datos describió con las identidades duplicadas: con suficiente ruido, quien revisa deja de leer y empieza a aprobar.

Si es demasiado grueso, el entitlement esconde diferencias que un revisor querría ver. Juntar “ver facturas” y “aprobar facturas” en un único “acceso a facturas” significa que quien lo revisa no puede saber si la persona solo mira facturas o también las aprueba. Esa diferencia importa muchísimo para la separación de funciones, y el catálogo acaba de borrarla. “Acceso a finanzas” es la versión extrema.

Una prueba que suele resolverlo: ¿dos personas con este entitlement podrían necesitar respuestas distintas a “¿hay que quitárselo?”? Si el acceso de una está claramente justificado y el de la otra claramente no, pero el catálogo tiene una sola entrada para las dos, es demasiado grueso. Si un revisor nunca decidiría en la práctica distinto entre dos entradas vecinas, probablemente sean un solo entitlement con dos nombres, y es demasiado fino.

Primero el descubrimiento, después la curaduría

Un catálogo no se diseña sobre una hoja en blanco. Se construye a partir de lo que ya existe, en dos pasadas que es fácil confundir y no conviene.

El descubrimiento es mecánico. Te conectas a cada sistema destino y listas sus permisos en bruto: cada grupo de AD, cada rol de base de datos, cada conjunto de permisos y scope de API de cada SaaS. Se puede automatizar casi por completo, con los mismos conectores que usa el aprovisionamiento. El descubrimiento responde qué existe técnicamente, y en cualquier organización de cierto tamaño la respuesta honesta suele asustar: miles de grupos, muchos sin uso, muchos superpuestos, muchos bautizados hace años por quien los creó de una forma que solo tenía sentido para esa persona.

La curaduría es el juicio que el descubrimiento no puede hacer. Decide cuáles de esos miles de permisos merecen convertirse en un número más chico de entitlements con nombre, con owner y con sentido de negocio, y cuáles son ruido, duplicación o acceso muerto que nadie debería gobernar porque nadie debería tenerlo. En la curaduría es donde se aplica la prueba de la granularidad, entitlement por entitlement, y es un trabajo humano, liderado por owners de aplicación que saben qué hace de verdad cada permiso y no solo cómo se llama en la consola de administración.

Un ejemplo de curaduría

El sistema de siniestros de una aseguradora regional lleva once años funcionando y tiene 340 grupos de permisos en su consola de administración, fruto de más de una década de pedidos puntuales, cada uno otorgado como un grupo propio porque era la forma más rápida de atender a una persona. Nadie en la empresa sabe explicar la mitad, y varios se diferencian entre sí en un solo carácter.

La owner de operaciones de siniestros e ingeniería de IAM los curan juntas. Empiezan por el uso: qué grupos tienen algún miembro activo. Cerca del 40% no tiene ninguno y se descarta. Las entrevistas con la owner de operaciones de siniestros muestran después que los grupos restantes corresponden a un puñado de distinciones de negocio reales: ver un siniestro, ajustar su reserva, aprobar un pago por debajo de un umbral, aprobar uno por encima y cerrar el expediente. Cinco entitlements con nombres claros, todos con la owner de operaciones de siniestros como responsable, reemplazan a 340 grupos que nadie sabía explicar. Y lo más importante: los cinco corresponden a niveles de riesgo y autoridad de verdad distintos, que los 340 grupos ocultaban en lugar de aclarar.

Un segundo caso parte de otro lugar. El CRM de una empresa SaaS en pleno crecimiento lo configuraron tres administradores a lo largo de cuatro años, sin hablar entre ellos, y quedaron 28 conjuntos de permisos personalizados con nombres como “Acceso Equipo A” y “Permisos Ventas Nuevos”. El uso muestra que los 28 están asignados a alguien, así que no hay peso muerto que quitar. Pero se reducen a cuatro distinciones reales: ver datos del pipeline, editar tus propias oportunidades, editar las de cualquier compañero y exportar datos de contactos. El catálogo curado queda más chico que la lista en bruto no porque sobrara acceso, sino porque las mismas cuatro capacidades se habían reinventado con nombres distintos por personas que nunca compararon notas. La cuarta, exportar datos de contactos, resulta además ser el único entitlement que necesita un nivel de riesgo más alto y un grupo de titulares más reducido, algo que nadie podía ver mientras estaba repartido en seis conjuntos de permisos con nombres distintos.

Por dónde empezar a curar

Ningún programa cura de una vez todos los permisos de todos los sistemas, e intentarlo es una buena forma de quedarse un año parado. Un orden sensato pone primero los sistemas de más riesgo: los que entran en el alcance de regulaciones como SOX o PCI DSS, los que guardan datos de clientes o pacientes y los que tienen autoridad financiera. Dentro de cada sistema, los permisos que tiene más gente van antes que la cola larga, porque afectan a más revisiones y a más solicitudes.

Una regla práctica útil es que una fracción pequeña de los permisos suele concentrar la mayoría de las asignaciones. Curar primero esa fracción les da a los revisores entitlements legibles para casi todo lo que ven, mientras la cola larga espera, marcada como sin curar, una pasada posterior. Etiquetar con honestidad lo que todavía no se ha curado, en lugar de dejar que pase por entitlement, evita que los revisores supongan que se ha limpiado más de lo que en realidad se limpió.

Qué registra cada entitlement

Una entrada del catálogo es más que un nombre. Un catálogo que solo guarda nombres obliga a cada proceso posterior a redescubrir todo lo demás, así que la mayoría de los catálogos maduros terminan con un conjunto común de campos para cada entitlement.

Está la correspondencia técnica: qué permisos de qué sistema representa el entitlement, mantenida al día a medida que cambia el sistema. Está el nombre estructurado y el nombre visible en lenguaje claro, con una breve descripción de lo que permite y de quién suele necesitarlo. Está el owner y un owner suplente. Está el nivel de riesgo y su motivo, y las poblaciones que pueden tenerlo. Está si se puede solicitar o solo se asigna mediante un rol o una política. Está la frecuencia de revisión que implica su nivel. Están las etiquetas a las que pueden referirse las reglas de separación de funciones, como “crea proveedores” o “aprueba pagos”, para escribir las reglas de conflicto una sola vez contra etiquetas y no contra cada entitlement suelto. Y está su estado en el ciclo de vida.

Tener estos campos en el catálogo, y no repartidos entre hojas de cálculo y la memoria de los owners de aplicación, es lo que permite que una solicitud de acceso, una revisión y una verificación de conflictos lean la misma respuesta. No todos los campos tienen que estar completos el primer día. El owner, el nivel de riesgo y la descripción son de los que más dependen las revisiones y las solicitudes, así que van primero; el resto puede ir llegando a medida que el catálogo madura.

Un entitlement también tiene ciclo de vida

Tratar la curaduría como un proyecto de una sola vez pasa por alto que los entitlements envejecen, igual que el acceso de cada persona. Un catálogo necesita unos pocos estados definidos y un proceso para mover los entitlements entre ellos, o se convierte en el tipo de artefacto viejo del que advertía el artículo de JML con los paquetes birthright: correcto el día en que se construyó y equivocado sin que nadie lo note dos reorganizaciones después.

stateDiagram-v2
    accTitle: El ciclo de vida de un entitlement en el catálogo
    accDescr: Un entitlement propuesto pasa a activo cuando tiene owner, nivel de riesgo y nombre definitivo, y desde ese momento puede asignarse a personas. Un entitlement activo puede revisarse, cambiando su nombre o su definición sin perder su identidad, o volverse obsoleto cuando un cambio de sistema o una reorganización lo dejan inexacto. Un entitlement obsoleto ve sus asignaciones trasladadas o retiradas y después se retira, y queda en el catálogo como registro pero ya no se puede asignar.
    [*] --> Propuesto: El descubrimiento y la curaduría encuentran un candidato
    Propuesto --> Activo: Owner asignado, nivel de riesgo, nombre definitivo
    Activo --> Activo: Revisado
    Activo --> Obsoleto: Ya no es exacto
    Obsoleto --> Retirado: Asignaciones trasladadas o retiradas
    Retirado --> [*]

El estado que más catálogos se saltan es “obsoleto” como paso propio y registrado, en lugar de un abandono silencioso. Una aplicación cambia su modelo de permisos, y un entitlement que antes correspondía limpiamente a él ahora describe algo un poco distinto, o nada. Sin un paso de obsolescencia, el entitlement sigue existiendo, se sigue asignando a las personas nuevas a través del rol que lo incluye y sigue apareciendo en revisiones que la gente aprueba porque el nombre todavía suena razonable. Marcarlo como obsoleto obliga a hacerse la pregunta: ¿esto sigue describiendo algo real y, si no, adónde tiene que pasar todo el que lo tiene?

Una forma de nombrar que sobreviva a una docena de sistemas

Un catálogo que abarca decenas de aplicaciones falla en silencio si cada aplicación nombra sus entitlements a su manera. “AP_Approve_10K”, “Invoice-Approval-Tier2” y “FinanceApprover3” pueden describir la misma autoridad, y sin un patrón coherente nadie, ni un revisor ni un auditor ni una búsqueda, puede darse cuenta.

Un patrón al que llegan casi todos los catálogos maduros es Sistema.Función.Nivel: la aplicación, la función de negocio y, cuando hace falta, un nivel o umbral que lo distingue de sus vecinos en la misma función. Aplicado de forma coherente, ERP.PurchaseOrderApproval.Under10K y ERP.PurchaseOrderApproval.Over10K quedan uno al lado del otro en cualquier lista ordenada, visiblemente relacionados y visiblemente distintos, algo que “AP_Approve_10K” y “AP_Approve_Senior” nunca lograrían.

Los nombres no cambian lo que otorga ninguno de estos. Cambian si alguien que mira el catálogo puede saber, sin abrir cuatro consolas de administración, que las dos primeras filas son dos niveles de la misma autoridad y que las dos últimas pertenecen a una función completamente distinta. Esa legibilidad es lo que hace que un catálogo sirva en una revisión y no sea solo completo.

El nombre técnico no es el único que importa. Quienes solicitan acceso necesitan un nombre visible en lenguaje claro y una descripción de una frase (“Aprobar órdenes de compra de hasta $10.000; suele necesitarlo la supervisión de cuentas por pagar”), y el artículo de solicitud de acceso explica cómo esa capa de presentación influye en lo que la gente pide. El nombre estructurado sirve a revisores y auditores; el nombre visible, a todos los demás. Un buen catálogo guarda los dos.

Cada entitlement necesita un owner

Cada entitlement del catálogo necesita un owner con nombre, normalmente el owner de la aplicación o del negocio que responde por ese sistema o esa función. La razón es la misma que dio el artículo del modelo de datos para que cada cuenta tenga una identidad dueña: un entitlement sin owner no tiene a nadie que pueda decir si una persona debe tenerlo, y por qué, con contexto de negocio real. Se acumula igual que una cuenta huérfana. Nadie nota cuando está mal, porque notarlo no es problema de nadie.

Ser owner no es una etiqueta que se pone una vez. Es una responsabilidad continua con dos trabajos concretos. El owner es quien aprueba cuando alguien solicita el entitlement, la persona a la que lo envía el flujo. Y es a quien una campaña de revisión le pide confirmar que las asignaciones del entitlement siguen siendo correctas, y quien debería revisar de vez en cuando el entitlement mismo: si sigue describiendo algo real, si el umbral de Over10K sigue coincidiendo con la política de aprobación vigente, si habría que dividirlo, fusionarlo o retirarlo.

La titularidad también necesita un sucesor, algo fácil de olvidar hasta que el owner se va. Un entitlement cuyo único owner acaba de pasar por su propia baja vuelve a quedarse sin owner hasta que alguien lo reasigna a propósito. El catálogo debería formar parte de lo que revisa la jefatura de quien se va o el traspaso de RR. HH., junto con la tarea más conocida de transferir sus reportes y su trabajo pendiente.

Clasificar los entitlements por riesgo

No todos los entitlements merecen el mismo escrutinio, y un catálogo que los trata a todos igual gasta esfuerzo en la mayoría de bajo riesgo mientras revisa poco los pocos que importan. Un número chico de niveles de riesgo, fijado para cada entitlement durante la curaduría, permite que el resto del programa, el enrutamiento de aprobaciones, la frecuencia de revisión, la política de separación de funciones, trate los entitlements de forma distinta sin discutir el riesgo cada vez.

El artículo de JML habló de dimensionar las aprobaciones y los plazos de escalamiento según el riesgo; esto es lo que daba por hecho. Un nivel no puede guiar un flujo de aprobación ni una frecuencia de revisión hasta que cada entitlement tenga uno asignado de forma explícita, y esa es una decisión de la curaduría, no algo que un motor de flujos pueda deducir solo.

El nivel merece un motivo por escrito, no solo una etiqueta, porque dos entitlements que se parecen pueden terminar en niveles distintos por razones que un revisor futuro necesitará entender. Aprobar órdenes de compra de hasta $10.000 y de hasta $500 son las dos aprobación de órdenes de compra, pero el umbral por sí solo puede poner una en “elevado” y dejar la otra en “estándar”. Ese razonamiento va en la definición del entitlement, no en la memoria de quien fijó los niveles.

El catálogo cubre más que a los empleados

El artículo del modelo de datos separó a los empleados, que vienen de RR. HH., de los contratistas, proveedores y cuentas de servicio, que vienen de otras fuentes. El catálogo tiene que reflejar esa separación, porque lo que alguien puede tener no es lo mismo en esos grupos aunque el entitlement sea técnicamente idéntico.

Una cuenta de servicio casi nunca debería poder tener nada por encima de “estándar” sin una excepción explícita y documentada. Una identidad no humana con acceso privilegiado y sin revisar aparece con muchísima frecuencia en los análisis posteriores a una brecha, justamente porque nadie le dedica el escrutinio que recibe por defecto una identidad humana. Los contratistas suelen poder tener menos que los empleados por política, no solo por su trabajo: algunas organizaciones excluyen a quienes no son empleados de todo entitlement “privilegiado / crítico”, sea cual sea su tarea, porque un contrato más corto e incierto hace más difícil sostener la responsabilidad en el tiempo.

La consecuencia práctica es registrar la elegibilidad como atributo de cada entitlement: cuáles de las poblaciones de empleados, contratistas y cuentas de servicio pueden tenerlo. Si no, se descubre la primera vez que un contratista recibe algo que nadie quería abrir a quienes no son empleados. Vale la pena nombrar a los usuarios de socios que entran por federación como cuarta población, para que su exclusión sea deliberada. Como esta organización nunca fue la autoridad sobre quiénes son, en general no debería asignarles sus propios entitlements mediante el mismo catálogo que gobierna a los empleados; su acceso se modela mejor como una integración acotada y hecha a medida.

El acceso que no vive en ningún sistema conectado

El descubrimiento encuentra lo que ven los conectores. Hay accesos que nunca aparecen ahí, y un catálogo que los ignora da una falsa sensación de completitud.

Las credenciales compartidas son el caso clásico: el usuario del portal de un proveedor que conocen cinco personas de compras, la contraseña de una cuenta de redes sociales guardada en una bóveda del equipo, el token de la banca empresarial que tienen dos personas de tesorería. El acceso delegado es otro: alguien con acceso completo al correo y al calendario de su jefatura, otorgado hace años y nunca revisado. También lo son las hojas de cálculo y los scripts con credenciales de base de datos incrustadas, que le dan a cualquiera que pueda abrir el archivo una entrada silenciosa a un sistema que el catálogo cree bien controlado.

No todo esto tiene que volverse un entitlement formal el primer día. Pero al menos debería estar inventariado, tener owner y estar marcado como fuera del aprovisionamiento automático, para que las revisiones y los procesos de baja sepan que tienen que preguntar por ello. Un catálogo honesto dice qué acceso cubre y cuál no.

Cómo fallan los esfuerzos de catálogo

Algunos patrones se repiten lo suficiente como para nombrarlos, porque cada uno produce un catálogo que parece completo sin ser gobernable.

El primero es clonar en lugar de curar. Con la presión de una fecha, alguien toma la estructura de grupos de un sistema, le cambia los nombres y la llama catálogo, saltándose el trabajo de contrastar cada grupo con el uso y con su significado de negocio. El resultado es tan inflado e inmantenible como la lista en bruto que debía reemplazar, con nombres más amables.

El segundo es la explosión de roles disfrazada de exhaustividad. Modelar una combinación ligeramente distinta para cada variante de cómo se hace un trabajo, un rol de auxiliar sénior de CxP para la región este, otro para la oeste, otro para quienes trabajan en remoto, produce cientos de roles casi idénticos que nadie sabe distinguir ni revisar con sentido. Es el problema de la explosión de roles que trata el artículo de ingeniería de roles, y empieza aquí, en el diseño del catálogo, cuando se afloja la disciplina de la granularidad.

El tercero es tratar el catálogo como un entregable de una sola vez. Un catálogo que se construye, se presenta a un comité y no se vuelve a mirar se degrada tan rápido como un paquete birthright sin revisar. Llegan aplicaciones nuevas cuyos entitlements nunca entran al catálogo, las existentes cambian su modelo de permisos sin que el catálogo cambie, y en dieciocho meses describe un entorno que ya no existe. Alguien tiene que responder por mantener al día el catálogo mismo, aparte de los owners de cada entitlement. La mayoría de los programas maduros le dan ese trabajo al mismo foro de gobierno que lleva la política de separación de funciones y el diseño de las revisiones.

Lo que el resto del dominio construye encima

Dos capacidades que vienen más adelante en este dominio dependen de que el catálogo exista justo en la capa de los entitlements.

La política de separación de funciones tiene que nombrar los entitlements que entran en conflicto, como “aprobar órdenes de compra” y “crear proveedores”, y esa política solo significa algo si esos nombres remiten a entitlements estables, bien definidos y del tamaño adecuado. Escrita contra permisos en bruto, una regla de SoD tendría que enumerar cada variante técnica de cada sistema y se rompería la primera vez que una aplicación cambiara su modelo. Escrita solo contra roles, puede pasar por alto un conflicto real dentro de un único rol: dos entitlements metidos en un rol que nunca debieron juntarse, invisibles para una verificación que solo compara nombres de roles.

La certificación de accesos es tan buena como lo que ve quien revisa, y lo que ve son entitlements. Por eso el trabajo de granularidad y de nombres de este artículo decide si una revisión tiene sentido o es un trámite de clics. El artículo del modelo de datos describió cómo las revisiones se rompen en silencio con identidades duplicadas; se rompen igual de en silencio con un catálogo mal diseñado, donde un revisor aprueba algo que no puede interpretar, no por descuido, sino porque el catálogo le dio “Acceso a finanzas”.

Medir si el catálogo está sano

Las medidas que vale la pena mirar aquí tratan del catálogo como artefacto, aparte de las medidas de los procesos que lo usan.

La proporción de entitlements con un owner con nombre y confirmado dice cuánto del catálogo tiene detrás una responsabilidad real; un entitlement sin owner no está gobernado por bien que esté nombrado. La proporción de entitlements revisados dentro de la frecuencia de su nivel dice si la revisión por riesgo ocurre de verdad o solo está definida; un entitlement privilegiado que nadie miró en dos años es un hallazgo esperando a que alguien lo encuentre. El número medio de permisos por entitlement es una señal aproximada de la granularidad; una cifra que no deja de subir sugiere que los entitlements van absorbiendo permisos nuevos sin que nadie se pregunte si siguen yendo juntos. Y el número de entitlements obsoletos que siguen asignados a personas dice si la obsolescencia está provocando algún cambio o solo cambiando etiquetas.

Ninguna de estas cifras dice mucho en una sola lectura. La señal es la tendencia. Un catálogo en el que crece la titularidad y bajan los obsoletos asignados es un catálogo que el programa mantiene; lo contrario, incluso desde un buen punto de partida, es un catálogo que vuelve poco a poco al desorden sin gestionar que vino a reemplazar. Una foto trimestral de estas cuatro, reportada junto con las medidas de JML y de calidad de datos de este módulo, le da a un comité una visión honesta de si la base se sostiene.

Cómo se relaciona con los estándares

Las capas de permiso, entitlement y rol no son una invención de la casa. Recogen un trabajo en el que la industria ya ha convergido:

• ANSI/INCITS 359, el estándar RBAC, formalizó hace décadas el control de acceso basado en roles como una capa entre usuarios y permisos. La composición de permisos en roles descrita aquí viene de ese modelo, aunque la mayoría de los catálogos reales añaden la capa de los entitlements en medio para que los roles no se vuelvan inmanejablemente finos.
• El IDPro Body of Knowledge trata la curaduría de entitlements, la titularidad y los nombres como disciplina profesional.
• SCIM (RFC 7643), presentado en el artículo del modelo de datos para los atributos de identidad, también define un esquema para grupos y objetos parecidos a entitlements, útil para los programas que aprovisionan asignaciones de entitlements por SCIM en lugar de con conectores propietarios.

Cerrando el ciclo que viene construyendo este módulo

El primer artículo describió IGA como un ciclo: la administración aprovisiona y retira, el gobierno decide y verifica. Cada artículo desde entonces construyó una parte de lo que el gobierno necesita para hacer su mitad en la práctica. Una fuente autoritativa y el emparejamiento para saber quién (artículo 2). Un ciclo de vida reconciliado y auditable para saber cuándo cambia el acceso y si cambió de verdad (artículo 3). Y ahora, un catálogo curado, con owners y niveles de riesgo, para saber qué se otorga, se retira, se revisa y se contrasta con los conflictos. Ninguna de las actividades de gobierno de este dominio tiene sobre qué trabajar sin él. Es la capa menos visible de un programa de IGA, y la que todo lo demás da por buena.

Resumen

• Un permiso es la concesión en bruto que aplica un sistema; un entitlement es la unidad de negocio construida sobre uno o varios permisos; un rol agrupa entitlements para una población. El gobierno trabaja sobre todo en la capa de los entitlements.
• El problema central del diseño es la granularidad: demasiado fino entierra a los revisores en ruido; demasiado grueso esconde diferencias que importan, sobre todo para la separación de funciones.
• Los entitlements salen del descubrimiento, que lista los permisos en bruto de forma mecánica, seguido de la curaduría, una pasada humana que nombra, agrupa, asigna owners y descarta el peso muerto.
• Cura primero los sistemas de más riesgo y los permisos que más gente tiene, y etiqueta con honestidad lo que queda sin curar.
• Cada entitlement registra más que un nombre: correspondencia técnica, descripción, owner, nivel de riesgo, elegibilidad, si se puede solicitar, frecuencia de revisión, etiquetas de SoD y estado.
• Los entitlements tienen ciclo de vida, y “obsoleto” tiene que ser un paso real y registrado.
• Una convención de nombres coherente, como Sistema.Función.Nivel, junto con un nombre visible en lenguaje claro, vuelve legible el catálogo a lo largo de decenas de sistemas.
• Cada entitlement necesita un owner con nombre que apruebe las solicitudes y confirme las revisiones, y un sucesor cuando ese owner se va.
• Los niveles de riesgo, fijados en la curaduría con un motivo por escrito, permiten que las aprobaciones, las revisiones y la política de SoD traten distinto a los entitlements. La elegibilidad por población va en cada entitlement.
• Inventaría y asigna owner al acceso que ningún conector ve, como las credenciales compartidas y los buzones delegados, aunque todavía no sea un entitlement formal.

Tres preguntas para ponerte a prueba

1. Una revisión le muestra a una jefa un entitlement llamado “Acceso a finanzas”. ¿Qué tiene de malo desde el punto de vista de la granularidad y cómo sería un diseño mejor?
2. ¿Por qué este artículo sostiene que la política de separación de funciones debe escribirse contra entitlements y no contra roles? Describe una situación en la que una verificación a nivel de rol pasaría por alto un conflicto real.
3. Un sistema heredado tiene 200 grupos de permisos y ningún owner documentado. Con el proceso de curaduría de este artículo, describe los tres primeros pasos que darías antes de proponer un solo nombre de entitlement nuevo.

Ejercicio práctico

Elige una aplicación que uses a menudo y de la que puedas ver algunos permisos, o imagina una con detalle.

1. Enumera todos los permisos o grupos que conozcas de ella, aunque sea de forma aproximada.
2. Agrúpalos en entre tres y seis entitlements con la prueba de granularidad de este artículo, y nombra cada uno con el patrón Sistema.Función.Nivel y un nombre visible en lenguaje claro.
3. Asigna a cada entitlement un nivel de riesgo con un motivo de una línea, y decide qué poblaciones (empleados, contratistas, cuentas de servicio) pueden tenerlo.
4. Nombra quién debería ser owner de cada entitlement y quién lo reemplazaría si esa persona se fuera.