Te presentamos una de las primeras implementaciones de SAP® GRC Access Control en VCEAA. En este post detallaremos la configuración de la totalidad de sus 4 módulos (ARA-Access Risk Analysis; ARM-Access Request Management; EAM-Emergency Access Management; BRM-Business Role Management)
VCEAA es la filial de Votorantim Cimentos en Europa, África y Asia. Votorantim Cimentos forma parte del TOP 10 de las mayores cementeras del mundo:
EL RETO
La dificultad de este proyecto venia por dos directrices diferentes, por un lado, la parte tecnológica que venia de la herramienta de GRC donde había un módulo para la Gestión de Roles a través de SAP® GRC que no había sido implementado de manera tan frecuente como el resto de otros módulos, y por otro lado un tema más organizacional donde había ciertos procesos que no estaban implementados organizativamente hablando. Se había desarrollado una nueva nomenclatura para los roles, pero no estaba implementada en todos los sistemas. Adicionalmente, el proceso de altas, bajas y modificaciones en SAP® tenia que ser revisado para buscar mejoras de cara a aumentar la seguridad del proceso.
Por otra parte, otro de los retos era aumentar el retorno de la inversión de la Licencia de SAP® GRC Access Control buscando utilizar la totalidad de la herramienta para ganar una mejor eficiencia y seguridad en los procesos de accesos de los usuarios en SAP®.
SOLUCIÓN INPROSEC
Se acordó ampliar las funcionalidades que existían en el GRC anterior, que solamente disponía de la solución de “Password Self Service” y del proceso de aprovisionamiento de accesos en Turquía, para incorporar el uso de EAM y BRM a la organización de VCEAA y adicionalmente desplegar ARM para el resto de los países.
Anteriormente, el sistema de GRC disponía de una Matriz de Riesgos de Segregación de Funciones y el proceso de aprovisionamiento de usuarios de SAP® en Turquía. A continuación, se detallan las actividades clave.
- Implementación y Despliegue de Controles Mitigantes (ARA).
- Implementación Global de EAM.
- Implementación Global de ARM.
- Implementación Global de BRM.
ARA – Access Risk Analysis
Se actualizó la Matriz de Riesgos de Accesos en SAP® pasando de monitorizar solamente 24 Riesgos de Segregación de Funciones a 46 y adicionalmente se incluyeron un total de 28 Acciones Criticas, quedando la Matriz Final de Riesgos de Acceso de la siguiente manera:
Adicionalmente se incluyeron Transacciones Z a la Matriz Final de Riesgos de Acceso que anteriormente no estaban siendo monitorizadas.
EAM – Emergency Access Management
Se implementó el módulo completo definiendo una estrategia de accesos de emergencia de manera global. Todos los países de la organización de VCEAA estaría compartiendo esta misma estrategia y no se crearían accesos de emergencia de manera local:
La estrategia tenia un total de 7 Accesos de Emergencia diferenciados en uso. Existía un Firefighter relacionado con accesos de IT, un Firefighter para el acceso OSS de SAP®, un Firefighter con accesos de Seguridad en SAP®, ….
Adicionalmente se activó el Workflow de Revisión de Logs de Firefighter para asegurarse que todos los accesos y modificaciones eran revisados.
Se sacaron estadísticas sobre los primeros meses de Uso y estos fueron los resultados:
ARM –Access Request Management
La implementacion del modulo de ARM se hizo en paralelo con un proyecto de Rediseño de Roles puesto que con el modelo anterior iba a ser muy complicado mejorar la eficienta del proceso de aprovionamiento.
Finalmente el proceso de aprovisionamiento para Altas y Modificaciones fue el siguiente:
Adicionalmente y como parte del modulo de ARM existía una funcionalidad que se llamaba HR Triggers. Esta aplicación permitía automatizar los procesos de creación de solicitudes basados en cambios realizados sobre el maestro de empleados en SAP® HCM.
Se realizó la implementación de los HR Triggers específicamente para el proceso de bajas, de manera que en el momento en que alguien desde el departamento de HR registraba una baja el sistema de GRC creaba automáticamente una solicitud para el bloqueo de la cuenta en todos los sistemas SAP® donde existiera.
BRM –Business Role Management
En este caso la dificultad era mayor puesto que no solo era un proyecto tecnológico, sino que requeriría también el diseño e implementación del proceso de Gestión de Roles en SAP®. Esto supuso que a medida que se iba diseñando el proceso se analizaba la implementación tecnológica de cada etapa para confirmar que era viable técnicamente.
Se diseñó un proceso de Gestion de Roles muy alineado a los procesos de Gestión del Cambio de las grandes organizaciones, para asegurar que el proceso estaría alineado con los requerimientos de auditoría y cumplimiento en materia de seguridad. El proceso de Gestión de Roles involucraba a las posiciones de “SAP® Security Manager”, “IT Quality Manager” y “Key User” (confirmación de las pruebas de aceptación del usuario).
RESULTADOS
Se cumplieron con todos los retos y objetivos del proyecto, aumentando notablemente el retorno de la inversión de la Licencia de GRC Access Control. Se eliminó la idea global de que la Licencia de GRC Access Control solo servía para analizar Riesgos de Segregación de Funciones y Acciones Críticas. Este cambio en la organización supuso una dinámica de mejora continúa dando paso a mejores versiones del sistema a medida que el tiempo avanzaba.
Como cualquier presentación de un “Case Study” en los eventos de GRC de SAP® es necesario destacar 7 puntos que mencionaremos a continuación.
- Estimar el doble de tiempo en relación con la parte formativa.
- Es un punto clave porque da igual que se implemente el mejor sistema del mundo si los usuarios no saben utilizarlo.
- Se tiene que crear un plan de comunicación para todas las fases del proyecto.
- Es importante que ese plan de comunicación esté alineado con los altos cargos de la organización para tener el mejor clima favorable en un proyecto tecnológico como es la implementación de SAP® GRC Access Control.
- Se debe tener cuidado con el despliegue de EAM, es importante definir una estrategia previa a la implementación técnica del módulo.
- Hay que evitar mal uso de Firefighter puesto que genera un sobresfuerzo en las tareas de revisión de Log.
- Se debe implementar todas las actividades disponibles en ARM para el proceso de aprovisionamiento de cuentas en SAP®.
- Hay actividades que sirven para el bloque y desbloqueo de usuarios que pueden ser útil en tu organización.
- En caso de que exista el sistema SAP® HCM se debe valorar la implementación de los HR triggers.
- Reducen mucho el esfuerzo en las tareas relacionadas con las bajas de usuarios en SAP® y aumentan la seguridad del proceso al solamente intervenir el Departamento de RRHH.
- Se recomiendo utilizar el reporting estándar que se incluye en SAP® GRC.
- Existen informes muy visuales sobre Riesgos de Accesos y Solicitudes de Aprovisionamiento.
- Se debe invertir tiempo en entender cómo funciona BRM.
- Esta herramienta supone un cambio respecto a la manera tradicional de crear y modificar roles en SAP® por lo que hay que entender que beneficios/ desventajas tiene para valorar la implementación en tu organización.
