安全管理最佳实践系列：给ECS实例配置RAM角色

问题描述

AK(AccessKey)是代表用户身份的钥匙，是用户访问阿里云API的身份认证密钥。如果部署在ECS实例中的应用程序需要访问各种阿里云服务API，用户通常会将AK保存在应用程序的配置文件中，使得应用程序能读取AK来调用阿里云服务API。这里存在两个问题：(1) 保密性问题。不管AK以何种形式存在于实例中，它都可能随着快照、镜像及镜像创建出来的实例被泄露。(2) 难运维性问题。由于AK存在于实例中，如果要更换AK（比如周期性轮转或切换用户身份），那么需要对每个实例和镜像进行更新并重新部署，这会极大增加对实例和镜像管理的复杂性。

针对保密性问题的通常解法是借助加解密(Crypto)或访问控制(Access Control)技术。

加密方案

由于AK本身也是一种密钥，而加解密技术通常不适合保护密钥本身，因为总有最后一把密钥(Last Key)是需要保护的，所以加密技术这里不实用。当然可能有少数区域的ECS实例提供了可信加密设备支持（比如HSM、TPM或SGX），但基于硬件来保护Last Key的方法是另一个专题，本文不做讨论。

访问控制方案

一种简单有效的AK保护做法是采用访问控制技术。比如，可以使用操作系统提供的访问控制机制来保护存放AK密钥的配置文件，比如

$ chmod 400 ~/.aliyuncli/credentials (只允许当前用户可读) 在用户登录管理严格的条件下，这种机制可以起到一定的保护作用。但由于AK本身没有加密，通过快照或镜像泄露之后就可能绕过访问控制机制，仍然可能泄漏。

针对难运维性问题就难解了，只要AK存在于实例文件中，对大量实例和镜像的管理复杂性就无法降低。

我有几张阿里云幸运券分享给你，用券购买或者升级阿里云相应产品会有特惠惊喜哦！把想要买的产品的幸运券都领走吧！快下手，马上就要抢光了。

阿里云的技术方案

站在操作系统设计的角度，用户态中难解的问题，在内核态看来根本不是事。同样，ECS实例中难解的问题交给ECS管控来解，也不是难题。

阿里云ECS结合RAM (Resource Access Management)提供的访问控制能力，针对此问题提供了一个根本的解决方法 —— 通过给ECS实例配置RAM角色来避免AK泄露及运维难的问题。

原文链接