1 caso de uso

Esta metodología es especialmente útil para realizar el rediseño de roles de SAP (pequeña o gran escala) donde elija implementar nuevo Rol(es) de SAP para su productivo entidad de SAP, para reemplazar un concepto de rol existente con un nuevo concepto de rol mejorado y está buscando una estrategia de prueba de autorización de alta calidad que requiera poca participación de los usuarios comerciales.

Esta metodología funciona bien desde la versión básica 7.4 en adelante y también es útil si desea reducir el acceso amplio (como SAP_ALL) de los usuarios del sistema (u otros técnicos) y elige implementar nuevas funciones.

Esta metodología es no útil:

• si cambia un rol de SAP existente que ya está asignado a los usuarios en su sistema productivo
• si está ejecutando un proyecto de implementación de SAP (la nueva entidad de SAP aún no está en uso en el sistema productivo).

requisitos previos:

• Su equipo de control interno/cumplimiento acepta transportar los roles de SAP recién creados hasta el sistema productivo. Esta metodología de prueba se ejecuta directamente en producción. A primera vista, esto suena arriesgado, sin embargo, el riesgo de otorgar un acceso inapropiado durante la fase de prueba puede mitigarse mediante varias comprobaciones previas.
• No se deben agregar autorizaciones críticas y/o innecesarias a sus funciones recién creadas. Supongo que si está buscando una metodología como esta, ya conoce muchas de ellas. (Si usa GRC -AC, entonces debería poder ejecutar un análisis de riesgo en los roles recién creados que ya están en el sistema de desarrollo y puede asegurarse de que solo transporta roles sin riesgo a producción)
• Tiene la transacción STUSERTRACE (rastreo a largo plazo) disponible en su sistema SAP y sabe cómo usarla. (Esta transacción está muy bien documentada para que pueda comprenderla fácilmente)

2 Resumen de la metodología

Los pasos del proceso son los siguientes:

1. Diseño/Implementación: cree los nuevos roles de SAP como de costumbre y transpórtelos hasta el sistema productivo
2. Preparación para la prueba:
   1. crear usuarios de referencia (tipo de usuario L) y asignar el usuario de referencia a los ID de usuario de SAP «normales»
   2. asignar los nuevos roles al usuario de referencia
   3. configurar un seguimiento a largo plazo para los usuarios «normales» (STUSERTRACE)
3. Pruebas: analice los resultados de STUSERTRACE y aplique correcciones
4. Activar (cambiar los roles del usuario de referencia y el ID de usuario normal de SAP y eliminar el usuario de referencia)
5. Hyper care (en caso de que algo salga mal por cualquier motivo, aún puede volver a agregar el usuario de referencia y analizar la causa raíz sin estrés)
6. Cierre: elimine los roles «antiguos» y los usuarios de referencia según sea necesario

Figura – 1 (la imagen fue hecha por mí)

Con esta metodología, puede lograr muy buenos resultados de prueba para posibles problemas de autorización sin que los usuarios sepan siquiera que están probando, y debido a que todo sucede en el sistema productivo, se trata de una prueba real y exhaustiva de extremo a extremo. , y no requiere un esfuerzo extra por parte del negocio.

3 Explicación detallada

3.1 Configurar usuarios de referencia

Una vez que haya terminado con la implementación de roles en su sistema de desarrollo y haya transportado todos los roles recién creados a su sistema productivo, deberá continuar creando usuarios con el tipo de usuario «L-Reference». Según el escenario, es posible que deba crear un usuario de referencia dedicado para cada usuario normal, pero también es posible asignar el mismo usuario de referencia a varias ID de usuario normales.

Figura – 2 (la foto fue tomada por mí)

No es posible iniciar sesión con el propio usuario de referencia, por lo que esto no significa que los usuarios «normales» tendrán 2 ID de usuario. Este es un tipo de usuario técnico que solo se puede asignar al ID de usuario normal de SAP.

Afortunadamente, esto no tiene impacto en el costo de su licencia porque SLAW2 normalmente no cuenta a los usuarios de referencia, pero es mejor verificarlos dos veces para evitar sorpresas.

3.2 Agregar usuarios de referencia a los ID de usuario regulares de SAP

Debe agregar el usuario de referencia al usuario normal en la pestaña «Roles» en SU01/SU10:

Figura – 3 (la foto fue tomada por mí)

Hay una entrada en la tabla PRGN_CUST (REF_USER_CHECK) que controla el comportamiento del sistema cuando intenta asignar una identificación de usuario aquí que no es del tipo «L – Referencia».

Figura – 4 (la foto fue tomada por mí)

En caso de que esté utilizando la administración central de usuarios (CUA), deberá crear los usuarios de referencia en todos los sistemas donde se crea el usuario regular; de lo contrario, el segmento de usuario del idoc USERCLONE fallará para aquellos sistemas donde se crea el usuario regular. se crea el ID de usuario, pero no el usuario de referencia.

Si utiliza un sistema SAP con la versión básica 7.50, la cantidad máxima de perfiles que se pueden asignar a un usuario es 312. El usuario de referencia no tiene efecto en este límite, lo que significa que el usuario normal tiene un umbral de 312 y la referencia el usuario también tiene su propio umbral del mismo tamaño.

3.3 Configurar el rastreo de autorización a largo plazo (STUSERTRACE)

Uno de los elementos clave de esta metodología de prueba si tiene el código de transacción STUSERTRACE en su sistema SAP.

Este código de transacción está bien documentado en SAP y también hay buenas publicaciones de blog al respecto en SCN, por ejemplo, https://blogs.sap.com/2021/09/20/stusertrace-new-tracing-option-authorization-trace-for-user/

STUSERTRACE recopila los datos en una tabla SAP dedicada: (SUAUTHVALTRC), lo que a veces facilita el análisis y, mientras ejecuta STUSERTRACE, aún puede usar ST01 o STAUTHTRACE como de costumbre.

Para resumir:

• ha creado usuarios de referencia y los ha asignado al ID de usuario normal de SAP
• asignó los nuevos roles a los usuarios de referencia
• ha activado el seguimiento a largo plazo y ha configurado el filtro para los ID de usuario regulares

En este punto, básicamente comenzó la prueba. Debe iniciar el proceso de análisis de los resultados del seguimiento. En el seguimiento de autorización, verá si una verificación de autorización fue exitosa a través del usuario de referencia o del usuario normal o si no fue exitosa en absoluto.

Figura – 5 (la foto fue tomada por mí)

La razón por la que esta metodología funciona bien es que SAP las autorizaciones se comprueban en secuencia. Primero, el sistema verifica si el usuario de referencia tiene la autorización correcta; de lo contrario, el sistema verifica si el usuario normal de SAP tiene la autorización necesaria., es por eso que necesitaba agregar los nuevos roles a los usuarios de referencia y mantener los roles antiguos para el ID de usuario de SAP normal. Básicamente, de esta manera puede ejecutar un análisis de «qué pasaría si» con respecto a lo que sucedería si el usuario normal solo tuviera los nuevos roles.

Figura – 6 (la foto fue tomada por mí)

3.4 Analizar resultados y solucionar problemas

Esto es un poco extraño, pero en este caso, las líneas que podrían ser problemas potenciales en STUSERTRACE son las que tienen éxito. sin información adicional (consulte la Figura – 5), porque estas verificaciones de autorización fueron exitosas con las autorizaciones del usuario normal, por lo que es algo que falta en sus nuevos roles. Algunos de estos valores podrían faltar a propósito, por lo tanto, serán falsos positivos, esto es algo que requiere un análisis cuidadoso.

Las líneas que tienen éxito con la información adicional «Autorizado a través del usuario de referencia» son aquellas verificaciones de autorización que tendrán éxito con sus nuevos roles.

Las líneas en las que falló la verificación de autorización (ya sea RC = 4 o 12) son casos en los que el usuario normal ya no tenía acceso (por lo tanto, de su rol «antiguo») también.

Puede ejecutar el análisis siempre que esté seguro de que no quedan problemas. La principal ventaja es que los usuarios comerciales no notarán ninguna diferencia, están haciendo su trabajo diario como antes y obtendrá un resultado de prueba muy detallado.

Una vez más, solo para decir lo obvio: es importante que no todas las verificaciones de autorización fallidas sean problemas, y que no todas las verificaciones de autorización aprobadas estén bien, por lo que cuando aplica esta metodología técnica, necesita saber lo que está haciendo.

4 Algunos inconvenientes

Este es un enfoque técnico para las pruebas de autorización e incluso si tiene algunos beneficios importantes (alta calidad de las pruebas y baja participación comercial), también hay algunos inconvenientes:

• No puede aplicar esta metodología para roles que ya están asignados a usuarios en su sistema productivo y no puede aplicar esta metodología para entidades que aún no viven en su sistema productivo.
• Necesita transportar nuevos roles hasta llegar a la producción. En algunos casos, esto podría no ser posible, sin embargo, vale la pena intentar convencer a su equipo de controles internos 😊
• Hay algunas cosas que no se «agregaron» del usuario de referencia
  Esta metodología es útil para probar las autorizaciones ABAP, por lo que cualquier otro elemento de su rol «antiguo» (por ejemplo, el menú de rol para Fiori o NWBC, el flujo de trabajo basado en el nombre técnico del rol u otras implementaciones personalizadas que dependen del nombre técnico del rol) podría no ser probado con esta metodología
  Además, es posible que no pueda probar los aspectos de acceso relacionados con los parámetros del usuario y otras configuraciones relacionadas con los datos maestros del usuario.
• Según la documentación, se puede rastrear un máximo de 1000 usuarios a la vez sin impacto en el rendimiento. Este número puede ser demasiado bajo dependiendo de la escala de sus pruebas.
• Problemas técnicos: no enfrenté ningún problema técnico, sin embargo, encontré algunas publicaciones de blog en SCN y algunas notas de soporte de SAP, sobre la transacción STUSERTRACE y las verificaciones de autorización de los usuarios de referencia. Lo más probable es que estos hayan sido corregidos por los paquetes de soporte posteriores, pero puede verificar cuál es su versión/versión de SAP y comenzar con una investigación primero.

5. Conclusión

Incluso si esta metodología es bastante técnica y requiere un poco más de preparación que un enfoque de prueba habitual, personalmente la encontré útil y efectiva. Después de una prueba de 3 meses, aunque solo usé esta metodología, solo hubo algunos problemas menores después de la puesta en marcha.

Haga/responda preguntas relacionadas con SAP Access Control aquí:
https://answers.sap.com/tags/01200615320800000796

Siga/comente los temas relacionados con SAP Access Control aquí:
https://blogs.sap.com/tags/01200615320800000796/

Comparta a continuación en la sección de comentarios sus pensamientos e ideas sobre esta publicación de blog.