资料：
B端系统权限体系知识整理
https://zhuanlan.zhihu.com/p/611331791

以下为上述学习资料的整理

概念

权限管理主要目的是对不同的人访问资源进行权限的控制，避免因权限控制缺失或操作不当引发的风险问题，如操作错误，隐私数据泄露等问题。

权限管理与用户管理、组织架构一起被誉为B端系统的三基座。

在描述权限之前，我们需要先定义清楚资源的概念。
资源可以理解为系统中的字段、按钮、信息区块、页面、菜单、对象、流程等内容，对资源划分的原子化程度，也影响着权限管理的灵活程度。

资源分类

模块资源：指业务功能板块，如：客户管理、线索管理。
一般情况下，分配模块权限，功能模块下的页 面、按钮均同步授予权限。
如：分配客户管理权限，客户列表、客户详情、新增客户、删除客户等按钮同步授予权限。

页面资源：
指特定的功能页面，如：客户列表、客户详情。
一般情况下，分配页面权限，页面下的按钮均同步授予权限，新增
客户、删除客户等

按钮资源： 指特定功能按钮，如：新增、删除、修改、提交等按钮

字段资源： 指功能模块的字段，字段权限控制多出现在paas平台，如：客户的客户名称字段的读写。

**流程资源：**流程资源权限控制多出现在paas平台，在paas平台上支持用户自定义流程并支持设定流程使用权限，包括业务流程，审批流程。流程权限较少单独作为一项权限资源进行管理，通常流程资源和按钮资源权限是一致的，大多数流程都是通过按钮触发。

**业务类型资源：**较少使用的权限资源控制，paas平台支持用户自定义对象的不同业务类型，且支持不同角色可使用不同业务对象。如：客户对象可定义直销客户、渠道客户两种业务类型，那么负责直销的销售使用直销客户，负责渠道的销售使用渠道客户，两种不同的业务类型的客户，字段模型、流程等都可能不同。

解决方式

权限：
是对用户与资源之间关系的定义。或者是主体和客体之间的关系。
解决权限管理的方式，减少映射关系。
管理用户与资源之间的关联关系或映射关系的一种解决方案。
在权限体系构建中我们经常将资源定义为权限或权限项。用“权限”来阐释每种模型的内涵与差异。

1.ACL（访问控制列表 Access Control List）

ACL（AccessControlList）访问控制列表方式：该模型是目前应用最多的方式。目标资源拥有访问权限列表，指明允许哪些用户访问。如果某个用户不在访问控制列表中，则不允许该用户访问这个资源。
《信息系统系项目管理师教程》（第3版）P656

访问控制列表的模型里只有权限与用户两个概念，从权限出发，来定义可访问该权限的用户，维护对应用户清单，从而实现用户与权限之间的映射管理。

如图，权限A指明只有用户1可以访问，权限B指明用户1和用户2可以访问，权限C指明只有用户2可以访问，而权限D不允许用户1和用户2访问。

ACL模型适用场景

• 权限少
• 用户少

场景举例：
邮件抄送，oa系统审批后的抄送，添加抄送人就是针对当前这个权限
指明允许哪些用户访问。

2.DAC( 自主访问控制 Discretionary Access Control)

DAC（DiscretionaryAccess
Control）自主访问控制方式：该模型针对每个用户指明能够访问的资源，对于不在指定的资源列表中的对象不允许访问。
《信息系统系项目管理师教程》（第3版）P656

自主访问从用户角度出发，定义每个用户可以访问哪些权限，维护对应的权限清单。
如图所示，用户1拥有权限B、权限C、权限D的访问权限，而无法访问权限A；用户2拥有权限A、权限D的访问权限，而无法访问权限B、权限C。

DAC模型适用场景：

• 用户少
• 权限多

场景举例：
网盘资源分享场景，选择想要分享的文件，点击分享，生成分享链接，这个分享链接就是一个“用户对象”，这个“用户对象”指定了可以访问我们所选选取的文件。
同理，如果选取另外的文件，等同于创建了一个新的“用户对象”。虽然新的分享链接种的文件可能与之前分享链接中的对象完全重叠，但访问的时候，本质上还是根据不同“用户对象”访问他们被指定允许访问的资源。

3.MAC（强制访问控制 Mandatory Access Control）

MAC（MandatoryAccess
Control）强制访问控制方式，该模型在军事和安全部门中应用较多，‍目标具有一个包含等级的安全标签（如:不保密、限制、秘密、机密、绝密）；访问者拥有包含等级列表的许可，其中定义了可以访问哪个级别的目标：例如允许访问秘密级信息，这时，秘密级、限制级和不保密级的信息是允许访问的，但机密和绝密级信息不允许访问。
《信息系统系项目管理师教程》（第3版）P656

区别于以上两种，强制访问控制在权限与用户之间，增加了标签概念，这里的标签可以理解为由权限抽象出的中间媒介，将权限根据安全等级贴上对应标签，通过标签与用户之间的关联关系实现管理。

MAC模型适用场景：
安全级别较高场景

如军事或安全部门

MAC模型在权限定义的基础上，需要增加标签的设计，这里的标签需要有等级关系，但一般等级不能相同，一旦标签等级调整，意味着权限也会跟着变化，当标签从低等级往高等级调整时，会给已关联的用户释放更多的权限。

标签与用户：一对多
标签与权限：一对多
权限与标签：一对一
已被其他标签关联的权限需要隐藏或不允许选择。
设置用户与标签是也是同样。

4.ABAC（基于属性的权限控制 Attribute-Based Access Control）

灵活性强，通过一个或一组属性来控制用户是否对资源由权限。

ABAC 属性通常来说分为四类：
用户属性：
用户自带的属性，比如年龄，性别，部门，角色等
环境属性：
时间信息、地理位置、访问位置信息，访问平台信息等
操作属性：
读取、删除、查看等
对象属性：
一条记录的修改时间，创建者等，又称资源属性。
ABAC模型本质上是基于策略来管控权限，而策略基于各种灵活的属性动态控制。
它最大的优势在于可以通过将各种更丰富的属性信息进行组合形成访问控制条件，可以细颗粒度地授权在任何情况下对某个资源具备特定的权限，从而灵活适应各种资源访问场景。

提供智能决策的 “防火墙”，以保护对it资源的访问。它应用"if/then"逻辑来确定用户在给定的时间内所呈现的风险。例如：员工在度假期间，利用公共wifi临时访问某一个敏感应用时，会被禁止访问

ABAC模型适用场景：

• 灵活性强
• 充满威胁的环境
• 需对策略加以管理，避免过多可维护性的问题。

场景举例：
基于终端IP
当员工在公司内网访问oa办公系统时，不需要动态密码认证，即可成功访问oa系统。但当员工在外出差办公时，访问需要动态密码。基于员工终端ip属性进行策略下发的场景。

基于用户源
内部员工访问公司核心交换机，认证通过后，具备读写权限（write）,外包人员访问公司核心交换机，认证通过后具备只读权限。

基于用户角色+终端合规性
研发人员使用合规终端（运行了杀毒软件，桌面软件的）接入公司网络，可访问生产网段，研发人员使用非合规终端接入公司网络，仅可访问办公网段。

5.RBAC（基于角色的权限控制 Role-Based Access Control）

ACL、DAC、MAC三类模型往往只适用于权限或者用户一方较少，方便管理的情况，但是在实际的企业系统中，用户基数一般都比较大，同时很多人的权限都是一致的，比如只需要普通的访问权限，此时管理员给100个员工授予访问权限工作量就会巨大。

RBAC模型引入了“角色（Role）”的概念

将角色作为用户与权限之间的媒介，一个角色可以与多个用户关联，一个用户也可以拥有多个角色，管理员只需要把对应的角色赋予用户，那么用户就有了该角色下的所有权限，这样的设计既提升了效率，也有很大的可拓展性。

不直接将权限赋予在用户身上，而是通过角色的媒介过渡，先将权限赋予在角色上，再关联相应的用户，对应的用户就继承了角色的权限，其中

用户：
发起操作的主体，按类型可分为2b和2c用户，可以是后台管理系统的用户，可以是oa系统内部员工，也可以是面向c端的用户，比如阿里云的用户。

角色：
每个角色可以关联多个权限，同时1个用户可以关联多个角色，这个用户就有多个角色的多个权限。用户拥有多个角色时，可访问多个角色关联的权限资源的总和。

权限：
是用户可访问的资源，包括页面权限，操作权限，数据权限。
1.页面权限：
即用户登录系统可以看到的页面，由菜单来控制。
菜单包括一级菜单和二级菜单，只要用户有一级和二级菜单的权限，那么用户就可以访问页面。
2.操作权限
即页面的功能按钮，包括查看，新增，修改，删除，审核等，用户点击删除按钮时，后台会校验用户角色下用户的所有权限是否包含该删除权限，如果是，就可以下一步，反之提示无权限。
有的系统要求，可见即可操作
需前端来配合，前端开发把用户的权限信息缓存，在页面判断用户是否包含此权限，如果有就显示该按钮，如果没有就隐藏该按钮。
3.数据权限
数据权限就是用户在同一页面看到的数据是不同的，比如财务部只能看到其部门下的用户数据，采购部只能看采购部的数据，在一些大型的公司，全国有很多城市和分公司，比如杭州用户登录系统只能看到杭州的数据等。

解决方案一般是把数据和具体的组织架构关联起来。
举个例子，在给用户授权时，用户选择某个角色同时绑定组织如财务部或合肥分公司，那么该用户就有了该角色下财务部或合肥分公司下的数据权
限。

RBAC模型在演进过程中也出现了几种细分，分别为RBAC1、RBAC2、RBAC3，为了方便理解演进的过程与差异，这里再多抽象出RBAC0的模型，下面我们逐个来做分析。

6.RBAC0（基本模型 Core RBAC）

RBAC0（基本模型）定义了完全支持RBAC概念的任何系统的最低需求。
RBAC0的模型中包含了最基础的用户、角色和权限3类实体集合，RABC0是权限管理的核心部分，其他的版本都是建立在0的基础上。

角色与权限关联，用户与角色关联，且都是多对多的关系。
类似于知乎的创作者昂作者权限系统，不同的创作者等级拥有不同的权限，对应不同的角色。

面对一些针对角色的关联管理需求时会显得乏力。比如，系统内存在【大区销售经理】和 【城市销售经理】两个角色，大区销售经理具有查看、审批其所有城市的销售合同的权限，城市销售经理只有查看其下城市的销售合同权限。
【大区销售经理】和【城市销售经理】存在包含的逻辑关系，后者的权限，前者都有，如果后者权限增加，前者的权限也要增加。

7.RBAC1（角色分层模型 Hierarchal RBAC）

RBAC1模型是在RBAC0模型基础上，引入了角色继承的概念，即角色具有上下级的关系，每个等级权限不同，从而实现更细粒度的权限管理。

角色间的继承关系可分为

• 一般继承关系
• 受限继承关系

一般继承关系仅要求角色继承关系是一个绝对偏序关系，允许角色间的多继承。

受限继承关系则进一步要求角色继承关系是一个树结构，实现角色间的单继承。模型适合于角色之间层次明确，包含明确的场景。

8.RBAC2（角色限制模型 Constraint RBAC）

类似于RBAC1对RBAC0的扩展，RBAC2模型引入了角色间的约束关系，来解决业务层面上对于角色分配的一些强制性要求。

比如财务和出纳是否可以是一个人（自己记账，自己拿钱）？公司ceo角色只能赋予单一用户等。

约束关系包含：静态分离和动态分离
静态分离：互斥的角色不能同时赋予同一个用户。
动态分离：用户不能同时操作两个互斥的角色进行登录。

静态分离是在用户和角色的分配阶段加入的，主要的约束形式：
互斥关系角色：
同一用户只能分配到一组互斥角色集合中至多一个角色，互斥角色是指各自权限相互制约的两个角色。
例如：设计部有交互设计师和视觉设计师两个角色，体现职责分离。

基数约定：
一个角色被分配的用户数量受限
一个用户可拥有的角色数目受限
同一个角色对应的访问权限数目受限

先决条件角色：
如某用户想获得上级角色，必须先获得其下一级角色，以此为一个先决条件。

动态分离时，互斥的角色可以同时被赋予同一个用户，用户登录后需要选择使用的角色，同时要支持根据需要切换角色，只能同时激活一个角色。

9.RBAC3（统一模型 Combines RBAC）

RBAC3就是同时包含了RBAC1（继承关系）和RBAC2（约束关系）的特性的统一模型。既具有角色分层，又具有角色约束的模型。

10.数据权限？？？

数据权限定义的是用户或角色在系统中可见、可操作的数据范围权限。关于数据权限的处理，常见的有两种方式，一种是在角色内完成数据权限的定义，另一种是将角色和权限分开，两种方式各有偏重

常见的数据权限有以下几类：
1.基于系统的数据权限：
即系统中的所有表都能被大家看到并管理，也可理解为没有数据权限。比如管理员a,b都能看到并管理所有考生，考官，考场数据。
2.基于对象的数据权限：
即按表划分数据权限，比如管理员a只负责管理考生，管理员b只负责管理考场
3.基于行的数据权限：
即按表中的数据行划分数据权限，比如管理员a智能管理b学校的考生，但不能管理c学校的考生。或a部门的经理只能看到a部门职员的周报。
4.基于列的数据权限：即按表中的数据列划分数据权限，比如管理员只能看到考生的姓名，而管理员b可以看到考生姓名，手机号，身份证号。

在实际问题解决的过程中，经常会遇到使用某单一模型，甚至组合模型也无法实现权限管理诉求的情况。
此时往往在的基础上，引入一些补充性的概念模型，下面列举了一些介绍：

用户组

虽然前面我们应用的rbac权限模型的概念，但是对于大量用户拥有相同权限的用户，我们同样也需要对每个用户设置对应的角色，如果一个部门上万人，那么我们就需要给这个部门上万人分别设置角色。而上万人相同权限，直接采用基础的rbac权限模型的话，那么面对这样的情况，无疑也是具有一个庞大，不利于后期维护，引入用户组的概念。

首先，我们明确一下用户组的定义：把具有相同角色的用户进行分类

引入用户组概念后，就可以把相同属性的用户归类到用户组，那么管理员直接给用户组分配角色，用户组里的每个角色，即可拥有该角色。以后其他用户加入用户组后，即可自动获取用户组的所有角色，退出用户组，同时也撤销了用户组下的角色，无需管理员手动管理角色。

根据用户组是否有上下级关系，可以分为有上下级的用户组和普通用户组：
1.具有上下级关系的用户组，最典型的例子就是部门和职位。当然用户组是可以拓展的，部门和职位常用在内部的管理系统，如果是面向c端的系统，比如淘宝网的商家，商家自身也有一套组织架构，如采购部，销售部，客服部，后勤部，有些人拥有客服权限，有些人拥有上架权限等，这就体现了用户组的扩展性。
2.普通用户组：
即没有上下级关系，和组织架构，职位都没有关系。也就是说可以跨部门，跨职位，举个例子：某电商后台管理系统，有拼团活动管理角色，我们可以设置一个拼团用户组，该组可以包括研发部后台开发人员，运营部的运营人员，采购部的人员等。

权限组

权限组与用户组的原理差不多，是将一些相对固定的功能或者权限建立组的关系，然后再给此权限组赋予角色，

引入组织

组织结构决定了公司内部的层级关系和权力结构。在权限管理中，因为不同层级的用户需要不同的权限，因此组织结构会影响到权限的管理范围。例如，高层管理者通常要管理整个组织的权限，而普通员工只需要管理自己的权限，因此，给用户分配权限时，需要根据组织结构中不同的层级和职位来制定相应的权限策略，并对其进行有效的管理和控制。

其次，职能决定了员工的职责和工作范围，在权限管理中，需要将某个特定任务所需的权限与具体职能进行绑定，以确保员工只能访问他们工作所需权限。如财务人员访问财务报表等。

权限授予

在系统管理中，为用户分配和管理权限是一项关键任务。授权是指授权访问或执行某些操作或功能，给用户授权可以帮助保护系统安全，确保合规性，简化管理和分担责任。

以下是常见的几种授权方式：
1手动授权：
管理员登录权限中心为用户授权。根据在哪个页面授权分为两种方式：给用户添加角色，给角色添加用户。
给用户添加角色就是在用户管理页面，点击某个用户去授权角色，可以一次为用户添加多个角色。给角色添加用户就是在角色管理页面

问题

1.数据权限