Entendiendo cómo funcionan los roles y perfiles dentro de SAP ERP
En Xamai, queremos hablar acerca de los roles y perfiles en SAP que son términos que se utilizan a menudo, de manera errónea pues no son sinónimos. Hoy vamos a explicar a detalle qué es un rol y un perfil y todos los elementos correspondientes a ellos para que tengas total conocimiento de su función.
¿Cuáles son los roles y perfiles de SAP?
Para entender mejor qué son, debemos hablar un poco sobre las primeras versiones del sistema SAP, ya que en aquel entonces no existían roles, solo perfiles.
Los perfiles se refieren a los elementos que permiten asignar autorizaciones a los usuarios que utilizan el sistema SAP. A través de ellos es posible habilitar a los usuarios para que utilicen el sistema.
El concepto de rol ha sido introducido más recientemente que el de perfil o perfil de autorización.
Pero intentemos dar una definición y luego desarrollarla:
Un perfil es un contenedor de autorizaciones y un rol es un contenedor que está conformado de tres partes: menú, autorizaciones y asignación de usuarios. Quizás esto aún no esté del todo claro.
Decíamos que antes, para asignar autorizaciones a los usuarios, sólo existían los perfiles. Eso es cierto. Para que un usuario pudiera ejecutar, por ejemplo, una solicitud de compra o un pedido, era necesario identificar todos los objetos de autorización requeridos para que estos aspectos del proceso funcionaran.
Todos estos objetos tenían que ser colocados con precisión en un perfil y ese perfil tenía que ser luego asignado al usuario o usuarios.
Esto era muy laborioso y requería mucho tiempo, sobre todo porque hay más de 3000 objetos de autorización definidos en un sistema SAP. El proceso se llevó a cabo mediante ensayo y error.
Los roles, entonces, tienen la capacidad de simplificar la gestión de autorizaciones de SAP, introduciendo así el RBAC (Role Based Access Control) o Control de acceso basado en roles.
¿Cómo se realiza este proceso?
Anteriormente a través de perfiles, el responsable de seguridad tenía que conocer todos los objetos a habilitar, hoy, a través de roles es posible asignar la transacción que una persona tendrá.
Esto significa que el rol (a través de la transacción PFCG - Generador de perfiles) permitirá recuperar toda la información necesaria (desde el punto de vista de las autorizaciones) para que el usuario, una vez asignado el rol, pueda trabajar.
Los perfiles y los roles no deben utilizarse juntos. Por lo tanto, los perfiles son un legado del pasado (aún activos en el sistema) pero "ocultos" a través de la gestión de roles. Por lo tanto, no deben utilizarse. ¡Solo deben utilizarse los roles!
¿Los roles de SAP facilitan la gestión de autorizaciones?
Sí. Aunque depende de cómo las estructures. En el entorno de autorización de SAP, realmente es así: cualquiera puede hacer que las cosas funcionen fácilmente tratando de definir un concepto de autorización.
Pero una cosa es hacer que funcionen y otra muy distinta es hacer que funcionen como deberían y, sobre todo, gestionarlos a lo largo del tiempo de forma adecuada.
Es común, de hecho, encontrar situaciones de modelos de autorización definidos al principio del proyecto y luego superpuestos, modificados sin mucha lógica por varias manos a lo largo del tiempo, hasta el punto en que debes revisar todo.
¿Qué pasa cuando se tiene acceso a los roles y administrador de perfiles?
Los roles y autorizaciones permiten a los usuarios acceder a SAP Standard y a transacciones personalizadas de forma segura para la empresa.
No hay opción a riesgos porque SAP proporciona un conjunto determinado de roles estándar genéricos para diferentes módulos y diferentes escenarios dependiendo de lo que pase en la empresa.
También podemos definir roles en función del escenario del proyecto teniendo en cuenta lo siguiente:
Existen dos tipos de roles:
Roles maestros: con transacciones, objetos de autorización y con toda la gestión a nivel organizacional.
Roles derivados: con gestión a nivel organizacional y objetos de transacciones y autorización copiados del rol maestro.
Componentes que tiene un Rol
Un rol maestro o un rol derivado tiene los siguientes componentes en su interior:
- Códigos de transacción
- Perfil
- Objetos de autorización
- Nivel de organización
Códigos de transacción
Los códigos de transacción (T-Codes) son comandos que permiten acceder rápidamente a diferentes funcionalidades dentro del sistema SAP. Un rol contiene los T-Codes que el usuario podrá ejecutar, definiendo así las transacciones que están autorizados a utilizar.
Perfiles
El perfil es una estructura que agrupa las autorizaciones de un rol. Cada rol tiene un perfil asociado que recoge las definiciones de acceso del usuario. Estos perfiles se crean automáticamente cuando se generan roles, y son los que realmente se asignan a los usuarios para otorgar los permisos.
Objetos de autorización
Los objetos de autorización son los elementos que definen qué datos específicos puede acceder o modificar un usuario al realizar una transacción. Estos objetos permiten un control detallado sobre qué operaciones pueden ejecutarse dentro de una transacción, incluyendo restricciones por tipo de actividad o nivel de información que se puede ver.
Nivel de organización
El nivel de organización se refiere a las estructuras organizacionales que limitan las autorizaciones dentro de un rol. Por ejemplo, un rol puede restringir las autorizaciones a una empresa específica, una planta, o una unidad organizativa. Esto asegura que el acceso a la información y las transacciones esté limitado a ciertas partes de la organización.
Diferencias entre Roles Maestros y Roles Derivados
Roles maestros: mantiene todos los códigos de transacción y los objetos de autorización relacionados. Un rol maestro es un rol que sirve como plantilla o rol base para crear roles derivados. Contiene un conjunto predefinido de autorizaciones y permisos que son comunes a un grupo particular de usuarios o procesos de negocios dentro de la organización.
Roles derivados: estos roles se derivan básicamente del rol maestro, que contiene sólo valores de la organización y se asigna al usuario. Hereda las autorizaciones y permisos del rol principal o principal y también puede tener autorizaciones adicionales específicas de la unidad organizativa.
Asignar todo el acceso organizacional al mismo usuario no es una práctica de seguridad adecuada. A los usuarios solo se les permite tener acceso a un nivel organizacional específico según su ubicación y responsabilidades.
Por lo tanto, con el enfoque de roles Maestro y Derivado podemos brindar acceso a un nivel organizacional específico a los usuarios.
El papel del consultor funcional en la gestión de roles y autorizaciones
El equipo de BASIS tiene conocimientos sobre gestión de usuarios, creación de roles, creación de perfiles, asignación de roles y perfiles, asignaciones de autorización, etc., pero la principal preocupación en la mayoría de los casos surge cuando el equipo de BASIS no responde a las siguientes preguntas:
- ¿A quién asignar los roles o transacciones?
- ¿Qué y a quién se debe restringir una transacción?
- ¿Cómo autorizar transacciones personalizadas?
Este tipo de preguntas no pueden ser respondidas por el equipo de BASIS. En ese caso se hace presente el rol de un consultor funcional quien es la persona encargada de guiarlos en el organigrama exacto para que no haya lugar a dudas.
Para que se entienda mejor, te pondremos un ejemplo pequeño: supongamos que tenemos un equipo de mantenimiento con el siguiente organigrama:
- Supervisor: Es el encargado de notificar las averías o requerimientos de mantenimiento correctivo.
- Encargado de mantenimiento: es responsable de asignar las tareas anteriores a los ingenieros.
- Jefe del departamento: Es el responsable de aprobar las tareas de Mantenimiento.
En este caso, el Consultor Funcional es muy consciente de que para el Supervisor solo se requerirían las transacciones relacionadas con Notificaciones (por ejemplo, IW21, IW22, IW28, IW29, etc.), el Encargado de Mantenimiento requeriría algunas de las transacciones relacionadas con notificaciones (por ejemplo, IW22, IW28, IW29) y también transacciones relacionadas con pedidos (IW31, IW32, IW38, IW39, etc.) y el Jefe del departamento requeriría notificaciones y transacciones de pedidos (por ejemplo, IW28, IW29, IW38, IW39) y también junto con esto requeriría permisos especiales como liberar pedidos, aprobar permisos, etc.
Desde la perspectiva del equipo BASIS, no tienen claros estos requisitos y, por lo tanto, no pueden tomar la decisión al respecto y deben ser proporcionados por consultores funcionales.
Pero, el problema principal en la mayoría de los casos surge cuando los consultores funcionales no conocen el concepto de roles y autorizaciones por eso es necesario que esta información sea totalmente dominada.
Xamai tu mejor aliado
En Xamai te ayudamos a tener una mayor comprensión y optimización de tus roles y perfiles SAP. Dado que los roles simplifican la gestión de accesos mediante el Control de Acceso Basado en Roles (RBAC), En Xamai te ayudamos en la correcta implementación de estos roles y la organización de los accesos de los usuarios, asegurando que las operaciones fluyan de manera segura y eficiente.
Además, te podemos orientar en la creación y administración de roles maestros y derivados, permitiendo ayudarte a estructurar tus autorizaciones de acuerdo con tus niveles organizacionales y requerimientos específicos.
De esta forma, en Xamai no solo ayudamos a gestionar de manera eficiente los accesos, sino que también podemos colaborar en capacitar al equipo BASIS y a los consultores funcionales, para evitar errores y garantizar una administración coherente y segura de las autorizaciones a largo plazo.