En este caso de éxito hablaremos de la implementación de la herramienta de SAP® GRC Access Control convirtiéndose en la novena implementación de SAP® GRC Access Control que se hacía por parte de Inprosec considerando todos sus clientes. Dicha implementación completaría el uso de todas las herramientas de SAP® GRC por parte del cliente, con un proyecto de 14 meses de duración, dando inicio en noviembre 2021 y terminando en diciembre 2022.
El cliente del que hablamos es un grupo líder en el sector audiovisual europeo único en integración de contenidos, producción y distribución audiovisual. Proporciona la creatividad y las soluciones técnicas necesarias para diseñar, producir y distribuir cualquier proyecto audiovisual o multicanal.
El reto
Aunque partíamos con una ligera ventaja, ya que en la organización del cliente ya se utilizaban los principales módulos de GRC (PC – Process controls, RM – Risk Management y AM – Audit Management), el proyecto tuvo sus dificultades, las cuales podríamos dividir en varios apartados:
- Interfaz de usuario para acceso a GRC: aunque se ha mencionado al inicio de esta sección que el cliente ya utilizaba SAP® GRC, lo hacía a través de la interfaz de usuario NWBC (Netweaver Business client). Uno de los objetivos del proyecto fue dejar de utilizar esta interfaz, un poco obsoleta, para comenzar el uso del Portal Fiori, mejorando asi la experiencia del usuario y habilitando el uso de GRC en diferentes dispositivos.
- Gestión de accesos de emergencia: el concepto de usuarios de emergencia no se había utilizado antes y eso hizo que la definición de este tipo de accesos fuese compleja. Aun así, se optó por una estrategia sencilla generando accesos alineados a los riesgos de accesos de negocio e IT más importantes para la organización.
- Gestión de riesgos de acceso: aunque no existía una matriz de accesos propia, desde el cliente ya utilizaban la matriz de riesgos estándar de SAP® para la reingeniería de su modelo de roles, por lo que aquí sí que no se partía desde cero. La complejidad vino más por la valoración e identificación de riesgos de acceso clave y el análisis del gran número de transacciones zeta (> 1,6K) y aplicaciones UI5 de negocio personalizadas.
- Procesos de aprovisionamiento de usuarios: la mayor dificultad estuvo en la adaptación del proceso de gestión de usuarios, donde además del cambio tecnológico, se tuvieron que hacer cambios a nivel funcional. El proceso de gestión era totalmente manual, gestionado por 2 niveles de servicio, con numerosas etapas y apoyado en una herramienta de tickets (JIRA) y el uso de correo electrónico para obtener las aprobaciones necesarias.
Además de lo anteriormente mencionado, se tuvo que ir adaptando el proyecto ante cambios no previstos inicialmente, se enumeran los más importantes:
- Migración sistema SAP® GRC (On Premise –> Cloud (RISE)): por estrategia de la organización, al inicio del proyecto, se tomó la decisión de migrar el sistema GRC en el que se trabajaba a entorno cloud. Este cambio estratégico hizo que la disponibilidad del nuevo sistema SAP® GRC se retrasase 5 meses.
- Cambios clave en la estructura organizativa: al inicio del proyecto se trabajó muy de cerca con el Área de Seguridad, que era la principal autoridad con la que se definieron y validaron los diseños de los procesos. Este departamento sufrió cambios que hicieron que se tuvieran que revisar y actualizar los diseños ya aprobados de los flujos de gestión de usuarios.
- Integración SAP® GRC Acccess Controls con gestor de identidades (One Identity – OI): uno de los objetivos del proyecto era la integración entre One Identity y GRC Access Controls. Este objetivo estratégico hizo que se tuviesen que adaptar los diseños de los flujos de aprobación de usuarios y el formulario de GRC, alargando el proceso de aceptación de estos. Finalmente, esta integración se tuvo que separar del proyecto de implementación de GRC AC en un proyecto paralelo, pero se mantuvieron los requisitos de diseño, GRC AC solo podía salir a producción si se mantenía la adaptabilidad a la integración con OI.
Una vez entendidos todos los retos que se presentaron, en la siguiente sección se expondrán cómo se les hizo frente y los hitos que se consiguieron en cada fase.
Solución Inprosec
El proyecto propuesto por Inprosec buscaba una solución dividida por fases, con un plan alineado a las dificultades anteriormente descritas.
La duración de cada una de las fases descritas a continuación se estimó en 2,5 meses, con una duración total de 6 meses, pero que tuvo que alargarse hasta los 14 meses para adaptarse a los problemas encontrados durante la ejecución.
Fase 1 – Implementación GRC EAM (Emergency Access Management)
- Definición – Accesos de emergencia de IT y negocio en base a roles basados en buenas prácticas. Se generaron roles de IT en base a un modelo buenas prácticas, que luego el cliente podría reutilizar para la correcta gestión del mínimo privilegio a la hora de asignar accesos de IT.
- Responsables – Se definieron aprobadores y revisores de logs específicos por proceso: IT, Finanzas, HR y BW.
- Flujos de aprobación (x3):
-
- Creación/modificación de accesos
- Aprobación de accesos
- Revisión de logs
Fase 2 – Implementación GRC ARA (Access Risk Analysis)
- Matriz negocio – Definición partiendo del estándar recomendado por SAP®, incluyendo riesgos relevantes derivados del análisis de las 1.600 transacciones zeta existentes en el sistema ECC
- Se analizaron las aplicaciones UI5, pero finalmente no se pudieron incluir debido a su alto grado de personalización.
- Matriz IT – Se utilizó de base la matriz de riesgos interna de Inprosec alineándola al último informe de los auditores externos del cliente.
- Niveles de riesgo – Se alinearon a la política de gestión de riesgos interna (Marginal, Leve, Moderado, Grave, Muy grave y Crítico
- Responsables de riesgos – Por proceso: IT, Finanzas, HR y BW.
- Flujos de aprobación (x2):
-
- Creación/modificación de riesgos
- Creación/modificación de funciones
Fase 3 – Implementación GRC ARM (Access Request Management)
- Definición de procesos – Considerando la situación actual y la posibilidad de integración con One Identity y el uso de SSO (Single Sign-On).
- Base de datos de usuarios – SAP® HR (HCM), módulo activo dentro del sistema SAP ECC.
- Identificador único – A través del proyecto, se solicitó la creación automática y controlada del SAP® User ID (infotipo 0105) como identificador único de los usuarios en los sistemas SAP®, esta fue una mejora significativa en la gestión de identidades derivada del proyecto de implementación.
- Puestos de trabajo – Se habilitó el uso de los puestos de trabajo (utilizando el campo «Function» para ligarlo con roles compuestos) para facilitar el aprovisionamiento.
- Campos personalizados – Se configuraron ciertos campos custom para facilitar la integración con JIRA (herramienta de tickets) y One Identity: nº ticket, licencias, sociedades adicionales y usuario de referencia.
- Flujos de aprobación (x5):
-
- Creación
- Modificación
- Bloqueo y desbloqueo
- Eliminación
Acompañando a las fases anteriormente mencionadas, se fueron diseñando y validando los roles que daban acceso a las distintas aplicaciones Fiori del Portal, generando los siguientes roles principales:
- Firefighter ID
- Solicitante EAM
- Propietario y Revisor
- Solicitante de GRC
- Administrador Gestión
- Visualización Informes EAM
- Visualización Informes ARA
- Ejecutor análisis de riesgos
- Visualización Informes BRM
- Visualización Informes ARM
Esta segregación permitió al cliente asignar los roles en función de las posiciones de cada usuario dentro de la gestión de procesos de GRC AC.
Finalmente, como apoyo documental al proyecto, se generaron los siguientes 3 tipos de documentos:
- Documento de procesos: describía el diseño de los procesos de cada módulo, los diagramas de flujo con sus principales actividades y la matriz RACI asociada. Además, a petición del área de Control Interno, se incluyeron puntos de control dentro de cada proceso para que formasen parte de la matriz de controles interna con el objetivo de validar periódicamente que los procesos definidos se estaban ejecutando tal y como se había definido.
- Diseño técnico: contenía el detalle técnico de la implementación para hacer que el cliente y su equipo técnico de GRC fuese independiente en el mantenimiento tras el despliegue y la finalización del periodo de PGLS.
- Manuales formativos y de uso: describía las principales funciones de los roles definidos dentro de cada proceso, con ejemplos simulados (casos) para facilitar el entendimiento de la herramienta y la transferencia de conocimiento en caso de ser necesario.
En todo este proceso, fue clave y se identificó como una lección aprendida positiva el gran apoyo recibido por parte de los departamentos de Control Interno, IT y SAP® GRC, siendo clave su participación en el diseño, pruebas de UAT, paso a producción de cada uno de los módulos y gestión del cambio para manejar las expectativas y oposición del usuario final a los cambios derivados del proyecto.
Resultados
La implementación de GRC Access Controls trajo consigo numerosos beneficios a la organización del cliente, a continuación, se resumen los principales relacionándolos con cada módulo:
EAM – Gestión de usuarios de emergencia:
-
- Habilitación de la monitorización del uso de accesos críticos (IT/Negocio) en entornos productivos reduciendo asi los niveles de riesgo de este tipo de acceso en entornos productivos.
- Remediación de deficiencias de auditoría (p. ej. acceso de debug en usuarios de IT).
- Mejora en la visibilidad sobre problemas en procesos de negocio durante las revisiones de logs de accesos de emergencia.
ARA – Gestión de riesgos de acceso:
-
- Aumento de visibilidad sobre el estado de riesgos de acceso en los sistemas SAP® para poder priorizar los planes de reducción de riesgos.
- Activación de la monitorización preventiva y en tiempo real del nivel de riesgo antes de la creación de cuentas en SAP® involucrando a los responsables de cada proceso (integración con flujos de aprobación).
- Habilitación de las simulaciones de riesgos por cambios en accesos para apoyar en los proyectos de rediseño del modelo de roles que el cliente estaba acometiendo.
- Se introdujo el control sobre los riesgos de acceso en transacciones zeta existentes.
ARM – Flujos aprovisionamiento de usuarios:
-
- Simplificación y centralización de las actividades del proceso de gestión de usuarios: menos grupos implicados, disminución de errores y una misma herramienta.
- Automatización de los procesos de gestión de accesos de usuarios, disminuyendo tiempos en el procesamiento de solicitudes.
- Mayor control en la asignación de accesos mediante la involucración de los aprobadores de los accesos y riesgos dentro del flujo de aprobación.
- Mejora de la trazabilidad sobre cambios en usuarios, pasando de mantener evidencias en varios lugares (correo y en herramienta de gestión de tickets) a estar todo disponible en el log de auditoría de SAP® GRC AC.
Para finalizar, es importante destacar que el objetivo principal fue siempre la mejora de los procesos de gestión de usuarios y accesos del cliente, maximizando el uso de las funcionalidades estándar de SAP® GRC AC, evitando asi procesos personalizados que dificultasen el mantenimiento y gestión de cambios de la herramienta a futuro.
