TheRouter.aiTheRouter.ai
← 全部文章

团队 LLM API 密钥管理：轮换、权限隔离与网关级密钥治理指南

一份面向多 Provider 场景的 LLM API 密钥管理实战指南——覆盖密钥蔓延、轮换策略、Vault 集成，以及如何通过路由网关合并上游凭据，让团队不再共享裸 Provider 密钥。

· TheRouter

一句话结论：团队使用多个 LLM Provider 时，最大的 API 密钥风险不是某一把密钥泄露——而是密钥蔓延。5 个 Provider × 3 个环境 × 4 个团队 = 60 把密钥散落在 .env 文件、CI Secret 和即时消息中。路由网关可以把这个矩阵压缩为：每个 Provider 一把上游密钥（集中管理）+ 每个团队一把网关凭据（可独立轮换），再配合密钥管理服务处理生命周期。本文逐步拆解实操方案。

为什么 LLM API 密钥比普通 API 密钥更难管

传统 SaaS API 密钥的管理虽然烦琐，但模式固定：一个 Provider、一把密钥、一个计费账户。LLM 场景打破了这一模式：

  1. 多 Provider 是常态。 生产环境通常至少路由到两个 Provider——一个主力、一个 fallback。OpenAI 用 GPT-5，Anthropic 用 Claude，中国区可能还要加上 DashScope 来调用 Qwen 模型。每个 Provider 的密钥格式、管理后台和轮换机制都不同。

  2. 密钥自带消费授权。 与只读的数据分析 API 密钥不同，LLM API 密钥授权的是 token 消费，单日开销可达数千美元。一把泄露的密钥不只是访问风险，更是账单风险。

  3. AI 编程工具放大了爆炸半径。 Cursor、Claude Code、Codex 等工具都需要凭据。当开发者把同一把生产密钥粘贴进 IDE 配置时，每台笔记本都变成了不受审计的入口。

第一步：盘点密钥清单

在修任何东西之前，先搞清楚手上有什么。对每个 Provider 回答以下问题：

问题需要记录的信息
有多少把活跃密钥？在 Provider 后台数一下
每把密钥存在哪里？环境变量、.env 文件、CI/CD Secret、配置文件、本地 IDE 配置
谁有访问权？团队级、个人级还是共享？
上次轮换是什么时候？从未轮换？半年前？不清楚？
是否设置了消费限额？按密钥还是按项目设限？

多数团队盘点后会发现，"谁有访问权"的答案是"密钥创建时在项目组的所有人"。这就是起点。

第二步：按环境隔离密钥

一把密钥跨 dev / staging / prod 共用（即"扁平密钥"反模式）会让轮换变得可怕——你无法在不影响生产流量的前提下测试新密钥。

解法： 在每个 Provider 上为每个环境分别创建密钥：

# 不要这样：
OPENAI_API_KEY=sk-prod-全组共享的那把

# 应该这样：
OPENAI_API_KEY_PROD=sk-prod-xxxxxxxx
OPENAI_API_KEY_STAGING=sk-staging-yyyyyyyy
OPENAI_API_KEY_DEV=sk-dev-zzzzzzzz

这样做有三个立竿见影的好处：

  • 安全轮换： 先轮换 staging 密钥，验证通过后再轮换生产。
  • 爆炸半径可控： dev 密钥泄露不会造成生产账单损失。
  • 可归因： Provider 用量面板能显示哪个环境产生了哪些流量。

OpenAI 支持项目级 API 密钥，可将密钥限制在特定模型和速率限额内。Anthropic 提供 workspace 级密钥隔离。DashScope 使用 RAM 策略为每把密钥设置访问控制。请善用各 Provider 的原生权限隔离能力。

第三步：将密钥迁入密钥管理服务

硬编码在 .env 文件中的密钥是隐患。密钥管理服务（Secrets Manager）能提供轮换自动化、访问控制和审计追踪：

密钥管理服务适合 LLM 密钥管理的关键能力
HashiCorp Vault动态密钥、基于 TTL 的自动轮换、细粒度 ACL 策略、可自托管
AWS Secrets Manager原生 Lambda 轮换、自动版本管理、跨账户 IAM 角色访问
GCP Secret Manager基于 IAM 的访问控制、自动复制、版本固定、Cloud Functions 轮换
Azure Key Vault证书和密钥生命周期管理、软删除保护、RBAC 集成

集成模式很直接：应用在启动时（或每次请求时，如果能接受延迟）从 vault 读取密钥，vault 按照你定义的计划自动轮换。

# 示例：运行时从 AWS Secrets Manager 读取 OpenAI 密钥
import boto3, json

def get_openai_key():
    client = boto3.client("secretsmanager", region_name="us-east-1")
    resp = client.get_secret_value(SecretId="prod/openai/api-key")
    return json.loads(resp["SecretString"])["OPENAI_API_KEY"]

第四步：在 Provider 前部署网关

即使有了按环境隔离的密钥和 vault，你仍然面临协调问题：每个调用 LLM Provider 的应用都需要知道该 Provider 的密钥、端点和轮换计划。使用 5 个 Provider 时，每个服务就需要 5 套凭据。

路由网关消除了这个问题：

之前（N 个应用 × M 个 Provider = N×M 组密钥）：
  应用 A → OpenAI 密钥, Anthropic 密钥, DashScope 密钥
  应用 B → OpenAI 密钥, Anthropic 密钥, DashScope 密钥
  应用 C → OpenAI 密钥, Anthropic 密钥, DashScope 密钥

之后（N 个应用 × 1 个网关凭据）：
  应用 A → 网关凭据（team-a-prod）
  应用 B → 网关凭据（team-b-prod）
  应用 C → 网关凭据（team-c-prod）
  网关 → OpenAI 密钥, Anthropic 密钥, DashScope 密钥（集中管理）

网关在一处持有所有上游 Provider 密钥。应用只需用一把按团队和环境隔离的网关凭据来认证。当某个 Provider 密钥轮换时，只需在网关侧更新一次——不需要重新部署任何应用。

OpenAI 兼容指供应商提供一个 chat-completions 接口，其请求与响应结构与 OpenAI API 契约足够接近——只需替换三个值（API key、base URL、模型名），原来的 OpenAI SDK 调用即可直接工作。最小实践面是POST /v1/chat/completions 带 messages、model， 并返回 OpenAI 形式的流式响应。

因为网关暴露的是 OpenAI 兼容端点，应用甚至不需要知道实际由哪个上游 Provider 处理请求。同一个 base_url + 网关凭据，无论请求路由到 OpenAI、Anthropic 还是 DeepSeek，都能正常工作。

第五步：用双密钥重叠模式轮换

最安全的轮换方式是在过渡窗口内同时保持新旧两把密钥有效：

时间线：
  T+0    在 Provider 后台生成新密钥（KEY_B）
  T+0    将 KEY_B 添加到 vault / 网关中，与 KEY_A 并存
  T+1h   验证 KEY_B 可用（发送测试请求）
  T+24h  将所有消费端切换到 KEY_B
  T+48h  在 Provider 后台吊销 KEY_A

48 小时宽限期很重要，原因如下：

  • 长期运行进程中缓存的旧凭据会自然过期。
  • CI/CD 流水线中缓存的旧密钥会在下次运行时获取新值。
  • 如果 KEY_B 出现问题，可以在不宕机的情况下回滚到 KEY_A。

必须立即轮换的场景（不设宽限期）：

  • 密钥确认泄露到公开仓库。
  • 检测到异常消费飙升。
  • 持有密钥访问权的团队成员离职。

SOC 2 和 ISO 27001 通常要求每 90 天轮换一次。对于具有高消费授权的 LLM 密钥，我们建议 30–60 天。

第六步：建立审计日志和告警

最后一步是可见性。你需要随时回答三个问题：

  1. 谁在发请求？（哪个团队、哪个应用、哪个环境？）
  2. 花了多少？（按密钥、按天、按模型？）
  3. 有没有异常？（dev 密钥突然飙量？来自异常 IP 的请求？）

配备可观测性功能的网关可以在不改造应用的前提下提供这些信息。每个网关凭据映射到一个团队和环境，因此每个请求自动带上标签。

建议设置的告警：

  • 消费阈值突破 — 按密钥的日/周上限。
  • 异常请求模式 — 突然的流量飙升、访问了新模型、非工作时间的请求。
  • 认证失败 — 重复的 401 可能意味着某处仍在使用已吊销的密钥。
  • 密钥年龄超期 — 密钥超过轮换期限时自动提醒。

常见错误及规避方式

错误为什么会犯解法
密钥写进源码开发者在原型阶段复制密钥后提交了 .envpre-commit 钩子（如 gitleaks、trufflehog）+ 仅限 vault 的策略
跨环境共享密钥"staging 跑通了，直接上线"按环境隔离密钥，网关强制执行
没有轮换策略"需要的时候再轮换"日历提醒 + vault TTL = 强制轮换
没有吊销预案密钥泄露 → 恐慌 → 新密钥发给谁？Runbook：生成新密钥 → 更新 vault → 验证 → 吊销旧密钥，全程 1 小时内完成
权限过大的密钥一把密钥能访问所有模型使用 Provider 原生隔离：项目密钥（OpenAI）、workspace 密钥（Anthropic）、RAM 策略（DashScope）

上线检查清单

在发布 LLM 驱动的功能前，用这份清单做 go/no-go 判断：

  • 每个 Provider 密钥都存储在密钥管理服务中（不在 .env，不在 CI 环境变量）
  • 密钥按环境隔离（dev / staging / prod）
  • 在 Provider 支持的范围内按团队或应用隔离密钥
  • 有轮换计划并严格执行（≤ 90 天，理想值 30–60 天）
  • 轮换使用双密钥重叠——不搞一刀切
  • 有吊销 Runbook 且已测试过
  • 在 Provider 层面按密钥设置了消费限额
  • 网关合并了上游密钥——应用只持有网关凭据
  • 审计日志按团队、应用、环境和模型维度记录每次请求
  • 对消费飙升、认证失败和密钥超龄设置了告警

TheRouter 集成

TheRouter 通过配置的 Provider 路由 OpenAI 兼容请求，天然承担了本指南中描述的网关角色。应用使用一个 TheRouter 凭据认证，TheRouter 持有 OpenAI、Anthropic、DashScope、SiliconFlow 和 DeepSeek 的上游密钥。

当某个 Provider 密钥轮换时，只需在 TheRouter 配置中更新——无需修改任何应用。结合 fallback 路由，即使某个 Provider 的密钥被吊销，你的应用也不会中断：流量会自动 fallback 到下一个配置的 Provider，同时你配置新密钥。

对于已经在使用 vault 的团队，模式是：vault 存储 Provider 密钥 → TheRouter 在配置时读取 → 应用使用按团队隔离的网关凭据调用 TheRouter。一个 vault、一个网关、每个团队一把凭据。

延伸阅读

客服支持