¿Cómo pueden las organizaciones aplicar la separación de funciones en los controles de acceso?

Separación de funciones en los controles de acceso

La separación de funciones y la segregación de funciones son el mismo control con dos nombres. Los auditores suelen decir "segregación." Los equipos de TI suelen decir "separación." Significan lo mismo: ninguna persona debe poder llevar un proceso sensible de principio a fin sin una segunda revisión.

Si el mismo empleado puede crear un proveedor, aprobar el pago de ese proveedor y conciliar la cuenta, nadie verifica esa transacción de forma independiente. SoD rompe la cadena asignando cada paso a un rol diferente. SOX lo exige para todo lo que afecte a los informes financieros, y los auditores quieren pruebas de que los conflictos se supervisan de forma continua, no solo documentados una vez y archivados.

Cómo hacer cumplir la separación de funciones

Mapea primero tus conflictos. Crea una matriz de responsabilidades que liste los pares de roles o permisos que no deberían estar en manos de una sola persona: crear un vendor y aprobar pagos a vendor, crear una orden de compra y aprobar esa compra, solicitar acceso y aprobar ese mismo acceso. Un par que se pasa por alto más de lo debido es administrar los controles de acceso y administrar los registros de auditoría que los revisan. Un admin que puede otorgar acceso y editar los registros destinados a detectar abusos ha anulado todo el propósito del registro.

Construya roles basados en la función laboral, no en las personas. Una vez que sepa qué conflictos existen, asigne permisos por rol en lugar de por individuo y dé a cada rol solo lo que necesita. El principio de menor privilegio hace dos cosas aquí: reduce el número de combinaciones conflictivas que debe controlar y limita el alcance del daño si una cuenta es comprometida.

Decida qué evitará y qué detectará. Los controles estáticos detienen una asignación conflictiva antes de que ocurra, bloqueando que alguien tenga dos roles incompatibles. Los controles dinámicos permiten la asignación pero la marcan, o requieren que una segunda persona apruebe la transacción específica después. La mayoría de las organizaciones necesitan ambos. Bloquee los conflictos evidentes de inmediato. Use aprobación independiente para las áreas grises que una regla general no podría manejar.

Requiere una segunda persona para acciones de alto riesgo. Para todo lo que no pueda separarse completamente por rol, exige una aprobación independiente antes de completarlo. Una persona inicia, otra aprueba. Aplica esto a la liberación de pagos, despliegue de código o cualquier cambio que afecte un control financiero.

Centralice donde pueda. Cuantos más sistemas estén en uso, más difícil es aplicar las políticas de forma coherente. Un usuario bloqueado en un sistema por un rol estricto puede seguir teniendo acceso activo en otro lugar que nadie recordó revisar. Cuando sea posible, gestione el acceso a través de una única capa para que la misma política se aplique en todas partes en lugar de reinventarse sistema por sistema.

Revise el acceso según un calendario, no cuando algo falla. Los roles cambian. Las personas cambian de trabajo, asumen responsabilidades temporales y acumulan accesos que nadie recuerda haber otorgado. Establezca una revisión periódica, confirme que cada rol sigue correspondiendo al trabajo y corrija cualquier acceso sospechoso.

Documente los controles compensatorios cuando no sea posible una separación real. Los equipos pequeños a veces no pueden separar completamente cada función. Si una persona debe crear y aprobar órdenes de compra porque no hay nadie más, no se limite a encogerse de hombros y seguir adelante. Establezca una revisión independiente por parte de un gerente y manténgala registrada.

Separación de funciones en NetSuite

El modelo nativo de roles y permisos de NetSuite no detecta conflictos de SoD por ti. Puedes crear roles y asignar niveles de permiso, pero nada en la plataforma indica que dos roles en la misma persona entren en conflicto, ni impide que esa asignación se guarde. Así que SoD se convierte en un ejercicio con hojas de cálculo: alguien cruza cada rol, cada nivel de permiso, cada empleado con la matriz de deberes, y lo repite cada vez que cambia un rol. Es lento, fácil de equivocarse, y los auditores no aceptan una limpieza puntual como control continuo. Un conflicto no detectado, una persona que puede crear y aprobar el mismo pago a proveedor, es lo que convierte una auditoría limpia en una lista de remediación.

StrongpointEl módulo Advanced SoD de Strongpoint integra esa aplicación directamente en NetSuite. Comience con una biblioteca de reglas predefinidas creada tras años de trabajo con clientes y auditores, que cubre las necesidades de la mayoría de las organizaciones desde el primer momento. Active solo las reglas que necesite y cree las suyas propias basadas en roles, permisos o ambas, para un control más preciso sobre registros personalizados sensibles cuando falte algo. Los controles de bloqueo detienen una asignación incompatible en el momento en que alguien intenta guardarla, por lo que la prevención ocurre en tiempo real en lugar de en la siguiente revisión trimestral. Para conflictos que no pueda bloquear completamente, Strongpoint registra el incidente y canaliza cualquier exención mediante una solicitud de cambio y aprobación documentadas, de modo que cada control compensatorio deje un rastro documental. El modo de prueba le permite modelar una nueva regla contra roles o empleados existentes antes de que se active, para que pueda ajustarla antes de que empiece a aplicarse. Además, Strongpoint registra cada cambio de regla, exención e infracción, por lo que el Informe de Auditoría SoD y los informes relacionados le proporcionan evidencia continua para auditorías SOX en lugar de una reconstrucción de última hora de quién tuvo qué acceso y cuándo.