阿里云：网传“可重置任意阿里云服务器root密码”为虚假信息

阿里云安全专家确认：网络传闻“可重置任意阿里云服务器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/这个目录”。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!