Um dem Miss­brauch von PowerShell auf die Schliche zu kommen, kann man sämt­liche aus­geführte Komman­dos und Scripts mit­schneiden. Dafür exi­stieren zwei Mecha­nismen, einer davon schreibt alle Ein- und Aus­gaben in eine Datei. Es empfiehlt sich, die gesam­melten Daten an zentraler Stelle zusammen­zuführen.

PowerShell 7 ist die nächste Version von PowerShell Core und beruht auf .NET Core 3.0. Aller­dings ent­fällt der Namenszusatz "Core", weil Micro­soft mit dem Release 7 Windows PowerShell er­setzen will. Daher soll es mit fast allen be­stehenden Windows-Modulen kompa­tibel sein. Hinzu kommen einige neue Features.

Verbindungen, die man über Enter-PSSession und Invoke-Command aufbaut, kommu­nizieren stan­dard­mäßig über HTTP. Aller­dings ver­schlüsselt dabei WinRM die über­tragenen Daten. Zusätz­liche Sicher­heit erlangt man speziell in Work­groups durch HTTPS, wobei ein selbst­sig­nierten SSL-Zertifikat in der Regel reicht.

Viele Unter­nehmen setzen zum Schutz ihrer Infra­struktur einen Proxy-Server ein. Möchte man in einer solchen Umge­bung Exchange (Online oder On-Prem) mit Power­Shell ver­walten, dann kann die Ver­bindung scheitern. Das Problem lässt sich meist durch Anpassung der zuständigen Proxy-Einstel­lungen lösen.

Während man früher Tools wie makecert.exe benö­tigte, um selbst­signierte Zerti­fikate aus­zustellen, kann Power­Shell diese Auf­gabe seit Windows 8 und Server 2012 mit New-SelfSignedCertificate über­nehmen. Sie lassen sich etwa für die Client- und Server-Authenti­fizierung oder die Code-Signierung ver­wenden.

Viele Admins und DevOps kennen es: Man ist dabei, ein PowerShell-Skript zu schreiben, hat aber natür­lich nicht immer alle Cmdlets im Kopf. Unter­stützung findet man hier nicht nur mit Get-Help oder Get-Command, sondern noch aus­führ­licher in Form des großen PowerShell-Posters von ScriptRunner.*

Mit Just Enough Administration (JEA) kön­nen Benutzer ohne admini­strative Berech­tigungen Manage­ment-Aufgaben über­nehmen. Die Grund­lage für JEA bilden Session-Konfi­gurationen, die bestim­men, wer Zugriff bekommt. Role Capabilities definieren dann die Mittel, welche in PowerShell zur Ver­fügung stehen.

Um die Authen­tizität von Scripts zu gewähr­leisten, kann sie PowerShell mit einer Signatur versehen. Dies ist eine Voraus­setzung dafür, um stren­gere Richt­linien für die Aus­führung von PowerShell-Code vorzu­geben. Das erfor­derliche Zerti­fikat kann man bei intern ent­wickel­ten Scripts über eine AD-basierte CA aus­stellen.

Wie Exchange im firmen­eigenen Rechen­zentrum kann man auch die Cloud-Version mit Power­Shell admini­strieren. Voraus­setzung dafür ist aller­dings, dass man sich erst von seinem lokalen Computer zur Microsoft-Cloud ver­bindet. Der Rest funk­tioniert dann allerdings wieder so, wie man es von Exchange gewohnt ist.

PowerShell ist ein mächtiges Werk­zeug, das fast alle Kompo­nenten von Windows und Anwen­dungen wie Exchange steuern kann. In den Händen von An­greifern kann sie daher große Schäden an­richten. Der Constrained Language Mode sperrt gefähr­liche Features und ver­hindert so deren Missbrauch.