En este artículo explicaremos en qué consiste el módulo de Gestión de Solicitudes de Acceso (ARM) de la herramienta GRC de SAP, y los diferentes usos y beneficios que tiene.
La Gestión de Solicitudes de Acceso pertenece al módulo de Control de Acceso (AC) de la herramienta GRC. SAP GRC Access Control ayuda a las organizaciones y empresas a detectar, gestionar y prevenir las violaciones de los riesgos de acceso y reducir el acceso no autorizado a autorizaciones, sistemas e información crítica. Este módulo cuenta con diferentes submódulos para controlar el Riesgo generado en una empresa (Análisis de Riesgos de Acceso), controlar el restablecimiento automático de contraseñas (Autoservicio de Contraseñas), uso de accesos de emergencia (EAM), etc.
Objetivos de ARM
En general, los objetivos de ARM son:
- Repositorio común/herramienta para elevar solicitudes de acceso para cambios de usuarios: cuando un empleado necesita actualizar sus autorizaciones o usuario en los sistemas SAP, eleva una solicitud que sigue automáticamente un flujo de trabajo específico.
- Revisión de solicitudes por usuarios específicos: las solicitudes pueden ser revisadas por gestores o aprobadores (como aprobadores de funciones o aprobadores de riesgos), y una vez completados todos los pasos.
- Los cambios en el sistema son realizados por un usuario del sistema: los cambios serán realizados automáticamente en los sistemas SAP por un usuario del sistema, siempre el mismo usuario del sistema. Con esta opción, todos los cambios en el sistema relacionados con la actualización de usuarios no son hechos por un usuario nominal, son hechos por un usuario del sistema, sólo cuando la aprobación correcta es hecha, para que las normas de seguridad o SoX sean correctamente seguidas.
Beneficios de ARM
Antes de hablar de cómo se puede configurar, es importante conocer los beneficios de ARM, los más importantes son:
- Existe un registro con todas las etapas del flujo de trabajo. Este registro puede descargarse de GRC y puede proporcionar información como el nombre de las etapas, los aprobadores, la hora de la revisión o los elementos aprobados o rechazados.
- Los flujos de trabajo pueden personalizarse a gusto de la empresa, con distintas etapas para que las revisen los directivos, los aprobadores de funciones, los propietarios de riesgos, etc.
- Los aprobadores se pueden asignar, por lo que no es necesario que un asesor envíe correos electrónicos solicitando una revisión.
- Las notificaciones pueden configurarse para cada paso y seleccionar por defecto el equipo que la recibirá y, por supuesto, el contenido de la notificación.
- Todos los cambios en el sistema serán realizados por un usuario del sistema.
- Los nuevos riesgos SoD o acciones críticas generados para los usuarios pueden ser revisados para decidir si son correctos y tienen el número de riesgos bajo control.
Por supuesto, hay más, pero estos son los más relevantes desde nuestro punto de vista. Si hablamos de la configuración, hay algunos puntos clave que es importante comprender:
Base de datos de usuarios (BD)
Se plantean Solicitudes ARM para crear o mantener usuarios, por lo que es necesario tomar los datos principales de los usuarios de una Base de Datos. Esta puede ser la SU01 de un sistema SAP conectado, un Directorio Activo u otro tipo de base de datos de sistemas conectados, como los sistemas de Recursos Humanos.
Es posible tomar diferentes tipos de datos de estas BBDD, los típicos son: nombre, nombre seguro, email, manager, departamento, etc. Pero hay otros más estándar, como tipo de empleado, teléfono, etc. Sin embargo, también es posible crear campos personalizados para tener más datos de la base de datos, como por ejemplo tipo de licencia o valores específicos.
Tipo de solicitudes
Existen diferentes tipos de solicitudes, las más útiles son:
- Crear/modificar cuentas.
- Bloquear/desbloquear cuentas.
- Eliminar cuentas.
- Solicitar usuarios de emergencia.
Por supuesto, estos son los más comunes, pero es posible crear diferentes tipos, como HR Triggers, que puede ser una solicitud automática cuando un usuario dejará la empresa, o solicitud para actualizar sólo los valores de los usuarios, como sus parámetros u otros detalles.
Notificaciones
Es posible configurar diferentes tipos de notificaciones para cada etapa. Las notificaciones pueden ser personalizadas, con datos específicos, datos personalizados, el logotipo de la empresa y mucho más.
Además, puede configurar a quién se pueden enviar estas notificaciones, por ejemplo, a los aprobadores actuales, al equipo de seguridad, a aprobadores o equipos específicos, o tal vez sólo al solicitante al final de la solicitud, las posibilidades son muchas.
Registro de auditoría y estado de la instancia
Existe una forma sencilla de conocer en todo momento el estado de una solicitud, consultando en la opción de «Buscar solicitud» el estado de la instancia. Esta opción da los principales detalles de la solicitud, que es el estado (pendiente o completa) de todos los caminos de la solicitud, que son los aprobadores pendientes (en caso de que haya) y el registro de la solicitud.
Además, es posible consultar y descargar el registro de todos los movimientos de la solicitud: asignaciones, decisiones, aprobaciones, comentarios, etc. Y el usuario asociado relacionado con estos cambios puede hacerlo y, la hora y fecha de ese cambio. Esta funcionalidad es muy útil en periodos de auditoría, apoyando la extracción de evidencias de forma sencilla, incluso con la opción de descargarlas en formato .pdf.
Puntos a revisar
Hay diferentes tipos de aprobadores porque hay diferentes tipos de elementos que aprobar:
- Roles: los roles a asignar o eliminar de un usuario pueden ser revisados por aprobadores específicos.
- Riesgo: los riesgos generados a nivel de usuario (o sólo los nuevos generados a causa de la solicitud) pueden ser revisados por aprobadores específicos.
- Datos del usuario: los datos del usuario, como nombre, apellidos, correo electrónico, parámetros, etc.
Por supuesto, estas opciones de funcionalidad no son las únicas de Gestión de Solicitudes de Acceso, pero teniendo en cuenta mi experiencia durante los últimos 6-7 años en diferentes clientes, son las más relevantes a tener en cuenta a la hora de diseñar GRC ARM desde una perspectiva funcional, algunas de las más relevantes.
