Business Intelligence-Lösungen bilden in der Regel Geschäftsdaten ab, die nicht jeder Mitarbeiter in vollem Umfang sehen soll.  Sinnvoll und notwendig ist es häufig, den Mitarbeitern nur Zugriff auf diejenigen Daten zu geben, die für ihre Arbeit notwendig sind. Um trotzdem alle Geschäftsdaten in derselben Datenbank/ PBIX-Datei speichern zu können, verfügt Power BI über sogenannte Row Level Security, eine Form der Zugriffsbeschränkung auf Datensatzebene, die es ermöglicht Mitarbeitern nur diejenigen Datensätze anzuzeigen, für die sie berechtigt wurden. Dieser Beitrag ist eine allgemeine Einführung in Row Level Security in Power BI und zugleich der Start einer mehrteiligen Beitragsserie zu diesem spannenden Thema.

Als Abonnent meines Newsletters erhältst Du die Beispieldateien zu den Beiträgen dazu. Hier geht’s zum Abonnement des Newsletters!

Warum ein Berechtigungskonzept für den Zugriff auf Daten?

Daten sind das Gold des 21. Jahrhunderts und die meisten Unternehmen versuchen ihre Daten vor unbefugtem Zugriff zu schützen. „Unbefugt“ gilt hierbei nicht nur für Menschen außerhalb des Unternehmens, sondern auch im Hinblick darauf, dass jeder Mitarbeiter nur diejenigen Daten sehen soll, die für seine Arbeit auch tatsächlich notwendig sind. Sieh Dir die folgende Abbildung an. In der dargestellten Faktentabelle sind Kosten je Team dargestellt. Ein entsprechend aufbereitetes Berechtigungskonzept würde die Datensätze in Reports und Dashboards für Ditmar Pfeiffer (Team 1) auf die des Teams 1 beschränken. Heike Stark (Abteilung 1) könnte alle Daten für die Teams 1 und 2 sehen. Karsten Müller, der den Bereich 1 verantwortet, hätte folglich die Berechtigung, auf alle Daten der Abteilungen 1 und 2, inklusive der darunter befindlichen Teams einzusehen.

Schutz der Unternehmensdaten durch die Zugriffsbeschränkung auf notwendige Datensätze, ist der Sinn eines Berechtigungskonzeptes. Doch wie läßt sich ein solches Konzept mit Power BI umsetzen? Die Antwort lautet: Row Level Security, oder kurz RLS!

Was ist Row Level Security (RLS)?

Row Level Security ist die technische Möglichkeit, den Zugriff innerhalb von Power BI auf Datensatzebene , d. h. Zeilenebene, auf befugte Mitarbeiter zu beschränken. Ein solches Berechtigungskonzept wird in Power BI Desktop definiert, findet allerdings zum gegenwärtigen Zeitpunkt ausschließlich Anwendung im Power BI Service. Für den Power BI Report Server steht diese Möglichkeit noch aus. Wichtig zu verstehen ist, dass es keine Zugriffsbeschränkung auf Datensatzebene in Power BI Desktop gibt. Erhält jemand eine pbix-Datei, stehen ihm/ ihr immer alle Daten uneingeschränkt zur Verfügung. Power BI Desktop ist die Entwicklungsumgebung für die Power BI Platform, kein Reporting-Tool! Wurde ein Datenmodell mit bestehender RLS in den Service hochgeladen, kann über das hinterlegte Berechtigungskonzept abgeglichen werden, welche Daten dieser Mitarbeiter, der sich mit seinen Nutzerdaten anmelden und somit identifizieren musste,  sehen darf. Alle Daten, für die diese Person nicht berechtigt wurde, werden auch nicht angezeigt. Existiert für diesen Nutzer gar keine Berechtigung, Daten zu sehen, sieht er/ sie in entsprechenden Reports und Dashboards nur leere Visualisierungen.

Da es verschiedene Typen von RLS gibt, gehe ich nun auf diese und deren wesentliche Unterschiede ein. In weiteren Beiträgen werde ich dies deutlich ausführlicher beschreiben. Mein Ziel für den aktuellen Beitrag ist es, einen Überblick und ein grundlegendes Verständnis für das Thema zu schaffen.

Verschiedene Typen von Row Level Security

Um Row Level Security einzurichten, gibt es zwei unterschiedliche Varianten: die statische und die dynamische Row Level Security.

Statische RLS

Die statische Row Level Security macht es erforderlich, dass in Power BI Desktop (häufig viele) Rollen definiert werden, denen dann im Power BI Service manuell Personen zugeordnet werden können. So kann ich beispielsweise alle Daten meines Datenmodells, die in den Ländern Dänemark, Schweden und Norwegen erhoben wurden, der Rolle Skandinavien zuordnen. Im Power BI Service bin ich dann in der Lage, entsprechende Mitarbeiter, die für Skandinavien zuständig sind, dieser Rolle manuell zuzuordnen. Hierbei kann ich auch auf Azure Active Directory Groups zurückgreifen, falls ich nicht jeden Mitarbeiter einzeln zuordnen möchte. Sofern die Mitarbeiter lediglich dieser einen Rolle zugeordnet wurden (es könnten auch mehrere Rollen parallel sein) wären sie ausschließlich in der Lage, Werte aus Skandinavien zu sehen. Dies ist für Szenarien mit wenigen Rollen (z. B. eine Rolle je Kontinent) sehr gut umsetzbar.

Jetzt stell Dir bitte vor, Du arbeitest für ein Handelsunternehmen, das mit mehreren 100 Produktgruppen handelt. Mitarbeiter aus Einkauf und Marketing sollen nur diejenigen Produktgruppen sehen, für die sie zuständig sind. Du müßtest wahrscheinlich sehr viele Rollen anlegen (z. B. Rolle Elektroartikel) und im Service stets pflegen, welcher Mitarbeiter welche Rolle(n) sehen darf. Das kann schnell sehr unübersichtlich werden und birgt stets die Gefahr, dass Daten in die falschen Hände geraten. Deshalb entscheidet man sich in einem solchen Szenario für die dynamische Row Level Security.

Dynamisch RLS

Auch bei der dynamischen Row Level Security erfolgt im Power BI Service die Zuordnung des Mitarbeiters (oder Azure Active Directory Security Groups) zu Rollen, aber ich benötige hier im Idealfall nur noch eine einzige Rolle, weil die Aufgabe der Rollen durch das Datenmodell übernommen wird. Auf diese Weise wird es beispielsweise möglich, Tabellen zu pflegen, die die Zuordnung von Mitarbeitern zu Gruppen (z. B. Abteilungen, Teams, Produktengruppen) beinhalten. Der Power BI Service erkennt dann automatisch über Anmeldung des Nutzers, für welche Datensätze dieser berechtigt ist. Der große Vorteil dieser RLS-Variante ist, dass die Zuordnung des Nutzers zu seinen relevanten Daten durch das Datenmodell definiert ist und nicht durch die (aufwändige) Definition von Rollen. Tabellen, die diese Zuordnung definieren, können beispielsweise aus HR-Systemen automatisert übernommen und via Power Query ins Datenmodell integriert werden. Wie das geht, werde ich im Laufe dieser Beitragsserie zeigen.

Nach dieser kurzen Vorstellung der RLS-Typen, hast Du vielleicht eine Idee, für welchen von beiden Typen Du Dich in Deinem Szenario entscheiden würdest. Bevor Du das jedoch tust, hier noch ein kurzer Exkurs, wann RLS überhaupt in Power BI zur Verfügung steht.

Wann steht RLS zur Verfügung?

Ob RLS zur Verfügung steht, ist von einigen Faktoren abhängig, auf die ich jetzt eingehen werde.

Ort der Anwendung

RLS kann, wie weiter oben schon erwähnt, gegenwärtig nur im Power BI Service genutzt werden. RLS funktioniert nicht (und wird es hoffentlich auch nie) in Power BI Desktop. Gegenwärtig ist RLS noch nicht im Power BI Report Server vorhanden, wurde aber bereits für Anfang 2019 angekündigt.

Lizenzen

RLS ist nur interessant, wenn ich im Power BI Service Reports/ Dashboards und/oder Datasets mit anderen teilen möchte. Für mich alleine muss ich schließlich kein Berechtigungskonzept einrichten. Teilen ist in Power BI ein sog. Pro-Feature, d. h. es erfordert eine Power BI Pro-Lizenz. Dies ist sowohl für den Reportsender, als auch für den Empfänger notwendig.

Bist Du im glücklichen Umstand, dass in Deinem Unternehmen, zusätzlich zu (mindestens einer) Power BI Pro-Lizenz auch Power BI Premium vorhanden ist, dann stellt sich das Szenario mit dem Teilen etwas anders dar: Sofern sich meine Inhalte in einem App-Workspace (App-Arbeitsbereich) in einer Premium-Kapazität befinden, bin ich in der Lage, diese Inhalte auch mit Nutzern einer kostenlosen Free-Lizenz zu teilen. Eine sinnvolle Frage wäre an dieser Stelle, ob auch beim Vorhandensein von Power BI Premium der Berichtsempfänger, bei dem RLS greifen soll, eine Pro Lizenz benötigt, oder ob dafür die Free-Lizenz ausreichend ist? Die Antwort ist: RLS ist kein Pro Feature, sondern das Teilen von Daten ist eines. RLS kann somit im Falle von Power BI Premium auch mit Nutzern einer Free-Lizenz verwendet werden.

ACHTUNG: Auch wenn ich die RLS in meinem Modell korrekt aufgesetzt und im PBI Service die entsprechenden Mitarbeiter ihren Rollen zugeordnet habe, gibt es eine kleine „Falle“, die dafür sorgen kann, dass die Mitarbeiter trotzdem alle Daten einsehen können.

Sofern ich meine Daten über einen App-Workspace teile, kann ich diesem Workspace unter Arbeitsbereich bearbeiten (3) Mitlieder hinzufügen. Hierbei kann ich wählen, ob diese Mitglieder Inhalte nur anzeigen (2) oder auch bearbeiten können (1):

Sofern ich Mitgliedern hier das Recht einräume, Inhalte auch zu bearbeiten, greift die Row Level Security nicht mehr. Hierbei reicht es, dem betreffenden Kollegen den Status Mitglied zuzuordnen. Er muss kein Admin sein und trotzdem kann er alle Daten sehen und nicht nur diejenigen, die ihm laut RLS zugewiesen sind. Beachte das unbedingt, wenn Du RLS im Unternehmen integrierst!

Verbindung zur Datenquelle

Ein weiterer wichtiger Punkt für die Möglichkeit, RLS zu nutzen, ist die Verbindung zur Datenquelle. Power BI unterstützt hier:

• Importierte Daten,
• Datenquellen, zu denen die Verbindung via DirectQuery aufgenommen wurde.

Eine Ausnahme stellen hierbei Liveverbindungen (Live Connection) z. B. zu den SQL Server Analysis Services (SSAS), oder auch zum Power BI Service dar, da diese Datenquellen ein eigenes Berechtigungskonzept beinhalten, das eins zu eins durchgereicht wird. Hier besteht keine Möglichkeit, es durch RLS in Power BI Desktop zu übersteuern.

Einschränkungen durch Row Level Security

Row Level Security bringt zum gegenwärtigen Zeitpunkt auch Einschränkungen mit sich, derer man sich bewußt sein sollte, bevor man beginnt, RLS in sein Modell zu integrieren. Die Wesentlichen sind:

• Q&A steht im Falle von RLS nicht zur Verfügung. Willst Du Q&A also unbedingt in Deinem Modell nutzen, kannst Du keine RLS integrieren.
• Es können dem Modell maximal 1.000 Nutzer oder Sicherheitsgruppen zugeordnet werden. Sollte das für Dein Szenario nicht ausreichen, kannst Du RLS derzeit nicht nutzen.

Da sich diese Einschränkungen schnell ändern können, empfehle ich diesen Artikel zu konsultieren, bevor Du mit RLS in Deinem Modell beginnst.

Das war viel Theorie, aber mir ist wichtig, dass gleich zu Beginn klar ist, wofür RLS gut ist, welchen Typ man für das eigene Szenario wählen sollte, und ob damit verbundene Einschränkungen eventuell die Nutzung von RLS verhindern. In den nächsten Beiträgen geht es dann an die technische Umsetzung von Row Level Security in Power BI 🙂

Bis zum nächsten Mal und denk dran: Sharing is caring. Wenn Dir der Beitrag gefallen hat, dann teile ihn gerne. Falls Du Anmerkungen hast, schreibe gerne einen Kommentar, oder schicke mir eine Mail an lars@ssbi-blog.de

Viele Grüße aus Hamburg,

Lars

Ich schreibe meine Beiträge für Dich, den Leser. Bitte schenke mir eine Minute Deiner Zeit und bewerte die folgenden Kategorien, um mir zu helfen meine Beiträge so gut wie möglich zu schreiben. Danke 🙂