中转站 API Key 安全：从生成到销毁的完整流程

中转站的 Key 和官方 Key 有一个关键区别：官方 Key 通常绑定一个账号、一套配额；中转站的 Key 往往能调它池子里的所有模型，一旦泄露，损失上限等于账户余额，而不是某个模型的额度。所以中转站的 Key 管理要更严。

一、Key 的命名

命名要能回答三个问题：哪个环境、哪个服务、谁负责。

推荐的格式：{env}-{service}-{owner}-{yyyymm}，例如 prod-agent-billing-alice-202611。好处是泄露时你能一眼看出影响范围，也能按月份批量清理。

不要用 test、key1、apikey 这种名字。半年后你无法判断哪个能删。

二、Key 放在哪

按优先级从高到低：

1. 密钥管理服务（云厂商 KMS、Vault、1Password Secrets Automation）。应用运行时拉取，不落磁盘。
2. 环境变量，由部署平台注入。不要在 .env 里提交到 git。
3. 本机配置文件，权限 600，且不在任何同步目录里。
4. 绝对不要：写进代码、写进前端 bundle、贴进 issue、贴进聊天记录、写进日志。

一个常被忽略的点：很多框架在报错时会把请求头打进日志。确认你的日志中间件对 Authorization 做了脱敏，否则一次 401 就能把 Key 写进日志系统。

三、一个服务一把 Key

不要多个服务共用一个 Key，原因不是安全洁癖，而是可观测性：出问题时你需要知道是哪个服务在烧钱，共用 Key 之后这个信息就没了。

同理，测试环境和生产环境必须分开。测试环境的 Key 泄露不应该影响生产余额。

四、轮换周期

固定周期轮换（例如 90 天）的意义有限，真正有用的是事件驱动轮换：

• 有人离职，或参与过部署的人变更
• Key 出现在任何可能被记录的地方（截图、录屏、工单）
• 供应商侧通知数据泄露
• 账单出现无法解释的调用

固定周期作为兜底可以保留，但不要把轮换当成安全的主要手段。

五、泄露后的前 30 分钟

顺序很重要，不要先调查再处置：

1. 立刻吊销。在站点后台删除 Key。不要先建新 Key——旧的没删之前，建新的没有意义。
2. 建新 Key，权限最小化。如果站点支持按模型或分组授权，只开需要的。
3. 部署新 Key，走环境变量或密钥服务，不要临时改代码。
4. 查账单。看泄露窗口内的调用记录，重点看你不用的模型、你没见过的时段、异常大的 token 量。
5. 查来源。搜索仓库历史、CI 日志、工单系统。删掉文件不够，git 历史里的还要处理。

六、泄露检测的自动化

低成本做法：

• CI 加 secret scanner（gitleaks、trufflehog）。在 pre-commit 和 PR 两个环节都跑。
• 给 Key 加可识别前缀，如果站点支持。这样 scanner 能精确匹配。
• 账单告警。日消费超过阈值就通知，这能兜住大部分"Key 被拿去刷"的情况。

七、Key 指纹的用法

需要向别人描述一把 Key 又不想泄露时，用"前 4 位 + 后 4 位 + 长度"，例如 sk-a…7f2c，48 位。不要贴中间部分，也不要贴完整 Key 的前 20 位——很多站点的 Key 前缀包含账号信息。

本站检测台只保留 Key 的后六位作为指纹，用于你之后核对"这次测的是哪把 Key"。

八、一个检查表

• [ ] 每个环境、每个服务独立 Key
• [ ] Key 只在密钥服务或平台环境变量里
• [ ] 日志对 Authorization 脱敏
• [ ] CI 有 secret scanner
• [ ] 账单有日消费告警
• [ ] 有人离职时轮换
• [ ] 泄露预案写在文档里，且有人知道

这张表全部做到的成本大约是一个下午。相比一次泄露烧掉的余额，这个投入不亏。