PowerShell & Scripting

Execution Policy (Ausführungsrichtlinie)

Overview

Die Execution Policy steuert, ob PowerShell Skripte und Konfigurationsdateien ausführt. Microsoft beschreibt sie ausdrücklich nicht als Sicherheitsgrenze, sondern als zusätzliche Schutzschicht: Wer Skriptinhalte direkt in die Konsole kopiert, umgeht sie. Sie schützt also vor versehentlicher Ausführung, nicht vor Angreifern.

Werte: Restricted (nur einzelne Befehle, keine Skripte), AllSigned (alle Skripte signiert), RemoteSigned (heruntergeladene Skripte müssen signiert sein), Unrestricted, Bypass (keine Prüfung, keine Warnung) und Undefined. Ist in keinem Bereich etwas gesetzt, gilt auf Windows-Clients Restricted und auf Windows Server RemoteSigned.

Die Prüfung findet nur unter Windows statt. Unter Linux und macOS steht die Richtlinie fest auf Unrestricted und verhält sich wie Bypass.

How it works

Die effektive Richtlinie ergibt sich aus mehreren Bereichen, in absteigender Priorität:

  1. MachinePolicy und UserPolicy: per Gruppenrichtlinie „Turn on Script Execution“ (Skriptausführung aktivieren) gesetzt. Sie überschreiben alle anderen Bereiche und lassen sich in PowerShell nicht ändern.
  2. Process: gilt nur für die laufende Sitzung, gespeichert in $Env:PSExecutionPolicyPreference.
  3. CurrentUser: gilt für den aktuellen Benutzer.
  4. LocalMachine: gilt für alle Benutzer des Computers.

Get-ExecutionPolicy -List zeigt alle Bereiche, Set-ExecutionPolicy -Scope ändert einen davon. Ein Befehl kann erfolgreich sein und trotzdem nichts bewirken, wenn ein höherer Bereich etwas anderes vorgibt.

RemoteSigned erkennt heruntergeladene Dateien an einem alternativen Datenstrom, den Browser wie Microsoft Edge setzen. Unblock-File entfernt diese Markierung. Downloads per curl.exe, Invoke-WebRequest oder Invoke-RestMethod werden nicht unbedingt markiert.

Benefits

  • Schutz vor versehentlicher Ausführung: Ein per Mail oder Browser geladenes Skript startet nicht durch einen Doppelklick oder Tippfehler
  • Zentrale Steuerung: Per GPO oder Intune setzt Du eine einheitliche Vorgabe für alle Clients und Server
  • Kombinierbar mit Signaturen: AllSigned erzwingt zusammen mit Code Signing, dass nur freigegebene Skripte laufen
  • Flexibel pro Sitzung: Der Bereich Process erlaubt Ausnahmen für eine Sitzung, ohne die Systemeinstellung zu ändern

Practical example

Ein Steuerberatungsbüro mit 60 Mitarbeitenden setzt per Gruppenrichtlinie RemoteSigned auf allen Clients und AllSigned auf den Servern. Mitarbeitende können so keine aus dem Internet geladenen Skripte versehentlich starten. Für echten Schutz vor Schadcode ergänzt die IT Windows Defender Application Control bzw. App Control for Business und Script Block Logging. Die Admins signieren ihre Serverskripte mit einem Zertifikat der internen CA.

Things to keep in mind

  • Execution Policy nicht als Malware-Schutz verstehen: Angreifer umgehen sie z. B. mit -ExecutionPolicy Bypass, für echte Kontrolle App Control for Business und Constrained Language Mode einsetzen
  • Die Richtlinie per GPO setzen, statt sie lokal zu pflegen, weil GPO-Werte Vorrang haben
  • In Automatisierungen nicht pauschal Bypass verwenden, sondern Skripte signieren oder gezielt Unblock-File nutzen
  • Bei rätselhaften Blockaden Get-ExecutionPolicy -List prüfen, oft greift ein höherer Bereich

Conclusion

Die Execution Policy ist ein Sicherheitsgurt gegen Versehen, keine Firewall gegen Angreifer. RemoteSigned auf Clients und AllSigned mit Signaturen auf Servern sind ein sinnvoller Standard.

Further reading

Related articles