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.“ Bei der Verteilung von Business-Apps kann die Ursache nicht nur ein Fehler der App selbst sein, sondern die Ausführungssteuerung in der Kundenumgebung. Manchmal startet die exe, und nur mitgelieferte DLLs oder Skripte werden gestoppt.

Dann gilt es nicht sofort, Signatur oder Installationsort zu ändern, sondern welcher Mechanismus welche Datei auf welcher Grundlage gestoppt hat einzugrenzen.

Dieser Artikel ordnet die Ausführungssteuerung unter Windows aus Sicht der Seite, die die App entwickelt und verteilt. Nach den Unterschieden zwischen AppLocker, App Control for Business (früher WDAC, Windows Defender Application Control), Smart App Control und SmartScreen folgen typische Blockierungen, das Lesen der Ereignisprotokolle und die Vorbereitung vor der Verteilung. Am Ende steht ein Ablauf für die IT-Abteilung, die die Steuerung auf den eigenen PCs einführt.

1. Zuerst das Fazit

• Unterscheiden Sie zuerst die vier Mechanismen und legen Sie das Ziel im Protokoll fest. Die Warnung von SmartScreen, die Steuerung von AppLocker pro Benutzer und Gruppe, die maschinenweite Steuerung von App Control und der Schutz von Smart App Control für private PCs sind nicht dasselbe. Bei exe/DLL unter AppLocker steht 8004 im Zentrum der Untersuchung, bei App Control 3077 und die Signaturinformation 3089. Bei Skripten und MSIs prüfen Sie zusätzlich das andere Protokoll.¹²
• Auf der verteilenden Seite machen Sie die App so, dass die Erlaubnisregeln auch nach einem Update noch passen. Im Zentrum steht eine einheitliche Signatur, die nicht nur die exe, sondern auch DLLs, Installer und mitgelieferte Skripte umfasst. Stimmen Sie außerdem Herausgeberinformationen, Dateiattribute, Ablageort und den Ablauf der automatischen Aktualisierung aufeinander ab. Auch auf einem PC ohne Unternehmensverwaltung kann Smart App Control eine unsignierte App stoppen.³⁴
• Auf der einführenden Seite lassen Sie zuerst einen kompletten Geschäftszyklus im Überwachungsmodus laufen und gehen dann zur Erzwingung. Wählen Sie App Control, wo es möglich ist, und AppLocker, wo etwa eine Steuerung pro Benutzer nötig ist. „Die PCs des Kunden sind Pro, das betrifft uns nicht“ gilt nicht. Ab Windows 10 2004 mit KB 5024351 und unter Windows 11 braucht die Erzwingung von AppLocker keine bestimmte Edition, und App Control unterstützt alle Client-Editionen.³⁵

Lesen nach Ziel

Bei PowerShell wird ein Skript manchmal nicht vollständig blockiert, sondern läuft im Constrained Language Mode, und nur ein Teil der Verarbeitung schlägt fehl. Diesen Unterschied behandelt Kapitel 4 ebenfalls.²

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (36 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Die vier Mechanismen unterscheiden

Produkte mit ähnlichen Namen trennen Sie nach „Ziel“, „Wirkungsweise“ und „wer verwaltet“. Zuerst klären Sie, ob eine Warnung zu behandeln ist oder ein Abgleich mit den Erlaubnisregeln eines Administrators.

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

SmartScreen warnt anhand des Rufs einer Datei. Es wirkt standardmäßig, ohne dass ein Administrator Regeln schreibt, und normalerweise kann der Benutzer die Warnung übergehen und ausführen.

Allerdings: Ist eine Verwaltungsrichtlinie in Kraft, die das Übergehen der Warnung untersagt, wird auch SmartScreen zu einer faktischen Blockierung. „Es ist eine Warnung, also lässt sich immer ausführen“ folgt daraus nicht.

Die Maßnahmen der verteilenden Seite halten Sie getrennt davon, den Kunden Erlaubnisregeln für AppLocker schreiben zu lassen. Bei SmartScreen stehen Signatur und der Aufbau von Ruf im Zentrum. Ausführlich behandelt das „Windows SmartScreen und Codesignatur“. Die folgenden Abschnitte 2.2 bis 2.4 sind Mechanismen, die nicht warnen, sondern die Ausführung blockieren.

2.2. AppLocker — der Veteran mit Steuerung pro Benutzer

Wonach und wessen Ausführung wird gesteuert?

AppLocker wurde mit Windows 7 eingeführt. Grundlage der Regeln sind Attribute des Codesignaturzertifikats (Herausgeber), Dateiattribute aus den Signaturmetadaten (ursprünglicher Dateiname, Version), Hash und Dateipfad. Eine Richtlinie lässt sich nicht nur auf den ganzen Computer, sondern auch auf bestimmte Benutzer und Gruppen anwenden.³

„Regeln erstellen können“ und „erzwingen können“ trennen

Die Editionsvoraussetzungen versteht man leichter, wenn man diese beiden trennt. 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.⁵

Auf älterem Windows bleibt ein Unterschied nach Verteilungsweg. In Umgebungen mit Windows 10 vor 2004 oder Windows Server 2019 gilt weiter: Die Erzwingung einer über Gruppenrichtlinien verteilten Richtlinie ist auf die Editionen Enterprise und Server beschränkt, die Verteilung über MDM funktioniert in jeder Edition.⁵

Auch unter Pro lassen sich Regeln erstellen. Die frühere Einschränkung betraf vor allem ob sie erzwungen werden, und bei MDM-Verteilung ließ sich auch Pro damals schon erzwingen. Die Regelarten — ausführbare Dateien, Windows Installer, Skripte, DLLs, Paket-Apps — unterscheiden sich nach Edition ebenfalls nicht.⁵

Es gibt außerdem eine Voraussetzung unabhängig von der Edition. Läuft der Application Identity-Dienst (AppIDSvc) nicht, werden die Regeln nicht ausgewertet. Zusammen mit der Vorbereitung der Überwachung prüft das Kapitel 6.

Einordnung als Sicherheitsfunktion

Microsoft hält ausdrücklich fest, dass AppLocker die Servicekriterien (servicing criteria) des MSRC für eine Sicherheitsfunktion nicht erfüllt. Wird ein Umgehungsverfahren gefunden, wird allein diese Tatsache nicht als Sicherheitslücke behandelt. Auch darin unterscheidet es sich vom folgenden App Control.³

2.3. App Control for Business — die eigentliche Sicherheitsfunktion

Ein Mechanismus, der für den ganzen Rechner gilt

App Control for Business ist der heutige Name des Mechanismus, der unter Windows 10 als Teil von Device Guard „konfigurierbare Codeintegrität“ hieß. Lange hieß er WDAC. Richtlinien gelten für den ganzen Rechner und betreffen alle Benutzer dieses Geräts. Dieser Mechanismus ist als Sicherheitsfunktion nach den Servicekriterien des MSRC entworfen.³

Die Grundlagen der Regeln lassen sich so ordnen.³

Voraussetzungen und Verteilungswege

Richtlinien lassen sich auf jeder Client-Edition von Windows 10/11 oder auf Windows Server 2016 und später erstellen und anwenden. Zur Verteilung dienen MDM wie Intune, Configuration Manager und PowerShell. Gruppenrichtlinien sind möglich, aber auf das Einzelrichtlinienformat beschränkt, das unter Windows Server 2016/2019 läuft.³

Die Wahl gegenüber AppLocker

Microsoft empfiehlt, App Control zu verwenden, wo sich damit umsetzen lässt, was Sie brauchen. App Control wird weiter verbessert, AppLocker erhält Sicherheitskorrekturen, aber keine neuen Funktionen.³

AppLocker passt, wenn Sie dieselbe Richtlinie in einer gemischten Umgebung mit älterem Windows verteilen wollen oder auf einem gemeinsam genutzten PC Regeln pro Benutzer und Gruppe unterscheiden wollen. Als Ergänzung zu App Control kann man auch Einschränkungen pro Benutzer hinzufügen.³

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

Smart App Control ist eine Schutzfunktion für private Nutzer von Windows 11. Zur Laufzeit prüft sie die Sicherheitsprognose eines Cloud-Sicherheitsdienstes und eine gültige Signatur. Sie 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 beginnt es im Bewertungsmodus; Windows entscheidet, ob es zu diesem Nutzer passt, und schaltet ein oder aus. Bei Nutzern, die häufig blockiert würden, etwa Entwicklern, wird es automatisch ausgeschaltet.⁴

Für die verteilende Seite zählt: Die Ausführungssteuerung wirkt auch auf PCs, für die keine IT-Abteilung eine Richtlinie geschrieben hat. Kleine Betriebe und Selbstständige unter den Kunden sind nicht ausgenommen. Unsignierte Apps können stoppen, und Microsoft selbst weist Entwickler an, mit einem gültigen Zertifikat zu signieren. Die Wahl des Zertifikats ordnet Kapitel 5.⁴

3. Typische Muster, in denen Ihre App blockiert wird

Prüfen Sie nicht nur, ob das Hauptprogramm startet, sondern Installation, Laden von DLLs, Skripte, Plug-ins und automatische Aktualisierung. Muster, die bei Custom Software Development und Paketverteilung häufig Probleme machen, sind die folgenden.

Die gemeinsame Ursache: Die Grundlage der Erlaubnisregeln ist nicht stabil

Was die Tabelle gemeinsam hat, ist: Die verteilende Seite liefert die Grundlage, die die erlaubende Seite braucht (Signatur, Pfad, Hash), nicht stabil.

Signieren Sie nur die exe, lässt sich dieselbe Herausgeberregel für unsignierte DLLs nicht verwenden. Erlauben Sie einzeln per Hashregel, muss die Regel bei jedem Update der Binärdateien nachgezogen werden. Es kann so aussehen, als sei die Steuerung des Kunden die Ursache, während Lieferumfang oder Aktualisierungsweg die Regeln zerbrechlich machen.

Haben die Symptome die Kandidaten eingegrenzt, legen Sie in den folgenden Protokollen die tatsächlich gestoppte Datei fest. Über Maßnahmen nachzudenken kommt danach.

4. Im Protokoll feststellen, was geschehen ist

Im Ereignisprotokoll lesen Sie „die Tatsache, dass etwas gestoppt wurde“ und „was zu korrigieren ist“ getrennt. Der Einstieg sind die Protokolle unter AppLocker und CodeIntegrity; wichtig ist, dass auch App-Control-Ereignisse unter einem Protokoll namens AppLocker aufgezeichnet werden.²

4.1. AppLocker-Ereignisse

Das Protokoll öffnen und die Art des Ziels wählen

Die Ereignisanzeige öffnen Sie über die Suche nach „Ereignisanzeige“ im Startmenü oder über eventvwr.msc im Dialog „Ausführen“.¹

Ereignisanzeige > Protokolle der Anwendungen und Dienste > Microsoft > Windows > AppLocker > EXE and DLL / MSI and Script / Packaged app-Deployment / Packaged app-Execution

In einer englischen Umgebung lautet der Pfad Applications and Services Logs > Microsoft > Windows > AppLocker.

Zum Abruf mit PowerShell öffnen Sie eine Sitzung als Administrator und führen Sie Folgendes aus. Dieses Beispiel holt nur Überwachung und Blockierung von exe/DLL der letzten 24 Stunden. Skripte und MSIs sind nicht enthalten.

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

Hat es eine Verweigerungsregel getroffen, oder fehlt eine Erlaubnisregel?

Das Ereignis hält den Pfad der Zieldatei, das Ergebnis Erlauben oder Blockieren, die Regelart (Pfad, Hash, Herausgeber), den Regelnamen und die SID von Benutzer oder Gruppe fest.¹

Beim Betrieb als Erlaubnisliste sind die meisten Fälle jedoch eine implizite Verweigerung, bei der keine Erlaubnisregel getroffen wurde.

8004 zeigt die Tatsache der Blockierung und das Ziel, bei impliziter Verweigerung lässt sich die Ursache aber nicht allein aus dem Regelnamen bestimmen. Sie müssen das Ereignis mit der geltenden Richtlinie abgleichen, nicht nur das Ereignis ansehen.

4.2. Ereignisse von App Control for Business (WDAC)

exe, DLL und Treiber liegen in einem anderen Protokoll als Skripte

Die Steuerung von exe, DLL und Treibern prüfen Sie im folgenden CodeIntegrity-Protokoll. Die Steuerung von MSI, Skripten und COM wird im bereits genannten Protokoll AppLocker - MSI and Script aufgezeichnet.²

Ereignisanzeige > Protokolle der Anwendungen und Dienste > Microsoft > Windows > CodeIntegrity > Operational (in einer englischen Umgebung Applications and Services Logs > Microsoft > Windows > CodeIntegrity > Operational)

# App-Control-Blockierungen (3077), Überwachung (3076) und zugehörige Signaturinformationen (3089) zusammen ansehen
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

Dieser Befehl holt CodeIntegrity 3076, 3077 und 3089. Bei MSI, Skripten oder COM folgen Sie der Tabelle unten und prüfen Sie AppLocker - MSI and Script zusätzlich. Solange unklar ist, welcher Mechanismus greift, legen Sie die Protokolle unter AppLocker und CodeIntegrity über denselben Zeitraum nebeneinander.

Mit 3089 die tatsächlich bewertete Signatur prüfen

Pro Signatur der Datei entsteht ein 3089-Ereignis. Bei einer unsignierten Datei erscheint ein Ereignis mit Signaturanzahl 0. Die Zuordnung zu 3076, 3077 und anderen erfolgt über die Korrelations-Activity-ID.²

Probleme wie „wir haben signiert, es wird aber als unsigniert behandelt“ oder „eine Signatur eines alten Zertifikats liegt noch darauf“ lassen sich an dieser Signaturinformation prüfen. Gleichen Sie den Zustand der Datei, den Sie auf der verteilenden Seite geprüft haben, mit dem Zustand der Datei ab, der auf Kundenseite bewertet wurde.

Auch bei 8029 hält PowerShell nicht unbedingt vollständig an

8029 zeigt die Blockierung eines Skripts, die tatsächliche Erzwingung liegt aber beim Skript-Host. PowerShell hält ein von der Richtlinie nicht erlaubtes Skript nicht vollständig an, sondern führt es im Constrained Language Mode aus.²

In diesem Modus ist das Erzeugen von .NET-Objekten weitgehend eingeschränkt. Daraus folgt das Bild „das Skript hat begonnen, aber eine Zeile zwischendurch ist fehlgeschlagen“. Bei der Untersuchung mitgelieferter Skripte urteilen Sie nicht allein nach dem Start. Die Praxis der Signatur steht in „PowerShell-Ausführungsrichtlinien und Skriptsignatur“.

Außerdem: Die Windows Server Core-Edition hat kein Protokoll AppLocker - MSI and Script. Bei der Untersuchung einer App auf einem Server ist auch das Vorhandensein des Protokolls zu beachten.²

5. Maßnahmen der verteilenden Seite — eine App, für die sich Regeln leicht schreiben lassen

Das Ziel ist, in einem Zustand zu liefern, in dem die IT-Abteilung des Kunden stabile Erlaubnisregeln schreiben kann. Die Signatur ist die zentrale Maßnahme, bedeutet aber nicht, dass die App unabhängig von der Richtlinie des Kunden läuft, sobald sie signiert ist. Was zusammenstehen muss, teilen wir in sechs Punkte.

Diese Vorbereitung hilft auch bei Smart App Control. Eine signierte Binärdatei mit aufgebautem Ruf bleibt von der automatischen Blockierung auf privaten PCs eher verschont.⁴

5.1. Wenn Sie zum ersten Mal ein Codesignaturzertifikat beschaffen

Ein RSA-Zertifikat einer vertrauenswürdigen Zertifizierungsstelle wählen

Wenn Sie an externe Kunden verteilen, wählen Sie ein RSA-basiertes Codesignaturzertifikat einer öffentlichen (kommerziellen) Zertifizierungsstelle. Ein selbstsigniertes Zertifikat oder eines einer internen CA lässt sich auf einem Kunden-PC, der dieser CA nicht vertraut, nicht prüfen und wird von Smart App Control nicht unterstützt.⁶

Prüfen Sie auch den Algorithmus. Die Signaturprüfung von Smart App Control unterstützt keine Signaturen mit elliptischer Kurvenkryptografie (ECC). Signieren Sie mit ECC, kann die Datei auf privaten PCs wie unsigniert behandelt werden.⁶

Auch bei App Control unterstützen Regeln auf Signaturgeberbasis nur RSA (bis 4096 Bit). Versuchen Sie, eine ECDSA-Signatur mit einer Herausgeberregel zu erlauben, steht in der zugehörigen 3089 VerificationError = 23. ECC allein deshalb zu wählen, weil „ECC neuer und stärker ist“, führt bei der Ausführungssteuerung in die Inkompatibilität.⁷

Für Herausgeberregeln sind OV und EV beide verwendbar

Öffentliche CA-Zertifikate gibt es als OV mit Prüfung der Unternehmensidentität und als EV mit strengerer Prüfung. Herausgeberregeln von AppLocker und App Control lassen sich mit beiden Zertifikaten schreiben.

App Control hat die Regeloption Required:EV Signers, die offizielle Dokumentation nennt sie jedoch derzeit nicht unterstützt. Es gibt also keinen Grund, EV um der hier behandelten Ausführungssteuerung willen zu wählen. Das Verhältnis zu SmartScreen ist getrennt in „Windows SmartScreen und Codesignatur“ geordnet.⁷

Nicht nur den Zertifikatspreis, sondern Aufbewahrung des privaten Schlüssels und Signaturbetrieb kalkulieren

Die Kosten unterscheiden sich nach CA und Gültigkeitsdauer. Im Angebot prüfen Sie neben dem Zertifikat selbst den Token, das HSM oder die Gebühr des Cloud-Signaturdienstes der CA.

Für Zertifikate, die am oder nach dem 1. Juni 2023 ausgestellt werden, verlangen die Vorgaben des CA/Browser Forum, unabhängig von OV oder EV den privaten Schlüssel in Hardware der Stufe FIPS 140-2 Level 2 oder gleichwertig (HSM oder USB-Token) zu erzeugen und aufzubewahren.⁸

Signieren Sie in CI/CD automatisch, ist ein Cloud-Signaturdienst oft leichter einzurichten als ein physischer Token. Bevor Sie ein Zertifikat kaufen, ist es praxisnah, auch den Ablauf von Build bis Signatur zu klären.

Alle Binärdateien signieren und einen Zeitstempel setzen

Authenticode-Signaturen stellen Sie nicht nur auf der exe, sondern auf eigenen DLL-Builds, dem Installer (MSI oder Setup-exe) und mitgelieferten Skripten zusammen. Mit Signaturmetadaten kann der Kunde updatefeste Regeln schreiben wie „dieses Produkt dieses Herausgebers unabhängig von der Version erlauben“.³

Den Zeitstempel setzen Sie, damit die Signatur nach Ablauf des Zertifikats gültig bleibt. Ein Minimalbeispiel mit signtool aus dem Windows SDK:

:: Signieren (mit SHA-256 hashen und RFC-3161-Zeitstempel setzen)
signtool sign /fd sha256 /tr <URL des Zeitstempelservers> /td sha256 /a MyApp.exe

:: Signatur prüfen (unter der Authenticode-Richtlinie prüfen und Details anzeigen)
signtool verify /pa /v MyApp.exe

Den Zeitstempelserver nehmen Sie von der URL, die die CA angibt, bei der Sie gekauft haben. Nutzen Sie einen Schlüssel auf Token oder HSM, prüfen Sie in der Anleitung der CA auch die Angabe von CSP/KSP. DLLs und Installer lassen sich mit demselben Befehl signieren, deshalb machen Sie Signieren und Prüfen zum letzten Schritt des Builds.

5.2. Änderungen an Zertifikat und Dateiattributen als Änderung der Kundenregeln behandeln

Auch bei einheitlicher Signatur wird eine neue Version gestoppt, wenn sich ändert, womit die Regeln vergleichen. Zu prüfen sind nicht nur Subject und Kette des Zertifikats. Produktname, ursprünglicher Dateiname und Version stammen aus der Versionsressource jeder Datei (Assembly-Informationen), nicht aus dem Zertifikat.

Publisher von App Control ist „PCA-Zertifikat (üblicherweise eine Stufe unter der Wurzel) + CN des Blattzertifikats“, FilePublisher fügt das FileName-Attribut der signierten Datei (standardmäßig OriginalFileName) und eine Mindestversion hinzu.⁷

Für den Kunden sehen solche Änderungen aus wie „nach dem Update startet es nur in dieser Umgebung nicht mehr“. Ändern Sie Firmenbezeichnung, CA oder Produkt- und Dateiattribute, setzen Sie in die Versionshinweise eine Gegenüberstellung der alten und neuen Signaturinformationen (Subject, ausstellende CA) und kündigen Sie vorher an. So kann die IT-Abteilung des Kunden Erlaubnisregeln ergänzen oder aktualisieren.

5.3. Ablageort und Ablauf der automatischen Aktualisierung stabil halten

Legen Sie ausführbare Dateien unter Program Files und vermeiden Sie Entwürfe, die zur Laufzeit exe oder DLL nach %TEMP% oder %APPDATA% entpacken und von dort starten. Ein Entwurf, der von einem vom Benutzer beschreibbaren Ort ausführt, passt schlecht zu Umgebungen mit Pfadregeln.

Bei der automatischen Aktualisierung signieren Sie auch das Updateprogramm selbst, sodass eine signierte Binärdatei durch eine signierte Binärdatei ersetzt wird. Die Einzelheiten eines sicheren Entwurfs stehen in „Sicherheitsdesign für Auto-Updates“.

Bei Verteilung über Intune oder Configuration Manager gilt: Hat der Kunde den Verteilungsagenten als Managed Installer konfiguriert, können Binärdateien, die über diesen Weg ankommen, betrieblich erlaubt werden. Allein über Intune zu verteilen erlaubt sie nicht automatisch; ausdrückliche Konfiguration durch einen Administrator ist Voraussetzung. Ein MSI mit Unterstützung für die stille Installation gibt dem Kunden diese Option in die Hand.

5.4. In der Einführungsanleitung die Informationen zusammenstellen, mit denen sich Regeln schreiben lassen

Die Einführungsanleitung an den Kunden soll Subject der Signatur, Liste der zum Ausführen nötigen Binärdateien und Installationspfade enthalten. Das ist die Grundlage, auf der die IT-Abteilung Erlaubnisregeln schreibt.

Im Blockierungsfall soll sich die Prüfung anhand der Protokollnamen und Ereignis-IDs aus Kapitel 4 anfordern lassen. Das verringert den Hin und Her, der bei „es startet nicht“ stehen bleibt, und lässt Zieldatei und Signaturinformation sofort abgleichen.

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

Die Grundreihenfolge der einführenden Seite ist Technik wählen → Wirkung mit Überwachung prüfen → Erlaubnisregeln ordnen und erzwingen → Ausnahmen weiter verwalten. Wichtig ist, nicht sofort auf allen Geräten zu blockieren.

6.1. Die Technik nach dem Einsatzzweck wählen und die Voraussetzungen der Überwachung zusammenstellen

Grundsatz ist App Control for Business. AppLocker kommt dazu, wenn auf einem gemeinsam genutzten PC Steuerung pro Benutzer nötig ist oder ältere Betriebssysteme gemischt sind.³ Bei PCs mit festem Zweck wie Kiosks vereinfacht eine vorherige Einschränkung der Shell die Regeln. Siehe auch „Geschäftsterminals mit dem Kioskmodus absichern“.

Die Überwachung sammelt „was unter Erzwingung blockiert worden wäre“, ohne den Betrieb zu stoppen. Bei AppLocker muss AppIDSvc laufen; steht der Dienst, erscheinen auch keine Überwachungsereignisse. Konfigurieren Sie den automatischen Start auf den Zielgeräten, bevor Sie beginnen.

Der Gedanke, bis zum Durchlauf eines kompletten Geschäftszyklus zu sammeln und dann zur Erzwingung zu gehen, ist derselbe wie bei SMB-Signatur oder NTLM-Einschränkungen. Beziehen Sie monatliche und jährliche Stapel ein, und schließen Sie die Prüfung nicht allein mit dem Alltag ab.

6.2. AppLocker geht in drei Schritten von der Überwachung zur Erzwingung

1. Den Überwachungsmodus aktivieren. Im Editor für Gruppenrichtlinien (lokal secpol.msc) öffnen Sie Computerkonfiguration > Richtlinien > Windows-Einstellungen > Sicherheitseinstellungen > Anwendungssteuerungsrichtlinien > AppLocker. Klicken Sie AppLocker mit der rechten Maustaste an, öffnen Sie Eigenschaften, wählen Sie je Regelauflistung (ausführbare Dateien, Windows Installer, Skripte, Paket-Apps) „Konfigurieren“ und setzen Sie „Nur überwachen“. Erstellen Sie in jeder Auflistung die Standardregeln und konfigurieren Sie den automatischen Start von AppIDSvc.

2. Ereignisse aus dem zum Ziel passenden Protokoll sammeln. Bei exe/DLL ist das 8003 in EXE and DLL, bei Skripten und MSIs 8006 in MSI and Script. Der Befehl in Abschnitt 4.1 erfasst nur EXE and DLL, 8006 holt er nicht. Um beides zu sehen, holen Sie die Protokolle getrennt wie folgt.¹

    # Im Überwachungsmodus „was unter Erzwingung 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
    }
   

   Weil Get-WinEvent bei einem Protokoll ohne passende Ereignisse einen Fehler zurückgibt, setzt dieses Beispiel -ErrorAction SilentlyContinue. Kommt keine Ausgabe, prüfen Sie den Dienst, das Zielprotokoll und den Abfragezeitraum. Sind auch Paket-Apps im Umfang, fügen Sie Packaged app-Deployment / Packaged app-Execution in derselben Form hinzu und prüfen Sie bis zu den monatlichen und jährlichen Stapeln.

3. Erlaubnisregeln ordnen, dann auf Erzwingung umschalten. Prüfen Sie die betrieblich nötigen Dateien aus 8003 und 8006 und übernehmen Sie sie in die Erlaubnisregeln. Danach stellen Sie im selben Eigenschaftendialog auf „Regeln erzwingen“. Nach dem Umschalten überwachen Sie Blockierungen in 8004 (exe/DLL) und 8007 (Skripte und MSIs).

6.3. Bei App Control die Überwachungsoption entfernen und zur Erzwingung gehen

Verteilen Sie die Richtlinie mit Regeloption 3 (Enabled:Audit Mode) in der Richtlinien-XML. Zum Setzen dienen der App Control Policy Wizard oder das Cmdlet Set-RuleOption.⁷

Prüfen Sie die Wirkung auf den Betrieb in 3076 und 8028, ordnen Sie die Erlaubnisregeln und entfernen Sie dann die Überwachungsoption; das ist der Erzwingungsmodus. Microsoft empfiehlt ebenfalls, eine neue Richtlinie zuerst im Überwachungsmodus zu prüfen.⁷

6.4. Unsignierte Ausnahmen an die Anlagenverwaltung binden

Ältere Business-Apps, die unsigniert weiterlaufen, werden mit Hashregeln als Ausnahme eingetragen und so verwaltet. Diese Liste ist zugleich die Liste der Anlagen, die künftig zu ersetzen sind. Hören Sie nicht beim Anlegen der Ausnahme auf: Binden Sie sie an die Anlagenverwaltung und prüfen Sie sie jedes Jahr.

7. Zusammenfassung

Der Umgang mit der Ausführungssteuerung lässt sich in drei Punkte fassen: die Mechanismen unterscheiden, im Protokoll feststellen, Lieferungen bauen, für die Erlaubnisregeln stabil bleiben.

SmartScreen ist grundsätzlich eine Warnung, unter einer Richtlinie, die das Übergehen untersagt, wird sie zur Blockierung. Halten Sie sie getrennt von AppLocker, App Control und Smart App Control. Die Editionsbeschränkung von AppLocker ist gelockert, App Control läuft auf allen Client-Editionen. Smart App Control wirkt auch auf privaten PCs, deshalb gilt „es ist Pro“ oder „es gibt keine IT-Abteilung“ nicht als Unbetroffenheit.⁵³⁴

Wenn es nicht startet, nehmen Sie AppLocker 8004 und App Control 3077 und 3089 als Einstieg und gleichen Sie auch die Protokolle von Skripten und MSIs ab. Schlägt nur ein Teil der Funktionen fehl, prüfen Sie auch den Constrained Language Mode von PowerShell.¹²

Die verteilende Seite stellt einheitliche Signatur aller Binärdateien, Zeitstempel, stabile Herausgeberinformationen und Dateiattribute, übliche Ablageorte, signierte automatische Aktualisierung und eine Einführungsanleitung zusammen. Der Grundsatz ist eine App, für die der Kunde Erlaubnisregeln leicht schreiben und nach einem Update leicht halten kann.

Die einführende Seite lässt den Betrieb unter AppLocker 8003 und 8006 sowie App Control 3076 und 8028 einen kompletten Zyklus durchlaufen und geht dann zur Erzwingung. Wenn Verteilung und Betrieb zusammenstehen, sinken die Fälle „es läuft nur in der Kundenumgebung nicht“.

Verwandte Artikel

• Warum Windows die Meldung „Der Computer wurde durch Windows geschützt“ anzeigt
• Sicherheitsdesign für Auto-Updates - Warum HTTPS allein nicht reicht
• Windows-App-Verteilung wählen – MSI/MSIX/ClickOnce/xcopy/eigener Updater
• PowerShell-Ausführungsrichtlinien und Skriptsignatur — Ein praktischer Leitfaden zum Abschied vom „Zudecken mit Bypass“
• Wenn die eigene Windows-App als Virus gemeldet wird — Umgang mit Fehlalarmen von Microsoft Defender
• Windows-Kioskmodus und zugewiesener Zugriff
• Praktische Optionen nach dem Support-Ende von Windows 10 — Eine Entscheidungstabelle für ESU, LTSC und Ersatz

Verwandte Beratungsleistungen

Die KomuraSoft LLC übernimmt Entwicklung und Anpassung von Business-Apps, die unter Ausführungssteuerung (AppLocker / App Control for Business) laufen, den Entwurf von Verteilung und automatischer Aktualisierung mit eingebauter Codesignatur sowie die Untersuchung von Fällen, in denen eine App in der Kundenumgebung nicht startet.

• Windows-Anwendungsentwicklung
• Anpassung und Wartung bestehender Windows-Software
• Fehleranalyse und Ursachenermittlung
• Kontakt

Quellen

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 Codesignatur“ 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: Codesignatur. 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.