安全管理最佳实践系列:给ECS实例配置RAM角色
2018-01-08 14:56
836 查看
问题描述
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泄露及运维难的问题。
原文链接
相关文章推荐
- 第4.1.2章 WEB系统最佳实践页面实例 角色管理
- ECS实例RAM角色实践
- 安全管理最佳实践系列:阿里云Access Key的轮转
- ECS实例RAM角色实践
- 安全管理最佳实践系列:账号管理
- Web服务器管理系列:6、网络和共享中心的安全配置
- 项目管理小公司最佳实践系列(一) 项目过程会议规格说明
- Zookeeper和Curator-Framework实践系列之: 配置管理
- 用 IIS 进行ASP.NET 成员/角色管理(1):安全和配置概述
- CMMI 配置管理(Configuration Management)系列(2)角色职责
- [最佳实践]基于Struts2+Spring+iBatis的web应用最佳实践系列之一(自动配置篇)
- JBoss 7/WildFly 配置管理,开发示例,架构分析,最佳实践
- saltstack自动化运维系列⑦SaltStack实践配置管理安装zabbix
- saltstack自动化运维系列⑧SaltStack实践配置管理安装nginx-1.10.3
- 第119讲:HDFS的配置以及安全高效的HDFS配置最佳实践学习笔记
- SpringCloud系列四:Eureka 服务发现框架(定义 Eureka 服务端、Eureka 服务信息、Eureka 发现管理、Eureka 安全配置、Eureka-HA(高可用) 机制、Eureka 服务打包部署)
- Zookeeper和Curator-Framework实践系列之: 配置管理
- 安全模式:J2EE、Web服务和身份管理最佳实践与策略