阿里云账号被黑，很多人第一反应是平台出了漏洞。实际排查下来，问题多半出在用户自己的配置上。攻击者通常不需要攻破阿里云的核心系统，拿到一把有效的钥匙就够了。这把钥匙可能是泄露的 AccessKey，也可能是弱密码，或者撞库得来的登录凭证。
三类常见失误
AccessKey 被推上了代码仓库。某小程序开发团队把带有 AccessKey 的配置文件推到了公开的 GitHub 仓库。几个小时内，自动扫描脚本就抓到了密钥。攻击者随即开了十几台高配 ECS 挖矿，三天内账单涨到数万元。团队删掉密钥后，费用还得通过工单申请核查。删掉文件并不等于删掉历史，提交记录里的密钥同样可能被抓取，所以要一并轮换。
子账号权限给得太大。一位运维为了省事，直接给开发子账号授予了 AdministratorAccess。这个子账号的密码在一封钓鱼邮件里泄露。攻击者登录后关掉了操作审计，又新建了一个隐藏用户，过了一段时间才被发现。密码泄露是入口，权限过宽才让攻击者能做这么多事。
安全组整体放开。一个测试环境的数据库为了调试方便，安全组规则设成 0.0.0.0/0，开放了 3306 端口，还在用默认账号和弱密码。扫描器很快找到了端口，数据库被植入勒索脚本。这类事故大多只要做到只开放必需端口、限制来源 IP，就能避免。
以上案例为综合场景，人物和数据均为示意，用于说明常见的失误类型。
被黑后先做这五件事
- 先停掉风险入口。在 RAM 控制台禁用可疑的 AccessKey，修改主账号和相关子账号的密码。如果一时无法确定哪把 Key 被用了，宁可全部禁用，再逐个核对。
- 查操作记录。通过操作审计（ActionTrail）查看最近的登录和 API 调用。重点看新建实例、修改安全组、创建用户，以及平时不用的地域有没有访问。
- 先保留证据。清理之前，把相关日志导出保存，并截图留痕。后续提交工单或向公安机关报案时，这些材料会用得上。
- 清理攻击者留下的东西。删除他创建的实例、快照、镜像和子账号，再检查定时任务和 SSH 公钥文件，确认没有残留的新入口。
- 提交工单。通过阿里云控制台说明事件经过，附上已经做过的处理。如果产生了大额费用，同时申请账单核查。
处理时有两个常见误区。一是发现异常后马上删光所有实例，结果攻击链和证据一起没了。二是只改了密码，却忘了 AccessKey 和 SSH 公钥，攻击者换个入口又回来。
日常防护怎么落地
- 给主账号和管理类子账号绑定 MFA。密码再长，被钓鱼后仍可能直接被用。MFA 能拦住大部分只靠密码的登录尝试。
- 按需授予 RAM 策略。开发只需要看日志，就给只读权限；要改实例，再给对应资源的操作权限。尽量不用 AdministratorAccess。
- 代码里不写密钥。用环境变量或密钥管理服务保存凭证，并定期轮换 AccessKey。提交代码前，可以用扫描工具检查一遍仓库，看有没有漏网的密钥。
- 收紧安全组。只开放业务必需的端口，来源 IP 尽量限定到具体网段。数据库不要放在公网。需要远程调试时，走临时白名单或跳板机，用完及时关闭。
- 设置费用告警。按账单阈值设提醒。挖矿这类攻击的动静通常会体现在费用上，账单告警能较早提示。
- 保留日志。操作审计和云监控日志要长期保存。事后排查时，日志是还原经过的主要依据。保存时长最好在事发前就定好，事后再补就晚了。
小结
阿里云账号被黑，多数源于密钥管理、权限划分和网络暴露这三个环节。把它们做好，就能挡住大部分常规攻击。已经出事的话，先停掉入口，再保留证据、清理残留，最后找官方处理。按这个顺序做，能减少二次损失。
