Transactions distribuées, chiffrement des champs, nouvel Opérateur Kubernetes... avec MongoDB 4.2, le leader des bases de données généralistes franchit un nouveau cap

Les transactions distribuées étendent les garanties de cohérence des transactions multi-documents ACID, des replica sets jusqu'aux clusters shardés. Cette nouveauté élargit considérablement les cas d'usage dans la mesure où les garanties transactionnelles sont assurées sur des applications hyperscale à l'échelle mondiale. Le chiffrement des champs permet aux utilisateurs de crypter les données de leur serveur (stockées en mémoire, dans les logs systèmes, sur disque actif et dans des sauvegardes) afin de les rendre illisibles à quiconque ne dispose pas d'un accès client ou des clés de déchiffrement. De son côté, le plan de contrôle Kubernetes laisse aux utilisateurs la liberté de gérer l'intégralité de leur déploiement MongoDB de façon totalement homogène, sur site ou sur un cloud privé, public ou hybride.

« Nous avons créé MongoDB dans le but de simplifier le travail de la data pour les développeurs, et ce n'importe où dans la stack », rappelle Eliot Horowitz, CTO et co-fondateur de MongoDB. « C'est une réelle fierté pour nous de pouvoir leur proposer de nouvelles fonctionnalités qui boostent leur productivité en leur permettant de passer moins de temps aux prises avec les données et plus de temps sur le développement d'applications de qualité. Le mieux dans tout cela, c'est que ces fonctionnalités sont très semblables aux outils qu'ils utilisent déjà. Ils bénéficient donc d'une expérience nettement améliorée avec une prise en main très courte ».

Transactions distribuées

Dans la version 4.0, MongoDB avait intégré les transactions multi-documents ACID. L'objectif était alors d'offrir une vue cohérente des données sur tous les replica sets, ainsi qu’une exécution « tout-ou-rien » assurant l’intégrité des données. Mais grâce à son modèle orienté documents et son architecture de systèmes distribués, ils peuvent facilement transformer leurs applications d'ancienne génération et créer de nouveaux services transactionnels. Les transactions distribuées présentent la même syntaxe que celles introduites sous MongoDB 4.0. Elles sont multi-instructions et appliquent l’isolement de snapshot, ce qui facilite la prise en main pour tout développeur habitué au format transactionnel. L'API et le processus d'implémentation sont les mêmes, qu'il s'agisse d'exécuter les transactions sur des collections, documents et bases de données, ou bien à l'échelle de clusters shardés. Enfin, l'atomicité reste complète : si une transaction échoue sur un shard, elle sera annulée sur tous les shards participants.

Sécurité d'entreprise : MongoDB monte d'un cran

Avec le chiffrement des champs (FLE), MongoDB choisit une approche plus complète qui se démarque du chiffrement « en colonne » propre aux bases de données relationnelles d'ancienne génération. En plus d'être totalement indépendant de la base de données, le FLE est transparent pour le serveur et n'est géré que sur les pilotes MongoDB du client. Actuellement, la plupart des bases de données gèrent le chiffrement côté serveur, ce qui veut dire que les données restent accessibles aux administrateurs qui possèdent un accès à l'instance elle-même, même s'ils n'ont aucun droit d'accès client. Avec le FLE, ce n'est plus le cas.

Le chiffrement FLE de MongoDB apporte de nombreux avantages :

Cryptage automatique et transparent – Le code applicatif peut s'exécuter sans modification pour la plupart des opérations de lecture et écriture. D'autres approches client-side peuvent imposer une modification du code de requête pour utiliser des méthodes et fonctions de chiffrement explicites adaptés au SDK.

Séparation des tâches – Les administrateurs systèmes, qui disposent généralement d'un accès aux systèmes d'exploitation et aux serveurs, logs et sauvegardes de la base de données, n'ont aucune possibilité de lire les données chiffrées sans accès client explicite ni clé de déchiffrement.

Conformité réglementaire – Il vous suffit de détruire la clé d'un client pour rendre ses données confidentielles totalement inutilisables. Vous respectez ainsi le principe du « droit à l'oubli » propre aux règlementations sur la protection des données personnelles, notamment le RGPD.

« Pour l'occasion, nous avons fait appel à deux des plus grands spécialistes mondiaux de la cryptographie de bases de données, dont un des auteurs du rapport préliminaire d'IETF Network Working Group sur le cryptage AES authentifié pour le développement du chiffrement des champs », déclare Lena Smart, RSSI chez MongoDB. « Fort d'un corpus de recherches universitaires et sectorielles, ces équipes nous ont aidé à définir les orientations conceptuelles du chiffrement FLE sur MongoDB et ont supervisé l'implémentation du logiciel dédié ».

Un contrôle intégral depuis un plan Kubernetes unique

Désormais, les utilisateurs peuvent gérer leur déploiement MongoDB avec un seul et même plan de contrôle Kubernetes. Pour la gestion et l'automatisation des clusters MongoDB sur des infrastructures gérées en interne (sur site ou dans le cloud), les utilisateurs Kubernetes peuvent recourir à MongoDB Enterprise Operator for Kubernetes et à MongoDB Ops Manager. Les développeurs peuvent utiliser l'Opérateur Kubernetes sur l'upstream Kubernetes bien entendu, mais aussi sur des distributions répandues comme Red Hat OpenShift ou Pivotal Container Service (PKS).