Azure Data Lake Storage 中的存取控制模型
Data Lake Storage 支援下列授權機制：
- 共用金鑰授權
- 共用存取簽章 (SAS) 授權
- 角色型存取控制 (Azure RBAC)
- 屬性型存取控制 (Azure ABAC)
- 存取控制清單 (ACL)
共用密鑰、帳戶 SAS 和服務 SAS 授權會授與使用者（或應用程式）的存取權，而不需要他們在Microsoft Entra 識別碼中具有身分識別。 透過這些形式的驗證，Azure RBAC、Azure ABAC 和 ACL 沒有任何作用。 ACL 可以套用至使用者委派的 SAS 令牌，因為這些令牌會受到 Microsoft Entra 認證保護。 請參閱 共用金鑰和 SAS 授權。
Azure RBAC 和 ACL 兩者都需要使用者 (或應用程式) 在 Microsoft Entra ID 中具有身分識別。 Azure RBAC 可讓您授與對儲存體帳戶資料的「粗略」存取權，例如儲存體帳戶中所有資料的讀取或寫入存取權。 Azure ABAC 可讓您藉由新增條件來精簡 RBAC 角色指派。 例如，您可以對儲存體帳戶中具有特定標籤的所有資料物件授與讀取和寫入權限。 ACL 則可讓您授與「精細」的存取權，例如特定目錄或檔案的寫入存取權。
本文著重於 Azure RBAC、ABAC 和 ACL，以及系統如何將其一起評估，以做出儲存體帳戶資源的授權決策。
角色型存取控制 (Azure RBAC)
Azure RBAC 會使用角色指派將權限套用至安全性主體。 安全性主體是一個物件，代表在 Microsoft Entra ID 中定義的使用者、群組、服務主體或受控識別。 權限集合可以為安全性主體提供「粗略」層級的存取權，例如儲存體帳戶中的所有資料或容器中所有資料的讀取或寫入存取權。
下列角色允許安全性主體存取儲存體帳戶中的資料。
| 角色 | 描述 |
|---|---|
| 儲存體 Blob 資料擁有者 | 對 Blob 儲存體容器和資料的完整存取權。 此存取權可讓安全性主體設定項目的擁有者，以及修改所有項目的 ACL。 |
| 儲存體 Blob 資料參與者 | 對 Blob 儲存體容器和 Blob 的讀取、寫入和刪除存取權。 此存取權不允許安全性主體設定項目的擁有權，但可以修改安全性主體所擁有之項目的 ACL。 |
| 儲存體 Blob 資料讀者 | 讀取和列出 Blob 儲存體容器與 Blob。 |
擁有者、參與者、讀者和儲存體帳戶參與者等角色允許安全性主體管理儲存體帳戶，但不提供該帳戶內所含資料的存取權。 不過，這些角色 (讀者除外) 可取得儲存體金鑰的存取權；這些金鑰可在多種用戶端工具中用來存取資料。
屬性型存取控制 (Azure ABAC)
Azure ABAC 會根據特定動作內容中的屬性新增角色指派條件，以在 Azure RBAC 上建立。 角色指派條件是額外的檢查，您可以選擇性地將其新增至您的角色指派，以提供更精簡的存取控制。 您無法使用條件明確地拒絕存取特定資源。
如需使用 Azure ABAC 來控制 Azure 儲存體存取的詳細資訊，請參閱使用 Azure 角色指派條件來授權存取 Azure Blob 儲存體。
存取控制清單 (ACL)
ACL 可讓您將「精細」層級的存取權套用至目錄和檔案。 ACL 是一種權限結構，其中包含一系列的 ACL 項目。 每個 ACL 項目都會將安全性主體與存取層級產生關聯。 若要深入瞭解，請參閱 Azure Data Lake Storage 中的訪問控制清單（ACL）。
如何評估權限
在安全性主體型授權期間，會評估權限，如下圖所示。
- Azure 會判斷主體是否存在角色指派。
- 如果角色指派存在，接下來會評估角色指派條件 (2)。
- 如果不存在，接下來會評估 ACL (4)。
- Azure 會判斷是否有任何 ABAC 角色指派條件存在。
- 如果沒有任何條件存在，則會授與存取權。
- 如果條件存在，系統會評估這些條件，以查看其是否符合要求 (3)。
- Azure 會判斷所有 ABAC 角色指派條件是否符合要求的屬性。
- 如果全部符合，則會授與存取權。
- 如果其中至少有一個不符，則接下來會評估 ACL (4)。
- 如果在評估角色指派和條件之後並未明確授與存取權，則會評估 ACL。
- 如果 ACL 允許要求的存取層級，則會授與存取權。
- 如果不允許，則會拒絕存取。
重要
由於系統評估存取權限的方式，您無法使用 ACL 來限制角色指派及其條件已授與的存取權。 這是因為系統會先評估 Azure 角色指派及條件，如果指派授與了足夠的存取權限，就會忽略 ACL。
下圖顯示三項常見作業的權限流程：列出目錄內容、讀取檔案，以及寫入檔案。
權限資料表：結合 Azure RBAC、ABAC 和 ACL
下表說明如何結合 Azure 角色、條件和 ACL 項目，讓安全性主體可以執行 [作業] 資料行中所列的作業。 下表顯示代表虛構目錄階層各層級的資料行。 容器 (/) 的根目錄有一個資料行、有一個名為 Oregon 的子目錄、Oregon 目錄中有一個名為 Portland 的子目錄，Portland 目錄中有一個名為 Data.txt 的文字檔案。 這些資料行中顯示的是授與權限所需之 ACL 項目的簡短形式。 如果某個 ACL 項目並非執行作業所需的項目，則會在資料行中顯示為 N/A (不適用)。
| 作業 | 指派的 Azure 角色 (具有或沒有條件) | / | Oregon/ | Portland/ | Data.txt |
|---|---|---|---|---|---|
| Read Data.txt | 儲存體 Blob 資料擁有者 | N/A | N/A | N/A | N/A |
| 儲存體 Blob 資料參與者 | N/A | N/A | N/A | N/A | |
| 儲存體 Blob 資料讀者 | N/A | N/A | N/A | N/A | |
| 無 | --X |
--X |
--X |
R-- |
|
| Append to Data.txt | 儲存體 Blob 資料擁有者 | N/A | N/A | N/A | N/A |
| 儲存體 Blob 資料參與者 | N/A | N/A | N/A | N/A | |
| 儲存體 Blob 資料讀者 | --X |
--X |
--X |
-W- |
|
| 無 | --X |
--X |
--X |
RW- |
|
| Delete Data.txt | 儲存體 Blob 資料擁有者 | N/A | N/A | N/A | N/A |
| 儲存體 Blob 資料參與者 | N/A | N/A | N/A | N/A | |
| 儲存體 Blob 資料讀者 | --X |
--X |
-WX |
N/A | |
| None | --X |
--X |
-WX |
N/A | |
| 建立/更新Data.txt | 儲存體 Blob 資料擁有者 | N/A | N/A | N/A | N/A |
| 儲存體 Blob 資料參與者 | N/A | N/A | N/A | N/A | |
| 儲存體 Blob 資料讀者 | --X |
--X |
-WX |
N/A | |
| None | --X |
--X |
-WX |
N/A | |
| List / | 儲存體 Blob 資料擁有者 | N/A | N/A | N/A | N/A |
| 儲存體 Blob 資料參與者 | N/A | N/A | N/A | N/A | |
| 儲存體 Blob 資料讀者 | N/A | N/A | N/A | N/A | |
| None | R-X |
N/A | N/A | N/A | |
| List /Oregon/ | 儲存體 Blob 資料擁有者 | N/A | N/A | N/A | N/A |
| 儲存體 Blob 資料參與者 | N/A | N/A | N/A | N/A | |
| 儲存體 Blob 資料讀者 | N/A | N/A | N/A | N/A | |
| None | --X |
R-X |
N/A | N/A | |
| List /Oregon/Portland/ | 儲存體 Blob 資料擁有者 | N/A | N/A | N/A | N/A |
| 儲存體 Blob 資料參與者 | N/A | N/A | N/A | N/A | |
| 儲存體 Blob 資料讀者 | N/A | N/A | N/A | N/A | |
| None | --X |
--X |
R-X |
N/A |
注意
若要在 Azure 儲存體總管中檢視容器的內容，安全性主體必須使用 Microsoft Entra ID 登入儲存體總管，且 (至少) 須具備容器根資料夾 (\) 的讀取權限 (R--)。 此層級的權限可讓他們列出根資料夾的內容。 如果您不想要顯示根資料夾的內容，可以為其指派讀者角色。 使用該角色時，他們將可列出帳戶中的容器，但無法列出容器的內容。 然後，您可以使用 ACL 來授與特定目錄和檔案的存取權。
安全性群組
請一律使用 Microsoft Entra 安全性群組作為 ACL 項目中的指派主體。 抵制直接指派個別使用者或服務主體的機會。 使用此結構將可讓您新增和移除使用者或服務主體，而不需要將 ACL 重新套用至整個目錄結構。 相反地，您可以直接從適當的 Microsoft Entra 安全性群組新增或移除使用者和服務主體。
有許多不同方式可以設定群組。 例如，假設您有一個名為 /LogData 的目錄，該目錄會保存伺服器產生的記錄資料。 Azure Data Factory (ADF) 會將資料內嵌至該資料夾內。 服務工程小組的特定使用者會上傳記錄並管理此資料夾的其他使用者，而各種 Databricks 叢集會分析該資料夾中的記錄。
若要啟用這些活動，您可以建立 LogsWriter 群組和 LogsReader 群組。 然後，您可以依下述步驟指派權限：
- 將
LogsWriter群組新增至具有rwx權限的 /LogData 目錄的 ACL。 - 將
LogsReader群組新增至具有r-x權限的 /LogData 目錄的 ACL。 - 將服務主體物件或適用於 ADF 的受控服務識別 (MSI) 新增至
LogsWriters群組。 - 將服務工程團隊中的使用者新增至
LogsWriter群組。 - 將 Databricks 的服務主體物件或 MSI 新增至
LogsReader群組。
如果服務工程團隊中的使用者離開公司，您可以直接從群組中 LogsWriter 移除。 如果您未將該使用者新增至群組，而是為該使用者新增專用的 ACL 項目，則必須從 /LogData 目錄中移除該 ACL 項目。 您也必須從 /LogData 目錄的所有目錄階層中的所有子目錄和檔案中移除該項目。
若要建立群組並新增使用者，請參閱使用 Microsoft Entra ID 建立群組並新增成員。
重要
Azure Data Lake Storage Gen2 會依賴 Microsoft Entra ID 來管理安全性群組。 Microsoft Entra ID 建議您將指定安全性主體的群組成員資格限制為小於 200。 這項建議是因為 JSON Web 權杖 (JWT) 的限制，而 JWT 則是在 Microsoft Entra 應用程式中提供安全性主體的群組成員資格資訊。 超過此限制可能會導致 Data Lake Storage Gen2 發生非預期的效能問題。 若要深入了解，請參閱使用 Microsoft Entra ID 設定應用程式的群組宣告。
Azure 角色指派和 ACL 項目的限制
藉由使用群組，您不太會超過每個訂用帳戶的角色指派數目上限，以及每個檔案或目錄的 ACL 項目數上限。 下表描述了這些限制。
| 機制 | 範圍 | 限制 | 支援的權限層級 |
|---|---|---|---|
| Azure RBAC | 儲存體帳戶、容器。 訂用帳戶或資源群組層級的跨資源 Azure 角色指派。 |
訂用帳戶中 4000 個 Azure 角色指派 | Azure 角色 (內建或自訂) |
| ACL | 目錄、檔案 | 每個目錄和每個檔案 32 個 ACL 項目 (實際上是 28 個 ACL 項目)。 存取和預設 ACL 各有各的 32 個 ACL 項目限制。 | ACL 權限 |
共用金鑰和共用存取簽章 (SAS) 授權
Azure Data Lake Storage 也支援 共用密鑰 和 SAS 方法來進行驗證。
使用共用金鑰時，呼叫者可有效取得「超級使用者」存取權，亦即對所有資源的所有作業具有完整存取權，包括資料、設定擁有者和變更 ACL。 ACL 不適用於使用共用金鑰授權的使用者，因為沒有身分識別與呼叫者相關聯，因此無法執行以安全性主體權限為基礎的授權。 對於共用存取簽章 (SAS) 權杖也是如此，除非使用使用者委派的 SAS 權杖。 在此情況下，只要使用選擇性參數 suoid，Azure 儲存體就會在授權操作之前對物件 ID 執行 POSIX ACL 檢查。 若要深入了解，請參閱建構使用者委派 SAS。
下一步
若要深入瞭解訪問控制清單，請參閱 Azure Data Lake Storage 中的訪問控制清單（ACL）。