SAP RFC-Schnittstellen sicher einrichten

Eine der meisten und gleichzeitig auch gravierendsten Sicherheitslücken in der Kommunikation zwischen und innerhalb von SAP-Systemen sind überberechtigte RFC-Schnittstellenbenutzer.

Aufgrund von historisch gewachsenen Schnittstellen-Architekturen sowie Entwicklung ohne definiertes Konzept, aber auch der schnellen Umsetzung von Geschäftsanforderungen stellen sie ein Risiko von innen und außen für Ihre Systeme dar. Oft existiert nur eine kleine Anzahl von SAP Usern, welche in einer Vielzahl von RFC-Verbindungen hinterlegt sind, diverse Szenarien abdecken und ohne klares Konzept meistens direkt mit dem Standardprofil „SAP_ALL“ ausgestattet sind.

In diesem Artikel erfahren Sie, was RFC-Schnittstellen sind, welche Verbindungstypen es gibt und wie Sie Ihre RFC-Schnittstellenarchitektur bei Sicherheitsrisiken analysieren und optimieren.

Was sind SAP RFC-Schnittstellen?

SAP RFC-Schnittstellen ermöglichen die Kommunikation zwischen SAP-Systemen bzw. -Anwendungen und Nicht-SAP-Systemen bzw. -Anwendungen.

Der Remote Function Call (RFC) beschreibt dabei den Aufruf von Funktionsbausteinen, die auf einem entfernten System ausgeführt werden. Neben dieser Hauptfunktion ist der RFC ein elementarer Baustein für weitere Technologien, wie IDoc-Verarbeitung, ALE oder BAPIs.

Funktionsweise der RFC-Kommunikation

Die RFC-Schnittstelle basiert auf einem Client-Server-Modell: Das aufrufende System (Client) sendet eine Anfrage an das Zielsystem (Server), wo der angesprochene Funktionsbaustein ausgeführt wird. Die Ergebnisse werden anschließend an den Client zurückgegeben.

Innerhalb von ABAP-Programmen erfolgt der Aufruf über die Anweisung „CALL FUNCTION … DESTINATION“. Der Parameter „DESTINATION“ verweist dabei auf eine in der Transaktion SM59 gepflegte RFC-Verbindung und teilt dem System mit, dass der Funktionsbaustein auf einem entfernten System ausgeführt werden soll.

Hinweis!

Trusted vs. Untrusted RFC

Bei RFC-Verbindungen unterscheidet SAP zwischen 2 Vertrauensmodellen:

  • Untrusted RFC: Das Standardverfahren – der Benutzer muss sich am Zielsystem mit Benutzername und Passwort authentifizieren. Die Anmeldedaten werden in der RFC-Destination hinterlegt.
  • Trusted RFC: Das aufrufende System ist als vertrauenswürdig eingestuft. Der User kann sich am Zielsystem anmelden, ohne erneut ein Passwort eingeben zu müssen. Dies erfordert eine entsprechende Konfiguration in der Transaktion SMT1.

Trusted-Verbindungen reduzieren den administrativen Aufwand, erfordern jedoch ein erhöhtes Sicherheitsbewusstsein, denn ein kompromittiertes vertrauenswürdiges System könnte unbefugten Zugriff auf alle verbundenen Zielsysteme bereitstellen.

RFC-Typen im Überblick

SAP stellt 5 verschiedene RFC-Typen bereit, die sich in ihrer Verarbeitungsweise und ihrem Einsatzzweck unterscheiden. Die Wahl des richtigen Typs hängt davon ab, ob Sie eine sofortige Rückmeldung benötigen, Daten transaktionssicher übertragen möchten oder Lastspitzen im System vermeiden wollen.

Vergleich der 5 RFC-Typen

RFC-Typ

Bezeichnung

Verarbeitung

Typischer Einsatz

sRFC

Synchroner RFC

Sofort, mit Warten auf Antwort

Echtzeit-Abfragen, Stammdatenprüfung

aRFC

Asynchroner RFC

Sofort, ohne Warten auf Antwort

Parallele Verarbeitung, Performance-Optimierung

tRFC

Transaktionaler RFC

Genau einmal, transaktionssicher

Kritische Buchungen, IDoc-Verarbeitung

qRFC

Queue RFC

Reihenfolgegesichert über Queues

Abhängige Transaktionen, Serialisierung

bgRFC

Background RFC

Modernisierte Variante von tRFC/qRFC

Empfohlener Standard ab SAP NetWeaver 7.0

sRFC – Synchroner RFC

Der sRFC ist die Standardvariante: Das aufrufende System wartet, bis der Funktionsbaustein auf dem Zielsystem vollständig ausgeführt wurde. Sie erhalten eine sofortige Rückmeldung, allerdings ist das Programm bis zum Eintreffen der Antwort blockiert.

aRFC – Asynchroner RFC

Beim aRFC setzt das aufrufende System seine Verarbeitung unmittelbar fort, ohne auf eine Antwort zu warten. Dies ermöglicht parallele Verarbeitung, erfordert jedoch eine komplexere Programmierung für die Ergebnisverarbeitung.

tRFC – Transaktionaler RFC

Der tRFC garantiert, dass ein Funktionsbaustein genau einmal ausgeführt wird – auch bei Verbindungsabbrüchen. SAP speichert den Aufruf in einer Transaktions-ID (TID) und wiederholt ihn bei Bedarf automatisch. Die IDoc-Verarbeitung basiert intern auf diesem Mechanismus.

qRFC – Queue RFC

Der qRFC erweitert den tRFC um eine Reihenfolgegarantie: Alle Aufrufe in derselben Queue werden auf dem Zielsystem in exakt der gesendeten Reihenfolge verarbeitet. Ideal für Szenarien, in denen Belege aufeinander aufbauen.

bgRFC – Background RFC

Der bgRFC ist die modernste Variante und ersetzt seit SAP NetWeaver 7.0 die klassischen tRFC- und qRFC-Mechanismen. Er bietet bessere Performance, vereinfachtes Monitoring (Transaktion SBGRFCMON) und effizientere Ressourcennutzung.

Welchen RFC-Typ sollten Sie verwenden?

Die Wahl des passenden RFC-Typs richtet sich nach Ihren Anforderungen:

Anforderung

Empfohlener RFC-Typ

Sofortige Antwort erforderlich

sRFC

Parallele Verarbeitung ohne Warten

aRFC

Garantierte Einmalausführung

tRFC oder bgRFC

Reihenfolge muss gewahrt bleiben

qRFC oder bgRFC

Neue Entwicklung ab NetWeaver 7.0

bgRFC

  Für die meisten modernen Integrationsszenarien ist der bgRFC die beste Wahl, da er die Vorteile von tRFC und qRFC vereint und gleichzeitig eine bessere Performance bietet. Das wird auch so von SAP empfohlen.

Sie benötigen Hilfe bei Ihrem RFC-Schnittstellenmanagement?

Unsere Experten freuen sich schon darauf, Ihr Problem zuverlässig lösen zu dürfen!

Wie richten Sie RFC-Verbindungen ein? (SM59)

Mit der Transaktion SM59 verwalten Sie alle RFC-Verbindungen in Ihrem SAP-System. Hier definieren Sie die technischen Parameter, Anmeldedaten und Verbindungseinstellungen für die Kommunikation mit Zielsystemen.

Verbindungstypen in der SM59

Die SM59 unterscheidet verschiedene Verbindungstypen, die sich nach der Art des Zielsystems richten:

Verbindungstyp

Beschreibung

Beispiel

Typ 3 – ABAP-Verbindung

Verbindung zu einem anderen SAP ABAP-System

ERP → BW, ERP → SRM

Typ H – HTTP-Verbindung

Verbindung über HTTP/HTTPS

Webservices, REST-APIs

Typ T – TCP/IP-Verbindung

Verbindung zu externen Programmen

RFC-Server, SAP GUI

Typ G – HTTP-Verbindung zu externem Server

Verbindung zu externen HTTP-Diensten

Cloud-Anwendungen

Für die Kommunikation zwischen SAP-Systemen ist Typ 3 (ABAP-Verbindung) der am häufigsten verwendete Verbindungstyp. Die Einrichtung einer ABAP-Schnittstelle schauen wir uns nun Schritt für Schritt an.

In 7 Schritten eine SAP ABAP RFC‑Verbindung anlegen

So legen Sie eine neue RFC-Verbindung vom Typ 3 an:

  1. SM59 aufrufen: Starten Sie die Transaktion SM59.

  2. Verbindung erstellen: Klicken Sie auf „Anlegen“ oder drücken Sie die Funktionstaste F5.

  3. RFC-Destination benennen: Vergeben Sie einen eindeutigen Namen. Bewährt hat sich eine Namenskonvention wie <SID>CLNT<Mandant> (z. B. ERPCLNT100).

  4. Verbindungstyp wählen: Wählen Sie „3 – Verbindung zu ABAP-System“.

  5. Technische Einstellungen: Tragen Sie im Reiter „Technische Einstellungen“ den Zielhost und die Instanznummer ein.

  6. Anmeldedaten hinterlegen: Im Reiter „Anmeldung & Sicherheit“ geben Sie Mandant, Benutzer, Passwort und Sprache an.

  7. Verbindung testen: Über die Schaltfläche „Verbindungstest“ prüfen Sie, ob die Verbindung erfolgreich hergestellt werden kann.

Hinweis!

Diagramm der RFC-Kommunikation zwischen SAP System A und System B: Darstellung der RFC-Destination, Berechtigungsobjekte S_ICF und S_RFC sowie des Funktionsbausteins RFCPING im technischen Ablauf.
Abb. 1: RFC-Kommunikation und Berechtigungsüberprüfung

Schon gewusst?

All Ihre RFC-Verbindungen werden technisch in der Datenbanktabelle RFCDES gespeichert. Über die Transaktion SE16 können Sie diese Tabelle direkt abfragen, was nützlich für Dokumentationen oder systemübergreifende Analysen ist.

Sicherheitsrisiken bei RFC-Schnittstellen

RFC-Schnittstellen zählen zu den häufigsten und gleichzeitig gravierendsten Sicherheitslücken in SAP-Systemlandschaften. Das Hauptproblem sind dabei überberechtigte RFC-Schnittstellenbenutzer, die durch historisch gewachsene Architekturen, fehlende Konzepte oder den Druck schneller Projektumsetzungen entstanden sind.

In vielen Unternehmen existiert nur eine kleine Anzahl von RFC-Benutzern, die in einer Vielzahl von RFC-Verbindungen hinterlegt sind. Diese Benutzer decken unterschiedlichste Szenarien ab – von BW-Extraktion über Solution-Manager-Monitoring bis zur zentralen Benutzerverwaltung. Ohne ein klares Berechtigungskonzept werden sie häufig mit dem Standardprofil SAP_ALL ausgestattet.

Die Folgen der Überberechtigung sind systemkritisch:

Risiko

Auswirkung

Vollzugriff auf alle Funktionsbausteine

Sämtliche Geschäftsdaten können gelesen und manipuliert werden

Keine Nachvollziehbarkeit

Aktionen erfolgen über anonymisierte technische Benutzer

Laterale Bewegung

Ein kompromittiertes System ermöglicht Zugriff auf alle verbundenen Systeme

Compliance-Verstöße

Revisionssichere Nachweise sind nicht möglich

Bei einem Cyberangriff auf einen überberechtigten RFC-Benutzer muss der Täter seine Spuren nicht einmal verwischen. Die Manipulationen erfolgen über technische Benutzer und sind im Nachhinein kaum einer realen Person zuzuordnen.

Info: Das Berechtigungsobjekt S_RFC

Ob ein RFC-Schnittstellenbenutzer einen bestimmten Funktionsbaustein ausführen darf, entscheidet das Berechtigungsobjekt S_RFC auf dem Zielsystem. Es prüft, welche Funktionsgruppen oder einzelnen Funktionsbausteine ein Benutzer aufrufen kann.

Das Problem: Wird S_RFC mit Stern-Berechtigung (*) vergeben, kann der Benutzer sämtliche RFC-fähigen Funktionsbausteine im System ausführen. In Kombination mit weiteren kritischen Berechtigungen entstehen so große Sicherheitslücken in Ihrer SAP-Landschaft.

Typische Schwachstellen in der Praxis

Bei der Analyse von RFC-Architekturen begegnen uns regelmäßig folgende Schwachstellen:

 

Schwachstelle Risiko
Generische Benutzer (z. B. DDIC, SAPCPIC) In mehreren Systemen hinterlegt, kaum mit maßgeschneiderten Rollen zu berechtigen

Kein Einsatzkonzept

Benutzer werden für verschiedene Szenarien wiederverwendet

Fehlende Namenskonvention

Einsatzzweck nicht erkennbar, Dokumentation unmöglich

Falscher Benutzertyp

Dialoganmeldung möglich, obwohl nur RFC-Zugriff vorgesehen
Veraltete Verbindungen Nicht mehr benötigte Destinationen bleiben aktiv

Wir zeigen Ihnen nun, wie Sie Ihre SAP RFC-Schnittstellen analysieren und optimieren können, damit Ihr System sicher bleibt bzw. wird.

RFC-Schnittstellen analysieren

Bevor Sie Sicherheitslücken schließen können, müssen Sie den Ist-Zustand Ihrer RFC-Architektur kennen. Eine systematische Analyse zeigt Ihnen, welche Verbindungen existieren, welche Benutzer hinterlegt sind und wo Handlungsbedarf besteht. Dabei sollten Sie folgende Faktoren analysieren:

  • Systeme und Mandanten der SAP-Landschaft
  • Aktive RFC-Schnittstellenbenutzer
  • Aufgerufene Funktionsbausteine pro RFC-Schnittstellenbenutzer
  • Anzahl der RFC-Destinationen
  • Aktive RFC-Szenarien (z. B. Solman-Monitoring, Zentrale Benutzerverwaltung, BW-Extraktion etc.)

Schon gewusst?

Mit der Xiting Authorizations Management Suite (XAMS) können Sie die nötigen RFC-Analysen effizient und zentralisiert durchführen. Das spart Zeit, reduziert die Ressourcenbindung und minimiert Ihre Kosten.

Client- vs. serverseitige Analyse

Bei der RFC-Analyse unterscheiden wir zwischen 2 Perspektiven, der clientseitigen und der serverseitigen Analyse:

 

 

Perspektive

Fragestellung

Datenquelle

Clientseitig

Welche RFC-Verbindungen sind in meinem System konfiguriert?

Transaktion SM59, Tabelle RFCDES

Serverseitig

Welche Systeme haben RFC-Funktionsbausteine auf meinem System aufgerufen?

ST03N-Statistikdaten

→ Die clientseitige Analyse liefert Ihnen das Fundament. Sie erfahren, welche Verbindungen zwischen Ihren SAP-Systemen bestehen.

→ Die serverseitige Analyse ergänzt dieses Bild um Informationen darüber, welche Funktionsbausteine tatsächlich aufgerufen wurden und von welchen Systemen die Aufrufe stammen.

Clientseitige Analyse mit RSRFCCHK

Die Transaktion RSRFCCHK (bzw. der gleichnamige Report) steht auf jedem SAP NetWeaver AS ABAP zur Verfügung. Sie stellt die Verbindungsinformationen aus der SM59 in einer auswertbaren Form dar und ermöglicht einen direkten Verbindungstest.

So nutzen Sie RSRFCCHK:

  1. Starten Sie die Transaktion RSRFCCHK oder führen Sie den Report über SE38 aus.
  1. Wählen Sie die gewünschten Verbindungstypen und Selektionskriterien.
  1. Aktivieren Sie optional den Verbindungstest.
  1. Führen Sie den Report aus.

→ Als Ergebnis erhalten Sie eine Übersicht aller RFC-Destinationen inklusive der hinterlegten Benutzer, Zielsysteme und Verbindungsstatus. Ungültige Verbindungen erkennen Sie sofort und können diese zur Bereinigung vormerken.

SAP‑Maske für RFC‑Verbindungen mit Anmeldedaten: Eingabefelder für RFC‑Destination, Verbindungstyp, Optionen zur Passwortprüfung sowie Einstellungen für den Verbindungstest inklusive maximaler Testdauer.
Abb. 2: RSRFCCHK – Auswahlbildschirm

Hinweis!

Serverseitige Analyse mit ST03N

Mit den Statistikdaten aus der Transaktion ST03N analysieren Sie, welche Funktionsbausteine auf Ihrem System aufgerufen wurden. Diese Perspektive zeigt Ihnen auch Zugriffe von Systemen außerhalb Ihrer SAP-Landschaft – etwa von Java-Anwendungen oder externen Partnern.

So führen Sie die Analyse mit ST03N durch:

  1. Starten Sie die Transaktion ST03N.
  1. Wählen Sie im linken Bereich einen Zeitraum für die totale Systemlast (monatsweise).
  1. Navigieren Sie zum RFC-Serverprofil.
  1. Filtern Sie im Reiter „Anwender“ nach technischen Benutzern.
Screenshot der SAP RFC-Serverstatistik: Tabelle mit RFC-Anwendern, Anzahl der Aufrufe, Ausführungszeiten, durchschnittlichen RFC-Zeiten sowie gesendeten und empfangenen Datenmengen
Abb. 3: ST03N – RFC-Server-Statistik: Anwender

→ Per Doppelklick auf einen Benutzernamen sehen Sie in der Detailansicht, welche Funktionsgruppen von welchem System aufgerufen wurden. So validieren Sie, ob die tatsächliche Nutzung zum angedachten Szenario passt.

Screenshot der SAP RFC-Serverstatistik mit gefilterten Aufrufen des Anwenders BGRFC_SUPER: Anzeige von Reportnamen, RFC-Destinationen, RFC-Benutzern, Servernamen sowie Remote-Servernamen und RFC-Programmnamen inklusive Anzahl der Aufrufe.
Abb. 4: ST03N – RFC-Server-Statistik: Anwender-Details

Im Reiter „Remote Server“ können Sie außerdem alle Clients einsehen, die mit Ihrem System kommuniziert haben. Durch einen Abgleich mit der clientseitigen Analyse erkennen Sie schnell, ob auch unbekannte Systeme auf Ihre Funktionsbausteine zugreifen.

Screenshot der SAP RFC-Serverstatistik: Tabelle mit Remote-Servern, Anzahl der RFC-Aufrufe, Ausführungszeiten, durchschnittlichen RFC-Zeiten sowie übertragenen gesendeten und empfangenen Datenmengen.
Abb. 5: ST03N – RFC-Server-Statistik: Remote Server

Im Reiter „Remote Server“ können Sie außerdem alle Clients einsehen, die mit Ihrem System kommuniziert haben. Durch einen Abgleich mit der clientseitigen Analyse erkennen Sie schnell, ob auch unbekannte Systeme auf Ihre Funktionsbausteine zugreifen.

RFC Freeware Tool von Xiting nutzen

Mit unserem Freeware Tool Xiting RFC Stocktake kann eine solche Analyse ebenfalls durchgeführt werden. Auch hier können Sie wieder mit einem sogenannten Zentralmodus arbeiten und somit per Knopfdruck Ihre komplette SAP-Systemlandschaft auswerten.

Das spart in größeren Landschaften erheblichen Aufwand und eliminiert Dokumentationsfehler. Des Weiteren kann der Xiting RFC Stocktake den gesamten Zeitraum – statt nur einzelne Monate – der Statistikdaten auswerten und „SAP_ALL“-Zuweisungen sofort farblich hervorheben.

Screenshot des SAP-Programms /XITING/RFC_STOCKTAKE mit einer Übersicht über 195 RFC‑Verbindungen im System S4T Mandant 100, inklusive Kennzahlen zu RFC‑Benutzern, Vertrauensstellungen, Dumps und einer Tabelle mit Rollen, Profilen und RFC‑Berechtigungen der RFC‑Serverbenutzer.
Abb. 6: Xiting RFC Stocktaker

Optimierung der SAP RFC-Verbindungen

Abschließend können Sie die analysierten Schwachstellen der RFC-Architektur bereinigen und somit die kritischen Sicherheitslücken schließen.

Hierfür hat sich über die Jahre hinweg ein Best-Practice-Ansatz etabliert, an dem Sie sich orientieren können:

Zunächst sollten Sie generische Nutzer, wie z. B. DDIC oder SAPCPIC, durch dedizierte Benutzer austauschen. Falls Sie generische User verwenden, sind diese oft in mehreren aufrufenden Systemen hinterlegt und somit nur schwierig mit maßgeschneiderten Rollen zu berechtigen.

Wie viele neue Benutzer Sie letztendlich erstellen und welche Architektur Sie dabei nutzen sollten, zeigen Ihnen die folgenden Richtlinien:

  • RFC-Schnittstellenbenutzer einführen, welche ein RFC-Szenario abdecken. Eine sinnvolle Namenskonvention ist dabei „RFC_<Szenario-Name>“.
  • RFC-Schnittstellenbenutzer einführen, welche nach aufrufendem System getrennt sind. Eine sinnvolle Namenskonvention ist dabei „RFC_<SID>“.
  • Die beiden genannten Ansätze können auch kombiniert werden. Dabei werden User am besten „RFC_<SID>_<Szenario-Name>“ genannt.

Nach dem Erstellen der Benutzer auf dem Server müssen Sie diese in den zugehörigen Destinationen auf dem Client eintragen.

Mit dieser Auftrennung haben Sie für die Zukunft sichergestellt, dass Sie zum einen nur das berechtigen, was ein aufrufendes System oder Szenario benötigt. Zum anderen haben Sie stets schon anhand des Benutzernamens den Einsatzzweck dokumentiert. Somit werden Ihre Schnittstellenbenutzer im besten Fall nicht mehr überberechtigt und zweckentfremdete Benutzer können schnell identifiziert werden.

Fazit

Ja, die Optimierung Ihrer RFC-Schnittstellenarchitektur ist technisch und organisatorisch anspruchsvoll. Dennoch ist sie notwendig, weil sie eine der gravierendsten Sicherheitslücken schließt und deshalb ein zwingend notwendiger Schritt für revisionssichere Systemlandschaften ist. 

RFC-Verbindungen betreffen die gesamte SAP-Systemlandschaft und Mängel an den Schnittstellen können wirtschaftlichen Schaden anrichten. Unsere Xiting Authorizations Management Suite nimmt Ihnen einen erheblichen Teil des Aufwands ab, damit Sie den Prozess sicher, einfach und dokumentierbar umsetzen können. Des Weiteren helfen unsere Tools „Xiting RFC Stocktake“ und „RFC Monitoring Tool“, ein anschließendes Berechtigungs-Redesign der technischen Benutzer nach dem „Need-to-know“-Prinzip durchzuführen.

>> So haben wir das RFC-Schnittstellenproblem bei Audi gelöst!

Sie benötigen Unterstützung bei Ihrem RFC-Schnittstellenmanagement? Mit unserem etablierten Service „Berechtigungsoptimierung der RFC-Schnittstellenbenutzer“ bekommen Sie eine vollumfängliche Unterstützung und Beratung bei der RFC-Bereinigung. Melden Sie sich noch heute kostenlos und unverbindlich bei uns und genießen auch Sie schon bald saubere SAP RFC‑Verbindungen.

FAQ

In welcher Tabelle werden RFC-Verbindungen gespeichert?

Alle RFC-Verbindungen werden in der Datenbanktabelle RFCDES gespeichert. Sie können diese Tabelle über die Transaktion SE16 abfragen, um Verbindungsinformationen für Dokumentationen oder systemübergreifende Analysen zu exportieren. Die Tabelle enthält technische Parameter, Zielsysteminformationen und Verbindungseinstellungen.

Das Berechtigungsobjekt S_RFC steuert auf dem Zielsystem, welche Funktionsbausteine ein RFC-Benutzer aufrufen darf. Es prüft den Zugriff auf Funktionsgruppen oder einzelne Bausteine. Eine Stern-Berechtigung (*) erlaubt den Aufruf aller RFC-fähigen Funktionsbausteine – ein erhebliches Sicherheitsrisiko, das Sie durch granulare Berechtigungen vermeiden sollten.

Die Transaktion SM59 ist die zentrale Anlaufstelle für die Verwaltung von RFC-Verbindungen. Hier legen Sie neue Verbindungen an, pflegen Anmeldedaten und testen die Erreichbarkeit von Zielsystemen. Für die Analyse bestehender Verbindungen eignet sich zusätzlich der Report RSRFCCHK, der alle Destinationen mit Anmeldedaten übersichtlich darstellt.

Bleiben Sie auf dem Laufenden

Melden Sie Sich zu dem Newsletter an, um weitere Informationen zu erhalten.

Folgen Sie @Xiting und @xiting.global auf den Sozialen Medien.

Kontaktieren sie unsere experten

Melden Sie sich jetzt an!

Contact our experts