Haben Sie Fragen?
Rufen Sie uns einfach an:
040 696985 - 0

Abfragen zum Thema RFC-Callback in CheckAud®

Der Remote Function Call (RFC) bietet viele verschiedene Einsatzmöglichkeiten. Daten können in ein SAP-System hinein- oder heraustransportiert werden und so in nahezu jedem beliebigen Umfeld verfügbar gemacht werden. Ein wesentlicher Sicherheitsaspekt beim Einsatz von RFC-Verbindungen ist die Vorgabe, RFC-Verbindungen nur „bergauf“ d. h. von einem System mit niedrigerem in Systeme mit höherem Sicherheitsstandard zu vermeiden, also z. B. von einem Entwicklungs- in ein Produktivsystem. Teilweise wird dies allerdings benötigt, wie etwa im Transportumfeld. Damit ist im Allgemeinen gewährleistet, dass keine unautorisierten Datenzugriffe über RFC-Schnittstellen auf sensible Systeme stattfinden können.
Über die Callback-Funktionalität kann allerdings die Zugriffsrichtung innerhalb einer vordefinierten Schnittstelle umgekehrt werden, und somit sind Datenzugriffe „bergauf“ möglich, obwohl die genutzte Schnittstelle eigentlich „bergab“ definiert wurde.

1.1 Funktionalität von RFC-Callback

Im Quellcode eines Funktionsbausteins kann eine Anweisung CALL FUNCTION <function> DESTINATION “BACK” eingesetzt werden, über die der Aufruf eines weiteren Funktionsbausteins entgegen der vordefinierten Schnittstellenrichtung abgesetzt werden kann. Wird der Funktionsbaustein mit der Callback-Funktionalität anschließend über eine RFC-Verbindung aufgerufen (beispielsweise über eine Schnittstelle von einem P- zu einem E-System), so kann der hier hinterlegte Callback-Funktionsbaustein in umgekehrter Richtung (also von dem E-System aus im P-System) aufgerufen werden. Die Berechtigungsprüfungen im ursprünglichen Start- und jetzigen Zielsystem findet über den Benutzer statt, der dort auf die RFC-Schnittstelle zugegriffen hatte. Über entsprechend manipulierte SAP Standardfunktionsbausteine oder Eigenentwicklungen sind also theoretisch beliebige Manipulationen im Startsystem möglich. Dies ist besonders in S/4 HANA Systemen interessant, da hier die Entwicklungsumgebung nicht mehr durch Entwickler- oder Objektschlüssel abgesichert ist. Somit sind hier evtl. unautorisierte Entwicklertätigkeiten wahrscheinlicher.

1.2 Schutz gegen unautorisierte Callback-Zugriffe

Generell kann über Callback-Positivlisten vorgegeben werden, in welchen Verbindungen, beim Aufruf welcher Funktionsbausteine welche anderen Callback-Funktionsbausteine in umgekehrter Richtung aufgerufen werden dürfen.

Die Pflege der Positivlisten für die einzelnen Schnittstellen findet über die Transaktion SM59 jeweils auf dem Register Logon-Daten statt, hier ist auch hinterlegt, ob diese Positivliste aktiviert ist. (siehe Abb.1).

Abb. 1: Callback-Positivliste pro Schnittstelle

Diese Informationen können auch schnittstellenübergreifend ausgewertet werden. Die definierten Positivlisten sind in der Tabelle RFCCBWHITELIST nachzuvollziehen. (siehe Abb.2).

Abb. 2: Callback-Positivliste, schnittstelleübergreifend: Inhalte

 

Ob diese auch aktiviert sind, steht in der Tabelle RFCCBWHITELIST_A (siehe Abb.3).

Abb. 3: Callback-Positivliste, schnittstelleübergreifend: Aktivierung

Ob überhaupt oder in welcher Art und Weise Positivlisten benötigt oder genutzt werden, wird über den Systemparameter rfc/callback_security_method gesteuert. Hier sind Werte von 0 (grundsätzlich werden alle RFC-Callbacks erlaubt) bis 3 (es werden nur Callbacks zugelassen, die in Positivlisten definiert sind, egal ob diese aktiviert sind oder nicht) möglich. In neueren Releaseständen setzt SAP diesen Parameter als Vorgabe auf den Wert 3 (siehe SAP Hinweis 2926224 – Collection Note: New security settings for S/4HANA using SL Toolset and SUM).

 

Wie dieser Parameter eingestellt ist, wird auch im Einstiegsbild der Transaktion SM59 angezeigt. Das Ampelsymbol wird nur beim Parameterwert 3 in folgender Weise als sicher dargestellt (siehe Abb.4):

Abb. 4: Darstellung: Aktueller Wert des Parameters rfc/callback_security_method

1.3 Unterstützung bei der Konfiguration

Über das AuditLog können Callback-Aufrufe mit den benötigten Randinformationen aufgezeichnet werden. Diese haben Meldungs-IDs DUI, DUJ und DUK (siehe Abb.5).

Abb. 5: Darstellung: Aktueller Wert des Parameters rfc/callback_security_method

 

Hilfreich ist in diesem Zusammenhang ist evtl. auch der Simulationsmodus des Parameters rfc/callback_security_method (Wert 2).

 

Wurden diese Informationen ausreichend lang aufgezeichnet, so lassen sich zentral für alle betroffenen Schnittstellen die Positivlisten in der Transaktion SM59 erstellen (siehe Abb.6).

Abb. 6: Zentrale Erstellung der Positivlisten, Aufruf

 

Nach der Definition des Auswertezeitraums der oben erwähnten Meldungen aus dem AuditLog werden die betroffen Inhalte des Protokolls zur Übernahme in die Positivlisten der jeweiligen Schnittstellen aufgelistet. Hier können Sie evtl. reduziert und anschließend übernommen werden (siehe Abb.7).

Abb. 7: Zentrale Erstellung der Positivlisten, Übernahme

 

2. Zukünftige Umsetzung in CheckAud®

In dem Thema RFC wird es in dem Kapitel „RFC-Sicherheit“ einen eigenen Unterordner „RFC Callback“ geben. Hier werden sowohl die aktuelle Einstellung des Parameters rfc/callback_security_method (Vorgabewert 3), als auch die vorhandenen Positivlisten und deren Aktivierungseinstellung analysiert (siehe Abb.8).

Abb. 8: Zukünftige Abfragen zum Thema RFC Callback in CheckAud®

 

Diese Änderung ist für die Version 2021.2 geplant, die im September 2021 veröffentlicht wird.

IBS Schreiber GmbH

Anschrift
Zirkusweg 1
20359 Hamburg

+49 40 6969 85-0
+49 40 6969 85-31
info@ibs-schreiber.de

Audit & Consulting