本文目录14 个章节
当 AI API 密钥出现在代码仓库、构建日志、工单附件、聊天记录或第三方服务配置中，风险不只是“被人调用几次模型”。对于企业而言，密钥泄露或误用可能同时造成非预算消耗、生产服务中断、敏感业务暴露、责任归属不清，以及采购、结算和审计流程受阻。
本清单面向平台主管理员、安全负责人、研发负责人和负责生产发布的工程团队。重点不是重新讲解如何创建 API 密钥，而是帮助组织在事件发生后，快速恢复服务、控制调用边界，并通过按业务、环境、团队拆分密钥的方式，减少共享密钥、权限过大和责任无法追溯的问题。
一、确认事件等级：先判断“泄露”还是“误用”
在轮换或删除密钥前，先建立统一事件记录，避免团队在信息不完整时做出相互矛盾的操作。
事件初判清单
- [ ] 记录发现时间、发现人、涉及系统、当前负责人和事件编号。
- [ ] 确认涉事密钥是否用于生产环境，而非开发、测试或个人试用环境。
- [ ] 判断问题类型：公开泄露、内部误共享、权限配置不当、异常调用、发布时引用错误密钥，或离职成员仍可使用。
- [ ] 标记密钥暴露位置：公开仓库、私有仓库、CI/CD 日志、镜像文件、配置中心、浏览器前端、工单系统、即时通信工具或第三方插件。
- [ ] 确认密钥是否仍然有效，是否仍被生产服务、定时任务、批处理任务或灰度发布环境调用。
- [ ] 识别关联业务：客户服务、内容生成、内部知识库、数据分析、自动化流程或面向外部用户的产品功能。
- [ ] 初步查看该密钥近期请求日志、模型消耗和调用时间段，判断是否存在与业务规律不一致的访问。
- [ ] 区分“调用量异常”与“模型范围异常”：前者可能是流量、重试或循环任务问题；后者可能意味着密钥被用于未授权模型或高成本模型。
- [ ] 确认是否涉及敏感输入数据、客户数据、内部文档或受监管业务数据，并同步数据保护、法务或合规负责人。
事件等级不应只按费用判断。一个调用量不高、但被用于生产敏感业务的共享密钥，也可能比开发环境的大量异常请求更需要优先处置。
二、立即止损：冻结风险路径，而不是盲目停止所有服务
处置目标是中断未经授权的调用，同时保留必要证据，并尽量避免因“全量停机”扩大业务影响。
平台主管理员检查项
- [ ] 立即在控制台定位涉事密钥，确认其所属业务、环境、团队和预期用途。
- [ ] 对已确认泄露且存在外部暴露可能的密钥执行禁用、删除或轮换操作。
- [ ] 不要将原密钥“改名后继续使用”；旧密钥一旦暴露，应视为不可再信任。
- [ ] 为受影响服务创建替代密钥前，先明确该服务实际需要的模型范围和额度上限。
- [ ] 检查是否存在多个服务共用同一密钥；如有，应拆分迁移，避免单次轮换影响范围失控。
- [ ] 在控制台核对密钥列表、请求日志和模型消耗，保存事件处置前后的关键记录。
- [ ] 对异常消耗设置临时监控阈值，并在轮换后持续观察新密钥是否出现相同模式。
- [ ] 若存在业务连续性要求，为关键生产服务安排受控的替代密钥和回滚方案。
安全负责人检查项
- [ ] 固化泄露证据，包括暴露链接、提交记录、日志片段、访问时间和相关账号信息。
- [ ] 记录密钥失效或轮换的确切时间，便于后续比对异常请求是否发生在失效前后。
- [ ] 排查是否存在同类泄露：同一仓库、同一发布模板、同一配置文件、同一人员维护的脚本。
- [ ] 审查密钥是否被写入前端代码、移动端应用或可下载客户端；这类场景不应依赖长期有效的生产密钥。
- [ ] 检查自动化流程是否会在下一次构建、部署或配置同步时重新写回旧密钥。
- [ ] 根据内部事件响应制度，确定是否需要通知管理层、合规、法务、采购或财务团队。
三、恢复生产：替换密钥前先重建权限边界
很多团队在事故后只做“生成新密钥、替换环境变量”两步操作，结果是新的共享密钥继续承担旧的所有职责。这样只能恢复服务，不能消除事故根因。
生产发布团队检查项
- [ ] 暂停引用涉事密钥的生产发布、自动扩缩容任务和可能覆盖配置的流水线。
- [ ] 核验替代密钥只被注入目标生产服务，不被开发机、测试环境、演示环境或临时脚本复用。
- [ ] 检查 CI/CD 变量、密钥管理系统、部署清单、容器编排配置和运行时环境变量是否全部更新。
- [ ] 在灰度环境验证替代密钥可正常调用后，再逐步恢复生产流量。
- [ ] 验证失败重试逻辑，防止因旧密钥失效导致循环重试、请求风暴或重复计费。
- [ ] 将密钥标识、所属服务、部署版本和变更单关联，确保日后能够追溯“哪次发布使用了哪把密钥”。
- [ ] 完成回滚预案：如新密钥配置错误，应回滚应用版本或切换到经过审批的备用密钥，而不是重新启用已泄露密钥。
研发负责人检查项
- [ ] 将密钥按“业务 × 环境 × 团队”拆分，而不是按单个研发人员或单个项目笼统分配。
- [ ] 为生产、测试和开发设置独立密钥，禁止使用生产密钥进行本地调试和联调。
- [ ] 为不同业务建立独立责任边界，例如客户产品、内部运营工具、数据处理任务分别使用不同密钥。
- [ ] 为每把密钥明确业务负责人、技术负责人、创建日期、用途说明和失效或复核时间。
- [ ] 禁止将“平台通用密钥”作为所有团队的默认配置；共享密钥会使异常消耗和责任归属无法准确定位。
- [ ] 复核模型范围：仅允许业务实际需要的模型，不以“未来可能会用”为理由开放全部模型。
- [ ] 复核额度边界：为不同业务设定与其预算、流量和风险相匹配的使用上限，避免单一密钥无约束消耗。
四、调查影响范围：从调用日志还原“谁、何时、为何使用”
密钥泄露事件的复盘不能只回答“有没有异常费用”，还应回答异常调用是否跨越了业务、环境、团队或模型范围边界。
调查与审计清单
- [ ] 从请求日志中提取涉事密钥的调用时间、请求来源、调用频率、模型类型和错误状态。
- [ ] 对比事件前后的模型消耗，识别突增、持续高频、非工作时间调用或与业务发布无关的峰值。
- [ ] 将异常请求与发布记录、代码提交、任务调度记录和业务流量变化进行关联。
- [ ] 判断异常是否来自密钥泄露，还是来自应用逻辑错误，例如无限重试、并发失控、缓存失效或重复队列消费。
- [ ] 核验调用的模型是否超出该业务原本授权范围；这通常反映权限设置过宽。
- [ ] 核验调用额度是否超出该团队、项目或环境的正常边界；这通常反映预算和资源责任未拆分。
- [ ] 确认是否存在同一密钥被多个团队、多个业务线或多个环境使用的情况。
- [ ] 对无法归因的请求单独标记，不应因“暂时无法确定”而直接归入某个团队。
- [ ] 形成影响结论：受影响业务、影响时间窗、异常调用性质、服务可用性影响、费用影响及数据风险判断。
企业应将请求日志、密钥归属和模型消耗放在同一治理视角中审查。只有密钥具备明确的业务、环境和团队标签，日志才真正具有责任追溯价值。
五、完成复盘：把临时补救转化为长期控制
复盘的重点不是追究“谁把密钥提交进仓库”，而是检验组织是否提供了正确的密钥分配、审批、发布和监控机制。
根因复盘清单
- [ ] 明确直接原因：代码提交、配置误传、共享账号、权限过大、发布脚本错误或未及时回收离职人员权限。
- [ ] 明确系统性原因：缺少环境隔离、缺少密钥台账、缺少负责人、缺少额度限制，或没有发布前密钥检查。
- [ ] 判断现有密钥命名是否能体现业务、环境和团队；无法识别用途的密钥应纳入清理范围。
- [ ] 建立密钥生命周期：申请、审批、创建、使用、复核、轮换、停用和删除。
- [ ] 将生产密钥变更纳入发布流程，要求关联服务、变更单、负责人和回滚方案。
- [ ] 为高风险或高消耗业务设置更严格的模型范围与额度控制。
- [ ] 对临时项目、演示项目和外包协作设置明确到期时间，避免临时密钥长期遗留。
- [ ] 定期核对控制台中的密钥、请求日志与模型消耗，清理无负责人、无用途说明或长期未使用的密钥。
- [ ] 将本次事件形成可执行的改进项，明确责任人、完成期限和验收标准，而不是只记录会议结论。
最小权限不是抽象原则，而是将每把密钥限制在必要的模型、额度、业务和环境中。
六、建立长期预防机制：让异常消耗能够被定位和止损
对于已经进入生产部署阶段的企业，API 密钥治理应与预算、采购、结算和运营责任共同管理。密钥不应只是开发配置项，也不应成为跨团队共享的“公共资源”。
长期治理检查项
- [ ] 每个业务线使用独立密钥，并由业务负责人对使用目的和预算边界负责。
- [ ] 每个环境使用独立密钥，生产密钥不得下沉至开发、测试或个人设备。
- [ ] 每个团队保有可追溯的调用边界，避免一个密钥覆盖多个无关团队。
- [ ] 根据业务需求限定可调用模型，防止默认开放全部模型带来成本和合规风险。
- [ ] 根据业务预算、调用量和服务等级设置额度，超出边界时触发人工确认或处置流程。
- [ ] 定期审阅密钥的负责人、用途、模型范围、额度和近期消耗，避免配置长期失真。
- [ ] 在采购、财务和技术沟通中使用统一的业务标签，确保模型消耗能够映射到具体成本中心或项目。
- [ ] 将日志审查纳入月度或季度治理流程，而不是只在事故后查看。
- [ ] 为生产发布团队保留明确的密钥替换操作手册，并定期验证轮换不会破坏业务连续性。
在 WisGate 控制台中，企业可按业务、环境或团队拆分 API 密钥，并结合额度与模型范围控制，查看密钥、请求日志及模型消耗。对于需要将调用责任、预算边界和生产发布流程统一起来的团队，这种拆分方式比长期共享单一密钥更适合企业治理。