Fundamentos de la segregación de funciones: combinaciones tóxicas y la matriz de conflictos

Un pago que nadie reconocía

David llevaba tres años como contralor financiero en una distribuidora de alimentos mediana cuando el banco llamó por un pago. Era una llamada de rutina para confirmar una transferencia de 48.000 dólares a un proveedor de embalaje, salvo por un detalle: en compras nadie había oído hablar de ese proveedor. La factura estaba en el ERP. También la orden de compra, y una recepción de mercancía de once palés de film retráctil que nadie en el almacén encontraba.

Reconstruir lo ocurrido llevó dos días. Una auxiliar de cuentas por pagar con once años en la empresa había dado de alta al proveedor en el maestro, había registrado una factura a su nombre y la había liberado en la corrida semanal de pagos. Cada uno de esos pasos lo hizo con accesos que tenía de forma legítima. Los permisos sobre el maestro de proveedores le llegaron dos años antes, en un proyecto para sacar trabajo atrasado cuando al equipo de datos maestros le faltaba gente. La liberación de pagos se la dieron durante la baja por paternidad de un compañero y nadie se la quitó después. Su jefa había aprobado ambas cosas, y las dos habían sobrevivido a cuatro revisiones trimestrales de accesos, porque quien miraba cada permiso por separado no veía nada raro.

El problema era la combinación. Ningún permiso era excesivo por sí solo, pero juntos dejaban que una sola persona llevara un pago desde su invención hasta la transferencia bancaria sin que nadie más interviniera. Para eso existe la segregación de funciones, y de eso tratan los cuatro artículos de este módulo.

Qué significa segregar funciones

La segregación de funciones (separation of duties o SoD, también llamada separación de funciones) es el principio según el cual ninguna persona debería poder completar sola una transacción sensible de principio a fin. Los pasos se reparten entre personas distintas para que un error o un fraude necesite al menos a dos, ya sea porque actúan juntas o porque una no se da cuenta, antes de pasar.

La idea es mucho más antigua que la informática. Viene de la contabilidad y del control interno, donde fue la principal defensa contra el fraude mucho antes de que nadie hablara de derechos de acceso. Quien registra los cobros en efectivo no debería ser quien deposita el dinero, y quien firma los cheques no debería conciliar el extracto bancario. El marco de control interno COSO, que es la referencia de la mayoría de los auditores en Estados Unidos y de muchos en otros países, incluye la segregación de funciones entre las actividades de control básicas que se espera que tenga una organización.

En una oficina de papel, las funciones se separaban con escritorios, libros y firmas. La persona de compras no podía liberar un pago porque la chequera estaba en otro cuarto. Cuando esos procesos pasaron a un ERP y a aplicaciones SaaS, la separación dejó de ser física. Ahora existe solo en los permisos de cada persona, y por eso es un problema de identidad. Por eso SoD vive en IGA, y por eso un programa de IGA que no sabe responder “¿quién puede hacer estas dos cosas a la vez?” acabará suspendiendo una auditoría o, como la empresa de David, enterándose por las malas.

Las funciones que se separan

Los contadores suelen hablar de cuatro tipos de función que no deberían recaer en la misma persona. El vocabulario cambia de un manual a otro, pero la idea es la misma.

Autorizar es decidir que algo debe ocurrir: aprobar una orden de compra, aprobar un proveedor nuevo, aprobar un pago. Registrar es introducir la transacción en los libros o en el sistema: crear la orden de compra, contabilizar la factura, hacer el asiento. Custodiar es controlar el activo en sí: el acceso a la cuenta bancaria, al almacén, al inventario o, en TI, al servidor de producción y sus datos. Verificar, que también se llama conciliar o revisar, es comprobar después que lo registrado coincide con la realidad: conciliar el extracto, contar existencias, revisar la corrida de pagos.

Un proceso sano pone al menos dos de esas funciones en manos distintas, y los más sensibles mantienen separadas las cuatro. El modelo también sirve como prueba rápida para cualquier solicitud de acceso nueva. Si alguien que registra transacciones pide poder aprobarlas, o alguien que custodia un activo quiere conciliarlo, probablemente hay un conflicto, aunque nadie haya escrito todavía una regla formal para él.

Combinaciones tóxicas

El término que usan los equipos de identidad para un emparejamiento prohibido es combinación tóxica: dos o más accesos que por separado son inofensivos, y a menudo necesarios, pero que juntos permiten a una persona cometer un error o un fraude y ocultarlo. La combinación de maestro de proveedores y liberación de pagos de la empresa de David es el caso de manual, porque es muy directa. Con las dos, alguien puede inventarse un proveedor o cambiar en silencio la cuenta bancaria de uno real, y después pagarle.

Es tentador pensar en SoD como un tema de finanzas, y es cierto que allí las reglas están más maduras. Pero las combinaciones tóxicas aparecen en cualquier función que mueva valor o cambie el control de algo. En recursos humanos, poder crear fichas de empleado y además ejecutar la nómina permite pagar a alguien que no existe. En TI, crear cuentas de usuario y asignar grupos privilegiados permite a un administrador fabricarse una cuenta de administrador que nadie rastreará. En desarrollo de software, escribir código y desplegarlo en producción sin revisión permite a un ingeniero cambiar por su cuenta lo que ejecuta el negocio. En un hospital, prescribir un fármaco controlado y dispensarlo permite desviarlo. Y dentro de la propia plataforma de IGA, poder solicitar un acceso y aprobar esa misma solicitud vuelve decorativos todos los demás controles del programa.

Lo que hace difíciles de ver estas combinaciones es justo lo que encontró David: cada acceso, por separado, parece razonable. Una revisión de accesos que enseña al revisor un entitlement cada vez no puede atraparlas. Tampoco un proceso de solicitud que comprueba si este acceso concreto está justificado sin mirar lo que la persona ya tiene. Para atraparlas hace falta una regla que nombre la combinación y una plataforma que la evalúe contra todo lo que la persona puede hacer, en todo lo que tiene asignado.

Segregación estática y dinámica

El estándar de RBAC, ANSI/INCITS 359, distingue dos maneras de aplicar la separación, y la diferencia importa a la hora de decidir dónde debe vivir cada control.

La segregación estática es una restricción sobre la asignación. Si dos roles están en conflicto, nadie puede tener los dos, y punto. Es lo que casi todo el mundo entiende por SoD en un contexto de IGA, y es lo que una plataforma de IGA hace bien: conoce todas las asignaciones, así que puede rechazar una combinación cuando alguien la solicita y señalarla cuando ya existe.

La segregación dinámica es una restricción sobre el uso. Una persona puede tener ambos roles, pero no puede activarlos en la misma sesión o, en la versión que implementan la mayoría de las aplicaciones, no puede actuar en los dos lados de la misma transacción. Un jefe de compras puede crear y aprobar órdenes de compra, pero el sistema no le deja aprobar una que haya creado él. Los portales bancarios que exigen que un segundo usuario autorice el pago que otro preparó hacen lo mismo.

Las dos se complementan. La estática es más limpia y más fácil de auditar, pero a veces es demasiado tosca: un equipo pequeño puede necesitar personas que creen y aprueben, solo que nunca sobre su propio trabajo. La dinámica es más flexible, pero vive dentro de cada aplicación de negocio, la configura el equipo de esa aplicación y la plataforma de IGA normalmente no puede ver si está activada. Un programa maduro usa reglas estáticas para las combinaciones que no deben existir nunca y deja anotado en el propio conjunto de reglas qué riesgos cubre la aplicación de forma dinámica, para que alguien compruebe que esa configuración sigue ahí. Un control dinámico desactivado sin que nadie se entere durante una actualización es uno de los hallazgos de auditoría más comunes en este terreno.

Del riesgo al permiso

Una regla que dice “el mantenimiento de proveedores está en conflicto con la liberación de pagos” es perfectamente clara para la directora financiera. Para una plataforma que solo conoce objetos de autorización de SAP, grupos de Entra ID y roles de un portal bancario, no sirve de nada. Por eso todo conjunto de reglas de SoD que funciona está hecho por capas, y acertar con esas capas es la mayor parte del trabajo.

Arriba está el riesgo, escrito en términos de negocio: “se paga a un proveedor ficticio o alterado”. Debajo, las funciones cuya combinación crea el riesgo: “mantener el maestro de proveedores” y “liberar pagos”. Debajo de cada función, los entitlements y transacciones que la realizan en cada sistema: un conjunto de transacciones y apps del ERP para la primera; la corrida de pagos y un rol de aprobador en el portal del banco para la segunda. Y abajo del todo, los permisos técnicos que otorgan de verdad la capacidad, como objetos de autorización con valores de campo concretos, scopes de una API o permisos de base de datos. La herramienta de control de accesos de SAP usa casi exactamente esta estructura, con riesgos formados por funciones y funciones formadas por acciones y permisos, y la mayoría de las plataformas de IGA modelan algo parecido.

flowchart TD
  accTitle: Capas de una regla de SoD, del riesgo al permiso
  accDescr: Arriba está un riesgo de negocio, que se pague a un proveedor ficticio o alterado. Lo crea la combinación de dos funciones, mantener el maestro de proveedores y liberar pagos. La función de proveedores la otorgan transacciones y apps de proveedores del ERP. La función de pagos la otorgan la corrida de pagos del ERP y un rol de aprobador en el portal del banco. Cada uno de esos entitlements lo otorgan a su vez permisos técnicos, como objetos de autorización y sus valores de campo.
  R[Riesgo<br/>se paga a un proveedor<br/>ficticio o alterado] --> F1[Función<br/>mantener proveedores]
  R --> F2[Función<br/>liberar pagos]
  F1 --> E1[Transacciones y apps<br/>de proveedores del ERP]
  F2 --> E2[Corrida de pagos<br/>del ERP]
  F2 --> E3[Rol de aprobador<br/>del portal bancario]
  E1 --> P[Permisos técnicos<br/>objetos y valores]
  E2 --> P
  E3 --> P

Las capas existen porque cada parte del problema tiene un dueño distinto. El responsable del proceso de negocio puede decidir si un riesgo importa y cuánto, y puede explicárselo a un auditor, pero no tiene ni idea de qué objeto de autorización controla los datos bancarios de un proveedor. El equipo de seguridad del ERP sí lo sabe, pero no debería decidir qué riesgos acepta el negocio. Mantener las capas separadas permite que cada grupo cuide su parte. Además, un mismo riesgo puede abarcar varios sistemas: si la aprobación de pagos pasa del ERP a una nueva plataforma de tesorería, el riesgo y sus funciones no cambian; solo cambia la traducción de abajo.

Construir la matriz de conflictos

La matriz de conflictos es la vista del conjunto de reglas que el negocio puede leer. Las funciones van en los dos ejes, y cada celda donde se cruzan dos funciones indica si tener ambas es un problema, qué tan grave es y qué regla lo cubre. Es el documento que firma el responsable del proceso, el que piden los auditores y el que se consulta cuando alguien pregunta “¿le puedo dar las dos cosas a esta persona?”.

Una buena matriz parte de un proceso, no de una lista de permisos. Se elige un proceso, por ejemplo de compra a pago (procure to pay), y se recorre con la gente que lo opera: quién da de alta proveedores, quién emite órdenes de compra, quién las aprueba, quién recibe la mercancía, quién registra facturas y quién paga. Cada uno de esos pasos es una función candidata. La mayoría de los procesos acaban con entre seis y quince funciones; muchas más suele significar que las funciones son en realidad permisos disfrazados y conviene agruparlas.

Después se recorre celda por celda preguntando qué podría hacer una persona con las dos. Para cada par que crea un riesgo real, se escribe el riesgo en una frase que entienda alguien no especialista, se le asigna una severidad y se nombra a un responsable. La severidad suele salir de unas pocas preguntas: si la combinación permite mover dinero o activos directamente, si hay un control posterior que detectaría el abuso (la doble autorización del propio banco, una conciliación mensual que hace otra persona) y cuánto podría perderse antes de que alguien lo notara. Las respuestas deben quedar escritas junto a la regla, porque quien la revise después querrá saber por qué “crear orden de compra más aprobar orden de compra” es crítico y “aprobar orden de compra más registrar facturas” es bajo.

Una matriz como esta es simétrica, porque tener A y B es lo mismo que tener B y A, y su diagonal está vacía, porque una función no puede estar en conflicto consigo misma. Con seis funciones quedan quince pares. No todos necesitan regla. Las celdas medias y bajas suelen aceptarse sin regla formal, o se vigilan en lugar de bloquearse, y esa decisión también debe ser explícita: una celda en blanco tiene que significar que alguien la miró y decidió que no hay un riesgo relevante, no que nadie llegó a revisarla.

Cada regla tiene después su propio registro, con las funciones que cubre, la descripción del riesgo, la severidad, el responsable, los sistemas a los que aplica y las excepciones permitidas. El artículo sobre políticas describió ese registro como un objeto de política y mostró cómo conviven las reglas de SoD con las de asignación y las de ciclo de vida. La matriz es la forma de presentar esos objetos a las personas que tienen que estar de acuerdo con ellos.

Acceso crítico: riesgo sin combinación

Hay accesos que son peligrosos por sí solos, sin necesidad de una segunda función. Cambiar los parámetros de la corrida de pagos, abrir y cerrar periodos contables, administrar usuarios y roles dentro del ERP, editar datos directamente en tablas de producción o desactivar el registro de cambios de una tabla sensible entran en este grupo. Una sola persona con cualquiera de ellos puede hacer mucho daño sin necesitar nada más.

La mayoría de las herramientas de SoD lo tratan como un caso especial de la misma maquinaria, que suelen llamar acceso crítico o acceso sensible: un riesgo con una sola función en lugar de dos. El proceso es idéntico. Se nombra el riesgo en términos de negocio, se traduce a los entitlements y permisos que lo otorgan, se le da una severidad y un responsable, y se decide quién puede tenerlo y en qué condiciones. Va en el mismo conjunto de reglas que los conflictos, porque quien mira el perfil de riesgo de un usuario necesita ver los dos tipos a la vez y porque el proceso de mitigación y aceptación es el mismo para ambos.

A qué nivel evaluar

Con las reglas definidas, la plataforma tiene que evaluarlas contra lo que la gente tiene de verdad, y el nivel al que lo haga decide si los resultados sirven o son solo ruido.

Evaluar solo a nivel de rol es lo más fácil y lo menos fiable. Te dice que alguien tiene el rol “auxiliar de cuentas por pagar” y el rol “analista de tesorería” y, si una regla dice que esos dos roles chocan, tienes un hallazgo. Pero los roles cambian, a menudo se llaman como lo que contenían antes, y un rol llamado “auxiliar de cuentas por pagar” que hace tres años incorporó sin ruido la liberación de pagos nunca disparará una regla escrita sobre nombres de roles.

Evaluar a nivel de transacción o de entitlement es mejor, y es donde opera la mayoría de los programas. La regla traduce cada función a las transacciones, apps o grupos que la otorgan, y la plataforma comprueba si el acceso combinado de la persona incluye algo de cada lado. Su punto débil son los falsos positivos. En SAP, por ejemplo, tener una transacción en el menú no significa poder hacer nada con ella; los objetos de autorización que hay detrás deciden si puedes crear, modificar o solo visualizar. Una regla que se dispara solo por la transacción marcará a cientos de personas que únicamente pueden consultar proveedores, y los conflictos reales se perderán entre el ruido.

El nivel más preciso es el permiso efectivo: la transacción más los valores de autorización que permiten a la persona realizar de verdad la función. Modelarlo cuesta más y exige buenos conectores, pero es el único nivel en el que los números significan lo que dicen. En la práctica, la regla debería definirse a nivel de función, evaluarse contra permisos efectivos allí donde el sistema los expone y reportarse tanto por usuario como por rol, para que se vea si un conflicto viene de la combinación inusual de una persona o de un rol que se lo entrega a todo el mundo.

Conflictos dentro de los roles y entre roles

Un rol que contiene los dos lados de un conflicto es el peor caso, porque todos sus miembros heredan el conflicto el mismo día en que se les asigna. Estos roles son más frecuentes de lo que parece. Suelen nacer copiando el acceso de una persona veterana que hacía varios trabajos, o crecen solicitud a solicitud mientras el dueño del rol añade “solo una transacción más” para un equipo que la necesita. El artículo de ingeniería de roles recomendaba pasar el análisis de SoD sobre el contenido de cada rol antes de publicarlo y cada vez que cambia, y esta es la razón. Corregir un solo rol en conflicto puede eliminar cientos de hallazgos de usuario de una vez.

El caso más habitual es el conflicto entre roles: dos roles limpios por separado que, juntos en una misma persona, forman un conflicto. Son más difíciles de prevenir en el diseño, porque el dueño de cada rol no ha hecho nada mal. Se atrapan comprobando la combinación en el momento de la asignación, y ahí entran los controles preventivos que se describen más abajo.

Conflictos entre sistemas

La auxiliar de la distribuidora trabajaba solo dentro del ERP. Muchos conflictos reales no son así. Una empresa puede mantener los proveedores en el ERP pero aprobar los pagos en el portal del banco, o dar de alta a los empleados en el sistema de RR. HH. y pagar la nómina a través de un proveedor externo. Una regla que mira dentro de un solo sistema dará por limpios los dos lados.

Las reglas entre sistemas dependen de algo a lo que los artículos anteriores dedicaron mucho espacio: saber que la cuenta del ERP JSMITH01 y el usuario del portal bancario j.smith@empresa.com son la misma persona. Sin esa correlación, descrita en el artículo del modelo de datos de identidad, la plataforma ve a dos personas distintas y no puede evaluar la combinación. Las cuentas que no correlacionan, o que alguien creó a mano en un sistema sin conector, son justo donde se esconden los conflictos entre sistemas. Una prueba útil para cualquier herramienta de SoD es montar una combinación tóxica repartida entre dos aplicaciones y comprobar si la herramienta la reporta como una sola infracción. Si alguien tiene que cruzar dos reportes a mano para verla, la herramienta no cubre de verdad la SoD entre sistemas.

Las identidades no humanas también cuentan

La mayoría de los análisis de SoD dejan fuera, sin decirlo, las cuentas de servicio, los usuarios de integración y los tokens de API. No son personas, no encajan en el modelo de roles y a menudo tienen accesos amplios porque una interfaz los necesitó hace años. Y sin embargo suelen ser las identidades con las combinaciones más peligrosas. Una interfaz por lotes que carga facturas de proveedores desde un servicio de digitalización bien puede tener permiso para crear proveedores y contabilizar facturas, porque era la forma más fácil de que la integración funcionara.

El riesgo es real aunque ninguna persona inicie sesión con esa cuenta. Quien controla la integración, porque tiene sus credenciales, puede cambiar su configuración o le entrega un archivo de entrada preparado a propósito, tiene en la práctica sus funciones. Las identidades no humanas deberían pasar por el mismo análisis que las personas, con un responsable humano para cada una, y su acceso debería reducirse a las transacciones concretas que usa la interfaz. Cuando una integración necesita de verdad los dos lados de un conflicto, hay que tratarla como cualquier otra excepción, que es el tema del próximo artículo.

SoD para quienes administran IAM

Hay un grupo de conflictos que todo programa debería revisar antes que cualquier otro: los de su propia administración. Quienes operan la plataforma de IGA normalmente pueden cambiar reglas, aprobar solicitudes en nombre de otros, editar el contenido de los roles y, a veces, escribir directamente en los sistemas destino a través de los conectores. Si la misma persona puede otorgarse un acceso y aprobarlo, o cambiar una regla de SoD y luego tener la combinación que esa regla bloqueaba, el programa tiene un agujero en el centro.

La separación habitual distingue entre administrar la plataforma, aprobar accesos, ser dueño de reglas y roles, y revisar los registros de todo lo anterior. Los administradores de la plataforma no deberían aprobar solicitudes propias ni de los sistemas que administran; los cambios en las reglas debería aprobarlos el responsable de negocio de cada regla, no quien edita la configuración; y las acciones administrativas deberían quedar registradas en un lugar que los administradores no puedan alterar y revisarlas alguien de fuera del equipo, como defendía el artículo de auditoría y reportes. Lo mismo vale para quienes administran directorios y proveedores de identidad, que muchas veces pueden hacer bastante más de lo que la plataforma de IGA sabe.

Prevenir el conflicto o detectarlo

Hay dos formas generales de aplicar SoD, y un programa que funciona necesita las dos.

Los controles preventivos frenan el conflicto antes de otorgarlo. Cuando alguien solicita un acceso, la plataforma simula el resultado, compara el acceso futuro de la persona con el conjunto de reglas y muestra los conflictos al aprobador antes de que decida, como describía el artículo de solicitud de acceso. Cuando una regla de asignación va a otorgar un rol de forma automática, se ejecuta la misma comprobación, y la asignación en conflicto queda retenida en lugar de aplicarse. Cuando alguien cambia de puesto, se revisa el acceso antiguo y el nuevo juntos antes de añadir nada. Y cuando el dueño de un rol modifica su contenido, el cambio se contrasta con las reglas antes de publicarse. Los controles preventivos son más baratos, porque nadie tiene que limpiar después, y más seguros, porque la ventana de riesgo nunca llega a abrirse.

Los controles detectivos encuentran los conflictos que ya existen. La plataforma revisa todo el acceso actual contra las reglas de forma periódica, normalmente a diario o cada semana, y reporta lo que encuentra. Las campañas de certificación muestran al revisor los conflictos de cada persona junto a sus accesos, de modo que decide sobre la combinación y no sobre cada pieza aislada, como recomendaba el artículo de certificación. Los detectivos hacen falta incluso con excelentes controles preventivos, porque el acceso llega por caminos que la plataforma no controla: un administrador que asigna un rol directamente en una aplicación, un acceso de emergencia durante una caída, un sistema que se conectó cuando la gente ya había acumulado permisos en él.

Los dos tipos también deberían informarse entre sí. Un conflicto que encuentra la detección y que debería haber frenado la prevención indica un hueco: un sistema sin conector, una vía de solicitud que se salta la comprobación, una regla que no se evalúa en la asignación. Vale la pena investigar cada uno, porque seguirá produciendo conflictos hasta que se cierre.

Tener el acceso o haberlo usado

Que un conflicto aparezca en el reporte significa que una persona podría hacer las dos cosas, no que las haya hecho. Esa diferencia, entre el riesgo de acceso y lo que algunos fabricantes llaman riesgo ejercido o transaccional, sirve para dos cosas.

La primera es priorizar. Un programa que encuentra 2.000 conflictos en su primera ejecución no puede resolverlos todos a la vez, y empezar por quienes han usado los dos lados recientemente es una forma razonable de ordenar el trabajo. La segunda es que suele ser la vía más rápida para remediar. Si alguien lleva un año con mantenimiento de proveedores y liberación de pagos pero solo ha usado la liberación, quitarle el mantenimiento difícilmente causará problemas, y su jefe lo aceptará con más facilidad que una discusión de principios. La mayoría de los ERP y muchas aplicaciones SaaS registran lo suficiente sobre quién hizo qué como para hacer este análisis, aunque extraerlo cueste algo de trabajo.

El análisis de uso también produce evidencia para los casos que más importan. Si alguien tenía una combinación crítica y usó los dos lados sobre la misma transacción, ya no es una cuestión de accesos: es una transacción que debe revisar alguien ajeno al proceso, y quizá un incidente. La investigación de David habría durado dos horas en lugar de dos días si alguien hubiera estado ejecutando esa consulta.

El conjunto de reglas nunca está terminado

Un conjunto de reglas de SoD describe procesos y sistemas, y los dos cambian. El equipo de finanzas se reorganiza, una nueva plataforma de tesorería sustituye al portal del banco, el ERP migra a una versión con pantallas y modelo de autorizaciones distintos. Cada uno de esos cambios puede dejar reglas obsoletas o conflictos nuevos sin cubrir sin que nadie lo note.

Por eso las reglas necesitan la misma disciplina que cualquier otro objeto controlado. Cada regla tiene un responsable que la revisa al menos una vez al año y siempre que cambia el proceso que cubre. Los cambios en las reglas pasan por control de cambios, guardando la versión anterior y la nueva, para que el programa pueda responder al auditor qué decía la regla en marzo pasado. Y cualquier proyecto que cambie un proceso de negocio o sustituya un sistema debería incluir como entregable la actualización de las reglas afectadas y una prueba de que siguen detectando lo que deben. El caso de estudio de finanzas de este mismo módulo muestra qué pasa cuando una migración de ERP se salta ese paso.

Ejemplo trabajado: la primera matriz de una distribuidora

En la empresa de David, el comité de auditoría pidió un programa de SoD en seis meses. El fabricante del ERP ofrecía un conjunto de reglas genérico con algo más de 200 riesgos, y el primer impulso fue cargarlo y ejecutarlo. El equipo de IGA lo hizo, a modo de experimento. El resultado fueron 9.400 conflictos repartidos entre 380 usuarios, con los que nadie podía hacer nada.

Volvieron a empezar desde los procesos. Durante tres semanas, la analista de IGA hizo talleres con los responsables de compra a pago, de pedido a cobro, de nómina y de registro y cierre contable, y con el responsable de seguridad del ERP. Para cada proceso trazaron los pasos, acordaron las funciones y recorrieron la matriz celda por celda. Muchos de los riesgos genéricos no aplicaban: la empresa no trabajaba con stock en consignación, no tenía motor de nómina propio y no gestionaba activos fijos en el ERP. Se añadieron algunos riesgos que el conjunto genérico no tenía, sobre todo la combinación de datos bancarios de proveedores en el ERP con la aprobación de pagos en el portal del banco. Terminaron con 40 reglas, que redujeron a 12 de severidad crítica y alta para empezar, más una lista de las medias para vigilar.

La primera ejecución real dio 2.300 conflictos. El análisis mostró que cerca del 70 % salía de tres roles: un “superusuario de cuentas por pagar” que combinaba el registro de facturas con la liberación de pagos, un “líder de compras” que podía crear y aprobar órdenes de compra y un rol de “soporte de finanzas” que llevaba años usándose como cajón de sastre. Rediseñar esos tres roles con sus dueños dejó los hallazgos en unos 400. El análisis de uso de los doce meses anteriores mostró que la mayoría de las personas restantes solo había usado uno de los dos lados de su conflicto, y sus jefes aceptaron retirar el acceso sin usar, lo que bajó la cifra a 35.

Esos 35 eran los casos difíciles: un equipo de tesorería de tres personas que se cubrían entre sí, un almacén regional con un único administrador, dos usuarios de integración que de verdad necesitaban crear y contabilizar. No se arreglaban quitando accesos, y la empresa necesitaba una forma de convivir con ellos que un auditor aceptara. Ese es el tema del próximo artículo. Al mismo tiempo se activó la comprobación preventiva en el proceso de solicitud y en la publicación de roles, y durante el trimestre siguiente los conflictos nuevos bajaron a un puñado al mes, cada uno revisado antes de otorgarse.

Un ejemplo más corto: una startup de quince personas

En el otro extremo, una startup de quince personas no puede separarlo todo, y no debería intentarlo. La fundadora aprueba los gastos, la única persona de finanzas registra y concilia, y tres ingenieros se reparten las guardias de producción.

Lo que sí puede hacer es elegir el puñado de riesgos que de verdad harían daño y cubrir cada uno. La doble autorización del propio banco puede garantizar que una segunda persona apruebe todo pago por encima de un umbral, lo que cubre la combinación más peligrosa sin reorganizar a nadie. Los cambios en los datos bancarios de un proveedor pueden exigir una llamada de verificación a un número conocido antes de aplicarse. La nómina puede pasar por un proveedor cuyos cambios revisa la fundadora cada mes. Y los despliegues a producción pueden exigir la revisión de un segundo ingeniero en el repositorio de código. Nada de esto necesita una herramienta de SoD; necesita que alguien haya pensado en las cuatro o cinco combinaciones que importan y haya dejado por escrito cómo se cubre cada una. A medida que la empresa crezca, esas notas serán la primera versión de su conjunto de reglas.

Errores frecuentes

El error más común es importar un conjunto de reglas genérico y tomar su resultado como si fuera el programa. Los conjuntos genéricos sirven como lista de comprobación, pero reflejan los procesos de otro, y ejecutarlos sin adaptar produce miles de hallazgos que no son de nadie. El desenlace habitual es un programa que se apaga después de su primer reporte.

El error contrario es una matriz que nadie mantiene: cientos de reglas que escribió una consultora durante la implantación, sin responsables, describiendo procesos que ya cambiaron. Las reglas sin dueño no se pueden ajustar, no se pueden defender ante un auditor y no pueden aprobar excepciones, así que todos los hallazgos que producen acaban atascados.

Otros errores habituales son evaluar solo roles, lo que deja fuera los conflictos que están dentro del contenido de los roles o que vienen de asignaciones directas; ignorar los sistemas sin conector, que es donde se esconden los conflictos entre sistemas; dejar fuera las cuentas de servicio y los usuarios de integración; y quedarse solo con controles detectivos, de modo que cada trimestre se encuentran y se corrigen los mismos conflictos porque nada impide volver a otorgarlos.

Qué medir

Unas pocas cifras muestran si el programa funciona. El número de conflictos abiertos, desglosado por severidad y por proceso, indica el tamaño del problema y debería ir bajando. El porcentaje de conflictos abiertos con una mitigación o aceptación aprobada indica si el riesgo restante está gestionado o simplemente está ahí. Los conflictos bloqueados o señalados en la solicitud, comparados con los que encuentra la detección, indican si la prevención hace su trabajo; si crece la parte que encuentra la detección, hay una vía que se salta la comprobación preventiva. El tiempo desde la detección hasta la resolución indica si los hallazgos se atienden. Y el número de reglas sin responsable vigente, o sin revisar en los últimos doce meses, indica si el propio conjunto de reglas está sano.

Qué normas lo piden

NIST SP 800-53 Rev. 5 tiene un control específico, AC-5 Separation of Duties, que exige identificar las funciones que deben separarse y definir autorizaciones de acceso que respalden esa separación; funciona junto con AC-6, el mínimo privilegio. ISO/IEC 27001:2022 exige segregar las funciones y áreas de responsabilidad en conflicto en el control 5.3 del anexo A. El marco COSO 2013 sitúa la segregación de funciones entre las actividades de control del principio 10, y es el marco que usan la mayoría de los auditores externos cuando evalúan el control interno sobre la información financiera para la sección 404 de SOX con la norma PCAOB AS 2201. SOC 2 trata la segregación de funciones como punto de atención dentro de sus criterios de actividades de control. Y las definiciones formales de la segregación estática y dinámica vienen del estándar de RBAC, ANSI/INCITS 359, mantenido junto con el NIST.

Resumen

Segregar funciones significa que nadie pueda llevar solo una transacción sensible de principio a fin, lo que en la práctica supone mantener en manos distintas la autorización, el registro, la custodia y la verificación. Como esas funciones ahora existen solo como permisos, SoD es un problema de identidad, y lo que hay que buscar es la combinación tóxica: accesos inofensivos por separado y peligrosos juntos. La SoD estática prohíbe tener los dos lados; la dinámica prohíbe usarlos sobre la misma transacción y suele vivir en la aplicación, así que el conjunto de reglas debe anotar qué riesgos dependen de ella. Un conjunto de reglas que funciona se construye por capas, del riesgo de negocio a las funciones y de ahí a los entitlements y permisos que las otorgan, y se presenta al negocio como una matriz de conflictos hecha a partir de procesos reales, con una severidad, un responsable y un motivo para cada regla. Cubre el acceso crítico además de las combinaciones, se evalúa a nivel de permisos efectivos, mira entre sistemas y también a las cuentas de servicio, y se aplica antes que a nadie a quienes administran IAM. Las comprobaciones preventivas en la solicitud, la asignación, el cambio de puesto y el diseño de roles frenan la mayoría de los conflictos; los análisis detectivos y la certificación atrapan el resto, y cada conflicto que aparece en la detección es una pista sobre un hueco en la prevención. Si a la auxiliar de la distribuidora la hubiera revisado una sola regla, la de mantenimiento de proveedores con liberación de pagos, el film retráctil nunca se habría pedido, porque el segundo acceso se habría quedado en la pantalla de su jefa con una advertencia encima.

Tres preguntas para ponerte a prueba

1. Una persona tiene el rol “auxiliar de cuentas por pagar” y el rol “analista de tesorería”, que sobre el papel no están en conflicto. ¿En qué circunstancias podría tener aun así una combinación tóxica, y cómo lo averiguarías?
2. Tu aplicación de compras ya impide que un usuario apruebe las órdenes que él mismo creó. ¿Eso elimina la necesidad de una regla estática entre crear y aprobar órdenes de compra? ¿Qué anotarías en el conjunto de reglas en cada caso?
3. Un usuario de integración que carga facturas desde un servicio de digitalización puede crear proveedores y contabilizar facturas. ¿Quién debería ser responsable de ese riesgo y qué cambiarías primero?

Ejercicio práctico

Elige un proceso que conozcas bien, de finanzas, RR. HH., TI o desarrollo de software.

1. Enumera sus pasos y agrúpalos en cinco funciones.
2. Dibuja una matriz de conflictos de 5×5 y decide, para cada uno de los diez pares, si tener ambas funciones crea un riesgo real. Para cada par que sí lo cree, escribe el riesgo en una frase y asígnale una severidad.
3. Para la regla más grave, enumera los entitlements o permisos que otorgan cada función en los sistemas que conozcas y anota si alguno lo tienen cuentas de servicio.
4. Decide si esa regla debe aplicarse de forma estática, de forma dinámica dentro de la aplicación o de las dos maneras, y explica por qué.