Power BI-Implementierungsplanung: Inhaltsersteller-Sicherheitsplanung

Hinweis

Dieser Artikel ist Teil der Artikelreihe zur Power BI-Implementierungsplanung. Diese Reihe konzentriert sich hauptsächlich auf die Power BI-Erfahrung in Microsoft Fabric. Eine Einführung in die Artikelreihe finden Sie unter Power BI-Implementierungsplanung.

In diesem Artikel zur Sicherheitsplanung werden Strategien für Inhaltsersteller beschrieben, die für die Erstellung semantischer Modelle, Datenflüsse, Datenmarts, Berichte oder Dashboards verantwortlich sind. Er wendet sich in erster Linie an folgende Zielgruppen:

• Power BI-Administrator*innen: Administrator*innen, die für die Überwachung von Power BI in der Organisation verantwortlich sind.
• Center of Excellence-, IT- und BI-Team: Die Teams, die ebenfalls für die Überwachung von Power BI verantwortlich sind. Sie müssen möglicherweise mit Power BI-Administratoren, Informationssicherheitsteams und anderen relevanten Teams zusammenarbeiten.
• Inhaltserstellende und -besitzende: Self-Service-BI-Erstellende, die Inhalte erstellen, veröffentlichen, schützen und verwalten müssen, die von anderen genutzt werden.

Die Artikelreihe soll den Inhalt des Whitepapers zur Power BI-Sicherheit erweitern. Während sich das Whitepaper mit wichtigen technischen Themen wie Authentifizierung, Datenresidenz und Netzwerkisolation befasst, ist es Anliegen der Artikelreihe, Ihnen bei der Planung von Sicherheit und Datenschutz durch ausführliche Informationen fundierte Entscheidungen zu ermöglichen.

In einer Organisation sind viele Benutzende Inhaltserstellende. Inhaltserstellende produzieren und veröffentlichen Inhalte, die von anderen angezeigt werden. Inhaltserstellende stehen im Mittelpunkt dieses Artikels.

Tipp

Es wird empfohlen, zuerst den Artikel Planung der Sicherheit für Berichtsconsumer zu lesen. Darin werden Strategien zum sicheren Bereitstellen von Inhalten für schreibgeschützte Consumer beschrieben, einschließlich der Erzwingung von Datensicherheit.

Strategie für Inhaltserstellende

Das Fundament eines gut kontrollierten Self-Service-BI-Systems beginnt bei den Inhaltserstellenden und -besitzenden. Sie erstellen und überprüfen Semantikmodelle und Berichte. In vielen Fällen richten Inhaltserstellende auch Berechtigungen ein, um die Sicherheit für ihre Inhalte zu verwalten.

Tipp

Es wird empfohlen, eine Datenkultur zu fördern, die Sicherheit und Schutz von Daten zu einem normalen Bestandteil der Rolle aller Beteiligten macht. Um dieses Ziel zu erreichen, sind Bildung, Support und Schulung der Benutzenden unerlässlich.

Aus Sicherheits- und Berechtigungsgründen sollten Sie berücksichtigen, dass es zwei Arten von Inhaltserstellenden gibt: Datenerstellende und Berichtserstellende. Sie können für die Erstellung und Verwaltung von Enterprise BI- oder Self-Service-BI-Inhalten verantwortlich sein.

Datenerstellende

Datenerstellende sind alle Power BI-Benutzer*innen, die Semantikmodelle, Dataflows oder Datamarts erstellen.

Hier sehen Sie einige gängige Szenarien mit Datenerstellenden.

• Erstellen eines neuen Semantikmodells: Sie erstellen und testen ein neues Datenmodell in Power BI Desktop. Dieses wird dann im Power BI-Dienst veröffentlicht, sodass es als freigegebenes Semantikmodell für viele Berichte verwendet werden kann. Weitere Informationen zur Wiederverwendung freigegebener Semantikmodelle finden Sie im Anwendungsszenario zur verwalteten Self-Service-BI.
• Erweitern und Anpassen eines Semantikmodells: Sie erstellen eine Liveverbindung mit einem vorhandenen freigegebenen Semantikmodell in Power BI Desktop. Konvertieren Sie die Liveverbindung in ein lokales Modell, wodurch das Modelldesign mit neuen Tabellen oder Spalten erweitert werden kann. Weitere Informationen zum Erweitern und Anpassen freigegebener Semantikmodelle finden Sie im Anwendungsszenario zur anpassbaren verwalteten Self-Service-BI.
• Erstellen eines neuen Dataflows: Sie erstellen im Power BI-Dienst einen neuen Dataflow, damit er von vielen Semantikmodellen als Quelle verwendet werden kann. Weitere Informationen zur Wiederverwendung von Datenaufbereitungsaktivitäten finden Sie im Anwendungsszenario zur Self-Service-Datenaufbereitung.
• Erstellen eines neuen Datamarts. Sie erstellen im Power BI-Dienst einen neuen Datamart.

Datenerstellende finden sich häufig in Enterprise BI-Teams und im Center of Excellence (COE). Sie spielen auch eine wesentliche Rolle in dezentralisierten Geschäftseinheiten und Abteilungen, die ihre eigenen Daten pflegen und verwalten.

Weitere Überlegungen zu unternehmensgesteuerter BI, verwalteter Self-Service-BI und Enterprise BI finden Sie im Artikel Besitz und Verwaltung von Inhalten.

Berichtsersteller

Berichtserstellende erstellen Berichte und Dashboards, um Daten zu visualisieren, die aus vorhandenen Semantikmodellen stammen.

Hier sehen Sie einige gängige Szenarien mit Berichtserstellenden.

• Erstellen eines neuen Berichts, einschließlich eines Datenmodells: Sie erstellen und testen einen neuen Bericht und ein neues Datenmodell in Power BI Desktop. Die Power BI Desktop-Datei, die eine oder mehrere Berichtsseiten enthält und ein Datenmodell umfasst, wird im Power BI-Dienst veröffentlicht. Neue Inhaltserstellende verwenden diese Methode häufig, solange sie die Verwendung freigegebener Semantikmodelle noch nicht kennen. Sie eignet sich auch für eng abgegrenzte Anwendungsfälle, die keine Wiederverwendung von Daten erfordern.
• Erstellen eines Liveverbindungsberichts: Sie erstellen einen neuen Power BI-Bericht, der eine Verbindung mit einem freigegebenen Semantikmodell im Power BI-Dienst herstellt. Weitere Informationen zur Wiederverwendung freigegebener Semantikmodelle finden Sie im Anwendungsszenario zur verwalteten Self-Service-BI.
• Erstellen einer verbundenen Excel-Arbeitsmappe: Sie erstellen einen neuen Excel-Bericht, der eine Verbindung mit einem freigegebenen Semantikmodell im Power BI-Dienst herstellt. Verbundene Excel-Erfahrungen werden anstelle von Datendownloads dringend empfohlen.
• Erstellen eines DirectQuery-Bericht: Sie erstellen einen neuen Power BI-Bericht, der eine Verbindung mit einer unterstützten Datenquelle im DirectQuery-Modus herstellt. Eine Situation, in der diese Methode nützlich ist, ist, wenn Sie die Benutzendensicherheit ausnutzen möchten, die vom Quellsystem implementiert wird.

Berichtserstellende finden sich in jeder Geschäftseinheit innerhalb der Organisation. In einer Organisation gibt es in der Regel wesentliche mehr Berichtserstellende als Datenerstellende.

Tipp

Auch wenn nicht jedes Semantikmodell ein freigegebenes Semantikmodell ist, empfiehlt es sich, eine Strategie der verwalteten Self-Service-BI einzuführen. Bei dieser Strategie werden freigegebene Semantikmodelle wann immer möglich wiederverwendet. Auf diese Weise werden die Berichts- und Datenerstellung voneinander entkoppelt. Alle Inhaltserstellenden aus einer beliebigen Geschäftseinheit können diese Strategie effektiv nutzen.

Berechtigungen für Erstellende

In diesem Abschnitt werden die gängigsten Berechtigungen für Datenerstellende und Berichtserstellende beschrieben.

Dieser Abschnitt soll keine vollständige Liste aller möglichen Berechtigungen sein. Vielmehr soll er bei der Planung Ihrer Strategie zur Unterstützung verschiedener Arten von Inhaltserstellenden helfen. Ihr Ziel sollte es sein, das Prinzip der geringsten Rechte zu befolgen. Dieses Prinzip gestattet Benutzenden ausreichende Berechtigungen, um produktiv zu sein, ohne übermäßige Berechtigungen bereitzustellen.

Erstellen neuer Inhalte

Die folgenden Berechtigungen sind in der Regel erforderlich, um neue Inhalte zu erstellen.

Berechtigung	Berichtsersteller	Erstellende von Semantikmodellen	Dataflowersteller	Datamartersteller
Zugriff auf die zugrunde liegende Datenquelle
Berechtigungen „Lesen“ und „Erstellen“ für Semantikmodelle
Dataflow-Leseberechtigung (wenn ein Dataflow als Quelle verwendet wird, über die Arbeitsbereichsrolle „Anzeigender Benutzer“)
Zugriff auf den Ort, an dem die ursprüngliche Power BI Desktop-Datei gespeichert ist
Berechtigung zur Verwendung benutzerdefinierter Visuals

Berechtigungen zum Veröffentlichen von Inhalten

Die folgenden Berechtigungen sind in der Regel erforderlich, um Inhalte zu veröffentlichen.

Berechtigung	Berichtsersteller	Erstellende von Semantikmodellen	Dataflowersteller	Datamartersteller
Arbeitsbereichsrolle: Mitwirkender, Mitglied oder Administrator
Berechtigung „Schreiben“ für Semantikmodelle (wenn der Benutzer bzw. die Benutzerin keiner Arbeitsbereichsrolle angehört)
Bereitstellungspipelinerolle zum Veröffentlichen von Elementen (optional)

Daten werden aktualisiert

Die folgenden Berechtigungen sind in der Regel erforderlich, um Daten zu aktualisieren.

Berechtigung	Berichtsersteller	Erstellende von Semantikmodellen	Dataflowersteller	Datamartersteller
Besitzer zugewiesen (der Einstellungen eingerichtet oder das Element übernommen hat)
Zugriff auf die zugrunde liegende Datenquelle (wenn kein Gateway verwendet wird)
Zugriff auf die Datenquelle in einem Gateway (wenn sich die Quelle lokal oder in einem virtuellen Netzwerk befindet)

Im weiteren Verlauf dieses Artikels werden Überlegungen zu Berechtigungen für Inhaltserstellende beschrieben.

Tipp

Informationen zu Berechtigungen im Zusammenhang mit dem Anzeigen von Inhalten finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer.

Checkliste: Die Planung Ihrer Sicherheitsstrategie für Inhaltserstellende umfasst folgende wichtige Entscheidungen und Aktionen:

• Bestimmen, wer Ihre Datenerstellenden sind: Stellen Sie sicher, dass Sie damit vertraut sind, wer Semantikmodelle, Dataflows und Datamarts erstellt. Vergewissern Sie sich, dass Sie deren Anforderungen verstehen, bevor Sie mit Ihren Sicherheitsplanungsaktivitäten beginnen.
• Bestimmen, wer Ihre Berichtserstellenden sind: Stellen Sie sicher, dass Sie damit vertraut sind, wer Berichte, Dashboards, Arbeitsmappen und Scorecards erstellt. Vergewissern Sie sich, dass Sie deren Anforderungen verstehen, bevor Sie mit Ihren Sicherheitsplanungsaktivitäten beginnen.

Ermitteln von Inhalten für Erstellende

Benutzer*innen können die Datenermittlung verwenden, um Semantikmodelle und Datamarts zu finden. Die Datenermittlung ist ein Power BI-Feature, mit dem Inhaltserstellende vorhandene Datenobjekte finden können – auch wenn sie über keine Berechtigungen für diesen Inhalt verfügen.

Die Ermittlung vorhandener Daten ist nützlich für:

• Berichtserstellende, die ein vorhandenes Semantikmodell für einen neuen Bericht verwenden möchten.
• Berichtserstellende, die Daten aus einem vorhandenen Datamart abfragen möchten.
• Erstellende von Semantikmodellen, die ein vorhandenes Semantikmodell für ein neues zusammengesetztes Modell verwenden möchten.

Hinweis

Datenermittlung in Power BI ist keine Datensicherheitsberechtigung. Es handelt sich um eine Einstellung, die es Berichtserstellenden ermöglicht, Metadaten zu lesen, sodass sie Daten ermitteln und Zugriff darauf anfordern können.

Sie können ein Semantikmodell oder einen Datamart als auffindbar einrichten, wenn es bzw. er unterstützt (zertifiziert oder höhergestuft) wurde. Wenn es auffindbar ist, können Inhaltserstellende es im Datenhub finden.

Inhaltserstellende können auch Zugriff auf das Semantikmodell oder auf den Datamart anfordern. Im Wesentlichen bittet eine Zugriffsanforderung um Erstellenberechtigung, die erforderlich ist, um darauf basierend neue Inhalte zu erstellen. Wenn Sie auf Zugriffsanforderungen antworten, erwägen Sie die Verwendung von Gruppen anstelle einzelner Benutzender. Weitere Informationen zur Verwendung von Gruppen zu diesem Zweck finden Sie unter Workflow zur Anforderung des Zugriffs für Consumer.

Sehen Sie sich die folgenden drei Beispiele an.

• Das Semantikmodell Sales Summary (Verkaufszusammenfassung) ist zertifiziert. Es ist die vertrauenswürdige und autoritative Quelle für die Vertriebsnachverfolgung. Dieses Semantikmodell wird von vielen Self-Service-Berichtserstellenden in der gesamten Organisation verwendet. Es gibt also viele vorhandene Berichte und zusammengesetzte Modelle, die auf dem Semantikmodell basieren. Um andere Erstellende zu ermutigen, das Semantikmodell zu suchen und zu verwenden, ist es als auffindbar festgelegt.
• Das Semantikmodell Inventory Stats (Bestandsstatistiken) ist zertifiziert. Es handelt sich um eine vertrauenswürdige und autoritative Quelle für die Bestandsanalyse. Das Semantikmodell und die zugehörigen Berichte werden vom Enterprise BI-Team gepflegt und verteilt. Aufgrund des komplexen Designs des Semantikmodells ist nur das Enterprise BI-Team berechtigt, Bestandsinhalte zu erstellen und zu pflegen. Da das Ziel darin besteht, Berichtserstellende von der Verwendung des Semantikmodells abzuhalten, ist es nicht als auffindbar festgelegt.
• Das Semantikmodell Executive Bonuses (Führungskräfteboni) enthält streng vertrauliche Informationen. Berechtigungen zum Anzeigen oder Aktualisieren dieses Semantikmodells sind auf einige wenige Benutzer*innen beschränkt. Dieses Semantikmodell ist nicht als auffindbar festgelegt.

Der folgende Screenshot zeigt ein Semantikmodell im Data Hub im Power BI-Dienst. Insbesondere wird ein Beispiel für eine Meldung vom Typ Zugriff anfordern für ein auffindbares Semantikmodell gezeigt. Diese Meldung wird angezeigt, wenn der Benutzer derzeit keinen Zugriff hat. Die Meldung Zugriff anfordern wurde in den Semantikmodelleinstellungen angepasst.

Die Meldung Zugriff anfordern lautet: Für die standardmäßige Vertriebsberichterstattung über MTD/QTD/YTD ist dieses Semantikmodell die autorisierte und zertifizierte Quelle. Fordern Sie Zugriff auf das Semantikmodell an, indem Sie das Formular unter https://COE.contoso.com/RequestAccess ausfüllen. Sie werden um eine kurze geschäftliche Begründung gebeten, und der Manager bzw. die Managerin des Center of Excellence muss die Anforderung ebenfalls genehmigen. Der Zugriff wird alle sechs Monate überprüft.

Hinweis

Ihre Datenkultur und Ihre Einstellung zur Demokratisierung von Daten sollten großen Einfluss darauf haben, ob Sie die Datenermittlung aktivieren. Weitere Informationen zur Datenermittlung finden Sie im Anwendungsszenario für anpassbare verwaltete Self-Service-BI.

Es gibt drei Mandanteneinstellungen im Zusammenhang mit der Ermittlung.

• Mit der Mandanteneinstellung Inhalt ermitteln können Power BI-Administratoren festlegen, welche Benutzergruppen Daten ermitteln dürfen. Sie richtet sich in erster Linie an Berichtserstellende, die beim Erstellen von Berichten möglicherweise vorhandene Semantikmodell finden müssen. Sie ist auch nützlich für Erstellende von Semantikmodellen, die möglicherweise nach vorhandenen Daten suchen, die sie bei der Entwicklung von zusammengesetzten Modellen verwenden können. Es ist zwar möglich, sie für bestimmte Sicherheitsgruppen festzulegen, allerdings ist es ratsam, die Einstellung für die gesamte Organisation zu aktivieren. Die Ermittlungseinstellung für einzelne Semantikmodelle und Dataflows steuert, was auffindbar ist. Dies ist zwar weniger gängig, doch können Sie in Erwägung ziehen, diese Fähigkeit nur auf genehmigte Inhaltserstellende zu beschränken.
• Mit der Mandanteneinstellung Zertifizierten Inhalt als auffindbar festlegen können Power BI-Administratoren festlegen, welche Gruppen festlegen dürfen, dass Inhalte auffindbar sein sollen (wenn sie außerdem über die Berechtigung zum Bearbeiten des Elements sowie über die Berechtigung zum Zertifizieren von Inhalten verfügen, die durch die Mandanteneinstellung Zertifizierung erteilt wird). Die Fähigkeit zum Zertifizieren von Inhalten sollte streng kontrolliert werden. In den meisten Fällen sollten dieselben Benutzenden, die Inhalte zertifizieren dürfen, diese auch als auffindbar festlegen können. In einigen Situationen sollten Sie diese Fähigkeit eventuell nur auf genehmigte Datenerstellende beschränken.
• Mit der Mandanteneinstellung Höhergestufte Inhalte als auffindbar festlegen können Power BI-Administratoren festlegen, welche Gruppen den Inhalt als auffindbar festlegen können (wenn sie außerdem über Berechtigungen zum Bearbeiten der Daten verfügen). Da die Möglichkeit, Inhalte höherzustufen, allen Inhaltserstellenden offensteht, sollte diese Fähigkeit in den meisten Fällen für alle Benutzenden verfügbar sein. Dies ist zwar weniger gängig, doch können Sie in Erwägung ziehen, diese Fähigkeit nur auf genehmigte Inhaltserstellende zu beschränken.

Checkliste: Die Planung der Datenermittlung für Ihre Inhaltserstellenden umfasst folgende wichtige Entscheidungen und Aktionen:

• Klären der Notwendigkeit für die Datenermittlung: Überlegen Sie, welche Einstellung Ihre Organisation dazu hat, Inhaltserstellende zu ermutigen, vorhandene Semantikmodelle und Datamarts zu finden. Erstellen Sie ggf. eine Governancerichtlinie für die Verwendung der Datenermittlung.
• Entscheiden, wer Inhalte ermitteln kann: Entscheiden Sie, ob alle Power BI-Benutzenden Inhalte ermitteln dürfen, oder ob die Ermittlung auf bestimmte Benutzergruppen (z. B. eine Gruppe genehmigter Inhaltserstellender) beschränkt werden soll. Legen Sie die Mandanteneinstellung Inhalt ermitteln entsprechend dieser Entscheidung fest.
• Entscheiden, wer zertifizierte Inhalte als auffindbar festlegen kann: Entscheiden Sie, ob alle Power BI-Benutzer*innen (die über die Berechtigung zum Bearbeiten des Semantikmodells oder Datamarts sowie über die Berechtigung zu deren Zertifizierung verfügen) sie als auffindbar festlegen können. Legen Sie die Mandanteneinstellung Zertifizierten Inhalt als auffindbar festlegen entsprechend dieser Entscheidung fest.
• Entscheiden, wer höhergestufte Inhalte als auffindbar festlegen kann: Entscheiden Sie, ob alle Power BI-Benutzer*innen (die über die Berechtigung zum Bearbeiten des Semantikmodells oder Datamarts verfügen) sie als auffindbar festlegen können. Legen Sie die Mandanteneinstellung Höhergestufte Inhalte als auffindbar festlegen entsprechend dieser Entscheidung fest.
• In Dokumentation und Schulung für Erstellende von Semantikmodellen einschließen: Nehmen Sie für Ihre Erstellenden von Semantikmodellen eine Anleitung dazu auf, wann es angemessen ist, die Datenermittlung für die Semantikmodelle und Datamarts zu verwenden, die sie besitzen und verwalten.
• In Dokumentation und Schulung für Berichtserstellende einschließen: Nehmen Sie für Ihre Inhaltserstellenden eine Anleitung dazu auf, wie die Datenermittlung funktioniert und was sie davon erwarten können.

Workflow zur Anforderung des Zugriffs für Erstellende

Benutzende können den Zugriff auf Inhalte auf zwei Arten anfordern.

• Für Inhaltsconsumer: Benutzende erhalten einen Link zu einem vorhandenen Bericht oder einer App im Power BI-Dienst. Um das Element anzuzeigen, können Consumer die Schaltfläche Zugriff anfordern auswählen. Weitere Informationen finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer.
• Für Inhaltserstellende: Benutzer*innen entdecken ein Semantikmodell oder einen Datamart im Datenhub. Um einen neuen Bericht oder ein neues zusammengesetztes Modell auf Grundlage der vorhandenen Daten zu erstellen, können die Inhaltserstellenden die Schaltfläche Zugriff anfordern auswählen. Diese Erfahrung steht im Mittelpunkt dieses Abschnitts.

Standardmäßig wird eine Zugriffsanforderung für ein Semantikmodell oder einen Datamart an den Besitzer bzw. an die Besitzerin gesendet. Der Besitzende ist der Benutzende, der zuletzt eine Datenaktualisierung geplant oder Anmeldeinformationen eingegeben hat. Bei Teamsemantikmodellen kann es akzeptabel sein, sich bei der Bearbeitung von Zugriffsanforderungen auf einen einzelnen Benutzer bzw. auf eine einzelne Benutzerin zu verlassen. Dies kann jedoch nicht praktikabel oder unzuverlässig sein.

Anstatt sich auf nur einen einzelnen Besitzer bzw. auf eine einzelne Besitzerin zu verlassen, können Sie benutzerdefinierte Anweisungen definieren, die Benutzer*innen angezeigt werden, wenn sie Zugriff auf ein Semantikmodell oder auf einen Datamart anfordern. Benutzerdefinierte Anweisungen sind in folgenden Fällen hilfreich:

• Das Semantikmodell ist als auffindbar festgelegt.
• Die Genehmigung der Zugriffsanforderung erfolgt durch eine andere Person als den Datenbesitzenden.
• Es gibt einen Prozess, der für Zugriffsanforderungen befolgt werden muss.
• Die Nachverfolgung, wer wann und warum Zugriff angefordert hat, ist aus Gründen der Überprüfbarkeit bzw. Compliance erforderlich.
• Es ist eine Erklärung erforderlich, wie Zugriff angefordert wird, und um die Erwartungen einzugrenzen.

Der folgende Screenshot zeigt ein Beispiel für die Einrichtung benutzerdefinierter Anweisungen, die Benutzenden angezeigt werden, wenn sie die Erstellenberechtigung anfordern. Die benutzerdefinierten Anweisungen lauten: Für die standardmäßige Vertriebsberichterstattung über MTD/QTD/YTD ist dieses Semantikmodell die autorisierte und zertifizierte Quelle. Fordern Sie Zugriff auf das Semantikmodell an, indem Sie das Formular unter https://COE.contoso.com/RequestAccess ausfüllen. Sie werden um eine kurze geschäftliche Begründung gebeten, und der Manager bzw. die Managerin des Center of Excellence muss die Anforderung ebenfalls genehmigen. Der Zugriff wird alle sechs Monate überprüft.

Es gibt viele Möglichkeiten zum Erstellen eines Formulars. Power Apps und Microsoft Forms sind beides bedienfreundliche Low-Code-Optionen. Es wird empfohlen, ein Formular unabhängig von einzelnen Benutzenden zu erstellen. Es ist von entscheidender Bedeutung, dass Ihr Formular vom richtigen Team erstellt, verwaltet und überwacht wird.

Es wird empfohlen, hilfreiche Informationen für folgende Gruppen zu erstellen:

• Inhaltserstellende, damit sie wissen, was sie erwarten können, wenn sie Zugriff anfordern.
• Inhaltsbesitzende und -administratoren, damit sie wissen, wie übermittelte Anforderungen zu verwalten sind.

Tipp

Weitere Informationen zum Antworten auf Anforderungen von Lesezugriff von Consumern finden Sie unter Workflow zur Anforderung des Zugriffs für Consumer. Darin sind auch Informationen zur Verwendung von Gruppen (anstelle einzelner Benutzender) enthalten.

Checkliste: Die Planung des Workflows für die Zugriffsanforderung umfasst folgende wichtige Entscheidungen und Aktionen:

• Klären der Präferenzen für die Verarbeitung von Zugriffsanforderungen: Bestimmen Sie, in welchen Situationen die Genehmigung durch Besitzende akzeptabel ist und wann ein anderer Prozess verwendet werden soll. Erstellen Sie ggf. eine Governancerichtlinie für die Handhabung von Zugriffsanforderungen.
• In Dokumentation und Schulung für Erstellende von Semantikmodellen und Datamarts einschließen: Nehmen Sie für Ihre Erstellenden von Semantikmodellen und Datamarts eine Anleitung dazu auf, wie und wann benutzerdefinierte Anweisungen für Zugriffsanforderungen festgelegt werden sollen.
• In Dokumentation und Schulung für Berichtserstellende einschließen: Nehmen Sie für Ihre Berichtserstellenden eine Anleitung dazu auf, was sie erwarten können, wenn Erstellungsberechtigungen für Semantikmodelle und Datamarts angefordert werden.

Erstellen und Veröffentlichen von Inhalten

Dieser Abschnitt behandelt Sicherheitsaspekte, die für Inhaltserstellende gelten.

Hinweis

Informationen zu Consumern, die Berichte, Dashboards und Scorecards anzeigen, finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer. Überlegungen im Zusammenhang mit App-Berechtigungen werden ebenfalls in diesem Artikel behandelt.

Arbeitsbereichsrollen

Sie gewähren Arbeitsbereichszugriff, indem Sie Benutzende oder Gruppen (einschließlich Sicherheitsgruppen, Microsoft 365-Gruppen und Verteilerlisten) zu Arbeitsbereichsrollen hinzufügen. Durch Zuweisen von Benutzenden zu Arbeitsbereichsrollen können Sie angeben, was diese mit dem Arbeitsbereich und seinen Inhalten tun können.

Hinweis

Weitere Informationen zu Überlegungen zur Arbeitsbereichsplanung finden Sie in den Artikeln zur Arbeitsbereichsplanung. Weitere Informationen zu Gruppen finden Sie im Artikel Sicherheitsplanung auf Mandantenebene.

Da der primäre Zweck eines Arbeitsbereichs in der Zusammenarbeit besteht, ist der Zugriff auf einen Arbeitsbereich hauptsächlich für die Benutzenden relevant, die die Inhalte darin besitzen und verwalten. Beim Planen von Arbeitsbereichsrollen ist es hilfreich, sich die folgenden Fragen zu stellen:

• Was sind die Erwartungen für die Art der Zusammenarbeit im Arbeitsbereich?
• Wer ist für die Verwaltung der Inhalte im Arbeitsbereich verantwortlich?
• Besteht die Absicht darin, einzelnen Benutzer*innen oder Gruppen Arbeitsbereichsrollen zuzuweisen?

Es gibt vier Power BI-Arbeitsbereichsrollen: „Administrator“, „Mitglied“, „Mitwirkender“ und „Anzeigender Benutzer“. Die ersten drei Rollen sind für Inhaltserstellende relevant, die Inhalte erstellen und veröffentlichen. Die Rolle „Anzeigender Benutzer“ ist für schreibgeschützte Consumer relevant.

Die vier Arbeitsbereichsrollenberechtigungen sind geschachtelt. Das bedeutet, dass Arbeitsbereichsadministratoren über alle Funktionen verfügen, die für Mitglieder, Mitwirkende und „Anzeigende Benutzer“ zur Verfügung stehen. Ebenso verfügen Mitglieder über alle Funktionen, die für Mitwirkende und „Anzeigende Benutzer“ zur Verfügung stehen. Mitwirkende verfügen über alle Funktionen, die „Anzeigenden Benutzern“ zur Verfügung stehen.

Tipp

Die autoritative Referenz für jede der vier Rollen finden Sie in der Dokumentation zu Arbeitsbereichsrollen.

Arbeitsbereichsadministrator

Benutzende, die der Rolle „Administrator“ zugewiesen sind, werden zu Arbeitsbereichsadministratoren. Sie können alle Einstellungen verwalten und alle Aktionen ausführen, einschließlich des Hinzufügens oder Entfernens von Benutzenden (einschließlich anderer Arbeitsbereichsadministratoren).

Arbeitsbereichsadministratoren können die Power BI-App aktualisieren oder löschen (sofern vorhanden). Sie können optional Mitwirkenden das Aktualisieren der App für den Arbeitsbereich gestatten. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Varianten von Arbeitsbereichsrollen.

Tipp

Wenn Sie auf einen Administrator verweisen, müssen Sie klären, ob Sie über einen Arbeitsbereichsadministrator oder einen Power BI-Administrator auf Mandantenebene sprechen.

Achten Sie darauf, dass nur vertrauenswürdige und zuverlässige Personen Arbeitsbereichsadministratoren sind bzw. werden. Arbeitsbereichsadministratoren verfügen über hohe Berechtigungen. Sie haben Zugriff zum Anzeigen und Verwalten aller Inhalte im Arbeitsbereich. Sie können Benutzer (einschließlich anderer Administratoren) zu jeder Arbeitsbereichsrolle hinzufügen und daraus entfernen. Sie können auch den Arbeitsbereich löschen.

Es wird empfohlen, dass mindestens zwei Administratoren vorhanden sind, damit einer als Ersatz dient, falls der primäre Administrator nicht verfügbar sein sollte. Ein Arbeitsbereich ohne Administrator wird als verwaister Arbeitsbereich bezeichnet. Der Status „verwaist“ tritt auf, wenn ein Benutzer die Organisation verlässt und dem Arbeitsbereich kein alternativer Administrator zugewiesen ist. Weitere Informationen zum Erkennen und Korrigieren verwaister Arbeitsbereiche finden Sie im Artikel Anzeigen von Arbeitsbereichen.

Im Idealfall sollten Sie in der Lage sein, zu bestimmen, wer für den Arbeitsbereichsinhalt verantwortlich ist, indem Sie festlegen, wer die Arbeitsbereichsadministratoren und -mitglieder sind (und die für den Arbeitsbereich angegebenen Kontakte). Einige Organisationen verfolgen jedoch eine Strategie des Besitzes und der Verwaltung von Inhalten, die die Erstellung von Arbeitsbereichen auf bestimmte Benutzende oder Gruppen beschränkt. Sie verfügen in der Regel über einen etablierten Prozess zur Erstellung von Arbeitsbereichen, der möglicherweise von der IT-Abteilung verwaltet wird. In diesem Fall rekrutieren sich die Arbeitsbereichsadministratoren wahrscheinlich eher aus der IT-Abteilung als den Benutzenden, die den Inhalt direkt erstellen und veröffentlichen.

Arbeitsbereichsmitglied

Benutzende, die der Rolle „Mitglied“ zugewiesen sind, können andere Arbeitsbereichsbenutzende (aber keine Administratoren) hinzufügen. Sie können auch Berechtigungen für alle Inhalte im Arbeitsbereich verwalten.

Arbeitsbereichsmitglieder können die App für den Arbeitsbereich veröffentlichen oder deren Veröffentlichung aufheben, ein Arbeitsbereichselement oder die App freigeben und anderen Benutzenden das Freigeben von Arbeitsbereichselementen oder der App ermöglichen.

Arbeitsbereichsmitglieder sollten auf die Benutzenden beschränkt sein, die die Erstellung von Arbeitsbereichsinhalten verwalten und die App veröffentlichen müssen. In einigen Fällen erfüllen die Arbeitsbereichsadministratoren diese Aufgabe, sodass Sie der Rolle „Mitglied“ möglicherweise gar keine Benutzenden oder Gruppen zuweisen müssen. Wenn die Arbeitsbereichsadministratoren nicht direkt mit dem Arbeitsbereichsinhalt in Zusammenhang stehen (z. B. weil die IT den Erstellungsprozess für Arbeitsbereiche verwaltet), sind die Arbeitsbereichsmitglieder möglicherweise die tatsächlichen Besitzer, die für den Arbeitsbereichsinhalt verantwortlich sind.

Mitwirkender im Arbeitsbereich

Benutzende, die der Rolle „Mitwirkender“ zugewiesen sind, können Arbeitsbereichsinhalte erstellen, bearbeiten und löschen.

Mitwirkende können die Power BI-App nicht aktualisieren (sofern eine für den Arbeitsbereich vorhanden ist), es sei denn, dies wurde über die Arbeitsbereichseinstellung zugelassen. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Varianten von Arbeitsbereichsrollen.

Die meisten Inhaltserstellenden in der Organisation sind Arbeitsbereichsmitwirkende.

Betrachter im Arbeitsbereich

Benutzende, die der Rolle „Anzeigender Benutzer“ zugewiesen sind, können alle Arbeitsbereichsinhalte anzeigen und mit ihnen interagieren.

Die Rolle „Anzeigender Benutzer“ ist für schreibgeschützte Consumer für kleine Teams und informelle Szenarien relevant. Sie wird vollständig im Artikel Planung der Sicherheit für Berichtsconsumer beschrieben.

Überlegungen zum Arbeitsbereichsbesitz

Betrachten Sie ein Beispiel, in dem die folgenden Aktionen zum Einrichten eines neuen Arbeitsbereichs ausgeführt werden.

1. Bestimmten Power BI-Champions und -Satellitenmitgliedern des Center of Excellence (COE) wurde in den Mandanteneinstellungen die Berechtigung zum Erstellen neuer Arbeitsbereiche erteilt. Sie wurden in Strategien der Inhaltsorganisation sowie in Benennungsstandards geschult.
2. Sie (ein Inhaltserstellender) übermitteln eine Anforderung zum Erstellen eines Arbeitsbereichs für ein neues Projekt, das Sie verwalten werden. Der Arbeitsbereich wird Berichte enthalten, die den Fortschritt Ihres Projekts nachverfolgen.
3. Ein Power BI-Champion für Ihre Geschäftseinheit erhält die Anforderung. Dieser stellt fest, dass ein neuer Arbeitsbereich gerechtfertigt ist. Anschließend erstellt er einen Arbeitsbereich und weisen die Power BI-Champions-Sicherheitsgruppe (für ihre Geschäftseinheit) der Arbeitsbereichsrolle „Administrator“ zu.
4. Der Power BI-Champion weist Sie (den Inhaltserstellenden) der Rolle Arbeitsbereichsrolle „Mitglied“ zu.
5. Sie weisen der Arbeitsbereichsrolle „Mitglied“ einen vertrauenswürdigen Kollegen zu, um sicherzustellen, dass es für den Fall Ihrer Abwesenheit einen Ersatz gibt.
6. Sie weisen andere Kolleg*innen der Arbeitsbereichsrolle „Mitwirkender“ zu, da sie für das Erstellen der Arbeitsbereichsinhalte (einschließlich Semantikmodelle und Berichte) verantwortlich sind.
7. Sie weisen Ihren Vorgesetzten der Arbeitsbereichsrolle „Anzeigender Benutzer“ zu, da er Zugriff angefordert hat, um den Fortschritt des Projekts überwachen zu können. Ihr Vorgesetzter möchte Inhalte im Arbeitsbereich überprüfen, bevor Sie eine App veröffentlichen.
8. Sie übernehmen die Verantwortung für die Verwaltung anderer Arbeitsbereichseigenschaften wie „Beschreibung“ und „Kontakte“. Außerdem übernehmen Sie die Verantwortung für die fortlaufende Verwaltung des Arbeitsbereichszugriffs.

Das vorherige Beispiel zeigt eine effektive Möglichkeit, einer dezentralen Geschäftseinheit die Möglichkeit zu geben, unabhängig zu handeln. Es zeigt ferner das Prinzip der geringsten Rechte.

Für kontrollierte Inhalte oder kritische Inhalte, die strenger verwaltet werden, ist es eine bewährte Methode, Gruppen anstelle einzelner Benutzendenkonten zu Arbeitsbereichsrollen zuzuweisen. Auf diese Weise können Sie die Gruppenmitgliedschaft gesondert vom Arbeitsbereich verwalten. Beim Zuweisen von Gruppen zu Rollen ist es jedoch möglich, dass Benutzende mehreren Arbeitsbereichsrollen zugewiesen werden (da die jeweiligen Benutzenden zu mehreren Gruppen gehören). In diesem Fall basieren deren effektive Berechtigungen auf der höchsten Rolle, der sie zugewiesen sind. Weitere Überlegungen hierzu finden Sie unter Strategie für die Verwendung von Gruppen.

Wenn sich ein Arbeitsbereich im gemeinsamen Besitz mehrerer Personen oder Teams befindet, kann dies die Verwaltung der Inhalte verkomplizieren. Versuchen Sie, Szenarien zu vermeiden, in denen sich mehrere Teams den Besitz teilen, indem Sie Arbeitsbereiche trennen. Auf diese Weise sind die Zuständigkeiten klar und Rollenzuweisungen lassen sich einfach einrichten.

Varianten von Arbeitsbereichsrollen

Es gibt zwei Varianten der (zuvor beschriebenen) vier Arbeitsbereichsrollen.

• Standardmäßig können nur Arbeitsbereichsadministratoren und -mitglieder die App für den Arbeitsbereich erstellen, veröffentlichen und aktualisieren. Mitwirkenden das Aktualisieren der App erlauben ist eine Einstellung auf Arbeitsbereichsebene, die es Arbeitsbereichsadministratoren ermöglicht, die Fähigkeit zum Aktualisieren der App für den Arbeitsbereich an Mitwirkende zu delegieren. Mitwirkende können jedoch weder neue Apps veröffentlichen noch ändern, wer über Berechtigungen zum Bearbeiten der App verfügt. Diese Einstellung ist nützlich, wenn Mitwirkende in der Lage sein sollen, die App zu aktualisieren (sofern eine für den Arbeitsbereich vorhanden ist), Sie aber nicht die anderen Berechtigungen gewähren möchten, die für Mitglieder verfügbar sind.
• Die Mandanteneinstellung Erneute Veröffentlichung blockieren und Paketaktualisierung deaktivieren erlaubt nur Semantikmodellbesitzer*innen das Veröffentlichen von Aktualisierungen. Wenn diese Option aktiviert ist, können Arbeitsbereichsadministrator*innen, Mitglieder und Mitwirkende Änderungen nur veröffentlichen, wenn sie zuerst das Semantikmodell als Besitzer*in übernehmen. Diese Einstellung gilt für die gesamte Organisation. Aktivieren Sie sie mit einem gewissen Maß an Vorsicht, da sie sich auf alle Semantikmodelle für den Mandanten auswirkt. Teilen Sie Ihren Erstellenden von Semantikmodellen mit, was sie erwarten können, da sich dadurch das normale Verhalten von Arbeitsbereichsrollen ändert.

Wichtig

Berechtigungen pro Element können Sie sich auch als Außerkraftsetzung der Standardarbeitsbereichsrollen vorstellen. Weitere Informationen zu Berechtigungen pro Element finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer.

Checkliste: Die Planung von Arbeitsbereichsrollen umfasst folgende wichtige Entscheidungen und Aktionen:

• Erstellen Sie eine Verantwortungsmatrix: Ordnen Sie zu, wer die einzelnen Funktionen beim Erstellen, Verwalten, Veröffentlichen, Sichern und Unterstützen von Inhalten übernehmen soll. Verwenden Sie diese Informationen beim Planen Ihrer Arbeitsbereichsrollen.
• Entscheiden für Ihre Strategie zum Zuweisen von Arbeitsbereichsrollen für Inhaltserstellende: Bestimmen Sie, welche Benutzenden Administrator, Mitglied oder Mitwirkender sein sollen und unter welchen Umständen (z. B. Auftragsrolle oder Themenbereich). Wenn es Unstimmigkeiten gibt, die Sicherheitsbedenken verursachen, überlegen Sie neu, wie sich Ihre Arbeitsbereiche besser organisieren lassen.
• Bestimmen, wie Sicherheitsgruppen im Vergleich zu Einzelpersonen für Arbeitsbereichsrollen verwendet werden sollen: Bestimmen Sie die Anwendungsfälle und Zwecke, für die Sie Gruppen verwenden müssen. Geben Sie sehr spezifisch an, wann die Sicherheit mithilfe von Benutzerkonten angewendet werden sollte und wann eine Gruppe erforderlich oder zu bevorzugen ist.
• Bereitstellen von Anleitungen für Inhaltserstellende zum Verwalten von Arbeitsbereichsrollen: Nehmen Sie für Inhaltserstellende eine Dokumentation dazu auf, wie Arbeitsbereichsrollen verwaltet werden. Veröffentlichen Sie diese Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.
• Einrichten und Testen von Arbeitsbereichsrollen-Zuweisungen: Überprüfen Sie, ob Inhaltserstellende über die erforderlichen Funktionen verfügen, um Inhalte bearbeiten und veröffentlichen zu können.

App-Erstellendenberechtigungen

Inhaltserstellende, die Arbeitsbereichsadministratoren oder -mitglieder sind, können eine Power BI-App erstellen und veröffentlichen.

Ein Arbeitsbereichsadministrator kann auch eine Einstellung im Arbeitsbereich angeben, die es Arbeitsbereichsmitwirkenden erlaubt, die App zu aktualisieren. Dies ist eine Variante der Arbeitsbereichsrollen-Sicherheit, da so Mitwirkenden eine andere Berechtigung gewährt wird, die sie normalerweise nicht hätten. Diese Einstellung wird auf Arbeitsbereichsbasis festgelegt.

Tipp

Weitere Informationen zum Bereitstellen von Inhalten für schreibgeschützte Consumer finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer. Dieser Artikel enthält Informationen zu App-Berechtigungen für App-Consumer, einschließlich Zielgruppen für die App.

Checkliste: Die Planung von Berechtigungen für App-Erstellende umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für Ihre Strategie, wer Power BI-Apps erstellen und veröffentlichen kann: Klären Sie, wem das Erstellen und Veröffentlichen von Power BI-Apps erlaubt werden soll.
• Bestimmen, wann Mitwirkende Power BI-Apps aktualisieren können: Klären Sie die Situationen, in denen einem Mitwirkenden das Aktualisieren von Power BI-Apps gestattet werden sollte. Aktualisieren Sie die Arbeitsbereichseinstellung, wenn diese Funktion erforderlich ist.

Datenquellenberechtigungen

Wenn Datenerstellende ein neues Projekt starten, sind Berechtigungen, die für den Zugriff auf externe Datenquellen erforderlich sind, eine der ersten sicherheitsrelevanten Überlegungen. Möglicherweise benötigen sie auch Anleitungen zu anderen Datenquellenfragen, einschließlich Datenschutzebenen, nativer Datenbankabfragen und benutzerdefinierter Connectors.

Zugriff auf Datenquellen

Wenn Datenerstellende ein Semantikmodell, einen Dataflow oder einen Datamart erstellen, müssen sie sich bei Datenquellen authentifizieren, um Daten abzurufen. In der Regel umfasst die Authentifizierung Benutzendenanmeldeinformationen (Konto und Kennwort), die für ein Dienstkonto sein können.

Manchmal ist es hilfreich, spezifische Dienstkonten für den Zugriff auf Datenquellen zu erstellen. Wenden Sie sich an Ihre IT-Abteilung, um Anleitungen zu erhalten, wie Dienstkonten in Ihrer Organisation verwendet werden sollten. Wenn sie zulässig sind, kann die Verwendung von Dienstkonten Folgendes ermöglichen:

• Zentralisieren von Berechtigungen, die für Datenquellen erforderlich sind.
• Verringern der Anzahl einzelner Benutzender, die Berechtigungen für eine Datenquelle benötigen.
• Vermeiden von Fehlern bei der Datenaktualisierung, wenn Benutzende die Organisation verlassen.

Tipp

Wenn Sie sich für die Verwendung von Dienstkonten entscheiden, empfehlen wir Ihnen, sehr streng zu kontrollieren, wer Zugriff auf die Anmeldeinformationen hat. Rotieren Sie Kennwörter regelmäßig (z. B. alle drei Monate) oder wenn jemand, der Zugriff hat, die Organisation verlässt.

Wenden Sie beim Zugriff auf Datenquellen das Prinzip der geringsten Rechte an, um sicherzustellen, dass Benutzende (oder Dienstkonten) über die Berechtigung verfügen, nur die benötigten Daten zu lesen. Sie sollten niemals die Berechtigung besitzen, Datenänderungen durchzuführen. Datenbankadministratoren, die diese Dienstkonten erstellen, sollten sich nach erwarteten Abfragen und Workloads erkundigen und Maßnahmen ergreifen, um sicherzustellen, dass angemessene Optimierungen (z. B. Indizes) und Ressourcen vorhanden sind.

Tipp

Wenn es schwierig ist, direkten Datenquellenzugriff für Self-Service-Datenerstellende bereitzustellen, sollten Sie einen indirekten Ansatz in Erwägung ziehen. Sie können Dataflows im Power BI-Dienst erstellen und Self-Service-Datenerstellenden erlauben, Daten daraus zu beziehen. Dieser Ansatz bietet die zusätzlichen Vorteile, dass die Abfragelast für die Datenquelle verringert und eine konsistente Momentaufnahme der Daten bereitgestellt wird. Weitere Informationen finden Sie in den Anwendungsszenarien zur Self-Service-Datenaufbereitung und zur erweiterte Datenaufbereitung.

Die Anmeldeinformationen (Konto und Kennwort) können auf eine von zwei Weisen angewendet werden.

• Power BI Desktop: Anmeldeinformationen werden verschlüsselt und lokal auf dem Benutzendencomputer gespeichert.
• Power BI-Dienst: Anmeldeinformationen werden verschlüsselt und sicher gespeichert für:
  • Das Semantikmodell (wenn kein Datengateway verwendet wird, um die Datenquelle zu erreichen).
  • Die Gatewaydatenquelle (wenn ein Standardgateway oder ein Gatewaydienst für virtuelle Netzwerke verwendet wird, um die Datenquelle zu erreichen).

Tipp

Wenn Sie bereits Anmeldeinformationen für eine Semantikmodell-Datenquelle eingegeben haben, bindet der Power BI-Dienst diese Anmeldeinformationen automatisch an andere Semantikmodell-Datenquellen, wenn eine exakte Übereinstimmung zwischen Verbindungszeichenfolge und Datenbankname vorliegt. Sowohl der Power BI-Dienst als auch Power BI Desktop lassen es so aussehen, als ob Sie Anmeldeinformationen für jede Datenquelle eingeben. Es können jedoch dieselben Anmeldeinformationen auf übereinstimmende Datenquellen angewendet werden, die denselben Besitzer haben. In dieser Hinsicht sind Semantikmodell-Anmeldeinformationen auf den Besitzer bzw. auf die Besitzerin ausgerichtet.

Anmeldeinformationen werden sowohl in Power BI Desktop als auch im Power BI-Dienst verschlüsselt und getrennt vom Datenmodell gespeichert. Diese Datentrennung hat die folgenden Sicherheitsvorteile.

• Sie erleichtert die Wiederverwendung von Anmeldeinformationen für mehrere Semantikmodelle, Dataflows und Datamarts.
• Wenn jemand die Metadaten eines Semantikmodells analysiert, kann diese Person die Anmeldeinformationen nicht extrahieren.
• In Power BI Desktop kann ein anderer Benutzer keine Verbindung mit der ursprünglichen Datenquelle herstellen, um Daten zu aktualisieren, ohne zuvor die Anmeldeinformationen anzuwenden.

Einige Datenquellen unterstützen einmaliges Anmelden (Single Sign On, SSO), das bei der Eingabe von Anmeldeinformationen im Power BI-Dienst (für Semantikmodell- oder Gatewaydatenquellen) festgelegt werden kann. Wenn Sie einmaliges Anmelden (SSO) aktivieren, sendet Power BI die Anmeldeinformationen des authentifizierten Benutzenden an die Datenquelle. Diese Option ermöglicht Power BI die Berücksichtigung der Sicherheitseinstellungen, die in der Datenquelle eingerichtet sind, z. B. Sicherheit auf Zeilenebene. Einmaliges Anmelden ist besonders nützlich, wenn Tabellen im Datenmodell den DirectQuery-Speichermodus verwenden.

Sicherheitsstufen

Datenschutzebenen für Daten spezifizieren den Grad der Isolation einer Datenquelle von anderen Datenquellen. Bei entsprechender Festlegung wird dadurch sichergestellt, dass Power Query nur kompatible Daten zwischen Quellen überträgt. Wenn Power Query Daten zwischen Datenquellen übertragen kann, kann dies zu effizienteren Abfragen führen, die die Menge der an Power BI gesendeten Daten reduzieren. Wenn keine Daten zwischen Datenquellen übertragen werden können, kann dies zu einer langsameren Leistung führen.

Es gibt drei Datenschutzebenen.

• Privat: Umfasst sensible oder vertrauliche Daten, die von allen anderen Datenquellen isoliert werden müssen. Diese Ebene ist die restriktivste. Daten aus privaten Datenquellen können nicht gemeinsam mit anderen Datenquellen genutzt werden. Beispielsweise sollte eine Personaldatenbank, die Gehaltssummen von Mitarbeitern enthält, auf die Datenschutzebene „Privat“ festgelegt werden.
• Organisationsweit: Isoliert von öffentlichen Datenquellen, aber für andere organisationsweite Datenquellen sichtbar. Diese Ebene ist die gängigste. Daten aus organisationsweiten Datenquellen können gemeinsam mit privaten Datenquellen oder anderen organisationsweiten Datenquellen genutzt werden. Die meisten internen operativen Datenbanken können auf die Datenschutzebene „Organisationsweit“ festgelegt werden.
• Öffentlich: Nicht vertrauliche Daten, die für jede Datenquelle sichtbar gemacht werden könnten. Diese Ebene ist die am wenigsten restriktive. Daten aus öffentlichen Datenquellen können gemeinsam mit allen anderen Datenquellen genutzt werden. Beispielsweise kann ein von einer Regierungswebsite abgerufener Volkszählungsbericht auf die Datenschutzebene „Öffentlich“ festgelegt werden.

Beim Kombinieren von Abfragen aus verschiedenen Datenquellen ist es wichtig, dass Sie die richtigen Datenschutzebenen festlegen. Wenn die Datenschutzebenen richtig festgelegt sind, besteht die Möglichkeit, dass Daten aus einer Datenquelle an eine andere Datenquelle übertragen werden, um Daten effizient abzufragen.

Stellen Sie sich ein Szenario vor, in dem Erstellende von Semantikmodellen über zwei Datenquellen verfügen: eine Excel-Arbeitsmappe und eine Tabelle in einer Azure SQL-Datenbank. Sie möchten die Daten in der Azure SQL-Datenbanktabelle mithilfe eines Werts filtern, der aus der Excel-Arbeitsmappe stammt. Die effizienteste Möglichkeit für Power Query, eine SQL-Anweisung für die Azure SQL-Datenbank zu generieren, besteht darin, eine WHERE-Klausel anzuwenden, um die erforderliche Filterung durchzuführen. Diese SQL-Anweisung enthält jedoch ein WHERE-Klauselprädikat mit einem Wert, der aus der Excel-Arbeitsmappe stammt. Wenn die Excel-Arbeitsmappe vertrauliche Daten enthält, kann dies eine Sicherheitsverletzung darstellen, da der Datenbankadministrator die SQL-Anweisung mithilfe eines Ablaufverfolgungstools anzeigen könnte. Obwohl dies weniger effizient ist, besteht die Alternative darin, dass die Mashup-Engine von Power Query das gesamte Resultset der Datenbanktabelle herunterlädt und die Filterung selbst im Power BI-Dienst durchführt. Dieser Ansatz ist weniger effizient und langsam, aber sicher.

Datenschutzebenen können für jede Datenquelle festgelegt werden:

• Von Datenmodellierenden in Power BI Desktop.
• Von Semantikmodellbesitzer*innen im Power BI-Dienst (für Clouddatenquellen, die kein Gateway erfordern).
• Von Gateway-Datenquellenerstellenden und -besitzenden im Power BI-Dienst (für Gatewaydatenquellen).

Wichtig

Die in Power BI Desktop festgelegten Datenschutzebenen werden nicht auf den Power BI-Dienst übertragen.

Es gibt eine Power BI Desktop-Sicherheitsoption, die das Ignorieren von Datenschutzebenen ermöglicht, um die Leistung zu verbessern. Sie könnten diese Option verwenden, um die Abfrageleistung während der Entwicklung eines Datenmodells zu verbessern, wenn kein Risiko besteht, die Datensicherheit zu verletzen (da Sie mit Entwicklungs- oder Testdaten arbeiten, die nicht vertraulich sind). Diese Einstellung wird jedoch vom Power BI-Dienst nicht berücksichtigt.

Weitere Informationen finden Sie unter Power BI Desktop – Datenschutzebenen.

Native Datenbankabfragen

Um effiziente Power Query Abfragen zu erstellen, können Sie eine native Abfrage verwenden, um auf Daten zuzugreifen. Eine native Abfrage ist eine Anweisung, die in einer Sprache geschrieben ist, die von der Datenquelle unterstützt wird. Native Abfragen werden nur von bestimmten Datenquellen unterstützt, bei denen es sich in der Regel um relationale Datenbanken wie Azure SQL-Datenbank handelt.

Native Abfragen können ein Sicherheitsrisiko darstellen, da sie eine böswillige SQL-Anweisung ausführen könnten. Eine böswillige Anweisung könnte Datenänderungen durchführen oder Datenbank-Datensätze löschen (wenn der Benutzende über die erforderlichen Berechtigungen in der Datenquelle verfügt). Aus diesem Grund erfordern native Abfragen standardmäßig die Benutzendengenehmigung, um in Power BI Desktop ausgeführt zu werden.

Es gibt eine Power BI Desktop-Sicherheitsoption, mit der Sie die Anforderung der Vorabgenehmigung deaktivieren können. Es wird empfohlen, die Standardeinstellung zu übernehmen, die eine Benutzendengenehmigung erfordert, insbesondere wenn Sie davon ausgehen, dass die Power BI Desktop-Datei von anderen Benutzern aktualisiert werden könnte.

Benutzerdefinierte Connectors

Entwickelnde können das Power Query SDK verwenden, um benutzerdefinierte Connectors zu erstellen. Benutzerdefinierte Connectors ermöglichen den Zugriff auf proprietäre Datenquellen oder implementieren eine bestimmte Authentifizierung mit benutzerdefinierten Datenerweiterungen. Einige benutzerdefinierte Connectors werden von Microsoft zertifiziert und als zertifizierte Connectors verteilt. Zertifizierte Connectors wurden überwacht und überprüft, um sicherzustellen, dass sie bestimmte, von Microsoft getestete und genehmigte Codeanforderungen erfüllen.

Es gibt eine Power BI Desktop-Datenerweiterungs-Sicherheitsoption, die die Verwendung nicht zertifizierter Connectors einschränkt. Standardmäßig wird ein Fehler ausgelöst, wenn versucht wird, einen nicht zertifizierten Connector zu laden. Wenn Sie diese Option so festlegen, dass nicht zertifizierte Connectors zugelassen sind, werden benutzerdefinierte Connectors ohne Validierung oder Warnung geladen.

Es wird grundsätzlich empfohlen, eine höhere Sicherheitsstufe für die Datenerweiterung zu verwenden, um zu verhindern, dass nicht zertifizierter Code geladen wird. Es kann jedoch der Fall eintreten, dass Sie bestimmte Connectors laden möchten – vielleicht von Ihnen entwickelte Connectors oder Connectors die Ihnen ein vertrauenswürdiger Beratender oder Anbietender außerhalb des Microsoft-Zertifizierungspfads bereitgestellt hat.

Hinweis

Entwickelnde von im Unternehmen entwickelten Connectors können Schritte ausführen, um einen Connector mit einem Zertifikat zu signieren, sodass Sie den Connector verwenden können, ohne Ihre Sicherheitseinstellungen ändern zu müssen. Weitere Informationen finden Sie unter Vertrauenswürdige Connectors von Drittanbietern.

Checkliste: Die Planung von Datenquellenberechtigungen umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden, wer direkt auf die jeweiligen Datenquellen zugreifen kann: Bestimmen Sie, welche Datenerstellenden direkt auf eine Datenquelle zugreifen dürfen. Wenn es eine Strategie gibt, um die Anzahl der Personen mit direktem Zugriff zu reduzieren, klären Sie, worin die bevorzugte Alternative besteht (z. B. mithilfe von Dataflows).
• Entscheiden, wie auf Datenquellen zugegriffen werden soll: Bestimmen Sie, ob Anmeldeinformationen einzelner Benutzender für den Zugriff auf eine Datenquelle verwendet werden oder ob zu diesem Zweck ein Dienstkonto erstellt werden sollte. Bestimmen Sie, wann einmaliges Anmelden (SSO) geeignet ist.
• Bereitstellen einer Anleitung für den Zugriff auf Datenquellen für Erstellende von Semantikmodellen: Nehmen Sie für Inhaltserstellende eine Dokumentation dazu auf, wie auf organisationsweite Datenquellen zugegriffen werden soll. Veröffentlichen Sie die Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.
• Bereitstellen einer Anleitung zu Datenschutzebenen für Erstellende von Semantikmodellen: Stellen Sie Erstellenden von Semantikmodellen eine Anleitung zur Verfügung, um sie über Datenschutzebenen und deren Auswirkungen bei der Arbeit mit sensiblen oder vertraulichen Daten zu informieren. Veröffentlichen Sie diese Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.
• Bereitstellen einer Anleitung zu Datenschutzebenen für Erstellende von Gatewayverbindungen: Stellen Sie Erstellenden von Semantikmodellen eine Anleitung zur Verfügung, um sie über Datenschutzebenen und deren Auswirkungen bei der Arbeit mit sensiblen oder vertraulichen Daten zu informieren. Veröffentlichen Sie diese Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.
• Entscheiden für eine Strategie für die Verwendung nativer Datenbankabfragen: Berücksichtigen Sie Ihre Strategie für die Verwendung nativer Datenbankabfragen. Informieren Sie Erstellende von Semantikmodellen darüber, wie und wann die Power BI Desktop-Option für native Datenbankabfragen festgelegt werden soll, um die Vorabgenehmigung beim Ausführen nativer Power Query-Abfragen zu deaktivieren.
• Entscheiden für eine Strategie für die Verwendung benutzerdefinierter Connectors: Berücksichtigen Sie Ihre Strategie für die Verwendung benutzerdefinierter Connectors. Bestimmen Sie, ob die Verwendung nicht zertifizierter Connectors gerechtfertigt ist. Informieren Sie in einem solchen Fall Erstellende von Semantikmodellen darüber, wie und wann die Power BI Desktop-Datenerweiterungsoption festgelegt werden soll.

Erstellerberechtigungen für Semantikmodelle

Sie können einem Benutzer bzw. einer Benutzerin oder einer Gruppe auf unterschiedliche Arten die Berechtigung zum Bearbeiten eines Semantikmodells zuweisen.

• Arbeitsbereichsrolle: Die Zuweisung zu einer der Arbeitsbereichsrollen ermöglicht den Zugriff auf alle Semantikmodelle im Arbeitsbereich. Die Fähigkeit zum Anzeigen oder Bearbeiten eines vorhandenen Semantikmodells hängt von der Arbeitsbereichsrolle ab, die Sie zuweisen. Administratoren, Mitglieder und Mitwirkende können Inhalte innerhalb eines Arbeitsbereichs veröffentlichen oder bearbeiten.
• Berechtigungslinks pro Element: Wenn ein Freigabelink für einen Bericht erstellt wurde, wird über den Link indirekt auch die Berechtigung zum Lesen des Semantikmodells (und optional zum Erstellen, Schreiben und/oder erneuten Freigeben) erteilt.
• Direkte Zugriffsberechtigungen pro Element: Sie können die Berechtigung für den direkten Zugriff einem bestimmten Semantikmodell zuweisen.

Beachten Sie im folgenden Screenshot die Berechtigungen, die dem Semantikmodell Call Center Data zugewiesen sind. Ein Benutzender besitzt Leseberechtigung, die mithilfe von direkten Zugriffsberechtigungen pro Element erteilt wurde. Die verbleibenden Benutzenden und Gruppen verfügen über Berechtigungen, weil sie Arbeitsbereichsrollen zugewiesen sind.

Tipp

Die Verwendung von Berechtigungen pro Element (Links oder direkter Zugriff) funktioniert am besten, wenn die Absicht Benutzender oder einer Gruppe die Anzeige oder Bearbeitung eines bestimmten Elements im Arbeitsbereich ist. Sie eigne sich am besten, wenn der Benutzende nicht auf alle Elemente im Arbeitsbereich zugreifen darf. In den meisten Fällen wird empfohlen, Ihre Arbeitsbereiche so zu entwerfen, dass sich die Sicherheit einfacher mit Arbeitsbereichsrollen verwalten lässt. Vermeiden Sie nach Möglichkeit das Festlegen von Berechtigungen pro Element.

Berechtigungen für Semantikmodelle

Sie können folgende Berechtigungen für Semantikmodelle zuweisen:

• Lesen: Diese Berechtigung richtet sich hauptsächlich an Berichtsconsumer und ermöglicht es einem Bericht, Daten im Semantikmodell abzufragen. Weitere Informationen zu Berechtigungen zum Anzeigen schreibgeschützter Inhalte finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer.
• Erstellen: Diese Berechtigung richtet sich an Berichtserstellende und ermöglicht es Benutzer*innen, neue Berichte auf der Grundlage des freigegebenen Semantikmodells zu erstellen. Weitere Informationen finden Sie weiter unten in diesem Artikel im Abschnitt Berichtserstellenden-Berechtigungen.
• Schreiben: Diese Berechtigung richtet sich an Erstellende von Semantikmodellen, die Semantikmodelle erstellen, veröffentlichen und verwalten, und ermöglicht Benutzer*innen das Bearbeiten des Semantikmodells. Sie wird weiter unten in diesem Abschnitt beschrieben.
• Erneut freigeben: Diese Berechtigung richtet sich an alle Personen mit vorhandenen Berechtigungen für das Semantikmodell und ermöglicht es Benutzer*innen, das Semantikmodell für andere Benutzer*innen freizugeben. Sie wird weiter unten in diesem Abschnitt beschrieben.

Arbeitsbereichsadministrator*innen oder -mitglieder können die Berechtigungen für ein Semantikmodell bearbeiten.

Semantikmodellberechtigung „Lesen“

Die Semantikmodellberechtigung „Lesen“ richtet sich in erster Linie an Consumer. Diese Berechtigung ist erforderlich, damit Benutzende Daten anzeigen können, die in Berichten angezeigt werden. Beachten Sie, dass Berichte, die auf dem Semantikmodell basieren, auch über die Leseberechtigung verfügen müssen. Andernfalls kann der Bericht nicht geladen werden. Weitere Informationen zum Festlegen von Leseberechtigungen für Berichte finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer.

Semantikmodellberechtigung „Erstellen“

Neben der Semantikmodellberechtigung „Lesen“ benötigen Inhaltserstellende auch die Semantikmodellberechtigung Erstellen. Insbesondere ermöglicht die Erstellenberechtigung Berichtserstellenden Folgendes:

• Erstellen eines neuen Power BI-Berichts auf der Grundlage des Semantikmodells.
• Herstellen einer Verbindung mit dem Semantikmodell unter Verwendung von In Excel analysieren.
• Abfragen des Semantikmodells unter Verwendung des XMLA-Endpunkts.
• Exportieren der zugrunde liegenden Daten des Power BI-Berichtsvisuals (anstelle der zusammengefassten Daten, die vom Visual abgerufen werden).
• Erstellen einer DirectQuery-Verbindung mit einem Power BI-Semantikmodell. In diesem Fall stellt das neue Semantikmodell eine Verbindung mit einem oder mehreren vorhandenen Power BI-Semantikmodellen her. (Dies wird auch als Verkettung bezeichnet.) Zum Abfragen verketteter Semantikmodelle benötigen Erstellende von Semantikmodellen die Berechtigung „Erstellen“ für alle Upstream-Semantikmodelle. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Verkettete Semantikmodelle.

Sie können Benutzenden oder einer Gruppe die Erstellenberechtigung direkt oder indirekt auf unterschiedliche Weise erteilen.

• Direktes Gewähren von „Erstellen“ durch:
  • Festlegen von Semantikmodellberechtigungen auf der Seite Semantikmodelleinstellungen im Power BI-Dienst.
  • Festlegen von Semantikmodellberechtigungen mithilfe der Power BI-REST-API.
• Indirektes Gewähren von „Erstellen“ durch:
  • Freigeben eines Berichts oder Dashboards und Festlegen der Option zum Gewähren der Semantikmodellberechtigung „Erstellen“.
  • Veröffentlichen einer Power BI-App und Festlegen der erweiterten Option (für eine Zielgruppe) zum Gewähren der Berechtigung „Erstellen“ für die verwandten Semantikmodelle.
  • Zuweisen von Benutzenden zu den Arbeitsbereichsrollen „Administrator“, „Mitglied“ oder „Mitwirkender“.

Das direkte Festlegen der Berechtigung „Erstellen“ für ein Semantikmodell ist angemessen, wenn Sie die Sicherheit differenziert pro Element verwalten möchten. Das indirekte Festlegen der Berechtigung „Erstellen“ ist angemessen, wenn die Benutzenden, die den Inhalt über eine der indirekten Methoden anzeigen oder verwenden werden, auch neue Inhalte erstellen.

Tipp

Häufig unterscheiden sich die Benutzer*innen, die einen Bericht oder eine Power BI-App anzeigen, von den Benutzer*innen, die mithilfe der zugrunde liegenden Semantikmodelle neue Inhalte erstellen. Die meisten Consumer sind nur „Anzeigende Benutzer“, weshalb sie keine neuen Inhalte erstellen müssen. Es wird empfohlen, Ihre Inhaltserstellenden dahingehend zu schulen, dass sie nur die geringste Anzahl von Berechtigungen gewähren, die erforderlich ist.

Semantikmodellberechtigung „Schreiben“

In der Regel erfolgt das Festlegen von Berechtigungen für Personen, die Semantikmodelle bearbeiten und verwalten können, indem Benutzer*innen der Arbeitsbereichsrolle „Administrator“, „Mitglied“ oder „Mitwirkender“ zugewiesen werden. Es ist jedoch auch möglich, die Schreibberechtigung für ein bestimmtes Semantikmodell festzulegen.

Es wird empfohlen, nach Möglichkeit Arbeitsbereichsrollen zu verwenden, da dies die einfachste Möglichkeit zum Verwalten und Überwachen von Berechtigungen ist. Verwenden Sie die Semantikmodellberechtigung „Schreiben“ pro Element, wenn Sie sich dafür entschieden haben, weniger Arbeitsbereiche zu erstellen, und ein Arbeitsbereich Semantikmodelle für verschiedene Themenbereiche enthält, die die Verwaltung unterschiedlicher Berechtigungen erfordern.

Tipp

Eine Anleitung zum Organisieren von Arbeitsbereichen finden Sie in den Artikeln zur Arbeitsbereichsplanung.

Semantikmodellberechtigung „Erneut freigeben“

Die Semantikmodellberechtigung „Erneut freigeben“ ermöglicht es Benutzer*innen mit vorhandener Berechtigung, das Semantikmodell für andere Benutzer*innen freizugeben. Sie können diese Berechtigung gewähren, wenn Inhalte im Semantikmodell frei geteilt werden können, ganz nach dem Ermessen der Benutzer*innen.

In vielen Fällen wird empfohlen, die Verwendung der Berechtigung „Erneut freigeben“ einzuschränken, um sicherzustellen, dass Semantikmodellberechtigungen sorgfältig kontrolliert werden. Holen Sie die Genehmigung der Semantikmodellbesitzer*innen ein, bevor Sie die Berechtigung „Erneut freigeben“ gewähren.

Datensicherheit von Semantikmodellen

Sie können planen, weniger Semantikmodelle und Berichte zu erstellen, indem Sie Datensicherheit erzwingen. Das Ziel besteht darin, die Datensicherheit basierend auf der Identität des Benutzenden zu erzwingen, der den Inhalt anzeigt.

Erstellende von Semantikmodellen können Datensicherheit auf zwei Arten erzwingen.

• Sicherheit auf Zeilenebene (Row-Level Security, RLS) ermöglicht es Datenmodellierenden, den Zugriff auf eine Teilmenge von Daten zu beschränken.
• Sicherheit auf Objektebene (Object-Level Security, OLS) ermöglicht es Datenmodellierenden, den Zugriff auf bestimmte Tabellen und Spalten sowie deren Metadaten zu beschränken.

Die Implementierung von RLS und OLS richtet sich an Berichtsconsumer. Weitere Informationen finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer. Darin wird beschrieben, wie und wann RLS und OLS für Consumer erzwungen werden, die nur über die Berechtigung zum Anzeigen des Semantikmodells verfügen.

Informationen zu RLS und OLS, die auf andere Berichtserstellende abzielen, finden Sie weiter unten in diesem Artikel im Abschnitt Berechtigungen für Berichtserstellende.

Verkettete Semantikmodelle

Power BI-Semantikmodelle können in einem Prozess, der als Verkettung bezeichnet wird, eine Verbindung mit anderen Semantikmodellen herstellen. Bei der Verkettung handelt es sich um Verbindungen mit Upstream-Semantikmodellen. Weitere Informationen finden Sie unter Verwenden von DirectQuery für Power BI-Semantikmodelle und Analysis Services.

Mit der Mandanteneinstellung DirectQuery-Verbindungen mit Power BI-Semantikmodellen zulassen können Power BI-Administrator*innen festlegen, welche Gruppen von Inhaltserstellenden verkettete Semantikmodelle erstellen können. Wenn Sie Erstellende von Semantikmodellen nicht am Verketten von Semantikmodellen hindern möchten, können Sie diese Einstellung für die gesamte Organisation aktiviert lassen und Arbeitsbereichszugriff sowie Semantikmodellberechtigungen nutzen. In einigen Fällen sollten Sie erwägen, diese Funktion auf genehmigte Inhaltserstellende zu beschränken.

Hinweis

Erstellende von Semantikmodellen können die Verkettung auf ihr eigenes Semantikmodell beschränken. Hierzu muss in Power BI Desktop die Option DirectQuery-Verbindung mit diesem Semantikmodell deaktivieren aktiviert werden. Weitere Informationen finden Sie unter Verwalten von DirectQuery-Verbindungen mit einem veröffentlichten Semantikmodell.

API-Abfragen für Semantikmodelle

In einigen Situationen sollten Sie eine DAX-Abfrage mithilfe der Power BI-REST-API ausführen. So können Sie beispielsweise Überprüfungen der Datenqualität durchführen. Weitere Informationen finden Sie unter Datasets – Ausführen von Abfragen.

Mit der Mandanteneinstellung REST-API für das Ausführen von Datasetabfragen können Power BI-Administratoren festlegen, welche Gruppen Benutzender DAX-Abfragen mithilfe der Power BI-REST-API senden können. In den meisten Fällen können Sie diese Einstellung für die gesamte Organisation aktiviert lassen und sich auf Arbeitsbereichszugriff und Semantikmodellberechtigungen verlassen. In einigen Fällen sollten Sie erwägen, diese Funktion auf genehmigte Inhaltserstellende zu beschränken.

Prüfliste: Die Planung von Berechtigungen für Erstellende von Semantikmodellen umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für eine Strategie für die Berechtigungen für Erstellende von Semantikmodellen: Bestimmen Sie die Präferenzen und Anforderungen für die Verwaltung der Sicherheit für Erstellende von Semantikmodellen. Berücksichtigen Sie den Themenbereich und die Ebene der Datensensibilität. Berücksichtigen Sie außerdem, wer die Verantwortung für die Verwaltung von Daten und Berechtigungen in zentralisierten und dezentralisierten Geschäftseinheiten übernehmen darf.
• Überprüfen, wie Arbeitsbereichsrollen für Erstellende von Semantikmodellen behandelt werden: Bestimmen Sie die Auswirkungen auf den Entwurfsprozess für Ihren Arbeitsbereich. Erstellen Sie separate Datenarbeitsbereiche für jeden Themenbereich, damit Sie die Arbeitsbereichsrollen und die Semantikmodellsicherheit für jeden Themenbereich einfacher verwalten können.
• Bereitstellen von Anleitungen zum Verwalten von Berechtigungen für Erstellende von Semantikmodellen: Nehmen Sie für Erstellende von Semantikmodellen eine Dokumentation dazu auf, wie Semantikmodellberechtigungen verwaltet werden sollen. Veröffentlichen Sie diese Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.
• Entscheiden, wer DirectQuery-Verbindungen für Power BI-Semantikmodelle verwenden kann: Entscheiden Sie, ob eingeschränkt werden soll, welche Erstellenden von Power BI-Semantikmodellen (mit der vorhandenen Berechtigung „Erstellen“ für ein Semantikmodell) eine Verbindung mit einem Power BI-Semantikmodell herstellen können. Legen Sie die Mandanteneinstellung DirectQuery-Verbindungen mit Power BI-Semantikmodellen zulassen entsprechend dieser Entscheidung fest. Wenn Sie beschließen, diese Funktion einzuschränken, verwenden Sie ggf. eine Gruppe wie Genehmigte Erstellende von Power BI-Semantikmodellen.
• Entscheiden, wer Power BI-Semantikmodelle mithilfe der REST-API abfragen kann: Entscheiden Sie, ob Power BI-Inhaltserstellende daran gehindert werden sollen, Power BI-Semantikmodelle mithilfe der Power BI-REST-API abzufragen. Legen Sie die Mandanteneinstellung REST-API für das Ausführen von Datasetabfragen entsprechend dieser Entscheidung fest. Wenn Sie sich entschließen, diese Funktion einzuschränken, erwägen Sie die Verwendung einer Gruppe wie Genehmigte Power BI-Berichtserstellende.
• Entscheiden für eine Strategie für die Verwendung von RLS oder OLS für Erstellende von Semantikmodellen: Überlegen Sie, in welchen Anwendungsfällen und zu welchen Zwecken RLS oder OLS verwendet werden soll. Berücksichtigen Sie die Strategie für den Arbeitsbereichsentwurf und wer über Lese- bzw. Bearbeitungsberechtigungen verfügt, wenn Sie RLS oder OLS für Erstellende von Semantikmodellen erzwingen möchten.

Berechtigungen für Berichtserstellende

Berichtserstellende benötigen Arbeitsbereichszugriff, um Berichte im Power BI-Dienst zu erstellen oder sie aus Power BI Desktop veröffentlichen zu können. Sie müssen Administrator, Mitglied oder Mitwirkender im Zielarbeitsbereich sein.

Berichtserstellende sollten nach Möglichkeit ein vorhandenes freigegebenes Semantikmodell (über eine Liveverbindung oder per DirectQuery) verwenden. Auf diese Weise wird der Prozess der Berichterstellung vom Prozess der Semantikmodellerstellung entkoppelt. Diese Art von Trennung bietet viele Vorteile für Sicherheits- und Teamentwicklungsszenarien.

Berichtserstellende müssen Arbeitsbereichsadministrator, -mitglied oder -mitwirkender sein.

Anders als bei Semantikmodellen gibt es für Berichte keine Schreibberechtigung. Zur Unterstützung von Berichtserstellenden müssen Arbeitsbereichsrollen verwendet werden. Aus diesem Grund ist ein optimaler Arbeitsbereichsentwurf wichtig, um die Anforderungen an die Inhaltsorganisation und die Sicherheit in Einklang zu bringen.

Tipp

Informationen zu Berechtigungen zur Unterstützung von Berichtsconsumern (einschließlich der Berechtigungen pro Element „Lesen“ und „Erneut freigeben“) finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer.

Berechtigungen „Lesen“ und „Erstellen“ für das zugrunde liegende Semantikmodell

Berichtserstellende müssen über die Berechtigungen „Lesen“ und „Erstellen“ für die Semantikmodelle verfügen, die von ihren Berichten verwendet werden. Dies schließt auch verketteter Semantikmodelle ein. Diese Berechtigung kann explizit für die einzelnen Semantikmodelle oder implizit für arbeitsbereichsspezifische Semantikmodell erteilt werden, wenn der bzw. die Berichtserstellende Arbeitsbereichsadministrator*in, -mitglied oder -mitwirkende*r ist.

Mit der Mandanteneinstellung Semantikmodelle arbeitsbereichsübergreifend verwenden können Power BI-Administrator*innen festlegen, welche Benutzergruppen Berichte erstellen können, die Semantikmodelle aus anderen Arbeitsbereichen verwenden. Diese Einstellung richtet sich an Erstellende von Semantikmodellen und Berichten. In der Regel wird empfohlen, diese Einstellung für die gesamte Organisation aktiviert zu lassen und sich auf arbeitsbereichsspezifische Zugriffseinstellungen und auf Semantikmodellberechtigungen zu verlassen. Auf diese Weise können Sie die Verwendung vorhandener Semantikmodelle fördern. In einigen Fällen sollten Sie erwägen, diese Funktion nur auf genehmigte Inhaltserstellende zu beschränken.

Außerdem gibt es die Mandanteneinstellung Liveverbindungen zulassen, mit der Power BI-Administrator*innen festlegen können, welche Benutzergruppen Liveverbindungen mit Semantikmodellen in Power BI Desktop oder Excel erstellen können. Sie richtet sich speziell an Berichtserstellende und erfordert außerdem, dass diesen die Berechtigungen „Lesen“ und „Erstellen“ für das Semantikmodell erteilt werden, das vom Bericht verwendet wird. Es wird empfohlen, diese Einstellung für die gesamte Organisation aktiviert zu lassen und sich auf Arbeitsbereichszugriff und Semantikmodellberechtigungen zu verlassen. Auf diese Weise können Sie die Verwendung vorhandener Semantikmodelle fördern. In einigen Fällen sollten Sie erwägen, diese Funktion nur auf genehmigte Inhaltserstellende zu beschränken.

Datensicherheit für zugrunde liegendes Semantikmodell

RLS und OLS (weiter oben in diesem Artikel beschrieben) zielen auf Berichtsconsumer ab. Manchmal muss sie jedoch auch für Berichtserstellende erzwungen werden. Das Erstellen getrennter Arbeitsbereiche ist gerechtfertigt, wenn RLS für Berichtserstellende als auch für Berichtsconsumer erzwungen werden muss.

Stellen Sie sich folgendes Szenario vor:

• Zentralisierte freigegebene Semantikmodelle mit RLS: Das Enterprise BI-Team hat vertriebsbezogene Semantikmodelle im Arbeitsbereich Sales Data (Vertriebsdaten) veröffentlicht. Diese Semantikmodelle erzwingen RLS, um Vertriebsdaten für die zugewiesene Vertriebsregion des Berichtsconsumers anzuzeigen.
• Dezentralisierte Self-Service-Berichtserstellende: Die Geschäftseinheit „Vertrieb und Marketing“ verfügt über zahlreiche fähige Analysten, die ihre eigenen Berichte erstellen. Sie veröffentlichen ihre Berichte im Arbeitsbereich Sales Analytics (Vertriebsanalysen).
• Berechtigungen „Lesen“ und „Erstellen“ für Semantikmodelle: Nach Möglichkeit verwenden die Analyst*innen die Semantikmodelle aus dem Arbeitsbereich Sales Data, um eine unnötige Duplizierung von Daten zu vermeiden. Da die Analyst*innen nur über die Berechtigungen „Lesen“ und „Erstellen“ für diese Semantikmodelle verfügen (und nicht über die Berechtigung „Schreiben“ oder „Bearbeiten“), wird RLS für die Berichtserstellenden (und auch für die Berichtsconsumer) erzwungen.
• Berechtigungen zum Bearbeiten für den Berichterstellungsarbeitsbereich: Die Analysten verfügen im Arbeitsbereich Sales Analytics über mehr Rechte. Die Arbeitsbereichsrollen „Administrator“, „Mitglied“ oder „Mitwirkender“ gestatten es ihnen, ihre Berichte zu veröffentlichen und zu verwalten.

Weitere Informationen zu RLS und OLS finden Sie im Artikel Planung der Sicherheit für Berichtsconsumer. Darin wird beschrieben, wie und wann RLS und OLS für Consumer erzwungen werden, die nur über die Berechtigung zum Anzeigen des Semantikmodells verfügen.

Herstellen einer Verbindung mit externen Semantikmodellen

Wenn Berichtserstellende eine Verbindung mit einem freigegebenen Semantikmodell für ihren Bericht herstellen, stellen sie normalerweise eine Verbindung mit einem freigegebenen Semantikmodell her, das in ihrem eigenen Power BI-Mandanten veröffentlicht wurde. Wenn die Berechtigung erteilt wurde, ist es auch möglich, eine Verbindung mit einem freigegebenen Semantikmodell in einem anderen Mandanten herzustellen. Der andere Mandant könnte ein Partner, Kunde oder Anbietender sein.

Diese Funktion wird als direkte Semantikmodellfreigabe (oder mandantenübergreifende Semantikmodellfreigabe) bezeichnet. Die von Berichtserstellenden erstellten Berichte (oder die neuen zusammengesetzten Modelle, die von Semantikmodellerstellenden erstellt wurden) werden mithilfe Ihres normalen Prozesses in Ihrem Power BI-Mandanten gespeichert und geschützt. Das ursprüngliche freigegebene Semantikmodell verbleibt in seinem ursprünglichen Power BI-Mandanten, und alle Berechtigungen werden dort verwaltet.

Weitere Informationen finden Sie im Artikel Sicherheitsplanung auf Mandantenebene. Er enthält Informationen zu den Mandanten- und Semantikmodelleinstellungen, mit denen die externe Freigabe ermöglicht wird.

Ausgewählte Tabellen

In Power BI Desktop können Erstellende von Semantikmodellen eine Modelltabelle als ausgewählte Tabelle konfigurieren. Wenn das Semantikmodell im Power BI-Dienst veröffentlicht wird, können Berichtserstellende den Datentypkatalog in Excel verwenden, um die ausgewählte Tabelle zu finden, sodass sie ausgewählte Tabellendaten hinzufügen können, um ihre Excel-Arbeitsblätter zu erweitern.

Mit der Mandanteneinstellung Verbindungen mit ausgewählten Tabellen zulassen können Power BI-Administratoren festlegen, welche Gruppen Benutzender auf ausgewählte Tabellen zugreifen können. Sie richtet sich an Excel-Benutzer, die auf ausgewählte Power BI-Tabellen in Excel-Organisationsdatentypen zugreifen möchten. Es wird empfohlen, diese Einstellung für die gesamte Organisation aktiviert zu lassen und sich auf Arbeitsbereichszugriff und Semantikmodellberechtigungen zu verlassen. Auf diese Weise können Sie die Verwendung ausgewählter Tabellen fördern.

Berechtigungen für benutzerdefinierte Visuals

Zusätzlich zu den Kernvisuals können Power BI-Berichtserstellende auch benutzerdefinierte Visuals verwenden. In Power BI Desktop können benutzerdefinierte Visuals von Microsoft AppSource heruntergeladen werden. Sie können auch intern mithilfe des Power BI SDK entwickelt und durch Öffnen der Visual-Datei (PBVIZ) installiert werden.

Einige Visuals, die von AppSource heruntergeladen werden können, sind zertifizierte Visuals. Zertifizierte Visuals erfüllen bestimmte vorgegebene Codeanforderungen, die vom Power BI-Team getestet und genehmigt wurden. Mit den Tests wird überprüft, ob Visuals nicht auf externe Dienste oder Ressourcen zugreifen.

Mit der Mandanteneinstellung Mit dem Power BI SDK erstellte Visuals zulassen, können Power BI-Administratoren steuern, welche Gruppen Benutzender benutzerdefinierte Visuals verwenden können.

Außerdem gibt es die Mandanteneinstellung Nur zertifizierte Visuals hinzufügen und verwenden, mit der Power BI-Administratoren die Verwendung nicht zertifizierter Visuals im Power BI-Dienst blockieren können. Diese Einstellung kann für die gesamte Organisation aktiviert oder deaktiviert werden.

Hinweis

Wenn Sie die Verwendung nicht zertifizierter Visuals blockieren, gilt dies nur für den Power BI-Dienst. Wenn Sie deren Verwendung in Power BI Desktop einschränken möchten, bitten Sie Ihre Systemadministratoren, eine Gruppenrichtlinieneinstellung zu verwenden, um ihre Verwendung in Power BI Desktop zu blockieren. Durch diesen Schritt wird sichergestellt, dass Berichtserstellende keine Zeit und Mühe mit dem Erstellen eines Berichts verschwenden, der bei der Veröffentlichung im Power BI-Dienst nicht funktioniert. Es wird dringend empfohlen, dass Sie für Ihre Benutzer konsistente Erfahrungen im Power BI-Dienst (mit der Mandanteneinstellung) und in Power BI Desktop (mit einer Gruppenrichtlinie) einrichten.

Power BI Desktop verfügt über eine Option zum Anzeigen einer Sicherheitswarnung, wenn Berichtserstellende dem Bericht ein benutzerdefiniertes Visual hinzufügen. Berichtserstellende können diese Option deaktivieren. Diese Option testet nicht, ob das Visual zertifiziert ist.

Power BI-Administratoren können benutzerdefinierte Visuals in ihrer Organisation genehmigen und implementieren. Berichtserstellende können diese Visuals dann leicht ermitteln, aktualisieren und verwenden. Administratoren können diese Visuals dann verwalten, indem sie Versionen aktualisieren oder bestimmte benutzerdefinierte Visuals deaktivieren oder aktivieren. Dieser Ansatz ist nützlich, wenn Sie Ihren Berichtserstellenden ein intern entwickeltes Visual zur Verfügung stellen möchten, oder wenn Sie ein benutzerdefiniertes Visual von einem Anbietenden beziehen, der sich nicht in AppSource befindet. Weitere Informationen finden Sie unter Power BI-Organisationsvisuals.

Erwägen Sie eine ausgewogene Strategie zum Aktivieren nur zertifizierter benutzerdefinierter Visuals in Ihrer Organisation (mit der zuvor beschriebenen Mandanteneinstellung und Gruppenrichtlinie), während Sie Organisationsvisuals bereitstellen, um alle Ausnahmen zu behandeln.

Checkliste: Die Planung von Berechtigungen für Berichtserstellende umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für eine Strategie für die Berechtigungen für Berichtserstellende: Bestimmen Sie, welche Präferenzen und Anforderungen für die Verwaltung der Sicherheit für Berichtserstellende vorhanden sind. Berücksichtigen Sie den Themenbereich und die Ebene der Datensensibilität. Berücksichtigen Sie außerdem, wer die Verantwortung für das Erstellen und Verwalten von Berichten in zentralisierten und dezentralisierten Geschäftseinheiten übernehmen darf.
• Überprüfen, wie Arbeitsbereichsrollen für Berichtserstellende behandelt werden: Bestimmen Sie die Auswirkungen auf den Entwurfsprozess für Ihren Arbeitsbereich. Erstellen Sie separate Datenarbeitsbereiche und Berichtsarbeitsbereiche für jeden Themenbereich, um die Arbeitsbereichsrollen (und die zugrunde liegende Semantikmodellsicherheit) für den Themenbereich zu vereinfachen.
• Bereitstellen einer Anleitung für Berichtserstellende zum Verwalten von Berechtigungen: Nehmen Sie für Berichtserstellende eine Dokumentation dazu auf, wie Berechtigungen für Berichtsconsumer verwaltet werden sollen. Veröffentlichen Sie diese Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.
• Entscheiden, wer freigegebene Semantikmodelle verwenden kann: Entscheiden Sie, eingeschränkt werden soll, welche Power BI-Berichtserstellenden (die bereits über die Berechtigungen „Lesen“ und „Erstellen“ für ein Semantikmodell verfügen) Semantikmodelle arbeitsbereichsübergreifend verwenden können. Legen Sie die Mandanteneinstellung Semantikmodelle arbeitsbereichsübergreifend verwenden entsprechend dieser Entscheidung fest. Wenn Sie sich entschließen, diese Funktion einzuschränken, erwägen Sie die Verwendung einer Gruppe wie Genehmigte Power BI-Berichtserstellende.
• Entscheiden, wer Liveverbindungen verwenden kann: Entscheiden Sie, ob eingeschränkt werden soll, welche Power BI-Berichtserstellenden (die bereits über die Berechtigungen „Lesen“ und „Erstellen“ für ein Semantikmodell verfügen) Liveverbindungen verwenden können. Legen Sie die Mandanteneinstellung Liveverbindungen zulassen entsprechend dieser Entscheidung fest. Wenn Sie sich entschließen, diese Funktion einzuschränken, erwägen Sie die Verwendung einer Gruppe wie Genehmigte Power BI-Berichtserstellende.
• Entscheiden für eine Strategie für die Verwendung von RLS für Berichtserstellende: Überlegen Sie, in welchen Anwendungsfällen und zu welchen Zwecken Sicherheit auf Zeilenebene (RLS) verwendet werden soll. Berücksichtigen Sie die Strategie für den Arbeitsbereichsentwurf, um sicherzustellen, dass RLS für Berichtserstellende erzwungen wird.
• Entscheiden für eine Strategie für die Verwendung benutzerdefinierter Visuals: Berücksichtigen Sie Ihre Strategie dafür, welche Berichtserstellenden benutzerdefinierte Visuals verwenden können. Legen Sie die Mandanteneinstellung Mit dem Power BI SDK erstellte Visuals zulassen entsprechend dieser Entscheidung fest. Erstellen Sie ggf. einen Prozess für die Verwendung von Organisationsvisuals.

Berechtigungen für Dataflowerstellende

Dataflows sind hilfreich für die Zentralisierung der Datenaufbereitung, damit die in Power Query ausgeführten Schritte nicht für zahlreiche Semantikmodelle wiederholt werden. Sie sind ein Baustein, um eine einzige zuverlässige Wissensquelle (single source of truth) zu erzielen, Analysten daran zu hindern, direkten Zugriff auf Quellen anzufordern, und bei der Ausführung von ETL-Vorgängen (Extrahieren, Transformieren und Laden) im großen Stil zu helfen.

Dataflowerstellende müssen Arbeitsbereichsadministrator, -mitglied oder -mitwirkender sein.

Erstellende von Semantikmodellen, die einen Dataflow nutzen möchten (z. B. aus einem neuen Datenmodell, das in Power BI Desktop oder in einem anderen Arbeitsbereich erstellt wurde), können einer beliebigen Arbeitsbereichsrolle angehören, einschließlich der Rolle „Anzeigender Benutzer“. Für Dataflows gibt es kein Konzept von Sicherheit auf Zeilenebene (RLS).

Zusätzlich zu Arbeitsbereichsrollen muss die Mandanteneinstellung Dataflows erstellen und verwenden aktiviert sein. Diese Mandanteneinstellung gilt für die gesamte Organisation.

Stellen Sie sich folgendes Szenario vor:

• Viele Semantikmodelle in der Organisation müssen dynamische RLS erzwingen. Dies erfordert die Speicherung von Benutzerprinzipalnamen (User Principal Names, UPNs) im Semantikmodell (um nach der Identität des Berichtsconsumers zu filtern).
• Dataflowerstellende, die zur Personalabteilung gehören, erstellen einen Dataflow mit aktuellen Mitarbeitendendetails, einschließlich ihrer UPNs. Sie richten den Dataflow so ein, dass er täglich aktualisiert wird.
• Erstellende von Semantikmodellen nutzen dann den Dataflow in ihren Modellentwürfen, um RLS einzurichten.

Weitere Informationen zur Verwendung von Dataflows finden Sie in den Anwendungsszenarien zur Self-Service-Datenaufbereitung und zur erweiterte Datenaufbereitung.

Checkliste: Die Planung von Berechtigungen für Dataflowerstellende umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für eine Strategie für die Berechtigungen für Dataflowerstellende: Bestimmen Sie, welche Präferenzen und Anforderungen für die Verwaltung der Sicherheit für Dataflowerstellende vorhanden sind. Berücksichtigen Sie, wer die Verantwortung für die Verwaltung von Datenaufbereitungsaktivitäten in zentralisierten und dezentralisierten Geschäftseinheiten übernehmen darf bzw. zu deren Übernahme ermutigt wird.
• Entscheiden, wer Dataflows erstellen kann: Entscheiden Sie, ob es Einschränkungen geben soll, welche Power BI-Datenerstellenden Dataflows erstellen können. Legen Sie die Mandanteneinstellung Dataflows erstellen und verwenden entsprechend dieser Entscheidung fest.
• Überprüfen, wie Arbeitsbereichsrollen für Dataflowerstellende behandelt werden: Bestimmen Sie die Auswirkungen auf den Entwurfsprozess für Ihren Arbeitsbereich. Erstellen Sie separate Dataflowarbeitsbereiche pro Themenbereich, damit Sie, wo angebracht, Arbeitsbereichsrollen und Berechtigungen für jeden Themenbereich separat behandeln können.

Berechtigungen für Datamarterstellende

Ein Datamart ist eine Self-Service-Analyselösung, mit der Benutzende Daten speichern und untersuchen können, die in eine vollständig verwaltete Datenbank geladen sind. Er umfasst auch ein automatisch generiertes Semantikmodell.

Datamarts bieten eine einfache Low-Code-Erfahrung zum Erfassen von Daten aus unterschiedlichen Datenquellen sowie zum Extrahieren, Transformieren und Laden (ETL) der Daten mithilfe von Power Query Online. Die Daten werden in eine Azure SQL-Datenbank geladen, die vollständig verwaltet ist und weder Feineinstellungen noch Optimierung erfordert. Das automatisch generierte Semantikmodell wird immer mit der verwalteten Datenbank synchronisiert, da es sich im DirectQuery-Modus befindet.

Sie können einen Datamart erstellen, wenn Sie Arbeitsbereichsadministrator, -mitglied oder -mitwirkender sind. Arbeitsbereichsrollen werden auch zu Rollen auf Datenbankebene in der Azure SQL-Datenbank zugeordnet (da die Datenbank jedoch vollständig verwaltet ist, können Benutzerberechtigungen jedoch in der relationalen Datenbank nicht bearbeitet oder verwaltet werden).

Mit der Mandanteneinstellung Datamarts erstellen können Power BI-Administratoren festlegen, welche Gruppen Benutzender Datamarts erstellen können.

Freigeben von Datamarts

Für Datamarts hat der Begriff Freigeben eine Bedeutung, die sich von anderen Power BI-Inhaltstypen unterscheidet. In der Regel richtet sich ein Freigabevorgang an einen Consumer, weil er eine schreibgeschützte Berechtigung für ein Element, z. B. einen Bericht, bereitstellt.

Das Freigeben eines Datamarts richtet sich an Inhaltserstellende (und nicht an Consumer). Es gewährt die Berechtigungen „Lesen“ und „Erstellen“, sodass Benutzer*innen je nach Präferenz das Semantikmodell oder die relationale Datenbank abfragen können.

Das Freigeben eines Datamarts ermöglicht Inhaltserstellenden Folgendes:

• Erstellen von Inhalten mithilfe des automatisch generierten Semantikmodells: Das Semantikmodell ist die semantische Ebene, auf der Power BI-Berichte erstellt werden können. Die meisten Berichtserstellenden sollten das Semantikmodell verwenden.
• Herstellen einer Verbindung mit und Abfragen der Azure SQL-Datenbank: Die relationale Datenbank ist nützlich für Inhaltserstellende, die neue Semantikmodelle oder paginierte Berichte erstellen möchten. Sie können SQL-Abfragen (Structured Query Language) schreiben, um Daten mithilfe des SQL-Endpunkts abzurufen.

Sicherheit auf Zeilenebene für Datamarts

Sie können RLS für Datamarts definieren, um den Datenzugriff für angegebene Benutzende einzuschränken. RLS wird im Datamart-Editor im Power BI-Dienst eingerichtet und automatisch auf das automatisch generierte Semantikmodell und die Azure SQL-Datenbank angewendet (als Sicherheitsregeln).

Unabhängig davon, wie Benutzer*innen eine Verbindung mit dem Datamart (mit dem Semantikmodell oder der Datenbank) herstellen, werden identische RLS-Berechtigungen erzwungen.

Checkliste: Die Planung von Berechtigungen für Datamarterstellende umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für eine Strategie für die Berechtigungen für Datamarterstellende: Bestimmen Sie, welche Präferenzen und Anforderungen für die Verwaltung der Sicherheit für Datamarterstellende vorhanden sind. Berücksichtigen Sie, wer die Verantwortung für die Verwaltung von Daten in zentralisierten und dezentralisierten Geschäftseinheiten übernehmen darf bzw. zu deren Übernahme ermutigt wird.
• Entscheiden, wer Datamarts erstellen kann: Entscheiden Sie, ob es Einschränkungen geben soll, welche Power BI-Datenerstellenden Datamarts erstellen können. Legen Sie die Mandanteneinstellung Datamarts erstellen entsprechend dieser Entscheidung fest. Wenn Sie sich entschließen, den Personenkreis einzuschränken, der Datamarts erstellen kann, sollten Sie eine Gruppe wie Genehmigte Power BI-Datamarterstellende verwenden.
• Überprüfen, wie Arbeitsbereichsrollen für Datamarterstellende behandelt werden: Bestimmen Sie die Auswirkungen auf den Entwurfsprozess für Ihren Arbeitsbereich. Erstellen Sie separate Datenarbeitsbereiche für jeden Themenbereich, um die Arbeitsbereichsrollen und die Semantikmodellsicherheit für den Themenbereich zu vereinfachen.
• Bereitstellen von Anleitungen für Datamarterstellende zum Verwalten von Berechtigungen: Nehmen Sie für Datamarterstellende eine Dokumentation dazu auf, wie Datamartberechtigungen verwaltet werden sollen. Veröffentlichen Sie diese Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.
• Entscheiden für eine Strategie für die Verwendung von RLS in Datamarts: Überlegen Sie, in welchen Anwendungsfällen und zu welchen Zwecken Sie RLS in einem Datamart verwenden möchten.

Berechtigungen für Scorecarderstellende

Mit Metriken in Power BI können Sie spezifische Metriken zusammenstellen und diese in Bezug auf wichtige Geschäftsziele nachverfolgen. Metriken werden Scorecards hinzugefügt, die für andere Benutzer freigegeben und in einem einzelnen Bereich angezeigt werden können.

Scorecards können mit drei Berechtigungsstufen gesichert werden:

• Den Arbeitsbereich.
• Scorecardberechtigungen (pro Element).
• Metriken (innerhalb der Scorecard).

Benutzende, die eine Scorecard erstellen oder vollständig verwalten, müssen Arbeitsbereichsadministrator, -mitglied oder -mitwirkender sein.

Da Metriken häufig mehrere Themenbereiche umfassen, empfiehlt es sich, einen separaten Arbeitsbereich zu erstellen, damit Sie Berechtigungen für Erstellende und Consumer unabhängig verwalten können.

Mit der Mandanteneinstellung Metriken erstellen und verwenden können Power BI-Administratoren festlegen, welche Gruppen Benutzender Scorecardmetriken erstellen können.

Scorecardberechtigungen

Sie können die folgenden Scorecardberechtigungen zuweisen.

• Lesen: Diese Berechtigung gestattet Benutzenden das Anzeigen der Scorecard.
• Erneut freigeben: Diese Berechtigung richtet sich an alle Personen mit vorhandenen Berechtigungen für die Scorecard und ermöglicht Benutzenden, die Scorecard für andere Benutzende freizugeben.

Konsistent mit den anderen Inhaltstypen im Power BI-Dienst sind die Berechtigungen pro Element nützlich, wenn ein Element für einen anderen Benutzer freigegeben werden soll. Es wird empfohlen, nach Möglichkeit Arbeitsbereichsrollen und App-Berechtigungen zu verwenden.

Berechtigungen auf Metrikebene

Jede Scorecard verfügt über einen Satz von Berechtigungen auf Metrikebene, die Sie in den Scorecardeinstellungen einrichten können. Die Berechtigungen auf Metrikebene (innerhalb einer Scorecard) können abweichend von den Berechtigungen des Arbeitsbereichs oder der Scorecard (pro Element) erteilt werden.

Mit den Rollen auf Metrikebene können Sie Folgendes festlegen:

• Wer einzelne Metriken auf einer Scorecard anzeigen kann.
• Wer einzelne Metriken auf folgende Weise aktualisieren kann:
  • Aktualisieren des Status während eines Eincheckvorgangs.
  • Hinzufügen von Notizen während eines Eincheckvorgangs.
  • Aktualisieren des aktuellen Werts während eines Eincheckvorgangs.

Um den Umfang der zukünftigen Wartung zu verringern, ist es möglich, Standardberechtigungen festzulegen, die von den von Ihnen in Zukunft erstellten Teilmetriken geerbt werden.

Checkliste: Die Planung von Berechtigungen für Metrikerstellende umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für eine Strategie für die Berechtigungen für Scorecarderstellende: Bestimmen Sie, welche Präferenzen und Anforderungen für die Verwaltung der Sicherheit für Scorecarderstellende vorhanden sind. Berücksichtigen Sie, wer die Verantwortung für die Verwaltung von Daten in zentralisierten und dezentralisierten Geschäftseinheiten übernehmen darf bzw. zu deren Übernahme ermutigt wird.
• Entscheiden, wer Scorecards erstellen kann: Entscheiden Sie, ob es Einschränkungen geben soll, welche Power BI-Datenerstellenden Scorecards erstellen können. Legen Sie die Mandanteneinstellung Metriken erstellen und verwenden entsprechend dieser Entscheidung fest. Wenn Sie sich entschließen, den Personenkreis einzuschränken, der Scorecards erstellen kann, sollten Sie eine Gruppe wie Genehmigte Power BI-Scorecarderstellende verwenden.
• Überprüfen, wie Arbeitsbereichsrollen für Scorecarderstellende behandelt werden: Bestimmen Sie die Auswirkungen auf den Entwurfsprozess für Ihren Arbeitsbereich. Erwägen Sie die Erstellung separater Arbeitsbereiche für Scorecards, wenn der Inhalt mehrere Themenbereiche umfasst.
• Bereitstellen von Anleitungen für Scorecarderstellende zum Verwalten von Berechtigungen: Nehmen Sie für Scorecarderstellende eine Dokumentation dazu auf, wie Berechtigungen auf Metrikebene verwaltet werden sollen. Veröffentlichen Sie diese Informationen in Ihrem zentralisierten Portal und in Ihren Schulungsmaterialien.

Veröffentlichen von Inhalten

Dieser Abschnitt enthält Themen, die sich auf die Veröffentlichung von Inhalten beziehen, die für Inhaltserstellende relevant sind.

Arbeitsbereiche

Inhaltserstellende benötigen Zugriff der Rolle „Administrator“, „Mitglied“ oder „Mitwirkender“, um Inhalte in einem Arbeitsbereich zu veröffentlichen. Weitere Informationen finden Sie weiter oben in diesem Artikel unter Arbeitsbereichsrollen.

Mit Ausnahme von persönlicher BI sollten Inhaltserstellende ermutigt werden, Inhalte in Standardarbeitsbereichen zu veröffentlichen, anstatt in ihren persönlichen Arbeitsbereichen.

Die Mandanteneinstellung Erneute Veröffentlichung blockieren und Paketaktualisierung deaktivieren ändert das Verhalten für das Veröffentlichen von Semantikmodellen. Wenn diese Option aktiviert ist, können Arbeitsbereichsadministrator*innen, -mitglieder oder -mitwirkende keine Änderungen an einem Semantikmodell veröffentlichen. Nur Semantikmodellbesitzer*innen dürfen eine Aktualisierung veröffentlichen (wodurch die Übernahme eines Semantikmodells vor der Veröffentlichung eines aktualisierten Semantikmodells erzwungen wird). Diese Mandanteneinstellung gilt für die gesamte Organisation. Aktivieren Sie sie mit einem gewissen Maß an Vorsicht, da sie sich auf alle Semantikmodelle für den gesamten Mandanten auswirkt. Teilen Sie Ihren Erstellenden von Semantikmodellen mit, was sie erwarten können, da sich dadurch das normale Verhalten von Arbeitsbereichsrollen ändert.

Power Apps-Synchronisierung

Es ist möglich, eine Power Apps-Lösung zu erstellen, die eingebettete Power BI-Berichte enthält. Der Power Apps-Prozess erstellt automatisch einen dedizierten Power BI-Arbeitsbereich zum Speichern und Schützen der Power BI-Berichte und -Semantikmodelle. Zum Verwalten von Elementen, die sowohl in Power Apps als auch in Power BI vorhanden sind, gibt es einen Synchronisierungsprozess.

Der Prozess synchronisiert Sicherheitsrollen, um sicherzustellen, dass Power BI die selben Rollen erbt, die ursprünglich in Power Apps eingerichtet wurden. Außerdem ermöglicht der Prozess Inhaltserstellenden die Verwaltung von Berechtigungen dafür, wer die Power BI-Berichte (und die zugehörigen Semantikmodelle) anzeigen kann, die in eine Power App eingebettet sind.

Weitere Informationen zum Synchronisieren von Power Apps-Rollen mit Power BI-Arbeitsbereichsrollen finden Sie unter Berechtigungssynchronisierung zwischen Power Apps-Umgebung und Power BI-Arbeitsbereich.

Zugriff auf Bereitstellungspipeline

Inhaltserstellende und -besitzende können Power BI-Bereitstellungspipelines für die Self-Service-Inhaltsveröffentlichung verwenden. Bereitstellungspipelines vereinfachen den Veröffentlichungsprozess und verbessern dem Umfang der Kontrolle beim Freigeben neuer Inhalte.

Pipelineberechtigungen (für Benutzende, die Inhalte mit einer Bereitstellungspipeline bereitstellen können) werden getrennt von den Arbeitsbereichsrollen verwaltet. Zugriff auf den Arbeitsbereich und die Bereitstellungspipeline ist für Benutzer*innen erforderlich, die eine Bereitstellung durchführen.

Inhaltserstellende benötigen möglicherweise auch Folgendes:

• Berechtigungen zum Erstellen von Arbeitsbereichen (wenn Arbeitsbereiche von der Pipeline erstellt werden müssen).
• Premium- oder Fabric-Kapazitätsberechtigungen (wenn Arbeitsbereiche von der Pipeline zugewiesen werden).

Wichtig

Manchmal bezieht sich dieser Artikel auf Power BI Premium oder seine Kapazitätsabonnements (P-SKUs). Beachten Sie, dass Microsoft derzeit Kaufoptionen konsolidiert und die SKUs von Power BI Premium pro Kapazität einstellt. Neue und vorhandene Kunden sollten stattdessen den Kauf von Fabric-Kapazitätsabonnements (F-SKUs) in Betracht ziehen.

Weitere Informationen finden Sie unter Wichtige Updates zur Power BI Premium-Lizenzierung und Häufig gestellte Fragen zu Power BI Premium.

Weitere Informationen finden Sie unter Zugriff auf Bereitstellungspipeline.

XMLA-Endpunkt

Beim XMLA-Endpunkt wird das XMLA-Protokoll verwendet, um alle Features eines tabellarischen Datenmodells verfügbar zu machen. Dazu gehören einigeDatenmodellierungsvorgänge, die von Power BI Desktop nicht unterstützt werden. Mithilfe der TOM-API (Tabellenobjektmodell) können Sie programmgesteuerte Änderungen am Datenmodell vornehmen.

Der XMLA-Endpunkt sorgt darüber hinaus auch für Konnektivität. Mit einem Semantikmodell kann nur dann eine Verbindung hergestellt werden, wenn der Lizenzmodus des Arbeitsbereichs auf Premium-Einzelbenutzerlizenz, Premium-Kapazitätslizenz oder Eingebettet festgelegt ist. Sobald eine Verbindung hergestellt wurde, kann ein XMLA-kompatibles Tool mit dem Datenmodell interagieren, um Daten zu lesen oder zu schreiben. Weitere Informationen dazu, wie Sie den XMLA-Endpunkt für die Verwaltung eines Semantikmodells verwenden können, finden Sie im Anwendungsszenario zur erweiterten Datenmodellverwaltung.

Der Zugriff über den XMLA-Endpunkt berücksichtigt vorhandene Berechtigungen. Arbeitsbereichsadministrator*innen, -mitglieder und -mitwirkende verfügen implizit über die Semantikmodellberechtigung „Schreiben“, was bedeutet, dass sie neue Semantikmodelle aus Visual Studio bereitstellen und TMSL-Skripts (Tabular Modeling Scripting Language) in SQL Server Management Studio (SSMS) ausführen können.

Benutzer*innen mit der Semantikmodellberechtigung „Erstellen“ können den XMLA-Endpunkt verwenden, um eine Verbindung mit Semantikmodellen herzustellen und diese zur Datennutzung und -visualisierung zu durchsuchen. RLS-Regeln werden berücksichtigt, und Benutzer*innen können keine internen Semantikmodellmetadaten anzeigen.

Die Mandanteneinstellung XMLA-Endpunkte und „In Excel analysieren“ mit lokalen Semantikmodellen zulassen bezieht sich auf zwei Funktionen: Sie steuert, welche Benutzergruppen den XMLA-Endpunkt verwenden können, um Semantikmodelle im Power BI-Dienst abzufragen und/oder zu verwalten. Außerdem bestimmt sie, ob „In Excel analysieren“ mit lokalen SSAS-Modellen (SQL Server Analysis Services) verwendet werden kann.

Hinweis

Der „In Excel analysieren“-Aspekt dieser Mandanteneinstellung gilt nur für lokale SSAS-Modelle (SQL Server Analysis Services). Die Standardfunktion „In Excel analysieren“, die eine Verbindung mit einem Power BI-Semantikmodell im Power BI-Dienst herstellt, wird über die Mandanteneinstellung Liveverbindungen zulassen gesteuert.

Im Web veröffentlichen

Im Web veröffentlichen ist ein Feature, das jedem über das Internet Zugriff auf Power BI-Berichte bietet. Eine Authentifizierung ist nicht erforderlich und der Zugriff wird nicht zu Überwachungszwecken protokolliert. Da die Berichtsconsumer nicht zum Unternehmen gehören oder eine Power BI-Lizenz besitzen müssen, eignet sich diese Technik gut für den Datenjournalismus, bei dem Berichte in Blogbeiträge, Websites, E-Mails oder soziale Medien eingebettet werden.

Achtung

Bei „Im Web veröffentlichen“ beseht die Möglichkeit, dass sensible oder vertrauliche Daten verfügbar gemacht werden, unabhängig davon, ob dies versehentlich oder absichtlich geschieht. Aus diesem Grund ist dieses Feature standardmäßig deaktiviert. „Im Web veröffentlichen“ sollte nur für Berichte verwendet werden, die Daten enthalten, die von der Öffentlichkeit angezeigt werden können.

Mit der Mandanteneinstellung Im Web veröffentlichen können Power BI-Administratoren steuern, welche Gruppen Benutzender Berichte im Web veröffentlichen können. Um ein höheres Maß an Kontrolle zu erlangen, empfehlen wir, dass Sie keine anderen Gruppen in diese Mandanteneinstellung einschließen (z. B. Power BI-Administratoren oder andere Arten von Inhaltserstellenden). Erzwingen Sie stattdessen spezifischen Benutzendenzugriff mithilfe einer Sicherheitsgruppe wie Power BI – öffentliches Veröffentlichen. Stellen Sie sicher, dass die Sicherheitsgruppe gut verwaltet wird.

Einbetten in benutzerdefinierte Apps

Mit der Mandanteneinstellung Inhalt in Apps einbetten können Power BI-Administratoren steuern, welche Benutzenden Power BI-Inhalte außerhalb des Power BI-Diensts einbetten können. Wenn Sie Power BI-Inhalte in benutzerdefinierte Anwendungen einbetten möchten, aktivieren Sie diese Einstellung für bestimmte Gruppen, z. B. App-Entwickelnde.

Einbetten in PowerPoint

Mit der Mandanteneinstellung Power BI-Add-In für PowerPoint aktivieren können Power BI-Administratoren steuern, welche Benutzenden Power BI-Berichtsseiten in PowerPoint-Präsentationen einbetten können. Aktivieren Sie diese Einstellung ggf. für bestimmte Gruppen, z. B. Berichtserstellende.

Hinweis

Damit diese Funktion funktioniert, müssen Benutzende das Power BI-Add-In für PowerPoint installieren. Um das Add-In zu verwenden, müssen Benutzende entweder Zugriff auf den Office-Add-In-Store haben, oder das Add-In muss ihnen als von einem Administrator verwaltetes Add-In zur Verfügung gestellt werden. Weitere Informationen finden Sie unter Power BI-Add-In für PowerPoint.

Schulen Sie Berichtserstellende dahingehend, vorsichtig zu sein, wo sie ihre PowerPoint-Präsentationen speichern und mit wem sie sie teilen. Der Grund hierfür ist, dass Benutzenden beim Öffnen der Präsentation ein Bild der Power BI-Berichtsvisuals angezeigt wird. Dieses Bild wird zu dem Zeitpunkt erfasst, als die PowerPoint-Datei zum letzten Mal verbunden war. Das Bild kann jedoch versehentlich Daten offenbaren, für deren Anzeige der empfangende Benutzende keine Berechtigung besitzt.

Hinweis

Das Bild kann nützlich sein, wenn empfangende Benutzende noch nicht über das Add-In verfügen, oder bis das Add-In eine Verbindung mit dem Power BI-Dienst zum Abrufen von Daten herstellt. Sobald der Benutzende eine Verbindung hergestellt hat, werden aus Power BI nur Daten abgerufen, für deren Anzeige der Benutzer berechtigt ist (wobei RLS erzwungen wird).

Vorlagen-Apps

Mit Vorlagen-Apps können Power BI-Partner und Softwareanbietende Power BI-Apps ohne oder mit nur wenig Code erstellen und der Power BI-Kundschaft bereitstellen.

Mit der Mandanteneinstellung Vorlagen-Apps veröffentlichen können Power BI-Administratoren steuern, welche Benutzenden Vorlagen-Apps außerhalb der Organisation veröffentlichen können, z. B. über Microsoft AppSource. Für die meisten Organisationen sollte diese Mandanteneinstellung deaktiviert oder streng kontrolliert werden. Erwägen Sie die Verwendung einer Sicherheitsgruppe, z. B Power BI – Externe Vorlagen-App-Erstellende.

E-Mail-Abonnements

Sie können Power BI-Berichte, Dashboards und paginierte Berichte für sich selbst und andere abonnieren. Power BI sendet dann eine E-Mail nach einem von Ihnen festgelegten Zeitplan. Die E-Mail enthält eine Momentaufnahme und einen Link zum Bericht oder Dashboard.

Sie können ein Abonnement erstellen, das andere Benutzende umfasst, wenn Sie Arbeitsbereichsadministrator, -mitglied oder -mitwirkender sind. Wenn sich der Bericht in einem Premium-Arbeitsbereich befindet, können Sie für Gruppen (unabhängig davon, ob sie sich in Ihrer Domäne befinden oder nicht) und externe Benutzer abonnieren. Beim Einrichten des Abonnements gibt es auch die Option, dem Element Berechtigungen zu erteilen. Zu diesem Zweck werden Direktzugriffsberechtigungen pro Element verwendet, die im Artikel Planung der Sicherheit für Berichtsconsumer beschrieben werden.

Achtung

Beim Feature „E-Mail-Abonnement“ besteht die Möglichkeit, Inhalte für interne und externe Zielgruppen freizugeben. Wenn RLS für das zugrunde liegende Semantikmodell erzwungen wird, werden außerdem Anlagen und Bilder unter Verwendung des Sicherheitskontexts des abonnierenden Benutzers bzw. der abonnierenden Benutzerin generiert.

Mit der Mandanteneinstellung E-Mail-Abonnements können Power BI-Administratoren steuern, ob dieses Feature für die gesamte Organisation aktiviert oder deaktiviert ist.

Es gibt einige Beschränkungen hinsichtlich Anlagen im Zusammenhang mit Einschränkungen von Lizenzierungs- und Mandanteneinstellungen. Weitere Informationen finden Sie unter E-Mail-Abonnements für Berichte und Dashboards im Power BI-Dienst.

Checkliste: Die Planung der Veröffentlichung von Inhalten umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für eine Strategie, wo Inhalte wie und von wem veröffentlicht werden sollen: Bestimmen Sie, welche Präferenzen und Anforderungen für die Orte zur Veröffentlichung von Inhalten bestehen.
• Überprüfen des Arbeitsbereichszugriffs: Bestätigen Sie den Arbeitsbereichsentwurf. Überprüfen Sie, wie Sie die Arbeitsbereichszugriffsrollen verwenden, um Ihre Strategie für die Orte zur Veröffentlichung von Inhalten zu unterstützen.
• Bestimmen, wie die Berechtigungen der Bereitstellungspipeline behandelt werden: Entscheiden Sie, welche Benutzenden Inhalte mithilfe einer Bereitstellungspipeline veröffentlichen dürfen. Legen Sie die Berechtigungen der Bereitstellungspipeline entsprechend fest. Stellen Sie sicher, dass ebenfalls der Arbeitsbereichszugriff bereitgestellt wird.
• Entscheiden, wer mithilfe des XMLA-Endpunkts eine Verbindung mit Semantikmodellen herstellen kann: Entscheiden Sie, welche Benutzer*innen Semantikmodelle mithilfe des XMLA-Endpunkts abfragen oder verwalten dürfen. Legen Sie die Mandanteneinstellung XMLA-Endpunkte und „In Excel analysieren“ mit lokalen Semantikmodellen zulassen entsprechend dieser Entscheidung fest. Wenn Sie sich entschließen, diese Funktion einzuschränken, erwägen Sie die Verwendung einer Gruppe wie Genehmigte Power BI-Inhaltserstellende.
• Entscheiden, wer Berichte öffentlich veröffentlichen darf: Entscheiden Sie, welche Benutzende Power BI-Berichte öffentlich veröffentlichen dürfen, falls vorhanden. Legen Sie die Mandanteneinstellung Im Web veröffentlichen entsprechend dieser Entscheidung fest. Verwenden Sie eine Gruppe wie Power BI – öffentliches Veröffentlichen.
• Entscheiden, wer Inhalte in benutzerdefinierte Apps einbetten darf: Bestimmen Sie, wer Inhalte außerhalb des Power BI-Diensts einbetten darf. Legen Sie die Mandanteneinstellung Inhalte in Apps einbetten entsprechend dieser Entscheidung fest.
• Entscheiden, wer Inhalte in benutzerdefinierte Apps einbetten darf: Bestimmen Sie, wer Inhalte in PowerPoint einbetten darf. Legen Sie die Mandanteneinstellung Power BI-Add-In für PowerPoint aktivieren entsprechend dieser Entscheidung fest.
• Entscheiden, wer Vorlagen-Apps veröffentlichen darf: Bestimmen Sie, wie Ihre Strategie für die Verwendung von Vorlagen-Apps außerhalb der Organisation aussieht. Legen Sie die Mandanteneinstellung Vorlagen-Apps veröffentlichen entsprechend dieser Entscheidung fest.
• Entscheiden, ob Abonnements aktiviert werden sollen: Bestätigen Sie, welche Strategie Sie für die Verwendung von Abonnements verfolgen. Legen Sie die Mandanteneinstellung E-Mail-Abonnements entsprechend dieser Entscheidung fest.

Daten aktualisieren

Nach der Veröffentlichung müssen Datenerstellende sicherstellen, dass ihre Semantikmodelle und Dataflows (die importierte Daten enthalten) regelmäßig aktualisiert werden. Sie sollten sich auch für geeignete Strategien für die Semantikmodell- und Dataflowbesitzer*innen entscheiden.

Semantikmodellbesitzer*innen

Jedes Semantikmodell hat einen Besitzer bzw. eine Besitzerin in Form eines einzelnen Benutzerkontos. Semantikmodellbesitzer*innen müssen die Semantikmodellaktualisierung einrichten und Semantikmodellparameter festlegen.

Standardmäßig erhalten Semantikmodellbesitzer*innen auch Zugriffsanforderungen von Berichtserstellenden, die die Berechtigung „Erstellen“ benötigen (es sei denn, die Zugriffsanforderungseinstellungen für das Semantikmodell sind so festgelegt, dass benutzerdefinierte Anweisungen bereitgestellt werden). Weitere Informationen finden Sie in diesem Artikel im Abschnitt Workflow zur Anforderung des Zugriffs für Erstellende.

Es gibt zwei Möglichkeiten, wie Power BI Anmeldeinformationen zum Aktualisieren eines Semantikmodells abrufen kann.

• Semantikmodellbesitzer*innen speichern Anmeldeinformationen in den Semantikmodelleinstellungen.
• Semantikmodellbesitzer*innen verweisen in den Semantikmodelleinstellungen auf ein Gateway (das eine Datenquelle mit gespeicherten Anmeldeinformationen enthält).

Wenn andere Benutzer*innen Aktualisierungs- oder Semantikmodellparameter einrichten müssen, müssen sie den Besitz des Semantikmodells übernehmen. Der Semantikmodellbesitz kann von Arbeitsbereichsadministrator*innen, -mitgliedern oder -mitwirkenden übernommen werden.

Achtung

Durch die dauerhafte Übernahme des Semantikmodellbesitzes werden alle gespeicherten Anmeldeinformationen für das Semantikmodell entfernt. Anmeldeinformationen müssen erneut eingegeben werden, damit Datenaktualisierungsvorgänge fortgesetzt werden können.

Im Idealfall ist der Semantikmodellbesitzer bzw. die Semantikmodellbesitzerin der Benutzer bzw. die Benutzerin, der bzw. die für das Semantikmodell verantwortlich ist. Semantikmodellbesitzer*innen müssen aktualisiert werden, wenn sie die Organisation verlassen oder sich ihre Rolle ändert. Beachten Sie außerdem, dass die Datenaktualisierung automatisch deaktiviert wird, wenn das Benutzerkonto des semantischen Modells in der Microsoft Entra-ID deaktiviert ist. In diesem Fall muss ein anderer Benutzer bzw. eine andere Benutzerin den Besitz des Semantikmodells übernehmen, damit Datenaktualisierungsvorgänge fortgesetzt werden können.

Dataflowbesitzer

Genau wie Semantikmodelle haben auch Dataflows einen Besitzer bzw. eine Besitzerin in Form eines einzelnen Benutzerkontos. Die Informationen und Anleitungen, die im vorherigen Thema zu Semantikmodellbesitzer*innen bereitgestellt wurden, gelten auch für Dataflowbesitzer*innen.

Checkliste: Die Planung der Sicherheit im Zusammenhang mit Datenaktualisierungsprozessen umfasst folgende wichtige Entscheidungen und Aktionen:

• Entscheiden für eine Strategie für Semantikmodellbesitzer*innen: Bestimmen Sie, welche Präferenzen und Anforderungen für die Verwaltung von Semantikmodellbesitzer*innen vorhanden sind.
• Entscheiden für eine Strategie für Dataflowbesitzende: Bestimmen Sie, welche Präferenzen und Anforderungen für die Verwaltung von Dataflowbesitzenden vorhanden sind.
• In Dokumentation und Schulung für Erstellende von Semantikmodellen einschließen: Nehmen Sie für Ihre Erstellenden von Semantikmodellen eine Anleitung dazu auf, wie Besitzer*innen für den jeweiligen Elementtyp verwaltet werden sollen.

Zugehöriger Inhalt

Andere Überlegungen, Aktionen, Entscheidungskriterien und Empfehlungen für Power BI-Implementierungsentscheidungen finden Sie in den jeweils zu berücksichtigenden Themenbereichen.