Für ein Fazit zur SAP-Sicherheit im Jahre 2018 ist es sicherlich noch zu früh. Andererseits ist der Herbst auch immer die Saison für Veranstaltungen, wie den DSAG Jahreskongress in Leipzig. Eben auf solchen Konferenzen und Messen lässt sich sehr genau abschätzen, welche Themen die SAP-Kunden beschäftigen. Insofern kann durchaus schon jetzt ein Gradmesser erstellt werden, welche Security-Themen im SAP-Umfeld wichtig sind.

Ganz vorne mit dabei, und wenig überraschend: HANA. Nicht zuletzt die Vorstellung von C/4 HANA hat dieses Thema bei vielen Kunden noch einmal auf die Agenda gebracht. Interessanterweise ist es nicht unbedingt nur die Sicherheit von SAP HANA, die durch die Produktoffensive der SAP in den Vordergrund gerückt ist. Vielmehr bereiten sich immer mehr Kunden darauf vor, HANA jetzt tatsächlich einzuführen. Damit einhergehend sind es vor allem zwei Themen, die für SAP Kunden im Zuge einer HANA-Migration interessant sind: Rollen und Berechtigungen sowie Custom Code.

Herausforderungen bei einer Migration auf S/4 HANA

In beiden Fällen ist es eine technische Notwendigkeit, beim Um- oder Einstieg in HANA Änderungen vorzunehmen: Einige Eigenentwicklungen funktionieren schlicht nicht mehr, wenn HANA als Datenbank bzw. Plattform eingesetzt wird. Bei Rollen und Berechtigungen sieht es ähnlich aus: Viele Berechtigungen laufen ins Leere, wenn S/4 HANA statt eines „normalen“ SAP ERP eingesetzt wird.

Aus der Perspektive eines Sicherheitsexperten ist aber ein anderer Trend interessant, der durch die beiden genannten technischen Erfordernisse ausgelöst wird. Kurz und prägnant lässt dieser sich mit den Worten „wenn schon, denn schon“ beschreiben. Wenn ich schon meine kundeneigenen Entwicklungen analysieren muss, kann ich sie im gleichen Zuge auch sicher machen. Wenn ich schon ein HANA-Rollenkonzept entwickle, kann ich auch kritische Berechtigungen und SoD-Konflikte beseitigen.

So löblich diese Vorsätze sind, verdeutlichen sie gleichzeitig ein weiteres Problem der SAP-Sicherheit im Jahre 2018. Denn wieder einmal sind es mehrere Abteilungen der Kunden, die auf unterschiedliche Themen schielen. Verständlich, schließlich sind es sehr häufig verschieden spezialisierte Teams, die entweder für Rollen oder für Entwicklungen zuständig sind. Eine einheitliche Sicht auf Sicherheit gibt es auf Kundenseite oft nicht – dabei ist es gerade im SAP-Umfeld wichtig, genau diese ganzheitliche Sicht anzuwenden. Beispiel gefällig?

Sicherheitslücken im Coding durch fehlende Berechtigungsprüfungen

Eine der häufigsten Sicherheitslücken in kundeneigenem Code ist die fehlende Berechtigungsabfrage. Verweist diese fehlende Berechtigung aber auf eine Transaktion, die gar nicht mehr genutzt wird, ist die Sicherheitslücke nur halb so schlimm. Schlaue Köpfe mögen jetzt darauf verweisen, dass die Sicherheitslücke ja trotzdem da ist und dadurch auch ausgenutzt werden kann. Das ist sicherlich richtig, offenbart aber zu einem Teil genau dieses Silo-Denken, das für SAP Security oft so fatal ist.

Das ist anhand genau dieses Beispiels recht einfach durchexerziert. Nehmen wir die fehlende Berechtigungsprüfung im Code, die auf eine nicht genutzte Transaktion verweist. Folgende Schritte kann ich jetzt durchführen:

• Da der Code auf eine nicht genutzte Transaktion verweist, gehen wir davon aus, dass auch dieses Stück Code obsolet ist. Er kann  also stillgelegt werden.
• Sollte die Transaktion noch in irgendwelchen Rollen verborgen sein, kann sie auch daraus entfernt werden.
• Um – vor dem Entfernen der Transaktion aus Code und Rollen – eine Ausnutzung dieser Sicherheitslücke zu verhindern, sollte jeder Zugriff auf genau diese Transaktion protokolliert werden und ggf. eine Sicherheitswarnung ausgelöst werden, sollte sie dennoch verwendet werden.

Für die Durchführung dieser Schritte gibt es weitere Voraussetzungen, die ich ebenfalls nur exemplarisch darstellen möchte:

• Um beispielsweise zu wissen, ob eine Transaktion überhaupt verwendet wird, braucht es Nutzungsstatistiken.
• Um herauszufinden, ob diese Transaktion im Code vorhanden ist, braucht der Kunde einen Codescanner.
• Vor allem aber: um herauszufinden, ob dieser Code obsolet ist, muss man beides kombinieren – schon sind wir wieder bei der ganzheitlichen Sicht, die unbedingt notwendig ist.

2018: SAP-Sicherheit ist im Trend

Um auf die Ausgangsfrage zurückzukommen: Wie ist denn nun der Stand der SAP-Sicherheit im Jahre 2018? Die gute Nachricht: Sicherheit ist mehr und mehr ein Thema für jeden Kunden. Und im Zuge des Umstiegs auf HANA ist die Umsetzung von Sicherheitsprojekten ein Stück weit realistischer geworden. Umso gefährlicher ist es, diesen Schwung nur für Stückwerk zu nutzen. Stattdessen sollten Kunden alle Aspekte der SAP-Sicherheit betrachten. Dazu zählen vor allem drei Themen:

Plattformsicherheit: Die technische Absicherung von SAP-Systemen. Wichtig ist, sich hier nicht nur auf das SAP-System zu beschränken, sondern auch Datenbank und Betriebssystem zu betrachten. Auch das Thema Codesicherheit ist eindeutig hier zu verordnen.

Identity and User Access Management: Gerne unter dem Begriff „Rollen und Berechtigungen“ zusammengefasst, ist dies ein zentraler Punkt, wenn es um das Thema Sicherheit von SAP-Systemen geht. Hierzu zählen beispielsweise (sicherheits-)kritische Berechtigungen, das Thema der sogenannten „Superuser“ oder „Firefighter“ oder auch ein allgemeines Rollenmanagement. Der Übergang zu einem anderen zentralen Thema im SAP – der Frage nach der Compliance – ist hier oft fließend, aber gerade deswegen ist es natürlich wichtig, bei den Rollen und Berechtigungen sauber aufgestellt zu sein.

Security Intelligence: Absicherung ist das Eine. Wenn dann aber trotzdem etwas passiert, möchte man trotzdem informiert bleiben. Wie ist der Sicherheitsstatus meines Systems? Wer lädt kritische Daten herunter? Greift gerade jemand mein System von außen an? Solche Fragen werden in diesem Bereich der Security Intelligence beantwortet.

Mit diesen drei Themen im Hinterkopf ist das große Abenteuer HANA(-Migration) nicht nur sinnvoll, sondern vor allem sicher.

Sie wollen mehr über die Absicherung Ihrer SAP-Systeme erfahren? Dann informieren Sie sich auf unserer SAST SOLUTIONS Website oder nehmen Sie Kontakt zu uns auf: sast@akquinet.de

Patrick Boch, Produktmanager SAST SOLUTIONS