【零信任安全架构】持续验证 vs 一次性认证：信号流、会话风险和策略降级

传统认证模型的时序是：登录时验证一次 → 签发一个数小时有效的 Session → 期间不再验证。零信任把这个模型变成了：信任分数随时间动态变化，会话可能在任何时刻被降级或撤销。

前置阅读：设备姿态与远程证明。

一、一次性认证的四个不可能假设

传统模型隐含四个假设，每个都在现代威胁面前不成立：

MGM 度假村 2023 年的攻击就是第三个假设崩塌的实例——攻击者冒充员工重置了 Okta MFA 令牌，此后的所有操作都被系统视为”已认证用户”。

二、三种持续验证模式

2.1 Event-driven 模式

Event-driven 持续验证是最”零信任原生”的模式：系统不在固定时间点重新评估，而是订阅风险信号事件（如设备不合规、密码被修改、用户被从组中移除），当事件到达时立即触发对应会话的降级或撤销。

这个模式的协议层实现是 OpenID Shared Signals Framework (SSF) 和 Continuous Access Evaluation Profile (CAEP)——目前仍处于草案阶段（CAEP 1.0 draft-05）。

CAEP 定义的事件类型：

CAEP 基于 RFC 8417（Security Event Token, SET）——SET 是一个 JWT 格式的事件载荷，包含事件类型、主体标识符（iss_sub）、事件时间戳和事件特定的属性。

SET 的交付机制有两种（RFC 8935 推 / RFC 8936 拉）：

推模式 (RFC 8935):
IdP/Transmitter → HTTP POST → Client/Receiver
                   ↓
              POST /events
              Body: {"events": {"https://schemas.openid.net/secevent/caep/event-type/device-compliance-change": {...}}}

拉模式 (RFC 8936):
Client/Receiver → HTTP GET → IdP/Transmitter
                             ↓
                        返回未送达的事件列表

目前 CAEP 的主要采纳者是 Microsoft（Azure AD Continuous Access Evaluation）、Okta 和 Google——但它们之间的互操作（跨厂商的 CAEP 事件传递）仍在早期阶段。Shared Signals 工作组的重大成果是定义了标准化的 Subject Identifiers（RFC 9493）——不同系统之间用相同的格式识别同一个用户/设备。

2.2 Periodic 模式

Periodic（周期性）持续验证是当前最主流的折中——它不需要复杂的事件基础设施，而是在固定的时间间隔重新查询设备状态。

周期长度是一个工程权衡： - 1 分钟：接近实时，但策略引擎和信号源的查询负载很高 - 5 分钟：当前主流选择——JWT 常见有效期（5 分钟）匹配评估周期 - 15 分钟：Google BeyondCorp 使用的间隔——足够应对大多数风险场景，同时保持较低的负载

Periodic 模式的一个工程挑战是时钟同步——如果 10000 台设备都在每分钟的第 0 秒触发重新评估，策略引擎会在那一刻承受全部的负载。实践中的做法是为每台设备分配一个随机的评估偏移量（stagger），把负载平滑到整个周期内。

2.3 Request-granular 模式（短有效期凭据）

证书有效期设为极短（如 1 小时或 5 分钟），每次证书续期时必须重新走完整的姿态检查。SPIRE 的默认 SVID TTL 就是 1 小时——这本质上就是一种 request-granular 的持续验证，以证书生命周期为原子单位。

但短有效期证书不等于真正的”每一个请求都验证”——证书在有效期内的所有请求都被视为”已认证”。Google 的做法是将访问代理的 Session Cookie 有效期设为短于 JWT 证书有效期——用户在操作过程中如果设备姿态变化，访问代理在下一个请求的 Cookie 验证中就能发现。

三、会话降级的工程机制

当信任分数从高降到低，系统不能简单地”关掉所有连接”——那会导致用户的工作被中断。降级有三种策略：

3.1 权限衰减（Authorization Attenuation）

用户的 Session 仍然有效，但访问的权限被缩减。原先可以访问生产数据库，降级后只能访问开发数据库。原先可以 POST/PUT/DELETE，降级后只能 GET。

实现方式：JWT 中编码的 scope 或 permissions 在续期时按新策略重新签发。旧的 JWT 仍然有效但不包含危险操作——因为这些操作在策略引擎中被拒绝。

3.2 Step-up 认证

当分数下降但尚未到需要完全撤销的程度时，要求用户完成额外的认证因素以恢复分数。例如： - 设备补丁落后 → 用户登录后看到”因为你的设备需要更新，访问此资源之前需要输入 FIDO2 安全密钥” - IP 地址变化 → “检测到你的位置变化，请输入手机验证码” - 非工作时间访问高敏感资源 → 同样触发 Step-up

Step-up 认证对用户体验的影响大——如果过于频繁触发，用户会产生”安全疲劳”，开始寻找绕过方法。

3.3 会话撤销（Session Revocation）

当信任分数降到阈值以下——设备被报告为被盗、用户密码被重置、IdP 发出 session-revoked 事件——PDP 通知所有 PEP 撤销该用户的全部活跃会话。

实现方式：JWT 无法被”撤销”（因为它是自包含的），所以撤销的实现依赖于： - JWT 短有效期（5-15 分钟）限制泄露窗口 - Token Introspection（RFC 7662）——资源服务器在每次请求中向 IdP 查询 token 是否仍有效 - 引用型令牌（Reference Token）——不发放 JWT，发放不透明标识符，资源服务器每次都查 IdP

引用型令牌给出了最强的撤销保证（即时生效），但引入了每次请求的额外网络延迟。这是安全性和性能之间的典型零和博弈。

四、信号源的不对等性

持续验证依赖的四种信号源的更新频率和可靠性完全不同：

这些信号的不对等性意味着持续验证不能”等所有信号就绪后再做决策”——因为用户行为基线可能还没算出来。实际工程中，持续验证策略是分层级的：

• 第一层（即时可靠）：设备证书存在 + Session 有效 → 基础访问
• 第二层（分钟级）：设备合规 + 无威胁情报告警 → 敏感资源访问
• 第三层（天级）：行为基线正常 + 无异常模式 → 高敏感资源访问（加权到信任分数中）

五、与 IAM 会话管理的衔接

本站 Session、Refresh Token 与吊销体系 讨论的是”令牌本身的生命周期管理”。持续验证是在这个基础上的叠加——它不仅关心”令牌是否过期”，还关心”令牌的有效性是否应该因为外部信号变化而被提前终止”。

具体衔接： - Refresh Token Rotation（每用一次 Refresh Token 就签发新的 Refresh Token）与持续验证结合：在刷新时重新评估风险分数 - Token Introspection 端点在持续验证中可以整合设备姿态检查——不仅返回 active: true/false，还返回 risk_level 和 allowed_scopes - Session 吊销事件（session-revoked）通过 CAEP 事件传播到所有依赖该 Session 的资源服务器

下一篇：零信任策略引擎：OPA/Rego 与 Cedar 在 ZT 中的落地。

参考资料

1. OpenID Foundation. Shared Signals Framework 1.0. https://openid.net/specs/openid-sharedsignals-framework-1_0.html
2. OpenID Foundation. Continuous Access Evaluation Profile 1.0 (draft 05). https://openid.net/specs/openid-caep-1_0-05.html
3. IETF. Security Event Token (SET). RFC 8417.
4. IETF. Push-Based SET Delivery Using HTTP. RFC 8935.
5. IETF. Subject Identifiers for Security Event Tokens. RFC 9493.
6. IETF. Token Introspection. RFC 7662.