3.5　访问控制

身份认证一般与授权控制是相互联系的，访问控制是指一旦用户的身份通过认证以后，确定哪些资源该用户可以访问、可以进行何种方式的访问操作等问题。一般根据系统设置的安全规则或安全策略，用户可以访问而且只能访问被授权的资源。访问控制是网络安全防范和保护的主要策略，它的主要任务是保证网络资源不被非法使用和访问。它是保证网络安全最重要的核心策略之一。访问控制涉及的技术也比较广，包括入网访问控制、网络权限控制、目录级控制及属性控制等多种手段。

对于企业信息化系统的访问控制，很多企业应用系统数量较多，从几个应用系统到十几个甚至几十个应用系统，各个应用系统独立采购、独立实施，缺少统一规划，权限体系各不相同。各自系统面向用户群不同，有的面向全体员工，有的面向某个部门，有的面向某些岗位，用户类型多样。各自系统权限体系独立管理维护，各自为政，为日常的管理员授权、权限变更、权限清理带来了不小的困扰，在很多情况下，申请人不知道自己需要的权限，而管理员也不清楚申请人申请的权限是否达到权限最小化的要求，加之系统数量又多，结合到一起导致了企业里权限管理和使用混乱，很难梳理清楚、说得明白。用户在多个系统中都有账号，但是无法直观、快速地了解用户在企业中到底具备哪些系统权限，权限的高低也很难统计，用户离职后账号权限无法做到快速权限清理，往往人员离职半年后此人的管理员账号依然可以使用，这带来了很多安全隐患。

IAM系统的统一授权管理对企事业单位内部应用系统的访问权限进行统一管理，将分布在各个系统中的权限管理模块统一规划在IAM系统中，由IAM系统集中管控多个业务系统的权限相关信息，提升管理员系统配置管理效率和应用访问安全性。

3.5.1　访问控制框架与模型

在典型的访问控制框架中，有策略执行点（Policy Enforcement Point，PEP）和策略决策点（Policy Decision Point，PDP）。PEP用于表达请求和执行访问控制决定。PDP从PEP处接收请求，评估适用于该请求的策略，并将授权决定返回给 PEP。访问控制框架逻辑图如图3-17所示。

主体是指请求对某种资源执行某些动作的请求者。

资源是指系统提供给请求者使用的数据、服务和系统组件。

策略是指一组规则，规定主体对资源使用的一些要求，多个策略进行组合形成策略集（Policy Set）。

策略执行点（PEP）是指在一个具体的应用环境下执行访问控制的实体，将具体应用环境下访问控制请求转换为适应计算机编程语言要求的策略请求；然后根据决策请求的判决结果执行相应的动作，如允许用户请求和拒绝用户请求等。

策略决策点（PDP）是指系统中授权的实体，依据访问控制框架描述的访问控制策略以及其他属性信息进行访问控制决策。

策略管理点（Policy Administration Point，PAP）是指在系统中产生和维护安全策略的实体。

策略信息点（Policy Information Point，PIP）是指通过它可以获取主体、资源和环境的属性信息的实体。

详细的访问控制过程见3.5.2节。

IAM系统的统一授权功能模块支持多种授权策略的管理模式，所有多层次细粒度的访问控制策略可在IAM系统统一管理、统一存储，也可以在各个信息化资源自身平台分散管理、分散存储，但分散的策略管理和存储需要依赖统一访问控制框架，需要以IAM系统的统一访问控制框架为基础。

IAM系统也应支持不同层次的访问控制。首先，应满足应用级别层次的访问控制，如菜单、标签页、表格、文本字段、按钮、树字节等。其次，根据需要可满足功能模块级别的访问控制，如交易模块、服务模块、URL等。此层级也可由各下游系统独立实现本系统功能模块的访问权限控制，结合IAM系统的统一访问框架，实现功能模块级别的访问控制。最后，针对数据层级的访问控制，如数据访问范围、数据操作方式进行访问控制，此层级也可以由各下游系统独立实现本系统数据的访问权限控制，结合IAM系统的统一访问框架，实现数据层级的访问控制。

访问控制的核心是授权策略。按授权策略来划分，常用的访问控制模型有以下几种：传统的访问控制模型（如ACL/DAC/MAC）、基于角色的访问控制（RBAC）模型、基于属性的访问控制（ABAC）模型、基于任务的访问控制（TBAC）模型、基于任务和角色的访问控制（T-RBAC）模型等。常用的访问控制模型汇总如表3-7所示。

3.5.2　访问控制过程

访问控制的过程包括两部分：一是系统管理员下发相应的访问控制策略，完成访问控制的初始化过程；二是信息化资源收到主体访问资源请求后，策略决策点判断访问主体的授权结果并返回策略执行点，策略执行点执行访问控制策略。

访问控制过程简图如图3-18所示，可以分为初始化过程（集中授权管理）和访问控制判断过程，初始化过程包括步骤1和步骤2，访问控制判断过程包括步骤3～步骤6。

步骤1：策略管理。策略管理平台用于管理访问控制策略，制定和产生访问控制策略是访问控制决策的基础。

步骤2：策略授权分发。访问控制策略通过策略分发组件推送到策略缓存库。待用户访问客体资源时，策略决策点从策略缓存库取出相应的访问控制策略。

步骤3：请求访问。策略执行点（PEP）收到用户访问资源请求。在一个具体的应用程序环境下，策略执行点截获用户发送的访问控制请求，这个访问控制请求的内容和格式根据不同的应用程序而不同。

步骤4：请求。策略执行点发送用户请求至策略决策点（PDP）。策略执行点将截获的访问控制请求发送给访问控制策略决策点，请求它进行访问控制决策。

步骤5：响应。策略决策点将判断授权结果返回策略执行点。策略决策点在判断授权结果时可以根据访问主体的角色、访问主体的属性、环境的属性、被访问资源的属性信息，以及工作流任务状态共同判断授权结果。

步骤6：授权访问资源。根据授权结果访问相应资源。在返回的决策结果中可能是拒绝的，也可能是许可的，还可能是带有相应的职责信息的，如需要进行日志记录等。

步骤7：访问资源。

1.统一鉴权模式

访问主体在通过IAM系统访问IAM系统纳管的资源客体时，IAM系统会对访问主体进行统一鉴权，权限鉴定后才能访问有权限的客体资源。IAM系统在对访问主体鉴权前，需要对访问主体进行集中授权。

集中授权管理主要是指当集中对访问主体访问信息化资源客体时，对权限的统一合理分配，实现不同用户对系统不同部分资源的访问控制。具体地说，就是集中实现对各访问主体能够以什么样的方式访问哪些资源客体的管理。

在集中授权里强调的集中是逻辑上的集中，而不是物理上的集中。即在各网络设备、主机系统、应用系统中可能还拥有各自的权限管理功能，管理员也由各自的归口管理部门委派，但是这些管理员从统一授权系统进去以后，可以对各自的管理对象进行授权，而不需要进入每个被管理对象才能授权。

统一鉴权往往包括两部分：身份认证和访问控制。身份认证是指确认访问主体的身份，是鉴权的第一步拦截点；访问控制是对通过身份认证的访问主体进行鉴权，限制访问主体可访问和操作的资源。

统一鉴权模式示意图如图3-19所示，统一鉴权模式过程可以分为初始化过程（集中授权管理）、身份认证过程、访问控制判断过程。其中初始化过程包括步骤1和步骤2，身份认证过程包括步骤3～步骤5，访问控制判断过程包括步骤6～步骤9。

步骤1：策略管理平台用于管理访问控制策略，制定和产生访问控制策略，是访问控制决策的基础。

步骤2：访问控制策略通过策略分发组件推送到策略缓存库。待用户访问客体资源时，策略决策点从策略缓存库取出相应的访问控制策略。

步骤3：访问主体尝试访问客体资源，在访问客体资源前，先需要对用户身份进行认证（可通过打开IAM平台的Portal进行统一身份认证）。

步骤4：访问主体通过各种认证方式对身份进行认证，身份认证可通过IAM平台的统一身份认证中心进行认证。

步骤5：认证通过后返回访问主体身份ID，以及用户采用的认证方式和认证强度等级（认证强度会影响访问主体可以访问客体资源的多少）。

步骤6：策略执行点收到用户访问资源请求。在一个具体的应用程序环境下，策略执行点截获用户发送的访问控制请求，这个访问控制请求的内容和格式根据不同的应用程序而不同。

步骤7：策略执行点发送用户请求至策略决策点。策略执行点将截获的访问控制请求发送给策略决策点，请求它进行访问控制决策。

步骤8：策略决策点将判断授权结果返回给策略执行点。策略决策点在判断授权结果时可以根据访问主体的角色、访问主体的属性、环境的属性、被访问资源的属性信息，以及工作流任务状态共同判断授权结果。

步骤9：根据授权结果访问相应资源。在返回的决策结果中可能是拒绝的，也可能是许可的，还可能是带有相应的职责信息的，如需要进行日志记录等。

2.访问控制列表（ACL）

访问控制列表（Access Control List，ACL）是最早也是最基本的一种访问控制机制。它的原理非常简单：每项信息化资源都配有一个列表，这个列表记录的就是哪些用户可以对这项资源执行CRUD 中的哪些操作。网络中的节点有资源节点和用户节点两大类，其中资源节点提供服务或数据，用户节点访问资源节点所提供的服务与数据。ACL的主要功能就是一方面保护资源节点，阻止非法用户对资源节点的访问；另一方面限制特定的用户节点所能具备的访问权限。当用户节点试图访问某项资源节点时，会首先检查这个列表中是否有关于当前用户的访问权限，从而确定当前用户可否执行相应的操作。

ACL是一种面向资源的访问控制模型，它的机制是围绕“资源”展开的。由于ACL的简单性，使得它几乎不需要任何基础设施就可以完成访问控制。但同时ACL的缺点也是很明显的，由于需要维护大量的访问权限列表，它在性能上有明显的缺陷。另外，对于拥有大量用户与众多资源的应用，管理ACL本身就变成非常繁重的工作。

ACL被广泛地应用于路由器和三层交换机，借助于ACL，可以有效地控制用户对网络的访问，从而最大限度地保障网络安全。以路由器为例，ACL是应用在路由器接口的指令列表，这些指令列表用来告诉路由器哪些数据包可以接收、哪些数据包需要拒绝。ACL使用包过滤技术，在路由器上读取第三层及第四层包头中的信息，如源地址、目的地址、源端口、目的端口等，根据预先定义好的规则对包进行过滤，从而达到访问控制的目的。

ACL不但可以起到控制网络流量、流向的作用，而且在很大程度上起到保护网络设备、服务器的关键作用。作为外网进入企业内网的第一道关卡，路由器上的ACL成为保护内网安全的有效手段。

按照ACL规则功能的不同，ACL被划分为基本ACL、高级ACL、二层ACL、用户自定义ACL和用户ACL这5种类型，每种类型ACL对应的编号范围是不同的。详细的不同规则功能ACL类别情况如表3-8所示。

3.基于角色的访问控制（RBAC）

基于角色的访问控制（Role-Based Access Control，RBAC）是把用户按角色进行归类，通过用户的角色来确定能否针对某项资源进行某些操作。RBAC相对于ACL最大的优势就是它简化了用户与权限的管理，通过对用户进行分类，使得角色与权限关联起来，而用户与权限变成了间接关系。RBAC使得访问控制，特别是对用户的授权管理变得非常简单，也便于维护，因此有广泛的应用。RBAC下的用户权限是以用户角色为载体分配的，如果某一角色下的个别用户需要进行特别的权限定制，如加入一些其他角色的小部分权限或去除当前角色的一些权限，RBAC就无能为力了，因为RBAC对权限的分配是以角色为单位的。

RBAC也是一套成熟的权限模型，其示意图如图3-20所示。在传统权限模型中，直接把权限赋予用户。而在RBAC中，增加了“角色”的概念，首先把权限赋予角色，再把角色赋予用户。这样，由于增加了角色，授权会更加灵活方便。在RBAC中，根据权限的复杂程度，又可分为RBAC0、RBAC1、RBAC2、RBAC3。其中，RBAC0是基础，RBAC1、RBAC2、RBAC3都是以RBAC0为基础的升级。企业可以根据自家应用系统权限的复杂程度，选取适合的权限模型。

1）RBAC0基本模型

RBAC0是基础，很多信息化资源只需基于RBAC0就可以搭建权限模型了。在这个模型中，我们把权限赋予角色，再把角色赋予用户。用户和角色、角色和权限都是多对多的关系，如图3-21所示。用户拥有的权限等于他所有的角色持有权限之和。

如果按照传统权限模型给每个用户赋予权限，则会非常麻烦，并且做不到批量修改用户权限。这时，可以抽象出几个角色，如销售经理、财务经理、市场经理等，然后把权限分配给这些角色，再把角色赋予用户。这样无论是分配权限还是之后的修改权限，只需要修改用户和角色的关系或角色和权限的关系即可，更加灵活方便。此外，如果一个用户有多个角色，如王先生既负责销售部也负责市场部，那么可以给王先生赋予两个角色，即销售经理+市场经理，这样他就拥有这两个角色的所有权限。

2）RBAC1角色分级模型

RBAC1建立在RBAC0基础之上，在角色中引入了等级的概念。简单理解就是，将角色分成几个等级，每个等级权限不同，从而实现更细粒度的权限管理，如图3-22 所示。

基于之前RBAC0的例子，我们发现一个公司的销售经理可能分为几个等级，如除了销售经理，还有销售副经理，而销售副经理只有销售经理的部分权限。这时，可以采用RBAC1的分级模型，把销售经理这个角色分成多个等级，给销售副经理赋予较低的等级即可。

3）RBAC2角色限制模型

RBAC2同样建立在RBAC0基础之上，仅是对用户、角色和权限三者之间增加了一些限制。这些限制可以分成两类，即静态职责分离（Static Separation of Duty，SSD）和动态职责分离（Dynamic Separation of Duty，DSD）。RBAC2角色限制授权模型如图3-23所示。

还是基于之前RBAC0的例子，我们又发现有些角色之间是需要互斥的，如给一个用户分配了销售经理的角色，就不能给他再赋予财务经理的角色了，否则他既可以录入合同又能自己审核合同；又如，有些公司对角色的升级十分看重，一个销售员要想升级到销售经理，必须先升级到销售主管，这时就要采用先决条件限制了。

4）RBAC3统一模型

RBAC3是RBAC1和RBAC2的合集，所以RBAC3既有角色分级，也可以增加各种限制。RBAC3可以解决RBAC0、RBAC1和RBAC2的所有问题。当然，只有在系统对权限要求非常复杂时，才考虑使用此权限模型。

5）基于RBAC的延展模型——用户组

基于RBAC模型，还可以适当延展，使其更适合企业的信息化资源授权访问。例如，增加用户组概念，直接给用户组分配角色，再把用户加入用户组，如图3-24所示。这样用户除了拥有自身的权限，还拥有所属用户组的所有权限。

例如，可以把一个部门看成一个用户组，如销售部、财务部等，再给这个部门直接赋予角色，使部门拥有部门权限，这样这个部门的所有用户都拥有部门权限。用户组的概念可以更方便地给群体用户授权，并且不影响用户本来就拥有的角色权限。

4.基于属性的访问控制（ABAC）

基于属性的访问控制（Attribute-Base Access Control，ABAC）有时也称为PBAC（Policy-Based Access Control）或CBAC（Claims-Based Access Control）。不同于常见的将用户通过某种方式关联到权限的方式，ABAC则是通过动态计算一个或一组属性是否满足某种条件来进行授权判断（可以编写简单的逻辑）。属性通常可分为四类：用户属性（如年龄、地址等）、环境属性（如时间等）、操作属性（如下载等）和对象属性（如数据等，又称为资源属性），所以理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求。用于权限控制的属性分类表如表3-9所示。

图3-25可以直观地表现ABAC访问控制模型的逻辑结构。例如，P5（职级）的员工有OA系统的权限。这是一个简单的ABAC例子，就是通过用户实体的职级这一属性来控制是否有OA系统的访问权限；又如，P5（职级）的研发（职位）员工有公司GitLab（一款项目管理和代码托管平台）的权限，此例子是通过一组用户实体的属性（职级和职位）来控制对操作对象的权限；再如，P5（职级）的研发（职位）员工在公司内网（环境）中可以查看和下载（操作）代码。此例子显然比之前的例子更加复杂，除了判断实体的属性（职级和职位），还判断当前的环境属性和操作属性。

ABAC在理论上能够实现非常灵活的权限控制，几乎能满足所有类型的需求，比较适用于用户数量多并且授权比较复杂的场景。简单的场景也是可以使用ABAC的，但是使用基础的ACL或RBAC也能满足需求。

ABAC的主要应用场景有以下几种：一是在需要根据环境属性和操作属性来动态计算权限时，使用其他授权模型可能不会满足需求。这时就需要使用ABAC了；二是ABAC也适用于企业员工（角色）快速变化的场景，因为ABAC是通过用户的属性来授权的，在新建用户/修改用户属性时会自动更改用户的权限，无须管理员手动更改账户角色；三是在属性的组合比较多，需要更细粒度地划分角色的情况下，RBAC需要建立大量的角色，而ABAC会更加灵活。

总之，ABAC有如下优势和劣势。

ABAC的优势：①集中化管理；②可以按需求实现不同颗粒度的权限控制；③不需要预定义判断逻辑，减轻了权限系统的维护成本，特别是在需求经常变化的系统中。

ABAC的劣势：①定义权限时，不能直观看出用户和对象间的关系；②规则如果稍微复杂一点，或者设计混乱，会给管理者维护和追查带来麻烦；③权限判断需要实时执行，规则过多会导致性能出现问题。

5.基于任务的访问控制（TBAC）

基于任务的访问控制（Task-Based Access Control，TBAC）是一种主动型安全访问控制模型。它从工作流的人物角度建模，可以根据任务和任务状态的不同，对权限进行动态管理。TBAC非常适合于工作流、分布式处理和事务管理系统中的决策制定。在TBAC中，对象的访问权限控制不是静止不变的，而是随着执行任务的上下文环境发生变化的。在分布式系统中存在各种复杂的工作流，对这些信息进行处理需要短暂的授权和控制，传统的访问控制方式难以适应分布式工作流的安全需求，不能保证分布式工作流数据按业务流程的预期方向进行流动，也很难及时准确地进行权限的授予和回收，因此对工作流数据的安全保护可以采用基于TBAC的安全访问控制策略。

TBAC的授权与任务相关，当任务即将执行时，才对用户授权；当任务执行完成时，就撤销用户的权限。这样就可以保证权限只有在需要时才得到，满足最小授权原则。TBAC是积极主动参与访问控制管理的，在完成任务的过程中，TBAC始终监视许可的状态，按照进行中的任务状态确定许可是活动状态还是非活动状态。TBAC访问控制授权模型如图3-26所示。

TBAC的访问控制的最小单元是授权步。授权步表示一个原始授权处理步，是指在一个工作流程中对处理对象的一次处理过程。授权步的概念类似于有纸办公环境下通过签名进行授权的单个行为。在有纸办公环境下，一些人可能被允许获得一定的签名类型，而具体的签名行为又由某个特定个体完成，该特定个体即为该授权的执行委托者，签名也即获得一定许可。

TBAC的授权有五元组（S、O、P、L、AS）构成，其中，S表示主体、O表示课题、P表示许可、L表示生命周期、AS表示授权步。P是AS所激活的权限，而L则是AS的存活期限。在AS被触发时，其委托执行者开始拥有执行者许可集中的权限，同时其L开始倒计时。在生命期中，五元组有效。当生命期终止，即AS被定为无效时，五元组无效，委托执行者所拥有的权限被回收。

TBAC尚有一些问题需要解决，如特权格式问题，系统中有许多类型的资源，且一个任务可以执行另一个任务；任务的多级别定义；多任务中特权的提取、合并和推广等。TBAC中并没有将角色与任务清楚地分离，也不支持角色的层次等级；另外，TBAC并不支持被动访问控制，需要与RBAC结合使用，即基于任务和角色的访问控制T-RBAC。

T-RBAC把任务和角色置于同等重要的地位，它们是两个独立而又相互关联的重要概念。任务是RBAC和TBAC结合的基础。在T-RBAC模型中，先将访问权限分配给任务，再将任务分配给角色，角色通过任务与权限关联，任务是角色和权限交换信息的桥梁。

在T-RBAC中，任务具有权限，角色只有在执行任务时才具有权限，当角色不执行任务时不具有权限；权限的分配和回收是动态进行的，任务根据流程动态到达角色，权限随之赋予角色，当任务完成时，角色的权限也随之收回；角色在工作流中不需要赋予权限。这样不仅使角色的操作、维护和任务的管理变得简单方便，也使得系统变得更为安全。

6.权限风险分析

上面讲述了几种常见的访问控制授权模型，不管是系统信息化资源自身对用户权限进行授权管理，还是由身份管理和访问控制（IAM）平台统一进行管理，都存在相应的管理风险。在初次部署IAM平台进行权限管理和后续持续维护权限模型时，都要考虑到权限分配带来的安全风险。如管理员通常采用RBAC的方法来根据用户访问类似资源的需要，将多个用户捆绑到用户组。虽然采用访问组的做法可减少需要创建和维护的访问数量，但很多企业将过多的用户集中到一个组中，其结果是有些用户被授予权限访问他们不需要的应用程序和服务。在最好的情况下，这只会导致用户访问不够严格。在最坏的情况下，这可能导致不适当的职责分离，从而导致访问控制不合规。

1）影响用户访问权限的因素

在对用户访问权限进行管理时，影响用户访问权限的因素包括以下几个方面。

（1）业务权限。业务权限是指为了保证用户在系统中能够按照规范的业务流程进行系统操作而设置的相应权限。该因素只要防范未经授权非法处理业务、系统处理不正确导致业务无法正常运行等风险。

（2）职责分离。职责分离是指遵循不相容职责相分离的原则，实现合理的组织分工。例如，一个企业的授权、签发、核准、执行、记录工作，不应该由一个人担任。不相容职责是指企业里某些相互关联的职责，如果集中于一个人身上，就会增加发生差错和舞弊的可能性，或者增加发生差错或舞弊以后进行掩饰的可能性。

（3）应用类别。对不同的信息化系统进行分类，并对不同应用的访问权限做一些基本的授权控制。如一些人员，针对某些类别的应用绝对没有访问权限，非财务人员绝对没有财务类应用系统的访问权限。

（4）组织机构。针对不同的组织机构部门，可以分配不同的应用访问策略，再结合不同的访问控制授权模型对用户的访问权限进行控制，这样也可以避免用户部门调整后，控制策略没有相应的调整。

（5）授权策略。根据实际的访问情况进行访问授权策略的制定，策略制定可以根据上面讲到的不同的授权模型进行，但策略设计要合理、不违背基本原则，如权限只增不减、不再负责的业务权限未删除、人员离职权限未收回等。

（6）策略审批。策略下发后要有相应的系统管理员对下发的策略进行审核的机制，审核人员审核通过后策略才能生效，审核人员和策略下发人员不能是同一个管理员，遵循职责分离的原则。

2）实施过程原则

在部署实施IAM以及进行统一授权管理时，跟进本企业实际情况选择合适的访问控制授权模型。实施过程建议采用以下几点，本着“统筹规划”“分步实施”的原则，减少统一权限管理不当带来的用户体验差和安全风险。

（1）统筹规划。在统一权限管理规划时，信息技术部门需要和业务部门进行统筹规划，双方达成共识，企业统一权限管理做到哪个层级、分几期进行等。避免后期在实施过程中产生分歧而影响统一权限管理的整体效果和进展。

（2）互通有无。在统一权限管理实施时，业务部门也要参与到日常的项目进展汇报、沟通中来，清晰了解实施情况及进展，“多沟通，早准备”，化解项目中沟通不畅造成的风险。

（3）逐一击破。在统一权限管理实施时，企业要针对每个业务系统制定实施方案，提前预见可能发生的风险，在实施过程中一个系统一个系统地逐一实施，最大限度地降低风险，提升整体实施效果。

7.权限审阅

策略审阅和审批制度是做好权限管理的重要因素，故不仅仅是权限分配的过程中需要考虑到各种权限风险因素和相应的管理政策，当部署IAM时，还要制定相应的定期访问控制审计的政策。随着用户角色的转变，这些用户组的访问权限也应该改变。此外，当用户职位改变时，需要确保撤销所有先前的访问权限。权限审阅流程图如图3-27所示。

（1）权限管理员和权限审核员以及相关业务人员共同参与制订权限审阅计划。针对信息化系统的访问控制授权，审阅计划的内容应包括目标信息化系统、用户范围、权限审阅内容、审核人、执行时间和频率等。

（2）权限审阅计划制订完成后，信息化系统根据审阅计划生成定时任务，或立即执行，或定时执行。

（3）当系统收到定时任务或立即执行的策略时，将生成审阅策略分发给相关审核人。

（4）工作流执行到相关审核人时，审核人查看详细的权限分配内容申请，并对申请进行审核。

（5）审核人根据授权管理制度和实际情况，认为授权申请比较合理，审核通过，反之，审核不通过，返回申请人重新修改。

（6）审核通过后信息化系统自动修复或调整信息化系统权限。

（7）审核流程结束后生成权限审核报告，从而便于权限变更查看和追溯。 9F2JCd2kSUFrcfjScbmwUs59E0uxWR4dIFLaEbNj4NytPmQH7zdLY4LAGojirVrl