Gestion de parc informatique avec GLPI · Étape 03

Conçois l'architecture GLPI et sépare les données sensibles

Place correctement frontal web, application, base, tâches automatiques, fichiers, logs et sauvegardes afin de réduire l'exposition et préparer l'exploitation.

Durée indicative · ~1 h 35Niveau intermédiairePrérequis conseillé · Leçon 2 — organisation, profils et périmètresPratique · TP
L’idée reçue

« Si la page de connexion fonctionne, l’architecture est terminée. »

Une plateforme exploitable doit aussi protéger les fichiers persistants, exécuter les tâches automatiques, sauvegarder la base et produire des journaux utiles.

01Identifie les composants

Utilisateur
    ↓ HTTPS
Reverse proxy ou serveur web

Application GLPI / runtime PHP
    ├── base de données
    ├── configuration protégée
    ├── fichiers persistants
    ├── journaux
    ├── tâches automatiques
    ├── messagerie
    └── agents d'inventaire

Chaque liaison possède une identité, un protocole, des droits et une méthode de diagnostic.

02Lis le contrat d’architecture

lab=/tmp/soria-glpi-foundations-$USER
cat "$lab/input/architecture.env"
GLPI_FQDN=glpi.lab.soria.invalid
TLS_REQUIRED=true
WEBROOT=/var/www/glpi/public
CONFIG_DIR=/etc/glpi
DATA_DIR=/var/lib/glpi
LOG_DIR=/var/log/glpi
DB_HOST=db-glpi
DB_USER=glpi_app
CRON_MODE=system
BACKUP_ENCRYPTED=true

Ce fichier ne contient aucun mot de passe. Il exprime les choix d’architecture, pas les secrets d’exécution.

03Réduis le document root

Le serveur web doit exposer uniquement les fichiers publics nécessaires. Les éléments suivants n’ont pas vocation à être téléchargés directement :

- configuration ;
- fichiers téléversés ;
- sessions ou caches persistants ;
- journaux ;
- sauvegardes ;
- exports contenant des données personnelles.

Le lab vérifie que CONFIG_DIR, DATA_DIR et LOG_DIR ne se trouvent pas sous WEBROOT.

04Sépare l’identité applicative

Compte de base GLPI
- accès uniquement à la base GLPI
- pas de rôle d'administration générale
- secret fourni par le mécanisme de déploiement
- rotation documentée

Compte système du service web
- lecture du code
- écriture seulement dans les répertoires nécessaires
- aucun shell administratif ordinaire

Le nom glpi_app est présent dans le dossier. Son mot de passe ne doit jamais l’être.

05Prévois les tâches automatiques

Sans scheduler fiable, certaines opérations restent en attente : notifications, collecte, escalades, maintenance ou traitements différés.

CRON_MODE=system

Le choix du planificateur système doit être accompagné de :

- fréquence connue ;
- compte d'exécution ;
- journal séparé ;
- alerte si la dernière exécution est trop ancienne ;
- commande compatible avec la version réellement installée.

06Traite la base et les fichiers comme un ensemble

Une sauvegarde cohérente doit couvrir les données nécessaires à une restauration complète.

Base de données
+ configuration utile
+ fichiers persistants
+ liste des plugins et versions
+ procédure de restauration
+ preuve de test

Sauvegarder uniquement la base ou uniquement les fichiers peut produire une plateforme incomplète.

07Définis la frontière de preuve

Le rapport généré contient :

proof_scope=design-dossier-only

Cela signifie que le lab prouve :

- cohérence des chemins ;
- présence des garde-fous ;
- organisation des objets ;
- matrice de droits ;
- intégrité du dossier.

Il ne prouve pas :

- installation de GLPI ;
- connexion à MariaDB ;
- certificat réellement servi ;
- envoi de courriel ;
- exécution d'un agent ;
- restauration réussie.
Mission

Dessine l’architecture exploitable

Produis un diagramme indiquant DNS, TLS, frontal web, runtime, base, scheduler, répertoires persistants, logs, sauvegarde et agents. Pour chaque flux, indique le compte utilisé, les données transportées et la preuve de fonctionnement attendue.

À retenir

L’architecture GLPI ne se limite pas au serveur web. La séparation des données, des identités et des preuves prépare la sécurité, la sauvegarde et le diagnostic.

Ta progression

Chargement de l’état… Se connecter pour synchroniser.