SAP Systeme absichern

Risiko = Bedrohnung x Verletzung x Konsequenz 

Der ehemalige General und NSA-Direktor Michael Hayden hat es auf einem SAP-CRM Kongress in Richtung der anwesenden SAP-Kunden direkt formuliert:

Jedes Risiko ist letztlich das Produkt aus einer Wahrscheinlichkeit ihres Eintretens, multipliziert mit den Kosten des Schadens, wenn sie eintritt.

Open Web Applikation Security Projekt

Die Organisation Open Web Applikation Sekurity Projekt (OWASP) beschreibt ihr Selbstverständnis in einem Wiki-Beitrag folgendermaßen:

„Das Open Web Application Security Project (OWASP) ist eine Non-Profit-Organisation mit dem Ziel, die Sicherheit von Anwendungen und Diensten im World Wide Web zu verbessern. Durch Schaffung von Transparenz sollen Endanwender und Organisationen fundierte Entscheidungen über wirkliche Sicherheitsrisiken in Software treffen können. An der OWASP-Community sind Firmen, Bildungseinrichtungen und Einzelpersonen aus aller Welt beteiligt. Innerhalb der Gemeinschaft werden frei verfügbare Informationsmaterialien, Methoden, Werkzeuge und Technologien erarbeitet.“

Eine Funktion , die jedes Jahr mit Spannung erwartet wird, ist die Top-10-Liste der in dem entsprechenden Jahr erkannten Schwachstellen von Webanwendungen genießt unter Sicherheitsexperten und Webentwicklern einen hohen Stellenwert. Für die neue Rankliste wurden über 500.000 Schwachstellen in mehreren Hundert Unternehmen und Tausend von Applikationen beobachtet. 2013 waren dies z.B. die folgenden (die Zahlen in Klammern zeigen die Vorjahresplatzierung):

1. Injection (1)

2. Broken Authentication und Session Management (3)

3. Cross-Site Scripting (XSS) (2)

4. Insecure direct Object References (4)

5. Security Misconfiguration (6)

6. Sensitive Data Exposure (7/9)

7. Missing Funktion Level Access Control (8)

8. Cross-Site Request Forgery (CSFR) (5)

9. Using Known Vulnerable Components(…)

10. Unvalidated Redirect and Forwards (10)

SAP-Sicherheit in der klassischen Sicht

Im Gegensatz zu früher stehen heute SAP-Systeme und SAP-Landschaften im Fokus der Cyber-Angriffe. Den hier findet man den „Schatz“ der Unternehmen in Form von Unternehmensdaten.

Bei der Umstellung auf die R/3 Architektur die aus einer klassischen 3-Tier-Landschaft besteht, also einen klassischen Client-Server-Umgebung. Und auf die basiert bis heute die SAP-NetWeaver-Architektur - auch wenn SAP HANA diese Welt nun wieder grundlegend verändert.

Tier 1: SAP-GUI-Client

Der Hauptzugang zu SAP-Systemen basiert in allen Systemen auf dem SAP GUI. Dieser Zugang basiert auf einem Rich-Client.Konzept, das ein proprietären Netzwerkprotokolle verwendet. Das Konzept ,das das SAP GUI verwirklicht , kommt ursprünglich aus der Terminal-Steuerung.

Aus Sicht eines Angreifers ist das SAP GUI sehr interessant. Zum einen bietet die auf dem Client liegende SAPINI-Datei einen hohen Informationswert, denn dort sind SAP-Systeme mit Adressen und Zielrouten hinterlegt. Zum anderen kann man sicher sein, das die Strecke vom Client zum SAP-System für diesen Desktop freigeschaltet ist.

Tier 1: Zugang aus dem Internet und Übergang ins Intranet

Dieses Netzwerksegment ist der Übergang vom Benutzer im anonymen Internet zum authentifizierten Internet-Benutzer und kennzeichnet auch die Grenze zum Unternehmensnetzwerk. Traditionall nennt man eine solche Zone auch Demilitarisierte Zone (DMZ), abhängig von der jeweiligen Architektur.

Für die Kommunikation zwischen SAP GUI und dem Anwendungsserver wurde das Dynamic Information and Action Gateway Protocol (kurz DIAG) entwickelt. Es ist ein proprietären Protokoll, dessen Spezifikation nicht veröffentlicht wurde - einige Details sind jedoch inzwischen bekannt geworden. DIAG übertragt binär Daten , die im Standard komprimiert sind, es findet jedoch ohne die zusätzliche Verschlüsselung per SNC keine Absicherung des Datenverkehrs gegen Sniffing statt.

Tier 2: Übergang von Intranet zur SAP-Tier

Der Übergang von Tier 1 (der DMZ) nach Tier 2 funktioniert in der Regel wieder durch eine Firewall, die das DMZ-Intranet gegen das interne Netzwerk, manchmal auch Campusnetzwerk genannt, abgrenzt. In Tier 2 liegen oft die Mitarbeiter-Systeme, auf denen dann auch der SAP Rich Client (SAP GUI) läuft. Aber auch externe Programme und nicht unternehmenskritische Anwendungen  können hier laufen. Aus dieser Ebene 2 werden dann die Verbindung zu den SAP-Systemen im inneren Tier 3 aufgebaut.

Tier 3: Die SAP-Systeme

Bis zur Einführung von SAP HANA hatte SAP zu Datenbanken eine ähnliche Haltung wie zu den Netzwerken. SAP wollte weitestgehend unabhängig von Datenbanken sein und implementierte nur eine Schnittstelle zu den Datenbanken hin und nannte diese Open SQL. Es war letztlich eine klassische Implementierung einer Datenbankschnittstelle, wie man sie auch im Bereich ODBC kennt, einem Protokoll, das letztlich von und zu Datenbanken redet.

Komponenten:

Schutz von SAProuter und SAP Web Dispatcher

SAProuter ist eine der ältesten Peripherie-Komponenten in der Welt der SAP-Kommunikation und war ursprünglich dazu gedacht, dem SAP-Support-Zugang zu den Kundeninstallationen zu ermöglichen.

Der Einsatzzweck hat sich im Laufe der Zeit deutlich gewandelt. Aus diesem Grund ist auch der Umfang der Sicherheitsthemen rund um den SAProuter mit den Jahren gewachsen.

Wann wird der SAProuter eingesetzt?

Der SAPRouter wird - neben der Rolle als Verbindung zu den Kundendiensten der SAP im SAP Help Portal - hauptsächlich zur Kontrolle und zur Protokollierung von Verbindungen von SAP-GUI.-Clients zu SAP-Servern eingesetzt. Hier ist es wichtig zu beachten, dass der SAProuter keine Funktion im Sinne einer Firewall oder als ein Paketfilter hat. Der SAProuter kann nur Verbindungen von und zu SAP-Systemen Verbindungen entweder zulassen (Allow) oder verweigern (Deny).

SAProuter und Secure Network Communications SNC

SNC ist in den letzten Jahren als Verschlüsselung auf Netzwerkebene immer wichtiger geworden, die Forderungen der Auditoren nach Verschlüsselung in Produktivnetzwerken sind immer häufiger in aktuellen Prüfberichten zu sehen.

Der SAP Web Dispatcher im SAP-Netzwerk

Der SAP Web Dispatcher steht zwischen dem Internet und Ihrem SAP-System und dient als eine SAP-spezifische Trennung von dem „Außen“ des Internets und dem „Innen“ einer Zone wie der Dermilitarisierten Zone (DMZ). Er ist ein Einstiegspunkt für HTTP-Requests an Ihr System, das aus einem oder mehreren SAP NetWeaver Application Servern besteht. In diesem Sinne ist der SAP WebDispatcher auch ein optionaler Terminator für HTTPS-Verbindungen. Als „Software-Web-Switch“ kann er Verbindungen abweisen oder annehmen und nimmt dann die Request-Verteilung für eine gleichmäßige Serverauslastung vor. Diese Last-Steuerung, die auch in einer klassischen SAP-Landschaft von spezifischen Load Balancern als Hardware-Appliance realisiert ist, kann hier softwareseitig realisiert werden.

Den SAP Web Dispatcher können Angreifer als Brücke verwenden, da hier SSL-Verbindungen terminiert sind und der SAP Web Dispatcher Zugriff auf die Backend-Systeme und SAP Gateway hat. Die Brücke ist ein Übergang, der es erlaubt , von einer gesicherten Kommunikation auf eine ungesicherte zu wechseln, ohne dass man selbst die verschlüsselte Verbindung auflösen oder terminieren muss. Wenn man beabsichtigt, den Netzverkehr unerlaubt mitzuschneiden, also zu sniffen, braucht man nur den Datenverkehr vom SAP Web Dispatcher zum SAP-System mitzuschneiden. Die verschlüsselte Verbindung davor kann man unangetastet lassen. Ähnlich dem SAProuter fungiert der SAP Web Dispatcher als Router und Load Balancer für alle angeschlossenen SAP-Systeme und adressiert diese meistens unverschlüsselt, das heißt ohne SSL-Zertifikate. Diese Verbindungen können auch gut mitgeschnitten , also gesnifft werden.

SAP-Prozesse und Dienste

Alle Applikationsserver eines SAP-Systems bilden eine logisch geschlossene Einheit Einheit. Daher müssen die Aufgaben der jeweiligen Server genau definiert werden. Die Aufgaben, die in einem SAP-System anfallen und die auf die einzelnen Applikationsserver verteilt werden müssen, werden Prozesse und Dienste genannt.

In einem SAP-System mit genau einem Applikationsserver werden diese Prozesse und Dienste von diesem einen Server ausgeführt. Wenn sich die SAP-Anwendung aus mehreren Applikationsserver zusammensetzt , werden sie auf die einzelnen Server verteilt. MIt Transaktion SM50 können Sie einsehen, welche Prozesse aktiv laufen.

Zu dern einzelnen Prozessen und Diensten gehören:

Dialogprozess - Der Dialogprozess nimmt die Anforderungen der laufenden Benutzersitzungen entgegen. Es sind mehrere Dialogprozesse pro SAP-System erforderlich. Auf jeder Instanz laufen mindestens zwei Dialogprozesse.

Ein Dialogprozess wird nicht genau einem Benutzer zugeordnet . Der Prozess nimmt immer genau eine Anforderung entgegen und wartet dann auf die nächste Anforderung, egal von welchem Benutzer sie ist. Der Dialogprozess wird von der jeweiligen Instanz mit Anforderungen versorgt. Ein Dialogschritt im SAP-System stellt genau eine Bildschirmmaske dar.

Verbuchungsprozess

Die meisten verändernden Zugriffe auf die Datenbank erfolgen asynchron. Das bedeutet , dass die Daten nicht direkt von einem Dialogprozess in die Datenbank geschrieben, sondern in Tabellen zwischengespeichert werden . Der Verbuchungsprozess übernimmt die Aufgabe , diese Tabellen auszulesen und die Daten in die Datenbank zu übertragen. Durch dieses Prinzip werden große Performanceverbesserungen erzielt.

Enqueue-Prozess/Enqueue-Server

Der Enque-Prozess stellt die Sperrverwaltung des SAP-Systems dar. Innerhalb eines SAP-Systems kann es nur einen einzigen Enqueue-Prozess geben, was häufig bei älteren ABAP-Systemen so konfiguriert wurde. Enqueue-Server kann er in einer eigenen Instanz installiert werden. Als Standalone-Enqueue-Server bildet er zusammen mit dem Message-Server die ASCS-Instanz (ABAP Server Central Services). Durch Einrichtung eines Enqueue Replication Servers kann er Hochverfügbarkeit ausgelegt werden.

Der Enqueue-Prozess verwaltet die Sperrtabelle. Bearbeitet ein Benutzer z.B.den Stammsatz des Debitors, wird in der Tabelle ein Eintrag vom Enqueue-Prozess auf die Anforderung eine negative Antwort. somit werden Inkonsistenzen in der Datenbank vermieden. Das Entsperren einer logischen Tabelle oder eines logischen Datensatzens übernimmt der Dequeue-Prozess.

Diese Sperre ist ein rein logische Sperre; es werden von diesem Prozess keine Tabellen in der Datenbank gesperrt. So ist es durch einen direkten Zugriff auf die Datenbanktabellen möglich, einen Datensatz zu ändern, der über das SAP-System durch den Enqueue-Prozess gesperrt ist.

Batchprozess

Der Batchprozess ist zuständig für die Hintergrundverarbeitung. Wiederkehrende Aufgaben, die keiner Dialogeingabe bedürfen, sollten im Hintergrund ausgeführt werden. Sie werden als Jobs eingeplant. Diese Jobs können von einem Benutzer ereignisgesteuert oder zu einem bestimmten Zeitpunkt ausgeführt werden. Auf jeder Instanz können mehrere Batchprozesse gestartet werden.

Message-Server

Der Message-Server ist für die Kommunikation der verschiedenen Instanzen untereinander verantwortlich. In jedem SAP-System gibt es genau einen Message-Server-Dienst, der auf der ASCS-Instanz (ABAP Server Central Services) läuft. Im Wesentlichen ist der Message-Server für das Routen von Mitteilungen zwischen den Servern verantwortlich. Bei diesen Mitteilungen kann es sich z.B. um das Starten von Batch-Jobs, das Starten einer Verbuchung oder um Enqueue- oder Dequeue-Prozesse handeln. Er übernimmt auch die Lastverteilung bei Anmeldung über SAP GUI und RFC mit Logon-Gruppen.

Gateway

Das Gateway (vormals SAP NetWeaver Gateway) übernimmt die Kommunikation zwischen Anwendungen auf verschiedenen SAP-Systemen oder zu Nicht-SAP-Systemen über das Protokoll Transmission Control Protocol/Internet Protocol (TCP/IP). Er ist auch zuständig für die Protokolle Remote Function Call (RFC) und Common Programming Interface for Communications (CPI-C). Es nutzt das Open Data Protocol (OData) und wird von allen Systemen benötigt, in denen SAP-Fiori-Applikationen und SAP-UI5-Oberflächen verwendet werden. Es ist somit die zentrale Komponente für die Anbindung eines SAP-Fiori-Frontend-Systems an ein SAP-S/4HANA-Backend.

Spool-Prozess

Der Spool-Prozess übernimmt die Verwaltung der Ausgabeaufträge eines SAP-Systems. Die Druckaufträge werden bis zur Ausgabe in den TemSe-Objekten (temporäre sequenzielle Objekte) zwischengespeichert. Die TemSe-Objekte können entweder in der Datenbank (unter Verwendung der RDBMS-Sicherheitsmechanismen) oder im Betreibssystem abgelegt werden. Es können beliebig viele Spool-Prozesse je Server gestartet werden.

Allgemeine Systemsicherheit

In der allgemeine Systemsicherheit fließen die Themen ein, die im Rahemen jeder Prüfung eines SAP-Systems zu betrachten sind.

Folgende Fragen können zum Thema allgemeine Systemsicherheit gestellt werden.

- Welches SAP-Release wird eingesetzt? Wie ist der aktuelle Stand der Support Packages?

- Existieren Vorgaben für die Einstellungen der Systemparamter?

- Entsprechen die aktuellen Paramaterwerte den Unternehmensverbände?

- Existieren Vorgaben für die Kontrolle der Parametereinstellungen nach Releasewechsel, Kernel-Updates usw?

- Wurden Änderungen an Parameterwerten nur von berechtigten Personen durchgeführt?

- Wurden Parameter sowohl im Instanz- als auch im Default-Profil gesetzt?

- Wurden für Parameter auf verschiedenen Instanzen unterschiedliche Werte gesetzt?