SIEM Wazuh : un seul endroit pour voir ce qui s'est passé
Une détection centralisée pour trois clusters Kubernetes, les VM et le compte cloud, de l'architecture au SSO et au réglage du bruit.
Contexte
Les signaux de sécurité étaient éparpillés entre les clusters Kubernetes, quelques VM d’infrastructure et le compte du fournisseur cloud. Rien ne les corrélait, et personne ne pouvait répondre à « que s’est-il passé cette nuit ? » depuis un seul écran.
Ce que j’ai construit
- L’architecture d’abord : manager, indexer et dashboard sur une VM dédiée, déployés avec Terraform, les flux de logs conçus avant toute installation.
- Des agents en code : l’agent Wazuh packagé en chart Helm et déployé sur chaque nœud Kubernetes via ArgoCD, avec enrôlement automatisé. Les mises à jour des agents suivent les mêmes canaux de release que le reste de la plateforme.
- SSO : dashboard et indexer derrière le fournisseur d’identité interne (OIDC), l’application déclarée en Terraform et les rôles mappés depuis le fournisseur. Aucun compte local.
- Contenu de détection : corrélation des alertes Falco, brute force SSH, élévation de privilèges, accès root suspect ; détection de vulnérabilités, de malwares et flux de threat intelligence.
- Sources cloud : logs d’API du compte cloud et logs des bases managées, ingérés avec des décodeurs et règles sur mesure.
- Alerting : notifications Slack via l’API bot, alignées sur la configuration Alertmanager existante.
Dompter le bruit
Un SIEM que personne ne lit est pire que pas de SIEM. Une règle du compte cloud se déclenchait environ 474 000 fois par jour. J’ai remonté la source jusqu’à une clé d’API qui interrogeait les nodepools une fois par seconde, puis j’ai restructuré les règles :
- erreurs HTTP et refus IAM évalués en premier, et remontés ;
- lectures réussies rendues silencieuses ;
- appels modifiants (POST, PUT, DELETE, PATCH) gardés à un niveau visible ;
- ordre des règles corrigé selon la logique « first-match » de Wazuh entre règles sœurs.
La même approche a supprimé les alertes répétées dues aux timers système et aux health checks internes des bases managées.
Résultat
Un seul endroit pour regarder clusters, VM et compte cloud, avec des alertes qui valent la peine d’être lues. Les runbooks de réponse à incident et les dashboards de sécurité sont la prochaine étape.