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

Une liste de contrôle de sécurité pour les déploiements de production MongoDB

Lorsqu'une application nécessite une grande zone géographique pour fonctionner, une organisation est souvent obligée de stocker ses données dans le cloud. Les applications construites sur MongoDB ne font pas exception à ce concept. Le fait de ne pas protéger les données sensibles peut entraîner de graves revers pour l'entreprise, notamment une réputation ruinée, des incohérences de données, des pertes financières et parfois une perte totale de données.

Les données stockées dans le cloud sont susceptibles d'intéresser des éléments criminels. Les personnes ayant des intentions malveillantes peuvent accéder plus facilement lorsqu'aucune procédure standard n'a été définie pour assurer la sécurité de la base de données. Certaines de ces procédures inférieures aux normes incluent...

  • Mauvaise gestion des mots de passe :certains développeurs finissent par coder en dur les mots de passe dans les fichiers source du projet. Ainsi, si un pirate décompile l'application, il peut facilement récupérer le contenu.
  • Réticence ou échec à mettre à jour la base de données et les plugins complémentaires. Les nouvelles versions de base de données ont de nouvelles fonctionnalités, peut-être en termes de sécurité ou plutôt certaines fonctionnalités ont été corrigées par rapport aux prédécesseurs.
  • Configurations de base de données inférieures aux normes, par exemple n'utilisant pas de clés de déchiffrement chiffrées ou n'utilisant aucun protocole de sécurité du tout.

Les attaques de bases de données augmentent de jour en jour (et la tendance devrait se poursuivre), mais vous ne serez peut-être pas victime si vous n'appliquez pas les considérations de sécurité appropriées. Dans cet article, nous allons discuter de certaines des procédures que l'on peut vérifier avec l'installation de MongoDB dans le cloud. Vous n'avez pas besoin de tous les appliquer, mais essayez au moins de choisir ceux qui, s'ils sont évités, pourraient mettre vos données dans une situation désastreuse.

Considérations de sécurité de pré-production MongoDB

Ce sont des considérations dont il faut s'assurer qu'elles sont bien configurées avant de déployer MongoDB dans l'environnement de production. Ils incluent : 

  1. Activer et appliquer l'authentification pour le contrôle d'accès
  2. Configurer le contrôle d'accès basé sur les rôles
  3. Limiter l'exposition du réseau
  4. Chiffrer les communications
  5. Crypter les données
  6. Activités du système d'audit 
  7. Utiliser un utilisateur dédié pour exécuter MongoDB
  8. Utiliser les packages MongoDB officiels et mis à jour
  9. Désactiver les exécutions Javascript si elles ne sont pas nécessaires
  10. Être mis à jour avec les correctifs de sécurité MongoDB

1. Activation et application de l'authentification pour le contrôle d'accès

Le contrôle d'accès n'est pas activé dans MongoDB par défaut, mais cela ne signifie pas que vous déployez également votre base de données sans cette option activée. En fait, certains packages de base de données comme Bitnami vous obligeront à configurer un contrôle d'accès avant d'utiliser votre base de données. Dans le cas contraire, n'importe qui peut avoir accès à la base de données, d'où une exposition à des données même très sensibles. Spécifiez un mécanisme d'authentification tel que le SCRAM afin que les clients qui seront connectés doivent fournir des informations d'identification valides avant de pouvoir se connecter à la base de données.

La chaîne de connexion doit ressembler à :

mongodb://[username:[email protected]]host[:port1][/[defaultauthdb]and not just

mongodb://host[:port1]/[defaultauthdb]

2. Configurer le contrôle d'accès basé sur les rôles

Après avoir ajouté des utilisateurs avec des autorisations administratives, limitez les rôles attribués à ces utilisateurs à l'aide du contrôle d'accès basé sur les rôles (RBAC). Les rôles qu'un utilisateur peut avoir incluent :lire, écrire ou les deux dans des collections spécifiques ou dans toutes les collections. Par conséquent, un utilisateur ne peut pas jouer un rôle qui ne lui est pas attribué ou peut effectuer des opérations uniquement sur les collections attribuées.

L'administrateur d'utilisateurs est créé en premier, puis les utilisateurs supplémentaires. Si un utilisateur dispose de privilèges sur différentes bases de données, vous pouvez créer un seul utilisateur avec des rôles qui accordent des privilèges de base de données applicables au lieu de créer l'utilisateur plusieurs fois dans différentes bases de données.

Il est conseillé d'avoir un petit nombre d'utilisateurs accédant à la base de données, les utilisateurs pouvant être des personnes ou des applications clientes.

Pour créer et accorder des autorisations utilisateur pour certains rôles dans MongoDB, vous pouvez utiliser cet exemple dans le shell mongo

use finance

db.createUser(

  {

    user: "manager",

    pwd: passwordPrompt(),  // or cleartext password

    roles: [

       { role: "read", db: "loans" },

       { role: "read", db: "interests" },

       { role: "read", db: "useraccounts" },

       { role: "readWrite", db: "wages" }

    ]

  }

)

 Optez également pour des options d'authentification externes telles que LDAP et Kerberos.

3. Limiter l'exposition du réseau

La topologie du réseau qui héberge la base de données doit être largement sécurisée et, surtout, n'écouter que l'interface localhost. Ceci afin d'éviter l'exposition des connexions extérieures comme c'était le cas pour les anciennes versions de MongoDB. Assurez-vous que MongoDB s'exécute dans un environnement réseau de confiance avec un pare-feu de sécurité activé. Contrôlez le trafic entrant et sortant avec des groupes de sécurité qui ne peuvent pas être utilisés avec d'autres instances. Utilisez la liste blanche d'adresses IP pour autoriser l'accès à partir d'adresses IP de confiance et autorisez donc les connexions aux instances MongoDB avec des interfaces réseau et des ports provenant uniquement de clients de confiance.

De plus, désactivez l'accès direct à la racine SSH.

4. Crypter les communications

La configuration de MongoDB doit limiter les connexions entrantes et sortantes à TLS/SSL uniquement. TLS/SSL crypte la communication entre les composants mongod et mongos d'un déploiement MongoDB et toutes les applications qui y sont connectées.

Dans l'environnement de production, le déploiement de MongoDB doit utiliser des certificats valides générés et signés par une seule autorité de certification.

5. Crypter les données

Les données de la base de données prennent deux formes :les données au repos et en transit. Les données en transit peuvent être sécurisées à l'aide du chiffrement au niveau du champ côté client, mais elles ne sont disponibles que dans la version 4.2. Le cryptage TLS/SSL prend également en charge les données en transit.

Le moteur de stockage WiredTiger de la version 3.2 Enterprise fournit des données dans le chiffrement de la couche de stockage. Cela affirme que seuls les utilisateurs authentifiés avec des clés de déchiffrement peuvent accéder aux données. Si vous n'utilisez pas le cryptage de WiredTiger au repos, utilisez le cryptage du système de fichiers. Le chiffrement des données au repos dissuade une personne d'accéder au contenu de votre base de données si elle accède au serveur physique, d'où un élément crucial dans la sécurisation de MongoDB.

6. Activités du système d'audit 

Il s'agit d'une option d'entreprise qui permet de suivre toutes les modifications apportées aux données et aux configurations de base de données. Les événements sont écrits dans une connexion syslog ou dans un fichier journal. Les journaux peuvent contenir des tentatives d'authentification de base de données, y compris des adresses IP sources, et les informations peuvent aider à déterminer quels hôtes doivent être bloqués par le pare-feu pour accéder à la base de données. En outre, on peut définir avec précision les événements à enregistrer.

En général, ces journaux d'audit aideront l'administrateur à effectuer des analyses médico-légales et donc à définir des contrôles de sécurité standard.

7. Utiliser un utilisateur dédié pour exécuter MongoDB

Les processus MongoDB doivent être exécutés avec un compte d'utilisateur dédié au système d'exploitation dont les autorisations d'accès doivent être activées.

8. Utiliser les packages MongoDB officiels et mis à jour

Passez des contrôles d'authenticité sur vos packages pour vous assurer qu'ils sont les packages officiels de MongoDB. L'utilisation des derniers pilotes MongoDB et de la dernière version de la base de données elle-même offre une plus grande stabilité de sécurité que les prédécesseurs. Par exemple, la version 4.2 offre le chiffrement au niveau du champ côté client. Assurez-vous donc de migrer vers la version la plus récente de MongoDB.

 9. Désactivez les exécutions Javascript si vous n'en avez pas besoin

mapReduce et $where sont quelques-uns des codes JavaScript exécutables dans MongoDB et s'ils ne sont pas bien gérés, ils peuvent entraîner des incohérences de données indésirables ou permettre à quelqu'un d'accéder indirectement aux données et d'appliquer certaines modifications s'il le souhaite .

En général, ce code JavaScript permettra des injections externes donc des données non validées entrant dans votre base de données. Vous pouvez également choisir d'utiliser des packages tels que mongoose pour valider et vous connecter à votre base de données. Utilisez les opérateurs MongoDB au lieu des expressions JavaScript.

10. Mettez-vous à jour avec les correctifs de sécurité MongoDB

Les protocoles de sécurité peuvent être brisés par les attaquants avec le temps, il en faut donc un pour impliquer des procédures avancées. Rester à jour avec les principales mises à jour de sécurité et les corrections de bogues des notes de version de MongoDB est très important. La page d'alerte MongoDB a été essentiellement créée à cette fin.

Demandez un guide de mise en œuvre technique de la sécurité si possible et assurez-vous que votre déploiement est conforme aux normes de sécurité.

Conclusion

Les bases de données en production sont sujettes aux attaques de sécurité, il faut donc investir massivement dans la protection des données sensibles. Les procédures de sécurité vont des données en transit, des données au repos et des applications clientes connectées. Outre les pratiques mentionnées ci-dessus, les entreprises de renforcement des serveurs fourniront une autre couche de protection des données.

Il est important d'utiliser les versions les plus récentes de MongoDB et des plugins en plus de se tenir au courant des dernières corrections de sécurité et de bogues liées à votre version.