适用范围

这份 SOP 适合 2-20 人远程团队：有 Stripe、GitHub、Cloudflare、Vercel、OpenAI/Claude、邮件服务、数据库和监控平台。一个人公司也建议照做简化版，因为未来招第一个 contractor 时，历史债最容易爆。

Vault 怎么分？

Vault放什么谁能看
Dev本地开发 key、测试账号工程团队
Staging预发环境 key工程 + QA
Production生产 key、支付、数据库创始人 + 核心工程
Finance收款、税务、账单创始人 + 财务
Emergency恢复码、break-glass两位负责人

不要把所有东西放进一个「Team Shared」。那只是把风险集中到一个大抽屉里。每个 vault 都要有 owner，owner 负责季度审计和离职撤权。

API key 入库 checklist

  • key 名称包含服务、环境、用途，例如 openai-prod-billing-worker
  • 备注写清 owner、创建日期、权限范围、轮换周期
  • 只给需要的人授权，不给全员默认可见
  • 禁止把 key 贴到 issue、PR、Slack、Notion
  • 生产 key 不给本地长期使用
  • 能用 scoped token 就不用全权限 token

我自己的习惯是：新 key 创建后先写备注，再复制到环境变量或 secret manager。否则三个月后只剩一串 sk-，没人记得它到底绑定哪个服务。

轮换流程怎么跑？

第一步，新建 key，不要先删旧 key。第二步，把新 key 放进 1Password/Bitwarden，并更新部署平台 secret。第三步，发版或重启服务，观察错误率和账单。第四步，确认无流量走旧 key 后再 revoke。第五步，在备注里写轮换日期和下一次检查时间。

场景轮换频率备注
生产支付 key30-90 天审计尽量少人可见
LLM API key月度看用量按项目拆 key
CI/CD token季度检查优先短权限
Contractor key项目结束当天立即撤权
泄露疑似立即先 revoke

1Password/Bitwarden 怎么选？

1Password 适合更重开发工作流：CLI、secret 引用、团队 vault 体验都比较顺。Bitwarden 胜在成本和开源生态，预算紧的小团队也够用。别为了工具争半天，把命名、权限和轮换跑起来。

如果你已经有云厂商 secret manager，密码管理器仍然有价值：它放恢复码、控制台登录、手工应急 key；生产服务运行时读取 AWS/GCP/Vercel/Cloudflare 的 secret。两者不是替代关系。

新成员和外包怎么发 key？

新成员入职时，只给当前项目需要的 vault，不给历史全量。外包更要按项目和截止日期发权限，合同结束当天撤回。临时需要生产排查时，可以开一个短期 key，备注写清过期时间和负责人。不要为了省事把创始人的主账号借出去，后续审计会非常难看。

我还建议把「谁能创建 key」和「谁能使用 key」分开。创建权限越少越好，使用权限按项目给。这样即使某个成员电脑丢失，也不会同时丢掉所有服务的管理权。

新成员前三天只给只读或测试环境权限。等他真的需要生产 key，再由负责人单独批准。这个节奏会慢一点，但能避免「入职礼包」一次性发太多权限。远程团队没有办公室里的口头确认，权限范围必须写在工具里。

泄露应急 runbook

  1. 立即 revoke 或禁用疑似泄露 key
  2. 查 provider 调用日志、账单、异常 IP、异常时间段
  3. 生成新 key，按最小权限恢复服务
  4. 搜索 git 历史、CI log、错误日志和聊天记录
  5. 通知受影响成员，写明影响范围和后续动作
  6. 更新 SOP：为什么会泄露，下次如何阻断

LLM API key 的特殊管理

LLM key 最容易失控——模型、项目、成员和账单都变化快。团队如果已经把多个 AI 工具接到同一套凭据管理里，可以用 API 中转把子 key、用量和项目标签拆开，减少共享主 key 的需求。

相关阅读