Microsoft AZ-140: Identità, accesso e governance — Guida allo studio

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

Fa parte della Microsoft Azure Virtual Desktop Specialty AZ-140 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Identità, accesso e governance definiscono come utenti, dispositivi e automazione interagiscono con le risorse di Azure Virtual Desktop. Un design robusto allinea Microsoft Entra ID come piano di controllo dell’identità, applica autorizzazioni con privilegi minimi tramite Azure RBAC con ambito limitato alle risorse AVD, impone l’accesso condizionale e l’autenticazione a più fattori e rende operativa l’automazione con le identità gestite. Decisioni come quella se gli host di sessione debbano essere aggiunti a Microsoft Entra (Microsoft Entra joined) o in modalità ibrida (hybrid Microsoft Entra joined) determinano i requisiti a valle per DNS, autenticazione, archiviazione dei profili e comportamento dell’Accesso Condizionale.

Progettazione di Identità e Directory

Tenant, utenti e gruppi di Microsoft Entra ID
- Il piano di controllo di AVD è nativo di Microsoft Entra ID. Gli utenti devono esistere nel tenant proprietario delle risorse AVD o essere utenti guest B2B con le assegnazioni appropriate.
- Utilizzare i gruppi di sicurezza di Microsoft Entra, statici o dinamici, per le assegnazioni ai gruppi di applicazioni e per l’amministrazione basata sui ruoli. Evitare gruppi annidati per le assegnazioni di ruolo AVD; Azure RBAC non valuta l’appartenenza annidata per le assegnazioni di ruolo.
Assegnazione basata su gruppi ai gruppi di applicazioni AVD
- Gli utenti ottengono il diritto ad app o desktop remoti tramite l’assegnazione di utenti o gruppi al gruppo di applicazioni. Al momento dell’autorizzazione, Azure applica a tali principal un’assegnazione di ruolo di Desktop Virtualization User con ambito limitato al gruppo di applicazioni.
- Preferire le assegnazioni a gruppi rispetto a quelle a singoli utenti per semplificare la gestione del ciclo di vita e le revisioni degli accessi. Utilizzare gruppi dinamici basati su attributi utente o reparto per mappare gli utenti ai corretti gruppi di applicazioni RemoteApp o Desktop.
Host di sessione aggiunti a Microsoft Entra (joined) rispetto a quelli aggiunti in modalità ibrida (hybrid joined)
- Aggiunti a Microsoft Entra (Microsoft Entra joined): Nessuna connettività diretta (line-of-sight) ai controller di dominio tradizionali. Ideale per implementazioni cloud-first. Supporta l’autenticazione moderna e l’SSO alla sessione con Microsoft Entra ID. Per FSLogix, utilizzare Azure Files con Microsoft Entra Kerberos in modo che gli host si autentichino ai profili senza AD DS.
- Aggiunti in modalità ibrida a Microsoft Entra (hybrid Microsoft Entra joined) (aggiunti al dominio AD DS e registrati in Entra ID): Necessario se si devono utilizzare Group Policy esistenti, Kerberos/NTLM on-premise o destinazioni SMB che richiedono AD DS. Assicurarsi che il DNS della VNET punti a controller di dominio in grado di risolvere e servire il dominio. Se si utilizza Azure AD DS (dominio gestito), impostare i server DNS della VNET sugli IP del dominio gestito prima di aggiungere gli host di sessione al dominio.
Identità ibrida, Microsoft Entra Connect, sincronizzazione degli hash delle password e Seamless SSO
- Utilizzare Microsoft Entra Connect per sincronizzare le identità utente da AD DS. La sincronizzazione degli hash delle password è il metodo di accesso più semplice e resiliente e supporta l’Accesso Condizionale lato cloud.
- Abilitare il Seamless SSO in modo che i dispositivi aziendali sulla rete interna possano ottenere un single sign-on basato su Kerberos verso Entra ID senza che vengano richieste le credenziali. Ciò migliora l’esperienza utente durante l’avvio di AVD da reti gestite, pur consentendo l’applicazione dell’Accesso Condizionale.

Controllo degli Accessi e Privilegio Minimo

Ruoli RBAC di Azure predefiniti per AVD
- Desktop Virtualization Administrator: Pieno controllo amministrativo sulle risorse AVD.
- Desktop Virtualization Contributor: Gestisce le risorse AVD senza concedere l’accesso agli utenti finali.
- Desktop Virtualization Reader: Visualizza le risorse AVD.
- Desktop Virtualization Host Pool Contributor: Gestisce le impostazioni del pool di host e le chiavi di registrazione; non ha il pieno controllo su altre risorse AVD.
- Desktop Virtualization Workspace Contributor: Pubblica o rimuove gruppi di applicazioni da un’area di lavoro.
- Desktop Virtualization Application Group Contributor: Gestisce le proprietà dei gruppi di applicazioni e le app pubblicate; non concede l’accesso agli utenti.
- Desktop Virtualization Session Host Operator: Orientato all’help-desk; visualizza gli host di sessione, le sessioni utente, invia messaggi, disconnette o scollega le sessioni.
- Desktop Virtualization User: Assegnato a utenti/gruppi a livello del gruppo di applicazioni per autorizzare gli avvii.
Ambiti e modelli di assegnazione dei ruoli
- Limitare l’ambito delle autorizzazioni il più strettamente possibile:
  - Assegnare il ruolo Desktop Virtualization User a utenti/gruppi solo a livello del gruppo di applicazioni.
  - Assegnare Application Group Contributor al gruppo di app; Workspace Contributor all’area di lavoro; Host Pool Contributor al pool di host.
  - Assegnare il ruolo Virtual Machine Contributor e i ruoli correlati a calcolo/archiviazione/rete a livello del gruppo di risorse che contiene le VM degli host di sessione, se il personale operativo deve gestire l’alimentazione, le dimensioni o le interfacce di rete dei guest.
- Separare i gruppi di risorse per gli oggetti del piano di controllo (aree di lavoro, pool di host, gruppi di applicazioni) e per le VM degli host di sessione migliora la definizione dell’ambito e la verificabilità.
Identità gestite, principal di servizio e automazione delegata
- Preferire le identità gestite assegnate dal sistema o dall’utente per la scalabilità automatica di AVD e per i runbook operativi. Concedere solo i ruoli necessari, con l’ambito minimo, per manipolare le risorse di destinazione (ad esempio, Virtual Machine Contributor sul gruppo di risorse degli host di sessione e Desktop Virtualization Contributor sul pool di host).
- Utilizzare principal di servizio con credenziali basate su certificato per le pipeline DevOps che pubblicano gruppi di app o aggiornano le proprietà RDP. Confinare le loro autorizzazioni alle specifiche risorse AVD che gestiscono.
Privileged Identity Management e accesso di emergenza
- Utilizzare Microsoft Entra Privileged Identity Management sia per i ruoli Azure RBAC che per i ruoli Microsoft Entra. Rendere i ruoli ad alto rischio, come Desktop Virtualization Administrator e Subscription Owner, idonei (eligible) e richiedere MFA, approvazioni e giustificazioni.
- Mantenere almeno due account di accesso di emergenza (break-glass) di tipo Global Administrator, esclusi dall’Accesso Condizionale e da PIM, conservati offline, testati periodicamente e utilizzati solo per il ripristino.

Brevi esempi per la definizione dell’ambito dei ruoli:

# 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

Accesso condizionale, MFA e controlli di sessione

Applicazioni cloud da designare come target
- Applicare l’Accesso condizionale sia ad Azure Virtual Desktop che ad Azure Virtual Desktop Azure Resource Manager per proteggere le connessioni degli utenti finali e le azioni amministrative. Escludere gli account di emergenza (break-glass) e le identità dei carichi di lavoro non interattivi.
Autenticazione a più fattori e livelli di autenticazione
- Richiedere l’MFA per tutti gli accessi esterni o ad alto rischio. Utilizzare i livelli di autenticazione (authentication strengths) per imporre metodi resistenti al phishing (ad esempio, chiavi di sicurezza FIDO2, passkey associate al dispositivo in Microsoft Authenticator o autenticazione basata su certificato).
- Per la migliore esperienza utente con il client Windows, abbinare l’MFA resistente al phishing con il single sign-on di AVD, in modo che gli utenti si autentichino una sola volta su Entra ID e accedano senza interruzioni alla sessione di Windows.
Conformità dei dispositivi e segnali di Intune
- Per limitare l’accesso agli endpoint gestiti, utilizzare l’Accesso condizionale con l’opzione Richiedi che il dispositivo sia contrassegnato come conforme. Questo valuta lo stato di conformità di Microsoft Intune da dispositivi Windows, macOS, iOS e Android che utilizzano il client Desktop remoto.
- Per i dispositivi BYOD o non gestiti, utilizzare controlli alternativi come MFA, policy basate sul rischio di accesso, Condizioni d’uso e limitazioni di sessione. Considerare gruppi di applicazioni separati per il BYOD con app soggette a restrizioni.
Controlli di sessione e frequenza di accesso
- Configurare una frequenza di accesso appropriata per la produttività e il rischio (ad esempio, 12 ore) per evitare richieste ripetute durante le riconnessioni. La sessione persistente del browser non è applicabile ai client Desktop remoto nativi. Sfruttare la Valutazione continua dell’accesso (Continuous Access Evaluation), dove supportata, per modifiche rapide delle policy e revoca del rischio.
Considerazioni su rete e posizione
- Utilizzare le posizioni denominate (named locations) per ridurre l’attrito per le reti aziendali attendibili. Per i lavoratori da remoto, combinare l’MFA e la conformità dei dispositivi per mantenere una postura di sicurezza solida.

Considerazioni sull’identità operativa per gli host

DNS e aggiunta al dominio
- Per gli host aggiunti ad AD DS o Azure AD DS, impostare i server DNS della VNET sugli IP dei controller di dominio o sugli IP del dominio gestito prima del provisioning. Senza un DNS corretto, l’aggiunta al dominio fallirà e FSLogix, GPO e Kerberos non saranno operativi.
- Per gli host aggiunti a Microsoft Entra, non è necessario il DNS di AD DS; tuttavia, le destinazioni SMB dei profili richiedono comunque la capacità di autenticazione moderna (Microsoft Entra Kerberos con Azure Files).
Chiavi di registrazione e scale-out
- L’aggiunta di host di sessione esistenti o nuovi a un host pool richiede una chiave di registrazione valida. Limitare la durata della chiave e definire l’ambito (scope) della distribuzione dell’estensione VM alla sola risorsa dell’host pool.
Start VM on Connect e autoscale
- Per le funzionalità di autoscale che deallocano/allocano le VM, assegnare all’identità gestita del piano di scalabilità il ruolo Virtual Machine Contributor sul gruppo di risorse delle VM host e il ruolo Desktop Virtualization Contributor sull’host pool. Evitare di concedere autorizzazioni a livello di sottoscrizione.
Revisioni dell’accesso e ciclo di vita delle autorizzazioni
- Implementare revisioni periodiche dell’accesso per i gruppi Entra assegnati ai gruppi di applicazioni. Integrare con Entitlement Management quando l’accesso alle applicazioni si estende su più gruppi di app o risorse.
Auditing
- Monitorare i log di accesso e di audit di Microsoft Entra per l’accesso alle app AVD e gli Azure Activity Logs per le modifiche alle risorse AVD. Inviare i dati in streaming a Log Analytics o a un SIEM con avvisi per attività anomale (ad esempio, disconnessioni di massa dalle sessioni o assegnazioni di ruolo inaspettate).

Scenario di un problema pratico

Tailwind Traders sta abilitando l’accesso remoto sicuro alle applicazioni line-of-business tramite Azure Virtual Desktop per 3.000 utenti. Hanno una foresta AD on-premise sincronizzata con Microsoft Entra ID tramite la sincronizzazione degli hash delle password e il Seamless SSO. Intendono modernizzare l’infrastruttura con host di sessione aggiunti a Microsoft Entra per i pool di nuova creazione, mantenendo al contempo un pool ibrido legacy che richiede le GPO. Devono imporre l’MFA resistente al phishing, consentire l’accesso solo da dispositivi conformi quando si è fuori sede, delegare le operazioni di sessione all’help-desk ed eseguire l’autoscale con il principio del privilegio minimo (least privilege).

Decidere i modelli di join degli host e il DNS
- Azione: Distribuire un nuovo host pool condiviso (pooled) con host Windows 11 Enterprise multi-sessione aggiunti a Microsoft Entra per la maggior parte degli utenti; mantenere un pool più piccolo aggiunto in modalità ibrida (hybrid-joined) per un’app che richiede le GPO.
- Perché: L’aggiunta a Entra riduce la dipendenza dai controller di dominio e semplifica il Conditional Access. Il pool legacy preserva le GPO necessarie. Per il pool ibrido, il DNS della VNET è impostato sugli IP dei DC on-premise, raggiungibili tramite VPN, per garantire l’aggiunta al dominio e il funzionamento di Kerberos.
Archiviazione dei profili con autenticazione moderna
- Azione: Utilizzare Azure Files con Microsoft Entra Kerberos per FSLogix per il pool aggiunto a Entra. Configurare le autorizzazioni a livello di condivisione e di file per gli utenti e per le identità gestite degli host di sessione.
- Perché: Abilita l’accesso SMB senza dominio utilizzando Entra ID, eliminando la dipendenza da AD DS per i profili nel pool cloud-first.
Autorizzazioni basate su gruppi
- Azione: Creare gruppi di sicurezza Entra per ogni “persona” (ad esempio, grp-tt-hr-remoteapps, grp-tt-sales-desktop). Assegnare questi gruppi ai gruppi di applicazioni appropriati; evitare i gruppi annidati.
- Perché: Centralizza il controllo degli accessi e abilita le revisioni dell’accesso. Le assegnazioni dirette ai gruppi vengono valutate in modo affidabile da Azure RBAC per AVD.
Conditional Access con livelli di autenticazione (authentication strengths)
- Azione: Creare policy che hanno come destinazione (target) Azure Virtual Desktop e Azure Virtual Desktop Azure Resource Manager:
  - Richiedere il livello di autenticazione “Phishing-resistant MFA”.
  - Per le postazioni al di fuori degli uffici considerati attendibili (trusted), richiedere anche che il dispositivo sia contrassegnato come conforme (compliant).
  - Impostare la frequenza di accesso (sign-in frequency) a 12 ore per gli utenti finali.
  - Escludere due account di emergenza (break-glass) e l’identità gestita per l’autoscale.
- Perché: Impone l’uso di fattori di autenticazione forti e l’accesso da dispositivi gestiti senza richieste eccessive, ed evita di bloccare le identità di emergenza o di workload.
Delegare le operazioni con il principio del privilegio minimo
- Azione: Assegnare i ruoli agli ambiti (scope) minimi:
  - Desktop Virtualization User ai gruppi di autorizzazione (entitlement groups) sugli ambiti dei loro gruppi di applicazioni.
  - Desktop Virtualization Session Host Operator al gruppo di help-desk a livello di ogni host pool.
  - Desktop Virtualization Workspace Contributor al team di pubblicazione delle app a livello del workspace.
  - Virtual Machine Contributor al team operativo (ops team) solo sul gruppo di risorse degli host di sessione.
- Perché: Allinea i compiti agli ambiti che gestiscono, prevenendo privilegi eccessivi a livello di sottoscrizione.
Configurare l’autoscale con un’identità gestita
- Azione: Abilitare l’autoscale sull’host pool con un’identità gestita assegnata dall’utente. Concederle il ruolo Virtual Machine Contributor sul gruppo di risorse degli host di sessione e il ruolo Desktop Virtualization Contributor sull’host pool. Esempio:

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

Perché: L’autoscale può avviare e arrestare le VM e aggiornare le metriche dell’host pool senza privilegi estesi.

Proteggere l’amministrazione con PIM e account di emergenza (break-glass)
- Azione: Integrare (onboard) i ruoli RBAC amministrativi in Microsoft Entra PIM con flussi di lavoro di approvazione e MFA. Mantenere due account Global Administrator di emergenza (break-glass) esclusi dal Conditional Access e da PIM.
- Perché: Riduce i privilegi permanenti (standing privilege) e garantisce la recuperabilità in caso di errata configurazione del Conditional Access o dei servizi di identità.
Monitorare e revisionare l’accesso periodicamente
- Azione: Inviare in streaming i log di accesso di Entra e gli Azure Activity Logs a Log Analytics. Eseguire revisioni trimestrali dell’accesso per i gruppi assegnati ai gruppi di applicazioni e per i ruoli di operatore dell’help-desk.
- Perché: Mantiene il principio del privilegio minimo nel tempo e rileva anomalie come aumenti imprevisti di accessi AVD negati o terminazioni di massa delle sessioni.

Questo approccio combina un’identità cloud-first con uno scoping preciso e policy di accesso rigorose, bilancia l’esperienza utente con la sicurezza e garantisce che alle operazioni e all’automazione vengano delegati solo i diritti necessari.

← Architettura e progettazione del servizio Azure Virtual Desktop · Tutti i domini · Networking →

Esercitati su queste domande → · Pratica cronometrata su ExamRoll.io →