J'utilise actuellement MongoDB pour enregistrer des journaux d'application, et pendant que je suis assez satisfait de la performance et de pouvoir vider des données structurées arbitraires dans des enregistrements de journal, je suis préoccupé par l'mutabilité des enregistrements de journal une fois stockés. .
Dans une base de données traditionnelle, je structurerais les subventions pour mes tables de journalisation telles que l'utilisateur de l'application avait inséré et sélectionner des privilèges, mais ne pas mettre à jour ou supprimer. De même, à Couchdb, je pourrais écrire une fonction de validateur de mise à jour qui a rejeté toutes les tentatives de modification d'un document existant.
Cependant, je n'ai pas été incapable de trouver un moyen de limiter les opérations sur une base de données de MongoDB ou de la collecte au-delà des trois niveaux d'accès (pas d'accès, de lecture seule, "mode dieu") documenté dans le Sujet de sécurité sur le wiki MongoDB.
Quelqu'un d'autre a-t-il déployé MongoDB comme magasin de documents dans un paramètre où l'immuabilité (ou au moins changer de suivi) pour les documents était une exigence? Quelles astuces ou techniques avez-vous utilisées pour que le code d'application mal écrit ou malveillant ne puisse pas modifier ou détruire les enregistrements de journal existants? Dois-je envelopper ma journalisation de MongoDB dans une couche de service qui applique la stratégie en écriture seule ou puis-je utiliser une combinaison de la configuration, de piratage de requête et de la réplication pour assurer un enregistrement cohérent et Audit-Auto-Auto?
3 Réponses :
in mongodub 1.3.2+ Vous pouvez ajouter une certaine restriction dans l'utilisateur:
Mais ce n'est que existant maintenant pas mieux. Peut-être que vous pouvez ajouter une demande de fonctionnalité
Voir les informations dans la documentation de MongoDB: http://www.mongodb.org / Affichage / Documents / Security + et + Authentification db.adduner ("Guest", "PasswordForGuest", True)
Comme je l'ai mentionné dans ma question, je ne cherche pas à ajouter un utilisateur en lecture seule; Je souhaite plutôt ajouter un utilisateur qui ne peut que écrire des enregistrements , sans pouvoir les modifier ou les supprimer après le fait.
Je dirais que le meilleur pari serait de terminer l'accès à MongoDB dans une couche de service qui applique vos contrats spécifiques. Nous ne faisons pas grand chose dans la voie du contrôle d'accès à grain fin, car il y a tellement de cas différents qui les résolvent correctement sont difficiles à obtenir correctement. Donc, pour la plupart, il appartient à la couche d'application de mettre en œuvre ce type de contrôle.
C'est un peu ce que je soupçonnais. J'épuise efficacement l'accès en lecture seule en ce qui n'expose pas de connexion brute à la base de données n'importe où dans le code de l'application. Cela ne nous protège pas parfaitement contre l'erreur utilisateur ou des mises à jour malveillantes, mais je vais vous élaborer une autre solution de journal d'audit durable.
Pour ajouter un utilisateur Disons que vous souhaitiez avoir un utilisateur que ne peut écrire que ( Insérer uniquement) à une Créer un fichier et exécuter cela de ligne de commande Ceci crée un utilisateur avec nom d'utilisateur user1 avec mot de passe pass1 et cet utilisateur a écrire uniquement Accès à la base de données votre collection col1 . Un effet secondaire de ceci est ce rôle rolename est créé. Si vous avez des utilisateurs existants qui devraient avoir un accès écrit à la même collection, subventionner le rôle rolename à cet utilisateur existant. N'hésitez pas à utiliser et à modifier le code fourni ci-dessus: ). CreateUser.js avec le contenu suivant: $ mongo --eval = "charge ('CreateUser.js'); CréationCollectionWriter (" Yourdb "," User1 "," Rolename ", 'Col1' ) "
Comme il ne semble pas y avoir de manière cuit au four, j'ai en fait mis en œuvre un simple proxy TCP qui est assis devant le MongoDb et les filtres envoyés sur le serveur en inspectant l'opcode: gist.github.com/328486
Merci d'avoir posté le gist. Votre configuration de proxy est assez cool et pourrait être utile pour un projet de type entreprise, je pouvais travailler à peu près la même chose (Trail d'audit).
Je cherchais cela exactement la même chose. IMHO, c'est la plus grande défaillance de MongoDB pour le moment.