AIBuilder · AI 搭建系统社群知识库

API Key 的安全管理

4分钟阅读

⚠️ 源单薄性声明 本条目素材单薄——只有 Anthropic 官方 doc 的散点提及 + AIBuilder 本项目自身的 1 个实战做法。没有独立安全专家视角、没有真实泄露事故案例。 已讲清楚:基础级的”不要写进代码”原则 / .env + chmod 的最小做法 还没听到:企业级密钥管理、泄露后的恢复流程、账户被盗用的真实案例 本条目视为”起步级安全意识提醒”，不是安全工程指南。

三条最基础的原则

原则 1:永远不要把 key 写进代码

不管是 Python 里 API_KEY = "sk-..." 还是 JS 里 const KEY = "..."——都不行。原因:代码进 git，git 历史永远在，即使你后来删了也能被翻出来。

原则 2:用环境变量或 .env 文件

Anthropic 官方 env-vars.md 和 settings.md 明确支持环境变量方式:

# ~/.zshrc 或 ~/.bashrc
export ANTHROPIC_API_KEY="sk-ant-..."

或用 .env 文件（项目根目录）:

# .env
ANTHROPIC_API_KEY=sk-ant-...
MINIMAX_API_KEY=...

关键:.env 必须立刻加进 .gitignore:

# .gitignore
.env
.env.local
*.env.secret

原则 3:权限收紧

AIBuilder 本项目的做法（来源:本 repo CLAUDE.md 里 deploy/.env 一行）:

chmod 600 deploy/.env

600 意思是只有文件所有者可读可写，其他人（包括同机器其他账号）读不到。

.env.example 模板约定

一个社群里常见做法（best-practices-page.md 侧面提及）:

  • 真实 .env 不进 git
  • .env.example 进 git，格式相同，但值都是占位符:
# .env.example
ANTHROPIC_API_KEY=sk-ant-YOUR_KEY_HERE
MINIMAX_API_KEY=YOUR_MINIMAX_KEY

新人 clone 项目后 cp .env.example .env，填自己的值。

Claude Code 的 deny 列表（permissions.md）

一个细节:可以在 settings.json 里加 deny 列表，阻止 Claude 读你的 key 文件:

{
  "permissions": {
    "deny": ["Read(.env)", "Read(.env.*)", "Read(**/*.secret)"]
  }
}

这不是万无一失的——Claude 能用 Bash(cat .env) 绕开（除非你也 deny bash）——但能防”顺手读”的场景。

本条目没涉及的（重要）

  • key 泄露后该做啥（立刻 revoke / rotate / 查调用日志）——没素材
  • 团队共享 key 的方式（Vault、1Password CLI、dotenv-vault）——没素材
  • CI/CD 中的 secret 管理（GitHub Actions secrets、GitLab CI variables）——没素材
  • 企业合规要求（SOC2、ISO）——没素材

这些场景在好朋友社群里迟早会出现——等有人具体踩坑，再写专题。

陈彬视角

这条目最诚实的说法:以上三条原则是最低门槛，不是”做到这些就够”。真想做好密钥管理，你需要专门学一下——这篇帮不了你。

但最常见的事故不是复杂的——是”写死在代码里 + push 到 public repo”。80% 的泄露就是这一条。把这一条做到，你已经超过大多数新手。

另一条观察:非程序员朋友经常犯的错——把 key 贴到聊天窗口问别人”这个 key 不对啊？“，截图里完整可见。一贴出来就等于公开了。任何时候在任何平台分享 key，都先想一想。

关联

needs_sources（明确待补）

  • 真实泄露案例研究
  • 企业级 secret 管理工具对比
  • 泄露后的响应流程
  • 国产 LLM key 管理实践

关系图谱

反向链接