RBAC
本文约需 2 分钟阅读
RBAC (Role-Based Access Control，基于角色的访问控制) 是一种通过「角色」来管理权限，而非直接向用户授予权限的访问控制模型。它由 David Ferraiolo 和 Richard Kuhn 于 1992 年在 NIST 提出，并于 2004 年标准化为 ANSI/INCITS 359。它将权限归集到「销售经理」「开发者」「审计员」等角色中，用户只需被分配角色即可，从而极大地简化了大型组织中的权限管理。它是 IAM 的核心概念，也是访问控制最广泛采用的实现方式。
NIST RBAC 模型的 3 个层级
NIST 将 RBAC 定义为可逐级扩展的 3 个层级。可根据组织的规模和需求，选择实现到哪个层级。
基础模型。由用户、角色、权限、会话 4 个要素构成。将角色分配给用户，将权限关联到角色。对大多数系统而言，这一层级已经足够。
在角色之间引入父子关系 (继承)。「部长」角色会自动继承「科长」角色的权限。可将组织层级原样映射为角色层级，从而消除权限的重复定义。
增加职责分离 (SoD: Separation of Duties) 约束。通过定义诸如不能将「会计」与「审批者」分配给同一用户的互斥约束，从结构上防止舞弊和误操作。
RBAC、ABAC、PBAC 的比较
访问控制模型不止 RBAC 一种。重要的是将其与基于属性 (ABAC) 和基于策略 (PBAC) 的模型进行比较，选择符合需求的模型。
| 观点 | RBAC | ABAC | PBAC |
|---|---|---|---|
| 判断标准 | 角色 | 用户、资源、环境的属性 | 策略 (规则引擎) |
| 粒度 | 粗 (以角色为单位) | 细 (属性的组合) | 最灵活 (任意条件) |
| 引入的难易度 | 容易 | 中等 | 复杂 |
| 管理成本 | 与角色数量成正比 | 维护属性定义 | 维护策略的一致性 |
| 适用场景 | 组织结构明确的企业 | 需要动态条件判断的情况 | 复杂的业务规则 |
| 代表性实现 | AWS IAM 角色、Kubernetes RBAC | AWS IAM 策略条件、Azure ABAC | OPA (Open Policy Agent) |
在实际系统中，结合 RBAC 与 ABAC 的混合方式正在增多。 AWS IAM 就是典型的混合实现：在基于角色的基本结构之上，可通过 Condition 要素添加基于属性的条件。
与最小权限原则的关系
最小权限原则是「只授予完成业务所需的最低限度权限」这一安全基本原则。可以说，RBAC 是在组织层面实现这一原则的机制。若角色设计得当，就能从结构上消除向个别用户授予过多权限的风险。但若角色设计过粗，便会产生诸如「开发者角色包含了生产环境的删除权限」这类过度权限。角色的粒度设计决定了最小权限的实际效果。
角色爆炸 (Role Explosion) 问题
RBAC 最大的难题是「角色爆炸」：随着组织日趋复杂，角色数量呈爆炸式增长。若按部门 × 职位 × 项目 × 环境的组合来创建角色，就会产生数百乃至数千个角色，导致管理崩溃。
要防止角色爆炸，行之有效的混合方式是：将角色粒度限定为「职务功能」，而部门和项目的区分则交由 ABAC 的属性条件处理。定期的角色盘点 (审计角色的使用情况，整合或废除不需要的角色) 也必不可少。
主流平台上的 RBAC 实现
将策略 (JSON) 附加到 IAM 角色上，让用户或服务承担该角色 (AssumeRole)。跨账户访问也使用角色。
用 Role / ClusterRole 定义对资源的操作权限，再用 RoleBinding / ClusterRoleBinding 关联到用户或服务账户。可实现命名空间级别的隔离。
将目录角色 (Global Admin、User Admin 等) 与应用程序专属的自定义角色相结合。通过 PIM (Privileged Identity Management) 可实现特权角色的即时 (Just-In-Time) 授予。
RBAC 也是零信任架构的基础，是合规审计中必查的项目。也请一并参阅企业的密码策略、初创企业的安全检查清单和零信任安全。访问控制相关书籍 (Amazon)推荐用来深入学习设计模式。
这篇文章对您有帮助吗？