Raccomandazioni sulla sicurezza per Desktop virtuale Azure

Completato

Desktop virtuale Azure è un servizio desktop virtuale gestito che include molte funzionalità di sicurezza per garantire la sicurezza dell'organizzazione. L'architettura di Desktop virtuale Azure comprende molti componenti che costituiscono il servizio che connette gli utenti ai desktop e alle app.

Desktop virtuale Azure include molte funzionalità di sicurezza avanzate predefinite, ad esempio Reverse Connect, in cui non è necessario aprire porte di rete in ingresso, che riducono i rischi correlati alla possibilità di accedere a desktop remoti ovunque ci si trovi. Il servizio trae vantaggio anche da numerose altre funzionalità di sicurezza di Azure, ad esempio l'autenticazione a più fattori e l'accesso condizionale. Il presente articolo descrive i passaggi che è possibile eseguire come amministratore per proteggere le distribuzioni di Desktop virtuale Azure, indipendentemente dal fatto che si forniscano desktop e app agli utenti dell'organizzazione o agli utenti esterni.

Responsabilità condivise della sicurezza

Prima di Desktop virtuale Azure, le soluzioni di virtualizzazione locali come Servizi Desktop remoto richiedono la concessione agli utenti dell'accesso a ruoli quali Gateway, Broker, Accesso Web e così via. Questi ruoli devono essere completamente ridondanti e in grado di gestire la capacità massima. Gli amministratori installavano questi ruoli come parte del sistema operativo Windows Server e dovevano essere aggiunti a un dominio con porte specifiche accessibili alle connessioni pubbliche. Per garantire la sicurezza delle distribuzioni, gli amministratori dovevano assicurarsi costantemente che tutti gli elementi dell'infrastruttura fossero gestiti ed aggiornati.

Nella maggior parte dei servizi cloud, tuttavia, esiste un set condiviso di responsabilità di sicurezza tra Microsoft e il cliente o il partner. Per Desktop virtuale Azure, la maggior parte dei componenti è gestita da Microsoft, ma gli host di sessione e alcuni servizi e componenti di supporto sono gestiti dal cliente o dai partner. Per altre informazioni sui componenti gestiti da Microsoft di Desktop virtuale Azure, vedere Architettura e resilienza del servizio Desktop virtuale Azure.

Sebbene alcuni componenti siano già protetti per l'ambiente in uso, sarà necessario configurare autonomamente altre aree in modo che si adattino alle esigenze di sicurezza dell'organizzazione o del cliente. Ecco i componenti di cui si è responsabili della sicurezza nella distribuzione di Desktop virtuale Azure:

Componente	Responsabilità
Identità	Cliente o partner
Dispositivi utente (dispositivo mobile e PC)	Cliente o partner
Sicurezza delle app	Cliente o partner
Sistema operativo host sessione	Cliente o partner
Configurazione della distribuzione	Cliente o partner
Controlli di rete	Cliente o partner
Piano di controllo della virtualizzazione	Microsoft
Host fisici	Microsoft
Rete fisica	Microsoft
Data center fisico	Microsoft

Limiti di sicurezza

I limiti di sicurezza separano il codice e i dati dei domini di sicurezza in base a livelli di attendibilità diversi. Ad esempio, esiste in genere un limite di sicurezza tra la modalità kernel e la modalità utente. La maggior parte dei software e dei servizi Microsoft dipende da più limiti di sicurezza per isolare i dispositivi su reti, macchine virtuali e applicazioni nei dispositivi. La tabella seguente elenca ogni limite di sicurezza per Windows e le operazioni eseguite per la sicurezza generale.

Limite di sicurezza	Descrizione
Limite di rete	Un endpoint di rete non autorizzato non può accedere o manomettere il codice e i dati nel dispositivo di un cliente.
Limite del kernel	Un processo in modalità utente non amministrativa non può accedere o manomettere il codice e i dati del kernel. Da amministratore a kernel non è un limite di sicurezza.
Limite del processo	Un processo in modalità utente non autorizzato non può accedere o manomettere il codice e i dati di un altro processo.
Limite sandbox AppContainer	Un processo sandbox basato su AppContainer non può accedere o manomettere il codice e i dati all'esterno della sandbox in base alle funzionalità del contenitore.
Limite utente	Un utente non può accedere o manomettere il codice e i dati di un altro utente senza essere autorizzato.
Limite sessione	Una sessione utente non può accedere o manomettere un'altra sessione utente senza essere autorizzata.
Limite del Web browser	Un sito Web non autorizzato non può violare i criteri della stessa origine, né può accedere o manomettere il codice nativo e i dati della sandbox del Web browser Microsoft Edge.
Limite della macchina virtuale	Una macchina virtuale guest Hyper-V non autorizzata non può accedere o manomettere il codice e i dati di un'altra macchina virtuale guest; ciò include i contenitori isolati di Hyper-V.
Limite della modalità protetta virtuale (VSM)	Il codice in esecuzione all'esterno del processo attendibile o dell'enclave VSM non può accedere o manomettere i dati e il codice all'interno del processo attendibile.

Limiti di sicurezza consigliati per gli scenari di Desktop virtuale Azure

È anche necessario effettuare alcune scelte sui limiti di sicurezza caso per caso. Ad esempio, se un utente dell'organizzazione richiede privilegi di amministratore locale per installare le app, è necessario assegnargli un desktop personale, anziché un host di sessione condiviso. Non è consigliabile concedere agli utenti privilegi di amministratore locale in scenari in pool multisessione perché questi utenti possono superare i limiti di sicurezza per sessioni o autorizzazioni di dati NTFS, arrestare le macchine virtuali multisessione o eseguire altre operazioni che potrebbero interrompere il servizio o causare perdite di dati.

Gli utenti della stessa organizzazione, come i knowledge worker con app che non richiedono privilegi di amministratore, sono ottimi candidati per gli host di sessioni multisessione come Windows 11 Enterprise multisessione. Questi host di sessione riducono i costi per l'organizzazione perché più utenti possono condividere una singola macchina virtuale, a fronte del pagamento di solo i costi generali di una macchina virtuale per utente. Con i prodotti di gestione dei profili utente come FSLogix, gli utenti possono essere assegnati a qualsiasi macchina virtuale in un pool di host senza notare interruzioni del servizio. Questa funzionalità consente anche di ottimizzare i costi, eseguendo operazioni come l'arresto delle macchine virtuali durante le ore di minore attività.

Se la situazione richiede agli utenti di organizzazioni diverse di connettersi alla distribuzione, è consigliabile disporre di un tenant separato per i servizi di gestione delle identità, ad esempio Active Directory e Microsoft Entra ID. È anche consigliabile avere una sottoscrizione separata per gli utenti per l'hosting di risorse di Azure, ad esempio Desktop virtuale Azure e macchine virtuali.

In molti casi, l'uso di più sessioni risulta un modo accettabile per ridurre i costi, ma la raccomandazione dipende dal livello di attendibilità tra gli utenti con accesso simultaneo a un'istanza condivisa di più sessioni. In genere, gli utenti che appartengono alla stessa organizzazione hanno una relazione di trust sufficiente e concordata. Ad esempio, un reparto o un gruppo di lavoro in cui le persone collaborano e possono accedere alle informazioni personali reciproche rappresenta un'organizzazione con un livello di trust elevato.

Windows si avvale dei limiti di sicurezza e dei controlli per garantire che i processi e i dati degli utenti siano isolati tra le sessioni. Tuttavia, Windows fornisce ancora l'accesso all'istanza su cui l'utente sta lavorando.

Le distribuzioni multisessione traggono vantaggio da una strategia di sicurezza approfondita che aggiunge più limiti di sicurezza che impediscono agli utenti all'interno e all'esterno dell'organizzazione di ottenere l'accesso non autorizzato alle informazioni personali di altri. L'accesso non autorizzato ai dati si verifica a causa di un errore nel processo di configurazione da parte dell'amministratore di sistema, ad esempio una vulnerabilità di sicurezza non divulgata o una vulnerabilità nota a cui non è ancora stata applicata una patch.

Non è consigliabile concedere l'accesso allo stesso ambiente multisessione a utenti che lavorano per aziende diverse o concorrenti. Questi scenari hanno diversi limiti di sicurezza che possono essere attaccati o utilizzati in modo improprio, ad esempio rete, kernel, processo, utente o sessioni. Una singola vulnerabilità di sicurezza potrebbe causare furti di dati e credenziali non autorizzati, perdite di informazioni personali, furti di identità e altri problemi. I fornitori di ambienti virtualizzati hanno la responsabilità di offrire sistemi ben progettati, con molteplici e solidi limiti di sicurezza e funzioni di sicurezza aggiuntive attivate ove possibile.

La tabella riepiloga le raccomandazioni per ogni scenario.

Scenario a livello di attendibilità	Soluzione consigliata
Utenti di un'organizzazione con privilegi standard	Utilizzare un sistema operativo Windows Enterprise multisessione.
Gli utenti richiedono privilegi amministrativi	Usare un pool di host personale e assegnare a ciascun utente il proprio host di sessione.
Utenti di organizzazioni diverse che si connettono	Separare il tenant di Azure e la sottoscrizione di Azure