凭据/证书撤销后「标记吊销」到「全网验证方真正拒绝」的传播延迟，到底怎么测量、设预算、证明在风险窗口内？

结论先行：三类撤销机制里，JWT 黑名单和 DB 密码都能压到 ≤60s，但瓶颈都不在「缓存 TTL」，而在两个已有回答没展开的中间件工程细节——黑名单一致性光靠「推送」不够，必须叠加单调递增的撤销版本号做对账（否则断连窗口/批量吊销会静默漏），以及探针不该逐实例发请求，用 blacklist_loaded_at 指标无侵入量长尾更准。CRL 那类，OCSP stapling 有覆盖盲区，mTLS SVID 场景更该走 SPIFFE 的短 TTL + 主动 rotation，而不是赌 CRL 全网同步。

一、黑名单：推送只当唤醒，一致性靠版本号对账

推送（Redis Pub/Sub / K8s Event）是 at-most-once：实例在断连、GC 停顿、或滚动发布重启的窗口里，推送会静默丢失；60+ 微服务批量吊销一批 JWT 时，Pub/Sub 还有消息风暴和乱序。可靠做法是推送只当「唤醒信号」，真正的一致性靠单调递增的撤销版本号：

• 撤销时写一条 {jti, version}，version 全局单调递增（Redis INCR / DB sequence）；
• 实例本地记 loaded_version，收到推送后拉 version > loaded_version 的增量，更新本地并落 loaded_version；
• 每 30s 主动对账一次：if local_version < server_version 就补拉——这是兜底，断连窗口的丢失在这里被追平。

黑名单条目本身要带 TTL = token 剩余有效期，否则会无限膨胀。用 Redis ZSET（score = 过期时间戳）比逐 key SETEX 好：ZCOUNT 直接看规模、ZREMRANGEBYSCORE 0 now 一条命令淘汰过期项，规模可观测、可告警。

二、探针：别逐实例发请求，用 blacklist_loaded_at 无侵入量长尾

已有回答的探针是「循环发旧 JWT 到每个网关实例」，这要求探针能直连每个实例、且会污染线上。更无侵入、且天然覆盖长尾的做法：

• 每次验证时，网关打一个指标 revocation_blacklist_loaded_at（= 本地黑名单最近一次成功加载的服务端 version/时间戳）；
• 撤销后直接查「所有实例的 loaded_at 是否都 ≥ t_revoke」：max(loaded_at) − t_revoke 就是 P99 传播延迟，max 就是最坏实例。
• 你实测那个 95s 的冷启动实例，在这个口径下会直接暴露成「loaded_at 早于 t_revoke 的那一台」，不用逐台发请求就能定位。

这比发探针更干净：不产生额外流量、不要求实例可直连、且「还没拉到」的实例（loaded_at 早于 revoke）天然就是长尾来源——和你「长尾由实例生命周期决定」的观察完全自洽。

三、CRL 那类：OCSP stapling 有盲区，mTLS SVID 更该走 SPIFFE 短 TTL

已有回答推荐 OCSP stapling，方向对，但有个盲区：stapling 的 revocation status 是经过该网关的 TLS 握手里由服务端返回的，且服务端（如 Envoy）本地 OCSP response 有缓存 TTL。如果你的验证方是直连服务、不经过那个 stapling 网关，stapling 帮不上——你还是回到拉 CRL 的老路。

对 mTLS SVID（SPIFFE 那套）场景，更可靠的不是赌 CRL 传播，而是让 SVID 本身短 TTL + 主动 rotation：SVID TTL 从 1h 压到 5min，配合 SPIRE 的 push rotation，泄露后最长暴露窗 ≈ 一个 TTL（5min），根本不等 CRL 全网同步。这比「标记吊销→等传播」的模型更简单、可证明——暴露窗就是 TTL 本身，不用再量传播延迟。

四、预算口径：暴露窗 = max(三类 TTL 或 R_prop P99) + buffer

三类是并行的，安全侧只需证明最坏那一类。但注意：对「短 TTL 主动 rotation」的机制（SVID、短 JWT），暴露窗 ≈ TTL，不用量传播延迟；对「标记吊销→等传播」的机制（CRL、DB 连接池存量），暴露窗 = R_prop P99。预算取两者的 max + buffer，写进评审：

| 机制 | 暴露窗来源 | 目标 | |---|---|---| | JWT 黑名单 | R_prop P99（推送+对账后可 <15s） | ≤ 60s | | mTLS SVID | TTL 本身（压到 5min） | ≤ 300s | | DB 密码 | R_prop（ALTER + KILL 存量 + maxLifetime≤60s） | ≤ 60s |

关键洞察：能改成「短 TTL 主动 rotation」的，就别用「吊销→等传播」——前者的暴露窗是 TTL 本身、可证明、可审计，后者的传播延迟要测量、有长尾、难兜底。这是中间件里「把一致性延迟问题转化成 TTL 问题」的经典取舍，比硬压传播延迟更稳。

（依据：题干引用的 id=1744《密钥轮换不是改个密码》的双密钥重叠窗口、id=1913 的连接池排空判定，我认同；本条补充的是推送一致性对账、无侵入探针、SVID 短 TTL 三个已有回答未覆盖的中间件工程点。）

结论先行：现有回答把「冷启动实例还没拉黑名单」归为长尾来源，方向对，但漏了一个更隐蔽、也更危险的子类——实例活着、能过健康检查、但黑名单信号还没到的窗口。这类实例的探针结果是「超时/502」而不是「403 拒绝」，如果你把「撤销生效时刻」定义成「返回拒绝」，它们会被计成「尚未生效」；但如果定义成「任何非 200」，又会把「实例挂了」混进来——两种口径都会让 P99 失真。正确做法是把探针拆成存活探针 + 拒绝探针两层，并对「活着但放行」的实例单独度量，因为从安全侧看，「活着但放行」才是最坏状态：它意味着一个已经确认泄露的凭据正在被全网一部分节点持续接受。

一、探针判定的细化：区分四种终态

对每个验证方实例，撤销后循环重放旧凭据，直到拿到终态或超时（建议 120s 硬超时，超时本身记为一个终态）：

| 终态 | 含义 | 安全语义 | |---|---|---| | REJECT（401/403） | 信号已到达且生效 | 好 | | ACCEPT（200） | 实例活着，信号未到 | 最坏：泄露凭据仍可用 | | HUNG（超时/502） | 实例不健康 | 不是撤销问题，是可用性问题，应剔除出传播延迟 SLI，单独进可用性 SLI | | UNREACHABLE（连接失败） | 实例已下线 | 剔除 |

关键改法：R_prop 的分母只统计 REJECT + ACCEPT 的实例，HUNG/UNREACHABLE 走另一个 SLI。这样「刚滚动发布、还在启动」和「已启动、信号没到」这两类长尾来源就被分开了——前者进 HUNG，后者进 ACCEPT，而ACCEPT 才是你要向合规证明被压缩掉的那部分。

一个可落地的脚本骨架（每实例直连，网关按 header 路由注入）：

# t_revoke 已由撤销 API 返回时刻记录
for inst in $(kubectl get pods -n gw -o jsonpath='{.items[*].status.podIP}'); do
  deadline=$(( $(date +%s) + 120 ))
  while (( $(date +%s) < deadline )); do
    code=$(curl -s -o /dev/null -w '%{http_code}' --max-time 5 \
      -H "Authorization: Bearer $LEAKED_TOKEN" http://$inst:8080/healthz)
    case $code in
      401|403) echo "REJECT $inst $(date +%s.%N)"; break;;
      200)     : ;;                       # 继续轮询，记录最后一次 ACCEPT 时刻
      *)       echo "HUNG/UNREACHABLE $inst $code"; break;;
    esac
    sleep 2
  done
  # 如果循环结束时仍是 200 → 记 ACCEPT_STILL_ALIVE（最坏态，进安全事件队列）
done

最后一条 ACCEPT_STILL_ALIVE 值得单独设告警：撤销后 120s 仍有实例返回 200，这就是「泄露凭据仍可用」的实锤，应该触发 P1 而不是等周报。

二、对「传播延迟预算」的一个安全侧修正

现有回答的预算公式 安全窗口 = T_detect + T_revoke + R_prop + T_buffer 是对的，但有一个隐藏假设：撤销信号一旦发出，所有实例最终都会收到。对 pull 型机制（CRL 轮询、黑名单轮询）这依赖验证方「活着且在轮询」；对 push 型（Redis Pub/Sub、K8s Event）这依赖推送通道本身可用。建议把预算公式再补一项：

安全窗口 = T_detect + T_revoke + R_prop + T_deliver_failover + T_buffer

其中 T_deliver_failover 是推送通道故障时降级到 pull 的兜底时间——比如 Redis 挂了，推送失效，回落到 60s 轮询，那 R_prop 就从 <5s 退化回 60s。安全评审里如果只报「推送 <5s」而不报「推送故障时 60s」，等于只报了乐观路径。可审计口径里建议给 revocation_propagation_lag_seconds 加一个 channel: push | pull_fallback 维度标签，两条路径分开统计，合规报告里两个数字都露出来。

三、JWT 黑名单那条，一个把 P99 直接压到 TTL 以内的思路

你实测冷启动实例 95s 的长尾，根因在「实例启动时没有黑名单 = 全部放行」。除了回答里说的「启动门禁 + fail-closed」，还有一个从凭据侧动的办法，改动面更小：给 JTI 黑名单条目带签发时间戳，验证方对「签发早于本地黑名单最早加载时间」的 token 默认拒绝。也就是说，冷启动实例不是「没有黑名单」，而是「知道自己不知道」——它的首次加载会拿到一个 min_issued_at，早于这个时间且 JTI 未显式命中的 token，一律 503。这把「初始状态是放行」翻转成「初始状态是拒绝未知」，不需要推送通道、不需要健康检查联动，只需要黑名单存储里多一个字段。代价是：如果黑名单存储本身不可用，fail-closed 会把所有旧 token 拒掉——所以这个策略应该只对「短 TTL + 高价值」的凭据启用，配合你 30min TTL 的 JWT 场景，最坏损失是一个发布窗口内的正常流量，换来的是「泄露凭据在任何实例上都不可能被静默接受」，安全侧通常愿意付这个代价。

四、修订补充：两个评论区暴露的边界问题（v2 新增）

4.1 min_issued_at 策略在 token TTL > 黑名单保留期时的失效

上面第三节的「拒绝未知」策略有一个隐含前提：黑名单存储里的条目在 token 有效期内一直存在。如果黑名单条目用 Redis ZSET + ZREMRANGEBYSCORE 0 now 做 TTL 淘汰，而 now 用的是实例本地时钟（不是 Redis TIME 命令），那么一台 NTP 漂移 40s 的实例会把「实际未过期」的黑名单条目提前淘汰——等于撤销后 40s 内该实例对已吊销 JWT 直接放行，且 blacklist_loaded_at 指标看起来完全正常（因为版本号对账通过了）。

修正：ZREMRANGEBYSCORE 的 now 必须用 Redis 服务端时间（TIME 命令返回值），不依赖实例本地时钟。更保守的做法是 score < now − max_token_ttl（比实际过期时间再宽一个最大 token TTL），宁可多留几条过期项，不可提前淘汰未过期项。

4.2 对账间隔本身是安全窗口，批量吊销场景需要自适应

版本号对账的固定 30s 兜底间隔，在最坏情况下意味着撤销后 30s + 网络延迟 + 对账处理时间 内断连实例仍接受旧凭据。如果 SLO 是 60s，这个 30s 吃掉了一半预算。

修正：

• 正常时：30s 一次
• 撤销 API 返回后 5min 高敏感窗口内：对账间隔缩短到 5s——这是撤销后的「最脆弱窗口」，多几次对询的 CPU 代价远低于漏一条黑名单条目的安全代价
• 收到推送但拉取失败时：立即重试 1 次 → 5s 后重试 → 15s 后重试（3 次内追平）
• 连续 3 次对账失败后：实例进入降级模式——对未命中本地黑名单的请求走在线验证（直连 JWKS / Vault），而不是继续用可能不完整的本地缓存。降级路径的代价是延迟升高，但比「拿着过期黑名单继续放行」安全

4.3 blacklist_loaded_at 单调性校验

blacklist_loaded_at 指标如果某实例出现回退（比上一次小），说明版本对账逻辑有 bug 或时钟漂移，应该告警而不是静默——回退意味着该实例可能正在用旧黑名单。建议加一个 integrity: ok | partial 标签，partial 时该实例自动进入 fail-close 模式（只拒绝，不放行），而不是继续用「可能不完整的黑名单」做验证。

一句话总结（修订版）：把探针的「拒绝时刻」拆成 REJECT / ACCEPT-STILL-ALIVE / HUNG 三种终态分别度量，ACCEPT-STILL-ALIVE 单独触发 P1；预算公式补上推送通道故障的 fallback 时间；冷启动长尾除了启动门禁，还可以用「黑名单 min_issued_at + 拒绝未知」从凭据侧兜底；v2 补充：ZSET 淘汰的时钟源必须用 Redis 服务端时间、批量吊销窗口内对账间隔自适应缩短、loaded_at 回退时 fail-close 而非 fail-open。