19,99 €
Mehr erfahren.
- Herausgeber: Espresso Tutorials
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2017
Sensible Firmendaten dürfen einerseits nicht in falsche Hände geraten, bilden aber andererseits auch eine wichtige Grundlage für Entscheidungen und strategische Unternehmensausrichtungen. Vermeiden Sie ein Szenario von versehentlich zugänglichen Daten bzw. unvollständigen und damit unbrauchbaren Berichten, indem Sie Ihre SAP BW-Berechtigungen richtig implementieren.
Mit diesem Buch lernen Sie anhand anschaulicher Praxisbeispiele die aktuellen Konzepte zur Vergabe von Berechtigungen für Standard-, Analyse- und Planungssettings mit SAP BW genauer kennen. Das Autorenteam berücksichtigt hierbei neue SAP HANA-Funktionen. Die aus dem ABAP-Applikationsserver oder SAP Business Warehouse (BW) bekannten diversen Berechtigungstypen finden, je nach Art des Zugriffs, in ähnlicher Form auch bei SAP HANA Anwendung. Der kompakte Ratgeber bringt Ihnen auf Grundlage des neuesten Stands der Technik die System-, Objekt-, Paket-, Applikations- und analytischen Privilegien in SAP HANA näher.
Ein eigenes Kapitel beleuchtet zudem das Zusammenspiel mit SAP BW on HANA und SAP BW/4HANA sowie die daraus resultierenden Herausforderungen für ein wirkungsvolles Berechtigungskonzept.
- Analyse- und Planungsberechtigungen für SAP BW
- Reportingberechtigungen für SAP HANA
- kompakter Ratgeber auf dem neuesten Stand der Technik
- End-to-End Szenario für ein transparentes Zusammenspiel der Systeme
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 251
Ähnliche
Christoph Kretner Jascha Kanngießer
Berechtigungen in SAP® BW, HANA und BW/4HANA
Alle Rechte vorbehalten
1. Aufl. 2017, Gleichen
© Espresso Tutorials GmbH
URL:www.espresso-tutorials.com
Das vorliegende Werk ist in allen seinen Teilen urheberrechtlich geschützt. Alle Rechte vorbehalten, insbesondere das Recht der Übersetzung, des Vortrags, der Reproduktion und der Vervielfältigung. Espresso Tutorials GmbH, Zum Gelenberg 11, 37130 Gleichen, Deutschland.
Ungeachtet der Sorgfalt, die auf die Erstellung von Text und Abbildungen verwendet wurde, können weder der Verlag noch Autoren oder Herausgeber für mögliche Fehler und deren Folgen eine juristische Verantwortung oder Haftung übernehmen.
Feedback: Wir freuen uns über Fragen und Anmerkungen jeglicher Art. Bitte senden Sie diese an: [email protected].
Inhaltsverzeichnis
Willkommen bei Espresso Tutorials!
Unser Ziel ist es, SAP-Wissen wie einen Espresso zu servieren: Auf das Wesentliche verdichtete Informationen anstelle langatmiger Kompendien – für ein effektives Lernen an konkreten Fallbeispielen. Viele unserer Bücher enthalten zusätzlich Videos, mit denen Sie Schritt für Schritt die vermittelten Inhalte nachvollziehen können. Besuchen Sie unseren YouTube-Kanal mit einer umfangreichen Auswahl frei zugänglicher Videos:
https://www.youtube.com/user/EspressoTutorials.
Kennen Sie schon unser Forum? Hier erhalten Sie stets aktuelle Informationen zu Entwicklungen der SAP-Software, Hilfe zu Ihren Fragen und die Gelegenheit, mit anderen Anwendern zu diskutieren:
http://www.fico-forum.de.
Eine Auswahl weiterer Bücher von Espresso Tutorials:
Dr. Bernd Klüppelberg:
Techniken im SAP®-Berechtigungswesen
Marcel Schmiechen:
Berechtigungen in SAP® ERP HCM – Einrichtung und Konfiguration
Martin Metz & Sebastian Mayer:
Schnelleinstieg in SAP® GRC Access Control
Vorwort
In Zeiten von Big Data und dem Internet of Things (IoT) bilden Daten eine immer wichtiger werdende Ressource für Unternehmen. Gleichzeitig stellt das kontinuierliche Wachstum an Informationen – eine Studie des IDC von 2014 [1] spricht von einer Verdoppelung des weltweiten Datenbestands alle zwei Jahre – die Unternehmen bzw. deren IT vor große Herausforderungen: Neue Modelle der Datenhaltung entstehen, in denen die Aufbereitung und zeitaufwendige Harmonisierung der Daten klassischer Datawarehouse-Systeme an Bedeutung verlieren. Während die Daten immer aufwendiger gegen unbefugten Zugriff von außen geschützt werden müssen, findet innerhalb von Data Lakes i.d.R. keine granulare Prüfung mehr statt. Auf der anderen Seite besitzen aber auch die traditionellen Modelle nach wie vor Gültigkeit: Geht es um rechtlich verbindliche Anforderungen wie einen Jahresabschluss, hat die Datenqualität höchste Priorität. Für personenbezogene Daten ist ein restriktiver Zugangsschutz allein aus Datenschutzgründen zwingend erforderlich.
Mit SAP HANA hat die SAP ihren Kunden eine Technologie zur Verfügung gestellt, die komplexe Analysen auf strukturierten und unstrukturierten Daten gleichermaßen in Echtzeit ermöglicht. HANA ist nicht nur eine In-Memory-Datenbank für Anwendungen wie S/4HANA und BW, sondern es bietet eine komplette Entwicklungsumgebung für eigene native Anwendungen. Unter dem Stichwort Enterprise Information Management (EIM) oder HANA Data Warehouse lassen sich erstmals auch native SAP-Data-Warehouse-Lösungen jenseits von SAP BW betreiben. Dennoch wird BW nicht durch HANA ersetzt, die Data-Warehousing-Welt der SAP wird nur breiter und agiler. Je nach Szenario lassen sich Anforderungen sowohl mit BW-Mitteln als auch nativ umsetzen. Zugleich bestehen beidseitig Integrationsmöglichkeiten, sodass insbesondere hybride Szenarien an Bedeutung gewinnen. Mit der Veröffentlichung von BW/4HANA folgt SAP genau diesem Weg.
Auch wenn viele der Novitäten unter dem Stichwort »Simplification«, also Vereinfachung, angepriesen werden und für Entwickler und Anwender zahlreiche bis dato unbekannte Möglichkeiten bieten, so bedeutet eine neue Technologie für die Administration immer auch eine weitere Lernphase. Bevor die Vereinfachungen wirklich genutzt werden können, wird es daher oft erst einmal komplexer. Insbesondere wer jahrelang mit SAP BW gearbeitet hat, steht nun vor einer größeren Umstellung.
Dieses Buch soll Ihnen, zumindest für den Bereich der Berechtigungen, die Angst nehmen und Ihnen Schritt für Schritt zeigen, wie Sie auch in modernen Hybrid-Systemen und mit unterschiedlichen Technologien jederzeit den unkontrollierten Zugriff auf Daten unterbinden. Dabei richten wir uns gleichermaßen an Neu- und Quereinsteiger sowie BW-Berechtigungsexperten. Um für jeden Benutzer den optimalen Mehrwert zu gewährleisten, haben wir das Buch in drei Abschnitte untergliedert: Ein Teil befasst sich mit BW, einer mit HANA und der dritte mit hybriden Szenarien. Innerhalb der Bereiche erklären wir zunächst die wichtigsten Grundlagen und steigen dann immer tiefer in die Materie ein, geben Tipps und Tricks für den Praxiseinsatz und hoffen, auch für Experten den einen oder anderen noch unbekannten Kniff parat zu haben.
Beispiel-Daten
Für unsere Beispiele im Buch verwenden wir den SAP E-Procurement Demo Content (InfoArea 0EPM_CONT_DELV) für BW on HANA, der mit BW 7.5 SP04 ausgeliefert wurde.
Sobald die Datenmodelle übertragen wurden, können Sie mithilfe des EPM-Datengenerators (Transaktion SEPM_DG) eigene Beispiel-Daten generieren.
Übungsaufgaben
Das Buch enthält eine Reihe von Übungsaufgaben, die zum besseren Verständnis ggf. bereits einen Screenshot der gewünschten Lösung enthalten. Die eigentlichen Schritt-für-Schritt-Musterlösungen sind nicht Teil des Buches, sondern können im »Bonusmaterial« als PDF-Dokument unter folgender Adresse heruntergeladen werden:
http://5127bonus.espresso-tutorials.de/
Auf diese Weise möchten wir interessierten Lesern die Möglichkeit geben, das theoretisch erworbene Wissen an Praxisbeispielen selbst auszuprobieren und auf diese Weise zu festigen.
Verwendete Software-Versionen
Soweit nicht anders vermerkt, basieren alle Beispiele auf SAP BW 7.5 SP07 bzw. BW/4 1.0 SP04 und SAP HANA SPS12 bzw. HANA 2. Als Modellierungswerkzeuge kommen die SAP GUI 7.4 PL11, die BW-Modeling-Tools 1.18 sowie die HANA Web Workbench zum Einsatz. Ausschließlich in SAP BW4/HANA oder SAP HANA 2 verfügbare Funktionen sind explizit als solche gekennzeichnet.
Im Text verwenden wir Kästen, um wichtige Informationen besonders hervorzuheben. Jeder Kasten ist zusätzlich mit einem Piktogramm versehen, das diesen genauer klassifiziert:
Hinweis
Hinweise bieten praktische Tipps zum Umgang mit dem jeweiligen Thema.
Beispiel
Beispiele dienen dazu, ein Thema besser zu illustrieren.
Achtung
Warnungen weisen auf mögliche Fehlerquellen oder Stolpersteine im Zusammenhang mit einem Thema hin.
Übungsaufgabe
Übungsaufgaben helfen Ihnen, Ihr Wissen zu festigen und zu vertiefen.
Zum Abschluss des Vorwortes noch ein Hinweis zum Urheberrecht: Sämtliche in diesem Buch abgedruckten Screenshots unterliegen dem Copyright der SAP SE. Alle Rechte an den Screenshots hält die SAP SE. Der Einfachheit halber haben wir im Rest des Buches darauf verzichtet, dies unter jedem Screenshot gesondert auszuweisen.
1 Berechtigungen in SAP BW
Das SAP Business Warehouse, kurz SAP BW, ist wie alle Data-Warehouses ein OLAP(»Online Analytical Processing«)-System. Im Gegensatz zu transaktionalen Systemen wie dem SAP ERP, die in erster Linie für klassische Buchungen genutzt werden, stehen hier die Aufbereitung und Auswertung großer Datenbestände aus oft unterschiedlichen Quellen im Vordergrund. Daraus ergeben sich auch für das Berechtigungskonzept zusätzliche Anforderungen.
Da die Daten im BW i.d.R. aus unterschiedlichen Modulen oder Systemen stammen und die Modelle eine Vielzahl an Dimensionen und Attributen besitzen können, sind die Anforderungen an das Berechtigungsmanagement deutlich höher als bei einem klassischen ERP-System. Neben den SAP-Standardberechtigungen nutzt das SAP BW daher auch ein weiteres, BW-spezifisches Konzept, die sogenannten Analyseberechtigungen. Vereinfacht könnte man sagen: Die Standardberechtigungen regulieren den reinen Zugriff, entscheiden also, ob ein Anwender einen bestimmten Bericht überhaupt ausführen darf, die Analyseberechtigungen aber sind ausschlaggebend dafür, welche Daten dem Anwender im Berichtsergebnis angezeigt werden.
1.1 Benutzer, Rollen und Standardberechtigungen
In Bezug auf die Benutzer- und Rollenverwaltung unterscheidet sich das SAP BW nicht stark vom SAP ERP, allerdings werden nicht alle Funktionalitäten gleichermaßen genutzt. Wir werden uns im Folgenden daher auf die für das SAP BW relevanten Bereiche des SAP-Standardberechtigungswesens konzentrieren.
Modellierungswerkzeug SAP GUI
Auch wenn in SAP BW 7.5 und SAP BW/4HANA die Datenmodellierung mit den SAP BW-Modellierungswerkzeugen in Eclipse, im Folgenden BW-MT (für BW-Modeling-Tools), erfolgt, so werden Benutzer, Rollen und Berechtigungen nach wie vor in der klassischen SAP GUI verwaltet. Weitere Details zu und eine Einführung in die BW-MT finden Sie im Kapitel 4 des Bonusmaterials zu diesem Buch.
1.1.1 Benutzer
Das Benutzer-Management und insbesondere die getrennte Verwaltung von Benutzern und Berechtigungen (Stichwort »Vieraugenprinzip«) ist ein zu komplexes Thema, um es an dieser Stelle in Gänze zu behandeln. Für unsere späteren Beispiele in diesem Buch benötigen wir aber zumindest ein Grundverständnis von der Benutzeranlage. Und genau das wollen wir in diesem Abschnitt liefern.
User werden über die Transaktion SU01 (»Benutzerpflege«) angelegt (Abbildung 1.1).
Abbildung 1.1: Benutzeranlage mit der SU01
In der Einstiegsmaske müssen wir zunächst einen technischen Benutzernamen (max. zwölf Zeichen) festlegen oder über die Hilfe einen existierenden auswählen . Im Fall einer Neuanlage klicken wir auf das Icon »Erstellen« . Weitere mögliche Aktionen sind die Anzeige , das Ändern oder Löschen bestehender User, das Kopieren eines Users in einen neuen , das Sperren und Entsperren von Usern oder auch das Erneuern von Passwörtern . Insbesondere das Entsperren von Usern, z.B. aufgrund wiederholter Falscheingabe des Passworts, und das Neusetzen eines Initialpassworts (falls ein Anwender sein Passwort vergessen hat) werden uns im Rahmen von Berechtigungstests immer wieder beschäftigen.
User-Stammdaten anzeigen
In vielen Systemen ist die Transaktion SU01 selbst für Entwickler oder Support-Mitarbeiter gesperrt. Falls bestimmte Personen dennoch User-Stammdaten ansehen dürfen sollen, so kann stattdessen die Transaktion SU01D berechtigt werden, die eine reine Anzeigefunktion bietet. Beispielweise kann der Supportmitarbeiter dann zumindest überprüfen, welche Rollen einem Anwender aktuell zugewiesen sind.
Sofern wir uns für die Neuanlage oder das Ändern eines Users entschieden haben, gelangen wir zur eigentlichen Benutzerpflege-Sicht (Abbildung 1.2).
Abbildung 1.2: Benutzerpflege mit der SU01
Für uns von Interesse sind an dieser Stelle nur die Tabs Adresse, Logondaten und Rollen. Auf dem Tab Adresse müssen wir zumindest einen Namen für den User angeben, damit der Benutzer auch gespeichert werden kann.
Abbildung 1.3: Kennwortvergabe mit der SU01
Auf dem Tab Logondaten (Abbildung 1.3) vergeben wir ein initiales Passwort oder können uns dieses alternativ vom System generieren lassen. Nähere Hinweise zu den Kennwortrichtlinien und dazu, wie sich diese festlegen lassen, finden wir, wenn wir auf den oberen der beiden Infobuttons klicken.
Abbildung 1.4: Rollenzuordnung mit der SU01
Auf dem Tab Rollen (Abbildung 1.4) sehen wir alle einem User zugeordneten Rollen. Rollen können zeitabhängig vergeben werden, daher enthält die Tabelle zusätzlich einen Gültigkeitszeitraum. Oft werden Rollenzuweisungen nicht entfernt, sondern es wird lediglich deren Gültigkeit über das Enddatum gesetzt, sodass am Userstamm die komplette Historie der Rollenzuweisung sichtbar bleibt. Nicht mehr gültige Rollen lassen sich durch den Button »Veraltete Rollen markieren« () hervorheben. Die Statusampel am Button Benutzerstamm sollte immer grün sein. Ist dies nicht der Fall, so wurde der Benutzerstamm nicht aktualisiert, und neu zugeordnete Rollen sind u. U. noch nicht wirksam. Sollte die Statusampel also einmal rot sein, so müssen wir einen Abgleich durch Drücken des besagten Buttons Benutzerstamm erzwingen.
Zentrale Benutzerverwaltung
Ein in verteilten Systemen oft genutztes Verfahren zur Vereinfachung des Usermanagements ist die sogenannte zentrale Benutzerverwaltung (ZBV). In diesem Szenario kann eines der ABAP-Systeme als zentrales System definiert werden. Die Pflege der Benutzerstammsätze wird dann in diesem System vorgenommen und an die angebundenen Tochtersysteme (z.B. das BW) übertragen. Weitere Informationen zur ZBV bietet das SAP Help Portal (https://help.sap.com).
User-Gruppen verwenden
User können in sogenannten Usergruppen verwaltet werden, die mit der Transaktion SUGR angelegt und gepflegt werden. Usergruppen nutzt man zum einen, um Aufgaben der Benutzeradministration auf bestimmte Anwender-Gruppen zu beschränken und so z.B. das Vieraugenprinzip (»Segregation of Duties«) bei der Rollenzuordnung zu gewährleisten. In diesem Fall spricht man von »Usergruppen für Berechtigungen«, die in der SU01 auf dem Tab Logondaten gepflegt und über das Berechtigungsobjekt S_USER_GROUP geprüft werden. Zum anderen dienen User-Gruppen dazu, die Selektion einer größeren Anzahl von Usern zu vereinfachen, z.B. bei der Massenpflege in der Transaktion SU10. Hier spricht man von »allgemeinen Usergruppen« und ordnet sie über den Tab Gruppen in der SU01 zu.
1-1: Anlegen eines Test-Users
Für unsere späteren Testfälle müssen wir zunächst einen Test-User im System anlegen. Dazu rufen Sie die Transaktion SU01 auf, erstellen den Benutzer »USER_1« und weisen ihm ein Initialpasswort zu.
1.1.2 Berechtigungen
Standardberechtigungen werden in allen SAP-ABAP-Systemen verwendet. Dabei werden vordefinierte Berechtigungsobjekte ausgeliefert, die in Berechtigungsklassen gruppiert sind. Jedes Berechtigungsobjekt besitzt eine Reihe von Eigenschaften, sogenannte Berechtigungsfelder, die einzeln ausgeprägt werden können.
Über die Transaktion SU21 erhalten wir eine Übersicht aller im System vorhandenen Berechtigungsobjekte, gegliedert nach Klassen (siehe Abbildung 1.5, Ausschnitt aller Objekte). Für das SAP BW ist insbesondere die Klasse RS (»Business Warehouse«) von Interesse, die alle Berechtigungsobjekte enthält, die man zum Arbeiten mit dem SAP BW benötigt. Für jede relevante Aktion im BW gibt es jeweils ein eigenes Berechtigungsobjekt, z.B. eines für das Anlegen und die Nutzung von CompositeProvidern (S_RS_HCPR), eines für BW-Queries (S_RS_COMP), ein weiteres für Analysis-Office-Dokumente (S_RS_AO) usw. Einige dieser Berechtigungsobjekte sind v. a. für Administratoren oder Entwickler relevant, andere werden auch beim Zugriff auf Daten durch den Endanwender geprüft.
Abbildung 1.5: Objekte der Berechtigungsklasse RS
Betrachten wir nun das Berechtigungsobjekt S_RS_COMP (Business Explorer - Komponenten) näher, das beim Zugriff auf BW-Queries geprüft wird. Wenn wir in der Objektliste an die entsprechende Stelle scrollen und dann auf das Berechtigungsobjekt doppelklicken, gelangen wir in die zugehörige Detailsicht (Abbildung 1.6).
Abbildung 1.6: Details zum Berechtigungsobjekt S_RS_COMP
Wir sehen, dass das Objekt S_RS_COMP fünf Berechtigungsfelder enthält:
RSINFOAREA
: die InfoArea des Providers, auf dem das zu berechtigende Query-Objekt basiert,
RSINFOCUBE
: den InfoProvider, auf dem das zu berechtigende Query-Objekt basiert,
RSZCOMPTP
: das eigentlich zu berechtigende Query-Objekt (Query, Struktur, …),
RSZCOMPID
: den Namen des Query-Objekts,
ACTVT
: die erlaubte Aktivität.
Ein und dasselbe Berechtigungsfeld kann in unterschiedlichen Berechtigungsobjekten genutzt werden. Ein gutes Beispiel ist die Aktivität (ACTVT), die in fast allen Berechtigungsobjekten vorkommt und die jeweilige Art des Zugriffs bestimmt, wie etwa Erzeugen (01), Ändern (02), Anzeigen (03), Ausführen (16) (vgl. Abbildung 1.8). Endanwender erhalten i.d.R. ausschließlich die Aktivitäten 03 und 16. Per Doppelklick auf ein Berechtigungsfeld sehen wir eine Auflistung aller Berechtigungsobjekte, die dieses Feld enthalten.
Die Liste der möglichen Aktivitäten für ein bestimmtes Berechtigungsobjekt erhält man per Klick auf den Button zulässige Aktivitäten (Abbildung 1.7).
Abbildung 1.7: Zulässige Aktivitäten anzeigen
In Abbildung 1.8 sehen wir die zulässigen Aktivitäten für das Berechtigungsfeld Aktivität des Berechtigungsobjekts S_RS_COMP, das bestimmt, welche Art von Zugriff dem Anwender auf ein Abfrageelement gewährt wird.
Abbildung 1.8: Zulässige Aktivitäten für S_RS_COMP
Manche Berechtigungsfelder wie RSINFOCUBE werden als Freitext gepflegt, dabei sind auch Muster wie z.B. YEPM* möglich. Für andere sind nur bestimmte vorgegebene Werte zulässig, die bei der Ausprägung aus einer Liste ausgewählt werden können.
Bisher haben wir nur die Definition der Berechtigungsobjekte betrachtet, nicht die eigentliche Berechtigung. Letztere ergibt sich erst durch die Ausprägung der Berechtigungsobjekte, die Sie im nächsten Kapitel kennenlernen werden. Das Ergebnis einer solchen Ausprägung sieht dann aus wie in Abbildung 1.9, die eine typische Endanwender-Berechtigung für das Berechtigungsobjekt S_RS_COMP zeigt.
Abbildung 1.9: Mögliche Ausprägung von S_RS_COMP
Der Anwender darf in diesem Fall alle Abfragen im YEPM-Namensraum (d.h., der Name des Providers und der Query starten jeweils mit »YEPM«) ausführen (16), die Query-Definition ansehen sowie nach der Query suchen (03). An diesem kleinen Beispiel erkennen wir bereits, wie wichtig durchgängige Namenskonventionen im SAP BW sind, da sie die Berechtigungsvergabe erheblich vereinfachen. Umgekehrt können Berechtigungen auch dazu beitragen, eine Namenskonvention konsequent durchzusetzen, indem Entwickler für einen bestimmten Bereich im BW (z.B. FI-Reporting) nur im entsprechenden Namensraum (z.B. »ZFI*«) Objekte anlegen dürfen.
Eigene Berechtigungsobjekte definieren
Über die Transaktionen SU21 (»Berechtigungsobjekte und klassen«) und SU22 (»Berechtigungsfelder«) lassen sich kundeneigene Berechtigungsobjekte definieren. Diese sollten entsprechend auch in kundeneigenen Berechtigungsklassen abgelegt werden. Das Berechtigungsobjekt kann sowohl kundeneigene als auch von SAP ausgelieferte Berechtigungsfelder enthalten. Erlaubte Ausprägungen lassen sich ebenfalls pflegen.
Im normalen BW-Alltag wird man eher selten mit diesem Szenario konfrontiert. Sobald es jedoch um eigene ABAP-Entwicklungen geht, die geschützt werden müssen, und ggf. unterschiedliche Aktivitäten berechtigt werden sollen, lässt sich auf diese Weise sehr einfach eine individuelle Berechtigungsprüfung erstellen, die vollständig den SAP Standard nutzt und z.B. auch in der Standard-Protokollierung auftaucht.
Die eigentliche Berechtigungsprüfung auf ein kundeneigenes Berechtigungsobjekt kann aus beliebigem ABAP-Code heraus wie folgt angestoßen werden.
AUTHORITY-CHECK OBJECT 'S_RS_COMP'
ID 'RSINFOAREA' FIELD 'MYAREA'
ID 'RSINFOCUBE' FIELD 'MYCUBE'
ID 'RSZCOMPTP' FIELD 'REP'
ID 'RSZCOMPID' FIELD 'MYQUERY'
ID 'ACTVT' FIELD '03'.
IF SY-SUBRC <> 0. MESSAGE 'No authorization' TYPE 'E'.
ENDIF.
In unserem Beispiel nutzen wir das Standardobjekt S_RS_COMP, da Sie dieses bereits kennengelernt haben. Auf dieselbe Weise können Sie aber auch kundeneigene Objekte abfragen. Für die Prüfung gibt es ein Template, das im ABAP-Editor über den Menüpfad MUSTER • AUTHORITY_CHECK ausgewählt werden kann.
1.1.3 Rollen und Profilgenerator
Die Ausprägung von Berechtigungsobjekten zu Berechtigungen erfolgt über Profile. Früher hat man diese direkt angelegt (Transaktion SU02) und den Anwendern zugeordnet. Heute nutzt man stattdessen Rollen (Transaktion PFCG), die deutlich flexibler und einfacher zu handhaben sind. Die Berechtigungen werden technisch zwar weiterhin in Profilen gekapselt, aber über den in der PFCG integrierten Profilgenerator auf Knopfdruck im Hintergrund erstellt.
Profil SAP_ALL
Das bekannteste und auch heute noch häufig verwendete Profil ist sicherlich »SAP_ALL«. Es enthält alle im System vorhandenen Berechtigungsobjekte, wobei alle Felder mit * ausgeprägt sind. Werden eigene Berechtigungsobjekte angelegt, so kann »SAP_ALL« in der Transaktion SU21 durch Drücken des Buttons »SAP_ALL nachgenerieren« noch einmal erstellt werden, wobei die neuen Berechtigungsobjekte ergänzt und ebenfalls mit * ausgeprägt werden.
Das Profil »SAP_NEW« ist mittlerweile obsolet. Stattdessen lässt sich aber eine gleichnamige Rolle per ABAP-Report generieren (siehe SAP Note 1711620 »Role SAP_NEW replaces profile SAP_NEW«).
Aufbau eines Rollenkonzepts
Generell kann man folgende Typen von Rollen unterscheiden:
Sammelrolle
Sammelrollen dienen lediglich der Gruppierung von Einzelrollen und enthalten selbst keine Berechtigungen. Weitere Ausprägungen wie Menüs sind möglich, aber eher unüblich.
Einzelrolle
Einzelrollen enthalten in erster Linie die eigentlichen Berechtigungen.
Es hat sich weiterhin bewährt, zumindest für die Endanwender die Einzelrollen wie folgt funktional zu trennen:
Menürollen
Diese enthalten ausschließlich Menüelemente, im BW-Kontext also Links auf die zugeordneten Berichte.
Berechtigungsrollen
Sie enthalten die Standardberechtigungen.
Datenrollen
Diese enthalten die Datenberechtigungen (Analyseberechtigungen, siehe
Abschnitt 1.2
).
Menürollen vs. Portalrollen und BIP-Rollen
Mit der Nutzung des »SAP Enterprise Portals« oder der »SAP-BusinessObjects-Enterprise-Plattform« (BIP), die beide eigene Rollenkonzepte für den Zugriff auf Reports nutzen und als zentrale Einstiegspunkte für Endanwender dienen, haben die Menürollen im BW stark an Bedeutung verloren, zumal sich Endanwender im SAP BW, anders als im SAP ERP, selten an der SAP GUI anmelden. Oft kann daher komplett auf Menürollen verzichtet werden. Lediglich für den direkten Zugriff aus den Client-Tools (z.B. Analysis für Office) heraus spielen sie ggf. noch eine Rolle.
Für Endanwenderrollen ist diese Trennung deshalb sinnvoll, da sich mit wenigen, modularen Einzelrollen eine Vielzahl von Business-Sammelrollen definieren lässt. Im einfachsten Fall haben beispielsweise alle Systemnutzer rein technisch Zugriff auf jede Query im System (nur eine einzige Rolle für alle Endanwender mit vollem Lesezugriff auf alle Inhalte). Pro Fachbereich existiert eine Menürolle mit den Links auf die Berichte (je eine Rolle für FI, HR, CRM usw.). Zu guter Letzt existiert für jede Ausprägung einer Datenberechtigung eine weitere Rolle (eine mit Zugriff auf die Kostenstelle 1000, eine für Kostenstelle 2000, eine auf die 3000). Aus diesen Einzel- lassen sich nun per Sammelrollen beliebige Kombinationen bilden. Änderungen an gemeinsam genutzten Berechtigungen (z.B. S_RS_COMP) müssen nur an einer Stelle gepflegt werden. An Endanwender werden i.d.R. dann nur Sammelrollen vergeben.
Ob die Sammelrollen am Ende streng nach BW-Bereichen (entsprechend ERP-Modulen) oder aber nach Business-Prozessen und damit ggf. modulübergreifend aufgebaut werden, hängt von den jeweiligen Anforderungen ab. Beides lässt sich aber gut mit dem vorgestellten Konzept umsetzen.
Vererbung und Ableitung
In ERP-Systemen findet sich außerdem das Konzept der »abgeleiteten Rollen«. Dabei werden zunächst zentrale Objekte (typisches Beispiel ist der Buchungskreis) als Organisationsebenen festgelegt, auf denen die Berechtigungen aufbauen. Danach werden eine Template-Rolle und beliebig viele abgeleitete Rollen (= Kind-Rollen) angelegt (z.B. eine pro Buchungskreis). Letztere übernehmen alle Berechtigungen der Template-Rolle (Vererbung) und werden nur in den Organisationsebenen explizit ausgeprägt. Änderungen an anderen Objekten als den Organisationsebenen erfolgen immer nur an der Template-Rolle. Auf diese Weise müssen Anpassungen an ähnlichen Rollen ebenfalls nur einmal zentral vorgenommen werden.
Vererbung versus Sammelrollenkonzept
Das Konzept der Vererbung funktioniert im ERP sehr gut, da oft eine Vielzahl ähnlicher Rollen existiert, die sich nur in einer oder wenigen Ausprägungen unterscheiden (z.B. dem erwähnten Buchungskreis oder der Aktivität). Im SAP BW stößt man mit diesem Ansatz dagegen schnell an Grenzen, da man bei komplexeren Endanwender- oder Entwicklerrollen eine ganze Reihe von Berechtigungsfeldern als Organisationsebenen definieren müsste (Report »PFCG_ORGFIELD_CREATE«). Betrachten wir beispielsweise S_RS_COMP, so stellen wir fest, dass eigentlich jedes einzelne Berechtigungsfeld darin eine potenzielle Organisationsebene darstellt. Aus diesem Grund empfehlen wir diesen Ansatz i.d.R. nicht für SAP BW, sondern schlagen stattdessen vor, wie oben beschrieben, mit modularen Einzel- und Sammelrollen zu arbeiten. Technisch möglich ist die Nutzung der Vererbung aber auch im BW und wird gelegentlich auch von Kunden genutzt.
Arbeiten mit Rollen
Einstieg in das Arbeiten mit Rollen ist die Transaktion PFCG (»Rollenpflege«), siehe Abbildung 1.10.
Abbildung 1.10: Rollenpflege
Der technische Name einer Rolle kann aus bis zu dreißig Zeichen bestehen. Wie bei allen BW-Objekten ist eine sinnvolle Namenskonvention empfohlen. In der Praxis haben sich z.B. folgende Elemente als mögliche Bestandteile einer Namenskonvention bewährt.
System (z.B. Entwicklung, Produktion),
Typ der Rolle (Einzelrolle, Sammelrolle),
Benutzerkreis (z.B. Endanwender, Admin, Entwickler, Support),
Art der Rolle (z.B. Backend, Frontend, Menürolle, Datenrolle),
(Fach-)Bereich.
PSF_FI_CONTROLLER wäre dann beispielweise die Sammelrolle (S) für den Fachbereich (F) Controlling im Produktivsystem (P), PEF_FI_D_CONTROLLER_DE eine darin enthaltene Einzelrolle, die die zugehörigen Datenberechtigungen für Deutschland enthält.
Bei der Neuanlage von Rollen muss zunächst festgelegt werden, ob es sich um eine Sammel- oder eine Einzelrolle handelt. Während Sammelrollen eine eingeschränkte Anzahl von Reitern aufweisen (insbesondere keine Berechtigungen), haben wir bei Einzelrollen alle Optionen.
Im Tab Menü können wir Menüstrukturen definieren (siehe Abbildung 1.11). Für Endanwender sind das in erster Linie Links auf Berichte, die über den kleinen Pfeil rechts im Kontextmenü des Buttons Transaktion eingefügt werden. Alternativ können Sie Berichte beim Speichern im jeweiligen Berichtswerkzeug (z.B. Analysis for Office) direkt der Rolle hinzufügen, ein besonders für Poweruser gebräuchlicher Ansatz, wenn von ihnen erstellte Berichte verteilt werden sollen.
Abbildung 1.11: Tab »Menü« in der PFCG
Im ERP-Kontext werden gern auch Transaktionen über den Button Transaktion ins Menü eingebunden. Das liegt zum einen daran, dass im ERP auch Endanwender direkt mit Transaktionen arbeiten, und hat zum anderen den Vorteil, dass automatisch die zu einer Transaktion gehörigen Berechtigungsobjekte im Tab Berechtigungen mit angelegt werden (über die Transaktion SU24 können die zu einer Transaktion gehörigen Berechtigungsobjekte gepflegt werden). Im BW-Kontext ist dieses Vorgehen allerdings eher unüblich: Endanwender arbeiten i.d.R. nicht mit Transaktionen und melden sich nur in den wenigsten Fällen über die SAP GUI direkt am System an, und Administratoren bzw. Entwickler kennen ihre Transaktionen ohnehin. Zudem arbeitet das SAP BW mit relativ wenigen, dafür zentralen Transaktionen wie der RSA1 (»Data Warehousing Workbench«), aus der heraus die meisten Funktionen zugänglich sind, ohne die Transaktionen direkt aufrufen zu müssen. Auch in Bezug auf die Berechtigungsobjekte kommt das BW mit relativ wenigen Objekten aus, die von vielen Transaktionen in unterschiedlichen Ausprägungen genutzt werden. Die abgeleiteten Ausprägungen sind bei Auslieferung außerdem oft schlecht oder gar nicht gepflegt, und die Rollen im BW sind weit weniger standardisiert als im ERP.
Rollen-Download
Rollen lassen sich auch als Textdateien speichern und in andere Systeme importieren. Das soll keinen Transportmechanismus ersetzen, kann aber bisweilen praktisch sein, um Rollen z.B. zwischen unterschiedlichen Entwicklungssystemen einfach zu kopieren oder ein schnelles Backup zu erstellen. Die Funktion findet man im Menüpunkt Rolle • Download bzw. für mehrere Rollen unter Hilfsmittel • Massendownload.
Eigentliches Kernstück der PFCG ist der Profilgenerator, der über den Tab Berechtigungen erreichbar ist (Abbildung 1.12). Hier werden die Berechtigungsobjekte beliebig kombiniert und ausgeprägt. Wie eingangs erwähnt, wird technisch gesehen im Hintergrund ein Profil erzeugt und mit der Rolle verbunden, aber das muss uns an dieser Stelle nicht weiter interessieren.
Abbildung 1.12: Tab »Berechtigungen« in der PFCG
Wenn wir auf Berechtigungsdaten ändern klicken und noch kein Profil existiert (da es sich um eine neue Rolle handelt), erhalten wir eine Liste mit wählbaren Vorlagen. Im Gegensatz zu den ausgelieferten SAP-Rollen, die i.d.R. im BW-Bereich mehr oder weniger unbrauchbar sind, weil sie viel zu viele Berechtigungen enthalten, sind diese Vorlagen zwar besser, aber z.T. veraltet. Neueinsteiger können die Funktion aber nutzen, um ein erstes Verständnis für die Zusammenhänge zwischen Berechtigungsobjekten und Ausprägungen zu erlangen.
Dokumentation von Berechtigungsobjekten
Eine andere gute Hilfe bei der Wahl der Ausprägung von Berechtigungen ist die Dokumentation der Berechtigungsobjekte, die via SU21 (Abbildung 1.13) über den zugehörigen Button zugänglich ist.
Alternativ können wir die Dokumentation auch per Doppelklick auf das Berechtigungsobjekt im Profilgenerator starten. Leider sind nicht alle Objekte gleichermaßen gut dokumentiert, zu den zentralen Objekten finden sich aber oft Beispiele mit konkreten Ausprägungen.
Abbildung 1.13: Dokumentation zum Berechtigungsobjekt anzeigen
Abbildung 1.14: Profilgenerator
Im Profilgenerator (Abbildung 1.14) lassen sich neue Berechtigungsobjekte über den Button Auswahl einfügen. Im nächsten Screen erscheint eine nach Klassen geordnete Liste aller im System vorhandenen Berechtigungsobjekte mit einem i.d.R. sprechenden Namen (Abbildung 1.15, linke Seite). Durch das jeweilige Markieren des kleinen roten Minus-Icons vor den gewünschten Objekten können Sie mehrere Objekte sammeln (es erscheint dann vor jedem gewählten Objekt ein grünes Plus-Icon) und am Ende alle gemeinsam in die Rolle einfügen. Alternativ lassen sich über den Button Manuell neue Berechtigungsobjekte direkt eingeben (Abbildung 1.15, rechte Seite).
Abbildung 1.15: Optionen zum Einfügen von Berechtigungsobjekten
In beiden Varianten werden die Berechtigungsobjekte mit leeren Berechtigungsfeldern in die Rolle eingefügt (Abbildung 1.16). Wurden Berechtigungsobjekte hingegen über Menü-Transaktionen eingefügt, so sind diese i.d.R. bereits partiell ausgeprägt. Per Klick auf das Stift-Symbol vor jeder Zeile können die zugehörigen Werte gepflegt werden. Je nachdem, wie das Feld definiert wurde, bekommt man eine Liste erlaubter Werte oder ein Freitext-Range-Feld angeboten. Klickt man auf den kleinen Stern (*) vor der Zeile, so wird eine Vollberechtigung erzeugt.
Abbildung 1.16: Berechtigungsobjekte aufnehmen
Technische Namen anzeigen
Über den Menüeintrag Hilfsmittel • Technische Namen an können Sie sich die technischen Namen der Berechtigungsfelder und der ausgeprägten Werte anzeigen lassen.
Über Hilfsmittel • Einstellung lässt sich dies auch als Standardeinstellung festlegen. Ebenso kann man hier die Ansicht auf ALV (ALV-Tree verwenden) umstellen, was wir im Folgenden aus Platzgründen für einige der Screenshots in diesem Buch gemacht haben.
Speichert man Berechtigungen zum ersten Mal, so wird man nach einem technischen Namen für das automatisch generierte Profil gefragt. Wir empfehlen, den Vorschlagswert beizubehalten, da Sie nirgends mehr auf dieses Profil direkt zugreifen werden. Verlassen wir die Pflege, ohne zu sichern oder das Profil generiert zu haben (Abbildung 1.14 ), so erhalten wir einen Warnhinweis. Wir müssen das Profil immer explizit generieren, damit jegliche Änderungen auch wirksam werden. Auf den Button Trace werden wir in Abschnitt 1.1.4 noch eingehen.
Zentrale Berechtigungsobjekte im SAP BW
Da wir nicht auf alle BW-Berechtigungsobjekte im Detail eingehen können, wollen wir zumindest kurz die für den Endanwender wichtigsten Objekte ansehen:
S_RS_COMP und S_RS_COMP1 Objekte für den Queryzugriff. S_RS_COMP1 ist eine später eingeführte Erweiterung, die es erlaubt, auch den Queryersteller zu berechtigen, und die aus Gründen der Abwärtskompatibilität als eigenes Objekt ausgeliefert wurde.
S_RS_AO und S_RS_ZEN Berechtigen den Zugriff auf Analysis-Office-Dokumente und Design-Studio-Applikationen.
S_RS_AUTH Über das Berechtigungsobjekt S_RS_AUTH lassen sich Analyseberechtigungen (siehe
Abschnitt 1.2
) mit Rollen verknüpfen.
S_RS_FOLD Damit lässt sich die Auswahl von Berichten für den Endanwender über die Infoarea-Hierarchie verbergen, es bleiben die Optionen »Favoriten« und »Rollen«.
S_RFC (Berechtigungsklasse AAAB) Jedes Frontend nutzt eine Reihe von RFC-Aufrufen zur Kommunikation mit dem Backend. Entsprechend müssen diese berechtigt sein.
Eine Übersicht der wichtigsten Berechtigungsobjekte für BW und BW/4HANA finden Sie im Anhang.
1-2: Eine Endanwender-Rolle erstellen
Erstellen Sie für die nachfolgenden Beispiele eine einfache Endanwender-Reportingrolle »YEPM_REPORTING_USER«.
Diese soll folgende Berechtigungen umfassen:
Ausführen von Queries im Namensraum »YEMP*«,Erstellen und Ausführen von Analysis for Office Workbooks,S_RFC, das wir der Einfachheit halber mit * ausprägen (für Analysis for Office stehen die Funktionsgruppen »SYST«, »RSAO_CORE« und »RSBOLAP_BICS*« zur Verfügung).Die neu erstellte Rolle weisen Sie nun dem in Übung 1-1 erstellten Anwender »USER_1« zu.
Eine typische Key-User-Berechtigung
Key-User dürfen häufig selbst temporäre Queries im Produktivsystem anlegen. Damit diese klar von den transportierten Queries abgrenzbar sind, wird i.d.R. ein eigener Namensraum verwendet, in unserem Beispiel »ZTEMP«. Dafür verwenden wir zwei unterschiedliche Ausprägungen des Objektes S_RS_COMP, die beide in derselben Rolle enthalten sein können. Außerdem soll unser Key-User nur seine eigenen temporären Queries ändern dürfen. Dafür nutzen wir eine Besonderheit von S_RS_COMP1, indem wir das Feld RSZOWNER (Besitzer) mit $USER ausprägen. Der Wert entspricht dem jeweils aktuell angemeldeten User (Abbildung 1.17). Soll der Key-User die Queries in Workbooks einbinden und diese über Menürollen anderen Benutzern zur Verfügung stellen können, so benötigt er zusätzlich die Berechtigungsobjekte S_RS_AO und S_USER_AGR. Soll er auch Objekte wieder aus Menürollen entfernen können, benötigt er zusätzlich das Objekt S_USER_TCD mit der Ausprägung SAP_BW_QUERY (siehe SAP-Hinweis 1979932).
Abbildung 1.17: Beispiel einer Key-User-Berechtigung
1.1.4 Fehlersuche bei Standardberechtigungen
Berechtigungstrace mit der ST01
Zur Überprüfung notwendiger Berechtigungen lässt sich mithilfe der Transaktion ST01 (»Systemtrace«) ein Berechtigungstrace aufzeichnen (Abbildung 1.18). Dazu setzen wir den Haken bei Berechtigungsprüfung und einen Filter auf einen bestimmten Benutzer, damit nur für diesen ein Trace aufgezeichnet wird. Da ein Trace immer Last auf dem System erzeugt und i.d.R. im Produktivsystem ausgeführt wird, sollten die Einschränkungen so eng wie möglich gesetzt und der Trace sollte nach getaner Arbeit auch wieder ausgeschaltet werden.
Abbildung 1.18: Einen Systemtrace mit der ST01 anlegen
Wir schalten aber erst einmal den Trace an, und die Aufzeichnung beginnt. In unserem oben angelegten Beispiel führen wir jetzt die Query YEPM_CP_SO_Q001 mit dem Anwender USER_1 in Analysis for Office aus. Nachdem wir bzw. der zu prüfende Anwender mit der Aktion fertig ist, schalten wir den Trace wieder aus und sehen uns das Ergebnis an, indem wir den Button Auswertung wählen.
Abbildung 1.19: Einen Systemtrace auswerten
Es öffnet sich ein Fenster (Abbildung 1.19), in das wir den Benutzer sowie ein passendes Zeitfenster eingeben. Wir lassen uns durch einen Klick auf den Button »Auswertung starten« (bzw. »F8«) die Ergebnisse des Traces anzeigen (Abbildung 1.20).
Abbildung 1.20: Ergebnisprotokoll eines Systemtrace
Übergehen wir an dieser Stelle die Prüfung auf das Objekt S_RS_AUTH (dazu mehr im nächsten Kapitel) und auch die Prüfung auf S_RS_RSTT (die mit dem Trace-Tool selbst zu tun hat) und sehen uns dafür die anderen Objekte genauer an. Wir stellen fest, dass alle anderen Prüfungen mit Returncode »0« (RC = 0
