Technical documentation
谁在操作？令牌如何被追踪：审计日志第二类关键记录详解
谁在操作？令牌如何被追踪：审计日志第二类关键记录详解
审计日志的第二类关键记录需明确标识操作发起者、客户端来源、凭证类型及会话或委托链的可识别引用，以此确立控制动作的具体对象。
一份日志若只记录了“用户 A 删除了文件”，却未说明该操作由哪个客户端发起、使用了哪张凭证或属于哪个会话，这份记录就失去了审计价值。这种模糊性正是 IETF Internet-Draft 挑战模型要解决的核心痛点 [1]。
从挑战模型看引用的必要性
Iman Schrock 在 2026 年的草案中明确指出，授权证据必须回答“此时、此资源、此动作”是否有效，而不仅仅是验证主体是否存在 [1]。单纯的角色存在性或令牌持有状态检查，无法证明权限在当前信任条件下依然生效。
这就是为什么受影响主体和令牌如何被引用被定义为五类关键记录中的第二类 [1][2]。前两类记录（目录变更与引用信息）共同定义了控制动作的具体对象与范围。若缺失这些可识别引用信息，审计者只能确认“动作已发起”，却无法判断资源侧是否真正执行了阻断。只有将引用信息与后续的策略判定及负向探测结果关联，才能区分“发起控制动作”与“资源侧有效阻断”的界限 [1][2]。没有这一步，所谓的权限回收往往只是理论上的闭环，而非可复验的事实。
一个常被忽视的细节是：“撤销指令已发出”并不等同于“攻击者手中的令牌即刻失效”。在许多分布式架构中，令牌一旦签发，其有效性往往依赖于本地缓存或边缘节点的短期记忆，直到其自然过期或被显式刷新。如果日志仅记录了中心服务器的“撤销动作”，而未同步记录该令牌在特定会话或客户端上下文中的具体引用状态（如 Token ID、序列号），审计人员将无法确认攻击者手中的那张旧令牌是否还在有效期内。这种“时间差”正是安全事件调查中最大的盲区——系统以为已经锁门，但钥匙孔里还插着旧钥匙。
必须记录的五大要素：构建完整的访问画像
构建完整访问画像必须记录谁发起操作、来自何处、使用何种凭证、处于哪个会话以及经过多少层委托这五大核心要素。
一次权限变更能否被精准复盘，取决于日志里是否写清了“谁、从哪来、拿着什么凭证、在哪个会话中、经过了多少层委托”。缺少这些具体信息，审计者只能看到动作发生了，却连不上具体的用户或设备，导致无法完成端到端审计闭环 [1]。
可复验的控制证据链明确要求记录五类关键内容，其中第二类专门负责提供受影响主体和令牌如何被引用，这是连接控制动作与目标资源的桥梁 [1]。
主体、客户端与令牌的关联逻辑
要确保身份可信，日志必须同时记录主体身份与请求来源（客户端）的唯一对应关系。如果只记了用户名而没记客户端 IP 或设备指纹，攻击者很容易利用被盗账号在不同设备上发起请求。令牌引用则用于防止跨会话滥用，它锁定了凭证的使用范围和时间窗口。只有将这三者绑定记录，才能证明当前的访问确实是由特定用户在特定时刻发起的，而非凭证泄露后的非法复用 [1]。
值得注意的是，现代云原生环境下的客户端标识早已超越了简单的 IP 地址。例如，在 Kubernetes 集群内部的服务间调用中，客户端往往是 Pod 的 ServiceAccount 或特定的 SPIFFE ID，而非传统的公网 IP。如果日志仍沿用旧有的网络层标识，不仅无法区分同一节点上不同服务的异常行为，还可能因为 NAT 或负载均衡的存在，导致多个独立请求被错误地聚合为同一个“客户端”事件，从而掩盖真实的攻击路径。
会话与委托链的追踪难点
多跳委托场景下，信任链往往被切断在中间环节。系统需要完整记录从初始用户到最终执行者的每一级委托关系，否则无法追溯责任的源头。此外，会话状态的变化直接影响审计准确性，一个过期的会话若未被标记，可能让已失效的权限继续生效。缺乏这些细节，审计人员很难判断某次违规操作是源于会话劫持还是内部越权 [1][2]。
| 记录要素 | 核心作用 | 缺失后果 | 典型错误示例 |
|---|---|---|---|
| 受影响主体 | 锁定责任归属 | 无法区分具体用户 | 仅记录”User A”而无 ID |
| 客户端 | 验证请求来源 | 无法发现异地登录 | 忽略设备指纹或 IP |
| 令牌 | 防止凭证滥用 | 无法阻断跨会话攻击 | 未记录 Token ID 或过期时间 |
| 会话 | 维持上下文状态 | 难以还原操作时序 | 丢失 Session ID 或状态标记 |
| 委托链 | 追溯信任传递 | 无法定位中间人风险 | 仅记录最终执行者 |
这五项引用信息拼在一起，才构成了完整的访问画像。它们不是孤立的字段，而是相互咬合的齿轮，共同支撑起对控制动作对象的精确判定 [1]。
仅有引用不够：结合后三类记录实现可复验审计
仅记录主体与令牌引用不足以证明动作生效，必须结合目标动作、策略版本及负向探测等后三类记录才能形成可复验的完整证据链。
仅仅知道“谁被操作了”还不够。第二类记录定义了动作的发起者与对象，但无法证明动作是否真正生效。前两类记录负责划定范围，后三类记录——目标动作、策略版本、负向探测——才负责验证结果[1][2]。没有后者，审计日志只是一份孤立的清单，而非完整的证据链。
从“动作发起”到“有效阻断”的跨越
很多场景下，系统会宣称“撤权已完成”。例如，SCIM 删除用户或回收角色后，断言所有应用缓存、长期令牌和网关授权均已失效。这个结论看似合理，实则缺乏支撑[3][4]。当前材料既无规范原文确认传播机制，也无系统设计图展示缓存刷新逻辑，更缺事件传播记录来追踪状态变更的时序[5][2]。
这就好比只记录了“你关掉了水龙头”，却没检查“水管里是否还有余水”。若缺乏可信时间源的负向探测结果，就无法直接断言资源侧权限已完全收敛。最稳妥的表述应是：控制动作已发起或完成，但资源侧有效权限是否彻底失效，仍需精确的拒绝证据来验证[1][5]。
要构建可复验的证据链，必须将五类记录串联起来。第一、二类记录锁定对象，第三、四类记录明确上下文，第五类记录则提供最终判决——即带有可信时间戳的负向测试数据[2]。只有当独立主体重复执行撤权后的访问尝试，并得到明确的拒绝响应时，断言才能升级为可审计结论[1][2]。这种独立重复测试消除了单次事件偶然性的干扰，让审计结论站得住脚。
| 记录层级 | 核心功能 | 缺失后果 | 典型数据项 |
|---|---|---|---|
| 前两类 (对象定义) | 锁定动作发起者与目标 | 无法定位具体是谁在操作什么 | 主体 ID、客户端标识、令牌引用 |
| 后三类 (结果验证) | 确认动作实际生效 | 只能证明“发了指令”，不知“指令执行” | 目标资源、策略版本、拒绝响应 |
| 关联依赖 | 建立因果闭环 | 断言缺乏事实支撑，沦为推测 | 时间戳、传播记录、测试脚本 |
若材料缺失，任何关于“全域失效”的宏大叙事都经不起推敲。唯有补齐规范、设计文档与重复测试结果，才能让审计日志从“发生了什么”进化为“确实没发生什么”。
落地建议：如何撰写准确的引用记录描述
撰写准确的引用记录描述需遵循精确、可追溯与防篡改原则，清晰表述受影响主体和令牌的引用方式以避免关联失效。
编写审计日志时，组织需遵循精确、可追溯与防篡改原则，确保清晰表述受影响主体和令牌如何被引用[1]。许多失败案例源于模糊的主体标识、缺失的令牌指纹或未绑定的会话 ID，这些漏洞让访问行为无法被正确关联[1]。
具体行动建议：在实施日志采集时，不要仅依赖默认配置，应强制要求日志生成器在输出中包含“全链路上下文快照”。具体步骤如下：首先，在代码层面将 Subject_ID、Client_ID（包含协议类型如 OIDC/SAML）、Token_ID（非哈希值，需包含序列号）、Session_ID 以及 Delegation_Chain（以 JSON 数组形式列出所有中间代理的身份）作为必填字段；其次，在日志存储阶段，对这些字段进行不可变处理，确保即使日志被修改也能通过校验和发现异常；最后，定期（如每周）运行自动化脚本，随机抽取一条“撤销操作”日志，模拟攻击者使用对应的令牌 ID 发起访问，验证系统是否返回预期的拒绝响应。这一过程能直接暴露出引用信息与实际阻断机制之间的脱节。
日志字段必须具体到颗粒度。不要只写“用户 A”，要记录其唯一身份标识；不要只存令牌哈希，要包含完整的令牌指纹以区分不同实例；会话 ID 必须与当前动作严格绑定，防止跨会话混淆。缺乏这些细节，后续权限验证将无从下手。
准确的引用记录是构建有效阻断证据的基石。它直接决定了能否从“动作发起”跨越到“有效阻断”的验证闭环[2]。在证据不足时，切勿宣称全域失效，而应如实记录控制动作状态，并指出资源侧验证的必要性[5]。只有补齐这些引用信息，合规审计才能从理论走向可复验的现实。
FAQ：关于审计日志引用的常见问题
Q: 如果日志中缺少“令牌引用”，是否意味着审计完全无效？ A: 并非完全无效，但会导致证据链断裂。缺少令牌引用意味着无法排除凭证被盗用或在其他会话中复用的可能性，使得“授权证据验证”无法通过，审计结论将停留在“疑似”阶段。
Q: “受影响主体”是指用户名还是用户 ID？ A: 强烈建议使用唯一的用户 ID（如 UUID）。用户名可能会更改，且容易重名，只有唯一 ID 才能作为不可变的“可识别引用信息”来锁定责任归属。
Q: 委托链记录对于小型系统真的必要吗？ A: 即使系统规模小，只要涉及服务间调用或多级代理，委托链就是风险点。一旦中间环节被攻破，缺乏委托链记录将无法定位攻击源头，导致“审计日志关键记录”失去追溯意义。
参考来源
- draft-schrock-ae-challenge-08 - An Authorization Evidence Challenge for High-Risk Agent Actions · https://datatracker.ietf.org/doc/draft-schrock-ae-challenge/（A级）
- Identity Lifecycle Management Playbook - IDManagement · https://www.idmanagement.gov/playbooks/ilm/（A级）
- draft-liu-oauth-chain-delegation-00 - Delegation Chain for OAuth 2.0 · https://datatracker.ietf.org/doc/draft-liu-oauth-chain-delegation/（A级）
- draft-niyikiza-oauth-attenuating-agent-tokens-01 - Attenuating Authorization Tokens for Agentic Delegation Chains · https://datatracker.ietf.org/doc/draft-niyikiza-oauth-attenuating-agent-tokens/（A级）
- Revoke user access in an emergency in Microsoft Entra ID - Microsoft Entra ID | Microsoft Learn · https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access（A级）