B端后台“权限设计”的99种解法与反思( 三 ) 卫星|水泥|互联网|晶圆厂|钛媒

3）角色限制模型：RBAC2
RBAC2模型中添加了责任分离关系。RBAC2的约束规定了权限被赋予角色时，或角色被赋予用户时，以及当用户在某一时刻激活一个角色时所应遵循的强制性规则。
责任分离包括静态责任分离和动态责任分离。约束与用户——角色——权限关系一起决定了RBAC2模型中用户的访问许可，此约束有多种，主要包括：
静态限制（静态责任分离）同一用户只能分配到一组互斥角色集合中至多一个角色，支持责任分离的原则。例如：同一个人不能既是“运动员”又是“裁判员”，即当用户分配给受众运动员的角色后，权限页面无法给于其分配裁判员的权限。

文章插图
动态限制：运行时互斥：例如，允许一个用户具有两个角色的成员资格，但在运行中不可同时激活这两个角色。当一个人被授予了运动员和裁判员角色，在一次比赛中，他只能选择以一个身份进行，不能以两种身份同时进行。
基数约束：一个角色被分配的用户数量受限；一个用户可拥有的角色数目受限；同样一个角色对应的访问权限数目也应受限，以控制高级权限。
先决条件角色：可以分配角色给用户仅当该用户已经是另一角色的成员；对应的可以分配访问权限给角色，仅当该角色已经拥有另一种访问权限。要想获得较高的权限，要首先拥有低一级的权限。就像我们生活中，国家主席是从副主席中选举的一样。
4）整合统一模型：RBAC3
RBAC3包含了RBAC1和RBAC2，既提供了角色间的继承关系，又提供了责任分离关系。

文章插图
5. 基于属性的权限验证（ABAC：Attribute-Based Access Control）
ABAC被认为是权限控制的未来，由于其逻辑比较复杂，笔者并未吃透，所以只简单地介绍一下。

文章插图
ABAC可分为访问控制策略、环境条件、主体、客体、主体属性、客体属性。它通过将主体属性、客体属性和环境条件结合起来，按照它们与访问控制策略的匹配情况来确定访问（即对系统客体的操作）。
简单而言就是将主体和客体的属性用策略相关联，通过读取策略来确定主体可对客体进行哪些操作。
四、基于RBAC模型设计权限时应注意什么？1. 熟悉业务流程，盘点角色设计初期，应该重新梳理系统中不同模块的业务流程，通过业务流程图，来盘点各个节点的角色，在这一环节中，需要对角色进行穷举，保证系统在运行过程中达到闭环。一般情况下：

角色通过岗位去划分，例如在禅道中，通过不同的岗位来划分不同的角色。
角色通过任务流划分，根据业务流程中的不同节点功能，可将定义角色，例如，在某审批系统，可将角色划分为录入人员、审核人员。

2. 盘点权限，使用正确的描述方式将系统中的所有功能模块进行归纳整理，并根据自身系统所需要的颗粒度，来选择权限的颗粒度。
同时，在PRD中传达一个系统的权限设计规则时，不应该采用“当…时，就….“的语句去表达规则，而是要将角色和单元绘制成网格，每一个交叉节点为描述该角色与权限的数据关系和限制。
特别要注意的是，在设计数据权限时，其查看权限往往应设计在“增、删、改、查”之前。
3. 做好无页面权限的提示在正常情况下，当用户无对应权限时，该页面会直接隐藏，但也不排除用户可以获取到权限外的URL地址，因为当用户访问到没有权限的页面时，需提示该用户无对应权限。
4. 创建默认角色默认角色一般为系统中自带的角色，其往往包括超级管理员，管理员、业务员等等。
一般情况下，超级管理员为隐形角色，为领导高层掌握，拥有整个系统的所有权限，管理员继承超级管理员所分配的权限，若管理员唯一的情况下，自身不可编辑，不可删除，防止用户删除管理员角色，导致系统无法正常运行。其余角色为管理员创建，可编辑，可删除。
5. 对系统的长期规划需明确在搭建权限系统时，应该详细地了解系统的业务范围和长期规划，梳理角色，并尽可能多地获取用户信息。
例如，在数据权限配置过程种，我们通过数据打标来划分数据权限，但是随着数据的标识增加，权限判断条件增多，就会出现大量用户信息需要判断的问题。
6. 用户的长期维护需及时处理当系统长时间运转时，在权限上，可能会因为用户离职，权限系统未及时更新，而导致内部数据泄露的问题发生。针对这种情况，产品可采用权限系统与OA系统互通或者系统设置数据自动清洗的规则来解决。