NexTool Solutions

In un audit, nessuno chiede "chi ha accesso all'ERP". Chiedono "chi puo CANCELLARE una registrazione nell'ERP" - e il foglio di calcolo degli accessi raramente sa rispondere. Access Matrix porta questa matrice decisionale dentro GLPI: sistemi esterni, i loro moduli e quattro flag CRUD (Creare, Leggere, Aggiornare, Cancellare) risolti per ruolo, gruppo e utente. Questa guida copre il modello di risoluzione, una diagnostica SQL diretta sul database, il formato di migrazione tra ambienti e le trappole che emergono solo in produzione.

Il problema reale: il foglio di calcolo di cui nessuno si fida

Nella manutenzione di ambienti dei clienti, la richiesta che espone la fragilita del controllo tramite foglio di calcolo si ripresenta di continuo. Arriva un audit (ISO 27001, SOX o un report di accesso per la conformita privacy) e la richiesta e granulare: "elenca tutti i ruoli che possono creare e cancellare record nel sistema finanziario". Un foglio "ha accesso / non ha accesso" non puo rispondere. Non separa lettura da scrittura, non ha storico di chi ha cambiato cosa, ed e gia obsoleto perche l'ultima uscita non e mai stata riflessa. Access Matrix affronta proprio questo vuoto: modella l'accesso con granularita CRUD e mantiene tutto dentro GLPI, accanto al resto dell'operativita del service desk.

Cosa modella il modulo: sistemi, moduli e quattro flag

La struttura e volutamente semplice. Registri i sistemi esterni (ERP, CRM, BI, portali di terzi) e, dentro ciascuno, i moduli rilevanti (per esempio "Contabilita Fornitori", "Fatturazione", "Report"). Per ogni combinazione di ruolo e modulo spunti quattro caselle: Creare, Leggere, Aggiornare, Cancellare. Un permesso puo essere definito a livello dell'intero sistema o per modulo specifico. Nel database questo diventa le colonne can_create, can_read, can_update, can_delete (tinyint 0/1), con il modulo a NULL quando la regola vale per l'intero sistema.

Un chiarimento onesto e importante: Access Matrix non e un proxy che blocca il login all'ERP. Non intercetta il sistema esterno. E la matrice decisionale autorevole - la fonte di verita che documenta, risolve e mostra chi dovrebbe avere ciascun permesso, affinche il team che effettua il provisioning dell'accesso (o l'auditor che lo verifica) lavori su un dato affidabile dentro GLPI e non su un foglio sparso.

Risoluzione a 4 livelli (OR: vince il piu permissivo)

Il permesso effettivo di un utente non arriva da un solo posto. Il modulo combina quattro fonti con logica OR - per ogni flag CRUD, se un qualsiasi livello lo concede, l'utente lo ha. In pratica, il risultato di ogni flag e un max() tra i livelli:

1. Il ruolo dell'utente - il campo che definisce il ruolo e configurabile (Categoria, Titolo o Gruppo predefinito di GLPI) tramite il parametro role_source.
2. Gruppi di permessi collegati al ruolo - insiemi CRUD riutilizzabili assegnati al ruolo.
3. Gruppi di permessi collegati direttamente all'utente - eccezioni puntuali senza toccare il ruolo.
4. Permessi individuali assegnati direttamente all'account.

Nella scheda di consultazione, il modulo mostra il permesso effettivo di qualsiasi utente con badge che indicano da quale livello proviene ciascun accesso (Ruolo, Gruppo o Individuale) - il che rende la risoluzione verificabile invece che una scatola nera.

Diagnostica diretta sul database (SQL)

In un audit, la domanda piu frequente e "chi puo scrivere (creare, aggiornare o cancellare) in ciascun sistema". Si risponde con un SELECT diretto sulla tabella dei permessi per ruolo. L'esempio assume la fonte predefinita (usercategories_id, la Categoria dell'utente) ed elenca solo chi ha un flag di scrittura:

-- Ruoli (Categoria utente) con potere di SCRITTURA su ciascun sistema esterno
-- Fonte del ruolo predefinita = usercategories_id
SELECT s.name                                AS sistema,
       COALESCE(m.name, '(sistema intero)')  AS modulo,
       c.name                                AS ruolo,
       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, ruolo;

Questo SELECT e di sola lettura e copre il livello del ruolo (la base). Il permesso effettivo finale - sommando gruppi di permessi e regolazioni individuali con l'OR dei 4 livelli - viene risolto dal modulo in PHP; usa la scheda di consultazione per il valore consolidato per utente. L'SQL serve per scansioni rapide di audit e per verificare la base prima di approfondire.

Migrazione tra ambienti: Import/Export CSV

Configurare la matrice in staging e promuoverla in produzione senza rifare tutto a mano si fa con Import/Export CSV. L'export genera un unico file con sistemi, moduli e permessi, in questo formato:

type,system_name,module_name,comment,is_active,role_source,role_id,can_create,can_read,can_update,can_delete
system,ERP Protheus,,Gestione finanziaria,1,,0,0,0,0,0
module,ERP Protheus,Contabilita Fornitori,,1,,0,0,0,0,0
permission,ERP Protheus,Contabilita Fornitori,,0,usercategories_id,5,1,1,1,0
permission,ERP Protheus,,,0,groups_id,12,0,1,0,0

La colonna type distingue le righe di sistema, modulo e permesso; nelle righe di permesso, role_source indica da quale livello proviene quella regola. Prima di applicare, il modulo mostra un'anteprima delle modifiche e scrive un backup automatico (snapshot JSON) dello stato precedente, per tornare indietro se qualcosa risulta diverso dal previsto.

Integrazione con il ticket

Una scheda dedicata appare sul modulo di ogni ticket, preselezionando gia il richiedente e mostrando i suoi permessi effettivi. In pratica, quando arriva un ticket del tipo "abilita il tale al modulo X dell'ERP", il tecnico vede subito cosa quell'utente ha gia in ciascun sistema - senza uscire dal ticket, senza aprire un'altra schermata, senza dipendere dal famoso foglio di calcolo.

Trappole sul campo (l'errore comune e...)

Tre dettagli emergono solo quando la matrice e in uso, e valgono per esperienza diretta di operativita:

• L'OR non revoca mai. L'errore comune e provare a "togliere" un accesso deselezionando i flag sul livello individuale dell'utente mentre un gruppo di permessi continua a concedere quel CRUD. Poiche la risoluzione e OR (vince il piu permissivo), il permesso resta valido. Non esiste un "nega" che sovrasti un "concedi" di un altro livello: per rimuoverlo davvero, toglilo dal livello che lo concede.
• Un utente senza ruolo compilato non eredita la matrice del ruolo. Se hai configurato la fonte come Categoria ma l'account dell'utente ha la Categoria vuota, il livello 1 semplicemente non si applica - contano solo i gruppi dell'utente e i permessi individuali. Il modulo lo segnala nella consultazione, ma il sintomo quotidiano e "ho configurato il ruolo e l'utente e ancora senza accesso". Controlla il campo del ruolo nella scheda prima di sospettare del modulo.
• Cambiare la fonte del ruolo non cancella cio che hai configurato. Se migri role_source da Categoria a Titolo, i permessi salvati per Categoria non spariscono - restano dormienti nel database e smettono di essere mostrati finche la modalita non e la loro. Tornare alla vecchia fonte riporta tutto. E sicuro sperimentare, ma sappi che "e sparito tutto" dopo un cambio di fonte e quasi sempre questo, non una perdita di dati.

Modellare la matrice una volta e la parte facile; mantenerla coerente con le uscite, i cambi di funzione e gli audit ricorrenti e lavoro di manutenzione. E cio che fa NexTool: scopri Access Matrix o parla con la manutenzione GLPI di NexTool per strutturare il controllo degli accessi ai sistemi esterni con governance e traccia di audit.

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