Le sujet que les documentations d'installation n'abordent jamais
GLPI est un logiciel largement déployé, donc étudié par les chercheurs comme par les attaquants. Des vulnérabilités critiques y ont été publiées, certaines permettant une exécution de code sans authentification, et elles ont été exploitées sur des instances non mises à jour.
Ce n'est pas un reproche à l'éditeur : c'est la condition normale de toute application web. La différence entre une instance saine et une instance compromise ne tient pas au produit, elle tient au délai entre la publication d'un correctif et son application.
Une veille qui tient en trois gestes
Elle échoue toujours pour la même raison : elle n'est datée nulle part. Trois gestes suffisent, et le troisième est le seul qui la rende réelle.
S'abonner aux annonces de l'éditeur et aux avis de sécurité nationaux, qui relaient les vulnérabilités des logiciels répandus.
Noter la version installée dans un endroit consulté, avec la date de sa mise en service.
Poser un rendez-vous récurrent, mensuel, pour comparer la version installée à la dernière publiée. Un ticket récurrent, exactement comme au chapitre du ticketing : ce qui n'existe pas comme tâche datée ne se fait pas.
Deux rythmes distincts
Confondre les deux conduit soit à l'immobilisme, soit au risque.
Les correctifs de sécurité s'appliquent vite, en jours, quitte à accepter une courte interruption. La sauvegarde préalable reste obligatoire, le reste de la procédure se raccourcit.
Les montées de version fonctionnelles se planifient, avec vérification des plugins et essai préalable, comme vu au chapitre de l'exploitation.
Une instance qui attend la prochaine version majeure pour appliquer un correctif critique passe des mois exposée.
Les données personnelles des tickets
Les tickets contiennent des noms, des adresses, parfois des informations sur des personnes identifiables. Trois obligations pratiques en découlent.
Une durée de conservation décidée et appliquée, par la purge automatique déjà réglée au chapitre de l'exploitation.
Une réponse possible à une demande d'accès. Une personne peut demander ce que l'entreprise détient sur elle : la recherche doit pouvoir aboutir, ce qui suppose de savoir où se trouvent les tickets la concernant.
Des pièces jointes maîtrisées. Une capture d'écran déposée dans un ticket peut contenir bien plus que le problème. La règle utile est de n'y mettre que ce qui sert au diagnostic.
Quand GLPI ralentit
Trois causes couvrent la quasi-totalité des cas, dans cet ordre.
L'historique non purgé, déjà nommé au premier chapitre. C'est le premier poste à vérifier, et souvent le seul à traiter.
Le journal de messagerie et les tâches automatiques accumulées, qui gonflent des tables consultées à chaque page.
Une base sans entretien, dont les statistiques et les index se dégradent avec le volume.
Avant d'ajouter du processeur, mesurez : une page lente à cause d'une table de plusieurs millions de lignes ne s'accélère pas en doublant la mémoire.
GLPI est un service critique
Constat d'expérience qui surprend : le jour d'un incident majeur, l'outil qui porte les tickets, les procédures et l'inventaire est aussi celui dont on a le plus besoin.
Deux conséquences.
GLPI figure dans votre plan de reprise, avec son délai de remise en service, et il n'est pas le dernier de la liste.
Ce qui est vital ne vit pas uniquement dedans. Les coordonnées des prestataires, les accès aux sauvegardes et la première page du plan de reprise existent aussi hors ligne. Une base de connaissances excellente et inaccessible n'aide personne.
À retenir
Le risque ne tient pas au produit mais au délai d'application des correctifs : abonnez-vous, notez votre version, posez un rendez-vous mensuel. Correctifs de sécurité en jours, montées fonctionnelles planifiées. Purgez avant d'agrandir la machine. Et gardez hors de GLPI ce dont vous aurez besoin le jour où GLPI est tombé.