PowerShell verstehen – Execution Policy, Codesignatur und Zone.Identifier richtig einsetzen

PowerShell-Sicherheit verstehen: mehr als nur eine Execution Policy

Die Microsoft PowerShell ist längst mehr als ein Werkzeug zur Systemadministration. Sie bildet das Fundament moderner Automatisierung unter Windows und in hybriden Cloudumgebungen. Gerade deshalb spielt das Thema Sicherheit eine zentrale Rolle: Wer PowerShell produktiv einsetzt, sollte verstehen, welche Mechanismen beim Ausführen von Skripten greifen – und warum.

Häufig wird die Execution Policy als einziges Sicherheitskonzept wahrgenommen. In der Praxis ist sie jedoch nur ein Teil eines mehrschichtigen Modells, das verschiedene Schutzebenen miteinander kombiniert:

1. Die Execution Policy definiert, unter welchen Bedingungen Skripte ausgeführt werden dürfen
2. Der Identifier markiert, woher eine Datei stammt und ob sie als potenziell unsicher gilt
3. Die Codesignatur (Authenticode) stellt sicher, dass ein Skript unverändert und vertrauenswürdig ist

Diese Mechanismen greifen ineinander, um sowohl Benutzer:innen als auch Systeme vor unbeabsichtigter oder unkontrollierter Codeausführung zu schützen. PowerShell-Sicherheit bedeutet daher nicht, Prozesse zu blockieren, sondern Vertrauen, Herkunft und Integrität von Skripten nachvollziehbar zu machen.

Das Ziel dieses Beitrags ist ein praxisnahes Verständnis dafür, wie diese drei Komponenten zusammenspielen – und wie Administrator:innen sie bewusst konfigurieren und prüfen können. Dabei stehen technische Präzision und Alltagstauglichkeit im Vordergrund.

Execution Policy: Behinderungs- statt Verhinderungsrichtlinie

Die Execution Policy ist einer der am häufigsten missverstandenen Sicherheitsmechanismen in PowerShell. Sie dient nicht dazu, bösartigen Code zu verhindern, sondern soll das unbeabsichtigte Ausführen von Skripten vermeiden. Im Kern handelt es sich um eine Bewusstseins- und Kontrollrichtlinie, keine Sicherheitsbarriere im kryptografischen Sinne.

Grundprinzip

Beim Start prüft PowerShell, welche Ausführungsrichtlinie aktuell gilt. Abhängig vom Modus entscheidet die Shell, ob und in welchem Umfang Skripte ausgeführt werden dürfen. Die Richtlinie kann zentral per Gruppenrichtlinie, systemweit oder benutzerspezifisch festgelegt werden. Im Seminar spreche ich dabei meist von einer Behinderungs- und nicht von einer Verhinderungsrichtlinie. Die Execution Policy soll vor zufälligem Ausführen von Skripten schützen, nicht vor bewusster Aktion. Wer weiß, was er tut, kann PowerShell-Code immer ausführen.

Modi im Überblick

PowerShell kennt mehrere vordefinierte Ausführungsmodi, die festlegen, wie restriktiv Skripte behandelt werden. Jede dieser Einstellungen verfolgt ein eigenes Sicherheits- oder Komfortziel, von maximaler Kontrolle bis zur vollständigen Freigabe. Die Wahl des passenden Modus hängt stark von der Umgebung ab: Während in Test- oder Lernumgebungen häufig RemoteSigned verwendet wird, gilt in produktiven Systemen auch AllSigned als bewährter Standard.

Modus	Beschreibung
Restricted	Skriptausführung nicht erlaubt (Standard auf neuen Systemen)
AllSigned	Nur signierte Skripte werden ausgeführt
RemoteSigned	Lokale Skripte erlaubt, heruntergeladene nur mit gültiger Signatur
Unrestricted	Alle Skripte erlaubt, Warnung bei Internetdateien
Bypass	Keine Einschränkung und keine Warnmeldungen
Undefined	Kein Wert gesetzt; PowerShell verwendet die nächsthöhere gültige Ebene (Scope)

Scopes und Prioritätsreihenfolge

PowerShell speichert die Execution Policy in sogenannten Scopes (Bereichen). Diese bestimmen, für welchen Kontext die Richtlinie gilt und in welcher Reihenfolge sie ausgewertet wird. Richtlinien auf höherer Ebene überschreiben dabei Werte auf niedrigerer Ebene.

Priorität	Bereich / Scope
1️⃣ MachinePolicy	Wird durch Gruppenrichtlinie auf Computerebene gesetzt
2️⃣ UserPolicy	Wird durch Gruppenrichtlinie auf Benutzerebene gesetzt
3️⃣ Process	Gilt nur für die aktuelle PowerShell-Sitzung
4️⃣ CurrentUser	Gilt nur für das aktuelle Benutzerprofil
5️⃣ LocalMachine	Gilt systemweit für alle Benutzer:innen

Richtlinien, die per Gruppenrichtlinie (MachinePolicy oder UserPolicy) gesetzt werden, haben höchste Priorität. Sie können durch lokale Befehle wie Set-ExecutionPolicy nicht überschrieben werden. PowerShell liest die aktiven Werte in genau dieser Reihenfolge ein und verwendet die erste Richtlinie, die definiert ist.

Anwendung in der Praxis

Das Ändern der Execution Policy erfordert administrative Berechtigungen, wenn die Änderung auf Systemebene erfolgen soll. Das betrifft insbesondere den Scope LocalMachine, also die standardmäßig wirksame, systemweite Richtlinie. Eine PowerShell-Sitzung mit administrativen Rechten ist in der Regel daran zu erkennen, dass in der Titelzeile des Fensters der Präfix Administrator: erscheint.

In Umgebungen mit Windows 11 oder Windows Server 2025 wird PowerShell standardmäßig über die Anwendung Terminal gestartet, die mehrere Shells (PowerShell, Eingabeaufforderung, Azure Cloud Shell) in einem konsistenten Fenster zusammenführt. Für das Setzen der Execution Policy spielt es dabei keine Rolle, ob die Befehle in einem klassischen PowerShell-Fenster oder innerhalb von Terminal ausgeführt werden – entscheidend sind allein die Berechtigungen der gestarteten Sitzung.

Mit dem Cmdlet Set-ExecutionPolicy kann die Richtlinie gezielt auf einer bestimmten Ebene gesetzt werden:

Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser

Fehlt der Parameter -Scope, wird standardmäßig die Ebene LocalMachine verwendet, also die systemweite Richtlinie für alle Benutzer:innen. Dieser Umstand führt häufig zu unerwartetem Verhalten, wenn Änderungen eigentlich nur für eine Sitzung oder ein einzelnes Benutzerprofil beabsichtigt waren.

Zur Kontrolle der aktuell wirksamen Richtlinie dient:

Get-ExecutionPolicy -List

Die Ausgabe zeigt die festgelegten Werte auf allen Scopes in Prioritätsreihenfolge und erleichtert die Analyse in komplexeren Umgebungen.

Zentrale Verwaltung über Gruppenrichtlinie

In Unternehmensnetzwerken lässt sich die Ausführungsrichtlinie komfortabel über Gruppenrichtlinien verwalten. Sowohl in der Computer- als auch in der Benutzerkonfiguration steht dazu die Richtlinie Skriptausführung aktivieren zur Verfügung. Hier gilt es diese Richtlinie zu aktivieren und die geeignete Ausführungsrichtline auszuwählen.

Über diese Einstellungen kann beispielsweise systemweit RemoteSigned oder AllSigned erzwungen werden. Richtlinien aus der GPO entsprechen den Scopes MachinePolicy oder UserPolicy und übersteuern lokale Einstellungen zuverlässig.

Fazit

Die Execution Policy ist kein Sicherheitsmechanismus im engeren Sinn, sondern ein bewusst gesetzter Schutz vor unbeabsichtigter Skriptausführung. Ihre Wirkung hängt maßgeblich vom Scope ab, in dem sie konfiguriert wird. Das Verständnis der Prioritäten – von MachinePolicy bis Process – ist entscheidend, um unerwartete Blockaden oder Warnungen richtig zu interpretieren.

Zone.Identifier und Alternate Data Streams

Beim Herunterladen von Dateien aus dem Internet oder dem Öffnen von E-Mail-Anhängen ergänzt Windows die Datei um zusätzliche Informationen, die für Sicherheitsprüfungen relevant sind. Diese Metadaten werden im sogenannten Zone.Identifier gespeichert, einem Alternate Data Stream (ADS) des NTFS-Dateisystems.

Herkunft und Funktion

Alternate Data Streams wurden ursprünglich mit NTFS eingeführt, um zusätzliche Informationen an Dateien zu binden, ohne den sichtbaren Inhalt zu verändern. Windows nutzt diese Funktion, um die Herkunft einer Datei zu kennzeichnen. Wird eine Datei beispielsweise aus dem Internet geladen, erhält sie automatisch einen Eintrag mit dem Hinweis, aus welcher Sicherheitszone sie stammt.

PowerShell, der Windows Explorer und auch SmartScreen greifen auf diese Information zurück, um zu entscheiden, ob eine Datei oder ein Skript ohne Warnung geöffnet werden darf.

ZoneId-Werte und ihre Bedeutung

Der Zone-Identifier speichert den Zonenwert (ZoneId), der der ursprünglichen Quelle der Datei entspricht. Diese Zuordnung stammt aus der Windows- und Internet-Explorer-Sicherheitsarchitektur:

ZoneId	Zone	Beschreibung
0	My Computer	Lokale Dateien, sicherer Ursprung
1	Local Intranet	Dateien aus dem Unternehmensnetz
2	Trusted Sites	Quellen, die explizit als vertrauenswürdig markiert sind
3	Internet	Heruntergeladene Dateien aus dem Internet
4	Restricted Sites	Eingeschränkte oder nicht vertrauenswürdige Quellen

PowerShell berücksichtigt diesen Wert insbesondere bei aktivierter Execution Policy RemoteSigned: Wird ein Skript mit ZoneId = 3 (Internet) erkannt und liegt keine gültige Signatur vor, blockiert PowerShell die Ausführung, bis die Datei gezielt freigegeben wird.

Zone.Identifier in der Praxis

Beim Arbeiten mit Dateien unter PowerShell wird standardmäßig der Primärdatenstrom einer Datei gelesen – also der tatsächliche Dateiinhalt, der unter dem Stream-Namen :$DATA geführt wird. Wird hingegen ein alternativer Stream wie Zone.Identifier angegeben, liest PowerShell den Inhalt dieses Metadatenstroms aus. So lassen sich Sicherheitsinformationen direkt anzeigen und nachvollziehen, ohne zusätzliche Tools zu verwenden:

# Anzeige aller vorhandenen Streams
Get-Item 'C:\Downloads\script.ps1' -Stream *

# Inhalt des Zone.Identifier-Streams anzeigen
Get-Content 'C:\Downloads\script.ps1' -Stream Zone.Identifier

Die hier ausgegebenen Werte, etwa ZoneId=3 für Dateien aus dem Internet, zeigen den Sicherheitskontext, den Windows beim Herunterladen der Datei automatisch gesetzt hat. Diese Information wird anschließend von PowerShell, SmartScreen und weiteren Sicherheitsmechanismen ausgewertet.

Dateien gezielt freigeben

Das Entfernen des Zone-Identifier-Eintrags erfolgt über:

Unblock-File 'C:\Downloads\script.ps1'

Dieser Befehl ist kein administratives Hexenwerk, er kann von allen Benutzer:innen ausgeführt werden, die über ausreichende Dateiberechtigungen verfügen. Er entfernt schlicht den alternativen Datenstrom Zone.Identifier und damit die Markierung, dass die Datei aus einer externen Quelle stammt. Damit gilt auch hier die bewährte Regel aus der Execution Policy-Praxis:

„Wer weiß, was zu tun ist, kriegt jedes Skript zur Ausführung – notfalls Zeile für Zeile.“

Selbst wenn die Execution Policy auf Restricted steht, lassen sich Skriptinhalte manuell oder schrittweise übertragen. PowerShell setzt also nicht auf Verbote, sondern auf das Prinzip der bewussten Entscheidung – die Technik ermöglicht, die Verantwortung liegt bei den Administrator:innen.

Technischer Hintergrund: NTFS und ADS

Alternate Data Streams (ADS) sind ein fester Bestandteil des NTFS-Dateisystems und ermöglichen es, mehrere Datenströme an eine einzelne Datei zu binden. Das Prinzip stammt ursprünglich aus der Kompatibilität zu Apple Hierarchical File System (HFS) und wurde später von Windows als flexible Erweiterung genutzt, etwa zur Speicherung von Metadaten, Miniaturansichten oder wie hier: Sicherheitsinformationen.

Ein typisches Beispiel:

• Script.ps1 → Hauptinhalt (Primärdatenstrom)
• Script.ps1:Zone.Identifier → Zusatzdatenstrom (Sicherheitskontext)

Der Primärdatenstrom enthält den tatsächlichen Inhalt der Datei (z.B. der PowerShell-Code). Alle weiteren Streams, wie der Zone.Identifier, sind unsichtbare Begleitinformationen, die nur über spezielle Befehle oder Tools zugänglich sind.

ADS sind eine mächtige, aber oft übersehene Funktion des NTFS-Dateisystems. Sie werden von Windows intern für viele Sicherheitsfunktionen genutzt, von SmartScreen über Mark-of-the-Web bis hin zu PowerShells RemoteSigned-Prüfung. In anderen Dateisystemen, etwa FAT oder exFAT, gehen diese Zusatzinformationen vollständig verloren, was den Sicherheitskontext beim Datenaustausch beeinflussen kann.

Unterstützung durch unterschiedliche Dateisysteme

Nicht jedes Dateisystem unterstützt Alternate Data Streams. Besonders beim Kopieren von Dateien zwischen Laufwerken können diese Zusatzinformationen verloren gehen.

Dateisystem	ADS-Unterstützung
NTFS	Vollständig unterstützt
ReFS	Teilweise unterstützt (abhängig von Version)
FAT (alle Varianten)	Keine Unterstützung

Aktuelle Versionen von ReFS unterstützen die Speicherung von ADS grundsätzlich, jedoch werten nicht alle Tools diese Strukturen korrekt aus. Dadurch kann es vorkommen, dass Sicherheitsinformationen erhalten bleiben, aber von PowerShell oder Drittsoftware nicht interpretiert werden. Wird eine Datei auf ein FAT32- oder exFAT-Laufwerk kopiert, gehen ADS-Daten vollständig verloren – damit entfällt auch der Sicherheitskontext.

Fazit

Der Zone.Identifier ist ein unscheinbarer, aber essenzieller Bestandteil des Windows-Sicherheitsmodells. Er sorgt dafür, dass Dateien aus unsicheren Quellen beim ersten Zugriff geprüft werden. In Verbindung mit der Execution Policy bildet er die Grundlage für das Verhalten von RemoteSigned.

NTFS bleibt dabei das Referenz-Dateisystem für sicherheitsrelevante Skripte, während ReFS in modernen Szenarien zunehmend kompatibel, aber noch nicht vollständig gleichwertig ist. Fehlt ADS-Unterstützung, gehen wichtige Kontextinformationen verloren, ein Risiko, das Administrator:innen beim Datenaustausch zwischen Systemen stets im Blick behalten sollten.

Codesignatur: Vertrauensanker für Skripte

Während die Execution Policy in erster Linie vor unbeabsichtigtem Handeln schützt, bietet die Codesignatur (Authenticode) eine echte Sicherheitsebene: Sie stellt sicher, dass ein Skript nicht verändert wurde und tatsächlich von der angegebenen Quelle stammt. Damit ist die Signatur der zentrale Vertrauensanker für produktive PowerShell-Umgebungen.

Ziel und Bedeutung der Codesignatur

Die Codesignatur adressiert ein zentrales Dilemma der modernen IT-Administration: Egal, ob ein PowerShell-Skript lokal von Mitarbeitenden erstellt oder aus dem Internet heruntergeladen wurde – in beiden Fällen ist zunächst nicht nachvollziehbar,

• wer das Skript erstellt hat,
• mit welcher Intention es entstanden ist,
• und ob es seit seiner Erstellung verändert oder manipuliert wurde.

Gerade in Umgebungen mit verteilten Teams oder mehreren Administrator:innen kann dies zu erheblichen Risiken führen. Ein scheinbar harmloses Skript kann Befehle enthalten, die unbeabsichtigt Systeme verändern, Berechtigungen manipulieren oder sensible Daten freigeben.

Hier setzt die Codesignatur an. Sie schafft eine überprüfbare Verbindung zwischen Person, Inhalt und Vertrauenskontext – und ermöglicht so eine klare Bewertung, ob ein Skript legitim ist oder nicht. Damit bildet sie das technische Rückgrat der drei zentralen Sicherheitsprinzipien:

1. Integrität: Das Skript wurde seit der Signierung nicht verändert. Jede noch so kleine Modifikation macht die Signatur ungültig.
2. Authentizität: Die herausgebende Person ist eindeutig identifizierbar. Die Signatur belegt, von wem das Skript stammt.
3. Vertrauen: Das Zertifikat der herausgebenden Person wurde durch eine interne oder öffentliche Zertifizierungsstelle validiert.

In sicherheitskritischen Umgebungen kann dieses Prinzip sogar erweitert werden, etwa durch ein Vier-Augen-Prinzip, bei dem Skripte vor der Freigabe doppelt signiert werden: einmal durch den/die Ersteller:in, einmal durch eine autorisierte Prüfinstanz oder Change-Manager:in. Dieses Verfahren erhöht den administrativen Aufwand, bietet aber maximale Nachvollziehbarkeit und schützt vor unautorisierten Änderungen durch Einzelpersonen.

Ein signiertes Skript ist somit nicht nur ein Stück Code, sondern ein nachvollziehbarer Vertrauensnachweis. Ändert ein Mitarbeiter ein Skript nachträglich, verliert die vorhandene Signatur automatisch ihre Gültigkeit – ein entscheidender Mechanismus, um Manipulationen zu erkennen.

Macht dieser Mitarbeiter die betreffende Änderung anschließend wieder rückgängig, stimmt die Dateifassung wieder mit der ursprünglichen Prüfsumme überein und ist erneut ausführbar. Eine Neusignatur des Skripts ist in diesem Fall nicht erforderlich.

Diese Funktionsweise verdeutlicht, dass Signaturen keine Zauberei sind, sondern auf einer klaren, kryptografisch abgesicherten Prüfsummenlogik beruhen. PowerShell vergleicht dabei den Hashwert der Datei mit dem in der Signatur gespeicherten Wert, wobei jede Abweichung zu einer Warnung oder Sperre führt.

Zertifikate für die Signierung

Zur Signierung werden Codesignatur-Zertifikate (Code Signing Certificates) verwendet, die den Herausgeber kryptografisch identifizieren und gleichzeitig die technische Vertrauenskette abbilden. Diese Zertifikate können aus unterschiedlichen Quellen stammen, je nach Einsatzszenario, Sicherheitsrichtlinie und organisatorischer Einbindung:

Selbstsignierte Zertifikate (Self-Signed)

Selbstsignierte Zertifikate sind schnell erstellt und für Test-, Labor- und Entwicklungsumgebungen sehr nützlich. Sie werden häufig mit dem PowerShell-Cmdlet New-SelfSignedCertificate generiert, etwa um die Signaturprozesse oder CI/CD-Pipelines (Continuous Integration / Continuous Deployment) vorab zu testen.

Da sie nicht von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt werden, enthalten sie keine externe oder organisatorische Vertrauenskette. Das bedeutet:

• Der Vertrauensstatus muss manuell hergestellt werden, z.B. durch das Importieren des selbstsignierten Root-Zertifikats in den lokalen Trusted Root Certification Authorities Store
• Auf anderen Systemen gelten Skripte, die mit einem solchen Zertifikat signiert sind, als nicht vertrauenswürdig, bis auch dort das Root-Zertifikat hinzugefügt wurde
• Eine Rückverfolgbarkeit oder zentrale Widerrufsmöglichkeit (Revocation) besteht nicht

In der Praxis sind selbstsignierte Zertifikate daher ein hervorragendes Werkzeug, um den Signaturprozess zu verstehen und zu testen, aber nicht geeignet für produktive Szenarien, in denen Nachvollziehbarkeit, Haftung oder zentrale Richtlinien eine Rolle spielen.

Ein typischer Anwendungsfall ist das interne Entwicklerlabor oder der Schulungsbetrieb, in dem Codesignaturen lediglich simuliert, nicht aber rechtlich oder organisatorisch verbindlich genutzt werden.

Öffentliche Zertifizierungsstellen

Zertifikate von öffentlichen Zertifizierungsstellen / Certificate Authorities (CAs) – beispielsweise von DigiCert, Sectigo, GlobalSign – eignen sich vor allem für Skripte, Tools oder Module, die außerhalb der eigenen Organisation verteilt werden, etwa an Kund:innen oder Partner:innen. Die Signatur wird von externen Systemen als vertrauenswürdig anerkannt, da die Zertifikatskette auf allgemein bekannte Root-Zertifikate verweist.

Interne Zertifizierungsstellen (Standalone CAs)

Eine interne Zertifizierungsstelle kann völlig unabhängig von Active Directory betrieben werden. Sie eignet sich für isolierte Umgebungen oder dedizierte Systeme, in denen Zertifikate manuell beantragt und verteilt werden. Die Vertrauenskette muss hier manuell verwaltet werden, z.B. durch das Verteilen des CA-Zertifikats an alle beteiligten Systeme. Für kleine Organisationen oder Testumgebungen ist dieses Modell oft ausreichend, administrativ aber aufwändiger.

Interne Zertifizierungsstellen (Enterprise CAs)

Eine Enterprise Certification Authority (Enterprise CA) ist eine spezielle Form der internen Microsoft-Zertifizierungsstelle, die vollständig in Active Directory integriert ist. Sie nutzt Gruppenrichtlinien, Zertifikatstemplates und automatisierte Enrollment-Mechanismen, um Zertifikate gezielt an Benutzer:innen oder Computer in der Domäne auszugeben.

Vorteile dieser Integration:

• Automatische Verteilung der CA-Zertifikate über Active Directory
• Automatisierte Ausstellung über Auto-Enrollment oder manuelle Anforderung per MMC oder PowerShell
• Einfache Umsetzung von Rollenmodellen (z.B. Entwickler:innen, Prüfer:innen, Administrator:innen)
• Nachvollziehbare Vertrauenskette innerhalb der Organisation
• Nutzung von Zertifikatvorlagen (Templates) für Code Signing

Gerade im Kontext von Codesignaturen ist diese Integration ein entscheidender Vorteil: Einmal ausgestellte Zertifikate lassen sich zentral verwalten, ablaufen oder erneuern, ohne dass Administrator:innen auf jedem System manuell eingreifen müssen. So kann beispielsweise ein Signaturprozess auf einem Build-Server automatisiert ablaufen, während die Zertifikatsrichtlinien weiterhin durch die Unternehmens-CA kontrolliert werden.

In jeder angeführten Variante zur Verteilung gilt: Das Zertifikat muss über die Code Signing Extended Key Usage (EKU) verfügen, sonst wird es von PowerShell für die Codesignatur nicht akzeptiert.

Signieren und Prüfen von Skripten

PowerShell stellt mit wenigen Befehlen alles Notwendige bereit, um Skripte zu signieren und Signaturen zu überprüfen. Entscheidend dabei ist, dass das Codesignaturzertifikat im Zertifikatspeicher des aktuellen Benutzers oder Computers vorhanden und für den Zweck Code Signing freigegeben ist.

In Umgebungen mit einer Enterprise Certification Authority (Enterprise CA) wird das Zertifikat häufig automatisch über Active Directory Certificate Services (AD CS) ausgestellt und über Gruppenrichtlinien an die berechtigten Domänenbenutzer:innen verteilt. Diese Integration erleichtert den gesamten Prozess, da Zertifikate nicht manuell exportiert oder installiert werden müssen.

Skript signieren (Beispiel mit Enterprise CA-Zertifikat)

Bevor ein Skript überprüft werden kann, muss es zunächst signiert werden. Damit erhält es eine digitale Identität, die sowohl seine Herkunft als auch seine Unverändertheit belegt. PowerShell nutzt hierfür ein Codesignaturzertifikat, das in der Regel aus dem persönlichen Zertifikatspeicher des Benutzers stammt, insbesondere dann, wenn Zertifikate über eine Enterprise-Zertifizierungsstelle (Enterprise CA) bereitgestellt werden.

Der folgende Befehl ruft ein gültiges Codesignaturzertifikat ab und verwendet es, um das angegebene Skript zu signieren:

# Codesignatur-Zertifikat aus dem persönlichen Zertifikatspeicher abrufen
$cert = Get-ChildItem Cert:\CurrentUser\My -CodeSigningCert

# Skript signieren
Set-AuthenticodeSignature -FilePath '.\script.ps1' -Certificate $cert

Der Parameter -Certificate erwartet ein gültiges Zertifikatsobjekt mit der erweiterten Schlüsselverwendung (EKU) Code Signing. Das Skript wird anschließend mit dem privaten Schlüssel des Zertifikatsinhabers signiert, und die Signatur wird direkt in der Datei selbst gespeichert. Dieser Vorgang geschieht vollständig lokal – das Zertifikat verlässt das System nicht, und der private Schlüssel bleibt geschützt im Zertifikatspeicher.

Das Ergebnis ist ein eindeutig gekennzeichnetes Skript, dessen Ursprung und Integrität jederzeit überprüfbar sind – der erste konkrete Schritt, um PowerShell-Skripte zu einem verlässlichen Vertrauensanker in der Unternehmensumgebung zu machen.

Signatur prüfen

Nachdem ein Skript signiert wurde, stellt sich die entscheidende Frage: Ist die Signatur gültig – und kann ihr vertraut werden? PowerShell bietet hierfür eine integrierte Prüfroutine, mit der sich Signaturen schnell und zuverlässig verifizieren lassen. So kann nachvollzogen werden, ob ein Skript nachträglich verändert oder außerhalb der definierten Vertrauenskette erstellt wurde.

Die Überprüfung erfolgt mit dem Cmdlet:

Get-AuthenticodeSignature .\script.ps1

Die Ausgabe zeigt den Signaturstatus (z.B. Valid, NotSigned oder HashMismatch), die ausstellende Zertifizierungsstelle, das Ablaufdatum sowie ggf. vorhandene Zeitstempelinformationen. Diese Daten liefern einen schnellen Überblick darüber, ob das Skript technisch unverändert und organisatorisch vertrauenswürdig ist.

Damit lässt sich im Alltag klar unterscheiden, ob ein Skript bedenkenlos ausgeführt oder zunächst überprüft werden sollte, insbesondere dann, wenn es aus einer externen Quelle stammt oder über einen internen Freigabeprozess bereitgestellt wurde.

Automatisiertes Signieren in Build- und CI/CD-Prozessen

In modernen Entwicklungs- und Betriebsumgebungen wird die Signierung zunehmend automatisiert. Gerade in Build-Pipelines, etwa mit Azure DevOps, GitHub Actions oder Jenkins, lässt sich die Signatur nahtlos in den Veröffentlichungsprozess integrieren.

Beispiel: Ein PowerShell-Build-Skript signiert automatisch alle Skripte, die vor einem Release bereitgestellt werden:

$cert = Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert
$path = 'C:\Build\Output\Scripts'

Get-ChildItem -Path $path -Filter *.ps1 | ForEach-Object {Set-AuthenticodeSignature -FilePath $PSItem.FullName -Certificate $cert}

In Verbindung mit einer Enterprise-CA lassen sich solche Prozesse zentral absichern. Zertifikate können gezielt an Build-Server oder Service-Konten ausgegeben und mit eingeschränkter Gültigkeitsdauer versehen werden. Dadurch bleibt nachvollziehbar, welches System welches Skript signiert hat, ohne dass Entwickler:innen selbst Zugriff auf die privaten Schlüssel erhalten.

Diese Kombination aus automatisierter Signierung und zentraler Zertifikatsverwaltung schafft die Grundlage für Compliance-konforme Skriptfreigaben in modernen DevOps- und IT-Prozessen: schnell, reproduzierbar und zugleich auditierbar.

Timestamping und Ablauf von Zertifikaten

Eine Codesignatur ist grundsätzlich nur so lange gültig, wie das zugrunde liegende Zertifikat gültig ist, es sei denn, die Signatur wurde mit einem Zeitstempel (Timestamp) versehen. Ein solcher Zeitstempel dokumentiert, wann die Signatur erstellt wurde, und erlaubt dadurch die Validierung auch nach Ablauf oder Erneuerung des verwendeten Zertifikats.

Der Zeitstempel selbst ist kein Bestandteil der Datei, sondern wird von einem RFC 3161-konformen Timestamp-Server bereitgestellt. Dieser signiert die Signaturzeit und speichert sie innerhalb der Authenticode-Struktur des Skripts. Beim späteren Verifizieren prüft PowerShell, ob die Signatur zum angegebenen Zeitpunkt gültig war und das Zertifikat zu diesem Zeitpunkt noch nicht abgelaufen oder widerrufen war.

Damit wird verhindert, dass eine ansonsten korrekte Signatur plötzlich als ungültig gilt, nur weil das Zertifikat nachträglich abgelaufen ist.

Öffentliche vs. interne Timestamp-Server

Für den Zeitstempelprozess kann sowohl ein öffentlicher als auch ein interner Timestamp-Server genutzt werden:

• Öffentliche Timestamp-Server (z.B. http://timestamp.digicert.com oder http://timestamp.globalsign.com)
  Diese Server sind frei zugänglich und werden häufig in Softwareverteilungs- oder Build-Umgebungen eingesetzt, die öffentlich signierte Anwendungen erstellen.
• Interne Timestamp-Server
  In größeren Organisationen kann der Zeitstempeldienst Bestandteil der eigenen Public-Key-Infrastruktur (PKI) sein. Eine interne RFC 3161-kompatible Timestamp Authority (TSA) erlaubt es, Zeitstempel ausschließlich mit unternehmensinternen Zertifikaten zu erzeugen, ideal für Skripte, die innerhalb des Unternehmens signiert und verteilt werden. Der Vorteil: volle Kontrolle über Zeitquelle, Vertrauenskette und Protokollierung.

Beispiel für die Verwendung eines Timestamp-Servers:

Set-AuthenticodeSignature -FilePath '.\deploy.ps1' -Certificate $cert -TimestampServer 'http://timestamp.digicert.com'

Bei der Signatur wird der aktuelle Zeitpunkt vom Timestamp-Server angefordert, kryptografisch signiert und gemeinsam mit der Codesignatur in das Skript eingebettet. Dadurch ergeben sich in der Praxis die folgenden Vorteile:

• Auditierbarkeit: Zeitstempel belegen nachweislich, wann ein Skript signiert wurde
• Compliance: Interne Timestamp-Server stellen sicher, dass Signaturen innerhalb der eigenen Vertrauenskette validiert werden können, ohne externe Abhängigkeiten
• Langzeitvalidierung: Auch nach Ablauf oder Erneuerung von Zertifikaten bleibt die Signatur überprüfbar
• Revisionssicherheit: In CI/CD-Umgebungen können Build-Artefakte eindeutig zeitlich zugeordnet werden

Damit wird Timestamping zu einem essenziellen Bestandteil professioneller Signaturprozesse: Es schützt vor unbeabsichtigten Ungültigkeiten und schafft gleichzeitig eine nachvollziehbare Chronologie von Skriptänderungen und Freigaben.

Integration in Entwicklungs- und Betriebsprozesse

In modernen IT- und DevOps-Umgebungen ist die automatisierte Signierung von Skripten fester Bestandteil des Build- und Release-Prozesses. So wird sichergestellt, dass jedes veröffentlichte PowerShell-Skript oder Modul geprüft, signiert und mit einem Zeitstempel versehen wird, bevor es in Produktion gelangt. Dieses Verfahren schafft Transparenz, Nachvollziehbarkeit und Sicherheit, unabhängig davon, ob Skripte intern verwendet oder über Paketquellen wie PowerShell Gallery verteilt werden.

Beispiel: Automatische Signierung in einer CI/CD-Pipeline

In Build-Systemen wie Azure DevOps oder GitHub Actions kann die Signaturphase als eigener Schritt innerhalb der Pipeline definiert werden. Dabei greift der Build-Agent auf ein Codesignaturzertifikat aus dem Zertifikatspeicher des Build-Servers oder eines dedizierten Service-Kontos zu. Der Zeitstempel wird über einen RFC 3161-kompatiblen Timestamp-Server ergänzt.

Ein einfaches Beispiel für eine PowerShell-basierte Signaturaufgabe in einer Pipeline:

# Pfad zu den Build-Artefakten
$path = 'C:\Build\Artifacts\Scripts'

# Codesignatur-Zertifikat aus dem lokalen Zertifikatsspeicher abrufen
$cert = Get-ChildItem -Path Cert:\LocalMachine\My -CodeSigningCert

 # Skripte signieren und mit Timestamp versehen
Get-ChildItem -Path $path -Filter *.ps1 | ForEach-Object {Set-AuthenticodeSignature -FilePath $PSItem.FullName -Certificate $cert -TimestampServer 'http://timestamp.digicert.com'}

In einem Azure- oder GitHub-Workflow wird dieser PowerShell-Schritt meist in einer geschützten Stage ausgeführt, also erst nach erfolgreichem Build und Codeprüfung. So wird verhindert, dass unsignierte oder veränderte Skripte in das Release-Paket gelangen.

Zertifikatsverwaltung im CI/CD-Kontext

Für die Integration in Build- und Deployment-Pipelines ist eine zentrale Zertifikatsverwaltung entscheidend. Hier kommen meist die folgenden Verfahren zum Einsatz:

• Hardware Security Module (HSM) oder Azure Key Vault:
  Die privaten Schlüssel für die Signierung werden in einem Hardware- oder Cloud-basierten Sicherheitsmodul hinterlegt. PowerShell kann über APIs auf das Zertifikat zugreifen, ohne dass der private Schlüssel exportiert werden muss.
• Zertifikatsbereitstellung über Enterprise CA (AD CS):
  Das Zertifikat wird über Gruppenrichtlinien oder Auto-Enrollment gezielt an Build-Server oder Service-Accounts ausgegeben.
• Zertifikatslebenszyklusmanagement:
  Ablaufüberwachung, automatische Erneuerung und Revocation Policies verhindern, dass abgelaufene Zertifikate unbemerkt weiterverwendet werden.

In produktiven CI/CD-Umgebungen wird häufig ein dedizierter Code-Signing-Service-Account verwendet, dessen Zertifikat streng reglementiert ist und ausschließlich innerhalb des Build-Prozesses eingesetzt werden darf. Dadurch ergeben sich in der Praxis die folgenden Vorteil:

• Compliance: Die Signaturerstellung und Timestamping können revisionssicher protokolliert werden
• Konsistenz: Alle ausgelieferten Skripte und Module tragen eine einheitliche, überprüfbare Signatur
• Sicherheit: Der Signaturprozess erfolgt in einer kontrollierten Umgebung – ohne direkte Interaktion durch Entwickler:innen
• Transparenz: Zeitpunkt, Zertifikat und Ersteller sind eindeutig nachvollziehbar

Damit wird die Codesignatur vom einmaligen Sicherheitsmerkmal zum integralen Bestandteil einer modernen Software-Lieferkette (Software Supply Chain). PowerShell-Skripte werden nicht nur funktional geprüft, sondern auch kryptografisch beglaubigt, ein entscheidender Schritt in Richtung DevSecOps und Compliance-by-Design.

Fazit

Die Codesignatur ist der verlässlichste Vertrauensanker in PowerShell. Sie stellt sicher, dass Skripte unverändert, nachvollziehbar und überprüfbar bleiben, unabhängig davon, wo sie ausgeführt werden. Kombiniert mit einer geeigneten Execution Policy und dem Zone-Identifier entsteht so ein Sicherheitskonzept, das sowohl technisch als auch organisatorisch tragfähig ist.

Fazit: Zusammenspiel statt Einzelmaßnahmen

PowerShell-Sicherheit besteht nicht aus einem einzelnen Schalter oder Kommando, sondern aus dem Zusammenspiel mehrerer ineinandergreifender Mechanismen. Execution Policy, Zone.Identifier und Codesignatur erfüllen jeweils eine klar umrissene Aufgabe, erst in Kombination entsteht ein konsistentes, nachvollziehbares Sicherheitsmodell.

Mechanismus	Aufgabe	Bedeutung in der Praxis
Execution Policy	Steuerung der Skriptausführung	Schutz vor unbeabsichtigtem Handeln und bewusster Kontrolle des Ausführungskontexts
Zone.Identifier	Kontextinformation zur Herkunft der Datei	Grundlage für RemoteSigned und Bewertung externer Quellen
Codesignatur (Authenticode)	Kryptografischer Vertrauensnachweis	Sicherstellung von Integrität und Authentizität von Skripten

Diese drei Bausteine wirken auf unterschiedlichen Ebenen:

• Die Execution Policy sensibilisiert Benutzer:innen und definiert, unter welchen Umständen Code ausgeführt werden darf
• Der Zone.Identifier liefert den Kontext, aus welcher Quelle eine Datei stammt und ob zusätzliche Überprüfung erforderlich ist
• Die Codesignatur schließt den Kreis, indem sie technische und organisatorische Vertrauensprüfungen ermöglicht

Zusammen bilden sie die Grundlage für einen bewussten, überprüfbaren und verantwortungsvollen Umgang mit PowerShell, ein Ansatz, der nicht auf Verbote, sondern auf Nachvollziehbarkeit und Vertrauen setzt.

PowerShell-Sicherheit bedeutet nicht, Skripte zu blockieren, sondern sie gezielt freizugeben, zu kennzeichnen und zu signieren. Die Mechanismen dahinter – Execution Policy, Zone.Identifier und Codesignatur – sind keine Hürden, sondern Werkzeuge, um Vertrauen und Nachvollziehbarkeit in der Automatisierung zu schaffen.

Wer diese Konzepte versteht und konsequent anwendet, nutzt PowerShell nicht nur sicher, sondern strategisch klug, als integralen Bestandteil einer modernen, compliance-konformen IT-Infrastruktur. PowerShell-Sicherheit beginnt nicht bei der Richtlinie, sondern beim Verständnis, was Vertrauen in einer automatisierten Welt wirklich bedeutet.

Quellenangaben

(abgerufen am 11.10.2025)

Offizielle Microsoft-Dokumentation

• Microsoft Learn: Differences from Windows PowerShell
• Microsoft Learn: Internet Explorer Security Zones Registry Entries
• Microsoft Learn: NTFS Overview
• Microsoft Learn: PowerShell Support Lifecycle
• Microsoft Learn: ReFS Overview
• PowerShell 7.5 Documentation: about_Execution_Policies

Fachartikel und Blogs

• Chris Elgee (GIST): Identifier Examples
• Ironman Software Blog: PowerShell Alternate Data Streams
• Jeffrey Snover (Microsoft GitHub): Monad Manifesto
• Mathias Fuchs (Medium): The Impact of Microsoft’s ReFS on DFIR
• Netwrix Blog: Alternate Data Streams
• NinjaOne Blog: Understanding PowerShell Execution Policies
• TomTalksPowershell (Medium): Implementing PowerShell Security Best Practices for Sysadmins
• Wiki C2: The KornShell Story
• WindowsPro: Ausführungsrichtlinien (ExecutionPolicy) für PowerShell Scripts über GPO setzen

Weiterlesen hier im Blog

• PowerShell – Parallelisierung in der Praxis
• PowerShell Remoting verstehen: Von Ad-hoc bis One-to-Many
• PowerShell-Konstrukte im Überblick – Schleifen, Bedingungen und Fehlerbehandlung professionell eingesetzt
• Rechnen ohne Reue – lokale Sprachmodelle mit Ollama verstehen und betreiben
• Warum jedes Bit seinen Weg braucht – Der Weg zur intelligenten Kommunikation