Im folgenden Beitrag will ich auf den aktuellen Stand zum Thema Row-Level Security im Power BI Umfeld eingehen. Bis anhin war es schwierig, die Sicherheit der Daten in einem Report sicherzustellen. Wurde in der Firma ein Report versehentlich an Peter Müller Abt.1 statt an Peter Müller Abt.2 gesendet, konnte erstgenannte Person den Report mit allen Daten einsehen, auch wenn sie im Normalfall keine Berechtigung für diese Daten hat.
Verhindert werden konnte dieser Umstand, in dem ein Report mit einer Live Connection auf eine on-prem Datenbank erstellt wurde. Somit werden im Report selber keine Daten, sondern nur noch das Gerüst des Reports gespeichert. Die Daten für den Report werden jedes Mal beim Aufrufen aus der Datenbank neu geladen. Die Datenbank übernimmt dabei die Kontrolle der Benutzerberechtigung. Von Power BI werden die Credentials des aufrufenden Users an die Datenbank übermittelt und die DB sendet nur Daten zurück, für welche der User auch eine Berechtigung hat. Erhält nun die falsche Person einen Report mit Informationen für welche sie keine Berechtigung hat, sind die Daten dennoch sicher und können nicht eingesehen werden.
Seit neustem gibt es nun bei Power BI die lang gewünschte Möglichkeit, Zugriffsrechte direkt in Power BI zu vergeben und zu verwalten, was mit sogenannten Row-Level Security Regeln funktioniert.
Row-Level Security
Row-Level Security (RLS) kann auf Deutsch etwa mit Sicherheit auf Zeilenebene übersetzt werden. Unterschiedliche Benutzer haben das Recht auf die gleichen Tabellen einer Datenbank zuzugreifen, haben jedoch nicht das Recht, die gleichen Daten zu sehen. So kann z.B. eingeschränkt werden, dass ein Verkäufer nur die Verkäufe seiner Region sehen kann, während ein Vorgesetzter die Verkäufe aller Regionen sieht. Führen beide Anwender den gleichen Report aus, erhalten sie unterschiedliche Werte zurückgeliefert, abhängig von ihren Rechten.
Bis anhin war es zum Beispiel nur möglich, dieses Verhalten mit unterschiedlichen Views zu erreichen. Unterschiedlichen Usergruppen wurden verschiedene Reports, welche auf unterschiedliche Views mit entsprechenden Filtern zugreifen, zur Verfügung gestellt.
RLS in Power BI steht aktuell erst als Preview zur Verfügung. Das bedeutet, dass diese neue Möglichkeit noch nicht in der produktiven Umgebung verwendet werden soll. Es ist wahrscheinlich, dass sich in den nächsten Wochen noch einige Änderungen ergeben. Zudem wird von Seite Microsoft davor gewarnt, dass es auch möglich ist, dass die RLS-Einstellungen verloren gehen, sobald die endgültige Version veröffentlicht wird.
Vorgehen
In PowerBI.com kann auf einem Modell rechts neben dem Namen auf die drei Punkte (…) und das neue Tab Sicherheit gewählt werden.
Beim Verfassen dieses Artikels gab es noch den Fehler, dass das Feld ‚Security‘ nur in der englischen Sprachversion angezeigt wurde. Falls PowerBI.com in einer anderen Sprache verwendet wird, ist das Feld nicht sichtbar.
In diesem Fall in PowerBI.com unter Einstellungen die Sprache auf Englisch ändern. PowerBI Desktop kann weiterhin auf Deutsch verwendet werden.
Zur Verdeutlichung wird hier ein Dataset zuerst mit der deutschen und anschliessend mit der englischen Spracheinstellung aufgerufen.
Auf Deutsch sind nur 5 Auswahlmöglichkeiten vorhanden, ein Tab ‚Sicherheit‘ fehlt.
Wird das genau gleiche Dataset, jedoch mit englischsprachiger Einstellung aufgerufen, stehen die Tabs ‚Quick Insights‘ und ‚Security‘ zur Verfügung.
Wird Security selektiert, warnt Power BI aktuell, dass ein Republizieren des Datasets nicht unterstützt wird, wenn RLS verwendet wird. Die Einstellungen des RLS gehen beim Republizieren verloren und müssen neu erfasst werden.
Im neuen Fenster muss anschliessend zuerst eine neue Rolle definiert werden.
Anschliessend wird definiert, für welche Anwender (Members) die neu erstellte Rolle gilt. Neue Mitglieder dieser Rolle werden über die E-Mailadresse hinzugefügt. Jedes Mitglied muss einzeln eingegeben werden, es können keine Security-Gruppen erfasst werden.
Abbildung 6 Create new Role
Im nächsten Schritt können die entsprechenden Regeln definiert werden. Die Regeln müssen als DAX-Anweisungen erfasst werden. Hilfestellungen, wie die Regeln definiert werden müssen, werden keine angeboten. Die Anweisungen können in diesem Fenster nicht validiert werden und werden auch als ungültige Befehle akzeptiert und gespeichert.
Wird ein ungültiger DAX-Befehl erfasst, werden den Nutzern in den Reports keine Daten mehr angezeigt. Es erfolgt jedoch keine Fehlermeldung, dass die Anweisung in DAX nicht verstanden wurde.
Zu beachten ist weiterhin, dass Anwender, welche keiner Rolle zugewiesen sind, ebenfalls keine Daten mehr sehen, sobald RLS in diesem Modell verwendet wird. Ansonsten könnte eine unberechtigte Person mehr Daten sehen als ein erfasster Anwender und die Idee hinter RLS würde umgangen werden.
Bei meinem Test konnte der Ersteller des Reports immer alle Daten sehen, auch wenn die RLS die Daten eingeschränkt hätte. Dieser Umstand muss besonders beim Testen der Funktionen berücksichtig werden.
Einschränkungen
Laut Microsoft sind aktuell die folgenden Einschränkungen für Row-Level Security zu berücksichtigen (frei übersetzt aus den offiziellen Unterlagen von Microsoft)
- RLS kann nur für ein Dataset verwendet werden, welches mit Power BI Desktop erstellt wurde. Soll RLS für ein Dataset aus einer Excel-Quelle verwendet werden, müssen diese Files zuerst in PBIX Files (Power BI Desktop) konvertiert werden.
- Nur ETL Connections werden aktuell unterstützt. Direkte Abfragen zu diversen Quellen werden in späteren Releases unterstützt.
- Wird am PBIX File eine Änderung durchgeführt und das File erneut publiziert, müssen die RLS-Einstellungen erneut erstellt werden.
- RLS kann nicht in einem Gruppen Workspace definiert werden.
- Security Groups oder Listen können aktuell nicht zur Member Liste hinzugefügt werden. Es müssen die einzelnen Personen selektiert werden. Diese Funktion ist jedoch für einen späteren Release geplant.
- Q&A und Cortana sind mit RLS zusammen nicht verfügbar.