Sécurité MongoDB 101 : fonctionnalités clés que tout développeur doit connaître

MongoDB propose un cadre de sécurité complet articulé autour de trois principes clés : l’authentification, l’autorisation et le chiffrement.

Ces piliers forment une défense en profondeur, garantissant qu’une défaillance n’expose pas l’ensemble du système. Le pilier de l’autorisation s’appuie sur le principe du moindre privilège (PoLP), afin que chaque utilisateur ou application ne dispose que des permissions strictement nécessaires pour accomplir ses tâches. 

Mettre en œuvre cette approche globale et en couches renforce sensiblement votre posture de sécurité et réduit le risque d’expositions liées à des erreurs de configuration ou à des compromissions. 

Ouvrir la première barrière : l’authentification

L’authentification est l’étape de base de la sécurité. Elle vérifie l’identité de tout principal tentant de se connecter. Dans MongoDB, cela consiste à activer des fonctionnalités de sécurité qui sont désactivées par défaut pour faciliter le développement local.

1. Comprendre la configuration par défaut

Par défaut, votre déploiement MongoDB n’écoute que sur localhost et autorise l’accès sans authentification. Ce choix est volontaire pour simplifier l’initialisation et l’expérimentation locale.

Pour tout environnement de production, deux paramètres requièrent l’attention des développeurs :

• État de l’authentification : l’authentification est désactivée par défaut. Vous pouvez activer l’autorisation via --auth ou le paramètre security.authorization. L’activation de l’authentification interne active également l’autorisation côté client. Notez qu’une fois le contrôle d’accès activé, les utilisateurs doivent s’authentifier.
• Liaison réseau (bindIp) : Par défaut, les binaires MongoDB (mongod et mongos) ne se lient qu’à localhost. Ce paramètre sécurisé limite les connexions à la même machine. En production, vous devez configurer explicitement bindIp pour lister les adresses IP de vos serveurs applicatifs autorisés. Si vous avez besoin du support IPv6, définissez le paramètre de configuration net.ipv6 ou l’option de ligne de commande --ipv6, ce qui fera également lier le binaire à l’adresse IPv6 localhost. Limitez toujours cette exposition aux interfaces réseau autorisées.

2. Comment activer l’authentification

Activer l’authentification transforme MongoDB d’un bac à sable local en magasin de données sécurisé. Cela se fait en modifiant votre fichier de configuration MongoDB (généralement mongod.conf) puis en redémarrant le serveur.

Paramètre dans le fichier de configuration : définissez l’option d’autorisation dans la section security pour activer la fonctionnalité :

  authorization: enabledPropulsé par

Le premier utilisateur : une fois l’authentification activée, personne ne peut se connecter tant que vous n’avez pas créé un utilisateur administratif. Cet utilisateur initial, crucial, doit être créé dans la base admin, avec les droits nécessaires pour gérer le système et créer d’autres utilisateurs.

3. Gestion des utilisateurs et des mots de passe (createUser)

Après avoir activé l’autorisation, tout accès à la base est régi par les utilisateurs et leurs rôles associés. Vous utilisez la commande createUser pour définir ces identités.

Syntaxe et rôles : lors de la création d’un utilisateur, vous renseignez son nom, son mot de passe et un tableau de rôles. Les rôles définissent ses permissions (par exemple readWrite sur une base donnée).

db.createUser(
   {
     user: "appUser",
     pwd: passwordPrompt(),  // Cette fonction demande un mot de passe,
                                              // évitant de stocker le mot de passe en clair dans
                                              // l'historique du shell et les journaux de commandes.
     roles: [ { role: "readWrite", db: "inventory" } ]
   }
)Propulsé par

Standard SCRAM : MongoDB s’appuie sur le Salted Challenge Response Authentication Mechanism (SCRAM) pour gérer les mots de passe en toute sécurité. SCRAM évite le stockage en clair et utilise un hachage et un salage cryptographiquement robustes, ce qui le rend résistant aux attaques courantes comme les tables arc-en-ciel.

4. Options d’authentification avancées

Pour les organisations avec des exigences de conformité strictes ou des infrastructures complexes, MongoDB s’intègre aux systèmes d’authentification d’entreprise existants :

• Certificats clients x.509 : permettent aux clients de s’authentifier via des certificats numériques plutôt que des mots de passe, offrant une vérification d’identité robuste, souvent utilisée pour la confiance machine-à-machine.
• LDAP/Kerberos : intègre MongoDB à des services externes comme Active Directory ou OpenLDAP, permettant aux utilisateurs de réutiliser leurs identifiants d’entreprise pour accéder à la base.
• Authentification OpenID Connect (OIDC) – Workforce et Workloads : pour les environnements cloud-natifs et hybrides, MongoDB prend en charge l’Identity Federation à la fois pour les Workforce (accès utilisateur via des IdP comme Azure AD, Okta) et les Workload (authentification machine-à-machine via l’identité du fournisseur cloud, p. ex. AWS IAM ou Google Cloud Service Accounts).

Autorisation : définir des rôles avec le RBAC

L’authentification confirme qui est un utilisateur ; l’autorisation détermine ce que cet utilisateur est autorisé à faire. Le système Role-Based Access Control (RBAC) de MongoDB est le mécanisme central de gestion des permissions, garantissant que les utilisateurs et services n’interagissent qu’avec les données et commandes dont ils ont strictement besoin.

1. Contrôle d’accès basé sur les rôles

Dans le modèle RBAC de MongoDB, les permissions sont regroupées en rôles, et ces rôles sont attribués aux utilisateurs. Plutôt que d’attribuer des centaines de permissions individuelles, vous assignez un rôle unique (par ex. inventoryReader) qui inclut automatiquement l’ensemble de permissions défini (par ex. lecture sur inventory.products). La gestion des permissions devient ainsi scalable et traçable.

2. Rôles intégrés utiles à tout développeur

MongoDB propose un ensemble robuste de rôles intégrés couvrant les schémas d’accès les plus courants. Voici quelques exemples ; la liste complète est disponible via le lien ci-dessus.

• read et readWrite (accès au niveau base de données) : rôles les plus courants pour les utilisateurs d’applications. Ils autorisent respectivement les opérations en lecture seule ou en lecture/écriture sur toutes les collections non système d’une base spécifique.
• dbAdmin : confère les droits nécessaires pour administrer une base précise : création, suppression, modification d’index et de collections. Adapté aux équipes de développement ou scripts de maintenance.
• clusterAdmin (accès opérationnel) : rôle à privilèges élevés, généralement réservé aux équipes opérations (DevOps/Ops). Il permet de gérer l’ensemble du déploiement MongoDB : configuration des replica sets, sharding, sauvegardes. Les développeurs applicatifs n’en ont que rarement besoin.

3. Appliquer le principe du moindre privilège

La pierre angulaire de la sécurité moderne des bases de données est le principe du moindre privilège (PoLP). Il impose que chaque utilisateur (en particulier ceux des applications) reçoive exclusivement les permissions indispensables à ses tâches, et rien de plus.

Exemple de bonne pratique : au lieu d’un utilisateur readWrite global, créez des utilisateurs propres à chaque application. Par exemple, si votre service d’inventaire n’accède qu’à la base app_data, l’utilisateur applicatif ne doit recevoir l’accès readWrite que sur cette seule base. Cette compartimentation évite qu’un service compromis accède à d’autres bases (comme billing ou users).

Exemple de code : créer un utilisateur à privilèges minimaux

Cet exemple crée un utilisateur (inventory_service) avec un accès lecture/écriture strictement limité à la base app_data.

use admin
db.createUser(
   {
     user: "inventory_service",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "app_data" }
     ]
   }
)Propulsé par

4. Créer des rôles personnalisés (quand l’intégration ne suffit pas)

Bien que les rôles intégrés soient puissants, la conformité ou une logique applicative complexe peuvent nécessiter un contrôle très granulaire. Dans ces cas, MongoDB permet de définir des rôles personnalisés à l’aide de la commande db.createRole().

Définir des permissions granulaires : les rôles personnalisés permettent de préciser exactement quelles actions (par ex. find, update, insert) peuvent être effectuées sur des ressources au niveau du cluster, de la base ou de la collection. Les organisations peuvent recourir à des techniques comme la rédaction au niveau du champ pour protéger des champs hautement sensibles au sein d’une collection autrement accessible.

Exemple de code : créer un rôle personnalisé

Cet exemple crée un rôle personnalisé (product_creator) autorisé uniquement à insérer des documents dans la collection products de la base app_data.

use app_data
db.createRole(
   {
     role: "product_creator",
     privileges: [
       {
         resource: { db: "app_data", collection: "products" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)Propulsé par

Protection complète des données : isolement réseau et chiffrement

Si l’authentification et l’autorisation fortes contrôlent l’accès à votre base, une sécurité complète exige de protéger les données elles-mêmes — en transit sur le réseau et au repos sur le disque.

1. Protéger les données en transit avec TLS/SSL

Toute transmission sur un réseau, interne au datacenter ou vers le cloud, doit être chiffrée pour prévenir l’écoute clandestine et les attaques de type homme‑du‑milieu (MITM). MongoDB utilise Transport Layer Security/Secure Sockets Layer (TLS/SSL) pour chiffrer toutes les communications entre les clients (votre application) et le serveur.

Sans TLS/SSL, les identifiants, paramètres de requête et résultats sensibles transitent en clair, et sont donc faciles à intercepter. Activer TLS/SSL garantit un chiffrement des données pendant leur transport.

Activer TLS/SSL : cela se fait principalement via la configuration, où vous indiquez les certificats utilisés par le serveur pour vérifier son identité et échanger les clés de chiffrement :

net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/ssl/mongodb.pemPropulsé par

• net.ssl.mode : requireTLS force toutes les connexions entrantes à utiliser TLS/SSL, en rejetant les tentatives non sécurisées.
• certificateKeyFile pointe vers votre certificat TLS/SSL et, le cas échéant, vers le fichier de l’autorité de certification.

2. Pare-feu et segmentation réseau

La segmentation réseau fournit une couche de défense essentielle en limitant les interfaces physiques ou virtuelles pouvant se connecter à la base. Même si un attaquant accède au réseau, il doit encore franchir votre périmètre.

• Restreindre l’accès via des listes blanches d’IP : à l’aide du paramètre bindIp ou de pare-feu réseau, vous pouvez autoriser uniquement certaines adresses IP.
• Bonne pratique : le serveur MongoDB doit uniquement être exposé à vos serveurs applicatifs, à votre load balancer ou à votre couche proxy. Il ne doit jamais être accessible directement depuis Internet. Cette segmentation place la base derrière le périmètre de sécurité de votre infrastructure applicative.

3. Chiffrement au repos (chiffrement du moteur de stockage)

Protéger les données au repos garantit que si le disque physique ou l’hôte est compromis, les fichiers restent illisibles. MongoDB y parvient via le chiffrement du moteur de stockage.

• Fonctionnement : le moteur de stockage WiredTiger peut être configuré pour chiffrer tous les fichiers de données, de configuration et de journalisation sur le disque. Les données sont chiffrées à l’écriture et déchiffrées à la lecture de manière transparente, avec une clé gérée par le système.
• Point d’attention crucial : bien que critique, le chiffrement natif au repos est généralement une fonctionnalité MongoDB Enterprise, et il s’appuie sur des serveurs KMIP (Key Management Interoperability Protocol) externes ou des fichiers de clés locaux pour la gestion des clés.

4. Client-Side Field Level Encryption (CSFLE) : la référence pour les développeurs

Alors que le chiffrement au repos protège l’ensemble de la base, le Client-Side Field Level Encryption (CSFLE) offre aux développeurs une précision chirurgicale : ils peuvent chiffrer des champs spécifiques avant leur envoi à la base.

• Présentation du CSFLE : avec CSFLE, le chiffrement s’effectue dans le driver applicatif avant que les données ne quittent le serveur applicatif. Le serveur MongoDB ne voit jamais les données sensibles en clair ; il stocke uniquement le chiffrogramme. Les données restent chiffrées en permanence côté serveur, y compris en mémoire, dans les journaux et sur le stockage.
• L’outil le plus puissant des développeurs : CSFLE est la référence pour la conformité (p. ex. RGPD, HIPAA), car même en cas de compromission totale de la base, les champs sensibles (PII, informations financières) demeurent chiffrés et protégés. Les développeurs doivent décider activement quoi chiffrer, en intégrant la logique directement dans leur code.

5. Chiffrement en usage avec Queryable Encryption

Queryable Encryption est une évolution du CSFLE qui répond au défi d’interroger des champs chiffrés. Elle permet d’effectuer des requêtes d’égalité (par ex. trouver les documents où un champ chiffré égale une valeur donnée) directement sur le chiffrogramme. Vous bénéficiez ainsi de la sécurité du CSFLE tout en préservant l’utilité des données, avec un chiffrement effectif des données « en usage ».

Audit : l’outil d’après‑incident

Les mesures de sécurité visent la prévention ; l’audit apporte responsabilité et détection. Le framework d’audit intégré de MongoDB permet de tracer et journaliser les événements liés à la sécurité, fournissant un enregistrement infalsifiable essentiel à la forensique, à la conformité et à la détection proactive des menaces.

1. Qu’est-ce que l’audit et pourquoi est-ce important ?

L’audit journalise chaque action critique effectuée sur la base, créant un historique détaillé. Cela inclut :

• Événements d’authentification : tentatives de connexion réussies et échouées.
• Modifications d’autorisation : création, modification ou suppression d’utilisateurs et de rôles.
• Changements de configuration : modifications de paramètres système ayant un impact sur la sécurité.

Ce journal est inestimable pour les équipes sécurité lors d’analyses post‑incident (l’« outil d’autopsie ») ou pour répondre aux exigences réglementaires.

2. Configuration et filtrage

Activer l’audit est simple : une ligne dans le fichier de configuration suffit souvent à activer le système et à préciser la destination du journal (fichier, syslog ou console).

auditLog:
  destination: file
  format: BSON
  path: /var/log/mongodb/audit.bson
  filter: '{ atype: { $in: [ "authenticate", "createRole", "dropUser" ] } }'Propulsé par

• Filtrage : le système d’audit permet un filtrage très granulaire via une syntaxe proche des requêtes. C’est crucial pour maîtriser le volume des logs. Les développeurs doivent cibler les événements critiques liés à la sécurité : gestion des utilisateurs, changements de configuration de sécurité et tentatives d’authentification.

Résumé et prochaines étapes

MongoDB propose un ensemble complet de fonctionnalités de sécurité qui, correctement déployées, constituent une stratégie de défense en profondeur efficace. Votre mission, en tant que développeur, est d’aller au‑delà des réglages par défaut et de mettre en œuvre ces contrôles essentiels.

Avant toute mise en production, gardez en tête ces trois impératifs :

• Chiffrer les données en transit : utilisez TLS/SSL pour toutes les connexions réseau (net.ssl.mode : requireTLS).
• Chiffrer les données au repos : sécurisez les fichiers de base sur disque via un chiffrement au niveau volume/système de fichiers ou via le chiffrement du moteur WiredTiger (disponible dans MongoDB Enterprise) pour contrer tout accès non autorisé aux fichiers.
• Chiffrer les données en usage : utilisez le Client-Side Field Level Encryption (CSFLE) et Queryable Encryption pour les champs hautement sensibles, afin qu’ils demeurent chiffrés même lorsque la base fonctionne.

La sécurité évolue en permanence. Pour aller plus loin et affiner vos configurations, appuyez-vous sur la documentation officielle :

• MongoDB Security center : explorez les guides de durcissement des déploiements et des pratiques opérationnelles.
• Documentation sur le chiffrement en usage : découvrez comment mettre en œuvre le Client-Side Field Level Encryption (CSFLE) et sa fonctionnalité avancée, ainsi que Queryable Encryption (QE), pour garantir la confidentialité de vos données sensibles tout en les interrogeant efficacement lorsqu’elles sont utilisées.

Je vous recommande également le cours Introduction to Using MongoDB for Data Science in Python.