Das SAP Gateway ist eine der unscheinbarsten Komponenten eines SAP-Systems – und eine der kritischsten. Über das Gateway laufen alle RFC-Verbindungen, es kann externe Programme starten und lässt Programme anderer Systeme sich als RFC-Server registrieren. Sind die Zugriffsregeln zu offen, kann ein Angreifer im Netzwerk unter Umständen Betriebssystembefehle mit den Rechten des SAP-Systembenutzers ausführen. Dieser Beitrag zeigt, wie Sie das Gateway Schritt für Schritt absichern, ohne laufende Schnittstellen zu unterbrechen.
Wofür das Gateway zuständig ist
Jede ABAP-Instanz hat einen Gateway-Prozess (Transaktion SMGW). Er erfüllt drei Aufgaben, und für jede gibt es eine eigene Zugriffsliste:
| Aufgabe | Zugriffsliste | Profilparameter |
|---|---|---|
| Externe Programme starten (z. B. für Drucken, Konvertierung, Integrationen) | secinfo | gw/sec_info |
| Registrierung externer RFC-Server (z. B. Konnektoren, Middleware) | reginfo | gw/reg_info |
| Weiterleitung von Verbindungen über das Gateway an andere Systeme | prxyinfo | gw/prxy_info |
Fehlen diese Dateien oder erlauben sie pauschal alles (USER=* HOST=*), ist das Gateway faktisch ungeschützt. In Sicherheitsprüfungen gehört dieser Punkt deshalb regelmässig zu den Befunden mit hoher Priorität.
Die wichtigsten Profilparameter
| Parameter | Empfehlung | Bedeutung |
|---|---|---|
| gw/acl_mode | 1 | Fehlen die Zugriffslisten, sind nur Zugriffe aus dem eigenen System erlaubt |
| gw/sec_info, gw/reg_info, gw/prxy_info | auf gepflegte Dateien zeigen | Pfad zu den Zugriffslisten |
| gw/sim_mode | 0 im Betrieb, 1 nur zur Einführung | Simulationsmodus: nicht passende Zugriffe werden erlaubt und protokolliert |
| gw/monitor | 1 | Das Gateway lässt sich nur lokal administrieren |
| gw/rem_start | DISABLED, falls nicht benötigt | Verhindert das Starten von Programmen auf entfernten Hosts |
| gw/reg_no_conn_info | gemäss aktueller SAP-Empfehlung | Zusätzliche Schutzmechanismen für registrierte Programme |
Die Basisempfehlungen für die beiden wichtigsten Dateien beschreibt SAP in Hinweis 1408081. Prüfen Sie dort und in der Dokumentation Ihres Releases die jeweils gültigen Werte, denn SAP hat die Standardwerte über die Jahre verschärft.
Aufbau der Regeln
Beide Dateien beginnen mit der Zeile #VERSION=2. Die Regeln werden von oben nach unten gelesen; die erste passende Regel entscheidet. P erlaubt (permit), D verbietet (deny). Trifft keine Regel zu, wird der Zugriff abgelehnt. Zwei Schlüsselwörter erleichtern die Pflege: local steht für den Host des Gateways, internal für alle Applikationsserver des eigenen Systems.
Beispiel reginfo
#VERSION=2
P TP=IGS.* HOST=internal,local CANCEL=internal,local ACCESS=*
P TP=MEIN_KONNEKTOR HOST=10.10.20.15 CANCEL=10.10.20.15,local ACCESS=internal,local
P TP=* HOST=internal,local CANCEL=internal,local ACCESS=internal,localDie erste Zeile erlaubt den Programmen des Internet Graphics Service die Registrierung von den eigenen Servern aus. Die zweite erlaubt einen bestimmten Konnektor von genau einem Host. ACCESS legt fest, wer das registrierte Programm nutzen darf, CANCEL, wer die Registrierung beenden darf. Die letzte Zeile ist die allgemeine Regel für alles Interne. Die Namen und Adressen im Beispiel sind Platzhalter.
Beispiel secinfo
#VERSION=2
P USER=* USER-HOST=internal,local HOST=internal,local TP=*Diese Grundregel erlaubt das Starten von Programmen nur aus dem eigenen System heraus und nur auf den eigenen Servern. Externe Benutzer oder Hosts benötigen eine eigene, möglichst enge Regel mit konkretem Programmnamen.
Vorgehen: absichern, ohne Schnittstellen zu brechen
Der grösste Respekt gilt meist der Frage, welche Schnittstellen nach einer Verschärfung nicht mehr funktionieren. Mit einem schrittweisen Vorgehen lässt sich das Risiko klein halten:
- Bestandsaufnahme: In SMGW die aktuell registrierten Programme und aktiven Verbindungen ansehen. In SM59 die RFC-Destinationen vom Typ T (TCP/IP) prüfen – sie verweisen auf registrierte oder gestartete Programme.
- Protokollierung einschalten: Im Gateway-Monitor die Protokollierung für secinfo- und reginfo-Zugriffe aktivieren und über mehrere Wochen laufen lassen – idealerweise über einen Monats- oder Quartalsabschluss hinweg, damit auch selten genutzte Schnittstellen erfasst werden.
- Regeln ableiten: Aus dem Protokoll die tatsächlich benötigten Programme, Hosts und Benutzer ermitteln und als enge Regeln formulieren. Allgemeine Platzhalter nur für
internalundlocalverwenden. - Simulation: Die neuen Dateien mit
gw/sim_mode = 1aktivieren. Zugriffe, die keine Regel treffen, werden weiter erlaubt, aber protokolliert – so werden fehlende Regeln sichtbar. - Scharf schalten: Nach einer ruhigen Simulationsphase den Simulationsmodus beenden. Die Dateien lassen sich in SMGW ohne Neustart neu einlesen.
- Im Betrieb halten: Jede neue Schnittstelle bekommt eine eigene Regel – als fester Schritt im Änderungsprozess.
Über das Gateway hinaus: RFC insgesamt absichern
- RFC-Destinationen: In SM59 keine Dialogbenutzer und keine weitreichenden Berechtigungen in hinterlegten Anmeldedaten. Technische Benutzer erhalten den Typ «System» oder «Kommunikation» und nur die nötigen Rollen.
- Vertrauensbeziehungen: Trusted-RFC-Verbindungen (SMT1/SMT2) nur zwischen Systemen gleicher oder höherer Schutzstufe; nie von Entwicklung nach Produktion.
- Berechtigungen: Das Objekt S_RFC so eng wie möglich vergeben; Vollberechtigungen auf Funktionsgruppen vermeiden.
- Verschlüsselung: RFC-Verbindungen über SNC verschlüsseln, insbesondere zwischen Rechenzentren und in die Cloud.
- Freigegebene Funktionsbausteine: Mit Unified Connectivity (UCON) lässt sich festlegen, welche remotefähigen Funktionsbausteine von aussen überhaupt aufgerufen werden dürfen.
Viele Gateway-Befunde gehen auf Systeme zurück, die über Jahre gewachsen sind. Ein guter Zeitpunkt für die Bereinigung ist ein Upgrade oder eine Migration – mehr dazu in unserem Beitrag SAP Applikationsserver und Applikationsschicht erklärt. Für die Nachvollziehbarkeit der Zugriffe empfehlen wir zusätzlich ein sauber konfiguriertes Security Audit Log.
Häufige Fragen
Muss das System für neue Gateway-Regeln neu gestartet werden?
Wie lange sollte die Protokollierung vor der Umstellung laufen?
Gilt das auch für SAP S/4HANA?
Fazit
Ein offenes Gateway ist eines der grössten technischen Risiken in SAP-Landschaften – und eines der am besten beherrschbaren. Mit gepflegten Zugriffslisten, restriktiven Parametern und einem schrittweisen Vorgehen über Protokollierung und Simulation lässt es sich ohne Betriebsunterbruch absichern. Gerne prüfen wir den Stand in Ihren Systemen im Rahmen unserer SAP Security Beratung.
