Durcissement de la sécurité MongoDB avec exemples pratiques

Introduction

MongoDB est une base de données documentaire populaire souvent déployée sans modifier ses paramètres par défaut. Par défaut, une instance fraîchement installée écoute sur toutes les interfaces réseau, n'a pas d'authentification activée et accorde un accès illimité à tout client pouvant se connecter. Pour les équipes de développement et les ingénieurs DevOps, c'est un risque sérieux : les instances MongoDB exposées ont été ciblées à plusieurs reprises par des attaquants qui volent des données, suppriment des bases de données et exigent une rançon.

Le durcissement de la sécurité consiste à réduire la surface d'attaque d'un système en modifiant les paramètres par défaut, en activant les contrôles d'accès et en vérifiant que la configuration résultante se comporte comme prévu. Ce guide présente un processus de durcissement pratique pour MongoDB. Vous apprendrez à inventorier votre environnement, à appliquer des changements de configuration de manière ciblée et sécuritaire, à vérifier les résultats avec des contrôles observables et à préparer un plan de retour en arrière en cas de problème. L'objectif n'est pas de transformer chaque déploiement MongoDB en forteresse du jour au lendemain, mais d'établir une base de référence reproductible qui protège vos données sans paralyser le développement.

Le processus suit trois principes issus de pratiques opérationnelles réussies : séparer la recherche de la mise en œuvre, piloter les changements de manière étroite avant de les généraliser, et rendre chaque étape mesurable. À la fin, vous disposerez d'une liste de contrôle concrète que vous pourrez adapter à votre environnement.

Inventaire des versions et de l'environnement

Avant de modifier tout paramètre de sécurité, vous devez avoir une image claire de ce que vous exécutez. Un inventaire évite les surprises, comme l'application d'un paramètre non pris en charge dans votre version de MongoDB ou le verrouillage accidentel d'un membre d'un jeu de réplicas.

Identifier la version et l'édition de MongoDB

Exécutez la commande suivante dans l'interpréteur MongoDB (mongosh) pour obtenir la version du serveur et les informations de build :

// Se connecter à la base de données admin
db = db.getSiblingDB('admin');
// Afficher la version et les informations de build
printjson(db.runCommand({ buildInfo: 1 }));

Sortie attendue (tronquée pour plus de lisibilité) :

{
  "version": "7.0.4",
  "gitVersion": "...",
  "modules": ["enterprise"],
  "sysInfo": "...",
  "ok": 1
}

Notez si le champ modules comprend "enterprise" ou est absent (édition Community). L'édition Enterprise comprend des fonctionnalités de sécurité avancées telles que l'authentification LDAP, le chiffrement au repos via KMIP et l'audit. L'édition Community prend toujours en charge l'authentification, TLS et le contrôle d'accès basé sur les rôles, mais vous ne pouvez pas utiliser ces fonctionnalités réservées à l'édition Enterprise. Connaître l'édition vous évite de tenter de configurer quelque chose de non pris en charge.

Déterminer la topologie du déploiement

MongoDB peut fonctionner comme un serveur autonome, un jeu de réplicas ou un cluster fragmenté. Chaque topologie nécessite des étapes de durcissement différentes. Pour vérifier la topologie actuelle, utilisez :

// Dans mongosh
printjson(db.adminCommand({ hello: 1 }));

Si le résultat comprend "isWritablePrimary": true et aucun "setName", vous êtes sur un serveur autonome. Si "setName" est présent, c'est un jeu de réplicas. Pour les clusters fragmentés, vous verrez également "msg": "isdbgrid" lors de la connexion à un routeur mongos.

Inventorier les utilisateurs, les rôles et l'état de l'authentification

Vérifiez si l'authentification est déjà activée et quels utilisateurs existent. Tout d'abord, voyez si vous êtes connecté sans informations d'identification. Dans mongosh, exécutez :

// Afficher l'utilisateur courant (vide si pas d'authentification)
printjson(db.runCommand({ connectionStatus: 1 }).authInfo.authenticatedUsers);

Si le résultat est un tableau vide, l'authentification n'est pas activée ou vous êtes connecté en tant qu'utilisateur sans rôles. Pour lister tous les utilisateurs dans la base de données admin :

use admin;
db.getUsers();

Cela renvoie un tableau de documents utilisateur, y compris leurs rôles et restrictions d'authentification. Documentez ces utilisateurs ; vous devrez peut-être les migrer ou les modifier après l'activation du contrôle d'accès.

Vérifier l'exposition réseau et le fichier de configuration

Déterminez sur quelles interfaces et quels ports MongoDB écoute. Sur Linux, utilisez ss ou netstat :

sudo ss -tulpn | grep mongod

Exemple de sortie :

tcp LISTEN 0 128 0.0.0.0:27017 0.0.0.0:* users:(("mongod",pid=1234, fd=10))

Le 0.0.0.0:27017 signifie que MongoDB écoute sur toutes les interfaces IPv4, ce qui est un risque de sécurité. Trouvez le fichier de configuration, généralement /etc/mongod.conf sur Linux, et vérifiez la section net :

net:
  port: 27017
  bindIp: 0.0.0.0  # C'est le problème

Prérequis pour le durcissement

Avant de continuer, assurez-vous d'avoir :

• Un accès shell administratif à l'hôte MongoDB.
• Une sauvegarde ou un instantané de la base de données, surtout si vous modifiez les paramètres d'authentification.
• La documentation MongoDB pour votre version spécifique téléchargée ou mise en favori.
• Un environnement de test ou une fenêtre de maintenance pour un jeu de réplicas (certaines modifications nécessitent le redémarrage de mongod).
• Un plan pour mettre à jour les chaînes de connexion de l'application avec de nouvelles informations d'identification ou paramètres TLS.

Un inventaire clair réduit les retouches ultérieures. Vous saurez exactement quoi changer et quoi éviter.

Chemin de configuration sécuritaire

Le durcissement se fait mieux de manière incrémentale, chaque étape étant vérifiée avant de passer à la suivante. Cette section décrit une approche ciblée : d'abord restreindre l'exposition réseau, puis activer l'authentification, ensuite mettre en œuvre le contrôle d'accès basé sur les rôles, et enfin chiffrer les connexions. Chaque étape comprend des commandes concrètes et des résultats attendus.

Étape 1 : Lier MongoDB à localhost ou à une interface privée

Lier MongoDB à une interface réseau spécifique est le moyen le plus rapide de réduire l'exposition. Si votre application s'exécute sur le même hôte, liez à 127.0.0.1. Si elle s'exécute sur d'autres serveurs d'un réseau privé, liez à l'adresse IP privée. Évitez 0.0.0.0 sauf si vous avez une raison impérieuse.

Modifiez le fichier de configuration (/etc/mongod.conf) et définissez :

net:
  port: 27017
  bindIp: 127.0.0.1  # Changement depuis 0.0.0.0

Ensuite, redémarrez MongoDB avec la commande système appropriée :

sudo systemctl restart mongod

Vérifiez le socket d'écoute :

sudo ss -tulpn | grep mongod

Sortie attendue :

tcp LISTEN 0 128 127.0.0.1:27017 0.0.0.0:* users:(("mongod",pid=1234, fd=10))

Si vous avez besoin d'un accès distant depuis une plage IP spécifique, envisagez d'utiliser un pare-feu (par exemple, iptables ou des groupes de sécurité cloud) au lieu de lier largement. La liaison à localhost est le défaut sûr le plus simple pour un pilote.

Étape 2 : Activer l'authentification et créer un administrateur

MongoDB n'active pas l'authentification par défaut. Pour l'activer, vous devez créer un administrateur utilisateur, puis redémarrer le serveur avec l'option --auth ou security.authorization: enabled dans le fichier de configuration.

Tout d'abord, connectez-vous sans authentification (pendant que le serveur fonctionne encore sans auth) et créez un administrateur :

use admin;
db.createUser({
  user: "siteUserAdmin",
  pwd: "changeMeToAStrongPassword", // remplacez par un mot de passe sécurisé
  roles: [ { role: "userAdminAnyDatabase", db: "admin" } ]
});

Cela crée un utilisateur capable de créer et de gérer des utilisateurs sur n'importe quelle base de données, mais pas de lire ou d'écrire des données d'application. Cette séparation des tâches est importante pour la sécurité.

Ensuite, activez l'autorisation dans le fichier de configuration :

security:
  authorization: enabled

Redémarrez MongoDB :

sudo systemctl restart mongod

Maintenant, connectez-vous en tant qu'administrateur :

mongosh --authenticationDatabase admin -u siteUserAdmin -p 'changeMeToAStrongPassword' --eval 'db.runCommand({ connectionStatus: 1 })'

La sortie attendue montre l'utilisateur authentifié et ses rôles.

Si vous voyez une erreur d'authentification, vérifiez que le mot de passe a été saisi correctement et que l'utilisateur existe dans la base de données admin.

Étape 3 : Mettre en œuvre des rôles à moindre privilège pour les applications

N'utilisez jamais le compte administrateur pour les connexions d'application. Créez plutôt des utilisateurs dédiés avec uniquement les autorisations nécessaires. Par exemple, si votre application lit et écrit uniquement des documents dans une base de données nommée appdb, créez un utilisateur avec le rôle readWrite sur cette base :

use appdb;
db.createUser({
  user: "appUser",
  pwd: "anotherStrongPassword",
  roles: [ { role: "readWrite", db: "appdb" } ]
});

Si l'application a uniquement besoin de lire depuis une base de données de reporting, utilisez le rôle read. Évitez d'accorder le rôle root ou dbAdmin sauf en cas d'absolue nécessité. Vous pouvez également définir des rôles personnalisés pour un contrôle plus fin, mais commencez par les rôles intégrés.

Pour lister les rôles intégrés disponibles, exécutez :

show roles;

Étape 4 : Activer le chiffrement TLS/SSL pour les connexions client

Le chiffrement du trafic entre les clients et MongoDB empêche l'écoute clandestine et le vol d'identifiants. Cette étape nécessite un certificat TLS. Pour un pilote, vous pouvez générer un certificat auto-signé, mais en production, utilisez un certificat signé par une autorité de certification de confiance.

Générez un certificat auto-signé (pour les tests uniquement) :

openssl req -newkey rsa:2048 -new -x509 -days 365 -nodes -out mongodb-cert.crt -keyout mongodb-cert.key
cat mongodb-cert.key mongodb-cert.crt > mongodb.pem
chmod 600 mongodb.pem

Déplacez le fichier mongodb.pem vers un emplacement sécurisé, par exemple /etc/ssl/mongodb.pem, et assurez-vous que l'utilisateur mongod peut le lire. Configurez ensuite MongoDB pour utiliser TLS :

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pem

Redémarrez MongoDB :

sudo systemctl restart mongod

Connectez-vous en utilisant TLS :

mongosh --tls --tlsCAFile /path/to/ca.crt --host <hostname> --authenticationDatabase admin -u siteUserAdmin -p 'changeMeToAStrongPassword'

Pour les certificats auto-signés, vous devrez peut-être utiliser --tlsAllowInvalidCertificates pour les tests. N'utilisez jamais ce drapeau en production.

Étape 5 : Sécuriser le fichier de configuration et les autorisations des clés

Le fichier de configuration MongoDB contient des paramètres sensibles et parfois des informations d'identification (par exemple, pour LDAP ou KMIP). Restreignez ses autorisations :

sudo chmod 600 /etc/mongod.conf
sudo chown mongod:mongod /etc/mongod.conf

Restreignez également l'accès à la clé privée TLS :

sudo chmod 600 /etc/ssl/mongodb.pem
sudo chown mongod:mongod /etc/ssl/mongodb.pem

Choix de mise en œuvre ciblée

Lors du déploiement de ces changements sur plusieurs serveurs, ne changez pas tout en même temps. Choisissez une application et une base de données comme pilote. Appliquez d'abord la liaison réseau et l'authentification, puis testez l'application minutieusement. Ajoutez ensuite TLS et les rôles à moindre privilège. Ce pilote étroit et mesurable réduit le risque de casser le trafic de production et facilite l'identification du changement à l'origine d'un problème en cas de défaillance.

Vérification et diagnostics

Après chaque étape de durcissement, vérifiez que le changement a pris effet et que les opérations légitimes fonctionnent toujours. Cette section fournit des contrôles observables et des résultats attendus.

Vérifier que l'authentification est appliquée

Essayez de vous connecter sans informations d'identification :

mongosh --eval 'db.runCommand({ ping: 1 })'

Résultat attendu : une erreur telle que MongoServerError: command ping requires authentication. Si vous obtenez une réponse { ok: 1 }, l'authentification n'est pas activée.

Vérifier la liaison réseau

Utilisez ss comme indiqué précédemment pour confirmer que l'adresse d'écoute est correcte. De plus, testez la connectivité depuis un hôte distant (le cas échéant) :

nc -zv <mongodb_host_ip> 27017

Si lié à 127.0.0.1 et que vous n'êtes pas sur cet hôte, la connexion doit être refusée. Si lié à une IP privée, seuls les hôtes de ce réseau privé doivent pouvoir se connecter.

Vérifier les rôles et autorisations des utilisateurs

Connectez-vous en tant qu'utilisateur d'application et tentez une opération en dehors de ses autorisations. Par exemple, si appUser a readWrite sur appdb mais pas sur otherdb :

use otherdb;
db.test.insertOne({ x: 1 });

Résultat attendu : MongoServerError: not authorized on otherdb to execute command. Cela confirme que le moindre privilège fonctionne.

Vérifier le chiffrement TLS

Connectez-vous avec l'option --tls et vérifiez les métadonnées de connexion :

// Dans mongosh
db.runCommand({ connectionStatus: 1 }).security;

Si TLS est actif, la sortie comprend "SSLServerHasCertificateAuthority": true (ou similaire selon la version). Alternativement, utilisez openssl s_client pour inspecter le certificat :

echo | openssl s_client -connect <hostname>:27017 -servername <hostname> | openssl x509 -noout -subject -issuer

Vous devriez voir les détails du certificat.

Exécuter une vérification complète avec mongosh

Le script suivant combine plusieurs contrôles. Enregistrez-le sous check_security.js et exécutez-le avec mongosh --file check_security.js (en tant qu'administrateur) :

// check_security.js
print('--- Diagnostics de sécurité ---');

// Vérifier l'état de l'authentification
const connStatus = db.runCommand({ connectionStatus: 1 });
print('Utilisateurs authentifiés :', JSON.stringify(connStatus.authInfo.authenticatedUsers));

// Vérifier si TLS est actif (nécessite des privilèges admin)
const serverStatus = db.adminCommand({ serverStatus: 1 });
print('TLS activé :', serverStatus.security && serverStatus.security.tls ? 'oui' : 'non');

// Lister tous les utilisateurs dans la base admin
const adminDb = db.getSiblingDB('admin');
print('Utilisateurs admin :', JSON.stringify(adminDb.getUsers().map(u => ({ user: u.user, roles: u.roles }))));

// Vérifier si l'autorisation est activée (à partir des paramètres du serveur)
const params = db.adminCommand({ getParameter: '*' });
print('Autorisation activée :', params.authorization);

La sortie attendue comprend votre utilisateur authentifié, une liste d'utilisateurs et authorization: enabled. Si l'un de ces éléments manque, réexécutez l'étape de durcissement appropriée.

Utiliser les journaux MongoDB pour le diagnostic

MongoDB journalise les échecs d'authentification et autres événements de sécurité. Vérifiez le fichier journal (souvent /var/log/mongodb/mongod.log) pour les erreurs :

sudo grep -i 'authentication' /var/log/mongodb/mongod.log | tail -n 20

Exemple de sortie :

2025-01-01T12:00:00.000+0000 I ACCESS [conn123] Successfully authenticated as principal siteUserAdmin on admin

Si vous voyez des messages répétés Authentication failed, résolvez les problèmes d'identifiants ou de chaîne de connexion.

Pièges courants et comment les éviter

Même les administrateurs expérimentés peuvent rencontrer des problèmes lors du durcissement de MongoDB. Voici les erreurs les plus fréquentes et comment les prévenir ou s'en remettre.

Oublier de créer un utilisateur admin avant d'activer l'authentification

Pourquoi cela arrive : Dans la précipitation pour sécuriser le serveur, les administrateurs activent l'autorisation dans le fichier de configuration et redémarrent MongoDB sans créer au préalable d'utilisateur. Le serveur exige alors une authentification pour toutes les connexions, mais aucune information d'identification n'existe, ce qui entraîne un verrouillage complet.

Comment l'éviter : Créez toujours au moins un administrateur utilisateur pendant que le serveur fonctionne encore sans authentification, comme indiqué à l'étape 2. Vérifiez que l'utilisateur existe avec db.getUsers() avant d'activer l'autorisation.

Comment s'en remettre : Désactivez temporairement l'autorisation dans le fichier de configuration, redémarrez MongoDB, créez l'administrateur utilisateur, réactivez l'autorisation et redémarrez à nouveau.

Lier à la mauvaise interface et casser la connectivité de l'application

Pourquoi cela arrive : Lier à 127.0.0.1 sur un serveur où l'application s'exécute sur un hôte différent, ou oublier de mettre à jour la chaîne de connexion après avoir modifié l'adresse de liaison.

Comment l'éviter : Inventoriez l'architecture de votre application avant de modifier l'adresse de liaison. Sachez où se trouvent vos serveurs d'application et quelles IP ils utilisent pour atteindre MongoDB. Si l'application est distante, liez à l'IP privée appropriée ou utilisez un pare-feu pour restreindre l'accès.

Comment s'en remettre : Mettez à jour l'adresse de liaison avec la valeur correcte ou configurez un tunnel SSH temporaire pour rétablir la connectivité, puis corrigez la configuration de manière permanente.

Utiliser des rôles trop larges pour les utilisateurs d'application

Pourquoi cela arrive : La commodité conduit à accorder root ou dbAdmin aux comptes d'application, ou à réutiliser les informations d'identification de l'administrateur dans le code de l'application. Cela va à l'encontre du moindre privilège et augmente le rayon d'impact si l'application est compromise.

Comment l'éviter : Définissez des rôles explicites basés sur les besoins réels de l'application. Commencez par des rôles intégrés comme readWrite sur la base de données spécifique, et n'ajoutez des autorisations que lorsqu'un besoin concret se présente. N'utilisez jamais l'utilisateur admin pour les connexions d'application.

Comment s'en remettre : Auditez les utilisateurs existants avec db.getUsers(), identifiez les comptes avec des privilèges excessifs et remplacez-les par de nouveaux utilisateurs étroitement ciblés. Mettez à jour les chaînes de connexion de l'application en conséquence.

Ignorer l'expiration du certificat TLS

Pourquoi cela arrive : Les certificats auto-signés ou signés par une autorité de certification ont une date d'expiration, et sans surveillance, ils expirent silencieusement, provoquant l'échec des connexions d'application.

Comment l'éviter : Utilisez des certificats à longue validité pour les déploiements internes (par exemple, 1 an) et configurez un rappel de calendrier ou une alerte de surveillance pour les renouveler avant l'expiration. Pour la production, automatisez le renouvellement des certificats avec un outil comme certbot ou votre PKI interne.

Comment s'en remettre : Générez un nouveau certificat, mettez à jour le fichier de configuration et redémarrez MongoDB. Assurez-vous que le nouveau certificat est distribué aux clients en cas d'épinglage de certificat.

Ne pas tester après chaque changement

Pourquoi cela arrive : Les équipes peuvent appliquer plusieurs étapes de durcissement à la fois sans vérifier chacune, ce qui rend difficile d'isoler le changement à l'origine d'une défaillance.

Comment l'éviter : Suivez l'approche incrémentale de ce guide : modifiez un paramètre, redémarrez, exécutez les contrôles de vérification et testez l'application. Ne passez à l'étape suivante qu'après avoir confirmé que l'étape actuelle fonctionne.

Comment s'en remettre : Si un changement combiné casse quelque chose, revenez à la configuration précédente qui fonctionnait et réappliquez les changements un par un pour identifier le coupable.

Liste de contrôle des opérations

Utilisez la liste de contrôle suivante comme examen reproductible avant et après le durcissement, et pour les opérations continues. Le format de tableau vous permet de suivre chaque élément. Attribuez un responsable unique pour chaque vérification et examinez selon une cadence définie.

Effectuez cette liste de contrôle :

• Avant tout changement majeur.
• Après chaque étape de durcissement.
• Mensuellement dans le cadre de l'examen de sécurité de routine.
• Lors de l'intégration de nouveaux membres de l'équipe pour s'assurer qu'ils comprennent la posture de sécurité.

Documentez tout écart et mettez à jour la liste de contrôle si votre environnement change (par exemple, nouvelles bases de données, nouveaux utilisateurs).

Modes de défaillance et récupération

Les changements de durcissement peuvent casser la connectivité des applications ou vous verrouiller. Cette section décrit les modes de défaillance courants et comment s'en remettre.

Verrouillé hors de MongoDB après l'activation de l'authentification

Si vous avez activé l'authentification sans créer au préalable un administrateur utilisateur, vous ne pourrez pas vous authentifier. Pour récupérer, vous devez désactiver temporairement l'autorisation et redémarrer MongoDB pour créer l'utilisateur.

Étapes :

• Modifiez /etc/mongod.conf et mettez en commentaire ou supprimez security.authorization.
• Redémarrez MongoDB : sudo systemctl restart mongod.
• Connectez-vous sans authentification et créez l'administrateur utilisateur comme indiqué à l'étape 2 du chemin de configuration sécuritaire.
• Réactivez l'autorisation et redémarrez à nouveau.

Pour éviter cela, créez toujours au moins un administrateur avant d'activer l'authentification.

L'application ne peut pas se connecter après la liaison à localhost

Si vous liez MongoDB à 127.0.0.1 mais que votre application s'exécute sur un hôte différent, l'application échouera à se connecter. Vérifiez les journaux d'application pour les erreurs de connexion. Pour récupérer, liez à l'IP privée appropriée ou configurez un tunnel sécurisé (par exemple, une redirection de port SSH) comme mesure temporaire. Mettez ensuite à jour la chaîne de connexion de l'application en conséquence.

Les erreurs de configuration TLS provoquent l'échec du démarrage du serveur

Si le chemin du fichier de certificat TLS est incorrect ou si les autorisations sont trop ouvertes, mongod peut ne pas démarrer. Vérifiez les journaux système :

sudo journalctl -u mongod -n 50 --no-pager

Les erreurs typiques comprennent Permission denied ou cannot read certificate file. Corrigez les autorisations du fichier (chmod 600) et la propriété (chown mongod:mongod), ou corrigez le chemin dans le fichier de configuration, puis redémarrez.

Plan de retour en arrière

Avant d'apporter des modifications, documentez la configuration d'origine. Vous pouvez copier /etc/mongod.conf vers un fichier de sauvegarde :

sudo cp /etc/mongod.conf /etc/mongod.conf.bak

Si un changement cause des problèmes, restaurez la configuration d'origine et redémarrez :

sudo cp /etc/mongod.conf.bak /etc/mongod.conf
sudo systemctl restart mongod

Cependant, notez que la désactivation de l'authentification après la création d'utilisateurs ne supprime pas les utilisateurs ; ils restent mais sont ignorés. Si vous réactivez l'authentification plus tard, les mêmes utilisateurs fonctionneront.

Vérification après récupération

Après un retour en arrière ou une correction, réexécutez les contrôles de vérification de la section précédente pour confirmer que le système est dans l'état attendu. Portez une attention particulière à l'authentification et à la liaison réseau.

Conclusion

Le durcissement de MongoDB n'est pas une tâche ponctuelle mais une pratique continue. En suivant les étapes de ce guide, vous avez :

• Inventorié votre version MongoDB, la topologie, les utilisateurs et l'exposition réseau.
• Lié le serveur à une interface sûre, activé l'authentification, créé des utilisateurs à moindre privilège et activé TLS.
• Vérifié chaque changement avec des commandes concrètes et des sorties attendues.
• Préparé des étapes de récupération pour les défaillances courantes et établi une liste de contrôle des opérations reproductible.

Vos prochaines étapes devraient être de :

• Appliquer ces étapes de durcissement à une seule base de données ou application pilote.
• Exécuter le script de vérification complet et la liste de contrôle.
• Tester l'application minutieusement, y compris les scénarios de défaillance.
• Documenter la configuration résultante et partager la liste de contrôle avec votre équipe.
• Planifier des examens réguliers et mettre à jour le durcissement à mesure que votre environnement évolue.

Cette approche pratique et mesurée réduit les risques sans perturbation inutile. Commencez par le pilote étroit, inspectez les résultats, puis étendez à d'autres parties de votre infrastructure. La sécurité est un processus, et chaque étape vérifiée vous rapproche d'une posture plus solide.