Modelo de autorizaciones en SAP: de la gestión de roles al gobierno de la seguridad de accesos
16 de octubre de 2025
Guía técnica para consultores que se enfrentan a la restricción de accesos de lectura
La trampa del ACTVT = 03
Un error frecuente es asumir que, si los objetos de autorización asociados a una transacción incluyen el campo ACTVT con el valor 03 (Display), entonces toda la transacción puede restringirse a modo lectura. En la práctica no es así:
- No todas las funciones internas de la transacción validan esos mismos objetos. Una transacción puede permitir navegar entre pantallas que sí verifican ACTVT 03 y otras que validan directamente actividades de modificación (ACTVT 02) u otros objetos sin diferenciación.
- Existen transacciones mixtas: algunas opciones del menú interno están pensadas para consulta, pero otras permiten crear, modificar o borrar, sin que medie un control específico de “solo lectura”.
- Dependencia del diseño estándar de SAP: si la transacción fue programada sin separar lógica de display/change en sus objetos de autorización, no es posible forzar la restricción solo con roles.
El mayor problema: la suma de roles
Si lo del ACTVT = 03 ya genera confusión, el mayor problema está en cómo SAP maneja las autorizaciones de los usuarios: no evalúa cada rol por separado, las suma todas en memoria (SU56).
¿Esto qué significa en la práctica?
- Que un usuario con un rol de display y otro rol de modificación no se queda con “lo más restrictivo”. Al contrario: termina teniendo lo más amplio.
- El sistema combina los objetos de ambos roles, y si uno le da ACTVT 02 (modificación), ese acceso prevalece aunque el otro rol intente limitarlo a ACTVT 03.
- Desde el punto de vista técnico, no existen “roles que anulen otros”, sino un pool de autorizaciones donde todo lo que se asigna se acumula.
Esto es especialmente peligroso en clientes grandes, donde un usuario puede acumular accesos por distintos proyectos, incidencias o cambios de puesto. Es lo que llamamos access creep: el usuario empieza con permisos mínimos, y al cabo de unos meses tiene un cóctel de roles que lo dejan hacer mucho más de lo que debería.
Checklist técnico para casos de solo visualización
1
Buscar si existe una transacción específica de visualización
Lo primero es verificar si SAP ya ofrece una transacción estándar pensada para consulta.
Ejemplos habituales:
- FI: FB03 (visualizar documentos contables) frente a FB02 (modificar)
- MM: ME23N (visualizar pedidos de compra) frente a ME22N (modificar)
- SD: VA03 (visualizar pedidos de cliente) frente a VA02 (modificar)
Si existe la transacción de display, la mejor práctica es proponer su uso en lugar de intentar limitar la de modificación.
2
Analizar las autorizaciones en detalle
Si no hay transacción de solo lectura, toca revisar cómo está construida la transacción solicitada.
Para ello:
- Ejecuta un trazo con ST01 y revisa todos los objetos de autorización que se disparan en los distintos caminos de la transacción.
- Comprueba con SU53 si el sistema pide más autorizaciones de las previstas. El objetivo es confirmar si todos los objetos que validan la transacción permiten restringir a ACTVT 03 (Display).
3
Evaluar el impacto de objetos compartidos
Hay que revisar si los objetos de autorización implicados son exclusivos de esa transacción o si se comparten con otras.
- Si son compartidos, es muy probable que el control no funcione como se espera.
- En ese caso, el consultor debe comunicar claramente que no es posible garantizar que la transacción quede limitada solo a lectura.
4
Proponer controles adicionales cuando el estándar no alcanza
Si la necesidad del cliente es crítica y el estándar no lo resuelve, se pueden aplicar medidas complementarias:
- BAdIs o User-Exits para bloquear funciones de modificación según el rol.
- Controles compensatorios, como revisiones periódicas de logs de cambios, aprobaciones adicionales o monitorización constante.
Conclusiones
El mito de los roles de “solo visualización” en SAP se origina en la comparación con otras aplicaciones, donde esta restricción es universal y sencilla de aplicar. En SAP, sin embargo, la realidad es más compleja:
- No todas las transacciones validan objetos con ACTVT 03.
- Algunas funciones de consulta permiten navegar hacia opciones de modificación.
- El sistema acumula roles en memoria (SU56), lo que puede neutralizar las restricciones.
Por ello, la mejor estrategia para un consultor de seguridad SAP es explicar claramente estas limitaciones al cliente y proponer alternativas viables: uso de transacciones específicas de display, análisis exhaustivo de autorizaciones, roles derivados por organización, reglas SoD y, en casos críticos, desarrollos adicionales.
Con este enfoque, lo que parecía un problema de “un clic en PFCG” se convierte en una oportunidad de aportar verdadero valor técnico, reforzar la seguridad del sistema y gestionar expectativas de forma profesional.
