只想着一直调用一直爽, 那API凭证泄漏风险如何破?

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

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

1、API凭证的安全现状

API凭证至关于登陆密码,只是使用场景不一样。前者用于程序方式调用云服务API,然后者用于登陆控制台。安全

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

(图1)阿里云AK样式(图1)阿里云AK样式

(图1)阿里云AK样式运维

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

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

(图2)泄漏的凭证(图2)泄漏的凭证

(图2)泄漏的凭证测试

笔者曾在不一样的代码托管平台搜索了不一样云平台的凭证格式,都能发现存在或多或少的凭证漏,这已是一个广泛的安全问题。网站

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

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

(图3)泄漏的简历(图3)泄漏的简历

(图3)泄漏的简历

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

过后复盘数据泄漏缘由发现,正是由于该公司管理员不慎将云服务器的凭证配置不当,致使黑客未受权访问到了其中一个存储容器而形成的大范围数据泄露。

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

(图4)Hackerone上面公开的案例(图4)Hackerone上面公开的案例

(图4)Hackerone上面公开的案例

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

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

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

(图5)Token scan流程(图5)Token scan流程

(图5)Token scan流程

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

用户能够在“云安全中心—AK&帐密泄露检测”模块中查看到泄漏的详情:

(图6)AK泄漏检测详情(图6)AK泄漏检测详情

(图6)AK泄漏检测详情

在平常使用云产品的过程当中为了防患于未然,用户也能够在“云安全中心—云安全最佳安全实践”检查当前云产品的配置项:

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

(图7)云安全最佳实践(图7)云安全最佳实践

(图7)云安全最佳实践

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

(图8)云产品调用威胁检测(图8)云产品调用威胁检测

(图8)云产品调用威胁检测

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

(图9)云安全中心检测理念(图9)云安全中心检测理念

(图9)云安全中心检测理念

3、安全建议

除了上述的措施外,笔者还建议用户在阿里云产品使用过程当中遵循如下几点安全规范,从不一样角度缓解凭证泄漏形成的影响:

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

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

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

 



本文做者:云安全专家

原文连接

本文为云栖社区原创内容,未经容许不得转载。

相关文章
相关标签/搜索