Wenn Power BI vorgestellt oder diskutiert wird, stehen meistens die grafischen Möglichkeiten oder auch die Möglichkeiten, die Anwender beim Extrahieren von Daten aus unterschiedlichen Datenquellen haben, im Vordergrund. Das ist auch klar, weil Power BI seine volle Stärke in diesen beiden Bereichen ausspielt und dies auch Bereiche sind die man einerseits einfach demonstrieren kann und die auch beim Kunden einfach verstanden werden können. Diese Funktionen sorgen oft für „Ahh“ und „Ohh“ Momente und wecken natürlich Begehrlichkeiten dieses tolle Produkt sofort einsetzen zu wollen.

Ein wichtiger Punkt der gerade im Einsatz von Power BI im Unternehmen eine zentrale Rolle spielt wird hierbei oft übersehen, weil der Punkt inhaltlich nicht so „sexy“ ist wie interaktive Diagramme die gut aussehen. Es geht um den Punkt Sicherheit. Sobald Power BI auf unternehmenskritische Produktivdaten zugreifen soll fängt die Sicherheits-Debatte auch schon an. Wer darf welche Daten sehen? Wer darf welche Daten auf gar keinen Fall sehen? Welche Möglichkeiten bietet Power BI hier?

In diesem Artikel möchte ich unterschiedliche Quellen aus dem Internet zusammenfassen und einen groben Überblick darüber geben wie Power BI das Thema Sicherheit bzw. Datensicherheit behandelt. Wer etwas tiefer in das Thema einsteigen möchte kann hier ein englischsprachiges Whitepaper zum Thema Sicherheit in Power BI herunterladen.

Betrachtet man die Sicherheit in Power BI können drei Kernthemen identifiziert werden.

• Sicherheit beim Zugriff auf Power BI, d.h. wie genau werden Power BI Benutzer gegenüber dem Dienst authentifiziert?
• Sicherheit beim Zugriff auf die Daten innerhalb von Power BI, d.h. wie greifen authentifizierte Benutzer auf Dokumente und Daten innerhalb von Power BI zu
• Sicherheit beim Zugriff von Power BI auf Datenquellen innerhalb eines Unternehmens, d.h. wie greift Power BI selbst auf die Daten zu die Berichten und Dashboards zugrundeliegen.

Sicherheit beim Zugriff auf Power BI und innerhalb von Power BI

Wie sicherlich schon richtig vermutet basiert Power BI natürlich auf Azure, Microsofts Cloud Umgebung und ist somit in vielen Regionen rund um die Welt verfügbar. Wenn sich ein User als erster Anwender einer Organisation (die aufgrund der E-Mail Domäne identifiziert wird) bei Power BI anmeldet wird innerhalb von Azure ein so genannter „Tenant“ angelegt. Tenant heißt im Englischen „Mieter“, in einer deutschen Umgebung würde man wahrscheinlich das Wort „Mandant“ verwenden. Technisch gesehen ist ein Tenant ein Azure Active Directory und als solches von allen anderen Azure Active Directories (Tenants) getrennt. In diesem Azure Active Directory werden alle Benutzer verwaltet die auf den bereitgestellten Dienst, in diesem Fall Power BI (gilt aber natürlich auch für andere Dienste wie Intune oder Office 365) zugreifen sollen. Alle anderen Security relevanten Informationen wie Gruppen oder Berechtigungen werden in diesem Auzre Active Directory verwaltet. Wichtig an dieser Stelle ist noch, dass der Tenant in dem Azure Datacenter angelegt wird das dem Anwender der den Tenant einrichten am nächsten liegt und dass der Tenant von dort aus (Stand heute) nicht umgezogen werden kann.

Nachdem der Tenant angelegt wurde, wird dann eine Power BI Umgebung bereitgestellt. Diese Umgebung besteht, wie oben im Bild zu sehen ist, aus zwei Elementen, dem Web Frontend Cluster (WFE) und dem Backend Cluster. Dem Web Frontend Cluster fällt die Aufgabe zu die initiale Verbindung zu verwalten und die Benutzerauthentifizierung über Azure Active Directory durchzuführen. Konnte der Benutzer erfolgreich authentifiziert werden, so bekommt er ein Token und wird dann an den Backend Cluster weitergeleitet, der ab diesem Moment übernimmt. Gegenüber dem Backend Cluster wird der User dann mit dem Token authentifiziert. Grundsätzlich wird immer der nächste WFE Cluster verwendet. Das Routing wird durch den Azure Traffic Manager durchgeführt. Wie genau dieser Prozess funktioniert kann hier nachgelesen werden. Um den zugehörigen Backend Cluster zu bestimmen wird der Azure Global Service verwendet, der wiederum bestimmt in welchem Azure Datacenter sich der Tenant des Users befindet. Der Backend Cluster „ist“ im Prinzip Power BI und stellt alles was Power BI ausmacht zur Verfügung. Hierbei übernimmt die Gateway Rolle die Kommunikation zwischen den Anwendern und allen anderen Rollen, die innerhalb des Backend Clusters implementiert worden sind. Neben der Gateway Rolle ist das Azure API Management die einzige andere Komponente des Backend Clusters auf die direkt vom Internet aus zugegriffen werden kann. Diese beiden Komponenten liefern alle Dienste die zum Zugriff auf Power BI benötigt werden wie beispielsweise Authentifizierung, Autorisierung, Load Balancing usw.. Die Trennung dieser beiden Rollen von allem anderen innerhalb des Backend Clusters wird durch die gestrichelte Linie oben im Diagramm symbolisiert.

Sicherheit beim Zugriff auf die Daten in Power BI

Bevor wir uns mit der Sicherheit beim Zugriff auf Datenquellen über Power BI beschäftigen können müssen wir uns zunächst einmal damit beschäftigen wie Power BI Daten überhaupt speichert. Wie man oben aus dem Diagramm entnehmen kann gibt es zwei Datenspeicher die von Power BI verwendet werden. Zum einen ist das ein Azure SQL Database zum anderen der BLOB-Storage. Grundsätzlich gilt, dass sämtlicher vom Anwender hochgeladener Inhalt, wie beispielsweise Excel-Tabellen oder Power BI Desktop Dateien, im Azure BLOB Storage landen. Metadaten über die Power BI Subscription und darin abgelegten Elemente wie Reports, Dashboards und Informationen zum Tenant werden in der Azure SQL Datebank gespeichert. Die Datenbank selbst wird über TDE (Transparent Data Encryption) verschlüsselt. Bisher werden nicht alle Daten die im Azure BLOB Storage liegen verschlüsselt, es ist aber in Q3 2016 damit zu rechnen, dass auch hier sämtliche Daten verschlüsselt abgelegt werden.

Bei den in Power BI angebundenen Datenquellen selbst muss man unterscheiden zwischen Datenquellen die über Direct Query und Datenquellen die nicht über Direct Query angebunden werden. Bei Daten die über Direct Query angebunden werden, wird die Benutzerabfrage aus DAX (Data Analysis Expression) in die native Sprache der Datenquelle umgewandelt (beim SQL Server ist das beispielsweise T-SQL). Daten die über Direct Query angesprochen werden, werden nicht in Power BI gespeichert wenn die Abfrage nicht aktiv ist. Ist die Abfrage aktiv, so werden die entsprechenden Daten zwischengespeichert um Diagramme oder Dashboards zu zeigen. Statt der Daten wird bei Direct Query nur eine Referenz auf die Daten gespeichert, d.h. eine Direct Query enthält alle Daten die benötigt werden um eine Verbindung zur Datenquelle herzustellen (das sind neben dem Speicherort der Datequelle natürlich auch die Anmeldeinformationen mit denen man auf die Datenquelle zugreifen kann). Unterstützt eine Datenquelle Direct Query nicht, so werden die von dieser Datenquelle zurückgegebenen Daten im Power BI Dienst gespeichert. Auch hier gilt: Keine Regel ohne Ausnahme! Wenn es sich bei den Nicht-Direct-Query-Daten um lokale Daten handelt die über ein Power BI Gateway freigegeben wurden, so wird in diesem Fall auch wieder nur die Referenz auf diese Daten gespeichert. Der Zugriff auf lokale Daten über Power BI ist stets verschlüsselt.

Sicherheit beim Zugriff von Power BI auf Datenquellen

Beim Zugriff von Power BI aus auf Datenquellen wird unterschieden, ob die Datenquelle Row Level Security (also Sicherheit auf Datensatzebene) unterstützt oder nicht. Unterstützt die Datenquelle keine Row Level Security, so erfolgt der Zugriff auf die Datenquelle über die in der Datenverbindung hinterlegten Anmeldeinformationen, d.h. alle Anwender greifen mit demselben Konto auf die Backend-Datenqulle zu und sehen demzufolge auch dieselben Daten, nämlich die Daten auf die das entsprechende Konto Zugriff hat. In diesem Fall greifen die Anwender auf die Daten zu, die in Power BI entweder vom Autor des Berichts oder durch eine automatische Aktualisierung hochgeladen worden sind. Eine Re-Authentifizierung der Benutzer gegenüber der eigentlichen Datenquelle findet nicht statt.

Unterstützt eine Datenquelle Row Level Security, so wird anhand des zugreifenden Benutzerkontos und der damit verbundenen Berechtigungen entschieden welche Daten für den jeweiligen Benutzer zu sehen sind und welche nicht. Hierbei muss das Konto des zugreifenden Benutzers auf ein „internes“ Benutzerkonto abgebildet werden. Unter Power BI kann, genau so wie unter Office 365 auch, mit zwei Benutzerkonten gearbeitet werden, mit Benutzerkonten die sich auf die eigene Domäne beziehen oder mit Benutzerkonten die sich auf Azure beziehen. Ein Beispiel für die eigene Domäne wäre frank@geislers.net, ein Beispiel für ein Azure Benutzerkonto ist frank@meinefirma.onmicrosoft.com. Dieses Benutzerkonto wird dann auf ein internes Benutzerkonto abgebildet. Im Fall der eigenen Domäne ist das recht einfach, da das externe Benutzerkonto mit dem internen Benutzerkonto übereinstimmt. Wird das Azure Benutzerkonto verwendet, so muss ein Verzeichnismapping eingerichtet werden um die externen Benutzerkonten auf interne Konten abzubilden. Danach wird dann mit dem internen Benutzerkonto auf die Datenquelle zugegriffen  und jeder Benutzer sieht nur das, für das er über Row Level Security berechtigt ist. Über das Power BI Enterprise Gateway kann man Row Level Security auf Datenquellen erzwingen.