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.
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 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.
Fuente: www.seguridadsap.com
No hay comentarios:
Publicar un comentario