Archive for the ‘roles’ Category

Creación de un rol – ejemplo

Thursday, April 23rd, 2009

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

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

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image

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

image image

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

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

image

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

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

VN:F [1.8.2_1042]
Rating: 4.8/5 (5 votes cast)
VN:F [1.8.2_1042]
Rating: +1 (from 1 vote)

Proyectos: Metodología de Construcción de Roles en SAP

Thursday, March 12th, 2009

A lo largo de un proyecto de implementación de SAP o una reingeniería de la seguridad del sistema nos encontramos con distintas tareas a realizar para construir los roles que le sean funcionales a la organización.

En el presente post evaluaremos una alternativa metodológica para trabajar utilizada en varios proyectos exitosos de implementación de la seguridad de SAP.

image

El gráfico que vemos arriba representa el proceso completo el cual pasamos a detallar:

Etapa 1 – Identificación de Roles

Entradas: Mapa de Procesos de la organización

Tareas: Una vez que los procesos se encuentran modelados se comienzan a identificar las actividades indivisibles que pueden ser agrupadas en roles. A su vez sobre estos roles se realizar un primer análisis de segregación de funciones para detectar

Salidas: Mapas de procesos con roles asignados a las actividades.

Actores: Analistas de Procesos, Analistas Funcionales SAP, Usuarios Clave, Control Interno, Administración de Seguridad.

Etapa 2 – Selección de Transacciones

Entradas: Mapas de procesos con roles asignados a las actividades.

Tareas: Definición de transacciones necesarias para ejecutar las actividades definidas en el mapa de procesos. Armado de roles y análisis de Segregación de Funciones por código de transacción. Apertura de roles de negocio en roles del sistema de acuerdo a las necesidades de mantenimiento u optimización (agrupar actividades de visualización, incorporar reportes necesarios para ejecutar la actividad principal, etc.)

image

Salidas: Definición de roles del sistema con sus respectivas transacciones. Planilla de Roles, Transacciones y Objetos de Autorización a completar.

Actores: Analistas Funcionales SAP, Control Interno, Administración de Seguridad

image

Etapa 3 – Definición de Variantes

Entradas: Definición de roles del sistema con sus respectivas transacciones. Planilla de Roles, Transacciones y Objetos de Autorización a completar.

Tareas: Elaboración de una planilla de criterios de apertura por niveles organizativos u otras necesidades específicas. Definición de las necesidades de apertura basándose en la confidencialidad, requerimientos del negocio, distribución geográfica, y control interno. Construcción de las variantes.

Salidas: Variantes de rol construidas y listas para las pruebas.

Actores: Usuarios Clave Control Interno, Administración de Seguridad, Analistas Funcionales SAP (apoyo)

Etapa 4 – Prueba de Roles

Entradas: Roles y variantes construidos (al menos uno de prueba).

Tareas: Elaboración de los casos de pruebas positivas y negativas (que no tiene que poder hacer). Ejecución de las pruebas. Registración de resultados y corrección de errores.

Salidas: Roles Aceptados y Construidos.

Actores: Usuarios Clave, Control Interno, Administración de Seguridad, Analistas Funcionales SAP.

image

Etapa 5 – Asignación a Usuarios

Entradas: Planilla de Roles y Variantes (Puede comenzar el relevamiento de asignación antes de la finalización de la prueba)

Tareas: Relevamiento de asignación de usuarios a roles. Puede hacerse un relevamiento previo para validar el criterio de roles con el negocio, y luego abrirlo en las variantes respectivas. Análisis de Segregación de funciones en la asignación.

image

Salidas: Seguridad creada y documentada.

Actores: Usuarios Clave, Control Interno, Administración de Seguridad.

Comentarios sobre el proceso:

- Es de suma importancia incorporar una actividad anterior a todas estas etapas, involucrando a los participantes del proyecto desde el lado funcional, para comentarles como es el proceso, cual sería su participación y el grado en que deberán involucrarse en el proceso. Del éxito, y la comprensión de esta charla dependerá mucho el éxito final del proyecto.

- Las dos revisiones de segregación de funciones a lo largo del proyecto atacan problemas distintos. El primero trata que los roles en si mismos no contengan problemas de segregación, de ser así, la simple asignación del rol estaría dándole un problema al usuario al que se le asigna. Este caso no puede ocurrir nunca porque implicaría una mala definición del rol por parte de los responsables. La segunda revisión es ya para controlar que a un usuario no se le presenten problemas de segregación de funciones por poseer más de un rol y estos entren en conflicto entre sí, y es distinto al control anterior.

Espero que les sea útil el presente post y espero sus comentarios.

VN:F [1.8.2_1042]
Rating: 4.5/5 (6 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 2 votes)

Nomenclatura de Roles

Friday, March 6th, 2009

A esta altura repasamos ya en el blog varios temas básicos, y hasta tuvimos un pantallazo de la transacción PFCG para poder crear y modificar roles (grupos de autorización o papeles).

Pero ahora hay un tema bastante importante que tratar, porque tiene implicancias bastante serias para el éxito o fracaso de un proyecto de seguridad SAP. Este tema es, justamente, el NOMBRE que les vamos a asignar a estos roles, siendo que el mismo está acotado a 30 caracteres como máximo.

El tema es bastante crítico y existen pocas reglas universales a aplicar al momento de bautizar a los pequeños roles, pero vamos a tratar de enumerar algunas pautas importantes:

1 – La única regla universal… TODOS los roles deben empezar con la letra Z (a lo sumo con la Y)… Esta notación nos va a servir como en cualquier ámbito de SAP para diferenciar lo que nosotros creamos, de lo que es estándar de SAP. Adicionalmente. si trabajamos con los roles estándar sin modificar su nombre y el día de mañana actualizamos la versión de SAP (cosa probable), es también altamente probable que sean sobrescritos por los nuevos, entre otros problemas.

2- Se acabaron las reglas universales… y a partir de ahora arranca la creatividad del diseñador de la seguridad para hacer un buen trabajo. Si aunque parezca mentira, algo de creatividad podemos aplicar en este trabajo ;-)

3- Si existe el requerimiento organizacional que la seguridad sea descentralizada tenemos que preocuparnos por los primeros caracteres que vienen después de la Z. Por ejemplo… si tenemos que crear una seguridad en donde cada oficina de cada país que acceda a SAP va a tener un administrador propio, podríamos empezar nuestro roles como: “ZAR” para Argentina, ZUY para Uruguay, y así sucesivamente.

De esta manera podemos hacer que cada administrador de seguridad esté limitado a gestionar los roles que comiencen con las siglas de su país. Esto se logra limitando a los administradores de seguridad en el objeto S_USER_AGR. Cómo podrán imaginar esta restricción puede hacerse para muchas cosas y por muchos motivos distintos, por ejemplo, para restringir la modificación de roles de base, restringir la modificación de los roles de seguridad, y un largo etc.

El hecho es que solo vamos a poder hacerlo por el principio del nombre de los roles, con lo cual es importante determinar este requerimiento apenas comenzamos a definir la nomenclatura.

4- Otra alternativa es definir, después de la Z, el módulo sobre el que “mayoritariamente” los roles van a dar acceso. Aunque no soy particularmente afecto a esto ya que depende el criterio que se use para construir los roles puede que este no respete los “límites de los módulos de SAP”. En este caso nuestros roles serían algo como “ZAP*”, “ZTR”, etc.

También puede hacerse uso de criterios que nos ayuden a identificar el proceso al que pertenecen los roles (si se encuentran tipificados en la organización)

5- Las posibilidades para las primeras letras son númerosas y mucho va a depender de las necesidades organizacionales. En algunas ocasiones para facilitar la lectura puede utilizarse un separador, pero siempre tengamos en cuenta que la cantidad de caracteres que tenemos para nomenclar un rol son relativamente escasos. Ejemplo: “ZMM:CMPR”, “ZUY:SLCT”

6- Ahora ya utilizamos los primero para la Z, los segundos para el país y hasta a lo mejor alguno más, y nos encontramos parados después de un separador. El resto va a depender mucho de como construyamos en si los roles, si nos enfocamos en puestos de trabajo, en actividades, etc.

En un próximo artículo vamos a tratar especificamente esto, pero hoy escapa un poco a lo que es la nomenclatura. Lo ideal independientemente de esto sería generar nomencladores estandar de 4 letras (+ o – según las variantes) por ejemplo de manera que un rol se llame: “ZAR:CMPR_SLCT”. Así estaríamos creando un rol propio (Z), para Argentina (AR), el cual pertenece al circuito de COMPRAS (CMPR) y su función es la de SOLICITANTE (SLCT).

7- Hasta aquí identificamos un rol, pero nos faltaría identificar en el mismo las variantes, ya que por ejemplo en este caso podrían existir roles separados por Centro, Organización de Compra, etc. Con lo cual el rol si el centro es A001 podría pasar a llamarse “ZAR:CMPR_SLCT-AR01″. De esta manera si utilizamos roles con herencia (Padre e Hijo) podriamos llamar al padre ZAR:CMPR_SLCT y los sucesivos hijos para cada centro serían *-AR01, *-AR02, etc. Podría seguir extendiendose para posibles variantes con Organización de compra hasta que los caracteres alcancen.

Es importante tomar conciencia que la nomenclatura es sumamente importante a la hora de definir los roles, y que adicionalmente es muy importante instalar el tema, incluso, al momento de realizar las definiciones más “grandes” del proyecto. Ya que la complejidad o simplicidad de la seguridad puede verse muchas veces afecta por la nomenclatura que utilizan los Analistas Funcionales a la hora de definir cosas tan globales para SAP como las Sociedades, Centros, Organización de Compras, Tipos de Documento, Divisiones, y un largo Etc.


VN:F [1.8.2_1042]
Rating: 5.0/5 (4 votes cast)
VN:F [1.8.2_1042]
Rating: 0 (from 0 votes)

Roles Derivados (Padres e Hijos, Herencia)

Thursday, March 5th, 2009

Ya sabemos que existen roles simples (los grupos de autorización o papeles que ya conocemos), otros que pueden ser compuestos (los roles que contienen roles simples, una suerte de grupo), pero hasta ahora no habíamos oído hablar de Roles Derivados o Herencia de Roles.

Los Roles Derivados son  un concepto muy vinculado con los niveles organizacionales. Ya que básicamente nos permiten definir un Rol como Padre, y después un conjunto de Hijos que van a heredar de este algunas características.

Entre estas características los hijos van a heredar los códigos de transacción que el padre posea, como así también (si están definidos) los valores de los objetos de autorización. Pero ahí se encuentra la diferencia con una simple copia de roles… Van a heredar todos los valores MENOS los que estén definidos como niveles organizacionales, estos últimos van a variar de cada hijo en hijo. Esto resulta muy util a la hora de crear permisos abiertos por locación geográfica o por departamento dentro de la organización, o por cualquier criterio para el que se hayan definido criterios como Sociedad, División, Centro, Organización de Compras, etc. De esta manera estos roles compartiran por ejemplo, las actividades que pueden realiarse sobre una Sociedad, pero no la Sociedad sobre las que pueden realizarse.

Por ejemplo: Podríamos tener un rol de nombre Z:ANLS_CBLE como padre, y dos hijo llamados Z:ANLS_CBLE-1000 y Z:ANLS_CBLE-2000 cada uno con permisos a una sociedad distinta. El día de mañana en caso de necesitarse una modificación en la funcionalidad, solo se tocarían los roles padre y la misma se distribuiría en los roles hijos.

Cuando estén trabajando con este tipo de roles, podrán apreciar que en los hijos no pueden realizarse inclusiones de nuevas transacciones, ya  que SAP limita esto y solo pueden realizarse en el padre y heredadas en los hijos.

En un próximo post explicaremos paso a paso la creación de un rol derivado de otro y como se trabaja con los mismos ya que tienen algunas diferencias particulares.

VN:F [1.8.2_1042]
Rating: 2.8/5 (4 votes cast)
VN:F [1.8.2_1042]
Rating: +1 (from 3 votes)