6.1 共担责任模型

如果不涉及共享责任模型 (SRM)，关于云的安全性和风险的讨论就不完整。许多企业领导者仍然会问“云安全吗？”，这是一个错误的问题。更合适的问题是“作为安全团队和组织，我们是否确保了我们在云消费中的份额？”

绝大多数云数据泄露和泄漏都是由于客户造成的，IT 研究和咨询公司 Gartner 预测，到 2025 年，大约 99% 的云安全故障将是客户的错误 (www.gartner.com/smarterwithgartner/is-the-cloud-secure)。因此，所有安全从业人员都必须了解自己的责任.

共担责任模型的细分

SRM 描述了您（云客户）负责什么以及您的云服务提供商 (CSP) 负责什么。在 IaaS 模型中，CSP 负责云的安全性 — 比如物理设施、公用设施、电缆、硬件等。客户负责云的安全性 — 即网络控制、身份和访问管理、应用程序配置和数据安全。

共担责任模式的职责

也就是说，这种责任划分可能会根据您使用的服务模型而改变。从基本层面上讲，NIST 对云计算的定义解释了三种主要的云服务模型：

■ 基础设施即服务 (IaaS)：在 IaaS 模型下，CSP 负责物理数据中心、物理网络和物理服务器/托管
■ 平台即服务 (PaaS)：在 PaaS 模型中，CSP 承担更多责任，例如修补（客户过去在这方面做得很差，并且是导致安全事件的主要途径）和维护操作系统。
■ 软件即服务 (SaaS)：在 SaaS 中，客户只能在应用程序的配置设置中进行更改，其他所有控制权都留给 CSP。（Gmail 是一个基本示例。）值得注意的是，即使在 SaaS 环境中，在 SaaS 治理和安全方面也有很多工作要做，我们将在本章后面深入讨论。

每种方式都有其代价，客户放弃控制权，以换取更多的交钥匙管理体验，而 CSP 则处理更多的运营活动，让客户专注于自己的核心竞争力。许多组织发现这种模式很有吸引力，因为管理计算和基础设施通常不是他们的核心业务，而是他们为提供核心服务和产品而必须执行的活动。

每个 CSP 都有不同版本的 SRM。图 6.1 是 Microsoft Azure SRM 的一个示例（https://docs.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility）

虽然 SRM 涉及合同和财务影响等非安全问题，但它也包括一些安全考虑因素。安全从业人员必须根据他们所使用的服务以及组织的实施和架构了解他们在 SRM 中的责任。

还记得几乎所有云数据事件都发生在 SRM 的客户端吗？这是了解 SRM 并确保您正在履行模型职责的主要原因。另一件我们再怎么强调也不为过的是，虽然可能存在责任分担，但您不能将责任外包。作为一个组织，您最终仍然是数据所有者，并对这些数据及其所属的利益相关者负责，即使您决定在向客户或利益相关者提供服务和业务时使用第三方（例如 CSP）。虽然涉及客户数据泄露的 CSP 可能会产生合同后果，但客户将承受声誉、品牌和监管后果方面的后果。

您的职责取决于您拥有两种主要安全角色中的哪一种：技术安全从业者或安全主管。技术安全从业者（例如云安全工程师或云安全架构师）必须了解您的组织使用哪些云服务；如何安全地构建这些解决方案；以及哪些配置、设置和控制属于您的职权范围，您可以影响这些配置、设置和控制并实现更强大的安全态势。一个明显的例子是，云原生供应商 SysDig 在其 2023 年的“云原生安全和使用情况报告”中发现，云环境中 90% 的授予权限未被使用。这与行业对零信任的推动相矛盾，并为攻击者滥用受损帐户留下了很多机会（https://sysdig.com/press-releases/sysdig-2023-usage-report）。

技术安全专业人员应该非常熟悉其组织使用的平台和服务，并了解如何安全地实施它们。云安全工程师/架构师经常与工程和开发团队合作。如果您无法引导他们找到安全的解决方案或发现有风险的配置（请记住，这些配置是大多数云数据事件的根源），您的组织可能会面临巨大的风险。

向您的 CSP 寻求安全资源。例如，Amazon Web Services (AWS) 提供了一个令人难以置信的安全文档数据库，按类别（例如，计算、存储、安全、身份和合规性）细分，您可以在其中找到与您的组织使用的每项服务相关的具体信息。这包括广泛的信息，从如何安全地配置服务，到您可以操作哪些配置，再到故障排除指南。

安全主管需要考虑的关键因素包括清点服务使用情况（你必须知道组织内正在使用什么，否则你就无法保护它）、确保所使用的服务符合适用的监管框架，以及了解合同/法律方面的问题，如 CSP 服务级别协议 (SLA)，尤其是涉及事件响应计划等方面的问题。其中一位作者贡献的一种资源是云安全联盟的云事件响应框架 （https:// cloudsecurityalliance.org/artifacts/cloud-incident-response-framework）。

许多组织与 CSP 建立合作伙伴关系并分担责任。这包括确保您使用的服务符合您必须遵守的监管框架。超大规模 CSP 使这些信息易于查找，AWS 和 Microsoft Azure 提供了“范围内的服务”页面，您可以在其中确定哪些服务符合哪些框架，哪些服务仍在审批流程中或尚未评估和评估。这有助于确保您的团队不仅在云中构建强大且安全的架构和工作负载，而且还使用符合适用框架的服务，以避免合规性或法规问题，并使用他们有保证的服务。

各级安全从业人员都应努力在其云环境中实施安全标准和最佳实践。这可能意味着从各自的 CSP 实施安全最佳实践，或者为各自的云环境实施诸如 Internet 安全中心 （CIS） 基准测试之类的内容（www.cisecurity.org/blog/ foundational-cloud-security-with-cis-benchmarks）。

处理 SRM 时的一个基本工件是客户责任矩阵 （CRM），它列出了 CSP 提供哪些控制以及哪些责任留给云消费者。查找 CRM 模板并了解有关它们的更多信息的一个地方是联邦风险和授权管理计划 （FedRAMP）。FedRAMP 是一个程序，用于处理美国联邦政府 （www.fedramp.gov/updated-Control-implementation-summarycis-and-customer-responsibility-matrix-crm-templates） 使用的云服务产品/服务的授权。

CRM是安全从业人员使用的关键工具。在 SRM 中，安全控制完全由 CSP 提供，混合控制（责任由云客户承担），或完全留给客户。安全从业人员可以利用CRM来清楚地了解这种安全控制描述。这些通常分别是指完全、部分或不可继承的安全控制。

使用云服务可以将某些安全控制和活动的责任转移到 CSP，并让组织专注于其核心竞争力。它创造了一种责任关系，安全专业人员必须理解并适当地处理。请记住，大多数云数据泄露将发生在 SRM 的客户端，归根结底，您对组织的声誉负有全部责任，而 CSP 代表了另一个第三方提供商，在推动软件透明度和软件供应链安全方面必须考虑该提供商。