Guide complet pour sécuriser votre ERP/CRMopen‑source et respecter les exigences réglementaires.
1. Introduction Dolibarr est une solution ERP/CRM gratuite et open‑source très populaire auprès des PME et des associations. Sa modularité et son architecture légère en font un outil idéal pour gérer la comptabilité, la gestion des stocks, la facturation ou encore la relation client.
Cependant, comme tout logiciel kritiquement intégré aux processus métiers, Dolibarr doit être protégé contre les menaces internes et externes et rester conforme aux exigences légales (RGPD, ISO 27001, PCI‑DSS, etc.).
Cet article propose une vue d’ensemble :
- Les principes de base d’une stratégie de sécurité adaptée à Dolibarr.
- Les mécanismes de monitoring (logs, alertes, audits).
- La mise en œuvre d’une politique de conformité (RGPD, normes, etc.).
- Les bonnes pratiques d’hardening, de sauvegarde et de continuité d’activité. > Objectif : fournir aux administrateurs, DSI et DPO une feuille de route concrète pour transformer Dolibarr en système sécurisé, audit‑able et conforme.
2. Principes fondamentaux d’une stratégie de sécurité Dolibarr
| Principe | Description | Application concrète |
|---|---|---|
| Défense en profondeur | plusieurs couches de contrôles (réseau, serveur, application) | Pare‑feu, SELinux/AppArmor, contraintes d’accès Web, validation des entrées. |
| Principe du moindre privilège | chaque acteur (utilisateur, service) ne reçoit que les droits strictement nécessaires | Création de rôles granulaires dans Dolibarr, comptes système limitées. |
| Segregation des duties (SoD) | séparer les fonctions critiques (ex. : validation de paiement vs. saisie) | Utilisation de profils “Comptabilité”, “Gestion des stocks” avec droits différents. |
| Surveillance continue | collecter, centraliser et analyser les événements de sécurité | Logs Dolibarr + serveur Web + OS, agrégateurs (ELK, Graylog). |
| Gestion du risque | identifier, évaluer et prioriser les vulnérabilités | Cartographie desprocessus, matrice de risques, plan d’action. |
| Conformité | aligner les pratiques sur les exigences légales et normatives | RGPD, ISO 27001, PCI‑DSS, NIS2, etc. |
3. Monitoring de Dolibarr : quels éléments surveiller ?
3.1. Logs applicatifs
| Type de log | Contenu clé | Où le récupérer |
|---|---|---|
| accès Web | IP source, URL demandée, code HTTP, référent | access.log d’Apache/Nginx |
| erreurs PHP | Niveau d’erreur, message, trace de pile | error.log |
| gestion des utilisateurs | Connexion/déconnexion, changements de rôle | Tables User, UserGroups (dans la DB) |
| impacts business | Création/modification/suppression d’enregistrements (clients, factures, stocks) | Triggers ou audit plugin |
Conseil : activez le mode
'log_errors' => 1et configurezerror_logvers un fichier dédié.
3.2. Surveillance du serveur
- CPU / Mémoire / I/O : surcharge peut indiquer une attaque DoS ou un processus défectueux.
- Réseau : trafic entrant/sortant inhabituel, connexions sortantes vers des IPs blacklistées.
- Système de fichiers : modifications de fichiers critiques (
/etc/dolibarr/*,persistence/*).
Outils recommandés :
htop,iostat,iftop,netstatou intégration à un exporter Prometheus.
3.3. Monitoring des dépendances
| Composant | Pourquoi le surveiller ? | Action |
|---|---|---|
| PHP | Vulnérabilités (ex. : CVE‑2024‑XXXXX) | Mettre à jour le runtime et activer opcache en mode « preload ». |
| Base de données (MySQL / PostgreSQL) | Injection SQL, fuite de données | Activer log_statement et contrôler les droits d’accès. |
| Extensions (ex. : GD, SOAP) | Peuvent exposer des vecteurs d’attaque | Désactiver les extensions inutiles. |
3.4. Alertes & automation
- Seuils dynamiques : > 5 tentatives d’échec d’authentification en 5 min → alerte.
- Scénario de fuite : export massif de données ( > 10 000 lignes) → notification.
- Réponse automatisée : script qui désactive temporairement le compte suspect ou bascule vers un serveur de secours.
Exemple d’alert (via Zabbix) :
Trigger: "Dolibarr - Nombre de login échoué > 5 sur 5 min"
Severity: HighAction: Send email to DPO & SysAdmin, execute script /usr/local/bin/dolibarr_block_ip.sh
4. Conformité et exigences réglementaires
4.1. RGPD (protection des données à caractère personnel) | Exigence | Implication sur Dolibarr | Mesure corrective |
|———-|————————–|——————-|
| Principe de minimisation | Limiter les champs personnels stockés (ex. : ne pas conserver les numéros de sécurité sociale inutilement) | Masquage / chiffrement des champs sensibles (module “Encryption”). |
| Droit d’accès, de rectification, d’effacement | Possibilité d’exporter ou de supprimer les enregistrements d’un client | Implémenter des scripts d’effacement sécurisé (e.g., dolibarr_export.php avec token). |
| Registre des traitements | Documenter les traitements liés à la comptabilité, à la facturation, etc. | Utiliser le module “Audits” pour générer les rapports de traitement. |
| Notification des violations | Détecter toute fuite de données (ex. : export CSV non autorisé) | Configurer un webhook qui notifie le DPO dès qu’un export > seuil est initié. |
4.2. ISO 27001 – Système de management de la sécurité de l’information (SMSI)
| Clause | Application dans Dolibarr | Action concrète |
|---|---|---|
| A.9 – Gestion des accès | Contrôle d’accès fonctionnel (profil « Admin », « Editor », « Viewer ») | Mapping des rôles Dolibarr → droits ISO 27001. |
| A.12 – Opérations de sécurité | Journalisation, sauvegarde, tests d’intrusion | Mettre en place un planning de backup quotidien + test de restauration trimestriel. |
| A.18 – Conformité | Respect des législations (RGPD, fiscalité) | Audits internes semi‑annuels, mise à jour du tableau de conformité. |
4.3. PCI‑DSS (si vous traitez des cartes bancaires)
- Dolibarr ne gère pas directement les paiements ; toutefois, le module “Bank” stocke les _numéros de carte ou les tokens.
- Si vous activez le stockage d’informations de carte, vous devez :
- Chiffrer les données au repos (AES‑256).
- Ne conserver que le token et la date d’expiration.
- Limiter l’accès aux seules personnes « Finance ».
- Réaliser un Self‑Assessment Questionnaire (SAQ) adapté.
5. Hardening (renforcement) de Dolibarr
| Étape | Action | Commande / Exemple |
|---|---|---|
| 1️⃣ Désactiver les modules inutiles | Les modules additionnels (ex. : talist, mettys) créent des surfaces d’attaque. |
Supprimer le répertoire du module ou désactiver via $_CONFIG['dolibarr_main_extra']. |
| 2️⃣ Restreindre l’accès à l’interface d’administration | Bloquer accès à admin.php depuis Internet. |
.htaccess : Allow from 10.0.0.0/24 |
| 3️⃣ Chiffrer le trafic | Utiliser HTTPS avec certificat valide (Let’s Encrypt). | RewriteEngine On + SSLEngine on + SSLCertificateFile /etc/letsencrypt/live/mondomain/fullchain.pem |
| 4️⃣ Configurer les en-têtes de sécurité | X-Content-Type-Options, X-Frame-Options, Content-Security-Policy. |
add_header X-Content-Type-Options nosniff; |
| 5️⃣ Activer le sandbox PHP | open_basedir pour limiter l’accès aux répertoires du système de fichiers. |
open_basedir;/var/www/dolibarr/:/tmp/ |
| 6️⃣ Sécuriser la base de données | Utiliser un compte dédié avec privilèges limités (SELECT/INSERT/UPDATE uniquement). | GRANT SELECT,INSERT,UPDATE ON dolibarr.* TO 'dolibarr_user'@'localhost' IDENTIFIED BY '********'; |
| 7️⃣ Désactiver le debug mode en production | error_reporting(0) et display_errors=off. |
Modifier php.ini ou .user.ini. |
| 8️⃣ Mettre en place des sauvegardes | Backup quotidien des fichiers et de la base, rétention 30 jours, test de restauration. | mysqldump -u dolibarr_user -p dolibarr > /backups/dolibarr_$(date +%F).sql |
6. Plan d’audit et de revue continue
| Période | Activité | Livrable |
|---|---|---|
| Mensuel | Revue des logs (access, error) et des alertes | Rapport d’anomalies + actions correctives. |
| Trimestriel | Test d’intrusion interne (scan de vulnérabilités) | Rapport de pénétration + recommandations. |
| Semestriel | Audit de conformité (RGPD, ISO 27001) | Tableau de non‑conformité, plan d’amélioration. |
| Annuel | Vérification des versions (PHP, DB, Dolibarr) et mise à jour majeure | Plan de migration, documentation des changements. |
Outils d’audit :
- OpenVAS ou Nessus pour le scan de vulnérabilités.
- Osquery pour interroger l’état du serveur (packages, fichiers, processus).
- Dolibarr Audit Module (ou plugin
auditlog) pour suivre les changements critiques.
7. Exemple de mise en œuvre concrète (workflow)
« `mermaidflowchart TD
A[Etat initial] –> B[Installation sécurisée (HTTPS, permissions 0750)]
B –> C[Configuration du pare‑feu (ports 80/443 uniquement)]
C –> D[Activation des logs détaillés (access, error)]
D –> E[Centralisation des logs (ELK)]
E –> F[Création de règles d’alerte (login échoué >5/5min)]
F –> G[Déclenchement d’un script de blocage IP]
G –> H[Sauvegarde quotidienne + test de restauration]
H –> I[Revue mensuelle du registre RGPD]
I –> J[Mise à jour régulière (PHP, DB, Dolibarr)]
J –> K[Fin du cycle (continuité)]
---
## 8. Checklist de conformité rapide (à cocher)
| ✅ | Action | Commentaire |
|----|--------|-------------|
| 1 | **HTTPS** activé avec certificat valide | Vérifier l’accès via `https://` uniquement. |
| 2 | **Journalisation** des accès et modifications | Activer `log_errors` et configurer rotation des fichiers. |
| 3 | **Rôles clairement définis** (admin, compta, stock) | Limiter les droits d’édition des comptes. |
| 4 | **MFA** pour les comptes à privilèges | Authentification à deux facteurs sur l’interface d’administration. |
| 5 | **Sauvegarde** automatisée & testée | Vérifier restauration sur serveur de test. |
| 6 | **Mise à jour** des dépendances (PHP 8.2+, Dolibarr ≥ 9.0) | Planifier les patches de sécurité. |
| 7 | **Registre des traitements** RGPD mis à jour | Documenter chaque type de donnée personnelle stockée. |
| 8 | **Plan de réponse aux incidents** documenté | Scénario de fuite, contact DPO, notification sous 72 h. |
| 9 | **Audit sécurité** externe ou interne réalisé | Faire un rapport annuel et corriger les vulnérabilités. |
| 10 | **Formation** des utilisateurs aux bonnes pratiques | Sensibilisation phishing, usage du module “Export CSV”. |
---
## 9. Conclusion
La sécurisation de **Dolibarr** ne se résume pas à un simple patch ou à la mise en place d’un pare‑feu. Elle repose sur **une approche structurée**, combinant :
1. **Hardening technique** (configuration, chiffrement, droits).
2. **Monitoring continu** (logs, alertes, métriques).
3. **Gestion proactive des risques** (cartographie, priorisation).
4. **Conformité réglementaire** (RGPD, ISO 27001, PCI‑DSS…).
En suivant la feuille de route décrite dans cet article, vous transformerez votre instance Dolibarr en un **système fiable, audité et conforme**, capable de protéger efficacement les données sensibles de votre organisation tout en respectant les exigences légales.
> **Prochaine étape** : établir un **plan d’action détaillé** (responsable, échéance, ressources) et lancer le premier cycle de **revue de conformité** dès la release prochaine.
---
*Article rédigé par [Nom de l’auteur], consultant en sécurité des systèmes d’information spécialisé dans les ERP open‑source.*