Supervision, journaux centralisés et alertes sur l'infrastructure de GSB

Conditions de réalisation

Ressources fournies : le laboratoire existant (pare-feu pfSense, cinq zones VLAN : WEB, BDD, ADM, USERS et VISITEURS, serveurs web et base en grappe de trois nœuds, Active Directory, bastion, sauvegarde nocturne), son plan d’adressage et son schéma (le schéma et les flux du lab).

Contexte et besoin de GSB. Les serveurs du siège rendent des services à toute l’entreprise (annuaire, DHCP / DNS, messagerie, intranet, bases de données, application de suivi des visites). Les visiteurs répartis sur le territoire ont besoin d’un service continu. La DSI veut être alertée avant les utilisateurs, réagir selon la gravité et protéger les services essentiels quand le réseau est chargé.

Cadre juridique. Les journaux contiennent des données personnelles (identifiants, adresses, connexions). Base légale : l’intérêt légitime de GSB à garantir la sécurité de son système d’information (RGPD, article 6.1.f). Durées : recommandation CNIL 2021-122, soit authentification 1 an, autres journaux 6 mois, métriques 30 jours. Information des personnes par la charte informatique de GSB, inscription au registre des traitements, accès en lecture seule, aucun transfert hors de l’Union européenne pour les journaux.

Description des ressources documentaires, matérielles et logicielles utilisées

Descriptif de la réalisation

Solution retenue et alternatives écartées. Retenue : Prometheus (mesures), rsyslog vers le cluster de bases (journaux), Grafana (écran et alertes, sa base dans le cluster) : un seul écran, et le cluster héberge des données réelles. Écartées : Zabbix seul (journaux faibles) ; Graylog (MongoDB et OpenSearch, trop lourd) ; Loki (journaux hors du cluster) ; Centreon et Icinga (pas de journaux, Icinga exige Redis) ; Uptime Kuma (disponibilité seulement).

Impact sur mon laboratoire existant. Deux machines supplémentaires dans la zone d’administration ; alias et règles de pare-feu dédiés (flux de mesures et de journaux, limités à un hôte source et à des ports précis, voir la matrice de flux) ; écriture des journaux et de la base de Grafana dans le cluster ; bruit des journaux réduit à la source ; horloges des zones web et base corrigées (NTP) ; zone VISITEURS ajoutée pour l’extension qualité de service. Mémoire globale du laboratoire à surveiller (30 Gio).

Mise en place. Étapes 46 à 52 de la documentation du laboratoire et procédures MO-13 à MO-17 ; un script, ajouter-machine.sh, installe l’exporteur et le transfert des journaux sur une nouvelle machine.

Tests réalisés. Sondes à probe_success = 1, cibles up, test de bout en bout d’un échec SSH et d’un événement Windows 4625 dans le tableau de bord. Pannes provoquées avec alerte reçue : service, machine, vrai arrêt de VM, nœud de base, sauvegarde, disque, mémoire, processeur, connexions refusées, arrêt de Prometheus, site lent (29 et 30 octobre), perte de quorum du cluster (2 novembre). Non-régression du cloisonnement vérifiée. Plan de tests : 39 tests, 38 réalisés ; reste l’exercice d’incident (janvier 2027).

Exploitation : supervision, incident, mode dégradé. Alertes par e-mail, 17 règles, toutes éprouvées par une panne provoquée, à deux niveaux de gravité (critique : rappel toutes les heures ; avertissement : rappel toutes les 24 h) ; une règle « supervision aveugle » évite les mails trompeurs quand Prometheus tombe ou quand Grafana perd sa base. Les alertes de sécurité et celles qui durent plus de 2 heures ouvrent un ticket GLPI, rattaché à la machine et résolu automatiquement au retour à la normale. Détection d’intrusion (Wazuh dans les machines, Suricata sur le réseau des zones USERS et VISITEURS) : ses alertes graves arrivent par le même circuit de mails. Escalade en trois niveaux : technicien, puis responsable du service Réseau et Système après 2 h, puis DSI avant le délai de reprise. Mode dégradé : un nœud de base arrêté, le site reste disponible ; arrêt réel d’une VM web sans coupure du site ; perte de quorum : le dernier nœud refuse d’écrire, puis le cluster se reforme seul.

Amélioration proposée au-delà du besoin. Limitation de débit de la zone VISITEURS, réalisée et mesurée le 12 novembre : plafond de 50 Mbit/s par sens pour toute la zone. Page d’accueil du site vue d’un poste salarié : 138 ms à vide, 344 ms quand un poste invité sature la zone sans limite, 136 ms avec la limite. La priorité au trafic de l’application de suivi n’est pas mise en place.