NexTool Solutions

Lors d'un audit, personne ne demande "qui a acces a l'ERP". On demande "qui peut SUPPRIMER une ecriture dans l'ERP" - et le tableur des acces sait rarement repondre. Access Matrix amene cette matrice de decision a l'interieur de GLPI : systemes externes, leurs modules et quatre indicateurs CRUD (Creer, Lire, Modifier, Supprimer) resolus par role, groupe et utilisateur. Ce guide couvre le modele de resolution, un diagnostic SQL directement en base, le format de migration entre environnements et les pieges qui n'apparaissent qu'en production.

Le vrai probleme : le tableur auquel personne ne se fie

En maintenance d'environnements clients, la demande qui revele la fragilite du controle par tableur revient sans cesse. Un audit arrive (ISO 27001, SOX ou un rapport d'acces pour la conformite au RGPD) et la demande est granulaire : "listez tous les roles qui peuvent creer et supprimer des enregistrements dans le systeme financier". Un tableur "a acces / n'a pas acces" ne peut pas y repondre. Il ne separe pas la lecture de l'ecriture, n'a pas d'historique de qui a change quoi, et il est deja perime parce que le dernier depart n'a jamais ete repercute. Access Matrix vise exactement ce vide : il modelise l'acces avec une granularite CRUD et garde tout dans GLPI, a cote du reste de l'exploitation du centre de services.

Ce que le module modelise : systemes, modules et quatre indicateurs

La structure est volontairement simple. Vous enregistrez les systemes externes (ERP, CRM, BI, portails tiers) et, dans chacun, les modules pertinents (par exemple "Comptes fournisseurs", "Facturation", "Rapports"). Pour chaque combinaison de role et de module, vous cochez quatre cases : Creer, Lire, Modifier, Supprimer. Une permission peut etre definie au niveau du systeme entier ou par module specifique. En base, cela devient les colonnes can_create, can_read, can_update, can_delete (tinyint 0/1), le module etant a NULL quand la regle s'applique au systeme entier.

Une precision honnete et importante : Access Matrix n'est pas un proxy qui bloque la connexion a l'ERP. Il n'intercepte pas le systeme externe. C'est la matrice de decision faisant autorite - la source de verite qui documente, resout et affiche qui doit detenir chaque permission, pour que l'equipe qui provisionne l'acces (ou l'auditeur qui le revoit) travaille sur une donnee fiable dans GLPI plutot que sur un tableur epars.

Resolution en 4 couches (OR : la plus permissive l'emporte)

La permission effective d'un utilisateur ne vient pas d'un seul endroit. Le module combine quatre sources avec une logique OR - pour chaque indicateur CRUD, si une couche l'accorde, l'utilisateur l'a. En pratique, le resultat de chaque indicateur est un max() entre les couches :

1. Le role de l'utilisateur - le champ qui definit le role est configurable (Categorie, Titre ou Groupe par defaut de GLPI) via le parametre role_source.
2. Groupes de permissions lies au role - ensembles CRUD reutilisables affectes au role.
3. Groupes de permissions lies directement a l'utilisateur - exceptions ponctuelles sans toucher au role.
4. Permissions individuelles affectees directement au compte.

Dans l'onglet de consultation, le module affiche la permission effective de tout utilisateur avec des badges indiquant de quelle couche chaque acces provient (Role, Groupe ou Individuel) - ce qui rend la resolution auditable plutot qu'une boite noire.

Diagnostic directement en base (SQL)

Lors d'un audit, la question la plus frequente est "qui peut ecrire (creer, modifier ou supprimer) dans chaque systeme". On y repond avec un SELECT directement sur la table de permissions par role. L'exemple suppose la source par defaut (usercategories_id, la Categorie de l'utilisateur) et ne liste que ceux ayant un indicateur d'ecriture :

-- Roles (Categorie utilisateur) avec pouvoir d'ECRITURE sur chaque systeme externe
-- Source de role par defaut = usercategories_id
SELECT s.name                                AS systeme,
       COALESCE(m.name, '(systeme entier)')  AS module,
       c.name                                AS role,
       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, role;

Ce SELECT est en lecture seule et couvre la couche role (la base). La permission effective finale - en ajoutant les groupes de permissions et les ajustements individuels via le OR des 4 couches - est resolue par le module en PHP ; utilisez l'onglet de consultation pour la valeur consolidee par utilisateur. Le SQL sert aux balayages rapides d'audit et a verifier la base avant d'aller plus loin.

Migration entre environnements : Import/Export CSV

Configurer la matrice en preproduction et la promouvoir en production sans tout refaire a la main se fait par Import/Export CSV. L'export produit un fichier unique avec systemes, modules et permissions, dans ce format :

type,system_name,module_name,comment,is_active,role_source,role_id,can_create,can_read,can_update,can_delete
system,ERP Protheus,,Gestion financiere,1,,0,0,0,0,0
module,ERP Protheus,Comptes fournisseurs,,1,,0,0,0,0,0
permission,ERP Protheus,Comptes fournisseurs,,0,usercategories_id,5,1,1,1,0
permission,ERP Protheus,,,0,groups_id,12,0,1,0,0

La colonne type distingue les lignes de systeme, de module et de permission ; sur les lignes de permission, role_source indique de quelle couche provient la regle. Avant d'appliquer, le module affiche un apercu des changements et ecrit une sauvegarde automatique (instantane JSON) de l'etat precedent, pour revenir en arriere si le resultat differe de l'attendu.

Integration avec le ticket

Un onglet dedie apparait sur chaque formulaire de ticket, presedelectionnant deja le demandeur et affichant ses permissions effectives. En pratique, quand arrive un ticket du type "donnez a untel l'acces au module X de l'ERP", le technicien voit aussitot ce que cet utilisateur possede deja dans chaque systeme - sans quitter le ticket, sans ouvrir un autre ecran, sans dependre du fameux tableur.

Pieges de terrain (l'erreur courante est...)

Trois details n'apparaissent qu'une fois la matrice en usage, et ils viennent d'une exploitation directe :

• Le OR ne revoque jamais. L'erreur courante est d'essayer de "retirer" un acces en decochant les indicateurs sur la couche individuelle de l'utilisateur alors qu'un groupe de permissions accorde toujours ce CRUD. Comme la resolution est un OR (la plus permissive l'emporte), la permission reste valable. Il n'y a pas de "refuser" qui l'emporte sur un "accorder" d'une autre couche : pour la retirer vraiment, sortez-la de la couche qui l'accorde.
• Un utilisateur sans role renseigne n'herite pas de la matrice de role. Si vous avez configure la source sur Categorie mais que le compte de l'utilisateur a la Categorie vide, la couche 1 ne s'applique tout simplement pas - seuls comptent les groupes de l'utilisateur et les permissions individuelles. Le module le signale dans la consultation, mais le symptome au quotidien est "j'ai configure le role et l'utilisateur n'a toujours pas d'acces". Verifiez le champ de role sur la fiche avant de soupconner le module.
• Changer la source de role n'efface pas ce que vous avez configure. Si vous migrez role_source de Categorie a Titre, les permissions enregistrees par Categorie ne disparaissent pas - elles restent dormantes en base et cessent d'etre affichees tant que le mode n'est pas le leur. Revenir a l'ancienne source ramene tout. Il est sans risque d'experimenter, mais sachez que "tout a disparu" apres un changement de source est presque toujours cela, pas une perte de donnees.

Modeliser la matrice une fois est la partie facile ; la garder coherente avec les departs, les changements de fonction et les audits recurrents est un travail de maintenance. C'est ce que fait NexTool : decouvrez Access Matrix ou parlez a la maintenance GLPI de NexTool pour structurer le controle d'acces aux systemes externes avec gouvernance et piste d'audit.

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