Virtualisierungsbasierte Sicherheit (VBS)

Virtualisierungsbasierte Sicherheit oder VBS verwendet Hardwarevirtualisierungsfeatures, um einen sicheren Speicherbereich aus dem normalen Betriebssystem zu erstellen und zu isolieren. Windows können diesen "virtuellen sicheren Modus" verwenden, um eine Reihe von Sicherheitslösungen zu hosten, die ihnen einen erheblich erhöhten Schutz vor Sicherheitsrisiken im Betriebssystem bieten und verhindern, dass böswillige Exploits verwendet werden, die versuchen, Schutz zu verhindern.

Eine solche Sicherheitslösung ist Hypervisor-Enforced Codeintegrität (HVCI), häufig als Speicherintegrität bezeichnet, die VBS verwendet, um die Codeintegritätsrichtlinienerzwingung erheblich zu stärken. Die Kernelmoduscodeintegrität überprüft alle Kernelmodustreiber und Binärdateien, bevor sie gestartet werden, und verhindert, dass nicht signierte Treiber oder Systemdateien in den Systemspeicher geladen werden.

VBS verwendet den Windows-Hypervisor, um diesen virtuellen sicheren Modus zu erstellen und Einschränkungen zu erzwingen, die wichtige System- und Betriebssystemressourcen schützen oder Sicherheitsressourcen wie authentifizierte Benutzeranmeldeinformationen schützen. Mit den erhöhten Schutzfunktionen von VBS, auch wenn Schadsoftware Zugriff auf den Betriebssystemkern erhält, kann die mögliche Exploits stark eingeschränkt und enthalten sein, da der Hypervisor verhindern kann, dass die Schadsoftware Code ausführt oder auf Plattformschlüssel zugreifen kann.

Ebenso überprüft der Benutzermodus konfigurierbare Codeintegritätsrichtlinie Anwendungen vor dem Laden und startet nur ausführbare Dateien, die von bekannten, genehmigten Signern signiert sind. HVCI nutzt VBS, um den Codeintegritätsdienst in einer sicheren Umgebung auszuführen, wodurch stärkere Schutz vor Kernelviren und Schadsoftware bereitgestellt wird. Der Hypervisor, die Systemsoftware mit der höchsten Berechtigungsstufe, legt Seitenberechtigungen für den gesamten Arbeitsspeicher des Systems fest und setzt diese durch. Seiten werden nur ausführbare Dateien erstellt, nachdem codeintegritätsprüfungen innerhalb des sicheren Bereichs übergeben wurden, und ausführbare Seiten sind nicht schreibbar. Auf diese Weise können Auch wenn Sicherheitsrisiken wie ein Pufferüberlauf vorhanden sind, mit dem Schadsoftware versucht werden kann, Speicher zu ändern, können Codeseiten nicht geändert werden, und der geänderte Speicher kann nicht ausführbare Datei ausgeführt werden.

VBS erfordert, dass die folgenden Komponenten vorhanden und ordnungsgemäß konfiguriert werden.

Bitte beachten Sie, dass TPM keine Anforderung ist, aber wir empfehlen dringend, TPM zu implementieren.

Hardwareanforderung Details
64-Bit-CPU Virtualisierungsbasierte Sicherheit (VBS) erfordert den Windows Hypervisor, der nur auf 64-Bit-IA-Prozessoren mit Virtualisierungserweiterungen unterstützt wird, einschließlich Intel VT-X und AMD-v.
Adressübersetzung der zweiten Ebene (Second Level Address Translation, SLAT) VBS erfordert auch, dass die Virtualisierungsunterstützung des Prozessors die Second Level Address Translation (SLAT), entweder Intel VT-X2 mit erweiterten Seitentabellen (EPT) oder AMD-v mit Rapid Virtualization Indexing (RVI) enthält.
IOMMUs oder SMMUs (Intel VT-D, AMD-Vi, Arm64 SMMUs) Alle I/O-Geräte, die DMA können, müssen hinter einem IOMMU oder SMMU stehen. Ein IOMMU kann verwendet werden, um die Systemsicherheit gegen Speicherangriffe zu verbessern.
Trusted Platform Module (TPM) 2.0 TPMs, entweder diskret oder firmware, sind ausreichend. Weitere Informationen finden Sie unter Trusted Platform Module (TPM) 2.0.
Firmwareunterstützung für den SMM-Schutz Die System-Firmware muss den Empfehlungen für die Härtung des SMM-Codes entsprechen, der in der Windows SMM Security Mitigations Table (WMST)-Spezifikation beschrieben ist. Die WSMT-Spezifikation enthält Details einer ACPI-Tabelle, die für die Verwendung mit Windows Betriebssystemen erstellt wurde, die Windows virtualisierungsbasierten Sicherheitsfeatures (VBS) unterstützen. Firmware muss die in der WSMT-Spezifikation beschriebenen Schutzmechanismen implementieren und die entsprechenden Schutzflags festlegen, wie in der Spezifikation beschrieben, um die Einhaltung dieser Anforderungen an das Betriebssystem zu melden.
Unified Extensible Firmware Interface (UEFI) Speicherberichterstattung UEFI-Firmware muss das folgende Speicherzuordnungsberichtsformat und die Speicherzuweisungsrichtlinien einhalten, um die Kompatibilität mit VBS sicherzustellen.

  • UEFI v2.6 Speicherattribute Tabelle (MAT) - Um die Kompatibilität mit VBS sicherzustellen, muss firmware EFI-Laufzeitspeicherbereiche für Code und Daten sauber trennen und dies dem Betriebssystem melden. Mit der richtigen Trennung und Berichterstellung von EFI-Laufzeitspeicherbereichen können VBS die erforderlichen Seitenschutzfunktionen auf EFI-Laufzeitdienste-Codeseiten innerhalb der sicheren VBS-Region anwenden. Die Übermittlung dieser Informationen an das Betriebssystem erfolgt mithilfe der EFI_MEMORY_ATTRIBUTES_TABLE. Gehen Sie wie folgt vor, um die UEFI-MAT zu implementieren:
    1. Die gesamte EFI-Laufzeit muss von dieser Tabelle beschrieben werden.
    2. Alle entsprechenden Attribute für EfiRuntimeServicesData und EfiRuntimeServicesCode-Seiten müssen markiert werden.
    3. Diese Bereiche müssen auf Seitengrenzen (4 KB) ausgerichtet werden und können nicht überlappen.
  • EFI-Seitenschutz – Alle Einträge müssen Attribute EFI_MEMORY_RO, EFI_MEMORY_XP oder beides enthalten. Alle UEFI-Speicher, die als ausführbare Datei gekennzeichnet sind, müssen schreibgeschützt sein. Als beschreibbar gekennzeichneter Speicher darf nicht ausführbar sein. Einträge sind möglicherweise nicht mit keiner der Attribute enthalten, die den Arbeitsspeicher angeben, der sowohl ausführbare als auch schreibbar ist.
  • Secure Memory Overwrite Request (MOR) Revision 2 Sichere MOR v2 wird erweitert, um die MOR-Sperreinstellung mithilfe einer sicheren UEFI-Variable zu schützen. Dadurch können Sie vor erweiterten Speicherangriffen schützen. Ausführliche Informationen finden Sie unter Secure MOR-Implementierung.
    Hypervisorcodeintegrität (HVCI)-kompatible Treiber Stellen Sie sicher, dass alle Systemtreiber getestet und überprüft wurden, um mit HVCI kompatibel zu sein. Das Windows Treiberkit und die Treiberüberprüfung enthalten Tests für die Treiber-HVCI-Kompatibilität. Es gibt vier Schritte zum Überprüfen der Treiberkompatibilität:
    1. Verwenden Sie die Treiberüberprüfung mit aktivierten Kompatibilitätsprüfungen für die Codeintegrität .
    2. Führen Sie den Hypervisor-Codeintegritätsbereitschaftstest im Windows HLK aus.
    3. Testen Sie den Treiber auf einem System mit aktiviertem VBS und HVCI. Dieser Schritt ist unerlässlich, das Verhalten des Treibers mit HVCI zu überprüfen, da statische Codeanalysetools einfach nicht in der Lage sind, alle HVCI-Verstöße zu erkennen, die zur Laufzeit möglich sind.
    4. Verwenden Sie das DGReadiness-Tool.

    VBS funktioniert auf VMs, die geschachtelte Virtualisierungsunterstützung haben. Dies umfasst alle Gen2-VMs und Gen1-VMs, die geschachtelte Virtualisierung unterstützen. Eine Liste der unterstützten VM-Serien wird in der nachstehenden Tabelle beschrieben.

    VM-Serienname Geschachtelte Virtualisierung VM-Gen
    Av2 Yes 1 (bestimmte interne Größen unterstützen gen 2)
    B Nein 1 und 2
    Dsv2/Dv2/Dv3/Ev3 Ja 1
    Dsv3/Ddsv3 Ja 1 und 2
    Dsv4/Ddsv4 Yes 1 und 2
    Esv3/Edsv3 Ja 1 und 2
    Esv4/Edsv4 Yes 1 und 2
    Ev4/Edv4 Yes Ev4 - 1 nur
    Edv4 -1&2
    Dv4/Ddv4 Yes 1 und 2
    Dv5/Ddv5/Dsv5/Ddsv5 Yes 1 und 2
    Ev5/Edv5/Esv5/Edsv5 Ja 1 und 2
    Dasv5/Dadsv5/Easv5/ Eadsv5 Yes 1 und 2
    Ebsv5/Edbsv5 Yes 1 und 2
    Fsv2 Yes 1 und 2
    Fx Ja 2
    Lsv2 Yes 1 und 2

    Weitere Informationen zu Hyper-V finden Sie unter Hyper-V auf Windows Server 2016 oder Einführung in Hyper-V auf Windows 10. Weitere Informationen zum Hypervisor finden Sie unter Hypervisorspezifikationen.