Whitepaper zur Sicherheit in Power BI

Zusammenfassung: Power BI ist ein Onlinesoftwaredienst (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. Mithilfe von Power BI können Sie eine Verbindung mit vielen verschiedenen Datenquellen herstellen, Daten aus diesen Verbindungen kombinieren und formen und anschließend Berichte und Dashboards erstellen, die Sie mit anderen teilen können.

Autoren: 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 Bearbeiter: 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 ausdrucken, indem Sie in Ihrem Browser erst auf Drucken und dann auf Als PDF speichern klicken.

Einführung

Power BI ist ein Onlinesoftwaredienst (SaaS oder Software-as-a-Service) von Microsoft, mit dem Sie ganz unkompliziert und schnell Self-Service-Business Intelligence-Dashboards, -Berichte, semantische Modelle und Visualisierungen erstellen können. Mithilfe von Power BI können Sie eine Verbindung mit vielen verschiedenen Datenquellen herstellen, Daten aus diesen Verbindungen kombinieren und formen und anschließend Berichte und Dashboards erstellen, die Sie mit anderen teilen können.

Die Welt verändert sich schnell; Organisationen durchlaufen eine beschleunigte digitale Transformation, und wir sehen einen massiven Anstieg der Remotearbeit, eine erhöhte Kundennachfrage nach Onlinedienste und einen verstärkten Einsatz fortschrittlicher Technologien bei betrieblichen und geschäftlichen Entscheidungen. Und all dies wird von der Cloud unterstützt.

Da sich der Übergang zur Cloud von einem Rinnsal zu einer Flut gewandelt hat, stellen sich immer mehr Unternehmen die Frage: Wie sicher sind meine Daten in der Cloud? und Welcher End-to-End-Schutz ist verfügbar, um zu verhindern, dass meine sensiblen Daten nach außen dringen? Und für die BI-Plattformen, die oft einige der strategisch wichtigsten Informationen im Unternehmen verarbeiten, sind diese Fragen doppelt wichtig.

Die jahrzehntealten Grundlagen des BI-Sicherheitsmodells – Sicherheit auf Objekt- und Zeilenebene – sind zwar immer noch wichtig, reichen jedoch eindeutig nicht mehr aus, um die im Cloudzeitalter erforderliche Sicherheit bereitzustellen. Stattdessen müssen Organisationen nach einer cloudnativen, mehrstufigen Sicherheitslösung für ihre Business Intelligence-Daten suchen.

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

Alles beginnt mit dem Fundament. Nach einer schwierigen Phase in den frühen 2000er Jahren investierte Microsoft massiv in die Behebung seiner Sicherheitslücken und baute in den folgenden Jahrzehnten einen starken Sicherheitsstack auf, der bis zum Bios-Kernel des Computers und bis zu den Erfahrungen der Endbenutzer reicht. Diese umfangreichen Investitionen werden fortgesetzt, und heute arbeiten mehr als 3.500 Microsoft-Ingenieure an der Entwicklung und Verbesserung des Microsoft-Sicherheitsstacks und der proaktiven Bekämpfung der sich ständig verändernden Bedrohungslandschaft. Mit Milliarden von Computern, Billionen von Anmeldungen und zahllosen Zettabytes an Informationen, die dem Schutz von Microsoft anvertraut sind, verfügt das Unternehmen heute über den fortschrittlichsten Sicherheitsstack in der Tech-Industrie und wird allgemein als weltweit führend im Kampf gegen bösartige Akteure angesehen.

Power BI baut auf diesem starken Fundament auf. Es nutzt denselben Sicherheitsstack, der Azure das Recht verschafft hat, die sensibelsten Daten der Welt bereitzustellen und zu schützen, und ist mit den fortschrittlichsten Tools für Informationsschutz und Compliance von Microsoft 365 integriert. Darüber hinaus bietet es Sicherheit durch mehrschichtige Sicherheitsmaßnahmen, die zu einem End-to-End-Schutz führen, der für die einzigartigen Herausforderungen des Cloud-Zeitalters entwickelt wurde.

Um eine End-to-End-Lösung zum Schutz sensibler Ressourcen bereitzustellen, musste das Produktteam anspruchsvolle Kundenanliegen an mehreren Fronten gleichzeitig angehen:

• Wie können wir kontrollieren, wer eine Verbindung herstellen kann, woher sie kommt und wie sie hergestellt wird? Wie können wir die Verbindungen kontrollieren?
• Wie werden die Daten gespeichert? Wie werden sie verschlüsselt? Welche Kontrollmöglichkeiten habe ich für meine Daten?
• Wie kann ich meine sensiblen Daten kontrollieren und schützen? Wie stelle ich sicher, dass diese Daten nicht nach außen dringen können?
• Wie prüfe ich, wer welche Vorgänge durchführt? Wie reagiere ich schnell, wenn es verdächtige Aktivitäten im Dienst gibt?

Dieser Artikel bietet eine umfassende Antwort auf all diese Fragen. Er beginnt mit einer Übersicht über die Dienstarchitektur und erläutert, wie die Standardflows im System funktionieren. Anschließend wird beschrieben, wie sich Benutzer bei Power BI authentifizieren, wie Datenverbindungen hergestellt werden und wie Power BI Daten speichert und durch den Dienst 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 ist Gegenstand der Microsoft Online Services-Nutzungsbedingungen und der Datenschutzbestimmungen von Microsoft Enterprise. Informationen zum für die Datenverarbeitung vorgesehenen Speicherort finden Sie im entsprechenden Abschnitt in den Microsoft-Bestimmungen für Onlinedienste und im Datenschutzanhang. Complianceinformationen in Bezug auf Power BI finden Sie in erster Linie im Microsoft Trust Center. Das Power BI-Team arbeitet hart daran, seinen Kunden die neuesten Innovationen und Produktivitätsfunktionen zur Verfügung zu stellen. Weitere Informationen zur Compliance finden Sie in den Microsoft-Complianceangeboten.

Die Power BI-Dienst folgt dem Security Development Lifecycle (SDL), strengen Sicherheitsmethoden, die Sicherheitssicherheits- 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-Praktiken.

Architektur von Power BI

Der Power BI-Dienst basiert auf Azure, der Cloud Computing-Plattform von Microsoft. Power BI wird derzeit weltweit in vielen Rechenzentren bereitgestellt und in den Regionen, die von diesen Rechenzentren abgedeckt werden, gibt es dieselbe Anzahl an aktiven Bereitstellungen, die den Kunden zur Verfügung stehen, und passiven Bereitstellungen, die jeweils zur Sicherung der aktiven Bereitstellungen dienen.

Web-Front-End-Cluster (WFE)

Der WFE-Cluster stellt dem Browser des Benutzers den anfänglichen HTML-Seiteninhalt beim Laden der Website sowie Zeiger auf CDN-Inhalte bereit, 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 Kunden möglicherweise mit dem Azure Traffic Manager, um das am besten geeignete (in der Regel das nächstgelegene) Rechenzentrum mit einer Power BI-Bereitstellung zu finden. Weitere Informationen über diesen Prozess finden Sie unter Traffic Manager-Routingmethoden.

Statische Ressourcen wie *.js, *.css und Bilddateien werden größtenteils in einem Azure Content Delivery Network (CDN) gespeichert und direkt vom Browser abgerufen. Beachten Sie, dass Bereitstellungen von Sovereign Government-Clustern eine Ausnahme von dieser Regel sind. Aus Konformitätsgründen wird das CDN weggelassen und stattdessen ein WFE-Cluster aus einer konformen Region zum Hosten statischer Inhalte verwendet.

Power BI-Back-End-Cluster (BE)

Der Back-End-Cluster ist das Rückgrat aller in Power BI verfügbaren Funktionen. Er besteht aus mehreren Dienstendpunkten, die von Web-Front-End- und API-Clients genutzt werden, sowie aus Hintergrundarbeitsdiensten, 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 ausgeschö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 Basiscluster des Mandanten bezeichnet. Die Informationen zum Basiscluster eines authentifizierten Benutzers werden vom globalen Dienst bereitgestellt und vom Web-Front-End verwendet, um Anforderungen an den Basiscluster des Mandanten weiterzuleiten.

Jeder Back-End-Cluster besteht aus mehreren virtuellen Computern, die in mehreren skalierungsfähigen Skalierungsgruppen kombiniert sind, die für bestimmte Aufgaben, zustandsbehaftete Ressourcen wie SQL-Datenbanken, Speicherkonten, Servicebusse, Caches und andere erforderliche Cloudkomponenten optimiert sind.

Mandantenmetadaten und -daten werden innerhalb von Clustergrenzwerten gespeichert, mit Ausnahme der Datenreplikation zu einem sekundären Back-End-Cluster in einer gekoppelten Azure-Region in derselben Azure-Geografie. Der sekundäre Back-End-Cluster fungiert im Falle eines regionalen Ausfalls als Failovercluster und ist zu jedem anderen Zeitpunkt passiv.

Die Back-End-Funktionalität wird von Mikrodiensten bereitgestellt, die auf verschiedenen Rechnern innerhalb des virtuellen Netzwerks des Clusters laufen und von außen nicht zugänglich sind, mit Ausnahme von zwei Komponenten, auf die vom öffentlichen Internet aus zugegriffen werden kann:

• Gatewaydienst
• Azure API Management

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 registriert, 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 (siehe oben). Dies bietet eine bessere Isolation, Ressourcenzuordnung, Unterstützung, 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 viele Arten erfolgen. Power BI Premium-Clients können der Browser eines Benutzers, ein reguläres 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 ein Cluster). Die meisten Premium-Ressourcen werden in einem Cluster gekapselt (z. B. Compute), und es gibt einige allgemeine regionale Ressourcen (z. B. Metadatenspeicher). Premium-Infrastruktur bietet zwei Möglichkeiten, horizontale Skalierbarkeit in einer Region zu erreichen: Erhöhen von Ressourcen innerhalb von Clustern und/oder Hinzufügen von mehr Clustern bei Bedarf (wenn sich Clusterressourcen ihren Grenzen nähern).

Der Backbone jedes Clusters sind Computeressourcen, die von Virtual Machine Scale Sets und Azure Service Fabric verwaltet werden. Virtual Machine Scale Sets und Service Fabric ermöglichen eine schnelle und schmerzfreie Erhöhung der Computeknoten, wenn die Nutzung zunimmt, 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: Lastenausgleiche, virtuelle Netzwerke, Netzwerksicherheitsgruppen, Service-Bus, Speicher usw. Alle Geheimnisse, 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 an die Power BI Premium-Infrastruktur gerichtet wird, geht zuerst an die Front-End-Knoten – 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, verarbeiten sie oder leiten sie an die entsprechenden Ressourcen weiter (z. B. Back-End-Knoten).

Back-End-Knoten stellen die meisten Power BI Premium-Funktionen und -Features bereit.

Power BI Mobile

Power BI Mobile ist eine Sammlung von Apps, die für die drei primären mobilen Plattformen entwickelt wurden: Android, iOS, and Windows (UWP). Sicherheitsaspekte für Power BI Mobile-Apps betreffen zwei Kategorien:

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

Zum Thema Gerätekommunikation: Alle Power BI Mobile-Anwendungen kommunizieren mit dem Power BI-Dienst und verwenden dabei dieselben Verbindungs- und Authentifizierungssequenzen, die von Browsern verwendet werden. Diese wurden in diesem Whitepaper bereits an früherer Stelle beschrieben. Die Power BI Mobile-Anwendungen für iOS und Android rufen eine Browsersitzung innerhalb der Anwendung selbst auf, während die mobile Windows-App einen Broker aufruft, um den Kommunikationskanal mit Power BI herzustellen (für den Anmeldevorgang).

In der folgenden Tabelle ist die Unterstützung der zertifikatbasierten Authentifizierung (Certificate-based Authentication, CBA) für Power BI Mobile nach Mobilgeräteplattform aufgelistet:

CBA-Unterstützung	iOS	Android	Windows
Power BI (Anmelden beim Dienst)	Unterstützt	Unterstützt	Nicht unterstützt
SSRS-ADFS lokal (Verbinden mit 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. Über Telemetriedaten werden Statistikdaten zur Verwendung von mobilen Apps und ähnliche Daten erfasst, die dann an Dienste übermittelt werden, die verwendet werden, um die Nutzung und die Aktivität zu überwachen. Zusammen mit den Telemetriedaten werden jedoch keine Kundendaten gesendet.

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

• Microsoft Entra ID- und Aktualisierungstoken werden durch einen sicheren Mechanismus auf dem Gerät gespeichert. Dabei kommen Sicherheitsmaßnahmen nach Industriestandard zum Einsatz.
• Daten und Einstellungen (Schlüssel-Wert-Paare 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 wird dies mithilfe von BitLocker erreicht.
• Für die Android- und iOS-Apps werden die Daten und Einstellungen (Schlüssel-Wert-Paare für die Benutzerkonfiguration) im Speicher auf dem Gerät in einer Sandbox und einem internen Speicher zwischengespeichert, auf den nur die App zugreifen kann. Für die Windows-App kann nur der Benutzer (und der Systemadministrator) auf die Daten zugreifen.
• Die Geolocation wird vom Benutzer explizit aktiviert oder deaktiviert. Wenn diese Option aktiviert ist, werden Geolocationdaten nicht auf dem Gerät gespeichert und nicht für Microsoft freigegeben.
• Benachrichtigungen werden vom Benutzer explizit aktiviert oder deaktiviert. Wenn sie aktiviert sind, unterstützen Android und iOS keine geografischen Datenresidenzanforderungen für Benachrichtigungen.

Die Datenverschlüsselung kann durch die Anwendung 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 einmaliges Anmelden zu implementieren, sind einige gesicherte Speicherwerte im Zusammenhang mit der tokenbasierten Authentifizierung für andere Microsoft Erstanbieter-Apps (z. B. Microsoft Authenticator) verfügbar und werden von der Microsoft Authentication Library (MSAL) verwaltet.

Von Power BI Mobile zwischengespeicherte Daten werden gelöscht, wenn sich der Benutzer von Power BI Mobile abmeldet oder die Anmeldung eines Benutzers fehlschlägt (z. B. im Falle eines abgelaufenen Token oder einer Kennwortänderung). Im Datencache sind Dashboards und Berichte enthalten, 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 Identifikation konfigurieren, z. B. die Bereitstellung einer Face ID, Touch ID oder einer 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 für den Power BI-Dienst besteht aus mehreren Anforderungen, Antworten und Umleitungen zwischen dem Browser des Benutzers und dem Power BI-Dienst oder den Azure-Diensten, die von Power BI verwendet werden. In diesem Abschnitt wird der Prozess der Benutzerauthentifizierung in Power BI beschrieben, der dem Flow zum Gewähren eines Autorisierungscodes von Microsoft Entra folgt. Weitere Informationen zu den unterschiedlichen Modellen für die Benutzerauthentifizierung einer Organisation (Anmeldemodelle) finden Sie unter Choosing a sign-in model for Office 365 (Auswahl eines Anmeldemodells für Microsoft 365).

Authentifizierungssequenz

Die Benutzerauthentifizierungssequenz für den Power BI-Dienst läuft wie in den folgenden Schritten beschrieben ab und wird durch die Bilder veranschaulicht.

1. Ein Benutzer initiiert eine Verbindung zum Power BI-Dienst von einem Browser aus, indem er entweder die Power BI-Adresse in die Adressleiste eingibt oder auf Anmelden auf der Power BI-Marketingseite klickt (https://powerbi.microsoft.com). Die Verbindung wird mit TLS und HTTPS hergestellt, und bei der gesamten weiteren Kommunikation zwischen dem Browser und dem Power BI-Dienst wird HTTPS verwendet.

2. Der Azure Traffic Manager überprüft den DNS-Eintrag des Benutzers, um das am besten geeignete (in der Regel das nächstgelegene) Rechenzentrum zu ermitteln, in dem Power BI bereitgestellt wird, und antwortet DNS mit der IP-Adresse des WFE-Clusters, zu der der Benutzer geleitet 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 Anmeldeflows erforderlich ist.

4. Der Browserclient lädt die von der WFE empfangene HTML-Seite und leitet den Benutzer zur Microsoft Online Services-Anmeldeseite um.

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

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 Browserclient verwendet, um den globalen Power BI-Dienst abzufragen, der eine Liste der Mandanten und ihrer Power BI-Back-End-Clusterstandorte 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.

8. Der Client kann nun über das Zugriffstoken im Autorisierungsheader für die HTTP-Anforderungen mit der Power BI-Back-End-Cluster-URL-API kommunizieren. Für das Microsoft Entra ID-Zugriffstoken ist ein Ablaufdatum gemäß den Microsoft Entra ID-Richtlinien festgelegt, und um die aktuelle Sitzung beizubehalten, stellt der Power BI-Client im Browser des Benutzers regelmäßig Anforderungen 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, auf die Verwendung der serverseitigen Authentifizierung in der WFE zurückzugreifen. Ausführliche Informationen zum serverseitigen Authentifizierungsflow finden Sie im Abschnitt mit 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 anmeldet. Ein Microsoft Entra-Mandant enthält die Benutzer- und Anwendungsidentitäten, Gruppen und andere relevante Informationen, die sich auf eine Organisation und deren Sicherheit beziehen.

Die Zuweisung einer Azure-Geografie für die Speicherung von Mandantendaten erfolgt durch Zuordnung des Landes oder der Region, das bzw. die als Teil der Microsoft Entra-Mandanteneinrichtung ausgewählt wurde, zu der am besten geeigneten Azure-Geografie, in der eine Power BI-Bereitstellung vorhanden ist. Nach dieser Ermittlung werden alle Power BI-Kundendaten in dieser ausgewählten Azure-Geografie (auch als Heimatgeografie bezeichnet) gespeichert, mit Ausnahme von Fällen, in denen Organisationen Multi-Geo-Bereitstellungen verwenden.

Mehrere geografische Regionen (Multi-Geo)

Einige Organisationen sind global präsent und benötigen möglicherweise Power BI-Dienste in mehreren Azure-Regionen. Ein Unternehmen kann beispielsweise seinen Hauptsitz in den Vereinigten Staaten haben, aber auch in anderen geografischen Gebieten, wie z. B. Australien, tätig sein. In solchen Fällen kann das Unternehmen verlangen, dass bestimmte Power BI-Daten im Ruhezustand in der Remoteregion gespeichert bleiben, um die lokalen Vorschriften zu erfüllen. Dieses Feature des Power BI-Dienstes wird als Multi-Geo bezeichnet.

Die Abfrageausführungsebene, Abfragecaches und Artefaktdaten, die einem Arbeitsbereich mit mehreren Geografien zugewiesen sind, werden gehostet und verbleiben in der Azure-Remotekapazität. Einige Artefaktmetadaten, z. B. die Berichtsstruktur, bleiben jedoch möglicherweise im Ruhezustand in der Heimatgeografie des Mandanten gespeichert. Darüber hinaus kann ein Teil des Datentransits und der Datenverarbeitung weiterhin in der Heimatgeografie des Mandanten erfolgen, auch für Arbeitsbereiche, die in einer Premium-Kapazität mit mehreren Geografien gehostet werden.

Weitere Informationen zum Erstellen und Verwalten von Power BI-Bereitstellungen, die mehrere Azure-Regionen umfassen, finden Sie unter Konfigurieren von Multi-Geo-Unterstützung für Power BI Premium.

Regionen und Rechenzentren

Power BI-Dienste sind in bestimmten Azure-Regionen verfügbar, wie im Microsoft Trust Center beschrieben. Weitere Informationen zu Speicherort und Verwendung Ihrer Daten finden Sie im Microsoft Trust Center. Verpflichtungen zum Speicherort ruhender Kundendaten sind in den Bedingungen zur Datenverarbeitung der Bestimmungen für Onlinedienste von Microsoft angegeben.

Microsoft bietet auch Rechenzentren für unabhängige Entitäten an. Weitere Informationen zur Verfügbarkeit des Power BI-Diensts für nationale/regionale Clouds finden Sie unter Nationale/regionale Power BI-Clouds.

Datenhandhabung

In diesem Abschnitt werden Power BI-Methoden für die Datenverarbeitung beim Speichern, Verarbeiten und Übertragen von Kundendaten beschrieben.

Ruhende Daten

Power BI verwendet zwei primäre Datenspeicherressourcentypen:

• Azure Storage
• Azure SQL-Datenbank-Instanzen

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 Artefaktmetadaten zu speichern.

Alle von Power BI gespeicherten Daten werden standardmäßig mit von Microsoft verwalteten Schlüsseln verschlüsselt. In Azure SQL-Datenbank gespeicherten Kundendaten werden mithilfe der integrierten Transparent Data Encryption-Technologie (TDE) vollständig verschlüsselt. Kundendaten, die in Azure Blob Storage gespeichert sind, werden mithilfe von 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 als Bring Your Own Key (BYOK) bezeichnet. Die Verwendung von BYOK trägt dazu bei, dass kundenseitige Daten auch bei einem Fehler des Serviceoperators nicht verfügbar gemacht werden, was sich mit transparenter dienstseitiger Verschlüsselung nicht einfach erreichen lässt. Weitere Informationen finden Sie unter Verwenden eigener Verschlüsselungsschlüssel für Power BI.

Semantische Modelle in Power BI ermöglichen verschiedene Datenquellenverbindungsmodi, die bestimmen, ob die Datenquellendaten im Dienst beibehalten werden oder nicht.

Semantikmodellmodus (Art)	In Power BI persistente Daten
Importieren	Ja
DirectQuery	Nein
Live Connect	Nein
Zusammengesetzt	Wenn eine Importdatenquelle enthalten ist
Streaming	Wenn für Beibehaltung konfiguriert

Unabhängig vom verwendeten Semantikmodellmodus kann Power BI alle abgerufenen Daten vorübergehend zwischenspeichern, um die Abfrage- und Berichtsladeleistung 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. die Aktualisierung, 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 erleichtern, werden die verarbeiteten Daten im Arbeitsspeicher nicht verschlüsselt.

Daten während der Übertragung

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

Authentifizierung in 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 mit den Anmeldeinformationen auf die Daten zu. Nachdem das semantische Modell im Power BI-Dienst veröffentlicht wurde, verwendet Power BI immer die Anmeldeinformationen dieses Benutzers, um Daten zu importieren. Sobald Daten importiert wurden, wird durch das Anzeigen der Daten in Berichten und Dashboards nicht mehr auf die zugrunde liegende Datenquelle zugegriffen. Power BI unterstützt die Authentifizierung des einmaligen Anmeldens für ausgewählte Datenquellen. Wenn die Verbindung für die Verwendung des einmaligen Anmeldens 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 mit einmaligem Anmelden verbunden ist, werden die Anmeldeinformationen des aktuellen Benutzers verwendet, um sich mit der Datenquelle zu verbinden, wenn ein Benutzer die Daten anzeigt. Bei Verwendung mit einmaligem Anmelden können Sicherheit auf Zeilenebene (Row Level Security, RLS) und/oder Sicherheit auf Objektebene (OLS) für die Datenquelle implementiert werden. Dadurch können Benutzer nur Daten anzeigen, für die sie Zugriffsberechtigungen haben. Wenn die Verbindung mit Datenquellen in der Cloud besteht, wird die Microsoft Entra-Authentifizierung für einmaliges Anmelden (SSO) verwendet. Für lokale Datenquellen werden Kerberos, Security Assertion Markup Language (SAML) und Microsoft Entra ID unterstützt.

Wenn die Datenquelle Azure Analysis Services oder lokale Analysis Services ist und RLS und/oder OLS konfiguriert sind, wendet der Power BI-Dienst die Sicherheit auf Zeilenebene an. Benutzer, die nicht über ausreichende Anmeldeinformationen für den Zugriff auf die zugrunde liegenden Daten verfügen (dies kann 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 sie dann in einem Zielmodell für die Verwendung in verschiedenen Berichterstellungstechnologien landen. Jeder Benutzer, der entweder über eine Mitglieds-, Mitwirkender- oder Administratorrolle in einem Arbeitsbereich verfügt, kann einen Dataflow erstellen. Benutzer in der Viewerrolle können vom Dataflow verarbeitete Daten anzeigen, aber keine Änderungen an der Zusammensetzung vornehmen. Sobald ein Dataflow erstellt wurde, können alle Mitglieder, Mitwirkenden oder Administratoren des Arbeitsbereichs Aktualisierungen planen und den Dataflow anzeigen und bearbeiten, indem sie den Besitz davon übernehmen.

Jede konfigurierte Datenquelle ist für den Zugriff auf diese Datenquelle an eine Clienttechnologie gebunden. Die Struktur der Anmeldeinformationen, die für den Zugriff erforderlich sind, wird so gebildet, dass sie den erforderlichen Implementierungsdetails der Datenquelle entspricht. Transformationslogik wird von Power Query-Diensten angewendet, während sich die Daten im Flug befindet. Bei Premium-Dataflows werden Power Query-Dienste in Back-End-Knoten ausgeführt. Daten können direkt aus den Cloudquellen oder über ein lokales Gateway abgerufen werden. Wenn der Transport direkt von einer Cloudquelle zum Dienst oder zum Gateway abgerufen wird, verwendet der Transport ggf. eine für die Clienttechnologie spezifische Schutzmethodik. Wenn Daten vom Gateway an den Clouddienst übertragen werden, werden sie verschlüsselt. Weitere Informationen finden Sie oben im Abschnitt Daten während der Übertragung.

Wenn vom Kunden angegebene Datenquellen Anmeldeinformationen für den Zugriff benötigen, stellt der Besitzer/Ersteller des Dataflows diese während der Dokumenterstellung bereit. Sie werden mithilfe des standardmäßigen produktweiten Anmeldeinformationsspeichers gespeichert. Weitere Informationen finden Sie oben im Abschnitt Authentifizierung in Datenquellen. 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 für die Blobspeichercontainer aktiviert, um die Daten zu schützen, während sie sich im Ruhezustand befinden. Weitere Informationen finden Sie weiter unten im Abschnitt Ruhende Daten. Benutzer können jedoch ihr eigenes Speicherkonto konfigurieren, das ihrem eigenen Azure-Abonnement zugeordnet ist. Dabei wird einem Power BI-Dienstprinzipal Zugriff auf dieses Speicherkonto gewährt, sodass er die Daten während der Aktualisierung dort schreiben kann. In diesem Fall ist der Besitzer der Speicherressource für die Konfiguration der Verschlüsselung des konfigurierten ADLS-Speicherkontos verantwortlich. Daten werden immer mithilfe der Verschlüsselung an Blob-Speicher übertragen.

Da die Leistung beim Zugriff auf Speicherkonten für einige Daten möglicherweise suboptimal ist, haben Benutzer auch die Möglichkeit, eine von Power BI gehostete Compute-Engine zu verwenden, um die Leistung zu steigern. In diesem Fall werden Daten redundant in einer SQL-Datenbank gespeichert, die für DirectQuery über den Zugriff durch das Back-End-Power BI-System verfügbar ist. Daten werden im Dateisystem immer 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 ihn doppelt zu verschlüsseln.

Bei Abfragen mit DirectQuery wird das verschlüsselte Transportprotokoll HTTPS für den Zugriff auf die API verwendet. Die gesamte sekundäre oder indirekte Verwendung von DirectQuery wird durch die gleichen Zugriffssteuerungen gesteuert, die zuvor beschrieben wurden. Da Dataflows immer an einen Arbeitsbereich gebunden sind, erfolgt der Zugriff auf die Daten immer durch die Rolle des Benutzers in diesem Arbeitsbereich. 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 Dataflow verwendet wird, muss der Benutzer zuerst mithilfe von Microsoft Entra ID authentifiziert werden, um festzustellen, ob der Benutzer über ausreichende Rechte zum Anzeigen der Daten verfügt. Wenn ja, wird ein SaS-Schlüssel abgerufen und für den direkten Zugriff auf Speicher mithilfe des verschlüsselten Transportprotokolls HTTPS verwendet.

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

Paginierte Berichte

Paginierte Berichte sind dafür ausgelegt, gedruckt oder geteilt zu werden. Sie werden als paginiert bezeichnet, weil sie so formatiert sind, dass sie gut auf eine Seite passen. Sie zeigen alle Daten in einer Tabelle an, selbst wenn die Tabelle sich über mehrere Seiten erstreckt. Das Berichtsseitenlayout kann detailliert gesteuert werden.

Paginierte Berichte unterstützen umfangreiche und leistungsstarke Ausdrücke, die in Microsoft Visual Basic .NET geschrieben wurden. Ausdrücke werden in paginierten Berichten im Power BI Report Builder häufig verwendet, um Daten abzurufen, zu berechnen, anzuzeigen, zu gruppieren, zu sortieren, zu filtern, zu parametrisieren oder zu formatieren.

Ausdrücke werden vom Autor des Berichts mit Zugriff auf die breite Palette von Features des .NET-Frameworks erstellt. Die Verarbeitung und Ausführung paginierter Berichte erfolgt in einer Sandbox.

Paginierte Berichtsdefinitionen (.rdl) werden in Power BI gespeichert, und zum Veröffentlichen und/oder Rendern eines paginierten Berichts muss ein Benutzer sich authentifizieren und autorisieren, wie im Abschnitt Authentifizierung beim Power BI-Dienst oben beschrieben.

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

In Power BI Premium stellt die Runtime des Power BI-Diensts eine entsprechend isolierte Ausführungsumgebung für jedes Rendern des Berichts bereit. Dies schließt Fälle ein, in denen die gerenderten Berichte zu Arbeitsbereichen gehören, die derselben Kapazität zugewiesen sind.

Ein paginierter Bericht kann im Rahmen des Renderings des Berichts auf einen breiten Satz von Datenquellen zugreifen. Die Sandbox kommuniziert nicht direkt mit einer der Datenquellen, sondern 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 Geheimnisse.

Um Features wie Bing-Karten oder Aufrufe von Azure Functions zu unterstützen, hat die Sandbox Zugriff auf das Internet.

Power BI Embedded Analytics

Unabhängige Softwareanbieter (Independent Software Vendors, ISVs) und Lösungsanbieter verfügen über zwei Standardmodi zum Einbetten von Power BI-Artefakten in ihre Webanwendungen und Portale: Einbetten für Ihre Organisation und Einbetten 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 unter Verwendung von POST-Nachrichten.

Beim Einbetten für Ihre Organisation greifen Microsoft Entra-Benutzer über von ihren Unternehmen und den IT-Mitarbeitern angepasste Portale auf ihre eigenen Power BI-Inhalte zu. Alle in diesem Dokument beschriebenen Power BI-Richtlinien und -Funktionen wie Sicherheit auf Zeilenebene (Row Level Security, RLS) und Sicherheit auf Objektebene (OLS) werden automatisch auf alle Benutzer angewendet, unabhängig davon, ob sie über das Power BI-Portal oder über benutzerdefinierte Portale auf Power BI zugreifen.

Beim Einbetten für Ihre Kunden besitzen ISVs in der Regel Power BI-Mandanten und Power BI-Elemente (Dashboards, Berichte, semantische Modelle usw.). 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 sind. 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, sind nicht in der Lage, Einbettungstoken zu entschlüsseln oder zu ändern. Clientseitige SDKs wie Power BI-Client-APIs fügen das verschlüsselte Einbettungstoken automatisch als Header Authorization: EmbedToken an Power BI-Anforderungen an. Basierend auf diesem Header erzwingt Power BI alle Richtlinien (z. B. Zugriff oder RLS) genau so, wie es vom ISV während der Generierung angegeben wurde.

Um die Einbettung und Automatisierung zu aktivieren und die oben beschriebenen Einbettungstoken zu generieren, macht Power BI einen umfangreichen Satz von REST-APIs verfügbar. Diese Power BI-REST-APIs unterstützen sowohl vom Benutzer delegierte als auch Dienstprinzipal-Microsoft Entra-Methoden der Authentifizierung und Autorisierung.

Power BI Embedded Analytics und die zugehörigen REST-APIs unterstützen alle in diesem Artikel beschriebenen Power BI-Netzwerkisolationsfunktionen: z. B. Diensttags und private Links.

KI-Features

Power BI unterstützt derzeit zwei große Kategorien von KI-Features im Produkt: KI-Visuals und KI-Anreicherungen. Die KI-Features auf visueller Ebene umfassen Funktionen wie „Wichtige Einflussfaktoren“, „Struktur für Aufschlüsselung“, „Smart Narrative“, „Anomalieerkennung“, „R-Visual“, „Python-Visual“, „Clustering“, „Vorhersagen“, „Q&A“, „Quick Insights“ usw. Die KI-Anreicherungsfunktionen umfassen Funktionen wie automatisiertes maschinelles Lernen, Azure Machine Learning, CognitiveServices, R-/Python-Transformationen usw.

Die meisten der oben genannten Features werden heute sowohl in Shared- als auch in Premium-Arbeitsbereichen unterstützt. AutoML und CognitiveServices werden jedoch aufgrund von IP-Einschränkungen nur in Premium-Arbeitsbereichen unterstützt. Mit der AutoML-Integration in Power BI können Benutzer ein benutzerdefiniertes ML-Modell (z. B. Vorhersage, Klassifizierung, Regression usw.) erstellen, trainieren und anwenden, um Vorhersagen zu erhalten, während Daten in einen in einem Premium-Arbeitsbereich definierten Dataflow 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 einen in einem Premium-Arbeitsbereich definierten Dataflow/semantischen Modell geladen werden.

Die Premium-KI-Anreicherungsfeatures können am besten als Sammlung zustandsloser KI-Funktionen/-Transformationen angezeigt werden, die von Power BI-Benutzern in ihren Datenintegrationspipelines verwendet werden können, die von einem Power BI-Semantikmodell oder -Dataflow verwendet werden. Beachten Sie, dass auf diese Funktionen auch über aktuelle Dataflow-/Semantikmodell-Erstellungsumgebungen 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 ihrer eigenen Daten anzeigen und nur diese Funktionen/Transformationen bereitstellen. Während der Ausführung führen diese Features keine ausgehenden Aufrufe an andere Dienste aus, um die Daten des Kunden zu übertragen. Sehen wir uns die Premium-Szenarien einzeln an, um die Kommunikationsmuster und relevanten sicherheitsrelevanten Details zu verstehen.

Zum Trainieren und Anwenden eines AutoML-Modells verwendet Power BI das Azure AutoML-SDK und führt das gesamte Training in der Power BI-Kapazität des Kunden aus. Während der Trainingsiterationen ruft Power BI einen experimentierfreudigen Azure Machine Learning Service 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. Das AutoML-Training erzeugt ein ONNX-Modell und Trainingsberichtsdaten, die dann im Dataflow gespeichert werden. Später können Power BI-Benutzer das trainierte ML-Modell dann als Transformation anwenden, um das ML-Modell planmäßig zu operationalisieren. Für TextAnalytics- und ImageTagging-APIs ruft Power BI die CognitiveServices-Dienst-APIs nicht direkt 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-Dataflows als auch in semantischen Modellen unterstützt. Beim Erstellen eines Datenmodells in Power BI Desktop können Benutzer nur 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 haben bestimmte Lizenzierungsanforderungen. Weitere Informationen finden Sie in den folgenden Abschnitten.

Diensttags

Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen eines bestimmten Azure-Diensts. Mit Diensttags kann die Komplexität häufiger Aktualisierungen von Netzwerksicherheitsregeln verringert werden. Kunden können Diensttags verwenden, um Netzwerkzugriffssteuerungen in Netzwerksicherheitsgruppen oder in der Azure Firewall zu definieren. Kunden können Diensttags anstelle von spezifischen IP-Adressen nutzen, wenn Sie Sicherheitsregeln erstellen. Indem sie den Diensttagnamen (z. B. PowerBI) im entsprechenden Quell- oder Zielfeld (für APIs) einer Regel angeben, können Kunden den Datenverkehr für den entsprechenden Dienst zulassen oder verweigern. Microsoft verwaltet die Adresspräfixe, für die das Diensttag gilt, und aktualisiert das Diensttag automatisch, wenn sich die Adressen ändern.

Private Link-Integration

Azure-Netzwerk bietet das Azure Private Link-Feature, das Power BI das Bereitstellen des sicheren Zugriffs über private Azure-Netzwerk-Endpunkte ermöglicht. Mit Azure Private Link und privaten Endpunkten wird der Datenverkehr privat über die Backbone-Netzwerkinfrastruktur von Microsoft gesendet, sodass die Daten nicht über das Internet übertragen werden.

Durch Private Link wird sichergestellt, dass Power BI-Benutzer den privaten Netzwerkbackbone von Microsoft verwenden, wenn sie auf Ressourcen im Power BI-Dienst zugreifen.

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

• Private Link stellt sicher, dass der Datenverkehr über den Azure-Backbone an einen privaten Endpunkt für cloudbasierte Azure-Ressourcen weitergeleitet wird.
• Für eine Isolierung von Netzwerkdatenverkehr von einer nicht auf Azure basierenden Infrastruktur, z. B. bei lokalem Zugriff, müssten Kunden ExpressRoute oder ein virtuelles privates Netzwerk (VPN) konfigurieren.

Weitere Informationen finden Sie unter Private Verknüpfungen für den Zugriff auf Power BI.

VNet-Konnektivität

Während die Integrationsfunktion für Private Link sichere eingehende Verbindungen mit Power BI bereitstellt, ermöglicht das VNET-Konnektivitätsfeature eine sichere ausgehende Konnektivität von Power BI zu Datenquellen innerhalb eines VNet.

Durch VNET-Gateways (von Microsoft verwaltet) wird der Mehraufwand für die Installation und Überwachung lokaler Datengateways für die Verbindung mit Datenquellen, die einem VNET zugeordnet sind, vermieden. 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 geschieht, wenn Sie mit einem Power BI-Bericht interagieren, der über VNET-Gateways mit einer Datenquelle innerhalb eines VNet 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 VNet-Dienst der Power Platform (PP VNet).

2. Der PP VNet-Dienst injiziert dann sicher einen Container, indem ein VNet-Gateway im Subnetz ausgeführt wird. Dieser Container kann jetzt eine Verbindung zu Datendiensten herstellen, auf die in diesem Subnetz zugegriffen werden kann.

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

4. Das VNet-Gateway ruft die Abfrage ab und stellt unter Verwendung dieser Anmeldeinformationen eine Verbindung mit den Datenquellen her.

5. Die Abfrage wird dann zum Ausführen an die Datenquelle gesendet.

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

Dienstprinzipale

Power BI unterstützt die Verwendung von Dienstprinzipalen. Speichern Sie beliebige Anmeldeinformationen für Dienstprinzipale in einem Schlüsseltresor, die für die Verschlüsselung oder den Zugriff auf Power BI verwendet werden, weisen Sie dem Tresor die entsprechenden Zugriffsrichtlinien zu, und überprüfen Sie die Zugriffsberechtigungen regelmäßig.

Weitere Informationen finden Sie unter Automatisieren von Arbeitsbereichs- und Semantikmodellaufgaben in Power BI Premium mithilfe von Dienstprinzipalen.

Microsoft Purview für Power BI

Microsoft Purview Information Protection

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 können sowohl im Power BI-Dienst als auch in Power BI Desktop mit denselben 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 auch dann geschützt werden, 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 leicht entsprechend ihrer Vertraulichkeit gekennzeichnet werden. Darüber hinaus können sie verschlüsselt werden, wenn sie vertrauliche Geschäftsdaten enthalten, sodass nur autorisierte Benutzer diese Dateien bearbeiten können.
• Excel-Arbeitsmappen erben automatisch Vertraulichkeitsbezeichnungen, wenn sie eine Verbindung mit Power BI herstellen (Vorschau), sodass die End-to-End-Klassifizierung beibehalten und Schutz angewendet werden kann, wenn Power BI-Semantikmodelle in Excel analysiert werden.
• Vertraulichkeitsbezeichnungen, die auf Power BI-Berichte und -Dashboards angewendet werden, sind in den mobilen Power BI iOS- und Android-Apps sichtbar.
• Vertraulichkeitsbezeichnungen bleiben erhalten, wenn ein Power BI-Bericht in Teams, SharePoint oder eine sichere Website eingebettet ist. Dies hilft Organisationen dabei, beim Einbetten von Power BI-Inhalten die Klassifizierung und den Schutz beim Export aufrechtzuerhalten.
• Die Bezeichnungsvererbung bei der Erstellung neuer Inhalte im Power BI-Dienst stellt sicher, dass Bezeichnungen, die auf semantische Modelle oder Datamarts im Power BI-Dienst angewendet werden, auf neue Inhalte angewendet werden, die auf diesen semantischen Modellen und Datamarts erstellt wurden.
• Power BI-Administratorscan-APIs können die Vertraulichkeitsbezeichnung eines Power BI-Elements extrahieren, sodass Power BI- und InfoSec-Administratoren die Bezeichnungen im Power BI-Dienst überwachen und Executive-Berichte 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 neue oder bearbeitete Inhalte 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.
• Die automatische nachgeschaltete Vertraulichkeitsbezeichnung im Power BI-Dienst stellt sicher, dass die Bezeichnung automatisch auf alle nachgeschalteten Inhalte angewendet oder geändert wird, die mit dem semantischen Modell oder Datamart verbunden sind, wenn eine Bezeichnung auf ein semantisches Modell oder einen Datamart angewendet oder geändert wird.

Weitere Informationen finden Sie unter Vertraulichkeitsbezeichnungen in Power BI.

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

Die DLP-Richtlinien von Microsoft Purview helfen Organisationen dabei, das Risiko von Datenlecks vertraulicher Geschäftsdaten aus Power BI zu verringern. DLP-Richtlinien helfen ihnen dabei, Complianceanforderungen von behördlichen oder branchenspezifischen Vorschriften wie der DSGVO (der Datenschutz-Grundverordnung der Europäischen Union) oder CCPA (California Consumer Privacy Act) zu erfüllen und sicherzustellen, dass ihre Daten in Power BI verwaltet werden.

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

• Alle semantischen Modelle in den Arbeitsbereichen, die in der Richtlinie angegeben sind, 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:
  • Vertraulichkeitsbezeichnungen
  • Typen vertraulicher Informationen. Über 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 wurde, können Sie einen benutzerdefinierten Richtlinientipp sehen, der Ihnen hilft, zu verstehen, was Sie tun sollten.
• Wenn Sie Besitzer eines semantischen Modells sind, können Sie eine Richtlinie überschreiben und verhindern, dass Ihr semantisches Modell als „vertraulich“ identifiziert wird, wenn Sie einen relevanten Grund dafür haben.
• Wenn Sie Besitzer eines semantischen Modells sind, können Sie ein Problem mit einer Richtlinie melden, wenn Sie zu dem Schluss kommen, dass ein vertraulicher Informationstyp fälschlicherweise identifiziert wurde.
• Automatische Risikominderungen, z. B. Warnungen an den Sicherheitsadministrator, können aufgerufen werden.

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

Microsoft Defender for Cloud Apps für Power BI

Microsoft Defender for Cloud Apps ist einer der weltweit führenden Cloud Access Security Broker, der in Gartners Magic Quadrant für den Cloud Access Security Broker (CASB)-Markt führend ist. Defender for Cloud Apps wird verwendet, um die Verwendung von Cloud-Apps zu schützen. So können Organisationen riskante Power BI-Sitzungen wie den Benutzerzugriff von nicht verwalteten Geräten in Echtzeit überwachen und steuern. Sicherheitsadministratoren können Richtlinien definieren, um Benutzeraktionen zu steuern, z. B. das Herunterladen von Berichten mit vertraulichen Informationen.

Mit Defender for Cloud Apps können Organisationen die folgenden DLP-Funktionen nutzen:

• Festlegen von Echtzeitsteuerelementen, um riskante Benutzersitzungen in Power BI zu erzwingen. Wenn ein Benutzer beispielsweise von außerhalb seines Landes oder seiner Region eine Verbindung mit Power BI herstellt, kann die Sitzung von den Echtzeitsteuerelementen von Defender for Cloud Apps überwacht werden, und riskante Aktionen, z. B. das Herunterladen von Daten, die mit der Vertraulichkeitsbezeichnung „Streng vertraulich“ gekennzeichnet sind, können sofort blockiert werden.
• Untersuchen der Power BI-Benutzeraktivität mit dem Defender for Cloud Apps-Aktivitätsprotokoll. 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 Informationen zur Vertraulichkeitsbezeichnung für relevante Aktivitäten wie Anwenden, Ändern und Entfernen von Bezeichnungen enthält. Administratoren können die erweiterten Filter von Defender for Cloud Apps und schnelle Aktionen für eine effektive Problemuntersuchung nutzen.
• Erstellen benutzerdefinierter Richtlinien zum Senden von Warnung bei verdächtigen Benutzeraktivitäten in Power BI. Die Defender for Cloud Apps-Aktivitätsrichtlinie kann verwendet werden, um eigene, benutzerdefinierte Regeln zu definieren, mit denen ein von der Norm abweichendes Benutzerverhalten erkannt und gegebenenfalls sogar automatisch darauf reagiert werden kann, wenn es als gefährlich eingestuft wird.
• Arbeiten mit der integrierten Anomalieerkennung in Defender for Cloud Apps. Die Defender for Cloud Apps-Richtlinien zur Erkennung von Anomalien bieten sofort einsatzbereite Verhaltensanalysen für Benutzer 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 for Cloud Apps bietet eine App-spezifische Administratorrolle, mit der Power BI-Administratoren nur die Berechtigungen erteilt werden können, die sie für den Zugriff auf Power BI-relevante Daten im Portal benötigen, z. B. Warnungen, gefährdete Benutzer, Aktivitätsprotokolle und andere Power BI-bezogene Informationen.

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

Vorschau der Sicherheitsfeatures

In diesem Abschnitt werden Features aufgeführt, die bis März 2021 veröffentlicht werden sollen. Da in diesem Thema Features aufgeführt sind, die möglicherweise noch nicht veröffentlicht wurden, können sich die Übermittlungszeiträume ändern, und die projizierten Funktionen werden möglicherweise später als März 2021 oder überhaupt nicht veröffentlicht. Weitere Informationen zu Vorschauversionen finden Sie in den Bestimmungen für Onlinedienste.

Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics ermöglicht die Integration zwischen Power BI und Azure Log Analytics. Diese Integration umfasst die erweiterte Analyse-Engine von Azure Log Analytics, interaktive Abfragesprache und integrierte Machine Learning-Konstrukte.

Fragen und Antworten zur Power BI-Sicherheit

Im Folgenden finden Sie häufige Sicherheitsfragen und dazugehörige Antworten für Power BI. Diese sind danach geordnet, wann sie diesem Whitepaper hinzugefügt wurden, um es Ihnen zu ermöglichen, neue Fragen und Antworten mühelos und schnell zu finden, wenn es aktualisiert wird. Die neuesten Fragen werden am Ende dieser Liste angefügt.

Wie verbinden sich Benutzer während der Verwendung von Power BI mit Datenquellen und erhalten Zugriff auf diese?

• Power BI verwaltet Anmeldeinformationen für Datenquellen für jeden Benutzer für Cloudanmeldeinformationen 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 semantischen Modells kann der Benutzer einen Satz Anmeldeinformationen aus dem persönlichen Speicher auswählen oder ein lokales Datengateway verwenden, um freigegebene Anmeldeinformationen zu verwenden.

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

  Bei Berichten, die mit DirectQuery verbunden sind, wird die Datenquelle direkt mit vorkonfigurierten Anmeldeinformationen verbunden. Die vorkonfigurierten Anmeldeinformationen werden verwendet, um eine Verbindung mit der Datenquelle herzustellen, wenn ein Benutzer die Daten anzeigt. Wenn eine Datenquelle direkt mit einmaligem Anmelden verbunden ist, werden die Anmeldeinformationen des aktuellen Benutzers verwendet, um sich mit der Datenquelle zu verbinden, wenn der Benutzer die Daten anzeigt. Bei Verwendung des einmaligen Anmeldens können Sicherheit auf Zeilenebene (Row Level Security, RLS) und/oder Sicherheit auf Objektebene (OLS) für die Datenquelle implementiert werden, sodass Benutzer Daten anzeigen können, auf die sie über Zugriffsberechtigungen 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 werden Kerberos, SAML und Microsoft Entra ID unterstützt.

  Beim Herstellen einer Verbindung mit Kerberos wird der UPN des Benutzers an das Gateway übergeben. Mithilfe der eingeschränkten Kerberos-Delegierung wird die Identität des Benutzers gewechselt und mit den entsprechenden Datenquellen verbunden. SAML wird auch auf der Gateway for 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 ist und Sicherheit auf Zeilenebene (Row Level Security, RLS) und/oder Sicherheit auf Objektebene (OLS) konfiguriert sind, wendet der Power BI-Dienst die Sicherheit auf Zeilenebene an. Benutzer, die nicht über ausreichende Anmeldeinformationen für den Zugriff auf die zugrunde liegenden Daten verfügen (dies kann 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.

  Die Sicherheit auf Zeilenebene (Row Level Security, RLS) mit Power BI kann zum Einschränken des Datenzugriffs für bestimmte Benutzer verwendet werden. Filter beschränken den Datenzugriff auf Zeilenebene, und Sie können Filter in Rollen definieren.

  Die Sicherheit auf Objektebene (Object Level Security, OLS) kann verwendet werden, um vertrauliche Tabellen oder Spalten zu schützen. Im Gegensatz zur Sicherheit auf Zeilenebene sichert die Sicherheit auf Objektebene jedoch auch Objektnamen und Metadaten. Dadurch wird verhindert, dass böswillige Benutzer überhaupt die Existenz solcher Objekte entdecken. Gesicherte Tabellen und Spalten werden bei Verwendung von Berichtstools wie Excel oder Power BI in der Feldliste verdeckt, und darüber hinaus können Benutzer ohne Berechtigungen nicht über DAX oder andere Methoden auf geschützte Metadatenobjekte zugreifen. Aus Sicht von Benutzern ohne entsprechende Zugriffsberechtigungen sind gesicherte Tabellen und Spalten einfach nicht vorhanden.

  Die Sicherheit auf Objektebene ermöglicht zusammen mit der Sicherheit auf Zeilenebene eine verbesserte Sicherheit auf Unternehmensniveau für Berichte und semantische Modelle, sodass nur Benutzer mit den erforderlichen Berechtigungen Zugriff auf die Anzeige und Interaktion mit vertraulichen Daten haben.

Wie werden Daten in den Power BI-Dienst übertragen?

• Alle von Power BI angeforderten und übertragenen Daten werden bei der Übertragung 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. Eine sichere Verbindung mit dem Datenanbieter wird hergestellt. Die Datenübertragung über das Netzwerk erfolgt erst, wenn diese Verbindung hergestellt wurde.

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

• Wenn auf eine Datenquelle zugegriffen wird, befolgt der Power BI-Dienst den Prozess, der weiter oben in diesem Artikel im Abschnitt Authentifizierung in Datenquellen erläutert wurde.

Speichern Clients Webseitendaten lokal im Cache?

• Wenn Browserclients auf Power BI zugreifen, legen die Power BI-Webserver die Direktive Cache-Control (Cache-Steuerung) auf no-store (nicht-speichern) fest. Die no-store-Direktive (nicht-speichern) befiehlt Browsern, die Webseite, die vom Benutzer angesehen wird, nicht im Cache zu speichern, und die Webseite auch nicht im Cacheordner des Clients zu speichern.

Wie sieht es mit rollenbasierter Sicherheit, der Freigabe von Berichten oder Dashboards und Datenverbindungen aus? Wie funktioniert das im Bezug auf Datenzugriff, Anzeige von Dashboards und Zugriff auf oder Aktualisierung von Berichten?

• Wenn ein Dashboard, Bericht oder Datenmodell bei Datenquellen, für die keine Sicherheit auf Rollenebene (Role Level Security, RLS) aktiviert wurde, für andere Benutzer über Power BI freigegeben wurde, sind Daten für die Benutzer verfügbar, für die freigegeben wurde, diese anzusehen und mit diesen zu interagieren. Power BI authentifiziert Benutzer nicht noch einmal für die ursprüngliche Datenquelle. Sobald Daten in Power BI hochgeladen wurden, ist der Benutzer, der sich für die Datenquelle authentifiziert hat, verantwortlich zu verwalten, welche anderen Benutzer und Gruppen sich die Daten ansehen können.

  Wenn Datenverbindungen mit einer Datenquelle, die zu RLS fähig ist, hergestellt werden, z.B. zu einer Analysis Services-Datenquelle, werden nur Dashboard-Daten in Power BI im Cache gespeichert. Jedes Mal, wenn ein Bericht oder ein semantisches Modell in Power BI angesehen oder auf ihn bzw. es zugegriffen wird und dabei Daten aus der zu RLS fähigen Datenquelle verwendet werden, greift der Power BI-Dienst auf die Datenquelle zu, um Daten auf Grundlage der Anmeldeinformationen des Benutzers zu erhalten. Wenn dann ausreichende Berechtigungen bestehen, werden die Daten für diesen Benutzer in den Bericht oder das Datenmodell geladen. Wenn die Authentifizierung fehlschlägt, wird ein Fehler für den Benutzer zurückgegeben.

  Weitere Informationen finden Sie weiter oben in diesem Artikel im Abschnitt Authentifizierung in Datenquellen.

Unsere Benutzer*innen verbinden sich ständig mit derselben Datenquelle. Dafür werden aber manchmal Anmeldeinformationen benötigt, die sich von deren Domänenanmeldeinformationen unterscheiden. Wie kann vermieden werden, dass diese Anmeldeinformationen jedes Mal eingegeben werden müssen, wenn eine Datenverbindung hergestellt werden soll?

• Power BI bietet das Power BI Personal Gateway, ein Feature, das Benutzern die Erstellung von Anmeldeinformationen für mehrere unterschiedliche Datenquellen ermöglicht, und dann diese Anmeldeinformationen automatisch verwendet, wenn anschließend auf eine dieser Datenquellen zugegriffen wird. Weitere Informationen zum Power BI Personal Gateway.

Welche Ports werden von lokalen Datengateways und persönlichen Gateways verwendet? Gibt es Domänennamen, die aus Konnektivitätsgründen zugelassen werden müssen?

• Eine detaillierte Antwort auf diese Frage erhalten Sie unter folgendem Link: Gateway-Ports

Wie werden Wiederherstellungsschlüssel verwendet und wo werden sie gespeichert, wenn mit dem lokalen Datengateway gearbeitet wird? Wie sieht es mit sicherer Anmeldeinformationsverwaltung aus?

• Während der Installation und Konfiguration eines Gateway gibt der Administrator einen Wiederherstellungsschlüssel für das Gateway 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. Die Inhalte dieser Datei können nur von einem speziellen Windows-Computer entschlüsselt werden, und auch nur von diesem speziellen Gatewaydienstkonto.

  Wenn ein Benutzer in der Power BI-Benutzeroberfläche Datenquellenanmeldeinformationen 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 mit einem symmetrischen AES-Schlüssel erneut, bevor die Daten im Power BI-Dienst gespeichert werden. Durch diesen Prozess ist sichergestellt, dass der Power BI-Dienst niemals auf die nicht verschlüsselten Daten zugreifen kann.

Welche Kommunikationsprotokolle werden vom lokalen Datengateway verwendet, und wie werden sie geschützt?

• Das Gateway unterstützt die folgenden beiden Kommunikationsprotokolle:

  • AMQP 1.0 – TCP + TLS: Dieses Protokoll erfordert, dass die Ports 443, 5671-5672 und 9350-9354 für ausgehende Kommunikation geöffnet sind. Dieses Protokoll wird bevorzugt, da es einen geringeren Kommunikationsaufwand hat.

  • HTTPS – WebSockets über HTTPS + TLS: Dieses Protokoll verwendet nur Port 443. Das WebSocket-Protokoll wird von einer einzelnen Nachricht „HTTP CONNECT“ initiiert. Sobald der Kanal hergestellt wurde, erfolgt die Kommunikation im Grunde genommen über TCP+TLS. Sie können erzwingen, dass das Gateway dieses Protokoll verwendet, indem Sie eine Einstellung bearbeiten, die im Artikel Lokales Datengateway beschrieben wird.

Welche Rolle spielt Azure CDN in Power BI?

• Wie bereits erwähnt, verwendet Power BI Azure Content Delivery Network (CDN) für die effiziente Verteilung der erforderlichen statischen Inhalte und Dateien an Benutzer*innen basierend auf einem Gebietsschema. Um noch weiter ins Details zu gehen: Der Power BI-Dienst verwendet mehrere CDN, um den erforderlichen statischen Inhalt und Dateien effizient über das öffentliche Internet an Benutzer*innen zu verteilen. Diese statischen Dateien umfassen Downloads von Produkten (wie Power BI Desktop, dem lokalen Datengateway oder Power BI-Apps von verschiedenen unabhängigen Dienstanbietern), Browserkonfigurationsdateien, mit denen alle darauffolgenden Verbindungen mit Power BI initiiert und hergestellt werden, sowie die sichere erste Anmeldeseite für Power BI.

  Auf Grundlage der Informationen, die während der ersten Verbindung mit dem Power BI-Dienst bereitgestellt werden, kontaktiert der Browser eines Benutzers oder einer Benutzerin das angegebene Azure CDN bzw. für einige der Dateien den WFE-Cluster, um die Sammlung der angegebenen gemeinsamen Dateien herunterzuladen, die benötigt werden, um die Interaktion des Browsers mit dem Power BI-Dienst zu aktivieren. Die Browserseite enthält dann für die Dauer der Browsersitzung beim Power BI-Dienst das Microsoft Entra-Token, Sitzungsinformationen, den Speicherort des zugehörigen Back-End-Clusters sowie die Sammlung der Dateien, die vom Azure CDN und vom WFE-Cluster heruntergeladen wurden.

Beurteilt Microsoft bei Power BI-Visuals deren Code hinsichtlich Sicherheit und Datenschutz, bevor Elemente im Katalog veröffentlicht werden?

• Nein. Der Kunde ist dafür verantwortlich, zu prüfen und zu bestimmen, ob man sich auf den Code benutzerdefinierter Visuals verlassen kann. Der Code aller benutzerdefinierten Visuals wird in einer Sandboxumgebung ausgeführt, sodass sich fehlerhafter Code in einem benutzerdefinierten Visual nicht nachteilig auf den restlichen Power BI-Dienst auswirkt.

Gibt es andere Power BI-Visuals, die Informationen vom Netzwerk des Kunden nach außen senden?

• Ja. Bing-Karten und ESRI-Visuals übermitteln Daten vom Power BI-Dienst nach außen, wenn Visuals diese Dienste nutzen.

Beurteilt Microsoft bei Vorlagenapps diese hinsichtlich Sicherheit und Datenschutz, bevor Elemente im Katalog veröffentlicht werden?

• Nein. Der App-Herausgeber ist für den Inhalt verantwortlich, während der Kunde dafür verantwortlich ist, zu überprüfen und zu bestimmen, ob er dem Herausgeber der Vorlagen-App vertraut.

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.

Was ist mit Datenhoheit? Können wir Mandanten in Rechenzentren in bestimmten Regionen bereitstellen, um sicherzustellen, dass Daten das Land oder die Region nicht verlassen?

• Einige Kunden in bestimmten Regionen haben die Möglichkeit, einen Mandanten in einer nationalen/regionalen Cloud zu erstellen. Dort finden Datenspeicherung und -verarbeitung von allen anderen Datencentern getrennt statt. In nationalen/regionalen Clouds wird die Sicherheit anders gewährleistet, da ein separater Datentreuhänder den Power BI-Dienst der nationalen/regionalen Cloud 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 Datentresoren von Microsoft. Die Preise für nationale/regionale Clouds unterscheiden sich vom allgemein verfügbaren, kommerziellen Power BI-Dienst. Weitere Informationen zur Verfügbarkeit des Power BI-Diensts für nationale/regionale Clouds finden Sie unter Nationale/regionale Power BI-Clouds.

Wie behandelt Microsoft Verbindungen für Kunden, die über Power BI Premium-Abonnements verfügen? Unterscheiden sich diese Verbindungen von denen, die für den Power BI-Dienst ohne Premium eingerichtet werden?

• Die Verbindungen, die für Kunden mit Power BI Premium-Abonnements eingerichtet werden, implementieren einen Microsoft Entra Business-to-Business (B2B)-Autorisierungsprozess, bei dem Microsoft Entra ID für die Zugriffssteuerung und Autorisierung verwendet wird. Power BI behandelt Verbindungen von Power BI Premium-Abonnenten mit Power BI Premium-Ressourcen wie bei jedem anderen Microsoft Entra-Benutzer.

Wie funktioniert die serverseitige Authentifizierung im WFE?

• Die serverseitige Benutzerauthentifizierungssequenz läuft wie in den folgenden Schritten beschrieben ab und wird durch die Bilder veranschaulicht.

1. Ein Benutzer initiiert eine Verbindung zum Power BI-Dienst von einem Browser aus, indem er entweder die Power BI-Adresse in die Adressleiste eingibt oder auf Anmelden auf der Power BI-Marketingseite klickt (https://powerbi.microsoft.com). Die Verbindung wird mit TLS 1.2 und HTTPS hergestellt, und bei der gesamten weiteren Kommunikation zwischen dem Browser und dem Power BI-Dienst wird HTTPS verwendet.

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

3. Der WFE-Cluster leitet den Benutzer dann zur Anmeldeseite von Microsoft Online Services weiter.

4. Nachdem der Benutzer authentifiziert wurde, wird er von der Anmeldeseite mit einem Authentifizierungscode an den zuvor bestimmten nächstgelegenen WFE-Cluster des Power BI-Diensts weitergeleitet.

5. Der WFE-Cluster überprüft mit der Microsoft Entra-ID, um ein Microsoft Entra-Sicherheitstoken mithilfe des Authentifizierungscodes abzurufen. Wenn Microsoft Entra ID den Benutzer erfolgreich authentifiziert hat und ein Microsoft Entra-Sicherheitstoken zurückgibt, wendet sich der WFE-Cluster an den Power BI Global Service. Dort ist eine Liste von Mandanten und deren Power BI-Back-End-Clusterstandorten hinterlegt, und es wird ermittelt, welcher Cluster des Power BI-Back-End-Diensts den Mandanten des Benutzers enthält. Der WFE-Cluster gibt dann eine Anwendungsseite an den Browser des Benutzers mit den für den Betrieb erforderlichen Sitzungs-, Zugriffs- und Routinginformationen zurück.

6. Wenn nun der Browser des Clients Kundendaten benötigt, sendet er Anforderungen mit dem Microsoft Entra-Zugriffstoken im Autorisierungsheader an die Back-End-Clusteradresse. 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. Für das Microsoft Entra ID-Zugriffstoken ist ein Ablaufdatum gemäß den Microsoft Entra ID-Richtlinien festgelegt, und um die aktuelle Sitzung beizubehalten, stellt der Power BI-Client im Browser des Benutzers regelmäßig Anforderungen zur Verlängerung des Zugriffstokens, bevor es abläuft.

Zusätzliche Ressourcen

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

• Erste Schritte mit Power BI Desktop
• Power BI REST APIs – Overview (Power BI-REST-APIs – Übersicht)
• Power BI REST APIs (Power BI-REST-APIs)
• Lokales Datengateway
• Nationale/regionale Power BI-Clouds
• Power BI Premium
• Übersicht: Single Sign-On für Gateways in Power BI