Se préparer pour son premier déploiement MongoDB : Sauvegarde et Sécurité

Dans la première partie de ce duo d'articles[en], nous avons étudié les différents concepts des bases de données relationnelles qui peuvent être directement appliqués à MongoDB, mais aussi le choix du matériel et les bonnes pratiques en termes de déploiement et de monitoring.

Dans cet article, nous allons nous concentrer sur la protection de votre déploiement grâce à des outils de sauvegarde et des politiques de sécurité.

MongoDB Backup et Restore

Il y a trois approches principales pour sauvegarder une base de données MongoDB :

• La sauvegarde dans le cloud via MongoDB Management Service (MMS)
• Faire des captures du système de fichiers
• Utiliser l'outil mongodump fourni avec MongoDB

Sauvegarde via MongoDB Management Service (MMS)

Au-delà des capacités de monitoring discutées précédemment, MMS offre une solution intégrée et dématérialisée de sauvegarde dans le cloud, qui est hébergée dans des datacenters fiables, répliqués et sécurisés.

L'agent de sauvegarde MMS est installé localement avec le cluster MongoDB et effectue une première synchronisation. Puis il envoie ensuite à MMS les données de l'oplog de MongoDB, chiffrées et compressées (utilisé dans les réplicats MongoDB). Des captures sont faites toutes les 6 heures.

La sauvegarde MMS est la seule solution qui supporte la restauration à un instant T pour les réplicats et les captures de clusters shardés. Les données d'Oplog des dernières 24 heures sont stockées et peuvent être rejouées pour créer une capture d'un réplicat. Pour les clusters shardés, le "balancer" est mis en pause toutes les 6 heures et un jeton de no-op est inséré sur tous les shards, mongo et serveurs de configuration. L'oplog peut être appliqué à tous les réplicats du cluster jusqu'au moment de l'insertion du jeton, permettant ainsi de recréer une catpure homogène sur tout le cluster.

Pour restaurer vos données, les captures sont envoyées par SCP directement à votre serveur ou peuvent être téléchargées via une url personnalisée. MMS impose une authentification en deux étapes pour toutes les restaurations.

Pour plus de détails sur le service de sauvegarde MMS, vous pouvez consulter la documentation sur le site de MongoDB.

Les sauvegardes sur le système de fichiers

Les sauvegardes du système de fichiers comme celui proposé par Linux LVM permettent de créer rapidement et efficacement des captures du système de fichiers qui peuvent être copiées pour la sauvegarde et restaurées si nécessaires. Pour plus d'information sur la sauvegarde via la capture du système de fichiers vous pouvez regarder la documentation sauvegarde et restauration de captures du système de fichiers.

mongodump

mongodump est un outil livré avec mongoDB qui permet de sauvegarder en temps réel les données de mongoDB. mongodump peut être utilisé pour récupérer la totalité d'une base de données, une collection ou simplement le résultat d'une requête. mongodump peut créer une capture des données qui reflète un instant précis dans le temps via une copie de l' oplog pour ensuite pouvoir le rejouer durant un mongorestore, qui est un outil pour importer des données d'une base BSON préalablement exportées via mongodump. mongodump fonctionne aussi pour les fichiers de bases de données inactives.

Pour plus d'information sur les sauvegardes, vous pouvez consulter la page Stratégies de Sauvegardes et Restauration sur le site de mongoDB.

Sécurité

Comme pour tout logiciel, les administrateurs mongoDB doivent envisager les problématiques de sécurité et l'exposition aux risques de tout déploiement mongoDB. Il n'y a pas de solution miracle qui protège de tous les risques et le maintien de la sécurité d'un déploiement mongoDB est un travail quotidien.

La protection en profondeur

Une approche de protection en profondeur est recommandée pour sécuriser ses déploiements mongoDB. Cette méthode regroupe en fait plusieurs méthodes de gestion du risque et de réduction de l'exposition au risque.

L'idée d'une approche en profondeur est de construire un environnement en couche pour s'assurer qu'il n'y a pas de point unique d'échec qui soit exploitable et qui pourrait permettre à un intrus ou à un tiers d'accéder aux données stockées dans mongoDB. La façon la plus efficace de réduire le risque est alors d'utiliser MongoDB dans un environnement contrôlé, de limiter les accès, d'utiliser un système de privilèges minimum, de mettre en place un processus de développement sécurisé et de suivre les bonnes pratiques de déploiement.

Toute base de données qui gère des informations sensibles doit mettre en place une approche "holistique" de la sécurité :

• Gestion des droits des utilisateurs pour réduire au maximum l'accès aux données sensibles, via des mécanismes d'authentification et de contrôle des autorisations;
• Tracer les opérations d'authentification à la base de données;
• Protection des données par chiffrement des données sur le réseau et de celles persistées;
• Contrôle de l'environnement et des processus.

MongoDB 2.4 a apporté plusieurs nouvelles fonctionnalités pour résoudre les problématiques mentionnées ci-dessus et MongoDB 2.6 continue d'enrichir ces possibilités. Une version développeur de MongoDB Enterprise 2.6 est déjà disponible.

Authentification

L'authentification d'entités accédant à MongoDB peut être gérée depuis la base de données elle-même ou via des mécanismes externes comme Kerberos services pour MongoDB Enterprise 2.4 ou LDAP ou encore Windows Active Directory et x.509 certification authorities si vous utilisez MongoDB 2.6.

Autorisation

MongoDB permet aux administrateurs de définir les permissions d'une application ou d'un utilisateur et les données accessibles lors des requêtes. MongoDB possède déjà plusieurs rôles prédéfinis, et avec MongoDB 2.6 arrive la possibilité de configurer des rôles au niveau de l'utilisateur. Par exemple, certains utilisateurs peuvent avoir le droit de voir un enregistrement mais ne pourront ni le mettre à jour ni le supprimer.

MongoDB 2.6 offre également une sécurité au niveau des champs pour gérer plus finement les autorisations d'accès aux données sensibles, avec la capacité de définir des politiques de sécurité déclaratives qui seront implémentées lors de l'exécution. Grâce au contrôle au niveau des champs d'un document, un même document décrivant une ressource peut avoir plusieurs niveaux de sécurité. Cela permet d'éviter d'avoir à séparer une même donnée sur plusieurs bases.

Audit

MongoDB 2.6 apporte le support de la journalisation des actions administratives effectuées sur la base par le biais d'un journal d'audit. Par souci de simplicité, les journaux d'audit distribués sur un cluster MongoDB peuvent être fusionnés en un seul, permettant par la même occasion d'associer des évènements liés à une même opération et affectant plusieurs noeuds.

Chiffrement

MongoDB offre la possibilité de chiffrer les données en transit sur le réseau et persistées dans des stockages permanents.

Le support de SSL permet aux clients de se connecter à MongoDB via un canal de communication chiffré. MongoDB supporte aussi le chiffrement FIPS 140-2 s'il est lancé en mode FIPS avec un module cryptographique FIPS validé.

Il y a plusieurs façons de chiffrer des données stockées avec MongoDB. Une solution est de chiffrer la donnée au niveau des champs dans la couche applicative, en utilisant le type de chiffrement souhaité.

Une autre possibilité est d'utiliser des bibliothèques tierses comme NcryptFS et LUKS qui offrent un chiffrement au niveau disque pour Linux, de manière intégrée au noyau du système d'exploitation, ce qui donne accès à des fonctionnalités avancées de gestion de clés et qui assure que seuls les processus autorisés pourront accéder à la donnée. On trouve aussi des solutions pour Windows telles qu'IBM Guardium Data Encryption, BitLocker Drive Encryption et TrueCrypt.

Ci-dessous, une liste des étapes clés pour mettre en place un déploiement sécurisé :

Injection de requêtes

Lorsqu'un programme client crée une requête mongoDB, il construit un objet BSON et non une String. Par conséquent, les injections SQL classiques ne devraient pas poser de problèmes pour les requêtes soumises sous forme d'objets BSON.

Cependant, plusieurs opérations MongoDB autorisent l'évaluation d'expressions Javascript arbitraires et il faut être vigilant dans ces cas-là. Heureusement, la plupart des requêtes sont exprimées en BSON et dans les cas où Javascript est nécessaire, il est possible de faire un mélange de Javascript et de BSON, de façon à ce que les valeurs saisies par un utilisateur soient interprétées comme de simples valeurs et non comme du code.

Conclusion

Les utilisateurs de MongoDB utilisent les bonnes pratiques discutées dans cet article et le précédent[en] pour maintenir le niveau de haute disponibilité, de sécurité et de scalabilité des opérations métiers du marché.

Ces bonnes pratiques sont détaillées dans le MongoDB Operations Guide (ouvrir le document PDF).

À propos de l'auteur

Mat Keep (@matkeep) fait partie de l'équipe marketing de MongoDB et est responsable de la vision, du positionnement et du contenu des produits et services MongoDB. Cela inclut les analyses de tendances des marchés et les demandes utilisateur. Avant MongoDB, Mat était directeur de la gestion produit chez Oracle Corp. et responsable de la base de données MySQL dans le web, les télécoms, le cloud et le big data. Cela fait suite à une série de ventes, de développements métiers et de postes d'analyste/programmeur chez des clients finaux ainsi que vendeurs de technologie.