用户访问权限回收流程图（权限注销）
用户访问权限回收流程图：离职与岗位变动触发、立即撤销分支、共享与特权账号处理、许可证回收，以及可供审计的证据与核对。
运作方式
写清你们真实的触发来源
图里有四种触发：离职、合同到期、岗位变动与权限审查发现。写下每一种的权威来源是哪个系统或哪个人，例如员工看人力资源系统，供应商与外包人员看合同台账，审查发现看审查结果。如果今天某一种触发没有负责人，那就是最值得先补上的缺口——没有人会去启动的流程，是没法被衡量的。
把立即撤销的规则写下来
“是否需要立即撤销？”这个判断，只有当判定标准就摆在旁边时才管用。常见的触发是解雇、涉嫌违规，以及任何持有管理员、生产环境或付款审批权限的人。加上你们自己的目标时限，并写明非工作时间由谁可以发起。遇到解雇时，撤销通常与谈话本身对时，所以这条分支讲的既是速度，也是次序。
把你们的系统台账挂到梳理步骤上
把通用的账号清单换成你们真正在维护的那份台账，并标出哪些系统在单点登录后面、哪些不在。身份平台之外的一切，正是被漏掉的权限藏身之处：本地管理员账号、数据库登录、SSH 密钥、API 令牌，以及某个团队用信用卡买下的工具。请离职者的经理把 IT 并不管理的东西一个个说出来。
在需要用到之前就定好停用还是删除
把停用设为默认，并定义什么情况下允许删除，例如过了规定的留存期，或者合同到期而协议要求如此。记下这个决定由谁来做。删得太早，会毁掉邮件数据、文件所有权，以及核对步骤和日后任何调查所依赖的操作历史。
保持数据与许可证步骤的次序
先移交邮箱与文件所有权，再回收许可证。两者一旦调换，共享文件与邮箱就会失去归属，事后再找回来很慢。如果设置了邮件转发或代理人，就在同一步里给它指定一位具名负责人和一个结束日期，否则这个临时安排会悄悄变成永久的。
议定什么算证据，以及由谁核对
定下一条撤销记录必须包含什么——通常是系统、动作、时间戳和执行人——以及它存放在哪里。然后指定谁来跑“是否还有访问权限仍然有效？”这项检查，以及对着什么核对：只有对着开头那份账号清单核对、而不是对着记忆核对，才抓得住遗漏。把批准过的图与你们的访问控制政策一起发布，让大家实际遵循的流程，和你们拿给审计师看的流程，是同一条。
常见问题
什么是用户访问权限回收流程？
它是把一个人的访问权限收回来所走的那条已定义路径，从触发一直到经过确认并留有证据的收尾。一条完整的流程有五个部分：一个有具名来源的触发；一个关于权限必须多快消失的判断；对这个人持有的每一个账号与每一项权限的梳理；在每个系统中的撤销，且数据与许可证的后果都已处理；以及一次核对，显示没有任何东西被留着仍然有效。触发比多数团队以为的要宽。除了离职，流程还应该在岗位或团队变动时、在合同或委托结束时、在任何一次权限审查发现时跑起来——正是这些路径，制造出了事后谁也解释不清的权限。
有人离职时，访问权限应该多快被回收？
标准规定的是要求，不是钟点。ISO/IEC 27001:2022 控制项 A.5.18 要求在雇佣关系终止或变更时移除或调整访问权限，但没有规定时限，因此目标由你们自己设定并说明理由。常见的做法是：有计划的离职在最后工作日结束时回收；解雇或任何持有特权权限的人则立即回收，并与谈话对时。无论你们选哪一种，都把它写进流程，衡量从触发到最后一次撤销的实际耗时，并把这两者之间的差距当作值得上报的那个数字。
我们应该停用还是删除账号？
停用是更安全的默认，也是多数组织首先会做的。它关闭账号、结束活动会话、阻止登录，同时保留邮箱内容、文件所有权、组成员关系，以及一次调查或日后一次权限审查可能需要的操作历史。删除属于规定留存期结束时，或者合同到期而协议或数据保护承诺要求如此时。无论选哪一种，结束活动会话与吊销令牌的重要性都不亚于账号状态本身：一个已停用但仍带着活动会话或有效刷新令牌的账号，在那个会话过期之前仍然拥有访问权限。
共享账号、服务账号与特权账号的权限该怎么回收？
共享账号或服务账号没法靠停用来注销，因为别的人和别的系统都依赖它。回收动作是轮换凭据：改掉密码或密钥，把这个人从保管它的密码库或组里移除，吊销他创建的 API 令牌、SSH 密钥与个人访问令牌，并结束所有活动会话。特权个人账号在常规停用之外，还需要同样的会话与令牌处理。模板把这一情形放在由安全负责的独立分支上，因为它是最常被漏掉的那一种，而一旦被漏掉，波及面也最广。
这条流程应该产出什么证据？
最少是每次回收一张工单或一条记录，显示触发及其日期、整理出的账号与权限清单、在每个系统中采取的动作及其时间戳和执行人，以及核对检查的结果。这份记录正是审计师抽查的对象，也正是让你们能用一个日期而不是一段描述去回答安全问卷的东西。这里有必要把话说清楚：流程图做的是记录预期的流程以及每一步归谁所有，而合规的证据，是这条流程真正跑起来时产生的那些记录。