Architecture Dolibarr : hébergement avec une approche sécurité

1. Introduction

Dolibarr est un ERP / CRM Open‑Source très répandu pour les PME et les indépendants. Sa simplicité d’utilisation masque toutefois une complexité sous‑jacente lorsqu’il s’agit de le déployer de façon sécurisée, surtout dans un contexte professionnel où les données sensibles (clients, factures, stocks) sont en jeu.

Cet article décrit l’architecture typique de Dolibarr, les différentes modalités d’hébergement (serveur dédié, VPS, cloud, conteneurs) et propose une feuille de route détaillée pour mettre en place une défense en profondeur dès le stade de l’infrastructure. Le but est d’aider les administrateurs, les développeurs et les décideurs à choisir la meilleure stratégie d’hébergement tout en respectant les exigences de confidentialité, d’intégrité et de disponibilité.

2. Architecture fonctionnelle de Dolibarr

Niveau Composant Description
Client Navigateur web (HTML/CSS/JS) Interface utilisateur statique, ne contient aucune logique métier.
Web server PHP + Apache/Nginx Exécute le code PHP de Dolibarr, sert les pages et gère les requêtes HTTP.
Base de données MySQL / MariaDB / PostgreSQL Stocke toutes les données (articles, contacts, factures, logs).
Stockage Système de fichiers Fichiers de configuration (conf/poll.conf, www), images, pièces jointes, sauvegardes.
Cron / Scheduler Tâches planifiées Executes des scripts externes (envoi de mails, nettoyage de logs).

Note : Dans la distribution officielle, les dépendances sont limitées à PHP ≥ 7.2 et un SGBD relationnel. Les versions récentes offrent une compatibilité avec Docker et des paquets pre‑compilés pour simplifier le déploiement.

Cette architecture trois tiers (présentation, logique, persistance) doit être isolée au niveau réseau et des droits d’accès pour minimiser les vecteurs d’attaque.

3. Modèles d’hébergement

3.1 Hébergement partagé

  • Avantages : Coût faible, maintenance prise en charge par le fournisseur.

  • Limites : Accès limité aux paramètres du serveur, risques de “noisy neighbour”, pas de contrôle total sur les extensions PHP ou les versions de PHP/MySQL.

Recommandation : Utilisable uniquement pour des environnements de test ou de petite taille, à condition d’activer le mode « shared‑hosting » de Dolibarr (gestion du php.ini via .htaccess) et de désactiver les fonctions dangereuses (disable_functions).

3.2 Serveur dédié / VPS

  • Avantages : Contrôle complet (OS, PHP, DB), capacité à installer des extensions spécifiques, isolation via virtualisation ou conteneurs.

  • Limites : Coût plus élevé, responsabilité de la maintenance système.

Cas d’usage typique : PME qui souhaitent garder la charge de travail interne, mais qui veulent une meilleure performance et des sauvegardes automatisées.

3.3 Cloud (IaaS / PaaS)

  • IaaS (ex. : AWS EC2, OVH Bare Metal) – similaire à un VPS mais avec la possibilité de dimensionner dynamiquement les ressources.

  • PaaS (ex. : Azure App Service, Google Cloud Run) – déploiement “sans serveur” où le provider gère le runtime PHP.

Points forts : Elasticité, sauvegarde automatisée, possibilité d’utiliser des bases de données gérées (RDS, CloudSQL).
Attention : La conformité RGPD dépend de la localisation des data‑centers et des certifications du provider.

3.4 Conteneurs Docker

  • Principe : Emballer l’application, le serveur web (NGINX/Apache) et le SGBD dans des images immuables.

  • Bénéfices : Reproductibilité, isolation forte, mise à jour du runtime via un simple docker pull.

  • Sécurité : Utilisation de profils de sécurité (seccomp, AppArmor), limites de ressources (--memory, --cpus) et volumes montés pour séparer les données persistantes.

Recommandation : Docker est la solution la plus moderne et la plus adaptée aux environnements DevOps/Continuous Integration. Elle facilite la mise en place de hardening au niveau du conteneur.

4. Approche sécurité : principes généraux

  1. Principe du moindre privilège – chaque processus utilise le compte le plus restreint possible.

  2. Défense en profondeur – plusieurs couches de protections (réseau, OS, application) sont combinées.

  3. Sécurité par défaut – des configurations robustes sont appliquées dès le démarrage, sans attendre de patch.

  4. Visibilité et audit – logs centralisés, monitoring en temps réel et rotations de logs.

Nous allons détailler chaque couche dans le contexte d’un déploiement Docker (solution la plus flexible).

5. Sécurisation de l’infrastructure Docker

5.1 Construction de l’image Docker

# Dockerfile minimal

FROM php:8.2-fpm-alpine
# 1. Installer les dépendances système minimalistes

RUN apk add --no-cache \

    nginx \

    libpng-dev \

    libjpeg-turbo-dev \

    freetype-dev \

    mariadb-client \

    && docker-php-ext-install gd mysqli pdo_mysql
# 2. Créer un utilisateur non‑root dédié

RUN addgroup -g 1001 -S dolibarr && \

    adduser -u 1001 -S -G dolibarr dolibarr
# 3. Copier le code source et les fichiers de configuration

COPY --chown=dolibarr:dolibarr ./www/ /var/www/html/

COPY --chown=dolibarr:dolibarr ./conf/ /var/www/html/conf/
# 4. Modifier les permissions pour isoler l’application

RUN chown -R dolibarr:dolibarr /var/www/html && \

    chmod -R 750 /var/www/html
# 5. Exposer les ports

EXPOSE 80 443
# 6. Entrypoint configuré pour démarrer nginx + php-fpm

CMD ["sh", "-c", "nginx -g 'daemon off;' & php-fpm8.2 -F"]

  • Analyse de chaque instruction :

    1. Alpine minimise la surface d’attaque.

    2. Ajout de libpng et libjpeg uniquement si Dolibarr a besoin de ces bibliothèques (gestion des photos de produits).

    3. Création d’un utilisateur dédié évite l’utilisation du compte root.

    4. Permissions rigides (750) limitent l’accès aux dossiers critiques.

    5. Exposition explicite des ports limite les vecteurs d’accès non intentionnels.

Bonnes pratiques :

  • Utiliser docker buildx pour créer des images multi‑arches (amd64, arm64).

  • Signer les images avec cosign ou Docker Content Trust pour prévenir les altérations.

5.2 Configuration du serveur web (NGINX)

# /etc/nginx/conf.d/dolibarr.conf

server {

    listen 80 default_server;

    server_name dolibarr.example.com;

    return 301 https://$host$request_uri;

}
server {

    listen 443 ssl http2;

    server_name dolibarr.example.com;
# Certificats Let's Encrypt (renouvellement automatique)

    ssl_certificate /etc/letsencrypt/live/dolibarr.example.com/fullchain.pem;

    ssl_certificate_key /etc/letsencrypt/live/dolibarr.example.com/privkey.pem;

    ssl_prefer_server_ciphers on;

    ssl_protocols TLSv1.2 TLSv1.3;

    ssl_ciphers 'TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256:...';
# Redirection HTTP → HTTPS + HSTS

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
root /var/www/html;

    index index.php index.html;
location / {

        try_files $uri $uri/ /index.php?$args;

    }
location ~ \.php$ {

        fastcgi_pass 127.0.0.1:9000;

        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        include fastcgi_params;

    }
# Limitation des gros fichiers (ex. : upload de pièces justificatives)

    client_max_body_size 100M;

}

  • Sécurisation TLS :

    • Utilisation de certificats Let’s Encrypt avec renouvellement automatisé (certbot).

    • Désactivation des protocoles anciens (TLS 1.0/1.1).

    • Paramétrage de ssl_ciphers avec les algorithmes forts recommandés par le Mozilla SSL Config Generator.

  • Headers de sécurité :

    • X-Content-Type-Options: nosniff

    • X-Frame-Options: SAMEORIGIN

    • Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data:;

5.3 Sécurisation du moteur de base de données

  • Mise en place d’un conteneur MySQL/MariaDB séparé ou utilisation d’un service géré.

  • Configuration réseau : 

    networks:
    
dolibarr-net:
    
  driver: bridge
    
services:
    
mariadb:
    
  image: mariadb:10.11
    
  restart: unless-stopped
    
  environment:
    
    MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
    
    MYSQL_DATABASE: dolibarr
    
    MYSQL_USER: dolibarr_user
    
    MYSQL_PASSWORD: ${MYSQL_PASSWORD}
    
  volumes:
    
    - mariadb-data:/var/lib/mysql
    
  networks:
    
    - dolibarr-net
    
  # Limiter l’accès :
    
  security_opt:
    
    - no-new-privileges:true
    
  cap_drop:
    
    - ALL

  • Privilèges réduits : le compte dolibarr_user possède uniquement les droits SELECT, INSERT, UPDATE, DELETE sur les tables requises, jamais DROP ou CREATE.

  • Utilisation d’un socket Unix plutôt que TCP lorsqu’on co‑locate DB et app dans le même conteneur Docker compose.

5.4 Isolation du conteneur et du système hôte

Technique Description
Capabilities --cap-drop ALL supprime toutes les capabilities Linux.
Seccomp Ajouter un profil seccomp:./profile.json qui autorise uniquement les syscalls nécessaires.
AppArmor Profils intégrés (docker-profiles/apparmor-profiles/profile.d/dolibarr) pour restreindre l’accès aux fichiers système.
Limitation des ressources --memory 512m --cpus 0.5 empêche la consommation abusive de RAM/CPU.
Read‑only filesystem read_only: true sur le répertoire /var/www/html (sauf les volumes mountés pour les logs).
Network namespace Utilisation d’un réseau dédié (dolibarr-net) afin d’empêcher les communications sortantes non nécessaires.

6. Gestion des données sensibles

  1. Chiffrement au repos :

    • Utiliser le chiffrement natif du SGBD (InnoDB avec innodb_encrypt_pages = ON).

    • Sur le serveur hôte, activer le LUKS ou le ZFS encrypted dataset pour le répertoire contenant les sauvegardes.

  2. Chiffrement en transit :

    • Toujours servir Dolibarr via HTTPS.

    • Forcer le TLS 1.3 si le SGBD le supporte (ex. : requires_ssl = true dans my.cnf).

  3. Gestion des credentials :

    • Ne jamais stocker les mots de passe en clair dans les fichiers de configuration.

    • Utiliser Docker secrets ou des Vault (HashiCorp, Azure Key Vault) pour injecter les variables d’environnement au démarrage du conteneur.

  4. Back‑up sécurisé :

    • Planifier des dumps SQL chiffrés (mysqldump --defaults-extra-file=/run/secrets/db_creds.sql | gzip > /backups/dump_$(date +%F).sql.gz).

    • Conserver les sauvegardes dans un bucket cloud disposant d’un access control list (ACL) strict.

  5. Audit et journalisation :

    • Configurer rsyslog ou journalctl pour rediriger les logs PHP (error_log) vers stdout et les collecter dans un système de logs centralisé (ELK, Loki).

    • Activer le mod_security côté Nginx pour bloquer les requêtes d’injection SQL classiques.

7. Processus de mise à jour et de patching

Étape Action
1. Monitoring Utiliser watchtower ou Ansible pour détecter les nouvelles versions d’images Docker.
2. Test en pré‑prod Créer un environnement de staging identique (même réseau, même volumes). Tester la migration des données.
3. Déploiement bleu/vert Faire tourner deux versions de conteneurs simultanément et basculer le DNS après validation.
4. Patch Appliquer les correctifs de sécurité du SGBD et du runtime PHP (apt-get upgrade ou mise à jour de l’image de base).
5. Rotation des clés Renouveler les certificats TLS avant expiration, et mettre à jour les secrets Docker.
6. Validation Vérifier la conformité des en‑têtes de sécurité (via curl -I https://dolibarr.example.com) et le bon fonctionnement des API internes.

8. Checklist de mise en production

Domaine Points à valider
Réseau – Ports 80/443 seulement exposés.
– Pas d’accès direct aux ports de la DB depuis l’extérieur.
Identité – Authentification à l’interface d’administration via 2FA (ex. : TOTP).
Configuration PHP – disable_functions → exec, shell_exec, phpinfo, show_source.
– open_basedir limité au répertoire de l’app.
SGBD – Accès en lecture‑écriture uniquement pour l’utilisateur dédié.
– Désactivation du FILE privilege si pas de besoins d’import/export depuis le serveur.
Logs – Rotation quotidienne (logrotate).
– Centralisation et conservation ≥ 90 jours.
Backup – Procédure de restauration testée au moins une fois par trimestre.
Hardening – Profils Docker AppArmor et Seccomp appliqués.
– --read-only sur les dossiers non nécessaires.
Tests d’intrusion – Scan de vulnérabilités (Nikto, OpenVAS).
– Pentest interne (OWASP ZAP) pour vérifier XSS, CSRF et injection.
Conformité – Vérification du registre RGPD (si vous traitez des données personnelles).
– Mise à jour de la politique de confidentialité et information légale.

9. Conclusion

L’architecture de Dolibarr, lorsqu’elle est déployée avec une méthodologie orientée sécurité dès le départ, offre une base solide pour les PME qui souhaitent centraliser leurs processus métiers sans sacrifier la protection des données.

  • Le conteneur Docker constitue aujourd’hui la méthode la plus flexible pour combiner portabilité, isolation etFacilité de mise à jour.

  • Le durcissement du stack (PHP, Nginx, MySQL) passe par la minimisation des privilèges, le chiffrement des flux, la gestion rigoureuse des secrets et la mise en place de logs d’audit centralisés.

  • Le modèle de mise à jour doit être intégré à la chaîne CI/CD pour garantir que chaque version livrée soit validée contre les tests de sécurité avant d’être mise en production.

En suivant les bonnes pratiques présentées — segmentation réseau, profils de sécurité Docker, utilisation d’HTTPS et de TLS modernisé, chiffrement des sauvegardes et rotation régulière des credentials — il est possible de transformer un ERP open‑source simple en une plateforme d’entreprise confiable, résiliente et conforme aux exigences de protection des données.

Message clé : la sécurité ne doit jamais être ajoutée « après coup ». Elle doit être inscrite dans le design même de l’infrastructure Dolibarr, du conteneur à la base de données, en passant par le serveur web.

Article rédigé par [Nom de l’auteur], consultant sécurité spécialisé en architectures d’applications open‑source, 2025.

Publications similaires