AK的应用场景极为广泛AK使用不安全的典型案例

简介：我们经常听到AK被外部攻击者恶意获取，或者员工不慎从github泄露，最终导致安全事故或者生产事故。AK的应用场景极其广泛，因此做好AK的管理和治理工作显得尤为重要。本文将分析介绍两个不安全使用AK的典型案例。

一、简介：

对于企业上云的典型场景，云账号管理员一般会为员工、应用程序或系统服务创建相应的用户账号。每个账户可以有一个独立的认证密钥，俗称AK（AccessKey），用于阿里云服务API的认证。既然是证明你是云账号合法拥有者的身份证明，一旦泄露后果会很严重。我们也经常听到AK被外部攻击者恶意获取，或者员工不慎从github泄露，最终导致安全事故或者生产事故。AK的应用场景极其广泛，因此做好AK的管理和治理工作显得尤为重要。

二、Access key 误删除，用户服务被屏蔽

典型案例再现

2020年，一位客户突然发现自己部分项目的用户APP上传数据失败。此上传数据功能使用云供应商上的存储服务。客户发起工单，认为云厂商的存储服务有问题。经调查，发现用户所在区域内其他业务方的生产活动正常，无明显异常；因此怀疑是网络问题，建议客户检查网络连接。这时客户在App端提交了错误日志，日志显示没有找到access key。在云客服的指导下，没有发现有相同ID的key存在，然后在操作审计记录中，

紧急处理

云产品建议客户立即更换使用的访问密钥。客户反映APP很难管控，尤其是iOS应用发布要审核，周期太长；客户紧急发布公告通知用户此功能暂时不可用。升级后恢复。

影响

影响是显而易见的。对于很多初创公司来说，这样的失败会导致用户体验不佳，最坏的情况是关键功能无法使用，公司的留存客户或收入都会受到不同程度的影响。

分析与结论

本次失败主要是员工误删AK造成的。有同学会说有密码的模块会被反编译吗，有没有类似垃圾站的功能可以回收？事实上，云厂商一般都会提供类似的功能，叫做激活/去激活，后面应该是“先禁用后删除”，以保证业务的正常连续性；另外，删除AK会导致服务器端出现故障。值得关注和自查的是，用户作为控件使用和服务器使用的不同场景是否有严格的区分？服务器使用和管理是分开的吗？员工和在线系统是分开的吗？应用程序中硬编码的访问密钥在发生泄漏时会导致高昂的更换成本。不能立即轮换完成业务止损。事实上，App 类业务不适合使用永久 AK 密钥访问 OpenAPI。另外，应用反编译、黑客攻击一直是频发事件，而永久密钥存储在代码中，泄露风险巨大！三、标准化接入密钥生命周期管理操作，确保安全生产

上述真实案例不仅给了我们巨大的警示，那么在哪些环节应该规范访问密钥呢？应该如何管理和控制它？

1.创建：访问密钥

2.配置：适当的权限

3.删除：访问密钥

访问密钥的删除是不可逆的，因此删除具有一定的风险。只有在安全确认访问密钥没有使用记录后才能删除。标准流程如下：

首先，用新的access key替换原来使用access key的地方，然后监控需要删除的access key的最后使用时间；根据自己的业务状态确定旧access key的过期时间，比如根据业务状态确定7天为安全时间，即如果access key 7天没有使用，可以尝试删除旧密钥；因此，在安全的时候，需要达到删除的效果，并在紧急情况下删除访问密钥。对于密钥检索，云供应商将提供一组此类操作来禁用/激活。使用禁用而不是删除操作。禁用操作可以达到和删除一样的效果，但是可以满足紧急情况下访问键的检索，即 通过 Activating 操作来恢复被禁用的访问密钥就像提供了一个垃圾桶功能；禁用access key后，继续观察业务是否有异常，直到最后一个安全时间，比如7天，如果没有异常有密码的模块会被反编译吗，就可以真正删除旧access key的使用记录。

4、 披露：密钥轮换

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

当需要翻转时，创建第二个访问密钥。在所有使用访问密钥的应用程序或系统中，将正在使用的访问密钥更新为新创建的第二个访问密钥。

注意：您可以在控制台的用户详情页的User AccessKey列表中查看Access Key的最后使用时间，从而初步判断第二个Access Key是否被使用过，以及原Access Key是否未被使用过.

3 禁用原始访问密钥。

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扫描；

云厂商也有类似的方案来帮助客户进行检测，比如阿里云安全中心的AK泄漏检测。

异常访问密钥使用检测

这种分析主要是分析与密钥本身实际使用相关的数据和日志，看是否出现异常。

供应商解决方案 – 运营审计

开启操作日志审计，并将其交给OSS和SLS进行长期存储和审计，并将操作日志存储在OSS中，以备出现异常情况时进行确认；当日志量大时，操作日志会下发到 SLS 来帮助您。高效的检索也是可能的。

供应商解决方案 – 访问日志审计

除了云产品的操作日志之外，还有大量的云产品访问日志，这些日志往往是数据访问的主要部分，比如OSS存储桶上数据的写入、获取、修改、删除等. 这部分日志可以直接通过阿里云提供的日志服务进行采集、存储、统计和分析。在各云产品的控制台开启日志功能后，您可以进行与日志服务相关的操作。

本地解决方案——自建分析引擎

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

统计分析

可以监控告警和分析的维度如下。您可以通过以下相关维度的日常监控，观察各个维度是否出现意外访问。如果出现，说明访问密钥可能已经泄露，需要重点关注：

四、总结

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

禁止使用主账户，

子账户进行隔离；

记住一次密码。

必须牢记 AK 的机密性；

不要乱搞泄漏，

必须先封禁后删除；

分配了两个AK，

定期审核很重要；

无钥匙的终极安全。