Azure 資源管理基本概念
請務必了解 Azure 資源特有的結構和字詞。 下圖顯示 Azure 所提供的四個範圍層級範例：
詞彙
以下是您應該熟悉的一些字詞：
資源 - 透過 Azure 提供的可管理項目。 虛擬機器、儲存體帳戶、Web 應用程式、資料庫和虛擬網路都是資源範例。
資源群組 - 保存 Azure 解決方案相關資源的容器，例如虛擬機器集合、相關聯的 VNet，以及需要特定小組管理的負載平衡器。 資源群組包括您想要以群組形式管理的資源。 您可以根據最適合您組織的方式，決定哪些資源屬於資源群組。 資源群組也可以用來協助生命週期管理，方法是一次刪除所有具有相同生命週期的資源。 此方式也提供安全性優勢，方法是不留下可能遭到惡意探索的片段。
訂用帳戶 - 從組織階層的觀點來看，訂用帳戶是資源和資源群組的計費和管理容器。 Azure 訂用帳戶與 Microsoft Entra ID 具有信任關係。 訂閱信任 Microsoft Entra ID 以驗證使用者、服務和裝置。
注意
訂用帳戶只能信任一個 Microsoft Entra 租用戶。 不過，每個租用戶都可能會信任多個訂用帳戶，而訂用帳戶可以在租用戶之間移動。
管理群組 - Azure 管理群組提供階層式方法，可在訂用帳戶上方的不同範圍套用原則和合規性。 其可以位於租用戶根管理群組 (最高範圍) 或階層中的較低層級。 您要將訂用帳戶整理到稱為「管理群組」的容器，並將治理條件套用至管理群組。 管理群組內的所有訂用帳戶都會自動繼承套用到管理群組的條件。 請注意，原則定義可以套用至管理群組或訂用帳戶。
資源提供者 - 提供 Azure 資源的服務。 例如，常見的資源提供者是 Microsoft。 計算，其提供虛擬機器資源。 Microsoft。 儲存體是另一個常見的資源提供者。
Resource Manager 範本 - JavaScript 物件標記法 (JSON) 檔案，可定義一或多個要部署至資源群組、訂用帳戶、租用戶或管理群組的資源。 範本可用於一致並且重複地部署資源。 請參閱範本部署概觀。 此外，可以使用 Bicep 語言，而非 JSON。
Azure 資源管理模型
每個 Azure 訂用帳戶都會與 Azure Resource Manager 所使用的控制項相關聯。 Resource Manager 是 Azure 的部署和管理服務，其針對組織，與 Microsoft Entra ID 具有信任關係以進行身分識別管理，並針對個人，與 Microsoft 帳戶 (MSA) 具有信任關係。 Resource Manager 提供管理層，可讓您建立、更新和刪除您 Azure 訂用帳戶中的資源。 您可以使用存取控制、鎖定和標記這類管理功能，以在部署後保護和組織您的資源。
注意
在 ARM 之前，有另一個名為 Azure Service Manager (ASM) 或「傳統」的部署模型。 若要深入了解，請參閱 Azure Resource Manager 與傳統部署。 使用 ASM 模型來管理環境不在此內容的範圍內。
Azure Resource Manager 是前端服務，可裝載 PowerShell、Azure 入口網站或其他用戶端用來管理資源的 REST API。 用戶端要求管理特定資源時，Resource Manager 會將要求 Proxy 處理至資源提供者，以完成要求。 例如，如果用戶端要求管理虛擬機器資源，則 Resource Manager 會將要求 Proxy 處理至 Microsoft。 計算資源提供者。 Resource Manager 要求用戶端要同時指定訂用帳戶和資源群組的識別碼，才能管理虛擬機器資源。
在 Resource Manager 可以執行任何資源管理要求之前，會檢查一組控制項。
有效的使用者檢查 - 要求管理資源的使用者必須在與受控資源的訂用帳戶相關聯的 Microsoft Entra 租用戶中擁有帳戶。
使用者權限檢查 - 使用角色型存取控制 (RBAC) 將權限指派給使用者。 RBAC 角色指定了一組權限，使用者可能會在特定資源上採用那些權限。 RBAC 可協助您管理可存取 Azure 資源的人員、這些人員如何使用資源，以及其可存取的區域。
Azure 原則檢查 - Azure 原則指定特定資源允許或明確拒絕的作業。 例如，原則可以指定只允許 (或不允許) 使用者部署特定類型的虛擬機器。
下圖摘要說明我們剛剛說明的資源模型。
Azure Lighthouse - Azure Lighthouse 可跨租用戶進行資源管理。 組織可以將訂用帳戶或資源群組層級的角色委派給另一個租用戶中的身分識別。
使用 Azure Lighthouse 啟用委派資源管理的訂用帳戶具有屬性，可指出可管理訂用帳戶或資源群組的租用戶識別碼，以及資源租用戶中內建 RBAC 角色與服務提供者租用戶中身分識別之間的對應。 在執行階段，Azure Resource Manager 將會取用這些屬性以授權來自服務提供者租用戶的權杖。
值得注意的是，Azure Lighthouse 本身會模型化為 Azure 資源提供者，這表示可以透過 Azure 原則將目標設為跨租用戶的委派各個層面。
Microsoft 365 Lighthouse - Microsoft 365 Lighthouse 是管理入口網站，可協助受控服務提供者 (MSP) 使用 Microsoft 365 商務進階版、Microsoft 365 E3 或 Windows 365 商務版的中小型企業 (SMB) 客戶，大規模保護和管理裝置、資料和使用者。
使用 Microsoft Entra ID 的 Azure 資源管理
既然您已進一步了解 Azure 中的資源管理模型，讓我們簡短地檢查 Microsoft Entra ID 的一些功能，以提供 Azure 資源的身分識別和存取管理。
計費
計費對於資源管理十分重要，因為某些計費角色會與資源互動或可以管理資源。 計費方式會根據您與 Microsoft 的合約類型而不同。
Azure Enterprise 合約
Azure Enterprise 合約 (Azure EA) 客戶會在執行與 Microsoft 的商業合約時上線至 Azure EA 入口網站。 上線時，身分識別會與「根」企業管理員計費角色相關聯。 入口網站提供管理功能的階層：
部門可協助您將成本分割成邏輯群組，並可讓您在部門層級設定預算或配額。
帳戶用來進一步區隔部門。 您可以使用帳戶來管理訂用帳戶，以及存取報表。 EA 入口網站可以授權 Microsoft 帳戶 (MSA) 或 Microsoft Entra 帳戶 (在入口網站中識別為「公司或學校帳戶」)。 EA 入口網站中具有「帳戶擁有者」角色的身分識別可以建立 Azure 訂用帳戶。
企業計費和 Microsoft Entra 租用戶
帳戶擁有者在企業合約內建立 Azure 訂用帳戶時，訂用帳戶的身分識別和存取管理設定如下：
Azure 訂用帳戶會與帳戶擁有者的相同 Microsoft Entra 租用戶相關聯。
已建立訂用帳戶的帳戶擁有者將會獲指派服務管理員和帳戶管理員角色。 (Azure EA 入口網站會指派 Azure Service Manager (ASM) 或「傳統」角色來管理訂用帳戶。 若要深入了解，請參閱 Azure Resource Manager 與傳統部署。)
在 Azure EA 入口網站中設定 [跨租用戶的公司或學校帳戶] 驗證類型，以將企業合約設定為支援多個租用戶。 根據上述內容，組織可以為每個租用戶設定多個帳戶，並為每個帳戶設定多個訂用帳戶，如下圖所示。
請務必注意，上述的預設設定會授與 Azure EA 帳戶擁有者權限，以管理其所建立的任何訂用帳戶中的資源。 針對持有生產工作負載的訂用帳戶，請考慮在建立後立即變更訂用帳戶的服務管理員來分離計費和資源管理。
若要進一步分離並防止帳戶擁有者重新取得訂用帳戶的服務管理員存取權，可以在建立之後變更訂用帳戶的租用戶。 如果帳戶擁有者在 Microsoft Entra 租用戶中沒有將訂用帳戶移入其中的使用者物件，則無法重新取得服務擁有者角色。
若要深入了解，請參閱 Azure 角色、Microsoft Entra 角色和傳統訂用帳戶管理員角色。
Microsoft 客戶合約
使用 Microsoft 客戶合約 (MCA) 所註冊的客戶會有不同的計費管理系統和其自己的角色。
Microsoft 客戶合約的計費帳戶包含一或多個可管理發票和付款方式的計費設定檔。 每個計費設定檔都會包含一或多個發票區段，以組織計費設定檔發票上的成本。
在 Microsoft 客戶合約中，計費角色來自單一 Microsoft Entra 租用戶。 若要為多個租用戶佈建訂用帳戶，一開始必須先在與 MCA 相同的 Microsoft Entra 租用戶中建立訂用帳戶，然後進行變更。 在下圖中，公司 IT 生產前環境的訂用帳戶已在建立之後移至 ContosoSandbox 租用戶。
Azure 中的 RBAC 和角色指派
在＜Microsoft Entra 基本概念＞一節中，您已了解 Azure RBAC 是授權系統，可提供更精細的 Azure 資源存取管理，並且包括許多內建角色。 您可以建立自訂角色，並在不同的範圍指派角色。 將 RBAC 角色指派給要求存取 Azure 資源的物件，以強制執行權限。
Microsoft Entra 角色的操作與 Azure 角色型存取控制這類概念類似。 這兩種角色型存取控制系統的差異在於 Azure RBAC 會使用 Azure 資源管理來控制對 Azure 資源 (例如虛擬機器或儲存體) 的存取，而 Microsoft Entra 角色則控制對 Microsoft Entra ID、應用程式和 Microsoft 服務 (例如 Office 365) 的存取。
Microsoft Entra 角色和 Azure RBAC 角色都會與 Microsoft Entra Privileged Identity Management 整合，以啟用 Just-In-Time 啟用原則，例如核准工作流程和 MFA。
Azure 中的 RBAC 和角色指派
屬性型存取控制 (ABAC) 是一種授權系統，可根據與安全性主體、資源和環境相關聯的屬性來定義存取權。 透過 ABAC，您可以根據屬性以授與安全性主體對資源的存取權。 Azure ABAC 是指適用於 Azure 的 ABAC 實作。
Azure ABAC 會根據特定動作內容中的屬性新增角色指派條件，以在 Azure RBAC 上建立。 角色指派條件是額外的檢查，您可以選擇性地將其新增至您的角色指派，以提供更精細的存取控制。 條件會篩選出角色定義和角色指派期間所授與的權限。 例如，您可以新增需要物件具有特定標記才能讀取物件的條件。 您無法使用條件明確地拒絕存取特定資源。
條件式存取
Microsoft Entra 條件式存取可以用來管理對 Azure 管理端點的存取。 條件式存取原則可以套用至 Windows Azure Service 管理 API 雲端應用程式，以保護 Azure 資源管理端點，例如：
Azure Resource Manager 提供者 (服務)
Azure Resource Manager API
Azure PowerShell
Azure CLI
Azure 入口網站
例如，管理員可以設定條件式存取原則，讓使用者只能從已核准的位置登入 Azure 入口網站，同時需要多重要素驗證 (MFA) 或已加入混合式 Microsoft Entra 網域的裝置。
Azure 受控身分識別
建置雲端應用程式常見的難題是如何管理程式碼中的認證，以向雲端服務進行驗證。 保護好這些認證是相當重要的工作。 在理想情況下，這些認證永不會出現在開發人員工作站且簽入原始程式碼控制。 資源的受控身分識別會在 Microsoft Entra ID 中為 Azure 服務提供自動受控身分識別。 您可以使用身分識別向任何支援 Microsoft Entra 驗證的服務進行驗證，不需要任何您程式碼中的認證。
受控身分識別有兩種：
系統指派的受控身分識別會直接在 Azure 資源上予以啟用。 啟用資源時，Azure 會在相關聯訂用帳戶的受信任 Microsoft Entra 租用戶中建立資源的身分識別。 建立身分識別之後，會將認證佈建至資源。 系統指派的身分識別生命週期會直接繫結至 Azure 資源。 如果資源已遭刪除，則 Azure 會自動清除 Microsoft Entra ID 中的認證和身分識別。
使用者指派的受控識別會以獨立 Azure 資源的形式建立。 Azure 會在 Microsoft Entra 租用戶中建立身分識別，而與資源相關聯的訂用帳戶信任此租用戶。 身分識別在建立之後，可以指派給一或多個 Azure 資源。 使用者指派的身分識別與獲指派此身分識別的 Azure 資源，兩者的生命週期分開管理。
就內部而言，受控身分識別是特殊類型的服務主體，僅供特定 Azure 資源使用。 刪除受控識別後，對應的服務主體也會自動移除。 請注意，Graph API 權限的授權只能透過 PowerShell 完成，因此無法透過入口網站 UI 存取受控身分識別的所有功能。
Microsoft Entra 網域服務
Microsoft Entra Domain Services 提供受控網域，以協助使用舊版通訊協定來驗證 Azure 工作負載。 支援的伺服器會從內部部署 AD DS 樹系移至並加入 Microsoft Entra Domain Services 受控網域，並繼續使用舊版通訊協定進行驗證 (例如 Kerberos 驗證)。
Azure AD B2C 目錄和 Azure
Azure AD B2C 租用戶會連結至 Azure 訂用帳戶，以進行計費和通訊。 Azure AD B2C 租用戶在目錄中具有獨立式角色結構，而這與 Azure 訂用帳戶的 Azure RBAC 特殊權限角色無關。
一開始佈建 Azure AD B2C 租用戶時，建立 B2C 租用戶的使用者必須在訂用帳戶中具有參與者或擁有者權限。 他們稍後可以建立其他帳戶，並將其指派給目錄角色。 如需範圍的相關詳細資訊，請參閱 Microsoft Entra ID 中角色型存取控制 (RBAC) 的概觀。
請務必注意，已連結 Microsoft Entra 訂用帳戶的擁有者和參與者可以移除訂用帳戶與目錄之間的連結，而這會影響 Azure AD B2C 使用量的持續計費。
Azure 中 IaaS 解決方案的身分識別考量
此案例涵蓋組織針對基礎結構即服務 (IaaS) 工作負載所擁有的身分識別隔離需求。
IaaS 工作負載隔離管理有三個主要選項：
已加入獨立 Active Directory Domain Services (AD DS) 的虛擬機器
已加入 Microsoft Entra Domain Services 的虛擬機器
使用 Microsoft Entra 驗證登入 Azure 中的虛擬機器
解決前兩個選項的重要概念，是這些案例涉及兩個身分識別領域。
當您透過遠端桌面通訊協定 (RDP) 登入 Azure Windows Server VM 時，一般會使用網域認證來登入至伺服器，這會對內部部署 AD DS 網域控制站或 Microsoft Entra Domain Service 執行 Kerberos 驗證。 或者，如果伺服器未加入網域，則可以使用本機帳戶來登入虛擬機器。
當您登入 Azure 入口網站以建立或管理 VM 時，將會針對 Microsoft Entra ID 進行驗證 (如果您已同步正確的帳戶，則可能會使用相同的認證)，而且這可能會導致針對您網域控制站進行驗證 (如果您要使用 Active Directory 同盟服務 (AD FS) 或 PassThrough Authentication)。
已加入獨立 Active Directory Domain Services 的虛擬機器
AD DS 是 Windows Server 型目錄服務，而組織已針對內部部署身分識別服務大量採用此服務。 需要將 IaaS 工作負載部署至 Azure 時，可以部署 AD DS，而 IaaS 工作負載需要與另一個樹系中的 AD DS 管理員和使用者隔離身分識別。
在此案例中，需要考慮下列事項：
AD DS 網域控制站：至少必須部署兩個 AD DS 網域控制站，以確保驗證服務具有高可用性且高效能。 如需詳細資訊，請參閱 AD DS 設計和規劃。
AD DS 設計和規劃 - 必須建立新的 AD DS 樹系，且其已正確設定下列服務：
AD DS 網域名稱服務 (DNS) - 必須針對 AD DS 內的相關區域設定 AD DS DNS，以確保伺服器和應用程式的名稱解析正確運作。
AD DS 網站和服務 - 必須設定這些服務，以確保應用程式具有低延遲且高效能的網域控制站存取。 伺服器所在的相關虛擬網路、子網路和資料中心位置應該在網站和服務中進行設定。
AD DS FSMO - 應該檢閱所需的彈性單一主機作業 (FSMO) 角色，並將其指派給適當的 AD DS 網域控制站。
AD DS 網域加入 - 所有需要 AD DS 以進行驗證、設定和管理的伺服器 (排除 "jumpboxes") 都需要加入隔離式樹系。
AD DS 群組原則 (GPO) - 必須設定 AD DS GPO，以確保設定符合安全性需求，而且設定已跨樹系和已加入網域的機器標準化。
AD DS 組織單位 (OU) - 必須定義 AD DS OU，以確保將 AD DS 資源分組為邏輯管理和設定定址接收器，來管理和套用設定。
角色型存取控制 - 必須定義 RBAC，才能管理和存取已加入此樹系的資源。 這包括：
AD DS 群組 - 必須建立群組，才能將使用者的適當權限套用至 AD DS 資源。
管理帳戶 - 如本節開頭所述，管理此解決方案需要兩個管理帳戶。
AD DS 管理帳戶，具有執行 AD DS 和已加入網域之伺服器所需的管理所需的最低特殊權限存取權。
進行 Azure 入口網站存取的 Microsoft Entra 管理帳戶，可連線、管理以及設定虛擬機器、VNet、網路安全性群組和其他必要 Azure 資源。
AD DS 使用者帳戶 - 需要將相關的使用者帳戶佈建和新增至正確的群組，以允許使用者存取此解決方案所裝載的應用程式。
虛擬網路 (VNet) - 設定指導
AD DS 網域控制站 IP 位址 - 不應該在作業系統內設定網域控制站的靜態 IP 位址。 Azure VNet 上應該保留 IP 位址，以確保其一律保持相同，而且 DC 應該設定為使用 DHCP。
VNet DNS 伺服器 - 必須在屬於此隔離式解決方案的 VNet 上設定 DNS 伺服器，才能指向網域控制站。 這是必要項目，以確保應用程式和伺服器可以解析已加入 AD DS 樹系的必要 AD DS 服務或其他服務。
網路安全性群組 (NSG) - 網域控制站應該位於自己的 VNet 或子網路上，其中將 NSG 定義為只允許從必要伺服器 (例如，已加入網域的機器或 jumpbox) 存取網域控制站。 Jumpboxes 應該新增至應用程式安全性群組 (ASG)，以簡化 NSG 建立和管理。
挑戰：下面的清單強調使用此選項進行身分識別隔離的主要挑戰：
管理和監視的額外 AD DS 樹系，讓 IT 小組能夠執行更多工作。
可能需要進一步的基礎結構，才能管理修補和軟體部署。 組織應該考慮部署 Azure 更新管理、群組原則 (GPO) 或System Center Configuration Manager (SCCM) 來管理這些伺服器。
讓使用者記住並用來存取資源的其他認證。
重要
針對此隔離式模型，假設客戶公司網路與網域控制站之間沒有連線，而且未設定與其他樹系的信任。 應該建立 Jumpbox 或管理伺服器，以允許可以從中管理 AD DS 網域控制站的位置。
已加入 Microsoft Entra Domain Services 的虛擬機器
如果需要將 IaaS 工作負載部署至 Azure，而 Azure 需要與 AD DS 管理員和另一個樹系中的使用者來進行身分識別隔離，則可以部署 Microsoft Entra Domain Services 受控網域。 Microsoft Entra Domain Services 是一種服務，提供受控網域，以協助使用舊版通訊協定來驗證 Azure 工作負載。 這可提供隔離式網域，而不需要建置和管理您自己的 AD DS 的技術複雜度。 需要考慮下列事項。
Microsoft Entra Domain Services 受控網域 - 每個 Microsoft Entra 租用戶只能部署一個 Microsoft Entra Domain Services 受控網域，而且這會繫結至單一 VNet。 建議此 VNet 形成進行 Microsoft Entra Domain Services 驗證的「中樞」。 從此中樞，可以建立「輪輻」，並將其連結以允許伺服器和應用程式的舊版驗證。 輪輻是已加入 Microsoft Entra Domain Services 的伺服器所在的額外 VNet，並且使用 Azure 網路閘道或 VNet 對等互連來連結至中樞。
受控網域位置 - 部署 Microsoft Entra Domain Services 受控網域時，必須設定位置。 此位置是受控網域部署所在的實體區域 (資料中心)。 建議您：
請考慮地理上接近伺服器和應用程式的位置，而伺服器和應用程式需要 Microsoft Entra Domain Services 服務。
請考慮使用可提供可用性區域功能以滿足高可用性需求的區域。 如需詳細資訊，請參閱 Azure 中的區域和可用性區域。
物件佈建 - Microsoft Entra Domain Services 會同步處理與部署 Microsoft Entra Domain Services 之訂用帳戶相關聯的 Microsoft Entra ID 身分識別。 也值得注意的是，如果已設定相關聯的 Microsoft Entra ID 與 Microsoft Entra Connect 進行同步 (使用者樹系案例)，則這些身分識別的生命週期也可以反映在 Microsoft Entra Domain Services 中。 此服務有兩種模式，可用於從 Microsoft Entra ID 佈建使用者和群組物件。
所有：所有使用者和群組都會從 Microsoft Entra ID 同步處理至 Microsoft Entra Domain Services。
範圍：只有一定範圍群組中的使用者會從 Microsoft Entra ID 同步處理至 Microsoft Entra Domain Services。
第一次部署 Microsoft Entra Domain Services 時，系統會設定自動單向同步從 Microsoft Entra ID 複寫物件。 此單向同步會在背景持續執行，使 Microsoft Entra Domain Services 受控網域隨 Microsoft Entra ID 的任何變更而更新，以保持在最新狀態。 不會從 Microsoft Entra Domain Services 往回同步處理到 Microsoft Entra ID。 如需詳細資訊，請參閱如何在 Microsoft Entra Domain Services 受控網域中同步物件和認證。
值得注意的是，如果您需要將同步類型從 [全部] 變更為 [已設定範圍] (反之亦然)，則需要刪除、重新建立和設定 Microsoft Entra Domain Services 受控網域。 此外，不錯的做法是組織應該考慮使用「已設定範圍」佈建，以將身分識別降低為只需要存取 Microsoft Entra Domain Services 資源的身分識別。
群組原則物件 (GPO) - 若要在 Microsoft Entra Domain Services 受控網域中設定 GPO，您必須在網域已加入 Microsoft Entra Domain Services 受控網域的伺服器上使用群組原則管理工具。 如需詳細資訊，請參閱管理 Microsoft Entra Domain Services 受控網域中的群組原則。
安全 LDAP - Microsoft Entra Domain Services 提供安全 LDAP 服務，可供需要此服務的應用程式使用。 預設會停用此設定，而且為了啟用安全 LDAP，需要上傳憑證，此外，保護 Microsoft Entra Domain Services 部署所在 VNet 的 NSG 必須允許連接埠 636 連線至 Microsoft Entra Domain Services 受控網域。 如需詳細資訊，請參閱為 Microsoft Entra Domain Services 受控網域設定安全 LDAP (英文)。
管理 - 若要在 Microsoft Entra Domain Services 上執行管理職責 (例如，機器加入網域或編輯 GPO)，用於這項工作的帳戶需要是 Microsoft Entra DC 管理員群組的一部分。 屬於此群組成員的帳戶無法直接登入網域控制站來執行管理工作。 相反地，您會建立已加入 Microsoft Entra Domain Services 受控網域的管理 VM，然後安裝您的一般 AD DS 管理工具。 如需詳細資訊，請參閱 Microsoft Entra Domain Services 中使用者帳戶、密碼與系統管理的管理概念。
密碼雜湊 - 若要使用 Microsoft Entra Domain Services 進行驗證，所有使用者的密碼雜湊格式都需要適用於 NT LAN Manager (NTLM) 和 Kerberos 驗證。 若要確保 Microsoft Entra Domain Services 的驗證如預期般運作，需要執行下列必要條件。
與 Microsoft Entra Connect 同步的使用者 (從 AD DS) - 舊版密碼雜湊需要從內部部署 AD DS 同步至 Microsoft Entra ID。
在 Microsoft Entra ID 中建立的使用者 - 需要重設其密碼，才能產生與 Microsoft Entra Domain Services 搭配使用的正確雜湊。 如需詳細資訊，請參閱啟用密碼雜湊的同步。
網路 - Microsoft Entra Domain Services 會部署至 Azure VNet，因此需要進行考量以確保伺服器和應用程式受到保護，而且可以正確地存取受控網域。 如需詳細資訊，請參閱 Microsoft Entra Domain Services 的虛擬網路設計考量和設定選項。
Microsoft Entra Domain Services 必須部署至自己的子網路：請不要使用現有的子網路或閘道子網路。
網路安全性群組 (NSG) - 是在部署 Microsoft Entra Domain Services 受控網域時所建立。 此網路安全性群組包含正確的服務通訊所需的規則。 請勿使用您本身的自訂規則來建立或使用現有的網路安全性群組。
Microsoft Entra Domain Services 需要 3-5 個 IP 位址 - 請確定子網路 IP 位址範圍可以提供此數目的位址。 限制可用的 IP 位址可防止 Microsoft Entra Domain Services 維護兩個網域控制站。
VNet DNS 伺服器 - 如先前對「中樞和輪輻」模型的討論，請務必在 VNet 上正確設定 DNS，以確保加入 Microsoft Entra Domain Services 受控網域的伺服器具有可解析 Microsoft Entra Domain Services 受控網域的正確 DNS 設定。 每個 VNet 都會有一個 DNS 伺服器項目，而此項目會在伺服器取得 IP 位址時傳遞給伺服器，而且這些 DNS 項目需要是 Microsoft Entra Domain Services 受控網域的 IP 位址。 如需詳細資訊，請參閱更新 Azure 虛擬網路的 DNS 設定。
挑戰 - 下列清單強調使用此選項進行身分識別隔離的主要挑戰。
某些 Microsoft Entra Domain Services 設定只能從加入 Microsoft Entra Domain Services 的伺服器中進行管理。
每個 Microsoft Entra 租用戶中只能部署一個 Microsoft Entra Domain Services 受控網域。 如本節所述，建議使用中樞和輪輻模型，以將 Microsoft Entra Domain Services 驗證提供給其他 VNet 上的服務。
可能需要進一步的基礎結構，才能管理修補和軟體部署。 組織應該考慮部署 Azure 更新管理、群組原則 (GPO) 或System Center Configuration Manager (SCCM) 來管理這些伺服器。
針對此隔離模型，假設未從客戶公司網路連線至裝載 Microsoft Entra Domain Services 受控網域的 VNet，而且未設定與其他樹系的信任。 應該建立 Jumpbox 或管理伺服器，以允許可以從中管理 Microsoft Entra Domain Services 的位置。
使用 Microsoft Entra 驗證登入 Azure 中的虛擬機器
需要將 IaaS 工作負載部署至需要身分識別隔離的 Azure 時，在此案例中，最後一個選項是使用 Microsoft Entra ID 來登入伺服器。 這可讓您將 Microsoft Entra ID 設為驗證用途的身分識別領域，並將伺服器佈建至相關的訂用帳戶，以達成身分識別隔離，而此訂用帳戶會連結至所需的 Microsoft Entra 租用戶。 需要考慮下列事項。
支援的作業系統：Windows 和 Linux 目前支援使用 Microsoft Entra 驗證來登入 Azure 中的虛擬機器。 如需所支援作業系統的更多細節，請參閱 Windows 和 Linux 的文件。
認證：使用 Microsoft Entra 驗證登入 Azure 中虛擬機器的其中一個主要優點，是能夠使用相同的同盟或受控 Microsoft Entra 認證，而您通常會使用這些認證來存取 Microsoft Entra 服務，以登入虛擬機器。
注意
此案例中用於登入的 Microsoft Entra 租用戶是與訂用帳戶相關聯的 Microsoft Entra 租用戶，而此訂用帳戶中已佈建虛擬機器。 此 Microsoft Entra 租用戶可以是具有從內部部署 AD DS 同步的身分識別的租用戶。 選擇組織想要用於登入這些伺服器的訂用帳戶和 Microsoft Entra 租用戶時，組織應該做出明智的選擇，以符合其隔離主體。
網路需求：這些虛擬機器將需要存取 Microsoft Entra ID 以進行驗證，因此您必須確定虛擬機器網路設定允許在 443 上對 Microsoft Entra 端點進行輸出存取。 如需詳細資訊，請參閱 Windows 和 Linux 的文件。
角色型存取控制 (RBAC)：有兩個 RBAC 角色可提供這些虛擬機器的適當存取權層級。 這些 RBAC 角色可以透過 Azure 入口網站或 Azure Cloud Shell 體驗進行設定。 如需詳細資訊，請參閱設定 VM 的角色指派。
虛擬機器管理員登入：獲指派此角色的使用者可以使用管理員權限來登入 Azure 虛擬機器。
虛擬機器使用者登入：獲指派此角色的使用者可以使用一般使用者權限來登入 Azure 虛擬機器。
條件式存取：使用 Microsoft Entra ID 登入 Azure 虛擬機器的主要優點，在於能夠於登入程序期間強制執行條件式存取。 這可讓組織在允許存取虛擬機器之前需要符合條件，以及使用多重要素驗證來提供強式驗證。 如需詳細資訊，請參閱使用條件式存取。
注意
僅允許從下列項目遠端連線至已加入 Microsoft Entra ID 的虛擬機器：從 Windows 10、Windows 11，以及已加入 Microsoft Entra 或已加入 Microsoft Entra 混合式的雲端電腦到與虛擬機器相同的目錄。
挑戰：下面的清單強調使用此選項進行身分識別隔離的主要挑戰。
未集中管理或設定伺服器。 例如，沒有群組原則可以套用至一組伺服器。 組織應該考慮在 Azure 中部署更新管理，以管理這些伺服器的修補和更新。
不適用於多層式應用程式，而這類應用程式需要使用內部部署機制以跨這些伺服器或服務來進行驗證 (例如 Windows 整合式驗證)。 如果這是組織的需求，則建議您探索獨立 Active Directory Domain Services，或本節所述的 Microsoft Entra Domain Services 案例。
針對此隔離式模型，假設沒有從客戶公司網路到裝載虛擬機器的 VNet 連線。 應該建立 Jumpbox 或管理伺服器，以允許可以從中管理這些伺服器的位置。