大模型应用的密钥供给怎么做：LLM API Key 托管与向量库加密实践

摘要：当企业把大语言模型接入业务系统时，LLM API Key、向量库加密密钥、推理服务凭据等敏感凭据数量会随应用规模线性增长。把这些密钥写死在配置文件、环境变量或代码仓库里，是数据泄露事件中最常见的根因。本文从工程视角拆解 AI 大模型应用的密钥供给模型，说明密钥管理系统如何以硬件安全模块为基座实现密钥全生命周期托管与防泄露，并给出覆盖 API Key 托管、向量库加密、服务身份、审计与轮换的落地架构。 正在上传图片...

关键词：密钥管理系统、国密密钥管理、透明数据加密、密评合规、信封加密、GM/T 0051、后量子密码、数据加密方案、云上数据加密

一、为什么 AI 大模型应用把密钥管理逼到了墙角

传统应用一个服务只持有数据库口令和一对证书。但大模型应用本质是个"多密钥聚合体"：它要调用多家大模型厂的推理接口，每家签发自己的 API Key；它把私有知识灌进向量数据库做检索增强生成，向量库需独立加密密钥；它还要对接对象存储、消息队列、内部微服务，每个下游都是一组凭据。这些密钥"形状"差异极大：LLM API Key 是无结构长令牌，泄露即失效；向量库加密密钥是对称密钥，须保证明文不出可信边界；推理服务凭据是短期令牌，需频繁轮换。粗放管理迟早出事。

大模型应用的典型密钥清单：

大模型应用的密钥清单与三级密钥分级

这张表说明：密钥管理系统不再是"锦上添花"的合规部件，而是大模型应用能不能安全上线的底层能力。

二、AI 应用的密钥供给安全模型

2.1 三条不能妥协的原则

第一，密钥明文永远不离开可信执行环境。 工程上即硬件安全模块（HSM）。应用侧只拿到"用密钥算出的结果"或"被密钥加密后的密文句柄"，而非密钥本身，从根上切断"配置文件被拖库"事故。

第二，密钥与使用者身份绑定。 谁在何时用了哪把密钥，必须可追溯到具体工作负载、具体服务账户，否则无法追责。

第三，密钥有生命周期，而非"一次签发用终身"。 生成、激活、更新、归档、注销、销毁，每步都要有记录、有触发条件、可回滚。配套动作是明确每把密钥的 owner，让密钥资产台账与人员变动联动。

2.2 信封加密：大模型场景的核心技巧

向量库加密最易被做错。很多团队用一把主密钥直接加密全量向量，主密钥泄漏整库被一锅端。正确做法是信封加密（Envelope Encryption）：数据密钥（DEK）加密向量数据并随数据落盘；主密钥（KEK）只加密 DEK，明文驻留 HSM 内；落盘仅保存"被 KEK 加密的 DEK 密文"和"用 DEK 加密的向量"。收益是轮换主密钥无需重加密全量向量，且 DEK 可做到"一文件一密钥"，把爆炸半径压到最小。

# 信封加密的伪代码逻辑（仅示意，不含真实域名与端点）
def encrypt_vector(plain_vector, kek_handle):
    dek, dek_iv = generate_data_key()          # 本地生成数据密钥
    cipher_vector = sm4_encrypt(plain_vector, dek, dek_iv)
    wrapped_dek = hsm_wrap_key(kek_handle, dek) # 主密钥在 HSM 内加密 DEK
    return {"cipher": cipher_vector, "iv": dek_iv,
            "wrapped_dek": wrapped_dek}         # 主密钥明文不出 HSM

def decrypt_vector(record, kek_handle):
    dek = hsm_unwrap_key(kek_handle, record["wrapped_dek"])
    return sm4_decrypt(record["cipher"], dek, record["iv"])

注意 hsm_wrap_key：密钥运算发生在 HSM 内部，应用拿不到 DEK 明文，更拿不到 KEK，这正是防泄露的关键。

信封加密原理：主密钥锁进HSM、数据密钥随数据

2.3 密钥分级：不同敏感度分开管

按"泄露冲击力"分三级。一级主密钥（KEK）泄漏等于整库加密失效，须锁在 HSM 内且永不导出；二级数据密钥与 API Key 直接保护业务数据或产生资损，需集中托管并支持快速吊销；三级短期会话令牌存活短、可频繁换新。分级让最严管控资源投给一级密钥，三级允许轻量签发，既安全又不拖慢研发。"一刀切"给所有密钥上最重审批流，反而逼开发者把 Key 写回代码仓库，更不安全。

三、以 HSM 为基座的商用密码基础设施长什么样

落地到具体技术栈，一套成熟的密钥管理系统以 HSM 为"信任根"：所有密钥运算都在 HSM 内完成，密钥永不明文导出；在此基座上做密钥全生命周期管理与一组可组合加密能力。

3.1 算法与合规底座

面向国内政企的密钥管理系统绕不开国密体系，典型实现同时支持：国密 SM1/SM2/SM3/SM4；国际 AES、RSA、ECC、SHA；后量子 Kyber（密钥封装）、Dilithium（数字签名）。把后量子密码放进基础设施，是应对"现在截获、未来解密"的前置动作——今天落盘的向量库密钥，十年后或被量子算力解密，主密钥体系预留抗量子替换路径合理。

合规层面依据 GM/T 0051 规范建设，对密钥执行完整生命周期状态机（生成 → 存储 → 激活 → 更新 → 归档 → 注销 → 销毁），每把密钥任意时刻处于且仅处于一个合法状态，状态跃迁需权限与审批，直接服务于密评合规中"密钥管理可管可控"的测评项。

3.2 八类加密能力如何对应到 AI 场景

HSM 基座之上通常提供一组可组合加密能力，与大模型应用强相关的几类映射如下：

把一个大模型应用"拆开"，几乎每类密钥都能在表中找到归宿：向量库落盘加密走透明数据加密，API Key 托管走密钥管理组件，服务间零信任身份走证书签发组件，运维远程接入凭据走远程接入凭据管理。

3.3 多语言 API 与部署形态

成熟系统应提供 Java、Go、C 及 RESTful 接口，使后台、推理网关、高性能算子都能用熟悉方式调用密钥服务。部署支持单机、集群、热备、冷备四种形态，既能边缘轻量运行，也能核心机房高可用。多租户隔离解决同一基础设施服务多业务线甚至多外部客户时，彼此密钥与审计逻辑隔离、不串租户的问题。

四、把密钥供给落到大模型应用架构里

4.1 LLM API Key 的集中托管

朴素写法把 API Key 放进环境变量或配置中心，配置中心被读穿则所有 Key 一起裸奔。改进做法是引入密钥代理：应用向代理申请短期调用令牌，真实 API Key 始终保存在 HSM 托管的密钥管理组件中。请求与返回结构示意如下：

{
  "app_id": "rag-service-prod",
  "provider": "llm-vendor-a",
  "scope": "chat",
  "ttl": 900
}

代理返回 15 分钟有效的短期令牌；即便令牌被日志打印、被前端透传，攻击窗口也只有一刻钟且可一键吊销。代理层本身也要防滥用：限制每应用签发额度与频率，对异常突增触发告警，签发记录进审计，做到"谁在何时为哪个应用申请了哪个厂商的令牌"全程留痕。

4.2 向量库加密密钥与信封加密

向量库写入前从密钥管理组件申请 DEK 句柄，走 2.2 节的数据加密方案（信封加密）。迁移、备份时只要 DEK 密文包裹随数据走，主密钥仍锁在 HSM 内，备份介质丢失也不泄密。常被忽略的是备份与归档：线上库加密了，却把明文快照丢进对象存储。正确做法是快照也走同一套信封加密，归档主密钥走独立归档状态，便于事后合规举证。

4.3 服务身份：从静态口令到动态证书

推理集群内部服务间调用应用 mTLS 而非共享口令。证书签发组件为每个工作负载自动签发短期证书，临期自动续期，注销立即进吊销列表。即便某 Pod 被拖进内存，身份凭据也几小时内失效，横向移动窗口被压窄。

4.4 审计与轮换：让泄露可被发现

• 全量审计：每次密钥使用（谁、哪个应用、哪把密钥、什么操作、何时、何 IP）落防篡改审计流水，支撑密评"密钥使用可追溯"；
• 自动轮换：API Key 按周、DEK 按数据分区、证书按天续期，轮换不需停机，因短期令牌与信封加密都支持热切换。

# 轮换策略示例（配置片段，仅示意）
rotation_policy:
  llm_api_key:
    mode: scheduled
    interval: 7d
    notice_channel: secure_message
  vector_dek:
    mode: per_partition
  service_cert:
    mode: ttl
    ttl: 24h
    auto_renew: true

五、防泄露设计的几个硬骨头

5.1 不要把密钥写进代码仓库

大模型项目尤其易犯：Notebook 里试通新模型顺手把 Key 写进 .env 又 git add。应做密钥扫描（secret scanning），CI 拦截含令牌提交，真实密钥只存运行时密钥系统。

5.2 日志与链路追踪脱敏

大模型请求体常夹带用户隐私与系统提示词。发给可观测平台前须用字段级保护组件对敏感字段脱敏，避免"密钥没漏、数据先漏"。

5.3 远程接入场景的凭据最小化

运维远程接入推理集群排障时，凭据应按需下发、用完即销，而非发长期有效万能钥匙。远程接入凭据管理组件做这件事：远程接入动态发放最小权限凭据，会话结束即回收。这里说的是"远程接入/远程访问"，并非其它网络隧道手段。

5.4 后量子迁移的前置准备

若主密钥体系只支持 RSA-2048，十年后面对量子算力会很被动。立项时选支持 PQC 的体系，把 Kyber/Dilithium 作为可切换算法项，性价比很高且不改变现有业务流程。

5.5 做一张威胁建模表

对着调用链逐段问：密钥存在哪、谁能动、泄露能干啥、怎么发现。简化片段如下：

5.6 密钥的归档与销毁也要可举证

被注销密钥往往要保留归档期，证明"某历史密文当时用哪把合法密钥加密"；真正销毁时执行密码学销毁而非简单删文件，确保密文不可还原。归档与销毁正是 GM/T 0051 生命周期状态机不可或缺的两端。

六、一个最小可行的落地路线图

1. 盘点密钥资产：登记散落环境变量、配置中心、代码里的密钥，标注生命周期与责任人，看清爆炸半径。
2. 先把 LLM API Key 收口：用密钥系统的密钥管理组件接管真实 Key，应用改申请短期令牌，立刻止血"Key 满天飞"。
3. 向量库上信封加密：引入透明数据加密/信封加密，主密钥锁进 HSM，DEK 随数据走，备份归档同步加密。
4. 补齐身份与审计：服务间上 mTLS，全量密钥使用进审计，设自动轮换策略，此时数据加密方案才算闭环。

走到第 4 步，系统已能满足大部分密评对密钥管理的要求，并为接入更多模型、更多租户留出扩展空间。

方案参考

大模型应用的密钥安全供给，本质是"把分散的、静态的、明文形态的密钥，收敛为集中的、动态的、密文形态的密钥服务"的工程问题。落地可把握以下通用建议：

第一，建设统一的密钥管理系统而非散点方案。 把 LLM API Key、向量库加密密钥、服务身份凭据纳入同一套有生命周期管理的系统，避免"每个组件自己发明一套密钥存储"。

第二，坚持信封加密与硬件信任根。 向量库、知识库等大规模数据加密优先采用信封加密：数据密钥随数据、主密钥锁在硬件安全模块内，既缩小泄露爆炸半径，又让主密钥轮换不触发全量重加密。

第三，把明文生命周期压到最短。 真实密钥只在硬件可信环境内可见，应用侧只持短期令牌或密文句柄；API Key 按小时或天签发短期令牌，服务证书按天续期，泄露窗口被显著压缩。

第四，服务身份走动态证书而非共享口令。 推理集群内部、服务与向量库之间用自动签发续期的 mTLS 证书代替长期共享口令，配合注销即生效的吊销机制抑制横向移动。

第五，可审计与可轮换是底线能力。 每笔密钥使用记录"谁、哪个应用、哪把密钥、什么操作、何时、何地"，审计日志防篡改；密钥、证书、DEK 设自动轮换且热切换不中断业务，直接支撑密评合规"密钥使用可追溯、可管可控"。

第六，合规与算法选型前置。 面向国内场景优先支持国密并依据 GM/T 0051 设计密钥状态机；对长期保护数据提前把后量子密码（Kyber/Dilithium）作为可切换算法项预留；对远程接入排障凭据执行按需下发、用完即销的最小化策略。

第七，别让工程习惯拖后腿。 代码仓库启用密钥扫描、CI 拦截含令牌提交、日志对敏感字段脱敏——这些"非密码学"纪律往往比选哪把算法更能决定最终是否泄密。

以安当KSP为例，其以硬件安全模块(HSM)为信任根、支持国密SM1/SM2/SM3/SM4及依据GM/T 0051的密钥全生命周期管理，可作为大模型密钥供给的工程样本对照。

综上，大模型应用的密钥供给没有银弹，但路径清晰：以硬件安全模块为信任根、密钥管理系统为中枢、信封加密为数据保护手段、审计与轮换为兜底，把防泄露做进架构而非依赖人的自觉。