Rollen, Autorisierungen und Services im SAP Gateway absichern

SAP Gateway und ICF als Zugriffsschicht für OData

SAP Gateway stellt die zentrale Laufzeitumgebung für OData-Services (Open Data Protocol) bereit und fungiert als Bindeglied zwischen HTTP-basierten Clients und ABAP-Backend-Logik. Jeder aktivierte Service öffnet einen Zugriffspfad über HTTP oder HTTPS und erweitert damit die Angriffsfläche des Systems. Der Zugriff erfolgt über ICF-Knoten (Internet Communication Framework) und wird durch den Gateway-Stack verarbeitet, der Routing, Authentifizierung und Autorisierungsprüfung übernimmt.

Dabei handelt es sich um die HTTP-Infrastruktur innerhalb des SAP-Systems. ICF-Knoten definieren konkrete URL-Endpunkte innerhalb dieser Struktur. Jeder OData-Service ist einem solchen Knoten zugeordnet. Nur ein aktiver Knoten verarbeitet eingehende HTTP-Anfragen und leitet sie an die zugehörige Serviceimplementierung weiter. Ein OData-Service basiert intern auf einem strukturierten Entwicklungsmodell, das Datenmodell, Serviceimplementierung und Servicebereitstellung voneinander trennt.

In Szenarien mit SAP Fiori Launchpad erfolgt der Zugriff indirekt über Browser und Reverse Proxy. Requests werden entweder an das Frontend-System mit den UI5-Ressourcen oder an das Gateway-System mit den OData-Endpunkten geleitet. Das ergibt eine klare Trennung zwischen UI und Datenzugriff, gleichzeitig jedoch eine zusätzliche Ebene, die abgesichert werden muss.

Die technische Grundlage bildet die Serviceregistrierung im Gateway-Katalog. Jeder Service besitzt einen technischen Namen, eine Servicedokument-ID und eine Zuordnung zu einem Systemalias. Ohne diese Zuordnung findet keine Laufzeitverarbeitung statt. Ein Service wird im Gateway nicht nur aktiviert, sondern nach der Implementierung zusätzlich im Backend registriert, damit er zur Laufzeit verarbeitet werden kann. Die Registrierung stellt sicher, dass das Servicemodell und die zugehörige Laufzeitklasse im Gateway-System miteinander verknüpft sind.

Serviceaktivierung und Systemalias als Kontrollpunkt

Die Aktivierung von OData-Services erfolgt über die Transaktion /IWFND/MAINT_SERVICE. Dort wird der Service im Katalog gesucht, registriert und einem Systemalias zugeordnet. Der Systemalias bestimmt, ob der Zugriff auf ein lokales Backend oder ein entferntes System erfolgt. In typischen Fiori-Szenarien zeigt der Alias auf das lokale System und verwendet keine RFC-Destination (Remote Function Call).

Die Konfiguration des Systemalias erfolgt im SAP Gateway. Der Alias definiert technische Parameter und legt fest, ob das Gateway lokal arbeitet. Eine falsche Konfiguration führt zu inkonsistentem Routing oder ungewolltem Zugriff auf externe Systeme. Nach der Registrierung erfolgt die Aktivierung des zugehörigen ICF-Knotens. Dieser Schritt entscheidet darüber, ob der Service über HTTP erreichbar ist. Ohne aktive ICF-Struktur bleibt der Service im Gateway registriert, ist jedoch nicht nutzbar. Zusätzlich verlangt die Laufzeit, dass jeder Service initial aufgerufen wird. Dieser Zugriff erzeugt Metadaten und initialisiert interne Caches.

Servicebereitstellung und interne Verarbeitung im Gateway

Nach der technischen Aktivierung und der Zuweisung von Rollen greift die eigentliche Serviceverarbeitung im Gateway-Stack. Ein OData-Service besteht intern aus mehreren Schichten, die Anfragen entgegennehmen, auf ABAP-Logik abbilden und strukturierte Antworten erzeugen. Die Implementierung erfolgt über definierte Serviceklassen und Methoden, die HTTP-Operationen wie Lesen, Anlegen oder Ändern auf konkrete Datenzugriffe abbilden.

Im Entwicklungsmodell wird zunächst ein Datenmodell definiert, das Entitäten und Beziehungen beschreibt. Die Zuordnung von Daten erfolgt über ein Mapping zwischen Serviceentitäten und Backend-Strukturen, wodurch bestehende Datenmodelle weiterverwendet werden können. Dieses Mapping kann auf Datenbanktabellen, CDS-Views (Core Data Services) oder RFC-Strukturen basieren und bestimmt, welche Daten ein Service tatsächlich bereitstellt.

Darauf aufbauend implementiert die Laufzeit die notwendigen Methoden, die eingehende Requests verarbeiten und an Backend-Funktionen weiterreichen. Die Serviceimplementierung unterscheidet zwischen automatisch generierten Methoden und explizit implementierter Logik, die nur bei Bedarf ergänzt wird. Nur die tatsächlich benötigten Operationen werden implementiert, sodass nicht jede mögliche HTTP-Methode zwangsläufig im Service vorhanden ist. Diese interne Struktur trennt Servicebeschreibung, Datenmodell und Implementierungslogik. Die Trennung zwischen Modell und Implementierung erlaubt es, Änderungen am Datenmodell vorzunehmen, ohne die Serviceimplementierung vollständig neu entwickeln zu müssen.

Dadurch lässt sich der Zugriff granular steuern und an bestehende Geschäftslogik anbinden, ohne dass externe Clients direkte Kenntnisse über Tabellen oder Funktionsbausteine benötigen. Ein Service kann sowohl neu entwickelt als auch auf Basis vorhandener Backend-Logik generiert werden, wodurch sich Integrationsszenarien flexibel abbilden lassen.

Rollenmodell im Backend und Servicebindung

Die Zugriffskontrolle erfolgt im Backend über Rollen, die in der Transaktion PFCG (Profile Generator) definiert werden. PFCG bildet das zentrale Werkzeug zur Erstellung und Pflege von Rollen und Berechtigungsprofilen im ABAP-System. Innerhalb dieser Transaktion werden Menüs, Berechtigungsobjekte und zugehörige Werte kombiniert, aus denen das System ein ausführbares Berechtigungsprofil generiert.

Dieses Profil wird Benutzern zugewiesen und bestimmt, auf welche OData-Services, Anwendungen und Funktionen ein Zugriff möglich ist. Jede Rolle enthält Berechtigungsdaten, die aus Servicedefinitionen generiert oder manuell ergänzt werden. Für OData-basierte Anwendungen unterscheidet die Plattform zwischen OData V2 und OData V4. V2-Services werden über SAP Gateway Business Suite Enablement eingebunden. V4-Services nutzen Servicegruppen und Zuordnungen im Backend.

Die Rollendefinition beginnt mit einem Berechtigungsvorschlag, der auf dem technischen Servicenamen basiert. Dieser Vorschlag enthält initial nur eingeschränkte Rechte und muss angepasst werden. Nach der Pflege generiert das System ein Berechtigungsprofil, das Benutzern zugeordnet wird. Die Zuordnung von Rollen bestimmt den effektiven Zugriff. Ohne passende Rolle kann ein Benutzer einen Service nicht nutzen, selbst wenn dieser technisch aktiviert ist. Gleichzeitig reicht eine Rolle ohne aktivierten Service nicht aus, da der Zugriff an der Gateway-Schicht endet.

Für komplexe Anwendungen ergänzt das System zusätzliche Rollen oder Varianten von Berechtigungsvorschlägen. Diese Varianten differenzieren zwischen Anzeige- und Änderungsrechten oder zwischen verschiedenen Anwendungsszenarien.

Autorisierungsprüfung innerhalb des Gateway-Stacks

Die Autorisierung erfolgt mehrstufig. Das Gateway prüft zunächst technische Zugriffsdaten und leitet die Anfrage an das Backend weiter. Dort greifen klassische Berechtigungsobjekte und rollenbasierte Prüfungen.

Die Prüfung basiert auf den im Backend gepflegten Berechtigungen. Das Gateway selbst führt keine vollständige semantische Prüfung durch, sondern delegiert diese an die ABAP-Logik. Damit ergibt sich eine klare Trennung zwischen Transportebene und Fachlogik.

Für OData V4-Services erfolgt die Zuordnung über Servicegruppen. Eine Rolle enthält die Zuordnung zu einer Servicegruppe, die wiederum mehrere Endpunkte kapselt. Dadurch lässt sich der Zugriff granular steuern.

Im Kontext von Integrationsszenarien wird häufig ein dedizierter technischer Benutzer verwendet. Dieser Benutzer erhält eine spezifische Rolle mit minimalem Berechtigungsumfang. Für Services wie LASTMILEVISITLIST erfolgt die Zuordnung über die Servicegruppe API_LASTMILEVISITLIST. Ohne diese Zuordnung bleibt der Zugriff blockiert.

Gateway-Sicherheitsmechanismen auf Netzwerkebene

Neben rollenbasierter Kontrolle spielt die Gateway-Sicherheitskonfiguration eine zentrale Rolle. Seit neueren Kernel-Versionen akzeptiert das Gateway keine Verbindungen mehr automatisch. Jede eingehende oder ausgehende Verbindung benötigt eine explizite Freigabe. Reginfo definiert erlaubte eingehende Verbindungen und registrierte Programme. Secinfo kontrolliert ausgehende Verbindungen und Startvorgänge externer Programme. Ohne passende Einträge blockiert das Gateway den Zugriff.

Eine typische Konfiguration erlaubt nur definierte Programme und Hosts. Generische Freigaben erhöhen die Angriffsfläche teilweise erheblich. Die Reihenfolge der Regeln beeinflusst das Ergebnis, da das Gateway die erste passende Regel auswertet. Für Analysezwecke existiert ein Simulationsmodus. Dieser Modus protokolliert undefinierte Verbindungen und erlaubt deren Bewertung ohne unmittelbare Blockierung. Nach Abschluss der Analyse muss der Modus deaktiviert werden, da er keine echte Schutzwirkung bietet. Die Sicherheitskonfiguration ergänzt damit die rollenbasierte Kontrolle und verhindert unerlaubte technische Verbindungen auf Netzwerkebene

Zusammenspiel von Serviceaktivierung, Rollen und Gateway

Die Absicherung von OData-Services basiert auf drei voneinander abhängigen Ebenen:

• Die erste Ebene bildet die technische Aktivierung im Gateway. Ohne aktive Registrierung und ICF-Knoten existiert kein Zugriffspfad.
• Die zweite Ebene umfasst das Rollenmodell im Backend. Rollen definieren, welche Services ein Benutzer aufrufen darf und welche Operationen erlaubt sind.
• Die dritte Ebene liegt in der Gateway-Sicherheitskonfiguration. Diese kontrolliert, welche Systeme und Programme überhaupt mit dem Gateway kommunizieren dürfen.

Ein vollständiges Sicherheitskonzept berücksichtigt alle drei Ebenen gleichzeitig. Eine isolierte Betrachtung einzelner Komponenten führt zu Lücken. Ein aktivierter Service ohne restriktive Rollen erlaubt ungewollten Zugriff. Eine korrekte Rollenvergabe ohne Gateway-Filter ermöglicht unerlaubte Verbindungen auf Netzwerkebene.

Die Integration in Fiori-Szenarien erhöht die Komplexität, da zusätzliche Komponenten wie Reverse Proxy und Frontend-Server beteiligt sind. Jede dieser Komponenten beeinflusst die Sicherheitsarchitektur und erfordert eine abgestimmte Konfiguration.