云安全性：共享责任模型内部

在最新的重大云安全问题中，Capital One遭受了数据泄露，影响了美国1亿人和加拿大600万人。 不只是首都一号楼的安全裤被抓住了。 现在我们知道黑客Paige A. Thompson从其他三十多家公司，教育机构和其他实体那里窃取了TB级的数据。”

就像所谓的攻击者自己谈到AWS配置时一样，“伙计，很多人做错了。”

就在公司破坏安全的第二天？ 不，这不同。 首先，我们已经对发生的事情了解很多。 我们知道Capital One在很大程度上依赖于Amazon Web Services（AWS）。 并且攻击是针对保存在Amazon Simple Storage Service（S3）中的数据进行的。 但是，由于没有防火墙的配置失误，因此这种攻击的发生而不是对没有任何安全性的S3进行攻击。

简而言之，这些违规行为并不是因为犯有愚蠢的安全错误。 之所以这样做，是因为公司在保持安全性方面做得很差。

让我们仔细看看。 Capital One的ModSecurity Web应用程序防火墙（WAF）的错误配置使攻击者（以前是AWS的一名雇员）诱骗防火墙将请求中继到关键的AWS后端资源。 有了这些，黑客就利用了服务器端请求伪造（SSRF）攻击来诱骗防火墙让攻击者进入。

我们将看到更多这类攻击。 正如Cloudflare产品安全团队经理埃文·约翰逊（Evan Johnson）所说：“这个问题很普遍，众所周知，但是很难预防，并且没有内置到AWS平台的缓解措施。”

因此，显然可以归咎于AWS的商店。 但是，正如被指控的攻击者自己对AWS配置所说的那样，“伙计，很多人做错了。”她实际上是在尝试数百家公司的门来找到被解锁的公司之后才这样做的。也许Gartner正在采取一些措施当他们预测时，“ 95％的云安全故障将是客户的过错。”

但是，有些人（例如参议员Ron Wyden）正在将这种违规行为的大部分责任推给AWS。 没那么快。

是的，AWS需要做一些解释，但是真正的问题是，如果您的安全实践不完善，您将会被淘汰。 云越大，燃烧越大。

正如安全专家Brian Krebs所指出的那样，此漏洞不是由“以前未知的“零日”漏洞或“内部”攻击”引起的，而是由使用众所周知的错误的众所周知的攻击引起的。

但是，在这一系列安全灾难中谁真正有过错呢？是使用云的云提供商还是公司？ 答案是两者。

云安全的分担责任模型

客户和云提供商各自负责云堆栈的不同部分。 此概念称为共享责任模型 （SRM）。 考虑此模型的一种快速方法是，云提供商负责云的安全性，而云用户负责云中的安全性。

AWS和Microsoft Azure都明确认可此模型。 但是，所有公共云都在某种程度上使用它。 它是我们目前处理云安全性的技术和合同方式的基础。

在最基本的级别上，这意味着您将负责管理程序级别以上的所有事务。 其中包括访客操作系统，您的应用程序软件，云实例的防火墙以及传输中和静止时的数据加密。 云提供商负责主机操作系统，虚拟化层及其设施的物理安全性。

当然，在现实世界中，这从未如此简单。

看看最新的安全惨案 。

AWS指出：“安全性和合规性是AWS与客户之间的共同责任。随着AWS从主机操作系统和虚拟化层到物理安全性的各个组件的运行，管理和控制，该共享模型可以帮助减轻客户的运营负担。客户负责客户操作系统的责任和管理（包括更新和安全补丁），其他关联的应用程序软件以及AWS提供的安全组防火墙的配置。”

在最后一点，Capital One出现了问题。 是的，看来他们没有正确设置防火墙。 但是，通过AWS，可以轻松访问AWS Identity and Access Management（IAM）角色临时证书。 有了这些临时凭证，进行SSRF攻击相对容易。

约翰逊声称，有几种方法可以钝化临时凭证的使用。 Netflix还显示，您可以在AWS云中发现临时安全证书的使用。 因此，是的，AWS在锁定防火墙方面可以做得更好，但是，再次重要的是，首先要设置防火墙。 简而言之，一切都很混乱。

这不足为奇。 正如KirkpatrickPrice指出的那样，云“安全需求是一个频谱。云服务客户将适用于其组织的所有法规，行业和业务需求（GDPR，PCI DSS，合同等）加在一起，总和等于该组织的特定安全要求。这些安全要求将有助于确保数据是机密的，具有完整性且可用的。

安全需求范围的一方面是云服务提供商，另一方面是云服务客户。 提供商负责其中的一些安全要求，而客户则负责其余的安全要求，但双方都应满足。 云服务提供商和云服务客户都有保护数据的义务。”

但是，您在哪里划分谁负责什么呢？ 这也不容易。 没有一个适合所有云解决方案的安全规模。 例如，如果您使用的是软件即服务（SaaS）办公套件，例如Google的GSuite，那么显然由Google而不是您来负责软件。 但是，如果您在平台即服务（PaaS）上运行自己的应用程序，则该程序如何运行既值得赞扬，也应受到指责。

如果仔细观察，您会看到AWS具有三个不同的SRM。 这些是基础设施服务； 集装箱服务； 和抽象服务。 Azure和其他公共云服务具有类似的安全策略设置。

基础架构包括诸如EC2之类的计算服务以及诸如弹性块存储（EBS），自动扩展和虚拟专用网（VPC）之类的支持服务。 使用此模型，您可以像在本地或在您自己的数据中心中一样在AWS云中安装和配置操作系统和平台。 在此之上，您可以安装应用程序。 最终，您的数据将驻留在您自己的应用程序中，并由您自己的应用程序进行管理。

尽管名称如此，但在此上下文中，容器服务与Docker和您想到容器时会想到的类似技术无关。 相反，这些服务通常是在单独的Amazon EC2或其他基础设施实例上运行的，但是有时您不管理操作系统或平台层。

AWS提供了托管服务，但是您负责设置和管理网络控制（例如防火墙规则），并负责与IAM分开管理平台级身份和访问管理。 容器服务的示例包括Amazon Relational Database Services（Amazon RDS），Amazon Elastic Map Reduce（Amazon EMR）和AWS Elastic Beanstalk。

在这里，AWS管理基础架构和基础服务，操作系统以及应用程序平台。 例如，使用Amazon RDS，AWS可以管理容器的所有层，直至并包括Oracle数据库平台。 但是，尽管AWS平台提供了数据备份和恢复工具； 维护业务连续性和灾难恢复策略是您的工作。 您还负责数据和防火墙规则。 因此，尽管Amazon RDS提供了防火墙软件，但管理防火墙是您的工作。

抽象服务是高级存储，数据库和消息传递服务。 它们包括Amazon Simple Storage Service（Amazon S3），Amazon DynamoDB和Amazon Simple Email Service。 这些抽象了可在其上构建和操作云应用程序的平台或管理层。 您可以使用其AWS API执行此操作。 AWS管理基础服务组件或操作系统。

在这里，您的安全性工作是通过使用IAM工具在平台级别将访问控制列表（ACL）样式权限应用于单个资源，或在IAM用户/组级别将用户身份或用户责任权限应用于管理数据。

让我们看一个简单的特定示例。 Amazon将Amazon Elastic Compute Cloud（Amazon EC2）归类为基础架构即服务（IaaS）云。 使用它，您将负责管理来宾操作系统（包括更新和安全补丁），实例上安装的所有应用程序软件或实用程序，以及每个实例的AWS提供的防火墙（也称为安全组）的配置。 但是，使用Amazon S3， “ AWS运行基础架构层 ，操作系统和平台，客户访问端点以存储和检索数据。客户负责管理其数据（包括加密选项），对其资产进行分类以及使用IAM应用适当权限的工具。”

明白这点？ 两者都是IaaSes，但是它们有不同的规则。

这个故事的寓意是，您必须仔细查看每个（我的意思是每个）云SRM服务协议。 尽管如此，尽管您必须仔细查看所使用的每种服务的含义以及由谁负责每个服务，但基本概念并不太复杂。 云提供商负责云的安全性，而您负责云中的安全性

未来更多的云复杂性

云原生计算使SRM中的内容变得混乱。 例如，AWS现在提供AWS Lambda 。 这是一种无服务器的云方法，使您无需配置或管理服务器即可运行代码。 因此，如果没有服务器本身，谁负责服务器呢？

亚马逊表示，借助Lambda，“ AWS管理基础架构和基础服务，操作系统以及应用程序平台。您负责代码的安全性，敏感数据的存储和可访问性以及身份和访问管理（IAM）。 ）到Lambda服务并在您的职能范围之内。”

这使问题公开。 例如，由于您使用Lambda运行代码，因此代码的责任从何处终止而Lambda的责任从哪里开始？

正如全栈云原生安全平台公司Alcide的联合创始人兼首席技术官Gadi Naor所说：“ 使用无服务器架构意味着组织将面临新的盲点，这仅仅是因为他们不再有权访问该架构的操作系统，阻止他们在这些工作负载中添加防火墙，基于主机的入侵防御或工作负载保护工具。”

这仅仅是个开始。 例如， Kubernetes使混合云能够一次沿着多个云运行。 因此，如果您运行的程序介于新的基于Red Hat的IBM云和AWS之间，那么谁负责保护整个项目呢？ 出现问题时谁负责？ 最后但并非最不重要的一点是，当最终用户提起诉讼时，谁付费？

好问题，不是吗？ 对于我们正在进入的这个新的复杂云世界，我们仍然没有好的答案。

所以，你可以做什么？ 首先，请确保您了解云安全需求。 您必须先确定适合自己的方式，才能选择云服务提供商并制定云安全协议。 这些不仅仅是技术问题。 它们也是法律问题。

有了这些信息，您就可以与云提供商达成安全协议了。这应该在您的服务级别协议中予以明确。

最后，无论合同中有什么规定，您和您的安全人员都必须确保基于云的数据和服务尽可能地安全。 毕竟，是您的数据，您的工作，是您和客户和股东在出现问题时首先要考虑的问题。