Sécurité Dolibarr : PostgreSQL Comparaison orienté performance

Dolibarr, l’ERP/CRM open source populaire, repose souvent sur PostgreSQL pour sa base de données. La sécurisation de cette pile applicative est cruciale, mais elle ne doit pas se faire au détriment des performances. Cet article explore l’équilibre délicat entre sécurité renforcée et optimisation des performances PostgreSQL pour Dolibarr, en proposant une approche pragmatique.

1. PostgreSQL par défaut pour Dolibarr : Un choix fondé sur la sécurité et la robustesse

Contrairement à MySQL/MariaDB, PostgreSQL offre par défaut un modèle de sécurité plus rigoureux :

  • Séparation stricte des rôles : Pas d’accès "root" automatique. Le principe du moindre privilège est natif.

  • Politiques de mot de passe robustes : Gestion fine des authentifications (SCRAM-SHA-256, etc.).

  • Sécurité au niveau des lignes (RLS) : Possible, bien que peu utilisée par défaut dans Dolibarr.

  • Conformité ACID stricte : Garantit l’intégrité des données financières et commerciales, un pilier de la sécurité transactionnelle.

Conclusion préliminaire : Le choix de PostgreSQL pour Dolibarr est déjà un bon point de départ sécuritaire. L’optimisation viendra ensuite de sa configuration.

2. Durcissement Sécuritaire (Hardening) de PostgreSQL pour Dolibarr

Ces mesures doivent être mises en place avant toute optimisation fine, car elles réduisent la surface d’attaque.

a) Configuration postgresql.conf (Sécurité de base)

# Désactiver l'accès non chiffré depuis le réseau si Dolibarr est local

listen_addresses = 'localhost'  # ou l'IP spécifique du serveur d'application
# Journalisation obligatoire pour l'audit

log_statement = 'all'        # Ou 'ddl' pour un équilibre performant/audit

log_connections = on

log_disconnections = on

log_line_prefix = '%m [%p] %u@%d/%a '
# Chiffrement des mots de passe

password_encryption = scram-sha-256

Impact performance : log_statement = 'all' génère une charge I/O disque significative. Pour la production, privilégiez log_statement = 'ddl' et log_min_error_statement = error, en complément d’outils d’audit applicatif Dolibarr.

b) Gestion des rôles et schémas

  • Ne jamais utiliser le superutilisateur postgres pour Dolibarr.

  • Créer un rôle dédié : CREATE ROLE dolibarr_user WITH LOGIN PASSWORD '...' NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT;

  • Accorder uniquement les privilèges nécessaires sur la base et les schémas : 
    GRANT CONNECT ON DATABASE dolibarr TO dolibarr_user;
    
GRANT USAGE ON SCHEMA public TO dolibarr_user;
    
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO dolibarr_user;
    
ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO dolibarr_user;

  • Astuce performance : Un rôle avec des privilèges minimaux évite les opérations de vérification inutiles par PostgreSQL. C’est une micro-optimisation, mais bonne pratique.

c) pg_hba.conf : Le gardien de l’accès

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# Accès local via socket (recommandé si app sur même serveur)

local   all             dolibarr_user                          scram-sha-256

# Accès TCP depuis le serveur web/application (IP spécifique!)

host    dolibarr       dolibarr_user   192.168.1.100/32        scram-sha-256

# Refuser tout le reste par défaut (placer en fin de fichier)

host    all             all             0.0.0.0/0               reject

3. Optimisation des Performances PostgreSQL compatible avec la sécurité

L’optimisation doit respecter les contraintes de sécurité établies ci-dessus.

a) Paramètres mémoire & cache (shared_buffers, work_mem, maintenance_work_mem)

  • shared_buffers : 25% de la RAM système est un bon point de départ. Cela améliore le cache des données, réduisant les I/O disque.

  • work_mem : Augmentez-le (ex: 16-64MB). Une valeur trop faible cause des spills sur disque pour les tris et jointures, dégradant les performances des rapports Dolibarr.

  • maintenance_work_mem : 128MB+ pour accélérer les VACUUM, CREATE INDEX, ALTER TABLE (gérés par Dolibarr lors des mises à jour de modules).

⚠️ Attention sécurité : Une mémoire excessive allouée à PostgreSQL peut le rendre vulnérable aux attaques par déni de service (OOM killer). Équilibrez avec les besoins des autres services.

b) Optimisation des requêtes et indexation (Levier principal)

  • Surveiller les requêtes lentes : Activez pg_stat_statements (extension indispensable) pour identifier les requêtes Dolibarr les plus coûteuses. 
    CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

    Requête de监控 : SELECT query, total_time, calls FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10;

  • Analyser les plans d’exécution avec EXPLAIN ANALYZE sur les requêtes identifiées.

  • Créer des index pertinents sur les tables les plus sollicitées (ex: llx_societe, llx_proposal, llx_invoice). Attention : Trop d’index ralentissent les INSERT/UPDATE et augmentent la surface d’attaque par pollution de cache (certaines attaques visent à "bousculer" le cache). Indexez stratégiquement.

  • Mettre à jour les statistiques : autovacuum doit être finement réglé pour éviter la "bloat" (fragmentation) qui plombe les performances. 
    autovacuum_vacuum_scale_factor = 0.05  # Plus agressif sur les tables actives
    
autovacuum_analyze_scale_factor = 0.02

c) Connexions et pooling (Performance et stabilité)

Dolibarr, comme toute application web, ouvre/ferme de nombreuses connexions courtes. Cela épuise les ressources PostgreSQL.

  • Imposer un max_connections réaliste (ex: 100-150) dans postgresql.conf.

  • Utiliser un pooler de connexions OBLIGATOIRE : PgBouncer en mode transaction est idéal pour Dolibarr.

    • Réduit drastiquement la charge de max_connections.

    • Améliore la latence des requêtes.

    • Sécurité : PgBouncer peut être configuré pour forcer l’utilisation de scram-sha-256 et filtrer les requêtes dangereuses (ex: COPY ... TO PROGRAM).

4. Points de Vigilance Spécifiques à Dolibarr

  1. Modules externes : Un modules tiers mal codé peut générer des requêtes N+1 catastrophiques. Auditez les performances après toute installation.

  2. Tâches cron (batch) : Les processus batch (génération de PDF, envois massifs) doivent être planifiés en heures creuses. Ajustez work_mem pour ces sessions lourdes (via ALTER ROLE dolibarr_user SET work_mem = '64MB';).

  3. Stockage des fichiers : Dolibarr stocke les documents (PDF, images) en dehors de la base (dans doc/). C’est une excellente pratique sécurité/performance : la base ne contient que les métadonnées. Ne mettez JAMAIS les documents dans la base (champs LONGBLOB), sauf cas très spécifiques et contrôlés.

  4. Mises à jour : Appliquez régulièrement les mises à jour de Dolibarr (correctifs de sécurité applicative) et de PostgreSQL (correctifs système et moteur).

5. Synthèse : La Boucle Vertueuse Sécurité/Performance

Action Sécuritaire Bénéfice Performance Indirect Risque si Ignoré
Rôle utilisateur dédié, privilèges min. Moins de vérifications par PostgreSQL, cache optimal Fuites de données, requêtes non désirées lourdes
pg_hba.conf restrictif Évite les tentatives de connexion coûteuses Attaques par force brute, saturation des connexions
Journalisation ciblée (log_statement=ddl) Réduction I/O disque, CPU préservé Logs énormes, disque plein, ralentissement système
PgBouncer (pooling) Élimine la surcharge de connexion, scaling Échec sous charge, plantage dû à max_connections
autovacuum bien réglé Base saine = requêtes rapides, espace maîtrisé Fragmentation, ralentissement progressif灾难

Conclusion

Sécuriser Dolibarr avec PostgreSQL n’est pas une option, c’est un prérequis. La bonne nouvelle est que la plupart des meilleures pratiques de sécurité pour PostgreSQL (modèle de rôles strict, pg_hba.conf, moindre privilège, mise à jour) sont gratuites en termes de performance, voire bénéfiques.

L’optimisation performante doit ensuite s’appuyer sur cette base saine :

  1. Pooler de connexions (PgBouncer) : Non négociable.

  2. Indexation & requêtes : Suivi continu via pg_stat_statements.

  3. Paramètres mémoire : Ajustement fin basé sur la RAM disponible.

  4. Maintenance : autovacuum réglé pour votre volume Dolibarr.

En adoptant cette démarche itérative – sécuriser d’abord, optimiser ensuite – vous construisez une infrastructure Dolibarr à la fois résiliente aux attaques et capable de supporter votre croissance métier. N’oubliez jamais : une base de données lente et mal configurée peut être une faille de sécurité en soi (DoS), tout comme une base non sécurisée peut mener à une catastrophe irrémédiable.

Publications similaires