Azure 资源管理基础知识
了解特定于 Azure 资源的结构和术语非常重要。 下图显示的示例演示了 Azure 提供的四个范围级别：
术语
下面是应熟悉的一些术语：
资源 - 可通过 Azure 获取的可管理项。 资源的示例包括虚拟机、存储帐户、Web 应用、数据库和虚拟网络。
资源组 - 一个容器，用于保存 Azure 解决方案的相关资源，例如一组需要由特定团队进行管理的虚拟机、关联的 VNet 和负载均衡器。 资源组包括你想要将其作为一个组进行管理的那些资源。 根据最适合组织的情况来决定哪些资源属于哪个资源组。 资源组还可用于帮助进行生命周期管理，方法是一次删除具有相同生存期的所有资源。 此方法不保留可能被利用的片段，因此还具有安全优势。
订阅 - 从组织层次结构的角度来看，订阅是资源和资源组的计费和管理容器。 Azure 订阅与 Microsoft Entra ID 存在信任关系。 订阅信任 Microsoft Entra ID 对用户、服务和设备执行身份验证。
注意
一个订阅只能信任一个 Microsoft Entra 租户。 但是，每个租户可以信任多个订阅，订阅可以在租户之间移动。
管理组 - Azure 管理组提供在订阅上方的不同范围应用策略和合规性的分层方法。 它可以位于租户根管理组（最高的范围）或层次结构中的较低级别。 可将订阅组织到名为“管理组”的容器中，并将管理条件应用到管理组。 管理组中的所有订阅都将自动继承应用于管理组的条件。 请注意，策略定义可以应用于管理组或订阅。
资源提供程序 - 提供 Azure 资源的服务。 例如，常见的资源提供程序是 Microsoft. Compute，提供虚拟机资源。 Microsoft. Storage 是另一个常见的资源提供程序。
资源管理器模板 - 一个 JavaScript 对象表示法 (JSON) 文件，用于定义一个或多个要部署到资源组、订阅、租户或管理组的资源。 使用模板能够以一致方式反复部署资源。 请参阅模板部署概述。 此外，可以使用 Bicep 语言而非 JSON。
Azure 资源管理模型
每个 Azure 订阅还与 Azure 资源管理器使用的控制相关联。 资源管理器是 Azure 的部署和管理服务，它与 Microsoft Entra ID 建立用于组织标识管理的信任关系，并为个人提供 Microsoft 帐户 (MSA)。 资源管理器提供一个管理层，用于在 Azure 订阅中创建、更新和删除资源。 部署后，请使用访问控制、锁和标记等管理功能来保护和组织资源。
注意
在 ARM 之前，还有一个名为 Azure 服务管理器 (ASM) 或“经典”的部署模型。 若要了解更多信息，请参阅 Azure 资源管理器部署与经典部署。 使用 ASM 模型管理环境不在此内容的范围内。
Azure 资源管理器是前端服务，它托管供 PowerShell、Azure 门户或其他客户端用来管理资源的 REST API。 当客户端发出管理特定资源的请求时，资源管理器会以代理身份向资源提供程序发出请求来完成该请求。 例如，如果客户端发出管理虚拟机资源的请求，则资源管理器会以代理身份将请求发给 Microsoft. Compute 资源提供程序。 资源管理器要求客户端，必须指定订阅和资源组的标识符，才能管理虚拟机资源。
在资源管理器执行任何资源管理请求之前，需要先检查一组控制。
有效用户检查 - 请求管理资源的用户必须在 Microsoft Entra 租户中有一个与受管理资源的订阅关联的帐户。
用户权限检查 - 权限是使用基于角色的访问控制 (RBAC) 分配给用户的。 RBAC 角色指定用户对特定的资源拥有的一组权限。 RBAC 有助于管理谁有权访问 Azure 资源、这些人可以对这些资源执行哪些操作，以及他们有权访问哪些区域。
Azure 策略检查 - Azure 策略指定允许的或显式拒绝的针对特定资源的操作。 例如，策略可以指定只允许（或不允许）用户部署特定类型的虚拟机。
下图汇总了我们刚才介绍的资源模型。
Azure Lighthouse - Azure Lighthouse 支持跨租户资源管理。 组织可以在订阅或资源组级别将角色委托给另一租户中的标识。
支持使用 Azure Lighthouse 进行委托资源管理的订阅具有特定的属性，这些属性指示那些可以管理订阅或资源组的租户 ID，以及资源租户中的内置 RBAC 角色与服务提供商租户中的标识之间的映射。 在运行时，Azure 资源管理器会使用这些属性为来自服务提供商租户的令牌授权。
值得注意的是，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 企业协议
Azure 企业协议 (Azure EA) 客户在执行其与 Microsoft 签订的商业合同后加入 Azure EA 门户。 加入后，标识将关联到“根”企业管理员计费角色。 门户提供管理功能的层次结构：
“部门”有助于将成本细分到逻辑分组中，使你可以在部门级别设置预算或配额。
帐户用于进一步细分部门。 可以使用帐户来管理订阅和访问报表。 EA 门户可以为 Microsoft 帐户 (MSA) 或 Microsoft Entra 帐户（在门户中标识为“工作或学校帐户”）授权。 EA 门户中具有“帐户所有者”角色的标识可以创建 Azure 订阅。
企业计费和 Microsoft Entra 租户
当帐户所有者在企业协议中创建 Azure 订阅时，将按如下所示方式配置订阅的标识和访问管理：
Azure 订阅与帐户所有者的 Microsoft Entra 租户相关联。
创建了订阅的帐户所有者会被分配服务管理员和帐户管理员角色。 （Azure EA 门户分配 Azure 服务管理器 (ASM) 角色或“经典”角色来管理订阅。 若要了解详细信息，请参阅 Azure 资源管理器部署与经典部署。
可以通过在 Azure EA 门户中设置“跨租户工作或学校帐户”身份验证类型，将企业协议配置为支持多个租户。 因此，组织可以为每个租户设置多个帐户，并为每个帐户设置多个订阅，如下图所示。
请务必注意，上述默认配置授予 Azure EA 帐户所有者权限，用于管理其创建的任何订阅中的资源。 对于包含生产工作负荷的订阅，请考虑在创建订阅后立即更改订阅的服务管理员，通过这种方式将计费和资源管理分离开来。
要进一步分离帐户所有者并阻止其重新获得订阅的服务管理员访问权限，可以在创建订阅后更改订阅的租户。 如果帐户所有者在 Microsoft Entra 租户中没有可供订阅移动到其中的用户对象，则该所有者无法重新获得服务所有者角色。
若要了解详细信息，请访问 Azure 角色、Microsoft Entra 角色和经典订阅管理员角色。
Microsoft 客户协议
注册 Microsoft 客户协议 (MCA) 的客户具有不同的计费管理系统及其自己的角色。
Microsoft 客户协议的计费帐户包含一个或多个计费对象信息，用于管理发票和付款方式。 每项计费对象信息包含一个或多个发票科目，用于在计费对象信息的发票上组织成本。
在 Microsoft 客户协议中，计费角色来自单个 Microsoft Entra 租户。 若要为多个租户预配订阅，开始时必须在与 MCA 相同的 Microsoft Entra 租户中创建订阅，然后更改订阅。 在下图中，Corporate 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 集成，以启用实时激活策略，例如审批工作流和 MFA。
Azure 中的 ABAC 和角色分配
基于属性的访问控制 (ABAC) 是一个授权系统，根据与安全主体、资源和环境关联的属性定义访问权限。 通过 ABAC，可根据属性向安全主体授予访问资源的权限。 Azure ABAC 是指为 Azure 实现 ABAC。
Azure ABAC 构建在 Azure RBAC 之上，它在特定操作上下文中根据属性添加角色分配条件。 角色分配条件是一项额外检查，你可选择将其添加到角色分配中，来提供更精细的访问控制。 条件会筛选找到作为角色定义和角色分配的一部分而授予的权限。 例如，为了读取对象，你可添加要求对象具有特定标记的条件。 你无法使用条件显式拒绝对特定资源的访问。
条件性访问
Microsoft Entra 条件访问可用于管理对 Azure 管理终结点的访问。 条件访问策略可以应用于 Azure 服务管理 API 云应用，以保护 Azure 资源管理终结点，例如：
Azure 资源管理器提供程序（服务）
Azure 资源管理器 API
Azure PowerShell
Azure CLI
Azure 门户
例如，管理员可以配置条件访问策略，使用户只能从批准的位置登录到 Azure 门户，并要求使用多重身份验证 (MFA) 或已加入混合 Microsoft Entra 域的设备。
Azure 托管标识
生成云应用程序时需要应对的常见挑战是，如何管理代码中用于云服务身份验证的凭据。 保护这些凭据是一项重要任务。 理想情况下，这些凭据永远不会出现在开发者工作站上，也不会被签入源代码管理系统中。 Azure 资源的托管标识在 Microsoft Entra ID 中为 Azure 服务提供了一个自动托管标识。 可以使用此标识向支持 Microsoft Entra 身份验证的任何服务进行身份验证，这样就无需在代码中插入任何凭据了。
托管标识分为两种类型：
系统分配托管标识直接在 Azure 资源上启用。 启用资源后，Azure 会在关联的订阅的受信任 Microsoft Entra 租户中创建资源的标识。 创建标识后，系统会将凭据预配到资源。 系统分配标识的生命周期将直接绑定到 Azure 资源。 如果资源遭删除，Azure 会自动清理 Microsoft Entra ID 中的凭据和标识。
用户分配托管标识是作为独立的 Azure 资源创建的。 Azure 会在 Microsoft Entra 租户中创建一个标识，该标识受与资源关联的订阅的信任。 在创建标识后，可以将标识分配到一个或多个 Azure 资源。 用户分配标识的生命周期是与它所分配到的 Azure 资源的生命周期分开管理的。
在内部，托管标识是特殊类型的服务主体，只能由特定的 Azure 资源使用。 删除托管标识时，相应的服务主体也会自动删除。 请注意，图形 API 权限的授予只能由 PowerShell 完成，因此并非所有托管标识功能都可以通过门户 UI 进行访问。
Microsoft Entra 域服务
Microsoft Entra 域服务提供了一个托管域，便于使用旧协议为 Azure 工作负荷进行身份验证。 支持的服务器从本地 AD DS 林移动后会加入 Microsoft Entra 域服务托管域，继续使用旧协议进行身份验证（例如 Kerberos 身份验证）。
Azure AD B2C 目录和 Azure
Azure AD B2C 租户链接到 Azure 订阅，用于计费和通信。 Azure AD B2C 租户在目录中有一个独立角色结构，独立于 Azure 订阅的 Azure RBAC 特权角色。
最初预配 Azure AD B2C 租户时，创建 B2C 租户的用户必须在订阅中拥有参与者或所有者权限。 他们稍后可以创建其他帐户并将其分配给目录角色。 有关详细信息，请参阅 Microsoft Entra ID 中基于角色的访问控制概述。
请务必注意，链接的 Microsoft Entra 订阅的所有者和参与者可以删除订阅与目录之间的链接，这将影响针对 Azure AD B2C 使用情况进行的持续计费。
Azure 中的 IaaS 解决方案的标识注意事项
此方案涵盖组织为基础结构即服务 (IaaS) 工作负荷设置的标识隔离要求。
对于 IaaS 工作负荷的隔离管理，有三个关键选项：
已加入独立 Active Directory 域服务 (AD DS) 的虚拟机
已加入 Microsoft Entra 域服务的虚拟机
使用 Microsoft Entra 身份验证登录到 Azure 中的虚拟机
前两个选项需要解决的关键概念是，这些方案中涉及两个标识领域。
通过远程桌面协议 (RDP) 登录到 Azure Windows Server VM 时，通常会使用域凭据登录到服务器，该服务器针对本地 AD DS 域控制器或 Microsoft Entra 域服务执行 Kerberos 身份验证。 在服务器未加入域的情况下，也可以使用本地帐户登录到虚拟机。
登录到 Azure 门户以创建或管理 VM 时，你是向 Microsoft Entra ID 进行身份验证（可能使用相同的凭据，前提是已同步正确的帐户），在你使用的是 Active Directory 联合身份验证服务 (AD FS) 或直通身份验证的情况下，这可能会导致向域控制器进行身份验证。
已加入独立 Active Directory 域服务的虚拟机
AD DS 是基于 Windows Server 的目录服务，大部分由组织用于本地标识服务。 如果需要将 IaaS 工作负荷部署到 Azure，而这些工作负荷需要与另一林中的 AD DS 管理员和用户进行标识隔离，则可以部署 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 进行身份验证、配置和管理的服务器（jumpbox 除外）都需要加入隔离林。
AD DS 组策略 (GPO) - 必须配置 AD DS GPO，以确保配置符合安全要求且已跨已加入林和域的计算机进行标准化。
AD DS 组织单位 (OU) - 必须定义 AD DS OU，以确保将 AD DS 资源分组到逻辑管理和配置接收器中，以便管理和应用配置。
基于角色的访问控制 - 必须定义 RBAC，以便管理和访问已加入此林的资源。 这包括：
AD DS 组 - 必须创建组，才能将用户的相应权限应用于 AD DS 资源。
管理帐户 - 如本部分开头所述，需要两个管理帐户来管理此解决方案。
一个 AD DS 管理帐户，具有在 AD DS 和已加入域的服务器中执行必要的管理所需的最低特权访问权限。
一个 Microsoft Entra 管理帐户，用于通过 Azure 门户访问来连接、管理和配置虚拟机、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）。 应将 jumpbox 添加到应用程序安全组 (ASG)，以简化 NSG 创建和管理。
挑战：以下列表突出显示了使用此选项进行标识隔离所面临的关键挑战：
一个额外的用于管理和监视的 AD DS 林，因此 IT 团队需完成更多工作。
可能需要进一步的基础结构才能管理修补事项和软件部署事项。 组织应考虑部署 Azure 更新管理、组策略 (GPO) 或 System Center Configuration Manager (SCCM) 来管理这些服务器。
需要用户记住的附加凭据，用于访问资源。
重要
对于此独立模型，假定没有与客户的公司网络中的域控制器建立连接，并且没有为其他林配置信任。 应创建 jumpbox 或管理服务器，以允许从某个点管理 AD DS 域控制器。
已加入 Microsoft Entra 域服务的虚拟机
如果要求将 IaaS 工作负荷部署到需要与另一林中的 AD DS 管理员和用户进行标识隔离的 Azure，则可以部署 Microsoft Entra 域服务托管域。 Microsoft Entra 域服务是一项服务，它提供一个托管域，便于使用旧协议为 Azure 工作负荷进行身份验证。 它提供独立的域，没有构建和管理你自己的 AD DS 所面临的技术复杂性。 需要考虑以下事项。
Microsoft Entra 域服务托管域 - 每个 Microsoft Entra 租户只能部署一个 Microsoft Entra 域服务托管域，此限制绑定到单个 VNet。 建议让此 VNet 形成 Microsoft Entra 域服务身份验证的“中心”。 可以在此中心创建“分支”并将其链接起来，允许为服务器和应用程序进行旧式身份验证。 分支是已加入 Microsoft Entra 域服务的服务器所在的附加 VNet，使用 Azure 网络网关或 VNet 对等互连链接到中心。
托管域位置 - 部署 Microsoft Entra 域服务托管域时必须设置位置。 该位置是部署托管域的物理区域（数据中心）。 建议：
考虑一个在地理上对需要 Microsoft Entra 域服务服务的服务器和应用程序来说处于关闭状态的位置。
考虑为满足高可用性要求而提供可用性区域功能的区域。 有关详细信息，请参阅 Azure 中的区域和可用性区域。
对象预配 - Microsoft Entra 域服务从 Microsoft Entra ID 同步标识，而该 Microsoft Entra ID 与 Microsoft Entra 域服务所部署到的订阅相关联。 还值得注意的是，如果关联的 Microsoft Entra ID 已通过 Microsoft Entra Connect（用户林方案）设置同步，则这些标识的生命周期也可以反映在 Microsoft Entra 域服务中。 此服务有两种可用于从 Microsoft Entra ID 预配用户和组对象的模式。
全部：所有用户和组都从 Microsoft Entra ID 同步到 Microsoft Entra 域服务中。
有限范围：仅组范围中的用户从 Microsoft Entra ID 同步到 Microsoft Entra 域服务中。
首次部署 Microsoft Entra 域服务时，将配置自动单向同步，以从 Microsoft Entra ID 中复制对象。 此单向同步将继续在后台运行，使 Microsoft Entra 域服务托管域与 Microsoft Entra ID 中的任何更改保持同步。 不会从 Microsoft Entra 域服务往回同步到 Microsoft Entra ID。 有关详细信息，请参阅如何在 Microsoft Entra 域服务托管域中同步对象和凭据。
值得注意的是，如果需要将同步类型从“全部”更改为“有限范围”（或反过来），则需要删除、重新创建和配置 Microsoft Entra 域服务托管域。 此外，组织应考虑使用“有限范围”预配，将标识数目减少，仅保留需要访问 Microsoft Entra 域服务资源的标识，这是一种良好的做法。
组策略对象 (GPO) - 若要在 Microsoft Entra 域服务托管域中配置 GPO，必须在已通过域加入方式加入 Microsoft Entra 域服务托管域的服务器上使用组策略管理工具。 有关详细信息，请参阅管理 Microsoft Entra 域服务托管域中的组策略。
安全 LDAP - Microsoft Entra 域服务提供安全 LDAP 服务，可供需要它的应用程序使用。 默认情况下禁用此设置。若要启用安全 LDAP，则需要上传证书。此外，保护 Microsoft Entra 域服务所部署到的 VNet 的 NSG 必须允许端口 636 连接到 Microsoft Entra 域服务托管域。 如需了解更多信息，请参阅为 Microsoft Entra 域服务托管域配置安全 LDAP。
管理 - 若要在 Microsoft Entra 域服务上履行管理职责（例如，将计算机加入域或编辑 GPO），用于此任务的帐户必须属于 Microsoft Entra DC 管理员组。 属于该组的帐户无法直接登录到域控制器来执行管理任务。 你可以改为创建一个加入到 Microsoft Entra 域服务托管域的管理 VM，然后安装常规 AD DS 管理工具。 有关详细信息，请参阅 Microsoft Entra 域服务中用户帐户、密码和管理的管理概念。
密码哈希 - 若要使用 Microsoft Entra 域服务进行身份验证，所有用户的密码哈希必须采用适合 NT LAN Manager (NTLM) 和 Kerberos 身份验证的格式。 若要确保使用 Microsoft Entra 域服务进行的身份验证正常工作，需要执行以下先决条件。
使用 Microsoft Entra Connect 从 AD DS 同步的用户 - 需要将旧密码哈希从本地 AD DS 同步到 Microsoft Entra ID。
在 Microsoft Entra ID 中创建的用户 - 需要重置其密码，以便生成与 Microsoft Entra 域服务配合使用的正确哈希。 有关详细信息，请参阅启用密码哈希同步。
网络 - Microsoft Entra 域服务部署到 Azure VNet，因此需注意确保服务器和应用程序受到保护并且可以正确访问托管域。 有关详细信息，请参阅 Microsoft Entra 域服务的虚拟网络设计注意事项和配置选项。
Microsoft Entra 域服务必须部署在其自己的子网中：不要使用现有子网或网关子网。
网络安全组 (NSG) - 在部署 Microsoft Entra 域服务托管域期间创建。 此网络安全组包含正确进行服务通信所需的规则。 请勿创建或使用拥有自定义规则的网络安全组。
Microsoft Entra 域服务需要 3-5 个 IP 地址 - 确保子网 IP 地址范围可以提供此数目的地址。 限制可用 IP 地址可能会阻止 Microsoft Entra 域服务维护两个域控制器。
VNet DNS 服务器 - 正如前面有关“中心辐射型”模型的讨论所介绍的那样，必须在 VNet 上正确配置 DNS 以确保加入 Microsoft Entra 域服务托管域的服务器具有正确的 DNS 设置来解析 Microsoft Entra 域服务托管域，这很重要。 每个 VNet 都有一个 DNS 服务器条目，该条目在服务器获取 IP 地址时传递给服务器。这些 DNS 条目必须是 Microsoft Entra 域服务托管域的 IP 地址。 有关详细信息，请参阅更新 Azure 虚拟网络的 DNS 设置。
挑战 - 以下列表突出显示了使用此选项进行标识隔离所面临的关键挑战。
某些 Microsoft Entra 域服务配置只能从已加入 Microsoft Entra 域服务的服务器进行管理。
每个 Microsoft Entra 租户只能部署一个 Microsoft Entra 域服务托管域。 如本部分所述，建议将中心辐射型模型设置为向其他 VNet 上的服务提供 Microsoft Entra 域服务身份验证。
可能需要进一步的基础结构才能管理修补事项和软件部署事项。 组织应考虑部署 Azure 更新管理、组策略 (GPO) 或 System Center Configuration Manager (SCCM) 来管理这些服务器。
对于此独立模型，假定没有从客户的公司网络到托管 Microsoft Entra 域服务托管域的 VNet 的连接，并且没有为其他林配置信任。 应创建 jumpbox 或管理服务器，以允许从某个点管理 Microsoft Entra 域服务。
使用 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 角色提供对这些虚拟机的适当访问权限级别。 可以通过 Azure 门户配置这些 RBAC 角色。 有关详细信息，请参阅配置 VM 的角色分配。
虚拟机管理员登录名：分配了此角色的用户可以使用管理员权限登录到 Azure 虚拟机。
虚拟机用户登录名：分配了此角色的用户可以使用常规用户权限登录到 Azure 虚拟机。
条件访问：使用 Microsoft Entra ID 登录到 Azure 虚拟机的主要好处是能够在登录过程中强制实施条件访问。 这使组织能够要求在允许访问虚拟机之前满足条件，并能够使用多重身份验证来提供强身份验证。 有关详细信息，请参阅使用条件访问。
注意
仅允许从 Windows 10 电脑、Windows 11 电脑和云电脑远程连接到已建立 Microsoft Entra ID 联接的虚拟机，而这些电脑已与虚拟机所在的目录建立 Microsoft Entra 联接或 Microsoft Entra 混合联接。
挑战：以下列表突出显示了使用此选项进行标识隔离所面临的关键挑战。
不对服务器进行集中管理或配置。 例如，没有可应用于一组服务器的组策略。 组织应考虑部署 Azure 更新管理，以管理这些服务器的修补和更新事项。
不适合那些要求在这些服务器或服务中使用 Windows 集成身份验证之类的本地机制进行身份验证的多层应用程序。 如果这是针对组织的要求，则建议浏览独立 Active Directory 域服务或本部分所述的 Microsoft Entra 域服务方案。
对于此独立模型，假设不存在与托管客户公司网络中虚拟机的 VNet 的连接。 应创建 jumpbox 或管理服务器，以允许从某个点管理这些服务器。