So fügen Sie explizite BEFUGNISPRÜFUNGEN sicher in benutzerdefinierte RFC-fähige Funktionsbausteine ein

Zuletzt aktualisiert: 5.1 .2026

Die Absicherung benutzerdefinierter Remote Function Modules (RFCs) erfordert mehr als nur die standardmäßigen S_RFC-Prüfungen; sie erfordert explizite AUTHORITY-CHECK Anweisungen, um sicherzustellen, dass Benutzer über bestimmte Geschäftsberechtigungen verfügen (z. B. „Genehmigen“ vs. „Anzeigen“). Während die Standardberechtigungen von S_RFC control auf die technisch Funktionsgruppe, setzen sie diese nicht durch Geschäftslogik, was häufig zu Verstößen gegen die Aufgabentrennung (Segregation of Duties, SoD) führt, bei denen ein Benutzer kritische Aktionen ausführen kann, nur weil er über einen allgemeinen RFC-Zugriff verfügt.

Um dieses Risiko zu mindern, ohne Produktionsprozesse zu beeinträchtigen, stellt SAP zwei Frameworks zur Verfügung: das Switchable Authorization Check Framework (SACF) zur nachträglichen Integration von Prüfungen und das Unified Connectivity Framework (UCON) zur Verringerung der Angriffsfläche. In diesem Leitfaden wird erläutert, wie Sie beide Tools einsetzen können, um Ihren benutzerdefinierten ABAP-Code effektiv zu sichern.

Compliance-Aspekte

Jede SAP-Anwendung bietet geschäftsbezogene Berechtigungsobjekte, die bestimmte Aktivitäten für einzelne Geschäftseinheiten klar definieren. Sie sind so konzipiert, dass sie Audit-Anforderungen wie die Nachvollziehbarkeit zugewiesener Berechtigungen und die Aufgabentrennung problemlos erfüllen und überwachen. 

S_RFC-Berechtigungen beziehen sich nicht auf eine bestimmte Geschäftseinheit oder -aktivität. Sie beschreiben die Zugriffsberechtigung auf ein technisches Objekt (einen Funktionsbaustein oder eine Funktionsgruppe). Die implizite Prüfung der „technischen“ S_RFC-Berechtigung sollte Entwickler nicht davon abhalten, explizite AUTHORITY-CHECKS für die beabsichtigten geschäftsbezogenen Berechtigungsobjekte hinzuzufügen. Andernfalls hängen die Aktivitäten, die ein Benutzer ausführen darf, nicht mehr nur von der Identität dieses Benutzers ab, sondern auch davon, wie der Benutzer auf das System zugegriffen hat – über die Haupttür (Dialog-Login) oder eine bestimmte Seitentür (RFC-FM).
 

Dies führt zu einer zusätzlichen Komplexität, die wiederum einen Verlust an Transparenz zur Folge hat und Compliance-Probleme verursachen kann.

Beispiel:
Sie definieren Ihren eigenen Geschäftseinheitstyp und wählen Aktivitäten wie: ANLEGEN, ANZEIGEN, ÄNDERN, GENEHMIGEN, AUSFÜHREN.

Die Entitäten können über die neue Transaktion ZENTITY_TRANS verwaltet werden, die Schaltflächen zur Ausführung aller möglichen Aktivitäten bereitstellt. Da Compliance-Vorschriften eine Aufgabentrennung bei der Erstellung, Genehmigung und Bearbeitung der Entität vorschreiben, wird ein neues Berechtigungsobjekt ZOBJ_ENTITY angelegt:

ZOBJ_ENTITY
     ID ‘ENTITY_NAME’
     ID ‘FIELD ‘ACTVT’

Für jede der Transaktionsschaltflächen kann die Berechtigung des Benutzers für die jeweilige Aktion überprüft werden.

In den Projektanforderungen ist festgelegt, dass diese Aktivitäten von außen zugänglich sein müssen. Daher legen Sie die RFC-FMs an:

• Z_ENTITY_CREATE
• Z_ENTITY_DISPLAY
• Z_ENTITY_CHANGE
• Z_ENTITY_APPROVE
• Z_ENTITY_EXECUTE
• Z_ENTITY_SUPER

Keiner der RFC-FMs enthält eine explizite AUTHORITY-CHECK-Prüfung für ZOBJ_ENTITY. Der RFC-FM Z_ENTITY_SUPER ermöglicht es dem Aufrufer, die gewünschte Aktivität über einen Eingabeparameter anzugeben, und alle Funktionsbausteine gehören zur Funktionsgruppe Z_ENTITY.

Aus Sicht der Rechnungsprüfung und Compliance weist diese Methode mehrere Nachteile auf:

 1. Um alle Benutzer zu ermitteln, die (potenziell) zur Genehmigung von Entitäten berechtigt sind, reicht es nicht aus, die Transaktion SUIM zu verwenden und nach Benutzern zu suchen, deren Rollen 

                                  ZOBJ_ENTITY
ID „ACTVT“ FELD „APPROVE“

Prüfer müssen außerdem wissen, dass S_RFC-Berechtigungen für die Funktionsbausteine Z_ENTITY_APPROVE oder Z_ENTITY_SUPER sowie S_RFC-Berechtigungen für die Funktionsgruppe „Z_ENTITY“ ebenfalls die Genehmigung einer Entität ermöglichen.

2. Die erforderliche Aufgabentrennung wird automatisch verletzt, wenn einem Benutzer eine Rolle zugewiesen wird, die 

S_RFC
    ID ‘RFC_TYPE’ FIELD ‘FUGR’
    ID ‘RFC_NAME’ FIELD ‘Z_ENTITY’
    …

oder

S_RFC
    ID ‘RFC_TYPE’ FIELD ‘FUNC’
    ID ‘RFC_NAME’ FIELD ‘Z_ENTITY_SUPER’

3. Eine Folge von Punkt 1 ist, dass es äußerst schwierig wird, in SAP GRC einen geeigneten Regelsatz zu definieren, der alle möglichen Kombinationen berücksichtigt. Wenn die RFC-FMs die richtige AUTHORITY-CHECK-Prüfung enthalten, könnten sie durch eine einfache Verwendungsanalyse leicht identifiziert werden.

Folglich wird jedes hochwertige Code-Scanning-Produkt RFC-FMs ohne explizite AUTHORITY-CHECKS als potenzielles Risiko melden. Dies zwingt Projektteams dazu, diese Risiken zu mindern, bevor das nächste Audit ansteht. SAP-Landschaften sind jedoch äußerst komplex, und Projektteams scheuen sich in der Regel vor unbekannten Nebenwirkungen, wenn sie AUTHORITY-CHECKS in bestehende RFC-FMs einführen.

Glücklicherweise stellt SAP zwei leistungsstarke Werkzeuge zur Verfügung, die Kunden in solchen Szenarien unterstützen: das Unified Connectivity Framework (UCON) und das Switchable Authorization Check Framework (SACF). 

Ein Projekt zur Behebung fehlender Berechtigungen umfasst drei Schritte:

Schritt 1: Allgemeine Aufräumarbeiten

Die erste Herausforderung besteht darin, die tatsächlich genutzten RFC-FMs zu identifizieren. Wenn es um SAP-Standard-RFC-FMs geht, gehen Experten davon aus, dass in einem durchschnittlichen SAP-Projekt nur 5 % davon in den laufenden Geschäftsprozessen aufgerufen werden. Bei den von Kunden entwickelten RFC-FMs dürfte dieser Anteil deutlich höher liegen, doch viele Module sind veraltet. Das liegt daran, dass:

• Über den oft begrenzten Lebenszyklus von SAP-Projekten 
• Dynamische Veränderungen der geschäftlichen Anforderungen der Projekte

Es gibt zudem eine Reihe von RFC-Funktionsmodulen von Kunden (sowie SAP-RFC-Funktionsmodulen), die nie für den externen Aufruf konzipiert wurden. Diese RFC-Funktionsmodule sind lediglich als „Remote-Enabled“ gekennzeichnet, da dieses Attribut für alle Funktionsmodule erforderlich ist, die lokal zur Parallelisierung oder Entkopplung aufgerufen werden. Solche RFC-FMs erfordern in der Regel keine expliziten AUTHORITY-CHECKS, da sie als lokale Funktionsbausteine betrachtet werden können. Sie lassen sich in SAP NetWeaver >= 7.56 anhand des neuen Attributs „Scope“ identifizieren. FMs mit dem Scope „From same system, client, and user“ erfordern nicht unbedingt einen expliziten AUTHORITY-CHECK, da sie als lokale FMs betrachtet werden können:

Ab SAP NetWeaver 7.40 hat SAP UCON eingeführt, um einen Whitelist-Ansatz für die Filterung der RFC-Funktionen bereitzustellen, denen der externe Zugriff auf das System gestattet ist. Die Einführung von UCON beginnt mit einer Protokollierungsphase, in der alle Aufrufe von RFC-Funktionen protokolliert werden. Wertvolle Informationen für ein Sicherheitsprojekt liefert die Transaktion UCONMON:

• Bezeichnet als RFC FM
• Verwendete RFC-Destination
• RFC-Server-Client (Ziel-Client)
• RFC-Server-Benutzer 
• RFC-Anrufer-SID (anrufendes System)
• RFC-Aufrufer (aufrufender Client)

Alle Informationen zu UCON finden Sie unter „SAP-Systeme mit dem Unified Connectivity Framework (UCON) schützen“. 

Im Rahmen eines UCON-Projekts werden alle erforderlichen RFC-FMs zur UCON-Standard-Kommunikationsbaugruppe (CA) hinzugefügt, und alle anderen RFC-FMs werden für externe Aufrufe gesperrt:

Schritt 2: Fehlende AUTHORITY-CHECKs identifizieren

Die RFC-FMs der UCON-Standard-CA, die sich im Kunden-Namespace befinden, werden als Eingabe für ein Code-Scanning-Produkt wie SAP Code Inspector (Prüf-ID 11A2) oder Onapsis Control Code ABAP (Testfall-ID 14) verwendet. Die FMs des Ergebnissatzes können an die zuständigen Entwicklungsteams weitergeleitet werden, z. B. auf der Grundlage der Verantwortlichen für die betroffenen Pakete. 

Schritt 3: Einführung expliziter Autorisierungsprüfungen 

Das SAP Switchable Authorization Framework (SACF) ermöglicht die reibungslose Einführung neuer Berechtigungsprüfungen in bereits im Produktivbetrieb befindlichem ABAP-Code. Daher wird es häufig von SAP-Standardanwendungen verwendet, wenn explizite Berechtigungsprüfungen für bereits ausgelieferte RFC-FMs eingeführt werden. Es gibt eine Reihe von SAP-Sicherheitshinweisen, die Schwachstellen durch fehlende Berechtigungsprüfungen in SAP-Standard-RFC-FMs beheben. Der SAP-Hinweis 2078596 mit dem Titel „Weitere Verbesserungen für die RFC-Sicherheit“ verweist auf mehr als hundert SAP-Hinweise, die zusätzliche AUTHORITY-CHECKS in SAP-Standard-RFC-FMs einführen. Die meisten der referenzierten Hinweise nutzen den SACF, um die neuen Prüfungen einfach einzuführen. Leider hat SAP diesen Hinweis seit Oktober 2016 nicht mehr aktualisiert. Seitdem wurden weitere Hinweise veröffentlicht – viele davon sind das Ergebnis der Arbeit der Onapsis Research Labs (ORL).

Der SACF ermöglicht zudem die Erstellung von Kundenszenarien (hierfür ist die Implementierung des SAP-Hinweises Nr. 3330401 – „SACF: Erstellung von Szenarien im Kundennamensraum“ – erforderlich) und bietet die Werkzeuge, um neue Berechtigungsprüfungen problemlos in bestehende Geschäftsprozesse des Kunden zu integrieren. 

Die Einführung expliziter Autorisierungsprüfungen umfasst drei Phasen: die Aufzeichnungsphase, die Protokollierungsphase und die Produktionsphase.

Aufzeichnungsphase
Die Aufzeichnungsphase beginnt mit der Erstellung einer SACF-Szenariodefinition und eines Produktionsszenarios mit dem Szenariostatus N in der Transaktion SACF. Beide werden in alle SAP-Systeme transportiert. Entwickler können dann damit beginnen, die anfälligen RFC-FMs Schritt für Schritt abzusichern, indem sie szenariospezifische Berechtigungsprüfungen hinzufügen. Eine „szenariospezifische Berechtigungsprüfung“ bedeutet, dass Entwickler die neuen Berechtigungsprüfungen über die Methode CL_SACF=>AUTH_CHECK_SPEC hinzufügen und dabei den Szenarionamen als Eingabeparameter angeben. Der Szenariostatus N des Produktionsszenarios hat zwei mögliche Ergebnisse:

• Neu bearbeitete Berechtigungsobjekte werden automatisch dem Szenario mit dem Status „Prüfung deaktiviert“ (wird immer bestanden) hinzugefügt  
• Autorisierungsobjekte, die bereits im Szenario enthalten sind, werden auf ihren aktuellen Status überprüft

Am Ende der Erfassungsphase können die erfassten Einträge mit der Transaktion SACF_TRANSFER aus allen beteiligten Produktionssystemen zurück in das Entwicklungssystem übertragen werden.

Protokollierungsphase
Die Protokollierungsphase simuliert das zukünftige aktive Szenario, indem sie Benutzer alle Berechtigungsprüfungen bestehen lässt und alle Prüfungen protokolliert, die in einem aktiven Szenario fehlgeschlagen wären. Die Phase wird auf dem Entwicklungssystem initialisiert, indem der Prüfstatus für alle erfassten Berechtigungsobjekte auf „Prüfung ohne Einschränkungen aktiv“ gesetzt und der Szenariostatus auf L (Szenario im Status „Protokollierung“ (Prüfbewertung erfolgreich)) umgeschaltet wird. Der SAL-Status muss auf E gesetzt sein (Autorisierungsfehler im Security Audit Log protokollieren). Hinweis: Die SAL-Protokollierung ist nur aktiv, wenn das entsprechende SAL-Ereignis (ID DUP) in der SAL-Konfiguration für die Protokollierung aktiviert ist. Die neuen Einstellungen werden in einem neuen Transportauftrag erfasst und müssen auf alle SAP-Systeme transportiert werden. 

Die Protokollierungsphase sollte zwischen drei und sechs Monaten dauern. Während dieses Zeitraums sollte das Sicherheitsereignisprotokoll regelmäßig auf DUP-Ereignisse überprüft werden, die auf fehlende Berechtigungen für einen RFC-Benutzer hinweisen:

Anhand dieser Protokolleinträge kann der Rollenadministrator die Rollen der betroffenen RFC-Benutzer fortlaufend erweitern. 

Die Produktionsphase
Sobald über einen Zeitraum von 2 bis 3 Monaten keine SAL-Einträge mehr generiert wurden, kann das Produktionsszenario aktiviert werden. Die Aktivierung erfolgt durch Setzen des Szenariostatus auf A (Szenario im Status „Aktiv“ (siehe Bewertung in der Liste)) und anschließenden Transport des geänderten Szenarios in alle SAP-Systeme. Hinweis: In aktiven Szenarien können fehlgeschlagene Berechtigungsprüfungen weiterhin im SAL nachverfolgt werden. Wenn Entwickler jedoch neue Berechtigungsobjekte zu RFC-FMs hinzufügen, werden die Prüfungen für diese Objekte immer bestanden. Daher sollten nach der Aktivierung des Produktionsszenarios keine szenariospezifischen Berechtigungsprüfungen für neue Berechtigungsobjekte zu RFC-FMs hinzugefügt werden. Andernfalls muss ein Prozess eingerichtet werden, der sicherstellt, dass das Produktionsszenario erweitert und an alle Systeme verteilt wird, bevor die neue Prüfung aus dem Entwicklungssystem freigegeben wird.

Sicherheitsaspekte

Aus Sicherheitsgründen wird empfohlen, die szenariospezifischen Berechtigungsprüfungen nach einer längeren Phase stabilen Betriebs des Produktionsszenarios durch reguläre AUTHORITY-CHECKs zu ersetzen.

Frameworks wie UCON und SACF können nur dann ein Höchstmaß an Sicherheit bieten, wenn ihre Konfigurations- und Statuseinstellungen nicht von Unbefugten manipuliert werden können. Zwar lassen sich lokale Änderungen über Änderungsbelege (UCON) oder SAL-Ereignisse (Ereignis-ID DUQ für SACF-Szenarioänderungen) erkennen, doch erfassen diese Mechanismen keine Änderungen, die über Transporte vorgenommen werden. Daher ist eine sorgfältige Überwachung aller Transportaufträge erforderlich. Die Überwachung wird zusätzlich erschwert, da Konfigurationsänderungen über die dafür vorgesehenen Objekttypen für RFC-Zustände (R3TR RFST), Communication Assemblies (R3TR UCSA) und SACF-Szenarien (R3TR SUCD, SUCC) transportiert werden können und ein Angreifer zudem Einträge für die zugrunde liegenden Tabellen zu einem Transportauftrag hinzufügen könnte.
Die Platform die einzige SAP-Sicherheitslösung, die Transportaufträge automatisch auf solche kritischen Konfigurationsänderungen überprüft. Control Transports erkennt, ob 

• Neue RFC-FMs werden zur Standard-CA von UCON hinzugefügt
• Die UCON-Phase eines RFC-FM wird geändert
• Die Standard-Zertifizierungsstelle von UCON wird auf Tabellenebene geändert
• Die UCON-Phase eines RFC-FM wird auf Tabellenebene geändert
• UCON-Änderungsdokumente werden manipuliert
• Ein RFC-FM wird geändert, der über die UCON-Standard-CA nach außen verfügbar ist
• Ein aktives SACF-Szenario wird deaktiviert
• Ein oder mehrere Berechtigungsobjekte werden aus einem SACF-Szenario entfernt
• Ein SACF-Szenario wird auf der Ebene der Tabellendaten geändert
• Die Berechtigungsobjekte eines SACF-Szenarios werden auf Tabellenebene geändert

Fazit

Die Behebung fehlender expliziter AUTHORITY-CHECKS in RFC-FMs kann komplex und anspruchsvoll sein. Da RFC-FMs einen der größten Angriffseingänge für Angreifer in SAP-Systeme darstellen, sollten SAP-Kunden diese Aufgabe unbedingt in ihre Projektpläne aufnehmen. Glücklicherweise unterstützt SAP seine Kunden mit dem Unified Connectivity Framework (UCON) und dem Switchable Authorization Check Framework (SACF). Beide Frameworks verfolgen kritische Konfigurationsänderungen lokal über Änderungsbelege oder SAL-Ereignisse, erkennen oder verfolgen jedoch keine Änderungen, die über Transporte angewendet werden. Diese Änderungen können von der Platform überwacht werden, Platform einzigen von SAP empfohlenen Cybersicherheits- und Compliance-Lösung. Onapsis Control Transports bietet unter anderem eine Reihe von 10 spezifischen Testfällen, die kritische Konfigurationsänderungen in UCON- und SACF-Konfigurationen identifizieren.    

Häufig gestellte Fragen (FAQ)

Was ist der Unterschied zwischen S_RFC und expliziten AUTHORITY-CHECKS?

S_RFC ist ein technisches Berechtigungsobjekt, das die Berechtigung zum Aufruf eines Funktionsbausteins oder einer Funktionsgruppe erteilt (die „Seitentür“). Ein ausdrücklich AUTHORITY-CHECK ist eine ABAP-Codezeile innerhalb des Funktionsbausteins, die prüft, ob der Benutzer über bestimmte Geschäftsberechtigungen verfügt (z. B. ACTVT = '02' (for Change) vor der Ausführung der Logik. Sich ausschließlich auf S_RFC zu verlassen, kann zu Compliance-Lücken führen.

Wie funktioniert das SAP Switchable Authorization Check Framework (SACF)?

Mit SACF können Entwickler neue Autorisierungsprüfungen in den Produktionscode integrieren, ohne dass es zu sofortigen Unterbrechungen kommt. Dabei wird ein dreistufiger Ansatz verfolgt:

1. Protokollierung: Das System protokolliert, welche Benutzer die neue Überprüfung nicht bestehen würden.
2. Protokollierung: Die Überprüfung läuft im „Simulationsmodus“ und protokolliert Fehler im Sicherheitsüberwachungsprotokoll (SAL), ohne Benutzer zu blockieren.
3. Produktion: Sobald die Protokolle keine Fehlalarme mehr aufweisen, wird die Überprüfung vollständig aktiviert, um unbefugten Zugriff zu verhindern.

Welche Rolle spielt das Unified Connectivity Framework (UCON)?

UCON fungiert als Firewall für RFC-Funktionsbausteine. Es erstellt eine „Whitelist“ (Kommunikations-Assembly) mit RFCs, deren Aufruf von außen ausdrücklich erlaubt ist. Alle RFCs, die nicht auf dieser Liste stehen, werden vor externem Zugriff geschützt, wodurch die Angriffsfläche erheblich verringert wird, da veraltete oder ungenutzte Funktionsbausteine vor Angreifern verborgen bleiben.

Kann ich SACF für meinen eigenen benutzerdefinierten Code verwenden?

Ja. Obwohl SACF häufig für SAP-Standard-Updates verwendet wird, können Sie Szenarien für Ihre eigene kundenspezifische Entwicklung erstellen. Dazu muss der SAP-Hinweis 3330401 implementiert werden, der die Erstellung von SACF-Szenarien im Kundennamensraum ermöglicht. Dies ist entscheidend für die Behebung von Befunden aus Code-Scanning-Tools.

Wie kann ich Änderungen an den UCON- und SACF-Konfigurationen überwachen?

Standard-SAP-Tools erfassen lokale Änderungen über Änderungsbelege, übersehen jedoch häufig Änderungen, die über Transportaufträge vorgenommen werden (z. B. wenn ein Angreifer eine deaktivierte UCON-Konfiguration transportiert). Die Onapsis Platform überwacht gezielt Transportaufträge, um festzustellen, ob kritische Sicherheitskonfigurationen wie UCON-Phasen oder SACF-Szenarien während der Bereitstellung manipuliert oder deaktiviert werden.