Sicherheitsüberlegungen für AppLocker
In diesem Thema für IT-Experten werden die Sicherheitsaspekte beschrieben, die bei der AppLocker-Implementierung zu beachten sind.
Der Zweck von AppLocker besteht darin, den Zugriff auf die Software – und damit auf die über die Software zugänglichen Daten – auf eine bestimmte Benutzer- oder Unternehmensgruppe zu beschränken. AppLocker unterliegt den folgenden Sicherheitsaspekten:
AppLocker wird in Unternehmen eingesetzt und von IT-Mitarbeitern mit vertrauenswürdigen Anmeldeinformationen zentral verwaltet. Dadurch wird sichergestellt, dass bei der Erstellung und Bereitstellung von Richtlinien ähnliche Bereitstellungsprozesse und Sicherheitseinschränkungen eingehalten werden.
AppLocker-Richtlinien werden über eine Gruppenrichtlinie und unter Einsatz bewährter Prozesse und Verfahren innerhalb der Domäne verteilt. Alternativ können AppLocker-Richtlinien für einzelne Computer festgelegt werden, sofern der Benutzer über Administratorrechte verfügt – auch wenn diese Richtlinien nicht mit der schriftlichen Sicherheitsrichtlinie der Organisation konform sind. Die Einstellungen zur Erzwingung lokaler Richtlinien werden durch die gleichen, in einem Gruppenrichtlinienobjekt (Group Policy Object, GPO) enthaltenen AppLocker-Richtlinien überschrieben. Da die AppLocker-Regeln additiv sind, wird eine lokale Richtlinie, die nicht in einem GPO enthalten ist, trotzdem für den betreffenden Computer ausgewertet.
Microsoft bietet keine Möglichkeit zur Entwicklung von AppLocker-Erweiterungen. Die Schnittstellen sind nicht öffentlich. Ein Benutzer mit Administratoranmeldeinformationen kann einige AppLocker-Prozesse mithilfe von Windows PowerShell-Cmdlets automatisieren. Informationen zu den Windows PowerShell-Cmdlets für AppLocker finden Sie unter AppLocker-Cmdlets in Windows PowerShell.
AppLocker wird im Administrator- oder LocalSystem-Kontext ausgeführt, der über die höchsten Rechte verfügt. Dieser Sicherheitskontext ist ein potenzielles Ziel für Datenmissbrauch. Wenn ein Benutzer mit Administratoranmeldeinformationen eine AppLocker-Richtlinie auf einem lokalen Gerät ändert, das einer Domäne angehört, können diese Änderungen vom GPO, das die AppLocker-Regel für dieselbe auf dem lokalen Gerät geänderte Datei (bzw. den geänderten Pfad) enthält, überschrieben oder abgelehnt werden. Da die AppLocker-Regeln additiv sind, wird eine lokale Richtlinie, die nicht in einem GPO enthalten ist, trotzdem für den betreffenden Computer ausgewertet. Wenn der lokale Computer keiner Domäne angehört und nicht von einer Gruppenrichtlinie verwaltet wird, kann ein Benutzer mit Administratoranmeldeinformationen die AppLocker-Richtlinie ändern.
Wenn Dateien in einem Verzeichnis mit einer Regel vom Typ „Pfadbedingung“ (über die Aktion „Zulassen“ oder „Verweigern“) geschützt werden, ist es trotzdem notwendig und sinnvoll, den Zugriff auf diese Dateien über Zugriffssteuerungslisten (Access Control Lists, ACLs) gemäß der geltenden Sicherheitsrichtlinie einzuschränken.
AppLocker bietet keinen Schutz vor der Ausführung von 16-Bit-DOS-Binärdateien in der Virtual DOS Machine (NTVDM). Diese Technologie ermöglicht die Ausführung älterer DOS- und 16-Bit-Windows-Programme auf Computern, die Intel 80386 oder höher verwenden, wenn die Hardware bereits durch ein anderes Betriebssystem ausgeführt und gesteuert wird. Dies führt dazu, dass 16-Bit-Binärdateien unter Windows Server 2008 R2 und Windows 7 ausgeführt werden können, auch wenn die AppLocker-Konfiguration Binärdateien und Bibliotheken blockiert. Falls die Ausführung von 16-Bit-Anwendungen verhindert werden muss, müssen Sie die Verweigerungsregel in der Regelsammlung für ausführbare Dateien für „NTVDM.exe“ konfigurieren.
Sie können AppLocker (oder Richtlinien für die Softwareeinschränkung) nicht dazu verwenden, die Codeausführung außerhalb des Win32-Subsystems zu verhindern. Dies gilt insbesondere für das POSIX-Subsystem in Windows NT. Falls es erforderlich ist, die Ausführung von Anwendungen im POSIX-Subsystem zu verhindern, müssen Sie das Subsystem deaktivieren.
AppLocker kann nur VBScript, JScript, BAT-Dateien, CMD-Dateien und Windows PowerShell-Skripts steuern. Er ist nicht in der Lage, den gesamten, innerhalb eines Hostprozesses ausgeführten interpretierten Code (z. B. Perl-Skripts und -Makros) zu steuern. Interpretierter Code ist eine Form ausführbaren Codes, der innerhalb eines Hostprozesses ausgeführt wird. Windows-Batchdateien („*.bat“) werden beispielsweise im Kontext des Windows-Befehlshosts („cmd.exe“) ausgeführt. Wenn der interpretierte Code mithilfe von AppLocker gesteuert werden soll, muss der Hostprozess AppLocker vor der Ausführung des interpretierten Codes aufrufen und dann die von AppLocker zurückgegebene Entscheidung erzwingen. Nicht alle Hostprozesse führen einen Aufruf in AppLocker aus, sodass AppLocker nicht jede Art von interpretiertem Code (z. B. Microsoft Office-Makros) steuern kann.
Wichtig
Es empfiehlt sich, geeignete Sicherheitseinstellungen für diese Hostprozesse zu konfigurieren, wenn Sie die Ausführung zulassen müssen. Stellen Sie durch die Konfiguration der Sicherheitseinstellungen in Microsoft Office z. B. sicher, dass nur signierte und vertrauenswürdige Makros geladen werden.
Durch AppLocker-Regeln wird der Start einer Anwendung entweder zugelassen oder verhindert. Das Verhalten der Anwendungen nach dem Start wird von AppLocker nicht gesteuert. Anwendungen können an Funktionen übergebene Kennzeichen enthalten, die AppLocker die Umgehung der Regeln signalisieren und das Laden einer anderen EXE- oder DLL-Datei zulassen. In der Praxis könnte eine von AppLocker zugelassene Anwendung diese Kennzeichen verwenden, um AppLocker-Regeln zu umgehen und untergeordnete Prozesse zu starten. Jede Anwendung muss eingehend geprüft werden, bevor Sie die Ausführung über AppLocker-Regeln zulassen.
Hinweis
Zwei Kennzeichen, die diese Bedingung verdeutlichen, sind SANDBOX_INERT, das an CreateRestrictedToken übergeben werden kann, und LOAD_IGNORE_CODE_AUTHZ_LEVEL, das an LoadLibraryEx übergeben werden kann. Beide Kennzeichen signalisieren AppLocker, die Regeln zu umgehen und das Laden einer untergeordneten EXE- oder DLL-Datei zuzulassen.