Zeit der Veränderungen
Steigende Zinsen, neue regulatorische Anforderungen, Probleme in den Lieferketten – mehr denn je stehen Unternehmen vor der Herausforderung die Auswirkungen neuer Situationen rasch einschätzen und bei Bedarf entsprechende Maßnahmen einleiten zu können. Vor diesem Hintergrund wird die IT-Infrastruktur vielerorts neu gedacht bzw. werden die Anforderungen neu definiert. Mehr Flexibilität, schnellere Zugriffszeiten, geringere Abstimmungsaufwände und Abhängigkeiten stehen dabei im Vordergrund. Neben konzeptionellen Überlegungen (siehe dazu auch den Blog-Eintrag zum Thema „Data Mesh“) werden dabei auch neue Datenmodellierungs- und Reporting-Werkzeuge, wie bspw. Microsofts Data Factory, Analysis Services und Power BI evaluiert.
Bei der Auswahl neuer Werkzeuge stellt sich schnell die Frage, ob und inwieweit bestehende Datenmodelle und Berechtigungslogiken integriert werden können. In der Regel wurden darin bereits viel Geld, Zeit und Nerven investiert. Einen kompletten Neuaufbau möchte man deshalb vermeiden.
Der heutige Blog-Eintrag widmet sich dem Thema „Berechtigungen in Power BI – im Zusammenspiel mit SAP BW“. Zunächst werden dabei die wichtigsten Elemente des Power BI Berechtigungskonzepts skizziert. Anschließend wird eine Möglichkeit aufgezeigt, existierende BW-Analyse-Berechtigungen dynamisch in Power BI zu übertragen – um eine Zeit- und Kostenaufwändige Redefinition zu vermeiden.
Das Berechtigungskonzept von Power BI
In Power BI lässt sich, ähnlich zu SAP BW, zwischen Funktions- und Datenberechtigungen unterscheiden. Funktionsberechtigungen legen dabei die Objekte (Queries, Datentöpfe, etc.) fest, auf die ein Anwender berechtigt ist. Datenberechtigungen schränken hingegen (entsprechend der betrieblichen Funktion eines Anwenders) die darzustellende Wertemenge ein.
In Power BI werden die zu berechtigenden Objekte „Artefakte“ genannt. Die wichtigsten sind: Datasets, Berichte, Arbeitsbereiche (Workspaces), Dashboards und Apps. Für jedes Element können die berechtigten User und der Funktionsumfang (bspw. im Hinblick auf Lesen/Bearbeiten) individuell festgelegt werden. Die Festlegung kann allerdings auch auf globaler Ebene erfolgen, bspw. über Arbeitsbereiche. Die Berechtigungen werden dann auf die darunterliegenden Objekte vererbt.
Die Zuordnung der Funktionsberechtigungen setzt somit zum einen eine genaue Kenntnis über das Beziehungsgefüge zwischen einzelnen Artefakten voraus. Zum anderen sind mit jedem Artefakt unterschiedliche Funktionen & berechtigungsbezogene Einstellungsmöglichkeiten verbunden. Die folgende Tabelle stellte diese Sachverhalte in einer Übersicht dar.
Artefakt
Arbeitsbereiche
Inhaltliche Beschreibung
Container für die Zusammenfassung logisch zusammengehöriger Elemente, beginnend bei den Datenquellen (Datasets) bis hin zu den Berichten, Dashboards und Apps. Bündeln die anderen Artefakten in einem gemeinsamen Bereich. Grob Vergleichbar mit einer Infoarea in SAP BW.
Beziehung zu anderen Artefakten
- Kann N andere Artefakte beinhalten
Berechtigungseinstellung
Auf dieser Ebene kann den Azure Active Directory-Usern (oder User-Gruppen) eine Arbeitsbereichsrolle zugeordnet werden. Diese sind bereits vordefiniert und umfassen: Administratoren, Mitglieder, Mitwirkende und Leser. Die Rollenzuordnung wirkt sich unmittelbar auf die Erstellungs-, Freigabe und Änderungsberechtigung von Datasets, Berichten, Dashboards und Apps aus.
Datasets
Container für ein oder mehrere Datenquellen. Die Daten können dabei sowohl physisch als auch virtuell vorliegen – je nach Zugriffsart (Import oder Live-Connection). Stellen die Basis für Berichte dar.
- Gehört 1:N Arbeits-bereichen an
- Kann in 0:N Berichten, Dashboards und Apps verwendet werden
Die Berechtigungen für Datasets können auf zwei Wegen vergeben werden: über die Zuweisung einer Arbeitsbereichsrolle (auf Arbeitsbereichsebene) oder auf Ebene des jeweiligen Datasets. Die Berechtigungen beziehen sich dabei auf die Änderung, die Freigabe und die Inhaltserstellung auf Basis des Datasets. Im Fall der Rollenzuweisung ergeben sich die konkreten Berechtigungen implizit aus der Rolle (rollenspezifische Abstufungen). Bei der Direktzuweisung eines Users, kann der Berechtigungsumfang dagegen individuell festgelegt werden.
Berichte
Tabellarische und/oder grafische Darstellung der Inhalte eines Datasets. Können sowohl über Power BI Desktop, als auch über Power BI Service (Web) angelegt und modifiziert werden. Ermöglicht Endanwendern Self-Service-Funktionalität.
- Gehört 1 Arbeitsbereich an
- Basiert auf 1 Dataset
- Kann in 0:N Dashboards und Apps desselben Arbeitsbereichs verwendet werden
Ähnlich wie bei Datasets lassen sich die Berechtigungen zum Aufruf und Erstellung von Berichten auf 2 Wegen vergeben. Über die Zuordnung einer Arbeitsbereichsrolle oder der Direktzuordnung eines Users zu einem Bericht. Die Berechtigungen können dabei zum einen die Freigabe des Berichts umfassen (Erteilung Leseberechtigung für andere User), zum anderen die Berechtigung für die Inhaltserstellung (Build-Option). Dies berechtigt andere User eigene Berichte auf Basis des zugrunde liegenden Datasets zu bauen.
Dashboards
Zusammenfassung der Inhalte aus unterschiedlichen Berichten und Datasets. Die Einstiegsseite kann beliebig viele Kacheln & Widgets beinhalten, über die eine Detailnavigation erfolgen kann.
- Gehört 1 Arbeitsbereich an
- Bezieht die Daten aus 0:N Berichten und Datasets
- Kann in 0:N Apps desselben Arbeits-bereichs verwendet werden
Im Kontrast zu den anderen Artefakten (Datasets, Berichte und Dashboards), sind Apps mit einem zus. Berechtigungslayer ausgestattet. Berechtigungen können zunächst wie bei den anderen Artefakten über die Arbeitsbereichsrolle geerbt oder direkt zugewiesen werden. Die Direktzuweisung bietet allerdings zus. Funktionen. So lassen sich an dieser Stelle individuelle Benutzergruppen definieren. Hierin kann der Zugriff die zugrunde liegenden Berichte & Dashboards Benutzergruppen-spezifisch eingestellt werden. Aufgrund dieser Eigenschaft ist zu empfehlen Dashboards und Berichte immer über Apps zu verteilen.
Apps
Zusammenfassung der Inhalte aus unterschiedlichen Berichten und Datasets. Die Einstiegsseite kann beliebig viele Kacheln & Widgets beinhalten, über die eine Detailnavigation erfolgen kann.
- Werden auf Basis 1 Arbeitsbereich angelegt
- Beziehen die Daten aus 0:N Berichten, Datasets und Dashboards desselben Arbeitsbereichs ein
Im Kontrast zu den anderen Artefakten (Datasets, Berichte und Dashboards), sind Apps mit einem zus. Berechtigungslayer ausgestattet. Berechtigungen können zunächst wie bei den anderen Artefakten über die Arbeitsbereichsrolle geerbt oder direkt zugewiesen werden. Die Direktzuweisung bietet allerdings zus. Funktionen. So lassen sich an dieser Stelle individuelle Benutzergruppen definieren. Hierin kann der Zugriff die zugrunde liegenden Berichte & Dashboards Benutzergruppen-spezifisch eingestellt werden. Aufgrund dieser Eigenschaft ist zu empfehlen Dashboards und Berichte immer über Apps zu verteilen.
Nachdem nun ein Überblick über die funktionalen Berechtigungen verschafft worden ist, werden wir uns im folgenden Abschnitt den Datenberechtigungen widmen. Ferner wird die dynamische Integration von SAP Analyse-Berechtigungen in Power-BI beleuchtet.
Abbildung der Datenberechtigungen über Row-Level-Security (RLS)
In Power BI werden Datenberechtigungen über den sog. „Row-Level-Security“ Ansatz abgebildet. Er ermöglicht die Definition individueller Datenrollen, in denen über DAX-Anweisungen die berechtigten Datenmenge eingeschränkt werden kann. Die Einschränkungen können sich dabei auf sämtliche Merkmals-Felder der zugrunde liegenden Datenquellen beziehen. Auch berechnete Tabellen, die eine View auf eine andere Tabelle darstellen, können als Berechtigungsgrundlage verwendet werden – dies ist insb. für das sog. dynamisches RLS interessant (dazu später mehr).
Die Folgende Abbildung zeigt ein einfaches Beispiel für eine Rollendefinition zur Einschränkung der Datenmenge:
Das Berichtsmodell besteht in diesem Fall lediglich aus einer Datenquelle (Personalbestand). Über einen Dax-Filter werden die Merkmale „Geschäftseinheit“ und „Land“ auf die zu berechtigenden Ausprägungen eingeschränkt.
Während die Definition der Rollen innerhalb von „Power BI Desktop“ erfolgt, wird die Benutzer- oder Benutzergruppenzuordnung in „Power BI Service“ vorgenommen. Das veröffentlichte Dataset verfügt dazu über die Option „Sicherheit auf Zeilenebene“. Hier können die entsprechenden User zugeordnet werden:
Ohne eine entsprechende Zuordnung wird den Usern mit Leseberechtigung eine Fehlermeldung angezeigt.
Achtung: Die Sicherheit auf Zeilenebene greift nicht, wenn den Benutzern eine der o.g. Arbeitsbereichsrollen (Administrator, Mitglied oder Mitwirkender) zugeordnet ist. Die Vergabe dieser Rollen sollte deshalb mit viel Bedacht und nur für Power-User durchgeführt werden.
Statisches vs. Dynamisches Row Level Security
In dem eingangs gezeigten Beispiel wurde RLS nach dem statischen Verfahren abgebildet. Dies sollte in der Praxis aus folgenden Gründen vermieden werden:
- Hoher Umsetzungs- und Pflegeaufwand: bestehende Analyseberechtigungen (in SAP BW) müssten manuell nachgebaut werden. Je nach Anzahl der berechtigungsrelevanten Objekte und zu berechtigenden Merkmalsausprägungen, wird die Pflege über DAX-Formeln schnell unübersichtlich und schwer handelbar.
- Die Rollen werden je Power BI- Bericht definiert. Sie lassen sich weder global (d.h. Berichtsübergreifend) pflegen noch transportieren.
Aufgrund dieser Einschränkungen empfiehlt es sich Berechtigungen über den dynamischen RLS-Ansatz abzubilden.
Dynamisches RLS zeichnet sich dadurch aus, dass die berechtigten Werte je Benutzer in einer eigenen Tabelle vorgehalten werden. Über die DAX-Funktion „USERPRINCIPALNAME“ wird bei Aufruf eines Berichts der User bestimmt und die Daten entsprechend der Berechtigungstabelle gefiltert. Dies bietet den großen Vorteil, dass sich der Pflegeaufwand innerhalb der Datenrollen auf wenige Anweisungen reduziert:
Die Berechtigungstabelle wird dabei über „Beziehungen“ in eine Verbindung zur Datentabelle (hier „Personalbestand“) gesetzt. Die Filterung der Berechtigungstabelle bewirkt somit automatisch eine entsprechende Filterung der Daten. Je nach Komplexität des Datenmodells, ist allerdings die Anlage zusätzliche Berechtigungstabellen notwendig. In der Regel werden je berechtigungsrelevanten Merkmal 3 weitere Tabellen benötigt – die allerdings relativ schnell innerhalb von Power BI Desktop oder Analysis Services angelegt werden können. Ein konkretes Beispiel wird im folgenden Abschnitt beschrieben.
Beispielhafte Umsetzung der Integration von SAP-BW-Analyseberechtigungen in Power BI über dynamisches RLS
Die Ausgangsbasis des Beispiels stellt ein vereinfachtes BW-Datenmodell dar. Dieses ist in der folgenden Abbildung (links) skizziert. Es besteht aus einem Composite Provider der Personalbestandsdaten beinhaltet (Köpfe, FTE, Mitarbeiter, Org.einheiten, etc.). Die Merkmale „Land“ und „Geschäftseinheit“ sind dabei als berechtigungsrelevant gekennzeichnet. Die Berechtigungen werden über Funktions- und Datenrollen verwaltet, wobei die Datenrolle einen Verweis auf die Analyseberechtigungen enthält. Hier sind die zulässigen Ausprägungen der beiden Merkmale hinterlegt.
Zur Umsetzung des dynamischen RLS-Ansatzes in Power BI bedarf es an dieser Stelle noch einer Tabelle, die für jeden Benutzer und berechtigungsrelevantes Merkmal die berechtigten Werte enthält. Diese Auflistung lässt sich über ein entsprechendes ABAP-Programm generieren.
Auf dieser Basis kann als Nächstes in Power BI Desktop das Power BI Modell angelegt werden. Hierbei werden, je nach Verbindungsvariante (Import/Direct Query), entweder die Metadaten oder der komplette Tabelleninhalt in das Modell geladen (für Näheres siehe dazu auch folgenden Blog-Eintrag). In diesem Zusammenhang ist allerdings zu beachten, dass in Power BI nicht bei jeder Verbindungsvariante Tabellen-Beziehungen und Rollen angelegt werden können. Dazu nachfolgend ein Überblick:
Variante
Dynamisches RLS unterstützt
SAP BW -> Power BI Desktop (Direct Query)
SAP BW -> Power BI Desktop (Import)
SAP BW -> Microsoft SQL Database -> Power BI Desktop (Import)
SAP BW -> Microsoft SQL Database -> Power BI Desktop (Live)
SAP BW -> Microsoft SQL Database -> MS Analysis Services (Import)
SAP BW -> Microsoft SQL Database -> MS Analysis Services (Live)
Wurde ein passende Verbindungsvariante gewählt und die BW-Tabellen in das Modell geladen, müssen als nächstes für jedes berechtigungsrelevante Merkmal „Security“-Tabelle angelegt werden. Über diese werden später bei Aufruf der Berichte die Daten gefiltert. Die folgende Abbildung stellt dies exemplarisch dar.
Nach Anlage der Tabellen sind sie, wie oben gezeigt, in Beziehung zueinander zu setzen. Die Pfeilrichtung gibt dabei die Filterrichtung vor, die bei Row-Level-Security angewendet wird. Sobald die Beziehungen angelegt worden sind, kann die Anlage der Power BI Rolle erfolgen. Erst damit wird die dynamische Sicherheit auf Zeileneben aktiv. Die Vorgehensweise für die Rollenanlage wurde bereits in den beiden vorangegangenen Abschnitten beschrieben. Im vorliegenden Beispielfall ist bei den „Security-User“-Tabellen die DAX-Funktion „USERPRINCIPALNAME“ einzutragen.
Die in Power BI Desktop notwendigen Schritte sind damit abgeschlossen. Optional kann an dieser Stelle noch die Berichtsdefinition erfolgen (alternativ in Power BI Service). Zur Aktivierung der Berechtigungen bzw. des dynamischen RLS-Verfahrens bedarf es nun noch der Rollenzuordnung zu den einzelnen Benutzern/Benutzergruppen. Dies erfolgt im Power BI Service. Unterhalb des veröffentlichten Datasets gibt es dazu die Option „Sicherheit“. Hier sind die entsprechenden Benutzerzuordnungen vorzunehmen.
Zusammenfassung und Ausblick
Im vorliegenden Blog-Eintrag wurde das Berechtigungskonzept von Power BI vorgestellt. Dabei wurde aufgezeigt, das zwischen funktionalen und datenbezogenen Berechtigungen unterschieden werden kann. Im Hinblick auf die funktionalen Berechtigungen wurden die zugrunde liegende Artefakte (Arbeitsbereiche, Datasets, Berichte, Dashboards, Apps) erläutert sowie deren Beziehungsgefüge dargestellt. Verständnis von dem Beziehungsgefüge ist die Voraussetzung, um Artefakt-inhärente Vererbungslogiken zu verstehen. Weiterhin wurde in diesem Zusammenhang auf die vordefinierten Arbeitsbereichsrollen (Administrator, Mitglied, Mitwirkender und Leser) eingegangen, deren Vergabe große Auswirkungen auf die Datenberechtigungen hat – weshalb an dieser Stelle mit viel Bedacht vorgegangen werden muss.
Im Hinblick auf Datenberechtigungen wurde das „Row-Level-Security“ (RLS)-Konzept von Power BI vorgestellt. Hierbei wurden die Unterschiede zwischen statischem und dynamischen RLS herausgearbeitet und die Vorzüge des letztgenannten Verfahrens beschrieben. Anhand eines Anwendungsbeispiels wurde schließlich gezeigt, dass eine automatische Überführung von SAP-BW-Analyseberechtigungen in Power-BI möglich ist und der manuelle Nachbau von Berechtigungslogiken somit vermieden werden kann.
Ob das vorgestellte Konzept zur Abbildung von SAP-BW-Berechtigungen für ein Unternehmen geeignet ist, hängt nun nur noch von der Frage ab, ob die Definition der Berechtigungen innerhalb von Power BI Desktop die Anforderungen im Hinblick auf die Wiederverwendbarkeit erfüllen. Wie angesprochen gibt es die die Restriktion, dass Berechtigungen nicht transportiert oder übergreifend verwendet werden können. Die beschriebene Vorgehensweise müsste somit von Modell zu Modell wiederholt werden, sofern sich die fachlichen Anforderungen nicht in einem Modell abbilden lassen und mehrere Berichte anzulegen sind.
Das Problem lässt sich allerdings lösen, in dem die Definition des Modells und der Berechtigungen nicht innerhalb von Power BI Desktop, sondern in Azure Analysis Services erfolgt. Analysis Services-Datenmodelle können in Power BI als eigenständige Datenquelle konsumiert werden. Ein einmal gebautes Berechtigungsmodell kann somit von beliebig vielen Power BI Berichten wiederverwendet werden. Falls Sie sich näher mit dem Thema beschäftigen möchten, sagen Sie Bescheid. Wir beraten Sie dazu gern.
