MongoDB 中的基于角色的访问控制（RBAC）

随着数字时代越来越多人上网，对权限与角色的定义需求不断增长，以确保安全并管理对应用和系统的访问。基于角色的访问控制是一种用于根据用户预定义角色控制资源访问的授权模型。

在 MongoDB 的 RBAC 模型中，操作以角色的形式表示，并被分配给合适的用户。例如，您无需分配多个单独权限，只需分配一个角色（如 dbAdmin），它会自动包含一组已定义的权限（如对数据库中集合的读取）。这种模型便于以可扩展的方式管理用户访问。

在 MongoDB 中启用 RBAC

在核心 RBAC 模型下，默认拒绝访问，这意味着如果没有角色，用户无法访问资源。用户可以被分配多个角色，每个角色都可以拥有一组特定的特权或权限来访问特定能力。

RBAC 核心概念

以下是您需要了解的一些 RBAC 关键概念：

用户

在RBAC 模型中，用户是被授予一个或多个角色的实体，这些角色决定了用户对数据库资源和操作的访问。如果没有角色分配，用户将无法访问系统。要获得系统访问权限，用户必须通过身份验证并被分配至少一个角色。

角色

MongoDB 为自管部署和 MongoDB Atlas 提供了内置角色和特权。一些常见的内置角色包括 read、readWrite 和 dbAdmin/atlasAdmin。数据库管理员角色相比其他数据库用户角色拥有更高的特权，包括管理其他角色特权的权限。

如果这些内置角色无法提供所需的特权集合，MongoDB 提供了创建和修改用户自定义角色的方法。

角色是分配给用户的一组特权。

例如，“read” 角色可能只有只读特权，“admin” 角色可能拥有读写特权，而 “owner” 角色可以对特定项目（数据库、文档等）拥有读、写和删除特权。角色授予在资源上执行指定操作的权限。每项特权要么在角色中显式指定，要么从其他角色继承，或两者兼有。

用户自定义角色 / 自定义角色

MongoDB 提供了许多内置角色，管理员可用于控制对 MongoDB 系统的访问。不过，如果现有角色无法描述您所需的特定特权，您可以在数据库中定义并分配新角色——这就是自定义角色。除在 admin 数据库中创建的角色外，某个角色只能包含适用于其所属数据库的特权，且只能继承该数据库中的其他角色。

要创建新角色，请使用 db.createRole() 方法，在 privileges 数组中指定特权，在 roles 数组中指定继承的角色。

MongoDB 使用数据库名与角色名的组合来唯一标识一个角色，并将所有角色信息存储在 admin 数据库中的 admin.system.roles 集合内。

示例：以下示例创建了一个自定义角色（sales_attendant），该角色只能向 sales_db 数据库内的 sales 集合插入文档。

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

内置角色 

内置角色是预先创建并可分配给用户的角色，允许他们在数据库的集合上执行读取和写入等操作。内置角色示例包括 read、write、readWrite、dbAdmin 和 readAnyDatabase。

• read 和 readWrite（数据库级访问）：这些角色分别授予对指定数据库内所有非系统集合的只读或读/写操作权限。
• dbAdmin：该角色授予管理特定数据库所需的管理权限，例如创建、删除和修改索引与集合。适用于开发团队或数据库维护脚本。
• clusterAdmin（运维访问）：此高权限角色主要保留给运维（DevOps/Ops）人员。它授予管理整个 MongoDB 部署所需的权限，包括创建定期备份、配置副本集和分片。

特权（权限）

特权是一组允许在某项能力上执行的操作（例如 find、insert）。

例如，如果能力是“告知客户其当前余额”，那么用户特权（比如银行柜员）可以是只读。如果能力是提高银行账户的交易限额，特权可以是读和写。

继承特权

角色可以包含一个或多个现有角色（包括其所有特权）。例如，dbAdmin 角色可以包含 read、write 和 update 角色（这些可以是单独的角色），并同时继承其特权。

资源

资源可以是数据库、集合、集合集或整个集群。

实施最小权限原则

在现代数据库安全中，最小权限原则（PoLP）至关重要。该原则指出，每位用户应仅被授予完成其必要任务所需的最少权限。

以下是一个最佳实践示例：不要使用全局的 readWrite 用户，而应创建特定于应用的用户。例如，如果您的库存服务只与 app_data 数据库交互，则该应用用户只应被授予对该单一数据库的 readWrite 访问权限。通过这种分隔，可防止被攻陷的服务对其他数据库（如 billing 或 users）进行未经授权的访问。

代码示例：

创建一个最小权限用户。该示例创建了一个用户（branch_manager），其读/写访问严格限定在 bank_data 数据库。

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

最佳实践

• 预先创建并分配定义清晰的角色和策略。
• 遵循最小权限原则以确保严格的安全性。
• 在可行时使用内置角色；定期审计已分配角色以发现异常。