阿里云安全专家确认：网络传闻“可重置任意阿里云服务器root密码”为虚假信息。真实情况为某客户自身的管理员AK（access key）泄露所导致的独立事件，目前我们已经联系该客户进行处理。借此提醒：AK为核心密钥，务必按照最佳实践合理使用： 上云，你需要了解的AK使用姿势
附链接原文：
上云，你需要了解的AK使用姿势
看了乌云君的漏洞报告，“ 假如你娶了云存储，这些姿势以后就别用了 ”，有些震惊。企业要安全上云，还需提高自身的安全修养呀，否则可能都不知道是怎么死的。报告里提到的几个上云的“受害者”，我猜都是“豪”。在Code里硬编码AccessKey，也就算了；还把Code放在公开的Github上，也算是醉了。这无异于，把取款密码写在银行卡上，然后再把银行卡扔在大街上。
认识AccessKey（简称AK）
企业上云时，云平台会为企业提供一个仓库，企业在云上的资源（比如云存储、云虚拟机、云数据库、……）都会放在这个仓库里。AK是给企业应用程序开启这个仓库的门钥匙，它和人类用的密码是类似的。保管好AK不被泄露是客户必需的责任。还记得两年前的CodeSpaces是怎样破产的吗？就是因为上云之后AK泄露了，黑客勒索未遂，结果彻底删除CodeSpaces的所有数据以及数据备份。
为了安全地上云，企业客户需要了解一些正确的使用姿势。
姿势1：正确保护AK
密钥保护非常有挑战。最简单的一种保护方法是使用操作系统的访问控制机制来保护AK文件，比如： $ chmod 400 ~/.aliyuncli/credentials 。其次，使用密钥管理系统(KMS)来保管AK也是不错的选择，KMS通常会验证应用程序是否有正确的授权码以及源IP地址，在严格检查授权有效性之后才允许使用。最严格的保护方法要算银行类企业，它们通常会使用硬件安全模块(HSM)来保护AK，保存在这个模块里的密钥是只进不出，当模块感知到有人拿刀“切”芯片时就会冒烟自毁，所以不管多牛逼的“厨子”也是无能为力的。
姿势2：杜绝使用“大AK”
AK是有“大”、“小”之分的。如果你还不知道，说明你使用的就是“大AK”。大AK，就是与云账号直接关联的AK，它代表的是云账号的所有权限。如果你在使用大AK —— 一旦这个大AK泄露，后果很严重，CodeSpaces的破产就是前车之鉴。
为了让企业应用程序能安全地工作，阿里云 访问控制服务 (RAM)允许云账号为应用程序创建一种“小AK”，这个小AK代表应用程序的身份，其访问权限可以被定制。根据最小权限原则，企业应该为应用程序提供刚好满足其功能所需的最小权限。
举个例子，如果应用程序只需要读取阿里云OSS的mybucket空间中hangzhou目录下的所有对象文件，那么就可以为小AK精确定制这一 授权策略 ，如下：
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:GetObject", "Resource": "acs:oss:*:*:mybucket/hangzhou/*" } ] }
使用这种方法后，假若企业应用程序的“小AK”被泄露，最糟糕的情况就是黑客也能读取OSS目录mybucket/hangzhou/下的所有对象文件，而仓库里的其它资产仍然安全无恙。
姿势3：限制应用程序的访问源IP
为了彻底防止因AK泄露所导致的风险，阿里云提供了针对应用程序的访问源IP限制。企业可以根据需要来设定访问云上仓库的源IP地址列表，应用程序发送操作请求的源IP地址如果不符合要求，那么就会被拒绝。只有源IP地址正确时，权限检查才会通过。
还是接着上面的例子，假设企业应用程序部署在一个确定的IP地址范围，如 42.120.99.0/24，那么带IP限制条件的授权策略如下：
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:GetObject", "Resource": "acs:oss:*:*:mybucket/hangzhou/*", "Condition": { "IpAddress": { "acs:SourceIp": "42.120.88.0/24" } } } ] }
这样的话，即使黑客盗取了应用程序的“小AK”，然并卵。。。
姿势4：为iOS或Android应用颁发临时访问令牌(Token)
永远不要将AK写到iOS或Android应用里。虽然App应用是企业开发的，但安装App的iOS或Android设备并不受企业的控制，记住永远不要将秘密放在不受控制的地方。如果AK写到了App里，控制App设备的人总是可能猎取到AK，并且可能任意传播猎取的AK。一旦出现这种情况，开启源IP限制也于事无补，因为App用户的IP地址一般是无法确定的，开启源IP限制还会误伤其他正常用户。
对于这种场景，从安全角度看，只能给iOS或Android应用做临时授权，如5分钟自动失效；而且必须授予最小权限，如每一App用户能访问的子目录都是不一样的。只有做到“最小权限+最短时效”，数据安全风险才能得到有效的控制。
为此，阿里云提供了 安全令牌服务 (STS)来解决这类问题，基本思路如下图所示
0. AppServer使用“小AK”，为“小AK”配置最小权限以及源IP限制。比如，AppServer的最小权限可能是这样 —— “不允许直接访问仓库里的OSS数据，只能访问STS来颁发Token，而且颁发出来的Token权限只能访问oss://mybucket/hangzhou/这个目录”。
1. 为每个App用户颁发满足“最小权限+最短时效”的Token。比如，App用户厨子只需访问oss://mybucket/hangzhou/<厨子>/ 这个目录，只需要访问1次，那么就为厨子的App颁发满足这一权限和最短时效的Token。
2. AppServer获取Token后，通过安全链路（如HTTPS）将Token传递给App。
3. App使用Token访问云上仓库（如OSS）。
下面我们来简单分析下安全性：
(1) 如果AppServer被攻击，黑客获取小AK，然并卵。首先，这个小AK不具备直接访问OSS数据的权限，它只能被用于调用STS获取Token。其次，黑客如果先通过STS获取Token再用Token访问OSS的话，也不可行的，因为小AK是受源IP限制的，无法在公网上任意使用；即使黑客知道这个受信的IP列表，实施ip spoofing攻击的难度也很大，因为公网路由器基本上都会做reverse path filter。
(2) 如果App用户厨子是个Geek，她能猎取到的所有秘密也就是一个“最小权限+最短时效”的Token，然并卵。因为这个小Token只能访问厨子自己应该访问的数据，猎取到这个Token并不能进行提权攻击。如果她故意把这个Token泄露出去，那就是搬石头砸自己的脚。
所以，建议乌云君报告里提到的“敢聊”，可以试试阿里云的OSS + STS解决方案，绝对可以确保App用户的照片和语音等隐私数据不会泄露。
欲知更多安全姿势，请移步云产品安全最佳实践。
结语
有云的地方就有恩怨，有恩怨的地方就有江湖，云就是江湖。上云，还是要多备些安全锦囊，以防患于未然。
相关阅读：
热门专题
