访问申请与权限开通流程图
访问申请流程图：基于角色的申请、直属主管与系统负责人审批、职责分离检查、按最小权限开通，以及定期重新认证。
什么是访问申请与权限开通流程
访问申请流程，是让员工拿到工作所需的权限，同时又不让组织失去对“谁能做什么”的掌握。它从申请一个已定义的角色开始，而不是一份逐项罗列权限的清单；经过对申请人负责的人和对系统负责的人的审批；最后落到一条记入台账、并带有下次复核日期的权限记录上。
最常被跳过的步骤，恰恰是日后变成审计发现的那些。职责分离检查可以阻止同一个人持有两个本不该放在一起的角色——例如创建供应商，又为这家供应商付款。单独的安全评审，让管理员权限和敏感数据权限不必与一份只读报表走同一条审批路径。而重新认证是权限台账得以保持真实的唯一原因：没有计划内的复核，每当有人换团队，权限就会累积一层，而且从来不会被收回。
本模板把从申请到重新认证的完整流程画在五条泳道上：申请人、直属主管、系统或数据负责人、IT 服务台和安全团队。它包含各团队争论最多的两个分支点——当申请的角色与本人已有的权限发生冲突时会怎样，以及哪些申请需要在开通前经过安全评审。它以一次计划内复核收尾，复核要么确认该权限继续有效，要么将其收回。整体结构遵循 ISO/IEC 27001:2022 附录 A 中关于访问控制（A.5.15）、身份管理（A.5.16）和访问权限（A.5.18）的控制项所确立的模式。
本流程图涵盖的内容
本模板包含
- 申请人泳道中的申请：发起访问申请，再从访问目录中选择一个已定义的角色，写明业务理由；权限如属临时性质，还要写明结束日期。
- 在任何技术检查之前的两道审批关口：直属主管批准或驳回，然后由系统或数据负责人审阅该角色实际授予哪些权限，再批准或驳回。两条驳回分支都汇入同一个节点“申请已驳回并关闭”。
- IT 服务台泳道中的“是否存在职责分离冲突？”决策，冲突分支会把申请退回系统负责人，由其调整权限范围或增加一项补偿性控制，然后重新检查，而不是直接放行。
- “是否属于特权或敏感权限？”决策，把管理员权限和高风险申请转到单独的安全审批，普通申请则直接进入权限开通。
- 开通与记录：按最小权限原则开通，向申请人确认权限已生效，请申请人确认接受使用规范，并把该权限登记到访问权限台账中。
- 最后一列中的重新认证回路：安全团队启动一次计划内复核，系统负责人判断该权限是否仍有必要，“否”分支在目标系统中收回权限并更新台账。
何时使用本模板
- 你们要为 ISO 27001、SOC 2 或一次内部审计编写或复审访问控制程序，需要一份共同认可的图，说明谁审批什么、记录什么。
- 你们要在服务台或身份治理工具中配置申请流程，让工具落实一套事先商定的流程，而不是在实施过程中现编一套。
- 你们要回答审计员或客户安全问卷，说明权限是如何申请、审批、开通和复核的。
- 你们要向新的审批人做说明，尤其是直属主管和系统负责人——他们需要知道自己签字的到底是什么，以及把申请搁置会发生什么。
- 一次复核翻出了一批谁都说不清、也对不上任何审批记录的权限，你们要着手处理权限累积的问题。
运作方式
写下你们真实的审批人
把五条泳道改成你们实际拥有的角色。在规模较小的组织里，系统负责人和安全评审人往往是同一个人；把这两条泳道合并，而不是画一次根本不会发生的审批。每个决策者一条泳道，而不是每个人一条，这样有人换岗时图还能继续用。
界定什么算特权或敏感权限
“是否属于特权或敏感权限？”这个决策，只有把判定标准写在它旁边才起作用。常见的触发条件包括管理员和 root 账号、服务账号、个人数据或财务数据的访问权限，以及任何能改动生产环境的权限。门槛要设在只有少数申请会触发安全分支的位置，否则这一步就会沦为盖章。
把职责分离规则写下来
列出任何一个人都不得同时持有的组合——例如创建供应商与批准付款，或编写代码与把代码发布到生产环境。没有这份矩阵，冲突检查就是做样子。同时决定：当冲突无法避免时，由谁批准补偿性控制，并把它记录在这条权限上。
决定访问权限台账放在哪里
把登记这一步指向你们真正会维护的系统——身份治理工具、你们的 ITSM 平台，或一份受控的电子表格。要确保收回权限的分支会更新同一条记录，否则台账会慢慢变成一份“曾经授予过的权限”清单，而不是“当前实际存在的权限”清单。
确定重新认证的周期和它的负责人
把笼统的“计划内复核”换成你们自己的频率和触发条件——例如特权账号每季度一次、标准角色每年一次，另加岗位变动时的临时复核。写明谁去催办复核人，以及复核期限过了会怎样；没有负责人的复核，正是那种会悄悄停摆的步骤。
让这张图获得批准，并只保留一个现行版本
把图分享给图中列名的审批人，取得他们的批准记录，并从访问控制策略中链接到已批准的版本。当图表处于版本控制之下且带有已记录的批准时，大家实际遵循的流程和你们拿给审计员看的流程，就是同一个。
常见问题
什么是访问申请流程？
它是一条已定义的路径：一项系统权限申请，从有人提出，到被授予、被记录、并在日后被复核。一个完整的流程有四个部分：一份写明已定义角色和业务理由的申请；由对该员工负责的人和对该系统负责的人分别审批；由持有管理权限的人完成开通；以及一条带有复核日期的权限记录。申请和开通被刻意拆成由不同的人完成的两个步骤，这样就没有人能给自己开权限。
访问申请应该由谁审批？
两位审批人足以覆盖大多数情况。直属主管确认这个人工作上确实需要这项权限，这是关于申请人的问题。系统或数据负责人确认这个角色实际授予哪些权限、这个人是否应当持有，这是关于系统的问题。来自安全团队的第三道审批，只有在特权或敏感权限的场景下才值得加上——本模板正是这样分流的。增加审批人很少能改善决策，却一定会拉长等待时间，而等待时间正是共享密码之类非正式变通做法的来源。
访问管理中的职责分离检查是什么？
它检验的是：申请的角色加上此人已有的权限，会不会让一个人在没有任何独立环节的情况下，从头到尾完成一笔敏感交易。常见的例子是创建供应商并批准其付款，或者编写代码并把它发布到生产环境。这项检查需要一份事先商定的冲突组合清单作为比对依据。当冲突无法避免时——例如在一个小团队里——通常的做法是采用一项有文档记录的补偿性控制，一般是由另一个人事后复核，并记录在这条权限上。
用户权限应该多久重新认证一次？
频率应当由风险决定。一种常见做法是：特权账号和管理员账号每季度一次，标准业务角色每年一次，并且每当有人变更岗位或团队时立即进行一次计划外复核。ISO/IEC 27001:2022 控制项 A.5.18 要求定期复核访问权限，但没有规定具体间隔，频率需要由你们自己给出理由。另外要注意，流程图记录的是意图，而不是合规本身：审计员索要的证据，是这个流程产出的审批记录和权限台账。