只有在經過妥善定義的程序驗證並標示為安全供使用時，才會在供應鏈中取用第三方軟體成品。 此模式是開發程式的操作側車。 此模式的取用者會叫用此程式，以驗證並封鎖可能會造成安全性弱點的軟體使用。
內容和問題
雲端解決方案通常依賴從外部來源取得的第三方軟體。 開放原始碼二進位檔、公用容器映像、廠商OS映像是這類成品的一些範例。 所有這類外部成品都必須被視為 不受信任。
在一般工作流程中，成品會從解決方案範圍外的存放區擷取，然後整合到部署管線中。 此方法中有一些潛在的問題。 來源可能不受信任、成品可能包含弱點，或可能不適合開發人員環境的其他方式。
如果未解決這些問題，解決方案的數據完整性和機密性保證可能會遭到入侵，或因為與其他元件不相容而造成不穩定。
您可以藉由將檢查新增至每個成品，來避免其中一些安全性問題。
解決方案
在工作負載中引進軟體之前，請進行程式來驗證軟體的安全性。 在程序期間，每個成品都會經過徹底的操作嚴謹性，以針對特定條件進行驗證。 只有在成品符合這些條件之後，進程才會將其標示為 受信任。
隔離的程式是一項安全性措施，其中包含取用成品之前採用的一系列檢查點。 這些安全性檢查點可確保成品會從不受信任的狀態轉換為受信任的狀態。
請務必注意，隔離程式不會變更成品的組成。 此程式與軟體開發周期無關，而且會視需要由取用者叫用。 作為成品的取用者，請封鎖使用成品，直到它們通過隔離為止。
以下是典型的隔離工作流程：
取用者會發出其意圖的訊號、指定成品的輸入來源，並封鎖其使用。
隔離程式會驗證要求的來源，並從指定的存放區取得成品。
自定義驗證程式會作為隔離的一部分執行，包括驗證輸入條件約束，以及根據已建立的標準檢查屬性、來源和類型。
其中一些安全性檢查可能是每個提交的成品上的弱點掃描、惡意代碼偵測等等。
實際檢查取決於成品的類型。 例如，評估OS映像與評估NuGet套件不同。
如果驗證程式成功，成品會在具有清楚批注的安全存放區中發佈。 否則，它仍無法供取用者使用。
發佈程式可以包含累積報告，其中顯示驗證證明和每個檢查的嚴重性。 在報表中包含到期日，報表應該無效，而且成品被視為不安全。
此程式會標示隔離的結尾，方法是向事件發出通知，其中包含報告隨附的狀態資訊。
根據資訊，取用者可以選擇採取動作來使用受信任的成品。 這些動作超出隔離模式的範圍。
問題和考量
身為取用第三方成品的小組，請確定它是從受信任的來源取得的。 您的選擇必須與從第三方廠商採購的成品的組織核准標準一致。 廠商必須能夠符合工作負載（和組織）的安全性需求。 例如，請確定廠商的負責任洩漏計劃符合貴組織的安全性需求。
建立儲存受信任和不受信任成品的資源之間的分割。 使用身分識別和網路控制來限制對授權使用者的存取。
有可靠的方法來叫用隔離程式。 請務必在標示為受信任之前，不小心取用成品。 訊號應該自動化。 例如，當成品擷取至開發人員環境、認可 GitHub 存放庫的變更、將映射新增至私人登錄等等時，通知責任方的相關工作。
實作隔離模式的替代方法是將其外包。 有隔離從業者專門從事公共資產驗證作為其商業模式。 評估實作模式與外包責任的財務和營運成本。 如果您的安全性需求需要更多控制權，建議實作您自己的程式。
自動化成品擷取程式，以及發佈成品的程式。 因為驗證工作可能需要時間，因此自動化程式必須能夠繼續，直到所有工作都完成為止。
此模式可作為第一次機會暫時驗證。 成功通過隔離不會確保成品無限期地保持可信任。 成品必須繼續進行持續掃描、管線驗證，以及其他例行安全性檢查，以作為升級發行前的最後機會驗證。
此模式可由組織的中央小組或個別工作負載小組實作。 如果隔離程式有許多實例或變化，則組織應該標準化和集中這些作業。 在此情況下，工作負載小組會共享程式，並受益於卸除程式管理。
使用此模式的時機
當下列情況時，請使用此模式：
工作負載會整合在工作負載小組範圍之外開發的成品。 常見的範例包括：
來自公用登錄的開放式容器計劃 （OCI） 成品，例如 DockerHub、GitHub Container Registry、Microsoft container registry
來自公用來源的軟體連結庫或套件，例如 NuGet 資源庫、Python 套件索引、Apache Maven 存放庫
外部基礎結構即程序代碼 （IaC） 套件，例如 Terraform 模組、Community Chef Cookbooks、Azure 已驗證的模組
廠商提供的OS映像
工作負載小組會將成品視為值得緩和的風險。 小組瞭解整合遭入侵成品的負面後果，以及確保受信任環境隔離的價值。
小組對應套用至成品類型的驗證規則有清楚且共用的瞭解。 如果沒有共識，模式可能無效。
例如，如果在每次將OS映射內嵌至隔離區時套用不同的驗證檢查集，OS 映像的整體驗證程式就會變得不一致。
當下列情況時，此模式可能不實用：
軟體成品是由工作負載小組或受信任的合作夥伴小組所建立。
未驗證成品的風險比建置和維護隔離程式的成本還低。
工作負載設計
架構設計人員和工作負載小組應該評估隔離模式如何作為工作負載DevSecOps實務的一部分使用。 基本準則涵蓋在 Azure 架構完善的架構要素中。
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 安全性驗證的第一個責任是由隔離模式提供。 在開發程式取用外部成品之前，會在分段環境中進行外部成品的驗證。 - SE：02 安全開發生命週期 - SE：11 測試和驗證 |
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 隔離模式支援安全部署做法 （SDP），方法是確保工作負載不會取用遭入侵的成品，這可能會導致在漸進式暴露部署期間發生安全性缺口。 - OE：03 軟體開發做法 - OE：11 測試和驗證 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
範例
此範例會將 解決方案工作流程 套用至工作負載小組想要將 OCI 成品從公用登錄整合至工作負載小組所擁有的 Azure Container Registry （ACR） 實例的案例。 小組會將該實例視為受信任的成品存放區。
工作負載環境會使用適用於 Kubernetes 的 Azure 原則 來強制執行治理。 它只會限制容器從其信任的登錄實例提取。 此外，系統會設定 Azure 監視器警示，以偵測從非預期來源匯入該登錄的任何匯入。
工作負載小組會透過 Azure Web Apps 上裝載的自定義應用程式，提出外部映像的要求。 應用程式只會從授權的使用者收集必要的資訊。
安全性檢查點：驗證要求者的身分識別、目的地容器登錄和要求的映射來源。
要求會儲存在 Azure Cosmos DB 中。
安全性檢查點：稽核記錄會保留在資料庫中，並追蹤映像的譜系和驗證。 此記錄也會用於歷程記錄報告。
要求是由工作流程協調器處理，這是持久的 Azure 函式。 協調器會使用散佈收集方法來執行所有驗證。
安全性檢查點：協調器具有具有足夠存取權的受控識別來執行驗證工作。
協調器會提出將映像匯入隔離 Azure Container Registry （ACR） 的要求，該隔離區被視為不受信任的存放區。
隔離登錄上的匯入程式會從不受信任的外部存放庫取得映像。 如果匯入成功，隔離登錄就會有映像的本機複本來執行驗證。
安全性檢查點：隔離登錄可防止驗證程序期間遭到竄改和工作負載耗用量。
協調器會在映像的本機複本上執行所有驗證工作。 工作包括檢查，例如常見弱點和暴露率（CVE）偵測、軟體材料帳單（SBOM）評估、惡意代碼偵測、映像簽署等。
協調器會決定檢查的類型、執行順序，以及執行時間。 在此範例中，它會使用 Azure 容器實例作為工作執行器，而結果位於 Cosmos DB 稽核資料庫中。 所有工作可能需要相當長的時間。
安全性檢查點：此步驟是執行所有驗證檢查的隔離程式的核心。 檢查類型可以是自定義、開放原始碼或廠商購買的解決方案。
協調器會做出決定。 如果映像通過所有驗證，則會在稽核資料庫中指出事件、將映像推送至受信任的登錄，並從隔離登錄中刪除本機複本。 否則，映射會從隔離登錄中刪除，以防止其不小心使用。
安全性檢查點：協調器會維護受信任與不受信任資源位置之間的分割。
注意
工作負載小組可以承擔該責任，而不是進行決策的協調器。 在此替代方式中，協調器會透過 API 發佈驗證結果，並將映像保留在隔離登錄中一段時間。
工作負載小組會在檢閱結果之後做出決策。 如果結果符合其風險承受能力，則會將映像從隔離存放庫提取到其容器實例。 當此模式用來支援具有不同安全性風險承受能力的多個工作負載小組時，此提取模型更為實用。
所有容器登錄都由適用於容器的 Microsoft Defender 所涵蓋，這些登錄會持續掃描新發現的問題。 這些問題會顯示在 Microsoft Defender 弱點管理 中。
下一步
實作此模式時，下列指引可能相關：
建議 來保護開發生命週期，提供透過開發生命週期的所有階段使用受信任程式碼單位的指引。
安全軟體供應鏈 的最佳做法，特別是當您應用程式中有 NuGet 相依性時。
Azure Artifacts 檔 是使用 Azure Artifacts 管理軟體套件的相關信息連結庫。