A la hora de asegurar la ejecución de actividades sobre el sistema SAP habitualmente nos acordamos de restringir el acceso a determinadas transacciones, objetos de autorización, etc.
Pero muchas veces, por necesidades incorrectamente satisfechas al momento de la implementación, o por un apresurado mantenimiento del código, entre otras posibilidades, quedan puertas abiertas que podrían permitir la ejecución de actividades no deseadas en el sistema.
Personalmente, pienso que muchas de estos permisos se dan por inconsciencia, o desconocimiento de lo que se está autorizando por parte de los dueños o responsables de los datos. Ya que ellos conocen la información que quieren restringir, pero no conocen los medios por los que se puede acceder a la misma. Cuantas veces uno habrá escuchado: “Los sueldos solo los pueden ver un grupo reducido de personas”, y por otro lado se entregan los permisos de visualización de tablas indiscriminados, el debug con modificación de variables, la ejecución libre de programas, entre tantos otros.
Hablando de estas posibilidades, una de ellas es la de permitir la ejecución directa de programas en el ambiente de producción. Para muchos puede sonar a una atrocidad, pero otros probablemente digan que ven esa posibilidad habitualmente habilitada en su sistema.
Principalmente estamos hablando de las transacciones SA38 y SE38.
A veces encontramos que los programadores pueden acceder a producción con estos permisos, otras veces los parametrizadores, e incluso otras veces hasta los usuarios finales, con el inocente fin de poder “Ejecutar un reporte”.
El primer tema a plantear a la hora de resolver estos inconvenientes es el de que todo desarrollo para ser ejecutado en un ambiente productivo debería tener asignado un código de transacción. Como adminsitradores de seguridad deberíamos exigir el cumplimiento de esto, más siendo que la tarea de utilizar la transacción SE93 para crear un código no demanda más de 1 minuto. De esta manera podríamos restringir la ejecución de cualquier programa como si una transacción estándar se tratara.
Ahora el segundo caso es cuando no podemos lograr esto, ya se por falta peso de nuestro sector, o porque las necesidades organizacionales son otras (casos puntuales, ejecución de programas estándar, pedidos ridículos pero con suficiente peso, etc). Ante esta situación lo ideal es no brindar permisos excesivos.
La ejecución de programas está restringida por el objeto S_PROGRAM, el cual tiene un “grupo de autorización de programas” y un código de acción posible (SUBMIT – Ejecutar un programa, BTCSUBMIT – Ejecutar como proceso de fondo, VARIANT – Ejecutar con una variante)
Lo primordial es la utilización de este grupo de autorizaciones, el cual puede definirse en la misma transacción SE38 a la hora de crear el programa. Pero hay que tener en cuenta que un número importante de programas estándar de SAP NO TIENEN GRUPO DE AUTORIZACION ASIGNADO, permitiendo así la ejecución de los mismos con sin chequear el campo de grupo. En este caso existe un programa estándar que permite el mantenimiento masivo de los grupos de autorización llamado SREPOAUTH.
También hay que tener en cuenta que los programas pueden ser ejecutados como proceso de fondo (de no tener las transacciones SA38/SE38) con las transacciones SM36/SM37, las cuales también hay que prever, sobre todo para quienes tienen permisos para la ejecución de procesos de fondo.
De esta manera tenemos bastante herramientas para restringir la ejecución de programas ante distintas circunstancias que se nos planten, en el trabajo cotidiano.
