Sécurité & Trust Center

La sécurité de vos données est notre priorité.

Confiance

Notre plateforme de confiance repose sur l'intégration de la sécurité à toutes les étapes du développement et de la livraison des solutions. Nous adoptons des pratiques rigoureuses en matière de sécurité opérationnelle : tests d'intrusion, évaluations de vulnérabilités et contrôles d'accès internes renforcés. Nous pensons que la confiance se gagne par la transparence. Ainsi nous communiquons publiquement sur notre mode opératoire et travaillons en étroite collaboration avec nos clients et partenaires pour répondre à leurs besoins en matière de sécurité. Nous proposons des offres conformes aux standards PCI-DSS, HIPAA et FedRAMP. Nous sommes nous-mêmes conformes aux normes ISO 27001, ISO 27017, ISO 27018 et à SOC 2 Type II.

Engagement contractuel

En plus de la documentation et de bonnes pratiques que vous trouverez sur notre Centre de sécurité et de confiance, nous remettons également à tous nos clients un engagement contractuel de sécurité présenté en termes simples. Cet engagement est consigné dans l'Addendum de sécurité de notre contrat. Il décrit les mesures et les pratiques de sécurité que nous appliquons pour protéger vos données.

Gestion des vulnérabilités

Détecter et corriger rapidement les logiciels vulnérables dont vous avez besoin au quotidien est l'une des missions les plus importantes d'un fournisseur de solutions ou de services. Nous prenons cette responsabilité très au sérieux et nous communiquons nos engagements de délai de correction dans notre Addendum de sécurité.

En interne, nous avons automatisé la gestion des vulnérabilités pour suivre, hiérarchiser et coordonner la correction des vulnérabilités dans notre environnement avec efficacité. Nous procédons quotidiennement à des scans de vulnérabilité authentifiés sur les packages Databricks ainsi que sur les packages tiers et open source que nous utilisons. Nous réalisons également des analyses de code statique et dynamique (SAST et DAST) à l'aide d'outils d'inspection de la sécurité réputés, avant tout passage en production de nouveau code ou de nouvelle image. Databricks fait également appel à des experts indépendants qui analysent nos sites publics et signalent les risques potentiels.

Databricks a fondé le Programme de réponse aux vulnérabilités pour surveiller l'émergence des vulnérabilités avant qu'elles ne soient signalées par nos prestataires d'inspection. Nous nous appuyons pour cela sur des outils internes, les réseaux sociaux, des listes de diffusion et des sources de renseignement sur les menaces (US-CERT et autres flux étatiques, industriels et open source). Databricks surveille les plateformes de vulnérabilités ouvertes comme CVE Trends et Open CVDB. Nous avons établi un processus de réponse qui nous permet d'identifier rapidement l'impact des risques sur notre entreprise, nos produits et nos clients. Dans le cadre de ce programme, nous reproduisons rapidement les vulnérabilités signalées et corrigeons celles en zero-day.

Notre Programme de gestion des vulnérabilités s'engage à traiter dans la plus grande urgence les vulnérabilités de sévérité 0, notamment celles de type zero-day. Leur correction est prioritaire sur tous les autres déploiements.

Tests d'intrusion et bug bounty

Nous effectuons des tests d'intrusion grâce à une équipe de sécurité offensive en interne, des testeurs d'intrusion tiers qualifiés et un programme annuel de bug bounty public. Nous combinons le fuzzing, la revue de code sécurisé et les tests d'applications dynamiques pour évaluer l'intégrité de notre plateforme et la sécurité de notre application. Nous réalisons des tests de pénétration sur nos versions majeures, nos nouveaux services et nos fonctionnalités sensibles sur le plan de la sécurité. L'équipe de sécurité offensive travaille avec notre équipe de réponse aux incidents et nos ambassadeurs de la sécurité au sein de l'ingénierie. Leur objectif commun est de résoudre les problèmes découverts et de partager les enseignements au sein de l'entreprise.

Nous réalisons typiquement 8 à 10 tests de pénétration tiers externes et 15 à 20 tests interne par an. Toutes les découvertes substantielles doivent être traitées avant qu'un test ne puisse être considéré comme réussi. Dans le cadre de notre engagement de transparence, nous partageons publiquement les rapports de tests tiers portant sur notre plateforme au sein de notre liasse de diligence raisonnable (due diligence).

Notre programme de bug bounty public, organisé avec HackerOne, permet à un collectif international de chercheurs en cybersécurité et de pen-testeurs de mettre à l'épreuve la sécurité de Databricks pour détecter des vulnérabilités. Le succès de ce programme s'explique par plusieurs choix stratégiques :

Nous encourageons une communauté motivée de hackers à s'impliquer dans notre programme en communiquant en toute transparence sur les statistiques du programme HackerOne, à commencer par le taux de réponse et les paiements.
Nous répondons rapidement à toutes les soumissions de bugs, et la prime est versée en moins d'une semaine en moyenne.
Nous réalisons des analyses de variantes sur toutes les soumissions valides pour identifier les méthodes alternatives d'exploitation, et nous vérifions 100 % des corrections.
Nous ajoutons des primes pour attirer l'attention sur les domaines les plus importants du produit.

Nous mettons tout en œuvre pour assurer le succès de notre programme et tirer des enseignements de chaque soumission. Grâce à l'approche ouverte et collaborative de notre programme de bug bounty, nous avons récompensé plus de 100 chercheurs en sécurité pour plus de 200 signalements. Merci à tous de nous aider à préserver la sécurité de Databricks !

Nous tenons à ce que nos clients aient toute confiance dans les charges qu'ils exploitent sur Databricks. Si votre équipe souhaite réaliser un scan de vulnérabilité ou un test de pénétration sur Databricks, nous vous suggérons :

D'exécuter des scans de vulnérabilité sur les systèmes du plan de données situés dans votre compte de fournisseur de services cloud.
De réaliser les tests sur votre code, à condition que ces tests soient entièrement contenus dans le plan de données (ou d'autres systèmes) situé dans le compte de votre fournisseur de services cloud et qu'ils évaluent vos propres contrôles.
De rejoindre le programme Bug Bounty Databricks pour accéder à un déploiement dédié de Databricks où vous pourrez effectuer des tests de pénétration. Tout test de pénétration visant notre plan de contrôle multi-tenant nécessite de participer au programme.

Enquêtes de sécurité et réponse aux incidents

Nous utilisons Databricks comme SIEM et plateforme XDR pour traiter plus de 9 téraoctets de données par jour à des fins de détection et d'enquête de sécurité. Nous importons et traitons les logs et les signaux de sécurité de l'infrastructure cloud, des appareils, des systèmes de gestion des identités et des applications SaaS. Nous utilisons des pipelines de streaming structuré et des Delta Live Tables pour identifier les événements de sécurité prioritaires à l'aide d'une approche data-driven et de modèles de ML statistiques. Cela nous permet de produire de nouvelles alertes, mais aussi de corréler, dédupliquer et hiérarchiser les alertes produites par les produits de sécurité connus. Nous modélisons nos runbooks sur les tactiques, techniques et procédures (TTP) adverses, que nous suivons à l'aide du framework MITRE ATT&CK. Notre équipe d'enquête de sécurité utilise des notebooks Databricks collaboratifs pour créer des processus d'investigation reproductibles, améliorer continuellement les playbooks d'enquête et rechercher activement les menaces sur plus de 2 pétaoctets de logs d'événements, en effectuant des recherches complexes sur des données structurées et semi-structurées.

Notre équipe de réponse aux incidents se tient à jour et appuie Databricks dans sa préparation aux scénarios d'incidents de plusieurs façons :

Elle participe à des formations réputées fournies par des prestataires tels que SANS, et assiste à des conférences de sécurité comme fwd:cloudsec, Black Hat, BSides et RSA
Elle effectue régulièrement des exercices théoriques avec les équipes de direction et les équipes internes pour s'entraîner à la gestion des scénarios de réponse qui touchent les produits Databricks et l'infrastructure de l'entreprise
Elle collabore avec les équipes d'ingénierie pour faire de l'observabilité de la plateforme une priorité et améliorer les capacités de détection et de réponse de sécurité
Elle met régulièrement à jour les stratégies de recrutement et de formation sur la base d'une matrice évolutive de compétences et d'aptitudes en réponse aux incidents

Accès interne

Nous appliquons des politiques et des contrôles stricts concernant l'accès des salariés internes à nos systèmes de production et à nos environnements et données clients.

Nous exigeons une authentification multifacteur pour accéder aux consoles d'infrastructure de base comme celles des fournisseurs de services cloud (AWS, GCP et Azure). Les politiques et procédures de Databricks ont pour but d'éviter, dans la mesure du possible, l'utilisation d'identifiants explicites – mots de passe et clés API notamment. Par exemple, seuls les membres de sécurité désignés peuvent traiter les demandes d'exception pour de nouveaux principes ou politiques AWS IAM.

Les collaborateurs de Databricks ont accès au système de production dans des circonstances extrêmement spécifiques (quand une correction est requise en urgence, par exemple). L'accès est encadré par un système développé par Databricks qui applique des vérifications et des contrôles de politique. L'accès nécessite que nos salariés soient connectés à notre VPN et s'authentifient grâce à notre solution Single Sign On avec authentification multifacteur.
En savoir plus →

Nos normes de sécurité internes imposent autant que possible la séparation des tâches. Par exemple, nous centralisons le processus d'authentification et d'autorisation de notre fournisseur d'identité cloud pour séparer l'autorisation d'accès (Marie doit accéder à un système) de l'octroi d'accès (Marie peut désormais accéder à un système).

Nous appliquons strictement le principe de moindre privilège, tant dans les systèmes internes que pour l'accès aux systèmes de production. Le moindre privilège est explicitement intégré à nos politiques internes et se retrouve dans nos procédures. Par exemple, la plupart des clients peuvent décider si les collaborateurs de Databricks ont accès ou non à leur espace de travail. Nous appliquons automatiquement de nombreuses vérifications avant d'accorder l'accès, ce dernier étant automatiquement révoqué après un délai défini.
En savoir plus →

Cycle de vie sécurisé du développement d'une solution

Le cycle de vie du développement logiciel (SDLC) de Databricks intègre la sécurité à toutes les étapes de conception, de développement et de production, depuis les demandes de fonctionnalités jusqu'au monitoring. Il s'appuie sur des outils conçus pour suivre les fonctionnalités tout au long de leur cycle de vie. Des scans de sécurité et des recherches de vulnérabilités sont automatiquement effectués sur nos systèmes, nos bibliothèques et notre code.

Databricks s'appuie sur un Portail d'idées qui centralise le suivi des demandes de fonctionnalités et permet aux clients et aux collaborateurs de voter pour celles qui leur semblent prioritaires. Notre processus de conception des fonctionnalités inclut la confidentialité et la sécurité dès la conception. Après une évaluation initiale, les fonctionnalités à forte incidence sont soumises à un examen de conception de sécurité. Celui-ci est réalisé par l'équipe de sécurité des produits, en collaboration avec les ambassadeurs de la sécurité de l'ingénierie, qui effectueront également une modélisation des menaces et d'autres contrôles en lien avec la sécurité.

Nous utilisons une méthodologie de développement agile et répartissons les nouvelles fonctionnalités en plusieurs sprints. Databricks ne sous-traite pas le développement de sa plateforme. Tous les développeurs doivent suivre une formation sur le développement de solutions sécurisées, couvrant notamment le Top 10 de l'OWASP, au moment de leur embauche et chaque année par la suite. Les environnements et les données de production sont séparés des environnements de développement, d'assurance qualité et de préproduction. Tout le code est enregistré dans un système de contrôle de la source qui exige une authentification Single Sign On multifacteur adossée à des autorisations granulaires. Les fusions de code sont soumises à l'approbation des responsables de l'ingénierie fonctionnelle de chaque domaine concerné, et tout le code fait l'objet d'un examen par les pairs. L'équipe de sécurité des produits examine manuellement le code sensible sur le plan de la sécurité pour éliminer les erreurs de logique métier.

Nous utilisons les meilleurs outils pour identifier le code ou les packages vulnérables. L'automatisation dans un environnement de préproduction exécute des scans de vulnérabilité du système d'exploitation et des packages installés sur l'hôte et le conteneur authentifiés, ainsi que des scans d'analyse de code dynamiques et statiques. Des tickets de data engineering sont créés automatiquement pour toute vulnérabilité et sont assignés aux équipes compétentes. L'équipe de sécurité des produits trie également les vulnérabilités critiques afin d'évaluer leur gravité dans l'architecture Databricks.

Nous effectuons des contrôles de qualité (tests unitaires et tests de bout en bout) à plusieurs étapes du processus SDLC : lors de la fusion du code, après la fusion du code, à la sortie d'une version et en production. Nos tests comprennent des tests positifs, négatifs et de régression. Une fois le déploiement terminé, nous exerçons un monitoring étendu pour identifier les défaillances. Quant aux utilisateurs, ils peuvent recevoir des alertes sur la disponibilité du système via la Page d'état. En cas de problème P0 ou P1, l'automatisation Databricks déclenche une analyse des causes profondes selon la méthodologie des « 5 pourquoi » et désigne un membre de l'équipe postmortem pour superviser l'examen. Les conclusions sont communiquées à la direction. La réalisation des tâches de correction fait l'objet d'un suivi.

Databricks dispose d'un processus de gestion formelle des versions qui comprend un cadre décisionnel de feu vert/feu rouge avant le lancement d'une version de code. Les changements sont soumis à des tests conçus pour éviter les régressions et confirmer que les nouvelles fonctionnalités ont été testées sur des charges de travail réalistes. En outre, le déploiement se fait par étapes, avec un monitoring permettant d'identifier les problèmes à un stade précoce. Pour implémenter la séparation des tâches, seul notre système de gestion des déploiements peut mettre les changements en production. Nous exigeons l'approbation de plusieurs personnes pour tous les déploiements.

Nous suivons le modèle d'infrastructure immuable dans lequel les systèmes sont remplacés plutôt que corrigés. Cette approche améliore la fiabilité et la sécurité, tout en évitant le risque de dérives de configuration. Lors du lancement de nouvelles images système ou d'un nouveau code d'application, nous transférons les charges de travail vers de nouvelles instances comportant le nouveau code. Cela s'applique aussi bien au plan de contrôle qu'au plan de données (voir la section Caractéristiques de sécurité pour en savoir plus sur l'architecture Databricks). Une fois le code en production, un processus de vérification confirme que des artefacts n'ont pas été ajoutés, supprimés ou modifiés sans autorisation.

La dernière phase du processus SDLC est la création de la documentation destinée aux clients. La documentation de Databricks est gérée aussi étroitement que notre code source et conservée dans le même système de contrôle. Les modifications importantes doivent être examinées par les équipes techniques et de documentation avant d'être fusionnées et publiées.
Consulter la documentation →

Informations sur la politique et la communication de sécurité

Databricks respecte les normes RFC 9116, ISO/IEC 30111:2019(E) et ISO/IEC 29147:2018(E) concernant la gestion et la communication des vulnérabilités de sécurité. Pour plus d'informations sur nos communications sécurisées et notre signature PGP, consultez le fichier security.txt.

Signaler un problème