Bild: Albert Hulm
Ein PC bleibt zuverlässiger und sicherer, wenn auf ihm nur eine handverlesene Auswahl von Programmen läuft. Um das sicherzustellen, verwenden professionelle Admins ein Windows-Werkzeug namens AppLocker. Mit ein paar Tricks und einigen c’t-Skripten schützt es auch Ihren heimischen Rechnerzoo.
Bild: Albert Hulm
Um Malware fernzuhalten, setzen viele Windows-Anwender auf Virenscanner. Die sind nicht komplett nutzlos, allerdings ist ihr Ansatz prinzipbedingt lückenhaft: Die Virenjäger können ja nur das an Schadprogrammen finden, was sie kennen. Daran ändern auch alle möglichen Heuristiken nichts, die Malware an ihrem Verhalten erkennen sollen: Irgendwo stricken Cybergangster mit Sicherheit schon am nächsten Mechanismus, um ihre Opfer zu schädigen.
Statt sich also bekannte Schädlinge vom Leib zu halten, wäre es doch viel schlauer, zunächst mal alles Unbekannte als böse zu verdächtigen und nur die Software zuzulassen, die sich auf die eine oder andere Weise als unverdächtig ausgewiesen hat. Genau diesen Ansatz verfolgt das sogenannte Whitelisting: Es erlaubt Programmen nur dann zu starten, wenn sie auf einer Erlaubnisliste harmloser Software – der Whitelist – verzeichnet sind. Um so eine Liste zu pflegen, bietet Windows zwei verschiedene Ansätze. Die „Richtlinien für Softwareeinschränkung“ (englisch „Software Restriction Policies“ oder kurz SRPs) sind Thema des Artikels „Apps nur aus dem Store installieren“. In diesem hier geht es um deren Nachfolger: den AppLocker.
Obwohl Microsoft den AppLocker intern gelegentlich auch als SRPv2 bezeichnet, unterscheiden sich die von ihm benutzten Mechanismen deutlich von denen seines Vorfahren. Noch deutlicher als bei den SRPs ist beim AppLocker zu spüren, dass er sich eigentlich nicht an Windows-Anwender zu Hause oder in kleinen Organisationen richtet, sondern an Administratoren, die in größeren Unternehmensnetzen ihre Clients schützen wollen. Bis vor gar nicht allzu langer Zeit war der AppLocker denn auch nur in den Enterprise-Ausgaben von Windows enthalten. Bei Windows 10 und 11 Pro hat Microsoft mittlerweile nachgelegt. Auch in den Home-Ausgaben kann man den AppLocker seit Kurzem benutzen, allerdings nur über Umwege – dazu weiter unten mehr.
Zu den Verbesserungen des AppLocker gegenüber den SRPs gehört, dass er zum Verwalten der Erlaubnisliste etliche neue Regeln kennt. So kann er nicht mehr nur reine Windows-Desktop- und Konsolenprogramme am Ausführen hindern, sondern mit jeweils gesonderten Regelsätzen auch Skripte, Windows-Apps und Installationspakete. Außerdem kann man bei jeder Regel angeben, für welche Benutzerkonten oder -gruppen sie gelten soll. Damit halten Firmen-Admins beispielsweise Unbefugte von den Programmen zur Auswertung der Geschäftszahlen fern und Familienoberhäupter den Nachwuchs von unangemessenen Spielen.
In Unternehmensnetzen verteilen Administratoren die AppLocker-Regeln normalerweise über Gruppenrichtlinien, englisch Group Policies. In allen Windows-Ausgaben außer den Home-Editionen ist aber auch ein Editor für lokale Gruppenrichtlinien enthalten (Gpedit.msc), mit dem man die auf diesem Rechner geltenden Policies bearbeiten kann. Zu dem gehört auch der Editor für die lokale Sicherheitsrichtlinie (Secpol.msc), in der unter anderem die AppLocker-Einstellungen stecken.
Dass der Gruppenrichtlinieneditor in Windows Home nicht enthalten ist, stimmt eigentlich nicht: Auf der Systempartition ist er schon vorhanden, nur nicht ins System eingebunden. Das lässt sich aber ändern: Findige Tüftler haben eine Batch-Datei geschrieben, die Gpedit unter Zuhilfenahme des in Windows eingebauten Programms dism installiert, indem sie die dafür zuständigen Pakete aus den Tiefen des Windows-Ordners aktiviert. Wo das Skript zuerst aufgetaucht ist, lässt sich nicht mehr mit Bestimmtheit herausfinden; in der Zip-Datei, die wir zu diesem Artikel als Download bereitstellen (siehe ct.de/wrs8) ist sie als „gpedit-enabler.cmd“ enthalten. Das Skript lädt keinerlei Daten aus dem Internet, schon gar keine externen Programme. Auf einen kleinen Wermutstropfen sei aber hingewiesen: Allein dadurch, dass das Skript die lokalen Gruppenrichtlinien unter Windows Home bearbeitbar macht, ist noch lange nicht sichergestellt, dass dort auch jede Policy-Einstellung wirklich so wirkt, wie sie das unter anderen Windows-Ausgaben tun würde. Im Zweifel ist Experimentieren angesagt. Wie Sie noch sehen werden, brauchen auch die AppLocker-Einstellungen eine Extra-Einladung.
Auch in den Pro-Editionen von Windows ist noch ein wenig Vorarbeit nötig, um den AppLocker in Betrieb zu nehmen. Damit er funktioniert, muss nämlich der Dienst „Anwendungsidentität“ laufen (Windows-intern heißt er AppIDSvc). Es gilt, ihn zu starten und dafür zu sorgen, dass er nach jedem Systemstart erneut geladen wird. Von Hand können Sie das über die Computerverwaltung erledigen: Sie öffnet sich durch Auswahl des gleichnamigen Befehls aus dem Rechtsklickmenü des Startmenüs. Suchen Sie in der Liste unter „Dienste und Anwendungen/Dienste“ den Eintrag „Anwendungsidentität“ und öffnen Sie seine Eigenschaften durch einen Doppelklick. Die Auswahl des Starttyps „Automatisch“, ein Klick auf „Übernehmen“ und anschließend auf „Starten“ erledigen alles Nötige.
Alternativ lassen Sie die Batch-Datei AppLocker-Prep.cmd aus unserem Download-Archiv die ganze Arbeit machen. Sie benötigt Administratorrechte und prüft zunächst, unter welcher Windows-Edition sie läuft. Unter Windows Home ruft sie nach Rückfrage die Policy-Editor-Installation auf, unter allen anderen Editionen konfiguriert sie den Anwendungsidentitätsdienst passend.
Einmal aktiviert schützt sich der Dienst davor, beendet oder deaktiviert zu werden. Ihn anzuhalten, scheitert stillschweigend, und jeder Versuch, einen anderen Starttyp als „Automatisch“ einzustellen, endet mit der Fehlermeldung „Zugriff verweigert“. Sollten Sie sich irgendwann mal anders entscheiden und den AppLocker wieder komplett stilllegen wollen, besteht die einzige Möglichkeit darin, in der Registry unter HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\AppIDSvc den Wert „Start“ manuell wieder auf 3 (für „Manuell“) zu setzen und Windows neu zu starten.
Die AppLocker-Konfiguration steckt im Editor für die „Lokale Sicherheitsrichtlinie“. Sie teilt sich in vier Bereiche auf.
Bitte nicht irritieren lassen: Auch die Regeln, bei denen „Konfiguriert“ ausgeschaltet ist, gelten und werden durchgesetzt.
Wie schon erwähnt ist das Werkzeug zum Konfigurieren der AppLocker-Regeln der Editor für die lokale Sicherheitsrichtlinie. Um ihn zu starten, drücken Sie die Tastenkombination Windows+R und tippen dann secpol.msc in den aufpoppenden Dialog ein. Die AppLocker-Einstellungen finden Sie in der lokalen Sicherheitsrichtlinie unter „Sicherheitseinstellungen\ Anwendungsrichtlinien\AppLocker“.
Wenn Sie diesen Eintrag links in der Baumansicht aufklappen, sehen Sie die vier Kategorien von Objekten, in deren Start der AppLocker eingreifen kann: Hinter „Ausführbare Regeln“ verbergen sich Einstellungen für gewöhnliche Desktop- und Konsolenprogramme, die in der Regel als EXE-Dateien daherkommen. „Windows Installer-Regeln“ beeinflussen die Installation von Programmen aus MSI-Paketen und verwandten Dateiformaten. Die „Skriptregeln“ beziehen sich auf Batch-Dateien, PowerShell-Skripte sowie Dateien für den Windows Script Host mit den Endungen .vbs und .js. „App-Paketregeln“ greifen, wenn moderne Windows-Apps gestartet werden sollen, also Windows-eigene Apps wie „Kalender“ oder „Wetter“ sowie die meisten Apps aus dem Microsoft Store.
Ein Klick auf den Baumeintrag „AppLocker“ selbst zeigt in der rechten Fensterhälfte eine Übersichtsseite mit einigen Links zu Microsofts Online-Dokumentation sowie einer Zusammenfassung der definierten Regeln an. Der wichtigste Link auf dieser Seite heißt „Regelerzwingung konfigurieren“ und führt auf die AppLocker-Eigenschaften. Der Dialog bietet für jede Regelkategorie einen Schalter „Konfiguriert“; ist er eingeschaltet, lassen sich darunter die Optionen „Regeln erzwingen“ und „Nur überwachen“ auswählen. Die Einstellungen sind ein bisschen missverständlich. Für den Hausgebrauch bedeuten „nicht konfiguriert“ einerseits und „konfiguriert“ nebst „Regeln erzwingen“ andererseits dasselbe: Vorhandene Regeln werden durchgesetzt. Einen Unterschied machen diese beiden Zustände allenfalls in Unternehmensumgebungen, in denen die AppLocker-Regeln von Policies aus verschiedenen Quellen stammen können.
Die Kombination „Konfiguriert“ und „Nur überwachen“ bewirkt dagegen, dass der AppLocker Ereignisse der jeweiligen Kategorie nicht unterbindet, sondern in einen „Was wäre wenn“-Modus schaltet: Beispielsweise lassen sich sämtliche Programme starten, auch wenn sie eigentlich durch eine Regel verboten sind. Die Programmstarts protokolliert der AppLocker aber im System-Log.
Das können Sie mit der Ereignisanzeige auswerten. Starten lässt sich diese am einfachsten über das Windows+X-Menü (Kontextmenü des Startmenüs). In der Ereignisanzeige finden Sie die AppLocker-Protokolle unterhalb von „Anwendungs- und Dienstprotokolle/Microsoft/Windows/AppLocker“. Sie sind in die vier aus der Konfiguration bekannten Bereiche aufgeteilt.
Ist der AppLocker einmal in Betrieb, füllt sich der Bereich „EXE and DLL“ erfahrungsgemäß recht schnell. Um die wesentlichen Einträge überhaupt noch zu sehen, sollten Sie die Anzeige filtern. Das geht über das Kontextmenü des Protokolls in der Baumansicht oder den Eintrag „Aktuelles Protokoll filtern“ rechts unter den Aktionen. Für eine bessere Übersicht sollten Sie den Filter so einstellen, dass er nur noch Einträge der Ebenen „Kritisch“, „Fehler“ und „Warnung“ anzeigt: Wenn der AppLocker eine Aktion wie einen Programmstart verhindert hat, protokolliert er das als Fehler, Überwachungsereignisse der Kategorie „Das wäre bei aktivierten Regeln gescheitert“ werden zu Warnungen. „Kritische“ Ereignisse sind uns bei unseren Experimenten nicht untergekommen, aber man weiß ja nie …
Sie können sich das Herumgeklicke in der Ereignisanzeige übrigens mit benutzerdefinierten Ansichten erleichtern: Der Befehl, um eine solche zu erstellen, findet sich rechts unter „Aktionen“. So eine Ansicht kann nicht nur nach Ereignisklassen oder -IDs filtern, sondern auch Einträge aus mehreren Protokollen zusammenfassen. Damit können Sie sich zum Beispiel einen schnellen Überblick über alle vier AppLocker-Protokolle gleichzeitig verschaffen.
Zurück zum AppLocker: Bevor Sie den mit tatsächlich erzwungenen Regeln in Betrieb nehmen, lautet die dringende Empfehlung: Konfigurieren Sie für die Bereiche, die Sie absichern wollen, zunächst den „Nur überwachen“-Modus, erstellen Sie die gewünschten Regeln und beobachten Sie eine Zeit lang, wie sie sich auf Ihre tägliche Arbeit auswirken würden. Erst wenn Sie im Protokoll keine gravierenden Nebenwirkungen mehr finden, schalten Sie die Regeln scharf.
Und gleich noch eine Empfehlung: In allen vier Bereichen enthält das Kontextmenü der Regelliste den Befehl „Standardregeln erstellen“. Den sollten Sie tunlichst ausführen, bevor Sie irgendwelche selbst erdachten Regeln eintragen. Er sorgt für eine Minimalausstattung an Regeln, die sicherstellt, dass Windows zumindest selbst noch bedienbar bleibt. Sobald nämlich einer der Bereiche eine oder mehrere Regeln enthält, ist in dieser Sektion automatisch alles verboten, was von den Regeln nicht erfasst ist.
Auch der Befehl „Neue Regel erstellen“ zum Definieren eigener Regeln verbirgt sich im Rechtsklickmenü. Er führt in einen Assistenten, der Sie beim Konfigurieren neuer Regeln unterstützt. Im ersten Schritt will er wissen, ob es sich um eine „Zulassen“- oder eine „Verweigern“-Regel handeln soll. „Zulassen“ ist praktisch immer die richtige Auswahl – das Prinzip des Whitelisting beruht ja gerade darauf, dass zunächst mal alles verboten ist und Ausnahmen explizit konfiguriert werden müssen. Außerdem können Sie festlegen, für wen die Regel gelten soll; als Berechtigte kommen bestehende Benutzerkonten oder -gruppen infrage. So können Sie zum Beispiel für sich selbst den Zugriff auf bestimmte Programme freischalten, die für andere Konten tabu sind.
Der nächste Schritt des Assistenten entscheidet darüber, welche Regelart zum Einsatz kommen soll. Davon kennt der AppLocker drei Stück: Herausgeberregeln entscheiden anhand der in einem Programm oder Skript enthaltenen Signatur – genauer: deren Herausgeber –, ob es der Regel entspricht. Pfadregeln bestimmen das anhand des Ordners, in dem ein Programm liegt, oder anhand dessen kompletten Dateinamens samt Pfad. Schließlich gibt es noch Dateihash-Regeln. Sie speichern eine kryptografisch erzeugte Prüfsumme einer ganz bestimmten Datei und lassen dann auch nur diese Datei durch.
Bei den Regeltypen Herausgeber und Pfad gibt es im folgenden Schritt des Assistenten noch die Möglichkeit, Ausnahmen zu definieren. So kann zum Beispiel eine Pfadregel dazu dienen, für normale Benutzer alle Programme aus dem Windows-Ordner zu erlauben, und eine Ausnahme nimmt diese Berechtigung für den Registry-Editor (regedit.exe) oder die Eingabeaufforderung (cmd.exe) wieder zurück. Unabhängig von der eigentlichen Regel stehen auch für die Ausnahmen wieder alle genannten Kriterien zur Verfügung.
Im letzten Schritt will der Assistent noch einen Namen für die neue Regel haben und nimmt auf Wunsch eine genauere Beschreibung entgegen. Mit einem Klick auf „Erstellen“ wird die Regel sofort gültig und wacht über die angegebenen Dateien. Das gilt jedenfalls für alle Windows-Editionen außer Home – auf den Sonderfall kommen wir gleich noch zu sprechen.
Wenn bislang erklärt wurde, die „Ausführbaren Regeln“ gelten für gewöhnliche Programme, dann ist das nur die halbe Wahrheit: Sie können nämlich darüber hinaus auch als Filter für DLLs (und die einigermaßen aus der Mode geratenen OCX-Dateien) dienen. Einschalten lässt sich die DLL-Prüfung über eine zweite Seite des Dialogs zur Regelerzwingung. Die auf dieser Seite angezeigte Warnung sollten Sie aber ernst nehmen: Ist dieser Modus eingeschaltet, muss Windows beim Start jedes Prozesses unzählige Dateien prüfen, was enorm auf die Systemleistung drückt. In unseren Versuchen hat diese Einstellung mitunter zu sekundenlangen Pausen geführt, in denen Windows komplett stillzustehen schien. Also besser Finger weg.
Sobald Sie mindestens eine EXE-Regel konfiguriert haben, sollten Sie auch unbedingt eine Regel für App-Pakete definieren. Die Standardregel winkt alle signierten Apps durch; zu einer restriktiveren Strategie kommen wir gleich. Ohne App-Regel taucht bei jedem Versuch, eine App zu starten, im Systemprotokoll ein Eintrag mit folgendem Text auf: „Es können keine App-Pakete ausgeführt werden, während Exe-Regeln erzwungen werden und keine App-Paketregeln konfiguriert worden sind.“ Im Klartext: Windows lädt keine Apps mehr. Und zu denen gehört unter Windows 11 auch das Startmenü – es öffnet sich dann einfach nicht mehr.
AppLocker-Regeln werden mit einem Assistenten erstellt, lassen sich aber anschließend noch per Doppelklick bearbeiten. Für Pfadregeln verwendet der AppLocker spezielle Platzhalter.
Eine Besonderheit, die sich nicht auf den ersten Blick erschließt, gibt es auch bei den AppLocker-Regeln für Skripte: Versucht man, ein Skript zu starten, das keiner der Regeln genügt, lehnt Windows das nicht rundheraus ab. Stattdessen wird das für das jeweilige Skriptformat zuständige Programm gestartet und gleichzeitig darüber informiert, dass das Skript eigentlich blockiert ist. Was dann weiter passiert, entscheidet der Skript-Interpreter. Die Eingabeaufforderung (für Batch-Dateien) und der Windows Script Host (für VBS- und JS-Dateien) lehnen die Ausführung kategorisch ab. Die PowerShell startet ein solches Skript trotzdem, versetzt es aber in den sogenannten ConstrainedLanguage-Modus, in dem nur noch PowerShell-eigene Grundbefehle erlaubt sind und der Zugriff auf Erweiterungen und bestimmte, als gefährlich eingestufte Befehle unterbunden wird.
Über was für eine Regel Sie die von Ihnen gewünschten oder benötigten Programme und Skripte freigeben, müssen Sie von Fall zu Fall entscheiden. Als Grundstock lassen die Standardregeln alles durch, was im Windows- oder im Programme-Ordner gespeichert ist. Beim Erstellen von Pfadregeln verwendet der AppLocker eigene Platzhalter, die an Umgebungsvariablen erinnern. So steckt beispielsweise hinter %WINDIR% der Windows-Ordner und hinter %PROGRAMFILES% der Programme-Ordner. Unter letzteren fällt auf 64-Bit-Systemen auch der Ordner „Programme (x86)“ für 32-Bit-Anwendungen. Die Inhalte dieser Ordner gehören zum System oder sind durch reguläre Installationsprogramme auf den Rechner gekommen, bei denen Sie hoffentlich die Vertrauenswürdigkeit der Herkunft geprüft haben. Dateirechte schützen sie vor Manipulationen – wichtig ist, dass Ordner mit ausführbaren Programmen nicht ohne volle Administratorrechte beschreibbar sind.
Leider gilt das nicht für alle Unterverzeichnisse des Windows-Ordners, und auch Programminstallationen enthalten gelegentlich beschreibbare Unterordner. Deshalb haben wir das PowerShell-Skript „Check-AppLockerRules“ entwickelt und in das Download-Paket zu diesem Artikel gepackt (siehe ct.de/wrs8). Es benötigt Administratorrechte, die es sich aber bei Bedarf selbst verschafft. Nach dem Start wertet es die bestehende AppLocker-Konfiguration aus und sucht in allen per Pfadregel freigeschalteten Ordnern nach Benutzer-beschreibbaren Unterordnern. Diese trägt es dann als Ausnahmen in die jeweilige Regel ein, nachdem es Sie dazu um Erlaubnis gefragt hat. Mit der – empfehlenswerten – Kommandozeilenoption -FullAuto oder der Antwort „V“ auf die erste Nachfrage erledigt es seinen Job per [V]ollautomatik. Sicherheitshalber sollten Sie das Skript jedes Mal von Neuem laufen lassen, wenn Sie im AppLocker eine neue Pfadregel eingetragen haben. Wenn Sie das Ergebnis anschließend kontrollieren wollen, sollten Sie den Sicherheitsrichtlinien-Editor vor der Skriptausführung beenden und anschließend neu öffnen. Falls Sie ansonsten nichts mit der PowerShell am Hut haben und das Skript nicht gestartet bekommen, lesen Sie bitte den Kasten „PowerShell-Zicken“. Zu beachten ist natürlich außerdem, dass das Skript selbst nicht durch den AppLocker an der Ausführung gehindert werden darf – eine entsprechende Hash-Regel eignet sich dazu am besten.
Für andere Anwendungen, die sich nicht in den Programme-Ordner installieren oder die Sie als portable Programme auf die Platte kopieren, sind Herausgeberregeln meist die bessere Wahl. Sie definieren sie, indem Sie die freizugebende Programmdatei auswählen. Sofern sie eine Signatur trägt – und das sollte sie, wenn Sie sicher sein wollen, dass sie aus vertrauenswürdiger Quelle stammt –, bietet Ihnen der AppLocker anschließend die darin enthaltenen Herausgeberinformationen an und Sie können wählen, welche davon Sie in die Regel übernehmen wollen. Bei großen, vertrauenswürdigen Softwareherstellern reicht vielleicht der Herausgeber selbst oder zusätzlich der Produktname. Die Dateiversion sollten Sie in der Regel ignorieren, denn so spielt die Herausgeberregel ihren Vorteil gegenüber Hash-Regeln aus: Bei Updates müssen Sie nicht ständig nacharbeiten.
Bei Herausgeberregeln entscheiden Sie selbst, welche Informationen aus der Signatur ein Programm identifizieren sollen. So erwischen Sie mit einer einzigen Regel mehrere zu einer Anwendung gehörende Programmdateien und sparen sich das Aktualisieren der Regel nach Updates.
Gänzlich unabhängig vom AppLocker (oder den SRPs) gibt es in Windows eine Einstellung, die im Auslieferungszustand das Ausführen sämtlicher PowerShell-Skripte unterbindet: die sogenannte ExecutionPolicy (zu Deutsch: Ausführungsrichtlinie) der Windows PowerShell. Um zumindest lokale Skripte ausführen zu können, sollte man die PowerShell einmal mit Administratorrechten starten und den Befehl Set-ExecutionPolicy RemoteSigned eingeben. Mehr zu den Hintergründen dieser Richtlinie erfahren Sie mit dem PowerShell-Befehl help about_Execution_Policies oder in der Online-Doku (Link via ct.de/wrs8).
Die Einstellung RemoteSigned besagt, dass die PowerShell nur lokale Skripte ausführt. Skripte aus dem Internet akzeptiert sie nur, wenn diese eine vertrauenswürdige Signatur tragen. Um Ihnen die Möglichkeit zu geben, unsere Skripte zu diesem Artikel selbst an eigene Vorlieben anzupassen, haben wir sie absichtlich nicht signiert. Nach dem Download und vor dem Auspacken sollten Sie im Explorer daher einmal die Eigenschaften des Zip-Archivs öffnen. Dort steht wahrscheinlich im unteren Bereich: „Die Datei stammt von einem anderen Computer. Der Zugriff wurde aus Sicherheitsgründen eventuell blockiert.“ Wenn das der Fall ist, gibt es daneben ein Feld namens „Zulassen“. Indem Sie dort das Häkchen setzen, entfernen Sie das „Mark of the Web“ und sorgen dafür, dass Windows und die PowerShell die enthaltenen Dateien als lokal ansehen.
Wenn Sie Ihren Rechner bislang mit SRPs verrammelt haben und sich mit dem Gedanken tragen, auf den AppLocker umzusteigen, sollten Sie einige wichtige Unterschiede zwischen beiden Ansätzen kennen. Um einen der bedeutenderen zu erklären, müssen wir etwas ausholen: Auch Mitglieder der Administratoren-Gruppe arbeiten im normalen Betrieb mit den eingeschränkten Rechten eines normalen Benutzers. Erst wenn sie ein Programm „Als Administrator starten“ oder eine Anwendung das von sich aus verlangt, erhalten sie für diesen einen Prozess die vollen Rechte. Abgesehen von einigen Windows-eigenen Verwaltungswerkzeugen ist diese Rechteerweiterung stets mit einem „Sind Sie sicher?“-Dialog zu bestätigen, den die Windows-Anwendungssteuerung (User Account Control, kurz UAC) auf den Schirm bringt. Dadurch versucht Windows zu verhindern, dass sich Programme die vollen Rechte heimlich verschaffen. Dafür sollten Sie aber den Regler in den UAC-Einstellungen ganz nach oben schieben.
In den SRPs können Sie einmal zentral festlegen, ob die definierten Regeln auch für Administratoren gelten sollen. Gemeint ist damit die Frage, ob die Regeln auch für solche Prozesse greifen, die gerade die vollen Rechte genießen. Ist die Option „Administratoren einschließen“ ausgeschaltet, können Sie mit dem Kontextmenübefehl „Als Administrator ausführen“ trotzdem jedes Programm verwenden, auch wenn es ansonsten durch die SRPs blockiert ist.
Das ist beim AppLocker anders: Hier legen Sie für jede Regel einzeln fest, für wen sie gelten soll. Aber Achtung: Wenn Sie bestimmte Programme, Skripte oder Apps für die Gruppe der Administratoren freigeben, bedeutet das genau das! Jedes Mitglied der Administratoren kann dieses Programm dann starten. Bei der üblichen Arbeitsweise mit einem Admin-Konto unter UAC-Schutz ist das fatal: Mitglied dieser Gruppe sind Sie dann ja ständig, also können Sie auch jedes dafür freigegebene Programm ausführen. Dasselbe gilt für heimlich startende Schadprogramme, sofern sie einer AppLocker-Regel genügen, die für Administratoren gilt.
In der Praxis bedeutet das, dass der AppLocker für diese Arbeitsweise ungeeignet ist, weil man damit keinen Regelsatz hinbekommt, der unterscheiden kann, ob ein Admin gerade Alltagsdinge tut oder hinter der UAC-Schranke Systemwartung betreibt. An dieser Stelle zeigt sich ganz besonders die Ausrichtung des AppLocker auf Unternehmensumgebungen, in denen es ja unüblich ist, dass normale Anwenderkonten Mitglied der Administratoren sind. Wenn Sie ihn trotzdem verwenden wollen, haben Sie zwei Möglichkeiten: Entweder Sie richten sich für den Alltag ein Extra-Konto ohne Administratorrechte ein. Ihr Admin-Konto verwenden Sie dann wirklich nur für Verwaltungsaufgaben und melden sich von dort wieder ab, sobald die erledigt sind. Gerade wenn Ihre Windows-Installation schon eine Weile besteht und Sie Ihr Konto mühsam mit liebgewonnenen Einstellungen konfiguriert haben, ist der Umstieg aber schmerzhaft. Alternativ können Sie den AppLocker auch so konfigurieren, dass Administratoren keinerlei Sonderrechte genießen. Für Verwaltungsaufgaben richten Sie sich auch bei dieser Herangehensweise ein weiteres Konto mit Admin-Rechten ein, das Sie beispielsweise „Verwalter“ nennen. Dem weisen Sie dann im AppLocker die Rechte zu, die Sie als Admin brauchen, und benutzen dieses Konto nur für die Systemwartung.
Es ist schon mehrfach angeklungen: Um Windows Home per AppLocker abzudichten, ist es mit dem Definieren der Regeln nicht getan. Zur Erinnerung: Die Regeln landen in den Gruppenrichtlinien, die in größeren Organisationen zentral über die Windows-Domäne verteilt werden. Nun gehört zu den wesentlichen Einschränkungen von Windows Home aber, dass es keiner Domäne beitreten kann. Deswegen beachtet Windows Home auch keine per Policy gespeicherten AppLocker-Regeln.
Es gibt aber auch in größeren Unternehmen durchaus Rechner, die zur Firma gehören, aber nicht Mitglied einer Domäne sind. Beispiele sind vor allem mobile Geräte wie Notebooks, die nur gelegentlich mit dem Firmennetz verbunden sind, bei denen der Firmen-Admin aber trotzdem die Kontrolle über die zugelassene Software haben möchte. Solche Rechner lassen sich über einen „Mobile Device Management“ (kurz MDM) genannten Dienst konfigurieren. Dessen Einstellungen landen nicht in den Gruppenrichtlinien, sondern in einem speziellen, per WMI (Windows Management Instrumentation) verwalteten Speicherplatz. Das erledigt ein „MDM Bridge WMI Provider“, der seit einiger Zeit Bestandteil von Windows 10 und 11 ist.
Wie Sie dem eine im XML-Format geschriebene AppLocker-Regelsammlung unterschieben können, hat die von Microsoft zum „Most Valuable Professional“ (MVP) ernannte Bloggerin Sandy Zeng im Internet beschrieben (Link via ct.de/wrs8). Deren Skript haben wir so weiterentwickelt, dass es die komplette AppLocker-Konfiguration in einem Rutsch aus den Gruppenrichtlinien ausliest und gleich wieder an den Bridge Provider verfüttert. Letzteres funktioniert nur unter dem von Windows selbst genutzten Benutzerkonto „Lokales System“. Aber auch darum kümmert sich unser Skript. Im Download-Archiv zu diesem Artikel ist dazu neben dem PowerShell-Skript AppLockerPolicy2MDM auch das Tool psexec von Microsoft Sysinternals enthalten.
Je nachdem, wie Sie das Konvertierungsskript starten, öffnen sich kurz nacheinander zwei oder drei Konsolenfenster und verschwinden gleich wieder. Das ist normal und der Jonglage mit psexec und den Benutzerrechten geschuldet. Am Ende sollte ein Fenster mit ein paar Statusmeldungen und der Aufforderung „Sie können dieses Fenster jetzt schließen“ übrig bleiben.
Zugegeben: Ein bisschen frickelig ist diese Lösung für Windows Home schon. Deshalb hier ein paar Worte der Warnung: Den Aufruf des Skripts nach getaner Arbeit in der lokalen Sicherheitsrichtlinie sollte man wirklich nicht vergessen! Denn diese greift nur auf die Policy-Daten zu. Eine Wirkung entfalten bei dieser Vorgehensweise aber ausschließlich die per MDM eingespielten Regeln. Man kann sich also wunderbar selbst ins Knie schießen, indem man Regeln konfiguriert oder wieder lockert und dann stundenlang grübelt, warum sie nicht wie vorgesehen funktionieren. Was man auf jeden Fall vermeiden sollte: die c’t-Methode etwa auf einem Dienst-PC oder sonst in einer Umgebung benutzen, in der ein Administrator den Rechner seinerseits mit AppLocker-Regeln beschickt. Und noch einmal: Unsere Skript-Lösung ist ausschließlich für Windows Home gedacht, unter Pro sorgt sie für Kuddelmuddel!
Allen Einschränkungen zum Trotz: Der AppLocker ist durchaus eine bedenkenswerte Alternative zu den SRPs. Dank der Skripte, die wir für diesen Artikel entwickelt haben, wird er auch unter den Windows-Ausgaben benutzbar, für die Microsoft ihn eigentlich nicht vorgesehen hat. Wie immer Sie sich entscheiden: Ganz ohne Whitelisting-Lösung zu arbeiten ist keine gute Idee. Und selbst wenn Sie mit den damit verbundenen Einschränkungen bei Ihrer eigenen Arbeit nicht leben können: Auf Rechnern, die Sie als Familien- oder Vereins-Admin betreuen, halten Sie sich damit eine Menge Ärger vom Hals, der ansonsten in Form von Malware-Infektionen früher oder später garantiert auftritt.
(hos) 
Skripte zum Download, Online-Doku
