Optimierung der RFC-Schnittstellenarchitektur
Eine der meisten und gleichzeitig auch gravierendsten Sicherheitslücken in der Kommunikation zwischen und innerhalb von SAP-Systemen sind die überberechtigten 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 auf Ihre Systeme dar. Oft existiert nur eine kleine Anzahl von Benutzern, welche in einer Vielzahl von RFC-Verbindungen hinterlegt sind, diverse Szenarien abdecken und ohne klarem Konzept meistens direkt mit dem Standardprofil SAP_ALL ausgestattet sind.
Diesem Missstand Herr zu werden ist oftmals technisch komplex und Bedarf einer granularen Analyse aller bestehenden RFC-Prozesse. Daher ist das Ziel dieses Blogs, Sie zum einem an das Thema Untrusted Remote Function Call (RFC) heranzuführen und gleichzeitig Ihnen zu helfen, diese Sicherheitslücken zu schließen. Hierbei wird der Blog nicht nur die Grundlagen im Schnittstellenbereich umreißen, sondern auch Best-Practice-Information zur Umsetzung, Optimierung und Bereinigung liefern. Mit den richtigen Werkzeugen lassen sich riesige Einfallstore in Ihre SAP-Landschaft in kürzester Zeit schließen.
Inhaltsverzeichnis
Die Kernkomponenten – Der Remote Function Call
RFC ist eine der SAP-Technologien, welche hauptsächlich für den Aufruf von Funktionen in entfernten Systemen genutzt wird. Zusätzlich ist es ein elementarer Baustein für weitere Technologien, wie z.B. IDoc-Verarbeitung, ALE oder BAPIs. RFC-Schnittstellenbenutzer melden sich im Falle von Untrusted RFC über die im aufrufenden System (Client) hinterlegten Daten an einem aufgerufenen System (Server) an. Die Benutzer sollten ausschließlich vom Benutzertyp „System“ sein, damit eine Dialoganmeldung ausgeschlossen ist. Ob ein RFC-Schnittstellenbenutzer einen spezifischen RFC-Funktionsbaustein ausführen darf, entscheidet das Berechtigungsobjekt S_RFC auf dem Server.
Das Aufbauen von sicherheitskritischen Architekturen und die damit einhergehende Überberechtigung von Systembenutzern birgt hohe Risiken, auch wenn sich nicht jede reale Person direkt über die SAP GUI mit diesen Benutzern anmelden kann. Gerade durch das Berechtigungsobjekt S_RFC können viele kritische Zugriffe geschaffen werden. Mit Hilfe dieser Startberechtigung können alle Funktionsbausteine eines SAP-Systems ausgeführt und somit jegliche Geschäftsdaten gelesen und manipuliert werden. Ein Angreifer muss im Regelfall noch nicht einmal seine Spuren verwischen, denn die Daten werden auf den Zielsystemen durch die anonymisierten technischen Benutzer manipuliert.
Um in einer solchen Systemarchitektur überhaupt wieder Sicherheit garantieren zu können, muss zwingend eine RFC-Schnittstellenbereinigung durchgeführt werden.
Analyse der Architektur
Der Prozess beginnt mit einer Analyse des Ist-Zustandes, um den Umfang und Aufwand des Vorhabens abzuschätzen. Dabei sollten folgende Faktoren analysiert werden:
- 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, BW-Extraktion, Zentrale Benutzerverwaltung etc.)
Bei diesem Vorgehen wird immer zwischen einer server- und einer clientseitigen Analyse unterschieden. Die Xiting Authorizations Management Suite (XAMS) bietet Ihnen hierbei die nötige Unterstützung, um beide Analysen effizient und zentralisiert durchzuführen. Das spart Zeit, reduziert die Ressourcenbindung und minimiert die Kosten. Doch zuerst bekommen Sie einen Einblick in die SAP Standard-Möglichkeiten und daraufhin auch das Potential der XAMS aufgezeigt.
Zusätzlich zu Ihrer Systemanalyse sollten Sie gleichzeitig folgende Schwachstellen identifizieren und dokumentieren, da sie sich später auf die Neukonzeption auswirken:
- Werden generische Benutzer in den Destinationen eingesetzt, z. B. SAP Standard Benutzer DDIC?
- Gibt es ein Einsatzkonzept für die Benutzer, z. B. Trennung pro aufrufendes System oder Szenario?
- Gibt es eine Namenskonvention für die Benutzer?
Clientseitige Analyse
Die clientseitige Analyse liefert Ihnen die essentiellen Daten, um den Ist-Zustand Ihrer RFC-Architektur zu modellieren. Das bedeutet, danach sollten Sie ein genaues Bild haben, welche Verbindungen zwischen Ihren SAP-Systemen bestehen.
Für die IST-Analyse können Sie entweder die Transaktion RSRFCCHK (RFC-Verbindungen mit Anmeldedaten) oder das Xiting RFC Monitoring Tool nutzen.
RSRFCCHK
Die Transaktion RSRFCCHK bzw. der gleichnamige Report stehen auf jedem SAP NetWeaver AS ABAP zur Verfügung. Sie hilft Ihnen hauptsächlich die Verbindungsinformationen aus der Transaktion SM59 (Konfiguration der RFC-Verbindungen) in einer auswertbaren Form darzustellen. Des Weiteren kann beim Auslesen ein Verbindungstest durchgeführt werden. Somit können Sie eine ungültige RFC-Destination direkt ermitteln und zur Bereinigung vormerken.
Als Ergebnis bekommen Sie alle in diesem System hinterlegten Destinationen inkl. der relevanten Informationen übersichtlich in einer Tabelle dargestellt.
RSRFCCHK liefert dabei immer nur Ergebnisse für das aktuelle System. Um die gesamte Architektur der Landschaft abzubilden, muss der Vorgang konsequenterweise in allen SAP-Systemen durchgeführt werden.
XAMS RFC Monitoring Tool
Sie können auch das XAMS RFC Monitoring Tool für Ihre clientseitige Analyse nutzen. Dieses bringt vor allem in größeren Systemlandschaften entscheidende Vorteile mit sich. Es kann auf einem Zentralsystem eingesetzt werden, von wo aus die komplette Systemlandschaft ausgelesen wird. Beispielsweise wurden im folgenden Bild zentral die Destinationen für die Systeme XIE und DEM ausgelesen. Somit wird erheblicher Arbeitsaufwand gespart, Fehler in der externen Datenhaltung vermieden und alle Informationen können auf Knopfdruck im Zentralsystem aktualisiert werden.
Die aktuellen Daten können Sie direkt im Tool editieren und somit ein Soll-Konzept erstellen. Geänderte Daten werden dabei gelb markiert. Über die „Status“-Spalte können Sie festhalten, welche Destinationen in Ordnung sind oder bearbeitet bzw. gelöscht werden müssen. Es dient Ihnen also auch als Arbeitsliste und zentrale Dokumentation, um die Architektur zu bereinigen.
Serverseitige Analyse
Eine RFC-Analyse kann nicht nur clientseitig, sondern auch serverseitg durchgeführt werden. Dabei wird auf ST03N-Statistikdaten zurückgegriffen. Das hat jedoch den entscheidenden Nachteil, dass selten genutzte oder ungültige Verbindungen möglicherweise nicht beachtet werden.
Es ergeben sich allerdings auch neue Optionen. Sie können analysieren, ob ein Schnittstellenbenutzer tatsächlich nur für sein angedachtes RFC-Anwendungsszenario verwendet wird und ob NON-SAP-Systeme, z. B. Java-Anwendungen, oder externe SAP-Systeme mit Ihrer Landschaft kommuniziert haben.
Die serverseitige Analyse ist also hauptsächlich als Zusatz- und Detailanalyse zu betrachten. Die grundlegende Architektur sollte mit der clientseitigen Analyse bereits modelliert worden sein.
Hier möchte ich erneut zwei Wege vorstellen, einerseits die SAP Standard-Transaktion ST03N und andererseits unser Freeware Tool RFC Stocktake.
Nutzung der ST03N-Nutzungsstatistiken
Mit Hilfe der Statistikdaten aus der Transaktion ST03N können Sie analysieren, welche Funktionsbausteine ausgeführt wurden. Dies umfasst nicht nur den ausführenden Benutzer, sondern auch das jeweilige aufrufende System. Hierfür müssen Sie in der Transaktion ST03N einen Zeitraum für die totale Systemlast (monatsweise) und das „RFC Server Profil“ im linken Bereich auswählen.
Im Reiter „Anwender“ sollten Sie die Tabelle über die Filterfunktion nach technischen Benutzern filtern. Auch personalisierte Dialog-Benutzer führen RFC-Funktionsbausteine aus, sind jedoch für diese Analyse irrelevant.
Durch diese Überprüfung können Sie validieren, welche technischen Benutzer überhaupt in der Vergangenheit Funktionsbausteine aufgerufen haben. Per Doppelklick auf den Benutzernamen sehen Sie in einer Detailansicht, welche Funktionsgruppen durch welches System aufgerufen wurden. Daraus können Sie schließen, ob die Statistikdaten des Benutzers zum angedachten Szenario passen bzw. ob der Benutzer nur vom angedachten Client verwendet wurde.
Unter dem Reiter „Remote Server“ können alle Clients eingesehen werden, welche mit dem aktuellen System kommuniziert haben. Durch einen Abgleich mit der clientseitigen Analyse kann also schnell herausgefunden werden, ob auch Systeme außerhalb Ihrer SAP-Landschaft mit Ihrem Server kommuniziert haben.
RFC Stocktaker
Mit unserem Freeware Tool Xiting RFC Stocktake kann eine solche Analyse ebenfalls durchgeführt werden. Der entscheidende Vorteil ist, dass Sie auch hier wieder mit einem sogenannten Zentralmodus arbeiten können 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 werden sofort farblich hervorgehoben.
Optimierung der Architektur
Im nächsten Schritt werden nun die analysierten Schwachstellen der RFC-Architektur bereinigt und somit die kritischen Sicherheitslücken geschlossen. Hierfür haben sich über die Jahre hinweg gewisse Best-Practice-Ansätze etabliert, an denen Sie sich orientieren können.
Zunächst sollten generische Nutzer, wie z. B. DDIC oder SAPCPIC, unbedingt durch dedizierte Benutzer ausgetauscht werden. Falls solche Benutzer verwendet werden, sind diese oft in mehreren aufrufenden Systemen hinterlegt und somit kaum mit maßgeschneiderten Rollen zu berechtigen. Wichtige Anhaltspunkte sind hier eine hohe Anzahl an aufrufenden Systemen oder vermischte RFC-Szenarien.
Doch wie viele neue Benutzer müssen letztendlich erstellt werden und welche Architektur lässt sich sauber berechtigen? Dabei gelten folgende 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 Best Practices können auch kombiniert werden. Dabei werden Benutzer am besten „RFC_<SID>_<Szenario-Name>“ genannt.
Nach dem Erstellen der Benutzer auf dem Server müssen Sie diese natürlich noch in den zugehörigen Destinationen auf dem Client eintragen. Mit einer solchen 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 erzielen Sie einen enormen Gewinn hinsichtlich der Sicherheit und der Wartbarkeit der RFC-Schnittstellen. Dadurch werden im besten Fall Schnittstellenbenutzer nicht mehr überberechtigt und zweckentfremdete Benutzer können schnell identifiziert werden.
Fazit
Die Optimierung der RFC-Schnittstellenarchitektur ist technisch und organisatorisch anspruchsvoll. Sie betrifft die gesamte SAP-Systemlandschaft und ein Ausfall der Schnittstellen kann wirtschaftlichen Schaden anrichten. Dennoch schließt sie eine der gravierendsten Sicherheitslücken und ist deshalb ein zwingend notwendiger Schritt für revisionssichere Systemlandschaften, die auch die jeweiligen Compliance-Vorgaben der Kunden oder Lieferanten einhalten müssen.
Der Einsatz der XAMS unterstützt Sie, den Prozess überwacht und dokumentiert umzusetzen. Des Weiteren helfen unsere Tools ein anschließendes Berechtigungs-Redesign der technischen Benutzer nach dem „Need-to-know“-Prinzip durchzuführen.
Für die nötige Unterstützung und Know-How-Transfer melden Sie sich gerne jederzeit bei uns. Wir bieten dafür den etablierten Service Berechtigungsoptimierung der RFC-Schnittstellenbenutzer an, mit dem Sie eine vollumfängliche Unterstützung und Beratung bei der RFC Bereinigung bekommen. Wie es auch bei Ihnen ablaufen könnte, können Sie außerdem in dieser Success Story nachlesen. Hier erfahren Sie, wie die Firma Xiting mit Hilfe der XAMS 500 RFC-Schnittstellen bei der Audi AG in nur drei Monaten bereinigt hat.
- Optimierung der RFC-Schnittstellenarchitektur - 5. November 2020
