Microsoft AZ-140: Identidad, acceso y gobernanza — Guía de estudio
Forma parte de la Microsoft Azure Virtual Desktop Specialty AZ-140 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Microsoft, o realiza tests cronometrados en ExamRoll.io.
Información general
La identidad, el acceso y la gobernanza definen cómo los usuarios, los dispositivos y la automatización interactúan con los recursos de Azure Virtual Desktop. Un diseño robusto alinea Microsoft Entra ID como el plano de control de identidad, aplica permisos de privilegio mínimo con Azure RBAC en el ámbito de los recursos de AVD, impone el acceso condicional y la autenticación multifactor, y operacionaliza la automatización con identidades administradas. Decisiones como si los hosts de sesión están unidos a Microsoft Entra (Microsoft Entra joined) o unidos de forma híbrida a Microsoft Entra (hybrid Microsoft Entra joined) determinan los requisitos posteriores para el DNS, la autenticación, el almacenamiento de perfiles y el comportamiento del Acceso Condicional.
Diseño de identidad y directorio
Inquilinos (tenants), usuarios y grupos de Microsoft Entra ID
- El plano de control de AVD es nativo de Microsoft Entra ID. Los usuarios deben existir en el inquilino propietario de los recursos de AVD o ser usuarios invitados B2B con las asignaciones adecuadas.
- Utilice grupos de seguridad de Microsoft Entra —estáticos o dinámicos— para las asignaciones de grupos de aplicaciones y para la administración basada en roles. Evite los grupos anidados para las asignaciones de roles de AVD; Azure RBAC no evalúa la pertenencia anidada para las asignaciones de roles.
Asignación basada en grupos a grupos de aplicaciones de AVD
- Los usuarios obtienen derecho a aplicaciones o escritorios remotos al asignar usuarios o grupos al grupo de aplicaciones. En el momento de la autorización, Azure aplica una asignación del rol Usuario de Desktop Virtualization en el ámbito del grupo de aplicaciones a esas entidades de seguridad (principals).
- Prefiera las asignaciones a grupos en lugar de a usuarios individuales para simplificar la gestión del ciclo de vida y las revisiones de acceso. Utilice grupos dinámicos basados en atributos de usuario o departamento para asignar a los usuarios a los grupos de aplicaciones de RemoteApp o de escritorio correctos.
Hosts de sesión unidos a Microsoft Entra frente a unidos de forma híbrida a Microsoft Entra
- Unido a Microsoft Entra (Microsoft Entra joined): Sin línea de visión a los controladores de dominio tradicionales. Ideal para implementaciones nativas de la nube (cloud-first). Admite autenticación moderna y SSO a la sesión con Microsoft Entra ID. Para FSLogix, utilice Azure Files con Microsoft Entra Kerberos para que los hosts se autentiquen en los perfiles sin AD DS.
- Unido de forma híbrida a Microsoft Entra (Hybrid Microsoft Entra joined) (unido al dominio de AD DS y registrado en Entra ID): Requerido si debe utilizar directivas de grupo (Group Policy) existentes, Kerberos/NTLM local, o destinos SMB que requieran AD DS. Asegúrese de que el DNS de la VNET apunte a controladores de dominio que puedan resolver y dar servicio al dominio. Si utiliza Azure AD DS (dominio administrado), establezca los servidores DNS de la VNET en las IP del dominio administrado antes de unir los hosts de sesión al dominio.
Identidad híbrida, Microsoft Entra Connect, sincronización de hash de contraseñas y SSO de conexión directa
- Utilice Microsoft Entra Connect para sincronizar las identidades de los usuarios desde AD DS. La sincronización de hash de contraseñas (Password hash synchronization) es el método de inicio de sesión más simple y resistente, y es compatible con el Acceso Condicional del lado de la nube.
- Habilite el SSO de conexión directa (Seamless SSO) para que los dispositivos corporativos en la red interna puedan obtener un inicio de sesión único basado en Kerberos en Entra ID sin solicitar credenciales. Esto mejora la experiencia del usuario al iniciar AVD desde redes administradas, al tiempo que permite la aplicación del Acceso Condicional.
Control de acceso y privilegio mínimo
Roles de Azure RBAC integrados para AVD
- Administrador de Desktop Virtualization: Control administrativo total sobre los recursos de AVD.
- Colaborador de Desktop Virtualization: Administra los recursos de AVD sin conceder acceso a los usuarios finales.
- Lector de Desktop Virtualization: Visualiza los recursos de AVD.
- Colaborador de grupo de hosts de Desktop Virtualization: Administra la configuración del grupo de hosts y las claves de registro; no tiene control total sobre otros recursos de AVD.
- Colaborador de área de trabajo de Desktop Virtualization: Publica o elimina grupos de aplicaciones de un área de trabajo.
- Colaborador de grupo de aplicaciones de Desktop Virtualization: Administra las propiedades del grupo de aplicaciones y las aplicaciones publicadas; no concede acceso a los usuarios.
- Operador de host de sesión de Desktop Virtualization: Orientado a soporte técnico (help-desk); visualiza hosts de sesión, sesiones de usuario, envía mensajes, desconecta o cierra sesiones.
- Usuario de Desktop Virtualization: Asignado a usuarios/grupos en el ámbito del grupo de aplicaciones para autorizar los inicios de sesión.
Ámbitos y patrones de asignación de roles
- Limite los permisos al ámbito más reducido posible:
- Asigne el rol Usuario de Desktop Virtualization a usuarios/grupos únicamente en el ámbito del grupo de aplicaciones.
- Asigne el rol Colaborador de grupo de aplicaciones al grupo de aplicaciones; Colaborador de área de trabajo al área de trabajo; Colaborador de grupo de hosts al grupo de hosts.
- Asigne el rol Colaborador de máquina virtual y roles relacionados de computación/almacenamiento/red en el grupo de recursos que contiene las VM de los hosts de sesión si el personal de operaciones debe administrar el encendido, los tamaños o las interfaces de red de los invitados.
- Separar los grupos de recursos para los objetos del plano de control (áreas de trabajo, grupos de hosts, grupos de aplicaciones) y las VM de los hosts de sesión mejora la delimitación del ámbito y la capacidad de auditoría.
- Limite los permisos al ámbito más reducido posible:
Identidades administradas, entidades de servicio y automatización delegada
- Prefiera las identidades administradas asignadas por el sistema o por el usuario para el autoescalado de AVD y los runbooks operativos. Conceda solo los roles necesarios, en el ámbito mínimo, para manipular los recursos de destino (por ejemplo, Colaborador de máquina virtual en el grupo de recursos del host de sesión y Colaborador de Desktop Virtualization en el grupo de hosts).
- Utilice entidades de servicio (service principals) con credenciales de certificado para las canalizaciones (pipelines) de DevOps que publican grupos de aplicaciones o actualizan las propiedades de RDP. Limite sus permisos a los recursos de AVD específicos que administran.
Privileged Identity Management y acceso de emergencia
- Utilice Microsoft Entra Privileged Identity Management tanto para los roles de Azure RBAC como para los de Microsoft Entra. Haga que los roles de alto riesgo, como Administrador de Desktop Virtualization y Propietario de la suscripción, sean elegibles y requieran MFA, aprobaciones y justificación.
- Mantenga al menos dos cuentas de Administrador global de acceso de emergencia (break-glass), excluidas del Acceso Condicional y de PIM, almacenadas fuera de línea, probadas periódicamente y utilizadas solo para recuperación.
Ejemplos breves para la delimitación de roles:
# 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
Acceso condicional, MFA y controles de sesión
Aplicaciones en la nube de destino
- Aplica el acceso condicional tanto a Azure Virtual Desktop como a Azure Virtual Desktop Azure Resource Manager para proteger las conexiones de los usuarios finales y las acciones administrativas. Excluye las cuentas de emergencia (break-glass) y las identidades de cargas de trabajo no interactivas.
Autenticación multifactor y niveles de seguridad de la autenticación
- Exige MFA para todos los inicios de sesión externos o de alto riesgo. Utiliza los niveles de seguridad de la autenticación para exigir métodos resistentes al phishing (por ejemplo, claves de seguridad FIDO2, claves de acceso (passkeys) vinculadas al dispositivo en Microsoft Authenticator o autenticación basada en certificados).
- Para una mejor experiencia de usuario con el cliente de Windows, combina la MFA resistente al phishing con el inicio de sesión único (SSO) de AVD para que los usuarios se autentiquen una vez en Entra ID y se les inicie sesión de forma transparente en la sesión de Windows.
Cumplimiento de dispositivos y señales de Intune
- Para restringir el acceso a los puntos de conexión administrados, utiliza el acceso condicional con la condición Require device to be marked as compliant (Requerir que el dispositivo esté marcado como compatible). Esto evalúa el estado de cumplimiento de Microsoft Intune de los dispositivos Windows, macOS, iOS y Android que utilizan el cliente de Escritorio remoto.
- Para dispositivos BYOD o no administrados, utiliza controles alternativos como MFA, directivas basadas en el riesgo de inicio de sesión, términos de uso y limitaciones de sesión. Considera la posibilidad de usar grupos de aplicaciones separados para BYOD con aplicaciones restringidas.
Controles de sesión y frecuencia de inicio de sesión
- Configura una frecuencia de inicio de sesión adecuada para la productividad y el riesgo (por ejemplo, 12 horas) para evitar solicitudes repetidas durante las reconexiones. La sesión de navegador persistente no es aplicable a los clientes nativos de Escritorio remoto. Aprovecha la Evaluación de acceso continuo (Continuous Access Evaluation) donde sea compatible para aplicar cambios de directiva y revocación de riesgos de forma rápida.
Consideraciones de red y ubicación
- Utiliza ubicaciones con nombre para reducir la fricción en las redes de oficina de confianza. Para los trabajadores remotos, combina la MFA y el cumplimiento de dispositivos para mantener una postura de seguridad sólida.
Consideraciones de identidad operativa para los hosts
DNS y unión a un dominio
- Para los hosts unidos a AD DS o Azure AD DS, establezca los servidores DNS de la VNET en las IP de los controladores de dominio o en las IP del dominio administrado antes del aprovisionamiento. Sin un DNS correcto, la unión al dominio fallará y FSLogix, las GPO y Kerberos no funcionarán.
- Para los hosts unidos a Microsoft Entra, no necesita el DNS de AD DS; sin embargo, los destinos SMB de los perfiles todavía requieren capacidad de autenticación moderna (Microsoft Entra Kerberos con Azure Files).
Claves de registro y escalado horizontal
- Para agregar hosts de sesión nuevos o existentes a un grupo de hosts se necesita una clave de registro válida. Limite la vida útil de la clave y restrinja el despliegue de la extensión de la VM únicamente al recurso del grupo de hosts.
Iniciar VM al conectar y autoescalado
- Para las características de autoescalado que desasignan/asignan VMs, asigne a la identidad administrada del plan de escalado el rol Virtual Machine Contributor en el grupo de recursos de las VM de host y el rol Desktop Virtualization Contributor en el grupo de hosts. Evite conceder permisos a nivel de suscripción.
Revisiones de acceso y ciclo de vida de las autorizaciones
- Implemente revisiones de acceso periódicas para los grupos de Entra que están asignados a grupos de aplicaciones. Intégrelo con Entitlement Management cuando el acceso a las aplicaciones abarque múltiples grupos de aplicaciones o recursos.
Auditoría
- Supervise los registros de inicio de sesión y de auditoría de Microsoft Entra para el acceso a las aplicaciones de AVD, y los Azure Activity Logs para los cambios en los recursos de AVD. Transmita los datos a Log Analytics o a un SIEM con alertas para actividades anómalas (por ejemplo, cierres de sesión masivos o asignaciones de roles inesperadas).
Escenario de un problema práctico
Tailwind Traders está habilitando el acceso remoto seguro a aplicaciones de línea de negocio a través de Azure Virtual Desktop para 3000 usuarios. Tienen un bosque de AD local sincronizado con Microsoft Entra ID mediante la sincronización de hashes de contraseña y Seamless SSO. Modernizarán su infraestructura con hosts de sesión unidos a Microsoft Entra para los nuevos grupos, al tiempo que conservarán un grupo híbrido heredado que requiere GPO. Deben aplicar MFA resistente al phishing, permitir el acceso solo desde dispositivos conformes cuando estén fuera de las instalaciones, delegar las operaciones de sesión al equipo de soporte (help-desk) y ejecutar el autoescalado con el mínimo privilegio.
Decidir los modelos de unión de hosts y el DNS
- Acción: Desplegar un nuevo grupo de hosts agrupado con Windows 11 Enterprise multisesión unido a Microsoft Entra para la mayoría de los usuarios; mantener un grupo más pequeño unido en modo híbrido para una aplicación que requiere GPO.
- Por qué: La unión a Entra reduce la dependencia de los controladores de dominio y simplifica el Acceso Condicional. El grupo heredado conserva las GPO necesarias. Para el grupo híbrido, el DNS de la VNET se establece en las IP de los DC locales accesibles a través de VPN para garantizar la unión al dominio y Kerberos.
Almacenamiento de perfiles con autenticación moderna
- Acción: Usar Azure Files con Microsoft Entra Kerberos para FSLogix en el grupo unido a Entra. Configurar los permisos a nivel de recurso compartido y de archivo para los usuarios y las identidades administradas de los hosts de sesión.
- Por qué: Habilita el acceso SMB sin necesidad de un dominio usando Entra ID, eliminando la dependencia de AD DS para los perfiles en el grupo enfocado en la nube (cloud-first).
Autorizaciones basadas en grupos
- Acción: Crear grupos de seguridad de Entra por perfil de usuario (por ejemplo, grp-tt-hr-remoteapps, grp-tt-sales-desktop). Asignar estos grupos a los grupos de aplicaciones correspondientes; evitar grupos anidados.
- Por qué: Centraliza el control de acceso y permite las revisiones de acceso. Las asignaciones directas de grupos son evaluadas de forma fiable por Azure RBAC para AVD.
Acceso Condicional con niveles de seguridad de autenticación
- Acción: Crear políticas dirigidas a Azure Virtual Desktop y Azure Virtual Desktop Azure Resource Manager:
- Requerir el nivel de seguridad de autenticación “MFA resistente al phishing”.
- Para ubicaciones fuera de las oficinas de confianza, requerir también que el dispositivo esté marcado como conforme.
- Establecer la frecuencia de inicio de sesión en 12 horas para los usuarios finales.
- Excluir dos cuentas de emergencia (break-glass) y la identidad administrada de autoescalado.
- Por qué: Aplica factores de autenticación fuertes y acceso desde dispositivos administrados sin peticiones excesivas, y evita bloquear identidades de emergencia o de cargas de trabajo.
- Acción: Crear políticas dirigidas a Azure Virtual Desktop y Azure Virtual Desktop Azure Resource Manager:
Delegar operaciones con el mínimo privilegio
- Acción: Asignar roles en los ámbitos mínimos:
- Desktop Virtualization User a los grupos de autorización en los ámbitos de sus grupos de aplicaciones.
- Desktop Virtualization Session Host Operator al grupo de soporte (help-desk) en cada grupo de hosts.
- Desktop Virtualization Workspace Contributor al equipo de publicación de aplicaciones en el área de trabajo.
- Virtual Machine Contributor al equipo de operaciones únicamente en el grupo de recursos de los hosts de sesión.
- Por qué: Alinea las responsabilidades con los ámbitos que gestionan, evitando el exceso de privilegios a nivel de suscripción.
- Acción: Asignar roles en los ámbitos mínimos:
Configurar el autoescalado con una identidad administrada
- Acción: Habilitar el autoescalado en el grupo de hosts con una identidad administrada asignada por el usuario. Concederle el rol Virtual Machine Contributor en el grupo de recursos de los hosts de sesión y el rol Desktop Virtualization Contributor en el grupo de hosts. Ejemplo:
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
- Por qué: El autoescalado puede iniciar y detener las VM y actualizar las métricas del grupo de hosts sin necesidad de privilegios amplios.
Proteger la administración con PIM y cuentas de emergencia
- Acción: Incorporar los roles RBAC administrativos a Microsoft Entra PIM con flujos de trabajo de aprobación y MFA. Mantener dos cuentas de emergencia (break-glass) de tipo Global Administrator excluidas del Acceso Condicional y de PIM.
- Por qué: Reduce los privilegios permanentes y garantiza la recuperabilidad si el Acceso Condicional o los servicios de identidad se configuran incorrectamente.
Supervisar y revisar el acceso periódicamente
- Acción: Transmitir los registros de inicio de sesión de Entra y los Azure Activity Logs a Log Analytics. Realizar revisiones de acceso trimestrales para los grupos asignados a los grupos de aplicaciones y para los roles de operador de soporte (help-desk).
- Por qué: Mantiene el principio de mínimo privilegio a lo largo del tiempo y detecta anomalías como aumentos inesperados en los inicios de sesión denegados en AVD o terminaciones masivas de sesiones.
Este enfoque combina una identidad orientada a la nube (cloud-first) con un alcance preciso y políticas de acceso robustas, equilibra la experiencia del usuario con la seguridad y garantiza que las operaciones y la automatización solo deleguen los permisos necesarios.
← Arquitectura y diseño del servicio de Azure Virtual Desktop · Todos los dominios · Redes →
Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Aprueba tu examen →