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.
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:
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:
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.
In einer typischen Kundenumgebung sind verschiedene Akteure an der Kommunikation mit ScriptRunner beteiligt. Die Kommunikationspartner sind dabei auf die drei oben genannten Ebenen verteilt:
The ScriptRunner communication relationships
Auf dieser Ebene rufen neben Anwendern auch verschiedene Drittsysteme Funktionen in ScriptRunner auf:
Auf der ScriptRunner Ebene sind zwei zentrale Komponenten von ScriptRunner dargestellt:
Auf der Ausführungsebene befinden sich typischerweise die verschiedenen Zielsysteme, auf denen PowerShell Scripte kontrolliert ausgeführt werden sollen, beispielsweise:
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.