Administration von SAP-Umgebungen, Teil 1 SAP-Sicherheit ist Einstellungssache

SAP steht für Produktivität und Prozesse, aber wie steht es um die SAP-Sicherheit? Zu oft wird dieser Aspekt ausgeklammert. De facto grassiert eine SAP-Unsicherheit, die oft durch mangelndes Fachwissen und fehlerhafte Konfigurationen entsteht. Dieser Beitrag gibt einige Tipps für die Praxis.

Anbieter zum Thema

Fujitsu Technology Solutions GmbH

Pathlock Deutschland | akquinet enterprise solutions GmbH

Für einen einfachen SAP-Penetrationstest benötigen Experten nicht mehr Informationen, als IP-Adressen und den gewöhnlichen Front-End-Zugang eines SAP-Anwenders. Schon hier sind die Ergebnisse erschreckend: Rund 95 Prozent der untersuchten Systeme sind nicht sicher und können jederzeit für Betrug, Spionage oder Sabotage kompromittiert werden – bis hin zum kompletten Shut-Down eines Systems.

Die Ursachen sind vielfältig: Einmal sind da die nicht ausreichenden Ressourcen. Manch ein CISO gesteht im Vertrauen, dass er sämtliche Audits mit zwei Mitarbeitern fahren muss. Unklar sind zudem auch die Zuständigkeiten für das weite Feld der SAP-Sicherheit, das sich über verschiedene Ebenen erstreckt. Auf Applikationsebene wird SAP-Sicherheit etwa überwiegend als Segregation of Duties (SOD) betrieben.

Noch unklarer sind aber die Kompetenzen auf der Transaktionsebene – sei es SAP NetWeaver, SAP Hana oder SAP BusinessObjects – die für die Übertragung von Daten und Informationen in SAP-Landschaften zuständig ist. Die sicherheitsrelevante Konfiguration von Servern und Instanzen findet hier statt.

Auf der Transaktionsebene lassen sich alle technischen Parameter festlegen, also Nutzer, Passwörter, Berechtigungen und Einstellungen zur Kommunikation. Außerdem werden hier der Zugriff auf Business-Daten und -Profile wie Kunden und Zulieferer oder auch Rechnungs- und Gehaltsdaten geregelt. Und hier hat ein Angriff eine ungleich höhere und direktere Auswirkung als ein Zugriff auf SAP-Applikationsebene.

Wer sich etwa einen SAP_All User einrichtet und entsprechend konfiguriert, hat anschließend freie Hand, um auch die Kompetenztrennung der SOD auszuspielen. SAP-Sicherheit fängt also schon bei der richtigen Definition der Konfigurationsparameter an. Und dieses Definitionsfeld ist ein weites Feld und daher eine Hauptquelle für Sicherheitslücken.

Ein weites Feld

Alle relevanten Einstellungen, die in SAP typischerweise über Parameter von Tabellen geregelt werden, lassen sich schnell durch die Eingabe von Zahlenwerten konfigurieren. Was einfach erscheint, wird dann problematisch, wenn man sich die Dimension und Feingliedrigkeit der Konfigurationstabellen vor Augen führt.

Die Möglichkeiten, Konfigurationsprofile für SAP-Server oder SAP-Instanzen anzulegen, sind schier unerschöpflich, denn je nach Kernel-Version existieren rund 1500 zu definierende Parameter, von den rund zehn Prozent unmittelbar sicherheitsrelevant sind. Bedenkt man, dass eine SAP-Landschaft eines Unternehmens aus Hunderten von oft geschichtlich entstandenen SAP-Servern besteht, wird die quantitative Dimension des Problems sichtbar.

Zusätzlich unübersichtlich wird die Konfigurationslage, weil die Parameter über verschiedene Mechanismen konfiguriert werden. So allein schon durch

• das Customizing der SAP-Software,

• die Einstellungen der User Management Engine (UME) bei JAVA-Systemen, die für die Suche oder das Anlegen von neuen Usern zuständig ist,

• die Parameter der Access Control List (ACL), welche die Anmeldung bei Servern und die Zulassung von Programmen oder Verbindungen regelt (reginfo, secinfo, Webdispatcher, Management Console, Message Server, ICM),

• die Konfiguration von Anwenderrollen und User-Parametern generell (sei es z.b. der erwähnte Sap_All-User oder auch User, die RFC Verbindungen aufnehmen, Dateien lesen beschreiben oder löschen und auf verschiedene Tabellen zugreifen können),

• die Konfiguration von Transport-Profilen oder

• die Adressierung von RFC-Zielen.

Viele Gelegenheiten also, etwas falsch zu machen oder eine einmal angelegte unsichere Konfiguration zu vergessen. Oft ist auch keine genügende Dokumentation verfügbar. Und was einfach erscheint, ist dennoch häufig schwierig zu verstehen. In manchen Fällen hängen die Parameter voneinander ab oder Vorabkonfigurationen werden später überschrieben.

So ersetzt die bisweilen mögliche dynamische Konfiguration einzelner Parameter das Profil der Instanz, diese das Default-Profile, welches wiederum die vom Kernel vorgelieferte Konfiguration ersetzt. Jede Konfiguration auf jeder Ebene hat also unter Umständen auch sicherheitsrelevante Folgen. Zudem gibt es Konfigurationen, die schnell in Vergessenheit geraten und nachlässig mit Default-Werten eingerichtet werden.

Hierzu zählen die häufig bei der Implementierung oder Wartung von SAP-Systemen notwendigerweise anzulegenden nichtproduktiven User, die später dann nicht mehr gebraucht werden, und deren Konfiguration man zu gerne auf sich selber beruhen lässt. Auch Anwenderprofile in Testumgebungen werden nicht speziell konfiguriert und sind mit Default-Werten eingerichtet. Default-Werte kann ein böswilliger Angreifer aber kennen oder relativ schnell in Erfahrung bringen.

(ID:43152921)