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