SOC souverain hébergeur et datacenter : Wazuh 24/7 (2026)

Un hébergeur ou un opérateur de datacenter n'a pas le même problème de sécurité qu'une PME classique. Le volume de logs est sans commune mesure (équipements réseau, hyperviseurs, baies de stockage, systèmes invités, contrôleurs d'accès physique), l'infrastructure est elle-même critique pour des dizaines ou des centaines de clients hébergés, et la moindre panne de sécurité devient un sujet de confiance commerciale autant qu'un sujet technique. Ajoutez la directive NIS2, qui place les infrastructures numériques dans le secteur le plus surveillé, et la question n'est plus de savoir s'il faut un SOC, mais comment le construire sans dépendre d'une plateforme étrangère facturée au volume.

Cet article détaille l'architecture, la logique de détection et le modèle de run d'un SOC souverain bâti sur Wazuh, pensé spécifiquement pour un environnement d'hébergement ou de datacenter. Nous maillons ce contenu avec deux articles techniques déjà publiés : la couverture NIS2 par Wazuh et Suricata et le pipeline de pré-tri des alertes par IA, qui prend ici une importance particulière vu le volume en jeu.

#Pourquoi un hébergeur ou un datacenter ne peut plus se passer d'un SOC

#Une infrastructure critique par construction

Un datacenter n'héberge pas seulement ses propres systèmes : il porte la disponibilité, l'intégrité et la confidentialité des environnements de tous ses clients. Une intrusion sur le plan de gestion (hyperviseurs, baies SAN, contrôleurs réseau, outils d'administration à distance) a un rayon d'impact qui dépasse largement l'incident isolé. C'est ce qui distingue un SOC pour hébergeur d'un SOC pour PME classique : on ne surveille pas un parc d'endpoints, on surveille un plan de contrôle dont dépend la sécurité de tiers.

#NIS2 : les infrastructures numériques dans le secteur hautement critique

La directive NIS2 (UE 2022/2555) classe les infrastructures numériques (points d'échange internet, fournisseurs DNS, registres de noms de domaine, fournisseurs de cloud, data centers, réseaux de diffusion de contenu, réseaux et services de communications électroniques) dans son annexe I, celle des secteurs hautement critiques. Les opérateurs de datacenters de taille significative y relèvent généralement du statut d'entité essentielle, avec des obligations renforcées de gestion des risques, de détection, de notification d'incident et de supervision par la direction.

Côté calendrier français, la transposition a pris du retard. Le projet de loi relatif à la résilience des infrastructures critiques et au renforcement de la cybersécurité (qui transpose NIS2, mais aussi DORA et REC) a été adopté par le Sénat en mars 2025 et a terminé son examen en commission spéciale à l'Assemblée nationale en septembre 2025, mais son passage en séance publique a été reporté au-delà de l'été 2026, la Commission européenne ayant même saisi la Cour de justice de l'Union européenne début juillet 2026 contre la France pour ce retard. Cela ne dispense pour autant aucun hébergeur de se préparer : le texte fera de l'ANSSI l'autorité compétente, et les obligations de fond (gestion des risques, détection, notification sous 24 heures puis 72 heures, gouvernance) sont déjà connues via la directive elle-même.

#La confiance client comme actif commercial

Un client qui héberge sa production, ses sauvegardes ou son PRA chez un tiers demande de plus en plus souvent des preuves concrètes de supervision de sécurité, pas seulement une clause contractuelle. Pouvoir démontrer un SOC actif, avec traçabilité des détections et des réponses, devient un argument commercial autant qu'une obligation réglementaire.

#Un volume de logs d'un autre ordre

Entre les switches et firewalls, les hyperviseurs, les systèmes des baies hébergées, l'Active Directory ou l'annuaire cloud, les onduleurs et systèmes de contrôle d'accès physique, et les API de gestion, le volume d'événements généré par un datacenter est structurellement bien supérieur à celui d'une PME. C'est précisément ce qui rend un SIEM facturé au volume, ou une équipe d'analystes qui trie tout à la main, intenables sur la durée.

#Pourquoi souverain, et pourquoi open source

#Les logs de sécurité sont eux-mêmes une donnée sensible

Les logs d'un datacenter révèlent l'architecture du plan de contrôle, les comptes à privilèges, la cartographie réseau, parfois des informations sur les clients hébergés. Faire transiter cette donnée par une plateforme SaaS étrangère pose un problème de souveraineté que beaucoup d'hébergeurs ne peuvent tout simplement pas accepter, pour eux-mêmes comme pour leurs propres clients.

#Le problème du SIEM propriétaire facturé au volume

Les SIEM propriétaires classiques facturent à l'ingestion (Go/jour) ou à l'événement par seconde. Sur le volume d'un datacenter, la facture grimpe vite et devient un frein direct à la couverture : on finit par exclure des sources de logs pour tenir le budget, ce qui est l'inverse de ce que demande NIS2. Wazuh, sous licence open source, ne facture pas au volume : le coût devient celui de l'infrastructure de stockage et de calcul, dimensionnée une fois pour toutes.

#Wazuh self-hosted, sur l'infrastructure de l'hébergeur lui-même

Dernier point, spécifique au métier : un hébergeur ou un opérateur de datacenter a, par définition, l'infrastructure pour héberger lui-même sa stack de sécurité. Le manager Wazuh et l'indexer tournent sur ses propres serveurs, dans un environnement qu'il maîtrise entièrement. Aucune donnée de sécurité ne sort du périmètre France, aucune dépendance à une plateforme tierce soumise à un droit extraterritorial.

#Architecture Wazuh pour un environnement de datacenter

#Les composants

Un déploiement Wazuh repose sur trois briques : le manager, qui collecte, décode et corrèle les événements remontés par les agents et les sources syslog ; l'indexer, bâti sur OpenSearch, qui stocke et indexe les alertes ; et le dashboard, qui expose la recherche et les visualisations. Sur la version actuelle (la branche 4.14, dont la 4.14.6 est sortie début juillet 2026), l'ensemble reste 100 % open source et auditable ligne par ligne, ce qui compte pour un opérateur tenu à une obligation de transparence sur ses contrôles.

#Dimensionner au volume : cluster multi-noeuds

Contrairement à une PME de quelques dizaines de postes, un datacenter justifie presque toujours un cluster Wazuh multi-noeuds : plusieurs managers en charge répartie, un indexer OpenSearch en cluster avec réplication des shards, et une rétention à plusieurs niveaux (index chauds pour l'investigation immédiate, tièdes pour le hunting, archivage froid pour la conformité). C'est un dimensionnement d'ingénierie, à faire au cas par cas, pas une configuration par défaut.

#Les sources de logs à couvrir

• Agents Wazuh sur les systèmes d'exploitation gérés (hyperviseurs, serveurs d'administration, jump servers).
• Syslog réseau pour les switches, routeurs et firewalls, dont les journaux de connexion et de configuration sont souvent la première trace d'un mouvement latéral.
• Hyperviseurs et plans de gestion cloud/virtualisation, où une compromission a le rayon d'impact le plus large.
• Annuaire (Active Directory ou équivalent cloud/Entra) pour la détection des élévations de privilèges et des comptes à risque.
• Contrôle d'accès physique (badges, vidéosurveillance, environnement technique) quand ces systèmes exposent des journaux exploitables : dans un datacenter, la sécurité physique et la cybersécurité se recoupent.

#Suricata en complément réseau

Sur le plan réseau, Wazuh se combine avec Suricata en IDS/IPS pour l'analyse du trafic en temps réel, comme détaillé dans notre article sur la conformité NIS2 avec Wazuh et Suricata. Pour un datacenter, ce couple se positionne aux points d'interconnexion et sur les segments les plus sensibles (plan de gestion, interconnexions réseau internes), sans dupliquer la charge sur l'ensemble du trafic client.

#Détection : MITRE ATT&CK, Sigma, et une couche d'IA souveraine

#Un socle de règles explicable

La détection s'appuie sur un noyau de règles mappées au référentiel MITRE ATT&CK et sur des règles au format Sigma, converties pour Wazuh. C'est un choix déterminant pour un opérateur soumis à NIS2 et à ISO 27001 : chaque alerte est traçable jusqu'à une technique documentée, ce qui permet de justifier la couverture de détection devant un auditeur, à l'inverse d'un moteur de scoring propriétaire dont la logique reste opaque. Nous détaillons cette mécanique, avec des exemples concrets de règles, dans notre article sur la détection MITRE ATT&CK avec Wazuh et Sigma.

#Pourquoi une IA souveraine, et seulement pour trier les alertes

Sur le volume d'un datacenter, aucune équipe humaine ne peut trier manuellement l'intégralité des alertes générées par un socle de règles volontairement large. C'est là qu'intervient une couche d'intelligence artificielle, mais avec une règle non négociable : le modèle ne voit jamais les logs bruts, il ne traite que les alertes déjà qualifiées par Wazuh. Un modèle de langage souverain, hébergé en France (voire en local sur l'infrastructure du client), reçoit uniquement l'alerte structurée (identifiant de règle, description, agent, données de contexte) et la classe du bruit connu à l'incident probable. Les règles de niveau critique contournent systématiquement le pré-tri et remontent directement à l'humain. Le mécanisme complet, avec le pipeline et les pièges à éviter (dérive du modèle, faux négatifs, injection de prompt via les logs), est détaillé dans notre article sur le tri des faux positifs SIEM par IA.

Cette séparation stricte entre les logs bruts (qui restent dans l'indexer Wazuh, sur l'infrastructure souveraine) et les alertes (seules à transiter par la couche IA) est ce qui rend l'ensemble cohérent avec une exigence de souveraineté : le volume brut ne quitte jamais le périmètre maîtrisé, seule une alerte déjà résumée et anonymisable est traitée par le modèle.

#Le 24/7 : build chez le client, run à distance sécurisé

#Phase 1, le build et la détection de premier niveau

La première phase consiste à déployer les agents, connecter les sources syslog, écrire le socle de règles mappées MITRE ATT&CK, dimensionner le cluster et mettre en place le pré-tri IA. C'est un travail d'ingénierie de détection, réalisé chez le client.

#Phase 2, la réponse et le threat hunting

Une fois le socle stabilisé, le run s'organise en niveaux : un premier niveau qualifie les alertes remontées par le pré-tri, un second prend en charge l'investigation et la réponse aux incidents avérés, et une activité de threat hunting régulière recherche des signaux faibles qui n'ont pas déclenché de règle. Pour un hébergeur, cette chasse porte en priorité sur le plan de gestion et les comptes à privilèges, la cible la plus rentable pour un attaquant.

#Un accès distant maîtrisé de bout en bout

Le run 24/7 se fait à distance, ce qui pose légitimement une question de confiance pour un opérateur d'infrastructure critique. La réponse est un accès encadré : bastion dédié, authentification multifacteur, sessions enregistrées et traçables, et périmètre d'accès limité strictement à la stack de sécurité, jamais aux systèmes de production des clients hébergés. Cette traçabilité de l'accès fait elle-même partie des preuves de conformité attendues par NIS2 et par ISO 27001.

#Ce que couvre un SOC managé, au-delà du tri des alertes

Un SOC ne se résume pas à trier des notifications. Sur un périmètre de datacenter, les missions couvrent :

• La détection, via le socle de règles MITRE ATT&CK et Sigma, actualisé en continu.
• L'investigation, quand une alerte de niveau 2 ou 3 nécessite une analyse approfondie.
• La réponse, avec des playbooks de confinement adaptés à un environnement multi-tenant, où une remédiation ne doit jamais impacter un client tiers par erreur.
• Le threat hunting, une recherche proactive de compromissions non détectées par les règles existantes.
• L'ingénierie de détection, l'écriture et l'ajustement continu des règles à mesure que l'infrastructure évolue.
• Le reporting de conformité, pour NIS2 comme pour ISO 27001, avec des preuves exploitables par un auditeur.

#FAQ

Un hébergeur peut-il héberger lui-même son SOC ? Oui, c'est même l'intérêt principal de l'approche : le manager et l'indexer Wazuh tournent sur l'infrastructure de l'hébergeur, qui garde la maîtrise complète de ses données de sécurité. Le run (supervision 24/7, réponse aux incidents) est assuré à distance via un accès encadré.

Wazuh tient-il la charge d'un datacenter ? Oui, à condition de dimensionner correctement l'architecture : cluster de managers, indexer OpenSearch en cluster avec réplication, rétention à plusieurs niveaux. Ce n'est pas une configuration par défaut, c'est un travail d'ingénierie fait sur mesure selon le volume réel du site.

Est-ce compatible avec NIS2 et ISO 27001 ? Oui, c'est même l'un des intérêts d'un socle basé sur MITRE ATT&CK et Sigma : la couverture est documentée et traçable, ce qui facilite la preuve de conformité attendue par NIS2 (détection, notification d'incident) et par ISO 27001 (contrôle A.8.16 sur la surveillance des activités).

L'intelligence artificielle a-t-elle accès aux logs bruts des clients hébergés ? Non. Le modèle ne traite que les alertes déjà générées par Wazuh, jamais les logs bruts. Les alertes critiques contournent systématiquement le pré-tri IA et remontent directement à un analyste humain.

Les équipements physiques (onduleurs, contrôle d'accès, climatisation) sont-ils couverts ? Quand ces équipements exposent des journaux exploitables, ils peuvent être intégrés via syslog au même titre que les équipements réseau. Dans un datacenter, la frontière entre sécurité physique et cybersécurité est poreuse : une intrusion sur le contrôle d'accès est un vecteur d'attaque à part entière.

Combien de temps pour déployer un SOC souverain sur un datacenter existant ? Le calendrier dépend du nombre de sources à intégrer et du niveau de maturité de la supervision déjà en place. La phase de build est systématiquement réalisée et validée avant le passage en run 24/7.

#En synthèse

Un hébergeur ou un opérateur de datacenter cumule les raisons d'investir dans un SOC : infrastructure critique par nature, classification NIS2 en annexe I, volume de logs hors norme, et exigence de confiance de la part de ses propres clients. Un socle Wazuh, complété par Suricata sur le réseau et une couche d'IA souveraine cantonnée au tri des alertes, permet de construire cette supervision sans faire sortir la moindre donnée de sécurité vers une plateforme tierce, et sans subir une facturation qui explose avec le volume.

M-KIS conçoit et opère ce type de SOC managé open source pour des infrastructures critiques, avec un socle de détection mappé MITRE ATT&CK, un run 24/7 à accès tracé, et un accompagnement dédié sur la conformité NIS2 et ISO 27001. Pour aller plus loin : notre offre de SOC managé et notre accompagnement conformité NIS2.

Équipe M-KIS, ESN souveraine basée à Nancy, Grand Est, spécialiste SOC managé open source, ISO 27001 et NIS2.