编辑导语:合理的B端后台权限设计体系，有助于用户处理更多事务，提高用户操作效率，降低风险的可能性。那么，你了解权限设计中的每一个模型吗？本文作者根据自己的经验，阐述了B端后台权限设计的多种解决方案。让我们来看看。

“权限设计”是中后台的底层设计，是系统设计中最重要的环节。

优秀的权限设计可以有效提高系统的安全性，降低用户误操作和数据泄露的风险；糟糕的权限设计往往导致系统流程不通，系统的稳定性和安全性受到威胁。

但是，产品经理在设计权限时，往往很迷茫，不知道从何下手。

问题在于:一方面，开源的授权产品很少，产品经理没有办法去体验和借鉴。另一方面，关于权威的文章良莠不齐，缺乏系统的文章帮助理解权威的构成，产品只能摸着石头过河，犯一些认知之外的错误。

对此，笔者基于以往的产品实践经验，整合互联网权威方面的优秀文章，输出自己对权威的粗浅认识，希望能起到抛砖引玉的作用。

权限，百度百科将其定义为:“为保证职责的有效履行，任职者必须具备并能对某一事项做出决策的范围和程度。”

但作者将其理解为:“不同使用场景下的不同对象，需要产品相应权责的统一，其核心是权责的清晰和分离。目的是建立分配资源的规则，让用户通过这套规则获得应得的资源。”

通常我们把权限分为两个维度，即功能权限和数据权限。功能权限是指用户可以做什么样的操作，或者可以访问哪些资源，可以使用哪些功能。数据权限是指哪些数据属于你，或者属于你可以操作的范围。

从粒度维度来看，功能权限的粒度一般由粗到细分为“模块级”:& gt"页面级别" >:& gt“界面级”，这就引出了俗称的页面权限、模块权限和界面权限。

数据权限的粒度一般分为“对象级”由粗到细>:& gt“字段级”，导致对象级数据权限(具体到实际用户)和字段级数据权限(具体到表单字段)。

从权限操作的维度来看，权限操作可以分为授权和认证。

功能授权通常是单维度，通常在功能列表或功能树中查看，确定用户对应的可操作资源。

数据授权不同于函数授权。数据是多维的、抽象的。所以在做数据授权之前，我们往往需要考虑拆分数据维度，数据是抽象的，无法将单个用户的一段数据可视化，没有任何意义。而是需要内置抽象规则，通过抽象规则找到数据背后的联系。

1.自主访问控制(DAC)

自主访问控制是指有权访问访问对象(文件、数据表等)的用户。)自己创造的，有客体权利。

可以将对这些对象的访问权限授予其他用户，并且可以从授予权限的用户那里收回他们的访问权限。这种权限模型常用于文档系统的权限设计，如微软的NTFS文件系统。

DAC不仅可以分配权限，还可以累积和继承权限。但它最大的缺点是权限太分散，不方便管理。例如，不可能简单地开发一组对一组用户有统一权限的文件。

2.强制访问控制(MAC:强制访问控制)

MAC模型常用于信息敏感型行业，它将系统中的信息进行分类分级管理，以保证每个用户只能访问标记为自己可以访问的信息。

一般来说，在强制访问的控制下，用户(或其他主体)和文件(或其他客体)都标有固定的安全属性(如安全级别、访问权限等。).每次访问发生时，系统都会检查安全属性，以确定用户是否有权访问该文件。例如，多级安全(MLS)是一种强制性的访问控制策略。

3.访问控制列表(ACL:访问控制列表)

ACL(访问控制列表)主要包含三个要素:用户、资源和操作。

ACL为每个资源分配一个列表。当用户需要访问资源时，会先询问列表中是否有当前用户的访问权限，从而确定当前用户是否可以进行相应的操作。

它的优点是ACL极其简单，不需要任何基础设备就可以完成访问控制。但是，由于表单数量过多，如果系统中有大量的资源，管理访问控制列表就变成了繁琐的工作。

4.基于角色的访问控制系统(RBAC:基于角色的访问控制)

RBAC模型是实际商业中应用最广泛的模型。RBAC模型主要由三个基本模块组成，即用户、角色和权限。通过编辑用户与角色、角色与权限的映射关系，系统解耦了用户与权限的关系，大大减少了数据冗余，从而降低了复杂性，提高了系统的灵活性。

RBAC模型只是一个大类，具体可以分为RBAC0、RBAC1、RBAC2、RBAC3。

1)基本模型:RBAC0

RBAC0是RBAC的核心，它定义了可以构成RBAC控制系统的最小元素的集合(角色)。在该模型中，它表示角色、用户、访问权限和会话之间的关系。其过程是通过将角色与用户相关联，定义权限集(角色)来间接授予用户权限，从而达到用户与权限解耦的目的。

在RABC中，用户与角色的关系可以分为“n: 1(多对一)用户角色关系”和“N:N(多对多)用户角色关系”。

以n: 1的用户角色关系为例。李三和李四(用户)都来自A部门(用户组)，职位是产品运营(角色)。都需要文章审核和文章发布的功能(权限)。因此，只需将文章审核和文章发布(权限)分配给产品运营(角色)，将产品运营(角色)分配给李三和李四即可。

在n: n(多对多)用户角色关系中，如果一个用户被分配了多个角色，那么该用户的权限就是所分配角色的联合。

再比如，吴立是B部门的产品经理，他的权限设置为文章模板。但因为某个调查，他需要A部门的文章审核发布权限，当他被分配到A部门的产品运营角色时，此时他的权限变成了文章审核、发布权限和文章模板设置。

但在实际业务中，对用户的了解并没有上面描述的那么肤浅。其实用户有各种各样的定义。就作者自己对用户的理解，“用户本质上是需求的集合”。

从这个角度来看，当使用场景和需求相对一致时，这部分用户就可以看作是一个需求聚合一致的群体，进而可以形成一个用户群(即用户的聚合)。

拿前面的例子来说，如果部门A是产品运营部门，那么我们不需要给部门A内部的人分配角色，而是给部门A分配角色。

同时，现实中也有以下几种使用场景，需要给用户分配大部分权限。如果逐个分配权限，会特别繁琐，可以选择把相对固定的权限打包成组给用户。

2)角色层次模型:RBAC1

RBAC1在RBAC0的基础上，引入了角色之间的继承关系，即有上下级角色的区别。角色之间的继承关系可以分为一般继承关系和有限继承关系。

一般继承关系只要求角色继承关系是绝对偏序关系(有向无环图)，可以进行多重继承。但是，受限继承关系进一步要求角色继承关系是树结构(二叉树)之间的单一继承。

一般继承的RBAC和限制继承的RBAC的区别在于，前者是图，可以继承更多；后者可以有多个父节点，但只能有一个子节点，这是一个反向树结构，只能单个继承。

RBAC1模型常用于角色层次清晰的产品，一般与组织结构相关联。例如，李三是产品操作员，他的上级李四是产品经理。李四将自己的部分权限委托给李三，也可以认为是李三继承了李四的部分权限，即子集继承了父的部分权限。

3)角色限制模型:RBAC2

RBAC2模型中增加了职责分离关系。RBAC2的约束规定了在给角色赋予权限时、给用户赋予角色时、用户在某个时间激活角色时应遵循的强制规则。

责任分离包括静态责任分离和动态责任分离。约束与用户-角色-权限关系一起决定了RBAC2模型中用户的访问权限。有许多种约束，包括:

静态限制(静态职责分离)同一用户最多只能被分配给一组互斥角色中的一个角色，这支持职责分离原则。比如同一个人不能同时是“运动员”和“裁判”，也就是用户被分配了观众运动员的角色后，权限页面不能将裁判的权限分配给他。

动态限制:运行时互斥:例如，允许一个用户拥有两个角色的成员身份，但是在运行时不能同时激活这两个角色。当一个人被赋予运动员和裁判员的角色时，他只能选择以一种身份参赛，而不能同时以两种身份参赛。

基数约束:分配给一个角色的用户数量是有限的；用户可以拥有的角色数量是有限的；对应于相同角色的访问权限的数量也应该被限制为控制高级权限。

先决角色:只有当用户已经是另一个角色的成员时，才能将角色分配给该用户；只有当角色已经拥有其他访问权限时，对应的才能将访问权限分配给该角色。想要获得更高的权限，首先要有更低的权限。就像在我们的生活中，总统是从副总统中选出的。

4)集成统一模型:RBAC3

RBAC3包括RBAC1和RBAC2，不仅提供了角色之间的继承关系，还提供了职责分离。

5.基于属性的访问控制(ABAC)

ABAC被认为是权威控制的未来。由于其逻辑复杂，作者还没有透彻理解，所以我只简单介绍一下。

ABAC可以分为访问控制策略、环境条件、主体、对象、主体属性和对象属性。它结合了主体属性、客体属性和环境条件，根据它们与访问控制策略的匹配来确定访问(即系统对象的操作)。

简单来说就是将主体和客体的属性与策略关联起来，通过读取策略来确定主体可以对客体进行哪些操作。

1.熟悉业务流程并评估角色

在设计初期，要对系统中不同模块的业务流程进行重组，通过业务流程图统计各个节点的作用。在这个环节中，需要对角色进行穷尽，以保证系统在运行过程中能够实现闭环。总的来说:

2.清单权限，使用正确的描述。

总结系统中的所有功能模块，根据自己系统要求的粒度来选择权限的粒度。

同时，在PRD中传达一个系统的权限设计规则时，不应该用“when ………”这样的句子来表达规则，而应该将角色和单元绘制成网格，每个交集节点就是描述角色和权限的数据关系和约束。

需要注意的是，在设计数据权限时，查看权限应该始终在“增加、删除、更改和检查”之前设计。

3.无页面权限提示。

一般情况下，当用户没有相应的权限时，页面会被直接隐藏，但不排除用户可以获取权限之外的URL地址，因为当用户在没有权限的情况下访问页面时，需要提醒用户没有相应的权限。

4.创建默认角色

默认角色是系统自带的角色，通常包括超级管理员、管理员、业务员等。

一般情况下，超级管理员是一个隐形角色，由高层领导掌握，拥有整个系统的所有权限。管理员继承超级管理员分配的权限。如果管理员是唯一的，则不能编辑或删除，以防止用户删除管理员角色，导致系统无法正常运行。其余角色由管理员创建，可以编辑或删除。

5.系统的长期规划需要明确。

在搭建权限系统的时候，要详细了解系统的业务范围和长远规划，梳理角色，尽可能多的获取用户信息。

比如在数据权限配置的过程中，我们通过标注数据来划分数据权限，但是随着数据标识和权限判断条件的增加，会有大量的用户信息需要判断。

6.长期维护的用户要及时处理。

当系统长时间运行时，在权限方面，由于用户离职，权限系统没有及时更新，可能会出现内部数据泄露的问题。针对这种情况，产品可以采用权限系统与OA系统的互通或者系统设置的数据自动清理规则来解决这个问题。

7.公司内部的权限规则应该统一。

当一个系统非常大，有几个产品经理负责的时候，可能会出现没有统一的权限规范，导致新的功能因为提需求的时候忘了说明而没有实现权限控制的情况。所以在一个比较大的项目中，产品经理可以对权限和UI做一个统一的标准。

网上优秀维权文章集锦

本文由@李氏自抄原创发布。每个人都是产品经理。未经作者允许，禁止转载。

图片来自Unsplash，基于CC0协议。