Microsoft AZ-140: 身份、访问和治理 — 学习指南

By Laurynas Brazys · 12 August 2026 · #microsoft #az-140 #certification #exam-prep #study-guide

属于 Microsoft Azure Virtual Desktop Specialty AZ-140 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

身份、访问和治理定义了用户、设备和自动化如何与 Azure Virtual Desktop 资源进行交互。一个稳健的设计应将 Microsoft Entra ID 作为身份控制平面，应用作用域限定于 AVD 资源的 Azure RBAC 最小权限原则，强制执行条件访问和多重身份验证，并通过托管标识实现自动化运维。诸如会话主机是 Microsoft Entra joined 还是 hybrid Microsoft Entra joined 等决策，会决定下游对 DNS、身份验证、配置文件存储和条件访问行为的需求。

身份和目录设计

Microsoft Entra ID 租户、用户和组
- AVD 控制平面原生于 Microsoft Entra ID。用户必须存在于拥有 AVD 资源的租户中，或者是具有适当分配的 B2B 来宾用户。
- 使用 Microsoft Entra 安全组（静态或动态）进行应用程序组分配和基于角色的管理。避免在 AVD 角色分配中使用嵌套组；Azure RBAC 不会评估角色分配的嵌套成员身份。
基于组的 AVD 应用程序组分配
- 通过将用户或组分配给应用程序组，用户有权访问远程应用或桌面。在授权时，Azure 会在应用程序组作用域为这些主体应用 Desktop Virtualization User 角色分配。
- 优先使用组分配而非单个用户，以简化生命周期管理和访问评审。使用由用户属性或部门驱动的动态组，将用户映射到正确的 RemoteApp 或桌面应用程序组。
Microsoft Entra joined 与 hybrid Microsoft Entra joined 会话主机对比
- Microsoft Entra joined：无需与传统域控制器建立直接连接（line-of-sight）。是云优先部署的理想选择。支持使用 Microsoft Entra ID 进行新式身份验证和到会话的 SSO。对于 FSLogix，请使用带有 Microsoft Entra Kerberos 的 Azure Files，这样主机无需 AD DS 即可对配置文件进行身份验证。
- Hybrid Microsoft Entra joined（已加入 AD DS 域并注册到 Entra ID）：如果您必须使用现有的组策略、本地 Kerberos/NTLM 或需要 AD DS 的 SMB 目标，则必须采用此方式。确保 VNET DNS 指向能够解析和为域提供服务的域控制器。如果使用 Azure AD DS（托管域），请在将会话主机加入域之前，将 VNET DNS 服务器设置为托管域的 IP。
混合身份、Microsoft Entra Connect、密码哈希同步和无缝 SSO
- 使用 Microsoft Entra Connect 从 AD DS 同步用户身份。密码哈希同步是最简单、最具弹性的登录方法，并支持云端的条件访问。
- 启用无缝 SSO，以便内部网络上的公司设备可以获得基于 Kerberos 的到 Entra ID 的单点登录，而无需提示输入凭据。这在从受管网络启动 AVD 时改善了用户体验，同时仍然允许强制执行条件访问。

访问控制和最小权限

AVD 的内置 Azure RBAC 角色
- Desktop Virtualization Administrator：对 AVD 资源的完全管理控制权。
- Desktop Virtualization Contributor：管理 AVD 资源，但不授予最终用户访问权限。
- Desktop Virtualization Reader：查看 AVD 资源。
- Desktop Virtualization Host Pool Contributor：管理主机池设置和注册密钥；但不能完全控制其他 AVD 资源。
- Desktop Virtualization Workspace Contributor：从工作区发布或移除应用程序组。
- Desktop Virtualization Application Group Contributor：管理应用程序组属性和已发布的应用；不授予用户访问权限。
- Desktop Virtualization Session Host Operator：面向服务支持人员；查看会话主机、用户会话、发送消息、断开或注销会话。
- Desktop Virtualization User：在应用程序组作用域分配给用户/组，以授权启动会话。
角色分配作用域和模式
- 尽可能缩小权限作用域：
  - 仅在应用程序组作用域将 Desktop Virtualization User 分配给用户/组。
  - 将 Application Group Contributor 分配给应用组；将 Workspace Contributor 分配给工作区；将 Host Pool Contributor 分配给主机池。
  - 如果运维人员必须管理来宾虚拟机的电源、大小或网络接口，请在包含会话主机虚拟机的资源组级别分配 Virtual Machine Contributor 及相关的计算/存储/网络角色。
- 为控制平面对象（工作区、主机池、应用程序组）和会话主机虚拟机使用不同的资源组，可以改善作用域划分和可审计性。
托管标识、服务主体和委托自动化
- 对于 AVD 自动缩放和运维运行手册，优先使用系统分配或用户分配的托管标识。仅在最小作用域内授予所需的角色，以操作目标资源（例如，在会话主机资源组上授予 Virtual Machine Contributor，在主机池上授予 Desktop Virtualization Contributor）。
- 对于发布应用组或更新 RDP 属性的 DevOps 管道，请使用带有证书凭据的服务主体。将其权限限制在它们管理的特定 AVD 资源上。
Privileged Identity Management 和紧急访问
- 对 Azure RBAC 和 Microsoft Entra 角色都使用 Microsoft Entra Privileged Identity Management。
- 将高风险角色（如 Desktop Virtualization Administrator 和 Subscription Owner）设置为 eligible（符合条件），并要求 MFA、审批和理由说明。
- 维护至少两个紧急访问（“break-glass”）的 Global Administrator 帐户，将它们从条件访问和 PIM 中排除，离线存储，定期测试，并且仅用于恢复目的。

角色作用域划分简例：

# End-user entitlement to one application group
az role assignment create \
  --assignee <groupObjectId> \
  --role "Desktop Virtualization User" \
  --scope /subscriptions/<subId>/resourceGroups/rg-avd-control/providers/Microsoft.DesktopVirtualization/applicationGroups/ag-fin-remoteapps

# Help-desk session operations on a host pool
az role assignment create \
  --assignee <helpdeskGroupId> \
  --role "Desktop Virtualization Session Host Operator" \
  --scope /subscriptions/<subId>/resourceGroups/rg-avd-control/providers/Microsoft.DesktopVirtualization/hostPools/hp-fin

条件访问、MFA 和会话控制

目标云应用
- 将条件访问应用于 Azure Virtual Desktop 和 Azure Virtual Desktop Azure Resource Manager，以保护最终用户连接和管理操作。排除紧急访问帐户和非交互式工作负载身份。
多重身份验证和身份验证强度
- 要求所有外部或高风险登录都使用 MFA。使用身份验证强度来强制要求采用防网络钓鱼的方法（例如，FIDO2 安全密钥、Microsoft Authenticator 中与设备绑定的通行密钥或基于证书的身份验证）。
- 为了在 Windows 客户端上获得最佳用户体验，请将防网络钓鱼的 MFA 与 AVD 单点登录结合使用，这样用户只需向 Entra ID 进行一次身份验证，即可无缝登录到 Windows 会话。
设备合规性和 Intune 信号
- 要限制对托管端点的访问，请使用条件访问并要求“将设备标记为合规”。此操作会评估使用 Remote Desktop 客户端的 Windows、macOS、iOS 和 Android 设备的 Microsoft Intune 合规性状态。
- 对于 BYOD 或非托管设备，请使用替代控制措施，例如 MFA、基于登录风险的策略、使用条款和会话限制。考虑为 BYOD 设置单独的应用程序组，并限制其中的应用。
会话控制和登录频率
- 配置适合生产力和风险的登录频率（例如，12 小时），以避免在重新连接期间重复出现提示。持久性浏览器会话不适用于原生 Remote Desktop 客户端。在支持的情况下，利用持续访问评估来实现快速策略更改和风险撤销。
网络和位置注意事项
- 使用命名位置来减少受信任办公网络的登录摩擦。对于远程工作人员，请结合使用 MFA 和设备合规性来保持强大的安全态势。

主机的操作身份注意事项

DNS 和域加入
- 对于已加入 AD DS 或 Azure AD DS 的主机，在预配之前，请将 VNET DNS 服务器设置为域控制器 IP 或托管域 IP。如果没有正确的 DNS，域加入将失败，并且 FSLogix、GPO 和 Kerberos 将无法正常工作。
- 对于已加入 Microsoft Entra 的主机，您不需要 AD DS DNS；但是，配置文件 SMB 目标仍需要新式身份验证功能（使用 Azure Files 的 Microsoft Entra Kerberos）。
注册密钥和横向扩展
- 将现有或新的会话主机添加到主机池需要一个有效的注册密钥。请限制密钥的生命周期，并将 VM 扩展部署的范围仅限定在主机池资源。
连接时启动 VM 和自动缩放
- 对于会解除分配/分配 VM 的自动缩放功能，请在主机 VM 资源组上为缩放计划的托管身份分配 Virtual Machine Contributor 角色，并在主机池上分配 Desktop Virtualization Contributor 角色。避免授予订阅范围的权限。
访问评审和授权生命周期
- 对分配给应用程序组的 Entra 组实施定期的访问评审。当应用程序访问跨越多个应用程序组或资源时，与 Entitlement Management 集成。
审计
- 监控 Microsoft Entra 登录和审核日志以了解 AVD 应用访问情况，并监控 Azure 活动日志以了解 AVD 资源变更。将日志流式传输到 Log Analytics 或 SIEM，并针对异常活动（例如，大规模会话注销或意外的角色分配）设置警报。

实际问题场景

Tailwind Traders 正在通过 Azure Virtual Desktop 为 3,000 名用户启用对业务线应用的安全远程访问。他们有一个本地 AD 林，已通过密码哈希同步和无缝 SSO 同步到 Microsoft Entra ID。他们将使用已加入 Microsoft Entra 的会话主机为全新的池进行现代化改造，同时保留一个需要 GPO 的旧有混合池。他们必须强制执行抗网络钓鱼的 MFA，仅允许在公司外部时从合规设备进行访问，委派服务台会话操作，并以最低权限运行自动缩放。

决定主机加入模型和 DNS
- 操作：为大多数用户部署一个新的、使用已加入 Microsoft Entra 的 Windows 11 企业版多会话的池化主机池；为一个需要 GPO 的应用保留一个较小的混合加入池。
- 原因：加入 Entra 可减少对域控制器的依赖并简化条件访问。旧有的池保留了必需的 GPO。对于混合池，VNET DNS 设置为可通过 VPN 访问的本地 DC IP，以确保域加入和 Kerberos 的正常工作。
使用新式身份验证的配置文件存储
- 操作：为已加入 Entra 的池，使用带有 Microsoft Entra Kerberos 的 Azure Files 来实现 FSLogix。为用户和会话主机的托管身份配置共享级别和文件权限。
- 原因：这使得可以使用 Entra ID 进行无域的 SMB 访问，从而消除了云优先池中配置文件对 AD DS 的依赖。
基于组的授权
- 操作：根据用户画像创建 Entra 安全组（例如，grp-tt-hr-remoteapps、grp-tt-sales-desktop）。将这些组分配给相应的应用程序组；避免使用嵌套组。
- 原因：集中化访问控制并启用访问评审。Azure RBAC for AVD 可以可靠地评估直接的组成员身份。
使用身份验证强度的条件访问
- 操作：创建以 Azure Virtual Desktop 和 Azure Virtual Desktop Azure Resource Manager 为目标的策略：
  - 要求身份验证强度为“抗网络钓鱼的 MFA”。
  - 对于受信任的办公地点以外的位置，还要求设备被标记为合规。
  - 为最终用户设置登录频率为 12 小时。
  - 排除两个紧急访问帐户和自动缩放托管身份。
- 原因：强制执行强身份验证因素和托管设备访问，而不会产生过多的提示，并避免阻止紧急或工作负载身份。
委派最低权限操作
- 操作：在最小范围分配角色：
  - 将 Desktop Virtualization User 角色分配给其应用程序组范围内的授权组。
  - 将 Desktop Virtualization Session Host Operator 角色分配给每个主机池的服务台组。
  - 将 Desktop Virtualization Workspace Contributor 角色分配给工作区的应用发布团队。
  - 仅在会话主机资源组上将 Virtual Machine Contributor 角色分配给运维团队。
- 原因：将职责与其管理的范围对齐，防止在订阅级别出现权限过高的情况。
使用托管身份配置自动缩放
- 操作：在主机池上使用用户分配的托管身份启用自动缩放。在会话主机资源组上授予其 Virtual Machine Contributor 角色，并在主机池上授予 Desktop Virtualization Contributor 角色。例如：

az role assignment create --assignee <miObjectId> --role "Virtual Machine Contributor" --scope /subscriptions/<sub>/resourceGroups/rg-tt-avd-hosts
az role assignment create --assignee <miObjectId> --role "Desktop Virtualization Contributor" --scope /subscriptions/<sub>/resourceGroups/rg-tt-avd-control/providers/Microsoft.DesktopVirtualization/hostPools/hp-tt-prod

原因：自动缩放可以启动和停止 VM 并更新主机池指标，而无需广泛的权限。

使用 PIM 和紧急访问帐户保护管理
- 操作：将管理性 RBAC 角色载入到带有审批工作流和 MFA 的 Microsoft Entra PIM 中。维护两个从 CA 和 PIM 中排除的紧急访问 Global Administrator 帐户。
- 原因：减少常设权限，并确保在条件访问或身份服务配置错误时具有可恢复性。
定期监控和评审访问
- 操作：将 Entra 登录日志和 Azure 活动日志流式传输到 Log Analytics。对分配给应用程序组的组以及服务台操作员角色运行季度访问评审。
- 原因：长期维持最低权限原则，并检测异常情况，例如 AVD 登录被拒次数的意外增加或大规模会话终止。

该方法将云优先身份模型与精确的范围界定及强访问策略相结合，在用户体验和安全性之间取得了平衡，并确保了操作与自动化任务只被授予必要的权限。

← Azure Virtual Desktop 架构和服务设计 · 所有领域 · 网络、连接和传输 →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →