Azure 中的雲端規模分析授權
授權是授與已驗證者執行動作許可權的動作。 訪問控制 的主要原則是只授與用戶執行工作所需的存取量，以及只允許特定範圍的特定動作。 角色型安全性對應於存取控制。 許多組織會使用角色型安全性，根據已定義的角色或作業功能來控制存取，而不是個別使用者。 用戶獲指派一或多個安全性角色，而且每個角色都會獲得授權許可權來執行特定工作。
Microsoft Entra ID 是集中式識別提供者，可授與授權，以根據 Microsoft Entra 身分識別，存取每個使用者或每個應用程式的數據服務和記憶體。
數據服務授權
Azure 角色型存取控制 （RBAC） 和存取控制清單 （ACL） 在管理存取和確保安全性方面扮演重要角色。 Azure RBAC 和 ACL 都需要使用者或應用程式在 Microsoft Entra ID 中具有身分識別。 在雲端規模分析中，RBAC 適用於資料庫和 Azure Data Lake Storage。 ACL 主要用於 Data Lake Storage，以在檔案和目錄層級提供更細緻的訪問控制。 ACL 藉由在記憶體階層中提供更詳細的許可權來補充 RBAC。
Azure RBAC 提供內建角色，例如 擁有者、參與者和 讀者，但您也可以針對特定需求建立自定義角色。 下列內建角色是所有 Azure 資源類型的基礎，包括 Azure 數據服務：
| 角色 | 描述 |
|---|---|
| 擁有者 | 此角色具有資源的完整存取權，並可管理資源的所有事宜，包括授予他人存取權的權限。 |
| 參與者 | 此角色可以管理資源，但無法授與資源的存取權。 |
| 讀者 | 此角色可以檢視資源與資訊，但不包括例如存取金鑰或秘密等敏感性資訊，關於此資源。 它們無法對資源進行任何變更。 |
注意
某些服務具有特定的 RBAC 角色，例如 記憶體 Blob 數據參與者 或 Data Factory 參與者，因此您應該將這些角色用於這些服務。 RBAC 是一種加法模型，其中添加角色指派是一個有效的許可權。 RBAC 也支援 優先於 角色 指派的拒絕 指派。
提示
當您規劃訪問控制策略時，建議您只授與使用者執行其工作所需的存取量。 您也應該只允許特定範圍內的特定動作。
Azure 資料庫中的訪問控制
Azure 資料庫中的 RBAC 圍繞角色、範圍和許可權。 Azure 提供數個用於資料庫管理的內建角色。 其中一個角色是 SQL Server 貢獻者，這可讓您管理 SQL Server 和資料庫。 另一個角色是 SQL DB 參與者，它允許管理 SQL 資料庫，但不能管理伺服器本身。 此外，您可以建立具有特定許可權的自定義角色，以符合唯一需求。
您可以在不同的範圍指派角色，包括：
- 在訂用帳戶層級，角色會套用至訂用帳戶內的所有資源。
- 在資源群組層級，角色會套用至指定資源群組內的所有資源。
- 在資源層級，您可以直接將角色指派給個別資料庫或伺服器。 此方法可讓您精確控制。
許可權會定義角色可執行的動作，例如讀取、寫入、刪除或安全性設定管理。 這些許可權會分組為角色，以簡化管理。
在 Azure SQL Database中，您可以將角色指派給使用者、群組或應用程式，以控制存取權。 例如，資料庫管理員可能會獲指派 SQL Server 參與者 角色來管理伺服器和資料庫。 SQL DB 參與者 等角色可讓使用者建立、更新和刪除資料庫，而 SQL 安全性管理員 角色則著重於安全性設定。
在 Azure Cosmos DB中，您可以指派角色來管理 Azure Cosmos DB 帳戶、資料庫和容器的存取權。 Cosmos DB 帳戶讀取者 和 Cosmos DB 帳戶參與者等內建角色 提供不同層級的存取權。
在 適用於 MySQL 的 Azure 資料庫、適用於 PostgreSQL 的 Azure 資料庫，以及 適用於 MariaDB 的 Azure 資料庫，您可以指派角色來管理資料庫伺服器和個別資料庫。 您可以使用 參與者 和 讀者 等角色來控制存取。
如需詳細資訊，請參閱 適用於資料庫的 Azure 內建角色。
Data Lake Storage 中的訪問控制
Azure RBAC 可讓您將所有記憶體帳戶數據授與粗略存取權，例如讀取或寫入存取權。 ACL 可讓您授與更細緻的存取權，例如特定目錄或檔案的寫入許可權。
在許多情況下，您可以使用 RBAC 和 ACL 在 Data Lake Storage 中提供完整的存取控制。 您可以使用 RBAC 來管理數據的高階存取權，這有助於確保只有授權的使用者可以存取服務。 然後，您可以在記憶體帳戶內套用 ACL 來控制特定檔案和目錄的存取，進而改善安全性。
Azure 屬性型訪問控制建置在 Azure RBAC 上，方法是根據特定動作內容中的屬性新增角色指派條件。 它基本上可讓您藉由新增條件來精簡 RBAC 角色指派。 例如，您可以對儲存體帳戶中具有特定標籤的所有資料物件授與讀取和寫入權限。
下列角色允許安全性主體存取儲存體帳戶中的資料。
| 角色 | 描述 |
|---|---|
| 儲存體 Blob 資料擁有者 | 此角色提供 Blob 記憶體容器和數據的完整存取權。 此存取權限允許安全性主體設定項目的擁有者，並修改所有項目的 ACL。 |
| 記憶體 Blob 數據參與者 | 此角色提供對 Blob 儲存容器及 Blob 的讀取、寫入和刪除存取權限。 此存取不允許安全性主體設定項目的擁有權，但可以修改安全性主體擁有之專案的 ACL。 |
| 儲存體 Blob 資料讀取器 | 此角色可以讀取及列出 Blob 儲存體的容器和物件。 |
擁有者、參與者、讀取者和 儲存器帳戶參與者等角色 允許安全性主體管理記憶體帳戶，但不會提供該帳戶內數據的存取權。 不過，除了 讀取器之外，這些角色可以取得記憶體密鑰的存取權，這可用於各種用戶端工具來存取數據。 如需詳細資訊，請參閱 Data Lake Storage中的
Azure Databricks 中的訪問控制
Azure Databricks 提供訪問控制系統來管理 Azure Databricks 環境中的存取。 這些系統著重於可被保護的對象和資料治理。 Azure Databricks 內的三個主要存取控制系統如下：
- ACL，您可以用來設定許可權來存取工作區物件，例如筆記本。 如需詳細資訊，請參閱 訪問控制概觀。
- 帳戶 RBAC，您可以用來設定許可權以使用帳戶層級物件，例如服務主體和群組。
- Unity 目錄，可用來保護及控管數據物件。
除了對象的訪問控制之外，Azure Databricks 還提供平臺上的內建角色。 您可以將角色指派給用戶、服務主體和群組。 如需詳細資訊，請參閱 系統管理員角色和工作區權利。
雲端規模分析中授權的最佳做法
本指南討論在雲端規模分析環境中實作 RBAC 的最佳做法。 其中包含一般 RBAC 準則、資料庫訪問控制和 Data Lake 訪問控制最佳做法，以協助確保安全且有效率的資源管理。
雲端規模分析中一般的 RBAC 最佳做法
下列最佳做法可協助您開始使用 RBAC：
使用 RBAC 角色進行服務管理和作業，並使用服務特定角色進行數據存取和工作負載特定工作。 在 Azure 資源上使用 RBAC 角色，將許可權授與需要執行資源管理和作業工作的安全性主體。 需要存取儲存中資料的安全主體不需要在這個資源上擁有 RBAC 角色，因為他們不需要管理這個資源。 相反地，將許可權直接授與數據物件。 例如，授予 Data Lake Storage 中資料夾的讀取權限，或在 SQL Database 中為內含使用者和資料表授予權限。
使用內建的 RBAC 角色。 首先，使用內建的 RBAC Azure 資源角色來管理服務，並指派作業角色來控制存取。 只有在內建角色不符合您的特定需求時，才建立及使用 Azure 資源的自定義角色。
使用群組來管理存取權。 將存取權指派給 Microsoft Entra 群組，並管理群組成員資格以持續進行存取管理。
請考慮訂用帳戶和資源群組範圍。 在非生產環境中，將資源群組範圍的存取權授與個別服務管理和作業存取需求，而不是授與個別資源的存取權。 這種方法很合理，因為在非生產環境中，開發人員和測試人員需要管理資源。 例如，他們可能需要在 Data Lake Storage 中建立 Azure Data Factory 擷取管線或容器。
不過，在生產環境中，您可以為針對特定工作負載的任務授予個別資源的存取權，例如資料湖檔案系統的支援和操作。 這種方法在生產環境中很合理，因為使用者只需要使用資源，例如檢視排程 Data Factory 擷取管線的狀態，或在 Data Lake Storage 中讀取數據檔。
請勿在訂用帳戶範圍授與不必要的存取權。 訂用帳戶範圍涵蓋訂用帳戶內的所有資源。
選擇最低許可權存取。 請選擇適合該職務的唯一角色。
資料庫訪問控制最佳做法
實作有效的 RBAC 對於維護分析環境中的安全性和管理性至關重要。 本節提供使用 Microsoft Entra 群組和內建角色的最佳做法，並避免使用直接的使用者權限，以協助確保流暢且安全的存取管理流程。
雲端規模分析環境通常包含多種記憶體解決方案類型，包括 PostgreSQL、MySQL、SQL Database、Azure SQL 受控實例和 Azure Synapse Analytics。
使用 Microsoft Entra 群組，而不是個別用戶帳戶。 建議您使用 Microsoft Entra 群組來保護資料庫物件，而不是個別Microsoft Entra 用戶帳戶。 使用 Microsoft Entra 群組來驗證用戶並保護資料庫物件。 與 Data Lake 模式類似，您可以使用資料應用程式上線來建立這些群組。
使用內建角色來管理存取權。 只有在您需要符合特定需求或內建角色授與太多許可權時，才建立自定義角色。
避免將許可權指派給個別使用者。 建議一致性地使用角色，例如資料庫角色或伺服器角色。 角色可協助報告和排除許可權問題。 Azure RBAC 僅支援透過角色的許可權指派。
注意
數據應用程式可以將敏感數據產品儲存在 SQL Database、SQL 受控實例或 Azure Synapse Analytics 集區中。 如需詳細資訊，請參閱在 Azure 中雲端規模分析的數據隱私權。
Data Lake Storage 訪問控制最佳做法
在現代數據環境中，安全且有效率的訪問控制是最重要的。 Data Lake Storage 提供強固的機制，可透過 ACL 管理存取。 本節概述在 Data Lake Storage 中實作 RBAC 並套用 ACL、Microsoft Entra 安全組，以及維護更安全且可管理 Data Lake 環境的最小許可權原則的最佳做法。 此外，它強調將 ACL 與數據分割配置對齊的重要性，以及使用適用於 Azure Databricks 使用者的 Unity 目錄，協助確保完整的安全性和治理。
使用 ACL 進行更細緻的訪問控制。 ACL 在定義細微層級的存取時扮演著重要角色。 在 Data Lake Storage 中，ACL 會與安全性主體合作，以管理對檔案和目錄的精細存取。
在檔案和資料夾層級套用 ACL。 若要控制數據湖中的數據存取，建議您在檔案和資料夾層級使用 ACL。 Data Lake Storage 也採用類似於可攜式作系統介面 （POSIX） 的 ACL 模型。 POSIX 是一組作業系統的標準。 一個標準會定義簡單但功能強大的許可權結構，以存取檔案和資料夾。 POSIX 通常用於網路檔案共用和 Unix 電腦。
使用 Microsoft Entra 安全群組作為 ACL 項目中指派的主體。 不使用直接指派個別用戶或服務主體，請使用此方法來新增和移除使用者或服務主體，而不需要將 ACL 重新套用至整個目錄結構。 您只要從適當的Microsoft Entra 安全組新增或移除用戶和服務主體。
將存取權指派給 Microsoft Entra 群組，並管理群組的成員資格以進行進行中的存取管理。 如需詳細資訊，請參閱 Data Lake Storage中的
訪問控制模型。 將最小權限原則套用至存取控制列表 (ACL)。 在大部分情況下，用戶應該僅能擁有 讀取 在數據湖中所需的檔案和資料夾的許可權。 數據使用者不應該具有記憶體帳戶容器的存取權。
將 ACL 與數據分割配置對齊。 ACL 和數據分割設計必須一致，以確保有效的數據訪問控制。 如需詳細資訊，請參閱 資料湖分割。
對於 Azure Databricks 使用者，請以 Unity 目錄獨佔方式控制對數據物件的存取。 授與 Data Lake Storage 中外部位置記憶體的直接儲存層級存取權，並不接受 Unity 目錄所維護的任何許可權或稽核。 直接存取會略過 Unity 目錄的稽核、譜系和其他安全性和監視功能，包括訪問控制和許可權。 因此，您不應該為 Azure Databricks 使用者提供 Unity 目錄受控數據表和磁碟區的直接記憶體層級存取權。