Déploiement d'une infrastructure GLPI sécurisée

Ce projet porte sur la conception et le déploiement d'une infrastructure GLPI sécurisée, pensée selon de bonnes pratiques d'administration systèmes et réseaux. L'architecture repose sur une séparation des rôles afin de renforcer la sécurité et la robustesse de l'ensemble.

Un serveur GLPI hébergeant l'interface web (Apache / PHP), accessible aux utilisateurs. Un serveur de base de données dédié, situé sur un réseau interne, est accessible uniquement depuis le serveur GLPI, afin d'isoler les données sensibles.

Technologies utilisées

Sommaire

I. Objectif du projet
II. Inventaire de l'infrastructure
III. Topologie de l'infrastructure GLPI
IV. Technologie utilisée

I. Objectif du projet

L'objectif de ce projet est de concevoir et de déployer une infrastructure GLPI sécurisée, en appliquant de bonnes pratiques d'administration systèmes et réseaux.

L'architecture repose sur une séparation des rôles entre deux serveurs distincts : un serveur GLPI hébergeant l'interface web (Apache / PHP), accessible aux utilisateurs, et un serveur de base de données dédié, situé sur un réseau interne, accessible uniquement depuis le serveur GLPI. Cette séparation permet d'isoler les données sensibles et de renforcer la robustesse de l'ensemble.

Au cours de ce projet, les éléments suivants ont été mis en place :

  • Installation et configuration du serveur GLPI
  • Mise en place de l'environnement web (Apache, PHP)
  • Déploiement et sécurisation du serveur de base de données
  • Configuration des communications entre les serveurs
  • Vérification du bon fonctionnement et de la conformité de l'infrastructure

Ce projet a pour but de démontrer ma capacité à concevoir, configurer et valider une infrastructure applicative dans un contexte professionnel, en mettant l'accent sur la sécurité, la clarté de l'architecture et la cohérence des choix techniques.

II. Inventaire de l'infrastructure

L'infrastructure repose sur deux réseaux distincts : un réseau LAN interne hébergeant les hyperviseurs et les serveurs sensibles, et une zone DMZ exposant uniquement le serveur web GLPI accessible aux utilisateurs.

A. LAN 01 : 172.16.0.0

Machine Adresse IP Masque Passerelle Rôles
ESXi 172.16.0.100 255.255.255.0 172.16.0.254 Hyperviseur type 1
SRV-AD 172.16.0.1 255.255.255.0 172.16.0.254 Annuaire Active Directory
SRV-BDD-GLPI 172.16.0.7 255.255.255.0 172.16.0.254 Base de données GLPI

Tableau — Inventaire LAN 01 : 172.16.0.0

B. LAN 02 : 192.168.200.0

Machine Adresse IP Masque Passerelle Rôles
Hyper-V 192.168.200.200 255.255.255.0 192.168.200.254 Hyperviseur de type 1
SRV-WEB (GLPI) 192.168.200.1 255.255.255.0 192.168.200.254 Serveur Apache et PHP

Tableau — Inventaire LAN 02 : 192.168.200.0

III. Topologie de l'infrastructure GLPI

Le schéma ci-dessous représente l'architecture globale de l'infrastructure GLPI déployée, avec la séparation entre le réseau LAN interne et la zone DMZ. Cliquez sur l'image pour l'agrandir.

Topologie Infrastructure GLPI
Zoom

Schéma — Topologie Infrastructure GLPI multi-serveurs

IV. Technologie utilisée

GLPI 10

Solution de gestion de parc informatique et de tickets. Elle centralise les équipements, les utilisateurs, les incidents et les demandes dans une interface unique.

Apache 2.4

Serveur web qui héberge l'application GLPI. Il reçoit les requêtes des utilisateurs via le navigateur et transmet les pages générées par l'application.

PHP 8.3

Langage utilisé par GLPI pour fonctionner. Il exécute le code de l'application et génère dynamiquement les pages web affichées aux utilisateurs.

PHP-FPM

Gestionnaire de processus qui exécute les scripts PHP de manière optimisée. Il améliore les performances et assure une communication efficace entre Apache et le moteur PHP.

MariaDB 11.x

Système de gestion de base de données utilisé pour stocker toutes les données de GLPI (utilisateurs, tickets, équipements, etc.). Il centralise et sécurise les données de l'application.

V. Configuration du serveur GLPI

Dans cette section, je configure le serveur applicatif destiné à héberger GLPI. Je mets en place l'environnement web (Apache et PHP), je déploie l'application et je sécurise les répertoires sensibles en appliquant une séparation entre les fichiers publics et les fichiers internes.

Je vérifie également le bon fonctionnement de l'intégration entre Apache et PHP-FPM afin de garantir une exécution correcte et sécurisée de l'application.

Serveur GLPI

Serveur GLPI — ip a

Les configurations suivantes concerneront le serveur 192.168.200.1

A.  Mise en place de l'environnement applicatif

Vérification de l'installation du serveur Apache
Vérification installation Apache

Je vérifie que le serveur Apache est bien installé sur le système. La présence du paquet Apache HTTP Server confirme que le service web nécessaire à l'hébergement de GLPI est correctement déployé et opérationnel.

Apache permet de traiter les requêtes HTTP et de fournir l'interface web de GLPI aux utilisateurs.

Vérification de la version et du fonctionnement de PHP
Vérification version PHP

L'utilisation d'une version récente et stable garantit le bon fonctionnement et les performances de l'application.

Je vérifie la version de PHP installée sur le serveur afin de m'assurer de sa compatibilité avec GLPI. Apache permet de traiter les requêtes HTTP et de fournir l'interface web de GLPI aux utilisateurs.

PHP est le moteur d'exécution de l'application : il interprète le code dynamique et génère les pages web affichées dans le navigateur.

Validation des extensions PHP nécessaires à GLPI
Extensions PHP installées

Je vérifie que l'ensemble des extensions PHP requises par GLPI sont bien installées.

Ces modules permettent notamment :

  • la communication avec la base de données,
  • la gestion des fichiers et des images,
  • la compression et la mise en cache,
  • l'authentification via LDAP / Active Directory.

Cette validation confirme que l'environnement PHP est complet et que GLPI peut interagir correctement avec les différents composants de l'infrastructure.

GLPI téléchargé + déployé dans /var/www
Déploiement GLPI dans /var/www

L'application GLPI est correctement déployée dans le répertoire /var/www/glpi.

La structure complète des fichiers et dossiers de l'application est présente, ce qui confirme que le déploiement a été effectué correctement.

Utilisation du répertoire public comme point d'entrée
Répertoire public GLPI

Le répertoire public est bien utilisé comme point d'entrée de l'application.

Ce choix permet de limiter l'exposition des fichiers sensibles en ne rendant accessibles via le navigateur que les éléments strictement nécessaires au fonctionnement de l'interface web.

Vérification des droits et du propriétaire des fichiers
Droits et propriétaire /var/www/glpi

Les répertoires /var/www/glpi et /var/www/glpi/public appartiennent à l'utilisateur et au groupe www-data, utilisés par Apache.

Les permissions appliquées permettent au serveur web d'accéder aux fichiers nécessaires tout en évitant l'attribution de droits excessifs.

B.  Sécurisation et cloisonnement des répertoires applicatifs

Séparation des répertoires sensibles
Séparation des répertoires sensibles

Je vérifie que les répertoires dédiés à la configuration, aux données et aux journaux de GLPI existent en dehors du répertoire web principal.

  • /etc/glpi pour les fichiers de configuration
  • /var/lib/glpi pour les données applicatives
  • /var/log/glpi pour les journaux

Cette organisation permet de séparer les fichiers sensibles des fichiers accessibles via le serveur web.

Déplacement des dossiers de configuration et de données
Déplacement dossiers config et données

Les dossiers config et files ont bien été déplacés vers leurs nouveaux emplacements sécurisés.

Le dossier de configuration est désormais situé dans /etc/glpi et le dossier contenant les fichiers applicatifs est stocké dans /var/lib/glpi/files. Ils ne sont plus présents dans /var/www/glpi, ce qui empêche toute exposition directe via le serveur web.

Redirection des chemins de configuration GLPI
Redirection chemins downstream.php et local_define.php

Je configure GLPI pour utiliser un répertoire de configuration situé en dehors du dossier web principal.

Le fichier downstream.php définit le chemin /etc/glpi comme répertoire de configuration principal étant donné que j'ai déplacé les fichiers sensibles précédemment. Cette redirection permet à l'application de ne plus utiliser le dossier config situé dans /var/www/glpi.

Cette approche évite que les fichiers de configuration sensibles soient exposés via le serveur web.

Définition des répertoires de données et de logs
Définition répertoires de données et logs

Je définis explicitement les emplacements des données applicatives et des journaux dans le fichier local_define.php.

Les constantes internes de GLPI (GLPI_CONFIG_DIR, GLPI_VAR_DIR, GLPI_LOG_DIR) pointent correctement vers les nouveaux emplacements définis.

Cette validation confirme que l'application utilise bien les chemins sécurisés configurés et que la séparation des répertoires est pleinement opérationnelle.

C.  Configuration et sécurisation du VirtualHost Apache

Validation du VirtualHost Apache
Validation VirtualHost Apache

Je vérifie que le VirtualHost dédié à GLPI est bien chargé par Apache. La configuration active montre que le site glpi-lab est correctement activé et associé au port 80.

DocumentRoot sécurisé
DocumentRoot VirtualHost sécurisé

Je configure le VirtualHost pour que le répertoire exposé publiquement soit /var/www/glpi/public.

Ce choix permet de limiter l'accès aux seuls fichiers nécessaires à l'exécution de l'application et d'éviter l'exposition directe de l'ensemble du dossier GLPI.

D.  Intégration et configuration du moteur PHP-FPM

Service PHP-FPM
Statut du service php8.3-fpm

Le service PHP-FPM est bien actif et configuré pour démarrer automatiquement avec le système.

Socket PHP-FPM
Fichier socket php8.3-fpm.sock dans /run/php/

Le fichier socket php8.3-fpm.sock est bien dans le répertoire /run/php/. La présence de ce fichier confirme que PHP-FPM fonctionne correctement et qu'il est prêt à recevoir les requêtes envoyées par le serveur web.

Ce socket permet la communication entre Apache et PHP-FPM.

Liaison entre Apache et PHP-FPM
Configuration FileMatch SetHandler dans glpi-lab.conf

Le VirtualHost Apache est configuré pour transmettre les fichiers .php au moteur PHP-FPM via le socket Unix.

La directive SetHandler confirme que toute requête concernant un fichier PHP est redirigée vers PHP-FPM pour exécution.

Modules Apache nécessaires à PHP-FPM
Modules proxy, proxy_fcgi et setenvif activés dans Apache

Je vérifie que les modules Apache requis pour la communication avec PHP-FPM sont bien activés.

La présence des modules proxy, proxy_fcgi et setenvif confirme que le serveur web est capable de transmettre les requêtes PHP au moteur FastCGI.

Test d'exécution PHP via Apache

Je réalise un test d'exécution en créant temporairement un fichier phpinfo() accessible via le navigateur. Ce test montre concrètement que le moteur PHP est bien interprété via Apache.

Test phpinfo() affiché dans le navigateur via Apache
  • Apache traite la requête HTTP,
  • La requête est transmise à PHP-FPM,
  • Le moteur PHP exécute correctement le code.

Ce test valide le bon fonctionnement de la chaîne complète : navigateur → Apache → PHP-FPM.

Suppression du fichier de test et contrôle d'accès
Suppression de info.php et erreur 403 dans le navigateur

Après validation, je supprime le fichier de test info.php montrant que la tentative d'accès ultérieure retourne une erreur 403, ce qui confirme que le fichier n'est plus accessible et que le serveur applique correctement les règles de sécurité.

E.  Validation applicative et contrôle des journaux

Vérification du comportement HTTP
wget --spider retournant 403 Forbidden après suppression de info.php

Je réalise un test HTTP en local afin de vérifier la réponse du serveur web après suppression du fichier de test.

La réponse 403 Forbidden confirme que l'accès au fichier n'est plus autorisé, ce qui valide le bon fonctionnement des règles de sécurité côté Apache.

Vérification des logs Apache
tail des logs access.log et error.log d'Apache

Je consulte ensuite les journaux Apache afin de contrôler le comportement du service. Le serveur fonctionne normalement et aucune erreur critique n'est détectée.

Cette vérification démontre que le serveur web répond correctement aux requêtes et applique les restrictions prévues.

Journaux applicatifs GLPI
ls -la /var/log/glpi montrant les fichiers de journaux GLPI

Je vérifie la présence des journaux applicatifs dans le répertoire /var/log/glpi. Les fichiers de logs liés aux accès, aux erreurs PHP, aux événements et aux tâches planifiées sont bien présents.

Cette validation confirme que GLPI enregistre correctement ses activités et que la redirection des journaux vers un répertoire dédié fonctionne comme prévu.

VI. Configuration de la base de données

Dans cette section, je mets en place le serveur de base de données dédié à GLPI. Je configure MariaDB, je sécurise les comptes administrateur et je crée une base ainsi qu'un utilisateur spécifique pour l'application.

Je vérifie également la communication entre le serveur GLPI et le serveur de base de données afin de garantir un fonctionnement correct dans une architecture multi-serveurs.

Serveur Base de données MariaDB

ss -ltnp et ip a sur le serveur MariaDB — 172.16.0.7

Les configurations suivantes concerneront le serveur 172.16.0.1

A.  Installation et validation du moteur MariaDB

Vérification de l'installation et du service MariaDB
dpkg -l | grep mariadb listant les paquets installés

Les paquets MariaDB nécessaires au fonctionnement du serveur de base de données sont correctement installés.

systemctl status mariadb montrant active (running) et enabled

Le statut indique que le service est actif (running) et activé (enabled), ce qui confirme que le moteur de base de données fonctionne correctement et est prêt à traiter les requêtes SQL provenant du serveur GLPI.

B.  Durcissement des comptes système et contrôle des accès

Comptes MariaDB
Table mysql.user listant glpi_adm, mariadb.sys, mysql, root

Je vérifie la liste des comptes présents dans la table système mysql.user.

  • L'utilisateur applicatif glpi_adm est configuré pour se connecter depuis n'importe quelle adresse (%),
  • Les comptes système internes (mariadb.sys, mysql) sont limités à localhost,
  • Le compte administrateur root est restreint à localhost.

Cette configuration démontre que l'accès administrateur distant est désactivé et que l'application GLPI utilise un compte dédié distinct du compte root.

Restriction du compte root à localhost
Erreur 1045 Access denied en distant + root | localhost en local

Je vérifie spécifiquement que le compte root est autorisé uniquement depuis localhost.

Cette restriction empêche toute connexion distante au compte administrateur de la base de données, ce qui constitue une mesure de sécurité essentielle.

C.  Création et gestion des ressources dédiées à GLPI

Base de données GLPI
SHOW DATABASES listant db_glpi

La présence de la base db_glpi dans la liste des bases confirme que l'environnement est prêt à accueillir les tables et les données de l'application.

Cette séparation permet d'isoler les données GLPI des bases système internes, renforçant l'organisation et la sécurité de l'infrastructure.

Utilisateur GLPI
SELECT User Host montrant glpi_adm avec hôte %

L'utilisateur glpi_adm est bien présent dans la table des utilisateurs MariaDB.

Cet utilisateur est configuré pour se connecter depuis n'importe quelle adresse (%), ce qui permet au serveur GLPI de communiquer avec le serveur de base de données situé sur un autre réseau.

Privilèges de l'utilisateur GLPI
SHOW GRANTS FOR glpi_adm@% montrant GRANT ALL PRIVILEGES ON db_glpi

La configuration montre que cet utilisateur dispose de l'ensemble des droits sur la base db_glpi, tout en restant limité à cette base uniquement.

D.  Configuration réseau et validation de la communication inter-serveurs

Configuration de l'écoute réseau MariaDB
grep bind-address montrant 0.0.0.0 dans la configuration MariaDB

Le paramètre bind-address est configuré sur 0.0.0.0 ce qui permet au serveur MariaDB d'écouter sur toutes les interfaces réseau, et non uniquement sur localhost — rendant possible la connexion distante depuis le serveur GLPI.

Vérification de l'écoute du port 3306
ss -ltnp | grep 3306 montrant LISTEN sur 0.0.0.0:3306

La présence de l'état LISTEN sur l'adresse 0.0.0.0:3306 confirme que le service accepte les connexions réseau et que le moteur MariaDB est prêt à traiter les requêtes provenant du serveur applicatif.

Test de connexion distante entre le serveur GLPI et le serveur MariaDB
mysql -h 172.16.0.7 -u glpi_adm -p depuis le serveur GLPI

Je teste la connexion distante à la base de données depuis le serveur GLPI en utilisant l'utilisateur applicatif glpi_adm.

Cela confirme les configurations précédentes : accès sur le réseau, port 3306 ouvert, les privilèges de l'utilisateur glpi_adm.

VII. Configuration supplémentaire

A.  Intégration LDAP et authentification Active Directory

Compte de liaison LDAP dans Active Directory
Propriétés du compte ldap-glpi dans Active Directory

Ce compte est utilisé exclusivement pour permettre à GLPI d'interroger l'annuaire Active Directory.

Configuration de l'annuaire LDAP dans GLPI
Interface de configuration LDAP dans GLPI

Je configure un nouvel annuaire LDAP dans GLPI afin d'intégrer l'authentification Active Directory.

Je renseigne

  • Le nom du serveur Active Directory,
  • L'adresse IP du contrôleur de domaine,
  • Le port LDAP (389),
  • La base DN correspondant au domaine,
  • Le compte de liaison ldap-glpi,
  • Ainsi que les paramètres de synchronisation des utilisateurs.

Cette configuration permet à GLPI de se connecter à l'annuaire Active Directory pour authentifier les utilisateurs et synchroniser leurs informations.

B.  Déploiement automatisé de l'agent GLPI via GPO

J'ai stocké l'agent GLPI dans un dossier partagé afin de le partager sur le réseau.

Droit sur le partage réseau
Autorisations de partage réseau — Utilisateurs authentifiés en lecture

Le groupe Utilisateurs authentifiés est autorisé en lecture, ce qui permet aux postes clients membres du domaine d'accéder au partage sans donner de privilèges excessifs.

Autorisations NTFS
Permissions NTFS — Utilisateurs authentifiés en lecture et exécution

Le groupe Utilisateurs authentifiés dispose des permissions de lecture et d'exécution, ainsi que de l'affichage du contenu du dossier.

Déploiement du package GLPI Agent via GPO
GPO Installation de logiciel — GLPI Agent 1.5 attribué

J'ai configuré une stratégie de groupe afin de déployer automatiquement le package GLPI Agent 1.5 sur les postes du domaine.

Le logiciel est attribué aux ordinateurs via les paramètres d'installation logicielle, ce qui permet un déploiement automatique lors du démarrage des machines.

Configuration des préférences de registre dans la GPO
GPO — Préférences > Paramètres Windows > Registre

Je configure des paramètres de registre via les préférences de la stratégie de groupe.

Cette configuration permet de définir automatiquement les paramètres de l'agent GLPI sur les postes clients, notamment l'adresse du serveur et les informations d'identification du domaine.

L'utilisation des préférences de registre assure une configuration homogène et contrôlée sur l'ensemble du parc.

Configuration de l'adresse du serveur GLPI
Propriété de registre SOFTWARE\GLPI-Agent — clé server pointant vers l'URL GLPI

Je définis dans le registre la clé SOFTWARE\GLPI-Agent afin d'indiquer à l'agent l'adresse du serveur GLPI.

La valeur configurée pointe vers l'URL du serveur, permettant aux agents installés sur les postes clients d'envoyer leurs informations d'inventaire vers la plateforme GLPI.

Configuration du tag d'identification
Propriété de registre SOFTWARE\GLPI-Agent — clé tag avec valeur LAPULY.local

Je configure un paramètre supplémentaire dans le registre afin d'attribuer un tag d'identification aux machines.

Ce tag permet d'identifier et de classer les équipements dans GLPI selon le domaine ou l'environnement concerné.

VIII. Test de fonctionnement

Dans cette section, j'effectue des tests de fonctionnement afin de valider l'ensemble des configurations ci-dessus.

A.  Test d'authentification via Active Directory

1

Connexion utilisateur AD

Page de connexion GLPI avec utilisateur direction1 via SRV-AD.LAPULY.local
Connexion à GLPI avec un compte du domaine Active Directory — source SRV-AD.LAPULY.local

Je me connecte avec un utilisateur de mon domaine via LDAP.

2

Interface GLPI

Tableau de bord GLPI après connexion réussie
Résultat — Accès à l'interface GLPI avec le compte Active Directory

La connexion a réussi. L'authentification LDAP fonctionne correctement.

B.  Validation du cycle complet d'un ticket (Front-end ↔ BDD)

1

Création de ticket

Ticket TEST-BDD créé dans GLPI avec pièce jointe
Ticket créé depuis l'interface GLPI — titre unique TEST-BDD avec pièce jointe

Un ticket a été créé depuis l'interface GLPI avec un titre unique et une pièce jointe afin de valider le bon fonctionnement de l'application.

2

Vérification de l'enregistrement du ticket dans la BDD (SRV-BDD-GLPI)

Requête MySQL sur glpi_tickets — ticket TEST-BDD présent
Vérification côté base de données — ticket TEST-BDD enregistré dans la table glpi_tickets

Côté serveur de base de données (SRV-BDD-GLPI), le ticket est correctement enregistré dans la table glpi_tickets de la base MariaDB, confirmant l'écriture des données applicatives.

3

Vérification du stockage de l'image sur le serveur GLPI

find /var/lib/glpi montrant les fichiers créés par la pièce jointe
Côté SRV-GLPI — fichiers créés dans /var/lib/glpi/files suite à l'ajout de la pièce jointe

Côté serveur GLPI (SRV-GLPI), l'ajout de la pièce jointe entraîne bien la création de fichiers dans le répertoire applicatif /var/lib/glpi/files.

Aucune donnée utilisateur n'est stockée dans le DocumentRoot (/var/www/glpi), ce qui confirme la séparation entre contenu web public et données sensibles, conformément à l'architecture définie.

L'enregistrement dans la base de données et le stockage des pièces jointes sur le serveur GLPI fonctionnent correctement.

C.  Validation du déploiement de l'agent et remontée d'inventaire

1

Exécution de gpupdate /force

PowerShell — gpupdate /force sur le poste client
Exécution de gpupdate /force sur le poste client — application de la stratégie de groupe

La stratégie de groupe a été appliquée avec succès sur le poste client, confirmant le bon déploiement automatisé de l'agent GLPI via GPO.

2

L'agent est bien installé sur les postes

Programmes et fonctionnalités — GLPI Agent 1.5 installé
Panneau de configuration — GLPI Agent 1.5 présent dans les programmes installés du poste client

L'agent GLPI est correctement installé sur le poste client, comme confirmé dans les programmes installés du système.

3

GLPI récupère les données des postes

Interface GLPI — ordinateur CLIENT-01 avec inventaire logiciel
Fiche inventaire CLIENT-01 dans GLPI — logiciels et matériel remontés automatiquement

Le poste client remonte bien dans l'interface GLPI, avec un inventaire matériel et logiciel visible et à jour, attestant de la communication entre le client et le serveur GLPI.

L'agent GLPI se déploie correctement au sein de l'infrastructure. Les ressources remontent dans le dashboard GLPI.