三分钟了解RBAC模型

RBAC 是 Role-Based Access Control 的缩写，含义为基于角色的访问控制模型，此模型是 20 世纪 90 年代在美国第十五届全国计算机安全大会上提出的，后逐步被业界广泛使用，至 2004 年形成了 ANSI/INCITS 标准。时至今日，RBAC 访问控制模型已经渗入 IT 领域的多个方面，有传统技术方面的操作系统、数据库、中间件 Web 服务器，有新兴技术方面的 Kubernetes、Puppet、OpenStack 等。RBAC 访问控制模型能得到如此丰富而广泛的使用，得益于它基于用户与角色关系分配权限进行访问控制的核心理念。

1、RBAC 模型相关概念

一家企业或组织中存在着多个不同的角色，不同的角色做着不同的事情。RBAC 模型的核心理念是，为企业或组织创建多个角色，每一个角色分配特定的权限，再给企业中的成员分配特定的角色。通过管理成员角色的方式来管理权限，大大简化了操作的难度。

在 RBAC 模型中，定义了三条主要规则，其基本含义如下。

• 角色分配：是指只有为某个用户（用户是指真实自然人或应用程序）分配了该角色后，才具有该角色对应的权限。
• 角色授权：对应于安全设计原则中的最小特权原则，即用户被授予某个角色之后，仅能完成所授予权限内的活动。
• 权限授权：是指仅当某个角色被授予权限后，该角色被分配的用户才具有此角色所授予的权限。

这三条规则之间，构成了一个用户→角色→权限的关系链，这个链上的任何一个环节出了问题，均无法完成正确的授权访问，这是 RBAC 模型的核心授权思路。用户、角色、权限这三者的关系用 E-R 图表示。

在这三者关系中，一个用户对应多个角色，同样，一个角色也可以分配给多个用户；一个角色可以分配多个权限，同样一个权限可以分配给多个角色。它们之间，都是多对多的关系。

为了满足业务发展的需求，RBAC 模型在上述核心授权思路上做了相应的拓展，被称为 RBAC1、RBAC2、RBAC3。

• RBAC1 模型主要增加了角色继承的概念，很多业务场景中，角色存在上下级关系。比如银行业务中省行的行长和地市分行的行长之间的关系、大型集团公司业务中大区经理和片区经理之间的关系；
• RBAC2 模型主要增加了责任分离关系，面向授权访问添加了诸多约束，这也是为了满足业务的需要。比如在企业内部，出纳和会计是两个不同的角色，这两个角色如果由一个人来担任，则可能会出现资金流失而无人知晓的情况，所以在 RBAC 模型实现时，通过授权约束，限制同一个人被授予出纳和会计这两个角色，以规避风险；
• RBAC3 模型是 RBAC1 和 RBAC2 的组合，既添加了角色继承，又有访问控制约束，以满足更加复杂的业务需求。

在实际的互联网应用中，大多数场景下 RBAC3 能满足业务需求，但随着近些年数据安全监管和业务风控的需要，很多企业在 RBAC3 的基础上做了进一步的延伸。

2、RBAC3 模型技术实现

在调用 API 的可视化组件中，最常见的是前端 Web 页面。通常来说，一个前端 Web 页面包含以下元素。

• 模块：是指多个业务功能相近的功能组合，比如用户管理模块中有用户注册、用户信息修改、用户注销、用户锁定等。
• 菜单：通常对应某个具体的业务功能页面，有上级菜单和子菜单的区别。
• 按钮：是指页面上的操作按钮，比如新增按钮、修改按钮、删除按钮等。
• 链接：页面主体部分显示的除按钮外需要进行访问控制的超链接。
• 数据：页面显示的业务数据、资源、文件等。

Web 应用程序通过以上元素的不同组合，融合不同的业务流程，完成所支撑的业务功能，这里离不开授权与访问控制。一个模块，可能员工 A 具有操作权限，而员工 B 不具有操作权限；一个菜单，员工 A 具有部分上级菜单的操作权限，而员工 B 可能具有所有子菜单的权限；一个页面上的多个按钮，可能员工 A 具有新增权限，而员工 B 具有审计和查询权限；同一个页面上的链接，当员工 A 和员工 B 打开时，显示的数据是完全不一样的，比如员工 A 显示的是北京地区的数据，而员工 B 显示的却是上海地区的数据。这些场景的授权与访问控制过程在 RBAC3 模型都有着对应的解决方案。

RBAC3 模型的拓展主要是在原 RBAC3 模型的基础上增加了数据维度的授权与访问控制，结合这套模型的概念模型，下面来看看它的具体实现。

RBAC3 核心模型

其主要的区别在于权限以下的建模，将所授予的权限按照功能权限和数据权限进行拆分。

RBAC3 拓展模型

功能权限主要对应于功能菜单，通过分配功能菜单，再由菜单去关联其中的按钮和链接；而数据权限是通过数据维度去控制，先分配数据维度，再关联数据维度所分配的数据范围。在实际业务中，经常会遇到这样的场景，比如某个银行柜员角色只能看到它所在地区的、部分渠道的信息，假设地区是北京，渠道是电话客服和在线客服，那么此处的数据权限包含两个维度，一个是地区，一个是渠道；地区的数据范围是北京市所有网点，渠道的范围是电话客服和在线客服接入的业务。这就是数据维度和数据范围对于访问控制的作用。对于非用户参与的 API 接口的访问也是如此，通过功能级权限可以限制 API 的调用和访问，通过数据级权限控制可以防止过度的接口数据响应。

当然在实际的业务中，数据库建模往往更为复杂。比如通过角色对象中父子 ID 的关联，构建上下级角色关系；通过权限组，构建组内多个权限之间的互斥、依赖、包含等关系；定义按钮实体为枚举类型，减少冗余的关联关系数据等，这都是要系统设计人员根据实际业务情况去考量的。