密钥泄露后先别点轮换：真正该吊销的，往往不是泄露的那个

凌晨两点十四分，一个 CI 任务报 401 失败。开发者把日志最后六十行贴进模型对话里问原因，而这段日志恰好包含了一次环境变量转储泄露出来的 runner 注册令牌。泄露就发生在这一刻，后面全是流程问题。

两点四十分，值班工程师吊销了 runner 令牌。直觉是对的，范围是错的。九点整，一台陌生主机注册了一个 runner——不是吊销失效，而是那个能签发 runner 令牌的 CI 个人访问令牌根本没被动过。攻击者从来不需要泄露出来的那个值，他需要的是它的父级。

所以真正该问平台团队的问题是：如果密钥在两点十四分落进了提示词，你的应急手册在两点四十一分会做什么，按什么顺序做？

多数手册的答案是"全部轮换"，然后就没了。顺序才是决定遏制要花四分钟还是四小时反复泄露的部分。

先画图，再写手册

提示词本质上是一条保留期未知的日志行。接受这一点之后，问题就不再是"我们泄露了一个密钥吗"，而是"现在存在几份副本，其中哪几份还能签发新的"。签发能力通常位于泄露点的边界另一侧，这正是"轮换泄露的那个叶子节点"感觉上奏效的原因。

把清单维护成 CSV 边表，因为它在 PR 里 diff 干净，也能扛住 wiki 迁移。一条边表示"左边能签发或替换右边"：

• ci_github_pat → repo_deploy_key
• ci_github_pat → ci_runner_reg_token
• ci_runner_reg_token → runner_ephemeral_token

三条边就足以抓住那个跑步机式的死循环。每新增一条签发路径就加一行：令牌到令牌、令牌到密钥、密钥到证书、组织管理员到任何东西。

算遏制顺序，而不是列轮换清单

一个只用标准库、零依赖的脚本，对上面这张图跑出来的结果是这样的：

guard : ci_github_pat
contain: ci_github_pat -> ci_runner_reg_token -> runner_ephemeral_token
restore: runner_ephemeral_token -> ci_runner_reg_token -> ci_github_pat

这个输出有点反直觉：第一个要吊销的，是没被泄露的那个。先杀签发者，再杀叶子，再杀叶子的叶子。恢复时方向相反，让依赖它的任务先回来，父级再开始签发替代品。

如果先轮换叶子，就会踩上跑步机：吊销、重签、再吊销、再重签，然后是一个很长的夜。

遇到环就老实承认

脚本遇到环会直接失败退出，而环是真实存在的——一个有权签发令牌的组织管理员令牌，在某些配置下能签发自己的兄弟节点。这时候诚实的答案是：顺序算不出来，手动吊销整个环，接受停机，然后拆掉这个签发回路，让下一次事故可计算。一张说谎的图比没有图更糟。

脱敏保留形状，别毁掉诊断价值

"别把密钥发给模型"是建议，不是控制措施。控制措施是一个脱敏器，它保留足够多的形状信息，让模型还能帮上忙。用正则匹配 AWS 访问密钥 ID、GitHub 令牌、私钥头和 Bearer 头，命中就替换成带类型标签的占位符。

负向测试用例比正向的更重要。一个会把 git SHA 也吃掉的脱敏器会摧毁调试价值，一周之内就会被人关掉。四十位十六进制 SHA、UUID、摘要标签，这些都必须保持可读。

有一个取舍要明说：为关联保留末四位，对四十字符的高熵令牌说得过去，对内部主机名这类低熵字符串就说不通。按形状逐个决定，别按政策段落一刀切。

证明吊销生效，别假设

这是所有人都会跳过的一步。没有证据行就没有闭环。"我轮换过了"是一个主张，一个 401 才是一条记录。

也不是每一次泄露都值得开事故。中间那两档才是团队消耗信任额度的地方：对每一个信号都全量轮换，会把人训练成忽略告警。

免费额度改变了什么，没改变什么

免费模型访问和免费服务器选项这两条可用性说法，都按运营方提供的信息处理，配额和条款变得比文章还快，自己去核对当前条款。

这两者都不是安全控制。它们只在一个具体方向上改变了你的威胁模型：一个免费的托管工作区在你的网络边界之外，你的出口规则、磁盘加密、日志管道都不再适用于跑在那里的那份副本。所以往里面贴任何东西之前，有三条规则：

• 工作区里不放长期凭证，改为运行时注入短期的、限定范围的令牌。
• 假设工作区文件系统和对话记录的生命周期长于你的会话，把记录导出到你能擦除的存储里。
• 既然试错不要钱，就没有预算借口跳过脱敏。先跑脱敏器，再粘贴。

免费访问的意义在于，小团队可以在真实事故之前，把遏制流程完整排练一遍。

这周就能跑的二十分钟演练

1. 建一个 edges.csv，写进三条你确认属实的签发路径。
2. 挑一个叶子凭证，对它跑一遍排序脚本。如果它打印出了 guard，你刚找到了手册里的洞。
3. 把脱敏测试的负向用例加进 CI，四个就够起步。
4. 拿一条真实的失败日志过一遍脱敏，确认模型仍然能回答你的问题。
5. 按凭证类型，写好事故时要截图的那条证据行。
6. 把脚本和图钉在仓库里手册旁边，让手册可以被重新生成，而不是靠记忆。

什么时候该跳过这套东西

凭证少于大约八个？跳过图，全部轮换然后去睡觉。图在规模和部分权限模型下才回本。没有清单？脚本只认识你敲进去的边，一张过期的图是虚假的自信，信任输出之前先去 CI 配置里 grep 一遍凭证创建。变更审批很重？图就变成工单附件，用 dry-run 模式跑，把遏制顺序贴上去，让审批和第一次吊销并行。受监管环境有逐凭证的事故文书？这个工具不替代你的流程，它只是给流程重新排序。

诚实的总结是：遏制是一个穿着手册外衣的图问题，而泄露出来的那个密钥，几乎从来不是第一个该吊销的东西。

那么该往 CI 里放哪条不变量："没有脱敏记录，任何密钥形状不得离开 runner"，还是"每一个有签发能力的凭证都有记录在案的父级"？我会从第二条开始——因为第一条只会失败一次，而第二条会在每一次有人按错顺序点轮换时失败。