Ausgangslage: Nicht die Konsole, sondern unkontrollierte Ausführung ist das Problem

PowerShell gehört zum Verwaltungs- und Automatisierungsmodell moderner Windows-Umgebungen. Betriebssystem, Endpoint Management, Softwareverteilung, Monitoring, EDR und Fachanwendungen nutzen PowerShell oder gehostete PowerShell-Runspaces. Ein pauschales Verbot von powershell.exe trifft deshalb häufig zuerst legitime Betriebsprozesse – und bildet trotzdem keine verlässliche Sicherheitsgrenze.

In gewachsenen Active-Directory-Umgebungen sieht die Ausgangslage oft so aus:

  • Windows PowerShell 5.1, PowerShell ISE und PowerShell 7 wurden nicht getrennt inventarisiert.
  • Die Execution Policy steht lokal auf Restricted oder AllSigned und gilt deshalb als erledigte Härtung.
  • Eine Softwareverteilung sperrt nur powershell.exe, lässt aber pwsh.exe, ISE, Remote-Endpunkte und gehostete Runspaces außer Acht.
  • Standardnutzer können Skripte aus Profil-, Download-, Temp- oder beschreibbaren Share-Pfaden starten.
  • Interne Skripte sind nicht signiert, liegen in veränderbaren Verzeichnissen oder besitzen keinen technischen Owner.
  • Administratoren verwenden auf normalen Benutzergeräten dieselbe interaktive Shell wie Standardnutzer.
  • Script-Block-Logging und Transkription fehlen – oder schreiben sensible Inhalte in ungeschützte lokale Ordner.
  • Ein hartes Verbot würde Logon-Skripte, Management-Agenten, Installer, Supportwerkzeuge oder Entwicklerprozesse unterbrechen.

Die Execution Policy ist dabei nur eine Sicherheits- und Bedienhilfe. Sie steuert, unter welchen Bedingungen PowerShell Skriptdateien lädt, verhindert aber keine interaktive Befehlseingabe und ist kein Schutz gegen einen entschlossenen Benutzer. RemoteSigned oder AllSigned können die Skripthygiene verbessern; sie ersetzen keine Ausführungskontrolle.

Auch PowerShell selbst verleiht einem Standardnutzer keine zusätzlichen Rechte. Die Shell automatisiert zunächst nur das, was dessen Token, Dateirechte, Netzwerkzugriffe und Applikationsberechtigungen ohnehin erlauben. Das Risiko entsteht aus der Kombination aus leistungsfähiger Sprache, erreichbaren Verwaltungsoberflächen, erlaubten nativen Programmen, schwachen Rechteketten und fehlender Codekontrolle. Genau diese Kette muss das Hardening begrenzen.

Zielbild: Standardnutzer behalten nur kontrollierte Fähigkeiten

Ein tragfähiger Zielzustand ist kein flächendeckendes „PowerShell aus“. Er trennt Benutzer-, Automations- und Administrationspfade:

  1. Alle PowerShell-Hosts sind bekannt. Windows PowerShell 5.1, PowerShell 7, ISE, Remote-Endpunkte, Scheduled Tasks, Management-Agenten und eingebettete Runspaces sind nach Geräteklasse erfasst.
  2. Application Control bildet die technische Grenze. Eine systemweite App-Control-for-Business-Policy mit User Mode Code Integrity kontrolliert Anwendungen, Skripte und Module. AppLocker bleibt nur dort Übergangsbasis, wo bereits ein belastbarer Betrieb existiert.
  3. Standardnutzer arbeiten unter System Lockdown. Interaktive PowerShell läuft im Constrained Language Mode; nicht vertrauenswürdige Skripte werden abhängig von Plattform, Host und Policy blockiert oder eingeschränkt.
  4. Vertrauenswürdige Automatisierung ist explizit freigegeben. Signierte Skripte, Module und Abhängigkeiten stammen aus administrativ geschützten Build- und Verteilungspfaden.
  5. Execution Policy dient nur der Hygiene. Der gewünschte Wert wird zentral verwaltet, aber weder als Sicherheitsgrenze noch als Ersatz für Application Control dokumentiert.
  6. Privilegierte Arbeit findet auf getrennten Systemen statt. Admin-Konten melden sich nicht auf normalen Benutzergeräten an; Full-Language-Automation läuft auf kontrollierten Managementsystemen.
  7. Delegierte Aufgaben nutzen JEA. Benutzer erhalten nur die benötigten Cmdlets, Funktionen und Parameter über einen gehärteten Remote-Endpunkt, nicht eine allgemeine administrative Konsole.
  8. Relevante Telemetrie ist definiert und geschützt. Script Blocks, benötigte Module, Transkripte und Application-Control-Ereignisse werden zentral gesammelt, zugriffsgeschützt und mit angemessener Aufbewahrung verarbeitet.
  9. Geräteklassen besitzen eigene Policies. Standard-Clients, Entwicklergeräte, Admin Workstations, Kiosks und Server teilen nicht blind dieselbe Ausführungsgrenze.
  10. Rollback und Ausnahmen sind vorab definiert. Jede Freigabe hat Owner, Scope und Review-Datum; Recovery erfolgt über getestete Policy-Ringe statt über lokale Abschaltungen.

Der wesentliche Unterschied: Eine ausgeblendete Shell ist nur schwerer zu finden. Eine systemweite Code- und Rechtekontrolle begrenzt dagegen, was tatsächlich ausgeführt werden darf.

Umsetzung: PowerShell in ein kontrolliertes Betriebsmodell überführen

1) Hosts, Policies und Abhängigkeiten read-only erfassen

Beginne mit repräsentativen Geräten jeder Klasse. Die folgende Abfrage verändert nichts und zeigt vorhandene PowerShell-Programme, den Zustand der aktuellen Sitzung und die wirksamen Execution-Policy-Scope-Werte:

& {
  Set-StrictMode -Version Latest

  $hostNames = @(
    'powershell.exe'
    'powershell_ise.exe'
    'pwsh.exe'
  )

  $hosts = Get-Command -Name $hostNames -All -ErrorAction SilentlyContinue |
    Select-Object Name, CommandType, Source, Version -Unique

  [pscustomobject]@{
    HostName            = $Host.Name
    PSEdition           = $PSVersionTable.PSEdition
    CurrentVersion      = $PSVersionTable.PSVersion.ToString()
    ProcessPath         = (Get-Process -Id $PID).Path
    CurrentLanguageMode = $ExecutionContext.SessionState.LanguageMode
  }

  $hosts
  Get-ExecutionPolicy -List

  if (Get-Command -Name Get-AppLockerPolicy -ErrorAction SilentlyContinue) {
    $effectivePolicy = Get-AppLockerPolicy -Effective
    $effectivePolicy.RuleCollections |
      Select-Object CollectionType, EnforcementMode
  }

  $ciTool = Get-Command -Name CiTool.exe -ErrorAction SilentlyContinue
  if ($ciTool) {
    (& $ciTool.Source -lp -json | ConvertFrom-Json).Policies |
      Select-Object PolicyID, FriendlyName, IsEnforced, IsAuthorized, IsSigned
  }
}

CurrentLanguageMode beschreibt nur den gestarteten Host in dieser Sitzung. Es beweist nicht, wie ein anderer Host, ein nicht vertrauenswürdiges Skript oder ein Serviceprozess behandelt wird. Wiederhole den Test deshalb mit Windows PowerShell und PowerShell 7 sowie mit einem repräsentativen Standardbenutzer.

Get-AppLockerPolicy zeigt ausschließlich die wirksame AppLocker-Konfiguration, nicht geladene App-Control-for-Business-Policies. CiTool listet diese Policies auf unterstützten Versionen ab Windows 11 22H2 beziehungsweise Windows Server 2025. Auf älteren Systemen gehören deshalb die zentrale Deploymentquelle und erfolgreiche Policy-Aktivierungsereignisse 3099 aus Microsoft-Windows-CodeIntegrity/Operational in die Bestandsaufnahme.

Prüfe auf älteren Plattformen zusätzlich, ob die optionale PowerShell-v2-Engine noch vorhanden ist. Auf aktuellen Windows-Versionen kann sie bereits entfernt beziehungsweise nicht mehr verfügbar sein:

Get-WindowsOptionalFeature -Online |
  Where-Object FeatureName -Like 'MicrosoftWindowsPowerShellV2*' |
  Select-Object FeatureName, State

Die Abfrage erfordert je nach Plattform eine erhöhte Sitzung, ändert aber keinen Featurezustand. Eine noch installierte v2-Engine gehört nach Kompatibilitätstest entfernt; sie unterstützt wesentliche moderne Schutz- und Protokollierungsfunktionen nicht.

Ergänze die technische Inventur durch Daten aus Softwareverteilung, EDR und Aufgabenplanung. Relevant sind .ps1, .psm1 und .psd1, interne Signaturketten, Logon-Skripte, Scheduled Tasks, WinRM-Endpunkte, RMM- und Endpoint-Management-Jobs sowie Anwendungen, die PowerShell über Bibliotheken hosten. Eine Dateinamenssuche nach powershell.exe reicht dafür nicht.

2) Geräteklassen und Administrationspfade trennen

Definiere zuerst, welche Arbeitsweise pro Geräteklasse benötigt wird:

  • Standard-Clients: interaktive Nutzung nur eingeschränkt; freigegebene Unternehmensskripte bleiben funktionsfähig.
  • Kiosk- und Produktionsgeräte: PowerShell-Hosts und nicht benötigte Verwaltungstools können per Policy vollständig blockiert oder, soweit unterstützt, aus dem Image entfernt werden.
  • Entwicklerarbeitsplätze: eigene Policy mit kontrollierten Toolchains, lokalen Testbereichen und klarer Trennung von privilegierten Konten.
  • Privileged Access Workstations und Managementserver: freigegebene administrative Module und Skripte, jedoch keine normale Benutzerkommunikation oder Office-Nutzung.
  • Server: separate Policy je Rolle; Backup, Monitoring, Cluster, Deployment und Recovery müssen vollständig getestet sein.

App Control for Business ist primär eine Gerätekontrolle. Eine erzwungene UMCI-Policy beeinflusst auch Administratoren auf demselben System. Versuche deshalb nicht, normale Benutzergeräte gleichzeitig zur freien Admin-Workstation zu machen. Für privilegierte Tätigkeiten sind getrennte Systeme oder eng definierte Remote-Endpunkte die sauberere Grenze.

Konten folgen derselben Trennung. Standardkonten erhalten keine lokale Administratorrolle. Privilegierte Identitäten werden nicht auf Benutzerclients angemeldet und ihre Zugangsdaten werden dort nicht zwischengespeichert. Service- und Deploymentkonten erhalten nur die Logon-Typen und Zielsysteme, die ihr Betriebsmodell benötigt.

3) Application Control als System-Lockdown pilotieren

Für neue Zielarchitekturen ist App Control for Business – früher Windows Defender Application Control – die bevorzugte Plattform. Aktiviere User Mode Code Integrity und lasse die Script-Enforcement-Funktion bewusst eingeschaltet. Eine bestehende, gut gepflegte AppLocker-Implementierung kann als Übergang dienen; ein neues PowerShell-Hardening sollte aber nicht von einer reinen Script-Rule-Sammlung abhängig werden.

PowerShell erkennt eine wirksame System-Lockdown-Policy. Interaktive Sitzungen laufen dann im Constrained Language Mode. Vertrauenswürdige Skripte und Module, die von der App-Control-Policy erlaubt werden, können im Full Language Mode laufen; nicht freigegebene Inhalte werden je nach Windows- und PowerShell-Version blockiert oder nur eingeschränkt ausgeführt. Genau deshalb müssen Policy und PowerShell-Version gemeinsam getestet werden.

Constrained Language Mode reduziert unter anderem den freien Zugriff auf beliebige .NET- und COM-APIs. Er ist aber keine Vollsperre: erlaubte Cmdlets, grundlegende Sprachelemente und freigegebene native Programme bleiben nutzbar und arbeiten weiterhin mit den Rechten des Benutzers. Das manuelle Setzen eines Language Mode in einem Profil oder Prozess ist keine belastbare Grenze. Der Schutz entsteht erst durch den vom Betriebssystem erkannten System Lockdown.

Jede neue oder wesentlich geänderte App-Control-Policy beginnt im Audit-Ring. Audit bedeutet dabei nicht automatisch „ohne Auswirkung“: einzelne Script-Hosts und PowerShell-Versionen können bereits ihr Verhalten ändern oder zusätzliche Einschränkungen protokollieren. Teste daher echte Arbeitsabläufe statt nur auf Blockevents zu warten.

Der Pilot muss mindestens abdecken:

  • interaktive Befehle mit Standard- und Administratorkonto,
  • signierte und nicht freigegebene Skripte,
  • Module, Manifeste, verschachtelte Module und Dot-Sourcing,
  • Logon- und Startup-Skripte,
  • Softwareverteilung, RMM, EDR, Monitoring und Backup,
  • WinRM, Scheduled Tasks und Helpdesk-Werkzeuge,
  • Geräte ohne Netzverbindung sowie Policy-Update und Rollback.

Erweitere den Scope erst nach einem normalen Patch- und Softwareupdate-Zyklus. Erlaube nicht automatisch jedes im Audit beobachtete Skript. Ausführung belegt Nutzung, nicht Vertrauenswürdigkeit.

4) Vertrauenswürdige Skripte wie Software ausliefern

Ein freigegebenes Skript kann unter System Lockdown mit Full-Language-Fähigkeiten laufen. Seine Lieferkette verdient deshalb denselben Schutz wie eine Anwendung:

  1. Quellcode liegt in einem versionierten Repository mit Review und nachvollziehbarem Owner.
  2. Ein kontrollierter Build erzeugt das auszuliefernde Skript oder Modul.
  3. Eine dedizierte Code-Signing-Identität signiert nur freigegebene Artefakte; der private Schlüssel liegt nicht auf Entwickler- oder Benutzergeräten.
  4. App Control erlaubt nur die benötigten Signer, Produkte, Dateien oder verwalteten Verteilpfade; bei signierten PowerShell-Inhalten muss zusätzlich die Root-CA der Signaturkette im Trusted-Root-Store des Geräts liegen.
  5. Zielverzeichnisse und Shares sind für Standardnutzer nicht beschreibbar.
  6. Updates, Modulabhängigkeiten und Zertifikatswechsel werden im Pilot getestet; abhängige Module sind ebenfalls erlaubt und exportieren Funktionen explizit ohne Wildcards.
  7. Veraltete Freigaben und Hashausnahmen besitzen ein Ablauf- und Review-Datum.

„Digital signiert“ bedeutet nicht automatisch „fachlich sicher“. Eine zu breite Publisher-Regel kann jedes Skript eines Signers freigeben. Ebenso macht eine sichere Signatur keinen unsicheren Parameter, kein Klartextgeheimnis und keine zu weitgehende Funktion ungefährlich. Review, Secret Handling und minimale Berechtigungen bleiben erforderlich.

Vermeide Dot-Sourcing in freigegebenen Modulen. Ist es unvermeidbar, muss jede eingebundene Datei die App-Control-Policy separat passieren. Implizite oder wildcard-basierte Funktions-Exports sind unter System Lockdown nicht nur schwer prüfbar, sondern können je nach Trust-Grenze auch fehlschlagen.

Die Execution Policy kann parallel per Gruppenrichtlinie auf AllSigned oder einen anderen zum Betriebsmodell passenden Wert gesetzt werden. Das schafft konsistente Bedienregeln und sichtbare Signaturfehler. Dokumentiere jedoch ausdrücklich, dass diese Einstellung absichtlich nur eine zusätzliche Hygieneschicht ist.

5) Windows PowerShell und PowerShell 7 separat konfigurieren

Die klassischen Windows-PowerShell-Richtlinien liegen typischerweise unter:

Computerkonfiguration
  Richtlinien
    Administrative Vorlagen
      Windows-Komponenten
        Windows PowerShell

Dort befinden sich unter anderem Einstellungen für Script Block Logging, Module Logging, Transkription und Script Execution. PowerShell 7 liefert PowerShellCoreExecutionPolicy.admx, die passende .adml und InstallPSCorePolicyDefinitions.ps1 in $PSHOME. Übernimm die Vorlagen versionskontrolliert in den Central Store und konfiguriere sie unter dem separaten Zweig Administrative Templates > PowerShell Core.

Eine Windows-PowerShell-GPO beweist daher nicht, dass pwsh.exe dieselben Einstellungen erhält. Prüfe auf Clients beide Hosts und die tatsächlich erzeugten Eventkanäle. Halte außerdem fest, welche Teams die ADMX-Version aktualisieren, wenn PowerShell 7 über einen neuen Servicing-Kanal ausgerollt wird.

Entferne PowerShell ISE und alte Engines dort, wo keine Abhängigkeit mehr besteht. Das reduziert Legacy-Fläche, ersetzt aber ebenfalls keine Codekontrolle. Anwendungen können PowerShell-Komponenten hosten, ohne eine sichtbare Konsole zu öffnen.

6) Delegierte Adminaufgaben über JEA bereitstellen

Wenn Helpdesk oder Betrieb einzelne administrative Aktionen benötigt, ist eine allgemeine lokale PowerShell-Sitzung meist die falsche Freigabe. Just Enough Administration stellt stattdessen einen registrierten Remote-Endpunkt mit festen Rollen bereit.

Eine JEA-Rolle enthält nur die benötigten Cmdlets, Funktionen, Provider und externen Programme. Parameter werden nach Möglichkeit auf sichere Werte oder Formate begrenzt. Die Sitzung arbeitet typischerweise im NoLanguage-Modus und kann privilegierte Aktionen über temporäre virtuelle Konten oder eine kontrollierte gMSA-Identität ausführen. Der Benutzer erhält damit eine definierte Funktion, nicht dauerhaft die zugrunde liegende Administratorrolle.

Die Run-as-Identität ist eine kritische Designentscheidung: Ohne RunAsVirtualAccountGroups gehört ein virtuelles Konto auf Member-Systemen standardmäßig zu den lokalen Administratoren und auf einem Domain Controller sogar zu Domain Admins. Begrenze es deshalb auf explizite lokale beziehungsweise Domänengruppen oder betreibe den Endpunkt auf einem separaten Managementhost. Eine gMSA ist für benötigten Netzwerkzugriff geeignet, teilt jedoch dieselbe Run-as-Identität zwischen Sitzungen. Die Zuordnung zum aufrufenden Benutzer hängt dann von geschützten JEA-Transkripten und korrelierten Logs ab.

JEA braucht dieselbe Sorgfalt wie eine API:

  • Endpoint- und Role-Capability-Dateien sind nur für Administratoren schreibbar.
  • Freigegebene Funktionen validieren alle Parameter und normalisieren Pfade.
  • Beliebige Script Blocks, frei wählbare Programme oder unbeschränkte Dateipfade werden nicht durchgereicht.
  • Rollen werden kleinen AD-Gruppen zugeordnet und regelmäßig rezertifiziert.
  • Transkripte und PowerShell-Ereignisse werden zentral geschützt gesammelt.
  • Versionierung, Hochverfügbarkeit und Recovery des Endpunkts sind getestet.

JEA ist keine allgemeine Sandbox für beliebige Benutzerskripte. Es ist ein kontrollierter Weg für klar definierte administrative Aufgaben und ergänzt die Ausführungskontrolle auf dem Client.

7) Logging einschalten, ohne neue Geheimnisablagen zu schaffen

Für Windows PowerShell 5.1 und PowerShell 7 sollten mindestens Script Block Logging und die für den Betrieb relevanten Module bewertet werden. Transkription kann Support und Nachvollziehbarkeit verbessern. App-Control-Ereignisse zeigen zusätzlich, welche Datei erlaubt, auditiert, eingeschränkt oder blockiert wurde.

Sammle die Daten über Windows Event Forwarding, EDR oder SIEM. Sinnvolle Korrelationsfelder sind Benutzer, Gerät, Hostgeneration, Prozesskette, Script- oder Modulpfad, Signer, Hash, Language Mode, Policy-Version und Change-Fenster. Ein einzelnes Event ohne Geräte- und Benutzerrolle liefert zu wenig Kontext.

Script Blocks und Transkripte können Kennwörter, Tokens, Connection Strings, personenbezogene Daten oder interne Pfade enthalten. Deshalb gelten mindestens:

  • keine Klartextgeheimnisse in Skripten oder Parametern,
  • Secret-Zugriff über einen Vault mit kurzlebiger Berechtigung,
  • geschützte zentrale Logziele statt benutzerbeschreibbarer lokaler Ordner,
  • restriktive Lese- und Löschrechte,
  • definierte Aufbewahrung und Datenschutzprüfung,
  • Protected Event Logging, wo es technisch und operativ unterstützt wird.

AMSI, EDR und Logging erhöhen Sichtbarkeit und Erkennungsqualität. Sie sind keine Ersatzkontrolle dafür, welcher Code überhaupt ausgeführt werden darf.

8) Enforcement, Ausnahmen und Recovery betreibbar machen

Wechsle von Audit zu Enforcement in kleinen Ringen: Security-/Workplace-Lab, IT-Pilot, repräsentative Fachbereiche, standardisierte Clientwellen und zuletzt getrennte Sondergeräte. Entwickler- und Adminsysteme erhalten eigene Changes.

Definiere vor Enforcement messbare Freigabekriterien: keine ungeklärten Managementfehler, freigegebene Skripte mit gültiger Signaturkette, erwarteter Language Mode, vollständige Ereignisübertragung, getestete Offline-Geräte und ein dokumentierter Rollback. Ein Fehler in einer systemweiten App-Control-Policy kann mehr als PowerShell betreffen; Recovery muss daher über die Policy-Plattform und nicht über spontane lokale Registryänderungen erfolgen.

Jede Ausnahme enthält Anwendung oder Skript, Signer beziehungsweise Hash, Geräte-Scope, Benutzerbedarf, Owner, Begründung, Ablaufdatum und Testnachweis. Benutzerbeschreibbare Allow-Pfade sind keine zulässige Ausnahme. Für Notfälle existiert ein getrennt geschützter Break-Glass-Pfad mit nachträglicher Prüfung, nicht eine dauerhaft breite Allow-Regel.

Vorteile

  • Belastbare Ausführungsgrenze: Application Control bewertet Skripte, Module und Anwendungen systemweit statt nur einen sichtbaren Prozessnamen zu sperren.
  • Weniger frei nutzbare Laufzeitfunktionen: Constrained Language Mode begrenzt den Zugriff auf leistungsfähige .NET- und COM-Funktionen für nicht vertrauenswürdigen Code.
  • Legitime Automatisierung bleibt möglich: Kontrolliert gebaute und freigegebene Unternehmensskripte können weiterarbeiten.
  • Klare Trennung privilegierter Arbeit: PAWs, Managementserver und JEA-Endpunkte halten Adminidentitäten von normalen Benutzerclients fern.
  • Bessere Nachvollziehbarkeit: Signer, Policy-Entscheidung, Language Mode und PowerShell-Telemetrie lassen sich gemeinsam auswerten.
  • Wartbare Delegation: JEA ersetzt breite lokale oder Domänenrollen durch kleine, prüfbare Aufgabenoberflächen.
  • Weniger Scheinsicherheit: Execution Policy, Logging und AMSI erhalten eine klar abgegrenzte Rolle statt als alleinige Härtung zu gelten.

Nachteile und Grenzen

  • Systemweite Auswirkungen: Eine fehlerhafte App-Control-Policy kann Management, Installer und Anwendungen außerhalb von PowerShell stören.
  • Zwei PowerShell-Generationen: Windows PowerShell 5.1 und PowerShell 7 besitzen unterschiedliche Policy-, Logging- und Servicing-Pfade.
  • Signaturbetrieb kostet Aufwand: Code-Signing-Schlüssel, Zertifikatswechsel, Module und Abhängigkeiten brauchen einen verlässlichen Lifecycle.
  • Vertrauenswürdige Skripte bleiben mächtig: Von der Policy erlaubter Code kann im Full Language Mode laufen und muss entsprechend geprüft und geschützt werden.
  • Constrained Language ist keine Vollsperre: Erlaubte Cmdlets und native Programme bleiben nutzbar; Benutzerrechte und weitere Application-Control-Regeln bleiben entscheidend.
  • Nicht jeder Interpreter ist integriert: Ein erlaubter Drittanbieter-Host kann Skripte anders behandeln und benötigt eine eigene Bewertung.
  • Audit kann Verhalten verändern: Script Enforcement ist je nach Host und Version schon im Audit-Ring betrieblich sichtbar.
  • Logging erzeugt sensible Daten: Mehr Telemetrie erhöht Schutz-, Speicher- und Datenschutzanforderungen.
  • JEA braucht Produktpflege: Rollen, Parametergrenzen, Endpunktverfügbarkeit und Transkripte müssen laufend getestet werden.
  • Entwickler benötigen andere Grenzen: Eine Standard-Client-Policy ist für Build-, Test- und Debug-Workflows meist zu eng.

Typische Stolperfallen

  • Nur powershell.exe sperren: pwsh.exe, ISE, Remote-Endpunkte und gehostete Runspaces bleiben unberücksichtigt.
  • Restricted oder AllSigned als Sicherheitsgrenze behandeln: Execution Policy verhindert keine entschlossene interaktive Nutzung.
  • Language Mode im Profil setzen: Der Benutzer kann den Prozess oder das Profil beeinflussen; erst System Lockdown schafft die beabsichtigte Grenze.
  • Alle signierten Skripte erlauben: Signatur allein ist keine fachliche Freigabe und breite Publisher-Regeln vergrößern den Trust Scope.
  • Beschreibbare Pfade freigeben: Wer eine erlaubte Datei ersetzen kann, kontrolliert den freigegebenen Ausführungspfad.
  • Nur .ps1 testen: Module, Manifeste, Dot-Sourcing, Binärmodule und verschachtelte Abhängigkeiten verhalten sich unter Policy ebenfalls relevant.
  • Audit als rein passiv annehmen: PowerShell oder andere Script-Hosts können bereits eingeschränkt reagieren.
  • Constrained Language mit Blockieren verwechseln: Viele Cmdlets und erlaubte native Programme bleiben verfügbar.
  • PowerShell-7-ADMX vergessen: Die Windows-PowerShell-Einstellungen decken den separaten Host nicht automatisch vollständig ab.
  • Freie Adminarbeit auf demselben Client erwarten: System Lockdown gilt geräteweit; privilegierte Arbeit braucht einen getrennten Pfad.
  • JEA zu breite Befehle geben: Beliebige Pfade, Programme oder Script Blocks können die kleine Aufgabenoberfläche wieder in eine allgemeine Konsole verwandeln.
  • Logs lokal und offen speichern: Transkripte und Script Blocks können selbst zu einer wertvollen Geheimnisablage werden.
  • Auditfunde automatisch erlauben: Häufige oder bestehende Nutzung beweist keine Vertrauenswürdigkeit.
  • Management-Agenten erst nach Enforcement testen: Ein gebrochener EDR-, Backup- oder Deploymentpfad erschwert anschließend auch die Recovery.
  • Lokale Ausnahmen verteilen: Nicht versionierte Einzeländerungen erzeugen einen unsichtbaren zweiten Policyzustand.

Projekt-Checkliste

  • [ ] Windows PowerShell 5.1, PowerShell ISE, PowerShell 7 und gehostete Runspaces je Geräteklasse inventarisieren.
  • [ ] Logon-Skripte, Scheduled Tasks, WinRM, Softwareverteilung, RMM, EDR, Monitoring und Backup erfassen.
  • [ ] Wirksame Execution Policy und aktuellen Language Mode mit Standard- und Administratorkonto dokumentieren.
  • [ ] Vorhandene AppLocker- und App-Control-Policies auf Scope, Modus und Script Enforcement prüfen.
  • [ ] Geladene App-Control-Policies mit CiTool oder Code-Integrity-Ereignis 3099 gegen die Deploymentquelle abgleichen.
  • [ ] PowerShell-v2-Feature auf Altplattformen erfassen und nach Kompatibilitätstest entfernen.
  • [ ] Standard-Clients, Entwicklergeräte, PAWs, Kiosks und Server in getrennte Policy-Gruppen aufteilen.
  • [ ] Festlegen, welche Unternehmensskripte und Module weiterhin Full Language benötigen.
  • [ ] Repository, Review, Build, Code Signing und geschützte Verteilung für diese Artefakte einrichten.
  • [ ] Schreibrechte auf alle erlaubten Skript-, Modul- und Verteilungspfade prüfen.
  • [ ] App-Control-for-Business-Basis mit UMCI und bewusstem Script Enforcement im Audit-Ring pilotieren.
  • [ ] Windows PowerShell 5.1 und PowerShell 7 mit derselben Policy separat testen.
  • [ ] Interaktive Sitzungen, Skripte, Module, Manifeste, Dot-Sourcing und native Abhängigkeiten testen.
  • [ ] PowerShell-Core-ADMX/ADML versioniert in den Central Store übernehmen.
  • [ ] Execution Policy zentral als zusätzliche Hygieneschicht konfigurieren und korrekt dokumentieren.
  • [ ] Script Block Logging, erforderliches Module Logging und Transkription je Hostgeneration festlegen.
  • [ ] Zentrale Logziele, ACLs, Verschlüsselung, Aufbewahrung und Datenschutzprüfung umsetzen.
  • [ ] Benötigte Helpdesk- und Betriebsaufgaben als eng begrenzte JEA-Rollen modellieren.
  • [ ] JEA-Run-as-Gruppen auf Member-Systemen und Domain Controllern explizit begrenzen.
  • [ ] JEA-Parameter, Pfade, Run-as-Identität, Transkripte und Hochverfügbarkeit testen.
  • [ ] Pilot über mindestens einen regulären Patch- und Softwareupdate-Zyklus beobachten.
  • [ ] Block-, Audit- und Restriction-Ereignisse nach Geräteklasse und Geschäftsbedarf bewerten.
  • [ ] Rollback-Policy, Offline-Verhalten und Break-Glass-Verfahren praktisch testen.
  • [ ] Enforcement in getrennten Ringen mit messbaren Freigabekriterien aktivieren.
  • [ ] Jede Ausnahme mit Owner, Scope, Begründung, Ablaufdatum und Review erfassen.
  • [ ] Regelmäßig prüfen, ob neue PowerShell-Versionen, Module oder Managementtools den Zielzustand verändern.