En este artículo revisaremos un caso práctico de escalado de privilegios en SAP®, que es posible aprovechar cuando las nuevas transacciones personalizadas no se configuran correctamente. Las protagonistas de este caso serán las transacciones de parámetros, uno de los tipos más comunes de transacciones personalizadas que podemos identificar en cualquier sistema.
No hay duda de que cualquier sistema SAP® es altamente personalizable y adaptable a las necesidades de cada cliente, en gran parte a esto se debe su éxito. Como parte de las capacidades que SAP® proporciona a sus clientes, es posible la creación de programas y transacciones propias, generadas específicamente para cubrir necesidades que el estándar no ofrece, o adaptarlo a los procesos de negocio del cliente. Una de las formas más simples para esto, es crear transacciones de parámetros. Sin embargo, como veremos, no seleccionar las opciones correctas en su creación puede acarrear serios riesgos de seguridad.
Transacciones de parámetros y sus características:
Las transacciones de parámetros son, a todos los efectos, una parametrización de una transacción ya existente, sea esta estándar o personalizada. Una transacción de este tipo te permite llamar a otra transacción base con valores preasignados en los campos en su pantalla inicial.
Como se puede apreciar en la imagen, las transacciones de parámetros siempre utilizan una transacción ya existente como base, a la cual se le asignan parámetros para acotar ligeramente su funcionalidad.
Uno de los principales usos de este tipo de transacciones es agilizar y automatizar en cierto grado la ejecución, facilitando valores que pueden ser siempre constantes e incluso obligatorios, y también reduciendo la probabilidad de error por parte del usuario.
El otro uso más común, y el más relevante para nuestro caso, será restringir la ejecución de la transacción base únicamente a los valores predefinidos, de modo que el usuario no pueda acceder a la totalidad de la información como podría hacerlo con la transacción base directamente.
Configuración para una restricción correcta:
Las transacciones de parámetro no comprueban autorización a la transacción base, a efectos del sistema se trata de una transacción diferente, pero a efectos prácticos estamos usando la misma transacción base con su misma funcionalidad. Cuando se desea utilizar una transacción de parámetro para restringir la funcionalidad de otra base, se debe poner especial atención a la configuración de esta.
No realizar una configuración correcta, puede invalidar la propia restricción que se desea implementar. Por defecto, al crear una transacción de parámetro esta accederá siempre a la pantalla inicial de la transacción base con los valores preasignados. Sin embargo, el usuario puede decidir no utilizar estos valores propuestos, modificarlos y acceder a un escenario distinto, siempre y cuando tenga autorización para estos otros valores. Por ejemplo, podría acceder a cualquier otra tabla del sistema si la transacción base es la SM30 o SE16. A todos los efectos, será lo mismo que tener acceso directo a la transacción base que se quería evitar.
Para evitar este comportamiento, existe una opción en la configuración de la transacción que permite saltar completamente la pantalla inicial de la transacción base. De esta forma, la nueva transacción se ejecuta únicamente con los valores predefinidos sin posibilidad de acceder a otros escenarios.
Cuando lo que se busca es restringir una transacción base, es primordial asegurar que esta opción está seleccionada.
La aplicación más común para este escenario, es la creación de nuevas transacciones de parámetro para la modificación de tablas personalizadas. Las buenas prácticas aconsejan que se cree una nueva transacción de este tipo para cada tabla (o grupo de tablas) que se desea modificar, en lugar de asignar directamente la SM30 (o SM34) que permite modificar cualquier tabla del sistema. De esta forma se consigue un acceso controlado.
Otro de los riesgos que aparecen con el uso de transacciones de parámetro es la posibilidad de ocultar una funcionalidad crítica dentro de una transacción no identificada. Al crear una transacción con la misma funcionalidad que otra, pero con diferente código y descripción, es posible que los controles establecidos no la detecten y se consiga un acceso no autorizado. Herramientas como los Análisis de Riesgos, o controles como la Revisión de Accesos de Usuario podrían no tener la nueva transacción identificada y por tanto no se detectaría su asignación ni esta se corregiría de ser necesario.
Detección del riesgo en el sistema
Afortunadamente, los riesgos que conllevan el uso de transacción de parámetro son fácilmente mitigables añadiendo chequeos muy simples a los controles establecidos.
Las transacciones de parámetro utilizan la tabla TSTCP para almacenar los parámetros configurados en el campo PARAM. Por tanto, es posible realizar una extracción de todas las transacciones de parámetro del sistema, o de aquellas que consideremos relevantes, y comprobar tanto su configuración como la transacción base que utilizan. En el campo PARAM de la TSTCP, las transacciones de parámetro comienzan siempre por los caracteres /N o /*, seguidos del código de la transacción base usada y los parámetros que se han establecido.
Para el caso en que se desea implementar una restricción de la transacción base, y se quiera comprobar si la opción de saltar la pantalla inicial está activada, debemos asegurar que el valor del campo PARAM para esta transacción comienza con /*. De lo contrario, el valor /N significará que no está activa.
Para detectar aquellas transacciones de parámetro que podrían estar ocultando transacciones críticas, se puede utilizar la misma tabla. El código que sucede a los dos primeros caracteres es precisamente la transacción base usada. Con filtros sencillos se puede comprobar el listado total de transacciones del sistema y cotejarlas contra aquellas ya identificadas por los equipos de seguridad, incluidas en matrices de riesgos o herramientas similares que ayuden al control de acceso.
Puntos Clave:
Como se ha discutido anteriormente, las transacciones de parámetro permiten utilizar la funcionalidad de cualquier otra transacción. Por esto, y por la propia facilidad de creación y uso, se deben tener en cuenta en la gestión de accesos y riesgos de cualquier sistema SAP®.
En este artículo se han comentado dos riesgos derivados del uso de estas transacciones: acceso no limitado al no configurarse correctamente la transacción y la posibilidad de ocultar una funcionalidad, pero también se han dado recomendaciones para mitigarlos.
- Asegurar que se aplica la opción de saltar pantalla inicial, revisando el campo PARAM de la tabla TSTCP comienza por el valor /* para las transacciones correctamente restringidas.
- Extraer y evaluar las transacciones base que se utilizan en el campo PARAM de la tabla TSTCP para detectar transacciones críticas.
De la misma forma, también se recomienda siempre tener un proceso robusto de análisis de nuevas transacciones creadas en cualquier sistema SAP®. Las recomendaciones indicadas deben ser parte integral de este análisis, donde se revise siempre la seguridad del código o la configuración de la transacción, pero también los riesgos que puede generar a nivel de funcionalidad con el objetivo de actualizar la matriz de riesgos del sistema si fuera necesario, previo a su paso a productivo.