常见的系统权限管理模型

目录：
1、ACL模型：访问控制列表
2、DAC模型：自主访问控制
3、MAC模型：强制访问控制
4、ABAC模型：基于属性的访问控制，更灵活复杂
5、RBAC模型：基于角色的权限访问控制，最常用
6、TBAC模型：基于任务和工作流的访问控制
7、T-RBAC模型：基于任务和角色的访问控制
8、OBAC模型：基于对象的访问控制
9、UCON模型：使用控制模型

一、ACL模型：访问控制列表

　　ccess Control List，ACL是最早的、最基本的一种访问控制机制，是基于客体进行控制的模型，在其他模型中也有ACL的身影。为了解决相同权限的用户挨个配置的问题，后来也采用了用户组的方式。
　　在OA系统中，接触了ACL（access control list）模型的权限设计。ACL是一种面向资源的访问控制模型。ACL实体模型的核心在于用户可以直接和权限挂钩，权限模型包括：资源标识、用户标识、授权状态。
　　 原理： ①每一个客体都有一个列表，列表中记录的是哪些主体可以对这个客体做哪些行为，非常简单。②每一项资源，都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行增加(Create)、检索(Retrieve)、更新(Update)和删除(Delete)等操作。当用户试图访问这项资源时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户是否可执行相应的操作。总体来说，ACL是一种面向资源的访问控制模型，它的机制是围绕“资源”展开的。
　　 例如： 当用户A要对一篇文章进行编辑时，ACL会先检查一下文章编辑功能的控制列表中有没有用户A，有就可以编辑，无则不能编辑。 再例如：不同等级的会员在产品中可使用的功能范围不同。
　　 优点： ①ACL权限模型原理简单，直接将权限赋给用户，便于理解和操作。②可以满足个性化的需求，即为系统中的用户单独分配权限。
　　 缺点： ①当主体的数量较多时，配置和维护工作就会成本大、易出错。②由于需要维护每个用户的访问权限列表，管理者工作量大，所以需要解决复用性问题。
　　改进： ACL不仅记录用户—资源—操作表，还记录用户组—资源—操作表，用于记录用户或者用户组对资源拥有的权限。改进之后的权限模型包括：资源标识、主体标识、主体类型（用户或用户组）、授权状态。

二、DAC模型：自主访问控制

　　Discretionary Access Control，DAC是ACL的一种拓展。
　　DAC是自主访问控制模型。
　　 定义： 规定资源可以被哪些主体进行哪些操作，同时，主体可以将资源、操作的权限，授予其他主体。
　　在ACL的基础上，DAC模型将授权的权力下放，允许拥有权限的用户，可以自主地将权限授予其他用户。
　　 原理： 在ACL模型的基础上，允许主体可以将自己拥有的权限自主地授予其他主体，所以权限可以任意传递。
　　DAC的应用场景： DAC常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。在实现上，先对用户鉴权，然后根据控制列表决定用户能否访问资源。用户控制权限的修改通常由特权用户或者管理员组实现。
　　 例如： 常见于文件系统，LINUX，UNIX、WindowsNT版本的操作系统都提供DAC的支持。
　　 缺点： ①对权限控制比较分散，例如无法简单地将一组文件设置统一的权限开放给指定的一群用户。主体的权限太大，无意间就可能泄露信息。②DAC最大缺陷是对权限控制过于分散，比如无法简单地将一组文件设置统一的权限开放给指定的一群用户。③主体的权限太大，授权其他用户时，无意间可能造成泄露信息。

三、MAC模型：强制访问控制

　　Mandatory Access Control，MAC模型中主要的是双向验证机制。常见于机密机构或者其他等级观念强烈的行业，如军用和市政安全领域的软件。
　　MAC是强制访问控制模型，是为了弥补DAC权限控制过于分散的问题而诞生的。主体被赋予一定的安全级别，客体被赋予一定的安全级别，主体能否访问客体由双方的关系安全级别决定，这个判断通常有系统硬性限制。
　　 定义： 当一个操作，同时满足a与b时，允许操作。a. 规定资源可以被哪些类别的主体进行哪些操作；b. 规定主体可以对哪些等级的资源进行哪些操作。
　　MAC是在ACL基础上的另一种实现，强调安全性。MAC会在系统中，对资源与主体，都划分类别与等级。MAC非常适合机密机构或者其他等级观念强烈的行业，但对于类似商业服务系统，则因为不够灵活而不能适用。MAC可以继续使用DAC的模型，但是要对用户进行等级划分，比如一级，二级，三级……，对对象资源也要做划分，比如机密，秘密和最高机密。用户访问的资源的时候，根据用户等级与资源访问级别来做判断，比如一级用户只能访问机密文件，如果访问的是最高机密文件，系统就会拒绝。这一系列规则是优先于DAC的，如果MAC与DAC混用，要先校验MAC再校验DAC。
　　 原理： 主体有一个权限标识，客体也有一个权限标识，而主体能否对该客体进行操作取决于双方的权限标识的关系。
　　 例如： 将军分为上将>中将>少将，军事文件保密等级分为绝密>机密>秘密，规定不同军衔仅能访问不同保密等级的文件，如少将只能访问秘密文件；当某一账号访问某一文件时，系统会验证账号的军衔，也验证文件的保密等级，当军衔和保密等级相对应时才可以访问。
　　 优点： MAC的优势就是实现资源与主体的双重验证，确保资源的交叉隔离，提高安全性。
　　 缺点： ①控制太严格，实现工作量大，缺乏灵活性。②只适用于特定的安全性高要求较高的场景。过重强调保密性，使得管理不够灵活。
　　 改进： 在实现上，MAC和DAC通常为每个用户赋予对客体的访问权限规则集，考虑到管理的方便，在这一过程中还经常将具有相同职能的用户聚集为组，然后再为每个用户组分配权限。

四、ABAC模型：基于属性的访问控制

　　Attribute-Based Access Control，能很好地解决RBAC的缺点，在新增资源时容易维护。
　　ABAC是基于属性的访问控制权限模型。
　　定义： 规定哪些属性的主体可以对哪些属性的资源在哪些属性的环境下进行哪些操作属性。
　　RBAC（Role-Based Access Control ）基于角色的访问控制。RBAC认为权限的过程可以抽象概括为：判断【Who对What是否可进行How的访问操作】：

• Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）。
• What：权限针对的对象或资源（Resource、Class）。
• How：具体的权限（Privilege，正向授权与负向授权）。

　　RBAC的核心思想就是将访问权限与角色相关联，通过给用户分配适合的角色，让用户与访问权限相联系。角色是根据组织内为完成各种不同的任务需要而设置的，根据用户在组织中的职权和责任来设定他们的角色，用户可以在角色间进行转换，系统可以添加、删除角色，还可以对角色的权限进行添加、删除。这样通过应用RBAC可将安全性放在一个接近组织结构的自然层面上进行管理。权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。一个用户拥有若干角色，一个角色拥有若干权限，这就构成“用户-角色-权限”的授权模型。
　　在RBAC之中，用户和角色是多对多的关系，角色与权限也是多对多关系：

• 一个用户在不同的场景下可以拥有不同的角色，例如项目经理也可以是项目架构师等。
• 一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等。
• 一个角色可以拥有多项权限，同一个权限也可以授给多个角色。

　　RBAC引入了角色的概念，目的是为了隔离用户与权限。角色（Role）作为一个用户（User）与权限（Privilege）的代理层，解耦了权限和用户的关系，所有的授权应该给予角色而不是直接给用户。基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理成本。 2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
　　 原理： 通过动态计算一个或一组属性是否满足某种机制来授权，是一种很灵活的权限模型，可以按需实现不同颗粒度的权限控制。这个模型在云系统中使用的比较多，比如 AWS，阿里云等。
考虑下面这些场景的权限控制：

• 授权某个人具体某本书的编辑权限
• 当一个文档的所属部门跟用户的部门相同时，用户可以访问这个文档
• 当用户是一个文档的拥有者并且文档的状态是草稿，用户可以编辑这个文档
• 早上九点前禁止 A 部门的人访问 B 系统
• 在除了上海以外的地方禁止以管理员身份访问 A 系统
• 用户对 2022-06-07 之前创建的订单有操作权限
• 可以发现上述的场景通过 RBAC模型 很难去实现，因为 RBAC模型 仅仅描述了用户可以做什么操作，但是操作的条件，以及操作的数据，RBAC模型 本身是没有这些限制的。但这恰恰是 ABAC模型 的长处，ABAC模型 的思想是基于用户、访问的数据的属性、以及各种环境因素去动态计算用户是否有权限进行操作。

在 ABAC模型 中，一个操作是否被允许是基于对象、资源、操作和环境信息共同动态计算决定的。
　　 主体/对象的属性： 指的是与主体相关的所有信息，包括主体的年龄、性别、职位等。对象是当前请求访问资源的用户。用户的属性包括 ID，个人资源，角色，部门和组织成员身份等
　　 资源的属性： 指的是与资源相关的所有信息，包括资源的创建时间、创建位置、密级等。资源是当前用户要访问的资产或对象，例如文件，数据，服务器，甚至 API
　　 操作的属性： 指的是可进行的全部操作，如增删改查等。操作是用户试图对资源进行的操作。常见的操作包括“读取”，“写入”，“编辑”，“复制”和“删除”
　　 环境的属性： 指的是客观情况的属性，比如当前的时间、当前的位置、当前的场景（普通状态、紧急状态）。环境是每个访问请求的上下文。环境属性包含访问的时间和位置，对象的设备，通信协议和加密强度等。
　　在 ABAC模型 的决策语句的执行过程中，决策引擎会根据定义好的决策语句，结合对象、资源、操作、环境等因素动态计算出决策结果。每当发生访问请求时，ABAC模型 决策系统都会分析属性值是否与已建立的策略匹配。如果有匹配的策略，访问请求就会被通过。
　　当企业中参与权限管理的用户数量很多、或者角色数量很多时，传统的RBAC模型会显露出一些缺点，比如容易遗漏需要参与到权限管理的部分用户，并且容易受到“角色数量爆炸”的影响。RBAC虽然是目前最普遍的权限控制模型。但是某些情况下，RBAC是无法满足并且也实现不了的。比如业务员1和业务员2都属于业务员角色，都有查看客户订单的权限。当有一个需求，要求业务员1只能查看北京地区的客户的订单，业务员2只能查看上海的客户的订单。这单单使用RBAC是无法实现。借助RBAC，可行的做法是，分地区创建角色，然后程序中根据角色做数据的过滤，这种做法缺点是，每次需求变更的时候可能都需要修改代码。
　　此时需要新的权限管理方法来控制对企业的访问，允许特定用户在特定场景下拥有特定权限。通常考虑的第一种解决方案是基于属性的访问控制（ABAC），会在系统中设置好基于用户属性、资源属性、环境属性和操作权限的预定义规则，当某个用户进入到系统中时，会获取用户和当前场景的属性，基于这些属性，自动为该用户分配权限。所以说，ABAC中可以完全自动化——可根据所获取到的属性进行自动判定和授权，而不需要使用管理员手动设置授权。
　　传统的 RBAC 与 ACL 等访问控制机制，可以认为是 ABAC 的子集。对于 RBAC来说，访问机制的实现只是基于主体的属性“角色”而已，ACL 只是基于主体的属性是“单个用户”。而ABAC 基于更多的属性，能做到更细粒度的授权管理。例如，ABAC权限模型中通过众多属性来决策实现，只有姓张的工程师在处理项目A时才能访问某个资源，其中“姓张、工程师、项目A”都是决策所依据的属性。因此，ABAC模型不需要关注特定的用户好角色，只需要对提炼出的各种“属性”进行授权规则设置，管理对象为属性和权限。
　　ABAC对用户本身的属性进行标识，通过属性标识来判断用户权限。这样的设计使得ABAC非常灵活，可扩展性也很高。ABAC一般来说，都是搭配着ACL或RBAC一起使用，不会单独成体系。以上述业务员查看订单为例，说明ABAC的一种实现方式：

• 在RBAC的基础上，扩展一个实体规则。其中，订单就是实体，地区是实体的属性。
• 然后针对实体（订单）的属性（地区）设置一系列规则。规则存储格式可以是json、SQL语句等等，能解析即可。规则为：业务员1只能查看北京地区的客户的订单，业务员2只能查看上海的客户的订单。
• 保存规则，包括规则内容(即json、SQL语句等)、规则实体(即订单)、适用操作（即增删改查等）。
• 将创建好实体的规则与角色做关联，也就是将北京地区的规则关联到北京地区业务员角色上，上海地区的规则关联到上海地区业务员角色上。
• 后端做权限校验的时候，还是先按RBAC模型的控制方式进行校验(是否具备订单查看权限)，然后根据当前操作对象(也就是实体)，取出用户所属角色关联的对应实体的规则。然后解析规则，动态拼接Sql语句。

　　以上只是针对地区属性实现了动态权限控制。实际业务中，要控制可能更多，比如字段权限、数据范围等等。要满足这些复杂的控制，需要制定一套完整的规则，以及针对规则编写相应的解析程序。
　　例如： 早上9:00，11:00期间A、B两个部门一起以考生的身份考试，下午14:00，17:00期间A、B两个部门相互阅卷。
　　优点：①可适用于用户数量和角色数量很多的权限管理场景，在设置好预定义规则之后，系统可对用户进行自动授权，不需要使用管理员手动设置授权。 ②通过对角色设置权限，可一次性对角色下的所有用户设置权限。在角色组中增删单个成员，也不会对角色组整体产生影响。
　　缺点： ①规则复杂，不易看出主体与客体之间的关系，实现非常难，现在应用的很少。②由于权限是以角色为载体分配的，因此无法对某一角色下的个别用户需要进行特别的权限定制，只能再重新创建角色。即不可对角色组下的单个成员进行个性化权限设置。③当采用ABAC模型时，随着属性数量的不断增加，定义与单个用户相关联的每个属性的复杂性也随之增加，从而增加了管理整个企业的访问管理的难度。需要IT团队部署和维护。④实现成本高：ABAC非常的灵活，但是实现比较困难。这其中涉及到逻辑的动态执行，数据动态过滤等，更加具体就是动态拼接SQL语句。
　　基于属性的访问控制模型(ABAC)被认为是访问控制模型的未来。但并不是当前权限管理场景下的最优方案。

五、RBAC，基于角色的权限访问控制

　　Role-Based Access Control，核心在于用户只和角色关联，而角色代表对了权限，是一系列权限的集合。
RBAC三要素：
　　用户： 系统中所有的账户
　　角色： 一系列权限的集合（如：管理员，开发者，审计管理员等）
　　权限： 菜单，按钮，数据的增删改查等详细权限。
　　RBAC（Role-Based Access Control ）基于角色的访问控制。RBAC认为权限的过程可以抽象概括为：判断【Who对What是否可进行How的访问操作】：

• Who：权限的拥用者或主体（如Principal、User、Group、Role、Actor等等）。
• What：权限针对的对象或资源（Resource、Class）。
• How：具体的权限（Privilege，正向授权与负向授权）。

　　RBAC的核心思想就是将访问权限与角色相关联，通过给用户分配适合的角色，让用户与访问权限相联系。角色是根据组织内为完成各种不同的任务需要而设置的，根据用户在组织中的职权和责任来设定他们的角色，用户可以在角色间进行转换，系统可以添加、删除角色，还可以对角色的权限进行添加、删除。这样通过应用RBAC可将安全性放在一个接近组织结构的自然层面上进行管理。权限被赋予角色,而不是用户，当一个角色被指定给一个用户时，此用户就拥有了该角色所包含的权限。一个用户拥有若干角色，一个角色拥有若干权限，这就构成“用户-角色-权限”的授权模型。
　　在RBAC之中，用户和角色是多对多的关系，角色与权限也是多对多关系：

• 一个用户在不同的场景下可以拥有不同的角色，例如项目经理也可以是项目架构师等。
• 一个角色可以给多个用户，例如一个项目中有多个组长，多个组员等。
• 一个角色可以拥有多项权限，同一个权限也可以授给多个角色。

　　RBAC引入了角色的概念，目的是为了隔离用户与权限。角色（Role）作为一个用户（User）与权限（Privilege）的代理层，解耦了权限和用户的关系，所有的授权应该给予角色而不是直接给用户。基于角色的访问控制方法（RBAC）的显著的两大特征是：1.由于角色/权限之间的变化比角色/用户关系之间的变化相对要慢得多，减小了授权管理的复杂性，降低管理成本。 2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。
　　在RBAC中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。
　　角色是为了完成各种工作而创造，用户则依据它的责任和资格来被指派相应的角色，用户可以很容易地从一个角色被指派到另一个角色。
　　角色可依新的需求和系统的合并而赋予新的权限，而权限也可根据需要而从某角色中回收。角色与角色的关系同样也存在继承关系防止越权。
　　优点： ①RBAC是把用户按角色进行归类，通过用户的角色来确定用户能否针对某项资源进行某项操作。相对于ACL最大的优势就是它简化了用户与权限的管理，通过对用户进行分类，使得角色与权限关联起来，而用户与权限变成了间接关联，从而解耦。②通过对角色设置权限，可一次性对角色下的所有用户设置权限。在角色组中增删单个成员，也不会对角色组整体产生影响。③便于角色划分，更灵活的授权管理；最小颗粒度授权；

　　以一个简单的场景（Gitlab 的权限系统）为例，用户系统中有 Admin、Maintainer、Operator 三种角色，这三种角色分别具备不同的权限，比如只有 Admin 具备创建代码仓库、删除代码仓库的权限，其他的角色都不具备。

　　我们授予某个用户「Admin」这个角色，他就具备了「创建代码仓库」和「删除代码仓库」这两个权限。
　　不直接给用户授权策略，是为了之后的扩展性考虑。比如存在多个用户拥有相同的权限，在分配的时候就要分别为这几个用户指定相同的权限，修改时也要为这几个用户的权限进行一一修改。有了角色后，我们只需要为该角色制定好权限后，给不同的用户分配不同的角色，后续只需要修改角色的权限，就能自动修改角色内所有用户的权限。
　　 缺点： ①由于权限是以角色为载体分配的，因此无法对某一角色下的个别用户需要进行特别的权限定制，只能再重新创建角色。即不可对角色组下的单个成员进行个性化权限设置。②RBAC模型只给角色赋予了权限，没有提供这些权限的操作顺序控制机制。这一缺陷使得RBAC模型很难应用关于那些要求有严格操作顺序的实体系统。例如，在购物控制系统中要求系统对购买步骤的控制，在客户未付款之前不应让他把商品拿走。RBAC模型要求把这种控制机制放到权限模型中预设好。
　　 改进： 原来模型关系为“用户—角色—权限”，为了解决个性化问题，可在此基础上，增加“用户—权限”的关联关系。除了可以给角色授权外，还可以给用户直接授权。这样一来，用户拥有的所有权限，就是用户个人拥有的权限与该用户所在角色拥有的权限之和。

RBAC的深度拓展

　　RBAC模型可以分为：RBAC0、RBAC1、RBAC2、RBAC3 四个阶段，一般公司使用RBAC0的模型就可以。另外，RBAC0相当于底层逻辑，后三者都是在RBAC0模型上的拔高。
简单介绍下这四个RBAC模型：

1. RBAC0模型

　　用户和角色、角色和权限多对多关系。
　　简单来说就是一个用户拥有多个角色，一个角色可以被多个用户拥有，这是用户和角色的多对多关系；同样的，角色和权限也是如此。
RBAC0模型如下图：没有画太多线，但是已经能够看出多对多关系。

2. RBAC1模型

　　相对于RBAC0模型，增加了角色分级的逻辑，类似于树形结构，下一节点继承上一节点的所有权限，如role1根节点下有role1.1和role1.2两个子节点

　　角色分级的逻辑可以有效的规范角色创建（主要得益于权限继承逻辑），我之前做过BD工具（类CRM），BD之间就有分级（经理、主管、专员），如果采用RBAC0模型做权限系统，我可能需要为经理、主管、专员分别创建一个角色（角色之间权限无继承性），极有可能出现一个问题，由于权限配置错误，主管拥有经理都没有权限。
　　而RBAC1模型就很好解决了这个问题，创建完经理角色并配置好权限后，主管角色的权限继承经理角色的权限，并且支持针对性删减主管权限。

3. RBAC2模型

基于RBAC0模型，对角色增加了更多约束条件。

　　如角色互斥，比较经典的案例是财务系统中出纳不得兼管稽核，那么在赋予财务系统操作人员角色时，同一个操作员不能同时拥有出纳和稽核两个角色。
　　如角色数量限制，例如：一个角色专门为公司CEO创建的，最后发现公司有10个人拥有CEO角色，一个公司有10个CEO？这就是对角色数量的限制，它指的是有多少用户能拥有这个角色。
　　RBAC2 模型主要是为了增加角色赋予的限制条件，这也符合权限系统的目标：权责明确，系统使用安全、保密。

4. RBAC3模型

　　同样是基于RBAC0模型，但是综合了RBAC1和RBAC2的所有特点
　　这里就不在多描述，读者返回去看RBAC1和RBAC2模型的描述即可。

RBAC 权限管理的在实际系统中的应用

　　RBAC 权限模型由三大部分构成，即用户管理、角色管理、权限管理。
　　用户管理按照企业架构或业务线架构来划分，这些结构本身比较清晰，扩展性和可读性都非常好。
　　角色管理一定要在深入理解业务逻辑后再来设计，一般使用各部门真实的角色作为基础，再根据业务逻辑进行扩展。
　　权限管理是前两种管理的再加固，做太细容易太碎片，做太粗又不够安全，这里我们需要根据经验和实际情况来设计。

1.用户管理

　　用户管理中的用户，是企业里每一位员工，他们本身就有自己的组织架构，我们可以直接使用企业部门架构或者业务线架构来作为线索，构建用户管理系统。

2.角色管理

　　在设计系统角色时，我们应该深入理解公司架构、业务架构后，再根据需求设计角色及角色内的等级。
　　一般角色相对于用户来说是固定不变的，每个角色都有自己明确的权限和限制，这些权限在系统设计之处就确定了，之后也轻易不会再变动。

1. 自动获得基础角色

　　当员工入职到某部门时，该名员工的账号应该自动被加入该部门对应的基础角色中，并拥有对应的基础权限。这种操作是为了保证系统安全的前提下，减少了管理员大量手动操作。使新入职员工能快速使用系统，提高工作效率。

2. 临时角色与失效时间

　　公司业务有时需要外援来支持，他们并不属于公司员工，也只是在某个时段在公司做支持。此时我们需要设置临时角色，来应对这种可能跨多部门协作的临时员工。
　　如果公司安全级别较高，此类账号默认有固定失效时间，到达失效时间需再次审核才能重新开启。避免临时账号因为流程不完善，遗忘在系统中，引起安全隐患。

3. 虚拟角色

　　部门角色中的等级，可以授权同等级的员工拥有相同的权限，但某些员工因工作原因，需要调用角色等级之外的权限，相同等级不同员工需要使用的权限还不相同。
　　这种超出角色等级又合理的权限授予，我们可以设置虚拟角色。这一虚拟角色可集成这一工作所需的所有权限，然后将它赋予具体的员工即可。这样即不用调整组织架构和对应的角色，也可以满足工作中特殊情况的权限需求。

4. 黑白名单

　　白名单：某些用户自身不拥有某部门的顶级角色，但处于业务需求，需要给他角色外的高级权限，那么我们可以设计限制范围的白名单，将需要的用户添加进去即可。
　　在安全流程中，我们仅需要对白名单设计安全流程，即可审核在白名单中的特殊用户，做到监控拥有特殊权限的用户，减少安全隐患。
　　 黑名单 ：比较常见的黑名单场景是某些犯了错误的员工，虽然在职，但已经不能给他们任何公司权限了。这种既不能取消角色关联，也不能完全停用账号的情况，可以设置黑名单，让此类用户可以登录账号，查看基本信息，但大多数关键权限已经被黑名单限制。

3. 权限管理

　　权限管理一般从三个方面来做限制。页面/菜单权限，操作权限，数据权限。

1. 页面/菜单权限

　　对于没有权限操作的用户，直接隐藏对应的页面入口或菜单选项。这种方法简单快捷直接，对于一些安全不太敏感的权限，使用这种方式非常高效。

2. 操作权限

　　操作权限通常是指对同一组数据，不同的用户是否可以增删改查。对某些用户来说是只读浏览数据，对某些用户来说是可编辑的数据。

3. 数据权限

　　对于安全需求高的权限管理，仅从前端限制隐藏菜单，隐藏编辑按钮是不够的，还需要在数接口上做限制。如果用户试图通过非法手段编辑不属于自己权限下的数据，服务器端会识别、记录并限制访问。

4. 数据权限如何管控

　　数据权限可以分为行权限和列权限。行权限控制：看多少条数据。列权限控制：看一条数据的多少个字段
　　简单系统中可以通过组织架构来管控行权限，按照角色来配置列权限，但是遇到复杂情况，组织架构是承载不了复杂行权限管控，角色也更不能承载列的特殊化展示。
　　目前行业的做法是提供行列级数据权规则配置，把规则当成类似权限点配置赋予某个角色或者某个用户。

用户管理系统权限设计中的更多实践细节

1.超级管理员

　　超级管理员是用来启动系统，配置系统的账号。这个账号应该在配置好系统，创建管理员之后被隐藏起来。超级管理员账号拥有系统中全部权限，可穿梭查看各部门数据，如果使用不恰当，是系统管理的安全隐患。

2.互斥角色如何处理

　　当用户已经有用的角色和即将添加的角色互相互斥时，应该在添加新角色时，提示管理员因角色互斥的原因，无法进行新角色添加。如需添加，要先撤销掉前一个角色，再添加新角色。

3.用户管理权限系统设计一定要简单清晰

　　在设计权限系统之处，一定要理清思路，一切从简，能不增加的多余角色和权限逻辑，就一定不要增加。因为随着公司业务的扩大，权限和角色也会随之增多，如果初期设计思路不严谨，那么权限系统会随着业务的扩大而无限混乱下去，此时再来整理权限，已经太晚了。所以初期设计就一定要条理清晰，简单明了，能避免后续非常多不必要的麻烦。

4.无权提示页

　　有时员工 A 会直接给员工 B 分享他当下正在操作的页面，但有可能员工 B 无权查看。此时我们应该在这里考虑添加「无权提示页」，避免粗暴的 404 页面让员工 B 以为是系统出错了。

六、TBAC模型：基于任务的访问控制

　　对象的访问权限控制并不是静止不变的，而是随着执行任务的上下文环境发生变化。
　　TBAC模型由工作流，授权结构体，受托人集，许可集四部分组成。
　　TBAC模型一般用五元组（主体，客体，许可，生命周期，授权步）来表示。
　　如：去银行办理：柜员在窗口有读取权，上交上一级后失去这个权利。
　　被赋予某个任务的时候才能有这个权限。
　　
　　TBAC是基于任务的访问控制模型。它从工作流中的任务角度建模,可以依据任务和任务状态的不同,对权限进行动态管理。适用于工作流、分布式处理和事务管理系统中的决策制定与权限管理。
　　ACL、RBAC、DAC、MAC都是从系统的角度(控制环境是静态的)出发保护资源。其访问控制的原理可以简单地描述为:如果主体对某客体有访问操作请求,而且主体拥有操作权限,则提供访问操作。
　　工作流是为完成某一目标而由多个相关的任务(即活动)构成的业务流程。工作流所关注的问题是处理过程的自动化，对人和其他资源进行协调管理，从而完成整个工作流程。当数据在工作流中流动时,执行操作的用户在改变，用户的权限也在改变，这与数据处理的前后节点环境相关。采用传统的访问控制技术，如 DAC、MAC等，则难以做到这一点；若采用 RBAC，也需要频繁地更换角色，且不适合工作流程的运转。TBAC则可对工作流中的各任务节点进行动态权限管理。在 TBAC 中，主体（即角色组等）的访问权限并不是静止不变的，而是随着工作流的任务流转不断发生变化。在工作流中，每一步对数据的处理都与以前的处理相关，相应的访问控制也是这样，因而TBAC是一种与前后任务节点相关的访问控制模型。
　　基于任务的权限模型有以下特点：

• TBAC不仅能对不同工作流实行不同的访问控制策略,也能对同一工作流的不同任务节点实行不同的访问控制策略。

• 因为任务都有时效性（即工作流流转到下个任务节点时，当前任务节点时效结束），所以TBAC中，用户对于授予他的权限使用也是有时效性的。
  　　 优点： 在业务流、工作流等特定情况下，可以动态管理权限，比传统的静态权限模型更贴合场景。
  　　 缺点： 实现成本高，需要IT团队开发和维护。工作流的任务节点数量和形式可能不固定，各节点的流转要求也不尽相同，每次进行调整时都要对权限模型进行修改。只有在结构稳定工作流中，才可稳定运行。

  七、T-RBAC模型：基于任务和角色的访问控制模型

  　　T-RBAC 模型把任务和角色置于同等重要的地位, 它们是两个独立而又相互关联的重要概念。任务是RBAC 和TBAC能结合的基础。
  　　T-RBAC 模型中是先将访问权限分配给任务,再将任务分配给角色,角色通过任务与权限关联,任务是角色和权限交换信息的桥梁。
  　　在T-RBAC模型中, 任务具有权限,角色只有在执行任务时才具有权限, 当角色不执行任务时不具有权限;权限的分配和回收是动态进行的,任务根据流程动态到达角色, 权限随之赋予角色,当任务完成时,角色的权限也随之收回;角色在工作流中不需要赋予权限。这样, 不仅使角色的操作、维护和任务的管理变得简单方便, 也使得系统变得更为安全。

  八、OBAC模型：基于对象的访问控制

  　　将访问控制列表与受控对象或受控对象的属性相关联，并将访问控制选项设计成为用户，组或角色及其对应权限的集合。
  　　允许对策略和规则进行重用，继承和派生操作。派生对象可以继承父对象的访问控制设置。
  　　可以减轻由于信息资源的派生，演化和重组等带来的分配
  　　一个单位可能混合使用五种访问控制机制。最常用是OBAC，强制访问控制比较少。学校里有基于角色的，有基于任务的。
  　　网络访问控制的应用
  MAC地址过滤： 自主访问控制，网桥自行定义。
  ACL访问控制列表： 自主访问控制，用IP来做访问控制。有一个路由表（选路，确定网域）。
  VLAN隔离： OBAC，虚拟网络需要一个表，网域切分。
  防火墙访问控制： TBAC任务流，决定账号，packet等能不能通过，由于机制比较多，使用比较多的表。
  　　控制策略和控制规则是OBAC访问控制系统的核心所在，在基于受控对象的访问控制模型中，将访问控制列表与受控对象或受控对象的属性相关联，并将访问控制选项设计成为用户、组或角色及其对应权限的集合；同时允许对策略和规则进行重用、继承和派生操作。这样，不仅可以对受控对象本身进行访问控制，受控对象的属性也可以进行访问控制，而且派生对象可以继承父对象的访问控制设置，这对于信息量巨大、信息内容更新变化频繁的管理信息系统非常有益，可以减轻由于信息资源的派生、演化和重组等带来的分配、设定角色权限等的工作量。
  　　OBAC从信息系统的数据差异变化和用户需求出发，有效地解决了信息数据量大、数据种类繁多、数据更新变化频繁的大型管理信息系统的安全管理。OBAC从受控对象的角度出发，将访问主体的访问权限直接与受控对象相关联，一方面定义对象的访问控制列表，增、删、修改访问控制项易于操作，另一方面，当受控对象的属性发生改变，或者受控对象发生继承和派生行为时，无须更新访问主体的权限，只需要修改受控对象的相应访问控制项即可，从而减少了访问主体的权限管理，降低了授权数据管理的复杂性。

  九、UCON模型：使用控制( UsageControl:UCON) 模型

  　　使用控制( UsageControl:UCON) 模型 , 也称ABC模型。UCON模型包含三个基本元素: 主体、客体、权限和另外三个与授权有关的元素: 授权规则、条件、义务。
  UCON模型中的主要元素如下:
  　　主体( Subjects)。它是具有某些属性和对客体(Objects)操作权限的实体。主体的属性包括身份、角色、安全级别、成员资格等。这些属性用于授权过程。客体( Objects) 。它是主体的操作对象,它也有属性,包括安全级别、所有者、等级等。这些属性也用于授权过程。
  　　权限( Rights)。它是主体拥有的对客体操作的一些特权。权限由一个主体对客体进行访问或使用的功能集组成。UCON中的权限可分成许多功能类, 如审计类、修改类等。
  　　授权规则( AuthorizationRules) 。它是允许主体对客体进行访问或使用前必须满足的一个需求集。授权规则是用来检查主体是否有资格访问客体的决策因素。
  　　条件( Condiions)。它是在使用授权规则进行授权过程中, 允许主体对客体进行访问权限前必须检验的一个决策因素集。条件是环境的或面向系统的决策因素。条件可用来检查存在的限制, 使用权限是否有效,哪些限制必须更新等。
  　　义务( Obligations)。它是一个主体在获得对客体的访问权限后必须履行的强制需求。分配了权限, 就应有执行这些权限的义务责任。
  　　在UCON模型中, 授权规则、条件、义务与授权过程相关,它们是决定一个主体是否有某种权限能对客体进行访问的决策因素。基于这些元素, UCON有四种可能的授权过程, 并由此可以证明:UCON模型不仅包含了DAC,MAC, RBAC, 而且还包含了数字版权管理(DRM)、信任管理等。UCON 模型涵盖了现代商务和信息系统需求中的安全和隐私这两个重要的问题。因此, UCON模型为研究下一代访问控制提供了一种有希望的方法, 被称作下一代访问控制模型。

十、EBAC权限模型

　　EBAC是基于受控实体的访问控制技术。对各种客观存在的和逻辑定义的企业信息资源（即主体拥有访问权限的客体），定义为受控实体。
　　传统的访问控制策略 DAC和 MAC存在安全缺陷和应用复杂性等问题，当前企业应用系统中采用较多的是RBAC。在访问控制对象和操作比较明确的系统中，RBAC 能够提供一种灵活、有效的用户行为能力的组织机制。但 RBAC 是一种被动的、提前授权的访问控制技术，主体可以无限制使用其拥有的客体及客体资源的访问权限，不能依据操作环境进行访问主体和客体的动态变更。
　　TBAC通过对工作流中任务步骤的动态授权，可以清晰地表达复杂工作流的控制机制，主体权限的时效性也因任务的时效性得以解决，在一定程度上能够实现授权管理的自动化。但是TBAC强调工作流各任务的原子性，受限于工作流和任务的数量，造成权限配置的复杂性。其次，主体访问权限的动态性和频繁改变的特性，增加了系统安全控制实现的难度，也给整个系统的运行效率造成影响。
　　EBAC模型以受控实体为访问客体，并以其为中心实现安全控制机制。一方面，用户通过对受控实体的管理，间接获取访问权限；另一方面，受控实体可动态地对用户权限集和属性集的访问进行自主控制。EBAC 是一个随受控实体业务调度变化的动态访问控制模型。EBAC 充分利用企业资源类属的有限性和依据管理策略组织的特性，以受控实体为访问客体，并由其自主控制访问主体对访问客体权限集和属性集的访问能力，采用静态权限分配和动态权限授予相结合的方式。