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.
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.
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!
Bei RFC-Verbindungen unterscheidet SAP zwischen 2 Vertrauensmodellen:
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.
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.
|
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 |
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.
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.
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.
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.
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.
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!
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.
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.
So legen Sie eine neue RFC-Verbindung vom Typ 3 an:
Hinweis!
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.
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 |
|
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.
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.
| 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.
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:
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.
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.
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:
→ 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.
Hinweis!
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:
→ 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.
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.
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.
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.
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:
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.
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.
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.
Sie sehen gerade einen Platzhalterinhalt von Vimeo. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von YouTube. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Facebook. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie müssen den Inhalt von hCaptcha - Formidable laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von reCAPTCHA laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie müssen den Inhalt von Turnstile laden, um das Formular abzuschicken. Bitte beachten Sie, dass dabei Daten mit Drittanbietern ausgetauscht werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von HubSpot. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Hubspot Meetings. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von Instagram. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr InformationenSie sehen gerade einen Platzhalterinhalt von X. Um auf den eigentlichen Inhalt zuzugreifen, klicken Sie auf die Schaltfläche unten. Bitte beachten Sie, dass dabei Daten an Drittanbieter weitergegeben werden.
Mehr Informationen