API密钥怎么管理才安全？密钥上限、主子账号、IP白名单这三件套到底该怎么配

API密钥管理的最小安全组合是三层：用密钥上限控制单把密钥的调用额度与并发，用主子账号把密钥归属到具体项目或成员，用IP白名单把可用来源锁定在固定出口。三者缺一，密钥泄露后的损失半径就会从一次调用扩大到整个账户；如果团队只有一两个人、出口IP又不固定，IP白名单可以后置，但另外两层必须先建起来。 密钥上限解决的是「一把密钥能闯多大祸」的问题，而不是「密钥会不会泄露」的问题。任何放在客户端、写在代码仓库、贴进聊天记录的密钥，都要默认它迟早泄露；上线了上限，泄露后的最坏结果就被压成一个可承受的数字，比如单日调用量封顶、并发数封顶、可用模型范围封顶。配置时的判断依据不是拍脑袋，而是这条业务线的历史峰值加一段余量：以最近四周的日调用峰值为基准，上浮百分之二十到三十作为硬顶，突发流量走单独的密钥，而不是把总闸门开大。 主子账号要解决的是「密钥属于谁、出事找谁」的问题。根账号只用来做账户级设置和开票，日常调用一律通过子账号签发的密钥进行；每个项目、每个环境（开发、测试、生产）、每个外部合作方各拿一把独立子密钥，命名里写清归属，例如「订单服务-生产-华东」。这样做的直接收益是两件事：一是单把密钥可以单独吊销而不影响其他业务，二是账单和调用日志能按子账号归集，成本归属不用靠猜。 把密钥按环境拆开，是主子账号里最容易被忽略、也最容易止血的一条。开发环境密钥写在前端联调代码里、生产密钥放在服务端，这两类密钥的暴露概率差一个数量级；很多泄露事故并不是生产密钥被拖库，而是开发密钥被提交进了公开仓库。因此开发、测试子账号的上限要显著低于生产，且只授权非核心模型或非核心接口。 IP白名单解决的是「密钥被拿到后还能不能用」的问题，它是三层里唯一带主动拦截性质的措施。密钥泄露后，攻击者拿到的是一个字符串；如果服务端出口 IP 固定，把可用来源收敛到这个或这几个 IP，攻击者从自己的机器上调用会被直接拒绝。适用条件是调用方有稳定的公网出口——自建机房、固定 NAT 网关、云函数固定出口，或者办公网出口；不适用的是终端用户浏览器直连、移动端 App 内置密钥、多地办公无固定出口这类场景。 IP白名单不是越严越好，配错了会直接变成可用性事故。常见做法是先把生产服务的出口 IP 全量列清，再加一条监控告警：一旦出现「来源 IP 不在白名单」的拒绝计数持续上涨，先确认是扩容节点新增了出口、还是有人在探测。对使用弹性 IP 或自动扩缩容的团队，建议预留一段可动态更新的网段，或者改用固定出口的中间层转发，避免每次扩容都要改白名单。 三层要联动看，单独配一层都留了缺口。只有上限没有子账号，等于把额度控制做在了一锅粥上，某条业务被打满，其他业务跟着一起不可用；只有子账号没有上限，一个失控的脚本就能把子账号额度跑穿；只有白名单没有前两层，一旦攻击来自白名单内的机器（比如被入侵的跳板机），拦截就失效了。合理的顺序是先拆子账号、再定上限、最后收白名单，因为前两步是管理动作，第三步是网络动作，依赖前两步理清调用方清单。 从配置成本看，这三件事的投入主要是一次性梳理，而不是持续运维。梳理的对象是三个清单：有哪些业务在调、它们的调用峰值是多少、它们从哪个出口出去。这份清单在多数技术团队里其实已散落在监控、网关配置和部署文档中，把它们合并一次，三件套就能当天配完；真正花时间的是后续的变更管理，新服务上线、IP 扩容、合作方接入时，要把「申请子密钥并附上出口 IP 和预估峰值」写进上线流程。 密钥轮换是这套机制能否长期成立的关键动作，建议按敏感度分级设定周期。面向外部合作方的密钥每季度轮换一次，内部生产密钥每半年一次，开发密钥可以更短；轮换时利用子账号能力并行签发新密钥、观察调用量转移、再吊销旧密钥，避免停机式替换。对已经泄露或疑似泄露的密钥，处理顺序是立即吊销、检查该子账号的调用日志、按上限评估是否出现异常消费，而不是先改密码。 判断一套密钥管理是否达标，可以用一个简化标准：任意一把密钥泄露，损失是否被限制在一个可预测的金额和一个明确的服务范围内。如果答案是否，说明至少缺了三件套中的一层；如果答案是是，还需要补一条——这三层的配置本身要有变更记录和权限控制，否则改白名单、放宽上限的人就成了新的风险入口。 对刚开始做接口接入的团队，落地顺序可以更朴素：第一步，停用共享密钥，按项目或按人各发一把；第二步，给每把密钥设一个明显的额度上限和可用范围；第三步，等出口稳定后再上 IP 白名单。前两步在任何规模下都做得到，第三步取决于网络架构，不必为了安全强行改变部署形态，但要把「出口不固定」记为已知风险并定期复核。