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

Steven J.

在最近发生的主要云安全事件中，Capital One公司的数据泄露事件影响了美国的1亿人和加拿大的600万人。其实并不只有Capital One公司遭遇网络攻击，黑客Paige A. Thompson与此同时窃取了其他三十多家公司、教育机构和其他实体的数TB的数据。正如这位被指控的网络攻击者在谈到AWS配置时所说，“很多组织在其安全方面都做错了”。

调查表明，Capital One公司的业务在很大程度上依赖亚马逊网络服务（AWS）的云计算服务。并且网络攻击是在Amazon简单存储服务（S3存储桶）中保存的数据上进行的。但是，由于防火墙配置错误，这次攻击并不是在没有任何安全措施的情况下对S3存储桶进行的攻击。简而言之，这些违规行为不是因为企业犯下了安全错误，而是因为在维护自身安全方面做得很差。

Capital One公司的ModSecurity Web应用程序防火墙（WAF）配置错误使得网络攻击者能欺骗防火墙，并将请求转发给关键的AWS后端资源。攻击者使用服务器端请求伪造（SSRF）攻击来欺骗防火墙让攻击者进入。

正如Cloudflare公司产品安全团队经理Evan Johnson所说的那样，“这个问题很常见，并且众所周知，但很难预防，而且AWS平台没有任何应对或缓解措施”。因此，显然很多人可以将一些责任归咎于AWS公司的公共云服务。但是，正如所谓的攻击者自己对AWS的配置所说的那樣，很多公司在这方面做错了。正如Gartner公司在调查报告中预测，“其实95%的云安全故障都是客户的错”。

然而有些人却将此次数据泄露的大部分责任推给AWS公司，AWS公司确实需要为此进行解释，但真正的问题是如果企业的安全措施不佳，就会在遭遇攻击时损失惨重。并且采用的云服务规模越大，损失越大。

云安全的共享责任模型

客户和云计算提供商各自负责云堆栈的不同部分。这个概念称为共享责任模型（SRM）。快速思考此模型的方法是云计算提供商负责云平台的安全性，采用云平台的用户则需要负责在云中的业务安全性。

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

在最基本的层面上，它意味着企业负责管理程序级别以上的所有内容。其中包括客户操作系统、应用程序软件、云计算实例的防火墙以及传输和空闲时的加密数据。云计算提供商负责主机操作系统、虚拟化层及其设施的物理安全性。

AWS公司表示：“安全与合规是AWS与用户之间的共同责任。这种共享模式可以帮助减轻用户的运营负担，因为AWS公司可以运行、管理和控制从主机操作系统和虚拟化层到组件的物理安全性的组件，以及服务运营的设施。客户承担操作系统的责任和管理（包括更新和安全补丁），其他相关的应用软件以及AWS提供的安全组防火墙的配置。”

对于Capital One公司来说，他们没有正确设置防火墙。但是，获得AWS身份和访问管理（IAM）角色临时凭据变得更容易。有了这些临时凭证，进行服务端请求伪造（SSRF）攻击相对容易。

正如行业专家指出的那样，将云安全要求视为一种范围。云计算服务客户将适用于其组织的所有监管法规、行业和业务要求（GDPR、PCI DSS、合同等），其总和等于该组织的所有特定安全要求。这些安全要求将有助于确保数据的机密性、完整性、可用性。

安全要求范围的一端是云计算服务提供商，另一端是采用云计算服务的用户。提供商负责其中一些安全要求，用户对其余部分负责，但都应该满足一些安全要求。云计算服务提供商和采用云服务的用户都有义务保护数据。

但是，在谁负责什么之间划清界限也不容易。没有一种适合所有云平台安全性的解决方案。如果在平台即服务（PaaS）上运行自己的应用程序，那么可以同时承担该程序运行的信誉和责任。如果仔细观察，人们会发现AWS公司提供三种不同的共享责任模型（SRM）。这些是基础设施服务、容器服务、抽象服务。Azure和其他公共云服务商也具有类似的安全策略设置。

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

容器服务与Docker和类似技术几乎没有关系，这些技术在用户考虑容器时会浮现在脑海中。相反，这些服务通常在单独的Amazon EC2或其他基础设施实例上运行，但有时用户不用管理操作系统或平台层。

AWS提供托管服务，但用户负责设置和管理网络控制（例如防火墙规则），以及与身份和访问管理（IAM）分开管理平台级别身份和访问管理。容器服务的示例包括Amazon 关系数据库服务（Amazon RDS）、Amazon 弹性映射还原（Amazon EMR）和AWS Elastic Beanstalk。

在这里，AWS公司管理底层基础设施和基础服务、操作系统和应用程序平台。例如，使用Amazon RDS AWS管理容器的所有层，包括Oracle数据库平台。但是，AWS平台提供数据备份和恢复工具;用户的工作是维护其业务连续性和灾难恢复政策。还负责数据和防火墙规则。因此，虽然Amazon RDS提供防火墙软件，但其工作是管理防火墙。

抽象服务是高级存储、数据库和消息传递服务。它们包括Amazon 简单存储服务（Amazon S3）、Amazon DynamoDB、Amazon Simple Email Service。这些抽象了用户可以构建和运行云应用程序的平台或管理层。可以使用他们的AWS API执行此操作。AWS公司来管理底层服务组件或操作系统。

在这里，用户的安全工作是使用身份和访问管理（IAM）工具管理数据，以便对平台级别的各个资源应用访问控制列表（ACL）样式权限，或者在身份和访问管理（IAM）用户/组级别应用用户身份或用户责任权限。

未来的云计算复杂度更高

云原生计算已经混淆了共享责任模型（SRM）中的内容。例如，AWS公司现在提供AWS Lambda。这是一种无服务器云计算方法，可让用户在不配置或管理服务器的情况下运行代码。因此，如果没有服务器，那么谁为服务器负责？

亚马逊公司表示，采用Lambda，AWS公司管理底层基础设施和基础服务、操作系统和应用程序平台。用户负责代码的安全性、敏感数据的存储和可访问性及身份和访问管理。

这就留下了问题。例如，既然用户正在使用Lambda来运行代码，那么代码的责任在哪里结束，Lambda的责任从哪里开始？

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

例如，Kuberrnetes正在使混合云同时在多个云平台上运行。那么，如果用户正在运行一个跨越新的基于Red Hat的IBM云平台和AWS的程序，那么谁负责保护整个项目？当出现问题时谁负责？而且，最后当最终用户起诉时谁来支付费用？

那么，用户可以做些什么？首先，确保了解自己的云安全需求。用户不能选择云计算服务提供商并制定云安全协议，直到知道什么对自己有用。这些不仅仅是技术问题。它们也是需要关注的法律问题。

有了这些信息，用户就可以与云计算提供商制定安全协议。这应该在其服务级别协议中明确规定。

最后，无论合同中有什么内容，用户和其安全人员都必须确保基于云计算的数据和服务尽可能安全。毕竟，这是自己的数据和工作，如果出了问题，将需要承担不可推托的责任。