上云，你需要了解的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用户的照片和语音等隐私数据不会泄露。

欲知更多安全姿势，请移步云产品安全最佳实践。

结语

有云的地方就有恩怨，有恩怨的地方就有江湖，云就是江湖。上云，还是要多备些安全锦囊，以防患于未然。

One More Thing ...

你懂的……