NexTool Solutions

Dans GLPI, une permission n'est pas un interrupteur marche/arrêt : c'est le produit de trois axes qui se multiplient - profil, entité et interface. Se tromper dans cette combinaison est la cause numéro un des tickets d'"accès disparu" et de la fuite de visibilité entre les services. Ce guide montre le modèle réel, où les droits vivent vraiment dans la base de données et les pièges qui n'apparaissent qu'en environnement multi-entité.

Le modèle RBAC sur trois axes

Le contrôle d'accès de GLPI (RBAC, Role-Based Access Control) combine trois dimensions indépendantes que beaucoup traitent comme une seule :

• Profil - l'ensemble des droits, c'est-à-dire ce que la personne peut faire (ouvrir, modifier, supprimer, configurer).
• Entité - la portée des données, c'est-à-dire où elle voit : quelle organisation, filiale ou service.
• Interface - comment elle navigue : Helpdesk (simplifiée, pour l'utilisateur final) ou Centrale (complète, pour l'exploitation).

Ce qui prête à confusion, c'est que les trois se combinent par attribution, et non par héritage automatique. La table glpi_profiles_users lie un utilisateur à un profil au sein d'une entité, avec un indicateur is_recursive qui décide si l'accès descend vers les sous-entités. C'est pourquoi le même utilisateur peut être Technicien dans l'entité "DSI" et Self-Service dans l'entité "RH" : deux lignes distinctes dans cette table, chacune avec sa portée.

La matrice de profils que nous utilisons comme référence

Plutôt que de personnaliser au hasard les sept profils d'usine de GLPI, nous partons d'une matrice épurée et clonons à partir d'elle. Moins de profils aux frontières claires génèrent moins d'incidents que dix profils quasi identiques dont personne ne se rappelle la différence.

Règle empirique de terrain : si deux profils diffèrent par une seule permission, ils devraient probablement n'en faire qu'un. La prolifération de profils est une dette technique de sécurité : chaque profil supplémentaire est une chose de plus à auditer.

Où vivent réellement les droits

L'écran des Profils (Administration > Profils) n'est qu'une coquille au-dessus de la table glpi_profilerights. Chaque ligne stocke le couple (profil, objet) et une colonne rights qui est un masque de bits entier. Comprendre cela change la donne en audit : au lieu de cliquer dans des dizaines d'onglets, vous lisez le droit directement dans la base.

-- Droits d'un profil sur des objets cles (le masque de bits est un entier)
SELECT p.name    AS profil,
       pr.name   AS objet,
       pr.rights AS masque_bits
FROM   glpi_profilerights pr
JOIN   glpi_profiles p ON p.id = pr.profiles_id
WHERE  p.name = 'Technicien'   -- adaptez au nom dans la langue d'installation
  AND  pr.name IN ('ticket', 'computer', 'config', 'user', 'entity')
ORDER  BY pr.name;

-- Decodage des bits de base (valables pour la plupart des itemtypes) :
--   READ = 1, UPDATE = 2, CREATE = 4, DELETE = 8, PURGE = 32
-- Ex. : masque 15 = READ+UPDATE+CREATE+DELETE (CRUD, sans purge)

Les bits de base valent pour la plupart des itemtypes, mais des objets comme le ticket (ticket) empaquettent des indicateurs supplémentaires dans le même entier : visibilité "les miens / mon groupe / tous", attribuer, voler, changer la priorité. N'essayez pas de deviner ces bits de mémoire - confirmez-les dans l'interface et validez avec une session de test avant de conclure.

Diagnostic rapide : qui a quoi

Avant de toucher à un profil, photographiez l'état actuel. Cette requête répond à "qui a quel profil, dans quelle entité, et si cela descend vers les enfants" - précisément l'image qui manque le plus dans un audit d'accès :

-- Qui a quel profil, dans quelle entite, avec ou sans recursion
SELECT u.name          AS utilisateur,
       p.name          AS profil,
       p.interface     AS interface,
       e.completename  AS entite,
       pu.is_recursive AS descend_vers_sous_entites
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 = 'jean.dupont'
ORDER  BY e.completename;

Exécuter cela périodiquement - mensuellement au minimum - est le moyen bon marché d'attraper l'accumulation de privilèges : d'anciens membres d'un groupe toujours Superviseurs, ou un profil administratif attribué "juste pour tester" que personne n'a retiré. En maintenance sérieuse, ce SELECT devient un rapport planifié, pas une chasse manuelle une fois que le problème a déjà éclaté.

Pièges de terrain

En maintenance d'environnements multi-entités de clients, le ticket récurrent "ma permission a disparu" n'est presque jamais un bug : c'est le cache de session. GLPI charge les droits du profil dans $_SESSION au moment de la connexion. Si vous ajustez le masque de bits pendant que le technicien est connecté, il conserve les anciens droits jusqu'à ce qu'il change d'entité dans le sélecteur ou se reconnecte. Nous avons appris à inscrire "demander à l'utilisateur de se déconnecter et de se reconnecter" dans le script de validation lui-même et à toujours tester dans une session neuve ou privée - sinon vous jurez avoir bien configuré et l'utilisateur jure que ça ne marche pas, tous deux ayant raison en même temps.

Les autres qui génèrent le plus d'incidents :

• Visibilité "Tous" pour le technicien - accorder "voir tous les tickets" fait que le technicien voit les tickets de toutes les entités auxquelles il a accès, pas seulement la sienne. Chez un client avec des domaines sensibles (RH, Juridique) c'est une fuite silencieuse. Préférez "de son groupe".
• Oublier is_recursive - attribuer le profil sur l'entité racine sans cocher la récursion fait que l'utilisateur ne voit aucune sous-entité. Le symptôme classique est "je me connecte mais je ne vois rien". L'inverse, une récursion indue, accorde un accès bien trop large sans que personne ne s'en aperçoive.
• Droit de la Centrale sur un profil Helpdesk - l'interface Helpdesk ignore la plupart des droits de la Centrale. Cocher des permissions d'actifs sur un profil helpdesk ne fait rien ; le menu n'existe tout simplement pas dans cette interface.
• Règles d'attribution dans le mauvais ordre - qui utilise LDAP ou SSO attribue le profil via les Règles d'attribution d'habilitations (RuleRight). La règle générique "attribuer Self-Service" doit venir en dernier ; placée en haut sans "arrêter le traitement", elle l'emporte sur toutes les règles spécifiques et tout le monde atterrit en Self-Service.
• Ne pas tester dans la peau du Self-Service - beaucoup de défauts n'apparaissent que dans l'interface Helpdesk. Gardez un utilisateur de test par profil et parcourez le vrai parcours avant la mise en production.

Checklist de durcissement des profils

1. Partez de la matrice minimale ; clonez les profils au lieu de modifier ceux d'usine.
2. Réglez la visibilité des tickets sur "de son groupe" par défaut ; "Tous" seulement avec une justification écrite.
3. Vérifiez l'indicateur is_recursive sur chaque attribution d'entité.
4. Exécutez le SQL de diagnostic chaque mois et retirez le privilège accumulé.
5. Gardez un utilisateur de test par profil et validez dans une session neuve après tout changement.
6. Restreignez qui modifie les Profils et les Règles : le droit UPDATE sur profile et rule est, en pratique, un droit d'administrateur.

Besoin d'un contrôle d'accès à des écrans et systèmes externes depuis GLPI lui-même, avec une matrice auditable ? Découvrez le module Access Matrix. Et si vous préférez externaliser la conception et la maintenance des profils, NexTool déploie et maintient des environnements GLPI multi-entités avec une gouvernance d'accès revue régulièrement.

Révisé par l'équipe NexTool Solutions.