最近，小编看了乌云君发布一篇漏洞报告《假如你娶了云存储，这些姿势以后就别用了》，一下子就震惊了。企业要安全上云，还需提高自身的安全修养，否则可能都不知道是怎么死的。
报告里提到的几个上云的“受害者”，我猜都是“壕”。在Code里硬编码AccessKey，也就算了；还把Code放在公开的Github上，也算是醉了。这无异于把取款密码写在银行卡上，然后再把银行卡扔在大街上。
认识AccessKey（简称AK）
企业上云时，云平台会为企业提供一个仓库，企业在云上的资源（比如云存储、云虚拟机、云数据库……）都会放在这个仓库里。AK是给企业应用程序开启这个仓库的门钥匙，它和人类用的密码是类似的。保管好AK不被泄露是客户必需的责任。还记得两年前的CodeSpaces是怎样破产的吗？就是因为上云之后AK泄露了，黑客勒索未遂，结果彻底删除CodeSpaces的所有数据以及数据备份。
为了安全地上云，企业客户需要了解一些正确的使用姿势。
姿势1：正确保护AK
密钥保护是非常有学问的。最简单的一种保护方法是使用操作系统的访问控制机制来保护AK文件，比如：$ chmod 400~/.aliyuncli/credentials 。
其次，使用密钥管理系统(KMS)来保管AK也是不错的选择，KMS通常会验证应用程序是否有正确的授权码以及源IP地址，在严格检查授权有效性之后才允许使用。最严格的保护方法要算银行类企业，它们通常会使用硬件安全模块(HSM)来保护AK，保存在这个模块里的密钥是只进不出，当模块感知到有人拿刀“切”芯片时就会冒烟自毁，所以不管多牛逼的“厨子”也是无能为力的。
如果企业对AccessKey保护机制有非常高的要求，不妨可以试试阿里云提供的KMS或HSM服务。
姿势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用户的照片和语音等隐私数据不会泄露。
欲知更多安全姿势，请移步云产品安全最佳实践。
那么，是不是所有云存储正确使用了鉴权功能就能保证万无一失了呢？
答案是，不一定。安全也有程度之分，剖析如下：
简单存储方案
方案由云服务提供商、云计算客户开发的业务系统、以及终端用户三个实体组成。几个关键组件说明如下：
(1) 云存储服务
云存储服务向业务服务器提供资源管理服务，向客户端提供资源上传和下载服务。
(2) 业务服务器
业务服务器需要开发者自行管理和维护，并且至少提供如下几个基本功能：
为客户端生成访问凭证（eg, 使用AK计算数据上传请求的签名），访问凭证的生成不能在客户端进行，否则会产生极大的安全风险。
管理用户帐号信息。最终的客户端用户信息的管理并非云存储服务的功能范畴。
使用数据库管理资源元数据和资源之间的关联关系。
响应客户端的业务请求，执行业务流程并返回执行结果。
(3) 客户端
客户端通常同时是数据的生产方和消费方。客户端在展示内容时，通常需要先从业务服务器获取资源的元信息，并得到必要的访问凭证，然后使用访问凭证从云存储服务获取数据内容。
下面以“客户端上传文件到云存储”的场景为例，操作步骤如下图（此图源自某云存储厂商）所示。
步骤1. 客户端向业务服务器请求上传文件的授权。
步骤2. 业务服务器根据客户端用户的业务数据，确定客户端需要访问的存储空间、存储对象及操作过期时间，构造请求消息并使用AK来计算消息签名，将签名作为“上传凭证”返回给客户端。
步骤3. 客户端使用上传凭证来上传文件数据到云存储服务。
步骤4. 返回结果。
这一方案非常简单，目前被很多云存储客户所使用。但是，该方案的安全性不强，它存在如下图所示的两个安全风险：
(1) 业务服务器所使用的AK权限过大，它拥有所有操作权限，那么这个AK很容易被误用而造成风险。从这个场景来看，业务服务器只需要具有给客户端颁发上传凭证的能力，而并不需要直接访问云存储，让它拥有完全权限显然不合适，比如，若出现系统程序bug或运维员工误操作而导致数据删除（这类事情常有发生），结果都会很悲剧。
(2) AK一旦泄露，问题很严重。任何人只要获取AK，在公网任何地方都能访问云存储数据，甚至彻底摧毁数据。企业的开发和运维人员最容易获取AK，所有获取AK的人都将具有摧毁云存储的能力。所以在客户实施这一方案时，安全性最终还是靠员工的价值观（而不是技术手段）来保证的。
说到这，可能有人会跳起来为某云存储的方案进行辩护，称其方案的安全性就是基于“业务服务器的AK不会泄露，也不会被内部员工误用”的假设。
没错，但小编在这里只想告诉大家：这一假设过于理想，它难以落地，客户在实际环境中很难构建这种理想的AK保护边界，这个可以参考最近乌云发布的漏洞报告。基于这种过强的假设来设计的系统，只不过是想简单地把安全责任推卸给云计算客户而已，很难保证实际环境中的客户数据安全。
以“阿里云OSS”为代表的安全方案
与前文描述的简单方案相比，阿里云安全方案有两个要求：
(1) 要求业务服务器使用“小AK”—— 一个访问权限可以被定制的AK，它可以让管理员根据最小权限原则来定制业务服务器的权限，而且可以限制请求发送者的源IP地址；
(2) 阿里云提供了一个安全令牌颁发服务（STS, SecurityToken Service），并要求业务服务器通过STS来申请访问凭证，而不允许由业务服务器在本地生成访问凭证。
补充说明：
(1) “小AK”是区别于云账号的“大AK”，它是由访问控制服务RAM提供。“小AK”代表的是企业客户下的应用程序身份，其访问权限可以被定制，支持最细粒度的授权策略，支持API调用方的源IP限制。在该方案中，“小AK”没有权限操作OSS，只有权限调用STS颁发凭证的API，并且限制了“小AK”的使用源IP。
(2) STS是为客户颁发自定义权限和时效的临时凭证颁发服务，通过STS所颁发的访问凭证的最大权限可以由客户指定，访问时效最长不超过1小时，支持API调用方的源IP限制。在此方案中，企业管理员可以限制“小AK”只能申请获取对某个子目录（比如，oss://mybucket/hangzhou/* ）里对象的某些操作权限的访问凭证，申请其它资源的访问凭证将被拒绝。
下面还是以“客户端上传文件到云存储”的场景为例来描述操作步骤，如下图所示。
步骤1. 客户端向业务服务器请求上传文件的授权。
步骤2. 业务服务器根据客户端用户的业务数据，确定客户端需要访问的存储空间、存储对象及操作过期时间，使用“小AK”向STS请求颁发上传数据的凭证。
步骤3. STS验证“小AK”是否具有调用STS获取凭证的权限，以及源IP地址限制，验证通过后颁发访问凭证并返回给业务服务器。
步骤4. 返回凭证给客户端。
步骤5. 客户端使用上传凭证来上传文件数据到云存储服务。
步骤6. 返回结果。
关于该方案的详细介绍请参考OSS相关安全文档。
相比于简单方案，此方案的设计相对复杂一点，但安全性更强，可以很好地解决前文描述的简单方案所存在的安全风险：
结语
上云之路多崎岖，还是要多备些安全锦囊，防患于未然。通过对比可以发现，阿里云存储方案设计具有更强的安全性，在一定程度上可以同时抵御内、外攻击，适合对数据安全要求苛严的企业客户，它可以有效避免因为AK泄露所带来的高危安全风险。
