API Key 安全管理：加密存储、权限最小化与轮换
作者：夸父
模型 API Key 是能直接花钱的凭据，管理不当轻则账单爆炸重则数据泄漏。本文给一套自部署环境下的 Key 安全实践：存储加密、子账号最小权限、泄露应急与轮换节奏。
Key 是什么级别的资产
一把模型 Key 等于一张"按量付费的信用卡"：泄漏后攻击者可以用你的额度消耗算力（生图、生视频都是烧钱大户），账单几天内可以到五位数。所以 Key 管理的安全等级应该按"能花钱的凭据"对待，而不是"一个配置字符串"。
存储加密：三层防线
应用层加密：逐日 AI 用 AES-256-GCM 加密存储 Key，主密钥放在服务器环境变量（ENCRYPTION_KEY）——数据库与 Key 分离，拖库读不出明文。
传输加密：管理后台到服务器的链路走 HTTPS，Key 不进 URL、不进前端日志。
服务器加固：服务器本身的 SSH 密钥登录、防火墙白名单——应用层加密再好，服务器被入侵就全白搭。
权限最小化：子账号拆分
在模型控制台用 RAM/子账号体系拆 Key：按环境拆（开发/生产各一套，开发的限额低）；按用途拆（文案/配音/生图可分账号）；按人拆（团队成员各持自己的 Key，离职吊销单人即可）。限额也要配：每个 Key 设月度用量上限，即使泄漏，损失也被上限框住。
泄漏应急四步
- 吊销：控制台立即吊销泄漏的 Key（第一动作，先于一切排查）；
- 换新：新 Key 配置进系统，恢复生产；
- 对账：查泄漏时段的账单与用量明细，评估损失；
- 溯源：确认泄漏渠道——代码仓库提交（用 git 历史扫描工具查）、日志输出、聊天窗口贴图、离职员工未吊销，堵住那个口子。
轮换节奏
没有泄漏也要定期换：生产 Key 建议季度轮换一次（低峰期操作，十分钟的事）；人员变动即时轮换；不同平台 Key 的有效期与政策不同，模型控制台的告警（余额/用量异常）是泄漏的第一道探测器——务必开启。
常见问题
Key 配置在系统里安全吗？
取决于系统的存储方式。逐日 AI 对 Key 做了 AES-256-GCM 加密存储（主密钥在服务器环境变量里），数据库被拖走也读不出明文 Key。要警惕的是明文存 Key 的方案和截图分享配置页的习惯。
Key 泄漏了第一件事做什么？
立刻在模型控制台吊销该 Key 并换新——止血优先于排查。然后再查账单确认损失、找泄漏点（日志、代码仓库、聊天记录里贴过 Key 是三大来源）。
多少人共用一个 Key 合理？
按"最小权限"原则拆：每个环境（开发/生产）独立 Key，团队场景按成员或用途建子账号 Key——出问题时能定位到人，吊销时不影响其他人。