查看“云原生分发安全”的源代码


<div class="figure">

[[File:cnswp-v2-security-structural-model-distribute.png|图 3]]

</div>
''图 3''

“分发”阶段负责消耗镜像定义和规范以构建下一阶段的工件，例如容器镜像、VM 镜像和其他工件。在现代的 CI/CD 管道中，“分发”阶段包括系统化的应用测试，以识别软件中的错误和故障。然而，采用开源和可重用的包可能会导致漏洞和恶意软件被纳入容器镜像中。因此，必须采取针对安全的步骤，例如扫描镜像以查找威胁向量，以及验证镜像的完整性以防止篡改。此外，如果需要保密，组织可能希望对软件工件进行加密。

如果软件工件由于妥协或其他事件而变得不可信，团队应该撤销签名密钥以确保否认。

== 构建管道 ==

持续集成（CI）服务器应该被隔离并限制在相似安全分类或敏感性的项目中。需要提升权限的基础设施构建应该在单独的专用 CI 服务器上运行。构建策略应该在 CI 管道和编排器的准入控制器中执行。

供应链工具可以收集并签署构建管道元数据。随后阶段可以验证签名以确认先决条件管道阶段已运行。

读者应确保 CI 和持续交付（CD）基础设施尽可能安全。例如，应优先安装安全更新，并通过使用 HSM 或凭证管理器来保护加密密钥免受外泄。

== 镜像扫描 ==

扫描容器镜像是保护容器应用程序整个生命周期中最常见的安全方式之一。在将镜像部署到生产环境之前，在 CI 流水线中进行扫描非常重要。 此外，持续扫描正在运行的容器镜像同样重要，以识别新发现的漏洞。整合此功能可确保开发人员、运营商和安全专家拥有所有已知漏洞和详细信息， 例如严重性、通用漏洞评分系统（CVSS）评分和可用的缓解/修复措施。将容器镜像的漏洞扫描与流水线合规规则相结合， 可确保只部署已充分修补的应用程序，从而减少潜在攻击面。容器镜像扫描还有助于识别开源软件包或从开源镜像库中获取的基础镜像层中的恶意软件存在。 虽然容器镜像扫描可以为团队提供漏洞或恶意软件的证据，但它并不能修复漏洞或防止恶意软件。组织需要确保采取行动来解决容器扫描发现，并执行组织合规规则。

== 镜像强化 ==

容器镜像必须包含安全强化措施，以减轻威胁，同时允许在运行时进行实时配置，以便更好地集成到生态系统中。

在考虑安全保证目标时，应评估以下问题：

* 是否将执行环境限制为特定用户？
* 是否限制对资源的访问？
* 是否对进程执行进行内核级别的限制？

== 容器应用清单扫描 ==

应用程序清单描述了容器化应用程序所需的配置。在 CI/CD 管道中扫描应用程序清单以识别可能导致不安全部署的配置至关重要。

== 容器应用清单强化 ==

与容器镜像一样，容器应用程序清单加固可以考虑并且可以在构建和运行时实现。

对于安全保证目标，主要问题是：''要满足哪些最小限制来执行生态系统？''

== 测试 ==

云原生应用程序应该接受与传统应用程序相同的质量测试套件和标准。这些包括干净代码的概念，遵循[https://martinfowler.com/articles/practical-test-pyramid.html 测试金字塔]，通过静态应用程序安全测试（SAST）进行应用程序安全扫描和代码检查，依赖性分析和扫描，动态应用程序安全测试（DAST），应用程序仪表化以及完整的基础架构，并在本地工作流中向开发人员提供测试。自动化测试结果应映射回双重认证（开发人员和工具）的要求，以实时安全保证提供给安全和合规团队。

一旦发现安全配置错误（例如不正确的防火墙或路由规则），如果根本原因分析确定其有合理的重现机会，则开发人员应编写自动化测试以防止缺陷的回归。在测试失败时，团队将收到反馈以纠正错误，并在下一次合并时，测试将通过（假设已经纠正）。这样做可以防止由于将来对该代码的更改而导致的回归。

基础架构的单元测试是一种预防性控制，目标是在基础架构作为代码（IaC）配置中定义的实体和输入。构建的基础架构的安全测试是一种探测性控制，它结合了保证、历史回归和意外配置检测（面向全球开放的防火墙规则、松散权限的身份和访问管理（IAM）策略、未经身份验证的端点等）。

基础架构和工作负载的硬化应该得到全面的测试套件的支持，这允许系统逐渐硬化。测试以验证硬化是否发生应该在构建期间运行，但也应在部署时运行，以评估可能在整个生命周期中发生的任何更改或回归。

=== 静态分析和安全测试 ===

静态分析是指对 IaC、应用程序清单和软件代码进行代码检查、错误配置的识别和特定组件的漏洞分析。但需要注意的是，个别分析很重要，但不应该是唯一的分析形式。IaC 代码应该受到与应用工作负载相同的管道策略控制。

IaC 是组织部署云和容器基础设施的越来越流行的方式。在 IaC 模板中，不安全的配置会自然地导致基础设施中的安全漏洞。因此，在部署应用程序和基础结构工件之前，应该扫描这些模板以寻找威胁安全的特征。需要注意的关键错误配置包括：

* 应用程序清单中指定的镜像中包含的漏洞
* 不遵守最小权限原则的设置，例如可以升级权限或过于宽松的防火墙规则的容器
* 安全上下文和系统调用的识别，可能会危及系统
* 资源限制设置

=== 动态分析 ===

部署基础架构的动态分析可能包括检测基于角色的访问控制（RBAC）和 IAM 配置漂移，验证期望的网络攻击面，并确保 SOC 可以检测专用测试环境中的异常行为以配置生产警报。动态分析是测试的一部分，但预计会在非生产运行时环境中发生。

=== 安全测试 ===

应将应用程序和基础架构的自动化安全测试作为安全团队的重点。测试套件应持续更新，以与组织的威胁模型相一致地复制威胁，并可用于安全回归测试，因为系统不断发展。自动化安全测试通过消除手动安全门（例如在单个检查点处实施验证和手动控制）来提高安全性和发布速度，这是耗时且不足够的。自动化安全测试还通过明确尝试执行威胁来随时展示控制效能，从而实时提高系统的安全性和遵守任何嵌入式合规要求。

== 工件和镜像 ==

=== 注册表暂存 ===

由于组织经常从公共来源中提取开源组件，因此应该在管道中创建几个注册表（镜像仓库）阶段。只有经过授权的开发人员才能从公共注册表中提取基本镜像并将其存储在内部注册表中以供组织范围内广泛使用。另外，建议为每个团队或组保留单独的私有注册表，以保留开发工件，并为准备生产的镜像保留一个分段或预生产注册表。这可以在 CI/CD 链的不同阶段为类型不同的测试提供更严格的开源组件来源和安全性控制。

对于所有使用的注册表，必须通过专用的身份验证和权限模型进行访问控制。在架构内的其他交互之间，应该使用互相认证的 TLS 来保护所有注册表连接。

<span id="签名信任和完整性"></span>
=== 签名、信任和完整性 ===

为了确保构建的完整性和来源，可以在构建时对镜像内容进行数字签名，并在使用前验证签名数据。这个过程通常开始于确认构件已经过审查和批准，以及验证构件具有有效签名的过程。

对于软件供应链更为复杂的情况，需要创建单个构件依赖于多个验证步骤，因此需要一组实体的信任。以下是一些示例：

* 容器镜像签名 - 签署容器镜像清单的过程
* 配置文件签名 - 签署配置文件，例如应用程序配置文件
* 包签名 - 签署包含构件的软件包，例如应用程序包

对于通用软件构件，例如库或 OCI 构件，签名这些构件表示组织批准使用它们的来源。同样重要的是验证这些构件，以确保只允许授权的构件。强烈建议仓库需要相互验证身份，以向注册表中的镜像引入更改或向仓库提交代码。

=== 加密 ===

容器镜像加密可以保护容器镜像中的内容，确保其在构建和运行时都是保密的。即使被攻击，镜像的注册表内容也可以保密，这对于保护商业秘密或其他机密材料等用例非常有帮助。

另一个常见的容器镜像加密用途是强制执行授权。当镜像加密与密钥管理、运行时环境的证明和/或授权和凭据分发相结合时，可以要求容器镜像只能在特定平台上运行。容器镜像授权对于合规用例（如地理围栏或出口控制和数字版权媒体管理）非常有用。