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

Autor / Redakteur: Gerhard Unger* / Stephan Augsten

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.

Firma zum Thema

SAP-Umgebungen sind oft nicht sicher konfiguriert, dieser Beitrag beleuchtet einige Fehler.
SAP-Umgebungen sind oft nicht sicher konfiguriert, dieser Beitrag beleuchtet einige Fehler.
(Bild: Archiv)

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.

Beispiele für Fehlkonfigurationen

Angesichts dieser Konfigurationsgemengelage ist es nicht verwunderlich, wenn hier Fehler entstehen, die dann oft lange unbemerkt bleiben oder nur von den Falschen bemerkt werden. Einige Beispiele illustrieren typische Gefahren.

Eine Lücke sind falsche Parameter in Notfall-Mechanismen von SAP. Mit dem Profil Parameter login/no_automatic_user_sapstar steht eine Notfalltür bereit, die natürlich auch zum gefährlichen Backdoor werden kann. Wird nämlich der Super-User SAP* gelöscht, existiert er nicht in den auditierbaren Datenbanken, hat aber dann sofort eine Verbindung mit allen Autorisierungen. Zudem kann das Standard-Passwort nicht geändert werden.

Das Ergebnis bei Missbrauch ist die Kompromittierung entweder eines oder mehrerer Clients, eines oder mehrere Applikationsserver oder gar des ganzen SAP-Systems. Abhilfe ist eigentlich einfach möglich, in dem man den Super-User niemals löscht, den User SAP* zusätzlich sichert und den Wert login/no_automatic_user_sapstar mit 1 festlegt.

Ein anderes Beispiel betrifft das Load Balancing. Die Lastenverteilung bei SAP-Systemen erfolgt hauptsächlich durch die Implementierung von neuen Applications-Servern auf dem Messaging Server. Der Zugang zum Messaging Server ist durch die Parameter ms/acl_info und durch die Inhalte der ms_acl_info-Datei eingeschränkt. Bei entsprechender Fehlkonfiguration kann man sich aber auch hier einen Zugriff auf das ganze SAP-System verschaffen.

Nur vermeintlich einfach, aber doch komplex und zugleich höchst sicherheitsrelevant sind Passwortrichtlinien. Richtlinien hängen hier von verschiedenen Faktoren ab, bspw. der Art der Verbindung – komprimierte RFC-Verbindungen oder das relativ offene DIAG (Dynamic Information and Action Gateway-Protokoll) – , dem User oder auch von Parametern zur Regelung des Umgangs mit nicht mehr gültigen Passwörtern (rfc/reject_expired_passwd).

Andere Einstellungen erzwingen – richtig konfiguriert! – die Anpassung von Passworten an verstärkte Richtlinien (login/password_compliance_to_current_policy). Der Anwender und das Übertragungsprotokoll sind dabei die entscheidenden Kriterien, was Brute-Force-Attacken eine gewisse Erfolgsaussicht gibt.

Schnell entstehen auch Sicherheitslücken durch Fehleinstellungen bei Schnittstellen zwischen SAP-Systemen: Parameter definieren hier, welche externen Programme registriert (gw/reg_info) oder auch gestartet werden können (gw/sec_info) oder auch eine Verbindung mit der Gateway aufnehmen dürfen (gw/acl_mode). Gw/sim_mode vereinfacht die Konfigurationsmöglichkeiten, lässt aber auch generell alle Anwendungen zu, wenn keine Einschränkungen eingeführt sind.

Konfigurationskontrolle

Angesichts der Komplexität und Dimension der Konfigurationsproblematik können Fehler fast gar nicht vermieden werden. Es gilt aber, sie so schnell wie möglich zu finden und zu beheben. Nötig ist daher vor allem ein Scannen möglicher Konfigurationsfehler sowie ein Echtzeitschutz gegen Probleme.

Die Inventarisierung von Sicherheitslücken kann dabei nur durch automatisierte Assessment-Lösungen erfolgen, die jede ABAP- und Java-Instanz auf unsichere Konfigurationen überprüft. Insbesondere sind gefährliche Autorisierungen von Usern, potentiell offene Schnittstellen sowie SAP HANA Deployments und SAP Mobile Deployments zu untersuchen.

Wichtig ist dabei eine periodische regelmäßige Überprüfung, um neu aufgekommene Fehleinstellungen schnell zu bemerken. Dabei müssen nicht nur Produktiv-Systeme sondern auch Testsysteme berücksichtigt werden, denn gerade hier befinden sich default konfigurierte und oft vergessene User-Accounts, die von ungewünschten Besuchern ausgenutzt werden.

Konfigurationen lassen sich dabei nach verschiedenen Richtlinien (SAP Sicherheitsrichtlinie, PCI, SOX, NERC, Custom oder anderen) überprüfen. Eine Assessment-Lösung gibt dann eine schrittweise und so schnell umsetzbare Anleitung zur Behebung der Lücken. Gegen unbekannte Bedrohungen, die auch durch Konfigurationen bedingte Risiken entstehen, bieten Lösungen nun auch einen Fast-Echtzeit-Schutz durch Blockieren von Angriffen, bis eine SAP Security Note dafür verfügbar ist.

Vorbeugend hilft natürlich auch die erhöhte Aufmerksamkeit bei der Konfiguration. So sollten – so weit möglich – Default-Einstellungen vermieden werden. Ein besonderes Augenmerk ist auch auf die Instanz-Profile zu richten, die solche Default-Profile überschreiben. Gerade dynamische Profile sollen in ihrer Konfiguration immer überprüft werden, da deren Veränderung sonst gerne unbeachtet bleibt.

SAP-Sicherheit ist zu einem Teil also auch „Einstellungssache“. Und daran lässt sich ja bekanntlich ohne weiteres arbeiten.

* Gerhard Unger ist Vice President EMEA bei Onapsis.

(ID:43152921)