A la hora de asegurar un sistema, un factor importante es la ejecución de procesos de fondo en SAP.
La posibilidad de ejecutar procesos de fondo es agradecida por muchos usuarios, y administradores ya que permite descargar los workprocess de diálogo de tareas pesadas para el sistema, pero que no necesitan una mayor interacción con el mismo.
De esta manera, procesos de cálculo, queries, largos reportes, etc, son ejecutados desde la SM36/SM37 o desde el menú de los mismos cuando lo permiten.
Para poder ejecutar procesos batch es necesario contar con el objeto S_BTCH_JOB, el cual tiene como opciones en su campo:
DELE – Eliminar jobs de fondo
LIST – Visualizar órdenes SPOOL creadas mediante job
PLAN – Copiar o repetir jobs
PROT – Visualizar logs de proceso de job
RELE – Liberar jobs (se realiza automáticamente si se planifica)
SHOW – Visualizar cola de jobs
Estas opciones deben configurarse funcionalmente a la necesidad del rol, aunque probablemente no sean para usuarios comunes los permisos de PLAN, DELE y la autorización de RELE puede estar segregada en el administrador del sistema. (Los usuarios planifican un job, y el administrador lo libera cuando considera que el sistema tiene menos carga)
También tenemos el objeto S_BTCH_ADM, que solo tiene las posibilidades de Yes y NO (Y/N), lo cual brinda autorización cross mandantes, y todos los permisos, la cual solo debe asignarse a administradores de de corresponder.
Y por último, uno que nos resulta interesante a la hora de revisar la seguridad es el S_BTCH_NAM. Este curioso objeto nos brinda la posibilidad que los jobs que nosotros creemos sean ejecutados por otro usuario, especificamente puede ser cualquiera de los usuarios que enumeremos en este objeto (seleccionable a la hora de crear el job, por parte del usuario).
Este objeto es de especial importancia, ya que en caso de poseerlo, nos permitiría ejecutar un proceso de fondo con permisos que no son los nuestros, y claramente el riesgo está en que es una práctica común utilizar un usuario con amplios permisos como BATCH, de manera que no “de errores”.
De esta manera un usuario podría ejecutar reportes para los que habitualmente no tiene permiso en forma batch y consultar el spool resultante del mismo.
En caso de requerirse este tipo de ejecución “impersonada”, los permisos deberían estar correctamente restringidos, para las necesidades específicas de la organización.
