Odoo Sécurité

Sauvegardes / Reprise après sinistre

• Nous conservons 14 sauvegardes complètes de chaque base de données d'Odoo pour une durée maximale de 3 mois : 1/jour pendant 7 jours, 1/semaine pendant 4 semaines, 1/mois pendant 3 mois.
• Les sauvegardes sont répliquées sur au moins 3 centres de données différents, sur au moins 2 continents différents.
• Les emplacements exacts de nos centres de données sont précisés dans notre Politique vie privée.
• Vous pouvez également télécharger des sauvegardes manuelles de vos données en direct à tout moment en utilisant le panneau de contrôle.
• Vous pouvez contacter notre service d'assistance pour restaurer n'importe laquelle de ces sauvegardes sur votre base de données active (ou sur le côté).
• Basculement du matériel : pour les services hébergés sur un serveur dédié, où une défaillance matérielle est possible, nous mettons en place une réplication locale en hot standby, avec surveillance et une procédure de basculement manuel qui prend moins de 5 minutes.
• Reprise après sinistre : en cas de sinistre total, avec un centre de données entièrement hors service pendant une période prolongée, empêchant le basculement vers notre hot standby local (cela ne s'est jamais produit jusqu'à présent, c'est le pire scénario), nous avons les objectifs suivants :
  • RPO (Objectif de point de récupération) = 24 heures. Ceci signifie que vous pouvez perdre au maximum 24 heures de travail s'il est impossible de récupérer les données et si nous devons restaurer votre dernière sauvegarde quotidienne.
  • RTO (Objectif de temps de récupération) = 24 heures pour les abonnements payants, 48 heures pour les essais gratuits, l'offre éducative, les utilisateurs freemium, etc. Il s'agit du temps nécessaire pour restaurer les services dans un centre de données différent en cas de sinistre et si un centre de données est entièrement hors service.
  • Comment nous y parvenons : nous surveillons activement nos sauvegardes quotidiennes et elles sont répliquées sur de multiples sites sur plusieurs continents. Nous disposons d'un système de provisionnement automatisé pour déployer nos services dans un nouveau site d'hébergement. La restauration des données basée sur nos sauvegardes de la veille peut alors être effectuée en quelques heures (pour les clusters les plus importants), accordant la priorité aux abonnements payants.
    Nous utilisons régulièrement les sauvegardes quotidiennes et des scripts de provisionnement pour les opérations quotidiennes, de sorte que les deux parties de la procédure de reprise après sinistre sont testées en permanence.

Sécurité de la base de données

• Les données des clients sont stockées dans une base de données dédiée - aucun partage de données entre les clients.
• Les règles de contrôle d'accès aux données mettent en œuvre une isolation complète entre les bases de données des clients fonctionnant sur le même cluster, aucun accès n'est possible d'une base de données à l'autre.

Sécurité des mots de passe

• Les mots de passe des clients sont protégés par des chiffrements PBKDF2+SHA512 conformes aux normes industrielles (salage + étirement pour des milliers de tours).
• Le personnel d'Odoo n'a pas accès à votre mot de passe et ne peut pas le récupérer pour vous. Votre seule option en cas de perte est de le réinitialiser.
• Les identifiants de connexion sont toujours transmis de manière sécurisée via HTTPS.
• Les administrateurs des bases de données clients ont même l'option de configurer la limitation de taux et la durée de refroidissement en cas de tentatives de connexion répétées.
• Politiques en matière de mots de passe : les administrateurs de bases de données disposent d'un paramètre intégré leur permettant d'imposer une longueur minimale pour le mot de passe de l'utilisateur. D'autres politiques de mot de passe, comme les classes de caractères obligatoires ne sont pas prises en charge par défaut, car elles se sont avérées contre-productives. Voir par exemple [Shay et al. 2016]), ainsi que NIST SP 800-63b.

Accès par nos employés

• L'équipe d'Odoo Assistance peut se connecter à votre compte pour accéder aux paramètres liés à votre problème d'assistance. Pour cela, elle utilise ses propres identifiants, pas votre mot de passe (qu'elle n'a aucun moyen de connaître).
• Cet accès spécial du personnel améliore l'efficacité et la sécurité : l'équipe peut immédiatement reproduire le problème que vous rencontrez, vous n'avez jamais besoin de partager votre mot de passe et nous pouvons auditer et contrôler les actions du personnel séparément !
• Notre équipe d'assistance s'efforce à respecter votre vie privée autant que possible et n'accède qu'aux fichiers et paramètres nécessaires pour diagnostiquer et résoudre votre problème.

Sécurité du système

• Tous les serveurs cloud d'Odoo exécutent des distributions Linux renforcées avec des correctifs de sécurité à jour.
• Les installations nous sont spécifiques et minimales afin de limiter le nombre de services qui pourraient contenir des vulnérabilités (pas de stack PHP/MySQL par exemple).
• Seuls quelques ingénieurs de confiance d'Odoo ont l'autorisation de gérer les serveurs à distance - et l'accès n'est possible qu'en utilisant une paire de clés SSH personnelles chiffrées, depuis un ordinateur avec chiffrement de disque.

Sécurité physique

Les serveurs cloud d'Odoo sont hébergés dans des centres de données de confiance dans différentes régions du monde (par ex. OVH, Google Cloud), et ils doivent tous respecter nos critères de sécurité physique :

• Périmètre restreint, physiquement accessible uniquement par les employés autorisés du centre de données.
• Contrôle d'accès physique avec badges de sécurité ou sécurité biométrique.
• Caméras de sécurité surveillant les emplacements des centres de données 24 heures sur 24, 7 jours sur 7.
• Personnel de sécurité sur le site 24 heures sur 24, 7 jours sur 7.

Sécurité des informations bancaires

• Nous ne stockons jamais les informations relatives aux cartes de crédit sur nos propres systèmes.
• Les informations relatives à votre carte de crédit sont toujours transmises de manière sécurisée directement entre vous et nos acquéreurs de paiement conformes aux normes PCI (consultez la liste sur la page relative à notre Politique vie privée ).

Chiffrement des données

• Toutes les communications de données aux instances des clients sont protégées par un chiffrement SSL 256 bits à la pointe de la technologie (HTTPS).
• Toutes les communications de données internes entre nos serveurs sont également protégées par un chiffrement à la pointe de la technologie (SSH).
• Nos serveurs font l'objet d'une surveillance stricte en matière de sécurité et sont toujours corrigés en fonction des dernières vulnérabilités SSL, bénéficiant à tout moment d'une notation SSL de Grade A .
• Tous nos certificats SSL utilisent un module robuste de 2048 bits avec des chaînes de certificats SHA-2 complètes.
• Toutes les données des clients (contenu de la base de données et fichiers stockés) sont chiffrées au repos, à la fois pour les bases de données de production et les sauvegardes (AES-128 ou AES-256)

Défense du réseau

• Tous les fournisseurs de centres de données utilisés par Odoo Cloud disposent de très grandes capacités de réseau et ont conçu leur infrastructure pour résister aux plus grandes attaques par déni de service distribuées (DDoS). Leurs systèmes de mitigation automatiques et manuels sont en mesure de détecter et détourner le trafic d'attaque à la périphérie de leurs réseaux multicontinentaux, avant qu'il ait la possibilité de perturber la disponibilité du service.
• Les pare-feu et les contre-mesures d'intrusion sur les serveurs Cloud d'Odoo aident à détecter et bloquer des menaces, telles que les attaques par force brute des mots de passe.
• Les administrateurs des bases de données clients ont même l'option de configurer la limitation de taux et la durée de refroidissement en cas de tentatives de connexion répétées.

Sécurité du logiciel

Odoo est open source, de sorte que le codebase est constamment examiné par les utilisateurs et les contributeurs d'Odoo dans le monde entier. Les rapports de bogues de la communauté sont donc une source importante de feedback concernant la sécurité. Nous encourageons les développeurs à vérifier le code et à signaler les problèmes de sécurité.

Les processus de R&D d'Odoo comportent des étapes de révision du code qui incluent les aspects de sécurité, pour les nouveaux éléments de code et les éléments de code contribués.

Sécurité par design

Odoo est conçu de manière à éviter l'introduction des vulnérabilités de sécurité les plus courantes :

• Les injections SQL sont empêchées par l'utilisation d'une API de niveau supérieur qui ne nécessite pas de requêtes SQL manuelles.
• Les attaques XSS sont évitées grâce à l'utilisation d'un système de modélisation de haut niveau qui échappe automatiquement aux données injectées.
• Le framework empêche l'accès RPC aux méthodes privées, rendant plus difficile l'introduction de vulnérabilités exploitables.

Consultez également la section sur Les principales vulnérabilités OWASP pour voir comment Odoo est conçu à tous les niveaux pour empêcher l'apparition de telles vulnérabilités.

Audits de sécurité indépendants

Odoo fait régulièrement l'objet d'audits par des sociétés indépendantes qui sont engagées par nos clients et prospects pour effectuer des audits et des tests d'intrusion. L'équipe de sécurité d'Odoo reçoit les résultats et prend le cas échéant les mesures correctives appropriées.

Toutefois, nous ne pouvons pas divulguer ces résultats, parce qu'ils sont confidentiels et appartiennent aux donneurs d'ordre. Merci de ne pas les demander ;-)

Odoo a également une communauté très active de chercheurs de sécurité indépendants, qui surveillent en permanence le code source et travaillent avec nous pour améliorer et renforcer la sécurité d'Odoo. Notre programme de sécurité est décrit sur notre page de Divulgation responsable .

Les principales vulnérabilités OWASP

Voici la position d'Odoo sur les principaux problèmes de sécurité des applications web, tels que répertoriés par Open Web Application Security Project (OWASP) :

• Failles d'injection : Des failles d'injection, telles que l'injection SQL, sont courantes dans les applications web. L'injection se produit lorsque des données fournies par l'utilisateur sont envoyées à un interpréteur en tant qu'élément d'une commande ou d'une requête. Les données hostiles de l'attaquant peuvent duper l'interpréteur afin de l'amener à exécuter des commandes fortuites ou accéder à des données non autorisées.

  Odoo s'appuie sur un cadre de mapping objet-relationnel (ORM) qui abstrait la construction des requêtes et empêche les injections SQL par défaut. Notamment les développeurs ne créent pas de requêtes SQL manuellement, elles sont générées par l'ORM et les paramètres sont toujours correctement échappés.

• Cross Site Scripting (XSS) : Les failles XSS se produisent chaque fois qu'une application prend des données fournies par l'utilisateur et les envoie à un navigateur web sans d'abord valider ou encoder ce contenu. XSS permet à des attaquants d'exécuter des scripts dans le navigateur de la victime afin de détourner des sessions d'utilisateurs, défigurer des sites web, ou rediriger l'utilisateur vers des sites malveillants, etc.

  Le framework Odoo échappe par défaut toutes les expressions rendues dans les vues et les pages, ce qui empêche les XSS. Les développeurs doivent spécialement marquer les expressions comme "sûres" pour les inclure dans les pages rendues.

• Cross Site Request Forgery (CSRF) : Une attaque par falsification de requête intersite force le navigateur d'une victime authentifiée à envoyer une requête HTTP forgée, comprenant le cookie de session de la victime, ainsi que toute autre information automatiquement comprise, à une application web vulnérable. Ceci permet à l'attaquant de forcer le navigateur de la victime à générer des requêtes dont l'application vulnérable pense qu'elles émanent légitimement de la victime.

  Le moteur de site web d'Odoo comprend un mécanisme de protection CRSF intégré. Il empêche tout contrôleur HTTP de recevoir une requête POST sans le jeton de sécurité correspondant. C'est la technique recommandée pour la prévention CSRF. Ce jeton de sécurité n'est connu et présent que lorsque l'utilisateur a réellement accédé au formulaire du site web concerné et un attaquant ne peut pas falsifier une requête sans ce jeton.

• Exécution de fichier malveillant : Un code vulnérable à l'inclusion de fichier à distance (RFI) permet à des attaquants d'inclure du code et des données hostiles, ayant pour résultat des attaques dévastatrices, telle que la compromission totale d'un serveur.

  Odoo n'expose pas de fonctions permettant d'effectuer des inclusions de fichier à distance. Cependant, il permet aux utilisateurs privilégiés de personnaliser les fonctions en ajoutant des expressions personnalisées qui seront évaluées par le système. Ces expressions sont toujours évaluées par un environnement sandbox qui ne permet que l'accès aux fonctions autorisées.

• Référence directe non sécurisée à un objet : Une référence directe à un objet se produit quand un développeur publie une référence à un objet d'exécution interne, tel qu'un fichier, un dossier, un enregistrement de base de données, ou une clé, comme un paramètre d'URL ou de formulaire. Les attaquants peuvent manipuler ces références pour avoir accès à d'autres objets sans autorisation.

  Le contrôle d'accès à Odoo n'est pas mis en œuvre au niveau de l'interface utilisateur. Il n'y a donc aucun risque à exposer des références à des objets internes dans les URLs. Les attaquants ne peuvent pas contourner la couche de contrôle d'accès en manipulant ces références, car chaque requête doit toujours passer par la couche de validation de l'accès aux données.

• Stockage cryptographique non sécurisé : Les applications web utilisent rarement correctement les fonctions cryptographiques pour protéger les données et les droits d'accès. Les attaquants utilisent des données faiblement protégées pour perpétrer un vol d'identité et d'autres crimes, tels que la fraude à la carte de crédit.

  Odoo utilise une fonction de hachage standard sécurisée pour les mots de passe d'utilisateurs ( PBKDF2 + SHA-512 par défaut, avec étirement de clé) pour protéger les mots de passe enregistrés. Il est également possible d'utiliser des systèmes d'authentification externes tels que OAuth 2.0 ou LDAP, afin d'éviter de stocker localement les mots de passe d'utilisateurs.

• Communications non sécurisées : La plupart du temps, les applications ne chiffrent pas le trafic réseau quand il est nécessaire de protéger des communications sensibles.

  Odoo Cloud fonctionne sur HTTPS par défaut. Pour les installations on-premise, il est recommandé d'exécuter Odoo derrière un serveur web mettant en œuvre le chiffrement et envoyant la requête à Odoo, par exemple Apache, Lighttpd ou nginx. Le guide d'implémentation d'Odoo comprend une checklist de sécurité pour des implémentations publiques plus sûres.

• Défaillance dans la restriction des accès URL : Fréquemment, une application protège seulement la fonctionnalité sensible en empêchant l'affichage des liens ou des URLs aux utilisateurs non autorisés. Les attaquants peuvent utiliser cette faiblesse pour accéder et effectuer des opérations non autorisées en accédant à ces URLs directement.

  Le contrôle d'accès d'Odoo n'est pas mis en œuvre au niveau de l'interface utilisateur et la sécurité ne repose pas sur le masquage d'URLs spéciales. Les attaquants ne peuvent pas contourner la couche de contrôle d'accès en réutilisant ou en manipulant n'importe quelle URL, parce que chaque requête doit toujours passer par la couche de validation de l'accès aux données. Dans les rares cas où une URL fournit un accès non autorisé à des données sensibles, comme les URLs spéciales que les clients utilisent pour confirmer une commande, ces URLs sont signées numériquement avec des jetons uniques et uniquement envoyées par e-mail au destinataire prévu.

Signaler les vulnérabilités de sécurité

Si vous devez signaler une vulnérabilité de sécurité, veuillez consulter notre page de divulgation responsable. Ces rapports sont traités avec une haute priorité et le problème est immédiatement évalué et résolu par l'équipe de sécurité d'Odoo, en collaboration avec le rapporteur et ensuite divulgué de manière responsable aux clients et utilisateurs d'Odoo.