Comment sécuriser une instance MongoDB?
Quelqu'un a-t-il de l'expérience avec la sécurisation/renforcement du serveur MongoDB? Des listes de contrôle ou des guides seraient les bienvenus.
Les bases de données NoSQL sont relativement nouvelles (bien que ce soit sans doute un vieux concept), je n'ai pas vu de guides de renforcement de MongoDB spécifiques et les endroits habituels que je regarde ( CISSecurity , les publications des fournisseurs, Sans etc. sont tous à court). Suggère que ce serait un bon projet pour une organisation, un étudiant uni, la communauté infosec d'en écrire un et de le maintenir.
Il y a quelques informations de base sur Mongodb.org. Toutes les étapes ici doivent être suivies, y compris l'activation de la sécurité. Le site lui-même déclare que MongoDB n'a qu'un niveau de sécurité très basique. http://www.mongodb.org/display/DOCS/Security+and+Authentication
MongoDB et d'autres bases de données NoSQL ont également beaucoup moins de fonctionnalités (en particulier de sécurité) que les bases de données SQL matures, il est donc peu probable que vous trouviez des autorisations précises ou un chiffrement des données, il utilise MD5 pour le hachage de mot de passe avec le nom d'utilisateur comme graine. Il existe également des limitations telles que l'authentification n'étant pas disponible avec le partitionnement avant la version 1.9.1, il est donc judicieux d'effectuer toujours une évaluation des risques et de créer un modèle de menace pour répondre à vos besoins de sécurité et aux menaces rencontrées. Sur la base de cette sortie, les bases de données MongoDB ou NoSQL en général peuvent ne pas convenir à vos besoins, ou vous devrez peut-être l'utiliser d'une manière différente qui maximise ses avantages et minimise ses faiblesses (par exemple pour les extraits de données plutôt que vos informations les plus sensibles, ou derrière un certain nombre de couches de contrôles réseau plutôt que directement connecté à votre application Web).
Cela dit, je crois fermement que les principes de sécurité sont indépendants de la technologie. Si vous analysez même les dernières attaques, et une bonne liste sur datalossdb.org, il est étonnant de voir combien sont toujours liés aux mots de passe par défaut et aux correctifs manquants. Avec une défense en profondeur si vous suivez les pratiques suivantes, vous devez avoir une sécurité suffisante pour protéger la plupart des actifs (par exemple, individuels, commerciaux), peut-être probablement pas militaires.
Principes de renforcement de la base de données:
- Authentification - nécessite une authentification, pour l'administrateur ou les utilisateurs privilégiés, si possible, deux facteurs (faites-le au niveau de la plate-forme ou via un périphérique réseau car la base de données elle-même ne la prend pas en charge) Utilisez l'authentification par clé pour éviter les mots de passe si possible.
- Autorisation - nombre minimal de comptes requis avec des autorisations minimales requises, les comptes en lecture seule sont pris en charge, alors utilisez-les. Comme le contrôle d'accès granulaire n'existe pas, utilisez des moyens alternatifs, par exemple un service Web en face de la base de données qui contient la logique métier, y compris les règles de contrôle d'accès ou dans l'application. Réduisez les autorisations que Mongodb exécute comme sur la plate-forme, par exemple ne doit pas s'exécuter en tant que root.
- Comptes par défaut et comptes système - modifiez les mots de passe de tous les comptes par défaut, supprimez/verrouillez/désactivez ce que vous pouvez, désactivez la connexion où vous le pouvez.
- Journalisation et surveillance - activez journalisation et exportez-les vers un système de surveillance central. Définissez des alertes spécifiques et des procédures d'enquête pour votre personnel de surveillance
- Validation des entrées - Les bases de données NoSQL sont toujours vulnérables aux attaques par injection, donc le seul fait de les valider est une bonne entrée connue, l'utilisation de la paramétrisation dans vos cadres d'application, toutes les bonnes pratiques pour passer des entrées non fiables à une base de données sont requises
- Chiffrement - selon la sensibilité des données, car vous ne pouvez pas chiffrer au niveau de la base de données, le chiffrement ou le hachage des données sensibles au niveau de la couche d'application est requis. Cryptage du transport également via la couche réseau (par exemple VPN).
- Minimisez les services et modifiez le port d'écoute par défaut
- Supprimer tout échantillon ou base de données de test
- Avoir un processus de gestion des correctifs en place pour identifier, évaluer et installer tous les correctifs de sécurité pertinents en temps opportun
- Renforcez la plateforme et la plateforme de virtualisation si utilisées
- Configurer les contrôles réseau appropriés, par exemple pare-feu, VLAN pour minimiser l'accès à la base de données, service de filtrage de déni de service en amont, DNS complet, bases de données de production et de non production séparées
- Environnement physiquement sécurisé
- Avoir un processus de gestion du changement
Voici une liste de contrôle pour la sécurité MongoDB
Activer l'authentification - Même si vous avez déployé vos serveurs Mongodb dans un réseau approuvé, il est recommandé d'activer l'authentification. Il vous offre une "défense en profondeur" si votre réseau est compromis. Modifiez votre fichier de configuration mongod pour activer l'authentification
N'exposez pas votre base de données de production à Internet - La restriction de l'accès physique à votre base de données est un aspect important de la sécurité. Si cela n'est pas nécessaire, n'exposez pas votre base de données de production à Internet. En cas de compromis si un attaquant ne peut pas se connecter physiquement à votre serveur MongoDB, vos données sont d'autant plus sécurisées. Si vous êtes sur AWS, vous pouvez placer vos bases de données dans un sous-réseau privé VPC. Lisez l'article de blog Déployer MongoDB dans un VPC pour plus d'informations.
Utiliser des pare-feu - Utilisez des pare-feu pour restreindre les autres entités autorisées à se connecter à votre serveur mongodb. La meilleure pratique consiste à autoriser uniquement vos serveurs d'applications à accéder à la base de données. Si vous êtes hébergé sur AWS, utilisez des "groupes de sécurité" pour restreindre l'accès. Si vous êtes hébergé sur un fournisseur qui ne prend pas en charge les constructions de pare-feu, vous pouvez facilement le configurer vous-même en utilisant ‘iptables’. Reportez-vous à la documentation de mongodb pour configurer iptables pour votre scénario.
Utiliser des fichiers de clés pour configurer le jeu de réplicas - Spécifiez un fichier de clés partagé pour activer la communication entre vos instances mongodb dans un jeu de réplicas. Pour l'activer, ajoutez le paramètre keyfile au fichier de configuration comme ci-dessous. Le contenu du fichier doit être le même sur toutes les machines.
Désactiver l'interface d'état HTTP Mongodb fournit par défaut une interface http s'exécutant par défaut sur le port 28017 qui fournit la page d'état "home". Cette interface n'est pas recommandée pour une utilisation en production et il est préférable de la désactiver. Utilisez le paramètre de configuration "nohttpinterface" pour désactiver l'interface http.
Désactivez l'interface REST L'interface monogdb REST n'est pas recommandée pour la production. Elle ne prend en charge aucune authentification. Elle est désactivée par défaut. Si vous avez désactivé en utilisant l'option de configuration "repos", vous devez la désactiver pour les systèmes de production.
Configurer Bind_ip Si votre système possède plusieurs interfaces réseau, vous pouvez utiliser l'option "bind_ip" pour restreindre votre serveur mongodb à écouter uniquement sur les interfaces pertinentes. Par défaut, mongodb se liera à toutes les interfaces
Activer SSL - Si vous n'utilisez pas SSL, vos données transitent non cryptées entre votre client Mongo et votre serveur Mongo et sont susceptibles d'être écoutées, falsifiées et attaquées par l'homme au milieu. Ceci est particulièrement important si vous vous connectez à votre serveur Mongodb sur des réseaux non sécurisés comme Internet.
Autorisation basée sur les rôles - MongoDB prend en charge l'authentification basée sur les rôles pour vous donner un contrôle précis sur les actions qui peuvent être effectuées par chaque utilisateur. Utilisez des constructions basées sur les rôles pour restreindre l'accès au lieu de faire de tous vos utilisateurs des administrateurs. Reportez-vous à la documentation des rôles pour plus de détails.
Enterprise mongodb & Kerberos Enterprise mongodb s'intègre à Kerberos pour l'authentification. Reportez-vous à la documentation de mongodb pour plus de détails. Les systèmes de nom d'utilisateur/mot de passe sont intrinsèquement non sécurisés - utilisez l'authentification basée sur le trottoir si possible.
https://scalegrid.io/blog/10-tips-to-improve-your-mongodb-security/
Avertissement: je suis le fondateur de scalegrid.io
De plus, je vous recommande également de crypter vos données mongodb au repos, comme les autres commentaires l'ont indiqué. Vous pouvez utiliser LUKS (Linux unified key setup) pour configurer le chiffrement au niveau du volume.
Peu de choses très importantes à retenir sont:
- Supprimez la liaison IP de tous à l'adresse IP (privée ou locale), vous vous attendez à obtenir une demande de connexion
- Modifier les liaisons de port par défaut
- Accordez uniquement les autorisations requises (comme aucune autorisation de mise à jour/suppression pour sélectionner les utilisateurs de requête)
- Configurer les clés ssh pour la connexion maître-esclave requise, supprimant l'implication des mots de passe
- Vous pouvez même configurer un tunnel crypté pour la connexion entre votre application et mongodb
en fait, ils s'appliquent à tous les services DataStorage
PS: expérience mongodb très limitée