Flashizzle/peopleimages.com - st

SAP-Webzugriffe kontrollieren und Angriffsflächen reduzieren

ICF-Services stellen HTTP-Endpunkte im ABAP-Stack bereit. Jeder aktivierte Service öffnet einen Webzugang zum SAP-System und stellt damit eine potenzielle Angriffsfläche dar.

SAP-Systeme stellen zahlreiche Funktionen über Webprotokolle bereit. Grundlage bildet das Internet Communication Framework (ICF) in SAP NetWeaver Application Server ABAP. Diese Komponente verarbeitet HTTP- und HTTPS-Anfragen aus externen Clients und übergibt sie an ABAP-Anwendungen. Browser, REST-Clients, OData-Services oder Web-Frontends greifen über diesen Mechanismus auf Funktionen des Systems zu.

Der Application Server ABAP bildet die zentrale Laufzeitumgebung vieler SAP-Anwendungen, was Geschäftslogik, Datenzugriffe und Integrationsprozesse beinhaltet. Programme, Reports, Transaktionen und Hintergrundprozesse laufen in dieser Umgebung. Auch zahlreiche Webfunktionen greifen direkt auf diese ABAP-Komponenten zu. Damit Browser, Analysewerkzeuge oder REST-Clients mit diesen Anwendungen kommunizieren können, benötigt der ABAP-Stack eine Webschnittstelle. Hier setzt das Internet Communication Framework an.

Internet Communication Framework als Web-Gateway des ABAP-Stacks

Das ICF verarbeitet Webanfragen und übergibt sie an ABAP-Anwendungen. Externe Clients senden HTTP-Requests an das SAP-System, das Framework identifiziert den zuständigen Service und startet anschließend die entsprechende ABAP-Logik. Dadurch lassen sich Webanwendungen, REST-Schnittstellen, OData-Services und analytische Funktionen direkt aus dem ABAP-System heraus bereitstellen. Ohne diese Infrastruktur könnten moderne Weboberflächen, Integrationsschnittstellen oder Analysewerkzeuge nicht auf SAP-Anwendungen zugreifen. Gleichzeitig entsteht durch jeden erreichbaren HTTP-Endpunkt ein möglicher Angriffspunkt, weshalb eine kontrollierte Verwaltung der ICF-Services zu den zentralen Sicherheitsmaßnahmen in SAP-Systemen gehört.

Jede Anfrage erreicht das System zunächst über den Internet Communication Manager (ICM). Dieser verarbeitet Netzwerkverbindungen und entscheidet, ob eine Anfrage an die Java- oder an die ABAP-Umgebung weitergeleitet wird. Für ABAP-Anwendungen übernimmt anschließend das Internet Communication Framework die Verarbeitung.

Das Framework fungiert damit als zentrale Vermittlungsschicht zwischen Webprotokollen und ABAP-Programmen. Sobald eine HTTP-Anfrage eintrifft, erzeugt das System ein Steuerobjekt der Klasse CL_HTTP_SERVER. Dieses Objekt enthält die Datenstrukturen für Anfrage und Antwort. Die Interfaces IF_HTTP_REQUEST und IF_HTTP_RESPONSE ermöglichen Zugriff auf HTTP-Header und Nachrichten-Body.

Architektur der ICF-Schnittstellen in SAP NetWeaver Application Server ABAP
Abbildung 1: Architektur der ICF-Schnittstellen im ABAP-Stack mit IF_HTTP_SERVER, Request- und Response-Objekten sowie den zentralen Interfaces zur Verarbeitung von HTTP-Anfragen und -Antworten.

Anwendungen implementieren HTTP-Request-Handler, die innerhalb dieser Struktur ausgeführt werden. Ein Handler verarbeitet die Anfrage, ruft ABAP-Logik auf und erstellt anschließend die Antwort für den Client. Dieser Mechanismus bildet die Grundlage sämtlicher Webzugriffe auf SAP-Systeme.

Rolle der ICF-Services im SAP-System

ICF-Services definieren die eigentlichen Einstiegspunkte für HTTP-Anfragen. Jeder Service stellt einen logischen Endpunkt dar, der einen oder mehrere HTTP-Handler ausführt. Die Konfiguration erfolgt in der Transaktion SICF. Dort bildet das System eine hierarchische Struktur aus Services, die als ICF-Baum bezeichnet wird. Jeder Eintrag besitzt einen übergeordneten Knoten und einen eigenen Servicenamen. Der vollständige Pfad innerhalb dieses Baums bestimmt die URL, über die ein Service erreichbar ist.

Ein typischer Zugriff auf einen ICF-Service erfolgt über eine URL mit einem festen Aufbau. Sie besteht aus dem verwendeten Protokoll, dem Servernamen, dem Port sowie dem anschließenden Pfad zum jeweiligen Service. In SAP-BW-Systemen beginnt dieser Pfad häufig mit dem Segment sap/bw, gefolgt vom eigentlichen Servicenamen. Die konkrete URL hängt von Protokoll, Hostname und Port des Systems ab. Administratoren können den generierten URL-Präfix über den Funktionsbaustein RSBB_URL_PREFIX_GET ermitteln. Dieser Aufbau ermöglicht direkten Zugriff auf Funktionen des SAP-Systems über HTTP. Ein aktivierter Service reagiert auf entsprechende Webanfragen und startet die hinterlegte ABAP-Logik.

HTTP-Verarbeitung im ICF

Das Internet Communication Framework stellt eine vollständige Infrastruktur zur Verarbeitung von HTTP-Requests innerhalb von ABAP-Workprozessen bereit. Nach Eingang einer Anfrage durchläuft der Datenstrom mehrere Schichten der Architektur. Der Internet Communication Manager übernimmt Netzwerkkommunikation und Übergabe an den ABAP-Stack. Das ICF identifiziert anschließend den passenden Service anhand des URL-Pfades. Der Service startet einen HTTP-Handler. Dieser Handler greift über das Interface IF_HTTP_SERVER auf Anfrage- und Antwortobjekte zu.

Das Anfrageobjekt enthält sämtliche Informationen der HTTP-Anfrage. Dazu gehören Header, Parameter und Body. Der Handler verarbeitet diese Daten, ruft ABAP-Programme auf und erzeugt eine Antwort. Das Antwortobjekt enthält Statuscode, Header und Daten der HTTP-Antwort. Nach Abschluss der Verarbeitung sendet das Framework die Antwort über den Internet Communication Manager zurück an den Client. Dieses Modell erlaubt es, Webanwendungen, REST-Services oder Integrationsschnittstellen vollständig im ABAP-Stack zu implementieren.

Bedeutung von ICF-Services für webbasierte SAP-Funktionen

Viele SAP-Funktionen basieren auf ICF-Services. Dazu gehören Web-Dynpro-Anwendungen, REST-Schnittstellen oder UI5-Frontends. SAP BW-Systeme liefern mehrere ICF-Services aus, die unterschiedliche Aufgaben erfüllen. Web-Dynpro-Komponenten benötigen öffentliche Ressourcenservices für Icons, Piktogramme oder UI-Elemente. Analysewerkzeuge greifen über eigene Services auf Reporting-Funktionen zu. Modeling-Tools verwenden REST-basierte Endpunkte für Entwicklungsoperationen.

Weitere Services unterstützen Funktionen für Metadatenverwaltung, Hierarchiepflege oder Master-Data-Bearbeitung. Reporting-Schnittstellen greifen über REST-Services oder XML-for-Analysis-Protokolle auf analytische Daten zu. Diese Architektur ermöglicht es, komplexe Anwendungen über Webschnittstellen zu betreiben. Gleichzeitig vergrößert jede aktivierte HTTP-Schnittstelle die Angriffsfläche eines Systems.

Sicherheitsrisiken aktiver ICF-Services

Jeder aktivierte ICF-Service stellt einen potenziellen Angriffspunkt dar. Angreifer können HTTP-Requests direkt an diese Endpunkte senden und versuchen, Funktionen oder Daten des Systems auszunutzen. Ein Service wird über seine URL angesprochen. Sobald ein Service aktiv ist, akzeptiert das System entsprechende Anfragen über HTTP oder HTTPS. Ohne geeignete Zugriffskontrollen lassen sich interne Funktionen über Webzugriffe aufrufen.

Ein Risiko ergibt sich durch Services ohne Authentifizierung. Solche Endpunkte erlauben Zugriff ohne Benutzeranmeldung. Auch Services mit hinterlegten Anmeldedaten können Angriffsvektoren darstellen. Die Zugriffskontrolle erfolgt über das Berechtigungsobjekt S_ICF. Rollen mit dieser Berechtigung erlauben das Aufrufen eines ICF-Service über eine URL. Eine zu großzügige Rollenvergabe erweitert den Kreis möglicher Angreifer innerhalb eines Systems. Angreifer analysieren häufig aktivierte Services und versuchen anschließend, bekannte Schwachstellen oder Fehlkonfigurationen auszunutzen. Daher gilt eine einfache Grundregel: Nur benötigte ICF-Services dürfen aktiv sein.

Minimierung der Angriffsfläche

Bei einer Standardinstallation befinden sich ICF-Services zunächst im deaktivierten Zustand. Erst nach Aktivierung reagieren sie auf Webanfragen. Dieses Verhalten reduziert automatisch die Angriffsfläche eines Systems. Administratoren aktivieren nur diejenigen Services, die für konkrete Funktionen benötigt werden. Das SAP Security Baseline Template empfiehlt zusätzlich die Deaktivierung bestimmter Test- oder Diagnose-Services. Dazu zählen unter anderem:

  • sap bc echo
  • sap bc xrfc
  • sap bc error
  • sap bc soap rfc

Solche Endpunkte besitzen in produktiven Umgebungen keinen funktionalen Nutzen. Ihre Aktivierung erweitert lediglich mögliche Angriffsfläche.

Kontrolle der ICF-Servicehierarchie

Die Struktur des ICF-Baums basiert auf zwei Systemtabellen. Die Tabelle ICFSERVICE enthält Servicenamen und deren übergeordnete Knoten. Die Tabelle ICFSERVLOC enthält zusätzlich Informationen über den Aktivierungsstatus eines Service. Diese Tabellen definieren gemeinsam die Struktur des ICF-Baums in der Transaktion SICF. Jeder Service besitzt einen Parent-Knoten, wodurch eine hierarchische Struktur entsteht.

Fehlerhafte Transporte oder manuelle Änderungen können Inkonsistenzen zwischen diesen Tabellen erzeugen. In solchen Fällen stimmen Struktur und Aktivierungsstatus eines Services nicht mehr überein. SAP stellt zur Analyse solcher Probleme den Report ICFTREE_CONSISTENCY bereit. Dieser überprüft die Integrität des ICF-Baums. Das Funktionsmodul REPAIR_HTTPTREE kann anschließend inkonsistente Einträge korrigieren und verwaiste Knoten neu zuordnen. Solche Wartungsmaßnahmen verhindern fehlerhafte Servicepfade und unerwartetes Verhalten der SICF-Konfiguration.

Aktivierung und Verwaltung von ICF-Services

Die zentrale Verwaltung erfolgt über die Transaktion SICF. Dort lassen sich Services anzeigen, aktivieren oder deaktivieren. Ein Service reagiert erst auf HTTP-Anfragen, nachdem er aktiviert wurde. Administratoren können einen Service direkt im Kontextmenü aktivieren. Für größere Landschaften stehen automatisierte Aktivierungsmechanismen zur Verfügung. Tasklisten im Aufgabenmanager ermöglichen die Massenaktivierung von Services.

Ein Beispiel bildet die Taskliste SAP_BASIS_ACTIVATE_ICF_NODES. Diese kann über die Transaktion STC01 ausgeführt werden. Parameter definieren dabei den Pfad eines Service sowie den zugehörigen virtuellen Host. Nach Ausführung aktiviert das System mehrere Services gleichzeitig. Dieser Ansatz wird häufig für OData- oder UI-Anwendungen verwendet, deren Webkomponenten über ICF-Nodes bereitgestellt werden.

Zusammenhang zwischen ICF-Services und modernen SAP-Webtechnologien

Moderne SAP-Frontends greifen nahezu ausschließlich über HTTP-basierte Services auf Backend-Funktionen zu. Dazu gehören UI5-Anwendungen, OData-Services, REST-Schnittstellen oder Web-Dynpro-Komponenten. Diese Technologien basieren intern auf denselben ICF-Mechanismen. Die URL-Struktur eines Service definiert den Einstiegspunkt einer Webanwendung.

Auch analytische Funktionen im SAP-Umfeld nutzen ICF-Services. REST-basierte Reporting-Schnittstellen oder XML-for-Analysis-Endpunkte liefern Daten an Analysewerkzeuge oder externe Anwendungen. Dadurch ergibt sich eine enge Kopplung zwischen Webarchitektur und ABAP-Anwendungslogik. Eine korrekte Konfiguration der ICF-Services beeinflusst daher direkt Sicherheit und Stabilität der gesamten Plattform.

Webzugriffe steuern

Ein wirksames Sicherheitskonzept für SAP-Systeme berücksichtigt mehrere Aspekte der ICF-Konfiguration. Administratoren analysieren zunächst alle aktiven Services im System. Anschließend erfolgt eine Bewertung der jeweiligen Funktion. Services ohne geschäftliche Nutzung bleiben deaktiviert. Zugriffsrechte sollten ausschließlich an Benutzer vergeben werden, die diese Funktionen benötigen. Rollen mit S_ICF-Berechtigungen erhalten eine restriktive Konfiguration.

Zusätzlich erfolgt eine regelmäßige Überprüfung auf Services ohne Authentifizierung. Solche Endpunkte benötigen besondere Aufmerksamkeit. Diese Maßnahmen reduzieren die Angriffsfläche eines Systems erheblich. Gleichzeitig bleibt die notwendige Funktionalität für Webanwendungen erhalten.

Bedeutung für die SAP-Sicherheitsarchitektur

ICF-Services bilden eine zentrale Schnittstelle zwischen SAP-Systemen und Webtechnologien. Jede moderne Benutzeroberfläche, Integrationsschnittstelle oder REST-API nutzt diese Infrastruktur. Aus sicherheitstechnischer Sicht stellt das Internet Communication Framework daher einen kritischen Bestandteil der SAP-Architektur dar.

Eine konsequente Verwaltung aktivierter Services, kontrollierte Zugriffskonzepte und regelmäßige Integritätsprüfungen des ICF-Baums reduzieren Risiken erheblich. Unternehmen sichern auf diese Weise ihre SAP-Systeme gegen unkontrollierte Webzugriffe ab und behalten gleichzeitig die volle Kontrolle über HTTP-basierte Integrationsschnittstellen.

Erfahren Sie mehr über Anwendungs- und Plattformsicherheit