SAP-Security – Teil 1

SAP ist bekanntlich einer der weltweit größten Hersteller von Software zur Abwicklung sämtlicher Geschäftsprozesse eines Unternehmens. In den letzten Jahren hat sich SAP durch den Zukauf vieler Unternehmen strategisch auf den Bereich Cloud neu ausgerichtet („SAP – A Cloud Company“). Resultierend hieraus ist die Anzahl der durch SAP angebotenen und hergestellten Softwareprodukte stark gewachsen und durchaus schwer überschaubar. In diesem Artikel werden wir das weit verbreitete Kernprodukt „SAP NetWeaver ABAP“ (kurz: NW), auf dem ein Großteil der klassischen Funktionen eines SAP-Systems aufsetzt, betrachten und auf grundlegende sicherheitskritische Aspekte bei dessen Einsatz eingehen.

1 Grundlagen und Architektur

1.1 Aufbau SAP NetWeaver

Zum Verständnis der bei der Sicherheitsanalyse von SAP-Systemen zu beachtenden Aspekte ist zunächst eine Betrachtung der grundlegenden Architektur von SAP-Systemen auf technischer Ebene vonnöten. Ein SAP-System mag nach außen als monolithischer Block wahrgenommen werden, dies ist bei genauerer Betrachtung jedoch nicht der Fall. Betrachten wir zunächst ober-flächlich den logischen Aufbau eines NW-Systems.

Abbildung-1: Logischer Aufbau eines SAP-Systems

Der in C/C++ geschriebene SAP-Kernel stellt die Schnittstelle zwischen dem SAP-System und dem unterliegenden OS sowie dem genutzten Datenbanksystem dar. Insbesondere für letzteres stellt er eine einheitliche Schnittstelle dar, die eine plattformunabhängige Applikations-programmierung erlaubt.

1.2 Netzwerk

Der Zugriff eines Benutzers erfolgt entweder über die SAP GUI oder einen Browser. Der Benutzer hat hier wiederum eine monolithische Sicht auf das System. Betrachten wir auch dies genauer, offenbart sich jedoch eine Vielzahl potentieller weiterer Komponenten zwischen dem Benutzer und dem System:

Abbildung-2: Schematische Darstellung der Komponenten eines SAP-Systems

Hinzu kommt, dass ein SAP-System faktisch niemals für sich alleine betrieben wird. Im Gegenteil ist es für gewöhnlich mit einer nicht zu vernachlässigenden Anzahl Vor- und Nachsystemen verbunden. Dies können weitere SAP-Systeme sein, aber auch weitere für die Geschäftsprozesse und Kommunikation erforderlichen Systeme.

Abbildung 3: Beispielhafter Systemverbund

Aus dieser Darstellung wird bereits deutlich, dass es für die Analyse der Sicherheit von SAP-Systemen nicht ausreichend ist, das System isoliert zu betrachten. Vielmehr muss der ganze Systemverbund betrachtet werden.

1.3 Systemschichten

Hinsichtlich der zu betrachtenden Sicherheitsaspekte ergeben sich vier technische Ebenen, in die sich ein SAP-System einteilen lässt.

Abbildung-4: Schichtenmodell eines SAP-Systems

Im Rahmen dieses Beitrags werden wir uns auf die Netzwerkebene sowie die SAP-Basis-Ebene beschränken. Grundsätzlich sind jedoch alle Ebenen in die Sicherheitsanalyse mit einzubeziehen, wobei auf jeder Ebene spezifische Herausforderungen bestehen.

2 Sicherheitsaspekte

Wie alle anderen Infrastrukturkomponenten und Applikationen sollen natürlich auch SAP-Systeme „sicher“ betrieben werden. In diesem Zusammenhang umfasst der Begriff „sicher“ mindestens die nachfolgenden Aspekte:

• Assets sollen keinem nicht-vertretbaren Risiko ausgesetzt werden

• Geschäftsdaten und -prozesse müssen geschützt sein

• Rechtliche Anforderungen müssen eingehalten werden (SOX, BASEL-II, BSIG etc.)

Hierbei kommen klassische Randbedingungen wie das angenommene Bedrohungspotential, Schutzstufe des Systems/der Daten, das Kosten-Nutzen-Verhältnis oder interne Sicherheits-richtlinien zum Tragen. Diese Aspekte sowie die vorgefundenen Randbedingungen müssen über alle vorhandenen technischen Ebenen betrachtet werden.

Die grundlegende Schicht (SAP-Basis) eines NW-Systems sollte sich innerhalb einer Systemlinie i.A. nicht stark unterscheiden. Große Unterschiede bestehen jedoch auf der Anwendungsebene. Hier können auf der gleichen unterliegenden Plattform eine Vielzahl unterschiedlicher Komponenten und Applikationen vorhanden sein.

Die Kenntnis der durch ein System bereitgestellten Funktionalität sowie deren technische Realisierung erfordert ein hohes Know-how seitens des IT- bzw. Applikationsbetriebs. Ebenso ist es für die Sicherheitsanalyse unabdingbar, dass kritische Geschäftsprozesse und -daten als solche identifiziert sind und dieses Wissen für die Sicherheitsanalyse zur Verfügung steht. Die Erfahrung zeigt, dass beide Voraussetzungen häufig nicht hinreichend erfüllt sind. Jedes SAP-System benötigt also eine individuelle Bedrohungsanalyse. Insbesondere durch die hohe Interkonnektivität mit anderen Systemen ist dies keine triviale Aufgabe.

2.1 Netzwerksicherheit

Befassen wir uns zunächst mit der netzwerkseitigen Angriffsoberfläche eines SAP-Systems. Ein neu installiertes System zeigt eine große Anzahl offener TCP-Ports, von denen nur die wenigsten außerhalb des Systemverbundes und insbesondere für Anwender direkt zugreifbar sein müssen. SAP-Systeme können eine Vielzahl von Kommunikationsprotokollen verwenden. Zentral ist hier das proprietäre RFC-Protokoll (Remote Function Call). Hierbei handelt es sich um die SAP-spezifische Implementierung eines Remote Procedure Call (RPC). RFC ist das Kommunikations-protokoll zwischen SAP-Systemen sowie zur Kommunikation von Nicht-SAP-Systemen mit eben diesen.

2.1.1 Das Gateway

Das Gateway ist die zentrale Kommunikationskomponente eines SAP-Systems und vermittelt jegliche RFC-basierte Kommunikation. Das Gateway ist traditionell auch der erste Ansatz bei Angriffen gegen ein SAP-System. Ist das Gateway nicht ausreichend geschützt, dann hat ein Angreifer das System bereits mit minimalem Aufwand schnell unter Kontrolle. 

Der Hintergrund ist der Folgende: 

• Auf Betriebssystemebene läuft das Gateway unter dem Benutzer des SAP-Systems (i.A. <sid>adm)

• Über das Gateway können Programme auf dem Betriebssystem gestartet werden

• Das Gateway bietet a-priori keine integrierten Authentisierungsmechanismen, ist also unauthentisiert zugreifbar

Zur Absicherung des Gateways existieren im Wesentlichen drei ACL-Dateien, die über die Konfigurationsparameter gw/reg_info, gw/sec_info sowie gw/prxy_info definiert werden. Als Dateinamen werden hier üblicherweise reginfo, secinfo sowie prxyinfo genutzt.

Zentral sind hierbei insbesondere die ersten beiden Dateien. Die dritte (prxyinfo) kontrolliert die Proxy-Funktionalität des Gateways und wird hier nicht näher betrachtet.

Die Datei reginfo regelt die Registrierung externer RFC-Server am Gateway des Systems. Der Begriff „extern“ bedeutet an dieser Stelle lediglich, dass es sich um einen anderen RFC-Server als das Gateway handelt. Es ist nicht notwendigerweise ein entferntes System, sondern kann sich hierbei auch um ein RFC-fähiges Serverprogramm auf dem gleichen Hostsystem handeln. Ist die Registrierung externer Programme nicht eingeschränkt, so kann ein Angreifer sich als ein legitimes, externes Serverprogramm ausgeben und so Zugriff auf die dem legitimen Programm zugedachten Daten erhalten.

Im Gegensatz hierzu steuert secinfo die Ausführung externer RFC-fähiger Programme auf dem Gateway. 

Die secinfo-Datei folgt nachstehender Syntax:

P|D TP=<tp>, USER=<user>, HOST=<host>, [USER-HOST=<user-host>]

Hierbei ist die Bedeutung der einzelnen Schlüsselwörter in der folgenden Tabelle aufgelistet:

Für die reginfo-Datei gilt die Syntax:

P|D TP=<tp> [HOST=<host>,…] [NO=<n>] [ACCESS=<host>,…] [CANCEL=<host>,…]

Bis Release 7.3 existierten keine sicheren Grundeinstellungen für die Absicherung des Gateways. Fehlte eine oder beide ACL-Dateien, so wurde der Zugriff grundsätzlich erlaubt. Dies macht eine Übernahme des SAP-Systems mit geringem Aufwand möglich, da dies die Ausführung beliebiger Betriebssystembefehle unter der Identität des SAP-Systems erlaubt und sich so bspw. die unterliegende Datenbank den Erfordernissen eines Angreifers anpassen lässt. Auf Grund der potentiellen Auswirkungen verzichten wir an dieser Stelle auf ein ausführliches Beispiel.

Ab Release 7.4 existieren sichere Grundeinstellungen für die Absicherung des Gateways. Diese sind auch durch Backports in älteren Releases verfügbar.

Für die Datei secinfo sind dies: 

P TP=* USER=* USER-HOST=local HOST=local

P TP=* USER=* USER-HOST=internal HOST=internal

Für reginfo:

P TP=* HOST=local

P TP=* HOST=internal

Hierdurch werden die Registrierung sowie die Ausführung externer RFC-Serverprogramme auf das lokale System bzw. alle zum System gehörenden Applikationsserver beschränkt.

Die Herausforderung bei der Absicherung des Gateways besteht nun darin, nur die minimal notwendigen Kommunikationsbeziehungen des abzusichernden SAP-Systems zu identifizieren. Dies ist gerade in großen und heterogenen Landschaften eine nicht-triviale Aufgabe und führt häufig dazu, dass zu weitreichende Berechtigungen (bspw. Für große IP-Subnetze) vergeben werden. Auch ist es nicht mit einer einmaligen Erstellung der ACLs getan. Diese müssen regelmäßig aktualisiert werden, um das erstrebte Sicherheitsniveau zu erhalten. Auch hier finden sich häufig Leichen in Form von bereits lange nicht mehr existierenden Systemen, deren IP-Adressen teilweise neu vergeben sind und so ungewollt Systemen den Zugriff ermöglichen, die diesen keinesfalls benötigen.

2.1.2 Der Message-Server

Eine weitere zentrale Kommunikationskomponente ist der Message-Server. Seine Hauptaufgaben bestehen in 

• der Registrierung einzelner Applikationsserver,

• der Vermittlung der Kommunikation zwischen den einzelnen Applikationsservern des Systems sowie

• der Vermittlung der Client-Kommunikation über die SAP GUI.

Aus letzterem Grund ist es notwendig, dass der Message-Server aus dem oder den Client-Netzen erreichbar ist. 

Historisch wurden die o.g. Kommunikationen auf dem gleichen TCP-Port geführt. Dies ist unter Sicherheitsaspekten offensichtlich kein gutes Design, da so ein Zugriff aus den Client-Netzen auf nur intern benötigte Dienste möglich wird. Abhilfe schafft hier die Möglichkeit, über den Konfigurationsparameter rdisp/msserv_internal einen eigenen TCP-Port zu definieren, über den die interne Kommunikation der Applikationsserver vermittelt wird. Dieser Port kann und muss dann über adäquate Firewallregeln oder Router-ACLs auf die benötigten Systeme bzw. IP-Subnetze eingeschränkt werden.

Weiterhin ist es notwendig, die Möglichkeit vermeintlicher Applikationsserver einzuschränken, sich am Message-Server als Teil des Systems zu registrieren. Hierzu dient eine weitere ACL-Datei, die über den Konfigurationsparameter ms/acl_info spezifiziert wird. Die Syntax dieser Datei kennt lediglich das Schlüsselwort HOST und folgt der nachstehenden Form:

HOST=[* | IP-Adresse | Hostname | CIDR | Domain] [, …]

Eine angemessene Message-Server-ACL erlaubt über die entsprechenden Einträge lediglich den Zugriff von Applikationsservern des eigenen Systems. Häufig ist in der Prüfung jedoch lediglich ein HOST=* anzutreffen, so dass kein wirksamer Schutz vor der Registrierung von Applikations-servern besteht.

2.1.3 Der WebDispatcher

Der Web Dispatcher dient als Loadbalancer für die HTTP-Kommunikation mit den dahinterliegenden Applikationsservern. Als solcher ist er auch der vorgesehene Single-Point-of-Entry für jegliche HTTP-basierte Client-Kommunikation (z.B. zum Zugriff auf die Web-GUI), dies wird in der Praxis jedoch so gut wie nie durch technische Maßnahmen erzwungen.

Darüber hinaus kann der Web Dispatcher über URI-Filter der Zugriff auf URIs des dahinterliegenden Systems kontrollieren. Die Steuerung erfolgt hierbei über eine einfache Textdatei in der die Zugriffsregeln nach folgendem Schema zeilenweise definiert werden:

P|D|S <URI Muster>

Hierbei kennzeichnet P einen erlaubten, D einen nicht-erlaubten sowie S einen Zugriff, für den zwingend HTTPS erforderlich ist. 

2.1.4 SAProuter

Durch SAP wird grundsätzlich die Verwendung eines SAProuters für jedes SAP-System empfohlen, wie sie in der nachstehenden Abbildung der empfohlenen Architektur eines NW-Systems gezeigt wird:

Abbildung-5: Kanonische netzwerkseitige Aufteilung eines NW-Systems

Hierbei ist zu beachten, dass nicht notwendigerweise Firewalls zwischen den Komponenten verwendet werden müssen, solange die Kommunikationsbeziehungen zwischen den Komponenten adäquat eingeschränkt sind, beispielsweise durch Router-ACLs.

Der SAProuter ist ein klassisches Application-Level-Gateway, das über eine sogenannte Route Permission Table, die ein- und ausgehenden Verbindungen zu dem dahinterliegenden SAP-System kontrolliert. Der SAProuter kann eine Firewall ergänzen, jedoch niemals ersetzen. Wie der Name bereits nahelegt, spezifiziert die Route Permission Table eine oder mehrere Netzwerkrouten, die entweder erlaubt oder verboten sind. Es handelt sich hierbei also um klassisches Source Routing. Hieraus ergibt sich offensichtlich ein unmittelbares Gefährdungspotential. Für den Fall, dass ein Angreifer ein System innerhalb einer erlaubten Route kompromittiert hat, besteht für ihn direkter Zugriff auf die über diese Route erlaubten Systeme, sofern keine weiteren Gegenmaßnahmen getroffen wurden.

Als unmittelbare Gegenmaßnahme kann eine Route mit einem Kennwort geschützt werden. Wird das Kennwort bei der Verwendung einer Route nicht mit übertragen, so wird die Verbindung durch den SAProuter nicht erlaubt. Dies ist jedoch nur eine rudimentäre Gegenmaßnahme. Wirksamere Möglichkeiten bietet hier das im nächsten Abschnitt behandelte SNC-Protokoll.

2.1.5 Kommunikationssicherheit

Weder das RFC-Protokoll, noch das darauf aufbauende und zur Kommunikation zwischen SAP-GUI und Applikationsserver verwendete DIAG-Protokoll bieten a-priori Verschlüsselungs-möglichkeiten. Zur Absicherung der Kommunikation auf Transportebene kann das ebenfalls SAP-proprietäre Secure Network Communication (SNC) verwendet werden.

SNC bietet drei verschiedene Sicherheitsmodi:

1. Authentifizierung: In diesem Modus wird lediglich die Identität der Kommunikationspartner sichergestellt. Die übertragenen Daten werden nicht gegen Veränderung oder Ausspähen geschützt.

2. Schutz der Integrität: Die übertragenen Daten werden gegen Veränderung geschützt, eine Verschlüsselung findet nicht statt.

3. Schutz der Vertraulichkeit: Dieser Modus kombiniert die beiden vorhergehenden und verschlüsselt zusätzlich die Daten.

Insbesondere bei RFC-Verbindungen mit hinterlegten Zugangsdaten sollte darauf geachtet werden, dass die Kommunikation über SNC geschützt wird.

SNC kennt zwei Betriebsmodi:

1. Ende-zu-Ende: Zur Verbindung bspw. zweier Applikationsserver

2. Tunnel: Zur Verbindung zwischen zwei SAProutern

SNC-Tunnel zwischen zwei SAProutern bieten eine elegante Möglichkeit die Kommunikation zwischen einem oder mehreren SAP-Systemen bzw. die Kommunikation zwischen räumlich getrennten Standorten abzusichern, ohne dies auf den jeweiligen Komponenten konfigurieren zu müssen.

In der Architekturanalyse werden SAProuter häufig außer Acht gelassen, da sie – einmal aufgesetzt – als quasi-transparentes System agieren und den Systemverantwortlichen ihre Präsenz nicht bewusst ist. Hier bietet sich jedoch auch ein erhebliches Gefährdungspotential durch fehlerhafte Konfiguration der SAProuter, zumal diese auch über das Internet exponiert sein können. 

HTTP-basierte Kommunikation wird über SSL/TLS abgesichert. Hierbei ist es durchaus üblich, dies auf dem Web Dispatcher zu terminieren. Je nach Anwendung kann dies jedoch bis auf die Applikationsserver durchgereicht werden. Die korrekte und angemessene SSL/TLS-Konfiguration der Applikationsserver bzw. des Web Dispatchers würde den Rahmen dieser Ausführung sprengen. Stattdessen sei an dieser Stelle auf die relevante SAP Note 510007 verwie-sen. Allgemein sollte jedwede Kommunikation von und zu SAP-Systemen – wo technisch möglich – auf Transportebene durch die zur Verfügung stehenden Protokolle abgesichert werden.

2.1.6 Zusammenfassung

Zusammenfassend ergeben sich die nachfolgenden Minimalanforderungen hinsichtlich der Netzwerksicherheit von SAP-Systemen:

• Adäquate Absicherung des Gateways und des Message-Servers.

• Netzwerkseitige Trennung von Produktiv- und Nicht-Produktiv-Systemen.

• WebDispatcher als Single-Point-of-Entry für jegliche HTTP-basierte Kommunikation.

• Durchgehende Verschlüsselung des Datenverkehrs auf Transportebene durch TLS/SNC.

Im zweiten Teil dieses Artikels werden wir uns mit der Sicherheit in der SAP-Basis sowie der Anwendungsentwicklung befassen. Hierbei wird es insbesondere um die korrekte Anwendung des Berechtigungskonzeptes gehen. 

Autor: Martin Monerjan, GAI NetConsult GmbH

Literatur

• Secure Configuration of SAP NetWeaver Application Server Using ABAP – SAP Securi-ty Recommendations, 2012. Verfügbar unter https://support.sap.com/content/dam/support/en_us/library/ssp/security-whitepapers/secure-config-netweaver-app-server-abap.pdf  

• Securing Remote Function Calls (RFC) – SAP Security Recommendations. SAP Though Leadership Paper, Christian Wippermann, 2014. Verfügbar unter https://support.sap.com/content/dam/support/en_us/library/ssp/security-whitepapers/securing_remote-function-calls.pdf  

Autor: Martin Monerjan