Malambo C/peopleimages.com - sto
Scripting für SAP GUI: zwischen Automatisierung und Risiko
SAP GUI Scripting automatisiert Transaktionen über die offizielle API. Nutzen, Risiko und Kontrollbedarf hängen an Parametern, Rechten und Client-Konfigurationen.
SAP GUI Scripting ist eine Automationsschnittstelle, die Funktionen von SAP GUI for Windows erweitert und GUI-Objekte programmatisch ansprechen kann. Die API kapselt Interaktionen auf Ebene von Fenstern, Sessions, Controls und Events und unterstützt das Aufzeichnen sowie Ausführen makroähnlicher Skripte.
Der SAP-Server verarbeitet die daraus resultierende GUI-Kommunikation wie eine manuelle Bedienung. Ein Skript nutzt daher dieselben Transaktionen, Eingaben, Dialoge und Prüfregeln, die auch bei einer Bedienung per Tastatur und Maus gelten. Diese Architektur koppelt das Risiko strikt an die Berechtigungen des SAP-Benutzers, der das Skript startet, und nicht an eine separate technische Identität der Automationslogik.
Die Gleichbehandlung im Backend liefert eine wichtige Eigenschaft für Tests und Prozessdokumentation. Test-Tools und RPA-Engines reproduzieren reale GUI-Abläufe, statt auf indirekte Schnittstellen auszuweichen. Gleichzeitig erzeugt die gleiche Eigenschaft eine Sicherheitsstufe. Ein Fehler im Skript schreibt Daten ohne zusätzliche Sicherheitsebene in das System, und die hohe Ausführungsgeschwindigkeit vergrößert die Streuung falscher Daten, bevor operative Kontrollen greifen. Unbeaufsichtigte Läufe verschärfen diesen Effekt, da der Mensch als Bremse und Plausibilitätsfilter entfällt.
Serverseitige Aktivierung und Steuerung per Profilparameter
Die serverseitige Freigabe läuft über den Profilparameter sapgui/user_scripting. Die Aktivierung beginnt auf dem Applikationsserver über die Transaktion RZ11. Nach dem Aufruf von RZ11 führt die Eingabe von sapgui/user_scripting zu den Parameterdetails. Der aktuelle Wert muss TRUE sein, sonst blockiert der Server die Scripting-Kommunikation.
Neben dem Basisschalter steuern ergänzende Parameter die tatsächliche Angriffsfläche. sapgui/user_scripting_disable_recording legt fest, ob Aufzeichnung und Playback im Frontend verfügbar bleiben. Ein Wert FALSE hält den Aufzeichnen-Button aktiv, ein Wert TRUE unterbindet das Aufzeichnen. Für Umgebungen, die nur Playback aus kontrollierten Repositories zulassen, liefert diese Trennung eine technische Stellschraube, sofern die Organisation die Skriptherkunft zentral regelt.
Die Einstellung sapgui/user_scripting_force_notification steuert serverseitig, ob Benachrichtigungen bei Script-Attach forciert laufen. FALSE reduziert Interaktionsbarrieren, erhöht aber die Gefahr unbemerkter Anbindung. Der Parameter sapgui/user_scripting_set_readonly setzt eine Scripting-Session auf schreibgeschützte Interaktion, sobald TRUE aktiv ist. Diese Einstellung passt zu lesenden Automationen, die nur navigieren und extrahieren.
In produktiven Systemen reduziert Readonly die Wirkung fehlerhafter Skripte, sofern keine seitlichen Wege über Uploads, Druckpfade oder lokale Dialogautomationen genutzt werden. Mit sapgui/user_scripting_per_user wird eine benutzerspezifische Freigabe erzwungen und die Kontrolle in die Berechtigungsverwaltung verlagert, die in SAP ohnehin den zentralen Steuerungsrahmen bildet. Zusätzlich dient sapgui/nwbc_scripting als Parameter, der auf FALSE stehen soll, wenn nur klassische SAP GUI Automation gewünscht ist. Das senkt Seiteneffekte aus parallelen Scripting-Pfaden im Umfeld anderer Clients.
Berechtigungen, Auditing und technische Verantwortung
Scripting überträgt keine Sonderrechte, es nutzt die Rechte des angemeldeten Benutzers. Daraus folgt: Automationskonten brauchen ein eng gefasstes Rollenprofil, das Transaktionen, Objekte und Tabellenzugriffe begrenzt. Eine breite Rolle oder generische RFC-Rechte erhöhen das Schadenspotenzial. In der Praxis führt dies zu dedizierten Benutzern je Skript oder Prozessdomäne, damit Verantwortliche den Effekt eingrenzen und bei Störungen gezielt sperren können.
Das Betriebsmodell braucht zudem belastbares Auditing. Da SAP-Server Skript und Mensch identisch behandeln, liefern Standard-Logs zunächst keinen Scripting-Indikator. Das erfordert ergänzende Korrelation. Technische Teams koppeln Frontend-Automationen an feste Benutzer, Logon-Gruppen, Applikationsserver und Zeitfenster und gleichen diese Signale mit Workload, Batch-Verhalten und Änderungsprofilen ab.
Client-seitige Aktivierung, Popups und lokale Härtung
Auf Client-Seite steuert SAP GUI die Ausführbarkeit über den Optionenbaum Barrierefreiheit & Scripting und dort Skriptunterstützung. Ein inaktives Feld im Bereich Installation zeigt, ob das Scripting-Feature lokal installiert ist. Erst nach Installation und Aktivierung greift die Option Skriptunterstützung aktivieren.
Zusätzlich existieren zwei sicherheitsrelevante Benachrichtigungsoptionen. Die Option Melden wenn ein Skript eine Verbindung öffnet meldet, wenn ein Skript an SAP GUI anbindet, eine zweite meldet, wenn ein Skript eine Verbindung öffnet. Im Standard erhöhen diese Dialoge die Sichtbarkeit und im Automationsbetrieb blockieren sie unbeaufsichtigte Abläufe, da ein Klick auf Zulassen erforderlich ist.
Die Option Skript-Aufzeichnung und -Playback steht nur dann zur Verfügung, wenn Server und Client Scripting erlauben. Den aktuellen Status zeigt der Scripting-Indikator in den Systeminformationen der SAP GUI. Fehlt dieser Indikator, blockiert meist der Server die Funktion. Der Dialog Aufzeichnen und Playback liefert eine zweite Kontrolle, da der Aufzeichnen-Button nur bei vollständiger Freigabe aktiv bleibt.
SAP GUI kennt zusätzlich eine Einstellung für Windows-Dialogfenster. Dateidialoge wie Öffnen und Sichern unter lassen sich nicht aufzeichnen, daher ersetzt SAP GUI diese Dialoge im Scripting-Fall durch vordefinierte SAP-GUI-Dialoge. Wenn die Option Systemeigene Dialogfenster von Microsoft Windows anzeigen aktiv ist, zeigt SAP GUI die nativen Dialoge und entzieht sie der Scripting-Steuerung. Diese Einstellung begrenzt die Reichweite von Skripten in Pfadoperationen, löst aber kein Sicherheitsproblem, da andere Automationswerkzeuge weiterhin Windows-Dialoge steuern können. Für den Betrieb zählt hier vor allem Vorhersagbarkeit. Native Dialoge variieren je Windows-Version, Sprache, Policies und OneDrive-Redirect, was die Playback-Qualität verschlechtert.
In gehärteten Windows-Umgebungen überschreibt die Registry teils die GUI-Einstellungen. Hier ist der Pfad HKEY_CURRENT_USER\Software\SAP\SAPGUI Front\SAP Frontend Server\Scripting und der Wert UserScripting hilfreich. Diese Ebene spielt eine zentrale Rolle bei VDI, bei Citrix und bei verwalteten Desktops, da zentrale Gruppenlinienobjekte (Group Policy Object, GPO) lokale UI-Entscheidungen aushebeln können. Für Security und Betrieb gilt daher die gleiche Regel wie für Serverparameter.
Änderungen an den GUI-Optionen greifen erst nach einem vollständigen Neustart. Alle SAP GUI-Fenster sowie das SAP Logon Pad müssen geschlossen und neu gestartet werden, damit die Einstellungen konsistent wirken. Für reproduzierbare Läufe spielen Desktop-Einstellungen eine zentrale Rolle. Parallel geöffnete SAP GUI-Instanzen führen zu Session-Verwechslungen und instabiler Objektadressierung. Viele Automations- und Dokumentationswerkzeuge erwarten genau eine aktive Instanz. Zudem muss die SAP GUI vor dem Start des jeweiligen Agents bereits laufen.
Risiken und Auswirkungen auf die Datenqualität
Die größten Risiken ergeben sich nicht durch klassische Sicherheitslücken, sondern durch fehlerhafte Automationen. Skripte können Endlosschleifen ausführen oder Masseneingaben ohne Pausen erzeugen. Das belastet Dialogprozesse, erzeugt Sperren auf Objektebene und triggert Update-Tasks sowie nachgelagerte Verarbeitungen. Eine hohe Ausführungsfrequenz kann Work-Prozesse auslasten, Sperrketten verlängern und Laufzeitgrenzen überschreiten. Tests reduzieren diese Effekte, bilden jedoch reale Produktionslasten nur eingeschränkt ab, da Datenvolumen, Parallelität und zeitliche Spitzen im Test selten identisch sind.
SAP GUI Scripting nutzt dieselben Feldprüfungen wie manuelle Eingaben. Viele fachliche Regeln liegen jedoch außerhalb dieser Prüfungen. Ein Skript kann technisch gültige Werte schreiben und dennoch fachlich falsche Buchungen erzeugen. Durch die hohe Ausführungsgeschwindigkeit verteilt sich ein Fehler schnell über viele Datensätze, bevor Kontrollen greifen. Daraus folgt eine klare Anforderung an den Betrieb. Skripte dürfen nicht unbemerkt starten, und Aufzeichnungen dürfen nicht unkontrolliert erfolgen. Sicherheitsdialoge liefern dafür einen Kontrollpunkt, stehen jedoch unbeaufsichtigten Abläufen im Weg. Werden sie deaktiviert, müssen andere technische Kontrollen greifen, zum Beispiel feste Benutzer, feste Arbeitsplätze und zeitliche Einschränkungen.
Ein zusätzlicher Risikofaktor liegt in SAP-Shortcut-Dateien mit der Endung .sap. Diese Textdateien starten beim Öffnen die SAP GUI und bauen automatisch eine Verbindung zu dem definierten System auf. Manipulierte Dateien können auf fremde Endpunkte verweisen, die das DIAG-Protokoll nachbilden. Der Client verbindet sich dann außerhalb eines Browserkontexts mit einem externen System. Über DIAG-Nachrichten lassen sich client-seitige Aktionen auslösen, bis hin zur Ausführung lokaler Programme, sofern der Benutzer Sicherheitsdialoge bestätigt. Da die Dateien keinen Schadcode enthalten, reagieren Endpoint-Schutzmechanismen oft verzögert.
Technische Gegenmaßnahmen bei Shortcuts und Scripting
Wirksame Gegenmaßnahmen setzen vor der Ausführung an. Mail-Gateways sollten .sap-Anhänge blockieren oder Parameter auf bekannte Zielsysteme und zulässige Domänen prüfen. Auf SAP-Seite gehört die Einschränkung von Shortcut-Nutzung zur Basis-Härtung. Für SAP GUI Scripting bedeutet das eine abgestufte Konfiguration. In produktiven Systemen sollten Shortcuts strikt kontrolliert bleiben, Scripting auf dedizierte Arbeitsplätze beschränkt sein und Benachrichtigungen nur dann entfallen, wenn Ersatzkontrollen existieren. Pauschales Aktivieren oder Deaktivieren reduziert die Sicherheit, eine differenzierte Konfiguration nach Systemrolle und Anwendungsfall erhöht sie.
Systemrollen und Governance
Entwicklungs- und Qualitätssysteme profitieren von Recording, Playback und Automationswerkzeugen. Tests lassen sich reproduzierbar ausführen, Prozesse für Migration und Abnahme lassen sich strukturiert erfassen. Produktivsysteme erfordern eine deutlich strengere Steuerung.
Scripting sollte nur dort aktiv bleiben, wo ein klarer fachlicher Bedarf existiert, der sich nicht über andere Schnittstellen abdecken lässt. Die Nutzung erfolgt dann über dedizierte Benutzer, von definierten Arbeitsplätzen oder Jump Hosts und mit schreibgeschützten Modi, sofern der Anwendungsfall das zulässt. Unbeaufsichtigte Läufe gehören in die Qualitätssicherung/Testumgebung, nicht in die Produktion.
Betriebliches Modell für Skripte
Ob SAP GUI Scripting hilfreich ist oder Probleme verursacht, hängt allein davon ab, wie es im Betrieb eingesetzt und kontrolliert wird. Skripte gehören in ein zentrales Repository mit Versionierung, Review und Freigabe. Der Ausführungskontext benötigt feste Rahmenbedingungen, darunter definierte SAP GUI Versionen, Themes, DPI-Einstellungen und Add-ons.
Skripte, die lokal auf einzelnen Rechnern liegen, lassen sich kaum überwachen oder gezielt sperren. Besser funktioniert ein zentraler Ansatz. Skripte liegen dabei in festen Verzeichnissen, werden versioniert verteilt und nur aus definierten Pfaden ausgeführt. Sicherheitswerkzeuge können diese Pfade überwachen und Veränderungen erkennen. Auf diese Weise bleibt nachvollziehbar, welches Skript wo läuft und welche Auswirkungen es hat.
