Sécurité – Yesbabylon

1. Yesbabylon Cloud Platform (hosting)

Backups / Disaster Recovery

Nous conservons 14 sauvegardes complètes de chaque base de données jusqu’à 3 mois : 1/jour pendant 7 jours, 1/semaine pendant 4 semaines, 1/mois pendant 3 mois.
Vous pouvez télécharger des sauvegardes manuelles de vos données en direct à tout moment à l’aide du panneau de contrôle.
Vous pouvez contacter notre service d’assistance pour obtenir une sauvegarde manuelle, ou pour restaurer une sauvegarde (sur votre instance de production, ou de staging).
Basculement matériel : pour les services hébergés sur bare metal, où une panne matérielle est possible, nous mettons en place une réplication locale de secours à chaud, avec une surveillance et une procédure de basculement manuel qui prend moins de 5 minutes.
Pour la reprise après sinistre en cas de sinistre complet, avec un centre de données entièrement indisponible pendant une période prolongée, nous avons les objectifs suivants :
- RPO (Objectif de point de récupération) = 24h. Cela signifie que vous pouvez perdre au maximum 24h de travail si les données ne peuvent pas être récupérées et nous devons restaurer votre dernière sauvegarde quotidienne.
- RTO (Recovery Time Objective) = 24h. C’est le temps de rétablir le service dans un datacenter différent si un sinistre survient et qu’un datacenter est complètement indisponible.

Sécurité de la base de données

Les données clients sont stockées dans une base de données dédiée (chaque instance est cloisonnée et il n’y pas de partage de données entre clients).
Les règles de contrôle d’accès aux données implémentent une isolation complète entre les bases de données client fonctionnant sur le même cluster, aucun accès n’est possible d’une base de données à l’autre.

Sécurité du mot de passe

Les mots de passe des clients sont protégés par le cryptage standard BCRYPT/BLOWFISH (+ salt 128 bits).
Le personnel de Yesbabylon n’a pas accès à vos mots de passe, et ne peut donc pas les récupérer pour vous, la seule option si vous perdez un mot de passe est de le réinitialiser.
Les identifiants de connexion sont toujours transmis de manière cryptée via HTTPS (http + SSL).
Les administrateurs de base de données ont la possibilité de configurer la limitation du débit et la durée de blocage pour les tentatives de connexion répétées ;
Politiques de mot de passe : les administrateurs disposent d’un paramètre intégré pour appliquer une stratégie de mot de passe utilisateur (simple : longueur minimale, ou stricte : NIST).

Accès du personnel

Le personnel du service d’assistance Yesbabylon peut se connecter à votre compte pour accéder aux paramètres liés à votre problème d’assistance. Pour cela, ils utilisent leurs propres informations d’identification spéciales (et non votre mot de passe qu’ils n’ont aucun moyen de connaître).
Cet accès spécial du personnel améliore l’efficacité et la sécurité : ils peuvent reproduire immédiatement 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 de respecter la privacité de vos données 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 Yesbabylon Cloud exécutent des distributions Linux renforcées avec des correctifs de sécurité à jour.
Les installations sont ponctuelles et minimales pour limiter le nombre de services pouvant contenir des vulnérabilités.
Seuls quelques ingénieurs Yesbabylon de confiance ont l’autorisation de gérer les serveurs à distance – et l’accès n’est possible qu’à l’aide d’une paire de clés SSH personnelle cryptée, à partir d’un ordinateur avec cryptage complet du disque.

Sécurité physique

Les serveurs Yesbabylon Cloud sont hébergés dans des centres de données de confiance dans différentes régions du monde (par exemple OVH, Google Cloud, Amazon AWS), et ils doivent tous répondre à nos critères de sécurité physique :

Périmètre restreint, accessible physiquement uniquement aux 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 24h/24 et 7j/7.
Personnel de sécurité sur place 24h/24 et 7j/7.

Sécurité des cartes de crédit

Les informations de carte de crédit ne sont jamais stockées sur les systèmes Yesbabylon.
En cas de paiement, les informations de carte de crédit sont toujours transmises en toute sécurité directement entre vous et nos acquéreurs de paiement PCI-Compliant.

Communication

Toutes les communications de données vers les instances clientes sont protégées par un cryptage SSL 256 bits (HTTPS).
Toutes les communications de données internes entre nos serveurs sont également protégées par cryptage (SSH).
Nos serveurs sont soumis à une surveillance de sécurité stricte avec les derniers correctifs de vulnérabilités SSL.
Tous nos certificats SSL utilisent un module robuste de 2048 bits avec des chaînes de certificats SHA-2 complètes, bénéficiant d’un classements SSL de grade A.

Défense du réseau

Tous les fournisseurs de centres de données utilisés par Yesbabylon Cloud disposent de très grandes capacités réseau et ont conçu leur infrastructure pour résister aux plus grandes attaques par déni de service distribué (DDoS). Leurs systèmes mitigation automatiques et manuels peuvent détecter et détourner le trafic d’attaque à la périphérie de leurs réseaux multicontinentaux, avant qu’il n’ait la possibilité de perturber la disponibilité des services.
Les pare-feu et les systèmes de prévention des intrusions sur les serveurs Yesbabylon Cloud aident à détecter et à bloquer les menaces telles que les attaques par mot de passe par force brute (fail2ban).
Les administrateurs de base de données ont la possibilité de configurer la limitation du débit et la durée de blocage pour les tentatives de connexion répétées.

2. Yesbabylon Symbiose (software)

Sécurité logicielle

Le logiciel Symbiose est open source, donc l’ensemble de la base de code est continuellement examiné par les contributeurs du monde entier. Les rapports de bogues de la communauté sont une source importante de commentaires concernant la sécurité. Nous encourageons les développeurs à auditer le code et à signaler les problèmes de sécurité.

Les processus de R&D de Yesbabylon comportent des étapes de revue de code qui incluent des aspects de sécurité pour les nouveaux extraits de code.

Sécurisé par conception

Symbiose est conçu de manière à empêcher l’introduction des vulnérabilités de sécurité les plus courantes :

Les injections SQL sont évitées grâce à l’utilisation d’une API de niveau supérieur qui ne nécessite pas de requêtes SQL manuelles.
Les attaques XSS sont empêchées par l’utilisation d’un système de modèles de haut niveau qui échappe automatiquement les données injectées.
Le framework empêche l’accès non-authentifié aux contrôleurs privés, et limite l’accès aux contrôleurs protégées en fonction des groupes d’utilisateurs, ce qui rend plus difficile l’introduction de vulnérabilités exploitables.

Principales vulnérabilités OWASP

Voici où Symbiose se positionne par rapport aux principaux problèmes de sécurité pour les applications Web, tels que répertoriés par le Open Web Application Security Project (OWASP) :

Failles d’injection : Les failles d’injection, en particulier 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 dans le cadre d’une commande ou d’une requête. Les données malveillantes de l’attaquant incitent l’interpréteur à exécuter des commandes involontaires ou à modifier des données.

Symbiose s’appuie sur un framework utilisant un ORM (Object Relational Mapping) qui intercepte la création de requêtes et empêche nativement les injections SQL. Les développeurs n’utilisent normalement pas les requêtes SQL manuellement, elles sont générées par l’ORM et les paramètres sont systématiquement échappés.

Cross Site Scripting (XSS) : Des failles XSS se produisent lorsqu’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 aux attaquants d’exécuter des scripts dans le navigateur de la victime qui peuvent détourner des sessions utilisateur, défigurer des sites Web, éventuellement introduire des vers, etc.

Symbiose échappe toutes les expressions rendues dans les vues et les pages par défaut, empêchant XSS. Les développeurs doivent spécialement marquer les expressions comme « sûres » pour une inclusion brute dans les pages rendues.

Cross Site Request Forgery (CSRF) : Une attaque CSRF force le navigateur d’une victime connectée à envoyer une requête HTTP falsifiée, y compris le cookie de session de la victime et toute autre information d’authentification incluse automatiquement, à une application Web vulnérable. Cela permet à l’attaquant de forcer le navigateur de la victime à générer des requêtes que l’application vulnérable considère comme des requêtes légitimes de la part de la victime.

Exécution de fichiers malveillants : Le code vulnérable à l’inclusion de fichiers à distance ou Remote File Inclusion (RFI) permet aux attaquants d’inclure du code et des données hostiles, ce qui entraîne des attaques dévastatrices, telles que la compromission totale du serveur.

Symbiose n’expose pas de fonctions pour effectuer l’inclusion de fichiers à distance. Cependant, il permet aux utilisateurs privilégiés de personnaliser les fonctionnalités en ajoutant des expressions personnalisées qui seront évaluées par le système. Ces expressions sont toujours évaluées par un environnement en bac à sable et nettoyé qui n’autorise l’accès qu’aux fonctions autorisées.

Référence d’objet directe non sécurisée : Une référence d’objet directe se produit lorsqu’un développeur expose une référence à un objet d’implémentation interne, tel qu’un fichier, un répertoire, un enregistrement de base de données ou une clé, en tant qu’URL ou paramètre de formulaire. Les attaquants peuvent manipuler ces références pour accéder à d’autres objets sans autorisation.

Le contrôle d’accès Symbiose n’est pas implémenté au niveau de l’interface utilisateur, il n’y a donc aucun risque à exposer des références à des objets internes dans les URL. Les attaquants ne peuvent pas contourner la couche de contrôle d’accès en manipulant ces références, car chaque demande passe systématiquement par la couche de validation d’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 informations d’identification. Les attaquants utilisent des données faiblement protégées pour commettre des vols d’identité et d’autres délits, tels que la fraude par carte de crédit.

Symbiose utilise le hachage sécurisé standard de l’industrie pour les mots de passe des utilisateurs (par défaut BLOWFISH, avec extension de clé) pour protéger les mots de passe stocké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 les mots de passe des utilisateurs localement.

Communications non sécurisées : les applications échouent fréquemment à chiffrer le trafic réseau lorsqu’il est nécessaire de protéger les communications sensibles.

YesBabylon Cloud fonctionne sur HTTPS par défaut. Pour les installations on-premise, il est recommandé d’exécuter Symbiose derrière un serveur Web implémentant les requêtes de cryptage et de proxy, par exemple Apache, Lighttpd ou nginx.

Échec de la restriction de l’accès aux URL : Souvent, une application ne protège que les fonctionnalités sensibles en empêchant l’affichage de liens ou d’URL 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 directement à ces URL.

Le contrôle d’accès Symbiose n’est pas implémenté au niveau de l’interface utilisateur et la sécurité ne repose pas sur le masquage d’URL 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, car chaque requête doit toujours passer par la couche de validation d’accès aux données. Dans les rares cas où une URL fournit un accès non authentifié à des données sensibles, telles que les URL spéciales utilisées par les clients pour confirmer une commande, ces URL sont signées numériquement avec des jetons uniques et envoyées uniquement par e-mail au destinataire prévu et on toujours une validité limitée dans le temps.

Signalement des vulnérabilités de sécurité

Si vous pensez avoir découvert une faille de sécurité et que vous souhaitez la signaler, contactez nos services via l’adresse cloud.security@yesbabylon.com. Ces signalements sont traités en priorité. En cas de problème avéré, la faille est immédiatement évaluée et résolue par l’équipe de sécurité de Yesbabylon, en collaboration avec le déclarant, puis divulgué de manière responsable à nos clients.