KMS AK在阿里云上的管理方案

目录 SOLUTION

身份认证是所有系统和应用的基础功能,也是安全首要关注的风险场景,如果身份认证出问题,其它安全机制都形同虚设。

身份认证有很多形式,用户身份认证已经大批量用上了生物识别技术,但在服务和接口调用的身份认证一般还是使用账密和AK。服务器上的账密或AK需要妥善保管,通常安全团队会建议使用KMS解决敏感数据存储的问题,而访问KMS也需要认证,在阿里云上KMS访问使用AK,那么就有一个鸡生蛋蛋生鸡的问题,访问KMS的AK怎么存储。此文以阿里云为例,描述阿里云上服务认证管理的方案和实现原理。

在聊解决方案之前,要先确定防护的目的和范围,要防护的是发布过程中泄露AK,还有通过一些漏洞比如文件读取泄露AK。但如果攻击者获取了ECS实例的权限,那攻击者同时也拥有了访问授权给这台ECS实例的阿里云服务的权限,如KMS,这个没法防护,因为ECS上的应用是需要访问服务的,攻击者如果有ECS权限,就能伪造成应用去获取明文AK或者访问服务的凭证,不同的防护手段只是伪造难度不同。

解决方案是阿里云的RAM (Resource Access Management) 服务,这是阿里云提供的一项基础的资源访问控制服务,无需额外收费。方案的思路是把所有AK集中放到RAM的STS服务,然后给ECS实例分配Ram-Role,ECS实例中的应用程序通过分配的RAM-Role去STS请求一个默认有效期为6小时的临时STS-Token,ECS就可以用STS-Token去请求阿里云的服务了,其中就包括KMS。

Ff69e1471053c25b30eafb80f268101a59d7091a

详细的方案说明请参考:安全管理最佳实践系列:给ECS实例配置RAM角色,这里只介绍2个我曾经有过的困惑:

1. ECS Meta服务部署在每个ECS里,还是单独的服务?

— ECS Meta服务是单独的服务,是一个能管理ECS的底层服务,ECS实例中的应用程序要通过http://100.200.100.200才能访问ECS Meta服务,它接收ECS中应用程序的请求,对ECS进行身份验证,并向STS服务发起获取STS-Token的请求。

2. ECS Meta服务怎么校验ECS的身份,是否还有个AK?

— ECS Meta服务不是通过AK来校验ECS的身份,而是通过底层VPC网络的TunnelID实现ECS身份认证,每个ECS实例的底层TunnelID是唯一的,如果要伪造,需要攻破KVM和VPC底层系统,成本很高。这样就实现了AK的安全管理,回到防护范围的话题,如果攻击者获取ECS权限,还是可以访问RAM-Role下的阿里云服务,这种场景没有办法。

RAM服务这种使用”RAM小AK”取代云账号”大AK”的做法,还有很多收益,比如明文AK不需要共享、可以集中管理AK、可以开启MFA、随时撤销权限并且前向保密等等,是阿里云上企业账号安全管理的最佳实践。

暂无评论

发表评论

电子邮件地址不会被公开。 必填项已用*标注