Gestion et Sécurisation du Parc Informatique

1. Contexte et Objectifs

Suite à la fusion Solutech/Horizon, l'équipe IT hérite d'un parc informatique non documenté, sans inventaire fiable ni contrôle des accès. Cette situation génère une alerte de sécurité de niveau orange : impossible de protéger ce qu'on ne connaît pas.

Objectifs : reprendre le contrôle du patrimoine IT via un inventaire automatisé (GLPI), cloisonner les données des deux entités pour respecter la confidentialité, implémenter un modèle RBAC pour limiter les droits d'accès au strict nécessaire, et durcir la sécurité en supprimant les comptes et services par défaut.

2. Besoins identifiés

Visibilité sur le patrimoine : Sans inventaire automatisé, impossible de connaître le nombre exact de machines, les versions logicielles déployées, l'état des licences ou les équipements en fin de vie. Cela expose à des risques financiers (audit), juridiques (conformité) et opérationnels (pannes).

Cloisonnement Solutech/Horizon : La fusion impose une séparation stricte des données via des entités GLPI dédiées. Un technicien Solutech ne doit pas accéder aux machines Horizon sans autorisation, garantissant confidentialité et conformité RGPD.

RBAC et comptes nominatifs : Chaque utilisateur reçoit un rôle précis (Administrateur, Technicien, Auditeur) avec des droits limités au strict nécessaire. Les comptes génériques (glpi, tech, normal) doivent être supprimés car ils constituent une faille de sécurité majeure.

Durcissement système : Suppression des comptes par défaut, activation HTTPS obligatoire, désactivation des services inutiles, restriction des flux réseau. Le système ne doit jamais rester en configuration d'origine.

Automatisation via GLPI-Agent : Installation d'un agent sur chaque machine pour remonter automatiquement l'inventaire (matériel, OS, logiciels, réseau) vers le serveur GLPI, éliminant la saisie manuelle et détectant le Shadow IT.

3. Solution technique

Architecture : GLPI (Gestionnaire Libre de Parc Informatique) est une application web de gestion d'actifs IT fonctionnant sur une stack LAMP (Linux Apache MariaDB PHP). GLPI-Agent est un programme installé sur chaque poste qui scanne le système et envoie l'inventaire au serveur via HTTP/HTTPS.

Stack technique : Debian 13, Apache 2.4, MariaDB 10.11, PHP 8.2, GLPI-Agent 1.7+

Concepts clés GLPI :

  • Entités : Organisations logiques qui cloisonnent les données (Solutech / Horizon). Chaque machine est rattachée à une entité, garantissant la séparation.

  • Profils (Rôles RBAC) : Ensemble de permissions (lecture/écriture) définissant ce qu'un utilisateur peut faire. Exemples : Super-Admin (tout), Technicien (tickets + parc), Auditeur (lecture seule).

  • Comptes Nominatifs : Chaque utilisateur est identifié par prenom.nom, relié à un profil et une entité. Garantit la traçabilité (qui a fait quoi, quand).

  • CMDB (Configuration Management Database) : GLPI modélise les relations entre actifs (ordinateur → utilisateur → licence → contrat). Permet de répondre à des questions complexes (quelles machines ont Windows 7 ? combien de licences Office utilisées ?).

  • Shadow IT : Équipements ou logiciels non autorisés utilisés sans validation IT. L'agent GLPI détecte automatiquement ces anomalies (logiciel non approuvé installé, machine inconnue sur le réseau).

4. Réalisation

Phase 1 : Installation du serveur GLPI

Stack LAMP : Installation de Debian 13, puis Apache, MariaDB et PHP. Sécurisation de MariaDB via mysql_secure_installation (définition mot de passe root, suppression comptes anonymes).

Base de données : Création de glpidb avec utilisateur dédié glpiuser ayant les droits nécessaires.

Installation GLPI : Téléchargement de l'archive depuis GitHub, extraction dans /var/www/html/glpi, ajustement des permissions (chown www-data:www-data). Configuration via interface web (connexion base, création tables).

Phase 2 : Durcissement système (Hardening)

Suppression des failles critiques : - Suppression du fichier install/install.php (empêche réinstallation malveillante) - Suppression des comptes par défaut glpi, tech, normal, post-only (mots de passe publics) - Création de comptes nominatifs prenom.nom avec mots de passe forts

Activation HTTPS : 

sudo a2enmod ssl
sudo a2ensite default-ssl
sudo sed -i '/VirtualHost \*:80/a Redirect permanent / https://IP_VM/' /etc/apache2/sites-available/000-default.conf
sudo systemctl restart apache2

Phase 3 : Gouvernance et cloisonnement

Création des entités : Structure hiérarchique Entité Racine > Solutech > Horizon, chacune avec ses propres règles de visibilité.

Configuration RBAC : Création des profils Super-Admin, Technicien, Auditeur avec droits granulaires. Affectation des utilisateurs aux profils et entités selon leur périmètre d'intervention.

Partitionnement technique : Restriction des droits par entité (un technicien Solutech ne voit que son périmètre). Configuration dans Administration > Profils > Entités.

Phase 4 : Déploiement GLPI-Agent

Windows : Installation du MSI avec URL du serveur http://IP_GLPI/front/inventory.conf.php et option "Lancer l'inventaire immédiatement".

Linux : Installation via paquet, configuration de /etc/glpi-agent/agent.cfg avec l'URL du serveur, lancement manuel via glpi-agent --force.

Vérification : Les machines apparaissent automatiquement dans Parc > Ordinateurs avec toutes leurs informations (OS, RAM, CPU, logiciels, réseau).

Phase 5 : MCO (Maintien en Condition Opérationnelle)

  • Déploiement automatisé de l'agent via GPO (Windows) ou Ansible (Linux)
  • Inventaires planifiés toutes les 24h
  • Surveillance des machines "perdues" (pas d'inventaire depuis 7 jours)
  • Traçabilité via tickets GLPI pour toute modification du parc
  • Sauvegarde quotidienne de la base MariaDB (mysqldump + cron)

5. Preuves de réalisation

Capture 1 : Tableau de bord GLPI et cloisonnement par entité

Dashboard GLPI

Légende : Tableau de bord GLPI montrant la vue d'ensemble complète du parc informatique de la fusion Solutech-Horizon : 114.7K logiciels inventoriés, 5.4K ordinateurs, 1.2K matériels réseau, 1.5K téléphones, ainsi que les statistiques détaillées (licences, moniteurs, baies, imprimantes). L'indicateur d'entité en haut à droite affiche "Super-Admin - Entité racine > Agence Horizon", démontrant le cloisonnement actif entre les deux organisations. Cette capture prouve que le système de partitionnement fonctionne : un administrateur connecté à l'entité Horizon ne voit que les données de son périmètre. Le graphique des tickets par mois montre l'activité du helpdesk (1.5K tickets ouverts, 2 en retard, 1.5K problèmes et changements), validant l'utilisation opérationnelle de GLPI pour la gestion du parc et du support.

Éléments techniques visibles : - Dashboard central avec indicateurs temps réel (logiciels, ordinateurs, réseau, téléphones) - Cloisonnement entité : "Agence Horizon" visible en permanence dans l'interface - Statistiques utilisateurs (4.2K), groupes (129), fournisseurs (56), documents (38.0K) - Graphiques de suivi : statuts tickets par mois, répartition par fabricant/modèle/statut - Architecture multi-entités avec 67 entités configurées, 15 profils RBAC, 1.5K base de connaissances

Capture 2 : Historique complet d'un ticket (Traçabilité et imputabilité)

Historique ticket

Légende : Historique détaillé du ticket "[PROJET HORIZON] - Déploiement d'un utilitaire technique" montrant la traçabilité complète de toutes les actions effectuées sur ce ticket. Chaque ligne représente une modification (changement de statut, ajout de description, mise à jour de champ, ajout de lien, modification d'ordinateur) avec trois informations critiques : la date et heure exacte (2026-01-26 11:33, 11:32, 11:31...), l'utilisateur responsable (YVON Jordann (B)), et le type de modification (changement de date de clôture, passage à statut "Clos", changement de statut "En cours (Attribué)" à "Résolu", ajout d'élément...). Cette capture démontre l'imputabilité garantie par les comptes nominatifs : on sait toujours qui a fait quoi, quand, et sur quel objet. Impossible de modifier un ticket anonymement. Le compteur "Historique : 13" indique que 13 actions ont été tracées, offrant une transparence totale sur le cycle de vie du ticket.

Éléments techniques visibles : - 13 entrées d'historique horodatées à la seconde près - Identification systématique de l'acteur (YVON Jordann (B)) - Types de modifications tracées : statut, date de clôture/résolution, description, logiciel, ordinateur, liens - Navigation temporelle : possibilité de remonter tout l'historique d'un objet depuis sa création - Audit trail complet : aucun changement ne peut être effectué sans traçabilité

Capture 3 : Détail d'un ticket et cycle de vie complet

Détail ticket

Légende : Vue détaillée du ticket "[PROJET HORIZON] - Déploiement d'un utilitaire technique" montrant le cycle de vie complet d'une demande de support. La demande initiale (en vert) décrit le besoin : "installation du logiciel VMware Workstation sur le poste pour les besoins du service". La réponse du technicien (en gris) confirme la résolution : "Le logiciel est correctement installé". Les dates clés prouvent la réactivité du service : ouverture le 2026-01-26 à 11:19:02, résolution à 11:32:15 (13 minutes de traitement), fermeture à 11:33:18 (1 minute de validation). Le ticket est rattaché à l'entité "Agence Horizon", confirmant le respect du cloisonnement. Le statut final "Clos" avec bouton "Rouvrir" permet une reprise si nécessaire. Le panneau de droite liste les éléments associés : ordinateur "Pc_de_Jordann", logiciel "VMware Workstation", demandeur "YVON Jordann", source "Helpdesk", urgence "Moyenne", impact "Moyen", priorité "Moyenne". Cette capture valide le respect des bonnes pratiques ITIL : catégorisation, prioritisation, traçabilité, association aux éléments du parc.

Éléments techniques visibles : - Cycle de vie complet : ouverture → résolution (13 min) → fermeture (1 min) - Cloisonnement : ticket rattaché à l'entité "Agence Horizon" - Catégorisation ITIL : Type "Demande", Source "Helpdesk", Urgence/Impact/Priorité configurés - Association CMDB : lien avec ordinateur (Pc_de_Jordann) et logiciel (VMware Workstation) - Traçabilité : demandeur identifié (YVON Jordann), acteurs visibles, historique accessible - Workflow : possibilité de rouvrir le ticket si nécessaire, garantissant la continuité de service