Table of contents
TOC
Inhaltsverzeichnis reduzieren
Inhaltsverzeichnis erweitern

Bereitstellen von Richtlinien für die Codeintegrität: Richtlinienregeln und Dateiregeln

Brian Lich|Zuletzt aktualisiert: 14.03.2017
|
1 Mitwirkender

Gilt für:

  • Windows 10
  • Windows Server 2016

Richtlinien für die Codeintegrität ermöglichen die Kontrolle über einen Computer mit Windows 10 durch die Angabe, ob ein Treiber oder eine Anwendung vertrauenswürdig ist und ausgeführt werden kann. Einen Überblick über Codeintegrität finden Sie in folgenden Ressourcen:

Wenn Sie mit den Grundlagen der Codeintegritätsrichtlinie bereits vertraut sind und Informationen zum Erstellen, Überwachen und Zusammenführen von Codeintegritätsrichtlinien benötigen, lesen Sie Bereitstellen von Codeintegritätsrichtlinien: Schritte.

Das Thema umfasst die folgenden Abschnitte:

Überblick über den Prozess zum Erstellen von Codeintegritätsrichtlinien

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 Einrichtung eines goldenen Computers beginnt. Wie bei der Imageerstellung können Sie auf Grundlage des Modells, der Abteilung, des Anwendungssatzes usw. über mehrere goldene Computer 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. Weitere Informationen zu dieser Bewertung finden Sie in den Planungsschritten unter Planung und die ersten Schritte im Device Guard-Bereitstellungsprozess.

Hinweis  Für jeden Computer kann jeweils nur eine Codeintegritätsrichtlinie angegeben werden. Unabhängig davon, wie Sie diese Richtlinie bereitstellen, wird sie in SIPolicy.p7b umbenannt und nach C:\Windows\System32\CodeIntegrityund, bei UEFI-Computern, <EFI System Partition>\Microsoft\Boot 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 eine Richtlinie für Basisanwendungen erstellen und Richtlinien anhand der Rolle oder Abteilung des Computers hinzufügen. Organisationen können auswählen, wie ihre Richtlinien erstellt, zusammengeführt, gewartet und verwaltet werden.

Wenn Sie eine interne Zertifizierungsstelle zum Signieren von Katalogdateien oder Codeintegritätsrichtlinien verwenden möchten, lesen Sie die Schritte unter Optional: Erstellen eines Codesignaturzertifikats für Codeintegritätsrichtlinien.

Regeln für Codeintegritätsrichtlinien

Codeintegritätsrichtlinien enthalten Richtlinienregeln, die Optionen wie etwa den Überwachungsmodus oder die Aktivierung von UMCI in einer Codeintegritätsrichtlinie steuern. Sie können diese Optionen in einer neuen oder vorhandenen Codeintegritätsrichtlinie ändern. (Information zu Dateiregeln, die die Ebene angeben, auf der Anwendungen identifiziert und als vertrauenswürdig eingestuft werden, finden Sie im nächsten Abschnitt: Dateiregelebenen der Codeintegrität.)

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:

  • Um sicherzustellen, dass UMCI für eine Codeintegritätsrichtlinie aktiviert ist, die mit der Option -UserPEs (Benutzermodus) erstellt wurde, fügen Sie einer vorhandenen Richtlinie Regeloption 0 hinzu, indem Sie den folgenden Befehl ausführen:

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

    Beachten Sie, dass eine Richtlinie, die ohne die Option -UserPEs erstellt wurde, keine ausführbaren Dateien des Benutzermodus, d. h. Anwendungen, enthält. Wenn Sie UMCI (Option 0) für eine solche Richtlinie aktivieren und dann versuchen, eine Anwendung ausführen, erkennt Device Guard, dass die Anwendung nicht in seiner Liste (die keine Anwendungen enthält) enthalten ist, und reagiert. Im Überwachungsmodus protokolliert die Antwort ein Ereignis und im erzwungenen Modus blockiert die Antwort die Anwendung. Um eine Richtlinie zu erstellen, die ausführbare Dateien des Benutzermodus (Anwendungen) umfasst, beziehen Sie bei Ausführung von New-CIPolicy die Option -UserPEs mit ein.

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

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

Sie können verschiedene Regeloptionen in einer Codeintegritätsrichtlinie festlegen. Geben Sie zum Anzeigen einer Liste mit Regeloptionen Set- RuleOption -Help in einer Windows PowerShell-Sitzung ein. In Tabelle 2 werden die einzelnen Regeloptionen beschrieben.

Hinweis  Enabled:Audit Mode ist eine wichtige Regeloption. Es wird empfohlen, diese Option eine Zeitlang mit allen neuen Codeintegritätsrichtlinien zu verwenden, da die Richtlinien dadurch vor der Erzwingung getestet werden können. Im Überwachungsmodus wird keine Anwendung blockiert. Die Richtlinie protokolliert nur ein Ereignis, wenn eine Anwendung außerhalb der Richtlinie gestartet wird. Wenn Sie die Richtlinie erweitern möchten, sodass sie (bei ihrer Erzwingung) diese Anwendungen zulässt, können Sie mithilfe von Windows PowerShell-Befehlen die erforderlichen Richtlinieninformationen aus dem Ereignisprotokoll abrufen. Fügen Sie diese Informationen anschließend in die vorhandene Richtlinie ein.

Der Modus (Überwachungsmodus oder erzwungener Modus) wird durch Hinzufügen bzw. Löschen der Angabe Enabled:Audit Mode in der Codeintegritätsrichtlinie festgelegt. Wird diese Option gelöscht, wird die Richtlinie im erzwungenen Modus ausgeführt.

Tabelle 2 Codeintegritätsrichtlinien – Richtlinienregeloptionen

RegeloptionBeschreibung
0 Enabled:UMCICodeintegritä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 ProtectionDiese Option wird derzeit nicht unterstützt.
2 Required:WHQLStandardmäß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)Aktiviert 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. Löschen Sie diese Option, um mit der Erzwingung einer Codeintegritätsrichtlinie zu beginnen.
4 Disabled:Flight SigningWenn 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 PolicyDiese 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 AugmentedDiese Option wird derzeit nicht unterstützt.
8 Required:EV SignersDiese 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 MenuDas 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 FailureWird 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.

Dateiregelebenen der Codeintegrität

Anhand von Regelebenen können Administratoren die Ebene angeben, auf der sie ihren Anwendungen vertrauen möchten. Diese Vertrauensebene könnte so differenziert wie der Hashwert jeder Binärdatei, aber auch so allgemein wie ein Zertifizierungsstellenzertifikat sein. Sie geben Dateiregelebenen an, 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. Bei der Zusammenführung kombinieren Codeintegritätsrichtlinien ihre Dateiregeln, sodass alle Anwendungen, die durch eine der ursprünglichen Richtlinien zugelassen wurden, auch durch die kombinierte Richtlinie zugelassen werden.

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

RegelebeneBeschreibung
HashGibt 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.
FileNameGibt 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.
SignedVersionHierdurch wird die Herausgeberregel mit einer Versionsnummer kombiniert. Mit dieser Option können alle Anwendungen vom angegebenen Herausgeber mit einer Version, die mindestens der angegebenen Versionsnummer entspricht, ausgeführt werden.
PublisherHierbei handelt es sich um eine Kombination aus der PcaCertificate-Ebene (in der Regel ein Zertifikat, das sich direkt unter dem Stammzertifikat befindet) und dem allgemeinen Namen (Common Name, CN) des untergeordneten Zertifikats. Diese Regelebene ermöglicht es Organisationen, ein Zertifikat von einer großen Zertifizierungsstelle (beispielsweise Symantec) nur dann als vertrauenswürdig einzustufen, wenn das untergeordnete Zertifikat von einem bestimmten Unternehmen (im Fall von Gerätetreibern beispielsweise Intel) stammt.
FilePublisherHierbei handelt es sich um eine Kombination aus dem FileName-Attribut der signierten Datei, „Publisher“ (PCA-Zertifikat mit dem allgemeinen Namen des untergeordneten Zertifikats) und einer minimalen Versionsnummer. Mit dieser Option werden bestimmte Dateien vom angegebenen Herausgeber mit einer Dateiversion, die mindestens der angegebenen Versionsnummer entspricht, als vertrauenswürdig eingestuft.
LeafCertificateFü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 Zertifizierungsstellenzertifikate. Dies führt zu einem Verwaltungsmehraufwand, wenn die Codeintegritätsrichtlinie aktualisiert werden muss, wenn diese Zertifikate ablaufen.
PcaCertificateFügt den Signaturgebern das höchste verfügbare 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 die Überprüfung nicht über die in der bereitgestellten Signatur enthaltenen Zertifikate hinausgeht (es wird weder in den Onlinemodus gewechselt noch werden lokale Stammspeicher überprüft).
RootCertificateDerzeit nicht unterstützt.
WHQLVertraut Binärdateien, wenn sie durch WHQL überprüft und signiert wurden. Dies gilt in erster Linie für Kernelbinärdateien.
WHQLPublisherDies ist eine Kombination der WHQL und des CNs auf dem untergeordneten Zertifikat, die primär für Kernelbinärdateien verwendet wird.
WHQLFilePublisherGibt 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 unsignierten Anwendungen vertrauen möchten, werden durch das Verwenden der Hashregelebene als Ausweichlösung die Hashwerte von Binärdateien hinzugefügt, die kein Signaturzertifikat aufweisen.

Beispiel für die Verwendung von Dateiregelebenen

Das Beispiel veranschaulicht die Arbeitsweise von IT-Experten in einer Abteilung, die über mehrere Server verfügt. Die Mitarbeiter haben sich dafür entschieden, dass auf den Servern nur Software ausgeführt werden darf, die von den Anbietern der Software und Treiber signiert wurde. Anbieter sind die Unternehmen, die Hardware, Betriebssysteme, Antivirenprogramme und andere wichtige Software zur Verfügung stellen. Die Mitarbeiter wissen, dass auf den Servern auch eine intern programmierte, unsignierte Anwendung ausgeführt wird, die jedoch nur selten aktualisiert wird. Die Ausführung dieser Anwendung soll zugelassen werden.

Zur Erstellung der Codeintegritätsrichtlinie wird ein Referenzserver auf Basis der Standardhardware erstellt, auf dem die gesamte Software installiert wird, die gewöhnlich auf den Servern ausgeführt werden darf. Anschließend wird New-CIPolicy mit -Level Publisher ausgeführt (um Software von Softwareanbietern (den „Anbietern“) zuzulassen, und -Fallback Hash (um die interne, unsignierte Anwendung zuzulassen). Dadurch wird die Richtlinie im Überwachungsmodus aktiviert, und es werden Informationen zu der erforderlichen Software gesammelt, die auf dem Referenzserver nicht vorhanden ist. Die Codeintegritätsrichtlinien werden in der ursprünglichen Richtlinie zusammengeführt, um die Ausführung zusätzlicher Software zuzulassen. Anschließend wird die Codeintegritätsrichtlinie im erzwungenen Modus für die Server aktiviert.

Im Rahmen des normalen Betriebs werden schließlich Softwareupdates installiert oder ggf. Software derselben Softwareanbieter hinzugefügt. Da der "Herausgeber" dieser Updates und Softwareprogramme immer gleich bleibt, muss deren Codeintegritätsrichtlinie nicht aktualisiert werden. Sobald ein Update der intern programmierten, unsignierten Anwendung ansteht, muss auch die Codeintegritätsrichtlinie aktualisiert werden, damit der Hash der Richtlinie mit dem Hash der aktualisierten internen Anwendung übereinstimmt.

Alternativ kann auch ein Katalog erstellt werden, um Informationen über die unsignierte interne Anwendung zu erfassen. Dieser Katalog kann dann signiert und verteilt werden. Anschließend kann die interne Anwendung von Codeintegritätsrichtlinien auf die gleiche Weise behandelt werden wie jede andere signierte Anwendung. Bei einem Update der internen Anwendung muss der Katalog lediglich neu generiert, signiert und verteilt werden (kein Neustart erforderlich).

Verwandte Themen

© 2017 Microsoft