最近，小编看了乌云君发布一篇漏洞报告《假如你娶了云存储，这些姿势以后就别用了》，一下子就震惊了。企业要安全上云，还需提高自身的安全修养，否则可能都不知道是怎么死的。

报告里提到的几个上云的“受害者”，我猜都是“壕”。在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的破产就是前车之鉴。

姿势3：限制应用程序的访问源IP

为了彻底防止因AK泄露所导致的风险，企业可以根据需要来设定访问云上仓库的源IP地址列表，应用程序发送操作请求的源IP地址如果不符合要求，那么就会被拒绝。只有源IP地址正确时，权限检查才会通过。

姿势4：为iOS或Android应用颁发临时访问令牌(Token)

永远不要将AK写到iOS或Android应用里。虽然App应用是企业开发的，但安装App的iOS或Android设备并不受企业的控制，记住永远不要将秘密放在不受控制的地方。

如果AK写到了App里，控制App设备的人总是可能猎取到AK，并且可能任意传播猎取的AK。一旦出现这种情况，开启源IP限制也于事无补，因为App用户的IP地址一般是无法确定的，开启源IP限制还会误伤其他正常用户。

对于这种场景，从安全角度看，只能给iOS或Android应用做临时授权，如5分钟自动失效；而且必须授予最小权限，如每一App用户能访问的子目录都是不一样的。只有做到“最小权限+最短时效”，数据安全风险才能得到有效的控制。

写在最后

上云之路多崎岖，还是要多备些安全锦囊，防患于未然。企业级用户可以选择托管租用+服高可用/高并发+云监控的超级战舰模式。