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.
|
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:
|
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 |
Zugehörige Themen
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.