Berechtigungen in Power BI: Teil 1 Access Control

Publiziert von

Der Zugriff auf die Power BI Artefakte – das sind Dashboards, Reports, Datasets, App-Workspaces („Gruppen“) und Apps („Pakete“) – wird unter dem Begriff Access Control zusammengefaßt.

In Power BI stehen 3 Methoden für Access Control zur Verfügung. Die Auswahl der für das eigene Unternehmen passenden Option ist entscheidend für den reibungslosen Betrieb der produktiven Power BI Anwendung und für die Einhaltung von firmenspezifischen Compliance Regeln.

Szenario

Wir verwenden einen sehr simplen Showcase auf Basis des (leicht adaptierten) Financial Sample Datasets mit den folgenden beiden Rollen:

  • Power User = „Robert Lochner“
  • End User = „Linearis Support“

Die folgenden Kapitel sind in je einen Abschnitt für die Power User Perspektive und für die End User Perspektive geteilt. Weiters verwenden wir hauptsächlich die englischsprachigen Bezeichnungen, da diese allgemein gültiger sind.

Lizenzbedingungen

Bitte beachten Sie, daß für sämtliche hier beschriebenen Instrumente entweder  (1) sowohl der Power User als auch auch der End User eine Power BI Pro Subscription benötigen oder (2) die Anwendung in einer Power BI Premium Umgebung deployed sein muß. Access Control mit einem Free Account ist nicht (mehr) möglich.

User mit verschiedenen Domains, die aber zum gleichen Office365-Tenant gehören, werden in Power BI als Personen innerhalb der eigenen Organisation angesehen.

Besondere (nicht behandelte) Fälle

Auf Besonderheiten bei der Access Control von Personen außerhalb der eigenen Organisation gehen wir in diesem Beitrag ebenso wenig ein wie auf Besonderheiten beim Zugriff auf ein on-premise Tabular Model und beim Zugriff mittels Power BI Embedded. Auf Besonderheiten in Zusammenhang mit der Publish to Web Option gehen wir ebenfalls hier nicht ein.

1. Access Control über die Sharing-Funktion

Die Sharing-Funktion ist die offensichtlichste Methode, um Dashboards zu teilen. Allerdings handelt es sich um eine adhoc Funktion, für den Betrieb produktiver (größerer) Dashboard-Infrastrukturen mit größeren Benutzerzahlen eignet sich diese Methode nicht. Die Sharing-Funktion wird im folgenden anhand einer Anwendung im „My Workspace“ beschrieben, diese steht aber genauso bei Anwendungen in „App-Workspaces“ als zusätzliche adhoc Verteilungsfunktion zur Verfügung. Für den Enduser ist der Unterschied nur anhand der Besitzer-Information zu sehen, im ersten Fall ist das die Person und im zweiten Fall der App-Workspace.

1a. Power User Perspektive

Der Power User erstellt in Power BI Desktop ein Datenmodell samt Visualisierungen (= Reports) und startet mit dem Button „Veröffentlichen“ das Deployment der Anwendung auf PowerBI.com auf den eigenen „My Workspace“ und setzt damit den ersten Schritt von der Desktop-Anwendung zur Multi-User Applikation:

Kurze Zeit später scheint die neue Applikation auch auf Power BI.com im Abschnitt „My Workspace“ des Power Users auf:

Jetzt muß aus zumindest einem Visual des Reports (aus PBI Desktop) ein Dashboard (auf PowerBI.com) erstellt werden, da die Sharing-Funktion nur in Dashboards (Link „Freigeben“) zur Verfügung steht:

Hier kann jetzt sehr simpel über die Eingabe einer E-Mail Adresse ein User – aus dem eigenen Unternehmen oder von einem anderen – zum Dashboard eingeladen werden. Um einen viralen Effekt für Unternehmensdaten zu verhindern, empfehlen wir dringend, die Option „Empfängern das Freigeben des Dashboards erlauben“ jedenfalls zu deaktivieren. Anstelle des Benachrichtungsmails kann auch der Dashboard-Link kopiert und über andere Kanäle (bspw. Chat) an den Empfänger geschickt werden. Wie eingangs erwähnt, muß auch der Empfänger („End User“) nicht nur über einen Power BI Account verfügen sondern auch über eine Power BI Pro Subscription.

Nach der erfolgten Freigabe kann über den den Reiter Zugriff überprüft werden, wer bereits mit welchen Rechten zum Dashboard berechtigt wurde:

Beachten Sie bitte, daß jeder User in seinem „My Workspace“ immer der Besitzer ist, und zwar der einzige. Das Besitzer-Recht kann auch nicht übertragen werden kann (siehe die fehlenden „3 Punkte“ beim „Besitzer“ im Screenshot oben), beim Austritt eines Mitarbeiters aus dem Unternehmen muß der „My Workspace“ gelöscht werden. Aus diesem Grund dürfen keine Enterprise Anwendungen im „My Workspace“ eines bestimmten User betrieben werden.

Der User verfügt daher in seinem „My Workspace“ immer über sämtliche Rechte für alle darin befindlichen Anwendungen und sieht auch immer sämtliche Daten, da eine eventuelle Row-Level-Security für den Besitzer nicht greift. Weiters folgt auch, daß ein User eine Anwendung aus PBI Desktop niemals in den „My Workspace“ eines anderen Users deployen kann, da er dort nicht das Besitzer-Recht haben kann.

1b. End User Perspektive

Der End User – dieser wurde in unserer Demo bei PowerBI.com neu registriert – hat seinen eigenen „My Workspace“, dieser ist mangels eigener Aktivitäten in Power BI noch komplett leer:

Das freigegebene Dashboard ist für den End User im Bereich Für mich freigegeben zu finden. Die Dashboards – in diesem Fall nur eines – können in der mittleren Pane nach Besitzer (= Freigeber) gefiltert werden. Das Dashboard kann durch den End User weder bearbeitet noch gelöscht werden, das Delete-Symbol im Bereich Aktionen dient lediglich zur End-User-seitigen Aufhebung der Mitgliedschaft an diesem Dashboard:

Durch Klick auf den Balken wird das Dashboard geöffnet, entsprechend der Freigabe durch den Power User fehlt hier die Option zum Re-Sharing des Dashboards (Verhinderung eines „viralen Effekts“):

Durch Klick auf ein Dashboard Visual – wie in Power BI üblich – gelangt der End User in den zugrundeliegenden Report. Auch hier sind die eingeschränkten Access Rights beispielsweise im Menü Datei zu sehen (und an der deaktivierten „Bericht Bearbeiten“-Funktion):

Beachten Sie bitte, daß ein eingeladener User immer nur Leserechte auf das Dashboard und den/die dahinterliegenden Reports bekommen kann. Der End User kann auch keine Visuals aus dem Report weder an dieses noch an eigene Dashboards „Pinnen„, da hiefür kein Recht besteht. Der Zugriff auf das zugrundeliegende Dataset und damit beispielsweise auf die Möglichkeit, eine Datenaktualisierung anzustoßen, besteht ebenfalls nicht.

2. Access Control über „App-Workspaces“-Mitgliedschaften

Power BI „App-Workspaces“ wurden im Mai 2017 eingeführt und lösen die „Groups“ schrittweise ab. Diese dienen zur organisatorischen Loslösung von Power BI Anwendungen von einzelnen Usern (bzw. deren „My Workspace“) sowie zur – häufig abteilungsweisen – organisatorischen Strukturierung und Berechtigung der Power User. Zur Berechtigung der End User werden App-Workspaces indirekt verwendet, sie bilden nämlich die Basis für die unter Punkt 3 vorgestellten „Apps“.

Heute sind die App-Workspaces noch 1:1 mit Office365 Groups verbunden, sodaß hier besonders darauf geachtet werden muß, daß die dort aufgebauten Strukturen nicht durch Power BI konterkariert werden. Diese Verbindung soll laut Roadmap aber demnächst aufgehoben werden.

1a. Power User Perspektive

Die Erstellung eines App-Workspace erfolgt sehr einfach:

Wichtig sind die beiden Optionen:

  • Öffentlich heißt, daß alle Mitglieder der Gruppe – diese kann aus Office365 stammen und Mitglieder zugewiesen bekommen haben – Zugriff auf die Dashboards usw. erhalten. Privat heißt, daß die Mitglieder in Power BI aktiv erfasst (und gepflegt) werden müssen. Diese Einstellung kann später nicht mehr geändert werden.
  • Können bearbeiten und Können nur anzeigen … das erklärt sich selbst.

Anschließend werden die Mitglieder durch Eingabe der E-Mail Adressen hinzugefügt, externe Mail-Adressen können hier standardmäßig nicht berechtigt werden (dies kann aber über die Office365 Settings der Gruppe gelockert werden, siehe dazu unten):

Nach dem Erzeugen des App-Arbeitsbereichs kann dieser über den Befehl Arbeitsbereich bearbeiten administriert werden und – ganz wichtig – die Administrator-Rolle(n) festgelegt werden. Es muß zumindest einen Administrator geben, es können aber auch mehrere sein. Alle anderen Benutzer sind automatisch Mitglied, es gibt also nur zwei Rollen auf Ebene der App-Workspaces. Mit dieser Funktion kann also bei personellem und/oder organisatorischem Wechsel die Admin-Rolle übertragen werden, die Dashboards stecken dann nicht im „My Workspace“ eines ausgetretenen früheren Mitarbeiters fest …

Nach der Anlage des neuen App-Workspace mit den gewünschten Zugriffsberechtigungen wird das Datenmodell aus PBI Desktop vom Power User neuerlich deployed, dieses Mal aber nicht in den „My Workspace“ sondern in den soeben angelegten „DEMO App-Arbeitsbereich„:

Beachten Sie bitte, daß ein Benutzer in der Administrator-Rolle immer sämtliche Daten sieht, da eine eventuelle Row-Level-Security für den Administrator (ebenso wie für den Besitzer beim „My Workspace“) nicht greift.

1b. End User Perspektive

Es braucht jetzt kein „Sharing“ mehr, alle im App-Workspace berechtigten User erhalten jetzt sofort Zugriff auf sämtliche Dashboards und Reports über die „normale Navigation„. Je nach Konfiguration (siehe oben) kann damit ein Bearbeitungsrecht für die Dashboards und Reports verbunden sein (allerdings nur für alle „Mitglieder“ oder gar keinen, eine Differenzierung pro User ist nicht möglich) bis hin zum Zugriffsrecht auf das Dataset für weitere Administratoren.

Hat ein End User nicht die Rolle Administrator sondern Mitglied, dann scheint der App-Workspace zwar in der Deployment-Liste von PBI Desktop auf, das Deployment selbst ist dann aber nicht möglich:

Beachten Sie bitte, daß sobald der Power User Änderungen am Datenmodell und/oder den Visualisierungen vornimmt, diese mit der Änderung / mit dem neuerlichen Deployment sofort für alle berechtigten End User verfügbar sind. Eventuelle Fehler oder ungetestete Neuerungen schlagen damit sofort auf alle Mitglieder des App-Workspace durch. Daher sollte diese Funktion für die Berechtigung der Power User, nicht aber für die Berechtigung der End User genutzt werden.

Leider hat derzeit jeder User das Recht zur Anlage von App-Workspaces, dieses Recht kann derzeit nicht auf bestimmte User eines Unternehmens beschränkt werden.

Exkurs: Power BI App-Workspaces und Office365 Groups

Laut Roadmap soll dies zwar demnächst geändert werden, aber heute sind App-Workspaces in Power BI gleichzeitig auch Office365 Groups. Und auch umgekehrt: bereits bestehende Office365 Groups werden in Power BI – entsprechend der Mitgliedschaft eines Users – automatisch in Power BI als App-Workspaces übernommen. Das wird in manchen Fällen nützlich sein, in vielen aber störend, da hier rasch zu viele Anforderungen auf einmal erfüllt werden sollen.

Der Konnex wird auch in Power BI etwa 30 Minuten nach der Anlage eines App-Workspaces sichtbar, da jeder App-Workspace auch einen Kalender, ein OneDrive for Business Verzeichnis usw. erhält und die entsprechenden Zugriffslinks auch in Power BI angezeigt werden:

Da derzeit jeder User das Recht zur Anlage von App-Workspaces hat, besteht derzeit das große Risiko, daß durch unüberlegtes Anlegen von Power BI App-Workspaces die Office365 Gruppenorganisation „überschwemmt“ wird. Dies muß durch organisatorische Maßnahmen bei der Einführung von Power BI bestmöglich verhindert werden.

3. Access Control über „Apps“-Mitgliedschaften

„Power BI Apps“ dienen dazu, sämtliche Dashboards, Reports und Datasets in einem App-Workspace als Paket für die jeweiligen End User in einem sehr einfachen „Standard-Berechtigungsverfahren“ bereitzustellen und auch die laufenden Updates und Weiterentwicklungen der Dashboards und Reports organisatorisch zu handhaben.

Power BI Apps sind – entgegen dem ersten Eindruck – nicht nur etwas für große Unternehmen sondern sollten generell verwendet werden, um End User zu berechtigen. Obwohl das Konzept der Power BI Apps grundsätzlich gut ist, sind heute leider noch ein paar sehr störende „Umständlichkeiten“ mit dieser Verteiltechnik verbunden (kein Push möglich, verwirrende Navigation). Aber das wird sich hoffentlich noch werden.

Power BI Apps“ wurden im Mai 2017 eingeführt und lösen die „Content Packages“ (deutsch „Inhaltspakete“) schrittweise ab. Die bisherigen Content Packages durch die neuen Apps zu ersetzen, geht sicherlich in die richtige Richtung, da die Content Packages so viele Freiheitsgrade für den einzelnen User geboten haben, daß das organisatorische Chaos damit in gewisser Weise vorprogrammiert war. Derzeit gibt es die alten Content Packages noch parallel zu den neuen Apps, diese sollten aber nicht mehr verwendet werden.

1a. Power User Perspektive

Power BI Apps können mit dem Button „App veröffentlichen“ auf „App-Workspace“ Ebene erstellt werden (nicht aber für Dashboards im „My Workspace“ eines einzelnen Users):

Im ersten Schritt wird ein Erläuterungstext und eine Signalfarbe für die App festgelegt …

… im nächsten Schritt erfolgt die sehr wichtige Info, daß alle Dashboards, Reports und Datasets des App-Workspaces in die App aufgenommen werden. Eine Selektion ist ist hier leider nicht möglich. Es kann ein bestimmtes Dashboard / ein bestimmter Report als Landingpage festgelegt werden, davon raten wir aber eher ab, da die Navigation dann für die End User schwieriger wird (zur Demo machen wir das aber trotzdem hier). Falls die Auswahl „Keine“ getroffen wird, wird dem User eine Liste der verfügbaren Artefakte gezeigt.

Zuletzt erfolgt die Zuordnung der berechtigten User:

Mit dem Button Fertig stellen wird die App fertig gestellt:

Eine sehr wertvolle Eigenschaft der Apps ist die Eigenschaft, daß Änderungen an den Datasets, Reports und Dashboards im zugrundeliegenden App-Workspace nicht automatisch in die App durchgereicht werden. Erst wenn der Ersteller der App – dieser ist deren Besitzer – die App zur Bearbeitung aufruft und erneut freigibt, werden die Änderungen an die End User verteilt.

Unklar ist (mir) derzeit, wie die Besitzer-Rolle einer App – beispielsweise nach dem Austritt eines Mitarbeiters – auf einen anderen User übertragen werden kann. Das Administrator-Recht im zugrundeliegenden App-Workspace führt derzeit (leider) nicht dazu, daß die App auch von einem anderen User bearbeitet werden könnte. Möglicherweise ein Bug …

1b. End User Perspektive

Derzeit bekommen die berechtigten End User die App aber leider nicht im Push-Verfahren zugestellt, sondern jeder einzelne Benutzer muß die App relativ umständlich seinem Power BI Account hinzufügen. Die Idee dahinter ist gut, in der Praxis wird dies vermutlich aber sehr oft scheitern. Dieser Punkt steht erfreulicherweise bereits auf der Roadmap und wird hoffentlich sehr bald in ein Push-Verfahren geändert.

Die Aktivierung einer App durch den End User erfolgt derzeit – wie gesagt sehr umständlich – über den Bereich Apps in der Navigationsleiste links, dann dem Button App abrufen und dann die Auswahl aus dem AppSource Dialog:

Das Dashboard bzw. der Report auf der Landingpage sieht wie gewohnt aus, die Bearbeitungsfunktionen sind wie schon zuvor bei den App-Workspaces deaktiviert, da es sich bei Apps immer um einen Read-Only Zugang handelt. Sehr unintuitiv finde ich den Zugang zu den Artefakten rechts oben …

… hier ist für mich unverständlich, warum dieser Overview nicht über die Navigation links dargestellt werden kann (das sieht ja sehr sehr ähnlich ist).  Wie auch immer, man landet dann in diesem Schirm:

Anders als beim App-Workspace ist neben den Dashboards und Reports auch das Dataset für die „Analyze with Excel“ sowie die „Quick Insights“ verfügbar, die Connections sind aber für End User unzugänglich und die Aktualisierung kann ebenfalls nur durch App-Workspace Administratoren angestoßen bzw. Zeitpläne konfiguriert werden.

Best Practices

Wir möchten folgende Best Practices ableiten, um aus einem „unkontrollierten Haufen“ einzelner Power-BI-Accounts eine nachhaltige Enterprise BI Applikation aufzubauen.

  1. Der My Workspace eines bestimmten Nutzers (auch nicht einer anonymen Office-Mailadresse) sollte nicht für produktive Anwendungen genutzt werden sondern ausschließlich für Sandbox- und adhoc Anwendungen eines Users (aber auch nicht für private Analysen). Die Einhaltung von Compliance Regeln muß organisatorisch/vertraglich sichergestellt werden, da jeder User in seinem My Workspace unbeschränkbare Rechte hat und derzeit auch jeder User das Recht hat, eigene App-Workspaces (mit angeschlossenen Office365 Groups) und Apps zu erzeugen.
  2. Enterprise Anwendungen müssen immer über App-Workspaces strukturiert werden, da damit die Besitzer-Rolle vom einzelnen Benutzer entkoppelt wird und die Zugriffsrechte fein-granularer als beim Sharing gesteuert werden können. Die Strukturierung der App-Workspaces wird sich in der Regel an Abteilungsstrukturen orientieren. Derzeit wirkt hier noch störend, daß jeder App-Workspace auch gleichzeitig eine Office365 Group erzeugt.
  3. Die Verteilung der Dashboards, Reports und Datasets an die End User sollte über Power BI Apps erfolgen, auch wenn diese heute noch einige schmerzende Schwachstellen haben. Selbst bei kleinen Benutzerzahlen ist dies sinnvoll, da mit den Apps ein standardisiertes Berechtigungsverfahren (mit wenig Fehlerquellen) sowie ein sehr nützlicher Update-Modus zur Verfügung steht.
  4. Die 3 Methoden für Access Control sollten nicht beliebig gemischt werden, da sonst sehr schnell ein sehr unübersichtlicher Zustand eintritt. Unsere empfohlene Standardmethode ist es, die (1) Sharing-Funktion nur für temporäre adhoc Einladungen zu verwenden, über (2) App-Workspaces den Zugriff für die Power User zu regeln und (3) für die Verteilung an die End User „Power BI Apps“ zu verwenden.
  5. Da Apps (derzeit) zwingend alle Artefakte von genau 1 App-Workspace verteilen, müssen die App-Workspaces schon nach Gesichtspunkten der späteren Verteilung gestaltet werden.
  6. Wird die Sharing-Funktion in Ausnahmefällen doch verwendet, dann ist dringend von der Aktivierung der „Re-Sharing“ Option abzuraten, da ein unkalkulierbarer viraler Effekt dann nicht mehr verhindert werden kann.
  7. Beim Austritt eines Mitarbeiters muß sichergestellt werden, daß keine produktiven Anwendungen des Unternehmens im My Workspace laufen (und auch keine privaten) und daß alle eventuell aufrechten Sharings garantiert beendet werden.

Fazit

Im Bereich der Access Control sind in den mittleren Zukunft noch deutliche Änderungen zu erwarten, einerseits wegen der diesbezüglich ohnehin kommunizierten Roadmap, andererseits wegen der noch zahlreich vorhandenen (im Beitrag genannten) Schwachstellen sowie der nach unserer Ansicht noch nicht ausgereiften Usability. Beispielsweise die Navigation zwischen My Workspace, App-Workspaces, Für-mich-Freigegeben und Apps ist für ungeübte Power BI User gewöhnungsbedürftig bis verwirrend.

Im Teil 2 dieser Blogserie werden wir die Security, also die Berechtigung innerhalb einer Anwendung, beleuchten.

Quellen

Sharing: powerbi.microsoft.com/en-us/documentation/powerbi-service-share-unshare-dashboard

App-Workspace: powerbi.microsoft.com/en-us/guided-learning/powerbi-service-manage-your-group-in-power-bi-and-office-365

App: powerbi.microsoft.com/en-us/blog/distribute-to-large-audiences-with-power-bi-apps (-> Roadmap am Ende des Beitrags)

App: powerbi.microsoft.com/en-us/documentation/powerbi-service-what-are-apps

App: angryanalyticsblog.azurewebsites.net/index.php/2017/05/11/power-bi-content-workflow-with-apps

Whitepaper: powerbi.microsoft.com/en-us/documentation/powerbi-admin-power-bi-security/

Whitepaper: blog.crossjoin.co.uk/2017/06/20/white-paper-on-planning-a-power-bi-enterprise-deployment/

Robert Lochner

Robert Lochner ist seit 2001 als Unternehmer tätig und Gründer der Linearis. Er ist Autor des Linearis Blogs, hält Trainings und unterstützt Unternehmen bei der digitalen Transformation ihrer Business Intelligence Prozesse.

Weitere Beiträge

Kategorien: Analyse, Dashboarding, Power BI im Team nutzen, Reporting