dsf

如今各家云厂商都通过给用户提供API调用的方式来实现一些自动化编排方面的需求。为了解决调用API过程中的通信加密和身份认证问题，大多数云厂商会使用同一套技术方案—基于非对称密钥算法的鉴权密钥对，这里的“密钥对”即API凭证，是云上用户调用云服务API、访问云上资源的唯一身份凭证。

在信息安全领域有一个广为认可的假定，即所有系统都是可攻破的，这里的“攻破”是广义的，可以是外部攻击，也可以是恶意内部威胁（insider threat），当然也可能是无心泄漏导致的潜在威胁。API凭证（在阿里云被称为AccessKey）作为用户访问内部资源最重要的身份凭证，被外部人员恶意获取或被内部员工无心泄露的案例时有发生，其导致的数据泄露非常严重，因此如何做好API凭证管理和监测就显得非常重要。

一、API凭证的安全现状

API凭证相当于登录密码，只是使用场景不同。前者用于程序方式调用云服务API，而后者用于登录控制台。

在阿里云，用户可以使用AccessKey构造一个API请求（或者使用云服务SDK）来操作资源。AccessKey包括AccessKeyId和AccessKeySecret。其中AccessKeyId用于标识用户，AccessKeySecret是用来验证用户的密钥。AccessKeySecret必须保密。在阿里云，它们看起来像这个样子：

（图1）阿里云AK样式（图1）阿里云AK样式

在大多数AK泄露的案例中，都是开发者不小心将自己的AccessKey提交到了任何人都可以访问的公共代码托管平台，导致安全防线毁于一旦。

笔者做了一个简单的测试，在开源代码托管网站Github上搜索一些特定的关键字，可以看到搜索结果近3万条，稍微进一步查找，就能发现某个用户在项目里将自己的AccessKey直接写在代码中。

（图2）泄漏的凭证（图2）泄漏的凭证

笔者曾在不同的代码托管平台搜索了不同云平台的凭证格式，都能发现存在或多或少的凭证漏，这已经是一个普遍的安全问题。

北卡罗莱纳州立大学的一篇研究报告则直接指出，“我们在涉及到的10万开源项目中发现，凭证泄漏问题不是一次性偶然问题，而是每天都在发生的，有数千新的、不重复的机密凭证公布到了网站”。

大家应该还记得，2018年波兰某招聘网站被曝泄漏近千份用户简历，内容包含邮件、照片、电话和职业生涯等隐私信息。

（图3）泄漏的简历（图3）泄漏的简历

相比历史上大型用户密码、信用卡信息泄露之类的事件，这千份私人简历显得有点微不足道。但是因为欧盟新出台的GDPR政策，这类数据泄露可能会导致运营公司面临数千万欧元的罚款。更为严重的是，即使该公司加强在数据安全方面的建设，用户也很难会继续信任该网站，流失的用户数造成的收入减少更是雪上加霜。

事后复盘数据泄漏原因发现，正是因为该公司管理员不慎将云服务器的凭证配置不当，导致黑客未授权访问到了其中一个存储容器而造成的大范围数据泄露。

从漏洞赏金猎人网站Hackerone公开的案例中笔者也能查询到Grab、SnapChat、Starbucks、Uber、Yelp等著名网站也存在过凭证泄漏的问题。

（图4）Hackerone上面公开的案例（图4）Hackerone上面公开的案例

所幸这些问题被白帽黑客直接报告给了网站管理方，没有造成事态进一步的恶化。由此可见，当业务发展到一定程度，在使用AccessKey的过程中极有可能会遇到类似的安全问题。

二、阿里云安全中心实现AK安全自动化检测闭环

作为国内最大的云服务提供商，阿里云率先和最大的开源代码托管服务商Github合作，引入Token scan机制。

（图5）Token scan流程（图5）Token scan流程

​整个流程完全自动化，可以实现高效且精准的检测到在Github上泄漏的AccessKey。实际场景中，阿里云能够做到在含有AccessKey的代码提交到Github的数秒之内就通知用户并且做出响应，尽可能减少对用户产生的负面影响。

用户可以在“云安全中心—AK&账密泄露检测”模块中查看到泄漏的详情：

（图6）AK泄漏检测详情（图6）AK泄漏检测详情

在日常使用云产品的过程中为了防患于未然，用户也可以在“云安全中心—云安全最佳安全实践”检查当前云产品的配置项：

• 确保云产品的操作审计日志处于开启状态，有助于分析是否有异常的调用行为。
• 确保使用Ram用户的AK而不是主账号AK，遵守最小权限原则，一旦发生泄漏问题不至于失去整个云账号的控制权限。
• 确保开启MFA认证。有数据统计显示，当开启多因素
  认证后能够显著降低因为密码泄漏导致的未授权访问。

（图7）云安全最佳实践（图7）云安全最佳实践

除了泄漏前的提前预防，在“云安全中心—待处理告警—云产品威胁检测”中，系统将对用户日常的业务调用基线做学习，在出现疑似黑客异常AK调用行为时进行告警，及时提醒用户做出响应，做到泄漏后及时检测。

（图8）云产品调用威胁检测（图8）云产品调用威胁检测

云安全中心为了应对用户不慎泄漏AccessKey造成恶劣影响，设计了全方位检测理念，从泄漏前配置检查——泄漏行为检测——黑客异常调用三点完成检测闭环，为用户的云上业务安全保驾护航。

（图9）云安全中心检测理念（图9）云安全中心检测理念

三、安全建议

除了上述的措施外，笔者还建议用户在阿里云产品使用过程中遵循以下几点安全规范，从不同角度缓解凭证泄漏造成的影响：

不要将AccessKey嵌入代码中：嵌入代码中的凭证容易被人忽视，经验丰富的开发者会将其写入数据库或者独立的文件中，使得其管理起来更方便。

• 定期轮换AccessKey：定期更新代码中存在的AccessKey能够保证一些旧的代码泄漏出去后不会影响线上业务。
• 定期吊销不需要的AccessKey：从控制台可以看见最后一次AccessKey的访问时间，记得把不用的AccessKey都禁用。
• 遵循最小权限原则，使用RAM账户：根据不同业务需要授予不同子账户的读写权限，给不同业务使用不同子账户的AccessKey。
• 开启操作日志审计，并将其投递至OSS和SLS长期保存和审计：将操作日志存至OSS，遇到异常情况可以起到固证的作用，投递至SLS可以在日志量十分庞大的时候也能够高效检索。

上述措施对API凭证泄漏安全风险的防范和收敛有很大的效果，虽然具有一定的运维成本，但正是因为从一次次泄漏事故中我们看见了凭证泄漏对于一个企业的巨大伤害，相比这些巨额的经济损失，运维成本就显得微不足道。希望各位读者能够提早发现风险，提早防范风险，安全的享受API给我们带来的便利。