Steuern der Integrität von Windows-Geräten

In diesem Artikel wird eine End-to-End-Lösung beschrieben, mit der Sie hochwertige Ressourcen schützen können, indem Sie die Integrität von Windows-Geräten erzwingen, steuern und melden.

Einführung

Für BYOD-Szenarien (Bring Your Own Device) verwenden Benutzer kommerziell verfügbare Geräte, um sowohl auf arbeitsbezogene Ressourcen als auch auf ihre persönlichen Daten zuzugreifen. Benutzer möchten das Gerät ihrer Wahl verwenden, um nicht nur über das interne Netzwerk, sondern auch von überall aus auf die Anwendungen, Daten und Ressourcen der Organisation zuzugreifen. Dieses Phänomen wird auch als Consumerisierung der IT bezeichnet.

Benutzer möchten die beste Produktivitätserfahrung erzielen, wenn sie auf Unternehmensanwendungen zugreifen und auf ihren Geräten an Organisationsdaten arbeiten. Dies bedeutet, dass sie nicht tolerieren, jedes Mal aufgefordert zu werden, ihre Geschäftlichen Anmeldeinformationen einzugeben, wenn sie auf eine Anwendung oder einen Dateiserver zugreifen. Aus Sicherheitssicht bedeutet dies auch, dass Benutzer Unternehmensanmeldeinformationen und Unternehmensdaten auf nicht verwalteten Geräten bearbeiten.

Mit der zunehmenden Nutzung von BYOD wird es mehr nicht verwaltete und potenziell fehlerhafte Systeme geben, die auf Unternehmensdienste, interne Ressourcen und Cloud-Apps zugreifen.

Selbst verwaltete Geräte können kompromittiert werden und schädlich werden. Organisationen müssen erkennen, wann die Sicherheit verletzt wurde, und so früh wie möglich reagieren, um hochwertige Ressourcen zu schützen.

Im weiteren Verlauf von Microsoft konzentrieren sich die Sicherheitsinvestitionen zunehmend auf sicherheitspräventive Schutzmaßnahmen sowie auf Erkennungs- und Reaktionsfunktionen.

Windows ist eine wichtige Komponente einer End-to-End-Sicherheitslösung, die sich nicht nur auf die Implementierung von präventiven Schutzmaßnahmen konzentriert, sondern auch Funktionen zum Nachweis der Geräteintegrität zur allgemeinen Sicherheitsstrategie hinzufügt.

Beschreibung einer stabilen End-to-End-Sicherheitslösung

Die heutige Bedrohungslandschaft im Computing nimmt mit einer Geschwindigkeit zu, die noch nie zuvor aufgetreten ist. Die Raffinesse krimineller Angriffe nimmt zu, und es besteht kein Zweifel, dass Schadsoftware jetzt sowohl Verbraucher als auch Fachleute in allen Branchen angreift.

In den letzten Jahren hat sich eine bestimmte Kategorie von Bedrohungen durchgesetzt: Advanced Persistent Threats (APTs). Der Begriff APT wird häufig verwendet, um jeden Angriff zu beschreiben, der anscheinend ständig auf einzelne Organisationen ausgerichtet ist. Tatsächlich umfasst diese Art von Angriff in der Regel entschlossene Angreifer, die alle erforderlichen Methoden oder Techniken verwenden können.

Bei den BYOD-Phänomenen stellt ein schlecht gewartetes Gerät ein Ziel der Wahl dar. Für einen Angreifer ist dies eine einfache Möglichkeit, den Sicherheitsnetzwerkperimeter zu verletzen, Zugriff auf hochwertige Ressourcen zu erhalten und sie dann zu stehlen.

Die Angreifer zielen auf Einzelpersonen ab, nicht speziell wegen ihrer Person, sondern wegen der Person, für die sie arbeiten. Ein infiziertes Gerät bringt Schadsoftware in eine Organisation, auch wenn die Organisation den Umkreis von Netzwerken gehärtet oder in ihren defensiven Status investiert hat. Eine defensive Strategie reicht nicht gegen diese Bedrohungen aus.

Ein anderer Ansatz

Anstatt den traditionellen Fokus auf die Verhinderung von Kompromittierungen zu legen, geht eine effektive Sicherheitsstrategie davon aus, dass entschlossene Angreifer erfolgreich alle Schutzmaßnahmen verletzen. Dies bedeutet, dass es notwendig ist, den Fokus von präventiven Sicherheitskontrollen auf die Erkennung und Reaktion auf Sicherheitsprobleme zu verlagern. Die Umsetzung der Risikomanagementstrategie gleicht daher die Investitionen in Prävention, Erkennung und Reaktion aus.

Da mobile Geräte zunehmend für den Zugriff auf Unternehmensinformationen verwendet werden, ist eine Möglichkeit zum Bewerten der Gerätesicherheit oder -integrität erforderlich. In diesem Abschnitt wird beschrieben, wie Sie die Bewertung der Geräteintegrität so bereitstellen, dass hochwertige Ressourcen vor fehlerhaften Geräten geschützt werden können.

Geräte, die für den Zugriff auf Unternehmensressourcen verwendet werden, müssen vertrauenswürdig sein. Ein effizienter End-to-End-Sicherheitsansatz ist in der Lage, die Geräteintegrität auszuwerten und den aktuellen Sicherheitsstatus zu verwenden, wenn Sie Zugriff auf eine hochwertige Ressource gewähren.

Ein robustes Design muss die Identität des Benutzers festlegen, die Authentifizierungsmethode bei Bedarf stärken und das Verhalten wie den Netzwerkspeicherort erlernen, von dem aus der Benutzer regelmäßig eine Verbindung herstellt. Darüber hinaus muss ein moderner Ansatz nur dann in der Lage sein, vertrauliche Inhalte freizugeben, wenn die Benutzergeräte als fehlerfrei und sicher eingestuft werden.

Die folgende Abbildung zeigt eine Lösung, die entwickelt wurde, um die Geräteintegrität aus der Cloud zu bewerten. Das Gerät authentifiziert den Benutzer über eine Verbindung mit einem Identitätsanbieter in der Cloud. Wenn die verwaltete Ressource streng vertrauliche Informationen enthält, kann die Engine für bedingten Zugriff des Identitätsanbieters die Sicherheitskonformität des mobilen Geräts überprüfen, bevor der Zugriff gewährt wird. Das Gerät des Benutzers kann seinen Integritätsstatus nachweisen, der jederzeit gesendet werden kann oder wenn die Verwaltung mobiler Geräte (Mobile Device Management, MDM) dies anfordert.

Windows-Geräte können vor Rootkits und Bootkits auf niedriger Ebene geschützt werden, indem Low-Level-Hardwaretechnologien wie Unified Extensible Firmware Interface (UEFI) Secure Boot verwendet werden.

Sicherer Start ist ein Firmwarevalidierungsprozess, der rootkit-Angriffe verhindert. sie ist Teil der UEFI-Spezifikation. Die Absicht von UEFI besteht darin, eine Standardmethode für die Kommunikation des Betriebssystems mit moderner Hardware zu definieren, die schneller und effizientere Eingabe-/Ausgabefunktionen (E/A) ausführen kann als ältere, softwareunterbrechungsgesteuerte BIOS-Systeme.

Ein Modul zum Nachweis der Geräteintegrität kann gemessene Startdaten, die durch ein Trusted Platform Module (TPM) geschützt sind, an einen Remotedienst übermitteln. Nachdem das Gerät erfolgreich gestartet wurde, werden die Messdaten des Startprozesses mithilfe eines sichereren und manipulationssicheren Kommunikationskanals an einen vertrauenswürdigen Clouddienst (Integritätsnachweisdienst) gesendet.

Der Remoteintegritätsnachweisdienst führt eine Reihe von Überprüfungen der Messungen durch. Es überprüft sicherheitsbezogene Datenpunkte, einschließlich Startstatus (sicherer Start, Debugmodus usw.) und des Zustands von Komponenten, die die Sicherheit verwalten (BitLocker, Device Guard usw.). Anschließend wird der Integritätsstatus des Geräts übermittelt, indem ein integritätsverschlüsseltes Blob zurück an das Gerät gesendet wird.

Eine MDM-Lösung wendet in der Regel Konfigurationsrichtlinien an und stellt Software auf Geräten bereit. MDM definiert die Sicherheitsbaseline und kennt den Grad der Konformität des Geräts mit regelmäßigen Überprüfungen, um festzustellen, welche Software installiert ist und welche Konfiguration erzwungen wird, und bestimmt den Integritätsstatus des Geräts.

Eine MDM-Lösung fordert das Gerät auf, Geräteintegritätsinformationen zu senden und das integritätsverschlüsselte Blob an den Remoteintegritätsnachweisdienst weiterzuleiten. Der Remoteintegritätsnachweisdienst überprüft Geräteintegritätsdaten, überprüft, ob MDM mit demselben Gerät kommuniziert, und gibt dann einen Geräteintegritätsbericht an die MDM-Lösung zurück.

Eine MDM-Lösung wertet die Integritätsassertionen aus und kann abhängig von den Integritätsregeln der Organisation entscheiden, ob das Gerät fehlerfrei ist. Wenn das Gerät fehlerfrei und konform ist, übergibt MDM diese Informationen an den Identitätsanbieter, damit die Zugriffssteuerungsrichtlinie der Organisation aufgerufen werden kann, um Zugriff zu gewähren.

Der Zugriff auf Inhalte wird dann für die entsprechende Vertrauensebene für den Integritätsstatus und andere bedingte Elemente autorisiert.

Abhängig von den Anforderungen und der Vertraulichkeit des verwalteten Medienobjekts kann der Geräteintegritätsstatus bei der Verarbeitung einer Zugriffsanforderung mit Benutzeridentitätsinformationen kombiniert werden. Der Zugriff auf Inhalte wird dann mit der entsprechenden Vertrauensstufe autorisiert. Die Engine für bedingten Zugriff kann so strukturiert sein, dass eine größere Überprüfung möglich ist, je nach Empfindlichkeit der verwalteten Ressource. Wenn beispielsweise Zugriff auf hochwertige Daten angefordert wird, muss möglicherweise eine weitere Sicherheitsauthentifizierung eingerichtet werden, indem der Benutzer abgefragt wird, um einen Telefonanruf entgegennehmen zu können, bevor der Zugriff gewährt wird.

Sicherheitsinvestitionen von Microsoft in Windows

In Windows gibt es drei Säulen der Investitionen:

• Sichere Identitäten. Microsoft ist Teil der FIDO-Allianz, die darauf abzielt, eine interoperable Methode der sicheren Authentifizierung bereitzustellen, indem sie von der Verwendung von Kennwörtern für die Authentifizierung sowohl auf dem lokalen System als auch für Dienste wie lokale Ressourcen und Cloudressourcen weggeht.
• Schutz von Informationen. Microsoft investiert, um Organisationen eine bessere Kontrolle darüber zu geben, wer Zugriff auf wichtige Daten hat und was sie mit diesen Daten tun können. Mit Windows können Organisationen Richtlinien nutzen, die angeben, welche Anwendungen als Unternehmensanwendungen betrachtet werden und denen der Zugriff auf sichere Daten vertrauenswürdig ist.
• Bedrohungsresistenz. Microsoft unterstützt Organisationen dabei, Unternehmensressourcen besser vor Bedrohungen durch Schadsoftware und Angriffe zu schützen, indem sicherheitsrelevante Schutzmaßnahmen verwendet werden, die auf Hardware angewiesen sind.

Schützen, Steuern und Melden des Sicherheitsstatus von Windows-basierten Geräten

Dieser Abschnitt enthält eine Übersicht über die verschiedenen Teile der End-to-End-Sicherheitslösung, die dabei hilft, hochwertige Ressourcen und Informationen vor Angreifern und Schadsoftware zu schützen.

Zahl	Teil der Lösung	Beschreibung
1	Windows-basiertes Gerät	Wenn ein Windows-basiertes Gerät zum ersten Mal eingeschaltet wird, wird der OOBE-Bildschirm (Out-of-Box Experience) angezeigt. Während des Setups kann das Gerät automatisch in der Microsoft Entra-ID registriert und bei MDM registriert werden. Ein Windows-basiertes Gerät mit TPM kann den Integritätsstatus jederzeit mithilfe des Integritätsnachweisdiensts melden, der für alle unterstützten Editionen von Windows verfügbar ist.
2	Identitätsanbieter	Die Microsoft Entra-ID enthält Benutzer, registrierte Geräte und die registrierte Anwendung des Mandanten der Organisation. Ein Gerät gehört immer einem Benutzer, und ein Benutzer kann über mehrere Geräte verfügen. Ein Gerät wird als Objekt mit unterschiedlichen Attributen wie dem Konformitätsstatus des Geräts dargestellt. Eine vertrauenswürdige MDM kann den Konformitätsstatus aktualisieren. Microsoft Entra ID ist mehr als ein Repository. Microsoft Entra ID kann Benutzer und Geräte authentifizieren und den Zugriff auf verwaltete Ressourcen autorisieren. Microsoft Entra ID verfügt über eine Engine für die bedingte Zugriffssteuerung, die die Identität des Benutzers, den Standort des Geräts und auch den Konformitätsstatus des Geräts verwendet, wenn eine Entscheidung für den vertrauenswürdigen Zugriff getroffen wird.
3	Verwaltung mobiler Geräte	Windows verfügt über MDM-Unterstützung, mit der das Gerät sofort verwaltet werden kann, ohne einen Agent bereitzustellen. MDM kann Microsoft Intune oder eine beliebige MDM-Lösung eines Drittanbieters sein, die mit Windows kompatibel ist.
4	Remoteintegritätsnachweis	Der Integritätsnachweisdienst ist ein von Microsoft betriebener vertrauenswürdiger Clouddienst, der eine Reihe von Integritätsprüfungen durchführt und MDM meldet, welche Windows-Sicherheitsfeatures auf dem Gerät aktiviert sind. Die Sicherheitsüberprüfung umfasst den Startstatus (WinPE, abgesicherter Modus, Debug-/Testmodi) und Komponenten, die die Sicherheit und Integrität von Laufzeitvorgängen (BitLocker, Device Guard) verwalten.
5	Unternehmensverwaltete Ressource	Die vom Unternehmen verwaltete Ressource ist die zu schützende Ressource. Die Ressource kann z. B. Office 365, andere Cloud-Apps, lokale Webressourcen sein, die von Microsoft Entra ID veröffentlicht werden, oder sogar VPN-Zugriff.

Die Kombination aus Windows-basierten Geräten, Identitätsanbieter, MDM und Remoteintegritätsnachweis erstellt eine stabile End-to-End-Lösung, die die Integrität und Konformität von Geräten, die auf hochwertige Ressourcen zugreifen, überprüft.

Schützen von Geräten und Unternehmensanmeldeinformationen vor Bedrohungen

In diesem Abschnitt wird beschrieben, was Windows in Bezug auf Sicherheitsmaßnahmen bietet und welche Kontrolle gemessen und gemeldet werden kann.

Hardwarebasierte Windows-Sicherheitsabwehr

Die aggressivsten Formen von Schadsoftware versuchen, sich so früh wie möglich in den Startprozess einzufügen, damit sie frühzeitig die Kontrolle über das Betriebssystem übernehmen können und verhindern, dass Schutzmechanismen und Anti-Malware-Software funktionieren. Diese Art von schädlichem Code wird häufig als Rootkit oder Bootkit bezeichnet. Der beste Weg, um zu vermeiden, dass sie mit Schadsoftware auf niedriger Ebene umgehen müssen, besteht darin, den Startprozess zu sichern, damit das Gerät von Anfang an geschützt ist. Windows unterstützt mehrere Startschutzebenen. Einige dieser Features sind nur verfügbar, wenn bestimmte Hardwaretypen installiert sind. Weitere Informationen finden Sie im Abschnitt Hardwareanforderungen .

Windows unterstützt Features, um zu verhindern, dass komplexe Schadsoftware auf niedriger Ebene wie Rootkits und Bootkits während des Startvorgangs geladen wird:

• Trusted Platform Module. Ein Trusted Platform Module (TPM) ist eine Hardwarekomponente, die einzigartige Sicherheitsfeatures bereitstellt.

  Windows verwendet die Sicherheitsmerkmale eines TPM zum Messen der Startintegritätssequenz (und basierend darauf die automatische Entsperrung von durch BitLocker geschützten Laufwerken), zum Schutz von Anmeldeinformationen oder zum Integritätsnachweis.

  Ein TPM implementiert Steuerelemente, die die von der Trusted Computing Group (TCG) beschriebene Spezifikation erfüllen. Zum Zeitpunkt dieses Schreibens gibt es zwei Versionen der TPM-Spezifikation, die von TCG erstellt wurden und nicht miteinander kompatibel sind:

  • Die erste TPM-Spezifikation, Version 1.2, wurde im Februar 2005 vom TCG veröffentlicht und nach ISO/IEC 11889 standardisiert.
  • Die neueste TPM-Spezifikation, die als TPM 2.0 bezeichnet wird, wurde im April 2014 veröffentlicht und wurde vom ISO/IEC Joint Technical Committee (JTC) als ISO/IEC 11889:2015 genehmigt.

  Windows verwendet das TPM für kryptografische Berechnungen als Teil des Integritätsnachweises und zum Schutz der Schlüssel für BitLocker, Windows Hello, virtuelle Smartcards und andere Öffentliche Schlüsselzertifikate. Weitere Informationen finden Sie unter TPM-Anforderungen in Windows.

  Windows erkennt tpm-Spezifikationen der Versionen 1.2 und 2.0, die vom TCG erstellt wurden. Für die neuesten und modernen Sicherheitsfeatures unterstützt Windows nur TPM 2.0.

  TPM 2.0 bietet eine umfassende Revision der Funktionen über TPM 1.2:

  • Aktualisieren der Kryptografiestärke, um moderne Sicherheitsanforderungen zu erfüllen

    • Unterstützung für SHA-256 für PCRs
    • Unterstützung für den HMAC-Befehl

  • Flexibilität von Kryptografiealgorithmen zur Unterstützung von Behördenanforderungen

    • TPM 1.2 ist hinsichtlich der Algorithmen, die es unterstützen kann, stark eingeschränkt.
    • TPM 2.0 kann beliebige Algorithmen mit geringfügigen Aktualisierungen der TCG-Spezifikationsdokumente unterstützen.

  • Implementierungsübergreifende Konsistenz

    • Die TPM 1.2-Spezifikation ermöglicht Anbietern einen breiten Breitengrad bei der Auswahl von Implementierungsdetails.
    • TPM 2.0 standardisiert einen Großteil dieses Verhaltens

• Sicherer Start. Geräte mit UEFI-Firmware können so konfiguriert werden, dass nur vertrauenswürdige Bootloader des Betriebssystems geladen werden. Für den sicheren Start ist kein TPM erforderlich.

  Der grundlegendste Schutz ist das Feature "Sicherer Start", das ein Standardbestandteil der UEFI 2.2+-Architektur ist. Auf einem PC mit herkömmlichem BIOS kann jeder, der die Kontrolle über den Startvorgang übernehmen kann, mithilfe eines alternativen Betriebssystemladeprogramms starten und möglicherweise Zugriff auf Systemressourcen erhalten. Wenn sicherer Start aktiviert ist, können Sie nur mit einem Betriebssystemladeprogramm starten, das mit einem zertifikat signiert wurde, das in der UEFI Secure Boot DB gespeichert ist. Natürlich befinden sich das Microsoft-Zertifikat, das zum digitalen Signieren der Windows-Betriebssystemladeprogramme verwendet wird, in diesem Speicher, sodass UEFI das Zertifikat als Teil seiner Sicherheitsrichtlinie überprüfen kann. Der sichere Start muss standardmäßig auf allen Computern aktiviert sein, die im Rahmen des Windows-Hardwarekompatibilitätsprogramms für Windows zertifiziert sind.

  Sicherer Start ist ein auf UEFI-Firmware basierendes Feature, das das Signieren und Überprüfen kritischer Startdateien und Treiber zum Startzeitpunkt ermöglicht. Der sichere Start überprüft die Signaturwerte des Windows-Start-Managers, des BCD-Speichers, der Windows-Betriebssystemladeprogrammdatei und anderer startkritischer DLLs zum Startzeitpunkt, bevor das System vollständig in einem verwendbaren Betriebssystem gestartet werden kann, indem Richtlinien verwendet werden, die vom OEM zur Buildzeit definiert werden. Der sichere Start verhindert viele Arten von startbasiertem Rootkit, Schadsoftware und anderen sicherheitsbezogenen Angriffen auf die Windows-Plattform. Der sichere Start schützt den Startvorgang des Betriebssystems, unabhängig davon, ob es von einer lokalen Festplatte, USB, PXE oder DVD oder in einer vollständigen Windows- oder Windows-Wiederherstellungsumgebung (RE) gestartet wird. Der sichere Start schützt die Startumgebung einer Windows-Installation, indem die Signaturen der kritischen Startkomponenten überprüft werden, um sicherzustellen, dass böswillige Aktivitäten sie nicht kompromittieren. Der Schutz für den sicheren Start endet, nachdem die Windows-Kerneldatei (ntoskrnl.exe) geladen wurde.

  Hinweis

  Der sichere Start schützt die Plattform, bis der Windows-Kernel geladen ist. Dann übernehmen Schutzmechanismen wie ELAM.

• Konfigurationsrichtlinie für den sicheren Start. Erweitert die Funktion für den sicheren Start auf kritische Windows-Konfigurationen.

  Beispiele für geschützte Konfigurationsinformationen sind der Schutz von Disable Execute Bit (NX-Option) oder das Sicherstellen, dass die Testsignaturrichtlinie (Codeintegrität) nicht aktiviert werden kann. Diese Schutzmaßnahme stellt sicher, dass die Binärdateien und die Konfiguration des Computers nach Abschluss des Startvorgangs als vertrauenswürdig eingestuft werden können. Die Konfigurationsrichtlinie für den sicheren Start führt diese Schutzaktion mit der UEFI-Richtlinie aus. Diese Signaturen für diese Richtlinien werden auf die gleiche Weise wie Binärdateien des Betriebssystems für die Verwendung mit dem sicheren Start signiert.

  Die Konfigurationsrichtlinie für den sicheren Start muss mit einem privaten Schlüssel signiert werden, der einem der öffentlichen Schlüssel entspricht, die in der Liste Schlüsselaustauschschlüssel (Key Exchange Key, KEK) gespeichert sind. Die Microsoft-Zertifizierungsstelle ist in der KEK-Liste aller windows-zertifizierten Systeme für den sicheren Start enthalten. Standardmäßig muss eine vom Microsoft KEK signierte Richtlinie auf allen Sicheren Startsystemen funktionieren. BootMgr muss die Signatur anhand der KEK-Liste überprüfen, bevor eine signierte Richtlinie angewendet wird. Unter Windows ist die Standardkonfigurationsrichtlinie für den sicheren Start in bootmgr eingebettet.

  Der Bootloader prüft die digitale Signatur des Windows-Kernels, bevor dieser geladen wird. Der Windows-Kernel überprüft wiederum jede andere Komponente des Windows-Startprozesses, einschließlich der Starttreiber, Startdateien und der ELAM-Komponente. Dieser Schritt ist wichtig und schützt den restlichen Startprozess, indem überprüft wird, ob alle Windows-Startkomponenten über Integrität verfügen und als vertrauenswürdig eingestuft werden können.

• Antischadsoftware-Frühstart (Early Launch Antimalware, ELAM). ELAM testet alle Treiber vor dem Laden und verhindert, dass nicht genehmigte Treiber geladen werden.

  Herkömmliche Antischadsoftware-Apps werden erst gestartet, nachdem die Starttreiber geladen wurden. Dies gibt einem Rootkit, das als Treiber getarnt ist, die Möglichkeit, zu arbeiten. ELAM ist ein Windows-Mechanismus, der in einer früheren Version von Windows eingeführt wurde und die Ausführung von Antischadsoftware zu einem frühen Zeitpunkt in der Startsequenz ermöglicht. Daher ist die Antischadsoftwarekomponente die erste Komponente von Drittanbietern, die die Initialisierung anderer Starttreiber ausführen und steuern kann, bis das Windows-Betriebssystem betriebsbereit ist. Wenn das System mit einer vollständigen Laufzeitumgebung (Netzwerkzugriff, Speicher usw.) gestartet wird, wird eine antimaladsoftware mit vollem Funktionsumfang geladen.

  ELAM kann einen Microsoft- oder Nicht-Microsoft-Antischadsoftwaretreiber vor allen Nicht-Microsoft-Starttreibern und -Anwendungen laden und so die Vertrauenskette fortsetzen, die durch den sicheren Start und den vertrauenswürdigen Start eingerichtet wurde. Da das Betriebssystem noch nicht gestartet wurde und Windows so schnell wie möglich gestartet werden muss, hat ELAM eine einfache Aufgabe: Überprüfen Sie jeden Starttreiber, und ermitteln Sie, ob er in der Liste der vertrauenswürdigen Treiber enthalten ist. Wenn er nicht als vertrauenswürdig eingestuft wird, lädt Windows ihn nicht.

  Hinweis

  Windows Defender, die standardmäßig in Windows enthaltene Antischadsoftware von Microsoft, unterstützt ELAM; es kann durch eine drittanbieterkompatible Antischadsoftwarelösung ersetzt werden. Der Name des Windows Defender ELAM-Treibers ist WdBoot.sys. Windows Defender verwendet seinen ELAM-Treiber, um alle böswilligen Änderungen zurückzusetzen, die beim nächsten Neustart am Windows Defender-Treiber vorgenommen wurden. Dadurch wird verhindert, dass Kernelmodus-Schadsoftware dauerhafte Änderungen am Minifiltertreiber von Windows Defender vor dem Herunterfahren oder Neustart vornimmt.

  Der von ELAM signierte Treiber wird vor anderen Treibern oder Anwendungen von Drittanbietern geladen, sodass die Antischadsoftware versuche, den Startprozess zu manipulieren, indem versucht wird, nicht signierten oder nicht vertrauenswürdigen Code zu laden, zu erkennen und zu blockieren.

  Der ELAM-Treiber ist ein kleiner Treiber mit einer kleinen Richtliniendatenbank mit einem begrenzten Bereich, der sich auf Treiber konzentriert, die früh beim Systemstart geladen werden. Die Richtliniendatenbank wird in einer Registrierungsstruktur gespeichert, die auch mit dem TPM gemessen wird, um die Betriebsparameter des ELAM-Treibers aufzuzeichnen. Ein ELAM-Treiber muss von Microsoft signiert werden, und das zugehörige Zertifikat muss die ergänzende EKU (1.3.6.1.4.1.311.61.4.1) enthalten.

• Virtualisierungsbasierte Sicherheit (Hyper-V + Sicherer Kernel). Virtualisierungsbasierte Sicherheit ist eine neue erzwungene Sicherheitsgrenze, mit der Sie wichtige Teile von Windows schützen können.

  Virtualisierungsbasierte Sicherheit isoliert sensiblen Code wie Kernelmoduscodeintegrität oder vertrauliche Unternehmensdomänenanmeldeinformationen vom Rest des Windows-Betriebssystems. Weitere Informationen finden Sie im Abschnitt Virtualisierungsbasierte Sicherheit .

• Hypervisorgeschützte Codeintegrität (HVCI). Hypervisorgeschützte Codeintegrität ist ein Feature von Device Guard, das sicherstellt, dass nur Treiber, ausführbare Dateien und DLLs ausgeführt werden dürfen, die der Device Guard-Codeintegritätsrichtlinie entsprechen.

  Wenn diese Option aktiviert und konfiguriert ist, kann Windows die auf Hyper-V-Virtualisierung basierenden Sicherheitsdienste starten. HVCI hilft beim Schutz des Systemkerns (Kernels), privilegierten Treibern und Systemabwehrmaßnahmen wie Antischadsoftwarelösungen, indem verhindert wird, dass Schadsoftware zu einem frühen Zeitpunkt im Startvorgang oder nach dem Start ausgeführt wird.

  HVCI verwendet virtualisierungsbasierte Sicherheit, um die Codeintegrität zu isolieren. Kernelspeicher kann nur durch eine Überprüfung der Codeintegrität ausführbar werden. Diese Abhängigkeit von der Überprüfung bedeutet, dass Kernelspeicherseiten niemals beschreibbar und ausführbarer Code (W+X) und ausführbarer Code nicht direkt geändert werden können.

  Hinweis

  Device Guard-Geräte, auf denen die Kernelmoduscodeintegrität mit virtualisierungsbasierter Sicherheit ausgeführt wird, müssen über kompatible Treiber verfügen. Weitere Informationen finden Sie im Blogbeitrag Treiberkompatibilität mit Device Guard in Windows .

  Mit der Device Guard-Codeintegritätsfunktion können Organisationen steuern, welcher Code vertrauenswürdig ist und welche Anwendungen für die Ausführung im Benutzermodus zugelassen sind. Sie kann mithilfe einer Richtlinie konfiguriert werden. Die Device Guard-Codeintegritätsrichtlinie ist eine Binärdatei, die Von Microsoft empfohlen wird, zu signieren. Das Signieren der Codeintegritätsrichtlinie unterstützt den Schutz vor böswilligen Benutzern mit Administratorrechten, die versuchen, die aktuelle Codeintegritätsrichtlinie zu ändern oder zu entfernen.

• Credential Guard. Credential Guard schützt Unternehmensanmeldeinformationen mit hardwarebasierter Isolation von Anmeldeinformationen.

  Unter Windows zielt Credential Guard darauf ab, Domänen-Unternehmensanmeldeinformationen vor Diebstahl und Wiederverwendung durch Schadsoftware zu schützen. Mit Credential Guard hat Windows eine Architekturänderung implementiert, die die aktuellen Formen des Pass-the-Hash-Angriffs (PtH) grundsätzlich verhindert.

  Dieser angriffsfreie Zustand wird mithilfe von Hyper-V und dem neuen virtualisierungsbasierten Sicherheitsfeature erreicht, um einen geschützten Container zu erstellen, in dem vertrauenswürdiger Code und Geheimnisse vom Windows-Kernel isoliert sind. Dies bedeutet, dass ein Angreifer, selbst wenn der Windows-Kernel kompromittiert ist, keine Möglichkeit hat, die Daten zu lesen und zu extrahieren, die zum Initiieren eines PtH-Angriffs erforderlich sind. Credential Guard verhindert diesen nicht autorisierten Zugriff, da der Speicher, in dem Geheimnisse gespeichert sind, nicht mehr vom regulären Betriebssystem aus zugänglich ist, auch nicht im Kernelmodus. Der Hypervisor steuert, wer auf den Speicher zugreifen kann.

• Integritätsnachweis. Die Firmware des Geräts protokolliert den Startvorgang, und Windows kann ihn an einen vertrauenswürdigen Server senden, der die Integrität des Geräts überprüfen und bewerten kann.

  Windows nimmt Messungen der UEFI-Firmware vor, und jede der Windows- und Anti-Malware-Komponenten wird beim Laden während des Startvorgangs erstellt. Darüber hinaus werden sie sequenziell erfasst und gemessen, nicht alle gleichzeitig. Wenn diese Messungen abgeschlossen sind, werden ihre Werte digital signiert und sicher im TPM gespeichert und können nur geändert werden, wenn das System zurückgesetzt wird.

  Weitere Informationen finden Sie unter Sicherer Start und gemessener Start: Härten von Komponenten für den frühen Start gegen Schadsoftware.

  Bei jedem nachfolgenden Start werden die gleichen Komponenten gemessen, was einen Vergleich der Messungen mit einer erwarteten Baseline ermöglicht. Für mehr Sicherheit können die vom TPM gemessenen Werte signiert und an einen Remoteserver übertragen werden, der dann den Vergleich durchführen kann. Dieser Prozess, der als Remotegeräteintegritätsnachweis bezeichnet wird, ermöglicht es dem Server, den Integritätsstatus des Windows-Geräts zu überprüfen.

  Obwohl der sichere Start eine proaktive Form des Schutzes ist, ist der Integritätsnachweis eine reaktive Form des Startschutzes. Der Integritätsnachweis wird in Windows deaktiviert und von einem Antischadsoftware- oder MDM-Anbieter aktiviert. Im Gegensatz zum sicheren Start stoppt der Integritätsnachweis nicht den Startprozess und führt keine Korrektur durch, wenn eine Messung nicht funktioniert. Mit der Steuerung des bedingten Zugriffs verhindert der Integritätsnachweis jedoch den Zugriff auf hochwertige Ressourcen.

Virtualisierungsbasierte Sicherheit

Virtualisierungsbasierte Sicherheit bietet eine neue Vertrauensgrenze für Windows und verwendet Hyper-V-Hypervisortechnologie, um die Plattformsicherheit zu verbessern. Virtualisierungsbasierte Sicherheit bietet eine sichere Ausführungsumgebung zum Ausführen bestimmter vertrauenswürdigen Windows-Codes (Trustlet) und zum Schutz vertraulicher Daten.

Virtualisierungsbasierte Sicherheit trägt zum Schutz vor einem kompromittierten Kernel oder einem böswilligen Benutzer mit Administratorrechten bei. Virtualisierungsbasierte Sicherheit versucht nicht, sich vor einem physischen Angreifer zu schützen.

Die folgenden Windows-Dienste werden durch virtualisierungsbasierte Sicherheit geschützt:

• Credential Guard (LSA-Anmeldeinformationsisolation): verhindert Pass-the-Hash-Angriffe und Diebstahl von Unternehmensanmeldeinformationen, die durch Lesen und Löschen des Inhalts des lsass-Speichers auftreten.
• Device Guard (Hyper-V-Codeintegrität): Device Guard verwendet die neue virtualisierungsbasierte Sicherheit in Windows, um den Codeintegritätsdienst vom Windows-Kernel selbst zu isolieren. Dadurch kann der Dienst Signaturen verwenden, die von Ihrer unternehmensgesteuerten Richtlinie definiert werden, um zu bestimmen, was vertrauenswürdig ist. Tatsächlich wird der Codeintegritätsdienst zusammen mit dem Kernel in einem durch Windows Hypervisor geschützten Container ausgeführt.
• Andere isolierte Dienste: Unter Windows Server 2016 gibt es beispielsweise das vTPM-Feature, mit dem Sie verschlüsselte virtuelle Computer (VMs) auf Servern verwenden können.

Das folgende Schema enthält eine allgemeine Ansicht von Windows mit virtualisierungsbasierter Sicherheit.

Credential Guard

Wenn Credential Guard unter Windows aktiviert ist, führt der lokale Sicherheitsautoritätssubsystemdienst (Local Security Authority Subsystem Service, lsass.exe) einen vertraulichen Code im Isolierten Benutzermodus aus, um Daten vor Schadsoftware zu schützen, die möglicherweise im normalen Benutzermodus ausgeführt wird. Diese Codeausführung trägt dazu bei, dass geschützte Daten nicht gestohlen und auf Remotecomputern wiederverwendet werden, was viele PtH-Angriffe abmildert.

Credential Guard trägt zum Schutz von Anmeldeinformationen bei, indem sie entweder mit einem Pro-Start- oder einem persistenten Schlüssel verschlüsselt werden:

• Der Schlüssel pro Start wird für alle Anmeldeinformationen im Arbeitsspeicher verwendet, die keine Persistenz erfordern. Ein Beispiel für solche Anmeldeinformationen wäre ein TGT-Sitzungsschlüssel (Ticket-Granting Ticket). Dieser Schlüssel wird bei jeder Authentifizierung mit einem Schlüsselverteilungscenter (Key Distribution Center, KDC) ausgehandelt und mit einem Startschlüssel geschützt.
• Der persistente Schlüssel oder eine Ableitung wird verwendet, um Elemente zu schützen, die nach einem Neustart gespeichert und neu geladen werden. Dieser Schutz ist für die langfristige Speicherung vorgesehen und muss mit einem konsistenten Schlüssel geschützt werden. Credential Guard wird durch einen Registrierungsschlüssel aktiviert und dann mithilfe einer UEFI-Variablen aktiviert. Diese Aktivierung dient zum Schutz vor Remoteänderungen der Konfiguration. Die Verwendung einer UEFI-Variablen impliziert, dass physischer Zugriff erforderlich ist, um die Konfiguration zu ändern. Wenn lsass.exe erkennt, dass die Isolation von Anmeldeinformationen aktiviert ist, wird LsaIso.exe als isolierter Prozess erzeugt, wodurch sichergestellt wird, dass er im isolierten Benutzermodus ausgeführt wird. Der Start von LsaIso.exe erfolgt vor der Initialisierung eines Sicherheitssupportanbieters, wodurch sichergestellt wird, dass die Supportroutinen für den sicheren Modus bereit sind, bevor eine Authentifizierung beginnt.

Device Guard

Device Guard ist ein Feature von Windows Enterprise, mit dem Organisationen ein Gerät sperren können, um es vor der Ausführung nicht vertrauenswürdiger Software zu schützen. In dieser Konfiguration dürfen nur Anwendungen ausgeführt werden, die von der Organisation als vertrauenswürdig eingestuft werden.

Die Vertrauensentscheidung zur Ausführung von Code erfolgt mithilfe der Hyper-V-Codeintegrität, die in der virtualisierungsbasierten Sicherheit ausgeführt wird, einem durch Hyper-V geschützten Container, der zusammen mit regulärem Windows ausgeführt wird.

Hyper-V-Codeintegrität ist ein Feature, das die Integrität eines Treibers oder einer Systemdatei bei jedem Laden in den Arbeitsspeicher überprüft. Die Codeintegrität erkennt, ob ein nicht signierter Treiber oder eine Systemdatei in den Kernel geladen wird oder ob eine Systemdatei durch Schadsoftware geändert wurde, die von einem Benutzerkonto mit Administratorrechten ausgeführt wird. In x64-basierten Versionen von Windows müssen Kernelmodustreiber digital signiert werden.

Mit Device Guard können Organisationen jetzt ihre eigene Codeintegritätsrichtlinie für die Verwendung auf x64-Systemen unter Windows Enterprise definieren. Organisationen haben die Möglichkeit, die Richtlinie zu konfigurieren, die bestimmt, was als vertrauenswürdig eingestuft wird. Dazu gehören Treiber und Systemdateien sowie herkömmliche Desktopanwendungen und Skripts. Das System ist dann so gesperrt, dass nur Anwendungen ausgeführt werden, denen die Organisation vertraut.

Device Guard ist ein integriertes Feature von Windows Enterprise, das die Ausführung von unerwünschtem Code und Anwendungen verhindert. Device Guard kann mit zwei Regelaktionen konfiguriert werden: Zulassen und Verweigern:

• Zulassen schränkt die Ausführung von Anwendungen auf eine zulässige Liste von Code oder vertrauenswürdigen Herausgebern ein und blockiert alles andere.
• Verweigern schließt den Ansatz vertrauenswürdigen Herausgeber zulassen ab, indem die Ausführung einer bestimmten Anwendung blockiert wird.

Zum Zeitpunkt dieses Schreibens und laut den neuesten Untersuchungen von Microsoft sind mehr als 90 Prozent der Schadsoftware vollständig ohne Vorzeichen. Die Implementierung einer grundlegenden Device Guard-Richtlinie kann daher einfach und effektiv dazu beitragen, Schadsoftware zu blockieren. In der Tat hat Device Guard das Potenzial, weiter zu gehen, und kann auch helfen, signierte Schadsoftware zu blockieren.

Device Guard muss geplant und konfiguriert werden, um wirklich effektiv zu sein. Es ist nicht nur ein Schutz, der aktiviert oder deaktiviert ist. Device Guard ist eine Kombination aus Hardwaresicherheitsfeatures und Softwaresicherheitsfeatures, die bei gemeinsamer Konfiguration einen Computer sperren können, um ein möglichst sicheres und widerstandsfähiges System zu gewährleisten.

Die Device Guard-Lösung in Windows besteht aus drei verschiedenen Teilen:

• Der erste Teil ist ein Basissatz von Hardwaresicherheitsfeatures , die mit der vorherigen Version von Windows eingeführt wurden. MIT TPM für kryptografische Hardwarevorgänge und UEFI mit moderner Firmware können Sie zusammen mit dem sicheren Start steuern, was das Gerät beim Starten des Systems ausführt.
• Nach dem Hardwaresicherheitsfeature gibt es die Codeintegritäts-Engine. Unter Windows ist die Codeintegrität jetzt vollständig konfigurierbar und befindet sich jetzt im Isolierten Benutzermodus, einem Teil des Arbeitsspeichers, der durch virtualisierungsbasierte Sicherheit geschützt ist.
• Der letzte Teil von Device Guard ist die Verwaltbarkeit. Die Codeintegritätskonfiguration wird über bestimmte Gruppenrichtlinienobjekte, PowerShell-Cmdlets und MDM-Konfigurationsdienstanbieter (CSPs) verfügbar gemacht.

Weitere Informationen zum Bereitstellen von Device Guard in einem Unternehmen finden Sie im Device Guard-Bereitstellungshandbuch.

Device Guard-Szenarien

Wie bereits beschrieben, ist Device Guard eine leistungsstarke Möglichkeit, Systeme zu sperren. Device Guard ist nicht für die allgemeine Verwendung vorgesehen und ist möglicherweise nicht immer anwendbar, aber es gibt einige Szenarien mit hohem Interesse.

Device Guard ist nützlich und kann auf Systemen mit festen Workloads wie Kassen, Kioskcomputern, Sicheren Administratorarbeitsstationen (SAWs) oder gut verwalteten Desktops angewendet werden. Device Guard ist sehr relevant für Systeme mit einer klar definierten Software, die voraussichtlich ausgeführt wird und sich nicht zu häufig ändert. Es könnte auch dazu beitragen, Information Worker (IWs) über SAWs hinaus zu schützen, solange bekannt ist, was sie ausführen müssen und sich die Anwendungsmenge nicht täglich ändert.

SAWs sind Computer, die dazu entwickelt wurden, das Risiko einer Kompromittierung durch Schadsoftware, Phishing-Angriffe, gefälschte Websites und PtH-Angriffe und andere Sicherheitsrisiken erheblich zu reduzieren. Obwohl SAWs für diese Angriffe nicht als "Wundermittel" betrachtet werden können, sind diese Arten von Clients als Teil eines mehrstufigen, tief greifenden Sicherheitsansatzes hilfreich.

Um hochwertige Ressourcen zu schützen, werden SAWs verwendet, um sichere Verbindungen mit diesen Ressourcen herzustellen.

Auf vollständig verwalteten Unternehmensarbeitsstationen, auf denen Anwendungen mithilfe eines Verteilungstools wie Microsoft Configuration Manager, Intune oder einer beliebigen Geräteverwaltung von Drittanbietern installiert werden, ist Device Guard ebenfalls anwendbar. In diesem Szenario hat die Organisation eine gute Vorstellung von der Software, die ein durchschnittlicher Benutzer ausführt.

Es kann schwierig sein, Device Guard auf unternehmensweiten, leicht verwalteten Arbeitsstationen zu verwenden, auf denen der Benutzer normalerweise die Möglichkeit hat, Software selbst zu installieren. Wenn eine Organisation eine große Flexibilität bietet, ist es schwierig, Device Guard im Erzwingungsmodus auszuführen. Dennoch kann Device Guard im Überwachungsmodus ausgeführt werden, und in diesem Fall enthält das Ereignisprotokoll einen Datensatz aller Binärdateien, die gegen die Device Guard-Richtlinie verstoßen. Wenn Device Guard im Überwachungsmodus verwendet wird, können Organisationen umfangreiche Daten zu Treibern und Anwendungen erhalten, die Benutzer installieren und ausführen.

Bevor Sie von dem in Device Guard enthaltenen Schutz profitieren können, muss die Codeintegritätsrichtlinie mithilfe von Tools von Microsoft erstellt werden, aber die Richtlinie kann mit gängigen Verwaltungstools wie Gruppenrichtlinien bereitgestellt werden. Die Codeintegritätsrichtlinie ist ein binärcodiertes XML-Dokument, das Konfigurationseinstellungen für den Benutzer- und Kernelmodus von Windows sowie Einschränkungen für Windows-Skripthosts enthält. Die Device Guard-Codeintegritätsrichtlinie schränkt den Code ein, der auf einem Gerät ausgeführt werden kann.

Die signierte Device Guard-Richtlinie bietet einen stärkeren Schutz vor einem böswilligen lokalen Administrator, der versucht, Device Guard zu besiegen.

Wenn die Richtlinie signiert ist, wird die GUID der Richtlinie in einer sicheren UEFI-Variable vor dem Betriebssystem gespeichert, die Manipulationsschutz bietet. Die einzige Möglichkeit, die Device Guard-Richtlinie später zu aktualisieren, besteht darin, im Abschnitt UpdateSigner eine neue Version der Richtlinie bereitzustellen, die vomselben Signierer oder von einem Signierer signiert wurde, der als Teil der Device Guard-Richtlinie angegeben ist.

Die Bedeutung des Signierens von Anwendungen

Auf Computern mit Device Guard schlägt Microsoft vor, von einer Welt zu wechseln, in der nicht signierte Apps ohne Einschränkungen ausgeführt werden können, in eine Welt, in der nur signierter und vertrauenswürdiger Code unter Windows ausgeführt werden darf.

Mit Windows stellen Organisationen branchenspezifische Apps für Mitglieder der Organisation über die Microsoft Store-Infrastruktur zur Verfügung. Insbesondere branchenspezifische Apps sind in einem privaten Store im öffentlichen Microsoft Store verfügbar. Der Microsoft Store signiert und verteilt universelle Windows-Apps und klassische Windows-Apps. Alle aus dem Microsoft Store heruntergeladenen Apps sind signiert.

In Organisationen sind heute viele BRANCHENanwendungen nicht signiert. Die Codesignierung wird häufig als ein schwieriges Problem angesehen, das aus verschiedenen Gründen gelöst werden muss, z. B. aus dem Mangel an Codesignaturkenntnissen. Selbst wenn codesignieren eine bewährte Methode ist, werden viele interne Anwendungen nicht signiert.

Windows enthält Tools, mit denen IT-Experten anwendungen, die bereits gepackt wurden, nutzen und ausführen können, um weitere Signaturen zu erstellen, die zusammen mit vorhandenen Anwendungen verteilt werden können.

Warum sind Antischadsoftware- und Geräteverwaltungslösungen weiterhin erforderlich?

Obwohl Positivlistenmechanismen effizient sicherstellen, dass nur vertrauenswürdige Anwendungen ausgeführt werden können, können sie die Kompromittierung einer vertrauenswürdigen (aber anfälligen) Anwendung durch schädliche Inhalte, die eine bekannte Sicherheitsanfälligkeit ausnutzen, nicht verhindern. Device Guard schützt nicht vor schädlichem Code im Benutzermodus, der durch Ausnutzen von Sicherheitsrisiken ausgeführt wird.

Sicherheitsrisiken sind Schwachstellen in Software, die es einem Angreifer ermöglichen könnten, die Integrität, Verfügbarkeit oder Vertraulichkeit des Geräts zu gefährden. Einige der schlimmsten Sicherheitsrisiken ermöglichen es Angreifern, das kompromittierte Gerät auszunutzen, indem sie dazu führen, dass es schädlichen Code ohne Wissen des Benutzers ausgeführt wird.

Es ist üblich, dass Angreifer speziell gestaltete Inhalte verteilen, um bekannte Sicherheitsrisiken in Benutzermodussoftware wie Webbrowsern (und deren Plug-Ins), Java-VMs, PDF-Readern oder Dokument-Editoren auszunutzen. Bis heute wirken sich 90 Prozent der entdeckten Sicherheitsrisiken auf Benutzermodusanwendungen aus, verglichen mit dem Betriebssystem und den Kernelmodustreibern, die sie hosten.

Um diese Bedrohungen zu bekämpfen, ist Patchen die effektivste Kontrolle, wobei Anti-Malware-Software komplementäre Verteidigungsebenen bildet.

Die meisten Anwendungssoftware verfügt nicht über die Möglichkeit, sich selbst zu aktualisieren. Selbst wenn der Softwarehersteller ein Update veröffentlicht, das das Sicherheitsrisiko behebt, weiß der Benutzer möglicherweise nicht, dass das Update verfügbar ist oder wie es abgerufen werden kann, und bleibt daher anfällig für Angriffe. Organisationen müssen weiterhin Geräte verwalten und Sicherheitsrisiken patchen.

MDM-Lösungen werden zunehmend als einfache Geräteverwaltungstechnologie verwendet. Windows erweitert die Verwaltungsfunktionen, die für MDMs verfügbar sind. Ein wichtiges Feature, das Microsoft Windows hinzugefügt hat, ist die Möglichkeit für MDMs, eine starke Aussage zur Geräteintegrität von verwalteten und registrierten Geräten zu erhalten.

Nachweis über Geräteintegrität

Der Geräteintegritätsnachweis verwendet das TPM, um kryptografisch starke und überprüfbare Messungen der Softwarekette bereitzustellen, die zum Starten des Geräts verwendet wird.

Für Windows-basierte Geräte führt Microsoft eine neue öffentliche API ein, mit der MDM-Software auf einen Remotenachweisdienst namens Windows Health Attestation Service zugreifen kann. Ein Integritätsnachweisergebnis kann zusätzlich zu anderen Elementen verwendet werden, um den Zugriff auf Netzwerke, Apps oder Dienste zuzulassen oder zu verweigern, je nachdem, ob sich Geräte als fehlerfrei erweisen.

Weitere Informationen zum Nachweis der Geräteintegrität finden Sie im Abschnitt Erkennen eines fehlerhaften Windows-basierten Geräts .

Windows-Edition und Lizenzierungsanforderungen

In der folgenden Tabelle sind die Windows-Editionen aufgeführt, die den Dienst zum Nachweis der Geräteintegrität unterstützen:

Windows Pro	Windows Enterprise	Windows Pro Education/SE	Windows Education
Ja	Ja	Ja	Ja

Lizenzberechtigungen für den Geräteintegritätsnachweisdienst werden von den folgenden Lizenzen gewährt:

Windows Pro/Pro Education/SE	Windows Enterprise E3	Windows Enterprise E5	Windows Education A3	Windows Education A5
Ja	Ja	Ja	Ja	Ja

Weitere Informationen zur Windows-Lizenzierung finden Sie unter Übersicht über die Windows-Lizenzierung.

Hardwareanforderungen

In der folgenden Tabelle sind die Hardwareanforderungen für virtualisierungsbasierte Sicherheitsdienste und das Integritätsnachweisfeature aufgeführt. Weitere Informationen finden Sie unter Mindesthardwareanforderungen.

Hardware	Grund
UEFI 2.3.1 oder höher Firmware mit aktiviertem sicheren Start	Erforderlich, um den sicheren UEFI-Start zu unterstützen. Der sichere UEFI-Start stellt sicher, dass das Gerät nur autorisierten Code startet. Darüber hinaus muss die Startintegrität (Platform Secure Boot) gemäß den Anforderungen in Hardware Compatibility Specification for Systems for Windows (Hardwarekompatibilitätsspezifikation für Windows) im Unterabschnitt "System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby" unterstützt werden.
Virtualisierungserweiterungen wie Intel VT-x, AMD-V und SLAT müssen aktiviert sein.	Erforderlich, um virtualisierungsbasierte Sicherheit zu unterstützen. Anmerkung: Device Guard kann aktiviert werden, ohne virtualisierungsbasierte Sicherheit zu verwenden.
X64-Prozessor	Erforderlich, um virtualisierungsbasierte Sicherheit zu unterstützen, die Windows Hypervisor verwendet. Hyper-V wird nur auf x64-Prozessoren (und nicht auf x86) unterstützt. Der DMA-Schutz (Direct Memory Access) kann aktiviert werden, um zusätzlichen Speicherschutz bereitzustellen, erfordert jedoch, dass Prozessoren DMA-Schutztechnologien enthalten.
IOMMU, z. B. Intel VT-d, AMD-Vi	Die Unterstützung für die IOMMU in Windows verbessert die Systemresilienz gegen DMA-Angriffe.
Trusted Platform Module (TPM)	Erforderlich, um den Integritätsnachweis zu unterstützen, und für andere Schlüsselschutzfunktionen für virtualisierungsbasierte Sicherheit erforderlich. TPM 2.0 wird unterstützt. Unterstützung für TPM 1.2 wurde ab Windows 10, Version 1607 (RS1) hinzugefügt.

Dieser Abschnitt enthält Informationen zu mehreren eng verwandten Steuerelementen in Windows. Die mehrschichtige Verteidigung und der tief greifende Ansatz helfen dabei, Schadsoftware auf niedriger Ebene während der Startsequenz zu beseitigen. Virtualisierungsbasierte Sicherheit ist eine grundlegende Änderung der Betriebssystemarchitektur, die eine neue Sicherheitsgrenze hinzufügt. Device Guard und Credential Guard tragen jeweils dazu bei, nicht vertrauenswürdigen Code zu blockieren und Unternehmensdomänenanmeldeinformationen vor Diebstahl und Wiederverwendung zu schützen. In diesem Abschnitt wurde auch kurz die Bedeutung der Verwaltung von Geräten und patchen von Sicherheitsrisiken erläutert. All diese Technologien können verwendet werden, um Geräte zu härten und zu sperren und gleichzeitig das Risiko zu begrenzen, dass Angreifer sie kompromittieren.

Erkennen eines fehlerhaften Windows-basierten Geräts

Bis heute betrachten viele Organisationen Geräte nur dann als konform mit der Unternehmensrichtlinie, nachdem sie verschiedene Überprüfungen bestanden haben, die beispielsweise zeigen, dass sich das Betriebssystem im richtigen Zustand befindet, ordnungsgemäß konfiguriert ist und der Sicherheitsschutz aktiviert ist. Leider ist diese Form der Berichterstellung bei heutigen Systemen nicht ganz zuverlässig, da Schadsoftware eine Software-Aussage über die Systemintegrität spoofen kann. Ein Rootkit oder ein ähnlicher Exploit auf niedriger Ebene kann herkömmlichen Compliancetools einen falschen fehlerfreien Zustand melden.

Die größte Herausforderung bei Rootkits besteht darin, dass sie für den Client nicht erkennbar sein können. Da sie vor Antischadsoftware beginnen und über Berechtigungen auf Systemebene verfügen, können sie sich vollständig verschleiern, während sie weiterhin auf Systemressourcen zugreifen. Infolgedessen scheinen herkömmliche Computer, die mit Rootkits infiziert sind, fehlerfrei zu sein, selbst wenn Antischadsoftware ausgeführt wird.

Wie bereits erwähnt, verwendet das Integritätsnachweisfeature von Windows die TPM-Hardwarekomponente, um eine Messung jeder startbezogenen Komponente sicher aufzuzeichnen, einschließlich Firmware, Windows-Kernel und sogar Frühstarttreibern. Da der Integritätsnachweis die hardwarebasierten Sicherheitsfunktionen von TPM verwendet, bleibt das Protokoll aller startgemessenen Komponenten außerhalb der Reichweite von Schadsoftware.

Nachdem die Geräte einen vertrauenswürdigen Startstatus bestätigt haben, können sie nachweisen, dass sie keine Schadsoftware auf niedriger Ebene ausführen, die spätere Konformitätsprüfungen spoofen könnte. Der TPM-basierte Integritätsnachweis bietet einen zuverlässigen Vertrauensanker für Ressourcen, die hochwertige Daten enthalten.

Was ist das Konzept der Geräteintegrität?

Um das Konzept der Geräteintegrität zu verstehen, ist es wichtig, die traditionellen Maßnahmen zu kennen, die IT-Experten ergriffen haben, um die Verletzung von Schadsoftware zu verhindern. Technologien zur Bekämpfung von Schadsoftware konzentrieren sich stark auf die Verhinderung von Installation und Verteilung.

Die Verwendung herkömmlicher Technologien zur Verhinderung von Schadsoftware wie Antischadsoftware oder Patchlösungen bringt jedoch eine neue Reihe von Problemen für IT-Experten mit sich: die Möglichkeit, die Compliance von Geräten zu überwachen und zu steuern, die auf die Ressourcen der Organisation zugreifen.

Die Definition der Gerätekonformität variiert je nach installierter Antischadsoftware, Gerätekonfigurationseinstellungen, Patchverwaltungsbaseline und anderen Sicherheitsanforderungen einer Organisation. Die Integrität des Geräts ist jedoch Teil der allgemeinen Gerätekonformitätsrichtlinie.

Die Integrität des Geräts ist nicht binär und hängt von der Sicherheitsimplementierung der Organisation ab. Der Integritätsnachweisdienst stellt informationen an die MDM zurück, für die Sicherheitsfeatures während des Startvorgangs des Geräts mithilfe eines vertrauenswürdigen Hardware-TPM aktiviert sind.

Der Integritätsnachweis liefert jedoch nur Informationen, weshalb eine MDM-Lösung erforderlich ist, um eine Entscheidung zu treffen und durchzusetzen.

Integritätsnachweis für Remotegeräte

Unter Windows bezieht sich der Integritätsnachweis auf ein Feature, bei dem die während des Startvorgangs generierten gemessenen Startdaten an einen remoten Dienst zum Nachweis der Geräteintegrität gesendet werden, der von Microsoft betrieben wird.

Dieser Ansatz ist der sicherste, der für Windows-basierte Geräte zur Verfügung steht, um zu erkennen, wenn sicherheitsrelevante Schutzmaßnahmen nicht mehr vorhanden sind. Während des Startvorgangs werden das TCG-Protokoll und die PCRs-Werte an einen Microsoft-Remote-Clouddienst gesendet. Protokolle werden dann vom Integritätsnachweisdienst überprüft, um zu ermitteln, welche Änderungen auf dem Gerät aufgetreten sind.

Eine vertrauende Seite wie eine MDM kann den vom Remoteintegritätsnachweisdienst generierten Bericht überprüfen.

Windows unterstützt Integritätsnachweisszenarien, indem Anwendungen zugriff auf den zugrunde liegenden Integritätsnachweis-Konfigurationsdienstanbieter (Health Attestation Configuration Service Provider, CSP) gewährt werden, damit Anwendungen ein Integritätsnachweistoken anfordern können. Die Messung der Startsequenz kann jederzeit lokal durch einen Anti-Malware- oder MDM-Agent überprüft werden.

Der Remotegeräteintegritätsnachweis in Kombination mit einer MDM bietet eine hardwarebasierte Methode zum Melden des aktuellen Sicherheitsstatus und zum Erkennen von Änderungen, ohne der auf dem System ausgeführten Software vertrauen zu müssen.

Wenn schädlicher Code auf dem Gerät ausgeführt wird, ist die Verwendung eines Remoteservers erforderlich. Wenn ein Rootkit auf dem Gerät vorhanden ist, ist die Antischadsoftware nicht mehr zuverlässig, und ihr Verhalten kann durch einen bösartigen Code, der zu einem frühen Zeitpunkt in der Startsequenz ausgeführt wird, kapern. Aus diesem Grund ist es wichtig, Secure Boot und Device Guard zu verwenden, um zu steuern, welcher Code während der Startsequenz geladen wird.

Die Antischadsoftware kann suchen, um festzustellen, ob die Startsequenz Anzeichen von Schadsoftware enthält, z. B. ein Rootkit. Es kann auch das TCG-Protokoll und die PCRs an einen Remoteintegritätsnachweisserver senden, um eine Trennung zwischen der Messkomponente und der Überprüfungskomponente bereitzustellen.

Der Integritätsnachweis protokolliert die Messungen während des Startvorgangs in verschiedenen TPM-Plattformkonfigurationsregistern (PCRs) und TCG-Protokollen.

Wenn Sie ein Gerät starten, das mit TPM ausgestattet ist, wird eine Messung verschiedener Komponenten durchgeführt. Zu diesen Komponenten gehören Firmware, UEFI-Treiber, CPU-Microcode und alle Windows-Treiber, deren Typ Start ist. Die Rohmessungen werden in den TPM-PCR-Registern gespeichert, während die Details aller Ereignisse (ausführbarer Pfad, Zertifizierung von Autoritäten usw.) im TCG-Protokoll verfügbar sind.

Der Integritätsnachweisprozess funktioniert wie folgt:

1. Hardwarestartkomponenten werden gemessen.
2. Startkomponenten des Betriebssystems werden gemessen.
3. Wenn Device Guard aktiviert ist, wird die aktuelle Device Guard-Richtlinie gemessen.
4. Der Windows-Kernel wird gemessen.
5. Antivirensoftware wird als erster Kernelmodustreiber gestartet.
6. Starttreiber werden gemessen.
7. Der MDM-Server über den MDM-Agent gibt mithilfe des Integritätsnachweis-CSP einen Integritätsprüfungsbefehl aus.
8. Startmessungen werden vom Integritätsnachweisdienst überprüft.

Der folgende Prozess beschreibt, wie Integritätsstartmessungen an den Integritätsnachweisdienst gesendet werden:

1. Der Client (ein Windows-basiertes Gerät mit TPM) initiiert die Anforderung mit dem Remotegeräteintegritätsnachweisdienst. Da erwartet wird, dass der Integritätsnachweisserver ein Microsoft-Clouddienst ist, ist der URI bereits im Client vorab bereitgestellt.

2. Der Client sendet dann das TCG-Protokoll, die von AIK signierten Daten (PCR-Werte, Startzähler) und die Informationen zum AIK-Zertifikat.

3. Der Integritätsnachweisdienst des Remotegeräts dann:

   1. Überprüft, ob das AIK-Zertifikat von einer bekannten und vertrauenswürdigen Zertifizierungsstelle ausgestellt wird und das Zertifikat gültig und nicht widerrufen wird.
   2. Überprüft, ob die Signatur in den PCR-Anführungszeichen korrekt und mit dem TCG-Protokollwert konsistent ist.
   3. Analysiert die Eigenschaften im TCG-Protokoll.
   4. Gibt das Geräteintegritätstoken aus, das die Integritätsinformationen, die AIK-Informationen und die Startindikatorinformationen enthält. Das Integritätstoken enthält auch eine gültige Ausstellungszeit. Das Geräteintegritätstoken ist verschlüsselt und signiert. Dies bedeutet, dass die Informationen geschützt sind und nur für den ausstellenden Integritätsnachweisdienst zugänglich sind.

4. Der Client speichert das integritätsverschlüsselte Blob in seinem lokalen Speicher. Das Geräteintegritätstoken enthält den Geräteintegritätsstatus, eine Geräte-ID (Windows AIK) und den Startindikator.

Komponenten zum Nachweis der Geräteintegrität

Die Lösung zum Nachweis der Geräteintegrität umfasst verschiedene Komponenten: TPM, Integritätsnachweis-CSP und Windows-Integritätsnachweisdienst. Diese Komponenten werden in diesem Abschnitt beschrieben.

Trusted Platform Module

In diesem Abschnitt wird beschrieben, wie PCRs (die Systemkonfigurationsdaten enthalten), Endorsement Key (EK) (die als Identitätskarte für TPM fungieren), SRK (die Schlüssel schützen) und AIKs (die den Plattformstatus melden können) für die Integritätsnachweisberichterstattung verwendet werden.

Vereinfacht ist das TPM eine passive Komponente mit begrenzten Ressourcen. Es kann Zufallszahlen, RSA-Schlüssel, kurze Daten entschlüsseln und Hashes speichern, die beim Starten des Geräts verwendet werden.

Ein TPM umfasst eine einzelne Komponente:

• Ein RSA-Schlüsselgenerator mit 2048 Bit
• Zufallszahlengenerator
• Nicht flüchtiger Speicher zum Speichern von EK-, SRK- und AIK-Schlüsseln
• Eine Kryptografie-Engine zum Verschlüsseln, Entschlüsseln und Signieren
• Flüchtiger Speicher zum Speichern der PCRs und RSA-Schlüssel

Endorsement Key

Das TPM verfügt über einen eingebetteten eindeutigen kryptografischen Schlüssel, der als Endorsement Key bezeichnet wird. Der TPM-Endorsement Key ist ein Paar von asymmetrischen Schlüsseln (RSA-Größe 2048 Bits).

Der öffentliche Schlüssel des Endorsement Key wird zum Senden von sicher vertraulichen Parametern verwendet, z. B. beim Besitz des TPM, das den definierenden Hash des Besitzerkennworts enthält. Der private EK-Schlüssel wird beim Erstellen von sekundären Schlüsseln wie AIKs verwendet.

Der Endorsement Key fungiert als Identitätskarte für das TPM. Weitere Informationen finden Sie unter Grundlegendes zum TPM-Endorsement Key.

Der Endorsement Key wird häufig von einem oder zwei digitalen Zertifikaten begleitet:

• Ein Zertifikat wird vom TPM-Hersteller erstellt und als Endorsement Certificate (Endorsement Certificate) bezeichnet. Das Endorsement Certificate wird verwendet, um die Authentizität des TPM (z. B. dass es sich um ein echtes TPM handelt, das von einem bestimmten Chiphersteller hergestellt wird) für lokale Prozesse, Anwendungen oder Clouddienste nachzuweisen. Das Endorsement Certificate wird während der Herstellung oder beim ersten Initialisieren des TPM durch Kommunikation mit einem Onlinedienst erstellt.
• Das andere Zertifikat wird vom Plattform-Generator erstellt und als Plattformzertifikat bezeichnet, um anzugeben, dass ein bestimmtes TPM in ein bestimmtes Gerät integriert ist. Für bestimmte Geräte, die firmwarebasiertes TPM verwenden, das von Intel oder Qualcomm erstellt wurde, wird das Endorsement Certificate erstellt, wenn das TPM während der Windows-Willkommensseite initialisiert wird.

• Für Intel Firmware TPM: https://ekop.intel.com/ekcertservice
• Für Qualcomm Firmware TPM: https://ekcert.spserv.microsoft.com/

Nachweisidentitätsschlüssel

Da das Endorsement Certificate für jedes Gerät eindeutig ist und sich nicht ändert, kann die Verwendung des Zertifikats Datenschutzbedenken darstellen, da es theoretisch möglich ist, ein bestimmtes Gerät nachzuverfolgen. Um dieses Datenschutzproblem zu vermeiden, stellt Windows basierend auf dem Endorsement Certificate einen abgeleiteten Nachweisanker aus. Dieser Zwischenschlüssel, der mit einem Endorsement Key bestätigt werden kann, ist der Nachweisidentitätsschlüssel (Attestation Identity Key, AIK), und das entsprechende Zertifikat wird als AIK-Zertifikat bezeichnet. Dieses AIK-Zertifikat wird von einem Microsoft-Clouddienst ausgestellt.

Der AIK ist ein asymmetrisches (öffentliches/privates) Schlüsselpaar, das als Ersatz für das EK als Identität für das TPM aus Datenschutzgründen verwendet wird. Der private Teil einer AIK wird nie außerhalb des TPM offengelegt oder verwendet und kann nur innerhalb des TPM für eine begrenzte Anzahl von Vorgängen verwendet werden. Darüber hinaus kann es nur zum Signieren und nur für eingeschränkte TPM-definierte Vorgänge verwendet werden.

Windows erstellt AIKs, die vom TPM geschützt werden, sofern verfügbar, bei denen es sich um 2048-Bit-RSA-Signaturschlüssel handelt. Microsoft hostt einen Clouddienst namens Microsoft Cloud CA, um kryptografisch festzustellen, dass es mit einem echten TPM kommuniziert und dass das TPM den präsentierten AIK besitzt. Nachdem der Microsoft Cloud CA-Dienst diese Fakten festgestellt hat, stellt er ein AIK-Zertifikat für das Windows-basierte Gerät aus.

Viele vorhandene Geräte, die ein Upgrade auf Windows 10 durchführen, verfügen nicht über ein TPM, oder das TPM enthält kein Bestätigungszertifikat. Um diese Geräte unterzubringen, lässt Windows 10 die Ausstellung von AIK-Zertifikaten zu, ohne dass ein Endorsement Certificate vorhanden ist. Solche AIK-Zertifikate werden nicht von der Microsoft Cloud-Zertifizierungsstelle ausgestellt. Diese Zertifikate sind nicht so vertrauenswürdig wie ein Endorsement Certificate, das während der Herstellung in das Gerät eingebrannt wird, aber es bietet Kompatibilität für erweiterte Szenarien wie Windows Hello for Business ohne TPM.

Dem ausgestellten AIK-Zertifikat wird eine spezielle OID hinzugefügt, um zu bestätigen, dass das Endorsement Certificate während des Nachweisprozesses verwendet wurde. Diese Informationen können von einer vertrauenden Seite verwendet werden, um zu entscheiden, ob Geräte, die mit AIK-Zertifikaten ohne Endorsement Certificate bestätigt wurden, abgelehnt oder akzeptiert werden sollen. Ein weiteres Szenario kann darin bestehen, den Zugriff auf hochwertige Ressourcen von Geräten nicht zuzulassen, die durch ein AIK-Zertifikat bestätigt werden, das nicht durch ein Endorsement Certificate gesichert ist.

Speicherstammschlüssel

Der Speicherstammschlüssel (Storage Root Key, SRK) ist ebenfalls ein asymmetrisches Schlüsselpaar (RSA mit einer Länge von mindestens 2048 Bits). Der SRK spielt eine wichtige Rolle und wird zum Schutz von TPM-Schlüsseln verwendet, sodass diese Schlüssel nicht ohne das TPM verwendet werden können. Der SRK-Schlüssel wird erstellt, wenn der Besitz des TPM übernommen wird.

Plattformkonfigurationsregister

Das TPM enthält eine Reihe von Registern, die eine kryptografische Darstellung der Software und des Zustands des gestarteten Systems bereitstellen. Diese Register werden als Plattformkonfigurationsregister (PLATFORM Configuration Registers, PCRs) bezeichnet.

Die Messung der Startsequenz basiert auf dem PCR- und TCG-Protokoll. Um einen statischen Vertrauensstamm einzurichten, muss das Gerät beim Starten des Geräts in der Lage sein, den Firmwarecode vor der Ausführung zu messen. In diesem Fall wird der Core Root of Trust for Measurement (CRTM) vom Start aus ausgeführt, berechnet den Hash der Firmware, speichert ihn dann durch Erweitern des Registers PCR[0] und überträgt die Ausführung an die Firmware.

PCRs werden beim Starten der Plattform auf 0 festgelegt. Dies ist die Aufgabe der Firmware, die die Plattform startet, um Komponenten in der Startkette zu messen und die Messungen in den PCRs aufzuzeichnen. In der Regel übernehmen Startkomponenten den Hash der nächsten Komponente, die ausgeführt werden soll, und zeichnen die Messungen in den PCRs auf. Die anfängliche Komponente, die die Messkette startet, wird implizit als vertrauenswürdig eingestuft. Diese Komponente ist die CRTM. Plattformhersteller müssen über einen sicheren Updateprozess für die CRTM verfügen oder keine Updates dafür zulassen. Die PCRs zeichnen einen kumulativen Hash der komponenten auf, die gemessen wurden.

Der Wert einer PCR allein ist schwer zu interpretieren (es handelt sich nur um einen Hashwert), aber Plattformen führen in der Regel ein Protokoll mit Details dazu, was gemessen wurde, und die PCRs stellen lediglich sicher, dass das Protokoll nicht manipuliert wurde. Die Protokolle werden als TCG-Protokoll bezeichnet. Jedes Mal, wenn eine Register-PCR erweitert wird, wird ein Eintrag zum TCG-Protokoll hinzugefügt. Daher wird während des gesamten Startvorgangs eine Ablaufverfolgung des ausführbaren Codes und der Konfigurationsdaten im TCG-Protokoll erstellt.

TPM-Bereitstellung

Damit das TPM eines Windows-basierten Geräts verwendet werden kann, muss es zuerst bereitgestellt werden. Der Bereitstellungsprozess unterscheidet sich je nach TPM-Versionen, führt aber bei erfolgreicher Ausführung dazu, dass das TPM verwendet werden kann und die Besitzerautorisierungsdaten (ownerAuth) für das TPM lokal in der Registrierung gespeichert werden.

Wenn das TPM bereitgestellt wird, versucht Windows zuerst, die EK- und lokal gespeicherten OwnerAuth-Werte zu ermitteln, indem es in der Registrierung an folgendem Speicherort sucht: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Während des Bereitstellungsprozesses muss das Gerät möglicherweise neu gestartet werden.

Das PowerShell-Cmdlet Get-TpmEndorsementKeyInfo kann mit Administratorrechten verwendet werden, um Informationen zum Endorsement Key und den Zertifikaten des TPM abzurufen.

Wenn der TPM-Besitz nicht bekannt ist, aber das EK vorhanden ist, stellt die Clientbibliothek das TPM bereit und speichert den resultierenden OwnerAuth-Wert in der Registrierung, wenn die Richtlinie zulässt, dass der öffentliche SRK-Teil am folgenden Speicherort gespeichert wird: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub

Im Rahmen des Bereitstellungsprozesses erstellt Windows eine AIK mit dem TPM. Wenn dieser Vorgang ausgeführt wird, wird der resultierende öffentliche AIK-Teil in der Registrierung am folgenden Speicherort gespeichert: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub

Windows-Integritätsnachweis-CSP

Windows enthält einen Konfigurationsdienstanbieter (Configuration Service Provider, CSP), der auf die Interaktion mit dem Integritätsnachweisfeature spezialisiert ist. Ein CSP ist eine Komponente, die an den Windows MDM-Client angeschlossen wird und ein veröffentlichtes Protokoll bereitstellt, mit dem MDM-Server Einstellungen konfigurieren und Windows-basierte Geräte verwalten können. Das Verwaltungsprotokoll wird als Struktur dargestellt, die als URIs mit Funktionen angegeben werden kann, die für die URIs wie "get", "set", "delete" usw. ausgeführt werden sollen.

Die folgende Liste enthält die Funktionen, die vom Windows-Integritätsnachweis-CSP ausgeführt werden:

• Erfasst Daten, die zum Überprüfen des Integritätsstatus eines Geräts verwendet werden
• Leitet die Daten an den Integritätsnachweisdienst weiter.
• Stellt das Integritätsnachweiszertifikat bereit, das es vom Integritätsnachweisdienst erhält
• Leitet auf Anforderung das Integritätsnachweiszertifikat (vom Integritätsnachweisdienst empfangen) und die zugehörigen Laufzeitinformationen zur Überprüfung an den MDM-Server weiter.

Während einer Integritätsnachweissitzung leitet der Integritätsnachweis-CSP die TCG-Protokolle und PCRs-Werte, die während des Starts gemessen werden, mithilfe eines sicheren Kommunikationskanals an den Integritätsnachweisdienst weiter.

Wenn ein MDM-Server überprüft, ob ein Gerät dem Integritätsnachweisdienst bestätigt wurde, erhält er eine Reihe von Anweisungen und Ansprüchen über den Start des Geräts mit der Sicherheit, dass das Gerät zwischen dem Zeitpunkt, zu dem es seine Integrität bestätigt hat, und dem Zeitpunkt, zu dem es vom MDM-Server überprüft wurde, nicht neu gestartet wurde.

Windows-Integritätsnachweisdienst

Die Rolle des Windows-Integritätsnachweisdiensts besteht im Wesentlichen darin, eine Reihe von Integritätsdaten (TCG-Protokoll und PCR-Werte) auszuwerten, eine Reihe von Erkennungen (basierend auf verfügbaren Integritätsdaten) durchzuführen und verschlüsselte Integritätsblobs zu generieren oder Berichte für MDM-Server zu erstellen.

Die Überprüfung, ob ein TPM-Nachweis und das zugehörige Protokoll gültig sind, führt mehrere Schritte aus:

1. Zunächst muss der Server überprüfen, ob die Berichte von vertrauenswürdigen KIKs signiert sind. Diese Überprüfung kann durchgeführt werden, indem überprüft wird, ob der öffentliche Teil des AIK in einer Datenbank mit Ressourcen aufgeführt ist, oder vielleicht, ob ein Zertifikat überprüft wurde.
2. Nachdem der Schlüssel überprüft wurde, sollte der signierte Nachweis (eine Anführungszeichenstruktur) überprüft werden, um festzustellen, ob es sich um eine gültige Signatur über PCR-Werte handelt.
3. Als Nächstes sollten die Protokolle überprüft werden, um sicherzustellen, dass sie mit den gemeldeten PCR-Werten übereinstimmen.
4. Schließlich sollten die Protokolle selbst von einer MDM-Lösung untersucht werden, um festzustellen, ob sie bekannte oder gültige Sicherheitskonfigurationen darstellen. Eine einfache Überprüfung könnte beispielsweise darin bestehen, festzustellen, ob die gemessenen frühen Betriebssystemkomponenten als gut bekannt sind, ob der ELAM-Treiber erwartungsgemäß ist und ob die ELAM-Treiberrichtliniendatei auf dem neuesten Stand ist. Wenn alle diese Überprüfungen erfolgreich sind, kann eine Nachweiserklärung ausgestellt werden, die später verwendet werden kann, um zu bestimmen, ob dem Client Zugriff auf eine Ressource gewährt werden soll.

Der Integritätsnachweisdienst stellt einer MDM-Lösung die folgenden Informationen zur Integrität des Geräts zur Verfügung:

• Aktivierung des sicheren Starts
• Start- und Kerneldebugaktivierung
• BitLocker-Aktivierung
• VSM aktiviert
• Messung der Device Guard-Codeintegritätsrichtlinie mit oder ohne Vorzeichen
• ELAM geladen
• Start im abgesicherten Modus, DEP-Aktivierung, Aktivierung der Testsignatur
• Geräte-TPM wurde mit einem vertrauenswürdigen Bestätigungszertifikat bereitgestellt

Informationen zur Vollständigkeit der Messungen finden Sie unter Integritätsnachweis-CSP.

Die folgende Liste enthält einige wichtige Elemente, die an MDM für Windows-basierte Geräte zurückgegeben werden können:

• PCR0-Messung
• Sicherer Start aktiviert
• Sichere Start-Db-Übereinstimmungen erwartet
• Sicherer Start dbx ist auf dem neuesten Stand
• GUID der Richtlinie für den sicheren Start entspricht erwartet
• BitLocker aktiviert
• Virtualisierungsbasierte Sicherheit aktiviert
• ELAM wurde geladen
• Codeintegritätsversion ist auf dem neuesten Stand
• Hash-Übereinstimmungen der Codeintegritätsrichtlinie erwartet

Verwenden von MDM und dem Integritätsnachweisdienst

Um die Geräteintegrität relevant zu machen, wertet die MDM-Lösung den Geräteintegritätsbericht aus und ist entsprechend den Geräteintegritätsanforderungen der Organisation konfiguriert.

Eine Lösung, die MDM und den Integritätsnachweisdienst verwendet, besteht aus drei Hauptteilen:

1. Ein Gerät mit aktiviertem Integritätsnachweis. Diese Aktivierung erfolgt im Rahmen der Registrierung bei einem MDM-Anbieter (Der Integritätsnachweis wird standardmäßig deaktiviert).

2. Nach der Aktivierung dieses Diensts und bei jedem anschließenden Start sendet das Gerät Integritätsmessungen an den von Microsoft gehosteten Integritätsnachweisdienst und erhält im Gegenzug ein Blob für den Integritätsnachweis.

3. Nach diesem Zyklus kann ein MDM-Server jederzeit das Integritätsnachweisblob vom Gerät anfordern und den Integritätsnachweisdienst auffordern, den Inhalt zu entschlüsseln und zu überprüfen, ob er bestätigt wurde.

   

Die Interaktion zwischen einem Windows-basierten Gerät, dem Integritätsnachweisdienst und MDM kann wie folgt ausgeführt werden:

1. Der Client initiiert eine Sitzung mit dem MDM-Server. Der URI für den MDM-Server wäre Teil der Client-App, die die Anforderung initiiert. Der MDM-Server kann derzeit die Integritätsnachweisdaten mithilfe des entsprechenden CSP-URI anfordern.

2. Der MDM-Server gibt eine Nonce zusammen mit der Anforderung an.

3. Der Client sendet dann die AIK-Nonce in Anführungszeichen , den Startindikator und die Integritätsblobinformationen. Dieses Integritätsblob wird mit einem öffentlichen Schlüssel des Integritätsnachweisdiensts verschlüsselt, den nur der Integritätsnachweisdienst entschlüsseln kann.

4. Der MDM-Server:

   1. Überprüft, ob die Nonce erwartungsgemäß ist.
   2. Übergibt die Daten in Anführungszeichen, die Nonce und das verschlüsselte Integritätsblob an den Integritätsnachweisdienstserver.

5. Der Integritätsnachweisdienst:

   1. Entschlüsselt das Integritätsblob.
   2. Überprüft mithilfe des AIK im Integritätsblob, ob der Startzähler im Anführungszeichen korrekt ist und mit dem Wert im Integritätsblob übereinstimmt.
   3. Überprüft, ob die Nonce mit dem Zitat übereinstimmt, das von MDM übergeben wird.
   4. Da der Startindikator und die Nonce mit dem AIK aus dem Integritätsblob in Anführungszeichen stehen, beweist dies auch, dass das Gerät mit dem Gerät identisch ist, für das das Integritätsblob generiert wurde.
   5. Sendet Daten zurück an den MDM-Server, einschließlich Integritätsparametern, Aktualität usw.

Das Festlegen der Anforderungen für die Gerätekonformität ist der erste Schritt, um sicherzustellen, dass registrierte Geräte, die die Integritäts- und Complianceanforderungen nicht erfüllen, erkannt, nachverfolgt und aktionen von der MDM-Lösung erzwungen werden.

Bei Geräten, die versuchen, eine Verbindung mit Ressourcen herzustellen, muss deren Integrität ausgewertet werden, damit fehlerhafte und nicht kompatible Geräte erkannt und gemeldet werden können. Um vollständig effizient zu sein, muss eine End-to-End-Sicherheitslösung eine Folge für fehlerhafte Geräte wie die Verweigerung des Zugriffs auf hochwertige Ressourcen erzwingen. Diese Folge für ein fehlerhaftes Gerät ist der Zweck der bedingten Zugriffssteuerung, die im nächsten Abschnitt erläutert wird.

Steuern der Sicherheit eines Windows-basierten Geräts, bevor der Zugriff gewährt wird

Die heutige Zugriffssteuerungstechnologie konzentriert sich in den meisten Fällen darauf, sicherzustellen, dass die richtigen Personen Zugriff auf die richtigen Ressourcen erhalten. Wenn Benutzer sich authentifizieren können, erhalten sie Zugriff auf Ressourcen über ein Gerät, über das die IT-Mitarbeiter und Systeme der Organisation wenig wissen. Vielleicht gibt es eine Überprüfung, z. B. sicherzustellen, dass ein Gerät verschlüsselt ist, bevor Sie Zugriff auf E-Mails gewähren, aber was ist, wenn das Gerät mit Schadsoftware infiziert ist?

Der Integritätsnachweis für Remotegeräte verwendet gemessene Startdaten, um den Integritätsstatus des Geräts zu überprüfen. Die Integrität des Geräts ist dann für eine MDM-Lösung wie Intune verfügbar.

Die folgende Abbildung zeigt, wie der Integritätsnachweisdienst voraussichtlich mit dem cloudbasierten Intune-MDM-Dienst von Microsoft funktioniert.

Eine MDM-Lösung kann dann Integritätszustandsanweisungen verwenden und diese auf die nächste Ebene bringen, indem sie mit Clientrichtlinien koppelt, die es ermöglichen, bedingten Zugriff basierend auf der Fähigkeit des Geräts zu gewähren, nachzuweisen, dass es frei von Schadsoftware ist, dass das Antischadsoftwaresystem funktionsfähig und aktuell ist, die Firewall ausgeführt wird und der Patchstatus des Geräts kompatibel ist.

Schließlich können Ressourcen geschützt werden, indem der Zugriff auf Endpunkte verweigert wird, die nicht nachweisen können, dass sie fehlerfrei sind. Dieses Feature ist für BYOD-Geräte, die auf Organisationsressourcen zugreifen müssen, dringend erforderlich.

Integrierte Unterstützung von MDM in Windows

Windows verfügt über einen MDM-Client, der als Teil des Betriebssystems ausgeliefert wird. Dieser MDM-Client ermöglicht ES MDM-Servern, Windows-basierte Geräte zu verwalten, ohne dass ein separater Agent erforderlich ist.

Nicht-Microsoft MDM-Serverunterstützung

Nicht-Microsoft-MDM-Server können Windows mithilfe des MDM-Protokolls verwalten. Der integrierte Verwaltungsclient kann mit einem kompatiblen Server kommunizieren, der das OMA-DM-Protokoll unterstützt, um Unternehmensverwaltungsaufgaben auszuführen. Weitere Informationen finden Sie unter Microsoft Entra-Integration mit MDM.

Der MDM-Server eines Drittanbieters verfügt über die gleiche konsistente Erstanbieter-Benutzeroberfläche für die Registrierung, was auch für Windows-Benutzer eine Einfachheit bietet.

Verwaltung von Windows Defender durch Drittanbieter-MDM

Diese Verwaltungsinfrastruktur ermöglicht es IT-Experten, MDM-fähige Produkte wie Intune zu verwenden, um Integritätsnachweise, Device Guard oder Windows Defender auf Windows-basierten Geräten zu verwalten, einschließlich BYODs, die nicht in die Domäne eingebunden sind. IT-Experten können alle Aktionen und Einstellungen verwalten und konfigurieren, mit denen sie mit der Anpassung vertraut sind, indem sie Intune mit Intune Endpoint Protection auf heruntergefahrenen Betriebssystemen verwenden. Administratoren, die derzeit nur in die Domäne eingebundene Geräte über Gruppenrichtlinien verwalten, können leicht zur Verwaltung von Windows-basierten Geräten mithilfe von MDM wechseln, da viele der Einstellungen und Aktionen in beiden Mechanismen gemeinsam genutzt werden.

Weitere Informationen zum Verwalten von Windows-Sicherheits- und -Systemeinstellungen mit einer MDM-Lösung finden Sie unter Benutzerdefinierte URI-Einstellungen für Windows-Geräte.

Steuerung des bedingten Zugriffs

Auf den meisten Plattformen erfolgt die Microsoft Entra-Geräteregistrierung automatisch während der Registrierung. Die Gerätezustände werden von der MDM-Lösung in die Microsoft Entra-ID geschrieben und dann von Office 365 (oder von einer beliebigen autorisierten Windows-App, die mit Microsoft Entra ID interagiert) gelesen, wenn der Client das nächste Mal versucht, auf eine Office 365-kompatible Workload zuzugreifen.

Wenn das Gerät nicht registriert ist, erhält der Benutzer eine Meldung mit Anweisungen zum Registrieren (auch als Registrieren bezeichnet). Wenn das Gerät nicht konform ist, erhält der Benutzer eine andere Meldung, die ihn an das MDM-Webportal umleitet, wo er weitere Informationen zum Complianceproblem und dessen Behebung erhalten kann.

Microsoft Entra ID authentifiziert den Benutzer und das Gerät, MDM verwaltet die Richtlinien für Compliance und bedingten Zugriff, und der Integritätsnachweisdienst meldet die Integrität des Geräts auf nachgewiesene Weise.

Office 365-Steuerung für bedingten Zugriff

Microsoft Entra ID erzwingt Richtlinien für bedingten Zugriff, um den Zugriff auf Office 365-Dienste zu sichern. Ein Mandantenadministrator kann eine Richtlinie für bedingten Zugriff erstellen, die einen Benutzer auf einem nicht konformen Gerät am Zugriff auf einen Office 365-Dienst hindert. Der Benutzer muss den Geräterichtlinien des Unternehmens entsprechen, bevor der Zugriff auf den Dienst gewährt werden kann. Alternativ kann der Administrator auch eine Richtlinie erstellen, die erfordert, dass Benutzer nur ihre Geräte registrieren, um Zugriff auf einen Office 365-Dienst zu erhalten. Richtlinien können auf alle Benutzer einer Organisation oder auf einige wenige Zielgruppen beschränkt und im Laufe der Zeit erweitert werden, um mehr Zielgruppen einzubeziehen.

Wenn ein Benutzer zugriff auf einen Office 365-Dienst von einer unterstützten Geräteplattform anfordert, authentifiziert Microsoft Entra den Benutzer und das Gerät, von dem aus der Benutzer die Anforderung startet. und gewährt nur Zugriff auf den Dienst, wenn der Benutzer die für den Dienst festgelegte Richtlinie erfüllt. Benutzer, die ihr Gerät nicht registriert haben, erhalten Anleitungen zur Behebung, wie sie sich registrieren und für den Zugriff auf Office 365-Unternehmensdienste konform werden.

Wenn sich ein Benutzer registriert, wird das Gerät mit der Microsoft Entra-ID registriert und mit einer kompatiblen MDM-Lösung wie Intune registriert.

Wenn ein Benutzer ein Gerät erfolgreich registriert, wird das Gerät vertrauenswürdig. Microsoft Entra ID bietet einmaliges Anmelden für den Zugriff auf Unternehmensanwendungen und erzwingt eine Richtlinie für bedingten Zugriff, um zugriff auf einen Dienst zu gewähren, nicht nur bei der ersten Zugriffsanforderung des Benutzers, sondern jedes Mal, wenn der Benutzer die Verlängerung des Zugriffs anfordert.

Dem Benutzer wird der Zugriff auf Dienste verweigert, wenn Anmeldeinformationen geändert werden, ein Gerät verloren geht/gestohlen wird oder die Konformitätsrichtlinie zum Zeitpunkt der Verlängerungsanforderung nicht erfüllt wird.

Je nach Art der E-Mail-Anwendung, die Mitarbeiter für den Zugriff auf Exchange Online verwenden, kann der Pfad zum Einrichten des sicheren Zugriffs auf E-Mails geringfügig abweichen. Die wichtigsten Komponenten: Microsoft Entra ID, Office 365/Exchange Online und Intune sind jedoch identisch. Die IT-Erfahrung und die Endbenutzererfahrung sind ebenfalls ähnlich.

Clients, die versuchen, auf Office 365 zuzugreifen, werden auf die folgenden Eigenschaften ausgewertet:

• Wird das Gerät von einer MDM verwaltet?
• Ist das Gerät mit der Microsoft Entra-ID registriert?
• Ist das Gerät kompatibel?

Um in einen konformen Zustand zu gelangen, muss das Windows-basierte Gerät Folgendes ausführen:

• Registrieren mit einer MDM-Lösung.
• Registrieren Sie sich mit der Microsoft Entra-ID.
• Konformität mit den Geräterichtlinien, die von der MDM-Lösung festgelegt werden.

Bedingte Zugriffssteuerung für Cloud- und lokale Apps

Die Steuerung des bedingten Zugriffs ist eine leistungsstarke Engine für die Richtlinienauswertung, die in Microsoft Entra ID integriert ist. It-Spezialisten erhalten eine einfache Möglichkeit, Zugriffsregeln über Office 365 hinaus zu erstellen, die den Kontext der Anmeldung eines Benutzers auswerten, um in Echtzeit Entscheidungen darüber zu treffen, auf welche Anwendungen er zugreifen darf.

IT-Experten können Richtlinien für die bedingte Zugriffssteuerung für Cloud-SaaS-Anwendungen konfigurieren, die durch Microsoft Entra ID geschützt sind, und sogar für lokale Anwendungen. Zugriffsregeln in Microsoft Entra ID verwenden die Engine für bedingten Zugriff, um die Geräteintegrität und den Konformitätsstatus zu überprüfen, die von einer kompatiblen MDM-Lösung wie Intune gemeldet werden, um zu bestimmen, ob der Zugriff zugelassen werden soll.

Weitere Informationen zum bedingten Zugriff finden Sie unter Azure Conditional Access Preview for SaaS Apps (Vorschauversion des bedingten Zugriffs für SaaS-Apps).

Für lokale Anwendungen gibt es zwei Optionen, um die bedingte Zugriffssteuerung basierend auf dem Konformitätszustand eines Geräts zu aktivieren:

• Für lokale Anwendungen, die über den Microsoft Entra-Anwendungsproxy veröffentlicht werden, können Sie Richtlinien für die bedingte Zugriffssteuerung wie für Cloudanwendungen konfigurieren. Weitere Informationen finden Sie unter Verwenden des Microsoft Entra-Anwendungsproxys zum Veröffentlichen lokaler Apps für Remotebenutzer.
• Darüber hinaus synchronisiert Microsoft Entra Connect Gerätekonformitätsinformationen von Microsoft Entra ID mit lokalem AD. AD FS unter Windows Server 2016 unterstützt die bedingte Zugriffssteuerung basierend auf dem Konformitätszustand eines Geräts. IT-Experten konfigurieren Richtlinien für die bedingte Zugriffssteuerung in AD FS, die den von einer kompatiblen MDM-Lösung gemeldeten Konformitätszustand des Geräts verwenden, um lokale Anwendungen zu schützen.

Der folgende Prozess beschreibt die Funktionsweise des bedingten Microsoft Entra-Zugriffs:

1. Der Benutzer hat sich bereits über Workplace Access/Azure AD join bei MDM registriert, wodurch das Gerät mit microsoft Entra ID registriert wird.
2. Wenn das Gerät gestartet oder aus dem Ruhezustand fortgesetzt wird, wird die Aufgabe "Tpm-HASCertRetr" ausgelöst, um im Hintergrund ein Integritätsnachweisblob anzufordern. Das Gerät sendet TPM-Startmessungen an den Integritätsnachweisdienst.
3. Der Integritätsnachweisdienst überprüft den Gerätestatus und gibt ein verschlüsseltes Blob auf dem Gerät basierend auf dem Integritätszustand mit Details zu fehlgeschlagenen Überprüfungen (falls vorhanden) aus.
4. Der Benutzer meldet sich an, und der MDM-Agent kontaktiert den Intune/MDM-Server.
5. Der MDM-Server pusht neue Richtlinien, falls verfügbar, und fragt den Integritätsblobstatus und anderen Bestandsstatus ab.
6. Das Gerät sendet ein zuvor abgerufenes Integritätsnachweisblob sowie den Wert des anderen Zustandsbestands, der vom Intune-/MDM-Server angefordert wurde.
7. Der Intune-/MDM-Server sendet das Integritätsnachweisblob zur Überprüfung an den Integritätsnachweisdienst.
8. Der Integritätsnachweisdienst überprüft, ob das Gerät, das das Integritätsnachweisblob gesendet hat, fehlerfrei ist, und gibt dieses Ergebnis an den Intune-/MDM-Server zurück.
9. Der Intune/MDM-Server wertet die Konformität basierend auf der Konformität und dem abgefragten Bestands-/Integritätsnachweisstatus des Geräts aus.
10. Der Intune-/MDM-Server aktualisiert den Konformitätsstatus für das Geräteobjekt in der Microsoft Entra-ID.
11. Der Benutzer öffnet die App und versucht, auf ein unternehmensverwaltetes Medienobjekt zuzugreifen.
12. Zugriff durch Complianceanspruch in Microsoft Entra ID abgegrenzt.
13. Wenn das Gerät konform ist und der Benutzer autorisiert ist, wird ein Zugriffstoken generiert.
14. Der Benutzer kann auf die unternehmensseitig verwaltete Ressource zugreifen.

Weitere Informationen zur Microsoft Entra-Einbindung finden Sie unter Microsoft Entra ID & Windows: Better Together for Work or School, ein Whitepaper.

Die Steuerung des bedingten Zugriffs ist ein Thema, das viele Organisationen und IT-Experten möglicherweise nicht kennen und sollten. Die verschiedenen Attribute, die einen Benutzer, ein Gerät, die Konformität und den Zugriffskontext beschreiben, sind bei verwendung mit einer Engine für bedingten Zugriff leistungsstark. Die Steuerung des bedingten Zugriffs ist ein wesentlicher Schritt, der Organisationen dabei hilft, ihre Umgebung zu schützen.

Erkenntnisse und Zusammenfassung

Die folgende Liste enthält allgemeine wichtige Erkenntnisse zur Verbesserung des Sicherheitsstatus jeder Organisation. Die wenigen in diesem Abschnitt vorgestellten Erkenntnisse sollten jedoch nicht als eine vollständige Liste bewährter Sicherheitsmethoden interpretiert werden.

• Verstehen, dass keine Lösung zu 100 Prozent sicher ist

  Wenn ermittelte Angreifer mit böswilligen Absichten physischen Zugriff auf das Gerät erhalten, könnten sie schließlich seine Sicherheitsebenen durchbrechen und es kontrollieren.

• Verwenden des Integritätsnachweises mit einer MDM-Lösung

  Bei Geräten, die versuchen, eine Verbindung mit hochwertigen Ressourcen herzustellen, muss deren Integrität ausgewertet werden, damit fehlerhafte und nicht kompatible Geräte erkannt, gemeldet und schließlich blockiert werden können.

• Verwenden von Credential Guard

  Credential Guard ist ein Feature, das die Anmeldeinformationen der Unternehmensdomäne erheblich vor Pass-the-Hash-Angriffen schützt.

• Device Guard verwenden

  Device Guard ist ein echter Sicherheitsvorschuss und eine effektive Möglichkeit zum Schutz vor Schadsoftware. Das Device Guard-Feature in Windows blockiert nicht vertrauenswürdige Apps (Apps, die nicht von Ihrer Organisation autorisiert wurden).

• Signieren der Device Guard-Richtlinie

  Die signierte Device Guard-Richtlinie schützt vor Einem Benutzer mit Administratorrechten, der versucht, die aktuelle Richtlinie zu besiegen. Wenn eine Richtlinie signiert ist, besteht die einzige Möglichkeit zum späteren Ändern von Device Guard darin, eine neue Version der Richtlinie bereitzustellen, die vom gleichen Signierer signiert oder von einem Signaturgeber signiert wird, der als Teil der Device Guard-Richtlinie angegeben ist.

• Verwenden der virtualisierungsbasierten Sicherheit

  Wenn Die Codeintegrität im Kernelmodus durch virtualisierungsbasierte Sicherheit geschützt ist, werden die Codeintegritätsregeln auch dann erzwungen, wenn ein Sicherheitsrisiko nicht autorisierten Speicherzugriff im Kernelmodus zulässt. Beachten Sie, dass Device Guard-Geräte, die Kernelcodeintegrität mit virtualisierungsbasierter Sicherheit ausführen, über kompatible Treiber verfügen müssen.

• Starten der Bereitstellung von Device Guard im Überwachungsmodus

  Stellen Sie die Device Guard-Richtlinie auf Zielcomputern und Geräten im Überwachungsmodus bereit. Überwachen Sie das Codeintegritätsereignisprotokoll, das angibt, dass ein Programm oder ein Treiber blockiert worden wäre, wenn Device Guard im Erzwingungsmodus konfiguriert wurde. Passen Sie Device Guard-Regeln an, bis ein hohes Maß an Zuverlässigkeit erreicht wurde. Nach Abschluss der Testphase kann die Device Guard-Richtlinie in den Erzwingungsmodus umgeschaltet werden.

• Erstellen eines isolierten Referenzcomputers bei der Bereitstellung von Device Guard

  Da das Unternehmensnetzwerk Schadsoftware enthalten kann, sollten Sie mit der Konfiguration einer Referenzumgebung beginnen, die von Ihrem Hauptnetzwerk isoliert ist. Danach können Sie eine Codeintegritätsrichtlinie erstellen, die die vertrauenswürdigen Anwendungen enthält, die Sie auf Ihren geschützten Geräten ausführen möchten.

• Verwenden von AppLocker, wenn es sinnvoll ist

  Obwohl AppLocker nicht als neues Device Guard-Feature angesehen wird, ergänzt es die Device Guard-Funktionalität für einige Szenarien wie die Möglichkeit, eine bestimmte universelle Windows-Anwendung für einen bestimmten Benutzer oder eine Gruppe von Benutzern zu verweigern.

• Firmware und Konfiguration sperren

  Nachdem Windows installiert wurde, sperren Sie den Zugriff auf Die Firmware-Startoptionen. Diese Sperrung verhindert, dass ein Benutzer mit physischem Zugriff UEFI-Einstellungen ändert, den sicheren Start deaktiviert oder andere Betriebssysteme startet. Um sich vor einem Administrator zu schützen, der versucht, Device Guard zu deaktivieren, fügen Sie außerdem in der aktuellen Device Guard-Richtlinie eine Regel hinzu, die die Ausführung des Tools C:\Windows\System32\SecConfig.efi verweigert und blockiert.

Der Integritätsnachweis ist ein wichtiges Feature von Windows, das Client- und Cloudkomponenten umfasst, um den Zugriff auf hochwertige Ressourcen basierend auf einem Benutzer und der Identität seines Geräts und der Einhaltung der Corporate Governance-Richtlinie zu steuern. Organisationen können wählen, ob fehlerhafte Geräte erkannt und gemeldet werden sollen, oder ob Sie Integritätserzwingungsregeln basierend auf ihren Anforderungen konfigurieren möchten. Der Integritätsnachweis bietet ein End-to-End-Sicherheitsmodell und Integrationspunkte, mit denen Anbieter und Softwareentwickler eine angepasste Lösung erstellen und integrieren können.

Verwandte Artikel

• Schützen abgeleiteter Domänenanmeldeinformationen mit Credential Guard
• Device Guard-Bereitstellungshandbuch
• Übersicht über die Technologie des Trusted Platform Module