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.
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.)
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
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.
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.
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.
Tags: construcción, metodología, Proyecto, roles, SAP, Seguridad
Excelente.. en que libro o site puedo ampliar esta información?
Miguel, la verdad que es una metodología desarrollada en varios proyectos en los que participé y que junta cosas de bastantes fuentes distintas. Espero que en este mismo blog puedas encontrar más adelante un poco de profundización que pensamos hacer sobre varios de estos puntos! Muchas gracias por comentar. Saludos!
Muy bueno, he utilizado la metodología y da resultados fabulosos.
Diego: impecable como siempre todo lo suyo, felicitaciones.
Abrazo
Para complementar lo relacionado a la segregación de funciones, existen mejores prácticas en este contexto y que etán incluidas en SAP GRC Access Control. Son reglas de incompatibilidad de transacciones en los roles de usuarios.
Quien quiera acceder a estas reglas envíeme un mal a amigogratis@gmail.com y se las haré llegar.
Saludos y muy bueno el post.
Echo en falta varios puntos fundamentales:
- Definir la matriz de segregación de funciones a utilizar (si no, es imposible realizar un análisis de SoD) que es diferente en cada CIA especialmente en lo que respecta a transacciones z (aunque las funciones incompatibles sean fácilmente reutilizables en todos los casos)
- Definir y poner en marcha los procedimientos que garanticen que el modelo definido inicialmente sin incompatibilidades se mantiene en el tiempo (qué normas seguimos al modificar los roles o crear nuevos y cuáles son los pasos para asignar nuevos roles a los usuarios, que deben incluir siempre una validación de que se mantienen los criterios de SoD)
También es relevante aclarar un problema común en muchas organizaciones: en el paso 1 – identificación de roles, se tiende a asociar “rol” con puesto organizativo. Esto es un tremendo error que puede llevar al fracaso cualquier modelo, ya que los roles organizativos evolucionan y cambian en el tiempo, obligando a continuas modificaciones del rol SAP. Lo correcto es identificar aquellos grupos de tareas indivisibles que en general siempre se utilizan juntas y serán necesarias para un mismo usuario (ej. mantenimiento de materiales).
Un saludo
Buenas! Gracias por tu participación! La realidad es que es la reseña de una metodología. La idea es, en posteriores posts, profundizar sobre cada uno de esos pasos, o al menos sobre los más importantes. Puntualmente el tema de SoD lo pensaba tratar en otro post aparte pero estoy tratando de armar algo interesante al respecto. Sobre la construcción de roles por tareas indivisibles y no por puestos de trabajo jajaja siento que escucho las mismas palabras que repetí tantas veces (y creo en algún post lo dije antes). Pero es TAN DIFICIL hacer entender ese concepto y separarlo del “puesto”… Aunque con paciencia y algunas cosas aprendidas se puede hacer. De nuevo muchas gracias por el aporte! Saludos! Diego
Buenas!
esta muy bien este procedimiento, yo quisiera agregar que en mis años de consultoria en seguridad. solo en un solo proyecto tuve los procesos de negocio como imput para armar las agrupaciones de actividaes.
normalmente no existe dicha estructura. los funcionales no le dan importancia al tema y los key users no estan muy involucrados.
entonces el equipo de autorizaciones tiene que evaluar los organigramas. hacer un relevamiento de uqe se usa. y extrapolar de algun otro proyecto o de los roles standar de sap.
me hubiera encantado tener los procesos y es algo que siempre trato de tener. pero la verdad es que nunca se dio.
saludos
Mosquito
Y si es verdad! es poco común tener los procesos disponibles y hay que luchar mucho por darle la importancia que merece a este tema. Esperemos con el tiempo poder “evangelizar” algo más en seguridad! Saludos!
Buen día,
Esta muy bien el procedimiento, pienso utilizarlo para una implementación con Oracle.
Con respecto a tener disponibles los procesos de negocios creo también que es una parte fundamenteal y si no se tienen entonces el proyecto debe iniciar por la elaboración del mapeo de los procesos, de esa manera el proceso pudiera ser utilizado tanto para la mejora de los procesos, así como para la segregación de funciones.
Saludos