S_SPO_DEV en SAP: qué es, riesgos de seguridad y buenas prácticas de control
19 de febrero de 2026
¿Quién debe ser el owner de la matriz de riesgos en una compañía?
19 de marzo de 2026
La suma de objetos en SAP: cuando el riesgo no está en ningún rol
En nuestro artículo “El mito de los roles de solo visualización en SAP” abordábamos una de las ideas más extendidas —y a la vez más peligrosas— en la gestión de autorizaciones: la creencia de que un rol es seguro simplemente porque, aislado, no permite ejecutar acciones críticas.
Sin embargo, muchas organizaciones se enfrentan a una pregunta recurrente:
Si los roles parecen correctos de forma individual, ¿por qué aparecen riesgos o hallazgos en auditoría?
La respuesta suele estar en un factor menos visible pero mucho más determinante: la suma de objetos de autorización.
SAP no evalúa roles, evalúa autorizaciones
SAP no analiza los roles de manera aislada. Lo que evalúa realmente es el conjunto de autorizaciones efectivas que tiene un usuario en el sistema.
Estas autorizaciones suelen ser el resultado de la acumulación de múltiples elementos:
- Roles simples
- Roles compuestos
- Perfiles generados
- Valores organizativos
- Accesos heredados de puestos anteriores
- Autorizaciones temporales que nunca se retiraron
SAP no distingue el motivo por el que se concedieron esos accesos.
El sistema simplemente evalúa si existe una combinación válida de objetos y valores que permita ejecutar la acción solicitada.
Uno de los mayores malentendidos en la seguridad SAP
Muchas organizaciones revisan los roles uno a uno con la sensación de que ese análisis garantiza el control del modelo de autorizaciones.
Sin embargo, en la práctica ocurre algo diferente:
- El usuario no ejecuta transacciones “desde un rol”.
- El usuario ejecuta transacciones desde la suma de todos sus roles.
Esto puede generar situaciones inesperadas.
Por ejemplo:
1
Un rol permite visualizar información financiera.
2
Otro rol permite modificar determinados datos maestros.
3
Ninguno de los dos roles parece crítico por separado.
Cuando diferentes transacciones usan los mismos objetos de autorización
El problema se amplifica por una característica estructural del modelo de seguridad de SAP:
Esto significa que:
- Distintas transacciones no siempre validan objetos diferentes.
- Varias transacciones pueden consultar exactamente los mismos objetos y campos para autorizar el acceso.
Como consecuencia, pequeñas variaciones en los valores de un objeto pueden tener un impacto mucho mayor del esperado.
El efecto acumulativo de las autorizaciones
El riesgo aumenta especialmente cuando varios roles contienen el mismo objeto de autorización con valores distintos.
En estos casos, SAP no aplica una lógica restrictiva. El sistema no selecciona el valor más limitado.
En realidad ocurre lo contrario:
- Si un perfil contiene un valor más amplio
- Ese valor prevalece en la evaluación
Esto genera lo que se conoce como pools de autorizaciones, donde:
- Los mismos objetos aparecen repetidos en distintos roles
- Con valores diferentes
- Y terminan otorgando más capacidad de la prevista
El resultado es claro:
- El control se diluye
- La trazabilidad del riesgo se pierde
- Y el acceso efectivo del usuario resulta difícil de explicar
Cuando aparece un acceso que “no debería existir”
Cuando estas situaciones salen a la luz, normalmente ocurre en forma de sorpresa.
Un caso típico es el siguiente:
- Un usuario ejecuta una acción que según la documentación no debería poder realizar.
- Se revisan los roles asignados.
- Y aparentemente todo parece correcto.
En estos casos, el problema no suele estar en un rol concreto, sino en la interacción entre todos ellos.
SU56: la vista real de lo que SAP está evaluando
La transacción SU56 permite visualizar las autorizaciones que SAP carga en la memoria intermedia de un usuario para evaluar el acceso a los distintos procesos.
Esta vista muestra:
- Los objetos de autorización activos
- Los valores que SAP está evaluando
- El resultado de la suma de todos los perfiles del usuario
Sin embargo, es importante entender lo que no muestra:
- No muestra roles
- No muestra estructuras jerárquicas de diseño
- No muestra la lógica organizativa del modelo
Lo que muestra es el resultado final que SAP utiliza para tomar sus decisiones.
Y ahí es donde muchas organizaciones descubren algo importante:
SAP no concede accesos por error.
Simplemente aplica una lógica basada en la suma de todos los objetos de autorización asignados al usuario.
Cambiar el enfoque de la gestión de autorizaciones
Por eso, el verdadero desafío no es crear roles “más seguros”, sino cambiar el enfoque.
La gestión de autorizaciones en SAP no puede basarse únicamente en parches puntuales o revisiones reactivas. Requiere una visión global, capaz de analizar cómo interactúan los permisos entre sí, qué objetos son críticos por su efecto acumulativo y cómo evoluciona el acceso de los usuarios a lo largo del tiempo.
Entender la suma de objetos es entender cómo SAP decide, de verdad, quién puede hacer qué.
Y hasta que no se aborda ese nivel de análisis, muchas organizaciones seguirán enfrentándose a riesgos que no están en ningún rol concreto, pero que existen igualmente.
