Sécurité et sauvegarde dans MongoDB

Lors de l'établissement de notre service dans un environnement de production ou peut-être dans un environnement de développement avec plusieurs utilisateurs, la première chose que nous devons faire est de créer un schéma de sécurité, cela nous permet d'empêcher notre Base de données sont accédés par des personnes de manière incorrecte.
La caractéristique principale de MongoDB c'est que lors de l'installation d'une instance elle s'exécute sans avoir créé aucun type de mesure d'authentification, c'est comme ça pour faciliter le démarrage du développement, mais il arrive un moment où il faut sécuriser notre infrastructure.
Un autre point important lié à la question de la sécurité et de la sauvegarde de nos données, c'est quand nous devons faire une sauvegarde d'un certain moment, mais nous ne voulons pas qu'il y ait de mouvement de données, car de cette façon nous garantissons l'intégrité de notre Base de données et collections de documents. Dans cet aspect, il existe également un outil au sein de MongoDB cela nous permet de le bloquer temporairement pour nous assurer que ce que nous copions est approprié.
ExigencesLes exigences dont nous avons besoin à cette occasion sont très simples, nous devons simplement avoir une instance de MongoDB installé et exécuté sur notre système, nous aurons également besoin d'accéder au service via la console. Ce tutoriel a été développé en les fenêtres, donc certaines commandes peuvent changer dans d'autres systèmes d'exploitation, mais tout a à voir avec ce qui est fait en dehors de la console MongoDB, et la façon dont nous exprimons les routes.
La définition des paramètres d'authentification de l'utilisateur n'est pas vitale pour le fonctionnement de MongoDB en production, puisque nous pouvons installer le service de manière à ce que l'équipement sur lequel il fonctionne dispose d'un filtre de connexion, donc si nous essayons d'accéder audit équipement en dehors du réseau, nous n'y aurons pas accès.
Cette approche simpliste de la sécurité est très efficace, mais uniquement pour les projets où le service n'est pas partagé avec d'autres équipes, car si nous avons différentes équipes de développement travaillant sur le même serveur, nous avons besoin d'autre chose. C'est là que le authentification, avec lui nous nous chargeons de demander un utilisateur et un mot de passe par collection si nous le souhaitons, ainsi nous avons la possibilité de séparer adéquatement les différentes instances pour chaque ordinateur.
Les deux mesures de sécurité ne sont pas exclusives et si nous voulons les utiliser simultanément, nous créons un service beaucoup plus sécurisé pour notre environnement, qu'il s'agisse de production, de pré-production ou de développement multi-équipes.
La authentification dans sa forme la plus basique, il est obtenu avec la commande Créer un utilisateur Ceci doit être exécuté lorsque nous avons sélectionné le Base de données administrateur c'est là que nos utilisateurs devraient être.
Il est important de noter que depuis la version 2.6 de MongoDB est que la méthode a commencé à être utilisée Créer un utilisateur, dans le passé tout était résolu par la méthode ajouter un utilisateurCependant, la modification a été apportée pour permettre une plus grande polyvalence lors des modifications.
Voyons comment nous pouvons définir un utilisateur administrateur puis un utilisateur qui ne peut lire que la base de données test.
La structure du document qui reçoit la méthode Créer un utilisateur est la suivante:

 {"User": "username", "pwd": "password", "roles": [{"role": "", "db": ""},]}

Comme nous l'avons noté, nous devons établir le nom et le mot de passe de l'utilisateur que nous créons, mais en plus de cela, nous devons également créer les rôles, qui est une structure d'autorisation qui nous permettra de définir les pouvoirs que nous donnons à l'utilisateur .
Dans l'exemple suivant, nous allons créer un utilisateur administrateur qui a accès à tous les Base de données et qui peut contrôler le service, pour cela nous utiliserons le les rôles:

• clusterAdmin
• readAnyDatabase
• lire écrire

Avec ces trois paramètres, nous pouvons déjà avoir notre premier utilisateur à gérer. Voyons à quoi cela ressemble sur console :

Avec cela, nous avons déjà créé notre utilisateur administrateur avec succès, maintenant nous devons nous souvenir correctement du nom d'utilisateur et du mot de passe car la prochaine étape que nous allons faire est d'activer la sécurité, pour cela nous devons démarrer le service avec le paramètre -auth.
Lors du redémarrage du service, nous pouvons alors placer notre utilisateur administrateur nouvellement créé et pour le tester, nous allons créer un utilisateur qui ne peut lire que le Base de données. Voyons comment redémarrer le service dans les étapes suivantes.
Nous devons simplement l'arrêter d'abord, par exemple dans les fenêtres on se positionne sur la console dans laquelle il tourne et on appuie sur les touches CTRL + C. Puis on recommence notre service normalement mais au final on passe le paramètre authentification, comme on peut le voir dans la console suivante :

Une fois cela fait, nous retournerons ensuite à la console de contrôle de MongoDB, mais dans ce cas si nous allons utiliser notre utilisateur nouvellement créé :

 mongo.exe --username = root --password = 123456 admin

Avec cette ligne précédente, nous pouvons accéder à notre service en toute sécurité, nous pouvons le voir dans l'image suivante :

Il est important de se rappeler que nous devons utiliser un mot de passe plus sécurisé que "123456" dans cet exemple, il n'est utilisé qu'à des fins de démonstration, cependant pour un environnement de production il ne convient pas.
Puisque nous avons vérifié comment accéder avec authentification, nous allons créer un utilisateur qui ne peut lire que dans le Base de données test, pour cela nous allons répéter la création d'un utilisateur, mais nous allons préciser le rôle :

 lis

Ainsi, de cette manière, nous limiterons l'utilisateur à ne pas pouvoir écrire dans les collections. Voyons la réponse dans notre console :

Maintenant, en essayant d'écrire un document, nous obtiendrons une erreur :

Nous avons vu alors comment nous avons déjà sécurisé nos utilisateurs de manière adéquate, il est clair que ce travail d'administration des utilisateurs est un peu complexe, mais une fois que nous l'avons fait, nous pouvons avoir une grande certitude que nous n'aurons pas d'accès non autorisé au Base de données que nous protégeons.
L'une des activités les plus complexes à assurer lorsque nous effectuons une sauvegarde est que nous devons garantir l'intégrité des données, cela nous conduit à un dilemme, localiser le moment où moins d'utilisateurs travaillent et effectuer la sauvegarde, ou le faire indépendamment des données .
fsync et verrouillageCela ne devrait pas être le cas, bien sûr, faire une sauvegarde au moment où nous savons qu'il y a le moins d'utilisateurs est toujours recommandé car nous évitons les problèmes d'application, garantissant que les données sont toujours possibles si nous utilisons quoi dans MongoDB nous savons comment fsync Oui serrure.
Avec ces deux paramètres, nous pouvons faire en sorte que notre base de données rejette les écritures et, au bon moment, nous pouvons effectuer les sauvegardes de manière appropriée.
Pour créer ce verrou, nous devons exécuter la commande suivante dans notre base de données :

 db.runCommand ({"fsync": "1", "lock": "1"});

Avec cela, nous aurons notre Base de données verrouillé efficacement contre l'écriture :

Comme on peut le voir, c'est assez simple et efficace, maintenant si on veut casser le verrou, il suffit de relancer la commande :

 db.fsyncUnlock ();

Avec ce dernier, nous aurons à nouveau notre Base de données capable de recevoir l'écriture :

Bien que ce qui précède représente une plus grande flexibilité et nous donne beaucoup plus de sécurité contre la corruption des données et favorise l'intégrité, ce n'est vraiment pas une pratique que nous devrions suivre dans des environnements de production réels.
L'idéal est de créer un environnement avec réplication, où nous pouvons accéder à une copie des données et ainsi pouvoir manipuler avec l'une des options dont nous disposons les sauvegardes nécessaires. Être dans une réplique du Base de données production, nous pouvons le bloquer, ou le désactiver et effectuer la sauvegarde de manière à ce que l'utilisateur ne rencontre jamais d'erreur dans l'application car il ne peut pas écrire d'enregistrement.
Quant aux sauvegardes, les choses se compliquent puisqu'il est conseillé d'utiliser des répliques de serveurs, cependant en raison de la façon dont il a été conçu MongoDB, ce type de structures Maître d'esclave Ils sont très faciles à mettre en œuvre, donc comprendre le concept est le plus difficile, mais son application est extrêmement conviviale. DBA.
Avec cela, nous terminons ce tutoriel, car nous voyons l'administration de MongoDB C'est assez avancé, si on a une structure de taille moyenne, on a peut-être déjà pensé à la question de la sécurité des utilisateurs, même si créer des utilisateurs n'est pas complexe, s'il est bon de s'asseoir et de définir une bonne structure pour créer ce type de permis.Avez-vous aimé et aidé ce tutoriel ?Vous pouvez récompenser l'auteur en appuyant sur ce bouton pour lui donner un point positif