Anzeige

SAP Sicherheit: Vier schnelle Möglichkeiten zur besseren Absicherung

SAP Sicherheit erhöhenWie kann man in SAP-Landschaften RFC-Schnittstellen, Netzwerkschnittstellen und ABAP-Code sicherer machen, und warum sollte man das SAP Audit Log aktivieren? Diese Fragen beantwortet Thomas Werth, Geschäftsführer von werth IT und Spezialist für IT- und SAP-Security Services, im zweiten Teil seiner acht Quick-Wins zu SAP-Sicherheit.

Im ersten Teil „SAP Security: 4 Empfehlungen für mehr Sicherheit“ gab er Tipps für das Einspielen von SAP Security Patches, zur Absicherung des SAP RFC Gateways, den Umgang mit Passworten für SAP-Standardbenutzer und zu Gefahr bei RFC Destinations.

Diese insgesamt acht Empfehlungen können helfen, die Grundabsicherung von SAP-Landschaften zu verbessern. Sie ersetzen natürlich kein ganzheitliches Sicherheitskonzept, aber erhöhen die Hürden für Angreifer.

 

 

5. RFC-Schnittstelle absichern

Die RFC-Schnittstelle ist das technische Gegenstück zur SAP-GUI. Hier stehen weit über 30.000 potenzielle Funktionen zum Abruf bereit. SAP stellt mit RFC SDK, NW RFC SDK oder JCo verschiedene Frameworks zum Zugriff auf die RFC-Schnittstelle bereit.

RFC Kommunikation bei SAP-Systemen (Quelle: SAP SE)

 

Der Parameter auth/rfc_authority_check regelt, ob für Systemfunktionsbausteine eine Anmeldung und eine Berechtigungsprüfung durchgeführt wird. Er ist in der Security Note 1769064 beschrieben.

Der Parameter sollte entweder auf 6 oder 9 konfiguriert werden:

6=Anmeldung und Berechtigungsprüfung erforderlich, jedoch nicht beim Funktionsbaustein RFC_PING. Der Funktionsbaustein RFC_PING wird ohne Anmeldung und ohne Berechtigungsprüfung ausgeführt

9 =Anmeldung und Berechtigungsprüfung erforderlich für alle Funktionsbausteine

Dadurch wird verhindert, dass ein Angreifer anonym auf RFC-Funktionen zugreifen und auf diesem Weg an zusätzliche Systeminformationen zur Angriffsvorbereitung gelangen kann. Potenzielle Funktionen hierzu wären:

  • RFC_PING: Einfache Prüfung der Erreichbarkeit
  • RFC_SYSTEM_INFO: Informationen zu dem System (OS, Datenbank, Version, Identifier)
  • RFC_GET_LOCAL_DESTINATIONS: Liefert alle momentan aktiven RFC-Destinations an derselben Datenbank
  • RFC_GET_LOCAL_SERVERS: Informationen zu den lokalen Servern
  • SYSTEM_INVISIBLE_GUI: Setzt die Sichtbarkeit der aktuellen SAP GUI auf unsichtbar.

 

Weitere Angriffsfläche

Die RFC-Schnittstelle bietet verschiedene Optionen zum Angriff auf ein SAP-System. Beispielsweise über SMB-Relay Angriffe. Bei dieser Art von Angriffen wird das SAP-System dazu gebracht, eine beliebige Datei auf dem System des Angreifers über das Netzwerk anzufragen.

Bei einer solchen Anfrage sendet das SAP-System dann automatisch die Zugangsdaten des <SID>ADM Benutzers an das System des Angreifers. Der kann diesen Hash dann mit Tools wie „Hashcat“ oder „John“ in Klartext überführen.

Es gibt viele RFC-Funktionen, die für diesen Angriffsversuch anfällig sind, dazu zählen auch diese:

  • EPS_DELETE_FILE
  • EPS_CLOSE_FILE
  • CLBA_CLASSIF_FILE_REMOTE_HOST
  • CLBA_UPDATE_FILE_REMOTE_HOST
  • EDI_DATA_INCOMMING
  • RZL_READ_FILE

Auch die Ausführung von Betriebssystemkommandos auf OS-Ebene als <SID>ADM kann möglich sein, wenn zum Beispiel die Funktion SXPG_COMMAND_EXECUTE nicht gepatcht ist und eine bekannte Schwachstelle beinhaltet.

Der Schutz vor diesen Angriffen beginnt mit dem Ändern der Standardzugangsdaten, wie in Punkt 3. (siehe Teil 1) beschrieben. Zudem sind RFC-Berechtigungen restriktiv zu vergeben. Nur Benutzer die RFC wirklich benötigen, dürfen Zugriff erhalten und auch nur in dem notwendigen Umfang.

Ein S_RFC * ist zwar einfach, aber ermöglicht auch die hier vorgestellten Angriffe. Besser ist es moderne Schutzmaßnahmen zu nutzen, beispielsweise SAP UCON. Dies ist sicher kein Quick-Win, doch kann das Logging von UCON bereits genutzt werden, um schnell einen Großteil der Benutzer zu analysieren und deren RFC-Berechtigungen zu minimieren.

 

6. Schnittstellen schützen

SAP-Systeme bieten einige Netzwerkschnittstellen zum Zugriff auf das System. Nicht alle davon werden von den Anwendern benötigt und können durch eine Firewall geschützt werden. Andere sind notwendig und sollten daher ein Minimum an Härtung aufweisen.

 

SAP START SERVICE und SAP HOST AGENT

In der SAP Note 1986725 empfiehlt SAP, den SAP Start Service und SAP Host Agent durch eine Firewall vor externem Zugriff zu schützen. Nur Systeme aus dem Rechenzentrum sollten Zugriff erhalten.

 

Datenbank

Analog ist auch mit Datenbankzugriffen zu verfahren: Die Ports der Datenbank dürfen nur für das SAP-System und einem administrativen Zugang zur Verfügung stehen. Entsprechend ist eine Firewall zum Zugriffsschutz einzurichten.

 

ICM

Die Absicherung des ICM erfordert mehrere Handgriffe.

Über die Transaction SICF empfiehlt SAP die Deaktivierung der nachfolgenden Dienste, sofern diese nicht zwingend für den produktiven Betrieb benötigt werden:

  • /sap/bc/soap/rfc (SAP Note 139410032)
  • /sap/bc/echo (SAP Note 62607333)
  • /sap/bc/FormToRfc
  • /sap/bc/report
  • /sap/bc/xrfc
  • /sap/bc/xrfc_test
  • /sap/bc/error
  • /sap/bc/webrfc (SAP Note 86585334)
  • /sap/bc/bsp/sap/certreq (SAP Note 141756835)
  • /sap/bc/bsp/sap/certmap
  • /sap/bc/gui/sap/its/CERTREQ
  • /sap/bc/gui/sap/its/CERTMAP
  • /sap/bc/bsp/sap/bsp_veri (SAP Note 142227336)
  • /sap/bc/bsp/sap/icf
  • /sap/bc/IDoc_XML (SAP Note 148760637)
  • /sap/bc/srt/IDoc

Zudem sollte HTTPS zur Kommunikation verwendet werden und folgende Profilparameter gesetzt werden:

  • login/ticket_only_by_https = 1
    Damit werden SSO-Anmeldetickets nur über HTTPS übertragen.
  • login/ticket_only_to_host = 1
    Damit wird das Ticket nur an den richtigen Server gesendet.
  • icf/set_HTTPonly_flag_on_cookies = 1
    Damit sind Cookies nur mittels HTTP im Zugriff und Angreifer können diese nicht mit Javascript Angriffen auslesen.
  • is/HTTP/show_detailed_errors = false
    Dies bewirkt, dass Fehlerseiten nicht zu viele Informationen beinhalten.

 

7. Authority Checks im kundeneigenen ABAP Code

Ein Berechtigungskonzept regelt den Zugriff der Mitarbeiter auf die Funktionen und Daten im SAP-System. Aufgrund der Individualität jedes Betreibers eines SAP-Systems, werden Anpassungen im System mittels Custom ABAP-Coding zur optimalen Unterstützung der eigenen Prozesse vorgenommen.

Hier lauern jedoch Fallstricke: Fehlen in dem jeweiligen kundeneigenen ABAP Code die Berechtigungsprüfungen, so wird das Berechtigungskonzept in diesem Bereich im schlimmsten Fall sogar wirkungslos. Dann könnten Benutzer Custom Reports oder RFC Funktionsbausteine ohne erforderliche Berechtigungen aufrufen. Hieraus können sich Compliance-Verstöße oder sogar Sicherheitsrisiken ergeben. Es wäre möglich, dass Benutzer über diesem Weg Zugriff auf Reports und Transaktionen erhalten, die nur einem eingeschränkten Benutzerkreis zur Verfügung stehen sollten.

Um dies zu unterbinden, sind jede Custom Programme mit einem AUTHORITY-CHECK abzusichern. Zudem sind vor Sprüngen, wie mit CALL TRANSACTION, die Berechtigungen für die Zieltransaktion zu prüfen. Dies übernimmt der Zusatz WITH AUTHORITY-CHECK.

 

8. SAP AUDIT LOG aktivieren

SAP beschreibt sein Audit Log folgendermaßen: “Das Security-Audit-Log ist ein Werkzeug für Auditoren, die sich die Ereignisse im SAP-System detailliert ansehen müssen. Wenn Sie das Security-Audit-Log aktivieren, zeichnen Sie die Aktionen auf, die Sie für die Verfolgung als relevant einstufen. Sie können dann in Form eines Audit-Analysereports auf diese Informationen zugreifen und sie auswerten.“

Das oberste Ziel des Audit-Log ist die Aufzeichnung von:

  • sicherheitsbezogenen Änderungen an der SAP-Systemumgebung (z. B. Änderungen an Benutzerstammsätzen)
  • Informationen, die mehr Transparenz bieten (z. B. erfolgreiche und erfolglose Anmeldeversuche)
  • Informationen, die der Nachvollziehbarkeit einer Reihe von Ereignissen dienen (z. B. erfolgreiche oder erfolglose Transaktionsstarts)

Das Security Audit Log ist im Standard nicht aktiviert und muss manuell gestartet werden. Die Logdatei wird im Pfad /usr/sap/<SID>/<INSTANCE>/log/audit_date gespeichert. Die Größe der Logdatei kann über den Profilparameter rsau/max_diskspace/local definiert werden. Der Vorschlagswert ist 1MB. Wird dieses Limit erreicht, stoppt das Logging und erst am nächsten Tag wird wieder protokolliert, in einer neuen Logdatei!

Der Inhalt des Logs kann über die SAP-Transaktion SM20 eingesehen werden. Dort lässt sich der genaue Zeitpunkt, der verursachende User und Quellcomputer, sowie die protokollierte Aktion bestimmen. Dieses Log beinhaltet sehr viele Informationen und kann durch die Abfrage-Filter in der SM20 sehr gezielt ausgewertet werden.

Für einen minimalen Betrieb sollten mindestens folgende Parameter gesetzt werden:

  • rsau/user_selection = 1
  • rsau/max_diskspace/local = 20 MB
  • rsau/enable = 1
  • rsau/integrity = 1
  • rsau/ip_only = 1
  • rsau/log_peer_address = 1
  • login/update_logon_timestamp = s

Die Konfiguration der zu protokollierenden Ereignisse ist über die Transaktion RSAU_CONFIG (alt SM19) vorzunehmen. Hier sind alle schwerwiegenden und kritischen Ereignisse zu aktivieren.

Für alle User sind nun die folgenden Punkte zu aktivieren:

  • Systemereignisse
  • Sonstige Ereignisse

und zusätzlich für alle User, mit Ausnahme der Benutzeradministratoren, noch der Punkt

  • Benutzerstammänderungen

Für alle Administratoren, Notfalluser und Benutzer mit weitreichenden Datenzugriff sind die Anmeldungen zu überwachen:

  • Dialoganmeldung
  • RFC-/CPIC-Anmeldung

Für alle Notfallbenutzer sind auch Transaktionsstart und Reportstart zu protokollieren.

 

Schlusswort von Thomas Werth

Thomas Werth
Autor: Thomas Werth

Die hier vorgestellten acht Quick-Wins dürfen sicherlich nur als oberste Spitze des Eisberges betrachtet werden. Die Absicherung eines SAP-Systems erfordert deutlich mehr Justierungen an den Stellschrauben zur Systemsicherheit. Dies zeigt schon der Vergleich mit dem DSAG-Prüfleitfaden, der über 250 empfohlene Prüfungen auf über 180 Seiten auflistet.

Doch gerade deshalb sind diese acht Quick-Wins hier so bedeutend. Denn mit wenig Aufwand lässt sich dadurch eine erste Angriffswelle auf SAP-Systeme stoppen oder zumindest erschweren. Die Hürden für einen erfolgreichen Angriff werden merklich höher gelegt, wenn diese Quick-Wins erfolgreich umgesetzt werden. Eine unabhängige Prüfung der SAP-Systemsicherheit wird dies belegen.

 

 

Wir danken Ihnen, wenn Sie diesen Artikel jetzt weiterempfehlen:

Anzeige

Über die Redaktion IT-Onlinemagazin

SAP-Community Nachrichten, die Entscheider kennen sollten: Abonnieren Sie jetzt unseren IT-Onlinemagazin Newsletter. Lesen Sie Umfrageergebnisse, Insights aus dem SAP-Ecosystem, Interviews und Artikel ... und Sie bleiben kompakt informiert.

Lesetipp für Sie:

Wegweiser HR.

SAP HR zwischen gestern und morgen

Wie sollte eine hybride IT-Architektur im Personalwesen aussehen? Wie kann die Migration nach HCM for …