MongoDB rend possible l’interrogation de données chiffrées

Queryable Encryption : une implémentation à l’échelle du chiffrement structuré

Le principe de Queryable Encryption est simple : la fonctionnalité rend possible l’interrogation des données chiffrées. Elle avait été introduite en préversion dans MongoDB 6.0, l’année dernière.

Plus précisément, Queryable Encryption permet à « une application client de chiffrer les données avant de les transporter à travers le réseau, tout en maintenant la possibilité de les interroger ».

Elle se différencie de deux manières par rapport à la fonctionnalité intégrée dans MongoDB 4.2. Cette capacité nommée Client-Side Field Level Encryption (CSFLE) permet, elle aussi, de chiffrer les champs de données côté client avant leur enregistrement dans la base de données. Toutefois, l’interrogation et la lecture des données se font généralement en clair.

Deuxième point d’importance, CSFLE exploite une approche déterministe qui dépend l’implémentation de l’algorithme de chiffrement AES-256-CBC-HMAC-SHA-512. MongoDB a bien tenté d’intégrer une méthode de chiffrement aléatoire, mais elle présente des défauts rédhibitoires.

L’approche aléatoire de CSFLE ne permet pas d’effectuer des opérations de lecture ciblant un champ de données protégé, car elle réclame de chiffrer tout l’objet, rendant impossible l’interrogation des champs imbriqués.

Par ailleurs, tous les opérateurs d’interrogation ne sont pas compatibles avec CSFLE. Si les développeurs pouvaient requêter ces champs chiffrés, ils devaient programmer eux-mêmes les traitements nécessaires.

Queryable Encryption doit surmonter ces limites. La fonction implémente un système nommé OST inspiré du « Structured Encryption » ou chiffrement structuré. Celui-ci est spécialement conçu pour une base de données orientée documents.

Cette méthode permet de chiffrer dynamiquement les structures de données pour les rendre interrogeables « de manière privée ». Elle est beaucoup plus adaptée aux technologies NoSQL que l’étaient les procédés de chiffrement auparavant embarqués dans les SGBD, notent les chercheurs en cybersécurité chez MongoDB dans un article technique publié le 8 août dernier.

« Le chiffrement structuré n’est pas nouveau », résume Kenn White, directeur de la sécurité chez MongoDB, lors d’une conférence ayant eu lieu à New York et retransmise sur YouTube. « C’est une technologie qui existe depuis près de vingt ans. Mais elle n’a pas réellement été déployée à l’échelle dans des systèmes distribués ».

Son fonctionnement s’apparente au chiffrement totalement homomorphe, sans les inconvénients majeurs relevés par le dirigeant. « Le chiffrement totalement homomorphe n’est pas conçu pour permettre la recherche dans une base de données contenant des millions de documents », insiste-t-il.

Dans le cas de MongoDB, quand une application soumet une requête, elle est analysée par les pilotes développés par l’éditeur. Lorsqu’une requête cible un champ chiffré, ces pilotes appellent une clé de chiffrement gérée depuis les KMS d’AWS, Google, d’Azure ou « tout autre fournisseur » exploitant le protocole KMIP.

Le pilote soumet la requête au serveur, en sus d’un token de chiffrement. Le serveur retourne les résultats chiffrés au pilote, puis ils sont déchiffrés côté client, pour être affichés en clair à l’auteur de la requête.

« Les champs chiffrés sont toujours stockés, transmis, traités et retrouvés sous la forme de textes chiffrés, tout comme les requêtes », assure la documentation de MongoDB.

Le chiffrement côté client, « une question de confiance » selon MongoDB

Les serveurs de MongoDB n’échangent pas directement avec le KMS. Les pilotes déployés côté client font office de proxy entre l’application, le KMS et la plateforme de base de données. En clair, les usagers de la DBaaS MongoDB Atlas peuvent stocker leurs données sans que l’éditeur puisse les voir ou y accéder.

« C’est une question de confiance », affirme Kenn White.

« La plupart des clients intéressés par le sujet nous disent : “ce n’est pas que l’on ne vous croit pas, mais ce que nous avons une posture de gestion des risques institutionnelle qui fait que nous ne pouvons pas vous faire confiance, tout comme nous ne pouvons pas faire confiance à nos fournisseurs cloud” ».

C’est pour la même raison que MongoDB MongoDB ne mise pas sur les enclaves sécurisées, comme le fait AWS avec son hyperviseur Nitro. Selon Kenn White, ces enclaves demandent justement l’usage de technologies propriétaires majoritairement maîtrisées par les fournisseurs de cloud. « D’autant que les données et les clés sont disponibles quelque part en clair sur les serveurs du fournisseur et ces enclaves ne sont pas forcément performantes », assène-t-il. 

MongoDB mise sur la gestion automatisée des clés

Encore faut-il savoir déployer Queryable Encryption.

Après avoir configuré la base de données, le KMS et avoir généré une clé maîtresse, les développeurs déploient un client, puis spécifient les champs à chiffrer et les requêtes qui peuvent être effectuées dans une cartographie des champs (encryptedFieldsMap).

Ensuite, ils créent la collection de documents correspondante. L’étape suivante consiste à appeler le KMS pour générer les clés de chiffrement de données nécessaires (DEK). Il faut associer les DEK aux champs de données. Lors de cette opération, deux collections contenant des métadonnées sont automatiquement générées.

Pour que les applications puissent gérer les actions de chiffrement et de déchiffrement, ainsi que les opérations CRUD chiffrées côté client, MongoDB a conçu la librairie libmongocrypt. Écrite en C, elle a été adaptée à douze langages de programmation différents. 

L’éditeur mise surtout sur une méthode de chiffrement automatique qui s’appuie sur la librairie côté client « query analysis shared library ». Ce module est disponible dans les éditions Enterprise et depuis la DBaaS MongoDB Atlas. 

Elle est déployée par les utilisateurs pour écrire en clair les opérations CRUD contre les données chiffrées.

« Par exemple, si l’application insère un nouveau document, la fonctionnalité d’analyse des requêtes utilise le schéma de chiffrement pour déterminer quels champs doivent être chiffrés et marque ces champs en conséquence », précisent les chercheurs en cybersécurité de MongoDB. « La librairie libmongocrypt exploite alors ces marques pour chiffrer et produire les jetons cryptographiques appropriés nécessaires à l’exécution de la requête côté serveur ».

Ces labels, générés pseudo aléatoirement, sont associés à un array présent dans le document. Il est nommé « safecontent » et renvoie à l’une des collections de métadonnées. Les champs sont chiffrés à l’aide de l’algorithme AES256-CBC-SHA256.

C’est à l’aide de la collection de métadonnées et des jetons cryptographiques que le moteur de la base de données (côté serveur donc) peut appliquer les opérations CRUD. Par exemple, pour trouver un document, « le serveur utilise ces jetons avec l’esc [le nom de la collection de métadonnées N.D.L.R] pour générer un ensemble de balises de recherche cryptographiques et renvoie les documents dont l’array safecontent contient l’une de ces balises », expliquent les chercheurs.

Le chiffrement de bout en bout a un prix

Pour autant, Queryable Encryption n’est pas parfait. L’éditeur n’a pas encore implanté la prise en charge des requêtes d’intervalle, de préfixes, de suffixes et de sous-chaînes. Cela fera l’objet d’une future mise à jour.

En outre, la fonctionnalité n’est pas sans incidence sur la performance d’une base de données MongoDB. Elle crée un index pour chaque champ chiffré, « ce qui peut allonger les opérations d’écriture sur ce champ ». Quand une opération d’écriture a lieu, l’index est forcément mis à jour. Aussi, une collection chiffrée entraîne la génération de deux collections de métadonnées supplémentaires, ce qui augmente la quantité de stockage nécessaire.

« En cinq mois, nous avons largement les performances de certaines requêtes », insiste Kenn White.

MongoDB assure que la solution a été formellement et techniquement éprouvée par des spécialistes tiers. « Nous ne dirons jamais que notre système est impénétrable, mais c’est important pour nous que la méthode d’implémentation puisse être accessible à tous », poursuit le directeur de la sécurité.

Enfin, comme MongoDB se décharge beaucoup de la plomberie, c’est véritablement la méthode d’implémentation de Queryable Encryption qui assure le chiffrement de bout en bout des traitements. L’éditeur ne fournit pas toutes les pièces du puzzle.

« Pour sécuriser un déploiement en production, il convient d’utiliser conjointement les mécanismes RBAC, de chiffrement en transit et au repos, et éventuellement [Queryable Encryption ou CSFLE] », précise la documentation de l’éditeur.