Sécurité préemptive avec journalisation d'audit pour MongoDB

La sécurité des bases de données est un vaste sujet qui va des mesures préventives à la protection contre les visiteurs indésirables. Même si vous pouviez sécuriser complètement vos serveurs MongoDB, vous voudriez quand même savoir si quelqu'un a tenté de s'introduire dans votre système. Et s'ils parviennent à violer votre sécurité et à installer le hack de rançon MongoDB, vous auriez besoin d'une piste d'audit pour les post-mortem ou pour prendre de nouvelles mesures préventives. Un journal d'audit vous permettrait de garder une trace de toute personne tentant de se connecter et de voir ce qu'elle a fait dans votre système.

La version MongoDB Enterprise contient la possibilité d'activer le journal d'audit, mais la version communautaire ne dispose pas de cette fonctionnalité. Percona a créé sa propre fonctionnalité de journalisation d'audit dans son serveur Percona dérivé de MongoDB pour MongoDB. Les approches MongoDB et Percona sont différentes l'une de l'autre et nous expliquerons comment les configurer et les utiliser toutes les deux.

Journalisation d'audit MongoDB

Le journal d'audit MongoDB est facile à configurer :pour activer la journalisation d'audit dans un fichier JSON, ajoutez simplement la section suivante à votre fichier de configuration et redémarrez MongoDB :

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

MongoDB prend en charge les fichiers, la console et syslog comme destinations. Pour les formats de fichiers, il existe deux options :JSON et BSON. Dans JSON, les lignes du journal d'audit ressemblent à ceci :

{ "atype" : "authCheck", "ts" : { "$date" : "2017-02-15T22:20:08.322-0000" }, "local" : { "ip" : "127.0.0.1", "port" : 27017 }, "remote" : { "ip" : "127.0.0.1", "port" : 63357 }, "users" : [], "roles" : [], "param" : { "command" : "update", "ns" : "test.inserttest", "args" : { "update" : "preauth_case", "updates" : [ { "q" : { "createdByUserId" : -2 }, "u" : { "$set" : { "statusCode" : "Update" } }, "multi" : false, "upsert" : false } ], "ordered" : true } }, "result" : 0 }

La configuration ci-dessus activerait le journal d'audit pour chaque action de n'importe quel utilisateur de votre système. Si vous avez une simultanéité élevée, cela réduirait considérablement les performances de votre cluster MongoDB. Heureusement, il existe une option pour filtrer les événements qui doivent être enregistrés.

Les filtres pour la journalisation d'audit peuvent être placés sur le type de requête, l'utilisateur/le rôle qui interroge ou sur la collection qui est interrogée. La documentation sur la journalisation d'audit chez MongoDB est très large et longue avec de nombreux exemples. Nous donnerons ci-dessous quelques-uns des exemples les plus importants.

Authentification auprès d'une collection spécifique :

    filter: '{ atype: "authenticate", "param.db": "test" }'

Journal pour plusieurs types d'audit :

    filter: '{ atype: { $in [ "update", "delete" ]}, "param.db": "test" }'

Enregistrez toutes les vérifications d'authentification pour les insertions/mises à jour/suppressions sur une collection spécifique :

    filter: '{ atype: "authCheck", "param.ns": "test.orders", "param.command": { $in: [ "find", "insert", "delete", "update", "findandmodify" ] } }'

Comme vous pouvez le constater, les filtres peuvent être assez flexibles et vous pourrez filtrer les messages dont vous avez besoin pour votre piste d'audit.

Serveur Percona pour la journalisation d'audit MongoDB

La journalisation d'audit du serveur Percona pour MongoDB est limitée au fichier JSON. La majorité des utilisateurs se connecteront uniquement aux fichiers JSON, mais il n'est pas clair si Percona ajoutera d'autres fonctionnalités de journalisation à l'avenir.

Selon la version de Percona Server pour MongoDB, votre configuration peut être différente. Au moment de la rédaction, toutes les versions ont la syntaxe suivante :

audit:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Cependant, cette différence de configuration a été récemment résolue, mais doit encore être publiée. Après la publication, il devrait suivre à nouveau la directive MongoDB auditLog :

auditLog:
   destination: file
   format: JSON
   path: /var/lib/mongodb/auditLog.json

Le format de Percona est légèrement différent :

{ "atype" : "authenticate", "ts" : { "$date" : { "$numberLong" : "1487206721903" } }, "local" : { "host" : "n3", "port" : 27017 }, "remote" : { "host" : "172.16.140.10", "port" : 50008 }, "users" : [ { "user" : "admin", "db" : "admin" } ], "params" : { "user" : "admin", "db" : "admin", "mechanism" : "SCRAM-SHA-1" }, "result" : 0 }

Contrairement à MongoDB qui journalise tout, Percona a choisi de ne journaliser que les commandes importantes. À en juger par la source du plug-in d'audit Percona, les requêtes suivantes sont prises en charge :authentification, créer/mettre à jour/supprimer des utilisateurs, ajouter/mettre à jour/supprimer des rôles, créer/supprimer une base de données/index et la plupart des commandes d'administration importantes.

De plus, le filtrage du journal d'audit de Percona Server pour MongoDB ne semble pas suivre la même norme que MongoDB. La syntaxe et les options exactes du filtre ne sont pas claires, car la documentation de Percona est très concise à ce sujet.

L'activation du journal d'audit sans filtrage vous donnerait plus qu'assez d'entrées dans votre fichier journal. À partir de là, vous pouvez affiner le filtre, car il suit la syntaxe JSON des entrées de journal.

Utilisation du journal d'audit

Pour vous faciliter la tâche, il peut être préférable d'alimenter le journal d'audit dans un cadre d'analyse de journal. Une pile ELK est un excellent environnement pour effectuer votre analyse et vous permet d'accéder assez facilement à des niveaux plus détaillés. L'utilisation d'un mappeur de champs vous permettrait même de faire la piste d'audit dans ELK.

Comme décrit dans l'introduction, nous pouvons utiliser le journal d'audit à diverses fins de sécurité. Le plus évident est lorsque vous en avez besoin comme référence lors d'une autopsie. Le journal d'audit MongoDB fournit un aperçu détaillé de ce qui s'est exactement passé. Le journal d'audit Percona contient un peu moins d'informations, mais il devrait être suffisant pour la plupart des post-mortems. L'utilisation du journal d'audit pour les analyses post-mortem est excellente, bien que nous aurions préféré éviter le problème dès le départ.

Un autre objectif du journal d'audit est de voir les tendances se produire et vous pouvez définir des interruptions sur un certain message du journal d'audit. Un bon exemple serait de vérifier le taux de tentatives d'authentification (échouées) et, s'il dépasse un certain seuil, d'agir en conséquence. Selon la situation, les mesures prises peuvent différer. L'une des actions peut consister à bloquer automatiquement l'adresse IP d'où proviennent les demandes, mais dans un autre cas, vous pouvez consulter l'utilisateur pour savoir pourquoi le mot de passe a été oublié. Cela dépend vraiment du cas et de l'environnement dans lesquels vous travaillez.

Une autre mesure préventive avancée consisterait à utiliser MongoDB comme pot de miel et à tirer parti du journal d'audit pour attraper les utilisateurs indésirables. Exposez simplement MongoDB et autorisez quiconque à se connecter à votre serveur MongoDB. Utilisez ensuite le journal d'audit pour détecter ce que les utilisateurs feront s'ils sont autorisés à faire des choses au-delà de leurs pouvoirs normaux et bloquez-les si nécessaire. La plupart des humains préfèrent la voie facile à la voie difficile, de sorte que le pot de miel pourrait détourner une attaque et le pirate passera à la cible suivante.

Conclusion

En plus d'expliquer comment configurer le journal d'audit pour MongoDB Enterprise et Percona Server pour MongoDB, nous avons également expliqué ce que vous pourriez potentiellement faire avec les données enregistrées dans le journal d'audit.

Par défaut, ClusterControl n'activera pas le journal d'audit, mais il est relativement facile de l'activer à l'échelle du cluster à l'aide de notre gestionnaire de configuration. Vous pouvez également l'activer dans les modèles de configuration, avant de déployer un nouveau cluster.

Bon regroupement !