Power BI-Implementierungsplanung: Überwachung auf Mandantenebene

Hinweis

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

Dieser Artikel zur Überwachungsplanung auf Mandantenebene richtet sich hauptsächlich an folgende Gruppen:

• Power BI-Administrator*innen: Administrator*innen, die für die Überwachung von Power BI in der Organisation verantwortlich sind. Power BI-Administrator*innen müssen möglicherweise mit Teams für IT, Sicherheit, interne Überwachung und anderen relevanten Teams zusammenarbeiten.
• 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 und anderen relevanten Teams zusammenarbeiten.

Wichtig

Es wird empfohlen, den Power BI-Releaseplan genau zu befolgen, um sich über zukünftige Verbesserungen der Überwachungsfunktionen zu informieren.

Der Zweck einer Überwachungslösung auf Mandantenebene besteht darin, Daten für alle Benutzer, Aktivitäten und Lösungen zu erfassen und zu analysieren, die in einem Power BI-Mandanten bereitgestellt werden. Diese Überwachungsdaten auf Mandantenebene sind für viele Zwecke nützlich und ermöglichen Ihnen die Analyse von Einführungsbemühungen, das Verstehen von Nutzungsmustern, das Schulen und zielgerichtete Unterstützen von Benutzern, das Vermindern von Risiken, das Verbessern der Compliance, die Verwaltung von Lizenzkosten und die Überwachung der Leistung.

Das Erstellen einer End-to-End-Überwachungslösung, die sicher und produktionsbereit ist, ist ein wichtiges Projekt, das Zeit in Anspruch nimmt. Stellen Sie es sich als das Erstellen von Business Intelligence für Business Intelligence (BI on BI) vor. Informationen dazu, warum die Überwachungsdaten so wertvoll sind, finden Sie unter Übersicht zur Überwachung.

Informationen zur Überwachung auf Berichtebene, die sich an Berichtersteller wendet, finden Sie unter Überwachung auf Berichtebene.

Informationen zum Überwachen von Datenressourcen, die sich auf Datenersteller richtet, finden Sie unter Überwachung auf Datenebene.

Im weiteren Verlauf dieses Artikels liegt der Schwerpunkt auf der Überwachung auf Mandantenebene.

Tipp

Der Hauptfokus dieses Artikels liegt darauf, Sie bei der Planung einer End-to-End-Überwachungslösung zu unterstützen. Da die Inhalte in diesem Artikel in vier Phasen aufgeteilt sind, benötigen Sie Informationen zu mehreren Phasen. Beispielsweise finden Sie in Phase 1 Informationen zur Planung der Verwendung eines Dienstprinzipals sowie Informationen zu Voraussetzungen und Setup in Phase 2.

Daher empfehlen wir Ihnen, zuerst den gesamten Artikel zu lesen, damit Sie mit den Inhalten vertraut sind. Dann sollten Sie gut vorbereitet sein, um Ihre Überwachungslösung iterativ zu planen und zu erstellen.

Wenn Sie die Erstellung einer Überwachungslösung auf Mandantenebene planen, berücksichtigen Sie Zeitaufwand für die folgenden vier Phasen.

• Phase 1: Planung und Entscheidungen
  • Anforderungen und Prioritäten
  • Datenanforderungen
  • Typ der Überwachungslösung
  • Berechtigungen und Zuständigkeiten
  • Technische Entscheidungen
  • Entscheidungen zu Datenquellen
• Phase 2: Voraussetzungen und Setup
  • Speicherkonto erstellen
  • Installieren von Software und Einrichten von Diensten
  • Registrieren einer Microsoft Entra-App
  • Festlegen von Power BI-Mandanteneinstellungen
• Phase 3: Entwicklung und Analyse von Lösungen
  • Extrahieren und Speichern der Rohdaten
  • Erstellen der kuratierten Daten
  • Erstellen eines Datenmodells
  • Verbessern des Datenmodells
  • Erstellen von Analyseberichten
  • Ergreifen von Maßnahmen auf Grundlage der Daten
• Phase 4: Verwalten, Verbessern und Überwachen
  • Operationalisieren und Verbessern
  • Dokumentation und Support
  • Aktivieren von Warnungen
  • Kontinuierliche Verwaltung

Phase 1: Planung und Entscheidungen

Die erste Phase konzentriert sich auf die Planung und Entscheidungsfindung. Es gibt viele Anforderungen und Prioritäten zu berücksichtigen, daher empfehlen wir Ihnen, genügend Zeit aufzuwenden, um die in diesem Abschnitt vorgestellten Themen zu verstehen. Dies geschieht mit dem Ziel, gute Vorentscheidungen zu treffen, damit die nachgelagerten Phasen reibungslos ablaufen.

Anforderungen und Prioritäten

Das Ziel der Anfangsphase besteht im Identifizieren der wichtigsten Punkte. Konzentrieren Sie sich auf die wichtigsten Punkte und darauf, wie Sie die Auswirkungen auf Ihre Organisation messen möchten. Sie sollten das Definieren geschäftsorientierter Anforderungen anstelle technologieorientierter Anforderungen in den Mittelpunkt stellen.

Dies sind einige Fragen, auf die Sie eine Antwort finden sollten.

• Welche wichtigen Fragen müssen Sie beantworten? Es gibt eine große Menge von Überwachungsdaten, die Sie untersuchen können. Der effektivste Ansatz für die Überwachung besteht darin, sich auf die Beantwortung spezifischer Fragen zu konzentrieren.
• Was sind Ihre Ziele für Einführung und Datenkultur? Möglicherweise ist eins Ihrer Ziele, die Anzahl der Self-Service-Ersteller von BI-Inhalten in der Organisation zu erhöhen. In diesem Fall müssen Sie Benutzeraktivitäten im Zusammenhang mit dem Erstellen, Bearbeiten und Veröffentlichen von Inhalten messen.
• Welche unmittelbaren Risiken bestehen? Beispielsweise könnte Ihnen bekannt sein, dass es in der Vergangenheit zu übermäßigem Freigeben von Inhalten gekommen ist. Die Benutzerschulung wurde seitdem verbessert, und jetzt möchten Sie Sicherheitseinstellungen und Aktivitäten fortlaufend überwachen.
• Gibt es aktuelle KPIs (Key Performance Indicators) oder Organisationsziele? Möglicherweise verfügen Sie bereits über einen Organisations-KPI, der sich auf die digitale Transformation oder den Weg zu einer stärker datengestützten Organisation bezieht. Überwachungsdaten auf Mandantenebene können Ihnen helfen, zu messen, ob Ihre Power BI-Implementierung diesen Zielen gerecht wird.

Tipp

Prüfen Sie die Überprüfungsanforderungen, und legen Sie mit Ihrem leitenden Sponsor und dem Center of Excellence Prioritäten fest. Es ist verlockend, Überwachungsdaten zu extrahieren und auf der Grundlage der vielen interessanten Daten mit der Erstellung von Berichten zu beginnen. Es ist jedoch unwahrscheinlich, dass Sie großen Nutzen aus Ihrer Überwachungslösung ziehen, wenn sie nicht von Fragen bestimmt wird, die Sie beantworten müssen, und von Maßnahmen, die Sie ergreifen möchten.

Weitere Ideen zur Verwendung von Überwachungsdaten finden Sie unter Übersicht zur Überwachung.

Checkliste: Beim Identifizieren von Anforderungen und Prioritäten zählen diese zu den wichtigsten Entscheidungen und Maßnahmen:

• Identifizieren der Anforderungen: Sammeln und dokumentieren Sie die wichtigsten Geschäftsanforderungen für die Überwachung Ihres Power BI-Mandanten.
• Priorisieren von Anforderungen: Legen Sie Prioritäten für die Anforderungen fest, und klassifizieren Sie sie als unmittelbar, kurzfristig, mittelfristig und langfristig (Überhang).
• Erstellen eines Plans für die unmittelbaren Prioritäten: Richten Sie einen Plan ein, um mit dem Sammeln von Daten zu beginnen, sodass sie bei Bedarf verfügbar sind.
• Regelmäßiges Überprüfen der Anforderungen: Erstellen Sie einen Plan, um Anforderungen regelmäßig neu zu bewerten (z. B. zweimal pro Jahr). Überprüfen Sie, ob die Überwachungslösung den festgelegten Anforderungen gerecht wird. Aktualisieren Sie Aktionselemente Ihres Plans nach Bedarf.

Datenanforderungen

Nachdem Sie die Anforderungen und Prioritäten definiert haben (wie zuvor beschrieben), können Sie die benötigten Daten bestimmen. In diesem Abschnitt werden vier Kategorien von Daten behandelt.

• Benutzeraktivitätsdaten
• Mandantenbestand
• Benutzer- und Gruppendaten
• Sicherheitsdaten

Die meisten der benötigten Daten stammen von den Administrator-APIs, die eine Fülle von Metadaten über den Power BI-Mandanten zur Verfügung stellen. Mehr Informationen dazu finden Sie weiter unten in diesem Artikel unter Auswählen einer Benutzer- oder Administrator-API.

Benutzeraktivitätsdaten

Machen Sie das Erfassen von Daten über Benutzeraktivitäten zu Ihrer obersten Priorität. Die Benutzeraktivitäten, die auch als Ereignisse oder Vorgänge bezeichnet werden, sind für eine Vielzahl von Zwecken nützlich.

Meistens werden diese Daten als Aktivitätsprotokoll oder Ereignisprotokoll bezeichnet. Technisch gesehen gibt es mehrere Möglichkeiten zum Abrufen von Benutzeraktivitätsdaten (das Aktivitätsprotokoll ist eine Methode). Weitere Informationen zu den daran beteiligten Entscheidungen und Aktivitäten finden Sie weiter unten in diesem Artikel unter Zugreifen auf Benutzeraktivitätsdaten.

Hier finden Sie einige allgemeine Fragen, auf die Benutzeraktivitätsdaten eine Antwort geben können.

• Ermitteln der Top-Benutzer und -Inhalte
  • Welche Inhalte werden am häufigsten und von welchen Benutzern angezeigt?
  • Welche täglichen, wöchentlichen und monatlichen Trends bestehen beim Anzeigen von Inhalten?
  • Gehen Berichtsaufrufe im Trend nach oben oder unten?
  • Wie viele Benutzer sind aktiv?
• Verständnis des Benutzerverhaltens
  • Welche Art von Sicherheit wird am häufigsten verwendet (Apps, Arbeitsbereiche oder elementweise Freigabe)?
  • Verwenden Benutzer vorwiegend Browser oder mobile Apps?
  • Welche Inhaltsersteller sind besonders aktiv beim Veröffentlichen und Aktualisieren von Inhalten?
  • Welche Inhalte werden wann und von welchen Benutzern veröffentlicht oder aktualisiert?
• Bestimmen von Bildungs- und Schulungsmöglichkeiten für Benutzer
  • Wer gibt (zu viel) aus seinem persönlichen Arbeitsbereich frei?
  • Wer exportiert in erheblichem Umfang?
  • Wer lädt regelmäßig Inhalte herunter?
  • Wer veröffentlicht viele neue Semantikmodelle (früher Datasets genannt)?
  • Wer nutzt Abonnements stark?
• Verbessern der Governance- und Compliancebemühungen
  • Wann werden Mandanteneinstellungen geändert, und von welchem Power BI-Administrator?
  • Wer hat eine Power BI-Testversion gestartet?
  • Auf welche Inhalte wird von externen Benutzern zugegriffen, vom wem, wann und wie?
  • Wer hat eine Vertraulichkeitsbezeichnung hinzugefügt oder aktualisiert?
  • Welcher Prozentsatz der Berichtsaufrufe basiert auf zertifizierten Semantikmodellen?
  • Welcher Prozentsatz von Semantikmodellen unterstützt mehr als einen Bericht?
  • Wann wird ein Gateway oder eine Datenquelle erstellt oder aktualisiert und von welchem Benutzer?

Weitere Informationen zur Verwendung dieser Daten finden Sie unter Grundlegendes zu Nutzungsmustern.

Wichtig

Wenn Sie noch keine Daten zu Benutzeraktivitäten extrahieren und speichern, sollten Sie dies zu einer dringenden Priorität machen. Stellen Sie zumindest sicher, dass Sie die Rohdaten extrahieren und an einem sicheren Ort speichern. Auf diese Weise sind die Daten verfügbar, wenn Sie bereit sind, sie zu analysieren. Der Verlauf ist je nach verwendeter Quelle 30 Tage oder 90 Tage lang verfügbar.

Mehr Informationen dazu finden Sie weiter unten in diesem Artikel unter Zugreifen auf Benutzeraktivitätsdaten.

Mandantenbestand

Oftmals liegt die zweite Priorität auf dem Abrufen von Daten, um einen Mandantenbestand zu erstellen. Manchmal wird dieser als Arbeitsbereichsinventur, Arbeitsbereichsmetadaten oder Mandantenmetadaten bezeichnet.

Ein Mandantenbestand ist eine Momentaufnahme zu einem bestimmten Zeitpunkt. Sie beschreibt, was im Mandanten veröffentlicht wird. Der Mandantenbestand enthält weder die eigentlichen Daten noch die tatsächlichen Berichte. Vielmehr handelt es sich um Metadaten, die alle Arbeitsbereiche und ihre Elemente (z. B. Semantikmodelle und Berichte) beschreiben.

Hier sehen Sie einige allgemeine Fragen, auf die der Mandantenbestand eine Antwort geben kann.

• Verstehen, wie viele Inhalte Sie wo haben
  • Welche Arbeitsbereiche haben den meisten Inhalt?
  • Welche Art von Inhalten wird in den einzelnen Arbeitsbereichen veröffentlicht (insbesondere, wenn Berichtsarbeitsbereiche und Datenarbeitsbereiche getrennt werden)?
  • Welche Abhängigkeiten bestehen zwischen Elementen (z. B. Dataflows, die viele Semantikmodelle unterstützen, oder ein Semantikmodell, das als Quelle für andere zusammengesetzte Modelle fungiert)?
  • Was ist die Datenherkunft (Abhängigkeiten zwischen Power BI-Elementen, einschließlich externer Datenquellen)?
  • Gibt es verwaiste Berichte (die von ihrem Semantikmodell getrennt sind)?
• Grundlegendes zum Verhältnis zwischen Semantikmodellen und Berichten
  • In welchem Umfang werden Semantikmodelle wiederverwendet?
  • Gibt es doppelte oder sehr ähnliche Semantikmodelle?
  • Gibt es Möglichkeiten, Semantikmodelle zu konsolidieren?
• Grundlegendes zu Trends zwischen Zeitpunkten
  • Nimmt die Anzahl der Berichte im Lauf der Zeit zu?
  • Nimmt die Anzahl von Semantikmodellen im Lauf der Zeit zu?
• Aufspüren nicht verwendeter Inhalte
  • Welche Berichte werden nicht genutzt (oder unzureichend genutzt)?
  • Welche Semantikmodelle werden nicht (oder zu wenig) genutzt?
  • Gibt es Möglichkeiten, Inhalte zurückzuziehen?

Ein Mandantenbestand hilft Ihnen, bei der Analyse von historischen Aktivitäten aktuelle Namen zu verwenden. Die Momentaufnahme der Elemente in Ihrem Mandanten enthält die Namen aller Elemente zu diesem Zeitpunkt. Es ist nützlich, für verlaufsbezogene Berichte aktuelle Elementnamen zu verwenden. Wenn ein Bericht beispielsweise vor drei Monaten umbenannt wurde, zeichnet das Aktivitätsprotokoll den alten Berichtsnamen zu diesem Zeitpunkt auf. Bei einem ordnungsgemäß definierten Datenmodell können Sie den neuesten Mandantenbestand verwenden, um ein Element anhand seines aktuellen Namens (anstelle des früheren Namens) aufzufinden. Mehr Informationen dazu finden Sie weiter unten in diesem Artikel unter Erstellen eines Datenmodells.

Weitere Informationen zur Verwendung eines Mandantenbestands finden Sie unter Grundlegendes zu veröffentlichten Inhalten.

Tipp

Sie verwenden häufig die Kombination der Benutzeraktivitätsereignisse (die im vorherigen Abschnitt beschrieben wurden) mit dem Mandantenbestand, um ein vollständiges Bild zu erstellen. Auf diese Weise steigern Sie den Wert aller Daten.

Da ein Mandantenbestand eine Momentaufnahme zu einem bestimmten Zeitpunkt ist, müssen Sie entscheiden, wie häufig die Metadaten extrahiert und gespeichert werden sollen. Eine wöchentliche Momentaufnahme ist nützlich, um Vergleiche zwischen den beiden Zeitpunkten anzustellen. Wenn Sie beispielsweise die Sicherheitseinstellungen für einen Arbeitsbereich untersuchen möchten, benötigen Sie die Momentaufnahme des vorherigen Mandantenbestands, die Ereignisse des Aktivitätsprotokolls und die aktuelle Momentaufnahme des Mandantenbestands.

Zum Erstellen eines Mandantenbestands gibt es in der Hauptsache zwei Möglichkeiten. Weitere Informationen zu den daran beteiligten Entscheidungen und Aktivitäten finden Sie weiter unten in diesem Artikel unter Zugreifen auf Mandantenbestandsdaten.

Benutzer- und Gruppendaten

Wenn Ihre analytischen Anforderungen steigen, stellen Sie wahrscheinlich fest, dass Sie Daten zu Benutzern und Gruppen in Ihre End-to-End-Überwachungslösung einbeziehen möchten. Zum Abrufen dieser Daten können Sie Microsoft Graph verwenden, die maßgebliche Quelle für Informationen zu Benutzer*innen und Gruppen von Microsoft Entra ID (ehemals Azure Active Directory).

Daten, die von den Power BI-REST-APIs abgerufen werden, beinhalten eine E-Mail-Adresse zur Beschreibung des Benutzers oder den Namen einer Sicherheitsgruppe. Diese Daten stellen eine Momentaufnahme zu einem bestimmten Zeitpunkt dar.

Hier sehen Sie einige der allgemeinen Fragen, auf die Microsoft Graph eine Antwort geben kann.

• Identifizieren von Benutzern und Gruppen
  • Wie lauten der vollständige Benutzername (zusätzlich zur E-Mail-Adresse), die Abteilung oder der Standort, die aus ihrem Benutzerprofil stammen?
  • Wer sind die Mitglieder einer Sicherheitsgruppe?
  • Wer ist der Besitzer einer Sicherheitsgruppe (zum Verwalten von Mitgliedern)?
• Abrufen zusätzlicher Benutzerinformationen
  • Welche Lizenzen – Power BI Pro- oder Power BI Premium-Einzelbenutzerlizenz (PPU) – sind den Benutzern zugewiesen?
  • Welche Benutzer melden sich am häufigsten an?
  • Welche Benutzer haben sich in letzter Zeit nicht beim Power BI-Dienst angemeldet?

Warnung

Einige ältere Methoden (die online ausführlich dokumentiert sind) für den Zugriff auf Benutzer- und Gruppendaten sind veraltet und sollten nicht verwendet werden. Verwenden Sie nach Möglichkeit Microsoft Graph als autoritative Quelle für Benutzer- und Gruppendaten.

Weitere Informationen und Empfehlungen zum Zugriff auf Daten aus Microsoft Graph finden Sie weiter unten in diesem Artikel unter Zugreifen auf Benutzer- und Gruppendaten.

Sicherheitsdaten

Möglicherweise besteht für Sie die Anforderung, regelmäßig Sicherheitsüberwachungen durchführen.

Hier sehen Sie einige allgemeine Fragen, auf die Power BI-REST-APIs eine Antwort geben können.

• Identifizieren von Personen und Anwendungen
  • Auf welche Berichte hat ein Benutzer, eine Gruppe oder einen Dienstprinzipal Zugriff?
  • Welche Benutzer, Gruppen oder Dienstprinzipale sind Abonnenten für den Empfang von Berichten mit einem E-Mail-Abonnement?
• Grundlegendes zu Inhaltsberechtigungen
  • Welche Arbeitsbereichsrollen sind welchen Benutzern und Gruppen zugewiesen?
  • Welche Benutzer und Gruppen sind den einzelnen Power BI-App-Zielgruppen zugewiesen?
  • Welche Elementberechtigungen sind welchen Benutzern für welche Berichte zugewiesen?
  • Welche Elementberechtigungen sind welchen Benutzer*innen für welche Semantikmodelle zugewiesen?
  • Für welche Semantikmodelle und Datamarts ist Sicherheit auf Zeilenebene (RLS) definiert?
  • Welche Elemente sind für Personen in der gesamten Organisation freigegeben?
  • Welche Elemente sind öffentlich zugänglich im Internet veröffentlicht?
• Grundlegendes zu weiteren Berechtigungen
  • Wer hat die Berechtigung zum Veröffentlichen mithilfe einer Bereitstellungspipeline?
  • Wer hat die Berechtigung zum Verwalten von Gateways und Datenverbindungen?
  • Wer hat die Berechtigung zum Verwalten einer Premium-Kapazität?

Tipp

Weitere Überlegungen zur Sicherheit finden Sie in den Artikeln zur Sicherheitsplanung.

Diese allgemeinen Fragen stellen keine vollständige Liste dar. Es steht eine Vielzahl von Power BI-REST-APIs zur Verfügung. Weitere Informationen finden Sie unter Verwenden der Power BI-REST-APIs.

Weitere Informationen zur Verwendung der Administrator-APIs im Vergleich zu Benutzer-APIs (einschließlich der Auswirkungen auf Berechtigungen, die für den Benutzer erforderlich sind, der die Daten extrahiert), finden Sie weiter unten in diesem Artikel unter Auswählen einer Benutzer-API oder Administrator-API.

Checkliste: Bei der Identifizierung der Daten, die für die Überwachung benötigt werden, sind diese wichtigen Entscheidungen zu treffen und Aktionen auszuführen:

• Identifizieren spezifischer Datenanforderungen für Benutzeraktivitätsdaten: Überprüfen Sie die Anforderungen, die Sie gesammelt haben. Ermitteln Sie, welche Überwachungsdaten erforderlich sind, um die einzelnen Anforderungen an Benutzeraktivitätsdaten zu erfüllen.
• Identifizieren spezifischer Datenanforderungen für Mandantenbestandsdaten: Überprüfen Sie die Anforderungen, die Sie gesammelt haben. Ermitteln Sie, welche Überwachungsdaten zum Kompilieren eines Mandantenbestands erforderlich sind.
• Identifizieren spezifischer Datenanforderungen für Benutzer- und Gruppendaten: Überprüfen Sie die Anforderungen, die Sie gesammelt haben. Ermitteln Sie, welche Überwachungsdaten erforderlich sind, um die einzelnen Anforderungen an Benutzer- und Gruppendaten zu erfüllen.
• Identifizieren spezifischer Datenanforderungen für Sicherheitsdaten: Überprüfen Sie die Anforderungen, die Sie gesammelt haben. Ermitteln Sie, welche Überwachungsdaten erforderlich sind, um die einzelnen Anforderungen an Sicherheitsdaten zu erfüllen.
• Überprüfen von Prioritäten: Überprüfen Sie die Reihenfolge der Prioritäten, damit Sie wissen, was zuerst entwickelt werden muss.
• Entscheidung, wie oft Aktivitäten erfasst werden sollen: Entscheiden Sie, wie häufig Aktivitätsereignisse erfasst werden sollen (z. B. einmal pro Tag).
• Entscheidung, wie oft Momentaufnahmen erfasst werden sollen: Entscheiden Sie, in welchem Intervall Momentaufnahmedaten erfasst werden sollen, etwa ein Mandantenbestand oder die Benutzer- und Gruppendaten.

Typ der Überwachungslösung

Die Überwachung auf Mandantenebene erfolgt entweder manuell oder mithilfe automatisierter Prozesse.

Die meisten neuen Überwachungsprozesse beginnen als manueller Prozess, insbesondere während der Entwicklung und während des Testens. Ein manueller Überwachungsprozess kann sich zu einem automatisierten Prozess entwickeln. Allerdings muss nicht jeder Überwachungsprozess vollständig automatisiert sein.

Manuelle Überwachungsprozesse

Die manuelle Überwachung basiert auf Skripts und Prozessen, die von einem Benutzer (normalerweise einem Power BI-Administrator) bei Bedarf ausgeführt werden. Bei Bedarf führt der Benutzer interaktiv Abfragen aus, um Überwachungsdaten abzurufen.

Die manuelle Überwachung eignet sich am besten für:

• Neue Skripts, die entwickelt und getestet werden.
• Gelegentliche, einmalige Überwachungsanforderungen.
• Überwachungsanforderungen zu Untersuchungszwecken.
• Nicht erforderliche Überwachungsprozesse, für die kein vollständiger Support erforderlich ist.

Automatisierte Überwachungsprozesse

Überwachungsdaten, die regelmäßig benötigt werden, sollten automatisiert werden. Sie werden nach einem regelmäßigen Zeitplan extrahiert und verarbeitet; dies wird als automatisierter Prozess bezeichnet. Manchmal tritt dies auch unter der Bezeichnung unbeaufsichtigter Prozess auf.

Die Ziele eines automatisierten Prozesses liegen in der Reduzierung des manuellen Aufwands, der Verringerung des Fehlerrisikos, der Erhöhung der Konsistenz und der Beseitigung der Abhängigkeit von einem einzelnen Benutzer für die Ausführung.

Die automatisierte Überwachung eignet sich am besten für:

• Überwachungsprozesse, die in der Produktion ausgeführt werden.
• Unbeaufsichtigte Prozesse, die regelmäßig ausgeführt werden.
• Skripts, die vollständig getestet wurden.
• Wichtige Überwachungsprozesse, die andere Berichte (oder andere Prozesse) beinhalten, die von ihnen als Datenquelle abhängen.
• Überwachungsprozesse, die dokumentiert sind und unterstützt werden.

Die Art des Prozesses – manuell oder automatisiert – kann sich darauf auswirken, wie Sie die Authentifizierung behandeln. Ein Power BI-Administrator kann beispielsweise die Benutzerauthentifizierung für einen manuellen Überwachungsprozess, aber einen Dienstprinzipal für einen automatisierten Prozess verwenden. Weitere Informationen finden Sie unter Bestimmen der Authentifizierungsmethode weiter unten in diesem Artikel.

Tipp

Wenn es eine regelmäßige, wiederkehrende Notwendigkeit gibt, Überwachungsdaten abzurufen, die derzeit manuell verarbeitet werden, kann es sinnvoll sein, die Zeit zu investieren, um den Vorgang zu automatisieren. Wenn ein Power BI-Administrator beispielsweise jeden Tag manuell ein Skript ausführt, um Daten aus dem Power BI-Aktivitätsprotokoll abzurufen, besteht das Risiko, dass Daten fehlen, falls diese Person krank oder im Urlaub ist.

Checkliste: Bei der Entscheidung für den Typ der zu entwickelnden Überwachungslösung sind diese wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Bestimmen des primären Zwecks für jede neue Überwachungsanforderung: Entscheiden Sie für jede neue Anforderung, ob ein manueller oder automatisierter Prozess verwendet werden soll. Überlegen Sie, ob diese Entscheidung vorübergehend oder dauerhaft ist.
• Erstellen eines Plans für die Automatisierung: Wenn Automatisierung für eine bestimmte Überwachungsanforderung geeignet ist, erstellen Sie einen Plan, wie sie wann und von wem automatisiert werden kann.

Berechtigungen und Zuständigkeiten

An diesem Punkt sollten Sie eine klare Vorstellung davon haben, was Sie erreichen möchten und welche Daten Sie anfänglich benötigen. Jetzt ist ein guter Zeitpunkt, um Entscheidungen über Benutzerberechtigungen sowie Rollen und Zuständigkeiten zu treffen.

Benutzerberechtigungen

Berücksichtigen Sie beim Erstellen einer End-to-End-Überwachungslösung Benutzerberechtigungen für andere Benutzer, die auf die Daten zugreifen müssen. Entscheiden Sie insbesondere, wer auf Überwachungsdaten zugreifen und diese anzeigen darf.

Dies sind einige der Überlegungen, die Sie berücksichtigen sollten.

Direkter Zugriff auf Überwachungsdaten

Sie sollten entscheiden, wer direkt auf die Überwachungsdaten zugreifen kann. Dazu sind mehrere Ansichten möglich.

• Wer sollte Power BI-Administrator sein? Ein Power BI-Administrator hat Zugriff auf alle Mandantenmetadaten, einschließlich der Administrator-APIs. Weitere Informationen zur Entscheidung, wer Power BI-Administrator sein soll, finden Sie unter Sicherheitsplanung auf Mandantenebene.
• Wer kann einen vorhandenen Dienstprinzipal verwenden? Wenn ein Dienstprinzipal (anstelle von Benutzerberechtigungen) für den Zugriff auf Überwachungsdaten verwendet werden soll, muss für autorisierte Benutzer ein Geheimnis angegeben werden, damit sie kennwortbasierte Authentifizierung durchführen können. Der Zugriff auf Geheimnisse (und Schlüssel) sollte sehr streng kontrolliert werden.
• Muss der Zugriff streng kontrolliert werden? In bestimmten Branchen mit gesetzlichen und Compliance-Anforderungen muss der Zugriff strenger kontrolliert werden als in anderen Branchen.
• Gibt es große Aktivitätsdatenvolumen? Es könnte erforderlich sein, genau zu kontrollieren, wer direkt auf die APIs zugreifen darf, die Überwachungsdaten erzeugen, um zu vermeiden, dass API-Drosselungsgrenzwerte erreicht werden. In diesem Fall ist es nützlich, sicherzustellen, dass es keine doppelten oder überlappenden Versuche gibt.

Zugriff auf extrahierte Rohdaten

Sie sollten entscheiden, wer die Rohdaten anzeigen kann, die extrahiert und an einen Speicherort geschrieben werden. In der Regel ist der Zugriff auf Rohdaten auf Administratoren und Prüfer beschränkt. Das Kompetenzzentrum (Center of Excellence, COE) erfordert möglicherweise ebenfalls Zugriff. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Bestimmen des Speicherorts von Überwachungsdaten.

Zugriff auf kuratierte Analysedaten

Sie sollten entscheiden, wer die kuratierten und transformierten Daten anzeigen kann, die für die Analyse bereit sind. Diese Daten sollten immer Administratoren und Prüfern zur Verfügung gestellt werden. Manchmal wird ein Datenmodell anderen Benutzer*innen in der Organisation zur Verfügung gestellt – insbesondere, wenn Sie ein Power BI-Semantikmodell mit Sicherheit auf Zeilenebene erstellen. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Planen der Erstellung kuratierter Daten.

Rollen und Zuständigkeiten

Sobald Sie über die Funktion von Benutzerberechtigungen entschieden haben, sind Sie in einer guten Ausgangsposition, um Überlegungen zu Rollen und Zuständigkeiten anzustellen. Es wird empfohlen, frühzeitig die richtigen Personen einzubeziehen, insbesondere dann, wenn an der Erstellung der End-to-End-Überwachungslösung mehrere Entwickler oder Teams beteiligt sind.

Entscheiden Sie, welche Benutzer oder Teams für die folgenden Aktivitäten zuständig sind.

Rolle	Art der Zuständigkeit	Rolle wird in der Regel ausgeführt von
Kommunikation mit den Beteiligten	Kommunikationsaktivitäten und Sammeln von Anforderungen.	Kompetenzzentrum in Partnerschaft mit der IT. Dies könnte zudem ausgewählte Personen aus wichtigen Geschäftseinheiten einbeziehen.
Festlegen von Prioritäten und Richtung für Anforderungen	Entscheidungsaktivitäten im Zusammenhang mit der End-to-End-Überwachungslösung, einschließlich der Weise, wie die Anforderungen erfüllt werden.	Das Team, das Power BI in der Organisation überwacht, z. B. das Kompetenzzentrum. Leitende Sponsor*innen oder ein Lenkungsausschuss für Data Governance könnten an kritischen Entscheidungen oder der Eskalation von Problemen beteiligt werden.
Extrahieren und Speichern der Rohdaten	Erstellen von Skripts und Prozessen für den Zugriff auf die Daten und ihre Extraktion. Dies umfasst auch das Schreiben der Rohdaten in den Speicher.	Data Engineering-Mitarbeiter, normalerweise aus der IT und in Zusammenarbeit mit dem Kompetenzzentrum.
Erstellen der kuratierten Daten	Datenbereinigung, Transformation und Erstellung der kuratierten Daten in einem Sternschema.	Data Engineering-Mitarbeiter, normalerweise aus der IT und in Zusammenarbeit mit dem Kompetenzzentrum.
Erstellen eines Datenmodells	Erstellen eines analysebasierten Datenmodells auf der Grundlage der kuratierten Daten.	Power BI-Inhaltsersteller, in der Regel aus der IT oder im Kompetenzzentrum.
Erstellen von Analyseberichten	Erstellen von Berichten zur Analyse der kuratierten Daten. Fortlaufende Änderungen an Berichten auf der Grundlage neuer Anforderungen und neuer Überwachungsdaten, wenn diese verfügbar werden.	Power BI-Berichtsersteller, in der Regel aus der IT oder im Kompetenzzentrum.
Analysieren der Daten und Reagieren auf die Ergebnisse	Analysieren der Daten und Reaktion auf die Überwachungsdaten.	Das Team, das Power BI in der Organisation überwacht, in der Regel das Kompetenzzentrum. Kann je nach den Überwachungsergebnissen und der Maßnahme auch weitere Teams umfassen. Zu den weiteren Teams können Sicherheit, Compliance, Recht, Risikomanagement oder Änderungsmanagement gehören.
Testen und Überprüfen	Testen, um sicherzustellen, dass die Überwachungsanforderungen erfüllt und die angezeigten Daten korrekt sind.	Power BI-Inhaltsersteller in Zusammenarbeit mit dem Team, das Power BI in der Organisation überwacht.
Schützen der Daten	Festlegen und Verwalten der Sicherheit für jede Speicherebene, einschließlich der Rohdaten und der kuratierten Daten. Verwalten des Zugriffs auf Semantikmodelle, die zur Analyse der Daten erstellt werden.	Systemadministrator für das System, das die Daten speichert, in Zusammenarbeit mit dem Team, das Power BI in der Organisation überwacht.
Planung und Automatisierung	Operationalisieren einer Lösung und Planen des Prozesses mit dem gewählten Tool.	Data Engineering-Mitarbeiter, normalerweise aus der IT und in Zusammenarbeit mit dem Kompetenzzentrum.
Unterstützung für die Lösung	Überwachen der Überwachungslösung, einschließlich der Ausführung von Aufträgen, Fehler und Support für technische Probleme.	Das Team, das die Power BI-Systemunterstützung innehat, in der Regel die IT oder das Kompetenzzentrum.

Viele der oben genannten Rollen und Zuständigkeiten können konsolidiert werden, wenn sie vom gleichen Team oder derselben Person ausgeführt werden. Beispielsweise können Ihre Power BI-Administratoren einige dieser Rollen ausführen.

Es ist auch möglich, dass verschiedene Personen je nach den Umständen unterschiedliche Rollen ausüben. Maßnahmen sind kontextbezogen und hängen von den Überwachungsdaten und der vorgeschlagenen Maßnahme ab.

Sehen Sie sich einige Beispiele an.

• Beispiel 1: Die Überwachungsdaten zeigen, dass einige Benutzer häufig Daten nach Excel exportieren. Ergriffene Maßnahme: Das Kompetenzzentrum kontaktiert die spezifischen Benutzer, um ihre Bedürfnisse zu verstehen und sie über bessere Alternativen aufzuklären.
• Beispiel 2: Die Überwachungsdaten zeigen, dass der Zugriff externer Benutzer in nicht erwarteter Weise erfolgt. Ergriffene Maßnahmen: Ein*e IT-Systemadministrator*in aktualisiert die relevanten Microsoft Entra ID Einstellungen für den Zugriff externer Benutzer*innen. Der Power BI-Administrator aktualisiert die Mandanteneinstellung, die sich auf den externen Benutzerzugriff bezieht. Das Kompetenzzentrum aktualisiert die Dokumentation und die Schulung für Inhaltsersteller, die die Sicherheit verwalten. Weitere Informationen finden Sie unter Strategie für externe Benutzer.
• Beispiel 3: Die Überwachungsdaten zeigen, dass mehrere Datenmodelle dasselbe Measure unterschiedlich definieren (verfügbar über die Metadatenüberprüfungs-APIs, sofern dies durch die detaillierten Metadaten-Mandanteneinstellungen zulässig ist). Ergriffene Maßnahme: Das Data Governance-Komitee startet ein Projekt zum Festlegen gemeinsamer Definitionen. Das Kompetenzzentrum aktualisiert die Dokumentation und die Schulung für Inhaltsersteller, die Datenmodelle erstellen. Das Kompetenzzentrum arbeitet außerdem nach Bedarf mit Inhaltserstellern zusammen, um ihre Modelle zu aktualisieren. Weitere Informationen zum Abrufen detaillierter Metadaten finden Sie weiter unten in diesem Artikel unter Zugreifen auf Mandantenbestandsdaten.

Hinweis

Das Einrichten von Datenextraktionsprozessen ist in der Regel ein einmaliger Aufwand mit gelegentlichen Verbesserungen und Problembehandlungen. Die Analyse und das Handeln auf der Grundlage der Daten ist ein fortlaufender Aufwand, der kontinuierliche Anstrengungen auf einer wiederkehrenden Basis erfordert.

Checkliste: Die Abwägung von Berechtigungen und Zuständigkeiten beinhaltet die folgenden wichtigen Entscheidungen und Maßnahmen:

• Ermitteln der beteiligten Teams: Bestimmen Sie, welche Teams an der End-to-End-Erstellung und dem Support der Überwachungslösung beteiligt sein sollen.
• Festlegen der Benutzerberechtigungen: Bestimmen Sie, wie die Benutzerberechtigungen für den Zugriff auf Überwachungsdaten eingerichtet werden sollen. Erstellen Sie eine Dokumentation der wichtigsten Entscheidungen für die spätere Bezugnahme.
• Entscheidung über Rollen und Zuständigkeiten: Achten Sie darauf, dass klare Erwartungen dazu bestehen, wer was erledigt, insbesondere wenn mehrere Teams beteiligt sind. Erstellen Sie Dokumentation für Rollen und Zuständigkeiten, die auch erwartete Maßnahmen beinhaltet.
• Zuweisen von Rollen und Zuständigkeiten: Weisen Sie bestimmten Personen oder Teams bestimmte Rollen und Zuständigkeiten zu. Aktualisieren Sie bei Bedarf einzelne Stellenbeschreibungen mit der Personalabteilung.
• Erstellen eines Schulungsplans: Richten Sie einen Plan für die Schulung der Mitarbeiter ein, wenn sie neue Fähigkeiten benötigen.
• Erstellen eines Plans für übergreifende Schulungen: Stellen Sie sicher, dass für Schlüsselrollen übergreifende Schulungen und Stellvertreter vorhanden sind.

Technische Entscheidungen

Wenn Sie eine Überwachungslösung auf Mandantenebene planen, müssen Sie einige wichtige technische Entscheidungen treffen. Zum Verbessern der Konsistenz, Vermeiden von Nacharbeit und Steigern der Sicherheit empfiehlt es sich, diese Entscheidungen so früh wie möglich zu treffen.

In der ersten Planungsphase werden die folgenden Entscheidungen getroffen.

• Auswählen einer Technologie für den Zugriff auf Überwachungsdaten
• Bestimmen der Authentifizierungsmethode
• Auswählen einer Benutzer- oder Administrator-API
• Auswählen von APIs oder PowerShell-Cmdlets
• Bestimmen des Speicherorts von Überwachungsdaten
• Planen der Erstellung kuratierter Daten

Auswählen einer Technologie für den Zugriff auf Überwachungsdaten

Zunächst müssen Sie entscheiden, wie auf die Überwachungsdaten zugegriffen werden soll.

Die einfachste Möglichkeit für den Einstieg besteht darin, die vorab erstellten Berichte zu verwenden, die im Arbeitsbereich für die Administratorüberwachungverfügbar sind.

Wenn Sie direkt auf die Daten zugreifen und eine eigene Lösung erstellen müssen, verwenden Sie eine API (Anwendungsprogrammierschnittstelle). APIs sind für den Austausch von Daten über das Internet ausgelegt. Die Power BI-REST-APIs unterstützen Datenanforderungen mithilfe des HTTP-Protokolls. Power BI-REST-APIs können mit beliebigen Sprachen oder Tools aufgerufen werden, sofern sie in der Lage sind, eine HTTP-Anforderung zu senden und eine JSON-Antwort zu empfangen.

Tipp

Die PowerShell-Cmdlets verwenden die Power BI-REST-APIs für den Zugriff auf die Überwachungsdaten. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Auswählen von APIs oder PowerShell-Cmdlets.

Dieser Abschnitt konzentriert sich auf Ihre Technologieauswahl. Überlegungen zur Quelle für den Zugriff auf bestimmte Arten von Überwachungsdaten finden Sie weiter unten in diesem Artikel unter Entscheidungen zu Datenquellen.

Plattformoptionen

Es gibt viele verschiedene Möglichkeiten, auf Überwachungsdaten zuzugreifen. Je nach der von Ihnen gewählten Technologie können Sie dazu neigen, einer bestimmten Sprache den Vorzug zu geben. Möglicherweise müssen Sie auch eine bestimmte Entscheidung treffen, wie Sie die Ausführung Ihrer Skripts planen. Technologien unterscheiden sich stark in der Lernkurve und der Einfachheit des Einstiegs.

Hier sehen Sie einige Technologien, die Sie zum Abrufen von Daten mithilfe der Power BI-REST-APIs verwenden können.

Technologie	Gute Wahl für manuelle Überwachungsprozesse	Gute Wahl für automatisierte Überwachungsprozesse
Administrator-Überwachungsarbeitsbereich
Try-it
PowerShell
Power BI Desktop
Power Automate
Bevorzugter Azure-Dienst
Bevorzugtes Tool/bevorzugte Sprache
Microsoft Purview-Überwachungsprotokollsuche
Defender-für-Cloud-Apps
Microsoft Sentinel

Der Rest dieses Abschnitts enthält eine kurze Einführung in jede der in der Tabelle dargestellten Optionen.

Administrator-Überwachungsarbeitsbereich

Der Arbeitsbereich für die Administratorüberwachung enthält vordefinierte Berichte und Semantikmodelle im Power BI-Dienst. Dies ist eine bequeme Möglichkeit für Fabric-Administratoren und globale Administratoren, aktuelle Überwachungsdaten anzuzeigen, die ihnen das Verständnis von Benutzeraktivitäten erleichtern.

Try-it in der API-Dokumentation

Try-it ist ein interaktives Tool, mit dem Sie die Power BI-REST-API direkt in der Microsoft-Dokumentation erleben können. Es stellt eine einfache Möglichkeit dar, die APIs zu erkunden, da keine weiteren Tools oder Setups auf Ihrem Computer erforderlich sind.

Sie können Try-it für Folgendes verwenden:

• Manuelles Senden einer Anforderung an eine API, um zu bestimmen, ob sie die gewünschten Informationen zurückgibt.
• Erfahren Sie, wie die URL erstellt wird, bevor Sie ein Skript schreiben.
• Überprüfen von Daten auf informelle Weise.

Hinweis

Sie müssen ein lizenzierter und authentifizierter Power BI-Benutzer sein, um Try-it verwenden zu können. Es folgt dem Standardberechtigungsmodell, was bedeutet, dass die Benutzer-APIs auf Benutzerberechtigungen basieren und die Administrator-APIs Power BI-Administratorberechtigungen erfordern. Sie können sich bei Try-it nicht mit einem Dienstprinzipal authentifizieren.

Da es interaktiv ist, eignet sich Try-it besonders gut zum Lernen, Erkunden und für neue manuelle Überwachungsprozesse.

PowerShell und Azure Cloud Shell

PowerShell-Skripts können auf verschiedene Weise erstellt und ausgeführt werden.

Hier sind mehrere gängige Optionen.

• Visual Studio Code: Ein moderner, schlanker Code-Editor. Er ist ein frei verfügbares Open-Source-Tool, das auf mehreren Plattformen unterstützt wird, einschließlich Windows, macOS und Linux. Sie können Visual Studio Code mit vielen Sprachen verwenden, einschließlich PowerShell (mithilfe der PowerShell-Erweiterung).
• Azure Data Studio: Ein Tool zum Erstellen von Skripts und Notebooks. Es basiert auf Visual Studio Code. Azure Data Studio ist einzeln oder zusammen mit SQL Server Management Studio (SSMS) erhältlich. Es gibt viele Erweiterungen, einschließlich einer Erweiterung für PowerShell.
• Azure Cloud Shell: Eine Alternative zum lokalen Arbeiten mit PowerShell. Sie können über einen Browser auf Azure Cloud Shell zugreifen.
• Azure Functions: Eine Alternative zum lokalen Arbeiten mit PowerShell. Azure Functions ist ein Azure-Dienst, mit dem Sie Code in einer serverlosen Umgebung schreiben und ausführen können. PowerShell ist eine von mehreren unterstützten Sprachen.

Wichtig

Es wird empfohlen, für alle neuen Entwicklungsaufgaben die neueste Version von PowerShell (PowerShell Core) zu verwenden. Sie sollten die Verwendung von Windows PowerShell (das PowerShell Core nicht ausführen kann) nicht fortsetzen und stattdessen einen der modernen Code-Editoren nutzen, die PowerShell Core unterstützen. Achten Sie darauf bei vielen Onlinebeispielen, die Windows PowerShell (Version 5.1) verwenden, da sie möglicherweise nicht die neuesten (und besseren) Codeansätze verwenden.

Sie können PowerShell auf verschiedene Weise verwenden. Weitere Informationen zu dieser technischen Entscheidung finden Sie weiter unten in diesem Artikel unter Auswählen von APIs oder PowerShell-Cmdlets.

Es gibt viele Onlineressourcen für die Verwendung von PowerShell, und oftmals ist es möglich, erfahrene Entwickler zu finden, die PowerShell-Lösungen erstellen und verwalten können. PowerShell ist eine gute Wahl, um sowohl manuelle als auch automatisierte Überwachungsprozesse zu erstellen.

Power BI Desktop

Da Power BI Desktop eine Verbindung mit APIs herstellen kann, sind Sie möglicherweise versucht, es zum Erstellen Ihrer Überwachungslösung zu verwenden. Es gibt jedoch einige erhebliche Nachteile und Schwierigkeiten.

• Ansammeln des Verlaufs: Da das Power BI-Aktivitätsprotokoll Daten von bis zu 30 Tagen enthält, müssen beim Erstellen Ihrer gesamten Überwachungslösung im Lauf der Zeit eine Reihe von Dateien gesammelt werden, in denen alle verlaufsbezogenen Ereignisse gespeichert sind. Das Sammeln von Verlaufsdateien lässt sich mit anderen Tools einfacher erledigen.
• Sichere Verarbeitung von Anmeldeinformationen und Schlüsseln: Viele Lösungen, die Sie online von Communitybloggern finden, sind nicht sicher, da sie Anmeldeinformationen und Schlüssel in Power Query-Abfragen hart in Klartext codieren. Dieser Ansatz ist zwar einfach, wird aber nicht empfohlen, da jeder, der Ihre Power BI Desktop-Datei erhält, die Werte lesen kann. Sie können das Kennwort (bei Verwendung von Benutzerauthentifizierung) oder das Geheimnis (bei Verwendung eines Dienstprinzipals) nicht sicher in Power BI Desktop speichern, es sei denn, Sie tun folgendes:
  • Verwenden eines benutzerdefinierten Connectors, der mit dem Power Query SDK entwickelt wurde. Ein benutzerdefinierter Connector könnte beispielsweise vertrauliche Werte aus Azure Key Vault oder einem anderen Dienst lesen, der den verschlüsselten Wert sicher speichert. Darüber hinaus stehen verschiedene Optionen für benutzerdefinierte Connectors in der globalen Power BI-Community zur Verfügung.
  • Verwenden der Option ApiKeyName, die in Power BI Desktop gut funktioniert. Es ist jedoch nicht möglich, den Schlüsselwert im Power BI-Dienst zu speichern.
• Arten von Anforderungen: Möglicherweise begegnen Sie einigen Einschränkungen für die Ausführung in Power BI Desktop. Beispielsweise unterstützt Power Query nicht jede Art von API-Anforderung. Beispielsweise werden nur GET- und POST-Anforderungen unterstützt, wenn die Web.Contents-Funktion verwendet wird. Für die Überwachung senden Sie in der Regel GET-Anforderungen.
• Möglichkeit zur Aktualisierung: Sie müssen bestimmte Power Query-Entwicklungsmuster befolgen, um ein Semantikmodell im Power BI-Dienst erfolgreich zu aktualisieren. Beispielsweise muss die Option RelativePath bei Verwendung von Web.Contents vorhanden sein, damit Power BI den Speicherort einer Datenquelle ordnungsgemäß überprüfen kann, ohne einen Fehler im Power BI-Dienst zu generieren.

In den meisten Fällen wird empfohlen, Power BI Desktop nur für zwei Zwecke zu verwenden. Sie sollten es für diese Zwecke verwenden:

• Erstellen Ihres Datenmodells auf der Grundlage der vorhandenen kuratierten Daten (anstatt es zur anfänglichen Extraktion der Überwachungsdaten zu verwenden).
• Erstellen von Analyseberichten auf der Grundlage Ihres Datenmodells.

Power Automate

Sie können Power Automate auf vielfältige Weise zusammen mit Power BI verwenden. Im Kontext der Überwachung können Sie Power Automate verwenden, um Anforderungen an die Power BI-REST-APIs zu senden und die extrahierten Daten dann am Speicherort Ihrer Wahl zu speichern.

Tipp

Zum Senden von Anforderungen an die Power BI-REST-APIs können Sie einen benutzerdefinierten Connector für Power Automate verwenden, um die Authentifizierung sicher durchzuführen und Überwachungsdaten zu extrahieren. Alternativ können Sie Azure Key Vault verwenden, um auf ein Kennwort oder Geheimnis zu verweisen. Beide Optionen sind besser als das Speichern von Kennwörtern und Geheimnissen im Klartext innerhalb des Power Automate-Flows.

Suchen Sie in den Power Automate-Vorlagen nach Power BI, um weitere Ideen zur Verwendung von Power Automate zu finden.

Bevorzugter Azure-Dienst

Es gibt mehrere Azure-Dienste, die Anforderungen an die Power BI-REST-APIs senden können. Sie können Ihren bevorzugten Azure-Dienst verwenden, z. B.:

• Azure-Funktionen
• Azure Automation
• Azure Data Factory
• Azure Synapse Analytics

In den meisten Fällen können Sie einen Computedienst, der die Logik für die Datenextraktion verarbeitet, mit einem Speicherdienst kombinieren, der die Rohdaten (und ggf. kuratierte Daten) speichert. Überlegungen zum Treffen von Entscheidungen zur technischen Architektur werden weiter unten in diesem Artikel beschrieben.

Bevorzugtes Tool und/oder bevorzugte Sprache

Sie können Ihr bevorzugtes Tool und Ihre bevorzugte Sprache verwenden, um Anforderungen an die Power BI-REST-APIs zu senden. Dies ist ein guter Ansatz, wenn Ihr Team über Kenntnisse mit einem bestimmten Tool oder einer bestimmten Sprache verfügt, wie etwa:

• Python
• C# im .NET-Framework. Optional können Sie das Power BI .NET SDK verwenden, das als Wrapper auf den Power BI-REST-APIs fungiert, um einige Prozesse zu vereinfachen und die Produktivität zu steigern.
• JavaScript

Microsoft Purview-Überwachungssuche

Das Microsoft Purview-Complianceportal (ehemals Microsoft 365 Compliance Center) beinhaltet eine Benutzeroberfläche, mit der Sie die Überwachungsprotokolle anzeigen und durchsuchen können. Die vereinheitlichten Überwachungsprotokolle beinhalten Power BI und alle anderen Dienste, die die einheitlichen Überwachungsprotokolle von Microsoft 365 unterstützen.

Die im einheitlichen Überwachungsprotokoll erfassten Daten sind genau die gleichen Daten, die im Power BI-Aktivitätsprotokoll enthalten sind. Wenn Sie im Microsoft Purview-Complianceportal eine Überwachungsprotokollsuche durchführen, wird Ihre Anforderung der Warteschlange hinzugefügt. Es kann einige Minuten (oder je nach Datenvolumen länger) dauern, bis die Daten bereit sind.

Hier sehen Sie einige gängige Methoden zur Verwendung des Suchtools für Überwachungsprotokolle. Ihre Möglichkeiten:

• Auswählen der Power BI-Workload, um Ereignisse für eine Reihe von Datumsangaben anzuzeigen.
• Suchen nach einer oder mehreren spezifischen Aktivitäten, z. B.:
  • Power BI-Bericht gelöscht
  • Administratorzugriff auf einen persönlichen Arbeitsbereich in Power BI hinzugefügt
• Anzeigen von Aktivitäten eines oder mehrerer Benutzer.

Für Administratoren mit ausreichenden Berechtigungen ist das Suchtool für Überwachungsprotokolle im Microsoft Purview-Complianceportal eine gute Option für manuelle Überwachungsprozesse. Weitere Informationen finden Sie unter Microsoft Purview-Complianceportal weiter unten in diesem Artikel.

Defender for Cloud Apps-Benutzeroberfläche

Defender for Cloud Apps steht Administratoren und Administratorinnen in Microsoft Defender XDR (Microsoft 365-Portal) zur Verfügung. Es enthält eine Benutzeroberfläche zum Anzeigen und Durchsuchen von Aktivitätsprotokollen für verschiedene Clouddienste, einschließlich Power BI. Es werden die gleichen Protokollereignisse angezeigt, die aus dem Microsoft Purview-Complianceportal stammen, zusätzlich zu anderen Ereignissen wie Benutzeranmeldeaktivitäten aus Microsoft Entra ID.

Die Überwachungsprotokollschnittstelle in Defender for Cloud Apps ist eine gute Option für manuelle Überwachungsprozesse. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Defender for Cloud Apps.

Microsoft Sentinel und KQL

Microsoft Sentinel ist ein Azure-Dienst, mit dem Sie Sicherheitsvorfälle und Bedrohungen erfassen, erkennen, untersuchen und darauf reagieren können. Power BI kann in Microsoft Sentinel als Datenconnector eingerichtet werden, sodass Überwachungsprotokolle aus Power BI in die Microsoft Sentinel Azure-Protokollanalyse gestreamt werden (eine Komponente des Azure Monitor-Diensts). Sie können die Kusto-Abfragesprache (KQL) verwenden, um die Aktivitätsprotokollereignisse zu analysieren, die in Azure Log Analytics gespeichert sind.

Die Verwendung von KQL zum Durchsuchen der Daten in Azure Monitor ist eine gute Option zum Anzeigen eines Teils des Überwachungsprotokolls. Es ist ebenfalls eine gute Option für manuelle Überwachungsprozesse. Weitere Informationen finden Sie weiter unten in diesem Artikel unter Microsoft Sentinel.

Überlegungen zu Plattformen

Hier sehen Sie einige Überlegungen zum Zugriff auf Überwachungsdaten.

• Implementieren Sie einen manuellen oder automatisierten Überwachungsprozess? Bestimmte Tools sind stark an der manuellen oder automatisierten Verarbeitung ausgerichtet. Beispielsweise werden die Try-it-Funktionen von Benutzern immer interaktiv ausgeführt, sodass sie nur für manuelle Überwachungsprozesse geeignet sind.
• Wie soll die Authentifizierung erfolgen? Nicht alle Optionen unterstützen jede Authentifizierungsoption. Beispielsweise unterstützt die Try-it-Funktion nur Benutzerauthentifizierung.
• Wie sollen Anmeldeinformationen sicher gespeichert werden? Verschiedene Technologien bieten unterschiedliche Optionen zum Speichern von Anmeldeinformationen. Weitere Informationen finden Sie unter Bestimmen der Authentifizierungsmethode weiter unten in diesem Artikel.
• Mit welcher Technologie ist Ihr Team bereits vertraut? Wenn es ein Tool gibt, das Ihr Team bevorzugt und gerne verwendet, nehmen Sie es als Ausgangspunkt.
• Wofür kann Ihr Team Support leisten? Wenn ein anderes Team die bereitgestellte Lösung unterstützen soll, überlegen Sie, ob dieses Team dafür angemessenen Support leisten kann. Erwägen Sie auch, ob Ihre internen Teams möglicherweise Support für Entwicklung leisten können, die durch Berater erfolgt.
• Für welches Tool haben Sie eine Genehmigung zur Verwendung? Bestimmte Tools und Technologien müssen möglicherweise genehmigt werden. Dies kann an den Kosten liegen. Es kann aber auch auf IT-Sicherheitsrichtlinien zurückzuführen sein.
• Was ist Ihre Vorliebe für die Planung? Bei einigen Technologien wurde die Entscheidung bereits für Sie getroffen. In anderen Fällen ist dies eine weitere Entscheidung, die Sie treffen müssen. Wenn Sie sich beispielsweise für das Schreiben von PowerShell-Skripts entscheiden, gibt es verschiedene Möglichkeiten, wie Sie die Ausführung dieser Skripts planen können. Wenn Sie dagegen einen Clouddienst wie Azure Data Factory verwenden, ist die Planung integriert.

Es empfiehlt sich, den Rest dieses Artikels zu lesen, bevor Sie eine Technologie für den Zugriff auf Überwachungsdaten auswählen.

Checkliste: Bei der Entscheidung, welche Technologie für den Zugriff auf Überwachungsdaten verwendet werden soll, gehören diese zu den wichtigsten Entscheidungen und Maßnahmen:

• Besprechung mit Ihren IT-Mitarbeitern: Sprechen Sie mit Ihren IT-Teams, um herauszufinden, ob bestimmte Tools genehmigt sind oder bevorzugt werden.
• Erkunden Sie die Optionen mit einem kleinen Proof of Concept (POC): Führen Sie einige Experimente mit einem technischen POC durch. Konzentrieren Sie sich zunächst auf das Lernen. Legen Sie den Schwerpunkt dann auf Ihre Entscheidung, was in Zukunft verwendet werden soll.

Bestimmen der Authentifizierungsmethode

Wie Sie die Authentifizierung einrichten möchten, ist eine kritische Entscheidung. Dies ist häufig einer der schwierigsten Aspekte, wenn Sie mit Überwachung beginnen. Sie sollten die verfügbaren Optionen sorgfältig prüfen, um eine fundierte Entscheidung zu treffen.

Wichtig

Beziehen Sie in dieser Angelegenheit Ihre IT- und Sicherheitsteams ein. Nehmen Sie sich die Zeit, um sich mit den Grundlagen der Funktionsweise der Sicherheit in Microsoft Entra ID vertraut zu machen.

Nicht jede API im Internet erfordert Authentifizierung. Jedoch erfordern alle Power BI-REST-APIs Authentifizierung. Wenn Sie auf Überwachungsdaten auf Mandantenebene zugreifen, wird der Authentifizierungsprozess von der Microsoft Identity Platform verwaltet. Dies ist eine Weiterentwicklung des Microsoft Entra-Identitätsdiensts, der auf Branchenstandardprotokollen basiert.

Tipp

Das Begriffsglossar der Microsoft Identity Platform ist eine Ressource, die Ihnen hilft, sich mit den grundlegenden Konzepten vertraut zu machen.

Bevor Sie Überwachungsdaten abrufen, müssen Sie sich zuerst authentifizieren, was als Anmelden bezeichnet wird. Die Konzepte der Authentifizierung und Autorisierung sind getrennt, aber verwandt. Ein Authentifizierungsprozess überprüft die Identität, wer die Anforderung stellt. Ein Autorisierungsprozess erteilt (oder verweigert) den Zugriff auf ein System oder eine Ressource, indem überprüft wird, wozu der Benutzer oder Dienstprinzipal berechtigt ist.

Wenn sich ein*e Benutzer*in oder ein Dienstprinzipal authentifiziert, wird ein Microsoft Entra-Zugriffstoken für einen Ressourcenserver ausgestellt, z. B. eine Power BI-REST-API oder eine Microsoft Graph-API. Standardmäßig verfällt ein Zugriffstoken nach 1 Stunde. Bei Bedarf kann ein Aktualisierungstoken angefordert werden.

Es gibt zwei Typen von Zugriffstoken:

• Benutzertoken: Wird im Auftrag eines Benutzers mit einer bekannten Identität ausgestellt.
• Nur App-Token: Wird im Auftrag einer Microsoft Entra-Anwendung (Dienstprinzipal) ausgestellt.

Weitere Informationen finden Sie unter Anwendungs- und Dienstprinzipalobjekte in Microsoft Entra ID.

Hinweis

Eine Microsoft Entra-Anwendung ist eine Identitätskonfiguration, die die Integration eines automatisierten Prozesses in Microsoft Entra ID ermöglicht. In diesem Artikel wird sie als App-Registrierung bezeichnet. Der Begriff Dienstprinzipal wird ebenfalls häufig in diesem Artikel verwendet. Diese Begriffe werden weiter unten in diesem Abschnitt ausführlicher beschrieben.

Tipp

Die einfachste Möglichkeit zur Authentifizierung besteht in der Verwendung des Cmdlets Connect-PowerBIServiceAccount aus dem Power BI-Verwaltungsmodul. Möglicherweise werden in Artikeln und Blogbeiträgen online weitere Cmdlets im Zusammenhang mit der Authentifizierung genannt. Beispielsweise gibt es die Cmdlets Login-PowerBI und Login-PowerBIServiceAccount, bei denen es sich um Aliase für das Connect-PowerBIServiceAccount-Cmdlet handelt. Es gibt außerdem das Cmdlet Disconnect-PowerBIServiceAccount , das Sie verwenden können, um sich am Ende eines Prozesses explizit abzumelden.

In der folgenden Tabelle sind die zwei Authentifizierungsoptionen beschrieben.

Typ der Authentifizierung	Beschreibung	Vorgesehen für	Gute Wahl für manuelle Überwachungsprozesse	Gute Wahl für automatisierte Überwachungsprozesse
Benutzerauthentifizierung	Melden Sie sich als Benutzer an, indem Sie den Benutzerprinzipalnamen (E-Mail-Adresse) und ein Kennwort verwenden.	Gelegentliche, interaktive Verwendung
Dienstprinzipalauthentifizierung	Melden Sie sich als Dienstprinzipal an, indem Sie einen geheimen Schlüssel verwenden, der einer App-Registrierung zugewiesen ist.	Laufende, geplante, unbeaufsichtigte Vorgänge

Jede Authentifizierungsoption wird im folgenden Abschnitt ausführlicher beschrieben.

Benutzerauthentifizierung

Die Benutzerauthentifizierung ist in den folgenden Situationen nützlich.

• Manuelle Überwachungsprozesse: Sie möchten ein Skript mit Ihren Benutzerberechtigungen ausführen. Berechtigungen können je nach Typ der API-Anforderung auf einer von zwei Ebenen erteilt werden:
  • Administratorberechtigungen für Administrator-APIs: Sie müssen Ihre Power BI-Administratorberechtigungen verwenden, um eine Anforderung an eine Administrator-API zu senden.
  • Benutzerberechtigungen für Benutzer-APIs: Sie müssen Ihre Power BI-Benutzerberechtigungen verwenden, um eine Anforderung an eine Benutzer-API zu senden. Weitere Informationen finden Sie unter Auswählen einer Benutzer- oder Administrator-API.
• Interaktive Anmeldung: Sie möchten sich interaktiv anmelden, wozu Sie Ihre E-Mail-Adresse und Ihr Kennwort eingeben müssen. Sie müssen sich beispielsweise interaktiv anmelden, um die Try-it-Benutzeroberfläche zu verwenden, die Sie in der Microsoft-API-Dokumentation finden.
• Nachverfolgen, wer auf Mandantenmetadaten zugegriffen hat: Wenn einzelne Benutzer und Administratoren API-Anforderungen senden, sollten Sie überprüfen, wer diese Personen sind. Wenn Sie sich bei einem Dienstprinzipal authentifizieren (im Anschluss beschrieben), ist die vom Aktivitätsprotokoll erfasste Benutzer-ID die Anwendungs-ID. Wenn sich mehrere Administratoren beim gleichen Dienstprinzipal authentifizieren, kann es schwierig sein, zu ermitteln, welcher Administrator auf die Daten zugegriffen hat.
• Gemeinsam verwendetes Administratorkonto: Einige IT-Teams verwenden ein freigegebenes Administratorkonto. Je nachdem, wie dieses implementiert und kontrolliert wird, könnte dies keine Best Practices darstellen. Anstelle eines gemeinsam verwendeten Kontos sollten Sie die Verwendung von Microsoft Entra Privileged Identity Management (PIM) in Betracht ziehen, mit dem Benutzer*innen gelegentlich und vorübergehend Power BI-Administratorrechte erteilt werden können.
• APIs, die nur die Benutzerauthentifizierung unterstützen: Gelegentlich müssen Sie möglicherweise eine API verwenden, die die Authentifizierung durch einen Dienstprinzipal nicht unterstützt. In der Dokumentation ist zu jeder API angegeben, ob sie von einem Dienstprinzipal aufgerufen werden kann.

Wichtig

Es empfiehlt sich, für automatisierte Prozesse nach Möglichkeit die Dienstprinzipalauthentifizierung zu verwenden.

Dienstprinzipalauthentifizierung

Die meisten Organisationen verfügen über einen Microsoft Entra-Mandanten, sodass die Begriffe App-Registrierung und Dienstprinzipal oftmals synonym verwendet werden. Beim Registrieren einer Microsoft Entra-App haben Sie es mit zwei Komponenten zu tun.

• App-Registrierung: Eine App-Registrierung ist global eindeutig. Sie stellt die globale Definition einer registrierten Microsoft Entra-App dar, die von mehreren Mandanten verwendet werden kann. Eine App-Registrierung wird auch als Clientanwendung oder Akteur bezeichnet. Normalerweise impliziert der Begriff Clientanwendung einen Benutzercomputer. Bei App-Registrierungen ist dies jedoch nicht der Fall. Im Azure-Portal finden Sie Microsoft Entra-Apps auf der Seite App-Registrierungen in Microsoft Entra ID.
• Dienstprinzipal: Ein Dienstprinzipal ist die lokale Darstellung der App-Registrierung zur Verwendung in Ihrem spezifischen Mandanten. Der Dienstprinzipal wird von der registrierten Microsoft Entra-App abgeleitet. In Organisationen mit mehreren Microsoft Entra-Mandanten können mehrere Dienstprinzipale auf dieselbe App-Registrierung verweisen. Im Azure-Portal finden Sie Dienstprinzipale auf der Seite Unternehmensanwendungen in Microsoft Entra ID.

Da der Dienstprinzipal die lokale Darstellung ist, ist der Begriff Dienstprinzipalauthentifizierung die gebräuchlichste Bezeichnung für Anmeldungen.

Tipp

Ihr*e Microsoft Entra-Administrator*in kann Ihnen mitteilen, wer in Ihrer Organisation eine App-Registrierung erstellen und ihr zustimmen darf.

Die Dienstprinzipalauthentifizierung ist in den folgenden Situationen nützlich.

• Automatisierte Überwachungsprozesse: Sie möchten einen unbeaufsichtigten Prozess nach einem Zeitplan ausführen.
• Keine Anmeldung beim Power BI-Dienst erforderlich: Sie müssen lediglich eine Verbindung herstellen und Daten extrahieren. Ein Dienstprinzipal kann sich nicht beim Power BI-Dienst anmelden.
• Freigegebener Zugriff auf Daten: Sie (persönlich) sind kein Power BI-Administrator, aber Sie sind berechtigt, einen Dienstprinzipal zu verwenden. Der Dienstprinzipal verfügt über die Berechtigung zum Ausführen von Administrator-APIs zum Abrufen von Daten auf Mandantenebene (oder andere spezifische Berechtigungen).
• Nutzung durch mehrere Administratoren: Sie möchten es mehreren Administratoren oder Benutzern ermöglichen, denselben Dienstprinzipal zu verwenden.
• Technische Blockade: Es gibt eine technische Blockade, die die Verwendung der Benutzerauthentifizierung verhindert. Zu den gängigen technischen Blockaden gehören:
  • Multi-Faktor-Authentifizierung (MFA): Automatisierte Überwachungsprozesse (die unbeaufsichtigt ausgeführt werden) können sich nicht mithilfe eines Benutzerkontos authentifizieren, wenn die Multi-Faktor-Authentifizierung aktiviert ist.
  • Kennworthashsynchronisierung: Microsoft Entra ID erfordert eine Kennworthashsynchronisierung für die Authentifizierung eines Benutzerkontos. In manchen Fällen wird diese Funktionalität möglicherweise durch die IT oder ein Cybersicherheitsteam deaktiviert.

Zweck und Namenskonvention der App-Registrierung

Jede App-Registrierung sollte einen eindeutigen Namen haben, der ihren Zweck und die Zielgruppe (wer die App-Registrierung verwenden kann) beschreibt.

Erwägen Sie die Implementierung einer Benennungskonvention, z. B.: <Workload> – <Zweck> – <Zielgruppe> – <Objekttyp>

Dies sind die Bestandteile der Benennungskonvention.

• Workload: Entspricht in der Regel einer Datenquelle (z. B. Power BI-Daten oder Microsoft Graph-Daten).
• Zweck: Ähnlich der Berechtigungsstufe (z. B. Lesen oder Lese-/Schreibzugriff). Wie unten beschrieben, hilft Ihnen der Zweck, das Prinzip der geringsten Rechte zu befolgen, wenn Sie separate App-Registrierungen erstellen, die Daten nur lesen können.
• Zielgruppe: Optional. Abhängig von der Workload und dem Zweck ermöglicht Ihnen die Zielgruppe, die beabsichtigten Benutzer der App-Registrierung zu bestimmen.
• Objekttyp: EntraApp ist aus Gründen der Übersichtlichkeit enthalten.

Ihre Namenskonvention kann spezifischer sein, wenn Sie über mehrere Mandanten oder mehrere Umgebungen (z. B. Entwicklung und Produktion) verfügen.

Die folgende Tabelle enthält Beispiele für App-Registrierungen, die zum Extrahieren von Überwachungsdaten auf Mandantenebene verwendet werden können:

Name der App-Registrierung	Zweck	Zielgruppe
PowerBIData-Read-AdminAPIs-EntraApp	Mandantenweites Extrahieren von Metadaten für die Überwachung und Verwaltung von Power BI. Administrator-APIs sind immer schreibgeschützt und verfügen möglicherweise nicht über Berechtigungen in Microsoft Entra ID (lediglich Power BI-Mandanteneinstellung).	Power BI-Administratoren und das Kompetenzzentrum
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Verwalten des Power BI-Mandanten. Erfordert Lese-/Schreibberechtigungen zum Erstellen oder Aktualisieren von Ressourcen.	Power BI-Administratoren und das Kompetenzzentrum
GraphData-Read-PowerBIAdministrators-EntraApp	Extrahieren von Benutzer- und Gruppendaten für die Überwachung und Verwaltung von Power BI. Erfordert Leseberechtigungen.	Power BI-Administratoren und das Kompetenzzentrum

Die Verwaltung mehrerer App-Registrierungen für unterschiedliche Zwecke erfordert mehr Aufwand. Jedoch können Sie von mehreren Vorteilen profitieren.

• Erfahren Sie, wofür die App-Registrierung verwendet werden soll und warum: Wenn die Client-ID aus der App-Registrierung in Ihren Überwachungsdaten angezeigt wird, haben Sie eine Vorstellung davon, wofür sie verwendet wurde und warum. Dies ist ein erheblicher Vorteil beim Erstellen separater App-Registrierungen (anstatt nur eine für alle Zwecke zu verwenden).
• Erfahren Sie, von wem die App-Registrierung verwendet werden soll: Wenn die Client-ID aus der App-Registrierung in Ihren Überwachungsdaten angezeigt wird, haben Sie eine Vorstellung davon, wer sie verwendet hat.
• Vermeiden der Überbereitstellung von Berechtigungen: Sie können dem Prinzip der geringsten Rechte folgen, indem Sie separate App-Registrierungen für verschiedene Gruppen von Personen mit unterschiedlichen Anforderungen bereitstellen. Sie können die Überbereitstellung von Berechtigungen vermeiden, indem Sie eine schreibgeschützte App-Registrierung verwenden, wenn keine Schreibberechtigungen erforderlich sind. Beispielsweise verfügen Sie möglicherweise über einige sehr fähige Self-Service-Benutzer*innen, die Daten zu ihren Semantikmodellen sammeln möchten, wofür sie Zugriff auf einen Dienstprinzipal mit Leseberechtigung benötigen. Andererseits gibt es möglicherweise dezentrale Mitglieder des Kompetenzzentrums, die für das Finanzteam arbeiten und Semantikmodelle programmgesteuert verwalten, wofür sie Zugriff auf einen Dienstprinzipal mit Schreibberechtigung benötigen.
• Wissen, wer im Besitz des Geheimnisses sein sollte: Das Geheimnis für jede App-Registrierung sollte nur für die Personen freigegeben werden, die es benötigen. Wenn das Geheimnis rotiert wird (weiter unten in diesem Abschnitt beschrieben), ist die Auswirkung geringer, wenn Sie separate App-Registrierungen für unterschiedliche Anforderungen verwenden. Dies ist nützlich, wenn Sie das Geheimnis rotieren müssen, weil ein Benutzer die Organisation verlässt oder die Rolle wechselt.

App-Registrierungsberechtigungen

Es gibt in der Hauptsache zwei Möglichkeiten, wie eine App-Registrierung auf Daten und Ressourcen zugreifen kann. Sie umfassen Berechtigungen und Zustimmung.

• Nur-App-Berechtigungen: Zugriff und Autorisierung werden vom Dienstprinzipal ohne angemeldeten Benutzer verarbeitet. Diese Authentifizierungsmethode ist für Automatisierungsszenarien nützlich. Wenn Sie Nur-App-Berechtigungen verwenden, ist es wichtig zu verstehen, dass Berechtigungen nicht in Microsoft Entra ID zugewiesen werden. Berechtigungen werden vielmehr auf eine von zwei Arten zugewiesen:
  • Für die Ausführung von Administrator-APIs: Bestimmte Power BI-Mandanteneinstellungen ermöglichen den Zugriff auf die Endpunkte für die Administrator-APIs (die mandantenweite Überwachungsmetadaten zurückgeben). Weitere Informationen finden Sie weiter unten in diesem Artikel unter Festlegen von Power BI-Mandanteneinstellungen.
  • Für die Ausführung von Benutzer-APIs: Es gelten Power BI-Arbeitsbereichs- und Elementberechtigungen. Power BI-Standardberechtigungen steuern, welche Daten an einen Dienstprinzipal zurückgegeben werden können, wenn Benutzer-APIs ausgeführt werden (die Überwachungsdaten auf der Grundlage der Berechtigungen des Benutzers oder Dienstprinzipals zurückgeben, der die API aufruft).
• Delegierte Berechtigungen: Es werden bereichsbasierte Berechtigungen verwendet. Der Dienstprinzipal greift im Namen des derzeit angemeldeten Benutzers auf Daten zu. Dies bedeutet, dass der Dienstprinzipal nicht auf etwas zugreifen kann, auf das der angemeldete Benutzer nicht zugreifen kann. Beachten Sie, dass dies ein anderes Konzept ist als die reine Benutzerauthentifizierung, die zuvor beschrieben wurde. Da eine benutzerdefinierte Anwendung erforderlich ist, um die Kombination von Benutzer- und App-Berechtigungen ordnungsgemäß zu verarbeiten, werden delegierte Berechtigungen selten für Überwachungsszenarien verwendet. Dieses Konzept wird häufig missverstanden, was zu vielen App-Registrierungen mit überdimensionierten Berechtigungen führt.

Wichtig

In diesem Artikel liegt der Schwerpunkt nur auf der Benutzerauthentifizierung oder der Nur-App-Authentifizierung. Delegierte Berechtigungen (mit einem interaktiven Benutzer und dem Dienstprinzipal) können beim programmgesteuerten Einbetten von Power BI-Inhalten eine wichtige Rolle spielen. Es wird jedoch dringend davon abgeraten, delegierte Berechtigungen zum Extrahieren von Überwachungsdaten einzurichten. Die Häufigkeit der Ausführung ist für jede API eingeschränkt (bei aktivierter Drosselung), sodass es nicht praktikabel ist, verschiedene Benutzer direkt auf die Rohdaten der Überwachung zugreifen zu lassen. Stattdessen empfiehlt es sich, die Überwachungsrohdaten einmal zu extrahieren (mit einem zentralisierten Prozess) und dann die kuratierten Überwachungsdaten für nachgelagerte autorisierte Benutzer zur Verfügung zu stellen.

Weitere Informationen finden Sie weiter unten in diesem Artikel unter Registrieren einer Microsoft Entra-App.

App-Registrierungsgeheimnisse

Einer App-Registrierung ist oftmals ein Geheimnis zugewiesen. Das Geheimnis wird als Schlüssel für die Authentifizierung verwendet und weist ein Ablaufdatum auf. Daher müssen Sie planen, wie Sie den Schlüssel regelmäßig rotieren und autorisierten Benutzern den neuen Schlüssel mitteilen.

Sie müssen sich auch um die sichere Aufbewahrung des Geheimnisses kümmern. Ein organisationsweiter Kennworttresor wie Azure Key Vault ist eine ausgezeichnete Wahl.

Tipp

Als Alternative zur Verwendung eines Geheimnisses können Sie eine verwaltete Identität verwenden. Bei einer verwalteten Identität entfällt die Notwendigkeit zur Verwaltung von Anmeldeinformationen. Wenn Sie Dienste wie Azure Functions oder Azure Data Factory zum Extrahieren der Daten verwenden möchten, ist eine verwaltete Identität eine gute Option, die Sie untersuchen sollten.

Sicheres Verwalten von Anmeldeinformationen

Unabhängig davon, ob Sie die Benutzerauthentifizierung oder die Dienstprinzipalauthentifizierung verwenden, ist eine der größten Herausforderungen die sichere Verwaltung von Kennwörtern, Geheimnissen und Schlüsseln.

Achtung

Die erste Regel ist eine, gegen die viele verstoßen: Kennwörter und Schlüssel sollten nie im Klartext in einem Skript vorkommen. Viele Artikel, Blogs und Beispiele, die online zu finden sind, tun dies der Einfachheit halber. Es ist jedoch eine schlechte Praxis, die vermieden werden sollte. Jeder, der in den Besitz des Skripts (oder der Datei) gelangt, kann potenziell Zugriff auf die gleichen Daten erhalten, auf die der Autor Zugriff hat.

Hier sehen Sie mehrere sichere Methoden, mit denen Sie Kennwörter, Geheimnisse und Schlüssel verwalten können.

• Integrieren Sie nach Möglichkeit Azure Key Vault oder ein anderes organisationsweites Kennworttresorsystem.
• Verwenden Sie Anmeldeinformationen und sichere Zeichenfolgen in Ihren PowerShell-Skripts. Anmeldeinformationen funktionieren sowohl für die Benutzerauthentifizierung als auch für die Dienstprinzipalauthentifizierung. Allerdings können Anmeldeinformationen nicht verwendet werden, wenn für ein Benutzerkonto Multi-Faktor-Authentifizierung aktiviert ist.
• Fordern Sie in Ihrem PowerShell-Skript ein Kennwort an, oder verwenden Sie die interaktive Authentifizierung mit einem Browser.
• Verwenden Sie das von Microsoft veröffentlichte Modul zur Geheimnisverwaltung für PowerShell. Es kann Werte mithilfe eines lokalen Tresors speichern. Es kann auch in einen Remote-Azure Key Vault integriert werden, was nützlich ist, wenn mehrere Administratoren in Ihrer Organisation mit denselben Skripts arbeiten.
• Erstellen Sie einen benutzerdefinierten Connector für Power BI Desktop, damit Anmeldeinformationen sicher verarbeitet werden können. Einige benutzerdefinierte Connectors sind von Communitymitgliedern verfügbar (in der Regel auf GitHub).

Tipp

Es empfiehlt sich, Ihre IT- und Sicherheitsteams zu Rate zu ziehen, um die beste Methode auszuwählen oder zu überprüfen, ob Ihre Lösung Anmeldeinformationen auf sichere Weise verwaltet.

Microsoft Authentication Library (MSAL)

Der Support für Azure AD-Authentifizierung Library (ADAL) wurde im Dezember 2022 eingestellt. In Zukunft sollten Sie die Microsoft Authentication Library (MSAL) verwenden. Das Sicherheitsteam in Ihrer Organisation sollte mit dieser wichtigen Änderung vertraut sein.

Zwar ist ein detailliertes Verständnis der Umstellung auf MSAL für Power BI-Experten nicht wichtig, trotzdem sollten Sie sich an die folgenden Empfehlungen halten.

• Verwenden Sie die neueste Version des Power BI-Verwaltungsmoduls, wenn Sie sich mit dem PowerShell-Cmdlet Connect-PowerBIServiceAccount authentifizieren. Es wurde in Version 1.0.946 (26. Februar 2021) von ADAL auf MSAL umgestellt.
• Verwenden Sie den Microsoft Entra V2-Endpunkt, wenn Sie die Authentifizierung direkt in Ihrem Skript vornehmen. Der Microsoft Entra V2-Endpunkt verwendet MSAL, während der Microsoft Entra V1-Endpunkt ADAL verwendet.
• Beenden Sie die Verwendung von APIs und Modulen, die als veraltet gekennzeichnet sind. Weitere Informationen finden Sie weiter unten in diesem Artikel unter veraltete APIs und Module.
• Wenn Sie online eine Communitylösung finden, achten Sie darauf, dass sie MSAL anstelle von ADAL für die Authentifizierung verwendet.

Checkliste: Bei der Entscheidung, wie die Authentifizierung verwaltet werden soll, sind die folgenden wichtigen Entscheidungen und Maßnahmen einzubeziehen:

• Entscheiden Sie, welcher Authentifizierungstyp verwendet werden soll: Bestimmen Sie, ob die Benutzerauthentifizierung oder die Dienstprinzipalauthentifizierung am besten geeignet ist, je nach Art der Überwachungslösung, die Sie erstellen möchten.
• Planen Sie, welche App-Registrierungen Sie benötigen: Berücksichtigen Sie Ihre Anforderungen, Workloads und die Zielgruppe (Benutzer der einzelnen App-Registrierungen). Planen Sie, wie viele App-Registrierungen Sie erstellen müssen, um diese Anforderungen zu erfüllen.
• Erstellen Sie eine Benennungskonvention für App-Registrierungen: Richten Sie eine Benennungskonvention ein, die es Ihnen erleichtert, den beabsichtigten Zweck und die beabsichtigten Benutzer jeder App-Registrierung zu verstehen.
• Planen Sie die sichere Verwaltung von Anmeldeinformationen: Erwägen Sie Möglichkeiten zum sicheren Verwalten von Kennwörtern, Geheimnissen und Schlüsseln. Überlegen Sie, was an Dokumentation und Schulung erforderlich sein könnte.
• Bestätigen Sie die Verwendung von MSAL: Ermitteln Sie, ob noch manuelle oder automatisierte Überwachungslösungen vorhanden sind, die auf ADAL basieren. Erstellen Sie bei Bedarf einen Plan zum Umschreiben dieser Lösungen für die Verwendung der neueren MSAL-Authentifizierungsbibliothek.

Auswählen einer Benutzer- oder Administrator-API

Beim Planen des Abrufens von Überwachungsdaten ist es wichtig, den richtigen API-Typ zu verwenden.

Es müssen zwei Typen von APIs berücksichtigt werden.

• Benutzer-APIs: Stützen sich beim Senden von Anforderungen an die API auf die Berechtigungen des angemeldeten Benutzers (oder Dienstprinzipals). Eine Möglichkeit zum Zurückgeben einer Liste von Semantikmodellen in einem Arbeitsbereich ist beispielsweise eine Benutzer-API. Die Berechtigung zum Lesen von Semantikmodellen kann entweder nach Arbeitsbereichsrolle oder mithilfe elementspezifischer Berechtigungen erteilt werden. Benutzer-APIs können auf zwei Arten ausgeführt werden:
  • Benutzerauthentifizierung: Der angemeldete Benutzer muss über die Berechtigung für den Zugriff auf den Arbeitsbereich oder das Element verfügen.
  • Dienstprinzipalauthentifizierung: Der Dienstprinzipal muss über die Berechtigung für den Zugriff auf den Arbeitsbereich oder das Element verfügen.
• Administrator-APIs: Abrufen von Metadaten beim Mandanten. Das wird manchmal als organisationsweiter Geltungsbereich bezeichnet. Verwenden Sie beispielsweise eine Administrator-API, um eine Liste aller Semantikmodelle im Mandanten zurückzugeben. Administrator-APIs können auf zwei Arten ausgeführt werden:
  • Benutzerauthentifizierung: Der angemeldete Benutzer muss ein Power BI-Administrator sein, um Administrator-APIs ausführen zu können.
  • Dienstprinzipalauthentifizierung: Der Dienstprinzipal muss über die Berechtigung zum Ausführen von Administrator-APIs verfügen (ohne sich auf Sicherheitsberechtigungen wie eine Benutzer-API zu stützen).

Tipp

Alle Administrator-APIs gehören zur Administrator-Vorgangsgruppe. Jede API mit dem Suffix As Admin ist eine Administrator-API. Alle verbleibenden APIs sind Benutzer-APIs.

Stellen Sie sich ein Beispielszenario vor, in dem Sie eine Liste von Semantikmodellen abrufen müssen. In der folgenden Tabelle sind sechs API-Optionen aufgeführt, die Sie dazu verwenden können. Vier Optionen sind Benutzer-APIs, und zwei Optionen sind Administrator-APIs. Der Umfang und die Anzahl der zurückgegebenen Elemente unterscheiden sich je nach ausgewählter API.

API-Name	Art der API	Umfang	Anzahl von Semantikmodellen
Get Dataset	User	Persönlicher Arbeitsbereich	Eine
Get Datasets (Datasets abrufen)	User	Persönlicher Arbeitsbereich	All
Get Dataset in Group	User	Ein Arbeitsbereich	Eins (vorausgesetzt, der angemeldete Benutzer bzw. die angemeldete Benutzerin verfügt über die Berechtigung zum Lesen des Semantikmodells)
Get Datasets in Group	User	Ein Arbeitsbereich	Alle (vorausgesetzt, der angemeldete Benutzer bzw. die angemeldete Benutzerin verfügt über die Berechtigung zum Lesen aller Semantikmodelle)
Get Datasets in Group as Admin	Administrator	Ein Arbeitsbereich	All
Get Datasets as Admin	Administrator	Gesamter Mandant	All

Hinweis

Einige der API-Namen enthalten den Begriff Group als Verweis auf einen Arbeitsbereich. Dieser Begriff stammt aus dem ursprünglichen Power BI-Sicherheitsmodell, das sich auf Microsoft 365-Gruppen stützte. Während sich das Power BI-Sicherheitsmodell im Lauf der Jahre erheblich weiterentwickelt hat, blieben die Namen der vorhandenen APIs unverändert, um zu vermeiden, dass vorhandene Lösungen beschädigt werden.

Informationen zu Mandanteneinstellungen finden Sie weiter unten in diesem Artikel unter Festlegen von Power BI-Mandanteneinstellungen.

Checkliste: Bei der Entscheidung, ob eine Benutzer-API oder eine Administrator-API verwendet werden soll, sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Verweis auf Datenanforderungen: Sammeln und dokumentieren Sie die wichtigsten Geschäftsanforderungen für eine Überwachungslösung. Ermitteln Sie ausgehend vom Typ der benötigten Daten, ob ein Benutzer- oder Organisationsbereich geeignet ist.
• Testen der Ergebnisse: Führen Sie einige Experimente aus. Testen Sie die Genauigkeit der Ergebnisse, die von den verschiedenen APIs zurückgegeben werden.
• Überprüfen von Berechtigungen: Vergewissern Sie sich bei allen vorhandenen Überwachungslösungen, dass Berechtigungen für Power BI-Administratoren und Dienstprinzipale ordnungsgemäß zugewiesen sind. Überprüfen Sie bei neuen Überwachungslösungen, welche Authentifizierungsmethode verwendet werden soll.

Auswählen von APIs oder PowerShell-Cmdlets

Eine wichtige Entscheidung ist, ob PowerShell-Cmdlets verwendet werden sollen, wenn sie für die spezifischen Daten verfügbar sind, die Sie abrufen möchten. Diese Entscheidung ist wichtig, wenn Sie entschieden haben, dass PowerShell eine der Technologien ist, die Sie für den Zugriff auf Überwachungsdaten verwenden möchten.

PowerShell ist eine Lösung für die Automatisierung von Aufgaben. Der Begriff PowerShell ist ein Sammelbegriff, der sich auf die Skriptsprache, eine Befehlszeilenshell-Anwendung und ein Konfigurationsverwaltungs-Framework bezieht. PowerShell Core ist die neueste Version von PowerShell, die unter Windows, Linux und macOS ausgeführt wird.

Ein PowerShell-Cmdlet ist ein Befehl, der eine Aktion ausführt. Ein PowerShell-Modul ist ein Paket, das PowerShell-Elemente wie z. B. Cmdlets, Anbieter, Funktionen, Workflows, Variablen und Aliase enthält. Module werden heruntergeladen und installiert.

Ein PowerShell-Modul erstellt eine Abstraktionsebene über den APIs. Beispielsweise ruft das Cmdlet Get-PowerBIActivityEvent Überwachungsereignisse für einen Power BI-Mandanten ab (oder gettet sie). Dieses PowerShell-Cmdlet ruft seine Daten aus der REST-API zum Abrufen von Aktivitätsereignissen ab. Im Allgemeinen ist der Einstieg mit den Cmdlets einfacher, da sie den Zugriff auf die zugrunde liegenden APIs vereinfachen.

Nur eine Teilmenge der APIs ist in Form von PowerShell-Cmdlets verfügbar. Wenn Sie Ihre gesamte Überwachungslösung ausweiten, werden Sie wahrscheinlich eine Kombination aus Cmdlets und APIs verwenden. Im weiteren Verlauf dieses Abschnitts können Sie entscheiden, wie Sie auf die Daten zugreifen.

PowerShell-Module

Microsoft hat zwei PowerShell-Module veröffentlicht, die Cmdlets enthalten, die sich auf Power BI beziehen. Diese sind das Power BI-Verwaltungsmodul und das Datengatewaymodul. Diese PowerShell-Module fungieren als API-Wrapper oberhalb der zugrunde liegenden Power BI-REST-APIs. Die Verwendung dieser PowerShell-Module kann das Schreiben von Skripts vereinfachen.

Tipp

Zusätzlich zu den von Microsoft veröffentlichten Modulen gibt es frei verfügbare PowerShell-Module und -Skripts (normalerweise auf GitHub), die von Power BI-Communitymitgliedern, Partnern und Microsoft Most Valued Professionals (MVPs) veröffentlicht werden.

Der Einstieg mit einer Communitylösung kann eine wichtige Rolle beim Aufbau Ihrer End-to-End-Überwachungslösung spielen. Wenn Sie sich für eine frei verfügbare Lösung entscheiden, sollten Sie sie unbedingt vollständig testen. Machen Sie sich mit der Funktionsweise vertraut, damit Sie Ihre Lösung im Lauf der Zeit effektiv verwalten können. Ihre IT-Abteilung verfügt möglicherweise über Kriterien für die Verwendung öffentlich verfügbarer Communitylösungen.

Power BI-Verwaltungsmodul

Das Power BI-Verwaltungsmodul ist ein Rollupmodul, das bestimmte Power BI-Module für Verwaltung, Kapazitäten, Arbeitsbereiche und mehr enthält. Sie können das Rollupmodul installieren und so alle Module abrufen, oder Sie können bestimmte Module installieren. Alle Power BI-Verwaltungsmodule werden sowohl in Windows PowerShell als auch in PowerShell Core unterstützt.

Wichtig

Es empfiehlt sich, die Verwendung von Windows PowerShell (das PowerShell Core nicht ausführen kann) einzustellen. Verwenden Sie stattdessen einen der modernen Code-Editoren, die PowerShell Core unterstützen. Die Windows PowerShell ISE (integrierte Skriptumgebung) kann nur PowerShell-Version 5.1 ausführen, die nicht mehr aktualisiert wird. Windows PowerShell ist jetzt veraltet. Daher empfehlen wir, für alle neuen Entwicklungsaufgaben PowerShell Core zu verwenden.

Hier sehen Sie mehrere häufig verwendete Cmdlets, die Sie zum Abrufen von Überwachungsdaten nutzen können.

Verwaltungsmodul	Cmdlet	Zweck
Profil	Connect-PowerBIServiceAccount	Authentifizieren eines Power BI-Benutzers oder -Dienstprinzipals.
Administrator	Get-PowerBIActivityEvent	Anzeigen oder Extrahieren von Power BI-Aktivitätsprotokollereignissen für den Mandanten.
Arbeitsbereiche	Get-PowerBIWorkspace	Kompilieren einer Liste von Arbeitsbereichen.
Berichte	Get-PowerBIReport	Kompilieren einer Liste von Berichten für einen Arbeitsbereich oder Mandanten.
Daten	Get-PowerBIDataset	Kompilieren einer Liste von Semantikmodellen für einen Arbeitsbereich oder Mandanten
Profil	Invoke-PowerBIRestMethod	Senden einer REST-API-Anforderung (Befehl). Dieses Cmdlet ist eine gute Option, da es jede der Power BI-REST-APIs aufrufen kann. Es ist auch eine gute Wahl, wenn Sie die einfachere Form der Authentifizierung mithilfe des Connect-PowerBIServiceAccount-Cmdlets verwenden und in der Lage sein möchten, eine API aufzurufen, der kein entsprechendes PowerShell-Cmdlet zugeordnet ist. Weitere Informationen finden Sie weiter unten in diesem Abschnitt unter Überlegungen zur Verwendung von PowerShell-Cmdlets.

Tipp

Es stehen weitere Cmdlets zum Verwalten und Veröffentlichen von Inhalten zur Verfügung. Der Schwerpunkt dieses Artikels liegt jedoch auf dem Abrufen von Überwachungsdaten.

Sie können das Power BI Management-Modul aus dem PowerShell-Katalog herunterladen. Die einfachste Möglichkeit zum Installieren von Modulen ist die Verwendung von PowerShellGet.

Es wird empfohlen, das Power BI-Verwaltungsrollupmodul zu installieren. Auf diese Weise sind alle Cmdlets verfügbar, die Sie möglicherweise einmal benötigen. Mindestens benötigen Sie das Profilmodul (für die Authentifizierung) und alle spezifischen Module, die die Cmdlets enthalten, die Sie verwenden möchten.

Achtung

Achten Sie darauf, dass Sie die Module auf jedem Server, jedem Benutzercomputer und in jedem Clouddienst (z. B. Azure Automation), auf bzw. in dem Sie PowerShell verwenden, auf dem neuesten Stand halten. Wenn die Module nicht regelmäßig aktualisiert werden, können unvorhersehbare Fehler oder Probleme auftreten. Einige Tools (z. B. Visual Studio Code) helfen Ihnen dabei, die Module auf dem neuesten Stand zu halten. Beachten Sie außerdem, dass PowerShellGet ältere Versionen eines Moduls nicht automatisch deinstalliert, wenn Sie eine neuere Version installieren oder aktualisieren. Es installiert neuere Versionen parallel zu älteren Versionen. Daher empfiehlt es sich, nach installierten Versionen zu suchen und ältere Versionen regelmäßig zu deinstallieren.

Datengatewaymodul

Das Datengateway-Modul enthält Cmdlets, die Daten aus einem lokalen Datengateway und seinen Datenquellen abrufen. Das Data Gateway-Modul wird nur in PowerShell Core unterstützt. Sie wird in Windows PowerShell nicht unterstützt.

Im Gegensatz zum Power BI-Verwaltungsmodul (zuvor beschrieben) enthält das Data Gateway-Modul keine Administrator-Cmdlets. Für viele der Cmdlets (und die entsprechenden Gateway-APIs) ist es erforderlich, dass der Benutzer über Gatewayadministratorrechte verfügt.

Warnung

Es ist nicht möglich, einen Dienstprinzipal als Gatewayadministrator zuzuweisen (selbst wenn der Dienstprinzipal Mitglied einer Sicherheitsgruppe ist). Planen Sie daher die Verwendung von Benutzeranmeldeinformationen beim Abrufen von Informationen zu Datengateways.

Im Folgenden finden Sie mehrere Cmdlets aus dem Data Gateway-Modul, mit denen Sie Überwachungsdaten abrufen können.

Cmdlet	Zweck
Connect-DataGatewayServiceAccount	Authentifizieren eines Power BI-Benutzers (erfordert normalerweise, dass der Benutzer der Rolle „Gatewayadministrator“ angehört).
Get-DataGatewayCluster	Kompilieren einer Liste von Gatewayclustern.
Get-DataGatewayClusterDataSource	Kompilieren einer Liste von Datenquellen für einen Gatewaycluster.
Get-DataGatewayInstaller	Überprüfen, welche Benutzer Gateways in der Organisation installieren und registrieren dürfen.

Sie können das Datengatewaymodul aus dem PowerShell-Katalog herunterladen.

Techniken zur Verwendung von PowerShell

Sie können PowerShell auf verschiedene Weise verwenden. Die Entscheidung, die Sie dazu treffen, ist wichtig.

In der folgenden Tabelle werden drei verschiedene Techniken für die Verwendung von PowerShell beschrieben.

Verfahren	Beschreibung	Beispiel
Verwenden von PowerShell-Cmdlets, um die Authentifizierung zu vereinfachen und APIs direkt aufzurufen. Empfohlener Ansatz	Bei dieser Technik besteht ein Gleichgewicht zwischen Einfachheit und Flexibilität. Das Cmdlet Invoke-PowerBIRestMethod ist im Power BI-Verwaltungsprofilmodul verfügbar. Dieses Cmdlet wird häufig als Schweizer Taschenmesser bezeichnet, da Sie es verwenden können, um jede der Power BI-REST-APIs aufzurufen. Der Vorteil dieser Technik liegt darin, dass Sie die Authentifizierung vereinfachen und dann eine beliebige der Power BI-REST-APIs aufrufen können. Wir empfehlen dringend, diese Technik zu verwenden.	Verwenden Sie nach der Authentifizierung mit dem Cmdlet Connect-PowerBIServiceAccount das Cmdlet Invoke-PowerBIRestMethod, um Daten aus Ihrer bevorzugten API abzurufen (z. B. Get Pipeline Users As Admin).
Weitestmögliche Verwendung von Cmdlets aus PowerShell, sowohl für die Authentifizierung als auch für das Abrufen von Daten.	Bei dieser Technik wird PowerShell umfassend verwendet. PowerShell wird verwendet, um die Ausführung des Skripts zu koordinieren, und PowerShell-Module werden wann immer möglich für den Zugriff auf die Daten verwendet. Dadurch entsteht unter mehreren Aspekten eine größere Abhängigkeit von PowerShell.	Verwenden Sie nach der Authentifizierung mit dem Cmdlet Connect-PowerBIServiceAccount ein Cmdlet (z. B. Get-PowerBIActivityEvent), um Daten abzurufen.
Verwenden von PowerShell nur für die Koordinierung der Prozessausführung. PowerShell-Module werden so wenig wie möglich verwendet.	Bei dieser Technik besteht weniger Abhängigkeit von PowerShell als Tool, da die primäre Nutzung darin besteht, das Aufrufen von API-Aufrufen zu orchestrieren. Nur ein generisches PowerShell-Modul wird für den Zugriff auf APIs verwendet (es wird keins der Module aus den Power BI-Verwaltungsmodulen verwendet).	Rufen Sie nach der Authentifizierung mithilfe der Microsoft Authentication Library (MSAL) Ihre bevorzugte API (z. B. Get Pipeline Users As Admin) auf, indem Sie das generische Cmdlet Invoke-RestMethod verwenden, um Daten abzurufen.

In der Tabelle oben beschreibt die erste Technik einen Ansatz, bei dem Benutzerfreundlichkeit und Flexibilität in Einklang steht. Dieser Ansatz bietet das beste Gleichgewicht für die Bedürfnisse der meisten Organisationen, was der Grund ist, weshalb er empfohlen wird. Einige Organisationen verfügen möglicherweise über vorhandene IT-Richtlinien und Mitarbeiterpräferenzen, die die Entscheidung für die Verwendung von PowerShell beeinflussen.

Tipp

Sie können das PowerShell-Cmdlet Invoke-ASCmd verwenden, um DAX-, XMLA- und TMSL-Skripts zu erstellen und auszuführen. Diese Anwendungsfälle liegen jedoch außerhalb des Bereichs dieses Artikels. Weitere Informationen zum Abfragen dynamischer Verwaltungssichten (DMVs) finden Sie unter Überwachung auf Datenebene.

Technische Benutzer (und Administratoren) können die Power BI-Verwaltungsmodule verwenden, um Daten abzurufen oder bestimmte Aspekte der Inhaltsverwaltung zu automatisieren.

• Für Administratoren: Legen Sie den Parameter -Scope auf Organization fest, um auf Entitäten im gesamten Mandanten zuzugreifen (z. B. um eine Liste aller Arbeitsbereiche abzurufen).
• Für technische Benutzer: Legen Sie den Parameter -Scope auf Individual fest (oder lassen Sie den Parameter weg), um auf Entitäten zuzugreifen, die dem Benutzer gehören (z. B. um eine Liste von Arbeitsbereichen abzurufen, für die der Benutzer eine Zugriffsberechtigung hat).

Stellen Sie sich ein Szenario vor, in dem Sie eine Liste von Semantikmodellen abrufen müssen. Wenn Sie sich für die direkte Arbeit mit den APIs entscheiden, müssen Sie angeben, welche API aufgerufen werden soll. Wenn Sie jedoch das Cmdlet Get-PowerBIDataset verwenden, können Sie den Parameter -Scope so festlegen, dass eine benutzerspezifische oder mandantenweite Liste von Semantikmodellen abgerufen wird. Die Wahl, die Sie treffen, hängt von Ihrer Entscheidung für die Verwendung von PowerShell ab (in der vorherigen Tabelle beschrieben).

In der folgenden Tabelle wird beschrieben, wie die im PowerShell-Cmdlet verwendeten Parameter in die API-PowerShell-Aufrufe übersetzt werden.

Cmdlet-Parameter	API, die das Cmdlet verwendet	Art der API	Bereich	Abgerufene Elemente
-DatasetID {DatasetID} -Scope Individual	Get Dataset	User	Persönlicher Arbeitsbereich	Ein einzelnes Semantikmodell
-Scope Individual	Get Datasets (Datasets abrufen)	User	Persönlicher Arbeitsbereich	Alle Semantikmodelle
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Get Dataset in Group	User	Ein Arbeitsbereich	Ein Semantikmodell (vorausgesetzt, der angemeldete Benutzer bzw. die angemeldete Benutzerin verfügt über die Berechtigung zum Lesen des Semantikmodells)
-GroupID {WorkspaceID}	Get Datasets in Group	User	Ein Arbeitsbereich	Alle Semantikmodelle (vorausgesetzt, der angemeldete Benutzer bzw. die angemeldete Benutzerin verfügt über eine Zugriffsberechtigung für den Arbeitsbereich sowie über eine Leseberechtigung für das Semantikmodell)
-GroupID {WorkspaceID} -Scope Organization	Get Datasets in Group as Admin	Administrator	Ein Arbeitsbereich	Alle Semantikmodelle
-Scope Organization	Get Datasets as Admin	Administrator	Gesamter Mandant	Alle Semantikmodelle

Überlegungen zur Verwendung von PowerShell-Cmdlets

Die Power BI PowerShell-Cmdlets sind einfacher zu verwenden, da sie einen Teil der Komplexität der REST-API-Aufrufe abstrahieren.

Hier sehen Sie einige Möglichkeiten, wie die Cmdlets den Zugriff auf Überwachungsdaten vereinfachen.

• Authentifizierung: Die einfachste Möglichkeit der Authentifizierung in einem PowerShell-Skript besteht darin, das Cmdlet Connect-PowerBIServiceAccount zu verwenden.
• Einfachheit: Der Einstieg ist einfacher, da die Techniken zum Abrufen von Überwachungsdaten einfach sind. Beachten Sie, dass Sie bei Verwendung des Cmdlets Get-PowerBIActivityEvent Überwachungsdaten für einen Tag abrufen. Wenn Sie jedoch direkt die REST-API Get Activity Events aufrufen, rufen Sie Überwachungsdaten für eine Stunde ab. Wenn Sie also die REST-API verwenden, um Überwachungsdaten für einen Tag abzurufen, müssen Sie eine Schleife verwenden, um die API 24-mal aufzurufen, um jede Stunde des Tages zu extrahieren.
• Paginierung großer Resultsets: Große Resultsets werden effizient mithilfe von Paginierung abgerufen. Bei der Paginierung wird jeweils ein Teil der Ergebnisse abgerufen. Die Cmdlets verwalten die Paginierung automatisch für Sie. Wenn Sie die REST-APIs jedoch direkt verwenden, muss Ihr Skript ein Fortsetzungstoken überprüfen, um zu bestimmen, ob weitere Ergebnisse vorliegen. Das Skript sollte mit dem Abrufen von Ergebnisblöcken fortfahren, bis kein Fortsetzungstoken mehr empfangen wird. Ein Beispiel für die Verwendung eines Fortsetzungstokens finden Sie unter Activity Events-REST-API.
• Ablauf von Zugriffstoken: Bei der Authentifizierung wird ein Zugriffstoken zurückgegeben. Standardmäßig läuft es nach einer Stunde ab. Die Cmdlets verarbeiten den Ablauf von Zugriffstoken für Sie. Auf diese Weise brauchen Sie keine Logik zu schreiben, um ein Aktualisierungstoken anzufordern.
• Formatierung: Die von einem Cmdlet zurückgegebenen Daten sind etwas schöner formatiert als die von der REST-API zurückgegebenen Daten. Die Ausgabe ist benutzerfreundlicher. Bei automatisierten Überwachungsprozessen stellt dies wahrscheinlich kein Problem dar. Für manuelle Überwachungsprozesse kann die schönere Formatierung jedoch nützlich sein.

Überlegungen zur direkten Verwendung der REST-APIs

Manchmal hat das direkte Aufrufen der Power BI-REST-APIs Vorteile.

• Viele weitere APIs verfügbar: Es sind mehr REST-APIs als PowerShell-Cmdlets verfügbar. Übersehen Sie jedoch nicht die Flexibilität des Cmdlets Invoke-PowerBIRestMethod, mit dem Sie eine beliebige der Power BI-REST-APIs aufrufen können.
• Häufigkeit von Updates: Microsoft aktualisiert die REST-APIs häufiger als die PowerShell-Module. Wenn z. B. der Get Dataset-API-Antwort ein neues Attribut hinzugefügt wird, kann es einige Zeit dauern, bis es in den Ergebnissen des Cmdlets Get-PowerBIDataset verfügbar ist.
• Weniger Sprach-/Toolabhängigkeit: Wenn Sie die REST-APIs direkt (anstelle eines Cmdlets) verwenden, brauchen Sie PowerShell nicht zu verwenden. Alternativ können Sie PowerShell nur verwenden, um das Aufrufen vieler APIs in einem Skript zu orchestrieren. Durch das Entfernen (oder Vermeiden) aller Abhängigkeiten von PowerShell können Sie zu einem bestimmten Zeitpunkt in der Zukunft Ihre Logik in einer anderen Sprache neu schreiben. Wenn Ihr IT- oder Entwicklerteam starke Vorlieben für Tools und Sprachen hat, kann eine geringere Abhängigkeit ein wichtiger Aspekt sein.

Unabhängig davon, welche Methode Sie verwenden möchten, können sich die REST-APIs im Laufe der Zeit ändern. Wenn sich eine Technologie weiterentwickelt, können APIs (und PowerShell-Module) veralten und ersetzt werden. Daher empfiehlt es sich, gezielt Skripts zu erstellen, die einfach zu verwalten und stabil gegenüber Änderungen sind.

Checkliste: Bei der Wahl, ob sie direkt oder mithilfe von PowerShell-Cmdlets auf die REST-APIs zugreifen möchten, sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Beratung mit der IT zur Verwendung von PowerShell: Wenden Sie sich an die entsprechenden IT-Teams, um zu ermitteln, ob interne Anforderungen oder Vorlieben zur Verwendung von PowerShell bestehen.
• Entscheidung, wie PowerShell verwendet werden soll: Bestimmen Sie, welche PowerShell-Techniken verwendet werden sollen und ob Sie Ihre Abhängigkeit von PowerShell absichtlich erhöhen oder verringern möchten. Überlegen Sie, ob interne Kommunikation oder Schulung erforderlich ist.
• Upgrade auf PowerShell Core: Stellen Sie Recherchen zur Verwendung von PowerShell Core an. Ermitteln Sie, ob Administratorcomputer aktualisiert werden müssen. Überlegen Sie, welche vorhandenen Skripts getestet werden müssen. Ermitteln Sie, ob Administratoren oder Entwickler zusätzliche Schulung benötigen, um ihre Fertigkeiten zu verbessern.
• Bestimmen der zu verwendenden PowerShell-Module: Überlegen Sie, ob die Power BI-Verwaltungsmodule und/oder das Data Gateway-Modul verwendet werden.
• Entscheidung, ob Communityprojekte zulässig sind: Legen Sie fest, ob online verfügbare PowerShell-Module (im Gegensatz zu von Microsoft veröffentlichten Modulen) verwendet werden dürfen (oder sogar empfohlen werden). Beraten Sie sich mit der IT, um zu ermitteln, ob es Kriterien für Communityprojekte gibt, die online bezogen werden.
• Abklären des Supports für Communityprojekte: Wenn PowerShell-Communityprojekte zulässig sind, sollten Sie erwägen, wer für ihren Support zuständig ist, sobald sie intern eingesetzt werden.
• Abschluss eines kleinen Proof of Concept (POC): Experimentieren Sie mit einem technischen POC. Bestätigen Sie Ihre bevorzugten Clienttools und die Methode des Datenzugriffs.
• Bestimmen des Supports für fortgeschrittene Benutzer: Überlegen Sie, wie Sie technische Benutzer unterstützen, die mithilfe der Benutzer-APIs selbst Automatisierung erstellen.

Bestimmen des Speicherorts von Überwachungsdaten

Wenn Sie eine End-to-End-Überwachungslösung erstellen möchten, müssen Sie entscheiden, wo die Rohdaten (und die kuratierten Daten, die im nächsten Abschnitt behandelt werden) gespeichert werden sollen. Ihre Entscheidungen zur Datenspeicherung stehen im Zusammenhang mit Ihren Präferenzen für die Datenintegration.

Wenn Sie rohe Überwachungsdaten extrahieren, halten Sie die Lösung einfach. Es empfiehlt sich, beim ersten Extrahieren der Daten keine spezifischen Attribute auszuwählen, Transformationen durchzuführen oder Formatierungen anzuwenden. Extrahieren Sie stattdessen alle verfügbaren Attribute, und speichern Sie die Daten im ursprünglichen Zustand.

Hier sind mehrere Gründe, warum das Speichern der Rohdaten im ursprünglichen Zustand eine bewährte Methode ist.

• Alle Daten sind im Verlauf verfügbar: Neue Attribute und neue Ereignistypen werden im Lauf der Zeit verfügbar. Das Speichern aller Rohdaten ist eine gute Möglichkeit, sicherzustellen, dass Sie immer Zugriff auf alle Daten haben, die zum Zeitpunkt der Extraktion verfügbar waren. Selbst wenn Sie Zeit benötigen – die Wochen oder Monate betragen kann –, um zu bemerken, dass neue Datenattribute verfügbar sind, ist es möglich, sie rückblickend zu analysieren, da Sie sie in den Rohdaten erfasst haben.
• Widerstandsfähig gegenüber Änderungen: Wenn sich das Rohdatenformat ändert, ist der Prozess, der die Daten extrahiert, nicht betroffen. Da einige Überwachungsdaten zeitabhängig sind, ist es wichtig, dass Sie einen Datenextraktionsprozess entwerfen, der nicht fehlschlägt, wenn eine Änderung in der Quelle auftritt.
• Rollen und Zuständigkeiten: Verschiedene Teammitglieder (z. B. Datentechniker oder globale Administratoren) sind möglicherweise für die Erstellung der Prozesse verantwortlich, um auf die rohen Überwachungsdaten zuzugreifen, sie zu extrahieren und zu speichern. Das Vereinfachen des Datenextraktionsvorgangs macht die Zusammenarbeit mehrerer Teams einfacher.

Hier sind einige Optionen für die Speicherung von Rohdaten:

• Data Lake oder Objektspeicher: Ein Clouddienst wie OneLake, der auf das Speichern von Dateien beliebiger Strukturen spezialisiert ist. Dies ist eine ideale Wahl zum Speichern der rohen Überwachungsdaten. In einer Data Lake-Architektur sollten Rohdaten in der Bronzeebene gespeichert werden.
• Dateisystem: Ein Dateisystem (z. B. Windows oder Linux) ist eine gängige Wahl zum Speichern der rohen Überwachungsdaten.
• Datenbank: Es ist möglich, JSON-Daten in einer relationalen Datenbank wie Azure SQL-Datenbank zu speichern. Dies ist jedoch weniger üblich als das Speichern der Daten in einem Data Lake oder Dateisystem. Dies liegt daran, dass das Abfragen und Verwalten von JSON-Daten schwierig und teuer werden kann, insbesondere bei anwachsendem Datenvolumen.

Tipp

Wenn Sie einen Data Lake, einen Objektspeicher oder ein Dateisystem verwenden, empfehlen wir, die Daten auf eine Weise zu speichern, die sich einfach organisieren und schützen lässt. Es ist auch wichtig, klar zu bestimmen, ob die Daten Ereignisse umfassen (die normalerweise angefügt werden) oder ob es sich um eine Momentaufnahme zu einem bestimmten Zeitpunkt handelt (was die Auswahl eines Datums für die Analyse erfordert).

Betrachten Sie ein Beispiel für eine Rohdatenzone eines Data Lake. Die Zone weist eine Ordnerhierarchie zum Speichern von Aktivitätsprotokolldaten auf : Raw > ActivityLog > JJJJ > MM. Die Ordner sind nach Jahr und Monat partitioniert. Eine Datei, die im Monatsordner gespeichert ist, verwendet das folgende Format: PBIActivityLog-JJJJMMDD-JJJJMMDDTTTT.json. JJJJMMD stellt das tatsächliche Datum dar, und JJJJJJMMDDTTTT ist der Extraktionszeitstempel. Indem Sie den Extraktionszeitstempel einschließen, können Sie bestimmen, welche Datei die neueste ist (falls Sie die Daten erneut extrahieren müssen). Wenn Sie beispielsweise am 25. April 2023 um 9 Uhr (UTC) Daten für die Aktivität am 23. April 2023 extrahieren, lautet der Dateiname PBIActivityLog-20230523-202305250900.

Es wird dringend empfohlen, eine Technologie zu verwenden, mit der Sie die Rohdaten in unveränderlichen Speicher schreiben können. Unveränderlicher Speicher garantiert, dass die Daten nach dem Schreiben nicht überschrieben oder gelöscht werden können. Diese Unterscheidung ist für Prüfer wichtig und gibt Ihnen das Vertrauen, dass die Rohdaten zuverlässig sind.

Ferner müssen Sie überlegen, wie Sie die Rohdaten sicher speichern. In der Regel benötigen nur sehr wenige Benutzer Zugriff auf die Rohdaten. Der Zugriff auf Rohdaten wird in der Regel auf Bedarfsbasis zur Verfügung gestellt, in der Regel für Datentechniker und Systemadministratoren. Möglicherweise benötigen Ihre internen Auditor*innen ebenfalls Zugriff. Die Teammitglieder, die für die Erstellung der kuratierten Daten zuständig sind (als nächster Punkt beschrieben), benötigen ebenfalls Zugriff auf die Rohdaten.

Hier sehen Sie einige Überlegungen, die Ihnen bei der Auswahl Ihres Rohdatenspeichers helfen können.

• Handelt es sich um einen manuellen oder automatisierten Überwachungsprozess? Ein automatisierter Überwachungsprozess hat in der Regel strengere Anforderungen an die Speicherung und den Speicherort von Daten.
• Ist der Themenbereich besonders sensibel? Abhängig vom Typ der Daten und ihrer Vertraulichkeit besteht für Ihre Organisation möglicherweise eine Anforderung an die Art und den Ort der Speicherung. Power BI-Überwachungsdaten enthalten Benutzerinformationen zur Identifikation und IP-Adressen, daher sollten sie in einem sicheren Bereich gespeichert werden.
• Gibt es eine bevorzugte Speichertechnologie? Es könnte eine vorhandene Speichertechnologie geben, die innerhalb der Organisation verwendet wird, was also eine logische Wahl wäre.
• Greifen Benutzer direkt auf den Speicher zu? Das Sicherheitsmodell ist ein wichtiger Aspekt. In der Regel wird nur sehr wenigen Benutzern Zugriff auf die Rohdaten erteilt. Der Zugriff auf die kuratierten Daten wird in der Regel Power BI-Inhaltsersteller*innen erteilt, die für die Erstellung des zentralisierten Datenmodells (das Semantikmodell, das als semantische Ebene für die Berichterstellung dient) zuständig sind.
• Bestehen für Sie Anforderungen an die Datenresidenz? Einige Organisationen haben rechtliche oder gesetzliche Anforderungen an die Datenresidenz, um Daten in einer bestimmten Datenregion zu speichern.
• Wie werden die Daten organisiert? Die Verwendung der Medallion-Architektur ist eine gängige Methode, insbesondere in Data Lake- und Lakehouse-Implementierungen. Das Ziel besteht darin, Ihre Daten in der Bronze-, Silber- und Gold-Datenebene zu speichern. Die Bronzeebene enthält die ursprünglichen Rohdaten. Die Silberebene enthält validierte und deduplizierte Daten, die für Transformationen verwendet werden. Die Goldebene enthält die zusammengestellten, hochgradig optimierten Daten, die zur Analyse bereit sind.

Checkliste: Bei der Planung des Speicherorts zum Speichern von Rohdaten sind diese wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Beratung mit der IT: Wenden Sie sich an die entsprechenden IT-Teams, um zu ermitteln, ob bereits Prozesse zur Extraktion der rohen Überwachungsdaten ausgeführt werden. Falls ja, finden Sie heraus, ob Sie auf die vorhandenen Daten zugreifen können. Wenn ein neuer Datenextraktionsprozess erforderlich ist, bestimmen Sie, ob es Präferenzen oder Anforderungen für den Speicherort der Daten gibt.
• Entscheidung, wo Rohdaten gespeichert werden sollen: Bestimmen Sie den besten Speicherort und die beste Struktur zum Speichern der Rohdaten.
• Ermitteln der Anforderungen an die Datenresidenz: Bringen Sie in Erfahrung, ob es gesetzliche oder behördliche Anforderungen für den Speicherort der Daten gibt.
• Erstellen einer Ordnerstruktur und Namenskonvention: Legen Sie fest, welche Namenskonvention für Rohdatendateien verwendet werden soll, einschließlich der Ordnerstruktur. Nehmen Sie diese Details in Ihre technische Dokumentation auf.
• Überlegungen zur Sicherheit für Rohdaten: Berücksichtigen Sie beim Entwerfen des Speicherorts für Rohdaten, wer Zugriff auf die Daten benötigt und wie der Zugriff erteilt wird.

Planen der Erstellung kuratierter Daten

Kuratierte Daten unterstützen die Analyse und sind benutzerfreundlich konzipiert. Sie müssen Entscheidungen darüber treffen, wie und wo kuratierte Daten erstellt werden. Die Technologie, die Sie zum Speichern der kuratierten Daten auswählen, kann eine der im vorherigen Abschnitt aufgeführten Technologien sein.

Das Ziel kuratierter Daten besteht darin, die Daten in ein benutzerfreundlicheres Format zu überführen, das für Analyse und Berichterstellung optimiert ist. Es bildet die Datenquelle eines Power BI-Datenmodells. Das bedeutet, dass Sie ein Power BI-Datenmodell verwenden, um die Nutzung von Power BI in Ihrer Organisation zu analysieren. Es gelten grundlegende Leitfäden für Datenmodelle: Sie sollten einen Sternschemaentwurf einführen, der auf Leistung und Benutzerfreundlichkeit optimiert ist.

Sie können unter verschiedenen Arten der Erstellung kuratierter Daten wählen. Sie müssen entscheiden, wie die Datenintegration erfolgen und wie weit upstream die Transformationen angewendet werden sollen, mit denen die Daten für das Laden in ein Sternschema vorbereitet werden.

Data Lake

Sie können die Anwendung der Transformationen und das Kuratieren der Datendateien in einem Data Lake vornehmen. Sie sollten eine Goldebene für kuratierte Daten verwenden, damit sie logisch von den Rohdaten getrennt sind, die in der Bronzeebene gespeichert sind. Die Trennung der Daten in Ebenen vereinfacht auch die Festlegung unterschiedlicher Benutzerzugriffsberechtigungen.

Verwenden Sie in den folgenden Fällen einen Data Lake, um die Daten zu transformieren und zu kuratieren:

• Sie erwarten, dass es mehrere Power BI-Datenmodelle gibt, die der Berichterstellung dienen (was die Erstellung einer zwischengeschalteten Silberebene rechtfertigt).
• Sie müssen mehrere Self-Service-Inhaltsersteller unterstützen, die Zugriff auf Überwachungsdaten auf Mandantenebene benötigen.
• Bei Ihnen sind Tools und Prozesse vorhanden, die Sie zum Transformieren und Laden von Daten verwenden möchten.
• Sie möchten die Datenaufbereitung minimieren, die in einem oder mehreren Power BI-Datenmodellen durchgeführt (und möglicherweise dupliziert) werden muss.

Power BI-Datenmodell

Möglicherweise können Sie alle Transformationsarbeiten in Power BI durchführen. Verwenden Sie Power Query, um auf die Daten zuzugreifen und diese vom Rohzustand in das kuratierte Format zu überführen.

Verwenden Sie ein Power BI-Datenmodell in folgenden Fällen:

• Sie möchten die End-to-End-Architektur vereinfachen und das Datenmodell direkt aus den Rohdaten laden. (Die inkrementelle Aktualisierung kann dazu beitragen, die Aktualisierungsdauer zu verringern.)
• Sie bevorzugen es, alle Transformationsarbeiten während des Ladens des Datenmodells zu erledigen.
• Sie erwarten, mit einem zentralen Datenmodell für die Überwachungsdaten auf Mandantenebene auszukommen. Alle Berichte (oder andere Datenmodelle) können das zentrale Power BI-Semantikmodell als Quelle verwenden.
• Sie möchten Benutzer*innen nur Zugriff auf das zentralisierte Power BI-Semantikmodell erteilen (und nicht auf Quelldaten).

Tipp

Richten Sie die Erstellung der kuratierten Daten so ein, dass Sie den Prozess für frühere Datumsbereiche problemlos erneut ausführen können. Wenn Sie beispielsweise feststellen, dass vor drei Monaten ein neues Attribut in den Überwachungsprotokollen auftrat, sollten Sie es seit dem ersten Vorkommen analysieren können. Die Möglichkeit, den Verlauf der kuratierten Daten erneut zu laden, ist einer von mehreren Gründen, warum es wichtig ist, die Rohdaten im ursprünglichen Zustand zu speichern (weiter oben in diesem Artikel beschrieben).

Weitere Informationen dazu, welche Dimensionstabellen und Faktentabellen Sie in Ihr Sternschema aufnehmen können, finden Sie weiter unten in diesem Artikel unter Erstellen eines Datenmodells.

Checkliste: Die Planung der Erstellung kuratierter Daten umfasst folgende wichtige Entscheidungen und Maßnahmen:

• Entscheidung, wo Transformationen erfolgen sollen: Überlegen Sie, wie weit upstream die Transformationsarbeit erledigt werden soll, und wie sich dies in Ihren Plan für die Gesamtarchitektur einfügt.
• Entscheidung, welches Tool zum Transformieren der Daten in ein Sternschema verwendet werden soll: Überprüfen Sie, welche Tools und Dienste zum Transformieren der Rohdaten in kuratierte Daten verwendet werden.
• Entscheidung zum Speicherort der kuratierten Daten: Bestimmen Sie die beste Option zum Speichern der Rohdaten, die in ein Sternschemaformat transformiert wurden. Entscheiden Sie, ob eine zwischengeschaltete Silberebene in der End-to-End-Architektur nützlich ist.
• Erstellen einer Namenskonvention: Legen Sie fest, welche Namenskonvention für kuratierte Datendateien und Ordner (falls zutreffend) verwendet werden soll. Nehmen Sie die Details in Ihre technische Dokumentation auf.
• Überlegungen zur Sicherheit der kuratierten Daten: Berücksichtigen Sie beim Entwerfen des Speicherorts der kuratierten Daten, wer auf die Daten zugreifen muss und wie Sicherheit zugewiesen wird.

Entscheidungen zu Datenquellen

An diesem Punkt sollten Sie sich über Anforderungen, Datenanforderungen und Berechtigungen im Klaren sein. Wichtige technische Entscheidungen wurden getroffen. Sie müssen nun einige Entscheidungen über den Ansatz treffen, wie Sie in den Besitz bestimmter Datentypen gelangen.

Zugriff auf Benutzeraktivitätsdaten

Die Power BI-Benutzeraktivitätsdaten, die manchmal auch als Aktivitätsprotokoll oder Überwachungsprotokolle bezeichnet werden, enthalten eine Fülle von Informationen, die Ihnen helfen, die Vorgänge in Ihrem Power BI-Mandanten zu verstehen. Weitere Informationen zum Identifizieren Ihrer Datenanforderungen finden Sie weiter oben in diesem Artikel unter Benutzeraktivitätsdaten.

Power BI integriert seine Protokolle in das einheitliche Überwachungsprotokoll von Microsoft Purview (früher als einheitliches Überwachungsprotokoll von Microsoft 365 bezeichnet). Diese Integration stellt einen Vorteil dar, denn sie bedeutet, dass nicht jeder Dienst innerhalb von Microsoft 365 eine eigene Protokollierung implementieren muss. Der Webhook ist standardmäßig aktiviert.

Wichtig

Wenn Sie noch keine Daten zu Benutzeraktivitäten extrahieren, sollten Sie dies zu einer dringenden Priorität machen. Die Benutzeraktivitätsdaten sind für die letzten 30 oder 90 Tage verfügbar (abhängig von der Quelle). Selbst wenn Sie noch nicht zu eingehenden Analysen bereit sind, ist es wichtig, so schnell wie möglich mit dem Extrahieren und Speichern der Daten zu beginnen. Auf diese Weise steht der wertvolle Verlauf zur Analyse zur Verfügung.

Sie haben mehrere Optionen zum Abrufen von Benutzeraktivitätsdaten.

Verfahren	Beschreibung	Standardanzahl an Tagen des verfügbaren Verlaufs	Gute Wahl für manuelle Überwachungsprozesse	Gute Wahl für automatisierte Überwachungsprozesse	Gute Wahl zum Einrichten von Warnungen	Gute Wahl für den schnellen Einstieg
Manuell (Benutzeroberfläche)	Grundlegendes zum Microsoft Purview-Complianceportal	90
Manuell (Benutzeroberfläche)	Defender-für-Cloud-Apps	30
Programmgesteuert	Power BI-Aktivitätsprotokoll (API oder PowerShell-Cmdlet)	30
Programmgesteuert	Office 365-Verwaltungsaktivitäts-API:	7
Programmgesteuert	Microsoft Sentinel (Azure Monitor)	30

Der weitere Verlauf dieses Abschnitts stellt eine Einführung in die einzelnen in der Tabelle vorgestellten Techniken dar.

Grundlegendes zum Microsoft Purview-Complianceportal

Das Überwachungssuchtool im Microsoft Purview-Complianceportal (früher als Microsoft 365 Compliance Center bezeichnet) ist ein praktischer Ort, um Aktivitäten und Warnungen anzuzeigen. Für dieses Tool brauchen Sie kein Skript zu erstellen, um die Daten zu extrahieren und herunterzuladen. Sie können eine Power BI-Workload auswählen, um alle Überwachungsprotokolldatensätze für einen bestimmten Zeitraum anzuzeigen. Ferner können Sie die Ergebnisse eingrenzen, indem Sie bestimmte Aktivitäten und Benutzer auswählen. Ein Vorgesetzter bittet Sie beispielsweise, herauszufinden, wer früher am Tag einen Arbeitsbereich gelöscht hat, damit er sich schnell mit der Person in Verbindung setzen kann, um die Situation zu besprechen.

Die letzten 90 Tage des Verlaufs sind mit Audit (Standard) verfügbar. Mit Audit (Premium) können Sie mit der langfristigen Aufbewahrung Überwachungsprotokolle (optional) länger aufbewahren. Da die langfristige Aufbewahrung nur für lizenzierte E5-Benutzer gilt, sind Überwachungsdatensätze für Nicht-E5-Benutzer und Gastbenutzer ausgeschlossen. Daher empfiehlt es sich, sich nur auf den standardmäßigen 90-Tage-Verlauf zu stützen, um sicherzustellen, dass alle Aktivitäten erfasst werden.

Es gibt Lizenzierungsanforderungen für den Zugriff auf die Überwachungsprotokolle im Microsoft Purview-Complianceportal. Außerdem sind für den Zugriff auf die Überwachungsprotokolle erhöhte Exchange Online-Berechtigungen erforderlich.

Tipp

Standardmäßig sind Power BI-Administratoren nicht berechtigt, auf die einheitliche Überwachungsprotokollsuche im Microsoft Purview-Complianceportal zuzugreifen. Da sie Daten für viele Microsoft 365-Dienste enthält, handelt es sich um eine Rolle mit hohen Berechtigungen. In den meisten Organisationen sind diese Berechtigungen für eine kleine Anzahl von IT-Administratoren reserviert. Power BI-Administratoren stehen andere Optionen zur Verfügung, die weiter unten in diesem Abschnitt beschrieben werden.

Die Benutzeroberfläche im Microsoft Purview-Complianceportal ist nützlich für manuelle Überwachungsprozesse und die gelegentliche Untersuchung von Benutzeraktivitäten.

Defender-für-Cloud-Apps

Das Portal in Defender for Cloud Apps ist ein praktischer Ort, um Aktivitäten und Warnungen anzuzeigen, ohne ein Skript zum Extrahieren und Herunterladen der Daten erstellen zu müssen. Außerdem können Sie Daten aus dem Power BI-Aktivitätsprotokoll und Benutzeranmeldungen anzeigen.

Defender for Cloud Apps enthält eine Benutzeroberfläche zum Anzeigen und Durchsuchen von Aktivitätsprotokollen für verschiedene Clouddienste, einschließlich Power BI. Es werden die gleichen Protokollereignisse angezeigt, die aus dem einheitlichen Microsoft Purview-Überwachungsprotokoll stammen, zusätzlich zu weiteren Ereignissen wie Benutzeranmeldeaktivitäten aus Microsoft Entra ID.

Wie das Microsoft Purview-Complianceportal (im vorherigen Abschnitt beschrieben) verfügt Defender for Cloud Apps über eine durchsuchbare Benutzeroberfläche. Die Filteroptionen sind jedoch unterschiedlich. Über den standardmäßigen 30-Tage-Verlauf hinaus können Sie Defender for Cloud Apps verwenden, um bis zu sechs Monate Aktivitätsprotokollverlauf (in Sieben-Tage-Schritten) anzuzeigen.

Für den Zugriff auf Defender for Cloud Apps bestehen Lizenzierungsanforderungen. Außerdem sind separate Berechtigungen erforderlich.

Tipp

Standardmäßig verfügen Power BI-Administratoren nicht über die Berechtigung für den Zugriff auf Defender for Cloud Apps. Es gibt eine Power BI-Rolle in Defender for Cloud Apps. Das Hinzufügen von Power BI-Administratoren zu dieser Rolle ist eine gute Möglichkeit, ihnen Zugriff auf einen begrenzten Satz von Daten zu erteilen.

Die Benutzeroberfläche in Defender for Cloud Apps ist nützlich für manuelle Überwachungsprozesse und einmalige Untersuchungen von Benutzeraktivitäten.

Power BI-Aktivitätsprotokoll

Das Power BI-Aktivitätsprotokoll stammt aus dem einheitlichen Überwachungsprotokoll. Es enthält nur Benutzeraktivitäten im Zusammenhang mit dem Power BI-Dienst.

Tipp

Für Organisationen, die das Extrahieren von Benutzeraktivitäten planen, empfiehlt es sich, mit dem Power BI-Aktivitätsprotokoll zu beginnen. Es ist die einfachste Quelle, auf die programmgesteuert zugegriffen werden kann.

Sie haben zwei Optionen für den Zugriff auf das Power BI-Aktivitätsprotokoll.

• Rufen Sie die REST-API Get Activity Events auf, indem Sie das Tool Ihrer Wahl verwenden.
• Verwenden Sie das PowerShell-Cmdlet Get-PowerBIActivityEvent. Sie steht im Power BI Management Admin-Modul zur Verfügung.

Informationen zur geeigneten Option finden Sie weiter oben in diesem Artikel unter Auswählen von APIs oder PowerShell-Cmdlets.

Tipp

Beispiele für den Zugriff auf das Power BI-Aktivitätsprotokoll mit PowerShell finden Sie unter Zugreifen auf das Power BI-Aktivitätsprotokoll.

Power BI-Aktivitätsprotokolldaten stehen allen Power BI-Administratoren, Power Platform-Administratoren und globalen Administratoren zur Verfügung. Auf die Daten kann über das einheitliche Überwachungsprotokoll zugegriffen werden, das bestimmten Exchange Online-Rollen zur Verfügung steht. Weitere Informationen finden Sie unter Nachverfolgen von Benutzeraktivitäten in Power BI.

Es empfiehlt sich, das Power BI-Aktivitätsprotokoll zu verwenden, wenn Sie nur Power BI-Überwachungsprotokolldatensätze abrufen möchten.

Hinweis

In den Überwachungsprotokolldaten werden Arbeitsbereiche als Ordner bezeichnet. In der Power BI-REST-API werden Arbeitsbereiche als Gruppen bezeichnet.

Office 365-Verwaltungsaktivitäts-API:

Sie können Daten aus dem einheitlichen Überwachungsprotokoll für andere Dienste extrahieren, wie etwa SharePoint Online, Teams, Exchange Online, Dynamics 365 und Power BI. Wenn Sie eine Überwachungslösung für mehrere Dienste implementieren möchten, empfiehlt es sich, die Office 365-Verwaltungsaktivitäts-API zu verwenden. Da diese API Daten aus vielen Diensten zurückgibt, wird sie als einheitliche Überwachungs-API (oder das einheitliche Überwachungsprotokoll) bezeichnet. Sie stellt eine der Office 365-Verwaltungs-APIs dar.

Bevor Sie eine neue Lösung erstellen, sollten Sie sich an Ihre IT-Abteilung wenden, um zu ermitteln, ob bereits vorhandene Power BI-Überwachungsdatensätze verfügbar sind. Es ist möglich, dass ein Prozess die Daten bereits extrahiert und speichert. Es ist ebenso möglich, dass Sie die Berechtigung für den Zugriff auf diese Daten erhalten, statt eine neue Lösung erstellen zu müssen.

Sie können auf zwei Arten auf die Daten zugreifen.

• Rufen Sie die Office 365-Verwaltungsaktivitäts-API direkt auf, indem Sie das Tool Ihrer Wahl verwenden. Standardmäßig gibt die API Daten von 24 Stunden zurück. Sie können maximal den Verlauf von sieben Tagen abrufen.
• Verwenden Sie das PowerShell-Cmdlet Search-UnifiedAuditLog. Es handelt sich um ein Exchange Online PowerShell-Cmdlet. Sie können maximal den Verlauf von 90 Tagen abrufen.

Wichtig

Das Cmdlet Search-UnifiedAuditLog lässt sich nicht gut skalieren, und es erfordert die Implementierung einer Schleifenstrategie, um den Grenzwert von 5.000 Zeilen zu überwinden. Aus diesen Gründen eignet es sich für gelegentliche Abfragen oder für kleine Organisationen mit geringer Aktivität. Wenn Sie nur Power BI-Daten benötigen, empfiehlt es sich, stattdessen das Cmdlet Get-PowerBIActivityEvent zu verwenden.

Im Allgemeinen ist der Einstieg mit der Office 365-Verwaltungsaktivitäts-API schwieriger als die Verwendung des Power BI-Aktivitätsprotokolls (zuvor beschrieben). Das liegt daran, dass die API Inhaltsblobs zurückgibt und jedes Inhaltsblob einzelne Überwachungsdatensätze enthält. Bei großen Organisationen kann es pro Tag Tausende von Inhaltsblobs geben. Da Kunden und Anwendungen von Drittanbietern diese API stark nutzen, implementiert Microsoft eine Drosselung, um sicherzustellen, dass sich ihre Nutzung des Diensts nicht negativ auf andere auswirkt (das sogenannte Noisy Neighbor-Problem). Daher kann das Abrufen großer Volumina des Verlaufs in größeren Organisationen eine Herausforderung darstellen. Weitere Informationen finden Sie in diesem Artikel zur Problembehandlung.

Zum Verwenden dieser API müssen Sie sich mit einem Dienstprinzipal authentifizieren, dem die Berechtigung zum Abrufen von Daten aus der Office 365-Verwaltungsaktivitäts-API erteilt wurde.

Tipp

Standardmäßig verfügen Power BI-Administratoren nicht über die Berechtigung zum Zugriff auf die Office 365-Verwaltungsaktivitäts-API. Da sie Daten für viele Microsoft 365-Dienste enthält, erfordert der Zugriff die Administrator- oder Überwachungsrollen mit hohen Berechtigungen. In den meisten Organisationen sind diese Rollen für eine kleine Anzahl von IT-Administratoren reserviert. Das Power BI-Aktivitätsprotokoll ist für die Verwendung durch Power BI-Administratoren vorgesehen.

Das programmgesteuerte Abrufen der Überwachungsdaten aus der Office 365-Verwaltungsaktivitäts-API ist eine gute Wahl, wenn die IT Überwachungsprotokolle aus verschiedenen Diensten (über Power BI hinaus) extrahieren und speichern muss.

Microsoft Sentinel

Microsoft Sentinel ist ein Azure-Dienst, mit dem Sie Sicherheitsvorfälle und Bedrohungen erfassen, erkennen, untersuchen und darauf reagieren können. Sie können Power BI in Microsoft Sentinel als Datenconnector einrichten. Bei bestehender Verbindung werden Überwachungsprotokolle (die eine Teilmenge von Daten enthalten) aus Power BI in Azure Log Analytics gestreamt, eine Funktion von Azure Monitor.

Tipp

Azure Log Analytics basiert auf der gleichen Architektur, die auch von den Ereignisprotokollen auf Arbeitsbereichsebene des Semantikmodells verwendet wird. Weitere Informationen zu Ereignisprotokollen für Semantikmodelle finden Sie unter Überwachung auf Datenebene.

Da es sich um einen separaten Azure-Dienst handelt, müssen jedem Administrator oder Benutzer, der Abfragen in der Kusto-Abfragesprache (KQL) ausführen soll, Berechtigungen in Azure Log Analytics (Azure Monitor) erteilt werden. Wenn sie über die Berechtigung verfügen, können sie die in der PowerBIActivity-Tabelle gespeicherten Überwachungsdaten abfragen. Beachten Sie jedoch, dass Sie Benutzern in den meisten Fällen Zugriff auf die kuratierten Daten in der Goldebene statt auf die Rohdaten in der Bronzeebene erteilen.

Sie verwenden KQL, um die Aktivitätsprotokollereignisse zu analysieren, die in Azure Log Analytics gespeichert sind. Wenn Sie über SQL-Erfahrung verfügen, werden Ihnen viele Ähnlichkeiten mit KQL auffallen.

Es gibt mehrere Möglichkeiten, auf die in Azure Log Analytics gespeicherten Ereignisse zuzugreifen. Verwenden Sie Folgendes:

• Die vordefinierte Vorlagen-App Log Analytics für Power BI-Semantikmodelle.
• Den Power BI Desktop-Connector für Azure Data Explorer (Kusto).
• Die webbasierte Abfrageumgebung in Azure Data Explorer.
• Jedes Abfragetool, das KQL-Abfragen senden kann.

Achtung

Beachten Sie, dass nur eine Teilmenge der Power BI-Aktivitätsprotokolldaten in Azure Monitor gespeichert wird. Wenn Sie eine umfassende Analyse der Nutzung und Verbreitung von Power BI in der Organisation planen, empfiehlt es sich, andere Optionen (weiter oben in diesem Abschnitt beschrieben) zum Abrufen von Aktivitätsdaten zu verwenden.

Der Verlaufszeitraum, den Sie abrufen können, hängt von der Datenaufbewahrungsrichtlinie für den Azure Log Analytics-Arbeitsbereich ab. Berücksichtigen Sie bei der Entscheidung über die Menge der aufzubewahrenden Daten die Kosten und den Zugriff auf Rohdaten.

Microsoft Sentinel und Azure Monitor sind gute Optionen, wenn die IT bereits in Microsoft Sentinel investiert hat, die erfasste Detailebene Ihren Anforderungen entspricht und Aktivitäten wie die Bedrohungserkennung hohe Priorität haben. Da Microsoft Sentinel jedoch nicht alle Power BI-Aktivitätsdaten erfasst, unterstützt es keine umfassende Analyse der Power BI-Nutzung und -Verbreitung.

Überlegungen zu Benutzeraktivitätsdaten

Hier sehen Sie einige Überlegungen, die Ihnen bei der Wahl Ihrer Quelle für Benutzeraktivitätsdaten helfen.

• Soll es sich um einen manuellen oder automatisierten Überwachungsprozess handeln? Die Benutzeroberflächenoptionen eignen sich gut für manuelle Überwachungsprozesse und gelegentliche einmalige Abfragen, insbesondere wenn Sie eine bestimmte Aktivität untersuchen müssen. Ein automatisierter Überwachungsprozess, der die Benutzeraktivitätsdaten nach einem Zeitplan extrahiert, ist ebenfalls erforderlich, um die Analyse der Verlaufsdaten zu unterstützen.
• Wie oft benötigen Sie die Benutzeraktivitätsdaten? Planen Sie für automatisierte Überwachungsprozesse das Extrahieren von Daten, die mindestens einen Tag vor dem aktuellen Datum liegen, mithilfe der koordinierten Weltzeit (UTC) anstelle Ihrer Ortszeit. Wenn Ihr Prozess beispielsweise am Freitagmorgen (UTC-Zeit) ausgeführt wird, sollten Sie Daten von Mittwoch extrahieren. Es gibt mehrere Gründe, warum Sie Daten mit einer Wartezeit von einem Tag extrahieren sollten.
  • Die Arbeit mit Ihren Dateien gestaltet sich einfacher, wenn Sie immer volle 24 Stunden pro Tag extrahieren, wodurch Ergebnisse für Tagesteile vermieden werden.
  • Sie minimieren das Risiko, dass einige Überwachungsereignisse fehlen. In der Regel treffen Überwachungsereignisse innerhalb von 30 Minuten ein. Gelegentlich kann es bis zu 24 Stunden dauern, bis einige Ereignisse im einheitlichen Überwachungsprotokoll eintreffen.
• Benötigen Sie mehr als Power BI-Daten? Betrachten Sie die effizienteste Methode, um auf die benötigten Daten zuzugreifen.
  • Wenn Sie nur Power BI-Benutzeraktivitätsdaten benötigen, verwenden Sie das Power BI-Aktivitätsprotokoll.
  • Wenn Sie Überwachungsprotokolle von mehreren Diensten benötigen, verwenden Sie die Office 365-Verwaltungsaktivitäts-API, um auf das einheitliche Überwachungsprotokoll zuzugreifen.
• Wer soll die Lösung entwickeln? Planen Sie etwas Zeit für die Entwicklung der Lösung ein. Die Erstellung eines produktionsbereiten Skripts kann erheblichen Aufwand bedeuten.

Checkliste: Die Planung des Zugriffs auf Benutzeraktivitätsdaten umfasst folgende wichtige Entscheidungen und Maßnahmen:

• Klärung des Umfangs der Anforderungen: Bestimmen Sie, ob Sie nur auf Power BI-Überwachungsdatensätze oder auf Überwachungsdaten für mehrere Dienste zugreifen müssen.
• Beratung mit der IT: Bringen Sie in Erfahrung, ob die IT derzeit Überwachungsprotokolle extrahiert und ob es möglich ist, Zugriff auf die Rohdaten zu erhalten, damit Sie keine neue Lösung erstellen müssen.
• Entscheidung über die Datenquelle: Ermitteln Sie die beste Quelle für den Zugriff auf Benutzeraktivitätsdaten.
• Durchführung eines Proof of Concept: Planen Sie die Durchführung eines kleinen technischen Proof of Concept (POC). Verwenden Sie ihn, um Ihre Entscheidungen dazu zu überprüfen, wie die endgültige Lösung erstellt werden soll.
• Nachverfolgen zusätzlicher Datenanforderungen: Sie können Aktivitätsprotokolldaten mit anderen Quellen korrelieren, um den Wert der Daten zu steigern. Verfolgen Sie diese Möglichkeiten nach, wenn sie sich ergeben, damit sie dem Umfang Ihres Projekts hinzugefügt werden können.

Zugreifen auf Mandantenbestandsdaten

Ein Mandantenbestand ist ein unschätzbarer und notwendiger Bestandteil einer ausgereiften Überwachungslösung. Er hilft Ihnen zu verstehen, welche Arbeitsbereiche und Inhalte (Semantikmodelle, Berichte und weitere Elemente) in Power BI vorhanden sind, und ist eine hervorragende Ergänzung zu den Benutzeraktivitätsdaten (im vorherigen Abschnitt beschrieben). Weitere Informationen zum Identifizieren Ihrer Datenanforderungen finden Sie weiter oben in diesem Artikel unter Mandantenbestand.

Benutzeraktivitäten (zuvor beschrieben) sind überwachte Ereignisse. Sie sind ein Datensatz der Aktionen, die ein Benutzer zu einem bestimmten Datum und zu einer bestimmten Uhrzeit ausgeführt hat. Der Mandantenbestand ist jedoch anders. Der Mandantenbestand ist eine Momentaufnahme zu einem bestimmten Zeitpunkt. Er beschreibt den aktuellen Status aller veröffentlichten Elemente im Power BI-Dienst zum Zeitpunkt der Extraktion.

Hinweis

Die Power BI-REST-API-Dokumentation bezieht sich auf veröffentlichte Elemente als Artefakte.

Tipp

Viele Organisationen finden es nützlich, den Mandantenbestand jede Woche zur gleichen Tageszeit zu extrahieren.

Zur ordnungsgemäßen Analyse der Vorgänge in Ihrem Power BI-Mandanten benötigen Sie sowohl die Benutzeraktivitätsdaten als auch den Mandantenbestand. Durch ihre Kombination können Sie verstehen, wie viele Inhalte Sie haben und wo sie sich befinden. Außerdem können Sie ungenutzte oder nicht genutzte Inhalte finden (da im Aktivitätsprotokoll keine Ereignisse dafür vorhanden sind). Der Mandantenbestand hilft Ihnen auch beim Kompilieren einer Liste aktueller Namen für alle Elemente, was nützlich ist, wenn sich Elementnamen ändern.

Weitere Informationen zum Wert des Mandantenbestands finden Sie weiter oben in diesem Artikel unter Mandantenbestand.

Tipp

Sie können die API Get Unused Artifacts as Admin verwenden, um nach Elementen zu suchen, die in den letzten 30 Tagen keine Benutzeraktivität aufweisen. Allerdings lässt sich dieser Zeitraum nicht anpassen. Beispielsweise verfügen Sie möglicherweise über kritische Inhalte, die nur vierteljährlich verwendet werden. Indem Sie Ihren Mandantenbestand mit den Benutzeraktivitätsdaten kombinieren, können Sie nicht verwendete Elemente auf anpassbare Weise finden.

Sie können Mandantenbestandsdaten auf zwei verschiedene Arten abrufen.

Verfahren	Beschreibung	Am besten geeignet für	Gute Wahl für manuelle Überwachungsprozesse	Gute Wahl für automatisierte Überwachungsprozesse
Programmgesteuert	Die API Get Groups as Admin oder das PowerShell-Cmdlet Get-PowerBIWorkspace kann eine Liste von Arbeitsbereichen für den gesamten Mandanten zur Verfügung stellen. Optional können einzelne Elemente (z. B. Semantikmodelle und Berichte) pro Arbeitsbereich eingeschlossen werden.	Kleinere Organisationen oder geringes Datenvolumen
Programmgesteuert	Eine Reihe von asynchronen Administrator-APIs, die zusammen als Metadatenüberprüfungs-APIs oder Scanner-APIs bezeichnet werden, können eine Liste von Arbeitsbereichen und einzelnen Elementen zurückgeben. Optional können auch detaillierte Metadaten (z. B. Tabellen, Spalten und Measureausdrücke) eingeschlossen werden.	Organisationen mit hohem Datenvolumen und/oder der Notwendigkeit, detaillierte Ergebnisse zu erhalten

Der weitere Verlauf dieses Abschnitts stellt eine Einführung in die einzelnen in der Tabelle vorgestellten Techniken dar.

Gruppen-APIs oder Arbeitsbereichs-Cmdlet

Zum Abrufen einer Liste von Arbeitsbereichen können Sie eine von mehreren REST-APIs verwenden, etwa die API Get Groups as Admin (mit dem Tool Ihrer Wahl). Die Ergebnisse enthalten zusätzliche Metadaten, z. B. die Beschreibung und die Angabe, ob der Arbeitsbereich in einer Premium-Kapazität gespeichert ist.

Hinweis

Die benannte API enthält den Ausdruck group als Verweis auf einen Arbeitsbereich. Dieser Begriff stammt aus dem ursprünglichen Power BI-Sicherheitsmodell, das sich auf Microsoft 365-Gruppen stützte. Während sich das Power BI-Sicherheitsmodell im Lauf der Jahre erheblich weiterentwickelt hat, blieben die Namen der vorhandenen APIs unverändert, um zu vermeiden, dass vorhandene Lösungen beschädigt werden.

Die Get Groups as Admin-REST-API enthält den nützlichen Parameter $expand. Mit diesem Parameter können Sie die Ergebnisse optional erweitern, sodass sie eine Liste von Elementen enthalten, die im Arbeitsbereich veröffentlicht wurden (z. B. Semantikmodelle und Berichte). Ferner können Sie den Datentyp users auch an den Parameter $expand übergeben, um die Benutzer einzuschließen, die einer Arbeitsbereichsrolle zugewiesen sind.

Darüber hinaus können Sie das PowerShell-Cmdlet Get-PowerBIWorkspace verwenden. Es stammt aus dem Modul Power BI Management Workspaces. Wenn Sie den -Scope-Parameter organizationfestlegen, funktioniert es wie die Get Groups as Admin-API. Das Cmdlet akzeptiert außerdem den Parameter -Include (der dem Parameter $expand in der REST-API entspricht), um im Arbeitsbereich veröffentlichte Elemente (wie Semantikmodelle und Berichte) einzuschließen.

Tipp

Durch die Übergabe von Parametern können Sie das Cmdlet auf unterschiedliche Weise verwenden. Dieser Abschnitt konzentriert sich auf das Abrufen eines mandantenweiten Bestandes. Weitere Informationen zur Verwendung des -Scope-Parameters finden Sie weiter oben in diesem Artikel unter Auswählen einer Benutzer- oder Administrator-API.

Informationen zur geeigneten Option finden Sie weiter oben in diesem Artikel unter Auswählen von APIs oder PowerShell-Cmdlets.

Die Get Groups as Admin-REST-API oder das Get-PowerBIWorkspace-PowerShell-Cmdlet eignet sich am besten für manuelle Überwachungsprozesse und einmalige Untersuchungen. Größere Organisationen mit hohem Datenvolumen finden diese Optionen in der Regel in der praktischen Nutzung schwierig. Die REST-API und das Cmdlet extrahieren immer einen vollständigen Satz Daten, sodass die Ausführung sehr lange dauern kann. Daher ist es wahrscheinlich, dass größere Organisationen in Bezug auf die Anzahl der zulässigen Anforderungen pro Stunde auf Einschränkungen stoßen (sogenannte Drosselung, die zum Schutz der Integrität des Diensts erfolgt). Die Metadatenüberprüfungs-APIs (als nächster Punkt beschrieben) bieten eine zuverlässigere und skalierbare Alternative.

Metadatenüberprüfungs-APIs

Die Metadatenüberprüfungs-APIs, häufig als Scanner-APIs bezeichnet, sind eine Gruppe von APIs, die eine Liste von Arbeitsbereichen und deren Power BI-Elemente (Semantikmodelle, Berichte und andere Elemente) zurückgeben. Konzeptionell stellen sie dieselben Daten (und mehr) wie die Gruppen-APIs oder das Arbeitsbereichs-Cmdlet zur Verfügung, die im vorherigen Abschnitt beschrieben werden. Die Methode, die Sie zum Abrufen der Daten verwenden, ist jedoch anders und eignet sich besser zum Extrahieren des Mandantenbestands.

Hinweis

Beachten Sie, dass einige Benutzer den Begriff Scanner-APIs oder den Ausdruck Scannen des Mandanten verwenden. Sie verwenden diese Begriffe häufig, um das Kompilieren eines Mandantenbestands zu bezeichnen und es von den Benutzeraktivitätsereignissen zu unterscheiden. Damit könnten sie sich buchstäblich auf die Verwendung der Metadatenüberprüfungs-APIs beziehen.

Es gibt zwei Hauptgründe, warum Sie die Verwendung der Metadatenüberprüfungs-APIs anstelle der Get Groups as Admin-REST-API oder des Get-PowerBIWorkspace-Cmdlets in Betracht ziehen sollten (weiter oben beschrieben).

• Inkrementelle Datenextraktion: Die Scanner-APIs extrahieren nur Daten, die seit der letzten Ausführung geändert wurden. Umgekehrt sind die Get Groups as Admin-REST-API und das Get-PowerBIWorkspace-Cmdlet synchrone Vorgänge, die bei jeder Ausführung den vollständigen Satz Daten extrahieren.
• Präzisere Detailebene: Die Scanner-APIs können feinere Details (z. B. Tabellen, Spalten und Measureausdrücke) abrufen, sofern von den beiden Mandanteneinstellungen für detaillierte Metadaten die Berechtigung dazu erteilt wird. Umgekehrt ist die niedrigste Detailebene, die mit der Get Groups as Admin-REST-API und dem Get-PowerBIWorkspace-Cmdlet verfügbar ist, nach Elementtyp (z. B. eine Liste von Berichten in einem Arbeitsbereich).

Die Verwendung der Scanner-APIs ist mit mehr Aufwand verbunden, da Sie eine Reihe von APIs aufrufen müssen. Außerdem werden sie als asynchroner Prozess ausgeführt. Ein asynchroner Prozess wird im Hintergrund ausgeführt, sodass Sie nicht warten müssen, bis er abgeschlossen ist. Möglicherweise müssen Sie mit der IT oder einem Entwickler zusammenarbeiten, wenn der Zeitpunkt gekommen ist, ein produktionsbereites Skript zu erstellen, das nach Plan ausgeführt werden soll.

Hier sehen Sie die Reihenfolge der Schritte, die Ihr Prozess bei Verwendung der Scanner-APIs befolgen sollte.

1. Anmelden: Melden Sie sich beim Power BI-Dienst an, indem Sie ein Power BI-Administratorkonto oder einen Dienstprinzipal verwenden, der über die Berechtigung zum Ausführen von Administrator-APIs verfügt. Weitere Informationen finden Sie unter Bestimmen der Authentifizierungsmethode weiter unten in diesem Artikel.
2. Abrufen der Arbeitsbereichs-IDs: Senden Sie eine Anforderung zum Abrufen einer Liste von Arbeitsbereichs-IDs. Bei der ersten Ausführung gibt es kein Änderungsdatum, daher wird eine vollständige Liste der Arbeitsbereiche zurückgegeben. Normalerweise übergeben Sie das Änderungsdatum, um nur Arbeitsbereiche abzurufen, die sich seit diesem Zeitpunkt geändert haben. Das Änderungsdatum muss innerhalb der letzten 30 Tage liegen.
3. Einleiten einer Metadatenüberprüfung: Leiten Sie einen Aufruf ein, um eine Überprüfung von Arbeitsbereichsinformationen anzufordern, indem Sie die Arbeitsbereichs-IDs übergeben, die in Schritt 2 abgerufen wurden. Beachten Sie, dass es sich hierbei um eine POST-API handelt (anstelle einer GET-API, die beim Abrufen von Überwachungsdaten häufiger vorkommt). Eine POST-API ist eine HTTP-Anforderung, die Daten für eine angegebene Ressource erstellt oder schreibt. Diese Abfrage gibt den Detailgrad an, der extrahiert wird, z. B. Datenquellendetails, Semantikmodellschema, Semantikmodellausdrücke oder Benutzer*innen. Bei der Übermittlung wird von der API eine ID für den Scan zurückgegeben. Außerdem werden das Datum und die Uhrzeit der Überprüfung zurückgegeben, die Sie als Datum der Momentaufnahme verzeichnen sollten.
4. Überprüfen des Überprüfungsstatus: Verwenden Sie die in Schritt 3 abgerufene Scan-ID, um den Überprüfungsstatus zu erhalten. Möglicherweise müssen Sie diese API mehrmals aufrufen. Wenn die zurückgegebene Status Erfolg ist, können Sie mit dem nächsten Schritt fortfahren. Die Zeit, die zum Scannen benötigt wird, hängt davon ab, wie viele Daten Sie anfordern.
5. Abrufen der Ergebnisse: Verwenden Sie die Scan-ID, die in Schritt 3 abgerufen wurde, um das Überprüfungsergebnis abzurufen und die Daten zu extrahieren. Sie müssen diesen Schritt innerhalb von 24 Stunden nach Abschluss von Schritt 4 ausführen. Beachten Sie, dass der Zeitstempel der Momentaufnahme auf Schritt 3 und nicht auf Schritt 5 (bei erheblicher Verzögerung) bezogen werden sollte. Auf diese Weise erhalten Sie einen genauen Zeitstempel für die Momentaufnahme. Speichern Sie die Ergebnisse an Ihrem bevorzugten Datenspeicherspeicherort. Wie bereits in diesem Artikel beschrieben, empfiehlt es sich, die Rohdaten im ursprünglichen Zustand zu speichern.
6. Vorbereiten des nächsten Prozesses: Notieren Sie sich den Zeitstempel der Überprüfung aus Schritt 3, damit Sie ihn beim nächsten Ausführen des Prozesses in Schritt 2 verwenden können. Auf diese Weise extrahieren Sie nur Daten, die seit diesem Zeitpunkt geändert wurden. In Zukunft sind dann alle nachfolgenden Datenextrakte inkrementelle Änderungen anstelle vollständiger Momentaufnahmen.

Checkliste: Bei der Planung des Zugriffs auf die Mandantenbestandsdaten müssen die folgenden wichtigen Entscheidungen und Maßnahmen berücksichtigt werden:

• Bestätigen der Anforderungen: Klären Sie die Anforderungen an die Zusammenstellung eines Mandantenbestands und die Analyseanforderungen an die Daten ab.
• Festlegen der Häufigkeit für das Extrahieren des Mandantenbestands: Überprüfen Sie, wie oft Sie einen neuen Mandantenbestand benötigen (z. B. jede Woche).
• Entscheidung zur Art der Extraktion des Mandantenbestands: Vergewissern Sie sich, welche Methode Sie zum Abrufen der Mandantenbestandsdaten verwenden (API, Cmdlet oder Metadatenüberprüfungs-APIs).
• Durchführung eines Proof of Concept: Planen Sie die Durchführung eines kleinen technischen Proof of Concept (POC). Verwenden Sie ihn, um Ihre Entscheidungen dazu zu überprüfen, wie die endgültige Lösung erstellt werden soll.

Zugriff auf Benutzer- und Gruppendaten

Über die identifizierenden Informationen (etwa eine E-Mail-Adresse) hinaus, die in den Benutzeraktivitätsdaten enthalten sind, ist es nützlich, zusätzliche Informationen wie Standort- oder Organisationsdetails abzurufen. Sie können Microsoft Graph verwenden, um Daten zu Benutzern, Gruppen, Dienstprinzipalen und Lizenzen abzurufen. Microsoft Graph umfasst eine Reihe von APIs und Clientbibliotheken, mit denen Sie Überwachungsdaten aus einer Vielzahl von Diensten abrufen können.

Hier sehen Sie einige Details zu den Microsoft Entra-Objekten, auf die Sie zugreifen können.

• Benutzer: Eine Identität, die in Microsoft Entra ID als Geschäfts-, Schul-/Uni- oder Microsoft-Konto vorhanden ist. Der Begriff Domänenbenutzer wird häufig verwendet, um Organisationsbenutzer zu beschreiben, während der formale Begriff Benutzerprinzipalname (UPN) ist. Ein UPN ist normalerweise der gleiche Wert wie die E-Mail-Adresse des Benutzers (jedoch ändert sich bei einer Änderung der E-Mail-Adresse der UPN nicht, da er unveränderlich ist). Außerdem gibt es eine eindeutige Microsoft Graph-ID für jeden Benutzer. Oftmals ist einer Person ein Benutzerkonto zugeordnet. Einige Organisationen erstellen Benutzer, bei denen es sich um Dienstkonten handelt, die für automatisierte Aktivitäten oder verwaltungstechnische Aufgaben verwendet werden.
• Dienstprinzipal: Ein anderer Identitätstyp, der beim Erstellen einer App-Registrierung bereitgestellt wird. Ein Dienstprinzipal ist für unbeaufsichtigte, automatisierte Aktivitäten vorgesehen. Weitere Informationen finden Sie unter Bestimmen der Authentifizierungsmethode weiter unten in diesem Artikel.
• Gruppe: Eine Sammlung von Benutzern und Dienstprinzipalen. Es gibt mehrere Arten von Gruppen, die Sie verwenden können, um die Berechtigungsverwaltung zu vereinfachen. Weitere Informationen finden Sie unter Strategie für die Verwendung von Gruppen.

Hinweis

Wenn sich dieser Artikel auf Benutzer und Gruppen bezieht, umfasst dieser Begriff auch Dienstprinzipale. Dieser kürzere Begriff wird aus Gründen der Kürze verwendet.

Bei den abgerufenen Benutzer- und Gruppendaten handelt es sich um eine Momentaufnahme, die den aktuellen Zustand zu einem bestimmten Zeitpunkt beschreibt.

Tipp

Weitere Informationen zu Benutzern, Dienstprinzipalen und Gruppen finden Sie unter Integration in Microsoft Entra ID.

Analyseattribute

Für die Power BI-Überwachung auf Mandantenebene können Sie die folgenden Attribute aus Microsoft Graph extrahieren und speichern.

• Vollständiger Name der Benutzer: Viele Datenquellen enthalten nur die E-Mail-Adresse des Benutzers, der eine Aktivität ausgeführt hat oder der einer Rolle zugewiesen ist. Verwenden Sie dieses Attribut, wenn Sie den vollständigen Namen (Anzeigenamen) in Analyseberichten anzeigen möchten. Durch die Verwendung des vollständigen Namens werden Berichte benutzerfreundlicher.
• Weitere Benutzereigenschaften: Weitere beschreibende Attribute zu Benutzer*innen könnten in Microsoft Entra ID verfügbar sein. Einige Beispiele für integrierte Benutzerprofilattribute, die analytischen Wert haben, sind Position, Abteilung, Vorgesetzter, Region und Bürostandort.
• Mitglieder einer Sicherheitsgruppe: Die meisten Datenquellen geben den Namen einer Gruppe an (beispielsweise zeichnet das Power BI-Aktivitätsprotokoll auf, dass einer Sicherheitsgruppe eine Arbeitsbereichsrolle zugewiesen wurde). Das Abrufen der Gruppenmitgliedschaft verbessert Ihre Fähigkeit, umfassend zu analysieren, was ein einzelner Benutzer tut oder worauf er Zugriff hat.
• Benutzerlizenzen: Es ist nützlich, zu analysieren, welche Benutzerlizenzen – Free, Power BI Pro oder Power BI Premium-Einzelbenutzerlizenz (PPU) – Benutzern zugewiesen sind. Diese Daten können Ihnen helfen, zu identifizieren, wer seine Lizenz nicht verwendet. Es hilft Ihnen auch, alle Benutzer (Einzelbenutzer mit einer Lizenz) im Vergleich zu den aktiven Benutzern (mit aktuellen Aktivitäten) zu analysieren. Wenn Sie erwägen, Power BI Premium Lizenzen hinzuzufügen oder Ihre Lizenzen zu erweitern, empfehlen wir Ihnen, die Benutzerlizenzdaten zusammen mit Benutzeraktivitätsdaten zu analysieren, um eine Kostenanalyse durchzuführen.
• Mitglieder der Administratorrollen: Sie können eine Liste Ihrer Power BI-Administratoren zusammenstellen (dies schließt Power Platform-Administratoren und globale Administratoren ein).

Den autoritativen Verweis auf Power BI-Lizenzinformationen, die Sie in den Überwachungsdaten von Microsoft Graph finden, finden Sie unter Produktnamen und Dienstplanbezeichner für die Lizenzierung.

Tipp

Das Abrufen von Mitgliedern aus Gruppen kann einer der schwierigsten Aspekte beim Abrufen von Überwachungsdaten sein. Sie müssen eine transitive Suche durchführen, um alle geschachtelten Mitglieder und geschachtelten Gruppen flach abzubilden. Sie können eine transitive Suche nach Gruppenmitgliedern durchführen. Diese Art der Suche stellt eine besondere Herausforderung dar, wenn Ihre Organisation Tausende von Gruppen umfasst. In diesem Fall könnten bessere Alternativen zum Abrufen der Daten in Betracht gezogen werden. Eine Möglichkeit besteht darin, alle Gruppen und Gruppenmitglieder aus Microsoft Graph zu extrahieren. Dies könnte jedoch nicht praktikabel sein, wenn lediglich eine kleine Anzahl von Gruppen für die Power BI-Sicherheit verwendet wird. Eine weitere Option besteht darin, vorab eine Referenzliste von Gruppen zu erstellen, die von jedem Typ von Power BI-Sicherheit (Arbeitsbereichsrollen, App-Berechtigungen, elementweise Freigabe, Sicherheit auf Zeilenebene usw.) verwendet werden. Anschließend können Sie die Referenzliste schleifenweise durchlaufen, um Gruppenmitglieder aus Microsoft Graph abzurufen.

Hier sind einige weitere Attribute, die Sie extrahieren und speichern können.

• Benutzertyp: Benutzer sind entweder Mitglieder oder Gäste. In der Regel sind Mitglieder interne Benutzer und Gäste externe (B2B-) Benutzer. Das Speichern des Benutzertyps ist nützlich, wenn Sie die Aktivitäten externer Benutzer analysieren müssen.
• Rollenwechsel: Wenn Sie eine Sicherheitsüberwachung durchführen, ist es nützlich zu verstehen, wann ein Benutzer die Rollen in der Organisation gewechselt hat (z. B. wenn er an eine andere Abteilung übertragen wird). Auf diese Weise können Sie überprüfen, ob ihre Power BI-Sicherheitseinstellungen aktualisiert wurden oder aktualisiert werden sollten.
• Deaktivierte Benutzer: Wenn ein Benutzer die Organisation verlässt, deaktiviert in der Regel ein Administrator sein Konto. Sie können einen Prozess erstellen, um zu überprüfen, ob es sich bei deaktivierten Benutzer*innen um Arbeitsbereichsadministrator*innen oder Semantikmodellbesitzer*innen handelt.

Tipp

Das Power BI-Aktivitätsprotokoll enthält ein Ereignis, das aufzeichnet, wenn sich ein Benutzer für eine Testlizenz anmeldet. Sie können dieses Ereignis mit den Benutzerlizenzdaten (aus Microsoft Entra ID) kombinieren, um ein vollständiges Bild zu erstellen.

Abrufen von Benutzer- und Gruppendaten

Sie können Daten zu Benutzern und Gruppen auf unterschiedliche Weise abrufen.

Verfahren	Beschreibung	Gute Wahl für manuelle Überwachungsprozesse	Gute Wahl für automatisierte Überwachungsprozesse
Manuell	Graph-Explorer
Programmgesteuert	Microsoft Graph-APIs und SDKs
Programmgesteuert	Az PowerShell-Modul

Der weitere Verlauf dieses Abschnitts stellt eine Einführung in die einzelnen in der Tabelle vorgestellten Techniken dar. Weitere Techniken, die veraltet sind und nicht für neue Lösungen verwendet werden sollten, werden am Ende dieses Abschnitts beschrieben.

Hinweis

Seien Sie vorsichtig, wenn Sie Informationen online lesen, da viele Toolnamen ähnlich sind. Einige Tools im Microsoft-Ökosystem enthalten den Begriff Graph im Namen, z. B. Azure Resource Graph, GraphQL und die Microsoft Security Graph-API. Diese Tools stehen in keinem Zusammenhang mit Microsoft Graph und liegen außerhalb des Themenbereichs dieses Artikels.

Microsoft Graph-Tester

Microsoft Graph Explorer ist ein Entwicklertool, mit dem Sie mehr über Microsoft Graph-APIs erfahren können. Er stellt eine einfache Möglichkeit für den Einstieg dar, da keine weiteren Tools oder Setups auf Ihrem Computer erforderlich sind. Sie können sich anmelden, um Daten von Ihrem Mandanten abzurufen oder Beispieldaten von einem Standardmandanten abzurufen.

Sie können Graph Explorer für die folgenden Zwecke verwenden:

• Manuelles Senden einer Anforderung an eine Microsoft Graph-API, um zu überprüfen, ob sie die gewünschten Informationen zurückgibt.
• Ansehen, wie die URL, die Kopfzeilen und der Text erstellt werden, bevor Sie ein Skript schreiben.
• Überprüfen von Daten auf informelle Weise.
• Bestimmen, welche Berechtigungen für jede API erforderlich sind. Sie können außerdem die Zustimmung für neue Berechtigungen erteilen.
• Abrufen von Codeschnipseln, die beim Erstellen von Skripts verwendet werden sollen.

Verwenden Sie diesen Link, um Graph Explorer zu öffnen.

Microsoft Graph-APIs und SDKs

Verwenden Sie die Microsoft Graph-APIs, um Benutzer und Gruppendaten abzurufen. Sie können sie außerdem verwenden, um Daten aus Diensten wie Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook usw. abzurufen.

Die Microsoft Graph SDKs fungieren als API-Wrapper oberhalb der zugrunde liegenden Microsoft Graph-APIs. Ein SDK ist ein Softwareentwicklungskit, das Tools und Funktionen zusammen bündelt. Die Microsoft Graph SDKs machen den gesamten Satz der Microsoft Graph-APIs verfügbar.

Sie können sich dafür entscheiden, Anforderungen direkt an die APIs zu senden. Alternativ können Sie eine Vereinfachungsebene hinzufügen, indem Sie Ihre bevorzugte Sprache und eines der SDKs verwenden. Weitere Informationen finden Sie weiter oben in diesem Artikel unter Auswählen von APIs oder PowerShell-Cmdlets.

Die Microsoft Graph SDKs unterstützen mehrere Sprachen, und es gibt außerdem die Microsoft Graph PowerShell-Module. Weitere SDKs sind für Python, C# und andere Sprachen verfügbar.

Wichtig

Das Microsoft Graph PowerShell-Modul ersetzt die Azure AD PowerShell- und MSOnline-Module (MSOL), die beide veraltet sind. Sie sollten keine neuen Lösungen mit veralteten Modulen erstellen. Das Microsoft Graph PowerShell-Modul bietet viele Features und Vorteile. Weitere Informationen finden Sie unter Upgrade von Azure AD PowerShell auf Microsoft Graph PowerShell.

Sie können die Microsoft Graph PowerShell-Module aus dem PowerShell-Katalog installieren. Da Microsoft Graph mit vielen Microsoft 365-Diensten funktioniert, gibt es viele PowerShell-Module, die Sie installieren.

Für die Power BI-Überwachung auf Mandantenebene finden Sie hier die gängigsten PowerShell-Module, die Sie installieren müssen.

• Authentifizierung (für die Anmeldung)
• Benutzer
• Gruppen
• Anwendungen (und Dienstprinzipale)
• Verzeichnisobjekte (und Lizenzdetails)

Tipp

Microsoft aktualisiert die Microsoft Graph PowerShell-Module regelmäßig. Manchmal werden Vorschaumodule als Vorabversion oder als Betaendpunkt verfügbar gemacht. Es kann sinnvoll sein, die gewünschte Version anzugeben, wenn Sie die Module installieren und aktualisieren. Beachten Sie außerdem, wenn Sie die Onlinedokumentation durcharbeiten, dass die aktuelle Versionsnummer automatisch an das Ende der URL angefügt wird (gehen Sie daher beim Speichern oder Freigeben von URLs umsichtig vor).

Az PowerShell-Modul

Sie können auch das Az PowerShell-Modul verwenden, um Benutzer- und Gruppendaten abzurufen. Sein Schwerpunkt liegt auf Azure-Ressourcen.

Wichtig

Das Az PowerShell-Modul ersetzt die AzureRM PowerShell-Module, die veraltet sind. Sie sollten keine neuen Lösungen mit veralteten Modulen erstellen.

Sie können das Cmdlet Invoke-AzRestMethod verwenden, wenn kein entsprechendes Cmdlet für eine API vorhanden ist. Dies stellt einen flexiblen Ansatz dar, mit dem Sie mithilfe des Az PowerShell-Moduls eine Anforderung an beliebige Microsoft Graph-APIs senden können.

Ab Az Version 7 verweisen die Az-Cmdlets jetzt auf die Microsoft Graph-API. Daher fungiert das Az-Modul als API-Wrapper oberhalb von Microsoft Graph. Die Az-Module weisen eine Teilmenge der Funktionen auf, die in den Microsoft Graph-APIs und PowerShell-Modulen enthalten sind. Für neue Lösungen empfiehlt es sich, das Microsoft Graph PowerShell SDK zu verwenden.

Veraltete APIs und Module

Möglicherweise finden Sie online Artikel und Blogbeiträge, die alternative Optionen vorschlagen, die in diesem Abschnitt nicht vorgestellt werden. Es wird dringend empfohlen, keine neuen Lösungen zu erstellen (und/oder Ihre vorhandenen Lösungen zu migrieren), indem Sie eine der folgenden APIs oder eins der folgenden Module verwenden.

• AzureRM PowerShell-Module: Veraltet und werden demnächst eingestellt. Sie wurden durch das Az PowerShell-Modul ersetzt.
• Azure AD Graph-API und Azure AD PowerShell-Modul: Veraltet und werden demnächst eingestellt. Diese Änderung ist das Ergebnis der Migration von Azure AD Graph zu Microsoft Graph („Graph“ kommt zwar in beiden Namen vor, die zukünftige Richtung ist aber Microsoft Graph). Alle zukünftigen PowerShell-Investitionen erfolgen im Microsoft Graph PowerShell SDK. (Microsoft Entra ID ist jetzt als Microsoft Entra ID bekannt.)
• PowerShell-Modul für MS Online (MSOL): Veraltet und wird demnächst eingestellt. Alle zukünftigen PowerShell-Investitionen erfolgen im Microsoft Graph PowerShell SDK.

Achtung

Vergewissern Sie sich, den Status aller veralteten APIs oder Module zu bestätigen, die Sie derzeit verwenden. Weitere Informationen zur Einstellung von AzureRM finden Sie in dieser Ankündigung.

Weitere Informationen zu Microsoft Entra ID und MSOL finden Sie in diesem Beitrag zur Ankündigung der Einstellung.

Wenn Sie Fragen haben oder eine Klarstellung über die zukünftige Richtung des programmgesteuerten Datenzugriffs benötigen, wenden Sie sich an Ihr Microsoft-Kontoteam.

Checkliste: Die Planung des Zugriffs auf Benutzer- und Gruppendaten beinhaltet die folgenden wichtigen Entscheidungen und Maßnahmen:

• Bestätigen der Anforderungen: Klären Sie die Anforderungen für die Kompilierung von Daten im Zusammenhang mit Benutzern, Gruppen und Lizenzen.
• Priorisieren von Anforderungen: Vergewissern Sie sich, was die wichtigsten Prioritäten sind, damit Sie wissen, wofür Sie vorrangig Zeit aufwenden müssen.
• Entscheiden über die Häufigkeit der Datenextraktion: Legen Sie fest, wie oft Sie eine neue Momentaufnahme der Benutzer- und Gruppendaten benötigen (z. B. jede Woche oder jeden Monat).
• Entscheiden über die Extraktion von Daten mit Microsoft Graph: Legen Sie fest, welche Methode Sie zum Abrufen der Daten verwenden möchten.
• Erstellen eines Proof of Concept: Planen Sie die Durchführung eines kleinen technischen Proof of Concept (POC), um Benutzer- und Gruppendaten zu extrahieren. Verwenden Sie ihn, um Ihre Entscheidungen dazu zu überprüfen, wie die endgültige Lösung erstellt werden soll.

Zugreifen auf Daten über Power BI-REST-APIs

Möglicherweise als niedrigere Priorität können Sie auch andere Daten mithilfe der Power BI-REST-APIs abrufen.

Sie können beispielsweise Daten zu folgenden Informationen abrufen:

• Alle Apps in der Organisation.
• Alle importierten Semantikmodelle in der Organisation.
• Alle Bereitstellungspipelines in der Organisation.
• Alle Premium-Kapazitäten in der Organisation.

Während einer Sicherheitsüberwachung sollten Sie Folgendes ermitteln:

• Elemente, die für die gesamte Organisation umfassend freigegeben wurden.
• Elemente, die aufgrund ihrer Veröffentlichung im Web im öffentlichen Internet verfügbar sind.

Weitere Informationen zur Verwendung der anderen API-Typen finden Sie weiter oben in diesem Artikel unter Auswählen einer Benutzer- oder Administrator-API.

Checkliste: Bei der Planung des Zugriffs auf Daten über die Power BI-APIs zählen diese zu den wichtigsten Entscheidungen und Maßnahmen:

• Abrufen von Anforderungen: Sammeln sie Analyseanforderungen, sobald sie auftreten. Verfolgen Sie sie in Ihrem Backlog nach.
• Priorisieren von Anforderungen: Legen Sie Prioritäten für die neuen Anforderungen fest, die sich ergeben.

Phase 2: Voraussetzungen und Setup

Die zweite Phase der Planung und Implementierung einer Überwachungslösung auf Mandantenebene legt den Schwerpunkt auf die Voraussetzungen und das Setup, die abgearbeitet werden müssen, bevor Sie mit der Entwicklung der Lösung beginnen.

Speicherkonto erstellen

An diesem Punkt haben Sie sich für einen Speicherort zum Speichern von Rohdaten und für die Art der Erstellung kuratierter Daten entschieden. Auf der Grundlage dieser Entscheidungen können Sie nun ein Speicherkonto erstellen. Abhängig von den Prozessen Ihrer Organisation kann dazu eine Anforderung an die IT erforderlich sein.

Wie bereits beschrieben, empfehlen wir die Verwendung einer Technologie, mit der Sie die Rohdaten in unveränderlichen Speicher schreiben können. Nachdem die Daten geschrieben wurden, können sie nicht mehr geändert oder gelöscht werden. Sie können dann auf die Rohdaten vertrauen, da Sie wissen, dass ein Administrator mit Zugriff sie in keiner Weise ändern kann. Die kuratierten Daten müssen jedoch (in der Regel) nicht in unveränderlichem Speicher gespeichert werden. Kuratierte Daten können sich ändern oder neu aufbereitet werden.

Checkliste: Beim Erstellen eines Speicherkontos sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Erstellen eines Speicherkontos: Erstellen Sie ein Speicherkonto, oder senden Sie eine Anforderung zum Erstellen eines Speicherkontos. Verwenden Sie, wann immer möglich, in Bezug auf die Rohdaten Einstellungen für den unveränderlichen Speicher.
• Festlegen von Berechtigungen: Legen Sie fest, welche Berechtigungen für das Speicherkonto festgelegt werden sollen.
• Testzugriff: Führen Sie einen kleinen Test durch, um sicherzustellen, dass Sie das Speicherkonto lesen und schreiben können.
• Bestätigen der Zuständigkeiten: Vergewissern Sie sich, dass abgeklärt ist, wer die fortlaufende Verwaltung des Speicherkontos übernimmt.

Installieren von Software und Einrichten von Diensten

An diesem Punkt haben Sie Ihre Entscheidungen dazu getroffen, welche Technologie für den Zugriff auf Überwachungsdaten verwendet werden soll. Ausgehend von diesen Entscheidungen können Sie nun Software installieren und Dienste einrichten.

Richten Sie die bevorzugte Entwicklungsumgebung für jeden Administrator ein. Die Entwicklungsumgebung ermöglicht es ihnen, Skripts zu schreiben und zu testen. Visual Studio Code ist ein modernes Tool zum Entwickeln von Skripts, daher ist es eine gute Option. Außerdem sind viele Erweiterungen für die Arbeit mit Visual Studio Code verfügbar.

Wenn Sie sich für die Verwendung von PowerShell entschieden haben (weitere oben beschrieben), sollten Sie PowerShell Core und die erforderlichen PowerShell-Module auf den folgenden Computern/in den folgenden Diensten installieren:

• Dem Computer jedes Administrators/Entwicklers, der Überwachungsskripts schreibt oder testet.
• Jedem virtuellen Computer oder Server, auf dem geplante Skripts ausgeführt werden sollen.
• Jedem Onlinedienst (z. B. Azure Functions oder Azure Automation).

Wenn Sie Azure-Dienste (z. B. Azure Functions, Azure Automation, Azure Data Factory oder Azure Synapse Analytics) verwenden möchten, sollten Sie diese ebenfalls bereitstellen und einrichten.

Checkliste: Bei der Installation von Software und der Einrichtung von Diensten sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Einrichten von Administrator-/Entwicklercomputern: Installieren Sie ggf. die erforderlichen Tools, die für die Entwicklung verwendet werden.
• Einrichten von Servern: Installieren Sie ggf. die erforderlichen Tools auf allen Servern oder virtuellen Computern, die in Ihrer Architektur vorhanden sind.
• Einrichten von Azure-Diensten: Stellen Sie ggf. die einzelnen Azure-Dienste bereit, und richten Sie sie ein. Weisen Sie jedem Administrator/Entwickler, der Entwicklungsarbeiten ausführt, Berechtigungen zu.

Registrieren einer Microsoft Entra-Anwendung

An diesem Punkt haben Sie die Entscheidung zum Authentifizierungsverfahren getroffen. Es wird empfohlen, eine Microsoft Entra-Anwendung (Dienstprinzipal) zu registrieren. Sie wird häufig als App-Registrierung bezeichnet und sollte für unbeaufsichtigte Vorgänge verwendet werden, die Sie automatisieren.

Weitere Informationen zum Erstellen einer App-Registrierung zum Abrufen von Überwachungsdaten auf Mandantenebene finden Sie unter Aktivieren der Dienstprinzipalauthentifizierung für schreibgeschützte Administrator-APIs.

Checkliste: Beim Registrieren einer Microsoft Entra-Anwendung sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Überprüfen, ob bereits eine App-Registrierung vorhanden ist: Überprüfen Sie zusammen mit der IT, ob eine vorhandene App-Registrierung zum Ausführen von Administrator-APIs verfügbar ist. Wenn ja, bestimmen Sie, ob die vorhandene verwendet werden oder ob eine neue erstellt werden soll.
• Erstellen einer neuen App-Registrierung: Erstellen Sie ggf. eine App-Registrierung. Erwägen Sie die Verwendung eines App-Namens wie PowerBI-AdminAPIs-EntraApp, der den Zweck eindeutig beschreibt.
• Erstellen eines Geheimnisses für die App-Registrierung: Sobald die App-Registrierung vorhanden ist, erstellen Sie ein Geheimnis dafür. Legen Sie das Ablaufdatum basierend darauf fest, wie oft Sie das Geheimnis rotieren möchten.
• Sicheres Speichern der Werte: Speichern Sie das Geheimnis, die App-ID (Client-ID) und die Mandanten-ID, da Sie sie für die Authentifizierung beim Dienstprinzipal benötigen. Verwenden Sie einen sicheren Speicherort, z. B. einen organisationsweiten Kennworttresor. (Wenn Sie die Erstellung einer App-Registrierung bei der IT anfordern müssen, geben Sie an, dass diese Werte an Sie zurückgegeben werden müssen.)
• Erstellen einer Sicherheitsgruppe: Erstellen Sie eine Sicherheitsgruppe (oder fordern Sie deren Erstellung an), die für Power BI verwendet wird. Erwägen Sie die Verwendung eines Gruppennamens wie Power BI-Administratordienstprinzipale, der anzeigt, dass die Gruppe für den Zugriff auf mandantenweite Metadaten verwendet wird.
• Hinzufügen des Dienstprinzipals als Mitglied der Sicherheitsgruppe: Verwenden Sie die App-ID (Client-ID), um den neuen (oder vorhandenen) Dienstprinzipal als Mitglied der neuen Sicherheitsgruppe hinzuzufügen.
• Aktualisieren der Administrator-API-Mandanteneinstellung in Power BI: Fügen Sie im Power BI-Verwaltungsportal die Sicherheitsgruppe der Mandanteneinstellung Zulassen der Verwendung schreibgeschützter Power BI-Administrator-APIs durch Dienstprinzipale hinzu.
• Zuweisen von Berechtigungen in Azure überspringen: Delegieren Sie keine Berechtigungen an die App-Registrierung (sie erhält Zugriff auf die Power BI-Überwachungsdaten auf Mandantenebene über die Power BI-Mandanteneinstellung Zulassen der Verwendung schreibgeschützter Power BI-Administrator-APIs durch Dienstprinzipale).
• Entscheidung, ob die App-Registrierung Zugriff auf detaillierte Metadaten erhalten soll: Legen Sie fest, ob Sie beim Erstellen Ihres Mandantenbestands detaillierte Informationen zu Semantikmodelltabellen, Spalten und Measureausdrücken extrahieren möchten.
• Aktualisieren der Mandanteneinstellungen für detaillierte Metadaten in Power BI: Fügen Sie optional im Power BI-Verwaltungsportal die Sicherheitsgruppe der Mandanteneinstellung Administrator-API-Antworten mit detaillierten Metadaten anreichern und ebenso die Mandanteneinstellung Administrator-API-Antworten mit DAX- und Mashupausdrücken anreichern hinzu.
• Testen des Dienstprinzipals: Erstellen Sie ein einfaches Skript für die Anmeldung mithilfe des Dienstprinzipals, und testen Sie, ob Daten von einer Administrator-API abgerufen werden können.
• Erstellen eines Prozesses zum Verwalten von App-Registrierungsgeheimnissen: Erstellen Sie Dokumentation und einen Prozess für die regelmäßige Rotation von Geheimnissen. Bestimmen Sie, wie Sie allen Administratoren und Entwicklern, die es benötigen, ein neues Geheimnis auf sichere Weise übermitteln.

Festlegen von Power BI-Mandanteneinstellungen

Im Power BI-Verwaltungsportal gibt es mehrere Mandanteneinstellungen, die für das Extrahieren von Überwachungsdaten auf Mandantenebene relevant sind.

Administrator-APIs

Es gibt drei Mandanteneinstellungen, die für die Ausführung von Administrator-APIs relevant sind.

Wichtig

Da diese Einstellungen Metadatenzugriff für den gesamten Mandanten erteilen (ohne direkte Power BI-Berechtigungen zuzuweisen), sollten Sie sie engmaschig kontrollieren.

Mit der Mandanteneinstellung Zulassen der Verwendung schreibgeschützter Power BI-Administrator-APIs durch Dienstprinzipale können Sie festlegen, welche Dienstprinzipale Administrator-APIs aufrufen können. Mit dieser Einstellung kann Microsoft Purview auch den gesamten Power BI-Mandanten überprüfen, um den Datenkatalog aufzufüllen.

Hinweis

Sie brauchen der Mandanteneinstellung Zulassen der Verwendung schreibgeschützter Power BI-Administrator-APIs durch Dienstprinzipale nicht explizit weitere Power BI-Administratoren zuzuweisen, da diese bereits Zugriff auf mandantenweite Metadaten haben.

Mit der Einstellung Administrator-API-Antworten mit detaillierten Metadaten anreichern können Sie festlegen, welche Benutzer und Dienstprinzipale detaillierte Metadaten abrufen können. Metadaten werden mithilfe der Metadatenüberprüfungs-APIs abgerufen und umfassen unter anderem Tabellen und Spalten. Mit dieser Einstellung kann Microsoft Purview auch auf Informationen zu Power BI-Semantikmodellen auf Schemaebene zugreifen, damit sie im Datenkatalog gespeichert werden können.

Mit der Einstellung Administrator-API-Antworten mit DAX- und Mashupausdrücken anreichern können Sie festlegen, welche Benutzer und Dienstprinzipale detaillierte Metadaten abrufen können. Metadaten werden aus den Metadatenüberprüfungs-APIs abgerufen und können Abfragen und Measureausdrücke für Semantikmodelle enthalten.

Hinweis

Die Mandanteneinstellung Zulassen der Verwendung schreibgeschützter Power BI-Administrator-APIs durch Dienstprinzipale betrifft insbesondere den Zugriff auf Administrator-APIs. Ihr Name ähnelt sehr der Mandanteneinstellung, die für den Zugriff auf Benutzer-APIs vorgesehen ist (als nächster Punkt beschrieben). Weitere Informationen zum Unterschied zwischen Administrator-APIs und Benutzer-APIs finden Sie weiter oben in diesem Artikel unter Auswählen einer Benutzer- oder Administrator-API.

Benutzer-APIs

Es gibt eine Mandanteneinstellung, die sich auf das Aufrufen von Benutzer-APIs bezieht. In dieser Situation sind außerdem Power BI-Berechtigungen für den Dienstprinzipal erforderlich (z. B. eine Arbeitsbereichsrolle).

Mit der Mandanteneinstellung Dienstprinzipalen die Verwendung von Power BI-APIs gestatten können Sie festlegen, welche Dienstprinzipale Zugriff auf die Ausführung von REST-APIs haben (mit Ausnahme der Administrator-APIs, die durch eine andere Mandanteneinstellung erteilt werden, wie oben beschrieben).

Es gibt weitere Mandanteneinstellungen im Zusammenhang mit APIs, die den Zugriff auf die Einbettungs-APIs, Streaming-APIs, Export-APIs und die API zur Abfrageausführung ermöglichen. Diese APIs liegen jedoch außerhalb des Bereichs dieses Artikels.

Weitere Informationen zu den Mandanteneinstellungen für Nutzungsmetriken finden Sie unter Überwachung auf Berichtsebene.

Checkliste: Diese wichtigen Entscheidungen und Maßnahmen sind beim Einrichten der Power BI-Mandanteneinstellungen zu berücksichtigen:

• Vergewisserung, dass sich jeder Dienstprinzipal in der richtigen Gruppe befindet: Vergewissern Sie sich, dass die Gruppe Power BI-Administratordienstprinzipale die richtigen Dienstprinzipale enthält.
• Aktualisieren der Administrator-API-Mandanteneinstellung in Power BI: Fügen Sie die Sicherheitsgruppe zur Mandanteneinstellung Zulassen der Verwendung schreibgeschützter Power BI-Administrator-APIs durch Dienstprinzipale hinzu, damit mithilfe der Administrator-APIs mandantenweite Metadaten abgerufen werden können.
• Aktualisieren der Mandanteneinstellungen für detaillierte Metadaten in Power BI: Fügen Sie bei Bedarf die Sicherheitsgruppe der Mandanteneinstellung Administrator-API-Antworten mit detaillierten Metadaten anreichern und die Mandanteneinstellung Administrator-API-Antworten mit DAX- und Mashupausdrücken anreichern hinzu.
• Bestätigen, auf welche Benutzer-APIs zugegriffen wird: Überprüfen Sie, ob mindestens eine Benutzer-APIs erforderlich ist (über die Verwendung der Administrator-APIs hinaus).
• Aktualisieren der Benutzer-API-Mandanteneinstellung in Power BI: Fügen Sie die Sicherheitsgruppe zur Mandanteneinstellung Dienstprinzipalen die Verwendung von Power BI-APIs gestatten hinzu, die für Benutzer-APIs vorgesehen ist.

Phase 3: Entwicklung und Analyse von Lösungen

Die dritte Phase der Planung und Implementierung einer Überwachungslösung auf Mandantenebene legt den Schwerpunkt auf die Lösungsentwicklung und -analyse. An diesem Punkt wurden die gesamte Planung und alle Entscheidungen festgelegt, und Sie haben die Voraussetzungen erfüllt und die Einrichtung abgeschlossen. Sie können jetzt mit der Lösungsentwicklung beginnen, damit Sie Analysen durchführen und Erkenntnisse aus Ihren Überwachungsdaten gewinnen können.

Extrahieren und Speichern der Rohdaten

An diesem Punkt sollten Ihre Anforderungen und Prioritäten klar sein. Die wichtigen technischen Entscheidungen über den Zugriff auf Überwachungsdaten und den Speicherort für Überwachungsdaten wurden getroffen. Bevorzugte Tools wurden ausgewählt, und die Voraussetzungen und Einstellungen wurden eingerichtet. In den beiden vorangegangenen Phasen haben Sie möglicherweise ein oder mehrere kleine Projekte (Proofs of Concept) abgeschlossen, um die Machbarkeit nachzuweisen. Der nächste Schritt besteht darin, einen Prozess einzurichten, um die rohen Überwachungsdaten zu extrahieren und zu speichern.

Wie bei Daten, die von den meisten Microsoft-APIs zurückgegeben werden, weisen Überwachungsdaten das JSON-Format auf. JSON-formatierte Daten sind selbstbeschreibend, da es sich um lesbaren Text handelt, der Struktur und Daten enthält.

JSON stellt Datenobjekte dar, die aus Attribut-Wert-Paaren und Arrays bestehen. So stellt etwa "state": "Active" ein Beispiel dar, in dem der Wert des Attributs stateActive lautet. Ein JSON-Array enthält eine geordnete Liste von Elementen, die durch Kommas getrennt und in Klammern ([ ]) eingeschlossen sind. In JSON-Ergebnissen finden sich oftmals geschachtelte Arrays. Wenn Sie sich mit der hierarchischen Struktur eines JSON-Ergebnisses vertraut gemacht haben, ist die Datenstruktur leicht zu verstehen – beispielsweise eine Liste (Array) von Semantikmodellen in einem Arbeitsbereich.

Hier sehen Sie einige Überlegungen zum Extrahieren und Speichern der Rohdaten, die von den APIs abgerufen werden.

• Welche Namenskonvention wird verwendet? Für ein dateibasiertes System ist eine Namenskonvention für Dateien, Ordner und Data Lake-Zonen erforderlich. Bei Datenbanken ist eine Namenskonvention für Tabellen und Spalten erforderlich.
• Welches Format soll zum Speichern der Rohdaten verwendet werden? Da Power BI immer wieder neue Funktionen einführt, werden auch neue Aktivitäten erscheinen, die es heute noch nicht gibt. Aus diesem Grund empfiehlt es sich, die ursprünglichen JSON-Ergebnisse zu extrahieren und aufzubewahren. Analysieren, filtern oder formatieren Sie die Daten nicht, während sie extrahiert werden. Auf diese Weise können Sie die ursprünglichen Rohdaten verwenden, um Ihre kuratierten Überwachungsdaten neu zu generieren.
• Welcher Speicherort soll verwendet werden? Zum Speichern von Rohdaten wird oftmals ein Data Lake- oder Blobspeicher verwendet. Weitere Informationen finden Sie weiter oben in diesem Artikel unter Bestimmen des Speicherorts von Überwachungsdaten.
• Wie viel Verlauf möchten Sie speichern? Exportieren Sie die Überwachungsdaten an einen Speicherort, an dem Sie den Verlauf speichern können. Planen Sie, mindestens zwei Jahre Verlauf anzusammeln. Auf diese Weise können Sie Trends und Änderungen über den standardmäßigen Aufbewahrungszeitraum von 30 Tagen hinaus analysieren. Sie können sich entscheiden, die Daten unbegrenzt zu speichern, oder Sie entscheiden sich für einen kürzeren Zeitraum, abhängig von den Datenaufbewahrungsrichtlinien für Ihre Organisation.
• Wie soll die letzte Ausführung des Prozesses nachverfolgt werden? Richten Sie eine Konfigurationsdatei oder eine gleichwertige Lösung ein, um die Zeitstempel aufzuzeichnen, wenn ein Prozess gestartet und abgeschlossen wird. Bei der nächsten Ausführung des Prozesses kann sie diese Zeitstempel abrufen. Es ist insbesondere wichtig, die Zeitstempel zu speichern, wenn Sie Daten mithilfe der Metadatenüberprüfungs-APIs extrahieren.
• Wie möchten Sie mit Drosselung umgehen? Einige Power BI-REST-APIs und die Microsoft Graph-API implementieren eine Drosselung. Es wird ein Fehler 429 (zu viele Anforderungen) ausgegeben, wenn Ihre API-Anforderung gedrosselt wird. Drosselung kann ein häufiges Problem für größere Organisationen sein, die eine große Menge an Daten abrufen müssen. Wie Sie aufgrund von Drosselung fehlschlagende Versuche vermeiden, hängt von der Technologie ab, mit der Sie auf die Daten zugreifen und diese extrahieren. Eine Möglichkeit besteht darin, Logik in Ihren Skripts zu entwickeln, die auf einen Fehler 429 „Zu viele Anforderungen“ reagiert, indem sie sie Ausführung nach einer Wartezeit wiederholt.
• Sind die Überwachungsdaten aus Gründen der Compliance erforderlich? Viele Organisationen verwenden die rohen Überwachungsprotokolldatensätze, um Complianceüberwachungen durchzuführen oder auf Sicherheitsuntersuchungen zu reagieren. In diesen Fällen wird dringend empfohlen, die Rohdaten in unveränderlichem Speicher zu speichern. Auf diese Weise können die Daten nach dem Schreiben nicht mehr von einem Administrator oder einem anderen Benutzer geändert oder gelöscht werden.
• Welche Speicherebenen sind erforderlich, um Ihre Anforderungen zu erfüllen? Die besten Speicherorte für Rohdaten sind ein Data Lake (z. B. Azure Data Lake Storage Gen2) oder Objektspeicher (wie Azure Blob Storage). Ein Dateisystem kann ebenfalls verwendet werden, wenn Clouddienste keine Option sind.

Checkliste: Beim Extrahieren und Speichern der Rohdaten sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Bestätigen von Anforderungen und Prioritäten: Klären Sie die Anforderungen und Prioritäten für die Daten ab, die Sie zuerst extrahieren.
• Bestätigen der Quelle der zu extrahierenden Daten: Überprüfen Sie die Quelle für jeden Datentyp, den Sie benötigen.
• Einrichten eines Prozesses, um die Daten zu extrahieren und sie in die Rohdatenzone zu laden: Erstellen Sie den Anfangsprozess zum Extrahieren und Laden der Rohdaten im ursprünglichen Zustand ohne Transformationen. Testen Sie, ob der Prozess wie beabsichtigt funktioniert.
• Erstellen eines Zeitplans zum Ausführen der Prozesse: Richten Sie einen wiederkehrenden Zeitplan ein, um die Prozesse zum Extrahieren, Laden und Transformieren auszuführen.
• Überprüfen, ob die Anmeldeinformationen sicher verwaltet werden: Vergewissern Sie sich, dass Kennwörter, Geheimnisse und Schlüssel auf sichere Weise gespeichert und übermittelt werden.
• Bestätigen, dass die Sicherheit ordnungsgemäß eingerichtet ist: Vergewissern Sie sich, dass Zugriffsberechtigungen für die Rohdaten ordnungsgemäß eingerichtet sind. Stellen Sie sicher, dass Administratoren und Prüfer auf die Rohdaten zugreifen können.

Weitere Informationen dazu, wie eine Überwachungslösung im Laufe der Zeit wächst, finden Sie weiter unten in diesem Artikel unter Operationalisieren und Verbessern.

Erstellen der kuratierten Daten

An diesem Punkt wurden die Rohdaten extrahiert und gespeichert. Der nächste Schritt ist die Erstellung einer separaten Golddatenebene für die kuratierten Daten. Ziel ist es, die Datendateien zu transformieren und in einem Sternschema zu speichern. Ein Sternschema umfasst Dimensionstabellen und Faktentabellen und ist absichtlich für die Analyse und Berichterstellung optimiert. Die Dateien in der kuratierten Datenebene werden zur Quelle eines Power BI-Datenmodells (im nächsten Thema beschrieben).

Tipp

Wenn Sie damit rechnen, mit mehr als einem Datenmodell zu arbeiten, ist die Investition in eine zentralisierte kuratierte Datenebene besonders nützlich.

Checkliste: Beim Erstellen der kuratierten Datenebene sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Bestätigen von Anforderungen und Prioritäten: Wenn Sie eine zwischengeschaltete Silberschicht für die transformierten Daten verwenden möchten, klären Sie die Anforderungen und zu erreichenden Ziele ab.
• Einrichten eines Prozesses, um die Rohdaten zu transformieren und in die kuratierte Datenzone zu laden: Erstellen Sie einen Prozess zum Transformieren und Laden der Daten in ein Sternschema. Testen Sie, ob der Prozess wie beabsichtigt funktioniert.
• Erstellen eines Zeitplans zum Ausführen der Prozesse: Richten Sie einen wiederkehrenden Zeitplan ein, um die kuratierte Datenebene aufzufüllen.
• Bestätigen, dass die Sicherheit ordnungsgemäß eingerichtet ist: Vergewissern Sie sich, dass Zugriffsberechtigungen für die kuratierten Daten ordnungsgemäß eingerichtet sind. Stellen Sie sicher, dass Entwickler des Datenmodells auf die kuratierten Daten zugreifen können.

Erstellen eines Datenmodells

In diesem Thema geht es um das Einrichten eines analytischen Datenmodells. Ein Datenmodell ist eine abfragbare Datenressource, die für Analysen optimiert ist. Manchmal wird es als semantisches Modell oder einfach als Modell bezeichnet. Für Ihre Überwachungslösung wird das Datenmodell wahrscheinlich als Power BI-Semantikmodell implementiert.

Im Kontext der Überwachung bezieht ein Datenmodell Daten aus der kuratierten (goldenen) Datenebene. Wenn Sie sich dafür entscheiden, keine kuratierte Datenebene zu erstellen, bezieht das Datenmodell seine Daten direkt aus den Rohdaten.

Es empfiehlt sich, Ihr Power BI-Datenmodell nach einem Sternschemaentwurf zu implementieren. Wenn es sich bei den Quelldaten um die kuratierte Datenebene handelt, sollte das Sternschema des Power BI-Datenmodells das Sternschema der kuratierten Datenebene spiegeln.

Tipp

Eine Übersicht zum Sternschemaentwurf finden Sie unter Informationen zum Sternschema und der Bedeutung für Power BI.

Wie bei jedem Power BI-Projekt ist das Erstellen eines Datenmodells ein iterativer Prozess. Sie können nach Bedarf neue Measures hinzufügen. Sie können außerdem neue Tabellen und Spalten hinzufügen, wenn neue Überwachungsereignisse verfügbar werden. Im Lauf der Zeit können Sie sogar neue Datenquellen integrieren.

Hier sehen Sie einige nützliche Dimensionstabellen, die Sie in das Datenmodell aufnehmen können.

• Datum: Eine Reihe von Datumsattributen, um die Analyse (Slicing und Dicing) von Daten nach Tag, Woche, Monat, Quartal, Jahr und anderen relevanten Zeiträumen zu ermöglichen.
• Uhrzeit: Wenn Sie nach Tageszeit analysieren müssen und Sie über eine sehr große Menge an Überwachungsdaten verfügen, sollten Sie den Uhrzeitteil separat vom Datum speichern. Dieser Ansatz kann helfen, die Abfrageleistung zu verbessern.
• Benutzer: Attribute, die Benutzer beschreiben (z. B. Abteilung und geografische Region), die viele Themen von Überwachungsdaten filtern können. Ziel ist es, alle Benutzerdetails aus den Faktentabellen zu entfernen und in dieser Dimensionstabelle zu speichern, damit sie zur Filterung vieler Faktentabellen dienen können. Sie können in dieser Tabelle auch Dienstprinzipale speichern.
• Aktivitätsereignisse: Attribute, mit denen die Aktivitätsereignisse (Vorgänge) gruppiert und beschrieben werden. Zum Verbessern der Berichterstellung können Sie ein Datenwörterbuch erstellen, das die einzelnen Aktivitätsereignisse beschreibt. Sie können auch eine Hierarchie erstellen, die ähnliche Aktivitätsereignisse gruppiert und klassifiziert. Beispielsweise können Sie alle Erstellungsereignisse für Elemente, Löschereignisse usw. gruppieren.
• Arbeitsbereiche: Eine Liste der Arbeitsbereiche in den Mandanten- und Arbeitsbereichseigenschaften, z. B. Typ (persönlich oder Standard) und Beschreibung. Einige Organisationen zeichnen weitere Details zu Arbeitsbereichen auf (möglicherweise mithilfe einer SharePoint-Liste). Sie können diese Details in diese Dimensionstabelle integrieren. Sie müssen entscheiden, ob in dieser Dimensionstabelle nur der aktuelle Status des Arbeitsbereichs oder versionierte Daten gespeichert werden, die erhebliche Änderungen des Arbeitsbereichs im Lauf der Zeit widerspiegeln. Wenn sich beispielsweise ein Arbeitsbereichsname ändert, zeigt die verlaufsbezogene Berichterstellung den aktuellen Arbeitsbereichsnamen oder den Arbeitsbereichsnamen, der zu diesem Zeitpunkt aktuell war? Weitere Informationen zur Versionsverwaltung finden Sie unter Langsam veränderliche Dimensionen.
• Elementtypen: Eine Liste von Power BI-Elementtypen (Semantikmodelle, Berichte und Ähnliches).
• Kapazitäten: Eine Liste der Premium-Kapazitäten im Mandanten.
• Gateways: Eine Liste der Datengateways im Mandanten.
• Datenquellen: Eine Liste der Datenquellen, die von jedem Semantikmodell, Dataflow oder Datamart verwendet werden.

Hier sehen Sie einige nützliche Faktentabellen (Themen), die Sie in das Datenmodell aufnehmen können.

• Benutzeraktivitäten: Die Faktendaten, die aus den ursprünglichen JSON-Daten stammen. Alle Attribute, die keinen analytischen Wert aufweisen, werden entfernt. Alle Attribute, die in die Dimensionstabellen (oben) gehören, werden ebenfalls entfernt.
• Mandantenbestand: Eine Momentaufnahme aller im Mandanten veröffentlichten Elemente zu einem bestimmten Zeitpunkt. Weitere Informationen finden Sie unter Mandantenbestand weiter oben in diesem Artikel.
• Semantikmodell: Schließt Benutzeraktivitäten ein, die Semantikmodelle (etwa Änderungen an Semantikmodellen) oder verwandte Datenquellen betreffen.
• Semantikmodellaktualisierungen: Speichert Datenaktualisierungsvorgänge, einschließlich Details zum Typ (geplant oder bei Bedarf), zur Dauer, zum Status und zu dem Benutzer bzw. zu der Benutzerin, der bzw. die den Vorgang initiiert hat.
• Arbeitsbereichsrollen: Eine Momentaufnahme von Arbeitsbereichs-Rollenzuweisungen zu einem bestimmten Zeitpunkt.
• Benutzerlizenzen: Eine Momentaufnahme von Benutzerlizenzen zu einem bestimmten Zeitpunkt. Möglicherweise sind Sie versucht, die Benutzerlizenz in der Dimensionstabelle Benutzer zu speichern – jedoch unterstützt dieser Ansatz keine Analyse von Lizenzänderungen und -trends im zeitlichen Ablauf.
• Benutzergruppenmitgliedschaften: Eine Momentaufnahme von Benutzern (und Dienstprinzipalen), die einer Sicherheitsgruppe zugewiesen sind, zu einem bestimmten Zeitpunkt.
• Communityaktivitäten: Enthält communitybezogene Fakten wie Schulungsveranstaltungen. Beispielsweise können Sie Power BI-Benutzeraktivitäten im Bezug zur Schulungsteilnahme analysieren. Diese Daten könnten dem Kompetenzzentrum helfen, potenzielle neue Champions zu identifizieren.

Faktentabellen sollten keine Spalten enthalten, die von Berichtserstellern gefiltert werden. Stattdessen gehören diese Spalten zu den zugeordneten Dimensionstabellen. Dieser Entwurf ist nicht nur effizienter für Abfragen, sondern fördert auch die Wiederverwendung von Dimensionstabellen durch mehrere Fakten (sogenanntes Drill Across). Dieser letzte Punkt ist wichtig, um ein nützliches und benutzerfreundliches Datenmodell zu erstellen, das erweiterbar ist, wenn neue Faktentabellen (Themen) hinzugefügt werden.

Beispielsweise bezieht sich die Dimensionstabelle Benutzer auf jede Faktentabelle. Sie sollte auf die Faktentabelle Benutzeraktivitäten (wer hat die Aktivität ausgeführt), die Faktentabelle Mandantenbestand (wer hat das veröffentlichte Element erstellt) und alle anderen Faktentabellen bezogen sein. Wenn ein Bericht in der Dimensionstabelle Benutzer nach einem Benutzer filtert, können visuelle Elemente in diesem Bericht Fakten für den betreffenden Benutzer aus jeder verwandten Faktentabelle anzeigen.

Stellen Sie beim Entwerfen Ihres Modells sicher, dass ein Attribut einmal und nur einmal im Modell sichtbar ist. Beispielsweise sollte die E-Mail-Adresse des Benutzers nur in der Dimensionstabelle Benutzer auftreten. Sie wird in anderen Faktentabellen ebenfalls vorhanden sein (als Dimensionsschlüssel zur Unterstützung einer Modellbeziehung). Jedoch sollten Sie sie in jeder Faktentabelle ausblenden.

Es empfiehlt sich, Ihr Datenmodell getrennt von Berichten zu erstellen. Die Entkopplung eines Semantikmodells und seiner Berichte führt zu einem zentralisierten Semantikmodell, das für viele Berichte herangezogen werden kann. Weitere Informationen zur Wiederverwendung freigegebener Semantikmodelle finden Sie im Anwendungsszenario zur verwalteten Self-Service-BI.

Erwägen Sie die Einrichtung von Sicherheit auf Zeilenebene, damit andere Benutzer – über das Center of Excellence, Prüfer und Administratoren hinaus – Überwachungsdaten analysieren und berichtigen können. Beispielsweise können Sie RLS-Regeln verwenden, damit Inhaltsersteller und -verbraucher Berichte über ihre eigenen Benutzeraktivitäten oder Entwicklungsbemühungen erstellen können.

Checkliste: Beim Erstellen des Datenmodells sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Planen und Erstellen des Datenmodells: Entwerfen Sie das Datenmodell als Sternschema. Überprüfen Sie, ob Beziehungen wie beabsichtigt funktionieren. Erstellen Sie bei der Entwicklung des Modells iterativ Measures, und fügen Sie zusätzliche Daten auf der Grundlage der Analyseanforderungen hinzu. Nehmen Sie bei Bedarf zukünftige Verbesserungen in ein Backlog auf.
• Einrichten von RLS: Wenn Sie das Datenmodell anderen allgemeinen Benutzern zur Verfügung stellen möchten, richten Sie Sicherheit auf Zeilenebene ein, um den Datenzugriff einzuschränken. Überprüfen Sie, ob die RLS-Rollen die richtigen Daten zurückgeben.

Verbessern des Datenmodells

Für die effektive Analyse von Inhaltsnutzung und Benutzeraktivitäten empfiehlt sich eine Anreicherung Ihres Datenmodells. Verbesserungen des Datenmodells können graduell und iterativ im Laufe der Zeit durchgeführt werden, wenn Sie Möglichkeiten und neue Anforderungen entdecken.

Erstellen von Klassifizierungen

Eine Möglichkeit, das Modell anzureichern und den Wert Ihrer Daten zu erhöhen, besteht darin, dem Datenmodell Klassifizierungen hinzuzufügen. Stellen Sie sicher, dass diese Klassifizierungen von Ihren Berichten konsistent verwendet werden.

Sie können sowohl Benutzer als auch Inhalte auf der Grundlage ihres Nutzungsgrads klassifizieren.

Klassifizierung der Nutzung durch Benutzer

Berücksichtigen Sie die folgenden Klassifizierungen für die Benutzernutzung.

• Häufiger Benutzer: Aktivität wurde in der letzten Woche und in neun der letzten 12 Monate erfasst.
• Aktiver Benutzer: Aktivität wurde im vergangenen Monat erfasst.
• Gelegentlicher Benutzer: Aktivität wurde in den letzten neun Monaten erfasst, jedoch keine Aktivität im letzten Monat.
• Inaktiver Benutzer: In den letzten neun Monaten wurde keine Aktivität registriert.

Tipp

Es ist nützlich zu wissen, wer Ihre gelegentlichen oder inaktiven Benutzer sind, insbesondere, wenn sie über Pro- oder PPU-Lizenzen verfügen (die mit Kosten einhergehen). Es ist ebenso nützlich zu wissen, wer Ihre häufigen und aktivsten Benutzer sind. Erwägen Sie, sie zu Sprechstunden einzuladen oder zur Teilnahme an Schulungen aufzufordern. Ihre aktivsten Inhaltsersteller sind möglicherweise Kandidaten für Ihr Champions-Netzwerk.

Klassifizierung der Inhaltsnutzung

Berücksichtigen Sie die folgenden Klassifizierungen für die Inhaltsnutzung.

• Häufig genutzter Inhalt: Aktivität wurde in der letzten Woche und in neun der letzten 12 Monate erfasst.
• Aktiv genutzter Inhalt: Aktivität wurde im vergangenen Monat erfasst.
• Gelegentlicher genutzter Inhalt: Aktivität wurde in den letzten neun Monaten erfasst, jedoch keine Aktivität im letzten Monat.
• Nicht genutzter Inhalt: In den letzten neun Monaten wurde keine Aktivität registriert.

Benutzertypklassifizierung

Ziehen Sie die folgenden Klassifizierungen für den Benutzertyp in Erwägung.

• Inhaltsersteller: Aktivität zum Erstellen, Veröffentlichen oder Bearbeiten von Inhalten wurde in den letzten sechs Monaten aufgezeichnet.
• Inhaltskonsument: Aktivität zum Anzeigen von Inhalten wurde in den letzten sechs Monaten aufgezeichnet, jedoch keine Aktivität zum Erstellen von Inhalten.

Abwägen von Aktualität im Gegensatz zu Trends

Sie sollten entscheiden, ob die Nutzungsklassifizierungen für Benutzer oder Inhalte nur darauf basieren sollen, wie aktuell eine Aktivität aufgetreten ist. Es kann auch sinnvoll sein, die durchschnittliche oder tendenzielle Nutzung im zeitlichen Verlauf zu berücksichtigen.

Sehen Sie sich einige Beispiele an, die veranschaulichen, wie die Realität durch einfache Klassifizierungslogik falsch dargestellt werden kann.

• Ein leitender Mitarbeiter hat diese Woche einen Bericht angezeigt. In den letzten sechs Monaten vor dieser Woche hatte der leitende Mitarbeiter jedoch keine Berichte angezeigt. Sie sollten diesen leitenden Mitarbeiter nicht allein auf der Grundlage der aktuellen Nutzung als häufigen Benutzer klassifizieren.
• Ein Berichtersteller veröffentlicht jede Woche einen neuen Bericht. Wenn Sie die Nutzung nach häufigen Benutzern analysieren, scheint die regelmäßige Aktivität des Berichtserstellers positiv zu sein. Bei näherer Untersuchung stellen Sie jedoch fest, dass dieser Benutzer bei jeder Bearbeitung des Berichts einen neuen Bericht (mit einem neuen Berichtsnamen) veröffentlicht hat. Für diesen Berichtersteller wäre weitere Schulung sicherlich angebracht.
• Eine Führungskraft sieht sporadisch einen Bericht an, sodass sich ihre Nutzungsklassifizierung häufig ändert. Möglicherweise müssen Sie bestimmte Arten von Benutzern, z. B. Führungskräfte, anders analysieren.
• Ein interner Prüfer sieht kritische Berichte einmal pro Jahr an. Interne Auditor*innen könnten aufgrund ihrer seltenen Nutzung als inaktive Benutzer*innen erscheinen. Jemand könnte Schritte unternehmen, um seine Pro- oder PPU-Lizenz aufzuheben. Oder jemand könnte glauben, dass ein Bericht zurückgezogen werden sollte, da er selten verwendet wird.

Tipp

Sie können Durchschnittswerte und Trends mithilfe der DAX-Zeitintelligenzfunktionen berechnen. Informationen zur Verwendung dieser Funktionen finden Sie im Lernmodul Verwenden von DAX-Zeitintelligenzfunktionen in Power BI Desktop-Modellen.

Checkliste: Beim Erstellen einer Klassifizierung von Nutzungsdaten sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Erzielen von Konsens über Klassifizierungsdefinitionen: Erörtern Sie Klassifizierungsdefinitionen mit den relevanten Beteiligten. Vergewissern Sie sich, dass die Entscheidungen auf der Grundlage von Übereinstimmung getroffen werden.
• Erstellen von Dokumentation: Stellen Sie sicher, dass die Klassifizierungsdefinitionen in der Dokumentation für Inhaltsersteller und -nutzer enthalten sind.
• Erstellen einer Feedbackschleife: Stellen Sie sicher, dass Benutzer eine Möglichkeit haben, Fragen zu stellen oder Änderungen an den Klassifizierungsdefinitionen vorzuschlagen.

Erstellen von Analyseberichten

An diesem Punkt wurden die Überwachungsdaten extrahiert und gespeichert, und Sie haben ein Datenmodell veröffentlicht. Der nächste Schritt besteht im Erstellen von Analyseberichten.

Konzentrieren Sie sich auf die wichtigsten Informationen, die für die einzelnen Zielgruppen besonders relevant sind. Möglicherweise müssen Sie sich mit Ihren Überwachungsberichten an mehrere Zielgruppen richten. Jede Zielgruppe ist an anderen Informationen und für unterschiedliche Zwecke interessiert. Zu den Zielgruppen, die Sie mit Ihren Berichten bedienen können, gehören:

• Executive Sponsor
• Center of Excellence
• Power BI-Administratoren
• Arbeitsbereichsadministrator*innen
• Administratoren von Premium-Kapazitäten
• Gatewayadministratoren
• Power BI-Entwickler und Inhaltsersteller
• Prüfer

Im Folgenden finden Sie einige der häufigsten Analyseanforderungen, mit denen Sie beim Erstellen Ihrer Überwachungsberichte beginnen sollten.

• Ansicht der wichtigsten Inhalte: Ihre leitenden Sponsor*innen und Führungsteams könnten hauptsächlich an Zusammenfassungsinformationen und Trends über einen Zeitraum interessiert sein. Ihre Arbeitsbereichsadministratoren, Entwickler und Inhaltsersteller werden sich stärker für die Details interessieren.
• Top-Benutzeraktivitäten: Ihr Kompetenzzentrum interessiert sich dafür, wer Power BI wie und wann verwendet. Ihre Premium-Kapazitätsadministratoren interessieren sich dafür, wer die Kapazität nutzt, um deren Integrität und Stabilität sicherzustellen.
• Mandantenbestand: Ihre Power BI-Administratoren, Arbeitsbereichsadministratoren und Prüfer interessieren sich dafür, welche Inhalte vorhanden sind, wo, welche Herkunft sie haben und welche Sicherheitseinstellungen für sie gelten.

Diese Liste ist nicht allumfassend. Sie soll Ihnen Ideen zum Erstellen von Analyseberichten geben, die auf bestimmte Anforderungen ausgerichtet sind. Weitere Überlegungen finden Sie weiter oben in diesem Artikel unter Datenanforderungen und Übersicht zur Überwachung. Diese Ressourcen enthalten viele Ideen für die Verwendung von Überwachungsdaten und die Arten von Informationen, die Sie in Ihren Berichten präsentieren können.

Tipp

Es ist zwar verlockend, viele Daten zu präsentieren, Sie sollten aber nur Informationen einschließen, auf die Sie reagieren können. Vergewissern Sie sich, dass für jede Berichtsseite klar ist, welchem Zweck sie dient und welche Maßnahmen von wem ergriffen werden sollten.

Wenn Sie die Erstellung von Analyseberichten lernen möchten, arbeiten Sie sich durch den Lernpfad Entwerfen effektiver Berichte in Power BI.

Checkliste: Bei der Planung von Überwachungsberichten zur Analyse sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Überprüfen der Anforderungen: Priorisieren Sie die Erstellung von Berichten auf der Grundlage bekannter Anforderungen und spezifischer Fragen, die beantwortet werden sollten.
• Bestätigen Ihre Zielgruppe(n): Klären Sie ab, wer die Überwachungsberichte verwendet und welchen Zweck sie haben sollen.
• Erstellen und Bereitstellen von Berichten: Entwickeln Sie den ersten Satz von Kernberichten. Erweitern und verbessern Sie sie schrittweise im Lauf der Zeit.
• Verteilen von Berichten in einer App: Erwägen Sie die Erstellung einer App, die alle Ihre Überwachungsberichte enthält.
• Überprüfen des Zugriff auf Berichte: Vergewissern Sie sich, dass die Berichte (oder die App) der richtigen Gruppe von Benutzern zur Verfügung gestellt werden.
• Erstellen einer Feedbackschleife: Stellen Sie sicher, dass es für Berichtsbenutzer eine Möglichkeit gibt, Feedback oder Vorschläge zu geben oder Probleme zu melden.

Ergreifen von Maßnahmen auf Grundlage der Daten

Die Überwachung von Daten ist nützlich, da sie Ihnen hilft, die Vorgänge in Ihrem Power BI-Mandanten zu verstehen. Es mag zwar offensichtlich erscheinen, trotzdem ist die explizite Reaktion auf das, was Sie aus den Überwachungsdaten lernen, leicht zu übersehen. Aus diesem Grund empfiehlt es sich, jemanden zuzuweisen, der für die Nachverfolgung messbarer Verbesserungen zuständig ist, anstatt nur Überwachungsberichte zu überprüfen. Auf diese Weise können Sie mit Power BI nach und nach messbare Fortschritte im Hinblick auf Akzeptanz und Reifegrad erzielen.

Basierend auf Ihren Zielen und dem, was Sie aus den Überwachungsdaten lernen, können Sie viele verschiedene Maßnahmen ergreifen. Im weiteren Verlauf dieses Abschnitts finden Sie mehrere Ideen.

Inhaltsnutzung

Hier sehen Sie einige Maßnahmen, die Sie ausgehend von der Verwendung von Inhalten umsetzen können.

• Inhalte werden häufig verwendet (täglich oder wöchentlich): Vergewissern Sie sich, dass alle kritischen Inhalte zertifiziert sind. Vergewissern Sie sich, dass der Besitz eindeutig ist und für die Lösung angemessener Support bereitsteht.
• Hohe Anzahl von Arbeitsbereichsansichten: Wenn eine große Anzahl von Arbeitsbereichsansichten auftritt, untersuchen Sie, warum keine Power BI-Apps verwendet werden.
• Inhalte werden selten verwendet: Wenden Sie sich an die Zielbenutzer, um zu ermitteln, ob die Lösung ihren Anforderungen entspricht oder ob sich ihre Anforderungen geändert haben.
• Aktualisierungsaktivitäten treten häufiger auf als Aufrufe: Wenden Sie sich an den Inhaltsbesitzer bzw. an die Inhaltsbesitzerin, um zu erfahren, warum ein Semantikmodell regelmäßig aktualisiert wird, ohne dass das Semantikmodell kürzlich verwendet wurde bzw. ohne dass zugehörige Berichte kürzlich verwendet wurden.

Benutzeraktivitäten

Hier sehen Sie einige Maßnahmen, die Sie auf der Grundlage von Benutzeraktivitäten ergreifen können.

• Erste Veröffentlichungsaktivität eines neuen Benutzers: Bestimmen Sie, wann sich ein Benutzertyp von Nutzer zu Ersteller ändert, was Sie daran erkennen können, dass er zum ersten Mal Inhalte veröffentlicht. Das ist eine großartige Gelegenheit, diesen Benutzern eine Standard-E-Mail zu senden, die Anleitungen und Links zu nützlichen Ressourcen enthält.
• Interaktion mit den häufigsten Inhaltserstellern: Laden Sie Ihre aktivsten Ersteller ein, Ihrem Champions-Netzwerk beizutreten oder sich an Ihrer Übungscommunity zu beteiligen.
• Lizenzverwaltung: Überprüfen Sie, ob inaktive Ersteller noch eine Pro- oder PPU-Lizenz benötigen.
• Aktivierung der Benutzertestversion: Eine Aktivierung der Testlizenz kann Sie darauf aufmerksam machen, dem Benutzer vor dem Ende der Testversion eine Dauerlizenz zuzuweisen.

Gelegenheit zur Benutzerschulung

Hier finden Sie einige Gelegenheiten zur Benutzerschulung, die Sie anhand der Überwachungsdaten identifizieren können.

• Hohe Anzahl von Semantikmodellen, die vom gleichen Inhaltsersteller bzw. von der gleichen Inhaltserstellerin veröffentlicht wurden: Informieren Sie Benutzer*innen über freigegebene Semantikmodelle, und erläutern Sie, warum es wichtig ist, doppelte Semantikmodelle zu vermeiden.
• Übermäßiges Teilen aus einem persönlichen Arbeitsbereich: Wenden Sie sich an einen Benutzer, der viele Freigaben aus seinem persönlichen Arbeitsbereich durchführt. Informieren Sie diese Benutzer über Standardarbeitsbereiche.
• Wichtige Berichtsansichten aus einem persönlichen Arbeitsbereich: Wenden Sie sich an einen Benutzer, der Inhalte besitzt, die eine hohe Anzahl von Berichtsansichten aufweisen. Zeigen Sie ihnen, inwiefern Standardarbeitsbereiche besser sind als persönliche Arbeitsbereiche.

Tipp

Sie können außerdem Ihre Schulungsinhalte oder Ihre Dokumentation verbessern, indem Sie Fragen, die von Ihrer internen Power BI-Community beantwortet werden, und Probleme überprüfen, die an den Helpdesk übermittelt werden.

Sicherheit

Im Folgenden finden Sie einige Sicherheitssituationen, die Sie möglicherweise aktiv überwachen sollten.

• Zu viele Benutzer sind der Fabric-Administratorrolle mit hohen Berechtigungen zugewiesen.
• Zu viele Arbeitsbereichsadministratoren (wenn die Arbeitsbereichsrolle Mitglied, Mitwirkender oder Zuschauer ausreichend wäre).
• Semantikmodellen sind übermäßige Erstellungsberechtigungen zugewiesen (wenn die Leseberechtigung ausreichend wäre).
• Starke Nutzung von Elementberechtigungen, wenn Power BI-App-Berechtigungen oder die Rolle Arbeitsbereichsbetrachter für Inhaltsnutzer eine bessere Wahl wären.
• Art der Freigabe von Inhalten für externe Benutzer.

Weitere Informationen finden Sie in den Artikeln zur Sicherheitsplanung.

Governance und Risikominderung

Im Folgenden finden Sie einige Situationen, auf die Sie stoßen könnten. Erwägen Sie, in Ihren Überwachungsberichten explizit nach Situationen dieser Art zu suchen, damit Sie schnell auf sie reagieren können.

• Hohe Anzahl von Aufrufen für Berichte (und zugrunde liegende Semantikmodelle) ohne Endorsement.
• Erhebliche Verwendung unbekannter oder nicht genehmigter Datenquellen.
• Dateispeicherorte entsprechen nicht den Governancerichtlinien für den Speicherort von Quelldateien.
• Arbeitsbereichsnamen entsprechen nicht den Governanceanforderungen.
• Vertraulichkeitsbezeichnungen werden für den Informationsschutz verwendet.
• Konsistente Fehler bei der Datenaktualisierung.
• Erhebliche und wiederkehrende Verwendung der Druckfunktion.
• Unerwartete oder übermäßige Nutzung von Abonnements.
• Unerwartete Verwendung von persönlichen Gateways.

Die spezifischen Maßnahmen, die in jeder dieser Situationen ergriffen werden müssen, hängen von Ihren Governancerichtlinien ab. Weitere Informationen finden Sie unter Governance in der Roadmap für die Fabric-Einführung.

Checkliste: Bei der Planung potenzieller Aktionen auf der Grundlage der Überwachungsdaten sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Abklären der Erwartungen: Erstellen Sie Überwachungsberichte mit klar umrissenen Erwartungen an die umzusetzenden Maßnahmen.
• Klären Sie, wer für Maßnahmen zuständig ist: Stellen Sie sicher, dass Rollen und Zuständigkeiten zugewiesen sind.
• Erstellen von Automatisierung: Automatisieren Sie nach Möglichkeit bekannte Aktionen, die wiederholbar sind.
• Verwenden eines Nachverfolgungssystems: Verwenden Sie ein System, um eine beobachtete Situation nachzuverfolgen, einschließlich der getätigten Kontakte, der nächsten geplanten Aktion, der zuständigen Person, der Lösung und des Status.

Phase 4: Verwalten, Verbessern und Überwachen

In der vierten Phase der Planung und Implementierung einer Überwachungslösung auf Mandantenebene liegt der Schwerpunkt auf Wartung, Verbesserungen und Überwachung. An diesem Punkt wird Ihre Überwachungslösung in der Produktion verwendet. Sie kümmern sich nun in erster Linie um die Wartung, Verbesserung und Überwachung der Lösung.

Operationalisieren und Verbessern

Überwachungsprozesse werden in der Regel als in der Produktion stattfindend angesehen, wenn die ursprüngliche Entwicklung und die Tests abgeschlossen sind und Sie den Prozess automatisiert haben. Auf automatisierte Überwachungsprozesse, die in der Produktion ausgeführt werden, richten sich größere Erwartungen an Qualität, Zuverlässigkeit, Stabilität und Support (als an manuelle Prozesse).

Ein Überwachungsprozess auf Produktionsebene wurde operationalisiert. Eine operationalisierte Lösung weist oftmals viele der folgenden Merkmale auf.

• Sicher: Anmeldeinformationen werden sicher gespeichert und verwaltet. Skripts enthalten keine Kennwörter oder Schlüssel im Klartext.
• Planung: Ein zuverlässiges Zeitplanungssystem ist vorhanden.
• Change Management: Change Management-Methoden und mehrere Umgebungen werden verwendet, um sicherzustellen, dass die Produktionsumgebung geschützt ist. Sie können darüber hinaus mit Entwicklungs- und Testumgebungen oder nur mit einer Entwicklungsumgebung arbeiten.
• Support: Das Team, das den Support für die Lösung leistet, ist klar definiert. Die Teammitglieder wurden geschult und verstehen die operativen Erwartungen. Reservemitglieder wurden identifiziert, und bei Bedarf erfolgt übergreifende Schulung.
• Benachrichtigung: Wenn etwas schief geht, wird das Supportteam automatisch durch Warnungen benachrichtigt. Die Benachrichtigung erfolgt vorzugsweise in Protokollen und E-Mails (anstatt nur in E-Mails). Ein Protokoll ist nützlich, um protokollierte Fehler und Warnungen zu analysieren.
• Protokollierung: Prozesse werden protokolliert, damit es einen Verlauf dazu gibt, wann die Überwachungsdaten aktualisiert wurden. Die protokollierten Informationen sollten die Startzeit, die Endzeit und die Identität des Benutzers oder der App erfassen, der bzw. die den Prozess ausgeführt hat.
• Fehlerbehandlung: Skripts und Prozesse behandeln Fehler ordnungsgemäß und protokollieren sie (etwa ob sie sofort beendet werden, fortgesetzt werden oder warten und es erneut versuchen). Warnungsbenachrichtigungen werden an das Supportteam gesendet, wenn ein Fehler auftritt.
• Programmierstandards: Es werden gute Programmiertechniken verwendet, die eine gute Leistung erbringen. Beispielsweise werden Schleifen gezielt vermieden, außer wenn sie erforderlich sind. Konsistente Programmierstandards, Kommentare, Formatierungen und Syntax werden verwendet, damit die Lösung einfacher zu verwalten und zu supporten ist.
• Wiederverwendung und Modularisierung: Zum Minimieren von Doubletten werden Code- und Konfigurationswerte (z. B. Verbindungszeichenfolgen oder E-Mail-Adressen für Benachrichtigungen) modularisiert, sodass sie von anderen Skripts und Prozessen wiederverwendet werden können.

Tipp

Sie brauchen nicht alles, was oben aufgeführt ist, gleichzeitig einzuführen. Wenn Sie Erfahrungen sammeln, können Sie die Lösung inkrementell verbessern, sodass sie umfassend und robust wird. Beachten Sie, dass die meisten online verfügbaren Beispiele einfache, einmalige Skriptschnipsel sind, die nicht über Produktionsqualität verfügen könnten.

Checkliste: Bei der Planung der Operationalisierung und Verbesserung einer Überwachungslösung sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Beurteilen des Niveaus vorhandener Lösungen: Ermitteln Sie, ob es Möglichkeiten gibt, vorhandene, automatisierte Überwachungslösungen zu verbessern und zu stabilisieren.
• Einrichten von Standards auf Produktionsniveau: Entscheiden Sie, welche Standards Sie Ihren automatisierten Überwachungsprozessen zu Grunde legen möchten. Berücksichtigen Sie Verbesserungen, die Sie realistisch betrachtet im Laufe der Zeit hinzufügen können.
• Erstellen eines Plans zur Verbesserung: Planen Sie, die Qualität und Stabilität von Produktionsüberwachungslösungen zu verbessern.
• Bestimmen, ob eine separate Entwicklungsumgebung erforderlich ist: Bewerten Sie das Gefahrenpotenzial und die Abhängigkeit von den Produktionsdaten. Entscheiden Sie, wann separate Entwicklungs- und Produktionsumgebungen (und Testumgebungen) erstellt werden sollen.
• Erwägen einer Strategie für die Datenaufbewahrung: Bestimmen Sie, ob Sie einen Datenaufbewahrungsprozess implementieren müssen, der Daten nach einem bestimmten Zeitraum oder auf Anforderung löscht.

Dokumentation und Support

Dokumentation und Support sind für jede Lösung auf Produktionsebene von entscheidender Bedeutung. Es ist nützlich, je nach Zielgruppe und Zweck verschiedene Arten von Dokumentation zu erstellen.

Technische Dokumentation

Die technische Dokumentation richtet sich an das technische Team, das die Lösung erstellt hat und sie Lösung im Lauf der Zeit schrittweise verbessern und erweitern soll. Sie stellt auch eine nützliche Ressource für das Supportteam dar.

Die technische Dokumentation sollte Folgendes umfassen:

• Eine Zusammenfassung der Architekturkomponenten und Voraussetzungen.
• Wer besitzt und verwaltet die Lösung.
• Wer leistet Support für die Lösung?
• Ein Architekturdiagramm.
• Entwurfsentscheidungen, einschließlich der Ziele, Gründe, warum bestimmte technische Entscheidungen getroffen wurden, und Einschränkungen (z. B. Kosten oder Qualifikationen).
• Sicherheitsentscheidungen und -optionen.
• Verwendete Namenskonventionen.
• Programmierungs- und technische Standards und Richtlinien.
• Change Management-Anforderungen.
• Bereitstellungs-, Setup- und Installationsanweisungen.
• Bekannte Bereiche technischer Verbindlichkeit (Bereiche, die verbessert werden sollten, wenn die Möglichkeit dazu besteht).

Supportdokumentation

Abhängig vom Grad der Kritizität für Ihre Überwachungslösung verfügen Sie möglicherweise über einen Helpdesk oder ein Supportteam bei dringenden Probleme. Sie können täglich rund um die Uhr verfügbar sein.

Supportdokumentation wird manchmal als Wissensdatenbank oder Runbook bezeichnet. Diese Dokumentation richtet sich an Ihren Helpdesk oder Ihr Supportteam und sollte Folgendes enthalten:

• Anleitung zur Problembehandlung, wenn etwas schief geht. Beispielsweise, wenn ein Fehler bei der Datenaktualisierung auftritt.
• Maßnahmen, die fortlaufend zu ergreifen sind. Beispielsweise könnte es einige manuelle Schritte geben, die regelmäßig von einer Person ausgeführt werden müssen, bis ein Problem behoben ist.

Dokumentation für Inhaltsersteller

Sie ziehen mehr Nutzen aus Ihrer Überwachungslösung, wenn Sie anderen Teams in der gesamten Organisation Nutzungs- und Akzeptanzanalysen zur Verfügung stellen (wobei bei Bedarf Sicherheit auf Zeilenebene erzwungen wird).

Die Dokumentation für Inhaltsersteller richtet sich an Self-Service-Inhaltsersteller, die Berichte und Datenmodelle erstellen, die die kuratierten Überwachungsdaten als Quelle nutzen. Sie enthält Informationen zum Datenmodell, einschließlich allgemeiner Datendefinitionen.

Checkliste: Bei der Planung von Dokumentation und Support für Ihre Überwachungslösung sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Vergewissern Sie sich, wer Support für die Lösung leisten soll: Bestimmen Sie, wer Überwachungslösungen unterstützt, die als auf Produktionsniveau angesehen werden (oder nachgelagerte Berichtsabhängigkeiten aufweisen).
• Sicherstellen der Bereitschaft des Supportteams: Vergewissern Sie sich, dass das Supportteam bereit ist, Support für die Überwachungslösung zu leisten. Ermitteln Sie, ob es Bereitschaftslücken gibt, die behoben werden müssen.
• Anordnen übergreifender Schulung: Führen Sie Wissensvermittlungssitzungen oder übergreifende Schulungssitzungen für das Supportteam durch.
• Abklären der Erwartungen an das Supportteam: Stellen Sie sicher, dass die Erwartungen an Reaktion und Behebung klar dokumentiert und kommuniziert werden. Entscheiden Sie, ob jemand in Bereitschaftsdienst sein muss, um Probleme im Zusammenhang mit der Überwachungslösung schnell zu beheben.
• Erstellen der technischen Dokumentation: Erstellen Sie Dokumentation zur technischen Architektur und Entwurfsentscheidungen.
• Erstellen einer Supportdokumentation: Aktualisieren Sie die Helpdesk-Wissensdatenbank, damit sie Informationen zum Support der Lösung beinhaltet.
• Erstellen von Dokumentation für Inhaltsersteller: Erstellen Sie Dokumentation, die Self-Service-Erstellern bei der Verwendung des Datenmodells unterstützt. Beschreiben Sie allgemeine Datendefinitionen, um die Konsistenz ihrer Verwendung zu verbessern.

Aktivieren von Warnungen

Es kann sinnvoll sein, auf der Grundlage bestimmter Bedingungen in den Überwachungsdaten Warnungen auszulösen. Beispielsweise können Sie eine Warnung auslösen, wenn jemand ein Gateway löscht oder wenn ein Power BI-Administrator eine Mandanteneinstellung ändert.

Weitere Informationen finden Sie unter Überwachung auf Mandantenebene.

Kontinuierliche Verwaltung

Es muss eine fortlaufende Verwaltung der gesamten Überwachungslösung erfolgen. Möglicherweise müssen Sie Ihre Überwachungslösung in den folgenden Fällen erweitern oder ändern:

• Die Organisation ermittelt neue Datenanforderungen.
• Neue Überwachungsereignisse treten in den Rohdaten auf, die Sie aus den Power BI-REST-APIs extrahieren.
• Microsoft nimmt Änderungen an den Power BI-REST-APIs vor.
• Mitarbeiter identifizieren Möglichkeiten, die Lösung zu verbessern.

Wichtig

Breaking Changes sind selten, aber sie können auftreten. Es ist wichtig, dass Sie über jemanden verfügen, der Probleme schnell beheben oder die Überwachungslösung bei Bedarf aktualisieren kann.

Checkliste: Bei der Planung der laufenden Verwaltung der Überwachungslösung sind die folgenden wichtigen Entscheidungen und Maßnahmen zu berücksichtigen:

• Zuweisen eines technischen Besitzers: Achten Sie darauf, dass der Besitz und die Verantwortung für die gesamte Überwachungslösung eindeutig sind.
• Überprüfung, ob eine Sicherung vorhanden ist: Stellen Sie sicher, dass es einen Besitzer der technischen Sicherung gibt, der einbezogen werden kann, wenn ein dringendes Problem auftritt, das der Support nicht lösen kann.
• Unterhalten eines Nachverfolgungssystems: Achten Sie darauf, dass eine Möglichkeit besteht, neue Anforderungen zu erfassen, und ein Verfahren zur Priorisierung von unmittelbaren Prioritäten sowie kurzfristigen, mittelfristigen und langfristigen Prioritäten (Backlog) verfügbar ist.

Zugehöriger Inhalt

Im nächsten Artikel dieser Reihe erfahren Sie mehr über die Überwachung auf Mandantenebene.