Sicher mit Hana kommunizieren
Die Architekturen von SAP-Landschaften haben sich mit der Einführung von SAP Hana grundlegend geändert. Hana war zunächst als relationale Datenbank für SAP-Systeme auf Basis der In-memory-Technologie entwickelt worden.
Die gesamte Datenverarbeitung und -speicherung erfolgt dabei im Hauptspeicher der Systemumgebung, was zu einem enormen Performance-Schub gegenüber herkömmlichen Datenbanksystemen führt.
Hana eröffnet aber auch neue Möglichkeiten im Business-Einsatz und wird so immer mehr zu einer Entwicklungsplattform, auf der Java- und HTML5-Anwendungen in Runtime-Umgebungen ausgeführt werden.
Der Fokus liegt hier mittlerweile auf webbasierten Anwendungen, die mittels HTTP kommunizieren.
Allerdings kann der SAP-Kern unter Hana nicht mehr vom Anwender selbst programmtechnisch verändert werden; Hana ist somit gesehen ein geschlossenes System und stellt seine Funktionen über eine Vielzahl von Connectoren und Interfaces zur Verfügung, auf die dann selbstentwickelte Anwendungsprogramme zugreifen können.
Derzeit sind mehr als 2000 solcher Connectoren und Interfaces im Hana-Kern implementiert – die Tendenz ist stark steigend, weil immer neue Anwendungsbereiche abgedeckt werden sollen. Generell lassen sich auf dieser Plattform folgende Kommunikationspfade unterscheiden:
Verbindungen zu Hana über den Datenbank-Client: Sie dienen hauptsächlich zur Verwaltung des Datenbanksystems – zum Beispiel Hana Cockpit oder Hana Studio – oder für die klassischen Datenbankabfragen beispielsweise mit Business-Intelligence-Tools oder auch ganz einfach mit Excel. Die Kommunikation erfolgt mittels Verwendung des Protokolls SQLDBC, das ein Derivat von ODBC/JDBC ist.
Verbindungen von sogenannten Web-Clients. Das können beispielsweise Anwendungen sein, die in der Java-Runtime von Hana XS laufen und direkt in die Datenbankumgebung eingebettet sind.
Dabei ist die XS-Erweiterung erforderlich; die meist webbasierte Kommunikation (HTTP/HTTPS) läuft üblicherweise über die TCP-Ports 3xx33, wobei xx für die jeweilige Instanznummer steht. XS stellt in dieser Konfiguration die Java-Runtime Machine sowie den Webserver bereit.
Für die Sicherheit der Plattform und der Anwendungen ergibt sich daraus eine Reihe von Problemen: Innerhalb der Plattform wird „plain text“ kommuniziert, das bedeutet, dass alle Daten unverschlüsselt ausgetauscht werden; das gilt sowohl für die Datenbank- als auch für Web-Clients.
Die jeweiligen Komponenten müssen sich gegenseitig authentifizieren. Möglich sind hierbei Basic Auth (username/password), SAML Assertions und X.509-Zertifikate. Allerdings wird Basic Auth generell als unsicher angesehen; SAML und X.509 erfordern wiederum ein entsprechendes Zertifikatsmanagement, das jedoch innerhalb der Hana-Landschaft nur eingeschränkt zur Verfügung steht.
Das Thema „Schutz der Daten“ rückt damit stärker in den Fokus. Was genau passiert beispielsweise, wenn kompromittierte Anwendungen über die Connectoren auf Daten zugreifen?
Aktuell stellt die Hana-Plattform keine RAM-Verschlüsselung zur Verfügung. Daher könnte also ein Angreifer eine App installieren, die Zugriff auf die gesamten unverschlüsselten Daten erhält.
Die naheliegende Lösung wäre hier eine RAM-Verschlüsselung, die aber erst mit der neuesten Prozessor-Generation sowie den entsprechenden Modulen im Betriebssystem zur Verfügung steht.
Herausforderung Validierung
Dies rückt das Thema sichere Anwendungsentwicklung mehr und mehr in den Sicherheitsfokus, die beispielsweise der Validierung und Autorisierung der Daten und Datenströme eine sehr hohe Priorität einräumt.
In der Vergangenheit, als eine SAP-Umgebung noch ein offenes System war, wurde die Mehrzahl der Funktionen von der Abap-Entwicklung selbst erstellt und dann in den SAP-Kern integriert.
Zwar konnten auch hier Sicherheitslücken entstehen, aber die Auswirkungen blieben begrenzt, weil der SAP-Kern für einen gewissen Schutz sorgte; auf diesem Weg konnte jedenfalls nicht eine ganze Infrastruktur kompromittiert werden.
Nun arbeitet der Entwickler auf einer anderen Ebene, auf der ihn das System nicht mehr schützt; seine Anwendung greift auf die Connectoren und Interfaces zu und wenn er hier einen sicherheitskritischen Fehler macht, steht schlimmstenfalls die ganze Infrastruktur für Angreifer offen, die dann ebenfalls auf die betreffenden Connectoren zugreifen können.
Die Anwendungsentwickler müssen sicherstellen, dass beispielsweise ihre XML-Streams korrekt validiert werden, sodass nicht über entsprechende Schwachstellen ein Angreifer kompletten Zugriff auf die Anwendung erhält, diese dann verändert und somit wiederum Zugriff auf alle Daten im RAM bekommt.
Auch die Berücksichtigung und Spezifikation von Sicherheitsanforderungen in der Design- und Konzeptionsphase, aber auch Investitionen ins Testing – zum Beispiel in Static Application Security Testing (SAST), Dynamic Application Security Testing und Penetrationstests – müssen nun berücksichtigt werden.
In großen SAP-Landschaften müssen sich die Anwender außerdem vermehrt um Infrastruktur-Themen wie Web Application Firewalls (WAFs) und XML-Firewalls kümmern.
So verwenden Entwickler immer häufiger Microservices auf Basis von REST-APIs für den Austausch von Daten – etwa mit SAP Leonardo, der Plattform für den Austausch und die Analyse von IoT-Informationen.
Diese Daten müssen schnell und sicher übertragen werden, eine Kompromittierung der Daten muss auf alle Fälle verhindert werden. Dazu sind beispielsweise digitale Signaturen, Transportverschlüsselung mittels 2-Way-SSL-Handshakes, XML-Validierung die Mittel der Wahl.
Viele Entwickler verzichten immer noch darauf, solche Sicherheitsvorkehrungen in ihren Anwendungen selbst zu realisieren, weil sie eine Reduzierung der Gesamtperformance ihrer Systeme befürchten, zum anderen aber sind Systeme mitunter auch nicht in der Lage, dergleichen auf Anwendungsebene zu unterstützen.
Daher sind die genannten Infrastruktur-Komponenten für einen sicheren Betrieb in einer Hana-Umgebung unverzichtbar.
Grundsätzlich muss beim Einsatz von Hana der Sicherheit auf Anwendungsebene in Zukunft mehr Aufmerksamkeit geschenkt werden, paradoxerweise gerade weil Hana ein programmatisch geschlossenes System ist und eben deshalb das Thema Kommunikationswege und Kommunikationspartner fokussiert werden muss.
Bei einem erfolgreichen Angriff auf Hana-Anwendungen könnte die Plattform für Angreifer zu einem Einfallstor werden, das Zugriff auf beliebige unternehmenskritische Daten ermöglicht.
