
*imagen1
Introducción: Las empresas siempre están evolucionando sus operaciones para mantenerse al día con las necesidades del mercado. La mayoría de las veces, surgen requisitos especiales que requieren una codificación personalizada para satisfacer las necesidades comerciales. Los clientes de SAP pueden implementar una codificación especial a través del lenguaje ABAP (en forma de transacción personalizada) para agregar nuevas funciones al sistema que no están disponibles en la plataforma estándar. Como resultado, pueden crear involuntariamente lagunas de seguridad que hacen que los entornos de SAP sean susceptibles a los ataques cibernéticos. Un código ABAP eficiente para una transacción personalizada debe contener elementos que puedan proteger contra amenazas a la seguridad, como usuario y contraseña codificados, relevancia de riesgo de césped, codificación ABAP de incumplimiento de sap, etc. Posteriormente, se debe determinar si tales transacciones personalizadas necesitan incluirse en la matriz de riesgo de SoD.
Este blog es más una lista de verificación que analiza las consideraciones clave que debe tener antes de agregar un código de transacción personalizado a un conjunto de reglas en GRC, para garantizar que su sistema permanezca seguro y que los riesgos se controlen con precisión mientras opera con la máxima eficiencia.
Suposiciones: Está familiarizado con la configuración de las funciones y los riesgos de SOD en el conjunto de reglas de SAP GRC, o tiene una comprensión básica del mismo.
Análisis de transacciones personalizadas desde el punto de vista de la seguridad:
a) Lo primero es lo primero, siempre asegúrese de tener una mirada minuciosa a los documentos de especificación funcional (FS) y/o especificación técnica (TS) para obtener una comprensión clara de la transacción personalizada y sus funcionalidades.
b) Verifique si el programa desarrollado para el código de transacción personalizado tiene las declaraciones AUTHORITY-CHECK para proteger los datos y la lógica comercial junto con la lógica del código de retorno (SY-SUBRC). La lógica de devolución se utiliza para devolver la transacción a un estado coherente cuando se deniega el acceso a un usuario. A continuación se muestra un ejemplo de una instrucción AUTHORITY-CHECK con la lógica de devolución en un programa estándar de SAP:
El programa asociado con una transacción personalizada también se puede identificar de las siguientes maneras:
C) Asegúrese de que la configuración de SU24 se realice y contenga todos los objetos de autorización que se llaman en el código de programa. Verifique lo mismo usando el programa “RS_ABAP_SOURCE_SCAN”.
Repitiendo el hecho obvio, los objetos de autorización con el indicador de cheque como «Cheque» y el valor de la propuesta como «Sí» en SU24, se agregarán automáticamente a los roles de PFCG cuando la transacción correspondiente se agregue al menú de roles. Asegúrese de que estos objetos estén incluidos en las sentencias AUTHORITY-CHECK del programa personalizado.
d) Se recomienda ejecutar la transacción por su cuenta en el entorno de Desarrollo o Prueba, solo para validar que funciona de la misma manera que se menciona en el documento de Especificación funcional y para descartar cualquier excepción adversa.
mi) Determine si la transacción personalizada está actualizando registros en una tabla específica en SAP o es solo una transacción de informe. Con base en este análisis de sensibilidad, se puede decidir si la transacción personalizada debe incluirse en la matriz SOD o no.
F) El Launchpad de Fiori se ha convertido con el tiempo en la interfaz principal para los usuarios, por lo tanto, es necesario verificar si hay alguna aplicación de Fiori asociada con la transacción personalizada que se haya configurado para que sea accesible en el Launchpad de Fiori, que a su vez tendrá que agregarse a la matriz SOD.
Si está interesado en obtener más información sobre cómo incorporar aplicaciones y servicios de Fiori en el conjunto de reglas de SOD, consulte el blog de SAP: https://blogs.sap.com/2021/07/12/how-to-incorporate-sap-fiori-appfapp-and-servicesvc-in-the-ruleset./
gramo) También se recomienda consultar con su Equipo de Administrador del Sistema (Equipo BASIS) para realizar un análisis de rendimiento en el código de transacción personalizado para evitar cualquier problema potencial de rendimiento del sistema.
h) En este momento, debemos haber identificado el proceso comercial asociado con la transacción personalizada y la funcionalidad que habilita en el sistema. El siguiente paso es buscar la función SOD que mejor se ajuste en GRC para poder agregarle la transacción personalizada, sus permisos junto con la aplicación Fiori y los servicios (si corresponde). Si no se puede encontrar una coincidencia adecuada, es mejor crear una nueva función SOD y luego asignarla al riesgo con el que está en conflicto. Por supuesto, esto debe hacerse en consonancia con los administradores de riesgos y/o el equipo de cumplimiento de SOD.
i) Conozca la audiencia prevista para esta transacción personalizada para que se pueda realizar un análisis de riesgo inicial en este conjunto de usuarios (y roles también) y los resultados se puedan compartir con el equipo de cumplimiento para su evaluación y revisión de los riesgos generados recientemente en el entorno.
Conclusión: La adición de códigos de transacción personalizados en un conjunto de reglas de GRC es una forma eficaz de ampliar la funcionalidad del sistema SAP para identificar nuevos riesgos asociados que ocurren en roles y usuarios. Sin embargo, se debe tener cuidado al implementar este procedimiento, asegurando que las nuevas definiciones de riesgo en la matriz SOD sean precisas. En este blog, hemos discutido las consideraciones que deben hacerse antes de agregar un código de transacción personalizado a un conjunto de reglas en SAP Access Control, para proteger adecuadamente el entorno de SAP.
Por favor, no olvide proporcionar sus comentarios y comentarios 😊
** Las capturas de pantalla del sistema que se muestran en este blog son datos de muestra y solo tienen fines de referencia. Cualquier parecido con datos reales es pura coincidencia.
*imagen1 cortesía – blogs.sap.com
Calle Eloy Gonzalo, 27
Madrid, Madrid.
Código Postal 28010
Paseo de la Reforma 26
Colonia Juárez, Cuauhtémoc
Ciudad de México 06600
Real Cariari
Autopista General Cañas,
San José, SJ 40104
Av. Jorge Basadre 349
San Isidro
Lima, LIM 15073