代码仓库误传云平台 API 密钥后，不要只删除文件或提交修复补丁：旧密钥可能仍留在 Git 历史、分支、构建日志或镜像中。云计算平台API密钥泄露后的吊销与轮换步骤，核心是先阻断旧凭据继续使用，再安全部署新凭据，并核查泄露期间是否发生异常调用。
第一步：确认泄露范围，同时准备吊销
记录密钥所属的云账号、项目或订阅、创建时间、权限范围，以及可能接触到它的代码仓库、分支和流水线。不要把密钥复制到工单、聊天记录或新的排查脚本里。若无法确定曝光范围，应按密钥已经被外部获取处理。
随后找到对应凭据的管理入口。AWS IAM 访问密钥、Google Cloud 服务账号密钥和 Azure 服务主体客户端密码，管理位置与停用方式并不相同；应按实际云平台及凭据类型操作。API 密钥若由具体服务单独签发，也要在该服务的凭据管理界面核对，不能只在云账号中寻找。
第二步：吊销旧凭据并排查使用记录
- 优先停用或删除泄露密钥。若当前凭据管理页面支持停用，可先停用并确认状态已更新；如果风险明确且没有安全的过渡安排，应直接吊销，不要为了维持服务而长期保留已泄露凭据。
- 检查近期调用和审计事件。AWS 可查看 CloudTrail，Google Cloud 可查看 Cloud Audit Logs，Azure 可查看相关活动与资源日志。重点核对异常时间、来源、调用接口、资源变更、权限调整及费用相关操作。日志是否记录到密钥级别和来源信息，取决于服务与日志配置。
- 控制可能的连带风险。检查该身份能访问的对象存储、计算资源、密钥管理服务和账单相关功能。若发现未授权变更，按平台事件响应流程保全日志、限制相关身份，并通知负责云账号的管理员。
密钥已公开时，先阻止滥用通常比先清理 Git 历史更紧急。删掉仓库中的当前文件，并不会让已经复制出去的旧值失效。
第三步：创建替代凭据并安全部署
- 为确有需要的应用创建新凭据，选择能够满足任务的最小权限；尽量限制可访问的项目、资源和操作，避免沿用过宽的管理员权限。
- 将新凭据放入合适的密钥存储，例如 AWS Secrets Manager、Google Secret Manager 或 Azure Key Vault，或使用云平台支持的工作负载身份机制。具体方案取决于运行环境；能使用短期身份凭据时，通常可减少长期密钥的暴露风险。
- 更新应用配置或部署流水线，确保程序从安全存储读取新凭据。通过受控测试验证必要 API 调用成功、权限不足的操作仍被拒绝，并观察错误日志和服务状态。
- 确认新凭据已在所有运行环境生效后，再确认旧密钥保持停用或已删除。若应用支持并行凭据，过渡期应尽量短，并明确切换完成的检查点；已泄露密钥不应为了方便而继续并行使用。
第四步：清理仓库与其他副本
从当前代码中移除密钥，改用环境配置或密钥管理服务；再检查提交历史、其他分支、标签、合并请求、CI/CD 变量、构建日志、容器镜像和开发者本地副本。可用秘密扫描工具检查仓库，并将扫描纳入提交或持续集成流程。若需要重写 Git 历史，应先通知协作者并协调重新拉取；历史清理不能替代吊销，因为已有克隆和缓存未必能同步清除。
云计算平台API密钥泄露后的吊销与轮换步骤，应以“旧密钥已失效、新密钥已验证、暴露副本已排查”为完成标准。补充最小权限、秘密扫描和凭据定期检查，能降低类似误传再次造成影响的可能。
常见问题
只删除公开仓库中的文件够吗？
不够。提交历史和已下载副本可能仍保存原值，应先吊销，再处理历史和其他副本。
应用还在运行，可以等维护窗口再吊销吗？
若密钥已暴露，拖延会延长滥用窗口。优先停用并评估服务影响；随后尽快部署新凭据。是否需要短暂并行切换，应结合泄露风险和应用能力决定。
轮换后还要查看审计日志吗？
要。轮换只能阻止旧凭据后续使用，不能说明泄露期间没有发生调用或资源变更。