NexTool Solutions

En una auditoria, nadie pregunta "quien tiene acceso al ERP". Preguntan "quien puede BORRAR un asiento en el ERP" - y la hoja de calculo de accesos rara vez sabe responder. Access Matrix lleva esa matriz de decision dentro de GLPI: sistemas externos, sus modulos y cuatro flags CRUD (Crear, Leer, Actualizar, Borrar) resueltos por cargo, grupo y usuario. Esta guia cubre el modelo de resolucion, un diagnostico SQL directo en la base de datos, el formato de migracion entre entornos y las trampas que solo aparecen en produccion.

El problema real: la hoja de calculo en la que nadie confia

En el mantenimiento de entornos de clientes, la peticion que expone lo fragil que es el control por hoja de calculo se repite una y otra vez. Llega una auditoria (ISO 27001, SOX o un informe de acceso para la proteccion de datos) y la peticion es granular: "lista todos los cargos que pueden crear y borrar registros en el sistema financiero". Una hoja de "tiene acceso / no tiene acceso" no puede responder eso. No separa lectura de escritura, no tiene historial de quien cambio que, y ya esta desactualizada porque la ultima baja nunca se reflejo. Access Matrix ataca justamente ese vacio: modela el acceso con granularidad CRUD y mantiene todo dentro de GLPI, junto al resto de la operacion del service desk.

Que modela el modulo: sistemas, modulos y cuatro flags

La estructura es deliberadamente simple. Registras los sistemas externos (ERP, CRM, BI, portales de terceros) y, dentro de cada uno, los modulos relevantes (por ejemplo "Cuentas por Pagar", "Facturacion", "Informes"). Para cada combinacion de cargo y modulo marcas cuatro casillas: Crear, Leer, Actualizar, Borrar. Un permiso puede definirse a nivel del sistema completo o por modulo especifico. En la base de datos esto se convierte en las columnas can_create, can_read, can_update, can_delete (tinyint 0/1), con el modulo en NULL cuando la regla aplica al sistema entero.

Una aclaracion honesta e importante: Access Matrix no es un proxy que bloquea el login del ERP. No intercepta el sistema externo. Es la matriz de decision autoritativa - la fuente de verdad que documenta, resuelve y muestra quien debe tener cada permiso, para que el equipo que provisiona el acceso (o el auditor que lo revisa) trabaje sobre un dato confiable dentro de GLPI y no sobre una hoja suelta.

Resolucion en 4 capas (OR: gana la mas permisiva)

El permiso efectivo de un usuario no viene de un solo lugar. El modulo combina cuatro fuentes con logica OR - para cada flag CRUD, si cualquier capa lo concede, el usuario lo tiene. En la practica, el resultado de cada flag es un max() entre las capas:

1. El cargo del usuario - el campo que define el cargo es configurable (Categoria, Titulo o Grupo por defecto de GLPI) mediante el parametro role_source.
2. Grupos de permisos vinculados al cargo - conjuntos reutilizables de CRUD asignados al cargo.
3. Grupos de permisos vinculados directamente al usuario - excepciones puntuales sin tocar el cargo.
4. Permisos individuales asignados directamente a la cuenta.

En la pestana de consulta, el modulo muestra el permiso efectivo de cualquier usuario con badges que indican de que capa vino cada acceso (Cargo, Grupo o Individual) - lo que hace la resolucion auditable en lugar de una caja negra.

Diagnostico directo en la base de datos (SQL)

En una auditoria, la pregunta mas frecuente es "quien puede escribir (crear, actualizar o borrar) en cada sistema". Se puede responder con un SELECT directo sobre la tabla de permisos por cargo. El ejemplo asume la fuente por defecto (usercategories_id, la Categoria del usuario) y lista solo a quienes tienen alguna flag de escritura:

-- Cargos (Categoria del usuario) con poder de ESCRITURA en cada sistema externo
-- Fuente de cargo por defecto = usercategories_id
SELECT s.name                                AS sistema,
       COALESCE(m.name, '(sistema entero)')  AS modulo,
       c.name                                AS cargo,
       p.can_create, p.can_update, p.can_delete
FROM        glpi_plugin_nextool_accessmatrix_perm_categories p
JOIN        glpi_plugin_nextool_accessmatrix_systems s
              ON s.id = p.plugin_nextool_accessmatrix_systems_id
LEFT JOIN   glpi_plugin_nextool_accessmatrix_modules  m
              ON m.id = p.plugin_nextool_accessmatrix_modules_id
JOIN        glpi_usercategories c
              ON c.id = p.usercategories_id
WHERE       p.can_create = 1 OR p.can_update = 1 OR p.can_delete = 1
ORDER  BY   s.name, cargo;

Ese SELECT es de solo lectura y cubre la capa de cargo (la base). El permiso efectivo final - sumando grupos de permisos y ajustes individuales con el OR de las 4 capas - lo resuelve el modulo en PHP; usa la pestana de consulta para el valor consolidado por usuario. El SQL sirve para barridos rapidos de auditoria y para verificar la base antes de profundizar.

Migracion entre entornos: Import/Export CSV

Configurar la matriz en preproduccion y promoverla a produccion sin rehacer todo a mano se hace con Import/Export CSV. El export genera un archivo unico con sistemas, modulos y permisos, en este formato:

type,system_name,module_name,comment,is_active,role_source,role_id,can_create,can_read,can_update,can_delete
system,ERP Protheus,,Gestion financiera,1,,0,0,0,0,0
module,ERP Protheus,Cuentas por Pagar,,1,,0,0,0,0,0
permission,ERP Protheus,Cuentas por Pagar,,0,usercategories_id,5,1,1,1,0
permission,ERP Protheus,,,0,groups_id,12,0,1,0,0

La columna type distingue filas de sistema, modulo y permiso; en las filas de permiso, role_source dice de que capa viene esa regla. Antes de aplicar, el modulo muestra una vista previa de los cambios y graba un backup automatico (snapshot JSON) del estado anterior, para revertir si algo sale distinto a lo esperado.

Integracion con el ticket

Una pestana dedicada aparece en el formulario de cada ticket, ya preseleccionando al solicitante y mostrando sus permisos efectivos. En la practica, cuando entra un ticket del tipo "da acceso a fulano en el modulo X del ERP", el tecnico ve al instante lo que ese usuario ya tiene en cada sistema - sin salir del ticket, sin abrir otra pantalla, sin depender de la dichosa hoja de calculo.

Trampas de campo (el error comun es...)

Tres detalles solo aparecen una vez que la matriz esta en uso, y valen por experiencia directa de operacion:

• El OR nunca revoca. El error comun es intentar "quitar" un acceso desmarcando las flags en la capa individual del usuario mientras un grupo de permisos sigue concediendo ese CRUD. Como la resolucion es OR (gana la mas permisiva), el permiso sigue vigente. No existe un "denegar" que sobreponga un "conceder" de otra capa: para quitarlo de verdad, retiralo de la capa que lo concede.
• Un usuario sin cargo definido no hereda la matriz de cargo. Si configuraste la fuente como Categoria pero la cuenta del usuario tiene la Categoria en blanco, la capa 1 simplemente no aplica - solo cuentan los grupos del usuario y los permisos individuales. El modulo avisa de esto en la consulta, pero el sintoma del dia a dia es "configure el cargo y el usuario sigue sin acceso". Revisa el campo de cargo en el registro antes de sospechar del modulo.
• Cambiar la fuente de cargo no borra lo que configuraste. Si migras role_source de Categoria a Titulo, los permisos guardados por Categoria no desaparecen - quedan dormidos en la base y dejan de mostrarse mientras el modo no sea el suyo. Volver a la fuente antigua lo trae todo de vuelta. Es seguro experimentar, pero ten en cuenta que "desaparecio todo" al cambiar la fuente casi siempre es esto, no perdida de datos.

Modelar la matriz una vez es la parte facil; mantenerla coherente con las bajas, los cambios de funcion y las auditorias recurrentes es trabajo de mantenimiento. Es lo que hace NexTool: conoce Access Matrix o habla con el mantenimiento de GLPI de NexTool para estructurar el control de accesos a sistemas externos con gobernanza y traza de auditoria.

Este conteudo foi produzido com auxilio de inteligencia artificial e revisado pela equipe Nextool Solutions.