6.2 云原生安全的4C

将云原生生态系统情境化的一种有用方法是通过 Kubernetes 文档中描述的“云原生安全 4C”，此处讨论的图 6.2 中所示的容器编排器。

图6.2

在此特定于容器及其编排的上下文中，您拥有云、集群、容器和代码，每一层本质上都依赖于其上层（或之前层）的各种形式的基础设施和部署到其上的代码。

如前所述，云范式具有 NIST 定义的三种商定的服务模型。云消费的主要方法之一是 IaaS，组织利用 CSP 的物理设施、实用程序、人员和基础设施来部署操作系统和应用程序。在这种模式中，CSP 负责底层基础设施、公用事业、设施、人员和一般资本支出 （CapEx） 成本。领先的 CSP 为网络、计算和存储等关键领域的使用提供强大的云服务。然而，这些服务仍然由软件提供支持，就像大多数现代基础设施一样。这意味着它们仍然容易受到与软件相关的漏洞和漏洞的攻击。虽然云消费者是从 IaaS 模型中的底层基础设施中抽象出来的，但这并不意味着他们完全不受可能影响它的风险和威胁的影响。这正是 Log4j 漏洞中发生的情况。主要的 CSP（AWS （https://aws.amazon.com/security/ security-bulletins/AWS-2021-006）、Azure （https://msrc-blog.microsoft .com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2） 和 Google Cloud （https://cloud.google.com/log4j2-security-advisory） 都发布了与 Log4j 对其云服务产品的影响相关的公告。

这些 CSP 与更广泛的 IT 行业非常相似，使用无数的开源库和组件来支持其多样化的云服务组合。从上述 CSP 的公告来看，这种单一的开源软件供应链妥协对其云原生服务组合产生了影响，而且并不止于此。这些 CSP 的收入高达数十亿美元，为数千个组织和数百万个人提供支持。当组织在这些 CSP 产品/服务之上构建和交付应用程序和服务时，基础服务产品中的软件供应链泄露或漏洞不仅会影响使用型组织，还会影响其业务合作伙伴、客户和利益相关者。对于前面提到的超大规模 CSP，这些客户甚至包括美国最关键和最敏感的工作负载，因为 CSP 由国防部 （DoD）、情报界和联邦民事行政部门 （FCEB） 机构等组织使用。

这一现实要求确保云客户正在使用的服务以及支持他们的相关软件。虽然已经制定了成熟的计划，例如 FedRAMP （www.fedramp.gov） 或 SOC2 （https://us.aicpa .org/interestareas/frc/assuranceadvisoryservices/aicpasoc2report），但他们传统上并没有从清点和了解为现代云原生服务产品提供支持的底层软件供应链以及与该软件相关的风险的角度来看待软件。这些计划着眼于更传统的风险评估方法，例如 CSP 策略和流程、基础计算实例的漏洞扫描结果以及渗透测试。随着软件供应链日益成为 IT 和网络安全领导者关注的焦点，我们可能会看到一种转变，即 FedRAMP 等授权计划开始要求 CSP 为其面向软件的托管服务产品提供 SBOM 等项目。美国联邦政府已经通过发布管理和预算办公室 （OMB） 备忘录 22-18 （www.whitehouse.gov/wp-content/uploads/2022/09/M-22-18.pdf） 表明了这一意图，该备忘录将让各机构可能要求工件，包括第三方软件生产商向联邦政府销售软件的 SBOM，其中当然包括云提供商。它还要求第三方软件供应商提供自我证明，证明他们遵循安全的软件开发实践，例如NIST的安全软件开发框架（SSDF）和其他NIST软件供应链安全指南。

然而，考虑到AWS、Azure和谷歌等超大规模CSP的广度和规模，这是具有挑战性的，他们无疑拥有大量的软件库存来支持他们的云服务产品。它也与目前的方法主要基于第三方评估组织 （3PAO），其中第三方评估服务提供商并提供与提供商的内部实践和安全流程相关的工件和证明。云和托管服务产品通常努力从消费者那里抽象出一些潜在的复杂性，以换取消费者体验和便利性。值得注意的是，在前面提到的 OMB 22-18 备忘录中，它允许软件生产者自我证明他们使用了安全开发实践。但是，如果机构认为有必要，它确实允许机构要求提供 3PAO。然而，考虑到当前的环境、工具和组织能力，如何为每个云服务大规模发挥作用是不切实际的。

虽然 IaaS 不可避免地涉及软件，但围绕软件供应链安全的对话在云原生架构的其他方面要成熟得多，例如容器、Kubernetes、代码和越来越多的 SaaS。