简介：我们也常有听说例如AK被外部攻击者恶意获取，或者员工无心从github泄露的案例，最终导致安全事故或生产事故的发生。AK的应用场景极为广泛，因此做好AK的管理和治理就尤为重要了。本文将通过两种AK使用不安全的典型案例，进行分析和介绍。

一、引言：

对于企业上云的典型场景，云账号管理员一般会给员工、应用程序或系统服务创建一个相应的用户账号。每个账号都可以有独立的身份认证密钥，俗称AK (AccessKey)，它用于阿里云服务API的身份认证。既然是身份证明，证明你是某个云账号的合法拥有者，那么一旦泄露后果着实严重。我们也常有听说例如AK被外部攻击者恶意获取，或者员工无心从github泄露的案例，最终导致安全事故或生产事故的发生。AK的应用场景极为广泛，因此做好AK的管理和治理就尤为重要了。本文将通过两种AK使用不安全的典型案例，进行分析和介绍。

二、访问密钥误删，用户服务受阻

典型案例重现

2020年，某客户突然发现自己的一些项目的用户APP上传数据出现失败，这个上传数据功能使用了该云厂商上的某存储服务，客户发起工单认为云厂商的存储服务有故障。经排查发现该用户的Region其他业务方的生产活动正常，未出现明显异常；遂怀疑网络问题，建议客户查询网络连接，此时客户提交App端的错误日志，日志中显示是访问密钥没有找到，在云客服的指导下，并未发现有相同ID的密钥存在，然后在操作审计的记录中，发现该访问密钥是被其自己内部做了删除操作。

紧急处理

云产品建议该客户对使用的访问密钥马上替换，客户反馈APP上不好控制，特别iOS的app发布还要审核，周期太长；
客户紧急发布公告，通知其用户此功能暂时不可用，待升级后恢复。

影响

影响显而易见，对很多初创企业这样的故障会轻则导致用户体验差，重则关键功能不可用，对企业留存客户或者收入都会受到不同程度的影响。

分析和总结

这次故障主要是由于员工误删除AK导致，有的同学就会说，能不能有个类似垃圾站的功能，还可以回收？其实云厂商一般都会提供一个类似的功能叫激活/禁用，应当遵循“先禁用再删除”，以确保业务的正常持续；
此外，AK删除导致服务端的故障，值得引起注意和自查的是，用户作为管控和服务端使用的不同场景，是不是做了严格的区分？服务端使用和管控是否区分开等？员工和线上系统是否区分开？
App应用中硬编码访问密钥，导致出现泄漏时，替换成本很大，不能马上进行轮转替换完成业务止损；其实App类业务不适合使用永久AK密钥来访问OpenAPI。
此外，应用反编译，hack已经是多发事件了，代码中存放永久密钥，泄露的风险巨大！

三、规范的访问密钥生命周期管理操作，保障安全生产进行

上述真实的案例不仅带给我们巨大的警示，那么针对访问密钥究竟在哪些环节进行规范操作？又应当通过什么办法进行管理控制呢？

1 、创建：访问密钥

再次敲黑板，不推荐使用主账号的访问密钥，原因很明显，主账号拥有的资源和权限太大，泄露后的风险不堪设想；
可以通过云厂商的访问控制等页面查看，有没有创建租户级别下的子用户，并实际使用的是这些子用户的访问密钥。

2 、配置：合适的权限

每个不同的应用使用不同子用户的访问密钥，这样可以做到应用级别资源和权限隔离；
每个子用户的权限是不是满足了最小可用原则，不扩大不要的权限；可以在测试环境试着减少权限，看看测试是不是能正常，不正常的话大概率这个权限是不能去除的；
通过RAM访问控制台查询，可以看到某一个用户所具有的权限Policy，以及Policy里具体的权限描述。

3 、删除：访问密钥

访问密钥的删除是不可恢复的，所以删除是具有一定风险的，只有在安全确认这把访问密钥没有任何使用记录后，才能删除，标准的流程如下：

首先把原来访问密钥使用的地方替换为新的访问密钥，然后监控需要删除的访问密钥的最后使用时间；
按照自己业务的状况，确定老的访问密钥的失效时间，比如根据业务状况确定7天为安全时间，即一把访问密钥7天没有使用记录就可以尝试删除老的密钥；
所以在安全时间既要到达删除的效果，又要在出现突发状况下把删除的访问密钥找回，云厂商都会提供一组这样的操作禁用/激活，使用禁用代替删除操作，禁用操作可以达到和删除一样的效果，但是可以满足突发状况下访问密钥的找回，即通过激活操作，把禁用的访问密钥恢复过来，就如同提供了一个垃圾箱的功能；
在访问密钥进行禁用后，持续观察业务是否有异常，直到一个最终安全时间，比如7天，如果没有任何老的访问密钥的使用记录，就可以真实删除了。

4、泄露：密钥轮转

每个RAM用户最多可以创建两个访问密钥。如果您的访问密钥已经使用3个月以上，建议您及时轮换访问密钥，降低访问密钥被泄露的风险。

在需要轮转的时候，再创建第二个访问密钥。
在使用访问密钥的所有应用程序或系统中，更新正在使用的访问密钥为新创建的第二个访问密钥。
说明：可以在控制台的用户详情页的用户AccessKey列表中，查看访问密钥的最后使用时间，以此初步判断第二个访问密钥是否已经被使用，原来的访问密钥是否已经不用。

3 禁用原来的访问密钥。

4 验证使用访问密钥的所有应用程序或系统是否正常运行。

如果运行正常，说明访问密钥更新成功，您可以放心地删除原来的访问密钥。
如果运行异常，您需要暂时激活原来的访问密钥，然后重复步骤2~4的操作，直至更新成功。

5 删除原来的访问密钥。

5 开发：避免密钥硬编码到代码

系统属性

在系统属性里寻找环境凭证，如果定义了 alibabacloud.accessKeyId 和
alibabacloud.accessKeyIdSecret 系统属性且不为空，程序将使用它们创建默认凭证。

环境凭证

在环境变量里寻找环境凭证，如果定义了
ALIBABA_CLOUD_ACCESS_KEY_ID和
ALIBABA_CLOUD_ACCESS_KEY_SECRET环境变量且不为空，程序将使用它们创建默认凭证。

配置文件

如果用户主目录存在默认文件
~/.alibabacloud/credentials （Windows 为 C:\Users\USER_NAME\.alibabacloud\credentials），程序会自动创建指定类型和名称的凭证。默认文件可以不存在，但解析错误会抛出异常。配置名小写。不同的项目、工具之间可以共用这个配置文件，因为不在项目之内，也不会被意外提交到版本控制。可以通过定义
ALIBABA_CLOUD_CREDENTIALS_FILE 环境变量修改默认文件的路径。不配置则使用默认配置 default，也可以设置环境变量 ALIBABA_CLOUD_PROFILE 使用配置。

[default]                          # 默认配置
enable = true                      # 启用，没有该选项默认不启用
type = access_key                  # 认证方式为 access_key
access_key_id = foo                # Key
access_key_secret = bar            # Secret[client1]                          # 命名为 `client1` 的配置
type = ecs_ram_role                # 认证方式为 ecs_ram_role
role_name = EcsRamRoleTest         # Role Name[client2]                          # 命名为 `client2` 的配置
enable = false                     # 不启用
type = ram_role_arn                # 认证方式为 ram_role_arn
region_id = cn-test                # 获取session用的region
policy = test                      # 选填 指定权限
access_key_id = foo
access_key_secret = bar
role_arn = role_arn
role_session_name = session_name   # 选填[client3]                          # 命名为 `client3` 的配置
type = rsa_key_pair                # 认证方式为 rsa_key_pair
public_key_id = publicKeyId        # Public Key ID
private_key_file = /your/pk.pem    # Private Key 文件

6、审计：定期分析访问密钥使用行为

通过规范访问密钥生命周期的管理操作，可以解决大部分由于不当操作导致的安全故障，但是很多安全问题，是需要分析访问密钥的使用数据才能发现的。

访问密钥存储泄露探测：是不是硬编码到代码里去了？可以借助代码托管平台提供一些服务来检测比如 Github Token scan；

云厂商也有类似一些方案帮助客户做检测，比如阿里云云安全中心的AK泄露检测。

异常访问密钥使用探测

这种分析主要是对密钥本身的实际使用相关的数据，日志等做分析，来看是否已经出现了异常。

厂商方案-操作审计

开启操作日志审计，并将其投递至OSS和SLS长期保存和审计，将操作日志存储至OSS，异常情况时可以起到固证的作用；操作日志投递至SLS，帮助您在日志数量大的时候也能实现高效检索。

厂商方案-访问日志审计

除了云产品的操作日志外，还有大量的云产品使用访问日志，这一部分也往往是数据访问的主要部分，比如OSS的Bucket上数据的写入，获取，修改和删除等。这部分日志可以直接通过阿里云提供的日志服务来做到收集，存储，统计和分析等，您在各个云产品控制台开通日志功能后，即可执行日志服务相关操作。

本地方案-自建分析引擎

对一些操作日志审计里没有记录的产品的访问日志，也可以通过云产品提供日志存储功能把这些日志记录并下载下来，通过自己离线的计算，和定时比较，发现上述异常访问记录。

统计分析

可以监控报警和分析的维度如下，可以通过下面相关维度的日常监控，来观测是否在各个维度上出现了非预期的访问，如果出现就预示了访问密钥可能已经出现泄漏，需要重点关注了：

使用访问密钥的IP是否是自有的机器的IP；
使用访问密钥的产品是否是自己购买过的；
使用访问密钥的region是否是自己预期的；
使用访问密钥的时间是不是服务自己的业务规律。

四、总结

本文从访问密钥的生命周期管理进行了分析和介绍，希望对于您在云上密钥管理能够有所启发和帮助。最后，附上AK使用锦囊：

禁止使用主账号，

子账号来隔离好；

密码一次要记好，

AK保密要记牢；

泄露先别乱阵脚，

先禁再删不可少；

两把AK分配好，

定期审计很重要；

究极安全无密钥。

原文链接

本文为阿里云原创内容，未经允许不得转载

谈AK管理之基础篇 - 如何进行访问密钥的全生命周期管理？相关推荐

Eolink神技之二、API全生命周期管理
Eolink神技之二.API全生命周期管理目录 Eolink神技之二.API全生命周期管理 Eolink全API全生命周期管理解决的问题演示过程一.创建项目文档 1.1.创建项目 1.2.项目管 ...
谈业务流程全生命周期管理支撑业务流程再造（3）
5.如何使用业务流程全生命周期管理能力平台在使用能力平台时,需要先了解流程能力平台生态环境. 生态环境说明如下: 生产环境:是按设计要求为全体用户提供生产支撑的信息系统环境,系统上所以业务应用都是经 ...
PPT 下载 | 神策数据孙文亮：客户全生命周期管理从方法到实践全解析
在以"场景赋能·驱动有数"为主题的神策 2018 数据驱动大会现场,神策数据技术经理孙文亮发表了名为<客户全生命周期管理从方法到实践>的主题演讲. 温馨提示:点击文末阅 ...
如何发布接口_Devops下的接口全生命周期管理与测试
什么是devops?随着时间的推移,devops的定义也在不断的演进.对于其定义可能出现千人千面,但从核心观点,整体业界还是保持着一致的认识.DevOps不是单一的技术或者工具,甚至不只是一个流程,而 ...
数据全生命周期管理应用平台的组成
一个智能敏捷的数据全生命周期管理应用平台,从主数据管理.元数据管理.数据质量.数据标准以及数据安全五大方面,全方位保障企业业务数据在采集.集成.交换.存储.应用等一系列业务流程中的完整性.准确性.一致 ...
从方法到实践：主数据全生命周期管理
也许您已经听过这个故事:一个顾客走进一家商店来退掉雪地轮胎,尽管这家零售商不卖雪地轮胎,但他们还是欣然接受了退货.另外一位客户,他在网上订购的价值200美元的鞋子被UPS快递司机淋了雨,客户只打一个电 ...
字节跳动无恒实验室首次亮相Black Hat 2021亚洲黑帽大会：全生命周期管理的隐私保护框架
5月4日至7日,Black Hat Aisa 2021(亚洲黑帽大会)如期在线上举行.Black Hat大会被公认为世界信息安全行业的最高盛会,被誉为黑客世界的"奥斯卡",也是最具 ...
“讲得清，控得住，降得下”——红辽公司备件全生命周期管理创新实践
"去产能.去库存.去杠杆.降成本.补短板"是当前烟草行业高质量发展的重点工作.红塔辽宁烟草有限责任公司(简称红辽公司),为落实其中"去产能.去库存.降成本" 有 ...
设备全生命周期管理第一股凌雄科技上市，京东、腾讯等长期看好
"设备全生命周期管理第一股"凌雄科技(小熊U租)于昨日正式在港交所挂牌上市.本次上市,凌雄科技的IPO发行价为7.60港元/股,募集资金净额约为3.372亿港元,上市时的总市值达到 ...

谈AK管理之基础篇 - 如何进行访问密钥的全生命周期管理？