使用條件和自定義安全性屬性調整 Azure 角色指派的管理

發行項
11/16/2023

Azure 角色型訪問控制（Azure RBAC）具有每個訂用帳戶的角色指派限制。如果您需要建立數百或甚至數千個 Azure 角色指派，可能會遇到此限制。管理數十或數千個角色指派可能很困難。視您的案例而定，您可能能夠減少角色指派的數目，並讓您更輕鬆地管理存取權。

本文說明使用 Azure 屬性型訪問控制（Azure ABAC）條件和主體的 Microsoft Entra 自定義安全性屬性，調整角色指派管理的解決方案。

範例案例

請考慮名為 Contoso 的公司，其中包含數千個想要設定下列設定的客戶：

基於安全性和效能考慮，將客戶數據分散到128個記憶體帳戶。
將 2,000 個容器新增至每個記憶體帳戶，其中每個客戶都有容器。
以唯一的 Microsoft Entra 服務主體表示每個客戶。
允許每個客戶存取其容器中的物件，但不允許其他容器。

此設定可能需要 256,000 個儲存體訂用帳戶中的 Blob 數據擁有者角色指派，遠遠超出角色指派限制。擁有這個許多角色指派會很難維護，如果不是不可能的話。

Diagram showing thousands for role assignments.

範例解決方案

以可維護的方式處理此案例的方法，是使用角色指派條件。下圖顯示一個解決方案，使用條件將256,000個角色指派減少為僅一個角色指派。角色指派位於較高的資源群組範圍，而條件可協助控制容器的存取。條件會檢查容器名稱是否符合客戶服務主體上的自定義安全性屬性。

Diagram showing one role assignment and a condition.

以下是讓此解決方案運作的條件中的表示式：

  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name]
  StringEquals
  @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]

完整條件如下所示。您可以調整動作清單，只調整為您需要的動作。

(
 (
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/delete'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/add/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/deleteBlobVersion/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/manageOwnership/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/modifyPermissions/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/move/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/permanentDelete/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/runAsSuperUser/action'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/read'})
  AND
  !(ActionMatches{'Microsoft.Storage/storageAccounts/blobServices/containers/blobs/tags/write'})
 )
 OR 
 (
  @Resource[Microsoft.Storage/storageAccounts/blobServices/containers:name] StringEquals @Principal[Microsoft.Directory/CustomSecurityAttributes/Id:Contosocustomer_name]
 )
)

為什麼要使用此解決方案？

您可以使用數種存取控制機制來提供資料平面資源的存取權。

存取金鑰是提供數據平面資源的存取權的常見方式。存取金鑰會提供讀取、寫入和刪除許可權給擁有存取密鑰的人員。這表示攻擊者可以在取得存取密鑰時取得敏感數據的存取權。存取金鑰沒有身分識別系結、沒有到期日，而且是儲存的安全性風險。

如同存取金鑰，共用存取簽章（SAS）令牌沒有身分識別系結，但會定期到期。缺乏身分識別系結代表與存取密鑰相同的安全性風險。您必須管理到期日，以確保用戶端不會收到錯誤。 SAS 令牌需要額外的程序代碼，才能每天管理及運作，而且對於 DevOps 小組來說可能是一個重大額外負荷。

Azure RBAC 提供集中式精細訪問控制。 Azure RBAC 具有身分識別系結，可降低您的安全性風險。您可以使用條件來調整角色指派的管理，並讓訪問控制更容易維護，因為存取是以彈性和動態屬性為基礎。

以下是此解決方案的一些優點：

集中式訪問控制
更容易維護
不依賴存取金鑰或 SAS 令牌
不需要您管理每個物件的存取權
可能會改善您的安全性狀態

您可以使用此解決方案嗎？

如果您有類似的案例，請遵循下列步驟來查看您是否可能使用此解決方案。

步驟 1：判斷您是否符合必要條件

若要使用此解決方案，您必須具備：

具有 Blob 記憶體數據動作的多個內建或自定義角色指派。其中包括下列內建角色：

步驟 2：識別可在條件中使用的屬性

您可以在條件中使用數個屬性，例如：

容器名稱
Blob 路徑
Blob 索引標籤 [索引鍵]
Blob 索引標籤 [索引鍵中的值]

您也可以為使用者、企業應用程式和受控識別定義自己的自定義安全性屬性。

如需詳細資訊，請參閱 Azure 角色指派條件格式和語法，以及什麼是 Microsoft Entra ID 中的自定義安全性屬性？。

步驟 3：在較高範圍建立條件

建立一或多個角色指派，以在較高範圍使用條件來管理存取權。如需詳細資訊，請參閱使用 Azure 入口網站新增或編輯 Azure 角色指派條件。

共用方式為