Archive for the ‘Transacción’ Category

Seguridad en la ejecución de programas

Friday, June 5th, 2009

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.

VN:F [1.9.10_1130]
Rating: 4.6/5 (5 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 2 votes)

Creación de un rol – ejemplo

Thursday, April 23rd, 2009

La idea en este post es entender un proceso simple de creación de un rol,  cómo asignar una transacción a un usuario, los objetos de autorización correspondientes, etc.

Para hacer esto vamos a crear un ejemplo simple en donde vamos a crear un rol con permisos para administrar usuarios en SAP R/3.

1- Lo primero… Darle un nombre, los nombres de todos lo objetos personalizados o creados por el usuario final en SAP comienzan con la letra Z de manera estándar, la realidad es que podemos utilizar cualquier letra pero agrupar todo tras la Z es una buena manera de identificar los roles propios en caso de tener que realizar un upgrade o por cualquier motivo diferenciarlos del resto, por eso en nuestro caso el rol se llamará Z:PRUEBA (podría haber sido por ejemplo ZUSERS o Z_ABM_USUARIOS, etc). Hacemos click en el botón de Rol Simple y pasamos a la siguiente pantalla:

image

2- Una vez en la próxima ventana podemos asignar una descripción al rol y proseguir a la pestaña de “Menú”, en donde haciendo click en el botón “Transacción” incorporaremos una transacción al Rol y por consiguiente a su menú:

image

3- Una vez hecho el click nos disponemos a escribir el nombre de la transacción que queremos incorporar, también podemos hacer esto desde las opciones de Tomar Menús las cuales incorporaran las transacciones desde los menús estándar de SAP, utilizando su estructura predefinida, pero eso se los dejo para que experimenten ustedes.

image

4- Una vez incorporada la transacción al menú podemos ir a la pestaña de autorizaciones:

image

5- Una vez en el menú de autorizaciones hacemos click en Modificar Autorizaciones, y accederemos a una nueva pantalla, nos preguntará si queremos grabar el rol, esta acción es necesaria para poder tratar los objetos de autorización del mismo con lo cual contestaremos que si. La otra alternativa sería utilizar el “diskette” que se encuentra en la barra superior para grabar nuestro trabaja hasta el momento.

image

6- Una vez estemos en la nueva pantalla (a veces demora),  podemos ver los objetos de autorización agrupados por tipo de objeto.

image

7- Una vez que hacemos click en el símbolo [+] podemos ver el nombre del objeto de autorización (en este caso el primero es S_TCODE) y una breve descripción del mismo. Haciendo otra vez click en el [+] podemos ver los campos y sus valores. En este caso vemos el campo TCD y el valor SU01 que es la transacción que anteriormente agregamos en el menú y con la que automáticamente SAP carga el objeto. Resumiendo las transacciones que agregamos en el menú automáticamente son incluidas dentro de los valores del objeto S_TCODE.

image

8-Debajo de este objeto podemos encontrar 3 grupos más con sus respectivos objetos. Estos objetos de autorización son los que la transacción SU01 verifica en tiempo de ejecución (son los definidos en la transacción SU24, puede que existan más o menos chequeos que los aquí establecidos).

image

9- Tenemos que definir todos los valores de los objetos de manera de hacerlos acorde a la funcionalidad a otorgar. Por ejemplo si queremos brindar solo la posibilidad de visualizar usuarios deberíamos concentrarnos en los objetos S_ADDRESS1 (poder visualizar datos de dirección del usuario) y S_USER_GRP (permisos por grupo de usuarios) definiéndolos con la actividad 03 (visualizar) y la definición del grupo correspondiente o “*” para todos los grupos y el tipo de dirección Bc01.

image

10- Una vez realizadas todas las modificaciones se deben grabar las modificaciones (icono de diskette en la barra superior) y generar los perfiles de autorización correspondientes (ícono generar al lado del tacho de basura)

image image

11- Los otros objetos de autorización no brindan permisos adicionales en el caso de solo querer visualizar los datos de un usuario, pueden hacer la prueba y efectivamente van a ser capaces de usar la transacción SU01, pero hay funcionalidades adicionales que solo pueden ser brindados por estos otros, por ejemplo ver los permisos del usuario (roles) con los objetos S_USER_AGR, S_USER_AUT, S_USER_PRO, etc.

12- Una vez creado el rol puede definirse los usuarios que tendrán asignado el mismo desde dentro de la misma transacción PFCG o el proceso inverso desde la transacción SU01 (ingresando desde el usuario y definiendo los roles para el mismo. Una vez realizada la modificación en la PFCG se debe ejecutar la comparación de usuarios (botón) para que se actualicen efectivamente los permisos en los buffers de usuarios.

image

13- Si fuera el caso de requerir la funcionalidad de bloquear/desbloquear usuarios, por ejemplo, se otorgaría en el mismo objeto S_USER_GRP la actividad 05 y automáticamente una vez generado de nuevo el rol (y en ocasiones una vez que se comparen los roles) el usuario tendría el permiso a realizar esa acción.

El presente actúa a modo de ejemplo y podría tener muchas modificaciones para ser un rol de utilidad, pero la idea es entender como es el proceso de creación de un rol, y que el mismo aplica a roles más complejos y transacciones tanto de Base como de Negocio.

VN:F [1.9.10_1130]
Rating: 4.3/5 (8 votes cast)
VN:F [1.9.10_1130]
Rating: +2 (from 2 votes)

Tips: Bloqueo de Transacciones

Wednesday, April 22nd, 2009

Entre tantas opciones de seguridad que tenemos en la herramienta SAP ECC nos encontramos que tenemos la posibilidad de bloquear el uso de una transacción para todos los usuarios independientemente de sus autorizaciones (siempre y cuando no tengan autorización para desactivar el bloqueo), a través de la transacción SM01, en la misma podemos indicar el código de transacción a bloquear y a partir de confirmar el mismo no se permitirá la ejecución de esa transacción por ningún usuario hasta que no se vuelva a desbloquear.

Esta opción es útil para impedir la ejecución de transacciones que consideremos críticas y no querramos que en ese ambiente nadie ejecute, o tal vez para impedir temporalmente la ejecución de una transacción específica (ocurre durante la ejecución de algunos procesos en batch, o actualizaciones del sistema).

VN:F [1.9.10_1130]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 0 votes)

Tips: Transacciones con asignación manual

Wednesday, March 4th, 2009

Es posible en la transacción PFCG agregar transacciones que no están en el menú de usuario de manera manual directamente en los objetos de autorización.

Es importante saber esto al momento de revisar la seguridad configurada en nuestro sistema SAP para no dejar pasar por alto determinados permisos que no aparecen en el menú de usuario, pero si directamente en el objeto de autorización S_TCODE.

Si nosotros ingresamos a modificar los valores de los objetos de autorización dentro de la transacción PFCG e intentamos incorporar un nuevo valor al campo TCD del objeto S_TCODE vamos a ver que SAP no nos lo permite.

El pequeño truco está en ir al botón titulado “Manualmente” e incorporar en el mismo un nuevo objeto de autorización “S_TCODE” de manera que ahora una nueva línea para el campo TCD aparecerá y esta podremos editarla manualmente.

Es interesante notar que si estamos controlando los permisos de los usuarios a través de tablas y chequeamos la tabla AGR_TCODES, estos que incorporemos no van a aparecer ya que la misma solo muestra las transacciones incorporadas a través del menú del Rol o Grupo de Autorización y tendremos que ir a ver especificamente la tabla AGR_1251 y el campo TCD del objeto S_TCODE o ya a más bajo nivel las autorizaciones propiamente dichas (perfiles).

VN:F [1.9.10_1130]
Rating: 4.0/5 (2 votes cast)
VN:F [1.9.10_1130]
Rating: 0 (from 0 votes)

La seguridad en SAP – Roles y permisos (ejemplo)

Tuesday, February 17th, 2009

En esta entrada vamos a ver un ejemplo de acceso a través de la transacción PFCG (Profile Generator) a un rol o papel, las posibilidades de modificación y su vínculo con perfiles de manera que todo lo que explicamos en las entradas anteriores quede un poco más claro.

1- Una vez logueados en SAP, ingresamos a la Transacción PFCG ingresando su nombre en la barra de ejecución rápida y presionando Enter (Intro) o haciendo click en el tilde verde de la izquierda

image

2- Una vez que ingresamos a la transacción podemos ver como nos muestra su interfaz de usuario a través de la cual si hacemos click en Vistas podemos elegir roles simples para ver en la lista de abajo los primeros doscientos con el criterio seleccionado como Filtro (si es que lo utilizamos)

image

image

3- Una vez que se muestra la lista buscamos el rol que queremos modificar o también podemos escribir directamente su nombre en el campo Rol o utilizar la alternativa de búsqueda del mismo campo a la izquierda (cuadrado gris).

4- Desde estas opciones se puede elegir modificar un rol existente (lápiz), visualizar sus datos (anteojos), crear un nuevo rol simple o uno compuesto.

image

5- Una vez en la pantalla siguiente a través de modificar podemos ver una nueva pantalla con datos de descripción, fecha de creación del rol, última modificación, datos de herencia y otras pestañas con el Menú, la solapa de autorizaciones, Usuarios que lo tienen asignado y dos más de menor utilidad práctica (o habitualidad).

image

6- En la solapa de menú podemos observar las transacciones asignadas al rol a través del menú y en este lugar es donde pueden sacarse o agregarse transacción de manera estándar. Este menú es que el usuario que tenga asignado este rol va a ver a la izquierda de su pantalla cuando ingrese a SAP (en conjunto con otros menús que pueda tener por otro roles)

image

7- En la solapa de autorizaciones se puede ver la información del perfil que utiliza SAP para asignar estas autorizaciones (su nombre empieza con T* siempre) y las opciones de modificar las autorizaciones existentes).

image

8- En la solapa de usuarios se pueden apreciar los usuario que tienen asignado el presente rol, pudiéndose asignar nuevos o eliminar asignaciones existentes. A cada asignación a usuario puede definírsele una fecha de inicio y otra de caducidad para la asignación del rol.

image

La idea de esta entrada era que se aprecie como se maneja un rol (papel o grupo de actividad) en SAP y en una próxima entrada estaremos viendo como ejemplo la creación o modificación de un rol y profundizando más en el tema.

VN:F [1.9.10_1130]
Rating: 5.0/5 (4 votes cast)
VN:F [1.9.10_1130]
Rating: +6 (from 6 votes)