谈AK管理之进阶篇 - 如何有效控制云上[最后一把密钥]的风险?

谈AK管理之进阶篇 - 如何有效控制云上[最后一把密钥]的风险?

一、引言:

上一期“谈AK管理之基础篇”,我们讲了如何规范的进行访问密钥生命周期管理。通过分出不同权限的阿里云RAM子账号,将不同的权限分给不同的用户,这样一旦子账号泄露也不会造成全局的信息泄露。但是,由于子账号在一般情况下是长期有效的,因此,子用户的访问密钥也是不能泄露的。

二、泄露挑战

AK通常的泄露途径会有哪些呢?我们先从用户的使用方式来分析和发现:

1. 硬编码在代码里

很多用户对访问密钥的安全意识不够或者没有意识到风险,为了使用方便,会直接把访问密钥的二元组写在代码里,供程序使用;在现在反编译和内存分析的技术已经很成熟的当下,硬编码的方式无异于明文存储密钥,有巨大的泄露风险。

2. 第三方密钥存储

还有很多客户了解访问密钥的重要性,会使用第三方的密钥存储系统或者配置文件,将原始的密钥加密起来。这种方式的做法加延了密钥泄露的链路,但本质上只是原始密钥泄露的风险转移到另外一把密钥上,比如第三方密钥存储系统的访问key,或者是加密的密钥,归根结底还是会存在“最后一把密钥”的安全泄露风险。比如避免密钥硬编码到代码中提到的:系统属性,环境凭证,配置文件等。

三、无密钥访问方案-基础

针对访问密钥的泄露高风险,我们有没有一些方案既能克服“最后一把密钥”的风险,又能很方便的进行可控的身份认证呢?很自然,我们会想出来的第一个方案:既然长期的访问密钥权限大,我们能不能换一种短期且权限可控的访问密钥呢,这就要介绍阿里云的另外一种身份类型和与之相对应的访问密钥。

阿里云虚拟身份

RAM角色(RAM role)与RAM用户一样,都是RAM身份类型的一种,只不过RAM角色是一种虚拟用户,没有确定的身份认证密钥,需要被一个受信的实体用户扮演才能正常使用。简单说,可信实体扮演RAM角色,并使用角色令牌去访问RAM角色里规定的资源以及资源上的OpenAPI。

RAM角色

RAM角色有确定的身份,可以被赋予一组权限策略,但没有确定的登录密码或访问密钥。RAM角色需要被一个受信的实体用户扮演,扮演成功后实体用户将获得RAM角色的安全令牌,使用这个安全令牌就能以角色身份访问被授权的资源。

可信实体(Trusted entity)

角色的可信实体是指可以扮演角色的实体用户身份。创建角色时必须指定可信实体,角色只能被受信的实体扮演。可信实体可以是受信的阿里云账号、受信的阿里云服务或身份提供商。

角色令牌(Role token)

角色令牌是角色身份的一种临时访问密钥。角色身份没有确定的访问密钥,当一个实体用户要使用角色时,必须通过扮演角色来获取对应的角色令牌,然后使用角色令牌来调用阿里云服务API。

对于虚拟身份类型(角色身份),对应的OpenAPI访问凭证就是上面说的角色令牌,是一种时效和权限可控的临时访问密钥。相对于阿里云实体身份的访问密钥的长效控制机制,STS提供的是一种临时访问授权。通过STS可以返回临时的访问密钥和令牌,这些信息可以直接发给临时用户用来访问阿里云服务。一般来说,从STS获取的权限会受到更加严格的限制,并且拥有时间限制,因此这些信息泄露之后对于系统的影响也很小。

阿里云用户在RAM中,定义一个角色,并授权了可以扮演此角色的可信实体,比如某主账户下的子用户账号A,然后授权账户可以访问RAM的接口获取临时访问密钥。账户A的访问流程就如下描述了。所以结合了STS访问密钥的方案一如下描述。

谈AK管理之进阶篇 - 如何有效控制云上[最后一把密钥]的风险?

  1. 客户的应用使用阿里云颁发给账户A的访问密钥签名访问RAMOpenAPI的请求,发给网关;
  2. 阿里云网关在验证身份和API的权限校验通过后,将请求发送到RAM的OpenAPI,请求颁发STS临时访问密钥;
  3. 阿里云RAM的OpenAPI颁发STS临时访问密钥;
  4. 阿里云网关将申请的STS临时访问密钥返回给调用方-云客户应用;
  5. 云客户应用再将获取的STS临时访问密钥分发给其自己的终端或者别的应用系统;

6- 9步和我们在前言里介绍的一样,应用使用访问密钥正常访问阿里云服务的OpenAPI,只不过这里使用的是STS临时访问密钥了。

四、无密钥访问方案-进阶

无密钥访问方案-基础方案里,我们把权限较大的长期访问密钥,替换成了STS临时访问密钥,由于STS在时间等属性上有限制,这样可以把原来泄露长期访问密钥带来的风险降低到短时间维度,做到了一定程度的安全风险减小,但细心的同学还会发现,要获取一个STS临时访问密钥,还是需要云账户或者其RAM子用户的长期访问密钥,也还是没有解决“最后一把密钥”的问题。


既然阿里云RAM提供了角色功能,并能把这个角色授权给实体,这个是实体是账户或者服务,那可不可以把这个角色和某些特定实体关联呢,比如某个IP,某个区域后者环境等。这种环境可以映射到什么实体呢?我们看现阶段客户的应用绝大部分会运行在机器,docker容器或者某个运行环境(Serverless)里,在这个特定的范围里,比如某个机上,是否可以实现免输入长期访问密钥而调用RAM的OpenAPI获取STS临时访问密钥呢。我们接下来引入阿里云ECS的一个特殊角色来举例。

实例RAM角色

ECS实例RAM(Resource Access Management)角色让ECS实例扮演具有某些权限的角色,从而赋予实例一定的访问权限。实例RAM角色允许用户将一个角色关联到ECS实例,在实例内部基于STS临时凭证(临时凭证将周期性更新)访问其他云产品的API。一方面可以保证AccessKey安全,另一方面也可以借助RAM实现权限的精细化控制和管理。

谈AK管理之进阶篇 - 如何有效控制云上[最后一把密钥]的风险?

首先,我们定一个特殊的角色,这个角色就是ECS实例角色,然后把这个角色授予这个特定的ECS实例,在这个实例里的应用可以通过如下流程进行完整的阿里云OpenAPI访问。

  1. 在已经授予了实例RAM角色的机器上的应用,可以向ECS的元数据服务请求STS临时访问密钥;
curl http://100.100.100.200/latest/meta-data/ram/security-credentials/{RAM角色名称}
  1. ECS元数据服务返回已经获取的STS临时访问密钥给客户的应用
{
  "AccessKeyId" : "STS.XXXXXXX",
  "AccessKeySecret" : "XXXXXXX",
  "Expiration" : "2019-09-24T09:05:00Z",
  "SecurityToken" : "XXXXXXX",
  "LastUpdated" : "2019-09-24T03:05:00Z",
  "Code" : "Success"
}
  1. 客户的应用可以把获取的STS临时访问密钥分发给自己的其他应用;
  2. 客户的其他应用从而使用获得的STS临时访问密钥正常访问阿里云服务的OpenAPI。

除了ECS,阿里云的一些其他运行环境(ECI,ContainerService,FuntionCompute)都有类似的安全实现,在使用了此类安全实现后,用户不在需要直接把访问密钥AccessKey固化在实例中,如写在配置文件中,硬编码在代码中等不安全的存储访问密钥。

五、总结

AK泄露问题导致企业安全事故或生产事故已有大量的案例,实施无密钥访问方案将会有效解决AK安全问题,也正在成为企业访问密钥管理的最佳实践。

上一篇:Python 入门篇-用Notepad++编写出第一个python程序


下一篇:如何利用 CSS 的动画原理,创作一个乒乓球对打动画