La segregación de funciones en SAP (SoD, por sus siglas en inglés) es uno de los primeros puntos que revisa una auditoría interna o externa. SAP la describe como un control interno básico para prevenir o reducir el riesgo de errores e irregularidades (SAP Help).
El problema es que los permisos se acumulan sin que nadie lo note. Un usuario cambia de puesto y conserva su rol anterior; se da un acceso temporal en un cierre y nadie lo quita; un rol se amplía para resolver una urgencia. Año tras año, el mapa de accesos se aleja de lo que la empresa cree tener.
En este artículo repasamos qué busca exactamente el auditor, los conflictos más comunes en S/4HANA y cómo detectarlos y corregirlos antes de la revisión.
¿Qué es la segregación de funciones en SAP y qué revisa el auditor?
La idea es simple: las tareas que permiten cometer y ocultar un error o un fraude deben estar en manos distintas. Quien crea un proveedor no debería poder registrar sus facturas y aprobar el pago; quien modifica precios no debería poder facturar.
En SAP, esas tareas se traducen en transacciones, aplicaciones Fiori y objetos de autorización agrupados en roles. Un conflicto aparece cuando un mismo usuario, sumando todos sus roles, puede ejecutar dos funciones incompatibles.
Las herramientas de análisis de accesos de SAP distinguen tres tipos de riesgo (SAP Learning), y el auditor suele revisar los tres:
- Riesgos de segregación de funciones: combinaciones de dos o más funciones en conflicto en un mismo usuario.
- Accesos críticos: una sola función tan sensible que debe estar muy restringida, como abrir y cerrar períodos contables o mantener la tabla de bancos.
- Permisos críticos técnicos: perfiles amplios como SAP_ALL, acceso a depuración con cambio de valores o a la modificación directa de tablas.
Además, el auditor pedirá evidencia de cómo se gestionan: quién aprueba los accesos, cada cuánto se revisan y qué controles compensan los conflictos que se aceptan.
¿Qué conflictos de permisos va a encontrar tu auditor?
Cada empresa define su propio conjunto de reglas, pero hay conflictos que aparecen en casi todas las revisiones. Esta tabla reúne los más habituales en SAP S/4HANA, ordenados por proceso:A estos se suman los hallazgos de accesos críticos que no dependen de una combinación: usuarios con SAP_ALL en producción, cuentas genéricas compartidas, usuarios de personas que ya dejaron la empresa y accesos de emergencia sin registro de uso.
Una observación frecuente no es el conflicto en sí, sino la falta de evidencia: la empresa sabe que hay un conflicto aceptado, pero no puede mostrar qué control lo compensa ni quién lo revisó.
¿Cómo detectar los riesgos antes que el auditor: SAP GRC u otras opciones?
Hay tres caminos habituales, y la elección depende del tamaño de la empresa y de lo que necesites gestionar después del análisis.
Revisión manual. Extraer usuarios y roles con los reportes estándar de SAP y cruzarlos en hojas de cálculo. Es posible en empresas pequeñas, pero lento, difícil de repetir y propenso a errores, porque un conflicto depende de la combinación de transacciones y objetos de autorización de todos los roles de un usuario.
SAP GRC Access Control. Es la solución de SAP para gobierno de accesos. Su análisis de riesgos compara los permisos de cada usuario con un conjunto de reglas y se complementa con gestión de roles, aprovisionamiento de usuarios con revisión de riesgos y gestión de accesos de emergencia (SAPinsider). Es la opción más completa, especialmente para grupos grandes con muchos sistemas, pero requiere un proyecto de implementación, infraestructura propia y un equipo que la administre.
SAP Risk Identification de Intelecta. Un análisis de riesgos de segregación de funciones, permisos críticos y licencias desarrollado 100 % en ABAP, es decir, que se ejecuta dentro de tu propio sistema SAP. Está pensado para empresas que necesitan saber dónde están sus riesgos y llegar preparadas a la auditoría sin implementar una plataforma completa de GRC. Más detalle en SAP Risk Identification.
| Criterio | Revisión manual | SAP GRC Access Control | SAP Risk Identification |
|---|---|---|---|
| Alcance | Lo que el equipo alcance a revisar | Análisis, roles, aprovisionamiento y accesos de emergencia | Análisis de SoD, permisos críticos y licencias |
| Implementación | No requiere | Proyecto e infraestructura propios | Dentro de tu sistema SAP |
| Repetible | Difícil | Sí, continuo | Sí |
| Mejor para | Pocos usuarios y roles | Grupos grandes y entornos regulados exigentes | Empresas que necesitan visibilidad y preparar la auditoría |
Las opciones no se excluyen: un análisis como Risk Identification puede servir como línea base antes de decidir si hace falta una plataforma de GRC.
¿Cómo corregir los conflictos y evitar que vuelvan?
Encontrar conflictos es la parte fácil. Lo que el auditor valora es cómo los tratas. Hay dos respuestas posibles para cada uno:
- Remediar: quitar el permiso o rediseñar el rol para que el conflicto desaparezca. Es la opción preferida.
- Mitigar: cuando el conflicto no se puede separar (por ejemplo, en un equipo pequeño), mantenerlo y asignarle un control compensatorio documentado, con responsable y frecuencia de revisión.
Este checklist sirve para preparar la próxima auditoría:
- Tienes un conjunto de reglas de SoD y accesos críticos acordado con negocio y auditoría.
- Analizaste todos los usuarios de producción con esas reglas en los últimos tres meses.
- Ningún usuario de diálogo tiene SAP_ALL ni perfiles equivalentes en producción.
- Los usuarios de personas que dejaron la empresa están bloqueados.
- Cada conflicto aceptado tiene un control compensatorio, un responsable y evidencia de su revisión.
- Los accesos de emergencia dejan registro de quién los usó, cuándo y para qué.
- Las solicitudes de acceso nuevas se revisan contra las reglas antes de aprobarse.
- Hay una revisión periódica de accesos firmada por los responsables de cada área.
El último punto es el que evita que los conflictos vuelvan. Un análisis único deja el sistema limpio por unos meses; un proceso de revisión lo mantiene así.
Preguntas frecuentes
¿Qué significa SoD en SAP? Son las siglas en inglés de Segregation of Duties, segregación de funciones. Se refiere a separar entre distintas personas las tareas que, juntas, permitirían cometer y ocultar un error o un fraude.
¿Es obligatorio tener SAP GRC para pasar una auditoría? No. El auditor revisa que los riesgos estén identificados, tratados y documentados, no qué herramienta usaste. SAP GRC Access Control es la opción más completa, pero hay alternativas más ligeras para el análisis.
¿Qué hago si mi equipo es pequeño y no puedo separar funciones? Mitiga el conflicto: manténlo, pero asigna un control compensatorio, como una revisión periódica de las transacciones de ese usuario por otra persona, y guarda la evidencia.
¿Cada cuánto conviene analizar los permisos? Como mínimo, antes de cada auditoría y después de cambios importantes de roles o estructura. Lo ideal es revisar cada solicitud de acceso nueva contra las reglas antes de aprobarla.
¿La segregación de funciones tiene relación con las licencias SAP? Sí, de forma indirecta. Los mismos roles que generan conflictos suelen dar a los usuarios más acceso del que necesitan, lo que puede afectar al tipo de licencia que requieren. Por eso conviene revisar ambos temas juntos.
¿Quieres saber qué encontraría hoy tu auditor?
Con Risk Identification analizamos los permisos de tus usuarios en SAP y te entregamos los conflictos de segregación de funciones, los accesos críticos y las oportunidades en licencias, priorizados por riesgo. Así llegas a la auditoría sabiendo qué corregir y qué documentar.
También te puede interesar SAP AMS: cuándo el soporte por tickets ya no basta.
Fuentes
- SAP Help: Segregation of Duties (SAP Access Control) (definición de la SoD como control interno)
- SAP Learning: Building a Rule Set (tipos de riesgo de acceso en SAP Access Control)
- SAPinsider: Get your system clean with Risk Analysis and Remediation (capacidades de SAP GRC Access Control)