切换深色模式
第 0 章：身份安全只是“登录”吗？一张图看懂人、机器与 Agent
本章主线：从“身份安全就是账号密码”这个误区出发，建立主体、身份、认证、授权、治理、审计的完整地图。
开场：小安接到的第一项任务
刚入职的小安被安排“接一下统一登录”。他以为工作只是调用登录 SDK，评审同事却连续问：员工离职后多久失效？服务账号由谁负责？设备不合规怎么办？Agent 代表谁调用工具？一次登录成功后风险变化如何撤销？
如果这些问题没有答案，系统只有登录功能，还没有身份安全能力。先用本章建立地图，后续每章再下钻一个区域。
本章目标
学完后，你应能说清身份安全的边界、六类主体、四类核心动作、主要业务域，以及如何用项目和证据而不是“看完课程”衡量成长。
前置知识与预计投入
- 前置：会使用一种编程语言，知道 HTTP 请求和数据库的基本概念即可。
- 首次学习：3–4 小时；画自己公司的图再用 2 小时。
- 产出：一张身份系统全景图、一张术语关系图、一份未知问题清单。
- 完成标志：能在 10 分钟内向非安全同事讲清楚“身份安全不等于登录”。
0.1 身份安全究竟保护什么
身份安全不是登录页，也不是某个厂商产品。它是一套持续回答以下问题的系统：
- 当前主体是谁，身份依据可靠吗？
- 它正在代表自己还是代表别人？委托是否有效？
- 它想对哪个资源执行什么动作？
- 当前设备、网络、时间、行为和风险是否允许？
- 权限从何而来、为何仍存在、何时回收？
- 事后能否还原决策、动作和责任链？
图 0-1：0.1 身份安全究竟保护什么 · 可编辑 Mermaid 源码
0.2 六类主体
| 主体 | 稳定标识示例 | 主要凭证 | 最大风险 |
|---|---|---|---|
| 员工/外包 | workforce user ID | Passkey、证书、MFA | 离职未撤权、钓鱼、内部滥用 |
| 消费者 | customer ID | Passkey、密码、社交登录 | 账号接管、欺诈、恢复滥用 |
| 设备 | device ID | 设备证书、TPM 密钥 | 克隆、失管、健康状态伪造 |
| 工作负载 | SPIFFE ID、cloud role | X.509-SVID、短期 token | 静态密钥、横向移动、供应链 |
| 自动化/机器人 | service principal | OAuth client、签名身份 | 过度授权、无人负责、永不过期 |
| AI Agent | definition + instance ID | 工作负载身份 + 任务委托 | 提示注入、工具误用、责任不清 |
同一个人可能拥有多个账号，但账号不等于人；同一个 Agent 定义也会产生许多运行实例。设计时必须区分现实主体、数字身份、账号、凭证和会话。
0.3 四个动作与常见混淆
- 身份证明：确认“这个申请者对应现实中的谁”。例：远程核验身份证件和活体。
- 认证：确认“当前访问者控制该账号绑定的认证器”。例：验证 Passkey 签名。
- 授权：确认“此刻能否读取 payroll.csv”。例：策略引擎结合角色和设备状态判断。
- 治理：确认“为什么获得权限、是否职责冲突、是否仍需保留”。例：季度访问复核。
403 通常是已识别但不允许；401 是缺少或无法接受认证信息。它们只是 HTTP 语义，不能替代完整的业务错误设计。
0.4 六大业务域如何协作
图 0-2：0.4 六大业务域如何协作 · 可编辑 Mermaid 源码
- IAM/CIAM 解决身份使用；IGA 解决权限为什么存在；PAM 解决高危权限如何使用。
- NHI 解决非人身份；ITDR 监视全部身份的异常使用。
- 大型组织往往多套系统并存，真正困难的是身份关联、事件一致性、责任边界和迁移。
0.5 一个完整访问案例
场景：财务员工在受管设备上，让报表 Agent 读取本月数据并生成摘要。
- HR 系统确认员工在职，IGA 给其财务分析角色。
- 员工用 Passkey 向 IdP 认证，设备平台提供合规状态。
- Agent 平台创建一次运行实例，记录发起人、任务、有效期和允许工具。
- Agent 以自己的工作负载身份连接工具网关，同时携带用户委托上下文。
- 策略引擎确认用户角色、Agent 可信版本、数据范围、时间和风险。
- 只读数据 token 绑定报表 API audience，五分钟后过期。
- Agent 输出带证据引用的摘要；下载原始全量数据需员工再次确认。
- 所有决策、工具参数、数据范围和审批进入审计；风险变化可撤销会话。
这一个案例同时包含 IAM、IGA、设备身份、工作负载身份、Agent 委托、授权、审计和持续访问。
0.5.1 把案例拆成数据对象
| 对象 | 示例字段 | 权威来源 | 变化频率 |
|---|---|---|---|
| 人员身份 | employee_id、employment_status | HR | 入转调离 |
| 账号 | account_id、tenant、status | IdP/应用 | 分钟到天 |
| 认证器 | credential_id、type、created_at | IdP | 注册/撤销时 |
| 设备 | device_id、compliance、last_seen | MDM/EDR | 分钟级 |
| Agent 实例 | run_id、definition、task、expiry | Agent 平台 | 每任务 |
| 权限 | relation/role、source、expiry | IGA/策略系统 | 申请/策略变化 |
| 会话 | session_id、aal、risk、expiry | IdP/应用 | 秒到小时 |
| 审计 | actor、action、resource、decision | 各执行点 | 每请求 |
建模时先找稳定 ID，再处理显示名、邮箱、手机号等可变属性。所有关系写清权威来源和最大同步延迟，否则无法定义撤权 SLA。
0.5.2 画信任边界
把系统分成用户设备、互联网入口、身份平面、策略平面、业务资源、管理平面和审计平面。跨边界的每条线标注：协议、认证方式、数据敏感度、超时、重试、owner。
常见遗漏：管理员控制台没有单独边界；日志平台能读全量敏感数据；内部服务盲信网关注入头；Agent 工具与普通 API 共用全权限 token。
0.5.3 明确责任
- HR 对雇佣状态负责，不对某个财务权限是否合理负责。
- IdP 对认证和会话负责，不自动知道业务资源关系。
- 资源 owner 对权限业务合理性负责。
- 安全团队定义基线与高风险控制，但不能代替全部审批。
- 应用团队必须在服务端执行授权，不能只依赖平台“已经登录”。
可用 RACI 明确负责、批准、协作和知会，尤其要覆盖异常和 break-glass。
0.6 学习的最小闭环
每个知识点按七步完成：
text
定义 → 画图 → 跑通 → 故意破坏 → 修复 → 度量 → 讲给别人“看懂”不算掌握。以 OIDC 为例，完成标准至少是：能画授权码流程；抓到真实请求；解释 state/nonce/PKCE；制造错误 audience 和过期 token；正确拒绝；加入日志与指标；让同事依据文档复现。
0.7 知识成熟度分级
| 等级 | 表现 | 证据 |
|---|---|---|
| L1 知道 | 能定义术语 | 概念卡、口头说明 |
| L2 会用 | 能按文档实现 | 可运行 demo、测试 |
| L3 会防 | 知道失败和攻击路径 | 威胁模型、负向用例 |
| L4 会设计 | 能比较方案和规模化 | RFC、压测、迁移方案 |
| L5 会负责 | 对业务结果和长期演进负责 | 指标、复盘、路线图 |
0.8 本章实践
画出所在公司的主体—身份源—IdP—策略—资源—日志数据流。每条边标注协议、数据、owner、超时和失败处理。若暂未入职，用“大学教务系统”模拟。
验收问题：账号和身份为何不能等同？Agent 为什么必须同时有自己的身份和用户委托？认证成功为何不能推出授权允许？
0.8.1 绘图步骤
- 列出所有主体，不先画产品名。
- 列出资源和高价值动作。
- 标出身份源、认证器、策略和执行点。
- 画正常请求，再画离职、凭证泄漏和风险升高三条异常路径。
- 给每条传播边写最大延迟和失败补偿。
- 找出没有 owner、不能撤销或无法审计的节点。
0.8.2 自测场景
- 员工从研发调到财务，旧 Git 仓库权限如何减掉？
- 手机号被运营商回收后，账号标识是否会指向新用户？
- 一个 CI 任务被复制到攻击者仓库，云角色还能否承担？
- Agent 任务结束后，工具 token 和长期记忆分别如何处理？
0.8.3 本章交付物模板
text
系统范围：
主体：
资源与高价值动作：
权威身份源：
认证方式：
授权模型与 PEP：
生命周期事件：
撤销最大延迟：
审计位置与 owner：
前三项未知风险：工程复盘：第一周不要急着画“大而全架构图”
小安最初把公司所有身份系统抄进一张图：几十个方框、上百条线，看起来很努力，却回答不了“员工离职后，哪个系统负责让生产权限真正失效”。导师让他换一种做法：只选“员工访问生产数据库”这一条旅程，从 HR 离职事件开始，一直追到账号、会话、临时权限和共享凭证全部失效。
第一版图的问题不是画得不漂亮，而是没有责任、时限和证据。小安重新给每个节点补上 owner、权威数据源、输入事件、失败补偿、撤销 SLA 和审计证据，并实际抽查一个测试账号。结果发现 IdP 已禁用，但数据库本地账号仍然有效——这才是地图真正创造价值的时刻。
本章完成后，应留下三件可评审的产物：
- 一条关键访问旅程，而不是一张百科全书式系统图；
- 一份主体、资源、凭证、会话和 owner 清单；
- 一个可以实际执行的撤权或访问验证用例。
地图的价值不在“覆盖了多少名词”，而在于它能否带着团队找到一个真实缺口。
面试与设计评审
- 30 秒回答：身份安全是什么？答出“正确主体、正确资源、正确动作、正确上下文、持续验证与审计”。
- 追问：账号、身份、凭证、会话分别是什么？用一个员工更换手机的例子解释生命周期不同。
- 生产级补充：说明权威源、撤销 SLA、策略执行点、非人身份和 Agent 委托。
本章小结
身份安全保护的是访问关系，不是登录页面。后续学习始终沿“主体—凭证—会话—策略—资源—审计”追踪，任何缩写都放回这条链上理解。