API Key 安全管理：别把密钥泄露到互联网上

2023 年，一位开发者把包含 AWS Access Key 的代码推到了公开的 GitHub 仓库。不到 10 分钟，自动化脚本就拿到了他的 Key，启动了大量 EC2 实例挖矿。等他发现时，AWS 账单已经飙升到了 4.5 万美元。

这不是个例。API Key 泄露是开发者圈子里最常见的安全事故之一，而且后果远比你想象的严重。

API Key 泄露的真实案例和后果

API Key 泄露不是理论风险，而是每天都在发生的真实事故。来看几个典型案例：

案例 1：GitHub 公开仓库泄露 OpenAI Key

开发者在 GitHub 公开仓库提交了包含 OpenAI API Key 的代码。黑客用这个 Key 跑了大量的 GPT-4 请求，月底账单 $2,000+。更糟糕的是，黑客还用这个 Key 做了一些违规操作，导致开发者账号被封禁。

案例 2：截图泄露 AWS 密钥

有人在 Stack Overflow 提问时贴了一张终端截图，截图里包含 AWS Access Key。自动化爬虫识别图片中的 Key 后，立刻用来启动服务器挖矿。3 天后，$6,000 账单。

案例 3：日志打印 Key

一个应用在启动时把所有配置参数（包括 API Key）打印到了日志里。日志被错误地配置为公开访问，搜索引擎索引了这些日志页面。Key 泄露后被批量利用。

泄露的后果不仅仅是钱的问题：

• 💰 账单暴涨——被盗用产生巨额费用
• 🚫 账号封禁——违规使用导致服务商封号
• 📉 数据泄露——通过 Key 可能访问你的数据
• ⚖️ 法律风险——如果泄露了用户数据，可能面临法律追责
• 😤 信任损失——用户和合作伙伴对你的信任崩塌

常见的泄露途径：你的 Key 是怎么跑到互联网上的？

1. 代码提交到 GitHub

这是最高频的泄露途径。开发者把 Key 写在代码里，然后 push 到了公开仓库。GitHub 上有大量自动化机器人在扫描新提交的代码，几秒内就能发现泄露的 Key。

常见场景：

• 配置文件里写了真实 Key，忘了加 .gitignore
• 代码示例里用了真实 Key，忘了替换
• 从私有仓库 fork 到公开仓库，Key 跟着一起暴露
• 环境变量文件（.env）被提交

2. 截图泄露

终端截图、配置截图、错误信息截图……很多人在分享问题时没有注意到截图里包含了 API Key。更隐蔽的是，即使你用马赛克涂抹了部分 Key，OCR 技术有时候还能识别出来。

3. 日志泄露

应用在启动时打印配置、调试日志打印完整请求头、错误信息包含认证信息……这些日志如果被公开或索引，Key 就暴露了。

4. 其他途径

• 聊天记录泄露——在 Slack/Discord/微信群里分享了包含 Key 的内容
• 错误配置的环境变量——调试时打印了所有环境变量
• 容器镜像——打包了 Key 的 Docker 镜像上传到了公开 Registry
• 客户端代码——Key 被嵌入到了前端 JavaScript 或移动 App 里

安全最佳实践

1. 使用环境变量存储 Key

永远不要把 API Key 硬编码在代码里。使用环境变量：

# ❌ 错误做法
api_key = "sk-abc123def456..."

# ✅ 正确做法
import os
api_key = os.environ.get("OPENAI_API_KEY")

环境变量的好处：Key 不在代码里，不会被 git 追踪，不同环境可以用不同的 Key。

2. .env 文件管理

用 .env 文件管理本地开发的环境变量，但一定要做好以下几点：

# .env 文件示例
OPENAI_API_KEY=sk-abc123...
ANTHROPIC_API_KEY=sk-ant-abc123...
DATABASE_URL=postgres://user:pass@localhost/db

1. 立刻把 .env 加入 .gitignore——创建项目的第一件事
2. 提供 .env.example 模板——只写 Key 名，不写真实值
3. 给 .env 文件设置严格权限：chmod 600 .env
4. 不要在 .env.example 里写真实 Key（听起来很蠢，但真的有人这么做）

3. 不要把 Key 写在代码里（再次强调）

不管你是写注释、写文档、写测试代码，还是写示例代码，都不要用真实 Key。用占位符：

// ✅ 使用占位符
const apiKey = "YOUR_API_KEY_HERE";

// ❌ 不要用真实 Key，哪怕是注释里
// const apiKey = "sk-abc123def456"; // 这是我的key

4. 定期轮换密钥

即使你没有发现泄露，也应该定期更换 API Key。就像定期换密码一样。

• 设置日历提醒，每 90 天轮换一次 Key
• 轮换时先创建新 Key，更新所有服务后，再删除旧 Key
• 避免轮换期间服务中断——先并行运行新旧 Key

OpenClaw 中的 Key 管理方式

OpenClaw 对 API Key 管理有内置的安全设计，了解这些机制能帮你更好地保护密钥。

配置文件管理

OpenClaw 的配置文件 config.yaml 存放在 ~/.openclaw/ 目录下。这个目录默认只有当前用户可读，权限是安全的。你在配置里填入的 API Key 都存储在这里。

配置示例：

providers:
  openai:
    api_key: "sk-..."
  anthropic:
    api_key: "sk-ant-..."

安全建议

• 确保 ~/.openclaw/config.yaml 的权限为 600（仅 owner 可读写）
• 不要把 OpenClaw 配置文件提交到 git
• 备份配置时，注意脱敏处理 Key
• 如果用 Docker 部署，用 Docker Secrets 或环境变量注入 Key，而不是写死在镜像里

API Key 权限控制

大多数 API 服务都支持创建不同权限级别的 Key。遵循最小权限原则——只给 Key 它需要的最低权限。

只读 vs 完整访问

以 OpenAI 为例，你可以创建：

• 只读 Key——只能调用 API 查询，不能修改账号设置、不能创建新的 Key
• 写入 Key——可以创建 fine-tune 任务、上传文件等
• 受限 Key——限制只能访问特定的模型或功能

如果你的使用场景只是调用 GPT API，那就创建一个只用于 completions 的 Key，不要用全能的管理员 Key。

多 Key 策略

为不同用途创建不同的 Key：

• 开发环境用一个 Key
• 生产环境用另一个 Key
• 测试/实验再用一个 Key

这样即使某个 Key 泄露了，你只需要轮换那个 Key，不会影响其他环境。

使用代理 API 隐藏真实 Key

如果你需要在多个地方使用 API，可以考虑使用代理服务来保护真实 Key：

自建 API 代理

搭建一个中间层服务，对外暴露代理 Key，对内使用真实 Key：

客户端 → 你的代理服务 → OpenAI API
        (代理Key)      (真实Key)

好处：

• 真实 Key 永远不离开你的服务器
• 可以在代理层做日志、限流、缓存
• 泄露了代理 Key，只需要在代理层更换，不用动真实 Key

第三方代理服务

一些服务提供 API 聚合和代理功能，比如 OpenRouter、OneAPI 等。你把 Key 配在这些服务上，客户端只用这些服务提供的 Key。即使客户端 Key 泄露，你的真实 API Key 仍然是安全的。

OpenClaw 支持配置自定义 API 端点，你可以很方便地接入这些代理服务。

设置用量限制和告警

即使做好了所有预防措施，也要设置"最后一道防线"——用量限制和告警。

用量限制

大部分 API 服务都支持设置用量上限：

• OpenAI——在后台设置月度预算上限（Monthly Budget）
• Anthropic——设置 Rate Limit 和用量限制
• 各大云服务——AWS Budgets、GCP Budget Alerts、Azure Cost Management

设置一个合理的上限，比如 $50/月。即使 Key 被盗用，损失也被控制在预算范围内。

告警通知

开启用量告警，在以下情况时通知你：

• 用量达到预算的 50%、80%、100%
• 短时间内请求量异常飙升
• 出现了你没有使用过的模型或功能

早发现 1 小时，可能省下几千美元。

被泄露后怎么处理？紧急步骤清单

如果你发现 API Key 已经泄露了，按照以下步骤紧急处理：

🚨 第一时间（0-5 分钟）

1. 立即撤销泄露的 Key——去 API 服务商后台删除或 revoke 这个 Key
2. 检查是否有异常用量——查看 API 调用日志，确认是否有非本人的操作

⚡ 短期处理（5-30 分钟）

3. 创建新 Key——生成新的 API Key 替换到所有正常使用的地方
4. 检查所有使用该 Key 的服务——确保全部切换到新 Key
5. 联系 API 服务商——说明情况，请求免除被盗用的费用（很多服务商对此有豁免政策）

🔍 后续排查（30 分钟 - 数小时）

6. 找到泄露源头——检查 git 历史、聊天记录、截图、日志
7. 清理泄露内容——删除公开仓库中的 Key、清除搜索引擎缓存
8. 检查关联服务——如果多个服务使用同一密码/Key，全部更换
9. review 安全流程——为什么会泄露？流程哪里出了问题？怎么防止下次发生？

GitHub 有一个专门的工具可以帮你扫描仓库中的密钥泄露：git-secrets 和 truffleHog。强烈建议在所有项目中安装使用。

总结

API Key 安全管理的核心原则就几条：

• 不要把 Key 写在代码里——用环境变量和配置文件管理
• 不要把 Key 提交到 Git——.env 加入 .gitignore
• 不要把 Key 截图分享——用占位符代替
• 遵循最小权限原则——只给 Key 需要的最低权限
• 设置用量上限——即使泄露，损失也可控
• 定期轮换 Key——把定期更换当作日常维护

记住，Key 泄露往往不是发生在你小心翼翼的时候，而是在你松懈大意的那一刻。把安全习惯变成肌肉记忆，比事后补救轻松一万倍。

相关阅读

• 国内外 AI 大模型 API 全对比——了解各平台 API 的安全特性和定价
• 免费 AI 大模型 API 使用指南——如何安全地使用免费 API 额度
• OpenClaw 云服务器部署指南——服务器环境下的 Key 安全管理
• AI 模型选择指南——如何选择合适的 AI 模型和 API