本文說明使用 Azure Synapse 建置安全 Data Lakehouse 解決方案的設計程式、原則和技術選擇。 我們著重于安全性考慮和關鍵技術決策。
Apache、 Apache® Spark® 和火焰標誌是美國和/或其他國家/地區的 Apache Software Foundation 注冊商標或商標。 Apache Software Foundation 不會隱含使用這些標記。
架構
下圖顯示 Data Lakehouse 解決方案的架構。 其設計目的是要控制服務之間的互動，以減輕安全性威脅。 解決方案會根據功能和安全性需求而有所不同。
資料流程
解決方案的資料流程如下圖所示：
- 資料會從資料來源上傳至資料登陸區域、Azure Blob 儲存體或Azure 檔案儲存體所提供的檔案共用。 資料是由批次上傳程式或系統上傳。 串流資料會使用 Azure 事件中樞 的擷取功能，擷取並儲存在 Blob 儲存體中。 可以有多個資料來源。 例如，數個不同的處理站可以上傳其作業資料。 如需保護 Blob 儲存體、檔案共用和其他儲存體資源存取權的相關資訊，請參閱 Blob 儲存體 的安全性建議和 規劃Azure 檔案儲存體部署 。
- 資料檔案的抵達會觸發 Azure Data Factory 來處理資料，並將其儲存在核心資料區域中的資料湖中。 將資料上傳至 Azure Data Lake 中的核心資料區域，可防止資料外流。
- Azure Data Lake 會儲存從不同來源取得的原始資料。 它受到防火牆規則和虛擬網路的保護。 它會封鎖來自公用網際網路的所有連線嘗試。
- Data Lake 中的資料抵達會觸發 Azure Synapse 管線，或計時觸發程式會執行資料處理作業。 Azure Synapse 中的 Apache Spark 會啟動並執行 Spark 作業或筆記本。 它也會協調 Data Lakehouse 中的資料流程。 Azure Synapse 管線會將資料從 銅級區域轉換成銀區，然後轉換成黃金區域 。
- Spark 作業或筆記本會執行資料處理作業。 資料策展或機器學習訓練作業也可以在 Spark 中執行。 黃金區域中的結構化資料會以 Delta Lake 格式儲存 。
- 無伺服器 SQL 集區 會建立外部資料表 ，以使用儲存在 Delta Lake 中的資料。 無伺服器 SQL 集區提供強大且有效率的 SQL 查詢引擎，並可支援傳統的 SQL 使用者帳戶或 Microsoft Entra 使用者帳戶。
- Power BI 會連線到無伺服器 SQL 集區，以將資料視覺化。 它會使用 Data Lakehouse 中的資料來建立報表或儀表板。
- 資料分析師或科學家可以登入 Azure Synapse Studio，以：
- 進一步增強資料。
- 分析以取得商業見解。
- 定型機器學習模型。
- 商務應用程式會連線到無伺服器 SQL 集區，並使用資料來支援其他商務作業需求。
- Azure Pipelines 會執行 CI/CD 程式，以自動建置、測試及部署解決方案。 其設計目的是在部署程式期間將人為介入降至最低。
元件
以下是此 Data Lakehouse 解決方案中的重要元件：
- Azure Synapse
- Azure 檔案
- 事件中樞
- Blob 儲存體
- Azure Data Lake 儲存體
- Azure DevOps
- Power BI
- Data Factory
- Azure Bastion
- Azure 監視器
- 適用於雲端的 Microsoft Defender
- Azure Key Vault
替代項目
- 如果您需要即時資料處理，您可以不將個別檔案儲存在資料登陸區域，而是使用 Apache 結構化串流從事件中樞接收資料流程並加以處理。
- 如果資料具有複雜的結構，而且需要複雜的 SQL 查詢，請考慮將它儲存在專用 SQL 集區中，而不是無伺服器 SQL 集區。
- 如果資料包含許多階層式資料結構，例如，它有大型 JSON 結構，您可能會想要將它儲存在 Azure Synapse 資料總管中。
案例詳細資料
Azure Synapse Analytics 是一個多功能的資料平臺，可支援企業資料倉儲、即時資料分析、管線、時間序列資料處理、機器學習和資料控管。 為了支援這些功能，它會整合數種不同的技術，例如：
- 企業資料倉儲
- 無伺服器 SQL 集區
- Apache Spark
- 管線
- 資料總管
- 機器學習功能
- Purview 整合資料控管
這些功能會開啟許多可能性，但有許多技術選擇可安全地設定基礎結構以供安全使用。
本文說明使用 Azure Synapse 建置安全 Data Lakehouse 解決方案的設計程式、原則和技術選擇。 我們著重于安全性考慮和關鍵技術決策。 此解決方案會使用這些 Azure 服務：
- Azure Synapse
- Azure Synapse 無伺服器 SQL 集區
- Azure Synapse Analytics 中的 Apache Spark
- Azure Synapse 管線
- Azure Data Lake
- Azure DevOps。
目標是提供建立安全且符合成本效益的 Data Lakehouse 平臺的指引，以供企業使用，並讓技術順暢且安全地合作。
潛在的使用案例
Data Lakehouse 是一種現代化資料管理架構，結合了資料湖的成本效益、規模和彈性功能，以及資料倉儲的資料與交易管理功能。 Data Lakehouse 可以處理大量資料，並支援商業智慧和機器學習案例。 它也可以處理來自各種資料結構和資料來源的資料。 如需詳細資訊，請參閱 什麼是 Databricks Lakehouse？ 。
以下所述解決方案的一些常見使用案例如下：
- 物聯網（IoT） 遙測分析
- 智慧工廠自動化（用於製造）
- 追蹤消費者活動和行為（適用于零售）
- 管理安全性事件和事件
- 監視應用程式記錄和應用程式行為
- 半結構化資料的處理和商務分析
高階設計
此解決方案著重于架構中的安全性設計和實作做法。 無伺服器 SQL 集區、Azure Synapse 中的 Apache Spark、Azure Synapse 管線、Data Lake 儲存體和 Power BI 是用來實 作 Data Lakehouse 模式 的重要服務。
以下是高階解決方案設計架構：
選擇安全性焦點
我們已使用 威脅模型化工具 啟動安全性設計。 此工具協助我們：
- 與系統專案關係人溝通潛在風險。
- 定義系統中的信任界限。
根據威脅模型化結果，我們已將下列安全性領域設為我們的首要任務：
- 身分識別和存取控制
- 網路保護
- DevOps 安全性
我們設計了安全性功能和基礎結構變更，藉由降低使用這些最高優先順序識別的主要安全性風險來保護系統。
如需應檢查和考慮哪些專案的詳細資訊，請參閱：
網路和資產保護計劃
雲端採用架構中的主要安全性原則之一是 零信任原則 ：設計任何元件或系統的安全性時，假設組織中其他資源遭到入侵，以降低攻擊者擴大其存取的風險。
根據威脅模型化結果，解決方案會 採用零信任中的微分割部署 建議，並定義數 個安全性界限 。 Azure 虛擬網絡 和 Azure Synapse 資料外泄保護 是用來實作安全性界限的重要技術，以保護資料資產和重要元件。
由於 Azure Synapse 是由數種不同的技術所組成，因此我們需要：
識別專案中所使用的 Synapse 和相關服務的元件。
Azure Synapse 是一個多功能的資料平臺，可處理許多不同的資料處理需求。 首先，我們需要決定專案中使用哪些 Azure Synapse 元件，以便規劃如何保護它們。 我們也需要判斷哪些其他服務會與這些 Azure Synapse 元件通訊。
在 Data Lakehouse 架構中，主要元件包括：
- Azure Synapse 無伺服器 SQL
- Azure Synapse 中的 Apache Spark
- Azure Synapse 管線
- Data Lake Storage
- Azure DevOps
定義元件 之間的法律通訊行為。
我們需要定義元件之間的允許通訊行為。 例如，我們希望 Spark 引擎直接與專用 SQL 實例通訊，還是想要透過 Azure Synapse 資料整合 管線或 Data Lake 儲存體 等 Proxy 進行通訊？
根據零信任原則，如果沒有商務需要互動，我們會封鎖通訊。 例如，我們會封鎖位於未知租使用者的 Spark 引擎，而無法直接與 Data Lake 儲存體通訊。
選擇適當的安全性解決方案，以強制執行定義的通訊行為 。
在 Azure 中，數種安全性技術可以強制執行定義的服務通訊行為。 例如，在 Data Lake 儲存體您可以使用 IP 位址允許清單來控制對 Data Lake 的存取，但您也可以選擇允許哪些虛擬網路、Azure 服務和資源實例。 每個保護方法都提供不同的安全性保護。 根據業務需求和環境限制選擇。 下一節將說明此解決方案中使用的組態。
針對重要資源 實作威脅偵測和進階防禦。
對於重要資源，最好實作威脅偵測和進階防禦。 服務可協助識別威脅和觸發警示，讓系統可以通知使用者安全性缺口。
請考慮下列技術，以更妥善地保護網路和資產：
部署周邊網路以提供資料管線的安全性區域
當資料管線工作負載需要存取外部資料和資料登陸區域時，最好實作周邊網路，並使用擷取、轉換和載入 （ETL） 管線加以區隔。
為所有儲存體帳戶啟用適用於雲端的 Defender
適用於雲端的 Defender偵測到存取或惡意探索儲存體帳戶時，會觸發安全性警示。 如需詳細資訊，請參閱 設定適用于 儲存體 的 Microsoft Defender。
鎖定儲存體帳戶以防止惡意刪除或設定變更
如需詳細資訊，請參閱 將 Azure Resource Manager 鎖定套用至儲存體帳戶 。
具有網路和資產保護的架構
下表描述為此解決方案選擇的已定義通訊行為和安全性技術。 這些選擇是以網路和資產保護計劃中 討論 的方法為基礎。
| 來自 （用戶端） | 至 （服務） | 行為 | 組態 | 備註 | |
|---|---|---|---|---|---|
| 網際網路 | Data Lake Storage | 全部拒絕 | 防火牆規則 - 預設拒絕 | 預設值：'Deny' | 防火牆規則 - 預設拒絕 |
| Azure Synapse Pipeline/Spark | Data Lake Storage | 允許 （實例） | 虛擬網路 - 受控私人端點 （Data Lake 儲存體） | ||
| Synapse SQL | Data Lake Storage | 允許 （實例） | 防火牆規則 - 資源實例 （Synapse SQL） | Synapse SQL 必須使用受控識別來存取 Data Lake 儲存體 | |
| Azure Pipelines 代理程式 | Data Lake Storage | 允許 （實例） | 防火牆規則 - 選取的虛擬網路 服務端點 - 儲存體 |
用於整合測試 略過：'AzureServices' （防火牆規則） |
|
| 網際網路 | Synapse 工作區 | 全部拒絕 | 防火牆規則 | ||
| Azure Pipelines 代理程式 | Synapse 工作區 | 允許 （實例） | 虛擬網路 - 私人端點 | 需要三個私人端點（Dev、無伺服器 SQL 和專用 SQL） | |
| Synapse 受控虛擬網路 | 網際網路或未經授權的 Azure 租使用者 | 全部拒絕 | 虛擬網路 - Synapse 資料外泄保護 | ||
| Synapse 管線/Spark | Key Vault | 允許 （實例） | 虛擬網路 - 受控私人端點 （金鑰保存庫） | 預設值：'Deny' | |
| Azure Pipelines 代理程式 | Key Vault | 允許 （實例） | 防火牆規則 - 選取的虛擬網路 * 服務端點 - 金鑰保存庫 |
略過：'AzureServices' （防火牆規則） | |
| Azure Functions | Synapse 無伺服器 SQL | 允許 （實例） | 虛擬網路 - 私人端點 （Synapse 無伺服器 SQL） | ||
| Synapse 管線/Spark | Azure 監視器 | 允許 （實例） | 虛擬網路 - 私人端點 （Azure 監視器） |
例如，在計畫中，我們想要：
- 使用受控虛擬網路建立 Azure Synapse 工作區。
- 使用 Azure Synapse 工作區資料外泄保護，保護來自 Azure Synapse 工作區的資料輸出。
- 管理 Azure Synapse 工作區的已核准 Microsoft Entra 租使用者清單。
- 設定網路規則，以將來自所選虛擬網路儲存體帳戶的流量授與流量、僅存取和停用公用網路存取。
- 使用 受控私人端點 將 Azure Synapse 管理的虛擬網路連線到 Data Lake。
- 使用 資源實例 安全地將 Azure Synapse SQL 連線到 Data Lake。
考量
這些考慮會實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可用來改善工作負載的品質。 如需詳細資訊，請參閱 Microsoft Azure Well-Architected Framework 。
安全性
如需妥善架構架構架構之安全性要素的資訊，請參閱 安全性 。
身分識別與存取控制
系統中有數個元件。 每個都需要不同的身分識別和存取管理 （IAM） 組態。 這些設定需要共同作業以提供簡化的使用者體驗。 因此，當我們實作身分識別和存取控制時，我們會使用下列設計指導方針。
為不同的存取控制層選擇身分識別解決方案
- 系統中有四個不同的身分識別解決方案。
- SQL 帳戶 （SQL Server）
- 服務主體 （Microsoft Entra ID）
- 受控識別 （Microsoft Entra ID）
- 使用者帳戶 （Microsoft Entra ID）
- 系統中有四個不同的存取控制層。
- 應用程式存取層：選擇 AP 角色的身分識別解決方案。
- Azure Synapse DB/資料表存取層：選擇資料庫中角色的身分識別解決方案。
- Azure Synapse 存取外部資源層：選擇身分識別解決方案來存取外部資源。
- Data Lake 儲存體存取層：選擇身分識別解決方案來控制儲存體中的檔案存取。
身分識別和存取控制的關鍵區段是為每個存取控制層選擇正確的身分識別解決方案。 Azure 架構完善的架構安全性設計原則 建議使用原生控制項並推動簡單。 因此，此解決方案會使用應用程式和 Azure Synapse DB 存取層中終端使用者的 Microsoft Entra 使用者帳戶。 它會利用原生第一方 IAM 解決方案，並提供更細緻的存取控制。 Azure Synapse 存取外部資源層和 Data Lake 存取層會使用 Azure Synapse 中的受控識別來簡化授權程式。
- 系統中有四個不同的身分識別解決方案。
考慮最低許可權存取
零信任指導原則建議提供對重要資源的 Just-In-Time 和 Just-enough 存取權。 請參閱 Microsoft Entra Privileged Identity Management （PIM）， 以在未來增強安全性。
保護連結服務
連結服務會定義服務連線至外部資源所需的連接資訊。 請務必保護連結的服務組態。
安全性分數評估與威脅偵測
為了瞭解系統的安全性狀態，解決方案會使用適用於雲端的 Microsoft Defender來評估基礎結構安全性並偵測安全性問題。 適用於雲端的 Microsoft Defender 是管理安全性態勢和防護威脅的工具。 它可以保護在 Azure、混合式和其他雲端平臺中執行的工作負載。
當您第一次流覽Azure 入口網站中的適用於雲端的 Defender頁面時，會自動在所有 Azure 訂用帳戶上啟用適用於雲端的 Defender的免費方案。 強烈建議您啟用它，以取得雲端安全性狀態評估和建議。 適用於雲端的 Microsoft Defender會為您的訂用帳戶提供安全性分數和一些安全性強化指引。
如果解決方案需要進階安全性管理和威脅偵測功能，例如偵測和警示可疑活動，您可以針對不同的資源個別啟用雲端工作負載保護。
成本最佳化
如需妥善架構架構之成本優化要素的資訊，請參閱 成本優化 。
Data Lakehouse 解決方案的主要優點是其成本效益和可調整的架構。 解決方案中的大部分元件都會使用以耗用量為基礎的計費，而且會自動調整。 在此解決方案中，所有資料都會儲存在 Data Lake 儲存體中。 如果您未執行任何查詢或處理資料，則只會支付儲存資料的費用。
此解決方案的定價取決於下列重要資源的使用量：
- Azure Synapse 無伺服器 SQL：使用以使用量為基礎的計費，只需支付您使用的費用。
- Azure Synapse 中的 Apache Spark：使用以使用量為基礎的計費，只需支付您使用的費用。
- Azure Synapse Pipelines：使用以使用量為基礎的計費，只需支付您使用的專案。
- Azure Data Lake：使用以使用量為基礎的計費，只需支付您使用的費用。
- Power BI：成本取決於您購買的授權。
- Private Link：使用以使用量為基礎的計費，只需支付您使用的費用。
不同的安全性保護解決方案有不同的成本模式。 您應該根據業務需求和解決方案成本選擇安全性解決方案。
您可以使用 Azure 定價計算機 來預估解決方案的成本。
卓越營運
如需妥善架構架構之營運卓越支柱的資訊，請參閱 卓越營運 。
針對 CI/CD 服務使用已啟用虛擬網路的自我裝載管線代理程式
預設的 Azure DevOps 管線代理程式不支援虛擬網路通訊，因為它使用非常廣泛的 IP 位址範圍。 此解決方案會在虛擬網路中實作 Azure DevOps 自我裝載代理程式 ，讓 DevOps 程式可以順暢地與解決方案中的其他服務通訊。 執行 CI/CD 服務的連接字串和秘密會儲存在獨立的金鑰保存庫中。 在部署程式期間，自我裝載代理程式會存取核心資料區域中的金鑰保存庫，以更新資源組態和秘密。 如需詳細資訊，請參閱 使用個別的金鑰保存庫 檔。 此解決方案也會使用 VM 擴展集 來確保 DevOps 引擎可以根據工作負載自動相應增加和減少。
在 CI/CD 管線中實作基礎結構安全性掃描和安全性煙霧測試
用於掃描基礎結構即程式碼 （IaC） 檔案的靜態分析工具可協助偵測並防止設定錯誤，進而造成安全性或合規性問題。 安全性煙霧測試可確保成功啟用重要的系統安全性措施，以防止部署失敗。
- 使用靜態分析工具掃描基礎結構即程式碼 （IaC） 範本，以偵測並防止可能導致安全性或合規性問題的設定錯誤。 使用 Checkov 或 Terrascan 之類的 工具來偵測並防止安全性風險。
- 請確定 CD 管線已正確處理部署失敗。 與安全性功能相關的任何部署失敗都應該視為重大失敗。 管線應該重試失敗的動作，或保留部署。
- 執行安全性煙霧測試，以驗證部署管線中的安全性措施。 安全性煙霧測試，例如驗證已部署資源的設定狀態，或檢查重要安全性案例的測試案例，可以確保安全性設計如預期般運作。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- 赫曼·吳 |資深軟體工程師
其他投稿人：
- Ian Chen |首席軟體工程師主管
- Jose Contreras |主要軟體工程
- Roy Chan |主要軟體工程師管理員
下一步
- Azure 產品檔
- 其他文章
- 什麼是 Azure Synapse Analytics？
- Azure Synapse Analytics 中的無伺服器 SQL 集區
- Azure Synapse Analytics 中的 Apache Spark
- Azure Data Factory 和 Azure Synapse Analytics 中的管線及活動
- 什麼是 Azure Synapse 資料總管？ (預覽)
- Azure Synapse Analytics 中的機器學習功能
- Microsoft Purview 是什麼？
- Azure Synapse Analytics 和 Azure Purview 共同運作
- Azure Data Lake Storage Gen2 簡介
- 什麼是 Azure Data Factory？
- 目前的資料模式部落格系列：Data Lakehouse
- 什麼是適用於雲端的 Microsoft Defender？
- Data Lakehouse、資料倉儲和新式資料平臺架構
- 組織 Azure Synapse 工作區和 Lakehouse 的最佳做法
- 瞭解 Azure Synapse 私人端點
- Azure Synapse Analytics – 資料安全性的新深入解析
- 適用于 Azure Synapse 專用 SQL 集區的 Azure 安全性基準（先前稱為 SQL DW）
- 雲端網路安全性 101：Azure 服務端點與私人端點
- 如何設定 Azure Synapse 工作區的存取控制
- 使用 Azure Private Link 中樞連線至 Azure Synapse Studio
- 如何將 Azure Synapse 工作區成品部署至受控虛擬網路 Azure Synapse 工作區
- Azure Synapse Analytics 工作區的持續整合和傳遞
- 適用於雲端的 Microsoft Defender 中的安全分數
- 使用 Azure Key Vault 的最佳做法
- Azure 中資料管理和分析的 Adatum Corporation 案例