基于角色的访问控制(RBAC).

基于角色的访问控制将权限授予抽象角色(例如"计费管理员"或"只读审计员"),再通过把用户加入这些角色来授予访问权。这种间接层简化了管理、支持职责分离,并使审计更容易,因为权限是按角色而非按用户记录的。RBAC 是企业 IAM、云平台(AWS IAM、Azure RBAC、Kubernetes RBAC)和 ERP 系统中占主导地位的模型。

RBAC 由 NIST 的 David Ferraiolo 和 Rick Kuhn 在 1992 年论文《Role-Based Access Controls》中形式化,随后与 Sandhu 等人的框架统一,并标准化为 ANSI/INCITS 359-2004(2012 年修订为 INCITS 359-2012)。该标准定义了四个累积组件:核心 RBAC(用户–角色–权限)、分层 RBAC(角色继承上级角色),以及两种受约束 RBAC——静态与动态职责分离(SSD/DSD),用于阻止有害的权限组合,例如同一用户既创建又批准同一笔付款。

其主要弱点是角色爆炸:在大型组织中,把每一项细粒度业务需求都编码为独立角色会产生数千个近乎重复、难以管理的角色。这促使团队转向 ABAC/RBAC 混合设计——角色设定粗粒度基线,而属性(部门、时间、资源标签)细化每次判定,这正是 AWS IAM 条件键和 Kubernetes 的 RBAC 加准入 Webhook 模型背后的思路。

flowchart LR
  U["用户:Alice"] -->|指派到| R1["角色:计费管理员"]
  U -->|指派到| R2["角色:审计员"]
  R1 -->|继承| R3["角色:计费查看者"]
  R1 -->|授予| P1["权限:创建发票"]
  R3 -->|授予| P2["权限:查看发票"]
  R2 -->|授予| P3["权限:导出日志"]
  P1 --> RES[("计费系统")]
  P2 --> RES
  P3 --> RES
  SSD["SSD 约束:<br/>不可同时为审批者与创建者"] -. 阻止 .-> R1