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的关联，构建上下级角色关系；通过权限组，构建组内多个权限之间的互斥、依赖、包含等关系；定义按钮实体为枚举类型，减少冗余的关联关系数据等，这都是要系统设计人员根据实际业务情况去考量的。
