什么是云安全审查,为什么需要它?

文章 (151) 2021-01-30 19:38:43

云可能是一个狂野的地方。拥有数十个首字母缩写词,数百种产品以及更多规则集,要建立一个简单的工作环境(更不用说一个安全的工作环境)已经非常困难。实际上,易于部署云服务意味着也很容易犯错误-甚至太容易了。

大多数初创公司和SaaS供应商出于明显的原因都在云中运行。尽管许多客户联系我们以对其平台进行黑盒渗透测试,但他们并没有在整个云环境中投入太多精力;相反,他们只专注于面向客户的“公共”部分,通常是基于Web的仪表板或向客户公开的某些REST API,这只是冰山一角。

最近的安全漏洞表明,造成此类漏洞的主要原因主要是云安全设置中的配置错误,如Capital One漏洞和Imperva漏洞所示。

在此博客文章中,我们将揭穿关于云环境及其与信息安全的关系的两个常见神话,解释云安全审查的过程,并讨论其在SOC2,ISO 27001或任何其他安全过渡和认证过程中的重要性。

误解一:云技术本质上比“传统”基础架构更安全。

尽管云基础架构因为支持DevOps管道和可伸缩性而非常适合快速发展,但过渡到云也存在安全性缺陷。

在云环境中,每个服务器(或服务)都使用一个身份,使其可以执行操作或与不同的服务进行交互。根据我们的经验,云安全性的最大陷阱是对已部署服务的权限管理不当。

此外,迁移到云使您失去了“内部网络”和传统的基于网络的边界的概念。例如,以某种方式“窃取”服务身份的攻击者可以直接到达API(通过设计暴露给互联网),部署新服务,安装后门或从公共云存储资源中提取数据(给定攻击者)有权这样做)。在这种情况下,蓝队将很难检测并阻止活动。

误解二:云提供了更好的审计和安全可见性。

想象一下,攻击者可以访问您环境中随机虚拟服务器的凭据。其实并不重要,它可以不同于SSRF,远程代码执行或只是一些随机公开的Git存储库。使用这些凭据,攻击者可能会尝试执行以下任一操作:

•枚举公共云存储资源并下载其内容。

•由于Web服务配置错误而导致特权升级。

•在安全组中设置新规则。

•在容器注册表中安装后门。

•部署加密矿机。

•清除所有数据。

根据与客户的经验,我发现十分之九的客户将不会发现这些操作,除非为时已晚。专业的云安全评估应识别这些盲点并在安全报告中解决它们。

如何执行云安全性审查

上面列出的攻击场景只是现代云环境中潜在攻击路径的一小部分。为了了解这种攻击的可行性,应该执行云安全性审查。

从本质上讲,云安全审查是以“白盒”方法进行的。审阅者需要具有对API和控制台访问权限,才能运行查询和检查云配置。由于每个系统的设计各不相同,因此没有自动的灵丹妙药。了解系统的上下文对于安全性审查的成功至关重要(例如,在某些情况下,S3存储桶应按设计公开打开;缺少上下文,则可以错误地将其视为“漏洞”)。

云安全性审查中的第一个活动是基于云的攻击面的映射(是否应该从互联网真正访问Grafana / MongoDB / Elasticsearch?)。

在绘制了攻击面后,以下几点的假设是,攻击者现在可以对您的云环境进行一定程度的访问。您应该回答的问题是:“攻击者此时可以造成什么损害?”

检查的主题应包括:

•配置Web服务策略,组和用户。

•存储服务的管理和配置。

•监控和审核规则。

•备份,冗余和灾难恢复。

•与安全最佳实践相比,各种服务的安全配置。

结论

近年来的数据泄露表明,云中的安全配置错误是大多数此类事件的根本原因。在符合SOC2或ISO 27001的过程中实施云安全性审查与对特定系统执行渗透测试或安全性代码审查一样重要。

正如开发人员不负责为自己的代码进行渗透测试和代码审查一样,云操作不应监督自己的云安全性实施。这些类型的安全检查应由经过认证的专业人员执行。

无论您是经营一家初创公司还是一家大公司,在为IT计划安全路线图时,请问自己以下问题:“如果攻击者获得了对我的云的初始访问权,他们将能够执行什么操作?” 很有可能需要通过云安全性审查来解决此问题。

THE END

发表回复