上云之后，出事的几乎都不是云厂商的问题

云安全

写完前几篇后，有一个线索是我回头才看明白的。

在Redis练手靶场里，Redis的每个代码都在按照设计出来的工作。把他放在公网，且不设密码，是部署者做的选择，翻遍整个漏洞库，这个'漏洞'都没有一个编号。

上一篇的内网环境中，后半程几台机器的介绍写着：一个正常的Redis服务、一个正常的phpMyAdmin服务。关键词在于正常，它们本身没有问题，关键在于密码太弱。

而这类配置问题如果出现在云上，这个规律就会被放大到极致。NIST的官方文件也引用了同一个判断——"NIST SP 800-144《公共云计算安全与隐私指南》"指出：“不当配置”可视为一种主要的控制失效，这属于客户侧的控制失败，而非供应商缺陷。

一、把边界划清楚

很多人对于云安全都存在一个误解，购买完服务器后，只需要利用自带的安全防护机制就够了。

但是真实的划分是一刀两断的：云厂商负责的是——云本身的安全，而用户要负责的是云里面的安全，前者是机房、物理设备、虚拟化层和网络骨干，后者是操作系统、应用、数据、账号的权限和防火墙规则。

服务类型	谁在管操作系统	谁在管应用和数据	用户的责任
LaaS（云服务器）	用户	用户	最重
PaaS（函数计算等）	厂商	用户	中等
SaaS（办公套件等）	厂商	用户只用管自己的数据	最轻

可以看出，这个表每往下读一层，责任就轻一分，可以说：“当你使用laaS的时候，你就要一个人承担所有”

国内的大部分上云应用都是停在laaS这一档。所以之前说的99%落在谁的头上，边界一看就清楚了。

配错的代价也不是平均的，就比如同样是配错，租来的虚拟机比租来的邮箱要严重的多。

二、钥匙丢在哪？

云API的访问凭据叫AccessKey，两大厂商里，阿里云的以LTAI开头，腾讯云是AKID。它等价于一套账户和密码，而且能从任意地方登录，不需要你在公司的网络中。

丢掉的路径有这五条，没有一条是需要什么技术的：

途径	怎么丢的
公开的代码仓库	配置文件提交上去了，扫描机器人二十四小时在跑
前端的JavaScript	写在前端调API，而前端代码对所有人可见
APP反编译	凭据硬编码进客户端，解包就能翻出来
CI/CD构建日志	日志打印了环境变量
服务器上的.env	拿到shell后可以读取

这五条的搜索成本很低。登上机器后直接用env | grep ALIBABA_CLOUD,或者cat ~/.aliyun/config.json这两条就看完了。

这台机器什么也没搜到。它既没配 AccessKey，轻量应用服务器又挂不了 RAM 角色，等于它压根不持有云凭据。第六节第一条说的就是用角色替换这把长期钥匙。

所以说难防的是看不见的地方。配置文件被提交、日志把环境变量打下来、包就直接打进前端，动手的人没有意识到这就是泄密。

最难受的一点就是：整个过程不需要任何漏洞。只需要一个自动脚本扫公开仓库，一天就能捞到成百上千个有效凭据。

再往下一层说，策略写成Action:"*"和Resource:"*";相当于把整个账号交出去了。

之前提到的泄露事故之所以能造成影响，不是拿到的数据太强，而是钥匙本事就配的太大。

三、每台云主机上都开着一扇门

在云平台上，每一台主体都有一个特殊的端点，只有自身可以访问的到，外面无法连接。

阿里云是100.100.100.200，腾讯云是metadata.tencentyun.com，AWS是169.254.169.254。在主机上只需要敲一条curl http://100.100.100.200/latest/meta-data/就会出现一长串路径。

清单里有hostname、内网IP、VPC ID 、地域。如果这是**一台挂了RAM角色的ECS的话，清单里还应该有ram/**再顺着ram/security-credentials/查下去，就可以拿到那台机器绑定角色的临时凭据。

不需要有任何软件的漏洞，只需要主机替你发送请求，这就是SSRF到了云上就会变严重的原因：本身SSRF多半只能扫扫内网的端口，到这里就能直接换一个可用的身份。

四、另类的两类入口

对象存储的权限有三档：私有、公共读、公共读写。它们的区别就旨在一个下拉框

私有的桶从URL访问会返回AccessDenied，公共读会返回文件列表，这个测试很简单，用桶名和地域名拼出URL访问就可以，格式如下：

curl https://<桶名>.oss-cn-hangzhou.aliyuncs.com

有一点比较麻烦。桶名一般都会有规律，如：公司名-环境、项目名-static、产品名-日期这一类组合很容易用字典枚举。也是不少源码泄露的原因。

安全组是最容易被忽视的。轻量应用服务器里它的名字叫防火墙，但是管的是同一件事，22端口对0.0.0.0/0放行,这样的策略就相当于全世界所有人都可以测试你的密码，3306和6379这些本来出现在内网的端口如果对外开放，那它配套的很可能是默认凭据。

五、最好要换一套眼睛

传统的渗透中，第一反应是什么？找版本、公告、CVE。这些动作在前面的几个阶段确实好用，但是在云上就没那么好使。

根本的原因是：云上根本就没有版本号

这套眼睛的第一步是确认目标是不是在云上。这个很好找，用IP归属一查就知道。各大厂商的地址端也不是什么秘密；主机名也会带着实例规格的痕迹；最直接的一条就是元数据端点，连的上基本就可以确定了。

存储桶公开了，软件上没有一行代码跑错，错在权限配置，服务跑的好好的；凭据已经泄露了，平台也没有第一时间去打补丁。这时候去对CVE公告，发现一条都对不上，为什么？因为从头到尾就不是软件的问题。

所以在云上这些问题就应该换一下：

传统的渗透问什么问题	云上问什么问题
跑的是什么版本	凭据在哪里，有几分
有没有已知的漏洞消息	那把钥匙的权限多大
打这个漏洞需要什么载荷	哪个门开着、本该关着的
补丁升到了多少	边界按照什么规则刻画

这个四个问题没有一个是指向CVE的。使用漏洞扫描工具到了云环境一般也不会有什么发现。也就是这个道理：它很擅长对照版本号，但这也是云上最没用的消息。

六、 咋防

按照对应的动作来做反制，比按照技术排好用的多。

• 第一：换长期凭据

云主机上的应用不能再用硬编码的AccessKey,改用绑定实例的RAM角色（可以在ECS里设置，轻量服务器不支持）。让凭据自动轮转，不打进磁盘，这样前五条的泄露途径就能小很多

• 第二：最小权限原则

前两个*是重点排查对象，可以定期扫策略，看看有没有Action:"*"和Resource:"*"成本不高。

• 第三： 开MFA

MFA主账号很重要，对于凭据泄露来说这打击很直接：拿到密码也进不去

• 第四： 元数据服务升级到IMDSv2

它挡不住SSRF，但是还是可以让SSRF那不到凭据

• 第五：配一台CSPM

通过持续扫描配置，重点查看“昨天还没问题今天却变了”这样的漂移，很多事故都发生在某次发布前改的一行配置，很少某天突然配错。

措施	挡住什么	挡不住什么
RAM 角色替代 AK	磁盘上出现的长期凭据泄露	已经在攻击力的攻击者拿临时凭据
最小权限	凭据泄露后出现的横向扩散	权限本身就应该给的那部分操作
MFA	纯凭据泄露导致登录	已登录会话的操作
IMDSv2	SSRF顺手换凭据	SSRF本身和内网探测
CSPM	配置漂移长期没被发现	两小时内改坏又改回去的情况

最后一列才是真话。没有一条能单独把这件事做完。

最后

其实还是那句话，在读明白责任划分后你就会发现它讲了一件事：边界越往下，越没有人帮你管。

回头看前面讲的哪些问题，没有一起是出现在云厂商负责的那一层。

所以下次上云先别着急问：“装了什么样的防护”，而是先打开控制台的三个地方：权限策略里有没有星号，安全组是否存在0.0.0.0/0是否配置合理，应用凭据是否写在配置文件。

这三处只用5分钟就可以看完，覆盖面比很多安全组件都扎实。