Conjuntos de reglas en SAP Access Control

Para comprender cómo se produce un riesgo empresarial, debe comprender la metodología que siguen tanto SAP Access Control como SAP Cloud Identity Access Governance para identificar un riesgo por sus componentes.

Uno o más riesgos comerciales se pueden agrupar en un conjunto de reglas. Esta publicación de blog cubre la arquitectura de un conjunto de reglas y sus componentes para que pueda comprender por qué se muestra un riesgo. Como administrador de roles, a menudo los rediseños de roles son provocados por SoD y violaciones de acceso críticas que causan fallas en las auditorías. Por lo tanto, es imperativo comprender cómo leer y procesar un conjunto de reglas.

Componentes del conjunto de reglas

Un conjunto de reglas es donde las reglas se definen en relación con códigos de transacción específicos de SAP que están/no están permitidos para la asignación a los usuarios. Para los riesgos de SoD, las reglas pueden definir qué combinaciones de transacciones no están permitidas. Las reglas también definen qué transacciones son de naturaleza crítica, lo que puede comprometer potencialmente la confidencialidad de los datos, la integridad del sistema o de los datos o la disponibilidad del sistema.

Control de acceso SAP utiliza estas reglas para evaluar usuarios, roles y perfiles para identificar el acceso que podría conducir a infracciones. Tales infracciones (conflictos o infracciones) pueden encontrarse en roles (debido a combinaciones de transacciones encontradas en un rol), a nivel de usuario (debido a combinaciones de roles y, por lo tanto, combinaciones de transacciones asignadas al usuario), a nivel de perfil (debido a autorizaciones conflictivas dentro de un mismo perfil, por ejemplo, SAP_ALL), o en el nivel de puesto de RRHH (acceso indirecto a través del módulo de RRHH).

Un conjunto de reglas consta de los siguientes componentes:

Riesgos de acceso

Un riesgo de acceso es una o más acciones o permisos que, cuando están disponibles para un solo usuario (o un solo rol, perfil u objeto de recursos humanos), crean la posibilidad de fraude o errores no intencionales. Un riesgo de acceso consta de una o más funciones dependiendo del tipo de riesgo. Están disponibles los siguientes tipos de riesgo:

• Acción crítica: Los riesgos de acción crítica consisten en transacciones que se consideran críticas. Tiene opciones para ejecutar el análisis de riesgos tanto en el nivel de acción como en el nivel de permiso. Los riesgos de acción crítica se crean con una sola función.
• Permisos críticos: Los riesgos de permisos críticos consisten en objetos/permisos de autorización que se consideran críticos. Los riesgos de permisos críticos se crean con una sola función, que no puede contener transacciones.
• Riesgos de SdD: Los riesgos de SoD consisten en transacciones en conflicto junto con sus objetos de autorización y valores que se consideran críticos. Los riesgos de SoD se crean con dos o más funciones. Cada función se combina con el operador OR.

Un ejemplo de una infracción de SoD común ocurre cuando la capacidad de crear datos maestros de proveedores y la capacidad de procesar pagos de cuentas por pagar pertenecen a un mismo rol. Este conflicto de SoD en particular describe los riesgos que surgen cuando a una sola persona se le permite crear un proveedor (ficticio), incluido el mantenimiento de su información de pago, y luego puede generar pagos (fraudulentos) a ese proveedor.

Funciones

Una función, en términos de gobierno, riesgo y cumplimiento, se puede definir como una tarea que se ejecuta en SAP, por ejemplo, mantenimiento de órdenes de compra o mantenimiento de datos maestros de proveedores. Una función es un contenedor en el conjunto de reglas para albergar todas las diversas transacciones que un usuario podría ejecutar para ejecutar una tarea en particular. por ejemplo, en ERP de SAPLas Transacciones ME21N (Crear Orden de Compra) y ME22N (Mantener Orden de Compra), entre otras, pueden ser utilizadas para la tarea de mantenimiento de órdenes de compra y por lo tanto se encontrarían en la función correspondiente.

Además de definir las transacciones que un usuario podría ejecutar para ejecutar una tarea, la función también contendrá una definición de todos los objetos de autorización y valores de autorización que se requieren para ejecutar cada transacción. Este detalle es necesario para establecer completamente si un rol o un usuario tiene todo el acceso necesario para ejecutar una transacción. Si no lo hacen, entonces la transacción no se puede ejecutar y, por lo tanto, se minimiza el riesgo de incumplimiento.

Arquitectura del conjunto de reglas

La siguiente figura muestra la arquitectura sistemática de un conjunto de reglas con sus componentes. Nuestro ejemplo involucra dos riesgos de SoD, que consisten en dos funciones cada uno. Las funciones pueden estar involucradas en uno o más riesgos. En este ejemplo, Business Risk 1 se define a través de las funciones Business Function 1 y Business Function 2. Una función se define a través de transacciones (Acciones) y autorizaciones (Permisos). Cada acción se define con permisos. Por ejemplo, la transacción SU01 requiere que el objeto de autorización S_USER_GRP tenga los valores ACTVT 01, 02, 05 o 06 para que la transacción se considere crítica. Por lo tanto, en el conjunto de reglas, si esta transacción es parte de una función para la gestión de usuarios, la transacción y sus valores de autorización se mantienen. Entonces se crea un riesgo cuando, en cada función, se encuentra al menos una acción con un permiso.

La siguiente figura muestra un ejemplo de un conflicto de SoD común desde una vista comercial. En este ejemplo, el SoD «Mantener órdenes de compra versus gestionar entrada de mercancías» se define a través de un riesgo de acceso (del tipo SoD). El riesgo de acceso contiene dos funciones: Mantener Órdenes de Compra y Administrar Entrada de Mercancías. Cada una de estas dos funciones se han definido con acciones y permisos.

Cuando se ejecuta un análisis de SoD, el SoD se produce cuando se encuentra una de las reglas. La regla representa cada combinación individual de SoD que es posible en este escenario. Como se muestra en la figura anterior, ambas funciones se definen con dos transacciones, lo que requiere cuatro reglas.

Al cambiar el conjunto de reglas en SAP Access Control, debe ejecutar el trabajo GRAC_GENERATE_RULES para generar todas las reglas de combinación posibles a través de Transaction SPRO. Navegar a GRC > Control de acceso > Análisis de riesgos de acceso > Reglas de SOD > Generar reglas de SOD. Sin la generación de reglas, los cambios de contenido en el conjunto de reglas no estarán disponibles para su análisis. Por lo tanto, recomendamos programar el trabajo para que las reglas de actualización se ejecuten con frecuencia.

Consejo: El número de reglas definidas para un riesgo está determinado por a) el número de combinaciones de acciones yb) las combinaciones de permisos/valores de campo contenidas en cada función del riesgo. Para obtener más información, consulte http://s-prs.co/v203613.

Conjuntos de reglas estándar de SAP

SAP ofrece conjuntos de reglas estándar de la industria con SAP Access Control que contienen amplios conjuntos de SoD conocidos y riesgos críticos. La siguiente tabla proporciona una descripción general de los conjuntos de reglas disponibles en SAP Access Control 12.0.

Puede consultar los conjuntos de BC disponibles y activarlos en la Transacción SCPR20.

Los conjuntos de reglas estándar de SAP forman la base del conjunto de reglas del cliente. Durante la personalización de su conjunto de reglas, debe identificar sus procesos comerciales y ajustarlos en consecuencia. SAP recomienda crear funciones personalizadas y riesgos de acceso en el espacio de nombres de su cliente (p. ej., comenzando con «Z») y no modificar en absoluto los objetos estándar entregados previamente. Este enfoque también le permite actualizar (reimportar los conjuntos de BC) las reglas estándar y luego comparar el estándar con sus personalizaciones.

En SAP Cloud Identity Access Governance, SAP proporciona conjuntos de reglas estándar para varios sistemas de destino (SAP ERP, SAP S/4 HANA, SAP Fiori, Factores de éxito de SAP, SAP Aribaetc.) que debe solicitarse a través de un ticket de incidencia en SAP Support Portal.

Nota SAP 2782388: Nota de SAP 2782388: IAG – Cómo cargar el conjunto de reglas estándar predeterminado explica cómo puede solicitar que los conjuntos de reglas estándar se carguen en SAP Cloud Identity Access Governance.

Reglas de organización

Las reglas organizativas en SAP Access Control se utilizan para eliminar los falsos positivos en los informes de SoD en función de las restricciones de nivel organizativo para los usuarios. Las reglas organizacionales no deben crearse para informes masivos a nivel de organización; Las reglas organizativas solo deben habilitarse para las funciones que necesita segregar específicamente. La mayoría de las empresas controlan a qué datos tiene acceso un usuario a través de la asignación de funciones.

Las reglas organizativas le permiten filtrar los falsos positivos del análisis de riesgos. Los falsos positivos en el contexto de las reglas organizacionales se producen cuando el análisis de riesgo no considera los niveles organizacionales. Por ejemplo, un usuario puede mantener datos maestros para el código de empresa A y realizar una contabilización para el código de empresa B. Sin respetar los valores de la organización, este escenario puede implicar un conflicto de separación de tareas, ya que una persona puede mantener datos maestros y también contabilizar transacciones.

Para profundizar en este tema, supongamos, por ejemplo, que tenemos los siguientes roles:

• Rol A: Z_ROLE_A_1000 para la sociedad 1000 con acción FB60.

• Rol B: Z_ROLE_B_2000 para sociedad 2000 con acción FK02.

El rol A contiene la transacción FB60 (contabilización de facturas de proveedores) para la sociedad 1000, mientras que la función B contiene la transacción FK02 (cambio de datos maestros de proveedores) para la sociedad 2000.

La combinación de Transacción FK02 y Transacción FB60 con sus permisos constituye un riesgo de SoD ya que la publicación de facturas de proveedores y el cambio de datos maestros de proveedores no deben ser realizados por la misma persona. Un usuario que recibe estos dos roles tendría asignadas ambas transacciones y, por lo tanto, el análisis de riesgo mostrará un riesgo. Sin embargo, este riesgo no es realmente un riesgo ya que el mismo individuo está limitado en sus acciones por el nivel organizacional (código de la compañía). Este resultado es un falso positivo y, al utilizar las reglas de la organización, puede asegurarse de que estos escenarios no se notifiquen como riesgos durante el análisis de riesgos.

En la mayoría de los casos, las reglas organizacionales se crean para riesgos individuales, pero no para todos los riesgos. Esta limitación se debe principalmente al posible impacto en el rendimiento que provoca el análisis de reglas organizativas.

Simulación de riesgos durante la creación de roles con el terminador de riesgos

Risk Terminator es un componente entregado automáticamente con SAP Access Control. Con el módulo de análisis de riesgo de acceso, el análisis de riesgo debe realizarse manualmente para cada cambio de rol/usuario. Pero, ¿y si se asigna un rol crítico al usuario sin realizar un análisis de riesgo? ¿Qué sucede si se agregan códigos de transacción críticos como Transactions SCC4, PFCG y SPRO a un rol recién creado o a un rol existente?

Risk Terminator proporciona la capacidad de mantener los sistemas SAP libres de riesgos. Ejecutándose en segundo plano, aparecerá una ventana emergente cuando se asigne un rol en las Transacciones SU01, SU10 y PFCG o cuando una modificación de rol en la Transacción PFCG pueda causar un riesgo. Risk Terminator reside en el sistema ABAP backend y utiliza el módulo de análisis de riesgo de acceso para ejecutar un análisis de riesgo ad-hoc. Dependiendo de la configuración, Risk Terminator puede funcionar como detective (informando sobre violaciones de acceso) o como preventivo (el sistema evitará que se introduzcan violaciones en los roles).

Cada vez que se realiza un cambio en un rol de SAP existente o se crea un nuevo rol, Risk Terminator verifica el contenido del rol. Con Risk Terminator, un administrador de roles puede remediar de inmediato las infracciones de acceso durante el desarrollo de los roles y, por lo tanto, desempeñar un papel importante para garantizar que el sistema se mantenga limpio (al evitar que se introduzcan infracciones en primer lugar). En este escenario, el Terminador de riesgos se utiliza en el sistema de desarrollo (DEV). También puedes utilizar el Terminador de Riesgos al momento de asignar roles a los usuarios, una poderosa característica en tu sistema productivo (PRD). Al verificar las asignaciones de roles, Risk Terminator ejecuta una simulación y muestra todos los riesgos en el nivel de usuario (similar a un flujo de trabajo ARM). Como administrador de seguridad, también puede mitigar el riesgo si no se puede evitar.

En el área de desarrollo de roles, el Terminador de riesgos puede ser un activo valioso para un administrador de roles en la prevención de conflictos de separación de tareas y la introducción de infracciones de acceso confidenciales en los roles.

Como ejemplo final, puede usar el Terminador de riesgo en su DEV para escanear los cambios de roles contra el conjunto de reglas para evitar introducir riesgos en los roles. También puede usar Risk Terminator en su PRD para simular asignaciones de roles a través de Transacciones SU01, SU10 y PFCG para evitar introducir riesgos a los usuarios.

Nota del editor: Esta publicación ha sido adaptada de una sección del libro. Autorizaciones en SAP S/4HANA y SAP Fiori por Alessandro Banzer y Alexander Sambill.