Cinq configurations de sécurité critiques de MongoDB que vous devez implémenter maintenant

Cinq configurations de sécurité MongoDB critiques que vous devez implémenter dès maintenant

MongoDB est une base de données de documents NoSQL puissante et flexible, utilisée par des millions de développeurs et d'entreprises à travers le monde. Cependant, la flexibilité et la facilité de déploiement qui rendent MongoDB attrayant peuvent également entraîner des vulnérabilités de sécurité importantes si les paramètres par défaut ne sont pas immédiatement renforcés. Les premières versions de MongoDB ont fréquemment subi des fuites de données publiques principalement parce que les paramètres de sécurité par défaut étaient trop permissifs.

Protéger votre déploiement MongoDB n'est pas une option ; c'est fondamental pour maintenir l'intégrité des données, la confidentialité et la conformité réglementaire. Ce guide décrit cinq étapes de sécurité non négociables qui doivent être mises en œuvre dans chaque environnement MongoDB de production et de pré-production afin de prévenir les accès non autorisés et le vol de données. En implémentant ces configurations, vous passez d'un état par défaut vulnérable à un cluster de base de données robuste et protégé.

---

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

L'une des étapes les plus critiques pour sécuriser MongoDB est de s'assurer que l'authentification est activée globalement. Par défaut, de nombreux déploiements MongoDB autorisent les connexions sans identifiants, sauf configuration explicite. Cette pratique est intrinsèquement dangereuse.

Comment activer l'authentification

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

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

# /etc/mongod.conf snippet
security:
  authorization: enabled

Ligne de commande :

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

Création de l'utilisateur administrateur

Une fois le contrôle d'accès activé, vous devez créer un utilisateur administratif avec le rôle userAdminAnyDatabase ou root. Vous ne pouvez créer cet utilisateur qu'avant le redémarrage du service avec --auth activé, ou en désactivant temporairement l'authentification pour l'étape de création initiale si le système est déjà en cours d'exécution.

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

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

use admin
db.createUser(
  {
    user: "mongoAdmin",
    pwd: passwordPrompt(), // Prompts for password securely
    roles: [ { role: "root", db: "admin" } ]
  }
)

⚠️ Avertissement : Utilisez toujours des mots de passe forts et complexes, stockés en toute sécurité via un gestionnaire de secrets. Ne jamais coder en dur des identifiants sensibles dans des scripts ou des fichiers de configuration.

2. Implémenter le contrôle d'accès granulaire basé sur les rôles (RBAC)

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 avoir que les 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 les différentes couches d'application (par exemple, app_rw pour le backend, reporting_ro pour l'analyse).
3. Limiter l'accès aux 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" } ] // Only read access to users_db
  }
)

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

La configuration réseau est la défense périmétrique de votre base de données. Par défaut, MongoDB se lie souvent à toutes les interfaces réseau disponibles (0.0.0.0), le rendant potentiellement accessible à l'ensemble du réseau ou, pire, à l'internet public s'il est exécuté sur une instance cloud sans règles de pare-feu appropriées.

Restreindre bindIp

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

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

# List of IPs or hostnames to bind to
# Use 127.0.0.1 for local access only
# Use internal IP(s) for access from application servers only
net:
  port: 27017
  bindIp: 127.0.0.1, 10.0.1.5, localhost

Implémenter 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 (par défaut 27017) depuis vos serveurs d'application, équilibreurs de charge et serveurs de rebond administratifs.

4. Imposer le chiffrement des données en transit (TLS/SSL)

Les données transmises entre les clients (applications, shells, pilotes) et le serveur MongoDB doivent être chiffrées à l'aide de Transport Layer Security (TLS) ou Secure Sockets Layer (SSL). L'envoi d'identifiants, de requêtes et de résultats sur des connexions non chiffrées expose les données à des écoutes clandestines potentielles (attaques de l'homme du milieu).

MongoDB prend en charge la configuration TLS/SSL native pour le chiffrement du trafic et la validation optionnelle des certificats clients.

Activation de TLS/SSL

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:
  ssl:
    mode: requireTLS
    # Path to the combined certificate and key file
    serverCertificateKeyFile: /etc/ssl/mongodb.pem
    # Path to the Certificate Authority file (for client validation)
    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 options sécurisées appropriées :

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

Conseil : Utilisez mode: requireTLS en production pour garantir que toutes les connexions sont sécurisées. Le mode preferTLS n'est généralement utilisé que lors de la migration ou des tests.

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

Même avec un contrôle d'accès et un chiffrement robustes, des menaces de sécurité peuvent survenir à la suite 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 forensique et la détection des comportements suspects.

La fonctionnalité d'audit de MongoDB peut enregistrer les actions administratives, les tentatives d'authentification, les tentatives d'accès non autorisées et potentiellement les lectures/écritures de données.

Configuration pour l'audit

L'audit est configuré via la section auditLog du 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
  # Focus on key security events like authentication and administrative changes
  filter: '{ atype: { $in: [ "authenticate", "authorize", "createCollection", "createUser", "dropDatabase" ] } }'

Zones de surveillance essentielles

• Tentatives d'authentification échouées : Une augmentation soudaine 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 avec des systèmes centralisés de gestion des journaux (par exemple, Splunk, ELK Stack, DataDog) pour des alertes en temps réel et une conservation à long terme.

Conclusion

L'implémentation de ces cinq configurations critiques fait passer votre déploiement MongoDB d'un état de vulnérabilité à un état de résilience. La sécurité dans MongoDB n'est pas une tâche que l'on configure une fois pour toutes ; c'est un processus continu. Assurez-vous que ces configurations – authentification obligatoire, RBAC granulaire, liaison réseau stricte, chiffrement TLS et audit complet – sont vérifiées lors de chaque déploiement et révisées régulièrement. La priorisation de ces étapes atténuera considérablement le risque d'accès non autorisé et de compromission des données.