Condividi tramite

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.

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 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.

  • UEFI v2.6 Memory Attributes Table (MAT) - Per garantire la compatibilità con la sicurezza basata su virgola virtuale, il firmware deve separare correttamente gli intervalli di memoria di runtime EFI per il codice e i dati e segnalarli al sistema operativo. La separazione e la creazione di report appropriati degli intervalli di memoria di runtime EFI consentono a VBS di applicare le protezioni di pagina necessarie alle tabelle codici dei servizi di runtime EFI all'interno dell'area protetta VBS. La comunicazione di queste informazioni al sistema operativo viene eseguita usando il EFI_MEMORY_ATTRIBUTES_TABLE. Per implementare il MAT UEFI, seguire queste linee guida:
    1. L'intero runtime EFI deve essere descritto da questa tabella.
    2. Tutti gli attributi appropriati per le pagine EfiRuntimeServicesData e EfiRuntimeServicesCode devono essere contrassegnati.
    3. Questi intervalli devono essere allineati sui limiti di pagina (4 KB) e non possono sovrapporsi.
  • Protezioni pagina EFI : tutte le voci devono includere attributi EFI_MEMORY_RO, EFI_MEMORY_XP o entrambi. Tutta la memoria UEFI contrassegnata come eseguibile deve essere di sola lettura. La memoria contrassegnata come scrivibile non deve essere eseguibile. Le voci potrebbero non essere lasciate con nessuno degli attributi impostati, a indicare la memoria eseguibile e scrivibile.
    • 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:
    1. Usare Driver Verifier con i controlli di compatibilità dell'integrità del codice abilitati.
    2. Eseguire il test di conformità dell'integrità del codice Hypervisor in Windows HLK.
    3. Testare il driver in un sistema con VBS e l'integrità della memoria abilitata. Questo passaggio è fondamentale per convalidare il comportamento del driver con l'integrità della memoria, poiché gli strumenti di analisi del codice statico semplicemente non sono in grado di rilevare tutte le violazioni dell'integrità della memoria possibili in fase di esecuzione.
    Avvio protetto L'avvio protetto deve essere abilitato nei dispositivi che sfruttano la sicurezza basata su vbs. Per altre informazioni, vedere Avvio protetto

    La sicurezza basata su virtualizzazione (VBS) funziona nelle macchine virtuali con supporto per la virtualizzazione annidata o VSM ospite abilitata. Quest'ultimo è abilitato per impostazione predefinita per le macchine virtuali di seconda generazione in Hyper-V. Sono incluse anche tutte le macchine virtuali di seconda generazione in Microsoft Azure e le macchine virtuali di prima generazione che hanno la virtualizzazione annidata abilitata. Un elenco di serie di macchine virtuali di Azure supportate è descritto in dettaglio nella tabella seguente.

    Nome della serie di macchine virtuali Virtualizzazione annidata Generazione di VM
    Av2 Sì 1 (alcune dimensioni interne supportano la generazione 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

    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.