Construisez votre propre SOC Wazuh, ou déployez-en un déjà construit

Ce que vous devez construire

Un Wazuh standard vous donne un manager, un indexeur et un agent. Tout ce qui vient au-dessus constitue le projet : des managers et indexeurs par client, un plan de contrôle pour les provisionner, une isolation des tenants au niveau de la base de données, la politique réseau, la plomberie d'enrôlement des agents, un workflow de triage et l'outillage de mise à niveau. Chaque pièce est abordable prise isolément ; c'est leur intégration, et son maintien à mesure que les clients arrivent, qui absorbe les mois d'ingénierie. Ajoutez une couche de triage IA et vous êtes aussi responsable des prompts, de l'orchestration d'outils contre Wazuh et vos sources d'enrichissement, des garde-fous pour que le modèle ne puisse pas clôturer ce qu'il ne devrait pas, des budgets de tokens et d'un workflow de revue autour de tout cela.

SocTalk livre ces pièces assemblées : un plan de contrôle qui exécute des piles Wazuh par client dans des namespaces Kubernetes isolés, avec le pipeline de triage et la file de revue inclus. Un entonnoir déterministe de déduplication, de regroupement et de corrélation résout de nombreuses alertes avant tout appel de modèle, chaque escalade passe par une revue humaine sans mode d'approbation automatique, et le LLM reste votre choix par tenant, y compris un Ollama entièrement local. Tout est sous Apache 2.0, le chart cible un Kubernetes standard 1.30+, et une installation de production prend environ une heure sur un cluster préparé.

Isolation des tenants

La multi-tenance est la décision de conception à trancher tôt, et sur la voie DIY, c'est à vous de la prouver. Cela signifie des politiques de sécurité au niveau ligne sur chaque table liée à un tenant, l'identité du tenant propagée dans chaque requête et chaque tableau de bord, une politique réseau et des quotas de ressources par tenant, et une suite de tests démontrant que les requêtes inter-tenants échouent réellement. Les scripts de provisioning que vous écrivez pour le troisième client doivent encore fonctionner pour le trentième.

SocTalk applique FORCE ROW LEVEL SECURITY sur chaque table Postgres liée à un tenant, adossé à sept tests d'isolation dont la réussite est exigée en CI. Chaque client reçoit un manager et un indexeur Wazuh dédiés dans son propre namespace, avec Cilium NetworkPolicy, ResourceQuota et des secrets d'enrôlement d'agents limités au tenant. La pile est testée jusqu'à ~50 tenants sur un cluster de 3 nœuds ; prévoyez environ 6 à 8 GB de RAM et 1,5 vCPU par tenant persistant.

Onboarding et mises à niveau

Dans une pile maison, chaque nouveau client est un runbook : monter son instance Wazuh, câbler le DNS et les secrets d'enrôlement, construire ses tableaux de bord, et relier le tout à l'outillage central que vous avez écrit. Les mises à niveau se multiplient de la même façon. Les montées de version Wazuh multipliées par le nombre de clients, les migrations de schéma, la rotation des certificats et le cycle de vie Kubernetes représentent un temps d'ingénierie récurrent qui croît avec chaque tenant.

SocTalk réalise l'onboarding depuis le plan de contrôle. Le provisioning exécute neuf phases ordonnées avec reprise idempotente, en créant le namespace, les quotas, la pile Wazuh et le point d'enrôlement, et les agents s'enrôlent via un ingress routé par nom d'hôte avec des secrets limités au tenant. Le câblage DNS et load balancer par tenant reste manuel en V1, et un profil « provided » permet de connecter un Wazuh que vous exploitez déjà. Les deux charts se mettent à niveau via helm upgrade avec des migrations de base de données appliquées automatiquement, même si les mises à niveau à l'échelle du parc restent aujourd'hui une boucle manuelle documentée sur les namespaces des tenants ; une API de mise à niveau du parc figure sur la feuille de route, elle n'est pas livrée.

Ce que cela coûte

Les frais de licence sont nuls sur les deux voies. Wazuh est open source, et SocTalk est sous Apache 2.0, sans scission communauté/entreprise et sans fonctionnalités bridées. La différence tient à l'endroit où la dépense atterrit. Une construction DIY coûte des mois d'ingénierie au départ, plus le temps récurrent pour la maintenir en marche, un échange qui se défend si la plateforme est là où vous voulez mobiliser votre équipe. Avec SocTalk, vous payez votre propre infrastructure et les tokens LLM, de l'ordre de $9 par jour et par tenant à 30 alertes par jour sur une configuration économique, montant très variable, ou un coût par token nul avec Ollama en local.

Quand construire vous-même a du sens

SocTalk suppose un plan de données Wazuh. Son plan de données est aujourd'hui exclusivement Wazuh ; d'autres SIEM sont des ajouts envisageables à sa surface d'outils, mais aucun n'est livré. Une pratique centrée sur Splunk ou Elastic sera mieux servie par son propre travail d'intégration.

Construisez aussi si la plateforme SOC elle-même est votre différenciateur produit. Une logique de corrélation sur mesure, une expérience analyste propriétaire et des workflows que vos concurrents ne peuvent pas copier plaident tous pour posséder chaque couche, et une plateforme préconstruite vous gênerait plus qu'autre chose.

Si vous hésitez sincèrement, le code source est sur github.com/soctalk/soctalk sous Apache 2.0. Lisez les politiques RLS, le modèle réseau et le pipeline de triage avant de décider. Dans le pire des cas, vous repartez avec une architecture de référence fonctionnelle pour votre propre construction.

Ce que vous gardez dans les deux cas

SocTalk tourne sur votre propre Kubernetes, du serveur bare-metal à EKS, AKS ou GKE, en environnement air-gapped si nécessaire, avec le LLM de votre choix par tenant, y compris un modèle entièrement local. L'auto-hébergement est une constante des deux voies. Vous gardez votre infrastructure et vos données, et la relation client ne passe jamais par un éditeur.

C'est la pile DIY avec l'assemblage déjà fait, et la licence garantit le même plafond que si vous la construisiez vous-même : tout ce qui se trouve dans le dépôt est sous Apache 2.0, il n'y a pas de niveau entreprise gardé en réserve, et si vous êtes un jour en désaccord avec la direction du projet, vous pouvez le forker et continuer à opérer.