API 密钥泄露怎么办？从紧急止损到安全恢复的实操指南

API 密钥泄露，可能始于一次截图、一段演示代码，或一份误提交的配置文件。真正需要处理的，是这把密钥仍然能否被使用、它能访问哪些资源，以及业务怎样恢复到可控状态。

这篇指南面向使用 AI 接口的个人开发者、小团队和网站运营者。你可以按顺序执行，也可以让团队成员并行完成止损、证据留存和配置排查。各平台的控制台名称和能力不同，具体操作以服务商说明为准。

一、先判断：这是凭据泄露，还是普通报错？

调用失败、余额减少、出现陌生 IP，都值得调查，但单独一项通常不足以确认泄露。正常的自动重试、服务器出口变化、团队新任务，也可能造成看起来异常的记录。

另一方面，完整密钥已经出现在公开仓库、公开网页或不可信接收者手里，即使暂时没有异常账单，也应按已暴露处理。没有看到滥用记录，不能证明密钥仍然安全。

把两个问题分开：“凭据是否暴露”决定是否立即撤销；“是否被使用、损失多大”需要结合日志、账单和业务记录继续核实。

AI 服务密钥的风险也不只在费用。它能做什么，取决于所属项目、角色和接口权限：可能只是调用模型，也可能涉及文件或其他项目资源。评估影响时，应检查实际授权范围，避免凭密钥名称推断权限。

二、紧急止损：让旧密钥失去访问能力

1. 找到密钥归属，撤销受影响凭据

确认密钥对应的服务商、组织、项目和使用环境。进入官方控制台撤销、删除或禁用它；不同平台的按钮不同，目标都是让旧密钥不能再授权新请求。

如果平台保留密钥标识、创建时间和状态，记录这些信息即可。不要把完整密钥复制进工单、群聊或事件报告，造成第二次扩散。

如果无法确认是哪一把密钥，可先依据创建时间、使用方和平台标识缩小范围，并联系项目管理员。不要为了避免影响业务，让一把已经公开的生产密钥继续有效。

2. 临时收缩业务入口

依赖旧密钥的功能可能立即报错。对用户可见的功能，可暂时提示“服务维护中”，暂停相关后台任务，或使用已有的安全降级方案。

重点检查重试机制：上游鉴权失败时，持续重试只会增加噪声，妨碍观察恢复情况。不要临时换成权限更大的共享密钥来掩盖故障。

3. 同步通知必要的人

小团队至少需要明确三件事：谁负责平台操作，谁负责应用配置，谁记录事件进展。同一人可以兼任，但每个动作应留下时间和结果。

如果密钥属于企业、客户或共享项目，尽快通知对应负责人；如发现无法解释的扣费或调用，携带脱敏后的请求标识联系服务商支持。费用争议是否能处理，需要由服务商结合证据判断，不能预先保证退款。

三、保留证据：建立一条能核对的时间线

证据留存可以与止损并行。若人手有限，优先撤销密钥，再继续导出记录。不要为了截图完整而延迟撤销。

建议建立一份内部事件记录，依次填写以下信息。

• 暴露窗口：最早可能公开的时间、发现时间、撤销时间，以及对应时区。注意，发现时间往往晚于实际暴露时间。
• 调用情况：受影响项目、密钥标识、请求时间、模型或接口、请求标识、成功与失败情况、用量和费用。来源 IP、地区和客户端信息仅在平台提供时记录。
• 业务对照：将平台记录与服务器日志、任务队列、发布记录及团队操作核对，区分正常流量、可疑流量和暂时无法判断的流量。
• 处置过程：记录谁在何时撤销凭据、修改哪些配置、暂停哪些任务，以及每次验证的结果。保留原始导出文件，分析时使用副本。

不要将包含提示词、用户输入或业务数据的日志直接发到公开渠道。向外部提供材料前，应去掉完整密钥和不必要的个人信息。

可复用的事件记录模板

1发现时间与时区：
2受影响项目 / 密钥标识（勿填完整密钥）：
3最早可能暴露时间：
4撤销时间与验证结果：
5已更新的服务 / 工具：
6异常调用与费用核对：
7当前负责人：
8待跟进事项与复查时间：

四、安全恢复：先堵住出口，再分批换钥匙

创建新密钥通常很快，确认它不会沿原路径再次泄露，才是恢复的关键。恢复前至少要知道：旧密钥已经撤销，已知泄露入口已经关闭，新密钥准备存放在哪里。

1. 按使用方建立替换清单

不要只修改本地配置。可以用“使用位置—负责人—是否更新—是否验证”四列建立清单，逐项确认。

• 线上服务：网站后端、容器配置、进程管理器环境变量、云函数、定时任务和后台工作进程。
• 开发与交付：开发机配置、测试环境、CI/CD 的秘密变量、部署平台设置，以及构建时读取配置的步骤。
• 个人与团队工具：编辑器插件、桌面 AI 客户端、自动化脚本、共享开发环境和其他已授权集成。
• 容易遗漏的位置：备用实例、停用但可被重新启动的任务、旧版部署配置、运维文档中的复制示例。

为每个实际使用方配置适当的凭据，避免再次让生产、测试和个人实验共用一把密钥。新密钥只授予该使用方需要的接口或资源权限。

2. 更新配置后，让真正运行的进程加载它

文件改好了，不代表进程已经使用新值。有些服务需要重启，有些部署平台需要重新发布，有些任务会在下一次启动时才读取配置。

因此，每更新一个使用方，就执行一次受控、低成本的正常请求，核对业务结果和平台记录。不要在终端输出完整环境变量来“确认配置”，也不要把密钥放进可能被保存的演示命令。

3. 避免把新密钥送回旧入口

如果旧密钥曾进入前端代码，单纯更换变量值会再次暴露。需要先调整调用方式，使长期服务端密钥留在受控后端，再恢复相关功能。

如果问题来自第三方工具同步配置，应先确认同步范围和凭据保存方式；如果来自公开日志，应先关闭或脱敏对应输出，再上线新配置。

完整取证可能持续更久。只要已确认受影响凭据失效、已知泄露入口关闭，并且恢复路径经过验证，就可以按业务重要程度分批恢复，同时继续调查其他潜在入口。

五、按暴露位置排查，避免同类问题再发生

公开仓库：删除当前文件后，还要考虑历史副本

修改最新提交，并不能让旧提交、克隆副本或已经下载的内容消失。凭据应先撤销；随后再评估是否需要清理 Git 历史、发布附件、构建产物或其他副本。

历史重写会影响提交标识和协作流程，应提前协调团队，不宜在没有备份和沟通的情况下直接强制推送。GitHub 的官方处理说明也明确要求优先撤销或轮换暴露的秘密。

前端页面：检查最终交付给浏览器的内容

配置名里带着“环境变量”，并不意味着它只存在于服务器。若构建工具将其写入浏览器脚本，访问者仍然可以看到。

检查打包后的脚本、公开配置文件、页面源码和可访问的构建附件。OpenAI 的官方安全建议明确指出，服务密钥不应部署在浏览器或移动客户端，应通过自己的后端发起请求。

后端接口也需要保护：校验登录身份、检查功能权限、限制用户调用频率和用量。否则，密钥虽然没有直接暴露，公开代理接口仍可能被滥用。

截图与日志：检查分享出去的实际内容

录屏、错误截图、聊天记录和支持工单，都可能包含配置窗口、请求头或调试输出。撤下可控范围内的公开内容，并修正日志脱敏规则；已经传播出去的副本无法靠删除原文件全部收回。

第三方工具：确认谁在保存凭据

检查工具是否将密钥保存在本机、云端或同步账户中，以及谁有权读取。不要仅凭“支持自定义 API”就默认其存储和访问控制符合团队要求。

六、费用防护：分清告警、限流与硬性上限

预算告警、速率限制和硬性支出限制解决的问题不同，配置前需要分别确认：

例如，OpenAI 的支出限制文档提供组织和项目层面的硬性限制说明。设置时仍应检查适用范围、计费口径和生效规则，不能仅凭一个“预算”字段就认定一定会自动停用。

团队可以设置分级告警，并明确收到提醒后的负责人和处置动作。对高成本功能，还应在自己的业务侧设置单次请求、用户用量或并发限制。

IP 白名单等措施可以缩小访问范围，但要先确认平台支持，并核实服务器的实际出口。动态出口和不同运行环境可能导致误拦截；这些措施也不能替代凭据撤销。

七、什么时候可以宣布恢复？

不要只以“网站又能用了”作为结束标准。至少逐项确认以下结果，并将其写入事件记录。

• ○
  旧凭据已失效：平台显示其已撤销或禁用；如需测试，使用受控环境和无敏感内容的最小请求，确认不能再通过鉴权。
• ○
  业务链路已恢复：所有应恢复的实例和任务都加载了新配置，正常请求成功，鉴权错误和重试噪声明显回落。
• ○
  泄露入口已关闭：已检查公开代码、构建产物、配置输出及相关分享位置，新密钥没有再次出现在这些位置。
• ○
  影响范围有记录：已核对已知暴露窗口内的调用与费用，无法解释的部分已经标记，并交由对应负责人继续跟进。
• ○
  后续观察有人负责：持续关注异常用量和新增告警。账单或使用量可能存在统计延迟，具体以平台说明为准。

八、把这次处置变成日常习惯

每把密钥都应有用途、负责人和撤销方式。开发、测试和生产分开管理，离职交接、工具停用和项目下线时同步清理不再使用的凭据。

将密钥放入受控的秘密管理设施或服务端配置中，限制读取权限，并避免出现在日志和构建输出里。环境变量是一种注入配置的方式，仍然需要配合访问控制和脱敏。

在代码提交和持续集成环节加入秘密扫描，可以提前发现误提交。团队还应保留一份不含秘密值的使用方清单，并定期演练更换密钥：知道要改哪里，比临时到处搜索更可靠。