En décembre 2019, base de données de documents populaire MongoDB ajouté une nouvelle assez radicale fonctionnalité à la plateforme: chiffrement de la base de données au niveau du terrain. À première vue, on peut se demander s’il s’agit d’une fonctionnalité significative dans un monde qui dispose déjà d’un cryptage de stockage au repos et d’un cryptage de transport en vol, mais après une analyse un peu plus approfondie, la réponse est un oui retentissant.

L’un des premiers clients de MongoDB à utiliser la nouvelle technologie est Apervita, un fournisseur qui traite des données confidentielles pour plus de 2 000 hôpitaux et près de 2 millions de patients individuels. Apervita a travaillé côte à côte avec MongoDB pendant le développement et le raffinement de la technologie.

Depuis sa mise à disposition générale en décembre, la technologie a également été adoptée par plusieurs agences gouvernementales et sociétés du Fortune 50, dont certaines des plus grandes pharmacies et assureurs.

Le chiffrement au niveau du champ en bref

Le cryptage au niveau du champ (FLE) de MongoDB offre la possibilité de stocker certaines parties des données cryptées dans son magasin de documents. La version communautaire (gratuite) de MongoDB permet le chiffrement explicite des champs dans les applications côté client.

Les versions d’entreprise de MongoDB (et de la base de données en tant que service de Mongo, Atlas) prennent également en charge le chiffrement automatique. MongoDB Enterprise et Atlas peuvent également appliquer le chiffrement sur les champs protégés côté serveur, empêchant un développeur d’applications sans aucune idée de stocker accidentellement des données sensibles en texte clair. Les champs chiffrés peuvent être automatiquement déchiffrés lors de la lecture – en supposant que l’application possède la clé – dans les versions gratuites ou d’entreprise.

Mise en place d’un chiffré automatiquement la base de données est un peu trop difficile à fouiller dans le code ici. Mais pour comprendre comment et quand le chiffrement se produit, il peut être utile de jeter un coup d’œil au code Python pour effectuer une seule insertion MongoDB chiffrée explicitement:

# Explicitly encrypt a field:
encrypted_field = client_encryption.encrypt(
    "123456789",
    Algorithm.AEAD_AES_256_CBC_HMAC_SHA_512_Deterministic,
    key_id=data_key_id)

coll.insert_one({"encryptedField": encrypted_field})

L’appel explicite ici indique clairement ce qui se passe: les données sont chiffrées du côté de l’application cliente, puis envoyées et stockées par l’instance de serveur MongoDB. Cela nous donne évidemment la plupart des avantages du cryptage en vol et au repos, mais il y a une autre couche de défense offerte ici qui pourrait ne pas être aussi immédiatement évidente.

Regardons de plus près le problème sysadmin

Les administrateurs système – et les administrateurs de base de données – représentent l’un des problèmes les plus épineux de la confidentialité des données. Un ordinateur a besoin d’un opérateur humain avec tous les privilèges nécessaires pour démarrer, arrêter, maintenir et surveiller les services; cela implique que l’administrateur système ait effectivement accès à toutes les données stockées ou traitées par ce système.

De même, les bases de données, en particulier les bases de données à grande échelle, doivent avoir des administrateurs de base de données. L’administrateur de base de données peut ne pas avoir l’accès racine de bas niveau à un système comme le ferait un administrateur système, mais il a accès au fonctionnement interne de la base de données elle-même. En plus de concevoir la structure initiale de la base de données, un administrateur de base de données doit être en mesure de consigner et de surveiller le moteur de base de données en cours d’exécution, afin d’identifier les «points chauds» dans les données.

Ces points chauds peuvent nécessiter une restructuration ou une indexation pour atténuer les problèmes de performances à mesure qu’ils surviennent. Les dépanner correctement signifiera également fréquemment la nécessité pour un DBA de pouvoir relire les requêtes gênantes, pour voir si les modifications du DBA ont eu un impact positif ou négatif sur les performances.

Le chiffrement au repos ne fait pas grand-chose pour résoudre le problème d’administrateur système ou le problème DBA. Bien que les administrateurs système ne puissent pas obtenir de données significatives en clonant les disques bruts du système, ils peuvent facilement copier les données non chiffrées du système en cours d’exécution une fois que leur stockage a été déverrouillé.

Si la clé de chiffrement du stockage est présente dans le matériel (par exemple, intégrée à un module de plateforme sécurisée (TPM)), elle ne fait rien ou presque pour atténuer le problème d’administrateur système, car l’administrateur système a accès au système en cours d’exécution. Comme nous l’a dit Michael Oltman, directeur technique d’Apervita, « [we’re] pas inquiet de voir quelqu’un sortir d’un centre de données AWS avec notre serveur. « 

Un système de chiffrement au repos qui nécessite un opérateur distant pour déverrouiller le stockage avec une clé fournie au démarrage atténue quelque peu ce problème. Mais un administrateur système local aura probablement encore la possibilité de compromettre la machine en cours d’exécution et la disponibilité peut être affectée, car l’indisponibilité de l’opérateur de clé à distance signifie que les services ne reviendront pas automatiquement après une fenêtre de maintenance impliquant un redémarrage.

Cette incapacité à sécuriser les données privées des administrateurs de système et de base de données rend plus difficile et plus coûteuse la mise à l’échelle d’une grande opération sans potentiellement violer la confidentialité.

Le chiffrement au niveau du champ permet une évolutivité en segmentant l’accès

Maintenant que nous comprenons le problème sysadmin, nous pouvons voir comment le chiffrement au niveau du champ l’atténue. Avec FLE, l’application crypte les données avant de les envoyer à la base de données, et la base de données les stocke exactement telles quelles. De même, lorsque des données chiffrées sont interrogées, elles sont récupérées et renvoyées à l’application toujours chiffrées – le déchiffrement ne se produit jamais au niveau du serveur, et en fait, le serveur n’a pas accès aux clés nécessaire pour le décrypter.

Avec des données cryptées en toute sécurité avant de toucher la base de données et sans jamais être décryptées jusqu’à ce qu’elles arrivent arrière à partir de la base de données – le problème sysadmin est largement résolu, qu’il s’agisse d’administrateurs sys ou d’administrateurs de base de données. Un administrateur système avec un accès root local peut arrêter, démarrer et mettre à niveau les services sans jamais avoir accès aux données, et un administrateur de base de données peut afficher et relire les requêtes en cours sans voir le contenu privé non plus.

Pour être juste, nous n’avons fait que lancer cette boîte un peu plus loin. Administrateurs système et développeurs ayant accès à la production application le serveur peut toujours voir les données qu’il ne devrait pas voir: l’application elle-même doit gérer les données brutes, après tout.

Cependant, la segmentation est toujours significative, car elle permet l’utilisation de services automatiquement provisionnés et surveillés par des tiers comme Atlas de MongoDB. Sans le chiffrement au niveau du champ, HIPAA aurait une journée de terrain avec tout fournisseur qui tenterait de stocker des informations d’intégrité protégées dans un service cloud géré par un tiers.

Avec FLE, cependant, le côté base de données de l’application peut être considéré comme non confidentiel. Cela permet au fournisseur responsable des données de tirer parti de l’expertise concentrée et de haut niveau d’une base de données en tant que fournisseur de services. Le fournisseur réduit également la portée des systèmes et équipements soumis à des règles de sécurité physiques et réseau HIPAA (ou autres lois réglementaires) coûteuses.

Objectifs et méthodes de conception

Il y a au moins deux questions qui devraient toujours être posées sur le chiffrement: quel impact cela a-t-il sur les performances et, plus important encore, est-il vraiment sécurisé? L’objectif de performance de MongoDB pour FLE était un impact de latence de 10% ou moins. Dans les tests internes utilisant des références de base de données standard de l’industrie, l’impact net sur les charges de travail à volume élevé et à lecture intensive était de 5 à 10%.

Tout aussi important, les applications qui n’utilisaient pas de champs cryptés n’ont pas été prises en compte. Les applications qui chiffrent uniquement les données sensibles – par exemple, le chiffrement des numéros de sécurité sociale tout en laissant les noms en texte clair – ont à leur tour moins d’impact que celles qui chiffrent des documents entiers dans leur ensemble.

Lorsque nous avons interviewé Kenn White de MongoDB, il a également souligné que la cryptographie elle-même n’était pas quelque chose de simplement préparé à la volée et en interne. La société a embauché plusieurs équipes d’experts en cryptographie réputés, issus de milieux universitaires et industriels. Il a également commandé un audit tiers du cryptage et de la sécurité des applications auprès de la célèbre société de sécurité Teserakt, qui a récemment retenu l’attention de ses propres Protocole E4, conçu pour fournir un chiffrement en vol aux appareils intégrés.

Au-delà de la bonne cryptographie et des bonnes performances, l’un des objectifs les plus importants que MongoDB avait pour FLE était de s’assurer que tout le monde pouvait l’utiliser, avec un minimum d’obstacles à l’adoption. Cela signifiait la conception d’API personnalisées pour sept des plates-formes de développement d’applications les plus populaires utilisées avec MongoDB, notamment Node.js, Python, Java, .NET et Go.

Conclusions

Bien que nous nous soyons fortement concentrés sur MongoDB ici, ce n’est pas la seule – ni même la première – technologie de base de données fournissant le FLE. Une plateforme de base de données NoSQL concurrente nommée Couchbase mis en œuvre FLE un an plus tôt et Amazon introduit FLE dans son CloudFront DBaaS fin 2017.

Tout comme le hachage unidirectionnel salé est rapidement devenu la norme obligatoire pour le stockage des mots de passe, nous nous attendons à ce que le chiffrement au niveau du champ devienne une fonctionnalité obligatoire pour les bases de données qui gèrent des informations sensibles ou confidentielles et pour les mêmes raisons – en le protégeant non seulement contre les attaquants extérieurs, mais aussi des administrateurs légitimes des systèmes et des infrastructures.