仅当供应链中的第三方软件项目经过验证并标记为安全以供使用时，才会被定义完善的进程使用。 此模式是开发过程的一个操作侧车。 此模式的使用者调用此过程来验证和阻止使用可能引入安全漏洞的软件。
上下文和问题
云解决方案通常依赖于从外部源获取的第三方软件。 开源二进制文件、公共容器映像、供应商 OS 映像是此类项目的一些示例。 所有这些外部项目都必须被视为不受信任的 。
在典型的工作流中，项目从解决方案范围之外的存储中检索，然后集成到部署管道中。 此方法中存在一些潜在问题。 源可能不受信任，项目可能包含漏洞，或者它可能不适合以其他方式用于开发人员环境。
如果未解决这些问题，则解决方案的数据完整性和保密性保证可能会受到损害，或者由于与其他组件不兼容而导致不稳定。
可以通过向每个项目添加检查来避免其中一些安全问题。
溶液
在工作负载中引入软件之前，请执行一个过程来验证软件的安全性。 在此过程中，每个项目都会经过彻底的操作严格性，根据特定条件对其进行验证。 只有在项目满足这些条件后，进程才会将其标记为 受信任的。
隔离过程是一种安全措施，它包含一系列在使用项目之前使用的检查点。 这些安全检查点可确保项目从不受信任的状态过渡到受信任的状态。
请务必注意，隔离过程不会更改项目的组合。 此过程独立于软件开发周期，并根据需要由使用者调用。 作为项目的使用者，请阻止使用项目，直到它们通过隔离。
下面是典型的隔离工作流：
使用者发出其意向的信号，指定项目的输入源，并阻止其使用。
隔离过程验证请求的来源，并从指定的存储中获取项目。
自定义验证过程作为隔离的一部分执行，其中包括根据既定标准验证输入约束和检查属性、源和类型。
其中一些安全检查可能是每个提交的项目上的漏洞扫描、恶意软件检测等。
实际检查取决于项目的类型。 例如，评估 OS 映像与评估 NuGet 包不同。
如果验证过程成功，则会在安全存储中发布项目，其中包含明确的批注。 否则，它仍对使用者不可用。
发布过程可以包含一个累积报告，其中显示了验证证明和每个检查的关键性。 在报表中包含过期时间，超出该报表应无效，项目被视为不安全。
此过程通过向事件发出状态信息以及报告附带的状态信息的信号来标记隔离的结束。
根据信息，使用者可以选择采取措施来使用受信任的项目。 这些操作超出了隔离模式的范围。
问题和注意事项
作为使用第三方项目的团队，请确保从受信任的源获取它。 你的选择必须与从第三方供应商采购的项目的组织批准的标准保持一致。 供应商必须能够满足工作负荷（和组织）的安全要求。 例如，确保供应商的负责任的披露计划满足组织的安全要求。
在存储受信任和不受信任的项目的资源之间创建分段。 使用标识和网络控制来限制对授权用户的访问。
有一种可靠的方法来调用隔离过程。 请确保在标记为受信任之前，不会无意中使用项目。 信号应自动化。 例如，当项目引入开发人员环境、将更改提交到 GitHub 存储库、将映像添加到专用注册表等时，与通知责任方相关的任务。
实现隔离模式的替代方法是将其外包。 有隔离从业者专门从事公共资产验证作为其商业模式。 评估实施模式与外包责任的财务和运营成本。 如果安全要求需要更多控制，建议实现自己的过程。
自动执行项目引入过程和发布项目的过程。 由于验证任务可能需要一些时间，因此自动化过程必须能够继续，直到完成所有任务。
该模式用作第一次机会的瞬间验证。 成功通过隔离区不会确保项目无限期保持可信。 项目必须继续进行持续扫描、管道验证和其他例行安全检查，这些检查在提升发布之前充当最后的机会验证。
模式可由组织的中央团队或单个工作负荷团队实现。 如果隔离过程有许多实例或变体，则组织应标准化和集中这些操作。 在这种情况下，工作负荷团队共享该过程，并从卸载进程管理中获益。
何时使用此模式
在以下情况下使用此模式：
该工作负荷将集成在工作负荷团队范围之外开发的项目。 常见示例包括：
公共注册表（如 DockerHub、GitHub 容器注册表、Microsoft容器注册表）中的开放容器计划 （OCI） 项目
公共源中的软件库或包，例如 NuGet 库、Python 包索引、Apache Maven 存储库
外部基础结构即代码 （IaC） 包，例如 Terraform 模块、社区 Chef 食谱、Azure 验证模块
供应商提供的 OS 映像或软件安装程序
工作负荷团队将项目视为值得缓解的风险。 团队了解集成已泄露项目和隔离的价值，确保受信任的环境产生负面影响。
团队对应应用于项目类型的验证规则有明确和共享的了解。 如果没有共识，模式可能无效。
例如，如果在每次将 OS 映像引入隔离区时应用一组不同的验证检查，则 OS 映像的整体验证过程将不一致。
在以下情况下，此模式可能无效：
软件项目由工作负荷团队或受信任的合作伙伴团队创建。
不验证项目的风险比生成和维护隔离过程的成本更低。
工作负荷设计
架构师和工作负荷团队应评估隔离模式如何用作工作负荷 DevSecOps 实践的一部分。 Azure Well-Architected 框架支柱介绍了基本原则。
| 支柱 | 此模式如何支持支柱目标 |
|---|---|
| 安全 设计决策有助于确保工作负荷数据和系统的 保密性、完整性以及 可用性。 | 安全验证的第一个责任由隔离模式提供。 外部项目的验证在开发过程使用之前，在分段环境中执行。 - 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 防范恶意公共包。