Trace-Rauschen im Berechtigungstrace: False Friends erkennen, sauber entscheiden

Wer ein Redesign ernsthaft angeht, kommt an Berechtigungstraces nicht vorbei. Ohne Trace sind wir maßgeblich auf SU24 angewiesen. Die SU24 ist als Ausgangspunkt nützlich, ihre Vorschlagswerte sind jedoch häufig generisch, historisch gewachsen und breiter als der konkrete Bedarf. Wenn wir sie ungeprüft übernehmen, rutschen Komfortpfade und Nebenwege in Rollen und es entstehen nahezu zwangsläufig Überberechtigungen.

Ein belastbarer Trace macht die Anforderungen messbar und ersetzt Bauchgefühl durch Evidenz. In der Praxis arbeiten wir mit STAUTHTRACE und verwandten Werkzeugen, um das Systemverhalten präzise zu beobachten, statt aus Screens und Menüs zu raten.

Daneben gibt es eine Reihe interessanter Drittanbieter-Tools, die Trace-Auswertungen in SAP mit Fokus auf Berechtigungsredesign unterstützen. Einige berücksichtigen Trace-Rauschen bereits. Wo solche Werkzeuge fehlen, zählt vor allem langjährige Projekterfahrung.

Was wir unter Trace-Rauschen verstehen

Trace-Rauschen sind Berechtigungsprüfungen ohne fachliche Relevanz für den konkret betrachteten Anwendungsfall. Frameworks, Komfortfunktionen oder administrative Dialoge lösen Prüfungen aus, obwohl der Nutzer diese Fähigkeit gar nicht braucht. Wer sauber unterscheiden möchte, erhöht gezielt die Signal-zu-Rauschen-Relation (Grüße an alle Elektrotechnik-Ingenieurinnen und Ingenieure). Entscheidend ist Klarheit vor dem Tracen. Welcher Anwendungsfall soll bewertet werden, welche Rolle führt ihn aus, in welcher Transaktion oder App läuft er, welche Daten sind beteiligt und woran erkennt man Erfolg. Je klarer diese Eckpunkte sind, desto belastbarer wird der Trace.

Technische Ursachen sind generische Framework-Checks, Seiteneffekte durch Exporte, Logs oder Hintergrundaufrufe sowie Bequemlichkeitsfunktionen der Oberfläche. Fachlich entsteht Rauschen, wenn Nutzer neugierig klicken, optional verfügbare Buttons ausprobieren oder in Menüs navigieren, die Nebenwege öffnen. Organisatorisch tragen Sammelrollen und unklare Verantwortlichkeiten ihren Teil bei.

Unterm Strich stammt die große Mehrheit des Trace-Rauschens aus pauschalen Vorabprüfungen auf mögliche, aber ungenutzte Absprünge sowie auf mögliche, aber ungenutzte Komfortfunktionen. 

Niemand hatte hier die Absicht innerhalb von unter 400 Millisekunden auf die VA15, VA25, VA05, VA45, VA35, VA55 und VC/2 abzuspringen

Wenn wir diese Muster erkennen und konsequent als nicht relevant einstufen, steigt die Aussagekraft des Traces spürbar.

Werkzeuge kurz eingeordnet

Für das Redesign stellen wir STAUTHTRACE in den Mittelpunkt. Die Transaktion ist in den meisten Systemen ohne Zusatzaufwand vorhanden, arbeitet systemweit über alle Applikationsserver und lässt sich sauber nach Benutzer, Mandant, Zeitraum, Ergebnistyp und Objekt filtern. Mit eng gesetzten Filtern erhalten wir schnell verwertbare Trefferlisten, die das tatsächliche Systemverhalten abbilden.

Zwei Grenzen sollten wir kennen. STAUTHTRACE zeigt Prüfungen chronologisch und führt sie nicht zu fachlichen Szenen zusammen. Außerdem basiert die Anzeige auf einem Puffer, der je nach Systemlast nur einen begrenzten Zeitraum umfasst. In der Praxis planen wir deshalb kurze, klar abgegrenzte Läufe, werten unmittelbar aus und bestätigen kritische Beobachtungen bei Bedarf mit einem identischen zweiten Durchlauf.

Alternativen:

SU53 zeigt die zuletzt fehlgeschlagene Prüfung und dient als schneller Zeiger, ersetzt aber keinen vollständigen Trace.

STUSOBTRACE ist ein langzeitfähiger, anwendungsbezogener Autorisierungstrace und steht ab SAP_BASIS 7.40 SP14 bereit, Kernel 7.45 Patch 112 vorausgesetzt.

STUSERTRACE ist der benutzerzentrierte Langzeit-Trace und steht ebenfalls ab SAP_BASIS 7.40 SP14 zur Verfügung, in der Praxis oft über SAP Note 2220030 eingeführt.

In Fiori-Landschaften (insbesondere public cloud) hilft die App Display Authorization Trace direkt aus dem Launchpad. Für ein breites, praxistaugliches Vorgehen bleibt STAUTHTRACE dennoch unser Werkzeug der ersten Wahl. Weitere Infos zur App hier.

Hinweis

Die folgenden Beispiele sind Beispiele aus Projekten. Ob und wie stark sie auftreten, hängt von Release- und Supportstand, von GUI oder Fiori sowie vom Customizing ab. Es ist keine vollständige Liste, sondern eine praktische Orientierung.

Beispiele aus der Praxis

PFCG und S_USER* beim Sessionstart: warum diese Checks erscheinen

Direkt nach der GUI Anmeldung zeigt der SAP Easy Access Bildschirm Schaltflächen wie Rolle anlegen und Benutzer zuordnen.

Beim Aufbau entscheidet die Oberfläche, ob diese Funktionen aktiv sind. Dafür laufen bereits beim Login Autorisierungsprüfungen. Im Trace sieht man das häufig über Aufrufe aus SAPLSUSE und SAPLSMTR_NAVIGATION_SIMULATION.

S_TCODE mit TCD = PFCG

Steuert die Aktivierbarkeit der Schaltfläche Rolle anlegen. Es handelt sich nicht um einen aktiven Start von PFCG, sondern um eine UI Sichtbarkeitsentscheidung.

S_USER*

Zur Familie zählen S_USER_GRP, S_USER_AGR, S_USER_PRO und S_USER_AUT. In neueren Ständen kann zusätzlich S_USER_SAS geprüft werden. Diese Checks entstehen durch die Bewertung, ob Funktionen wie Benutzer zuordnen, Gruppen oder Profilaktionen sowie objektbezogene Optionen angeboten werden dürfen. Das ist UI getrieben und kein bewusster Administrationsvorgang.

Einordnung für die Rollenarbeit

Im Enduser Kontext sind diese Treffer Sessionstart Rauschen. Sie begründen keinen Bedarf an Rollen oder Benutzerpflege und gehören ausschließlich in Adminrollen.

S_TABU_DIS: Relikt aus alten Zeiten

S_TABU_DIS wirkt vertraut, schließlich geht es scheinbar um Tabellenzugriffe und die hat jeder. Genau hier liegt die Gefahr. Das Objekt arbeitet mit Berechtigungsgruppen und ist dadurch grob. In modernen Konzepten überdeckt es schnell mehr, als beabsichtigt war, und bläht Rollen unnötig auf. In Enduser-Szenarien ist S_TABU_DIS fast immer Rauschen. Wenn es im Trace auftaucht, war es häufig nur die generische Absicherung des Dialogs. In neuen Rollen vermeiden wir S_TABU_DIS konsequent.

Wichtig zur Einordnung: Die Reihenfolge und das Zusammenspiel von S_TABU_DIS und S_TABU_NAM hängen von Release und Codepfad ab. In der klassischen Logik prüft die Standardroutine VIEW_AUTHORITY_CHECK zunächst S_TABU_DIS und greift nur bei fehlender Berechtigung zusätzlich auf S_TABU_NAM zu. In neueren SAP_BASIS-Ständen kann die Prüfreihenfolge so angepasst sein, dass zuerst S_TABU_NAM und anschließend S_TABU_DIS geprüft wird. In der Praxis sehen wir daher häufig beide Objekte im STAUTHTRACE, zwingend ist das jedoch nicht, insbesondere dort, wo Anwendungen oder Eigenentwicklungen weiterhin nur S_TABU_DIS hart prüfen.

Keine Regel ohne Ausnahme: Vor allem in älteren Releases oder in Eigenentwicklungen mit generischen AUTHORITY-CHECKs kommt es vor, dass ausschließlich S_TABU_DIS geprüft wird und S_TABU_NAM gar nicht im Trace auftaucht. Die langfristig saubere Lösung ist, den Code auf S_TABU_NAM oder einen selektiven Service umzubauen. Pragmatisch müssen wir bis dahin in produktiven Projekten gelegentlich S_TABU_DIS vergeben, so eng wie möglich, gut dokumentiert, mit Monitoring im Trace und einem klaren Rückbauplan. Keine Regel ohne Ausnahme.

S_TRANSLAT: Übersetzungswerkzeuge ohne fachliche Notwendigkeit

S_TRANSLAT erscheint überraschend oft, obwohl niemand Texte übersetzen soll. Viele Oberflächen prüfen im Vorbeigehen, ob Übersetzungsfunktionen möglich wären. Für Enduser hat das keinen Nutzen, für Sicherheit und Audit jedoch einen Preis. In Fachrollen lassen wir S_TRANSLAT weg. Nur Teams, die wirklich mit SE63 und Übersetzungsobjekten arbeiten, erhalten es gezielt.

S_PROJECT: Projektsystem im falschen Film

Auch S_PROJECT taucht gerne in Umgebungen auf, die gar nichts mit dem Projektsystem zu tun haben, etwa in FI oder MM. Framework Bezüge oder Statusmechanismen ziehen die Prüfung mit. Wenn keine echten PS Prozesse vorliegen, ist das ein klassischer False-Friend. Für PS Nutzer berechtigen wir S_PROJECT eng und bewusst, alle anderen kommen ohne aus.

S_CTS_ADMI: Transportlandschaft gehört nicht in Fachrollen

Viele Dialoge fragen pauschal nach Transport und Änderungsberechtigungen. Das ist technisch nachvollziehbar, fachlich aber selten nötig. S_CTS_ADMI öffnet Türen, die klar in Entwicklungs oder Basisrollen verortet sind. In Enduser Rollen hat es nichts verloren. Wenn es im Trace erscheint, dokumentieren wir es als systemisches Rauschen.

S_SPO_ACT: Spool Aktionen ohne Pflichtcharakter

Eine Druckvorschau reicht häufig, damit S_SPO_ACT im Trace steht. Der Teufel steckt im Detail. Rechte auf fremde Spools sind besonders sensibel und müssen von Endusern ferngehalten werden. In der Praxis ist S_SPO_ACT selten fachlich erforderlich. Wenn ein Bereich seine eigenen Spools ansehen muss, lässt sich das sehr eng modellieren. Der Standardfall bleibt: nicht vergeben.

S_ALV_LAYO mit ACTVT 23: globale Layoutpflege ist Chefsache

Hier entsteht oft ein Missverständnis. Benutzerspezifische ALV-Layouts kann jeder auch ohne S_ALV_LAYO speichern. Die Prüfung auf S_ALV_LAYO greift erst bei globalen Layouts. Mit Aktivität 23 darf man benutzerübergreifend ändern. Das wirkt sich sofort auf fast alle ALV-Layouts aus und gehört deshalb nur in die Hände von Key Usern oder Modulbetreuern mit klarer Governance.

In Enduser Rollen ist das ein Paradebeispiel für False Friends. Ergänzend taucht gelegentlich S_ALV_LAYR im Trace auf. Es steuert globale Layoutänderungen reportbezogen und damit enger. Für Enduser ist auch das in der Regel Rauschen.

Workflow Objekte: Anzeigen erzeugt nicht automatisch einen Bedarf

S_WF_WI, S_WF_ADM oder S_WFAR_OBJ erscheinen gerne, wenn jemand Workflowsichten öffnet, diagnostische Listen ansieht oder sich durch Hilfen klickt. Ohne echte Bearbeitung oder Administration von Workitems sind diese Prüfungen Beiwerk. Wir gewähren sie nur Workflow Ownern und Administratoren, alle anderen erhalten sie nicht.

Beispiele mit differenzierter Einordnung

S_DATASET: kritisch und je nach Rollentyp unterschiedlich

S_DATASET schützt Dateizugriffe auf dem Applikationsserver. Für Enduser ist das häufig ein Nebenprodukt. Exportfunktionen, Protokolle oder technische Helfer lösen Checks aus, obwohl gar keine Dateioperationen am Server benötigt werden. Hier hilft leider nur Testen. Glücklicherweise lässt sich Objekt nicht nur auf Pfade, sondern auch auf konkrete Reports einschränken. Wichtig ist, auch hier so restriktiv wie möglich vorzugehen, da dieses Berechtigungsobjekt in Vollausprägung sehr mächtig ist und entsprechend auch gerne in Audits zur Herausforderung werden kann.

S_BTCH_JOB, S_BTCH_NAM und S_BTCH_ADM: fein trennen

Für Hintergrundjobs unterscheiden wir klar zwischen Fachanwendern und Administratoren. Enduser, die eigene Jobs planen, brauchen S_BTCH_JOB in engem Zuschnitt. In der Praxis reicht meist JOBACTION = RELE zum Freigeben eigener Jobs. Es gibt für Fachanwender Anwendungsfälle wie der Zahllauf in der F110, die klassisch im Hintergrund ausgeführt werden müssen.

S_BTCH_NAM steuert, für welche Step-Benutzer ein Anwender Job-Schritte anlegen darf. Ohne dieses Objekt kann er ausschließlich sich selbst als Schritt-Benutzer eintragen. Mit gepflegtem BTCUNAME darf er zusätzlich andere Benutzer hinterlegen; die Schritte laufen dann mit deren Berechtigungen. Wenn ein fester technischer Benutzer erforderlich ist, schneiden wir S_BTCH_NAM exakt auf dessen BTCUNAME zu und begrenzen bei Bedarf mit S_BTCH_NA1 zusätzlich auf erlaubte Programme.

S_BTCH_ADM hebt den Nutzer in die Batchadministration. Mit BTCADMIN = Y erhält er weitreichende Rechte bis hin zu systemweiten Eingriffen. Diese Berechtigung gehört ausschließlich in Admin-Rollen.

Reports richtig einordnen: S_PROGRAM und S_PROGNAM

S_PROGRAM bleibt das Arbeitspferd für Reportstarts und SUBMIT. Es greift auch indirekt, wenn der Nutzer keinen Report von Hand startet, die Anwendung jedoch im Hintergrund einen Report einreicht. In solchen Fällen ist S_PROGRAM kein False Friend.

Die Ausprägung von AM10 bei P_GROUP wird hier tatsächlich benötigt

Wir schneiden über P_GROUP eng zu und verzichten auf Wildcards.

Generelle Empfehlung: Z-Transaktionen bauen, im Fall von direkten Reportaufrufen.

S_PROGNAM ist, wenn im Stack verfügbar und im relevanten Codepfad geprüft, die präzisere Alternative. Der Grund ist einfach: Hier berechtigen wir direkt auf den Programmnamen und erhalten damit eine echte Whitelist ohne Umweg über Berechtigungsgruppen. Das reduziert Kollateraleffekte, macht die Begründung im Audit leichter und hält Rollen schlanker. In der Praxis nutzen wir S_PROGNAM programmscharf, dokumentieren die freigegebenen Reports transparent und lassen S_PROGRAM als Fallback dort bestehen, wo Altcode oder Frameworks weiterhin nur auf P_GROUP prüfen.

Sonderfälle, die in eine allgemeine Enduser-Rolle gehören

S_GUI mit 60 und 61: Upload und Download sind Grundversorgung

Nahezu jeder exportiert irgendwann eine Liste nach Excel. In vielen Prozessen gehören Uploads genauso selbstverständlich dazu, zum Beispiel in der Massenpflege oder beim Import von Buchungsstapeln. Deshalb packen wir S_GUI mit den Aktivitäten 61 für Download und 60 für Upload in eine allgemeine Enduser-Basisrolle. Steuerung und Sicherheit erreichen wir über valide Prozesse, fachliche Prüfungen und Vier-Augen-Prinzipien, nicht über das komplette Vorenthalten dieser Funktionen.

S_SPO_DEV: Gerätezugriff gezielt freigeben

Drucken ist Alltag. Der Zugriff auf Druckgeräte muss trotzdem sorgfältig gesteuert werden. In die Basisrolle kommen die Standard- oder LOCAL-Geräte sowie explizit freigegebene Drucker. Für Frontend-Druck nutzen wir häufig das Standardgerät LOCL. Archiv-, Fax- oder technische Geräte schließen wir aus. So bleibt die alltägliche Funktion erhalten, ohne ungewollte Seiteneffekte.

Quick-Matrix als Orientierung

Objekt oder Gruppe	Typischer Trigger	Persona	Risiko	Default
S_TABU_DIS	Tabellenoberflächen allgemein	Enduser	Überberechtigung	Raus, Ausnahme bei Altcode eng und befristet
S_TABU_NAM mit 03	gezielte Tabellenanzeige	Enduser	moderat	Eng rein, nur benötigte Tabellen
S_SPO_ACT	Vorschau, Spoollisten	Enduser	fremde Spools	Raus oder nur eigene Spools
S_SPO_DEV	Gerätedruck	Enduser	Gerätewildcards	Eng rein, z. B. LOCL und freigegebene Drucker
S_BTCH_JOB	Als Job einplanen	Enduser	Jobmissbrauch	Kontextabhängig, z. B. F110 mit RELE, nur eigene Jobs
S_BTCH_NAM	Jobs im Namen anderer	Enduser	sehr hoch	Raus
S_BTCH_ADM	Batch-Administration	Enduser	sehr hoch	Raus
S_ALV_LAYO mit 23	globale Layouts	Key User	breite Wirkung	Optional für Key User, Enduser raus
S_ALV_LAYR	reportbezogene Layouts	Key User	steuerbar	Optional für Key User, Enduser raus
S_TRANSLAT	Übersetzungsfunktionen	Enduser	Fehlrechte	Raus
S_PROJECT	Projektsystem	Enduser ohne PS	Fehlrechte	Raus, nur PS-Nutzer eng rein
S_CTS_ADMI	Transportverwaltung	Enduser	sehr hoch	Raus
S_PROGRAM	Report oder SUBMIT	Enduser oder Tech	mittel	Eng rein über P_GROUP, nur nötig wo genutzt
S_PROGNAM	programmscharf	Tech oder Dev	mittel	Besser wenn verfügbar, programmscharf rein
S_GUI 60 und 61	Upload und Download	Enduser	Datenfluss	Rein in Basisrolle
PFCG und S_USER*	Sessionstart UI-Schaltflächen	Enduser	Admin-Leak	Raus, als Sessionstart-Rauschen ignorieren

Fazit

Ein Trace ist im Redesign unverzichtbar. Er verhindert, dass wir uns blind auf SU24-Vorschlagswerte verlassen, und sorgt dafür, dass Rollen am echten Bedarf ausgerichtet sind. Mit klarem Anwendungsfall, engem Scope, Persona-Denken und einer konsequenten Policy für False Friends bleiben Rollen schlank, prüfbar und sicher.

Rauschen erkennt man in der Regel aufgrund von Erfahrung und dem zeitlichen Kontext. Fehlt langjährige, können Drittanbieter-Tools oder das Einbeziehen von externer Unterstützung eine sinnvolle Ergänzung bei einem Berechtigungsredesign-Projekt sein.

Bei Anmerkungen, Ergänzungen, Hinweise auf Fehler, gerne eine kurze Mail an blog@wtrknt.com

MfG DMa