⚠️ Disclaimer

La méthode que je présente ici correspond à ma propre démarche d’apprentissage. Elle peut contenir des approximations ou des erreurs, car j’apprends et je progresse chaque jour un peu plus. Ne prenez donc pas ce que je fais comme une référence absolue, mais plutôt comme un retour d’expérience personnel.

Avant de commencer : Mon ressenti sur ce premier projet

Quand j’ai découvert le sujet de ce premier projet, quelque chose a immédiatement résonné avec mon expérience passée de Data Analyst. La gestion des tickets dans GLPI m’a rappelé mes années à gérer les demandes des utilisateurs concernant mes outils BI. Certes, je n’avais pas de référentiel ITIL à l’époque, mais j’avais développé mon propre système de classification des priorités selon la nature du problème : un souci technique sur l’outil, des données erronées remontées, ou simplement un utilisateur qui ne maîtrisait pas correctement la solution. C’était mon propre classement empirique, construit au fil de l’expérience.

Mais ce qui m’a le plus marqué dans ce projet, c’est évidemment le scénario de départ : un serveur GLPI en panne et pas de sauvegarde récente. Cette situation m’a fait prendre conscience d’une vérité fondamentale en infrastructure IT : la sauvegarde, c’est la base absolue de tout projet. Que ce soit un snapshot, une sauvegarde complète sur un autre serveur ou dans le cloud, peu importe la méthode, il faut toujours prévoir des plans B. C’est une leçon que je n’oublierai pas.

Au-delà de la reconstruction technique, une question me trottait dans la tête tout au long du projet : pourquoi ce serveur est-il tombé en panne ? Dans un environnement réel, cette panne n’aurait-elle pas pu être détectée en amont grâce à du monitoring des performances du serveur ? C’est là que j’ai vraiment compris que la cybersécurité, l’administration système et les réseaux relèvent avant tout de la prévoyance. Il ne s’agit pas seulement de réagir aux incidents, mais de les anticiper. Le monitoring, l’analyse des logs, la surveillance proactive des ressources : tout cela permet d’identifier les signaux faibles avant qu’ils ne deviennent des pannes critiques. Pour moi, ce projet a été une excellente introduction à cette philosophie : anticiper plutôt que subir. Et c’est exactement cette approche que je veux développer dans ma reconversion en cybersécurité. ( On essaiera plusieurs tests sur le homelab, notamment au niveau du monitoring. )

Le jour où tout a planté (et où il n’y avait pas de sauvegarde)

Vous savez ce moment où vous regardez un écran noir et où vous réalisez que oui, c’est vraiment cassé, et que non, il n’y a pas de backup récent ? C’est exactement le scénario de mon premier projet dans le cadre de ma formation Administrateur Systèmes, Réseaux et Sécurité (ASRS).

Le contexte : Une entreprise , un serveur GLPI en panne totale, des tickets de support qui s’accumulent, et une mission claire : tout reconstruire de zéro tout en assurant la continuité du service IT.

C’est le genre de situation qui fait pâlir n’importe quel administrateur système, mais c’est aussi une opportunité d’apprentissage exceptionnelle pour démarrer une formation.

Ce qui rend ce projet particulièrement formateur, c’est qu’il simule une situation que tout administrateur système redoute… et que beaucoup rencontrent un jour. On ne parle pas ici d’une simple installation “suivez le tuto” : on parle de reconstruire une infrastructure critique sous pression, avec des processus métier à maintenir et des utilisateurs qui attendent.

Les objectifs étaient ambitieux :

  • Reconstruire un serveur GLPI 10+ sur Debian 12 (pile LAMP complète)
  • Sécuriser l’installation selon les bonnes pratiques
  • Réintégrer tout un backlog de tickets en attente
  • Appliquer rigoureusement la méthodologie ITIL
  • Mettre en place l’inventaire automatisé
  • Formaliser les processus pour le support N1

Pour un premier projet de formation, c’est un sacré baptême du feu !

La stack technique : Retour aux fondamentaux Linux

L’environnement

Pour ce projet, j’ai travaillé sur :

  • Debian 12 “Bookworm” en CLI (pas d’interface graphique, on fait les choses sérieusement !)
  • Pile LAMP : Apache2, MariaDB 10+, PHP 8+
  • GLPI 10.x comme solution ITSM
  • VMware Workstation Pro pour la virtualisation
  • Un client Windows 10 pour tester l’agent d’inventaire

Installation et premier piège : La sécurisation d’Apache

L’installation de la pile LAMP en elle-même n’était pas le plus complexe. Mais GLPI 10 a introduit une nouvelle architecture de sécurité qui m’a donné du fil à retordre au début.

Après l’installation, GLPI affichait un avertissement de sécurité concernant l’accessibilité de certains dossiers sensibles. La solution ? Reconfigurer Apache pour pointer le DocumentRoot vers le dossier /public de GLPI au lieu de la racine de l’application.

1
2
3
4
5
6
7
8

# Configuration sécurisée dans le VirtualHost Apache
DocumentRoot /var/www/html/glpi/public

<Directory /var/www/html/glpi/public>
    Options -Indexes +FollowSymLinks
    AllowOverride All
    Require all granted
</Directory>

Décomposition de cette configuration :

  • DocumentRoot : Définit le répertoire racine accessible depuis le web
  • Options -Indexes : Empêche l’affichage du contenu des répertoires (sécurité)
  • +FollowSymLinks : Autorise le suivi des liens symboliques
  • AllowOverride All : Permet l’utilisation de fichiers .htaccess pour des règles supplémentaires
  • Require all granted : Autorise l’accès à ce répertoire

Ce que j’ai appris : On ne configure pas juste “pour que ça marche”, on configure pour que ce soit sécurisé. Chaque application web a ses propres bonnes pratiques, et GLPI ne déroge pas à la règle.

MariaDB : Sécuriser avant de produire

La sécurisation de MariaDB a été une étape cruciale. J’ai utilisé mysql_secure_installation pour :

  • Supprimer les comptes anonymes
  • Désactiver la connexion root à distance
  • Supprimer la base de test

Puis création d’un utilisateur dédié avec les privilèges minimums nécessaires :

1
2
3
4

CREATE DATABASE glpidb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'glpiuser'@'localhost' IDENTIFIED BY '[mot_de_passe_fort]';
GRANT ALL PRIVILEGES ON glpidb.* TO 'glpiuser'@'localhost';
FLUSH PRIVILEGES;

Explication ligne par ligne :

  • CHARACTER SET utf8mb4 : Jeu de caractères étendu supportant les émojis et caractères spéciaux
  • COLLATE utf8mb4_unicode_ci : Règles de tri et comparaison insensibles à la casse
  • 'glpiuser'@'localhost' : Utilisateur limité aux connexions locales uniquement
  • GRANT ALL PRIVILEGES ON glpidb.* : Droits complets UNIQUEMENT sur la base GLPI

Principe du moindre privilège : Une application ne doit jamais tourner avec le compte root de la base de données. C’est une règle d’or en sécurité.

ITIL en pratique : Gérer le chaos avec méthode

Le backlog de la terreur

Une fois le serveur opérationnel, j’ai dû intégrer un backlog conséquent de tickets en attente. C’est là que la méthodologie ITIL prend tout son sens.

ITIL (Information Technology Infrastructure Library) est le framework de référence pour la gestion des services IT. Dans ce projet, j’ai appliqué notamment :

  • La distinction Incident / Demande : Un incident interrompt ou dégrade un service existant, une demande est une évolution ou un besoin nouveau.
  • La priorisation Impact × Urgence : Chaque ticket est évalué selon son impact métier (combien d’utilisateurs affectés ?) et son urgence (délai critique ?) pour déterminer sa priorité.
  • L’escalade N1 → N2 : Les tickets simples restent au support de premier niveau, les cas complexes remontent au niveau 2.

Les cas complexes : Quand la technique rencontre l’humain

Certains tickets m’ont vraiment fait réfléchir au-delà de la technique pure :

Le conflit “Logiciel de Comptabilité”

Une utilisatrice était bloquée par un logiciel qu’elle ne maîtrisait pas, coincée entre son manager qui refusait une formation et les besoins opérationnels urgents.

Ma réponse :

  • Création de tickets liés (un pour l’urgence immédiate, un pour la demande de formation)
  • Rédaction d’un document de médiation expliquant les risques du statu quo
  • Un email personnalisé à l’utilisatrice pour la rassurer sur la prise en charge

Leçon apprise : Un bon technicien IT ne fait pas que résoudre des problèmes techniques. Il doit aussi savoir communiquer, médiatiser et documenter pour éviter que les problèmes organisationnels ne se reproduisent.

La configuration VPN Partenaire

Rédiger une communication technique formelle avec les paramètres IPsec (IKEv2, AES-256, SHA-256, Perfect Forward Secrecy…) m’a obligé à réviser mes connaissances réseau et à comprendre ce que je demandais réellement.

Points techniques abordés :

  • Phase 1 (IKE) : Établissement du tunnel sécurisé entre les deux équipements VPN
  • Phase 2 (IPsec) : Chiffrement des données transitant dans le tunnel
  • PFS (Perfect Forward Secrecy) : Garantit que la compromission d’une clé ne compromet pas les sessions passées
  • Paramètres cryptographiques modernes : AES-256 pour le chiffrement, SHA-256 pour l’intégrité

L’Agent GLPI : L’inventaire qui fait gagner du temps

La mise en place de l’agent d’inventaire GLPI sur un poste Windows a été une étape particulièrement gratifiante. Plutôt que de saisir manuellement chaque composant de chaque machine, l’agent remonte automatiquement :

  • L’inventaire matériel complet (processeur, RAM, disques, cartes réseau…)
  • Les logiciels installés et leurs versions
  • Les informations réseau (adresse IP, MAC, configuration…)
  • Les licences détectées

Le piège que j’ai rencontré : Trouver la bonne URL cible pour l’agent. Ce n’est pas juste http://[IP_SERVEUR] mais bien http://[IP_SERVEUR]/front/inventory.php. Un détail qui m’a coûté quelques minutes de débogage !

Formalisation des processus : Le logigramme N1

Pour aider à la formation du support N1, j’ai créé un logigramme décrivant le cycle de vie d’un ticket :

  1. Création du ticket par l’utilisateur ou le technicien
  2. Qualification : S’agit-il d’un incident ou d’une demande ?
  3. Priorisation : Calcul Impact × Urgence
  4. Traitement N1 : Résolution si le problème est standard
  5. Escalade N2 si nécessaire (cas complexe ou hors compétence N1)
  6. Résolution et clôture avec documentation
  7. Retour utilisateur pour validation

Cette formalisation permet de standardiser les pratiques et de ne rien oublier dans le traitement d’un ticket. C’est un outil de formation essentiel pour les nouveaux arrivants au support.

Les défis techniques rencontrés

Connectivité réseau en mode Bridged

Travailler sur un portable qui passe du Wi-Fi à l’Ethernet selon les lieux m’a obligé à bien comprendre le fonctionnement du mode “Accès par pont” dans VMware. Parfois, un simple redémarrage du service réseau suffisait :

1

sudo systemctl restart networking.service

D’autres fois, il fallait vérifier quelle carte physique était utilisée par le pont dans la configuration de VMware.

Apprentissage : Les environnements de lab ne sont jamais aussi stables qu’on le voudrait. Il faut savoir diagnostiquer et s’adapter aux changements d’infrastructure, même mineurs.

Documentation vs. Exécution

Un défi constant dans ce projet : documenter au fur et à mesure sans perdre le fil technique. Chaque action dans GLPI doit être tracée via les “suivis”, chaque décision justifiée, chaque résolution documentée.

Ce que ce projet m’a apporté

Au-delà des compétences techniques, ce projet m’a appris quelque chose de fondamental : l’administration système, c’est 50% de technique et 50% de méthodologie.

Les compétences techniques acquises

  • Administration Debian en CLI : Installation, configuration, gestion des services (systemctl), permissions (chmod, chown)
  • Configuration sécurisée d’une pile LAMP : Apache, MariaDB, PHP avec leurs interdépendances
  • Gestion MariaDB : Création de bases, utilisateurs, gestion des privilèges, sauvegarde (mysqldump)
  • Maîtrise de GLPI : Configuration, gestion des utilisateurs/groupes/profils, traitement de tickets, inventaire
  • Application pratique d’ITIL : Priorisation, escalade, distinction incident/demande, base de connaissances

Lien avec la cybersécurité

Ce projet, bien qu’axé “administration système”, pose des bases cruciales pour la cybersécurité :

  • Principe du moindre privilège : Chaque utilisateur/service n’a que les droits strictement nécessaires à son fonctionnement
  • Sécurisation en profondeur : Chaque couche (base de données, serveur web, application) doit être durcie indépendamment
  • Traçabilité : Tous les événements et actions doivent être loggés et suivis pour l’audit et l’investigation
  • Procédure de réponse à incident : La procédure “Machine Infectée” créée est une mini-réponse à incident malware
  • Gestion des accès : Utilisateurs, groupes, profils dans GLPI = Introduction pratique à l’IAM (Identity and Access Management)
  • Hardening système : Sécuriser MariaDB, Apache, supprimer les services inutiles = Réduction de la surface d’attaque

Ces fondamentaux s’appliquent directement aux métiers SOC, pentesting et architecture sécurité que je vise.

Les livrables produits

Pour ce projet, j’ai produit l’ensemble des livrables demandés :

  • Un dump SQL complet de la base GLPI configurée avec tous les tickets traités
  • 4 documents PDF : médiation pour le conflit logiciel, communication technique VPN, demande d’achat matériel, email utilisateur personnalisé
  • Une présentation complète sur l’Agent GLPI (rôle, avantages, mise en place, démonstration)
  • Un logigramme des processus N1 pour la formation du support de premier niveau
  • Une procédure de réponse à incident pour les machines infectées par malware

Le code et les livrables anonymisés de ce projet seront disponibles sur mon GitHub.

Prochain article : je vous parlerai de mon second projet

Projet réalisé dans le cadre de la formation Administrateur Systèmes, Réseaux et Sécurité - Octobre 2025