PowerShell-Ausführungsrichtlinien und Skriptsignatur — Ein praktischer Leitfaden zum Abschied vom „Zudecken mit Bypass“

„Auf einem neuen PC läuft ein Skript nicht und sagt nur ‚Das Ausführen von Skripts wurde auf diesem System deaktiviert…‘“ „Das Hinzufügen von -ExecutionPolicy Bypass hat es zum Laufen gebracht, also steht das jetzt in jeder einzelnen Aufgabe“ „Eine .ps1-Datei in einem gemeinsamen Ordner wirft einen Signaturfehler, aber nur auf dem Rechner einer Person“ — Die Ausführungsrichtlinie von PowerShell ist eine Mauer, gegen die Sie fast garantiert stoßen, sobald Sie beginnen, interne Abläufe zu automatisieren. Und bei vielen Organisationen türmt sich die Lösung, die sich immer weiter anhäuft, ohne dass irgendjemand den Mechanismus wirklich versteht, zu „mit Bypass zudecken“ auf.

Was das knifflig macht, ist, dass leicht missverstanden wird, was die Ausführungsrichtlinie eigentlich schützt. Behandeln Sie sie als Sicherheitsfunktion und schränken Sie zu stark ein, kommt die Arbeit zum Erliegen. Oder gehen Sie den anderen Weg — entscheiden Sie „es ist ohnehin sinnlos“ und setzen alles auf Bypass, wodurch Sie die letzte Sicherheitsfunktion entfernen, die versehentliche Fehler verhindert. Beide Fehler lassen sich vermeiden, sobald Sie den Mechanismus verstehen.

Dieser Artikel richtet sich an IT-Verantwortliche kleiner und mittlerer Unternehmen sowie an alle, die PowerShell zur Automatisierung routinemäßiger interner Arbeit nutzen. Er legt, gestützt auf die offizielle Dokumentation, dar, was die Ausführungsrichtlinie tatsächlich ist, wie die Rangfolge der Geltungsbereiche funktioniert, ihre Beziehung zu Zone.Identifier (dem sogenannten Mark of the Web) sowie wie man einen Verteilungsbetrieb aufbaut, der auf Skriptsignatur beruht.

1. Das Wichtigste zuerst

• Die Ausführungsrichtlinie ist eine Sicherheitsfunktion, keine Sicherheitsgrenze. Die offizielle Dokumentation stellt unmissverständlich fest, dass „die Ausführungsrichtlinie kein Sicherheitssystem ist, das Benutzeraktionen einschränkt“, und dass sie sich „trivial umgehen lässt, indem man den Inhalt eines Skripts in die Befehlszeile eintippt“. Ihr Zweck ist, Grundregeln festzulegen und unbeabsichtigte Ausführung — versehentliche Fehler — zu verhindern.¹
• Die Ausführungsrichtlinie betrifft nur die Ausführung von Skripten — interaktive Befehle können Sie immer ausführen. Windows PowerShell 5.1 setzt standardmäßig auf Restricted (keine Skriptausführung) unter Client-Betriebssystemen und auf RemoteSigned unter Windows Server. PowerShell 7 setzt standardmäßig auf RemoteSigned.²¹
• Die Richtlinie besitzt fünf Geltungsbereiche, mit der Rangfolge MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. MachinePolicy und UserPolicy sind ausschließlich über Gruppenrichtlinien einstellbar; Sie können sie nicht mit Set-ExecutionPolicy ändern, und auch keine Befehlszeilenangabe kann sie überschreiben.¹³
• RemoteSigned verlangt eine Signatur nur für Skripte, die „aus dem Internet“ stammen. Diese Herkunft wird durch den alternativen Datenstrom Zone.Identifier bestimmt, der an die Datei angehängt wird (das Mark of the Web); haben Sie den Inhalt geprüft, erlaubt das Entfernen mit Unblock-File die Ausführung des Skripts, ohne je die Richtlinie zu ändern.¹⁴
• AllSigned verlangt eine Signatur eines vertrauenswürdigen Herausgebers für jedes Skript, einschließlich lokal erstellter. Sie bringen die Signatur mit Set-AuthenticodeSignature an, was sie als # SIG #-Kommentarblock am Ende der Datei einbettet.¹⁵
• Bringen Sie einer Signatur immer einen Zeitstempel (-TimestampServer) an. Mit einem Zeitstempel funktioniert das Skript auch nach Ablauf des Signaturzertifikats weiter. Da die meisten Codesignaturzertifikate ein Jahr gültig sind, verwandelt sich das Weglassen dieses Schritts in eine jährlich hochgehende Zeitbombe.⁶⁵
• Ein selbstsigniertes Zertifikat dient nur zum Testen. Ein mit einem selbstsignierten Zertifikat signiertes Skript läuft auf keinem anderen Computer. Nutzen Sie für die organisatorische Verteilung ein Codesignaturzertifikat, das von einer Zertifizierungsstelle ausgestellt wurde (eine interne CA oder eine kommerzielle CA).⁵⁷
• Möchten Sie organisationsweite Kontrolle, verwalten Sie diese zentral über die Gruppenrichtlinieneinstellung „Skriptausführung aktivieren“. Diese Einstellung hat Vorrang vor jeder Geltungsbereich-Einstellung auf der PowerShell-Seite.¹

2. Was die Ausführungsrichtlinie tatsächlich ist — eine „Sicherheitsfunktion“, keine „Sicherheitsgrenze“

Klären wir zunächst die Prämisse. Die offizielle Dokumentation (about_Execution_Policies) ist unverblümt in dieser Hinsicht. Die Ausführungsrichtlinie ist eine „Sicherheitsfunktion“, die die Bedingungen steuert, unter denen PowerShell Konfigurationsdateien lädt und Skripte ausführt — sie ist „kein Sicherheitssystem, das Benutzeraktionen einschränkt“. Das liegt daran, dass selbst ein Benutzer, der kein Skript ausführen kann, dieselbe Verarbeitung erledigen kann, indem er den Inhalt des Skripts in die Befehlszeile einfügt. Es wird ausdrücklich festgehalten, dass die Rolle der Ausführungsrichtlinie darin besteht, Grundregeln festzulegen und ihre unbeabsichtigte Verletzung zu verhindern.¹ Auch die Einstiegsdokumentation wiederholt denselben Punkt: „sie ist keine Sicherheitsgrenze; sie kann einen Benutzer, der absichtlich ein Skript ausführen möchte, nicht aufhalten.“²

Sobald Sie diese Einordnung verinnerlicht haben, fügt sich Ihre betriebliche Designstrategie zusammen. Sowohl „das Verschärfen der Ausführungsrichtlinie verhindert Angriffe“ als auch „es ist ohnehin sinnlos, da es umgangen werden kann“ sind falsch. Das Abwehren von Angriffen ist Aufgabe einer anderen Schicht (Anwendungssteuerung, minimale Rechtevergabe, Audit-Protokollierung); die Aufgabe der Ausführungsrichtlinie ist es, Unfälle zu verhindern.⁸

Hier eine Zusammenfassung der Unterschiede zwischen den wichtigsten Richtlinien.¹

Es wird leicht übersehen, aber Restricted stoppt mehr als nur Ihre eigenen Geschäftsskripte — es blockiert auch das Laden von Profilen (.ps1), Modulen (.psm1) und Formatierungskonfigurationsdateien (.ps1xml).¹ Dass „das Profil auf dem neuen Rechner nicht geladen wird“ letztlich an der Ausführungsrichtlinie liegt, ist ein klassisches, immer wiederkehrendes Beratungsthema.

3. Geltungsbereiche und Rangfolge — Was wirklich hinter „Ich habe es geändert, aber nichts hat sich geändert“ steckt

Die Ausführungsrichtlinie ist kein einzelner Wert — sie kann unabhängig für fünf verschiedene Geltungsbereiche festgelegt werden, und der mit der höchsten Priorität wird zum effektiven Wert.¹

Der Standardweg, um „ich habe es geändert, aber nichts hat sich geändert“ zu diagnostizieren, besteht darin, sich die vollständige Liste anzusehen, nicht nur den effektiven Wert.

# Immer prüfen, welcher Geltungsbereich tatsächlich wirkt, nicht nur die effektive Richtlinie
Get-ExecutionPolicy -List

# Beispiel: Selbst wenn LocalMachine auf AllSigned steht, gewinnt CurrentUsers RemoteSigned
#         Scope ExecutionPolicy
#         ----- ---------------
# MachinePolicy       Undefined
#    UserPolicy       Undefined
#       Process       Undefined
#   CurrentUser    RemoteSigned
#  LocalMachine       AllSigned

# Um nur Ihre eigene Umgebung zu ändern, ist der CurrentUser-Bereich praktisch, da er keine Administratorrechte benötigt
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Da CurrentUser Vorrang vor LocalMachine hat, ist die effektive Richtlinie im obigen Beispiel RemoteSigned.¹ Set-ExecutionPolicy schreibt standardmäßig in den LocalMachine-Bereich, was Administratorrechte erfordert, aber im CurrentUser-Bereich kann sie auch ein gewöhnlicher Benutzer ändern.³

Und das eigentliche Werkzeug für die organisatorische Verwaltung ist die Gruppenrichtlinie. Die Richtlinie „Skriptausführung aktivieren“ (Turn on Script Execution) hat Vorrang vor jedem auf der PowerShell-Seite festgelegten Geltungsbereich. Deaktivieren entspricht Restricted; Aktivieren lässt Sie zwischen „Alle Skripts zulassen“ (Unrestricted), „Lokale Skripts und remote signierte Skripts zulassen“ (RemoteSigned) und „Nur signierte Skripts zulassen“ (AllSigned) wählen, und sie befindet sich unter der Verwaltungsvorlage Windows-Komponenten\Windows PowerShell. Die Computerkonfiguration hat Vorrang vor der Benutzerkonfiguration.¹ In einer über GPO verwalteten Umgebung speichert Set-ExecutionPolicy die Einstellung zwar, aber sie wird nicht tatsächlich wirksam, und es wird eine Meldung angezeigt, die den Konflikt erklärt.³

Es gibt hier eine wichtige Konsequenz. Verwaltet GPO die Richtlinie, hat ein in eine Aufgabe oder Verknüpfung geschriebenes -ExecutionPolicy Bypass keine Wirkung. Es ist ausdrücklich dokumentiert, dass eine Process-Bereich-Angabe die LocalMachine-/CurrentUser-Konfiguration schlägt, aber Gruppenrichtlinien nicht schlagen kann.¹ Umgekehrt formuliert: „Einfach Bypass hinschreiben, dann klappt es schon“ gilt nur in Umgebungen, in denen die Organisation die Ausführungsrichtlinie überhaupt nicht verwaltet.

4. Zone.Identifier (Mark of the Web) und Unblock-File

RemoteSigneds Vorstellung von „remote (aus dem Internet)“ wird nicht danach beurteilt, wo die Datei liegt, sondern nach einer Markierung auf der Datei. Programme wie Browser hängen an eine heruntergeladene Datei einen alternativen Datenstrom, der sie als „eine Datei, die aus dem Internet stammt“ markiert.¹ Dieser Stream ist Zone.Identifier und trägt den Wert 3, der die Internetzone anzeigt. Das ist das sogenannte Mark of the Web.⁴

Versuchen Sie, ein unsigniertes Skript mit diesem Zeichen in einer RemoteSigned-Umgebung auszuführen, wird es mit einem „nicht digital signiert“-Fehler blockiert. Die Lösung besteht aus zwei Schritten.

# 1) Zunächst prüfen, welche Dateien blockiert sind (ein sicherer, nur lesender Vorgang)
Get-Item -Path C:\Tools\*.ps1 -Stream Zone.Identifier -ErrorAction SilentlyContinue

# 2) Nur die entsperren, die Sie geprüft und als sicher eingestuft haben
#    (Unblock-File entfernt den Zone.Identifier-Stream; die Ausführungsrichtlinie selbst ändert sich nicht)
Unblock-File -Path C:\Tools\Get-InventoryReport.ps1

Unblock-File ist das Cmdlet, das den alternativen Datenstrom Zone.Identifier entfernt, und es ist derselbe Vorgang wie das Kontrollkästchen „Zulassen“ in den Eigenschaften der Datei im Explorer. Der entscheidende Punkt ist, dass Sie nur geprüfte Dateien durchlassen können, ohne die Ausführungsrichtlinie überhaupt zu lockern.⁴ Auch die offizielle Dokumentation behandelt „die Datei und ihre Herkunft vor der Nutzung zu prüfen und zu verifizieren, dass sie sicher ist“ als verbindlichen Schritt.⁴³

Es lohnt sich, auch die Falle in die entgegengesetzte Richtung zu kennen. Nicht jeder Bezugsweg hängt das Mark of the Web an. Es ist ausdrücklich dokumentiert, dass Dateien, die mit curl.exe, Invoke-WebRequest oder Invoke-RestMethod heruntergeladen wurden, möglicherweise nicht mit der Internetzonen-Markierung versehen werden.¹ Mit anderen Worten: RemoteSigned ist keine Garantie, dass „jede gefährliche heruntergeladene Datei gestoppt wird“ — genau deshalb ist es eine Sicherheitsfunktion statt einer Sicherheitsgrenze. Es gibt auch einen Hinweis, dass auf Systemen, die so konfiguriert sind, dass sie nicht zwischen UNC-Pfaden und Internetpfaden unterscheiden, ein Skript auf einer Freigabe unter RemoteSigned möglicherweise abgelehnt wird.¹ Wenn „.ps1-Dateien auf einer Freigabe nur auf manchen Rechnern nicht funktionieren“, verdächtigen Sie die Zonenkonfiguration und ob Zone.Identifier vorhanden ist.

Übrigens behandeln wir den SmartScreen-Mechanismus, der auf der Seite ausführbarer Dateien (.exe) ein ähnliches Symptom verursacht, in Warum Windows „Windows hat Ihren PC geschützt“ anzeigt.

5. Die Praxis der Skriptsignatur — Set-AuthenticodeSignature und Zeitstempel

Der Wechsel zu einem AllSigned-Betrieb oder zum Signieren verteilter Dateien innerhalb einer RemoteSigned-Umgebung erfordert ein Codesignaturzertifikat. Es gibt drei Wege, eines zu erhalten.⁵

Die offizielle Dokumentation legt es genauso dar: „einem von einer Zertifizierungsstelle ausgestellten Zertifikat wird auch auf anderen Computern vertraut“, während „ein selbst erstelltes Zertifikat kostenlos, aber spezifisch für den eigenen Computer ist und auf Testzwecke beschränkt bleiben sollte“.⁵ Ist internes Verteilen Ihr Ziel, ist es realistisch, ein Codesignaturzertifikat von einer internen CA wie Active Directory-Zertifikatdiensten auszustellen.

Bestätigen wir zunächst den Ablauf mit einem selbstsignierten Testzertifikat.

# Ein Test-Codesignaturzertifikat erstellen (selbstsigniert — nur auf diesem Rechner vertrauenswürdig)
$params = @{
    Subject           = 'CN=KomuraSoft Code Signing (Test)'
    Type              = 'CodeSigningCert'
    CertStoreLocation = 'Cert:\CurrentUser\My'
    HashAlgorithm     = 'sha256'
}
$cert = New-SelfSignedCertificate @params

New-SelfSignedCertificate ist das Cmdlet, das ein selbstsigniertes Zertifikat zu Testzwecken erstellt; die Angabe von -Type CodeSigningCert fügt die Codesignatur-Erweiterung hinzu. Die Standardgültigkeitsdauer beträgt ein Jahr.⁷ Möchten Sie ein selbstsigniertes Zertifikat verwenden, um eine AllSigned-Umgebung zu testen, muss es im Speicher der vertrauenswürdigen Stammzertifizierungsstellen dieses Rechners registriert werden.⁵

Das eigentliche Signieren, im Produktivbetrieb, ist diese eine Zeile.

# Das Codesignaturzertifikat aus dem Zertifikatspeicher abrufen und damit signieren
# -CodeSigningCert grenzt nur auf „für Codesignatur nutzbare Zertifikate“ ein,
# beschränken Sie also zusätzlich auf solche mit privatem Schlüssel innerhalb der Gültigkeitsdauer,
# und identifizieren Sie es in Umgebungen mit mehreren Treffern zusätzlich über Subject oder Thumbprint
$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert |
    Where-Object { $_.HasPrivateKey -and $_.NotAfter -gt (Get-Date) -and
                   $_.Subject -eq 'CN=KomuraSoft Code Signing (Test)' } |
    Sort-Object NotAfter -Descending |
    Select-Object -First 1   # Bleiben durch Erneuerung mehrere Zertifikate mit demselben Subject übrig, auf das mit dem weitesten Ablaufdatum eingrenzen

# Der Zeitstempel ist Pflicht. Er hält die Signatur auch nach Ablauf des Zertifikats gültig
# Ersetzen Sie die URL durch den Zeitstempeldienst, den der Aussteller Ihres Zertifikats (interne CA/Anbieter) angibt
Set-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1 -Certificate $cert `
    -HashAlgorithm SHA256 -TimestampServer 'http://timestamp.example.com'

# Der Status der Signatur lässt sich mit Get-AuthenticodeSignature prüfen (Valid/NotSigned/HashMismatch usw.)
Get-AuthenticodeSignature -FilePath .\Invoke-NightlyBatch.ps1

Es gibt drei Spezifika, die Sie im Griff haben sollten.⁶⁵

• Die Signatur wird als # SIG #-Kommentarblock am Ende der Datei eingebettet. Eine bestehende Signatur wird ersetzt. Das bedeutet, dass die Bearbeitung auch nur eines einzigen Zeichens des Skripts nach der Signatur diese ungültig macht — genau das dient als Manipulationserkennung.
• Die Angabe von -TimestampServer bedeutet, dass das Skript nach Ablauf des Zertifikats nicht mehr fehlschlägt. Eine Signatur bleibt entweder gültig, „solange das Signaturzertifikat selbst gültig ist“, oder „solange der Zeitstempelserver verifizieren kann, dass sie signiert wurde, während das Zertifikat gültig war“, und da die meisten Codesignaturzertifikate ein Jahr gültig sind, ist der Zeitstempel die Lebensader für den langfristigen Betrieb.⁶⁵ Folgen Sie für die zu verwendende Zeitstempeldienst-URL den Angaben des Ausstellers Ihres Zertifikats (der CA).
• Ein unter Windows PowerShell 5.1 oder PowerShell-Versionen vor 7.2 signiertes Skript musste als ASCII oder UTF8NoBOM gespeichert werden. PowerShell 7.2 und höher unterstützen signierte Skripte in beliebiger Kodierung.⁵ An Standorten, an denen 5.1 noch im Einsatz ist, ist dies eine häufige Quelle für Vorfälle, bei denen die Signaturprüfung durch die Kodierung eines Skripts mit japanischsprachigen Kommentaren bricht — achten Sie also darauf. Die umfassenderen Unterschiede zwischen 5.1 und PowerShell 7 sowie die Migration sind ein Thema, das eine eigene Behandlung wert ist.

In einer AllSigned-Umgebung erscheint zur Laufzeit eine Eingabeaufforderung, falls ein Skript zwar signiert ist, aber sein Herausgeber noch nicht als vertrauenswürdig oder blockiert eingestuft wurde: „Möchten Sie Software von diesem nicht vertrauenswürdigen Herausgeber ausführen?“ Wählen Sie „Immer ausführen“, werden Sie bei diesem Herausgeber nicht erneut gefragt.¹⁵ Bei einem Betrieb mit interner CA lässt sich diese Eingabeaufforderung vollständig aus dem Betrieb entfernen, indem Sie auch das Herausgeberzertifikat in den Speicher „Vertrauenswürdige Herausgeber“ jedes Rechners verteilen.

6. Standardpraxis in einer Entscheidungstabelle — Vom „Zudecken mit Bypass“ bis zum Signaturbetrieb

Der Standardweg, um die Governance interner Skriptverteilung und -ausführung durchzudenken, ist die folgende Entscheidungstabelle.

Eine Anmerkung zur letzten Zeile. Das Problem eines Betriebs, der „Dinge mit ExecutionPolicy Bypass zudeckt“, ist nicht an sich, ein Sicherheitsloch zu öffnen (da die Ausführungsrichtlinie von Anfang an nie eine Grenze war). Das Problem sind diese drei Dinge.

• Die Aufgabe der Sicherheitsfunktion — Sie entfernen dauerhaft das letzte Netz, das den Unfall auffängt, versehentlich das falsche Skript auszuführen oder ein manipuliertes Skript auszuführen, ohne es zu bemerken.
• Die Abweichung von der Governance — in dem Moment, in dem GPO beginnt, die Ausführungsrichtlinie zu verwalten, hört die Bypass-Angabe auf zu funktionieren, und jede Aufgabe, die das Problem zugedeckt hatte, schlägt auf einmal fehl.¹ Das ist technische Schuld, bei der sich „der Grund, warum es funktionierte“ als ein unverwaltetes Schlupfloch herausstellt.
• Die Verwirrung der Ursachenermittlung — sobald Bypass verstreut ist, können Sie das Verhalten nicht mehr aus der effektiven Richtlinie der Umgebung ableiten, was die Untersuchung von Rechner-zu-Rechner-Unterschieden (warum schlägt es nur auf diesem Rechner fehl) erheblich erschwert.

Bypass selbst ist eine Einstellung, die für Konfigurationen bereitgestellt wird, bei denen eine auf PowerShell aufgebaute Anwendung die Dinge mit ihrem eigenen Sicherheitsmodell steuert.¹ Machen Sie sich mit der Tatsache vertraut, dass es nicht dazu gedacht ist, gewohnheitsmäßig als Startoption für operative Skripte verwendet zu werden, die ein Mensch geschrieben hat. Den Aufbau sicherer, zuverlässiger zeitgesteuerter Ausführung in der Aufgabenplanung behandeln wir ausführlich in Wenn Aufgaben der Aufgabenplanung nicht laufen oder mit 0x1 enden — Ursachenermittlung und Design für zuverlässigen Betrieb.

7. Zusammenfassung

• Die Ausführungsrichtlinie ist eine Sicherheitsfunktion, keine Sicherheitsgrenze. Behandeln Sie das Abwehren von Angriffen auf einer anderen Schicht, und lassen Sie die Ausführungsrichtlinie die Aufgabe „versehentliche Fehler verhindern“ übernehmen.
• Die Richtlinie besitzt fünf Geltungsbereiche, mit der Rangfolge MachinePolicy > UserPolicy > Process > CurrentUser > LocalMachine. Beginnen Sie jede Fehlersuche mit Get-ExecutionPolicy -List.
• Worauf RemoteSigned achtet, ist Zone.Identifier (das Mark of the Web). Lassen Sie geprüfte Dateien mit Unblock-File durch, ohne die Richtlinie zu lockern.
• Signieren Sie mit Set-AuthenticodeSignature, und geben Sie immer -TimestampServer an. Nutzen Sie für interne Verteilung ein von einer internen CA ausgestelltes Zertifikat; selbstsigniert ist nur zum Testen.
• Zentralisieren Sie die organisatorische Governance über die Gruppenrichtlinie „Skriptausführung aktivieren“. Diese Einstellung hat Vorrang vor jedem Geltungsbereich und jeder -ExecutionPolicy-Angabe.
• Die gewohnheitsmäßige Nutzung von -ExecutionPolicy Bypass gibt die Sicherheitsfunktion auf und hat unter GPO-Verwaltung ohnehin keine Wirkung. Der richtige Weg ist, das „Zudecken“ überflüssig zu machen, indem Sie die Umgebungsrichtlinie ordentlich einrichten und einen Signaturbetrieb führen.

Verwandte Artikel

• PowerShell-Befehlsgrundlagen — Die zuerst zu lernenden Vorgänge und wie man sie sicher nutzt
• Warum Windows „Windows hat Ihren PC geschützt“ anzeigt
• Wenn Aufgaben der Aufgabenplanung nicht laufen oder mit 0x1 enden — Ursachenermittlung und Design für zuverlässigen Betrieb
• Fehlerbehandlung und Wiederholungsdesign für PowerShell-Skripte

Verwandte Beratungsbereiche

Die Komura Software LLC übernimmt das Design von Ausführungsrichtlinien- und Signaturbetrieb für interne PowerShell-Skripte, die Prüfung einer Verteilung über Gruppenrichtlinien sowie die Untersuchung umgebungsspezifischer Unterschiede wie „dieses Skript schlägt nur auf bestimmten Rechnern fehl“. Wir können auch dabei helfen, bestehende Batch- und Skriptbestände auf eine sicherere betriebliche Grundlage zu stellen.

• Technische Beratung & Design-Review
• Fehleranalyse und Ursachenermittlung
• Windows-Modernisierung & Wartung
• Kontakt

Referenzlinks

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.

Ist die Ausführungsrichtlinie von PowerShell eine Sicherheitsfunktion?

Die offizielle Dokumentation stellt unmissverständlich fest, dass „die Ausführungsrichtlinie kein Sicherheitssystem ist, das Benutzeraktionen einschränkt“. Das liegt daran, dass sie sich trivial umgehen lässt, indem man den Inhalt eines Skripts einfach in die Befehlszeile einfügt. Der Zweck der Ausführungsrichtlinie ist es, Grundregeln festzulegen und als Sicherheitsfunktion zu wirken, die den Unfall verhindert, „unbeabsichtigt ein Skript auszuführen, das man nicht ausführen wollte“ — Sie dürfen sie nicht als Sicherheitsgrenze konzipieren, die einen Angreifer aufhalten soll. Das Abwehren von Angriffen ist Aufgabe einer anderen Schicht (Anwendungssteuerung, minimale Rechtevergabe und Ähnliches).

Was ist der Unterschied zwischen RemoteSigned und AllSigned?

RemoteSigned verlangt eine Signatur eines vertrauenswürdigen Herausgebers nur für Skripte, die aus dem Internet stammen (mit dem Mark of the Web versehen); lokal erstellte Skripte können unsigniert ausgeführt werden. AllSigned verlangt eine Signatur für jedes Skript und jede Konfigurationsdatei, einschließlich lokal erstellter, und fordert vor der Ausführung von etwas eines noch nicht klassifizierten Herausgebers eine Bestätigung an. AllSigned ist die realistische Wahl, wenn Ihre Organisation einen Signaturbetrieb aufbauen kann (Verteilung von Codesignaturzertifikaten und ein Signaturverfahren); RemoteSigned ist realistisch, wenn Sie keine solche Struktur haben.

Warum lässt sich ein heruntergeladenes Skript mit einer Fehlermeldung „nicht digital signiert“ nicht ausführen?

Dateien, die über einen Browser oder ähnliche Werkzeuge heruntergeladen werden, erhalten einen alternativen Datenstrom namens Zone.Identifier, der sie als „eine Datei, die aus dem Internet stammt“ markiert. Ist Ihre Ausführungsrichtlinie RemoteSigned, wird die Ausführung eines unsignierten Skripts mit diesem Zeichen blockiert. Sobald Sie den Inhalt geprüft und als sicher eingestuft haben, können Sie den Zone.Identifier-Stream mit dem Cmdlet Unblock-File oder über das Kontrollkästchen „Zulassen“ in den Eigenschaften der Datei im Explorer entfernen und das Skript ausführen, ohne je Ihre Ausführungsrichtlinie zu ändern.

Was ist ein realistischer Weg, intern verteilte PowerShell-Skripte zu betreiben?

Es gibt grob zwei Optionen. Die erste ist RemoteSigned plus Ablage von Skripten auf einem Dateiserver, was den Start ohne den Aufbau eines Signaturbetriebs erlaubt, aber je nach Verteilungsweg kann das Mark of the Web angehängt werden und die Ausführung blockieren, und auch die Manipulation eines Skripts lässt sich nicht erkennen. Die zweite ist AllSigned plus ein Signaturbetrieb: Skripte mit Set-AuthenticodeSignature signieren, unter Verwendung eines Codesignaturzertifikats (realistischerweise eines, das von einer internen Zertifizierungsstelle ausgestellt wurde), und die Richtlinie zentral über Gruppenrichtlinien verwalten. Im Gegenzug für Kontrolle über die Ausführungsrichtlinie und die Fähigkeit, Manipulationen zu erkennen, tragen Sie die Betriebskosten der Zertifikatsverteilung und -erneuerung.

Ist es in Ordnung, in der Aufgabenplanung weiterhin -ExecutionPolicy Bypass anzugeben?

Es funktioniert, wird aber nicht empfohlen. Erstens kann in einer Umgebung, in der die Ausführungsrichtlinie über Gruppenrichtlinien verwaltet wird, eine Befehlszeilenangabe von ExecutionPolicy die Gruppenrichtlinie nicht schlagen, sie greift also gar nicht erst. Zweitens bedeutet die gewohnheitsmäßige Nutzung von Bypass, aus eigener Hand genau die Sicherheitsfunktion zu entfernen, die versehentliche Ausführung verhindern soll, und wird im Laufe der Zeit zu einer wachsenden Ursache für die Kluft zwischen organisatorischer Richtlinie und dem, was tatsächlich vor Ort passiert. Wenn Sie das dauerhaft betreiben möchten, besteht der richtige Ansatz darin, die Richtlinie der Umgebung ordentlich über Gruppenrichtlinien oder das Set-ExecutionPolicy eines Administrators festzulegen und stattdessen Skripte über eine Signatur Vertrauen demonstrieren zu lassen.

Warum braucht die Skriptsignatur einen Zeitstempel (-TimestampServer)?

Die Gültigkeit einer Signatur ist grundsätzlich an das Ablaufdatum des Signaturzertifikats gebunden, aber mit einem Zeitstempel bürgt der Zeitstempelserver dafür, dass „dies signiert wurde, während das Zertifikat noch gültig war“, sodass Sie das Skript auch nach Ablauf des Zertifikats weiter nutzen können. Die meisten Codesignaturzertifikate sind etwa ein Jahr gültig, sodass der Betrieb ohne Zeitstempel Sie jedes Jahr dem Risiko aussetzt, dass „eines Tages, ganz plötzlich, jedes signierte Skript im Unternehmen auf einmal aufhört zu funktionieren“. Geben Sie beim Signieren immer -TimestampServer an.

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.