关于信息安全:谈AK管理之进阶篇-如何有效控制云上最后一把密钥的风险

简介： 上一期“谈 AK 治理之根底篇”，咱们讲了如何标准的进行拜访密钥生命周期治理。通过分出不同权限的阿里云 RAM 子账号，将不同的权限分给不同的用户，这样一旦子账号泄露也不会造成全局的信息泄露。然而，因为子账号在个别状况下是长期有效的，因而，子用户的拜访密钥也是不能泄露的。

一、引言：

上一期“谈 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 拜访密钥的计划一如下形容。

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 实现权限的精细化管制和治理。

首先，咱们定一个非凡的角色，这个角色就是 ECS 实例角色，而后把这个角色授予这个特定的 ECS 实例，在这个实例里的利用能够通过如下流程进行残缺的阿里云 OpenAPI 拜访。

1. 在曾经授予了实例 RAM 角色的机器上的利用，能够向 ECS 的元数据服务申请 STS 长期拜访密钥；

curl http://100.100.100.200/latest…{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 平安问题，也正在成为企业拜访密钥治理的最佳实际。
原文链接
本文为阿里云原创内容，未经容许不得转载。