Power BI-Sicherheits-Whitepaper

Zusammenfassung: Power BI ist ein Online-Softwaredienst (SaaS oder Software as a Service) von Microsoft, der Ihnen das einfache und schnelle Erstellen von Self-Service Business Intelligence-Dashboards, Berichten, semantischen Modellen und Visualisierungen ermöglicht. Mit Power BI können Sie eine Verbindung mit vielen verschiedenen Datenquellen herstellen, Daten aus diesen Verbindungen kombinieren und modellieren und dann Berichte und Dashboards erstellen, die für andere Freigegeben werden können.

Schreiber: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Technische Prüfer: Cristian Petculescu, Amir Netz, Sergei Gundorov

Gilt für: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Hinweis

Sie können dieses Whitepaper speichern oder drucken, indem Sie im Browser "Drucken" und dann " Als PDF speichern" auswählen.

Einleitung

Power BI ist ein Online-Softwaredienst (SaaS oder Software as a Service) von Microsoft, der Ihnen das einfache und schnelle Erstellen von Self-Service Business Intelligence-Dashboards, Berichten, semantischen Modellen und Visualisierungen ermöglicht. Mit Power BI können Sie eine Verbindung mit vielen verschiedenen Datenquellen herstellen, Daten aus diesen Verbindungen kombinieren und modellieren und dann Berichte und Dashboards erstellen, die für andere Freigegeben werden können.

Die Welt verändert sich schnell; Organisationen durchlaufen eine beschleunigte digitale Transformation, und wir sehen eine massive Zunahme der Remotearbeit, eine erhöhte Kundennachfrage nach Onlinediensten und eine erhöhte Nutzung erweiterter Technologien in Betriebs- und Geschäftsentscheidungen. Und all dies wird von der Cloud unterstützt.

Da sich der Übergang zur Cloud von einem Rinnsal in eine Flut verwandelt hat und mit der neuen, freigelegten Oberfläche, die damit einhergeht, fragen mehr Unternehmen: Wie sicher sind meine Daten in der Cloud? und Welcher End-to-End-Schutz steht zur Verfügung, um zu verhindern, dass meine vertraulichen Daten auslaufen? Und für die BI-Plattformen, die häufig einige der strategischsten Informationen im Unternehmen verarbeiten, sind diese Fragen doppelt wichtig.

Die jahrzehntealten Grundlagen des BI-Sicherheitsmodells – Objektebene und Sicherheit auf Zeilenebene – sind zwar noch wichtig, reichen jedoch nicht mehr aus, um die Art der im Cloud-Zeitalter benötigten Sicherheit bereitzustellen. Stattdessen müssen Organisationen nach einer cloudeigenen, mehrstufigen, umfassenden Sicherheitslösung für ihre Business Intelligence-Daten suchen.

Power BI wurde entwickelt, um branchenführenden vollständigen und hermetischen Schutz für Daten bereitzustellen. Das Produkt hat die höchsten Sicherheitsklassifizierungen erzielt, die in der Branche verfügbar sind, und heute vertrauen viele nationale Sicherheitsbehörden, Finanzinstitute und Gesundheitsdienstleister es mit ihren vertraulichsten Informationen an.

Alles beginnt mit der Grundlage. Nach einer rauen Zeit anfang der 2000er Jahre investierte Microsoft massiv, um seine Sicherheitsrisiken zu beheben, und in den folgenden Jahrzehnten wurde ein starker Sicherheitsstapel aufgebaut, der so tief wie der Computer-Bios-Kernel ist und bis hin zu Endbenutzererfahrungen erweitert. Diese umfassenden Investitionen werden fortgesetzt, und heute sind mehr als 3.500 Microsoft-Techniker daran beteiligt, den Sicherheitsstapel von Microsoft zu entwickeln und zu verbessern und proaktiv die sich ständig verschiebende Bedrohungslandschaft zu behandeln. Mit Milliarden von Computern, Billionen von Anmeldungen und unzähligen Zettabytes von Informationen, die Microsofts Schutz anvertraut wurden, verfügt das Unternehmen nun über die fortschrittlichste Sicherheitsarchitektur in der Technologiebranche und wird allgemein als weltweiter Marktführer im Kampf gegen maliziöse Akteure angesehen.

Power BI baut auf dieser starken Grundlage auf. Es verwendet denselben Sicherheitsstapel, der Azure legitimiert hat, die sensibelsten Daten der Welt zu bedienen und zu schützen, und ist in die fortschrittlichsten Informationsschutz- und Compliance-Tools von Microsoft 365 integriert. Darüber hinaus liefert sie Sicherheit durch mehrschichtige Sicherheitsmaßnahmen, was zu End-to-End-Schutz führt, der sich mit den einzigartigen Herausforderungen des Cloudzeitalters befasst.

Um eine End-to-End-Lösung zum Schutz vertraulicher Ressourcen bereitzustellen, musste das Produktteam anspruchsvolle Kundenbedenken an mehreren gleichzeitigen Fronten behandeln:

• Wie steuern wir, wer eine Verbindung herstellen kann, von wo aus sie eine Verbindung herstellen und wie sie eine Verbindung herstellen?Wie können wir die Verbindungen steuern?
• Wie werden die Daten gespeichert?Wie wird es verschlüsselt?Welche Steuerelemente habe ich für meine Daten?
• Wie kann ich meine vertraulichen Daten steuern und schützen?Wie kann ich sicherstellen, dass diese Daten nicht außerhalb der Organisation verloren gehen können?
• Wie prüfe ich, wer welche Vorgänge durchführt?Wie kann ich schnell reagieren, wenn verdächtige Aktivitäten auf dem Dienst vorhanden sind?

Dieser Artikel enthält eine umfassende Antwort auf all diese Fragen. Es beginnt mit einer Übersicht über die Dienstarchitektur und erläutert, wie die wichtigsten Abläufe im System funktionieren. Anschließend wird beschrieben, wie Benutzer sich bei Power BI authentifizieren, wie Datenverbindungen hergestellt werden, und wie Power BI Daten über den Dienst speichert und verschiebt. Im letzten Abschnitt werden die Sicherheitsfeatures erläutert, mit denen Sie als Dienstadministrator Ihre wertvollsten Ressourcen schützen können.

Der Power BI-Dienst unterliegt den Microsoft Online Services-Bedingungen und den Microsoft Enterprise-Datenschutzbestimmungen. Informationen zur Lage der Datenverarbeitung finden Sie in den Bestimmungen zum Standort der Datenverarbeitung in den Microsoft Online Services-Bedingungen und im Datenschutzzusatz. Für Complianceinformationen ist das Microsoft Trust Center die primäre Ressource für Power BI. Das Power BI-Team arbeitet hart daran, seinen Kunden die neuesten Innovationen und Produktivität zu bieten. Weitere Informationen zur Compliance in den Microsoft-Complianceangeboten.

Der Power BI-Dienst folgt dem Security Development Lifecycle (SDL), strengen Sicherheitspraktiken, die Sicherheitsüberprüfungs- und Complianceanforderungen unterstützen. Der SDL unterstützt Entwickler*innen beim Erstellen sichererer Software, indem er die Anzahl und den Schweregrad von Sicherheitsrisiken in Software und gleichzeitig Entwicklungskosten reduziert. Weitere Informationen finden Sie unter Microsoft Security Development Lifecycle Practices (Microsoft Security Development Lifecycle Practices).

Power BI-Architektur

Der Power BI-Dienst basiert auf azure, der Cloud Computing-Plattform von Microsoft. Power BI wird derzeit in vielen Rechenzentren auf der ganzen Welt bereitgestellt; Es gibt viele aktive Bereitstellungen, die Kunden in den Regionen zur Verfügung gestellt werden, die von diesen Rechenzentren bedient werden, und eine gleiche Anzahl passiver Bereitstellungen, die als Sicherungen für jede aktive Bereitstellung dienen.

Web-Front-End-Cluster (WFE)

Der Web-Front-End-Cluster (WFE-Cluster) stellt dem Browser des Benutzers beim Laden der Website die anfänglichen HTML-Seiteninhalte bereit und liefert Verweise auf Azure Content Delivery Network (CDN)-Inhalte, die zum Rendern der Website im Browser verwendet werden.

Ein WFE-Cluster besteht aus einer ASP.NET Website, die in der Azure App Service-Umgebung ausgeführt wird. Wenn Benutzer versuchen, eine Verbindung mit dem Power BI-Dienst herzustellen, kommuniziert der DNS-Dienst des Clients möglicherweise mit dem Azure Traffic Manager, um das am besten geeignete (in der Regel nächstgelegene) Rechenzentrum mit einer Power BI-Bereitstellung zu finden. Weitere Informationen zu diesem Prozess finden Sie unter Performance Traffic Routing-Methode für Azure Traffic Manager.

Statische Ressourcen wie *.js, *.css und Bilddateien werden hauptsächlich auf einem Azure CDN gespeichert und direkt vom Browser abgerufen. Beachten Sie, dass Bereitstellungen von Sovereign Government-Clustern eine Ausnahme zu dieser Regel sind, und aus Compliancegründen wird das CDN weggelassen und stattdessen ein WFE-Cluster aus einer kompatiblen Region für das Hosten statischer Inhalte verwendet.

Power BI-Back-End-Cluster

Der Back-End-Cluster ist das Rückgrat aller Funktionen, die in Power BI verfügbar sind. Sie besteht aus mehreren Dienstendpunkten, die von WFE- und API-Clients genutzt werden, sowie Hintergrundarbeitsdienste, Datenbanken, Caches und verschiedenen anderen Komponenten.

Das Back-End ist in den meisten Azure-Regionen verfügbar und wird in neuen Regionen bereitgestellt, sobald sie verfügbar sind. Eine einzelne Azure-Region hostet einen oder mehrere Back-End-Cluster, die eine unbegrenzte horizontale Skalierung des Power BI-Diensts ermöglichen, sobald die vertikalen und horizontalen Skalierungsgrenzwerte eines einzelnen Clusters erschöpft sind.

Jeder Back-End-Cluster ist zustandsbehaftet und hostet alle Daten aller Mandanten, die diesem Cluster zugewiesen sind. Ein Cluster, der die Daten eines bestimmten Mandanten enthält, wird als Homecluster des Mandanten bezeichnet. Die Heimclusterinformationen eines authentifizierten Benutzers werden vom globalen Dienst bereitgestellt und vom WFE verwendet, um Anforderungen an den Heimcluster des Mandanten weiterzuleiten.

Jeder Back-End-Cluster besteht aus mehreren virtuellen Computern, die in mehreren größenveränderbaren Skalierungsgruppen kombiniert werden, um bestimmte Aufgaben auszuführen, zustandsbehaftete Ressourcen wie SQL-Datenbanken, Speicherkonten, Servicebusse, Caches und andere erforderliche Cloudkomponenten.

Mandantenmetadaten und -daten werden innerhalb der Clustergrenzen gespeichert, mit Ausnahme der Datenreplikation in ein sekundäres Back-End-Cluster in einer verbundenen Azure-Region innerhalb derselben Azure-Geografie. Der sekundäre Back-End-Cluster dient als Failovercluster bei regionalem Ausfall und ist jederzeit passiv.

Back-End-Funktionen werden von Mikrodiensten bereitgestellt, die auf verschiedenen Computern im virtuellen Netzwerk des Clusters ausgeführt werden, auf die nicht von außen zugegriffen werden kann, mit Ausnahme von zwei Komponenten, auf die über das öffentliche Internet zugegriffen werden kann:

• Gatewaydienst
• Azure-API-Verwaltung

Power BI Premium-Infrastruktur

Power BI Premium bietet einen Dienst für Abonnenten, die Premium-Power BI-Features benötigen, z. B. erweiterte KI, Verteilung an nicht lizenzierte Benutzer usw. Wenn sich ein Kunde für ein Power BI Premium-Abonnement anmeldet, wird die Premium-Kapazität über den Azure Resource Manager erstellt.

Power BI Premium-Kapazitäten werden in Back-End-Clustern gehostet, die unabhängig vom regulären Power BI-Back-End sind, wie oben beschrieben. Dies bietet eine bessere Isolation, Ressourcenzuordnung, Unterstützungsfähigkeit, Sicherheitsisolation und Skalierbarkeit des Premium-Angebots.

Das folgende Diagramm veranschaulicht die Architektur der Power BI Premium-Infrastruktur:

Die Verbindung mit der Power BI Premium-Infrastruktur kann je nach Benutzerszenario auf vielfältige Weise erfolgen. Power BI Premium-Clients können der Browser eines Benutzers, ein normales Power BI-Back-End, direkte Verbindungen über XMLA-Clients, ARM-APIs usw. sein.

Die Power BI Premium-Infrastruktur in einer Azure-Region besteht aus mehreren Power BI Premium-Clustern (mindestens eins). Die meisten Premium-Ressourcen werden in einem Cluster gekapselt (z. B. Berechnen), und es gibt einige gängige regionale Ressourcen (z. B. Metadatenspeicher). Premium-Infrastruktur ermöglicht zwei Möglichkeiten, horizontale Skalierbarkeit in einer Region zu erreichen: Erhöhung von Ressourcen innerhalb von Clustern und/oder Hinzufügen weiterer Cluster nach Bedarf (wenn Clusterressourcen ihre Grenzen nähern).

Das Backbone jedes Clusters besteht aus Computeressourcen, die von Vm Scale Sets und Azure Service Fabric verwaltet werden. Virtuelle Maschinen Skalierungsgruppen und Service Fabric ermöglichen eine schnelle und problemlose Erhöhung der Computeknoten, wenn die Nutzung wächst, und orchestrieren die Bereitstellung, Verwaltung und Überwachung von Power BI Premium-Diensten und -Anwendungen.

Es gibt viele umgebende Ressourcen, die eine sichere und zuverlässige Infrastruktur gewährleisten: Lastenausgleichsgeräte, virtuelle Netzwerke, Netzwerksicherheitsgruppen, Servicebus, Speicher usw. Alle geheimen Schlüssel, Schlüssel und Zertifikate, die für Power BI Premium erforderlich sind, werden ausschließlich von Azure Key Vault verwaltet. Jede Authentifizierung erfolgt ausschließlich über die Integration mit microsoft Entra ID.

Jede Anforderung, die zur Power BI Premium-Infrastruktur kommt, geht zuerst an Front-End-Knoten – sie sind die einzigen Knoten, die für externe Verbindungen verfügbar sind. Die restlichen Ressourcen sind hinter virtuellen Netzwerken verborgen. Die Front-End-Knoten authentifizieren die Anforderung, behandeln sie oder leiten sie an die entsprechenden Ressourcen weiter (z. B. Back-End-Knoten).

Back-End-Knoten bieten die meisten Funktionen und Möglichkeiten von Power BI Premium.

Power BI Mobile

Power BI Mobile ist eine Sammlung von Apps, die für die drei primären mobilen Plattformen entwickelt wurden: Android, iOS und Windows (UWP). Sicherheitsüberlegungen für die Power BI Mobile-Apps sind in zwei Kategorien unterteilt:

• Gerätekommunikation
• Die Anwendung und Daten auf dem Gerät

Für die Gerätekommunikation kommunizieren alle Power BI Mobile-Anwendungen mit dem Power BI-Dienst und verwenden die gleichen Verbindungs- und Authentifizierungssequenzen, die von Browsern verwendet werden, die weiter oben in diesem Whitepaper ausführlich beschrieben werden. Die mobilen Power BI-Anwendungen für iOS und Android rufen eine Browsersitzung innerhalb der Anwendung selbst auf, während die mobile Windows-App einen Broker öffnet, um den Kommunikationskanal mit Power BI (für den Anmeldevorgang) einzurichten.

Die folgende Tabelle zeigt die zertifikatbasierte Authentifizierung (CBA)-Unterstützung für Power BI Mobile basierend auf der Mobilen Geräteplattform:

CBA-Support	Ios	Android	Fenster
Power BI (Anmelden beim Dienst)	Unterstützt	Unterstützt	Nicht unterstützt
Lokale SSRS-ADFS (Herstellen einer Verbindung mit dem SSRS-Server)	Nicht unterstützt	Unterstützt	Nicht unterstützt
SSRS-App-Proxy	Unterstützt	Unterstützt	Nicht unterstützt

Power BI Mobile-Apps kommunizieren aktiv mit dem Power BI-Dienst. Telemetrie wird verwendet, um Statistiken zur Nutzung mobiler Apps und ähnliche Daten zu sammeln, die an Dienste übermittelt werden, die zur Überwachung der Nutzung und Aktivität verwendet werden; Es werden keine Kundendaten mit Telemetrie gesendet.

Die Power BI-Anwendung speichert Daten auf dem Gerät, das die Verwendung der App erleichtert:

• Microsoft Entra-ID und Aktualisierungstoken werden in einem sicheren Mechanismus auf dem Gerät gespeichert, wobei Branchenstandard-Sicherheitsmaßnahmen verwendet werden.
• Daten und Einstellungen (Schlüsselwertpaare für die Benutzerkonfiguration) werden im Speicher auf dem Gerät zwischengespeichert und können vom Betriebssystem verschlüsselt werden. In iOS erfolgt dies automatisch, wenn der Benutzer eine Kennung festlegt. In Android kann dies in den Einstellungen konfiguriert werden. In Windows erfolgt dies mithilfe von BitLocker.
• Für die Android- und iOS-Apps werden die Daten und Einstellungen (Schlüsselwertpaare für die Benutzerkonfiguration) im Speicher auf dem Gerät in einem Sandkasten und internen Speicher zwischengespeichert, der nur für die App zugänglich ist.
• Geolocation wird vom Benutzer explizit aktiviert oder deaktiviert. Wenn diese Option aktiviert ist, werden Geolocation-Daten nicht auf dem Gerät gespeichert und nicht mit Microsoft geteilt.
• Benachrichtigungen werden vom Benutzer explizit aktiviert oder deaktiviert. Wenn aktiviert, unterstützen Android und iOS keine Anforderungen an den geografischen Datenstandort für Benachrichtigungen.

Die Datenverschlüsselung kann durch Anwenden der Verschlüsselung auf Dateiebene über Microsoft Intune verbessert werden, einem Softwaredienst, der die Verwaltung mobiler Geräte und Anwendungen bereitstellt. Alle drei Plattformen, für die Power BI Mobile verfügbar ist, unterstützen Intune. Wenn Intune aktiviert und konfiguriert ist, werden Daten auf dem mobilen Gerät verschlüsselt, und die Power BI-Anwendung selbst kann nicht auf einer SD-Karte installiert werden. Erfahren Sie mehr über Microsoft Intune.

Die Windows-App unterstützt auch Windows Information Protection (WIP).

Um SSO zu implementieren, stehen einige gesicherte Speicherwerte im Zusammenhang mit der tokenbasierten Authentifizierung für andere Microsoft-Erstanbieter-Apps (z. B. Microsoft Authenticator) zur Verfügung und werden von der Microsoft-Authentifizierungsbibliothek (MSAL) verwaltet.

Power BI Mobile zwischengespeicherte Daten werden gelöscht, wenn die App entfernt wird, wenn sich der Benutzer von Power BI Mobile abmeldet oder wenn sich der Benutzer nicht anmelden kann (z. B. nach einem Tokenablaufereignis oder kennwortänderung). Der Datencache enthält Dashboards und Berichte, auf die zuvor über die Power BI Mobile-App zugegriffen wurde.

Power BI Mobile greift nicht auf andere Anwendungsordner oder Dateien auf dem Gerät zu.

Mit den Power BI-Apps für iOS und Android können Sie Ihre Daten schützen, indem Sie zusätzliche Identifikationen konfigurieren, z. B. Face ID, Touch-ID oder eine Kennung für iOS sowie biometrische Daten (Fingerabdruck-ID) für Android. Erfahren Sie mehr über zusätzliche Identifikation.

Authentifizierung beim Power BI-Dienst

Die Benutzerauthentifizierung beim Power BI-Dienst besteht aus einer Reihe von Anforderungen, Antworten und Umleitungen zwischen dem Browser des Benutzers und dem Power BI-Dienst oder den von Power BI verwendeten Azure-Diensten. Diese Sequenz beschreibt den Prozess der Benutzerauthentifizierung in Power BI, der auf den Microsoft Entra-Autorisierungscode-Genehmigungsfluss folgt. Weitere Informationen zu Optionen für die Benutzerauthentifizierungsmodelle einer Organisation (Anmeldemodelle) finden Sie unter Auswählen eines Anmeldemodells für Microsoft 365.

Authentifizierungssequenz

Die Benutzerauthentifizierungssequenz für den Power BI-Dienst erfolgt wie in den folgenden Schritten beschrieben, die in einer Abbildung dargestellt sind, die auf die Schritte folgt.

1. Ein Benutzer initiiert eine Verbindung mit dem Power BI-Dienst über einen Browser, entweder durch Eingabe der Power BI-Adresse in die Adressleiste oder durch Auswählen der Anmeldung über die Power BI-Marketingseite (https://powerbi.microsoft.com). Die Verbindung wird mithilfe von TLS und HTTPS hergestellt, und die gesamte nachfolgende Kommunikation zwischen dem Browser und dem Power BI-Dienst verwendet HTTPS.

2. Der Azure Traffic Manager überprüft den DNS-Eintrag des Benutzers, um das am besten geeignete (in der Regel nächstgelegene) Rechenzentrum zu ermitteln, in dem Power BI bereitgestellt wird, und antwortet auf das DNS mit der IP-Adresse des WFE-Clusters, an die der Benutzer gesendet werden soll.

3. WFE gibt dann eine HTML-Seite an den Browserclient zurück, die einen MSAL.js Bibliotheksverweis enthält, der zum Initiieren des Anmeldeflusses erforderlich ist.

4. Der Browserclient lädt die HTML-Seite, die vom WFE empfangen wurde, und leitet den Benutzer zur Anmeldeseite der Microsoft Online Services um.

5. Nachdem der Benutzer authentifiziert wurde, leitet die Anmeldeseite den Benutzer zurück zur Power BI WFE-Seite mit einem Authentifizierungscode zurück.

6. Der Browserclient lädt die HTML-Seite und verwendet den Authentifizierungscode, um Token (Zugriff, ID, Aktualisierung) von Microsoft Entra ID anzufordern.

7. Die Mandanten-ID des Benutzers wird vom Browser-Client verwendet, um den Power BI Global Service abzufragen, der eine Liste der Mandanten und deren Back-End-Cluster-Standorte verwaltet. Der globale Power BI-Dienst bestimmt, welcher Power BI-Back-End-Dienstcluster den Mandanten des Benutzers enthält, und gibt die Power BI-Back-End-Cluster-URL zurück an den Client zurück.

8. Der Client kann nun mit der Power BI-Back-End-Cluster-URL-API kommunizieren, wobei das Zugriffstoken im Autorisierungsheader für die HTTP-Anforderungen verwendet wird. Das Microsoft Entra-Zugriffstoken hat ein Ablaufdatum, das gemäß Microsoft Entra-Richtlinien festgelegt wird. Um die aktuelle Sitzung aufrechtzuerhalten, sendet der Power BI-Client im Browser des Benutzers regelmäßig Anfragen zur Verlängerung des Zugriffstokens, bevor es abläuft.

In den seltenen Fällen, in denen die clientseitige Authentifizierung aufgrund eines unerwarteten Fehlers fehlschlägt, versucht der Code, die serverseitige Authentifizierung im WFE zu verwenden. Ausführliche Informationen zum serverseitigen Authentifizierungsfluss finden Sie im Abschnitt "Fragen und Antworten" am Ende dieses Dokuments .

Datenresidenz

Sofern in der Dokumentation nicht anders angegeben, speichert Power BI Kundendaten in einer Azure-Geografie, die zugewiesen wird, wenn sich ein Microsoft Entra-Mandant zum ersten Mal für Power BI-Dienste registriert. Ein Microsoft Entra-Mandant beherbergt die Benutzer- und Anwendungsidentitäten, Gruppen und andere relevante Informationen, die zu einer Organisation und ihrer Sicherheit gehören.

Die Zuweisung einer Azure-Geografie für die Mandantendatenspeicherung erfolgt durch Zuordnen des Landes oder der Region, das bzw. die als Teil des Microsoft Entra-Mandantensetups ausgewählt wurde, zur am besten geeigneten Azure-Geografie, in der eine Power BI-Bereitstellung vorhanden ist. Sobald diese Bestimmung getroffen wurde, werden alle Power BI-Kundendaten in dieser ausgewählten Azure-Geografie (auch als Home-Geo bezeichnet) gespeichert, außer in Fällen, in denen Organisationen Multi-Geo-Bereitstellungen verwenden.

Mehrere Regionen (Multi-Geo)

Einige Organisationen verfügen über eine globale Präsenz und erfordern möglicherweise Power BI-Dienste in mehreren Azure-Regionen. Beispielsweise könnte ein Unternehmen seinen Hauptsitz in den VEREINIGTEN Staaten haben, aber auch geschäfte in anderen geografischen Gebieten, z. B. Australien. In solchen Fällen kann das Unternehmen verlangen, dass bestimmte Power BI-Daten im Ruhezustand in der Remoteregion gespeichert bleiben, um lokale Vorschriften einzuhalten. Dieses Feature des Power BI-Diensts wird als Multi-Geo bezeichnet.

Die Abfrageausführungsebene, Abfrage-Caches und Artefaktdaten, die einem Multi-Geo-Arbeitsbereich zugewiesen sind, werden in einer geografischen Remotekapazität von Azure gehostet und verbleiben dort. Einige Artefaktmetadaten, z. B. die Berichtsstruktur, bleiben jedoch möglicherweise im Ruhezustand in der Heimatregion des Mandanten gespeichert. Darüber hinaus kann die Datenübertragung und -verarbeitung für Arbeitsbereiche, die in einer Premium-Kapazität mit mehreren geografischen Standorten gehostet werden, weiterhin im Heimat-Geo des Mandanten stattfinden.

Weitere Informationen zum Erstellen und Verwalten von Bereitstellungen, die sich über mehrere Azure-Regionen erstrecken, finden Sie unter Konfigurieren der Multi-Geo-Unterstützung für Fabric.

Regionen und Rechenzentren

Power BI-Dienste sind in bestimmten Azure-Regionen verfügbar, wie im Microsoft Trust Center beschrieben. Weitere Informationen dazu, wo Ihre Daten gespeichert werden und wie sie verwendet werden, finden Sie im Microsoft Trust Center. Verpflichtungen im Hinblick auf den Speicherort ruhender Kundendaten sind in den Bedingungen zur Datenverarbeitung der Bestimmungen für Onlinedienste von Microsoft angegeben.

Microsoft stellt auch Rechenzentren für souveräne Entitäten bereit. Weitere Informationen zur Verfügbarkeit von Power BI-Diensten für nationale/regionale Clouds finden Sie unter Power BI national/regional clouds.

Datenhandhabung

In diesem Abschnitt werden Power BI-Verfahren zur Datenverarbeitung beschrieben, wenn es um das Speichern, Verarbeiten und Übertragen von Kundendaten geht.

Daten im Ruhezustand

Power BI verwendet zwei primäre Datenspeicherressourcentypen:

• Azure Storage
• Azure SQL-Datenbanken

In den meisten Szenarien wird Azure Storage verwendet, um die Daten von Power BI-Artefakten zu speichern, während Azure SQL-Datenbanken verwendet werden, um Artefaktemetadaten zu speichern.

Alle von Power BI gespeicherten Daten werden standardmäßig mit von Microsoft verwalteten Schlüsseln verschlüsselt. Kundendaten, die in Azure SQL-Datenbanken gespeichert sind, werden vollständig mit der transparenten Datenverschlüsselungstechnologie (Data Encryption, TDE) von Azure SQL verschlüsselt. Kundendaten, die in Azure Blob Storage gespeichert sind, werden mithilfe der Azure Storage-Verschlüsselung verschlüsselt.

Optional können Organisationen Power BI Premium verwenden, um ihre eigenen Schlüssel zum Verschlüsseln ruhender Daten zu verwenden, die in ein semantisches Modell importiert werden. Dieser Ansatz wird häufig als bring your own key (BYOK) beschrieben. Durch die Verwendung von BYOK wird sichergestellt, dass Kundendaten selbst bei einem Dienstoperatorfehler nicht verfügbar gemacht werden – etwas, das nicht einfach mithilfe einer transparenten dienstseitigen Verschlüsselung erreicht werden kann. Weitere Informationen finden Sie unter Verwenden eigener Verschlüsselungsschlüssel für Power BI.

Power BI-Semantikmodelle ermöglichen verschiedene Datenquellenverbindungsmodi, die bestimmen, ob die Datenquellendaten im Dienst beibehalten werden oder nicht.

Semantischer Modellmodus (Art)	In Power BI gespeicherte Daten
Importieren	Ja
Direktabfrage	Nein
Live Connect	Nein
Komposit	Wenn eine Importdatenquelle enthalten ist
Streamen	Wenn so konfiguriert, dass es dauerhaft bleibt

Unabhängig vom verwendeten Semantikmodellmodus speichert Power BI möglicherweise alle abgerufenen Daten vorübergehend zwischen, um die Leistung von Abfragen und Berichten zu optimieren.

Daten in Verarbeitung

Daten werden verarbeitet, wenn sie entweder aktiv von einem oder mehreren Benutzern als Teil eines interaktiven Szenarios verwendet werden, oder wenn ein Hintergrundprozess, z. B. aktualisieren, diese Daten berührt. Power BI lädt aktiv verarbeitete Daten in den Arbeitsspeicher einer oder mehrerer Dienstworkloads. Um die für die Workload erforderliche Funktionalität zu vereinfachen, werden die verarbeiteten Daten im Arbeitsspeicher nicht verschlüsselt.

Daten im Transit

Power BI erfordert, dass alle eingehenden HTTP-Datenverkehr mit TLS 1.2 oder höher verschlüsselt werden. Alle Anforderungen, die versuchen, den Dienst mit TLS 1.1 oder niedriger zu verwenden, werden abgelehnt.

Authentifizierung für Datenquellen

Beim Herstellen einer Verbindung mit einer Datenquelle kann ein Benutzer eine Kopie der Daten in Power BI importieren oder eine direkte Verbindung mit der Datenquelle herstellen.

Im Falle des Imports stellt ein Benutzer eine Verbindung basierend auf der Anmeldung des Benutzers her und greift auf die Daten mit den Anmeldeinformationen zu. Nachdem das semantische Modell im Power BI-Dienst veröffentlicht wurde, verwendet Power BI immer die Anmeldeinformationen dieses Benutzers, um Daten zu importieren. Nachdem Daten importiert wurden, greift das Anzeigen der Daten in Berichten und Dashboards nicht auf die zugrunde liegende Datenquelle zu. Power BI unterstützt die Single Sign-On-Authentifizierung für ausgewählte Datenquellen. Wenn die Verbindung für die Verwendung von Single Sign-On konfiguriert ist, werden die Anmeldeinformationen des Besitzers des semantischen Modells verwendet, um eine Verbindung mit der Datenquelle herzustellen.

Wenn eine Datenquelle direkt mit vorkonfigurierten Anmeldeinformationen verbunden ist, werden die vorkonfigurierten Anmeldeinformationen verwendet, um eine Verbindung mit der Datenquelle herzustellen, wenn ein Benutzer die Daten anzeigt. Wenn eine Datenquelle direkt über einmaliges Anmelden verbunden ist, werden die Anmeldeinformationen des aktuellen Benutzers verwendet, um eine Verbindung mit der Datenquelle herzustellen, wenn ein Benutzer die Daten anzeigt. Bei Verwendung mit einmaligem Anmelden kann die Sicherheit auf Zeilenebene (RLS) und/oder die Sicherheit auf Objektebene (OBJECT-Level Security, OLS) in der Datenquelle implementiert werden. Auf diese Weise können Benutzer nur Daten anzeigen, auf die sie über Berechtigungen für den Zugriff verfügen. Wenn die Verbindung mit Datenquellen in der Cloud besteht, wird die Microsoft Entra-Authentifizierung für einmaliges Anmelden verwendet. für lokale Datenquellen, Kerberos, Security Assertion Markup Language (SAML) und Microsoft Entra ID werden unterstützt.

Wenn die Datenquelle Azure Analysis Services oder lokale Analysis Services ist und RLS und/oder OLS konfiguriert ist, wendet der Power BI-Dienst diese Sicherheitsstufe an, und Benutzer, die nicht über ausreichende Anmeldeinformationen für den Zugriff auf die zugrunde liegenden Daten verfügen (dies könnte eine Abfrage sein, die in einem Dashboard, Bericht oder anderen Datenartefakt verwendet wird), werden keine Daten angezeigt, für die sie nicht über ausreichende Berechtigungen verfügen.

Premium-Features

Dataflows-Architektur

Dataflows bieten Benutzern die Möglichkeit, Back-End-Datenverarbeitungsvorgänge zu konfigurieren, die Daten aus polymorphen Datenquellen extrahieren, Transformationslogik für die Daten ausführen und es dann in ein Zielmodell für die Verwendung in verschiedenen Berichtspräsentationstechnologien bringen. Jeder Benutzer, der entweder über eine Rolle "Mitglied", "Mitwirkender" oder "Administrator" in einem Arbeitsbereich verfügt, erstellt möglicherweise einen Datenfluss. Benutzer in der Viewer-Rolle können Daten anzeigen, die vom Datenfluss verarbeitet werden, jedoch keine Änderungen an der Komposition vornehmen. Nachdem ein Datenfluss erstellt wurde, kann jedes Mitglied, jeder Mitwirkende oder ein Administrator des Arbeitsbereichs Aktualisierungen planen sowie den Datenfluss anzeigen und bearbeiten, indem er den Besitz übernimmt.

Jede konfigurierte Datenquelle ist an eine Clienttechnologie für den Zugriff auf diese Datenquelle gebunden. Die Struktur der anmeldeinformationen, die für den Zugriff erforderlich sind, wird so gebildet, dass sie den erforderlichen Implementierungsdetails der Datenquelle entsprechen. Die Transformationslogik wird von Power Query-Diensten angewendet, während die Daten übertragen werden. Bei Premium-Datenflüssen werden Power Query-Dienste in Back-End-Knoten ausgeführt. Daten können direkt aus den Cloudquellen oder über ein lokal installiertes Gateway abgerufen werden. Wenn der Transport direkt von einer Cloudquelle an den Dienst oder an das Gateway abgerufen wird, verwendet der Transport gegebenenfalls spezifische Schutzmethodik für die Clienttechnologie. Wenn Daten vom Gateway an den Clouddienst übertragen werden, wird sie verschlüsselt. Siehe oben den Abschnitt "Daten während der Übertragung ".

Wenn vom Kunden angegebene Datenquellen Anmeldeinformationen für den Zugriff benötigen, stellt der Besitzer/Ersteller des Datenflusses diese während der Erstellung bereit. Sie werden mithilfe des standardmäßigen produktweiten Anmeldeinformationsspeichers gespeichert. Siehe "Authentifizierung für Datenquellen oben". Es gibt verschiedene Ansätze, die Benutzer konfigurieren können, um die Datenpersistenz und den Zugriff zu optimieren. Standardmäßig werden die Daten in einem power BI-eigenen und geschützten Speicherkonto gespeichert. Die Speicherverschlüsselung ist in den Blob-Speichercontainern aktiviert, um die Daten zu schützen, während sie ruhen. Siehe Ruhende Daten weiter unten. Benutzer können jedoch ihr eigenes Speicherkonto konfigurieren, das ihrem eigenen Azure-Abonnement zugeordnet ist. Auf diese Weise erhält ein Power BI-Dienstprinzipal Zugriff auf dieses Speicherkonto, sodass die Daten während der Aktualisierung dort geschrieben werden können. In diesem Fall ist der Besitzer der Speicherressource für die Konfiguration der Verschlüsselung für das konfigurierte Azure Data Lake Storage-Konto verantwortlich. Daten werden immer mithilfe der Verschlüsselung an Blob Storage übertragen.

Da die Leistung beim Zugriff auf Speicherkonten für einige Daten möglicherweise suboptimal ist, haben Benutzer auch die Möglichkeit, ein von Power BI gehostetes Computemodul zu verwenden, um die Leistung zu erhöhen. In diesem Fall werden Daten redundant in einer SQL-Datenbank gespeichert, die für DirectQuery über den Zugriff über das Back-End-Power BI-System verfügbar ist. Daten werden immer im Dateisystem verschlüsselt. Wenn der Benutzer einen Schlüssel zum Verschlüsseln der in der SQL-Datenbank gespeicherten Daten bereitstellt, wird dieser Schlüssel verwendet, um sie doppelt zu verschlüsseln.

Beim Abfragen mithilfe von DirectQuery wird das verschlüsselte Transportprotokoll HTTPS für den Zugriff auf die API verwendet. Alle sekundären oder indirekten Verwendung von DirectQuery werden von den zuvor beschriebenen Zugriffssteuerelementen gesteuert. Da Datenflüsse immer an einen Arbeitsbereich gebunden sind, wird der Zugriff auf die Daten immer von der Rolle des Benutzers in diesem Arbeitsbereich abgegrenzt. Ein Benutzer muss mindestens Lesezugriff haben, um die Daten auf beliebige Weise abfragen zu können.

Wenn Power BI Desktop für den Zugriff auf Daten in einem Datenfluss verwendet wird, muss er zuerst den Benutzer mithilfe der Microsoft Entra-ID authentifizieren, um festzustellen, ob der Benutzer über ausreichende Rechte zum Anzeigen der Daten verfügt. Wenn ja, wird ein SaS-Schlüssel erworben und verwendet, um direkt über das verschlüsselte Transportprotokoll HTTPS auf den Speicher zuzugreifen.

Die Verarbeitung von Daten in der gesamten Pipeline generiert Office 365-Überwachungsereignisse. Einige dieser Ereignisse erfassen Vorgänge im Zusammenhang mit Sicherheit und Datenschutz.

Paginierte Berichte

Paginierte Berichte sind so konzipiert, dass sie gedruckt oder freigegeben werden. Sie werden als paginierte bezeichnet, da sie so formatiert sind, dass sie gut auf eine Seite passen. Sie zeigen alle Daten in einer Tabelle an, auch wenn sich die Tabelle über mehrere Seiten erstreckt. Sie können das Layout der Berichtsseite genau steuern.

Paginierte Berichte unterstützen umfangreiche und leistungsstarke Ausdrücke, die in Microsoft Visual Basic .NET geschrieben wurden. Ausdrücke werden im Power BI-Berichts-Generator für paginierte Berichte häufig verwendet, um Daten abzurufen, berechnen, anzeigen, gruppieren, sortieren, filtern, parametrieren und formatieren.

Ausdrücke werden vom Autor des Berichts mit Zugriff auf die breite Palette von Features von .NET Framework erstellt. Die Verarbeitung und Ausführung von paginierten Berichten wird in einem Sandkasten ausgeführt.

Paginierte Berichtsdefinitionen (.rdl) werden in Power BI gespeichert. Um einen paginierten Bericht zu veröffentlichen und/oder zu rendern, muss sich ein Benutzer authentifizieren und autorisieren, und zwar auf die gleiche Weise, wie es in der Authentifizierung beim Power BI-Dienst beschrieben ist.

Das während der Authentifizierung abgerufene Microsoft Entra-Token wird verwendet, um direkt vom Browser zum Power BI Premium-Cluster zu kommunizieren.

In Power BI Premium stellt Power BI-Dienstlaufzeit eine entsprechend isolierte Ausführungsumgebung für jede Berichtausführung bereit. Dies schließt Fälle ein, in denen die gerenderten Berichte zu Arbeitsbereichen gehören, die derselben Kapazität zugeordnet sind.

Ein paginierter Bericht kann im Rahmen des Renderns des Berichts auf eine vielzahl Datenquellen zugreifen. Der Sandkasten kommuniziert nicht direkt mit einer der Datenquellen, sondern kommuniziert mit dem vertrauenswürdigen Prozess, um Daten anzufordern, und dann fügt der vertrauenswürdige Prozess die erforderlichen Anmeldeinformationen an die Verbindung an. Auf diese Weise hat die Sandbox nie Zugriff auf Anmeldeinformationen oder geheime Schlüssel.

Um Features wie Bing Maps oder Aufrufe von Azure Functions zu unterstützen, hat der Sandkasten Zugriff auf das Internet.

Power BI Embedded Analytics

Unabhängige Softwareanbieter (ISVs) und Lösungsanbieter verfügen über zwei Hauptmodi zum Einbetten von Power BI-Artefakten in ihre Webanwendungen und Portale: Einbetten für Ihre Organisation und Einbettung für Ihre Kunden. Das Artefakt wird in einen IFrame in der Anwendung oder im Portal eingebettet. Ein IFrame darf keine Daten aus der externen Webanwendung oder dem externen Portal lesen oder schreiben, und die Kommunikation mit dem IFrame erfolgt mithilfe des Power BI Client SDK mithilfe von POST-Nachrichten.

In einer Einbettung für Ihr Organisationsszenario greifen Microsoft Entra-Benutzer über Portale, die von ihren Unternehmen und ITs angepasst wurden, auf ihre eigenen Power BI-Inhalte zu. Alle in diesem Dokument beschriebenen Power BI-Richtlinien und -Funktionen wie RLS und OLS werden automatisch auf alle Benutzer angewendet, unabhängig davon, ob sie über das Power BI-Portal oder über angepasste Portale auf Power BI zugreifen.

In einem Einbettungsszenario für Ihre Kunden besitzen ISVs normalerweise eigene Power BI-Mandanten und Power BI-Elemente (Dashboards, Berichte, semantische Modelle und andere). Es liegt in der Verantwortung eines ISV-Back-End-Diensts, seine Endbenutzer zu authentifizieren und zu entscheiden, welche Artefakte und welche Zugriffsebene für diesen Endbenutzer geeignet ist. ISV-Richtlinienentscheidungen werden in einem von Power BI generierten Einbettungstoken verschlüsselt und an das ISV-Back-End zur weiteren Verteilung an die Endbenutzer gemäß der Geschäftslogik des ISV übergeben. Endbenutzer, die einen Browser oder andere Clientanwendungen verwenden, können Einbettungstoken nicht entschlüsseln oder ändern. Clientseitige SDKs wie Power BI-Client-APIs hängen das verschlüsselte Einbettungstoken automatisch als Authorization: EmbedToken-Header an Power BI-Anforderungen an. Basierend auf dieser Überschrift wird Power BI alle Richtlinien (wie Zugriffs- oder RLS-Richtlinien) genau so durchsetzen, wie dies von der ISV bei der Erstellung vorgegeben wurde.

Um Einbettung und Automatisierung zu aktivieren und die oben beschriebenen Einbettungstoken zu generieren, macht Power BI eine umfangreiche Gruppe von REST-APIs verfügbar. Diese Power BI-REST-APIs unterstützen sowohl benutzerdelegierte als auch dienstprinzipale Microsoft Entra-Methoden der Authentifizierung und Autorisierung.

Eingebettete Power BI-Analysen und ihre REST-APIs unterstützen alle in diesem Artikel beschriebenen Power BI-Netzwerkisolationsfunktionen, einschließlich Diensttags und private Links.

KI-Funktionen

Power BI unterstützt derzeit zwei allgemeine Kategorien von KI-Features im Produkt: KI-Visualisierungen und KI-Anreicherungen. Zu den KI-Funktionen auf visueller Ebene gehören Funktionen wie Key Influencer, Decomposition Tree, Smart Narrative, Anomalieerkennung, R-Visualisierung, Python-Visualisierung, Clustering, Forecasting, Q&A, Quick Insights usw. Zu den KI-Anreicherungsfunktionen gehören Funktionen wie AutoML, Azure Machine Learning, CognitiveServices, R/Python-Transformationen usw.

Die meisten der oben genannten Features werden heute sowohl in freigegebenen als auch in Premium-Arbeitsbereichen unterstützt. AutoML und CognitiveServices werden jedoch nur in Premium-Arbeitsbereichen unterstützt, aufgrund von IP-Einschränkungen. Mit der AutoML-Integration in Power BI kann ein Benutzer ein benutzerdefiniertes ML-Modell (z. B. Vorhersage, Klassifizierung, Regression usw.) erstellen und trainieren und anwenden, um Vorhersagen zu erhalten, während Daten in einen in einem Premium-Arbeitsbereich definierten Datenfluss geladen werden. Darüber hinaus können Power BI-Benutzer mehrere CognitiveServices-APIs wie TextAnalytics und ImageTagging anwenden, um Daten zu transformieren, bevor sie in ein in einem Premium-Arbeitsbereich definiertes Datenfluss-/Semantikmodell geladen werden.

Die Premium-AI-Anreicherungsfunktionen können am besten als eine Sammlung zustandsloser KI-Funktionen und -Transformationen angesehen werden, die von Power BI-Nutzern in ihren Datenintegrationspipelines verwendet werden, welche von einem Power BI-Semantikmodell oder einem Datenfluss genutzt werden. Beachten Sie, dass auf diese Funktionen auch über aktuelle Datenfluss-/Semantikmodellerstellungsumgebungen im Power BI-Dienst und Power BI Desktop zugegriffen werden kann. Diese KI-Funktionen/Transformationen werden immer in einem Premium-Arbeitsbereich/einer Premium-Kapazität ausgeführt. Diese Funktionen werden in Power BI als Datenquelle angezeigt, die ein Microsoft Entra-Token für den Power BI-Benutzer erfordert, der die KI-Funktion verwendet. Diese KI-Datenquellen sind besonders, da sie keine eigenen Daten darstellen und nur diese Funktionen/Transformationen bereitstellen. Während der Ausführung führen diese Features keine ausgehenden Anrufe an andere Dienste durch, um die Daten des Kunden zu übertragen. Sehen wir uns die Premium-Szenarien einzeln an, um die Kommunikationsmuster und relevanten sicherheitsrelevanten Details zu verstehen, die sie betreffen.

Zur Schulung und Anwendung eines AutoML-Modells verwendet Power BI das Azure AutoML SDK und führt alle Schulungen in der Power BI-Kapazität des Kunden aus. Während der Schulungsdurchläufe ruft Power BI einen Azure Machine Learning-Dienst auf, um ein geeignetes Modell und Hyperparameter für die aktuelle Iteration auszuwählen. In diesem ausgehenden Aufruf werden nur relevante Experimentmetadaten (z. B. Genauigkeit, ML-Algorithmus, Algorithmusparameter usw.) aus der vorherigen Iteration gesendet. Die AutoML-Schulung erzeugt ein ONNX-Modell und Schulungsberichtsdaten, die dann im Datenfluss gespeichert werden. Später können Power BI-Benutzer dann das trainierte ML-Modell als Transformation anwenden, um das ML-Modell auf geplanter Basis zu operationalisieren. Für TextAnalytics- und ImageTagging-APIs ruft Power BI nicht direkt die CognitiveServices-Dienst-APIs auf, sondern verwendet stattdessen ein internes SDK, um die APIs in der Power BI Premium-Kapazität auszuführen. Heute werden diese APIs sowohl in Power BI-Datenflüssen als auch in semantischen Modellen unterstützt. Beim Erstellen eines Datenmodells in Power BI Desktop können Benutzer nur dann auf diese Funktionalität zugreifen, wenn sie Zugriff auf einen Premium Power BI-Arbeitsbereich haben. Daher werden Kunden aufgefordert, ihre Microsoft Entra-Anmeldeinformationen anzugeben.

Netzwerkisolation

In diesem Abschnitt werden erweiterte Sicherheitsfeatures in Power BI beschrieben. Einige der Features weisen spezifische Lizenzierungsanforderungen auf. Ausführliche Informationen finden Sie in den folgenden Abschnitten.

Diensttags

Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen aus einem bestimmten Azure-Dienst. Dies trägt dazu bei, die Komplexität häufiger Updates für Netzwerksicherheitsregeln zu minimieren. Kunden können Diensttags verwenden, um Netzwerkzugriffssteuerungen für Netzwerksicherheitsgruppen oder Azure Firewall zu definieren. Kunden können Diensttags anstelle bestimmter IP-Adressen verwenden, wenn Sicherheitsregeln erstellt werden. Durch die Angabe des Diensttag-Namens (z. B. PowerBI) im entsprechenden Quell- oder Zielangabefeld (für APIs) einer Regel können Kunden den Datenverkehr des entsprechenden Dienstes zulassen oder verweigern. Microsoft verwaltet die Adresspräfixe, die von der Dienstmarke umfasst werden, und aktualisiert die Dienstmarke automatisch, wenn sich die Adressen ändern.

Integration von privaten Links

Azure Networking bietet das Azure Private Link-Feature, mit dem Power BI sicheren Zugriff über private Azure Networking-Endpunkte bereitstellen kann. Mit Azure Private Link und privaten Endpunkten wird der Datenverkehr privat über die Backbone-Netzwerkinfrastruktur von Microsoft gesendet, und die Daten durchlaufen daher nicht das Internet.

Private Link stellt sicher, dass Power BI-Benutzer das Backbone des privaten Microsoft-Netzwerks verwenden, wenn Sie zu Ressourcen im Power BI-Dienst wechseln.

Die Verwendung von privatem Link mit Power BI bietet die folgenden Vorteile:

• Private Link stellt sicher, dass Datenverkehr über das Azure-Backbone zu einem privaten Endpunkt für cloudbasierte Azure-Ressourcen fließt.
• Die Netzwerkdatenverkehrisolation von einer nicht azurebasierten Infrastruktur, z. B. lokalem Zugriff, erfordert, dass Kunden ExpressRoute oder ein VPN konfiguriert haben.

Weitere Informationen finden Sie unter Private Links für sicheren Zugriff auf Fabric.

VNet-Konnektivität

Während das Integrationsfeature für private Links sichere eingehende Verbindungen mit Power BI bereitstellt, ermöglicht das VNet-Konnektivitätsfeature sichere ausgehende Verbindungen von Power BI zu Datenquellen innerhalb eines VNet.

VNet-Gateways (von Microsoft verwaltet) vermeiden den Aufwand für die Installation und Überwachung lokaler Datengateways zum Herstellen einer Verbindung mit Datenquellen, die einem VNet zugeordnet sind. Sie folgen jedoch weiterhin dem vertrauten Prozess der Verwaltung von Sicherheit und Datenquellen, wie bei einem lokalen Datengateway.

Im Folgenden finden Sie eine Übersicht darüber, was passiert, wenn Sie mit einem Power BI-Bericht interagieren, der mit einer Datenquelle innerhalb eines VNet über VNet-Gateways verbunden ist:

1. Der Power BI-Clouddienst (oder einer der anderen unterstützten Clouddienste) startet eine Abfrage und sendet die Abfrage, Datenquellendetails und Anmeldeinformationen an den Power Platform VNet (PP VNet)-Dienst.

2. Der PP-VNet-Dienst injiziert dann sicher einen Container mit einem VNet-Gateway in das Subnetz. Dieser Container kann jetzt eine Verbindung mit Datendiensten herstellen, auf die innerhalb dieses Subnetzes zugegriffen werden kann.

3. Der PP-VNet-Dienst sendet dann die Abfrage, Datenquellendetails und Anmeldeinformationen an das VNet-Gateway.

4. Das VNet-Gateway erhält die Abfrage und verbindet sich mit den Datenquellen anhand dieser Anmeldeinformationen.

5. Die Abfrage wird dann zur Ausführung an die Datenquelle gesendet.

6. Nach der Ausführung werden die Ergebnisse an das VNet-Gateway gesendet, und der PP-VNet-Dienst verschiebt die Daten sicher vom Container an den Power BI-Clouddienst.

Dienstprinzipale

Power BI unterstützt die Verwendung von Dienstprinzipalen. Speichern Sie alle Dienstprinzipal-Credentials, die zum Verschlüsseln oder Zugreifen auf Power BI in einem Key Vault verwendet werden, weisen Sie dem Tresor geeignete Zugriffsrichtlinien zu und überprüfen Sie regelmäßig Zugriffsberechtigungen.

Weitere Details finden Sie unter Automatisierte Aufgaben des Premium-Arbeitsbereichs und des semantischen Modells mit Dienstprinzipalen.

Microsoft Purview für Power BI

Microsoft Purview Informationsschutz

Power BI ist tief in Microsoft Purview Information Protection integriert. Microsoft Purview Information Protection ermöglicht Organisationen eine einzige, integrierte Lösung für Klassifizierung, Bezeichnung, Überwachung und Compliance in Azure, Power BI und Office.

Wenn der Informationsschutz in Power BI aktiviert ist:

• Vertrauliche Daten, sowohl im Power BI-Dienst als auch in Power BI Desktop, können mit den gleichen Vertraulichkeitsbezeichnungen klassifiziert und bezeichnet werden, die in Office und in Azure verwendet werden.
• Governancerichtlinien können erzwungen werden, wenn Power BI-Inhalte in Excel-, PowerPoint-, PDF-, Word- oder PBIX-Dateien exportiert werden, um sicherzustellen, dass Daten geschützt werden, auch wenn Sie Power BI verlassen.
• Es ist einfach, PBIX-Dateien in Power BI Desktop zu klassifizieren und zu schützen, genau wie in Excel-, Word- und PowerPoint-Anwendungen. Dateien können auf einfache Weise entsprechend ihrer Vertraulichkeitsstufe kategorisiert werden. Darüber hinaus können sie verschlüsselt werden, wenn sie geschäftsrelevante Daten enthalten und sicherstellen, dass nur autorisierte Benutzer diese Dateien bearbeiten können.
• Excel-Arbeitsmappen übernehmen automatisch Sensitivitätsbezeichnungen, wenn sie eine Verbindung mit Power BI herstellen. Dadurch wird eine durchgängige Klassifizierung beibehalten und Schutz angewendet, wenn Power BI-Semantikmodelle in Excel analysiert werden.
• Vertraulichkeitsbezeichnungen, die auf Power BI-Berichte und Dashboards angewendet werden, sind in den mobilen Power BI- und Android-Apps sichtbar.
• Vertraulichkeitsbezeichnungen bleiben erhalten, wenn ein Power BI-Bericht in Teams, SharePoint oder eine sichere Website eingebettet ist. Dadurch können Organisationen beim Einbetten von Power BI-Inhalten Klassifizierung und Schutz beim Export beibehalten.
• Die Bezeichnungsvererbung beim Erstellen neuer Inhalte im Power BI-Dienst stellt sicher, dass Bezeichnungen, die auf semantische Modelle oder Datenmarts im Power BI-Dienst angewendet werden, auf neue Inhalte angewendet werden, die über diese semantischen Modelle und Datamarts erstellt wurden.
• Power BI-Administratorscan-APIs können die Vertraulichkeitsbezeichnung eines Power BI-Elements extrahieren, sodass Power BI- und InfoSec-Administratoren die Bezeichnung im Power BI-Dienst überwachen und Geschäftsleitungsberichte erstellen können.
• Power BI-Administrator-APIs ermöglichen es zentralen Teams, Vertraulichkeitsbezeichnungen programmgesteuert auf Inhalte im Power BI-Dienst anzuwenden.
• Zentrale Teams können obligatorische Bezeichnungsrichtlinien erstellen, um das Anwenden von Bezeichnungen auf neuen oder bearbeiteten Inhalten in Power BI zu erzwingen.
• Zentrale Teams können Standardbezeichnungsrichtlinien erstellen, um sicherzustellen, dass eine Vertraulichkeitsbezeichnung auf alle neuen oder geänderten Power BI-Inhalte angewendet wird.
• Automatische nachgeschaltete Sensitivitätskennzeichnung im Power BI-Dienst stellt sicher, dass beim Anwenden oder Ändern einer Kennzeichnung auf ein semantisches Modell oder Datamart die Kennzeichnung automatisch auf alle damit verbundenen nachgeschalteten Inhalte angewendet oder geändert wird.

Weitere Informationen finden Sie unter Vertraulichkeitsbezeichnungen in Power BI.

Microsoft Purview Data Loss Prevention (DLP)-Richtlinien für Power BI

Die Richtlinien von Microsoft Purview (Data Loss Prevention, DLP) helfen Organisationen, das Risiko vertraulicher Geschäftsdatenlecks aus Power BI zu verringern. DLP-Richtlinien helfen ihnen dabei, die Compliance-Anforderungen von Behörden- oder Branchenbestimmungen zu erfüllen, z. B. die Datenschutz-Grundverordnung (DSGVO) der Europäischen Union oder das California Consumer Privacy Act (CCPA), und stellen Sie sicher, dass ihre Daten in Power BI verwaltet werden.

Wenn DLP-Richtlinien für Power BI eingerichtet sind:

• Alle semantischen Modelle innerhalb der in der Richtlinie angegebenen Arbeitsbereiche werden von der Richtlinie ausgewertet.
• Sie können erkennen, wann vertrauliche Daten in Ihre Premium-Kapazitäten hochgeladen werden. DLP-Richtlinien können Folgendes erkennen:
  • Vertraulichkeitsetiketten.
  • Typen vertraulicher Informationen. Mehr als 260 Typen werden unterstützt. Die Erkennung vertraulicher Informationen basiert auf der Inhaltsüberprüfung von Microsoft Purview.
• Wenn Sie auf ein semantisches Modell stoßen, das als vertraulich identifiziert wird, können Sie einen angepassten Richtlinientipp sehen, der Ihnen hilft, zu verstehen, was Sie tun sollten.
• Wenn Sie ein Semantikmodellbesitzer sind, können Sie eine Richtlinie außer Kraft setzen und verhindern, dass Ihr semantisches Modell als "vertraulich" identifiziert wird, wenn Sie einen gültigen Grund dafür haben.
• Wenn Sie ein Semantikmodellbesitzer sind, können Sie ein Problem mit einer Richtlinie melden, wenn Sie schließen, dass ein vertraulicher Informationstyp falsch identifiziert wurde.
• Automatische Risikominderungen, z. B. Warnungen an den Sicherheitsadministrator, können aufgerufen werden.

Weitere Informationen finden Sie unter Richtlinien zur Verhinderung von Datenverlust für Fabric und Power BI.

Microsoft Defender für Cloud-Apps für Power BI

Microsoft Defender für Cloud Apps ist einer der weltweit führenden Cloud-Zugriffssicherheitsbroker, der als Führendes in Gartners Magic Quadrant für den Markt für cloudzugriffssicherheitsbroker (CASB) bezeichnet wird. Defender für Cloud-Apps wird verwendet, um die Verwendung von Cloud-Apps zu sichern. Es ermöglicht Organisationen, riskante Power BI-Sitzungen, wie den Benutzerzugriff von nicht verwalteten Geräten, in Echtzeit zu überwachen und zu steuern. Sicherheitsadministratoren können Richtlinien definieren, um Benutzeraktionen zu steuern, z. B. das Herunterladen von Berichten mit vertraulichen Informationen.

Mit Defender für Cloud-Apps können Organisationen die folgenden DLP-Funktionen erhalten:

• Legen Sie Echtzeitsteuerelemente fest, um riskante Benutzersitzungen in Power BI zu erzwingen. Wenn ein Benutzer beispielsweise eine Verbindung mit Power BI von außerhalb seines Landes oder seiner Region herstellt, kann die Sitzung von den Echtzeitsteuerelementen von Defender für Cloud Apps überwacht werden, und riskante Aktionen, z. B. das Herunterladen von Daten, die mit einer Vertraulichkeitsbezeichnung "Streng vertraulich" gekennzeichnet sind, können sofort blockiert werden.
• Untersuchen Sie die Aktivitäten von Power BI-Benutzern mit dem Aktivitätsprotokoll von Defender for Cloud Apps. Das Defender for Cloud Apps-Aktivitätsprotokoll enthält Power BI-Aktivitäten, die im Office 365-Überwachungsprotokoll erfasst werden, das Informationen zu allen Benutzer- und Administratoraktivitäten sowie Vertraulichkeitsbezeichnungsinformationen für relevante Aktivitäten enthält, z. B. Anwenden, Ändern und Entfernen der Bezeichnung. Administratoren können die erweiterten Filter von Defender für Cloud Apps und schnelle Aktionen für eine effektive Problemuntersuchung nutzen.
• Erstellen Sie benutzerdefinierte Richtlinien, um verdächtige Benutzeraktivitäten in Power BI zu benachrichtigen. Das Feature "Defender for Cloud Apps-Aktivitätsrichtlinien" kann verwendet werden, um Ihre eigenen benutzerdefinierten Regeln zu definieren, um das Benutzerverhalten zu erkennen, das von der Norm abweicht, und sogar möglicherweise automatisch darauf reagieren, wenn es zu gefährlich erscheint.
• Arbeiten Sie mit der integrierten Anomalieerkennung von Defender for Cloud Apps. Die Anomalieerkennungsrichtlinien für Defender für Cloud-Apps bieten sofort einsatzbereite Benutzerverhaltensanalysen und maschinelles Lernen, sodass Sie von Anfang an bereit sind, erweiterte Bedrohungserkennung in Ihrer Cloudumgebung auszuführen. Wenn eine Anomalieerkennungsrichtlinie ein verdächtiges Verhalten identifiziert, löst sie eine Sicherheitswarnung aus.
• Power BI-Administratorrolle im Defender for Cloud Apps-Portal. Defender für Cloud-Apps bietet eine appspezifische Administratorrolle, die verwendet werden kann, um Power BI-Administratoren nur die Berechtigungen zu erteilen, die sie für den Zugriff auf Power BI-relevante Daten im Portal benötigen, z. B. Warnungen, Risikobenutzer, Aktivitätsprotokolle und andere Power BI-bezogene Informationen.

Weitere Informationen finden Sie unter Verwenden von Microsoft Defender für Cloud Apps-Steuerelementen in Power BI.

Power BI-Sicherheitsfragen und -antworten

Die folgenden Fragen sind allgemeine Sicherheitsfragen und Antworten auf Power BI. Diese werden basierend auf dem Zeitpunkt organisiert, an dem sie diesem Whitepaper hinzugefügt wurden, um Ihre Fähigkeit zu erleichtern, neue Fragen und Antworten schnell zu finden, wenn dieses Dokument aktualisiert wird. Die neuesten Fragen werden am Ende dieser Liste hinzugefügt.

Wie können Benutzer eine Verbindung herstellen und während der Verwendung von Power BI Zugriff auf Datenquellen erhalten?

• Power BI verwaltet Anmeldeinformationen zu Datenquellen für jeden Benutzer für Cloud-Anmeldeinformationen oder für die Konnektivität über ein persönliches Gateway. Datenquellen, die von einem lokalen Datengateway verwaltet werden, können unternehmensweit freigegeben werden, und Berechtigungen für diese Datenquellen können vom Gatewayadministrator verwaltet werden. Beim Konfigurieren eines Semantikmodells kann der Benutzer eine Anmeldeinformation aus dem persönlichen Speicher auswählen oder ein lokales Datengateway verwenden, um eine freigegebene Anmeldeinformation zu verwenden.

  Im Importfall stellt ein Benutzer eine Verbindung basierend auf der Anmeldung des Benutzers her und greift auf die Daten mit den Anmeldeinformationen zu. Nachdem das semantische Modell im Power BI-Dienst veröffentlicht wurde, verwendet Power BI immer die Anmeldeinformationen dieses Benutzers, um Daten zu importieren. Nachdem Daten importiert wurden, greift das Anzeigen der Daten in Berichten und Dashboards nicht auf die zugrunde liegende Datenquelle zu. Power BI unterstützt die Single Sign-On-Authentifizierung für ausgewählte Datenquellen. Wenn die Verbindung für die Verwendung von Single Sign-On konfiguriert ist, wird die Anmeldeinformation des semantischen Modellbesitzers verwendet, um eine Verbindung mit der Datenquelle herzustellen.

  Für Berichte, die mit DirectQuery verbunden sind, wird die Datenquelle direkt mit einer vorkonfigurierten Anmeldeinformation verbunden. Die vorkonfigurierten Anmeldeinformationen werden verwendet, um eine Verbindung mit der Datenquelle herzustellen, wenn beliebige Benutzer die Daten einsehen. Wenn eine Datenquelle direkt über einmaliges Anmelden verbunden ist, werden die Anmeldeinformationen des aktuellen Benutzers verwendet, um eine Verbindung mit der Datenquelle herzustellen, wenn der Benutzer die Daten anzeigt. Bei Verwendung mit einmaligem Anmelden können RLS und/oder OLS in der Datenquelle implementiert werden, und dadurch können Benutzer Daten anzeigen, auf die sie Über Berechtigungen für den Zugriff verfügen. Wenn die Verbindung mit Datenquellen in der Cloud besteht, wird die Microsoft Entra-Authentifizierung für einmaliges Anmelden verwendet. für lokale Datenquellen, Kerberos, SAML und Microsoft Entra ID werden unterstützt.

  Beim Herstellen einer Verbindung mit Kerberos wird der UPN des Benutzers an das Gateway übergeben. Mithilfe der eingeschränkten Delegierung von Kerberos wird der Benutzer nachgeahmt und mit den entsprechenden Datenquellen verbunden. SAML wird auch auf dem Gateway für SAP HANA-Datenquelle unterstützt. Weitere Informationen finden Sie in der Übersicht über einmaliges Anmelden für Gateways.

  Wenn die Datenquelle Azure Analysis Services oder lokale Analysis Services und/oder RLS und/oder OLS konfiguriert ist, wendet der Power BI-Dienst diese Sicherheitsstufe an, und Benutzer, die nicht über ausreichende Anmeldeinformationen verfügen, um auf die zugrunde liegenden Daten zuzugreifen (dies könnte eine Abfrage sein, die in einem Dashboard, Bericht oder anderen Datenartefakt verwendet wird), werden keine Daten angezeigt, für die der Benutzer nicht über ausreichende Berechtigungen verfügt.

  RLS mit Power BI können verwendet werden, um den Datenzugriff für bestimmte Benutzer einzuschränken. Filter beschränken den Datenzugriff auf Zeilenebene, und Sie können Filter innerhalb einer Rolle definieren.

  OLS kann verwendet werden, um vertrauliche Tabellen oder Spalten zu schützen. Im Gegensatz zu RLS sichert OLS jedoch auch Objektnamen und Metadaten. Dadurch wird verhindert, dass böswillige Benutzer sogar das Vorhandensein solcher Objekte entdecken. Gesicherte Tabellen und Spalten werden in der Feldliste verdeckt, wenn Berichtstools wie Excel oder Power BI verwendet werden, und darüber hinaus können Benutzer ohne Berechtigungen nicht über DAX oder eine andere Methode auf gesicherte Metadatenobjekte zugreifen. Aus Sicht der Benutzer ohne ordnungsgemäße Zugriffsberechtigungen sind geschützte Tabellen und Spalten einfach nicht vorhanden.

  OLS ermöglicht zusammen mit RLS erweiterte Sicherheit auf Unternehmensniveau für Berichte und semantische Modelle, um sicherzustellen, dass nur Benutzer mit den erforderlichen Berechtigungen Zugriff auf die Anzeige und Interaktion mit vertraulichen Daten haben.

Wie werden Daten an Power BI übertragen?

• Alle von Power BI angeforderten und übertragenen Daten werden mit HTTPS verschlüsselt (außer wenn die vom Kunden ausgewählte Datenquelle HTTPS nicht unterstützt), um eine Verbindung von der Datenquelle mit dem Power BI-Dienst herzustellen. Es wird eine sichere Verbindung mit dem Datenanbieter hergestellt, und nur wenn diese Verbindung hergestellt wird, durchläuft die Daten das Netzwerk.

Wie speichert Power BI Bericht-, Dashboard- oder Modelldaten im Cache, und ist das sicher?

• Wenn auf eine Datenquelle zugegriffen wird, folgt der Power BI-Dienst dem in der Authentifizierung für Datenquellen beschriebenen Prozess.

Speichern Clients Webseitendaten lokal zwischen?

• Wenn Browserclients auf Power BI zugreifen, legen die Power BI-Webserver die Cache-Control-Direktive auf "no-store" fest. Die No-Store-Direktive weist Browser an, die vom Benutzer angezeigte Webseite nicht zwischenzuspeichern und die Webseite nicht im Cacheordner des Clients zu speichern.

Was ist mit rollenbasierter Sicherheit, dem Teilen von Berichten und Dashboards sowie Datenverbindungen? Wie funktioniert dies im Hinblick auf Datenzugriff, Dashboardanzeige, Berichtszugriff oder Aktualisierung?

• Für nicht RLS-fähige Datenquellen, wenn ein Dashboard, ein Bericht oder ein Datenmodell für andere Benutzer über Power BI freigegeben wird, sind die Daten dann für Benutzer verfügbar, mit denen sie geteilt werden, um sie anzuzeigen und mit ihnen zu interagieren. Power BI authentifiziert Benutzer nicht erneut mit der ursprünglichen Quelle der Daten. sobald Daten in Power BI hochgeladen wurden, ist der Benutzer, der sich für die Quelldaten authentifiziert hat, verantwortlich für die Verwaltung, welche anderen Benutzer und Gruppen die Daten anzeigen können.

  Wenn Datenverbindungen mit einer RLS-fähigen Datenquelle hergestellt werden, z. B. einer Analysis Services-Datenquelle, werden nur Dashboarddaten in Power BI zwischengespeichert. Jedes Mal, wenn ein Bericht oder semantisches Modell in Power BI angezeigt oder aufgerufen wird, auf das Daten aus der RLS-fähigen Datenquelle verwendet werden, greift der Power BI-Dienst auf die Datenquelle zu, um Daten basierend auf den Anmeldeinformationen des Benutzers abzurufen, und wenn ausreichende Berechtigungen vorhanden sind, werden die Daten in den Bericht oder das Datenmodell für diesen Benutzer geladen. Wenn die Authentifizierung fehlschlägt, wird dem Benutzer ein Fehler angezeigt.

  Weitere Informationen finden Sie unter Authentifizierung für Datenquellen.

Unsere Benutzer stellen immer eine Verbindung mit denselben Datenquellen her, von denen einige Anmeldeinformationen erfordern, die sich von ihren Domänenanmeldeinformationen unterscheiden. Wie können sie vermeiden, diese Anmeldeinformationen jedes Mal einzugeben, wenn sie eine Datenverbindung herstellen?

• Power BI bietet das persönliche Power BI-Gateway, ein Feature, mit dem Benutzer Anmeldeinformationen für mehrere verschiedene Datenquellen erstellen können, diese Anmeldeinformationen dann automatisch verwenden, wenn sie anschließend auf jede dieser Datenquellen zugreifen. Weitere Informationen finden Sie unter Verwenden eines persönlichen Gateways in Power BI.

Welche Ports werden von einem lokalen Datengateway und einem persönlichen Gateway verwendet? Gibt es Domänennamen, die für Verbindungszwecke zulässig sein müssen?

• Die ausführliche Antwort auf diese Frage ist im folgenden Artikel verfügbar: Anpassen der Kommunikationseinstellungen für das lokale Datengateway.

Wie werden Wiederherstellungsschlüssel verwendet, wenn Sie mit dem lokalen Datengateway arbeiten, und wo werden sie gespeichert? Was ist mit der sicheren Verwaltung von Anmeldeinformationen?

• Während der Gatewayinstallation und -konfiguration gibt der Administrator einen Gatewaywiederherstellungsschlüssel ein. Dieser Wiederherstellungsschlüssel wird verwendet, um einen starken symmetrischen AES-Schlüssel zu generieren. Gleichzeitig wird auch ein asymmetrischer RSA-Schlüssel erstellt.

  Diese generierten Schlüssel (RSA und AES) werden in einer Datei gespeichert, die sich auf dem lokalen Computer befindet. Diese Datei ist ebenfalls verschlüsselt. Der Inhalt der Datei kann nur von diesem bestimmten Windows-Computer und nur von diesem bestimmten Gatewaydienstkonto entschlüsselt werden.

  Wenn ein Benutzer Datenquellenanmeldeinformationen in die Power BI-Dienst-UI eingibt, werden die Anmeldeinformationen mit dem öffentlichen Schlüssel im Browser verschlüsselt. Das Gateway entschlüsselt die Anmeldeinformationen mithilfe des privaten RSA-Schlüssels und verschlüsselt sie erneut mit einem AES-symmetrischen Schlüssel, bevor die Daten im Power BI-Dienst gespeichert werden. Mit diesem Prozess hat der Power BI-Dienst nie Zugriff auf die unverschlüsselten Daten.

Welche Kommunikationsprotokolle werden vom lokalen Datengateway verwendet und wie werden sie gesichert?

• Das Gateway unterstützt die folgenden beiden Kommunikationsprotokolle:

  • AMQP 1.0 – TCP + TLS: Für ausgehende Kommunikation sind Ports 443, 5671-5672 und 9350-9354 erforderlich. Dieses Protokoll wird bevorzugt, da es weniger Kommunikationsaufwand hat.

  • HTTPS – WebSockets über HTTPS + TLS: Dieses Protokoll verwendet nur Port 443. Das WebSocket wird durch eine einzelne HTTP CONNECT-Nachricht initiiert. Sobald der Kanal eingerichtet wurde, ist die Kommunikation im Wesentlichen TCP+TLS. Sie können erzwingen, dass das Gateway dieses Protokoll verwendet, indem Sie eine einstellung ändern, die im Artikel zum lokalen Gateway beschrieben ist.

Welche Rolle spielt Azure CDN in Power BI?

• Wie bereits erwähnt, verwendet Power BI das Azure CDN, um die erforderlichen statischen Inhalte und Dateien effizient basierend auf geografischem Gebietsschema an Benutzer zu verteilen. Um ausführlicher zu gehen, verwendet der Power BI-Dienst mehrere CDNs, um die notwendigen statischen Inhalte und Dateien effizient über das öffentliche Internet an Benutzer zu verteilen. Zu diesen statischen Dateien gehören Produktdownloads (z. B. Power BI Desktop, das lokale Datengateway oder Power BI-Apps aus verschiedenen ISVs), Browserkonfigurationsdateien, die verwendet werden, um nachfolgende Verbindungen mit dem Power BI-Dienst zu initiieren und einzurichten sowie die erste sichere Power BI-Anmeldeseite.

  Basierend auf Informationen, die während einer anfänglichen Verbindung mit dem Power BI-Dienst bereitgestellt werden, kontaktiert der Browser eines Benutzers das angegebene Azure CDN (oder für einige Dateien, das WFE), um die Sammlung der angegebenen gemeinsamen Dateien herunterzuladen, die erforderlich sind, um die Interaktion des Browsers mit dem Power BI-Dienst zu ermöglichen. Die Browserseite enthält dann das Microsoft Entra-Token, Sitzungsinformationen, den Speicherort des zugeordneten Back-End-Clusters und die Sammlung von Dateien, die aus dem Azure CDN- und WFE-Cluster heruntergeladen wurden, für die Dauer der Power BI-Dienstbrowsersitzung.

Für visuelle Power BI-Elemente führt Microsoft vor dem Veröffentlichen von Elementen im Katalog eine Sicherheits- oder Datenschutzbewertung des benutzerdefinierten visuellen Codes durch?

• Nein. Es liegt in der Verantwortung des Kunden, zu überprüfen und zu bestimmen, ob benutzerdefinierter visueller Code aufgegriffen werden soll. Alle benutzerdefinierten visuellen Code werden in einer Sandkastenumgebung betrieben, sodass alle fehlerhaften Code in einer benutzerdefinierten visuellen Darstellung den Rest des Power BI-Diensts nicht beeinträchtigen.

Gibt es andere Visuelle Power BI-Elemente, die Informationen außerhalb des Kundennetzwerks senden?

• Ja. Bing Maps und ESRI-Visualisierungen übertragen Daten aus dem Power BI-Dienst für visuelle Elemente, die diese Dienste verwenden.

Führt Microsoft für Vorlagen-Apps vor dem Veröffentlichen von Elementen im Katalog eine Sicherheits- oder Datenschutzbewertung der Vorlagen-App durch?

• Nein. Der App-Herausgeber ist für den Inhalt verantwortlich, während es in der Verantwortung des Kunden liegt, den Herausgeber der Vorlagen-App zu überprüfen und dessen Vertrauenswürdigkeit zu bestimmen.

Gibt es Vorlagen-Apps, die Informationen außerhalb des Kundennetzwerks senden können?

• Ja. Es liegt in der Verantwortung des Kunden, die Datenschutzrichtlinie des Herausgebers zu überprüfen und zu bestimmen, ob die Vorlagen-App auf dem Mandanten installiert werden soll. Der Herausgeber ist dafür verantwortlich, den Kunden über das Verhalten und die Funktionen der App zu informieren.

Wie sieht es mit der Datenhoheit aus? Können wir Mandanten in Rechenzentren bereitstellen, die sich in bestimmten Regionen befinden, um sicherzustellen, dass Daten die Landes- oder Regionsgrenzen nicht verlassen?

• Einige Kunden in bestimmten Regionen haben die Möglichkeit, einen Mandanten in einer nationalen/regionalen Cloud zu erstellen, in der Datenspeicher und -verarbeitung von allen anderen Rechenzentren getrennt gehalten werden. Nationale/regionale Clouds weisen eine etwas andere Sicherheitsart auf, da ein separater Datenverwalter den nationalen/regionalen Cloud-Power BI-Dienst im Auftrag von Microsoft betreibt.

  Alternativ können Kunden auch einen Mandanten in einer bestimmten Region einrichten. Solche Mandanten verfügen jedoch nicht über einen separaten Datenvertrauensempfänger von Microsoft. Die Preise für nationale/regionale Clouds unterscheiden sich von dem allgemein verfügbaren kommerziellen Power BI-Dienst. Weitere Informationen zur Verfügbarkeit von Power BI-Diensten für nationale/regionale Clouds finden Sie unter Power BI national/regional clouds.

Wie behandelt Microsoft Verbindungen für Kunden mit Power BI Premium-Abonnements? Unterscheiden sich diese Verbindungen von denen, die für den Nicht-Premium-Power BI-Dienst eingerichtet wurden?

• Die Verbindungen für Kunden mit Power BI Premium-Abonnements implementieren einen Microsoft Entra Business-to-Business-Autorisierungsprozess (B2B) mithilfe der Microsoft Entra-ID, um die Zugriffssteuerung und Autorisierung zu ermöglichen. Power BI verarbeitet Verbindungen von Power BI Premium-Abonnenten zu Power BI Premium-Ressourcen genauso wie jeder andere Microsoft Entra-Benutzer.

Wie funktioniert die serverseitige Authentifizierung im WFE?

• Die Authentifizierung der Benutzerauthentifizierungssequenz auf Serverseite erfolgt wie in den folgenden Schritten beschrieben, die in der folgenden Abbildung dargestellt sind.

1. Ein Benutzer initiiert eine Verbindung mit dem Power BI-Dienst über einen Browser, entweder durch Eingabe der Power BI-Adresse in die Adressleiste oder durch Auswählen der Anmeldung über die Power BI-Marketingseite (https://powerbi.microsoft.com). Die Verbindung wird mit TLS 1.2 und HTTPS hergestellt, und alle nachfolgenden Kommunikation zwischen dem Browser und dem Power BI-Dienst verwendet HTTPS.

2. Der Azure Traffic Manager überprüft den DNS-Eintrag des Benutzers, um das am besten geeignete (in der Regel nächstgelegene) Rechenzentrum zu ermitteln, in dem Power BI bereitgestellt wird, und antwortet auf das DNS mit der IP-Adresse des WFE-Clusters, an die der Benutzer gesendet werden soll.

3. WFE leitet den Benutzer dann zur Anmeldeseite der Microsoft Online Services um.

4. Nachdem der Benutzer authentifiziert wurde, leitet die Anmeldeseite den Benutzer zum zuvor ermittelten nächstgelegenen Power BI-Dienst WFE-Cluster mit einem Authentifizierungscode um.

5. Der WFE-Cluster überprüft bei Microsoft Entra ID, um mithilfe des Authentifizierungscodes ein Microsoft Entra-Sicherheitstoken zu erhalten. Wenn Microsoft Entra ID die erfolgreiche Authentifizierung des Benutzers bestätigt und ein Microsoft Entra-Sicherheitstoken ausstellt, konsultiert der WFE-Cluster den Power BI Global Service, der eine Liste der Mandanten und ihrer Power BI-Back-End-Clusterspeicherorte pflegt und feststellt, welcher Power BI-Back-End-Dienstcluster den Mandanten des Benutzers enthält. Der WFE-Cluster gibt dann eine Anwendungsseite mit den Sitzungs-, Zugriffs- und Routinginformationen an den Browser des Benutzers zurück, die für den Vorgang erforderlich sind.

6. Wenn nun der Browser des Clients Kundendaten erfordert, sendet er Anforderungen an die Back-End-Clusteradresse mit dem Microsoft Entra-Zugriffstoken im Autorisierungs-Header. Der Power BI-Back-End-Cluster liest das Microsoft Entra-Zugriffstoken und überprüft die Signatur, um sicherzustellen, dass die Identität für die Anforderung gültig ist. Das Microsoft Entra-Zugriffstoken hat ein Ablaufdatum, das gemäß Microsoft Entra-Richtlinien festgelegt wird. Um die aktuelle Sitzung aufrechtzuerhalten, sendet der Power BI-Client im Browser des Benutzers regelmäßig Anfragen zur Verlängerung des Zugriffstokens, bevor es abläuft.

Weitere Ressourcen

Weitere Informationen zu Power BI finden Sie in den folgenden Ressourcen.

• Erste Schritte mit Power BI Desktop
• Power BI-API-Referenz
• Lokales Datengateway
• Power BI nationale und regionale Cloud-Dienste
• Microsoft Fabric-Sicherheitsgrundlagen
• Datenschutz, Sicherheit und verantwortungsvolle Nutzung von Copilot in Power BI