El objetivo principal de este artículo es explorar cómo adoptar una estrategia de autorizaciones basada en las mejores prácticas en SAP GRC Process Control. Como se ha mencionado con anterioridad en otros artículos, Process Control desempeña una función fundamental en garantizar el cumplimiento con diversas regulaciones. En este contexto, cobra especial relevancia la gestión de acceso a la información de acuerdo con los roles y responsabilidades de cada usuario.
Entity Level Authorizations
La restricción del acceso a la información mantiene la integridad de entorno de monitorización. Dado que la herramienta de Process Control trabaja con información de todo el sistema organizativo empresarial, es de vital importancia mantener este punto en mente.
Por eso en SAP GRC existen las autorizaciones a nivel de identidad o “Entity-Level Authorizations” que funcionan como una extensión de los estándares de autorización ya presentes en el propio SAP.
Esta figura nace como respuesta a la necesidad restringir el acceso a la información por departamentos o entidades dentro de una misma empresa.
Además, ofrece un modelo de gestión más amigable para el usuario ya que permite realizar gestiones a través del portal “Front-end” de GRC, SAP Net Weaver Business Client (NWBC).
Roles & Entity-level Assignments
Para ejemplificar mejor el funcionamiento de los “Entity level” usaremos el organigrama mostrado basándonos en 2 casuísticas en función de si el sistema tiene el heredado de roles (“Role Inheritance for Organizations”) para organizaciones activo o no.
CASO A:
- Role Inheritance for Organizations: Desactivada.
- Asignación de rol: “Organization Owner”.
- Actividad: Cambio o modificación.
- Tipo de entidad: Unidad Organizacional.
- Entidad Asignada: Org A2.
Los recuadros con el marco rojo son aquellos donde el usuario podrá realizar cambios en los datos que se encuentren en su mismo nivel organizativo. Esto es importante, porque en el caso de existieran niveles inferiores el usuario solamente podría visualizarlos ya que la naturaleza de su rol impide realizar cambios fuera de su nivel de asignación.
En el caso de los recuadros negros el usuario podrá visualizar los datos de los niveles jerárquicos superiores, pero no modificarlos.
Es interesante destacar que tampoco podrá visualizar los datos de otras organizaciones que broten a partir de un nivel jerárquico superior como sería el caso de la Org B en este caso.
CASO B:
- Role Inheritance for Organizations: Activada,
- Asignación de rol: “Organization Owner”.
- Actividad: Cambio o modificación.
- Tipo de entidad: Unidad Organizacional.
- Entidad Asignada: Org A1.
En este caso el usuario tendrá a su disposición la posibilidad de ver y modificar los datos dentro su organización (recuadro rojo) y también tendrá la posibilidad de ver y asignar subprocesos y controles (recuadro gris) siempre y cuando se encuentren en un nivel jerárquico inferior dentro de la misma rama del organigrama.
Nuevamente en el caso de los niveles superiores, la posibilidad de visualizar la información de esos niveles estará presente pero no se podrán realizar cambios en ella.
Antes de continuar es relevante destacar que existe una excepción a este escenario, se trata de los roles a nivel corporativo:
- Este tipo de roles no se ven afectados por la opción “Role Inheritance for Organizations”, aun así, su funcionamiento a nivel de autorizaciones es el mismo en ambos casos.
- En este caso los usuarios pueden realizar tareas de cambio en los niveles organizativos en los que hayan sido asignados directamente, así como todas las organizaciones subordinadas que existan dentro del mismo nivel corporativo.
- El tipo de acceso a los tipos de objetos relacionados como pueden ser los subprocesos o controles se verá determinado en función de las autorizaciones que sean agregadas a dicho rol.
Todo lo anterior, se configura desde la SPRO, en el apartado de General Settings y en el subapartado de Maintain Authorization Customizing.
En resumen,
- Si la “herencia de roles para organizaciones” está activada.
- Los usuarios gestionan objetos asignados directamente y en organizaciones subordinadas en la misma sub-rama (el acceso a objetos relacionados depende de autorizaciones de roles en back-end).
- Si la “herencia de roles para organizaciones” NO está Activada:
- Los usuarios pueden gestionar objetos asignados directamente (organizaciones, procesos, controles), pero únicamente pueden visualizar organizaciones subordinadas (no gestionarlas).
Tipos de roles
Las autorizaciones para que un usuario final muestre, cambie o cree datos de Process Control se determinan en 3 áreas, cada una con su propio tipo de función:
- SAP “back-end”: Este grupo incluye los roles standard creados en SAP (roles técnicos), creados a través de la transacción PFCG, también incluye los roles base que otorgan acceso a la aplicación, así como los roles funcionales de PC (“Process Control”) que dan acceso a determinadas acciones y tipo de entidad específicos.
- Aplicación GRC UI: Son los roles propios de la aplicación de PC (roles de negocio) que se asignan a un usuario a través de la UI de GRC.
- SAP “Enterprise Portal”: Este caso solo se aplica si se ha optado por usar esta modalidad en la empresa. Este portal tiene sus propios roles que asigna a un usuario final y con ellos determina el número y el orden de centros de trabajo a los que podrá acceder, así como otras variables.
Dentro de la categoría de Roles Técnicos existen 3 roles que deben de ser asignados a todos los usuarios de PC en entorno “back-end”:
- SAP_GRC_NWBC: Da acceso al SAP Netweaver Business Client mediante el T-Code, NWBC y también a través de ciertos centros de trabajo de tipo Web Dynpros.
- SAP_GRC_FN_BASE: Otorga autorizaciones técnicas necesarias para ejecutar tareas de PC.
- SAP_GRC_FN_BUSINESS_USER: Habilita a un usuario final para ser elegible para la asignación de un rol de usuario y entidad en la UI de GRC. Además, activa la actividad “16” (ejecutar) en el objeto GRFN_USER.
Al igual que los roles técnicos, los roles de negocio también tienen ciertas particularidades que se manifiestan a través de lo que se llaman “roles funcionales”:
- Estos roles son el equivalente a la parte técnica de los roles de negocio.
- Estas versiones deben de existir en la PFCG, pero su asignación deberá de realizarse a través de la UI de GRC.
- SAP trae de serie una lista de roles funcionales de PC standard con una serie de autorizaciones preconfiguradas para algunos tipos de entidad concretos.
- Estos roles pueden ser modificados a través de las opciones de configuración de la UI.
Además, también existe un rol de usuario avanzado: GRC_SAP_GRC_FN_ALL: Rol técnico que solo se puede asignar en el Back-End (pero proporciona acceso al contenido de la PC en la interfaz de usuario de GRC). Similar al SAP_ALL, pero para la parte de Process Control. Permite visualizar toda la información del sistema de Process Control.
Configuración de autorizaciones en PC.
Presentamos a continuación el método de configuración que se considera de buenas prácticas:
Cada uno de estos pasos tiene una serie de criterios recomendados que iremos comentando a continuación. Todos estos parámetros pueden configurarse a través de la transacción SPRO en el “back-end” de SAP.
Paso 1: Definir los roles en la PFCG
SAP trae de serie una serie de roles standard (técnicos y funcionales) que pueden visualizarse a través de la PFCG. Se recomienda crear versiones “custom” o “Z” de estos roles para prevenir que el estado original se vea alterado por los cambios que vayan surgiendo con el tiempo.
Paso 2: Autorizaciones de primer y segundo nivel
Este apartado es importante porque regula los criterios de elegibilidad de un usuario para poder ser asignable a un rol de negocio en la UI de GRC.
El parámetro se regula a través del objeto GRFN_USER y la actividad “16” (Ejecutar), este objeto se encuentra integrado en el rol base SAP_GRC_FN_BUSINESS_USER.
El sistema trae activadas las autorizaciones de primer nivel por defecto.
A efectos prácticos esto significa que, aunque un usuario no tenga un rol técnico asignado en el “back-end”, si tiene asignado el objeto de autorización con la actividad mencionada anteriormente, este podrá ser elegible para ser asignado a un rol de negocio en la UI de GRC.
Para evitar este problema deberemos activar en nuestro sistema las autorizaciones de segundo nivel, gracias a esto si un usuario no tiene el rol técnico necesario en el “back-end” el sistema no lo propondrá como candidato a la hora de asignar un usuario a un rol de negocio a través de la interfaz del NWBC.
La activación del segundo nivel actúa como una capa extra de seguridad que previene errores y limita la responsabilidad de asignar accesos únicamente a los administradores del sistema SAP. Si por el contrario nos interesa que los usuarios finales tengan poder para gestionar los accesos, deberemos de dejar las autorizaciones de primer nivel activadas.
Paso 3: Asignar Roles a Entidades
En este punto deberemos tener en cuenta las siguientes consideraciones:
Todos los usuarios de roles de negocio se asignan a un nivel de entidad relevante (organización, subproceso, control, etc) a través del proceso de configuración. Esto indica al sistema qué roles debe poner a disposición de esos usuarios mediante la relación entidad – usuario.
Los BC Sets que vienen con el sistema SAP asignan forma automática roles de negocio a niveles de entidad correspondientes.
Si a un rol se le marca la casilla de valor único, ese rol sólo podrá ser asignado a un único usuario dentro de esa entidad.
Todo rol personalizado que se cree en el sistema ya sea desde 0 o como copia de uno estándar, debe de ser correctamente configurado para evitar fallos.
Paso 4: Definición de Regulaciones personalizadas
Mediante el “Multi-compliance Framework (MCF)” el sistema nos otorga la posibilidad de manejar las actividades relacionadas con el cumplimiento a través de múltiples regulaciones.
Las regulaciones deben de ser definidas a través del proceso de configuración para que puedan ser asignadas a determinadas entidades y roles.
El sistema trae por defecto las regulaciones SOX y FDA.
Los roles específicos de una regulación se asignan con una combinación de entidades (control, etc.) y regulaciones (SOX, FDA, etc.) configurada previamente a través de la fase configuración.
Esto significa que un rol será asignable a un tipo de entidad y regulación en concreto.
EJ: Rol X para control A con regulación SOX, Rol Y para control B con regulación FDA.
En esta fase se recomienda que los roles generados se restrinjan a regulaciones específicas.
Paso 5: Asignación de usuarios a roles.
Una vez se ha completado la configuración de autorizaciones en el sistema, se puede proceder a la asignación de roles a usuarios finales.
Roles técnicos (“Back-end”)
- Incluyen 3 tipos de roles base.
- Si las autorizaciones de segundo nivel están activadas, serán necesarios las versiones técnicas de los roles.
Roles de negocio (UI de GRC)
Las asignaciones a usuarios se realizarán a las combinaciones de entidades y regulaciones apropiadas.
Conclusiones
En el contexto de SAP GRC Process Control, la estrategia de autorizaciones basada en «Entity-Level Authorizations» se revela como un componente clave para garantizar el acceso controlado a la información en cumplimiento con las regulaciones. Este enfoque permite asignar roles según las responsabilidades de los usuarios, facilitando una gestión eficiente y segura de la conformidad normativa.
La configuración óptima de autorizaciones, a través de la definición de roles, autorizaciones de niveles y regulaciones personalizadas, refuerza la coherencia y la seguridad en las actividades de cumplimiento, al mismo tiempo que empodera a los usuarios a través de interfaces intuitivas como el SAP Net Weaver Business Client.
