MongoDB的权限管理体系基于角色进行权限分配，不同的内置角色对应不同的操作权限集合，开发者可以根据实际使用场景为不同用户分配合适的角色，既满足业务操作需求，又能避免权限滥用带来的数据安全风险。在众多内置角色中，read、write、dbAdmin是数据库级别最常用的三个角色，很多刚接触MongoDB权限管理的开发者容易混淆三者的权限边界，导致出现权限分配不合理的情况。
read角色的核心权限与适用场景
read角色是MongoDB中权限最低的数据库级内置角色，它的核心定位是给只需要查询数据的用户分配，完全不具备任何数据修改能力。从权限构成来看，read角色拥有对目标数据库中所有非系统集合的find操作权限，同时也支持对集合执行aggregate聚合查询、distinct去重查询等只读类操作，还可以查看集合的索引信息和统计信息，但无法执行任何会修改数据或集合结构的操作。
在实际业务场景中，read角色非常适合分配给只需要做数据查询的下游系统或者只读账号。比如数据分析团队需要拉取业务库的数据做报表统计，或者前端页面的游客模式需要查询部分公开数据，这类场景只需要查询能力，不需要修改数据，分配read角色就能满足需求，同时避免误操作修改数据。如果给这类用户分配更高权限的角色，一旦出现账号泄露或者操作失误，就可能导致数据被篡改，带来业务损失。
我们可以通过MongoDB的shell命令验证read角色的权限，下面是为test数据库创建只读用户并验证权限的示例：
// 切换到admin数据库，需要管理员权限才能创建用户
use admin
// 创建拥有test数据库read角色的用户
db.createUser({
user: "read_user",
pwd: "read_pwd_123",
roles: [{ role: "read", db: "test" }]
})
// 切换到test数据库，使用只读用户登录后执行操作
use test
// 可以正常执行查询操作
db.user.find({ name: "张三" })
// 执行插入操作会报错，提示没有权限
db.user.insertOne({ name: "李四", age: 20 })
// 报错信息类似：not authorized on test to execute command { insert: "user" ... }
write角色的权限范围与使用限制
write角色在read角色的全部权限基础上，增加了数据增删改的相关权限，是业务系统中最常用的角色之一。write角色支持对目标数据库的非系统集合执行insert、update、delete、findAndModify等所有数据修改类操作，同时也支持执行createIndex创建索引吗？不对，这里需要注意，write角色并不包含索引管理权限，也不支持创建、删除集合，修改集合结构等操作，它的权限边界严格限定在数据内容的修改上，不涉及数据库结构的调整。
write角色非常适合分配给业务系统的核心服务账号，比如后端API服务需要读写业务数据，就可以给对应的数据库账号分配write角色。这类账号需要正常处理业务的增删改查逻辑，但不需要调整数据库的结构，比如不需要创建新的集合，也不需要修改已有集合的索引，分配write角色既满足业务操作需求，又避免了账号拥有过高权限带来的风险。如果给业务服务账号分配dbAdmin角色，一旦服务被攻击，攻击者就可以直接删除整个集合或者篡改索引，导致业务完全不可用。
下面是创建write角色用户并验证权限的示例代码：
use admin
// 创建拥有test数据库write角色的用户
db.createUser({
user: "write_user",
pwd: "write_pwd_123",
roles: [{ role: "write", db: "test" }]
})
use test
// 可以正常执行插入操作
db.user.insertOne({ name: "王五", age: 22 })
// 可以正常执行更新操作
db.user.updateOne({ name: "王五" }, { $set: { age: 23 } })
// 可以正常执行删除操作
db.user.deleteOne({ name: "王五" })
// 尝试创建索引会报错，提示没有权限
db.user.createIndex({ name: 1 })
// 报错信息类似：not authorized on test to execute command { createIndexes: "user" ... }
dbAdmin角色的管理权限与注意事项
dbAdmin角色是数据库级别的管理类角色，它的核心权限围绕数据库的管理操作展开，和read、write角色的权限几乎没有重叠。dbAdmin角色支持对目标数据库执行集合的创建、删除、重命名操作，支持管理集合的索引，包括创建、删除、重建索引，还可以查看数据库的统计信息、执行数据压缩、管理集合的分片配置等数据库管理类操作，但dbAdmin角色没有数据的读写权限，无法执行find、insert等数据操作命令。
dbAdmin角色适合分配给数据库管理员或者需要维护数据库结构的运维人员，比如需要定期创建新的业务集合、调整集合索引优化查询性能、清理无用集合等场景，就可以给对应的账号分配dbAdmin角色。需要注意的是，dbAdmin角色虽然不能读写数据，但拥有删除集合的权限，所以如果给普通业务人员分配这个角色，一旦出现误操作，就可能导致整个集合的数据被删除，因此这个角色的分配需要严格控制，不能随便授予业务系统的服务账号。
下面是创建dbAdmin角色用户并验证权限的示例代码：
use admin
// 创建拥有test数据库dbAdmin角色的用户
db.createUser({
user: "dbadmin_user",
pwd: "dbadmin_pwd_123",
roles: [{ role: "dbAdmin", db: "test" }]
})
use test
// 可以正常创建集合
db.createCollection("order")
// 可以正常创建索引
db.order.createIndex({ order_id: 1 })
// 可以正常删除集合
db.order.drop()
// 尝试查询数据会报错，提示没有权限
db.user.find({ name: "张三" })
// 报错信息类似：not authorized on test to execute command { find: "user" ... }
三个角色的核心差异对比与权限选择建议
为了更清晰地理解read、write、dbAdmin三个角色的差异，我们可以从权限类型、适用场景、风险等级三个维度做对比：
| 角色名称 | 核心权限 | 适用场景 | 风险等级 |
|---|---|---|---|
| read | 仅数据查询权限，无修改能力 | 数据分析、只读查询、游客数据访问 | 低 |
| write | 数据增删改查权限，无结构管理权限 | 业务系统服务账号、普通业务操作人员 | 中 |
| dbAdmin | 数据库结构管理权限，无数据读写权限 | 数据库管理员、运维人员 | 高 |
在实际的权限分配过程中，遵循最小权限原则是最核心的要求，也就是给用户分配刚好满足其操作需求的最低权限角色，不要为了方便直接分配更高权限的角色。比如业务服务只需要读写数据，就分配write角色，不要分配dbAdmin或者更高权限的userAdmin、root角色；如果只需要查询数据，就分配read角色，不要分配write角色。这样即使出现账号泄露或者操作失误，也能把损失控制在最小范围内。
另外需要注意，这三个角色都是数据库级别的角色，作用范围仅限单个数据库，如果需要跨数据库分配权限，需要给用户在多个数据库分别分配对应的角色，或者使用更高层级的内置角色。同时MongoDB的内置角色还可以组合使用，比如如果一个用户既需要读写数据，又需要管理索引，可以同时给用户分配write和dbAdmin两个角色，这样就能同时满足两类操作需求，而不需要分配更高权限的角色。
MongoDBread_rolewrite_role修改时间：2026-08-17 14:13:10