共用方式為


受控識別最佳做法建議

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

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

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

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

這個生命週期可讓您將資源建立和身分識別管理責任分開。 使用者指派的身分識別及其角色指派可以在需要它們的資源之前進行設定。 建立資源的使用者只需要存取權即可指派使用者指派的身分識別,而不需要建立新的身分識別或角色指派。

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

如果您的基礎結構要求多個資源需要存取相同的資源,則可以指派單一使用者指派的身分識別。 系統管理負擔將會降低,因為要管理的相異身分識別和角色指派較少。

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

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

如果資源快速建立或刪除,當您使用系統指派的身分識別時,也可能會超出 Microsoft Entra ID 中的資源數目限制。 雖然已刪除的系統指派身分識別已無法再供任何資源存取,但是在 30 天後完全清除之前,將會計入您的限制。

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

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

藉由使用相同的使用者指派身分識別,需要較少的角色指派,以降低管理負擔。 資源不一定是相同的類型。
法規遵循 使用者指派的身分識別 如果您的組織要求所有身分識別建立都必須通過核准程序,在多個資源上使用單一使用者指派的身分識別,會比系統指派的身分識別需要較少的核准,而這會在建立新資源時建立。
部署資源之前需要存取 使用者指派的身分識別 某些資源可能需要存取某些 Azure 資源,以作為其部署的一部分。

在此情況下,系統指派的身分識別可能無法及時建立,因此應該使用既有的使用者指派身分識別。
稽核記錄 系統指派的身分識別 如果您需要記錄執行動作的特定資源,而不是哪個身分識別,請使用系統指派的身分識別。
權限生命週期管理 系統指派的身分識別 如果您需要資源的權限與資源一併移除,請使用系統指派的身分識別。

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

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

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

四部虛擬機器,其使用系統指派的身分識別來存取儲存體帳戶和金鑰保存庫。

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

四部虛擬機器,其使用使用者指派的身分識別來存取儲存體帳戶和金鑰保存庫。

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

四部虛擬機器,其系統指派的身分識別新增至具有角色指派的安全性群組。

多個受控識別

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

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

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

四部虛擬機器,其中兩部具有多個使用者指派的身分識別。

在下列範例中,「虛擬機器 4」具有使用者指派的身分識別,可讓其存取儲存體帳戶和金鑰保存庫,取決於驗證時使用的身分識別。 系統指派身分識別的角色指派是該虛擬機器的特定角色指派。

四部虛擬機器,其中一部同時具有系統指派的身分識別和使用者指派的身分識別。

限制

檢閱受控識別自訂角色和角色指派的限制。

授與存取權時,請遵循最低權限的原則

授與任何身分識別 (包括受控識別) 時,存取服務的權限一律會授與執行所需動作必要的最低權限。 例如,如果使用受控識別從儲存體帳戶讀取資料,則不需要允許該身分識別權限也可以將資料寫入儲存體帳戶。 授與額外權限 (例如,在不需要 Azure 訂用帳戶時,讓受控識別成為參與者) 時,會增加與身分識別相關聯的安全性影響半徑。 必須一律將安全性影響半徑降至最低,讓身分識別能夠造成的危害減至最輕。

請考慮將受控識別指派給 Azure 資源的效果和/或將指派權限授予使用者

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

例如,如果受控識別 (ClientId = 1234) 已將讀取/寫入存取權授與 StorageAccount7755 並且已指派給 LogicApp3388,則沒有儲存體帳戶的直接存取,但是具有在 LogicApp3388 內執行程式碼權限的 Alice 這位使用者,也可以藉由執行可使用受控識別的程式碼,將資料讀取/寫入進出 StorageAccount7755

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

安全性案例

一般來說,對可執行程式碼 (例如邏輯應用程式) 和具有受控識別的資源授與系統管理存取權時,請考慮要指派給使用者的角色是否可以在資源上安裝或執行程式碼,如果是的話,僅指派使用者真正需要的角色。

維護

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

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

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

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

找不到身分識別以進行角色指派。

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

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

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

使用 Microsoft Entra ID 群組來授與服務的存取權,是簡化授權程序的絕佳方法。 此概念很簡單 - 將權限授與群組,並將身分識別新增至群組,使其繼承相同的權限。 這是來自各種內部部署系統的妥善建立模式,當身分識別代表使用者時,也會正常運作。 在 Microsoft Entra ID 中控制授權的另一個選項是使用應用程式角色,可讓您宣告應用程式特定的角色 (而不是群組,這是目錄中的全域概念)。 然後,您可以將應用程式角色指派給受控識別 (以及使用者或群組)。

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

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

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