DeepSeek接入自建中转网关密钥加密存储

知识分享

2026-07-11 18:40

22 阅读

很多人在自建中转网关时，习惯把 DeepSeek 的 API Key 直接写在配置文件里。
这种方式虽然省事，但只要服务器被人翻到文件、日志泄露或者备份文件流出，密钥就可能被滥用。
本文从零开始，教你用对称加密把 DeepSeek 密钥安全存储，只有在网关启动时解密一次，平时磁盘上只有密文。

你需要准备什么

开始之前，请确保你已经满足下面几个条件：

一台能运行 Linux 的服务器（本文使用 Ubuntu 22.04 为例）
自建的中转网关已经能正常工作（比如基于 Nginx + Lua、OpenResty 或 Node.js 搭建的代理层）
服务器上已经安装了 OpenSSL（一般系统自带）
手头有一个有效的 DeepSeek API Key

如果网关还没搭建好，建议先完成基础搭建再来处理密钥安全的问题。

在自建网关上实现 DeepSeek 密钥加密存储

整个思路很简单：用 AES-256-CBC 算法加密密钥，把密文放到配置目录，网关启动时通过解密脚本拿到明文并注入环境变量。
下面按步骤走。

1. 生成加密密钥文件

在服务器上准备一个用于加密的密钥文件，这个文件要妥善保管，权限设严。

openssl rand -base64 32 > /etc/gateway/aes.key
chmod 600 /etc/gateway/aes.key

这里生成的 32 字节随机字符串就是 AES-256 的密钥。
权限设为 600 表示只有 root 才能读。

2. 加密 DeepSeek API Key

假设你的 DeepSeek API Key 是 sk-xxxx...，把它加密成密文：

API_KEY="sk-你的真实密钥"
echo -n "$API_KEY" | openssl enc -aes-256-cbc -base64 -pbkdf2 -pass file:/etc/gateway/aes.key > /etc/gateway/deepseek_key.enc

执行后看看 /etc/gateway/deepseek_key.enc 文件，内容是一串无意义的字符，这就是加密后的结果。
以后你只需要存储这个密文文件。

3. 编写网关启动时的解密脚本

为了让网关能自动解密，我们在网关的初始化脚本或 systemd 服务里加一段解密逻辑。
创建一个脚本 /usr/local/bin/decrypt_deepseek_key.sh：

#!/bin/bash
DECRYPTED_KEY=$(openssl enc -aes-256-cbc -d -base64 -pbkdf2 -pass file:/etc/gateway/aes.key -in /etc/gateway/deepseek_key.enc)
export DEEPSEEK_API_KEY="$DECRYPTED_KEY"
# 然后启动你的网关进程
exec /path/to/your/gateway-binary

记得给脚本加执行权限：

chmod +x /usr/local/bin/decrypt_deepseek_key.sh

如果你的网关是用 systemd 管理的，可以修改 service 文件，将 ExecStart 指向这个脚本，并设置 EnvironmentFile 不直接写密钥。

4. 在网关配置中引用环境变量

不管你的网关是用什么语言写的，都改成从环境变量 DEEPSEEK_API_KEY 读取密钥。
例如 Node.js 中使用 process.env.DEEPSEEK_API_KEY，Python 使用 os.environ['DEEPSEEK_API_KEY']。

常见配置错误与解决办法

问题 1：解密时报 bad decrypt 错误

原因：加密时的密钥文件和解密时的密钥文件不一致，或文件权限导致无法读取。
解决：确认 /etc/gateway/aes.key 存在且内容正确，权限为 600，属主是运行网关进程的用户。

问题 2：启动后网关报错 API Key 无效

原因：解密后的密钥可能包含尾部换行符或其他空白。
解决：加密时使用 -n 选项避免换行，或解密后在脚本中 trim 一下。上面示例已经用了 -n，安全。

问题 3：环境变量未成功注入

原因：网关进程不是由解密脚本发起的子进程。
解决：脚本最后必须用 exec 启动网关，否则环境变量只对脚本进程有效。如果使用 systemd，也可以将解密结果直接写入 /etc/default/gateway 但注意权限。

如何确认密钥加密存储生效

1. 检查磁盘上的密钥文件

用 cat 查看 /etc/gateway/deepseek_key.enc，里面应该是乱码，而不是以 sk- 开头的明文。

2. 验证网关能否正常调用 DeepSeek API

先重启网关服务，然后发一个测试请求：

curl -X POST "https://api.deepseek.com/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $(openssl enc -aes-256-cbc -d -base64 -pbkdf2 -pass file:/etc/gateway/aes.key -in /etc/gateway/deepseek_key.enc)" \
  -d '{"model":"deepseek-chat","messages":[{"role":"user","content":"Hello"}]}'

如果返回正常的响应，说明密钥密文能被正确解密并调用 API。
注意这行命令只是测试用途，实际生产环境不要这样写。

3. 确认明文未暴露

ls -la /etc/gateway/

确保目录下没有类似 deepseek_key.txt 之类的明文文件。
试试用普通用户身份能否读取加密密钥文件（应该是被权限拒绝）。

如果你发现日志里意外输出了环境变量，记得检查网关日志配置里是否无意中记录了请求头中的 Authorization。

完成以上步骤后，你的自建中转网关就不再直接保存 DeepSeek 的明文 API Key，即使服务器被入侵，攻击者也无法直接拿到可用密钥。
后续你可以定期轮换加密密钥和网关内部解密逻辑，进一步提升安全性。

OneAPI多租户权限隔离防止下游密钥泄露

AI中转站对话日志审计追踪API调用记录