周一早上九点零四分，我端着刚接满热水的杯子坐回工位，邮箱里躺着一封安全提醒：检测到你的 AccessKey 存在泄露风险。
心情有点微妙——不是恐慌，更像考试时突然发现监考老师正站在你身后看你答题。那条 AK 已经在好几个小项目里用了一年多，天知道它被塞进过多少 .env 文件、多少份 CI 配置，甚至可能在某次手滑的提交里裸奔过。
第一反应是打开控制台把它删了。
还好手停了一下。删掉 AK 确实能让攻击者立刻登不上门，但也把唯一的线索一起扔进了垃圾桶——之后你再想知道「他到底用这把钥匙干了什么」，就只能靠猜。
这篇文章不讲怎么防泄露，只讲一件事：确认泄露之后的两小时，按什么顺序做什么，才能既把损失按住、又不把证据弄丢。
一、为什么第一站是操作审计，而不是 RAM 控制台
多数人的第一反应是去 RAM 控制台翻 AccessKey 列表。但那里只能看到这把钥匙的状态、创建时间、最后使用时间，回答不了最关键的问题：
- 它被谁、从哪个 IP、在什么时间调用过？
- 调用的都是哪些云服务、动了哪些资源？
- 有没有在某个我没注意的时间点做过高危操作？
这几个问题，只有审计日志能回答。阿里云的 操作审计（ActionTrail） 就是干这个的：它是平台的统一审计服务，控制台操作、OpenAPI 调用、云服务通过服务角色发起的调用都会记录，覆盖 200 多款云产品。
它有三个特点，直接决定了它适合当应急的第一站：
- 开箱即用。 不需要提前开通配置，账号下默认就记录最近 90 天的管控事件，在线即可查阅。
- 入库很快。 事件通常在 10 分钟内被追踪并记录，不会出现「刚发生的操作查不到」的尴尬。
- 信息足够细。 一条事件里能拿到：谁（操作身份）、什么时刻、从哪个源 IP、对哪个对象、做了什么操作、来自控制台还是 API、成功还是失败、失败原因是什么。
对应急来说，这基本等于一份带时间戳的案发现场笔录。
二、第一步：拿着 AK ID 去查「这把钥匙开过哪些门」
操作审计里有个专门的入口，叫 AccessKey 审计（控制台左侧导航栏 → AccessKey 审计 → AccessKey 事件查询），直接输入泄露的 AccessKey ID 就能查。
查询结果会给你三张表，建议按这个顺序看：
第一张：云服务列表。 这把 AK 访问过哪些云产品、各自最后一次使用时间。如果里面出现了你完全没印象的服务，比如从来没碰过的容器服务、函数计算，基本可以判定有人在试。
第二张：IP 列表。 每个服务对应的调用源 IP、最后使用时间、归属地域。这一步是排查的分水岭——把明显不是你公司出口 IP、也不是内网地址的 IP 单独抄下来，它往往就是攻击来源的线索。
第三张：资源列表。 被访问过的具体资源：ECS 实例、OSS Bucket、安全组、RAM 用户……哪些是正常业务，哪些是凭空冒出来的，看名字基本心里有数。
三张表对照着看，十分钟内就能画出「泄露窗口期内的可疑操作地图」。
三、第二步：五类高危事件，看到就要立刻处理
事件列表里的事件名很多，但真正需要你血压升高的其实就那几类。官方文档里点名的有五个，我把它们整理成一张表：
| 事件名 | 攻击者在干什么 | 你怎么判断 |
|---|---|---|
| CreateInstance | 用你的额度开 ECS 挖矿、搭代理 | 出账金额突然变大，或出现不认识的实例 |
| AuthorizeSecurityGroup | 开放 22/3389 等端口，把内网捅个窟窿 | 安全组多出宽松的入方向规则 |
| CreateAccessKey | 给已有 RAM 用户再配一把新钥匙，方便长期潜伏 | RAM 用户下多出未知 AK |
| CreateUser | 直接建一个后门 RAM 用户，做持久化 | 用户列表里出现陌生账号 |
| CreatePolicy / AttachPolicyToUser | 给自己或新用户挂上 AdministratorAccess 之类的高权限 | 出现来源不明的高权限授权 |
这张表建议直接抄进你的应急手册。因为排查时的心理状态是：一边慌一边查，能靠清单对照就不要靠脑子记。
四、第三步：止血四连，顺序别乱
发现问题之后的处理顺序其实是有讲究的：
① 禁用、轮换、删除泄露的 AK。 先在 RAM 控制台把原 AK 禁用（注意是禁用，不是直接删），再用同一用户重新生成新 AK 顶上业务；确认业务没受影响，最后才删掉旧的。顺序反了，可能先把自己业务干停。
② 排查有没有多出来的钥匙和人。 回操作审计事件列表里搜 CreateAccessKey 和 CreateUser，凡是自己没印象的一律删掉。这一步最容易被跳过，也最容易招来二次入侵。
③ 回滚异常资源。 攻击者开的 ECS、建的 OSS Bucket、改过的安全组规则和访问策略，逐个确认后释放或还原。别只删钥匙不清场子。
④ 顺着 IP 列表定位影响面。 把非自有 IP 摘出来，判断攻击是「刚拿到钥匙在试探」还是「已经进来逛了很久」。影响范围的大小，直接决定了后续要不要做取证和对外通报。
这里有个很多人会踩的细节：别忘了确认这把 AK 在业务里的使用范围。操作审计记录的源 IP，只反映已接入管控事件的调用；像 OSS 对象上传下载这类数据类操作，默认是不记录的。也就是说，光看 IP 列表，还原不出这把钥匙的完整使用轨迹。
所以禁用/删除之前，先回头确认一遍：本地开发机的环境变量、SDK 配置文件、CLI 凭据文件，以及 CI/CD 流水线的构建任务和部署脚本里，是不是还都配着这把 AK？
五、三个坑：现在不知道，出事时会很被动
坑一：默认只有 90 天。 操作审计默认在线可查最近 90 天的事件。如果想在出事时翻更早的记录——比如等保 2.0 要求的 180 天留存——必须在平时就建好跟踪，把事件投递到日志服务 SLS 或对象存储 OSS 长期保存。90 天内的查询不需要额外付费，投递后的存储费用按对应产品计费，具体以官方页面实时展示为准。等出了事再建跟踪，历史数据不会补给你。
坑二：数据类事件默认不记录。 前面说过，管控事件开箱即用，但像 OSS 对象读写这类数据事件，需要额外创建数据事件跟踪，而且只记录创建跟踪之后产生的事件。
坑三：STS 临时凭证的调用查不到。 通过 STS Token 发起的 API 调用（比如某次 AssumeRole 之后的操作），不会出现在 AccessKey 事件查询结果里——因为它用的是临时凭证的 AK ID，不是 RAM 用户的永久 AK。想查这类调用，得回到事件查询页按事件名检索。
六、收尾：把「应急」变成「日常」
应急做得再漂亮，也不如不出事。两个零成本的习惯值得现在就配上：
- 在云安全中心打开 AK 泄露检测（路径：风险治理 → AK 泄露检测），它会盯着公开渠道里出现的 AK，发现疑似泄露直接告警；配合告警模块里的云产品威胁检测，异常调用也会推到你手上。
- 在操作审计里建一个跟踪，把事件长期投递到日志服务或 OSS。平时看着没什么用，出事时它就是你唯一的笔录。
至于平时怎么防——不用主账号 AK、给不同业务配独立 RAM 用户的 AK、能上环境变量或密钥管理服务的就别硬编码、定期轮换、把长期不用的 AK 禁掉，这些说多了像念经，但每一条都能让你少一次早上的惊吓。
毕竟，应急响应方案最理想的状态，是永远躺在抽屉里，一次都用不上。
