登陸區域身分識別和存取管理
識別身分識別架構之後，您必須管理應用程式和平臺登陸區域中資源的授權和存取權。 請考慮每個已驗證主體可存取和需要存取的資源，以及如何降低未經授權存取資源的風險。 如需詳細資訊，請參閱 身分識別架構設計。
概觀
身分識別和存取管理設計區域提供指引，協助您在 Azure 中實作企業存取模型，以及實作和保護控制平面。 當您納入訂用帳戶民主化的設計原則時，應用程式小組可以在平臺小組所設定的原則護欄內管理自己的工作負載。 此方法也會遵循 原則驅動的治理 原則。
平臺小組負責布建新的應用程式登陸區域或訂用帳戶。 當他們為應用程式擁有者布建登陸區域時，平臺小組應該使用適當的訪問控制來設定它，讓應用程式擁有者可以管理自己的資源。 應用程式擁有者應該能夠在 Microsoft Entra 識別碼內建立和管理使用者和群組，並將角色指派給這些使用者和群組。 然後，應用程式擁有者可以管理自己資源的存取權，並視需要將存取權委派給其他使用者和群組。 登陸區域也應該根據應用程式的需求，在 Microsoft 身分識別平台 訂用帳戶中對 Active Directory 網域服務 或 Microsoft Entra Domain Services 有選擇性的網路連線能力。
使用 Azure 角色型存取控制 （RBAC） 來管理 Azure 資源的系統管理存取權。 請考慮使用者是否需要範圍狹窄的許可權，例如單一應用程式的系統管理員，或廣泛的範圍，例如跨多個應用程式工作負載的網路管理員。 不論是哪一種情況，都遵循足夠存取的原則，並確保使用者只有正常活動所需的角色。 必要時，請使用自定義角色和Microsoft Entra Privileged Identity Management （PIM） 來強制執行 Just-In-Time （JIT） 存取。 雖然平臺小組負責身分識別和存取管理基礎，但平臺和應用程式小組都是服務的取用者，而且應該遵循相同的原則。
身分識別和存取管理對於成功將一個登陸區域與另一個登陸區域分離，以及組織內工作負載的隔離很重要。 這是平臺和應用程式登陸區域的重要設計區域。
如果您的組織使用訂用 帳戶自動銷售程式，您可以將應用程式登陸區域的許多身分識別和存取設定自動化。 實作 訂閱自動販賣 以協助標準化登陸區域建立，讓應用程式小組可以管理自己的資源。
設計考量
某些組織在多個應用程式之間共享服務。 例如，可能有數個獨立應用程式使用的集中式整合服務。 在該案例中，請考慮集中管理哪些服務，哪些服務會下放給應用程式小組，並瞭解需要強制執行安全性界限的位置。 為應用程式小組提供共用服務的系統管理存取權可能有助於開發人員生產力，但可能會提供比必要更多的存取權。
管理未跨安全性界限的應用程式資源可以委派給應用程式小組。 請考慮委派維護安全性與合規性所需的其他層面。 讓使用者在安全管理的環境中布建資源，可讓組織利用雲端的敏捷本質，並防止違反任何重要的安全性或治理界限。
RBAC
重要
傳統資源和傳統系統管理員將於 2024 年 8 月 31 日淘汰。 拿掉不必要的共同管理員，並使用 Azure RBAC 進行更細緻的訪問控制。
瞭解Microsoft Entra ID 角色與 Azure RBAC 角色之間的差異。
Microsoft Entra ID 角色可控制全租使用者服務的系統管理許可權，例如 Microsoft Entra ID，以及其他 Microsoft 服務，包括 Microsoft Teams、Microsoft Exchange Online 和 Microsoft Intune。
Azure RBAC 角色可控制 Azure 資源的系統管理許可權，例如虛擬機、訂用帳戶和資源群組。
Azure RBAC 擁有者和使用者存取系統管理員角色可以修改 Azure 資源上的角色指派。 根據預設，Microsoft Entra 全域管理員角色沒有管理 Azure 資源存取權的許可權。 它必須明確啟用。 如需詳細資訊，請參閱提高存取權以管理所有 Azure 訂用帳戶和管理群組。
重要
Microsoft建議您使用具有最少許可權的角色。 這有助於改善組織的安全性。 全域管理員是高度特殊許可權的角色，當您無法使用現有角色時，應該受限於緊急案例。
下圖顯示Microsoft Entra ID 角色與 Azure RBAC 角色之間的關聯性：
如果您將 屬性設定
isAssignableToRole為 ，您可以建立可指派角色的群組，並將Microsoft Entra 角色指派給true群組。 只有具有此屬性集的群組會受到保護。 唯一可以修改群組成員資格的角色是全域管理員、特殊許可權角色管理員或群組的擁有者。只有 某些角色可以重設另一個系統管理員的密碼 或多重要素驗證 （MFA） 設定。 此限制可防止未經授權的系統管理員重設較高許可權帳戶的認證，以取得更多許可權。
如果 Azure 內建的角色無法滿足您組織的特定需求，您可以建立自己的自訂角色。 就像內建角色一樣，您可以將自定義角色指派給租使用者、管理群組、訂用帳戶和資源群組範圍中的使用者、群組和服務主體。 目的是盡可能使用 Azure 內建角色，並在必要時只建立自定義角色。
當您設計訪問控制策略時，請知道 角色、角色指派和自定義角色的服務限制。
某些 Azure RBAC 角色支援 屬性型存取控制 （ABAC）或角色指派條件。 當您使用條件時，系統管理員可以根據資源的屬性動態指派角色。 例如，您可以指派記憶體 Blob 數據參與者角色，但僅適用於具有特定索引標籤的 Blob，而不是容器中的所有 Blob。
您可以使用內建和自定義 RBAC 角色搭配
Microsoft.Authorization/roleAssignments/write或Microsoft.Authorization/roleAssignments/delete權限來建立、刪除和更新角色指派。 具有此角色的任何人都可以決定誰具有指派範圍中任何資源的寫入、讀取和刪除許可權。 平臺或應用程式登陸區域小組成員應考慮如何將特殊許可權角色委派給其他使用者和群組，以授與他們必要的自主性。 為了確保符合最低許可權存取原則，他們可以使用 條件 來委派使用者。
設計建議
一般建議
針對 具有 Azure 環境許可權的使用者強制執行Microsoft Entra 多重要素驗證 （MFA）， 包括平臺訂用帳戶、應用程式訂用帳戶，以及Microsoft Entra ID 租使用者。 許多合規性架構都需要強制執行 MFA。 MFA 有助於降低認證竊取和未經授權的存取風險。 若要防止未經授權的敏感性資訊存取，請確定您在 MFA 原則中包含具有讀取者角色的使用者。
針對具有 Azure 環境許可權的使用者，使用 Microsoft Entra 條件式存取 原則。 條件式存取是另一項功能，可協助保護受控制的 Azure 環境免於未經授權的存取。 應用程式和平台系統管理員應該有條件式存取原則，以反映其角色的風險配置檔。 例如，您可能必須只從特定位置或特定工作站執行系統管理活動。 或者，具有 Azure 資源系統管理存取權的使用者登入風險承受能力可能低於標準Microsoft Entra ID 使用者。
啟用 適用於身分識別的 Microsoft Defender 以協助保護使用者身分識別及保護用戶認證。 適用於身分識別的Defender是 Microsoft Defender 全面偵測回應的一部分。 您可以使用適用於身分識別的 Defender 來識別可疑的使用者活動並取得事件時程表。 您也可以將它與條件式存取搭配使用，以拒絕高風險驗證嘗試。 將適用於身分識別的 Defender 感測器部署至 Azure 身分識別訂用帳戶中的內部部署域控制器和域控制器。
使用 Microsoft Sentinel 提供威脅情報和調查功能。 Sentinel 會使用來自 Azure 監視器記錄、Microsoft Entra ID、Microsoft 365 和其他服務的記錄，以提供主動式威脅偵測、調查和回應。
將系統管理存取與非管理性、日常存取權分開，例如網頁瀏覽和電子郵件存取。 Web 和電子郵件是常見的攻擊媒介。 當用戶帳戶遭到入侵時，如果帳戶未用於系統管理存取，則不太可能造成安全性缺口。
針對特殊許可權角色使用個別的僅限雲端帳戶。 請勿針對特殊許可權系統管理，每天使用相同的帳戶。 特殊許可權Microsoft Entra ID 和 Azure RBAC 角色會在 Azure 入口網站 和檔中標示為 PRIVILEGED。
針對可管理 Azure 應用程式資源的非特殊許可權作業函式角色，請考慮您是否需要個別的系統管理帳戶， 或使用 Microsoft Entra PIM 來控制系統管理存取。 PIM 可確保帳戶只有在需要時才具有必要的許可權，而且工作完成時會移除許可權（也稱為 Just-In-Time 存取權）。
若要讓角色指派更容易管理，請勿將角色直接指派給使用者。 相反地，將角色指派給群組，以協助將角色指派數目降到最低，每個訂用帳戶都有限制。
針對群組使用Microsoft Entra PIM，將 Just-In-Time 系統管理訪問控制套用至具特殊許可權的使用者。 請考慮使用權利管理來控制群組成員資格。 您可以使用權利管理功能，將核准和稽核工作流程新增至群組成員資格作業，並協助確保系統管理群組成員不會不必要地新增或移除。
當您授與資源的存取權時，請針對 Azure 控制平面資源使用僅限 Entra 群組Microsoft。 僅限 Entra 的使用者和群組，以及使用 Microsoft Entra Connect 從內部部署同步處理的使用者和群組，都可以新增至僅限 Entra 的群組。 如果已有群組管理系統，則將內部部署群組新增至僅限 Microsoft Entra 的群組。 使用僅限 Entra 的群組有助於保護雲端控制平面免於未經授權的內部部署目錄服務修改。 請注意， Microsoft僅限 Entra，也稱為 僅限雲端。
建立 緊急存取 帳戶或斷層帳戶，以避免意外鎖定您的Microsoft Entra ID 組織。 緊急存取帳戶具有高度特殊許可權，而且只會指派給特定個人。 安全地儲存帳戶的認證、監視其使用狀況，並定期進行測試，以確保您可以在發生災害時使用它們。
如需詳細資訊，請參閱 Microsoft Entra ID 中系統管理員的安全存取做法。
Microsoft項目標識碼建議
整合 Microsoft Entra ID 與 Azure 監視器 ，以便分析登入活動，以及租用戶內變更的稽核記錄。 設定診斷設定，將登入記錄和稽核記錄傳送至管理訂用帳戶中的平臺中央 Azure 監視器記錄工作區。
使用 Microsoft Entra ID 控管 的權利管理功能，建立可透過自動核准程式和特殊許可權群組成員的定期存取權檢閱來控制群組成員資格的存取套件。
使用 Microsoft Entra 內建角色 來管理租用戶層級的下列身分識別設定：
角色 描述 注意 全域系統管理員 管理使用Microsoft Entra 身分識別Microsoft專案標識碼和 Microsoft 服務 的所有層面。 請勿指派超過五人至該角色。 混合式身分識別管理員 管理從 Active Directory 到 Microsoft Entra 標識符的雲端布建，並管理 Microsoft Entra Connect、Microsoft Entra 傳遞驗證、Microsoft Entra 密碼哈希同步處理、Microsoft Entra 無縫單一登錄 （SSO） 和同盟設定。 安全性系統管理員 讀取安全性資訊和報告，並管理 Microsoft Entra ID 和 Microsoft 365 中的組態。 應用程式系統管理員 建立和管理應用程式註冊和企業應用程式的所有層面。 您無法授與整個租用戶的系統管理同意。 請勿將較高許可權的角色指派給低許可權角色可以執行的工作。 例如，指派使用者管理員角色來管理使用者，而不是全域管理員角色。 如需詳細資訊，請參閱 Microsoft Entra 內建角色許可權。
使用 系統管理單位 來限制一組系統管理員，因此他們只能管理租使用者中的特定物件。 您可以使用系統管理單位來委派目錄子集的管理。 例如，您可以將服務台的管理委派給更廣泛的組織內的單一業務單位。
系統管理單位也可以協助消除個別Microsoft Entra ID 租用戶作為安全性界限的需求，其中個別小組會管理相同組織中的Microsoft 365 平臺和 Azure 平臺。 例如，您可以使用系統管理單位，將 Azure 應用程式安全性主體的管理委派給應用程式小組，而不需要授與整個 Microsoft Entra ID 租使用者的許可權。
使用 受限制的管理管理單位 來提供進一步的保護。 防止您指定的特定系統管理員集合以外的任何人修改特定物件。 例如，您的職責原則區隔可能需要您使用此功能來防止任何人修改特定用戶帳戶，甚至是具有用戶系統管理員角色的使用者。 這項限制適用於應用程式所使用的服務帳戶，甚至系統管理員也不應該修改。 您也可以防止許可權提升，例如，如果有人修改具有平臺或登陸區域系統管理許可權的用戶帳戶或群組。
Azure RBAC 建議
為了簡化系統管理並降低設定錯誤的風險，請將所有應用程式登陸區域的角色和角色指派標準化。 例如，如果您有委派使用者管理虛擬機的角色，請在所有應用程式登陸區域中使用相同的角色。 此方法也會簡化在登陸區域之間移動資源的程式。
盡可能使用 Azure RBAC 管理資源的數據平面存取。 數據平面端點的範例包括 Azure 金鑰保存庫、記憶體帳戶或 SQL 資料庫。
請確定 Azure 監視器記錄工作區已設定適當的許可權模型。 當您使用集中式 Azure 監視器記錄工作區時，請使用 資源許可權 來確保應用程式小組可以存取自己的記錄，但無法存取來自其他小組的記錄。
內建角色
請考慮內建角色是否適合您的需求。 在許多情況下，您可以將多個內建角色指派給安全組，為使用者提供適當的存取權。 但有時候，您無法使用內建角色，也必須遵守最低許可權存取，因為角色可能包含超過使用者所需許可權的許可權。 如需更細微的控制，請考慮建立自定義角色，以反映執行作業功能所需的特定許可權。 如需詳細資訊，請參閱 提供角色型授權。
許多 Azure 內建角色會在平台和資源層級提供預先定義的角色指派。 當您 結合數個角色指派時，請考慮整體效果。
Azure 登陸區域加速器包含數個常見系統管理功能的自定義角色。 您可以將這些角色與 Azure 內建角色搭配使用。 下表說明 Azure 登陸區域加速器的自訂系統管理角色或區域：
系統管理角色或區域 描述 動作 NotActions Azure 平台擁有者（例如內建擁有者角色） 管理管理群組和訂用帳戶生命週期 *訂用帳戶擁有者 訂用帳戶擁有者的委派角色 *Microsoft.Authorization/*/write、 、Microsoft.Network/vpnGateways/*
Microsoft.Network/expressRouteCircuits/*,
Microsoft.Network/routeTables/write,
Microsoft.Network/vpnSites/*應用程式擁有者（DevOps、應用程式作業） 訂用帳戶範圍的應用程式或作業小組參與者角色 *Microsoft.Authorization/*/write、 、Microsoft.Network/publicIPAddresses/writeMicrosoft.Network/virtualNetworks/write,Microsoft.KeyVault/locations/deletedVaults/purge/action網路管理 （NetOps） 管理全平臺的全局連線能力，例如虛擬網路、UDR、NSG、NVA、VPN、Azure ExpressRoute 及其他 */read,Microsoft.Network/*,
Microsoft.Resources/deployments/*,
Microsoft.Support/*安全性作業 （SecOps） 在整個 Azure 資產和 金鑰保存庫 清除原則之間具有水平檢視的安全性系統管理員角色 */read,
*/register/action,
Microsoft.KeyVault/locations/deletedVaults/purge/action,Microsoft.PolicyInsights/*,
Microsoft.Authorization/policyAssignments/*,Microsoft.Authorization/policyDefinitions/*,Microsoft.Authorization/policyExemptions/*,Microsoft.Authorization/policySetDefinitions/*,Microsoft.Insights/alertRules/*,
Microsoft.Resources/deployments/*,Microsoft.Security/*,Microsoft.Support/*這些角色可能需要額外的許可權，視責任模型而定。 例如，在某些組織中，NetOps 角色可能只需要管理和設定全域連線能力。 在需要更集中式方法的組織中，您可以使用更多允許的動作來擴充 NetOps 角色，例如在中樞與其輪輻之間建立對等互連。
角色指派和群組
當平臺小組布建應用程式登陸區域時，應該確保建立所有必要的身分識別和存取管理物件，例如安全組、標準角色指派，以及使用者指派的受控識別。
在訂用帳戶或資源群組範圍建立登陸區域角色指派。 Azure 原則 指派發生在管理群組範圍，因此您應該在較低範圍布建登陸區域角色指派。 使用此方法可確保登陸區域管理員對其資源具有完全的自主權，但無法修改管理其登陸區域的 Azure 原則 指派。
每個應用程式登陸區域都應該有自己的群組和角色指派。 請勿建立泛型群組，並將其指派給多個登陸區域。 這種方法可能會導致設定錯誤和安全性缺口，而且難以大規模管理。 如果使用者需要存取多個登陸區域，請將它們指派給每個登陸區域中的適當群組。 使用標識子治理來管理其群組成員資格。
將角色指派給群組，而不是指派給使用者。 這種方法有助於確保使用者在加入或離開組織時具有正確的許可權。 它也有助於確保使用者在小組之間移動時具有正確的許可權。 例如，如果使用者從網路小組移至安全性小組，您應該從網路群組中移除它們，並將其新增至安全組。 如果您將角色直接指派給用戶，他們會在移至不同的小組之後保留角色。 使用標識符控管來管理群組成員資格，而不是手動新增和移除群組成員。
針對相同應用程式的不同環境維護個別的安全性設定，例如開發/測試和生產環境。 為每個環境建立個別的群組和角色指派。 請勿跨環境共享受控識別或服務主體。 將每個環境視為個別的登陸區域。 這種方法有助於確保開發/測試與生產之間的隔離，並標準化在環境之間移動應用程式部署的程式。 如果相同的個人需要存取數個登陸區域，您應該將它們指派給每個登陸區域中的適當群組。
請考慮平臺管理員是否需要應用程式登陸區域的許可權。 如果是，請使用 Microsoft Entra PIM 來控制這些資源的存取權，並指派所需的最低許可權。 例如，平臺管理員可能需要存取特定應用程式登陸區域，以針對問題進行疑難解答，但不應該有應用程式數據或程式碼的例行存取權。 在此情況下，平臺管理員可以要求存取應用程式。 特殊許可權角色管理員會核准要求，且平臺管理員已獲授與指定時段的必要許可權。 這種方法有助於強制執行職責分離，並保護應用程式登陸區域免於意外或惡意設定錯誤。
當您將系統管理責任委派給其他人，例如應用程式小組時，請考慮它們是否需要完整的許可權集或只有子集。 遵循最低許可權原則（PoLP）。 例如，您可以將使用者存取系統管理員角色或 RBAC 系統管理員角色指派給需要管理 Azure 資源存取權但不需要自行管理資源的使用者。 若要限制使用者可以委派和指派 Azure RBAC 指派的身分識別、身分識別類型和角色，請使用 具有條件的委派角色指派。 應用程式小組可以使用條件，在平臺小組設定的條件內管理自己的安全性主體。 更多特殊許可權角色指派需要向平臺小組呈報。 當您使用條件委派 RBAC 角色時，請考慮下列因素：
檢閱內建和自定義特殊許可權角色的目前角色指派，並評估您是否應該將適當的條件新增至這些現有指派。 例如，您可以將條件新增至 Azure 登陸區域加速器所提供的訂用帳戶擁有者和應用程式擁有者自定義角色。 這些條件可以限制他們可以指派角色的主體類型，或限制他們可以指派的特定角色。
當您將條件新增至角色指派時，請遵循 PoLP。 例如，限制委派只將角色指派給群組，或讓委派指派除擁有者、使用者存取管理員和 RBAC 系統管理員等特殊許可權系統管理員角色以外的所有角色。
如果可用的條件範本不符合您的需求或原則，請建置您自己的條件。
下表顯示 Azure 登陸區域環境的範例角色指派結構。 它提供安全性與輕鬆管理之間的平衡。 您可以調整結構，以符合組織的需求。 您可以根據組織內的角色，將相同的個人指派給多個群組。 但是，您應該將 RBAC 指派套用至特定登陸區域內的特定群組。
資源 User 角色指派 工作分派目標 指派範圍 應用程式 X 登陸區域 應用程式 X 擁有者 應用程式擁有者（自定義，包含在 Azure 登陸區域加速器中） Application X Admins安全組應用程式 X 生產與開發/測試訂用帳戶 應用程式 X 登陸區域 應用程式 X 擁有者 應用程式存取管理員（自定義，具有角色指派條件來管理自己應用程式的存取權） Application X Admins安全組應用程式 X 生產與開發/測試訂用帳戶 應用程式 X 登陸區域 應用程式 X 資料管理員 資料管理員 （自訂，具有必要資料資源的權限） Application X Data Team安全組應用程式 X 生產與開發/測試訂用帳戶 應用程式 Y 登陸區域 應用程式 Y 擁有者 應用程式擁有者（自定義，包含在 Azure 登陸區域加速器中） Application Y Admins安全組應用程式 Y 生產與開發/測試訂用帳戶 應用程式 Y 登陸區域 應用程式 Y 測試小組 測試參與者 （自訂，具有應用程式測試所需的許可權） Application Y Test Team安全組應用程式 Y 開發/測試訂用帳戶 沙箱 應用程式 Z 開發小組 擁有者 （內建） Application Z developers安全組沙箱訂用帳戶中的應用程式 Z 資源群組 平台資源 平臺管理小組 參與者（內建） Platform AdminsPIM 群組Platform管理群組平臺登陸區域 平臺管理小組 讀者（內建） Platform Team安全組組織最上層管理群組 全租使用者 安全性小組 安全性作業（自定義，包含在 Azure 登陸區域加速器中） Security Ops安全組組織最上層管理群組 全租使用者 安全性小組 條件式存取管理員（內建且已啟用受保護動作） Security administrators安全組Microsoft Entra ID 租使用者 全租使用者 網路小組 網路作業 （自訂，包含在 Azure 登陸區域加速器中） Network Ops安全組所有訂用帳戶 全租使用者 FinOps 小組 計費讀者（內建） FinOps Team安全組組織最上層管理群組 Azure 原則 具有
DeployIfNotExists效果的指派需要受控識別來補救不符合規範的資源。 如果您使用系統指派的受控識別作為 Azure 原則 指派程式的一部分，Azure 會自動授與必要的許可權。 如果您使用使用者指派的受控識別，則必須手動授與許可權。 受控識別角色指派必須遵循PoLP，並只啟用必要的許可權，才能在目標範圍上執行原則補救。 原則補救受控識別不支援自定義角色定義。 將角色指派直接套用至受控識別，而不是套用至群組。
Microsoft Entra PIM 建議
使用 Microsoft Entra PIM 來符合 零信任 模型和最低許可權存取。 將組織的角色與所需的最低存取層級相互關聯。 在 Microsoft Entra PIM 中，您可以使用 Azure 原生工具、擴充現有的工具和程式，或視需要使用現有和原生工具。
使用 Microsoft Entra PIM 存取權檢閱 ，定期驗證資源權利。 存取權檢閱是眾多合規性架構的一部分，因此許多組織已經制定存取權檢閱流程。
針對需要提高訪問許可權或特殊許可權部署管線的自動化 Runbook 使用特殊許可權身分識別。 您可以使用相同的工具和原則來管理自動化工作流程，這些工作流程會存取您用來控管對等許可權使用者的重要安全性界限。 應用程式小組的自動化和部署管線應該具有角色指派，以防止應用程式擁有者提升自己的許可權。
控制高度特殊許可權的 Azure RBAC 角色，例如指派給訂用帳戶或管理群組上平臺或應用程式登陸區域小組成員的擁有者或使用者存取系統管理員。 針對群組使用 Microsoft Entra PIM 來設定 Azure RBAC 角色，因此它們需要與Microsoft Entra ID 角色相同的提高許可權程式。
例如，使用者通常會要求對應用程式登陸區域中的資源進行有限的系統管理存取。 有時候，他們可能需要擁有者角色。 您可以建立兩個安全組：應用程式管理員和應用程式擁有者。 將最低許可權角色指派給應用程式管理員群組，並將擁有者角色指派給應用程式擁有者角色。 使用 PIM 群組，讓使用者在需要時可以要求擁有者角色。 在所有其他情況下，使用者只有執行其一般活動所需的許可權。
搭配 使用受保護的動作 搭配 Microsoft Entra PIM 來新增額外的保護層。 在 Microsoft Entra ID 中，受保護的動作是指派 條件式存取原則的許可權。 當使用者嘗試執行受保護的動作時，他們必須先滿足指派給必要許可權的條件式存取原則。 例如，若要允許系統管理員更新跨租使用者存取設定，您可以要求他們先滿足 網路釣魚防護 MFA 原則。
Azure 登陸區域加速器中的身分識別和存取管理
身分識別和存取管理是 Azure 登陸區域加速器實作的核心功能。 部署包含專用於身分識別的訂用帳戶，其中組織可以部署AD DS域控制器或其他身分識別服務，例如其環境所需的 Microsoft Entra Connect 伺服器。 並非所有組織都需要訂用帳戶中的服務。 例如，某些組織可能會有已完全與 entra 識別符Microsoft整合的應用程式。
身分識別訂用帳戶具有與平臺訂用帳戶中中樞虛擬網路對等互連的虛擬網路。 透過此設定，平臺小組可以管理身分識別訂用帳戶，而應用程式擁有者可以視需要存取身分識別服務。 您必須保護身分識別訂用帳戶和虛擬網路，以保護身分識別服務免於未經授權的存取。
Azure 登陸區域加速器實作也包含下列選項：
- 指派建議的原則以控管身分識別和域控制器。
- 建立虛擬網路，並透過虛擬網路對等互連連線到中樞。