Les PME françaises font face à un double défi : garantir la disponibilité de leurs services tout en maîtrisant leurs coûts et leur souveraineté numérique. Face à la complexité croissante des infrastructures IT et à la multiplication des cybermenaces, les solutions propriétaires type Splunk ou Datadog deviennent financièrement et techniquement inaccessibles. L’alternative open source, combinée à des pratiques d’infrastructure-as-code (IaC), offre une réponse adaptée aux contraintes des PME. Cet article détaille comment déployer un monitoring souverain avec Wazuh et Suricata, sécuriser ses sauvegardes via la règle 3-2-1, et industrialiser ses infrastructures avec Ansible et Terraform — le tout en respectant un budget maîtrisé et une approche 100 % open source.
#1. Monitoring souverain : Wazuh et Suricata pour une détection proactive
#1.1 Wazuh : un SIEM open source adapté aux PME
Wazuh est une plateforme open source de détection des menaces et de réponse aux incidents (XDR/SIEM). Elle collecte et analyse les logs des endpoints, serveurs, conteneurs et workloads cloud pour identifier vulnérabilités, malconfigurations et comportements suspects. Son architecture modulaire permet une intégration progressive, essentielle pour les PME aux ressources limitées.
Fonctionnalités clés pour les PME :
- Collecte centralisée : logs système (auth, syslog), applications (Apache, Nginx, PostgreSQL), et événements de sécurité (fail2ban, OSSEC).
- Analyse comportementale : détection d’anomalies via des règles personnalisables (ex : tentatives de brute-force, élévations de privilèges).
- Intégrations natives : VirusTotal pour l’analyse des fichiers suspects, TheHive pour la gestion des incidents, et compatibilité avec des outils comme PagerDuty.
- Conformité : modules prédéfinis pour les standards NIST, PCI DSS, ou ISO 27001 — utile pour les PME soumises à des obligations réglementaires (ex : NIS2).
Exemple de déploiement minimal :
# Installation de l'agent Wazuh sur un serveur Linux (Debian/Ubuntu)
# apt-key est déprécié depuis Debian 11 / Ubuntu 22.04 — on stocke la clé GPG dans /etc/apt/keyrings/
# et on référence le keyring via l'option signed-by dans le fichier de dépôt.
sudo install -d -m 0755 /etc/apt/keyrings
curl -fsSL https://packages.wazuh.com/key/GPG-KEY-WAZUH \
| sudo gpg --dearmor -o /etc/apt/keyrings/wazuh.gpg
echo "deb [signed-by=/etc/apt/keyrings/wazuh.gpg] https://packages.wazuh.com/4.x/apt/ stable main" \
| sudo tee /etc/apt/sources.list.d/wazuh.list
sudo apt-get update && sudo apt-get install -y wazuh-agent
#1.2 Suricata : un IDS/IPS complémentaire
Suricata est un moteur open source de détection et prévention d’intrusions (IDS/IPS) basé sur des règles. Il analyse le trafic réseau en temps réel pour bloquer les attaques connues (ex : exploits, malwares, scans réseau).
Pourquoi l’associer à Wazuh ?
- Wazuh se concentre sur les endpoints (logs, fichiers, processus).
- Suricata surveille le réseau (paquets, flux, signatures d’attaques).
- Ensemble, ils couvrent les vecteurs d’attaque principaux des PME : compromission de postes, mouvements latéraux, exfiltration de données.
Configuration de base :
# Installation Suricata 7 (Debian/Ubuntu)
sudo add-apt-repository ppa:oisf/suricata-stable
sudo apt-get update && sudo apt-get install -y suricata
# Récupération et mise à jour des règles (Emerging Threats Open par défaut)
# suricata-update est livré nativement avec Suricata, on ne télécharge plus les règles à la main.
sudo suricata-update update-sources
sudo suricata-update
sudo systemctl restart suricata
Intégration Wazuh-Suricata :
L'architecture recommandée est la plus simple : Suricata écrit ses alertes dans eve.json, et l'agent Wazuh installé sur la même machine surveille ce fichier en tant que log source. La corrélation est ensuite faite côté manager Wazuh.
# /etc/suricata/suricata.yaml — sortie eve.json lue par l'agent Wazuh
outputs:
- fast:
enabled: yes
filename: fast.log
- eve-log:
enabled: yes
filetype: regular
filename: /var/log/suricata/eve.json
types:
- alert
- http
- dns
- tls
- flow
<!-- /var/ossec/etc/ossec.conf — déclaration côté agent Wazuh -->
<localfile>
<log_format>json</log_format>
<location>/var/log/suricata/eve.json</location>
</localfile>
syslog au même niveau qu'eve-log — ne pas imbriquer un bloc syslog à l'intérieur d'un eve-log typé file, Suricata refusera la configuration.
#2. Sauvegardes souveraines : la règle 3-2-1 adaptée aux PME
La règle 3-2-1 est un standard de sauvegarde conçu pour résister aux pannes matérielles, erreurs humaines et cyberattaques (ransomware, suppression malveillante).
#2.1 Principes de la règle 3-2-1
- 3 copies : 1 originale + 2 sauvegardes.
- 2 supports différents : ex : disque dur local + NAS, ou NAS + bande (pour les données critiques).
- 1 copie hors site : cloud souverain (ex : OVH, Scaleway) ou datacenter physique distant.
Pour les PME, une implémentation réaliste :
| Type de donnée | Support 1 | Support 2 | Hors site |
|---|---|---|---|
| Bases de données | Disque SSD local | NAS Synology | Cloud Scaleway (S3) |
| Fichiers utilisateurs | NAS | Disque USB chiffré | Backup chiffré (Restic) |
| Configurations | Git (auto-hébergé) | - | Dépôt Git distant |
#2.2 Outils open source pour automatiser les sauvegardes
- Restic : outil de backup chiffré, incrémental, compatible avec de nombreux backends (SFTP, S3, local). Idéal pour les sauvegardes hors site.
# Exemple de sauvegarde Restic vers un bucket S3 (Scaleway) # Le protocole https:// dans l'URL est obligatoire — sans lui, restic init échoue. export AWS_ACCESS_KEY_ID="votre_cle" export AWS_SECRET_ACCESS_KEY="votre_secret" restic -r s3:https://s3.fr-par.scw.cloud/votre-bucket init restic -r s3:https://s3.fr-par.scw.cloud/votre-bucket backup /chemin/à/sauvegarder - BorgBackup : alternative à Restic, avec déduplication et compression.
- Duplicati : interface graphique pour les PME moins techniques, compatible avec les protocoles standards.
#3. Infrastructure-as-Code (IaC) : Ansible et Terraform pour les PME
L’IaC permet de décrire et provisionner les infrastructures via du code, garantissant reproductibilité, traçabilité et souveraineté.
#3.1 Ansible : l’automatisation sans agent
Ansible est un outil d’automatisation simple, basé sur YAML, qui ne nécessite pas d’agent sur les machines cibles. Idéal pour :
- La configuration des serveurs (ex : déploiement de Wazuh, Suricata).
- La gestion des mises à jour de sécurité.
- L’orchestration de tâches répétitives (ex : rotation des logs).
Exemple de playbook Ansible pour déployer Wazuh :
---
- name: Déploiement de l'agent Wazuh
hosts: serveurs_production
become: yes
tasks:
- name: Ajout du dépôt Wazuh
apt_repository:
repo: "deb https://packages.wazuh.com/4.x/apt/ stable main"
state: present
- name: Installation de l'agent
apt:
name: wazuh-agent
state: present
- name: Configuration de l'agent (enregistrement vers le serveur Wazuh)
lineinfile:
path: /var/ossec/etc/ossec.conf
regexp: '<address>MANAGER_IP</address>'
line: '<address>192.168.1.100</address>'
notify: Redémarrer Wazuh
handlers:
- name: Redémarrer Wazuh
service:
name: wazuh-agent
state: restarted
#3.2 Terraform : le provisionnement multi-cloud
Terraform permet de décrire l’infrastructure (VMs, réseaux, stockages) dans des fichiers .tf, puis de l’appliquer sur différents providers (OVH, AWS, Azure, Proxmox).
Cas d’usage pour une PME :
- Déploiement d’un serveur Wazuh sur une VM OVH.
- Création automatisée de buckets S3 pour les sauvegardes.
- Gestion des règles de sécurité réseau (firewalls).
Exemple Terraform pour un bucket S3 (Scaleway) :
terraform {
required_providers {
scaleway = {
source = "scaleway/scaleway"
version = "~> 2.40"
}
}
}
provider "scaleway" {
zone = "fr-par-1"
region = "fr-par"
access_key = var.scaleway_access_key
secret_key = var.scaleway_secret_key
}
# Bucket Object Storage — préfixe officiel : scaleway_*, pas scw_*
resource "scaleway_object_bucket" "backup_bucket" {
name = "pme-backup-2026"
region = "fr-par"
}
# Versioning : ressource dédiée depuis la v2.x du provider Scaleway
# (l'argument `versioning = true` directement dans le bucket est déprécié).
resource "scaleway_object_bucket_versioning" "backup_bucket" {
bucket = scaleway_object_bucket.backup_bucket.id
versioning_configuration {
status = "Enabled"
}
}
# ACL gérée séparément de la ressource bucket depuis la v2.x.
resource "scaleway_object_bucket_acl" "backup_bucket" {
bucket = scaleway_object_bucket.backup_bucket.id
acl = "private"
}
#4. Coûts et ROI pour une PME
| Solution | Coût estimé (annuel) | Avantages |
|---|---|---|
| Wazuh + Suricata | 0 € (open source) | Détection proactive, conformité NIS2/ISO 27001 |
| Restic + S3 souverain | 300-600 € (stockage) | Sauvegardes chiffrées, résilientes |
| Ansible/Terraform | 0 € (open source) | Automatisation, reproductibilité |
| Infogérance M-KIS | À partir de 1 500 €/mois | SOC managé 100 % open source (Wazuh, TheHive) |
Comparaison avec les solutions propriétaires :
- Un SIEM comme Splunk coûte 50 000 €/an pour 100 Go/jour (source : tarifs publics 2025).
- Les solutions SaaS type Datadog ou Vanta impliquent des coûts récurrents élevés et une dépendance au Cloud Act.
#5. Conclusion : une approche souveraine et scalable
Les PME peuvent construire une infrastructure résiliente et conforme sans dépendre de solutions propriétaires coûteuses. En combinant :
- Wazuh + Suricata pour le monitoring et la détection,
- Restic + règle 3-2-1 pour les sauvegardes,
- Ansible + Terraform pour l’automatisation,
elles gagnent en souveraineté, maîtrisent leurs coûts et se préparent aux obligations réglementaires (NIS2, RGPD).
Pour les équipes internes en sous-effectif, des prestataires comme M-KIS proposent des offres d’infogérance 100 % open source, avec un SOC managé basé sur ces mêmes outils.
Ressources utiles :
- Documentation Wazuh : wazuh.com/documentation
- Règles Suricata Emerging Threats : rules.emergingthreats.net
- Guide Ansible pour débutants : docs.ansible.com
Équipe M-KIS — Cabinet Lead Auditor ISO 27001 certifié
Cet article vous parle ?
On accompagne PME, ESN et éditeurs SaaS dans leur conformité ISO 27001 / NIS2 — Lead Auditor certifié, tarifs publics, 100 % open source.