一次 Access Key 泄露引发的生产事故，从收到 AWS 安全通知到账户完全恢复的完整过程
故事的开端：一条让人后背发凉的邮件
周六的一个下午，我收到了一封来自 AWS 的邮件——而那天是五一假期的第二天。
"We are reaching out to you because your AWS Account may have been inappropriately accessed by a third-party."
翻译过来就是：你的 AWS 账号可能被第三方入侵了。
随之而来的是账户被限制——无法启动 EC2 实例，无法使用部分 AWS 服务。而更让人焦虑的是，新加坡区域有一台生产环境的 EC2 正在运行海外业务，用户还在正常使用。
那一刻的心情，大概只有经历过的人才能理解。
本来计划好的五一假期安排，从收到这封邮件起全部作废。接下来的三天，我几乎住在了 AWS 控制台和工单页面里。
第 1 阶段：收到通知，紧急处理（第 0-6 小时）
AWS 在通知中给出了明确的安全恢复步骤：
- 修改 Root 账户密码
- 为 Root 用户启用 MFA
- 检查 CloudTrail 日志，排查异常活动
- 清理所有未授权的 IAM 用户、角色、策略
- 回复工单确认完成
我第一时间登录控制台，按步骤操作：
- 修改了 Root 密码
- 启用了 MFA
- 检查了 CloudTrail 日志，确实发现了异常的 API 调用
- 清理了所有可疑的 IAM 资源
做完这一切，我在工单中回复："我已按要求完成所有步骤，请帮我恢复我的账户功能。"
此时我以为很快就能解决，但事实证明这只是开始。
第 2 阶段：发现根因，请求加急（第 6-18 小时）
在排查过程中，我们的开发团队终于搞清楚了密钥泄露的根本原因——项目代码存在漏洞。
我们确认已经修复了所有相关代码。随后我紧急请求 AWS 启动新加坡区域的 EC2 实例，因为这个实例已经停机超过 4 小时，海外业务全面瘫痪，用户投诉不断。
启动时的报错信息让人绝望：
This account is currently blocked and not recognized as a valid account.
Please contact AWS Support if you have questions.
此时我开始意识到：安全限制不是做完步骤就能自动解除的，背后还有一套审核流程。
第 3 阶段：安全审核，回答问题（第 18-24 小时）
周日早上，AWS 安全团队回复了，要求确认以下信息：
- 你从哪个国家/城市访问 AWS 账户？
- 是否有其他人有权访问你的账户？
- 如果有，他们从何处登录？
- 所有活跃的 IAM 用户和角色是否都已获得你的授权？
我如实回答：
- 我会使用 VPN 访问，常用节点包括美国、新加坡、中国香港
- 没有其他人访问我的账户
- 所有 IAM 用户和角色都是我授权的
安全团队表示已转交审核，请我耐心等待。
期间我不断刷新工单页面，每一分钟都度日如年。
第 4 阶段：清理可疑资源（第 24-30 小时）
周一早上，安全团队发现了新的问题——一个 S3 存储桶可疑：
存储桶名称: logs-94591786-wmn5rp
要求确认该存储桶是否为我业务所需，如果不是则删除。
我检查后发现这个存储桶确实不是我们业务使用的（很有可能是攻击者创建的），立即删除并回复确认。
本以为这下可以解封了，然而还是太天真。
第 5 阶段：48 小时已过，忍无可忍（第 30-48 小时）
从收到通知到现在已经超过 48 小时，账户仍然处于限制状态。生产环境持续停机，海外业务瘫痪。
我再次在工单中表达了强烈诉求：
"我们已经完成所有安全措施，但账户仍然受限。如果问题不能尽快解决，我们将不得不考虑将生产服务迁移到阿里云和其他云服务商。"
这并不是虚张声势——每一分钟的停机都在实实在在地造成损失。
AWS 回复说正在与服务团队协作处理。
别人的五一假期在朋友圈晒旅游，我在工单里写小作文催进度。
第 6 阶段：细节遗漏，Chat 紧急沟通（第 48-52 小时）
周一傍晚，AWS 回复了一封让我意外的邮件：
"The team was unable to perform the required remediation steps. There are some actions needed from your side."
还需要我完成以下操作：
Step 1：删除未授权的 IAM 资源
- IAM 用户 "Server"：删除该角色或添加 MFA
Step 2：重置 Root 密码并更新 MFA
可是这些我早就做过了啊？仔细一看，是 IAM 用户 "Server" 的 MFA 没有被正确识别。
我没有再通过工单回复——这次我选择了 Chat 在线聊天。
接线的 Melissa 非常专业：
- 确认了我对 IAM 用户 "Server" 的 MFA 设置
- 要求再次重置 Root 密码并更新 MFA 信息
- 确认没问题后，立即更新了服务团队
这里要划重点：在紧急情况下，Chat 比工单回复高效得多，建议直接选这个渠道。
最终章：解封！（第 52-56 小时）
周一晚上 21:48，终于收到了那封让我松了一口气的邮件：
"We've verified that you've taken the required steps, and we've reinstated your AWS account."
账户终于解封了！所有限制都已解除。
从周六 14:06 收到通知，到周一 21:48 解封，整整 56 小时。 整个五一假期就这样泡汤了，我的假期余额全部充值到了 AWS 工单系统里。其中生产环境的中断时间也差不多是这个长度，海外业务直接瘫痪了一个完整的周末加周一。
完整时间线回顾
注：以下时间全部发生在五一假期期间。
周六 14:06 — 收到 AWS 安全通知，账户被限制
周日 01:08 — 完成初步安全步骤，请求恢复
周日 04:14 — 找到根因（代码漏洞），请求加急
周日 04:22 — EC2 已停机 4h+，紧急请求启动
周日 10:38 — 安全团队提问（访问地点/人员等）
周日 10:45 — 回答完毕，转交审核
周一 09:54 — 要求删除可疑 S3 存储桶
周一 11:06 — 删除完成，请求恢复并升级
周一 12:11 — 48h+ 仍未解封，强烈抗议
周一 15:07 — AWS 确认要求服务团队解除限制
周一 18:02 — 新要求：处理 IAM Server + 重置密码
周一 18:07 — Chat 在线指导，完成操作
周一 21:48 — 账户解封！
经验总结与建议
1. 安全第一，防患于未然
这次事故的根因是代码漏洞导致 Access Key 泄露。事后我们做了以下改进：
- 代码仓库中硬编码的密钥全部清理
- 使用 AWS Secrets Manager 或类似服务管理密钥
- 在 git 仓库中配置
git-secrets等工具防止密钥提交 - 定期轮换 Access Key
2. 理解 AWS 的解封流程
整个流程可以概括为：
收到通知 → 执行安全步骤 → 安全审核 → 补充操作 → 最终审核 → 解封
关键时间可能会超过 48 小时，如果涉及生产环境，要有充分的应急预案。
3. 紧急情况选对渠道
| 渠道 | 适用场景 | 响应速度 |
|---|---|---|
| 工单回复 | 常规沟通、提供信息 | 慢（数小时到十几小时） |
| Chat 在线 | 紧急问题、需要指导 | 快（即时） |
| 电话 | 极其紧急 | 最快 |
如果是生产环境故障，直接选 Chat 或电话，不要等在工单下面回复。另外，沟通时强烈建议使用英文，因为AWS的安全团队成员大多数看不懂中文，所以如果用中文沟通，还需要经中文客服转交一手。
4. 提前配置好安全联系人
AWS 强烈建议配置备用安全联系人。这样当账户出现异常时，AWS 可以通过多个渠道联系到你，不会错过关键通知。
5. 设置预算告警和成本异常检测
这次事件还有一个附带发现——AWS 的 Cost Anomaly Detection 和预算告警可以在异常消费发生时第一时间通知你。如果当时我们有设置这些，可能在 AWS 发现之前自己就已经察觉到了异常。
写在最后
五一假期本是用来休息和陪伴家人的，结果变成了全天候守在电脑前跟 AWS 工单死磕。虽然过程煎熬，但也是一次宝贵的实战经验。
这次经历让我学到了几件事：
技术层面： 密钥泄露听起来很远，但一个代码漏洞就能让它变成现实。安全不是一个开关，而是一个持续的过程。
流程层面： AWS 的安全审核机制虽然让人心急，但从另一个角度看，它确实在保护你的账户。如果随随便便就能解封，那安全防线就形同虚设了。
心态层面： 56 小时的停机很痛苦，但与其抱怨流程漫长，不如把精力放在如何加速沟通、如何准备充分的材料上。
最后想说的是——一定要在生产环境出问题之前，把安全联系人、预算告警、密钥管理这些东西配置好。 因为这些事在风平浪静的时候总觉得"不急"，等风暴来的时候，就已经晚了。
你有遇到过云服务商的安全限制经历吗？欢迎在评论区分享你的故事和踩过的坑。
