云渗透测试需采取不一样的方法

攻防

2年前

　　大多数公司都遵循类似的安全防护模式：只要攻击者调整攻击技术，防御人员就必须重新考虑自己的安全策略。如今，随着攻击面不断扩大，随着网络罪犯开始盯上云环境，企业不得不扛起确保自身云基础设施安全的压力。

　　在今年的线上ISC²安全大会上，Fugue联合创始人兼首席技术官Josh Stella表示，很多企业依靠渗透测试来找出存在于自身系统中的安全漏洞，但这一过程并不是一成不变的。面对传统的数据中心，渗透测试人员主要关心的是获取网络设备访问权限，透过TCP/IP网络突破防御边界，最终触及数据库等企业宝贵资产。

　　Stella称：“渗透测试在云技术方面有点滞后了。攻击面已然发生了变化。”

　　由于重点放在数据中心技术而非云策略上，渗透测试人员往往错过了很多云漏洞。合规框架未囊括安全漏洞，DevOps和安全团队也没识别出安全漏洞。安全缺陷往往只有放在整个环境中才会显露出来，所以只要没有了解全局，就有可能漏掉这些缺陷。

　　以Uber数据泄露事件为例。这起发生在2016年的网络安全事件导致全球5700万用户和美国60万名司机的个人信息失泄。而原因据称是攻击者盗取凭证入手了Uber在GitHub上的私有代码，并从中挖掘出了硬编码到代码中的AWS S3存储桶登录凭证。于是，攻击者就能利用这些凭证登录Uber的AWS账户并下载文件了。

　　Stella表示：“对黑客而言，利用目标在用的多个云服务来跨越边界并不是什么罕见的攻击手法。”攻击者不利用网络和操作系统漏洞，因为他们不靠此类漏洞就能侵入云环境。

　　攻击者用来突破云环境的渠道往往是架构性问题或流程问题，而不是存在缺陷的软件库。虽然这些问题在云端确实存在，但相比数据中心环境还是不那么常见。云环境中的很多渗透测试都是四处收集并拼凑内容来形成数据泄露。

　　传统攻击模式中，攻击者选好目标后再查找或制造漏洞来形成数据泄露。但云环境中的数据泄露大多不是这个路数。即便是重大攻击也往往会采用全新的模式：攻击者利用自动化技术查找漏洞（通常是云资源API错误配置），然后再选择要突破的目标。

　　Stella解释道：“无论是S3存储桶还是你自己的什么东西，到你推上云端并做好配置的时候，攻击者都会探测有无错误配置和漏洞。”通常，攻击者会在数分钟之内找到你的云资源。

棘手的S3问题

　　S3数据渗漏是太过普遍的企业常见问题，Uber事件已经凸显出其危害，而且出于一系列原因，这个问题还十分棘手：大多数情况下，数据不会穿过任何客户可访问的网络，所以数据泄露相当难检测到。数据渗漏发生在客户公司实际上无权访问的云提供商网络上；而公司可以访问的事件日志则只会在数据已经失窃后才会反映出这一悲伤的事实。

　　所以企业应该尤为关注S3列表，因为这是攻击者用得最趁手的工具之一。

　　Stella指出，“读取”权限错误配置构成了危险云错误配置的主体，常被攻击者用来执行资源发现操作。例如，2019年的Imperva数据泄露事件中，攻击者就是从可通过互联网访问的内部系统中盗取了AWS API密钥。事件发生后，Imperva采取措施加强了对快照访问的审计，也就是仔细检查允许“读取”的IAM策略和角色关联。企业应努力找出存有API密钥的所有位置，因为这些位置就是攻击者的目标所在。（编者注：在数世咨询统计的年度大事记中，配置错误是信息泄露事件的主要原因之一）

　　Imperva还推行登录凭证轮换并巩固了凭证管理流程。这些举措也是企业改善自身云安全态势所必须做的。所有凭证都应该轮换，即使是安全控制往往相对较弱的开发和测试环境中的那些。

　　Stella补充道：“对于云黑客攻击而言，开发和测试环境可能比生产环境还诱人，其热门程度至少不亚于生产环境。之所以会出现这种现象，很大程度上是由于开发和测试环境中的安全控制更加宽松。”

　　审查供应商安全状况时要问的问题，与面对渗透测试人员时应该问的那些问题都是一样的。他们了解漏洞面和自身暴露情况吗？有没有打算测试控制平面API，尤其是这些API托管在云上的情况下？这是企业在巩固自身云安全态势时必须谨记的又一个方面：数据几乎总是通过控制平面API流出云环境。

参考阅读

云安全实践：CWPP、CSPM和CNAPP