Windows Defender Credential Guard-Anforderungen
Damit Windows Defender Credential Guard Schutz bietet, müssen die zu schützenden Computer bestimmte grundlegende Hardware-, Firmware- und Softwareanforderungen erfüllen, die als Hardware- und Softwareanforderungen bezeichnet werden. Darüber hinaus blockiert Windows Defender Credential Guard spezifische Authentifizierungsfunktionen, sodass Anwendungen, die blockierte Funktionen erfordern, unterbrochen werden. Diese Anforderungen werden als Anwendungsanforderungen bezeichnet. Über diese Anforderungen hinaus können Computer zusätzliche Hardware- und Firmwarequalifikationen erfüllen und zusätzlichen Schutz erhalten. Diese Computer sind noch stärker vor bestimmten Bedrohungen geschützt. Ausführliche Informationen zum grundlegenden Schutz und zum Schutz für erhöhte Sicherheit, der mit den in 2015, 2016 und 2017 verfügbaren Hardware- und Firmwareoptionen verknüpft ist, finden Sie in den Tabellen unter Sicherheitsüberlegungen.
Hardware- und Softwareanforderungen
Zum Bereitstellen von grundlegendem Schutz gegen Versuche auf Betriebssystemebene, Domänenanmeldeinformationen für die Anmeldeinformationsverwaltung sowie von NTLM und Kerberos abgeleitete Anmeldeinformationen zu lesen, verwendet Windows Defender Credential Guard Folgendes:
- Unterstützung für virtualisierungsbasierte Sicherheit (erforderlich)
- Sicherer Start (erforderlich)
- Die Versionen 1.2 und 2.0 des Trusted Platform Module (TPM, bevorzugt : Bindung an Hardware) werden unterstützt, entweder diskret oder firmware
- UEFI-Sperre (bevorzugt – verhindert Deaktivierungen durch Angreifer mit einer einfachen Änderung des Registrierungsschlüssels)
Die virtualisierungsbasierte Sicherheit erfordert Folgendes:
- 64-Bit-CPU
- CPU-Virtualisierungserweiterungen sowie erweiterte Seitentabellen
- Windows-Hypervisor (erfordert keine Installation des Hyper-V-Windows-Features)
Windows Defender Credential Guard-Bereitstellung auf virtuellen Computern
Credential Guard kann geheime Schlüssel auf einem virtuellen Hyper-V-Computer genau wie auf einem physischen Computer schützen. Wenn Sie Credential Guard auf einem virtuellen Computer bereitstellen, werden geheime Schlüssel vor Angriffen innerhalb des virtuellen Computers geschützt. Credential Guard bietet jedoch keinen zusätzlichen Schutz vor Systemangriffen von einem Host mit privilegiertem Zugriff.
Anforderungen für die Ausführung von Windows Defender Credential Guard auf virtuellen Hyper-V-Computern
- Der Hyper-V-Host muss über eine IOMMU verfügen und mindestens Windows Server 2016 oder Windows 10, Version 1607, ausführen.
- Beim virtuellen Hyper-V-Computer muss es sich um einen Computer der Generation 2 mit aktiviertem virtuellen TPM handeln, auf dem mindestens Windows Server 2016 oder Windows 10 ausgeführt wird.
- TPM ist keine Voraussetzung, es wird jedoch empfohlen, TPM zu implementieren.
Informationen zu anderen Hostplattformen finden Sie unter Aktivieren Windows Server 2016- und Hyper-V-Virtualisierungsbasierter Sicherheitsfeatures auf anderen Plattformen.
Informationen zu Windows Defender Hardware- und Softwareanforderungen für Remote Credential Guard finden Sie unter Windows Defender Remote Credential Guard-Anforderungen.
Anforderungen an Anwendungen
Wenn Windows Defender Credential Guard aktiviert ist, werden bestimmte Authentifizierungsfunktionen blockiert, sodass Anwendungen, die blockierte Funktionen erfordern, unterbrochen werden. Anwendungen sollten vor der Bereitstellung getestet werden, um die Kompatibilität mit der eingeschränkten Funktionalität sicherzustellen.
Warnung
Das Aktivieren von Windows Defender Credential Guard auf Domänencontrollern wird derzeit nicht empfohlen. Windows Defender Credential Guard bietet keine zusätzliche Sicherheit für Domänencontroller und kann Probleme mit der Anwendungskompatibilität auf Domänencontrollern verursachen.
Hinweis
Windows Defender Credential Guard bietet keinen Schutz für die Active Directory-Datenbank oder die Sicherheitskontenverwaltung (Security Accounts Manager, SAM). Die bei Aktivierung von Windows Defender Credential Guard durch Kerberos und NTLM geschützten Anmeldeinformationen sind auch in der Active Directory-Datenbank (auf Domänencontrollern) und in der SAM (für lokale Konten) enthalten.
Anwendungen werden unterbrochen, wenn sie Folgendes benötigen:
- Kerberos-DES-Verschlüsselungsunterstützung
- Uneingeschränkte Kerberos-Delegierung
- Extrahieren des Kerberos-TGT
- NTLMv1
Anwendungen fordern Anmeldeinformationen an und setzen diese Risiken aus, wenn sie Folgendes benötigen:
- Digestauthentifizierung
- Delegierung von Anmeldeinformationen
- MS-CHAPv2
Anwendungen können zu Leistungsproblemen führen, wenn sie versuchen, den isolierten Windows Defender Credential Guard-Prozess zu verknüpfen.
Dienste oder Protokolle, die auf Kerberos basieren, z. B. Dateifreigaben, Remotedesktop oder BranchCache, funktionieren weiterhin und sind von Windows Defender Credential Guard nicht betroffen.
Sicherheitsaspekte
Alle Computer, die die Hardware-, Firmware- und Softwareanforderungen für grundlegenden Schutz erfüllen, können Windows Defender Credential Guard nutzen. Computer mit zusätzlichen Qualifikationen können erweiterten Schutz bieten, um die Angriffsfläche weiter zu verringern. In den folgenden Tabellen werden grundlegende Schutzmaßnahmen und Schutzmaßnahmen für erhöhte Sicherheit für Hardware- und Firmwareoptionen beschrieben, die 2015, 2016 und 2017 verfügbar sind.
Hinweis
Ab Windows 10, Version 1607, muss Trusted Platform Module (TPM 2.0) auf neu ausgelieferten Computern standardmäßig aktiviert sein.
Wenn Sie OEM sind, finden Sie weitere Informationen unter PC-OEM-Anforderungen für Windows Defender Credential Guard.
Grundlegender Schutz
Grundlegender Schutz | Beschreibung | Sicherheitsvorteile |
---|---|---|
Hardware: 64-Bit-CPU | Damit Windows-Hypervisor VBS bereitstellen kann, ist ein 64-Bit-Computer erforderlich. | |
Hardware: CPU-Virtualisierungserweiterungen sowie erweiterte Seitentabellen | Anforderungen: – Diese Hardwarefeatures sind für VBS erforderlich: Eine der folgenden Virtualisierungserweiterungen: - VT-x (Intel) oder - AMD-V Und: - Erweiterte Seitentabellen, auch als Second Level Address Translation (SLAT) bezeichnet. | VBS isoliert den sicheren Kernel vom normalen Betriebssystem. Sicherheitsrisiken und Day 0s im normalen Betriebssystem können aufgrund dieser Isolation nicht ausgenutzt werden. |
Hardware: Trusted Platform Module (TPM) | Anforderung: - TPM 1.2 oder TPM 2.0, entweder diskret oder Firmware. TPM-Empfehlungen | Ein TPM bietet Schutz für VBS-Verschlüsselungsschlüssel, die in der Firmware gespeichert sind. TPM schützt vor Angriffen, die einen physisch anwesenden Benutzer mit BIOS-Zugriff betreffen. |
Firmware: UEFI-Firmwareversion 2.3.1.c oder höher mit „Sicherer Start“ gemäß UEFI | Anforderungen: - Sehen Sie sich die folgende Windows-Hardwarekompatibilitätsprogramm-Anforderung an: System.Fundamentals.Firmware.UEFISecureBoot | Der sichere UEFI-Start stellt sicher, dass das Gerät nur autorisierten Code startet, und kann verhindern, dass Bootkits und Root-Kits über Neustarts hinweg installiert und beibehalten werden. |
Firmware: Prozess für ein sicheres Firmwareupdate | Anforderungen: - UEFI-Firmware muss ein sicheres Firmwareupdate unterstützen, das unter der folgenden Windows-Hardwarekompatibilitätsprogramm-Anforderung gefunden wird: System.Fundamentals.Firmware.UEFISecureBoot. | UEFI-Firmware kann wie Software Sicherheitsrisiken aufweisen. Falls vorhanden, müssen sie mithilfe von Firmwareupdates gepatcht werden. Die Patches verhindern die Installation von Rootkits. |
Software: Qualifiziertes Windows-Betriebssystem | Anforderung: Mindestens Windows 10 Enterprise, Windows 10 Education oder Windows Server 2016. | Unterstützung von VBS und von Verwaltungsfeatures, welche die Konfiguration von Windows Defender Credential Guard vereinfachen. |
Wichtig
Die folgenden Tabellen enthalten zusätzliche Qualifikationen für erhöhte Sicherheit. Allerdings wird dringend empfohlen, die Anforderungen für erhöhte Sicherheit einzuhalten, um den Sicherheitsgrad, den Windows Defender Credential Guard gewährleisten kann, deutlich zu erhöhen.
Zusätzliche Sicherheitsqualifikationen 2015 (ab Windows 10, Version 1507, und Windows Server 2016, Technical Preview 4)
Schutzmaßnahmen für erhöhte Sicherheit | Beschreibung |
---|---|
Hardware: IOMMU (Input/Output Memory Management Unit, Speicherverwaltungseinheit für die Ein-/Ausgabe) | Anforderung: - VT-D oder AMD Vi IOMMU Sicherheitsvorteile: - Eine IOMMU kann die Systemresilienz gegenüber Speicherangriffen verbessern. Weitere Informationen finden Sie unter Advanced Configuration and Power Interface (ACPI)-Beschreibungstabellen. |
Firmware: Schützen der Startkonfiguration und -verwaltung | Anforderungen: – BIOS-Kennwort oder eine stärkere Authentifizierung müssen unterstützt werden. – In der BIOS-Konfiguration muss die BIOS-Authentifizierung festgelegt werden. – Es muss Unterstützung für die geschützte BIOS-Option vorhanden sein, um die Liste der zulässigen Startgeräte (z. B. "Nur von der internen Festplatte starten") und die Startgerätereihenfolge zu konfigurieren, wodurch die vom Betriebssystem vorgenommene BOOTORDER-Änderung überschrieben wird. - In der BIOS-Konfiguration müssen BIOS-Optionen im Zusammenhang mit Sicherheits- und Startoptionen (Liste der zulässigen Startgeräte, Startreihenfolge) gesichert werden, um zu verhindern, dass andere Betriebssysteme gestartet werden und Änderungen an den BIOS-Einstellungen verhindert werden. |
Firmware: Sichere Implementierung von MOR, Version 2 | Anforderung: - Secure MOR, Revision 2-Implementierung |
Zusätzliche Sicherheitsqualifikationen 2016 (ab Windows 10, Version 1607, und Windows Server 2016)
Wichtig
Die folgenden Tabellen enthalten zusätzliche Qualifikationen für erhöhte Sicherheit. Systeme, die diese zusätzlichen Qualifikationen erfüllen, bieten einen stärkeren Schutz.
Schutzmaßnahmen für erhöhte Sicherheit | Beschreibung | Sicherheitsvorteile |
---|---|---|
Firmware: Hardware-Vertrauensanker, sicherer Plattformstart | Anforderungen: – Startintegrität (Platform Secure Boot) muss unterstützt werden. Weitere Informationen finden Sie in den Windows-Hardwarekompatibilitätsprogrammanforderungen unter System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby – Die Hardwaresicherheitstestschnittstelle (HSTI) muss implementiert werden. Siehe Spezifikation zur Prüfbarkeit von Hardwaresicherheit. | Startintegrität (sicherer Plattformstart) nach dem Einschalten bietet Schutzmaßnahmen vor physisch anwesenden Angreifern und eine tiefengestaffelte Verteidigung gegen Schadsoftware. - HSTI bietet zusätzliche Sicherheit für ordnungsgemäß gesichertes Silizium und plattform. |
Firmware: Firmwareupdate über Windows Update | Anforderungen: – Firmware muss Feldupdates über Windows Update- und UEFI-Kapselungsupdates unterstützen. | Stellt sicher, dass Firmwareupdates schnell, sicher und zuverlässig sind. |
Firmware: Schützen der Startkonfiguration und -verwaltung | Anforderungen: – Erforderliche BIOS-Funktionen: Die Fähigkeit des OEM zum Hinzufügen eines ISV-, OEM- oder Enterprise-Zertifikats in der Datenbank für den sicheren Start zur Herstellungszeit. – Erforderliche Konfigurationen: Microsoft UEFI-Zertifizierungsstelle muss aus der Datenbank für den sicheren Start entfernt werden. UEFI-Module von Drittanbietern können unterstützt werden, allerdings sollten von ISVs bereitgestellte Zertifikate oder OEM-Zertifikate für die spezifische UEFI-Software genutzt werden. | – Unternehmen können die Ausführung proprietärer EFI-Treiber/-Anwendungen zulassen. – Das Entfernen Microsoft UEFI-Zertifizierungsstelle aus der Datenbank für den sicheren Start bietet Unternehmen vollständige Kontrolle über Software, die vor dem Starten des Betriebssystems ausgeführt wird. |
Zusätzliche Sicherheitsqualifikationen 2017 (ab Windows 10, Version 1703)
Die folgende Tabelle enthält die Qualifikationen für Windows 10, Version 1703, die zusätzlich zu allen vorherigen Qualifikationen gelten.
Schutzmaßnahmen für erhöhte Sicherheit | Beschreibung | Sicherheitsvorteile |
---|---|---|
Firmware: VBS-Aktivierung des No-Execute (NX)-Schutzes für UEFI-Laufzeitdienste | Anforderungen: – VBS aktiviert NX-Schutz für UEFI-Laufzeitdienstcode und Datenspeicherregionen. UEFI-Laufzeitdienstcode muss Maßnahmen für den schreibgeschützten Seitenschutz unterstützen, und UEFI-Laufzeitdienstdaten dürfen nicht ausführbar sein. Der UEFI-Laufzeitdienst muss die folgenden Anforderungen erfüllen: – Implementieren sie UEFI 2.6 EFI_MEMORY_ATTRIBUTES_TABLE. Alle UEFI-Laufzeitdienstspeicher (Code und Daten) müssen in dieser Tabelle beschrieben werden. – PE-Abschnitte müssen im Arbeitsspeicher seitenbündig ausgerichtet sein (für nicht flüchtigen Speicher nicht erforderlich). - Die Tabelle "Speicherattribute" muss Code und Daten ordnungsgemäß als RO/NX für die Konfiguration durch das Betriebssystem markieren: – Alle Einträge müssen Attribute EFI_MEMORY_RO, EFI_MEMORY_XP oder beides enthalten. – Keines der oben genannten Attribute darf keines der Einträge erhalten, was auf Arbeitsspeicher hinweist, der sowohl ausführbare als auch schreibbar ist. Der Arbeitsspeicher muss entweder lesbar und ausführbar oder schreibbar und nicht ausführbar sein. (WICHTIGE INFORMATIONEN FINDEN SIE NACH DIESER TABELLE) | Sicherheitsrisiken in der UEFI-Runtime werden ggf. durch Kompromittieren von VBS blockiert (z. B. in Funktionen wie UpdateCapsule und SetVariable): Reduziert die Angriffsfläche für VBS von der Systemfirmware. |
Firmware: Firmwareunterstützung für SMM-Schutz | Anforderungen: – Die WSMT-Spezifikation (Windows SMM Security Mitigations Table) enthält Details zu einer ACPI-Tabelle, die für die Verwendung mit Windows-Betriebssystemen erstellt wurde, die VBS-Features (Virtualisierungsbasierte Sicherheit) von Windows unterstützen. | - Schützt vor potenziellen Sicherheitsrisiken in UEFI-Laufzeitdiensten, falls vorhanden, wird vor einer Kompromittierung von VBS blockiert (z. B. in Funktionen wie UpdateCapsule und SetVariable): Reduziert die Angriffsfläche für VBS von der Systemfirmware aus. – Blockiert zusätzliche Sicherheitsangriffe auf SMM. |
Wichtig
Zur VBS-Aktivierung des NX-Schutzes für UEFI-Laufzeitdienste:
Dies gilt nur für den Arbeitsspeicher des UEFI-Laufzeitdiensts und nicht für den Arbeitsspeicher des UEFI-Startdiensts.
Dieser Schutz wird von VBS auf Betriebssystemseitentabellen angewendet.
Beachten Sie außerdem Folgendes:
Verwenden Sie keine Abschnitte, die sowohl beschreibbar als auch ausführbar sind.
Versuchen Sie nicht, den ausführbaren Systemspeicher direkt zu ändern.
Keinen dynamischen Code verwenden