发现云API密钥出现在公开代码仓库、构建日志或工单附件中，先不要只删掉那段文本。副本可能已被缓存或复制，删除痕迹不能让凭证失效。云服务API密钥泄露后的轮换与审计流程，应从控制访问开始，并同步保留证据、追查使用情况。
第一步是确认凭证类型：它可能是云平台访问密钥、第三方服务的API令牌，也可能是服务账号密钥。不同类型的撤销位置和审计范围不同；若无法判断，应先按可能已被他人获取处理。
1. 先控制可疑凭证，同时保全证据
- 记录凭证标识、所属账号或项目、权限、发现时间和暴露位置。不要把完整密钥复制进事件记录或聊天工具。
- 在云控制台或对应身份系统中停用、撤销可疑凭证；若业务必须短暂维持运行，先评估风险并安排有负责人和时限的替代方案。已经公开暴露且无法确认访问范围时，优先撤销而不是等待排查完成。
- 保留相关仓库提交记录、构建记录、告警和云审计日志。限制证据访问范围，并记录导出时间及保管位置，避免为调查扩大泄露面。
停用密钥并不一定会清除已签发的访问令牌，也不必然终止已经建立的会话。还要核查对应身份的令牌、会话和信任关系，并依据平台能力撤销或缩短其有效访问。
2. 盘点依赖，按风险安排轮换
云服务API密钥泄露后的轮换与审计流程不能只针对发现密钥的一个文件。搜索代码仓库、部署配置、CI/CD变量、容器镜像构建配置和运维文档，找出使用该凭证的工作负载及维护人员。注意只搜索密钥标识或变量名，避免把密钥值再次写入命令历史。
- 先确认新凭证由哪个服务或应用使用、权限是否仍有必要，以及是否存在备用凭证。
- 为新凭证设置最小权限，并存入密钥管理服务，例如 AWS Secrets Manager、Azure Key Vault 或 Google Secret Manager；不要硬编码进源码或镜像。
- 先更新一个可控实例并检查认证、调用和错误日志，再按发布流程逐步推广。确认所有使用方切换后，撤销旧凭证。
- 若暴露风险高、旧凭证已被异常使用，立即撤销旧凭证；业务恢复应通过创建受控的新凭证完成，不能让已泄露凭证继续有效。
是否采用短暂的新旧凭证并行，要看平台是否支持、旧密钥能否安全保留以及暴露程度。并行便于无停机切换，但会延长风险窗口；立即撤销更能止损，却可能造成调用中断。
3. 用审计日志还原访问范围
按凭证关联的身份、账号或项目，检查暴露前后是否有异常认证、API调用、权限变更和资源创建。AWS环境可查看 CloudTrail 事件；Azure可结合 Activity Log 与 Microsoft Entra 的登录记录；Google Cloud 可查看 Cloud Audit Logs。实际记录内容和保留时间取决于平台配置、日志类别及组织策略，应先确认覆盖范围。
重点比对调用时间、来源地址、所用身份、请求的服务与操作，以及调用是否符合该应用平时的用途。异常地址不一定单独构成入侵证据；同样，没有发现异常日志也不能证明密钥未被使用，日志可能未启用、未覆盖相关服务或已超出保留期。
4. 追查凭证权限与潜在影响
把审计事件与密钥当时的权限范围对照，确认是否发生数据读取、配置修改、计算资源启动、身份权限提升或新凭证创建。若出现可疑操作，扩大检查相关资源和身份，不要只清理最初的密钥；必要时暂停受影响身份并按组织的事件响应流程升级处理。
同时检查是否有其他凭证被一并暴露，例如同一配置文件中的访问令牌。对确认发生的数据访问或变更，记录受影响资源、时间范围和已采取措施；是否需要通知客户或监管方，应依据适用的法律、合同和组织流程判断。
5. 验证修复，并关闭泄露入口
- 确认旧凭证已撤销，新凭证的调用正常且权限符合预期；在可行时检查旧凭证是否仍有成功请求。
- 扫描源码、配置和构建产物，清理可访问位置中的密钥副本。若公开仓库曾包含密钥，即使重写提交历史，也仍须以撤销凭证作为安全边界。
- 为后续发现建立告警和责任人：关注异常认证、非预期权限变更及不常见的API调用，并定期核对凭证用途、所有者和有效状态。
有效的云服务API密钥泄露后的轮换与审计流程，以凭证失效、影响范围有据可查、业务依赖已更新为完成条件，而不是以“文件已删除”作为结案依据。
常见问题
撤销密钥会不会让线上服务立刻中断？
如果服务仍使用该密钥，调用可能失败。高风险泄露应先止损；风险较低且平台支持时，可先部署新凭证并确认切换，再撤销旧凭证。
只改代码仓库历史是否足够？
不够。历史清理不能保证缓存、分叉或下载副本消失，必须撤销旧凭证，并检查其他配置和构建产物。
没有异常日志能否认定没有被利用？
不能。先确认日志已启用、覆盖相关服务且时间范围完整；记录不足时，应按无法排除访问风险继续评估。
轮换后还需要审计吗？
需要。轮换阻止旧凭证继续使用，审计用于判断此前是否发生访问或变更，并发现权限与流程上的缺口。
