Chapitre 5 - Sécurité et sauvegardes

HTTPS, reverse proxy, permissions, sauvegarde et restauration.

HTTPS et reverse proxy Caddy
Sécurité, pare-feu et clés de chiffrement
Sauvegarde complète de GLPI
Restauration de GLPI

HTTPS et reverse proxy Caddy

10.1 Exemple avec Caddy

Sur le serveur Caddy :

glpi.dreamsaphir.fr {
    reverse_proxy 192.168.1.100:80
}

Puis :

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

Le DNS public doit pointer vers Caddy et les ports 80/443 doivent arriver sur Caddy, pas directement sur le serveur GLPI.

10.2 Conserver l’adresse IP du client

Si Apache n’est accessible que depuis Caddy, activer mod_remoteip :

sudo a2enmod remoteip

Ajouter dans le VirtualHost, en remplaçant l’adresse de Caddy :

RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 192.168.1.10

Puis :

sudo apache2ctl configtest
sudo systemctl reload apache2

Ne jamais faire confiance à X-Forwarded-For provenant de n’importe quelle adresse.

Documentation GLPI 11 — Debian 12, Apache, PHP 8.2 et MariaDB.

Sécurité, pare-feu et clés de chiffrement

10.3 Pare-feu

Si Caddy est sur une autre machine, autoriser le port 80 uniquement depuis son adresse :

sudo apt install -y nftables

La politique exacte dépend du pare-feu déjà présent. Ne pas activer une nouvelle politique restrictive à distance avant d’avoir explicitement autorisé SSH et vérifié la console de secours.

10.4 Mesures indispensables

utiliser HTTPS uniquement ;
pointer Apache vers /var/www/glpi/public ;
changer ou désactiver les comptes par défaut ;
activer la MFA pour les administrateurs ;
appliquer rapidement les versions de sécurité ;
sauvegarder la base, les documents, la configuration et les clés ;
limiter les droits MariaDB à la seule base glpi ;
utiliser LDAPS plutôt que LDAP simple ;
limiter l’accès SSH aux administrateurs ;
ne pas exposer MariaDB sur Internet ;
maintenir Debian, Apache, PHP et les plugins ;
vérifier régulièrement les journaux ;
tester les restaurations ;
limiter les données personnelles collectées au strict besoin.

10.5 Clés de chiffrement

GLPI utilise des clés pour chiffrer certaines informations sensibles. Les fichiers présents dans /etc/glpi, notamment glpi.key, glpicrypt.key, oauth.pem et oauth.pub selon la configuration, doivent faire partie de chaque sauvegarde.

La perte de la base seule est grave. La perte de la base accompagnée des clés peut rendre certaines données chiffrées définitivement inutilisables.

Documentation GLPI 11 — Debian 12, Apache, PHP 8.2 et MariaDB.

Sauvegarde complète de GLPI

Une sauvegarde GLPI complète contient au minimum :

la base MariaDB ;
/etc/glpi ;
/var/lib/glpi/files ;
/var/lib/glpi/marketplace ;
/var/www/glpi/inc/downstream.php ;
la configuration Apache et, si utilisé, Caddy.

Un snapshot de VM est pratique avant une opération, mais ne remplace pas une sauvegarde exportée et testée.

11.1 Sauvegarde manuelle

Créer un dossier daté :

sudo install -d -m 0700 /var/backups/glpi
BACKUP_DATE="$(date +%F_%H-%M-%S)"
sudo install -d -m 0700 "/var/backups/glpi/${BACKUP_DATE}"

Sauvegarder la base :

sudo mariadb-dump \
  --single-transaction \
  --quick \
  --routines \
  --triggers \
  glpi \
  | sudo gzip \
  > "/var/backups/glpi/${BACKUP_DATE}/glpi-database.sql.gz"

Sauvegarder les fichiers :

sudo tar -czf \
  "/var/backups/glpi/${BACKUP_DATE}/glpi-files.tar.gz" \
  /etc/glpi \
  /var/lib/glpi/files \
  /var/lib/glpi/marketplace \
  /var/www/glpi/inc/downstream.php \
  /etc/apache2/sites-available/glpi.conf

Contrôler :

sudo ls -lh "/var/backups/glpi/${BACKUP_DATE}"
sudo gzip -t \
  "/var/backups/glpi/${BACKUP_DATE}/glpi-database.sql.gz"
sudo tar -tzf \
  "/var/backups/glpi/${BACKUP_DATE}/glpi-files.tar.gz" \
  | head

Copier ensuite cette sauvegarde vers un autre serveur ou support. Une sauvegarde conservée uniquement sur la VM GLPI ne protège pas contre la perte de cette VM.

Documentation GLPI 11 — Debian 12, Apache, PHP 8.2 et MariaDB.

Restauration de GLPI

11.2 Restauration de la base

Activer la maintenance :

cd /var/www/glpi
sudo -u www-data php bin/console glpi:maintenance:enable

Recréer une base vide :

sudo mariadb

DROP DATABASE glpi;
CREATE DATABASE glpi
  CHARACTER SET utf8mb4
  COLLATE utf8mb4_unicode_ci;
GRANT ALL PRIVILEGES ON glpi.* TO 'glpi'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Restaurer :

sudo gzip -dc \
  /var/backups/glpi/DATE/glpi-database.sql.gz \
  | sudo mariadb glpi

Restaurer les fichiers :

sudo tar -xzf \
  /var/backups/glpi/DATE/glpi-files.tar.gz \
  -C /

Rétablir les permissions :

sudo chown -R www-data:www-data \
  /etc/glpi \
  /var/lib/glpi \
  /var/log/glpi

Contrôler puis désactiver la maintenance :

cd /var/www/glpi
sudo -u www-data php bin/console glpi:system:check_requirements
sudo -u www-data php bin/console db:check_schema_integrity
sudo -u www-data php bin/console glpi:maintenance:disable

Ne jamais restaurer une sauvegarde sur une base ayant déjà subi une migration partielle. Recréer une base vide avant une nouvelle tentative.

Documentation GLPI 11 — Debian 12, Apache, PHP 8.2 et MariaDB.