身分識別和存取管理
本文將探討身分識別和存取管理的設計考慮和建議。 它專注於在 Microsoft Azure 上部署雲端規模的分析平台。 由於雲端規模分析是任務關鍵元素,因此 Azure 登陸區域設計區域的指引也應該包含在您的設計中。
本文基於對 Azure 登陸區域的考量與建議。 如需詳細資訊,請參閱 身分識別與存取管理。
數據登陸區域設計
雲端規模分析支援使用Microsoft Entra 身分識別的訪問控制模型。 此模型同時使用 Azure 角色型存取控制 (Azure RBAC) 和存取控制清單 (ACL)。
檢閱您的小組執行的 Azure 管理和管理活動。 請考慮 Azure 上的雲端規模分析。 判斷組織內最可能的責任分佈。
角色指派
為了在數據平臺內自主開發、傳遞及提供數據產品,數據應用程式小組在 Azure 環境中需要少數訪問許可權。 在討論個別的 RBAC 需求之前,請務必強調應該將不同的存取模型用於開發和更高環境。 此外,應盡可能使用安全組來減少角色指派的數目,並簡化 RBAC 許可權的管理與檢閱程式。 此步驟非常重要,因為 每個訂用帳戶可以建立的角色指派數目有限,。
開發環境應該可供開發小組及其各自的使用者身分識別存取。 此存取可讓他們更快速地反覆運算、瞭解 Azure 服務內的某些功能,以及有效地針對問題進行疑難解答。 存取開發環境有助於開發或增強基礎架構即程式碼 (IaC) 與其他程式碼工件。 在開發環境內的實作如預期般運作之後,就可以持續推出至較高的環境。 對於數據應用程式小組,較高等級的環境,例如測試和生產環境,應加以限制。 只有服務主體可以存取這些環境,因此所有部署都必須使用 CI/CD 管線透過服務主體身分識別來執行。 總結來說,在開發環境訪問許可權中,應該提供給服務主體和使用者身分識別,而較高環境中的訪問許可權應該只提供給服務主體身分識別。
若要能夠在數據應用程式資源群組內的資源之間建立資源和角色指派,必須提供 Contributor
和 User Access Administrator
許可權。 這些許可權可讓小組在 Azure 原則的 Network Contributor
角色指派(子資源範圍)。 此角色指派可讓小組使用私人端點加入子網。
這兩項首次角色指派可在這些環境中啟用自助式的數據服務部署。 為了解決成本管理問題,組織應將成本中心標籤新增至資源群組,以啟用交叉收費和分散式成本擁有權。 這可以提高團隊的意識,並促使他們在必要的 SKU 和服務層級方面做出正確的決策。
若要在數據登陸區域內啟用對其他共用資源的自助式使用,則需要少數額外的角色指派。 如果需要存取 Databricks 環境,組織應該使用 Microsoft Entra ID 的 Can Restart
預先定義的叢集訪問許可權,才能在工作區內執行工作負載。
個別小組需要存取Microsoft Purview 帳戶,以探索個別數據登陸區域內的數據資產。 此外,在大多數情況下,小組會需要編輯他們擁有的已編目數據資產,以提供更多細節,比如數據擁有者和專家的聯絡詳細信息,以及更細緻的細節,說明資料集中的列描述了什麼以及包含了哪些資訊。
角色型訪問控制需求的摘要
針對部署數據登陸區域的自動化用途,您需要下列角色:
角色名稱
描述
範圍
將所有數據服務的所有私人 DNS 區域部署到單一訂用帳戶和資源群組。 服務主體必須在建立於數據管理登陸區域部署期間的全域 DNS 資源群組 Private DNS Zone Contributor
上。 要部署私有端點的 A 記錄,需要此角色。
(資源群組範圍) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
為了設定數據登陸區域網路與數據管理登陸區域網路之間的虛擬網路對等互連,服務主體需要在遠端虛擬網路的資源群組上 Network Contributor
訪問許可權。
(資源群組範圍) /subscriptions/{{dataManagement}subscriptionId}/resourceGroups/{resourceGroupName}
需要此許可權,才能與其他資料工廠共用佈建到 integration-rg
資源群組的自我託管整合執行個體。 也需要在各自的存儲帳戶文件系統上指派 Azure Data Factory 和 Azure Synapse Analytics 受控識別的存取權限。
(資源範圍) /subscriptions/{{dataLandingZone}subscriptionId}
注意
在生產情境中,可以減少角色指派的數量。
Network Contributor
角色分配僅需用於在數據管理登陸區域與數據登陸區域之間設定虛擬網路對等連接。 若未考慮此考慮,DNS 解析將無法運作。 因為 Azure 防火牆沒有可見線,因此會捨棄輸入和輸出流量。
如果透過具有 deployIfNotExists
效果的 Azure 原則自動化私人端點的 DNS A 記錄部署,則 Private DNS Zone Contributor
也是不必要的。
User Access Administrator
也是如此,因為部署可以使用 deployIfNotExists
原則來自動化。
數據產品的角色指派
在數據登陸區域內部署數據產品需要下列角色指派:
角色名稱
描述
範圍
將所有數據服務的所有私人 DNS 區域部署到單一訂用帳戶和資源群組。 服務主體需要設置為 Private DNS Zone Contributor
,於數據管理著陸區域部署期間所建立的全域 DNS 資源群組上。 需要此角色才能為各自的私人端點部署 A 記錄。
(資源群組範圍) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
將所有數據整合串流服務部署到數據登陸區域訂用帳戶內的單一資源群組。 服務主體需要在該資源群組上具有 Contributor
角色指派。
(資源群組範圍) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}
為了將私人端點部署到在數據登陸區域部署期間建立的指定 Private Link 子網,服務主體需要 Network Contributor
該子網的存取權。
(子資源範圍) /subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName} /providers/Microsoft.Network/virtualNetworks/{virtualNetworkName}/subnets/{subnetName}"
存取其他資源
在 Azure 外部,資料應用程式小組也需要存取存放庫來儲存程式代碼成品、有效地共同作業,以及透過 CI/CD 持續推出更新和變更至較高環境。 此外,應該提供專案面板,以允許敏捷式開發、短期衝刺規劃、追蹤工作,以及使用者意見反應和功能要求。
最後,CI/CD 自動化需要設定與 Azure 的連線,大部分服務是透過服務主體來完成此設定的。 因此,小組需要存取服務原則,才能在其專案中實現自動化。
管理數據的存取權
應該使用 Microsoft Entra 群組來管理數據的存取權。 將用戶主體名稱或服務主體名稱新增至 Microsoft Entra 群組。 將群組新增至服務,並將許可權授與群組。 此方法允許更細緻的訪問控制。
如需有關如何增強數據管理登陸區域和管理數據資產的數據登陸區域的安全性之詳細資訊,請參閱 Azure 中用於雲端規模分析的 驗證。