Atlas 数据库用户的访问权限由“认证库 + 角色”共同决定：认证库（如 admin）只负责身份验证，真正可访问的范围则由角色绑定的 db 字段（例如 {role:"read",db:"orders"}）严格限定。未被明确授权的数据库，默认无法访问。

MongoDB Atlas 数据库用户的权限控制是基于数据库粒度完成的，不能简单理解为“随意限制到某个指定数据库”即可实现。真正关键的是创建用户时设置的 db 参数，以及后续分配的角色作用域；这两项配置会直接决定用户最终能访问哪些数据库。如果这两个概念混淆，就很容易误以为 Atlas 没有限制成功。

创建用户时指定 db 参数，决定的是认证库而不是访问库

在 Atlas 中，所有数据库用户都必须绑定一个“认证数据库”（authentication database），通常使用 admin。这个数据库并不是用户实际访问业务数据的目标库，而是用于保存和校验用户凭证。

• 使用 db.createUser() 创建用户时，db 字段填写的是认证库名称，不是权限生效的数据库；例如 db: "admin" 表示用户信息保存在 admin 库中
• 连接字符串中的 ?authSource=xxx 必须与这个 db 保持一致，否则认证会直接失败，根本无法进入后续的权限校验流程
• 如果填写了 db: "myapp"，那么该用户连接时就必须使用 ?authSource=myapp；但 Atlas 默认不允许将用户存放在非 admin 库中（除非手动启用 legacy user storage，通常不建议这样做）

真正决定可访问数据库范围的是角色（role）

MongoDB Atlas 的数据库访问权限由角色定义，而角色的作用范围（resource）会明确绑定到具体数据库或集群级资源。像 read、readWrite 这类 Atlas 内置角色，本质上都属于“数据库级角色”，必须配合 db 字段一起使用，才能准确限制访问范围。

• { role: "read", db: "orders" } → 只能读取 orders 数据库，对 users 数据库没有访问权限，也通常不可见
• { role: "readWriteAnyDatabase", db: "admin" } → 这是风险较高的全库权限，允许读写所有数据库；这里的 db: "admin" 只是固定写法，并不表示权限只作用于 admin 库
• 如果使用自定义角色，也必须显式声明类似 resource: { db: "logs", collection: "" } 的资源范围，其中空字符串表示整个数据库；不能写成 resource: { db: "" }，否则会被识别为集群级资源，需要更高权限

连接参数 defaultAuthDb 或 authSource 不会改变数据库权限范围

很多人在配置 MongoDB Atlas 连接字符串时，会尝试通过 authSource 来“切换用户可访问的数据库”，这其实是常见误区。这个参数仅用于告诉驱动程序：去哪个数据库验证用户名和密码，与最终授权范围没有直接关系。

• 错误理解：mongodb+srv://u:p@cluster/?authSource=reports 就意味着只能访问 reports 数据库
• 实际情况：只要用户被授予了 { role: "read", db: "analytics" }，即使 authSource=reports，依然可以连接并访问 analytics 数据库，还能执行 db.getCollectionNames() 等允许范围内的操作
• 唯一需要注意的是 __system、local 等系统数据库，这类库默认不会向普通用户开放，不会因为修改角色写法就自动获得访问权

限制 MongoDB Atlas 用户只访问指定数据库的可靠方式

如果你的目标是让 A 用户完全无法查看或接触 B 数据库，那么仅理解角色名称还不够。因为在某些情况下，Atlas 允许用户列出数据库列表（例如某些角色隐含包含 listDatabases 权限）。想要真正实现数据库访问隔离，建议这样做：

• 不要为用户分配任何包含 listDatabases 的角色，例如尽量避免使用 dbAdminAnyDatabase、clusterAdmin 或其他高权限角色
• 确保用户只拥有明确绑定具体 db 的数据库级角色，例如仅授予 read + db: "finance"，不要叠加其他跨库或通配型权限
• 如果业务中存在多个敏感数据库，最佳实践是拆分到不同的 Atlas Project 中；因为项目之间的网络、用户和权限都是完全隔离的，这种方式比单纯依赖库级权限更彻底、更安全

还有一个很容易被忽视的点：虽然 Atlas 控制台里展示的“数据库用户列表”是项目级统一显示的，但每个用户的实际权限只会在被显式授予的数据库上生效。没有出现在角色配置中的数据库，并不是“勉强限制访问”，而是从权限设计上就不存在可访问入口。