HTTP-Sicherheit in SAP-Systemen fachgerecht umsetzen

Angriffsfläche durch exponierte HTTP-Dienste

Eine der häufigsten Schwachstellen in SAP-Umgebungen betrifft die Erreichbarkeit von HTTP- und HTTPS-Ports. Offene Zugriffe auf ICM-Ports oder auf den Web Dispatcher erweitern die Angriffsfläche erheblich. Besonders kritisch sind zentrale Komponenten wie SAP Gateway oder Message-Server, sofern sie über das Internet oder unkontrollierte interne Netze erreichbar sind.

Das Prinzip der minimalen Angriffsfläche verlangt eine strikte Netzwerksegmentierung. HTTP-Zugriffe sollten ausschließlich über definierte Einstiegspunkte erfolgen. In typischen Architekturen übernimmt der Web Dispatcher die Rolle eines Reverse Proxys in einer demilitarisierten Zone (DMZ). Backend-Systeme sollten vom direkten Internetzugriff isoliert bleiben. Firewall-Regeln sollten außerdem nur explizit definierte Kommunikationsbeziehungen erlauben.

Fehlende oder unvollständig durchgesetzte Zugriffskontrolllisten (Access Control Lists, ACL) verstärken das Risiko. ACLs am SAP Gateway oder Message Server müssen aktiv erzwungen werden. Das alleinige dokumentieren von erlaubten Hosts ohne technische Durchsetzung erzeugt kein Sicherheitsniveau. Ein Deny-by-Default-Ansatz mit expliziten Allow-Einträgen reduziert das Risiko deutlich. Ergänzend empfiehlt sich eine Protokollierung sämtlicher erlaubter und abgelehnter Zugriffe.

Verschlüsselung als Grundvoraussetzung

Unverschlüsselte HTTP-Kommunikation gehört zu den gravierendsten Fehlkonfigurationen. Klassische Protokolle ohne Transportverschlüsselung ermöglichen das Abfangen sensibler Inhalte. In SAP-Landschaften betrifft dies nicht nur Browser-Zugriffe, sondern auch RFC-Verbindungen oder DIAG-Kommunikation.

Für HTTP-basierte Kommunikation ist TLS verpflichtend. ICM und Web Dispatcher unterstützen SSL-Konfigurationen mit serverseitigen Zertifikaten. Ergänzend empfiehlt sich die Aktivierung des HTTP Security Session Managements auf der ABAP-Plattform, um Logon-Tickets und Session-Cookies gegen Missbrauch abzusichern.

Eine reine TLS-Aktivierung genügt jedoch nicht. Ohne zusätzliche Header-Mechanismen bleibt das System anfällig für Protokoll-Downgrade-Angriffe oder Clickjacking-Szenarien. Hier greifen HTTP Strict Transport Security (HSTS) und Frame-Schutzmechanismen.

HTTP Response Header als Verteidigungsebene

SAP Web Dispatcher und ICM erlauben das Modifizieren und Ergänzen von HTTP Response Headern. Diese Funktion stellt eine zweite Verteidigungslinie gegen aktive Inhalte dar. Neben der Integration externer Virenscanner auf Anwendungsebene begrenzen Response Header das Verhalten des Browsers. Empfohlen sind unter anderem folgende Header:

• X-Content-Type-Options mit dem Wert nosniff verhindert MIME-Type-Sniffing durch den Browser.
• X-XSS-Protection mit dem Wert 1; mode=block aktiviert browserseitige Schutzmechanismen gegen reflektiertes Cross-Site Scripting.

Diese Header lassen sich im Web Dispatcher oder direkt im ICM konfigurieren. Wichtig ist eine zentrale Steuerung, damit alle ausgelieferten Anwendungen konsistent abgesichert sind.

HSTS im Internet Communication Manager

HTTP Strict Transport Security (HSTS) verhindert Downgrade-Angriffe von HTTPS auf HTTP. Ohne HSTS kann ein Angreifer initiale Verbindungen manipulieren und den Browser zur Nutzung unverschlüsselter Kommunikation bewegen. HSTS zwingt den Client, ausschließlich HTTPS zu verwenden.

Im ICM erfolgt die Konfiguration über den Parameter icm/HTTP/strict_transport_security. Der Parameter fügt allen ausgehenden HTTP-Responses den Header Strict Transport Security hinzu. Zulässige Werte entsprechen der RFC 6797 und definieren eine maximale Lebensdauer in Sekunden sowie optional includeSubDomains. Ein typischer Eintrag lautet:

icm/HTTP/strict_transport_security = max-age=31536000;includeSubDomains

Mit dieser Konfiguration instruieren Server den Browser, für ein Jahr ausschließlich HTTPS zu verwenden. Wird der Parameter nicht gesetzt, sendet das System keinen HSTS-Header. Die Funktion ist dynamisch änderbar, was eine Anpassung ohne vollständigen Neustart ermöglicht.

Die Unterstützung von Header Rewriting im ICM setzt eine bestimmte Kernel- beziehungsweise Patch-Ebene voraus. Mindestanforderungen ergeben sich aus einschlägigen SAP-Hinweisen zur HTTP-Response-Header-Modifikation. Alternativ kann HSTS im Web Dispatcher implementiert werden, sofern die eingesetzte Version dies unterstützt.

Administratoren sollten vor der Aktivierung sicherstellen, dass sämtliche Subdomains TLS-fähig sind. Andernfalls führt includeSubDomains zu Erreichbarkeitsproblemen. Zudem ist zu prüfen, ob ausschließlich HTTPS-Zugriffe erlaubt sind. Mischbetrieb mit HTTP widerspricht der HSTS-Strategie.

Clickjacking-Schutz auf AS ABAP und AS Java

Clickjacking nutzt das Einbetten legitimer Anwendungen in fremde Frames, um Benutzerinteraktionen umzuleiten. SAP NetWeaver stellt Mechanismen bereit, um Framing-Angriffe zu verhindern. Auf ABAP-Systemen erfolgt der Schutz über die Clickjacking Framing Protection im Application Server. Hier können Whitelists definiert werden, die erlaubte Einbettungsquellen festlegen. Anwendungen außerhalb dieser Liste werden nicht gerendert.

Für AS Java gibt es einen dedizierten ClickjackingProtectionService. Nach Aktivierung prüft das System vor jeder Darstellung einer Webanwendung, ob sie in einen fremden Frame eingebettet ist. Schlägt die Prüfung fehl, rendert das System einen leeren Frame. Eine Anwendung gilt als vertrauenswürdig, wenn sich der Host in derselben Domain befindet oder explizit in einer Whitelist geführt wird. In Multi-Domain-Szenarien, zum Beispiel bei föderierten Portalnetzwerken, muss der jeweilige Host in die Whitelist aufgenommen werden.

Die Aktivierung erfolgt über den SAP NetWeaver Administrator unter Configuration, Infrastructure, Java System Properties. Dort wird für die Anwendung tc~lm~itsam~service~clickjacking die Eigenschaft ClickjackingProtectionService von false auf true gesetzt. Anschließend ist ein Neustart des AS Java erforderlich. Zusätzlich ist eine Anpassung im verwendeten UI-Framework notwendig, da der serverweite Property-Schalter allein nicht alle Framework-Spezifika abdeckt. Administratoren müssen neben der Aktivierung auch die Whitelist pflegen. Ein unvollständiger Eintrag blockiert legitime Einbettungen. Eine zu großzügige Whitelist konterkariert den Schutzmechanismus.

Zusammenspiel von Web Dispatcher und ICM

In typischen Landschaften übernimmt der Web Dispatcher die Rolle der zentralen HTTP-Instanz. Header-Manipulationen können hier konsolidiert erfolgen. Alternativ lassen sich Header direkt im Backend-ICM konfigurieren. Die Entscheidung hängt von Architektur, Release-Stand und Betriebsmodell ab.

Wird HSTS im Web Dispatcher gesetzt, entfällt eine doppelte Konfiguration im Backend. In verteilten Szenarien mit mehreren Backend-Systemen vereinfacht dies das Management. Dennoch bleibt die Prüfung der Kernel-Unterstützung relevant, da ältere Stände kein vollständiges Header-Rewriting erlauben.

Die Aktivierung sicherheitsrelevanter Header darf nicht isoliert betrachtet werden. Sie ergänzt Transportverschlüsselung, ACL-Konfiguration, Session-Management und Logging.

Logging und Nachvollziehbarkeit

Technische Schutzmechanismen entfalten nur dann Wirkung, wenn sie mit Protokollierung kombiniert werden. Sicherheitsrelevante Änderungen an Analyseberechtigungen oder Ausführungen im Kontext fremder Benutzer werden in dedizierten Tabellen protokolliert. Ergänzend sollte der Zugriff auf HTTP-Services überwacht werden.

Die Lesezugriffsprotokollierung auf AS ABAP erlaubt das Monitoring von Zugriffen über Analytics-Kanäle, Web Services oder Gateway. Voraussetzung ist eine aktive Konfiguration im RAL-Manager sowie die Kennzeichnung relevanter InfoObjects. Native HANA-Zugriffe bleiben davon ausgenommen.

Für HTTP-Sicherheit bedeutet dies, dass sowohl erlaubte als auch blockierte Zugriffe dokumentiert werden sollten. Auffällige Häufungen fehlgeschlagener Frame-Checks oder wiederholte HTTP-Anfragen auf HTTPS-Ports liefern Indikatoren für Angriffsversuche.

Typische Fehlkonfigurationen und Gegenmaßnahmen

Sicherheitsüberprüfungen zeigen wiederkehrende Defizite: Dienste sind öffentlich erreichbar, ACLs existieren, sind jedoch nicht erzwungen, HSTS fehlt oder wird inkonsistent eingesetzt, Clickjacking-Schutz bleibt deaktiviert oder veraltete Systeme unterstützen keine aktuellen Header-Mechanismen.

Administratoren sollten daher folgende Maßnahmen umsetzen:

• Netzwerkseitige Minimierung exponierter HTTP-Ports.
• Erzwingen von HTTPS für sämtliche Webzugriffe.
• Aktivierung und korrekte Parametrisierung von icm/HTTP/strict_transport_security.
• Konfiguration sicherheitsrelevanter Response Header im Web Dispatcher oder ICM.
• Aktivierung des ClickjackingProtectionService auf AS Java und Pflege der Whitelist.
• Aktivierung der Clickjacking Framing Protection auf AS ABAP.
• Regelmäßige Überprüfung der Patch- und Kernel-Stände.
• Integration der Header-Konfiguration in Change- und Compliance-Prozesse.
• Kombination mit umfassendem Logging und Monitoring.

Fazit

HTTP-Sicherheit in SAP-Systemen erschöpft sich nicht in der Aktivierung von TLS. Erst das Zusammenspiel aus Netzwerksegmentierung, ACL-Durchsetzung, Response-Header-Strategie, HSTS-Konfiguration und Clickjacking-Schutz schafft ein belastbares Sicherheitsniveau. ICM und Web Dispatcher stellen dafür die notwendigen technischen Instrumente bereit. Ihre konsequente, überprüfte und regelmäßig auditierte Konfiguration entscheidet darüber, ob webbasierte SAP-Anwendungen gegen aktuelle Angriffsszenarien resilient sind.