Un audit GLPI consiste à contrôler la version installée, les comptes créés par défaut, l’exposition du serveur sur le web et les droits des profils, puis à relire l’historique des objets. GLPI centralise l’inventaire du parc et les tickets du support : une faille sur ce serveur donne une vue complète sur le système d’information.
Pourquoi auditer une installation GLPI
Un serveur GLPI contient la liste des machines et des logiciels, les comptes des utilisateurs, l’historique des tickets et, selon la configuration, des identifiants de connexion à l’annuaire. Un attaquant qui y accède sait quels postes sont obsolètes et qui a quels droits.
Cet audit reste ciblé sur une application. Pour évaluer l’ensemble de votre protection (réseau, postes, procédures), lisez notre article sur l’audit de sécurité informatique, dont celui-ci reprend la logique appliquée à un seul outil.
Vérifier la version et les correctifs installés
La version de GLPI s’affiche dans l’interface, en bas de page et dans le menu de configuration. Le projet recommande, pour la production, la dernière version stable de la branche en cours. Les versions correctives ne contiennent que des corrections de bugs et de failles, ce qui les rend sans risque pour la compatibilité des modules.
Pour savoir si votre version est concernée par une vulnérabilité publiée, consultez les avis de sécurité du dépôt GitHub du projet et la base CVE. Chaque avis indique les versions touchées et la version qui corrige le défaut. Une installation restée sur une ancienne branche ne reçoit plus ces correctifs : la mise à jour de branche devient alors le premier chantier.
Relevez la version, la date de la dernière mise à jour et la branche suivie dans votre compte rendu d’audit. Ces trois lignes suffisent pour comparer deux contrôles successifs.
Neutraliser les comptes par défaut et revoir les profils
L’installation crée quatre comptes de démonstration : glpi (administrateur), tech (technicien), normal et post-only, chacun avec un mot de passe prévisible. La documentation d’installation demande de les supprimer ou de les modifier, et GLPI affiche une alerte tant que ces mots de passe n’ont pas changé.
Avant de supprimer le compte glpi, créez un autre utilisateur doté du profil super-admin, sinon vous perdez l’accès à l’administration. Désactivez ensuite les trois autres comptes si vous ne vous en servez pas.
Passez ensuite les profils en revue. Les profils de type super-admin ne doivent concerner que deux ou trois personnes identifiées. Les techniciens n’ont pas besoin des droits de configuration, et le profil self-service suffit aux utilisateurs qui ouvrent seulement des tickets. Vérifiez aussi les habilitations par entité : un technicien rattaché à une seule entité ne doit pas voir les autres.
Terminez par les comptes inactifs. Un ancien prestataire ou un collaborateur parti depuis des mois garde souvent un accès actif, et c’est l’un des contrôles les plus rapides à faire.
Contrôler l’exposition du serveur GLPI sur le web
Un serveur GLPI joint depuis Internet sans précaution multiplie la surface d’attaque. Voici les points à contrôler dans la configuration du serveur web :
- la racine web pointe sur le dossier prévu à cet effet dans la version installée, et non sur la racine de l’application ;
- le script d’installation a été retiré une fois l’installation terminée ;
- les dossiers de configuration, de fichiers déposés et de journaux ne sont pas accessibles par une adresse web, la documentation recommandant de les placer hors de la racine web ;
- l’accès se fait en HTTPS uniquement, avec une redirection depuis le port non chiffré.
Mieux vaut aussi réserver l’accès au réseau interne ou le passer derrière un VPN. L’approche décrite dans notre article sur les avantages et inconvénients du Zero Trust s’applique bien ici : chaque connexion est vérifiée, même venue du réseau de l’entreprise.
Le choix de l’hébergement pèse aussi dans cette exposition. Notre comparatif des solutions cloud et serveurs locaux détaille ce qui change pour la surveillance et les mises à jour. Pour aller plus loin, il existe un outil libre de recherche de vulnérabilités dédié à GLPI, à lancer avec l’accord de l’exploitant du serveur et uniquement sur vos propres installations.
Exploiter l’historique et les journaux de GLPI
La plupart des objets de GLPI (ordinateurs, utilisateurs, tickets, profils) possèdent un onglet Historique qui consigne chaque modification : qui l’a faite, quand, et quelle valeur a changé. Il sert à reconstituer ce qui s’est passé après un incident, par exemple l’ajout d’un droit à un compte qui n’en avait pas.
Le journal des événements de l’administration complète cette trace avec les connexions et les actions sensibles. Vérifiez la durée de conservation réglée dans la configuration : trop courte, elle efface les preuves avant qu’on les cherche ; trop longue, elle alourdit la base.
Pour un contrôle de conformité, l’historique prouve qu’une modification de droits a été faite par une personne habilitée. Exportez-en un extrait lors de chaque audit et conservez-le avec le compte rendu.
Auditer aussi les logiciels inventoriés
Dans l’autre sens, audit GLPI désigne l’usage de l’outil pour contrôler le parc. L’inventaire remonte les logiciels installés sur chaque poste : triez-les par version pour repérer les programmes obsolètes, et rapprochez-les des licences déclarées pour voir celles qui manquent ou qui ne servent plus.
Planifier les corrections et la fréquence des contrôles
Classez les écarts par ordre de gravité. Une version vulnérable ou un compte par défaut encore actif passent avant un profil trop large, lui-même avant un réglage de conservation des journaux.
Avant toute mise à jour, sauvegardez la base de données et les fichiers, puis testez la montée de version sur une copie du serveur. Une mise à jour testée sur une copie évite une panne du support le jour où elle s’applique en production.
Programmez un contrôle complet à chaque nouvelle version majeure et après chaque départ ou arrivée dans l’équipe informatique. Plusieurs vérifications se prêtent à l’automatisation des tâches informatiques : relevé de la version, liste des comptes actifs, test d’accès depuis l’extérieur.
Gardez la liste des écarts d’un audit à l’autre : la prochaine passe commence par vérifier que ces points sont bien corrigés.
