Freigeben über

Virtualisierungsbasierte Sicherheit (VBS)

Virtualisierungsbasierte Sicherheit (VBS) verwendet Hardwarevirtualisierung und den Windows-Hypervisor, um eine isolierte virtuelle Umgebung zu erstellen, die zum Vertrauensanker 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, die einen deutlich besseren Schutz vor Sicherheitsrisiken im Betriebssystem bieten und die Verwendung bösartiger Exploits verhindern, die versuchen, diesen Schutz zu umgehen. VBS erzwingt Einschränkungen, um wichtige System- und Betriebssystemressourcen zu schützen oder Sicherheitsressourcen wie authentifizierte Benutzeranmeldeinformationen zu schützen.

Eine solche Sicherheitslösung ist die Speicherintegrität, die Windows schützt und abschirmt, indem es die Integrität des Kernel-Modus-Codes innerhalb der isolierten virtuellen Umgebung von VBS ausführt. 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 Kernel-Speicherzuweisungen ein, die zur Kompromittierung des Systems verwendet werden könnten. So wird sichergestellt, dass Kernel-Speicherseiten nur dann ausführbar gemacht werden, wenn sie Code-Integritätsprüfungen innerhalb der sicheren Laufzeitumgebung bestanden haben, und dass die ausführbaren Seiten selbst niemals beschreibbar sind. Selbst wenn es Schwachstellen wie einen Pufferüberlauf gibt, die es Malware ermöglichen, den Speicher zu ändern, können ausführbare Codepages nicht geändert und der geänderte Speicher nicht ausführbar gemacht werden.

Hinweis

Speicherintegrität wird manchmal als hypervisorgeschützte Codeintegrität (HVCI) oder 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 Lokalisieren der Speicherintegrität und VBS-Einstellungen in der Gruppenrichtlinie oder in der Windows-Registrierung.

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

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 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 auf Kompatibilität mit der Speicherintegrität überprüft wurden. Das Windows-Treiberkit und Treiberüberprüfung enthalten Tests für die Treiberkompatibilität mit der Speicherintegrität. Es gibt drei Schritte zum Überprüfen der Treiberkompatibilität:
    1. Verwenden Sie die Treiberüberprüfung mit aktivierten Prüfungen der Codeintegritätskompatibilitä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 aktivierter Speicherintegrität. Dieser Schritt ist zwingend erforderlich, um das Verhalten des Treibers in Bezug auf die Speicherintegrität zu überprüfen, da statische Codeanalysetools einfach nicht in der Lage sind, alle möglichen Verletzungen der Speicherintegrität zur Laufzeit zu erkennen.
    Sicherer Start Der sichere Start muss auf Geräten aktiviert sein, die VBS nutzen. Weitere Informationen finden Sie unter Sicherer Start.

    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.