Eine Migration auf SAP S/4HANA® bietet die Chance, das bestehende Berechtigungskonzept gründlich auf Schwachstellen zu prüfen, bevor Altlasten in das neue System übernommen werden. Leider vernachlässigt mehr als ein Viertel der SAP-Anwenderunternehmen die Sicherheit bei S/4HANA®-Migrationen komplett. Dabei zählt die Überprüfung von Rollen und Berechtigungen längst zu den häufigsten Sicherheitsmaßnahmen in SAP-Systemen (78 % der Unternehmen führen dies regelmäßig durch). Warum also jetzt handeln? Weil das Berechtigungskonzept maßgeblich die Sicherheit Ihrer Unternehmensdaten bestimmt – und weil eine frühzeitige Risikoanalyse einen reibungslosen Übergang und einen sicheren Start in S/4HANA® gewährleistet.
SoD-Konflikte frühzeitig aufdecken
In SAP-Systemen gilt das Minimalprinzip: Jeder Benutzer sollte so wenige Berechtigungen wie möglich und nur so viele wie nötig erhalten. Ebenso muss auf die Trennung kritischer Funktionen (Segregation of Duties, SoD) geachtet werden. Werden Aufgaben kombiniert vergeben, steigt das Risiko von SoD-Konflikten, die gravierende Prozess- und Compliance-Probleme nach sich ziehen können. SoD-Konflikte – ob kleine Schwachstellen oder eklatante Lücken – eröffnen Angriffsflächen für Fehler oder sogar Betrug und belasten die interne Kontrolle. Best Practice ist daher, Rollen proaktiv auf SoD-Verstöße zu prüfen und Konflikte zu bereinigen, bevor Anwender produktiv damit arbeiten. Grundsätzlich sollten Rollen frei von eingebauten Funktionstrennungskonflikten und kritischen Berechtigungen sein. Die frühzeitige Identifikation solcher Konflikte (z. B. durch Simulationen oder Berechtigungs-Checks in der Vorprojektphase) ermöglicht es, ein schlankes, regelkonformes Rollenmodell für S/4HANA® aufzubauen – lange bevor ein Verstoß in Produktion zum Prüfungsfall wird.
Kritische Berechtigungen im Blick: Debug & Replace
Neben Konflikten zwischen Berechtigungen verdienen kritische Einzelberechtigungen höchste Aufmerksamkeit. Ein prominentes Beispiel aus der SAP-Welt ist Debug & Replace: Über das Berechtigungsobjekt S_DEVELOP mit Debug-Option können Nutzer Programme im Debug-Modus beeinflussen. Was in Entwicklungsumgebungen nötig ist, wird auf einem Produktionssystem zum erheblichen Risiko. Diese Debug-Berechtigung erlaubt es, den normalen Programmablauf zu manipulieren und Werte während der Ausführung zu ändern – ein Anwender könnte so z. B. einen AUTHORITY-CHECK überspringen und unerlaubt auf Daten zugreifen. Derartige Zugriffe untergraben sämtliche Sicherheitsprüfungen. Deshalb sollten kritische Berechtigungen wie Debug & Replace vor der Migration identifiziert und konsequent auf das notwendige Minimum beschränkt werden. Gleiches gilt für ähnlich weitreichende Berechtigungen (z. B. SAP_ALL oder vergleichbare Profile): Sie gehören nicht in die Hände regulärer Benutzer, sondern allenfalls in dedizierte Notfall-User – und auch dort nur unter strikter Kontrolle. Wird dies missachtet, können interne Kontrollsysteme umgangen und prüfungsrelevante Anforderungen verletzt werden. Für die Praxis bedeutet das: Noch vor der S/4HANA®-Umstellung sollte eine Liste aller sensiblen Berechtigungen erstellt, deren Verwendung geprüft und unnötige Rechte entfernt oder speziell abgesichert werden.
Externe Dienstleister-Rollen unter Kontrolle
Viele Unternehmen greifen bei SAP-Projekten auf externe Dienstleister zurück – sei es für Beratung, Entwicklung von Berechtigungen oder Systemwartung. Die Rollen und Zugriffsrechte, die externe Partner erhalten oder entwickeln, müssen besonders streng kontrolliert werden. Zum einen besteht die Gefahr, dass ein Dienstleister aus Bequemlichkeit zu großzügige Rollen vergibt (z. B. mit Wildcard-Berechtigungen „*“), um technischen Problemen vorzubeugen. Ein häufiger Fehler bei S/4HANA®-Umstellungen ist etwa, alte Rollen 1:1 zu übernehmen und mit weitreichenden Platzhaltern zu versehen, „damit erstmal alles läuft“. Dies führt dazu, dass Benutzer unnötig breite Berechtigungen erhalten – im Extremfall Zugriff auf alle Funktionen einer Applikation. Zum anderen kennen externe Entwickler nicht immer alle internen Policies und könnten kritische Berechtigungen in ausgelieferten Rollen übersehen. Abhilfe schafft hier eine konsequente Qualitätsprüfung: Alle von externen Dienstleistern erstellten oder geänderten Rollen sollten vor dem Einsatz von der internen Berechtigungs-Administration geprüft werden. Dazu zählt die Kontrolle auf SoD-Konflikte und sensible Berechtigungen genauso wie die Einhaltung von Namenskonventionen und dem Minimalprinzip. Besonders Administrations- und Support-Zugänge externer Berater sind restriktiv zu handhaben – im Zweifel zeitlich befristet und eng überwacht. Die Praxis zeigt, dass eine unkontrollierte Vergabe hochprivilegierter Profile an externe Helfer verheerende Folgen haben kann. Daher gilt: Rollen, die an Externe vergeben werden, nur mit klar definiertem Umfang und regelmäßiger Überprüfung betreiben.
Fazit
Wer sein SAP-Berechtigungskonzept schon vor der S/4HANA®-Migration auf den Prüfstand stellt, legt den Grundstein für Sicherheit und Compliance im neuen System. Frühzeitig behobene SoD-Konflikte bedeuten weniger Risiko von Compliance-Verstößen oder betrügerischen Handlungen im Tagesgeschäft. Die Eindämmung kritischer Berechtigungen wie Debug & Replace schützt produktive Systeme vor Manipulationen und verhindert, dass bekannte Schwachstellen ins neue Umfeld mitwandern. Und die strikte Kontrolle extern entwickelter Rollen sichert ab, dass keine Hintertüren oder Überberechtigungen unbemerkt bleiben. Für die Praxis zahlt sich dieser Aufwand aus: Unternehmen starten mit aufgeräumten, prüfungssicheren Berechtigungen in SAP S/4HANA® – ohne böse Überraschungen und mit einem guten Gefühl für IT-Revision und Management. Jetzt ist der ideale Zeitpunkt, das Berechtigungskonzept systematisch auf Risiken abzuklopfen und fit für die S/4HANA®-Zukunft zu machen.