Die Prüfung von RFC-Verbindungen in einem ABAP-System ist ein altes aber weiterhin aktuelles und sicherheitsrelevantes Thema. Während in der Vergangenheit hier der Fokus auf Verbindungen vom Typ 3 oder L lag (RFC-Verbindungen zum Aufruf von Funktionsbausteinen im Zielsystem), wird in diesem Artikel gezeigt, dass auch Verbindungen vom Typ H zum Aufruf von HTTP-Services zu unautorisierten Datenzugriffen führen kann, und dies umso mehr, da in S/4 HANA-Systemen über den Einsatz von Fiori-Apps immer mehr auf der HTTP-Kommunikation basierende Funktionen zum Einsatz kommen.
HTTP-Services in der Transaktion SICF
Die Services werden über die Transaktion SICF im Zielsystem aktiviert und allgemein administriert. Von hier lassen sich mit den entsprechenden Berechtigungen die einzelnen Services auch direkt starten (siehe Abb. 1), das Ergebnis ist in Abb. 2 zu sehen.
Konfigurationen im Startsystem
In der Transaktion SM59 werden in einem Startsystem entsprechende RFC-Verbindungen vom Typ H angelegt. Neben den Zielsystem-Daten (ermittelbar über TA SMICM SPRINGEN – SERVICES im Zielsystem) kann hier ein Pfadpräfix gesetzt werden (siehe Abb. 3), das später bei jedem Aufruf eines Services über diese Schnittstelle automatisch vor den Aufrufpfad gesetzt wird. Damit wird also grundsätzlich der Funktionsumfang dieser Schnittstelle auf die später benötigten Services eingeschränkt.
Die Eingabe eines möglichst kleinen Ausschnitts aus der Service-Hierarchie im Feld Pfadpräfix trägt also wesentlich zur Härtung dieser Schnittstelle bei.
Auf dem Register „Anmeldung & Sicherheit“ werden in gewohnter Weise beispielsweise Benutzername und Kennwort hinterlegt (siehe Abb. 4):
Im Gegensatz zur Nutzung von Funktionsbausteinen, kann hier im Startsystem kein Service direkt gestartet und dadurch im Zielsystem remote ausgeführt werden. Es muss in irgendeiner Form Programmlogik vorhanden sein, um den gewünschten Service über die definierte Schnittstelle zu nutzen. „Dank“ KI stellt dies aber heutzutage keine große Herausforderung dar.
In diesem Fall wurde ein kleines ABAP-Programm erstellt, das über den bereits im Zielsystem direkt getesteten Service „info“ und über die zuvor definierte Schnittstelle aus dem Zielsystem die Systemdaten ausliest und aufbereitet darstellt (dies ist nur ein harmloses Beispiel 😊).
Konfigurationen im Zielsystem
Damit Services im Zielsystem gestartet werden können, müssen diese aktiviert sein. dies lässt sich beispielsweise über die Tabelle ICFSERVLOC feststellen (siehe Abb. 5).
Weiterhin muss der Schnittstellenbenutzer über das Berechtigungsobjekt S_SERVICE oder S_START auf diese Services berechtigt sein. Die benötigte Berechtigung ist abhängig von der Art des Services, so wird beispielsweise zur Ausführung eines OData-Services vom Typ V.2 das Objekt S_SERVICE, und für OData Services vom Typ V.4 das Objekt S_START benötigt.
Fazit
Die klassischen Methoden um von außen kommend Funktionen remote in einem Zielsystem auszuführen, sind Funktionsbausteine und HTTP-Services. Beides Objektarten können über Schnittstellen mit hinterlegten Anmeldeinformationen aus einem Startsystem heraus ausgeführt werden.
Generell gilt, dass in einem Produktivsystem die Berechtigungen auf den Objekten S_RFC (remote-Aufruf von Funktionsbausteinen) und S_START/ S_SERVICE (Aufruf von HTTP-Services) nur restriktiv zu vergeben sind.
Darüber hinaus sollten in einem Produktivsystem nur benötigte HTTP-Services aktiviert sein.
RFC-Verbindungen vom Typ H aus unsicheren Startsystemen heraus mit hinterlegten Anmeldeinformationen auf sensible Zielsystem zeigend sind möglichst zu vermeiden, zumindest aber über das Pfadpräfix (und natürlich über die Berechtigungen des Schnittstellenbenutzers) stark einzuschränken.