SAP S/4HANA: Kommunikationsarchitektur und Sicherheit

Die Kommunikation innerhalb von SAP-Systemen

Präsentationsschicht, Applikationsserver, Message Server, Dispatcher, Internet Communication Manager (ICM) und angebundene Systeme bilden in diesem Kontext einen Verbund, der interne und externe Datenflüsse steuert. Jeder Kommunikationspfad nutzt ein definiertes Protokoll und einen festgelegten Sicherheitsmechanismus. Die Kombination aus Protokollwahl, Authentifizierung und Transportverschlüsselung bestimmt den Schutzgrad der übertragenen Informationen.

Im ABAP-Stack übernimmt der Dispatcher die Annahme eingehender Requests und weist sie den verfügbaren Workprozessen der jeweiligen Instanz zu. Der Message Server verwaltet Logon-Gruppen und organisiert die Verteilung der Benutzeranmeldungen auf mehrere Applikationsserver-Instanzen. Die Kommunikation zwischen diesen Komponenten erfolgt über SAP-interne Protokolle innerhalb der Systemlandschaft und bleibt auf interne Netzsegmente beschränkt. Der Internet Communication Manager stellt die Verbindung zwischen HTTP-Protokollen und der ABAP-Laufzeitumgebung her. Er beendet TLS-Sitzungen, prüft Zertifikate und übergibt die eingehenden Requests an das Internet Communication Framework zur weiteren Verarbeitung.

DIAG und die interne GUI-Kommunikation

Das DIAG-Protokoll verbindet SAP GUI direkt mit dem Applikationsserver und bildet den klassischen Dialogkanal zwischen Benutzeroberfläche und ABAP-Laufzeitumgebung. DIAG steht für Dynamic Information and Action Gateway und überträgt Dialogschritte, Bildschirminhalte, Eingaben, Parameter sowie Steuerinformationen der Transaktion. Neben fachlichen Transaktionsdaten gelangen darüber auch Customizing-Daten und Systemkonfigurationen in die Verarbeitungsschicht.

In funktionalen Erweiterungen im Bereich Vergütungsmanagement fließen sämtliche Customizing-Daten über diesen Kanal. In Bankzenarien gelangen Kundenkennungen, Kontostände und Transaktionsinformationen ebenfalls über DIAG in die Verarbeitungsschicht. Der Schutzbedarf umfasst daher sowohl Konfigurationsintegrität als auch Vertraulichkeit geschäftskritischer Inhalte.

Secure Network Communications (SNC) ergänzt DIAG um kryptographische Mechanismen. SNC kapselt das Protokoll in eine verschlüsselte Sitzung, nutzt X.509-Zertifikate oder Kerberos-Tickets zur Authentifizierung und stellt Integritätsschutz über digitale Signaturen sicher. Die Implementierung bindet sich an die SAP Cryptographic Library oder externe GSS-API-Komponenten an. Dadurch bleibt der interne Protokollcharakter erhalten, ohne auf Verschlüsselung zu verzichten. Der Message Server verteilt DIAG-Verbindungen anhand von Logon-Gruppen. Die Lastverteilung erfolgt innerhalb definierter Serverzonen und reduziert die Notwendigkeit externer Komponenten für diesen spezifischen Kommunikationspfad.

HTTP, HTTPS und SAP Gateway

Browserbasierte Anwendungen stellen Verbindungen über HTTP oder HTTPS zum SAP-Gateway her. Das Gateway übernimmt die Rolle eines Vermittlers zwischen OData-Services und der ABAP-Logik im Backend. Der Internet Communication Manager nimmt eingehende TLS-Verbindungen an, führt den TLS-Handshake aus und prüft Zertifikate anhand der im System hinterlegten Trust Stores. Protokollversionen, unterstützte Cipher-Suites und Perfect Forward Secrecy (PFS) lassen sich auf Systemebene konfigurieren.

OData-Services liefern strukturierte Daten im JSON- oder Atom-Format. Fiori-Anwendungen greifen auf diese Services zu, um Daten zu lesen oder zu schreiben. Der Schutzbedarf richtet sich nach dem jeweiligen Anwendungskontext. Transaktionsdaten, Finanzinformationen oder personenbezogene Stammdaten erfordern eine durchgängige TLS-Verschlüsselung. Zusätzlich kommen Authentifizierungsverfahren wie OAuth 2.0 oder SAML zum Einsatz. OAuth 2.0-Flows verwenden Access Tokens, die das Gateway überprüft. SAML Assertions realisieren Single Sign-On (SSO) zwischen Identity Provider und SAP-System. Principal Propagation überträgt die Identität eines Benutzers über mehrere Systemgrenzen hinweg und erhält den fachlichen Kontext innerhalb einer Prozesskette.

ICF-Services (Internet Communication Framework) definieren die technischen Endpunkte für HTTP-basierte Kommunikation. Eine restriktive Aktivierung reduziert die Angriffsfläche eines Systems. Nicht benötigte Services lassen sich deaktivieren und Authentifizierungsmethoden pro Service festlegen. HTTP Security Session Management schützt Sitzungs-Cookies durch die Attribute Secure und HttpOnly. Das System verhindert damit den Zugriff clientseitiger Skripte auf sicherheitsrelevante Sitzungsinformationen.

RFC, tRFC, qRFC und bgRFC

Remote Function Call (RFC) bildet eine zentrale Kommunikationsschnittstelle zwischen SAP-Systemen. Über RFC ruft ein System die Schnittstelle eines Funktionsbausteins in einem entfernten System auf und übergibt Parameter an die dortige ABAP-Laufzeitumgebung. Das Zielsystem verarbeitet den Aufruf im zugewiesenen Workprozess und liefert Rückgabewerte direkt an den aufrufenden Kontext zurück.

Ein synchroner RFC blockiert den aufrufenden Prozess bis zur vollständigen Verarbeitung im Zielsystem. Ein transaktionaler RFC erweitert dieses Modell um eine sichere Übertragung mit Wiederholmechanismus, falls die Verbindung während der Verarbeitung unterbrochen wird. Queued RFC ergänzt zusätzlich eine Warteschlange, in der Aufrufe in definierter Reihenfolge abgearbeitet werden, sodass abhängige Geschäftsprozesse sequenziell im Zielsystem ausgeführt werden. bgRFC ergänzt diese Mechanismen um Hintergrundverarbeitung mit definierter Queue-Steuerung. Jede dieser Varianten transportiert fachliche Nutzdaten, die von einfachen Stammdatensätzen bis zu komplexen Finanztransaktionen reichen.

Secure Network Communications (SNC) sichert RFC-Verbindungen durch Verschlüsselung und gegenseitige Authentifizierung der beteiligten Systeme. Die RFC-Kommunikation nutzt dazu eine Security Layer, die Integrität, Vertraulichkeit und Identitätsprüfung der Verbindung sicherstellt. RFC-Ziele definieren das entfernte Zielsystem sowie die technischen Parameter für die Verbindung. Dazu gehören Hostadresse, Systemnummer, Kommunikationsprotokoll, Anmeldekontext und Sicherheitsoptionen. SAP unterscheidet mehrere Typen. Typ 3 beschreibt Verbindungen zu einem entfernten ABAP-System. Typ T definiert TCP/IP-Kommunikation zu externen Programmen. Typ G ermöglicht HTTP- oder HTTPS-basierte Aufrufe zu Webservices oder APIs.

Die Verwaltung dieser Ziele erfolgt über die Systemkonfiguration. Technische Benutzerkonten dienen ausschließlich der Kommunikation zwischen Systemen. Ihre Berechtigungen beschränken sich auf die Funktionsbausteine oder Services, die für den jeweiligen Integrationsprozess benötigt werden.

SOAP, IDoc und serviceorientierte Integration

SOAP-Schnittstellen ergänzen RFC um standardisierte Webservices. Sie transportieren XML-Nachrichten über HTTPS und können zusätzlich XML-Signaturen und Verschlüsselung auf Nachrichtenebene einsetzen. Web Services Security schützt Integrität und Authentizität einzelner Payloads unabhängig vom Transportkanal. Kreditprüfungen oder externe Beschaffungsprozesse nutzen diese Mechanismen für strukturierte Interaktion mit Fremdsystemen.

Die IDoc-basierte Kommunikation unterstützt asynchrone Dokumentenübertragung. Bestellungen, Lieferavise oder Rechnungen durchlaufen definierte Partnerprofile und Prozesscodes. Die technische Übertragung erfolgt über tRFC oder HTTP-basierte Mechanismen. Der Schutzbedarf orientiert sich am Inhalt des Dokuments. Finanzrelevante Belege verlangen Verschlüsselung und Zugriffsbeschränkung. Protokollierung und Monitoring ergänzen den technischen Schutz um Nachvollziehbarkeit.

Event-basierte Architekturen nutzen SAP Event Mesh oder Advanced Event Mesh. Ereignisse gelangen über AMQP oder MQTT an abonnierende Systeme. TLS schützt den Transport, während Zugriffsrichtlinien definieren, welche Publisher oder Subscriber teilnehmen dürfen. Ereignisse transportieren fachliche Daten, die bei unsachgemäßer Exposition Rückschlüsse auf Geschäftsprozesse zulassen. Eine abgesicherte Broker-Infrastruktur und getrennte Netzsegmente begrenzen dieses Risiko.

Integration zu IBP und externen Systemen

Die Anbindung von SAP Integrated Business Planning (IBP) in Lieferkettenprozesse erfolgt über HTTPS im Rahmen von Smart Data Integration. Übertragene Inhalte umfassen Stammdaten, Transaktionsdaten, Customizing-Informationen und Code-Listen. Der Schutzbedarf umfasst Integrität von Planungsparametern und Vertraulichkeit strategischer Kennzahlen. TLS schützt den Transport, während Authentifizierungsmechanismen den Zugriff auf autorisierte Systeme beschränken.

Im Banking-Kontext kommuniziert der Applikationsserver entweder über HTTPS oder RFC mit einer Drittanwendung oder mit einem weiteren Applikationsserver. Beide Varianten transportieren Transaktionsdaten und Systeminformationen. TLS oder SNC sichern diese Verbindungen. Die Kombination aus Transportverschlüsselung, rollenbasierter Autorisierung und restriktiver Netzkonfiguration bildet eine geschlossene Sicherheitsarchitektur.

Datenkategorien und technische Ableitung von Maßnahmen

Customizing-Daten steuern Systemverhalten und Parametrisierung. Eine Manipulation kann Geschäftsprozesse verändern oder Kontrollmechanismen aushebeln. SNC schützt DIAG- und RFC-basierte Übertragung dieser Daten. Zusätzlich begrenzt die Rollenverwaltung den Zugriff auf Customizing-Transaktionen.

Anwendungs- und Transaktionsdaten repräsentieren operative Geschäftsvorgänge. TLS sichert HTTP-basierte Übertragungen, SNC sichert RFC- und DIAG-Verbindungen. Protokollierung und Audit-Trails ergänzen diese Maßnahmen um Nachvollziehbarkeit.

Stammdaten und organisatorische Informationen unterliegen häufig regulatorischen Vorgaben und verlangen daher einen erhöhten Schutz bei Übertragung und Verarbeitung. Sobald solche Daten im Rahmen von Extraktor-Szenarien in Richtung SAP Business Warehouse (BW) oder andere Analyse- und Integrationssysteme übertragen werden, empfiehlt sich eine konsequente Absicherung der Transportwege durch TLS-verschlüsselte HTTP-Verbindungen oder durch SNC geschützte RFC-Kommunikation. Diese Mechanismen gehören zur technischen Basis der Plattform, aktivieren sich jedoch nicht automatisch. Administratoren müssen die HTTPS-Kommunikation konfigurieren, Zertifikate im Trust Store hinterlegen und sichere RFC-Destinationen definieren. Ergänzend reduziert ein fein abgestuftes Berechtigungskonzept das Risiko unbefugter Einsicht. Rollen, Objektberechtigungen und feldbasierte Zugriffskontrollen legen fest, welche Benutzer Datensätze lesen oder verändern dürfen.

Noch höheren Schutzbedarf besitzen Authentifizierungs- und Systemkonfigurationsdaten, da sie direkten Einfluss auf Zugriffsrechte und Systemverhalten ausüben. Die Absicherung sollte bereits beim Aufbau der Verbindung ansetzen. TLS- oder SNC-geschützte Kommunikationskanäle verhindern, dass Anmeldeinformationen oder Konfigurationsparameter im Netzwerk abgegriffen werden. Im Rahmen des TLS-Handshakes prüfen beide Kommunikationspartner ihre Zertifikate und gleichen sie mit den im Trust Store hinterlegten Vertrauensketten ab. Eine strukturierte Zertifikatsverwaltung gehört daher zu den grundlegenden Betriebsaufgaben. Zertifikate müssen regelmäßig erneuert und ihre Gültigkeit überwacht werden, damit Verbindungen stabil bleiben und kompromittierte Schlüssel nicht unbemerkt weiterverwendet werden.

Netzwerksegmentierung und DMZ-Konzepte

Eine sichere SAP-Landschaft sollte auf einer mehrschichtigen Netzwerkarchitektur basieren, in der Präsentationszone, Applikationsserver und Datenbank voneinander getrennt betrieben werden. Exponierte Webkomponenten lassen sich dabei in einer DMZ (demilitarisierte Zone) platzieren, während interne RFC- oder DIAG-Verbindungen ausschließlich innerhalb geschützter Netzsegmente stattfinden sollten. Firewalls übernehmen in diesem Modell eine zentrale Rolle. Sie definieren verbindliche Regeln für zulässige Verbindungen und erlaubte Ports. Dienste, die für den Betrieb nicht erforderlich sind, sollten deaktiviert bleiben. Eine solche Segmentierung erschwert es Angreifern, sich innerhalb der Infrastruktur weiter auszubreiten, falls einzelne Systeme kompromittiert werden.

Auch die Konfiguration der Webschnittstellen verdient besondere Aufmerksamkeit. Der Internet Communication Manager sollte nur Verbindungen über explizit freigegebene Ports akzeptieren. In vielen Architekturen bietet sich zusätzlich ein vorgeschalteter Web Dispatcher oder ein Load Balancer in der DMZ an. Diese Komponenten können TLS-Verbindungen terminieren oder verschlüsselte Sitzungen an interne Server weiterleiten. Wichtig bleibt dabei, dass interne Kommunikationspfade auf definierte Netzwerkzonen beschränkt bleiben und keine direkten Zugriffe aus externen Netzen auf Applikationsserver oder Datenbanken möglich sind.

Ganzheitliche Sicherheitsarchitektur

Die Kommunikationsarchitektur von SAP S/4HANA verbindet proprietäre SAP-Protokolle mit etablierten Internetprotokollen. Für interne Dialog- und Integrationspfade kommen DIAG und RFC zum Einsatz. Diese Verbindungen lassen sich über Secure Network Communications kryptographisch absichern. Gateway-basierte Dienste und Fiori-Anwendungen nutzen HTTP-basierte Schnittstellen, die über TLS verschlüsselt werden sollten.

Webservice-Schnittstellen auf Basis von SOAP können zusätzlich Mechanismen zur Signatur und Verschlüsselung einzelner Nachrichten einsetzen. Ereignisbasierte Integrationsmodelle auf Basis von Event Mesh nutzen Broker-Systeme, deren Kommunikation ebenfalls über verschlüsselte Transportprotokolle erfolgt.

Eine belastbare Sicherheitsarchitektur ergibt sich erst aus dem Zusammenspiel mehrerer Ebenen. Dazu gehören abgesicherte Kommunikationsprotokolle, eine saubere Identitäts- und Rollenverwaltung, eine segmentierte Netzwerkstruktur sowie eine restriktive Konfiguration exponierter Dienste. Kommunikationskanäle verdienen daher besondere Aufmerksamkeit in der Systemarchitektur. Sie bilden die technischen Pfade, über die Geschäftsprozesse, Transaktionsdaten und Systeminformationen zwischen Komponenten und Systemen ausgetauscht werden. Eine sorgfältige Absicherung dieser Pfade trägt maßgeblich dazu bei, Vertraulichkeit, Integrität und Verfügbarkeit der SAP-Landschaft zu gewährleisten.