In diesem Blogartikel lernen Sie das Schalenmodell kennen und erfahren, nach welchem Sicherheitskonzept ScriptRunner funktioniert und wie die Kommunikationsbeziehungen von ScriptRunner in einer typischen Kundenumgebung aussehen. 

Schale für Schale – das Schalenmodell als Sicherheitskonzept

Bevor wir uns im Detail mit den einzelnen Kommunikationsprotokollen und -partnern beschäftigen, lohnt sich ein Blick auf das grundlegende Sicherheitskonzept, welches ScriptRunner abbildet. Ausgangspunkt ist ein Schalenmodell. Im Gegensatz zu gängigen Sichtweisen von Netzwerkabschnitten, Firewalls und VPNs bietet das Schalenmodell den Vorteil, Sicherheitslevel und damit Zonen unabhängig von der konkreten Infrastruktur zu definieren.

Das ScriptRunner Schalenmodell mit drei Sicherheitszonen

In der Abbildung sind drei Sicherheitslevel definiert:

1. Die erste, innere Zone beherbergt die zentralen IT-Ressourcen, z.B. Active Directory, Exchange Server etc. Aus Sicht von ScriptRunner befinden sich in dieser Zone die Zielsysteme. Das notwendige Sicherheitslevel ist hier am höchsten.
2. In einer zweiten Zone befinden sich der ScriptRunner Host und die zentrale PowerShell Codeverwaltung. Das notwendige Sicherheitslevel ist hoch.
3. Die Benutzerzone ist der Bereich, in der sich die Anwender mit ihren Ressourcen befinden. Im Falle von ScriptRunner sind dies Helpdesk-Anwender und Administratoren, welche die Browser Apps anwenden und DevOps, die mit der PowerShell ISE App arbeiten. Das Sicherheitslevel wäre hier bspw. „normal“.

Der Kerngrundsatz in diesem Modell lautet: Eine Kommunikation zwischen zwei Partnern darf nur über eine Schalengrenze hinweg erfolgen. Ein Durchgriff von der Benutzerzone auf die innere Zone ist nicht erlaubt. 

Das bedeutet, eine Kommunikation kann nur zwischen Akteuren benachbarter Schalen stattfinden.

Daraus ergeben sich folgende erlaubte Kommunikationsbeziehungen:

• ein Administrator oder Helpdesk-Mitarbeiter verwendet die Browser-App, um eine PowerShell Aktion in ScriptRunner zu starten.
• ein externes System kann zur Automation ausschließlich über einen Connector in ScriptRunner eine Aktion starten. Der Aufruf durch das Quellsystem wäre der Benutzerzone zuzuordnen.
• ausschließlich der ScriptRunner Host darf PowerShell Scripte auf den Zielsystemen ausführen.

Als Konsequenz daraus ergeben sich wesentliche Vorteile für die gesamte IT-Sicherheit, da nur dieses Modell eine effektive Rechte- und Zugriffstrennung ermöglicht. Ein Helpdesk-Mitarbeiter hat mit seinem User Account nur Zugriff auf die ihm zugewiesenen Aktionen. Die notwendigen Rechte zur Ausführung des Scripts der Aktion auf dem Zielsystem besitzt nur der ScriptRunner Host. Der Anwender ist davon völlig entkoppelt und benötigt deshalb keine Kenntnisse über die administrativen Rechte für die Zielsysteme. Gleiches gilt für aufrufende Systeme, wie Monitoring, ITSM und Workflows.

Das Konzept der Sicherheitsschalen ist um weitere Schalen erweiterbar, bspw. für administrative Zugriffe über das Internet oder aus internetbasierten Monitoring oder ITSM Systemen heraus auf ScriptRunner.

Die Kommunikationspartner

In einer typischen Kundenumgebung sind verschiedene Akteure an der Kommunikation mit ScriptRunner beteiligt. Die Kommunikationspartner sind dabei auf die drei oben genannten Ebenen verteilt:

1. Client in der Benutzerzone
2. ScriptRunner Host in der ScriptRunner Zone
3. Zielsysteme in der Zone zentrale IT-Ressourcen

The ScriptRunner communication relationships

1. Client in der Benutzerzone

Auf dieser Ebene rufen neben Anwendern auch verschiedene Drittsysteme Funktionen in ScriptRunner auf:

• Die Benutzeroberflächen der ScriptRunner Admin und Delegate App sind browserbasiert. Berechtigte Anwender können damit sowohl ScriptRunner administrieren als auch PowerShell Aktionen starten.
• Über die PowerShell ISE lassen sich Befehle ausführen und PowerShell Scripte schreiben. Die ScriptRunner ISE App ermöglicht es DevOps direkt auf das Script-Repository auf dem Host zuzugreifen.
• Darüber hinaus befinden sich auf dieser Ebene die Webservice Clients von Drittanbietern (Monitoring, ITSM, Workflows) und das ScriptRunner Mail Postfach für den Email Inbound Connector.

2. ScriptRunner Host in der ScriptRunner Zone

Auf der ScriptRunner Ebene sind zwei zentrale Komponenten von ScriptRunner dargestellt:

• Als Webserver für die Web Apps dient der Internet Information Server (IIS) von Microsoft, es können aber auch andere Webserver verwendet werden. Die Funktionalität dient ausschließlich dazu, die JavaScript und HTML Dateien der Web Apps an den aufrufenden Browser auszuliefern.
• Das Kernstück von ScriptRunner, der ScriptRunner Host, ist die zentrale Instanz für alle Aktivitäten rund um PowerShell. Er steuert und kontrolliert alle zentralen Funktionen zum Automatisieren, Ausführen, Überwachen, Verwalten und Entwickeln von PowerShell-Scripten. Installiert auf einem Windows Server, überwacht er zudem Lizenzen, Zugriffsrechte und die Host-Konfiguration.

3. Zielsysteme in der Zone zentrale IT-Ressourcen

Auf der Ausführungsebene befinden sich typischerweise die verschiedenen Zielsysteme, auf denen PowerShell Scripte kontrolliert ausgeführt werden sollen, beispielsweise:

• Hyper-V und Windows Server
• Windows Clients
• Exchange Server
• VMWare, Citrix oder weitere
• Office365 Services
• Azure Services
• Anwendungen
• Optional befinden sich auf dieser Ebene aus Sicht von ScriptRunner zwei weitere Systeme:
  • SQL Server für die Reporting/Auditing-Datenbank zur Langzeitspeicherung
  • Mail Server für das Versenden von Reports

Der Kommunikationsablauf

Ein Beispiel soll den gesamten Vorgang illustrieren. Ein Anwender startet die Delegate App und führt eine Aktion in seinem Rollenkontext aus.

Der Web Browser kontaktiert zum Aufrufen der Delegate App den IIS und fordert die Webseiteninhalte an. Der IIS Webserver liefert die angeforderten Inhalte im HTML-, Javascript- und CSS-Format zurück an den Browser. Die Kommunikation erfolgt über die standardisierten Übertragungsprotokolle HTTP und HTTPS, üblicherweise über Port 80 (HTTP) und Port 443 (HTTPS).

Anschließend startet die JavaScript-Anwendung im Browser und kontaktiert den ScriptRunner Host über das Webservice-Interface. Dazu verwendet der Client das Webservice-Protokolle ODATA/REST auf dem Standardport 8091. War die Authentifikation erfolgreich, dann werden die Daten in die Anwendung geladen. In der Delegate App erscheinen die Kacheln, welche dem Benutzer oder der Gruppe zugewiesen worden sind.

Nun kann der Anwender eine Aktion auswählen, die notwendigen Eingaben ausfüllen und die Aktion starten. Dazu sind im zentralen ScriptRunner Repository alle Ausführungsrichtlinien, Zielsysteme, Connectoren, administrative Konten, Rollen und Einstellungen organisiert. Der Host startet nun einen abgeschotteten PowerShell-Prozess im hinterlegten Rechtekontext (Script Policy) mit allen notwendigen Daten und Informationen, kontaktiert das Zielsystem und übermittelt diesem den Auftrag „dieses Script ausführen“. Nachdem die Scripte in der PowerShell auf dem Zielsystem ausgeführt wurden, werden die Ergebnisdaten zurück an den ScriptRunner Host geschickt.

Der ScriptRunner Host überprüft dann das Ergebnis. Ist es korrekt, so wird es an die Anwendung weitergeleitet und der Nutzer wird über die erfolgreiche Ausführung oder einen Fehler informiert.

Die Kommunikation zwischen ScriptRunner Host und Zielsystem ist in erster Linie vom Zielsystem abhängig. Diese kann über das Standard-PowerShell-Protokoll (Port 5985 und 5986), über http/https (Exchange) oder über Managementprotokolle von Produkten diverser Hersteller erfolgen. In diesem Fall erfolgt die Protokollumsetzung im PowerShell-Modul des jeweiligen Produktes.

Für eine fehlerfreie Funktion ist es enorm wichtig, die Kommunikation und den Ablauf des spezifischen Zielsystems zu verstehen und die Konfiguration in ScriptRunner entsprechend anzupassen.