SEGURIDAD SAP R/3

Pgina 1 de 49

Tabla de Contenidos
0-OBJETIVO ............................................................................................................................................. 3 1-ALCANCE ............................................................................................................................................... 3

1.1-A QUIEN VA DIRIGIDO? ........................................................................................................................ 3

2-INTRODUCCIN ................................................................................................................................. 4

2.1-GRUPO DE ACTIVIDAD .......................................................................................................................... 4 2.2-GRUPO DE ACTIVIDAD DERIVADO ......................................................................................................... 4 2.2-ROL .................................................................................................................................................... 5 2.2-ROL COMPUESTO ................................................................................................................................. 5
3-INTERACTUANDO CON EL SISTEMA ........................................................................................... 6

3.1-PFCG ................................................................................................................................................. 7
3.1.1 3.1.2 3.1.3 Nomenclatura de GA .............................................................................................................. 8 GA - Simple............................................................................................................................. 9 Solapa MENU ....................................................................................................................... 10 Asignacin de transaccin Modo estndar .......................................................... 11 Asignacin de transaccin Desde el men de SAP............................................... 12 Asignacin de transaccin Desde un GA ............................................................. 14 Asignacin de transaccin Desde un archivo TXT ............................................... 19

3.1.3.1 3.1.3.2 3.1.3.3 3.1.3.4 3.1.4 3.1.5 3.1.6

Solapa AUTORIZATIONS .................................................................................................... 20 Niveles Organizacionales ..................................................................................................... 22 Solapa USERS ...................................................................................................................... 28 Asignacin de usuario ............................................................................................. 28 Desafectar usuario de un GA .................................................................................. 30 Desafectar usuarios de un GA en modo masivo ...................................................... 31 Datos bsicos de usuario......................................................................................... 32

3.1.6.1 3.1.6.2 3.1.6.3 3.1.6.4 3.1.7

GA - Derivado ...................................................................................................................... 33 Modificacin de un GAD ......................................................................................... 35 Autorizaciones distribuidas ..................................................................................... 37 Problemas en las Autorizaciones ............................................................................ 41 Otras funciones........................................................................................................ 44

3.1.7.1 3.1.7.2 3.1.7.3 3.1.7.4

3.2-SU53 ............................................................................................................................................... 46
3.2.1 3.2.2 Ejecutando SU53 para transacciones................................................................................... 46 Ejecutando SU53 para autorizaciones ................................................................................. 48

Pgina 2 de 49

0-Objetivo
Demostrar el funcionamiento de la herramienta para entender en que sitio del sistema impactan los cambios que se desarrollan en los grupos de actividad asociados a los usuarios.

Medir el impacto de las autorizaciones y entender los conceptos de segregacin de funciones.

1-Alcance
Este curso pretende llegar a la mnima granularidad en lo que respecta a la seguridad de SAP R/3, pasando por las herramientas estndar de creacin de grupos de actividad, informes de auditoria de seguridad, tablas de seguridad y funcionales, parmetros bsicos de usuarios, creacin de usuarios, definicin de roles, etc.

1.1-A quien va dirigido?

Este curso va dirigido aquellas personas que se estn iniciando en la seguridad de SAP R/3 y, en una segunda etapa, aquellos administradores con conocimientos bsicos de las herramientas estndar del sistema.

Pgina 3 de 49

2-Introduccin
En principio veamos algunos conceptos bsicos que demos tener en cuenta sobre la teora de seguridad en SAP R/3. Estos conceptos nos sern de gran ayuda a lo largo del curso, ya que con estos conceptos daremos la totalidad del curso.

A continuacin, abarcaremos los conceptos de Grupo de Actividad, Grupo de Actividad Derivado, Rol, y Rol compuesto. Para ello daremos la definicin de cada uno de ellos con el fin de tengamos bien en claro como es realmente cada uno de estos.

2.1-Grupo de actividad
El grupo de actividad, tambin denominado errneamente ROL, nos es ms que un sub.-conjunto de un rol. El mismo, posee una pequea porcin de las funciones que desempeara un recursos o puesto de trabajo (Varios recursos).

Entonces cuando hablamos de un GA (Grupo de Actividad), podemos relacionarlo con el string de caracteres que cargamos en la transaccin PFCG para realizar un alta, baja o modificacin del mismo. La transaccin PFCG ser explicada en captulos posteriores

2.2-Grupo de actividad derivado

El grupo de actividad derivado, es, jerrquicamente hablando, sbdito del GA (Grupo de actividad). El mismo, posee las autorizaciones en funcin del GA padre, vale decir, que si el GA padre posee diez (10) transacciones, el GA derivado poseer los objetos de autorizacin chequeados por la transacciones del GA padre.

En un esquema ordenado, la autorizaciones debern estar en los GA derivados y la transacciones en los GA padre. El GA padre nunca deber poseer autorizaciones salvo una excepcin que es cuando se quiere limitar por niveles organizacionales.

Un ejemplo de GAD puede ser: ZAR_E_CO:FI:GRTE_GRAL

Pgina 4 de 49

2.2-Rol
Un Rol, es un conjunto de GADs agrupados para desempear una funcin preestablecida. Esta funcin nace de un anlisis funcional y de proceso que no abarcaremos en este curso.

Un ejemplo de Rol puede ser: GERENTE

2.2-Rol compuesto
Un rol compuesto, es un conjunto de Roles o GAD para realizar una tarea CROSS o abarcativa de varios puestos de trabajo. Los Roles compuestos son muy difciles de mantener dado que se crean con un propsito especifico y terminan siendo alterados por el desconocimiento del proceso, o por directrices mal gestionadas.

Pgina 5 de 49

3-Interactuando con el sistema

En esta seccin vamos a ver las distintas transacciones que involucran a la seguridad en SAP R/3. Algunas de ellas son de impacto directo, mientras que otras son de investigacin en forma indirecta a la seguridad.

Las transacciones a utilizar sern las siguientes:

1. PFCG (Profile Generador) 2. SU01 (Gestin de usuarios) 3. SU10 (Gestin de usuarios en masa) 4. SU53 (Datos de autorizacin para usuario) 5. SU56 (Autorizaciones en el buffer del usuario) 6. SU24 (Chequeo de objetos para transaccin) 7. SE10 (Liberacin de ordenes de transporte) 8. SE16 (Browser de tablas) 9. SE37 (Programas del sistema) 10. STMS (Sistema de transportes)

Las tablas que utilizaremos sern las siguientes:

1. ADCP (Datos de usuario) 2. ADRP (Datos de usuario) 3. AGR_DEFINE (Definicin de GA) 4. AGR_USERS (Usuarios por GA) 5. AGR_TCODES (Transacciones por GA) 6. AGR_1016 (Autorizaciones por GA) 7. AGR_1251 (Datos de autorizaciones) 8. AGR_1252 (Niveles organizacionales en autorizaciones) 9. AGR_AGRS (Jerarqua de GA (Roles Compuestos)) 10. TACT (Descripcin de actividades) 11. TOBJ (Objetos del sistema) 12. TSTCA (Transacciones con valores estndar por objeto) 13. TSTCT (Descripcin de transacciones) 14. USR02 (Usuarios del sistema) 15. USR05 (Parmetros de usuarios del sistema)

Pgina 6 de 49

16. USR21(Datos de usuario) 17. USOBT (Objetos chequeados por transacciones (Standard)) 18. USOBT_C (Idem anterior (Copia))

3.1-PFCG
La transaccin PFCG (Profile Generador), es utilizada generalmente para la creacin de GA, asignacin de autorizaciones y eventualmente asignacin de usuarios al GA creado o modificado. Tambin se utiliza para remover usuarios de los GA indicados por personal jerrquico.

Dicha transaccin, tiene muchas mas funcionalidades que sern vistas a los largo de este punto.

En la figura 1 observaremos la pantalla de inicio de la transaccin.

Figura 1

Como podemos observar, en la pantalla principal de la transaccin, adems de tener mltiples opciones, podemos crear, modificar, visualizar o borrar un grupo de actividad.

Pgina 7 de 49

3.1.1

Nomenclatura de GA

Tanto para la creacin de nuevos GA, como transacciones, objetos de autorizacin, etc., SAP, deja a disposicin de los usuarios las letras Y y Z para el comienzo de la denominacin de algunas de las actividades antes mencionadas.

De esta manera, es muy simple detectar lo que no es estndar de SAP, y en funcin de ello, poder realizar el anlisis correspondiente ante cualquier situacin. No olvidemos, que los desarrollos estndar de SAP NUNCA comenzaran con las letras anteriormente descriptas.

Igualmente, no hay una regla de oro para la nomenclatura que utilicemos, para este caso preciso, utilizaremos la denominacin PRUEBA, cuya inicial no es Y ni Z. En los casos prcticos (Servidores DEV QUA - PRD) inexorablemente debern comenzar con las consonantes antes mencionadas.

En el caso de que los mismo no comiencen con las consonantes que mencionamos anteriormente, los mismo funcionaran y no habr ningn tipo de problemas en cuanto a la funcionalidad de los mismos. Pero hay que destacar, que se esta saliendo del estndar y ello puede traer consecuencias para los futuros administradores del sistema.

Pgina 8 de 49

3.1.2

GA - Simple

En la figura 2 observaremos la creacin de un GA. Para ello, debemos ingresar el nombre del GA en el campo ROLE y luego presionar el botn que se encuentra a la derecha denominado ROLE .

Figura 2

Podemos observar que una vez creado el GA, pasamos a ver una serie de solapas en donde podemos definir el Menu del usuario, las Autorizaciones para las transacciones que posee en el men y la asignacin a el/los usuarios que harn uso del GA creado. Veamos paso por paso como se construye un grupo de actividad.

Pgina 9 de 49

En la solapa Descripcin, daremos detalle de que se trata el GA para futuros cambios a los que pueda ser sometido el GA. A continuacin, en la figura 3 y 4 veremos los dos primeros pasos descriptos anteriormente.

Figura 3

Como podemos ver, la descripcin queda a la entrada al GA, vale decir, que de ahora en mas cuando queramos modificar el GA, lo primero que nos aparecer en pantalla es la pantalla de la figura 3.

3.1.3

Solapa MENU Haciendo un clic en la solapa Menu, nos encontraremos con la pantalla de la

figura 4, donde podremos hacer mltiples configuraciones, yendo desde la mas bsica (Manual) hasta copias del menu de otros GAs.

Pgina 10 de 49

Figura 4

El paso a seguir, es incorporarle transacciones al nuevo GA, dado que la configuracin actual no nos es de mucha utilidad.

3.1.3.1 Asignacin de transaccin Modo estndar

Para agregar una transaccin, haremos un clic en el botn donde nos aparecer a modo POP-UP la pantalla de la figura 5.

Figura 5

Pgina 11 de 49

En los espacios en blanco, definiremos las transacciones que queremos que formen parte del grupo de actividad, en este caso, solo hemos incorporado la transaccin SM37.

Para que la transaccin sea confirmada en el GA, debemos hacer un clic en el botn Asignar Transaccin . A partir de ese momento, la

transaccin empieza a formar parte del GA lo que no quiere decir que la misma se encuentre operativa para su uso. Mas adelante configuraremos la puesta en marcha de las transacciones asignadas.

3.1.3.2 Asignacin de transaccin Desde el men de SAP

Ahora, vamos a incorporar una transaccin desde el men sap. Para ello, debemos hacer clic en el botn From the SAP menu . Ante

este evento, nos aparecer una pantalla a modo POP-UP como se ve en la figura 6.

Figura 6

Pgina 12 de 49

En esta pantalla podremos seleccionar las transacciones a partir del men SAP. Las mismas, estn ordenadas en carpetas y bajo ese mismo esquema es como las importara. Veamos un ejemplo en la figuras 7 y 8.

Figura 7

Como vemos en la figura 7, hemos seleccionado la transaccin SM02 a travs del men estndar de SAP. Para que la misma comience a formar parte del GA, debemos hacer un clic en el botn Transfer .

Como mencionbamos anteriormente, en la figura 8 veremos la incorporaron de las transacciones seleccionadas por los dos primeros mtodos.

A continuacin veremos los mtodos restantes.

Pgina 13 de 49

Figura 8

Ahora veamos los tres mtodos restantes que son de gran utilidad a la hora de simplificar trabajo en el diseo de GAs. Comnmente, estos mtodos no son utilizados ya que los mantenimientos se realizan en forma manual. Lo ideal seria mantener el esquema propuesto por SAP, ya que de esta manera, los GA se convertiran en estndares.

3.1.3.3 Asignacin de transaccin Desde un GA

El siguiente mtodo que vamos a investigar es el de tomar transacciones desde otro GA que conozcamos. Como todos sabemos, SAP en la instalacin, deja GAs genricos creados para su utilizacin. Estos GAs son los que propone para la utilizacin del sistema, dado que los mismos estn normalizados y las funciones se encuentran correctamente segregadas.

En la figura 9, vamos a trabajar con el men de un GA estndar de SAP. Cuando apreciemos la pantalla, podremos observar que prcticamente no difiere en relacin al mtodo From the SAP men.

Para comenzar con este mtodo, debemos hacer un clic en el botn from other role . En ese instante, nos aparecer una pantalla a modo

de POP-UP tal como vemos a continuacin.

Pgina 14 de 49

Figura 9

En esta pantalla, podremos optar por seleccionar entre Single Roles o Composite Roles. En nuestro caso vamos a continuar tal cual nos aparece la pantalla.

En el campo Single Role debemos colocar el nombre del GA que queremos utilizar como referencia para el men. Si desconocemos este, debemos hacer un clic en el botn . Como nosotros no tenemos conocimiento del GA a utilizar,

procederemos a tomar la accin antes descripta. En ese momento, el sistema arrojara una pantalla como muestra la figura 10

Figura 10

Pgina 15 de 49

En la figura 10 observamos gran parte de los grupos de actividad creados en el sistema. Ah, seleccionamos el GA al que deseamos para heredar el men y luego hacemos clic en el botn SAP_ACH_ADMIN. . En nuestro caso, hemos seleccionado el GA

En la figura 11, observamos una pantalla muy similar a la de la figura 6.

Figura 11

Si comparamos con detenimiento las figuras 6 y 11, vemos que la diferencia es perceptible dado que en la cabecera de una pantalla y otra, lo nico que vara es SAP estndar Menu por SAP_ACH_ADMIN. El resto, salvando las distancias de las transacciones asignadas, es prcticamente similar.

Pgina 16 de 49

Una vez seleccionada la transaccin que se adecuaba a nuestro GA, haremos clic en el botn Add .

Antes de ver como quedo plasmada la transaccin en el GA, veamos los ltimos dos mtodos que nos quedan. El mtodo que a continuacin veremos, es el de incorporar un rea del men. Difcilmente utilicemos esta opcin, aunque es muy util en las reingenieras de seguridad ya que podremos decir con exactitud los procesos de cada rea siempre que el dueo de los datos este de acuerdo con el mtodo a emplear.

Para

comenzar, .

debemos

pulsar

el

botn

From

area

menu

En la figura 12 veremos un pop-up que solicitara algunos datos.

Figura 12

Muy probablemente, las reas de men lo las conozcamos en demasa, con lo cual pulsaremos el botn para que el sistema no de un resumen de todas las

reas creadas hasta el momento.

La pantalla arrojada por el sistema es como la que podemos observar en la figura 13.

Pgina 17 de 49

Figura 13

Seleccionaremos la primera rea de men y veremos la pantalla tal como muestra la figura 14.

Figura 14

Esta pantalla, que como vemos es similar a la de la figura 6 y 11, y la operatoria es exactamente igual a las dos anteriores. Lo nico que difiere es la asignacin del rea en cuanto a que no es una transaccin, si no que es un rea de

Pgina 18 de 49

transacciones. Esto es exclusivamente as cuando seleccionamos toda el rea como lo haremos nosotros.

3.1.3.4 Asignacin de transaccin Desde un archivo TXT

Por ultimo, resta ver como armar el men de transacciones desde un archivo de texto. Cabe destacar, que esta opcin no tiene una frecuente utilizacin. El caso donde se aplica con frecuencia esta modalidad, es en la recopilacin de roles tanto en reingenieras como puestas en marcha.

La aplicacin que genera la salida del archivo TXT podra ser una macro en Excel, o bien, un desarrollo propio.

A continuacin, veremos el esqueleto del archivo TXT, con el fin de poder tomarlo como template para futuras implementaciones. Los ejemplos a mostrar son para la implantacin de transacciones con y sin carpeta.

Esqueleto de archivo TXT con transaccin en carpeta:

FORMAT NODE TEXT NODE TEXT 1.2B 000030000100001FOLDER 00003ENAdministration of role 000060000300003TRANSACTION 00006ENProfile Generator PFCG

El archivo esta compuesto en este caso, por cinco (5) lneas. La primera de ellas, cumple la funcin de cabecera del archivo. Algo que no nos aporta mucho, pero que el sistema interpreta.

La segunda lnea, denominada NODE, cumple la funcin tal como su denominacin lo dice NODO, pasndole cuatro parmetros. El primero, es el ID por el cual va a tener nombre la carpeta, el segundo y tercero indica el nodo predecesor, y el cuarto indica que tipo de nodo ser. Veamos como funciona:

NODE 00003 00001 00001 FOLDER parmetros que comentaba anteriormente.

Esta linea marca los cuatro

Pgina 19 de 49

El primero de ellos (00003) es el ID con el que llamara a la etiqueta TEXT. Luego, aparecen dos grupos de parmetros (00001 00001) donde nos muestra la hoja o el nodo padre, en este caso: FORMAT 1.2B.

El cuarto parmetro denominado FOLDER, nos indica que el nodo ser una carpeta que contendr una o un grupo de transacciones.

TEXT 00003 EN Administration of role indica que se trata de una etiqueta 00003 es el ID de la etiqueta, llamada desde el nodo FOLDER, EN indica el idioma con el que estamos trabajando (podra contener mltiples lneas con el mismo ID pero diferente identificador de idioma), y Administration of role, indica el nombre de la carpeta.

NODE 00006 00003 00003 TRANSACTION PFCG indica un nuevo nodo que tiene como padre al 00003. Vale decir, que este nodo estar por debajo del nodo FOLDER con una jerarqua menor. Pero este nodo es del tipo TRANSACTION, con lo que deberemos indicarle un nuevo parmetro, que en nuestro caso es PFCG.

Si lo pasamos en limpio, tendremos una transaccin (PFCG) dentro de la carpeta ADMINISTRATION OF ROLE. Lo nico que resta es la etiqueta TEXT para identificar la transaccin. Se los dejo para que lo hagan ustedes. Procuren no copiarse del ejemplo anterior.

En la figura 15 veremos el proceso de finalizado.

Figura 15

3.1.4

Solapa AUTORIZATIONS

Pgina 20 de 49

Ahora,

siguiendo

en

la

transaccin

PFCG,

veamos

la

solapa

AUTHORIZATIONS.

En esta solapa vamos a configurar las autorizaciones que tendr el usuario o el grupo de usuarios para las transacciones que existen en el men. En primera instancia, observaremos como se compone la solapa y luego iremos a la configuracin propiamente dicha. En la figura 16 tenemos una visin de la misma.

Figura 16

Como podemos apreciar, esta pantalla nos es mas que informativa. Tenemos datos como:

1. Creador de la autorizacin (No del GA) 2. Ultimo usuario que ha realizado un cambio 3. Nombre del perfil 4. Status (Generado, Necesita Ajuste, etc.) 5. Botn de modificacin de autorizaciones.

Configuremos las autorizaciones. En las siguientes figuras veremos la configuracin de las autorizaciones, pasando por los niveles organizacionales, estados de los objetos y significado de las actividades ms relevantes.

Pgina 21 de 49

3.1.5

Niveles Organizacionales

Los niveles organizacionales componen una parte fundamental del sistema SAP. Los mismos, son parametrizados post instalacin del sistema acorde a los mdulos solicitados.

Estos valores son permanentes en el sistema, y como decamos anteriormente, se definen a media de que se parametriza el modulo, que no quiere decir que en el futuro no puedas ser agregados, modificados o borrados.

El sistema viene con niveles organizacionales por defecto, que si bien nunca son utilizados, para este curso nos servirn de ejemplo. En la siguiente pantalla, veremos que los niveles organizacionales aun no fueron configurados. En este tipo de situaciones, el sistema arroja la siguiente pantalla como ilustra la figura 17.

Figura 17

El smbolo

, significa MATCH CODE, si lo pulsamos, no traer todos los

datos relacionados con el campo a completar. En este caso, el campo a desplegar es el de COMPANY CODE, tal como ilustra la figura 18.

Pgina 22 de 49

Figura 18

En esta pantalla, seleccionaremos aquellas compaas o sociedades que debemos asignar al GA.

En la figura 19, observaremos los distintos estados de los objetos de autorizacin. Esta nomenclatura es fundamental tenerla presente a la hora de trabajar con GAs dado que el status nos indica a primera vista, que datos nos estn faltando.

Figura 19

Si observamos con detenimiento, el semforo general se encuentra en ROJO, y los que estn en el rbol poseen dos estados, ROJO y AMARILLO. Vemos de qu se tratan estos estados.

17)

Significa que estn faltando valores ORGANIZACIONALES (Figura

Pgina 23 de 49

Significa que estn faltando valores NO ORGANIZACIONALES, tales

como por ejemplo: ACTIVIDAD.

Significa que los valores para el objeto estn completos.

Ahora pasemos a ver los objetos desplegados. En ellos encontraremos una serie de valores a cargar segn las tares que se hayan definido para el grupo de actividad (GA). En la figura 20, veremos lo explicado en detalle.

Figura 20

Observemos que los desplegados son los que estn en AMARILLO y uno VERDE. Cada uno de estos objetos esta faltante de datos, pero es como SAP presenta de forma Standard. Si nos remitimos a la figura 19 podremos ver lo antedicho.

Cuando se realiza la modificacin de un objeto, el mismo cambiara este status, ya que se estara violando el Standard SAP. El nuevo status del objeto y grupo de objetos para a ser MAINTAINED. Veamos la figura 21.

Pgina 24 de 49

Figura 21

Si observan con detenimiento, el primer grupo de objetos figura en MAINTAINED dado que en el interior del mismo, se ha modificado un objeto. En la figura 22 vemos este grupo de objetos desplegado.

Figura 22

En algunos casos, los objetos de autorizacin que figuran en nuestro GA, no son suficientes para que la transaccin ejecutada cumpla con el espectro funcional que se desea. En estos casos, se debern incorporar de forma manual, aquellos objetos solicitados por el sistema, tanto por un reporte SU53 o en su defecto, a travs de un trace (ST01).

Cuando insertamos un nuevo objeto manualmente, el mismo presenta el status MANUALLY. Esto quiere decir que debido a un incidente o por anlisis surgi que el objeto debera estar en el GA que estamos modificando.

En la figura 23 veremos como se ve el grupo de objetos al que le hemos agregado un objeto.

Pgina 25 de 49

Figura 23

En la figura 24 veremos el grupo de objeto FI desplegado para ver que objeto fue incorporado al GA.

Figura 24

Como vemos, el objeto agregado manualmente figura como tal, pero el grupo de objetos figura igual. Esto es muy interesante ya que a primera vista podremos observar si alguien hizo modificaciones manuales. Este status no es ms que una insercin de un objeto y el mismo, no ocasiona ningn problema. Lo unico que debemos tener en cuenta, es que el objeto a insertar, no genere conflictos funcionales o por contraposicin de funciones.

Un ejemplo muy utilizado es el objeto F_BKPF_BUP, o los objetos de generacin de ordenes de compra con los de liberacin de la misma.

Una vez cargado todos los datos de autorizacin, los semforos se posicionaran en color verde. Esto conlleva a generar la autorizacin y a posteriori, asignarlo al usuario correspondiente. En la figura 25 vemos el grupo de objetos cargados.

Pgina 26 de 49

Figura 25

En la figura 25, vemos todos los grupos de objetos con sus datos cargados, lo que restara, es generar el GA. En la cabecera de la imagen, el Status del GA es CHANGED, luego de seleccionar el botn . En la figura 26, vemos el cambio en el

status cuando se ha seleccionado el botn GENERAR.

Figura 26

Si nos remitimos a la pantalla superior, veremos que el semforo de autorizacin figura en verde, tal como lo ilustra la figura 27.

Figura 27

Pgina 27 de 49

3.1.6

Solapa USERS

3.1.6.1 Asignacin de usuario En la siguiente pantalla, asignaremos el GA construido al usuario que corresponda. Para ello, solo bastara con insertar un usuario ya conocido, o seleccionarlo desde el Match Code. En la figura 28, vemos el front end de la misma.

Figura 28

Cuando desconocemos al usuario, debemos seleccionar el botn del Match Code para seleccionar el usuario al que deseamos incorporar el nuevo GA. En la

figura 29 vemos el resultado de la bsqueda.

Figura 29

En este caso, al tratarse de un sistema recientemente instalado, solo contamos con dos usuarios, uno de los cuales es para los transportes entre sistemas.

Pgina 28 de 49

En la pantalla de la figura 29, seleccionaremos el usuario HROSSI, y luego aceptaremos con el botn .

En la figura 30 veremos los resultados de transaccin. Prestar atencin al botn y al semforo de la solapa . Estos

indicadores nos hacen ver que el maestro de usuarios esta desajustado. Para que el mismo quede en verde, debemos presionar el botn antes mencionado. Veamos en la figura 31 el resultado de la accin.

Figura 30

El usuario quedo ajustado, y el GA esta listo para ser utilizado.

Si observamos con detenimiento, los usuarios que son asignados a un GA tienen fecha de inicio y vencimiento del mismo. SAP por defecto, pone como fecha limite el 31.12.9999. Esta fecha puede ser modificada a los fines procedimentales.

Cuando se hace una modificacin en el vencimiento de un GA, el maestro de usuarios queda inconsistente, y el mismo deber ser ajustado nuevamente para que el mismo este operacional.

En la figura 31, vemos el cambio de vencimiento del usuario HROSSI para el GA PRUEBA.

Pgina 29 de 49

Figura 31

3.1.6.2 Desafectar usuario de un GA

En este punto, veremos como desasignar un usuario del GA prueba. En la figura 32, seleccionaremos el usuario HROSSI para su posterior remocin del GA.

Figura 32

En el paso 1, seleccionamos el usuario que queremos eliminar, luego procedemos al punto 2, para la efectivizacion de la eliminacin. Luego, como ilustra la figura 33, veremos que el maestro de usuarios queda desajustado. El procedimiento de ajuste lo hemos visto anteriormente.

Pgina 30 de 49

Figura 33

3.1.6.3 Desafectar usuarios de un GA en modo masivo

Este procedimiento es similar al anterior, con la salvedad de que se hace un borrado masivo de usuarios del GA.

Para ello, seguiremos una serie de pasos que veremos en la figura 34.

Figura 34

El paso 1, se seleccionan todas las filas en un solo paso, luego en el paso 2, el procedimiento es similar al punto anterior.

Pgina 31 de 49

3.1.6.4 Datos bsicos de usuario

En la solapa USER, existe un botn poco utilizado, pero que en algunas oportunidades suele ser til para verificar los datos del usuario tratado. En este caso, el botn en cuestin es , donde con el mismo, con previa seleccin de un usuario

(Figura 32), podremos ver los datos bsicos del mismo. En la figura 35, se ilustra una pantalla modelo.

Figura 35

Esta pantalla como podemos ver, solo es de modo informativa, sin poder realizar modificaciones sobre ella.

Pgina 32 de 49

3.1.7

GA - Derivado En esta seccin del documento, veremos como, a partir de un GA SIMPLE,

construiremos un GA derivado.

Para que sirve derivar? La respuesta es sencilla. Si nos remitimos al principio de la teora de objetos (POO), el mismo tiene entre varias caractersticas, la de reutilizacin. Vale decir, que si creamos un GA padre con X transacciones, luego podremos derivar al mismo por el valor de autorizacin que consideremos critico o indispensable. Un ejemplo muy utilizado, es el de derivar por CENTRO, DIVISION, SOCIEDAD, etc.

Como vimos anteriormente, los GAD solo contendrn las autorizaciones, vale decir, que el GA padre, tendr todas las transacciones que constituirn el GA completo.

Vayamos a la construccin de uno de ellos a partir del GA PRUEBA creado anteriormente. En la figura 37, veremos una nueva funcionalidad para crear los GAD.

Figura 37

Prestemos mucha atencin a:

Pgina 33 de 49

1. El GAD se lo denomino PRUEBA_GRAL. 2. No tiene transacciones ni autorizaciones. 3. Aun no fue asignado a ningn usuario.

Veamos que en la figura 37, hay un campo denominado DERIVE FROM ROLE, donde el mismo esta claramente marcado con un ovalo rojo. En este campo, debemos indicar el GA padre que ser el que sedera las transacciones. En la figura 38, vemos lo que estamos describiendo.

Figura 38

En la figura 39, veamos que las transacciones son heredadas del GA padre. Las misma no pueden ser eliminadas ni modificadas ya que el owner de las misma, es el GA padre.

Pgina 34 de 49

Figura 39

En las solapas AUTHORIZATIONS y USER, el procedimiento es igual al explicado en los puntos 3.1.3 y 3.1.5.

3.1.7.1 Modificacin de un GAD

Cuando realizamos la modificacin de un GA, el GAD sufre un desajuste de autorizaciones ya que las modificaciones siempre impactan en orden jerrquico. Estas modificaciones contemplan, Altas y Bajas de transacciones. En la figura 40, veremos el GAD con todas sus solapas en verde, luego, en la figura 41, modificaremos el GA PRUEBA sacando una transaccin (VA02). En la figura 42, volveremos al GAD PRUEBA_GRAL, y veremos el desajuste que mencionamos anteriormente, donde la solapa AUTHORIZATIONS aparecer en rojo y la USER en AMARILLO.

Estos estados se dan de la siguiente forma, AUTHORIZATIONS en ROJO significa que el perfil deber ser generado nuevamente, y USER en AMARILLO que el maestro de usuarios esta desajustado. El procedimiento de generacin y ajuste de maestro de usuarios los vimos anteriormente.

Pgina 35 de 49

Figura 40

Figura 41

Pgina 36 de 49

Figura 42

3.1.7.2 Autorizaciones distribuidas

Como anteriormente vimos, las autorizaciones solo deban estar en el GAD, pero existe una alternativa a la hora de crear GAD cuyos valores de autorizacin que no sean organizacionales no varen.

Este caso se presenta especialmente cuando creamos GAD, cuya limitacin se presenta a la hora de fijar el marco de trabajo a uno o varios valores organizacionales. Este caso lo podemos relacionar rpidamente si les pusiera como ejemplo que el GA es PRUEBA y los GAD son PRUEBA_0001, PRUEBA_0002, etc. Donde

XXXXXX_0001 es la ORGANIZACIN DE COMPRAS.

Veamos un caso prctico, donde los GAD ya estn creados y solo resta configurar las autorizaciones. En las figuras 42 y 43 veremos los GAD con variante en la ORGANIZACIN DE COMPRAS.

Pgina 37 de 49

Figura 42

Figura 43

Noten, que la diferencia entre la figura 42 y 43 es el nombre del GAD. Ahora, trabajaremos en las autorizaciones del GA PRUEBA, figura 44.

Pgina 38 de 49

Figura 44

Como podemos ver, los semforos verdes indican que los valores solicitados fueron cargados, mientras que los que estn en rojo indican que los niveles organizacionales no fueron ingresados. Estos ltimos, sern ingresados en los GAD.

Primero, debemos pasar las autorizaciones configuradas en el GA a los GAD, para ello, debemos utilizar una herramienta a la cual no hemos hecho referencia aun. En la figura 45 realizamos dicha configuracin. El botn que realiza esta operacin es

Figura 45

Pgina 39 de 49

Como indica el crculo rojo de la figura 45, el botn hereda las autorizaciones (SOLO LAS NO ORGANIZACIONALES) del GA al GAD. Ahora, veamos por ejemplo a GAD PRUEBA_0001 en la figura 46.

Figura 46

Veamos, que el GAD sin que los hayamos configurado, ya posee autorizaciones. Las misma vienen derivadas del GA padre quien posee las autorizaciones NO ORGANIZACIONALES. Lo que restara ahora, es configurar la variante para este GAD (Niveles Organizacionales). En la figura 47 veremos el resultado de la configuracin.

Figura 47

Pgina 40 de 49

Observemos, que las autorizaciones organizacionales han completado la totalidad de las configuraciones del GAD. Ahora, el GAD PRUEBA_0001 ser limitado a la organizacin de compras 0001, este es el concepto puro de una variante.

3.1.7.3 Problemas en las Autorizaciones

En algunos casos, cuando se realizan mantenimientos en los GA, es posible que los objetos se dupliquen generando grandes problemas. Uno de ellos puede ser el de sumar actividades que no sean requeridas en el GA, o que valores estndar del objeto agregado, traiga consecuencias inimaginables en la operatoria de los usuarios. Un caso muy comn, es el duplicado del objeto que administra jobs, el mismo trae el Y en el nico campo que tiene para completar. Esta Y trae como consecuencia que los usuarios puedan administrar los jobs del sistema.

En las figuras 48 y 49, veremos los casos de los objetos duplicados.

Figura 48

En la figura 48, lo nico que podemos identificar, es que hay objetos nuevos en el GAD, ahora, si observamos bien, hay objetos nuevos que figuran como MAINTAINED. Esto, en condiciones normales, suena muy extrao, que por ser nuevo no debera estar mantenido. Veamos la figura 49, donde este status se aclarara.

Pgina 41 de 49

Figura 49

Si observamos, los objetos F_BKPK_BED y F_BKPF_BEK, estn duplicados, quedando en este caso en amarillo. El ID que figura a la derecha del objeto (TDV300), se refiere a la autorizacin asignada al objeto. Veamos, que tanto el BEK como el BED terminan en 700 y 701. Esto quiere decir, que se ha sumado uno al existente (700).

Veamos entonces como resolver este problema, ya que de ninguna manera puede quedar duplicado, salvo raras excepciones. En la figura 50, se resolver este problema. El mismo, ser atendido con el botn .

Figura 50

Pgina 42 de 49

Veamos que los objetos inhabilitados son los que aparecen en la parte superior en la jerarqua de objetos. Siempre debe ser de esta manera, ya que, cuando SAP quiere insertar un nuevo objeto, chequea que el mismo este activo, de lo contrario omite el agregado del mismo.

Cuando un nuevo objeto se agrega al grupo de objetos, los mismos se identifican como NEW (NUEVO). En la figura 51, veremos un caso prctico de esta situacin.

Figura 51

Veamos, que tanto el grupo de objetos como el objeto propiamente dicho, figuran como NEW. En el grupo de objetos, si bien hay objetos OLD, lo que pretende es advertir de la incorporacin que hay nuevos elementos que debern ser revisados.

Pgina 43 de 49

3.1.7.4 Otras funciones

La transaccin PFCG posee innumerables funciones para realizar operatorias de apoyo, no obstante, no remitiremos a las funciones mas usadas dentro de las que no hemos visto. A continuacin, iremos listando los controles a los que haremos mencin de su funcionabilidad.

Este botn tiene como funcin mostrar todos los objetos del sistema agrupados por su categora. De aqu, seleccionaremos el objeto que deseamos y luego ser aadido al GA en modificacin. Veamos un ejemplo en la figura 52.

Figura 52

Los grupos de objetos estn sealizados con el signo (+), mientras que cuando los desplegamos quedan con el signo (-). Luego, vemos a los objetos con un smbolo , esto quiere decir que el mismo no fue seleccionado aun. En el caso de que lo seleccionemos, el mismo quedara con el smbolo , lo que indica que este objeto ser aadido al GA en modificacin.

Esta funcin se utiliza cuando no tenemos forma de encontrar un error, para solucionar el mismo, debemos acudir a este men y aplicar lgica procedimental.

Pgina 44 de 49

Este botn tiene como funcin, el agregado de objetos de forma manual. Para utilizar dicha funcin, debemos tener bien en claro, que objeto se debe agregar o por medio de un reporte, que nos dar la informacin precisa del objeto a aadir.

Estos botones cumplen similares funciones, pero como su nombre dice, OPEN, despliega todos los nodos de las autorizaciones, NEW, despliega el grupo de objetos (NEW), CHANGED, despliega el grupo de objetos modificado, MAINTAINED, despliega el grupo de objetos cuyos valores de autorizacin fueron cargados en los niveles organizacionales.

Pgina 45 de 49

3.2-SU53
La transaccin SU53, es de suma utilidad a la hora de investigar los problemas de seguridad de los usuarios. El mismo, genera un reporte con el ltimo evento generado por el usuario, vale decir, que si un usuario ejecuta una transaccin que no tiene asignada, el sistema arrojara un mensaje de error informando que no posee autorizacin para ejecutar dicha transaccin.

3.2.1

Ejecutando SU53 para transacciones

Lo primero que debemos hacer antes que nada, es generar un error para ver como el sistema genera el reporte. Para ello, ejecutaremos una transaccin que no esta asignada al GAD que tiene el usuario. En la figura 53 veremos este procedimiento.

Figura 53

Pgina 46 de 49

Como vemos en la figura 53, la transaccin que se ejecuto y a la que no tuvo acceso en la MK01. Este, seria el caso ms sencillo dentro de los errores de autorizacin. En la figura 54, veremos el reporte que genera la transaccin SU53, para ello, debemos ejecutar la misma inmediatamente que el sistema arroja el error. En este caso, podemos ejecutarla directamente, pero en el caso de que estemos dentro de una transaccin y ocurra un error de autorizacin, a la misma se deber anteponer el cdigo /N /O.

Figura 54

En la primer seccin del reporte, nos indica que autorizacin esta haciendo falta. En este caso, solicita para la clase de objeto AAAB, el objeto S_TCODE, el valor MK01.

Pgina 47 de 49

En este caso, el valor MK01, no debe ser cargado a mano en el objeto ya que en los mismos se contemplan variables. Si llegramos a modificar manualmente este campo, cada vez que agreguemos una transaccin por men, la misma, no ser cargada en el campo del objeto S_TCODE. Lo mismo sucede, si lo que estamos modificando manualmente es un Nivel Organizacional. Mas adelante veremos este caso.

3.2.2

Ejecutando SU53 para autorizaciones

Como vimos anteriormente, el concepto de autorizacin va de la mano de las transacciones que tenga el o los GADs asignados a un usuario. Ahora, simularemos un error de autorizacin dentro de una transaccin. En la figura 55, veremos el mensaje de error dentro de una transaccin.

Figura 55

Pgina 48 de 49

En la figura 56 veremos el reporte que genera la transaccin SU53 respecto de este error.

Figura 56

Este error, debe ser tratado desde los niveles organizacionales del GA asignado al usuario, ya que el CODIGO de COMPAA esta sujeto a una variable igual que el campo de la S_TCODE. En este caso, el objeto que esta solicitando el valor 0001 es el F_BKPK_BUK, cuya actividad es correcta, pero el campo restante solo tiene seteado AR01 faltando 0001.

Pgina 49 de 49