Power BI implementation planning: Report consumer security planning (Power BI-Implementierungsplanung: Bericht zur Planung der Consumersicherheit)

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.

Dieser Artikel zur Sicherheitsplanung beschreibt Strategien für Consumers mit nur Leseberechtigung. Der Fokus liegt auf den Berechtigungen „Viewer“ für Berichte und Apps sowie auf der Erzwingung der Datensicherheit. 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-Administrator*innen, Informationssicherheitsteams und anderen relevanten Teams zusammenarbeiten.
• Inhaltsersteller und Inhaltsbesitzer: Self-Service-BI-Ersteller, die Inhalte erstellen, veröffentlichen, schützen und verwalten müssen, die von anderen Benutzern 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 werden viele Benutzer als Consumer klassifiziert. Consumer sehen sich Inhalte an, die andere Benutzer erstellt und veröffentlicht haben. Consumer stehen im Mittelpunkt dieses Artikels. Informationen zur Sicherheitsplanung, die sich auf Inhaltsersteller und Inhaltsbesitzer konzentriert, finden Sie im Artikel Sicherheitsplanung für Inhaltsersteller .

Um diesen Artikel optimal nutzen zu können, ist es hilfreich, die Bedeutung der Begriffe Freigabe und Verteilung im Kontext von Power BI zu verstehen.

Freigabe ist der Vorgang, wenn ein Benutzer einem anderen Benutzer (oder einer Gruppe von Benutzern) Zugriff auf einen bestimmten Inhalt gewährt. Die Freigabefunktionalität im Power BI-Dienst ist auf ein Element beschränkt. Sie erfolgt am häufigsten zwischen Personen, die sich kennen und eng zusammenarbeiten.

Verteilung ist der Vorgang, wenn Inhalte an andere Benutzer übermittelt werden, die als Empfänger bezeichnet werden. Sie umfasst häufig eine größere Anzahl von Benutzern in mehreren Teams. Empfänger*innen haben den Inhalt möglicherweise nicht explizit angefordert, jedoch wird anerkannt, dass sie ihn benötigen, um ihre Rollen zu erfüllen. Empfänger*innen, die verteilte Inhalte nutzen, kennen die ursprünglichen Ersteller*innen des Inhalts möglicherweise nicht. Daher ist die Verteilung als Konzept formaler als die Freigabe.

Wenn Sie mit anderen Personen sprechen, stellen Sie fest, ob sie den Begriff Freigabe allgemein oder wörtlich verwenden. Die Verwendung des Begriffs Freigabe kann auf zwei Arten interpretiert werden.

• Der Begriff Freigabe wird oft allgemein für den Austausch von Inhalten mit Kollegen verwendet. Es gibt mehrere Techniken zum Bereitstellen schreibgeschützter Inhalte, die in diesem Artikel beschrieben werden.
• Freigabe ist auch ein bestimmtes Feature in Power BI. Es handelt sich um eine Funktion, bei der einem Benutzer oder einer Gruppe Zugriff auf ein einzelnes Element gewährt wird. Freigabelinks und die Freigabe über Direktzugriff werden in diesem Artikel beschrieben.

Wichtig

Die Power BI-Administratorrolle wurde umbenannt. Der neue Name der Rolle lautet Fabric-Administrator.

Strategie für Consumer mit nur Leseberechtigung

Im Power BI-Dienst können Consumer einen Bericht oder eine Dashboard anzeigen, wenn sie über die Berechtigung für beides verfügen:

• Anzeigen des Power BI-Elements, das die Visualisierungen enthält (z. B. einen Bericht oder Dashboard).
• Lesen sie die zugrunde liegenden Daten (Semantikmodell oder andere Quelle).

Sie können Consumern Nur-Lesen-Zugriff gewähren, indem Sie verschiedene Techniken verwenden. Zu den gängigen Techniken, die von Self-Service-Inhaltserstellern verwendet werden, gehören:

• Gewähren des Zugriffs auf eine Power BI-App für Benutzer und Gruppen.
• Hinzufügen von Benutzern und Gruppen zu einer Power BI-Arbeitsbereichsrolle „Viewer“.
• Bereitstellen von Berechtigungen pro Element für Benutzer und Gruppen mithilfe eines Freigabelinks.
• Bereitstellen von Berechtigungen pro Element für Benutzer und Gruppen mithilfe von Direktzugriff.

Die Optionen für die Rolle „Viewer“ für die Power BI-App und den Power BI-Arbeitsbereich umfassen die Verwaltung von Berechtigungen für eine Reihe von Elementen. Die beiden Techniken für Berechtigungen pro Element umfassen die Verwaltung von Berechtigungen für ein einzelnes Element.

Tipp

Ganz allgemein ist es eine bewährte Methode, eine Power BI-App für die meisten Verbraucher zu verwenden. Gelegentlich könnte außerdem die Arbeitsbereichsrolle „Viewer“ geeignet sein. Die Rolle „Viewer“ für Power BI-Apps wie auch den Arbeitsbereich ermöglicht die Verwaltung von Berechtigungen für viele Elemente und sollte wann immer möglich verwendet werden. Die Verwaltung von Berechtigungen für einzelne Elemente kann mühsam, zeitaufwendig und fehleranfällig sein. Im Gegensatz dazu reduziert die Verwaltung einer Gruppe von Elementen den Wartungsaufwand und verbessert die Genauigkeit.

Beim Überprüfen der Sicherheitseinstellungen für ein Element könnten dessen Berechtigungen folgendermaßen angezeigt werden:

• Geerbt vom Arbeitsbereich oder einer App.
• Direkt auf das Element angewendet.

Im folgenden Screenshot werden die Berechtigungen für den Direktzugriff für einen Bericht angezeigt. In diesem Fall werden die Arbeitsbereichsrollen „Administrator“ und „Mitglied“ jeweils einer Gruppe zugewiesen. Diese Rollen werden für den Bericht angezeigt, da der Zugriff auf Berichtsebene vom Arbeitsbereich geerbt wird. Es gibt auch einen Benutzer, der über die Berechtigung „Lesen“ verfügt, die direkt auf den Bericht angewendet wurden.

Die Strategie, die Sie für schreibgeschützte Consumer auswählen, kann unterschiedlich sein. Sie sollte auf der individuellen Lösung, den Präferenzen der Personen, welche die Lösung verwalten, oder den Anforderungen des Consumers basieren. Im weiteren Verlauf dieses Abschnitts wird beschrieben, wann sie die einzelnen verfügbaren Techniken verwenden sollten.

Prüfliste – Beim Erstellen Ihrer Strategie für die Bereitstellung von Inhalten für Consumer mit nur Leseberechtigung sind folgende wichtigen Entscheidungen und Aktionen zu berücksichtigen:

• Bewerten Ihrer vorhandenen Strategie für Consumer mit nur Leseberechtigung: Überprüfen Sie, wie Inhalte derzeit verteilt und für Consumer freigegeben werden. Ermitteln Sie, ob Verbesserungsmöglichkeiten vorhanden sind.
• Festlegen Ihrer Strategie für Consumers mit nur Leseberechtigung: Überlegen Sie, welche Präferenzen Sie für die Verwendung von App-Berechtigungen, Arbeitsbereichsrollen oder Berechtigungen pro Element haben. Wenn Änderungen erforderlich sind, um diese Präferenzen zu erfüllen, erstellen Sie einen Plan für Verbesserungen.

Berechtigungen für Power BI-Apps

Eine Power BI-App stellt eine Sammlung von Berichten, Dashboards und Arbeitsmappen für Consumer bereit. Eine App bietet für Consumer die beste Benutzererfahrung aus folgenden Gründen:

• Der Navigationsbereich der App bietet eine einfache und intuitive Benutzererfahrung. Es ist eine schöneres Erlebnis als der direkte Zugriff auf Inhalte in einem Arbeitsbereich.
• Inhalte können im Navigationsbereich der App logisch in Abschnitte (normalerweise Ordner) organisiert werden.
• Consumer haben nur Zugriff auf bestimmte Elemente, die explizit für ihre Zielgruppe in die App aufgenommen wurden.
• Links zu zusätzlichen Informationen, Dokumentationen oder anderen Inhalten können dem Navigationsbereich für ihre Zielgruppe hinzugefügt werden.
• Es gibt einen integrierten Workflow zum Anfordern des Zugriffs .

Hinweis

Alle Verweise auf eine App in diesem Artikel beziehen sich auf eine Power BI-App. Dies ist ein anderes Konzept als Power Apps. Es ist auch ein anderes Konzept als die mobilen Power BI-Anwendungen. In diesem Abschnitt liegt der Schwerpunkt auf organisatorischen Apps und nicht auf Vorlagen-Apps.

Sie können eine App für jeden Arbeitsbereich erstellen, um einige oder alle Arbeitsbereichsinhalte auf formale Art und Weise zu verteilen. Apps sind eine gute Möglichkeit, Inhalte innerhalb einer Organisation breit zu verteilen, insbesondere an Benutzer, die Sie nicht kennen oder mit denen Sie nicht eng zusammenarbeiten.

Tipp

Weitere Informationen zur Verwendung einer Power BI-App für eine breite Inhaltsverteilung finden Sie unter Nutzungsszenarien für Unternehmens-BI. Wir empfehlen, dass Inhaltsersteller, die Inhalte verteilen müssen, die Erstellung einer App als erste Wahl in Betracht ziehen.

Sie verwalten App-Berechtigungen getrennt von Arbeitsbereichsrollen. Die Trennung von Berechtigungen hat zwei Vorteile. Sie fördert Folgendes:

• Gewähren von Arbeitsbereichszugriff für Inhaltsersteller. Dies beinhaltet Benutzer*innen, die aktiv an den Inhalten zusammenarbeiten, z. B. Semantikmodellersteller*innen, Berichtsersteller*innen und Tester*innen.
• Erteilen von App-Berechtigungen für Consumer. Im Gegensatz zu Arbeitsbereichsberechtigungen sind App-Berechtigungen immer Nur-Lesen (oder keine).

Alle Benutzer*innen mit Arbeitsbereichszugriff können die App automatisch anzeigen, sofern eine Power BI-App für den Arbeitsbereich veröffentlicht wurde. Aufgrund dieses Verhaltens können Sie sich Arbeitsbereichsrollen konzeptionell so vorstellen, dass sie von jeder App-Zielgruppe geerbt werden. Einige Benutzer*innen mit Arbeitsbereichszugriff können abhängig von ihrer zugewiesenen Arbeitsbereichsrolle zudem die Power BI-App aktualisieren.

Tipp

Weitere Informationen zum Arbeitsbereichszugriff finden Sie im Artikel Sicherheitsplanung für Inhaltsersteller.

Die Verwendung einer App zum Verteilen von Inhalten an Consumer mit nur Leseberechtigung ist die beste Wahl, wenn:

• Sie möchten, dass Benutzer nur bestimmte Elemente anzeigen können, die für diese Zielgruppe sichtbar sind (und nicht alle Elemente im zugrunde liegenden Arbeitsbereich).
• Sie möchten Nur-Lesen-Berechtigungen für die App separat vom Arbeitsbereich verwalten.
• Sie möchten eine einfachere Berechtigungsverwaltung für Benutzer mit nur Leseberechtigung haben als Berechtigungen pro Element.
• Sie möchten sicherstellen, dass die Sicherheit auf Zeilenebene für Nutzer*innen erzwungen wird (wenn diese über eine Nur-Lesen-Berechtigung für das zugrunde liegende Semantikmodell verfügen).
• Sie möchten sicherstellen, dass Consumer neue und geänderte Berichte erst anzeigen können, wenn die App neu veröffentlicht wird.

Es stimmt zwar, dass Änderungen an Berichten und Dashboards für Benutzer der App erst sichtbar sind, wenn die App neu veröffentlicht wird, aber es gibt zwei Überlegungen, die Vorsicht erfordern.

• Sofortige Semantikmodelländerungen: Semantikmodelländerungen werden immer sofort wirksam. Wenn Sie beispielsweise Breaking Changes an einem Semantikmodell im Arbeitsbereich vornehmen, kann dies unbeabsichtigt zu instabilen Berichten führen (obwohl sie in der App nicht neu veröffentlicht wurden). Es gibt zwei Möglichkeiten, dieses Risiko zu minimieren: Führen Sie erstens die gesamte Entwicklungsarbeit in Power BI Desktop durch (getrennt vom Arbeitsbereich). Isolieren Sie zweitens die Produktions-App, indem Sie separate Arbeitsbereiche für Entwicklung und Test verwenden. (Optional können Sie mithilfe von Bereitstellungspipelines ein höheres Maß an Kontrolle über die Bereitstellung von Arbeitsbereichsinhalten von der Entwicklung über den Test bis hin zur Produktion erreichen.)
• Inhalte und Berechtigungen werden zusammen veröffentlicht: Wenn Sie eine App veröffentlichen, werden ihre Berechtigungen gleichzeitig mit dem Inhalt veröffentlicht. Beispiel: Möglicherweise gibt es Berichtsänderungen in einem Arbeitsbereich, die noch nicht abgeschlossen, vollständig getestet oder genehmigt sind. Sie können die App also nicht nur zum Zweck der Aktualisierung der Berechtigungen neu veröffentlichen. Um dieses Risiko zu minimieren, weisen Sie App-Berechtigungen an Sicherheitsgruppen zu, und verwenden Sie Sicherheitsgruppenmitgliedschaften (anstelle einzelner Benutzer) beim Erteilen von App-Berechtigungen. Vermeiden Sie die Neuveröffentlichung einer App, nur um Berechtigungsänderungen anzuwenden.

App-Zielgruppe

Jeder Arbeitsbereich im Power BI-Dienst kann nur über eine Power BI-App verfügen. Innerhalb der App können Sie jedoch eine oder mehrere Zielgruppen erstellen. Stellen Sie sich folgendes Szenario vor:

• Sie verfügen über fünf Verkaufsberichte, die an viele Benutzer in Ihrer globalen Verkaufsorganisation verteilt werden.
• Eine Zielgruppe wird in der App für die Vertriebsmitarbeiter definiert. Diese Zielgruppe kann drei der fünf Berichte anzeigen.
• Eine weitere Zielgruppe wird in der App für das Vertriebsleitungsteam definiert. Diese Zielgruppe kann alle fünf Berichte anzeigen, einschließlich der beiden Berichte, die für Vertriebsmitarbeiter nicht verfügbar sind.

Diese Funktion zum Mischen und Abgleichen von Inhalten und Zielgruppen hat die folgenden Vorteile.

• Bestimmte Berichte können von mehreren Zielgruppen angezeigt werden. Durch das Erstellen mehrerer Zielgruppen entfällt die Notwendigkeit, Inhalte in verschiedene Arbeitsbereichen zu duplizieren.
• Bestimmte Berichte sollten lediglich für eine Zielgruppe verfügbar sein. Inhalte für diese eine Zielgruppe können sich also im gleichen Arbeitsbereich befinden wie andere verwandte Inhalte.

Der folgende Screenshot zeigt eine App mit zwei Zielgruppen: Vertriebsleitung und Vertriebsmitarbeiter. Der Bereich Zielgruppenzugriff verwalten bietet Zugriff auf die Zielgruppe Vertriebsleitung für zwei Sicherheitsgruppen: Vertriebsleitung – USA und Vertriebsleitung – Europa. Der Bericht Analyse der Bruttomarge, der im Screenshot für die Zielgruppengruppe Vertriebsleitung gezeigt wird, ist für die Zielgruppengruppe Vertriebsmitarbeiter nicht verfügbar.

Hinweis

Manchmal wird der Begriff Publikumsgruppe verwendet. Dies ist kein direkter Verweis auf die Verwendung von Sicherheitsgruppen. Sie umfasst die Mitglieder der Zielgruppe, welche die Sammlung von Inhalten in einer Power BI-App sehen werden. Obwohl Sie einzelne Benutzer einer Zielgruppe zuweisen können, empfiehlt es sich, Sicherheitsgruppen, Microsoft 365-Gruppen oder Verteilergruppen zuzuweisen, wann immer dies möglich ist. Weitere Informationen finden Sie in der Strategie für die Verwendung von Gruppen im Artikel Sicherheitsplanung auf Mandantenebene.

Wenn Sie Berechtigungen für eine App verwalten, können Sie auf der Seite Direktzugriff die Mitglieder jeder Zielgruppe anzeigen. Sie können auch Benutzer mit einer Arbeitsbereichsrolle unter der Zielgruppe Alle sehen. Sie können die App-Berechtigungen nicht über die Seite Direktzugriff aktualisieren. Stattdessen müssen Sie die App neu veröffentlichen. Sie können App-Berechtigungen jedoch auf der Seite Ausstehend aktualisieren, wenn offene Zugriffsanforderungen für die App vorhanden sind.

Tipp

Der primäre Anwendungsfall für die Verwendung von App-Zielgruppen besteht darin, bestimmte Berechtigungen für verschiedene Gruppen von Benutzern zu definieren. Sie können jedoch ein wenig kreativ werden, wenn Sie Zielgruppen verwenden. Ein Benutzer kann Mitglied mehrerer Zielgruppen sein, und jede Zielgruppe wird den Viewern in der App als sekundärer Menüsatz angezeigt. Sie können beispielsweise eine Zielgruppe mit dem Namen Hier beginnen erstellen, die Informationen zur Verwendung der App, zur Kontaktperson, zur Bereitstellung von Feedback und zum Erhalten von Hilfe enthält. Oder Sie können eine Zielgruppe mit dem Namen KPI-Definitionen erstellen, die ein Datenwörterbuch enthält. Die Bereitstellung dieser Art von Informationen hilft neuen Benutzern und verbessert die Akzeptanz der Lösung.

App-Berechtigungsoptionen

Wenn Sie eine App erstellen (oder neu veröffentlichen), verfügt jede Zielgruppe über einen Bereich Zielgruppenzugriff verwalten . In diesem Bereich sind die folgenden Berechtigungen verfügbar.

• Zugriff gewähren auf: Für jede Zielgruppe können Sie einzelnen Benutzern und Gruppen Zugriff gewähren. Es ist möglich, die App in der gesamten Organisation zu veröffentlichen, wenn die Mandanteneinstellung Veröffentlichen von Apps für die gesamte Organisation aktiviert ist und die App nicht automatisch installiert wird. Wir empfehlen, Zielgruppen nach Möglichkeit Gruppen zuzuweisen, da das Hinzufügen oder Entfernen von Benutzern eine erneute Veröffentlichung der App erfordert. Jeder Benutzer mit Arbeitsbereichszugriff verfügt automatisch über die Berechtigung, die App je nach seiner Arbeitsbereichsrolle anzuzeigen oder zu aktualisieren.
• Semantikmodellberechtigungen: Zwei Arten von Semantikmodellberechtigungen können beim Veröffentlichen einer App gewährt werden:
  • Semantikmodellberechtigung „Erneut freigeben“: Wenn diese Berechtigung aktiviert ist, erhalten App-Benutzer*innen die Berechtigung zum erneuten Freigeben der zugrunde liegenden Semantikmodelle für andere Personen. Es ist sinnvoll, diese Option zu aktivieren, wenn die zugrunde liegenden Semantikmodelle problemlos für beliebige Personen erneut freigegeben werden können. Wir empfehlen, die Genehmigung der Semantikmodellbesitzer*innen einzuholen, bevor Sie einer App-Zielgruppe die Berechtigung „Erneut freigeben“ erteilen.
  • Semantikmodellberechtigung „Erstellen“: Wenn diese Berechtigung aktiviert ist, erhalten App-Benutzer*innen die Berechtigung „Erstellen“ für die Semantikmodelle. Mithilfe der Berechtigung „Build“ können Benutzer neue Berichte erstellen, zugrunde liegende Daten aus Berichten exportieren und vieles mehr. Wir empfehlen, die Genehmigung der Semantikmodellbesitzer*innen einzuholen, bevor Sie einer App-Zielgruppe die Berechtigung „Erstellen“ erteilen.

Es ist praktisch, beim Veröffentlichen einer App die Semantikmodellberechtigung „Erneut freigeben“ oder „Erstellen“ hinzufügen zu können. Es empfiehlt sich allerdings, App-Berechtigungen und Semantikmodellberechtigungen separat zu verwalten. Hier sind die Gründe dafür.

• Das freigegebene Semantikmodell kann sich in einem separaten Arbeitsbereich befinden: Wenn das Semantikmodell in einem von der App getrennten Arbeitsbereich veröffentlicht wird, müssen seine Berechtigungen direkt verwaltet werden. Das Hinzufügen der Berechtigung „Lesen“, „Erstellen“ oder „Erneut freigeben“ beim Veröffentlichen einer App funktioniert nur für Semantikmodelle, die sich im gleichen Arbeitsbereich befinden wie die App. Aus diesem Grund sollten Sie sich anzugewöhnen, Semantikmodellberechtigungen unabhängig zu verwalten.
• Semantikmodellberechtigungen werden separat verwaltet: Wenn Sie Berechtigungen für eine App entfernen oder ändern, wirkt sich diese Aktion nur auf die App aus. Zuvor zugewiesene Semantikmodellberechtigungen werden nicht automatisch entfernt. App-Berechtigungen und Semantikmodellberechtigungen sind somit voneinander entkoppelt. Sie müssen das Semantikmodell direkt (also getrennt von der App) verwalten, wenn Semantikmodellberechtigungen geändert werden oder entfernt werden müssen.
• Semantikmodellberechtigungen sollten kontrolliert werden: Durch das Erteilen von Semantikmodellberechtigungen über eine App wird dem Besitzer bzw. der Besitzerin des Semantikmodells die Kontrolle entzogen. Die Erteilung der Berechtigung „Erneut freigeben“ liegt im Ermessen von Benutzer*innen, die sich für die erneute Freigabe der Semantikmodelle entscheiden. Ihre internen Governance- oder Sicherheitsrichtlinien können schwieriger zu verwalten werden, wenn die erneute Freigabe zulässig ist.
• Consumer und Ersteller haben unterschiedliche Ziele: In der Regel gibt es in einer Organisation viel mehr Consumer als Ersteller von Inhalten. Im Einklang mit dem Prinzip der geringsten Rechte benötigen Nutzer*innen nur die Berechtigung „Lesen“ für das zugrunde liegende Semantikmodell. Sie benötigen keine Berechtigung „Build“, es sei denn, sie beabsichtigen, neue Berichte zu erstellen.

Tipp

Weitere Informationen dazu, wann separate Datenarbeitsbereiche und Berichtsarbeitsbereiche verwendet werden sollen, finden Sie im Artikel Planung auf Arbeitsbereichsebene .

Rechte für die Vorinstallation von Apps

Nachdem Sie eine Power BI-App veröffentlicht haben, muss ein Benutzer sie in der Regel installieren, damit sie geöffnet werden kann. Ein Benutzer kann eine App über die Seite „Apps“ im Power BI-Dienst oder über einen Link installieren, den er von einem anderen Benutzer erhalten hat. Benutzer können eine App finden (und installieren), wenn sie in mindestens einer Zielgruppe der App enthalten sind.

Ein alternativer Ansatz besteht darin, eine App per Push für App-Consumer zu installieren. Dies führt zur Vorinstallation der App, sodass sie automatisch auf der Seite „Apps“ im Power BI-Dienst angezeigt wird. Dieser Ansatz ist eine Vereinfachung für Verbraucher, da sie die App nicht finden und installieren müssen. Allerdings können vorinstallierte Apps für Benutzer*innen zu einem Ärgernis werden, da sie möglicherweise von zu vielen für sie nicht relevanten Apps überfordert werden.

Die Mandanteneinstellung Apps an Endbenutzer pushen steuert, wer Apps automatisch installieren darf. Wir empfehlen Ihnen, dieses Feature zu verwenden, da es für Benutzer bequem ist. Wir empfehlen Ihnen aber auch, dass Sie Ihre Inhaltsersteller darüber schulen, wann es verwendet werden soll, damit es nicht übermäßig genutzt wird.

Tipp

Wenn Sie beim Veröffentlichen einer App die Option zum automatischen Installieren der App auswählen, können Sie die Zielgruppe nicht auf die gesamte Organisation festlegen (sofern dies durch die Mandanteneinstellung Apps an Endbenutzer pushen aktiviert ist).

Prüfliste – Beim Erstellen Ihrer Strategie für die Verwendung von Apps für Inhaltsviewer sind folgende wichtigen Entscheidungen und Aktionen zu berücksichtigen:

• Entscheiden bezüglich der Strategie für die Verwendung von Apps: Definieren Sie Ihre Präferenzen für die Verwendung von Apps. Stellen Sie sicher, dass sie an Ihrer Gesamtstrategie für Consumer mit nur Leseberechtigung ausgerichtet ist.
• Entscheiden, wer Apps für die gesamte Organisation veröffentlichen kann: Entscheiden Sie, welche Berichtsersteller in der gesamten Organisation veröffentlichen können. Legen Sie die Mandanteneinstellung Veröffentlichen von Apps für die gesamte Organisation so fest, dass sie mit dieser Entscheidung übereinstimmt.
• Entscheiden, wer Apps an Endbenutzer pushen kann: Entscheiden Sie, welche Power BI-Berichtsersteller Apps vorinstallieren können. Legen Sie die Mandanteneinstellung Apps an Endbenutzer pushen so fest, dass sie mit dieser Entscheidung übereinstimmt.
• Erstellen und Veröffentlichen von Anleitungen für Inhaltsersteller: Stellen Sie Dokumentation und Training für Inhaltsersteller bereit. Schließen Sie Anforderungen und Präferenzen für die effektivste Nutzung von Apps ein.
• Bestimmen, wie App-Zugriffsanforderungen verarbeitet werden: Stellen Sie sicher, dass ein Prozess vorhanden ist, um Kontakte zuzuweisen und App-Zugriffsanforderungen zeitnah zu behandeln.

Arbeitsbereichsrolle „Viewer"

Wie in den Artikeln zur Arbeitsbereichsplanung beschrieben, ist der Hauptzweck eines Arbeitsbereichs die Zusammenarbeit. Arbeitsbereichsmitarbeiter*innen (z. B. Semantikmodellersteller*innen, Berichtsersteller*innen und Tester*innen) sollten einer von drei Rollen zugewiesen werden: „Mitwirkender“, „Mitglied“ oder „Administrator“. Diese Rollen werden im Artikel zur Sicherheitsplanung für Inhaltsersteller*innen beschrieben.

Sie können Consumern die Arbeitsbereichsrolle „Viewer“ zuweisen. Für kleine Teams und informelle Teams, die eng zusammenarbeiten, kann es sinnvoll sein, den Benutzern den Zugriff auf Inhalte direkt in einem Arbeitsbereich zu ermöglichen.

Consumern den direkten Zugriff auf Inhalte im Arbeitsbereich zu ermöglichen, ist eine gute Wahl, wenn Folgendes gilt:

• Die Formalität einer App mit ihren separaten Berechtigungen ist nicht erforderlich.
• Viewer haben die Berechtigung, alle im Arbeitsbereich gespeicherten Elemente anzuzeigen.
• Sie möchten eine einfachere Berechtigungsverwaltung als Berechtigungen pro Element.
• Arbeitsbereichsbenutzer*innen könnten eine App ebenfalls anzeigen, sofern eine App für den Arbeitsbereich veröffentlicht wurde.
• Das Ziel ist, dass Viewer Inhalte prüfen, bevor sie in einer App veröffentlicht werden.

Hier sind einige Vorschläge zur Unterstützung für Viewer im Arbeitsbereich.

• Organisieren Sie Inhalte in jedem Arbeitsbereich, sodass die Elemente von Berichtsconsumern leicht gefunden werden können und dass sie gut mit der Sicherheit übereinstimmen. Die Organisation der Arbeitsbereiche nach Themenbereich oder Projekt funktioniert in der Regel gut.
• Trennen Sie Entwicklungs- und Testinhalte von Produktionsinhalten, sodass Viewer nicht auf Elemente in Bearbeitung zugreifen können.
• Verwenden Sie Apps (oder allenfalls Berechtigungen pro Element), wenn Sie erwarten, dass viele Zugriffsanforderungen verarbeitet werden müssen. Es gibt keinen Workflow für die Anforderung von Zugriff für Arbeitsbereiche.

Prüfliste – Beim Erstellen Ihrer Strategie für die Verwendung von Arbeitsbereichen für Inhaltsviewer sind folgende wichtigen Entscheidungen und Aktionen zu berücksichtigen:

• Entscheiden bezüglich einer Strategie für die Verwendung der Arbeitsbereichsrolle „Viewer“: Definieren Sie, welche Präferenzen Sie für die Verwendung von Arbeitsbereichen für Consumer haben. Stellen Sie sicher, dass sie an Ihrer Gesamtstrategie für Consumer mit nur Leseberechtigung ausgerichtet ist.
• Erstellen und Veröffentlichen von Anleitungen für Inhaltsersteller: Stellen Sie Dokumentation und Training für Inhaltsersteller bereit. Schließen Sie Anforderungen und Präferenzen für die effektivste Nutzung von Arbeitsbereichsberechtigungen ein.

Berechtigungen pro Element

Die individuelle Freigabe von Elementen gewährt Berechtigungen für ein einzelnes Element. Weniger erfahrene Inhaltsersteller verwenden diese Technik in der Regel als primäre Freigabetechnik, da die Freigabebefehle im Power BI-Dienst an prominenter Stelle angezeigt werden. Aus diesem Grund ist es wichtig, Ihre Inhaltsersteller über die verschiedenen Freigabeoptionen zu schulen, einschließlich der Frage, wann App-Berechtigungen anstelle von Arbeitsbereichsrollen verwendet werden sollten.

Berechtigungen pro Element sind eine gute Wahl in folgenden Fällen:

• Sie möchten Nur-Lesen-Zugriff auf ein Element (Bericht oder Dashboard) bereitstellen.
• Sie möchten nicht, dass der Consumer alle in einem Arbeitsbereich veröffentlichten Inhalte anzeigen kann.
• Sie möchten nicht, dass der Consumer alle Inhalte anzeigen kann, die für eine App-Zielgruppe veröffentlicht wurden.

Verwenden Sie Berechtigungen pro Element sparsam, da die Freigabe einem einzelnen Element die Berechtigung „Lesen“ gewährt. In gewisser Weise können Sie sich Berechtigungen pro Element als Außerkraftsetzung von Arbeitsbereichsrollen oder App-Berechtigungen vorstellen.

Tipp

Wir empfehlen Ihnen, nach Möglichkeit immer App-Berechtigungen zu verwenden. Schauen Sie als Nächstes die Verwendung von Arbeitsbereichsrollen an, um den direkten Arbeitsbereichszugriff zu aktivieren. Verwenden Sie schlussendlich Berechtigungen pro Element, wenn sie die oben genannten Kriterien erfüllen. App-Berechtigungen und Arbeitsbereichsrollen legen beide die Sicherheit für eine Sammlung von Inhalten fest (anstelle für einzelne Elemente), was eine bessere Sicherheitspraxis ist.

Das Freigeben vieler Elemente mithilfe von Berechtigungen pro Element kann mühsam und fehleranfällig sein, insbesondere bei der Freigabe für einzelne Benutzer anstelle von Gruppen. Betrachten Sie dieses Szenario: Sie verfügen über 40 Berichte, die Sie für Kollegen mithilfe ihrer individuellen Benutzerkonten freigegeben haben. Wenn ein Kollege in eine andere Abteilung wechselt, müssen Sie den Zugriff widerrufen, was die Bearbeitung von Berechtigungen für alle 40 Berichte umfasst.

Wichtig

Die Freigabe von Inhalten aus einem persönlichen Arbeitsbereich sollte nur selten erfolgen. Persönliche Arbeitsbereiche eignen sich am besten für nicht kritische, informelle oder temporäre Inhalte. Wenn Sie eine Situation haben, in der Inhaltsersteller häufig wichtige oder kritische Inhalte aus ihren persönlichen Arbeitsbereichen freigeben, sollten Sie geeignete Maßnahmen ergreifen, um diese Inhalte in einen Standardarbeitsbereich zu verschieben. Weitere Informationen finden Sie im Nutzungsszenario zu persönlichem BI.

Wenn Sie ein einzelnes Element freigeben, haben Sie mehrere Berechtigungsoptionen.

• Berechtigung „Erneut freigeben“: Wenn diese Berechtigung aktiviert ist, können Benutzer*innen das Element für andere Benutzer*innen freigeben – einschließlich der zugrunde liegenden Semantikmodelle. Es ist sinnvoll, diese Berechtigung zu erteilen, wenn das Element ohne Weiteres für jeden freigegeben werden kann. Es entfernt die Kontrolle von der Person oder dem Team, welche das Element verwalten. Es hängt also vom guten Urteilsvermögen der Benutzer ab, denen die Berechtigung „Erneut freigeben“ erteilt wurde. Ihre internen Governance- oder Sicherheitsrichtlinien können jedoch schwieriger zu verwalten sein, wenn die erneute Freigabe zulässig ist.
• Berechtigung „Erstellen“: Wenn diese Option aktiviert ist, wird Benutzer*innen die Berechtigung „Erstellen“ für das zugrunde liegende Semantikmodell gewährt. Mit der Berechtigung „Erstellen“ können Benutzer*innen neue Inhalte erstellen, die auf dem Semantikmodell basieren. Außerdem können sie zugrunde liegende Daten aus Berichten exportieren und vieles mehr. Überlegungen zum Erteilen der Berechtigung „Build“ werden im Artikel zur Sicherheitsplanung von Inhaltsersteller beschrieben.

Berechtigungen pro Element für Berichte und Dashboards können für informelle Szenarien sinnvoll sein, wenn Inhalte für einige Benutzer freigegeben werden. Es ist eine gute Idee, Benutzer stattdessen über die Verwaltung von Berechtigungen mit Apps und Arbeitsbereichen zu schulen, insbesondere wenn sie Inhalte für eine große Anzahl von Benutzern oder Benutzer außerhalb ihres Teams freigeben. Es ist wichtig, die folgenden Punkte hervorzuheben.

• Es wird schwieriger zu ermitteln, welche Inhalte für welche Benutzer freigegeben wurden, da die Berechtigungen für jeden Bericht und jedes Dashboard einzeln überprüft werden müssen.
• In vielen Fällen wird die Berechtigung „Erneut freigeben“ festgelegt, da die Benutzererfahrung diese Option standardmäßig aktiviert. Es besteht also das Risiko, dass Inhalte für eine größere Gruppe von Benutzern freigegeben werden als beabsichtigt. Dieses Ergebnis kann verhindert werden, indem Sie die Option Empfängern erlauben, diesen Bericht freizugeben bei der Freigabe deaktivieren. Die Minimierung der Überfreigabe auf diese Weise ist eine Frage des Benutzertrainings. Der Inhaltsersteller, der die Freigabeberechtigungen festlegt, sollte diese Auswahl jedes Mal bedenken.
• Alle Änderungen an Berichten und Dashboards können von anderen sofort gesehen werden, was Benutzer*innen verwirren könnte, wenn Änderungen an Inhalten noch in Bearbeitung sind. Dieses Problem kann durch das Verteilen von Inhalten in einer App oder durch die Verwendung separater Arbeitsbereiche zum Trennen von Entwicklungs-, Test- und Produktionsinhalten entschärft werden. Weitere Informationen finden Sie unter dem Nutzungsszenario für die Self-Service-Inhaltsveröffentlichung .
• Wenn ein Benutzer Inhalte aus dem persönlichen Arbeitsbereich teilt und die Organisation verlässt, deaktiviert die IT in der Regel sein Benutzerkonto. In diesem Fall verlieren alle Empfänger der freigegebenen Inhalte sofort den Zugriff auf die Inhalte.

Es gibt drei spezifische Arten der Freigabe: Freigabelinks, Freigabe über Direktzugriff und freigegebene Ansichten.

Links zu Berechtigungen pro Element

Wenn Sie ein einzelnes Element freigeben, ist das Resultat in der Standarderfahrung ein Freigabelink. Es gibt drei Arten von Freigabelinks.

• Personen in Ihrer Organisation: Wenn dies in Ihren Power BI-Mandanteneinstellungen aktiviert ist, ist diese Art des Freigabelinks eine einfache Möglichkeit, allen Personen innerhalb der Organisation Nur-Lesen-Zugriff zu gewähren. Der Freigabelink funktioniert jedoch nicht für externe Benutzer. Diese Option eignet sich am besten, wenn jeder den Inhalt anzeigen kann und der Link innerhalb der gesamten Organisation frei geteilt werden darf. Sofern dies nicht durch die Mandanteneinstellung Freigabelinks zulassen, um allen Benutzern in Ihrer Organisation Zugriff zu gewähren deaktiviert ist, ist diese Art der Freigabe die Standardeinstellung.
• Personen mit vorhandenem Zugriff: Diese Option erstellt keinen neuen Freigabelink. Stattdessen können Sie die URL abrufen, um sie an eine Person zu senden, die bereits Zugriff hat.
• Bestimmte Personen: Diese Option erzeugt einen Freigabelink für bestimmte Benutzer oder Gruppen. Wir empfehlen Ihnen, diese Option in den meisten Fällen zu verwenden, da sie spezifischen Zugriff bietet. Wenn Sie häufig mit externen Benutzern arbeiten, können Sie diesen Linktyp für Gastbenutzer verwenden, die bereits in der Microsoft Entra-ID vorhanden sind. Weitere Informationen zum Prozess der geplanten Einladung zum Erstellen von Gastbenutzern finden Sie im Artikel Sicherheitsplanung auf Mandantenebene.

Wichtig

Wir empfehlen Ihnen, die Mandanteneinstellung Freigegebene Links zulassen, um allen Personen in Ihrer Organisation Zugriff zu gewähren auf Mitglieder einer Gruppe einzuschränken. Sie können einen Gruppennamen wie Power BI-Freigabe für die gesamte Organisation erstellen und dann eine kleine Anzahl von Benutzern hinzufügen, welche die Auswirkungen der organisationsweiten Freigabe verstehen. Wenn Sie Bedenken bezüglich vorhandenen organisationsweiten Links haben, können Sie die Administrator-API verwenden, um alle Elemente zu finden, die für die gesamte Organisation freigegeben wurden.

Ein Freigabelink fügt dem Element die Berechtigung „Lesen“ hinzu. Die Berechtigung „Erneut freigeben“ ist standardmäßig ausgewählt. Es ist auch möglich, dem zugrunde liegenden Semantikmodell die Berechtigung „Erstellen“ hinzuzufügen, wenn der Freigabelink erstellt wird.

Tipp

Wir empfehlen, Inhaltsersteller*innen dahingehend zu schulen, die Berechtigungsoption „Erstellen“ nur dann zu aktivieren, wenn die Nutzer*innen des Berichts auch Inhaltsersteller*innen sind, die möglicherweise Berichte erstellen, Daten exportieren oder ein zusammengesetztes Modell auf der Grundlage des zugrunde liegenden Semantikmodells erstellen müssen.

Freigabelinks sind einfacher zu verwalten als die Freigabe über Direktzugriff, insbesondere wenn Sie Massenänderungen vornehmen müssen. Es ist ein erheblicher Vorteil, wenn einzelnen Benutzern Freigabeberechtigungen erteilt werden, viel mehr als für Gruppen (was häufig auftritt, wenn Self-Service-Benutzer für die Verwaltung von Berechtigungen verantwortlich sind). Betrachten Sie die folgenden Vergleiche.

• Freigabelink: 20 einzelnen Benutzern wird der Zugriff mit einem Freigabelink gewährt. Eine einzige Änderung des Links wirkt sich auf alle 20 Benutzer aus.
• Direktzugriff: 20 Personen erhalten Direktzugriff auf ein Element. Um eine Änderung vorzunehmen, müssen alle 20 Benutzerberechtigungen geändert werden.

Direktzugriffsberechtigungen pro Element

Sie können auch Berechtigungen pro Element mithilfe von Direktzugriff erreichen. Direktzugriff umfasst das Einrichten der Berechtigungen für ein einzelnes Element. Sie können auch alle geerbten Berechtigungen bestimmen, die von Arbeitsbereichsrollen abgeleitet werden.

Wenn Sie einem Benutzer Direktzugriff gewähren, erhält er die Berechtigung „Lesen“ für das Element. Die Berechtigung „Erneut freigeben“ ist standardmäßig ausgewählt, ebenso wie die Berechtigung „Erstellen“ für das zugrunde liegende Semantikmodell. Wir empfehlen, Inhaltsersteller*innen dahingehend zu schulen, die Berechtigung „Erstellen“ nur dann zu aktivieren, wenn die Nutzer*innen dieses Berichts auch Inhaltsersteller*innen sind, die möglicherweise Berichte erstellen, Daten exportieren oder zusammengesetzte Modelle auf der Grundlage des zugrunde liegenden Semantikmodells erstellen müssen.

Tipp

Die Benutzererfahrung macht das Erteilen der Berechtigungen „Erneutes freigeben“ und „Build“ sehr einfach, aber der Benutzer, der die Freigabe durchführt, sollte immer überprüfen, ob diese Berechtigungen erforderlich sind.

Freigegebene Ansichten

Verwenden Sie eine freigegebene Ansicht, um eine gefilterte Perspektive eines Berichts für einen anderen Benutzer freizugeben. Sie können eine freigegebene Ansicht über einen Freigabelink oder über Direktzugriff veröffentlichen.

Freigegebene Ansichten sind ein temporäres Konzept. Sie laufen nach 180 Tagen automatisch ab. Aus diesem Grund eignen sich freigegebene Ansichten am besten für informelle und temporäre Freigabeszenarien. Stellen Sie sicher, dass Ihre Benutzer sich dieser Einschränkung bewusst sind.

Prüfliste – Beim Erstellen Ihrer Strategie für die Berechtigungen pro Element sind folgende wichtigen Entscheidungen und Aktionen zu berücksichtigen:

• Entscheiden bezüglich der Strategie für die Verwendung des Freigabefeatures: Definieren Sie ihre Präferenzen für die Verwendung von Berechtigungen pro Element. Stellen Sie sicher, dass sie an Ihrer Gesamtstrategie für Consumer mit nur Leseberechtigung ausgerichtet ist.
• Entscheiden, wer Apps für die gesamte Organisation veröffentlichen kann: Entscheiden Sie, welche Berichtsersteller Links für die gesamte Organisation veröffentlichen können. Legen Sie die Mandanteneinstellung Freigegebene Links zulassen, um allen Benutzern in Ihrer Organisation Zugriff zu gewähren so fest, dass sie mit dieser Entscheidung übereinstimmt.
• Erstellen und Veröffentlichen von Anleitungen für Inhaltsersteller: Stellen Sie Dokumentation und Training für Inhaltsersteller bereit, die Anforderungen und Präferenzen für die effektive Verwendung von Berechtigungen pro Element enthalten. Stellen Sie sicher, dass sie sich über die Vor- und Nachteile von Berechtigungen pro Element im Klaren sind. Schließen Sie Anleitungen dazu ein, wann Freigabelinks verwendet werden sollen und wann die Freigabe über Direktzugriff verwendet werden soll.

Andere Consumerabfragetechniken

Die gängigsten Möglichkeiten für Consumer, mit Power BI zu interagieren, sind Apps, Arbeitsbereiche und Berechtigungen pro Element (zuvor in diesem Artikel beschrieben).

Es gibt andere Techniken, die Consumer verwenden können, um Power BI-Daten abzufragen. Jede der folgenden Abfragetechniken erfordert die Semantikmodell- oder Datamart-Berechtigung „Erstellen“.

• Analysieren in Excel: Nutzer*innen, die Excel bevorzugen, können ein Power BI-Semantikmodell mithilfe von In Excel analysieren abfragen. Diese Funktionalität ist eine hervorragende Alternative zum Exportieren von Daten nach Excel, da die Daten nicht dupliziert werden. Durch eine Liveverbindung mit dem Semantikmodell können Benutzer*innen PivotTables, Diagramme und Datenschnitte erstellen. Anschließend können sie die Arbeitsmappe in einem Arbeitsbereich im Power BI-Dienst veröffentlichen, sodass Consumer sie öffnen und mit ihr interagieren können.
• XMLA-Endpunkt: Nutzer*innen können ein Semantikmodell abfragen, indem sie eine Verbindung mit dem XMLA-Endpunkt herstellen. Eine Anwendung, die XMLA-konform ist, kann eine Verbindung mit einem Semantikmodell herstellen, das in einem Premium-Arbeitsbereich gespeichert ist, und es abfragen und nutzen. Das ist hilfreich, wenn Nutzer*innen ein Power BI-Semantikmodell als Datenquelle für ein Datenvisualisierungstool außerhalb des Microsoft-Ökosystems verwenden möchten.
• Datamart-Editor: Consumer können einen Power BI-Datamart mithilfe des Datamart-Editors abfragen. Es handelt sich um einen webbasierten visuellen Abfrage-Editor zum Erstellen von Abfragen ohne Code. Es gibt auch einen webbasierten SQL-Editor, falls Consumer es bevorzugen, SQL-Abfragen zu schreiben. Beide Editoren fragen die verwaltete Azure SQL-Datenbank ab, die dem Power BI-Datamart zugrunde liegt (anstelle des integrierten Semantikmodells).
• SQL-Endpunkt: Consumer können einen Power BI-Datamart mithilfe des SQL-Endpunkts abfragen. Sie können Tools wie Azure Data Studio oder SQL Server Management Studio (SSMS) verwenden, um SQL-Abfragen auszuführen. Der SQL-Endpunkt leitet Abfragen an die verwaltete Azure SQL-Datenbank weiter, die dem Power BI-Datamart zugrunde liegt (anstelle des integrierten Semantikmodells).

Weitere Informationen zur Berechtigung „Build“ finden Sie im Artikel Sicherheitsplanung für Inhaltsersteller.

Prüfliste – Bei der Planung der Abfragetechniken, die von Consumern verwendet werden, sind folgende wichtigen Entscheidungen und Aktionen zu berücksichtigen:

• Erstellen von Anleitungen für Benutzer*innen zur Verwendung von „Analysieren in Excel“: Stellen Sie Dokumentations- und Schulungsmaterial für Nutzer*innen bereit, um sie darüber zu informieren, wie vorhandene Semantikmodelle am besten mit Excel wiederverwendet werden.
• Erstellen von Anleitungen für Benutzer*innen zur Verwendung des XMLA-Endpunkts: Stellen Sie Dokumentations- und Schulungsmaterial für Nutzer*innen bereit, um sie darüber zu informieren, wie vorhandene Semantikmodelle am besten mit dem XMLA-Endpunkt wiederverwendet werden.
• Erstellen einer Anleitung für Benutzer für Datamart-Abfragen: Stellen Sie Dokumentation und Training für Verbraucher zu den verfügbaren Techniken zum Abfragen von Power BI-Datamarts bereit.

Workflow „Zugriff anfordern“ für Consumer

Beim Freigeben von Inhalten ist es üblich, dass ein Benutzer einen Link (URL) an einen anderen Benutzer weiterleitet. Wenn der Empfänger versucht, den Inhalt anzuzeigen und feststellt, dass er keinen Zugriff darauf hat, kann er die Schaltfläche Zugriff anfordern auswählen. Diese Aktion initiiert den Workflow Zugriff anfordern. Der Benutzer wird dann aufgefordert, eine Nachricht bereitzustellen, in der er erklärt, warum er Zugriff benötigt.

Ein Workflow Zugriff anfordern existiert für Folgendes:

• Zugriff auf eine Power BI-App.
• Zugriff auf ein Element, z. B. einen Bericht oder ein Dashboard.
• Zugriff auf ein Semantikmodell Weitere Informationen zum Workflow Zugriff anfordern bei auffindbaren Semantikmodellen finden Sie im Artikel Sicherheitsplanung für Inhaltsersteller*innen.

Zugriffsanforderungen auf eine App

Es gibt zwei Möglichkeiten, sich über ausstehende Zugriffsanforderungen zu informieren, die für eine App übermittelt wurden.

• E-Mail: Die Kontakte für die App erhalten eine E-Mail-Benachrichtigung. Standardmäßig ist dieser Kontakt der Herausgeber der App. Um kritische Apps besser zu unterstützen, empfehlen wir, den Kontakt auf eine Gruppe festzulegen, die schnell auf Zugriffsanforderungen reagieren kann.
• Menü „Berechtigungen verwalten“": Arbeitsbereichsadministratoren und Mitglieder können Zugriffsanforderungen anzeigen, genehmigen oder ablehnen. Die Seite Berechtigungen verwalten ist auf der Seite „Apps“ verfügbar und kann für jede App geöffnet werden. Diese Funktionalität ist auch für Arbeitsbereichsmitwirkende verfügbar, wenn die Einstellung Zulassen, dass Mitwirkende die App für diesen Arbeitsbereich aktualisieren aktiviert ist.

Ausstehende Zugriffsanforderungen für eine App zeigen die vom Benutzer bereitgestellte Nachricht an. Jede ausstehende Anforderung kann genehmigt oder abgelehnt werden. Wenn Sie eine Anforderung genehmigen möchten, muss eine App-Zielgruppe ausgewählt werden.

Der folgende Screenshot zeigt eine ausstehende Zugriffsanforderung eines Benutzers. Um sie zu genehmigen, muss eine der beiden App-Zielgruppen Vertriebsmitarbeiter oder Vertriebsleitung ausgewählt werden.

Wenn Sie eine App veröffentlichen, werden der Inhalt und die Berechtigungen gleichzeitig veröffentlicht. Wie bereits beschrieben, ist es nicht möglich, nur die App-Berechtigungen ohne Inhaltsänderungen zu veröffentlichen. Es gibt jedoch eine Ausnahme: Wenn Sie eine ausstehende Zugriffsanforderung genehmigen (z. B. die im vorherigen Screenshot angezeigte Anforderung), wird die Berechtigungsänderung durchgeführt, ohne den neuesten Inhalt im Arbeitsbereich zu veröffentlichen.

Zugriffsanforderungen auf einen Arbeitsbereich

Der Arbeitsbereichszugriff wird von Benutzern gewährt, die der Rolle „Administrator“ oder der Rolle „Mitglied“ angehören.

Ein Benutzer, der versucht, einen Arbeitsbereich anzuzeigen, erhält eine Nachricht Zugriff verweigert, wenn er kein Mitglied einer Arbeitsbereichsrolle ist. Da es keinen integrierten Workflow für Zugriff anfordern für Arbeitsbereiche gibt, werden sie am besten für kleine Teams und informelle Teams verwendet, die eng zusammenarbeiten. Dies ist ein Grund, warum eine Power BI-App besser für größere Teams und breitere Inhaltsverteilungsszenarien geeignet ist.

Zugriffsanforderungen pro Element

Es gibt zwei Möglichkeiten, sich über ausstehende Zugriffsanforderungen zu informieren, die für ein einzelnes Element wie beispielsweise einen Bericht übermittelt wurden.

• E-Mail: Die Kontakte für das Element erhalten eine E-Mail-Benachrichtigung. Um kritische Berichte besser zu unterstützen, empfehlen wir, den Kontakt auf eine Gruppe festzulegen, die schnell auf Zugriffsanforderungen reagieren kann.
• Menü „Berechtigungen verwalten“: Administrator*innen und Mitglieder eines Arbeitsbereichs können auf die Seite Berechtigungen verwalten für jedes Element zugreifen. Sie können ausstehende Anforderungen anzeigen, genehmigen oder den Zugriff ablehnen.

Verwalten von Zugriffsanforderungen mit Gruppen

Wenn ein Benutzer oder eine Benutzerin das Formular Zugriff anfordern für ein Power BI-Element (z. B. einen Bericht oder ein Semantikmodell) oder für eine Power BI-App übermittelt, wird die Anforderung für einen einzelnen Benutzer bzw. für eine einzelne Benutzerin übermittelt. Viele große Organisationen müssen jedoch Gruppen verwenden, um mit ihren internen Sicherheitsrichtlinien konform zu sein.

Wir empfehlen Ihnen, wann immer möglich Gruppen anstelle von Einzelpersonen zu verwenden, um Inhalte zu schützen. Weitere Informationen zur Planung für Gruppen finden Sie im Artikel Sicherheitsplanung auf Mandantenebene.

Wenn Sie den Zugriff auf Gruppen anstelle einzelner Benutzer gewähren möchten, muss der Inhaltsbesitzer oder Administrator, der die Zugriffsanforderung verarbeitet, die Anforderung in mehreren Schritten durchführen:

1. Ablehnen der ausstehende Anforderung in Power BI (da sie einem einzelnen Benutzer zugeordnet ist).
2. Hinzufügen des Anfordernden zur richtigen Gruppe gemäß Ihrem aktuellen Prozess.
3. Benachrichtigen des Anfordernden, dass er jetzt Zugriff hat.

Tipp

Informationen zum Beantworten von Anforderungen für den Zugriff „Build“ für Inhaltsersteller finden Sie unter Workflow „Zugriff anfordern“ für Ersteller . Dort finden Sie auch Empfehlungen zur Verwendung eines Formulars für Zugriffsanforderungen.

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

• Bestimmen, wer App-Zugriffsanforderungen verarbeiten soll: Stellen Sie sicher, dass ein Prozess vorhanden ist, um App-Zugriffsanforderungen zeitnah zu behandeln. Stellen Sie sicher, dass App-Kontakte zur Unterstützung des Prozesses zugewiesen sind.
• Bestimmen, wer Anforderungen pro Element verarbeiten soll: Stellen Sie sicher, dass ein Prozess vorhanden ist, um Anforderungen pro Element zeitnah zu behandeln. Stellen Sie sicher, dass jedem Element Kontakte zugewiesen sind, um den Prozess zu unterstützen.
• In die Dokumentation und das Training für Inhaltsersteller einbeziehen: Stellen Sie sicher, dass die Ersteller von Inhalten verstehen, wie Zugriffsanforderungen zeitnah verarbeitet werden. Machen Sie ihnen bewusst, wie mit Anfragen umzugehen ist, wenn eine Gruppe anstelle eines einzelnen Benutzers verwendet werden soll.
• In die Dokumentation und das Training einbeziehen: Schließen Sie Anleitungen für Ihre Inhaltsersteller ein, wie Sie Zugriffsanforderungen effektiv verwalten können. Schließen Sie ebenfalls Anleitungen für Consumer ein, welche Informationen in ihre Zugriffsanforderungsnachricht aufgenommen werden sollen.

Durchsetzen der Datensicherheit basierend auf der Consumeridentität

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.

Stellen Sie sich beispielsweise einen einzelnen Umsatzbericht vor , den Sie für alle Vertriebsmitarbeiter (Consumer) freigeben können, da sie wissen, dass jeder Vertriebsmitarbeiter nur Verkaufsergebnisse für seine Region sehen wird. Mit diesem Ansatz können Sie die Komplexität des Erstellens separater Berichte pro Region vermeiden, die für die Vertriebsmitarbeiter aus dieser Vertriebsregion freigegeben werden müssten.

Einige Organisationen haben bestimmte Anforderungen an bestätigte (zertifizierte oder höher gestufte) Semantikmodelle oder Datamarts. Für Daten, die breit verwendet werden, kann es eine Anforderung sein, Datensicherheit zu verwenden.

Sie können Datensicherheit auf mehrere Arten erreichen.

• Power BI-Semantikmodell: Power BI-Datenersteller*innen können Sicherheit auf Zeilenebene (Row-Level Security, RLS) und Sicherheit auf Objektebene (Object-Level Security, OLS) erzwingen. RLS umfasst das Definieren von Rollen und Regeln zum Filtern von Datenmodellzeilen, während OLS den Zugriff auf bestimmte Tabellen oder Spalten einschränkt. Diese definierten RLS- und OLS-Regeln gelten nicht für Verweise, die außerhalb des semantischen Modells gespeichert sind, z. B. Datenschnitt und Filterauswahl. Beide RLS- und OLS-Techniken werden weiter unten in diesem Abschnitt beschrieben.
• Analysis Services: Ein Semantikmodell mit Liveverbindung kann eine Verbindung mit einem Remotedatenmodell herstellen, das entweder von Azure Analysis Services (AAS) oder von SQL Server Analysis Services (SSAS) gehostet wird. Das Remotemodell kann RLS oder OLS basierend auf der Consumeridentität erzwingen.
• Datenquelle: Einige Datenquellen, z. B. Azure SQL-Datenbank, können RLS erzwingen. In diesem Fall kann das Power BI-Modell die vorhandene Sicherheit nutzen, anstatt sie neu zu definieren. Dieser Ansatz kann ein erheblicher Vorteil sein, wenn die in der Quelle definierte RLS komplex ist. Sie können ein DirectQuery-Modell entwickeln und veröffentlichen und die Datenquellenanmeldeinformationen des Semantikmodells im Power BI-Dienst festlegen, um einmaliges Anmelden (Single Sign-On, SSO) zu aktivieren. Wenn ein Berichtsconsumer einen Bericht öffnet, übergibt Power BI seine Identität an die Datenquelle. Die Datenquelle erzwingt dann RLS, basierend auf der Identität des Berichtsverbrauchers. Weitere Informationen zu RLS für Azure SQL-Datenbank finden Sie in diesem Artikel.

Hinweis

Quellsysteme wie Azure SQL-Datenbank können auch Techniken wie Ansichten verwenden, um einzugrenzen, was der Benutzer sehen kann. Dies ist zwar eine gültige Technik, aber für den Schwerpunkt dieses Abschnitts nicht relevant.

Sicherheit auf Zeilenebene

Sicherheit auf Zeilenebene (Row-Level Security, RLS) ermöglicht es Datenmodellierenden, den Zugriff auf eine Teilmenge von Daten zu beschränken. Sie wird in der Regel verwendet, um sicherzustellen, dass einige Berichtsconsumer spezifischen Daten nicht sehen können, z. B. Verkaufsergebnisse anderer Vertriebsregionen.

Tipp

Wenn Sie bemerkt haben, dass jemand mehrere Datenmodelle zur Unterstützung verschiedener Gruppen von Consumern erstellt hat, überprüfen Sie, ob RLS ihre Anforderungen erfüllen wird. In der Regel ist es besser, nur ein Datenmodell zu erstellen, zu testen und zu verwalten, anstatt mehrere.

Beachten Sie, dass, wenn ein Power BI-Bericht auf eine Zeile mit konfiguriertem RLS verweist, dieselbe Meldung wie für ein gelöschtes oder nicht vorhandenes Feld angezeigt wird. Für diese Benutzer sieht es so aus, als sei der Bericht beschädigt.

Es gibt zwei Schritte zum Einrichten von RLS: Regeln und Rollenzuordnungen.

RLS-Regeln

Für Semantikmodelle können Datenmodellierer*innen RLS in Power BI Desktop einrichten, indem sie eine oder mehrere Rollen erstellen. Eine Rolle hat einen eindeutigen Namen im Modell und umfasst normalerweise eine oder mehrere Regeln. Regeln erzwingen Filter auf Modelltabellen mithilfe von DAX-Filterausdrücken (Data Analysis Expressions). Standardmäßig hat ein Modell keine Rollen.

Wichtig

Ein Modell ohne Rollen bedeutet, dass Benutzer (welche über die Berechtigung verfügen, das Datenmodell abzufragen) Zugriff auf alle Modelldaten haben.

Regelausdrücke werden im Zeilenkontext ausgewertet. Zeilenkontext bedeutet, dass der Ausdruck für jede Zeile ausgewertet wird, indem die Spaltenwerte dieser Zeile verwendet werden. Wenn der Ausdruck TRUE zurückgibt, kann der Benutzer die Zeile sehen. Sie können Regeln definieren, die entweder statisch oder dynamisch sind.

• Statische Regeln: Verwenden Sie DAX-Ausdrücke, die auf Konstanten verweisen, z. B [Region] = "Midwest".
• Dynamische Regeln: Verwenden Sie spezielle DAX-Funktionen, die Umgebungswerte zurückgeben (im Gegensatz zu Konstanten). Umgebungswerte werden von drei spezifischen DAX-Funktionen zurückgegeben: USERNAME, USERPRINCIPALNAME und CUSTOMDATA. Die Definition von dynamischen Regeln ist einfach und effektiv, wenn eine Modelltabelle Werte von Benutzernamen speichert. Sie ermöglichen Ihnen die Durchsetzung eines datengesteuerten RLS-Entwurfs.

RLS-Rollenzuordnungen

Nachdem Sie das Modell im Power BI-Dienst veröffentlicht haben, müssen Sie Rollenzuordnungen einrichten, bevor Benutzer auf verwandte Berichte zugreifen. Die Rollenzuordnung umfasst die Zuweisung von Microsoft Entra-Sicherheitsobjekten zu Rollen. Sicherheitsobjekte können Benutzerkonten oder Sicherheitsgruppen sein.

Wann immer möglich ist es eine bewährte Methode, Rollen zu Sicherheitsgruppen zuzuordnen. Auf diese Weise gibt es weniger Zuordnungen, und die Verwaltung der Gruppenmitgliedschaft kann vom Besitzer der Gruppe bewältigt werden.

Wir empfehlen Ihnen, Sicherheitskontoinformationen aus Microsoft Entra für Ihre Inhaltsersteller verfügbar zu machen. Eine Option besteht darin, einen Dataflow mit Daten zu erstellen, die mit Microsoft Entra ID synchronisiert werden. Auf diese Weise können Inhaltsersteller*innen die Daten des Dataflows integrieren, um ein datengesteuertes Semantikmodell zu erstellen.

Tipp

Es ist möglich, eine Rolle zu definieren, die keine Regeln hat. In diesem Fall bietet die Rolle Zugriff auf alle Zeilen aller Modelltabellen. Das Einrichten dieser Art von Rolle ist geeignet, wenn ein Administrator oder Benutzer alle Daten im Modell anzeigen darf.

RLS-Benutzererfahrung

Einige Organisationen entscheiden sich dafür, RLS gezielt als zweite Sicherheitsebene zusätzlich zu den Standardberechtigungen von Power BI zu verwenden. Betrachten Sie das folgende Szenario: Sie teilen einen Link zu einem Bericht mit der gesamten Organisation. Jeder Benutzer, der den Bericht anzeigt, muss einer RLS-Rolle zugeordnet sein, um Daten im Bericht anzeigen zu können. Wenn er keiner RLS-Rolle zugeordnet sind, wird er keine Daten sehen.

Das Vorhandensein von RLS ändert die Standarderfahrung für Consumer.

• Wenn RLS für das Semantikmodell nicht definiert ist: Ersteller*innen und Nutzer*innen, die mindestens über die Berechtigung „Lesen“ für das Semantikmodell verfügen, können alle Daten im Semantikmodell anzeigen.
• Wenn RLS für das Semantikmodell definiert ist: Ersteller*innen und Nutzer*innen, die nur über die Berechtigung „Lesen“ für das Semantikmodell verfügen, können nur die Daten anzeigen, die sie sehen dürfen (basierend auf ihrer RLS-Rollenzuordnung).

Hinweis

Einige Organisationen erzwingen RLS als zusätzliche Sicherheitsebene, insbesondere wenn vertrauliche Daten betroffen sind. Aus diesem Grund können Sie sich ggf. dafür entscheiden, RLS für Semantikmodelle vorzuschreiben, die zertifiziert sind. Diese Anforderung kann mit einem internen Überprüfungs- und Genehmigungsprozess vor der Zertifizierung des Semantikmodells erreicht werden.

Wenn Benutzer*innen einen Bericht in einem Arbeitsbereich oder in einer App anzeigen, ist die Erzwingung von RLS ggf. abhängig von ihren Semantikmodellberechtigungen. Aus diesem Grund ist es wichtig, dass Nutzer*innen und Ersteller*innen von Inhalten nur dann die Berechtigung „Lesen“ für das zugrunde liegende Semantikmodell besitzen, wenn RLS erzwungen werden muss.

Hier finden Sie die Berechtigungsregeln, die bestimmen, ob RLS erzwungen wird.

• Der Benutzer bzw. die Benutzerin verfügt über die Berechtigung „Lesen“ für das Semantikmodell: RLS wird für den Benutzer bzw. für die Benutzerin erzwungen.
• Der Benutzer bzw. die Benutzerin verfügt über die Berechtigungen „Lesen“ und „Erstellen“ für das Semantikmodell: RLS wird für den Benutzer bzw. für die Benutzerin erzwungen.
• Der Benutzer bzw. die Benutzerin verfügt über die Berechtigung „Schreiben“ für das Semantikmodell: RLS wird für den Benutzer bzw. für die Benutzerin nicht erzwungen, was bedeutet, dass er bzw. sie alle Daten im Semantikmodell sehen kann. Die Berechtigung „Schreiben“ ermöglicht die Bearbeitung eines Semantikmodells. Sie kann auf zwei Arten zugewiesen werden:
  • Mit den Arbeitsbereichsrollen „Mitwirkender“, „Mitglied“ oder „Administrator“ (für den Arbeitsbereich, in dem das Semantikmodell gespeichert ist)
  • Mit der elementspezifischen Semantikmodellberechtigung „Schreiben“.

Tipp

Weitere Informationen zur Verwendung separater Arbeitsbereiche, damit RLS für Inhaltsersteller funktioniert, finden Sie im Nutzungsszenario für verwaltetes Self-Service-BI.

Weitere Informationen zu RLS finden Sie unter Einschränken des Zugriffs auf Power BI-Modelldaten.

RLS für Datamarts

Power BI Datamarts können RLS ebenfalls erzwingen. Die Implementierung ist jedoch anders.

Der Hauptunterschied besteht darin, dass RLS für Datamarts im Power BI-Dienst und nicht in Power BI Desktop eingerichtet wird.

Ein weiterer Unterschied besteht darin, dass Datamarts RLS sowohl für das Semantikmodell als auch für die verwaltete Azure SQL-Datenbank erzwingen, die dem Datamart zugeordnet ist. Das Erzwingen von RLS auf beiden Ebenen bietet Konsistenz und Flexibilität. Die gleichen RLS-Filter werden unabhängig davon angewendet, wie Benutzer*innen die Daten abfragen – sei es durch Herstellen einer Verbindung mit dem Semantikmodell oder durch Herstellen einer Verbindung mit der verwalteten Azure SQL-Datenbank.

Weitere Informationen finden Sie unter RLS für Datamarts.

Sicherheit auf Objektebene

Sicherheit auf Objektebene (Object-Level Security, OLS) ermöglicht es Datenmodellierenden, den Zugriff auf bestimmte Tabellen und Spalten sowie deren Metadaten zu beschränken. In der Regel verwenden Sie OLS, um sicherzustellen, dass vertrauliche Spalten, z. B. Mitarbeitergehalt, für bestimmte Benutzer nicht sichtbar sind. Obwohl es nicht möglich ist, den Zugriff auf Measures einzuschränken, wird jedes Measure, das auf eine eingeschränkte Spalte verweist, selbst eingeschränkt sein.

Betrachten Sie ein Beispiel für eine Mitarbeitertabelle. Sie enthält Spalten, in denen der Name und die Telefonnummer des Mitarbeiters sowie das Gehalt gespeichert sind. Sie können OLS verwenden, um sicherzustellen, dass nur bestimmte Benutzer, z. B. Mitarbeiter im Personalwesen, Gehaltswerte anzeigen können. Für diejenigen Benutzer, die keine Gehaltswerte sehen können, ist es so, als ob diese Spalte nicht vorhanden wäre.

Seien Sie vorsichtig: Wenn ein Visual eines Power BI-Berichts das Gehalt enthält, erhalten Benutzer ohne Zugriff auf dieses Feld eine Fehlermeldung. Die Nachricht wird sie informieren, dass das Objekt nicht vorhanden ist. Für diese Benutzer sieht es so aus, als sei der Bericht beschädigt.

Hinweis

Sie können auch Perspektiven in einem Datenmodell definieren. Eine Perspektive definiert anzeigbare Teilmengen von Modellobjekten, um Berichtserstellern einen bestimmten Fokus zu geben. Perspektiven sind nicht dazu gedacht, den Zugriff auf Modellobjekte einzuschränken. Ein Benutzer kann auch dann noch eine Tabelle oder Spalte abfragen, wenn sie für ihn nicht sichtbar ist. Betrachten Sie Perspektiven daher als ein Feature der Benutzerfreundlichkeit und nicht als Sicherheitsfeature.

Es gibt derzeit keine Schnittstelle in Power BI Desktop, um OLS einzurichten. Sie können den Tabellarischen Editor verwenden, der ein Drittanbietertool zum Erstellen, Unterhalten und Verwalten von Modellen ist. Weitere Informationen finden Sie im Verwendungsszenario Erweiterte Datenmodellverwaltung.

Weitere Informationen zu OLS finden Sie unter Einschränken des Zugriffs auf Power BI-Modellobjekte.

Prüfliste – Bei der Planung für RLS und OLS sind folgende wichtigen Entscheidungen und Aktionen zu berücksichtigen:

• Entscheiden bezüglich einer Strategie für die Verwendung von RLS: Überlegen Sie, für welche Anwendungsfälle und Zwecke Sie Sicherheit auf Zeilenebene verwenden wollen.
• Entscheiden bezüglich einer Strategie für die Verwendung von OLS: Überlegen Sie, für welche Anwendungsfälle und Zwecke Sie Sicherheit auf Objektebene verwenden wollen.
• Berücksichtigen der Anforderungen für zertifizierte Inhalte: Wenn Sie einen Prozess für die Anforderungen zur Zertifizierung eines Semantikmodells haben, müssen Sie entscheiden, ob sie spezifische Anforderungen für die Verwendung von RLS oder OLS einbeziehen möchten.
• Erstellen und Veröffentlichen einer Benutzeranleitung: Erstellen Sie eine Dokumentation für Benutzer, die Anforderungen und Präferenzen für die Verwendung von RLS und OLS enthält. Beschreiben Sie, wie Benutzerzuordnungsinformationen abgerufen werden, wenn sie an einem zentralen Speicherort vorhanden sind.
• Aktualisieren der Trainingsmaterialien: Fügen Sie wichtige Informationen zu Anforderungen und Präferenzen für RLS und OLS in die Trainingsmaterialien für Benutzer ein. Stellen Sie Beispiele für Benutzer bereit, damit diese verstehen, wann es angemessen ist, eine der beiden Datensicherheitstechniken zu verwenden.

Zugehöriger Inhalt

Im nächsten Artikel dieser Reihe erfahren Sie mehr über die Sicherheitsplanung für Inhaltsersteller*innen, die für die Erstellung von Semantikmodellen, Dataflows, Datamarts, Berichten oder Dashboards verantwortlich sind.