很多人以为云平台被攻破，资产才会丢。实际上多数事故出在使用环节：主账号长期裸奔，没开多因素认证；AccessKey 写死在代码里，又被推到了公开仓库；安全组对公网开放了不该开的端口；OSS 桶或 CDN 域名没有任何访问限制。
扫描脚本每天都在全网翻公开仓库和网页源码。只要拿到一把有效密钥，几分钟内就可能有人开始批量建机器。所以阿里云防盗首先要做的，是让攻击者找不到可用的入口。
二、账号层面：主账号和子账号分开用
主账号权限最大，平时只用来管账单和安全设置。日常运维、开发、财务各自用 RAM 子账号，权限按职责给，不要图省事全部给管理员。
- 主账号先开多因素认证，绑定手机或安全令牌，别只靠密码。
- 运维、开发、财务分别建 RAM 用户，只授予他们工作需要的策略。
- 每隔一段时间翻一下登录记录，重点看异地、凌晨这类不寻常的登录。
- 人员离职当天就删除账号，并回收其名下的 AccessKey，别等下次想起来再说。
有个电商团队的前员工账号一直没停用，对方登进去改了安全组，把数据库端口直接暴露到了公网。复盘时发现，技术层面其实没什么复杂问题，只是离职流程里少了一步权限回收。
三、AccessKey 泄露是最容易被忽略的风险
AccessKey 基本等于账号本身。拿到它的人不需要碰控制台，直接调 API 就能干活，所以这部分要比其他配置更谨慎。
- 代码、配置文件和前端脚本里不要硬编码密钥，改用环境变量或凭据管理服务。
- 提交前跑一遍密钥扫描工具，把明文密钥拦在本地，别等推上远程仓库才发现。
- 能用 STS 临时凭证的场景就别用长期密钥，泄露后的影响时间会短很多。
- 一旦怀疑泄露，先在控制台禁用这把密钥，再排查影响范围，最后生成新的。顺序反过来，排查期间攻击者还在用。
一个开发者把测试脚本连同密钥推到了公开仓库，三小时内就有自动化程序用它创建了二十多台高配实例挖矿。第二天账单就异常了，最后还得找云平台沟通处理。这类事情说明，密钥管理花的时间远比事后收拾少得多。
四、资源层面：Referer 白名单怎么配，哪里容易踩坑
如果图片、视频、安装包放在 OSS 里，再通过 CDN 分发，那防盗链基本是必配项。思路很直接：在 CDN 或 OSS 侧设置 Referer 白名单，只允许你自己的域名引用资源，其他来源的请求直接拒绝。
有个资讯网站发现，文章配图被好几个论坛直接引用，每个月多出一笔流量费，服务器带宽也三天两头告警。加上 Referer 白名单和 CDN 访问控制之后，外站流量明显下降，账单也跟着降了下来。
配置时有几个坑值得提前注意：
- 白名单要把主域名和带 www 的写法都加上，少一个，正常访问就会被挡掉。
- 直接访问资源、没有 Referer 的请求，要明确决定放行还是拦截。很多浏览器和代理默认不带 Referer，一刀切拒绝会误伤部分用户。
- Referer 可以被伪造，它只能挡住普通盗链，挡不住有针对性的攻击。
- 如果是合同文件、内部资料这类敏感内容，就不要只靠 Referer，应当配合签名 URL 和过期时间使用。
五、费用监控：账单往往是最早的信号
很多安全事件最后都会在账单上留下痕迹。月底才看账单就晚了，提前设好这几项监控：
- 设置预算告警，费用超过日常均值一定比例时，直接通知负责人。
- 对 ECS、CDN、OSS 的流量和实例数量配置云监控告警，突增时能第一时间知道。
- 定期看费用明细，留意从没用过的地域，还有突然拉高的产品。
如果发现一个平时不用的地域冒出了新实例，第一反应应该是先怀疑密钥泄露，业务增长的可能放到后面再排查。
六、一周内可以完成的基础配置
如果想在一周之内把基础防护搭起来，可以按下面的顺序做：
- 给主账号开多因素认证，清理掉不再用的子账号和密钥。
- 检查代码仓库，确认没有明文密钥，统一换成环境变量或凭据服务。
- 审查安全组，关掉不需要的公网端口，数据库只对内网开放。
- 给 OSS 和 CDN 配 Referer 白名单，敏感资源启用签名 URL。
- 设置费用预算告警和关键指标监控，并指定一个人接收通知。
防盗得长期维护，做一次很快就会过时。权限、密钥和费用如果能像日常运维一样定期过一遍，大部分风险在造成损失之前就能被发现。
