Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Accès à la base de données à l'aide du contrôle d'accès basé sur les rôles
Vous pouvez restreindre l'accès aux actions que les utilisateurs peuvent effectuer sur les bases de données à l'aide du *contrôle d'accès basé sur les rôles* (RBAC) dans Amazon DocumentDB (avec compatibilité avec MongoDB). Le RBAC fonctionne en accordant un ou plusieurs rôles à un utilisateur. Ces rôles déterminent les opérations qu'un utilisateur peut effectuer sur les ressources de base de données. Amazon DocumentDB prend actuellement en charge à la fois les rôles intégrés définis au niveau de la base de données, tels que,,`read`, `readWrite` `readAnyDatabase``clusterAdmin`, et les rôles définis par l'utilisateur pouvant être étendus à des actions spécifiques, ainsi que des ressources granulaires telles que des collections en fonction de vos besoins.
Les cas d'utilisation courants du RBAC incluent l'application des privilèges minimaux en créant des utilisateurs ayant un accès en lecture seule aux bases de données ou aux collections d'un cluster, et les conceptions d'applications multi-locataires qui permettent à un seul utilisateur d'accéder à une base de données ou à une collection donnée dans un cluster.
**Note**
Tous les nouveaux utilisateurs créés avant le **26 mars 2020** ont reçu les rôles `clusterAdmin`, `dbAdminAnyDatabase` et `readWriteAnyDatabase`. Il est recommandé de réévaluer tous les utilisateurs existants et de modifier les rôles si nécessaire pour appliquer le principe du moindre privilège pour vos clusters.
**Topics**
+ [
## Concepts du RBAC
](#role_based_access_control-concepts)
+ [
## Commencer à utiliser les rôles intégrés au RBAC
](#role_based_access_control-getting_started)
+ [
## Commencer à utiliser les rôles définis par l'utilisateur du RBAC
](#w2aac29c29c15)
+ [
## Connexion à Amazon DocumentDB en tant qu'utilisateur
](#role_based_access_control-connecting_as_user)
+ [
## Commandes communes
](#role_based_access_control-common_commands)
+ [
## Différences fonctionnelles
](#role_based_access_control-functional_differences)
+ [
## Restrictions
](#role_based_access_control-limits)
+ [
## Accès à la base de données à l'aide du contrôle d'accès basé sur les rôles
](#role_based_access_control-built_in_roles)
## Concepts du RBAC
Voici des termes et concepts importants liés au contrôle d'accès basé sur les rôles. Pour plus d'informations sur les utilisateurs d'Amazon DocumentDB, consultez. [Gestion des utilisateurs d'Amazon DocumentDB](security.managing-users.md)
+ **Utilisateur** : entité individuelle capable de s'authentifier auprès de la base de données et d'effectuer des opérations.
+ **Mot de passe** : secret utilisé pour authentifier l'utilisateur.
+ **Rôle** : autorise un utilisateur à effectuer des actions sur une ou plusieurs bases de données.
+ **Base de données d'administration** : base de données dans laquelle les utilisateurs sont enregistrés et autorisés.
+ **Database (`db`)** — L'espace de noms au sein des clusters qui contient des collections pour le stockage de documents.
La commande suivante permet de créer un utilisateur nommé `sample-user`.
```
db.createUser({user: "sample-user", pwd: "abc123", roles: [{role: "read", db: "sample-database"}]})
```
Dans cet exemple :
+ `user: "sample-user"`— Indique le nom d'utilisateur.
+ `pwd: "abc123"`— Indique le mot de passe de l'utilisateur.
+ `role: "read", "db: "sample-database"`— Indique que l'utilisateur `sample-user` disposera d'autorisations de lecture`sample-database`.
![\[Exemple de code montrant une commande createUser indiquant le nom d'utilisateur, le mot de passe et les autorisations.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/rbac-createuser-command.png)
L'exemple suivant présente la sortie après l’obtention de l'utilisateur `sample-user` avec `db.getUser(sample-user)`. Dans cet exemple, l'utilisateur `sample-user` réside dans la base de données `admin` mais possède le rôle de lecture pour la base de données `sample-database`.
![\[Exemple de sortie de code montrant le résultat de la commande CreateUser définissant le nouvel ID utilisateur, la base de données d'administration à laquelle le nouvel utilisateur est affecté et les autorisations de rôle appliquées à l'utilisateur.\]](http://docs.aws.amazon.com/fr_fr/documentdb/latest/developerguide/images/rbac-createuser-output-json.png)
Lorsque vous créez des utilisateurs, si vous omettez le `db` champ lorsque vous spécifiez le rôle, Amazon DocumentDB attribuera implicitement le rôle à la base de données dans laquelle la connexion est établie. Par exemple, si votre connexion est émise sur la base de données `sample-database` et que vous exécutez la commande suivante, l'utilisateur `sample-user` sera créé dans la base de données `admin` et aura des autorisations `readWrite` sur la base de données `sample-database`.
```
db.createUser({user: "sample-user", pwd: "abc123", roles: ["readWrite"]})
```
Le résultat de cette opération ressemble à ceci.
```
{
"user":"sample-user",
"roles":[
{
"db":"sample-database",
"role":"readWrite"
}
]
}
```
La création d'utilisateurs avec des rôles étendus à toutes les bases de données (par exemple, `readAnyDatabase`) nécessite que vous soyez dans le contexte de la base de données `admin` lors de la création de l'utilisateur, ou que vous indiquiez explicitement la base de données pour le rôle lors de la création de l'utilisateur. Pour émettre des commandes sur la base de données `admin`, vous pouvez utiliser la commande `use admin`. Pour de plus amples informations, veuillez consulter [Commandes communes](#role_based_access_control-common_commands).
## Commencer à utiliser les rôles intégrés au RBAC
Pour vous aider à démarrer avec le contrôle d'accès basé sur les rôles, cette section vous guide à travers un exemple de scénario d'application du principe du moindre privilège en créant des rôles pour trois utilisateurs aux fonctions de travail différentes.
+ `user1` est un nouveau responsable qui doit pouvoir afficher et accéder à toutes les bases de données d'un cluster.
+ `user2` est un nouvel employé qui a besoin d'accéder à une seule base de données, `sample-database-1`, dans ce même cluster.
+ `user3` est un employé existant qui doit afficher et accéder à une base de données différente, `sample-database-2`, à laquelle il n'avait pas accès auparavant, dans le même cluster.
Plus tard, `user1` et `user2` quitteront la société et leur accès devra donc être révoqué.
Pour créer des utilisateurs et accorder des rôles, l'utilisateur avec lequel vous vous authentifiez auprès du cluster doit avoir un rôle associé pouvant effectuer des actions pour `createUser` et `grantRole`. Par exemple, les rôles `admin` et `userAdminAnyDatabase` peuvent tous les deux accorder ces autorisations. Pour les actions par rôle, veuillez consulter [Accès à la base de données à l'aide du contrôle d'accès basé sur les rôles](#role_based_access_control-built_in_roles).
**Note**
Dans Amazon DocumentDB, toutes les opérations relatives aux utilisateurs et aux rôles (par exemple,`create`,,`get`,`drop`, `grant``revoke`, etc.) sont implicitement effectuées dans la `admin` base de données, que vous émettiez ou non des commandes sur la base de données. `admin`
Tout d'abord, pour comprendre quels sont les utilisateurs et les rôles actuels dans le cluster, vous pouvez exécuter la commande `show users`, comme dans l'exemple suivant. Vous verrez deux utilisateurs, `serviceadmin` ainsi que l'utilisateur principal du cluster. Ces deux utilisateurs existent toujours et ne peuvent pas être supprimés. Pour de plus amples informations, veuillez consulter [Gestion des utilisateurs d'Amazon DocumentDB](security.managing-users.md).
```
show users
```
Pour `user1`, créez un rôle avec un accès en lecture et en écriture sur toutes les bases de données de l'ensemble du cluster à l'aide de la commande suivante.
```
db.createUser({user: "user1", pwd: "abc123", roles: [{role: "readWriteAnyDatabase", db: "admin"}]})
```
Le résultat de cette opération ressemble à ceci.
```
{
"user":"user1",
"roles":[
{
"role":"readWriteAnyDatabase",
"db":"admin"
}
]
}
```
Pour `user2`, créez un rôle avec un accès en lecture seule sur la base de données `sample-database-1` à l'aide de la commande suivante.
```
db.createUser({user: "user2", pwd: "abc123", roles: [{role: "read", db: "sample-database-1"}]})
```
Le résultat de cette opération ressemble à ceci.
```
{
"user":"user2",
"roles":[
{
"role":"read",
"db":"sample-database-1"
}
]
}
```
Pour simuler le scénario où `user3` est un utilisateur existant, créez d'abord l'utilisateur `user3`, puis affectez un nouveau rôle à `user3`.
```
db.createUser({user: "user3", pwd: "abc123", roles: [{role: "readWrite", db: "sample-database-1"}]})
```
Le résultat de cette opération ressemble à ceci.
```
{
"user":"user3",
"roles":[
{
"role":"readWrite",
"db":"sample-database-1"
}
]
}
```
Maintenant que l'utilisateur `user3` a été créé, affectez à `user3` le rôle `read` sur `sample-database-2`.
```
db.grantRolesToUser("user3", [{role: "read", db: "sample-database-2"}])
```
Enfin, `user1` et `user2` quittent l'entreprise, leur accès au cluster doit donc être révoqué. Pour ce faire, vous pouvez supprimer les utilisateurs, comme suit.
```
db.dropUser("user1")
db.dropUser("user2")
```
Pour vous assurer que tous les utilisateurs disposent des rôles appropriés, vous pouvez répertorier tous les utilisateurs avec la commande suivante.
```
show users
```
Le résultat de cette opération ressemble à ceci.
```
{
"_id":"serviceadmin",
"user":"serviceadmin",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"master-user",
"user":"master-user",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"user3",
"user":"user3",
"db":"admin",
"roles":[
{
"db":"sample-database-2",
"role":"read"
},
{
"db":"sample-database-1",
"role":"readWrite"
}
]
}
```
## Commencer à utiliser les rôles définis par l'utilisateur du RBAC
Pour vous aider à démarrer avec les rôles définis par l'utilisateur, cette section présente un exemple de scénario d'application du moindre privilège en créant des rôles pour trois utilisateurs ayant des fonctions différentes.
Dans cet exemple, les règles suivantes s'appliquent :
+ `user1` est un nouveau responsable qui doit pouvoir afficher et accéder à toutes les bases de données d'un cluster.
+ `user2`est un nouvel employé qui n'a besoin que de l'action « rechercher » sur une seule base de données`sample-database-1`, dans le même cluster.
+ `user3`est un employé existant qui doit consulter et accéder à une collection spécifique, col2, dans une base de données différente, à `sample-database-2` laquelle il n'avait pas accès auparavant, dans le même cluster.
+ Pour `user1`, créez un rôle avec un accès en lecture et en écriture sur toutes les bases de données de l'ensemble du cluster à l'aide de la commande suivante.
```
db.createUser(
{
user: "user1", pwd: "abc123",
roles: [{role: "readWriteAnyDatabase", db: "admin"}]
}
)
```
Le résultat de cette opération ressemble à ceci.
```
{
"user":"user1",
"roles":[
{
"role":"readWriteAnyDatabase",
"db":"admin"
}
]
}
```
Pour `user2` créer un rôle doté des privilèges « find » pour toutes les collections de la base de données à l'`sample-database-1`aide de la commande suivante. Notez que ce rôle garantit que les utilisateurs associés ne peuvent exécuter que des requêtes de recherche.
```
db.createRole(
{
role: "findRole",
privileges: [
{
resource: {db: "sample-database-1", collection: ""}, actions: ["find"]
}],
roles: []
}
)
```
Le résultat de cette opération ressemble à ceci.
```
{
"role":"findRole",
"privileges":[
{
"resource":{
"db":"sample-database-1",
"collection":""
},
"actions":[
"find"
]
}
],
"roles":[
]
}
```
Créez ensuite l'utilisateur (`user2`) et associez le rôle récemment créé `findRole` à l'utilisateur.
```
db.createUser(
{
user: "user2",
pwd: "abc123",
roles: []
})
db.grantRolesToUser("user2",["findRole"])
```
Pour simuler le scénario d'un utilisateur existant, créez d'abord l'utilisateur`user3`, puis créez un nouveau rôle appelé CollectionRole que nous allons attribuer à l'étape suivante. `user3` `user3`
Vous pouvez désormais attribuer un nouveau rôle à`user3`. Ce nouveau rôle permettra d'insérer, de mettre `user3` à jour, de supprimer et de trouver l'accès à une collection spécifique dans `sample-database-2` laquelle col2 est installé.
```
db.createUser(
{
user: "user3",
pwd: "abc123",
roles: []
})
db.createRole(
{
role: "collectionRole",
privileges: [
{
resource: {db: "sample-database-2", collection: "col2"}, actions: ["find", "update", "insert", "remove"]
}],
roles: []
}
)
```
Le résultat de cette opération ressemble à ceci.
```
{
"role":"collectionRole",
"privileges":[
{
"resource":{
"db":"sample-database-2",
"collection":"col2"
},
"actions":[
"find",
"update",
"insert",
"remove"
]
}
],
"roles":[
]
}
```
Maintenant que l'utilisateur `user3` a été créé, vous pouvez lui attribuer `user3` le rôle`collectionFind`.
```
db.grantRolesToUser("user3",["collectionRole"])
```
Enfin, `user1` et `user2` quittent l'entreprise, leur accès au cluster doit donc être révoqué. Pour ce faire, vous pouvez supprimer les utilisateurs, comme suit.
```
db.dropUser("user1")
db.dropUser("user2")
```
Pour vous assurer que tous les utilisateurs disposent des rôles appropriés, vous pouvez répertorier tous les utilisateurs avec la commande suivante.
```
show users
```
Le résultat de cette opération ressemble à ceci.
```
{
"_id":"serviceadmin",
"user":"serviceadmin",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"master-user",
"user":"master-user",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"root"
}
]
}
{
"_id":"user3",
"user":"user3",
"db":"admin",
"roles":[
{
"db":"admin",
"role":"collectionRole"
}
]
}
```
## Connexion à Amazon DocumentDB en tant qu'utilisateur
Lorsque vous vous connectez à un cluster Amazon DocumentDB, vous vous connectez dans le contexte d'une base de données particulière. Par défaut, si vous ne spécifiez pas de base de données dans votre chaîne de connexion, vous êtes automatiquement connecté au cluster dans le contexte de la base de données `test`. Toutes les commandes de niveau collection comme `insert` et `find` sont émises sur les collections dans la base de données `test`.
Pour voir la base de données dans laquelle vous vous trouvez ou, en d'autres termes, pour émettre des commandes, utilisez la `db` commande dans le shell mongo, comme suit.
Interrogation :
```
db
```
Sortie :
```
test
```
Bien que la connexion par défaut puisse être associée au contexte de la base de données `test`, cela ne signifie pas nécessairement que l'utilisateur associé à la connexion est autorisé à effectuer des actions sur la base de données `test`. Dans l'exemple de scénario précédent, si vous vous authentifiez en tant qu'utilisateur `user3`, auquel le rôle `readWrite` a été attribué pour la base de données `sample-database-1`, le contexte par défaut de votre connexion est la base de données `test`. Toutefois, si vous essayez d'insérer un document dans une collection de la base de données `test`, un message d'erreur d'*échec d'autorisation* s'affiche. En effet, cet utilisateur n'est pas autorisé à exécuter cette commande sur cette base de données, comme indiqué ci-dessous.
Interrogation :
```
db
```
Sortie :
```
test
```
Interrogation :
```
db.col.insert({x:1})
```
Sortie :
```
WriteCommandError({ "ok" : 0, "code" : 13, "errmsg" : "Authorization failure" })
```
Si vous modifiez le contexte de votre connexion à la base de données `sample-database-1`, vous pouvez écrire dans la collection pour laquelle l'utilisateur a reçu l'autorisation.
Interrogation :
```
use sample-database-1
```
Sortie :
```
switched to db sample-database-1
```
Interrogation :
```
db.col.insert({x:1})
```
Sortie :
```
WriteResult({ "nInserted" : 1})
```
Lorsque vous vous authentifiez auprès d'un cluster avec un utilisateur particulier, vous pouvez également spécifier la base de données dans la chaîne de connexion. Cela supprime la nécessité d'exécuter la commande `use` après l'authentification de l'utilisateur sur la base de données `admin`.
La chaîne de connexion suivante authentifie l'utilisateur par rapport à la base de données `admin`, mais le contexte de la connexion sera celui de la base de données `sample-database-1`.
```
mongo "mongodb://user3:abc123@sample-cluster.node.us-east-1.docdb.amazonaws.com:27017/sample-database-2"
```
## Commandes communes
Cette section fournit des exemples de commandes courantes utilisant le contrôle d'accès basé sur les rôles dans Amazon DocumentDB. Vous devez être dans le contexte de la base de données `admin` pour créer et modifier des utilisateurs et des rôles. Vous pouvez utiliser la commande `use admin` pour basculer vers la base de données `admin`.
**Note**
Les modifications apportées aux utilisateurs et aux rôles se produiront implicitement dans la base de données `admin`. La création d'utilisateurs avec des rôles étendus à toutes les bases de données (par exemple, `readAnyDatabase`) nécessite que vous soyez soit dans le contexte de la base de données `admin` (c'est-à-dire, `use admin`) lors de la création de l'utilisateur, ou que vous indiquiez explicitement la base de données pour le rôle lors de la création de l'utilisateur (comme indiqué dans l'exemple 2 de cette section).
**Exemple 1** : créer un utilisateur avec un `read` rôle pour la base de données`foo`.
```
db.createUser({user: "readInFooBar", pwd: "abc123", roles: [{role: "read", db: "foo"}]})
```
Le résultat de cette opération ressemble à ceci.
```
{
"user":"readInFooBar",
"roles":[
{
"role":"read",
"db":"foo"
}
]
}
```
**Exemple 2** : créez un utilisateur avec un accès en lecture sur toutes les bases de données.
```
db.createUser({user: "readAllDBs", pwd: "abc123", roles: [{role: "readAnyDatabase", db: "admin"}]})
```
Le résultat de cette opération ressemble à ceci.
```
{
"user":"readAllDBs",
"roles":[
{
"role":"readAnyDatabase",
"db":"admin"
}
]
}
```
**Exemple 3** : Accorder un `read` rôle à un utilisateur existant sur une nouvelle base de données.
```
db.grantRolesToUser("readInFooBar", [{role: "read", db: "bar"}])
```
**Exemple 4** : mettre à jour le rôle d'un utilisateur.
```
db.updateUser("readInFooBar", {roles: [{role: "read", db: "foo"}, {role: "read", db: "baz"}]})
```
**Exemple 5** : Révoquer l'accès à une base de données pour un utilisateur.
```
db.revokeRolesFromUser("readInFooBar", [{role: "read", db: "baz"}])
```
**Exemple 6** : Décrivez un rôle intégré.
```
db.getRole("read", {showPrivileges:true})
```
Le résultat de cette opération ressemble à ceci.
```
{
"role":"read",
"db":"sample-database-1",
"isBuiltin":true,
"roles":[
],
"inheritedRoles":[
],
"privileges":[
{
"resource":{
"db":"sample-database-1",
"collection":""
},
"actions":[
"changeStream",
"collStats",
"dbStats",
"find",
"killCursors",
"listCollections",
"listIndexes"
]
}
],
"inheritedPrivileges":[
{
"resource":{
"db":"sample-database-1",
"collection":""
},
"actions":[
"changeStream",
"collStats",
"dbStats",
"find",
"killCursors",
"listCollections",
"listIndexes"
]
}
}
```
**Exemple 7** : Supprimer un utilisateur du cluster.
```
db.dropUser("readInFooBar")
```
Le résultat de cette opération ressemble à ceci.
```
true
```
**Exemple 8** : Création d'un rôle avec accès en lecture et en écriture à une collection spécifique
```
db.createRole(
{
role: "collectionRole",
privileges: [
{
resource: {db: "sample-database-2", collection: "col2"}, actions: ["find", "update", "insert", "remove"]
}],
roles: []
}
)
```
Le résultat de cette opération ressemble à ceci.
```
{
"role":"collectionRole",
"privileges":[
{
"resource":{
"db":"sample-database-2",
"collection":"col2"
},
"actions":[
"find",
"update",
"insert",
"remove"
]
}
],
"roles":[
]
}
```
**Exemple 9** : Création d'un utilisateur et attribution d'un rôle défini par l'utilisateur
```
db.createUser(
{
user: "user3",
pwd: "abc123",
roles: []
})
db.grantRolesToUser("user3",["collectionRole"])
```
**Exemple 10** : Accorder des privilèges supplémentaires à un rôle défini par l'utilisateur
```
db.grantPrivilegesToRole(
"collectionRole",
[
{
resource: { db: "sample-database-1", collection: "col1" },
actions: ["find", "update", "insert", "remove"]
}
]
)
```
**Exemple 11** : Supprimer les privilèges d'un rôle défini par l'utilisateur
```
db.revokePrivilegesFromRole(
"collectionRole",
[
{
resource: { db: "sample-database-1", collection: "col2" },
actions: ["find", "update", "insert", "remove"]
}
]
)
```
**Exemple 12** : Mettre à jour un rôle défini par l'utilisateur existant
```
db.updateRole(
"collectionRole",
{
privileges: [
{
resource: {db: "sample-database-3", collection: "sample-collection-3"}, actions: ["find", "update", "insert", "remove"]
}],
roles: []
}
)
```
## Différences fonctionnelles
Dans Amazon DocumentDB, les définitions des utilisateurs et des rôles sont stockées dans la `admin` base de données et les utilisateurs sont authentifiés par rapport à la base de données. `admin` Cette fonctionnalité diffère de MongoDB Community Edition, mais est compatible avec MongoDB Atlas.
Amazon DocumentDB prend également en charge les flux de modifications, qui fournissent une séquence chronologique des événements de modification qui se produisent dans les collections de votre cluster. L'`listChangeStreams`action est appliquée au niveau du cluster (c'est-à-dire dans toutes les bases de données), et l'`modifyChangeStreams`action peut être appliquée au niveau de la base de données et au niveau du cluster.
## Restrictions
Le tableau suivant contient les limites du contrôle d'accès basé sur les rôles dans Amazon DocumentDB.
****
| Description | Limite |
| --- | --- |
| Nombre d'utilisateurs par cluster | 1 000 |
| Nombre de rôles associés à un utilisateur | 1 000 |
| Nombre de rôles définis par l'utilisateur | 100 |
| Nombre de ressources associées à un privilège | 100 |
## Accès à la base de données à l'aide du contrôle d'accès basé sur les rôles
Avec le contrôle d'accès basé sur les rôles, vous pouvez créer un utilisateur et lui accorder un ou plusieurs rôles afin de déterminer les opérations qu’il peut effectuer dans une base de données ou un cluster.
Voici une liste des rôles intégrés actuellement pris en charge dans Amazon DocumentDB.
**Note**
Dans Amazon DocumentDB 4.0 et 5.0, les `ListDatabase` commandes `ListCollection` and peuvent éventuellement utiliser les `authorizedDatabases` paramètres `authorizedCollections` and pour répertorier les collections et les bases de données auxquelles l'utilisateur est autorisé à accéder en exigeant les `listDatabase` rôles `listCollections` and, respectivement. De plus, les utilisateurs ont désormais la possibilité de supprimer leurs propres curseurs sans avoir besoin du `KillCursor` rôle.
------
#### [ Database user ]
****
| Nom du rôle | Description | Actions |
| --- | --- | --- |
| read | Accorde à un utilisateur un accès en lecture à la base de données spécifiée. | `[changeStreams](https://docs.aws.amazon.com//documentdb/latest/developerguide/change_streams.html)` `collStats` `dbStats` `find` `killCursors` `listIndexes` `listCollections` |
| readWrite | Accorde à l'utilisateur un accès en lecture et en écriture à la base de données spécifiée. | Toutes les actions à partir des autorisations `read`. `createCollection` `dropCollection` `createIndex` `dropIndex` `insert` `killCursors` `listIndexes` `listCollections` `remove` `update` |
------
#### [ Cluster user ]
****
| Nom du rôle | Description | Actions |
| --- | --- | --- |
| readAnyDatabase | Accorde à un utilisateur un accès en lecture à toutes les bases de données du cluster. | Toutes les actions à partir des autorisations `read`. `listChangeStreams` `listDatabases` |
| readWriteAnyDatabase | Accorde à un utilisateur un accès en lecture et en écriture à toutes les bases de données du cluster. | Toutes les actions à partir des autorisations `readWrite`. `listChangeStreams` `listDatabases` |
| userAdminAnyDatabase | Accorde à un utilisateur la possibilité d'attribuer et de modifier les rôles ou les privilèges dont un utilisateur dispose pour la base de données spécifiée. | `changeCustomData` `changePassword` `createUser` `dropRole` `dropUser` `grantRole` `listDatabases` `revokeRole` `viewRole` `viewUser` |
| dbAdminAnyDatabase | Accorde à un utilisateur la possibilité d'exécuter des rôles d'administration de base de données sur une base de données spécifiée. | Toutes les actions à partir des autorisations `dbAdmin`. `dropCollection` `listDatabases` `listChangeStreams` `modifyChangeStreams` |
------
#### [ Superuser ]
****
| Nom du rôle | Description | Actions |
| --- | --- | --- |
| root | Accorde à un utilisateur l'accès aux ressources et aux opérations de tous les rôles suivants combinés : readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabase, clusterAdmin, restore et backup. | Toutes les actions à partir de `readWriteAnyDatabase`, `dbAdminAnyDatabase`, `userAdminAnyDatabase`, `clusterAdmin`, `restore` et `backup`. |
------
#### [ Database administrator ]
****
| Nom du rôle | Description | Actions |
| --- | --- | --- |
| dbAdmin | Accorde à un utilisateur la possibilité d'effectuer des tâches d’administration sur la base de données spécifiée. | `bypassDocumentValidation` `collMod` `collStats` `createCollection` `createIndex` `dropCollection` `dropDatabase` `dropIndex` `dbStats` `find` `killCursors` `listIndexes` `listCollections` `modifyChangeStreams` |
| dbOwner | Accorde à un utilisateur la possibilité d'effectuer des tâches d’administration sur la base de données spécifiée en combinant les rôles dbAdmin et readWrite. | Toutes les actions à partir de `dbAdmin` et `readWrite`. |
------
#### [ Cluster administrator ]
****
| Nom du rôle | Description | Actions |
| --- | --- | --- |
| clusterAdmin | Accorde à un utilisateur l’accès de gestion de cluster le plus élargi en combinant les rôles hostManager, clusterManager et clusterMonitor. | Toutes les actions à partir de `clusterManager`, `clusterMonitor` et `hostManager`. `listChangeStreams` `dropDatabase` `modifyChangeStreams` |
| clusterManager | Accorde à un utilisateur la possibilité d’effectuer des actions de gestion et de surveillance sur le cluster spécifié. | `listChangeStreams` `listSessions` `modifyChangeStreams` `replSetGetConfig` |
| clusterMonitor | Accorde à un utilisateur la possibilité d'accéder en lecture seule aux outils de surveillance. | `collStats` `dbStats` `find` `getParameter` `hostInfo` `indexStats` `killCursors` `listChangeStreams` `listCollections` `listDatabases` `listIndexes` `listSessions` `replSetGetConfig` `serverStatus` `top` |
| hostManager | Accorde à un utilisateur la possibilité de surveiller et de gérer les serveurs. | `auditConfigure` `killCursors` `killAnyCursor` `killAnySession` `killop` |
------
#### [ Backup administrator ]
****
| Nom du rôle | Description | Actions |
| --- | --- | --- |
| backup | Accorde à un utilisateur l'accès nécessaire à la sauvegarde des données. | `getParameter` `insert` `find` `listChangeStreams` `listCollections` `listDatabases` `listIndexes` `update` |
| restore | Accorde à un utilisateur l'accès nécessaire à la restauration des données. | `bypassDocumentValidation` `changeCustomData` `changePassword` `collMod` `createCollection` `createIndex` `createUser` `dropCollection` `dropRole` `dropUser` `getParameter` `grantRole` `find` `insert` `listCollections` `modifyChangeStreams` `revokeRole` `remove` `viewRole` `viewUser` `update` |
------