用户访问权限回收流程图（权限注销）

什么是用户访问权限回收流程图（权限注销）流程

用户访问权限回收，也叫权限注销或权限撤销，就是把一个人已经不再需要的访问权限收回来，并且能够证明它确实被收回了。它从一个触发事件开始——可能是一次离职，一次岗位变动，一份合同或一项委托结束，也可能是一次权限审查查出了谁也说不清理由的权限——一直走到一份记录，显示每一个账号、每一项权限都被处理过。它对时间的敏感程度是多数行政流程没有的：风险窗口在触发发生的那一刻打开，一直开着，直到最后一个会话被关闭。

这不是整个离职流程。工作交接、离职面谈、资产归还与最后一笔工资属于员工离职流程，那是一项由人力资源负责、范围更宽的协同工作。本流程是其中的权限那一半，而且它也会为根本没有要走的人跑起来——所以那条泳道按触发来源命名，而不是按一次离职命名。它也不是授权那一侧：权限如何申请、如何说明理由、如何审批、如何开通，是访问申请流程的事。回收从这两者停下的地方开始，一条流程覆盖全部四种触发，而不是只为离职写得规整、对其他情形临时凑合。

模板把流程铺在五条泳道上——触发来源（人力资源或经理）、IT 服务台、系统负责人、安全与审计——横跨从触发到证据与收尾的六个阶段。它包含决定撤销是立即执行还是在生效日执行的那条分支，共享账号、服务账号与特权账号这类不能一关了事的情形的处理，停用还是删除的判断，以及最后一步核对：把实际回收掉的，与开头整理出的那份清单对上。它的形状遵循 ISO/IEC 27001:2022 附录 A 控制项 A.5.18 所描述的访问生命周期中回收的那一半——该控制项要求在雇佣关系或合作关系终止或变更时，移除或调整访问权限。

本流程图涵盖的内容

本模板包含

• 四个入口，一条流程：触发来源泳道中的“触发类型？”判断，把离职或合同到期、岗位变动、权限审查发现送上同一条回收路径，因此什么都不取决于这张工单碰巧是不是人力资源开的。
• IT 服务台泳道中的“是否需要立即撤销？”判断：立即分支针对解雇与特权账号，在一小时之内切断全部访问权限；计划分支把回收安排在生效日。两条分支在同一个梳理步骤重新汇合。
• 一个独立的梳理步骤，在关掉任何东西之前先整理出完整的账号与权限清单，节点备注里点名了人们最常漏掉的来源：本地账号、服务账号与共享账号、VPN 与远程访问、云控制台与数据库控制台、用信用卡买下的第三方 SaaS，以及楼宇门禁。
• 由系统负责人负责的“是否共享账号或特权账号？”判断，把共享账号、服务账号与特权账号转给安全去轮换凭据与密钥——因为这类账号一旦被停用，就会弄坏依赖它们的东西。
• 撤销那一列中的“停用还是删除账号？”判断，两条分支都在系统负责人于各目标系统中撤销权限处重新汇合。
• 数据与许可证按避免文件失去归属的次序处理：先移交邮箱与文件所有权，再回收许可证并更新台账，然后由安全留存撤销证据，最后由审计泳道的“是否还有访问权限仍然有效？”核对，把发现的缺口退回梳理步骤，之后才签字收尾。

何时使用本模板

• 你们正在编写或复核一份权限注销程序，需要把权限相关的步骤从更宽的离职清单中单独拎出来，并为每一步指定一位负责人。
• 权限审查一次又一次翻出已离职、已换团队或合同已结束的人仍然有效的账号，你们需要说明回收发生在流程的哪个位置、由谁确认。
• 你们正在身份平台或服务台工具中配置入职、调岗、离职的自动化，希望流程在被写成工作流规则之前先被议定下来。
• 你们的环境里外包与第三方人员很多，主要触发是合同到期日而不是人力资源系统的数据推送，根本没有离职记录可以依托。
• 你们要回答审计师或客户安全问卷中的问题：雇佣关系终止时访问权限是如何回收的，有什么证据表明它确实发生过。

运作方式

1. 写清你们真实的触发来源

   图里有四种触发：离职、合同到期、岗位变动与权限审查发现。写下每一种的权威来源是哪个系统或哪个人，例如员工看人力资源系统，供应商与外包人员看合同台账，审查发现看审查结果。如果今天某一种触发没有负责人，那就是最值得先补上的缺口——没有人会去启动的流程，是没法被衡量的。

2. 把立即撤销的规则写下来

   “是否需要立即撤销？”这个判断，只有当判定标准就摆在旁边时才管用。常见的触发是解雇、涉嫌违规，以及任何持有管理员、生产环境或付款审批权限的人。加上你们自己的目标时限，并写明非工作时间由谁可以发起。遇到解雇时，撤销通常与谈话本身对时，所以这条分支讲的既是速度，也是次序。

3. 把你们的系统台账挂到梳理步骤上

   把通用的账号清单换成你们真正在维护的那份台账，并标出哪些系统在单点登录后面、哪些不在。身份平台之外的一切，正是被漏掉的权限藏身之处：本地管理员账号、数据库登录、SSH 密钥、API 令牌，以及某个团队用信用卡买下的工具。请离职者的经理把 IT 并不管理的东西一个个说出来。

4. 在需要用到之前就定好停用还是删除

   把停用设为默认，并定义什么情况下允许删除，例如过了规定的留存期，或者合同到期而协议要求如此。记下这个决定由谁来做。删得太早，会毁掉邮件数据、文件所有权，以及核对步骤和日后任何调查所依赖的操作历史。

5. 保持数据与许可证步骤的次序

   先移交邮箱与文件所有权，再回收许可证。两者一旦调换，共享文件与邮箱就会失去归属，事后再找回来很慢。如果设置了邮件转发或代理人，就在同一步里给它指定一位具名负责人和一个结束日期，否则这个临时安排会悄悄变成永久的。

6. 议定什么算证据，以及由谁核对

   定下一条撤销记录必须包含什么——通常是系统、动作、时间戳和执行人——以及它存放在哪里。然后指定谁来跑“是否还有访问权限仍然有效？”这项检查，以及对着什么核对：只有对着开头那份账号清单核对、而不是对着记忆核对，才抓得住遗漏。把批准过的图与你们的访问控制政策一起发布，让大家实际遵循的流程，和你们拿给审计师看的流程，是同一条。

常见问题

什么是用户访问权限回收流程？

它是把一个人的访问权限收回来所走的那条已定义路径，从触发一直到经过确认并留有证据的收尾。一条完整的流程有五个部分：一个有具名来源的触发；一个关于权限必须多快消失的判断；对这个人持有的每一个账号与每一项权限的梳理；在每个系统中的撤销，且数据与许可证的后果都已处理；以及一次核对，显示没有任何东西被留着仍然有效。触发比多数团队以为的要宽。除了离职，流程还应该在岗位或团队变动时、在合同或委托结束时、在任何一次权限审查发现时跑起来——正是这些路径，制造出了事后谁也解释不清的权限。

有人离职时，访问权限应该多快被回收？

标准规定的是要求，不是钟点。ISO/IEC 27001:2022 控制项 A.5.18 要求在雇佣关系终止或变更时移除或调整访问权限，但没有规定时限，因此目标由你们自己设定并说明理由。常见的做法是：有计划的离职在最后工作日结束时回收；解雇或任何持有特权权限的人则立即回收，并与谈话对时。无论你们选哪一种，都把它写进流程，衡量从触发到最后一次撤销的实际耗时，并把这两者之间的差距当作值得上报的那个数字。

我们应该停用还是删除账号？

停用是更安全的默认，也是多数组织首先会做的。它关闭账号、结束活动会话、阻止登录，同时保留邮箱内容、文件所有权、组成员关系，以及一次调查或日后一次权限审查可能需要的操作历史。删除属于规定留存期结束时，或者合同到期而协议或数据保护承诺要求如此时。无论选哪一种，结束活动会话与吊销令牌的重要性都不亚于账号状态本身：一个已停用但仍带着活动会话或有效刷新令牌的账号，在那个会话过期之前仍然拥有访问权限。

共享账号、服务账号与特权账号的权限该怎么回收？

共享账号或服务账号没法靠停用来注销，因为别的人和别的系统都依赖它。回收动作是轮换凭据：改掉密码或密钥，把这个人从保管它的密码库或组里移除，吊销他创建的 API 令牌、SSH 密钥与个人访问令牌，并结束所有活动会话。特权个人账号在常规停用之外，还需要同样的会话与令牌处理。模板把这一情形放在由安全负责的独立分支上，因为它是最常被漏掉的那一种，而一旦被漏掉，波及面也最广。

这条流程应该产出什么证据？

最少是每次回收一张工单或一条记录，显示触发及其日期、整理出的账号与权限清单、在每个系统中采取的动作及其时间戳和执行人，以及核对检查的结果。这份记录正是审计师抽查的对象，也正是让你们能用一个日期而不是一段描述去回答安全问卷的东西。这里有必要把话说清楚：流程图做的是记录预期的流程以及每一步归谁所有，而合规的证据，是这条流程真正跑起来时产生的那些记录。