Wo stehen Unternehmen aktuell beim Thema SAP-Sicherheit – und wie wird aus einer leisen Vorahnung eine klare Handlungsgrundlage? In dieser Folge des SAP-IT-Podcasts spreche ich mit Max Beckmann, Strategieberater mit Fokus auf SAP Security und Compliance bei mindsquare, darüber, wie Unternehmen die dunklen Ecken ihrer Systeme sichtbar machen. Wir klären, warum ein großzügig verteiltes SAP_ALL mehr ist als ein Schönheitsfehler und weshalb ein belastbares Sicherheitskonzept vor allem Transparenz, klare Verantwortlichkeiten und realistische Priorisierung braucht.
…zum Anschauen
YOUTUBE-CHANNEL abonnieren: https://www.youtube.com/@sap-it-podcast
…zum Hören
…zum Lesen
Wie SAP-Sicherheit auf die Tagesordnung kommt
Das Thema kommt meist über zwei Wege auf die Tagesordnung. Die klassische Variante: Ein technischer Ansprechpartner ist für die SAP-Berechtigungen verantwortlich, hat das Gefühl, dass etwas nicht stimmt, und holt sich Unterstützung, um diese Ahnung in belastbare Zahlen zu übersetzen.
Neu hinzugekommen ist in den letzten ein bis zwei Jahren ein zweiter Weg: die CISOs. Diese sind organisatorisch für die gesamte IT-Sicherheit zuständig und nehmen SAP nun bewusst ins Visier – teils, weil die Rolle im Unternehmen überhaupt erst neu geschaffen wurde, teils, weil bestehende CISOs durch Compliance-Anforderungen wie NIS2 aufmerksam werden. In beiden Fällen geht es darum, einen transparenten Stand zu bekommen und SAP nicht länger als Blackbox neben der übrigen Informationssicherheit stehen zu lassen.
Warum trotzdem so wenig passiert
Damit ist das Problem benannt – geändert hat sich noch nichts. Auf die Frage, woran es scheitert, nennt Max zwei Gründe, und fehlendes Wissen ist keiner davon.
Der erste ist schlicht Kapazität: Ihm sei noch nie ein Ansprechpartner begegnet, der nicht wusste, womit er seinen Tag füllen soll – eher das Gegenteil. Security-Themen zusätzlich zum Tagesgeschäft gesondert zu betrachten, passt kapazitätstechnisch einfach nicht hinein. Der zweite Grund liegt zwischen Wissen und Umsetzung. Dass ein verteiltes SAP_ALL keine gute Idee ist, lässt sich nachlesen. Die eigentliche Arbeit beginnt eine Stufe später – bei kritischen Berechtigungen, Funktionstrennungskonflikten und der Frage, was aus einem konkreten Finding nun eigentlich folgt. Genau diese Ableitung ist es, die Teams von außen erwarten.
Wir verschaffen Ihnen einen klaren Einblick in die aktuelle Sicherheitssituation Ihres SAP-Systems - mit unserem SAP Security Check und Audit.
Vom Gefühl zum Geschäftsrisiko
Der entscheidende Mehrwert einer strukturierten Analyse liegt nicht in den rein technischen Findings. Dass ein SAP_ALL verteilt ist oder Funktionstrennungskonflikte bestehen, lässt sich vergleichsweise einfach ermitteln.
Der Security-Check ist dabei modular aufgebaut – Berechtigungen, Systemparameter, Schnittstellen und der gesamte Cloud-Bereich rund um BTP und Cloud Connector lassen sich einzeln prüfen, teils mit ergänzenden Tools und eigenen Exports. Aus der Analyse entstehen zwei Ergebnisse: eine konkrete Maßnahmenableitung für die technischen Ansprechpartner und die Übersetzung der Findings in Geschäftsrisiken für das Management. Max beschreibt seine Rolle in diesen Projekten treffend als die eines „Dolmetschers”. Gegenüber dem Vorstand mit dem Argument „Wir haben hier Leute mit zu vielen Rechten” aufzutreten, ist für den Vorstand häufig nicht greifbar genug. Anders klingt es, wenn dasselbe Problem so formuliert wird: Mitarbeiter können unbemerkt Geld abziehen, ohne dass es nachvollziehbar ist – und zusätzlich können HGB-Verstöße entstehen, weil Buchungsbelege nicht transparent zuordenbar sind.
Ein konkretes Beispiel aus dem Podcast: Ein Unternehmen war auf S/4HANA migriert, hatte das Thema Berechtigungen dabei aber sehr locker behandelt – die Berechtigungen sollten vor allem nicht stören. Das Ergebnis: mehrere Benutzer mit SAP_ALL, und das über Jahre hinweg. Zusätzlich war das Security Audit Log nicht aktiviert. Das Bewusstsein bei den Technikern war da, die Management Attention fehlte. Erst die Übersetzung in reale Geschäftsrisiken sorgte für den nötigen Wow-Effekt in der Führungsetage.
Was Teams selbst tun können
Muss man für den ersten Schritt gleich externe Hilfe holen? Nein. Max ermutigt ausdrücklich dazu, mit Bordmitteln selbst zu prüfen. Wer SAP_ALL im System hat, lässt sich im SAP-Standard relativ einfach herausfinden. Auch ein Blick in die Systemparameter lohnt sich – die Best Practices von SAP sind über die SAP Notes öffentlich verfügbar und lassen sich mit dem Ist-Zustand abgleichen. Ebenso lohnt der Blick auf technische Benutzer an den Schnittstellen (Spoiler: Auch dort findet sich häufig ein SAP_ALL).
Ziel dieser Eigenanalyse ist es, aus dem Bauchgefühl eine erste, belegbare Indikation zu machen. Eeine kostenpflichtige Analyse lässt sich gegenüber dem Management deutlich besser begründen, wenn es bereits erste belegbare Indikationen gibt. Die Eigenleistung ist also kein Ersatz, sondern ein wertvoller Türöffner – dort, wo Kapazität und Know-how es zulassen.
Nachhaltigkeit statt Drehtür-Effekt
Ein Security-Check liefert den Status quo. Danach beginnt die eigentliche Arbeit: Prozesse etablieren, die das erreichte Sicherheitsniveau auch halten. Denn das Tagesgeschäft holt jedes System ein. Max nennt das Beispiel eines Kunden, dessen frisch durchgeführtes Berechtigungs-Redesign schon nach drei Jahren wieder als „historisch gewachsen” galt.
Damit man sich nicht ewig im Kreis aus Analyse und Absicherung dreht, braucht es definierte Update-, Transport- und User-Lifecycle-Prozesse sowie interne Kontrollen. Die berechtigte Sorge vieler Administratoren – „Am Ende habe ich mehr Arbeit als vorher” – entkräftet Max mit dem Stichwort Automatisierung. Tools und zunehmend auch künstliche Intelligenz können große Datenmengen analysieren, Reportings auslösen und Prozesse technisch unterstützen. Wichtig bleibt dabei der Praktikabilitätsfokus: Prozesse, die nur auf dem Papier existieren, helfen im nächsten Audit niemandem.
Patch-Management: dringender denn je
Ein oft ungeliebtes Kind ist das Patch-Management. Durch KI werden derzeit deutlich mehr Sicherheitslücken gefunden – beim Browser Firefox stieg die Zahl der monatlichen Sicherheitspatches von 20 bis 30 auf mehrere hundert. Für SAP heißt das: Kritische Updates müssen zeitnah eingespielt werden. Bei vielen Kunden ist inzwischen mehr Bewusstsein da als früher, doch es fehlt häufig an klaren Verantwortlichkeiten und definierten Prozessen.
SAP BTP – die unterschätzte Angriffsflanke
Ein besonderes Augenmerk legt Max auf die SAP Business Technology Platform. Ein verbreiteter Mythos: Die Verantwortung liege komplett bei SAP. Tatsächlich trägt der Kunde einen großen Anteil der Verantwortung selbst. Die BTP wird meist fachbereichsgetrieben eingeführt – etwa mit SuccessFactors oder der SAP Analytics Cloud – und kommt gewissermaßen „im Schlepptau” mit. Nach Max’s Erfahrung landet sie in rund 95 Prozent der Fälle dann bei der Basis oder in den Fachbereichen, wird nach bestem Wissen eingerichtet und wächst ohne übergreifendes Security Konzept weiter.
Ein Klassiker unter den Stolpersteinen ist die Authentifizierung über den SAP Universal User. Max’ klare Empfehlung: nicht nutzen, sondern den eigenen Corporate Identity Provider – bei vielen Kunden etwa der Microsoft-Account – anbinden. Je mehr Benutzer, Services und Schnittstellen hinzukommen, desto teurer wird das spätere Aufräumen, vor allem wegen der wachsenden Abhängigkeiten.
Fazit: SAP darf keine Blackbox bleiben
Die zentrale Botschaft der Folge: Ein schlechtes Bauchgefühl ist ein guter erster Indikator – aber kein Handlungsplan. Der Weg führt über eine qualifizierte Analyse, die Übersetzung technischer Findings in konkrete Geschäftsrisiken und eine abgestimmte Roadmap mit realistischen nächsten Schritten. In einem Kundenprojekt aus dem Automotive-Umfeld mit hohen TISAX-Anforderungen zeigte sich SAP trotz sehr gut aufgestellter Infrastruktursicherheit als blinder Fleck – bis klar wurde: Steht SAP, steht binnen zwei Stunden die Produktion. Genau diese Übersetzung überzeugt am Ende auch den Vorstand.
