Contrôle d’accès basé sur les rôles (RBAC) dans MongoDB

À mesure que la vie en ligne s’intensifie, le besoin de définir précisément des autorisations et des rôles augmente pour sécuriser et contrôler l’accès aux applications et aux systèmes. Le contrôle d’accès basé sur les rôles (RBAC) est un modèle d’autorisation qui régule l’accès aux ressources en fonction des rôles prédéfinis des utilisateurs.

Avec le modèle RBAC de MongoDB, les actions sont regroupées sous forme de rôles, puis attribuées aux bons utilisateurs. Par exemple, plutôt que d’accorder plusieurs autorisations individuelles, vous pouvez attribuer un rôle unique (p. ex. dbAdmin) qui inclut automatiquement l’ensemble d’autorisations défini (p. ex. lecture des collections d’une base). Ce modèle simplifie et fiabilise la gestion des accès à grande échelle.

Activer RBAC dans MongoDB

Avec le modèle RBAC, l’accès est refusé par défaut : sans rôle, un utilisateur ne peut accéder à aucune ressource. Un utilisateur peut se voir attribuer plusieurs rôles, chacun donnant un ensemble précis de privilèges ou d’autorisations pour certaines fonctionnalités.

Concepts clés du RBAC

Voici les notions essentielles à connaître sur le RBAC :

Utilisateurs

Dans le modèle RBAC, un utilisateur est une entité à laquelle un ou plusieurs rôles sont accordés, ces rôles déterminant son accès aux ressources et opérations de la base de données. Sans assignation de rôle, un utilisateur n’a aucun accès au système. Pour y accéder, il doit s’authentifier et se voir attribuer au minimum un rôle.

Rôles

MongoDB propose des rôles et privilèges intégrés pour les déploiements autogérés comme pour MongoDB Atlas. Parmi les rôles intégrés courants : read, readWrite et les rôles dbAdmin/atlasAdmin. Les rôles d’administration de base de données disposent de privilèges plus élevés que les autres rôles, y compris la gestion des privilèges des autres rôles.

Si ces rôles intégrés ne couvrent pas exactement vos besoins, MongoDB permet de créer et modifier des rôles définis par l’utilisateur.

Un rôle est un ensemble de privilèges attribués à l’utilisateur.

Par exemple, un rôle « read » peut n’accorder que la lecture, un rôle « admin » peut accorder la lecture et l’écriture, tandis que le rôle « owner » peut permettre la lecture, l’écriture et la suppression sur un élément donné (base de données, document, etc.). Un rôle donne donc les privilèges nécessaires pour effectuer des actions précises sur des ressources. Chaque privilège peut être défini explicitement dans le rôle, hérité d’un autre rôle, ou les deux.

Rôles définis par l’utilisateur / rôles personnalisés

MongoDB fournit de nombreux rôles intégrés que les administrateurs peuvent utiliser pour contrôler l’accès à un système MongoDB. Cependant, si les rôles existants ne décrivent pas exactement les privilèges souhaités, vous pouvez définir et attribuer de nouveaux rôles à des utilisateurs d’une base de données : c’est un rôle personnalisé. À l’exception des rôles créés dans la base admin, un rôle ne peut inclure que des privilèges applicables à sa propre base et ne peut hériter que d’autres rôles de cette même base.

Pour créer un nouveau rôle, utilisez la méthode db.createRole(), en précisant les privilèges dans le tableau privileges et les rôles hérités dans le tableau roles.

MongoDB combine le nom de la base et le nom du rôle pour l’identifier de manière unique, et stocke toutes les informations de rôle dans la collection admin.system.roles de la base admin.

Exemple : cet exemple crée un rôle personnalisé (sales_attendant) autorisé uniquement à insérer des documents dans la collection sales de la base sales_db.

use sales
db.createRole(
   {
     role: "sales_attendant",
     privileges: [
       {
         resource: { db: "sales_db", collection: "sales" },
         actions: [ "insert" ]
       }
     ],
     roles: []
   }
)

Rôles intégrés 

Les rôles intégrés sont des rôles prédéfinis que l’on attribue aux utilisateurs pour leur permettre d’effectuer des opérations telles que la lecture et l’écriture sur les collections d’une base. Exemples : read, write, readWrite, dbAdmin et readAnyDatabase.

• read et readWrite (accès au niveau base) : ces rôles accordent respectivement la lecture seule ou la lecture/écriture sur toutes les collections non système d’une base spécifiée.
• dbAdmin : ce rôle donne les droits d’administration nécessaires à la gestion d’une base donnée, comme créer, supprimer et modifier des index et des collections. Il convient aux équipes de développement ou aux 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, notamment la création de sauvegardes périodiques, la configuration des ensembles de réplicas et le sharding.

Privilèges (autorisations)

Les privilèges sont un ensemble d’actions (p. ex. find, insert) autorisées sur une capacité.

Par exemple, si la capacité est « informer le client de son solde actuel », alors les privilèges de l’utilisateur (disons le guichetier) pourraient être en lecture seule. Si la capacité est d’augmenter le plafond de transactions d’un compte bancaire, les privilèges pourraient être lecture et écriture.

Privilèges hérités

Un rôle peut inclure un ou plusieurs rôles existants (avec tous leurs privilèges). Par exemple, un rôle dbAdmin peut inclure des rôles read, write et update (chacun pouvant être défini séparément) et hériter de leurs privilèges.

Ressources

Une ressource peut être une base de données, une collection, un ensemble de collections, ou le cluster.

Appliquer le principe du moindre privilège

En sécurité des bases modernes, le principe du moindre privilège (PoLP) est essentiel : chaque utilisateur ne doit disposer que des autorisations strictement nécessaires à ses tâches.

Bonnes pratiques : plutôt qu’un utilisateur global readWrite, créez des utilisateurs spécifiques à chaque application. Par exemple, si votre service d’inventaire n’interagit qu’avec la base app_data, l’utilisateur applicatif ne doit recevoir un accès readWrite que sur cette base unique. Cette compartimentation empêche un service compromis d’accéder indûment à d’autres bases (comme billing ou users).

Exemple de code :

Création d’un utilisateur à moindres privilèges. Cet exemple crée un utilisateur (branch_manager) avec des droits de lecture/écriture strictement limités à la base bank_data.

use admin
db.createUser(
   {
     user: "branch_manager",
     pwd: passwordPrompt(),
     roles: [ 
       { role: "readWrite", db: "bank_data" }
     ]
   }
)

Bonnes pratiques

• Définissez en amont des rôles et des politiques clairs, puis attribuez-les.
• Appliquez le principe du moindre privilège pour une sécurité renforcée.
• Utilisez les rôles intégrés quand c’est possible ; auditez régulièrement les rôles attribués pour détecter les anomalies.