很多团队是在月底对账时才发现问题。账单上的ECS费用突然涨了几倍，登录服务器一看，CPU长时间占满，进程列表里有一个名字随机、看不出用途的程序。这类事故常被称为云上挖矿。它未必是平台出了问题，更常见的情况是客户的账号或实例被人拿去挖矿。
一、云上挖矿通常从哪里进来
先说清楚一点：多数案例里，被利用的是客户自己的云资源，而不是云厂商的基础设施。攻击者不需要打穿平台，只要拿到有效凭证，就能像普通用户一样开机、部署程序、跑矿机。
常见入口大致有这几类：
- AccessKey泄露：开发者把AccessKey写进代码、配置文件或前端脚本，又推送到公开仓库。公开仓库经常被自动化脚本扫描，密钥一旦暴露，可能很快被人利用。
- 服务器弱口令或未授权访问：SSH用了简单密码，或者Redis、Docker API、Jenkins等服务直接暴露在公网又没有鉴权。攻击者可以借此写入计划任务或容器。
- 已知漏洞长期未修复：中间件或Web框架的远程代码执行漏洞没有及时打补丁，就给了植入挖矿程序的机会。
- 子账号被钓鱼：员工密码被盗，且没有开启多因素认证，攻击者登录控制台就能直接创建实例。
二、一个排查顺序的示例
下面是一个模拟场景，并非某个真实事件，用来说明排查时的先后顺序。假设某电商团队周一收到财务提醒，当月云资源费用比上月高出近四倍。运维登录控制台，发现账号下多了六台从没创建过的按量付费ECS，分布在三个地域。
排查大致可以分四步：
- 先止血：冻结可疑子账号，暂停异常实例，并轮换相关AccessKey。这一步要先做，否则攻击者会一直保持操作。
- 查操作日志：在操作审计（ActionTrail）里筛选创建实例、修改安全组和调用API的记录。示例中，所有创建动作都来自同一个陌生IP，用的是某个测试脚本里的AccessKey。
- 查代码历史：这个AccessKey半年前曾被误提交到仓库，后来文件删了，密钥却没有作废。历史提交、镜像和缓存里仍然留着它。删除文件并不等于消除泄露。
- 清理残留：除了删除实例，还要检查定时任务、启动项和镜像里有没有后门，并确认安全组里没有被加入可疑的入站规则。
这个例子暴露的是凭证缺少生命周期管理：谁在用、用在哪里、什么时候该作废，都没有人记录。
三、降低风险的几项常规做法
多数云安全事故，靠的是把基础工作做扎实。下面几条比较直接，也容易落地。
- 日常不用主账号AccessKey：为业务单独建RAM子账号，按最小权限授权，只开放业务需要的接口。主账号密钥一旦泄露，影响面最大。
- 自动化任务改用STS临时凭证：令牌有效期短，即使被截获，可利用的时间窗口也小。暂时无法改造的老脚本，至少要列出清单，排期替换。
- 控制台和RAM用户都开启MFA：尤其是有实例创建权限的账号。
- 设置预算和用量告警：在账单中配置预算阈值，异常增长时通知到负责人。这样能把发现时间从月底提前到当天。
- 收紧安全组：SSH、数据库和中间件端口不要对0.0.0.0/0开放，需要远程维护时走堡垒机或VPN。
- 开启云安全中心：它可以发现挖矿进程、异常外联和暴力破解行为，适合作为基础防护层，但替代不了前面几项。
- 在CI中做密钥检测：提交代码时扫描是否含有AccessKey等凭证，命中就阻止合并。
四、确认被挖矿之后
如果已经确认遭遇攻击，处理顺序可以是隔离、取证、清除、加固、复盘。隔离时不要急着删实例，否则日志和样本可能一起丢失。取证阶段保留操作审计记录和进程信息。清除之后，重新检查所有凭证和访问路径，不能只处理看得见的那台机器。
加固完成后，建议写一份书面复盘，记录入口、影响范围和改进措施。不少团队会发现，同类问题在不同项目里反复出现，原因往往是没有统一的凭证管理规范。复盘的价值就在这里：让同样的漏洞不再出现在下一个项目中。
阿里云被挖矿的消息看起来突然，但链路通常很朴素：凭证泄露、服务暴露、权限过大，三者叠在一起，攻击者就有了机会。先把账号体系、密钥管理和费用告警这三件事做好，大多数挖矿攻击在早期就能被拦住。
