受控識別最佳做法建議

Azure 資源的受控識別是 Microsoft Entra ID 的功能。 每個支援適用於 Azure 資源的受控識別 Azure 服務均受限於其本身的時間表。 開始之前,請務必檢閱 資源受控識別的可用性 狀態和 已知問題

選擇系統或使用者指派的受控識別

使用者指派的受控識別在比系統指派的受控識別更廣泛的案例中更有效率。 如需某些案例,請參閱下表,以及使用者指派或系統指派的建議。

使用者指派的身分識別可由多個資源使用,且其生命週期會與與其相關聯的資源生命週期分離。 讀取哪些資源支援受控識別

此生命週期可讓您分隔資源建立和身分識別管理責任。 使用者指派的身分識別及其角色指派可以事先設定需要他們的資源。 建立資源的使用者只需要存取權才能指派使用者指派的身分識別,而不需要建立新的身分識別或角色指派。

由於系統指派的身分識別會隨著資源一起建立和刪除,因此無法事先建立角色指派。 如果建立資源的使用者沒有建立角色指派的存取權,則部署基礎結構時,此順序可能會導致失敗。

如果您的基礎結構要求多個資源需要存取相同的資源,則可以將單一使用者指派的身分識別指派給他們。 管理員管理的額外負荷將會減少,因為要管理的不同身分識別和角色指派較少。

如果您要求每個資源都有自己的身分識別,或有需要一組唯一許可權的資源,而且想要刪除資源時刪除身分識別,則您應該使用系統指派的身分識別。

案例 建議 備註
使用受控識別快速建立資源(例如暫時運算) 使用者指派的身分識別 如果您嘗試在短時間內建立多個受控識別 –例如,部署多個虛擬機器,每個虛擬機器都有自己的系統指派身分識別-您可能超過 Microsoft Entra 物件建立的速率限制,而且要求將會失敗,並出現 HTTP 429 錯誤。

如果資源正在快速建立或刪除,則如果使用系統指派的身分識別,您可能也會超過 Microsoft Entra 識別碼中的資源數目限制。 雖然任何資源無法再存取已刪除的系統指派身分識別,但它將會計入您的限制,直到 30 天后完全清除為止。

部署與單一使用者指派身分識別相關聯的資源,只需要在 Microsoft Entra ID 中建立一個服務主體,以避免速率限制。 使用事先建立的單一身分識別,也會降低複寫延遲的風險,如果建立多個資源時,每個資源都有自己的身分識別。

深入瞭解 Azure 訂用 帳戶服務限制
複寫的資源/應用程式 使用者指派的身分識別 執行相同工作的資源 –例如,重複的網頁伺服器或相同功能在應用程式服務和虛擬機器上的應用程式中執行 - 通常需要相同的許可權。

藉由使用相同的使用者指派身分識別,需要較少的角色指派,以減少管理額外負荷。 資源不一定是相同的類型。
合規性 使用者指派的身分識別 如果您的組織要求所有身分識別建立都必須經過核准程式,跨多個資源使用單一使用者指派的身分識別,將需要比系統指派的身分識別更少的核准,而系統指派的身分識別會建立為新資源。
部署資源之前所需的存取權 使用者指派的身分識別 某些資源可能需要在其部署時存取特定 Azure 資源。

在此情況下,系統指派的身分識別可能不會及時建立,因此應該使用預先存在的使用者指派身分識別。
稽核記錄 系統指派的身分識別 如果您需要記錄哪些特定資源執行動作,而不是哪個身分識別,請使用系統指派的身分識別。
許可權生命週期管理 系統指派的身分識別 如果您需要將資源的許可權連同資源一起移除,請使用系統指派的身分識別。

使用使用者指派的身分識別來減少系統管理

此圖表示範系統指派和使用者指派的身分識別之間的差異,這可用來允許數部虛擬機器存取兩個儲存體帳戶。

此圖顯示四部具有系統指派身分識別的虛擬機器。 每個虛擬機器都有相同的角色指派,可授與兩個儲存體帳戶的存取權。

Four virtual machines using system-assigned identities to access a storage account and key vault.

當使用者指派的身分識別與四部虛擬機器相關聯時,只有兩個角色指派,而系統指派的身分識別則只有八個。 如果虛擬機器的身分識別需要更多角色指派,則會授與此身分識別相關聯的所有資源。

Four virtual machines using a user-assigned identity to access a storage account and key vault.

安全性群組也可以用來減少所需的角色指派數目。 此圖顯示四部具有系統指派身分識別的虛擬機器,這些虛擬機器已新增至安全性群組,並將角色指派新增至群組,而不是系統指派的身分識別。 雖然結果類似,但此設定不會提供與使用者指派身分識別相同的 Resource Manager 範本功能。

Four virtual machines with their system-assigned identities added to a security group that has role assignments.

多個受控識別

支援受控識別的資源可以同時擁有系統指派的身分識別和一或多個使用者指派的身分識別。

此模型可讓您彈性地使用共用使用者指派的身分識別,並在需要時套用細微的許可權。

在下列範例中,「虛擬機器 3」和「虛擬機器 4」可以存取儲存體帳戶和金鑰保存庫,視他們在驗證時所使用的使用者指派身分識別而定。

Four virtual machines, two with multiple user-assigned identities.

在下列範例中,「虛擬機器 4」同時具有使用者指派的身分識別,根據驗證時會使用哪個身分識別,授與儲存體帳戶和金鑰保存庫的存取權。 系統指派身分識別的角色指派是該虛擬機器特有的。

Four virtual machines, one with both system-assigned and user-assigned identities.

限制

檢視受控識別的限制 ,以及 自訂角色和角色指派的限制

授與存取權時,請遵循最低許可權原則

授與任何身分識別,包括受控識別、存取服務的許可權時,一律授與執行所需動作所需的最低許可權。 例如,如果使用受控識別從儲存體帳戶讀取資料,就不需要允許該身分識別許可權也將資料寫入儲存體帳戶。 例如,在不需要 Azure 訂用帳戶時授與額外的許可權,讓受控識別成為 Azure 訂用帳戶上的參與者,會增加與身分識別相關聯的安全性爆破半徑。 必須一律將安全性爆炸半徑降到最低,以損害該身分識別。

請考慮將受控識別指派給 Azure 資源及/或將指派許可權授與使用者的效果

請務必注意,當 Azure 資源,例如 Azure 邏輯應用程式、Azure 函式或虛擬機器等指派受控識別時,所有授與受控識別的許可權現在都可供 Azure 資源使用。 這很重要,因為如果使用者有權在此資源上安裝或執行程式碼,則使用者可以存取指派/與 Azure 資源相關聯的所有身分識別。 受控識別的目的是讓 Azure 資源上執行的程式碼能夠存取其他資源,而開發人員不需要直接處理或將認證放入程式碼中,以取得該存取權。

例如,如果受控識別 (ClientId = 1234) 已授與儲存體Account7755 的 讀取/寫入權限 ,且已指派給 LogicApp3388,則 Alice 沒有儲存體帳戶的直接存取權,但有權在 LogicApp3388 執行程式碼,也可以讀取/ 寫入資料至 儲存體Account7755 執行使用受控識別的程式碼。

同樣地,如果 Alice 有權自行指派受控識別,她可以將它指派給不同的 Azure 資源,並有權存取受控識別可用的擁有權限。

security scenario

一般而言,授與使用者系統管理存取權給可執行程式碼的資源(例如邏輯應用程式)並具有受控識別時,請考慮將角色指派給使用者是否可以在資源上安裝或執行程式碼,如果是,則只指派該角色,如果使用者真的需要它。

維護

系統指派的身分識別會在刪除資源時自動刪除,而使用者指派身分識別的生命週期與與其相關聯的任何資源無關。

當您不再需要使用者指派的身分識別時,即使沒有任何資源與其相關聯,您也必須手動刪除該身分識別。

刪除系統指派或使用者指派的受控識別時,不會自動刪除角色指派。 這些角色指派應該手動刪除,因此不會超過每個訂用帳戶的角色指派限制。

在入口網站中檢視時,與已刪除的受控識別相關聯的角色指派會顯示為「找不到身分識別」。 閱讀更多內容

Identity not found for role assignment.

不再與使用者或服務主體相關聯的角色指派將會以 的值 Unknown 出現 ObjectType 。 若要移除這些命令,您可以將數個 Azure PowerShell 命令管線傳送到一起,先取得所有角色指派、篩選為僅具有 ObjectTypeUnknown 的人員,然後從 Azure 移除這些角色指派。

Get-AzRoleAssignment | Where-Object {$_.ObjectType -eq "Unknown"} | Remove-AzRoleAssignment 

使用受控識別進行授權的限制

使用 Microsoft Entra 識別碼 群組 來授與服務的存取權是簡化授權程式的絕佳方式。 概念很簡單 – 將許可權授與群組,並將身分識別新增至群組,使其繼承相同的許可權。 這是來自各種內部部署系統且在身分識別代表使用者時運作良好的模式。 在 Microsoft Entra ID 中控制授權的另一個選項是使用 應用程式角色 ,這可讓您宣告 應用程式專屬的角色 (而不是目錄中全域概念的群組)。 然後 ,您可以將應用程式角色指派給受控識別 (以及使用者或群組)。

在這兩種情況下,對於非人為身分識別,例如 Microsoft Entra Applications 和受控識別,此授權資訊向應用程式呈現方式的確切機制目前並不適合。 現今使用 Microsoft Entra ID 和 Azure 角色型存取控制 (Azure RBAC) 的實作會使用 Microsoft Entra ID 所簽發的存取權杖來驗證每個身分識別。 如果身分識別新增至群組或角色,這會以 Microsoft Entra ID 所簽發的存取權杖中的宣告表示。 Azure RBAC 會使用這些宣告來進一步評估授權規則,以允許或拒絕存取。

假設身分識別的群組和角色是存取權杖中的宣告,在重新整理權杖之前,任何授權變更都不會生效。 對於通常不是問題的人類使用者,因為使用者可以透過登出和重新登入來取得新的存取權杖(或等待權杖存留期到期,預設為 1 小時)。 另一方面,受控識別權杖會由基礎 Azure 基礎結構快取,以達到效能和復原性目的:受控識別的後端服務會在大約 24 小時內維護每個資源 URI 的快取。 這表示變更受控識別的群組或角色成員資格可能需要數小時才會生效。 目前,您無法強制在受控識別的權杖到期前重新整理。 如果您變更受控識別的群組或角色成員資格以新增或移除許可權,您可能需要等候數小時,讓 Azure 資源使用身分識別具有正確的存取權。

如果您的需求無法接受此延遲,請考慮使用權杖中的群組或角色的替代方案。 為了確保受控識別的許可權變更會快速生效,建議您使用 使用者指派的受控識別 將 Azure 資源分組,並將許可權直接套用至身分識別,而不是從具有許可權的 Microsoft Entra 群組新增或移除受控識別。 使用者指派的受控識別可以像群組一樣使用,因為它可以指派給一或多個 Azure 資源來使用它。 您可以使用受控識別參與者 受控識別操作員角色 來控制 指派作業。