Die Tücken von SU53: Mehr Schein als Sein bei SAP-Berechtigungen

Sap Su53 ist ein Werkzeug, das sowohl geliebt als auch gefürchtet wird. Wenn Benutzer über Fehlermeldungen klagen, ist der erste Weg oft in diese Transaktion, um die Ursache zu finden. Doch die roten Linien, die SU53 anzeigt, sind nicht immer das, was sie zu sein scheinen. Viele davon sind harmlose interne Prüfungen von SAP, sogenannte “False Positives”, die fälschlicherweise auf fehlende Berechtigungen hindeuten. Das blinde Zuweisen von Berechtigungen, um diese roten Markierungen verschwinden zu lassen, kann jedoch zu erheblichen Sicherheitsrisiken und Problemen bei Audits führen. Dieser Artikel beleuchtet die häufigsten “False Positives” in SU53 und erklärt, warum Sie nicht jeder roten Zeile Glauben schenken sollten.

Das Problem: Wenn SU53 mehr verwirrt als hilft

Ein Benutzer meldet einen Fehler in einer Transaktion, und schnell öffnet man SU53. Dort steht dann zum Beispiel:

Fehlendes Autorisierungsobjekt: S_ALV_LAYO
Aktivität: 23 (Pflege)

Obwohl die Transaktion des Benutzers einwandfrei funktioniert, neigen viele Teams dazu, dieses Objekt “vorsichtshalber” zuzuweisen. Langsam, aber sicher, wird dadurch die Systemsicherheit ausgehöhlt. Die Wahrheit ist: Nicht jede rote Linie in SU53 stellt ein echtes Problem dar. Einige sind lediglich interne Prüfungen, die SAP von vornherein so vorsieht, ohne dass der Benutzer diese Berechtigung tatsächlich benötigt.

Häufige “False Positive”-Objekte in SU53 – Mit Beispielen

Es gibt eine Reihe von Autorisierungsobjekten, die in SU53 häufig rot erscheinen, obwohl sie für den reibungslosen Ablauf einer Transaktion oft irrelevant sind.

1) S_ALV_LAYO – Verwaltung von ALV-Layouts

Ein Benutzer führt eine Transaktion wie ME2N (Bestellungen nach Lieferant) aus, und SU53 zeigt ein fehlendes S_ALV_LAYO an.

  • Warum passiert das?
    Jeder ALV-basierte Bericht (mit sortierbaren, anpassbaren Tabellen) ruft S_ALV_LAYO automatisch auf, wenn Layouts geladen oder gespeichert werden – selbst wenn der Benutzer niemals versucht, ein solches zu speichern.

  • Auswirkungen:
    Die Autorisierungsprüfung schlägt fehl und wird protokolliert, aber die Transaktion läuft normal weiter.

  • Warum nicht zuweisen?
    Die Zuweisung von S_ALV_LAYO mit weitreichenden Aktivitäten (z. B. 23 – Pflege) erlaubt Benutzern, globale Layouts zu überschreiben, die von anderen Benutzern verwendet werden, oder gemeinsame Layouts zu erstellen und zu löschen. Dies beeinträchtigt die Konsistenz von Berichten.

  • Besserer Ansatz:
    Lassen Sie dieses Objekt unzugewiesen. Wenn Benutzer unbedingt Layouts speichern müssen, sollten dies lokale Layouts sein, die nur sie selbst betreffen.

Weiterlesen >>  Die Aufnahme von Präsentationen in Microsoft PowerPoint: Eine umfassende Anleitung

2) S_GUI – Zugriff auf Frontend-Dateien

Ein Benutzer exportiert einen Bericht nach Excel oder klickt auf “Herunterladen”, bricht dann aber den Dialog zum Speichern der Datei ab. SU53 zeigt trotzdem S_GUI an.

  • Warum passiert das?
    Funktionsbausteine wie GUI_DOWNLOAD und CL_GUI_FRONTEND_SERVICES=>FILE_SAVE_DIALOG führen eine Prüfung gegen S_GUI durch, unabhängig davon, ob die Operation erfolgreich abgeschlossen wird oder nicht.

  • Warum nicht zuweisen?
    Die Zuweisung von S_GUI ermöglicht uneingeschränkten Datei-Upload und -Download vom SAP GUI aus – ein erhebliches Risiko für die Datenexfiltration. Benutzer könnten vertrauliche Tabellen auf lokale Laufwerke exportieren oder nicht verifizierte Dateien importieren.

  • Besserer Ansatz:
    Exporte sollten nur über kontrollierte Fiori-Anwendungen oder ALV-Schnittstellen erfolgen. Für GUI-basierte Benutzer reichen die vorhandenen ALV-Download-Funktionen aus (diese erfordern kein S_GUI).

3) S_TCODE – Prüfung des Transaktionscodes

Ein Benutzer führt einen Z-Bericht aus, der intern eine andere Transaktion aufruft (z. B. über CALL TRANSACTION ‘FB03’). SU53 zeigt ein fehlendes S_TCODE für diesen Code an, aber der Hauptprozess funktioniert.

  • Warum passiert das?
    SAP prüft S_TCODE bei jedem Start einer Transaktion – selbst wenn es sich um eine Hintergrund- oder sekundäre Prüfung handelt.

  • Warum nicht zuweisen?
    Das zufällige Zuweisen von Transaktionscodes zur Behebung von SU53-Alarmen kann sensible Transaktionen unbeabsichtigt freischalten. Beispielsweise könnte die Autorisierung für FB03 indirekt den Zugriff auf Buchhaltungsbelege außerhalb des Zuständigkeitsbereichs eines Benutzers ermöglichen.

  • Besserer Ansatz:
    Autorisieren Sie nur die Transaktionen, die Geschäftsanwender direkt ausführen sollen.

S_ADMI_FCD – Administrative Funktionscodes

Ein Logistikbenutzer führt VL03N aus, und SU53 meldet ein fehlendes S_ADMI_FCD mit dem Wert STOR.

  • Warum passiert das?
    Viele Standard-Funktionsbausteine führen eine “Admin-Prüfung” durch, um zu entscheiden, ob erweiterte Funktionen oder zusätzliche Schaltflächen (z. B. System-Traces, Speicheroptionen) aktiviert werden sollen.

  • Warum nicht zuweisen?
    S_ADMI_FCD schaltet interne Basis-/Admin-Funktionen frei, die nicht für Endbenutzer bestimmt sind – z. B. SPOO (Spool-Administration), STOR (Speichermanagement), SCPR (Customizing). Diese können das Systemverhalten, Spool-Ausgaben oder Customizing-Inhalte verändern.

  • Besserer Ansatz:
    Ignorieren Sie diese Prüfung, es sei denn, der Benutzer führt tatsächlich Systemadministrationsaufgaben durch.

Weiterlesen >>  Avira PC-Cleaner: Ihr Weg zu einem schnelleren und saubereren Computer

S_TABU_DIS / S_TABU_NAM – Prüfungen zur Tabellenpflege

Ein Finanzbenutzer führt FB03 (Beleganzeige) aus, und SU53 zeigt S_TABU_DIS für die Tabelle V_T001 an.

  • Warum passiert das?
    SAP führt eine generische Prüfung für Konfigurationstabellen durch, selbst wenn das Lesen intern von der Transaktion gehandhabt wird.

  • Warum nicht zuweisen?
    Diese Objekte steuern die Tabellenpflege und den SM30-Zugriff. Die Zuweisung gewährt direkten Lese- (oder Änderungs-) Zugriff auf Konfigurationstabellen – ein ernstes Risiko für die Funktionstrennung (SoD).

  • Besserer Ansatz:
    Lassen Sie diese Objekte unzugewiesen, es sei denn, der Benutzer pflegt Customizing über SM30/SM31.

S_BTCH_JOB / S_BTCH_ADM – Steuerung von Hintergrundjobs

Ein Power-User führt SM37 aus, um seine eigenen Hintergrundjobs anzuzeigen. SU53 zeigt S_BTCH_ADM an.

  • Warum passiert das?
    SM37 führt intern immer Admin-Prüfungen durch, um zu entscheiden, ob “Alle Jobs” angezeigt werden sollen. Selbst wenn der Benutzer nur seine eigenen Jobs anzeigt, wird die Prüfung ausgelöst.

  • Warum nicht zuweisen?
    Die Zuweisung von S_BTCH_ADM=Y erlaubt dem Benutzer, alle Jobs im System anzuzeigen, abzubrechen und zu ändern – einschließlich systemkritischer Jobs.

  • Besserer Ansatz:
    Ignorieren Sie SU53 hier; solange der Benutzer seine eigenen Jobs sehen kann, besteht kein Problem.

5) S_RFC – Autorisierung für Remote Function Call

Ein Benutzer führt einen Prozess aus, der eine RFC-Destination aufruft (z. B. RFC_PING). SU53 meldet ein fehlendes S_RFC.

  • Warum passiert das?
    Jede Funktionsbausteinprüfung, die über RFC ausgelöst wird, erfolgt lokal, bevor geprüft wird, ob die Destination vertrauenswürdig ist.

  • Warum nicht zuweisen?
    Die Zuweisung von Wildcards wie S_RFC: RFC_TYPE=* oder RFC_NAME=* setzt das System unautorisierten Remote-Aufrufen und systemübergreifenden Exploits aus.

  • Besserer Ansatz:
    Prüfen Sie, ob der RFC vertrauenswürdig ist oder mit einem Systembenutzer ausgeführt wird – typischerweise ist hierfür keine Endbenutzerautorisierung erforderlich.

6) S_DEVELOP – Zugriff auf Entwicklungsobjekte

Ein Benutzer öffnet einen Berichtsvariantenbildschirm, und SU53 zeigt ein fehlendes S_DEVELOP an.

  • Warum passiert das?
    Der Bericht greift auf Metadaten aus dem ABAP Dictionary zu, was eine Autorisierungsprüfung für S_DEVELOP durchführt. Dies ist eine Prüfung auf Informationsebene, kein Ausführungsblocker.

  • Warum nicht zuweisen?
    S_DEVELOP gewährt Zugriff auf ABAP-Entwicklungswerkzeuge (SE38, SE80) – und gibt Benutzern die Möglichkeit, Programme zu bearbeiten oder zu debuggen. Dies stellt eine massive Verletzung der Funktionstrennung (SoD) dar.

  • Besserer Ansatz:
    Weisen Sie dies in Produktionssystemen niemals zu. Entwickler sollten dies nur in DEV-Systemen haben.

Weiterlesen >>  PDF-Erstellung in AutoCAD: Automatisieren und Beschleunigen

7) S_SPO_ACT / S_SPO_DEV – Spool- und Druckberechtigungen

Ein Benutzer zeigt einen Bericht an, druckt ihn aber nicht. SU53 meldet ein fehlendes S_SPO_ACT.

  • Warum passiert das?
    SAP führt Spool-Prüfungen für jeden Bericht durch, der gedruckt werden könnte – selbst wenn der Benutzer nie “Drucken” auswählt.

  • Warum nicht zuweisen?
    Diese Autorisierungen ermöglichen die Manipulation von Spool-Ausgaben (Löschen, Umleiten oder Ändern von Druckergebnissen). Ein böswilliger Benutzer könnte Audit-Protokolle löschen oder vertrauliche Ausdrucke umleiten.

  • Besserer Ansatz:
    Ignorieren Sie dies, es sei denn, die Druckausgabe schlägt tatsächlich fehl.

8) S_USER_GRP / S_USER_AUT – Benutzeradministrationsprüfungen

Ein HR-Benutzer führt einen Bericht aus, der Mitarbeiternamen anzeigt; SU53 meldet ein fehlendes S_USER_GRP.

  • Warum passiert das?
    SAP prüft die Benutzergruppenzuweisungen intern beim Lesen von Benutzerstammdaten – selbst wenn der Benutzer keine Benutzer verwaltet.

  • Warum nicht zuweisen?
    Die Vergabe dieser Berechtigungen eröffnet Möglichkeiten zur Benutzerstammdatenadministration (SU01, SUIM) und verstößt gegen SoD-Prinzipien.

  • Besserer Ansatz:
    Ignorieren Sie dies, es sei denn, der Benutzer ist Teil der Sicherheitsadministration.

Warum Sie SU53 nicht durch Zuweisung von Berechtigungen “reparieren” sollten

[

Checkliste für Best Practices

  1. Funktionalität prüfen: Vergewissern Sie sich immer, ob die gemeldete “fehlende” Prüfung die Funktionalität tatsächlich blockiert.
  2. STAUTHTRACE nutzen: Verwenden Sie STAUTHTRACE, um alle durchgeführten Prüfungen anzuzeigen – nicht nur die letzte von SU53.
  3. Support schulen: Vermitteln Sie Ihrem Supportteam: “Rot in SU53 ≠ Fehlende Berechtigung.”
  4. Keine pauschalen Zuweisungen: Weisen Sie niemals Objekte wie S_ALV_LAYO, S_GUI, S_BTCH_ADM, S_DEVELOP etc. Endbenutzern zu, es sei denn, es gibt einen eindeutigen Geschäftsgrund.
  5. Whitelist bekannter Prüfungen: Dokumentieren und listen Sie bekannte, harmlose Prüfungen in Ihren Support-SOPs (Standard Operating Procedures).

Das letzte Wort

SU53 lügt nicht – aber es erzählt auch nicht immer die ganze Wahrheit. Viele der angezeigten “fehlenden” Autorisierungen sind lediglich technisches Rauschen von SAPs internen Prüfungen. Ein guter Sicherheitsanalyst weiß, wie man echte Lücken von Fehlalarmen unterscheidet und hält das System sicher, ohne die Geschäftsprozesse zu beeinträchtigen.

Wenn Sie das nächste Mal ein SU53-Screenshot erhalten, eilen Sie nicht zur Zuweisung von Berechtigungen. Halten Sie inne, denken Sie nach – und konsultieren Sie lieber noch einmal diesen Artikel. 😉