La Matriz de Permisos en el ERP: Clave para la Seguridad y la Eficiencia Empresarial
La implementación de un sistema de Planificación de Recursos Empresariales (ERP) es fundamental para la gestión de cualquier compañía. Sin embargo, su eficacia y seguridad dependen en gran medida de una adecuada configuración de roles y permisos. Una matriz de permisos en el ERP es un documento crucial que define el acceso y las capacidades de cada usuario dentro del sistema, asegurando que solo puedan realizar las tareas para las que están autorizados.
¿Por Qué es Crucial Definir Roles y Controlar el Acceso al ERP?
Aunque la definición de una matriz de permisos pueda parecer ambigua al principio, es un documento con filas y columnas donde se especifica a qué aplicaciones puede ingresar el equipo y qué acciones pueden realizar una vez dentro (ver, editar, administrar, etc.). Aunque pueda surgir la pregunta de por qué se necesita si todos los miembros del equipo son de confianza, es una implementación aconsejable, ya que tarde o temprano un cliente la solicitará en sus cuestionarios de ciberseguridad.
La definición de roles y permisos en un ERP no es solo una buena práctica, sino una necesidad imperante por varias razones:
- Seguridad de los datos: Es uno de los principales motivos para definir roles y permisos en un ERP, garantizando la seguridad de los datos empresariales. La definición de roles y permisos en el ERP permite cumplir con la normativa de protección de datos y restringir el acceso a información sensible únicamente a aquellos usuarios que están autorizados y capacitados para manejarla adecuadamente.
- Control de acceso y responsabilidades: La definición de roles y permisos en un ERP permite un control efectivo sobre quién tiene acceso a determinadas funciones y datos. Al asignar roles específicos, se puede limitar el acceso a módulos concretos a aquellos empleados que realmente necesiten utilizarlos. Esto también permite atribuir responsabilidades claras a cada usuario.
- Eficiencia y productividad: Todos los usuarios del software de gestión no necesitan el mismo acceso y permisos. De esta manera, se pueden crear diferentes perfiles, asignar roles a cada usuario y definir a qué información y módulos podrán acceder e, incluso, qué podrán hacer en cada uno de esos módulos. La eliminación de información irrelevante para ciertos usuarios optimiza su experiencia y productividad.
Un ERP, como Tryton, que permite personalizar los roles y permisos de los usuarios a la información de la empresa, es clave para asegurar un uso adecuado del programa.
¿Quieren Implementar un ERP? ✔️ ❰ANTES DEBEN CUMPLIR CON ESTO❱
Diferenciación de Roles
Al diseñar la matriz, es recomendable asignar los accesos basándose en los roles, en lugar de en las personas individuales. Esto facilita la gestión y escalabilidad. Para diferenciar roles de manera efectiva, se pueden seguir los siguientes principios:
1. Diferenciar roles por departamentos
Como hemos comentado, en una empresa existen diversos departamentos y no todos necesitan acceso a la información de los demás. Por ejemplo, el departamento de finanzas no requiere acceso a los detalles de producción, y viceversa.
2. Diferenciar roles entre cargos del departamento
Dentro de un mismo departamento, encontramos diferentes cargos de responsabilidad que, a menudo, también condicionan el acceso a la información. Un gerente tendrá acceso a más información y funciones que un empleado júnior.
Capas de Permisos en un ERP: Ejemplos Prácticos
La forma en que funcionan los permisos, tanto a nivel de compañía como de proyecto, es muy similar en muchos sistemas ERP. Generalmente, se establecen diferentes niveles o capas de permisos para asegurar una gestión detallada del acceso.
Permisos a Nivel General
Los niveles de permisos generales son los niveles básicos de permiso disponibles para cada herramienta en Procore. Con pocas excepciones, a los usuarios se les otorgará uno de estos niveles generales de permiso en todas las herramientas, tanto a nivel de compañía como a nivel de proyecto, en la cuenta de Procore de su compañía.
Los niveles generales de permiso suelen incluir:
- Ninguno: No hay permisos para la herramienta en absoluto.
- Solo lectura: Permite visualizar la información sin posibilidad de modificación.
- Estándar: Permite ver y modificar ciertos datos o realizar tareas básicas.
- Admin: Ofrece control total sobre la herramienta, incluyendo la gestión de otros usuarios.
Permisos Granulares
Hay otros permisos que se pueden utilizar para refinar las capacidades de un usuario, en combinación con un nivel general de permiso (como "Solo lectura" o "Estándar"). Estos se denominan "permiso granular". Se puede pensar en el permiso granular como una capa adicional en la parte superior de los niveles generales de permiso. Esta capa adicional de permiso no es aplicable a los usuarios con permisos de "Ninguno", porque cuando se les asignan permisos de "Ninguno" en una herramienta, los usuarios no tienen acceso a esa herramienta en absoluto.
Esta capa de permiso se utiliza principalmente para dar a un usuario la habilidad de realizar una tarea específica en una herramienta que el nivel general de permiso que tienen asignado no permite por sí solo. Por ejemplo, un usuario con permisos de nivel "Estándar" para la herramienta Directorio (ya sea de proyecto o de compañía) no puede agregar un usuario nuevo al directorio, a menos que se le otorgue un permiso granular específico para esa acción.
Capas Adicionales de Permisos y Roles
En algunas situaciones menos comunes, puede haber una tercera capa de permisos para asignar a un usuario para permitirle realizar una tarea. Por ejemplo, si una compañía licencia la herramienta Integraciones de ERP para administrar una integración con su sistema ERP, deberá asignar al menos a un usuario el rol de "Aprobador contable". Esta asignación de roles NO se administra en plantillas de permiso. Usando el ejemplo del rol de "Aprobador de contabilidad", se puede asignar este privilegio a un usuario directamente desde su registro de directorio a nivel de compañía. Esta opción de rol en particular se encuentra justo encima del espacio donde se pueden ver sus plantillas de permiso asignadas, pero no forma parte de una plantilla de permiso o se considera un permiso granular.
La siguiente tabla resume los tipos de permisos en Procore:
| Tipo de Permiso | Descripción | Ejemplo |
|---|---|---|
| Permisos a Nivel Compañía | Determinan el acceso a herramientas que no son específicas de un proyecto. | Herramienta Directorio a nivel compañía. |
| Permisos a Nivel Proyecto | Determinan el acceso a herramientas específicas de un proyecto. | Herramienta RFI en un proyecto específico. |
| Niveles Generales | Permisos básicos (Ninguno, Solo Lectura, Estándar, Admin) para cada herramienta. | Usuario con permiso "Estándar" para la herramienta Presupuesto. |
| Permisos Granulares | Refinan las capacidades de un usuario en una herramienta, encima de los niveles generales. | Usuario con permiso "Estándar" y permiso granular para "Agregar nuevo usuario" al Directorio. |
| Roles Específicos | Asignaciones directas para tareas muy específicas, fuera de plantillas o permisos granulares. | Rol de "Aprobador contable" para la herramienta de Integraciones de ERP. |
Implementación de una Matriz de Permisos en el ERP
Uno de los desafíos que tienen las startups al cumplir con una regulación o una normativa como ISO 27001 es crear los documentos de seguridad desde cero. Para diseñar una matriz de permisos efectiva, se pueden seguir los siguientes pasos prácticos:
- Listar los roles de la empresa: En una tabla de Excel, se hace una lista de los roles que existen en la empresa. Para ello, se puede utilizar el organigrama o las descripciones de trabajo de cada puesto.
- Identificar aplicaciones y bases de datos: En las columnas de la matriz, se agregan las aplicaciones y bases de datos que usa la startup.
- Definir un modelo de permisos y accesos: Es importante y lo más recomendable al crear la matriz es usar un modelo de accesos basado en roles. Esto implica establecer qué nivel de acceso (ver, editar, administrar) cada rol tendrá para cada aplicación o base de datos.
- Revisar la situación actual: Revisar cómo está la situación en la realidad. Se puede buscar cómo exportar estas listas en la documentación de cada aplicación.
- Corregir y agregar accesos: Tomar todo lo resaltado en la revisión y comenzar a corregir o agregar los accesos y permisos según el modelo definido.
Gestión de Autorizaciones en SAP Human Capital Management (HCM)
SAP Human Capital Management es muy adecuado para tratar las autorizaciones, porque el departamento de Recursos Humanos (RRHH) tiene una percepción muy distinta de las autorizaciones. Cuando hablamos de autorizaciones, como en el resto de sistemas SAP, la clave es la Segregación de Funciones (SoD). SAP GRC ofrece una matriz de riesgo estándar con 21 riesgos de segregación de funciones (SoD) específicos para el módulo HCM.
En esta sección, se lleva a cabo el procedimiento siguiendo la misma metodología de autorización que se utiliza para los sistemas ECC en SAP. Esta opción se basa en los Objetos de Autorización que definen los campos de autorización que se comprueban durante la ejecución de la transacción. Se puede utilizar la transacción de mantenimiento de roles (PFCG) para crear perfiles de autorización y asignarlos a los usuarios. Si se desean comprobar campos adicionales del infotipo, por ejemplo, el centro de coste o la subdivisión de personal, se puede utilizar el objeto de autorización P_NNNN.
En lo que respecta a las tablas, es importante destacar el objeto de autorización S_TABU_LIN (autorización para la unidad organizativa). Este objeto complementa los objetos de autorización S_TABU_NAM, S_TABU_DIS y S_TABU_CLI. S_TABU_NAM funciona a nivel de restringir el acceso a la visualización o modificación de una tabla específica del sistema. Pero el S_TABU_LIN controla el acceso a filas individuales de la tabla.
Además, es importante indicar que cuando se decide restringir el modelo de rol de autorización de Human Capital Management a través de “autorizaciones generales”, es recomendable combinar un modelo de rol derivado del maestro con roles habilitadores. Estos roles solo tienen objetos de autorización, no transacciones.
La separación técnica de los perfiles de autorizaciones generales y estructurales puede causar problemas de contexto para los usuarios que desempeñan diferentes funciones en una empresa. Los perfiles estructurales se asignan de forma diferente a los perfiles de autorización generales (transacción PFCG). Para asignar los perfiles estructurales, se utiliza una transacción específica llamada Perfiles de Autorización (OOSP).
