Azure资源管理基础知识

请务必了解特定于Azure资源的结构和术语。 下图显示了由Azure提供的四个范围的一个示例：

显示Azure资源管理模型的

术语

下面是应熟悉的一些术语：

Resource - 可通过Azure提供的可管理项。 资源的示例包括虚拟机、存储帐户、Web 应用、数据库和虚拟网络。

Resource group - 包含Azure解决方案的相关资源的容器，例如虚拟机集合、关联的 VNet 和需要特定团队管理的负载均衡器。 资源组包括你想要将其作为一个组进行管理的那些资源。 根据最适合组织的情况来决定哪些资源属于哪个资源组。 资源组还可用于帮助进行生命周期管理，方法是一次删除具有相同生存期的所有资源。 此方法不保留可能被利用的片段，因此还具有安全优势。

订阅 - 从组织层次结构的角度来看，订阅是资源和资源组的计费和管理容器。 Azure订阅与Microsoft Entra ID具有信任关系。 订阅信任Microsoft Entra ID对用户、服务和设备进行身份验证。

管理组 - Azure管理组提供分层方法，用于在订阅上方的不同范围内应用策略和合规性。 它可以位于租户根管理组（最高的范围）或层次结构中的较低级别。 可将订阅组织到名为“管理组”的容器中，并将管理条件应用到管理组。 管理组中的所有订阅都将自动继承应用于管理组的条件。 请注意，策略定义可以应用于管理组或订阅。

资源提供程序 - 提供Azure资源的服务。 例如，常见的资源提供程序是 Microsoft. Compute，提供虚拟机资源。 Microsoft。 Storage 是另一个常见的资源提供程序。

Resource Manager模板 - 一个 JavaScript 对象表示法（JSON）文件，用于定义部署到资源组、订阅、租户或管理组的一个或多个资源。 使用模板能够以一致方式反复部署资源。 请参阅模板部署概述。 此外，可以使用 Bicep 语言而不是 JSON。

Azure资源管理模型

每个Azure订阅都与 Azure Resource Manager 使用的控件相关联。 Resource Manager是Azure的部署和管理服务，它与Microsoft Entra ID和Microsoft帐户（MSA）分别建立了信任关系，用于组织和个人的身份管理。 Resource Manager提供了一个管理层，可用于在Azure订阅中创建、更新和删除资源。 部署后，请使用访问控制、锁和标记等管理功能来保护和组织资源。

Azure Resource Manager是前端服务，它托管 PowerShell、Azure 门户或其他客户端用来管理资源的 REST API。 当客户端发出管理特定资源的请求时，Resource Manager将请求代理给资源提供程序以完成请求。 例如，如果客户端发出管理虚拟机资源的请求，Resource Manager将请求代理到Microsoft。 计算资源提供程序。 Resource Manager要求客户端为订阅和资源组指定标识符来管理虚拟机资源。

在Resource Manager执行任何资源管理请求之前，将检查一组控制措施。

• 有效用户检查 - 请求管理资源的用户必须在与托管资源订阅相关联的 Microsoft Entra 租户中有一个帐户。

• 用户权限检查 - 使用基于角色的访问控制 (RBAC) 将权限分配给用户。 RBAC 角色指定用户对特定的资源拥有的一组权限。 RBAC 可帮助你管理谁有权访问 Azure 资源、他们可以对那些资源执行的操作，以及他们可以访问哪些区域。

• Azure策略检查 - Azure策略指定特定资源允许或显式拒绝的操作。 例如，策略可以指定只允许（或不允许）用户部署特定类型的虚拟机。

下图汇总了我们刚才介绍的资源模型。

Azure Lighthouse - Azure Lighthouse可跨租户进行资源管理。 组织可以在订阅或资源组级别将角色委托给其他租户中的身份。

启用委托的资源管理的订阅在Azure Lighthouse中具有一些属性，这些属性指示哪些租户ID可以管理订阅或资源组，并且定义了资源租户中的内置RBAC角色与服务提供商租户中的标识之间的映射关系。 在运行时，Azure Resource Manager使用这些属性来授权来自服务提供商租户的令牌。

值得注意的是，Azure Lighthouse 本身被设计为一个 Azure 资源提供程序，这意味着可以通过 Azure 策略来针对租户委托的各个方面进行管理。

Microsoft 365 Lighthouse - Microsoft 365 Lighthouse 是一个管理门户，可帮助托管服务提供商（MSP）大规模地为使用 Microsoft 365 Business Premium、Microsoft 365 E3 以及 Windows 365 Business 的中小型企业客户保护和管理设备、数据和用户。

使用 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 Resource Manager 与经典部署.）

可以通过在 Azure EA 门户中设置“工作或学校帐户跨租户”的身份验证类型，将企业协议配置为支持多个租户。 因此，组织可以为每个租户设置多个帐户，并为每个帐户设置多个订阅，如下图所示。

请务必注意，上述默认配置授予Azure EA 帐户所有者权限来管理他们创建的任何订阅中的资源。 对于包含生产工作负荷的订阅，请考虑在创建订阅后立即更改订阅的服务管理员，通过这种方式将计费和资源管理分离开来。

要进一步分离帐户所有者并阻止其重新获得订阅的服务管理员访问权限，可以在创建订阅后更改订阅的租户。 如果帐户所有者在订阅被迁移到的 Microsoft Entra 租户中没有用户对象，他们将无法重新获得服务所有者角色。

若要了解详细信息，请访问 Azure 角色、Microsoft Entra角色和经典订阅管理员角色。

微软客户协议

使用 Microsoft 客户协议（MCA） 的客户拥有不同的计费管理系统及其自身的角色。

Microsoft Customer Agreement的计费帐户包含一个或多个计费配置文件，用于管理发票和付款方式。 每项计费对象信息包含一个或多个发票科目，用于在计费对象信息的发票上组织成本。

在 Microsoft Customer Agreement 中，计费角色来自单个 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 Conditional Access可用于管理对Azure管理终结点的访问。 条件访问策略可以应用于Windows Azure服务管理 API 云应用，以保护Azure资源管理终结点，例如：

• Azure Resource Manager 提供者（服务）

• Azure Resource Manager 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 资源使用。 删除托管标识时，相应的服务主体也会自动删除。 注意，Graph API 权限的授权只能通过 PowerShell 进行，因此并不是所有托管标识的特性都可以通过门户用户界面访问。

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 Federation Services (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 组策略，以确保配置符合安全要求，并在整个林和已加入域的计算机中实现标准化。

• 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 地址配置域控制器。 IP 地址应保留在 Azure VNet 上，以确保它们始终保持不变，并且应将 DC 配置为使用 DHCP。

• VNet DNS 服务器 - 必须在属于此独立解决方案的 VNet 上配置 DNS 服务器，使之指向域控制器。 这是必要的，以确保应用程序和服务器能够解析并访问加入 AD DS 林的必需 AD DS 服务或其他相关服务。

• 网络安全组 (NSG) - 域控制器应该位于其专用的 VNet 或子网中，并配置 NSG 以仅允许来自特定服务器（例如已加入域的计算机或跳板机）的访问。 应将 jumpbox 添加到应用程序安全组 (ASG)，以简化 NSG 创建和管理。

挑战：以下列表突出显示了使用此选项进行标识隔离所面临的关键挑战：

• 在管理、运维和监控方面需要一个额外的 AD DS 林，这将导致 IT 团队需承担更多工作。

• 可能需要进一步的基础结构才能管理修补事项和软件部署事项。 组织应考虑部署Azure更新管理、组策略（GPO）或System Center Configuration Manager（SCCM）来管理这些服务器。

• 需要用户记住的附加凭据，用于访问资源。

加入 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)，这些 VNet 使用 Azure 网络网关或 VNet 对等连接到中心。

托管域位置 - 在部署 Microsoft Entra 域服务托管域时，必须设置域的位置。 该位置是部署托管域的物理区域（数据中心）。 建议您：

• 请考虑地理上靠近需要 Microsoft Entra 域服务的服务器和应用程序的位置。

• 考虑为高可用性要求提供Availability Zones功能的区域。 有关详细信息，请参阅 Azure 中的区域和可用区。

对象预配 - Microsoft Entra 域服务会将与订阅关联并部署于 Microsoft Entra 域服务中的 Microsoft Entra ID 的标识同步。 值得注意的是，如果关联的 Microsoft Entra ID 已与 Microsoft Entra Connect（用户林场景）设置了同步，那么这些身份的生命周期也会在 Microsoft Entra 域服务中得到体现。 此服务具有两种模式，可用于从Microsoft Entra ID预配用户和组对象。

• All：所有用户和组都从Microsoft Entra ID同步到Microsoft Entra域服务。

• Scoped：只有在组范围内的用户才会从 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 域服务托管域中管理组策略的文档 。

Secure LDAP - Microsoft Entra域服务提供安全 LDAP 服务，可供需要它的应用程序使用。 此设置默认处于禁用状态，若要启用安全 LDAP，还需要上传证书，此外，保护Microsoft Entra域服务的 VNet 的 NSG 必须允许端口 636 连接到 Microsoft Entra 域服务托管域。 有关详细信息，请参阅 为 Microsoft Entra 域服务托管域配置安全 LDAP。

Administration - 若要对Microsoft Entra域服务（例如域加入计算机或编辑 GPO）执行管理职责，则用于此任务的帐户需要是Microsoft Entra DC 管理员组的一部分。 属于该组的帐户无法直接登录到域控制器来执行管理任务。 而是创建一个已加入 Microsoft Entra 域服务托管域的管理 VM，然后安装常规 AD DS 管理工具。 有关详细信息，请参阅 Microsoft Entra 域服务中的用户帐户、密码和管理概念。

Password 哈希 - 若要使用 Microsoft Entra 域服务进行身份验证，所有用户的密码哈希必须采用适用于 NT LAN Manager （NTLM） 和 Kerberos 身份验证的格式。 若要确保Microsoft Entra域服务的身份验证按预期工作，需要执行以下先决条件。

• 通过 Microsoft Entra Connect（从 AD DS）同步的用户 - 需要将已有密码哈希从本地 AD DS 同步到 Microsoft Entra ID。

• 在 Microsoft Entra ID - 需要重置其密码，以便为与 Microsoft Entra 域服务一起使用而生成正确的哈希。 有关详细信息，请参阅启用密码哈希同步。

Network - Microsoft Entra域服务部署到 Azure VNet，因此需要注意确保服务器和应用程序受到保护并能够正确访问托管域。 有关详细信息，请参阅 Microsoft Entra 域服务的网络设计注意事项和配置选项。

• Microsoft Entra域服务必须部署在其自己的子网中：请勿使用现有子网或网关子网。

• 在部署Microsoft Entra域服务托管域期间创建网络安全组（NSG）。 此网络安全组包含正确进行服务通信所需的规则。 请勿创建或使用拥有自定义规则的网络安全组。

• Microsoft Entra域服务需要 3-5 个 IP 地址 - 确保子网 IP 地址范围可以提供此数量的地址。 限制可用的 IP 地址可以防止Microsoft Entra域服务维护两个域控制器。

• VNet DNS 服务器 - 正如之前讨论的“中心辐射”模式，在 VNet 上正确配置 DNS 至关重要。这保证加入 Microsoft Entra 域服务管理域的服务器具有正确的 DNS 设置，以便解析这些托管域。 每个 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，也没有与其他林配置的信任关系。 应创建跳板机或管理服务器，以作为 Microsoft Entra 域服务的管理和维护入口。

使用Microsoft Entra身份验证登录到Azure中的虚拟机

如果存在将 IaaS 工作负荷部署到需要标识隔离的Azure的要求，最后一个选项是使用此方案使用 Microsoft Entra ID登录到服务器。 这为Microsoft Entra ID成为身份领域提供了可能性，用于身份验证。通过将服务器预配到与所需Microsoft Entra租户相关联的订阅中，可以实现身份隔离。 需要考虑以下事项。

支持的操作系统：目前，Windows 和 Linux 支持使用 Microsoft Entra 身份验证登录到 Azure 中的虚拟机。 有关支持的作系统的更多详细信息，请参阅 Windows 和 Linux 的文档。

Credentials：通过Microsoft Entra身份验证登录Azure虚拟机的主要优势之一是，您可以使用通常用于访问Microsoft Entra服务的相同联合身份或托管身份凭据来登录虚拟机。

Network 要求：这些虚拟机需要访问Microsoft Entra ID进行身份验证，因此必须确保虚拟机网络配置允许出站访问 443 上的 Microsoft Entra 终结点。 有关详细信息，请参阅 Windows 和 Linux 的文档。

基于角色的访问控制（RBAC）：可以使用两个 RBAC 角色来提供对这些虚拟机的适当访问级别。 可以通过Azure门户配置这些 RBAC 角色。 有关详细信息，请参阅配置 VM 的角色分配。

• 虚拟机管理员登录：分配有此角色的用户可以使用管理员权限登录到Azure虚拟机。

• 虚拟机用户登录：分配有此角色的用户可以使用常规用户特权登录到Azure虚拟机。

条件访问：使用Microsoft Entra ID登录到Azure虚拟机的主要好处是能够在登录过程中强制实施条件访问。 这使组织能够要求在允许访问虚拟机之前满足条件，并能够使用多重身份验证来提供强身份验证。 有关详细信息，请参阅使用条件访问。

挑战：以下列表突出显示了使用此选项进行标识隔离所面临的关键挑战。

• 不对服务器进行集中管理或配置。 例如，没有可应用于一组服务器的组策略。 组织应考虑在 Azure 中部署 Update Management 服务来管理这些服务器的补丁和更新。

• 不适用于需要通过本地机制进行身份验证的多层应用程序，例如在这些服务器或服务中Windows集成身份验证。 如果这是对组织的要求，那么建议您探索本部分中描述的独立的 Active Directory 域服务或 Microsoft Entra 域服务方案。

对于此独立模型，假设不存在与托管客户公司网络中虚拟机的 VNet 的连接。 应创建 jumpbox 或管理服务器，以允许从某个点管理这些服务器。

后续步骤

• 委派管理和隔离环境简介

• Microsoft Entra基础知识

• 单租户环境中的资源隔离

• 多租户环境下的资源隔离