Caso de Éxito: Implementación de SAP® GRC Access Control en SIGMA

La implementación de la herramienta de SAP® GRC Access Control en la organización de Sigma fue la primera implementación de SAP® GRC Access Control que se hacía por parte de Inprosec en México. Dicha implementación tuvo una diferencia respecto a otros casos de implementación de SAP® GRC AC puesto que fue la primera en la que se hizo una implementación del módulo de User Access Review (UAR) para cumplir con el requisito de auditoría para la recertificación de accesos. El proyecto tuvo una duración de 5 meses dando inicio en Noviembre 2018 y terminaría en Marzo 2019.

Sigma es una empresa multinacional mexicana que participa en la producción y distribución de alimentos refrigerados. Tiene la sede en el municipio de San Pedro, en la Zona Metropolitana de Monterrey, Nuevo León, México. Tiene operaciones en más de 20 países incluyendo México, Estados Unidos y Europa.

El reto

La dificultad del proyecto residía en por una parte adaptar el proceso actual que se estaba siguiente en el día a día en Sigma con la tecnología que ofrecía el sistema de GRC. Este punto es muy importante puesto que no solo estamos hablando de un cambio tecnológico, sino que incluía también una necesidad de un cambio organizativo o de gobierno. Otro de los retos que buscaba cubrir el proyecto se relacionaba con el proceso de gestión de roles donde se buscaba que la gestión de riesgos fuera incluida dentro del proceso para la creación/modificación de roles.

Desde la organización de Sigma se disponía de una Matriz de Riesgos que estaba siendo revisado por parte de auditoría externa. Esa matriz fue el primer paso en la creación de la Matriz de Riesgos de Sigma que supuso un paso adelante en la Gestión de Riesgos por parte de Sigma.

Solución Inprosec

La solución de Inprosec fue realizar un proyecto dividiendo las fases en función de la herramienta a implementar:

Fase I – Access Risk Analysis

 

Fase II – Access Request Management

 

Fase III – Business Role Management

 

Los Objetivos/Hitos que se buscaron para la primera fase fueron:

  • Actualización de la Matriz de Riesgos a la última versión del estándar de SAP®.
  • Activación de las Alertas del Riesgo
  • Análisis de Transacciones Z para incluir en la Matriz de Riesgos.
  • Creación de Controles Compensatorios
  • Creación de Matriz de Riesgos Sigma
  • Formación a partes interesadas.

Los Objetivos/Hitos que se buscaron para la segunda fase fueron:

  • Configuración de “Workflows” para Creación, Modificación, Eliminación de Usuarios en SAP®.
  • Reinicio de Contraseñas
  • Solicitud de Acceso para Firefighters
  • Recertificación de Roles (User Access Reviews)
  • Formación a partes interesadas.

Los Objetivos/Hitos que se buscaron para la tercera fase fueron:

  • Configuración de “Workflows” para Creación y Modificación de Roles en SAP®.
  • Carga Masiva de Roles (basados en el nuevo modelo de roles que estaba siendo implementado).
  • Automatización de Nomenclatura
  • Formación a partes interesadas.

En relación con la Fase I se definieron un total 13 Alertas de Riesgos centradas en escenarios de IT y que comunicarían de manera diaria todos los riesgos en los que se confirmará la ejecución de los Transacciones involucradas en dichos riesgos. Se marcó la opción de que aquellos usuarios que tuvieran un control compensatorio asignado se excluirían de dicha comunicación automática.

Otra herramienta a mayores y que se utiliza de manera frecuente en Sigma fue la utilización del Dashboard estándar de SAP® donde se pueden identificar todos los detalles de usuarios y riesgos existentes en la organización de Sigma:

Durante la Fase II, se trabajó en todo lo relacionado con el aprovisionamiento de usuarios. De cara a permitir una mayor flexibilidad a lo largo del proceso de aprovisionamiento se optó por la creación de un pequeño formulario que en función de la respuesta avanzaría de una manera o de otra a lo largo del proceso.

  1. La opción de autorización individual significaba que el acceso era solamente necesario para un usuario de la posición.
  2. La opción de autoriza posición significaba que el acceso debía ser entregado a todos los usuarios que formaban parte de la posición, de manera que esta selección suponía la creación de una solicitud de BRM para la actualización del rol de la posición.

Adicionalmente a lo que ya se había mencionado de ARM anteriormente, la fase II también incluía la implementación de la funcionalidad de User Access Review que permitía cumplir con el proceso de recertificación de accesos que estaba requiriendo Auditoría. Para el caso de Sigma, y debido a que estaba en proceso de reingeniería del modelo de roles, esta implementación fue más sencilla puesto que el proceso de recertificación se ejecutaría solamente a las posiciones que por el momento habían sido homologadas:

Finalmente, durante la Fase III, se realizó la implementación de la herramienta Business Role Management, que permite crear y modificar roles en SAP® a través de SAP® GRC. Se estableció un flujo completo que pudiera cumplir con el proceso de gestión del cambio que existía en Sigma:

Se trabajó con un único proceso activo en BRM y que permitía no solo el diseño y la creación del rol en el entorno de Desarrollo, sino que permitía su transporte a los sistemas de Calidad y Producción alineándolo con un proceso que soportase la gestión del cambio. Un punto importante fue la desactivación de cualquier tipo de actividad de eliminación de roles a través de BRM para evitar cualquier tipo de impacto en los sistemas satélites conectados a SAP® GRC Access Control.

Resultados

La implementación de la herramienta de Access Control en Sigma fue un éxito desde diversos puntos de vista: se activó una matriz de riesgos que cumplía con los requerimientos de auditoría y con las necesidades de Sigma, se generó un proceso de aprovisionamiento ágil para las creaciones y modificaciones de usuarios en SAP®, se implementó un proceso de gestión de roles que incluía la visibilidad de posibles riesgos de SoD que pudieran estar apareciendo como parte del proceso de creación/mantenimiento, se generó un proceso de recertificación de accesos que cumplía con el objetivo de auditoría. El proyecto se completó en los tiempos que fueron marcados en la versión inicial del plan y se obtuvieron todos los hitos marcados a lo largo del proyecto.

En relación con la parte técnica, fue la primera vez que se trabajó con un formulario sencillo para flexibilizar el proceso de aprovisionamiento lo cual ha sido utilizado en posteriores implementaciones. Se ha trabajado con el módulo de User Access Review y se ha comprobado que es una herramienta que puede cumplir con el objetivo de recertificación de accesos siempre y cuando se haga una correcta selección de los roles a revisar (es necesario un modelo de roles que disponga de posiciones homologadas).

 

¿Te ha gustado?

¡Compártelo en redes sociales!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Rellena este campo
Rellena este campo
Por favor, introduce una dirección de correo electrónico válida.
Tienes que aprobar los términos para continuar

Categorías

Calendario de entradas

Nuestros servicios

keyboard_arrow_up