Top 5 Ausreden für SAP_ALL
Autor: Tobias Harmes | 2. Januar 2015
In meinen Projekten für das Redesign von SAP Berechtigungskonzepten und SAP Systemberechtigungen erlebe ich immer wieder verschiedenste Ausreden, warum alles gut ist wie es ist. Hier sind die fünf meistgenannten Antworten, warum SAP_ALL in Ordnung ist und ein SAP Berechtigungsredesign "doch nicht so wichtig ist".
1. Ich vertraue meinen Mitarbeitern.
Ist es Mißtrauen, wenn sich ein Unternehmen vor menschlichen Fehlern schützt? Was passiert, wenn ein Disponent im guten Glauben eine Liefersperre entfernt, weil die Ware ach so eilig raus gehen soll – ohne zu wissen, dass der Kunde insolvent ist? Obwohl es niemand absichtlich gemacht hat – der Schaden ist da.
2. Woher sollen meine Mitarbeiter wissen, wie man SAP hackt?
Googlen Sie doch mal “sap hacken”. Zurzeit 80.000 Treffer – Tendenz steigend. Inklusive Treffer auf youtube mit Video-Anleitung.
3. Was kann da schon passieren?
Wie lange benötigen Sie für eine Komplett-Wiederherstellung inklusive Wiederanlauf? Was kostet Sie der Ausfall Ihres SAP-Systems für zwei Tage? Wieviel sind die Konstruktionszeichnungen dem Mitbewerber wert? Und wieviel die Liste der Geschäftspartner inklusive Preiskonditionen?
SAP Berechtigungsredesignworkshop mit dem Fachbereich
In unserem zweitägigen Redesignworkshop beschäftigen wir uns mit der Abstimmung von Funktionsrollen für die Fachbereiche Ihres Unternehmens.
4. Wir haben eine Firewall.
Firewalls und andere Sicherheitsprodukte bieten Sicherheit gegen das Ausnutzen von Schwachstellen und Sicherheitslücken von Software. Sie bieten keinen Schutz gegen das erlaubte Zugreifen auf Ihre SAP Daten. Aus Sicht des Systems lautet die Devise: Benutzer mit SAP_ALL oder Varianten dürfen das.
5. Bisher ist noch nie etwas passiert.
Wirklich? Wie oft haben Sie eigentlich schon kontrolliert, ob sich jemand einen Kreditor mit der eigenen Bankverbindung angelegt hat? Wer kann eigentlich alles bei Ihnen einen Zahllauf ausführen?
Fazit zu den SAP_ALL Ausreden
Auch wenn man darüber vielleicht schmunzeln kann – viele der Gesprächspartner sind IT-Leiter und Geschäftsführer. Sie sind somit mehr oder weniger direkt verantwortlich für die ihnen anvertrauten Daten. Und nicht zuletzt stehen sie für die korrekte Buchführung und ordnungsgemäße Bilanz ein. Es spricht für sie, dass sie wenig “kriminelle Fantasie” haben – andere haben diese aber. Und das war bei den uns bekannten Fälle sehr teuer.
Nicht nur zum Jahreswechsel hat man die Gelegenheit neue Vorsätze zu fassen und den Umgang mit der SAP Sicherheit neu auszurichten. Wie ist es bei Ihnen? Rufen Sie mich an unter 0211.9462 8572-25 oder mailen an harmes@rz10.de.
3 Kommentare zu "Top 5 Ausreden für SAP_ALL"
Toller Artikel.
Im Salesforce Umfeld bekomme ich täglich die gleichen Ausreden für die Verwendung von “Modify All Data” und die Verwendung des Administratorprofils zu hören.
Ich werde diesen Artikel in Zukunft in Berechtigungsdiskussionen mit einfließen lassen.
Liebe Grüße
Robert Richter
Klar sap_all ist ein no go!
Aber, da Ich Basisbetreuer, Entwickler und Berater in einem bin, benötige Ich zumindest alle Anzeigeberechtigungen (ausser HR , was black box ist) für die Module und alle Customizing-tcodes (nicht nur spro , sondern auch OA* tcodes u.ä.)
Gibt es hier vielleicht ein Muster-Profil oder Rolle???
VG
Andreas Mann
Hallo Herr Mann.
In manchen Fällen bietet es sich an, ein abgespecktes SAP_ALL zu bauen, in dem zumindest Funktionen wie S_DEVELOP mit DEBUG/Replace und Löschen von Änderungsbelegen entfernt sind. Ihr User bekommt diese Spezialrolle, außerdem wird Ihr User in das Security Audit Log mit aufgenommen. Eine Read-Only-Rolle (z.B. SAP_ALL in eine Rolle, alle Aktivitäten verändern) ist leider sehr aufwändig und lässt sich leider nicht ohne nennenswerten Aufwand aktuell halten.
Viele Grüße, Tobias Harmes