AppLocker effektive Richtlinie: Benutzerregeln testen

Was ist eine effektive AppLocker-Richtlinie?

Die AppLocker effektive Richtlinie ist die Richtlinie, die auf einem bestimmten Windows-Computer über Group Policy gilt. Sie kombiniert die lokale AppLocker-Richtlinie mit den angewendeten AppLocker-Richtlinien der Domäne. Ihre Prüfung hilft festzustellen, welche Regeln eine Datei für den vorgesehenen Benutzer betreffen sollten. Eine GPO namens „AppLocker“ ist eine administrative Bezeichnung; sie belegt weder diese Regeln noch ihren Modus oder eine blockierte Ausführung. Referenz zu Get-AppLockerPolicy

Für ein Active-Directory-Team, das einen Befund zur Anwendungskontrolle untersucht, ist das nützliche Ergebnis ein Nachweisprotokoll mit Bezug zu Gerät, Benutzer und Arbeitslast. Bestimmen Sie den Bereitstellungskanal, sichern Sie die effektive Richtlinie, prüfen Sie ihre Regelsammlungen, bewerten Sie repräsentative Dateien und planen Sie einen kontrollierten Ausführungstest. Halten Sie fehlende Messungen sichtbar, bis ein Administrator sie erheben kann.

Diese Anleitung verwendet Primärdokumentation, die am 4. Oktober 2026 geprüft wurde, sowie die unten beschriebene Collector-Implementierung. Die PowerShell-Befehle sind dokumentationsbasierte Beispiele für autorisierte Administratoren. Für diesen Artikel wurden sie auf keinem Endgerät ausgeführt; es werden weder Testergebnisse noch eine erfolgreiche Behebung behauptet.

Funktionsweise: Bereitstellungskanal und Regelsammlungen bestimmen

Schritt 1: Group Policy und CSP-Bereitstellung unterscheiden

Fragen Sie den Verantwortlichen für die Geräteverwaltung, ob AppLocker über Group Policy oder den AppLocker configuration service provider (CSP) bereitgestellt wird. Die Referenz von Microsoft zu Get-AppLockerPolicy erklärt ausdrücklich, dass das Cmdlet nur GP-Bereitstellungen versteht und falsche Daten zurückgeben kann, wenn die Richtlinie über CSP angewendet wurde. Ein leerer GP-Export beantwortet die CSP-Frage nicht.

Die Referenz zu AppLocker CSP dokumentiert Einschränkungen beim Start von Anwendungen anhand sammlungsspezifischer Richtlinienknoten. Sichern Sie bei einem CSP-verwalteten Gerät das zuständige Verwaltungsprofil, die Payloads der Regelsammlungen und die Nachweise der Richtlinienanwendung auf dem Gerät über diesen Kanal. Legen Sie fest, wie das Verwaltungsteam den auf dem Gerät angewendeten Zustand nachweisen wird, bevor Sie eine Abdeckung behaupten. Das GP-Exportverfahren dieses Artikels kann diese Nachweise für CSP nicht liefern.

Erfassen Sie Folgendes, bevor Sie den Prüfpfad wählen:

Diese Felder bilden einen vorgeschlagenen Prüfdatensatz. Füllen Sie sie mit tatsächlichen Beobachtungen; ein Richtlinienname oder eine unbestätigte Zuweisung genügt nicht, um eine Zeile abzuschließen.

Schritt 2: Regelsammlungen und Durchsetzungsmodi erfassen

Microsoft definiert fünf AppLocker-Regelsammlungen: ausführbare Dateien, Windows-Installer-Dateien, Skripte, DLLs sowie paketierte Apps und Installationsprogramme. Ein auf ausführbare Dateien begrenzter Test lässt andere relevante Sammlungen ungeprüft. Die DLL-Sammlung ist standardmäßig nicht aktiviert; prüfen Sie ihre Auswirkungen auf Kompatibilität und Leistung, bevor Sie sie in den Piloten aufnehmen.

Bewahren Sie für jede relevante Sammlung die Regeln, Benutzer- oder Gruppen-SIDs, Bedingungen, Ausnahmen und den konfigurierten Modus auf. Das XML-Schema der CSP-Referenz enthält für die Durchsetzung von Sammlungen die Werte AuditOnly, Enabled und NotConfigured. Sichern Sie den exakt beobachteten Wert zusammen mit der Konsoleneinstellung und der Bereitstellungsquelle; fassen Sie nicht die ganze Richtlinie als „aktiviert“ zusammen, nur weil eine Sammlung durchgesetzt wird.

Microsofts Verfahren für Audit only unterscheidet zwischen der Bewertung von Regeln mit Protokollierung der Entscheidungen und ihrer Durchsetzung. Eine Sammlung im Auditmodus kann Dateien identifizieren, die abgelehnt würden, während diese Dateien weiterhin ausgeführt werden. Erfassen Sie eine fehlende Sammlung oder einen unklaren Modus als gesonderten Prüfpunkt, statt aus einer anderen Sammlung Schutz abzuleiten.

Wenn Ihre Umgebung auch WDAC verwendet, erklärt unser Leitfaden zur Prüfung von App-Control-Richtlinienidentität und Aktivierung das CiTool-Inventar und die Nachweise zu Code-Integrity-Richtlinien. Unser Leitfaden zur Prüfung von Defender-ASR-Endpunkt-GUIDs und Aktionen prüft die Konfiguration von Verhaltensregeln mit Get-MpPreference. Bewahren Sie beim gleichzeitigen Einsatz die eigenen Nachweise jeder Kontrolle auf.

Erkennung: Exportieren, bewerten und Ausführungsnachweise zuordnen

Schritt 1: Die über GP bereitgestellte effektive Richtlinie exportieren

Auf dem untersuchten, über GP verwalteten Computer verwendet Microsofts Testverfahren eine administrative Windows-PowerShell-Sitzung, um die Richtlinie zu exportieren:

Get-AppLockerPolicy -Effective -XML > C:\Effective.xml

Wählen Sie einen autorisierten Ablageort für Nachweise und sichern Sie den Originalexport mit Angaben zu Host, Zeitpunkt und Bereitstellungskanal. Prüfen Sie vor Dateitests alle relevanten Sammlungen. Ein fehlgeschlagener Export ist ein Fehler bei der Datenerhebung; ein Export mit unerwartetem Inhalt erfordert eine Untersuchung im Vergleich zur vorgesehenen Konfiguration. Keines dieser Ergebnisse wird durch das Weglassen des Geräts zu einem konformen Ergebnis.

Bewerten Sie mit diesem Export den beobachteten GP-Zustand. Wenn Sie stattdessen eine vorgeschlagene Richtlinie bewerten, kennzeichnen Sie sie als Kandidaten und bewahren Sie sie getrennt auf. Der Test einer Kandidaten-XML-Datei belegt nicht, dass ein Gerät diesen Kandidaten erhalten hat.

Schritt 2: Repräsentative Dateien für den vorgesehenen Benutzer testen

Dasselbe Microsoft-Verfahren enthält dieses Beispiel mit einem Office-Verzeichnis und einem Beispielbenutzer:

Get-ChildItem 'C:\Program Files\Microsoft Office\' -filter *.exe -Recurse | Convert-Path | Test-AppLockerPolicy -XMLPolicy C:\Effective.xml -User contoso\zwie -Filter Denied,DeniedByDefault | Export-CSV C:\BlockedFiles.csv

Ersetzen Sie Verzeichnis, Identität und Ausgabeort durch für die Prüfung freigegebene Werte. Dieser Befehl bewertet Dateien anhand der angegebenen Richtlinie und exportiert gefilterte Entscheidungen. Der Dateiname macht die CSV nicht zu einem Protokoll blockierter Ausführungen. Der Filter für ausführbare Dateien im Beispiel testet außerdem weder Skripte noch Installationsprogramme, DLL-Abhängigkeiten oder paketierte Apps.

Die Referenz zu Test-AppLockerPolicy nennt Allowed, AllowedByDefault, Denied und DeniedByDefault als Entscheidungsfilter. Bewahren Sie neben jedem gezielten Bericht über abgelehnte Dateien auch eine ungefilterte Bewertung auf. Andernfalls lässt ein leerer Bericht, der nur Ablehnungen enthält, weder erkennen, welche Dateien bewertet wurden, noch bestätigen, dass die vorgesehenen verbotenen Fälle enthalten waren.

Geben Sie für Regeln mit verschachtelten Gruppen ein repräsentatives Einzelkonto an, wie die Cmdlet-Referenz empfiehlt. Der Test eines Gruppennamens oder des Administrators, der den Export erhoben hat, kann eine andere Berechtigungsfrage beantworten als den Zugriff des vorgesehenen Benutzers. Wiederholen Sie die Bewertung für wesentlich unterschiedliche Benutzerpopulationen und sichern Sie deren Identitäten zusammen mit den Ergebnissen.

Erstellen Sie mit den Anwendungsverantwortlichen eine begrenzte Testmenge. Nehmen Sie gegebenenfalls freigegebene Abläufe für Start, Installation, Aktualisierung und Skripte auf, dazu harmlose Dateien, die bewusst außerhalb der freigegebenen Anwendungen liegen. Erfassen Sie für jeden Fall die erwartete Entscheidung, die Datei- oder Paketidentität, die relevante Sammlung, den Benutzer und das Bewertungsergebnis. Fehlende Dateien und Bewertungsfehler bleiben ausdrückliche Lücken. Leiten Sie aus einem engen Verzeichnisscan kein bestandenes Ergebnis ab.

Schritt 3: Die richtigen AppLocker-Protokolle prüfen

Microsofts Überwachungsverfahren verortet die AppLocker-Protokolle unter Applications and Services Logs → Microsoft → Windows → AppLocker. Prüfen Sie EXE and DLL für diese Dateitypen und MSI and Script für Installationsprogramme und Skripte; beziehen Sie Packaged app-Deployment und Packaged app-Execution ein, wenn diese Sammlungen im Umfang liegen.

Die AppLocker-Ereignisreferenz dokumentiert diese nützlichen Unterschiede:

Microsofts Dokumentation zu Skriptregeln schränkt die Aussage von Skriptblockierungsereignissen ein: Der Skripthost implementiert die Durchsetzung. Als blockiert gemeldete PowerShell-Skripte können weiterhin im Constrained Language Mode laufen; autorisierte Skripte laufen im Full Language Mode. Erfassen Sie bei einem Skripttest den Host, Sprachmodus und die beobachteten Vorgänge, statt Ereignis 8007 allein als Beweis zu behandeln, dass kein Skriptcode ausgeführt wurde.

Bewahren Sie vollständige Ereignisdetails einschließlich Datei, Zeitpunkt, Regelkontext und Identität mit dem Testdatensatz auf. Ein Ereignis zu einer einzelnen versuchten Dateiausführung belegt keine Abdeckung für jede Arbeitslast oder jeden Benutzer. Bei stillen Protokollen müssen vor der Interpretation die ausgeübten Aktivitäten, Berechtigungen zur Protokollerhebung und Aufbewahrung geprüft werden.

Behebung: Einen wiederherstellbaren Piloten vom Audit zur Durchsetzung validieren (Remediation)

Schritt 1: Erwartetes Verhalten vor Regeländerungen freigeben

Klären Sie drei operative Entscheidungen: Welche Nachweise decken den Bereitstellungskanal ab, welche Sammlungen und Modi betreffen den vorgesehenen Benutzer, und welche zugelassenen und verbotenen Szenarien werden im Labor validiert? Benennen Sie Richtlinienverantwortlichen, Anwendungsfreigebende und Wiederherstellungsverantwortlichen. Sichern Sie vor der Verteilung einer Änderung die aktuelle Richtlinie und ein freigegebenes Wiederherstellungsverfahren.

Verwenden Sie wiederherstellbare Pilotgeräte und harmloses Testmaterial. Vereinbaren Sie, welche erforderlichen Abläufe verfügbar bleiben müssen und welche verbotenen Fälle nach der Durchsetzung scheitern müssen. Ein Fehler in einem erforderlichen Verwaltungs- oder Geschäftsablauf stoppt die Ausweitung, bis dessen Verantwortlicher die Regel geprüft hat. Auch ein unerwartet zugelassenes Ergebnis für einen verbotenen Fall muss untersucht werden; erfolgreiche geschäftliche Nutzung allein belegt die vorgesehene Einschränkung nicht.

Schritt 2: Audit only konfigurieren und den Piloten erproben

Verwenden Sie für eine über GPO verwaltete Richtlinie die Group Policy Management Console zur Verwaltung der zuständigen GPO. Microsofts Verfahren für Audit only weist Administratoren an, AppLocker → Properties → Enforcement zu öffnen, Configured für jede gewählte Sammlung auszuwählen, Audit only zu wählen und zu bestätigen. Local Security Policy ist das entsprechende Werkzeug für die Verwaltung lokaler Richtlinien.

Prüfen Sie vor der Erprobung des Piloten, dass Application Identity (AppIDSvc) läuft. Microsoft erklärt, dass das Stoppen dieses Dienstes die AppLocker-Durchsetzung verhindert. Konfigurieren Sie bei einer Group-Policy-Bereitstellung den automatischen Start in mindestens einer GPO, die AppLocker-Regeln anwendet, unter Computer Configuration → Windows Settings → Security Settings → System Services → Application Identity. Sichern Sie den beobachteten Dienstzustand mit dem Richtlinienexport. Verfahren für den Dienst Application Identity

Erheben Sie nach der Anwendung die Richtlinie erneut und wiederholen Sie die Bewertungen für den vorgesehenen Benutzer. Erproben Sie die freigegebenen Szenarien im Piloten und prüfen Sie die Auditereignisse anhand der erwarteten Entscheidungen. Bitten Sie Anwendungsverantwortliche, Abhängigkeiten und vorgeschlagene Ausnahmen zu erklären. Verknüpfen Sie jede Ausnahme mit einer konkreten Anforderung, einem Freigebenden und einer Prüfentscheidung. Machen Sie nicht aus jeder auditierten Datei eine Zulassungsregel, nur um Auditmeldungen zu beseitigen.

Schritt 3: Freigegebene Sammlungen durchsetzen und die Ausführung validieren

Microsofts Verfahren für Enforce rules verwendet dieselbe Registerkarte Properties → Enforcement: Wählen Sie Configured für die zu ändernde Sammlung und anschließend Enforce rules. Nehmen Sie diese Änderung nach der Pilotprüfung über den festgelegten Verantwortlichen und Kanal vor. Eine CSP-Bereitstellung benötigt ihr eigenes freigegebenes Verwaltungsverfahren.

Exportieren Sie die GP-Richtlinie nach der Anwendung erneut, vergleichen Sie Sammlungen und Modi und wiederholen Sie die Regelbewertung. Führen Sie anschließend die freigegebenen Ausführungstests als vorgesehener Benutzer im Piloten durch. Erfassen Sie für erforderliche wie für verbotene Szenarien das tatsächliche Verhalten und die zugehörigen Ereignisse. Wenn das Verhalten von der Bewertung abweicht, untersuchen Sie vor der Ausweitung das Richtlinienartefakt, den Anwendungszustand, Benutzerkontext und die relevante Sammlung.

Gehen Sie erst zu weiteren Populationen über, wenn benannte Prüfer die Nachweise und Wiederherstellungsbereitschaft akzeptieren. Halten Sie unbekannte Geräte und ungetestete Arbeitslasten im Änderungsprotokoll fest. Das Abschlusskriterium ist das freigegebene, auf der untersuchten Population beobachtete Verhalten mit dokumentierten Einschränkungen und Ausnahmen.

Wie EtcSec dies erkennt

Der etc-collector von EtcSec enthält ANSSI_R37_APPLOCKER_NOT_ENFORCED. Am Commit 0423094759d50002457031317098417993e19510 wandelt Detect() in public/internal/audit/detectors/ad/compliance/anssi/anssi-r37-applocker-not-enforced.go:41 den DisplayName jeder erhobenen GPO in Kleinbuchstaben um und sucht nach applocker, wdac, code integrity oder srp. Ein übereinstimmender Name genügt, damit Count 0 bestehen bleibt; kein übereinstimmender Name erzeugt Count 1 mit dem Schweregrad Medium. Dieser Zähler zählt keine ungeschützten Endgeräte.

Das Prädikat liest weder AppLocker-XML-Regeln noch Sammlungsmodi oder benutzerspezifische Berechtigungen. Es belegt nicht die Anwendung einer GPO auf ein Gerät. Ein passender Name kann das Signal ohne Durchsetzung unterdrücken; eine echte Richtlinie mit anderem Namen kann das Signal bestehen lassen. Das Umbenennen einer GPO verändert diese Heuristik, ohne eine Sicherheitsverbesserung zu belegen.

Der LDAP-Provider in public/internal/providers/ldap/client.go:1007 ruft GPO-Metadaten ab. Ein Suchfehler gibt einen Fehler zurück, doch public/internal/audit/engine.go:521 verwirft den GetGPOs-Fehler bei der Zuweisung der zurückgegebenen GPOs. Daher kann dieses Signal allein nicht zwischen einer fehlgeschlagenen GPO-Erhebung und einer erfolgreichen Erhebung ohne Namenshinweise unterscheiden. Stellen Sie vor der Interpretation unabhängig die Qualität der Erhebung fest.

R37 ist ein historischer Detektoridentifikator, nicht die Nummer der normativen AppLocker-Empfehlung. Der Code ordnet diese Prüfung ANSSI PA-099 R11 zu. Der PA-099-Leitfaden vom 2. Oktober 2023, Seite 28 empfiehlt System- und Softwarehärtung, die zur Tier-Isolation beiträgt. Diese breite Empfehlung macht die Namensheuristik nicht zu einem AppLocker-spezifischen Konformitätstest.