离职账号停用的关键，是把“人已离职”这个事实转成一条可执行、可核验的处置流程：先确认离职生效时间并触发停用，再按账号清单逐项停用或回收，随后核验登录、令牌与授权，最后留存记录并定期复查。本文按触发准备、执行步骤、角色分工、完整示例和完成检查五部分展开，适用于企业身份源、单点登录、研发平台及第三方SaaS等账号的停用场景。
要点总览（TL;DR）
- 停用前先定触发时点：敏感岗位按离职生效即时停用，普通岗位按最后工作日结束时停用，交接周期长的岗位按交接完成后停用并设最晚期限。
- 账号清单按入职开通记录反向核对，覆盖身份源主账号、单点登录、研发平台、代码仓库、CI/CD、云资源、邮件与即时通讯及第三方SaaS。
- 执行顺序为创建停用工单、停用身份源主账号并观察同步、手工处理未接入统一身份的系统、转移共享与服务账号归属、清理会话与令牌、处置异常。
- 人事或直属负责人负责触发，IT或系统管理员负责执行与记录，系统负责人确认本系统停用与归属转移，安全或审计角色抽查核验。
- 关闭工单前逐项核对登录失败、令牌密钥失效、授权与数据已回收、记录齐全，并建立周期性抽查补停机制。
停用前先定好触发时点与账号清单
停用工作的第一步是确定“什么时候开始停”和“要停哪些账号”。这两个问题没有统一答案，需要结合岗位敏感度、交接安排和系统依赖关系来定。准备阶段的产出物是一份离职账号停用清单和一条明确的触发规则，后续执行和核验都以它为依据。
三种停用时点口径及适用条件
离职生效时间与停用时点之间通常有三种对应关系，选择哪一种取决于岗位和交接情况：
- 离职生效即时停用：离职手续办结或生效时间一到，立即停用全部账号。适用于掌握核心权限、接触敏感数据或存在较高风险的岗位。代价是交接期间原岗位人员无法再登录系统，需要提前把交接材料准备好。
- 最后工作日结束时停用：以最后工作日下班时间为停用时点，当天仍可正常办公和完成交接。适用于大多数普通岗位，兼顾交接连续性和账号安全。
- 交接完成后停用：以交接确认完成为前提再停用，适合交接周期较长、依赖关系复杂的岗位。采用这种口径时，需要设定一个最晚停用期限，避免交接拖延导致账号长期可用。
无论选择哪种口径，都应在离职流程中写明停用时点，并由触发人确认，避免执行人凭印象判断。
账号清单覆盖哪些系统
账号清单要覆盖离职人员可能拥有的全部账号，常见类别包括：身份源主账号（企业目录账号）、单点登录、研发平台、代码仓库、CI/CD流水线、云资源控制台、邮件与即时通讯、第三方SaaS服务。清单不完整是停用遗漏的主要原因，建议按“入职时开通过什么”反向核对，而不是只凭记忆列举。
清单建议包含以下字段，便于执行和追溯：
| 字段 | 填写内容示例 | 作用 |
|---|---|---|
| 账号标识 | 登录名、邮箱或工号 | 准确定位到具体账号 |
| 所属系统 | 目录服务、代码仓库、云平台 | 明确停用入口 |
| 账号类型 | 个人账号、共享账号、服务账号 | 决定停用方式 |
| 负责人 | 系统管理员或业务负责人 | 明确谁执行、谁确认 |
| 停用方式 | 禁用、删除、改密、回收密钥 | 统一操作口径 |
| 依赖关系 | 被哪些任务、服务或人员使用 | 识别停用前需先处理的事项 |
触发人与执行人的分工
触发人一般由人事或直属负责人担任，负责在离职流程中提供离职人员、生效时间和交接状态，并发出停用信号。执行人由IT或系统管理员担任，负责按清单逐项停用、处理同步异常并留存记录。两者职责分开，可以避免“以为对方会处理”的遗漏。准备阶段结束时，应形成一份经触发人确认的清单，作为执行依据。
按顺序执行停用的操作步骤
执行阶段的目标是把清单上的每一项落到“已停用、已核验”的状态。建议按以下顺序推进，每一步都明确输入、动作、输出和完成标志。
第一步：接收离职通知并创建停用工单
输入是离职流程中的离职人员信息、生效时间和涉及系统范围。动作是创建停用工单，把离职人员、停用时点、账号清单和负责人记录在案。输出是一张可跟踪的工单。完成标志是工单已创建且触发人、执行人明确。
第二步：停用身份源主账号并观察同步
输入是身份源中的主账号。动作是在企业目录或统一身份源中禁用该账号，然后观察下游系统的同步结果。输出是主账号已禁用、同步状态已记录。完成标志是主账号无法登录，且已确认哪些下游系统完成了自动同步、哪些没有。同步存在时延时，应记录观察时间点，避免把“尚未同步”误判为“同步失败”。
第三步：逐个处理未接入统一身份的系统
输入是清单中未纳入统一身份管理的系统。动作是逐个登录管理后台，执行禁用、删除或改密，并回收该账号持有的令牌、API密钥和访问凭证。输出是每个系统的停用记录。完成标志是清单上每个系统都标注了停用方式和执行时间。改密适用于账号需要保留但不能再被离职人员使用的场景，例如交接期间仍需保留的公共邮箱。
第四步：处理共享账号、服务账号与代管账号
输入是清单中标记为共享、服务或代管的账号。动作是先确认这些账号的实际使用者和依赖方，再把归属转移给接替人员或改为由团队统一管理，必要时更换凭据。输出是归属变更记录。完成标志是每个共享或服务账号都有明确的新负责人，且原离职人员不再持有凭据。
第五步：检查会话、登录态与已授权设备
输入是已停用的账号。动作是检查是否存在未过期的登录会话、已授权的移动设备或长期有效的访问令牌，并主动使其失效。输出是会话与设备清理记录。完成标志是已确认没有残留的有效登录态。
第六步：处置异常情况
执行中常见三类异常，处理方式如下：
- 同步失败：记录失败的系统与报错信息，转为手工停用，并在工单中标注原因，便于后续排查集成问题。
- 账号不存在：核对账号标识是否填写有误，或该账号是否已被其他流程停用，确认后在清单中注明，避免重复处理。
- 仍有任务在运行的账号：先确认任务的归属和影响，把任务迁移到接替人员的账号或服务账号后再停用，避免中断业务；无法立即迁移的，设定明确的处理期限并记录风险。
角色分工与交付物对照
流程能否落地，取决于每个角色是否清楚自己交付什么。下表把常见角色、职责和交付物对应起来，企业可根据自身组织调整角色名称，但职责边界建议保持清晰。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 人事/直属负责人 | 提供离职人员信息与生效时间，确认交接完成情况，触发停用 | 离职通知、停用触发记录 |
| IT或系统管理员 | 按清单执行停用，处理同步异常，回收令牌与密钥，留存操作记录 | 停用工单、逐系统停用记录 |
| 系统负责人/业务负责人 | 确认本系统账号已停用，完成数据与任务归属转移 | 系统确认记录、归属转移说明 |
| 安全或审计角色 | 抽查停用结果与记录完整性，跟踪遗漏项补停 | 核验结果、抽查报告 |
分工确定后，建议把停用工单、账号清单和核验记录放在同一处管理，让触发、执行、确认三个环节共享同一份状态。在ONES中，这类处置可以按工作项流转：离职事件建为工作项，账号清单作为子项或检查项逐条勾选，停用记录与核验结论以文档形式关联，形成可追溯的处置链路。这样做的价值在于，后续抽查时能直接看到每个账号的停用时间、执行人和核验结果，而不必在多个系统之间翻找。
一个完整的停用示例
以下示例为演示情景，用于说明流程如何走通，不代表任何真实企业环境。
背景：一名研发人员提出离职，最后工作日为周五，涉及目录账号、单点登录、代码仓库、CI/CD流水线和云资源控制台。该岗位接触生产环境，按敏感岗位口径采用最后工作日结束时停用。
时间线
- 周一：人事在离职流程中确认生效时间，触发人发出停用通知。IT创建停用工单，附上账号清单，标注代码仓库和云平台未接入统一身份，需要手工处理。
- 周二至周四：直属负责人安排交接，把代码仓库中的个人分支合并或归档，CI/CD中由个人账号触发的流水线改为团队服务账号运行，云资源控制台的资源移交到接替人员名下。
- 周五下班后：IT在身份源禁用主账号，观察到邮件和即时通讯完成自动同步；代码仓库和云平台按清单手工禁用账号，并回收该账号的访问密钥。
- 周五晚：检查发现该账号仍有一个定时任务在运行。IT与接替人员确认后，把任务迁移到服务账号，再完成停用。
- 次周一：安全角色抽查，用该账号尝试登录各系统均被拒绝，令牌已失效，记录齐全，工单关闭。
记录表单填写要点
示例对应的记录应至少写清：离职人员与生效时间、每个系统的停用方式与执行时间、同步成功与手工处理的区分、异常情况及处理结果、核验人与核验结论。记录的价值在于事后可追溯，因此执行时间和执行人两项不宜省略。
完成检查：怎样确认停用做到位
流程走完不等于账号已停用。以下检查项建议逐条核对，全部通过后再关闭工单。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 登录验证 | 用该账号尝试登录清单中的各系统 | 全部登录失败或被拒绝 |
| 令牌与密钥 | 检查已签发的访问令牌、API密钥、访问凭证 | 均已失效或已回收 |
| 授权与数据 | 检查账号关联的权限、共享、委派关系 | 已回收或已转移给接替人员 |
| 记录完整性 | 核对工单、停用时间、执行人、核验结果 | 信息齐全，可追溯 |
| 定期复查 | 对已离职账号做周期性抽查 | 发现遗漏及时补停并记录 |
登录验证时要注意区分“密码错误”和“账号已禁用”，前者可能只是凭据变更，后者才说明停用生效。令牌与密钥的检查容易被忽略，尤其是长期有效的访问密钥，建议在停用后主动查询并作废。定期复查的周期可根据企业规模设定，抽查范围优先覆盖敏感岗位和近期离职人员。复查发现遗漏时，除了补停，还应回溯原因，判断是清单不全、同步失败还是执行遗漏，并据此调整清单或流程。
常见问题
离职员工最后工作日仍在交接，账号应该当天停还是等交接完再停？
两种做法都有适用条件。按最后工作日结束时停用，交接当天仍可正常登录，适合大多数普通岗位；按交接完成后停用，适合依赖关系复杂、交接周期较长的岗位，但需要同时设定一个最晚停用期限，避免交接拖延导致账号长期可用。掌握核心权限或接触敏感数据的岗位，建议按离职生效即时停用，提前把交接材料准备好，用文档和工单承接交接，减少对账号登录的依赖。
下游系统没有跟随身份源自动同步停用，应该怎么处理？
先在工单中记录同步失败的系统与报错信息，转为在对应系统管理后台手工禁用或改密，并回收该账号持有的令牌与访问密钥。同步存在时延时，要记录观察时间点，区分“尚未同步”和“同步失败”。手工补停完成后，把失败原因反馈给负责身份集成的人员排查，避免下次离职再次出现同类遗漏。
离职人员名下还有定时任务或流水线在运行，能直接停用账号吗？
直接停用可能中断业务。建议先确认任务的归属和影响范围，把任务迁移到接替人员的账号或团队服务账号，确认运行正常后再停用原账号。无法立即迁移的，设定明确的处理期限并记录风险，在工单中标注该账号的例外状态，到期前完成迁移和停用。
共享账号和服务账号在离职时怎么处理才算停用到位？
这类账号的重点是归属转移而不是简单禁用。先确认实际使用者和依赖方，把归属转给接替人员或改为团队统一管理，必要时更换凭据，确保离职人员不再持有密码、密钥或恢复方式。完成标志是每个共享或服务账号都有明确的新负责人，且原持有人无法再通过任何凭据访问。
停用记录要保留哪些内容，后续复查时怎么用？
记录至少写清离职人员与生效时间、每个系统的停用方式与执行时间、自动同步与手工处理的区分、异常情况及处理结果、核验人与核验结论。复查时按记录逐项抽查，优先覆盖敏感岗位和近期离职人员；发现遗漏除了补停，还要回溯是清单不全、同步失败还是执行遗漏，据此调整清单或流程。留存期限按企业适用的制度要求执行。
