云平台API密钥泄露后的应急处置，关键不是在“禁用”和“轮换”之间二选一，而是尽快阻止旧密钥继续被使用，同时控制服务中断风险。若已有异常调用或密钥公开在代码仓库、日志等不受控位置，应优先让旧密钥失效；若暂时没有利用迹象且业务不能停，则先准备替代密钥并快速切换，随后立即撤销旧密钥。
先判断：立即禁用，还是先切换？
先禁用适用于确认密钥已公开、发现来源不明的调用或权限涉及敏感资源等情况。它能最快切断凭证访问，但依赖该密钥的程序可能报错或停止工作。不要因担心短暂故障而让可疑凭证继续有效。
先轮换再禁用适用于尚无异常迹象、关键服务依赖该凭证且可迅速部署新凭证的情况：创建新密钥，更新使用方，验证调用后撤销旧密钥。这个顺序有利于维持连续性，但旧密钥会在切换期间继续有效，所以应尽量缩短窗口，并限制其权限。
各云平台对“禁用”“删除”和“重新生成”的支持不同。有些凭证可单独停用，有些操作会立即影响依赖方；先查看该凭证类型的控制台说明。若已确认遭滥用，不应为了无中断切换而延迟撤销。
按顺序处置，避免只改一处
- 确认凭证并控制传播。记录凭证所属账号、用途、权限范围和可能暴露时间；从公开仓库、构建产物或日志中移除明文，并限制相关仓库或文件的访问。不要把密钥复制到工单、聊天记录或排查报告。
- 评估风险并止损。检查审计日志中的调用时间、来源、操作类型和目标资源。日志可能不包含完整来源信息，也可能有延迟，应结合程序部署记录判断。发现异常操作时，立即禁用旧凭证；同时检查是否存在新增凭证、权限变更等后续行为。
- 生成替代凭证并更新使用方。仅授予完成任务所需的权限，遵循最小权限原则。将新凭证存入受控的密钥管理服务，例如 Azure Key Vault，而不是提交到代码仓库。逐一更新应用配置、自动化任务和部署环境。
- 验证后撤销旧凭证。通过健康检查和实际授权操作确认新凭证可用，再禁用或删除旧凭证。若服务仍调用旧凭证，不要无限期保留两把有效密钥；尽快定位遗漏的使用方并完成切换。
- 复核影响并留档。查看相关资源是否被读取、修改或创建，确认权限和计费状态无异常。保存必要的审计日志、处置时间线及变更记录，但不要保存密钥明文。
轮换后仍要查清来源
只换一把密钥，不能消除其暴露根因。排查代码提交历史、CI/CD变量配置、调试日志和个人设备；若凭证曾被复制到提交记录，仅删除当前文件并不足以证明旧内容已不可见。还应检查同一身份下的其他凭证和授权，必要时撤销可疑会话或收紧权限。
例如，使用 Microsoft Entra ID 应用客户端密钥的服务，处置时要确认哪些应用配置引用了该密钥，并检查相关登录与审计记录。不同应用可能有独立发布节奏，不能只更新一台服务器就认定切换完成。
常见问题
只有“疑似”泄露，也要马上禁用吗？
若密钥已公开或出现异常调用，按泄露处理并尽快禁用。若只是内部告警且无法确认暴露，先快速核对来源和日志，同时准备替代凭证，不要长时间观望。
禁用后，旧密钥还能恢复吗？
取决于平台和凭证类型。禁用通常用于停止使用，删除或重新生成可能无法恢复；操作前确认影响，必要时先准备新凭证。
怎样确认轮换已经完成？
检查所有服务、任务和部署环境均已更新，观察调用日志中是否还有旧凭证请求，再撤销旧凭证。仅凭某个服务运行正常并不够。
云平台API密钥泄露后的应急处置，最重要的原则是什么？
先控制凭证风险，再恢复业务：确认泄露或滥用时立即让旧密钥失效；无异常且服务不能中断时，先快速切换新密钥，随后撤销旧密钥并复核日志。