Políticas de IGA y acceso por nacimiento (birthright): reglas que otorgan acceso sin solicitud

El lunes que nadie tuvo que aprobar

Un lunes por la mañana, David empieza como enfermero en el área de cardiología de un hospital privado. Antes de terminar el café de la inducción ya puede entrar en la estación de trabajo clínica, abrir el expediente electrónico de los pacientes de su unidad, leer los procedimientos compartidos del área, ver su horario y mandar correos. Nadie pidió nada de eso. Ningún jefe lo aprobó. Ocurrió porque el sistema de RR. HH. registró que ese día empezaba una persona con el código de puesto de enfermería, asignada a cardiología, y la plataforma de IGA tenía reglas que convertían esos datos en acceso.

Esas reglas son políticas, y de ellas trata este artículo. Los anteriores de este módulo cubrieron el acceso que la gente pide (solicitud de acceso), la revisión del acceso que ya tiene (certificación) y los paquetes en los que llega (ingeniería de roles). Las políticas son la parte que funciona sin que nadie pida nada. Deciden quién recibe qué roles de forma automática, qué combinaciones de acceso no se permiten nunca y qué pasa cuando cambian los datos de una persona.

También son el lugar donde los errores de un programa salen caros más rápido. Una mala aprobación afecta a una persona. Una mala regla afecta a todos los que coinciden con ella, a la velocidad de la siguiente sincronización con RR. HH.

Tres tipos de política

Los productos de IGA usan la palabra “política” para muchas cosas, pero lo importante cae casi siempre en tres grupos.

Las políticas de asignación otorgan acceso cuando los atributos cumplen una condición. “Todo el que tenga tipo de contratación empleado recibe el rol base de la plantilla.” “Todo el que esté en el área 4410 recibe el rol de Auxiliar de CxP.” “Toda enfermera asignada a una unidad recibe lectura de los expedientes de esa unidad.” Son las reglas detrás del lunes de David.

Las políticas de separación de funciones dicen lo que nadie debe tener al mismo tiempo: crear un proveedor y aprobar su pago, recetar un medicamento controlado y dispensarlo, escribir código y aprobar su paso a producción. No otorgan nada. Ponen límites a todo lo demás.

Las políticas de ciclo de vida deciden cuándo termina un acceso o cuándo hay que volver a mirarlo: el acceso de un contratista termina con su contrato, las cuentas sin uso durante 90 días se deshabilitan, los entitlements privilegiados vencen tras un plazo fijo. El artículo de JML trató los eventos; las políticas de ciclo de vida son las reglas permanentes que esos eventos disparan.

Las tres se cruzan todo el tiempo. Una regla de asignación otorga un rol, una regla de separación de funciones comprueba si ese rol choca con algo que la persona ya tiene y una regla de ciclo de vida decide cuándo desaparece. Casi toda la dificultad del diseño de políticas sale de esos cruces, así que el artículo les dedica más espacio que a cualquier regla suelta.

Las reglas de asignación funcionan con atributos, y los atributos valen lo que vale su fuente

Una regla de asignación es una condición sobre atributos de identidad y un resultado. En la mayoría de las plataformas se parece a esto:

CUANDO tipo_contratacion = "empleado"
   Y   area              = "Cuentas por pagar"
   Y   codigo_puesto     EN ("4410", "4411")
ENTONCES asignar rol de negocio "Auxiliar de CxP"

La lógica casi nunca es lo difícil. Lo difícil es que la regla es exactamente tan confiable como los atributos que lee. El artículo del modelo de datos de identidad dedicó mucho espacio a las fuentes autoritativas y la calidad de los datos, y aquí es donde ese trabajo rinde o no. Si RR. HH. escribe los nombres de las áreas a mano y “Cuentas por pagar” a veces aparece como “Ctas. por pagar” o “CxP”, la regla se salta a esas personas sin avisar. Si los códigos de puesto se reutilizan para trabajos distintos en distintos países, la regla le da el rol equivocado a alguien de un país que nadie probó. Si el campo de ubicación solo se actualiza cuando alguien se acuerda, una enfermera que pasó a oncología sigue leyendo expedientes de cardiología durante meses.

Unos pocos hábitos hacen las reglas mucho más firmes. Escribirlas contra valores codificados, como códigos de puesto e identificadores de área, y no contra nombres en texto libre. Acordar con RR. HH. qué campos son lo bastante confiables para mover acceso y tratar los demás como meramente informativos. Y vigilar el caso vacío: una regla que filtra por área no coincide con nadie que tenga el área en blanco, que a menudo son justo los registros que más atención necesitan.

flowchart TD
  accTitle: De los atributos de RR. HH. al acceso aprovisionado mediante políticas
  accDescr: El sistema de RR. HH. entrega atributos como el tipo de contratación, el área, el código de puesto y la ubicación. Las reglas de asignación evalúan esos atributos y deciden qué roles debería tener la persona. Antes de aprovisionar nada, la política de separación de funciones revisa la combinación resultante contra lo que la persona ya tiene. Si no hay conflicto, el acceso pasa al aprovisionamiento. Si lo hay, el otorgamiento queda retenido y se envía al owner de la política para que decida sobre una excepción.
  HR[Atributos de RR. HH.<br/>tipo de contratación, área,<br/>código de puesto, ubicación] --> AR[Reglas de asignación]
  AR --> R[Roles que debería<br/>tener la persona]
  R --> SOD{Verificación de SoD<br/>contra el acceso actual}
  SOD -->|Sin conflicto| PROV[Aprovisionamiento]
  SOD -->|Conflicto| EX[Retenido para decisión<br/>de excepción del owner]

Birthright: qué tan chico es suficientemente chico

El acceso por nacimiento es el que recibe una persona por el solo hecho de pertenecer a una población: todo empleado, todo contratista, toda enfermera. Es la capa más baja de las políticas de asignación, y tienta hacerla grande. Un paquete birthright generoso significa menos solicitudes, gente nueva más contenta y una mesa de servicio más tranquila la primera semana.

También significa que todos en esa población tienen ese acceso lo necesiten o no, mientras sigan en la población. El acceso birthright casi nunca se certifica elemento por elemento (el artículo de certificación recomendaba excluirlo, con razón), así que lo que cae ahí queda gobernado únicamente por la regla. Un birthright demasiado generoso es acumulación de privilegios incorporada en el diseño.

Una prueba que funciona bien: ¿cada una de las personas que cubre esta regla usaría este acceso durante su primer mes? El correo y la intranet la pasan para todos los empleados. La herramienta de gastos probablemente también. El data warehouse de finanzas no, aunque la mitad de la empresa termine teniendo acceso; eso va en un rol asignado por una regla más estrecha o detrás de una solicitud.

En la práctica, el birthright suele venir por capas. Una capa fina a nivel de toda la organización cubre a todos los de un tipo de contratación. Una capa de área o de unidad suma lo que necesita todo ese grupo. A partir de ahí toman el relevo las reglas por rol y las solicitudes. El lunes de David lo muestra bien. La capa del hospital le dio correo, intranet y autoservicio de RR. HH. La capa de enfermería le dio la estación clínica y el expediente electrónico con perfil de enfermería. La capa de unidad limitó su acceso a expedientes a cardiología. Cada capa pasa la prueba de “todos en este grupo, desde el primer mes” para su propia población.

Poblaciones distintas, birthright distinto

Los contratistas y proveedores necesitan su propio birthright, que sale del sistema de gestión de proveedores y no de RR. HH., y debería ser más delgado que el de un empleado. Muchas organizaciones no les dan correo por defecto y solo les abren los sistemas concretos que cubre su contrato. Los becarios y el personal de temporada también merecen una mirada aparte, porque un birthright pensado para personal permanente suele incluir accesos de larga duración que tienen poco sentido para una estancia de tres meses.

Las cuentas de servicio y demás identidades no humanas no deberían tener ningún birthright. No pertenecen a una población en el sentido de RR. HH., y cada acceso que tengan debería poder rastrearse hasta una integración concreta y un owner.

Cuando cambian los atributos: la política en un evento de mover

Las reglas de asignación no se evalúan una vez al contratar a alguien y luego se olvidan. Vuelven a correr cada vez que RR. HH. envía un cambio, y un evento de mover es simplemente el momento en que los atributos de una persona dejan de coincidir con un conjunto de reglas y empiezan a coincidir con otro.

Pensemos en una enfermera que pasa de cardiología a oncología. La regla de la unidad de cardiología ya no coincide, así que ese acceso debería irse. La de oncología ahora sí coincide, así que ese acceso debería llegar. La pregunta que parece trivial y no lo es: ¿en qué orden y con qué rapidez?

Quitar primero y otorgar después es lo seguro siempre que el acceso viejo y el nuevo puedan formar un conflicto. El artículo de JML recorrió justo ese caso con el paso de Sara a revisión de fraude, donde tener las dos mitades aunque fuera un día habría abierto una ventana para el abuso. Otorgar primero y quitar después es más amable con quien cambia de puesto, que de lo contrario podría pasar un turno sin acceso para hacer ninguno de los dos trabajos. Muchos programas terminan con un ajuste por regla: en un hospital, el acceso de unidad se mueve con un solapamiento corto, a menudo hasta el final del turno en curso, porque la atención de pacientes no puede esperar a un ciclo de sincronización; los roles de finanzas que tocan pagos quitan primero, siempre.

Sea cual sea el orden, el solapamiento debería ser corto y deliberado. Un “periodo de gracia” de 30 días para el acceso anterior después de un traslado es habitual, casi siempre justificado como tiempo de traspaso, y es una de las principales formas en que el acceso de un mover se queda mucho más de lo que nadie pretendía. Si de verdad hace falta un traspaso, debería ser una excepción acotada, con fecha de fin y visible en el acceso de la persona, no un valor por defecto que se aplica en silencio a todos los movers.

Hay que distinguir el acceso que da una regla del que se solicitó

El acceso de una persona llega por puertas distintas: una parte por reglas de asignación, otra por solicitudes aprobadas y otra por roles asignados a mano antes de que existiera el programa. La lógica de políticas necesita saber cuál es cuál, porque de eso depende el retiro.

Si una regla otorgó el acceso a los expedientes de oncología, la regla debería quitarlo cuando la persona deje de coincidir. Si esa misma persona también solicitó acceso a un conjunto de datos de investigación oncológica, aprobado por su owner para un estudio concreto, la regla de unidad no tiene por qué quitarlo cuando la persona se traslade; ese acceso tiene su propia justificación y su propia fecha de fin. Las plataformas lo resuelven registrando el origen de cada asignación. Lo que vino de una regla “pertenece” a la regla y la sigue. Lo que vino de una solicitud pertenece a esa solicitud y sigue su fecha de fin y su certificación.

El fallo habitual es una plataforma, o una migración, que pierde el origen. Toda asignación pasa a ser simplemente “asignada”, sin registro de por qué, y el programa ya no puede dejar que las reglas limpien lo suyo sin arriesgarse a quitar acceso que se pidió legítimamente. Al migrar a una plataforma de IGA nueva, conservar o reconstruir el origen de las asignaciones existentes merece más esfuerzo del que suele recibir.

Casos raros que vale la pena probar antes de salir a producción

La mayoría de las reglas funcionan para el empleado típico y se rompen en los casos que nadie pensó. Una lista corta cubre casi todas las sorpresas.

Las recontrataciones vuelven con un expediente nuevo en algunos sistemas de RR. HH. y con el antiguo en otros. Si se reactiva el antiguo, las reglas pueden devolverle el acceso de un puesto que tuvo hace años; si se crea uno nuevo, la correlación puede fallar y dejar a la persona con dos identidades. Las licencias (por maternidad o paternidad, médicas, sabáticas) casi nunca son bajas definitivas, pero tampoco deberían dejar todo el acceso activo durante seis meses. Muchos programas suspenden todo salvo el autoservicio de RR. HH. y el correo durante una licencia larga y lo restituyen a la vuelta.

Las personas con dos relaciones con la organización desconciertan a reglas pensadas para una sola: alguien en plantilla que además cubre turnos de fin de semana a través de una agencia, o un contratista que pasa a la plantilla y durante unos días tiene los dos registros. Y los cambios de nombre, que no deberían cambiar nada del acceso, a veces provocan que un conector que empareja cuentas por nombre borre una cuenta y cree otra. Cada uno de estos casos merece una identidad de prueba en el entorno de simulación antes de activar las reglas.

La separación de funciones como objeto de política

El artículo del catálogo de entitlements sostuvo que las reglas de separación de funciones deben escribirse contra entitlements, no contra permisos en bruto ni solo contra roles, y el artículo de solicitud de acceso mostró uno de los lugares donde se verifican. Para que la separación de funciones funcione en todo el programa, cada regla tiene que tratarse como un objeto propio, con bastante más que un par de nombres de entitlement.

Una regla de SoD útil registra qué entitlements entran en conflicto (dos o más, a veces de sistemas distintos), cuál es el riesgo en lenguaje claro, qué tan grave es, quién es su owner y qué excepciones se permiten y en qué condiciones. El owner suele ser el responsable del proceso de negocio, la persona capaz de explicar por qué “crear proveedor” y “aprobar pago” no deben ir juntos y de aprobar una excepción con un control compensatorio cuando el negocio no tiene alternativa.

La ventaja de tratarla como objeto es que la misma regla se verifica en todos los lugares donde el acceso puede cambiar. Corre cuando alguien solicita un acceso, cuando una regla de asignación está a punto de otorgar un rol, cuando un evento de mover combina el acceso viejo y el nuevo, cuando alguien edita el contenido de un rol y, una vez más, en la certificación como respaldo. Un conflicto que se cuela por una puerta queda atrapado en otra. El próximo módulo trata la separación de funciones a fondo, incluida la matriz de conflictos y el diseño de controles compensatorios; aquí solo interesa cómo encaja junto a las demás políticas.

Cuando dos políticas no están de acuerdo

En cuanto hay decenas de reglas de asignación, unas cuantas de separación de funciones y algunas de ciclo de vida, se van a contradecir. Una regla de área otorga aprobación de pagos a todo tesorería. Una regla de SoD prohíbe la aprobación de pagos a quien pueda editar proveedores. Un analista de tesorería además tiene permisos de datos maestros de proveedores por un proyecto del año pasado. ¿Qué regla gana?

La respuesta tiene que decidirse de antemano y quedar escrita, porque una plataforma con sus valores por defecto resolverá el conflicto de algún modo, a menudo por el orden de las reglas o por la última que evaluó, y después nadie sabrá explicar el resultado. La convención que adopta la mayoría de los programas es sencilla: una prohibición gana a un otorgamiento. Si una regla de asignación crearía un conflicto de SoD, el otorgamiento se retiene en lugar de aplicarse y pasa al owner de la regla para que decida. Solo una excepción explícita y aprobada, con fecha de vencimiento, se impone a una prohibición.

Hay otros dos choques frecuentes. Dos reglas de asignación pueden otorgar accesos que se superponen, algo casi siempre inofensivo pero que deja poco claro qué regla hay que cambiar cuando ese acceso debe desaparecer; un rol que llega por dos reglas no se retira cuando solo una de ellas deja de coincidir. Y una regla de ciclo de vida puede pelearse con una de asignación: la regla de inactividad de 90 días deshabilita una cuenta, la siguiente sincronización con RR. HH. ve que la persona sigue coincidiendo con la regla de su área y la cuenta se vuelve a habilitar. Cada uno de estos casos necesita una solución documentada, y el foro de gobierno del artículo de roles del programa es el lugar natural para acordarla.

Simular antes de activar

Cada cambio de política toca a todos los que coinciden con ella, que es justamente su gracia y también su principal peligro. Cambiar la condición de una regla de área de codigo_puesto EN ("4410","4411") a codigo_puesto = "4410" parece una limpieza menor. Si 600 personas tienen el código 4411, les quita un rol a 600 personas en la siguiente sincronización.

La mayoría de las plataformas de IGA pueden correr una simulación, a veces llamada análisis de impacto o what-if, que evalúa la regla modificada contra los datos de identidad actuales sin aplicar nada. El resultado es la lista que importa: quién ganaría qué acceso, quién perdería cuál y qué conflictos de SoD nuevos aparecerían. Revisar esa lista antes de activar el cambio atrapa los errores que no se ven en la regla misma, como una errata en un código, un área que cambió de nombre el mes pasado o una población que nadie recordaba que la regla cubría.

Una rutina razonable trata cada cambio de regla como una pequeña entrega. Se escribe el cambio con su intención (“dar a todas las enfermeras de cardiología acceso al nuevo panel de telemetría”). Se corre una simulación con datos de producción. El owner de la regla revisa las altas y bajas simuladas, y se investiga a cualquier persona afectada que esté fuera de la población prevista. Los cambios grandes pasan por el foro de gobierno. Y el cambio se activa a una hora conocida, mejor no un viernes a las cinco de la tarde, con alguien mirando la primera sincronización.

Conviene pensar también en la marcha atrás antes de activar. Si un cambio de regla quita acceso que no debía, restaurar la versión anterior de la regla debería devolver ese acceso en la siguiente sincronización. Eso solo funciona si las reglas tienen versiones y se conserva la anterior, algo que vale la pena comprobar en cualquier plataforma antes de confiar en ello.

Armar el primer conjunto de reglas

Los programas casi nunca empiezan de cero. Normalmente ya hay roles, unos salidos de la ingeniería de roles del artículo anterior y otros heredados, asignados a mano a quien parecía necesitarlos. Convertirlos en reglas es un trabajo gradual, y una buena forma de juzgar cada regla candidata es comparar con quién coincidiría y quién tiene hoy el rol.

Se corre la regla propuesta como simulación y se ponen sus coincidencias al lado de los miembros actuales del rol. Las personas que aparecen en las dos listas son la parte fácil. Las que la regla abarca pero hoy no tienen el rol son, o un hueco que la regla va a cerrar, lo cual está bien, o una señal de que la regla es demasiado amplia. Las que tienen el rol pero no coinciden con la regla son las más interesantes: algunas lo recibieron por error y deberían perderlo, y otras hacen ese trabajo con un código de puesto que nadie esperaba, lo que significa que a la regla le falta una condición. Una regla está lista para hacerse cargo de un rol cuando esa comparación se ha repasado con el owner del rol y cada diferencia tiene explicación.

El orden del trabajo también importa. Conviene empezar por la capa birthright de toda la organización, porque afecta a todos y es la más simple de acertar. Después, las poblaciones más grandes y estables, las mismas que el artículo de ingeniería de roles recomendaba para empezar, donde una sola regla reemplaza más trabajo manual. Los equipos pequeños y cambiantes pueden seguir con solicitudes de acceso hasta que sus roles se asienten. Y durante el primer mes tras activar las reglas de una población hay que mirar sus solicitudes de acceso; una solicitud que se repite una y otra vez desde el mismo grupo es la señal más clara de algo que la regla debería incluir.

Quién es owner de una política

Toda política necesita un owner, por la misma razón que todo entitlement y todo rol. Las reglas de asignación suelen pertenecer al owner del rol que asignan, porque es quien decide quién debe estar en él. Las reglas de SoD pertenecen al responsable del proceso de negocio que el conflicto pondría en riesgo. Las de ciclo de vida suelen quedar en manos del propio programa de IAM, con cumplimiento acordando los umbrales.

Ser owner implica una cadencia de revisión. Una revisión anual de cada regla de asignación pregunta si la condición sigue describiendo a la población correcta; las organizaciones se reorganizan, renombran áreas y crean códigos de puesto nuevos, y las reglas escritas para la estructura anterior siguen corriendo mucho después de que esa estructura desapareció. Las reglas de SoD se revisan mirando las excepciones que han generado: una regla con decenas de excepciones abiertas, o es demasiado amplia, o describe un proceso que el negocio de verdad no puede separar, y los dos casos piden una conversación, no otra excepción.

Las políticas como evidencia

Los auditores hacen una pregunta que las políticas responden mejor que cualquier otra parte del programa: ¿por qué esta persona tiene este acceso? Para el acceso solicitado, la respuesta es el registro de la solicitud. Para el acceso que dio una regla, la respuesta debería ser igual de concreta. Esta persona coincidió con la regla CxP-Auxiliar-02, versión 4, el día de su contratación, porque RR. HH. registró el código de puesto 4410 en el área 3100. La regla la aprobó la dirección de operaciones de finanzas, se revisó por última vez en marzo y su historial muestra quién la modificó y cuándo.

Esa cadena solo existe si la plataforma guarda las versiones de las reglas y registra qué regla y qué versión produjo cada asignación. Si lo hace, el muestreo es sencillo para ambas partes. Si no, al programa solo le queda explicar que el acceso “vino de una regla” sin poder mostrar cuál, qué decía en ese momento ni quién la aprobó, y un auditor tratará ese acceso, con razón, como acceso sin explicación.

Ejemplo trabajado: birthright para el personal de enfermería de un hospital

Un hospital privado de 1.800 personas quiere dejar de aprovisionar el acceso clínico por ticket. Hoy, las enfermeras nuevas esperan de dos a cuatro días para acceder al expediente electrónico, mientras tanto usan el usuario de una compañera, y la última auditoría de privacidad señaló que conservan el acceso a los pacientes de su unidad anterior después de un traslado.

El equipo de IAM trabaja con la dirección de enfermería y con la owner del expediente electrónico. Acuerdan tres capas. Todo el personal recibe correo, intranet, autoservicio de RR. HH. y la plataforma de formación. Toda enfermera titulada recibe el acceso a la estación clínica y el expediente electrónico con perfil de enfermería, pero todavía sin acceso a pacientes. Y cada asignación a una unidad suma lectura y registro clínico de los pacientes de esa unidad, a partir del código de unidad del expediente de RR. HH.

El trabajo con los datos lleva más tiempo que las reglas. Los códigos de unidad en RR. HH. resultan fiables para el personal fijo pero están vacíos para las enfermeras volantes, que cambian de unidad según el turno. Esas enfermeras reciben una regla aparte con el perfil volante, que da acceso a los pacientes de la unidad donde tengan turno, leída del sistema de programación de turnos en lugar de RR. HH. Las enfermeras de agencia llegan desde el sistema de proveedores con una fecha de fin de contrato y reciben las capas de enfermería y de unidad, pero no el correo del hospital.

Antes de activarlo, una simulación corre las nuevas reglas contra las 1.800 identidades. Muestra 43 enfermeras que perderían acceso que hoy tienen. La mayoría son enfermeras que cambiaron de unidad hace meses, que es justo el hallazgo de auditoría que se quiere corregir. Seis no lo son: sus códigos de unidad se cargaron con una numeración antigua que RR. HH. dejó de usar, y las reglas las habrían dejado sin acceso a sus pacientes actuales. RR. HH. corrige esos seis registros antes de la puesta en marcha.

En este alcance hay una sola regla de SoD. Una enfermera no puede tener además el rol de farmacia que valida y dispensa órdenes de medicación, porque una misma persona podría administrar y rendir cuentas de los medicamentos controlados. La owner de la regla es la dirección de farmacia.

Tres meses después, las enfermeras nuevas tienen acceso al expediente desde su primer turno, los traslados mueven el acceso el mismo día en que RR. HH. registra el cambio y la auditoría de seguimiento no encuentra ninguna enfermera con acceso a una unidad donde ya no trabaja.

Un ejemplo más corto: personal de temporada en una cadena de tiendas

Una cadena de tiendas contrata a 2.000 personas de temporada cada noviembre. Su regla birthright para el personal de tienda da a todos el usuario del punto de venta, la app de horarios y la intranet, sin fecha de fin, porque se diseñó para el personal permanente. Cada febrero, la mesa de servicio pasa semanas deshabilitando cuentas de gente que se fue en enero.

La solución es una política de ciclo de vida, no un birthright distinto. El personal de temporada se identifica por su tipo de contrato en RR. HH., y su birthright lleva una fecha de fin tomada del contrato. Cuando termina la temporada, termina el acceso, y a quien se le extiende el contrato al año siguiente le llega una fecha de fin nueva desde RR. HH. sin que nadie toque la plataforma de IGA.

Errores frecuentes

Los paquetes birthright crecen y casi nunca se achican. Cada herramienta nueva se suma “porque todos la van a necesitar tarde o temprano”, y nadie quita la herramienta que la empresa dejó de usar hace dos años. Revisar el contenido del birthright una vez al año, con datos de uso, lo mantiene honesto.

Las reglas se escriben contra atributos que nadie verificó. La regla parece correcta, los datos de debajo no lo son, y la primera señal del problema es un área entera con acceso de menos o de más.

Las políticas se cambian sin simular, que es como una condición editada deja sin acceso a cientos de personas de un día para otro.

La precedencia se deja en manos de los valores por defecto de la plataforma, y las reglas en conflicto se resuelven distinto según el orden de evaluación.

Las reglas de SoD existen en el papel pero solo se verifican en la certificación. Una regla que solo corre a posteriori detecta conflictos; para prevenirlos tiene que correr donde se otorga el acceso, incluidas las reglas de asignación.

Qué medir

Unas pocas cifras dicen si las políticas hacen su trabajo. La proporción de personas nuevas con el acceso completo el primer día indica si el birthright y las reglas de asignación cubren lo que la gente necesita. El volumen de solicitudes de acceso de una población durante su primer mes indica lo que les falta a las reglas; si cada auxiliar de CxP nuevo pide el mismo reporte, ese reporte va en el rol. La cantidad de acceso otorgado por reglas a personas cuyos atributos ya no coinciden, que aparece en la reconciliación, indica qué tan desactualizados están los datos o las reglas. Y el número de excepciones de SoD abiertas por regla, junto con su antigüedad, indica si cada regla describe un control real o un proceso que el negocio dejó de respetar sin decirlo.

Hay otras dos que conviene seguir cuando las reglas llevan un tiempo funcionando. Una es la proporción del acceso de cada población que llega por reglas y no por solicitudes o asignaciones manuales, que muestra hasta dónde llegó realmente la automatización. La otra es el número de cambios de regla activados sin una simulación registrada, que debería ser cero y casi nunca lo es la primera vez que alguien lo cuenta.

Cómo se relaciona con los estándares

La NIST SP 800-53 Rev. 5 toca las políticas en tres puntos: AC-2 trata la gestión de cuentas, incluidas las condiciones de pertenencia a grupos y roles; AC-5 exige definir la separación de funciones y aplicarla a través de las autorizaciones de acceso, y AC-6 fija el principio de mínimo privilegio que mantiene chico el birthright. El modelo que hay detrás de las reglas de asignación por atributos lo describe la NIST SP 800-162, la guía del control de acceso basado en atributos. ISO/IEC 27001:2022 pide la misma disciplina en los controles 5.3 de segregación de funciones, 5.15 de control de acceso y 5.18 de derechos de acceso de su Anexo A, que exigen definir, aplicar y revisar las reglas de acceso. Y los criterios de SOC 2, en CC6.1 a CC6.3, esperan que el acceso se otorgue según roles y responsabilidades definidos y que cambie cuando estos cambian, que es justo lo que revisará un auditor cuando pregunte cómo se decidió el acceso de David.

Cerrando el ciclo

Las políticas son lo que permite que las decisiones de gobierno de este módulo funcionen solas. Los roles diseñados en el artículo anterior se vuelven útiles cuando las reglas de asignación los reparten a partir de los datos de RR. HH. Las reglas de SoD que hizo posibles el catálogo se vuelven reales cuando se verifican en cada puerta. Y el proceso de solicitud de acceso se achica, porque casi todo lo que la gente necesita el primer día ya lo otorgó una regla que alguien revisó, simuló y tiene a su cargo.

Resumen

Las políticas de IGA son reglas que la plataforma aplica sola: las de asignación otorgan acceso a partir de atributos, las de separación de funciones prohíben combinaciones y las de ciclo de vida deciden cuándo termina el acceso. Una regla de asignación es tan confiable como los atributos que lee, así que debe usar valores codificados, apoyarse solo en campos que RR. HH. haya aceptado que muevan acceso y tratar un campo vacío como una alerta y no como una coincidencia. El birthright se mantiene chico y por capas, primero la organización, después el grupo y por último los roles y las solicitudes, y la prueba para cada elemento es si todos los que cubre lo usarían en su primer mes, como David usó todo lo que recibió aquel lunes. Cuando alguien cambia de puesto, cada regla necesita un orden decidido y cualquier solapamiento debe ser corto y visible, y cada asignación debe guardar su origen para que una regla solo retire lo que otorgó. Cada regla de separación de funciones es un objeto con owner, severidad y excepciones controladas, que se verifica en cualquier punto donde pueda cambiar el acceso, y cuando una prohibición choca con un otorgamiento, gana la prohibición. Y ningún cambio de regla se activa sin una simulación con datos reales que muestre exactamente quién ganaría y quién perdería acceso.

Tres preguntas para ponerte a prueba

1. Una regla birthright da a todos los empleados lectura sobre el data warehouse de la empresa “porque casi todos lo terminan usando”. ¿Qué tiene de malo y dónde debería estar ese acceso?
2. Una regla de asignación da aprobación de pagos a tesorería y una regla de SoD prohíbe la aprobación de pagos a quien pueda editar proveedores. Un analista de tesorería puede editar proveedores. Describe qué debería pasar, y qué pasaría si la precedencia dependiera del orden de las reglas.
3. ¿Por qué una pequeña edición en la condición de una regla de asignación puede ser más arriesgada que aprobar una sola solicitud de acceso privilegiado?

Ejercicio práctico

Diseña las políticas de una población que conozcas bien, como un área de tu trabajo o una sucursal imaginaria.

1. Escribe las capas de birthright (organización, área, equipo) y justifica cada elemento con la prueba de “todos, desde el primer mes”.
2. Escribe dos reglas de asignación con la forma CUANDO/ENTONCES que se mostró arriba, y anota de qué atributos de RR. HH. depende cada una y qué tan confiables te parecen.
3. Escribe una regla de SoD como objeto completo: acceso en conflicto, riesgo, severidad, owner y excepciones permitidas.
4. Describe cómo simularías un cambio en una de tus reglas y qué buscarías en el resultado antes de activarlo.