撤销并轮换暴露的密钥

一旦确认凭证已泄露，速度很重要——但顺序同样重要。如果不先了解哪些系统依赖该密钥，突然禁用密钥可能会导致生产环境中断。

目标是在保持合法工作负载运行的同时切断攻击者的访问，最好通过一次经过演练的流程完成。

处理泄露访问密钥时，第一步是停用它，而不是删除它。立即将密钥状态设置为 Inactive，就能停止其工作。

暂时保留该密钥（处于非活动状态），可以在 CloudTrail 中进行取证关联。只有在调查完成后，才能删除它。

对于合法用途，轮换意味着签发新的访问密钥，更新所有使用旧密钥的位置，然后停用遭到入侵的密钥。

按此顺序操作可以避免服务中断：新凭证先投入使用，旧凭证随后才关闭。请务必先验证应用能够使用新密钥正常运行。

停用长期密钥并不会终止它可能已经生成的临时凭证。对于角色，请使用 IAM 的撤销会话功能；该功能会根据令牌签发截止时间附加拒绝策略。

这会使早于该时间点的所有活动会话失效，彻底阻断已经落入攻击者手中的凭证。

轮换之前，请先了解机密存放在哪里。CloudTrail 会显示哪些服务和 IP 使用过该密钥。

机密被硬编码在多个位置，正是硬编码危险的原因。梳理每个使用方，可以确保轮换不会让某个被遗忘的系统发生故障，也不会让机密的副本继续生效。

AWS Secrets Manager可以存储数据库密码和 API 密钥等机密，并可通过 Lambda 函数按计划自动轮换这些机密。

自动轮换意味着泄露的机密只有很短的有效使用期限，应用会在运行时获取当前值，而不是持有过时的硬编码副本。

一个泄露的凭证往往会解锁其他凭证。如果攻击者使用某个密钥读取了数据库，那么数据库密码也可能已经遭到泄露。

也要轮换下游机密。请理清整个链条：攻击者可能接触过的每个机密，都必须被视为已暴露并进行替换。

如果 AWS 检测到暴露，可能会将AWSCompromisedKeyQuarantineV2附加到用户上，在允许您继续调查的同时拒绝高风险操作。

不要只是将其分离后置之不理。请将它视为一个提示，说明真正的补救措施——停用、轮换和审查——仍必须由您完成。

轮换可以阻止未来的滥用，但无法撤销过去造成的损害。请使用 CloudTrail 列出遭到入侵的凭证执行过的每一项操作。

回滚恶意变更：删除恶意 IAM 用户，移除后门密钥，并拆除攻击者创建的资源。遏制和清理是两个彼此独立但都必不可少的步骤。

恢复之后，请降低未来的风险。用基于角色的临时凭证替代长期密钥，启用机密自动轮换，并将机密扫描加入 CI/CD 流水线。

最有力的修复方式是从架构上解决：如果不存在可供泄露的静态机密，攻击者就无从寻找。

在完成记录之前，补救工作就还没有结束。请记录轮换了哪些凭证、攻击者执行了什么操作，以及哪些内容已被回滚。

请通知运行手册中列出的相关人员；如果受监管数据遭到暴露，请履行安全事件通知义务。清晰的记录能将事件转化为经验，并满足后续审计要求。

请选择正确的第一步操作。

要处理泄露的凭证，请停用访问密钥（保留该密钥以供取证），在不中断服务的情况下轮换为新密钥，并撤销活跃角色会话，使已签发的临时凭证失效。请先找出所有使用方，轮换攻击者可能接触到的下游密钥，并根据 CloudTrail 记录回滚恶意更改。请使用 Secrets Manager 自动执行轮换，并改用基于角色的临时凭证，以防止类似问题再次发生。