Empezamos con un tipo de post nuevo, donde vamos a ir enumerando entrada tras entrada diversos tipos de riesgos a los que podemos estar expuestos en la plataforma SAP y cuando sea posible las formas conocidas de minimiarlos.
En este primer caso vamos a enumerar uno de los más graves que puede ocurrir, y es el que el existan usuarios que en el ambiente productivo posean permisos para realizar debug o depuración, y a su vez el permiso de modificar el valor de las variables (y en las versiones más nuevas como ECC 6.0, ir a una línea de ejecución específica).
¿Qué es el DEBUG?
El debug o depuración es la capacidad de recorrer línea por línea el código fuente ABAP de la transacción que se ejecuta, en el caso de poseer el permiso en la actividad 02, uno puede a su vez modificar los valores de las variables de los programas.
El riesgo de poseer estos permisos es que prácticamente el usuario que lo ejecute puede saltearse todos los controles de autorización, ya que en el momento de ejecutar una transacción, podría ir paso a paso por el código y cuando sus permisos no le permitieran seguir tras un AUTHORITY-CHECK fallido el podría cambiar ese valor de error, autorizándose a si mismo a continuar.
Un usuario con los permisos adecuado puede acceder al modo debug utilizando en la barra de acceso rápido de SAP el código “/h”.
Este modo de ejecución se permite cuando el usuario posee entre sus roles el permiso al objeto de autorización S_DEVELOP, el cual entre sus campos tiene el valor de ACTVT en 02 (modificar) y el valor de OBJTYPE en “DEBUG“.
Si se da esta condición (sin importar los valores de otros campos, pueden incluso estar vacíos), el usuario puede acceder al modo debug y modificar el valor de las variables.
La manera de evitar este inconveniente es justamente no brindando estos permisos en un ambiente productivo, salvo en un caso excepcional por tiempo limitado y a un usuario específico y nomenclado, para solucionar un error importante en el sistema.
Incluso este tipo de permisos no debiera otorgarse en los ambientes de desarrollo (modificar, el DEBUG común puede realizarse) , ya que también permite vulnerar la seguridad de los mismos y por consiguiente el entorno productivo podría llegar a verse afectado.
Para realizar la búsqueda de quienes tienen permisos para realizar esta acción lo ideal es utilizar la transacción SUIM y buscar los usuarios que posean este objeto de autorización y estos valores de campo.
En un próximo post vamos a hacer una explicación integral del uso de la transacción SUIM (probablemente en más de un post por lo extenso del tema)
Coincido en la cuestión de no dar permisos de debug en ambiente de producción salvo casos excepcionales, pero en desarrollo y calidad tanto funcionales como desarrolladores los deben poseer permanentemente, porque los usan para rastrear problemas.
Ahora, si hablamos de usuarios comunes, no deberían tener directamente acceso a desarrollo, no tiene sentido que así sea, aunque si a calidad, con los mismos permisos que en Producción. La única razón para dar acceso a desarrollo sería en el caso de no disponer de un entorno de calidad, entonces desarrollo funciona como desarrollo/calidad.
Si evidentemente es más incómodo para un desarrollador no contar con los permisos de modificación de variables, pero la realidad es que por otro lado es prácticamente como entregar un SAP_ALL, la realidad es que pueden ejercerse otras medidas de control aledañas y por supuestos concentrar mucho de los esfuerzos en la revisión de las órdenes de transporte que van al entorno productivo. Gracias por participar! Saludos.
Nosotros implementamos GRC- Access control de SAP. Tiene un módulo FireFighter que permite definir y mantener un control del uso de los usuarios bomberos.
La verdad que nos resultó muy útil para este caso de DEBUG y por ejemplo de editar tablas.