在本文中，我們將討論與資訊安全風險管理 (ISRM) 控制項之常見高風險層分類集的分析和實作相關的 Azure 架構考量。
架構
此圖表顯示架構，並遵循企業級登陸區域的原則，特別是企業級分析和 AI 參考架構。
下載此架構的 Visio 檔案。
工作流程
該架構由以下各節中描述的工作流組成。 架構的每個元件在圖表中都有對應的數字。 我們會描述元件的主要用途、元件如何融入架構，以及採用該元件時應採取的任何其他重要考量：
- 平台訂用帳戶 – 透過 Microsoft Entra ID 提供管理、連線和身分識別的核心 Azure 訂用帳戶。 這裡不會更詳細地介紹這些帳戶，並假設在核心企業級設定中已就緒且可供使用。
資料管理
- 資料管理區域 – 資料管理區域負責跨平台的資料控管並強制執行護欄，以在資料登陸區域中提供更多下游的彈性。 此區域有自己的訂用帳戶，並裝載集中式服務，例如資料編錄、監視、稽核等等。 此環境受到高度控制，並受限於嚴格的稽核。 所有資料分類類型都會儲存在中央資料目錄 (Microsoft Purview)。 根據中繼資料，會強制執行不同的原則和存取模式。 整個租用戶只有一個資料管理區域訂用帳戶。 資料管理區域會與所有其他資料登陸區域進行對等互連 (透過虛擬網路對等互連)。 盡可能使用私人端點，以確保無法透過公用因特網存取已部署的服務。
- 網路資源群組 – Azure 虛擬網路、網路安全性群組，以及資料管理區域所需的所有其他網路相關資源，都會佈建在網路資源群組內。
- 部署資源群組 – 部署資源群組會裝載資料管理區域所需的私人 Azure DevOps CI/CD 代理程式 (虛擬機器)，以及儲存任何部署相關秘密的金鑰保存庫。
- 資料控管資源群組 – Microsoft Purview 會做為資料控管和資料目錄解決方案，並用來強制執行資料集的必要護欄，以遵循法律或其他實體所規定的資料需求和資料法規。 Microsoft Purview 會集中裝載在此資源群組內，以及用來儲存秘密的 Key Vault 執行個體。
- 集中式資產 – 集中式資產會裝載平台中心的重要且有價值資產，例如：
- 裝載 Azure Machine Learning 型資料產品中所使用基底映像的 Azure 容器登錄 (先前掃描的映像和無弱點的映像)
- 已發行並提供給平台上取用者的 AI/Machine Learning 模型 (因此可以視需要部署到一或多個資料登陸區域)。
- 其他服務 – 任何其他應該集中的服務都可以裝載在這些資源群組中，其中包括集中式 Azure API 管理執行個體、第三方軟體等等。
- 資料視覺化資源群組 – 此資源群組會裝載跨資料登陸區域共用的資料視覺化解決方案。 解決方案可以是 Power BI、Tableau 或任何其他視覺化解決方案。
- 其他基礎結構控制項和控管 – 適用於雲端的 Microsoft Defender 和 Azure 監視器會做為基準安全性和監視解決方案。
資料登陸區域
資料登陸區域 001 – 資料登陸區域是代表資料平台內縮放單位的訂用帳戶。 資料登陸區域會以核心資料登陸區域架構 (藍圖) 為基礎來部署，包括裝載分析和 AI 平台的所有重要功能。 環境中可以有一或多個資料登陸區域。 會套用 Azure 原則，以確保各種 Azure 服務的存取和設定安全。 資料登陸區域會與所有其他資料登陸區域和資料管理區域進行對等互連 (透過虛擬網路對等互連)。 盡可能使用私人端點，以確保無法透過公用因特網存取已部署的服務。
網路資源群組 – Azure 虛擬網路、網路安全性群組，以及資料登陸區域所需的所有其他網路相關資源，都會佈建在這個資源群組內。
部署資源群組 – 部署資源群組會裝載資料登陸區域所需的私人 Azure DevOps CI/CD 代理程式 (虛擬機器)，以及儲存任何部署相關秘密的金鑰保存庫。
資料儲存體資源群組 – 資料儲存體資源群組包含此資料登陸區域的主要資料儲存體帳戶，部署為具有階層命名空間的 Azure Data Lake Storage Gen2。 這些群組分散在三個主要區域：
- 原始 – 資料會從資料來源內嵌其原始狀態
- 策劃和擴充 – 資料已清理、驗證及匯總
- 工作區 – 特定資料產品可以儲存其資料集或 Machine Learning 模型的輸出等等
圖表中的箭號會顯示從原始資料到策劃和擴充 (受信任的) 資料的預期資料流程，並在工作區進行探索、分析，以提供資料產品的額外價值。
資料整合資源群組 – 資料整合資源群組會裝載與內部部署自我裝載整合執行階段 (SHIR) 共用連線的 Azure 資料處理站。 其主要目的是建立連線。 其他 Data Factory 執行個體會重複使用此群組，以便只在一個位置維護連線。 另一個用途是裝載 Azure Microsoft Purview 服務的自我裝載整合執行階段，以便存取此資料登陸區域的資料來源，以供掃描之用。
中繼資料管理資源群組 – 中繼資料管理資源群組會裝載 Azure Databricks 的中繼資料 (Hive 中繼存放區)，以及 Azure Data Factory 內嵌和處理管線。 此群組也會裝載金鑰保存庫，以儲存用於存取此資料的秘密。 Azure SQL Database 可用來裝載中繼資料。
資料內嵌資源群組 – 資料內嵌資源群組會裝載 Azure Data Factory 執行個體，其中會部署資料網域專屬的所有資料內嵌管線。 Azure Databricks 可用來做為處理引擎來載入和轉換資料，並將其儲存在 Data Lake 帳戶中。
分析資源群組 – 分析資源群組包含兩個共用服務，用於進一步資料分析和探索：Azure Synapse 和 Azure Databricks。 這兩項服務都針對大量資料探索和分析目的，提供廣泛的計算和規模。
資料產品資源群組 – 資料產品資源群組是資料產品的藍圖，而資源群組包含資料產品可能需要的基本 Azure 資源。 部署應該可透過 Azure DevOps 管線根據企業的特定需求來設定。 此處部署的核心 Azure 服務如下所示：
- Azure Machine Learning 工作區做為任何具有相關服務的企業機器學習專案的基礎，例如 Key Vault (用於儲存秘密)
- Application Insights (用於模型監測)
- Azure 儲存體 (用於儲存資料集)
- 用於在開發期間儲存模型映像的 Azure 容器登錄
Azure AI 服務會部署為套件，以提供多個 AI 支援服務的 API 存取，而 Azure Machine Learning 計算執行個體和計算叢集則用於開發、建模和測試用途。 如有需要，Azure Data Factory 可用來協調模型的批次評分。 Azure App Service 和 Azure Cosmos DB 提供額外一層資料產品部署，其中自訂應用程式或 API 可以裝載自己的內部資料存放區。
受管制的產業通常會有嚴格的資料存取限制，而且通常只允許生產環境裝載生產資料。 因此，資料產品的開發生命週期只會發生在生產資料登陸區域中，而個別的環境或資源群組會佈建以供開發、測試和部署之用。
其他資料產品 – 這些資源群組裝載其他資料產品，因為一個資料登陸區域可以裝載一或多個資料產品。
共用計算資源群組 – 此資源群組內佈建裝載和部署資料產品所需的任何共享計算。 Azure Kubernetes 服務叢集就是一個示例。
其他基礎結構控制項和控管 – 適用於雲端的 Microsoft Defender 和 Azure 監視器會做為基準安全性和監視解決方案。
資料登陸區域 002 – 此登陸區域是用於裝載新資料登陸區域的額外 Azure 訂用帳戶預留位置。 這些準則以之前所述的準則為基礎，例如資料落地需求，或具有自己跨功能小組的不同業務單位，以及要傳遞的一組使用案例。
元件
- Microsoft Entra ID
- Azure Purview
- Azure 虛擬網路
- Azure DevOps
- Azure Container Registry
- Azure Machine Learning
- 適用於雲端的 Microsoft Defender
- Azure 監視器
- Azure 原則
- Azure Data Lake 儲存體
- Azure Data Factory
- Azure SQL Database
- Azure Databricks
- Azure Synapse Analytics
- Azure Kubernetes Service
替代項目
在分散式組織中，商務群組會獨立運作，且具有高度自主性。 因此，他們可能會考慮替代解決方案設計，在 Azure 登陸區域中完全隔離使用案例，共用一組最少的一般服務。 雖然此設計允許快速啟動，但需要 IT 和 ISRM 組織投入大量精力，因為個別使用案例的設計可能會快速脫離藍圖設計。 此外，還需要針對裝載於 Azure 中的每個 AI 和 Machine Learning 產品進行獨立的 ISRM 程式和稽核。
案例詳細資料
無論其數位成熟度和大小為何，在受管制環境中調整 AI 和機器學習計劃，都對組織構成重大挑戰。 在本文中，我們會討論在受管制產業採用 Azure 資料工程和機器學習服務時要考慮的重要架構決策。 這些決定是根據從財星雜誌 500 大全球生命科學和醫療保健公司最近的實作所學到的知識而做出。
本文所呈現的架構遵循企業級分析和 AI 參考架構設計，是其第一個實作之一。
如果您設定資料科學專案並在生命科學和醫療保健環境中開發機器學習模型，則幾乎所有情況下，都需要存取高業務影響 (HBI) 資料來源。 例如，這些來源可以是臨床試驗通訊協議資訊，而不需要病患資料、分子的化學配方或製造流程秘密。
在受管制的產業中，IT 系統會根據這些系統存取的資料來源分類來分類。 在 Azure 上執行的 AI 和機器學習環境會分類為 HBI，且必須符合一組廣泛的 ISRM 原則和控制項。
設計原則
此架構基於以下原則：
- 企業級是一種架構方法和參考實作，符合 Azure 藍圖且為 Microsoft 雲端採用架構的一部分。 其可大規模地對 Azure 上的登陸區域進行有效的建構和運作。 名稱登陸區域會做為新應用程式或已遷移應用程式登陸 Azure 的界限。 在此案例中，這也是指用來裝載資料和 AI/Machine Learning 模型的資料平台部分。
- 傳統的整合型資料平台架構有一個固有的限制，會減緩特性和值的傳遞。 此處所述的架構可讓組織調整其資料資產，並藉由使用具有擁有權分離的分散式方法來解決集中式整合式資料湖的挑戰。 這種方法可讓組織調整為數千個內嵌管線和資料產品，同時藉由將核心資料平台和資料管理服務 (部署在稱為資料管理區域的個別登陸區域) 與資料網域和資料產品 (部署到一或多個資料登陸區域) 分離，以確保資料平台的安全和維護。
- 訂用帳戶是做為與業務需求和優先順序一致的管理及調整單位。 藉由根據不同的業務項目關係人、不同的業務目標和需求，以及資料落地需求 (資料需要裝載於特定地理區域中) 等準則，為業務單位提供新的訂用帳戶 (資料登陸區域) 來達成調整。
- Azure 原則可用來提供護欄，並確保在公司 IT 環境中持續符合規範。
- 單一控制和管理平面 (透過 Azure 入口網站) 會在所有 Azure 資源和佈建通道中提供一致的體驗，遵循角色型存取和原則導向控制。 盡可能運用 Azure 原生平台服務和功能。
- 跨功能小組會擁有設計、開發和作業的擁有權，以縮短上市時間和平台內靈活度的時間。 DevOps、基礎結構即程式碼 (IaC) 和彈性設計等核心原則可用來避免人為錯誤和單一失敗點。
- 領域和資料來源主題專家可以使用資料網域，從 Azure、第三方或內部部署環境提取資料資產。 資料網域是資料登陸區域內的資源群組，可供跨職能小組用於自訂資料內嵌。 資料登陸區域內可以有一或多個資料域。 資料網域可以視為類似網域驅動設計中的網域，提供內容界限、自給自足且隔離。 資料域的範例是臨床試驗資料或供應鏈資料。
潛在使用案例
本文所討論的架構考量在生命科學和醫療保健產業中都有其來源。 不過，這些考量也適用於其他受管制產業的組織，包括下列產業：
- 金融服務
- 醫療提供者
- 石油與天然氣
在受管制的環境中實作企業級分析和 AI 參考架構遵循類似的設計模式。
考量
這些考量能實作 Azure Well-Architected Framework 的支柱，其為一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework (部分機器翻譯)。
在本節中，我們會討論在生命科學和醫療保健管制環境中實作稍早所述的架構所學到的教訓。 我們也涵蓋符合常見 ISRM 控制項和原則的高階設計考量。
安全性
安全性可提供保證，以避免刻意攻擊和濫用您寶貴的資料和系統。 如需詳細資訊，請參閱安全性支柱的概觀。
環境
在受管制的環境中，分類為 HBI 的 IT 系統必須有多個隔離的環境，例如開發、品質和生產環境或類似環境。 只有經過生產認證的環境中，才能存取受保護的資料來源。
由於 AI 和機器學習開發需要存取敏感資料集，因此機器學習作業流程的不同階段，例如模型建置、定型和推斷 (或類似階段)，都會在生產環境中進行。 開發和品質環境通常受限於基礎結構、作業和資料工程類型的工作，以確保隨著新的 Azure 服務和功能可供使用，持續增強功能。
AI 和資料科學開發活動應在生產環境中執行，但沙箱或早期探勘工作除外。
加密
需要 IT 系統存取、儲存及處理機密商務資料，才能實作加密金鑰管理的特定需求，例如 FIPS 140-2 層級 2 或層級 3 原則，以及客戶自控金鑰 (CMK) 整合。 使用 TLS 1.2 或更高版本的通訊協定，受保護的資料必須一律在待用和傳輸中加密。
在架構設計期間，需要仔細分析 Azure 服務對組織 CMK 基礎結構的支援和整合。 資料加密的任何例外狀況都必須記載。 硬體安全性模組 (HSM) 廠商的支援一律會擴充，您可以在 Azure Key Vault 受控硬體安全性模組中找到其他資訊。
網路設計和環形隔離
AI 和機器學習環境必須具備環狀隔離，並實作網路分割和網路存取控制。 架構元件之間的網路通訊僅限於必要的資料流程和基礎結構，以在允許清單方法中運作。 應套用簽章型分析和行為型分析。
在架構的數個層級強制執行網路存取控制，包括 Azure 防火牆、檢查輸入和輸出網路連線能力、網路安全組，以及使用 Web 應用程式防火牆 (WAF) 保護的 Web 應用程式端點存取權。
授權管理
在 Azure 上執行的 AI 和機器學習環境必須與組織的主要帳戶佈建系統整合，其中提交、核准和稽核要授與重要商務應用程式存取權的要求。
帳戶佈建系統應該連線到組織的 Active Directory 和 Microsoft Entra 識別符，讓商務授權角色對應至對應的 Active Directory 和 Microsoft Entra 安全組。
AI 和機器學習環境遵循角色型存取控制模型。 存取控制授權可確保使用者只能針對其作業角色和商務需求執行工作和動作。 機器學習使用案例應該會高度隔離，因為在特定使用案例中工作的資料科學家只允許存取該使用案例的資源部分，並遵循最低權限原則。 這些資源可能包括：
- 儲存體帳戶
- Azure Machine Learning 工作區
- 計算執行個體
角色型存取控制會使用 Microsoft Entra 識別碼中的安全組。
多重要素驗證
多重要素驗證必須就緒並實作，才能存取在 Azure 上執行的所有環境，並分類為高業務影響。 您可以使用 Microsoft Entra 多重要素驗證服務來強制執行多重要素驗證。 包括 Azure DevOps、Azure 管理入口網站、Azure Machine Learning、Azure Databricks 和 Azure Kubernetes Service 等應用程式端點，應該在多重要素驗證存取控制原則中設定。
您必須對所有使用者強制執行多重要素驗證，包括 Azure 服務經理、資料工程師和資料科學家。
卓越營運
卓越營運涵蓋部署應用程式並使其持續在生產環境中執行的作業流程。 如需詳細資訊，請參閱卓越營運支柱的概觀 (部分機器翻譯)。
記錄和監視
所有 Azure 服務都必須將其安全性事件內嵌至組織的安全性作業中心 (SOC) 平台，且應記錄下列安全性事件：
- 成功和失敗的驗證嘗試
- 敏感資料存取
- 安全性原則的變更
- 管理使用者群組、使用者或角色的變更
- 如果適用，敏感資料會傳輸到外部位置
- 啟用和停用保護系統，例如屬性型存取控制 (ABAC) 控制件
- 已更新記錄的存取權，以及記錄中斷
Azure 安全性記錄可以透過不同的模式內嵌至 SOC：
- 中央 Azure Log Analytics 工作區
- 連線到 SOC 平台系統的事件中樞，例如 Splunk
- 使用 SOC 代理程式部署的 Windows VM 和其他計算資源
DevOps
在受規範的環境中，IT 系統必須遵循嚴格的瀑布式品質控制流程，並在流程階段之間獲得正式核准 (或閘道)，例如使用者需求規格、功能規格、設計和測試規格 (或類似階段)，還要熟悉大量耗時的支援文件。
Azure 環境和資料科學開發會遵循反覆程式，並錨定在 DevOps 文化特性中。 在調整 AI 和機器學習計劃方面，花費大量精力來傳達 DevOps 組織的支柱，並在 Azure DevOps Epics、功能、使用者劇本、測試計劃和 CI/CD 管線之間建立自動化端對端可追蹤性對應，以及必要的品質控制實體和辨識項。
效能效益
效能效率可讓您的工作負載進行調整，以有效率的方式符合使用者對其放置的需求。 如需詳細資訊，請參閱效能效率支柱概觀。
若要在受管制的環境中調整 AI 和機器學習，並推動跨組織業務領域的快速採用，建議您設計和設定採用架構，以測量、監視及評估 Azure 服務所創造的價值。 我們在生命科學和醫療保健產業範例中，評估了下列商業價值槓桿和關鍵績效指標 (KPI)：
延展性 – 為了確保 Azure 架構可以隨著業務需求進行調整，無論調整點為何，建議使用下列 KPI：
- 計算執行個體數目，以及使用的儲存體和記憶體總數
- 已執行的實驗數目
- 已部署的模型數目
加速 AI 開發 – 若要加速 AI 和機器學習解決方案開發，建議使用下列 KPI：
- 取用 Azure AI 和機器學習服務的不同業務單位數目
- 每個類別上線的使用者數目 – 例如資料工程師、資料科學家、公民資料科學家和商務使用者
- 已執行的實驗數目
- 使用者上線與使用中使用量之間的時間
- 佈建服務的時間 – 從變更設定要求到服務佈建完成
合規性 – 為了確保已部署的 AI 和機器學習解決方案持續合規，建議使用下列 KPI：
- 與適用 ISRM 控制項的整體相容性
- 安全性弱點警告的數目
- 最後一個期間的安全性事件數目
使用者體驗 – 為了確保提供高品質且一致的使用者體驗，建議使用下列 KPI：
- 使用者技術支援中心要求數目
- 淨推薦分數 (NPS)
安全基礎 – 為了確保已備妥安全的基礎，建議使用下列 KPI：
- 重要服務運行時間
- 與效能可用性相關的事件數目
成本最佳化
成本最佳化是關於考慮如何減少不必要的費用，並提升營運效率。 如需詳細資訊，請參閱成本最佳化支柱的概觀。
成本管理是實作可調整 AI 和機器學習平台設計的重要部分，因為執行成本不會遵循簡單且可預測的模式。 成本主要是由平台中執行的 AI 和機器學習實驗數目和大小所驅動，更具體地說是模型定型和推斷中使用的計算資源數目和 SKU。
以下是我們建議的一些做法：
- 指派每個使用案例和 AI 和機器學習產品自己的 Azure 服務預算，這是良好的成本管理做法。
- 建立平台共用服務的透明成本模型。
- 使用標籤一致地將使用案例和產品資源與成本中心產生關聯。
- 使用 Azure Advisor 和 Azure 預算來了解資源未以最佳方式使用的位置，並定期檢閱設定。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主要作者：
- Eran Sagi | AI 解決方案架構設計師
下一步
了解如何使用 Azure Machine Learning 定型和部署模型，以及管理機器學習生命週期。 此處提供了教學課程、程式碼範例、API 參考等：
了解如何在 Azure 中為資料分析和 AI 實作企業級登陸區域：
產品文件：
相關資源
Azure 架構中心概觀文章：