第 6 章：员工离职一周后还能访问，究竟是谁的系统出了问题？

本章主线：用一条离职未撤权事件，串起 Workforce IAM、CIAM、IGA、PAM、NHI 和平台产品方法。

开场：一张“已禁用”的截图够吗

HR 显示员工已离职，IdP 账号也已禁用，但某 SaaS 仍保留本地会话，云控制台还有长期 Access Key，生产数据库共享密码没有轮换。小安发现：每个系统都说自己“处理成功”，最终风险却仍存在。

身份业务的难点不是单点功能，而是权威源、生命周期、权限来源、会话、凭证和下游证据形成闭环。

学习目标

能画出 Workforce/CIAM 旅程；设计 JML、访问申请、复核与 SoD；区分 PAM 与普通 IAM；建立 NHI 库存；用风险、体验、效率和合规指标评价项目。

六个业务域的责任边界

领域	首要客户	核心对象	最重要结果
Workforce IAM	员工/应用团队	企业账号、认证器、会话	安全且顺畅地访问工作应用
CIAM	消费者/产品团队	客户身份、账户关系、同意	转化、留存与账号安全平衡
IGA	资源 owner/审计	权限来源、角色、复核	权限合理且可证明
PAM	管理员/SRE	高危权限、会话、凭证	临时、最小、可归因
NHI	平台/应用团队	服务、证书、密钥、Agent	可发现、短期、可撤销
ITDR	SOC/响应团队	风险、会话、攻击路径	快速发现并可信恢复

6.1 从业务问题而非产品缩写出发

业务方不购买“身份”，而是在解决：员工能否及时办公、客户是否顺利登录、敏感数据是否被滥用、离职权限是否回收、审计能否通过、客服成本是否下降。

任何身份项目先写四种结果：风险、体验、效率、合规。只提高安全强度而让注册转化暴跌，不是完整成功；只提高转化而账号接管激增，同样失败。

6.2 Workforce IAM

典型旅程

图 6-1：典型旅程 · 可编辑 Mermaid 源码

核心对象：员工号、雇佣关系、manager、department、cost center、location、employment type。HR 通常是雇佣状态权威源，但不一定知道业务权限。

关键难点：同名/重雇、外包无 HR 记录、合并/拆分组织、多个目录、旧应用不支持自动化、紧急离职、共享账号。

指标：首日可用率、应用接入时长、认证成功率、MFA/Passkey 实际覆盖、离职撤权 P95/P99、身份工单量。

6.2.1 Joiner 详细流程

1. HR 创建雇佣记录，生成稳定 employee ID；
2. 身份服务去重并创建企业身份；
3. 根据岗位、地点、雇佣类型计算出生权限；
4. 创建目录和 IdP 账号；
5. 通过安全渠道完成初始认证器注册；
6. SCIM/API 供应目标应用；
7. 对账并在入职日验证关键应用可用；
8. 异常进入工单而不是静默跳过。

提前创建账号要限制生效时间；初始密码不能通过普通邮件明文发送；manager 改变、入职取消和日期推迟都需要补偿。

6.2.2 Mover 权限差分

计算 target_entitlements - current 为新增，current - target 为待撤。新增走审批和 SoD；撤销考虑业务交接但不能无限延期。对临时例外单独保留来源和 expiry，不并入永久角色。

6.3 CIAM

CIAM 面向消费者，规模、转化、隐私和反欺诈更加突出。

注册漏斗

图 6-2：注册漏斗 · 可编辑 Mermaid 源码

每一步同时量化转化与攻击：验证码到达率、机器人注册、重复账号、账号接管、恢复滥用。风险控制应分层：低风险减少摩擦，高风险提高证明或转人工。

账号模型需解决手机号/邮箱变化、社交账号绑定、账户合并、家庭/组织关系、未成年人、注销和数据删除。不要把手机号当永恒身份主键。

6.3.1 账号合并

合并是高风险、不可轻率自动化的状态转换。验证两个账号控制权；识别订单、余额、订阅、风控标签和隐私同意冲突；生成可追溯 merge record；防止攻击者用弱社交账号吞并高价值账号。

6.3.2 注册反滥用

在设备、网络、验证码、行为、支付和后续业务事件之间关联。验证码成功不代表是真实人；强制实名也可能不适用于低风险产品。按业务损失逐步增加摩擦。

6.4 IGA：身份治理与管理

IGA 关注“谁为什么拥有何种权限，是否仍合理”。

Joiner–Mover–Leaver

• Joiner：根据职位/部门给最小出生权限，额外权限走申请。
• Mover：先计算新旧差异；新增和撤销都要处理，防止只加不减。
• Leaver：禁用身份、撤销会话/凭证/授权、转移数据 owner、处理保留义务。

访问申请

申请应包含资源、权限、业务理由、期限、数据敏感度、审批链。审批者必须理解批准内容；“manager 全批”不是有效控制。高危权限加入资源 owner、安全或职责分离检查。

访问复核

给复核者提供上次使用、权限来源、风险、同岗位对比和业务影响。默认全选会造成橡皮图章；对高风险/长期未用/异常组合优先排序。

6.4.1 权限来源链

每个 entitlement 应能回答：由出生角色、组继承、直接申请、项目关系、特权会话还是 break-glass 获得；谁批准；业务理由；何时到期。只保存最终布尔值会让撤销和解释困难。

6.4.2 复核决策

keep、revoke、reduce、delegate review、exception until date 分开。未按时复核的默认动作按风险分级；对关键权限不可无限顺延。撤销结果还要对账。

职责分离 SoD

例：创建供应商与批准付款不能由同一人同时拥有。SoD 包含静态冲突（同时持权）和动态冲突（同一交易执行两个步骤）。例外需要补偿控制、期限和 owner。

6.5 PAM：特权访问管理

特权不只 root/Domain Admin，也包括生产数据库写权限、密钥管理、身份平台管理员、CI/CD 发布权和云组织管理员。

图 6-3：6.5 PAM：特权访问管理 · 可编辑 Mermaid 源码

Vault 轮换共享密码是过渡；更成熟方向是 JIT/JEA、个人可归因身份、短期凭证和会话代理。Break-glass 账号需离线保护、双人取用、实时告警和用后轮换。

6.5.1 会话代理的边界

代理可以隐藏目标密码、录制会话、限制命令，但不能替代目标系统最小权限。录屏涉及高敏数据和员工隐私，需要访问控制、留存和检索审计。命令阻断规则不能替代数据库事务权限。

6.6 NHI 治理

非人身份包括服务账号、API Key、OAuth Client、云角色、证书、机器人、CI 任务和 Agent。治理清单至少有：唯一 ID、类型、owner、用途、环境、权限、凭证、最后使用、依赖、轮换与撤销方法。

常见问题：owner 离职；一个账号供多服务共享；长期 secret；权限复制；无人知道删除影响。优先用可证明工作负载身份和短期凭证，静态 secret 进入集中管理并自动轮换。

6.6.1 发现渠道

云 IAM、代码/制品扫描、Kubernetes、Secrets Manager、证书管理、OAuth Client 注册、CI 平台、API Gateway 和日志联合发现。发现后做 identity resolution，避免一个服务在各系统被算成十个无关对象。

6.7 Build vs Buy

评估维度：业务差异化、协议覆盖、规模/延迟、合规地域、可扩展性、迁移成本、供应商锁定、SLA、数据导出、管理员安全、总拥有成本。

通常不自研底层密码学和标准协议解析器；差异化风险策略、业务授权和身份数据整合可能需要自建。选择不是一次性决定，要有退出和迁移路径。

6.7.1 概念验证评分

用真实场景而非销售 demo：百万用户峰值、复杂 SCIM、密钥轮换、租户隔离、审计导出、IdP 故障、数据驻留和退出导出。权重由业务确定，保留原始证据和未满足项。

6.8 身份平台产品方法

把应用团队视为内部客户：提供 SDK、中间件、示例、沙箱、自助注册、合规配置、测试工具、文档、支持 SLA。平台成功指标包括接入周期、错误配置率、升级覆盖和复用率。

强迫所有应用一次重写通常失败。按风险和价值分群：新应用默认新标准；高风险旧应用优先迁移；低风险遗留用网关/适配器过渡并设退出日期。

6.9 商业案例

项目提案用可验证假设：

现状：每月 8 万次密码登录，1.8% 进入恢复，产生 900 个工单。
方案：优先推广 Passkey，保留受控恢复。
目标：登录成功率 +2pp，恢复工单 -40%，ATO 不上升。
成本：开发、支持、设备兼容、迁移沟通。
风险：恢复绕过、同步账户接管、覆盖不足。
验证：分群灰度，四周看漏斗、安全事件和工单。

6.10 本章实践与验收

为一家 3000 人、多云、50 个 SaaS 的公司设计 JML；再为 1000 万用户 App 设计 CIAM 注册恢复。列出主体、权威源、SLA、人工例外和指标。

验收：解释 IAM 与 IGA 的边界；为何调岗比入职更危险；PAM 为何要个人归因；如何计算身份平台的业务价值。

6.10.1 业务指标字典

每个指标写 owner、公式、数据源、更新频率和反作弊解释。例如“Passkey 覆盖”至少分注册覆盖、最近 30 天实际使用覆盖、高风险用户覆盖；只看注册会高估效果。

工程复盘：一张“账号已禁用”的截图不能关闭离职事件

HR、IdP 和 SaaS 团队都向小安展示了自己的成功记录，但测试账号仍可通过旧会话访问报表，并使用一把没人认领的云密钥读取对象存储。每个系统局部正确，端到端结果却失败。

小安把“离职完成”改成一组可计算的业务状态：权威源已变更、目录账号已禁用、活跃会话已撤销、应用权限已回收、特权会话已关闭、设备与长期凭证已处理、下游已完成对账。任何一项超时都会生成明确 owner 的异常，而不是把工单停在“接口返回 200”。

复盘会上，业务负责人真正关心的是三组数字：高风险权限暴露了多久、还有多少孤儿身份、撤权失败需要多少人工处理。技术团队则继续追踪事件延迟、重试、乱序、补偿和证据留存。

这次改造把 IAM、IGA、PAM 和 NHI 从产品名词变成同一个业务闭环：一个人的业务关系结束后，他曾经获得的访问能力能否按风险时限真正消失。

面试与设计评审

• IAM、IGA、PAM 各解决什么？用“登录使用—权限治理—特权控制”分层，再说明协作关系。
• 调岗为什么危险？旧权限未减、新权限叠加，形成权限累积和 SoD 冲突。
• 如何证明离职撤权？给出事件时间、各目标回执、会话/凭证撤销、对账和 P95/P99。

本章小结

业务成功不由某个控制台的绿色状态决定，而由主体在全部资源上的最终访问状态决定。身份团队要同时经营风险、体验、效率和证据。