API 密钥管理是什么
密钥泄露是 AI 应用最常见的安全事故：把密钥写进前端代码、提交进仓库、打进镜像层，都会让它对全网可见。正确做法是密钥只存在服务端环境变量或密钥管理服务里，按环境与用途拆分，逐个设置额度上限，定期轮换，并在提交前扫描防止误提交。已经泄露过的密钥必须立即作废重发，只改文件里的那一处并不安全。
基本信息
| 存放位置 | 服务端环境变量或密钥管理服务，绝不进前端与移动端 |
|---|---|
| 拆分原则 | 按环境与用途分别签发，一个用途一把密钥 |
| 额度控制 | 每把密钥设置用量上限，异常时可快速熔断 |
| 轮换节奏 | 定期轮换，人员变动与疑似泄露时立即执行 |
| 防误提交 | 提交前扫描代码库，仓库历史与镜像层同样要检查 |
| 泄露处置 | 直接作废并重新签发，同时排查调用记录 |
常见泄露场景与后果
| 场景 | 成因 | 后果 |
|---|---|---|
| 前端直连接口 | 密钥写进网页或小程序的请求里 | 任何人打开调试工具都能看到并使用 |
| 密钥进仓库 | 本地配置文件未加入忽略清单 | 仓库历史与分支长期留痕，扫描工具可批量发现 |
| 密钥进镜像 | 构建阶段把密钥写进镜像层 | 镜像分发范围越大泄露面越广 |
| 日志记录请求头 | 日志系统未对鉴权头脱敏 | 运维与日志平台都能看到密钥明文 |
| 多环境共用 | 测试与生产共用一把密钥 | 测试侧误操作直接影响生产额度与数据 |
治理要点
- 前端只调自有后端，由后端持有并注入真实密钥
- 把配置文件加入忽略清单，同时在提交前做密钥特征扫描
- 网关统一持有上游密钥，业务侧只携带内部令牌
- 按功能统计用量，突增时能定位到具体密钥与调用方
- 离职与转岗时把相关密钥纳入回收清单
安全使用与自查
安全使用与自查
# .env 只放服务端，并加入忽略清单
OPENAI_API_KEY=sk-... # 通过环境变量读取，不写进代码
# 提交前扫描常见密钥前缀，避免误提交
grep -rn "sk-[A-Za-z0-9]\{20,\}" . --exclude-dir=node_modules --exclude-dir=.git
# 检查仓库历史：已提交过的密钥必须作废，仅修改文件不够
git log -p | grep -n "api[_-]key" | head
# 镜像构建阶段不要通过构建参数传密钥，改由运行时注入密钥治理清单
| 环节 | 做法 | 检查方式 |
|---|---|---|
| 签发 | 按环境与用途拆分，最小权限 | 核对每把密钥的实际用途 |
| 存储 | 环境变量或密钥管理服务 | 确认代码与镜像里不含明文 |
| 使用 | 服务端注入，日志脱敏 | 抽查日志中的请求头字段 |
| 监控 | 按密钥统计用量与异常 | 配置用量突增告警 |
| 回收 | 定期轮换，人员变动即换 | 核对已失效密钥是否仍可调用 |
把密钥统一放在网关上是常见做法：业务侧不接触上游密钥，轮换时只改网关配置，影响面小且便于审计。
怀疑泄露时先作废再排查：留着有效密钥去分析调用日志，等于给攻击者留了一张仍在生效的门票。