Sicurezza basata su virtualizzazione (VBS)
La sicurezza basata su virtualizzazione o la sicurezza basata su virtualizzazione usa la virtualizzazione hardware e l'hypervisor 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. La sicurezza basata su vbs applica restrizioni per proteggere le risorse vitali del sistema operativo o per proteggere gli asset di sicurezza, ad esempio 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 kernel vengano eseguite solo dopo aver superato i controlli di integrità del codice all'interno dell'ambiente di runtime protetto e le pagine eseguibili stesse non siano mai scrivibili. In questo modo, anche se ci sono 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 dall'hypervisor (HVCI) o hypervisor applicata all'integrità del codice ed è stata originariamente rilasciata come parte di Device Guard. Device Guard non viene più usato tranne per individuare l'integrità della memoria e le impostazioni VBS in Criteri di gruppo o nel Registro di sistema di Windows.
La sicurezza basata su 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 nei 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 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, sono 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 WMST (Windows SMM Security Mitigations Table). 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 della memoria UEFI (Unified Extensible Firmware Interface) | Il firmware UEFI deve rispettare il seguente formato di segnalazione della mappa di memoria e le linee guida per l'allocazione della memoria per garantire la compatibilità con la sicurezza basata su vbs.
|
| Secure Memory Overwrite Request (MOR) revisione 2 | Secure MOR v2 è stato migliorato per proteggere l'impostazione del 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 che siano 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 nelle 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. Un elenco di serie di macchine virtuali supportate è descritto in dettaglio nella tabella seguente.
| Nome della serie di macchine virtuali | Virtualizzazione annidata | Generazione di macchine virtuali |
|---|---|---|
| Av2 | Sì | 1 (alcune dimensioni interne supportano gen 2) |
| G | 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.