La segregación de funciones (SoD, por segregation of duties) parte de una idea muy simple: nadie debería poder completar solo un proceso sensible de principio a fin. El ejemplo de manual es el de compras. Si la misma persona puede dar de alta un proveedor y aprobarle un pago, puede inventarse un proveedor y pagarse a sí misma, y ningún control del proceso lo va a frenar.
En los proyectos de gobierno de identidades, definir y controlar estas reglas es una parte importante del trabajo, y suele ser la que más conversación con el negocio necesita. Acá va qué es un conflicto de SoD, cómo se detecta y qué hacer cuando no hay forma de separar las tareas.
Por qué la piden
Separar funciones sirve contra el fraude y también contra el error: si otra persona tiene que aprobar lo que hiciste, hay una segunda mirada antes de que el cambio impacte. Por eso aparece en casi todos los marcos. ISO 27001:2022 la tiene como control propio (5.3, segregación de funciones), NIST SP 800-53 la cubre en AC-5, y en empresas alcanzadas por SOX es de lo primero que se revisa en los controles sobre el reporte financiero.
Para un auditor es un control fácil de probar: elige un par de permisos que no deberían convivir y busca si alguien tiene los dos. Si aparece alguien y no hay una excepción documentada, ya tiene el hallazgo.
Qué es un conflicto
Un conflicto de SoD es un par (a veces un trío) de funciones que una misma persona no debería tener juntas. Se definen a nivel de negocio, pensando en el proceso, y recién después se bajan a permisos técnicos. Algunos de los más comunes:
| Función A | Función B | Riesgo |
|---|---|---|
| Alta y modificación de proveedores | Aprobación de pagos | Pagos a proveedores ficticios |
| Carga de facturas | Aprobación de esas mismas facturas | Facturas infladas o duplicadas |
| Desarrollo de código | Pase a producción | Cambios sin revisión en sistemas productivos |
| Solicitud de accesos | Aprobación de accesos | Autoasignarse permisos |
| Administración de un sistema | Revisión de los logs de ese sistema | Borrar el rastro de lo que se hizo |
Lo difícil es el paso siguiente: traducir "aprobación de pagos" a los permisos reales de cada sistema. En un ERP puede ser una transacción, un perfil o la combinación de varios; en Active Directory, la membresía a un grupo que da acceso a una carpeta. Si esa traducción está mal, la regla existe en papel y no detecta nada.
Cómo se detectan
Hay dos momentos para hacerlo, y conviene tener los dos.
El control preventivo actúa cuando alguien pide un acceso. Antes de aprobar, el flujo revisa si el permiso nuevo entra en conflicto con lo que la persona ya tiene. Si hay conflicto, la solicitud se rechaza o pasa a una aprobación especial donde alguien acepta el riesgo de forma explícita.
El control detectivo revisa periódicamente los accesos que ya existen. Es necesario porque no todo pasa por el flujo de solicitudes: hay permisos que se dan a mano por una urgencia, cambios de puesto que no le quitaron lo anterior a nadie, y reglas que se crean cuando los accesos ya estaban asignados.
Sin una herramienta, un primer análisis detectivo se puede hacer con una exportación de accesos. Por ejemplo, con dos tablas, una con los accesos de cada usuario y otra con las reglas de conflicto:
-- accesos(usuario, permiso): exportación de lo que tiene cada persona
-- reglas_sod(regla, permiso_a, permiso_b): los pares que no pueden convivir
SELECT r.regla, a.usuario, r.permiso_a, r.permiso_b
FROM reglas_sod r
JOIN accesos a ON a.permiso = r.permiso_a
JOIN accesos b ON b.permiso = r.permiso_b
AND b.usuario = a.usuario
ORDER BY r.regla, a.usuario;Sirve para un primer diagnóstico. El límite aparece rápido: los conflictos más interesantes suelen cruzar sistemas (el alta del proveedor en el ERP y la liberación del pago en el home banking), y para verlos necesitás los accesos de todos esos sistemas asociados a la misma persona. Eso es justamente lo que resuelve una plataforma de IGA, que tiene la identidad única y los accesos de cada sistema conectado.
Cuidado con los roles
Un error que veo seguido es armar roles que ya traen el conflicto adentro. Se crea un rol "Analista de compras" sumando todo lo que tenía la persona que hacía ese trabajo, y esa persona, por acumulación, podía cargar y aprobar. A partir de ahí, cada alta con ese rol nace en conflicto.
Por eso las reglas de SoD también se evalúan sobre la definición de cada rol, antes de asignarlo a alguien. Si un rol viola una regla por sí solo, hay que partirlo.
Cuando no se puede separar
En una empresa chica, a veces hay una sola persona en administración y no hay a quién pasarle la mitad del proceso. Ahí toca convivir con el conflicto y gestionarlo con controles compensatorios. Lo habitual es:
- Registrar la excepción con su motivo, quién aceptó el riesgo y una fecha de vencimiento.
- Hacer que un tercero revise periódicamente las operaciones de esa persona (por ejemplo, los pagos del mes contra los proveedores dados de alta).
- Asegurarse de que los logs de esas operaciones existan y que esa persona no los pueda modificar.
- Volver a evaluar la excepción cuando vence, en lugar de renovarla sola.
Para un auditor, un conflicto con una excepción documentada y un control compensatorio que funciona es muy distinto de un conflicto que nadie conocía.
Por dónde empezar
El error típico es querer cargar cientos de reglas de entrada. Termina en miles de conflictos que nadie puede revisar, y el análisis se abandona. Me funciona mejor sentarme con finanzas, compras y tecnología, acordar entre cinco y diez reglas para los procesos que de verdad preocupan, traducirlas bien a permisos y limpiar esos conflictos primero. Después se suman reglas de a poco.
Si querés una prueba rápida de cómo estás, elegí el par proveedores y pagos, exportá quién tiene cada permiso y cruzalo. Esa lista corta suele decir bastante sobre el resto.