Cinq configurations de sécurité MongoDB critiques à implémenter dès maintenant

Les problèmes de sécurité MongoDB commencent généralement par une simple erreur : une base de données écoute là où elle ne devrait pas, accepte des utilisateurs qu'elle ne devrait pas, ou envoie du trafic sans chiffrement. Votre configuration MongoDB nécessite une authentification explicite, des rôles restreints, une exposition réseau privée, TLS et des enregistrements d'audit utiles.

Ce guide présente cinq vérifications de production qui réduisent les risques d'accès non autorisé et facilitent l'investigation des activités suspectes.

---

1. Activer le contrôle d'accès obligatoire et l'authentification forte

Commencez par vous assurer que l'autorisation est activée. Sans elle, un client capable d'atteindre le serveur pourrait être en mesure de lire ou de modifier des données en fonction de la manière dont le déploiement a été démarré et configuré.

Comment activer l'authentification

L'authentification est généralement activée via le fichier de configuration (mongod.conf) ou les indicateurs de ligne de commande lors du démarrage.

Fichier de configuration (/etc/mongod.conf) :

# Extrait de /etc/mongod.conf
security:
  authorization: enabled

Ligne de commande :

mongod --auth --dbpath /var/lib/mongodb

Création de l'utilisateur administrateur

Créez le premier utilisateur administratif avant d'activer l'autorisation, ou utilisez l'exception localhost de MongoDB lors de la configuration initiale. Une fois le premier utilisateur créé, redémarrez avec l'autorisation activée et utilisez des comptes nommés pour tout accès.

Exemple : Création de l'utilisateur root via mongosh

D'abord, connectez-vous à la base de données (si elle fonctionne déjà sans authentification, ou en utilisant l'exception localhost) :

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // Demande le mot de passe de manière sécurisée
    roles: [ { role: "root", db: "admin" } ]
  }
)

Avertissement : Utilisez toujours des mots de passe forts stockés dans un gestionnaire de secrets. Ne codez jamais en dur des informations d'identification sensibles dans des scripts ou des fichiers de configuration.

2. Mettre en œuvre un contrôle d'accès basé sur les rôles (RBAC) granulaire

Après avoir activé l'authentification, l'étape suivante consiste à établir le Principe du moindre privilège (PoLP). Cela signifie que chaque utilisateur, application et compte de service ne doit disposer que des autorisations minimales nécessaires pour effectuer ses tâches requises.

Évitez d'utiliser les rôles root ou readWriteAnyDatabase pour les connexions d'application. Définissez plutôt des rôles personnalisés qui accordent des autorisations spécifiques sur des bases de données ou des collections spécifiques.

Étapes pratiques du RBAC

1. Définir des rôles personnalisés : Si les rôles intégrés (read, readWrite) sont insuffisants, créez des rôles avec des actions d'accès granulaires (par exemple, uniquement insert et find sur une collection spécifique).
2. Séparer les utilisateurs d'application : Créez des utilisateurs dédiés pour différents niveaux d'application (par exemple, app_rw pour le backend, reporting_ro pour l'analyse).
3. Limiter l'accès des outils externes : Assurez-vous que les outils d'administration ne se connectent qu'avec des comptes privilégiés lorsque cela est absolument nécessaire.

Exemple : Création d'un utilisateur en lecture seule pour une base de données spécifique

use users_db
db.createUser(
  {
    user: "reporting_svc",
    pwd: passwordPrompt(),
    roles: [ { role: "read", db: "users_db" } ] // Accès en lecture seule à users_db
  }
)

3. Configurer une liaison réseau et des pare-feu stricts

La configuration réseau constitue la défense périmétrique de votre base de données. De nombreuses installations packagées de MongoDB se lient à localhost par défaut, mais les images conteneur, les lignes de commande personnalisées et les fichiers de configuration copiés peuvent exposer 0.0.0.0. Vérifiez toujours le bindIp effectif au lieu de supposer que la valeur par défaut est sûre.

Restreindre bindIp

La mesure de sécurité principale consiste à définir le paramètre bindIp dans votre fichier de configuration. Cela indique explicitement à MongoDB sur quelles adresses IP ou noms d'hôte il doit écouter.

Fichier de configuration (/etc/mongod.conf) :

# Liste des adresses IP ou noms d'hôte auxquels se lier
# Utilisez 127.0.0.1 pour un accès local uniquement
# Utilisez la ou les adresses IP internes pour un accès depuis les serveurs d'application uniquement
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Mettre en œuvre des pare-feu externes (groupes de sécurité)

En plus de bindIp (qui restreint le processus MongoDB), vous devez utiliser un pare-feu externe (comme iptables, les groupes de sécurité AWS ou les groupes de sécurité réseau Azure) pour filtrer le trafic avant qu'il n'atteigne le serveur.

Meilleure pratique : Autorisez uniquement le trafic entrant sur le port MongoDB (27017 par défaut) en provenance de vos serveurs d'application, équilibreurs de charge et bastions administratifs.

4. Appliquer le chiffrement pour les données en transit (TLS)

Les données transmises entre les clients, les shells, les pilotes et MongoDB doivent être chiffrées avec TLS (Transport Layer Security). L'envoi d'identifiants, de requêtes et de résultats sur des connexions non chiffrées expose les données à l'écoute clandestine et aux attaques de l'homme du milieu.

MongoDB prend en charge la configuration TLS native pour le trafic chiffré et la validation facultative des certificats clients.

Activation de TLS

Pour activer le chiffrement, vous devez générer ou obtenir des certificats TLS valides et spécifier leur emplacement dans le fichier de configuration.

Fichier de configuration (/etc/mongod.conf) :

net:
  tls:
    mode: requireTLS
    # Chemin vers le fichier combiné de certificat et de clé
    certificateKeyFile: /etc/ssl/mongodb.pem
    # Chemin vers le fichier de l'autorité de certification (pour la validation client)
    CAFile: /etc/ssl/ca.pem

Connexion client avec TLS

Une fois que le serveur exige TLS, tous les clients doivent se connecter en utilisant les indicateurs sécurisés appropriés :

mongosh "mongodb://[email protected]/admin?authSource=admin" --tls --tlsCAFile /path/to/ca.pem

Astuce : Utilisez mode: requireTLS en production pour garantir que toutes les connexions sont sécurisées. Le mode preferTLS est généralement utilisé uniquement pendant la migration ou les tests.

5. Activer l'audit et surveiller les journaux d'activité

Même avec un contrôle d'accès et un chiffrement solides, les menaces de sécurité peuvent provenir de comptes internes compromis ou d'une escalade de privilèges. L'activation d'un audit complet fournit un historique des actions, ce qui est crucial pour la conformité, l'analyse médico-légale et la détection des comportements suspects.

La fonction d'audit de MongoDB peut enregistrer les actions administratives, les tentatives d'authentification, les échecs d'autorisation et certaines opérations sur les données. La disponibilité dépend de votre édition ou plateforme MongoDB ; par exemple, l'audit est disponible dans MongoDB Enterprise et MongoDB Atlas, tandis que les déploiements Community autogérés nécessitent d'autres approches de journalisation et de surveillance.

Configuration pour l'audit

L'audit est configuré via la section auditLog dans le fichier de configuration. Vous pouvez spécifier la destination (fichier, syslog, console) et les critères de filtre.

Fichier de configuration (/etc/mongod.conf) :

auditLog:
  destination: file
  path: /var/log/mongodb/audit.log
  format: JSON
  # Concentrez-vous sur les événements de sécurité clés comme l'authentification et les modifications administratives
  filter: '{ atype: { $in: [ "authenticate", "authCheck", "createCollection", "createUser", "dropDatabase" ] } }'

Domaines de surveillance essentiels

• Tentatives d'authentification échouées : Un pic soudain indique une potentielle attaque par force brute.
• Création/suppression d'utilisateurs/rôles : Toutes les modifications de privilèges doivent être enregistrées et examinées.
• Suppressions de bases de données ou de collections : Des alertes immédiates sont nécessaires pour les opérations destructrices.

Intégrez les journaux d'audit MongoDB à des systèmes centralisés de gestion de journaux tels que Splunk, la pile Elastic ou Datadog pour les alertes et la conservation.

Conclusion

Examinez ces cinq contrôles lors de chaque déploiement MongoDB : l'autorisation est activée, les utilisateurs d'application ont des rôles restreints, bindIp et les pare-feu limitent l'accès réseau, les clients exigent TLS, et les événements de sécurité sont transmis à votre système de surveillance. Ces vérifications ne remplacent pas les sauvegardes, les correctifs ou la rotation des secrets, mais elles comblent d'abord les lacunes de configuration les plus courantes.