Supervision des systèmes d’information avec Zabbix : cours, installation et sécurisation

Édition 2026 — Zabbix 7.4 / 7.0 LTS.

1. La supervision informatique

Dans une infrastructure informatique, garantir le bon fonctionnement des systèmes, des réseaux, des services et des applications est une obligation de service. Pour y parvenir, les organisations mettent en place des outils de supervision qui observent en permanence l’état et les performances des ressources, et signalent toute dérive avant qu’elle ne devienne une panne.

1.1 Définition

La supervision informatique désigne l’ensemble des outils et des méthodes permettant de surveiller, mesurer, analyser et alerter sur l’état d’un système d’information. Elle repose sur quatre briques :

• le monitoring : la collecte périodique de données (métriques, états, journaux) ;
• les alertes : la notification des équipes lorsqu’une valeur sort des seuils définis ;
• les tableaux de bord : la visualisation de l’état courant et des tendances ;
• les actions : les réactions programmées (redémarrage d’un service, exécution d’un script, ouverture d’un ticket).

Depuis quelques années, le terme d’observabilité étend cette définition : il ne s’agit plus seulement de savoir *qu’*un service est tombé, mais de disposer de suffisamment de signaux (métriques, journaux, traces applicatives) pour comprendre pourquoi. Les outils de supervision modernes, Zabbix compris, convergent progressivement vers ce modèle.

1.2 Objectifs

• Assurer la disponibilité des services rendus aux utilisateurs.
• Prévenir les incidents en détectant les signaux faibles (saturation progressive d’un disque, dérive de charge, certificat proche de l’expiration).
• Optimiser les performances et dimensionner correctement les ressources.
• Réduire le temps de détection (MTTD) et le temps de résolution des pannes (MTTR).
• Fournir des éléments de preuve et de traçabilité en cas d’incident de sécurité.

2. Les composants d’une chaîne de supervision

Quelle que soit la solution retenue, une chaîne de supervision s’articule autour des mêmes éléments :

Composant	Rôle
Agent / sondes	Collecter les données sur les machines supervisées : CPU, mémoire, disques, services, journaux.
Serveur de supervision	Centraliser les informations, évaluer les seuils et déclencher les alertes.
Base de données	Stocker l’historique des mesures, les événements et la configuration.
Interface web / tableau de bord	Visualiser l’état du système et administrer la solution (frontend Zabbix, Grafana).
Système d’alerte	Diffuser les notifications : courriel, SMS, webhook, messagerie d’équipe, outil de ticketing.
Collecteur intermédiaire (proxy)	Collecter localement sur un site distant puis transmettre au serveur, en réduisant sa charge.

3. Supervision et cybersécurité

La supervision est un pilier de la gestion des systèmes d’information, mais elle joue également un rôle stratégique en cybersécurité. Une console de supervision correctement paramétrée détecte des comportements qui ne sont pas des pannes : un compte qui échoue vingt fois à s’authentifier, un fichier système modifié, un volume de trafic sortant anormal la nuit, un service d’antivirus arrêté, un certificat expiré.

Cette dimension est aujourd’hui renforcée par le cadre réglementaire : la directive NIS 2, transposée en droit français, impose aux entités concernées des capacités de détection, de journalisation et de notification des incidents. La supervision constitue la première brique technique de cette exigence.

4. La solution Zabbix

Zabbix est une solution libre de supervision des réseaux, des systèmes et des applications, publiée sous licence AGPLv3 depuis la version 7.0. Elle offre une visibilité en temps réel sur l’état des infrastructures, qu’il s’agisse de serveurs physiques ou virtuels, d’équipements réseau, de services cloud ou d’applications métier.

4.1 Fonctionnalités clés

• Surveillance complète : serveurs, réseaux, applications, services, environnements virtualisés et cloud.
• Détection des problèmes : déclencheurs, corrélation d’événements et notifications temps réel.
• Tableaux de bord personnalisables : widgets, graphiques interactifs, cartes réseau, vues par service.
• Automatisation : découverte automatique des hôtes et des éléments, enregistrement automatique des agents, actions correctives.
• Extensibilité : API JSON-RPC, webhooks, modèles officiels et communautaires, plugins de l’agent 2.

4.2 Versions et cycle de vie

Zabbix alterne des versions LTS (support long, recommandées en production) et des versions standard (support court, nouvelles fonctionnalités). Le choix de la version conditionne la durée de maintenance et les prérequis logiciels.

Version	Type	Situation en septembre 2026
Zabbix 7.0	LTS	Version LTS de référence en production. Support complet jusqu’à mi-2027, support étendu jusqu’en 2029.
Zabbix 7.2	Standard	Fin de vie. À ne plus déployer.
Zabbix 7.4	Standard	Branche standard courante, utilisée dans ce livret. Support limité dans le temps : prévoir la migration.
Zabbix 8.0	LTS	Prochaine LTS (annoncée pour le second semestre 2026) : JSON natif, ClickHouse en historique, moteur de corrélation d’événements, OpenTelemetry annoncé.

5. Architecture et flux

Zabbix est modulaire : chaque composant peut être installé sur une machine dédiée, ce qui permet d’adapter l’architecture à la taille de l’infrastructure supervisée.

Composant	Rôle
Zabbix Server	Cœur de la solution : interroge les agents, reçoit les données, évalue les déclencheurs, exécute les actions.
Zabbix Frontend	Interface web en PHP : visualisation des événements, administration et configuration. Accessible depuis n’importe quel navigateur.
Base de données	MySQL/MariaDB, PostgreSQL ou TimescaleDB : configuration, historique des valeurs et événements.
Zabbix Proxy	Collecteur intermédiaire pour un site distant ou un segment isolé. Bufferise les données en cas de coupure et allège le serveur.
Zabbix Agent / Agent 2	Processus léger installé sur les machines supervisées. L’agent 2 (écrit en Go) ajoute la concurrence des contrôles et une architecture de plugins.

5.1 Flux réseau à connaître

La maîtrise des ports est indispensable pour ouvrir correctement les pare-feux et pour justifier les règles de filtrage lors d’une revue de sécurité.

Flux	Port	Sens
Console d’administration vers frontend	TCP 443 (80 à proscrire)	Poste admin → serveur web
Serveur/proxy vers agent (check passif)	TCP 10050	Serveur → hôte supervisé
Agent vers serveur/proxy (check actif)	TCP 10051	Hôte supervisé → serveur
Proxy vers serveur	TCP 10051	Proxy → serveur
Interrogation SNMP	UDP 161	Serveur/proxy → équipement
Réception de traps SNMP	UDP 162	Équipement → serveur/proxy
Accès à la base de données	TCP 3306 / 5432	Serveur et frontend → SGBD

6. Intégrer Zabbix dans une chaîne de sécurité

Zabbix n’est pas un SIEM, mais il s’intègre naturellement dans un dispositif de détection en alimentant ou en consommant d’autres outils.

6.1 Avec un SIEM

Un SIEM (Security Information and Event Management) collecte, normalise et corrèle les événements de sécurité provenant de sources multiples. Zabbix peut lui transmettre ses événements de trois manières : par webhook vers une API REST, par export temps réel des événements (fonction de streaming intégrée au serveur), ou par exportation de fichiers de journalisation.

• Solutions courantes : Splunk, IBM QRadar, Wazuh, la suite Elastic (Elasticsearch, Logstash, Kibana) ou OpenSearch.

6.2 Avec un IDS/IPS

Les sondes de détection d’intrusion analysent le trafic réseau. Zabbix peut superviser leur bon fonctionnement (service actif, règles à jour) et remonter leurs alertes via l’utilitaire zabbix_sender ou par lecture des journaux.

• Solutions courantes : Suricata, Snort, Zeek, Wazuh (HIDS).

6.3 Avec la gestion des vulnérabilités

Les scanners de vulnérabilités identifient les failles connues du parc. Zabbix ne les remplace pas, mais surveille la fraîcheur des analyses et le nombre de vulnérabilités critiques ouvertes, ce qui permet de suivre la tendance dans un tableau de bord.

• Solutions courantes : OpenVAS/Greenbone, Nessus, Qualys.

6.4 Avec la gestion des journaux et des identités

La collecte des journaux (Graylog, Rsyslog, Fluentd) alimente la détection ; la surveillance des annuaires (Active Directory, OpenLDAP, FreeIPA) permet de détecter les créations de comptes à privilèges, les verrouillages en série ou l’arrêt d’un service d’authentification.

7. Rappel Linux : su, su - et sudo

Sous Debian, les commandes su et su - permettent toutes deux de changer d’utilisateur, mais elles ne produisent pas le même environnement.

Commande	Comportement	Conséquence
su	Change d’identité sans recharger l’environnement du compte cible.	Les variables PATH, HOME, etc. restent celles de l’utilisateur de départ : certains binaires d’administration (/usr/sbin) peuvent ne pas être trouvés.
su -	Simule une connexion complète (équivalent de su -l).	PATH, HOME et le répertoire courant sont ceux du compte cible : environnement propre et prévisible.
sudo -i	Ouvre un shell root via sudo, avec traçabilité.	Chaque élévation est journalisée et rattachée à un compte nominatif : à privilégier en production.

8. Installer le serveur Zabbix

Une procédure d’installation recopiée dans un support de cours se périme vite : les numéros de version, les noms de paquets et l’adresse des dépôts changent à chaque publication. Zabbix met à disposition un configurateur en ligne qui génère la séquence exacte de commandes correspondant à votre contexte. C’est cette procédure qui fait foi.

8.1 Les choix à arrêter avant de commencer

Chaque paramètre du configurateur correspond à une décision d’architecture. Elle doit être justifiée et consignée dans le dossier technique.

Paramètre	Ce qui guide le choix	Configuration du plateau technique
Version de Zabbix	LTS en production, version standard pour découvrir les nouveautés. Vérifier la date de fin de support.	Zabbix 7.4 (branche standard)
Distribution et version	Le suffixe du paquet de dépôt en dépend (debian12, debian13, ubuntu24.04…). Un mauvais suffixe installe un dépôt inutilisable.	Debian 12 « bookworm »
Composants	Serveur, frontend, agent, proxy : tout n’est pas installé sur la même machine dans une architecture distribuée.	Serveur + frontend + agent sur la même machine
Base de données	MySQL/MariaDB, PostgreSQL ou TimescaleDB. Le nom du paquet serveur en dépend (zabbix-server-mysql ou zabbix-server-pgsql).	MariaDB, locale
Serveur web	Apache ou Nginx : détermine le paquet de configuration du frontend.	Apache
Version de PHP	Chaque version de Zabbix impose un minimum. Un frontend refusera de démarrer avec une version trop ancienne.	PHP fourni par Debian 12

Les choix se retrouvent dans l’adresse de la page générée, ce qui permet de conserver une trace exacte de la configuration retenue :

https://www.zabbix.com/download?zabbix=7.4&os_distribution=debian
  &os_version=12&components=server_frontend_agent&db=mysql&ws=apache

8.2 Ce que contient la procédure générée

Quelle que soit la combinaison retenue, la procédure officielle se déroule toujours selon le même enchaînement. Le comprendre permet de diagnostiquer une installation qui échoue, plutôt que de recommencer à l’aveugle.

Étape	Ce qui se passe	Point de vigilance
Ajout du dépôt Zabbix	Téléchargement et installation du paquet zabbix-release, qui déclare la source APT et la clé de signature.	Le suffixe de distribution doit correspondre à la machine. Vérifier l’empreinte du paquet téléchargé.
Installation des paquets	Serveur, frontend, configuration du serveur web, scripts SQL et agent.	Le paquet serveur diffère selon le SGBD choisi.
Création de la base	Création de la base, d’un compte applicatif dédié et attribution des privilèges.	Mot de passe robuste, compte limité à la base zabbix, jamais root.
Import du schéma	Chargement de la structure depuis les scripts fournis par le paquet.	Opération longue. Un paramètre de journalisation binaire est activé puis doit être remis à zéro.
Configuration du serveur	Renseignement des paramètres de connexion à la base dans zabbix_server.conf.	Le fichier contient un mot de passe en clair : ses droits doivent être restreints.
Démarrage des services	Activation et démarrage du serveur, de l’agent et du serveur web.	Contrôler le journal du serveur avant de conclure au bon fonctionnement.
Assistant du frontend	Paramétrage de la connexion à la base depuis le navigateur, puis première authentification.	Identifiants par défaut à changer immédiatement.

8.3 Ce que la procédure officielle ne traite pas

Le configurateur produit une installation fonctionnelle, pas une installation sécurisée ni recettée. Trois compléments sont systématiquement à prévoir :

• La sécurisation du SGBD : exécuter mariadb-secure-installation (ou l’équivalent PostgreSQL) immédiatement après l’installation du moteur, avant même de créer la base de Zabbix. Voir le tutoriel Installer MariaDB sur Debian.
• Le durcissement de la plateforme : chapitre 9.
• La recette : chapitre 10, qui atteste que l’installation est conforme et exploitable.

9. Politique de sécurité de la plateforme de supervision

Le serveur de supervision connaît la cartographie complète du système d’information et dispose d’un agent sur chaque machine critique. Il doit donc être protégé au niveau de l’actif le plus sensible qu’il supervise. Les mesures ci-dessous constituent la politique minimale à appliquer, et à consigner dans le dossier d’exploitation.

9.1 Durcir le système hôte

• Installation minimale : aucun service inutile, pas d’environnement graphique sur le serveur.
• Accès SSH par clé, authentification par mot de passe désactivée, connexion directe de root interdite (PermitRootLogin no).
• Élévation de privilèges par sudo, avec des comptes nominatifs : chaque commande d’administration reste attribuable.
• Mises à jour de sécurité appliquées régulièrement, idéalement automatisées pour les correctifs critiques.
• Synchronisation de l’horloge (NTP) : sans horodatage fiable, ni la corrélation d’événements ni l’analyse après incident ne sont exploitables.
• Surveillance du remplissage de la partition des journaux et de la base : un serveur de supervision qui sature ne supervise plus rien.

9.2 Protéger la base de données

• Script de sécurisation exécuté dès l’installation : mot de passe root, suppression du compte anonyme et de la base de test, interdiction de la connexion distante de root.
• Compte applicatif dédié, limité à la seule base zabbix, sans privilège global.
• Écoute restreinte à la boucle locale si le SGBD est hébergé sur la même machine ; liaison chiffrée TLS s’il est distant.
• Mot de passe robuste, stocké dans un gestionnaire de secrets, jamais dans un document partagé ni dans un compte rendu de TP.
• Droits du fichier de configuration du serveur restreints : propriétaire root, groupe zabbix, permissions 640.
• Sauvegarde quotidienne de la base et, au moins une fois par an, test de restauration effectif : une sauvegarde jamais restaurée n’est pas une sauvegarde.
• Rétention de l’historique et des tendances dimensionnée : conserver ce qui est utile, pas tout, afin de maîtriser la volumétrie et la durée de conservation des données.

9.3 Sécuriser l’interface web

• Publication en HTTPS exclusivement, avec un certificat valide et une redirection du port 80.
• Accès au frontend restreint au réseau d’administration : l’interface de supervision n’a rien à faire sur un réseau utilisateur, et encore moins sur Internet.
• Expiration automatique des sessions inactives et blocage temporaire du compte après plusieurs échecs d’authentification.
• Compte guest désactivé et aucune consultation anonyme possible.
• Authentification à deux facteurs (TOTP) pour les comptes d’administration, ou rattachement à l’annuaire de l’établissement (LDAP, SAML).

9.4 Gérer les comptes, les rôles et l’API

• Comptes nominatifs uniquement : le compte Admin partagé rend toute imputation impossible.
• Mot de passe par défaut changé dès la première connexion.
• Rôles construits selon le principe du moindre privilège : la plupart des utilisateurs n’ont besoin que d’un accès en lecture aux tableaux de bord de leur périmètre.
• Jetons d’API dédiés par usage (script de sauvegarde, outil de ticketing), avec une date d’expiration et des droits limités ; jamais le jeton d’un administrateur.
• Revue périodique des comptes : suppression à chaque départ, désactivation des comptes inutilisés.

9.5 Chiffrer et cloisonner les flux

• Chiffrement TLS systématique entre agents, proxies et serveur : par clé pré-partagée (PSK) sur un parc modeste, par certificats X.509 au-delà.
• Une clé PSK distincte par hôte, protégée en lecture (permissions 600) et renouvelée selon la politique de l’établissement.
• Restriction de l’agent aux seules adresses du serveur et du proxy (directives Server et ServerActive), doublée d’une règle de pare-feu local.
• Segmentation : VLAN d’administration dédié, proxy Zabbix pour les sites distants plutôt qu’une ouverture de flux de bout en bout.
• SNMPv3 avec authentification et chiffrement pour les matériels actifs ; communautés par défaut proscrites et accès limité par liste de contrôle.

9.6 Limiter les capacités offensives de la plateforme

Zabbix sait exécuter des commandes sur les hôtes supervisés. C’est une fonctionnalité utile, et une arme redoutable si le serveur est compromis.

• Exécution de commandes distantes désactivée tant qu’un besoin précis ne la justifie pas.
• Paramètres utilisateur non sécurisés interdits (UnsafeUserParameters=0) : sans cela, un paramètre peut être détourné pour exécuter une commande arbitraire.
• Restriction des clés autorisées côté agent (AllowKey / DenyKey), notamment pour interdire system.run.
• Scripts d’action versionnés, relus et stockés hors du répertoire modifiable par le compte de service.

9.7 Journaliser et superviser la supervision

• Journal d’audit du frontend activé : il conserve la trace de chaque modification de configuration et de chaque connexion.
• Journaux du serveur et des agents conservés et, si possible, exportés vers un collecteur externe : un attaquant qui compromet la machine efface les journaux locaux.
• Le serveur Zabbix se supervise lui-même : files d’attente, processus internes, espace disque, disponibilité de la base.
• Supervision de l’absence de données (nodata) sur les hôtes sensibles : un agent arrêté ne génère aucune alerte par lui-même.
• Export régulier de la configuration (modèles et hôtes au format YAML) conservé hors de la machine : c’est la sauvegarde de votre travail de paramétrage.

9.8 Maintenir la plateforme dans la durée

• Veille sur les vulnérabilités publiées concernant Zabbix, le SGBD, PHP et le serveur web.
• Plan de montée de version anticipé : ne pas rester sur une branche dont le support est terminé.
• Revue annuelle des seuils et des déclencheurs : un seuil jamais atteint ne sert à rien, un seuil atteint en permanence fabrique du bruit.
• Documentation tenue à jour : architecture, comptes, flux ouverts, procédure de restauration.

9.9 Récapitulatif

Domaine	Mesure minimale	Échéance
Système hôte	Installation minimale, SSH par clé, sudo nominatif, mises à jour de sécurité, NTP.	À l’installation, puis en continu
Base de données	Script de sécurisation, compte dédié, écoute locale, conf en 640, sauvegarde.	À l’installation
Frontend	HTTPS, accès restreint au réseau d’administration, guest désactivé, 2FA.	Avant mise en service
Comptes	Mot de passe par défaut changé, comptes nominatifs, rôles de moindre privilège.	Première connexion
Flux	TLS PSK ou certificats, Server= restreint, pare-feu, SNMPv3.	À chaque ajout d’hôte
Capacités	Commandes distantes et paramètres non sécurisés désactivés.	À l’installation
Traçabilité	Journal d’audit, export des journaux, auto-supervision, nodata.	Avant mise en service
Maintien	Veille CVE, montées de version, test de restauration, revue des seuils.	Trimestriel à annuel

10. Recette de l’installation

L’installation n’est terminée que lorsqu’elle est vérifiée. Les points suivants constituent la base du document de recettage attendu (voir la série Le recettage informatique).

Point de contrôle	Attendu
Services actifs	zabbix-server, zabbix-agent et le serveur web sont en état active (running) et activés au démarrage.
Journal du serveur	Aucune erreur de connexion à la base dans le journal du serveur Zabbix.
Interface web	Authentification réussie en HTTPS, avec un compte nominatif.
Mot de passe par défaut	Le mot de passe du compte Admin a été modifié et le compte guest est désactivé.
Hôte « Zabbix server »	Disponibilité de l’agent au vert dans Data collection → Hosts.
Collecte	Des valeurs remontent dans Monitoring → Latest data.
Chiffrement	La colonne de chiffrement affiche PSK ou CERT pour les hôtes concernés.
Droits du fichier de configuration	Permissions 640, propriétaire root, groupe zabbix.
Sauvegarde	Sauvegarde de la base planifiée et restauration testée.
Traçabilité	Journal d’audit accessible et alimenté.

11. À retenir

Sources de référence : zabbix.com/download — documentation Zabbix (FR) — Guide d’hygiène informatique de l’ANSSI, cyber.gouv.fr.