Microsoft AZ-801: Hyper-V, Virtualizzazione e Archiviazione — Guida allo studio

By Laurynas Brazys · 7 August 2026 · #microsoft #az-801 #certification #exam-prep #study-guide

Fa parte della Microsoft Windows Server Hybrid Administrator Associate AZ-801 — Guida allo studio. Esercitati con risposte verificate nel centro esami Microsoft, oppure fai test cronometrati su ExamRoll.io.

Panoramica

Hyper-V e lo storage software-defined di Windows Server formano una piattaforma coesa per carichi di lavoro sicuri, isolati e ad alta disponibilità. La piena padronanza richiede la comprensione di come le infrastrutture sorvegliate (guarded fabric) proteggano le VM dei tenant dagli amministratori dell’infrastruttura, di come la Virtualization-Based Security (VBS) rafforzi il sistema operativo con un isolamento basato sull’hardware, di come la rete di Hyper-V imponga l’isolamento e di come la replica, i checkpoint e il clustering si comportino sotto carico e in caso di guasto. Questa sezione spiega il modello di sicurezza per le VM schermate (shielded VM) e il rafforzamento (hardening) degli host, approfondisce i costrutti di isolamento di rete, tratta la durabilità tramite Hyper-V Replica e la meccanica dei checkpoint, e si conclude con Storage Spaces Direct (S2D), Cluster Shared Volumes (CSV) e la progettazione del quorum nel Failover Clustering.

Virtualizzazione sicura e protezione dei carichi di lavoro

Le VM schermate (Shielded VM) proteggono le risorse dei tenant dall’accesso all’infrastruttura (fabric). L’Host Guardian Service (HGS) funge da ancora di attendibilità (trust anchor), fornendo due servizi: attestazione (convalida lo stato di integrità dell’host) e protezione delle chiavi (rilascia le chiavi per sbloccare il TPM virtuale della VM). HGS viene distribuito in una foresta o in un dominio dedicato e blindato (locked-down) per minimizzare il rischio di compromissione. Esistono due modalità di attestazione:

Attestazione basata su TPM (TPM-trusted): la garanzia più forte. Gli host Hyper-V richiedono TPM 2.0, Secure Boot, l’applicazione di policy di integrità del codice e l’avvio misurato (measured boot). HGS verifica i log dell’avvio misurato e l’identità dell’host prima di rilasciare la protezione della chiave al vTPM della VM.
Attestazione basata su amministratore (Active Directory): una garanzia più leggera. Gli host dimostrano l’attendibilità tramite l’appartenenza a un gruppo AD e metadati dell’host pubblicati. Non viene valutata alcuna prova di avvio misurato, quindi è più facile da avviare ma meno resistente alle manomissioni.

I ruoli di amministratore dell’infrastruttura (fabric) e del tenant sono deliberatamente separati. Gli amministratori dell’infrastruttura gestiscono host, cluster, storage e rete, ma non possono ispezionare i dischi delle VM schermate, collegare debugger o utilizzare la console/PowerShell Direct. Gli amministratori dei tenant creano la VM, possiedono le credenziali del sistema operativo e creano i dati di schermatura (shielding data), un pacchetto sigillato contenente un file di risposte unattend, un certificato RDP e le chiavi di protezione (guardian keys), per controllare dove la VM può essere eseguita. Le VM schermate utilizzano BitLocker all’interno del sistema operativo guest, ancorato a un vTPM, e solo gli host sorvegliati (guarded host) attestati da HGS ricevono i segreti necessari per l’avvio.

La Virtualization-Based Security (VBS) eleva il confine di sicurezza al di sopra del kernel creando la Virtual Secure Mode (VSM). Con la VBS, l’hypervisor impone i Virtual Trust Levels (VTL), isolando i componenti sensibili in VTL1 insieme a un kernel sicuro. Le funzionalità includono:

Credential Guard: i segreti di LSASS risiedono in un processo isolato (LSAISO) in VSM; il sistema operativo normale (VTL0) non può leggerne direttamente la memoria.
Hypervisor-Enforced Code Integrity (HVCI): viene eseguito solo il codice del kernel che soddisfa i moderni requisiti di firma e integrità; gli attacchi DMA sono mitigati con l’IOMMU. I requisiti includono UEFI con Secure Boot, virtualizzazione della CPU con SLAT (Intel EPT/AMD NPT) e IOMMU (Intel VT-d/AMD-Vi). La configurazione avviene tramite Criteri di gruppo (Group Policy): attivare la Virtualization Based Security, quindi abilitare Credential Guard e HVCI; bloccare la configurazione con Secure Boot per impedire il rollback. Insieme alle VM di seconda generazione, a Secure Boot e al vTPM, VBS/VSM fornisce un robusto rafforzamento (hardening) sia per gli host che per i guest.

Isolamento di rete, replica e checkpoint di Hyper-V

Gli switch virtuali di Hyper-V applicano l’isolamento di Layer 2/L3:

Gli switch esterni si collegano a una NIC fisica (o a un team SET) per raggiungere la LAN. Utilizzare adattatori separati per il traffico di gestione e tenant per evitare contaminazioni.
Gli switch interni connettono le VM solo all’host; non esiste un uplink esterno.
Gli switch privati connettono le VM solo tra loro; non esiste connettività né con l’host né con la LAN. Le VLAN segmentano i domini L2. Assegnare una VLAN di accesso per ogni NIC della VM per un isolamento semplice, oppure abilitare la modalità trunk per trasportare più VLAN verso un’appliance guest consapevole delle VLAN (VLAN-aware). Le Port ACL su una scheda di rete della VM aggiungono un filtro stateless a 5 tuple (IP di origine/destinazione, protocollo, porta) con direzioni (in/out/entrambe) e azioni (allow/deny/meter). Le Port ACL sono applicate dall’host e utili per l’isolamento locale e un controllo rudimentale del traffico in uscita (egress), ma non sostituiscono un firewall completo.

Hyper-V Replica fornisce una replica asincrona per singola VM senza richiedere uno storage condiviso. Un server è il primario (che invia i log delle modifiche) e un altro è la replica (che riceve i delta basati su AVHDX). Gli intervalli di replica sono di 30 secondi, 5 minuti o 15 minuti. Opzioni di autenticazione:

Kerberos (HTTP 80): semplice per server membri di un dominio; il traffico non è crittografato. Usare IPsec se è richiesta la crittografia in transito.
Basata su certificati (HTTPS 443): crittografata con TLS, funziona attraverso reti non attendibili e workgroup. Pianificare di conseguenza le aperture sul firewall, configurare l’autorizzazione sulla replica e selezionare lo storage per la replica. Tipi di failover:
Test Failover: avvia una VM di test isolata sulla replica senza impattare la protezione.
Planned Failover: switchover orchestrato; il primario viene spento, i log rimanenti vengono inviati, ottenendo un RPO a zero perdita di dati in presenza di connettività sana. Supporta la replica inversa per ristabilire la protezione.
Unplanned Failover: invocato quando il primario non è disponibile; l’RPO è uguale all’ultimo log ricevuto. La replica estesa può inoltrare le modifiche dalla replica a un sito terziario, aumentando la ridondanza.

I checkpoint acquisiscono uno stato point-in-time per il ripristino e per attività di sviluppo/test. I checkpoint standard salvano la memoria della VM e lo stato dei dispositivi, consentendo rollback istantanei ma potendo compromettere la consistenza dell’applicazione. I checkpoint di produzione usano il VSS all’interno del guest (Windows) o il flush del file system (Linux) per creare un’immagine consistente a livello applicativo senza lo stato della memoria; sono appropriati per i flussi di lavoro di backup e per punti di ripristino di lunga durata. Lo storage è implementato come dischi differenziali AVHDX incatenati al VHDX di base. L’applicazione o l’eliminazione di un checkpoint esegue il merge della catena di differenze nel suo disco padre online; merge di grandi dimensioni creano pressione sull’I/O, quindi è bene mantenere un margine di performance (headroom) adeguato ed evitare alberi di dipendenze profondi. Per i domain controller e le app distribuite, i checkpoint di produzione mitigano il rollback degli USN e problemi correlati; i checkpoint standard sono più adatti per attività di sviluppo/test di breve durata.

Funzionalità dell’host, virtualizzazione nidificata e sicurezza della generazione di VM

Le VM di Generazione 2 si avviano tramite UEFI, supportando Secure Boot e vTPM. Secure Boot verifica i bootloader rispetto a un database attendibile (utilizzare il modello Windows o il modello Linux appropriato). Il vTPM porta la semantica di TPM 2.0 al guest, abilitando BitLocker, il provisioning di Windows Hello for Business e scenari con VM schermate (shielded VM). Laddove i guest più vecchi richiedono BIOS o dispositivi legacy, le VM di Generazione 1 rimangono disponibili ma sono prive di Secure Boot e vTPM.

La virtualizzazione nidificata abilita Hyper-V all’interno di una VM. I requisiti includono una CPU compatibile (Intel VT-x/EPT o AMD-V/NPT), Windows Server 2016 o successivo sia sull’host che sul guest, e una VM configurata con:

Memoria statica (disabilitare la Dynamic Memory).
Estensioni di virtualizzazione esposte (

undefined

MAC address spoofing per scenari in cui gli host interni forniscono NAT o networking in modalità bridge. I casi d’uso includono l’esecuzione di container isolati con Hyper-V, la creazione di cluster di laboratorio, il test del failover e pipeline di CI che necessitano di hypervisor. Azure supporta la virtualizzazione nidificata su specifiche serie di VM; assicurarsi che la scelta della dimensione sia allineata alla necessità delle estensioni di virtualizzazione.

Archiviazione definita dal software, comportamento dei CSV e quorum

Storage Spaces Direct aggrega le unità disco collegate localmente in un pool a livello di cluster utilizzando SMB3, RDMA e lo stack di clustering. I requisiti del cluster includono l’edizione Windows Server Datacenter, nodi aggiunti a un dominio con NIC omogenee, una rete a banda larga e bassa latenza (10/25/40 GbE; RDMA tramite iWARP o RoCEv2 raccomandato) e hardware convalidato. I domini di errore (fault domain) possono rappresentare nodi, chassis e rack; la loro configurazione migliora il comportamento di posizionamento e riparazione e mitiga i guasti correlati. I tipi di resilienza includono:

Mirror a due vie (min 2 domini di errore): orientato alle prestazioni, tollera un guasto.
Mirror a tre vie (min 3 domini di errore): durabilità superiore, tollera due guasti.
Doppia parità e parità con accelerazione mirror: efficiente in termini di capacità con compromessi nella latenza di scrittura; adatto per carichi di lavoro di archiviazione o misti con cache write-back. I tier di caching associano supporti più veloci (NVMe/SSD) come cache di lettura/scrittura a dischi di capacità (SSD/HDD). La cache write-back assorbe le scritture casuali e le unisce; la regolazione è per singolo volume. Utilizzare ReFS per l’allocazione accelerata, la clonazione di blocchi e i flussi di integrità; si abbina bene con le semantiche di prestazione e riparazione di S2D. Un witness (disco, condivisione file o cloud) è obbligatorio per un S2D a due nodi per sostenere il guasto di un singolo nodo.

I Cluster Shared Volumes (CSV) espongono uno spazio dei nomi coerente (C:\ClusterStorage...) a tutti i nodi, abilitando l’accesso concorrente ai volumi NTFS/ReFS tramite CSVFS. Le operazioni normali utilizzano l’I/O diretto, in cui la coordinazione dei metadati avviene tramite SMB, ma le letture/scritture colpiscono direttamente i percorsi di archiviazione. L’I/O reindirizzato si attiva in determinate condizioni: manutenzione, guasto del percorso di archiviazione, operazioni di snapshot/backup o quando un volume è in pausa. Esistono due modalità di reindirizzamento:

I/O reindirizzato a livello di file system: il traffico attraversa SMB verso il nodo coordinatore.
I/O reindirizzato a livello di blocco: più efficiente per carichi di lavoro pesanti a livello di blocchi, quando necessario. La cache CSV è una cache di lettura nella memoria dell’host che avvantaggia i carichi di lavoro a predominanza di letture, come i dischi padre VHDX e le catene di differenze. Configurare la cache a livello di cluster abilitandola e impostando una dimensione della cache a blocchi appropriata per la RAM disponibile, lasciando un margine per l’host e i carichi di lavoro. Monitorare i rapporti di hit della cache e regolare in modo conservativo per evitare di esaurire la memoria di sistema.

Il quorum del Failover Cluster determina l’operatività del cluster. Le modalità includono:

Maggioranza dei nodi: numero dispari di nodi; sopravvive a floor((N-1)/2) guasti.
Maggioranza di nodi e disco: aggiunge un disco witness che partecipa alla votazione; ideale quando è presente uno storage condiviso.
Maggioranza di nodi e condivisione file: utilizza una condivisione file witness ospitata al di fuori del dominio di errore del cluster.
Cloud Witness: sfrutta un account di Azure Storage per un witness leggero e ad alta disponibilità, ideale per implementazioni multi-sito ed edge. I cluster moderni utilizzano il quorum dinamico e il witness dinamico: i voti vengono regolati in tempo reale per massimizzare la tolleranza ai guasti, e il witness guadagna o perde automaticamente un voto per evitare pareggi. Applicare pesi ai nodi per escludere dalla votazione i nodi inaffidabili, quando necessario. Per i cluster a due nodi, configurare sempre un witness (condivisione file o cloud) per consentire la sopravvivenza al guasto di un singolo nodo.

Scenario di Problema Pratico

Presso Siemens, il team OT/IT deve modernizzare un piccolo sito edge che ospita tre VM Windows Server per la telemetria di produzione. Devono isolare il traffico tra le reti OT e quelle aziendali, proteggere le credenziali sugli host e ottenere resilienza a livello di sito senza storage condiviso.

Creare un failover cluster Hyper-V a due nodi con Storage Spaces Direct

Perché: S2D elimina la necessità di una SAN, fornisce mirroring tra i nodi per la durabilità e si integra con il Failover Clustering per il failover automatico. Viene aggiunto un witness di tipo condivisione file o cloud in modo che il cluster a due nodi possa sostenere il guasto di un singolo nodo.

Abilitare VBS con Credential Guard e HVCI su entrambi gli host

Perché: VBS/VSM isola le credenziali di LSASS e impone l’integrità del codice del kernel, riducendo il rischio di movimento laterale del malware in un ambiente con dispositivi OT eterogenei.

Utilizzare VM di Generazione 2 con Secure Boot e vTPM

Perché: UEFI Secure Boot resiste alle manomissioni da parte di boot-kit; il vTPM abilita BitLocker all’interno della VM per i dati a riposo. Ciò è in linea con il requisito di Siemens di proteggere le configurazioni di telemetria sensibili dal furto nelle sedi remote.

Creare uno switch Hyper-V esterno per ogni uplink fisico e segmentare con VLAN e Port ACL

Perché: Le VLAN separano il traffico OT e quello aziendale sulla stessa infrastruttura fisica, mentre le Port ACL forniscono filtri granulari applicati a livello di host per prevenire il traffico “east-west” tra i tier senza dover implementare appliance virtuali complete nell’edge.

Configurare Hyper-V Replica dal sito edge a un server di replica in un datacenter centrale tramite HTTPS

Perché: L’autenticazione basata su certificati crittografa la replica end-to-end attraverso link WAN non attendibili. Il failover pianificato supporta le finestre di manutenzione; il failover non pianificato offre DR quando il sito edge è offline. La replica inversa ripristina la protezione dopo il failback.

Standardizzare l’uso dei soli checkpoint di produzione

Perché: I checkpoint di produzione generano punti di ripristino coerenti con l’applicazione senza lo stato della memoria, adatti per lo stack di telemetria e più sicuri nel tempo rispetto ai checkpoint standard che catturano la memoria volatile.

Abilitare la cache CSV con un dimensionamento conservativo

Perché: Le dashboard di telemetria, prevalentemente in lettura, beneficiano dei blocchi padre memorizzati nella cache, migliorando la reattività senza consumare RAM eccessiva sui nodi edge con risorse limitate.

Questo progetto utilizza S2D per l’alta disponibilità, VBS/vTPM/Secure Boot per un trust rafforzato, VLAN e Port ACL per un isolamento deterministico, e Hyper-V Replica per la resilienza del sito, bilanciando sicurezza, prestazioni e operabilità in un ambiente edge con risorse limitate.

← Aggiornamento e Gestione delle Patch di Windows Server · Tutti i domini · Disaster Recovery e Continuità Operativa →

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