|
MongoDB accorde l’accès aux données et commandes via une autorisation basée sur les rôles et fournit des rôles intégrés qui fournissent les différents niveaux d’accès couramment nécessaires dans un système de base de données. Vous pouvez également créer des rôles définis par l’utilisateur. Un rôle accorde des privilèges pour effectuer des ensembles d’actions sur des ressources définies. Un rôle donné s’applique à la base de données sur laquelle il est défini et peut accorder un accès jusqu’à un niveau de granularité de collection. Chacun des rôles intégrés de MongoDB définit l’accès au niveau de la base de données pour toutes les collections non système dans la base de données du rôle et au niveau des collections pour toutes les collections système. MongoDB fournit les rôles intégrés d’utilisateur de base de données et d’administration de base de données sur chaque base de données. MongoDB fournit tous les autres rôles intégrés uniquement dans la base de données admin. Cette section décrit les privilèges pour chaque rôle intégré. Vous pouvez également consulter les privilèges d’un rôle intégré à tout moment en envoyant la commande rolesInfo avec les champs showPrivileges et showBuiltinRolesfields tous deux réglés sur true. Rôles des utilisateurs de la base de donnéesChaque base de données comprend les rôles clients suivants : lirePermet de lire les données sur toutes les collections non système ainsi que sur les collections système suivantes : system.indexes, system.js et system.namespaces. Le rôle offre un accès en lecture en accordant les actions suivantes : - collStats
- dbHash
- dbStats
- Trouver
- killCursors
- listIndexes
- Liste Collections
readWriteOffre tous les privilèges du rôle de lecture ainsi que la possibilité de modifier les données sur toutes les collections non système et la collection system.js. Le rôle propose les actions suivantes sur ces collections : - collStats
- convertiToCap
- createCollection
- dbHash
- dbStats
- dropCollection
- createIndex
- dropIndex
- à bout vide
- Trouver
- Insertion
- killCursors
- listIndexes
- Liste Collections
- Retirer
- renameCollectionSameDB
- mettre à jour
Fonctions d’administration de bases de donnéesChaque base de données comprend les rôles suivants d’administration de base de données : dbAdminFournit les actions suivantes sur les collections system.indexes, system.namespaces et system.profile de la base de données : - collStats
- dbHash
- dbStats
- Trouver
- killCursors
- listIndexes
- Liste Collections
- dropCollection et createCollection uniquement sur system.profile
Modifié dans la version 2.6.4 : dbAdmin a ajouté la createCollection pour le system.profilecollection. Les versions précédentes ne présentaient que la dropCollection sur la collection system.profile.
Fournit les actions suivantes sur toutes les collections non systématiques. Ce rôle n’inclut pas l’accès complet en lecture sur les collections non système : - contournementDocumentValidation
- collMod
- collStats
- compact
- convertiToCap
- createCollection
- createIndex
- dbStats
- dropCollection
- dropDatabase
- dropIndex
- enableProfiler
- reIndex
- renameCollectionSameDB
- repairDatabase
- storageDétails
- valider
dbOwnerLe propriétaire de la base de données peut effectuer toute action administrative sur la base de données. Ce rôle combine les privilèges accordés par les rôles readWrite, dbAdmin et userAdmin. userAdminPermet de créer et de modifier des rôles et des utilisateurs sur la base de données actuelle. Ce rôle offre également indirectement un accès superutilisateur soit à la base de données, soit, si c’est à la base de données d’administration, au cluster. Le rôle AdminuserAdmin permet aux utilisateurs d’accorder n’importe quel privilège à n’importe quel utilisateur, y compris eux-mêmes. Le rôle userAdmin fournit explicitement les actions suivantes : - changeCustomData
- changePassword
- createRole
- createUser
- dropRole
- dropUser
- SubventionRôle
- revokeRôle
- viewRôle
- viewUser
Rôles d’administration de clusterLa base de données administrative comprend les rôles suivants pour administrer l’ensemble du système plutôt qu’une seule base de données. Ces rôles incluent, sans s’y limiter, des fonctions administratives de répliques, ensembles et clusters fragmentés. clusterAdminOffre le meilleur accès à la gestion de clusters. Ce rôle combine les privilèges accordés par les rôles theclusterManager, clusterMonitor et hostManager. De plus, le rôle fournit l’action de dépôt de la base de données. ClusterManagerAssure la gestion et les actions de surveillance sur le cluster. Un utilisateur ayant ce rôle peut accéder aux bases de données locales de config et de configuration, qui sont utilisées respectivement pour le sharding et la réplication. Fournit les actions suivantes sur l’ensemble du cluster : - addShard
- applicationMessage
- nettoyage Orphelin
- flushRouterConfig
- listShards
- removeShard
- replSetConfigure
- replSetGetConfig
- replSetGetStatus
- replSetStateChange
- resynchronisation
Fournit les actions suivantes sur toutes les bases de données du cluster : - enableSharding
- moveChunk
- splitChunk
- splitVector
Sur la base de données de configuration, les actions suivantes sont fournies sur la collection de paramètres : - Insertion
- Retirer
- mettre à jour
Sur la base de données de configuration, les actions suivantes sont proposées sur toutes les collections de configuration ainsi que sur les collections thesystem.indexes, system.js et system.namespaces : - collStats
- dbHash
- dbStats
- Trouver
- killCursors
Sur la base de données locale, fournit les actions suivantes sur la collection replset : - collStats
- dbHash
- dbStats
- Trouver
- killCursors
clusterMonitorOffre un accès en lecture seule aux outils de surveillance, tels que MongoDB Cloud Manager et l’agent de surveillance Ops Manager. Fournit les actions suivantes sur l’ensemble du cluster : - connPoolStats
- cursorInfo
- getCmdLineOpts
- getLog
- getParameter
- getShardMap
- hostInfo
- inprog
- listDatabases
- listShards
- netstat
- replSetGetStatus
- replSetGetConfig
- serverStatus
- ShardingState
- Retour au début
Fournit les actions suivantes sur toutes les bases de données du cluster : - collStats
- dbStats
- getShardVersion
- indexStats
Fournit l’action de recherche sur toutes les collections system.profile du cluster. Fournit les actions suivantes sur les collections de configuration et les collections de configuration.indexes, system.js et system.namespaces de la base de configuration : - collStats
- dbHash
- dbStats
- Trouver
- killCursors
hostManagerPermet de surveiller et de gérer les serveurs. Fournit les actions suivantes sur l’ensemble du cluster : - applicationMessage
- closeAllDatabases
- connPoolSync
- cpuProfiler
- diagLogging
- flushRouterConfig
- fsync
- invalidateUserCache
- killop
- logRotate
- resynchronisation
- setParameter
- Fermeture
- Toucher
- Déverrouiller
Fournit les actions suivantes sur toutes les bases de données du cluster : - killCursors
- repairDatabase
Rôles de secours et de restaurationLa base de données administrative comprend les rôles suivants pour la sauvegarde et la restauration des données : RemplaçantOffre des privilèges minimaux nécessaires à la sauvegarde des données. Ce rôle offre suffisamment de privilèges pour utiliser l’agent de sauvegarde MongoDB Cloud Manager, l’agent de sauvegarde Ops Manager, ou pour utiliser mongodump afin de sauvegarder une instance mongod entière. Fournit les actions d’insertion et de mise à jour sur la collection mms.backup dans la base de données d’administration et sur la collection de paramètres dans la base de données de configuration. Fournit l’action listDatabases sur l’ensemble du cluster. Fournit l’action listCollections sur toutes les bases de données. Fournit l’action listIndexes pour toutes les collections. Fournit l’action bypassDocumentValidation pour les collections ayant une validation de documents. Fournit l’action de recherche sur les points suivants : - toutes les collections non système du cluster
- toutes les collections système suivantes du cluster : system.indexes, system.namespaces, et system.js
- les collections admin.system.users et admin.system.roles
- La collection config.settings
- collections héritées de system.users issues de versions antérieures à la 2.6
Changement dans la version 3.2.1 : Le rôle de sauvegarde offre des privilèges supplémentaires pour sauvegarder les collections system.profile existantes lors de l’exécution avec le profilage de base de données. Auparavant, les utilisateurs devaient avoir un accès supplémentaire à la lecture sur cette collection.
RestaurationFournit les privilèges nécessaires pour restaurer les données issues de sauvegardes qui n’incluent pas les données system.profilecollection. Ce rôle est suffisant lors de la restauration de données avec mongorestore sans l’option --oplogReplay. Si les données de sauvegarde incluent des données de collection system.profile et que la base de données cible ne contient pas la collection system.profile, mongorestore tente de créer la collection même si Le programme ne restaure en réalité pas les documents system.profile. Ainsi, l’utilisateur a besoin de privilèges supplémentaires pour effectuer les actions createCollection et convertToCapped sur la collection system.profile pour une base de données. Les rôles intégrés dbAdmin et dbAdminAnyDatabase offrent des privilèges supplémentaires. Si on exécute mongorestore avec --oplogReplay, le rôle de restauration est insuffisant pour rejouer l’oplog. Pour rejouer l’oplog, créez un rôle défini par l’utilisateur qui ait anyAction sur anyResource et accordez-les uniquement aux utilisateurs qui doivent exécuter mongorestore avec --oplogReplay.
Fournit les actions suivantes sur toutes les collections non système et system.js collections du cluster ; sur les collections admin.system.users et admin.system.roles dans la base de données admin ; et sur les collections héritées de system.users issues de versions antérieures à la 2.6 : - collMod
- createCollection
- createIndex
- dropCollection
- Insertion
Fournit l’action listCollections sur toutes les bases de données. Fournit les actions supplémentaires suivantes sur admin.system.users et system.userscollections héritées : - Trouver
- Retirer
- mettre à jour
Fournit l’action de recherche sur toutes les collections system.namespaces du cluster. Bien que la restauration inclue la possibilité de modifier les documents dans admin.system.userscollections en utilisant des opérations de modification normales, mais de ne modifier ces données qu’avec la gestion utilisateur méthodes.
Rôles tout-bases de donnéesLa base de données admin fournit les rôles suivants qui s’appliquent à toutes les bases de données d’une instance mongod et sont à peu près équivalents à leurs équivalents à base de données unique : readAnyDatabaseFournit les mêmes permissions en lecture seule que la lecture, sauf qu’elle s’applique à toutes les bases de données du cluster. Le rôle fournit également l’action listDatabases sur l’ensemble du cluster. readWriteAnyDatabaseFournit les mêmes permissions de lecture et d’écriture que readWrite, sauf qu’elle s’applique à toutes les bases de données du cluster. Le rôle fournit également l’action listDatabases sur l’ensemble du cluster. userAdminAnyDatabaseFournit le même accès aux opérations d’administration utilisateur que userAdmin, sauf qu’il s’applique à toutes les bases de données du cluster. Le rôle propose également les actions suivantes sur l’ensemble du cluster : - authSchemaUpgrade
- invalidateUserCache
- listDatabases
Le rôle fournit également les actions suivantes sur les collections admin.system.users et admin.system.roles de la base de données admin, ainsi que sur les collections héritées system.users issues de versions de MongoDB avant la version 2.6 : - collStats
- dbHash
- dbStats
- Trouver
- killCursors
- planCacheRead
Modifié dans la version 2.6.4 : userAdminAnyDatabase a ajouté les permissions suivantes sur les collections admin.system.users et admin.system.roles :
Le rôle userAdminAnyDatabase ne limite pas les permissions qu’un utilisateur peut accorder. En conséquence, les utilisateurs de UserAdminAnyDatabase peuvent s’accorder des privilèges dépassant leurs privilèges actuels et même s’accorder tous les privilèges, même si le rôle ne le fait pas autoriser explicitement des privilèges au-delà de l’administration utilisateur. Ce rôle est en fait un superutilisateur système MongoDB. dbAdminAnyDatabaseFournit le même accès aux opérations d’administration de base de données que dbAdmin, sauf qu’il s’applique à toutes les bases de données du cluster. Le rôle fournit également l’action listDatabases sur l’ensemble du cluster.
Rôles de superutilisateurPlusieurs rôles offrent un accès superutilisateur à l’échelle du système indirect ou direct. Les rôles suivants offrent la capacité d’attribuer à n’importe quel utilisateur n’importe quel privilège sur n’importe quelle base de données, ce qui signifie que les utilisateurs de l’un de ces rôles peuvent s’attribuer n’importe quel privilège sur n’importe quelle base de données : - Rôle dbOwner, lorsqu’il est regroupé dans la base de données admin
- Rôle userAdmin, lorsqu’il est regroupé dans la base de données admin
- Rôle userAdminAnyDatabase
Le rôle suivant offre des privilèges complets sur toutes les ressources : racineDonne accès aux opérations et à toutes les ressources des rôles readWriteAnyDatabase, dbAdminAnyDatabase, userAdminAnyDatabase, clusterAdmin, restore combinés. Modifié dans la version 3.0.7 : La racine a une action de validation sur le système. Des recouvrements. Auparavant, root n’incluait aucun accès aux collections qui commencent avec le système. préfixe autre que system.indexes et system.namespaces. Le rôle racine inclut les privilèges du rôle de restauration.
Rôle interne__systemMongoDB attribue ce rôle aux objets utilisateur qui représentent des membres du cluster, tels que les membres de répliques et les instances mongos. Ce rôle donne à son détenteur le droit d’agir contre n’importe quel objet dans la base de données. N’attribuez pas ce rôle aux objets utilisateur représentant des applications ou des administrateurs humains, sauf dans des circonstances exceptionnelles. Si vous avez besoin d’accéder à toutes les actions sur toutes les ressources, par exemple pour exécuter des commandes ApplyOps, n’attribuez pas ce rôle. À la place, créez un rôle défini par l’utilisateur qui accorde anyAction sur anyResource et assurez-vous que seuls les utilisateurs ayant besoin d’accéder à ces opérations ont cet accès. Original : https://docs.mongodb.com/manual/reference/built-in-roles/#built-in-roles
| 
Publié sur 09/10/2016 17:04:10
|
|
|
Propriétaire|
Publié sur 09/10/2016 17:33:26
|
