NexTool Solutions

In GLPI un permesso non è un interruttore acceso/spento: è il prodotto di tre assi che si moltiplicano - profilo, entità e interfaccia. Sbagliare questa combinazione è la causa numero uno dei ticket di "accesso sparito" e della fuga di visibilità tra le aree. Questa guida mostra il modello reale, dove i diritti vivono davvero nel database e le trappole che emergono solo in un ambiente multi-entità.

Il modello RBAC su tre assi

Il controllo degli accessi di GLPI (RBAC, Role-Based Access Control) combina tre dimensioni indipendenti che molti trattano come una sola:

• Profilo - l'insieme dei diritti, cioè cosa la persona può fare (aprire, modificare, eliminare, configurare).
• Entità - l'ambito dei dati, cioè dove vede: quale organizzazione, filiale o reparto.
• Interfaccia - come naviga: Helpdesk (semplificata, per l'utente finale) o Centrale (completa, per l'operatività).

Ciò che confonde è che i tre si combinano per assegnazione, non per ereditarietà automatica. La tabella glpi_profiles_users collega un utente a un profilo dentro un'entità, con un flag is_recursive che decide se l'accesso scende alle sotto-entità. Per questo lo stesso utente può essere Tecnico nell'entità "IT" e Self-Service nell'entità "HR": due righe distinte in quella tabella, ciascuna con il proprio ambito.

La matrice di profili che usiamo come baseline

Invece di personalizzare a caso i sette profili di fabbrica di GLPI, partiamo da una matrice snella e cloniamo da essa. Meno profili con confini chiari generano meno incidenti di dieci profili quasi identici di cui nessuno ricorda la differenza.

Regola pratica sul campo: se due profili differiscono per un solo permesso, probabilmente dovrebbero essere uno solo. La proliferazione di profili è debito tecnico di sicurezza: ogni profilo in più è una cosa in più da controllare.

Dove vivono davvero i diritti

La schermata dei Profili (Amministrazione > Profili) è solo un guscio sopra la tabella glpi_profilerights. Ogni riga custodisce la coppia (profilo, oggetto) e una colonna rights che è un bitmask intero. Capirlo cambia le regole del gioco in fase di audit: invece di cliccare in decine di schede, legge il diritto direttamente dal database.

-- Diritti di un profilo su oggetti chiave (il bitmask e un intero)
SELECT p.name    AS profilo,
       pr.name   AS oggetto,
       pr.rights AS bitmask
FROM   glpi_profilerights pr
JOIN   glpi_profiles p ON p.id = pr.profiles_id
WHERE  p.name = 'Tecnico'   -- adatta al nome nella lingua di installazione
  AND  pr.name IN ('ticket', 'computer', 'config', 'user', 'entity')
ORDER  BY pr.name;

-- Decodifica dei bit base (validi per la maggior parte degli itemtype):
--   READ = 1, UPDATE = 2, CREATE = 4, DELETE = 8, PURGE = 32
-- Es.: bitmask 15 = READ+UPDATE+CREATE+DELETE (CRUD, senza purge)

I bit base valgono per la maggior parte degli itemtype, ma oggetti come il ticket (ticket) impacchettano flag aggiuntivi nello stesso intero: visibilità "miei / mio gruppo / tutti", assegnare, rubare, cambiare priorità. Non provi a indovinare quei bit a memoria - li confermi nell'interfaccia e validi con una sessione di prova prima di darlo per certo.

Diagnosi rapida: chi ha cosa

Prima di toccare qualsiasi profilo, fotografi lo stato attuale. Questa query risponde a "chi ha quale profilo, in quale entità, e se scende ai figli" - proprio l'immagine che più manca in un audit degli accessi:

-- Chi ha quale profilo, in quale entita, con o senza ricorsione
SELECT u.name          AS utente,
       p.name          AS profilo,
       p.interface     AS interfaccia,
       e.completename  AS entita,
       pu.is_recursive AS scende_a_sottoentita
FROM   glpi_profiles_users pu
JOIN   glpi_users    u ON u.id = pu.users_id
JOIN   glpi_profiles p ON p.id = pu.profiles_id
JOIN   glpi_entities e ON e.id = pu.entities_id
WHERE  u.name = 'mario.rossi'
ORDER  BY e.completename;

Eseguirla periodicamente - almeno mensilmente - è il modo economico per intercettare l'accumulo di privilegi: ex membri di un gruppo che restano Supervisori, o un profilo amministrativo assegnato "solo per provare" che nessuno ha rimosso. In una manutenzione seria questa SELECT diventa un report pianificato, non una caccia manuale quando il problema è già esploso.

Trappole sul campo

Nella manutenzione di ambienti multi-entità dei clienti, il ticket ricorrente "il mio permesso è sparito" quasi mai è un bug: è la cache di sessione. GLPI carica i diritti del profilo in $_SESSION al momento del login. Se regola il bitmask mentre il tecnico è connesso, lui mantiene i diritti vecchi finché non cambia entità nel selettore o rifà il login. Abbiamo imparato a inserire "chiedi all'utente di uscire e rientrare" nello stesso copione di validazione e a testare sempre in una sessione nuova o anonima - altrimenti giura di aver configurato bene e l'utente giura che non funziona, entrambi con ragione allo stesso tempo.

Le altre che generano più incidenti:

• Visibilità "Tutti" per il tecnico - dare "vedere tutti i ticket" fa sì che il tecnico veda i ticket di tutte le entità a cui ha accesso, non solo della sua. In un cliente con aree sensibili (HR, Legale) questo è una fuga silenziosa. Preferisca "del proprio gruppo".
• Dimenticare is_recursive - assegnare il profilo sull'entità radice senza spuntare la ricorsione fa sì che l'utente non veda alcuna sotto-entità. Il sintomo classico è "accedo ma non vedo niente". L'opposto, ricorsione indebita, concede un accesso troppo ampio senza che nessuno se ne accorga.
• Diritto della Centrale su un profilo Helpdesk - l'interfaccia Helpdesk ignora la maggior parte dei diritti della Centrale. Spuntare permessi sugli asset in un profilo helpdesk non fa nulla; il menu semplicemente non esiste in quell'interfaccia.
• Regole di assegnazione fuori ordine - chi usa LDAP o SSO assegna il profilo tramite le Regole di assegnazione delle autorizzazioni (RuleRight). La regola generica "assegna Self-Service" deve venire per ultima; se sta in cima senza "interrompere l'elaborazione", batte tutte le regole specifiche e tutti finiscono come Self-Service.
• Non testare nei panni del Self-Service - molti difetti compaiono solo nell'interfaccia Helpdesk. Tenga un utente di prova per profilo e percorra il tragitto reale prima di rilasciare in produzione.

Checklist di hardening dei profili

1. Parta dalla matrice minima; cloni i profili invece di modificare quelli di fabbrica.
2. Imposti la visibilità dei ticket su "del proprio gruppo" per default; "Tutti" solo con giustificazione scritta.
3. Riveda il flag is_recursive in ogni assegnazione di entità.
4. Esegua il SQL di diagnosi ogni mese e rimuova il privilegio accumulato.
5. Tenga un utente di prova per profilo e validi in una sessione nuova dopo ogni modifica.
6. Limiti chi modifica Profili e Regole: il diritto UPDATE su profile e rule è, in pratica, un diritto di amministratore.

Le serve il controllo degli accessi a schermate e sistemi esterni dall'interno di GLPI stesso, con una matrice verificabile? Scopra il modulo Access Matrix. E se preferisce esternalizzare il disegno e la manutenzione dei profili, NexTool implementa e mantiene ambienti GLPI multi-entità con una governance degli accessi rivista periodicamente.

Revisionato dal team NexTool Solutions.