Détecter : SIEM et sécurité opérationnelle dans une architecture

40 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 12 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Un SIEM (Security Information and Event Management) centralise les journaux de sécurité de toute une architecture et les corrèle pour repérer un abus : une attaque, une fuite, un compte détourné. Il ne répond pas à la même question que la supervision, l'observabilité vue dans le module Plateforme, qui dit si le service fonctionne ; le SIEM dit si quelqu'un en abuse, ce qui peut arriver pendant que tout fonctionne parfaitement. Cette leçon apprend à lire le SIEM sur un schéma : ses sources, sa corrélation, l'intégrité de ses journaux, et ce que coûte sa panne.

Ce que vous allez apprendre

Distinguer la supervision, qui dit si le service fonctionne, du SIEM, qui dit si on en abuse
Citer les sources de journaux qui alimentent un SIEM
Expliquer ce qu'apporte la corrélation d'événements
Dire pourquoi les journaux de sécurité doivent échapper aux administrateurs de la production

Supervision ou SIEM : quelle différence ?

La supervision mesure si le service fonctionne, pour une équipe d'exploitation ; le SIEM cherche si on en abuse, pour une équipe de sécurité. Une attaque réussie est souvent invisible pour la supervision : un attaquant qui exporte la base des clients avec un compte volé fait des requêtes normales, la latence est bonne, aucun taux d'erreur ne monte. Seuls les journaux de sécurité, qui disent qui s'est connecté, d'où et pour faire quoi, le trahissent.

Le tableau oppose les deux familles sur ce qu'un schéma doit faire voir. Elles partagent souvent des briques de collecte, mais ni leurs questions, ni leurs destinataires, ni leurs durées de conservation ne sont les mêmes.

Critère	Supervision	SIEM
Question	le service fonctionne-t-il ?	quelqu'un en abuse-t-il ?
Signaux	métriques, journaux techniques, traces	journaux de sécurité et d'audit
Destinataire	astreinte d'exploitation	analyste de sécurité
Conservation	des semaines	des mois ou des années, souvent par obligation
Panne silencieuse	le service tombe sans alerte	une attaque passe inaperçue

Quels journaux alimentent un SIEM ?

Un SIEM reçoit les journaux qui racontent les accès et les actions sensibles : connexions, authentifications, changements de droits, flux refusés, actions d'administration. Les sources se lisent sur le schéma : le bastion et ses sessions, le fournisseur d'identité et ses connexions, le journal d'audit de l'application, le pare-feu, et les journaux d'audit du fournisseur cloud, qui disent qui a modifié quoi dans le compte.

Le schéma montre le SIEM de la boutique et ses quatre sources.

Un SIEM rapproche des journaux venus de briques différentes ; seule l'alerte corrélée atteint un humain. Source · SVG

Une source oubliée est un angle mort : un attaquant qui passe par la seule brique non raccordée n'apparaît nulle part. La question à poser devant chaque frontière de confiance du schéma est donc : ce qui la franchit laisse-t-il une trace dans le SIEM ?

Qu'apporte la corrélation ?

La corrélation rapproche des événements venus de briques différentes pour reconnaître un scénario qu'aucun d'eux ne révèle seul. Un échec de connexion n'est rien ; cinquante échecs suivis d'une réussite, depuis un pays où l'entreprise n'a personne, puis la création d'un compte d'administration dans la minute, racontent une attaque. Ces trois événements viennent du fournisseur d'identité, du bastion et de l'IAM : seul un système qui les voit ensemble les relie.

Le prix de la corrélation est le bruit. Des règles trop larges produisent des centaines d'alertes par jour, que plus personne ne lit, et la vraie attaque s'y perd. Un SIEM utile est réglé en continu par une équipe qui lit ses alertes : sans analyste, ce n'est qu'un entrepôt de journaux coûteux.

Pourquoi les journaux doivent-ils échapper aux administrateurs ?

Un attaquant qui obtient des droits d'administration efface d'abord les traces de son passage : des journaux qu'il peut modifier ne prouvent plus rien. C'est pourquoi les journaux de sécurité partent aussitôt de la machine qui les produit vers un SIEM que les administrateurs de la production ne gèrent pas, dans un autre domaine de confiance. Les journaux d'un bastion compromis gardés sur ce même bastion n'ont aucune valeur.

La même logique vaut pour la rétention. Une intrusion se découvre souvent des mois après le premier accès ; des journaux gardés deux semaines ne permettent plus de remonter jusqu'à elle. Les obligations légales fixent parfois cette durée, et les journaux, qui contiennent des données personnelles, se protègent en conséquence.

Que se passe-t-il quand le SIEM tombe ?

Quand le SIEM tombe, le service continue, mais plus aucune attaque n'est détectée, et une intrusion commencée pendant la panne passera inaperçue. C'est le même aveuglement que la panne de l'observabilité, avec un enjeu différent : ce n'est plus une panne qu'on ne voit pas, c'est un attaquant. Les agents de collecte gardent souvent les journaux en tampon pendant une courte panne ; au-delà, ils sont perdus.

Question de la grille	Ce qu'il faut regarder
État porté	des mois de journaux de sécurité, et les règles de corrélation
À sauvegarder	les règles et la configuration en code ; les journaux exigés comme preuve
S'il tombe	le service continue, les attaques passent inaperçues
Confiance	des journaux hors de portée des administrateurs de la production
Signal à surveiller	sources muettes, retard d'ingestion, volume anormal d'alertes

Une source muette est le premier signal à surveiller : un bastion qui n'envoie plus rien depuis une heure est en panne, ou a été réduit au silence. C'est la version sécurité du watchdog vu avec l'observabilité.

Ce que la détection change dans la boutique

La boutique envoie les journaux de son bastion, de son fournisseur d'identité, de son application et de son pare-feu vers un SIEM tenu par une autre équipe, et une alerte corrélée réveille un analyste. Sur la V5 du fil rouge, le SIEM est un cylindre en pointillé, alimenté par l'application et le bastion. Le tableau pose le compromis.

Ce qu'on gagne	Ce qu'on paie
des attaques visibles même quand le service va bien	une collecte à tenir depuis chaque source
des traces qu'un attaquant ne peut pas effacer	des mois de journaux à stocker et à protéger
une enquête possible des mois après	des règles à régler en continu contre le bruit

La responsabilité se partage par construction. L'équipe de la boutique choisit ce qu'elle journalise dans son application ; l'équipe de sécurité tient le SIEM, ses règles et sa lecture. Si personne ne lit les alertes la nuit, la boutique est surveillée en heures ouvrées seulement, et les attaquants le savent.

Qui prend le relais pour installer un SIEM ?

Cette leçon décrit le rôle architectural du SIEM ; son installation et le réglage de ses règles relèvent des guides spécialisés du site. Le guide Sécurité cloud situe le SIEM parmi les outils de surveillance ; Sécurité opérationnelle IAM montre quels événements d'identité y envoyer ; la section Sécurité réseau présente Wazuh. Le guide GitLab CI : audit et conformité fait remonter les événements d'audit d'une forge.

Pièges de lecture courants

Ces erreurs reviennent devant la détection d'une architecture, et elles viennent presque toutes d'une supervision prise pour une sécurité qu'elle n'apporte pas :

Croire que la supervision voit les attaques : un abus réussi ressemble à un trafic normal.
Garder les journaux de sécurité sur les machines qu'ils décrivent.
Oublier une source, comme le bastion ou l'audit du compte cloud.
Garder les journaux deux semaines alors qu'une intrusion se découvre en mois.
Installer un SIEM sans personne pour lire ses alertes.

À retenir

La supervision dit si le service fonctionne, le SIEM si on en abuse.
Un SIEM reçoit les journaux des frontières de confiance : bastion, identité, application, pare-feu, compte cloud.
La corrélation relie des événements qu'aucune brique ne voit seule.
Les journaux de sécurité échappent aux administrateurs de la production.
SIEM en panne : le service continue, les attaques passent inaperçues.
Une source muette se surveille comme un watchdog.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

6 min.

70% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin