Azure Data Lake Storage 中的存取控制清單 (ACL)

Azure Data Lake Storage 可實作支援 Azure 角色型存取控制 (Azure RBAC) 和 POSIX 型存取控制清單 (ACL) 的存取控制模型。 本文說明 Data Lake Storage 中的存取控制清單。 欲了解如何將 Azure RBAC 與 ACL 結合，以及系統如何評估它們以做出授權決策，請參閱 Azure Data Lake Storage 中的 存取控制模型。

關於 Azure Data Lake Storage 中的 ACL

您可以將安全性主體與檔案和目錄的存取層級建立關聯。 每個關聯都是 存取控制清單（ACL）中的一個項目。 儲存體帳戶中的每個檔案和目錄都具有存取控制清單。 當安全性主體嘗試在檔案或目錄上執行作業時，ACL 檢查會判斷該安全性主體 (使用者、群組、服務主體或受控識別) 是否有相應的權限等級來執行此作業。

如何在 Azure Data Lake Storage 中設定 ACL

若要設定檔案和目錄層級權限，請參閱下列任何文章：

ACL 的類型：存取 ACL、預設 ACL

存取控制清單有兩種： 存取存取控制清單（access ACL） 與 預設存取控制清單（default ACL）。

存取 ACL 可控制對物件的存取。 檔案和目錄都有存取 ACL。

預設 ACL 是目錄相關聯 ACL 的範本，用以判斷在該目錄下所建立任何子項目的存取 ACL。 檔案沒有預設 ACL。

存取 ACL 和預設 ACL 都有相同的結構。

權限層級

容器中目錄與檔案的權限為 讀取、 寫入與 執行。 請對檔案與目錄使用這些權限，如下表所示：

權限的簡短格式

使用 RWX 顯示 讀取 + 寫入 + 執行 權限。 還有一種數值形式， Read=4、 Write=2、 Execute=1。 把這些數字加起來就能顯示權限。 以下是一些範例：

權限繼承

在 Data Lake Storage 使用的 POSIX 模式中，你會將項目的權限儲存在該項目本身。 換句話說，如果你在建立子項目後才設定權限，子項目就無法繼承父項目的權限。 只有在建立子項目前，先設定父項目的預設權限，項目才會繼承權限。 舉例來說，如果你建立一個目錄，然後之後再設定預設 ACL，該目錄中已經存在的檔案就不會繼承新的預設 ACL。 只有設定 ACL 後建立的檔案會繼承它。

Azure Data Lake Storage 中 ACL 權限的常見情境

下表顯示讓安全性主體能夠執行 Operation 資料行中所列作業所需的 ACL 項目。

下表顯示代表虛構目錄階層各層級的資料行。 容器 (/) 的根目錄有一個資料行、有一個名為 Oregon 的子目錄、Oregon 目錄中有一個名為 Portland 的子目錄，Portland 目錄中有一個名為 Data.txt 的文字檔案。

刪除檔案與目錄

要刪除檔案，你不需要對檔案本身設定寫入權限。 父目錄只需要 -WX 權限。 但是要刪除目錄及其所有內容，父目錄必須具有寫入 + 執行權限。 要刪除的目錄及其中的每個目錄，都需要 [讀取 + 寫入 + 執行] 權限。

ACL 中的使用者與身份

每個檔案和目錄都有這些身分識別的不同權限︰

• 擁有的使用者
• 擁有群組
• 具名使用者
• 具名群組
• 具名服務主體
• 具名受控識別
• 所有其他使用者

使用者和群組的身分識別是 Microsoft Entra 身分識別。 因此，除非另有註明，否則 Data Lake Storage 中的使用者可能表示 Microsoft Entra 使用者、服務主體、受控識別或安全性群組。

超級使用者

超級使用者擁有所有使用者的大多數權限。 超級使用者：

• 擁有 所有 檔案和資料夾的 RWX 權限。

• 可以變更任何檔案或資料夾的權限。

• 可以變更任何檔案或資料夾的擁有使用者或擁有群組。

如果你用共享金鑰、帳號 SAS 或服務 SAS 建立容器、檔案或目錄，擁有者和擁有群組會被設定為 $superuser。

擁有的使用者

創建該項目的使用者自動成為該項目的所有權使用者。 擁有者使用者可以：

• 更改他們擁有的檔案權限。
• 只要檔案擁有者同時也是目標群組的成員，即可變更其所擁有檔案的所屬群組。

擁有群組

在 POSIX ACL 中，每個使用者都與主要群組相關聯。 例如，使用者 "Alice" 可能屬於 "finance" 群組。 Alice 也可能屬於多個群組，但一定有一個群組指定為其主要群組。 在 POSIX 中，當 Alice 建立檔案時，該檔案的擁有群組會被設定為她的主要群組，這裡是「財務」。擁有者群組的行為則類似於其他使用者和群組被分配的權限。

指派新檔案或目錄的擁有群組

• 案例 1：根目錄/。 在建立 Data Lake Storage 容器時，即會建立此目錄。 在此情況下，如果使用者使用 OAuth，擁有群組會設為建立容器的使用者。 若使用者使用共享金鑰、帳號 SAS 或服務 SAS 建立容器，擁有者與擁有群組會設定為 $superuser。
• 案例 2 (其他所有案例)：建立新項目時，會從父目錄複製擁有群組。

變更擁有群組

擁有群組可由下列身分變更：

• 任何超級使用者。
• 擁有者使用者 (前提是擁有者使用者也是目標群組的成員)。

系統如何評估 ACL 權限

系統依下列順序評估身分：

1. 超級使用者
2. 擁有者使用者
3. 具名使用者、服務主體或受控識別
4. 擁有群組或具名群組
5. 所有其他使用者

如果多個身份對象適用於一個安全主體，系統會授予與第一個身份關聯的權限等級。 例如，若安全主體同時是擁有者與命名使用者，則適用與擁有者相關聯的權限等級。

系統會將所有命名群一起考慮。 如果一個安全主體同時屬於多個命名群組，系統會評估每個群組直到找到所需的權限。 若所有指定群組均未提供所需權限，系統會根據所有其他使用者的權限進行評估請求。

以下的虛擬程式碼代表儲存體帳戶的存取檢查演算法。 此演算法會顯示身分識別的評估順序。

def access_check( user, desired_perms, path ) :
  # access_check returns true if user has the desired permissions on the path, false otherwise
  # user is the identity that wants to perform an operation on path
  # desired_perms is a simple integer with values from 0 to 7 ( R=4, W=2, X=1). User desires these permissions
  # path is the file or directory
  # Note: the "sticky bit" isn't illustrated in this algorithm

  # Handle super users.
  if (is_superuser(user)) :
    return True

  # Handle the owning user. Note that mask isn't used.
  entry = get_acl_entry( path, OWNER )
  if (user == entry.identity)
      return ( (desired_perms & entry.permissions) == desired_perms )

  # Handle the named users. Note that mask IS used.
  entries = get_acl_entries( path, NAMED_USER )
  for entry in entries:
      if (user == entry.identity ) :
          mask = get_mask( path )
          return ( (desired_perms & entry.permissions & mask) == desired_perms)

  # Handle named groups and owning group
  member_count = 0
  perms = 0
  entries = get_acl_entries( path, NAMED_GROUP | OWNING_GROUP )
  mask = get_mask( path )
  for entry in entries:
    if (user_is_member_of_group(user, entry.identity)) :
        if ((desired_perms & entry.permissions & mask) == desired_perms)
            return True

  # Handle other
  perms = get_perms_for_other(path)
  mask = get_mask( path )
  return ( (desired_perms & perms & mask ) == desired_perms)

ACL 遮罩

遮罩只會套用到具名使用者、具名群組與擁有群組的 ACL 項目。 遮罩會指定 ACL 專案中哪些許可權可用來授權存取。 這些套用的許可權稱為 ACL 專案的有效 許可權。 系統會忽略 ACL 條目中的所有其他權限。 藉由使用遮罩，您可以建立許可權等級的上限。

您可以針對個別呼叫指定遮罩。 這種彈性讓不同的消費系統（如叢集）能為其檔案操作使用不同的有效遮罩。 若您在特定要求上指定遮罩，將會完全覆寫預設遮罩。

Data Lake Storage 中的黏性位元

黏性位元是 POSIX 容器的更進階功能。 在 Data Lake Storage 的情境下，你不太可能需要那個黏性部分。 總結來說，如果你啟用目錄上的黏著位元，只有子項目的擁有者、目錄擁有者或超級使用者（$superuser）能刪除或重新命名子項目。

Azure 入口網站不會顯示黏滯位元。 想了解更多關於黏性位及其設定方法，請參閱《 什麼是黏性位 Data Lake Storage？》。

根目錄的默認許可權

針對新的 Data Lake Storage 容器，根目錄 （“/”） 的存取 ACL 預設為 750 ，檔案 為 640 。 下表顯示這些權限層級的符號標記法。

檔案不會被賦予 X bit，因為在純儲存系統中，X bit 對檔案沒有意義。

新檔案和目錄的預設權限

當你在現有目錄下建立新檔案或目錄時，父目錄的預設 ACL 會決定：

• 下層目錄的預設 ACL 和存取 ACL。
• 子檔案的存取 ACL（檔案沒有預設 ACL）。

Data Lake Storage 中的 umask

當你建立預設 ACL 時，系統會將 umask 套用到 access ACL 來決定預設 ACL 的初始權限。 如果你在父目錄上定義預設 ACL，系統會忽略 umask，並使用父目錄的預設 ACL 來設定初始值。

umask 是父目錄上的一個 9 位元值，其中包含用於擁有使用者、擁有群組及其他的 RWX 值。

Azure Data Lake Storage 的 umask 是設為 007 的常數值。 此值會轉譯成：

FAQ

我必須啟用 ACL 的支援嗎？

否。 只要開啟階層命名空間（HNS）功能，儲存帳號即可啟用存取控制（ACL）。

如果 HNS 被關閉，Azure RBAC 授權規則仍然適用。

套用 ACL 的最佳方式為何？

請一律使用 Microsoft Entra 安全性群組作為 ACL 項目中的指派主體。 抵制直接指派個別使用者或服務主體的機會。 使用此結構將可讓您新增和移除使用者或服務主體，而不需要將 ACL 重新套用至整個目錄結構。 相反地，您可以直接從適當的 Microsoft Entra 安全性群組新增或移除使用者和服務主體。

有許多不同方式可以設定群組。 例如，假設您有一個名為 /LogData 的目錄，該目錄會保存伺服器產生的記錄資料。 Azure Data Factory (ADF) 會將資料內嵌至該資料夾內。 服務工程小組的特定使用者會上傳記錄並管理此資料夾的其他使用者，而各種 Databricks 叢集會分析該資料夾中的記錄。

若要啟用這些活動，您可以建立 LogsWriter 群組和 LogsReader 群組。 然後，您可以依下述步驟指派權限：

• 將 群組新增至 目錄的 ACL，並設置 權限。
• 將 群組新增至 目錄的 ACL，並設置 權限。
• 將服務主體物件或適用於 ADF 的受控服務識別 (MSI) 新增至 LogsWriters 群組。
• 將服務工程團隊中的使用者新增至 LogsWriter 群組。
• 將 Databricks 的服務主體物件或 MSI 新增至 LogsReader 群組。

如果服務工程團隊中的使用者離開公司，您可以直接從該群組LogsWriter移除他們。 如果您未將該使用者新增至群組，而是為該使用者新增專用的 ACL 項目，則必須從 /LogData 目錄中移除該 ACL 項目。 您也必須從 /LogData 目錄的所有目錄階層中的所有子目錄和檔案中移除該項目。

若要建立群組並新增使用者，請參閱使用 Microsoft Entra ID 建立群組並新增成員。

Azure RBAC 和 ACL 權限的評估方式為何？

若要瞭解系統如何一起評估 Azure RBAC 和 ACL，以進行儲存體帳戶資源的授權決策，請參閱如何評估權限。

Azure 角色指派和 ACL 項目有哪些限制？

下表提供使用 Azure RBAC 管理「粗粒度」權限（套用至儲存體帳戶或容器的權限）以及使用 ACL 管理「細粒度」權限（套用至檔案和目錄的權限）時須考慮的限制摘要檢視。 使用安全性群組以進行 ACL 指派。 藉由使用群組，您不太會超過每個訂用帳戶的角色指派數目上限，以及每個檔案或目錄的 ACL 項目數上限。

Data Lake Storage 是否支援 Azure RBAC 的繼承？

Azure 角色指派會繼承。 指派會從訂用帳戶、資源群組和儲存體帳戶資源向下傳至容器資源。

Data Lake Storage 是否支援 ACL 的繼承？

預設 ACL 可以用來為父目錄下新建立的子目錄和檔案設定 ACL。 要更新現有子項目的 ACL，你需要依照所需的目錄階層，遞迴地新增、更新或移除 ACL。 如需指引，請參閱本文的如何設定 ACL 一節。

若要以遞迴方式刪除目錄及其內容，需要哪些權限？

• 來電者擁有超級使用者權限，

或

• 父目錄擁有寫入與執行權限。
• 要刪除的目錄及其內的每個目錄都需要讀取、寫入和執行權限。

誰是檔案或目錄的擁有者？

檔案或目錄的建立者會成為擁有者。 以根目錄為例，這個身份就是建立容器的使用者。

在建立檔案或目錄時，會將哪個群組設定為擁有群組？

當建立新檔案或目錄時，擁有群組會從建立該新檔案或目錄之父目錄的擁有群組複製而來。

我是檔案的擁有使用者，但沒有我需要的 RWX 權限。 我該如何處理？

擁有使用者可以變更檔案的權限，以取得本身所需的任何 RWX 權限。

為什麼我有時候會在 ACL 中看到 GUID？

如果該條目代表已不存在於 Microsoft Entra 中的使用者，你會看到 GUID。 這種情況通常發生在使用者離職或其帳戶在 Microsoft Entra ID 中被刪除時。 此外，服務主體與安全群組沒有使用者主體名稱（UPN），因此系統會以其 OID 屬性（GUID）來識別它們。 若要清除 ACL，請手動刪除這些 GUID 項目。

如何為服務主體正確設定 ACL？

當您為服務主體定義 ACL 時，請務必針對您所建立的應用程式註冊使用服務主體的物件識別碼 (OID)。 請注意，已註冊的應用程式在特定 Microsoft Entra 租用戶中具有個別的服務主體。 註冊的應用程式具有 Azure 入口網站中可見的 OID，但服務主體具有另一個 (不同的) OID。 文章若要取得對應至應用程式註冊的服務主體 OID，您可以使用 az ad sp show 命令。 將應用程式識別碼指定為參數。 以下是取得與應用程式註冊（App ID = 00001111-aaaa-2222-bbbb-3333cccc4444）對應的服務主體 OID 的範例。 在 Azure CLI 中執行以下命令：

az ad sp show --id 00001111-aaaa-2222-bbbb-3333cccc4444 --query objectId

此命令會顯示 OID。

當您有服務主體的正確 OID 時，請移至儲存體總管 [管理存取權] 頁面，以新增 OID 並為 OID 指派適當的權限。 請確定選取 [儲存]

我是否可以設定容器的 ACL？

否。 容器沒有存取控制清單（ACL）。 不過，您可以設定容器根目錄的 ACL。 每個容器都有一個根目錄，且與容器共用相同名稱。 例如，若容器命名 my-container為 ，根目錄則命名 my-container/為 。

Azure 儲存體 REST API 包含一個名為 Set Container ACL 的操作，但你無法用該操作來設定容器的 ACL 或容器的根目錄。 相反地，該操作用來指示容器中的 blob 是否能以匿名請求存取。 所有對 blob 資料的要求都必須經過授權。 如需詳細資訊，請參閱概觀：修復 Blob 資料的匿名讀取存取。

何處可以進一步了解 POSIX 存取控制模型？

• Linux 上的 POSIX 存取控制清單
• HDFS 權限指南
• POSIX 常見問題集
• POSIX 1003.1 2008
• POSIX 1003.1 2013
• POSIX 1003.1 2016
• Ubuntu 上的 POSIX ACL

另請參閱

• Azure Data Lake Storage 中的存取控制模型