Sicherheit

Sperren von Anwendungen mit Softwareeinschränkungsrichtlinien

Chris Corio and Durga Prasad Sayana

Auf einen Blick:

• Funktionsweise von Softwareeinschränkungsrichtlinien
• Erfassen von Anwendungen in Ihrer Umgebung
• Erstellen und Durchsetzen von Richtlinien

Wenn IT-Experten nach Möglichkeiten suchen, die Gesamtkosten ihrer Desktopcomputer zu verringern, greifen sie häufig auf zwei Hauptstrategien zurück. Die erste besteht darin, die Konten der Desktopbenutzer

aus der Administratorengruppe zu entfernen. Die zweite besteht im Begrenzen der Anwendungen, die von den Benutzern ausgeführt werden können. Die Lösung dieser Probleme kann in einer Unternehmensumgebung eine Herausforderung darstellen, Windows Vista® bietet aber einige Technologien, die Ihnen dabei helfen.

Windows Vista hat IT-Experten mit seinem Feature der Benutzerkontensteuerung einen großen Schritt vorangebracht, indem es ihnen ermöglicht, Unternehmensanwender als Mitglieder der Benutzergruppe (Standardbenutzer) auszuführen. Die Benutzerkontensteuerung änderte den Standardsicherheitskontext für alle Anwendungen in den eines Benutzers (statt eines Administrators). Diese Migration zur Benutzergruppe ist immer noch ein schwieriges Unterfangen, aber mit fortschreitender Umstellung der Branche auf dieses neue Paradigma wird diese Aufgabe im Lauf der Zeit einfacher.

Viele Administratoren katalogisieren nach (oder auch während) der Analyse der Aufgaben, die mit dem Verschieben der Benutzer in die Benutzergruppe verbunden sind, welche Anwendungen ihre Benutzer ausführen müssen, und überlegen, welche Schritte erforderlich sind, um nur diese Anwendungen zuzulassen. Das Feature der Softwareeinschränkungsrichtlinien wurde entworfen, um IT-Experten dabei zu helfen.

Sie geben einfach an, welche Anwendungen ausgeführt werden dürfen, und stellen dann die Richtlinie mithilfe der Gruppenrichtlinie bereit. Mit der Durchsetzung einer solchen Richtlinie im gesamten Unternehmen ist es möglich, die Gesamtkosten zu verringern, denn durch die Sperrung werden die Probleme in Verbindung mit nicht unterstützten Anwendungen begrenzt. (Für die Verwendung von Softwareeinschränkungsrichtlinien gibt es darüber hinaus einige interessante und extreme Möglichkeiten, die wir in der Randleiste „Die minimale Softwareeinschränkungsrichtlinie“ besprechen.)

Funktionsweise von Softwareeinschränkungsrichtlinien

Das Ziel der Softwareeinschränkungsrichtlinien besteht darin, genau zu kontrollieren, welchen Code ein Benutzer auf einem Windows Vista-Computer ausführen kann. Sie, der Administrator, erstellen eine Richtlinie, die definiert, was (oder was nicht) in Ihrer Umgebung ausgeführt werden darf. Diese Richtlinie wird immer dann herangezogen, wenn Code ausgeführt werden könnte. Dies gilt u. a. während der Prozesserstellung, bei einem Aufruf von ShellExecute und bei Ausführung eines Skripts. (Wir untersuchen dies sogleich ausführlicher.)

Wenn festgelegt wurde, dass eine Anwendung ausgeführt werden darf, wird die Anwendung gestartet. Wenn aber festgelegt wurde, dass eine Anwendung nicht ausgeführt werden darf, wird die Anwendung gesperrt, und der Benutzer wird benachrichtigt. Wenn Sie beispielsweise versucht haben, Solitär vom Startmenü aus auszuführen, und dies war nicht zulässig, wird ein Dialogfeld ähnlich dem in Abbildung 1 angezeigt.

Abbildung 1** Ein Dialogfeld wird angezeigt, wenn eine Anwendung gesperrt ist **(Zum Vergrößern auf das Bild klicken)

Die Benutzeroberfläche zum Definieren einer Softwareeinschränkungsrichtlinie ist im Gruppenrichtlinienobjekt-Editor verfügbar. Hier wird die Sperrungsrichtlinie erstellt. Es gibt verschiedene Methoden, mit denen sich definieren lässt, welcher Code ausgeführt werden darf und welcher nicht. Wenn die Richtlinie fertig gestellt ist und getestet wurde, können Sie sie bereitstellen.

Definieren der Softwareeinschränkungsrichtlinie

Die erste wichtige Entscheidung, die Sie treffen müssen, wirkt sich grundlegend darauf aus, wie die Softwareeinschränkungsrichtlinie in Ihrer Umgebung funktioniert: Sie müssen einen Standardregeltyp auswählen. Für die Bereitstellung von Softwareeinschränkungsrichtlinien stehen zwei Modi zur Verfügung: eine Zulassungsliste und eine Verweigerungsliste. Im Grunde legen Sie fest, ob Sie eine Richtlinie erstellen möchten, die jede in Ihrer Umgebung zugelassene Anwendung beschreibt, oder eine Richtlinie, die jede Anwendung definiert, die nicht ausgeführt werden darf.

Im Zulassungslistenmodus ist die Standardregel in Ihrer Richtlinie „Eingeschränkt“. Es werden alle Anwendungen gesperrt, deren Ausführung Sie nicht explizit zulassen. Im Verweigerungslistenmodus ist die Standardregel „Nicht eingeschränkt“. Es werden nur die Anwendungen eingeschränkt, die Sie explizit aufgelistet haben.

Sicher haben Sie erkannt, dass der Verweigerungslistenmodus eine unrealistische Option ist, wenn Sie an einer deutlichen Verringerung der Gesamtkosten sowie den Sicherheitsvorteilen interessiert sind, die sich aus der Sperrung von Anwendungen ergeben. Das Erstellen und Führen einer umfangreichen Liste zur Sperrung sämtlicher Malware und anderer problematischer Anwendungen wäre so gut wie unmöglich. Daher empfehlen wir die Implementierung der Softwareeinschränkungsrichtlinie im Zulassungslistenmodus, das heißt mit der Standardregel „Eingeschränkt“.

Erfassen von Anwendungen in Ihrer Umgebung

Bei der Entwicklung einer Richtlinie, mit der festgelegt wird, welche Anwendungen ausgeführt werden dürfen, müssen Sie genau bestimmen, welche Anwendungen die Benutzer benötigen. Das Feature der Softwareeinschränkungsrichtlinien bietet ein Feature zur erweiterten Protokollierung mit einer sehr einfachen Richtlinie, die es ermöglicht, genau zu verstehen, welche Anwendungen in Ihrer Umgebung ausgeführt werden.

Stellen Sie die Softwareeinschränkungsrichtlinie für eine Beispielgruppe von Computern in Ihrer Umgebung bereit, wobei Sie für den Standardregelsatz „Nicht eingeschränkt“ festlegen. Entfernen Sie alle anderen Regeln. Die Absicht besteht darin, die Softwareeinschränkungsrichtlinie zu aktivieren, ihr aber nicht zu erlauben, Anwendungen einzuschränken. Stattdessen verwenden Sie sie lediglich zur Überwachung der ausgeführten Anwendungen.

Erstellen Sie als Nächstes den folgenden Registrierungswert, um das Feature zur erweiterten Protokollierung zu aktivieren, und geben Sie für den Pfad das Verzeichnis an, in das die Protokolldatei geschrieben werden soll:

"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\
CodeIdentifiers"
String Value: LogFileName, <path to a log file>

Wenn jetzt eine Anwendung ausgeführt und die Softwareeinschränkungsrichtlinie ausgewertet wird (die Auswertung erfolgt trotz der Tatsache, dass die Richtlinie allen Anwendungen die Ausführung erlaubt), wird ein Eintrag in die Protokolldatei geschrieben.

Jeder Protokolleintrag enthält den Aufrufer der Softwareeinschränkungsrichtlinie und die Prozess-ID (PID) des aufrufenden Prozesses, das Ziel, das ausgewertet wird, den angetroffenen Regeltyp der Softwareeinschränkungsrichtlinie sowie eine Kennung für die Regel. Hier ein Beispieleintrag, der geschrieben wird, wenn ein Benutzer auf notepad.exe doppelklickt:

explorer.exe (PID = 3268) identified
C:\Windows\system32\notepad.exe as Unrestricted using
path rule, Guid =
{191cd7fa-f240-4a17-8986-94d480a6c8ca}

In dieser Protokolldatei werden sämtliche Abschnitte ausführbaren Codes dargestellt, die von dieser Softwareeinschränkungsrichtlinie überprüft werden, wenn die Richtlinie aktiviert und für die Sperrung von Anwendungen eingerichtet wurde. Das bedeutet, dass Sie für jeden Eintrag in der Protokolldatei entscheiden müssen, ob er in Ihrer Zulassungsliste berücksichtigt werden soll oder nicht. Beachten Sie, dass mehrere Binärdateien überprüft werden, die Teil von Windows® sind und vom System benötigt werden.

Mithilfe des hier beschriebenen Protokollierungsverfahrens können Sie genau beurteilen, auf welche Anwendungen die Softwareeinschränkungsrichtlinie in Ihrer Umgebung stoßen wird. Dies ist aber nicht die einzige Möglichkeit, diese Aufgabe zu auszuführen.

Mit dem Inventory Collector, Teil des Microsoft® Anwendungskompatibilitäts-Toolkit 5.0, können Sie alle Anwendungen erfassen, die in Ihrer Umgebung verwendet werden. Dieses Tool bietet Ihnen verschiedene Möglichkeiten zum Ermitteln der Anwendungen, die in Ihrer Umgebung installiert sind, und konsolidiert die Ergebnisse in einer zentralen Datenbank.

Erstellen zusätzlicher Regeln

Sie verfügen jetzt über eine Liste der Anwendungen, die in Ihrer Umgebung ausgeführt werden dürfen. Nun können Sie die eigentlichen Regeln erstellen, von denen diese Anwendungen die Berechtigung zur Ausführung erhalten. Das Feature der Softwareeinschränkungsrichtlinien verwendet zwei Methoden zur Bestimmung von Richtlinien: Eine basiert auf den kryptografischen Eigenschaften einer Anwendung (z. B. dem Hash), und mit der anderen wird ein vertrauenswürdiger Pfad oder Ordner definiert, in dem sich vertrauenswürdige Anwendungen befinden sollten.

Abbildung 2 zeigt, wo Sie Regeln hinzufügen würden, um die Ausführung der Anwendungen im Knoten „Richtlinien für Softwareeinschränkung“ des Gruppenrichtlinienobjekt-Editors (gpedit.msc) zu erlauben. Die einfachste Möglichkeit zur Definition von Anwendungen in Ihrer Umgebung besteht darin, eine Hashregel für jede Binärdatei zu erstellen, auf die Sie in der Protokollierungsphase gestoßen sind.

Abbildung 2** Verwenden von gpedit.msc zum Erstellen von Softwareeinschränkungsrichtlinien **(Zum Vergrößern auf das Bild klicken)

Da der Hash ein eindeutiger Wert ist, der für einen bestimmten Bitsatz zurückgegeben wird, verfügt jede Binärdatei in Ihrer Richtlinie über einen anderen Hash. Dieser Ansatz bietet besonders viel Sicherheit, da nur den spezifischen Binärdateien in Ihrer Richtlinie die Ausführung erlaubt wird.

Selbstverständlich hat dieser Ansatz auch einige Nachteile. So könnte Ihre Umgebung beispielsweise ohne weiteres mehrere tausend Binärdateien enthalten. Es dürfte schwierig sein, alle diese Regeln in der Benutzeroberfläche für Softwareeinschränkungsrichtlinien zu erstellen. Bei einer besonders großen Zahl von Regeln kann außerdem die Leistung beeinträchtigt sein. Zudem muss bei jeder Anwendungsaktualisierung in Ihrer Umgebung mindestens eine neue Hashregel in der Umgebung bereitgestellt werden. Das Aktualisieren einer solch umfangreichen Richtlinie bei der Aktualisierung von Anwendungen kann eine äußerst aufwändige Aufgabe sein.

Dies lässt sich glücklicherweise vermeiden, da es zwei andere Methoden gibt, Regeln zu bestimmen, die Ihnen die Verwendung von Softwareeinschränkungsrichtlinien in Ihrer Umgebung erleichtern. Wenn Sie die Möglichkeiten nutzen, die kryptografische Sicherheit bietet, können Sie eine Regel erstellen, die die Ausführung aller Binärdateien zulässt, die von einem bestimmten Zertifikat signiert wurden.

Dies erleichtert die Wartung der Richtlinienliste, da bei der Aktualisierung einer Anwendung die neuen Binärdateien für gewöhnlich von demselben Zertifikat signiert werden wie die vorhergehenden. Wenn Sie aber nicht möchten, dass eine frühere Version der Binärdatei in Ihrer Umgebung ausgeführt wird, müssen Sie eine Hashregel „Eingeschränkt“ hinzufügen, um zu verhindern, dass die Datei ausgeführt werden kann.

Standardmäßig ist die Auswertung von Zertifikatregeln für Softwareeinschränkungsrichtlinien deaktiviert. Dafür gibt es zwei Gründe.

Erstens werden die Zertifikatregeln in den Softwareeinschränkungsrichtlinien vom Inhalt des Systemspeichers für vertrauenswürdige Herausgeber definiert. Da der Speicher für vertrauenswürdige Herausgeber noch anderen Zwecken dient als der Speicherung von Regeln für Softwareeinschränkungsrichtlinien, müssen zusätzliche Überlegungen angestellt werden, wenn er für das Feature der Softwareeinschränkungsrichtlinien genutzt wird.

Zweitens müssen Sie, um die Gültigkeit der Signatur einer Datei zu bestimmen, einen Hash der Datei mit den Signaturinformationen vergleichen. Das Hashing einer Datei ist ein sehr aufwändiger Vorgang: Die gesamte Datei muss vom Datenträger gelesen und dann verarbeitet werden, um diesen Hash zu berechnen.

Um Zertifikatregeln zur aktivieren, navigieren Sie zum Knoten „Richtlinien für Softwareeinschränkung“, und wählen Sie im Ergebnisbereich die Option für das Erzwingungsobjekt aus. Doppelklicken Sie darauf, um das Eigenschaftsdialogfeld zu öffnen, und wählen Sie die Optionsschaltfläche „Zertifikatregeln erzwingen“ aus.

Die zweite gebräuchliche Methode zur Identifizierung von Code besteht darin, den Pfad des Codes auf dem lokalen Computer zu verwenden. Dies ist eine wirksame und effiziente Methode, die aber einen Nachteil hat: Sie müssen darauf achten, die korrekten Sicherheitseinstellungen für den Ordner festzulegen.

Wenn Sie eine bestimmte Pfadregel hinzufügen und dieser Pfad Benutzern das Schreiben von Dateien an dieser Position (z. B. auf dem Desktop) ermöglicht, wäre eine unbeschränkte Ausführung aller Anwendungen möglich. Die ausführbaren Dateien müssten lediglich in diesem Ordner abgelegt werden. Wenn sich die Benutzer aber nicht in der Administratorengruppe befinden, fehlt ihnen in der Regel die Möglichkeit, Änderungen in den Verzeichnissen „Programme“ oder „Windows“ vorzunehmen. Wenn sich alle Ihre Anwendungen im Verzeichnis „Programme“ befinden und Ihre Benutzer keine Administratoren sind, sollten Sie den Einsatz von Pfadregeln erwägen, um eine einfache und effiziente Richtlinie zu erstellen.

Dank einiger ihrer Features sind Pfadregeln für bestimmte Umgebungen besser geeignet. Sie ermöglichen die Verwendung von Platzhaltern und Umgebungsvariablen und erleichtern damit die Definition von Regeln, die in Ihrer Umgebung übertragbar sind. Schließlich ist es möglich, dass nicht für alle Benutzer c:\ als %systemdrive% fungiert.

Im Hinblick auf Leistung und Wartung ist dies wahrscheinlich diejenige Methode zur Identifizierung von Code, die am wenigsten Probleme bereitet. Pfadregeln sind ganz sicher eine Möglichkeit, Sie müssen sich aber der zusätzlichen Sicherheitsaspekte bewusst sein.

Netzwerkzonenregeln

Die Softwareeinschränkungsrichtlinie umfasst einen Regeltyp namens „Netzwerkzonenregel“, obwohl dieser Regeltyp als veraltet angesehen wird. Die ursprüngliche Idee hinter diesen Regeln war, dass die Quelle von bestimmtem ausführbarem Code identifiziert und als vertrauenswürdig eingestuft werden konnte. Folglich konnte dem Code die Ausführung gestattet werden. Leider ist dies besonders schwierig zu erreichen und funktionierte daher nie besonders gut. Derzeit wird dieser Regeltyp an den meisten Einstiegspunkten der Softwareeinschränkungsrichtlinie nicht erzwungen.

In Fällen, in denen die Mehrheit der Anwendungen im Verzeichnis „%Programme%“ installiert ist, es aber weitere ausführbare Dateien an anderen Installationsorten gibt, die von einem bestimmten Zertifikat signiert sind, könnte es sinnvoll sein, Regeln anderer Typen zu verwenden. Ein paar Hashregeln, einige Pfadregeln, und schon haben Sie die richtige Richtlinie für Ihre Anforderungen gefunden.

Beachten Sie aber, dass die Regeln in einer bestimmten Reihenfolge verarbeitet werden (siehe Abbildung 3). Zertifikatregeln sind am spezifischsten, an zweiter Stelle stehen Hashregeln, dann folgen Pfadregeln und schließlich Pfadregeln mit Platzhaltern. Wenn also ein Codeabschnitt von einer Hashregel und einer Pfadregel identifiziert wird, erhält die Sicherheitsstufe der Hashregel Priorität.

Abbildung 3** Reihenfolge der Regelverarbeitung **(Zum Vergrößern auf das Bild klicken)

Richtliniendurchsetzung

Das Feature der Softwareeinschränkungsrichtlinien lässt sich umfassend in dem zu sichernden System anwenden. Die Idee besteht darin, alle Speicherorte, an denen Code ausgeführt werden kann, in die Softwareeinschränkungsrichtlinie zu integrieren und dann wiederum die Richtlinie zu überprüfen, um zu sehen, ob dem ausführbaren Code die Ausführung ermöglicht wird.

Die Softwareeinschränkungsrichtlinie kann an zahlreichen Punkten überprüft werden, der einfachste Einstiegspunkt ist aber CreateProcess. Während CreateProcess wird die Richtlinie überprüft, um zu bestimmen, ob die Binärdatei, die die Anwendung repräsentiert, ausgeführt werden darf. Die Richtlinienüberprüfung wird von der API „SaferIdentifyLevel“ durchgeführt, die öffentlich dokumentiert ist. Der allgemeine Prozess ist in Abbildung 4 dargestellt. (Auf SaferIdentifyLevel kommen wir sogleich ausführlicher zurück.)

Abbildung 4** Verwenden von SaferIdentifyLevel, um zu bestimmen, ob eine Binärdatei ausgeführt werden darf **(Zum Vergrößern auf das Bild klicken)

Die nach CreateProcess gebräuchlichste API bei der Durchsetzung der Softwareeinschränkungsrichtlinie ist ShellExecute. Dies ist die API, die aufgerufen wird, wenn der Benutzer im Startmenü auf eine Anwendung klickt oder auf ein Element auf dem Desktop doppelklickt.

ShellExecute kann für eine Vielzahl von Dateiformaten aufgerufen werden. Handelt es sich z. B. um eine .txt-Datei, führt der Aufruf der Datei durch ShellExecute nicht dazu, dass die Datei tatsächlich ausgeführt wird. Genau genommen wird die Datei natürlich geöffnet. Aus diesem Grund enthält die Softwareeinschränkungsrichtlinie eine Liste der Typen ausführbarer Dateien, damit kontrolliert werden kann, welche Dateitypen beim Aufruf von ShellExecute überprüft werden. Sie können diese Liste der Typen ausführbarer Dateien in der Benutzeroberfläche für Softwareeinschränkungsrichtlinien anpassen.

Außer CreateProcess und ShellExecute gibt es zwei weitere wichtige Integrationspunkte: LoadLibrary und Skripthosts. LoadLibrary ist offensichtlich ein wichtiger Ort, um ausführbaren Code zu überprüfen, bringt aber leider einige besondere Einschränkungen mit sich.

Für die meisten Anwendungen gibt es eine ausführbare Datei und mehrere DLLs, die geladen werden. In der Regel werden zahlreiche Anwendungen auf dem System ausgeführt. Dies bedeutet, dass für LoadLibrary die Überprüfung der Richtlinie in beträchtlichem Umfang erforderlich wäre. In Abhängigkeit von Ihrer Richtlinie für die Identifizierung von Code könnte die Durchsetzung an diesem Einstiegspunkt sehr aufwändig sein: Stellen Sie sich vor, Sie müssten den Hash jeder im System geladenen DLL überprüfen, was das Hashing der Binärdatei und den anschließenden Vergleich mit einer Liste vielleicht Tausender von Hashes einschließt.

Diese Funktion ist standardmäßig deaktiviert, kann aber manuell aktiviert werden. Navigieren Sie hierzu in gpedit.msc zum Knoten „Richtlinien für Softwareeinschränkung“, und doppelklicken Sie auf „Erzwingen“. Klicken Sie danach auf die Optionsschaltfläche „Alle Softwaredateien“.

Wie bereits erwähnt, ist die Softwareeinschränkungsrichtlinie in die meisten Skripthosts im System integriert. Dazu gehören cmd, VBScript, Cscript und JScript®. Diese Einstiegspunkte verwenden wie die anderen die primäre API zur Durchsetzung der Softwareeinschränkungsrichtlinie: SaferIdentifyLevel.

Die API „SaferIdentifyLevel“ bestimmt, ob eine angegebene ausführbare Datei ausgeführt werden darf, indem sie die Identifizierungsinformationen in den relevanten Softwareeinschränkungsrichtlinien abruft. Dies ist eine öffentlich dokumentierte API. Skripthosts von Drittanbietern und ausführbare Umgebungen können und sollten die API zur Integration in die Softwareeinschränkungsrichtlinie verwenden, damit die Richtlinie bestimmen kann, ob ein Abschnitt ausführbaren Codes ausgeführt werden darf.

Ausführung als Standardbenutzer

Ein weniger bekanntes Feature der Softwareeinschränkungsrichtlinien ist ihre Fähigkeit, die Berechtigungen bestimmter Anwendungen beim Anwendungsstart zu filtern. Diese Funktion wurde in Windows XP eingeführt, aber erst ab Windows Vista in der Benutzeroberfläche für Softwareeinschränkungsrichtlinien verfügbar gemacht.

Somit war sie ein Vorläufer der Benutzerkontensteuerung in Windows Vista, denn Sie konnten mit ihrer Hilfe eine Anwendung als Standardbenutzer ausführen, auch wenn der Benutzer Mitglied der Administratorengruppe war. Dies geschieht, wenn Sie eine Regel erstellen und als Sicherheitsebene in der Benutzeroberfläche unter „Zusätzliche Regeln“ die Option „Normal User“ (Normaler Benutzer) festlegen.

Sowohl die Funktion der Tokenfilterung der Benutzerkontensteuerung als auch die „Normal User“-Regeln der Softwareeinschränkungsrichtlinien nutzen eine zugrunde liegende API, die dasselbe Verhalten implementiert wie die API „CreateRestrictedToken“. Insgesamt gibt es aber bedeutende architektonische Unterschiede zwischen den Technologien. Die Benutzerkontensteuerung weicht in einigen wesentlichen Punkten von der Softwareeinschränkungsrichtlinie ab.

Erstens wird bei Aktivierung der Benutzerkontensteuerung in Windows Vista standardmäßig jede Anwendung mit einem Sicherheitstoken gestartet, das einem Mitglied der Benutzergruppe ähnelt. Dies gilt auch dann, wenn der Benutzer ein Administrator ist. Dies kann mit der Softwareeinschränkungsrichtlinie erreicht werden, aber es gibt keine Möglichkeit, eine Anwendung mit dem eigentlichen Administratortoken des Benutzers zu starten (z. B. wenn der Benutzer eine Anwendung installieren muss). Die wichtigsten Vorteile der Benutzerkontensteuerung sind die Änderung des Standardsicherheitskontexts und der einfache Zugriff auf das vollständige Administratortoken eines Benutzers.

Der zweite Unterschied besteht darin, dass der Code im Fall ausführbarer Dateien selbst ausdrückt, welche Berechtigungsstufe erforderlich ist, damit er funktionieren kann. Dies ist ein wichtiger Unterschied, weil unabhängige Softwarehersteller und Entwickler die Anforderungen ihres Codes verstehen. Wenn beispielsweise eine Systemsteuerungsanwendung ein Element bearbeiten muss, das Administratorberechtigungen erfordert, kann diese Anforderung in ihrer Manifestdatei festgelegt werden. Folglich kann der unabhängige Softwarehersteller die Berechtigungen beschreiben, die eine Anwendung benötigt, statt ihr eine bestimmte Berechtigungsstufe aufzuerlegen, ohne dass die Möglichkeit besteht, diese Stufe zu ändern.

Sofern Ihnen nicht hundertprozentig klar ist, wie die Regeln für normale Benutzer funktionieren, sollten Sie ihren Einsatz vorläufig vermeiden. Die Benutzerkontensteuerung ist eine hervorragende Möglichkeit, um die Desktopbenutzer aus der Administratorengruppe zu entfernen, und Sie sollten sie einfach in Ihrer Unternehmensumgebung belassen.

Heutige Verwendung der Softwareeinschränkungsrichtlinien

Beim Einsatz der Softwareeinschränkungsrichtlinie müssen Sie zusätzliche Aspekte berücksichtigen. Es ist aber einfacher, als Sie vielleicht denken. Möglicherweise verwenden Sie sogar schon Softwareeinschränkungsrichtlinien, ohne es zu wissen. Wenn Sie beispielsweise mit Jugendschutzeinstellungen auf einem Windows Vista-System arbeiten, verwenden Sie Softwareeinschränkungsrichtlinien, um die Ausführung der Anwendungen zu kontrollieren.

Bei ihrer Ersteinführung in Windows XP war die Softwareeinschränkungsrichtlinie eine wichtige technologische Entwicklung. Die Sperrung von Anwendungen rückt aber erst in letzter Zeit verstärkt in das Blickfeld von IT-Experten.

Das Feature der Softwareeinschränkungsrichtlinien in Windows Vista bedarf sicher noch der Optimierung. Schon heute ist aber klar, dass Administratoren diese verstärkte Kontrolle über die in ihrer Umgebung ausgeführten Anwendungen wünschen. Erfreulicherweise wird sich die Technologie weiterentwickeln und es IT-Experten erleichtern, ihre Systeme zu verwalten und die Kosten zu senken, die mit einer Microsoft Windows-Umgebung verbunden sind.

Die minimale Softwareeinschränkungsrichtlinie

Die Softwareeinschränkungsrichtlinie kann u. a. zum Erstellen einer Richtlinie genutzt werden, mit der Windows in einen Kioskmodus versetzt wird. Microsoft stellt sogar ein Toolkit namens SteadyState™ zum Erstellen dieses Kiosks her. Wenn Sie allerdings nur die Anwendungen sperren möchten, die ausgeführt werden können, gibt es eine einfachere Lösung.

Um dem Mindestsatz erforderlicher Anwendungen die Anmeldung bei Windows Vista zu ermöglichen, erstellen Sie eine Richtlinie, die logonui.exe und userinit.exe die Ausführung unter %windir%\system32 ermöglicht. Für die meisten Benutzer muss wahrscheinlich auch die Ausführung der folgenden Anwendungen erlaubt sein:

dllhost.exe, rundll32.exe, control.exe (also under %windir%\system32)....

Wenn Sie die standardmäßige Windows-Shell wünschen, müssten Sie auch %windir%\explorer.exe hinzufügen.

Eine Alternative wäre es, direkt in eine Anwendung hinein zu starten, z. B. Internet Explorer®. In diesem Fall müssten Sie iexplore.exe statt explorer.exe auflisten.

Ein weiterer Aspekt dieser minimalen Richtlinie besteht darin, dass Ihre Benutzer sich nicht in der Administratorengruppe befinden dürfen. Dies ist wichtig, damit sie die Richtlinie nicht umgehen können. Da sie aber nur eine sehr beschränkte Gruppe von Anwendungen ausführen können und nicht über die Berechtigungen eines Administrators verfügen, fehlen den Benutzern die Berechtigungen zum Installieren von Anwendungen oder zur Wartung des Systems.

Sie müssen eine Möglichkeit einrichten, dies für die betreffenden Computer auszuführen. Wenn Sie vorhaben, diese Computer zu aktualisieren und zu warten, indem Sie sich lokal mit einem Administratorkonto anmelden, sollten Sie die Optionsschaltfläche auswählen, mit der die Softwareeinschränkungsrichtlinie auf alle Benutzer mit Ausnahme lokaler Administratoren angewendet wird. Die Richtlinie sollte außerdem consent.exe und cmd.exe einschließen. Dies ermöglicht es dem Administrator, beliebige Verwaltungsoptionen über eine Administrator-cmd-Eingabeaufforderung zu starten.

Beachten Sie, dass die Benutzerkontensteuerung die Berechtigungen des Sicherheitstokens des Benutzers standardmäßig beschränkt, damit der Anschein erweckt wird, das Token sei kein Mitglied der Administratorengruppe. Selbst wenn Sie die obige Einstellung so festlegen, dass sie die Richtlinie nicht auf Administratoren anwendet, wird die Richtlinie trotzdem auf die Benutzer angewendet. Nur wenn Sie die Berechtigungen der Benutzerkontensteuerung erweitern, erhält der Administrator tatsächlich die vollständigen Administratorrechte, und die Softwareeinschränkungsrichtlinie wird nicht angewendet.

Chris Corio Chris Corio gehörte mehr als fünf Jahre lang dem Windows Security-Team bei Microsoft an. Sein Arbeitsschwerpunkt bei Microsoft waren Anwendungssicherheitstechnologien und Verwaltungstechnologien zur Sicherung von Windows. Sie erreichen Chris Corio unter winsecurity@chriscorio.com.

Durga Prasad Sayana Durga Prasad Sayana ist als Software Design Engineer/Test im Windows Core Security-Team tätig. Seine Hauptinteressen liegen in den Bereichen Sicherheitstechnologien und Softwareprüfung. Sie erreichen Durga Prasad Sayana unter durgas@microsoft.com.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.