sicurezza basata sulla virtualizzazione (VBS)
La sicurezza basata su virtualizzazione o la sicurezza basata su virtualizzazione usa la virtualizzazione hardware e l'hypervisor Di Windows per creare un ambiente virtuale isolato che diventa la radice di attendibilità del sistema operativo che presuppone che il kernel possa essere compromesso. Windows usa questo ambiente isolato per ospitare una serie di soluzioni di sicurezza, fornendo loro una maggiore protezione dalle vulnerabilità nel sistema operativo e impedendo l'uso di exploit dannosi che tentano di sconfiggere le protezioni. VbS applica restrizioni per proteggere le risorse vitali del sistema operativo o per proteggere asset di sicurezza come le credenziali utente autenticate.
Una di queste soluzioni di sicurezza di esempio è l'integrità della memoria, che protegge e protegge Windows eseguendo l'integrità del codice in modalità kernel all'interno dell'ambiente virtuale isolato della sicurezza basata su virtualizzazione. L'integrità del codice in modalità kernel è il processo di Windows che controlla tutti i driver e i file binari in modalità kernel prima dell'avvio e impedisce il caricamento di driver o file di sistema non firmati o non attendibili nella memoria di sistema. L'integrità della memoria limita anche le allocazioni di memoria del kernel che potrebbero essere usate per compromettere il sistema, assicurandosi che le pagine di memoria del kernel vengano rese eseguibili solo dopo aver superato i controlli di integrità del codice all'interno dell'ambiente di runtime sicuro e le pagine eseguibili stesse non siano mai scrivibili. In questo modo, anche se sono presenti vulnerabilità come un overflow del buffer che consentono al malware di tentare di modificare la memoria, le tabelle codici eseguibili non possono essere modificate e la memoria modificata non può essere resa eseguibile.
Nota
L'integrità della memoria viene talvolta definita integrità del codice protetta da hypervisor (HVCI) o hypervisor applicata all'integrità del codice ed è stata originariamente rilasciata come parte di Device Guard. Device Guard non viene più usato se non per individuare l'integrità della memoria e le impostazioni vbs in Criteri di gruppo o nel Registro di sistema di Windows.
VbS richiede che i componenti seguenti siano presenti e configurati correttamente.
Si noti che TPM non è un requisito obbligatorio, ma è consigliabile implementare TPM.
| Requisito hardware | Dettagli |
|---|---|
| CPU a 64 bit | La sicurezza basata su virtualizzazione richiede l'hypervisor Windows, supportato solo su processori IA a 64 bit con estensioni di virtualizzazione, tra cui Intel VT-X e AMD-v. |
| Conversione indirizzi di secondo livello (SLAT) | La sicurezza basata su virtualizzazione richiede anche che il supporto della virtualizzazione del processore includa SLAT (Second Level Address Translation), Intel VT-X2 con tabelle di pagine estese (EPT) o AMD-v con Rapid Virtualization Indexing (RVI). |
| IOMMU o SMMU (Intel VT-D, AMD-Vi, Arm64 SMMU) | Tutti i dispositivi di I/O che supportano DMA devono essere protetti da un IOMMU o SMMU. Un IOMMU può essere usato per migliorare la resilienza del sistema contro gli attacchi alla memoria. |
| Trusted Platform Module (TPM) 2.0 | I TPM, discreti o firmware, saranno sufficienti. Per altre informazioni, vedere Trusted Platform Module (TPM) 2.0. |
| Supporto del firmware per la protezione SMM | Il firmware di sistema deve rispettare le raccomandazioni per la protezione avanzata del codice SMM descritto nella specifica Windows SMM Security Mitigations Table (WMST). La specifica WSMT contiene i dettagli di una tabella ACPI creata per l'uso con sistemi operativi Windows che supportano le funzionalità VBS. Il firmware deve implementare le protezioni descritte nella specifica WSMT e impostare i flag di protezione corrispondenti come descritto nella specifica per segnalare la conformità a questi requisiti al sistema operativo. |
| Segnalazione di memoria UEFI (Unified Extensible Firmware Interface) | Il firmware UEFI deve rispettare il formato di segnalazione della mappa della memoria seguente e le linee guida per l'allocazione della memoria per garantire la compatibilità con vbs.
|
| Secure Memory Overwrite Request (MOR) revisione 2 | Mor sicuro v2 è stato migliorato per proteggere l'impostazione di blocco MOR usando una variabile protetta UEFI. In questo modo è possibile proteggersi dagli attacchi avanzati alla memoria. Per informazioni dettagliate, vedere Implementazione sicura di MOR. |
| Driver compatibili con l'integrità della memoria | Verificare che tutti i driver di sistema siano stati testati e verificati per essere compatibili con l'integrità della memoria. Windows Driver Kit e Driver Verifier contengono test per la compatibilità dei driver con l'integrità della memoria. Esistono tre passaggi per verificare la compatibilità dei driver:
|
La sicurezza basata su virtualizzazione funziona su macchine virtuali con supporto per la virtualizzazione annidata. Sono incluse tutte le macchine virtuali gen2 e le macchine virtuali gen1 che supportano la virtualizzazione annidata. Nella tabella seguente è riportato un elenco delle serie di macchine virtuali supportate.
| Nome serie di macchine virtuali | Virtualizzazione annidata | Generazione di macchine virtuali |
|---|---|---|
| Av2 | Sì | 1 (alcune dimensioni interne supportano gen 2) |
| B | No | 1 e 2 |
| Dsv2/Dv2/Dv3/Ev3 | Sì | 1 |
| Dsv3/Ddsv3 | Sì | 1 e 2 |
| Dsv4/Ddsv4 | Sì | 1 e 2 |
| Esv3/Edsv3 | Sì | 1 e 2 |
| Esv4/Edsv4 | Sì | 1 e 2 |
| Ev4/Edv4 | Sì | Ev4 - solo 1 Edv4 -1&2 |
| Dv4/Ddv4 | Sì | 1 e 2 |
| Dv5/Ddv5/Dsv5/Ddsv5 | Sì | 1 e 2 |
| Ev5/Edv5/Esv5/Edsv5 | Sì | 1 e 2 |
| Dasv5/Dadsv5/Easv5/ Eadsv5 | Sì | 1 e 2 |
| Ebsv5/Edbsv5 | Sì | 1 e 2 |
| Fsv2 | Sì | 1 e 2 |
| Fx | Sì | 2 |
| Lsv2 | Sì | 1 e 2 |
Argomenti correlati
Per altre informazioni su Hyper-V, vedere Hyper-V in Windows Server 2016 o Introduzione a Hyper-V in Windows 10. Per altre informazioni sull'hypervisor, vedere Specifiche di Hypervisor.