Virtualisierungsbasierte Sicherheit (VBS)

Virtualisierungsbasierte Sicherheit (VBS) verwendet Hardwarevirtualisierung und den Windows-Hypervisor, um eine isolierte virtuelle Umgebung zu erstellen, die zum Vertrauensstamm des Betriebssystems wird, das davon ausgeht, dass der Kernel kompromittiert werden kann. Windows verwendet diese isolierte Umgebung, um eine Reihe von Sicherheitslösungen zu hosten, ihnen einen erheblich erhöhten Schutz vor Sicherheitsrisiken im Betriebssystem zu bieten und die Verwendung böswilliger Exploits zu verhindern, die versuchen, Den Schutz zu besiegen. VBS erzwingt Einschränkungen zum Schutz wichtiger System- und Betriebssystemressourcen oder zum Schutz von Sicherheitsressourcen wie authentifizierten Benutzeranmeldeinformationen.

Eine solche Beispiel-Sicherheitslösung ist die Speicherintegrität, die Windows schützt und härtet, indem die Kernelmoduscodeintegrität in der isolierten virtuellen Umgebung von VBS ausgeführt wird. Die Codeintegrität im Kernelmodus ist der Windows-Prozess, der alle Kernelmodustreiber und Binärdateien überprüft, bevor sie gestartet werden, und verhindert, dass nicht signierte oder nicht vertrauenswürdige Treiber oder Systemdateien in den Systemspeicher geladen werden. Die Speicherintegrität schränkt auch Kernelspeicherzuordnungen ein, die verwendet werden könnten, um das System zu kompromittieren. Dadurch wird sichergestellt, dass Kernelspeicherseiten nur nach bestandenen Codeintegritätsprüfungen in der sicheren Laufzeitumgebung ausführbar sind und ausführbare Seiten selbst nie beschreibbar sind. Auf diese Weise können ausführbare Codepages nicht geändert werden, und der geänderte Arbeitsspeicher kann nicht ausführbar gemacht werden, selbst wenn Sicherheitsrisiken wie ein Pufferüberlauf vorhanden sind, die es Schadsoftware ermöglichen, den Arbeitsspeicher zu ändern.

Hinweis

Die Speicherintegrität wird manchmal als hypervisorgeschützte Codeintegrität (Hypervisor-Protected Code Integrity, HVCI) oder durch Hypervisor erzwungene Codeintegrität bezeichnet und wurde ursprünglich als Teil von Device Guard veröffentlicht. Device Guard wird nicht mehr verwendet, außer zum Suchen nach Speicherintegritäts- und VBS-Einstellungen in Gruppenrichtlinie oder der Windows-Registrierung.

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

Bitte beachten Sie, dass TPM keine zwingende Voraussetzung 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 außerdem, dass die Virtualisierungsunterstützung des Prozessors Second Level Address Translation (SLAT) umfasst, entweder Intel VT-X2 mit Extended Page Tables (EPT) oder AMD-v mit Rapid Virtualization Indexing (RVI).
IOMMUs oder SMMUs (Intel VT-D, AMD-Vi, Arm64 SMMUs) Alle DMA-fähigen E/A-Geräte müssen sich hinter einer IOMMU oder SMMU befinden. Eine IOMMU kann verwendet werden, um die Systemresilienz gegen Speicherangriffe zu verbessern.
Trusted Platform Module (TPM) 2.0 TPMs, entweder diskret oder in der Firmware, sind ausreichend. Weitere Informationen finden Sie unter Trusted Platform Module (TPM) 2.0.
Firmware-Unterstützung für SMM-Schutz Die Systemfirmware muss den Empfehlungen zum Härten von SMM-Code entsprechen, die in der Windows SMM Security Mitigations Table (WMST)-Spezifikation beschrieben sind. Die WSMT-Spezifikation enthält Details zu einer ACPI-Tabelle, die für die Verwendung mit Windows-Betriebssystemen erstellt wurde, die VBS-Features unterstützen. Die Firmware muss die in der WSMT-Spezifikation beschriebenen Schutzmaßnahmen implementieren und die entsprechenden Schutz-Flags wie in der Spezifikation beschrieben setzen, um die Einhaltung dieser Anforderungen an das Betriebssystem zu melden.
Unified Extensible Firmware Interface (UEFI) Speicherberichterstattung Die UEFI-Firmware muss das folgende Speicherzuordnungs-Berichtsformat und die folgenden Richtlinien zur Speicherzuweisung einhalten, damit die Firmware die Kompatibilität mit VBS gewährleistet.

  • UEFI v2.6 Speicherattribute Tabelle (MAT) - Um die Kompatibilität mit VBS zu gewährleisten, muss die Firmware die EFI-Laufzeitspeicherbereiche für Code und Daten sauber trennen und dies an das Betriebssystem melden. Durch die ordnungsgemäße Trennung und Meldung von EFI-Laufzeitspeicherbereichen kann VBS den erforderlichen Seitenschutz auf Codepages der EFI-Laufzeitdienste innerhalb der VBS-Sicherheitsregion anwenden. Die Übermittlung dieser Informationen an das Betriebssystem erfolgt mithilfe von EFI_MEMORY_ATTRIBUTES_TABLE. Um die UEFI MAT zu implementieren, befolgen Sie diese Richtlinien:
    1. Die gesamte EFI-Laufzeit muss durch diese Tabelle beschrieben werden.
    2. Alle entsprechenden Attribute für EfiRuntimeServicesData- und EfiRuntimeServicesCode-Seiten müssen markiert sein.
    3. Diese Bereiche müssen an Seitengrenzen (4 KB) ausgerichtet sein und dürfen sich nicht überschneiden.
  • EFI-Seitenschutz – Alle Einträge müssen die Attribute EFI_MEMORY_RO, EFI_MEMORY_XP oder beide enthalten. Der gesamte als ausführbar markierte UEFI-Speicher muss schreibgeschützt sein. Als beschreibbar gekennzeichneter Speicher darf nicht ausführbar sein. Einträge dürfen nicht mit keinem der gesetzten Attribute belassen werden, was darauf hinweist, dass Speicher sowohl ausführbar als auch beschreibbar ist.
  • Secure Memory Overwrite Request (MOR) Revision 2 Secure MOR v2 wurde erweitert, um die MOR-Sperreinstellung mithilfe einer sicheren UEFI-Variablen zu schützen. Dies schützt vor erweiterten Speicherangriffen. Einzelheiten finden Sie unterSecure MOR-Implementierung.
    Speicherintegritätskompatible Treiber Stellen Sie sicher, dass alle Systemtreiber getestet und überprüft wurden, ob sie mit der Speicherintegrität kompatibel sind. Windows Driver Kit und Driver Verifier enthalten Tests auf Treiberkompatibilität mit Speicherintegrität. Es gibt drei Schritte zum Überprüfen der Treiberkompatibilität:
    1. Verwenden Sie die Treiberüberprüfung mit aktivierter Codeintegritätskompatibilitätsüberprüfung .
    2. Führen Sie den HyperVisor-Codeintegritätsbereitschaftstest im Windows HLK aus.
    3. Testen Sie den Treiber auf einem System mit aktivierter VBS- und Speicherintegrität. Dieser Schritt ist unerlässlich, um das Verhalten des Treibers mit der Speicherintegrität zu überprüfen, da statische Codeanalysetools einfach nicht in der Lage sind, alle zur Laufzeit möglichen Verletzungen der Speicherintegrität zu erkennen.

    VBS funktioniert auf VMs mit Unterstützung für verschachtelte Virtualisierung. Dies umfasst alle Gen2-VMs und Gen1-VMs, die verschachtelte Virtualisierung unterstützen. Eine Liste der unterstützten VM-Serien ist in der folgenden Tabelle aufgeführt.

    Name der VM-Serie Geschachtelte Virtualisierung VM Gen
    Av2 Yes 1 (bestimmte interne Größen unterstützen Gen 2)
    B No 1 und 2
    Dsv2/Dv2/Dv3/Ev3 Ja 1
    Dsv3/Ddsv3 Ja 1 und 2
    Dsv4/Ddsv4 Yes 1 und 2
    Esv3/Edsv3 Yes 1 und 2
    Esv4/Edsv4 Yes 1 und 2
    Ev4/Edv4 Ja Nur Ev4 - 1
    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 Hypervisor-Spezifikationen.