Dienstprinzipalprofile für Apps mit mehreren Mandanten in Power BI Embedded

  • Artikel

In diesem Artikel wird erläutert, wie ein ISV oder ein beliebiger anderer Power BI Embedded App-Besitzer mit vielen Kunden Dienstprinzipalprofile verwenden kann, um die Daten der einzelnen Kunden im Rahmen seiner Power BI-Lösung zur Einbettung für Ihre Kunden zuzuordnen und zu verwalten. Dienstprinzipalprofile ermöglichen es dem ISV, skalierbare Anwendungen zu erstellen, die eine bessere Isolation von Kundendaten ermöglichen und engere Sicherheitsgrenzen zwischen Kunden herstellen. In diesem Artikel werden die Vorteile und die Einschränkungen dieser Lösung erläutert.

Hinweis

Das Wort Mandant in Power BI kann manchmal auf einen Microsoft Entra-Mandanten verweisen. In diesem Artikel verwenden wir jedoch den Begriff mehrere Mandanten, um eine Lösung zu beschreiben, bei der eine einzelne Instanz einer Softwareanwendung mehrere Kunden oder Organisationen (Mandanten) bedient, für die eine physische und logische Trennung der Daten erforderlich ist. Beispielsweise kann der Power BI-App-Generator einen separaten Arbeitsbereich für alle Kund*innen (oder Mandanten) zuweisen, wie unten dargestellt. Bei diesen Kunden handelt es sich nicht zwangsläufig um Microsoft Entra-Mandanten; verwechseln Sie also nicht den Begriff Anwendung mit mehreren Mandanten, den wir hier verwenden, mit der Microsoft Entra-Mehrmandantenanwendung.

Ein Dienstprinzipalprofil ist ein Profil, das von einem Dienstprinzipal erstellt wird. Die ISV-App ruft die Power BI-APIs mithilfe eines Dienstprinzipalprofils auf, wie in diesem Artikel erläutert.

Der Dienstprinzipal der ISV-Anwendung erstellt für jeden Kunden oder Mandanten ein anderes Power BI-Profil. Wenn ein Kunde die ISV-App besucht, verwendet die App das entsprechende Profil, um ein Einbettungstoken zu generieren, das zum Rendern eines Berichts im Browser verwendet wird.

Mithilfe von Dienstprinzipalprofilen kann die ISV-App mehrere Kunden auf einem einzelnen Power BI-Mandanten hosten. Jedes Profil stellt einen Kunden in Power BI dar. Mit anderen Worten, jedes Profil erstellt und verwaltet Power BI-Inhalte für die Daten eines bestimmten Kunden.

Diagramm von SP-Profilen und mehreren Mandanten.

Hinweis

Dieser Artikel richtet sich an Organisationen, die eine App für mehrere Mandanten mithilfe von Dienstprinzipalprofilen einrichten möchten. Wenn Ihre Organisation bereits über eine App verfügt, die mehrere Mandanten unterstützt, und Sie zum Dienstprinzipalprofil-Modell migrieren möchten, finden Sie Informationen dazu unter Migrieren zum Dienstprinzipalprofil-Modell.

Das Einrichten Ihrer Power BI-Inhalte umfasst die folgenden Schritte:

Alle oben genannten Schritte können mithilfe von Power BI REST-APIs vollständig automatisiert werden.

Voraussetzungen

Damit Sie Dienstprinzipalprofile erstellen können, müssen Sie Folgendes erledigt haben:

  • Einrichten des Dienstprinzipals mithilfe der ersten drei Schritte von Einbetten von Power BI-Inhalten mit einem Dienstprinzipal.
  • Aktivieren Sie in einem Power BI-Mandantenadministratorkonto das Erstellen von Profilen im Mandanten mit derselben Sicherheitsgruppe, die Sie beim Erstellen des Dienstprinzipals verwendet haben.

Screenshot des Verwaltungsportalswitches

Erstellen eines Profils

Profile können mithilfe der REST-API von Profilen erstellt, aktualisiert und gelöscht werden.

So erstellen Sie z. B. ein Profil:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

Ein Dienstprinzipal kann außerdem GET Profiles REST API aufrufen, um eine Liste seiner Profile abzurufen. Zum Beispiel:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Profilberechtigungen

Jede API, die einem Benutzer Berechtigungen für Power BI-Elemente erteilt, kann auch Power BI-Elementen eine Profilberechtigung erteilen. Beispielsweise kann die API zum Hinzufügen von Gruppenbenutzern verwendet werden, um einem Arbeitsbereich eine Profilberechtigung zu erteilen.

Die folgenden Punkte sind wichtig, um zu verstehen, wann Profile verwendet werden:

  • Ein Profil gehört zum Dienstprinzipal, der es erstellt hat, und kann nur von diesem Dienstprinzipal verwendet werden.
  • Nach der Erstellung kann der Profilbesitzer kann nicht geändert werden.
  • Ein Profil ist keine eigenständige Identität. Es benötigt das Microsoft Entra-Token des Dienstprinzipals, um Power BI-REST-APIs aufzurufen.

ISV-Apps rufen Power BI-REST-APIs auf, indem sie das Microsoft Entra-Token des Dienstprinzipals im Autorisierungsheader und die Profil-ID im X-PowerBI-Profil-ID-Header bereitstellen. Beispiel:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Erstellen eines Arbeitsbereichs

Power BI-Arbeitsbereiche werden verwendet, um Power BI-Elemente wie Berichte und Semantikmodelle zu hosten.

Jedes Profil muss:

  • Mindestens einen Power BI-Arbeitsbereich erstellen

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Dem Arbeitsbereich Zugriffsberechtigungen erteilen Das Dienstprinzipalprofil muss über Administratorzugriff auf den Arbeitsbereich verfügen.

  • Den Arbeitsbereich einer Kapazität zuweisen

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

Informieren Sie sich ausführlicher über Power BI-Arbeitsbereiche.

Importieren von Berichten und Semantikmodellen

Verwenden Sie Power BI Desktop, um Berichte vorzubereiten, die mit den Daten des Kunden oder Beispieldaten verbunden sind. Anschließend können Sie die Import-API verwenden, um die Inhalte in den erstellten Arbeitsbereich zu importieren.

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Verwenden Sie Datasetparameter, um ein Semantikmodell zu erstellen, das eine Verbindung mit den Datenquellen verschiedener Kund*innen herstellen kann. Verwenden Sie dann die API Parameter aktualisieren, um zu definieren, zu welchen Kundendaten das Semantikmodell eine Verbindung herstellt.

Festlegen der Semantikmodellverbindung

ISVs speichern in der Regel die Daten ihrer Kunden auf eine von zwei Arten:

In beiden Fällen sollten Sie im Ergebnis Einzelmandanten-Semantikmodell (ein Semantikmodell pro Kunde bzw. Kundin) in Power BI erhalten.

Eine separate Datenbank für jeden Kunden

Wenn die ISV-Anwendung für jede Kundin bzw. jeden Kunden eine separate Datenbank nutzt, erstellen Sie Einzelmandanten-Semantikmodelle in Power BI. Geben Sie für jedes Semantikmodell Verbindungsdetails an, die auf die ihm zugeordnete Datenbank verweisen. Verwenden Sie eine der folgenden Methoden, um das Erstellen mehrerer identischer Berichte mit unterschiedlichen Verbindungsdetails zu vermeiden:

  • Semantikmodellparameter: Erstellen Sie ein Semantikmodell mit Parametern in den Verbindungsdetails (z. B. SQL-Servername, SQL-Datenbankname). Importieren Sie dann einen Bericht in den Arbeitsbereich eines Kunden, und ändern Sie die Parameter so, dass sie den Datenbankdetails des Kunden entsprechen.

  • API zum Aktualisieren der Datenquelle: Erstellen Sie eine PBIX, die auf eine Datenquelle mit Beispielinhalten verweist. Importieren Sie dann die PBIX-Datei in den Arbeitsbereich eines Kunden, und ändern Sie die Verbindungsdetails mithilfe der API zum Aktualisieren der Datenquelle.

Eine einzelne Datenbank mit mehreren Mandanten

Wenn die ISV-Anwendung eine Datenbank für alle Kund*innen verwendet, trennen Sie die Kund*innen in Power BI wie folgt in verschiedene Semantikmodelle:

Erstellen Sie einen Bericht mithilfe von Parametern, die nur die Daten des relevanten Kunden abrufen. Importieren Sie dann einen Bericht in den Arbeitsbereich eines Kunden, und ändern Sie die Parameter so, dass nur die Daten des relevanten Kunden abgerufen werden.

Einbetten eines Berichts

Nachdem das Setup abgeschlossen ist, können Sie Kundenberichte und andere Elemente mithilfe eines Einbettungstokens in Ihre Anwendung einbetten.

Wenn ein Kunde Ihre Anwendung besucht, verwenden Sie das entsprechende Profil, um die GenerateToken-API aufzurufen. Verwenden Sie das generierte Einbettungstoken, um einen Bericht oder andere Elemente im Browser des Kunden einzubetten.

So wird ein Einbettungstoken generiert:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Entwurfsaspekte

Bevor Sie eine profilbasierte Lösung für mehrere Mandanten einrichten, sollten Sie sich der folgenden Probleme bewusst sein:

Skalierbarkeit

Durch die Aufteilung der Daten in separate Semantikmodelle für jede Kundin bzw. jeden Kunden minimieren Sie den Bedarf an großen Semantikmodellen. Wenn die Kapazität überlastet wird, können nicht verwendete Semantikmodelle entfernt werden, um Arbeitsspeicher für aktive Semantikmodelle freizugeben. Diese Optimierung ist für ein einzelnes großes Semantikmodell nicht möglich. Durch die Verwendung mehrerer Semantikmodelle können Mandanten außerdem bei Bedarf auf mehrere Power BI-Kapazitäten aufgeteilt werden.

Ohne Profile ist ein Dienstprinzipal auf 1.000 Arbeitsbereiche eingeschränkt. Zum Überwinden dieses Grenzwerts kann ein Dienstprinzipal mehrere Profile erstellen, wobei jedes Profil (auf) bis zu 1.000 Arbeitsbereiche zugreifen/erstellen kann. Bei mehreren Profilen kann die ISV-App die Inhalte jedes Kunden mithilfe getrennter logischer Container isolieren.

Sobald ein Dienstprinzipalprofil Zugriff auf einen Arbeitsbereich hat, kann der Zugriff des übergeordneten Dienstprinzipals auf den Arbeitsbereich entfernt werden, um Probleme bei der Skalierbarkeit zu vermeiden.

Trotz dieser Vorteile sollten Sie die potenzielle Skalierung Ihrer Anwendung berücksichtigen. Beispielsweise ist die Anzahl der Arbeitsbereichselemente, auf die ein Profil zugreifen kann, beschränkt. Aktuell gelten für ein Profil dieselben Grenzwerte wie für einen regulären Benutzer. Wenn die ISV-Anwendung Endbenutzern das Speichern einer personalisierten Kopie ihrer eingebetteten Berichte ermöglicht, hat das Profil eines Kunden Zugriff auf alle erstellten Berichte aller seiner Benutzer. Bei diesem Modell kann der Grenzwert unter Umständen überschritten werden.

Automatisierung und Komplexität des Betriebs

Bei einer Aufteilung auf der Grundlage von Power BI-Profilen müssen Sie möglicherweise hunderte oder tausende von Elementen verwalten. Daher ist es wichtig, die Prozesse zu definieren, die in Ihrer Verwaltung des Anwendungslebenszyklus häufig stattfinden, und sicherzustellen, dass Sie die richtigen Tools für die angemessene Durchführung dieser Vorgänge im großen Stil besitzen. Zu diesen Vorgängen gehören u. a.:

  • Hinzufügen eines neuen Mandanten
  • Aktualisieren eines Berichts für einige oder alle Mandanten
  • Aktualisieren des Semantikmodellschemas für einige oder alle Mandanten
  • Ungeplante Anpassungen für bestimmten Mandanten
  • Häufigkeit der Aktualisierungen des Semantikmodells

Beispielsweise ist das Erstellen eines Profils und eines Arbeitsbereichs für einen neuen Mandanten eine allgemeine Aufgabe, die mit der Power BI REST-APIvollständig automatisiert werden kann.

Multi-Geo-Anforderungen

Die Multi-Geo-Unterstützung für Power BI Embedded bewirkt, dass unabhängige Softwarehersteller (ISVs) und Organisationen, die Anwendungen mit Power BI Embedded entwickeln, um eine Analyse in ihre Apps zu integrieren, ihre Daten jetzt in unterschiedlichen Regionen auf der ganzen Welt bereitstellen können. Weisen Sie zum Unterstützen verschiedener Kunden in unterschiedlichen Regionen den Arbeitsbereich des Kunden einer Kapazität in der gewünschten Region zu. Diese Aufgabe ist ein einfacher Vorgang, mit dem keine zusätzlichen Kosten einhergehen. Wenn einige Ihrer Kunden jedoch Daten aus mehreren Regionen benötigen, sollte das Mandantenprofil alle Elemente in mehrere Arbeitsbereiche duplizieren, die verschiedenen regionalen Kapazitäten zugewiesen sind. Durch diese Duplizierung können sich sowohl die Kosten als auch Komplexität der Verwaltung erhöhen.

Aus Compliancegründen kann es trotzdem sinnvoll sein, mehrere Power BI-Mandanten in verschiedenen Regionen zu erstellen. Weitere Informationen zu Multi-Geo.

Kosteneffizienz

Anwendungsentwickler, die Power BI Embedded verwenden, müssen eine Power BI Embedded-Kapazität erwerben. Das profilbasierte Trennungsmodell funktioniert aus diesen Gründen gut mit Kapazitäten:

  • Das kleinste Objekt, das Sie einer Kapazität unabhängig zuweisen können, ist ein Arbeitsbereich (Sie können z. B. keinen Bericht zuweisen). Indem Sie Kunden nach Profilen trennen, erhalten Sie verschiedene Arbeitsbereiche – einen pro Kunde. Auf diese Weise erhalten Sie volle Flexibilität, jeden Kunden entsprechend seinen Leistungsanforderungen zu verwalten und die Kapazitätsauslastung zu optimieren, indem Sie auf- oder abskalieren. Beispielsweise können Sie große und wichtige Mandanten mit großem Volumen und hoher Fluktuation in einer separaten Kapazität verwalten, um ein konsistentes Serviceniveau sicherzustellen, während kleinere Mandanten in einer anderen Kapazität gruppiert werden können, um die Kosten zu optimieren.

  • Das Trennen von Arbeitsbereichen bringt auch das Trennen von Semantikmodellen zwischen Mandanten mit sich, sodass Datenmodelle in kleineren Blöcken statt in einem einzigen großen Semantikmodell vorliegen. Mit diesen kleineren Modellen kann die Kapazität die Speichernutzung effizienter verwalten. Kleine, nicht verwendete Semantikmodelle können nach einem Zeitraum von Inaktivität entfernt werden, um eine gute Leistung aufrecht zu erhalten.

Berücksichtigen Sie beim Erwerb einer Kapazität den Grenzwert für die Anzahl paralleler Aktualisierungen, da Aktualisierungsprozesse bei Verwendung mehrerer Semantikmodelle möglicherweise zusätzliche Kapazität benötigen.

Sicherheit auf Zeilenebene

In diesem Artikel wird erläutert, wie Profile zum Erstellen eines separaten Semantikmodelle für jeden Kunden bzw. jede Kundin verwendet werden. Alternativ können ISV-Anwendungen alle Daten ihrer Kund*innen in einem großen Semantikmodell speichern und Sicherheit auf Zeilenebene (Row-Level Security, RLS) verwenden, um die Daten der einzelnen Kund*innen zu schützen. Dieser Ansatz kann aus folgenden Gründen für ISVs, die relativ wenige Kund*innen und kleine bis mittlere Semantikmodelle haben, von Vorteil sein:

  • Es müssen nur ein Bericht und ein Semantikmodell gewartet werden
  • Der Onboardingprozess für neue Kunden kann vereinfacht werden

Vergewissern Sie sich jedoch, dass Sie die Einschränkungen von RLS verstehen, bevor Sie sie einsetzen. Alle Daten für alle Kund*innen befinden sich in einem großen Power BI-Semantikmodell. Dieses Semantikmodell wird in einer einzelnen Kapazität mit eigener Skalierung und anderen Einschränkungen ausgeführt.

Selbst wenn Sie Dienstprinzipalprofile verwenden, um die Daten Ihrer Kund*innen zu trennen, können Sie RLS innerhalb des Semantikmodells einzelner Kund*innen verwenden, um verschiedenen Gruppen Zugriff auf verschiedene Teile der Daten zu gewähren. Sie können z. B. RLS verwenden, um zu verhindern, dass Mitglieder einer Abteilung auf Daten einer anderen Abteilung in derselben Organisation zugreifen.

Überlegungen und Einschränkungen

  • Dienstprinzipalprofile werden nur über die Power BI REST API und das Power BI .NET SDK unterstützt. Dienstprinzipalprofile werden in Power BI nicht über den XMLA-Endpunkt oder das tabellarische Objektmodell (Tabular Object Model, TOM) unterstützt.
  • Dienstprinzipalprofile werden im Liveverbindungsmodus nicht zusammen mit Azure Analysis Services (AAS) unterstützt.

Einschränkungen der Power BI-Kapazität

Verwalten von Dienstprinzipalen

Ändern eines Dienstprinzipals

In Power BI gehört ein Profil zum Dienstprinzipal, der es erstellt hat. Das bedeutet, dass ein Profil nicht für andere Prinzipale freigegeben werden kann. Wenn Sie den Dienstprinzipal aus irgendeinem Grund ändern möchten, müssen Sie aufgrund dieser Einschränkung alle Profile neu erstellen und den neuen Profilen Zugriff auf die relevanten Arbeitsbereiche erteilen. Oftmals muss die ISV-Anwendung eine Zuordnung zwischen einer Profil-ID und einer Kunden-ID speichern, um bei Bedarf das richtige Profil auszuwählen. Wenn Sie den Dienstprinzipal ändern und die Profile neu erstellen, ändern sich auch die IDs, und Sie müssen möglicherweise die Zuordnung in der ISV-Anwendungsdatenbank aktualisieren.

Löschen eines Dienstprinzipals

Warnung

Gehen Sie beim Löschen eines Dienstprinzipals sehr umsichtig vor. Sie möchten es vermeiden, versehentlich Daten aus allen seinen zugeordneten Profilen zu verlieren.

Wenn Sie den Dienstprinzipal im aktiven Verzeichnis löschen, werden alle seine Profile in Power BI gelöscht. Power BI löscht die Inhalte jedoch nicht sofort, sodass der Mandantenadministrator weiterhin auf die Arbeitsbereiche zugreifen kann. Gehen Sie beim Löschen eines Dienstprinzipals, der in einem Produktionssystem verwendet wird, mit Bedacht vor, insbesondere, wenn Sie in Power BI Profile mithilfe dieses Dienstprinzipals erstellt haben. Wenn Sie trotzdem einen Dienstprinzipal löschen, der Profile erstellt hat, seien Sie sich bewusst, dass Sie alle Profile neu erstellen, dem neuen Profil Zugriff auf die relevanten Arbeitsbereiche erteilen und die Profil-IDs in der ISV-Anwendungsdatenbank aktualisieren müssen.

Datentrennung

Wenn Daten nach Dienstprinzipalprofilen getrennt werden, verhindert eine einfache Zuordnung zwischen einem Profil und einem Kunden, dass ein Kunde die Inhalte eines anderen Kunden sehen kann. Die Verwendung eines einzelnen Dienstprinzipals erfordert, dass der Dienstprinzipal Zugriff auf alle verschiedenen Arbeitsbereiche in allen Profilen hat.

Wenn Sie zusätzliche Trennung hinzufügen möchten, weisen Sie jedem Mandanten einen separaten Dienstprinzipal zu, anstatt einen einzigen Dienstprinzipal mit verschiedenen Profilen auf mehrere Arbeitsbereiche zugreifen zu lassen. Das Zuweisen separater Dienstprinzipale hat mehrere Vorteile, darunter:

  • Menschliches Versagen oder ein Leck in den Zugangsdaten führt nicht dazu, dass die Daten mehrerer Mieter offengelegt werden.
  • Zertifikatrotation kann separat für jeden Mandanten erfolgen.

Die Verwendung mehrerer Dienstprinzipale bringt jedoch hohe Verwaltungskosten mit sich. Entscheiden Sie sich nur für diesen Pfad, wenn Sie die zusätzliche Trennung benötigen. Bedenken Sie, dass die Konfiguration, die festlegt, welche Daten einem Endbenutzer angezeigt werden, beim Generieren des Einbettungstokens erfolgt. Dies ist ein reiner Back-End-Prozess, der von Endbenutzern weder angezeigt noch geändert werden kann. Beim Anfordern eines Einbettungstokens mithilfe eines mandantenspezifischen Profils wird ein Einbettungstoken für dieses bestimmte Profil generiert, durch das Sie bei der Nutzung Kundentrennung erhalten.

Ein Bericht, mehrere Semantikmodelle

Im Allgemeinen haben Sie einen Bericht und ein Semantikmodell pro Mandant. Bei hunderten von Berichten sind das hunderte Semantikmodelle. Manchmal haben Sie unter Umständen ein Berichtsformat mit verschiedenen Semantikmodelle (z. B. verschiedene Parameter oder Verbindungsdetails). Für jede neue Version des Berichts müssen Sie alle Berichte für alle Mandanten aktualisieren. Das lässt sich zwar automatisieren, mit nur einer Kopie des Berichts ist die Verwaltung aber einfacher. Erstellen Sie einen Arbeitsbereich, der den einzubettenden Bericht enthalten soll. Während der Sitzungslaufzeit binden Sie den Bericht an das mandantenspezifische Semantikmodell. Mehr dazu erfahren Sie unter dynamische Bindungen.

Anpassen und Erstellen von Inhalten

Bedenken Sie beim Erstellen von Inhalten sorgfältig, wer die Berechtigung zur Bearbeitung innehat. Wenn Sie mehreren Benutzer*innenn in jedem Mandanten das Bearbeiten erlauben, können Beschränkungen des Semantikmodells leicht überschritten werden. Wenn Sie sich entscheiden, Benutzern die Bearbeitung zu ermöglichen, sollten Sie ihre Inhaltserstellung engmaschig überwachen und bei Bedarf hochskalieren. Aus denselben Gründen wird davon abgeraten, diese Funktion für die Personalisierung von Inhalten zu nutzen, bei der jeder Benutzer kleine Änderungen an einem Bericht vornehmen und ihn zur eigenen Verwendung speichern kann. Wenn die ISV-Anwendung die Personalisierung von Inhalten zulässt, sollten Sie die Einführung von Aufbewahrungsrichtlinien für Arbeitsbereiche für benutzerspezifische Inhalte in Erwägung ziehen. Aufbewahrungsrichtlinien erleichtern das Löschen von Inhalten, wenn Benutzer zu einer neuen Position wechseln, das Unternehmen verlassen oder die Nutzung der Plattform beenden.

Systemseitig verwaltete Identität

Anstelle eines Dienstprinzipals können Sie eine benutzerseitig oder systemseitig zugewiesene verwaltete Identität verwenden, um Profile zu erstellen. Durch verwaltete Identitäten verringert sich die Notwendigkeit von Geheimnissen und Zertifikaten.

Seien Sie beim Nutzen systemseitig verwalteter Identität vorsichtig, denn diese Punkte sind zu beachten:

  • Wenn eine vom System zugewiesene verwaltete Identität versehentlich deaktiviert wird, verlieren Sie den Zugriff auf die Profile. Diese Situation ähnelt einem Fall, in dem ein Dienstprinzipal gelöscht wird.
  • Eine systemseitig zugewiesene verwaltete Identität ist mit einer Ressource in Azure (Web App) verbunden. Wenn Sie die Ressource löschen, wird die Identität gelöscht.
  • Die Verwendung mehrerer Ressourcen (verschiedene Web-Apps in verschiedenen Regionen) führt zu mehreren Identitäten, die separat verwaltet werden müssen (jede Identität verfügt über eigene Profile).

Aufgrund der oben genannten Überlegungen empfiehlt es sich, eine benutzerseitig zugewiesene verwaltete Identität zu verwenden.

Beispiel

Ein Beispiel für die Verwendung von Dienstprinzipalprofilen zum Verwalten einer mehrinstanzenfähigen Umgebung mit Power BI und App-Owns-Data-Einbettung finden Sie unter Power BI Dev Camp (Website eines Drittanbieters) das App-eigene Datenrepository.

Zugehöriger Inhalt