IT-Security ist eines der Themen, das Unternehmen wirklich beschäftigt. Zu Recht, wie immer mehr Attacken auf Infrastrukturen zeigen. Auch Scripte, mit denen viele Aufgaben gesteuert werden, sind begehrte Angriffsziele. Doch wie kann die Sicherheit im PowerShell-Umfeld erhöht werden? Der folgende Beitrag zeigt für einige Aspekte eine Lösung auf.

Was PowerShell mitbringt

PowerShell bringt bereits im „Standard-Umfang“ einige Funktionalitäten mit, mit denen die Sicherheit gesteigert und Angreifer von schädlichen Eingriffen abgehalten werden sollen, wie z.B. den Execution Policies, der Logging- und Monitoring-Funktion, der digitalen Signatur. Sie sind ein guter Anfang.

Execution Policies

Security beginnt bei PowerShell bereits bei den Execution Policies. Die Ausführungsrichtlinien legen fest, welche Bedingungen geschaffen sein müssen, damit PowerShell-Scripte ausführt. Hier können Sie verschiedene Levels definieren, zum Beispiel, dass lokale Scripte unsigniert ausgeführt werden dürfen, während heruntergeladene Scripte dafür signiert sein müssen. An sich ist diese Funktion durchaus hilfreich, wenn man ein versehentliches Ausführen von Scripten verhindern möchte. Hacker sind davon allerdings wenig beeindruckt.

Tipp: Wenn Sie die Execution Policies nutzen, steuern Sie diese über die Group Policies. Diese sind immer über den lokalen Berechtigungen angesiedelt und somit mächtiger im Kampf gegen unerwünschte Ausführungen.

Überprüfen Sie die gesetzten Policies mittels „Get-ExecutionPolicy -list“. Sind die Einstellungen auf RemoteSigned gesetzt, bedeutet das, dass lokale Scripte immer, heruntergeladene Scripte nur mit Signatur ausgeführt werden. Stellt man das Script selbst nun aber einfach auf „unblocked“ um und macht es lokal verfügbar, ist die Hürde bereits umgangen.

Logging & Monitoring

Auch Logging & Monitoring sind in PowerShell bereits inbegriffen. Hier kann man dafür sorgen, dass das Ausführen von Scripten über das Windows Event Log nachvollziehbar wird.  Auch dies sollten Sie allerdings über die Group Policies tun, da die Nachvollziehbarkeit nur über eine Zentralisierung zu erreichen ist.

Digital Signature

Die digitale Signatur haben wir bereits bei den Ausführungsrichtlinien erwähnt und festgestellt, dass diese enorm wichtig sein kann. Denn sie beantwortet zwei Fragen: Wer hat das Script erstellt (Authentifizierung)? Und wurde das Script nach der Signierung nochmals verändert (Integrität)? Am besten ist es sicherlich, Zertifikate von offiziellen Anbietern zu erwerben, da sie als besonders sicher gelten. Sie können über New-SelfSignedCertificate aber auch eigene Zertifikate erstellen und in Scripten verwenden.

Nach jeder Änderung an einem Script muss dieses übrigens neu signiert werden.

Constrained Language

PowerShell kann in verschiedenen Sprachmodi genutzt werden. Einer davon ist die „Constrained Language“, also die eingeschränkte Sprache. Sie wurde gerade in jüngster Vergangenheit umfangreich implementiert, bedingt aber eine Zentralisierung, wenn man die Möglichkeiten der PowerShell-Sprache und -Commandlets einschränken möchte.

Denn: Bei jeder neuen Session wird die Einstellung wieder auf FullLanguage zurückgesetzt. Die Zentralisierung gelingt daher nur mithilfe von Lösungen wie Applocker oder Device Guard.

Credentials

Ein spannendes Thema und gleichzeitig eine der größten Herausforderungen sind die Credentials, die zur Ausführung von PowerShell-Scripten benötigt werden.

PowerShell Credentials bestehen aus User-Namen und Passwort, und haben in den Scripten rein gar nichts verloren. Die manuelle Eingabe von Credentials durch den Benutzer ist zwar sicher, verhindert aber natürlich die automatische Ausführung von Scripten. Eine Möglichkeit dieses Problem zu umgehen, ist die verschlüsselte Ablage der Passwortinformation, die dann zur Laufzeit durch das PowerShell-Script ausgelesen werden. Dies funktioniert allerdings nur auf der Maschine, auf der die Verschlüsselung durchgeführt wurde. Wird die Passwort-Datei auf einen anderen Rechner kopiert, kann die Datei dort nicht mehr verwendet werden. Mit dieser Methode ist also auch die sichere Delegation nicht umsetzbar.

JEA – Just Enough Administration

Das Ziel von JEA ist es, Benutzern wirklich nur mit den Berechtigungen auszustatten, die sie für die Ausführung von bestimmten Aktionen benötigen. Ein Beispiel wäre hier das Anlegen eines Benutzers im Active Directory (AD), ohne dass der User dabei auch noch andere Berechtigungen im AD besitzt.

JEA bietet eine Role-based Access Control (RBAC) Plattform für PowerShell. Da hier mit Whitelisting gearbeitet wird, ist es zwingend erforderlich alle Aktionen zu kennen, die Benutzer ausführen können sollen. Dadurch ist die Pflege der entsprechenden Richtlinien entsprechend aufwendig und erfordert nach wie vor, dass der Benutzer PowerShell-Wissen besitzt.

Wie ScriptRunner die Sicherheit deutlich erhöht

PowerShell ist also mit einigen „Grundfunktionalitäten“ ausgestattet, um den Umgang mit Scripten sicher gestalten zu können. Auf der anderen Seite sind eine ganze Reihe von Problemen, die bei der praktischen Verwendung von PowerShell auftauchen, nicht gelöst. Im Folgenden sind die erweiterten Sicherheitsfunktionen von ScriptRunner beschrieben.

Zentralisierung der Scripte

Mit ScriptRunner werden alle PowerShell-Scripte zentral gespeichert und strukturiert. Damit wird die Voraussetzung für Entwicklung und Nutzung in Teams geschaffen.

Darüber hinaus ist sichergestellt, dass alle Beteiligten immer mit den aktuellen Script-Versionen arbeiten. Mit Hilfe der Rechtesteuerung wird der Zugriff auf die Scripte geregelt. Über das ScriptRunner Add-In für die PowerShell ISE können Scripte im zentralen Repository bearbeitet und ein- und ausgecheckt werden. Die Integration in Git, TFS und anderen Source Code Management Systemen ist ebenfalls möglich.

Sichere Verwaltung der Credentials

Credentials sind für das Ausführen der meisten PowerShell-Scripten unbedingt erforderlich. Mit ScriptRunner können diese Informationen zentral und sicher gespeichert werden. Dafür stehen zum einen der Windows Credential Store auf dem ScriptRunner Server zur Verfügung, zum anderen werden Passwort-Server Lösungen von CyberArk, Pleasant und Delinea unterstützt. Damit managen Sie alle Credentials in einem zentralen Repository, was insbesondere bei der Nutzung von mehreren ScriptRunner-Instanzen die Verwaltung wesentlich vereinfacht.

Keine privilegierten Berechtigungen für Benutzer

Mit ScriptRunner werden Berechtigungen für die Ausführung von PowerShell-Scripten über zentrale Service-Accounts gesteuert. Das heißt, für jedes sog. Target (Exchange, Active Directory, Azure, Office365, VMware, etc.) kommen die jeweils passenden Service-Accounts zum Einsatz. Benutzer (z.B. aus dem Helpdesk-Team), die Scripte starten können sollen, benötigen daher keine speziellen Berechtigungen auf den entsprechenden Targets.

Durch diese Trennung können Aufgaben sicher an Benutzer delegiert werden, die nur Standard Domänen-Benutzer sind.

Sichere Ausführung & zentrales Monitoring

ScriptRunner bietet alle Möglichkeiten zur sicheren Ausführung von PowerShell-Scripts: von der Local Execution über PowerShell-Remoting und speziellen Ausführungsmodi für z.B. JEA stehen vielen Optionen zur Verfügung. Die Ausführung selbst ist auf drei Arten möglich:

1. Manuelles Ausführen durch Benutzer
2. Zeitgesteuerte Ausführung
3. Automatische Ausführung, getriggert durch Drittsysteme wie z.B. Monitoring- oder Workflow-Systeme

Alle Aktivitäten können über das zentrale Dashboard nachvollzogen werden. Wichtige Informationen stehen darüber hinaus im Windows EventLog und über Windows Performance Counter zur Verfügung.

Sichere Delegation

Die bisher beschriebenen Funktionen, ermöglichen es nun schlussendlich Mitarbeitern einzelne Aufgaben sicher und einfach zu delegieren. Sicher, da die Benutzer zur Durchführung der Aufgaben keine besonderen Berechtigungen benötigen. Einfach, da die Mitarbeiter keinerlei PowerShell Know-how benötigen und die Bedienung über eine komfortable Web-Oberfläche erfolgt. Dabei werden die erforderlichen Eingabemasken dynamisch aus dem jeweiligen PowerShell-Script erstellt. D.h. der Aufwand für die Entwicklung einer Benutzeroberfläche entfällt komplett.

So entsteht eine sichere Lösung für den kompletten PowerShell-Lifecycle, von der gemeinsamen Script-Entwicklung bis zur Nutzung durch Helpdesk Teams und End-Anwender.