前言

如今越来越多公司选择使用云平台，诸如:阿里云、腾讯云、AWS、Azure。使用云平台大大降低了企业的资源成本，另一方面随着公用云的普及，也存在着一些风险。现代应用程序需要与其他外部应用程序通信，并且它们需要内部服务到服务的通信。这意味着访问任何服务、应用程序和数据都需要大量凭证或密钥。而密钥泄漏、配置不当等问题正引起的越来越安全问题。

常见的密钥

1. 用户凭据

这些通常是用户名和密码组合，用于验证物理用户以及授予对受保护数据、服务或端点的访问权限。它们绑定到特定用户。

2.数据库连接字符串

连接字符串将应用程序连接到数据库服务器。因此它将包含建立与目标数据库或文件的连接所需的所有凭据（秘密）。

3. 密钥

这些可确保通过风险介质进行安全通信，并有助于身份验证和用户身份验证。秘密包含加密和解密密钥。

4.云服务访问凭证(AK)

访问云服务提供商提供的数据、资源和服务器所需的秘密。它们包含确认访问云资源的用户身份验证所需的凭据。

5. 应用程序编程接口 (API) 密钥

识别 API 请求来源所需的秘密。

6. 访问令牌

发出 API 请求以支持用户所需的秘密。

云服务访问凭证(AccessKey)

虽然有很多密钥类型都需要我们关注，今天我们主要讨论的就是云服务的访问凭证。

AccessKey（即访问密钥）是云平台用户在通过API访问云资源时用来确认用户身份的凭证，以确保访问者具有相关权限。AccessKey由云平台提供商（如亚马逊AWS、阿里云等）颁发给云主机的所有者，一般由AccessKeyID（访问密钥ID）和Secret Access Key（私有访问密钥）构成。

主要的泄露方式

1.硬编码产生泄露

例如将AK/SK硬编码到程序代码/配置文件中，攻击者只需要对小程序包进行反编译即可获取AK/SK，例如下面的代码配置文件中，直接包含了AK/SK的信息，如果攻击者获取了相关内容就可以直接拿到，并进行后续动作。

同时，由于github等代码托管仓库的风靡，是越来越的项目得到开放和传播，但是如果在开发时不慎将AK/SK泄露，产生的影响也会随之而扩大。

常见的信息获取方式如搜索github，FOFA等

2.云存储泄露

随着越来越多数据到云端，我们可能会看到更多配置错误导致意外的数据泄露。如果存储桶因意外或故意原因让任何人都可以访问，那么，如果这些文件的权限被设置为公开，则存储桶中所有数据都可能被泄露。即使数据不是机密数据，这些数据也可能被用于进一步攻击，也许通过分析文件中的元数据。常见的配置错误如：

Bucket允许任意文件上传和读取
bucket允许匿名访问
bucket允许列出文件
bucket允许盲上传
bucket允许任意读取/写入对象
bucket显示ACP/ACL

而这些问题大部分的产生是由于客户配置错误，凭证管理不当泄漏，而不是云提供商方面的漏洞。

3.网络请求泄露AK/SK

通过后端API将AK/SK返回到前端，攻击者只需要对程序进行网络抓包，即可获取后端返回的AK/SK，举例如下，可以清楚看到该API的返回内容泄露了多个公有云厂商的AK/SK

一些优化建议

优化开发并配合检测工具

针对硬编码带来的安全问题，首先需要解决额就是问题的源头，所以我们需要提升开发者的安全意识和安全习惯，这样可以最大程度的避免问题的发生。

当然问题不会那么理想，很多时候由于人员水平和管理水平的局限性，无法要求所有的开发人员都能做到完全的自我安全管理，那这个时候我们就要配合必要的安全检测工具，在代码提交到仓库前，发现其中潜在的AK/SK泄露问题。将两者结合可以更好的优化和解决问题。

监控和审计

要配合适当的监控和审计能力，监控是为了实时的去发现问题的出现，而审计则更加关注问题出现后的处理和追溯。配合适当的工具和能力，这样一旦发生了泄露事件，我们可以根据监控和审计情况，快速定位问题的影响范围，并锁定攻击者，快速处理和修复。

这部分能力，大多数的云供应商都有提供相关工具，当然基于云中的责任共担模型，使用工具和管理上层安全是需要用户去负责的，所以最关键的问题还是在用户层面。

建立持续性云上安全检测机制

最后也是最重要，针对云上层出不穷的安全问题，错误配置是最常见的原因，“1%的错误配置会让99%的安全防护工作失去意义”。对已经上云的资源，建立持续性的机制，主要通过预防、检测、响应和主动识别云基础设施风险，持续管理云安全状况，以及企业的安全策略，主动与被动结合，发现评估云服务的安全配置风险，一旦发现问题，可以提供自动或者人工的补救措施。