权限审查发现离职人员账号未回收，处置的第一步是定级，第二步才是动手。把“是否仍可登录、是否持有高权限或敏感数据访问、近期是否有活动”三项证据交叉判断，可将账号分为高、中、低三级：高等级立即冻结并保留取证快照，中等级确认业务交接后限时回收，低等级纳入批量清理。整体顺序是先止血、再取证、后回收，最后通过复查和离职联动验证闭环，避免直接删除导致审计证据丢失。
要点总览（TL;DR）
- 分级看三项证据：账号是否仍可登录、是否持有高权限或敏感数据访问、离职后是否有操作记录，三项交叉判断后给出高、中、低等级。
- 处置顺序是先止血、再取证、后回收：高等级立即冻结并保留日志与权限快照，中等级确认业务交接后限时回收，低等级纳入批量清理。
- 删除、改密、转移资产前需满足取证快照可读、业务交接已确认、关联令牌已梳理三个条件，任一不满足就停止操作。
- 验证由执行人以外的角色交叉核对账号状态、权限残留、令牌密钥和共享账号，高等级账号在处置后24小时内复查。
- 防复发靠离职清单与账号清单定期比对、离职流程内置账号回收节点，外包与跨项目账号按合同和项目逐项核对。
先判断风险等级：离职账号未回收的三种典型情形
“账号未回收”是一个笼统描述，落到处置上需要拆成不同情形。同样是离职人员账号，一个仍能登录且持有生产环境发布权限的账号，与一个已停用但项目成员关系尚未清理的账号，风险相差很大。定级的目的，是让有限的处置资源优先覆盖真正可能造成损失的账号。
从症状看，离职账号未回收通常表现为三类：第一类是账号仍可登录，说明身份凭证未被停用；第二类是账号仍持有权限，包括系统角色、项目成员身份、用户组继承权限、密钥或令牌；第三类是账号仍有活动记录，例如近期登录、提交代码、访问文档或调用接口。三类症状可以单独出现，也可以叠加，叠加越多风险越高。
定级依据建议固定为三项证据，逐项核实后再给等级：
- 登录状态：账号当前是否可登录、最近一次登录时间、登录来源IP与设备是否异常。
- 权限范围：账号是否持有管理员角色、生产环境操作权限、敏感数据或密钥访问权限，权限是直接授予还是通过项目、用户组继承。
- 近期操作痕迹：离职日期之后是否有代码提交、配置变更、数据导出、权限变更等操作记录。
三项证据与初步等级的对应关系可参考下表。表中等级是初步判断，最终等级还需结合原因排查结果调整。
| 典型情形 | 关键证据 | 初步等级 |
|---|---|---|
| 仍可登录，且持有管理员或生产环境高权限，离职后仍有操作记录 | 登录成功记录、高权限授予记录、离职后操作日志 | 高 |
| 仍可登录，权限为普通项目成员，离职后无操作记录 | 登录状态、项目成员关系、最近活动时间早于离职日期 | 中 |
| 已停用或无法登录，但项目成员关系、用户组继承权限仍残留 | 账号状态为停用、权限继承链路仍存在 | 中 |
| 账号已停用、无残留权限、无活动记录，仅账号记录未归档 | 停用状态、权限清单为空、活动记录为空 | 低 |
本文讨论的范围限于离职人员账号本身的停用、权限回收、取证与验证。离职人员使用AI工具或外部大模型服务产生的权限问题，归入研发AI应用权限与治理；围绕操作日志构建过程审计证据体系，归入研发过程合规与审计。这两类问题与离职账号处置相关，但处置对象和方法不同，本文不展开。
原因假设与排除证据：账号为什么没被回收
定级之后需要弄清账号为什么没被回收，否则同类问题会反复出现。原因排查的关键是把假设和证据分开：先列出可能原因，再逐条找证据验证或排除，不能凭经验直接下结论。排查顺序建议从“离职流程是否触发”开始，再查账号归属与权限来源，最后查清单覆盖范围。
常见原因假设及对应的验证证据如下：
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 离职流程未触发账号回收动作 | 人事离职记录与账号停用工单的时间对比；离职流程中是否包含账号回收节点及责任人 | 第一步 |
| 账号由多人共用，无法对应到具体离职人员 | 账号登录IP与设备分布、使用人登记记录、共享账号清单 | 第二步 |
| 权限来自项目或用户组继承，移除成员身份后权限仍残留 | 账号直接授权清单与继承授权清单对比；项目成员关系、用户组成员关系 | 第二步 |
| 外包或外部协作账号未纳入离职清单 | 外包人员合同结束记录、外部协作账号台账、账号创建来源 | 第三步 |
排查中需要区分“确实未回收”与“已停用但权限残留”。前者指账号仍可登录或身份凭证仍有效，处置重点是停用与取证；后者指账号已停用，但项目成员关系、用户组继承、API令牌或密钥仍然有效，处置重点是清理权限来源。两者的验证方法不同：前者查登录状态和认证记录，后者查授权链路和凭证清单。把这两种情况混在一起，容易出现“账号已停用就认为处置完成”的误判。
排查顺序上，建议先确认离职流程与账号停用的时间差，再核对账号归属，最后检查清单覆盖范围。每一步都留下书面记录，包括查了哪些系统、看了哪些日志、结论是什么。这些记录既是原因分析的依据，也是后续复查和机制改进的输入。
分级处置步骤：从止血、取证到回收
处置顺序遵循先止血、再取证、后回收。止血是阻止账号继续产生新的操作，取证是固定当前状态供后续审计和责任认定，回收是清理账号及其权限。顺序颠倒会带来两类问题：先删除账号会丢失登录与操作证据；只停用不取证，后续无法判断离职后是否发生过异常操作。
高等级账号的处置动作最紧急。第一步立即冻结或停用账号，阻断登录与接口调用；第二步在停用前后保留登录日志、操作日志、权限清单的快照，快照应包含时间戳和操作人；第三步通知账号原所属团队负责人和安全责任人，说明处置原因与当前状态。如果账号涉及生产环境或敏感数据，还需同步检查离职后是否发生过数据导出、配置变更等操作，发现异常时转入安全事件流程。
中等级账号在确认业务交接后限时回收。先核实该账号承载的业务、数据归属和交接状态，确认无未完成交接后再执行停用与权限清理。权限清理要沿继承链路处理：移除项目成员关系、用户组成员关系，再核对直接授权是否清空。限时回收的时限由团队根据业务连续性要求设定，并在工单中记录截止时间与责任人。
低等级账号纳入批量清理。按账号清单批量停用、归档，保留账号标识与处置记录，便于后续审计核对。批量清理同样需要先导出清单快照，避免清理后无法回溯处理了哪些账号。
| 等级 | 处置动作 | 顺序与停止点 |
|---|---|---|
| 高 | 立即冻结或停用；保留登录与操作日志快照；通知团队负责人和安全责任人；检查离职后异常操作 | 先停用再取证或停用同时取证；发现异常操作时停止常规回收，转入安全事件流程 |
| 中 | 确认业务交接与数据归属；限时停用；沿继承链路清理项目、用户组权限；核对直接授权 | 交接未确认前不执行删除；权限清理完成并复核后才关闭工单 |
| 低 | 批量停用与归档；导出账号清单快照；记录处置结果 | 清单快照完成后再批量执行；归档记录保留可查 |
删除账号、修改密码、转移资产属于破坏性操作，执行前需要满足前置条件：取证快照已完成并确认可读；业务交接已由接收方确认；账号关联的密钥、令牌、集成配置已梳理并确定处理方式。任一条件不满足时应停止操作，先补齐条件。删除操作建议设置观察期，观察期内账号保持停用状态，确认无业务影响后再执行删除。
处置过程涉及多角色协作：安全或平台管理员负责定级与执行，团队负责人确认业务交接，人事提供离职记录。把每个账号的处置动作、责任人、截止时间和当前状态记录在统一的工作项中，可以减少口头交接造成的遗漏。ONES 的工作项跟踪可以承载这类处置任务，将账号处置拆成可分配、可流转、可留痕的任务项，处置记录与复查结果随任务归档，便于后续审计时按账号追溯处置过程。
验证恢复与防复发：怎么确认处置到位
处置完成后需要验证结果，确认账号状态、权限残留和关联凭证都已处理到位。验证不是重复执行处置动作，而是用独立视角核对处置结果，发现遗漏后回到处置环节补做。
验证项建议覆盖以下内容：
- 账号状态：账号是否已停用或删除，尝试登录是否被拒绝，认证记录是否显示停用生效。
- 权限残留：直接授权、项目成员关系、用户组继承权限是否清空，是否存在通过服务账号或集成配置保留的访问路径。
- 关联令牌与密钥：该账号创建或持有的API令牌、访问密钥、个人访问凭证是否已吊销。
- 共享账号：是否存在与该离职人员相关的共享账号，共享账号的使用人登记是否更新。
复查时点和责任人需要事先约定。高等级账号建议在处置完成后24小时内复查一次，确认停用生效且无新的活动记录；中等级账号在限时回收截止后复查；低等级账号随批量清理批次复查。复查人应与执行人分离，由安全团队或平台管理员交叉核对，复查结果记录在处置工单中。
防复发的核心是把离职清单与账号清单做定期比对，并让账号生命周期与人事流程联动。具体做法包括：定期导出在职人员清单与账号清单比对，识别离职后仍存在的账号；在离职流程中设置账号回收节点，明确触发条件和责任人；对外包和外部协作账号建立单独台账，合同结束时同步触发账号处置。比对频率根据团队人员流动情况设定，人员流动频繁时缩短比对周期。
外包与跨项目情形需要补充检查。外包账号往往不在正式离职清单中，需要按合同结束日期单独核对；跨项目账号可能存在多个项目的成员关系，清理时要逐个项目确认，避免只清理主项目而遗漏其他项目的继承权限。复查时把这两类情形列入固定检查项，可以减少同类问题再次出现。
常见问题
离职账号已经停用了，还需要按分级流程处置吗？
需要，但处置重点不同。账号停用只解决了“能否登录”，权限残留仍可能通过项目成员关系、用户组继承、API令牌或密钥保留访问路径。这类账号在定级时通常归入中等级，处置动作是沿继承链路逐项清理权限来源，并吊销该账号创建或持有的凭证，而不是重复执行停用。验证时重点核对授权链路是否清空，确认不存在绕过登录的访问方式。
高等级账号发现离职后有异常操作，处置顺序要不要调整？
要调整。常规顺序是先止血、再取证、后回收，但一旦发现离职后存在数据导出、配置变更等异常操作，止血之后应暂停常规回收，转入安全事件流程。此时账号保持冻结状态，取证范围从登录日志和权限清单扩展到具体操作对象，例如被访问的数据、被修改的配置，并同步通知安全责任人和业务负责人。待事件定性后再决定是否继续回收，避免清理动作破坏事件现场。
外包人员账号不在正式离职清单里，怎么纳入处置？
外包账号需要单独建台账，按合同结束日期而不是人事离职流程触发处置。排查时先核对合同结束记录与账号最近活动时间，确认合同已结束但账号仍可登录或仍持有项目权限的，按中等级以上处理。清理时逐个项目确认成员关系，因为外包人员常同时参与多个项目，只清理主项目会遗漏其他项目的继承权限。合同结束与账号处置的联动节点应写入外包管理流程，明确触发人和时限。
处置记录要保留哪些内容，后续审计才够用？
至少保留四类内容：定级依据，即三项证据的核查结果；处置动作与时间，包括停用、权限清理、令牌吊销的执行时间和执行人；取证快照，包含时间戳的登录日志、操作日志和权限清单；验证结果，即复查人、复查时间和核对结论。把这些记录挂在同一个处置工单下按账号归档，审计时可按账号追溯完整处置过程。记录保留周期参照团队适用的合规要求设定。
离职清单与账号清单比对多久做一次比较合适？
比对频率取决于人员流动情况，没有统一标准。人员流动频繁的团队可以缩短到每月一次，流动较少的团队按季度比对也能覆盖主要风险。比对外还需要关注触发时点：离职流程中设置账号回收节点，让处置在离职发生时即启动，定期比对作为兜底检查，两者配合比单纯提高比对频率更有效。每次比对输出差异清单，逐条确认是待处置账号还是清单口径差异。
