Device Guard-Bereitstellungshandbuch

Microsoft Device Guard ist eine Featuregruppe, die aus Hardware- und Softwaresystem-Integritätshärtungsfeatures besteht, die die Sicherheit des Windows-Betriebssystems revolutionieren. Windows 10 verwendet sowohl Device Guard als auch die Codeintegrität und erweiterte Hardwarefeatures wie CPU-Virtualisierungserweiterungen, Trusted Platform Module und die Adressübersetzung der zweiten Ebene (Second-Level Address Translation, SLAT), um seinen Benutzern eine umfassende moderne Sicherheit zu bieten. In diesem Handbuch werden die einzelnen Features in Device Guard untersucht, und es wird ihre Planung, Konfiguration und Bereitstellung beschrieben.

Device Guard-Einführung

Anhand der heutigen Landkarte mit den Sicherheitsbedrohungen wird ersichtlich, dass die Bedrohungen aggressiver als je zuvor sind. Moderne Schadsoftwareangriffe konzentrieren sich auf die Umsatzgenerierung, den Diebstahl geistigen Eigentums und die Zersetzung des Zielsystems, was zu finanziellen Verlusten führen kann. Viele dieser modernen Angreifer werden durch Nationen, die über unbekannte Motive verfügen, und große Internetterrorismusbudgets finanziert. Diese Bedrohungen können durch simple Methoden in ein Unternehmen gelangen. Dazu genügt schon eine einfache E-Mail. Sie können dauerhaft den Ruf hinsichtlich der Sicherung der zugehörigen Softwareressourcen schädigen und sich finanziell negativ auswirken. Windows 10 führt verschiedene neue Sicherheitsfeatures ein. Diese helfen dabei, einen großen Prozentsatz der heute bekannten Bedrohungen zu minimieren.

Es wird geschätzt, dass mehr als 300.000 neue Schadsoftwarevarianten täglich ermittelt werden. Leider verwenden die Unternehmen derzeit eine antike Methode, um diese Schadsoftware zu ermitteln und ihre Verwendung zu verhindern. Tatsächlich vertrauen aktuelle PCs jeder Anwendung, die ausgeführt wird, bis anhand der Schadsoftwaresignaturen ermittelt wird, ob eine Bedrohung vorhanden ist. Anschließend versucht die Antischadsoftware, den PC zu bereinigen, und zwar oftmals nachdem die Auswirkung der Schadsoftware festgestellt wurde. Dieses signaturbasierte System konzentriert sich darauf, auf eine Infektion zu reagieren, und darauf, sicherzustellen, dass die bestimmte Infektion nicht erneut erfolgt. In diesem Modell verlässt sich das System, das die Schadsoftwareerkennung steuert, auf das Feststellen der Schadsoftware. Nur in diesem Fall kann dem Client eine Signatur bereitgestellt werden, um das Problem zu beheben. Demzufolge muss ein Computer zunächst infiziert werden. Die Zeit, die zwischen dem Feststellen der Schadsoftware und der Ausstellung einer Signatur an den Client vergeht, könnte den Unterschied zwischen Datenverlust und Sicherheit ausmachen.

Zusätzlich zu den Antischadsoftwarelösungen stehen einige Whitelist-Technologien wie AppLocker zur Verfügung. Diese Technologien führen Einzelinstanz-, oder pauschale Zulassungs- oder pauschale Verweigerungsregeln für das Ausführen von Anwendungen aus. Auch wenn dies eine vorbeugendere Methode als die signaturbasierte Ermittlung darstellt, erfordert dieser Ansatz eine erheblich kontinuierliche Wartung. In Windows 10 sind diese Anwendungen am effektivsten, wenn sie zusammen mit Microsoft Device Guard bereitgestellt werden.

Device Guard bricht das aktuelle Modell der Ermittlung zunächst um, blockiert sie später und ermöglicht nur die Ausführung von vertrauenswürdigen Anwendungen. Diese Methodologie ist einheitlich mit der erfolgreichen Verhinderungsstrategie für die Mobiltelefonsicherheit. Mit Device Guard hat Microsoft die Art und Weise geändert, wie das Windows-Betriebssystem nicht vertrauenswürdige Anwendungen verarbeitet. Dadurch kann Schadsoftware die Abwehr schwieriger durchdringen. Diese neue Verhinderung gegenüber dem Modell der Ermittlung bietet Windows-Clients die nötige Sicherheit gegen moderne Bedrohungen, und sobald die Implementierung erfolgt ist, sind die heutigen Bedrohungen von Anfang an veraltet.

Die Features von Device Guard revolutionieren die Sicherheit des Windows-Betriebssystems, indem von den neuen Optionen für die virtualisierungsbasierte Sicherheit (VBS) und dem nichts trauenden Mobilgerät-Betriebssystemmodell profitiert wird, wodurch das Durchdringen der Abwehrreihen durch Schadsoftware weiteraus komplizierter wird. Mithilfe von konfigurierbaren Codeintegritätsrichtlinien können Organisationen exakt auswählen, welche Anwendungen in ihrer Umgebung ausgeführt werden dürfen. Die konfigurierbare Codeintegrität ist nicht auf Windows Store-Anwendungen begrenzt und kann für nicht signierte oder signierte Win32-Anwendungen ohne die Anforderung verwendet werden, dass die Anwendung umgepackt werden muss. Zusätzlich kann die konfigurierbare Codeintegrität als ein einzelnes Feature bereitgestellt werden, wenn Organisationen die erforderliche Hardware für Device Guard nicht besitzen. Zusammen mit der Codeintegrität verwendet Windows 10 erweiterte Hardwarefeatures wie CPU-Virtualisierungserweiterungen, Arbeitsspeicherverwaltungseinheiten für die Eingabe/Ausgabe (Input/Output Memory Management Unit, IOMMUs), Trusted Platform Module und die Adressübersetzung der zweiten Ebene (Second-Level Address Translation, SLAT), um seinen Benutzern eine umfassende moderne Sicherheit zu bieten. Wenn Device Guard mit konfigurierbare Codeintegrität und Credential Guard bereitgestellt wird, bedeutet dies die wirksamsten clientseitigen Sicherheitsbereitstellungen, die eine Organisation heutzutage implementieren kann. In diesem Handbuch erhalten Sie Informationen über die einzelnen Features in Device Guard und darüber, wie Sie sie planen, konfigurieren und bereitstellen. Device Guard mit konfigurierbarer Codeintegrität ist für die Bereitstellung mit zusätzlichen die Bedrohung minimierenden Windows-Features wie Credential Guard und AppLocker gedacht.

Device Guard – Überblick

Bei Device Guard handelt es sich um eine Featuregruppe, die aus Hardware- und Softwaresystemintegritäts-Härtungsfeatures besteht. Diese Features revolutionieren die Sicherheit des Windows-Betriebssystems, indem von den neuen Optionen für die virtualisierungsbasierte Sicherheit (VBS) und dem nichts trauenden Mobilgerät-Betriebssystemmodell profitiert wird. Ein Hauptfeature in diesem Modell wird als konfigurierbare Codeintegrität bezeichnet. Mit diesem kann Ihre Organisation exakt auswählen, welche Software oder Software von vertrauenswürdigen Herausgebern Code auf Ihren Clientcomputern ausführen kann – also genau das, was die Mobiltelefonsicherheit so erfolgreich gemacht hat. Zusätzlich bietet Device Guard Organisationen eine Möglichkeit, vorhandene Branchenanwendungen zu signieren, sodass sie ihrem eigenen Code vertrauen können, und zwar ohne dass die Anwendung umgepackt werden muss. Mit dieser gleichen Signierungsmethode erhalten Organisationen zudem eine Möglichkeit, einzelnen Drittanbieteranwendungen zu vertrauen. Device Guard (mit konfigurierbarer Codeintegrität, Credential Guard und AppLocker) ist die umfassendste Sicherheitslösung, die ein Microsoft-Produkt jemals für einen Client unter Windows anbieten konnte.

Erweiterte Hardwarefeatures wie CPU-Virtualisierungserweiterungen, IOMMUs und SLAT unterstützen dabei diese neuen Clientsicherheitsangebote. Durch die stärkere Integration dieser Hardwarefeatures in das Kernbetriebssystem, kann Windows 10 sie auf neue Art und Weise verwenden. Beispielsweise wird dieselbe Typ-1-Hypervisor-Technologie, die zum Ausführen von virtuellen Computern in Microsoft Hyper-V verwendet wird, verwendet, um wichtige Windows-Dienste in einem virtualisierungsbasierten, geschützten Container zu isolieren. Dies ist nur ein Beispiel, wie Windows 10 die erweiterten Hardwarefeatures besser im Betriebssystem integriert, um seinen Benutzern eine umfassende moderne Sicherheit zu bieten. Diese Hardwarefeatures sind nun in den Märkten für Heimanwender- und Unternehmens-PCs verfügbar. Sie werden im Abschnitt Hardwareaspekte ausführlich erläutert.

Zusammen mit diesen neuen Features sind einige Komponenten von Device Guard vorhandene Tools oder Technologien, die in diesem strategischen Sicherheitsangebot enthalten sind, um Kunden das möglichst sicherste Windows-Betriebssystem bereitzustellen. Device Guard – eine Clientsicherheits-Featuregruppe – soll mit anderen im Windows-Betriebssystem verfügbaren bedrohungsresistenten Features verwendet werden, wobei einige davon in diesem Handbuch erwähnt werden. In diesem Handbuch wird nicht nur eine Übersicht über jedes Feature gegeben, sondern es wird auch ihre Konfiguration und Bereitstellung beschrieben.

Konfigurierbare Codeintegrität

Das Windows-Betriebssystem besteht aus zwei Betriebsmodi: dem Benutzermodus und dem Kernelmodus. Die Basis des Betriebssystems wird im Kernelmodus ausgeführt. Hier besteht die direkte Schnittstelle zwischen dem Windows-Betriebssystem und den Hardwareressourcen. Der Benutzermodus ist primär verantwortlich für das Ausführen von Anwendungen und Weitergeben von Informationen vom und an den Kernelmodus für Hardwareressourcenanforderungen. Beispielsweise muss, wenn eine im Benutzermodus ausgeführte Anwendung zusätzlichen Arbeitsspeicher benötigt, der Benutzermodusprozess die Ressourcen vom Kernelmodus anfordern und nicht direkt aus dem Arbeitsspeicher.

Bei der Codeintegrität handelt es sich um die Komponente des Windows-Betriebssystems. Sie stellt sicher, dass der Code, der durch Windows ausgeführt wird, vertrauenswürdig und sicher ist. Wie beim Betriebssystem weist die Windows-Codeintegrität ebenfalls zwei primäre Komponenten auf: die Codeintegrität im Kernelmodus (KMCI) und die Codeintegrität im Benutzermodus (UMCI). KMCI wurde in früheren Versionen des Windows-Betriebssystems verwendet, um den Kernelmodus davor zu schützen, dass nicht signierte Treiber ausgeführt werden. Auch wenn dies eine wirksame Maßnahme ist, sind Treiber nicht die einzige Möglichkeit für Schadsoftware, um in den Kernelmodusbereich des Betriebssystems einzudringen. In Windows 10 hat Microsoft jedoch den Standard für den integrierten Kernelmoduscode erhöht. Zudem erhalten Unternehmen darin die Möglichkeit, ihre eigenen UMCI- und KMCI-Standards festzulegen. Microsoft hat Windows 10 sicherer gestaltet als jede Windows-Version zuvor: Dies beginnt mit dem Codeintegritätsdienst an sich und reicht bis zu den von einem Windows-Client verwendeten Richtlinien, um sicherzustellen, dass das Ausführen einer Anwendung zulässig ist. In der Vergangenheit war UMCI nur in Windows RT und auf Windows Phone-Geräten verfügbar. Dadurch konnten diese Geräte nur schwer durch Viren und Schadsoftware infiziert werden. In Windows 10 sind dieselben erfolgreichen UMCI-Standards verfügbar.

In der Vergangenheit war der Großteil der Schadsoftware nicht signiert. Durch das einfache Bereitstellen von Codeintegritätsrichtlinien sind Organisationen sofort in der Lage, sich selbst gegen nicht signierte Schadsoftware zu schützen, was schätzungsweise mehr als 95 % der aktuellen Angriffe ausmacht. Mithilfe von Codeintegritätsrichtlinien kann ein Unternehmen genau auswählen, welche binären Dateien im Benutzer- und im Kernelmodus ausgeführt werden können, und zwar von der Herausgeber- zur Hashebene. Bei vollständiger Erzwingung funktioniert der Benutzermodus in Windows wie ein Mobiltelefon, indem nur bestimmte Anwendungen oder bestimmte Signaturen ausgeführt werden dürfen. Dieses Feature ändert die Sicherheit in einem Unternehmen grundlegend. Diese zusätzliche Sicherheit ist nicht auf Windows-Apps begrenzt. Zudem ist es nicht erforderlich, dass eine Anwendung neu geschrieben wird, um mit Ihren vorhandenen, nicht signierten Anwendungen kompatibel zu sein. Sie können die konfigurierbare Codeintegrität implementieren, ohne Device Guard zu aktivieren. Es ist jedoch vorgesehen, dass sie zusammen mit Device Guard ausgeführt wird, wenn die unterstützte Hardware verfügbar ist. Weitere Informationen über das Konfigurieren, Bereitstellen und Verwalten von Codeintegritätsrichtlinien finden Sie im Abschnitt Richtlinien für die Codeintegrität.

Hardwaresicherheitsfeatures und virtualisierungsbasierte Sicherheit

Die Device Guard-Kernfunktion und der zugehörige Schutz beginnen auf Hardwareebene. Geräte, die über mit SLAT-Technologien und Virtualisierungserweiterungen ausgerüstete Prozessoren verfügen wie Intel Virtualization Technology (VT-x) und AMD-V, können die VBS-Features verwenden, die die Windows-Sicherheit erweitern. Device Guard nutzt VBS, um wichtige Windows-Dienste zu isolieren, die sicherheitskritisch sind und um die Integrität des Betriebssystems aufrechtzuerhalten. Durch diese Isolation wird das Sicherheitsrisiko beseitigt, dem diese Dienste im Benutzer- und Kernelmodus ausgesetzt sind. Sie fungiert zudem als eine nicht überwindbare Grenze für den Großteil der heutigen Schadsoftware. Einer dieser isolierten Dienste, der sogenannte Windows-Codeintegritätsdienst, unterstützt das Feature für die konfigurierbare Codeintegrität des Device Guard-Kernelmodus. Dadurch wird verhindert, dass Code, der in die Kernelmodusvorgänge eingedrungen ist, den Codeintegritätsdienst beeinträchtigt.

Bei der Überwachung von Anmeldeinformationen handelt es sich um ein weiteres Windows 10-Feature, das VBS unterstützt. Credential Guard verfügt über einen zusätzlichen Schutz für Active Directory-Domänenbenutzer. Hierzu werden die Domänenanmeldeinformationen im Virtualisierungscontainer gespeichert, der die Windows-Sicherheitsdienste wie die Codeintegrität hostet. Durch das Isolieren dieser Domänenanmeldeinformationen vom aktiven Benutzer- und Kernelmodus ist das Risiko, dass sie gestohlen werden, weitaus geringer. Weitere Informationen darüber, wie die Überwachung von Anmeldeinformationen Device Guard ergänzt, finden Sie im Abschnitt Device Guard mit Überwachung von Anmeldeinformationen. Informationen über das Aktivieren von Credential Guard finden Sie im Abschnitt Aktivieren von Credential Guard.

Device Guard mit AppLocker

Auch wenn AppLocker nicht als ein neues Device Guard-Feature angesehen wird, ergänzt es die Device Guard-Funktion, wenn die erzwungene Codeintegrität nicht vollständig implementiert wird oder die zugehörige Funktion nicht jedes gewünschte Szenario abdecken kann. Es gibt viele Szenarien, in denen Codeintegritätsrichtlinien zusammen mit AppLocker-Regeln verwendet werden. Als bewährte Vorgehensweise sollten Sie die Codeintegritätsrichtlinien für Ihr Unternehmen nach Möglichkeit auf der restriktivsten Ebene erzwingen. Anschließend können Sie AppLocker verwenden, um die Einschränkungen, auch auf eine niedrigere Ebene, zu optimieren.

Hinweis  Ein Beispiel, in der die Device Guard-Funktion durch AppLocker ergänzt werden muss, besteht darin, wenn Ihre Organisation die Anzahl universeller Anwendungen begrenzen möchte. Universelle Anwendungen wurden bereits durch Microsoft dahingehend überprüft, dass ihrer Ausführung vertraut wird. Eine Organisation möchte jedoch möglicherweise nicht, dass bestimmte universelle Anwendungen in ihrer Umgebung ausgeführt werden. Sie können diese Erzwingung mithilfe einer AppLocker-Regel umsetzen.

 

AppLocker und Device Guard sollten zusammen in Ihrer Organisation ausgeführt werden. Dadurch erhalten Sie nicht nur die bestmöglichen Sicherheitsfeatures gleichzeitig, sondern auch die umfassendste Sicherheit für möglichst viele Geräte. Zusätzlich zu diesen Features empfiehlt Microsoft, dass Sie weiterhin eine Unternehmensantivirenlösung verwenden, um ein angemessenes Unternehmenssicherheitsportfolio zu erhalten.

Device Guard mit Überwachung von Anmeldeinformationen

Auch wenn Credential Guard kein Feature in Device Guard ist, werden viele Organisationen wahrscheinlich Credential Guard zusammen mit Device Guard bereitstellen, um einen zusätzlichen Schutz gegen den Diebstahl von Anmeldeinformationen zu erhalten. Ähnlich wie beim virtualisierungsbasierten Schutz der Kernelmodus-Codeintegrität nutzt Credential Guard die Hypervisor-Technologie, um Domänenanmeldeinformationen zu schützen. Diese Risikominderung zielt darauf ab, die Verwendung von Hashweitergabe- und Ticketweitergabetechniken abzuwehren. Durch das Verwenden der mehrstufigen Authentifizierung mit Credential Guard erhalten Organisationen einen zusätzlichen Schutz gegen solche Bedrohungen. Informationen über das Bereitstellen von Credential Guard auf Ihren Clients unter Windows 10 Enterprise finden Sie im Abschnitt Aktivieren von Credential Guard. Zusätzlich zur clientseitigen Aktivierung von Credential Guard können Organisationen auf Zertifizierungsstellen- und Domänencontrollerebene Risikominderungen bereitstellen, die den Diebstahl von Anmeldeinformationen verhindern sollen. Microsoft stellt künftig Details über diese zusätzlichen Risikominderungen bereit.

Einheitliche Verwaltbarkeit

Sie können die Device Guard-Features einfach verwalten, indem Sie die vertrauten Unternehmens- und Clientverwaltungstools verwenden, die durch IT-Experten täglich verwendet werden. Verwenden Sie die folgenden Verwaltungstools zum Aktivieren und Verwalten von Device Guard:

• Gruppenrichtlinie. Windows 10 enthält eine administrative Vorlage, mit der die konfigurierbaren Richtlinien für die Codeintegrität für Ihre Organisation konfiguriert und bereitgestellt werden können. Mit dieser Vorlage können Sie angeben, welche hardwarebasierten Sicherheitsfeatures aktiviert und bereitgestellt werden sollten. Sie können diese Einstellungen zusammen mit Ihren vorhandenen Gruppenrichtlinienobjekten (Group Policy Objects, GPOs) verwalten, wodurch es ein Leichtes wird, Device Guard-Features zu implementieren. Zusätzlich zu diesen Codeintegritäts- und hardwarebasierten Sicherheitsfeatures können Sie „Gruppenrichtlinie“ verwenden, was Sie beim Verwalten der Katalogdateien unterstützt. Weitere Informationen über Katalogdateien finden Sie im Abschnitt Katalogdateien.

• Microsoft System Center Configuration Manager. Sie können System Center Configuration Manager für die Vereinfachung der Bereitstellung und Verwaltung von Katalogdateien, Codeintegritätsrichtlinien und hardwarebasierten Sicherheitsfeatures sowie für das Bereitstellen der Versionskontrolle verwenden. Weitere Informationen über das Bereitstellen von Katalogdateien mithilfe von System Center Configuration Manager finden Sie im Abschnitt Bereitstellen von Katalogdateien mit System Center Configuration Manager.

• Microsoft Intune. In einer künftigen Version von Microsoft Intune können Organisationen Intune für die Bereitstellung und Verwaltung der Codeintegritätsrichtlinien und Katalogdateien verwenden.

• Windows PowerShell. Die Windows PowerShell wird primär verwendet, um Codeintegritätsrichtlinien zu erstellen und zu warten. Diese Richtlinien stellen die stärkste Komponente von Device Guard dar. Eine schrittweise Anleitung zum Erstellen, Überwachen, Warten, Erzwingen und Bereitstellen von Codeintegritätsrichtlinien finden Sie im Abschnitt Richtlinien für die Codeintegrität.

Diese Optionen stellen eine vertraute Benutzererfahrung bereit, damit Sie Ihre vorhandenen Unternehmensverwaltungslösungen verwalten können. Weitere Informationen über das Verwalten und Bereitstellen von Device Guard-Hardware- und Codeintegritätsfeatures in Ihrer Organisation finden Sie im Abschnitt Device Guard-Bereitstellung.

Device Guard-Planung

In diesem Abschnitt erhalten Sie Informationen über die folgenden Themen:

• Erreichen der Unternehmenscodeintegritäts-Bereitstellung. Für die Device Guard-Bereitstellung in Ihrer Organisation ist ein geplanter Ansatz erforderlich. In diesem Abschnitt erhalten Sie allgemeine Empfehlungen darüber, wie Sie die Unternehmenscodeintegritäts-Bereitstellung in Ihrer Organisation erreichen können.

• Device Guard-Bereitstellungsszenarien. Für das Planen der Device Guard-Bereitstellung empfiehlt Microsoft, dass Sie jedes Gerät in Ihrer Organisation in ein Bereitstellungsszenario kategorisieren. Diese Szenarien stellen eine Roadmap für Ihre Device Guard-Bereitstellung bereit.

• Codesignaturübernahme. Die Codesignatur ist wichtig für die Sicherheit, die durch Device Guard bereitgestellt wird. In diesem Abschnitt werden die Optionen für die Codesignatur sowie die Vor- und Nachteile jeder Methode hervorgehoben.

• Hardwareaspekte. Für verschiedene Device Guard-Features ist eine erweiterte Hardware erforderlich. In diesem Abschnitt werden die Anforderungen für die jeweiligen Features hervorgehoben und wonach während der nächsten Hardwareaktualisierung gesucht werden sollte.

Erreichen der Unternehmenscodeintegritäts-Bereitstellung

Unternehmen, die Device Guard in Erwägung ziehen, sollten nicht von einer Bereitstellung in ihrer gesamten Organisation ausgehen, die über Nacht stattfindet. Für die Device Guard-Implementierung müssen Sie die Auswirkung auf die Endbenutzer und die IT planen. Zusätzlich ist für das Bereitstellen der Device Guard-Features in Ihrem Unternehmen ein geplanter, stufenweiser Ansatz erforderlich, um sicherzustellen, dass die Endbenutzersysteme vollständig kompatibel sind und zum Erzwingen dieser neuen Sicherheitseinschränkungen bereit sind. Führen Sie die folgenden allgemeinen Aufgaben aus, um die Bereitstellung von Device Guard in Ihrem Unternehmen zu erreichen:

1. Gruppieren Sie die Geräte anhand ähnlicher Funktionen. Kategorisieren Sie Computer analog zur Beschreibung im Abschnitt Device Guard-Bereitstellungsszenarien in Gruppen. Dadurch wird die Roadmap für Ihre Device Guard-Bereitstellung begonnen, und es werden Gruppen von einfacher und schwieriger zu verstehenden Implementierungen bereitgestellt. Hier können Sie den Umfang der erforderlichen Device Guard-Richtlinien bewerten. Die einfachste Lösung besteht darin, Ihr gesamtes Unternehmen zu sperren, dies erfüllt jedoch möglicherweise nicht die Anforderungen Ihrer einzelnen Abteilungen.

   Um eine angemessene Anzahl an Richtlinien für Ihre Organisation zu bestimmen, sollten Sie versuchen, die definierten Gruppen in Abteilungen oder Rollen zu trennen. Stellen Sie anschließend einige Fragen: Welche Software benötigt jede einzelne Abteilung oder Rolle, um die entsprechende Aufgabe auszuführen? Sollten sie in der Lage sein, die Software anderer Abteilungen zu installieren und auszuführen? Muss eine Basiscode-Integritätsrichtlinie erstellt werden, die an unseren Anwendungskatalog angeglichen ist? Sollten Benutzer in der Lage sein dürfen, beliebige Anwendungen zu installieren oder nur die aus einer Liste der zugelassenen Anwendungen? Dürfen Benutzer ihre Peripheriegeräte verwenden? Diese Fragen helfen Ihnen beim Ermitteln der Anzahl der erforderlichen Richtlinien für Ihre Organisation. Versuchen Sie abschließend, sich darauf zu konzentrieren, welche Personen oder Abteilungen zusätzliche Berechtigungsstufen benötigen würden. Sollte beispielsweise Abteilung x in der Lage sein, die Anwendung xyz zu installieren und auszuführen, auch wenn dies bei keiner anderen Abteilung der Fall ist. Wenn die Antwort ja lautet und gerechtfertigt ist, benötigen Sie eine sekundäre Codeintegritätsrichtlinie für diese Gruppe. Wenn dies nicht der Fall ist, können Sie wahrscheinlich verschiedene Richtlinien zusammenführen, um die Verwaltung zu vereinfachen. Weitere Informationen über die konfigurierbaren Richtlinien für die Codeintegrität finden Sie im Abschnitt Richtlinien für die Codeintegrität.

2. Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs Nachdem Sie die Gerätegruppen erstellt haben, können Sie die Codeintegritätsrichtlinien so erstellen, dass sie mit diesen Gruppen übereinstimmen, und zwar auf ähnliche Weise, wie Sie Unternehmensimages verwalten würden. Nachdem Sie diese Gruppen getrennt und die goldenen PCs eingerichtet haben, die die Software und Hardware nachahmen, welche für diese einzelnen Gruppen erforderlich sind, erstellen Sie Codeintegritätsrichtlinien von jedem einzelnen von ihnen. Nachdem Sie diese erstellt haben, können Sie diese Codeintegritätsrichtlinien so zusammenführen, um eine Hauptrichtlinie zu erstellen. Alternativ können Sie sie einzeln verwalten und bereitstellen. Schrittweise Anleitungen über das Erstellen von Codeintegritätsrichtlinien finden Sie im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs.

3. Überwachen Sie Codeintegritätsrichtlinien, und führen Sie sie zusammen. Microsoft empfiehlt, dass Sie die Codeintegritätsrichtlinien im Überwachungsmodus testen, bevor Sie sie erzwingen. Im Überwachungsmodus können Administratoren die Codeintegritätsrichtlinie auf einem System ausführen, wobei jedoch tatsächlich nichts blockiert wird. Anstelle die Ausführung von Anwendungen zu verhindern, werden Ereignisse mit jeder Ausnahme zur Richtlinie protokolliert. So können Sie Probleme einfach hervorheben, die während der anfänglichen Überprüfung nicht erkannt wurden. Sie können mithilfe von Überwachungsereignissen zusätzliche Codeintegritätsrichtlinien erstellen und sie in der vorhandenen Richtlinie zusammenführen. Weitere Informationen über das Überwachen von Codeintegritätsrichtlinien finden Sie im Abschnitt Überwachen der Codeintegritätsrichtlinien.

4. Bewerten Sie zurzeit nicht signierte Branchenanwendungen, und erstellen Sie eine Katalogdatei für sie. Mit Katalogdateien können Organisationen Anwendungen signieren, die derzeit nicht über digital signierte binäre Dateien oder Anwendungen verfügen, zu denen ein Kunde möglicherweise eine sekundäre Signatur hinzufügen möchte. Bei diesen Anwendungen kann es sich um interne oder Anwendungen von Drittanbietern handeln, und für den Prozess ist nicht das Umpacken der Anwendung erforderlich. Wenn Sie Codeintegritätsrichtlinien auf einer Regelebene erstellen, die über den Hashwerten liegt, werden Sie keine nicht signierten Anwendungen ermitteln. Um diese Anwendungen in Ihre Codeintegritätsrichtlinien einzubeziehen, erstellen Sie einfach eine Katalogdatei, signieren Sie sie, und stellen Sie sie bereit. Informationen über Katalogdateien finden Sie im Abschnitt Katalogdateien.

5. Aktivieren Sie die gewünschten Hardwaresicherheitsfeatures. Jeder im Abschnitt Device Guard-Bereitstellungsszenarien vorgestellte Gerätetyp profitiert von unterschiedlichen Software- und Hardwareintegritätskonfigurationen. Sollten die hardwarebasierten Sicherheitsfeatures von den Codeintegritätsrichtlinien separat bewerten, da sie eine ergänzende Funktion übernehmen. Informationen über das Konfigurieren der Device Guard-Hardware-basierten Sicherheitsfeatures finden Sie im Abschnitt Konfigurieren von hardwarebasierten Sicherheitsfeatures.

6. Stellen Sie Codeintegritätsrichtlinien und Katalogdateien bereit. Nachdem Sie die erforderlichen Katalogdateien erstellt und signiert sowie die Codeintegritätsrichtlinien erstellt und überwacht haben, können Sie sie in mehreren Phasen bereitstellen. Microsoft empfiehlt dringend, dass Sie diese Komponenten für eine Testgruppe an Benutzern bereitstellen, und zwar auch dann wenn Ihre IT-Organisation sie getestet und untersucht hat. Dies führt zu einer endgültigen Qualitätskontrolle vor dem umfassenderen Bereitstellen der Katalogdateien und Richtlinien. Informationen über das Bereitstellen von Katalogdateien mit „Gruppenrichtlinie“ finden Sie im Abschnitt Bereitstellen von Katalogdateien mit „Gruppenrichtlinie“. Weitere Informationen über das Bereitstellen von Codeintegritätsrichtlinien finden Sie im Abschnitt Bereitstellen von Codeintegritätsrichtlinien mit „Gruppenrichtlinie“.

Device Guard-Bereitstellungsszenarien

Um die Bereitstellung von Device Guard in Ihrer Organisation zu vereinfachen, empfiehlt Microsoft, dass Sie Geräte anhand der Beschreibung in diesem Abschnitt in Bereitstellungsszenarien gruppieren. Bei Device Guard handelt es sich nicht um ein bloßes Feature, das Organisationen einfach „aktivieren“. Vielmehr ist hierfür ein schrittweiser Implementierungsansatz erforderlich. Szenarien, in denen ein gesamter Device Guard-Bereitstellungsansatz möglich ist, finden Sie im Abschnitt Erreichen der Unternehmenscodeintegritäts-Bereitstellung.

Geräte mit fester Arbeitsauslastung

Die Liste der genehmigten Anwendungen auf Geräten mit fester Arbeitsauslastung ändert sich selten, da sie täglich dieselben Aufgaben ausführen. Zu diesen Geräten zählen beispielsweise Kiosks, Point of Sale-Systeme und Callcenter-PCs. Diese Geräte könnten problemlos die vollständigen Device Guard-Funktionen in Anspruch nehmen, und für sie wären nur geringfügige Verwaltungs- oder Richtlinienänderungen erforderlich. Die Device Guard-Implementierung auf diesen Geräten ist einfach und erfordert nur eine geringfügige fortwährende Verwaltung. Wenn Device Guard vollständig implementiert ist, können Benutzer nur die von der IT-Abteilung installierten, verwalteten und vertrauten Anwendungen ausführen.

Zu den Device Guard-Komponenten, die für Geräte mit fester Arbeitsauslastung zutreffen, zählen:

• KMCI-VBS-Schutz

• Erzwungene UMCI-Richtlinie

Vollständig verwaltete Geräte

Für vollständig verwaltete Geräte schränkt die IT-Abteilung die Software ein, die auf ihnen installiert und ausgeführt wird. Sie erlaubt Benutzern jedoch, die Installation von zusätzlicher Software anzufordern oder stellt eine Liste der genehmigten Software in einem Anwendungskatalog bereit. Beispiele derartiger Geräte umfassen gesperrte, unternehmenseigene Desktopcomputer und Laptops. Errichten Sie mit diesen Geräten eine anfängliche Grundlinien-Codeintegritätsrichtlinie, und erzwingen Sie die Integritätsrichtlinie. Die IT-Abteilung verwaltet die Richtlinien und aktualisiert die Geräte, wenn neu Anwendungen genehmigt oder im System Center Configuration Manager-Katalog bereitgestellt werden.

Zu den Device Guard-Komponenten, die für vollständig verwaltete Geräte zutreffen, zählen:

• KMCI-VBS-Schutz

• Erzwungene UMCI-Richtlinie

In diesem Szenario wird eine Anwendungsliste bereitgestellt, der vertraut wird, und die Vertrauensrichtlinie wird konstant erneut ausgewertet, wenn ein Benutzer eine neue Anwendung anfordert. Wenn eine Anwendung über alle Geräte hinweg vertrauenswürdig ist, ist für neue Benutzeranforderungen für diese Anwendung keine Richtlinienaktualisierung (die Ausrichtung erfolgt mit dem Anwendungskatalog) erforderlich. Zudem können Sie dies mit einem Onboarding-Prozess für neue Anwendungen kombinieren, die Sie zum zentralen Anwendungskatalog hinzufügen sollten. Die anfängliche Implementierung von Device Guard für vollständig verwaltete Geräte ist einfach. Demgegenüber führt das Verwalten von vertrauenswürdigen Signaturen von neu angeforderten und genehmigten Anwendungen jedoch zu einem höheren Verwaltungsaufwand.

Kaum verwaltete Geräte

Bei wenig verwalteten Geräten handelt es sich um unternehmenseigene Computer, die von Benutzern vollständig gesteuert werden können. Dies umfasst auch die darauf installierten Elemente. Diese Geräte führen die Antivirenlösung und Clientverwaltungstools der Organisation aus, werden jedoch nicht durch Softwareanforderungen oder Compliancerichtlinien beschränkt.

Zu den Device Guard-Komponenten, die für kaum verwaltete Geräte zutreffen, zählen:

• KMCI-VBS-Schutz

• UMCI-Richtlinie im Überwachungsmodus

Bring Your Own Device (BYOD)

Device Guard ist keine gute Methode, wenn es darum geht, Geräte in einem BYOD-Modell zu verwalten. Wenn Mitarbeiter ihre eigenen Geräte mitbringen dürfen, kann die Verwaltung von Benutzermodusanwendungen auf diesen es für Benutzer schwierig machen, ihre eigenen Geräte zu verwenden, wenn sie nicht auf Arbeit sind. Zusätzlich ist die Device Guard-Funktion aus Administratorperspektive schwierig zu verwalten. Ermitteln Sie für Geräte in dieser Gruppe alternative Härtungs- und Sicherheitsfeatures mit MDM-basierten Lösungen für den bedingten Zugriff wie etwa Microsoft Intune.

Codesignaturübernahme

Die Codesignatur ist für die erfolgreiche Implementierung von konfigurierbaren Richtlinien für die Codeintegrität entscheidend. Diese Richtlinien können Signaturzertifikaten von unabhängigen Softwareanbietern (Independent Software Vendors, ISVs) und Kunden vertrauen. In Windows 10 sind alle Windows Store-Anwendungen signiert. Zudem können Sie jeder anderen signierten Anwendung auf einfache Weise vertrauen, indem Sie der Codeintegritätsrichtlinie das Signaturzertifikat hinzufügen.

Bei nicht signierten Anwendungen verfügen Kunden über mehrere Möglichkeiten, sie zu signieren, sodass die Codeintegritätsrichtlinien ihnen vertrauen. Die erste Option ist die herkömmliche integrierte Codesignatur. Organisationen mit internen Entwicklungsteams können die Codesignatur für binäre Dateien in ihren Anwendungsentwicklungsprozess integrieren und anschließend einfach ihren Codeintegritätszertifikaten das Signaturzertifikat hinzufügen. Die zweite Option für das Signieren nicht signierter Anwendungen besteht in der Verwendung von Katalogdateien. In Windows 10 können Kunden Katalogdateien erstellen, während sie die Installation und anfängliche Ausführung einer Anwendung überwachen. Weitere Informationen über das Signieren von vorhandenen nicht signierten Branchenanwendungen oder Drittanbieteranwendungen finden Sie im Abschnitt Vorhandene Branchenanwendungen.

Vorhandene Branchenanwendungen

Bis dato war es schwierig, vorhandenen Branchenanwendungen zu trauen, wenn sie von einer vom Windows Store abweichenden Quelle signiert oder überhaupt nicht signiert wurden. Mit Windows 10 wird das Signieren Ihrer vorhandenen nicht signierten Branchen- und Drittanbieteranwendungen vereinfacht. Für diese neue Signaturmethode müssen die Anwendungen nicht umgepackt werden. Mithilfe von Katalogdateien können Administratoren diese nicht signierten Anwendungen einfach signieren, indem sie sie für eine Installation und den ersten Start überwachen. Mithilfe dieser Überwachungsinformationen kann ein Administrator eine Katalogdatei generieren. Bei Katalogdateien handelt es sich um einfache SHA2-Hashlisten (Secure-Hash-Algorithmus 2) von erkannten Binärdateien. Die Hashwerte dieser Binärdateien werden bei jeder Aktualisierung einer Anwendung aktualisiert. Daher ist für sie eine aktualisierte Katalogdatei erforderlich. Um die Verwaltung zu vereinfachen, sollten Sie in Erwägung ziehen, die integrierte Codesignatur in Ihren Anwendungsentwicklungsprozess zu integrieren. Weitere Informationen über das Generieren von Katalogdateien finden Sie im Abschnitt Katalogdateien.

Hinweis  

Bei Katalogdateien handelt es sich um Listen von Hashwerten einzelner Binärdateien. Wenn die überprüfte Anwendung aktualisiert wird, müssen Sie eine neue Katalogdatei erstellen. Ungeachtet dessen wird das Signieren binärer Dateien für künftige Anwendungen weiterhin dringend empfohlen, sodass keine Katalogdateien erforderlich sind.

 

Beim Erstellen einer Katalogdatei müssen Sie sie signieren, indem Sie die Public Key-Infrastruktur (PKI) des Unternehmens oder ein erworbenes Codesignaturzertifikat verwenden. Wenn sie signiert sind, können Codeintegritätsrichtlinien dem Signaturgeber oder dem Signaturzertifikat dieser Dateien vertrauen. Informationen über das Signieren von Katalogdateien finden Sie im Abschnitt Katalogdateien.

Anwendungsentwicklung

Auch wenn interne Anwendungen nach dem Packen mithilfe von Katalogdateien signiert werden können, empfiehlt Microsoft dringend, dass die integrierte Codesignatur in Ihren Anwendungsentwicklungsprozess integriert wird. Fügen Sie beim Signieren von Anwendungen der Codeintegritätsrichtlinie einfach das zum Signieren Ihrer Anwendungen verwendete Codesignaturzertifikat hinzu. Dadurch wird sichergestellt, dass Ihre Codeintegritätsrichtlinie künftigen Anwendungen vertraut, die mit diesem Zertifikat signiert sind. Das Integrieren der Codesignatur in einem internen Anwendungsentwicklungsprozess unterstützt Ihre IT-Organisation dabei, Codeintegritätsrichtlinien zu implementieren.

Hardwareaspekte

Für den Erfolg der Device Guard-Implementierungsanstrengungen für Ihre Organisation ist es besonders wichtig, sorgfältige Überlegungen darüber anzustellen, welcher Hardwareanbieter verwendet werden soll bzw. welche bestimmten Modelle während Ihres nächsten Hardwareaustauschs erworben werden sollen. Im Einklang mit Ihrem aktuellen Hardwarelebenszyklus sollten Sie beim Bestimmen der entsprechenden Hardwareaustauschreihenfolge in Ihrer Organisation den im Abschnitt Erreichen der Unternehmenscodeintegritäts-Bereitstellung beschriebenen Prozess berücksichtigen. Device Guard sollte in mehreren Phasen bereitgestellt werden. Daher haben Sie Zeit, die Implementierung methodisch zu planen.

Zum Implementieren verschiedener Device Guard-Features sind unterschiedliche Hardwarefeatures erforderlich. Es stehen wahrscheinlich einige einzelne Features zur Verfügung, die Sie mit Ihrer aktuellen Hardware aktivieren können und andere, mit denen dies nicht möglich ist. Für Organisationen, die Device Guard vollständig implementieren möchten, sind jedoch verschiedene erweiterte Hardwarefeatures erforderlich. Zusätzliche Details über die für Device Guard-Komponenten erforderlichen Hardwarefeatures finden Sie in der folgenden Tabelle.

Anforderung	Beschreibung
Windows 10 Enterprise	Auf dem PC muss Windows 10 Enterprise ausgeführt werden.
UEFI Firmware Version 2.3.1 oder höher sowie „Sicherer Start”	Um sicherzustellen, dass die Firmware UEFI Version 2.3.1 oder höher und den sicherer Start verwendet, können Sie sie mit der Windows-Hardwarekompatibilitätsprogramm-Anforderung System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby überprüfen.
Virtualisierungserweiterungen	Die folgenden Virtualisierungserweiterungen sind zur Unterstützung der virtualisierungsbasierten Sicherheit nötig: Intel VT-x oder AMD-V Adressübersetzung der zweiten Ebene
Firmwaresperre	Die Firmwareeinrichtung muss gesperrt sein, damit andere Betriebssysteme nicht gestartet werden und keine Änderungen an den UEFI-Einstellungen vorgenommen werden. Sie sollten auch andere Startmethoden als die von der Festplatte deaktivieren.
x64-Architektur	Die Features, die die virtualisierungsbasierte Sicherheit im Windows-Hypervisor verwendet, können nur auf einem 64-Bit-PC ausgeführt werden.
Eine VT-d- oder AMD Vi IOMMU (Input/Output Memory Management Unit, Speicherverwaltungseinheit für die Ein-/Ausgabe)	In Windows 10 verbessert eine IOMMU die Systemresilienz gegenüber Angriffen auf den Arbeitsspeicher. ¹
Prozess für ein sicheres Firmwareupdate	Um sicherzustellen, dass die Firmware dem sicheren Firmwareupdateprozess entspricht, können Sie sie mit der Windows-Hardwarekompatibilitätsprogramm-Anforderung System.Fundamentals.Firmware.UEFISecureBoot überprüfen.

 

Device Guard-Bereitstellung

In diesem Abschnitt erhalten Sie Informationen über die folgenden Themen:

• Konfigurieren von hardwarebasierten Sicherheitsfeatures. In diesem Abschnitt wird erläutert, wie die hardwarebasierten Sicherheitsfeatures in Device Guard aktiviert werden. Mithilfe der Windows-Verwaltungsinfrastruktur (WMI) und „Msinfo32.exe“ können Sie zudem überprüfen, ob die Features aktiviert sind.

• Katalogdateien. In diesem Abschnitt erstellen, signieren und stellen Sie Katalogdateien bereit. Die Katalogdateien werden mithilfe von „Gruppenrichtlinie“ und System Center Configuration Manager bereitgestellt. Zudem verwenden Sie System Center Configuration Manager, um die bereitgestellten Katalogdateien zu Berichterstellungszwecken zu inventarisieren.

• Richtlinien für die Codeintegrität. In diesem Abschnitt erhalten Sie Informationen über das Erstellen, Überwachen, Warten, Zusammenführen, Bereitstellen und Entfernen von signierten und nicht signierten konfigurierbaren Richtlinien für die Codeintegrität.

Konfigurieren von hardwarebasierten Sicherheitsfeatures

Hardwarebasierte Sicherheitsfeatures bilden einen Großteil der Device Guard-Sicherheitsangebote. VBS verstärkt das wichtigste Device Guard-Feature: die konfigurierbare Codeintegrität. Zum Konfigurieren der hardwarebasierten Sicherheitsfeatures in Device Guard stehen drei Schritte zur Verfügung:

1. Stellen Sie sicher, dass die Hardwareanforderungen erfüllt und aktiviert sind. Überprüfen Sie, ob Ihre Clientcomputer über die erforderliche Hardware verfügen, um diese Features auszuführen. Im Abschnitt Hardwareaspekte finden Sie eine Liste der Hardwareanforderungen für die hardwarebasierten Sicherheitsfeatures. Zudem sollten Sie die im Abschnitt Device Guard–fähige Geräte erläuterten Geräte in Erwägung ziehen, wenn Sie nach neuer Hardware suchen.

2. Aktivieren Sie die erforderlichen Windows-Features. Es gibt verschiedene Möglichkeiten, die für die hardwarebasierte Sicherheit erforderlichen Windows-Features zu aktivieren. Ausführliche Informationen darüber, welche Windows-Features erforderlich sind, finden Sie im Abschnitt Windows-Featureanforderungen für VBS.

3. Aktivieren Sie die gewünschten Features. Wenn die erforderlichen Hardware- und Windows-Features aktiviert wurden, können Sie die gewünschten hardwarebasierten Sicherheitsfeatures aktivieren. Informationen über den sicheren UEFI-Start finden Sie im Abschnitt Aktivieren des sicheren UEFI-Starts. Informationen über das Aktivieren des VBS-Schutzes des KMCI-Diensts finden Sie im Abschnitt Aktivieren des virtualisierungsbasierten Schutzes der Kernelmodus-Codeintegrität. Informationen über das Aktivieren von Credential Guard finden Sie darüber hinaus im Abschnitt Aktivieren von Credential Guard.

Windows-Featureanforderungen für VBS

Zusätzlich zu den im Abschnitt Hardwareaspekte aufgeführten Hardwareanforderungen müssen Sie bestimmte Betriebssystemfeatures aktivieren, bevor Sie VBS aktivieren können: Microsoft Hyper-V und den isolierten Benutzermodus (siehe Abbildung 1).

Hinweis  

Sie können diese Features mithilfe der Windows PowerShell oder Abbildverwaltung für die Bereitstellung manuell konfigurieren. Bestimmte Informationen über diese Methoden finden Sie unter Credential Guard.

 

Abbildung 1. Aktivieren von Betriebssystemfeatures für VBS

Nachdem Sie diese Features aktiviert haben, können Sie die gewünschten hardwarebasierten Sicherheitsfeatures konfigurieren. Informationen über das Aktivieren des virtualisierungsbasierten Schutzes der Kernelmodus-Codeintegrität finden Sie im Abschnitt Aktivieren des virtualisierungsbasierten Schutzes der Kernelmodus-Codeintegrität. Informationen über das Aktivieren des sicheren UEFI-Starts finden Sie im Abschnitt Aktivieren des sicheren UEFI-Starts. Zusätzliche Informationen über das Aktivieren von Credential Guard finden Sie darüber hinaus im Abschnitt Aktivieren von Credential Guard.

Aktivieren des sicheren UEFI-Starts

Bevor Sie diesen Prozess beginnen, müssen Sie sicherstellen, dass das Gerät die Hardwareanforderungen für den sicheren UEFI-Start erfüllt, die im Abschnitt Hardwareaspekte aufgeführt werden. Es gibt zwei Möglichkeiten für die Konfiguration des sicheren UEFI-Starts: die manuelle Konfiguration der entsprechenden Registrierungsschlüssel und die Bereitstellung über „Gruppenrichtlinie“. Führen Sie die folgenden Schritte aus, um den sicheren UEFI-Start auf einem Computer unter Windows 10 manuell zu konfigurieren:

Hinweis  

Es gibt zwei Plattformsicherheitsebenen für den sicheren Start: den eigenständigen sicheren Start und den sicheren Start mit DMA-Schutz. Der DMA-Schutz bietet zusätzlichen Arbeitsspeicherschutz. Er wird jedoch nur auf Systemen aktivieren, der Prozessoren DMA-Schutztechnologien (IOMMU) aufweisen. Ohne vorhandene IOMMUs und mit deaktiviertem DMA-Schutz sind Kunden nicht vor treiberbasierten Angriffen geschützt.

 

1. Navigieren Sie zum Registrierungsunterschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.

2. Legen Sie den Wert EnableVirtualizationBasedSecurity DWORD auf 1 fest.

3. Legen Sie den Wert RequirePlatformSecurityFeatures DWORD entsprechend fest:

   • Legen Sie diesen Wert auf 1 fest, um die Option Sicherer Start zu aktivieren.

   • Legen Sie diesen Wert auf 2 fest, um die Option Sicherer Start und DMA-Schutz zu aktivieren.

4. Starten Sie den Clientcomputer neu.

Das manuelle Ausführen dieser Schritte auf jedem geschützten Computer in Ihrem Unternehmen wäre jedoch leider zeitaufwändig. Mit „Gruppenrichtlinie“ erhalten Sie eine wesentlich einfachere Möglichkeit, um den sicheren UEFI-Start in Ihrer Organisation bereitzustellen. In diesem Beispiel wird eine Testorganisationseinheit (Organizational Unit, OU) mit dem Namen DG Enabled PCs erstellt. Wenn Sie es vorziehen, die Richtlinie mit einer vorhandenen OU zu verknüpfen und dann mithilfe entsprechend benannter Computersicherheitsgruppen den Bereich des GPOs auszuwählen, ist dies natürlich möglich.

Hinweis  

Microsoft empfiehlt, dass Sie dieses Feature in einer Gruppe von Testcomputern testweise aktivieren, bevor Sie es auf Computern bereitstellen, die zurzeit für Benutzer bereitgestellt sind.

 

Verwenden von „Gruppenrichtlinie“ zum Bereitstellen des sicheren Starts

1. Klicken Sie zum Erstellen eines neuen GPOs mit der rechten Maustaste auf die OU, mit der Sie das GPO verknüpfen möchten, und klicken Sie dann auf Gruppenrichtlinienobjekt hier erstellen und verknüpfen.

   

   Abbildung 2. Erstellen eines neuen mit der OU verknüpften GPOs

2. Nennen Sie das neue GPO Contoso Secure Boot GPO Test. In diesem Beispiel wird Contoso Secure Boot GPO Test als Name des GPOs verwendet. Sie können einen beliebigen Namen für dieses Beispiel auswählen. Idealerweise müsste sich der Name an der Namenskonvention Ihres vorhandenen GPOs orientieren.

3. Klicken Sie zum Öffnen des Gruppenrichtlinienverwaltungs-Editors mit der rechten Maustaste auf das neue GPO, und klicken Sie dann auf Bearbeiten.

4. Navigieren Sie im ausgewählten GPO zu „Computerkonfiguration\Administrative Vorlagen\System\Device Guard“. Klicken Sie anschließend mit der rechten Maustaste auf Virtualisierungsbasierte Sicherheit aktivieren, und klicken Sie dann auf Bearbeiten.

   

   Abbildung 3. Aktivieren von VBS

5. Wählen Sie die Option Aktiviert und dann Sicherer Start und DMA-Schutz aus der Liste Plattform-Sicherheitsstufe auswählen aus.

   

   Abbildung 4. Aktivieren von „Sicherer Start“

   Hinweis  

   Der Nutzen des sicheren Starts von Device Guard wird in Kombination mit dem DMA-Schutz maximiert. Wenn Ihre Hardware die für den DMA-Schutz erforderlichen IOMMUs aufweist, müssen Sie die Plattformsicherheitsebene Sicherer Start und DMA-Schutz auswählen. Wenn Ihre Hardware keine IOMMU enthält, stehen verschiedene Ausgleichsmaßnahmen zur Verfügung, indem der sichere Start ohne DMA-Schutz verwendet wird.

    

6. Schließen Sie den Gruppenrichtlinienverwaltungs-Editor, und starten Sie den Testcomputer unter Windows 10 anschließend neu. Nachdem Sie diese Einstellung konfiguriert haben, wird der sichere UEFI-Start beim Neustart aktiviert.

7. Überprüfen Sie das Ereignisprotokoll des Testcomputers für die Device Guard-GPOs.

   Die verarbeiteten Device Guard-Richtlinien werden in der Ereignisanzeige unter „Anwendungs- und Dienstprotokolle\Microsoft\Windows\DeviceGuard-GPEXT\Operational“ protokolliert. Wenn die Richtlinie Virtualisierungsbasierte Sicherheit aktivieren erfolgreich verarbeitet wird, wird die Ereignis-ID 7000 protokolliert. Diese enthält die ausgewählten Einstellungen in der Richtlinie.

Aktivieren der virtualisierungsbasierten Sicherheit der Kernelmodus-Codeintegrität

Bevor Sie diesen Prozess beginnen, müssen Sie überprüfen, ob der gewünschte Computer die im Abschnitt Hardwareaspekte aufgeführten Hardwareanforderungen erfüllt. Darüber hinaus müssen Sie die im Abschnitt Windows-Featureanforderungen für VBS beschriebenen Windows-Features aktivieren. Nach der Überprüfung können Sie den virtualisierungsbasierten Schutz von KMCI auf zwei Arten aktivieren: durch die manuelle Konfiguration der entsprechenden Registrierungsunterschlüssel und durch die Bereitstellung über „Gruppenrichtlinie“.

Hinweis  

Alle Treiber auf dem System müssen mit dem virtualisierungsbasierten Schutz der Codeintegrität kompatibel sein. Ansonsten ist das System möglicherweise fehlerhaft. Microsoft empfiehlt, dass Sie dieses Feature für eine Gruppe an Testcomputern aktivieren, bevor Sie es für bereitgestellte Computer aktivieren.

 

So nehmen Sie eine manuelle Konfiguration des virtualisierungsbasierten Schutzes der KMCI vor

1. Navigieren Sie zum Registrierungsunterschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard.

2. Legen Sie den Wert HypervisorEnforcedCodeIntegrity DWORD auf 1 fest.

3. Starten Sie den Clientcomputer neu.

Das manuelle Ausführen dieser Schritte auf jedem geschützten Computer in Ihrem Unternehmen wäre jedoch zeitaufwändig. Verwenden Sie stattdessen „Gruppenrichtlinie“, um den virtualisierungsbasierten Schutz der KMCI bereitzustellen. In diesem Beispiel wird eine Test-OU mit dem Namen DG Enabled PCs erstellt, die Sie zum Verknüpfen des GPOs verwenden. Wenn Sie es bevorzugen, die Richtlinie mit einer vorhandenen OU zu verknüpfen, anstelle eine Test-OU zu erstellen und den Bereich der Richtlinie mithilfe der entsprechend benannten Computersicherheitsgruppen auszuwählen, ist dies eine andere Option.

Hinweis  

Microsoft empfiehlt, dass Sie dieses Feature in einer Gruppe von Testcomputern testweise aktivieren, bevor Sie es auf Computern bereitstellen, die zurzeit für Benutzer bereitgestellt sind. Wenn kein Test vorgenommen wurde, besteht die Möglichkeit, dass dieses Feature eine Systeminstabilität und letztendlich das Fehlschlagen des Clientbetriebssystems verursacht.

 

So verwenden Sie „Gruppenrichtlinie“ zum Konfigurieren von VBS der KMCI

1. Klicken Sie zum Erstellen eines neuen GPOs mit der rechten Maustaste auf die OU, mit der Sie das GPO verknüpfen möchten, und klicken Sie dann auf Gruppenrichtlinienobjekt hier erstellen und verknüpfen.

   

   Abbildung 5. Erstellen eines neuen mit der OU verknüpften GPOs

2. Nennen Sie das neue GPO Contoso VBS CI Protection GPO Test.

   In diesem Beispiel wird Contoso VBS CI Protection GPO Test als Name des GPOs verwendet. Sie können für dieses Beispiel jeden gewünschten Namen auswählen. Idealerweise müsste sich dieser Name an der Namenskonvention Ihres vorhandenen GPOs orientieren.

3. Klicken Sie zum Öffnen des Gruppenrichtlinienverwaltungs-Editors mit der rechten Maustaste auf das neue GPO, und klicken Sie dann auf Bearbeiten.

4. Navigieren Sie im ausgewählten GPO zu „Computerkonfiguration\Administrative Vorlagen\System\Device Guard“. Klicken Sie anschließend mit der rechten Maustaste auf Virtualisierungsbasierte Sicherheit aktivieren, und klicken Sie dann auf Bearbeiten.

   

   Abbildung 6. Aktivieren von VBS

5. Wählen Sie die Option Aktiviert aus, und aktivieren Sie dann das Kontrollkästchen Virtualisierungsbasierten Schutz der Codeintegrität aktivieren.

   

   Abbildung 7. Aktivieren von VBS der KMCI

6. Schließen Sie den Gruppenrichtlinienverwaltungs-Editor, und starten Sie den Testcomputer unter Windows 10 anschließend neu. Wenn diese Einstellung konfiguriert ist, wird die VBS der KMCI nach dem Neustart wirksam.

7. Überprüfen Sie das Ereignisprotokoll des Testclients auf Device Guard-GPOs.

   Die verarbeiteten Device Guard-Richtlinien werden in der Ereignisanzeige unter „Anwendungs- und Dienstprotokolle\Microsoft\Windows\DeviceGuard-GPEXT\Operational“ protokolliert. Wenn die Richtlinie Virtualisierungsbasierte Sicherheit aktivieren erfolgreich verarbeitet wurde, wird die Ereignis-ID 7000 protokolliert. Diese enthält die ausgewählten Einstellungen in der Richtlinie.

Aktivieren von Credential Guard

Credential Guard bietet eine zusätzliche Ebene für den Schutz von Anmeldeinformationen, die speziell für Domänenbenutzer vorgesehen ist. Hierfür werden die Anmeldeinformationen im virtualisierten Container gespeichert, und zwar getrennt vom Kernel- und Benutzermodus-Betriebssystem. Dadurch wird es selbst für ein kompromittiertes System schwierig, Zugriff auf die Anmeldeinformationen zu erlangen. Zusätzlich zur clientseitigen Aktivierung von Credential Guard können Sie auf Zertifizierungsstellen- und Domänencontrollerebene zusätzliche Risikominderungen bereitstellen, um den Diebstahl von Anmeldeinformationen zu verhindern. Microsoft stellt künftig Details über diese zusätzlichen Risikominderungen bereit.

Bevor Sie diesen Prozess beginnen, müssen Sie überprüfen, ob das gewünschte System die im Abschnitt Hardwareaspekte aufgeführten Hardwareanforderungen erfüllt und dass Sie die im Abschnitt Windows-Featureanforderungen für VBS beschriebenen Windows-Features aktiviert haben. Wenn sie überprüft wurden, können Sie Credential Guard manuell aktivieren, indem Sie die entsprechenden Registrierungsunterschlüssel konfigurieren.

So nehmen Sie die manuelle Konfiguration der VBS von Credential Guard vor

1. Navigieren Sie zum Registrierungsunterschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

2. Legen Sie den Wert LsaCfgFlags DWORD auf 1 fest.

3. Starten Sie den Clientcomputer neu.

Verwenden Sie „Gruppenrichtlinie“, um Credential Guard in Ihrer Organisation bereitzustellen. So vermeiden Sie nicht erforderliche zeitaufwändige manuelle Bereitstellungen. In diesem Beispiel wird eine Test-OU mit dem Namen DG Enabled PCs erstellt. Um Credential Guard zu aktivieren, können Sie eine Verbindung zu einer OU herstellen und dann mithilfe der Sicherheitsgruppen den Bereich der Anwendung des GPOs auswählen.

Hinweis  

Microsoft empfiehlt, dass Sie Credential Guard aktivieren, bevor Sie einen Computer mit einer Domäne verknüpfen, um sicherzustellen, dass alle Anmeldeinformationen ordnungsgemäß geschützt sind. Das Festlegen der entsprechenden Registrierungsunterschlüssel während Ihres Imageerstellungsprozesses wäre ideal, um diesen Schutz zu erzielen.

 

So verwenden Sie „Gruppenrichtlinie“ zum Aktivieren von Credential Guard

1. Klicken Sie zum Erstellen eines neuen GPOs mit der rechten Maustaste auf die OU, mit der Sie das GPO verknüpfen möchten, und klicken Sie dann auf Gruppenrichtlinienobjekt hier erstellen und verknüpfen.

   

   Abbildung 8 Erstellen eines neuen mit der OU verknüpften GPOs

2. Nennen Sie das neue GPO Contoso Credential Guard GPO Test.

   In diesem Beispiel wird Contoso Credential Guard GPO Test als Name des GPOs verwendet. Sie können für dieses Beispiel jeden gewünschten Namen auswählen. Idealerweise müsste sich dieser Name an der Namenskonvention Ihres vorhandenen GPOs orientieren.

3. Klicken Sie zum Öffnen des Gruppenrichtlinienverwaltungs-Editors mit der rechten Maustaste auf das neue GPO, und klicken Sie dann auf Bearbeiten.

4. Navigieren Sie im ausgewählten GPO zu „Computerkonfiguration\Administrative Vorlagen\System\Device Guard“. Klicken Sie mit der rechten Maustaste auf Virtualisierungsbasierte Sicherheit aktivieren, und klicken Sie dann auf Bearbeiten.

   

   Abbildung 9 Aktivieren von VBS

5. Wählen Sie die Option Aktiviert aus, und aktivieren Sie dann das Kontrollkästchen Credential Guard aktivieren.

   

   Abbildung 10 Aktivieren von Credential Guard

6. Schließen Sie den Gruppenrichtlinienverwaltungs-Editor, und starten Sie den Testcomputer unter Windows 10 anschließend neu.

   Hinweis  

   Die standardmäßige Plattformsicherheitsebene lautet Sicherer Start. Wenn auf den geschützten Computern IOMMUs verfügbar sind, sollten Sie Sicherer Start und DMA-Schutz auswählen, um die Abschwächungen zu maximieren, die sich aufgrund von Credential Guard ergeben.

    

7. Überprüfen Sie das Ereignisprotokoll des Testclients auf Device Guard-GPOs.

Hinweis  

Alle verarbeiteten Device Guard-Richtlinien werden in der Ereignisanzeige unter „Anwendungs- und Dienstprotokolle\Microsoft\Windows\DeviceGuard-GPEXT\Operational“ protokolliert.

 

Zusätzliche Informationen über die Funktionsweise von Credential Guard sowie zusätzliche Konfigurationsoptionen finden Sie unter Credential Guard.

Überprüfen von aktivierten Device Guard-Hardware-basierten Sicherheitsfeatures

Windows 10 sowie Windows Server 2016 und höher weisen die WMI-Klasse Win32_DeviceGuard für Eigenschaften und Features auf, die mit Device Guard in Zusammenhang stehen. Diese Klasse kann in einer Windows PowerShell-Sitzung mit erhöhten Rechten mithilfe des folgenden Befehls abgerufen werden:

Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard

Hinweis  

Die WMI-Klasse Win32_DeviceGuard steht nur in der Enterprise-Edition von Windows 10 zur Verfügung.

In der Ausgabe dieses Befehls werden Details über die verfügbaren hardwarebasierten Sicherheitsfeatures sowie über die aktuell aktivierten Features bereitgestellt. Ausführliche Informationen über die Bedeutung jeder einzelnen Eigenschaft finden Sie in der Tabelle 1.

 

Tabelle 1. Win32_DeviceGuard-Eigenschaften

Eigenschaften	Beschreibung	Gültige Werte
AvailableSecurityProperties	Dieses Feld hilft dabei, den Status in den relevanten Sicherheitseigenschaften für Device Guard aufzulisten und zu melden.	0. Wenn vorhanden, sind auf dem Gerät keine relevanten Eigenschaften vorhanden. 1. Wenn vorhanden, ist die Hypervisor-Unterstützung verfügbar. 2. Wenn vorhanden, ist „Sicherer Start“ verfügbar. 3. Wenn vorhanden, ist der DMS-Schutz verfügbar.
InstanceIdentifier	Eine für ein bestimmtes Gerät eindeutige Zeichenfolge.	Wird durch WMI bestimmt.
RequiredSecurityProperties	In diesem Feld werden die erforderlichen Sicherheitseigenschaften zum Aktivieren der virtualisierungsbasierten Sicherheit beschrieben.	0. Nichts ist erforderlich. 1. Wenn vorhanden, ist „Sicherer Start“ erforderlich. 2. Wenn vorhanden, ist der DMA-Schutz erforderlich. 3. Wenn vorhanden, sind „Sicherer Start“ und der DMA-Schutz erforderlich.
SecurityServicesConfigured	Dieses Feld gibt an, ob der Credential Guard- oder HVCI-Dienst konfiguriert wurde.	0. Keine Dienste konfiguriert. 1. Wenn vorhanden, ist Credential Guard konfiguriert. 2. Wenn vorhanden, ist HVCI konfiguriert.
SecurityServicesRunning	Dieses Feld gibt an, ob der Credential Guard- oder HVCI-Dienst ausgeführt wird.	0. Es werden keine Dienste ausgeführt. 1. Wenn vorhanden, wird Credential Guard ausgeführt. 2. Wenn vorhanden, wird HVCI ausgeführt.
Version	In diesem Feld wird die Version dieser WMI-Klasse ausgeführt.	Der derzeit einzig gültige Wert lautet 1.0.
VirtualizationBasedSecurityStatus	Dieses Feld gibt an, ob VBS aktiviert ist und ausgeführt wird.	0. VBS ist nicht aktiviert. 1. VBS ist aktiviert, wird jedoch nicht ausgeführt. 2. VBS ist aktiviert und wird ausgeführt.
PSComputerName	In diesem Feld wird der Computername aufgeführt.	Alle gültigen Werte für den Computernamen.

 

Eine andere Methode, die verfügbaren und aktivierten Device Guard-Features zu bestimmen, besteht darin, die Datei „msinfo32.exe“ in einer PowerShell-Sitzung mit erhöhten Rechten auszuführen. Beim Ausführen dieses Programms werden die Device Guard-Eigenschaften unten im Abschnitt Systemübersicht angezeigt, wie dies in Abbildung 11 veranschaulicht wird.

Abbildung 11 Device Guard-Eigenschaften in der Systemübersicht

Katalogdateien

Für das Erzwingen von Device Guard auf einem System muss jede vertrauenswürdige Anwendung über eine Signatur verfügen oder die Hashwerte der zugehörigen Binärdateien müssen zur Codeintegritätsrichtlinie hinzugefügt werden. Für viele Organisationen kann dies ein Problem darstellen, wenn sie in Erwägung ziehen, nicht signierte Branchenanwendungen einzusetzen. Um zu vermeiden, dass Organisationen diese Anwendungen umpacken und signieren müssen, enthält Windows 10 ein sogenanntes Paketprüfungstool. Dieses überwacht einen Installationsprozess für bereitgestellte und ausgeführte Binärdateien. Wenn das Tool derartige Dateien ermittelt, werden sie in einer Katalogdatei aufgeschlüsselt. Diese Katalogdateien stellen Ihnen eine Möglichkeit bereit, Ihren vorhandenen nicht signierten Anwendungen zu vertrauen. Dabei spielt es keine Rolle, ob sie intern oder durch einen Drittanbieter entwickelt wurde. Zudem ermöglichen sie Ihnen, signierten Anwendungen zu vertrauen, bei denen Sie dem Herausgeber nicht vertrauen, jedoch einer bestimmten Anwendung vertrauen möchten. Nach dem Erstellen können diese Dateien signiert wird. Zudem können Ihren vorhandenen Codeintegritätsrichtlinien die Signaturzertifikate hinzugefügt werden, und die Katalogdateien an sich können auf den Clients bereitgestellt werden.

Hinweis  

Zum Erstellen und Verwenden von Katalogdateien ist die Enterprise-Edition von Windows 10 oder Windows Server 2016 erforderlich.

 

Erstellen von Katalogdateien

Das Erstellen von Katalogdateien stellt den ersten Schritt beim Hinzufügen einer nicht signierten Anwendung zu einer Codeintegritätsrichtlinie dar. Kopieren Sie zum Erstellen einer Katalogdatei jeden der folgenden Befehle in eine Windows PowerShell-Sitzung mit erhöhten Rechten, und führen Sie diese Schritte aus:

Hinweis  

Wenn Sie eine Namenskonvention einrichten, können Sie künftig bereitgestellte Katalogdateien einfacher ermitteln. In diesem Handbuch wird *-Contoso.cat als Namenskonvention verwendet. Weitere Informationen darüber, weshalb diese Übung für das Inventarisieren oder Ermitteln von Katalogdateien hilfreich ist, finden Sie im Abschnitt Inventarisieren von Katalogdateien mit System Center Configuration Manager.

 

1. Stellen Sie sicher, dass eine Codeintegritätsrichtlinie zurzeit im Überwachungsmodus ausgeführt wird.

   Vom Paketprüfungstool werden die Installationsdateien nicht immer ermittelt, die während des Installationsprozesses vom Computer entfernt wurden. Um sicherzustellen, dass diese Binärdateien ebenfalls vertrauenswürdig sind, sollte die von Ihnen in den Abschnitten Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs und Überwachen der Codeintegritätsrichtlinien erstellte und überwachte Codeintegritätsrichtlinie im Überwachungsmodus für das System bereitgestellt werden, auf dem Sie das Paketprüfungstool ausführen.

   Hinweis  

   Dieser Prozess sollte nicht auf einem System ausgeführt werden, auf dem eine erzwungene Device Guard-Richtlinie ausgeführt wird, sondern nur mit einer Richtlinie, die im Überwachungsmodus ausgeführt wird. Wenn aktuell eine Richtlinie erzwungen wird, können Sie die Anwendung weder installieren noch ausführen.

    

2. Starten Sie das Paketprüfungstool, und nehmen Sie dann eine Überprüfung des Laufwerks „C:“ vor.

   PackageInspector.exe Start C:

   Hinweis  

   Mit dem Paketprüfungstool können Installationen auf jedem lokalen Laufwerk überwacht werden. In diesem Beispiel wird die Anwendung auf dem Laufwerk „C“ installiert. Es kann jedoch auch jedes andere Laufwerk verwendet werden.

    

3. Kopieren Sie die Installationsmedien auf das Laufwerk „C“.

   Durch das Kopieren der Installationsmedien auf das Laufwerk „C“ stellen Sie sicher, dass der tatsächliche Installer durch das Paketprüfungstool ermittelt und katalogisiert wird. Wenn Sie diesen Schritt überspringen, vertraut die künftige Codeintegritätsrichtlinie möglicherweise der Ausführung, nicht aber der Installation der Anwendung.

4. Installieren und starten Sie die Anwendung.

   Installieren Sie die Anwendung auf Laufwerk „C“. Starten Sie nach abgeschlossener Installation die Anwendung, und stellen Sie sicher, dass die Produktupdates installiert sind und während die herunterladbaren Inhalte während der Überprüfung gefunden werden. Schließen Sie, wenn dieser Vorgang abgeschlossen ist, die Anwendung, und öffnen Sie sie erneut, um sicherzustellen, dass die Überprüfung alle Binärdateien gefunden hat.

   Hinweis  

   Jede Binärdatei, die während der Ausführung des Paketprüfungstools ausgeführt wird, wird im Katalog aufgezeichnet. Daher müssen Sie sicherstellen, während der Überprüfung keine zusätzlichen Installationen oder Updates auszuführen, um das Risiko zu minimieren, falschen Binärdateien zu vertrauen. Wiederholen Sie alternativ einfach den Installations- und Ausführungsprozess, während die aktuelle Überprüfung ausgeführt wird, wenn Sie einer einzelnen Katalogdatei mehrere Anwendungen hinzufügen möchten.

    

5. Beenden Sie die Überprüfung, und generieren Sie dann die Definitions- und Katalogdateien. Beenden Sie nach dem Abschluss der Anwendungsinstallation und Ersteinrichtung die Paketprüfungstool-Überprüfung, und generieren Sie mithilfe der folgenden Befehle die Katalog- und Definitionsdateien auf Ihrem Desktop.

   $ExamplePath=$env:userprofile+"\Desktop"

   $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"

   $CatDefName=$ExamplePath+"\LOBApp.cdf"

   PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName

Hinweis  

Bei dieser Überprüfung werden die Hashwerte für jede ermittelte Binärdatei katalogisiert. Wenn die überprüften Anwendungen aktualisiert werden, schließen Sie diesen Prozess erneut ab, um den Hashwerten der neuen Binärdateien zu vertrauen.

 

Wenn Sie fertig sind, werden die Dateien auf Ihrem Desktop gespeichert. Um dieser Katalogdatei in einer Codeintegritätsrichtlinie zu vertrauen, muss der Katalog zunächst signiert werden. Anschließend kann das Signaturzertifikat in der Codeintegritätsrichtlinie eingeschlossen werden. Zudem kann die Katalogdatei auf den einzelnen Clientcomputern bereitgestellt werden. Katalogdateien können mithilfe eines Zertifikats und „SignTool.exe“ signiert werden. Hierbei handelt es sich um ein in Windows SDK kostenlos verfügbares Tool. Weitere Informationen über das Signieren von Katalogdateien mit „SignTool.exe“ finden Sie im Abschnitt Katalogsignatur mit „SignTool.exe“.

Katalogsignatur mit „SignTool.exe“

Device Guard erleichtert es Organisationen, vorhandene nicht signierte Branchenanwendungen zu signieren und diesen zu vertrauen. In diesem Abschnitt signieren Sie mithilfe von „PackageInspector.exe“ eine von Ihnen im vorherigen Abschnitt generierte Katalogdatei. Informationen über das Erstellen von Katalogdateien finden Sie im Abschnitt Erstellen von Katalogdateien. In diesem Beispiel benötigen Sie Folgendes:

• Die in Windows Software Development Kit (SDK – Windows 7 oder höher) enthaltene „SignTool.exe“

• Die von Ihnen im Abschnitt Erstellen von Katalogdateien generierte Katalogdatei oder eine andere von Ihnen erstellte Katalogdatei

• Ein internes Zertifizierungsstellen-Codesignaturzertifikat oder ein erworbenes Codesignaturzertifikat

Wenn Sie nicht über ein Codesignaturzertifikat verfügen, lesen Sie den Abschnitt Erstellen eines Device Guard-Codesignaturzertifikats, um anhand einer exemplarischen Vorgehensweise zu erfahren, wie sie eins erstellen können. Zusätzlich zur Verwendung des Zertifikats, das Sie im Abschnitt Erstellen eines Device Guard-Codesignaturzertifikats erstellen, wird in diesem Beispiel die von Ihnen im Abschnitt Erstellen von Katalogdateien erstellte Katalogdatei signiert. Wenn Sie ein alternatives Zertifikat oder eine Katalogdatei verwenden, aktualisieren Sie die folgenden Schritte mit den entsprechenden Werten bzw. dem Zertifikat. Kopieren Sie zum Signieren der vorhandenen Katalogdatei die folgenden Befehle in eine Windows PowerShell-Sitzung mit erhöhten Rechten:

1. Initialisieren die zu verwendenden Variablen:

   $ExamplePath=$env:userprofile+"\Desktop"
   
   $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
   

   Hinweis  

   In diesem Beispiel wird die von Ihnen im Abschnitt Erstellen von Katalogdateien erstellte Katalogdatei verwendet. Stellen Sie beim Signieren einer anderen Katalogdatei sicher, die Variablen $ExamplePath und $CatFileName mit den richtigen Informationen zu aktualisieren.

    

2. Importieren Sie das Codesignaturzertifikat. Importieren Sie das Codesignaturzertifikat, das verwendet wird, um die Katalogdatei für den persönlichen Speicher des signierenden Benutzers zu signieren. In diesem Beispiel wird das von Ihnen im Abschnitt Erstellen eines Device Guard-Codesignaturzertifikats erstellte Zertifikat verwendet.

3. Signieren Sie die Katalogdatei mit „Signtool.exe“:

   <Path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
   

   Hinweis  

   Bei der Variablen <Path to signtool.exe> sollte es sich um den vollständigen Pfad zum „Signtool.exe“-Hilfsprogramm handeln. ContosoDGSigningCert ist der Antragstellername des Zertifikats, das Sie zum Signieren der Katalogdatei verwenden. Dieses Zertifikat sollte in Ihren persönlichen Zertifikatsspeicher auf dem Computer importiert werden, auf dem Sie versuchen, die Katalogdatei zu signieren.

    

   Hinweis  

   Weitere Informationen über „Signtool.exe“ und alle zusätzlichen Switches finden Sie unter SignTool.exe (Signaturtool).

    

4. Überprüfen Sie die digitale Signatur der Katalogdatei. Klicken Sie mit der rechten Maustaste auf die Katalogdatei, und klicken Sie anschließend auf Eigenschaften. Stellen Sie auf der Registerkarte Digitale Signaturen sicher, dass Ihr Signaturzertifikat mit einem SHA256-Algorithmus vorhanden ist, wie dies in Abbildung 12 veranschaulicht wird.

   

   Abbildung 12 Sicherstellen, dass das Signaturzertifikat vorhanden ist

5. Kopieren Sie die Katalogdatei nach „C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}“.

   Zu Testzwecken können Sie die signierten Katalogdateien manuell in den gewünschten Zielordner verschieben. Bei Implementierungen im großen Ausmaß empfiehlt Microsoft, dass Sie die Gruppenrichtlinien-Dateieinstellungen verwenden, um die entsprechenden Katalogdateien auf alle gewünschten Computer oder ein Verwaltungsprodukt für Unternehmenssysteme wie System Center Configuration Manager zu kopieren. Dadurch wird die Verwaltung der Katalogversionen ebenfalls vereinfacht.

Bereitstellen von Katalogdateien mit „Gruppenrichtlinie“

Zum Vereinfachen der Verwaltung von Katalogdateien können Sie die Einstellung „Gruppenrichtlinie“ verwenden, um die Katalogdateien auf den entsprechenden PCs in Ihrer Organisation bereitzustellen. Der folgende Prozess führt Sie durch die Bereitstellung einer signierten Katalogdatei mit dem Namen „LOBApp-Contoso.cat“. Hierbei wird eine OU mit dem Namen „DG Enabled PCs“ mit einem GPO mit dem Namen Contoso DG Catalog File GPO Test getestet.

Hinweis  

Für diese Vorgehensweise ist es erforderlich, dass Sie zuvor eine signierte Katalogdatei erstellt haben und über einen Client-PC unter Windows 10 verfügen, auf dem Sie eine Gruppenrichtlinienbereitstellung testen. Weitere Informationen über das Erstellen und Signieren einer Katalogdatei finden Sie im Abschnitt Katalogdateien.

 

So stellen Sie mithilfe von „Gruppenrichtlinie“ eine Katalogdatei bereit

1. Öffnen Sie in einem Domänencontroller oder auf einem Client-PC, auf dem Remoteserver-Verwaltungstools (Remote Server Administration Tools, RSAT) installiert sind, die Gruppenrichtlinien-Verwaltungskonsole (Group Policy Management Console, GPMC), indem Sie GPMC.MSC ausführen oder indem Sie nach „Gruppenrichtlinienverwaltung“ suchen.

2. Erstellen Sie ein neues GPO, klicken Sie mit der rechten Maustaste auf die OU „DG Enabled PCs“, und klicken Sie dann auf Gruppenrichtlinienobjekt hier erstellen und verknüpfen, wie dies in Abbildung 13 veranschaulicht wird.

   Hinweis  

   Bei der OU „DG Enabled PCs“ handelt es sich einfach um ein Beispiel davon, wohin das Test-GPO verknüpft wird, das Sie in diesem Abschnitt erstellt haben. Sie können einen beliebigen OU-Namen verwenden. Darüber stellt die Sicherheitsgruppenfilterung eine Option dar, wenn Sie Richtlinienpartitionierungsoptionen auf Grundlage der im Abschnitt Erreichen der Unternehmenscodeintegritäts-Bereitstellung erläuterten Strategie in Erwägung ziehen.

    

   

   Abbildung 13 Erstellen eines neuen GPOs

3. Nennen Sie das neue GPO Contoso DG Catalog File GPO Test.

   In diesem Beispiel wird Contoso DG Catalog File GPO Test als Name des GPOs verwendet. Sie können für dieses Beispiel jeden gewünschten Namen auswählen.

4. Klicken Sie zum Öffnen des Gruppenrichtlinienverwaltungs-Editors mit der rechten Maustaste auf das neue GPO, und klicken Sie dann auf Bearbeiten.

5. Navigieren Sie im ausgewählten GPO zu „Computerkonfiguration\Einstellungen\Windows-Einstellungen\Dateien“. Klicken Sie mit der rechten Maustaste auf Dateien, zeigen Sie auf Neu, und klicken Sie dann auf Datei, wie dies in Abbildung 14 gezeigt wird.

   

   Abbildung 14 Erstellen einer neuen Datei

6. Konfigurieren Sie die Katalogdateifreigabe.

   Um diese Einstellung so zu verwenden, dass eine einheitliche Bereitstellung der Datei „LOBApp-Contoso.cat“ geboten wird, sollte sich die Quelldatei auf einer Freigabe befinden, auf die über das Computerkonto von jedem bereitgestellten Computer zugegriffen werden kann. In diesem Beispiel wird eine Freigabe mit dem Namen „\\Contoso-Win10\Share“ auf einem Clientcomputer unter Windows 10 verwendet. Die bereitzustellende Katalogdatei wird auf diese Freigabe kopiert.

7. Wählen Sie, damit die Versionen konsistent bleiben, im Dialogfeld Neue Dateieigenschaften (Abbildung 15) die Option Ersetzen aus der Liste Aktion aus, sodass immer die neueste Version verwendet wird.

   

   Abbildung 15. Festlegen der neuen Dateieigenschaften

8. Geben Sie im Feld Quelldatei(en) den Namen Ihrer zugreifbaren Freigabe ein, wobei der Name der Katalogdatei (beispielsweise „\\Contoso-Win10\share\LOBApp-Contoso.cat“) einzuschließen ist.

9. Geben Sie im Feld Zieldatei den Text C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-Contoso.cat ein.

   Hinweis  

   Bei „LOBApp-Contoso.cat“ handelt es sich nicht um einen erforderlichen Dateinamen. Dieser Name wurde im Abschnitt Erstellen von Katalogdateien verwendet, und daher wird er auch hier verwendet.

    

10. Wählen Sie auf der Registerkarte Allgemein des Dialogfelds Neue Dateieigenschaften die Option Element entfernen, wenn es nicht mehr angewendet wird aus. Dadurch wird sichergestellt, dass die Katalogdatei von jedem System entfernt wird, wenn die Notwendigkeit besteht, dass Sie dieser Anwendung nicht mehr vertrauen können.

11. Klicken Sie auf OK, um die Dateierstellung abzuschließen.

12. Schließen Sie den Gruppenrichtlinienverwaltungs-Editor, und aktualisieren Sie dann die Richtlinie auf dem Testcomputer unter Windows 10, indem Sie „GPUpdate.exe“ ausführen. Stellen Sie, nachdem die Richtlinie aktualisiert wurde, sicher, dass auf dem Computer unter Windows 10 die Katalogdatei im Ordner „C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}“ vorhanden ist.

Bereitstellen von Katalogdateien mit System Center Configuration Manager

Als Alternative zu „Gruppenrichtlinie“ können Sie System Center Configuration Manager zum Bereitstellen von Katalogdateien auf den verwalteten Computern in Ihrer Umgebung verwenden. Durch diesen Ansatz kann die Bereitstellung und Verwaltung von mehreren Katalogdateien vereinfacht werden. Zudem bietet sie eine Berichterstellung darüber, welcher Katalog von jedem einzelnen Client oder jeder Sammlung bereitgestellt wurde. Zusätzlich zur Bereitstellung dieser Dateien kann System Center Configuration Manager zudem verwendet werden, um die aktuell bereitgestellten Katalogdateien für Berichterstellungs- und Compliancezwecke zu inventarisieren. Führen Sie die folgenden Schritte aus, um ein neues Bereitstellungspaket für Katalogdateien zu erstellen:

Hinweis  

Im folgenden Beispiel wird eine Netzwerkfreigabe mit dem Namen „\\Shares\CatalogShare“ als eine Quelle für die Katalogdateien verwendet. Wenn Sie über sammlungsspezifische Katalogdateien verfügen oder bevorzugen, sie einzeln bereitzustellen, sollten Sie die Ordnerstruktur verwenden, die sich für Ihre Organisation am besten eignet.

 

1. Öffnen Sie die Configuration Manager-Konsole, und wählen Sie den Arbeitsbereich „Softwarebibliothek“.

2. Navigieren Sie zu „Übersicht\Anwendungsverwaltung“, klicken Sie mit der rechten Maustaste auf Pakete, und klicken Sie dann auf Paket erstellen.

3. Benennen Sie das Paket, legen Sie Ihre Organisation als Hersteller fest, und wählen Sie die entsprechende Versionsnummer (Abbildung 16) aus.

   

   Abbildung 16. Angeben von Informationen über das neue Paket

4. Klicken Sie auf Weiter, und wählen Sie dann als Programmtyp Standardprogramm aus.

5. Wählen Sie auf der Seite Standardprogramm einen Namen aus, und legen Sie anschließend die Eigenschaft Befehlszeile auf XCopy \\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y fest.

6. Wählen Sie auf der Seite Standardprogramm die folgenden Optionen (Abbildung 17) aus:

   • Geben Sie unter Name den Text Contoso Catalog File Copy Program ein.

   • Navigieren Sie unter Befehlszeile zum Programmspeicherort.

   • Geben Sie unter Startordner den Text C:\Windows\System32 ein.

   • Wählen Sie in der Liste Ausführen die Option Ausgeblendet aus.

   • Wählen Sie in der Liste Programm kann ausgeführt werden die Option Unabhängig von Benutzeranmeldung aus.

   • Wählen Sie in der Liste Treibermodus die Option Unterstützt UNC-Namen aus.

   

   Abbildung 17. Angeben von Informationen über das Standardprogramm

7. Akzeptieren Sie die Standardeinstellungen für den Rest des Assistenten, und schließen Sie dann den Assistenten.

Nachdem Sie das Bereitstellungspaket erstellt haben, stellen Sie es in einer Sammlung bereit, sodass die Clients die Katalogdateien empfangen. In diesem Beispiel stellen Sie das Paket bereit, das Sie gerade für eine Testsammlung erstellt haben:

1. Navigieren Sie im Arbeitsbereich „Softwarebibliothek“ zu „Übersicht\Anwendungsverwaltung\Pakete“, klicken Sie dann mit der rechten Maustaste auf das Katalogdateipaket, und klicken Sie dann auf Bereitstellen.

2. Wählen Sie auf der Seite Allgemein die Testsammlung aus, in der die Katalogdateien bereitgestellt werden, und klicken Sie dann auf Weiter.

3. Klicken Sie auf der Seite Inhalt auf Hinzufügen, um den Verteilungspunkt auszuwählen, der die ausgewählte Sammlung mit Inhalten versorgt, und klicken Sie dann auf Weiter.

4. Wählen Sie auf der Seite Bereitstellungseinstellungen die Option Erforderlich im Feld Zweck aus.

5. Klicken Sie auf der Seite Zeitplanung auf Neu.

6. Wählen Sie im Dialogfeld Zuweisungszeitplan die Option Direkt nach diesem Ereignis zuweisen aus, legen Sie den Wert auf So bald wie möglich fest, und klicken Sie dann auf OK.

7. Klicken Sie auf der Seite Zeitplanung auf Weiter.

8. Legen Sie auf der Seite Benutzerfreundlichkeit (Abbildung 18) die folgenden Optionen fest, und klicken Sie dann auf Weiter:

   • Aktivieren Sie das Kontrollkästchen Softwareinstallation.

   • Aktivieren Sie das Kontrollkästchen Änderungen zum Stichtag oder während eines Wartungsfensters ausführen (erfordert Neustart).

   

   Abbildung 18. Angeben der Benutzerfreundlichkeit

9. Wählen Sie auf der Seite Verteilungspunkte im Feld Bereitstellungsoptionen die Option Programm vom Verteilungspunkt ausführen aus, und klicken Sie dann auf Weiter.

10. Überprüfen Sie die Angaben auf der Seite Zusammenfassung, und klicken Sie dann auf Weiter.

11. Schließen Sie den Assistenten.

Inventarisieren von Katalogdateien mit System Center Configuration Manager

Wenn Katalogdateien mithilfe von „Gruppenrichtlinie“ oder System Center Configuration Manager auf Computern in Ihrer Umgebung bereitgestellt wurden, können Sie sie mit dem Softwareinventarisierungsfeature von System Center Configuration Manager inventarisieren. Der folgende Prozess führt Sie durch die Aktivierung der Softwareinventarisierung über die Ermittlung von Katalogdateien auf Ihren verwalteten Systemen bis hin zur Erstellung und Bereitstellung einer Richtlinie für neue Clienteinstellungen.

Hinweis  

Durch eine Standardnamenskonvention für Ihre Katalogdateien wird der Katalogdatei-Softwareinventarisierungsprozess erheblich vereinfacht. In diesem Beispiel wurde -Contoso zu allen Katalogdateinamen hinzugefügt.

 

1. Öffnen Sie die Configuration Manager-Konsole, und wählen Sie den Arbeitsbereich „Verwaltung“ aus.

2. Navigieren Sie zu Übersicht\Clienteinstellungen, klicken Sie mit der rechten Maustaste auf Clienteinstellungen, und klicken Sie dann auf Benutzerdefinierte Geräteclienteinstellungen erstellen.

3. Benennen Sie die neue Richtlinie, und aktivieren Sie das Kontrollkästchen Softwareinventur in der Liste für das Auswählen und Konfigurieren der benutzerdefinierten Einstellungen für Clientgeräte, wie dies in der Abbildung 19 gezeigt wird.

   

   Abbildung 19. Auswählen der benutzerdefinierten Einstellungen

4. Klicken Sie im Navigationsbereich auf Softwareinventur, und klicken Sie dann auf Typen festlegen, wie dies in Abbildung 20 veranschaulicht wird.

   

   Abbildung 20. Festlegen der Softwareinventur

5. Klicken Sie im Dialogfeld Clienteinstellung konfigurieren auf die Schaltfläche Start, um das Dialogfeld für die Inventardateieigenschaften zu öffnen.

6. Geben Sie im Feld Name den Text *Contoso.cat ein, und klicken Sie auf Festlegen.

   Hinweis  

   *Contoso.cat ist die in diesem Beispiel verwendete Namenskonvention. Dies sollte die von Ihnen für Ihre Katalogdateien verwendete Namenskonvention imitieren.

    

7. Wählen Sie im Dialogfeld Pfadeigenschaften die Option Variable oder Pfadname aus, und geben Sie dann den Text C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} in das Feld ein, wie dies in Abbildung 21 veranschaulicht wird.

   

   Abbildung 21. Festlegen der Pfadeigenschaften

8. Klicken Sie auf OK.

9. Klicken Sie, nachdem Sie die Clienteinstellungsrichtlinie erstellt haben, mit der rechten Maustaste auf die neue Richtlinie, klicken Sie auf Bereitstellen, und wählen Sie dann die Sammlung aus, in der Sie die Katalogdateien inventarisieren möchten.

Beim nächsten Softwareinventarisierungszyklus, wenn die gewünschten Client die Richtlinie für die neuen Clienteinstellungen empfangen, können Sie die inventarisierten Dateien in den integrierten System Center Configuration Manager-Berichten oder im Ressourcen-Explorer anzeigen. So zeigen Sie die inventarisierten Dateien auf einem Client im Ressourcen-Explorer an

1. Öffnen Sie die Configuration Manager-Konsole, und wählen Sie den Arbeitsbereich „Bestand und Kompatibilität“ aus.

2. Navigieren Sie zu „Übersicht\Geräte“, und suchen Sie nach dem Gerät, auf dem Sie die inventarisierten Dateien anzeigen möchten.

3. Klicken Sie mit der rechten Maustaste auf den Computer, zeigen Sie auf Start, und klicken Sie dann auf Ressourcen-Explorer.

4. Navigieren Sie im Ressourcen-Explorer zu „Software\Dateidetails“, um die inventarisierten Katalogdateien anzuzeigen.

Hinweis  

Wenn in dieser Ansicht nichts angezeigt wird, navigieren Sie im Ressourcen-Explorer zu „Software\Letzte Softwareüberprüfung“, um sicherzustellen, dass kürzlich eine Softwareinventarisierungsüberprüfung durch den Client vorgenommen wurde.

 

Richtlinien für die Codeintegrität

Richtlinien für die Codeintegrität halten die Standards aufrecht, mit denen ein Computer unter Windows 10 bestimmt, ob eine Anwendung vertrauenswürdig ist und ausgeführt werden kann. Eine Übersicht über die Codeintegrität finden Sie im Abschnitt Konfigurierbare Codeintegrität.

Eine allgemeine Systemimageerstellungs-Methode in heutigen IT-Organisationen besteht darin, ein „goldenes“ Image als eine Referenz zu erstellen, wie ein ideales System aussehen sollte, und dann dieses Image zu verwenden, um zusätzliche Unternehmensressourcen zu klonen. Codeintegritätsrichtlinien folgen einer ähnlichen Methodologie, die mit der Errichtung eines goldenen PCs beginnt. Wie bei der Imageerstellung können Sie auf Grundlage des Modells, der Abteilung, des Anwendungssatzes usw. über mehrere goldene PCs verfügen. Auch wenn der Denkprozess hinsichtlich der Erstellung von Codeintegritätsrichtlinien dem der Imageerstellung ähnelt, sollten diese Richtlinien unabhängig verwaltet werden. Bewerten Sie die Notwendigkeit von zusätzlichen Codeintegritätsrichtlinien anhand davon, was von wem installiert und ausgeführt werden darf.

Hinweis  

Jeder Computer kann gleichzeitig nur eine Codeintegritätsrichtlinie aufweisen. Unabhängig davon, wie Sie diese Richtlinie bereitstellen, wird sie in „SIPolicy.p7b“ umbenannt und nach „C:\Windows\System32\CodeIntegrity“ kopiert. Berücksichtigen Sie dies beim Erstellen von Codeintegritätsrichtlinien

 

Optional können Codeintegritätsrichtlinien an Ihrem Softwarekatalog und den durch die IT-Abteilung genehmigten Anwendungen ausgerichtet werden. Eine einfache Methode, Codeintegritätsrichtlinien zu implementieren, besteht in der Verwendung von vorhandenen Images zum Erstellen einer Master-Codeintegritätsrichtlinie. Sie können dies vornehmen, indem Sie eine Codeintegritätsrichtlinie von jedem Image erstellen und dann die Richtlinien zusammenführen. Auf diese Weise darf das ausgeführt werden, was auf allen diesen Images installiert ist, wenn die Anwendungen auf einem Computer auf Grundlage eines anderen Images installiert werden. Alternativ können Sie auswählen, eine Richtlinie für Basisanwendungen zu erstellen und Richtlinien anhand der Rolle oder Abteilung des Computers hinzuzufügen. Organisationen können auswählen, wie ihre Richtlinien erstellt, zusammengeführt, gewartet und verwaltet werden.

Hinweis  

Im folgenden Abschnitt wird davon ausgegangen, dass Sie Codeintegritätsrichtlinien als Bestandteil Ihrer Device Guard-Bereitstellung bereitstellen. Alternativ steht die konfigurierbare Codeintegrität zur Verfügung, ohne dass dafür Device Guard aktiviert werden muss.

 

Regeln für Codeintegritätsrichtlinien

Richtlinien für die Codeintegrität bestehen aus verschiedenen Komponenten. Die zwei Hauptkomponenten, die konfigurierbar sind, werden als Richtlinienregeln bzw. Dateiregeln bezeichnet. Bei den Regeln für Codeintegritätsrichtlinien handelt es sich um Optionen, die der Ersteller der Codeintegritätsrichtlinie für die Richtlinie angeben kann. Diese Optionen umfassen die Aktivierung des Überwachungsmodus, von UMCI usw. Sie können diese Optionen in einer neuen oder vorhandenen Codeintegritätsrichtlinie ändern. Bei Dateiregeln handelt es sich um die Ebene, bis zu der Codeintegritätsrichtlinien-Überprüfungen jede binäre Vertrauensstellung binden. Beispielsweise schlüsselt die Hashebene jeden ermittelten Hash auf dem System in der generierten Codeintegritätsrichtlinie auf. Auf diese Weise gleicht, wenn die Ausführung einer binären Datei vorbereitet wird, der Codeintegritätsdienst seinen Hashwert mit den vertrauenswürdigen Hashwerten ab, die sich in der Codeintegritätsrichtlinie befinden. Auf Grundlage dieses Ergebnisses wird das Ausführen der Binärdatei zugelassen oder verweigert.

Verwenden Sie das Windows PowerShell-Cmdlet Set-RuleOption, um die Richtlinienregeloptionen einer vorhandenen Codeintegritätsrichtlinie zu ändern. Beachten Sie in den folgenden Beispielen, wie dieses Cmdlet verwendet wird, um eine Regeloption zu einer vorhandenen Codeintegritätsrichtlinie hinzuzufügen bzw. aus dieser zu entfernen:

• Fügen Sie zum Aktivieren von UMCI die Regeloption „0“ zu einer vorhandenen Richtlinie hinzu, indem Sie den folgenden Befehl ausführen:

  Set-RuleOption -Option 0 -FilePath <Path to policy>

• Entfernen Sie zum Deaktivieren von UMCI aus einer vorhandenen Codeintegritätsrichtlinie die Regeloption „0“, indem Sie den folgenden Befehl ausführen:

  Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete

Sie können verschiedene Regeloptionen in einer Codeintegritätsrichtlinie festlegen. In Tabelle 2 werden alle Regeln und die jeweils zugehörige allgemeine Bedeutung aufgeführt.

Tabelle 2. Codeintegritätsrichtlinien – Richtlinienregeloptionen

Regeloption	Beschreibung
0 Enabled:UMCI	Codeintegritätsrichtlinien schränken die Binärdateien für den Kernel- und den Benutzermodus. Standardmäßig sind nur die Binärdateien des Kernelmodus eingeschränkt. Durch das Aktivieren dieser Regeloption, werden die ausführbaren Dateien und Skripts des Benutzermodus überprüft.
1 Enabled:Boot Menu Protection	Diese Option wird derzeit nicht unterstützt.
2 Required:WHQL	Standardmäßig dürfen Legacytreiber ausgeführt werden, die nicht durch Windows Hardware Quality Labs (WHQL) signiert wurden. Durch das Aktivieren dieser Regel muss jeder ausgeführte Treiber eine WHQL-Signatur aufweisen. Zudem wird dadurch die Legacytreiberunterstützung entfernt. Künftig muss jeder neue Windows 10-kompatible Treiber WHQL-zertifiziert sein.
3 Enabled:Audit Mode (Default)	Aktivieren das Ausführen von Binärdateien außerhalb der Codeintegritätsrichtlinie. Es wird dadurch jedoch jedes Vorkommen im Ereignisprotokoll „CodeIntegrity“ protokolliert. Dieses kann verwendet werden, um die vorhandene Richtlinie vor der Erzwingung zu aktualisieren. Entfernen Sie zum Erzwingen einer Codeintegritätsrichtlinie diese Option.
4 Disabled:Flight Signing	Wenn diese Option aktiviert ist, vertrauen Codeintegritätsrichtlinien den Binärdateien nicht, die mittels Flightroot signiert wurden. Diese Option würde in dem Szenario verwendet werden, in dem Organisationen nur veröffentlichte Binärdateien ausführen möchten, nicht aber Vorabversionen.
5 Enabled:Inherent Default Policy	Diese Option wird derzeit nicht unterstützt.
6 Enabled:Unsigned System Integrity Policy (Default)	Ermöglicht der Richtlinie, nicht signiert zu bleiben. Wenn diese Option entfernt wird, muss die Richtlinie signiert werden. Zudem muss der Richtlinie „UpdatePolicySigners“ hinzugefügt werden, um künftige Richtlinienänderungen zu erlauben.
7 Allowed:Debug Policy Augmented	Diese Option wird derzeit nicht unterstützt.
8 Required:EV Signers	Diese Regel muss WHQL-signiert sein. Zudem müssen für diese Regel Treiber durch einen Partner übermittelt worden sein, der über ein Zertifikat für die erweiterte Überprüfung (Extended Verification, EV) verfügt. Alle Treiber für Windows 10 und höher erfüllen diese Anforderung.
9 Enabled:Advanced Boot Options Menu	Das F8-Menü vor dem Start ist standardmäßig für alle Codeintegritätsrichtlinien deaktiviert. Durch das Festlegen dieser Regeloption kann das F8-Menü physisch anwesenden Benutzern angezeigt werden.
10 Enabled:Boot Audit on Failure	Wird verwendet, wenn die Codeintegritätsrichtlinie sich im Erzwingungsmodus befindet. Wenn ein Treiber während des Starts einen Fehler aufweist, wechselt die Codeintegritätsrichtlinie in den Überwachungsmodus, sodass Windows geladen wird. Administratoren können die Fehlerursache im Ereignisprotokoll „CodeIntegrity“ überprüfen.

 

Anhand von Regelebenen können Administratoren die Ebene angeben, auf der sie ihren Anwendungen vertrauen möchten. Diese Vertrauensebene könnte so niedrig wie der Hashwert jeder Binärdatei, aber auch so hoch wie ein PCA-Zertifikat sein. Dateiregelebenen werden angegeben, wenn Sie eine neue Codeintegritätsrichtlinie anhand einer Überprüfung erstellen und wenn Sie eine Richtlinie anhand von Überwachungsereignissen erstellen. Zusätzlich können Sie zum Kombinieren von in mehreren Richtlinien vorhandenen Regelebenen die Richtlinien zusammenführen. Wenn sie zusammengeführt wurden, kombinieren die Codeintegritätsrichtlinien ihre Dateiregeln. Jede Dateiregelebene weist Vor- und Nachteile auf. Verwenden Sie Tabelle 3, um die entsprechende Schutzebene für Ihre verfügbaren Verwaltungsressourcen und Ihr Device Guard-Bereitstellungsszenario auszuwählen.

Tabelle 3. Codeintegritätsrichtlinien – Dateiregelebenen

Regelebene	Beschreibung
Hash	Gibt die einzelnen Hashwerte für jede ermittelte Binärdatei an. Auch wenn dies für die jeweilige Ebene spezifisch ist, kann dies zu einem Verwaltungsmehraufwand führen, um die Hashwerte der aktuellen Produktversionen zu warten. Nach jedem Aktualisieren einer Binärdatei wird der Hashwert geändert, wodurch eine Richtlinienaktualisierung erforderlich wird.
FileName	Gibt einzelne Binärdateinamen an. Auch wenn die Hashwerte für eine Anwendung geändert werden, wenn sie aktualisiert wird, ist dies für gewöhnlich bei den Dateinamen nicht der Fall. Dies bietet eine weniger spezifische Sicherheit als die Hashebene. Es ist jedoch für gewöhnlich eine Richtlinienaktualisierung erforderlich, wenn eine Binärdatei geändert wird.
SignedVersion	Hierdurch wird die Herausgeberregel mit einer Dateiversionsnummer kombiniert. Mit dieser Option kann alles vom angegebenen Herausgeber mit einer Dateiversion, die mindestens der angegebenen Versionsnummer entspricht, ausgeführt werden.
Publisher	Hierbei handelt es sich um eine Kombination des PCA-Zertifikats und des allgemeinen Namens (Common Name, CN) des untergeordneten Zertifikats. Wenn ein PCA-Zertifikat zum Signieren von Anwendungen (wie VeriSign) mehrerer Unternehmen verwendet wird, ermöglicht diese Regelebene, Organisationen dem PCA-Zertifikat zu vertrauen, jedoch nur für das Unternehmen, dessen Name sich auf dem untergeordneten Zertifikat befindet (beispielsweise Intel für Gerätetreiber). Diese Ebene vertraut einem Zertifikat mit einer langen Gültigkeitsdauer, jedoch nur in Kombination mit einem vertrauenswürdigen untergeordneten Zertifikat.
FilePublisher	Hierbei handelt es sich um eine Kombination der Herausgeberdatei-Regeleben und der SignedVersion-Regelebene. Es wird jeder signierten Datei von dem vertrauenswürdigen Herausgeber vertraut, die der angegebenen Version entspricht oder neuer ist.
LeafCertificate	Fügt vertrauenswürdige Signaturgeber auf der einzelnen Signaturzertifikatsebene hinzu. Der Vorteil, diese Ebene anstelle einzelner Hashebenen zu verwenden, besteht darin, dass die neuen Versionen des Produkts unterschiedliche Hashwerte, jedoch für gewöhnlich dasselbe Signaturzertifikat aufweisen. Mit dieser Ebene wäre keine Richtlinienaktualisierung erforderlich, um die neue Version der Anwendung auszuführen. Untergeordnete Zertifikate weisen jedoch eine wesentlich kürzere Gültigkeitsdauer auf als PCA-Zertifikate. Dies führt zu einem Verwaltungsmehraufwand, wenn die Codeintegritätsrichtlinie aktualisiert werden muss, sofern diese Zertifikate ablaufen.
PcaCertificate	Fügt den Signaturgebern das höchste Zertifikat in der angegebenen Zertifikatskette hinzu. Hierbei handelt es sich für gewöhnlich um ein Zertifikat, das sich direkt unter dem Stammzertifikat befindet, da durch die Überprüfung nicht oberhalb der vorhandenen Signatur überprüft wird, indem er in den Onlinemodus wechselt oder nach lokalen Stammspeichern sucht.
RootCertificate	Derzeit nicht unterstützt.
WHQL	Vertraut Binärdateien, wenn sie durch WHQL überprüft und signiert wurden. Dies gilt in erster Linie für Kernelbinärdateien.
WHQLPublisher	Dies ist eine Kombination der WHQL und des CNs auf dem untergeordneten Zertifikat, die primär für Kernelbinärdateien verwendet wird.
WHQLFilePublisher	Gibt an, dass die Binärdateien mit einem bestimmten Herausgeber (WHQLPublisher) durch WHQL überprüft und signiert werden und dass es sich bei der Binärdatei um die angegebene oder eine neuere Version handelt. Dies gilt in erster Linie für Kernelbinärdateien.

 

Hinweis  

Beim Erstellen von Codeintegritätsrichtlinien mit dem Cmdlet New-CIPolicy können Sie eine primäre Dateiregelebene angeben, indem Sie den Parameter –Level einschließen. Verwenden Sie für ermittelte Binärdateien, denen anhand der primären Dateiregelkriterien nicht vertraut werden kann, den Parameter –Fallback. Wenn beispielsweise die primäre Dateiregelebene „PCACertificate“ lautet, Sie jedoch auch nicht signierten Anwendungen vertrauen möchten, werden durch das Verwenden der Hashregelebene als ein Ausweich die Hashwerte von Binärdateien hinzugefügt, die kein Signaturzertifikat aufweisen.

 

Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs

Der Prozess, eine goldene Codeintegritätsrichtlinie von einem Referenzsystem zu erstellen, ist einfach. In diesem Abschnitt wird der Prozess beschrieben, der erforderlich ist, um mit der Windows PowerShell erfolgreich eine Codeintegritätsrichtlinie zu erstellen. Zunächst müssen Sie in diesem Beispiel die während des Erstellungsprozesses zu verwendenden Variablen initiieren. Anstelle Variablen zu verwenden, können Sie im Befehl einfach die vollständigen Dateipfade verwenden. Erstellen Sie als Nächstes die Codeintegritätsrichtlinie, indem Sie das System auf installierte Anwendungen überprüfen. Wenn sie erstellt wurde, wird die Richtliniendatei in das Binärformat umgewandelt, sodass ihre Inhalte durch Windows verwendet werden können.

Hinweis  

Bevor Sie mit dieser Prozedur beginnen, müssen Sie sicherstellen, dass der Referenz-PC frei von Viren und Schadsoftware ist. Jede Softwarekomponente sollte als vertrauenswürdig überprüft werden, bevor Sie mit dem Erstellen dieser Richtlinie beginnen. Achten Sie zudem darauf, dass die gesamte Software auf dem System installiert ist, die Sie überprüfen möchten, bevor Sie mit dem Erstellen der Codeintegritätsrichtlinie beginnen.

 

Kopieren Sie zum Erstellen einer Codeintegritätsrichtlinie jeden der folgenden Befehle in der folgenden Reihenfolge in eine Windows PowerShell-Sitzung mit erhöhten Rechten:

1. Initialisieren Sie die zu verwendenden Variablen:

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

   $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

2. Erstellen Sie eine neue Codeintegritätsrichtlinie, indem Sie das System auf installierte Anwendungen überprüfen:

   New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt

   Hinweis  

   Durch Angeben des Parameters –UserPEs wird der Codeintegritätsrichtlinie automatisch die Regeloption 0 Enabled:UMCI hinzugefügt. Wenn Sie diesen Parameter nicht angeben, verwenden Sie den folgenden Befehl, um UMCI zu aktivieren:

   Set-RuleOption -Option 0 -FilePath $InitialCIPolicy

    

   Hinweis  

   Sie können den Parameter –Fallback hinzufügen, um Anwendungen zu erfassen, die mithilfe der primären Dateiregelebene, welche durch den Parameter –Level angegeben wurde, nicht erkannt wurden. Weitere Informationen über Dateiregelebenen-Optionen finden Sie im Abschnitt Regeln für Codeintegritätsrichtlinien.

    

   Hinweis  

   Wenn Sie festlegen möchten, dass die Codeintegritätsrichtlinien-Überprüfung ein bestimmtes Laufwerk durchsuchen soll, können Sie dies mithilfe des Parameters –ScanPath festlegen. Ohne Angabe dieses Parameters wird das gesamte System überprüft, wie dies im Beispiel gezeigt wird.

    

3. Wandeln Sie die Codeintegritätsrichtlinie in ein binäres Format um:

   ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

Nach dem Abschließen dieser Schritte stehen die Device Guard-Binärdatei („DeviceGuardPolicy.bin“) und die ursprüngliche XML-Datei („IntialScan.xml“) auf Ihrem Desktop zur Verfügung. Sie können die binäre Version als eine Codeintegritätsrichtlinie verwenden oder sie für die zusätzliche Sicherheit signieren.

Hinweis  

Microsoft empfiehlt, dass Sie die ursprüngliche XML-Datei der Richtlinie beibehalten, um sie zu verwenden, wenn Sie die Codeintegritätsrichtlinie mit einer anderen Richtlinie zusammenführen oder die zugehörigen Regeloptionen aktualisieren müssen. Alternativ müssen Sie eine neue Richtlinie aus einer neuen Überprüfung für Wartungszwecke erstellen. Weitere Informationen über das Zusammenführen von Codeintegritätsrichtlinien finden Sie im Abschnitt Zusammenführen von Codeintegritätsrichtlinien.

 

Microsoft empfiehlt, dass jede Codeintegritätsrichtlinie im Überwachungsmodus ausgeführt wird, bevor sie erzwungen wird. So können Administratoren Richtlinienprobleme ermitteln, ohne dass Fehlermeldungs-Dialogfelder angezeigt werden. Informationen über das Überwachen einer Codeintegritätsrichtlinie finden Sie im Abschnitt Überwachen der Codeintegritätsrichtlinien.

Überwachen der Codeintegritätsrichtlinien

Wenn Codeintegritätsrichtlinien im Überwachungsmodus ausgeführt werden, können Administratoren dadurch Anwendungen, die während einer anfänglichen Richtlinienüberprüfung nicht erkannt wurden, sowie neue Anwendungen ermitteln, die nach dem Erstellen der ursprünglichen Richtlinie installiert und ausgeführt wurden. Während eine Codeintegritätsrichtlinie im Überwachungsmodus ausgeführt wird, wird jede ausgeführte Binärdatei, die verweigert werden würde, bei der die Richtlinie erzwungen wurde, im Ereignisprotokoll unter „Anwendungs- und Dienstprotokolle\Microsoft\CodeIntegrity\Betrieb“ protokolliert. Wenn diese protokollierten Binärdateien überprüft wurden, können sie einer neuen Codeintegritätsrichtlinie einfach hinzugefügt werden. Wenn die neue Ausnahmerichtlinie erstellt wird, können Sie sie mit Ihren vorhandenen Codeintegritätsrichtlinien zusammenführen.

Hinweis  

Bevor Sie diesen Prozess beginnen, müssen Sie eine Codeintegritätsrichtlinien-Binärdatei erstellen. Wenn Sie dies noch nicht vorgenommen haben, finden Sie im Abschnitt Erstellen einer Codeintegritätsrichtlinie eine schrittweise Anleitung für das Erstellen einer Codeintegritätsrichtlinie und Umwandeln dieser in das Binärformat.

 

So überwachen Sie eine Codeintegritätsrichtlinie mit der lokalen Richtlinie

1. Kopieren Sie die im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs erstellte Datei „DeviceGuardPolicy.bin“ nach „C:\Windows\System32\CodeIntegrity“.

2. Öffnen Sie auf dem System, das Sie im Überwachungsmodus ausführen möchten, den Editor für lokale Gruppenrichtlinien, indem Sie GPEdit.msc ausführen.

3. Navigieren Sie zu „Computerkonfiguration\Administrative Vorlagen\System\Device Guard“, und wählen Sie dann Codeintegritätsrichtlinie bereitstellen aus. Aktivieren Sie diese Einstellung unter Verwendung des Dateipfads „C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin“, wie dies in Abbildung 22 veranschaulicht wird.

   Hinweis  

   DeviceGuardPolicy.bin ist kein erforderlicher Richtlinienname. Dieser Name wurde einfach im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs verwendet, und daher wurde er hier auch verwendet. Diese Richtlinie muss zudem nicht auf jedes System kopiert werden. Alternativ können Sie die Codeintegritätsrichtlinien auf eine Dateifreigabe kopieren, auf die alle Computerkonten zugreifen können.

    

   Hinweis  

   Die von Ihnen hier ausgewählte Richtlinie wird in „SIPolicy.p7b“ umgewandelt, wenn sie auf einzelnen Computern bereitgestellt wird.

    

   

   Abbildung 22. Bereitstellen der Codeintegritätsrichtlinie

   Hinweis  

   Sie haben möglicherweise bemerkt, dass die GPO-Einstellung eine P7B-Datei referenziert und diese Richtlinie eine BIN-Datei verwendet. Sie werden unabhängig vom Richtlinientyp, den Sie bereitstellen (BIN, P7B oder P7), alle in „SIPolicy.p7b“ umgewandelt, wenn sie auf Computern unter Windows 10 abgelegt werden. Microsoft empfiehlt, dass Sie die Anzeigenamen Ihrer Codeintegritätsrichtlinien einfach halten und dem System erlauben, die Richtliniennamen für Sie umzuwandeln. Dadurch wird sichergestellt, dass die Richtlinien einfach unterschieden werden können, wenn sie in einer Freigabe oder in einem anderen zentralen Repository angezeigt werden.

    

4. Starten Sie das Referenzsystem neu, damit die Codeintegritätsrichtlinie wirksam wird.

5. Überwachen Sie das „CodeIntegrity“-Ereignisprotokoll. Während Sie sich im Überwachungsmodus befinden, werden Codeintegritätsrichtlinien-Ausnahmen im Ereignisprotokoll unter „Anwendungs- und Dienstprotokolle\Microsoft\CodeIntegrity\Betrieb“ protokolliert, wird dies in der Abbildung 23 veranschaulicht wird.

   

   Abbildung 23. Ausnahmen für die bereitgestellte Codeintegritätsrichtlinie

6. Überprüfen Sie die Codeintegritätsrichtlinien-Ausnahmen.

   Microsoft empfiehlt, dass jede protokollierte Ausnahme untersucht und überprüft werden sollte, nachdem Sie eine Codeintegritätsrichtlinie im Überwachungsmodus ausgeführt haben. Überprüfen Sie nach dem Ermitteln, welche Anwendung die Ausnahme auslöst, und Sicherstellen, dass sie zur Codeintegritätsrichtlinie hinzugefügt wird, welche Dateiebene verwendet werden sollte, um jeder Anwendung zu vertrauen. Auch wenn auf der Hashdatei-Regelebene alle diese Ausnahmen erfasst werden, ist dies möglicherweise nicht die beste Möglichkeit, all diesen Ausnahmen zu vertrauen. Informationen über Dateiregelebenen und über den zugehörigen Zweck finden Sie im Abschnitt Regeln für Codeintegritätsrichtlinien.

7. Erstellen Sie die Codeintegritätsrichtlinie anhand von Überwachungsereignissen.

   Informationen über das Erstellen von Codeintegritätsrichtlinien anhand von Überwachungsereignissen finden Sie im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs.

Hinweis  

Eine alternative Methode, eine Richtlinie zu testen, besteht darin, die Testdatei in „SIPolicy.p7b“ umzubenennen und im Ordner „C:\Windows\System32\CodeIntegrity“ abzulegen, anstelle sie mit der Richtlinie für den lokalen Computer bereitzustellen.

 

Erstellen und Überwachen der Codeintegritätsrichtlinie

Wenn Sie Codeintegritätsrichtlinien im Überwachungsmodus ausführen, überprüfen Sie die Ausnahmen, und bestimmen Sie, ob Sie sie zur Codeintegritätsrichtlinie hinzufügen müssen, die Sie überwachen möchten. Verwenden Sie das System, wie Sie dies für gewöhnlich tun, um sicherzustellen, dass alle Verwendungsausnahmen protokolliert werden. Wenn Sie bereit sind, eine Codeintegritätsrichtlinie anhand der Überwachungsereignisse zu erstellen, führen Sie in einer Windows PowerShell-Sitzung mit erhöhten Rechten die folgenden Schritte aus:

1. Initialisieren die zu verwendenden Variablen:

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

2. Analysieren Sie die Überwachungsergebnisse.

   Microsoft empfiehlt, dass jede Ausnahme analog zur Beschreibung in den Schritten 5 und 6 des Abschnitts Überwachen der Codeintegritätsrichtlinien analysiert werden sollte, bevor Sie beginnen, eine Codeintegritätsrichtlinie anhand von Überwachungsereignissen zu erstellen.

3. Generieren Sie eine neue Codeintegritätsrichtlinie anhand der protokollierten Überwachungsereignisse:

   New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt

Hinweis  

Wenn Sie Richtlinien anhand von Überwachungsereignissen erstellen, sollten Sie sorgfältig abwägen, welcher von Ihnen ausgewählten Dateiregelebene Sie vertrauen möchten. In diesem Beispiel verwenden Sie die Hashregelebene, die als letzte Option verwendet werden sollte.

 

Nachdem Sie diese Schritte ausgeführt haben, steht die XML-Datei für die Device Guard-Überwachungsrichtlinie („DeviceGuardAuditPolicy.xml“) auf Ihrem Desktop zur Verfügung. Sie können diese Datei nun verwenden, um die vorhandene Codeintegritätsrichtlinie zu aktualisieren, die Sie im Überwachungsmodus ausgeführt hatten, indem Sie die zwei Richtlinien zusammenführen. Anweisungen über das Zusammenführen dieser Überwachungsrichtlinie mit der vorhandenen Codeintegritätsrichtlinie finden Sie im Abschnitt Zusammenführen von Codeintegritätsrichtlinien.

Hinweis  

Sie haben möglicherweise festgestellt, dass Sie keine binäre Version dieser Richtlinie erstellt haben, wie Sie dies im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs vorgenommen haben. Dies liegt daran, da für anhand eines Überwachungsprotokolls erstellte Codeintegritätsrichtlinien nicht vorgesehen ist, dass sie als eigenständige Richtlinien ausgeführt werden. Vielmehr sollen anhand eines Überwachungsprotokolls erstellte Codeintegritätsrichtlinien nur vorhandene Codeintegritätsrichtlinien aktualisiert werden.

 

Zusammenführen von Codeintegritätsrichtlinien

Beim Entwickeln von Codeintegritätsrichtlinien müssen Sie gelegentlich zwei Richtlinien zusammenführen. Ein gängiges Beispiel hierfür ist, wenn eine Codeintegritätsrichtlinie erstmals erstellt und überwacht wird. Ein weiteres Beispiel besteht darin, wenn Sie eine einzelne Hauptrichtlinie mithilfe von mehreren Codeintegritätsrichtlinien erstellen, die zuvor anhand von goldenen PCs erstellt wurden. Da jeder Computer unter Windows 10 nur eine Codeintegritätsrichtlinie aufweisen kann, ist es wichtig, diese Richtlinien ordnungsgemäß zu verwalten. In diesem Beispiel wurden die Überwachungsereignisse in einer sekundären Codeintegritätsrichtlinie gespeichert, die Sie anschließend mit der ursprünglichen Codeintegritätsrichtlinie zusammengeführt haben.

Hinweis  

Im folgenden Beispiel werden die von Ihnen in den Abschnitten Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs und Überwachen der Codeintegritätsrichtlinien erstellten XML-Dateien für die Codeintegritätsrichtlinien verwendet. Sie können diesem Prozess folgen, jedoch mit zwei beliebigen Codeintegritätsrichtlinien, die Sie kombinieren möchten.

 

Führen Sie zum Zusammenführen von zwei Codeintegritätsrichtlinien die folgenden Schritte in einer Windows PowerShell-Sitzung mit erhöhten Rechten aus:

1. Initialisieren die zu verwendenden Variablen:

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

   $AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"

   $MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"

   $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"

   Hinweis  

   Die Variablen in diesem Abschnitt gehen speziell davon aus, eine ursprüngliche Richtlinie mit dem Namen „InitialScan.xml“ auf Ihrem Desktop sowie eine Überwachungs-Codeintegritätsrichtlinie mit dem Namen „DeviceGuardAuditPolicy.xml“ zu finden Wenn Sie andere Codeintegritätsrichtlinien zusammenführen möchten, müssen Sie die Variablen entsprechend aktualisieren.

    

2. So führen Sie zwei Richtlinien zum Erstellen einer neuen Codeintegritätsrichtlinie zusammen

   Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy

3. Wandeln Sie die zusammengeführte Codeintegritätsrichtlinie in ein binäres Format um:

   ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin

Nachdem Sie eine neue Codeintegritätsrichtlinie mit dem Namen „NewDeviceGuardPolicy.bin“ erstellt haben, können Sie die Richtlinie manuell auf den Systemen bereitstellen oder „Gruppenrichtlinie“ oder Microsoft-Clientverwaltungslösungen zum Ausführen dieser Aktion verwenden. Informationen über das Bereitstellen dieser neuen Richtlinie mit „Gruppenrichtlinie“ finden Sie im Abschnitt Bereitstellen und Verwalten von Codeintegritätsrichtlinien mit „Gruppenrichtlinie“.

Erzwingen von Codeintegritätsrichtlinien

Jede Codeintegritätsrichtlinie wird mit aktiviertem Überwachungsmodus erstellt. Nachdem Sie eine Codeintegritätsrichtlinie im Überwachungsmodus erfolgreich bereitgestellt und getestet haben und bereit sind, die Richtlinie im erzwungenen Modus zu testen, führen Sie die folgenden Schritte an einer Windows PowerShell-Sitzung mit erhöhten Rechten aus:

Hinweis  

Jede Codeintegritätsrichtlinie sollte zunächst im Überwachungsmodus getestet werden. Informationen über das Überwachen von Codeintegritätsrichtlinien finden Sie im Abschnitt Überwachen der Codeintegritätsrichtlinien.

 

1. Initialisieren die zu verwendenden Variablen:

   $CIPolicyPath=$env:userprofile+"\Desktop\"

   $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"

   $EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"

   $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"

   Hinweis  

   Die ursprüngliche Codeintegritätsrichtlinie, auf die dieser Abschnitt verweist, wurde im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs erstellt. Aktualisieren Sie die Variablen CIPolicyPath und InitialCIPolicy, wenn Sie eine andere Codeintegritätsrichtlinie verwenden.

    

2. Kopieren Sie die ursprüngliche Datei, um eine Originalkopie beizubehalten:

   cp $InitialCIPolicy $EnforcedCIPolicy

3. Entfernen Sie die Überwachungsmodus-Regeloption:

   Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete

   Hinweis  

   Anstelle eine Enforced-Option hinzuzufügen, werden Codeintegritätsrichtlinien einfach erzwungen, wenn die Option Audit Mode Enabled nicht vorhanden ist.

    

4. Wandeln Sie die neue Codeintegritätsrichtlinie in ein binäres Format um:

   ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin

   Hinweis  

   Microsoft empfiehlt dringend, dass Sie die Regeloptionen 9 und 10 aktivieren, bevor Sie eine erzwungene Richtlinie erstmals ausführen. Wenn diese in der Richtlinie bereits vorhanden sind, entfernen Sie sie nicht. Dadurch kann Windows gestartet werden, wenn die Codeintegritätsrichtlinie die Ausführung eines Kernelmodustreibers blockiert. Zudem wird Administratoren dadurch eine Eingabeaufforderung vor dem Start angezeigt. Wenn Sie für die Unternehmensbereitstellung bereit sind, können Sie diese Optionen entfernen.

    

Nachdem diese Richtlinie erzwungen wurde, können Sie sie auf Ihren Testcomputern bereitstellen. Benennen Sie die Richtlinie in „SIPolicy.p7b“ um, und kopieren Sie sie nach „C:\Windows\System32\CodeIntegrity“, um sie zu testen. Stellen Sie die Richtlinie alternativ mithilfe von „Gruppenrichtlinie“, indem Sie die im Abschnitt Bereitstellen und Verwalten von Codeintegritätsrichtlinien mit „Gruppenrichtlinie“ erteilten Anweisungen befolgen, oder mithilfe der Clientverwaltungssoftware bereit, indem Sie die Anweisungen im Abschnitt „Deploying and managing code integrity policies by using Microsoft client management solutions“ (Bereitstellen und Verwalten von Codeintegritätsrichtlinien mithilfe von Microsoft-Clientverwaltungslösungen) befolgen.

Signieren von Codeintegritätsrichtlinien mithilfe von „SignTool.exe“

Mit signierten Codeintegritätsrichtlinien erhalten Organisationen die höchste in Windows 10 verfügbare Ebene gegen den Schutz vor Schadsoftware. Zusätzlich zu ihren erzwungenen Richtlinienregeln können signierte Richtlinien durch einen Benutzer oder Administrator auf dem Computer weder geändert noch gelöscht werden. Diese Richtlinien sollen administrative Manipulationen und den missbräuchlichen Zugriff auf den Kernelmodus unterbinden. Unter diesem Aspekt ist es wesentlich schwieriger, signierte Codeintegritätsrichtlinien zu entfernen als nicht signierte. Microsoft empfiehlt, dass Sie die Richtlinie überwachen, um blockierte Anwendungen zu ermitteln, deren Ausführung zulässig sein sollte, bevor Sie damit beginnen, eine signierte Codeintegritätsrichtlinie zu signieren und bereitzustellen. Weitere Informationen über das Überwachen von Codeintegritätsrichtlinien finden Sie im Abschnitt Überwachen der Codeintegritätsrichtlinien.

Das Signieren von Codeintegritätsrichtlinien mithilfe eines lokalen durch die Zertifizierungsstelle generierten Zertifikats oder mithilfe eines erworbenen Codesignaturzertifikats ist einfach. Wenn Sie aktuell nicht über ein Codesignaturzertifikat verfügen, das in das PFX-Format exportiert wurde (mit privaten Schlüsseln, Erweiterungen und Stammzertifikaten), finden Sie unter Erstellen eines Device Guard-Codesignaturzertifikats Informationen dazu, wie Sie eins mit Ihrer lokalen Zertifizierungsstelle erstellen können. Bevor Sie Codeintegritätsrichtlinien erstmals signieren, müssen Sie die Regeloptionen 9 und 10 aktivieren, damit die Problembehandlungsoptionen für Testadministratoren verbleiben. Wenn die Richtlinien überprüft wurden und für die Unternehmensbereitstellung bereit sind, können Sie diese Optionen entfernen. Informationen über das Hinzufügen von Regeloptionen finden Sie im Abschnitt Regeln für Codeintegritätsrichtlinien.

Hinweis  

Das Signieren von Codeintegritätsrichtlinien stellt den letzten Schritt in einer Codeintegritätsbereitstellung dar. Es ist wesentlich schwieriger, eine signierte Codeintegritätsrichtlinie zu entfernen als eine nicht signierte. Bevor Sie eine signierte Codeintegritätsrichtlinie auf bereitgestellten Clientcomputern bereitstellen, müssen Sie ihre Auswirkung auf einer Teilmenge der Computer testen.

Zum Signieren einer Codeintegritätsrichtlinie mithilfe von „SignTool.exe“ benötigen Sie die folgenden Komponenten:

• Die in Windows SDK (Windows 7 oder höher) enthaltene „SignTool.exe“-Datei

• Das binäre Format der von Ihnen im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs generierten Codeintegritätsrichtlinie oder eine andere von Ihnen erstellte Codeintegritätsrichtlinie

• Ein internes Zertifizierungsstellen-Signaturzertifikat oder ein erworbenes Codesignaturzertifikat

 

Wenn Sie über kein Codesignaturzertifikat verfügen, lesen Sie den Abschnitt Erstellen eines Device Guard-Codesignaturzertifikats, um anhand einer exemplarischen Vorgehensweise zu erfahren, wie sie eins erstellen können. Ersetzen Sie beim Verwenden eines alternativen Zertifikats oder einer Codeintegritätsrichtlinie in den folgenden Schritten die Werte durch die entsprechenden Variablen bzw. das Zertifikat, damit die Befehle ordnungsgemäß funktionieren. Kopieren Sie zum Signieren einer vorhandenen Codeintegritätsrichtlinie jeden der folgenden Befehle in der folgenden Reihenfolge in eine Windows PowerShell-Sitzung mit erhöhten Rechten:

1. Initialisieren die zu verwendenden Variablen:

   $CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"

   Hinweis  

   In diesem Beispiel wird die von Ihnen im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs erstellte Codeintegritätsrichtlinie verwendet. Stellen Sie beim Signieren einer anderen Richtlinie sicher, die Variablen $CIPolicyPath und $CIPolicyBin durch die richtigen Informationen zu ersetzen.

    

2. Importieren Sie das PFX-Codesignaturzertifikat. Importieren Sie das Codesignaturzertifikat, das Sie verwenden, um die Codeintegritätsrichtlinie im persönlichen Speicher des signierenden Benutzers auf dem Computer zu signieren, auf dem die Signierung vorgenommen wird. In diesem Beispiel wird das von Ihnen im Abschnitt Erstellen eines Device Guard-Codesignaturzertifikats erstellte Zertifikat verwendet.

3. Exportieren Sie das CER-Codesignaturzertifikat. Nachdem das Codesignaturzertifikat importiert wurde, exportieren Sie die CER-Version auf Ihren Desktop. Der Richtlinie wird diese Version hinzugefügt, sodass sie später aktualisiert werden kann.

4. Navigieren Sie zu Ihrem Desktop als das Arbeitsverzeichnis.

   cd $env:USERPROFILE\Desktop

5. Fügen Sie der Codeintegritätsrichtlinie ein Aktualisierungssignaturgeber-Zertifikat hinzu:

   Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update

   Hinweis  

   <Path to exported .cer certificate> sollte der vollständige Pfad zum Zertifikat sein, das Sie in Schritt 3 exportiert haben.

    

   Hinweis  

   Das Hinzufügen von Aktualisierungssignaturgebern ist entscheidend, um diese Richtlinie künftig ändern oder deaktivieren zu können. Weitere Informationen über das Deaktivieren von signierten Codeintegritätsrichtlinien finden Sie im Abschnitt Deaktivieren von signierten Codeintegritätsrichtlinien in Windows.

    

6. Entfernen Sie die nicht signierte Richtlinienregeloption:

   Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete

7. Wandeln Sie die Richtlinie in das Binärformat um:

   ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin

8. Signieren Sie die Codeintegritätsrichtlinie mithilfe von „SignTool.exe“:

   <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin

   Hinweis  

   Bei der Variablen <Path to signtool.exe> sollte es sich um den vollständigen Pfad zum „SignTool.exe“-Hilfsprogramm handeln. ContosoDGSigningCert ist der Antragstellername des Zertifikats, das zum Signieren der Codeintegritätsrichtlinie verwendet wird. Sie sollten dieses Zertifikat in Ihren persönlichen Zertifikatsspeicher auf dem Computer importieren, den Sie zum Signieren der Richtlinie verwenden.

    

9. Überprüfen Sie die signierte Datei. Nach dem Abschluss sollten die Befehle eine signierte Richtliniendatei mit dem Namen „DeviceGuardPolicy.bin.p7“ auf Ihrem Desktop ausgeben. Sie können diese Datei auf gleiche Art und Weise bereitstellen, wie Sie eine erzwungene oder nicht erzwungene Richtlinie bereitstellen. Informationen über das Bereitstellen von Codeintegritätsrichtlinien finden Sie im Abschnitt Bereitstellen und Verwalten von Codeintegritätsrichtlinien mit „Gruppenrichtlinie“.

Deaktivieren von nicht signierten Codeintegritätsrichtlinien

Manchmal möchte ein Administrator eine Codeintegritätsrichtlinie deaktivieren. Bei nicht signierten Codeintegritätsrichtlinien ist dieser Prozess ein Leichtes. In Abhängigkeit davon, wie die Codeintegritätsrichtlinie bereitgestellt wurde, können nicht signierte Richtlinien auf zwei Arten deaktiviert werden. Wenn eine Codeintegritätsrichtlinie manuell aktiviert und zum Codeintegritätsordner-Speicherort kopiert wurde, müssen Sie die Datei einfach löschen und den Computer danach neu starten. Die folgenden Speicherorte können ausführbare Codeintegritätsrichtlinien enthalten:

• <EFI-Systempartition>\Microsoft\Boot\

• <Betriebssystemvolume>\Windows\System32\CodeIntegrity\

Wenn die Codeintegritätsrichtlinie mithilfe von „Gruppenrichtlinie“ bereitgestellt wurde, muss das GPO, das die Richtlinie zurzeit aktiviert und bereitstellt, auf „deaktiviert“ festgelegt werden. Anschließend wird die Codeintegritätsrichtlinie beim nächsten Computerneustart deaktiviert.

Deaktivieren von signierten Codeintegritätsrichtlinien in Windows

Signierte Richtlinien schützen Windows vor administrativen Manipulationen und vor Schadsoftware, die Zugriff auf administrativer Ebene auf das System erlangt hat. Daher sind signierte Codeintegritätsrichtlinien mit Absicht schwieriger zu entfernen als nicht signierte Richtlinien. Sie schützen sich grundsätzlich selbst vor Änderungen oder Entfernungen. Daher ist es selbst für Administratoren schwierig, sie erfolgreich zu entfernen. Wenn die signierte Codeintegritätsrichtlinie manuell aktiviert und in den Ordner „CodeIntegrity“ kopiert wird, müssen Sie zum Entfernen der Richtlinie die folgenden Schritte ausführen:

Hinweis  

Hierzu sollten signierte Codeintegritätsrichtlinien an den folgenden Speicherorten ersetzt und entfernt werden:

• <EFI-Systempartition>\Microsoft\Boot\

• <Betriebssystemvolume>\Windows\System32\CodeIntegrity\

 

1. Ersetzen Sie die vorhandene Richtlinie durch eine andere signierte Richtlinie, bei der die Regeloption 6 Enabled: Unsigned System Integrity Policy aktiviert ist.

   Hinweis  

   Um wirksam zu werden, muss diese Richtlinie mit einem Zertifikat signiert werden, das zuvor zum Abschnitt UpdatePolicySigners der ursprünglich signierten Richtlinie hinzugefügt wurde, die Sie ersetzen möchten.

    

2. Starten Sie den Clientcomputer neu.

3. Überprüfen Sie, ob die neue signierte Richtlinie auf dem Client vorhanden ist.

   Hinweis  

   Wenn die signierte Richtlinie, die die Regeloption 6 enthält, auf dem Client nicht verarbeitet wurde, führt das Hinzufügen einer nicht signierten Richtlinie möglicherweise zu Startfehlern.

    

4. Löschen Sie die neue Richtlinie.

5. Starten Sie den Clientcomputer neu.

Wenn die signierte Codeintegritätsrichtlinie mithilfe von „Gruppenrichtlinie“ bereitgestellt wurde, müssen Sie die folgenden Schritte ausführen:

1. Ersetzen Sie die vorhandene Richtlinie im GPO durch eine andere signierte Richtlinie, bei der die Regeloption 6 Enabled: Unsigned System Integrity Policy aktiviert ist.

   Hinweis  

   Um wirksam zu werden, muss diese Richtlinie mit einem Zertifikat signiert werden, das zuvor zum Abschnitt UpdatePolicySigners der ursprünglich signierten Richtlinie hinzugefügt wurde, die Sie ersetzen möchten.

    

2. Starten Sie den Clientcomputer neu.

3. Überprüfen Sie, ob die neue signierte Richtlinie auf dem Client vorhanden ist.

   Hinweis  

   Wenn die signierte Richtlinie, die die Regeloption 6 enthält, auf dem Client nicht verarbeitet wurde, führt das Hinzufügen einer nicht signierten Richtlinie möglicherweise zu Startfehlern.

    

4. Legen Sie das GPO auf „deaktiviert“ fest.

5. Löschen Sie die neue Richtlinie.

6. Starten Sie den Clientcomputer neu.

Deaktivieren von signierten Codeintegritätsrichtlinien im BIOS

Manchmal führen signierte Codeintegritätsrichtlinien möglicherweise zu einem Startfehler. Da Codeintegritätsrichtlinien Kernelmodustreiber erzwingen, ist es wichtig, dass sie sorgfältig in jeder Software- und Hardwarekonfiguration getestet wurden, bevor sie erzwungen und signiert werden. Signierte Codeintegritätsrichtlinien werden mithilfe von „Sicherer Start“ in der Sequenz vor dem Start überprüft. Wenn Sie das Feature „Sicherer Start“ im BIOS deaktivieren und dann die Datei an den folgenden Speicherorten auf dem Betriebssystemdatenträger löschen, kann das System in Windows gestartet werden:

• <EFI-Systempartition>\Microsoft\Boot\

• <Betriebssystemvolume>\Windows\System32\CodeIntegrity\

Bereitstellen und Verwalten von Codeintegritätsrichtlinien mit „Gruppenrichtlinie“

Codeintegritätsrichtlinien können mithilfe von „Gruppenrichtlinie“ einfach bereitgestellt und verwaltet werden. In Windows Server 2016 steht eine administrative Device Guard-Vorlage zur Verfügung. Mit dieser können Sie die Bereitstellung der Device Guard-Hardware-basierten Sicherheitsfeatures und Codeintegritätsrichtlinien vereinfachen. Im folgenden Verfahren wird eine Codeintegritätsrichtlinie mit dem Namen DeviceGuardPolicy.bin bereitgestellt, um mithilfe eines GPOs mit dem Namen Contoso GPO Test eine OU mit dem Namen DG Enabled PCs zu testen.

Hinweis  

In dieser exemplarischen Vorgehensweise wird davon ausgegangen, dass Sie zuvor eine Codeintegritätsrichtlinie erstellt haben und über einen Client-PC unter Windows 10 verfügen, auf dem Sie eine Gruppenrichtlinienbereitstellung testen können. Weitere Informationen über das Erstellen einer Codeintegritätsrichtlinie finden Sie im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs.

 

Hinweis  

Signierte Codeintegritätsrichtlinien können Startfehler verursachen, wenn sie bereitgestellt wurden. Microsoft empfiehlt, dass die signierten Codeintegritätsrichtlinien sorgfältig auf jeder Hardwareplattform getestet werden, bevor die Unternehmensbereitstellung erfolgt.

 

So stellen Sie eine Codeintegritätsrichtlinie mithilfe von „Gruppenrichtlinie“ bereit und verwalten Sie sie

1. Öffnen Sie auf einem Domänencontroller auf einem Clientcomputer, auf dem RSAT installiert ist, die Gruppenrichtlinien-Verwaltungskonsole, indem Sie GPMC.MSC ausführen oder in Windows Search nach „Gruppenrichtlinienverwaltung“ suchen.

2. Erstellen Sie ein neues GPO, klicken Sie mit der rechten Maustaste auf die OU „DG Enabled PCs“, und klicken Sie dann auf Gruppenrichtlinienobjekt hier erstellen und verknüpfen, wie dies in Abbildung 24 veranschaulicht wird.

   Hinweis  

   Bei der OU „DG Enabled PCs“ handelt es sich einfach um ein Beispiel davon, wohin das Test-GPO verknüpft wird, das im Abschnitt erstellt wurde. Es kann ein beliebiger OU-Name verwendet werden. Darüber stellt die Sicherheitsgruppenfilterung eine Option dar, wenn Sie Richtlinienpartitionierungsoptionen auf Grundlage der im Abschnitt Erreichen der Unternehmenscodeintegritäts-Bereitstellung erläuterten Strategie in Erwägung ziehen.

    

   

   Abbildung 24. Erstellen eines GPOs

3. Nennen Sie das neue GPO Contoso GPO Test. In diesem Beispiel wird „Contoso GPO Test“ als GPO-Name verwendet. Sie können für dieses Beispiel jeden gewünschten Namen auswählen.

4. Klicken Sie zum Öffnen des Gruppenrichtlinienverwaltungs-Editors mit der rechten Maustaste auf das neue GPO, und klicken Sie dann auf Bearbeiten.

5. Navigieren Sie im ausgewählten GPO zu „Computerkonfiguration\Administrative Vorlagen\System\Device Guard“. Klicken Sie anschließend mit der rechten Maustaste auf Codeintegritätsrichtlinie bereitstellen, und klicken Sie dann auf Bearbeiten.

   

   Abbildung 25. Bearbeiten der Codeintegritätsrichtlinie

6. Wählen Sie im Dialogfeld Codeintegritätsrichtlinie bereitstellen die Option Aktiviert aus, und geben Sie dann den Bereitstellungspfad für die Codeintegritätsrichtlinie an.

   In dieser Richtlinieneinstellung geben Sie den lokalen Pfad, an dem sich die Richtlinie befindet, auf dem Clientcomputer oder einen Universal Naming Convention-Pfad (UNC) an, den die Clientcomputer durchsuchen, um die neueste Version der Richtlinie abzurufen. In diesem Beispiel wurde die Datei „DeviceGuardPolicy.bin“ auf den Testcomputer kopiert. Zudem werden darin diese Einstellung aktiviert und der Dateipfad „C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin“ verwendet, wie dies in Abbildung 26 veranschaulicht wird.

   Hinweis  

   Bei DeviceGuardPolicy.bin handelt es sich nicht um einen erforderlichen Richtliniennamen. Er wird einfach im Abschnitt Erstellen von Codeintegritätsrichtlinien anhand von goldenen PCs verwendet, daher wird er auch hier verwendet. Diese Richtlinie muss zudem nicht auf jeden Computer kopiert werden. Alternativ können Sie die Codeintegritätsrichtlinien auf eine Dateifreigabe kopieren, auf die die Computerkonten zugreifen können. Die hier ausgewählte Richtlinie wird in „SIPolicy.p7b“ umgewandelt, wenn sie auf einzelnen Clientcomputern bereitgestellt wird.

    

   

   Abbildung 26. Aktivieren der Codeintegritätsrichtlinie

   Hinweis  

   Sie haben möglicherweise bemerkt, dass die GPO-Einstellung eine P7B-Datei referenziert und in diesem Beispiel eine BIN-Datei für die Richtlinie verwendet wird. Sie werden unabhängig vom Richtlinientyp, den Sie bereitstellen (BIN, P7B oder P7), alle in „SIPolicy.p7b“ umgewandelt, wenn sie auf Clientcomputern unter Windows 10 abgelegt werden. Gestalten Sie Ihre Codeintegritätsrichtlinien anzeigefreundlich, und ermöglichen Sie dem System, die Richtliniennamen für Sie umzuwandeln, um sicherzustellen, dass die Richtlinien einfach unterschieden werden können, wenn sie auf einer Freigabe oder in einem anderen zentralen Repository angezeigt werden.

    

7. Schließen Sie den Gruppenrichtlinienverwaltungs-Editor, und starten Sie den Testcomputer unter Windows 10 anschließend neu. Durch das Neustarten des Clientcomputers wird die Codeintegritätsrichtlinie aktualisiert. Informationen über das Überwachen von Codeintegritätsrichtlinien finden Sie im Abschnitt Überwachen der Codeintegritätsrichtlinien.

Erstellen eines Device Guard-Codesignaturzertifikats

Zum internen Signieren von Katalogdateien oder Codeintegritätsrichtlinien benötigen Sie entweder ein öffentlich ausgestelltes Codesignaturzertifikat oder eine interne Zertifizierungsstelle. Wenn Sie ein Codesignaturzertifikat erworben haben, können Sie diese Schritte überspringen und mit den Abschnitten fortfahren, in denen die Schritte für das Signieren von Katalogdateien und Codeintegritätsrichtlinien umrissen werden. Wenn Sie kein Zertifikat erworben haben, jedoch über eine interne Zertifizierungsstelle verfügen, führen Sie die folgenden Schritte aus, um ein Codesignaturzertifikat zu erstellen:

1. Öffnen Sie das Zertifizierungsstellen-MMC-Snap-In, und wählen Sie dann die ausstellende Zertifizierungsstelle aus.

2. Klicken Sie nach dem Herstellen der Verbindung mit der rechten Maustaste auf Zertifikatsvorlagen, und klicken Sie dann auf Verwalten, um „Zertifikatvorlagenkonsole“ zu öffnen.

   

   Abbildung 27. Verwalten der Zertifikatsvorlagen

3. Klicken Sie im Navigationsbereich mit der rechten Maustaste auf „Codesignaturzertifikat“, und klicken Sie dann auf Vorlage duplizieren.

4. Deaktivieren Sie auf der Registerkarte Kompatibilität das Kontrollkästchen Resultierende Änderungen anzeigen. Wählen Sie Windows Server 2012 in der Liste Zertifizierungsstelle und dann Windows 8 / Windows Server 2012 in der Liste Zertifikatsempfänger aus.

5. Geben Sie auf der Registerkarte Allgemein den Vorlagenanzeigenamen und Vorlagennamen an. In diesem Beispiel wird DG Catalog Signing Certificate verwendet.

6. Aktivieren Sie auf der Registerkarte Anforderungsverarbeitung das Kontrollkästchen Exportieren von privatem Schlüssel zulassen.

7. Aktivieren Sie auf der Registerkarte Erweiterungen das Kontrollkästchen Basiseinschränkungen, und klicken Sie dann auf Bearbeiten.

8. Aktivieren Sie im Dialogfeld Basiseinschränkungserweiterung bearbeiten das Kontrollkästchen Diese Erweiterung aktivieren, wie dies in Abbildung 28 veranschaulicht wird.

   

   Abbildung 28. Aktivieren der Einschränkungen für die neue Vorlage

9. Wenn der Zertifikat-Manager ausgestellte Zertifikate genehmigen muss, wählen Sie auf der Registerkarte Ausstellungsvoraussetzungen die Option Genehmigung von Zertifikatverwaltung der Zertifizierungsstelle aus.

10. Wählen Sie auf der Registerkarte Antragstellername die Option Informationen werden in der Anforderung angegeben aus.

11. Überprüfen Sie auf der Registerkarte Sicherheit, ob das zum Anfordern des Zertifikats verwendete Konto über das Recht verfügt, das Zertifikat zu registrieren.

12. Klicken Sie auf OK, um die Vorlage zu erstellen, und schließen Sie anschließend die Zertifikatvorlagenkonsole.

Wenn diese Zertifikatsvorlage erstellt wurde, müssen Sie sie im durch die Zertifizierungsstelle veröffentlichten Vorlagenspeicher veröffentlichen. Führen Sie dafür folgende Schritte aus:

1. Klicken Sie im Zertifizierungsstellen-MMC-Snap-In mit der rechten Maustaste auf Zertifikatvorlagen, zeigen Sie auf Neu, und klicken Sie dann auf Auszustellende Zertifikatvorlage, wie dies in Abbildung 29 veranschaulicht wird.

   Es wird eine Liste der verfügbaren Vorlagen angezeigt, die ausgestellt werden sollen, einschließlich der Vorlage, die Sie eben erstellt haben.

   

   Abbildung 29. Auswählen der neuen auszustellenden Zertifikatsvorlage

2. Wählen Sie das DG-Katalogsignaturzertifikat aus, und klicken Sie dann auf OK.

Sobald die Vorlage verfügbar ist, um ausgestellt zu werden, müssen Sie auf dem Computer unter Windows 10 eine anfordern, die Sie zum Erstellen und Signieren von Katalogdateien verwenden. Öffnen Sie, um zu beginnen, MMC, und führen Sie die folgenden Schritte aus:

1. Klicken Sie in MMC im Menü Datei auf Snap-In hinzufügen/entfernen. Doppelklicken Sie auf Zertifikate, und wählen Sie dann Eigenes Benutzerkonto aus.

2. Klicken Sie im Snap-In „Zertifikate“ mit der rechten Maustaste auf den Ordner für den persönlichen Speicher, zeigen Sie auf Alle Aufgaben, und klicken Sie dann auf Neues Zertifikat anfordern.

3. Klicken Sie zweifach auf Weiter, um zur Zertifikatsauswahlliste zu gelangen.

4. Wählen Sie in der Liste Zertifikat anfordern Ihr neu erstelltes Codesignaturzertifikat und dann den blauen Text aus, über den zusätzliche Informationen angefordert werden, wie dies in der Abbildung 30 veranschaulicht wird.

   

   Abbildung 30. Abrufen weiterer Informationen über Ihr Codesignaturzertifikat

5. Wählen Sie im Dialogfeld Zertifikateigenschaften für Typ die Option Allgemeiner Name aus. Wählen Sie für Wert die Option ContosoDGSigningCert aus, und klicken Sie dann auf Hinzufügen. Klicken Sie nach dem Hinzufügen auf OK.

6. Nehmen Sie die Registrierung vor, und schließen Sie den Vorgang ab.

Hinweis  

Wenn ein Zertifikat-Manager zum Genehmigen ausgestellter Zertifikate erforderlich ist und Sie ausgewählt haben, dass die Verwaltungsgenehmigung für die Vorlage erforderlich ist, muss die Anforderung in der Zertifizierungsstelle genehmigt werden, bevor sie für den Client ausgestellt wird.

 

Dieses Zertifikat muss im persönlichen Speicher des Benutzers auf dem Computer installiert sein, der die Katalogdateien und Codeintegritätsrichtlinien signiert. Wenn die Signierung auf dem Computer erfolgt, auf dem Sie jüngst das Zertifikat angefordert haben, ist das Exportieren des Zertifikats in eine PFX-Datei nicht erforderlich, da sie bereits in Ihrem persönlichen Speicher vorhanden ist. Wenn Sie die Signierung auf einem anderen Computer vornehmen, müssen Sie das PFX-Zertifikat mit den erforderlichen Schlüsseln und Eigenschaften exportieren. Führen Sie dafür folgende Schritte aus:

1. Klicken Sie mit der rechten Maustaste auf das Zertifikat, zeigen Sie auf Alle Aufgaben, und klicken Sie dann auf Exportieren.

2. Klicken Sie auf Weiter, und wählen Sie dann Ja, privaten Schlüssel exportieren aus.

3. Wählen die Standardeinstellungen und dann Alle erweiterten Eigenschaften exportieren aus.

4. Legen Sie ein Kennwort fest, wählen Sie einen Exportpfad und dann DGCatSigningCert.pfx als Dateinamen aus.

Wenn das Zertifikat exportiert wurde, importieren Sie es in den persönlichen Speicher für den Benutzer, der die Katalogdateien oder Codeintegritätsrichtlinien auf dem bestimmten Computer signiert, auf dem sie signiert werden.

Verwandte Themen

AppLocker-Übersicht

Codeintegrität

Credential Guard

Device Guard-Zertifizierung und -Compliance

Driver compatibility with Device Guard in Windows 10 (Treiberkompatibilität mit Device Guard in Windows 10)

Dropping the Hammer Down on Malware Threats with Windows 10’s Device Guard (Beseitigen von Schadsoftwarebedrohungen mit Device Guard von Windows 10)