Kontrollieren der Integrität Windows 10-basierter Geräte

Dieser Artikel beschreibt eine End-to-End-Lösung zum Schutz hochwertiger Ressourcen, die die Integrität von Windows 10-basierten Geräten erzwingt, überwacht und meldet.

Einführung

In Bring Your Own Device (BYOD)-Szenarien bringen Mitarbeiter handelsübliche Geräte mit, um sowohl auf arbeitsbezogene Ressourcen als auch auf persönliche Daten zuzugreifen. Für den Zugriff auf Anwendungen, Daten und Ressourcen des Unternehmens möchten die Benutzer ein Gerät ihrer Wahl einsetzen und neben dem internen Netzwerk auch von überall Zugriff erhalten. Dieses Phänomen wird auch als „Konsumerisierung“ der IT bezeichnet.

Wenn Benutzer von ihren Geräten auf Unternehmensanwendungen zugreifen und mit geschäftlichen Daten arbeiten möchten, kommt es ihnen auf höchste Produktivität an. Es kommt für sie nicht in Frage, bei jedem Zugriff auf eine Anwendung oder einen Dateiserver Anmeldeinformationen für ihr Geschäftskonto eingeben zu müssen. Im Hinblick auf die Sicherheit muss befürchtet werden, dass Unternehmensanmeldeinformationen und -daten auf nicht verwalteten Geräten manipuliert werden.

Mit der Verbreitung von BYOD wird auch die Zahl der nicht verwalteten und potenziell sicherheitsgefährdenden Systeme zunehmen, über die der Zugriff auf Unternehmensdienste, interne Ressourcen und Cloud-Apps erfolgt.

Sogar verwaltete Geräte sind manipulierbar und können zu einer Gefahr werden. Unternehmen müssen in der Lage sein, Sicherheitsverletzungen zu erkennen und zum frühstmöglichen Zeitpunkt dagegen vorzugehen, um ihre hochwertigen Ressourcen zu schützen.

Bei Neuentwicklungen investiert Microsoft beträchtliche Summen in die Sicherheit, insbesondere präventive Abwehrmechanismen sowie Erkennungs- und Abhilfemaßnahmen.

Windows 10 ist eine wichtige Komponente einer End-to-End-Sicherheitslösung, die neben der Implementierung präventiver Sicherheitsmaßnahmen auch das Ziel hat, Nachweise der Geräteintegrität in der gesamten Sicherheitsstrategie durchzusetzen.

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

Bedrohungen für Computingumgebungen breiten sich heute so schnell aus wie nie zuvor. Kriminelle Angriffe werden immer intelligenter ausgeführt und Schadsoftware stellt branchenübergreifend eine Bedrohung für private Verbraucher und professionelle Anwender dar.

In den vergangenen Jahren hat besonders die Bedrohung durch APTs (Advanced Persistent Threat, Fortgeschrittene andauernde Bedrohung) erheblich zugenommen. Der Begriff „APT“ beschreibt allgemein Angriffe, die scheinbar auf bestimmte einzelne Unternehmen gerichtet sind und über einen längeren Zeitraum stattfinden. Diese Art von Übergriffen geht tatsächlich gezielt von Angreifern aus, die sich verschiedener Methoden oder Verfahren bedienen.

Vor dem Hintergrund von BYOD stellen unzureichend verwaltete Geräte ein leichtes Ziel dar. Angreifer haben es leicht, die Sicherheit des Umkreisnetzwerks zu umgehen, Zugriff auf das Netzwerk zu erlangen und hochwertige Ressourcen zu stehlen.

Die Angreifer haben Einzelpersonen im Visier, nicht um ihnen persönlich zu schaden, sondern um über sie an Unternehmensdaten zu gelangen. Ein infiziertes Gerät ist eine Schwachstelle, durch die Schadsoftware in ein Unternehmen eingeschleust wird, auch wenn das Umkreisnetzwerk abgesichert oder Abwehrmaßnahmen implementiert wurden. Eine Abwehrstrategie reicht zur Bekämpfung dieser Bedrohungen jedoch nicht aus.

Ein alternativer Ansatz

Im Unterschied zur traditionellen Präventivlösung geht eine effektive Sicherheitsstrategie heute davon aus, dass entschlossene Angreifer jede Abwehrstrategie austricksen können. Dies lässt nur einen Schluss zu: den Umstieg von präventiven Sicherheitskontrollen auf ein Sicherheitsmodell mit dem Fokus auf Erkennung und Reaktion. Bei der Umsetzung der Risikomanagementstrategie muss deshalb in Prävention, Erkennung und Reaktion gleichermaßen investiert werden.

Da der Zugriff auf Unternehmensinformationen zunehmend über mobile Geräte erfolgt, bedarf es einer Methodik zur Auswertung der Gerätesicherheit und -integrität. In diesem Abschnitt wird beschrieben, wie sich die Bewertung der Geräteintegrität bereitstellen lässt, um hochwertige Ressourcen vor Gefahren durch infizierte Geräte zu schützen.

Der Zugriff auf Unternehmensressourcen muss in jedem Fall über vertrauenswürdige Geräte erfolgen. Eine effiziente End-to-End-Sicherheitslösung muss in der Lage sein, die Geräteintegrität festzustellen und den Zugriff auf hochwertige Ressourcen auf Grundlage des aktuellen Sicherheitszustands zu erteilen.

Ein zuverlässiges Konzept muss folgende Anforderungen erfüllen: Nachweis der Benutzeridentität, Verstärken der Authentifizierungsmethode (falls erforderlich) und Erlernen von Verhaltensmustern, z. B. die Netzwerkadresse, über die der Benutzer regelmäßig eine Verbindung herstellt. Darüber hinaus muss eine innovative Lösung in der Lage sein, vertrauliche Inhalte nur preiszugeben, nachdem die Integrität und Sicherheit der Benutzergeräte nachgewiesen wurde.

Die folgende Abbildung zeigt eine Lösung, die die Geräteintegrität aus der Cloud bewertet. Das Gerät authentifiziert den Benutzer über eine Verbindung mit einem Identitätsanbieter in der Cloud. Wenn die verwaltete Ressource streng vertrauliche Daten enthält, kann das Modul für bedingten Zugriff des Identitätsanbieters wahlweise überprüfen, ob die Sicherheitskonformität des mobilen Geräts vor dem Erteilen des Zugriffs geprüft wird. Das Benutzergerät kann den Integritätsstatus bestätigen, der zu einem beliebigen Zeitpunkt oder auf Anforderung der mobilen Geräteverwaltung (Mobile Device Management, MDM) gesendet werden kann.

Windows-Geräte können mithilfe von Low-Level-Rootkits und -Bootkits geschützt werden, wobei Low-Level-Hardwaretechnologien wie „Sicherer Start“ gemäß UEFI (Unified Extensible Firmware Interface) zum Einsatz kommen.

„Sicherer Start“ ist ein Firmwareüberprüfungsprozess, der Angriffe auf Rootkits verhindern hilft. Diese Technologie ist Teil der UEFI-Spezifikation. Der Zweck von UEFI ist das Festlegen einer Standardmethode für die Kommunikation zwischen Betriebssystem und moderner Hardware. Diese zeichnet sich durch höhere Leistung und effizientere E/A (Ein-/Ausgabe)-Funktionen als ältere, softwareinterruptfähige BIOS-Systeme aus.

Das Nachweismodul für die Geräteintegrität kann mit gemessenen Startdaten kommunizieren, die von einem TPM (Trusted Platform Module) für einen Remotedienst geschützt werden. Nachdem das Gerät erfolgreich gestartet wurde, werden Messdaten zum Startprozess über einen zuverlässigen und manipulationssicheren Kommunikationskanal an einen vertrauenswürdigen Clouddienst (Health Attestation Service) übermittelt.

Der Remote Health Attestation Service (HAS) führt eine Reihe von Überprüfungen anhand der Messdaten aus. Er prüft sicherheitsrelevante Datenpunkte einschließlich Startzustand (sicherer Start, Debugmodus usw.) und den Zustand von Sicherheitsmanagement-Komponenten (BitLocker, Device Guard usw.). Anschließend wird der Integritätszustand des Geräts über einen verschlüsselten Integritäts-BLOB an das Gerät zurückübermittelt.

Eine MDM-Lösung wendet normalerweise Konfigurationsrichtlinien an und stellt Software auf Geräten bereit. MDM definiert die Sicherheitsbaseline und ermittelt den Kompatibilitätsgrad des Geräts durch regelmäßige Überprüfungen der installierten Software und der erzwungenen Konfiguration sowie den Integritätsstatus des Geräts.

Eine MDM-Lösung weist das Gerät an, Geräteintegritätsinformationen zu senden und den verschlüsselten Integritäts-BLOB an den Remotedienst zum Integritätsnachweis weiterzuleiten. Der Remotedienst zum Integritätsnachweis überprüft die Geräteintegritätsdaten und stellt sicher, dass MDM mit demselben Gerät kommuniziert. Abschließend wird ein Geräteintegritätsbericht an die MDM-Lösung zurückgesendet.

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

Der Inhaltszugriff wird dann unter der Vertrauensebene autorisiert, die dem Integritätsstatus und anderen bedingten Elementen angemessen ist.

Je nach den Anforderungen und der Vertraulichkeit der verwalteten Ressource kann der Geräteintegritätsstatus bei der Verarbeitung der Zugriffsanforderung mit Benutzeridentitätsinformationen kombiniert werden. Der Inhaltszugriff wird dann unter der angemessenen Vertrauensebene autorisiert. Das Modul für bedingten Zugriff kann strukturiert ausgeführt werden, um bei Bedarf eine zusätzliche Überprüfung nach Vertraulichkeit der verwalteten Ressource zuzulassen. Wenn beispielsweise Zugriff auf hochwertige Daten angefordert wird, muss vor Erteilung des Zugriffs ggf. eine weitergehende Sicherheitsauthentifizierung stattfinden, etwa die Annahme eines Telefonanrufs durch den Benutzer.

Sicherheitsschwerpunkte von Microsoft für Windows 10

Unter Windows 10 gibt es drei verschiedene Sicherheitsschwerpunkte:

• Sichere Identitäten. Microsoft ist einer der Unterstützer der FIDO-Allianz, deren Ziel die Bereitstellung einer interoperablen Methode der sicheren Identifizierung ist. Dazu soll sowohl in lokalen Systemen als auch für lokal oder in der Cloud gehostete Dienste die kennwortlose Authentifizierung eingeführt werden.

• Schutz von Informationen. Microsoft setzt sich dafür ein, dass Organisationen eine bessere Kontrolle über den Zugriff auf wichtige Daten und deren Nutzung haben. Unter Windows 10 können Organisationen Richtlinien nutzen, die festlegen, welche Anwendungen ausdrücklich als Unternehmensanwendungen angesehen werden und den vertrauenswürdigen Zugriff auf Daten gewährleisten.

• Gefahrenschutz. Microsoft hilft Organisationen, ihre Unternehmensressourcen besser gegen Bedrohungen durch Schadsoftware und Angriffe zu schützen, indem es auf hardwarebasierte Sicherheitsmaßnahmen setzt.

Schutz, Kontrolle und Melden des Sicherheitsstatus von Windows 10-basierten Geräten

Dieser Abschnitt enthält eine Übersicht der verschiedenen Komponenten der End-to-End-Sicherheitslösung, die zum Schutz hochwertiger Ressourcen und Informationen vor Angreifern und Schadsoftware beiträgt.

Ziffer	Teil der Lösung	Beschreibung
1	Windows 10-basiertes Gerät	Beim ersten Einschalten eines Windows 10-basierten Geräts wird die Windows-Willkommensseite (Out-of-the-Box Experience, OOBE) angezeigt. Während des Setups kann das Gerät automatisch bei Azure Active Directory (AD) registriert und bei MDM angemeldet werden. Ein Windows 10-basiertes Gerät mit TPM 2.0 kann den Integritätsstatus jederzeit mithilfe des Integritätsnachweisdiensts (Health Attestation Service, HAS) melden, der in allen Windows 10-Editionen enthalten ist.
2	Identitätsanbieter	Azure AD enthält Benutzer, registrierte Geräte und die registrierte Anwendung des Mandanten der Organisation. Ein Gerät ist immer einem Benutzer zugeordnet, und ein Benutzer kann über mehrere Geräte verfügen. Ein Gerät wird als ein Objekt dargestellt, das verschiedene Attribute wie den Kompatibilitätsstatus des Geräts enthält. Der Kompatibilitätsstatus kann durch eine vertrauenswürdige MDM aktualisiert werden. Azure AD ist mehr als ein Repository. Azure AD ermöglicht zusätzlich die Authentifizierung von Benutzern und Geräten und kann den Zugriff auf verwaltete Ressourcen autorisieren. Azure AD verfügt über ein Modul zur Steuerung des bedingten Zugriffs, das die Identität des Benutzers, den Standort und Kompatibilitätsstatus des Geräts auswertet, um eine Entscheidung über vertrauenswürdigen Zugriff zu treffen.
3	Mobile Geräteverwaltung	Windows 10 verfügt über MDM-Unterstützung. Das bedeutet, dass die Verwaltung ohne Bereitstellung eines Agents von Anfang an möglich ist. MDM kann über Microsoft Intune oder eine mit Windows 10 kompatible MDM-Lösung eines Drittanbieters erfolgen.
4	Remoteintegritätsnachweis	Health Attestation Service (HAS) ist ein von Microsoft betriebener vertrauenswürdiger Clouddienst, der eine Reihe von Integritätsprüfungen durchführt und der MDM-Lösung meldet, welche Sicherheitsfeatures von Windows 10 auf dem Gerät aktiviert sind. Die Sicherheitsüberprüfung umfasst den Startstatus (WinPE, abgesicherter Modus, Debug-/Testmodi usw.) und Komponenten, die die Sicherheit und/oder Integrität der Laufzeitvorgänge (BitLocker, Device Guard) verwalten.
5	Unternehmensverwaltete Ressource	Eine unternehmensverwaltete Ressource ist die Ressource, die geschützt werden soll. Dabei kann es sich beispielsweise um Office 365, andere Cloud-Apps und lokale Webressource handeln, die von Azure AD veröffentlicht werden oder sogar per VPN-Zugriff zugänglich sind.

 

Die Kombination von Windows 10-basierten Geräten, Identitätsanbieter, MDM und Remoteintegritätsnachweis ergibt eine stabile End-to-End-Lösung, die die Integritäts- und Kompatibilitätsprüfung von Geräten sicherstellt, die auf hochwertige Ressourcen zugreifen.

Schutz von Geräten und Unternehmensanmeldeinformationen vor Bedrohungen

In diesem Abschnitt werden die Sicherheitsmaßnahmen von Windows 10 und die messbaren und berichtsfähigen Kontrollmechanismen beschrieben.

Hardwarebasierte Sicherheitsmaßnahmen von Windows 10

Die aggressivsten Formen von Schadsoftware versuchen, sich frühstmöglich in den Startprozess einzuschleusen, um frühzeitig die Kontrolle über das Betriebssystem zu übernehmen und zu verhindern, dass Schutzmechanismen und Antischadsoftware die Arbeit aufnehmen. Diese Art von schädlichem Code wird häufig als Rootkit oder Bootkit bezeichnet. Am einfachsten lässt sich Low-Level-Schadsoftware durch einen sicheren Startprozess vermeiden, damit das Gerät von Anfang an geschützt ist.

Windows 10 unterstützt mehrere Ebenen des Startschutzes. Einige dieser Features sind nur verfügbar, wenn bestimmte Hardwaretypen installiert sind. Weitere Informationen finden Sie im Abschnitt Hardwareanforderungen.

Windows 10 unterstützt Features, die verhindern, dass während des Startvorgangs anspruchsvolle Low-Level-Schadsoftware wie Rootkits und Bootkits geladen wird:

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

  Windows 10 nutzt Sicherheitseigenschaften eines TPM für die Messung der Startintegritätsequenz (basierend darauf werden Laufwerke mit BitLocker-Schutz automatisch entsperrt) zum Schutz von Anmeldeinformationen oder zum Integritätsnachweis.

  Ein TPM implementiert Steuerelemente, die den Spezifikationen der Trusted Computing Group (TCG) entsprechen. Zum Zeitpunkt der Erstellung dieses Dokuments sind zwei Versionen der TPM-Spezifikation von TCG vorhanden, die nicht miteinander kompatibel sind:

  • Die erste TPM-Spezifikation – Version 1.2 – wurde im Februar 2005 von der TCG im Standard ISO/IEC 11889 veröffentlicht.

  • Die aktuelle TPM-Spezifikation mit der Bezeichnung „TPM 2.0“ wurde im April 2014 veröffentlicht und vom Gemeinschaftskomitee (Joint Technical Committee, JTC) von ISO und IEC als „ISO/IEC 11889:2015“ genehmigt.

  Windows 10 verwendet das TPM für kryptografische Berechnungen im Rahmen des Integritätsnachweises und zum Schutz der Schlüssel für BitLocker, Microsoft Passport, virtuelle Smartcards und andere Zertifikate mit öffentlichem Schlüssel. Weitere Informationen finden Sie unter TPM-Anforderungen unter Windows 10.

  Windows 10 erkennt die Versionen 1.2 und 2.0 der vom TCG veröffentlichten TPM-Spezifikationen. Für die neuesten und modernen Sicherheitsfeatures unterstützt Windows 10 nur TPM 2.0. TPM 2.0 ist für den Nachweis über Geräteintegrität erforderlich.

  Für TPM 2.0 wurden die Funktionen von TPM 1.2 umfangreich überarbeitet:

  • Aktualisierung der Schlüsselstärke zur Erfüllung aktueller Sicherheitsanforderungen

    • Unterstützung von SHA-256 für PCRs

    • Unterstützung des HMAC-Befehls

  • Flexibilität kryptografischer Algorithmen zur Unterstützung der Anforderungen von Behörden

    • TPM 1.2 ist in Bezug auf die Unterstützung von Algorithmen stark eingeschränkt.

    • TPM 2.0 kann beliebige Algorithmen mit geringfügigen Updates der TCG-Spezifikationsdokumente unterstützen.

  • Implementierungsübergreifende Konsistenz

    • Die TPM 1.2-Spezifikation ermöglicht Herstellern bei der Auswahl von Implementierungsdetails eine hohe Flexibilität.

    • 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 Betriebssystem-Bootloader geladen werden. Der sichere Start erfordert kein TPM.

  Den grundlegenden Schutz bietet das Feature „Sicherer Start“, das ein standardmäßiger Bestandteil der UEFI 2.2+-Architektur ist. Auf einem PC mit herkömmlichen BIOS kann jeder, der den Startvorgang steuern kann, den Start mit einem alternativen Betriebssystem-Bootloader durchführen und potenziell Zugriff auf Systemressourcen erlangen. Wenn der sichere Start aktiviert ist, kann der Start nur mit einem Betriebssystem-Ladeprogramm erfolgen, das mit einem in der UEFI-Datenbank für den sicheren Start gespeicherten Zertifikat signiert ist. Natürlich befindet sich das Microsoft-Zertifikat zum Signieren der Betriebssystem-Ladeprogramme von Windows 10 in diesem Speicher; dadurch kann UEFI das Zertifikat als Teil der Sicherheitsrichtlinie überprüfen. Der sichere Start muss standardmäßig auf allen Computern aktiviert sein, die unter dem Windows-Hardwarekompatibilitätsprogramm für Windows 10 zertifiziert sind.

  Sicherer Start ist ein auf der UEFI-Firmware basierendes Feature und ermöglicht das Signieren und die Überprüfung kritischer Startdateien und Treiber zur Startzeit. Der sichere Start überprüft Signaturwerte des Windows-Start-Manager, des BCD-Speichers, der Ladeprogrammdatei des Windows-Betriebssystems und anderer für den Start erforderlicher DLLs zur Startzeit, bevor das System vollständig als verwendbares Betriebssystem gestartet werden kann. Dazu werden vom OEM zur Erstellungszeit definierte Richtlinien verwendet. Der sichere Start verhindert zahlreiche Arten von startbasierten Rootkit-, Schadsoftware- und anderen sicherheitsbezogenen Angriffen auf die Windows-Plattform. Der sichere Start schützt den Startvorgang des Betriebssystems unabhängig davon, ob dieser über die lokale Festplatte, USB, PXE oder DVD in eine vollständige Windows-Umgebung oder die Windows-Wiederherstellungsumgebung (Recovery Environment, RE) erfolgt.

  Der sichere Start schützt die Startumgebung einer Windows 10-Installation durch eine Überprüfung der Signaturen kritischer Startkomponenten, um sicherzustellen, dass diese nicht von bösartigen Aktivitäten beeinträchtigt werden. Der Schutz des sicheren Starts endet, nachdem die Windows-Kernel-Datei (ntoskrnl.exe) geladen wurde.

  Hinweis  

  Der sichere Start schützt die Plattform, bis der Windows-Kernel geladen ist. Anschließend übernehmen andere Schutzlösungen wie ELAM.

   

• Konfigurationsrichtlinie für „Sicherer Start“. Erweitert die Funktionen des sicheren Starts auf wichtige Windows 10-Konfigurationen.

  Beispiele für geschützte Konfigurationsinformationen umfassen das Schützen der Ausführungsverhinderung (NX-Option) und das Sicherstellen, dass die Testsignierungsrichtlinie (Codeintegrität) nicht aktiviert werden kann. Dadurch wird sichergestellt, dass die Binärdateien und die Konfiguration des Computers vertrauenswürdig sind, nachdem der Startvorgang abgeschlossen wurde.

  Die Konfigurationsrichtlinie für „Sicherer Start“ verwendet dazu die UEFI-Richtlinie. Die Signaturen für diese Richtlinien sind auf die gleiche Weise signiert, wie Binärdateien des Betriebssystems für die Verwendung mit dem sicheren Start signiert sind.

  Die Konfigurationsrichtlinie für „Sicherer Start“ muss mit einem privaten Schlüssel signiert sein, der einem der öffentlichen Schlüssel in der Liste Schlüsselaustauschschlüssel (Key Exchange Key, KEK) entspricht. Die Microsoft-Zertifizierungsstelle (Certificate Authority, CA) steht auf der KEK-Liste aller Windows-zertifizierten Systeme mit sicherem Start. In der Regel funktioniert eine von Microsoft KEK signierte Richtlinie auf allen Systemen mit sicherem Start. „BootMgr“ muss die Signatur anhand der KEK-Liste überprüfen, bevor eine signierte Richtlinie angewendet wird. Bei Windows 10 ist die Standardkonfigurationsrichtlinie für „Sicherer Start“ in „bootmgr“ integriert.

  Der Bootloader prüft die digitale Signatur des Windows 10-Kernels, bevor dieser geladen wird. Der Windows 10-Kernel überprüft wiederum alle anderen Komponenten des Windows-Startvorgangs, einschließlich der Starttreiber, der Startdateien und der ELAM-Komponente. Dieser Schritt ist wichtig, und schützt den Rest des Startvorgangs durch die Überprüfung, dass alle Windows-Startkomponenten Integrität aufweisen und vertrauenswürdig sind.

• 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 starten erst, nachdem die Starttreiber geladen wurden. Dadurch kann ein als Treiber maskiertes Rootkit zu wirken beginnen. ELAM ist ein Windows-Mechanismus, der in einer früheren Windows-Version eingeführt wurde und ein frühzeitiges Ausführen von Antischadsoftware in der Startsequenz ermöglicht. Daher ist die Antischadsoftware-Komponente die erste Drittanbieterkomponente, die ausgeführt wird und die Initialisierung von anderen Starttreibern steuern, bis das Windows-Betriebssystem betriebsbereit ist. Wenn das System mit einer vollständigen Laufzeitumgebung (Netzwerkzugriff, Speicher usw.) gestartet wird, wird eine vollwertige Antischadsoftware geladen.

  ELAM kann vor dem Laden von nicht von Microsoft stammenden Starttreibern und Anwendungen einen Antischadsoftware-Treiber von Microsoft oder einem Drittanbieter laden und so die durch „Sicherer Start“ und „Vertrauenswürdiger Start“ erstellte Vertrauenskette fortsetzen. Da das Betriebssystem noch nicht gestartet wurde, und da Windows so schnell wie möglich zu starten muss, hat ELAM eine einfache Aufgabe: alle Startgerätetreiber untersuchen und bestimmen, ob sie auf der Liste der vertrauenswürdigen Treiber stehen. Wenn er nicht als vertrauenswürdig eingestuft wird, lädt Windows ihn nicht.

  Hinweis  

  Windows Defender, die standardmäßig in Windows 10 enthaltene Antischadsoftware von Microsoft, unterstützt ELAM. Sie kann durch eine kompatible Antischadsoftware-Lösung eines Drittanbieters ersetzt werden. Der Name des ELAM-Treibers für Windows Defender ist „WdBoot.sys“. Windows Defender unter Windows 10 verwendet den ELAM-Treiber zum Zurücksetzen schädlicher Änderungen am Windows Defender-Treiber beim nächsten Neustart. Dadurch wird verhindert, dass Kernelmodus-Schadsoftware vor dem Herunterfahren oder dem Neustart dauerhafte Änderungen am Windows Defender-Minifiltertreiber vornimmt.

   

  Der signierte ELAM-Treiber wird vor allen anderen Drittanbietertreibern oder -anwendungen geladen. Dies ermöglicht der Antischadsoftware das Erkennen und Blockieren aller Versuche, den Startvorgang durch das Laden von nicht signiertem oder nicht vertrauenswürdigem Code zu manipulieren.

  Der ELAM-Treiber ist ein kleiner Treiber mit einer kleinen Richtliniendatenbank mit einem sehr schmalen Gültigkeitsbereich; er konzentriert sich Treiber, die beim Starten des Systems frühzeitig geladen werden. Die Richtliniendatenbank ist in einer Registrierungsstruktur gespeichert, die auch an das TPM angepasst wird, um die Betriebsparameter des ELAM-Treibers aufzuzeichnen. Ein ELAM-Treiber muss von Microsoft signiert sein, und das zugehörige Zertifikat muss die ergänzenden EKU (1.3.6.1.4.1.311.61.4.1) enthalten.

• Virtualisierungsbasierte Sicherheit (Hyper-V + sicherer Kernel). Virtualisierungsbasierte Sicherheit ist eine völlig neue erzwungene Sicherheitsbegrenzung, die Ihnen das Schützen wichtiger Teile von Windows 10 ermöglicht.

  Virtualisierungsbasierte Sicherheit isoliert sensiblen Code wie die Kernelmodus-Codeintegrität oder sensible Anmeldeinformationen für die Unternehmensdomäne vom Rest des Windows-Betriebssystems. Weitere Informationen finden Sie im Abschnitt Virtualisierungsbasierte Sicherheit.

• Hyper-V-Codeintegrität (HVCI). Hyper-V-Codeintegrität ist ein Feature von Device Guard, das gewährleistet, dass nur Treiber, ausführbare Dateien und DLLs ausgeführt werden dürfen, die der Codeintegritäts-Richtlinie von Device Guard entsprechen.

  Wenn sie aktiviert und konfiguriert sind, kann Windows 10 die virtualisierungsbasierten Hyper-V-Sicherheitsdienste einschließlich der Hyper-V-Codeintegrität (HVCI) starten. HVCI dient dem Schutz des Systemkerns (Kernel), der privilegierten Treiber und der Verteidigungseinrichtungen des Systems, z. B. Antischadsoftware, indem die Ausführung von Schadsoftware zu einem frühen Zeitpunkt des Startprozesses oder nach dem Start verhindert wird.

  HVCI nutzt virtualisierungsbasierte Sicherheit zum Isolieren von Codeintegrität; die einzige Möglichkeit zum Ausführen von Kernelspeicher ist über eine Überprüfung der Codeintegrität. Das bedeutet, dass Kernelspeicherseiten nie beschreibbar und ausführbar sein können, und ausführbarer Code kann nicht direkt geändert werden.

  Hinweis  

  Device Guard-Geräte, auf denen die Kernelmodus-Codeintegrität mit virtualisierungsbasierter Sicherheit ausgeführt wird, müssen über kompatible Treiber verfügen. Weitere Informationen finden Sie im Blogbeitrag Driver compatibility with Device Guard in Windows 10 (Treiberkompatibilität mit Device Guard in Windows 10).

   

  Mit dem Codeintegritätsfeature von Device Guard können Organisationen steuern, welcher Code als vertrauenswürdig für die Ausführung im Windows-Kernel eingestuft wird, und welche Anwendungen für die Ausführung im Benutzermodus genehmigt werden. Dieses Feature ist mithilfe einer Richtlinie konfigurierbar.

  Die Codeintegritätsrichtlinie von Device Guard ist eine Binärdatei, deren Signierung von Microsoft empfohlen wird. Das Signieren der Codeintegritätsrichtlinie unterstützt den Schutz vor einem böswilligen Benutzer mit Administratorrechten, der versucht, die aktuelle Codeintegritätsrichtlinie zu ändern oder zu entfernen.

• Credential Guard. Credential Guard schützt Anmeldeinformationen von Unternehmen durch hardwarebasierte Isolierung dieser.

  Unter Windows 10 soll Credential Guard die Domänenanmeldeinformationen von Unternehmen vor Diebstahl und Missbrauch durch Schadsoftware schützen. Mit Credential Guard hat Windows 10 eine architektonische Änderung eingeführt, die derzeitige Formen des Angriffs durch Hashweitergabe (Pass-the-Hash, PtH) grundsätzlich verhindert.

  Dazu werden Hyper-V und das neue virtualisierungsbasierte Sicherheitsfeature genutzt, um einen geschützten Container zu erstellen, in dem vertrauenswürdiger Code und geheime Schlüssel vom Windows-Kernel isoliert werden. Das heißt, dass ein Hacker auch bei einer Gefährdung des Windows-Kernels keine Möglichkeit zum Lesen und Extrahieren der erforderlichen Daten zum Initiieren eines PtH-Angriffs hat. Credential Guard verhindert dies, da der Speicher, in dem geheime Schlüssel gespeichert werden, im regulären Betriebssystem selbst im Kernelmodus nicht mehr zugänglich ist. Der Zugriff auf den Speicher wird von den Hypervisor-Steuerelementen kontrolliert.

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

  Windows 10 nimmt Messungen der UEFI-Firmware aller Windows- und Antischadsoftware-Komponenten vor, wenn diese während des Startvorgangs geladen werden. Diese Komponenten werden außerdem nacheinander erfasst und gemessen, nicht alle auf einmal. Wenn diese Messungen abgeschlossen sind, werden die Werte digital signiert und sicher im TPM gespeichert. Anschließend können sie nicht mehr geändert werden, es sei denn, das System wird zurückgesetzt.

  Weitere Informationen finden unter Sicherer Start und kontrollierter Start: Schützen vorrangiger Startkomponenten vor Schadsoftware.

  Bei jedem nachfolgenden Startvorgang werden die gleichen Komponenten gemessen; dies ermöglicht einen Vergleich der Messungen mit einer erwarteten Basis. Für zusätzliche Sicherheit können die vom TPM gemessenen Werte signiert und an einen Remoteserver übertragen werden, der dann den Vergleich durchführt. Dieser Vorgang wird als Remote-Nachweis über Geräteintegrität bezeichnet und ermöglicht dem Server das Überprüfen des Integritätsstatus des Windows-Geräts.

  Für den Integritätsnachweis ist TPM 2.0 erforderlich. Unter Windows 10 erfordert TPM 2.0 auch UEFI-Firmware.

  Obwohl der sichere Start eine proaktive Schutzart ist, handelt es sich beim Integritätsnachweis um eine reaktive Art von Startschutz. Im Auslieferungszustand von Windows ist der Integritätsnachweis deaktiviert und wird von Antischadsoftware oder einem MDM-Anbieter aktiviert. Im Gegensatz zum sicheren Start hält der Integritätsnachweis den Startprozess nicht an und initiiert Wartungsaktionen, falls eine Messung nicht funktioniert. Mit der bedingten Zugriffssteuerung trägt der Integritätsnachweis jedoch zur Verhinderung des Zugriffs auf hochwertige Ressourcen zu.

Virtualisierungsbasierte Sicherheit

Die virtualisierungsbasierte Sicherheit bietet eine neue Vertrauensstellungsgrenze für Windows 10. nutzt Hyper-V-Hypervisor-Technologie zur Verbesserung der Plattformsicherheit. Die virtualisierungsbasierte Sicherheit bietet eine sichere Umgebung für die Ausführung von bestimmtem vertrauenswürdigem Windows-Code (Trustlet) sowie zum Schutz sensibler Daten.

Die virtualisierungsbasierte Sicherheit trägt zum Schutz vor einem gefährdeten Kernel oder einem böswilligen Benutzer mit Administratorrechten bei. Beachten Sie, dass die virtualisierungsbasierte Sicherheit keinen Schutz vor physischen Angriffen bietet.

Folgende Windows 10-Dienste sind durch virtualisierungsbasierte Sicherheit geschützt:

• Credential Guard (Isolation von LSA-Anmeldeinformationen): verhindert Pass-the-Hash-Angriffe und den Diebstahl von Unternehmensanmeldeinformationen durch das Lesen und Sichern des Lsass-Speicherinhalts.

• Device Guard (Hyper-V-Codeintegrität): Für Device Guard wird die neue auf Virtualisierung basierende Sicherheit in Windows 10 genutzt, bei der der Codeintegritätsdienst vom eigentlichen Windows-Kernel isoliert wird. Für den Dienst können dann Signaturen verwendet werden, die über Ihre vom Unternehmen gesteuerte Richtlinie festgelegt werden, um ermitteln zu können, was als vertrauenswürdig angesehen wird. Der Codeintegritätsdienst wird praktisch parallel zum Kernel in einem per Windows-Hypervisor geschützten Container ausgeführt.

• Andere isolierte Dienste: Windows Server Technical Preview 2016 bietet beispielsweise das vTPM-Feature, das Ihnen das Einrichten verschlüsselter virtueller Computer (VMs) auf Servern ermöglicht.

Hinweis  

Die virtualisierungsbasierte Sicherheit ist nur mit Windows 10 Enterprise verfügbar. Virtualisierungsbasierte Sicherheit erfordert Geräte mit UEFI (2.3.1 oder höher) mit aktiviertem sicheren Start und x64-Prozessor mit aktivierten Virtualisierungserweiterungen und SLAT. IOMMU, TPM 2.0. und die Unterstützung für überschriebenen sicheren Speicher sind optional, werden aber empfohlen.

 

Das folgende Schema ist eine allgemeine Übersicht über Windows 10 mit virtualisierungsbasierter Sicherheit.

Credential Guard

Wenn Credential Guard unter Windows 10 aktiviert ist, führt der Subsystemdienst für die lokale Sicherheitsautorität (lsass.exe) sensiblen Code in einem isolierten Benutzermodus aus, um Daten vor Schadsoftware schützen, die u. U. im normalen Benutzermodus ausgeführt wird. Dadurch wird sichergestellt, dass geschützte Daten nicht gestohlen und auf Remotecomputern wiederverwendet werden, und zahlreiche PtH-artige Angriffe werden abgewehrt.

Credential Guard schützt Anmeldeinformationen durch Verschlüsselung mit einem startbasierten oder einem dauerhaften Schlüssel:

• Der startbasierte Schlüssel wird für Anmeldeinformationen im Speicher verwendet, die keine Persistenz erfordern. Ein Beispiel für solche Anmeldeinformationen wäre ein Ticket-Granting-Ticket (TGT)-Sitzungsschlüssel. Dieser Schlüssel wird bei jeder Authentifizierung mit einem Schlüsselverteilungscenter (Key Distribution Center, KDC) ausgehandelt und mit einem startbasierten Schlüssel geschützt.

• Der dauerhafte Schlüssel oder eine Ableitung davon wird zum Schutz von Elementen verwendet, die nach einem Neustart gespeichert und erneut geladen werden. Solcher Schutz ist für langfristigen Speicher vorgesehen und muss mit einem einheitlichen Schlüssel geschützt werden.

Credential Guard wird durch einen Registrierungsschlüssel und die anschließende Verwendung einer UEFI-Variable aktiviert. Dies geschieht zum Schutz vor Remote-Änderungen der Konfiguration. Die Verwendung einer UEFI-Variable impliziert, dass zum Ändern der Konfiguration physischer Zugriff erforderlich ist. Wenn „lsass.exe“ erkennt, dass die Isolierung von Anmeldeinformationen aktiviert ist, erstellt der Dienst „LsaIso.exe“ als isolierten Prozess, der die Ausführung im isolierten Benutzermodus sicherstellt. Der Start von „LsaIso.exe“ erfolgt vor der Initialisierung eines Sicherheitsunterstützungsanbieters. Dadurch wird sichergestellt, dass die Routinen zur Unterstützung des abgesicherten Modus vor Beginn einer Authentifizierung bereit sind.

Device Guard

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

Die Entscheidung über die Vertrauenswürdigkeit und die Ausführung von Code erfolgt mithilfe von Hyper-V-Codeintegrität, die in der virtualisierungsbasierten Sicherheit ausgeführt wird, einem durch Hyper-V geschützten Container, der zusammen mit dem normalen Windows-System 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. Bei x64-basierten Versionen von Windows 10 müssen Kernelmodustreiber digital signiert werden.

Hinweis  

Unabhängig von der Aktivierung der Device Guard-Richtlinie sind unter Windows 10 die standardmäßigen Anforderungen an im Kernel ausgeführte Anwendungen höher. Windows 10-Treiber müssen von Microsoft, genauer vom WHQL (Windows Hardware Quality Labs)-Portal signiert sein. Außerdem akzeptiert das WHQL-Portal ab Oktober 2015 nur noch Treiberübermittlungen, einschließlich der Kernel- und Benutzermodustreiberübermittlungen, die über ein gültiges Codesignaturzertifikat für die erweiterte Überprüfung (Extended Validation, „EV“) verfügen.

 

Mit Device Guard können Unternehmen unter Windows 10 jetzt eine eigene Codeintegritätsrichtlinien für die Verwendung auf x64-Systemen mit Windows 10 Enterprise definieren. Unternehmen haben die Möglichkeit zum Konfigurieren der Richtlinie, die bestimmt, was als vertrauenswürdig eingestuft und ausgeführt wird. Dazu zählen Treiber und Systemdateien sowie traditionelle Desktopanwendungen und Skripts. Das System lässt dann nur noch die Ausführung von Anwendungen zu, denen das Unternehmen vertraut.

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

• Zulassen beschränkt die Ausführung von Anwendungen auf eine Liste von zulässigem Code oder einen vertrauenswürdigen Herausgeber und blockiert alle anderen Anwendungen.

• Verweigern schließt den Ansatz zum Zulassen vertrauenswürdiger Herausgeber ab, indem die Ausführung einer bestimmten Anwendung blockiert wird.

Zum Zeitpunkt der Erstellung dieses Dokuments und laut aktuellen Untersuchungen von Microsoft weisen mehr als 90 Prozent aller Schadsoftware überhaupt keine Signatur auf. Daher kann das Implementieren einer einfachen Device Guard-Richtlinie dazu beitragen, den einen Großteil von Schadsoftware einfach und effizient zu blockieren. Tatsächlich verfügt Device Guard über noch mehr potenzielle Funktionen und kann auch zum Blockieren von signierter Schadsoftware beitragen.

Device Guard muss geplant und konfiguriert werden, damit das Feature wirklich effektiv ist. Es handelt sich nicht einfach um eine Schutzlösung, die entweder aktiviert oder deaktiviert ist. Device Guard ist eine Kombination aus Hardware- und Software-Sicherheitsfeatures, die bei einer gemeinsamen Konfiguration einen Computer sperren können, um für ein möglichst sicheres und widerstandsfähiges System zu sorgen.

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

• Der erste Teil ist ein Standardsatz von Hardware-Sicherheitsfeatures, die in der vorhergehenden Version von Windows eingeführt wurden. Das TPM für kryptografische Hardwarevorgänge und UEFI mit moderner Firmware in Verbindung mit dem sicheren Start ermöglichen Ihnen die Kontrolle der beim Systemstart ausgeführten Geräte.

• Auf das Hardware-Sicherheitsfeature folgt das Modul für Codeintegrität. Unter Windows 10 ist die Codeintegrität ist jetzt vollständig konfigurierbar und befindet sich im isolierten Benutzermodus, einem Teil des Speichers, der durch virtualisierungsbasierte Sicherheit geschützt ist.

• Der letzte Teil des Device Guard ist Verwaltbarkeit. Die Konfiguration der Codeintegrität wird durch bestimmte Gruppenrichtlinienobjekte, PowerShell-Cmdlets und MDM-Konfigurationsdienstanbieter (CSPs) verfügbar gemacht.

Weitere Informationen zur Bereitstellung von Device Guard in einem Unternehmen finden Sie im Device Guard-Bereitstellungshandbuch.

Device Guard-Szenarien

Wie bereits beschrieben stellt Device Guard eine leistungsstarke Methode zum Sperren von Systemen dar. Device Guard ist nicht für die allgemeine Verwendung vorgesehen und ist möglicherweise nicht immer geeignet; es sind jedoch einige Szenarien von hohem Interesse vorhanden.

Device Guard eignet sich für Systeme mit fester Arbeitsauslastung wie Registrierkassen, Kiosk-Computer, sichere Admin Workstations (SAWs) oder gut verwaltete Desktops. Device Guard ist von hoher Relevanz auf Systemen mit sehr gut definierter Software, die voraussichtlich ausgeführt und nicht häufig geändert wird. Es kann Information-Worker (IWs) auch auf anderen Geräten als SAWs schützen, sofern bekannt ist, welche Anwendungen sie ausführen müssen und dass sich diese Anwendungen nicht täglich ändern.

SAWs sind Computer, die dazu entwickelt wurden, das Risiko einer Gefährdung durch u. a. Schadsoftware, Phishing-Angriffe, gefälschte Websites und PtH-Angriffe erheblich zu reduzieren. Obwohl SAWs nicht als Wunderwaffe unter den Sicherheitslösungen gegen diese Angriffe gelten können, ist diese Art von Clients hilfreich als Teil einer mehrstufigen Tiefenverteidigungsstrategie.

Zum Schutz hochwertiger Ressourcen werden SAWs zum Herstellen sicherer Verbindungen mit diesen Ressourcen verwendet.

Ebenso eignet sich Device Guard hervorragend für vollständig verwaltete Unternehmens-Workstations, auf denen Anwendungen mithilfe eines Verteilungstools wie System Center Configuration Manager, Intune oder der Geräteverwaltungslösung eines Drittanbieters installiert werden. In dieser Art von Szenario hat das Unternehmen einen guten Überblick über die von einem durchschnittlichen Benutzer verwendete Software.

Die Verwendung von Device Guard auf geringfügig verwalteten Unternehmens-Arbeitsstationen, auf denen der Benutzer in der Regel zum Installieren von Software berechtigt ist, kann eine Herausforderung darstellen. Wenn ein Unternehmen hohe Flexibilität bietet, ist die Ausführung von Device Guard im Erzwingungsmodus schwierig. Device Guard kann jedoch im Überwachungsmodus ausgeführt werden, und in diesem Fall enthält das Ereignisprotokoll einen Datensatz der Binärdateien, die gegen die Device Guard-Richtlinie verstoßen haben. Wenn Device Guard im Überwachungsmodus verwendet wird, erhalten Unternehmen umfangreiche Daten zu Treibern und Anwendungen, die Benutzer installieren und ausführen.

Bevor Sie vom Schutz durch Device Guard profitieren können, müssen Sie mit den Tools von Microsoft eine Codeintegritätsrichtlinie erstellen. Die Bereitstellung kann jedoch mit allgemeinen Verwaltungstools, z. B. die Gruppenrichtlinie erfolgen. Die Codeintegritätsrichtlinie ist ein binär codiertes XML-Dokument mit Konfigurationseinstellungen für den Benutzer- und Kernelmodus von Windows 10 und Einschränkungen für Windows 10-Skripthosts. Mit der Richtlinie für Device Guard-Codeintegrität wird beschränkt, welcher Code auf einem Gerät ausgeführt werden kann.

Hinweis  

Die Device Guard-Richtlinie kann in Windows 10 signiert werden, um für zusätzlichen Schutz vor Benutzern mit Administratorrechten zu sorgen, die diese Richtlinie ändern oder entfernen möchten.

 

Die signierte Device Guard-Richtlinie bietet besseren Schutz vor einem böswilligen lokalen Administrator, der versucht, Device Guard zu bezwingen.

Wenn die Richtlinie signiert ist, wird die GUID der Richtlinie vor dem Betriebssystemstart mit UEFI in einer sicheren Variable gespeichert, die Schutz vor Manipulation bietet. Die einzige Möglichkeit, die Device Guard-Richtlinie später zu aktualisieren ist das Bereitstellen einer neuen Version der Richtlinie, die vom selben Signaturgeber oder einem Signaturgeber signiert ist, der in der Device Guard-Richtlinie im Abschnitt „UpdateSigner“ angegeben ist.

Die Bedeutung der Signatur von Anwendungen

Auf Computern mit Device Guard schlägt Microsoft den Wechsel zu einer Umgebung vor, in der unter Windows 10 nur signierter und vertrauenswürdiger Code ausgeführt werden darf, im Gegensatz zu einer Umgebung in der signierte Apps ohne Einschränkungen ausgeführt werden können.

Mit Windows 10 stellen Unternehmen branchenspezifische Apps für Mitarbeiter über die Windows Store-Infrastruktur zur Verfügung. Genauer gesagt stehen branchenspezifische Apps in einem privaten Speicher innerhalb des öffentlichen Windows Store zur Verfügung. Windows Store signiert und verteilt universelle und klassische Windows-Apps. Alle aus dem Windows Store heruntergeladenen Apps sind signiert.

Heutzutage ist in Unternehmen der Großteil der branchenspezifischen Anwendungen nicht signiert. Die Codesignatur gilt aus verschiedenen Gründen, z. B. dem Mangel an entsprechender Kompetenz, häufig als ein schwer zu lösendes Problem. Obwohl das Signieren von Code eine bewährte Methode ist, sind zahlreiche interne Anwendungen nicht signiert.

Windows 10 enthält Tools, mit denen IT-Spezialisten einen Prozess für bereits verpackte Anwendungen zum Erstellen zusätzlicher Signaturen durchführen können, die zusammen mit vorhandenen Anwendungen verteilt werden können.

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

Mit Mechanismen von Zulassungslisten wird zwar äußerst effizient sichergestellt, dass nur vertrauenswürdige Anwendungen ausgeführt werden können, die Gefährdung einer vertrauenswürdigen (aber anfälligen) Anwendung durch schädliche Inhalte, die für den Missbrauch einer bekannten Schwachstelle entworfen wurden, können sie jedoch nicht verhindern. Device Guard schützt nicht vor schädlichem Code im Benutzermodus, der durch das Ausnutzen von Sicherheitslücken ausgeführt wird.

Sicherheitslücken sind Schwächen in einer Software, die es einem Angreifer ermöglichen, die Integrität, Verfügbarkeit oder Vertraulichkeit des Geräts zu manipulieren. Einige der schwerwiegendsten Sicherheitsrisiken ermöglichen Angreifern den Missbrauch des gefährdeten Geräts durch die Ausführung von schädlichem Code ohne das Wissen des Benutzers.

Angreifer verteilen häufig speziell erstellten Inhalt, um zu versuchen, bekannte Sicherheitslücken in Benutzermodus-Software wie Webbrowsern (und zugehörige Plug-Ins), virtuelle Java-Computer, PDF-Reader oder Dokumenteditoren zu missbrauchen. Momentan wirken sich 90 Prozent der entdeckten auf Benutzermodusanwendungen aus im Vergleich zum Betriebssystem und Kernelmodustreiber, die sie hosten.

Zur Bekämpfung dieser Bedrohungen sind Patches das mit Abstand am effektivste Steuerelement, und Antischadsoftware sorgt für ergänzende Sicherheitsebenen.

Die meiste Anwendungssoftware verfügt über keine Möglichkeit zur Selbstaktualisierung, d. h. auch wenn der Softwareanbieter ein Update zum Schließen der Sicherheitslücke veröffentlicht, weiß der Benutzer vielleicht nicht, dass das Update verfügbar ist bzw. wie es abgerufen werden kann und bleibt daher anfällig für Angriffe. Unternehmen müssen weiterhin Geräte verwalten und Sicherheitslücken schließen.

MDM-Lösungen gewinnen an Bedeutung als Technologie für einfache Geräteverwaltung. Unter Windows 10 werden die für MDMs verfügbaren Verwaltungsfunktionen erweitert. Eines der wichtigsten Features, die Microsoft unter Windows 10 hinzugefügt hat, ist die Möglichkeit für MDMs, eine überzeugende Deklaration zum Gerätezustand von verwalteten und registrierten Geräten zu erhalten.

Nachweis über Geräteintegrität

Der Nachweis über Geräteintegrität nutzt TPM 2.0 zum Bereitstellen von kryptografisch sicheren und überprüfbaren Messungen der beim Gerätestart verwendeten Softwarekette.

Für Windows 10-basierte Geräte führt Microsoft eine neue öffentliche API ein, die MDM-Software den Zugriff auf einen Remote-Nachweisdienst namens „Windows Health Attestation Service“ bietet. Ein Integritätsnachweisergebnis kann in Verbindung mit anderen Elementen außerdem verwendet werden, um den Zugriff auf Netzwerke, Apps oder Dienste zuzulassen oder zu verweigern, je nachdem, ob Geräte ihre Integrität nachweisen können.

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

Hardwareanforderungen

Die folgende Tabelle enthält Details zu den Hardwareanforderungen für virtualisierungsbasierte Sicherheitsdienste und das Integritätsnachweisfeature. Weitere Informationen finden Sie unter Minimale Hardwareanforderungen.

Hardware	Grund
UEFI-Firmware 2.3.1 oder höher mit Aktivierung von „Sicherer Start“	Erforderlich zur Unterstützung von „Sicherer Start“ gemäß UEFI. „Sicherer Start“ gemäß UEFI stellt sicher, dass das Gerät nur autorisierten Code startet. Darüber hinaus muss Startintegrität (sicherer Plattformstart) gemäß den Anforderungen in der Spezifikation für die Hardwarekompatibilität für Systeme für Windows 10 im Unterabschnitt „System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby“.
Virtualisierungserweiterungen, z. B. Intel VT-x, AMD-V und SLAT, müssen aktiviert sein	Zur Unterstützung von virtualisierungsbasierter Sicherheit erforderlich Hinweis   Device Guard kann ohne Verwendung von virtualisierungsbasierter Sicherheit aktiviert werden.
x64-Prozessor	Zur Unterstützung virtualisierungsbasierter Sicherheit erforderlich, die Windows-Hypervisor verwendet. Hyper-V wird nur auf x64-Prozessoren (nicht x86) unterstützt. Der DMA (Direct Memory Access)-Schutz kann für zusätzlichen Arbeitsspeicherschutz aktiviert werden; dazu müssen Prozessoren jedoch DMA-Schutztechnologien aufweisen.
IOMMU (z. B. Intel VT-d, AMD-Vi)	Unterstützung für die IOMMU unter Windows 10 verbessert die Systemresilienz gegenüber DMA-Angriffen.
Trusted Platform Module (TPM) 2.0	Erforderlich zur Unterstützung des Integritätsnachweises und für weitere wichtige Schutzmaßnahmen für virtualisierungsbasierte Sicherheit.

 

Dieser Abschnitt enthält Informationen über mehrere eng verwandte Steuerelemente unter Windows 10 angezeigt. Die mehrstufigen Sicherheitsmaßnahmen und der umfassende Ansatz tragen zur Beseitigung von Low-Level-Schadsoftware während der Startsequenz bei. Die virtualisierungsbasierte Sicherheit stellt eine grundlegende Änderungen der Betriebssystemarchitektur dar, die eine neue Sicherheitsgrenze einführt. Device Guard und Credential Guard dienen zum Blockieren von nicht vertrauenswürdigem Code bzw. zum Schutz von Anmeldeinformationen für Unternehmensdomänen vor Diebstahl und Missbrauch. In diesem Abschnitt wurde außerdem kurz erläutert, welche Bedeutung die Verwaltung von Geräten und das Schließen von Sicherheitslücken hat. Alle diese Technologien können verwendet werden, um Geräte zu sichern und zu sperren, um das Risiko einer Gefährdung durch Angreifer zu mindern.

Erkennen eines fehlerhaften Windows 10-basierten Geräts

In vielen Unternehmen gelten Geräte derzeit nur dann als konform mit der Unternehmensrichtlinie, nachdem anhand einer Reihe von Überprüfungen nachgewiesen wurde, dass sich z. B. das Betriebssystem im richtigen Zustand befindet und Sicherheitsvorkehrungen aktiviert sind. Leider ist diese Art der Berichterstattung bei heutigen Systemen nicht vollständig zuverlässig, da Schadsoftware eine Softwaredeklaration über den Systemstatus spoofen kann. Ein Rootkit oder ein ähnlicher Low-Level-Angriff kann einen falschen fehlerfreien Zustand an herkömmliche Compliance-Tools melden.

Die größte Herausforderung bei Rootkits besteht darin, dass die u. U. für den Client nicht erkennbar sind. Da Rootkits und Bootkits vor Antischadsoftware starten und über Berechtigungen auf Systemebene verfügen, können sie sich selbst vollständig verschleiern und weiterhin auf Systemressourcen zugreifen. Daher erscheinen herkömmliche, mit Rootkits infizierte Computer fehlerfrei, auch wenn Antischadsoftware ausgeführt wird.

Wie bereits erläutert verwendet das Integritätsnachweisfeature von Windows 10 die TPM 2.0-Hardwarekomponente, um für jede startbezogene Komponente einschließlich Firmware, Windows 10-Kernel und sogar Frühstarttreiber, eine sichere Messung aufzuzeichnen. Da der Integritätsnachweis die hardwarebasierten Sicherheitsfunktionen des TPM nutzt, bleibt das Protokoll aller beim Start gemessenen Komponenten außerhalb der Reichweite von Schadsoftware.

Durch die Bestätigung eines vertrauenswürdigen Startzustands können Geräte nachweisen, dass sie keine Low-Level-Schadsoftware ausführen, die später Kompatibilitätsprüfungen spoofen könnte. Der TPM-basierte Integritätsnachweis bietet einen zuverlässigen Vertrauensanker für Ressourcen, die wertvolle Daten enthalten.

Was ist das Konzept der Geräteintegrität?

Um das Konzept der Geräteintegrität zu verstehen, muss man wissen, welche herkömmlichen Maßnahmen IT-Spezialisten zum Verhindern einer Kompromittierung durch Schadsoftware einsetzen. Technologien zum Kontrollieren von Schadsoftware sind stark auf die Vermeidung von Installation und Verteilung konzentriert.

Allerdings birgt die Verwendung herkömmlicher Technologien zur Vorbeugung von Schadsoftware wie Antischadsoftware- oder Patch-Lösungen eine Reihe von neuen Problemen für IT-Spezialisten: die Möglichkeit zum Überwachen und Steuern der Compliance von Geräten, die auf Unternehmensressourcen zugreifen.

Die Definition der Gerätecompliance variiert basierend auf der von einem Unternehmen installierten Antischadsoftware, Konfigurationseinstellungen von Geräten, der grundlegenden Patchverwaltung und anderen Sicherheitsanforderungen. Die Integrität des Geräts ist jedoch Teil der allgemeinen Gerätecompliance-Richtlinie.

Die Integrität des Geräts ist nicht binär und hängt von der Sicherheitsimplementierung des Unternehmens ab. Der Integritätsnachweisdienst nutzt ein vertrauenswürdiges Hardware-TPM und gibt Informationen zu den beim Gerätestart aktivierten Sicherheitsfeatures an das MDM zurück.

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

Remote-Nachweis über Geräteintegrität

Unter Windows 10 bezieht sich der Integritätsnachweis auf ein Feature, mit dem während des Startvorgangs generierte Daten zum kontrollierten Start an einen von Microsoft betriebenen Remotedienst zum Integritätsnachweis gesendet werden.

Dies ist die sicherste verfügbare Ansatz für Windows 10-basierten Geräten, um zu erkennen, wenn Sicherheitsmaßnahmen ausgefallen sind. Während des Startvorgangs werden das TCG-Protokoll und PCR-Werte an einem Remote-Clouddienst von Microsoft gesendet. Die Protokolle werden dann von Health Attestation Service überprüft, um zu ermitteln, welche Änderungen auf dem Gerät aufgetreten sind.

Eine vertrauende Seite wie ein MDM kann den vom Remotedienst zum Integritätsnachweis generierten Bericht prüfen.

Hinweis  

Zur Verwendung des Integritätsnachweisfeatures von Windows 10 muss das Gerät mit einem diskreten oder firmwarebasierten TPM 2.0 ausgestattet sein. Eine Einschränkung auf einer bestimmten Edition von Windows 10 ist nicht vorhanden.

 

Windows 10 unterstützt Integritätsnachweisszenarien, indem Anwendungen auf den zugrunde liegenden Integritätsnachweis-Konfigurationsdienstanbieter (CSP) zugreifen können, um ein Integritätsnachweistoken anzufordern. Die Messung der Startsequenz kann jederzeit lokal von einer Antischadsoftware oder einem MDM-Agenten überprüft werden.

Remote-Nachweis über Geräteintegrität in Kombination mit einem MDM bietet eine hardwarebasierte Methode für das Melden des aktuellen Sicherheitsstatus und das Erkennen von Änderungen, ohne dass der auf dem System ausgeführten Software vertraut werden muss.

Falls auf dem Gerät schädlicher Code ausgeführt wird, ist die Verwendung eines Remoteservers erforderlich. Wenn auf dem Gerät ein Rootkit vorhanden ist, ist die Antischadsoftware nicht mehr zuverlässig, und ihr Verhalten kann durch schädlichen Code manipuliert werden, der frühzeitig in der Startsequenz ausgeführt wird. Daher ist es wichtig, den sicheren Start und Device Guard zu verwenden, um zu steuern, welcher Code während der Startsequenz geladen wird.

Die Antischadsoftware kann die Startsequenz durchsuchen, um zu ermitteln, ob sie Anzeichen von Schadsoftware wie z. B. eines Rootkits enthält. Sie kann auch das TCG-Protokoll und die PCRs an einen Remoteserver zum Integritätsnachweis 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.

Beim Start von einem Gerät mit einem TPM wird eine Messung verschiedener Komponenten durchgeführt. Dazu gehören Firmware, UEFI-Treiber, CPU-Microcode und auch alle Windows 10 Treiber vom Typ „Bootstart“. Die unformatierten Messungen werden in den TPM-PCRs gespeichert, während die Details aller Ereignisse (ausführbarer Pfad, Zertifizierungsstelle usw.) im TCG-Protokoll verfügbar sind.

Funktionsweise des Integritätsnachweisprozesses:

1. Hardware-Startkomponenten werden gemessen.

2. Betriebssystem-Startkomponenten werden gemessen.

3. Wenn Device Guard aktiviert ist, wird die aktuelle Device Guard-Richtlinie gemessen.

4. Windows-Kernel wird gemessen.

5. Antivirensoftware wird als erster Kernelmodustreiber gestartet.

6. Bootstarttreiber werden gemessen.

7. Der MDM-Server nutzt den Integritätsnachweis-CSP, um über den MDM-Agent einen Befehl zur Integritätsprüfung auszugeben.

8. Startmessungen werden vom Integritätsnachweisdienst überprüft.

Hinweis  

Standardmäßig werden die letzten 100 Systemstartprotokolle und alle zugehörigen Fortsetzungsprotokolle im Ordner „%SystemRoot%\logs\measuredboot“ archiviert.

Die Anzahl der beibehaltenen Protokolle kann in der Registrierung unter REG_DWORD mit dem Wert PlatformLogRetention unter dem Schlüssel HKLM\SYSTEM\CurrentControlSet\Services\TPM festgelegt werden. Der Wert 0 deaktiviert die Protokollarchivierung, und bei einem Wert von 0xffffffff werden alle Protokolle beibehalten.

 

Das folgende Verfahren beschreibt, wie Integritätsstartmessungen an den Integritätsnachweisdienst gesendet werden:

1. Der Client (ein Windows 10-basiertes Gerät mit einem TPM 2.0) initiiert die Anforderung an den Remotedienst zum Integritätsnachweis. Da als Server für den Integritätsnachweis ein Microsoft-Clouddienst erwartet wird, ist der URI bereits vorab auf dem Client bereitgestellt.

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

3. Der Remotedienst zum Integritätsnachweis führt dann folgende Aktionen aus:

   1. Überprüft, ob das AIK-Zertifikat von einer bekannten und vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde, gültig ist und nicht aufgehoben wurde.

   2. Stellt sicher, dass die Signatur auf den PCR-Angeboten korrekt und mit dem Wert des TCG-Protokolls konsistent ist.

   3. Analysiert die Eigenschaften im TCG-Protokoll.

   4. Gibt das Gerätintegritätstoken aus, das die Statusinformationen, die AIK-Informationen und die Startzählerinformationen enthält. Das Integritätstoken enthält auch die gültige Ausstellungszeit. Das Gerätintegritätstoken ist verschlüsselt und signiert; das bedeutet, dass die Informationen geschützt und nur für den ausstellenden Integritätsnachweisdienst zugänglich sind.

4. Der Client speichert das verschlüsselte Integritäts-BLOB im lokalen Speicher. Das Gerätintegritätstoken enthält den Gerätestatus, eine Geräte-ID (den Windows AIK) und den Startzähler.

Nachweis über Geräteintegrität – Komponenten

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

Trusted Platform Module

Es geht um TPM 2.0 und Endorsement-Zertifikate. In diesem Abschnitt wird beschrieben, wie PCRs (enthalten Systemkonfigurationsdaten), der Endorsement Key (EK) (fungiert als Identitätskarte für TPM), SRK (schützt Schlüssel) und AIKs (können den Plattformstatus melden) zur Erstellung von Integritätsnachweisberichten verwendet werden.

In einer vereinfachten Version ist das TPM eine passive Komponente mit eingeschränkten Ressourcen. Es kann Zufallszahlen berechnen, RSA-Schlüssel erstellen, kurze Daten entschlüsseln und beim Gerätestart erstellte Hashes speichern.

Ein TPM umfasst in einer einzelnen Komponente:

• Einen RSA 2048-Bit-Schlüsselgenerator

• Ein Zufallszahlen-Generator

• Permanenten Speicher zum Aufbewahren von EK-, SRK und AIK-Schlüsseln

• Ein kryptografisches Modul zum Verschlüsseln, Entschlüsseln und Signieren

• Flüchtigen Speicher zum Aufbewahren PCRs und RSA-Schlüssel

Endorsement Key

Das TPM verfügt über einen eingebetteten eindeutigen kryptografischen Schlüssel, der als „Endorsement Key“ bezeichnet wird. Beim Endorsement Key des TPM handelt es sich um ein Paar von asymmetrischen Schlüsseln (RSA-Größe: 2048 Bit).

Der öffentliche Endorsement Key-Schlüssel wird im Allgemeinen für das Senden von sicheren sensiblen Parametern verwendet, z. B. wenn das TPM in Besitz genommen wird, das den definierenden Hash des Besitzerkennworts enthält. Der private EK-Schlüssel EK wird beim Erstellen von sekundären Schlüsseln wie AIKs verwendet.

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

Der Endorsement Key wird häufig zusammen mit einem oder zwei digitalen Zertifikaten angegeben:

• Ein Zertifikat wird vom TPM-Hersteller erstellt und als Endorsement-Zertifikat bezeichnet. Das Endorsement-Zertifikat wird als Nachweis der Authentizität des TPM (z. B., dass es sich um ein echtes TPM von einem bestimmten Chiphersteller handelt) für lokale Prozesse, Anwendungen oder Clouddienste verwendet. Das Endorsement-Zertifikat wird während der Herstellung oder bei der ersten Initialisierung des TPMs durch die Kommunikation mit einem Onlinedienst erstellt.

• Das andere Zertifikat wird vom Plattformgenerator erzeugt und wird als Plattformzertifikat bezeichnet, um anzugeben, dass ein bestimmtes TPM in ein bestimmtes Gerät integriert ist.

Für bestimmte Geräte, die ein firmwarebasiertes TPM von Intel oder Qualcomm verwenden, wird das Endorsement-Zertifikat beim Initialisieren des TPMs während des Eindrucks beim ersten Ausführen von Windows 10 erstellt.

Hinweis  

Der sichere Start schützt die Plattform, bis der Windows-Kernel geladen ist. Anschließend übernehmen andere Schutzlösungen wie der vertrauenswürdige Start, Hyper-V-Codeintegrität und ELAM. Ein Gerät, das ein TPM von Intel oder Qualcomm verwendet, ruft online ein signiertes Zertifikat vom Hersteller ab, der den Chip erstellt hat, und speichert dieses dann im TPM-Speicher. Damit der Vorgang erfolgreich ausgeführt werden kann, müssen Sie beim Filtern des Internetzugriffs auf Ihren Clientgeräten die folgenden URLs autorisieren:

• Für Intel-Firmware-TPMs: https://ekop.intel.com/ekcertservice

• Für Qualcomm-Firmware-TPMs: https://ekcert.spserv.microsoft.com/

 

Attestation Identity Keys (AIKs)

Da das Endorsement-Zertifikat für jedes Gerät eindeutig ist und nicht geändert wird, kann dessen Verwendung Bedenken in Bezug auf den Datenschutz hervorrufen, da es theoretisch möglich ist, ein bestimmtes Gerät nachzuverfolgen. Um ein solches Datenschutzproblem zu vermeiden, gibt Windows 10 einen abgeleiteten Nachweisanker aus, der Endorsement-Zertifikat basiert. Dieser Zwischenschlüssel, der an einen Endorsement-Key nachgewiesen werden kann, ist der Attestation Identity Key (AIK), und das entsprechende Zertifikat ist das AIK-Zertifikat. Dieses AIK-Zertifikat wird von einem Microsoft-Clouddienst ausgestellt.

Hinweis  

Bevor das Gerät mithilfe der Nachweisfunktionen von TPM 2.0 seine Integrität melden kann, muss ein AIK-Zertifikat in Verbindung mit einem Drittanbieterdienst wie der Cloud-Zertifizierungsstelle von Microsoft bereitgestellt werden. Nach seiner Bereitstellung kann der private AIK-Schlüssel zum Melden der Plattformkonfiguration verwendet werden. Windows 10 erstellt mit dem AIK bei jedem Start eine Signatur über den Zustand des Plattformprotokolls (und einen monotonen Leistungsindikatorwert).

 

Der AIK ist ein asymmetrisches (öffentlich/privat) Schlüsselpaar, das aus Datenschutzgründen als Ersatz für den EK als Identität für das TPM verwendet wird. Der private Teil eines AIK wird nie eingeblendet oder außerhalb des TPM verwendet und kann innerhalb des TPM nur für bestimmte Vorgänge verwendet werden. Außerdem kann es nur zum Signieren und nur für beschränkte, TPM-definierte Vorgänge verwendet werden.

Windows 10 erstellt AIKs, die ggf. durch das TPM geschützt sind, als RSA-Signaturschlüssel mit 2048 Bit. Microsoft hostet einen Clouddienst, die Microsoft-Cloud-Zertifizierungsstelle, um kryptografisch sicherzustellen, dass mit einem echten TPM kommuniziert wird und das TPM über den bereitgestellten AIK verfügt. Nachdem die Microsoft-Cloud-Zertifizierungsstelle diese Fakten bestätigt hat, gibt sie ein AIK-Zertifikat an das Windows 10-basierte Gerät aus.

Zahlreiche vorhandene Geräte, die auf Windows 10 aktualisiert werden, verfügen nicht über ein TPM, oder das TPM enthält kein Endorsement-Zertifikat. Um diese Geräte zu unterstützen, lässt Windows 10 die Ausstellung von AIK-Zertifikaten ohne das Vorhandensein eines Endorsement-Zertifikats zu. Solche AIK-Zertifikate werden nicht von der Microsoft-Cloud-Zertifizierungsstelle ausgestellt. Beachten Sie, dass dieses Zertifikat weniger vertrauenswürdig als ein Endorsement-Zertifikat ist, das während der Herstellung in das Gerät gebrannt wird, es bietet jedoch Kompatibilität für erweiterte Szenarien wie Microsoft Passport ohne TPM.

Dem ausgestellten AIK-Zertifikat wird eine spezielle OID hinzugefügt, um nachzuweisen, dass das Endorsement-Zertifikat während des Nachweisvorgangs verwendet wurde. Diese Informationen können von einer vertrauende Seite genutzt werden, um zu entscheiden, ob Geräte, die über einen Nachweis in Form von AIK-Zertifikaten ohne Endorsement-Zertifikat verfügen, abgelehnt oder akzeptiert werden. Als weiteres Szenario kann der Zugriff auf hochwertige Ressourcen über Geräten verweigert werden, die über einen Nachweis in Form eines AIK-Zertifikats verfügen, das nicht durch ein Endorsement-Zertifikat unterstützt wird.

Storage Root Key

Der Storage Root Key (SRK) ist auch ein asymmetrisches Schlüsselpaar (RSA mit einer Länge von mindestens 2048 Bit). Der SRK hat eine wichtige Rolle und dient zum Schutz von TPM-Schlüsseln, damit diese Schlüssel nicht ohne das TPM verwendet werden können. Der SRK-Schlüssel wird erstellt, wenn das TPM in Besitz genommen wird.

Plattformkonfigurationsregister

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

Die Messung der Startsequenz basiert auf dem PCR und TCG-Protokoll. Zum Herstellen eines statischen Vertrauensankers beim Gerätestart muss das Gerät in der Lage sein, den Firmwarecode vor der Ausführung zu messen. In diesem Fall wird das CRTM (Core Root of Trust for Measurement) beim Start ausgeführt, berechnet den Hash der Firmware, speichert ihn dann durch die Erweiterung des Registers „PCR[0]“ und überträgt die Ausführung an die Firmware.

PCRs werden beim Start der Plattform auf NULL gesetzt, und die Aufgabe der Firmware, die die Plattform startet, ist das Messen von Komponenten in der Startkette und das Aufzeichnen der Messungen in den PCRs. In der Regel nehmen Startkomponenten den Hash der nächsten auszuführenden Komponente und erfassen die Messungen in den PCRs. Der ersten Komponente in der Messungskette wird implizit vertraut. Dies ist das CRTM. Plattformhersteller müssen über einen sicheren Updateprozess für das CRTM verfügen, andernfalls dürfen sie keine Updates zulassen. Die PCRs zeichnen einen kumulativen Hash der gemessenen Komponenten auf.

Der Wert eines einzelnen PCRs ist schwierig zu interpretieren (es ist nur ein Hashwert), Plattformen protokollieren jedoch in der Regel Details von Messungen, und die PCRs stellen lediglich sicher, dass das Protokoll nicht manipuliert wurde. Die Protokolle werden als TCG-Protokoll bezeichnet. Bei jeder Erweiterung eines Register-PCRs wird dem TCG-Protokoll ein Eintrag hinzugefügt. Daher wird während des gesamten Startvorgangs eine Ablaufverfolgung des ausführbaren Code und der Konfigurationsdaten im TCG-Protokoll erstellt.

TPM-Bereitstellung

Damit das TPM eines Windows 10-basierten Geräts verwendet werden kann, muss es zunächst bereitgestellt werden. Der Bereitstellungsprozess unterscheidet basierend auf TPM-Versionen etwas; wenn er jedoch erfolgreich ist, können das TPM verwendet und die Besitzerautorisierungsdaten (OwnerAuth) für das TPM lokal in der Registrierung gespeichert werden.

Nach der TPM-Bereitstellung versucht Windows 10 zunächst, den EK und lokal gespeicherte OwnerAuth-Werte in der Registrierung unter folgendem Speicherort zu ermitteln: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Endorsement

Das Gerät muss während des Bereitstellungsprozesses möglicherweise neu gestartet werden.

Beachten Sie, dass das PowerShell-Cmdlet Get TpmEndorsementKeyInfo mit Administratorrechten zum Abrufen von Informationen zum Endorsement Key und der Zertifikate des TPMs verwendet werden kann.

Wenn die TPM-Besitzrechte nicht bekannt sind, der EK jedoch vorhanden ist, stellt die Clientbibliothek das TPM bereit und speichert den resultierenden OwnerAuth-Wert in der Registrierung. Wenn die Richtlinie es zulässt, speichert sie den öffentlichen SRK-Teil unter folgendem Pfad: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\Admin\SRKPub .

Im Rahmen des Bereitstellungsprozesses erstellt Windows 10 mit dem TPM einen AIK. Sobald dieser Vorgang ausgeführt wurde, wird der öffentliche Teil des resultierenden AIK in der Registrierung unter folgendem Pfad gespeichert: HKLM\SYSTEM\CurrentControlSet\Services\TPM\WMI\WindowsAIKPub.

Hinweis  

Für die Bereitstellung von AIK-Zertifikaten und das Filtern des Internetzugriffs müssen Sie die folgende Platzhalter-URL autorisieren: https://*.microsoftaik.azure.net.

 

CSP für den Integritätsnachweis unter Windows 10

Windows 10 enthält einen CSP (Konfigurationsdienstanbieter), der auf die Interaktion mit dem Integritätsnachweisfeatures spezialisiert ist. Ein CSP ist eine Komponente, die an den Windows-MDM-Client angeschlossen wird und ein veröffentlichtes Protokoll für die Konfiguration von Einstellungen und die Verwaltung von Windows-basierten Geräten durch MDM-Server bereitstellt. Das Verwaltungsprotokoll wird als Struktur dargestellt, die als URIs mit Funktionen zur Ausführung für URIs angegeben werden kann, z. B. „GET“, „SET, „DELETE“ usw.

Nachfolgend finden eine Liste der Funktionen, die vom CSP für den Integritätsnachweis unter Windows 10 ausgeführt werden:

• Erfassung von Daten zur Überprüfung des Integritätsstatus eines Geräts

• Weiterleitung der Daten an den Integritätsnachweisdienst

• Bereitstellung des vom Integritätsnachweisdienst erhaltenen Integritätsnachweiszertifikats

• Auf Anforderung werden das (vom Integritätsnachweisdienst erhaltene) Integritätsnachweiszertifikat und zugehörige Laufzeitinformationen zur Überprüfung an den MDM-Server weitergeleitet.

Während einer Integritätsnachweissitzung leitet der CSP für den Integritätsnachweis die TCG-Protokolle und während des Startvorgangs gemessenen PCR-Werte über einen sicheren Kommunikationskanal an den Integritätsnachweisdienst weiter.

Wenn MDM-Server überprüft hat, dass ein Gerät vom Integritätsnachweisdienst erkannt wurde, erhält er eine Reihe von Anweisungen und Ansprüche zum Gerätestart und die Bestätigung, dass das Gerät zwischen dem Zeitpunkt des Integritätsnachweises und der Überprüfung durch den MDM-Server nicht neu gestartet wurde.

Windows-Integritätsnachweisdienst (Health Attestation Service)

Die Aufgaben des Windows-Integritätsnachweisdiensts sind im Wesentlichen die Auswertung von Integritätsdaten (TCG-Protokoll und PCR-Werte), eine Reihe von Erkennungen (auf der Grundlage der verfügbaren Integritätsdaten) und das Generieren eines verschlüsselten Integritäts-BLOBs bzw. das Erzeugen eines Berichts für MDM Server.

Hinweis  

Sowohl das Gerät als auch die MDM-Server benötigen Zugriff auf has.spserv.microsoft.com mithilfe des TCP-Protokolls auf Port 443 (HTTPS).

 

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

1. Zunächst muss der Server überprüfen, ob die Berichte von vertrauenswürdigen AIKs signiert wurden. Dazu kann ermittelt werden, ob der öffentliche Teil des AIK in einer Ressourcendatenbank aufgeführt ist, oder ob ein Zertifikat überprüft wurde.

2. Nachdem der Schlüssel überprüft wurde, sollte sichergestellt werden, dass der signierte Nachweis (eine Angebotsstruktur) eine gültige Signatur über PCR-Werte ist.

3. Als Nächstes sollten die Protokolle überprüft werden, um sicherzustellen, dass sie mit den gemeldeten PCR-Werten übereinstimmen.

4. Abschließend sollten die Protokolle selbst von einer MDM-Lösung geprüft werden, um festzustellen, ob sie bekannte oder gültige Sicherheitskonfigurationen darstellen. Mit einer einfachen Überprüfung kann z. B. festgestellt werden, ob die gemessenen frühen Betriebssystemkomponenten als vertrauenswürdig bekannt sind, dass sich der ELAM-Treiber erwartungsgemäß verhält, und dass die ELAM-Treiberdateirichtlinie auf dem neuesten Stand ist. Wenn alle diese Tests erfolgreich sind, kann eine Nachweisanweisung ausgegeben werden, anhand deren später bestimmt wird, ob der Client Zugriff auf eine Ressource erhalten soll.

Der Integritätsnachweisdienst stellt einer MDM-Lösung folgende Informationen über den Zustand des Geräts bereit:

• Aktivierung von „Sicherer Start“

• Aktivierung von Start- und Kerneldebugging

• Aktivierung von BitLocker

• VSM aktiviert

• Messung der signierten oder unsignierten Richtlinie für Device Guard-Codeintegrität

• ELAM geladen

• Start im abgesicherten Modus, DEP-Aktivierung, Aktivierung der Testsignierung

• Bereitstellung des Geräte-TPMs mit einem vertrauenswürdigen Endorsement-Zertifikat

Informationen zur Vollständigkeit der Messungen finden Sie unter CSP für den Integritätsnachweis.

Die folgende Tabelle enthält einige wichtige Aspekte, die abhängig vom Typ des Windows 10-basierten Geräts an das MDM gemeldet werden können.

Betriebssystemtyp	Wichtige Aspekte, die gemeldet werden können
Windows 10 Mobile	PCR0-Messung „Sicherer Start“ aktiviert Datenbank (db) für „Sicherer Start“ ist Standard Datenbank (dbx) für „Sicherer Start“ ist auf dem neuesten Stand GUID der Richtlinie für „Sicherer Start“ ist Standard Geräteverschlüsselung aktiviert Zeitstempel/Version der Sperrliste für Codeintegrität ist auf dem neuesten Stand
Windows 10-Desktopeditionen	PCR0-Messung „Sicherer Start“ aktiviert Datenbank (db) für „Sicherer Start“ entspricht Erwartungen Datenbank (dbx) für „Sicherer Start“ ist auf dem neuesten Stand GUID der Richtlinie für „Sicherer Start“ entspricht Erwartungen BitLocker aktiviert Virtualisierungsbasierte Sicherheit aktiviert ELAM wurde geladen Codeintegritätsversion ist auf dem neuesten Stand Hash der Codeintegritätsrichtlinie entspricht Erwartungen

 

Nutzung von MDM und dem Integritätsnachweisdienst

Um der Geräteintegrität Nachdruck zu verleihen, wertet die MDM-Lösung den Integritätsbericht aus und ist gemäß den Geräteintegritätsanforderungen des Unternehmens konfiguriert.

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

1. Gerät mit aktiviertem Integritätsnachweis Dieser wird in der Regel als Teil der Registrierung bei einem MDM-Anbieter aktiviert (der Integritätsnachweis ist standardmäßig deaktiviert).

2. Nach der Aktivierung und bei jedem nachfolgenden Startvorgang sendet das Gerät Integritätsmessungen an den Microsoft gehosteten Integritätsnachweisdienst und erhält im Gegenzug ein Integritätsnachweis-BLOB.

3. Danach kann ein MDM-Server das Integritätsnachweis-BLOB jederzeit vom Gerät anfordern und den Integritätsnachweisdienst dazu auffordern, den Inhalt zu entschlüsseln und den Nachweis zu überprüfen.

Die Interaktion zwischen einem Windows 10-basierten Gerät, dem Integritätsnachweisdienst und MDM kann folgendermaßen durchgefü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 könnte zu diesem Zeitpunkt Integritätsnachweisdaten mithilfe des entsprechenden CSP-URI anfordern.

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

3. Der Client sendet dann die Nonce im AIK-Angebot, den Startzähler und die Integritäts-BLOB-Informationen. Dieses Integritäts-BLOB ist mit einem öffentlichen HAS (Health Attestation Service)-Schlüssel verschlüsselt, den nur der Integritätsnachweisdienst (Health Attestation Service) entschlüsseln kann.

4. Der MDM-Server:

   1. Stellt sicher, dass sich die Nonce erwartungsgemäß verhält.

   2. Leitet die Daten im Angebot, die Nonce und das verschlüsselte Integritäts-BLOB an den Server des Integritätsnachweisdiensts weiter.

5. Der Integritätsnachweisdienst:

   1. Entschlüsselt das Integritäts-BLOB.

   2. Stellt mithilfe des AIK im Integritäts-BLOB sicher, dass der Startzähler im Angebot richtig ist und dem Wert im Integritäts-BLOB entspricht.

   3. Stellt sicher, dass die Nonce im Angebot mit der vom MDM weitergegebenen übereinstimmt.

   4. Da der Startzähler und die Nonce mit den AIK aus dem Integritäts-BLOB angegeben werden, wird auch nachgewiesen, dass es sich um das Gerät handelt, für das das Integritäts-BLOB generiert wurde.

   5. Sendet Daten an den MDM-Server zurück, u. a. Integritätsparameter, Aktualität usw.

Hinweis  

Der MDM-Server (vertrauende Seite) führt Überprüfung des Angebots oder des Startzähler nie selbst durch. Er ruft die Daten im Angebot und das (verschlüsselte) Integritäts-BLOB ab und sendet die Daten zur Überprüfung an den Integritätsnachweisdienst. Auf diese Weise ist der AIK niemals für das MDM, und es wird Bedenken hinsichtlich des Datenschutzes vorgebeugt.

 

Das Festlegen der Anforderungen bezüglich der Gerätekompatibilität ist der erste Schritt, um sicherzustellen, dass registrierte Geräte, die den Integritäts- und Complianceanforderungen nicht entsprechen, erkannt werden, und dass die MDM-Lösung Aktionen erzwingt.

Wenn Geräte 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. Für eine umfassende Effizienz muss eine End-to-End-Sicherheitslösung Konsequenzen für fehlerhafte Geräte durchsetzen, z. B. das Verweigern des Zugriffs auf hochwertige Ressourcen. Dies ist der Zweck der Steuerung des bedingten Zugriffs, der im nächsten Abschnitt ausführlich erläutert wird.

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

Bei der heutigen Zugriffssteuerungstechnologie geht es in den meisten Fällen um die Sicherzustellung, dass die richtigen Personen Zugriff auf die richtigen Ressourcen erhalten. Wenn Benutzer authentifizieren können, erhalten sie Zugriff auf Ressourcen mit einem Gerät, über das den IT-Mitarbeitern und -Systemen des Unternehmens sehr wenig bekannt ist. Möglicherweise wird überprüft, ob ein Gerät verschlüsselt ist, bevor der E-Mail-Zugriff gewährt wird, aber was geschieht, wenn das Gerät mit Schadsoftware infiziert ist?

Der Prozess zum Remote-Nachweis über Geräteintegrität überprüft den Integritätszustand des Geräts anhand von gemessenen Startdaten. Die Integrität des Geräts ist dann für eine MDM-Lösung wie Intune verfügbar.

Hinweis  

Aktuelle Informationen zur Unterstützung von Intune und Windows 10-Features finden Sie im Microsoft Intune-Blog sowie unter Neuheiten in Microsoft Intune.

 

Die folgende Abbildung zeigt die erwartete Interoperation des Integritätsnachweisdiensts mit dem cloudbasierten Intune-MDM-Dienst von Microsoft.

Eine MDM-Lösung kann anschließend Deklarationen zum Integritätszustand nutzen und auf der nächsten Ebene mit Clientrichtlinien kombinieren, mit denen bedingter Zugriff gewährt werden kann. Dies erfolgt basierend auf der Fähigkeit des Geräts, Folgendes nachzuweisen: es ist schadsoftwarefrei, das Antischadsoftware-System ist funktionsfähig und auf dem neuesten Stand, die Firewall wird ausgeführt, und der Gerätpatchstatus ist kompatibel.

Schließlich können Ressourcen geschützt werden, indem Endgeräten, die ihre Integrität nicht nachweisen können, der Zugriff verweigert wird. Diese Feature wird dringend für BYOD-Geräte benötigt, die auf Unternehmensressourcen zugreifen müssen.

Integrierte MDM-Unterstützung unter Windows 10

Windows 10 verfügt über einen MDM-Client, der als Teil des Betriebssystems ausgeliefert wird. Dies ermöglicht MDM-Server das Verwalten von Windows 10-basierten Geräten ohne separaten Agent.

Unterstützung von MDM-Servern von Drittanbietern

MDM-Server von Drittanbietern können Windows 10 mithilfe des MDM-Protokolls verwalten. Der integrierte Verwaltungsclient kann mit einem kompatiblen Server kommunizieren, der das OMA-DM-Protokoll unterstützt, um Unternehmensverwaltungsaufgaben durchzuführen. Zusätzliche Informationen finden Sie unter Azure Active Directory-Integration mit MDM.

Hinweis  

MDM-Server müssen keinen Client zur Verwaltung von Windows 10 erstellen oder herunterladen. Weitere Informationen finden Sie unter Mobile Geräteverwaltung.

 

Der MDM-Server des Drittanbieters weist bei der Registrierung dieselbe konsistente Oberfläche wie bei Erstanbietern auf; so wird für Benutzer von Windows 10 eine problemlose Verwendung sichergestellt.

Verwaltung von Windows Defender durch ein Drittanbieter-MDM

Diese Verwaltungsinfrastruktur ermöglicht es IT-Spezialisten, mit MDM-fähigen Produkten wie Intune den Integritätsnachweis, Device Guard oder Windows Defender auf Windows 10-basierten Geräten zu verwalten, einschließlich BYODs, die keiner Domäne beigetreten sind. IT-Spezialisten können alle Aktionen und Einstellungen verwalten und konfigurieren, mit deren Anpassung sie vertraut sind, indem sie Intune mit Intune Endpoint Protection auf älteren Betriebssystemversionen verwenden. Für Administratoren, die derzeit nur in Domänen eingebundene Geräte über eine Gruppenrichtlinie verwalten, ist der Übergang zum Verwalten von Windows 10-basierten Geräten mit MDM einfach, da viele der Einstellungen und Aktionen für beide Mechanismen verwendet werden.

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

Steuerung des bedingten Zugriffs

Auf den meisten Plattformen erfolgt die Geräteregistrierung bei Azure Active Directory (Azure AD) automatisch während der Anmeldung. Die Gerätezustände werden von der MDM-Lösung in Azure AD geschrieben und anschließend von Office 365 (oder einer anderen autorisierten Windows-App, die mit Azure AD interagiert) gelesen, wenn der Client das nächste Mal versucht, auf eine mit Office 365 kompatible Arbeitsauslastung zuzugreifen.

Wenn das Gerät nicht registriert ist, erhält der Benutzer eine Meldung mit Anweisungen zum Registrieren (auch bekannt als Anmelden). Wenn das Gerät nicht kompatibel ist, erhält der Benutzer eine andere Meldung, die ihn auf das DMD-Webportal MDM umleitet, wo er weitere Informationen zum Complianceproblem sowie Lösungsmöglichkeiten findet.

Azure AD authentifiziert den Benutzer und das Gerät, MDM verwaltet die Kompatibilität und Richtlinien für den bedingten Zugriff, und der Integritätsnachweisdienst erstellt anhand einer anerkannten Methode Berichte über die Integrität des Geräts.

Steuerung des bedingten Zugriffs auf Office 365

Azure AD erzwingt Richtlinien für den bedingten Zugriff, um den Zugriff auf Office 365-Dienste zu schützen. Ein Mandantenadministrator kann eine Richtlinie für den bedingten Zugriff erstellen, die den Zugriff auf einen Office 365-Dienst über ein nicht konformes Gerät blockiert. Der Benutzer muss die Geräterichtlinien des Unternehmens einhalten, damit Zugriff auf den Dienst gewährt werden kann. Als Alternative kann der Administrator auch eine Richtlinie erstellen, die erfordert, dass Benutzer einfach ihre Geräte anmelden, um Zugriff auf einen Office 365-Dienst zu erhalten. Richtlinien können auf alle Benutzer eines Unternehmens angewendet oder auf wenige Zielgruppen beschränkt und im Laufe der Zeit erweitert werden, um zusätzliche Zielgruppen einzuschließen.

Wenn ein Benutzer auf einer unterstützen Geräteplattform Zugriff auf einen Office 365-Dienst anfordert, authentifiziert Azure AD den Benutzer sowie das Gerät und gewährt den Zugriff auf den Dienst nur, wenn der Benutzer die für den Dienst festgelegte Richtlinie einhält. Benutzer, die ihr Gerät nicht angemeldet haben, erhalten Anweisungen zur Anmeldung und zur Einhaltung der Richtlinien, um Zugriff auf Office 365-Dienste des Unternehmens zu erhalten.

Wenn ein Benutzer die Anmeldung durchführt, ist das Gerät bei Azure AD registriert und bei einer kompatiblen MDM-Lösung wie Intune angemeldet.

Hinweis  

Microsoft arbeitet mit unabhängigen Softwareherstellern (Independent Software Vendor, ISV) von Drittanbieter-MDMs zusammen, um die automatisierte MDM-Anmeldung und Überprüfungen von richtlinienbasiertem Zugriff zu unterstützen. Die Schritte zum Aktivieren der automatischen MDM-Anmeldung bei Azure AD und Intune sind im Blogbeitrag Windows 10, Azure AD und Microsoft Intune: automatische MDM-Anmeldung über die Cloud.

 

Wenn ein Benutzer ein Gerät erfolgreich anmeldet, wird es vertrauenswürdig. Azure AD bietet einmaliges Anmelden für den Zugriff auf Unternehmensanwendungen und erzwingt eine Richtlinie für bedingten Zugriff, um den Zugriff auf einen Dienst nicht nur bei der ersten Anforderung eines Benutzers zu gewähren, sondern immer, wenn er den Zugriff erneut anfordert.

Dem Benutzer wird der Zugriff auf Dienste verweigert, wenn Anmeldedaten geändert werden, ein Gerät ist verloren geht/gestohlen wird, oder wenn die Compliancerichtlinien zum Zeitpunkt der Anforderung der Erneuerung nicht erfüllt wird.

Je nach Typ der E-Mail-Anwendung, die Mitarbeiter für den Onlinezugriff auf Exchange verwenden, kann sich der Pfad zum Einrichten des sicheren Zugriffs auf E-Mail geringfügig unterscheiden. Die Hauptkomponenten – Azure AD, Office 365/Exchange Online und Intune – sind dieselben. Die Oberflächen für IT-Mitarbeiter und Endbenutzer sind sich ebenfalls ähnlich.

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

• Wird das Gerät wird von einem MDM verwaltet?

• Ist das Gerät bei Azure AD registriert?

• Ist das Gerät kompatibel?

Um einen kompatiblen Zustand zu erhalten, muss das Windows 10-basierten Gerät folgende Bedingungen erfüllen:

• Anmeldung bei einer MDM-Lösung an

• Registrierung bei Azure AD

• Einhaltung der von der MDM-Lösung festgelegten Geräterichtlinien

Hinweis  

Derzeit werden Richtlinien für den bedingten Zugriff selektiv für Benutzer mit iOS- und Android-Geräte erzwungen. Weitere Informationen finden Sie im Blogbeitrag Azure AD, Microsoft Intune und Windows 10 – unter Verwendung der Cloud zum Modernisieren der Unternehmensmobilität!.

 

Steuerung des bedingten Zugriffs auf Cloud- und lokale Apps

Die Steuerung des bedingten Zugriffs ist ein leistungsstarkes Modul zur Richtlinienauswertung, das in Azure AD integriert ist. Es bietet IT-Spezialisten eine einfache Möglichkeit zum Erstellen von Zugriffsregeln über Office 365 hinaus, die den Kontext der Anmeldung eines Benutzers auswerten, um in Echtzeit Entscheidungen darüber zu treffen, auf welche Anwendungen der Zugriff gewährt werden soll.

IT-Spezialisten können Richtlinien für den bedingten Zugriff für SaaS-Anwendungen erstellen, die durch Azure AD gesichert sind, und sogar für lokale Anwendungen. Zugriffsregeln in Azure AD nutzen das Modul für bedingten Zugriff, um den Geräteintegritäts- und Compliance-Zustand des Geräts zu überprüfen, der von einer kompatiblen MDM-Lösung wie Intune gemeldet wird, um zu bestimmen, ob der Zugriff gewährt wird.

Weitere Informationen zum bedingten Zugriff finden Sie unter Bedingter Zugriff unter Azure – Vorschau für SaaS-Apps.

Hinweis  

Die Steuerung des bedingten Zugriffs ist ein Azure AD Premium-Feature, das auch mit EMS verfügbar ist. Wenn Sie kein Azure AD Premium-Abonnement besitzen, finden Sie auf der Microsoft Azure-Website eine Testversion.

 

Für lokale Anwendungen gibt es zwei Optionen, um die Steuerung des bedingten Zugriffs basierend auf dem Compliancezustands eines Geräts zu aktivieren:

• Für lokale Anwendungen, die über den Azure AD-Anwendungsproxy veröffentlicht werden, können Sie Richtlinien für den bedingten Zugriff genau wie für Cloudanwendungen konfigurieren. Weitere Details finden Sie im Blogbeitrag Update der Vorschau auf den bedingten Zugriff auf Azure AD: Unterstützung von lokalen und benutzerdefinierten Branchen-Apps.

• Darüber hinaus synchronisiert Azure AD Connect Informationen zur Gerätecompliance aus Azure AD mit dem lokalen AD. ADFS unter Windows Server Technical Preview 2016 unterstützt die Steuerung des bedingten Zugriffs basierend auf dem Compliancezustand eines Geräts. IT-Spezialisten konfigurieren in ADFS Richtlinien zur Steuerung des bedingten Zugriffs, die den von einer kompatiblen MDM-Lösung gemeldeten Compliancezustand des Geräts verwenden, um lokale Anwendungen zu sichern.

Der folgende Prozess beschreibt die Funktionsweise des bedingten Zugriffs von Azure AD:

1. Der Benutzer hat sich bereits über den Arbeitsplatzzugriff/Azure AD-Beitritt beim MDM angemeldet, d. h. das Gerät ist bei Azure AD registriert.

2. Wenn das Gerät gestartet oder aus dem Ruhezustand reaktiviert wird, wird die Aufgabe „Tpm-HASCertRetr“ ausgelöst, um im Hintergrund ein Integritätsnachweis-BLOB anzufordern. Das Gerät sendet TPM-Startmessungen an den Integritätsnachweisdienst.

3. Der Integritätsnachweisdienst überprüft den Gerätestatus und stellt anhand des Integritätsstatus ein verschlüsseltes BLOB mit Details zu fehlgeschlagenen Tests (sofern vorhanden) an das Gerät aus.

4. Der Benutzer meldet sich an, und der MDM-Agent kontaktiert den Intune/MDM-Server.

5. Der MDM-Server übergibt ggf. neue Richtlinien und fragt den Status des Integritäts-BLOBs und andere Bestandsstatus ab.

6. Das Gerät sendet ein zuvor abgerufenes Integritätsnachweis-BLOB und den Wert der anderen Bestandsstatus, die von Intune/MDM-Server angefordert wurden.

7. Der Intune/MDM-Server sendet das Integritätsnachweis-BLOB zur Überprüfung an den Integritätsnachweisdienst.

8. Der Integritätsnachweisdienst stellt die Fehlerfreiheit des Geräts sicher, von dem das Integritätsnachweis-BLOB gesendet wurde, und gibt dieses Ergebnis an den Intune/MDM-Server zurück.

9. Der Intune/MDM-Server wertet die Compliance basierend auf den vom Gerät abgefragten Bestands-/Integritätsnachweisstaus aus.

10. Der Intune/MDM-Server aktualisiert den Compliancestatus für das Geräteobjekt in Azure AD.

11. Der Benutzer öffnet die App und versucht, auf eine vom Unternehmen verwaltete Ressource zuzugreifen.

12. Der Zugriff wird durch eine Compliance-Anforderung in Azure AD abgegrenzt.

13. Wenn das Gerät konform und der Benutzer autorisiert ist, wird ein Zugriffstoken generiert.

14. Der Benutzer kann auf die vom Unternehmen verwaltete Ressource zugreifen.

Weitere Informationen zum Azure AD-Beitritt finden Sie im Whitepaper Microsoft Azure Active Directory and Windows 10: Better Together for Work or School (engl.).

Die Steuerung des bedingten Zugriffs ist ein Thema, über das viele Unternehmen und IT-Spezialisten nicht so gut informiert sind, wie sie sollten. Die verschiedenen Attribute zur Beschreibung eines Benutzers, eines Geräts, von Compliance und Zugriffskontext sind sehr leistungsstark, wenn sie mit einem Modul für bedingten Zugriff verwendet werden. Die Steuerung des bedingten Zugriffs ist ein wichtiger Schritt, der Unternehmen beim Sichern ihrer Umgebung unterstützt.

Erkenntnisse und Zusammenfassung

Die folgende Liste enthält allgemeine wichtige Erkenntnisse zur Verbesserung des Sicherheitsstatus eines Unternehmens. Die in diesem Abschnitt dargestellten wenigen Erkenntnisse sollten jedoch nicht als vollständige Liste aller bewährte Sicherheitsmethoden interpretiert werden.

• Beachten Sie, dass keine Lösung zu 100 Prozent sicher ist.

  Wenn zielstrebige Angreifer mit böswilliger Absicht physischen Zugriff auf das Gerät erlangen, könnten sie letztendlich die Sicherheitsebenen umgehen und das Gerät steuern.

• Integritätsnachweis mit einer MDM-Lösung verwenden

  Wenn Geräte versuchen, eine Verbindung mit hochwertigen Ressourcen herzustellen, muss deren Integrität ausgewertet werden, damit fehlerhafte und nicht kompatible Geräte erkannt und gemeldet werden können.

• Credential Guard verwenden

  Credential Guard ist ein Feature, das erheblich zum Schutz von Anmeldeinformationen für Unternehmensdomänen vor Pass-the-Hash-Angriffen beiträgt.

• Device Guard verwenden

  Device Guard ist ein echter Fortschritt in der Sicherheit und eine effektive Möglichkeit zum Schutz vor Schadsoftware. Das neue Device Guard-Feature unter Windows 10 blockiert nicht vertrauenswürdige Apps (Apps, die nicht von Ihrem Unternehmen autorisiert wurden).

• Device Guard-Richtlinie signieren

  Die signierte Device Guard-Richtlinie trägt zum Schutz vor einem Benutzer mit Administratorrechten bei, der versucht, die aktuelle Richtlinie zu bezwingen. Bei einer signierten Richtlinie ist die einzige Möglichkeit zum späteren Ändern von Device Guard das Bereitstellen einer neuen Version der Richtlinie, die vom selben Signaturgeber oder einem Signaturgeber signiert ist, der als Teil der Device Guard-Richtlinie angegeben ist.

• Virtualisierungsbasierte Sicherheit verwenden

  Wenn die Kernelmodus-Codeintegrität durch virtualisierungsbasierte Sicherheit geschützt ist, werden die Codeintegritätsregeln auch dann weiterhin durchgesetzt, wenn ein Sicherheitsrisiko den nicht autorisierten Zugriff auf Kernelmodusspeicherzugriff zulässt. Bedenken Sie, dass Device Guard-Geräte, die Kernelcodeintegrität mit virtualisierungsbasierter Sicherheit ausführen, über kompatible Treiber verfügen müssen.

• Device Guard mit Überwachungsmodus neu bereitstellen

  Stellen Sie die Device Guard-Richtlinie auf Zielcomputern und -geräten im Überwachungsmodus bereit. Überwachen Sie das Codeintegritäts-Ereignisprotokoll, das angibt, dass ein Programm oder ein Treiber bei einer Konfiguration von Device Guard im Erzwingungsmodus gesperrt würde. Passen Sie Device Guard-Regeln so an, dass ein hohes Maß an Zuverlässigkeit erzielt wird. Nach Abschluss der Testphase kann für die Device Guard-Richtlinie der Erzwingungsmodus aktiviert werden.

• Erstellen eines isolierten Referenzcomputers bei der Bereitstellung von Device Guard

  Da das Unternehmensnetzwerk Schadsoftware enthalten kann, sollten Sie zunächst eine Referenzumgebung konfigurieren, die von Ihrem Hauptunternehmensnetzwerk isoliert ist. Anschließend können Sie eine Richtlinie für Codeintegrität mit den vertrauenswürdigen Anwendungen erstellen, die Sie auf Ihren geschützten Geräten ausführen möchten.

• Verwenden Sie AppLocker, wenn dies sinnvoll ist.

  Obwohl AppLocker nicht als neues Device Guard-Feature gilt, ergänzt es die Device Guard-Funktionen für einige Szenarien, z. B. durch die Fähigkeit, einem bestimmten Benutzer oder einer Benutzergruppe den Zugriff auf eine bestimmte universelle Windows-Apps zu verweigern.

• Sperren der Firmware und Konfiguration

  Sperren Sie nach der Installation von Windows 10 den Zugriff auf Firmware-Startoptionen. Dadurch wird verhindert, dass ein Benutzer mit physischem Zugriff UEFI-Einstellungen ändert, den sicheren Start deaktiviert oder andere Betriebssysteme startet. Außerdem können Sie zum Schutz vor einem Administrator, der versucht, Device Guard zu deaktivieren, der aktuellen Device Guard-Richtlinie eine Regel hinzufügen, die die Ausführung des Tools C:\Windows\System32\SecConfig.efi verweigert und blockiert.

Der Integritätsnachweis ist ein wichtiges Feature von Windows 10. Es enthält Client- und Cloudkomponenten zur Steuerung des Zugriffs auf hochwertige Ressourcen basierend auf der Identität eines Benutzer und seines Geräts sowie der und Einhaltung der Verwaltungsrichtlinie des Unternehmens. Unternehmen können entweder fehlerhafte Geräte erkennen und melden oder basierend auf ihren Anforderungen Regeln zur Integritätserzwingung konfigurieren. Der Integritätsnachweis bietet ein End-to-End-Sicherheitsmodell und Integrationspunkte, die Anbieter und Softwareentwickler zum Erstellen und Integrieren einer benutzerdefinierten Lösung verwenden können.

Verwandte Themen

Credential Guard

Device Guard-Bereitstellungshandbuch

Trusted Platform Module – Technologieübersicht