简介： 上一期“谈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拜访密钥的计划一如下形容。
- 客户的利用应用阿里云颁发给账户A的拜访密钥签名拜访RAMOpenAPI的申请，发给网关；
- 阿里云网关在验证身份和API的权限校验通过后，将申请发送到RAM的OpenAPI，申请颁发STS长期拜访密钥；
- 阿里云RAM的OpenAPI颁发STS长期拜访密钥；
- 阿里云网关将申请的STS长期拜访密钥返回给调用方-云客户利用；
- 云客户利用再将获取的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拜访。
- 在曾经授予了实例RAM角色的机器上的利用，能够向ECS的元数据服务申请STS长期拜访密钥；
curl http://100.100.100.200/latest...{RAM角色名称}
- ECS元数据服务返回曾经获取的STS长期拜访密钥给客户的利用
{ "AccessKeyId" : "STS.XXXXXXX", "AccessKeySecret" : "XXXXXXX", "Expiration" : "2019-09-24T09:05:00Z", "SecurityToken" : "XXXXXXX", "LastUpdated" : "2019-09-24T03:05:00Z", "Code" : "Success" }
- 客户的利用能够把获取的STS长期拜访密钥分发给本人的其余利用；
- 客户的其余利用从而应用取得的STS长期拜访密钥失常拜访阿里云服务的OpenAPI。
除了ECS，阿里云的一些其余运行环境（ECI，ContainerService，FuntionCompute）都有相似的平安实现，在应用了此类平安实现后，用户不在须要间接把拜访密钥AccessKey固化在实例中，如写在配置文件中，硬编码在代码中等不平安的存储拜访密钥。
五、总结
AK泄露问题导致企业安全事故或生产事变已有大量的案例，施行无密钥拜访计划将会无效解决AK平安问题，也正在成为企业拜访密钥治理的最佳实际。
原文链接
本文为阿里云原创内容，未经容许不得转载。