seguridad sap r/3

SEGURIDAD SAP R/3
Página 1 de 49
Tabla de Contenidos
0-OBJETIVO ............................................................................................................................................. 3
1-ALCANCE ............................................................................................................................................... 3
1.1-A QUIEN VA DIRIGIDO? ........................................................................................................................ 3
2-INTRODUCCIÓN ................................................................................................................................. 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
Nomenclatura de GA .............................................................................................................. 8
3.1.2
GA - Simple............................................................................................................................. 9
3.1.3
Solapa MENU ....................................................................................................................... 10
3.1.3.1
Asignación de transacción – Modo estándar .......................................................... 11
3.1.3.2
Asignación de transacción – Desde el menú de SAP............................................... 12
3.1.3.3
Asignación de transacción – Desde un GA ............................................................. 14
3.1.3.4
Asignación de transacción – Desde un archivo TXT ............................................... 19
3.1.4
Solapa AUTORIZATIONS .................................................................................................... 20
3.1.5
Niveles Organizacionales ..................................................................................................... 22
3.1.6
Solapa USERS ...................................................................................................................... 28
3.1.6.1
Asignación de usuario ............................................................................................. 28
3.1.6.2
Desafectar usuario de un GA .................................................................................. 30
3.1.6.3
Desafectar usuarios de un GA en modo masivo ...................................................... 31
3.1.6.4
Datos básicos de usuario......................................................................................... 32
3.1.7
GA - Derivado ...................................................................................................................... 33
3.1.7.1
Modificación de un GAD ......................................................................................... 35
3.1.7.2
Autorizaciones distribuidas ..................................................................................... 37
3.1.7.3
Problemas en las Autorizaciones ............................................................................ 41
3.1.7.4
Otras funciones........................................................................................................ 44
3.2-SU53 ............................................................................................................................................... 46
3.2.1
Ejecutando SU53 para transacciones................................................................................... 46
3.2.2
Ejecutando SU53 para autorizaciones ................................................................................. 48
Página 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 segregación
de funciones.
1-Alcance
Este curso pretende llegar a la mínima granularidad en lo que respecta a la
seguridad de SAP R/3, pasando por las herramientas estándar de creación de grupos
de actividad, informes de auditoria de seguridad, tablas de seguridad y funcionales,
parámetros básicos de usuarios, creación de usuarios, definición de roles, etc.
1.1-A quien va dirigido?
Este curso va dirigido aquellas personas que se están iniciando en la seguridad
de SAP R/3 y, en una segunda etapa, aquellos administradores con conocimientos
básicos de las herramientas estándar del sistema.
Página 3 de 49
2-Introducción
En principio veamos algunos conceptos básicos que demos tener en cuenta
sobre la teoría de seguridad en SAP R/3. Estos conceptos nos serán de gran ayuda a
lo largo del curso, ya que con estos conceptos daremos la totalidad del curso.
A continuación, abarcaremos los conceptos de Grupo de Actividad, Grupo de
Actividad Derivado, Rol, y Rol compuesto. Para ello daremos la definición 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, también denominado erróneamente ROL, nos es más
que un sub.-conjunto de un rol. El mismo, posee una pequeña porción de las funciones
que desempeñara 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 transacción PFCG para
realizar un alta, baja o modificación del mismo. La transacción PFCG será explicada
en capítulos posteriores
2.2-Grupo de actividad derivado
El grupo de actividad derivado, es, jerárquicamente hablando, súbdito del GA
(Grupo de actividad). El mismo, posee las autorizaciones en función del GA padre,
vale decir, que si el GA padre posee diez (10) transacciones, el GA derivado poseerá
los objetos de autorización chequeados por la transacciones del GA padre.
En un esquema ordenado, la autorizaciones deberán estar en los GA derivados
y la transacciones en los GA padre. El GA padre nunca deberá poseer autorizaciones
salvo una excepción que es cuando se quiere limitar por niveles organizacionales.
Un ejemplo de GAD puede ser: ZAR_E_CO:FI:GRTE_GRAL
Página 4 de 49
2.2-Rol
Un Rol, es un conjunto de GAD´s agrupados para desempeñar una función
preestablecida. Esta función nace de un análisis 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
difíciles de mantener dado que se crean con un propósito especifico y terminan siendo
alterados por el desconocimiento del proceso, o por directrices mal gestionadas.
Página 5 de 49
3-Interactuando con el sistema
En esta sección 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 investigación en forma indirecta a la seguridad.
Las transacciones a utilizar serán las siguientes:
1. PFCG (Profile Generador)
2. SU01 (Gestión de usuarios)
3. SU10 (Gestión de usuarios en masa)
4. SU53 (Datos de autorización para usuario)
5. SU56 (Autorizaciones en el buffer del usuario)
6. SU24 (Chequeo de objetos para transacción)
7. SE10 (Liberación de ordenes de transporte)
8. SE16 (Browser de tablas)
9. SE37 (Programas del sistema)
10. STMS (Sistema de transportes)
Las tablas que utilizaremos serán las siguientes:
1. ADCP (Datos de usuario)
2. ADRP (Datos de usuario)
3. AGR_DEFINE (Definición 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 (Jerarquía de GA (Roles Compuestos))
10. TACT (Descripción de actividades)
11. TOBJ (Objetos del sistema)
12. TSTCA (Transacciones con valores estándar por objeto)
13. TSTCT (Descripción de transacciones)
14. USR02 (Usuarios del sistema)
15. USR05 (Parámetros de usuarios del sistema)
Página 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 transacción PFCG (Profile Generador), es utilizada generalmente para la
creación de GA, asignación de autorizaciones y eventualmente asignación de usuarios
al GA creado o modificado. También se utiliza para remover usuarios de los GA
indicados por personal jerárquico.
Dicha transacción, tiene muchas mas funcionalidades que serán vistas a los
largo de este punto.
En la figura 1 observaremos la pantalla de inicio de la transacción.
Figura 1
Como podemos observar, en la pantalla principal de la transacción, además de
tener múltiples opciones, podemos crear, modificar, visualizar o borrar un grupo de
actividad.
Página 7 de 49
3.1.1
Nomenclatura de GA
Tanto para la creación de nuevos GA, como transacciones, objetos de
autorización, etc., SAP, deja a disposición de los usuarios las letras “Y” y “Z” para el
comienzo de la denominación de algunas de las actividades antes mencionadas.
De esta manera, es muy simple detectar lo que no es estándar de SAP, y en
función de ello, poder realizar el análisis correspondiente ante cualquier situación. No
olvidemos, que los desarrollos estándar 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 denominación PRUEBA, cuya inicial no es “Y” ni “Z”.
En los casos prácticos (Servidores DEV – QUA - PRD) inexorablemente deberán
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á ningún tipo de
problemas en cuanto a la funcionalidad de los mismos. Pero hay que destacar, que se
esta saliendo del estándar y ello puede traer consecuencias para los futuros
administradores del sistema.
Página 8 de 49
3.1.2
GA - Simple
En la figura 2 observaremos la creación de un GA. Para ello, debemos ingresar
el nombre del GA en el campo ROLE y luego presionar el botón 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 asignación a el/los usuarios que harán uso
del GA creado. Veamos paso por paso como se construye un grupo de actividad.
Página 9 de 49
En la solapa “Descripción”, daremos detalle de que se trata el GA para futuros
cambios a los que pueda ser sometido el GA. A continuación, en la figura 3 y 4
veremos los dos primeros pasos descriptos anteriormente.
Figura 3
Como podemos ver, la descripción 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 múltiples configuraciones, yendo desde la mas básica
(Manual) hasta copias del menu de otros GA´s.
Página 10 de 49
Figura 4
El paso a seguir, es incorporarle transacciones al nuevo GA, dado que la
configuración actual no nos es de mucha utilidad.
3.1.3.1 Asignación de transacción – Modo estándar
Para agregar una transacción, haremos un clic en el botón
donde nos aparecerá a modo POP-UP la pantalla de la figura 5.
Figura 5
Página 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
transacción SM37.
Para que la transacción sea confirmada en el GA, debemos hacer un clic en el
. A partir de ese momento, la
botón “Asignar Transacción”
transacción 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 Asignación de transacción – Desde el menú de SAP
Ahora, vamos a incorporar una transacción desde el menú sap. Para ello,
debemos hacer clic en el botón “From the SAP menu”
. Ante
este evento, nos aparecerá una pantalla a modo POP-UP como se ve en la figura 6.
Figura 6
Página 12 de 49
En esta pantalla podremos seleccionar las transacciones a partir del menú
SAP. Las mismas, están 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 transacción SM02 a través del
menú estándar de SAP. Para que la misma comience a formar parte del GA, debemos hacer
un clic en el botón “Transfer”
.
Como mencionábamos anteriormente, en la figura 8 veremos la incorporaron de las
transacciones seleccionadas por los dos primeros métodos.
A continuación veremos los métodos restantes.
Página 13 de 49
Figura 8
Ahora veamos los tres métodos restantes que son de gran utilidad a la hora de
simplificar trabajo en el diseño de GA´s. Comúnmente, estos métodos 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
convertirían en estándares.
3.1.3.3 Asignación de transacción – Desde un GA
El siguiente método que vamos a investigar es el de tomar transacciones desde
otro GA que conozcamos. Como todos sabemos, SAP en la instalación, deja GA´s
genéricos creados para su utilización. Estos GA´s son los que propone para la
utilización del sistema, dado que los mismos están normalizados y las funciones se
encuentran correctamente segregadas.
En la figura 9, vamos a trabajar con el menú de un GA estándar de SAP.
Cuando apreciemos la pantalla, podremos observar que prácticamente no difiere en
relación al método “From the SAP menú”.
Para comenzar con este método, debemos hacer un clic en el botón “from other
role”
. En ese instante, nos aparecerá una pantalla a modo
de POP-UP tal como vemos a continuación.
Página 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 botón
. Como nosotros no tenemos conocimiento del GA a utilizar,
procederemos a tomar la acción antes descripta. En ese momento, el sistema arrojara
una pantalla como muestra la figura 10
Figura 10
Página 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 botón
. En nuestro caso, hemos seleccionado el GA
SAP_ACH_ADMIN.
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 varía es “SAP
estándar Menu” por “SAP_ACH_ADMIN”. El resto, salvando las distancias de las
transacciones asignadas, es prácticamente similar.
Página 16 de 49
Una vez seleccionada la transacción que se adecuaba a nuestro GA, haremos
.
clic en el botón “Add”
Antes de ver como quedo plasmada la transacción en el GA, veamos los
últimos dos métodos que nos quedan. El método que a continuación veremos, es el de
incorporar un área del menú. Difícilmente utilicemos esta opción, aunque es muy util
en las reingenierías de seguridad ya que podremos decir con exactitud los procesos
de cada área siempre que el dueño de los datos este de acuerdo con el método a
emplear.
Para
comenzar,
debemos
pulsar
el
botón
“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 demasía, con lo
cual pulsaremos el botón
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.
Página 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
asignación del área en cuanto a que no es una transacción, si no que es un área de
Página 18 de 49
transacciones. Esto es exclusivamente así cuando seleccionamos toda el área como lo
haremos nosotros.
3.1.3.4 Asignación de transacción – Desde un archivo TXT
Por ultimo, resta ver como armar el menú de transacciones desde un archivo
de texto. Cabe destacar, que esta opción no tiene una frecuente utilización. El caso
donde se aplica con frecuencia esta modalidad, es en la recopilación de roles tanto en
reingenierías como puestas en marcha.
La aplicación que genera la salida del archivo TXT podría ser una macro en
Excel, o bien, un desarrollo propio.
A continuación, veremos el esqueleto del archivo TXT, con el fin de poder
tomarlo como template para futuras implementaciones. Los ejemplos a mostrar son
para la implantación de transacciones con y sin carpeta.
Esqueleto de archivo TXT con transacción en carpeta:
FORMAT
1.2B
NODE
000030000100001FOLDER
TEXT
00003ENAdministration of role
NODE
000060000300003TRANSACTION
TEXT
00006ENProfile Generator
PFCG
El archivo esta compuesto en este caso, por cinco (5) líneas. La primera de
ellas, cumple la función de cabecera del archivo. Algo que no nos aporta mucho, pero
que el sistema interpreta.
La segunda línea, denominada NODE, cumple la función tal como su
denominación lo dice “NODO”, pasándole cuatro parámetros. 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 -Æ Esta linea marca los cuatro
parámetros que comentaba anteriormente.
Página 19 de 49
El primero de ellos (00003) es el ID con el que llamara a la etiqueta TEXT.
Luego, aparecen dos grupos de parámetros (00001 00001) donde nos muestra la hoja
o el nodo padre, en este caso: FORMAT 1.2B.
El cuarto parámetro 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 (podría contener múltiples líneas 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 jerarquía menor. Pero este nodo es del tipo TRANSACTION, con lo
que deberemos indicarle un nuevo parámetro, que en nuestro caso es PFCG.
Si lo pasamos en limpio, tendremos una transacción (PFCG) dentro de la
carpeta ADMINISTRATION OF ROLE. Lo único que resta es la etiqueta TEXT para
identificar la transacción. 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
Página 20 de 49
Ahora,
siguiendo
en
la
transacción
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 configuración
propiamente dicha. En la figura 16 tenemos una visión de la misma.
Figura 16
Como podemos apreciar, esta pantalla nos es mas que informativa. Tenemos
datos como:
1. Creador de la autorización (No del GA)
2. Ultimo usuario que ha realizado un cambio
3. Nombre del perfil
4. Status (Generado, Necesita Ajuste, etc.)
5. Botón de modificación de autorizaciones.
Configuremos las autorizaciones. En las siguientes figuras veremos la
configuración de las autorizaciones, pasando por los niveles organizacionales, estados
de los objetos y significado de las actividades más relevantes.
Página 21 de 49
3.1.5
Niveles Organizacionales
Los niveles organizacionales componen una parte fundamental del sistema
SAP. Los mismos, son parametrizados post instalación del sistema acorde a los
módulos solicitados.
Estos valores son permanentes en el sistema, y como decíamos 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 servirán 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 símbolo
, 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.
Página 22 de 49
Figura 18
En esta pantalla, seleccionaremos aquellas compañías o sociedades que
debemos asignar al GA.
En la figura 19, observaremos los distintos estados de los objetos de
autorización. Esta nomenclatura es fundamental tenerla presente a la hora de trabajar
con GA´s dado que el status nos indica a primera vista, que datos nos están faltando.
Figura 19
Si observamos con detenimiento, el semáforo general se encuentra en ROJO,
y los que están en el árbol poseen dos estados, ROJO y AMARILLO. Vemos de qué
se tratan estos estados.
-Æ Significa que están faltando valores ORGANIZACIONALES (Figura
17)
Página 23 de 49
-Æ Significa que están faltando valores NO ORGANIZACIONALES, tales
como por ejemplo: ACTIVIDAD.
-Æ Significa que los valores para el objeto están completos.
Ahora pasemos a ver los objetos desplegados. En ellos encontraremos una
serie de valores a cargar según 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 están 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 modificación de un objeto, el mismo cambiara este status,
ya que se estaría violando el Standard SAP. El nuevo status del objeto y grupo de
objetos para a ser MAINTAINED. Veamos la figura 21.
Página 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 autorización que figuran en nuestro GA, no
son suficientes para que la transacción ejecutada cumpla con el espectro funcional
que se desea. En estos casos, se deberán incorporar de forma manual, aquellos
objetos solicitados por el sistema, tanto por un reporte SU53 o en su defecto, a través
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 análisis surgió que el
objeto debería 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.
Página 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 más que una
inserción de un objeto y el mismo, no ocasiona ningún problema. Lo unico que
debemos tener en cuenta, es que el objeto a insertar, no genere conflictos funcionales
o por contraposición de funciones.
Un ejemplo muy utilizado es el objeto F_BKPF_BUP, o los objetos de
generación de ordenes de compra con los de liberación de la misma.
Una vez cargado todos los datos de autorización, los semáforos se
posicionaran en color verde. Esto conlleva a generar la autorización y a posteriori,
asignarlo al usuario correspondiente. En la figura 25 vemos el grupo de objetos
cargados.
Página 26 de 49
Figura 25
En la figura 25, vemos todos los grupos de objetos con sus datos cargados, lo
que restaría, es generar el GA. En la cabecera de la imagen, el Status del GA es
CHANGED, luego de seleccionar el botón
. En la figura 26, vemos el cambio en el
status cuando se ha seleccionado el botón GENERAR.
Figura 26
Si nos remitimos a la pantalla superior, veremos que el semáforo de
autorización figura en verde, tal como lo ilustra la figura 27.
Figura 27
Página 27 de 49
3.1.6
Solapa USERS
3.1.6.1 Asignación 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 botón del Match
Code
para seleccionar el usuario al que deseamos incorporar el nuevo GA. En la
figura 29 vemos el resultado de la búsqueda.
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.
Página 28 de 49
En la pantalla de la figura 29, seleccionaremos el usuario HROSSI, y luego
aceptaremos con el botón
.
En la figura 30 veremos los resultados de transacción. Prestar atención al
botón
y al semáforo 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 botón antes mencionado. Veamos en la
figura 31 el resultado de la acción.
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 modificación 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.
Página 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 remoción del GA.
Figura 32
En el paso 1, seleccionamos el usuario que queremos eliminar, luego
procedemos al punto 2, para la efectivizacion de la eliminación. Luego, como ilustra la
figura 33, veremos que el maestro de usuarios queda desajustado. El procedimiento
de ajuste lo hemos visto anteriormente.
Página 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.
Página 31 de 49
3.1.6.4 Datos básicos de usuario
En la solapa USER, existe un botón poco utilizado, pero que en algunas
oportunidades suele ser útil para verificar los datos del usuario tratado. En este caso,
el botón en cuestión es
, donde con el mismo, con previa selección de un usuario
(Figura 32), podremos ver los datos básicos 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.
Página 32 de 49
3.1.7
GA - Derivado
En esta sección 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 teoría de objetos (POO), el mismo tiene entre varias características, la de
reutilización. Vale decir, que si creamos un GA padre con X transacciones, luego
podremos derivar al mismo por el valor de autorización que consideremos critico o
indispensable. Un ejemplo muy utilizado, es el de derivar por CENTRO, DIVISION,
SOCIEDAD, etc.
Como vimos anteriormente, los GAD solo contendrán las autorizaciones, vale
decir, que el GA padre, tendrá todas las transacciones que constituirán el GA
completo.
Vayamos a la construcción 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 atención a:
Página 33 de 49
1. El GAD se lo denomino PRUEBA_GRAL.
2. No tiene transacciones ni autorizaciones.
3. Aun no fue asignado a ningún 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.
Página 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 Modificación de un GAD
Cuando realizamos la modificación de un GA, el GAD sufre un desajuste de
autorizaciones ya que las modificaciones siempre impactan en orden jerárquico. 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 transacción (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 generación y ajuste de
maestro de usuarios los vimos anteriormente.
Página 35 de 49
Figura 40
Figura 41
Página 36 de 49
Figura 42
3.1.7.2 Autorizaciones distribuidas
Como anteriormente vimos, las autorizaciones solo debían estar en el GAD,
pero existe una alternativa a la hora de crear GAD cuyos valores de autorización que
no sean organizacionales no varíen.
Este caso se presenta especialmente cuando creamos GAD, cuya limitación se
presenta a la hora de fijar el marco de trabajo a uno o varios valores organizacionales.
Este caso lo podemos relacionar rápidamente si les pusiera como ejemplo que el GA
es
PRUEBA
y
los
GAD
son
PRUEBA_0001,
PRUEBA_0002,
etc.
Donde
XXXXXX_0001 es la ORGANIZACIÓN DE COMPRAS.
Veamos un caso práctico, donde los GAD ya están creados y solo resta
configurar las autorizaciones. En las figuras 42 y 43 veremos los GAD con variante en
la ORGANIZACIÓN DE COMPRAS.
Página 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.
Página 38 de 49
Figura 44
Como podemos ver, los semáforos verdes indican que los valores solicitados
fueron cargados, mientras que los que están en rojo indican que los niveles
organizacionales no fueron ingresados. Estos últimos, serán 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 configuración. El botón que realiza esta operación es
Figura 45
Página 39 de 49
Como indica el círculo rojo de la figura 45, el botón 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 restaría ahora, es configurar la
variante para este GAD (Niveles Organizacionales). En la figura 47 veremos el
resultado de la configuración.
Figura 47
Página 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 organización 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 estándar del
objeto agregado, traiga consecuencias inimaginables en la operatoria de los usuarios.
Un caso muy común, 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 extraño, que por ser nuevo
no debería estar mantenido. Veamos la figura 49, donde este status se aclarara.
Página 41 de 49
Figura 49
Si observamos, los objetos F_BKPK_BED y F_BKPF_BEK, están duplicados,
quedando en este caso en amarillo. El ID que figura a la derecha del objeto (TDV300…), se refiere a la autorización 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 botón
.
Figura 50
Página 42 de 49
Veamos que los objetos inhabilitados son los que aparecen en la parte superior
en la jerarquía 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 práctico de esta
situación.
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 incorporación que hay nuevos elementos que deberán ser revisados.
Página 43 de 49
3.1.7.4 Otras funciones
La transacción 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 continuación, iremos listando los controles a los que haremos
mención de su funcionabilidad.
Este botón tiene como función mostrar todos los objetos del
sistema agrupados por su categoría. De aquí, seleccionaremos el objeto que
deseamos y luego será añadido al GA en modificación. Veamos un ejemplo en la
figura 52.
Figura 52
Los grupos de objetos están señalizados con el signo (+), mientras que cuando
los desplegamos quedan con el signo (-). Luego, vemos a los objetos con un
símbolo , esto quiere decir que el mismo no fue seleccionado aun. En el caso de que
lo seleccionemos, el mismo quedara con el símbolo , lo que indica que este objeto
será añadido al GA en modificación.
Esta función se utiliza cuando no tenemos forma de encontrar un error, para
solucionar el mismo, debemos acudir a este menú y aplicar lógica procedimental.
Página 44 de 49
Este botón tiene como función, el agregado de objetos de forma manual.
Para utilizar dicha función, debemos tener bien en claro, que objeto se debe agregar o
por medio de un reporte, que nos dará la información precisa del objeto a añadir.
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 autorización fueron cargados en los niveles organizacionales.
Página 45 de 49
3.2-SU53
La transacción 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 transacción que no
tiene asignada, el sistema arrojara un mensaje de error informando que no posee
autorización para ejecutar dicha transacción.
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 transacción que no
esta asignada al GAD que tiene el usuario. En la figura 53 veremos este
procedimiento.
Figura 53
Página 46 de 49
Como vemos en la figura 53, la transacción que se ejecuto y a la que no tuvo
acceso en la MK01. Este, seria el caso más sencillo dentro de los errores de
autorización. En la figura 54, veremos el reporte que genera la transacción 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 transacción y ocurra un error de autorización, a la misma se deberá anteponer
el código “/N” ó “/O”.
Figura 54
En la primer sección del reporte, nos indica que autorización esta haciendo
falta. En este caso, solicita para la clase de objeto AAAB, el objeto S_TCODE, el valor
MK01.
Página 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 llegáramos a modificar manualmente este
campo, cada vez que agreguemos una transacción 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 autorización va de la mano de las
transacciones que tenga el o los GAD´s asignados a un usuario. Ahora, simularemos
un error de autorización dentro de una transacción. En la figura 55, veremos el
mensaje de error dentro de una transacción.
Figura 55
Página 48 de 49
En la figura 56 veremos el reporte que genera la transacción 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 COMPAÑÍA 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.
Página 49 de 49