OpenAI API Key 如何安全保存和轮换？
简答：一句话结论：OpenAI API Key 应只保存在后端环境变量、CI/CD Secret 或密钥管理服务中，不能随前端应用发布，也不能提交到仓库。轮换时先创建替代 Key，更新并验证应用，再撤销旧 Key；如果已经泄露，应先撤销或轮换，再检查用量、日志和代码历史。本文按本地开发、CI/CD、生产环境给出可执行流程。
定义：OpenAI API Key 安全管理，是指对密钥进行隔离存储、最小化使用范围、用量监控、定期替换和泄露后的撤销处置。
先看保存方式：本地、CI/CD、生产环境怎么选
先做这一步：确认 API 请求是否从浏览器或移动 App 直接发出。如果是，应改为由自己的后端转发请求；OpenAI 明确不建议把 API Key 部署到浏览器或移动应用中，因为用户可以提取密钥并代为发起请求。
| 使用场景 | 推荐保存位置 | 不要采用的方式 | 核验重点 |
|---|---|---|---|
| 本地开发 | 操作系统环境变量，例如 OPENAI_API_KEY | 写死在源码、提交到仓库、放进前端代码 | 确认程序能读取变量，但不要把完整 Key 打到终端或日志 |
| CI/CD | 平台提供的加密 Secret，并按仓库或环境限制访问 | 写进工作流文件、命令参数或构建产物 | 检查日志脱敏、分支权限和生产环境审批 |
| 生产后端 | 密钥管理服务或云平台 Secret | 写进镜像、配置文件、聊天记录或错误上报 | 限制读取主体，记录使用情况并设置轮换流程 |
| 浏览器或移动 App | 不直接保存 OpenAI API Key；改由后端代理调用 | 把 Key 放入 JavaScript、移动端包或公开配置 | 检查构建产物、网络请求和源码是否包含密钥 |
OpenAI 的官方建议包括使用环境变量、为生产环境考虑密钥管理服务、按成员或项目使用不同 Key，并结合用量监控、支出限制和网络控制。具体控制台选项应以当前 OpenAI 文档和账户页面为准。
本地开发：用环境变量代替硬编码
本地开发的目标不是让密钥“消失”，而是让密钥不进入源码、版本历史和可分享文件。OpenAI 官方建议使用名为 OPENAI_API_KEY 的环境变量。
- 在当前操作系统或开发环境中设置
OPENAI_API_KEY。 - 代码通过运行时环境读取该变量，而不是把实际 Key 写进 Python、Node.js 或配置文件。
- 将本地变量文件加入忽略规则，不要提交到 Git 仓库。
- 检查启动脚本、调试输出、异常堆栈和 HTTP 日志，确保不会打印完整密钥。
- 如果曾经把 Key 写进源码或提交记录，不要只删除文本：先撤销或轮换密钥，再决定是否清理仓库历史。
Python 读取环境变量的最小形态可以是：
import os
api_key = os.environ["OPENAI_API_KEY"]这段代码只展示读取方式，不代表可以把 Key 放在前端。浏览器、移动 App 和其他用户可控制的客户端都不应持有服务端 API Key。
如果使用 GitHub，可以启用 Secret scanning 检查已提交内容和 Git 历史中的凭据。GitHub 文档同时提醒：发现泄露后应先轮换凭据；仅重写历史并不能让已经复制到其他克隆、分支或缓存中的内容自动消失。
参考：GitHub Secret scanning、从仓库移除敏感数据。
CI/CD 与生产部署：从环境变量迁移到 Secret
环境变量适合本地开发和简单部署，但生产环境通常需要更细的访问控制、审计和轮换能力。OpenAI 官方建议生产部署考虑使用密钥管理服务；如果使用 GitHub Actions，则应使用 GitHub Secrets，而不是把值写在工作流 YAML 中。
- 按环境拆分 Secret，例如开发、测试、生产分别管理，不让测试工作流默认读取生产密钥。
- 按应用、项目或服务拆分 Key，避免所有服务共用一个个人 Key。
- 只给需要调用 API 的部署主体读取权限，避免把 Secret 暴露给不相关的构建步骤。
- 检查构建日志、错误上报、APM 标签、容器环境和产物压缩包，确认没有完整 Key。
- 在部署前用不包含密钥值的方式验证变量是否存在，例如只检查是否为空，不输出变量内容。
- 保存轮换记录：替换时间、受影响服务、验证结果和旧 Key 撤销时间。
GitHub Actions Secret 可以按仓库、组织或环境管理；环境级 Secret 适合把生产凭据与测试凭据分开。具体权限和可用范围取决于当前仓库设置，部署前应在对应平台文档和项目配置中核对。
参考：GitHub Secret 类型、GitHub Actions Secrets 参考。
OpenAI API Key 轮换：推荐的无中断流程
OpenAI 官方给出的基本顺序是：在旧 Key 过期前创建替代 Key，更新应用，确认替代 Key 正常工作后撤销旧 Key。下面是适合后端服务的实施流程；其中新旧 Key 是否能在当前账户或项目中同时保留，需要以当前控制台能力为准。
- 盘点使用位置：列出本地环境、CI/CD、生产实例、容器、定时任务和临时脚本，确认旧 Key 被哪些服务读取。
- 创建替代 Key：优先使用项目级或服务用途独立的 Key，并在支持的情况下设置到期时间和必要的权限。
- 先更新 Secret：把新值写入密钥管理服务或部署平台，不要通过聊天、工单或命令行参数传递。
- 灰度验证：重启一个实例或测试环境，执行最小 API 请求，检查 HTTP 状态、响应体和应用日志是否正常。
- 逐步发布：将新配置发布到剩余实例，观察请求是否仍然成功、用量是否符合预期。
- 确认旧 Key 不再使用：如果平台提供按 Key 或项目查看用量的能力，可结合用量记录判断；如果无法区分流量，应以部署完成和应用验证为依据，不要把“没有报错”当成绝对证明。
- 撤销旧 Key：确认没有回滚实例仍依赖旧值后删除或撤销旧 Key。
- 复盘：更新密钥清单、轮换日期、责任人和下次检查时间。
轮换不是普通重试，也不是断点续传。它的目标是更换凭据并验证应用恢复，而不是重复发送失败请求。
疑似泄露后的应急 Runbook
如果 Key 出现在公开仓库、前端构建产物、日志、截图、聊天记录或第三方工单中，应按“先止血、后清理”的顺序处理。
- 立即删除或撤销受影响的 Key：不要等待确认是否已经被使用。OpenAI 官方建议疑似泄露时立即轮换或删除受影响密钥。
- 检查用量：查看是否出现无法解释的请求、异常时间段或异常消耗，并保存必要的时间、项目和请求记录。
- 创建替代 Key：将新 Key 写入后端 Secret 或密钥管理服务，不要沿用已经暴露的值。
- 更新并验证所有部署：包括生产实例、CI/CD、容器、定时任务和本地脚本。
- 清理暴露位置：删除公开文件、日志、截图和工单中的密钥；如果进入 Git 历史，评估是否需要在轮换后清理历史，并通知已有克隆的协作者。
- 检查自动扫描：对仓库、Issue、Pull Request、构建日志和镜像进行 Secret 扫描。
- 联系 OpenAI 支持：如果存在未授权使用或账户安全疑虑，保留事件信息并通过 OpenAI Help Center 联系支持。
关键点是：清理仓库文本不能替代撤销 Key。GitHub 文档指出，历史重写可能影响提交哈希、分支、Pull Request 和其他协作者的克隆，因此应在凭据已经失效后再谨慎处理。
参考：OpenAI 账户安全与疑似泄露处理、GitHub 泄露 Secret 修复流程。
发布前安全自查清单
- 客户端：浏览器、移动 App 和前端构建产物中没有 OpenAI API Key。
- 代码：源码、配置样例、测试数据和 Git 历史中没有真实 Key。
- 日志：Authorization 头、环境变量、错误对象、APM 标签和截图不会显示完整密钥。
- 权限：不同项目、服务和环境没有无必要地共用同一个 Key。
- 部署：生产密钥由 Secret 或密钥管理服务注入，而不是写入镜像。
- 监控：已设置用量检查、预算或支出提醒，并知道从哪里查看异常活动。
- 轮换：有替换、验证、撤销旧 Key 和回滚的书面步骤。
- 应急：团队知道谁负责撤销、谁负责更新部署、谁负责检查仓库和用量。
如果你只能先完成三项：先移除前端 Key，再把生产 Key 移入 Secret 管理，最后建立“新 Key 验证成功后撤销旧 Key”的轮换流程。
常见问题
OpenAI API Key 可以放在前端 JavaScript 里吗？
不建议。浏览器中的代码和网络请求可以被使用者查看，密钥可能被复制后代为调用 API。更安全的做法是让前端请求自己的后端，由后端保存并使用 OpenAI API Key。
本地开发一定要使用 Secret Manager 吗？
不一定。个人本地开发可以先使用操作系统环境变量，并避免把变量值打印到终端、日志或仓库。生产环境和多人协作项目则应根据平台能力考虑使用 Secret 或密钥管理服务，并限制读取权限。
把 API Key 从 Git 文件中删除后就安全了吗？
不一定。如果 Key 曾经提交到 Git 历史、公开仓库、Issue、Pull Request 或其他克隆中，删除当前文件并不能让旧值自动失效。应先撤销或轮换 Key，再根据仓库情况处理历史和其他副本。
OpenAI API Key 多久轮换一次？
官方建议建立定期轮换流程，并优先使用带到期时间的项目密钥；具体周期取决于项目风险、部署频率和当前控制台能力。无论固定周期如何设置，只要怀疑泄露，都应立即撤销或轮换。
轮换时如何避免服务中断？
先创建替代 Key，更新 Secret，选择一个实例或测试环境验证，再逐步发布到生产实例。确认旧配置不再被使用后撤销旧 Key。如果当前平台不支持新旧 Key 并存，应先安排短暂切换窗口，并准备回滚到仍有效的配置。
OpenAI API Key 泄露后第一步做什么？
第一步是立即删除或撤销受影响的 Key，而不是先清理 Git 历史。随后检查 API 用量，创建替代 Key，更新所有部署，清理泄露位置，并在需要时联系 OpenAI 支持。