La semaine dernière, nous avons annoncé la disponibilité générale de la prise en charge des Requête de préfixe, de suffixe et de sous-chaîne dans MongoDB Queryable Encryption. Ces capacités étendent Queryable Encryption au-delà des Requête d’égalité et de plage, et sont désormais entièrement prises en charge pour les charges de travail de production.
MongoDB Queryable Encryption est une technologie de chiffrement en cours d'utilisation révolutionnaire, première du secteur, développée par le MongoDB Cryptography Research Group. Il permet aux clients de chiffrer les données sensibles de leurs applications, de les stocker sous forme chiffrée dans MongoDB et d'effectuer des requêtes expressives sur ces données chiffrées sans les déchiffrer. La base de données ne voit jamais les données en clair.
Les organisations peuvent désormais effectuer des recherches textuelles flexibles, en faisant correspondre des noms partiels, des mots ou des identifiants sur des données chiffrées en production, tout en préservant les informations sous-jacentes par conception, dans le cadre de garanties de sécurité clairement définies. Cela signifie une protection plus forte des données, une conformité plus simple et aucune nécessité de solutions de contournement telles que des index de recherche externes. Le tout avec un minimum de changements de code et aucune nouvelle infrastructure.
Grâce à la prise en charge des Requête avec préfixe, suffixe et sous-chaîne désormais généralement disponible dans Queryable Encryption, MongoDB permet aux entreprises de protéger leurs données sensibles tout au long de leur cycle de vie : au repos, en transit et en cours d’utilisation. Par conséquent, les équipes peuvent créer des applications sécurisées qui préservent la confidentialité sans compromettre la fonctionnalité. Queryable Encryption est disponible sans coût supplémentaire dans MongoDB Atlas, MongoDB Enterprise Advanced et MongoDB Community Edition.
Le défi : les données ne sont protégées que jusqu'à ce que vous deviez les utiliser
La plupart des organisations stockent des données sensibles : des informations personnellement identifiables (PII) telles que les noms et les numéros de sécurité sociale, ou des informations de santé protégées (PHI) telles que les dossiers médicaux. La sécurisation de ces données au repos ou lors de leur transfert sur un réseau est une pratique bien comprise. Le chiffrement au repos et en transit est une pratique courante aujourd'hui.
La requête sur ces données est une tout autre affaire. Le chiffrement traditionnel rend les données illisibles, ce qui signifie qu’une base de données ne peut pas les rechercher sans les avoir déchiffrées au préalable. Prenons le cas d’un prestataire de soins de santé qui a besoin de trouver tous les patients ayant un diagnostic contenant le mot « œdème » ; sans déchiffrer les dossiers, la base de données ne peut pas rechercher ce terme.
Pour contourner ce problème, de nombreuses organisations laissent les champs sensibles non chiffrés ou construisent des index de recherche externes pour permettre les Requête dont leurs applications ont besoin. Les deux approches ajoutent des frais généraux opérationnels. Les deux augmentent également le risque d’accès non autorisé, précisément au moment où les données sensibles sont les plus exposées.
Cela devient plus difficile sous la pression réglementaire. Des normes telles que la Health Insurance Portability and Accountability Act (HIPAA), la Payment Card Industry Data Security Standard (PCI-DSS) et le General Data Protection Regulation (GDPR) s'attendent de plus en plus à ce que les entreprises démontrent que les données sensibles restent protégées à chaque étape, pas seulement au repos et en transit. La protection des données lorsqu'elles sont activement utilisées est l'élément auquel la plupart des approches de chiffrement ne peuvent pas répondre.
Pour protéger pleinement les données sensibles et répondre aux exigences de conformité, les organisations ont besoin d’un moyen de rechercher des données chiffrées sans les déchiffrer, et sans sacrifier la performance ou ajouter une nouvelle infrastructure.
Protection des données sans exposition
MongoDB Queryable Encryption est conçu pour combler cette lacune. Il maintient les données sensibles chiffrées alors qu'elles sont activement recherchées, l'étape unique que les autres méthodes de chiffrement ne peuvent pas atteindre.
Avec Queryable Encryption, les champs sensibles ne sont jamais stockés, transmis, traités ou renvoyés en texte brut, même sur le serveur de base de données lui-même. Les Requête sont exécutées sur des données chiffrées. Il n'y a pas de déchiffrement et pas de fenêtre où les données sont exposées.
Ceci est possible grâce à Queryable Encryption, qui repose sur un schéma de chiffrement structuré permettant de conserver les données chiffrées pendant le traitement des requêtes sur le serveur à tout moment. Le schéma est totalement open source et vérifiable par des tiers, et ne relève pas d’une simple déclaration de fournisseur. Il s’agit d’une première dans le secteur : aucune autre technologie de base de données n’offre aujourd’hui ce niveau de chiffrement en cours d’utilisation, et cela ne dépend pas de hardware spécialisé comme les enclaves sécurisées.
Les organisations font déjà confiance à Queryable Encryption pour protéger certaines de leurs données les plus sensibles. Les forces de sécurité intérieure françaises (ANFSI) comptent sur elle pour sécuriser les enregistrements sensibles, avec l'appui d'un examen de sécurité de niveau gouvernemental.
Pour les équipes qui traitent des données PII, PHI ou d’autres données réglementées, cela signifie un risque supplémentaire d’exposition des informations sensibles en moins, même de la part d’initiés ayant un accès direct à la base de données.
Une recherche plus expressive, intégrée
Jusqu’à présent, Queryable Encryption prenait en charge les requêtes d’égalité et de plage en disponibilité générale. Cela couvre les correspondances exactes et les recherches numériques délimitées, mais les applications ont souvent besoin de quelque chose de plus flexible : les recherches de noms partiels, la saisie semi-automatique ou le filtrage de mots partiels. Avec la disponibilité générale des Requête de préfixe, de suffixe et de sous-chaîne, cette lacune est désormais comblée.
Voici ce qui est désormais possible directement sur les champs chiffrés :
Les requêtes de préfixes renvoient des documents où une valeur de champ commence par une séquence de caractères spécifique. Par exemple, trouver tous les clients dont le nom de famille commence par « Mac ».
Les Requête de suffixe renvoient les documents dont la valeur de champ se termine par une séquence spécifique. Par exemple, faire correspondre les quatre derniers chiffres d’un numéro de sécurité sociale chiffré.
Les Requête de sous-chaîne renvoient des documents dans lesquels une séquence spécifique apparaît n’importe où dans le champ. La recherche de sous-chaînes couvre les champs courts et structurés jusqu’à 50 caractères, en recherchant des termes de 2 à 6 caractères. Par exemple, rechercher « eng » dans un champ de titre de poste chiffré, correspondant à la fois à « Ingénieur » et à « Responsable de l’ingénierie ».
Les Requête de plage (existantes) renvoient des documents dont la valeur de champ se situe dans une limite inférieure et supérieure spécifiée, comme une plage de salaires chiffrée.
Les requêtes d'égalité (existantes) renvoient des documents où une valeur de champ correspond exactement, comme une adresse e-mail chiffrée spécifique.
Ces types de Requête s'exécutent via le moteur de Requête et les pilotes natifs de MongoDB, les mêmes que ceux utilisés pour tout autre type de Requête. Il n'y a pas d’index de recherche externes à mettre en place, pas de middleware à maintenir et des changements minimes à apporter au code de l’application. Les équipes bénéficient d’une recherche expressive et basée sur des correspondances partielles sur des données chiffrées en utilisant l’architecture qu’elles exécutent déjà.
Une conformité que vous pouvez prouver, pas seulement revendiquer
Répondre aux exigences comme HIPAA, PCI-DSS et GDPR signifie démontrer que les données sensibles sont protégées, pas simplement l'affirmer. C'est difficile lorsque les affirmations de chiffrement ne peuvent pas être vérifiées indépendamment, et encore plus difficile lorsque l'affirmation ne couvre pas les données pendant qu'elles sont activement utilisées.
Queryable Encryption offre aux équipes de conformité et de gestion des risques une réponse défendable. Son schéma de chiffrement structuré est entièrement open source, de sorte que la cryptographie sur laquelle il repose peut faire l'objet d'un examen indépendant plutôt que d'être acceptée sans preuve. Et comme elle protège les données lors du traitement des requêtes, et pas seulement au repos et en transit, elle répond à une étape que la plupart des programmes de conformité ne peuvent pas prendre en compte par ailleurs.
Avec les Requête sur les préfixes, suffixes et sous-chaînes désormais généralement disponibles, cette même preuve s'étend à davantage de cas d'utilisation : recherche partielle de noms et d'e-mails, filtrage de mots partiels dans les champs en texte libre et correspondance partielle d'ID. Le résultat est moins d'écarts d'audit et moins d'outils fragmentés à concilier, que les charges de travail s'exécutent sur site, dans un environnement hybride ou sur plusieurs cloud.
Ce que les équipes peuvent maintenant construire
Avec des Requête de préfixe, de suffixe et de sous-chaîne généralement disponibles dans Queryable Encryption, voici quelques exemples de ce que les organisations peuvent désormais réaliser :
Recherche de PII pour la conformité et la facilité d'utilisation : des réglementations comme GDPR et HIPAA exigent une confidentialité stricte des informations personnelles. Grâce aux Requêtes de préfixe, les équipes peuvent récupérer les utilisateurs par nom de famille ou par préfixe d'e-mail tout en conservant les données sous-jacentes chiffrées. Cela facilite la conformité sans sacrifier la fonctionnalité de recherche.
Filtrage de mots partiels sur les champs structurés : Les champs structurés comme les diagnostics nécessitent souvent une correspondance partielle. Grâce à la prise en charge des requêtes de sous-chaîne, les équipes peuvent rechercher dans un champ de condition de santé chiffré un terme comme « diabet », correspondant à la fois à « diabetes » et à « diabetic ».
Validation d’ID sécurisée : Les flux de travail d’identité reposent souvent sur des identifiants partiels, comme les quatre derniers chiffres d’un numéro de sécurité sociale, d’un numéro national d’assurance ou d’un numéro Aadhaar. Les Requête de suffixe permettent ces recherches sur des champs chiffrés sans révéler les valeurs complètes, réduisant ainsi le risque de fuites de données dans les environnements réglementés.
Gestion des dossiers pour les agences publiques : Les numéros de dossier et les ID de référence dans les applications du secteur public suivent souvent des formats structurés. Les Requête avec préfixe permettent aux agences de récupérer des enregistrements à l’aide de préfixes basés sur la région ou le bureau, comme « NYC- » ou « EUR-, » sans exposer les métadonnées sensibles des dossiers.
Lancez-vous avec Queryable Encryption
Les Requête de préfixe, de suffixe et de sous-chaîne offrent aux équipes un nouveau niveau de flexibilité dans la recherche de données sensibles sans leur demander de choisir entre sécurité et fonctionnalité. Qu’il s’agisse de respecter des exigences de conformité, de réduire la complexité de l’infrastructure ou simplement de créer de meilleures applications, ces fonctionnalités sont prêtes pour la production dès aujourd’hui.
Les requêtes de préfixe, de suffixe et de sous-chaîne offrent aux équipes un nouveau niveau de flexibilité dans la recherche de données sensibles. Ces nouveaux types de requêtes contribuent à protéger les données sensibles contre les accès non autorisés et à respecter les exigences de conformité, tout en réduisant la complexité de l’infrastructure et des opérations.
Pour aller plus loin
Pour en savoir plus sur Queryable Encryption et son fonctionnement, consultez la page des fonctionnalités de Queryable Encryption. Pour commencer, consultez le Guide de démarrage rapide.