El primer caso de éxito destacable de nuestra compañía fue la creación de un cliente maestro (“Golden client”), para el aprovisionamiento de usuarios (“user provisioning”) con SAP GRC Access Control (5.3, de aquella) en Unilever.
Por esta razón, queremos contaros como ha sido el proceso y lo más destacable de este caso que fue presentado en el evento de SAP GRC europeo en Milán, en 2012.
En este evento se presentaban varios casos de Unilever, pero éste en concreto era el único de la aplicación de Access Control de SAP GRC.
UNILEVER es una de las mayores compañías del mundo, siendo una de las empresas líder en bienes de consumo de origen anglo-holandés. Además de pertenecer al Fortune 500, se encuentra en el Euro Stoxx 50 y en el FTSE 100.
El reto
Por aquel entonces (2011) Unilever no disponía de un sistema de gestión de identidades (“Identity Management”) para SAP. Sin embargo disponía de un gran número de sistemas SAP sin una centralización y coordinación en relación a los nombres de las cuentas de usuario y la asignación de las licencias de uso (lo que determina el coste del sistema para la empresa). Cuando se creaba un usuario en un sistema, lo hacía un equipo distinto, manualmente y con nomenclatura y criterios distintos. Esto provocaba que para una misma persona, los datos del usuario eran distintos en función del sistema.
Por lo tanto, la compañía estaba pagando más de lo necesario y además tenía falta de control sobre aquellos usuarios que tenían cuentas en distintos sistemas, pero no estaban identificados como el mismo usuario. Esto indirectamente supone un riesgo mayor respecto al control de riesgos de acceso, principalmente en la Segregación de Funciones (SoD).
Un usuario podría tener una cuenta en el sistema A y una cuenta en el sistema B, pero al tener identificadores y nombres distintos, se consideraban dos usuarios distintos, por lo tanto, los posibles conflictos de acceso por disponer de accesos incompatibles en el sistema A con los del sistema B nunca serían detectados.
Solución Inprosec
Inprosec trabajaba con Unilever desde sus orígenes, realmente podemos decir que Inprosec nació en gran parte gracias a Unilever – como hemos contado en el artículo de nuestro 10º aniversario. Desde 2010 ya trabajábamos con Access Control, la herramienta de SAP GRC para la gestión de gobierno, riesgos y cumplimiento; donde se empezó con la solución original de VIRSA y en aquel momento ya se había actualizado a la última versión JAVA (la 5.3) antes de migrar a la versión 10.0 basada en ABAP. En concreto la solución se conseguía mediante la implementación de un “Golden client” (repositorio central de datos de usuario) integrado con la aplicación de aprovisionamiento de usuarios dentro de SAP GRC Access Controls (de aquella denominada “CUP – Compliant User Provisioning” y a día de hoy, desde GRC 10 denominada “ARM – Access Request Management”).
En el momento Unilever no disponía de una solución de gestión de identidades (“Identity Management”) que incluyese los sistemas SAP y además su implementación suponía un proyecto de gran envergadura y de otra área de responsabilidad, sin embargo, la necesidad desde un punto de Control Interno era importante; y por lo tanto se definió una solución que permitía el propio uso de la base de datos de usuarios del sistema GRC como repositorio central y, ligado al uso continuo de la herramienta de GRC AC (CUP/ARM) para el aprovisionamiento de usuarios, iba realizando la limpieza de los mismos.
Mediante el uso de roles por defecto, una nomenclatura y campos clave para los usuarios, cada vez que se daba de alta un nuevo usuario, éste se creaba en el repositorio central (Golden Client) y en todos los sistemas que fuese necesario inicialmente. A partir de ese momento esa sería la identidad del usuario para siempre, y siempre que se fuesen a crear cuentas en otros sistemas para el mismo usuario, se identificaría con el que ya existía en el “Golden Client” y en los demás sistemas se crearía siempre con los mismos datos de manera alineada y robusta.
El uso del sistema y el proceso definido conseguían de manera automática la limpieza del sistema (aunque hubo que hacer alguna revisión y reemplazo de cuentas antiguas, pero fue menor) – como veremos en una gráfica a continuación.
Además otro elemento que ya existía, pero que se mejoró, era una parte importante de la solución: “Dormant Deletion program” – el programa de borrado de cuentas sin uso (o “dormidas”). Este proceso permitía ir eliminando aquellas cuentas antiguas (con nomenclatura antigua y no alineada) que se dejaban de usar al ser reemplazadas por las nuevas. Precisamente el ahorro en licencias venía por esta parte.
En la imagen podemos ver la arquitectura del sistema de GRC y su conexión a los diferentes sistemas (de manera anónima), con la identificación del “Golden Client”, tal y como fue presentado en Milán en 2012:
Resultados
La implementación de esta solución dentro de SAP GRC y complementada con un programa ABAP de limpieza (“dormant deletion program”) nos sirvió para conseguir los siguientes beneficios:
Limpieza y mantenimiento del sistema
El primer y principal beneficio, de los que luego resultan la mayoría de los demás beneficios, es el tener un conjunto de sistemas más limpio y con un número menor de cuentas para gestionar, lo cual reduce los costes en diferentes áreas.
El volumen inicial de cuentas en 13 sistemas distintos era de casi 35.000 cuentas de usuario – el 50% de las mismas, unas 16.500 en el ERP/sistema principal – y no se podía determinar cual era el número de usuarios únicos. Después de la solución el volumen total de cuentas era inferior a las 20.000 y el número de usuarios únicos por debajo de los 14.000.
Mayor control sobre los accesos
Tras la implementación se obtenían varias mejoras de control sobre las cuentas de usuario y los accesos correspondientes. No solo permite la solución poder monitorizar y medir los distintos parámetros ahora de manera clara y precisa (antes no podíamos ni saber el número de usuarios reales en el sistema o conjunto de sistemas), si no que este hecho permite ser capaces de monitorizar riesgos de acceso por segregación de funciones que sean “cross-system” (algo que explicaremos en un artículo técnico en detalle) o también denominados “cross-application risks” (riesgos entre aplicaciones).
Reducción del coste en licencias de usuario
El beneficio más tangible y cuantificable fue la reducción del coste de licencias, puesto que antes de la solución estimamos que el número de usuarios “únicos” eran de unos 20.000. Después de la solución nos quedamos con una cifra real y precisa de unos 14.000 usuarios distintos por los que se empezaría a pagar licencia. Estimamos que con pongamos un gasto media de licencia por usuario de unos 1.000€ al año, suponían unos 6M€ de ahorro anuales. Antes se podía estar pagando por cuentas que realmente estaban inactivas y en varios casos varias veces por cuentas que realmente pertenecían a la misma persona (usuario).
Auto-mantenimiento y auto-gestión
Precisamente mediante ciertas funcionalidades técnicas de SAP GRC se podían automatizar y darle robustez y sostenibilidad y continuidad a la solución, lo cual podemos ver en un ejemplo muy claro en la gráfica a continuación. Donde mediante el auto-aprovisionamiento en el propio repositorio (“Golden Client”) el sistema mejoraba y se limpiaba automáticamente solo con el uso.
En la siguiente gráfica, podemos ver la parte final de la reducción de cuentas innecesarias y como los identificadores de usuario se iban incrementando en el “Golden Client”, igualándose a los usuarios únicos:
