离职员工账号还活着的真正原因
一句话总结
离职人员的账户仍然存活，不是因为没人处理离职，而是因为人力系统与账户系统之间没有自动预配。SSO 并不能解决这个问题。
审计最先询问什么
信息安全审计或 ISMS-P 审核中，账户问题几乎是固定的。
- 离职账户是否立即禁用？请提供证据。
- 请提供拥有管理员权限的账户列表和授权理由。
- 如何管理最近 N 个月未登录的账户？
- 是否保留账户创建、变更、删除记录？
- 是否定期核对人力系统与账户系统？
第 5 项是核心，其余四项的答案都来自这里。而多数组织仍然让人手工使用 Excel完成这项核对。
幽灵账户为什么出现
原因并不是“忘记处理离职”，而是结构问题。
原因 1——没有自动预配
这是最大原因。接入 SSO 并不等于解决账户生命周期。
“离职人员仍能登录 SaaS”的事故，大多不是 SSO 的问题， 而是缺少自动预配。
SSO 只负责“登录时确认此人是谁”。在目标系统中创建、删除用户记录是另一件事，实现自动化的标准是 SCIM（RFC 7644）。
没有 SCIM 时，人员离职后虽然 IdP 会阻止登录，但各业务系统里仍保留账户；只要系统存在任何一个本地登录路径，离职人员仍可能进入。而大多数系统都有一个名为“IdP 故障应急登录”的本地入口。
原因 2——增量同步看不到删除
前一模块已经介绍过。“拉取最近变更用户”无法看见已经消失的用户。如果不定期执行全量同步，离职人员会一直残留。
原因 3——非人员账户
批处理账户、集成账户、厂商维护账户、测试账户都不在人力系统中，因此自动从核对范围中漏掉，而这些账户往往权限很高。
这类账户也是审计中的高频问题。审计员问“这个账户属于谁？”得到的回答常常是“好像以前是厂商在用”。
原因 4——并非离职的状态变化
停薪留职、外派、合作方合同结束、部门调动，都不像离职那样有清晰触发器，权限因此会一直跟随人员。调到新部门后仍保留旧部门权限，会被审计认定为“权限累积（privilege creep）”。
如何机械化核对
分别导出人力名册（HR）和目录账户列表，再做集合运算。
A = HR 재직자 uid 집합
B = 디렉터리 계정 uid 집합
B - A → 유령 계정 (퇴사했는데 계정이 남음) ★ 1순위
A - B → 미생성 계정 (입사했는데 계정이 없음) 업무 지연
A ∩ B → 정상. 단 부서·직급 불일치는 따로 본다
还要增加三个维度。
- 权限维度：幽灵账户中仍属于管理员组的，必须立即处理
- 时间维度：90 天以上未登录的，作为休眠候选
- 属性维度：HR 部门 ≠ 目录部门，说明调动未同步
如果每周自动生成并邮件发送这五份列表，核对就从审计应对变成了日常运维。手工 Excel 通常一个季度才做一次，而事故会发生在两次核对之间。
删除账户还是禁用账户
离职账户不应立即删除，原因有多个。
- 审计追踪：该人员所留数据的所有者信息会损坏
- 法律保留：金融、医疗等行业的访问记录保留期很长
- 重新入职：同一个人可能再次回来
- 引用完整性：审批链、负责人、文档作者都可能引用此账户
因此，标准做法是隔离。
1. 비활성화 (로그인 차단) ← 즉시
2. 권한 그룹에서 제거 ← 즉시
3. 별도 OU 로 이동 (ou=Disabled) ← 즉시
4. 사유·일자·처리자 기록 ← 즉시
5. 보존 기간 경과 후 삭제 ← 정책에 따라 (보통 1~5년)
第 3 步在实践中很有用。移到隔离 OU 后，账户会自动从“活跃用户”搜索过滤器中消失，同时数据仍然保留。只需统计隔离 OU 的条目数，也能报告处理数量。
授权原则——只通过组
一旦开始直接给个人授权，六个月后就没人知道全貌。应遵循以下原则。
- 权限只附着于角色组
- 人员成为角色组成员
- 如果需要个人例外，就创建带期限的独立组
并且，不要混用部门组与角色组。 dev-team 是组织，role-deploy 是权限。组织调整经常发生，不能让权限随组织结构一起崩塌。
审计报告应包含的五个数字
报告不必很长，以下五项足以展开对话。
| 项目 | 含义 |
|---|---|
| 账户总数 | 基线 |
| 幽灵账户数 | 离职人员残留，必须为 0 |
| 未创建账户数 | 新入职延迟，业务延迟指标 |
| 特权账户中的幽灵账户 | 最高优先级处理 |
| 90 天未登录账户数 | 休眠候选 |
有数字才能观察趋势。“幽灵账户从上月 12 个降到本月 3 个”可以证明改进；没有数字，每次都只能从头解释。
在实际项目中
五个审计问题里，最后一个最关键：“是否定期核对人力系统与账户系统？”其他四项的答案都来自这里，但多数组织仍让人用 Excel 手工处理。
Excel 核对的问题不在准确度，而在频率。每季度核对一次，无法保证离职次日账户就失效；期间的访问只能事后从日志发现，无法预防。
只做增量同步也很常见，而且更危险：只拉取变更的方式无法看见删除。 从人力系统消失的人并不属于“变更”，永远不会被传过来，账户也就静默残留。
因此，删除前必须有隔离流程。直接删除，会同时破坏此人创建的文档与审批链，而且无法恢复。