AppLocker, App Control for Business (WDAC) und die Verteilung von Business-Apps — Bevor die „Ausführungssteuerung“ blockiert

„Wir haben die App auf dem PC des Kunden installiert, aber sie startet nicht. Ein Doppelklick zeigt keine Reaktion.“ – Rückmeldungen dieser Art erreichen uns bei im Auftrag entwickelten Windows-Apps immer häufiger. Untersucht man die Ursache, stellt sich heraus, dass es die beim Kunden zunehmend eingeführte Ausführungssteuerung (Application Control) war, die die App stoppte, ohne auch nur eine Fehlermeldung anzuzeigen.

Windows verfügt über mehrere Mechanismen, mit denen sich festlegen lässt, dass nur bestimmte Apps ausgeführt werden dürfen: AppLocker, App Control for Business (lange als WDAC, Windows Defender Application Control, bekannt) und das für Privatnutzer gedachte Smart App Control. Im Sicherheitskontext wird meist aus Sicht der „einführenden Seite“ erklärt. Dieser Artikel wechselt die Perspektive und ordnet das Thema aus Sicht der Seite, die die App entwickelt und verteilt: die typischen Muster, nach denen die eigene Business-App in einer Kundenumgebung blockiert wird, an welchem Protokoll sich eine Blockierung eindeutig feststellen lässt, und welche Maßnahmen Entwicklung und Vertrieb im Voraus treffen können. Ergänzend fasst er die wichtigsten Punkte für die IT-Abteilung zusammen, die eine Einführung auf den eigenen PCs erwägt.

1. Zuerst das Ergebnis

• Bei der Ausführungssteuerung sind vier Mechanismen zu unterscheiden: das warnende SmartScreen, das den Nutzer wählen lässt, das nutzer-/gruppenbezogene AppLocker, das maschinenweite App Control for Business und das für Privatnutzer automatisch wirkende Smart App Control (Entscheidungstabelle in Abschnitt 2).
• Die alte Annahme „AppLocker ist nur für Enterprise“ ist überholt. Seit KB 5024351 ist ab Windows 10 Version 2004 und in allen Editionen von Windows 11 für die Durchsetzung keine bestimmte Edition mehr erforderlich.¹
• App Control for Business funktioniert auf allen Client-Editionen von Windows 10/11 sowie auf Windows Server 2016 und neuer. Microsoft empfiehlt, wo immer möglich App Control statt AppLocker einzusetzen.²
• Im Zentrum der Maßnahmen der verteilenden Seite steht die Codesignierung. Signieren Sie nicht nur die exe, sondern alle Binärdateien einschließlich der DLLs sowie den Installer, mit konsistenten Herausgeberinformationen (Abschnitt 5). Mit der Verbreitung von Smart App Control kommt es vor, dass unsignierte Apps selbst auf privaten PCs nicht mehr laufen.³
• Der Nachweis einer Blockierung lässt sich über das Ereignisprotokoll führen. Bei AppLocker ist das Ereignis 8004 im Protokoll „AppLocker – EXE and DLL“ der zentrale Beleg, bei App Control das Ereignis 3077 in „CodeIntegrity – Operational“ (Entscheidungstabelle in Abschnitt 4).⁴⁵
• Ein PowerShell-Skript wird mitunter nicht „blockiert“, sondern „im eingeschränkten Modus ausgeführt“. In einer App-Control-Umgebung läuft ein richtlinienwidriges Skript im Constrained Language Mode, was zu dem schwer zu durchschauenden Fehlerbild führt: „Es läuft, aber nur ein Teil der Vorgänge schlägt fehl.“⁵
• Die einführende Seite sollte mit dem Überwachungsmodus beginnen. Sowohl AppLocker als auch App Control besitzen einen Modus, der aufzeichnet, „was blockiert worden wäre“, ohne tatsächlich zu blockieren; dafür stehen die Ereignisse 8003 und 3076.⁴⁵

2. Die vier Mechanismen unterscheiden

Zunächst die Gesamtübersicht. Die Namen ähneln sich und werden leicht verwechselt, daher trennen wir nach „wer verwaltet es“, „auf welcher Einheit wirkt es“ und „wie greift es“.

2.1. SmartScreen — der einzige Mechanismus, der mit einer „Warnung“ stoppt

SmartScreen ist ein Mechanismus, der „Dinge mit schlechtem Ruf“ meldet, wobei der Nutzer die Warnung standardmäßig übergehen kann. In verwalteten Umgebungen kann jedoch eine Richtlinie aktiv sein, die das Übergehen der Warnung untersagt; dann wirkt auch SmartScreen faktisch als Blockade (dieses Thema wird in „Windows SmartScreen und Codesignierung“ behandelt).

Aus Sicht der verteilenden Seite zeichnet sich SmartScreen dadurch aus, dass es standardmäßig wirkt, auch wenn kein Administrator irgendeine Regel geschrieben hat, und dass der Grund für eine Blockierung nicht eine Richtlinie, sondern der „Ruf“ ist. Der Umgang damit unterscheidet sich daher von den anderen drei: Statt den Kunden eine Erlaubnisregel schreiben zu lassen, löst man das über Signierung und den Aufbau von Reputation. Was in 2.2 bis 2.4 folgt, sind Mechanismen, die nicht warnen, sondern blockieren.

2.2. AppLocker — der Veteran mit nutzerbezogener Steuerung

AppLocker ist eine mit Windows 7 eingeführte Ausführungssteuerung, die Regeln anhand von Attributen des Codesignaturzertifikats (des Herausgebers), von aus den Signaturmetadaten abgeleiteten Dateiattributen (ursprünglicher Dateiname, Version) oder Hashes sowie anhand des Dateipfads definiert. Richtlinien lassen sich auf den ganzen Computer, aber auch auf bestimmte Nutzer oder Gruppen anwenden.²

Bei der Editionsvoraussetzung gibt es viele Missverständnisse. Die aktuelle Dokumentation ist eindeutig: Seit KB 5024351 ist ab Windows 10 Version 2004 und in allen Editionen von Windows 11 für die Durchsetzung einer AppLocker-Richtlinie keine bestimmte Edition mehr erforderlich. Bei älteren Versionen (Windows 10 vor 2004, einschließlich Windows Server 2019) gilt weiterhin die frühere Einschränkung: Über Gruppenrichtlinien verteilte Richtlinien werden nur in den Editionen Enterprise und Server durchgesetzt, per MDM verteilte Richtlinien dagegen in jeder Edition.¹

Gliedert man „was auf Pro geht“ in ob sich Regeln erstellen lassen und ob die erstellten Regeln tatsächlich greifen (durchgesetzt werden), ergibt sich folgendes Bild. Dass diese beiden Dinge verschieden sind, hält die alte Annahme am Leben.¹

Häufig wird angenommen, „auf Pro lassen sich nicht einmal Regeln erstellen“, aber das Erstellen funktioniert in jeder Edition. Unterschiedlich war früher die Durchsetzung, und selbst dabei griff eine per MDM verteilte Richtlinie schon damals auf Pro. Die Arten der anwendbaren Regeln (ausführbare Dateien, Windows Installer, Skripte, DLLs, paketierte Apps) unterscheiden sich nicht nach Edition.¹ Unabhängig von der Edition gilt außerdem: Läuft der Application Identity-Dienst (AppIDSvc) nicht, werden die Regeln nicht ausgewertet (Abschnitt 6).

AppLocker hat allerdings einen wichtigen Vorbehalt. Microsoft selbst stellt klar fest, dass AppLocker die Servicing-Kriterien (die servicing criteria des MSRC) für eine Sicherheitsfunktion nicht erfüllt. Wird also eine Umgehungstechnik gefunden, gilt sie nicht als Sicherheitslücke im eigentlichen Sinne.²

2.3. App Control for Business — der eigentliche Kandidat als Sicherheitsfunktion

App Control for Business ist die heutige Bezeichnung für den Mechanismus, der in Windows 10 zunächst als „Device Guard“ bzw. „Configurable Code Integrity (WDAC)“ eingeführt wurde. Die Richtlinie gilt für den ganzen Rechner und wirkt sich auf alle Nutzer des Geräts aus. Grundlage für Regeln können Attribute des Signaturzertifikats, Dateiattribute oder Hashes, eine Bewertung durch Microsofts Intelligent Security Graph (ISG), der Prozess, der die Installation gestartet hat (ein Managed Installer), der Dateipfad (ab Windows 10 1903) sowie der startende Prozess sein.²

Dieser Mechanismus ist als Sicherheitsfunktion konzipiert, definiert nach den Servicing-Kriterien des MSRC. Auch die Nutzungsvoraussetzungen sind weit gefasst: Richtlinien lassen sich in jeder Client-Edition von Windows 10/11 oder auf Windows Server 2016 und neuer erstellen und anwenden. Für die Verteilung stehen MDM-Lösungen wie Intune, Configuration Manager und PowerShell zur Verfügung. Eine Verteilung über Gruppenrichtlinien ist ebenfalls möglich, jedoch nur im Single-Policy-Format, das auf Windows Server 2016/2019 läuft.²

Zur Frage, welches der beiden Tools zu verwenden ist, gibt Microsoft eine klare Empfehlung: Wo sich etwas mit App Control umsetzen lässt, sollte App Control genutzt werden. App Control wird kontinuierlich weiterentwickelt, während AppLocker zwar Sicherheitskorrekturen, aber keine neuen Funktionen mehr erhält. AppLocker eignet sich dort, wo ältere Windows-Versionen gemischt vorkommen und dieselbe Richtlinie verteilt werden soll, bei gemeinsam genutzten PCs, die je nach Nutzer/Gruppe unterschiedliche Regeln benötigen, sowie als Ergänzung zu App Control, um nutzerbezogene Einschränkungen hinzuzufügen.²

2.4. Smart App Control — Ausführungssteuerung, die auf privaten PCs „einfach schon da ist“

Smart App Control ist eine Schutzfunktion für private Nutzer von Windows 11. Beim Versuch, eine App auszuführen, prüft ein Cloud-Sicherheitsdienst, ob er eine zuverlässige Prognose zur Sicherheit dieser App abgeben kann, und blockiert Apps, die als bösartig eingestuft werden, sowie Apps ohne gültige Signatur, deren Vertrauenswürdigkeit sich nicht bestätigen lässt. Auf einem neuen PC startet die Funktion im Bewertungsmodus, und Windows entscheidet automatisch, ob sie für diesen Nutzer geeignet ist, und schaltet sie entsprechend ein oder aus (bei Nutzern, die voraussichtlich häufig blockiert würden, etwa Entwicklern, wird sie automatisch deaktiviert).³

Für die verteilende Seite ist die Bedeutung einfach: Ausführungssteuerung ist inzwischen standardmäßig auch auf PCs vorhanden, die nicht unter Unternehmensverwaltung stehen, also auf den PCs von Kleinunternehmen und Einzelunternehmern. Auch wenn kein Administrator irgendeine Richtlinie geschrieben hat, kann eine unsignierte App blockiert werden. Auch Microsofts Hinweise für Entwickler nennen das Signieren der App mit einem gültigen Zertifikat als Mittel, eine Blockierung zu vermeiden.³

3. Typische Muster, bei denen Ihre App blockiert wird

Hier folgen die in Auftragsentwicklung und Paketverteilung tatsächlich anzutreffenden Muster, sortiert nach Ursache.

Das gemeinsame Muster ist, dass die verteilende Seite die Grundlage (Signatur, Pfad, Hash), auf der die Erlaubnis beruht, nicht zuverlässig bereitstellt. Selbst wenn die IT-Abteilung des Kunden eine Herausgeberregel schreiben möchte, bleibt ihr, wenn nur ein Teil der Binärdateien signiert ist, nur eine Hash-Regel – und diese bricht bei jeder neuen Version, die Sie ausliefern. Die Verantwortung für die Blockierung scheint bei der einführenden Seite zu liegen, tatsächlich ist es aber häufig die verteilende Seite, die die Regeln instabil macht.

4. Was passiert ist, im Protokoll bestätigen

Ob „es startet nicht“ auf die Ausführungssteuerung zurückzuführen ist, lässt sich nicht durch Mutmaßung, sondern anhand des Ereignisprotokolls klären. Zu prüfen sind zwei Stellen.

4.1. AppLocker-Ereignisse

Sehen Sie unter Anwendungs- und Dienstprotokolle\Microsoft\Windows\AppLocker in der Ereignisanzeige nach.⁴ Für alle, die dies zum ersten Mal öffnen, hier der Weg dorthin.

Ereignisanzeige (im Startmenü „Ereignisanzeige“ eingeben oder über „Ausführen“ eventvwr.msc) > Anwendungs- und Dienstprotokolle > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

In einer englischsprachigen Umgebung lautet der Pfad Applications and Services Logs > Microsoft > Windows > AppLocker. Wer die grafische Oberfläche überspringen möchte: PowerShell als Administrator öffnen und das Protokoll mit der folgenden Zeile auslesen (auch beim Kunden ist es am schnellsten, ihm diese Zeile zu übergeben).

# AppLocker-Blockierungen (8004) und Überwachungsereignisse (8003) der letzten 24 Stunden auslesen
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-AppLocker/EXE and DLL'
    Id        = 8003, 8004
    StartTime = (Get-Date).AddDays(-1)
} | Format-List TimeCreated, Id, Message

Das Ereignis erfasst den Pfad der betroffenen Datei, ob erlaubt oder blockiert wurde, die Art der angewendeten Regel (Pfad, Hash, Herausgeber) samt Regelname sowie die SID von Nutzer/Gruppe der Regel.⁴ Beim Lesen ist allerdings Vorsicht geboten. Im Betrieb mit Erlaubnislisten ist die überwiegende Mehrheit der Blockierungen keine „hat auf eine Verweigerungsregel gepasst“, sondern eine implizite Verweigerung, weil keine Erlaubnisregel gepasst hat. In diesem Fall bestätigt das Ereignis 8004 lediglich „die Tatsache der Blockierung und die betroffene Datei“; der Regelname liefert keinen Hinweis. Trifft man auf eine explizite Verweigerungsregel, ist deren Name direkt die Ursache; bei einer impliziten Verweigerung muss man dagegen durch Abgleich mit der geltenden Richtlinie herausfinden, „welche Erlaubnisregel fehlt“.

4.2. Ereignisse von App Control for Business (WDAC)

Blockierungen durch App Control erscheinen an anderer Stelle, unter Anwendungs- und Dienstprotokolle\Microsoft\Windows\CodeIntegrity\Operational. Die Kontrolle von exe, DLL und Treibern erscheint hier, während die Kontrolle von MSI, Skripten und COM im bereits genannten Protokoll „AppLocker – MSI and Script“ erscheint – so ist die Aufgabenteilung.⁵

Ereignisanzeige > Anwendungs- und Dienstprotokolle > Microsoft > Windows > CodeIntegrity > Operational (in einer englischsprachigen Umgebung: Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# App-Control-Blockierungen (3077), Überwachungsereignisse (3076) und die zugehörigen
# Signaturinformationen (3089) gemeinsam anzeigen
Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-CodeIntegrity/Operational'
    Id        = 3076, 3077, 3089
    StartTime = (Get-Date).AddDays(-1)
} | Sort-Object TimeCreated | Format-List TimeCreated, Id, Message

Wenn unklar ist, welcher der beiden Mechanismen die Blockierung ausgelöst hat, ist es am sichersten, diese beiden Protokolle für denselben Zeitraum nebeneinanderzulegen und abzugleichen.

Ereignis 3089 wird leicht übersehen, ist aber wichtig. Es entsteht einmal pro Signatur der Datei; bei einer unsignierten Datei entsteht ein einzelnes Ereignis mit der Signaturanzahl null. Mängel auf der Verteilerseite wie „eigentlich signiert, wird aber als unsigniert behandelt“ oder „eine Signatur eines alten Zertifikats hängt noch dran“ lassen sich hier eindeutig feststellen.⁵

Beim Skriptverhalten ist besondere Vorsicht geboten. Ereignis 8029 zeigt an, dass „ein Skript blockiert wurde“, doch die tatsächliche Durchsetzung liegt beim Verhalten des Skript-Hosts: PowerShell etwa stoppt ein richtlinienwidriges Skript nicht vollständig, sondern führt es im Constrained Language Mode aus.⁵ Da die Erzeugung von .NET-Objekten dabei umfassend eingeschränkt ist, entsteht das unangenehme Fehlerbild, dass „das Skript selbst läuft, aber eine einzelne Zeile mittendrin fehlschlägt“. Wenn Ihre App ein Skript mitliefert, verzögert Unkenntnis dieses Fehlerbilds die Fehlersuche erheblich (die praktische Seite der Skriptsignierung wird in „PowerShell-Ausführungsrichtlinie und Skriptsignierung“ behandelt).

Beachten Sie außerdem, dass das Protokoll „AppLocker – MSI and Script“ auf der Windows Server Core-Edition nicht existiert.⁵ Bei der Untersuchung serverseitig eingesetzter Apps sollten Sie das im Hinterkopf behalten.

5. Was die verteilende Seite tun kann — die App „leicht regelbar“ machen

Statt erst nach einer Blockierung zu reagieren, besteht der eigentliche Weg darin, die App so auszuliefern, dass die IT-Abteilung des Kunden eine stabile Erlaubnisregel schreiben kann. Dazu ist nicht viel nötig.

1. Signieren Sie alle Binärdateien mit Authenticode. Nicht nur die exe, sondern auch selbst gebaute DLLs, den Installer (MSI/Setup-exe) und beiliegende Skripte. Herausgeberregeln stützen sich auf Signaturmetadaten (Herausgeber, Produktname, Dateiname, Version); ist alles signiert, kann eine update-feste Regel geschrieben werden: „dieses Produkt dieses Herausgebers erlauben, unabhängig von der Version“.² Wählen Sie ein Zertifikat, das RSA-basiert ist und von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt wurde. Ein selbstsigniertes Zertifikat oder ein Zertifikat einer internen CA funktioniert auf einem Kunden-PC nicht, der dieser CA nicht vertraut, und wird auch von Smart App Control nicht unterstützt. Auch unterstützt die Signaturprüfung von Smart App Control keine ECC-Signaturen (elliptische Kurven); wird mit einem ECC-Zertifikat signiert, kann die App auf einem privaten PC praktisch als unsigniert gelten.⁶ Dieselbe Einschränkung gilt bei App Control: Signaturgeber-basierte Regeln unterstützen nur RSA (bis 4096 Bit), eine mit ECDSA signierte Datei lässt sich über eine Herausgeberregel nicht erlauben (im zugehörigen Signaturinformations-Ereignis 3089 erscheint VerificationError = 23).⁷ Die Annahme „ECC ist neuer und stärker“ wirkt sich unter dem Blickwinkel der Ausführungssteuerung also gegenteilig aus.
2. Versehen Sie die Signatur unbedingt mit einem Zeitstempel. So bleibt die Signatur auch nach Ablauf des Zertifikats gültig. Das praktische Vorgehen beim Signieren und der Zusammenhang mit SmartScreen sind in einem separaten Artikel zusammengefasst.
3. Halten Sie Herausgeberinformationen und die Versionsressource jeder Datei stabil. Ändert sich beim Erneuern eines Zertifikats das Subject (der Organisationsname), bricht die Herausgeberregel. Wenn sich die Schreibweise des Firmennamens oder die Bezugsquelle des Zertifikats ändert, weisen Sie in den Release Notes vorab darauf hin. Ein weiterer, oft übersehener Punkt: „Produktname“, „ursprünglicher Dateiname“ und „Version“ einer Herausgeberregel werden nicht aus dem Zertifikat, sondern aus der Versionsressource (den Assembly-Informationen) jeder Datei entnommen. Bleiben diese Felder leer, oder ändern sich Produktname oder Dateiname von Release zu Release, bricht eine auf Produkt oder Datei eingeschränkte Regel, selbst wenn der Signaturgeber gleich bleibt.
4. Halten Sie den Ablageort der ausführbaren Datei konventionell. Installieren Sie unter Program Files und verzichten Sie auf Konstruktionen, die exe/DLL zur Laufzeit nach %TEMP% oder %APPDATA% entpacken und von dort starten. Eine Ausführung aus einem beschreibbaren Verzeichnis verträgt sich grundsätzlich schlecht mit einer pfadregelbasierten Umgebung.
5. Überarbeiten Sie das Design des automatischen Updates. Signieren Sie auch das Update-Programm selbst, damit ein Update ein geschlossener Ablauf ist, bei dem „eine signierte Binärdatei eine signierte Binärdatei ersetzt“. Wird über Intune oder Configuration Manager verteilt und hat der Kunde diesen Verteilungsagenten als Managed Installer konfiguriert, lässt sich ein Betrieb einrichten, der über den Installer eingebrachte Binärdateien erlaubt. Das greift nicht automatisch, sondern setzt eine ausdrückliche Konfiguration durch den Administrator voraus – aber indem Sie eine für die stille Installation geeignete MSI bereithalten, geben Sie dem Kunden diese Option (das sichere Design des automatischen Updates behandelt „Sicherheit beim automatischen Update“).
6. Halten Sie Informationen für den Blockierungsfall bereit. Wenn Signatur-Subject, die Liste der zur Laufzeit benötigten Binärdateien und der Installationspfad im Bereitstellungshandbuch dokumentiert sind, kann die IT-Abteilung des Kunden daraus allein eine Regel schreiben. Kommt es zu Problemen, genügt eine einzige Rückfrage, wenn Sie um Prüfung der in Abschnitt 4 genannten Ereignis-IDs bitten.

Diese sechs Punkte wirken direkt auch als Vorbereitung auf Smart App Control. Eine Binärdatei, die signiert ist und Reputation aufgebaut hat, wird auf einem privaten PC seltener von der automatischen Blockierung erfasst.³

5.1. Erstmalig ein Codesignaturzertifikat beschaffen

Wenn es bei „dann signieren wir eben“ stecken bleibt, kommt es nicht voran. Deshalb hier der nächste konkrete Schritt für alle, die noch kein Zertifikat besitzen.

Zertifikatswahl. Nutzbar ist ein Codesignaturzertifikat einer öffentlichen Zertifizierungsstelle (kommerzielle CA). Ein selbstsigniertes Zertifikat oder ein Zertifikat einer internen CA lässt sich auf einem Kunden-PC, der dieser CA nicht vertraut, nicht validieren und ist daher für die Verteilung unbrauchbar. Zertifikate öffentlicher CAs gibt es als OV (Prüfung der Unternehmensexistenz) und als strenger geprüfte EV; aus Sicht der Herausgeberregeln von AppLocker und App Control lässt sich mit beiden gleichermaßen eine Regel schreiben. App Control kennt zwar eine Regeloption, die eine EV-Signatur verlangt (Required:EV Signers), doch die Dokumentation stellt ausdrücklich klar, dass diese derzeit nicht unterstützt wird – es gibt also derzeit keinen Grund, sich um der Ausführungssteuerung willen für EV zu entscheiden.⁷

Zur Kostenfrage. Der Betrag hängt von CA und Laufzeit ab, sodass ein Angebot einzuholen ist, aber es hilft zu wissen, wie sich die Kosten zusammensetzen. Seit dem 1. Juni 2023 ist nach den Vorgaben des CA/Browser Forums unabhängig von OV oder EV die Erzeugung und Aufbewahrung des privaten Schlüssels auf Hardware mit mindestens FIPS-140-2-Level-2-Äquivalent (HSM oder USB-Token) vorgeschrieben.⁸ Die Kosten umfassen also nicht nur „das Zertifikat selbst“, sondern auch „die Gebühr für Token bzw. HSM oder für einen von der CA angebotenen Cloud-Signaturdienst“. Wer in CI/CD automatisch signieren möchte, kommt mit einem Cloud-Signaturdienst in der Regel leichter zurecht als mit einem physischen Token – klären Sie deshalb beim Angebot gleich, wie Sie das Signieren operativ betreiben wollen.

Der minimale Signierbefehl. Verwendet wird signtool aus dem Windows SDK.

:: Signieren (SHA-256-Hash, RFC-3161-Zeitstempel hinzufügen)
signtool sign /fd sha256 /tr <URL des Zeitstempelservers> /td sha256 /a MyApp.exe

:: Signatur prüfen (Validierung nach Authenticode-Richtlinie, Details anzeigen)
signtool verify /pa /v MyApp.exe

/fd gibt den Hash-Algorithmus der Datei an, /tr die URL des RFC-3161-Zeitstempelservers, /td den Hash-Algorithmus des Zeitstempels und /a die Anweisung, das passende Zertifikat automatisch aus dem Zertifikatspeicher auszuwählen. Verwenden Sie die vom Zertifikatsanbieter angegebene URL des Zeitstempelservers. Wird mit einem Schlüssel auf Token oder HSM signiert, steht die CSP-/KSP-Angabe im Handbuch der CA. Mit demselben Befehl lassen sich auch DLLs und Installer signieren, sodass es sich empfiehlt, ihn am Ende des Builds über alle Dateien laufen zu lassen.

Was beim Erneuern des Zertifikats bricht. Herausgeberregeln stützen sich auf die Herausgeberinformationen der Signatur (Zertifikatskette und Subject). Folgende Änderungen führen daher dazu, dass die Regel beim Kunden stillschweigend nicht mehr passt.

• Die Schreibweise des Firmennamens wurde geändert (z. B. das Subject des Zertifikats von Komura Soft LLC auf 合同会社小村ソフト, die offizielle japanische Firmenbezeichnung, geändert). Auch bei gleicher Firma ist eine andere Zeichenkette ein anderer Herausgeber.
• Die CA wurde gewechselt. Eine Publisher-Regel von App Control ist eine Kombination aus „Zwischenzertifizierungsstelle (PCA) + CN des Leaf-Zertifikats“; wechselt die CA, ändert sich die PCA, und die Regel passt nicht mehr.⁷
• Der Name der ausführbaren Datei oder der Produktname wurde geändert. Eine FilePublisher-Regel enthält zusätzlich dazu den ursprünglichen Dateinamen (OriginalFileName) und eine Mindestversion.⁷

In jedem Fall zeigt sich dasselbe Symptom: In dem Moment, in dem Sie das aktualisierte Release ausrollen, startet die App – nur in dieser Umgebung – nicht mehr. Und aus Sicht des Kunden heißt es dann schlicht „nach dem Update kaputt“, sodass niemand die Signatur als Ursache vermutet. Legen Sie beim Erneuern oder Ändern eines Zertifikats die alten und neuen Signaturinformationen (Subject, ausstellende CA) nebeneinander in den Release Notes vor, damit die IT-Abteilung des Kunden die Regel ergänzen kann.

6. Wichtige Punkte für die einführende Seite (IT-Abteilung)

Für die Seite, die Ausführungssteuerung auf den eigenen PCs einführt, beschränkt sich dieser Artikel auf das Wesentliche.

1. Wählen Sie die Technologie. Im Grundsatz App Control for Business. Für gemeinsam genutzte PCs, die nutzerbezogene Steuerung benötigen, oder in Umgebungen mit gemischten älteren Betriebssystemen ergänzen Sie AppLocker.² Bei fest zweckgebundenen PCs wie Kiosk-Terminals wird die Regelmenge einfacher, wenn Sie zunächst über Shell-Einschränkungen (siehe „Kioskmodus und zugewiesener Zugriff“) eingrenzen und erst danach weiterplanen.
2. Beginnen Sie unbedingt mit dem Überwachungsmodus. Bei AppLocker mit „Nur überwachen“ zeichnen die Ereignisse 8003 und 8006 auf, was bei Durchsetzung blockiert worden wäre; im Überwachungsmodus von App Control leisten das die Ereignisse 3076 und 8028.⁴⁵ Das Vorgehen – sammeln, bis ein voller Geschäftszyklus durchlaufen ist, und erst dann auf Durchsetzung umschalten – ist genau dasselbe wie bei SMB-Signierung oder NTLM-Einschränkung. Beim Einsatz von AppLocker gibt es eine Voraussetzung: Die AppLocker-Richtlinie wird nicht ausgewertet, wenn der Application Identity-Dienst (AppIDSvc) nicht läuft, und selbst im Überwachungsmodus erscheinen dann keine Ereignisse. Konfigurieren Sie diesen Dienst auf den betroffenen Geräten für den automatischen Start, bevor Sie mit der Überwachung beginnen.
3. Führen Sie ein Ausnahmeverzeichnis. Alte, unsigniert weiterlaufende Fachanwendungen benötigen eine Ausnahme über eine Hash-Regel. Diese Liste ist im Grunde eine Liste der „irgendwann zu erneuernden Dinge“ und sollte mit der Bestandsverwaltung verknüpft und jährlich überprüft werden.

Punkt 2, „mit dem Überwachungsmodus beginnen“, hier noch der minimale Ablauf, damit Sie nicht auf einen anderen Artikel verwiesen werden müssen.

Bei AppLocker (3 Schritte)

1. Überwachungsmodus aktivieren. Öffnen Sie im Editor für lokale Gruppenrichtlinien (lokal: secpol.msc) Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Anwendungssteuerungsrichtlinien > AppLocker, klicken Sie AppLocker mit der rechten Maustaste an und wählen Sie Eigenschaften. Setzen Sie für jede Regelsammlung (ausführbare Dateien, Windows Installer, Skripte, paketierte Apps) den Haken bei „Konfigurieren“ und wählen Sie „Nur überwachen“. Erstellen Sie außerdem für jede Sammlung die Standardregeln und konfigurieren Sie auf den betroffenen Geräten den Application Identity-Dienst (AppIDSvc) für den automatischen Start (läuft dieser nicht, wird die Richtlinie nicht ausgewertet, und es erscheinen keine Ereignisse).

2. Ereignisse sammeln. Erfassen Sie, bis ein voller Geschäftszyklus durchlaufen ist, das Ereignis 8003 (exe/DLL) aus Microsoft-Windows-AppLocker/EXE and DLL und das Ereignis 8006 (Skripte/MSI) aus MSI and Script.⁴ Hier ist Vorsicht geboten. Das PowerShell aus Abschnitt 4 ist fest auf den Protokollnamen „EXE and DLL“ eingestellt und erfasst so nicht die 8006 für Skripte und MSI. Da die Protokolle getrennt sind, müssen Sie es wie folgt für beide ausführen.

    # Im Überwachungsmodus "was bei Durchsetzung blockiert worden wäre" aus beiden Protokollen sammeln
    $since = (Get-Date).AddDays(-7)
    $collections = @(
        @{ LogName = 'Microsoft-Windows-AppLocker/EXE and DLL';    Id = 8003 }
        @{ LogName = 'Microsoft-Windows-AppLocker/MSI and Script'; Id = 8006 }
    )
    foreach ($c in $collections) {
        Get-WinEvent -FilterHashtable ($c + @{ StartTime = $since }) -ErrorAction SilentlyContinue |
            Select-Object TimeCreated, LogName, Id, Message
    }
   

   -ErrorAction SilentlyContinue ist gesetzt, weil Get-WinEvent bei einem Protokoll ohne passende Ereignisse einen Fehler zurückgibt. Werden auch paketierte Apps kontrolliert, ergänzen Sie Packaged app-Deployment / Packaged app-Execution in derselben Form. Prüfen Sie, ob auch monatliche und jährliche Batch-Läufe erfasst wurden.

3. Auf Durchsetzung umschalten. Übernehmen Sie, was unter 8003 und 8006 erschienen ist, in Erlaubnisregeln und stellen Sie dann im selben Eigenschaftenfenster auf „Regeln durchsetzen“ um. Überwachen Sie nach dem Umschalten 8004 (Blockierung von exe/DLL) und 8007 (Blockierung von Skript/MSI).

Bei App Control for Business ist der Ablauf derselbe: Verteilen Sie die Richtlinien-XML mit gesetzter Regeloption 3 (Enabled:Audit Mode) (Konfiguration über den App Control Policy Wizard oder das Cmdlet Set-RuleOption), sammeln Sie 3076 und 8028, entfernen Sie dann diese Option und schalten Sie auf Durchsetzung um. Auch Microsoft empfiehlt, die Auswirkungen zunächst mit Enabled:Audit Mode zu prüfen.⁷

7. Zusammenfassung

• Unterscheiden Sie bei der Ausführungssteuerung zwischen dem „warnenden“ SmartScreen und den „blockierenden“ AppLocker / App Control for Business / Smart App Control (wobei auch SmartScreen unter einer Verwaltungsrichtlinie, die das Übergehen der Warnung untersagt, faktisch als Blockade wirkt).
• Die Editionsbeschränkung von AppLocker ist bereits gelockert (Windows 10 ab 2004, alle Editionen von Windows 11), und App Control funktionierte von Beginn an auf allen Client-Editionen. „Unsere Kunden nutzen Pro, also betrifft uns das nicht“ gilt nicht mehr.¹²
• Mit Smart App Control ist Ausführungssteuerung nun auch auf privaten, von niemandem verwalteten PCs vorhanden. Ein unsigniertes Verteilungsobjekt kann allein deshalb schon nicht laufen.³
• Bestätigen Sie eine Blockierung über das Ereignisprotokoll. Bei AppLocker ist 8004 (Protokoll EXE and DLL) zentral, bei App Control 3077 zusammen mit dem Signaturinformations-Ereignis 3089 (Protokoll CodeIntegrity – Operational).⁴⁵
• Was die verteilende Seite tun kann: konsistente Signierung aller Binärdateien, Zeitstempel, ein konventioneller Installationsort, signiertes automatisches Update sowie Informationsbereitstellung im Bereitstellungshandbuch. Die App für den Kunden leicht regelbar zu machen ist das ganze Geheimnis der Blockierungsvermeidung.
• Die einführende Seite sollte im Überwachungsmodus (8003 / 3076) einen vollen Zyklus sammeln, bevor sie auf Durchsetzung umschaltet. Dieses Vorgehen entspricht anderen Maßnahmen zur Sicherheitshärtung.

Verwandte Artikel

• Warum Windows „Windows hat Ihren PC geschützt“ anzeigt
• Sicheres Design für automatische Updates - Warum HTTPS allein nicht genügt
• Die Wahl der Windows-App-Verteilungsmethode - MSI/MSIX/ClickOnce/xcopy/eigener Updater
• PowerShell-Ausführungsrichtlinie und Skriptsignierung — praktischer Leitfaden, um vom Zudecken mit „Bypass“ wegzukommen
• Umgang mit Fehlalarmen (False Positives) von Windows Defender
• Kioskmodus und zugewiesener Zugriff unter Windows
• Die realistische Lösung nach dem Support-Ende von Windows 10 — Entscheidungstabelle für ESU, LTSC und Neuanschaffung

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt die Entwicklung und Anpassung von Fachanwendungen, die in Umgebungen mit Ausführungssteuerung (AppLocker / App Control for Business) laufen, das Design von Verteilung und automatischem Update mit integrierter Codesignierung sowie die Untersuchung von Fällen, in denen eine App in einer Kundenumgebung nicht startet.

• Windows-Anwendungsentwicklung
• Anpassung und Wartung bestehender Windows-Software
• Fehleruntersuchung und Ursachenanalyse
• Kontakt

Referenzlinks

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Lässt sich AppLocker in der Pro-Edition nicht verwenden?

Diese Annahme ist überholt. Seit KB 5024351 ist ab Windows 10 Version 2004 und in allen Editionen von Windows 11 für die Durchsetzung einer AppLocker-Richtlinie keine bestimmte Edition mehr erforderlich. Die frühere Einschränkung – „die Durchsetzung bei Verteilung über Gruppenrichtlinien ist auf die Editionen Enterprise und Server beschränkt“ – gilt nur noch für Windows 10 vor Version 2004 und bis Windows Server 2019 (und selbst dort funktioniert die Verteilung über MDM in jeder Edition). Auch in einer Umgebung, die überwiegend aus Pro-Rechnern kleiner und mittlerer Unternehmen besteht, ist AppLocker heute eine gangbare Option.

Sollten wir ein EV-Codesignaturzertifikat kaufen?

Aus Sicht der Herausgeberregeln von AppLocker und App Control for Business lässt sich mit einem OV-Zertifikat (Organisationsvalidierung) ebenso eine auf den Signaturgeber gestützte Regel schreiben wie mit einem EV-Zertifikat. Beachten Sie außerdem, dass die Vorstellung „bei EV verschwindet die SmartScreen-Warnung schon beim ersten Ausführen“ veraltet ist; eine mit EV signierte Datei muss inzwischen ebenso wie eine OV-signierte auf Basis eines sich aufbauenden Rufs betrachtet werden (dieser Punkt wird im separaten Artikel „Windows SmartScreen und Codesignierung“ behandelt). Wichtiger als der Zertifikatstyp ist, alle Binärdateien – nicht nur die exe, sondern auch DLLs und den Installer – mit einem konsistenten Subject zu signieren, einen Zeitstempel hinzuzufügen und die Herausgeberinformationen über Zertifikatserneuerungen hinweg stabil zu halten. Herausgeberregeln stützen sich auf genau diese Signaturinformationen; verschiebt sich der Signaturzustand von Release zu Release, bricht die Regel beim Kunden.

Unsere eigene App scheint in einer Kundenumgebung blockiert worden zu sein, aber im Protokoll finde ich nichts. Wo sollte ich nachsehen?

Meist liegt es daran, dass sich das zu prüfende Protokoll auf zwei getrennte Systeme verteilt. Eine AppLocker-Blockierung von exe/DLL erscheint als Ereignis 8004 (bzw. 8003 im Überwachungsmodus) im Protokoll „AppLocker – EXE and DLL“; Skripte und MSIs erscheinen als 8007 (bzw. 8006) im Protokoll „AppLocker – MSI and Script“. Eine Blockierung durch App Control for Business (WDAC) hingegen erscheint als Ereignis 3077 (bzw. 3076 im Überwachungsmodus) im Protokoll „CodeIntegrity – Operational“, wobei die zugehörigen Signaturinformationen unter 3089 erfasst werden. Wird ein Skript, eine MSI oder ein COM-Objekt von App Control abgefangen, taucht das ebenfalls im Protokoll „AppLocker – MSI and Script“ auf, als 8029, 8036 oder 8040. Wenn Sie untersuchen, ohne zu wissen, welcher Mechanismus greift, legen Sie CodeIntegrity – Operational und die Protokolle unter AppLocker zeitlich nebeneinander und gleichen Sie sie ab.

Was ist nötig, damit Smart App Control die eigene App nicht blockiert?

In der Praxis: Codesignierung. Beim Ausführen einer App prüft Smart App Control die Sicherheitsprognose des Cloud-Sicherheitsdienstes für diese App sowie, ob die App eine gültige Signatur trägt, und blockiert Apps, die als bösartig eingestuft werden, ebenso wie unsignierte Apps, deren Vertrauenswürdigkeit sich nicht bestätigen lässt. Auch Microsofts Hinweise für Entwickler nennen das Signieren der App mit einem gültigen Zertifikat. Zu beachten ist allerdings der Signaturalgorithmus: Die Signaturprüfung von Smart App Control unterstützt keine Signaturen mit elliptischer Kurvenkryptografie (ECC); nur Apps, die mit einem RSA-basierten Zertifikat signiert sind, kommen für die Ausführungserlaubnis infrage. Smart App Control ist keine Verwaltungsfunktion für Unternehmen, sondern ein Schutz für private Nutzer von Windows 11, der ausgehend vom Bewertungsmodus automatisch ein- oder ausgeschaltet wird. Aus Sicht der verteilenden Seite ist es daher am sichersten, davon auszugehen, dass eine unsignierte ausführbare Datei auf einem privaten PC unter Umständen nicht läuft.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.