var
来源:网络作者:server发布时间:2016-07-18点击:2257
最近,小编看了乌云君发布一篇漏洞报告《假如你娶了云存储,这些姿势以后就别用了》,一下子就震惊了。企业要安全上云,还需提高自身的安全修养,否则可能都不知道是怎么死的。
报告里提到的几个上云的“受害者”,我猜都是“壕”。在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用户能访问的子目录都是不一样的。只有做到“最小权限+最短时效”,数据安全风险才能得到有效的控制。
写在最后
上云之路多崎岖,还是要多备些安全锦囊,防患于未然。企业级用户可以选择托管租用+服高可用/高并发+云监控的超级战舰模式。
版权声明:本文系技术人员研究整理的智慧结晶,转载勿用于商业用途,并保留本文链接,侵权必究!