Objectif – Vous fournir une méthodologie claire et opérationnelle pour sécuriser votre plateforme Dolibarr (ERP/CRM) tout en intégrant la sécurité dès la conception (security‑by‑design). La checklist ci‑dessous peut être utilisée à chaque étape du cycle de vie du projet : installation, configuration, exploitation et maintenance.
1️⃣ Cadre de référence & Principes de base
| Principe | Description | Application à Dolibarr |
|---|---|---|
| Defense‑in‑depth | Plusieurs couches de défense (réseau, application, données). | Firewall, HTTPS, contrôle d’accès, chiffrement des données. |
| Least privilege (principe du moindre privilège) | Chaque composant ne possède que les droits strictement nécessaires. | Droits DB, droits fichier, rôles PHP, comptes système. |
| Fail‑secure | En cas d’erreur, le système doit rester bloqué dans un état sûr. | Refus d’accès par défaut, logs détaillés, erreurs affichées uniquement aux administrateurs. |
| Security‑by‑design | La sécurité est intégrée dès le premier jour, pas ajoutée en arrière‑plan. | Choix de la stack (Docker, HTTPS, 2FA) dès l’installation. |
| Patch & Update | Mise à jour régulière des dépendances et du code. | Monitoring des versions Dolibarr, plugins, bibliothèques. |
2️⃣ Étapes de mise en œuvre (Checklist détaillée)
A. Pré‑installation – Analyse & Planification
- Inventaire des parties prenantes
- Identifier les utilisateurs, rôles, API externes et partenaires.
- Cartographie des flux métier
- Diagrammer lestraces (clients, paiement, facturation, stocks) pour identifier les points critiques.
- Évaluation des exigences de conformité
- RGPD, PCI‑DSS, ISO 27001, etc. – Définir les obligations spécifiques.
- Choix de l’infrastructure
- Serveur dédié, VPS, cloud (AWS, Azure, GCP) – Définir les exigences de isolation (VPC, sous‑réseaux).
- Plan de sauvegarde & de continuité
- Stratégie de backup (incremental + full), rotation, tests de restauration.
B. Installation – Renforcer le基礎
| Action | Détails | Outils / Références |
|---|---|---|
| Utiliser les sources officielles | Télécharger le zip officiel, vérifier le checksum SHA256. | sha256sum ou md5sum. |
| Déployer via Docker (option recommandée) | Containeriser l’application, limiter les privilèges du conteneur. | docker run --restart unless‑stopped -u www-data:www-data |
| Séparer les services | DB (MariaDB/MySQL) dans un conteneur ou serveur dédié, pas sur le même hôte que Dolibarr. | Docker‑Compose ou Kubernetes. |
| Privilégier un OS minimal & à jour | Ex. Ubuntu LTS 22.04, Debian 12, ou RockyLinux 9. | Utiliser les dépôts officiels et activer les mises à jour automatiques. |
| Définir des variables d’environnement | DOLIBARR_SERVER_ROOT, DOLIBARR_DB_TYPE, DOLIBARR_HTTPS=1, DOLIBARR_HTTPS_CERT, etc. |
.env protégé (chmod 600). |
| Configurer un reverse proxy HTTPS | Nginx ou Caddy avec TLS 1.3, HSTS, OCSP stapling. | Certificat Let’s Encrypt ou PKI interne. |
C. Configuration de Dolibarr – Hardening applicatif
- Désactiver les modules inutiles
Modules → Desactivertout ce qui n’est pas utilisé (ex.exnet,multicurrencysi non requis).
- Forcer le mode « HTTPS only »
- Dans
Configuration → General → HTTPS, cocher « Force SSL ».
- Dans
- Limiter l’accès à l’admin
- Créer un virtual host dédié (ex.
admin.mydomain.local) avec IP‑whitelisting ou authentification HTTP Basic + 2FA.
- Créer un virtual host dédié (ex.
- Renforcer les droits de la base de données
- Créez un utilisateur DB dédié :
GRANT SELECT,INSERT,UPDATE,DELETE ON dolibarr.* TO 'dolibarr_user'@'%' IDENTIFIED BY '**********'; - Révoquez
DROP,CREATE, etc.
- Créez un utilisateur DB dédié :
- Activer le chiffrement des communications
php.ini→openssl.cipher = AES-256-GCM.- Désactivez les fonctions PHP inutiles (
disable_functions = exec,passthru,shell_exec,system,proc_open,popen).
- Paramétrer le mot de passe du compte admin
- Minimum 12 caractères, contenant majuscules, minuscules, chiffres et symboles.
- Activer 2FA via l’extension
Google AuthenticatorouAuthentification à deux facteurs.
- Limiter les tentatives de connexion
- Utiliser un module d Captcha ou
Fail2Bansur le log d’authentification.
- Utiliser un module d Captcha ou
- Configurer le fichier
conf/master.confSESSION LIFETIME = 3600(ou moins) – Réduire le temps de vie de la session.FORCE_HOST = your.domain.tld– Prévenir les attaques de Host‑Header.
D. Sécurisation du réseau & du système
| Action | Détails |
|---|---|
| Firewall | Autoriser uniquement les ports 80/443 (HTTPS) et 3306 (DB) depuis les IP de confiance. |
| Fail2Ban | Filtre Apache/Nginx pour bloquer les IPs après 5 tentatives d’erreur d’authentification. |
| IDS/IPS | Deployez un système d’intrusion léger (OSSEC, Wazuh) pour surveiller les changements de fichiers critiques. |
| Séparer les environnements | Dev / Test / Prod sur des sous‑réseaux ou des tags Docker différents. |
| Audit des logs | Rotation quotidienne (logrotate), archivage crypté (GPG), centralisation (ELK, Graylog). |
| TLS strict | ssl_protocols TLSv1.2 TLSv1.3;ssl_ciphers HIGH:!aNULL:!MD5;ssl_prefer_server_ciphers on; |
E. Gestion des données & conformité
- Chiffrement des colonnes sensibles (ex. numéros de carte, données personnelles).
- Utiliser les fonctions
OpenSSLvia un plugin ou écrire un champ chiffré personnalisé.
- Utiliser les fonctions
- Masquage & anonymisation des logs (ex. masquer les champs
email,nom). - Droit à l’oubli – Implémenter une procédure de suppression/anonymisation automatisée pour répondre aux demandes RGPD.
- Journalisation des accès – Activer
audit_log(ou plugin équivalent) pour tracer chaque modification de données critiques.
F. Tests & Validation
| Test | Objectif | Méthode |
|---|---|---|
| Scansion de vulnérabilités | Identifier les failles connues (OWASP). | Nikto, OWASP ZAP, Qualys. |
| Pen‑test interne | Vérifier la contrainte du moindre privilège. | Utiliser sqlmap (sur comptes test) ou scripts de bruteforce. |
| Tests de récupération | S’assurer que les sauvegardes sont récupérables. | Simuler une perte de disque, restaurer à partir du backup. |
| Audit de configuration | Vérifier que les paramètres de sécurité sont appliqués. | Dolibarr Hardening Script (exist. sur GitHub). |
| Simulation d’incident | Tester le temps de réponse et la communication d’incident. | Exercices de table‑top ou drill de perte de service. |
3️⃣ Checklist “À cocher” (version imprimable)
| ✅ | Action | Responsable | Échéance | Commentaire |
|---|---|---|---|---|
| ☐ | Télécharger la version officielle et vérifier le checksum | Admin Sys | J‑1 | |
| ☐ | Déployer via Docker‑Compose avec user non‑root | DevOps | J‑2 | |
| ☐ | Configurer Nginx avec TLS 1.3 + HSTS | SysAdmin | J‑2 | |
| ☐ | Désactiver tous les modules non essentiels | Business Analyst | J‑3 | |
| ☐ | Créer un compte DB dédié avec droits limités | DBA | J‑3 | |
| ☐ | Activer le mode « Force SSL » dans Dolibarr | Admin | J‑4 | |
| ☐ | Implémenter 2FA pour les comptes admin | Security Officer | J‑4 | |
| ☐ | Configurer Fail2Ban sur les logs d’authentification | Security | J‑5 | |
| ☐ | Réduire la durée de vie des sessions à 1 h | Dev | J‑5 | |
| ☐ | Mettre en place la rotation et le chiffrement des logs | SysAdmin | J‑6 | |
| ☐ | Planifier les backups (full + incrémental) | Ops | J‑7 | Tester mensuellement |
| ☐ | Réaliser le premier scan de vulnérabilité | Pentester | J‑8 | |
| ☐ | Documenter les procédures d’incident & de reprise | PM | J‑9 | |
| ☐ | Faire valider la configuration par un audit externe | Direction | J‑10 | |
| ☐ | Mettre à jour le certificat TLS chaque 90 jours | SysAdmin | Ongoing | |
| ☐ | Appliquer les patches de Dolibarr dès leur sortie | Dev | Ongoing |
4️⃣ Bonnes pratiques à long terme
| Domaine | Bonnes pratiques |
|---|---|
| Patch Management | Souscrire à la mailing‑list Docker/Dolibarr, automatiser les notifications (unattended-upgrades). |
| Monitoring | Métriques Prometheus (exposition du stats de Dolibarr via /phpinfo.php). |
| Security Champions | Désigner un “security champion” parmi les développeurs pour valider chaque release. |
| Formation | Sensibiliser les utilisateurs aux phishing & à la gestion des mots de passe. |
| Segregation des environnements | Utiliser destags Docker (dev, test, prod) et des variables d’environnement distinctes. |
| Gestion des secrets | Stocker les clés API, mots de passe DB dans un vault (HashiCorp Vault, AWS Secrets Manager). |
| Réduction de la surface d’attaque | Supprimer les fichiers inutiles (install.php, setup.sh) après installation. |
| Documentation vivante | Maintenir un wiki interne des procédures de sécurité Dolibarr (mise à jour régulière). |
5️⃣ Conclusion
Mettre en place une sécurité robuste sur Dolibarr ne consiste pas à cocher une simple case, mais à adopter une approche systémique qui intègre la protection à chaque niveau du système d’information. En suivant la checklist ci‑dessus :
- Planifier dès le départ (analyse, conformité, infrastructure).
- Isoler et chiffrer les communications et les données.
- Limiter les privilèges tant au niveau du serveur que de l’application.
- Actualiser et surveiller continuellement (patches, logs, tests).
- Documenter et former les équipes pour pérenniser les bonnes pratiques.
Vous disposerez alors d’une plateforme Dolibarr résiliente, conforme aux exigences légales et capable de résister aux menaces modernes.
Ressources complémentaires
| Ressource | Lien |
|---|---|
| Dolibarr Official Documentation – Security | https://dolibarr.org/en/doc/security/ |
| OWASP Top 10 – Application Security | https://owasp.org/www-project-top-ten/ |
| Docker Hardening Guide | https://docs.docker.com/engine/security/ |
| Fail2Ban – Official Documentation | https://www.fail2ban.org/wiki/index.php/Main_Page |
| HashiCorp Vault – Secrets Management | https://www.vaultproject.io/ |
| Docker Bench for Security | https://github.com/docker/docker-bench-security |
À retenir : la sécurité n’est jamais « terminée ». Chaque mise à jour de Dolibarr ou de ses dépendances ouvre une fenêtre d’opportunité pour renforcer davantage votre posture de sécurité. Continuez à auditer, à tester et à former !
Auteur : Équipe Sécurité & DevOps – 2025 (adapté à votre contexte Dolibarr).