¿Cómo funciona la seguridad en SAP?

La seguridad de SAP es algo compleja, eso creo que ya lo dijimos, pero todas las cosas pueden ser complejas hasta que las entendemos. En este post vamos a tratar de lograr eso.

Algunos temas los empezamos a tratar en posts anteriores, pero no el proceso completo que pasamos a relatar.

1- El usuario ingresa en SAP R/3 y se le permite su acceso

2- Se cargan desde el maestro de usuarios los roles que el usuario posee (tablaAGR_USERS), a partir de los mismos se obtienen los perfiles que tienen las autorizaciones para esos roles (AGR_1016). Aunque es altamente probable que el sistemaSAP directamente miré la tabla UST04 (usuarios y perfiles). En caso de perfiles compuestos estos se encuentran definidos en la tabla UST10C. A su vez la relación entre autorización y perfiles está en la UST10S, y por último los valores que se le otorgan a los objetos de autorización se encuentran en la tabla UST12 (probablemente SAP internamente utilice algunas otras tablas o no haga un uso de todas estas, pero es interesante repasarlo porque puede ser de utilidad para ustedes).

3-  Esta información recopilada es almacenada en el buffer del usuario, el cual tiene para cada usuario todas las autorizaciones que el mismo posee cuando está logueado en el sistema, esta información puede consultarse para el propio usuario o para otro distinto mediante la transacción SU56 o si se necesita un mayor

análisis en la tabla USRBF2 (y vínculos a la tabla UST12).

4- A partir de este momento el usuario ya tiene acceso al sistema y todos sus permisos están cargados. El sistema se encuentra a la espera de una acción por parte del mismo.

5- El usuario decide ejecutar una transacción, por ejemplo la FB02 (modificar documento contable).

6- SAP verifica SIEMPRE que el usuario en su buffer posea el permiso para la transacción. Para esto chequea que el objeto de autorización S_TCODE posea el campo TCD y entre sus valores se encuentre el FB02. Este chequeo no depende de la transacción si no que se ejecuta SIEMPRE que una es llamada.

7- Si se posee el valor FB02 se permite la ejecución del código de la transacción y se procede con el mismo, en caso negativo se rechaza automáticamente la solicitud informándole al usuario.

8- Dependiendo de la transacción a ejecutar, la misma puede chequear como primera instancia (antes de la ejecución del código) que se posea un objeto de autorización con un valor determinado para más de un campo. Este objeto, campos y valores se especifican en la definición de la misma a través de la transacción SE93 o la tabla TSTCA donde también pueden consultarse. Este chequeo actúa igual que el del código de transacción y se realiza previo a la ejecución del programa correspondiente a la transacción. En el caso de la transacción FB02 se chequea el objeto F_BKPF_BUK y la actividad (campo ACTVT) con valor 02 (modificación), el campo Sociedad (BUKRS) en esta instancia, no se verifica ya que el valor de chequeo está en blanco). Cabe destacar que no todas las transacciones realizan este chequeo inicial.

9- A partir de este momento se inicia la ejecución del código.

10- El código ABAP de la transacción se ejecuta hasta que dentro del mismo aparezca la instrucción AUTHORITY_CHECK.

11- A través de esta instrucción el programa verifica que los valores especificados para cada campo en la misma se encuentren en el buffer del usuario que la ejecuta. En caso de tenerlos se permite que se continúe la transacción y en caso de ausencia no se permite continuar o se bloquea el acceso a determinada información. Es a decisión del programador de la transacción en que momento se realiza el chequeo, a veces se verifica cuando uno ingresa un valor (por ejemplo la sociedad en la FB02) en donde se verifica el mismo objeto que antes F_BKPF_BUK, pero pidiendo la actividad 02 (modificar) y la sociedad para la cual va a realizarse la modificación (BUKRS).

NOTA 1: Tengamos que cuenta que los campos de un objeto de autorización siempre se verifican en conjunto, quiero decir que la actividad 02 (modificar) solo autoriza a la Sociedad que se encuentra dentro de la misma autorización. Podría ocurrir que dentro de un mismo rol tengamos permiso para modificar una Sociedad pero solo para Visualizar otra. Por eso es importante tener en cuenta que estas son verificadas “en bloque”

NOTA 2: También es importante destacar que es posible y hasta habitual que un usuario tenga más de un ROL asignado, en este caso se produce lo que se conoce como “suma de autorizaciones” y esto quiere decir que los valores solicitados de objetos de autorización pueden encontrarse en cualquiera de los roles que el usuario tiene asignado. Ejemplo: Si en el rol 1 el usuario tiene el acceso a la transacción FB02 (objeto S_TCODE), y en el objeto F_BKPF_BUK la actividad con valor 03 y la sociedad en 0001, pero el programa solicite 02 y 0001 el usuario no podría ingresar a la transacción. Ahora si agregamos un segundo rol al usuario sin ningún objeto S_TCODE pero con el objeto F_BKPF_BUK con valor de actividad 02 y sociedad 0001 el usuario ahora si va a

poder tener acceso a ejecutar esta transacción (el primer rol le da el S_TCODE con FB02 y el segundo el F_BKPF_BUK con actividad 02)

Por último cabe destacar que la transacción FB02 necesita de otros objetos de autorización para ser ejecutada pero el nombrado aquí fue solo a modo de ejemplo. En un próximo post veremos un ejemplo completo.

Perfiles de autorización

En un post anterior explicamos lo que era un Rol   o   Grupo de Autorizaciones, bueno ahora vamos a tratar de explicar que es un Perfil (o Perfil de autorizaciones).

Antiguamente la seguridad de SAP era un poco más rudimentaria que la actual, era manejada mediante Perfiles de Autorización. Los perfiles no tienen una diferencia sustancial conceptual con lo que es un Rol, simplemente las herramientas para trabajar con ellos eran más límitadas (transacciones SU02, SU03).

Básicamente un perfil era un conjunto de autorizaciones, y el pérfil se le asignaba directamente a un usuario.

Ahora porque explicar que es un perfil si lo relatamos en pasado, como algo que ya no existe… porque esto no es tan así… Al margen de las instalaciones más viejas de SAP (4.0 y anteriores), en las versiones actuales SAP trabaja con perfiles por debajo de los roles.

¿Qué quiere decir eso? Que lo que vemos como roles es simplemente una capa superior a la capa de perfiles que está debajo solo que con la complejidad del manejo de perfiles simplificada porque lo hace SAP automáticamente.

Basicamente por cada rol creado pueden existir uno o más perfiles creados automáticamente por SAP que van a ser los que efectivamente nos den las autorizaciones.

Por eso si ustedes van a ver las autorizaciones específicas van a encontrarse que tienen una pestaña de Roles y otra de Perfiles (que su nombre empieza con la letra T y no pueden ser modificados manualmente) a través de los cuales tienen los permisos asignados.

Hasta ahora es bastante anécdótico el motivo por el que explico los pérfiles, pero hay un motivo más profundo, todavía pueden crearse perfiles manualmente y asignarselos a un usuario, o utilizar un perfil creado anteriormente de la misma manera.

Y adicionalmente… existen perfiles que vienen en la instalación de SAP que pueden ser asignados a los usuarios finales y que muchas veces contienen permisos sumamente amplios, como es el caso del famoso perfil SAP_ALL.

El caso específico del perfil SAP_ALL podemos tratarlo en un post separado pero básicamente podemos decir que nos brinda un acceso irrestricto al sistema a través de sus permisos.

Aprovechando la introducción del perfil SAP_ALL puedo contarles que existen a su vezperfiles simples y perfiles compuestos, siendo la diferencia que los segundos son perfiles de perfiles, o perfiles que solamente contienen otros perfiles dentro (con sus consiguientes autorizaciones)

Resumiendo este post… Existen perfiles que son creados automáticamente por SAP (T-*), existen otros que ya vienen con el sistema y poseen autorizaciones sumamente amplias(SAP_ALL), y a su vez los perfiles pueden contener dentro de si otros perfiles (perfiles compuestos).

Uno de los riesgos a tener en cuenta es que por como está dispuesta la pantalla donde uno consulta los usuarios (una pestaña de roles y otra de perfiles) uno puede llegar a confundirse pensando que un usuario no tiene ninguna autorización crítica mirando el contenido de la pestaña de roles, cuando en realidad si uno revisara la pestaña de perfiles uno podría ver que adicionalmente tiene asignado por ejemplo, los permisos de SAP_ALL.

Un error común, algunos pueden llamarlo tonto, pero sepan que puede pasar. Igualmente más adelante vamos a ver maneras más prácticas de revisar los permisos que efectivamente tiene un usuario.

La seguridad en SAP – Roles y permisos

Tema complicado si los hay… explicar como funciona la seguridad en SAP… trataré de hacer lo más simple posible algo lo suficientemente complicado.

Una vez que accedimos a SAP si nuestro usuario no tiene efectivamente ningún tipo de permiso al sistema (solo el acceso) no vamos a poder realizar ninguna actividad sobre el mismo.

La manera de asignar estos permisos es a través de Roles (alias Papeles, alias Grupos de Autorización).

Los Roles, son un medio para permitir que un usuario acceda a una transacción o pueda ejecutar una función determinada dentro de alguna transacción.

Para entender el concepto hace falta explicar el concepto de Objeto de Autorización: Es un objeto que nos brinda SAP como marco para crear Autorizaciones y es la unidad fundamental de la seguridad en SAP.

Un Objeto de Autorización tiene el siguiente formato:

Nombre del Objeto: S_TCODE (Permiso de acceso a las transacciones)Campo: TCD (Código de Transacción)

Este es el objeto por excelencia (S_TCODE), en donde uno determina las transacciones a las que el usuario debería tener acceso. Para ser más claros:

Paso 1: El usuario pfernandez necesita acceder a las transacciones SU01 (ABM de Usuarios) y SU10 (Gestión de Usuarios en Lote)

Paso 2: Ante la necesidad se crea un ROL de nombre Z:GESTION_USUARIOS al cual se le asignan las dos transacciones en el menú a través de la transacción PFCG.

Paso 3: Automáticamente SAP crea una autorización para el rol Z:GESTION_USUARIOS para el objeto S_TCODE, al que le agrega en el campo TCD los valores: SU01 y SU10.

Paso 4: Se asigna al usuario pfernandez el rol Z:GESTION_USUARIOS dándole a través del mismo el acceso a las transacciones SU01 y SU10

Paso 5: El usuario  pfernandez, accede al sistema con su usuario y contraseña y una vez dentro, ejecuta la transacción SU01.

Paso 6: SAP analiza el pedido de ejecución de la transacción SU01, y se fija que entre los permisos de pfernandez se encuentre el objeto de autorización S_TCODE con el campo TCD con el valor SU01. Si es correcto permite el acceso a la transacción.

Cabe destacar que el control del objeto S_TCODE está implícito en SAP y se realiza siempre que se llama a una transacción, por eso el objeto S_TCODE es tan “popular” dentro de la segurida SAP

Esta explicación es a fines educativos solamente, más adelante vamos a ver que la generación de un rol, es mucho más compleja que los pasos seguidos anteriormente, pero da una idea general de como es el proceso.

También recuerden que según la versión de SAP con la que trabajemos a veces pueden llamarse Roles, o pueden ser Grupos de Autorización o en algún lugar también pueden ser Papeles.

Una explicación sobre perfiles la podemos ver en el siguiente post

En un próximo post también, vamos a explicar como es el proceso de autorización completo y con ejemplos de mayor complejidad.

creación de un rol – ejemplo

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:

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ú:

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.

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

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.

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

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.

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).

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.

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)

 

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.

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.