Grundlegendes zu Richtlinien- und Dateiregeln für App Control for Business
Hinweis
Einige Funktionen von App Control for Business sind nur für bestimmte Windows-Versionen verfügbar. Erfahren Sie mehr über die Verfügbarkeit von App Control-Features.
App Control for Business kann steuern, was auf Ihren Windows-Geräten ausgeführt wird, indem Richtlinien festgelegt werden, die angeben, ob ein Treiber oder eine Anwendung vertrauenswürdig ist. Eine Richtlinie enthält Richtlinienregeln, die Optionen wie den Überwachungsmodus steuern, und Dateiregeln (oder Dateiregelebenen), die angeben, wie Anwendungen identifiziert werden, denen Ihre organization vertrauen.
App Control for Business-Richtlinienregeln
Verwenden Sie den App Control-Richtlinien-Assistenten oder das PowerShell-Cmdlet Set-RuleOption , um die Richtlinienoptionen einer vorhandenen App Control-Richtlinie zu ändern.
Sie können mehrere Regeloptionen innerhalb einer App-Steuerungsrichtlinie festlegen. Tabelle 1 beschreibt jede Regeloption und gibt an, ob zusätzliche Richtlinien sie festlegen können. Einige Regeloptionen sind für zukünftige Arbeiten reserviert oder werden nicht unterstützt.
Hinweis
Es wird empfohlen, zunächst Enabled:Audit Mode zu verwenden, da Sie damit neue App-Steuerungsrichtlinien testen können, bevor Sie sie erzwingen. Im Überwachungsmodus werden Anwendungen normal ausgeführt, aber App Control protokolliert Ereignisse, wenn eine Datei ausgeführt wird, die von der Richtlinie nicht zulässig ist. Um diese Dateien zuzulassen, können Sie die Richtlinieninformationen aus dem Ereignisprotokoll erfassen und diese Informationen dann mit der vorhandenen Richtlinie zusammenführen. Wenn Aktiviert:Überwachungsmodus gelöscht wird, wird die Richtlinie im erzwungenen Modus ausgeführt.
Einige Apps verhalten sich möglicherweise anders, auch wenn sich Ihre Richtlinie im Überwachungsmodus befindet. Wenn eine Option das Verhalten im Überwachungsmodus ändern kann, ist dies in Tabelle 1 angegeben. Sie sollten Ihre Apps immer gründlich testen, wenn Sie wichtige Updates für Ihre App-Steuerungsrichtlinien bereitstellen.
Tabelle 1: App Control for Business-Richtlinie – Richtlinienregeloptionen
| Regeloption | Beschreibung | Gültige Zusatzoption |
|---|---|---|
| 0 Enabled:UMCI | App-Steuerungsrichtlinien schränken sowohl Kernelmodus- als auch Benutzermodusbinärdateien ein. 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. | Nein |
| 1 Enabled:Boot Menu Protection | Diese Option wird derzeit nicht unterstützt. | Nein |
| 2 Required:WHQL | Kerneltreiber, die nicht mit Windows Hardware Quality Labs (WHQL) signiert sind, dürfen standardmäßig ausgeführt werden. Zum Aktivieren dieser Regel ist es erforderlich, dass jeder Treiber WHQL-signiert ist und die Legacytreiberunterstützung entfernt wird. Für Windows 10 erstellte Kerneltreiber sollten WHQL-zertifiziert sein. | Nein |
| 3 Enabled:Audit Mode (Default) | Weist App Control an, Informationen zu Anwendungen, Binärdateien und Skripts zu protokollieren, die blockiert worden wären, wenn die Richtlinie erzwungen wurde. Sie können diese Option verwenden, um die potenziellen Auswirkungen Ihrer App-Steuerungsrichtlinie zu identifizieren und die Überwachungsereignisse zu verwenden, um die Richtlinie vor der Erzwingung zu verfeinern. Um eine App Control-Richtlinie zu erzwingen, löschen Sie diese Option. | Nein |
| 4 Disabled:Flight Signing | Wenn diese Option aktiviert ist, werden Binärdateien aus Windows-Insider-Builds nicht als vertrauenswürdig eingestuft. Diese Option ist nützlich für Organisationen, die nur veröffentlichte Binärdateien ausführen möchten, nicht Vorabversionen von Windows-Builds. | Nein |
| 5 Enabled:Inherit Default Policy | Diese Option ist für die zukünftige Verwendung reserviert, und hat derzeit keine Auswirkungen. | Ja |
| 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, und alle zusätzlichen Richtlinien müssen ebenfalls signiert werden. Die Zertifikate, die für zukünftige Richtlinienupdates vertrauenswürdig sind, müssen im Abschnitt „UpdatePolicySigners“ identifiziert werden. Zertifikate, die für zusätzliche Richtlinien vertrauenswürdig sind, müssen im Abschnitt SupplementalPolicySigners identifiziert werden. | Ja |
| 7 Allowed:Debug Policy Augmented | Diese Option wird derzeit nicht unterstützt. | Ja |
| 8 Required:EV Signers | Diese Option wird derzeit nicht unterstützt. | Nein |
| 9 Enabled:Advanced Boot Options Menu | Das F8-Preboot-Menü ist standardmäßig für alle App-Steuerungsrichtlinien deaktiviert. Durch das Festlegen dieser Regeloption kann das F8-Menü physisch anwesenden Benutzern angezeigt werden. | Nein |
| 10 Enabled:Boot Audit on Failure | Wird verwendet, wenn sich die App-Steuerungsrichtlinie im Erzwingungsmodus befindet. Wenn ein startkritischer Treiber während des Startvorgangs ausfällt, wird die App-Steuerungsrichtlinie in den Überwachungsmodus versetzt, sodass Windows geladen wird. Administratoren können die Fehlerursache im Ereignisprotokoll „CodeIntegrity“ überprüfen. | Nein |
| 11 Disabled:Script Enforcement | Mit dieser Option werden Optionen zur Skripterzwingung deaktiviert, die PowerShell, Windows-basierter Skripthost (wscript.exe), Windows-konsolenbasierter Skripthost (cscript.exe), HTA-Dateien, die in Microsoft HTML-Anwendungshost (mshta.exe) ausgeführt werden, und MSXML abdecken. Einige Skripthosts verhalten sich möglicherweise anders, auch wenn sich Ihre Richtlinie im Überwachungsmodus befindet. Weitere Informationen zur Skripterzwingung finden Sie unter Skripterzwingung mit App Control. HINWEIS: Diese Option wird unter Windows Server 2016 oder Windows 10 1607 LTSB nicht unterstützt und sollte unter diesen Betriebssystemen nicht verwendet werden. |
Nein |
| 12 Required:Enforce Store Applications | Wenn diese Regeloption aktiviert ist, gelten App-Steuerungsrichtlinien auch für universelle Windows-Anwendungen. | Nein |
| 13 Enabled:Managed Installer | Verwenden Sie diese Option, um von einem verwalteten Installationsprogramm installierte Anwendungen automatisch zuzulassen. Weitere Informationen finden Sie unter Autorisieren von Apps, die mit einem verwalteten App Control-Installationsprogramm bereitgestellt wurden. | Ja |
| 14 Enabled:Intelligent Security Graph Authorization | Verwenden Sie diese Option, um Anwendungen mit einem "bekannten guten" Ruf gemäß Der Definition von Microsoft Intelligent Security Graph (ISG) automatisch zuzulassen. | Ja |
| 15 Enabled:Invalidate EAs on Reboot | Wenn die Option Intelligent Security Graph (14) verwendet wird, legt App Control ein erweitertes Dateisattribut fest, das angibt, dass die Datei zur Ausführung autorisiert wurde. Diese Option bewirkt, dass App Control den Ruf für Dateien, die zuvor von der ISG autorisiert wurden, in regelmäßigen Abständen erneut überprüft. | Nein |
| 16 Enabled:Update Policy No Reboot | Verwenden Sie diese Option, um zukünftige App Control-Richtlinienupdates zuzulassen, ohne dass ein Systemneustart erforderlich ist. HINWEIS: Diese Option wird nur unter Windows 10, Version 1709 und höher, oder Windows Server 2019 und höher unterstützt. |
Nein |
| 17 Aktiviert:Zusatzrichtlinien zulassen | Verwenden Sie diese Option für eine Basisrichtlinie, um es ergänzenden Richtlinien zu ermöglichen, sie zu erweitern. HINWEIS: Diese Option wird nur unter Windows 10, Version 1903 und höher, oder Windows Server 2022 und höher unterstützt. |
Nein |
| 18 Deaktiviert:Laufzeit-Dateipfadregelschutz | Diese Option deaktiviert die standardmäßige Laufzeitüberprüfung, die nur FilePath-Regeln für Pfade zulässt, die nur von einem Administrator geschrieben werden können. HINWEIS: Diese Option wird nur unter Windows 10, Version 1903 und höher, oder Windows Server 2022 und höher unterstützt. |
Ja |
| 19 Aktiviert:Sicherheit für dynamischen Code | Aktiviert die Richtlinienerzwingung für .NET-Anwendungen und dynamisch geladene Bibliotheken. HINWEIS: Diese Option wird nur unter Windows 10, Version 1803 und höher, oder Windows Server 2019 und höher unterstützt. HINWEIS: Diese Option wird immer erzwungen, wenn eine App Control-UMCI-Richtlinie sie aktiviert. Es gibt keinen Überwachungsmodus für die .NET-Sicherheitshärtung für dynamischen Code. |
Nein |
| 20 Aktiviert:Widerrufen als nicht signiert ablaufen | Verwenden Sie diese Option, um Binärdateien, die mit gesperrten Zertifikaten signiert wurden, oder abgelaufene Zertifikate mit der Lifetime Signing-EKU für die Signatur als "Nicht signierte Binärdateien" für Prozesse/Komponenten im Benutzermodus unter Unternehmenssignaturszenarien zu behandeln. | Nein |
| Aktiviert:Dynamische Codevertrauensstellung im Entwicklermodus | Verwenden Sie diese Option, um UWP-Apps zu vertrauen, die in Visual Studio gedebuggt oder über das Geräteportal bereitgestellt werden, wenn der Entwicklermodus auf dem System aktiviert ist. | Nein |
App Control for Business-Dateiregelebenen
Anhand von Regelebenen können Administratoren die Ebene angeben, auf der Sie ihren Anwendungen vertrauen möchten. Diese Vertrauensebene kann so präzise sein wie der Hash jeder Binärdatei oder so allgemein wie ein Zertifizierungsstellenzertifikat. Sie geben Dateiregelebenen an, wenn Sie den App-Steuerungs-Assistenten oder Die PowerShell-Cmdlets für Die App-Steuerung verwenden, um Richtlinien zu erstellen und zu ändern.
Jede Dateiregelebene hat Vor- und Nachteile. Verwenden Sie Tabelle 2, um die geeignete Schutzebene für Ihre verfügbaren Verwaltungsressourcen und das App Control-Bereitstellungsszenario auszuwählen.
Hinweis
App Control-basierte Regeln funktionieren nur mit RSA-Kryptografie mit einer maximalen Schlüssellänge von 4.096 Bit. ECC-Algorithmen wie ECDSA werden nicht unterstützt. Wenn Sie versuchen, Dateien anhand von ECC-Signaturen zuzulassen, wird VerificationError = 23 für die entsprechenden 3089-Signaturinformationsereignisse angezeigt. Dateien können stattdessen durch Hash- oder Dateiattributeregeln oder mithilfe anderer Signaturgeberregeln zugelassen werden, wenn die Datei auch mit Signaturen mit RSA signiert ist.
Tabelle 2 App Control for Business-Richtlinie – Dateiregelebenen
| Regelebene | Beschreibung |
|---|---|
| Hash | Gibt einzelne Authenticode/PE-Bildhashwerte für jede ermittelte Binärdatei an. Diese Ebene ist die spezifischste Ebene und erfordert mehr Aufwand, um die Hashwerte der aktuellen Produktversionen zu verwalten. Nach jedem Aktualisieren einer Binärdatei wird der Hashwert geändert, wodurch eine Richtlinienaktualisierung erforderlich wird. |
| FileName | Gibt den ursprünglichen Dateinamen für jede Binärdatei 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. Diese Ebene bietet eine weniger spezifische Sicherheit als die Hashebene, erfordert aber in der Regel keine Richtlinienaktualisierung, wenn eine Binärdatei geändert wird. Standardmäßig verwendet diese Ebene das OriginalFileName-Attribut des Ressourcenheaders der Datei. Verwenden Sie -SpecificFileNameLevel , um ein alternatives Attribut auszuwählen, z. B. ProductName. |
| FilePath | Ab Windows 10, Version 1903, ermöglicht diese Ebene die Ausführung von Binärdateien von bestimmten Dateipfadspeicherorten. FilePath-Regeln gelten nur für Binärdateien im Benutzermodus und können nicht verwendet werden, um Kernelmodustreiber zuzulassen. Weitere Informationen zu Regeln auf FilePath-Ebene finden Sie weiter unten in diesem Artikel. |
| SignedVersion | Bei dieser Ebene wird die Herausgeberregel mit einer Versionsnummer kombiniert. Sie ermöglicht die Ausführung aller Versionen des angegebenen Herausgebers mit einer Version, die mindestens der angegebenen Versionsnummer entspricht. |
| Herausgeber | Diese Ebene kombiniert die PcaCertificate-Ebene (normalerweise ein Zertifikat unter der Wurzel) und den allgemeinen Namen (CN) des untergeordneten Zertifikats. Sie können diese Regelebene verwenden, um einem Zertifikat zu vertrauen, das von einer bestimmten Zertifizierungsstelle ausgestellt und an ein bestimmtes Unternehmen ausgestellt wurde, dem Sie vertrauen (z. B. Intel für Gerätetreiber). |
| FilePublisher | Diese Ebene kombiniert das Attribut "FileName" der signierten Datei plus "Publisher" (PCA-Zertifikat mit CN of leaf) sowie eine Mindestversionsnummer. Mit dieser Option werden bestimmte Dateien vom angegebenen Herausgeber mit einer Dateiversion, die mindestens der angegebenen Versionsnummer entspricht, als vertrauenswürdig eingestuft. Standardmäßig verwendet diese Ebene das OriginalFileName-Attribut des Ressourcenheaders der Datei. Verwenden Sie -SpecificFileNameLevel , um ein alternatives Attribut auszuwählen, z. B. ProductName. |
| LeafCertificate | Fügt vertrauenswürdige Signaturgeber auf der einzelnen Signaturzertifikatsebene hinzu. Der Vorteil der Verwendung dieser Ebene gegenüber der einzelnen Hashebene besteht darin, dass neue Versionen des Produkts unterschiedliche Hashwerte haben, aber in der Regel dasselbe Signaturzertifikat. Wenn diese Ebene verwendet wird, wäre keine Richtlinienaktualisierung erforderlich, um die neue Version der Anwendung auszuführen. Blattzertifikate haben jedoch in der Regel kürzere Gültigkeitsdauern als andere Zertifikatebenen, sodass die App-Steuerungsrichtlinie aktualisiert werden muss, wenn sich diese Zertifikate ändern. |
| PcaCertificate | Fügt den Signaturgebern das höchste verfügbare Zertifikat in der angegebenen Zertifikatskette hinzu. Bei dieser Ebene handelt es sich in der Regel um ein Zertifikat unterhalb des Stamms, da die Überprüfung nicht die vollständige Zertifikatkette über die lokalen Stammspeicher oder eine Onlineüberprüfung auflöst. |
| RootCertificate | Nicht unterstützt |
| WHQL | Vertrauen nur Binärdateien, die an Microsoft übermittelt und vom Windows Hardware Qualification Lab (WHQL) signiert wurden. Diese Ebene ist hauptsächlich für Kernel-Binärdateien vorgesehen. |
| WHQLPublisher | Diese Ebene kombiniert die WHQL-Ebene und den CN im untergeordneten Zertifikat und ist in erster Linie für Kernelbinärdateien vorgesehen. |
| WHQLFilePublisher | Diese Ebene kombiniert das Attribut "FileName" der signierten Datei sowie "WHQLPublisher" sowie eine Mindestversionsnummer. Diese Ebene ist hauptsächlich für Kernel-Binärdateien vorgesehen. Standardmäßig verwendet diese Ebene das OriginalFileName-Attribut des Ressourcenheaders der Datei. Verwenden Sie -SpecificFileNameLevel , um ein alternatives Attribut auszuwählen, z. B. ProductName. |
Hinweis
Wenn Sie App Control-Richtlinien mit New-CIPolicy erstellen, 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 z. B. die primäre Dateiregelebene „PCACertificate“ ist, Sie aber auch den nicht signierten Anwendungen vertrauen möchten, werden die Hashwerte von Binärdateien, die nicht über ein Signaturzertifikat verfügen, mithilfe der Hashregelebene als Fallback hinzugefügt,.
Hinweis
Falls zutreffend, werden die Mindest- und Höchstversionsnummern in einer Dateiregel im Richtlinien-XML als MinimumFileVersion bzw. MaximumFileVersion referenziert.
- MinimumFileVersion und MaximumFileVersion angegeben: Für Allow-Regeln sind Dateien mit einer Version zulässig, die größer oder gleich MinimumFileVersion und kleiner oder gleich MaximumFileVersion ist. Bei Deny-Regeln werden Dateien mit einer Version verweigert, die größer oder gleich MinimumFileVersion und kleiner oder gleich MaximumFileVersion ist.
- MinimumFileVersion ohne MaximumFileVersion angegeben: Für Zulassungsregeln dürfen Dateien mit einer Version ausgeführt werden, die größer oder gleich der angegebenen Version ist. Bei Deny-Regeln werden Dateien mit einer Version blockiert, die kleiner oder gleich der angegebenen Version ist.
- MaximumFileVersion ohne MinimumFileVersion angegeben: Für Zulassungsregeln dürfen Dateien mit einer Version ausgeführt werden, die kleiner oder gleich der angegebenen Version ist. Bei Deny-Regeln werden Dateien mit einer Version blockiert, die größer oder gleich der angegebenen Version ist.
Beispiel für die Verwendung von Dateiregelebenen
Stellen Sie sich beispielsweise einen IT-Experten in einer Abteilung vor, die viele Server ausführt. Sie möchten nur Software ausführen, die von den Unternehmen signiert wurde, die ihre Hardware, ihr Betriebssystem, Antivirensoftware und andere wichtige Software bereitstellen. 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.
Um die App Control-Richtlinie zu erstellen, erstellen sie einen Referenzserver auf ihrer Standardhardware und installieren die gesamte Software, die von ihren Servern ausgeführt wird. 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). Sie stellen die Richtlinie im Überwachungsmodus bereit, um die potenziellen Auswirkungen der Erzwingung der Richtlinie zu ermitteln. Mit Hilfe der Überwachungsdaten aktualisieren sie ihre App-Steuerungsrichtlinien, um jede andere Software einzuschließen, die sie ausführen möchten. Anschließend aktivieren sie die App-Steuerungsrichtlinie im erzwungenen Modus für ihre Server.
Im Rahmen des normalen Betriebs werden schließlich Softwareupdates installiert oder möglicherweise Software derselben Softwareanbieter hinzugefügt. Da der "Herausgeber" für diese Updates und Software unverändert bleibt, muss die App-Steuerungsrichtlinie nicht aktualisiert werden. Wenn die nicht signierte interne Anwendung aktualisiert wird, muss auch die App-Steuerungsrichtlinie aktualisiert werden, um die neue Version zuzulassen.
Rangfolge der Dateiregel
App Control verfügt über eine integrierte Dateiregelkonfliktlogik, die in die Rangfolge übersetzt wird. Zunächst werden alle gefundenen expliziten Ablehnungsregeln verarbeitet. Anschließend werden alle expliziten Zulassungsregeln verarbeitet. Wenn keine Verweigerungs- oder Zulassungsregel vorhanden ist, sucht app Control nach einem Managed Installer-Anspruch , wenn die Richtlinie dies zulässt. Schließlich greift die App-Steuerung auf die ISG zurück, wenn dies durch die Richtlinie zulässig ist.
Hinweis
Um es einfacher zu machen, ihre App-Steuerungsrichtlinien zu überlisten, empfiehlt es sich, separate ALLOW- und DENY-Richtlinien für Windows-Versionen beizubehalten, die mehrere App-Steuerungsrichtlinien unterstützen.
Verwenden von -SpecificFileNameLevel mit Regeln auf FileName-, FilePublisher- oder WHQLFilePublisher-Ebene
Standardmäßig verwenden die Regelebenen FileName, FilePublisher und WHQLFilePublisher das OriginalFileName-Attribut aus dem Ressourcenheader der Datei. Sie können ein alternatives Ressourcenheader-Attribut für Ihre Regeln verwenden, indem Sie -SpecificFileNameLevel festlegen. Für instance kann ein Softwareentwickler denselben ProductName für alle Binärdateien verwenden, die Teil einer App sind. Mit -SpecificFileNameLevel können Sie eine einzelne Regel erstellen, um alle Binärdateien in Ihrer Richtlinie abzudecken, anstatt einzelne Regeln für jede Datei.
Tabelle 3 beschreibt die verfügbaren Optionen für Ressourcenheaderattribute, die Sie mit -SpecificFileNameLevel festlegen können.
Tabelle 3. -SpecificFileNameLevel-Optionen
| SpecificFileNameLevel-Wert | Beschreibung |
|---|---|
| FileDescription | Gibt die vom Entwickler der Binärdatei bereitgestellte Dateibeschreibung an. |
| InternalName | Gibt den internen Namen der Binärdatei an. |
| OriginalFileName | Gibt den ursprünglichen Dateinamen der Binärdatei oder den Namen an, mit dem die Datei zuerst erstellt wurde. |
| PackageFamilyName | Gibt den Paketfamiliennamen der Binärdatei an. Der Paketfamilienname besteht aus zwei Teilen: dem Namen der Datei und der Herausgeber-ID. |
| ProductName | Gibt den Namen des Produkts an, mit dem die Binärdatei ausgeliefert wird. |
| Dateipfad | Gibt den Dateipfad der Binärdatei an. |
Weitere Informationen zu Dateipfadregeln
Dateipfadregeln bieten nicht dieselben Sicherheitsgarantien wie explizite Signaturgeberregeln, da sie auf änderbaren Zugriffsberechtigungen basieren. Dateipfadregeln eignen sich am besten für Umgebungen, in denen die meisten Benutzer als Standard und nicht als Administrator ausgeführt werden. Pfadregeln eignen sich am besten, um Pfade zuzulassen, von denen Sie erwarten, dass sie nur vom Administrator schreibbar bleiben. Sie sollten Pfadregeln für Verzeichnisse vermeiden, in denen Standardbenutzer ACLs für den Ordner ändern können.
Beschreibbare Dateipfade
Standardmäßig führt App Control zur Laufzeit eine Benutzerschreibbarkeitsprüfung durch, die sicherstellt, dass die aktuellen Berechtigungen für den angegebenen Dateipfad nur Schreibzugriff für Administratorbenutzer zulassen.
Es gibt eine definierte Liste von SIDs, die App Control als Administratoren erkennt. Wenn ein Dateipfad Schreibberechtigungen für eine SID zulässt, die nicht in dieser Liste enthalten ist, gilt der Dateipfad als vom Benutzer beschreibbar, auch wenn die SID einem benutzerdefinierten Administratorbenutzer zugeordnet ist. Um diese Sonderfälle zu behandeln, können Sie die vom Administrator beschreibbare Überprüfung der App-Laufzeit mit der zuvor beschriebenen Option Disabled:Runtime FilePath Rule Protection überschreiben.
Die Liste der bekannten Administrator-SIDs von App Control ist:
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
Wenn Dateipfadregeln mit New-CIPolicy generiert werden, wird für jede Datei, die in den gescannten Pfaden ermittelt wird, eine eindeutige, vollqualifizierte Pfadregel generiert. Um Regeln zu erstellen, die stattdessen alle Dateien unter einem angegebenen Ordnerpfad zulassen, verwenden Sie New-CIPolicyRule zum Definieren von Regeln, die Platzhalter enthalten, unter Verwendung des Switches -FilePathRules.
Verwenden von Wildcards in App Control-Dateipfadregeln
Die folgenden Wildcards können in App Control-Dateipfadregeln verwendet werden:
| Platzhalterzeichen | Bedeutung | Unterstützte Betriebssysteme |
|---|---|---|
* |
Entspricht null oder mehr Zeichen. | Windows 11, Windows 10 und Windows Server 2022 |
? |
Entspricht einem einzelnen Zeichen. | Nur Windows 11 |
Sie können auch die folgenden Makros verwenden, wenn die genaue Anzahl variieren kann: %OSDRIVE%, %WINDIR%, %SYSTEM32%. Diese Makros können in Kombination mit den oben genannten Wildcards verwendet werden.
Hinweis
Auf Windows 11 können Sie einen oder mehrere Wildcards überall innerhalb einer Dateipfadregel verwenden.
In allen anderen Windows- und Windows Server-Versionen ist nur ein Einziger -Wildcard pro Pfadregel zulässig und muss sich am Anfang oder Ende einer Pfadregel befinden.
Beispiel für Dateipfadregeln mit Wildcards
| Beispiele | Beschreibung | Unterstützte Betriebssysteme |
|---|---|---|
|
C:\Windows\* D:\EnterpriseApps\MyApp\* %OSDRIVE%\Windows\* |
Platzhalter, die am Ende eines Pfads platziert werden, autorisieren alle Dateien im unmittelbaren Pfad und die zugehörigen Unterverzeichnisse rekursiv. | Windows 11, Windows 10 und Windows Server 2022 |
| *\bar.exe | Platzhalter, die am Anfang eines Pfads platziert werden, lassen den genau angegebenen Dateinamen an einem beliebigen Speicherort zu. | Windows 11, Windows 10 und Windows Server 2022 |
|
C:\*\CCMCACHE\*\7z???? -x64.exe %OSDRIVE%\*\CCMCACHE\*\7z???? -x64.exe |
In der Mitte eines Pfads verwendete Wildcards lassen alle Dateien zu, die diesem Muster entsprechen. Berücksichtigen Sie sorgfältig alle möglichen Übereinstimmungen, insbesondere wenn Ihre Richtlinie die überprüfung vom Administrator beschreibbar mit der Option Disabled:Runtime FilePath Rule Protection deaktiviert. In diesem Beispiel würden beide hypothetischen Pfade übereinstimmen:C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe C:\USERS\AppControlUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe |
Nur Windows 11 |
Ohne einen Wildcard lässt die Dateipfadregel nur eine bestimmte Datei zu (z. B. C:\foo\bar.exe).
Hinweis
Beim Erstellen von App Control-Richtlinien mit Configuration Manager gibt es eine Option zum Erstellen von Regeln für angegebene Dateien und Ordner. Diese Regeln sind keine App Control-Dateipfadregeln. Stattdessen führt Configuration Manager eine einmalige Überprüfung der angegebenen Dateien und Ordner durch und erstellt Regeln für alle Binärdateien, die zum Zeitpunkt der Überprüfung an diesen Speicherorten gefunden wurden. Dateiänderungen an den angegebenen Dateien und Ordnern nach dieser Überprüfung sind nur zulässig, wenn die Configuration Manager Richtlinie erneut angewendet wird.
Weitere Informationen zu Hashes
App Control verwendet den Authenticode/PE-Bildhashalgorithmus , wenn der Hash einer Datei berechnet wird. Im Gegensatz zum häufiger bekannten Flatfile-Hash werden bei der Authenticode-Hashberechnung die Prüfsumme der Datei, die Zertifikattabelle und die Attributzertifikattabelle weggelassen. Daher ändert sich der Authenticode-Hash einer Datei nicht, wenn die Signaturen und Zeitstempel der Datei geändert werden oder wenn eine digitale Signatur aus der Datei entfernt wird. Mithilfe des Authenticode-Hashs bietet App Control zusätzliche Sicherheit und weniger Verwaltungsaufwand, sodass Kunden die Richtlinienhashregeln nicht überarbeiten müssen, wenn die digitale Signatur in der Datei aktualisiert wird.
Der Authenticode/PE-Imagehash kann für digital signierte und nicht signierte Dateien berechnet werden.
Warum erstellt die Überprüfung vier Hash-Regeln pro XML-Datei?
Das PowerShell-Cmdlet erzeugt einen Authenticode Sha1-Hash, einen Sha256-Hash, einen Sha1-Seitenhash, einen Sha256-Seitenhash. Während der Überprüfung wählt App Control aus, welche Hashes basierend auf der Signatur der Datei und dem Szenario, in dem die Datei verwendet wird, berechnet werden. Wenn die Datei beispielsweise seitenhashsigniert ist, überprüft App Control jede Seite der Datei und vermeidet das Laden der gesamten Datei in den Arbeitsspeicher, um den vollständigen sha256 authenticode-Hash zu berechnen.
Anstatt vorherzusagen, welcher Hash verwendet wird, berechnen und verwenden wir in den Cmdlets die vier Hashes (sha1/sha2 authenticode und sha1/sha2 der ersten Seite). Diese Methode ist auch resilient gegenüber Änderungen bei der Art und Weise, wie die Datei signiert wird, da Ihre App Control-Richtlinie bereits mehr als einen Hash für die Datei zur Verfügung hat.
Warum erstellt die Überprüfung acht Hashregeln für bestimmte Dateien?
Für UMCI und KMCI werden separate Regeln erstellt. Wenn die Cmdlets nicht feststellen können, dass eine Datei nur im Benutzermodus oder im Kernel ausgeführt wird, werden Aus vorsichtshalber Regeln für beide Signierungsszenarien erstellt. Wenn Sie wissen, dass eine bestimmte Datei nur im Benutzermodus oder Kernel geladen wird, können Sie die zusätzlichen Regeln sicher entfernen.
Wann verwendet App Control den Flatfile-Hashwert?
Es gibt einige seltene Fälle, in denen das Format einer Datei nicht der Authenticode-Spezifikation entspricht, sodass App Control auf die Verwendung des Flatfile-Hash zurückfällt. Dieses Verhalten kann aus vielen Gründen auftreten, z. B. wenn zur Laufzeit Änderungen an der In-Memory-Version der Datei vorgenommen werden. In solchen Fällen sehen Sie, dass der im korrelierten 3089-Signaturinformationsereignis angezeigte Hash mit dem Flatfile-Hash aus dem Blockereignis 3076/3077 übereinstimmt. Um Regeln für Dateien mit einem ungültigen Format zu erstellen, können Sie der Richtlinie für den Flatfile-Hash mithilfe des App-Steuerelement-Assistenten oder durch direktes Bearbeiten des Richtlinien-XML-Codes Hashregeln hinzufügen.