Bereinigung von RFC-Schnittstellen

Sicherheitsrisiko RFC-Schnittstelle?

Bei der Analyse von RFC-Schnittstellen stellt sich immer wieder heraus, dass Unternehmen Probleme haben, die Sicherheit dieser zu gewährleisten und eine Transparenz über deren Nutzung herzustellen. Vielfach zeigt sich, dass die Anlage und Pflege keinem dokumentierten Prozess unterliegen. Außerdem fehlen Vorgaben zur einheitlichen Dokumentation nebst Einschränkungen von notwendigen Berechtigungen. Damit mangelt es an Informationen, welche Daten über vorhandene Schnittstellen übertragen werden und ob diese dem ursprünglichen Zweck der Verbindung entsprechen. Dadurch enstehen unnötige Einfallstore für unerwünschte Zugriffe auf die häufig sensiblen Daten in SAP-Systemen.

Im Rahmen von Prüfungen, beispielsweise durch Auditing oder Revision, werden Defizite aufgedeckt und Handlungsanforderungen definiert. Damit lassen sich Risiken beseitigen und die Sicherheit, insbesondere die produktiver oder Produktivdaten enthaltener Systeme, erhöhen und vor möglichen Angriffen absichern.

Als Grundlage solcher Handlungsanforderungen ist zunächst eine tiefgehende Analyse des Schnittstellenbestandes nach verschiedenen Kriterien relevant. Dabei spiegelt eine solche Analyse vielfach den Tatbestand wider, dass sich in SAP-Systemen oder Systemverbünden über die Jahre eine Vielzahl angesammelter RFC-Verbindungen wiederfindet. Diese sind aus teils nicht mehr nachvollziehbaren Gründen in den Systemen eingerichtet worden. Hierzu gehören neben den SAP-seitig ausgelieferten Standardschnittstellen auch solche, die nur temporär zu Testzwecken eingerichtet und danach nicht wieder beseitigt oder deaktiviert wurden. Im schlimmsten Fall ein Dialogbenutzer mit hinterlegten Anmeldedaten und umfänglichen Berechtigungen auf produktiven Systemen. Oder auch kundenindividuelle Schnittstellen, die als betriebsnotwendig angesehen werden können.

Im Rahmen eines Bereinigungsvorhabens sollten folgenden Aspekten beachtet werden:

• Schaffung von Transparenz eingerichteter und verwendeter Schnittstellen
• Reduzierung der Gesamtmenge an zu verwaltenden Schnittstellen auf das betriebsnotwendige Maß
• Berücksichtigung der Kommunikation zwischen Systemen mit unterschiedlicher Risikobewertung und Schutzniveau
• Einschränkung auf notwendige Berechtigungen für den Betrieb einer Schnittstelle
• Berücksichtigung aktueller Standards zur Absicherung von RFC-Aufrufen z.B. RFC-Callback-Thematik

Umsetzung

Reduzierung vorhandener RFC-Schnittstellen

Um die Menge der zu bearbeitenden Schnittstellen möglichst gering zu halten, sollten vorab nicht relevante, nicht funktionierende oder nicht verwendete Schnittstellen abgegrenzt werden. Die Restmenge bildet dann die Basis für weitere Härtungs- und Sicherungsmaßnahmen.

Zur Auswertung kann die Transaktion „RSRFCCHK“ auf jedem System herangezogen werden, die Informationen über Verbindungsstatus sowie Mandanten und Benutzer/Passwortangaben enthält.

In der Auswertung des Verbindungsstatus sind fehlgeschlagene Verbindungen mögliche Kandidaten zur Deaktivierung bzw. Löschung.

Um die Gesamtmenge weiter zu reduzieren, besteht die Möglichkeit auch nicht verwendete, aber funktionierende Verbindungen zu deaktivieren und ggf. zu löschen. Hierzu kann z.B. die Transaktion „ST03N“ herangezogen werden, in welcher Aufrufstatistiken von RFC-Verbindungen ermittelt werden.

Nicht aufgerufene RFC-Verbindungen sind Kandidaten zur Deaktivierung oder zur Löschung.

Nach Abschluss sind nun auch die obsoleten Verbindungen aus dem System entfernt oder deaktiviert.

Dokumentation

Um die Transparenz sowie Einsatzzweck und Analyse im Fehlerfall verwendeter Schnittstellen zu verbessern, sollten diese einheitlich und nachvollziehbar dokumentiert werden. Diese Dokumentation sollte mindestens eine standardisierte Beschriftung in den Beschreibungsfeldern einer einzelnen Verbindung in „SM59“ enthalten. Besser wäre es, kundenspezifische RFC-Verbindungen zur einfacheren Nachvollziehbarkeit in einer tiefergehenden Dokumentation zu beschreiben. In dieser sollten sowohl Angaben zu Quelle/Ziel sowie User/Berechtigungen als auch inhaltliche Zuordnung und Abhängigkeiten zu anderen Schnittstellen genannt werden.

Empfehlungen:

• Für eine einheitliche Bezeichnung ist es sinnvoll Namenskonventionen für verwendete Schnittstellen zu verwenden.
• Ein RFC-User je Schnittstelle:
  Je Schnittstelle wird ein fachlich zur Schnittstelle passender User mit Berechtigungen nach dem Need-to-know-Prinzip vergeben.
• Eine RFC-Rolle je Schnittstelle dem RFC-User zuzuordnen.

Kommunikation zwischen Systemen mit unterschiedlichem Schutzniveau

Systemlinien beinhalten üblicherweise Entwicklungs-, Test- und Produktivsysteme, wobei z.B. Entwicklungssysteme als potenziell unsichere Systeme – also mit einem niedrigeren Schutzniveau– gesehen werden können.

Ausgehende RFC-Verbindungen von z.B. produktiven Systemen, oder Testsysteme mit sensiblen Produktivdaten zu unsicheren Systemen, sollten auf das betriebsnotwendige Maß begrenzt und ggf. mittels Transaktion SM59 entfernt werden, um die Gefahr eines RFC-Call-Back-Angriffs zu reduzieren.

Alternativ kann der RFC-Benutzer aus der Verbindung entfernt werden, um eine personalisierte Anmeldung des agierenden Benutzers z.B. für die Überleitung anonymisierter Testdaten zu erzwingen.

Flankierend sollten die Systeme über die Implementierung des RFC-Call-Back-Schutzmechanismus mit Whitelists zulässiger Aufrufe ausgestattet werden.

Umstellung User-Typ

In RFC-Verbindungen sollten keine Dialog- und Service-Benutzer verwendet werden, um eine Dialoganmeldung am System zu verhindern. Der empfohlene User-Typ für RFC-Verbindungen ist „SYSTEM“. Zur Auswertung kann die Transaktion „STRFCTRACE“ flankierend angewandt werden.

Wurden Dialog oder Servicebenutzer ermittelt, ist der

• User Typ im Zielsystem auf „SYSTEM“ umzustellen oder
• Login auf „Current User“ zu setzen.
• Benutzer ggf. umzubenennen und auf beiden Seiten (RFC-Verbindung Quellsystem/User im Zielsystem) zu ändern.

Umsetzung von SNC-Verschlüsselung

Ist SNC im gegebenen System umgesetzt, können neben Dialog auch RFC-Verbindungen verschlüsselt übertragen werden. Hierzu sind ausgehende und eingehende RFC-Verbindungen hinsichtlich Datenschutzkriterien und SNC-Absicherung zu analysieren.

Als Empfehlung sollten alle Verbindungen, die

• Anmeldedaten übertragen (Benutzer/Kennwort oder Zertifikate),
• relevante Schnittstellen nach BDSG (Bundesdatenschutzgesetz) darstellen,
• für Datenübertragung der Stufen „geheim“ oder „streng vertraulich“ verwendet,

mittels SNC-Ende-zu-Ende verschlüsselt werden.

Absicherung ausgehender RFC-Verbindungen

Die Nutzungsberechtigung von RFC-Verbindungen in den Quellsystemen kann über das Berechtigungsobjekt „S_ICF“ eingeschränkt werden. Vorab sind hierzu die zum Aufruf berechtigten Benutzer zu ermitteln und diese, den jeweiligen RFC-Verbindungen im Feld „Berechtigung“ in Gruppen zuzuordnen. Für die Bildung der Gruppen sind Schutzbedarfseinstufung und fachliche Nutzung zu berücksichtigen.

Absicherung eingehender RFC-Verbindungen

Im Rahmen der Kommunikation zwischen Systemen über das „RFC“ Protokoll werden von einem Quellsystem (Client) Funktionsbausteine im Zielsystem (Server) aufgerufen und ausgeführt. Damit ein Funktionsbaustein aufgerufen werden kann, muss er in seinen Eigenschaften als „remote fähig“ gekennzeichnet sein. Zu dieser Kategorie gehören aktuell sehr viele der existierenden Funktionsbausteine. Als kritisch gelten solche, mit denen z.B. Systemeinstellungen geändert oder Benutzer- und Berechtigungszuordnungen vorgenommen werden können. Um hier eine Einschränkung herbeizuführen, können die Berechtigungen der RFC-Benutzer im Zielsystem mit entsprechend eingeschränkten Autorisierungen ausgestattet werden, welche nur die für die Ausführung der Schnittstelle notwendigen Funktionsbausteine zulassen. Im Zielsystem sind hierzu Rollen und Berechtigungen über das Berechtigungsobjekt „S_RFC“ auszuprägen.

Wurden vorab die Vorgaben aus Punkt 2 (Dokumentation) umgesetzt, lassen sich die erforderlichen Aufrufe von Funktionsbausteinen und Funktionsgruppen direkt ermitteln und in notwendige Berechtigungen einfügen. Hierzu kann die Transaktion „STRFCTRACE“ verwendet werden.

Die Auswertung liefert Informationen zu gerufenen RFC-Funktionsbausteinen /-gruppen sowie ermittelten Funktionsberechtigungen (Feldinformation) des betroffenen RFC-Users.  Vollberechtigte User „Gesamtberechtigung“ sollten eine Überarbeitung der S_RFC Berechtigungen erfahren. Generische Berechtigungen sollten bezüglich S_RFC gepflegt, jedoch ggf. hinsichtlich der zu berechtigenden Funktionen ergänzt werden.

Eine grundlegende Analyse sollte ein möglichst vollständiges Bild sämtlicher SAP-Systeme in einer Landschaft betrachten. Die RFC-Bereinigung kann jedoch insbesondere in komplexen Systemlandschaften mit teils unterschiedlichen SAP-Releases und einer Vielzahl von Schnittstellen eine sehr zeitaufwendige Arbeit darstellen. Für eine systemübergreifende Analyse von RFC-Schnittstellen bietet sich daher der Einsatz von unterstützenden Tools an, mit denen eine systemweite Darstellung der Schnittstellen aus Sicht von Quellsystemen in ausgehenden, als auch aus Sicht der Zielsysteme in eingehenden RFC-Aufrufen gelingt.

Hier bietet sich beispielsweise die SAST SUITE der akquinet AG an. Diese ermöglicht systemübergreifende Auswertungen für SAP ERP- und auch S/4HANA-Umgebungen, wobei die Schnittstellenkonfiguration der gesamten SAP-Landschaft überprüft werden, Schwachstellen in Systemen sichtbar gemacht und zuverlässig behoben.

Interface Analysen mit der SAST SUITE