员工离职权限清理清单：身份下线核查指南

员工离职后的权限清理，往往是身份与访问管理（IAM）中最容易被忽视、也最容易出事的环节。一份清晰的离职下线清单，能帮IT和安全团队确认每个应用里该禁用什么、该撤销什么、该转移什么、该轮换什么，以及要留下哪些证据。

为什么离职权限清理需要“核查”而非“操作”

大多数团队并不缺离职流程，缺的是验证。账号禁用按钮按下去，不代表访问真的断了：应用里可能还有活跃的OAuth令牌，共享账号的密码可能从未改过，离职员工的邮箱可能还绑着第三方服务的找回入口。

原始素材把这件事定位为“核查清单”而非“操作手册”，这个视角很关键。操作关注的是“我做了什么”，核查关注的是“我能证明什么”。在审计和事故复盘场景里，后者才是真正有价值的。

清单的四个动作维度：禁用、撤销、转移、轮换

这套框架把每个应用的处理动作拆成四类，覆盖了访问残留的主要形态。

禁用（Disable）

针对以个人身份直接登录的账号。禁用账号是第一步，但要注意两点：一是禁用不等于删除，保留账号便于审计追溯；二是要确认禁用后会话是否立即失效，部分系统允许已登录会话继续存活数小时。

撤销（Revoke）

针对授权类访问，包括OAuth应用授权、API密钥、个人访问令牌、SSH公钥、设备信任状态等。这类凭证往往在账号禁用后依然有效，是清理中最容易被漏掉的部分。清单应要求逐应用确认：该员工授过哪些第三方应用？发放过哪些长期令牌？

OAuth 令牌是第三方应用访问用户资源的授权凭证。当员工授权某个应用（如日历同步工具、代码分析服务）访问其账号数据时，应用会获得一个长期有效的令牌，通常独立于用户密码或登录会话。即使账号被禁用，已颁发的令牌在过期前仍可能有效，因此必须在每个应用中逐一检查并撤销。API 密钥和个人访问令牌同理，它们往往被硬编码在脚本或配置中，离职员工可能仍能通过它们访问系统。SSH 公钥和设备信任状态则关联到基础设施访问，也应纳入撤销范围。

转移（Transfer）

针对数据所有权。离职员工名下的文档、邮箱、日历、代码仓库、自动化脚本、共享邮箱的委派权限，需要明确转移给谁。素材强调这一项要写进清单，因为“账号还在但数据跟着走”是常见的事故来源。

数据所有权转移是离职清理中容易遗漏的环节。员工个人账号下可能存有业务文档、邮箱、日历、代码仓库、自动化脚本等，这些数据若未转移，会随账号禁用而无法访问。共享邮箱的委派权限也需要重新分配，否则可能导致业务中断。明确转移对象并记录在清单中，既能保障业务连续性，也能避免数据丢失或成为“孤儿数据”。

轮换（Rotate）

针对共享凭证。凡是离职员工接触过的共享密码、服务账号密钥、团队保管库中的凭据，都应轮换。共享账号的密码不轮换，等于离职员工的访问从未真正终止。

共享凭证轮换是确保离职员工访问彻底终止的关键。共享密码、服务账号密钥、团队保管库中的凭据，若离职员工曾接触过，都必须立即轮换。否则，即使个人账号被禁用，员工仍可通过共享凭证访问系统。轮换应记录在清单中，包括轮换时间、执行人和验证结果，以形成可审计的证据链。

逐应用核查：清单应覆盖的字段

一份可执行的清单，每个应用至少记录以下信息：应用名称与负责人、账号类型（个人/共享/服务）、禁用状态与时间戳、已撤销的授权与令牌、数据转移去向、需轮换的凭证及完成时间、截图或系统日志等证据链接。

字段看似繁琐，但它把“清理完成”从口头确认变成了可核验的状态。对安全团队而言，这份表格本身就是审计材料；对IT运维而言，它是交接时的责任边界。

证据留存：清单的另一半价值

素材特别提到“要保留哪些证据”，这一点值得展开。常见的证据包括：账号禁用操作的系统日志、授权撤销的截图、数据转移的确认邮件、凭证轮换的记录。

证据的意义不只是应付审计。当出现“离职员工仍能访问内部系统”的告警时，有证据的团队可以快速定位是哪个环节遗漏，而不是从头排查。建议把证据链接直接嵌入清单条目，形成“动作—证据”的对应关系。

落地建议：把清单变成流程

这套清单要真正生效，需要绑定到离职流程的触发点上，而不是等人想起来再执行。可以把它做成离职工单的必填子项，由HR发起、IT执行、安全复核，三方在清单上留痕。

对于应用数量多的组织，建议按风险分级：核心系统（代码仓库、云平台、财务系统、邮箱）逐项核查并留存证据；低风险应用可批量处理，但同样要记录完成状态。定期抽样复核已完成的下线记录，能发现流程中的系统性遗漏。

离职权限清理不是一次性的技术操作，而是一套可验证、可追溯的核查机制。清单的价值，正在于把“应该没人能进来了”变成“有证据表明没人能进来了”。