仅当供应链中的第三方软件项目经过定义明确的进程验证并标记为可安全使用时，才使用第三方软件项目。 此模式是开发流程的操作挎斗。 此模式的使用者会调用此进程来验证和阻止使用可能会引入安全漏洞的软件。
上下文和问题
云解决方案通常依赖于从外部源获取的第三方软件。 开源二进制文件、公共容器映像、供应商 OS 映像是这些类型的项目的一些示例。 所有此类外部项目都必须被视为不受信任。
在典型的工作流中，从解决方案范围之外的存储区中检索项目，然后将其集成到部署管道中。 此方法中存在一些潜在问题。 源可能不受信任，项目可能包含漏洞，或者它可能不适合以其他方式用于开发人员环境。
如果未解决这些问题，则可能会危及解决方案的数据完整性和保密性保证，或者由于与其他组件不兼容而导致不稳定。
通过向每个项目添加检查，可以避免其中一些安全问题。
解决方案
在工作负荷中引入软件之前，请执行一个进程来验证软件的安全性。 在此进程中，每个项目都会经过仔细严格的操作，以根据特定条件对其进行验证。 只有在项目满足这些条件后，进程才会将其标记为受信任。
隔离过程是一种安全措施，它由一系列在使用项目之前采用的检查点组成。 这些安全检查点可确保项目从不受信任状态过渡到受信任状态。
请务必注意，隔离过程不会更改项目的组合。 此过程独立于软件开发周期，并由使用者根据需要调用。 作为项目的使用者，请在项目完成隔离之前阻止使用项目。
下面是典型的隔离工作流：
使用者发出其意向的信号，指定项目的输入源，并阻止其使用。
隔离过程会验证请求的来源，并从指定的存储区中获取项目。
自定义验证过程作为隔离的一部分执行，其中包括根据既定标准验证输入约束和检查属性、源和类型。
其中一些安全检查可能是针对每个提交的项目进行漏洞扫描、恶意软件检测等。
实际检查取决于项目的类型。 例如，评估 OS 映像与评估 NuGet 包不同。
如果验证过程成功，则会在安全存储区中发布项目，其中包含明确的批注。 否则，它仍对使用者不可用。
发布过程可能会包含一个累积报告，其中显示验证证明和每项检查的关键性。 在报告中包含过期时间，超过该时间报告应无效，且项目被视为不安全。
此过程通过发出带状态信息和报告的事件信号来标记隔离的结束。
根据这些信息，使用者可以选择采取措施来使用受信任项目。 这些操作超出了隔离模式的范围。
问题和注意事项
作为使用第三方项目的团队，请确保从受信任源获取项目。 您的选择必须与从第三方供应商采购的项目的组织批准标准保持一致。 供应商必须能够满足工作负荷（和贵组织）的安全性要求。 例如，确保供应商的负责任披露计划满足贵组织的安全性要求。
在存储受信任和不受信任的项目的资源之间创建分段。 使用标识和网络控制来仅限授权用户访问。
有一种可靠的方法可用于调用隔离流程。 确保在将项目标记为受信任之前，未意外使用项目。 信号应自动发出。 例如，将项目引入开发人员环境、将更改提交到 GitHub 存储库、将映像添加到专用注册表等时，与通知责任方相关的任务。
一种实施隔离模式的替代方法是将其外包。 有隔离从业者专门从事公共资产验证作为其商业模式。 评估实施模式与外包责任的财务和运营成本。 如果安全性要求需要更多控制，建议实施自己的流程。
自动执行项目引入流程和项目发布流程。 由于验证任务可能需要一些时间，因此自动化流程必须能够继续，直到完成所有任务。
该模式用作第一次机会的瞬间验证。 成功通过隔离并不确保项目无限期保持可信。 项目必须继续进行持续扫描、管道验证和其他常规安全检查，这些安全检查在升级版本之前充当最后机会验证。
模式可由组织的中央团队或单个工作负荷团队实施。 如果隔离流程有许多实例或变体，则组织应标准化和集中化这些操作。 在这种情况下，工作负荷团队将共同负责完成该流程，并从卸载流程管理中获益。
何时使用此模式
在以下情况下使用此模式：
工作负荷将集成在工作负荷团队范围之外开发的项目。 常见示例包括：
公共注册表中的开放容器计划 (OCI) 项目，例如 DockerHub、GitHub 容器注册表、Microsoft 容器注册表
公共源中的软件库或包，例如 NuGet 库、Python 包索引、Apache Maven 存储库
外部基础结构即代码 (IaC) 包，例如 Terraform 模块、社区 Chef 指南、Azure 验证模块
供应商提供的 OS 映像
工作负荷团队将项目视为值得缓解的风险。 该团队了解集成已泄露项目的负面影响，以及隔离在确保受信任环境方面的价值。
该团队都清楚地了解应该应用于某种项目类型的验证规则。 如果没有共识，模式可能就会无效。
例如，如果在每次将 OS 映像引入隔离时应用一组不同的验证检查，OS 映像的整体验证过程就会变得不一致。
在以下情况下，此模式可能不起作用：
软件项目由工作负荷团队或受信任合作伙伴团队创建。
不验证项目的风险比生成和维护隔离流程的成本更低。
工作负载设计
架构师和工作负荷团队应评估将隔离模式用于工作负荷 DevSecOps 实践的方式。 Azure Well-Architected Framework 支柱中介绍了基本原则。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 安全设计决策有助于确保工作负荷数据和系统的机密性、完整性和可用性。 | 安全验证的第一个责任由隔离模式提供。 在开发流程中使用外部项目之前，会在分段环境中对其进行验证。 - SE:02 安全开发生命周期 - SE:11 测试和验证 |
| 卓越运营有助于通过标准化流程和团队凝聚力提供工作负载质量。 | 隔离模式支持安全部署实践 (SDP)，方法是确保工作负荷不会使用已泄露的项目，因为这可能会导致在渐进式曝光部署期间出现安全漏洞。 - OE:03 软件开发做法 - OE:11 测试和验证 |
与任何设计决策一样，请考虑对可能采用此模式引入的其他支柱的目标进行权衡。
示例
此示例将解决方案工作流应用于工作负荷团队希望将 OCI 项目从公共注册表集成到工作负荷团队拥有的 Azure 容器注册表 (ACR) 实例的场景。 该团队将该实例视为受信任项目存储区。
工作负荷环境使用适用于 Kubernetes 的 Azure Policy 强制实施治理。 它限制仅从其受信任注册表实例进行容器拉取。 此外，还设置了 Azure Monitor 警报，以检测从意外源导入到该注册表的任何导入。
工作负荷团队通过 Azure Web 应用上托管的自定义应用程序发出外部映像请求。 应用程序仅从授权用户收集所需的信息。
安全检查点：验证请求者的标识、目标容器注册表和请求的映像源。
请求存储在 Azure Cosmos DB 中。
安全检查点：在数据库中维护审核线索，跟踪映像的世系和验证。 此线索还用于历史报告。
请求由工作流业务流程协调程序处理，该业务流程协调程序是持久 Azure 函数。 业务流程协调程序使用分散-聚集方法来运行所有验证。
安全检查点：业务流程协调程序具有托管标识，具有足够访问权限来执行验证任务。
业务流程协调程序发出将映像导入隔离 Azure 容器注册表 (ACR) 的请求，该注册表被视为不受信任存储区。
隔离注册表上的导入流程从不受信任的外部存储库获取映像。 如果导入成功，隔离注册表具有映像的本地副本来执行验证。
安全检查点：隔离注册表可防止验证过程中的篡改和工作负荷消耗。
业务流程协调程序在映像的本地副本上运行所有验证任务。 任务包括检查，例如常见漏洞和泄露 (CVE) 检测、软件材料清单 (SBOM) 评估、恶意软件检测、映像签名等。
业务流程协调程序决定检查的类型、执行顺序和执行时间。 在此示例中，它使用 Azure 容器实例作为任务运行器，结果位于 Cosmos DB 审核数据库中。 所有任务可能需要很长时间。
安全检查点：此步骤是执行所有验证检查的隔离流程的核心。 检查类型可以是自定义、开源或供应商购买的解决方案。
业务流程协调程序做出决定。 如果映像通过所有验证，则会在审核数据库中记录该事件，将映像推送到受信任注册表，并从隔离注册表中删除本地副本。 否则，将从隔离注册表中删除映像，以防止意外使用。
安全检查点：业务流程协调程序维护受信任和不受信任的资源位置之间的分段。
注意
工作负荷团队可以承担该责任，而不是由业务流程协调程序做出决定。 在此替代方法中，业务流程协调程序通过 API 发布验证结果，并在隔离注册表中保留映像一段时间。
工作负荷团队在评审结果后做出决定。 如果结果满足其风险容忍度，则会将映像从隔离存储库提取到其容器实例中。 将此模式用于支持具有不同安全风险容忍度的多个工作负荷团队时，此拉取模型更为实用。
Microsoft Defender for Containers 涵盖所有容器注册表，会持续扫描新发现的问题。 这些问题将显示在 Microsoft Defender 漏洞管理中。
后续步骤
实现此模式时，以下指南可能比较有用：
用于保护开发生命周期的推荐提供有关在开发生命周期的所有阶段使用受信任代码单元的指导。
安全软件供应链的最佳实践，尤其是在应用程序中具有 NuGet 依赖项时。
Azure Artifacts 文档是与使用 Azure Artifacts 管理软件包相关的信息库。