带你读《从基础到应用云上安全航行指南》——干货长文快收藏！阿里云专家教你如何安全访问和管理ECS资源（2）：https://developer.aliyun.com/article/1441585
四、避免显示AK配置的最佳实践总结
接下来为大家介绍如何避免显示AK配置的最佳实践。
前面提到了RAM角色是一种虚拟的角色，ECS里面的RAM角色，它其实就是RAM角色的一种，他是使ECS的实例可以扮演某一种特定权限的角色，可以通过临时访问凭证STS去访问指定的云服务，比如ECS可以临时访问OSS的对象存储、访问数据库，这样最大的好处是您不需要在ECS内去保存用于访问云服务的明文AK信息，而且是由ECS的云服务通过角色扮演的方式来实现了与ECS实例和其他阿里云服务间的一安全通信。
为了实现这个效果，您可以在RAM的控制台上去创建一个RAM角色，指定的可信的实体类型是阿里云的服务，角色的类型是普通服务角色，授信的服务是ECS云服务器，为RAM角色进行授权，比如是可以只读的访问对象存储，在ECS的控制台上，选择指定的ECS实例，授予ECS实例的RAM角色就可以了。
接下来，我们通过给ECS关联的RAM角色来解决一个实际的安全隐患。
在很多用户的业务服务当中，经常会使用到MSE配置中心来管理日常、或者预发、或者线上各种环境的配置信息，由于配置项中往往存在敏感的数据，明文保存在配置中心是不安全的，但如果把配置项加密保存在MSE配置中心之后，又需要把加密之后的配置传给KMS进行解密，在过程中会使用到密钥等敏感的配置项，这些配置项如果在使用过程中落盘，比如落到了ECS实例里面，就会容易产生安全的风险。
这时候就可以通过给ECS的实例去关联一个RAM的角色，来无密钥的访问MSE的配置中心和KMS。通过给ECS的实例关联RAM角色，授予一个临时访问的权限，这时候就可以避免开发人员和用户，拥有解密配置项的能力。
这里ECS实例去访问MSE的配置管理的时候，使用的是MSE的SDK，在获取到了配置项，实际上这时候还是一个加密的配置项，这个加密配置项是封装在MSE的SDK当中的，这时候应用程序再拿加密的配置项，调用KMS的SDK，调用KMS的SDK之后返回的结果也是在KMS的SDK中，这里面全过程中所有的敏感配置项都不会落盘，都是在内存当中。好处就是用户无论是KMS的密钥的管理员，还是MSE的配置的管理员，他们都获取不到敏感的信息。
五、总结
最后我们对本次分享做一个总结：本次分享一共有三大部分，分别是身份认证、访问控制和一些进阶的安全方案。
如何提升身份认证的安全性？建议您开启主账号MFA的多因素多因子认证来增强主账号的安全性，不建议使用主账号的AK，而是给应用颁发子AK，避免将明文的AK暴露到外部的开发平台上，同时定期的去清理长期不使用的RAM用户。尽可能的使用具有时效性的临时的STS token。
提升访问控制安全性方面，建议您可以利用ECS已经预定义好的系统策略和自定义的RAM策略，为不同职责的人员授予权限，可以基于资源组，按照云资源的用途、部门结构等不同的维度来管理资源，授予不同用户访问不同资源组的权限，也可以使用标签对云资源进行细粒度的资源管理和控制。
在进阶方面，建议您可以使用ECS实例的RAM角色，将RAM角色关联到某个具体的ECS实例上，这样就可以避免将显示的AK配置落到ECS的本地，同时建议您能够启用操作审计ActionTrail，可以进行事后的行为分析和安全跟踪，来识别潜在的安全风险，满足合规审计的需求，建议您也开通免费的身份权限治理服务来定期检测身份和权限上的安全风险，及时完善云上身份和权限配置的安全性。
以上就是本次分享的全部内容。希望通过这个分享，能为您在
阿里云上安全的使用ECS，提供一些的帮助和建议，谢谢大家。
