MongoDB
 sql >> Base de données >  >> NoSQL >> MongoDB

Niveaux d'insécurité de MongoDB et comment les éviter

La plupart des systèmes de gestion de bases de données disposent de plusieurs techniques pour sécuriser leurs données contre un tiers ou une personne ou une application non autorisée. Les techniques empêchent que vos données soient lues ou copiées sans l'autorisation de l'utilisateur.

MongoDB n'est pas différent car il a des niveaux d'insécurité. Dans cet article de blog, nous discuterons des niveaux d'insécurité dans MongoDB et comment les éviter afin que vous puissiez protéger votre installation MongoDB.

Pour la sûreté et la sécurité de votre MongoDB, voici quelques-unes des principales mesures de sécurité à prendre strictement en compte :
 

  1. Authentification des connexions utilisateur.

  2. Autorisation/Contrôle d'accès basé sur les rôles.

  3. chiffrement du réseau/chiffrement du transport.

  4. Chiffrement du stockage/ Chiffrement au repos.

  5. Audit.

Dans cet article, nous examinerons en détail les mesures de sécurité ci-dessus, en mettant l'accent sur l'authentification et l'autorisation.

Authentification et autorisation

L'authentification et l'autorisation doivent être activées à l'unisson. Cependant, ils peuvent être utilisés indépendamment les uns des autres. L'authentification empêche l'accès à une personne inconnue disposant d'un accès réseau au serveur de base de données de copier ou d'endommager les données de la base de données. L'authentification nécessite que tous les clients et serveurs fournissent des informations d'identification valides avant de pouvoir se connecter au système. L'autorisation, quant à elle, empêche une application ou un utilisateur de lire, modifier ou supprimer des données autres que celles qu'ils étaient censés lire.

Pour configurer le contrôle d'accès basé sur les rôles ;

  1. Créez d'abord un administrateur utilisateur.

  2. Créer des utilisateurs supplémentaires.

  3. Créez ensuite un utilisateur MongoDB unique pour chaque personne/application qui accède au système.

  4. En suivant le principe du moindre privilège, vous devez créer des rôles qui définissent les droits d'accès exacts nécessaires à un ensemble d'utilisateurs.

  5. Ensuite, attribuez aux utilisateurs uniquement les rôles qu'ils doivent jouer dans leurs opérations. Un utilisateur peut être une application cliente ou une personne.

Vous devez noter qu'un utilisateur peut avoir des privilèges sur différentes ou plusieurs bases de données. Dans ce scénario, au lieu de créer plusieurs fois un utilisateur dans différentes bases de données, créez un seul utilisateur avec des rôles qui accordent les privilèges de base de données applicables.

Plus souvent qu'autrement, ces deux mesures de sécurité peuvent être confondues pour signifier la même chose. Dans certains scénarios, ils sont similaires les uns aux autres, mais ils sont également différents.

Similarités entre l'authentification et l'autorisation

  • Les deux sont en quelque sorte une seule unité car, lorsque vous activez l'authentification, l'autorisation est activée automatiquement. L'autorisation est activée à l'unisson avec l'authentification, de sorte que les connexions d'utilisateurs inconnus n'auront aucun privilège pour accéder aux données de la base de données. L'autorisation nécessite également que le nom d'utilisateur soit vérifié par l'authentification afin de savoir quels privilèges s'appliquent aux demandes d'une connexion. Par conséquent, il ne peut pas non plus être activé indépendamment de l'autre.

  • Ils sont également similaires dans la dénomination malheureuse et héritée des options de configuration. L'option du fichier de configuration pour l'authentification est security.authorization au lieu de l'authentification de sécurité comme on pourrait s'y attendre. Cependant, lorsque vous utilisez la commande, l'authentification est la première à être activée et l'autorisation n'est activée qu'en conséquence. "-auth" est l'argument de ligne de commande pour activer l'authentification qui force automatiquement l'autorisation à être également activée.

Différences entre l'authentification et l'autorisation

  • Ces deux sont différents car ce sont deux parties du logiciel qui ont des fonctions différentes.

Authentification ==Identité de l'utilisateur, au moyen de la vérification des informations d'identification.

Autorisation ==Affectation et application des autorisations d'objet DB et de commande DB.

  • Lors de la configuration initiale, l'authentification est désactivée pour les connexions localhost. Ceci est bref car vous avez une opportunité de créer le premier utilisateur, puis le privilège d'exception (à la règle d'authentification et d'autorisation ensemble) est supprimé.

Comment vérifier si l'authentification et l'autorisation sont activées ou non

Les premières versions de MongoDB avaient "- auth" activé par défaut et cela est largement considéré comme une mauvaise décision. Même dans la version 4.0, il était toujours désactivé par défaut. Une configuration vide équivaut toujours à une autorisation désactivée malgré les avertissements de démarrage et diverses réductions d'exposition, telles que localhost devenant le seul périphérique réseau lié par défaut dans MongoDB v3.6.

Vous n'utilisez pas l'authentification ou plutôt vous n'avez pas activé l'authentification si les fichiers de configuration mongod ne le font pas :

  1. Avoir security.authorization défini sur "enabled".

  2. Inclure un security.keyfile.

  3. Incluez un paramètre security.clusterAuthMode qui force l'activation de l'authentification.

Pour revérifier si l'authentification et l'autorisation sont activées ou non, vous pouvez essayer ce mongo shell rapide (sans jeu d'arguments d'informations d'identification de l'utilisateur) :

mongo --host  : --quiet --eval 'db.adminCommand({listDatabases :1})'

La réponse que vous devriez obtenir est une erreur "non autorisée". Mais, d'un autre côté, si vous obtenez une liste de noms de bases de données, cela signifie automatiquement que vous avez un déploiement MongoDB nu.

Authentification externe

Comme son nom l'indique, l'authentification externe consiste à permettre aux utilisateurs de s'authentifier auprès d'un service externe. À titre exceptionnel, il ne peut pas être utilisé pour l'utilisateur interne du système mongodb __, mais son utilisation pour tout utilisateur humain réel ou compte de service d'application client convient parfaitement.

Simple, le service d'authentification externe sera un KDC Kerberos, ou un serveur ActiveDirectory ou OpenLDAP. Vous devez noter que l'utilisation de l'authentification externe ne vous empêche pas d'avoir des comptes d'utilisateur MongoDB ordinaires en même temps.

Authentification interne

Au contraire, l'authentification interne MongoDB ne signifie pas le contraire de l'authentification externe. En effet, un nœud mongod s'exécutant avec l'authentification activée ne fera pas confiance au fait qu'un pair TCP est un autre nœud mongod ou mongos simplement parce qu'il communique comme tel. Au contraire, il exige que le pair s'authentifie par preuve de secret partagé.

Il existe deux types de mécanismes d'authentification interne dans MongoDB :

  1. Authentification interne du fichier clé.

  2. Authentification interne SCRAM ou x.509.

Authentification interne du fichier clé

Il s'agit du mécanisme d'authentification interne par défaut dans MongoDB. Le terme "Clé" indique une clé de chiffrement asymétrique, mais en réalité, il ne s'agit que d'un mot de passe, quelle que soit la manière dont vous l'avez généré. Le fichier clé est enregistré dans un fichier identique distribué à chaque nœud mongod et mongos du cluster. Dans le cas où le mot de passe est utilisé avec succès, un nœud mongod permettra aux commandes provenant du pair authentifié de s'exécuter en tant que superutilisateur « _ _ system ».

Si quelqu'un a une copie du fichier clé, il peut simplement supprimer les caractères de contrôle et non imprimables du fichier clé pour créer la chaîne de mot de passe qui lui permettra de se connecter en tant qu'utilisateur "_ _ système".

Cependant, si cela se produit et que vous exécutez la commande ci-dessous en tant qu'utilisateur mongod (ou root) sur l'un de vos serveurs MongoDB et que vous réussissez, vous ne devriez pas vous inquiéter car il n'y aura pas de fuite accidentelle de privilège de lecture . C'est parce que le mongod s'arrêtera au démarrage si le fichier clé est en mode autre que 400 (ou 600) autorisations de fichiers.

mongo --authenticationDatabase local -u __system -p "$(tr -d '\011-\015\040' < /path/to/keyfile)"

Cependant, l'enregistrement accidentel du fichier clé dans votre contrôle de source lisible par tous peut permettre aux utilisateurs qui ne sont pas des DBA (ou les administrateurs du serveur avec root) de lire une copie du fichier clé. Ceci est considéré comme une défaillance de sécurité.

Un risque extrême augmente lorsque le fichier clé est distribué avec des nœuds mongos détenus et exécutés comme l'un des utilisateurs Unix de l'équipe d'application au lieu de "mongod" ou d'un autre utilisateur Unix appartenant à l'équipe DBA.

SCRAM ou authentification interne x.509

Le mécanisme d'authentification interne x.509 utilise en fait des clés privées ou publiques asymétriques et doit être utilisé en union avec TLS/SSL. Ce mécanisme peut être utilisé pour les connexions client ainsi que pour l'authentification interne.

Le mécanisme x.509 ou SCRAM a un avantage sur le mécanisme Keyfile car dans le mécanisme x.509, il est moins probable qu'une des clés déployées avec les nœuds mongod et mongos puisse être abusée par un intrus qui en obtient une copie. Cependant, cela dépend de la rigueur avec laquelle les certificats x.509 sont configurés. Pour profiter d'une sécurité maximale de ce mécanisme, vous devez disposer d'une équipe de sécurité dédiée qui comprend les concepts et les meilleures pratiques x.509. Ces meilleures pratiques incluent le resserrement des hôtes sur lesquels il fonctionnera et la possibilité de révoquer et de renverser les certificats.

Cryptage du réseau/Cryptage du transport

Le cryptage réseau empêche quelqu'un de copier les données qui sont transférées sur un lien réseau quelque part entre deux serveurs. Le cryptage réseau nécessite peu ou pas de réflexion lorsqu'il s'agit de décider de l'utiliser car il est crucial. Mais si, par exemple, votre cluster MongoDB et tous ses clients se trouvent à l'intérieur d'un réseau privé virtuel dont vous pensez qu'il n'y a pas de trous dans son pare-feu et qu'il n'y a pas de risque d'escalade de privilèges de la part d'autres applications, vous n'avez pas besoin de chiffrement réseau.

Pour le chiffrement du réseau, vous devez configurer MongoDB pour utiliser TLS/SSL pour toutes les connexions entrantes et sortantes. Chiffrez la communication entre les composants mongod et mongos d'un déploiement MOngoDB ainsi qu'entre toutes les applications et MongoDB à l'aide de TLS/SSL.

À partir de la version 4.0 ; MongoDB désactive la prise en charge du chiffrement TLS 1.0 sur les systèmes où TLS 1.1+ est disponible et utilise également les bibliothèques TLS/SSL natives suivantes :

  1. Windows - Canal sécurisé (Schannel).

  2. Linux/BSD - OpenSSL.

  3. macOS - Transport sécurisé.

Limiter l'exposition du réseau

Vous devez vous assurer que MongoDB s'exécute dans un environnement réseau de confiance et également configurer un pare-feu ou des groupes de sécurité pour contrôler le trafic entrant et sortant de vos instances MongoDB. Plus encore, configurez pour autoriser uniquement les clients de confiance à accéder aux interfaces réseau et aux ports sur lesquels les instances MongoDB sont disponibles. Par exemple, utilisez la liste blanche d'adresses IP pour autoriser l'accès à partir d'adresses IP de confiance.

Exécutez MongoDB avec des options de configuration sécurisées

MongoDB prend en charge le code JavaScript d'exécution pour les opérations côté serveur suivantes :

  1. mapReduce.

  2. $où.

  3. $accumulateur.

  4. $fonction.

Utilisez l'option --noscripting sur la ligne de commande pour désactiver les scripts côté serveur si vous n'utilisez pas les opérations ci-dessus. Gardez la validation des entrées activée bien que MongoDB active la validation des entrées par défaut via le paramètre net.wireObjectCheck. Cela garantit que tous les documents stockés par l'instance mongod sont des BSON valides.

Chiffrement du stockage MongoDB/ Chiffrement au repos

Le chiffrement du stockage empêche quiconque d'obtenir une copie des fichiers de base de données sous-jacents. Cela peut se produire lorsque quelqu'un s'introduit dans votre centre de données et vole le disque dur de votre serveur. Les données MongoDB incluent des fichiers de données, des fichiers de configuration, des journaux d'audit et des fichiers clés.

À partir de MongoDB Enterprise 3.2, vous pouvez chiffrer les données dans la couche de stockage avec le chiffrement au repos natif du moteur de stockage WiredTiger. Les données MongoDB doivent être cryptées sur chaque hôte à l'aide d'un système de fichiers, d'un périphérique ou d'un cryptage physique lorsqu'elles n'utilisent pas le cryptage au repos de WiredTiger. En outre, vous devez collecter les journaux dans un magasin de journaux central car ces journaux contiennent des tentatives d'authentification de base de données, y compris l'adresse IP source. Cependant, le chiffrement du stockage a un léger coût de performance.

Audit

L'audit aide à suivre un utilisateur de base de données qui sait comment dissimuler ses traces après avoir changé ou modifié les données de la base de données. Fondamentalement, l'audit suit l'accès et les modifications apportées aux configurations et aux données de la base de données. MongoDB Enterprise dispose d'un système d'audit capable d'enregistrer des événements système tels que les opérations des utilisateurs et les événements de connexion sur une instance MongoDB.

Ces enregistrements d'audit facilitent l'analyse médico-légale et permettent aux administrateurs de vérifier les contrôles appropriés. L'audit est d'une grande valeur pour certains utilisateurs mais ne peut l'être que lorsque certains autres risques sont éliminés. Par exemple, un attaquant ne peut pas obtenir un accès root Unix sur les serveurs lors de l'exécution des nœuds mongod en direct.

Aller de l'avant

Vous pouvez configurer des filtres pour enregistrer des événements spécifiques comme les événements d'authentification. Mais soyez prudent car lorsque les filtres d'audit sont rendus trop larges, ses performances s'étouffent rapidement, entraînant des coûts de performance élevés. Bien que, si l'audit est utilisé de manière appropriée, il n'y aura pas beaucoup de coûts de performance.