API密钥怎么管理才不失控：密钥上限、主子账号与IP白名单的配置顺序

很多团队第一次意识到API密钥需要管理，是在账单突然翻倍，或者下游合作方回一句“我们这边没调用过”的时候。一把密钥交给所有人共用，出了问题既查不到是谁在用，也没法单独关掉某一方。密钥管理的难点从来不是生成一串字符，而是把它变成可控、可追溯、可回收的资产。企业级安全选项里最常被跳过的，恰恰是最基础的三件事：密钥上限、主子账号、IP白名单，它们分别管住“能用多少”“谁能用”“从哪里能连”。

先说密钥上限。多数中转平台允许一个账号开出多条密钥，上限通常有两层含义：一是数量上限，即一个账号最多能创建多少条密钥；二是调用上限，也就是这条密钥能用多少额度、能占多少并发。数量上限防止密钥无限扩散，调用上限决定一旦某条密钥泄露，损失被框在多大范围内。很多事故的根源不是密钥被偷，而是被偷的那条密钥本身没有边界，等于把整个账号的额度暴露出去。

实践中最有效的做法是“一密钥一用途”。按业务线拆、按环境拆、按调用方拆：线上问答服务一条，内部数据清洗任务一条，外部合作方一条。命名上带上业务、环境、负责人，账单和调用日志一眼就能对上是哪条线在消耗。这样做增加的管理成本很低，收益是排查异常时从翻半天日志缩短到几分钟。

再说主子账号。主账号是资产所有者，掌握充值、提额、创建子账号这类高权限操作；子账号是执行者，只负责日常调用和查看自己范围内的数据。如果把主账号的密钥直接发给开发同学，等于把整个账号的控制权交了出去，对方一次误操作就可能改掉全站的调用配置。

更细的权限划分，是把“能花钱”和“能改配置”分开。业务同学需要新增密钥或调整额度，走申请流程由管理员在子账号体系里授权，而不是共享一个万能账号。人员离职或项目结项时，回收的是子账号，不必惊动主账号，也不会影响其他业务继续跑。权限收敛到这一步，才谈得上审计。

第三件套是IP白名单，它回答的是“这条密钥允许从哪里发起请求”。只允许公司出口IP、云主机固定IP或NAT网关地址调用，即使密钥意外泄漏到公网，攻击者从别处发起的请求也会被拦在门外。这层防护的配置成本几乎为零，拦下的却是最常见的一类盗用。

白名单也有边界。移动端应用、Serverless函数、多地办公的团队，出口IP经常变化，强行全量白名单反而会让业务频繁中断。更稳的做法是分级处理：跑在固定机房的核心调用一律加白名单，临时或分布式的场景先依赖额度上限和密钥隔离，等网络架构稳定后再逐步收紧。

配置顺序上，建议先建主子账号把权限理顺，再按业务拆密钥并设置额度上限，最后逐条补白名单，并留一段观察期。上线白名单之前先看几天的调用来源日志，确认没有遗漏的出口地址，否则很容易把自己挡在系统外面。三件事的次序颠倒，往往就得返工重来。

密钥轮换是这三件套的配套动作。安全要求密钥定期更换，但直接删掉旧密钥会让正在跑的业务瞬间失败。可行的路径是新旧密钥并行一段时间，观察旧密钥的调用量归零后再吊销。这个动作能否顺利完成，前提正是前面的密钥分级做得足够细，能分辨哪条确实没人用了。

从选型角度看，模型API中转服务的安全选项是否完整，往往比单价更能决定长期成本。快米兔的模型API中转支持注册送5元测试金、按量计费，团队可以直接用测试金把主子账号、密钥上限和IP白名单的实际配置跑一遍，确认权限粒度是否够用，再决定要不要把生产流量迁过来，具体的安全项细节以官方说明为准。

最后是几个高频的坑：把密钥硬编码进前端代码或提交到代码仓库；在日志里完整打印请求头；多个业务共用一条密钥导致异常来源无法定位；只设了额度上限却没有做用量告警。这些问题大多不是技术难题，而是流程缺位，补起来并不难，难的是有人愿意在业务跑通之后回头补。

密钥管理的目标不是把安全做成门槛，而是让每一次调用都能被解释清楚：谁在用、用了多少、从哪里来。密钥上限、主子账号、IP白名单三件套叠加起来，才构成一个能收口、能追溯、能应急的最小闭环。先把这三步落地，再谈更复杂的风控策略，节奏会顺很多。