Architecture de sécurité Odoo 19 : bien combiner pare-feu, 2FA, droits d'accès et Web RBL

Odoo est accessible depuis l'Internet ouvert sur nos cinq sites web, et ce n'est pas une exception, mais le cas normal : quiconque exploite une offre, une boutique ou une connexion client dispose d'un serveur public. Un seul mot de passe vulnérable, un fichier de configuration oublié ou un droit trop généreux suffit pour qu'un serveur public devienne un serveur ouvert.

Cet article montre comment sécuriser correctement Odoo 19 — non pas avec une mesure isolée, mais avec plusieurs couches qui se complètent mutuellement : pare-feu et reverse proxy, notre module open source Web RBL, authentification à deux facteurs, politique de mots de passe et droits d'accès — et quelles tentatives d'attaque chacune intercepte réellement. À la fin se trouve un guide pas à pas permettant de reproduire la démarche sur n'importe quelle installation Odoo.

La défense en profondeur : pourquoi une seule mesure ne suffit jamais

Chaque mesure de sécurité a une faille. Un pare-feu ne voit pas ce qui se passe dans un formulaire de connexion Odoo. Un mot de passe robuste ne protège pas s'il a déjà été volé ailleurs. Une structure de droits d'accès n'est d'aucune aide contre un attaquant qui ne s'est pas encore connecté. Le principe qui comble ces failles s'appelle la défense en profondeur (defense in depth) : plusieurs couches indépendantes dont chacune, prise isolément, pourrait être contournée — mais pas toutes ensemble.

Chez nous, il y a quatre couches, chacune avec une mission différente :

• Pare-feu / reverse proxy — tient à distance ce qui est manifestement malveillant avant même qu'il n'atteigne le serveur
• Web RBL — relie les deux côtés : Odoo apprend, grâce à son propre journal d'application, ce que le pare-feu ne peut pas voir, et le lui renvoie
• Odoo lui-même — authentification à deux facteurs, politique de mots de passe, droits d'accès, gestion des sessions
• Base de données & exploitation — sauvegarde, protection d'accès à l'administration, secrets hors de tout journal

Les sections suivantes passent en revue chaque couche une à une.

Couche 1 : pare-feu et reverse proxy

Le pare-feu est la première instance à voir une requête, et la seule capable de tenir un attaquant à l'écart de tous les services du serveur — pas seulement du site web, mais aussi du serveur de messagerie, de l'accès VPN et de sa propre interface d'administration. Ce qu'il est judicieux d'activer à ce niveau dépend du fabricant, mais les formes de base sont les mêmes pour OPNsense, pfSense, HAProxy, FortiGate, Sophos ou Check Point :

Listes RBL : la voie standard pour diffuser la réputation

RBL signifie Real-time Blackhole List, un terme issu du monde du courrier électronique : une adresse par ligne, accessible via HTTP, rechargée régulièrement. Pratiquement tous les pare-feu peuvent lire une telle liste et en tirer des règles — OPNsense et pfSense comme URL Table Alias, HAProxy comme fichier ACL, FortiGate comme External Block List, Palo Alto comme External Dynamic List, Cisco, Sophos, Juniper et MikroTik avec leurs propres noms pour le même principe.

C'est précisément là qu'intervient notre propre module — et c'est précisément là que commence la deuxième couche.

Couche 2 : Web RBL — le pont entre l'application et le pare-feu

Un pare-feu voit des paquets, pas la logique applicative. Il ne sait pas qu'une requête vers /xmlrpc/2/common est une tentative de connexion, que vingt chemins différents en quatorze secondes signalent un scanner, ou qu'une adresse vient de deviner un mot de passe avec succès. Tout cela, seul Odoo lui-même le sait. Web RBL, notre propre module open source (AGPL-3), rend ce savoir exploitable — pour Odoo lui-même et, diffusé sous forme de liste RBL, aussi pour le pare-feu placé devant.

Listes de menaces comparées en continu, chacune avec son propre niveau.

En bref, ce qui est décrit en détail dans l'article précédent :

• Reconnaissance de motifs dans les chemins : fichiers .env, répertoires .git, fichiers de configuration, sondes WordPress et PHP, traversée de chemin, exécution de commandes via les nouvelles interfaces d'IA
• Défense des connexions qui compte au fil des redémarrages — contrairement au compteur propre à Odoo, qui vit en mémoire vive
• Note de chaque adresse de 0 à 100, avec justification en clair
• Erreurs de configuration (QNAP, Autodiscover, Synology) détectées et jamais bloquées, car un blocage ne corrige pas le défaut, il ne fait que le masquer
• Listes de menaces tierces comme Spamhaus, FireHOL et les nœuds de sortie Tor, comparées en continu
• Liste blanche pour les adresses qui ne doivent jamais être bloquées

Pour cet article, deux propriétés sont particulièrement importantes, car elles sont directement liées au pare-feu et à la connexion.

Une liste inerte est une liste à laquelle on peut se fier

La liste blanche — des adresses qui ne sont jamais bloquées, par exemple les raccordements de nos propres sites — change en général rarement. C'est précisément sa valeur, et non son défaut : lorsqu'une liste calme ne bouge guère pendant des jours, chaque changement rare se remarque immédiatement. La mise à jour automatique quotidienne n'existe pas parce que beaucoup de choses changeraient, mais pour que le changement rare n'ait pas à être reporté à la main — et c'est précisément le moment où on l'oublie. L'une de nos propres erreurs de configuration le mois dernier a été repérée exactement ainsi : non pas par de nombreux événements, mais par celui que personne ne connaissait, jusqu'à ce que l'API web QNAP d'un client soit bloquée à tort. Depuis, QNAP figure sur la liste des erreurs de configuration qui ne sont jamais bloquées, mais seulement signalées.

La connexion est l'endroit que le pare-feu ne voit pas

Un pare-feu peut bloquer une adresse. Il ne peut pas savoir si une connexion a réussi, et encore moins si elle provenait d'une adresse qui venait de chercher des identifiants. Web RBL, lui, le sait : une note au-dessus d'un seuil réglable interdit entièrement la connexion, et une connexion réussie depuis une adresse suspecte est signalée — c'est le maillon vers la couche suivante.

Couche 3 : sécuriser Odoo lui-même

Authentification à deux facteurs : un second secret qui n'est pas réutilisable

Le plus gros problème des mots de passe n'est pas leur qualité, mais leur réutilisation. Un mot de passe volé auprès d'un autre service fonctionne chez nous exactement de la même manière tant qu'il est identique. L'authentification à deux facteurs (2FA, aussi appelée TOTP) y oppose un second secret : un code à six chiffres qui change toutes les trente secondes et qui est calculé à partir d'un secret que seul son propre smartphone connaît. Un mot de passe volé ne suffit alors plus à lui seul.

Odoo 19 Community l'intègre en standard — sous la forme du module installable Two-Factor Authentication (TOTP), complété par une option de repli par e-mail. Chaque utilisateur la configure lui-même, par code QR, avec n'importe quelle application d'authentification courante :

La configuration : scanner le code QR, confirmer une fois le code à six chiffres, et c'est terminé.

Mais cela n'aide que ceux qui la configurent eux-mêmes — et l'expérience montre que, sans contrainte, ils restent minoritaires. Odoo connaît donc une politique d'application obligatoire : soit uniquement pour les collaborateurs (utilisateurs internes), soit pour tous, utilisateurs du portail compris. Sans second secret configuré, plus personne ne franchit le formulaire de connexion sans au moins le confirmer par un code envoyé par e-mail.

Politique de mots de passe : une longueur minimale n'a rien d'évident

Sans module complémentaire, Odoo Community n'impose aucune longueur minimale pour les mots de passe — un utilisateur peut définir un mot de passe de trois caractères si personne ne l'en empêche. Le module Password Policy comble précisément cette lacune : une longueur minimale appliquée côté serveur, et pas seulement suggérée dans le navigateur. Qui veut davantage — une durée de validité imposée, un historique contre la réutilisation — a besoin pour cela d'un module OCA ou tiers ; la version Community est volontairement restée épurée.

Droits d'accès : seul celui qui en a besoin y a accès

Odoo sépare d'emblée trois niveaux : les utilisateurs du portail (uniquement leur propre portail client ou fournisseur), les utilisateurs internes (le backend, avec des droits par application) et les administrateurs (accès illimité, y compris aux paramètres techniques). L'erreur la plus fréquente n'est pas un mot de passe trop faible, mais un rôle d'administrateur attribué trop généreusement : celui qui doit seulement créer des factures n'a pas besoin d'accéder aux paramètres système.

Deux principes portent l'essentiel de la charge :

Les deux peuvent être vérifiés dans la même vue que celle où l'on configure l'authentification à deux facteurs :

Une vue d'ensemble, quatre leviers : mot de passe, second facteur, clés d'API, appareils connectés.

Sessions et appareils : qui est connecté en ce moment

La même vue montre aussi depuis quels appareils un compte est actuellement connecté — et permet de déconnecter l'un d'eux ou tous à la fois. Après la perte d'un ordinateur portable ou en cas de soupçon de mot de passe compromis, c'est l'étape efficace la plus rapide : la session se termine immédiatement, que le mot de passe ait déjà été changé ou non.

Couche 4 : base de données et exploitation

La quatrième couche est la moins visible et en même temps la plus impardonnable, car une erreur ici peut anéantir tout ce qui a été construit auparavant.

• Des sauvegardes régulières et vérifiées, stockées séparément du serveur lui-même. Une sauvegarde qui n'a jamais été restaurée est une supposition, pas une sauvegarde.
• Les secrets n'ont leur place dans aucun fichier journal. Mots de passe, clés d'API, données de licence — celui qui écrit ses propres extensions devrait les traiter comme le mot de passe principal lui-même : ne les consigner nulle part, pas même « juste pour le débogage ».
• Maintenir les modules à jour, y compris et surtout les modules tiers. Les modules complémentaires libres (OCA et autres) sont naturellement en retard sur les nouvelles versions d'Odoo ; avant chaque installation, il vaut la peine de regarder quelles dépendances sont installées automatiquement.

Le parcours de connexion dans son ensemble

Les quatre couches n'agissent pas successivement dans des pièces séparées, mais sur la même requête, étape après étape. L'exemple d'une connexion le montre le plus clairement :

Cinq endroits où une requête malveillante peut s'arrêter avant d'atteindre sa véritable cible — et un seul où un utilisateur légitime les franchit tous.

Scénarios d'attaque et contre-mesures

Le tableau suivant associe des motifs d'attaque réels aux couches qui les arrêtent effectivement. Plusieurs d'entre eux ne relèvent pas de la théorie, mais de nos propres observations sur dix-sept jours de trafic réel sur nos cinq sites web.

Pas à pas : sécuriser sa propre installation Odoo

L'ordre suivant est celui que nous suivrions nous-mêmes — de l'effet le plus important au réglage le plus fin.

1. Imposer l'authentification à deux facteurs

1. Si ce n'est pas encore installé : ouvrir Apps, rechercher « Two-Factor Authentication » et l'installer (en cas de plusieurs sites web, « Two-Factor Authentication by Mail » est en outre recommandé comme option de repli).
2. Ouvrir Paramètres → Paramètres généraux → Permissions.
3. Activer « Imposer l'authentification à deux facteurs ».
4. Choisir la politique : « Collaborateurs uniquement » pour les utilisateurs internes, « Tous les utilisateurs » si les utilisateurs du portail (clients disposant d'un accès) doivent aussi être inclus.
5. Enregistrer. Dès la prochaine tentative de connexion, Odoo exige de chaque utilisateur sans second secret configuré au moins le code par e-mail, jusqu'à ce qu'il ait configuré l'application d'authentification.

2. Définir une longueur minimale pour les mots de passe

1. Ouvrir Apps, rechercher « Password Policy » et l'installer.
2. Ouvrir Paramètres → Paramètres généraux → Permissions.
3. Définir « Longueur minimale du mot de passe » — douze caractères constituent une valeur de départ raisonnable.
4. Enregistrer. La règle s'applique dès maintenant à chaque nouveau mot de passe ou mot de passe modifié, mais pas rétroactivement aux mots de passe existants.

3. Passer en revue les droits d'accès

1. Ouvrir Paramètres → Utilisateurs & sociétés → Utilisateurs.
2. Ouvrir chaque utilisateur individuellement et vérifier l'onglet des droits d'accès par application : cette personne a-t-elle vraiment besoin de « Gestionnaire » ou « Administrateur », ou « Utilisateur » suffit-il ?
3. À vérifier en particulier : qui a accès aux « Paramètres » eux-mêmes ? Ce devrait être un très petit groupe.
4. Pour chaque connexion externe (comptabilité, scripts personnalisés, suivi du temps), dans l'onglet « Sécurité du compte » de l'utilisateur technique concerné, créer une clé d'API propre, au lieu de transmettre le mot de passe de l'utilisateur.

4. Installer Web RBL et observer avant de passer en mode actif

1. Télécharger le module depuis github.com/Alex0176/odoo-web-rbl le placer dans le chemin des addons et l'installer.
2. Observer pendant quelques jours : le menu Web RBL → Analyse montre quels motifs se déclenchent réellement.
3. Seulement ensuite, activer web_rbl.sperren_aktiv (Paramètres → Technique → Paramètres système) — à partir de là, les sondes détectées sont effectivement rejetées.
4. Intégrer la liste de blocage dans le pare-feu comme liste RBL, à l'adresse indiquée dans le module et protégée par jeton (dans OPNsense/pfSense comme URL Table Alias, dans HAProxy comme fichier ACL).

5. Sécuriser le pare-feu lui-même

1. Rendre l'interface d'administration du pare-feu accessible exclusivement depuis le réseau interne, jamais par la même adresse publique que le site web.
2. Activer les mises à jour de sécurité automatiques pour le logiciel du pare-feu, si le fabricant les propose.
3. Vérifier la configuration TLS : uniquement des versions de protocole actuelles, désactiver les méthodes de chiffrement obsolètes.
4. Si disponible : intégrer directement sur le pare-feu une liste de réputation connue (par exemple Spamhaus DROP) — indépendamment de Web RBL, car le pare-feu voit ainsi aussi le trafic vers des services qu'Odoo n'atteint jamais.

6. Fermer l'administration de la base de données

1. Vérifier si /web/database/manager est accessible de l'extérieur — si oui, définir list_db = False dans la configuration d'Odoo ou bloquer le chemin au niveau du pare-feu.
2. Définir le mot de passe principal de l'administration de la base de données long et aléatoire, et ne le noter à aucun endroit que quelqu'un d'autre pourrait lire.

7. Vérifier la sauvegarde, pas seulement la configurer

1. Mettre en place une sauvegarde automatique et régulière, stockée séparément du serveur Odoo.
2. La restaurer réellement au moins une fois et vérifier que la restauration fonctionne — une sauvegarde non vérifiée est une supposition.

Aucune de ces étapes ne remplace une autre. Celui qui n'en met qu'une en œuvre a renforcé une porte et laissé toutes les autres ouvertes — celui qui applique les sept dispose d'une défense qui tient encore lorsqu'une seule couche faillit.

Ce que cette architecture ne remplace pas

Aucune des mesures décrites ne rend la rigueur superflue. Un module qui rejette les sondes .env ne rend pas inoffensif un fichier .env publié par mégarde. L'authentification à deux facteurs ne protège pas contre un utilisateur qui lit son code à un interlocuteur au téléphone. Et un pare-feu ne remplace pas la décision de savoir qui a réellement besoin de quel droit. L'architecture de sécurité crée les conditions dans lesquelles une erreur isolée ne devient pas aussitôt un incident — elle ne dispense personne de rigueur.

Questions fréquentes

Un mot de passe robuste suffit-il pour sécuriser Odoo 19 ?

Non. Un mot de passe peut être volé ailleurs, quelle que soit sa qualité, et fonctionne alors auprès de tout service acceptant le même mot de passe. Seule la combinaison avec l'authentification à deux facteurs, un pare-feu placé devant et une structure de droits d'accès pertinente donne une protection qui tient encore après le vol d'un mot de passe.

Comment activer l'authentification à deux facteurs dans Odoo 19 ?

Installer le module « Two-Factor Authentication (TOTP) » via la gestion des Apps, puis activer l'application obligatoire sous Paramètres → Paramètres généraux → Permissions et choisir entre « Collaborateurs uniquement » et « Tous les utilisateurs ». Chaque utilisateur configure ensuite son propre second facteur par code QR.

Qu'est-ce qu'une liste RBL, et pourquoi Odoo en a-t-il besoin ?

RBL (Real-time Blackhole List) est une liste d'adresses accessible via HTTP que pratiquement tous les pare-feu peuvent lire. Odoo lui-même n'en fournit pas — notre module Web RBL comble cette lacune en détectant le trafic d'attaque dans le journal d'application propre à Odoo et en le restituant sous forme de liste RBL au pare-feu placé en amont.

Odoo 19 Community est-il suffisamment sécurisé sans modules complémentaires ?

Pas complètement. Sans le module Password Policy, il n'y a aucune longueur minimale pour les mots de passe, sans Two-Factor Authentication aucun second facteur, et sans un module comme Web RBL, Odoo ne détecte ni les tentatives de sondage ni les tentatives de connexion répétées au-delà d'un redémarrage. Les quatre peuvent être ajoutés gratuitement.

Disponibilité

Web RBL est disponible publiquement sous AGPL-3 et tourne chez nous en production sur cinq sites web :

github.com/Alex0176/odoo-web-rbl

La description complète des fonctions, avec tous les motifs, la notation et les listes de menaces, se trouve dans l'article précédent : Web RBL – liste de blocage du trafic d'attaque sur nos propres sites web.

Nous accueillons volontiers vos questions, remarques et rapports de bogues — de préférence sous forme d'issue sur GitHub.