Whitepaper zur Sicherheit in Power BI

Zusammenfassung: Power BI ist ein Online-Softwaredienstangebot (SaaS oder Software as a Service) von Microsoft, mit dem Sie einfach und schnell Self-Service-Business Intelligence-Dashboards, Berichte, Datasets 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.

Schriftsteller: 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.

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, -Datasets 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 von fortschrittlichen Technologien in Betrieb und Geschäftsentscheidungen. Und all dies wird von der Cloud unterstützt.

Da sich der Übergang zur Cloud von einem Trickle zu einer Flut geändert hat, und mit der neuen, offengelegten Oberfläche, die damit eingeht, fragen sich immer mehr Unternehmen, wie sicher sind meine Daten in der Cloud? und welchen End-to-End-Schutz ist verfügbar, um zu verhindern, dass meine vertraulichen Daten verloren gehen? 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 - 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 hat Microsoft massiv investiert, um seine Sicherheitsrisiken zu beheben, und in den folgenden Jahrzehnten einen sehr starken Sicherheitsstapel erstellt, der so tief wie der Computer-On-Chip-BIOS-Kernel reicht und sich bis hin zu Endbenutzererfahrungen erstreckt. Diese tiefgreifenden Investitionen werden fortgesetzt, und heute sind mehr als 3.500 Microsoft-Techniker damit beschäftigt, den Sicherheitsstapel von Microsoft zu erstellen und zu verbessern und proaktiv die sich ständig verändernde Bedrohungslandschaft zu bewältigen. Mit Milliarden von Computern, Billionen von Anmeldungen und unzähligen Zettabytes an Informationen, die Microsofts Schutz anvertraut sind, verfügt das Unternehmen jetzt über den fortschrittlichsten Sicherheitsstapel in der Technologiebranche und wird allgemein als globaler Marktführer im Kampf gegen böswillige Akteure angesehen.

Power BI baut auf dieser sehr starken Grundlage auf. Es verwendet denselben Sicherheitsstapel, der Azure das Recht erworben hat, die vertraulichsten Daten der Welt zu bedienen und zu schützen, und es ist in die fortschrittlichsten Informationsschutz- und Compliancetools von Microsoft 365 integriert. Darüber hinaus bietet es Sicherheit durch mehrschichtige Sicherheitsmaßnahmen, was zu einem End-to-End-Schutz führt, der auf die besonderen Herausforderungen des Cloudzeitalters ausgelegt ist.

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

• Wie steuern wir, wer eine Verbindung herstellen kann, von wo aus sie eine Verbindung herstellen und wie sie sich verbinden?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?
• Gewusst wie meine vertraulichen Daten kontrollieren und schützen?Gewusst wie sicherstellen, dass diese Daten nicht außerhalb des organization.
• Gewusst wie überwachen, wer welche Vorgänge durchführt?Gewusst wie schnell reagieren, wenn verdächtige Aktivitäten im Dienst vorliegen?

Dieser Artikel bietet eine umfassende Antwort auf all diese Fragen. Es beginnt mit einer Übersicht über die Dienstarchitektur und erläutert, wie die Standard flows 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 Speicherort der Datenverarbeitung finden Sie unter Standort der Datenverarbeitungsbedingungen in den Microsoft Online Services-Nutzungsbedingungen und im Datenschutz-Nachtrag. 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. Sdl unterstützt Entwickler beim Erstellen sichererer Software, indem die Anzahl und der Schweregrad von Sicherheitsrisiken in Software reduziert und gleichzeitig die Entwicklungskosten gesenkt werden. Weitere Informationen finden Sie unter Microsoft Security Development Lifecycle Practices.

Power BI-Architektur

Die 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 Clients möglicherweise mit dem Azure Traffic Manager, um das am besten geeignete (normalerweise nächstgelegene) Rechenzentrum mit einer Power BI-Bereitstellung zu finden. Weitere Informationen zu diesem Prozess finden Sie unter Leistungsdatenverkehrsroutingmethode für Azure Traffic Manager.

Statische Ressourcen wie *.js, *.css und Bilddateien werden größtenteils in 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. Es besteht aus mehreren Dienstendpunkten, die von Web-Front-End- und API-Clients verwendet 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 der Power BI-Dienst 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 werden, die für die Ausführung bestimmter Aufgaben, zustandsbehafteter 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 Microdiensten bereitgestellt, die auf verschiedenen Computern innerhalb des virtuellen Netzwerks des Clusters ausgeführt werden, auf die von außen nicht zugegriffen werden kann, mit Ausnahme von zwei Komponenten, auf die über das öffentliche Internet 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 wie Dataflows, paginierte Berichte, KI usw. benötigen. Wenn sich ein Kunde für ein Power BI Premium-Abonnement registriert, wird die Premium-Kapazität über die 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 verschiedene Arten hergestellt werden. 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). Der Großteil der Premium-Ressourcen wird in einem Cluster gekapselt (für instance, Compute), 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öhen von Ressourcen innerhalb von Clustern und/oder Hinzufügen von mehr Clustern bei Bedarf bei Bedarf (wenn Clusterressourcen sich 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 bei steigender Nutzung und orchestriert 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: Lastenausgleich, 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 in Azure AD.

Jede Anforderung, die an 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, verarbeiten sie oder leiten sie an die entsprechenden Ressourcen weiter (z. B. Back-End-Knoten).

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

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 fallen in zwei Kategorien:

• 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 Windows Mobile-App einen Broker angibt, um den Kommunikationskanal mit Power BI (für den Anmeldeprozess) einzurichten.

Die folgende Tabelle zeigt die Unterstützung der zertifikatbasierten Authentifizierung (Certificate-Based Authentication, CBA) für Power BI Mobile basierend auf der Plattform für mobile Geräte:

CBA-Unterstützung	iOS	Android	Windows
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. Telemetriedaten werden verwendet, um Nutzungsstatistiken für mobile Apps und ähnliche Daten zu sammeln, die an Dienste übertragen werden, die zur Überwachung der Nutzung und Aktivität verwendet werden. Es werden keine Kundendaten mit Telemetriedaten gesendet.

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

• Azure AD und Aktualisierungstoken werden unter Verwendung branchenüblicher Sicherheitsmaßnahmen in einem sicheren Mechanismus auf dem Gerät gespeichert.
• 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. Unter Android kann dies in den Einstellungen konfiguriert werden. Unter Windows erfolgt dies mithilfe von BitLocker.
• 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.
• Geolocation wird vom Benutzer explizit aktiviert oder deaktiviert. Wenn diese Option aktiviert ist, werden geolocation-Daten nicht auf dem Gerät gespeichert und nicht für Microsoft freigegeben.
• Benachrichtigungen werden vom Benutzer explizit aktiviert oder deaktiviert. Wenn diese Option aktiviert ist, unterstützen Android und iOS keine anforderungen an die geografische Datenresidenz für Benachrichtigungen.

Die Datenverschlüsselung kann verbessert werden, indem Verschlüsselung auf Dateiebene über Microsoft Intune angewendet wird, einem Softwaredienst, der die Verwaltung mobiler Geräte und Anwendungen bereitstellt. Alle drei Plattformen, für die Power BI Mobile verfügbar sind, 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, stehen einige gesicherte Speicherwerte im Zusammenhang mit der tokenbasierten Authentifizierung für andere Microsoft-Apps von Drittanbietern (z. B. Microsoft Authenticator) zur Verfügung und werden vom ADAL-SDK (Azure Active Directory Authentication Library) verwaltet.

Power BI Mobile zwischengespeicherten Daten werden gelöscht, wenn die App entfernt wird, wenn sich der Benutzer von Power BI Mobile abmeldet oder wenn sich der Benutzer nicht anmeldet (z. B. nach einem Tokenablaufereignis 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 Identifizierungen konfigurieren, z. B. Gesichts-ID, Touch-ID oder eine Kennung für iOS und biometrische Daten (Fingerabdruck-ID) für Android. Erfahren Sie mehr über zusätzliche Identifizierung.

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. Diese Sequenz beschreibt den Prozess der Benutzerauthentifizierung in Power BI, der dem Authentifizierungscode-Gewährungsflow von Azure Active Directory folgt. Weitere Informationen zu Optionen für die Benutzerauthentifizierungsmodelle eines organization (Anmeldemodelle) finden Sie unter Auswählen eines Anmeldemodells für Microsoft 365.

Authentifizierungssequenz

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

1. Ein Benutzer initiiert über einen Browser eine Verbindung mit dem Power BI-Dienst, indem er entweder die Power BI-Adresse in der Adressleiste eingibt oder auf der Power BI-Marketingseite (https://powerbi.microsoft.com) anmelden auswählt. 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. Azure Traffic Manager überprüft den DNS-Eintrag des Benutzers, um das am besten geeignete (normalerweise nächstgelegene) Rechenzentrum zu ermitteln, in dem Power BI bereitgestellt wird, und antwortet auf das DNS mit der IP-Adresse des WFE-Clusters, an den 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 Anmeldeflows erforderlich ist.

4. Der Browserclient lädt die von der WFE empfangene HTML-Seite und leitet den Benutzer zur Anmeldeseite für Microsoft Online Services 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) vom Azure AD-Dienst anzufordern.

7. Die Mandanten-ID des Benutzers wird vom Browserclient verwendet, um den globalen Power BI-Dienst abzufragen, der eine Liste der Mandanten und deren Power BI-Back-End-Clusterspeicherorte 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 jetzt mit der URL-API des Power BI-Back-End-Clusters kommunizieren, indem das Zugriffstoken im Autorisierungsheader für die HTTP-Anforderungen verwendet wird. Für das Azure AD-Zugriffstoken wird ein Ablaufdatum gemäß den Azure AD-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 sehr 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 Authentifizierungsablauf 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 Azure AD-Mandant zum ersten Mal für Power BI-Dienste registriert. Ein Azure AD-Mandant enthält die Benutzer- und Anwendungsidentitäten, Gruppen und andere relevante Informationen, die sich auf ein organization und dessen Sicherheit beziehen.

Die Zuweisung einer Azure-Geografie für die Mandantendatenspeicherung erfolgt durch Zuordnung des Landes bzw. der Region, das bzw. die im Rahmen der Einrichtung des Azure AD-Mandanten ausgewählt wurde, der 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 Geografische Regionen (multi-geo)

Einige Organisationen sind global präsent und benötigen möglicherweise Power BI-Dienste in mehreren Azure-Regionen. Beispielsweise kann ein Unternehmen seinen Hauptsitz in der USA aber auch in anderen geografischen Gebieten wie 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 einzuhalten. Dieses Feature der Power BI-Dienst wird als Multi-Geo bezeichnet.

Die Abfrageausführungsebene, Abfragecaches und Artefaktdaten, die einem Arbeitsbereich mit mehreren geografischen Standorten zugewiesen sind, werden gehostet und verbleiben in der Azure-Remotekapazität. Einige Artefaktmetadaten, z. B. die Berichtsstruktur, bleiben jedoch möglicherweise im Ruhezustand im Geografischen Standort des Mandanten gespeichert. Darüber hinaus können einige Datenübertragungen und -verarbeitungen weiterhin im Geografischen Standort des Mandanten erfolgen, selbst für Arbeitsbereiche, die in einer Premium-Kapazität mit mehreren Geografischen Gehostet werden.

Weitere Informationen zum Erstellen und Verwalten von Power BI-Bereitstellungen, die mehrere Azure-Regionen umfassen, finden Sie unter Konfigurieren der 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 dazu, wo Ihre Daten gespeichert werden und wie sie verwendet werden, finden Sie im Microsoft Trust Center. Verpflichtungen in Bezug auf den Speicherort ruhender Kundendaten sind in den Datenverarbeitungsbedingungen der Microsoft Online Services-Nutzungsbedingungen angegeben.

Microsoft stellt auch Rechenzentren für souveräne Entitäten bereit. Weitere Informationen zur Verfügbarkeit des Power BI-Diensts für nationale Clouds finden Sie unter Nationale Power BI-Clouds.

Datenverarbeitung

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 beizubehalten.

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 mithilfe der Transparent Data Encryption-Technologie (TDE) von Azure SQL vollständig verschlüsselt. Kundendaten, die in Azure Blob Storage gespeichert sind, werden mit Azure Storage Encryption 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 Dataset importiert werden. Dieser Ansatz wird als Bring Your Own Key (BYOK) bezeichnet. Die Verwendung von BYOK trägt dazu bei, dass auch im Falle eines Fehlers des Serviceoperators keine Kundendaten verfügbar gemacht werden – was mit transparenter dienstseitiger Verschlüsselung nicht einfach erreicht werden kann. Weitere Informationen finden Sie unter Bring Your Own Encryption Keys für Power BI .

Power BI-Datasets ermöglichen eine Vielzahl von Datenquellenverbindungsmodi, die bestimmen, ob die Datenquellendaten im Dienst beibehalten werden oder nicht.

Datasetmodus (Art)	In Power BI persistente Daten
Importieren	Ja
Direkte Abfrage	Nein
Live Connect	Nein
Composite	Wenn eine Importdatenquelle enthält
Streaming	Wenn für die Beibehaltung konfiguriert

Unabhängig vom verwendeten Datasetmodus kann Power BI alle abgerufenen Daten vorübergehend zwischenspeichern, um die Abfrage- und Berichtsladeleistung zu optimieren.

Daten in der Verarbeitung

Daten werden verarbeitet, wenn sie entweder aktiv von einem oder mehreren Benutzern im Rahmen 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 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 mit den Anmeldeinformationen auf die Daten zu. Nachdem das Dataset im Power BI-Dienst veröffentlicht wurde, verwendet Power BI immer die Anmeldeinformationen dieses Benutzers, um Daten zu importieren. Nach dem Importieren von Daten greift das Anzeigen der Daten in Berichten und Dashboards nicht mehr auf die zugrunde liegende Datenquelle zu. 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 Datasetbesitzers 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 mithilfe des einmaligen Anmeldens direkt 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 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, auf die sie über Zugriffsberechtigungen verfügen. Wenn die Verbindung mit Datenquellen in der Cloud besteht, wird die Azure AD-Authentifizierung für einmaliges Anmelden verwendet. für lokale Datenquellen werden Kerberos, Security Assertion Markup Language (SAML) und Azure AD unterstützt.

Wenn die Datenquelle Azure Analysis Services oder lokalen Analysis Services ist und RLS und/oder OLS konfiguriert sind, wendet der Power BI-Dienst die Sicherheit auf Zeilenebene an und Benutzer, die nicht über ausreichende Anmeldeinformationen für den Zugriff auf die zugrunde liegenden Daten verfügen (dies kann eine Abfrage sein, die in einer Dashboard , Bericht oder ein anderes Datenartefakt) 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, kann jedes Mitglied, Mitwirkender oder Administrator des Arbeitsbereichs Aktualisierungen planen sowie den Dataflow anzeigen und bearbeiten, indem er den Besitz davon übernimmt.

Jede konfigurierte Datenquelle ist für den Zugriff auf diese Datenquelle an eine Clienttechnologie gebunden. Die Struktur der Anmeldeinformationen, die für den Zugriff auf sie 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 in der Verarbeitung .

Wenn vom Kunden angegebene Datenquellen Anmeldeinformationen für den Zugriff benötigen, stellt der Besitzer/Ersteller des Dataflows diese während der Erstellung bereit. Sie werden mithilfe des standardmäßigen produktweiten Anmeldeinformationsspeichers gespeichert. Weitere Informationen finden Sie oben im Abschnitt Authentifizierung für 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 abgelegt. 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 Daten im Ruhezustand . Benutzer können jedoch ihr eigenes Speicherkonto konfigurieren, das ihrem eigenen Azure-Abonnement zugeordnet ist. Dabei wird einem Power BI-Dienst Prinzipal 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 für das konfigurierte ADLS-Speicherkonto 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, 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 von denselben 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 Über 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 Azure AD 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 Azure AD-Token wird verwendet, um direkt vom Browser an den Power BI Premium-Cluster zu kommunizieren.

In Power BI Premium stellt die Power BI-Dienst Runtime eine entsprechend isolierte Ausführungsumgebung für jedes Berichtsrendern 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 Standard Modi zum Einbetten von Power BI-Artefakten in ihre Webanwendungen und Portale: Einbetten für Ihre organization 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 einem Einbettungsszenario für Ihre organization greifen Azure AD-Benutzer über von ihren Unternehmen und ITs angepasste Portale auf ihre eigenen Power BI-Inhalte zu. Alle in diesem Dokument beschriebenen Power BI-Richtlinien und -Funktionen wie Zeilenebenensicherheit (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.

In einem Einbettungsszenario für Ihre Kunden besitzen ISVs in der Regel Power BI-Mandanten und Power BI-Artefakte (Dashboards, Berichte, Datasets 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 ist. ISV-Richtlinienentscheidungen werden in einem von Power BI generierten Einbettungstoken verschlüsselt und an das ISV-Back-End für die weitere 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 Authorization: EmbedToken-Header 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 dienstprinzipale Azure AD-Methoden der Authentifizierung und Autorisierung.

Eingebettete Power BI-Analysen 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 Key-Influencers, Decomposition-Tree, Smart-Narrative, Anomalieerkennung, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights usw. Die KI-Anreicherungsfunktionen umfassen Funktionen wie AutoML, 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 kann ein Benutzer heute 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 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/Dataset 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-Dataset oder -Dataflow verwendet werden. Beachten Sie, dass auf diese Funktionen auch über aktuelle Dataflow-/Dataseterstellungsumgebungen 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 Azure AD-Token für den Power BI-Benutzer erfordert, der die KI-Funktion verwendet. Diese KI-Datenquellen sind besonders, da sie keine ihrer eigenen Daten enthalten 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 kapazität des Power BI Premium auszuführen. Heute werden diese APIs sowohl in Power BI-Dataflows als auch in Datasets unterstützt. Beim Erstellen eines Datasets 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 Azure AD-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 abschnitten unten.

Diensttags

Ein Diensttag steht für eine Gruppe von IP-Adresspräfixen eines bestimmten Azure-Diensts. Dies trägt dazu bei, die Komplexität häufiger Updates von 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 Sie Sicherheitsregeln erstellen. Durch Angabe des Diensttagnamens (z PowerBI. B. ) im entsprechenden Quell- oder Zielfeld (für APIs) einer Regel 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. Bei Azure Private Link und privaten Endpunkten wird der Datenverkehr privat über die Backbone-Netzwerkinfrastruktur von Microsoft gesendet, sodass die Daten nicht über das Internet geleitet werden.

Private Link stellt sicher, dass Power BI-Benutzer den privaten Microsoft-Netzwerk-Backbone verwenden, wenn sie zu Ressourcen im Power BI-Dienst wechseln.

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

• Private Link stellt sicher, dass der Datenverkehr über den Azure-Backbone zu einem privaten Endpunkt für cloudbasierte Azure-Ressourcen fließt.
• Die Isolation des Netzwerkdatenverkehrs von einer nicht azurebasierten Infrastruktur, z. B. dem lokalen Zugriff, erfordert, dass Kunden ExpressRoute oder ein VIRTUELLEs privates Netzwerk (VPN) konfigurieren müssen.

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

VNET-Konnektivität (Vorschau – in Kürze verfügbar)

Während die Private Link-Integrationsfunktion 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 das Herstellen einer Verbindung mit Datenquellen vermieden, 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 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, die Datenquellendetails und die Anmeldeinformationen an den Power Platform-VNet-Dienst (PP-VNet).

2. Der PP-VNet-Dienst fügt dann einen Container, der ein VNET-Gateway ausführt, sicher in das Subnetz ein. 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, die Datenquellendetails und die Anmeldeinformationen an das VNet-Gateway.

4. Das VNET-Gateway ruft die Abfrage ab und stellt mit diesen 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 pusht die Daten sicher aus dem Container an den Power BI-Clouddienst.

Dieses Feature wird in Kürze in der öffentlichen Vorschau verfügbar sein.

Dienstprinzipale

Power BI unterstützt die Verwendung von Dienstprinzipalen. Speichern Sie alle Dienstprinzipalanmeldeinformationen, die für die Verschlüsselung oder den Zugriff auf Power BI verwendet werden, in einem Key Vault, weisen Sie dem Tresor die richtigen Zugriffsrichtlinien zu, und überprüfen Sie die Zugriffsberechtigungen regelmäßig.

Weitere Details finden Sie unter Automatisieren von Arbeitsbereichs- und Datasettasks mit Dienstprinzipalen .

Microsoft Purview für Power BI

Microsoft Purview Information Protection

Power BI ist tief in Microsoft Purview Information Protection (zuvor Microsoft 365 Compliance 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 sind, 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 geschäftsvertraute Daten 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-Datasets 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 Datasets oder Datamarts im Power BI-Dienst angewendet werden, auf neue Inhalte angewendet werden, die auf diesen Datasets 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 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 Dataset oder Datamart verbunden sind, wenn eine Bezeichnung auf ein Dataset oder datamart angewendet oder geändert wird.

Weitere Informationen finden Sie unter Vertraulichkeitsbezeichnungen in Power BI.

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

Die DLP-Richtlinien von Microsoft Purview können Organisationen dabei helfen, das Risiko von Datenlecks vertraulicher Geschäftsdaten aus Power BI zu verringern. DLP-Richtlinien können ihnen dabei helfen, 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 Datasets 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 Dataset stoßen, das als vertraulich identifiziert wurde, sehen Sie einen benutzerdefinierten Richtlinientipp, der Ihnen hilft, zu verstehen, was Sie tun sollten.
• Wenn Sie ein Datasetbesitzer sind, können Sie eine Richtlinie überschreiben und verhindern, dass Ihr Dataset als "vertraulich" identifiziert wird, wenn Sie einen gültigen Grund dafür haben.
• Wenn Sie ein Datasetbesitzer 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 zur Verhinderung von Datenverlust für 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 für Cloud-Apps wird verwendet, um die Verwendung von Cloud-Apps zu schützen. Sie ermöglicht Es 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 for Cloud Apps können Organisationen die folgenden DLP-Funktionen nutzen:

• Legen Sie Echtzeitsteuerelemente fest, 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 Sie die Power BI-Benutzeraktivität mit dem Defender für Cloud Apps-Aktivitätsprotokoll. Das Defender für Cloud Apps-Aktivitätsprotokoll enthält Power BI-Aktivitäten, die im Office 365-Überwachungsprotokoll erfasst sind, 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 für Cloud Apps und schnelle Aktionen für eine effektive Problemuntersuchung nutzen.
• Erstellen Sie benutzerdefinierte Richtlinien, um bei verdächtigen Benutzeraktivitäten in Power BI zu warnen. Die Aktivitätsrichtlinienfunktion von Defender für Cloud Apps kann verwendet werden, um Ihre eigenen benutzerdefinierten Regeln zu definieren, um Benutzerverhalten zu erkennen, das von der Norm abweicht, und möglicherweise sogar automatisch darauf zu reagieren, wenn es zu gefährlich erscheint.
• Arbeiten Sie mit der integrierten Anomalieerkennung von Defender für Cloud Apps. Die Defender für Cloud Apps-Richtlinien zur Erkennung von Anomalien 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 für Cloud Apps-Portal. Defender für Cloud Apps bietet eine app-spezifische 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, 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 Thema 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 Übermittlungszeitachsen ändern, und die projizierten Funktionen werden möglicherweise später als März 2021 veröffentlicht oder überhaupt nicht veröffentlicht. Weitere Informationen zu Vorschauversionen finden Sie in den Nutzungsbedingungen 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 werden basierend darauf organisiert, wann sie zu diesem Whitepaper hinzugefügt wurden, damit Sie schnell neue Fragen und Antworten finden können, wenn dieses Papier 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 Gateway-Admin verwaltet werden. Beim Konfigurieren eines Datasets kann der Benutzer anmeldeinformationen aus dem persönlichen Speicher auswählen oder ein lokales Datengateway verwenden, um freigegebene Anmeldeinformationen zu verwenden.

  Im Importfall stellt ein Benutzer eine Verbindung basierend auf der Anmeldung des Benutzers her und greift mit den Anmeldeinformationen auf die Daten zu. Nachdem das Dataset in Power BI-Dienst veröffentlicht wurde, verwendet Power BI immer die Anmeldeinformationen dieses Benutzers, um Daten zu importieren. Nach dem Importieren der Daten greift das Anzeigen der Daten in Berichten und Dashboard nicht mehr auf die zugrunde liegende Datenquelle zu. 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 Datasetbesitzers 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 mithilfe des einmaligen Anmeldens direkt verbunden ist, werden die Anmeldeinformationen des aktuellen Benutzers verwendet, um eine Verbindung mit der Datenquelle herzustellen, 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 Azure AD-Authentifizierung für einmaliges Anmelden verwendet. für lokale Datenquellen werden Kerberos, SAML und Azure AD unterstützt.

  Beim Herstellen einer Verbindung mit Kerberos wird der UPN des Benutzers an das Gateway übergeben. Mithilfe der eingeschränkten Kerberos-Delegierung wird der Benutzer identitätswechselt 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 lokalen Analysis Services und Row Level Security (RLS) und/oder Objektebenensicherheit (OLS) konfiguriert ist, wendet der Power BI-Dienst die Sicherheit auf Zeilenebene an, und Benutzer, die nicht über ausreichende Anmeldeinformationen für den Zugriff auf die zugrunde liegenden Daten verfügen (dies kann eine Abfrage sein, die in einer Dashboard , Bericht oder ein anderes Datenartefakt) werden keine Daten angezeigt, für die der Benutzer nicht über ausreichende Berechtigungen verfügt.

  Die Sicherheit auf Zeilenebene mit Power BI kann verwendet werden, um den Datenzugriff für bestimmte Benutzer einzuschränken. Filter beschränken den Datenzugriff auf Zeilenebene, und Sie können Filter innerhalb der Rolle 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 in der Feldliste verschleiert, 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 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 Datasets, wodurch sichergestellt wird, dass nur Benutzer mit den erforderlichen Berechtigungen Zugriff zum Anzeigen und Interagieren 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, folgt der Power BI-Dienst dem Prozess, der weiter oben in diesem Dokument im Abschnitt Authentifizierung für Datenquellen beschrieben ist.

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, Ansicht 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 RLS-fähigen Datenquelle hergestellt werden, z. B. einer Analysis Services-Datenquelle, werden nur Dashboard Daten in Power BI zwischengespeichert. Jedes Mal, wenn ein Bericht oder ein Dataset 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 Dokument im Abschnitt Authentifizierung für Datenquellen .

Unsere Benutzer 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?

• Die ausführliche Antwort auf diese Frage finden Sie unter folgendem Link: Gatewayports

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: Für dieses Protokoll müssen die Ports 443, 5671-5672 und 9350-9354 für ausgehende Kommunikation geöffnet sein. 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 ändern, die im Artikel zum lokalen Gateway beschrieben wird.

Welche Rolle spielt Azure CDN in Power BI?

• Wie bereits erwähnt, verwendet Power BI das Azure Content Delivery Network (CDN) für die effiziente Verteilung der erforderlichen statischen Inhalte und Dateien an Benutzer 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 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 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 das Azure AD-Token, Sitzungsinformationen, den Speicherort des zugeordneten Back-End-Clusters und die Sammlung von Dateien, die für die Dauer der Power BI-Dienst Browsersitzung aus dem Azure CDN- und WFE-Cluster heruntergeladen wurden.

Führt Microsoft für Power BI-Visuals eine Sicherheits- oder Datenschutzbewertung des benutzerdefinierten visuellen Codes durch, 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.

Führt Microsoft für Vorlagen-Apps eine Sicherheits- oder Datenschutzbewertung der Vorlagen-App durch, bevor Elemente im Katalog veröffentlicht werden?

• Nein. Der App-Herausgeber ist für den Inhalt verantwortlich, während es in der Verantwortung des Kunden liegt, zu überprüfen und zu bestimmen, ob er dem Herausgeber der Vorlagen-App vertrauen soll.

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 die Daten die Landes- oder Regionsgrenzen nicht verlassen?

• Einige Kunden in bestimmten Regionen haben die Möglichkeit, einen Mandanten in einer nationalen Cloud zu erstellen. Dort finden Datenspeicherung und -verarbeitung von allen anderen Datencentern getrennt statt. In nationalen Clouds wird die Sicherheit anders gewährleistet, da ein separater Datentreuhänder den Power BI-Dienst der nationalen 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 Clouds unterscheiden sich vom allgemein verfügbaren, kommerziellen Power BI-Dienst. Weitere Informationen zur Verfügbarkeit des Power BI-Diensts für nationale Clouds finden Sie unter Nationale 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 für Kunden mit Power BI Premium Abonnements hergestellten Verbindungen implementieren einen Azure Business-to-Business-Autorisierungsprozess (B2B), der Azure AD verwendet, um die Zugriffssteuerung und Autorisierung zu ermöglichen. Power BI behandelt Verbindungen von Power BI Premium-Abonnenten mit Power BI Premium-Ressourcen wie bei jedem anderen Azure AD-Benutzer.

Wie funktioniert die serverseitige Authentifizierung in der WFE?

• Die dienstseitige Authentifizierung der Benutzerauthentifizierungssequenz erfolgt wie in den folgenden Schritten beschrieben, die in der folgenden Abbildung veranschaulicht werden.

1. Ein Benutzer initiiert über einen Browser eine Verbindung mit dem Power BI-Dienst, indem er entweder die Power BI-Adresse in der Adressleiste eingibt oder auf der Power BI-Marketingseite (https://powerbi.microsoft.com) anmelden auswählt. 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. Azure Traffic Manager überprüft den DNS-Eintrag des Benutzers, um das am besten geeignete (normalerweise nächstgelegene) Rechenzentrum zu ermitteln, in dem Power BI bereitgestellt wird, und antwortet auf das DNS mit der IP-Adresse des WFE-Clusters, an den der Benutzer gesendet werden soll.

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

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

5. Der WFE-Cluster überprüft mit dem Azure AD-Dienst, um mithilfe des Authentifizierungscodes ein Azure AD-Sicherheitstoken abzurufen. Wenn Azure AD die erfolgreiche Authentifizierung des Benutzers zurückgibt und ein Azure AD-Sicherheitstoken zurückgibt, konsultiert der WFE-Cluster den globalen Power BI-Dienst, der eine Liste der Mandanten und ihrer Power BI-Back-End-Clusterstandorte verwaltet und bestimmt, welcher Power BI-Back-End-Dienstcluster 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 der Browser des Clients Nun Kundendaten benötigt, sendet er Anforderungen an die Back-End-Clusteradresse mit dem Azure AD-Zugriffstoken im Autorisierungsheader. Der Power BI-Back-End-Cluster liest das Azure AD-Zugriffstoken und überprüft die Signatur, um sicherzustellen, dass die Identität für die Anforderung gültig ist. Für das Azure AD-Zugriffstoken ist ein Ablaufdatum gemäß Den Azure AD-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)
• On-premises data gateway (Lokales Datengateway)
• Nationale Power BI-Clouds
• Power BI Premium
• Übersicht: Single Sign-On für Gateways in Power BI