Ein Event der ganz anderen Art: Data Security for SAP.live
Ich werde mich sehr bemühen, den Ausdruck „neue Normalität“ zu vermeiden. Erstens, kann ich den Begriff nicht mehr hören, und zweitens, kann man nicht von Normalität sprechen, wenn sich die Situation von Tag zu Tag ändert.
Vor Kurzem habe ich an unserem virtuellen Event sap.live teilgenommen. In den letzten sechs Jahren hat EPI-USE Labs regionale Events und Konferenzen veranstaltet. Ich durfte um die ganze Welt reisen und Vorträge halten. Dabei habe ich tolle Menschen kennengelernt, die unsere Software täglich nutzen. Seit März haben wir mehr Inhalte über digitale Plattformen ausgetauscht, aber unsere virtuelle Konferenz „Data Security for SAP .live“ war etwas völlig Neues. Die zweitägige Veranstaltung wurde weltweit mit Kunden, Partnern und internen Experten aus Europa, Afrika und Amerika koordiniert. Es ging um sicherheitsrelevante Themen wie unter anderem Datenschutzrecht, GRC und Risikomonitoring. Falls Sie die Veranstaltung verpasst haben, können Sie sich hierdie Aufzeichnungen der einzelnen Sessions ansehen.
Am ersten Tag habe ich für die letzte Session: „Häufige SAP-Hacks: Sind Ihre SAP-Daten so sicher, wie Sie glauben?“ gehalten. Darum soll es auch hier gehen.
Workarounds versus Hacking
Die Veranstaltung war etwas völlig Neues, weswegen ich etwas ganz anderes probieren wollte. Mir war klar, dass die Teilnehmer vor der letzten Session des Tages schon eine Menge Folien gesehen haben. Deshalb habe ich die Folien auf ein absolutes Minimum beschränkt. Stattdessen habe ich auf meinem Bildschirm ein paar „Hacks“ gezeigt, die vor allem in Nicht-Produktionssystemen vorkommen können. Ich verwende den Begriff „Hack“ mit Vorbehalt. Damit ist nicht gemeint, dass jemand von außerhalb des Unternehmens illegal auf ein System zugreift. Vielmehr geht es darum, dass jemand in einem System Zugang zu A, B und C erhält und einen Weg findet, D auszuführen. In vielen Fällen war D Teil der Aktivität oder sehr wichtig für die Ausführung der Aktivität, für die man mich hinzugezogen hat.
Die Session sollte Administratoren und Berechtigungsprüfer darauf aufmerksam machen, wie Transaktionen, Programme und Funktionsaufrufe in SAP technisch funktionieren. Wer diesen Text mit der Absicht liest, selbst Berechtigungsprüfungen zu umgehen, sollte es bitte mit Bedacht, Rücksicht und Integrität tun. Wenn Sie nach Ihren Aktivitäten gefragt werden, können Sie den Zugriff auf D rechtfertigen, ohne einen direkten Zugang gehabt zu haben? Wurde das bei Ihrem Zugang übersehen und haben Sie mit Ihrem Workaround allen Arbeit gespart? Oder greifen Sie auf etwas zu, von dem Sie wissen, dass Sie dazu nicht in der Lage sein sollten?
Im letzten Fall – oder wenn Sie Zweifel haben – empfehle ich dringend, den erweiterten Zugang über die normalen Wege zu beantragen.
Die Rolle des Codes
In der Session habe ich drei solcher Workarounds vorgestellt. In der Keynote wurde unter anderem dieser Punkt angesprochen: Wer von zu Hause aus arbeitet, „testet“ womöglich eher die eigenen Berechtigungen aus. Niemand bekommt dieses „austesten“ so leicht mit, wie es im Büro der Fall wäre. Daran habe ich bei der Vorbereitung noch nicht gedacht, aber das ist aus meiner Sicht relevant.
Alle drei Workarounds erfordern ein technisch besseres Verständnis von SAP, als die meisten SAP Anwender wahrscheinlich haben. Die Berechtigungen werden hauptsächlich auf zwei Arten geprüft:
Zuerst als Ergebnis von etwas, das der Programmierer beabsichtigt. Er kann in seinem Code das Schlüsselwort AUTHORITY-CHEC' verwenden und ein Berechtigungsobjekt (z.B. S_TABU_DIS) mit einem oder mehreren ID-Werten übergeben. Diese Werte müssen im Benutzerstammsatz, mit dem Berechtigungsobjekt, verzeichnet werden. Zum Beispiel folgendermaßen:
AUTHORITY-CHECK OBJECT 'S_TABU_DIS'
ID 'ACTVT' FIELD ‘03’
ID 'DICBERCLS' FIELD pd_group.
In diesem Beispiel ist der Feldwert für ACTVT explizit angegeben, der andere ID-Wert ist eine Variable im Code. Aber auch dabei werden alle ID-Werte des Objekts geprüft. Das ist nicht immer der Fall. Das Muster in einer Rolle wie dieser:
könnte zugewiesen werden, um einem Benutzer Zugriff auf etwas zu geben, das eine Berechtigungsprüfung nur für die IDs Aktivität und Objektkategorie ausführt. Um besser zu sehen, was der Code aufruft, können auch technische Namen eingeschaltet werden:
SAP warnt Sie, wenn Sie die Felder überhaupt nicht pflegen. Deshalb würden Sie normalerweise den Dummy-Wert zu den Feldern hinzufügen, die für die Prüfung, die Sie zu bestehen versuchen, nicht erforderlich sind. Dadurch wird sichergestellt, dass Sie nicht versehentlich Zugriff für etwas anderes geben, das andere IDs prüft.
Eine Berechtigungsprüfung kann auf eine zweite Art erfolgen: Wenn der Kernel sie automatisch auslöst. Zum Beispiel: Wenn jemand einen Transaktionscode ausführt, wird die S_TCODE-Berechtigungsprüfung für die ID TCD (die einzige ID des Objekts) mit dem Transaktionsnamen durchgeführt. Und das führt Sie zum ersten Hack.
Laden Sie unser Whitepaper herunter: „So verhindern Sie die drei häufigsten SAP Hacks“
Einen Kommentar schreiben