Przeczytaj w języku angielskim

Udostępnij za pośrednictwem

Planowanie implementacji usługi Power BI: inspekcja na poziomie dzierżawy

  • Artykuł

Uwaga

Ten artykuł stanowi część serii artykułów dotyczących planowania implementacji usługi Power BI. Ta seria koncentruje się głównie na środowisku usługi Power BI w usłudze Microsoft Fabric. Aby zapoznać się z wprowadzeniem do serii, zobacz Planowanie implementacji usługi Power BI.

Ten artykuł dotyczący planowania inspekcji na poziomie dzierżawy jest przeznaczony głównie dla:

  • Administratorzy usługi Power BI: administratorzy, którzy są odpowiedzialni za nadzorowanie usługi Power BI w organizacji. Administratorzy usługi Power BI mogą wymagać współpracy z zespołami IT, zabezpieczeniami, inspekcją wewnętrzną i innymi odpowiednimi zespołami.
  • Centrum doskonałości, IT i zespół ds. analizy biznesowej: zespoły, które są również odpowiedzialne za nadzorowanie usługi Power BI. Może być konieczne współpraca z administratorami usługi Power BI i innymi odpowiednimi zespołami.

Ważne

Zalecamy dokładne przestrzeganie planu wydania usługi Power BI, aby dowiedzieć się więcej o przyszłych ulepszeniach możliwości inspekcji i monitorowania.

Celem rozwiązania inspekcji na poziomie dzierżawy jest przechwytywanie i analizowanie danych dla wszystkich użytkowników, działań i rozwiązań wdrożonych w dzierżawie usługi Power BI. Te dane inspekcji na poziomie dzierżawy są cenne w wielu celach, co pozwala na analizowanie wysiłków związanych z wdrażaniem, zrozumienie wzorców użycia, informowanie użytkowników, wspieranie użytkowników, ograniczanie ryzyka, poprawianie zgodności, zarządzanie kosztami licencji i monitorowanie wydajności.

Tworzenie kompleksowego rozwiązania do inspekcji, które jest bezpieczne i gotowe do produkcji, to znaczący projekt, który zajmuje trochę czasu. Pomyśl o tym, jak o tworzeniu analizy biznesowej na temat analizy biznesowej (BI w usłudze BI w usłudze BI). Aby uzyskać informacje o tym, dlaczego dane inspekcji są tak cenne, zobacz Omówienie inspekcji i monitorowania.

Aby uzyskać informacje na temat inspekcji na poziomie raportu, która jest przeznaczona dla twórców raportów, zobacz Inspekcja na poziomie raportu.

Aby uzyskać informacje na temat inspekcji zasobów danych przeznaczonych dla twórców danych, zobacz Inspekcja na poziomie danych.

W pozostałej części tego artykułu skupiono się na inspekcji na poziomie dzierżawy.

Porada

Głównym celem tego artykułu jest ułatwienie utworzenia kompleksowego rozwiązania do inspekcji. Ponieważ zawartość w tym artykule jest zorganizowana w cztery fazy, potrzebne będą informacje w wielu fazach. Na przykład w fazie 1 znajdziesz informacje o planowaniu korzystania z jednostki usługi oraz informacje w fazie 2 dotyczące wymagań wstępnych i konfiguracji.

Dlatego zalecamy najpierw przeczytanie całego artykułu, aby zapoznać się z tym, co jest zaangażowane. Następnie należy dobrze przygotować się do planowania i tworzenia rozwiązania do inspekcji w sposób iteracyjny.

Jeśli planujesz utworzyć rozwiązanie inspekcji na poziomie dzierżawy, zaplanuj poświęcanie czasu na następujące cztery fazy.

Faza 1. Planowanie i decyzje

Pierwsza faza koncentruje się na planowaniu i podejmowaniu decyzji. Istnieje wiele wymagań i priorytetów, które należy wziąć pod uwagę, dlatego zalecamy poświęcanie wystarczającego czasu na zrozumienie tematów wprowadzonych w tej sekcji. Celem jest podjęcie dobrych decyzji z góry, aby fazy podrzędne działały płynnie.

Diagram przepływu opisujący fazę 1, która koncentruje się na planowaniu i decyzjach dotyczących tworzenia rozwiązania inspekcji na poziomie dzierżawy.

Wymagania i priorytety

W początkowej fazie celem jest określenie, co jest najważniejsze. Skoncentruj się na tym, co ma największe znaczenie i jak będziesz mierzyć wpływ w organizacji. Staraj się definiować wymagania biznesowe, a nie wymagania zorientowane na technologię.

Oto kilka pytań, na które należy odpowiedzieć.

  • Jakie kluczowe pytania należy odpowiedzieć? Istnieje duża liczba danych inspekcji, które można eksplorować. Najbardziej efektywnym sposobem podejścia do inspekcji jest skupienie się na odpowiadaniu na konkretne pytania.
  • Jakie są cele dotyczące wdrażania i kultury danych? Na przykład możesz mieć na celu zwiększenie liczby autorów zawartości samoobsługowej analizy biznesowej w organizacji. W takim przypadku musisz zmierzyć działania użytkowników związane z tworzeniem, edytowaniem i publikowaniem zawartości.
  • Jakie natychmiastowe zagrożenia są obecne? Na przykład możesz wiedzieć, że w przeszłości doszło do nadmiernego udostępniania zawartości. Szkolenie użytkowników zostało od tego czasu ulepszone, a teraz chcesz przeprowadzać inspekcję ustawień zabezpieczeń i działań na bieżąco.
  • Czy istnieją bieżące kluczowe wskaźniki wydajności (KPI) lub cele organizacyjne? Na przykład masz organizacyjny wskaźnik KPI, który odnosi się do transformacji cyfrowej lub staje się bardziej opartą na danych organizacją. Dane inspekcji na poziomie dzierżawy mogą ułatwić określenie, czy implementacja usługi Power BI jest zgodna z tymi celami.

Porada

Zweryfikuj wymagania dotyczące inspekcji i ustaw priorytety za pomocą sponsora wykonawczego i Centrum Doskonałości. Kuszące jest wyodrębnienie danych inspekcji i rozpoczęcie tworzenia raportów na podstawie wielu interesujących danych. Jest jednak mało prawdopodobne, że uzyskasz wysoką wartość z rozwiązania do przeprowadzania inspekcji, gdy nie jest on oparty na pytaniach, na które należy odpowiedzieć, i akcji, które zamierzasz podjąć.

Aby uzyskać więcej pomysłów na sposoby korzystania z danych inspekcji, zobacz Omówienie inspekcji i monitorowania.

Lista kontrolna — podczas identyfikowania wymagań i priorytetów kluczowe decyzje i akcje obejmują:

  • Identyfikowanie wymagań: zbieranie i dokumentowanie kluczowych wymagań biznesowych dotyczących inspekcji dzierżawy usługi Power BI.
  • Określanie priorytetów wymagań: ustawianie priorytetów wymagań, klasyfikowanie ich jako natychmiastowych, krótkoterminowych, średnioterminowych i długoterminowych (lista prac).
  • Utwórz plan dla natychmiastowych priorytetów: umieść plan, aby rozpocząć zbieranie danych, aby było dostępne w razie potrzeby.
  • Regularne ponowne oceny wymagań: utwórz plan regularnego ponownego oceny wymagań (na przykład dwa razy w roku). Sprawdź, czy rozwiązanie do inspekcji i monitorowania spełnia określone wymagania. Zaktualizuj elementy akcji w planie zgodnie z potrzebami.

Wymagania dotyczące danych

Po zdefiniowaniu wymagań i priorytetów (opisanych wcześniej) możesz przystąpić do identyfikowania potrzebnych danych. W tej sekcji omówiono cztery kategorie danych.

Większość potrzebnych danych pochodzi z interfejsów API administratora, które zapewniają wiele metadanych dotyczących dzierżawy usługi Power BI. Aby uzyskać więcej informacji, zobacz Wybieranie interfejsu API użytkownika lub interfejsu API administratora w dalszej części tego artykułu.

Dane aktywności użytkownika

Priorytetem jest uzyskanie danych dotyczących działań użytkowników. Działania użytkownika, nazywane również zdarzeniami lub operacjami, są przydatne w wielu różnych celach.

Najczęściej te dane są określane jako dziennik aktywności lub dziennik zdarzeń. Technicznie istnieje kilka sposobów uzyskiwania danych aktywności użytkownika (dziennik aktywności jest jedną metodą). Aby uzyskać więcej informacji o decyzjach i działaniach, zobacz Uzyskiwanie dostępu do danych aktywności użytkowników w dalszej części tego artykułu.

Poniżej przedstawiono kilka typowych pytań, na które mogą odpowiedzieć dane aktywności użytkownika.

  • Znajdowanie najlepszych użytkowników i wierzchołka zawartości
    • Jaka zawartość jest najczęściej przeglądana i przez jakich użytkowników?
    • Jakie są dzienne, tygodniowe i miesięczne trendy wyświetlania zawartości?
    • Czy widoki raportów są trendami w górę lub w dół?
    • Ilu użytkowników jest aktywnych?
  • Informacje o zachowaniu użytkownika
    • Jakiego typu zabezpieczenia są najczęściej używane (aplikacje, obszary robocze lub udostępnianie poszczególnych elementów)?
    • Czy użytkownicy korzystają z przeglądarek lub aplikacji mobilnych najczęściej?
    • Którzy twórcy zawartości aktywnie publikują i aktualizują zawartość?
    • Jaka zawartość jest publikowana lub aktualizowana, kiedy i przez jakich użytkowników?
  • Identyfikowanie możliwości edukacyjnych i szkoleniowych użytkowników
    • Kto robi (zbyt wiele) udostępniania z osobistego obszaru roboczego?
    • Kto wykonuje znaczną ilość eksportu?
    • Kto regularnie pobiera zawartość?
    • Kto publikuje wiele nowych modeli semantycznych?
    • Kto intensywnie korzysta z subskrypcji?
  • Ulepszanie wysiłków związanych z ładem i zgodnością
    • Kiedy ustawienia dzierżawy są zmieniane i przez którego administratora usługi Power BI?
    • Kto rozpoczął wersję próbną usługi Power BI?
    • Do jakiej zawartości uzyskują dostęp użytkownicy zewnętrzni, którzy, kiedy i jak?
    • Kto dodał lub zaktualizował etykietę poufności?
    • Jaki procent widoków raportu jest oparty na certyfikowanych modelach semantycznych?
    • Jaki procent modeli semantycznych obsługuje więcej niż jeden raport?
    • Kiedy brama lub źródło danych zostało utworzone lub zaktualizowane, i według którego użytkownika?

Aby uzyskać więcej informacji na temat sposobów korzystania z tych danych, zobacz Omówienie wzorców użycia.

Ważne

Jeśli jeszcze nie wyodrębniasz i nie przechowujesz danych działań użytkownika, upewnij się, że priorytet jest pilny. Upewnij się co najmniej, że wyodrębnisz nieprzetworzone dane i zapiszesz je w bezpiecznej lokalizacji. Dzięki temu dane będą dostępne, gdy wszystko będzie gotowe do ich przeanalizowania. Historia jest dostępna przez 30 dni lub 90 dni w zależności od używanego źródła.

Aby uzyskać więcej informacji, zobacz Uzyskiwanie dostępu do danych aktywności użytkownika w dalszej części tego artykułu.

Spis dzierżawy

Często drugim priorytetem jest pobranie danych w celu utworzenia spisu dzierżawy. Czasami jest to nazywane spisem obszarów roboczych, metadanymi obszaru roboczego lub metadanymi dzierżawy.

Spis dzierżawy to migawka w danym punkcie w czasie. Opisuje on, co zostało opublikowane w dzierżawie. Spis dzierżawy nie zawiera rzeczywistych danych ani rzeczywistych raportów. Zamiast tego są to metadane opisujące wszystkie obszary robocze i ich elementy (takie jak modele semantyczne i raporty).

Poniżej przedstawiono kilka typowych pytań, na które może odpowiedzieć spis dzierżaw.

  • Dowiedz się, ile zawartości masz i gdzie
    • Które obszary robocze mają najwięcej zawartości?
    • Jakiego typu zawartość jest publikowana w każdym obszarze roboczym (szczególnie w przypadku oddzielania obszarów roboczych raportowania i obszarów roboczych danych)?
    • Jakie zależności istnieją między elementami (takimi jak przepływy danych obsługujące wiele modeli semantycznych lub semantyczny model, który jest źródłem innych modeli złożonych)?
    • Jaka jest pochodzenie danych (zależności między elementami usługi Power BI, w tym zewnętrznymi źródłami danych)?
    • Czy istnieją oddzielone raporty (które są odłączone od ich modelu semantycznego)?
  • Omówienie współczynnika semantycznych modeli do raportów
    • Ile ponownego użycia modelu semantycznego występuje?
    • Czy istnieją zduplikowane lub bardzo podobne modele semantyczne?
    • Czy istnieją możliwości konsolidacji modeli semantycznych?
  • Omówienie trendów między punktami w czasie
    • Czy liczba raportów rośnie wraz z upływem czasu?
    • Czy liczba semantycznych modeli rośnie wraz z upływem czasu?
  • Znajdowanie nieużywanej zawartości
    • Które raporty są nieużywane (lub nieużywane)?
    • Które modele semantyczne są nieużywane (lub nieużywane)?
    • Czy istnieją możliwości wycofania zawartości?

Spis dzierżawy pomaga używać bieżących nazw podczas analizowania działań historycznych. Migawka elementów w dzierżawie zawiera nazwy wszystkich elementów w tym momencie. Warto używać bieżących nazw elementów do raportowania historycznego. Na przykład jeśli nazwa raportu została zmieniona trzy miesiące temu, dziennik aktywności w tym czasie rejestruje starą nazwę raportu. Za pomocą prawidłowo zdefiniowanego modelu danych możesz użyć najnowszego spisu dzierżawy, aby zlokalizować element według jego bieżącej nazwy (a nie jej poprzedniej nazwy). Aby uzyskać więcej informacji, zobacz Tworzenie modelu danych w dalszej części tego artykułu.

Aby uzyskać więcej informacji na temat sposobów używania spisu dzierżawy, zobacz Omówienie opublikowanej zawartości.

Porada

Aby utworzyć pełny obraz, często będziesz używać łączenia zdarzeń aktywności użytkownika (opisanych w poprzedniej sekcji) i spisu dzierżawy. W ten sposób zwiększasz wartość wszystkich danych.

Ponieważ spis dzierżawy jest migawką w danym momencie w czasie, musisz zdecydować, jak często wyodrębniać i przechowywać metadane. Cotygodniowa migawka jest przydatna do porównywania między dwoma punktami w czasie. Jeśli na przykład chcesz zbadać ustawienia zabezpieczeń obszaru roboczego, potrzebujesz poprzedniej migawki spisu dzierżawy, zdarzeń dziennika aktywności i bieżącej migawki spisu dzierżawy.

Istnieją dwa główne sposoby tworzenia spisu dzierżawy. Aby uzyskać więcej informacji o decyzjach i działaniach, zobacz Uzyskiwanie dostępu do danych spisu dzierżawy w dalszej części tego artykułu.

Dane użytkowników i grup

W miarę wzrostu potrzeb analitycznych prawdopodobnie określisz, że chcesz uwzględnić dane dotyczące użytkowników i grup w rozwiązaniu kompleksowej inspekcji. Aby pobrać te dane, możesz użyć programu Microsoft Graph, który jest autorytatywnym źródłem informacji o użytkownikach i grupach identyfikatora Entra firmy Microsoft.

Dane pobrane z interfejsów API REST usługi Power BI zawierają adres e-mail opisujący użytkownika lub nazwę grupy zabezpieczeń. Te dane są migawką w danym momencie w czasie.

Oto kilka typowych pytań, na które może odpowiedzieć program Microsoft Graph.

  • Identyfikowanie użytkowników i grup
    • Jaka jest pełna nazwa użytkownika (oprócz adresu e-mail), dział lub lokalizacja źródłowa z profilu użytkownika?
    • Kim są członkowie grupy zabezpieczeń?
    • Kto jest właścicielem grupy zabezpieczeń (do zarządzania członkami)?
  • Uzyskiwanie dodatkowych informacji o użytkowniku
    • Które licencje — Power BI Pro lub Power BI Premium na użytkownika (PPU) — są przypisane do użytkowników?
    • Którzy użytkownicy logują się najczęściej?
    • Którzy użytkownicy nie zalogowali się do usługa Power BI niedawno?

Ostrzeżenie

Niektóre starsze metody (które są szeroko udokumentowane w trybie online) na potrzeby uzyskiwania dostępu do danych użytkowników i grup są przestarzałe i nie powinny być używane. Jeśli to możliwe, użyj programu Microsoft Graph jako autorytatywnego źródła danych użytkowników i grup.

Aby uzyskać więcej informacji i zaleceń dotyczących uzyskiwania dostępu do danych z programu Microsoft Graph, zobacz Uzyskiwanie dostępu do danych użytkowników i grup w dalszej części tego artykułu.

Dane zabezpieczeń

Może być wymagane regularne przeprowadzanie inspekcji zabezpieczeń.

Poniżej przedstawiono kilka typowych pytań, na które mogą odpowiedzieć interfejsy API REST usługi Power BI.

  • Identyfikowanie osób i aplikacji
    • Do których raportów ma dostęp użytkownik, grupa lub jednostka usługi?
    • Którzy użytkownicy, grupy lub jednostki usługi są subskrybentami, którzy otrzymują raporty z subskrypcją poczty e-mail?
  • Informacje o uprawnieniach do zawartości
    • Które role obszaru roboczego są przypisywane do których użytkowników i grup?
    • Którzy użytkownicy i grupy są przypisywani do poszczególnych odbiorców aplikacji usługi Power BI?
    • Które uprawnienia poszczególnych elementów są przypisane, dla których raportów i dla których użytkowników?
    • Które uprawnienia poszczególnych elementów są przypisywane, dla których modeli semantycznych i dla których użytkowników?
    • Które semantyczne modele i magazyny danych mają zdefiniowane zabezpieczenia na poziomie wiersza?
    • Które elementy są udostępniane osobom w całej organizacji?
    • Które elementy są publikowane publicznie w Internecie?
  • Informacje o innych uprawnieniach
    • Kto ma uprawnienia do publikowania przy użyciu potoku wdrażania?
    • Kto ma uprawnienia do zarządzania bramami i połączeniami danych?
    • Kto ma uprawnienia do zarządzania pojemnością Premium?

Ważne

Czasami w tym artykule opisano usługę Power BI Premium lub jej subskrypcje pojemności (jednostki SKU P). Należy pamiętać, że firma Microsoft obecnie konsoliduje opcje zakupu i cofnie usługę Power BI Premium na jednostki SKU pojemności. Nowi i istniejący klienci powinni rozważyć zakup subskrypcji pojemności sieci szkieletowej (jednostki SKU F).

Aby uzyskać więcej informacji, zobacz Ważne aktualizacje dostępne w licencjonowaniu usługi Power BI Premium i Power BI Premium — często zadawane pytania.

Porada

Aby uzyskać więcej informacji na temat zabezpieczeń, zobacz artykuły dotyczące planowania zabezpieczeń.

Te typowe pytania nie są wyczerpującą listą; Dostępnych jest wiele różnych interfejsów API REST usługi Power BI. Aby uzyskać więcej informacji, zobacz Używanie interfejsów API REST usługi Power BI.

Aby uzyskać więcej informacji na temat używania interfejsów API administratora i interfejsów API użytkowników (w tym wpływu na uprawnienia wymagane dla użytkownika, który wyodrębnia dane), zobacz Wybieranie interfejsu API użytkownika lub interfejsu API administratora w dalszej części tego artykułu.

Lista kontrolna — podczas identyfikowania danych potrzebnych do inspekcji kluczowe decyzje i akcje obejmują:

  • Zidentyfikuj określone wymagania dotyczące danych aktywności użytkownika: zweryfikuj zebrane wymagania. Określenie, które dane inspekcji są niezbędne do spełnienia poszczególnych wymagań dotyczących danych aktywności użytkownika.
  • Zidentyfikuj określone wymagania dotyczące danych spisu dzierżawy: zweryfikuj zebrane wymagania. Określenie, które dane inspekcji są niezbędne do skompilowania spisu dzierżawy.
  • Zidentyfikuj konkretne potrzeby dotyczące danych użytkowników i grup: zweryfikuj zebrane wymagania. Określenie, które dane inspekcji są niezbędne do spełnienia poszczególnych wymagań dotyczących danych użytkowników i grup.
  • Zidentyfikuj określone wymagania dotyczące danych zabezpieczeń: zweryfikuj zebrane wymagania. Określenie, które dane inspekcji są niezbędne do spełnienia poszczególnych wymagań dotyczących danych zabezpieczeń.
  • Zweryfikuj priorytety: sprawdź kolejność priorytetów, aby wiedzieć, co należy najpierw opracować.
  • Zdecyduj, jak często należy przechwytywać działania: zdecyduj, jak często przechwytywać zdarzenia działań (np. raz dziennie).
  • Zdecyduj, jak często przechwytywać migawki: zdecyduj, jaki interwał przechwytuje dane migawek, takie jak spis dzierżawy lub dane użytkowników i grup.

Typ rozwiązania inspekcji

Inspekcja na poziomie dzierżawy odbywa się ręcznie lub przy użyciu zautomatyzowanych procesów.

Większość nowych procesów inspekcji rozpoczyna się od procesu ręcznego, szczególnie podczas programowania i podczas testowania. Proces ręcznego przeprowadzania inspekcji może ewoluować, aby stać się zautomatyzowanym procesem. Jednak nie każdy proces inspekcji musi być w pełni zautomatyzowany.

Ręczne procesy inspekcji

Inspekcja ręczna opiera się na skryptach i procesach uruchamianych na żądanie przez użytkownika (zazwyczaj administratora usługi Power BI). W razie potrzeby użytkownik uruchamia zapytania interakcyjne w celu pobrania danych inspekcji.

Inspekcja ręczna najlepiej nadaje się do:

  • Nowe skrypty, które są opracowywane i testowane.
  • Czasami jednorazowe potrzeby inspekcji.
  • Wymagania dotyczące inspekcji eksploracyjnej.
  • Bezwartościowe procesy inspekcji, które nie wymagają pełnej obsługi.

Zautomatyzowane procesy inspekcji

Inspekcja danych, które są potrzebne cyklicznie, powinna być zautomatyzowana. Jest on wyodrębniany i przetwarzany zgodnie z regularnym harmonogramem i jest znany jako zautomatyzowany proces. Czasami jest określany jako proces nienadzorowany.

Celem zautomatyzowanego procesu jest zmniejszenie nakładu pracy ręcznej, zmniejszenie ryzyka błędu, zwiększenie spójności i wyeliminowanie zależności od pojedynczego użytkownika w celu jego uruchomienia.

Automatyczne przeprowadzanie inspekcji najlepiej nadaje się do:

  • Inspekcja procesów uruchamianych w środowisku produkcyjnym.
  • Nienadzorowane procesy, które są uruchamiane zgodnie z regularnym harmonogramem.
  • Skrypty, które zostały w pełni przetestowane.
  • Podstawowe procesy inspekcji, które mają inne raporty (lub inne procesy), które zależą od niego jako źródło danych.
  • Procesy inspekcji, które są udokumentowane i obsługiwane.

Typ procesu — ręcznego lub zautomatyzowanego — może mieć wpływ na sposób obsługi uwierzytelniania. Na przykład administrator usługi Power BI może używać uwierzytelniania użytkownika do ręcznego procesu inspekcji, ale używa jednostki usługi do zautomatyzowanego procesu. Aby uzyskać więcej informacji, zobacz Określanie metody uwierzytelniania w dalszej części tego artykułu.

Porada

Jeśli istnieje regularne, cykliczne, należy uzyskać dane inspekcji, które są obecnie obsługiwane ręcznie, rozważ zainwestowanie czasu, aby je zautomatyzować. Jeśli na przykład administrator usługi Power BI ręcznie uruchamia skrypt każdego dnia w celu pobrania danych z dziennika aktywności usługi Power BI, istnieje ryzyko braku danych, jeśli ta osoba jest chora lub z dala od urlopu.

Lista kontrolna — biorąc pod uwagę typ rozwiązania inspekcji do opracowania, kluczowe decyzje i akcje obejmują:

  • Określ podstawowy cel każdego nowego wymagania dotyczącego inspekcji: zdecyduj, czy należy użyć ręcznego, czy zautomatyzowanego procesu dla każdego nowego wymagania. Zastanów się, czy decyzja ta jest tymczasowa, czy stała.
  • Utwórz plan automatyzowania: jeśli jest odpowiedni dla określonego wymagania dotyczącego inspekcji, utwórz plan automatyzacji, kiedy i przez kogo.

Uprawnienia i obowiązki

W tym momencie musisz mieć jasny pomysł na to, co chcesz osiągnąć, i dane, które będą początkowo potrzebne. Teraz warto podjąć decyzje dotyczące uprawnień użytkowników, a także ról i obowiązków.

Uprawnienia użytkownika

Podczas planowania tworzenia kompleksowego rozwiązania do inspekcji należy wziąć pod uwagę uprawnienia użytkowników dla innych użytkowników, którzy będą musieli uzyskać dostęp do danych. W szczególności zdecyduj, kto będzie mógł uzyskiwać dostęp do danych inspekcji i wyświetlać je.

Poniżej przedstawiono kilka zagadnień, które należy wziąć pod uwagę.

Bezpośredni dostęp do danych inspekcji

Należy zdecydować, kto może uzyskać bezpośredni dostęp do danych inspekcji. Istnieje wiele sposobów, aby o tym myśleć.

  • Kto powinien być administratorem usługi Power BI? Administrator usługi Power BI ma dostęp do wszystkich metadanych dzierżawy, w tym do interfejsów API administratora. Aby uzyskać więcej informacji na temat decydowania o tym, kto powinien być administratorem usługi Power BI, zobacz Planowanie zabezpieczeń na poziomie dzierżawy.
  • Kto może używać istniejącej jednostki usługi? Aby użyć jednostki usługi (zamiast uprawnień użytkownika) do uzyskiwania dostępu do danych inspekcji, należy podać wpis tajny autoryzowanym użytkownikom, aby mogli wykonywać uwierzytelnianie oparte na hasłach. Dostęp do wpisów tajnych (i kluczy) powinien być bardzo ściśle kontrolowany.
  • Czy dostęp musi być ściśle kontrolowany? Niektóre branże z wymaganiami prawnymi i zgodności muszą kontrolować dostęp bardziej ściśle niż inne branże.
  • Czy istnieją duże woluminy danych aktywności? Aby uniknąć osiągnięcia limitów ograniczania przepustowości interfejsu API, może być konieczne ścisłe kontrolowanie, kto może bezpośrednio uzyskiwać dostęp do interfejsów API generujących dane inspekcji. W takim przypadku warto upewnić się, że nie ma zduplikowanych ani nakładających się wysiłków.
Dostęp do wyodrębnionych danych pierwotnych

Należy zdecydować, kto może wyświetlać nieprzetworzone dane wyodrębnione i zapisane w lokalizacji magazynu. Najczęściej dostęp do danych pierwotnych jest ograniczony do administratorów i audytorów. Centrum Doskonałości (COE) może również wymagać dostępu. Aby uzyskać więcej informacji, zobacz Określanie miejsca przechowywania danych inspekcji w dalszej części tego artykułu.

Dostęp do wyselekcjonowanych danych analitycznych

Należy zdecydować, kto może wyświetlać wyselekcjonowane i przekształcone dane gotowe do analizy. Te dane powinny być zawsze udostępniane administratorom i audytorom. Czasami model danych jest udostępniany innym użytkownikom w organizacji, szczególnie w przypadku tworzenia modelu semantycznego usługi Power BI z zabezpieczeniami na poziomie wiersza. Aby uzyskać więcej informacji, zobacz Planowanie tworzenia wyselekcjonowanych danych w dalszej części tego artykułu.

Role i obowiązki

Po podjęciu decyzji, w jaki sposób działają uprawnienia użytkowników, możesz zacząć myśleć o rolach i obowiązkach. Zalecamy zaangażowanie odpowiednich osób na wczesnym etapie, zwłaszcza gdy wielu deweloperów lub zespołów będzie zaangażowanych w tworzenie kompleksowego rozwiązania do przeprowadzania inspekcji.

Zdecyduj, którzy użytkownicy lub zespół będą odpowiedzialni za następujące działania.

Rola Typy obowiązków Rola zwykle wykonywana przez
Komunikacja z uczestnikami projektu Działania komunikacyjne i wymagania dotyczące zbierania. CoE we współpracy z IT. Może również obejmować wybieranie osób z kluczowych jednostek biznesowych.
Podejmowanie decyzji o priorytetach i zapewnianie kierunku wymagań Działania decyzyjne związane z kompleksowego rozwiązania do przeprowadzania inspekcji, w tym sposobu spełnienia wymagań. Zespół, który nadzoruje usługę Power BI w organizacji, na przykład coE. Sponsor wykonawczy lub komitet kierowniczy ds. ładu danych może zaangażować się w podejmowanie krytycznych decyzji lub eskalację problemów.
Wyodrębnianie i przechowywanie danych pierwotnych Tworzenie skryptów i procesów w celu uzyskiwania dostępu do danych i ich wyodrębniania. Obejmuje również zapisywanie nieprzetworzonych danych do magazynu. Personel inżynierów danych, zwykle w dziale IT i we współpracy z COE.
Tworzenie wyselekcjonowanych danych Czyszczenie, przekształcanie i tworzenie wyselekcjonowanych danych w projekcie schematu gwiazdy. Personel inżynierów danych, zwykle w dziale IT i we współpracy z COE.
Tworzenie modelu danych Tworzenie modelu danych analitycznych na podstawie wyselekcjonowanych danych. Twórcy zawartości usługi Power BI zazwyczaj w IT lub COE.
Tworzenie raportów analitycznych Tworzenie raportów w celu analizowania wyselekcjonowanych danych. Bieżące zmiany w raportach oparte na nowych wymaganiach i gdy nowe dane inspekcji staną się dostępne. Twórcy raportów usługi Power BI zazwyczaj w IT lub COE.
Analizowanie danych i wykonywanie działań na podstawie wyników Analizowanie danych i reagowanie na dane inspekcji. Zespół, który nadzoruje usługę Power BI w organizacji, zwykle coE. Może również obejmować inne zespoły w zależności od wyników inspekcji i akcji. Inne zespoły mogą obejmować zabezpieczenia, zgodność, prawne, zarządzanie ryzykiem lub zarządzanie zmianami.
Testowanie i weryfikowanie Przetestuj, aby upewnić się, że wymagania dotyczące inspekcji są spełnione i czy prezentowane dane są dokładne. Twórcy zawartości usługi Power BI we współpracy z zespołem nadzorującym usługę Power BI w organizacji.
Zabezpieczanie danych Ustawianie zabezpieczeń dla każdej warstwy magazynu i zarządzanie nimi, w tym nieprzetworzonych danych i wyselekcjonowanych danych. Zarządzanie dostępem do modeli semantycznych tworzonych do analizowania danych. Administrator systemu dla systemu, który przechowuje dane we współpracy z zespołem, który nadzoruje usługę Power BI w organizacji.
Planowanie i automatyzacja Operacjonalizacja rozwiązania i planowanie procesu przy użyciu wybranego narzędzia. Personel inżynierów danych, zwykle w dziale IT i we współpracy z COE.
Obsługa rozwiązania Monitoruj rozwiązanie inspekcji, w tym przebiegi zadań, błędy i pomoc techniczną pod kątem problemów technicznych. Zespół, który obsługuje obsługę systemu usługi Power BI, czyli zwykle IT lub COE.

Wiele z powyższych ról i obowiązków można skonsolidować, jeśli będą wykonywane przez ten sam zespół lub tę samą osobę. Na przykład administratorzy usługi Power BI mogą wykonywać niektóre z tych ról.

Istnieje również możliwość, że różne osoby pełnią różne role, w zależności od okoliczności. Akcje będą kontekstowe w zależności od danych inspekcji i proponowanej akcji.

Rozważ kilka przykładów.

  • Przykład 1. Dane inspekcji pokazują, że niektórzy użytkownicy często eksportują dane do programu Excel. Podjęte działania: COE kontaktuje się z określonymi użytkownikami, aby zrozumieć ich potrzeby i nauczyć ich lepsze alternatywy.
  • Przykład 2. Dane inspekcji pokazują, że dostęp użytkowników zewnętrznych występuje w nieoczekiwany sposób. Podjęte akcje: administrator systemu IT aktualizuje odpowiednie ustawienia identyfikatora entra firmy Microsoft na potrzeby dostępu użytkowników zewnętrznych. Administrator usługi Power BI aktualizuje ustawienie dzierżawy związane z dostępem użytkowników zewnętrznych. CoE aktualizuje dokumentację i szkolenia dla twórców zawartości, którzy zarządzają zabezpieczeniami. Aby uzyskać więcej informacji, zobacz Strategia dla użytkowników zewnętrznych.
  • Przykład 3: Dane inspekcji pokazują, że kilka modeli danych definiuje tę samą miarę inaczej (dostępną z interfejsów API skanowania metadanych, jeśli są dozwolone przez szczegółowe ustawienia dzierżawy metadanych). Podjęto akcję: Komitet nadzoru nad danymi rozpoczyna projekt definiujący typowe definicje. CoE aktualizuje dokumentację i szkolenia dla twórców zawartości, którzy tworzą modele danych. CoE współpracuje również z twórcami zawartości, aby odpowiednio zaktualizować swoje modele. Aby uzyskać więcej informacji na temat pobierania szczegółowych metadanych, zobacz Uzyskiwanie dostępu do danych spisu dzierżawy w dalszej części tego artykułu.

Uwaga

Konfiguracja procesów wyodrębniania danych jest zwykle jednorazowym wysiłkiem z okazjonalnymi ulepszeniami i rozwiązywaniem problemów. Analizowanie i działanie na danych to ciągły wysiłek, który wymaga ciągłego wysiłku na bieżąco.

Lista kontrolna — podczas rozważania uprawnień i obowiązków kluczowe decyzje i akcje obejmują:

  • Zidentyfikuj, które zespoły są zaangażowane: określ, które zespoły będą zaangażowane w kompleksowe tworzenie i obsługę rozwiązania do inspekcji.
  • Zdecyduj uprawnienia użytkownika: określ, w jaki sposób uprawnienia użytkownika będą konfigurowane na potrzeby uzyskiwania dostępu do danych inspekcji. Utwórz dokumentację kluczowych decyzji na potrzeby późniejszego odwołania.
  • Podejmowanie decyzji o rolach i obowiązkach: Upewnij się, że oczekiwania są jasne dla tego, kto robi to, szczególnie w przypadku zaangażowania wielu zespołów. Utwórz dokumentację dotyczącą ról i obowiązków, w tym oczekiwanych akcji.
  • Przypisywanie ról i obowiązków: przypisz określone role i obowiązki określonym osobom lub zespołom. Zaktualizuj poszczególne opisy zadań przy użyciu zasobów ludzkich, jeśli jest to konieczne.
  • Utwórz plan szkolenia: ustanów plan dla personelu szkoleniowego, gdy wymagają nowych umiejętności.
  • Utwórz plan między trenowaniami: upewnij się, że w przypadku kluczowych ról są wykonywane trenowanie krzyżowe i tworzenie kopii zapasowych.

Decyzje techniczne

Podczas planowania rozwiązania do inspekcji na poziomie dzierżawy należy podjąć pewne ważne decyzje techniczne. Aby poprawić spójność, uniknąć przeróbki i poprawić bezpieczeństwo, zalecamy jak najszybsze podejmowanie tych decyzji.

Pierwsza faza planowania obejmuje podejmowanie następujących decyzji.

Wybieranie technologii w celu uzyskania dostępu do danych inspekcji

Najpierw musisz zdecydować, jak uzyskać dostęp do danych inspekcji.

Najprostszym sposobem rozpoczęcia pracy jest użycie wstępnie utworzonych raportów dostępnych w obszarze roboczym monitorowania administratora.

Jeśli musisz uzyskać bezpośredni dostęp do danych i utworzyć własne rozwiązanie, użyjesz interfejsu API (interfejsu programu aplikacji). Interfejsy API są przeznaczone do wymiany danych przez Internet. Interfejsy API REST usługi Power BI obsługują żądania dotyczące danych przy użyciu protokołu HTTP. Dowolny język lub narzędzie może wywoływać interfejsy API REST usługi Power BI, gdy może wysyłać żądanie HTTP i odbierać odpowiedź JSON.

Porada

Polecenia cmdlet programu PowerShell używają interfejsów API REST usługi Power BI do uzyskiwania dostępu do danych inspekcji. Aby uzyskać więcej informacji, zobacz Wybieranie interfejsów API lub poleceń cmdlet programu PowerShell w dalszej części tego artykułu.

Ta sekcja koncentruje się na wyborze technologii. Aby zapoznać się z zagadnieniami dotyczącymi źródła dostępu do określonych typów danych inspekcji, zobacz Decyzje dotyczące źródła danych w dalszej części tego artykułu.

Opcje platformy

Istnieje wiele różnych sposobów uzyskiwania dostępu do danych inspekcji. W zależności od wybranej technologii możesz chylić się w kierunku preferowanego języka. Może być również konieczne podjęcie konkretnej decyzji dotyczącej planowania uruchamiania skryptów. Technologie różnią się znacznie w swojej krzywej uczenia się i łatwości rozpoczynania pracy.

Poniżej przedstawiono niektóre technologie, których można użyć do pobierania danych przy użyciu interfejsów API REST usługi Power BI.

Technologia Dobry wybór w przypadku ręcznych procesów inspekcji Dobry wybór dla zautomatyzowanych procesów inspekcji
Obszar roboczy monitorowania administratora Obszar roboczy monitorowania administratora jest dobrym wyborem w przypadku ręcznych procesów inspekcji.
Wypróbuj Wypróbuj to dobry wybór w przypadku ręcznych procesów inspekcji.
PowerShell Program PowerShell jest dobrym wyborem w przypadku ręcznych procesów inspekcji. Program PowerShell jest dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji.
Power BI Desktop Program Power BI Desktop jest dobrym wyborem w przypadku ręcznych procesów inspekcji.
Power Automate Usługa Power Automate jest dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji.
Preferowana usługa platformy Azure Preferowana usługa platformy Azure to dobry wybór w przypadku zautomatyzowanych procesów inspekcji.
Preferowane narzędzie/język Preferowane narzędzie/język to dobry wybór w przypadku ręcznych procesów inspekcji. Preferowane narzędzie/język to dobry wybór w przypadku zautomatyzowanych procesów inspekcji.
Wyszukiwanie w dzienniku inspekcji usługi Microsoft Purview Wyszukiwanie dzienników inspekcji usługi Microsoft Purview jest dobrym wyborem w przypadku ręcznych procesów inspekcji.
Defender dla aplikacji w chmurze Defender dla Chmury Apps to dobry wybór w przypadku ręcznych procesów inspekcji.
Microsoft Sentinel Usługa Microsoft Sentinel jest dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji.

W pozostałej części tej sekcji przedstawiono krótkie wprowadzenie do każdej z opcji przedstawionych w tabeli.

Obszar roboczy monitorowania administratora

Obszar roboczy monitorowania administratora zawiera wstępnie zdefiniowane raporty i modele semantyczne w usługa Power BI. Jest to wygodny sposób, aby administratorzy sieci Szkieletowej wyświetlali najnowsze dane inspekcji i pomagali im zrozumieć działania użytkowników.

Dokumentacja narzędzia Try-it w interfejsie API

Wypróbuj to interaktywne narzędzie, które umożliwia korzystanie z interfejsu API REST usługi Power BI bezpośrednio w dokumentacji firmy Microsoft. Jest to łatwy sposób eksplorowania interfejsów API, ponieważ nie wymaga innych narzędzi ani żadnej konfiguracji na maszynie.

Możesz użyć narzędzia Try-it, aby:

  • Ręcznie wyślij żądanie do interfejsu API, aby określić, czy zwraca żądane informacje.
  • Dowiedz się, jak jest tworzony adres URL przed napisaniem skryptu.
  • Sprawdzanie danych w sposób nieformalny.

Uwaga

Aby korzystać z aplikacji Try-it, musisz być licencjonowanym i uwierzytelnianym użytkownikiem usługi Power BI. Jest zgodny ze standardowym modelem uprawnień, co oznacza, że interfejsy API użytkowników korzystają z uprawnień użytkownika, a interfejsy API administratora wymagają uprawnień administratora usługi Power BI. Nie można uwierzytelnić się za pomocą narzędzia Try-it przy użyciu jednostki usługi.

Ponieważ jest interakcyjny, najlepiej nadaje się do nauki, eksploracji i nowych ręcznych procesów inspekcji.

Program PowerShell i usługa Azure Cloud Shell

Skrypty programu PowerShell można tworzyć i uruchamiać na wiele sposobów.

Poniżej przedstawiono kilka typowych opcji.

  • Visual Studio Code: nowoczesny, lekki edytor kodu źródłowego. Jest to bezpłatne narzędzie typu open source obsługiwane na wielu platformach, w tym Windows, macOS i Linux. Można użyć programu Visual Studio Code w wielu językach, w tym programu PowerShell (przy użyciu rozszerzenia programu PowerShell).
  • Azure Data Studio: narzędzie do tworzenia skryptów i notesów. Jest ona oparta na programie Visual Studio Code. Narzędzie Azure Data Studio jest dostępne niezależnie lub w programie SQL Server Management Studio (SSMS). Istnieje wiele rozszerzeń, w tym rozszerzenie programu PowerShell.
  • Azure Cloud Shell: alternatywa dla pracy z programem PowerShell lokalnie. Dostęp do usługi Azure Cloud Shell można uzyskać w przeglądarce.
  • Azure Functions: alternatywa dla pracy z programem PowerShell lokalnie. Azure Functions to usługa platformy Azure, która umożliwia pisanie i uruchamianie kodu w środowisku bezserwerowym. Program PowerShell jest jednym z kilku obsługiwanych języków.

Ważne

Zalecamy używanie najnowszej wersji programu PowerShell (PowerShell Core) dla wszystkich nowych prac programistycznych. Należy zaprzestać korzystania z programu Windows PowerShell (który nie może uruchomić programu PowerShell Core) i zamiast tego użyć jednego z nowoczesnych edytorów kodu, które obsługują program PowerShell Core. Podczas odwoływania się do wielu przykładów online korzystających z programu Windows PowerShell (wersja 5.1), ponieważ mogą nie używać najnowszych (i lepszych) metod kodu.

Program PowerShell można używać na kilka różnych sposobów. Aby uzyskać więcej informacji na temat tej decyzji technicznej, zobacz Wybieranie interfejsów API lub poleceń cmdlet programu PowerShell w dalszej części tego artykułu.

Istnieje wiele zasobów online dostępnych do korzystania z programu PowerShell i często można znaleźć doświadczonych deweloperów, którzy mogą tworzyć rozwiązania programu PowerShell i zarządzać nimi. Program PowerShell jest dobrym wyborem do tworzenia zarówno procesów ręcznych, jak i zautomatyzowanych inspekcji.

Power BI Desktop

Ponieważ program Power BI Desktop może łączyć się z interfejsami API, może być kuszony, aby użyć go do utworzenia rozwiązania inspekcji. Istnieją jednak pewne znaczące wady i złożoność.

  • Zbieranie historii: ponieważ dziennik aktywności usługi Power BI zapewnia do 30 dni danych, utworzenie całego rozwiązania do inspekcji obejmuje zebranie zestawu plików w czasie, które przechowują wszystkie zdarzenia historyczne. Gromadzenie plików historycznych jest prostsze w przypadku innych narzędzi.
  • Bezpieczne obsługa poświadczeń i kluczy: wiele rozwiązań dostępnych w trybie online z blogerów społeczności nie jest bezpiecznych, ponieważ są to poświadczenia i klucze w postaci zwykłego tekstu w zapytaniach dodatku Power Query. Chociaż takie podejście jest łatwe, nie jest zalecane, ponieważ każdy, kto uzyskuje plik programu Power BI Desktop, może odczytać wartości. Nie można bezpiecznie przechowywać hasła (w przypadku uwierzytelniania użytkownika) ani wpisu tajnego (w przypadku korzystania z jednostki usługi) w programie Power BI Desktop, chyba że:
    • Użyj łącznika niestandardowego opracowanego za pomocą zestawu POWER Query SDK. Na przykład łącznik niestandardowy może odczytywać poufne wartości z usługi Azure Key Vault lub innej usługi, która bezpiecznie przechowuje zaszyfrowaną wartość. Istnieją również różne opcje łącznika niestandardowego dostępne w globalnej społeczności usługi Power BI.
    • Użyj opcji ApiKeyName, która działa dobrze w programie Power BI Desktop. Nie można jednak przechowywać wartości klucza w usługa Power BI.
  • Typy żądań: możesz napotkać pewne ograniczenia dotyczące tego, co można uruchomić w programie Power BI Desktop. Na przykład dodatek Power Query nie obsługuje każdego typu żądania interfejsu API. Na przykład tylko żądania GET i POST są obsługiwane w przypadku korzystania z funkcji Web.Contents . W przypadku inspekcji zwykle wysyłasz żądania GET.
  • Możliwość odświeżania: aby pomyślnie odświeżyć model semantyczny w usługa Power BI, należy postępować zgodnie z określonymi wzorcami programistycznymi dodatku Power Query. Na przykład opcja musi być obecna podczas korzystania z pliku Web.Contents, RelativePath aby usługa Power BI mogła prawidłowo zweryfikować lokalizację źródła danych bez generowania błędu w usługa Power BI.

W większości przypadków zalecamy używanie programu Power BI Desktop tylko do dwóch celów. Należy go użyć do:

  • Skompiluj model danych na podstawie istniejących wyselekcjonowanych danych (zamiast ich używać do początkowego wyodrębniania danych inspekcji).
  • Tworzenie raportów analitycznych na podstawie modelu danych.
Power Automate

Usługi Power Automate można używać z usługą Power BI na wiele sposobów. W odniesieniu do inspekcji możesz użyć usługi Power Automate do wysyłania żądań do interfejsów API REST usługi Power BI, a następnie przechowywać wyodrębnione dane w wybranej lokalizacji.

Porada

Aby wysyłać żądania do interfejsów API REST usługi Power BI, możesz użyć łącznika niestandardowego dla usługi Power Automate, aby bezpiecznie uwierzytelnić i wyodrębnić dane inspekcji. Alternatywnie możesz użyć usługi Azure Key Vault do odwołowania się do hasła lub wpisu tajnego. Obie opcje są lepsze niż przechowywanie haseł i wpisów tajnych w postaci zwykłego tekstu w przepływie usługi Power Automate.

Aby uzyskać inne pomysły na sposoby korzystania z usługi Power Automate, wyszukaj usługę Power BI w szablonach usługi Power Automate.

Preferowana usługa platformy Azure

Istnieje kilka usług platformy Azure, które mogą wysyłać żądania do interfejsów API REST usługi Power BI. Możesz użyć preferowanej usługi platformy Azure, takiej jak:

W większości przypadków można połączyć usługę obliczeniową, która obsługuje logikę wyodrębniania danych za pomocą usługi magazynu, która przechowuje nieprzetworzone dane (i wyselekcjonowane dane, jeśli jest to konieczne). Zagadnienia dotyczące podejmowania decyzji dotyczących architektury technicznej zostały opisane w dalszej części tego artykułu.

Preferowane narzędzie i/lub język

Możesz użyć preferowanego narzędzia i preferowanego języka do wysyłania żądań do interfejsów API REST usługi Power BI. Dobrym rozwiązaniem jest to, gdy twój zespół ma wiedzę na temat określonego narzędzia lub języka, takiego jak:

  • Python
  • Język C# w programie .NET Framework. Opcjonalnie możesz użyć zestawu .NET SDK usługi Power BI, który działa jako otoka na podstawie interfejsów API REST usługi Power BI, aby uprościć niektóre procesy i zwiększyć produktywność.
  • JavaScript

Portal zgodności Microsoft Purview (dawniej Centrum zgodności platformy Microsoft 365) zawiera interfejs użytkownika, który umożliwia wyświetlanie i przeszukiwanie dzienników inspekcji. Ujednolicone dzienniki inspekcji obejmują usługę Power BI i wszystkie inne usługi, które obsługują ujednolicone dzienniki inspekcji platformy Microsoft 365.

Dane przechwycone w ujednoliconym dzienniku inspekcji to dokładnie te same dane, które znajdują się w dzienniku aktywności usługi Power BI. Podczas przeszukiwania dziennika inspekcji w portal zgodności Microsoft Purview dodaje ono żądanie do kolejki. Przygotowanie danych może potrwać kilka minut (lub dłużej, w zależności od ilości danych).

Poniżej przedstawiono kilka typowych sposobów korzystania z narzędzia do wyszukiwania dzienników inspekcji. Masz następujące możliwości:

  • Wybierz obciążenie usługi Power BI, aby wyświetlić zdarzenia dla serii dat.
  • Poszukaj co najmniej jednego konkretnego działania, takiego jak:
    • Usunięty raport usługi Power BI
    • Dodano dostęp administratora do osobistego obszaru roboczego w usłudze Power BI
  • Wyświetlanie działań co najmniej jednego użytkownika.

W przypadku administratorów z wystarczającymi uprawnieniami narzędzie do wyszukiwania dzienników inspekcji w portal zgodności Microsoft Purview jest dobrym rozwiązaniem w przypadku ręcznych procesów inspekcji. Aby uzyskać więcej informacji, zobacz portal zgodności Microsoft Purview w dalszej części tego artykułu.

interfejs użytkownika usługi Defender dla Chmury Apps

usługa Defender dla Chmury Apps jest dostępna dla administratorów w usłudze Microsoft Defender XDR (portal platformy Microsoft 365). Zawiera interfejs użytkownika do wyświetlania i wyszukiwania dzienników aktywności dla różnych usług w chmurze, w tym usługi Power BI. Wyświetla on te same zdarzenia dziennika, które pochodzą z portal zgodności Microsoft Purview, oprócz innych zdarzeń, takich jak aktywność logowania użytkownika z identyfikatora Entra firmy Microsoft.

Interfejs dziennika inspekcji w usłudze Defender dla Chmury Apps jest dobrym rozwiązaniem w przypadku ręcznych procesów inspekcji. Aby uzyskać więcej informacji, zobacz Defender dla Chmury Apps w dalszej części tego artykułu.

Microsoft Sentinel i KQL

Microsoft Sentinel to usługa platformy Azure, która umożliwia zbieranie, wykrywanie, badanie i reagowanie na zdarzenia i zagrożenia bezpieczeństwa. Usługę Power BI można skonfigurować w usłudze Microsoft Sentinel jako łącznik danych, dzięki czemu dzienniki inspekcji są przesyłane strumieniowo z usługi Power BI do usługi Azure Log Analytics w usłudze Microsoft Sentinel (która jest składnikiem usługi Azure Monitor ). Za pomocą język zapytań Kusto (KQL) można analizować zdarzenia dziennika aktywności przechowywane w usłudze Azure Log Analytics.

Wyszukiwanie danych w usłudze Azure Monitor przy użyciu języka KQL jest dobrym rozwiązaniem do wyświetlania części dziennika inspekcji. Jest to również dobra opcja ręcznego przeprowadzania inspekcji procesów. Aby uzyskać więcej informacji, zobacz Microsoft Sentinel w dalszej części tego artykułu.

Zagadnienia dotyczące platformy

Poniżej przedstawiono kilka zagadnień dotyczących sposobu uzyskiwania dostępu do danych inspekcji.

  • Czy implementujesz proces ręcznego lub zautomatyzowanego przeprowadzania inspekcji? Niektóre narzędzia są silnie dopasowane do przetwarzania ręcznego lub zautomatyzowanego przetwarzania. Na przykład użytkownik zawsze uruchamia funkcję Try-it interaktywnie, więc jest odpowiedni tylko do ręcznych procesów inspekcji.
  • Jak się uwierzytelniasz? Nie wszystkie opcje obsługują każdą opcję uwierzytelniania. Na przykład funkcja Wypróbuj obsługuje tylko uwierzytelnianie użytkowników.
  • Jak bezpiecznie będą przechowywane poświadczenia? Różne technologie mają różne opcje przechowywania poświadczeń. Aby uzyskać więcej informacji, zobacz Określanie metody uwierzytelniania w dalszej części tego artykułu.
  • Która technologia jest już biegła w Twoim zespole? Jeśli istnieje narzędzie preferowane przez twój zespół i jest wygodne, zacznij tam.
  • Jaki jest twój zespół zdolny do obsługi? Jeśli inny zespół będzie obsługiwał wdrożone rozwiązanie, rozważ, czy ten zespół może odpowiednio go obsługiwać. Należy również wziąć pod uwagę, że zespoły wewnętrzne mogą wspierać programowanie wykonywane przez konsultantów.
  • Jakiego narzędzia chcesz użyć? Niektóre narzędzia i technologie mogą wymagać zatwierdzenia. Może to być spowodowane kosztem. Może to być również spowodowane zasadami zabezpieczeń IT.
  • Jakie są Twoje preferencje dotyczące planowania? Niektóre technologie podejmujące decyzję za Ciebie. Innym razem będzie to kolejna decyzja, którą musisz podjąć. Jeśli na przykład zdecydujesz się na pisanie skryptów programu PowerShell, istnieją różne sposoby ich uruchamiania. Z drugiej strony, jeśli używasz usługi w chmurze, takiej jak Azure Data Factory, planowanie jest wbudowane.

Zalecamy przejrzenie pozostałej części tego artykułu przed wybraniem technologii w celu uzyskania dostępu do danych inspekcji.

Lista kontrolna — podczas podejmowania decyzji, która technologia ma być używana do uzyskiwania dostępu do danych inspekcji, kluczowe decyzje i akcje obejmują:

  • Porozmawiaj z pracownikami IT: porozmawiaj z zespołami IT, aby dowiedzieć się, czy istnieją pewne narzędzia zatwierdzone, czy preferowane.
  • Zapoznaj się z opcjami przy użyciu małego dowodu koncepcji: wykonaj eksperymenty z technicznym weryfikacją koncepcji. Początkowo skupiaj się na uczeniu się. Następnie skoncentruj się na podjęciu decyzji o tym, co należy wykorzystać w przyszłości.

Określanie metody uwierzytelniania

Sposób konfigurowania uwierzytelniania jest kluczową decyzją. Często jest to jeden z najtrudniejszych aspektów podczas rozpoczynania pracy z inspekcją i monitorowaniem. Należy starannie rozważyć dostępne opcje, aby podjąć świadomą decyzję.

Ważne

W tej sprawie skontaktuj się z zespołami IT i zespołami ds. zabezpieczeń. Pośmiń czas, aby dowiedzieć się, jak działa zabezpieczenia w usłudze Microsoft Entra ID.

Nie każdy interfejs API w Internecie wymaga uwierzytelniania. Jednak wszystkie interfejsy API REST usługi Power BI wymagają uwierzytelniania. Podczas uzyskiwania dostępu do danych inspekcji na poziomie dzierżawy proces uwierzytelniania jest zarządzany przez Platforma tożsamości Microsoft. Jest to ewolucja usługi tożsamości Firmy Microsoft Entra, która jest oparta na standardowych protokołach branżowych.

Porada

Słownik terminów Platforma tożsamości Microsoft to zasób, który ułatwia zapoznanie się z podstawowymi pojęciami.

Przed pobraniem danych inspekcji należy najpierw uwierzytelnić się, co jest nazywane logowaniem. Pojęcia związane z uwierzytelnianiem i autoryzacją są jednak oddzielne. Proces uwierzytelniania weryfikuje tożsamość osoby wysyłającej żądanie. Proces autoryzacji udziela (lub odmawia) dostępu do systemu lub zasobu, sprawdzając , co użytkownik lub jednostka usługi ma uprawnienia do wykonania.

Po uwierzytelnieniu użytkownika lub jednostki usługi token dostępu firmy Microsoft entra jest wystawiany na serwerze zasobów, takim jak interfejs API REST usługi Power BI lub interfejs API programu Microsoft Graph. Domyślnie token dostępu wygasa po godzinie. W razie potrzeby można zażądać tokenu odświeżania.

Istnieją dwa typy tokenów dostępu:

  • Tokeny użytkownika: wystawione w imieniu użytkownika ze znaną tożsamością.
  • Tokeny tylko dla aplikacji: wystawione w imieniu aplikacji Microsoft Entra (jednostka usługi).

Aby uzyskać więcej informacji, zobacz Application and service principal objects in Microsoft Entra ID (Obiekty aplikacji i jednostki usługi w usłudze Microsoft Entra ID).

Uwaga

Aplikacja Microsoft Entra to konfiguracja tożsamości, która umożliwia zautomatyzowaną integrację procesu z identyfikatorem Entra firmy Microsoft. W tym artykule jest ona nazywana rejestracją aplikacji. Termin jednostka usługi jest również często używana w tym artykule. Te terminy zostały szczegółowo opisane w dalszej części tej sekcji.

Porada

Najprostszym sposobem uwierzytelniania jest użycie polecenia cmdlet Connect-PowerBIServiceAccount z modułu zarządzania usługi Power BI. Inne polecenia cmdlet związane z uwierzytelnianiem mogą być widoczne w artykułach i wpisach w blogu w trybie online. Istnieją na przykład Login-PowerBI polecenia cmdlet i Login-PowerBIServiceAccount , które są aliasami dla Connect-PowerBIServiceAccount polecenia cmdlet. Istnieje również polecenie cmdlet Disconnect-PowerBIServiceAccount , którego można użyć do jawnego wylogowania się na końcu procesu.

W poniższej tabeli opisano dwie opcje uwierzytelniania.

Typ uwierzytelniania Opis Przeznaczony dla Dobry wybór w przypadku ręcznych procesów inspekcji Dobry wybór dla zautomatyzowanych procesów inspekcji
Uwierzytelnianie użytkownika Zaloguj się jako użytkownik przy użyciu głównej nazwy użytkownika (adresu e-mail) i hasła. Okazjonalne, interakcyjne użycie Uwierzytelnianie użytkowników jest dobrym wyborem w przypadku ręcznych procesów inspekcji
Uwierzytelnianie nazwy głównej usługi Zaloguj się jako jednostka usługi przy użyciu wpisu tajnego (klucza) przypisanego do rejestracji aplikacji. Bieżące, zaplanowane, nienadzorowane operacje Uwierzytelnianie jednostki usługi jest dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji

Każdą opcję uwierzytelniania opisano bardziej szczegółowo w poniższej sekcji.

Uwierzytelnianie użytkownika

Uwierzytelnianie użytkownika jest przydatne w następujących sytuacjach.

  • Ręczne procesy inspekcji: chcesz uruchomić skrypt przy użyciu uprawnień użytkownika. Uprawnienia mogą być na jednym z dwóch poziomów, w zależności od typu żądania interfejsu API:
    • Uprawnienia administratora dla interfejsów API administratora: musisz użyć uprawnień administratora usługi Power BI, aby wysłać żądanie do interfejsu API administratora.
    • Uprawnienia użytkownika dla interfejsów API użytkownika: musisz użyć uprawnień użytkownika usługi Power BI, aby wysłać żądanie do interfejsu API użytkownika. Aby uzyskać więcej informacji, zobacz Wybieranie interfejsu API użytkownika lub interfejsu API administratora.
  • Logowanie interakcyjne: chcesz zalogować się interaktywnie, co wymaga wprowadzenia adresu e-mail i hasła. Na przykład musisz zalogować się interaktywnie, aby użyć środowiska Wypróbuj, które znajduje się w dokumentacji interfejsu API firmy Microsoft.
  • Śledzenie osób, które uzyskiwały dostęp do metadanych dzierżawy: gdy indywidualni użytkownicy i administratorzy wysyłają żądania interfejsu API, możesz chcieć przeprowadzić inspekcję, kim są te osoby. Po uwierzytelnieniu przy użyciu jednostki usługi (opisanej dalej) identyfikator użytkownika przechwycony przez dziennik aktywności to identyfikator aplikacji. Jeśli wielu administratorów uwierzytelnia się przy użyciu tej samej jednostki usługi, może być trudno wiedzieć, do którego administratora uzyskiwał dostęp do danych.
  • Konto administratora współużytkowanego: niektóre zespoły IT używają udostępnionego konta administratora. W zależności od tego, jak jest on implementowany i kontrolowany, może nie być najlepszym rozwiązaniem. Zamiast konta udostępnionego należy rozważyć użycie usługi Microsoft Entra Privileged Identity Management (PIM), która może udzielać okazjonalnych i tymczasowych praw administratora usługi Power BI dla użytkownika.
  • Interfejsy API, które obsługują tylko uwierzytelnianie użytkowników: czasami może być konieczne użycie interfejsu API, który nie obsługuje uwierzytelniania przez jednostkę usługi. W dokumentacji każdy interfejs API zauważa, czy jednostka usługi może ją wywołać.

Ważne

Jeśli to możliwe, zalecamy użycie uwierzytelniania jednostki usługi dla zautomatyzowanych procesów.

Uwierzytelnianie nazwy głównej usługi

Większość organizacji ma jedną dzierżawę firmy Microsoft Entra, dlatego warunki rejestracji aplikacji i jednostki usługi są używane zamiennie. Podczas rejestrowania aplikacji Microsoft Entra istnieją dwa składniki.

  • Rejestracja aplikacji: rejestracja aplikacji jest globalnie unikatowa. Jest to globalna definicja zarejestrowanej aplikacji Firmy Microsoft Entra, która może być używana przez wiele dzierżaw. Rejestracja aplikacji jest również nazywana aplikacją kliencką lub aktorem. Zazwyczaj termin aplikacja kliencka oznacza maszynę użytkownika. Nie jest to jednak sytuacja w przypadku rejestracji aplikacji. W witrynie Azure Portal aplikacje firmy Microsoft Entra znajdują się na stronie Rejestracje aplikacji w witrynie Microsoft Entra ID.
  • Jednostka usługi: jednostka usługi jest lokalną reprezentacją rejestracji aplikacji do użycia w określonej dzierżawie. Jednostka usługi pochodzi z zarejestrowanej aplikacji Firmy Microsoft Entra. W przypadku organizacji z wieloma dzierżawami firmy Microsoft Entra można odwoływać się do tej samej rejestracji aplikacji przez więcej niż jedną jednostkę usługi. W witrynie Azure Portal jednostki usługi można znaleźć na stronie Aplikacje dla przedsiębiorstw w witrynie Microsoft Entra ID.

Ponieważ jednostka usługi jest lokalną reprezentacją, uwierzytelnianie jednostki usługi jest najczęściej spotykanym sposobem odwoływania się do logowania.

Porada

Administrator firmy Microsoft Entra może poinformować, kto może utworzyć rejestrację aplikacji w organizacji i wyrazić na nie zgodę.

Uwierzytelnianie jednostki usługi jest przydatne w następujących sytuacjach.

  • Zautomatyzowane procesy inspekcji: chcesz uruchomić proces nienadzorowany zgodnie z harmonogramem.
  • Nie trzeba logować się do usługa Power BI: musisz tylko nawiązać połączenie i wyodrębnić dane. Jednostka usługi nie może zalogować się do usługa Power BI.
  • Dostęp współużytkowany do danych: Ty (osobiście) nie jesteś administratorem usługi Power BI, ale masz uprawnienia do korzystania z jednostki usługi. Jednostka usługi ma uprawnienia do uruchamiania interfejsów API administratora w celu pobrania danych na poziomie dzierżawy (lub innych określonych uprawnień).
  • Użyj przez wielu administratorów: chcesz zezwolić wielu administratorom lub użytkownikom na używanie tej samej jednostki usługi.
  • Blokady techniczne: istnieje blokada techniczna, która uniemożliwia korzystanie z uwierzytelniania użytkownika. Typowe blokady techniczne obejmują:
    • Uwierzytelnianie wieloskładnikowe (MFA): zautomatyzowane procesy inspekcji (uruchamiane nienadzorowane) nie mogą uwierzytelniać się przy użyciu konta użytkownika, gdy jest włączone uwierzytelnianie wieloskładnikowe.
    • Synchronizacja skrótów haseł: identyfikator Entra firmy Microsoft wymaga synchronizacji skrótów haseł dla konta użytkownika w celu uwierzytelnienia. Czasami zespół IT lub zespół ds. cyberbezpieczeństwa może wyłączyć tę funkcję.
Cel rejestracji aplikacji i konwencja nazewnictwa

Każda rejestracja aplikacji powinna mieć wyraźną nazwę opisjącą jej przeznaczenie i docelową grupę odbiorców (którzy mogą korzystać z rejestracji aplikacji).

Rozważ zaimplementowanie konwencji nazewnictwa, takiej jak: <Obciążenie> — Cel> — <<Odbiorcy docelowi> — <Typ obiektu>

Poniżej przedstawiono części konwencji nazewnictwa.

  • Obciążenie: zwykle równoważne źródle danych (na przykład dane usługi Power BI lub dane programu Microsoft Graph).
  • Cel: podobnie jak poziom uprawnień (na przykład Odczyt i ReadWrite). Jak opisano poniżej, cel pomaga przestrzegać zasady najniższych uprawnień podczas tworzenia oddzielnych rejestracji aplikacji, które mogą odczytywać tylko dane.
  • Docelowi odbiorcy: opcjonalnie. W zależności od obciążenia i celu docelowy odbiorca umożliwia określenie zamierzonych użytkowników rejestracji aplikacji.
  • Typ obiektu: EntraApp jest uwzględniona w celu zapewnienia przejrzystości.

Konwencja nazewnictwa może być bardziej szczegółowa, jeśli masz wiele dzierżaw lub wiele środowisk (takich jak programowanie i produkcja).

W poniższej tabeli przedstawiono przykłady rejestracji aplikacji, których można użyć do wyodrębnienia danych inspekcji na poziomie dzierżawy:

Nazwa rejestracji aplikacji Przeznaczenie Docelowej
PowerBIData-Read-AdminAPIs-EntraApp Wyodrębnianie metadanych dla całej dzierżawy na potrzeby inspekcji i administrowania usługą Power BI. Interfejsy API administratora są zawsze tylko do odczytu i mogą nie mieć uprawnień przyznanych w usłudze Microsoft Entra ID (tylko ustawienie dzierżawy usługi Power BI). Administratorzy usługi Power BI i centrum doskonałości
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp Zarządzanie dzierżawą usługi Power BI. Wymaga uprawnień do odczytu/zapisu w celu tworzenia lub aktualizowania zasobów. Administratorzy usługi Power BI i centrum doskonałości
GraphData-Read-PowerBIAdministrators-EntraApp Wyodrębnianie danych użytkowników i grup na potrzeby inspekcji i administrowania usługą Power BI. Wymaga uprawnień do odczytu. Administratorzy usługi Power BI i centrum doskonałości

Zarządzanie wieloma rejestracjami aplikacji w różnych celach wymaga większego nakładu pracy. Można jednak skorzystać z kilku zalet.

  • Zobacz, w jaki sposób rejestracja aplikacji ma być używana i dlaczego: Gdy identyfikator klienta z rejestracji aplikacji pojawi się w danych inspekcji, będziesz mieć pojęcie o tym, co było używane i dlaczego. Jest to znacząca zaleta tworzenia oddzielnych rejestracji aplikacji (zamiast używania tylko jednego ze wszystkich celów).
  • Sprawdź, kto ma być używany przez rejestrację aplikacji: gdy identyfikator klienta z rejestracji aplikacji zostanie wyświetlony w danych inspekcji, będziesz mieć pomysł, kto z niego korzystał.
  • Unikaj uprawnień do nadmiernej aprowizacji: możesz postępować zgodnie z zasadą najniższych uprawnień, zapewniając oddzielne rejestracje aplikacji różnym zestawom osób, które mają różne potrzeby. Uprawnienia do nadmiernej aprowizacji można uniknąć, korzystając z rejestracji aplikacji tylko do odczytu, gdy uprawnienia do zapisu nie są konieczne. Na przykład może istnieć kilku wysoce zdolnych użytkowników samoobsługi, którzy chcą zbierać dane dotyczące ich modeli semantycznych; potrzebują dostępu do jednostki usługi z uprawnieniami do odczytu . Mając na uwadze, że mogą istnieć członkowie satelity Centrum Doskonałości pracujący dla zespołu finansowego, którzy programowo zarządzają modelami semantycznymi; potrzebują dostępu do jednostki usługi z uprawnieniami do zapisu .
  • Dowiedz się, kto powinien być w posiadaniu wpisu tajnego: Wpis tajny dla każdej rejestracji aplikacji powinien być udostępniany tylko osobom, które jej potrzebują. Po obróceniu wpisu tajnego (opisanego w dalszej części tej sekcji) wpływ jest mniejszy, gdy używasz oddzielnych rejestracji aplikacji dla różnych potrzeb. Jest to przydatne w przypadku konieczności rotacji wpisu tajnego, ponieważ użytkownik opuszcza organizację lub zmienia role.
Uprawnienia rejestracji aplikacji

Istnieją dwa główne sposoby uzyskiwania dostępu do danych i zasobów przez rejestrację aplikacji. Obejmuje uprawnienia i zgodę.

  • Uprawnienia tylko do aplikacji: dostęp i autoryzacja są obsługiwane przez jednostkę usługi bez zalogowanego użytkownika. Ta metoda uwierzytelniania jest przydatna w scenariuszach automatyzacji. W przypadku korzystania z uprawnień tylko do aplikacji ważne jest, aby zrozumieć, że uprawnienia nie są przypisane w identyfikatorze Entra firmy Microsoft. Uprawnienia są przypisywane na jeden z dwóch sposobów:
    • W przypadku uruchamiania interfejsów API administratora: niektóre ustawienia dzierżawy usługi Power BI umożliwiają dostęp do punktów końcowych dla interfejsów API administratora (które zwracają metadane inspekcji dla całej dzierżawy). Aby uzyskać więcej informacji, zobacz Ustawianie ustawień dzierżawy usługi Power BI w dalszej części tego artykułu.
    • W przypadku uruchamiania interfejsów API użytkownika: mają zastosowanie uprawnienia obszaru roboczego i elementu usługi Power BI. Uprawnienia usługi Power BI w warstwie Standardowa kontrolują, jakie dane mogą być zwracane do jednostki usługi podczas uruchamiania interfejsów API użytkownika (które zwracają dane inspekcji na podstawie uprawnień użytkownika lub jednostki usługi wywołującej interfejs API).
  • Uprawnienia delegowane: używane są uprawnienia oparte na zakresie. Jednostka usługi uzyskuje dostęp do danych w imieniu aktualnie zalogowanego użytkownika. Oznacza to, że jednostka usługi nie może uzyskać dostępu do niczego poza tym, do czego zalogowany użytkownik może uzyskać dostęp. Należy pamiętać, że jest to inna koncepcja niż uwierzytelnianie tylko dla użytkownika, opisane wcześniej. Ponieważ aplikacja niestandardowa jest wymagana do prawidłowego obsługi kombinacji uprawnień użytkownika i aplikacji, delegowane uprawnienia są rzadko używane w scenariuszach inspekcji. Ta koncepcja jest często błędnie rozumiana, co prowadzi do wielu rejestracji aplikacji, które są nadmiernie aprowizowane z uprawnieniami.

Ważne

W tym artykule fokus dotyczy tylko uwierzytelniania użytkowników lub uwierzytelniania tylko dla aplikacji. Delegowane uprawnienia (z użytkownikiem interaktywnym i jednostką usługi) mogą odgrywać ważną rolę podczas programowego osadzania zawartości usługi Power BI. Zdecydowanie odradzamy jednak konfigurowanie delegowanych uprawnień do wyodrębniania danych inspekcji. Każdy interfejs API ogranicza częstotliwość jego uruchamiania (z ograniczaniem przepustowości), więc nie jest praktyczne, aby różni użytkownicy uzyskiwali bezpośredni dostęp do nieprzetworzonych danych inspekcji. Zamiast tego zalecamy wyodrębnienie nieprzetworzonych danych inspekcji raz (za pomocą scentralizowanego procesu), a następnie udostępnienie nadzorowanych danych inspekcji autoryzowanym użytkownikom podrzędnym.

Aby uzyskać więcej informacji, zobacz Rejestrowanie aplikacji Microsoft Entra w dalszej części tego artykułu.

Wpisy tajne rejestracji aplikacji

Rejestracja aplikacji często ma przypisany wpis tajny . Wpis tajny jest używany jako klucz do uwierzytelniania i ma datę wygaśnięcia. W związku z tym należy zaplanować regularne obracanie klucza i komunikowanie nowego klucza autoryzowanym użytkownikom.

Musisz również zaniepokoić się tym, gdzie bezpiecznie przechowywać wpis tajny. Magazyn haseł organizacji, taki jak usługa Azure Key Vault, jest doskonałym wyborem.

Porada

Alternatywną metodą korzystania z wpisu tajnego jest użycie tożsamości zarządzanej. Tożsamość zarządzana eliminuje konieczność zarządzania poświadczeniami. Jeśli zamierzasz wyodrębnić dane przy użyciu usług takich jak Azure Functions lub Azure Data Factory, dobrym rozwiązaniem jest tożsamość zarządzana.

Bezpieczne zarządzanie poświadczeniami

Niezależnie od tego, czy używasz uwierzytelniania użytkowników, czy uwierzytelniania jednostki usługi, jednym z największych wyzwań jest bezpieczne zarządzanie hasłami, wpisami tajnymi i kluczami.

Przestroga

Pierwsza reguła jest taka, że wiele osób narusza: hasła i klucze nigdy nie powinny pojawiać się w postaci zwykłego tekstu w skrypcie. Wiele artykułów, blogów i przykładów w trybie online robi to dla uproszczenia. Jednak jest to słaba praktyka, którą należy unikać. Każda osoba uzyskująca skrypt (lub plik) może potencjalnie uzyskać dostęp do tych samych danych, do których autor ma dostęp.

Poniżej przedstawiono kilka bezpiecznych metod zarządzania hasłami, wpisami tajnymi i kluczami.

  • Integracja z usługą Azure Key Vault lub innym systemem magazynu haseł organizacji, jeśli jest to możliwe.
  • Użyj poświadczeń i bezpiecznych ciągów w skryptach programu PowerShell. Poświadczenia działają zarówno w przypadku uwierzytelniania użytkownika, jak i uwierzytelniania jednostki usługi. Nie można jednak użyć poświadczeń, gdy dla konta użytkownika jest włączone uwierzytelnianie wieloskładnikowe.
  • Monituj o podanie hasła w skrypcie programu PowerShell lub użyj uwierzytelniania interakcyjnego w przeglądarce.
  • Użyj modułu Zarządzania wpisami tajnymi dla programu PowerShell opublikowanego przez firmę Microsoft. Może przechowywać wartości przy użyciu magazynu lokalnego. Można ją również zintegrować ze zdalnym usługą Azure Key Vault, co jest przydatne, gdy w organizacji istnieje wielu administratorów, którzy pracują z tymi samymi skryptami.
  • Utwórz łącznik niestandardowy dla programu Power BI Desktop, aby mógł bezpiecznie obsługiwać poświadczenia. Niektóre łączniki niestandardowe są dostępne od członków społeczności (zazwyczaj w usłudze GitHub).

Porada

Zalecamy skonsultowanie się z zespołami IT i ds. zabezpieczeń, aby pomóc wybrać najlepszą metodę lub zweryfikować, czy rozwiązanie zarządza poświadczeniami w bezpieczny sposób.

Biblioteka uwierzytelniania firmy Microsoft

Obsługa biblioteki Azure AD Authentication Library (ADAL) zakończyła się w grudniu 2022 r. W przyszłości należy użyć biblioteki Microsoft Authentication Library (MSAL). Zespół ds. zabezpieczeń w organizacji powinien zapoznać się z tą znaczącą zmianą.

Chociaż nie ważne jest, aby specjaliści usługi Power BI głęboko zrozumieli przejście do biblioteki MSAL, należy przestrzegać poniższych zaleceń.

  • Użyj najnowszej wersji modułu zarządzania usługi Power BI podczas uwierzytelniania za pomocą polecenia cmdlet Connect-PowerBIServiceAccount programu PowerShell. W wersji 1.0.946 została przełączona z biblioteki ADAL na MSAL (26 lutego 2021 r.).
  • Użyj punktu końcowego Microsoft Entra V2 podczas uwierzytelniania bezpośrednio w skrycie. Punkt końcowy Microsoft Entra V2 używa biblioteki MSAL, natomiast punkt końcowy microsoft Entra V1 używa biblioteki ADAL.
  • Zaprzestanie korzystania z interfejsów API i modułów, które są przestarzałe. Aby uzyskać więcej informacji, zobacz Przestarzałe interfejsy API i moduły w dalszej części tego artykułu.
  • Jeśli znajdziesz rozwiązanie społeczności online, upewnij się, że używa biblioteki MSAL do uwierzytelniania, a nie biblioteki ADAL.

Lista kontrolna — podczas podejmowania decyzji dotyczących zarządzania uwierzytelnianiem kluczowe decyzje i akcje obejmują:

  • Zdecyduj, jakiego typu uwierzytelniania użyć: określ, czy uwierzytelnianie użytkownika lub uwierzytelnianie jednostki usługi jest najbardziej odpowiednie, w zależności od typu rozwiązania inspekcji, które chcesz utworzyć.
  • Zaplanuj, jakich rejestracji aplikacji potrzebujesz: weź pod uwagę wymagania, obciążenia i odbiorców docelowych (użytkowników każdej rejestracji aplikacji). Zaplanuj liczbę rejestracji aplikacji, które należy utworzyć, aby obsługiwać te potrzeby.
  • Utwórz konwencję nazewnictwa dla rejestracji aplikacji: skonfiguruj konwencję nazewnictwa, która ułatwia zrozumienie zamierzonego celu i zamierzonych użytkowników każdej rejestracji aplikacji.
  • Planowanie bezpiecznego zarządzania poświadczeniami: Rozważ sposoby bezpiecznego zarządzania hasłami, wpisami tajnymi i kluczami. Zastanów się, jaka dokumentacja i szkolenia mogą być konieczne.
  • Potwierdź użycie biblioteki MSAL: określ, czy istnieją jakieś rozwiązania do ręcznego lub zautomatyzowanego inspekcji, które korzystają z biblioteki ADAL. W razie potrzeby utwórz plan ponownego zapisania tych rozwiązań w celu korzystania z nowszej biblioteki uwierzytelniania biblioteki MSAL.

Wybieranie interfejsu API użytkownika lub interfejsu API administratora

Podczas planowania pobierania danych inspekcji ważne jest użycie odpowiedniego typu interfejsu API.

Istnieją dwa typy interfejsów API, które należy wziąć pod uwagę.

  • Interfejsy API użytkownika: polegaj na uprawnieniach zalogowanego użytkownika (lub jednostki usługi), aby wysyłać żądania do interfejsu API. Na przykład jednym ze sposobów zwrócenia listy modeli semantycznych w obszarze roboczym jest użycie interfejsu API użytkownika. Uprawnienia do odczytu modeli semantycznych można udzielić za pomocą roli obszaru roboczego lub uprawnień dla poszczególnych elementów. Istnieją dwa sposoby uruchamiania interfejsów API użytkownika:
    • Uwierzytelnianie użytkownika: zalogowany użytkownik musi mieć uprawnienia dostępu do obszaru roboczego lub elementu.
    • Uwierzytelnianie jednostki usługi: jednostka usługi musi mieć uprawnienia dostępu do obszaru roboczego lub elementu.
  • Interfejsy API administratora: pobieranie metadanych z dzierżawy. Czasami jest określany jako zakres organizacyjny. Aby na przykład zwrócić listę wszystkich modeli semantycznych w dzierżawie, należy użyć interfejsu API administratora. Istnieją dwa sposoby uruchamiania interfejsów API administratora:
    • Uwierzytelnianie użytkownika: zalogowany użytkownik musi być administratorem usługi Power BI, aby uruchamiać interfejsy API administratora.
    • Uwierzytelnianie jednostki usługi: jednostka usługi musi mieć uprawnienia do uruchamiania interfejsów API administratora (bez polegania na uprawnieniach zabezpieczeń, takich jak interfejs API użytkownika).

Porada

Wszystkie interfejsy API administratora należą do grupy operacji administratora. Każdy interfejs API, który ma sufiks Jako administrator , jest interfejsem API administratora. Wszystkie pozostałe interfejsy API są interfejsami API użytkownika.

Rozważmy przykład, w którym należy uzyskać listę modeli semantycznych. W poniższej tabeli przedstawiono sześć opcji interfejsu API, których można użyć do tego celu. Cztery opcje to interfejsy API użytkowników, a dwie opcje to interfejsy API administratora. Zakres i liczba zwracanych elementów różnią się w zależności od wybranego interfejsu API.

Nazwa interfejsu API Typ interfejsu API Scope Liczba modeli semantycznych
Pobieranie zestawu danych User Osobisty obszar roboczy Jeden
Pobieranie zestawów danych User Osobisty obszar roboczy wszystkie
Pobieranie zestawu danych w grupie User Jeden obszar roboczy Jeden z nich, pod warunkiem, że zalogowany użytkownik ma uprawnienia do odczytywania modelu semantycznego
Pobieranie zestawów danych w grupie User Jeden obszar roboczy Wszystko, pod warunkiem, że zalogowany użytkownik ma uprawnienia do odczytywania każdego modelu semantycznego
Pobieranie zestawów danych w grupie jako administrator Administracja Jeden obszar roboczy wszystkie
Pobieranie zestawów danych jako administrator Administracja Cała dzierżawa wszystkie

Uwaga

Niektóre nazwy interfejsów API zawierają termin Grupa jako odwołanie do obszaru roboczego. Ten termin pochodzi z oryginalnego modelu zabezpieczeń usługi Power BI, który polegał na grupach platformy Microsoft 365. Chociaż model zabezpieczeń usługi Power BI znacznie ewoluował na przestrzeni lat, istniejące nazwy interfejsów API pozostają niezmienione, aby uniknąć przerywania istniejących rozwiązań.

Aby uzyskać informacje na temat ustawień dzierżawy, zobacz Ustawianie ustawień dzierżawy usługi Power BI w dalszej części tego artykułu.

Lista kontrolna — podczas wybierania, czy używać interfejsu API użytkownika, czy interfejsu API administratora, kluczowe decyzje i akcje obejmują:

  • Zapoznaj się z wymaganiami dotyczącymi danych: Zbieranie i dokumentowanie kluczowych wymagań biznesowych dotyczących rozwiązania do inspekcji. Na podstawie wymaganego typu danych określ, czy zakres użytkownika lub zakres organizacyjny jest odpowiedni.
  • Przetestuj wyniki: Wykonaj eksperymentowanie. Przetestuj dokładność wyników zwracanych przez różne interfejsy API.
  • Przejrzyj uprawnienia: w przypadku wszystkich istniejących rozwiązań do inspekcji upewnij się, że uprawnienia są przypisane poprawnie dla administratorów i jednostek usługi Power BI. W przypadku nowych rozwiązań do inspekcji upewnij się, która metoda uwierzytelniania będzie używana.

Wybieranie interfejsów API lub poleceń cmdlet programu PowerShell

Kluczową decyzją jest to, czy używać poleceń cmdlet programu PowerShell, gdy są dostępne dla określonych danych, które chcesz pobrać. Ta decyzja jest ważna, jeśli zdecydujesz, że program PowerShell jest jedną z technologii, których będziesz używać do uzyskiwania dostępu do danych inspekcji.

Program PowerShell to rozwiązanie automatyzacji zadań. Termin PowerShell to zbiorczy termin, który odnosi się do języka skryptowego, aplikacji powłoki wiersza polecenia i struktury zarządzania konfiguracją. PowerShell Core to najnowsza wersja programu PowerShell, która działa w systemach Windows, Linux i macOS.

Polecenie cmdlet programu PowerShell to polecenie, które wykonuje akcję. Moduł programu PowerShell to pakiet zawierający elementy członkowskie programu PowerShell, takie jak polecenia cmdlet, dostawcy, funkcje, przepływy pracy, zmienne i aliasy. Pobierasz i instalujesz moduły.

Moduł programu PowerShell tworzy warstwę abstrakcji w interfejsach API. Na przykład polecenie cmdlet Get-PowerBIActivityEvent pobiera (lub pobiera) zdarzenia inspekcji dla dzierżawy usługi Power BI. To polecenie cmdlet programu PowerShell pobiera dane z interfejsu API REST Get Activity Events . Ogólnie rzecz biorąc, łatwiej jest rozpocząć korzystanie z poleceń cmdlet, ponieważ upraszcza dostęp do bazowych interfejsów API.

Jako polecenia cmdlet programu PowerShell są dostępne tylko podzestaw interfejsów API. W miarę dalszego rozszerzania całego rozwiązania do inspekcji prawdopodobnie będziesz używać kombinacji poleceń cmdlet i interfejsów API. W pozostałej części tej sekcji możesz zdecydować, w jaki sposób będziesz uzyskiwać dostęp do danych.

Moduły programu PowerShell

Firma Microsoft opublikowała dwa moduły programu PowerShell zawierające polecenia cmdlet związane z usługą Power BI. Są one modułem zarządzania usługi Power BI i modułem bramy danych. Te moduły programu PowerShell działają jako otoka interfejsu API na podstawie podstawowych interfejsów API REST usługi Power BI. Użycie tych modułów programu PowerShell może ułatwić pisanie skryptów.

Porada

Oprócz modułów opublikowanych przez firmę Microsoft dostępne są bezpłatnie moduły i skrypty programu PowerShell opublikowane (zazwyczaj w serwisie GitHub) przez członków społeczności, partnerów i specjalistów Microsoft Most Valued Professionals (MVP).

Rozpoczęcie pracy z rozwiązaniem społeczności może odgrywać ważną rolę w tworzeniu kompleksowego rozwiązania do inspekcji. Jeśli zdecydujesz się korzystać z bezpłatnego dostępnego rozwiązania, pamiętaj, aby w pełni go przetestować. Dowiedz się, jak to działa, aby efektywnie zarządzać rozwiązaniem w czasie. Twój dział IT może mieć kryteria korzystania z publicznie dostępnych rozwiązań społeczności.

Moduł zarządzania usługą Power BI

Moduł zarządzania usługą Power BI to moduł zbiorczy zawierający określone moduły usługi Power BI do celów administracyjnych, pojemności, obszarów roboczych i nie tylko. Możesz zainstalować moduł zbiorczy w celu uzyskania wszystkich modułów lub zainstalować określone moduły. Wszystkie moduły zarządzania usługi Power BI są obsługiwane zarówno w programie Windows PowerShell, jak i programie PowerShell Core.

Ważne

Zalecamy zaprzestanie korzystania z programu Windows PowerShell (który nie może uruchomić programu PowerShell Core). Zamiast tego należy użyć jednego z nowoczesnych edytorów kodu, który obsługuje program PowerShell Core. Środowisko WINDOWS PowerShell ISE (zintegrowane środowisko skryptu) jest w stanie uruchomić program PowerShell w wersji 5.1, która nie jest już aktualizowana. Program Windows PowerShell jest teraz przestarzały, dlatego zalecamy używanie programu PowerShell Core do wszystkich nowych prac programistycznych.

Poniżej przedstawiono kilka często używanych poleceń cmdlet, których można użyć do pobierania danych inspekcji.

Moduł zarządzania Polecenie cmdlet Przeznaczenie
Profil Connect-PowerBIServiceAccount Uwierzytelnianie użytkownika lub jednostki usługi Power BI.
Administracja Get-PowerBIActivityEvent Wyświetlanie lub wyodrębnianie zdarzeń dziennika aktywności usługi Power BI dla dzierżawy.
Obszary robocze Get-PowerBIWorkspace Skompiluj listę obszarów roboczych.
Raporty Get-PowerBIReport Skompiluj listę raportów dla obszaru roboczego lub dzierżawy.
Data Get-PowerBIDataset Skompiluj listę modelu semantycznego dla obszaru roboczego lub dzierżawy.
Profil Invoke-PowerBIRestMethod Wyślij żądanie interfejsu API REST (polecenie). To polecenie cmdlet jest dobrym rozwiązaniem, ponieważ może wywoływać dowolne interfejsy API REST usługi Power BI. Jest to również dobry wybór, jeśli chcesz użyć prostszej formy uwierzytelniania przy użyciu Connect-PowerBIServiceAccount polecenia cmdlet i mieć możliwość wywołania interfejsu API, który nie ma odpowiedniego polecenia cmdlet programu PowerShell. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące używania poleceń cmdlet programu PowerShell w dalszej części tej sekcji.

Porada

Dostępne są inne polecenia cmdlet do zarządzania zawartością i publikowania jej. Jednak celem tego artykułu jest pobieranie danych inspekcji.

Moduł zarządzania usługi Power BI można pobrać z Galeria programu PowerShell. Najprostszym sposobem instalowania modułów jest użycie modułów PowerShellGet.

Zalecamy zainstalowanie modułu zestawienia zarządzania usługą Power BI. Dzięki temu wszystkie potrzebne polecenia cmdlet są dostępne. Potrzebujesz co najmniej modułu Profile (do uwierzytelniania) i wszystkich określonych modułów zawierających polecenia cmdlet, których chcesz użyć.

Przestroga

Upewnij się, że moduły są aktualne na każdym serwerze, maszynie użytkownika i usłudze w chmurze (np. Azure Automation), w której używasz programu PowerShell. Jeśli moduły nie są regularnie aktualizowane, mogą wystąpić nieprzewidywalne błędy lub problemy. Niektóre narzędzia (takie jak Visual Studio Code) ułatwiają aktualizowanie modułów. Należy również pamiętać, że polecenie PowerShellGet nie powoduje automatycznego odinstalowania starszych wersji modułu podczas instalowania lub aktualizowania nowszej wersji. Instaluje nowsze wersje wraz ze starszymi wersjami. Zalecamy sprawdzenie zainstalowanych wersji i okresowe odinstalowywanie starszych wersji.

Moduł bramy danych

Moduł bramy danych zawiera polecenia cmdlet pobierające dane z lokalnej bramy danych i jej źródeł danych. Moduł bramy danych jest obsługiwany tylko w programie PowerShell Core. Nie jest obsługiwany w programie Windows PowerShell.

W przeciwieństwie do modułu zarządzania usługi Power BI (wcześniej opisanego), moduł bramy danych nie zawiera żadnych poleceń cmdlet administratora. Wiele poleceń cmdlet (i odpowiednich interfejsów API bramy) wymaga, aby użytkownik miał uprawnienia administratora bramy.

Ostrzeżenie

Nie można przypisać jednostki usługi jako administratora bramy (nawet jeśli jednostka usługi jest członkiem grupy zabezpieczeń). W związku z tym należy zaplanować używanie poświadczeń użytkownika podczas pobierania informacji o bramach danych.

Poniżej przedstawiono kilka poleceń cmdlet z modułu bramy danych, których można użyć do pobierania danych inspekcji.

Polecenie cmdlet Przeznaczenie
Connect-DataGatewayServiceAccount Uwierzytelnianie użytkownika usługi Power BI (zwykle wymaga, aby użytkownik należał do roli administratora bramy).
Get-DataGatewayCluster Skompiluj listę klastrów bramy.
Get-DataGatewayClusterDataSource Skompiluj listę źródeł danych dla klastra bramy.
Get-DataGatewayInstaller Sprawdź, którzy użytkownicy mogą instalować i rejestrować bramy w organizacji.

Moduł data gateway można pobrać z Galeria programu PowerShell.

Techniki korzystania z programu PowerShell

Program PowerShell można używać na kilka różnych sposobów. Decyzja, którą podejmujesz, jest ważna.

W poniższej tabeli opisano trzy różne techniki korzystania z programu PowerShell.

Technika Opis Przykład
Użyj poleceń cmdlet programu PowerShell, aby uprościć uwierzytelnianie i bezpośrednio wywoływać interfejsy API. Zalecane podejście Ta technika zapewnia równowagę między prostotą i elastycznością. Polecenie cmdlet Invoke-PowerBIRestMethod jest dostępne w module Profil zarządzania usługi Power BI. To polecenie cmdlet jest często określane jako szwajcarski nóż armii, ponieważ można go użyć do wywoływania dowolnego interfejsu API REST usługi Power BI. Zaletą tej techniki jest uproszczenie uwierzytelniania, a następnie wywołanie dowolnego interfejsu API REST usługi Power BI. Zdecydowanie zalecamy użycie tej techniki. Po uwierzytelnieniu za pomocą polecenia cmdlet Connect-PowerBIServiceAccount użyj polecenia cmdlet Invoke-PowerBIRestMethod , aby pobrać dane z preferowanego interfejsu API (na przykład Pobierz użytkowników potoku jako administrator).
Użyj poleceń cmdlet programu PowerShell, jak najwięcej, zarówno na potrzeby uwierzytelniania, jak i pobierania danych. W przypadku tej techniki program PowerShell jest szeroko używany. Program PowerShell służy do koordynowania uruchamiania skryptu, a moduły programu PowerShell są używane zawsze, gdy jest to możliwe do uzyskiwania dostępu do danych. Spowoduje to utworzenie większej zależności od programu PowerShell z wielu aspektów. Po uwierzytelnieniu za pomocą polecenia cmdlet Connect-PowerBIServiceAccount użyj polecenia cmdlet (na przykład Get-PowerBIActivityEvent), aby pobrać dane.
Użyj programu PowerShell tylko do koordynowania uruchamiania procesu. Moduły programu PowerShell są używane tak mało, jak to możliwe. W przypadku tej techniki istnieje mniejsza zależność od programu PowerShell jako narzędzia, ponieważ jej podstawowym zastosowaniem jest organizowanie wywoływania wywołań interfejsu API. Do uzyskiwania dostępu do interfejsów API służy tylko jeden ogólny moduł programu PowerShell (żaden z modułów zarządzania usługi Power BI nie jest używany). Po uwierzytelnieniu przy użyciu biblioteki Microsoft Authentication Library (MSAL) wywołaj preferowany interfejs API (na przykład Pobierz użytkowników potoku jako administrator) przy użyciu ogólnego polecenia cmdlet Invoke-RestMethod w celu pobrania danych.

W powyższej tabeli pierwsza technika opisuje podejście, które równoważy łatwość użycia z elastycznością. Takie podejście zapewnia najlepszą równowagę dla potrzeb większości organizacji, dlatego jest to zalecane. Niektóre organizacje mogą mieć istniejące zasady IT i preferencje personelu, które wpływają na sposób, w jaki decydujesz się na korzystanie z programu PowerShell.

Porada

Za pomocą polecenia cmdlet Invoke-ASCmd programu PowerShell można tworzyć i wykonywać skrypty języka DAX, XMLA i TMSL . Jednak te przypadki użycia nie należą do zakresu tego artykułu. Aby uzyskać więcej informacji na temat wykonywania zapytań dotyczących dynamicznych widoków zarządzania (DMV), zobacz Inspekcja na poziomie danych.

Użytkownicy techniczni (i administratorzy) mogą używać modułów zarządzania usługi Power BI do pobierania danych lub automatyzowania niektórych aspektów zarządzania zawartością.

  • Dla administratorów: ustaw parametr na -Scope w celu Organization uzyskania dostępu do jednostek w całej dzierżawie (na przykład w celu pobrania listy wszystkich obszarów roboczych).
  • Dla użytkowników technicznych: ustaw parametr na Individual (lub pomiń parametr), aby uzyskać dostęp do jednostek należących do użytkownika (na przykład w celu pobrania listy obszarów roboczych, do których użytkownik ma uprawnienia dostępu-Scope).

Rozważmy scenariusz, w którym należy uzyskać listę modeli semantycznych. Jeśli zdecydujesz się pracować bezpośrednio z interfejsami API, musisz określić interfejs API do wywołania. Jeśli jednak zdecydujesz się użyć polecenia cmdlet Get-PowerBIDataset , możesz ustawić -Scope parametr w celu pobrania listy modeli semantycznych specyficznych dla użytkownika lub dla całej dzierżawy. Wybór zależy od decyzji dotyczącej korzystania z programu PowerShell (omówionego w poprzedniej tabeli).

W poniższej tabeli opisano sposób tłumaczenia parametrów używanych w poleceniu cmdlet programu PowerShell na wywołania programu PowerShell interfejsu API.

Parametry polecenia cmdlet Interfejs API używany przez polecenie cmdlet Typ interfejsu API Scope Pobrane elementy
-DatasetID {DatasetID}
-Scope Individual		 Pobieranie zestawu danych User Osobisty obszar roboczy Jeden semantyczny model
-Scope Individual Pobieranie zestawów danych User Osobisty obszar roboczy Wszystkie modele semantyczne
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Pobieranie zestawu danych w grupie User Jeden obszar roboczy Jeden model semantyczny, pod warunkiem że zalogowany użytkownik ma uprawnienia do odczytywania modelu semantycznego
-GroupID {WorkspaceID} Pobieranie zestawów danych w grupie User Jeden obszar roboczy Wszystkie modele semantyczne, pod warunkiem, że zalogowany użytkownik ma uprawnienia dostępu do obszaru roboczego i odczytywania modelu semantycznego
-GroupID {WorkspaceID}
-Scope Organization		 Pobieranie zestawów danych w grupie jako administrator Administracja Jeden obszar roboczy Wszystkie modele semantyczne
-Scope Organization Pobieranie zestawów danych jako administrator Administracja Cała dzierżawa Wszystkie modele semantyczne
Zagadnienia dotyczące używania poleceń cmdlet programu PowerShell

Polecenia cmdlet programu PowerShell w usłudze Power BI są prostsze, ponieważ stanowią abstrakcję niektórych złożoności wywołań interfejsu API REST.

Poniżej przedstawiono niektóre sposoby upraszczania dostępu do danych inspekcji przez polecenia cmdlet.

  • Uwierzytelnianie: najprostszym sposobem uwierzytelniania w skry skryptzie programu PowerShell jest użycie Connect-PowerBIServiceAccount polecenia cmdlet .
  • Prostota: Łatwiej jest rozpocząć pracę, ponieważ techniki pobierania danych inspekcji są proste. Należy wziąć pod uwagę, że w przypadku korzystania z polecenia cmdlet Get-PowerBIActivityEvent pobierasz jeden dzień danych inspekcji. Jednak podczas bezpośredniego wywoływania interfejsu API REST Get Activity Events pobierasz jedną godzinę danych inspekcji. Dlatego gdy używasz interfejsu API REST do pobierania danych inspekcji jednego dnia, musisz użyć pętli w celu wywołania interfejsu API 24 razy w celu wyodrębnienia każdej godziny dnia.
  • Stronicowanie dużych zestawów wyników: duże zestawy wyników są efektywnie pobierane przez stronicowanie. Stronicowanie polega na pobieraniu jednego fragmentu wyników jednocześnie. Polecenia cmdlet automatycznie zarządzają stronicacją. Jednak w przypadku bezpośredniego używania interfejsów API REST skrypt musi sprawdzić token kontynuacji, aby ustalić, czy istnieją jeszcze jakieś wyniki. Skrypt powinien kontynuować pobieranie fragmentów wyników do momentu odebrania tokenu kontynuacji. Aby zapoznać się z przykładem użycia tokenu kontynuacji, zobacz Interfejs API REST zdarzeń aktywności.
  • Wygaśnięcie tokenu dostępu: po uwierzytelnieniu zwracany jest token dostępu. Domyślnie wygasa po godzinie. Polecenia cmdlet obsługują wygaśnięcie tokenu dostępu. W ten sposób nie trzeba pisać logiki w celu żądania tokenu odświeżania.
  • Formatowanie: dane zwracane przez polecenie cmdlet są nieco bardziej sformatowane niż dane zwracane przez interfejs API REST. Dane wyjściowe są bardziej przyjazne dla użytkownika. W przypadku zautomatyzowanych procesów inspekcji prawdopodobnie nie będzie to problem. Jednak w przypadku ręcznych procesów inspekcji formatowanie kart interfejsu sieciowego może być przydatne.
Zagadnienia dotyczące bezpośredniego używania interfejsów API REST

Czasami istnieją zalety bezpośredniego wywoływania interfejsów API REST usługi Power BI.

  • Dostępnych jest wiele innych interfejsów API: dostępnych jest więcej interfejsów API REST niż polecenia cmdlet programu PowerShell. Nie pomijaj jednak elastyczności polecenia cmdlet Invoke-PowerBIRestMethod , którego można użyć do wywoływania dowolnych interfejsów API REST usługi Power BI.
  • Częstotliwość aktualizacji: firma Microsoft aktualizuje interfejsy API REST częściej niż aktualizuje moduły programu PowerShell. Jeśli na przykład nowy atrybut zostanie dodany do odpowiedzi Interfejs API pobierania zestawu danych , może upłynąć trochę czasu, zanim stanie się on dostępny w wynikach polecenia cmdlet Get-PowerBIDataset .
  • Mniej zależności języka/narzędzia: jeśli używasz interfejsów API REST bezpośrednio (zamiast polecenia cmdlet), nie musisz używać programu PowerShell. Możesz też użyć programu PowerShell tylko do organizowania wywoływania wielu interfejsów API w skrytecie. Usuwając (lub unikając) jakiejkolwiek zależności od programu PowerShell, w pewnym momencie możesz ponownie napisać logikę w innym języku. Jeśli twój zespół IT lub deweloper ma silne preferencje dotyczące narzędzi i języków, mniejsza zależność może być ważną kwestią, która należy wziąć pod uwagę.

Niezależnie od wybranej metody interfejsy API REST mogą ulec zmianie w czasie. Gdy technologia ewoluuje, interfejsy API (i moduły programu PowerShell) mogą być przestarzałe i zastępowane. W związku z tym zalecamy celowe tworzenie skryptów, które są proste w obsłudze i odporne na zmiany.

Lista kontrolna — podczas wybierania, czy uzyskać bezpośredni dostęp do interfejsów API REST, czy przy użyciu poleceń cmdlet programu PowerShell, kluczowe decyzje i akcje obejmują:

  • Skontaktuj się z działem IT w sprawie korzystania z programu PowerShell: skontaktuj się z odpowiednimi zespołami IT, aby ustalić, czy istnieją wymagania wewnętrzne lub preferencje dotyczące sposobu używania programu PowerShell.
  • Zdecyduj, jak chcesz używać programu PowerShell: określ, które techniki programu PowerShell mają być używane i czy chcesz celowo zwiększyć lub zmniejszyć zależność od programu PowerShell. Zastanów się, czy komunikacja wewnętrzna czy szkolenie jest konieczne.
  • Uaktualnianie do programu PowerShell Core: badania przy użyciu programu PowerShell Core. Ustal, czy należy zaktualizować maszyny administratora. Zastanów się, które istniejące skrypty należy przetestować. Ustal, czy administratorzy lub deweloperzy potrzebują dodatkowego szkolenia, aby podnieść swoje umiejętności.
  • Ustal, które moduły programu PowerShell mają być używane: rozważ użycie modułów zarządzania usługi Power BI i/lub modułu bramy danych.
  • Zdecyduj, czy projekty społeczności są dozwolone: określ, czy zezwalasz (a nawet zachęcano) na korzystanie z modułów programu PowerShell dostępnych w trybie online (a moduły opublikowane przez firmę Microsoft). Skontaktuj się z it, aby ustalić, czy istnieją kryteria dla projektów społeczności uzyskanych w trybie online.
  • Wyjaśnij, jak obsługiwać projekty społeczności: jeśli projekty społeczności programu PowerShell są dozwolone, należy rozważyć, kto będzie odpowiedzialny za ich obsługę, gdy będą używane wewnętrznie.
  • Ukończ mały dowód koncepcji: eksperymentuj z technicznym weryfikacją koncepcji. Potwierdź preferowane narzędzia klienckie i metodę uzyskiwania dostępu do danych.
  • Określ, jak obsługiwać zaawansowanych użytkowników: rozważ, jak będziesz obsługiwać użytkowników technicznych, którzy tworzą automatyzację samodzielnie przy użyciu interfejsów API użytkownika.

Określanie miejsca przechowywania danych inspekcji

Jeśli planujesz utworzyć kompleksowe rozwiązanie do inspekcji, musisz zdecydować, gdzie mają być przechowywane nieprzetworzone dane (oraz dane wyselekcjonowane, które zostały omówione w następnej sekcji). Twoje decyzje dotyczące magazynu danych są powiązane z preferencjami dotyczącymi sposobu obsługi integracji danych.

Podczas wyodrębniania nieprzetworzonych danych inspekcji zachowaj prostotę. Zalecamy, aby nie wybierać określonych atrybutów, wykonywać przekształceń ani stosować żadnego formatowania podczas początkowego wyodrębniania danych. Zamiast tego wyodrębnij wszystkie dostępne atrybuty i zapisz dane w oryginalnym stanie.

Oto kilka powodów, dla których przechowywanie danych pierwotnych w ich pierwotnym stanie jest najlepszym rozwiązaniem.

  • Wszystkie dane dostępne w historii: nowe atrybuty i nowe typy zdarzeń staną się dostępne w miarę upływu czasu. Przechowywanie wszystkich danych pierwotnych jest dobrym sposobem na zapewnienie, że zawsze będziesz mieć dostęp do danych, które były dostępne w momencie ich wyodrębnienia. Nawet jeśli zajmuje ci to trochę czasu — co może być tygodniami lub miesiącami — aby zdać sobie sprawę, że są dostępne nowe atrybuty danych, można je przeanalizować historycznie, ponieważ przechwyciliśmy je w nieprzetworzonych danych.
  • Odporność na zmianę: jeśli format danych pierwotnych ulegnie zmianie, proces wyodrębniania danych nie ma wpływu. Ponieważ niektóre dane inspekcji są wrażliwe na czas, ważne jest, aby upewnić się, że projektujesz proces wyodrębniania danych, który nie ulegnie awarii w przypadku zmiany w źródle.
  • Role i obowiązki: Różni członkowie zespołu (na przykład inżynierowie danych lub administratorzy sieci szkieletowej) mogą być odpowiedzialni za tworzenie procesów uzyskiwania dostępu, wyodrębniania i przechowywania nieprzetworzonych danych inspekcji. Uproszczenie procesu wyodrębniania danych ułatwia wielu zespołom współpracę.

Poniżej przedstawiono kilka opcji przechowywania danych pierwotnych.

  • Magazyn typu data lake lub magazyn obiektów: usługa w chmurze, taka jak OneLake , która specjalizuje się w przechowywaniu plików dowolnej struktury. Jest to idealny wybór do przechowywania nieprzetworzonych danych inspekcji. W architekturze usługi Data Lake dane pierwotne powinny być przechowywane w warstwie z brązu.
  • System plików: system plików (taki jak Windows lub Linux) jest typowym wyborem do przechowywania nieprzetworzonych danych inspekcji.
  • Baza danych: istnieje możliwość przechowywania danych JSON w relacyjnej bazie danych, takiej jak Usługa Azure SQL Database. Jednak jest to mniej powszechne niż przechowywanie danych w usłudze Data Lake lub systemie plików. Dzieje się tak, ponieważ wykonywanie zapytań i utrzymywanie danych JSON może stać się trudne i kosztowne, zwłaszcza w miarę wzrostu ilości danych.

Porada

W przypadku korzystania z usługi Data Lake, magazynu obiektów lub systemu plików zalecamy przechowywanie danych w sposób łatwy w organizowaniu i zabezpieczaniu. Ważne jest również, aby jasno określić, czy dane obejmują zdarzenia (które są zwykle dołączane) lub czy jest to migawka punktu w czasie (która wymaga wybrania daty do przeanalizowania).

Rozważmy przykład obejmujący nieprzetworzone strefy danych typu data lake. Strefa ma hierarchię folderów do przechowywania danych dziennika aktywności: Raw > ActivityLog > RRRR > MM. Foldery są partycjonowane według roku i miesiąca. Plik przechowywany w folderze month używa następującego formatu: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. RRRRMMDD reprezentuje rzeczywiste dane, a RRRRMDDDTTTT reprezentuje sygnaturę czasową wyodrębniania. Dołączając sygnaturę czasową wyodrębniania, można określić, który plik jest najnowszy (w przypadku konieczności ponownego wyodrębnienia danych). Jeśli na przykład wyodrębnisz dane o 9:00 (UTC) w dniu 25 kwietnia 2023 r. w dniu 23 kwietnia 2023 r., nazwa pliku to PBIActivityLog-20230523-202305250900.

Zdecydowanie zalecamy użycie technologii, która umożliwia zapisywanie nieprzetworzonych danych w magazynie niezmiennym. Niezmienny magazyn gwarantuje, że po zapisaniu danych nie można go zastąpić ani usunąć. To rozróżnienie jest ważne dla audytorów i pozwala ufać, że nieprzetworzone dane są wiarygodne.

Należy również rozważyć sposób bezpiecznego przechowywania danych pierwotnych. Zazwyczaj bardzo niewielu użytkowników wymaga dostępu do danych pierwotnych. Dostęp do danych pierwotnych jest zwykle zapewniany na podstawie potrzeb, zazwyczaj dla inżynierów danych i administratorów systemu. Wewnętrzni audytorzy mogą również potrzebować dostępu. Członkowie zespołu, którzy są odpowiedzialni za tworzenie wyselekcjonowanych danych (opisanych w dalszej części) wymagają również dostępu do danych pierwotnych.

Poniżej przedstawiono kilka zagadnień, które pomogą Ci wybrać magazyn danych pierwotnych.

  • Czy jest to proces ręcznego lub zautomatyzowanego przeprowadzania inspekcji? Zautomatyzowany proces inspekcji zwykle ma bardziej rygorystyczne wymagania dotyczące sposobu i miejsca przechowywania danych.
  • Czy obszar tematu jest szczególnie wrażliwy? W zależności od typu danych i tego, jak jest to poufne, organizacja może mieć wymaganie dotyczące sposobu i miejsca ich przechowywania. Dane inspekcji usługi Power BI zawierają informacje o użytkownikach i adresach IP, więc powinny być przechowywane w bezpiecznym obszarze.
  • Czy istnieje preferowana technologia magazynowania? Może istnieć istniejąca technologia magazynowania, która jest używana w organizacji, więc jest to wybór logiczny.
  • Czy użytkownicy będą uzyskiwać bezpośredni dostęp do magazynu? Model zabezpieczeń jest ważnym zagadnieniem. Zazwyczaj bardzo niewielu użytkowników otrzymuje dostęp do danych pierwotnych. Dostęp do wyselekcjonowanych danych jest zwykle udostępniany twórcom zawartości usługi Power BI, którzy są odpowiedzialni za tworzenie scentralizowanego modelu danych (semantyczny model, który służy jako warstwa raportowania).
  • Czy masz wymagania dotyczące rezydencji danych? Niektóre organizacje mają wymagania dotyczące przechowywania danych prawnych lub prawnych w celu przechowywania danych w określonym regionie danych.
  • Jak będą zorganizowane dane? Korzystanie z architektury medalionu jest powszechną praktyką, szczególnie w implementacjach typu data lake i lakehouse. Celem jest przechowywanie danych w warstwach danych z brązu, srebra i złota. Warstwa z brązu zawiera oryginalne nieprzetworzone dane. Warstwa srebrna zawiera zweryfikowane i deduplikowane dane używane do przekształceń. Warstwa złota zawiera wyselekcjonowane, wysoce wyrafinowane dane, które są gotowe do analizy.

Lista kontrolna — podczas planowania lokalizacji przechowywania danych pierwotnych kluczowe decyzje i akcje obejmują:

  • Skontaktuj się z działem IT: skontaktuj się z odpowiednimi zespołami IT, aby ustalić, czy istnieją procesy uruchomione w celu wyodrębnienia nieprzetworzonych danych inspekcji. Jeśli tak, sprawdź, czy możesz uzyskać dostęp do istniejących danych. Jeśli wymagany jest nowy proces wyodrębniania danych, określ, czy istnieją preferencje lub wymagania dotyczące miejsca przechowywania danych.
  • Zdecyduj, gdzie mają być przechowywane nieprzetworzone dane: określ najlepszą lokalizację magazynu i strukturę do przechowywania danych pierwotnych.
  • Określanie wymagań dotyczących rezydencji danych: dowiedz się, czy istnieją wymagania prawne, czy prawne dotyczące miejsca przechowywania danych.
  • Utwórz strukturę folderów i konwencję nazewnictwa: określ konwencję nazewnictwa używaną dla nieprzetworzonych plików danych, w tym struktury folderów. Dołącz te szczegóły do dokumentacji technicznej.
  • Zastanów się, jak będą działać zabezpieczenia danych pierwotnych: podczas projektowania lokalizacji przechowywania danych pierwotnych należy wziąć pod uwagę, kto będzie musiał uzyskiwać dostęp do danych i jak zostanie udzielony dostęp.

Planowanie tworzenia wyselekcjonowanych danych

Wyselekcjonowane dane obsługują analizę i są zaprojektowane tak, aby było przyjazne dla użytkownika. Musisz podjąć pewne decyzje dotyczące sposobu i miejsca tworzenia wyselekcjonowanych danych. Wybrana technologia do przechowywania wyselekcjonowanych danych może być dowolną z technologii wymienionych w poprzedniej sekcji.

Celem wyselekcjonowanych danych jest przekształcenie danych w bardziej przyjazny format zoptymalizowany pod kątem analizy i raportowania. Stanowi ona źródło danych modelu danych usługi Power BI, co oznacza, że używasz modelu danych usługi Power BI do analizowania użycia usługi Power BI w organizacji. Mają zastosowanie podstawowe wskazówki dotyczące modelu danych: należy przyjąć projekt schematu gwiazdy zoptymalizowany pod kątem wydajności i użyteczności.

Możesz utworzyć wyselekcjonowane dane na różne sposoby. Musisz zdecydować, jak przeprowadzić integrację danych i jak daleko do góry stosować przekształcenia, które przygotowują dane do ładowania do schematu gwiazdy.

Data Lake

Przekształcenia można stosować i tworzyć wyselekcjonowane pliki danych w usłudze Data Lake. Należy użyć warstwy złota do wyselekcjonowanych danych, aby była logicznie oddzielona od danych pierwotnych przechowywanych w warstwie z brązu. Oddzielenie danych w warstwach upraszcza również ustawianie różnych uprawnień dostępu użytkowników.

Użyj usługi Data Lake, aby przekształcić i przetworzyć dane w następujących przypadkach:

  • Oczekujesz, że będzie wiele modeli danych usługi Power BI obsługujących raportowanie (co uzasadnia utworzenie pośredniej warstwy srebra).
  • Musisz obsługiwać wielu samoobsługowych twórców zawartości, którzy potrzebują dostępu do danych inspekcji na poziomie dzierżawy.
  • Masz istniejące narzędzia i procesy, których chcesz użyć do przekształcania i ładowania danych.
  • Chcesz zminimalizować przygotowanie danych, które należy wykonać (i potencjalnie zduplikować) w co najmniej jednym modelu danych usługi Power BI.
Model danych usługi Power BI

Możesz ukończyć wszystkie prace związane z transformacją w usłudze Power BI. Użyj dodatku Power Query, aby uzyskać dostęp do danych i przekształcić je ze stanu pierwotnego na format wyselekcjonowy.

Użyj modelu danych usługi Power BI, gdy:

  • Chcesz uprościć kompleksową architekturę i załadować model danych bezpośrednio z danych pierwotnych. (Odświeżanie przyrostowe może pomóc zmniejszyć czas trwania odświeżania).
  • Preferencją jest wykonywanie wszystkich zadań przekształcania podczas ładowania modelu danych.
  • Oczekujesz, że masz jeden scentralizowany model danych dla danych inspekcji na poziomie dzierżawy. Wszystkie raporty (lub inne modele danych) mogą używać scentralizowanego modelu semantycznego usługi Power BI jako źródła.
  • Chcesz zapewnić dostęp użytkownika tylko do scentralizowanego modelu semantycznego usługi Power BI (a nie żadnego ze źródłowych danych).

Porada

Podczas tworzenia wyselekcjonowanych danych skonfiguruj je w taki sposób, aby można było łatwo ponownie uruchomić proces dla wcześniejszych zakresów dat. Jeśli na przykład wykryjesz, że nowy atrybut pojawił się w dziennikach inspekcji trzy miesiące temu, będzie można go przeanalizować, ponieważ po raz pierwszy się pojawił. Możliwość ponownego załadowania wyselekcjonowanej historii danych jest jedną z kilku przyczyn, dla których ważne jest przechowywanie danych pierwotnych w oryginalnym stanie (opisanym wcześniej w tym artykule).

Aby uzyskać więcej informacji na temat tabel wymiarów i tabel faktów, które można uwzględnić w schemacie gwiazdy, zobacz Tworzenie modelu danych w dalszej części tego artykułu.

Lista kontrolna — podczas planowania tworzenia wyselekcjonowanych danych kluczowe decyzje i akcje obejmują:

  • Zdecyduj, gdzie należy wykonać przekształcenia: rozważ, jak daleko należy wykonać pracę nad transformacją i gdzie pasuje do planu dla całej architektury.
  • Zdecyduj, jakiego narzędzia używać do przekształcania danych w schemat gwiazdy: Potwierdź, które narzędzia i usługi będą używane do przekształcania danych pierwotnych w wyselekcjonowane dane.
  • Zdecyduj, gdzie mają być przechowywane wyselekcjonowane dane: określ najlepszy wybór do przechowywania nieprzetworzonych danych, które zostały przekształcone w format schematu gwiazdy. Zdecyduj, czy pośrednia warstwa srebra jest przydatna w kompleksowej architekturze.
  • Utwórz konwencję nazewnictwa: określ konwencję nazewnictwa używaną dla wyselekcjonowanych plików danych i folderów (jeśli ma to zastosowanie). Dołącz szczegóły do dokumentacji technicznej.
  • Zastanów się, jak będą działać zabezpieczenia wyselekcjonowanych danych: podczas projektowania nadzorowanego miejsca przechowywania danych należy wziąć pod uwagę, kto będzie musiał uzyskiwać dostęp do danych i jak zostaną przypisane zabezpieczenia.

Decyzje dotyczące źródła danych

W tym momencie należy jasno określić wymagania, potrzeby dotyczące danych i uprawnienia. Podjęto kluczowe decyzje techniczne. Teraz musisz podjąć pewne decyzje dotyczące podejścia do sposobu uzyskiwania określonych typów danych.

Uzyskiwanie dostępu do danych aktywności użytkownika

Dane aktywności użytkownika usługi Power BI, które są czasami określane jako dziennik aktywności lub dzienniki inspekcji, zawierają wiele informacji, które ułatwiają zrozumienie, co dzieje się w dzierżawie usługi Power BI. Aby uzyskać więcej informacji na temat identyfikowania potrzeb dotyczących danych, zobacz Dane aktywności użytkownika wcześniej w tym artykule.

Usługa Power BI integruje dzienniki z ujednoliconym dziennikiem inspekcji usługi Microsoft Purview (wcześniej znanym jako ujednolicony dziennik inspekcji platformy Microsoft 365). Ta integracja jest zaletą, ponieważ oznacza to, że każda usługa platformy Microsoft 365 nie musi implementować własnego unikatowego sposobu rejestrowania. Jest domyślnie włączony.

Ważne

Jeśli nie wyodrębnisz jeszcze danych aktywności użytkownika, upewnij się, że priorytet jest pilny. Dane aktywności użytkownika są dostępne przez ostatnie 30 lub 90 dni (w zależności od źródła). Nawet jeśli nie jesteś gotowy do szczegółowej analizy, ważne jest, aby rozpocząć wyodrębnianie i przechowywanie danych tak szybko, jak to możliwe. Dzięki temu będzie dostępna cenna historia do analizy.

Istnieje kilka opcji pobierania danych aktywności użytkownika.

Technika Opis Dostępne są domyślne dni historii Dobry wybór w przypadku ręcznych procesów inspekcji Dobry wybór dla zautomatyzowanych procesów inspekcji Dobry wybór do skonfigurowania alertów Dobry wybór, aby szybko rozpocząć pracę
Ręczne (interfejs użytkownika) Portal zgodności Microsoft Purview 90 portal zgodności Microsoft Purview jest dobrym wyborem w przypadku ręcznych procesów inspekcji. portal zgodności Microsoft Purview jest dobrym wyborem, aby szybko rozpocząć pracę.
Ręczne (interfejs użytkownika) Defender dla aplikacji w chmurze 30 Defender dla Chmury Apps to dobry wybór w przypadku ręcznych procesów inspekcji. Defender dla Chmury Apps to dobry wybór do skonfigurowania alertów.
Programowa Dziennik aktywności usługi Power BI (interfejs API lub polecenie cmdlet programu PowerShell) 30 Dziennik aktywności usługi Power BI (interfejs API lub polecenie cmdlet programu PowerShell) to dobry wybór dla zautomatyzowanych procesów inspekcji. Dziennik aktywności usługi Power BI (interfejs API lub polecenie cmdlet programu PowerShell) to dobry wybór, aby szybko rozpocząć pracę.
Programowa Interfejs API działań zarządzania usługi Office 365 7 Interfejs API działań usługi Office 365 Management to dobry wybór w przypadku zautomatyzowanych procesów inspekcji.
Programowa Microsoft Sentinel (Azure Monitor) 30 Usługa Microsoft Sentinel (Azure Monitor) jest dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji. Usługa Microsoft Sentinel (Azure Monitor) to dobry wybór do skonfigurowania alertów.

W pozostałej części tej sekcji przedstawiono poszczególne techniki przedstawione w tabeli.

Portal zgodności Microsoft Purview

Narzędzie wyszukiwania inspekcji w portal zgodności Microsoft Purview (wcześniej znane jako centrum zgodności platformy Microsoft 365) to wygodne miejsce do wyświetlania działań i alertów. To narzędzie nie wymaga utworzenia skryptu w celu wyodrębnienia i pobrania danych. Możesz wybrać obciążenie usługi Power BI, aby wyświetlić wszystkie rekordy dziennika inspekcji dla zakresu czasu. Możesz również zawęzić wyniki, wybierając określone działania i użytkowników. Na przykład menedżer prosi Cię o to, kto usunął obszar roboczy wcześniej tego dnia, aby mógł szybko skontaktować się z osobą w celu omówienia sytuacji.

Najnowsze 90 dni historii są dostępne w usłudze Audit (Standard). Dzięki funkcji Inspekcja (Premium) długoterminowe przechowywanie umożliwia (opcjonalnie) przechowywanie dzienników inspekcji dłużej. Ponieważ długoterminowe przechowywanie dotyczy tylko licencjonowanych użytkowników E5, wyklucza rekordy inspekcji dla użytkowników innych niż E5 i użytkowników-gości. W związku z tym zalecamy poleganie tylko na domyślnej 90-dniowej historii, aby upewnić się, że wszystkie działania są przechwytywane.

Istnieją wymagania licencyjne dotyczące uzyskiwania dostępu do dzienników inspekcji w portal zgodności Microsoft Purview. Uprawnienia usługi Exchange Online z podwyższonym poziomem uprawnień są również wymagane w celu uzyskania dostępu do dzienników inspekcji.

Porada

Domyślnie administratorzy usługi Power BI nie mają uprawnień dostępu do ujednoliconego przeszukiwania dzienników inspekcji w portal zgodności Microsoft Purview. Ponieważ zawiera ona dane dla wielu usług platformy Microsoft 365, jest to rola o wysokim poziomie uprawnień. W większości organizacji te uprawnienia są zarezerwowane dla niewielkiej liczby administratorów IT. Istnieją inne opcje dostępne dla administratorów usługi Power BI, które zostały opisane w dalszej części tej sekcji.

Interfejs użytkownika w portal zgodności Microsoft Purview jest przydatny w przypadku ręcznych procesów inspekcji i okazjonalnych badań działań użytkownika.

Defender dla aplikacji w chmurze

Portal w usłudze Defender dla Chmury Apps to wygodne miejsce do wyświetlania działań i alertów bez konieczności tworzenia skryptu w celu wyodrębniania i pobierania danych. Umożliwia również wyświetlanie danych z dziennika aktywności usługi Power BI i logowań użytkowników.

Defender dla Chmury Apps zawiera interfejs użytkownika umożliwiający wyświetlanie i wyszukiwanie dzienników aktywności dla różnych usług w chmurze, w tym usługi Power BI. Wyświetla on te same zdarzenia dziennika, które pochodzą z ujednoliconego dziennika inspekcji usługi Microsoft Purview, i zawiera inne zdarzenia, takie jak aktywność logowania użytkownika z identyfikatora Entra firmy Microsoft.

Podobnie jak portal zgodności Microsoft Purview (opisane w poprzedniej sekcji), Defender dla Chmury Apps ma interfejs użytkownika z możliwością wyszukiwania. Jednak opcje filtru są inne. Oprócz standardowej 30-dniowej historii można użyć usługi Defender dla Chmury Apps, aby wyświetlić do sześciu miesięcy historii dziennika aktywności (w siedmiodniowych przyrostach).

Istnieją wymagania licencyjne dotyczące uzyskiwania dostępu do aplikacji Defender dla Chmury. Wymagane są również oddzielne uprawnienia .

Porada

Domyślnie administratorzy usługi Power BI nie mają uprawnień dostępu do aplikacji Defender dla Chmury. W usłudze Defender dla Chmury Apps istnieje rola usługi Power BI. Dodanie administratorów usługi Power BI do tej roli jest dobrym sposobem udzielenia im dostępu do ograniczonego zestawu danych.

Interfejs użytkownika w usłudze Defender dla Chmury Apps jest przydatny w przypadku ręcznych procesów inspekcji i jednorazowych badań działań użytkownika.

Dziennik aktywności usługi Power BI

Dziennik aktywności usługi Power BI pochodzi z ujednoliconego dziennika inspekcji. Zawiera tylko działania użytkownika związane z usługa Power BI.

Porada

W przypadku organizacji, które planują wyodrębnić działania użytkowników, zalecamy rozpoczęcie od dziennika aktywności usługi Power BI. Najprostszym źródłem jest programowe uzyskiwanie dostępu.

Dostępne są dwie opcje uzyskiwania dostępu do dziennika aktywności usługi Power BI.

Aby uzyskać informacje o tym, której opcji użyć, zobacz Wybieranie interfejsów API lub poleceń cmdlet programu PowerShell wcześniej w tym artykule.

Porada

Przykłady uzyskiwania dostępu do dziennika aktywności usługi Power BI za pomocą programu PowerShell można znaleźć w temacie Access the Power BI activity log (Uzyskiwanie dostępu do dziennika aktywności usługi Power BI).

Dane dziennika aktywności usługi Power BI są dostępne dla wszystkich administratorów sieci szkieletowej i administratorów platformy Power Platform. Dostęp do danych można uzyskać z ujednoliconego dziennika inspekcji dostępnego dla niektórych ról usługi Exchange Online. Aby uzyskać więcej informacji, zobacz Śledzenie działań użytkowników w usłudze Power BI.

Zalecamy użycie dziennika aktywności usługi Power BI, gdy twoim zamiarem jest pobranie tylko rekordów dziennika inspekcji usługi Power BI.

Uwaga

W danych dziennika inspekcji obszary robocze są określane jako foldery. W interfejsie API REST usługi Power BI obszary robocze są określane jako grupy.

Interfejs API działań zarządzania usługi Office 365

Możesz wyodrębnić dane z ujednoliconego dziennika inspekcji dla innych usług, takich jak SharePoint Online, Teams, Exchange Online, Dynamics 365 i Power BI. Jeśli twoim celem jest zaimplementowanie rozwiązania do inspekcji i monitorowania dla wielu usług, zalecamy użycie interfejsu API działań zarządzania usługi Office 365. Ponieważ ten interfejs API zwraca dane z wielu usług, jest znany jako ujednolicony interfejs API inspekcji (lub ujednolicony dziennik inspekcji). Jest to jeden z interfejsów API zarządzania usługą Office 365.

Przed utworzeniem nowego rozwiązania zalecamy skontaktowanie się z działem IT w celu ustalenia, czy są dostępne istniejące rekordy inspekcji usługi Power BI. Istnieje możliwość, że proces już wyodrębnia i przechowuje dane. Istnieje również możliwość uzyskania uprawnień dostępu do tych danych zamiast tworzenia nowego rozwiązania.

Dostęp do danych można uzyskać na jeden z dwóch sposobów.

Ważne

Polecenie Search-UnifiedAuditLog cmdlet nie jest dobrze skalowane i wymaga zaimplementowania strategii pętli w celu pokonania limitu 5000 wierszy. Z tych powodów jest ona odpowiednia dla okazjonalnych zapytań lub małych organizacji, które doświadczają niskiej aktywności. Jeśli potrzebujesz tylko danych usługi Power BI, zalecamy użycie polecenia cmdlet Get-PowerBIActivityEvent .

Ogólnie rzecz biorąc, wprowadzenie do interfejsu API działań zarządzania usługi Office 365 jest trudniejsze niż korzystanie z dziennika aktywności usługi Power BI (opisanego wcześniej). Dzieje się tak, ponieważ interfejs API zwraca obiekty blob zawartości, a każdy obiekt blob zawartości zawiera poszczególne rekordy inspekcji. W przypadku dużych organizacji może istnieć tysiące obiektów blob zawartości dziennie. Ponieważ klienci i aplikacje innych firm intensywnie korzystają z tego interfejsu API, firma Microsoft implementuje ograniczanie, aby upewnić się, że korzystanie z usługi nie ma negatywnego wpływu na inne osoby (znane jako problem z hałaśliwym sąsiadem ). W związku z tym pobieranie dużych ilości historii może stanowić wyzwanie w większych organizacjach. Aby uzyskać więcej informacji, zobacz ten artykuł dotyczący rozwiązywania problemów.

Aby korzystać z tego interfejsu API, musisz uwierzytelnić się przy użyciu jednostki usługi, której udzielono uprawnień do pobierania danych z interfejsu API działań usługi Office 365 Management.

Porada

Domyślnie administratorzy usługi Power BI nie mają uprawnień dostępu do interfejsu API działań zarządzania usługi Office 365. Ponieważ zawiera ona dane dla wielu usług platformy Microsoft 365, dostęp wymaga uprawnień administratora o wysokim poziomie uprawnień lub ról inspekcji. W większości organizacji te role są zarezerwowane dla niewielkiej liczby administratorów IT. Dziennik aktywności usługi Power BI jest przeznaczony do użycia przez administratorów usługi Power BI.

Programowe pobieranie danych inspekcji z interfejsu API działań zarządzania usługi Office 365 jest dobrym wyborem, gdy dział IT musi wyodrębnić i przechowywać dzienniki inspekcji z różnych usług (poza usługą Power BI).

Microsoft Sentinel

Microsoft Sentinel to usługa platformy Azure, która umożliwia zbieranie, wykrywanie, badanie i reagowanie na zdarzenia i zagrożenia bezpieczeństwa. Usługę Power BI można skonfigurować w usłudze Microsoft Sentinel jako łącznik danych. Po nawiązaniu połączenia dzienniki inspekcji (zawierające podzestaw danych) są przesyłane strumieniowo z usługi Power BI do usługi Azure Log Analytics, co jest funkcją usługi Azure Monitor.

Porada

Usługa Azure Log Analytics jest oparta na tej samej architekturze używanej przez dzienniki zdarzeń modelu semantycznego na poziomie obszaru roboczego. Aby uzyskać więcej informacji na temat dzienników zdarzeń modelu semantycznego, zobacz Inspekcja na poziomie danych.

Ponieważ jest to oddzielna usługa platformy Azure, każdy administrator lub użytkownik, którego chcesz uruchomić zapytania język zapytań Kusto (KQL), muszą mieć przyznane uprawnienia w usłudze Azure Log Analytics (Azure Monitor). Gdy mają uprawnienia, mogą wykonywać zapytania dotyczące danych inspekcji przechowywanych w tabeli PowerBIActivity . Należy jednak pamiętać, że w większości przypadków przyznasz użytkownikom dostęp do wyselekcjonowanych danych w warstwie złota, a nie danych pierwotnych w warstwie brązowej.

Język KQL służy do analizowania zdarzeń dziennika aktywności przechowywanych w usłudze Azure Log Analytics. Jeśli masz środowisko SQL, znajdziesz wiele podobieństw z językiem KQL.

Istnieje kilka sposobów uzyskiwania dostępu do zdarzeń przechowywanych w usłudze Azure Log Analytics. Możesz użyć:

  • Wstępnie utworzona aplikacja szablonu Usługi Log Analytics dla modeli semantycznych usługi Power BI.
  • Łącznik programu Power BI Desktop dla usługi Azure Data Explorer (Kusto).
  • Środowisko zapytań oparte na sieci Web w usłudze Azure Data Explorer.
  • Dowolne narzędzie do zapytań, które może wysyłać zapytania KQL.

Przestroga

Należy pamiętać, że w usłudze Azure Monitor są przechowywane tylko podzestaw danych dziennika aktywności usługi Power BI. Jeśli planujesz kompleksową analizę użycia i wdrażania usługi Power BI w organizacji, zalecamy użycie innych opcji (opisanych wcześniej w tej sekcji) w celu pobrania danych działań.

Okres historii, który można pobrać, zależy od zasad przechowywania danych dla obszaru roboczego usługi Azure Log Analytics. Podczas podejmowania decyzji o sposobie przechowywania danych należy rozważyć koszt i dostęp do danych pierwotnych.

Usługi Microsoft Sentinel i Azure Monitor są dobrymi opcjami, gdy firma IT dokonała już inwestycji w usługę Microsoft Sentinel, poziom szczegółowości przechwycony spełnia Twoje potrzeby, a działania, takie jak wykrywanie zagrożeń, są priorytetem. Jednak ponieważ usługa Microsoft Sentinel nie przechwytuje wszystkich danych działań usługi Power BI, nie obsługuje kompleksowej analizy użycia i wdrażania usługi Power BI.

Zagadnienia dotyczące danych aktywności użytkownika

Poniżej przedstawiono kilka zagadnień, które pomogą Ci wybrać źródło danych aktywności użytkownika.

  • Czy będzie to proces ręcznego lub zautomatyzowanego przeprowadzania inspekcji? Opcje interfejsu użytkownika działają dobrze w przypadku ręcznych procesów inspekcji i okazjonalnych jednorazowych zapytań, szczególnie w przypadku konieczności zbadania określonego działania. Zautomatyzowany proces inspekcji, który wyodrębnia dane aktywności użytkownika zgodnie z harmonogramem, będzie również niezbędny do obsługi analizy danych historycznych.
  • Jak często są potrzebne dane aktywności użytkownika? W przypadku zautomatyzowanych procesów inspekcji zaplanuj wyodrębnianie danych, które są co najmniej jeden dzień przed bieżącą datą przy użyciu uniwersalnego czasu koordynowanego (UTC), a nie czasu lokalnego. Jeśli na przykład proces jest uruchamiany w piątek rano (czas UTC), należy wyodrębnić dane z środy. Istnieje kilka powodów, dla których należy wyodrębnić dane z jednorazowym opóźnieniem.
    • Pliki będą prostsze do pracy, gdy zawsze wyodrębniasz pełne 24 godziny naraz, co pozwala uniknąć częściowych wyników dnia.
    • Zminimalizujesz ryzyko braku niektórych zdarzeń inspekcji. Zazwyczaj zdarzenia inspekcji są dostarczane w ciągu 30 minut. Czasami niektóre zdarzenia mogą potrwać do 24 godzin, aby dotrzeć do ujednoliconego dziennika inspekcji.
  • Czy potrzebujesz więcej niż dane usługi Power BI? Rozważ najbardziej wydajny sposób uzyskiwania dostępu do potrzebnych danych.
    • Jeśli potrzebujesz tylko danych aktywności użytkownika usługi Power BI, użyj dziennika aktywności usługi Power BI.
    • Jeśli potrzebujesz dzienników inspekcji z wielu usług, użyj interfejsu API działań zarządzania usługi Office 365, aby uzyskać dostęp do ujednoliconego dziennika inspekcji.
  • Kto opracuje rozwiązanie? Zaplanuj zainwestowanie trochę czasu, aby zbudować rozwiązanie. Utworzenie skryptu gotowego do produkcji może wymagać znacznego nakładu pracy.

Lista kontrolna — podczas planowania dostępu do danych aktywności użytkownika kluczowe decyzje i akcje obejmują:

  • Wyjaśnienie zakresu potrzeb: określ, czy chcesz uzyskać dostęp tylko do rekordów inspekcji usługi Power BI, czy też inspekcji danych dla wielu usług.
  • Skontaktuj się z działem IT: dowiedz się, czy dział IT obecnie wyodrębnia dzienniki inspekcji i czy jest możliwe uzyskanie dostępu do danych pierwotnych, aby nie trzeba było tworzyć nowego rozwiązania.
  • Zdecyduj o źródle danych: określ najlepsze źródło, które ma być używane do uzyskiwania dostępu do danych aktywności użytkownika.
  • Ukończ weryfikację koncepcji: Zaplanuj ukończenie małego dowodu technicznego koncepcji( POC). Użyj go, aby zweryfikować decyzje dotyczące sposobu tworzenia ostatecznego rozwiązania.
  • Śledzenie dodatkowych potrzeb związanych z danymi: możesz skorelować dane dziennika aktywności z innymi źródłami, aby zwiększyć wartość danych. Śledź te możliwości w miarę ich powstawania, aby można je było dodać do zakresu projektu.

Uzyskiwanie dostępu do danych spisu dzierżawy

Spis dzierżawy jest nieoceniony i niezbędny, częścią dojrzałego rozwiązania do inspekcji i monitorowania. Pomaga to zrozumieć, jakie obszary robocze i zawartość (semantyczne modele, raporty i inne elementy) istnieją w usłudze Power BI, i stanowi doskonałe uzupełnienie danych aktywności użytkownika (opisane w poprzedniej sekcji). Aby uzyskać więcej informacji na temat identyfikowania potrzeb dotyczących danych, zobacz Spis dzierżawy we wcześniejszej części tego artykułu.

Działania użytkownika (opisane wcześniej) są zdarzeniami inspekcji; są one rekordem akcji, które użytkownik wykonał w określonej dacie i godzinie. Jednak spis dzierżawy jest inny. Spis dzierżawy to migawka w danym momencie w czasie. Opisuje bieżący stan wszystkich opublikowanych elementów w usługa Power BI w momencie wyodrębnienia go.

Uwaga

Dokumentacja interfejsu API REST usługi Power BI odnosi się do opublikowanych elementów jako artefaktów.

Porada

Wiele organizacji uważa, że przydatne jest wyodrębnienie spisu dzierżawy o tej samej porze każdego tygodnia.

Aby prawidłowo przeanalizować, co dzieje się w dzierżawie usługi Power BI, potrzebne są zarówno dane aktywności użytkownika, jak i spis dzierżawy. Połączenie ich pozwala zrozumieć, ile zawartości masz i gdzie się znajduje. Umożliwia również znalezienie nieużywanej lub niedoużywanej zawartości (ponieważ w dzienniku aktywności nie będzie żadnych zdarzeń). Spis dzierżawy pomaga również skompilować listę bieżących nazw dla wszystkich elementów, co jest przydatne, gdy nazwy elementów się zmieniają.

Aby uzyskać więcej informacji na temat wartości spisu dzierżaw, zobacz Spis dzierżawy we wcześniejszej części tego artykułu.

Porada

Możesz użyć polecenia Pobierz nieużywane artefakty jako interfejs API administratora , aby wyszukać elementy, które nie mają żadnej aktywności użytkownika w ciągu ostatnich 30 dni. Nie można jednak dostosować tego okresu. Na przykład może istnieć zawartość krytyczna, która jest używana tylko co kwartał. Łącząc spis dzierżawy z danymi aktywności użytkownika, możesz znaleźć nieużywane elementy w sposób, który można dostosować.

Dane spisu dzierżawy można uzyskać na dwa różne sposoby.

Technika Opis Najbardziej odpowiednie do Dobry wybór w przypadku ręcznych procesów inspekcji Dobry wybór dla zautomatyzowanych procesów inspekcji
Programowa Interfejs Get Groups as Admin API lub Get-PowerBIWorkspace polecenie cmdlet programu PowerShell może udostępnić listę obszarów roboczych dla całej dzierżawy. Opcjonalnie można uwzględnić poszczególne elementy (takie jak modele semantyczne i raporty) dla każdego obszaru roboczego. Mniejsze organizacje lub mała ilość danych Polecenie cmdlet Get Groups as Admin API (Pobierz grupy jako interfejs API administratora) lub Get-PowerBIWorkspace PowerShell jest dobrym wyborem w przypadku ręcznych procesów inspekcji. Polecenie cmdlet Get Groups as Admin API (Pobierz grupy jako interfejs API administratora) lub Get-PowerBIWorkspace PowerShell jest dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji.
Programowa Zestaw asynchronicznych interfejsów API administratora, nazywanych zbiorczo interfejsami API skanowania metadanych lub interfejsami API skanera, może zwracać listę obszarów roboczych i poszczególnych elementów. Opcjonalnie można również uwzględnić szczegółowe metadane (takie jak tabele, kolumny i wyrażenia miar). Organizacje z dużą ilością danych i/lub muszą uzyskać szczegółowe wyniki Interfejsy API skanowania metadanych są dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji.

W pozostałej części tej sekcji przedstawiono poszczególne techniki przedstawione w tabeli.

Polecenia cmdlet interfejsów API grup lub obszarów roboczych

Aby pobrać listę obszarów roboczych, możesz użyć jednego z kilku interfejsów API REST, takich jak Pobieranie grup jako interfejsu API administratora (przy użyciu wybranego narzędzia). Wyniki obejmują dodatkowe metadane, takie jak opis i informacje o tym, czy obszar roboczy jest przechowywany w pojemności Premium.

Uwaga

Interfejs API o nazwie zawiera grupę terminów jako odwołanie do obszaru roboczego. Ten termin pochodzi z oryginalnego modelu zabezpieczeń usługi Power BI, który polegał na grupach platformy Microsoft 365. Chociaż model zabezpieczeń usługi Power BI znacznie ewoluował na przestrzeni lat, istniejące nazwy interfejsów API pozostają niezmienione, aby uniknąć przerywania istniejących rozwiązań.

Interfejs Get Groups as Admin API REST zawiera przydatny $expand parametr. Ten parametr pozwala opcjonalnie rozwinąć wyniki, tak aby zawierały listę elementów opublikowanych w obszarze roboczym (takich jak modele semantyczne i raporty). Możesz również przekazać typ danych do parametru users $expand , aby uwzględnić użytkowników przypisanych do roli obszaru roboczego.

Możesz również użyć polecenia cmdlet Get-PowerBIWorkspace programu PowerShell. Pochodzi on z modułu Obszary robocze zarządzania usługi Power BI. Po ustawieniu parametru -Scope organizationfunkcja ta działa jak Get Groups as Admin interfejs API. Polecenie cmdlet akceptuje -Include również parametr (który jest odpowiednikiem parametru $expand w interfejsie API REST) w celu uwzględnienia elementów publikowanych w obszarze roboczym (takich jak modele semantyczne i raporty).

Porada

Przekazując parametry, możesz użyć polecenia cmdlet na różne sposoby. Ta sekcja koncentruje się na pobieraniu spisu dla całej dzierżawy. Aby uzyskać więcej informacji na temat używania parametru, zobacz Wybieranie interfejsu -Scope API użytkownika lub interfejsu API administratora wcześniej w tym artykule.

Aby ułatwić wybór opcji do użycia, zobacz Wybieranie interfejsów API lub poleceń cmdlet programu PowerShell wcześniej w tym artykule.

Interfejs Get Groups as Admin API REST lub Get-PowerBIWorkspace polecenie cmdlet programu PowerShell najlepiej nadaje się do ręcznych procesów inspekcji i jednorazowych badań. Większe organizacje z dużą ilością danych zwykle znajdują te opcje trudne do użycia. Interfejs API REST i polecenie cmdlet zawsze wyodrębniają pełny zestaw danych, co może zająć dużo czasu. Istnieje również prawdopodobieństwo, że większe organizacje napotkają ograniczenia dotyczące liczby żądań dozwolonych na godzinę (nazywanej ograniczaniem, co jest wykonywane w celu ochrony kondycji usługi). Interfejsy API skanowania metadanych (opisane w dalszej części) zapewniają bardziej niezawodną i skalowalną alternatywę.

Interfejsy API skanowania metadanych

Interfejsy API skanowania metadanych, często nazywane interfejsami API skanera, to zestaw interfejsów API, które zwracają listę obszarów roboczych i ich elementów usługi Power BI (semantycznych modeli, raportów i innych elementów). Koncepcyjnie udostępniają te same dane (i inne), co interfejsy API grup lub polecenie cmdlet obszaru roboczego, które opisano w poprzedniej sekcji. Jednak metoda używana do pobierania danych różni się i lepiej nadaje się do wyodrębniania spisu dzierżawy.

Uwaga

Zwróć uwagę na to, jak niektórzy użytkownicy używają interfejsów API skanera terminów lub skanowania fraz dzierżawy. Często używają tych terminów, aby oznaczać kompilowanie spisu dzierżaw, rozróżniając je od zdarzeń aktywności użytkownika. Mogą one, lub nie, dosłownie odwołują się do korzystania z interfejsów API skanowania metadanych.

Istnieją dwa podstawowe powody, dla których należy rozważyć użycie interfejsów API skanowania metadanych zamiast Get Groups as Admin interfejsu Get-PowerBIWorkspace API REST lub polecenia cmdlet (opisane wcześniej).

  • Wyodrębnianie danych przyrostowych: interfejsy API skanera wyodrębniają tylko zmienione dane od czasu ostatniego uruchomienia. Z drugiej strony interfejs Get Groups as Admin API REST i Get-PowerBIWorkspace polecenie cmdlet są operacjami synchronicznymi, które wyodrębniają pełny zestaw danych za każdym razem, gdy są uruchamiane.
  • Bardziej szczegółowy poziom szczegółowości: interfejsy API skanera mogą pobierać szczegółowe szczegóły (takie jak tabele, kolumny i wyrażenia miary), zapewniając uprawnienia przyznane przez dwa ustawienia dzierżawy dla szczegółowych metadanych. Z drugiej strony najniższy poziom szczegółowości dostępny w interfejsie Get Groups as Admin API REST i Get-PowerBIWorkspace polecenie cmdlet jest według typu elementu (na przykład listy raportów w obszarze roboczym).

Korzystanie z interfejsów API skanera wymaga większego nakładu pracy, ponieważ trzeba wywołać serię interfejsów API. Ponadto są one uruchamiane jako proces asynchroniczny . Proces asynchroniczny jest uruchamiany w tle, więc nie trzeba czekać na jego zakończenie. Może być konieczne współpraca z it lub deweloperem, gdy nadszedł czas na utworzenie skryptu gotowego do produkcji, który zostanie zaplanowany.

Poniżej przedstawiono sekwencję kroków, które należy wykonać podczas korzystania z interfejsów API skanera.

  1. Logowanie: zaloguj się do usługa Power BI przy użyciu konta administratora usługi Power BI lub jednostki usługi z uprawnieniami do uruchamiania interfejsów API administratora. Aby uzyskać więcej informacji, zobacz Określanie metody uwierzytelniania wcześniej w tym artykule.
  2. Pobierz identyfikatory obszarów roboczych: wyślij żądanie, aby pobrać listę identyfikatorów obszarów roboczych. Po pierwszym uruchomieniu nie będziesz mieć daty modyfikacji, dlatego zwróci pełną listę obszarów roboczych. Zazwyczaj należy przekazać zmodyfikowaną datę, aby pobrać tylko obszary robocze, które uległy zmianie od tego momentu w czasie. Data modyfikacji musi należeć do ostatnich 30 dni.
  3. Zainicjuj skanowanie metadanych: zainicjuj wywołanie, aby zażądać skanowania informacji o obszarze roboczym, przekazując identyfikatory obszaru roboczego pobrane w kroku 2. Należy pamiętać, że jest to interfejs API POST (zamiast interfejsu API GET , który jest częściej spotykany podczas pobierania danych inspekcji). Interfejs API POST to żądanie HTTP, które tworzy lub zapisuje dane dla określonego zasobu. To zapytanie określa poziom szczegółowości, który zostanie wyodrębniony, na przykład szczegóły źródła danych, schemat modelu semantycznego, wyrażenia modelu semantycznego lub użytkowników. Po przesłaniu identyfikator skanowania jest zwracany przez interfejs API. Zwraca również datę i godzinę skanowania, które należy zarejestrować jako datę migawki.
  4. Sprawdź stan skanowania: użyj identyfikatora skanowania uzyskanego w kroku 3, aby uzyskać stan skanowania. Może być konieczne wywołanie tego interfejsu API więcej niż raz. Gdy zwrócony stan to Powodzenie, można przejść do następnego kroku. Czas potrzebny na skanowanie zależy od ilości żądanych danych.
  5. Pobierz wyniki: użyj identyfikatora skanowania uzyskanego w kroku 3, aby uzyskać wynik skanowania i wyodrębnić dane. Ten krok należy wykonać w ciągu 24 godzin od ukończenia kroku 4. Należy pamiętać, że sygnatura czasowa migawki powinna być skorelowana z krokiem 3, a nie krokiem 5 (w przypadku znacznego opóźnienia). Dzięki temu będziesz mieć dokładną sygnaturę czasową migawki. Zapisz wyniki w preferowanej lokalizacji przechowywania danych. Zgodnie z opisem w tym artykule zalecamy przechowywanie danych pierwotnych w ich oryginalnym stanie.
  6. Przygotuj się do następnego procesu: zarejestruj sygnaturę czasową skanowania z kroku 3, aby można było go użyć w kroku 2 przy następnym uruchomieniu procesu. W ten sposób wyodrębnisz tylko dane, które uległy zmianie od tego momentu w czasie. W przyszłości wszystkie kolejne wyodrębnienia danych będą zmianami przyrostowymi, a nie pełnymi migawkami.

Lista kontrolna — podczas planowania dostępu do danych spisu dzierżawy kluczowe decyzje i akcje obejmują:

  • Potwierdź wymagania: Wyjaśnij potrzeby kompilowania spisu dzierżawy i wymagań analitycznych dotyczących danych.
  • Zdecyduj o częstotliwości wyodrębniania spisu dzierżawy: potwierdź, jak często będziesz potrzebować nowego spisu dzierżawy (na przykład co tydzień).
  • Zdecyduj, jak wyodrębnić spis dzierżawy: potwierdź, która metoda będzie używana do uzyskiwania danych spisu dzierżawy (interfejs API, polecenie cmdlet lub interfejsy API skanowania metadanych).
  • Ukończ weryfikację koncepcji: Zaplanuj ukończenie małego dowodu technicznego koncepcji( POC). Użyj go, aby zweryfikować decyzje dotyczące sposobu tworzenia ostatecznego rozwiązania.

Uzyskiwanie dostępu do danych użytkowników i grup

Oprócz informacji identyfikujących (takich jak adres e-mail), które są zawarte w danych aktywności użytkownika, warto pobrać dodatkowe informacje, takie jak lokalizacja lub szczegóły organizacji. Program Microsoft Graph umożliwia pobieranie danych dotyczących użytkowników, grup, jednostek usługi i licencji. Program Microsoft Graph obejmuje zestaw interfejsów API i bibliotek klienckich, które umożliwiają pobieranie danych inspekcji z wielu różnych usług.

Poniżej przedstawiono kilka szczegółów dotyczących obiektów firmy Microsoft Entra, do których można uzyskać dostęp.

  • Użytkownik: tożsamość, która istnieje w usłudze Microsoft Entra ID jako konto służbowe lub Microsoft. Termin użytkownik domeny jest często używany do opisywania użytkowników organizacji, podczas gdy formalnym terminem jest główna nazwa użytkownika (UPN). Nazwa UPN jest zwykle taką samą wartością jak adres e-mail użytkownika (jednak jeśli adres e-mail ulegnie zmianie, nazwa UPN nie zmienia się, ponieważ jest niezmienna). Istnieje również unikatowy identyfikator programu Microsoft Graph dla każdego użytkownika. Często konto użytkownika jest skojarzone z jedną osobą. Niektóre organizacje tworzą użytkowników, którzy są kontami usług używanymi do zautomatyzowanych działań lub zadań administracyjnych.
  • Jednostka usługi: inny typ tożsamości, który jest aprowizowany podczas tworzenia rejestracji aplikacji. Jednostka usługi jest przeznaczona dla nienadzorowanych, zautomatyzowanych działań. Aby uzyskać więcej informacji, zobacz Określanie metody uwierzytelniania wcześniej w tym artykule.
  • Grupa: kolekcja użytkowników i jednostek usługi. Istnieje kilka typów grup , których można użyć do uproszczenia zarządzania uprawnieniami. Aby uzyskać więcej informacji, zobacz Strategia używania grup.

Uwaga

W przypadku odwoływania się do użytkowników i grup ten termin obejmuje również jednostki usługi. Ten krótszy termin jest używany do zwięzłości.

Pobierane dane użytkowników i grup to migawka, która opisuje bieżący stan w danym punkcie w czasie.

Porada

Aby uzyskać więcej informacji na temat użytkowników, jednostek usługi i grup, zobacz Integracja z identyfikatorem Entra firmy Microsoft.

Atrybuty analityczne

W przypadku inspekcji na poziomie dzierżawy usługi Power BI można wyodrębnić i zapisać następujące atrybuty z programu Microsoft Graph.

  • Pełna nazwa użytkowników: wiele źródeł danych zawiera tylko adres e-mail użytkownika, który wykonał działanie lub kto jest przypisany do roli. Użyj tego atrybutu, jeśli chcesz wyświetlić pełną nazwę (nazwę wyświetlaną) w raportach analitycznych. Użycie pełnej nazwy sprawia, że raporty są bardziej przyjazne dla użytkownika.
  • Inne właściwości użytkownika: inne atrybuty opisowe dotyczące użytkowników mogą być dostępne w identyfikatorze Entra firmy Microsoft. Niektóre przykłady wbudowanych atrybutów profilu użytkownika, które mają wartość analityczną, obejmują stanowisko, dział, menedżer, region i lokalizację biura.
  • Członkowie grupy zabezpieczeń: większość źródeł danych udostępnia nazwę grupy (na przykład rekordy dziennika aktywności usługi Power BI przypisane do roli obszaru roboczego). Pobieranie członkostwa w grupie zwiększa możliwość pełnej analizy tego, co robi dany użytkownik lub do której ma dostęp.
  • Licencje użytkowników: warto analizować, które licencje użytkowników — bezpłatne, Power BI Pro lub Power BI Premium na użytkownika (PPU) — są przypisywane do użytkowników. Te dane mogą pomóc w ustaleniu, kto nie korzysta z licencji. Ułatwia również analizowanie wszystkich użytkowników (unikatowych użytkowników z licencją) i aktywnych użytkowników (z ostatnimi działaniami). Jeśli rozważasz dodawanie lub rozszerzanie licencji usługi Power BI Premium, zalecamy analizowanie danych licencji użytkownika wraz z danymi aktywności użytkownika w celu przeprowadzenia analizy kosztów.
  • Członkowie ról administratora: możesz skompilować listę administratorów usługi Power BI (w tym administratorów platformy Power Platform).

Aby zapoznać się z autorytatywnym odwołaniem do informacji o licencji usługi Power BI, które można znaleźć w danych inspekcji z programu Microsoft Graph, zobacz Nazwy produktów i identyfikatory planu usługi na potrzeby licencjonowania.

Porada

Pobieranie członków z grup może być jednym z najtrudniejszych aspektów uzyskiwania danych inspekcji. Należy przeprowadzić wyszukiwanie przechodnie, aby spłaszczyć wszystkie zagnieżdżone elementy członkowskie i zagnieżdżone grupy. Możesz wyszukać przechodnie członków grupy. Ten typ wyszukiwania jest szczególnie trudny, gdy w organizacji znajdują się tysiące grup. W takim przypadku można rozważyć lepsze alternatywy pobierania danych. Jedną z opcji jest wyodrębnienie wszystkich grup i członków grupy z programu Microsoft Graph. Jednak może to nie być praktyczne, gdy tylko niewielka liczba grup jest używana na potrzeby zabezpieczeń usługi Power BI. Inną opcją jest wstępne utworzenie listy referencyjnej grup, które są używane przez dowolny typ zabezpieczeń usługi Power BI (role obszaru roboczego, uprawnienia aplikacji, udostępnianie poszczególnych elementów, zabezpieczenia na poziomie wiersza i inne). Następnie możesz wykonać pętlę na liście referencyjnej, aby pobrać członków grupy z programu Microsoft Graph.

Oto kilka innych atrybutów, które można wyodrębnić i przechowywać.

  • Typ użytkownika: użytkownicy są członkami lub gośćmi. Najczęściej członkowie są użytkownikami wewnętrznymi, a goście są użytkownikami zewnętrznymi (B2B). Przechowywanie typu użytkownika jest przydatne, gdy trzeba analizować działania użytkowników zewnętrznych.
  • Zmiany ról: podczas przeprowadzania inspekcji zabezpieczeń warto zrozumieć, kiedy użytkownik zmienił role w organizacji (na przykład podczas przenoszenia do innego działu). W ten sposób możesz sprawdzić, czy ustawienia zabezpieczeń usługi Power BI zostały lub powinny być zaktualizowane.
  • Wyłączone użytkownicy: gdy użytkownik opuszcza organizację, zazwyczaj administrator wyłącza swoje konto. Możesz utworzyć proces sprawdzania, czy wyłączone użytkownicy są administratorami obszaru roboczego, czy semantycznymi właścicielami modeli.

Porada

Dziennik aktywności usługi Power BI zawiera zdarzenie, które rejestruje się, gdy użytkownik zarejestruje się w celu uzyskania licencji próbnej. To zdarzenie można połączyć z danymi licencji użytkownika (pochodzącymi z identyfikatora Entra firmy Microsoft), aby utworzyć pełny obraz.

Pobieranie danych użytkowników i grup

Dane dotyczące użytkowników i grup można pobierać na różne sposoby.

Technika Opis Dobry wybór w przypadku ręcznych procesów inspekcji Dobry wybór dla zautomatyzowanych procesów inspekcji
Ręcznie Eksplorator programu Graph Eksplorator programu Graph to dobry wybór w przypadku ręcznych procesów inspekcji.
Programowa Interfejsy API i zestawy SDK programu Microsoft Graph Interfejsy API i zestawy SDK programu Microsoft Graph są dobrymi wyborami dla zautomatyzowanych procesów inspekcji.
Programowa Moduł Az programu PowerShell Moduł Az programu PowerShell jest dobrym wyborem w przypadku zautomatyzowanych procesów inspekcji.

W pozostałej części tej sekcji przedstawiono poszczególne techniki przedstawione w tabeli. Inne techniki, które są przestarzałe i nie powinny być używane w przypadku nowych rozwiązań, są opisane na końcu tej sekcji.

Uwaga

Podczas odczytywania informacji w trybie online należy zachować ostrożność, ponieważ wiele nazw narzędzi jest podobnych. Niektóre narzędzia w ekosystemie firmy Microsoft zawierają termin Graph w nazwie, taki jak Azure Resource Graph, GraphQL i Microsoft Security Graph API. Te narzędzia nie są związane z programem Microsoft Graph i nie należą do zakresu tego artykułu.

Eksplorator programu Microsoft Graph

Microsoft Graph Explorer to narzędzie deweloperskie, które pozwala dowiedzieć się więcej o interfejsach API programu Microsoft Graph. Jest to prosty sposób rozpoczęcia pracy, ponieważ nie wymaga żadnych innych narzędzi ani konfiguracji na maszynie. Możesz zalogować się, aby pobrać dane z dzierżawy lub pobrać przykładowe dane z dzierżawy domyślnej.

Eksplorator programu Graph umożliwia:

  • Ręcznie wyślij żądanie do interfejsu API programu Microsoft Graph, aby sprawdzić, czy zwraca żądane informacje.
  • Zobacz, jak utworzyć adres URL, nagłówki i treść przed napisaniem skryptu.
  • Sprawdzanie danych w sposób nieformalny.
  • Określ, które uprawnienia są wymagane dla każdego interfejsu API. Możesz również wyrazić zgodę na nowe uprawnienia.
  • Uzyskaj fragmenty kodu do użycia podczas tworzenia skryptów.

Użyj tego linku , aby otworzyć Eksploratora programu Graph.

Interfejsy API i zestawy SDK programu Microsoft Graph

Użyj interfejsów API programu Microsoft Graph, aby pobrać dane użytkowników i grup. Można go również użyć do pobierania danych z usług, takich jak Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook i nie tylko.

Zestawy SDK programu Microsoft Graph działają jako otoka interfejsu API na podstawie podstawowych interfejsów API programu Microsoft Graph. Zestaw SDK to zestaw programistyczny, który łączy narzędzia i funkcje. Zestawy SDK programu Microsoft Graph udostępniają cały zestaw interfejsów API programu Microsoft Graph.

Możesz wysyłać żądania bezpośrednio do interfejsów API. Alternatywnie możesz dodać warstwę uproszczenia przy użyciu preferowanego języka i jednego z zestawów SDK. Aby uzyskać więcej informacji, zobacz Wybieranie interfejsów API lub poleceń cmdlet programu PowerShell wcześniej w tym artykule.

Zestawy SDK programu Microsoft Graph obsługują kilka języków, a także moduły programu Microsoft Graph PowerShell . Inne zestawy SDK są dostępne dla języków Python, C# i innych.

Ważne

Moduł Programu PowerShell programu Microsoft Graph zastępuje moduły programu PowerShell usługi Azure AD i moduły MSOnline (MSOL), które są przestarzałe. Nie należy tworzyć nowych rozwiązań z przestarzałymi modułami. Moduł Programu PowerShell programu Microsoft Graph ma wiele funkcji i korzyści. Aby uzyskać więcej informacji, zobacz Uaktualnianie z programu Azure AD PowerShell do programu Microsoft Graph PowerShell.

Moduły programu PowerShell programu Microsoft Graph można zainstalować z Galeria programu PowerShell. Ponieważ program Microsoft Graph współpracuje z wieloma usługami platformy Microsoft 365, istnieje wiele zainstalowanych modułów programu PowerShell.

W przypadku inspekcji na poziomie dzierżawy usługi Power BI poniżej przedstawiono najbardziej typowe moduły programu PowerShell, które należy zainstalować.

Porada

Firma Microsoft regularnie aktualizuje moduły programu PowerShell programu Microsoft Graph. Czasami moduły w wersji zapoznawczej są udostępniane w wersji wstępnej lub w punkcie końcowym beta. Możesz określić wersję, którą interesuje Cię podczas instalowania i aktualizowania modułów. Ponadto podczas przeglądania dokumentacji online należy pamiętać, że bieżący numer wersji jest automatycznie dołączany na końcu adresu URL (dlatego należy zachować ostrożność podczas zapisywania lub udostępniania adresów URL).

Moduł Az programu PowerShell

Możesz również użyć modułu Az programu PowerShell, aby pobrać dane użytkowników i grup. Koncentruje się on na zasobach platformy Azure.

Ważne

Moduł Az programu PowerShell zastępuje moduły AzureRM PowerShell, które są przestarzałe. Nie należy tworzyć nowych rozwiązań z przestarzałymi modułami.

Możesz użyć polecenia cmdlet Invoke-AzRestMethod , jeśli nie ma odpowiedniego polecenia cmdlet dla interfejsu API. Jest to elastyczne podejście, które umożliwia wysyłanie żądania do dowolnego interfejsu API programu Microsoft Graph przy użyciu modułu Az programu PowerShell.

Począwszy od modułu Az w wersji 7, polecenia cmdlet Az odwołują się teraz do interfejsu API programu Microsoft Graph. W związku z tym moduł Az działa jako otoka interfejsu API na podstawie programu Microsoft Graph. Moduły Az mają podzbiór funkcji zawartych w interfejsach API programu Microsoft Graph i modułach programu PowerShell. W przypadku nowych rozwiązań zalecamy korzystanie z zestawu Microsoft Graph PowerShell SDK.

Przestarzałe interfejsy API i moduły

Możesz znaleźć artykuły i wpisy w blogu w trybie online, które sugerują alternatywne opcje, które nie są przedstawione w tej sekcji. Zdecydowanie zalecamy, aby nie tworzyć nowych rozwiązań (i/ani migrować istniejących rozwiązań) przy użyciu dowolnego z następujących interfejsów API lub modułów.

  • Moduły programu PowerShell modułu AzureRM: przestarzałe i zostaną wycofane. Zostały one zastąpione modułem Az programu PowerShell.
  • Interfejs API programu Azure AD Graph i moduł programu PowerShell usługi Azure AD: przestarzałe i zostaną wycofane. Ta zmiana jest wynikiem migracji z usługi Azure AD Graph do programu Microsoft Graph (należy pamiętać, że program Graph pojawia się w obu nazwach, ale program Microsoft Graph jest przyszłym kierunkiem). Wszystkie przyszłe inwestycje w program PowerShell zostaną wykonane w zestawie Microsoft Graph PowerShell SDK.
  • Moduł PROGRAMU PowerShell usługi MS Online (MSOL): przestarzały i zostanie wycofany. Wszystkie przyszłe inwestycje w program PowerShell zostaną wykonane w zestawie Microsoft Graph PowerShell SDK.

Przestroga

Upewnij się, że stan dowolnego przestarzałego interfejsu API lub modułu, którego obecnie używasz. Aby uzyskać więcej informacji na temat wycofania modułu AzureRM, zobacz to ogłoszenie.

Aby uzyskać więcej informacji na temat microsoft Entra ID i MSOL, zobacz ten wpis o wycofaniu.

Jeśli masz pytania lub potrzebujesz wyjaśnień dotyczących przyszłego kierunku dostępu do danych programistycznych, skontaktuj się z zespołem ds. kont Microsoft.

Lista kontrolna — podczas planowania dostępu do danych użytkowników i grup kluczowe decyzje i akcje obejmują:

  • Potwierdź wymagania: Wyjaśnij potrzeby kompilowania danych związanych z użytkownikami, grupami i licencjami.
  • Określanie priorytetów wymagań: potwierdź, jakie są najważniejsze priorytety, aby wiedzieć, na co należy poświęcić czas.
  • Zdecyduj o częstotliwości wyodrębniania danych: określ, jak często będziesz potrzebować nowej migawki danych użytkowników i grup (takich jak co tydzień lub co miesiąc).
  • Zdecyduj, jak wyodrębnić dane za pomocą programu Microsoft Graph: określ metodę, która będzie używana do pobierania danych.
  • Ukończ weryfikację koncepcji: Zaplanuj ukończenie małego technicznego weryfikacji koncepcji w celu wyodrębnienia danych użytkowników i grup. Użyj go, aby zweryfikować decyzje dotyczące sposobu tworzenia ostatecznego rozwiązania.

Uzyskiwanie dostępu do danych z interfejsów API REST usługi Power BI

Być może jako niższy priorytet można również pobrać inne dane przy użyciu interfejsów API REST usługi Power BI.

Możesz na przykład pobrać dane dotyczące:

Podczas inspekcji zabezpieczeń warto zidentyfikować następujące elementy:

Aby uzyskać więcej informacji na temat innych typów interfejsów API, zobacz Wybieranie interfejsu API użytkownika lub interfejsu API administratora we wcześniejszej części tego artykułu.

Lista kontrolna — podczas planowania uzyskiwania dostępu do danych z interfejs API usługi Power BI kluczowe decyzje i akcje obejmują:

  • Uzyskiwanie wymagań: Kompiluj wymagania analityczne w miarę ich powstawania. Śledź je na liście prac.
  • Określanie priorytetów wymagań: ustaw priorytety dla nowych wymagań.

Faza 2. Wymagania wstępne i konfiguracja

Druga faza planowania i wdrażania rozwiązania inspekcji na poziomie dzierżawy koncentruje się na wymaganiach wstępnych i konfiguracji, które należy wykonać przed rozpoczęciem opracowywania rozwiązań.

Diagram przepływu opisujący fazę 2, która koncentruje się na wymaganiach wstępnych i konfiguracji do tworzenia rozwiązania inspekcji na poziomie dzierżawy.

Tworzenie konta magazynu

Na tym etapie zdecydowano się na lokalizację przechowywania danych pierwotnych i sposobu tworzenia wyselekcjonowanych danych. Na podstawie tych decyzji możesz teraz utworzyć konto magazynu. W zależności od procesów organizacji może ona obejmować przesłanie żądania do działu IT.

Zgodnie z wcześniejszym opisem zalecamy użycie technologii, która umożliwia zapisywanie danych pierwotnych w magazynie niezmiennym. Po zapisaniu danych nie można ich zmienić ani usunąć. Możesz mieć pewność, że nieprzetworzone dane są dostępne, ponieważ wiesz, że administrator z dostępem nie może w żaden sposób go zmienić. Jednak wyselekcjonowane dane nie muszą być przechowywane w niezmiennym magazynie. Wyselekcjonowane dane mogą ulec zmianie lub mogą być generowane ponownie.

Lista kontrolna — podczas tworzenia konta magazynu kluczowe decyzje i akcje obejmują:

  • Utwórz konto magazynu: utwórz lub prześlij żądanie utworzenia konta magazynu. Zawsze, gdy jest to możliwe, użyj niezmiennych ustawień magazynu dla danych pierwotnych.
  • Ustaw uprawnienia: określ, które uprawnienia mają być ustawione dla konta magazynu.
  • Przetestuj dostęp: wykonaj mały test, aby upewnić się, że możesz odczytywać i zapisywać dane na koncie magazynu.
  • Potwierdź obowiązki: upewnij się, że masz pewność, że będziesz w sposób ciągły zarządzać kontem magazynu.

Instalowanie oprogramowania i konfigurowanie usług

Na tym etapie podjęto decyzje dotyczące technologii, która ma być używana do uzyskiwania dostępu do danych inspekcji. Na podstawie tych decyzji możesz teraz zainstalować oprogramowanie i skonfigurować usługi.

Skonfiguruj preferowane środowisko programistyczne dla każdego administratora. Środowisko programistyczne umożliwi im pisanie i testowanie skryptów. Visual Studio Code to nowoczesne narzędzie do tworzenia skryptów, więc jest to dobra opcja. Ponadto wiele rozszerzeń jest dostępnych do pracy z programem Visual Studio Code.

Jeśli podjęto decyzję (poprzednio opisano) w celu korzystania z programu PowerShell, należy zainstalować program PowerShell Core i niezbędne moduły programu PowerShell w:

  • Maszyna każdego administratora/dewelopera, który napisze lub przetestuje skrypty inspekcji.
  • Każda maszyna wirtualna lub serwer, na których będą uruchamiane zaplanowane skrypty.
  • Każda usługa online (na przykład Azure Functions lub Azure Automation).

Jeśli wybrano korzystanie z dowolnych usług platformy Azure (takich jak Azure Functions, Azure Automation, Azure Data Factory lub Azure Synapse Analytics), należy aprowizować i konfigurować je również.

Lista kontrolna — podczas instalowania oprogramowania i konfigurowania usług kluczowe decyzje i akcje obejmują:

  • Skonfiguruj maszyny administratora/dewelopera: w razie potrzeby zainstaluj niezbędne narzędzia, które będą używane do programowania.
  • Konfigurowanie serwerów: w razie potrzeby zainstaluj niezbędne narzędzia na dowolnych serwerach lub maszynach wirtualnych, które znajdują się w architekturze.
  • Konfigurowanie usług platformy Azure: jeśli ma to zastosowanie, aprowizuj i skonfiguruj każdą usługę platformy Azure. Przypisz uprawnienia dla każdego administratora/dewelopera, który będzie wykonywać prace programistyczne.

Rejestrowanie aplikacji Firmy Microsoft Entra

Na tym etapie podjęto decyzję o uwierzytelnieniu. Zalecamy zarejestrowanie aplikacji Entra firmy Microsoft (jednostki usługi). Często nazywana rejestracją aplikacji powinna być używana w przypadku nienadzorowanych operacji, które zostaną zautomatyzowane.

Aby uzyskać więcej informacji na temat tworzenia rejestracji aplikacji w celu pobrania danych inspekcji na poziomie dzierżawy, zobacz Włączanie uwierzytelniania jednostki usługi dla interfejsów API administratora tylko do odczytu.

Lista kontrolna — podczas rejestrowania aplikacji Firmy Microsoft Entra kluczowe decyzje i akcje obejmują:

  • Sprawdź, czy istnieje rejestracja istniejącej aplikacji: sprawdź w witrynie IT, czy istniejąca rejestracja aplikacji jest dostępna na potrzeby uruchamiania interfejsów API administratora. Jeśli tak, ustal, czy należy użyć istniejącego, czy też należy utworzyć nowy.
  • Utwórz nową rejestrację aplikacji: utwórz rejestrację aplikacji, jeśli jest to konieczne. Rozważ użycie nazwy aplikacji, takiej jak PowerBI-AdminAPIs-EntraApp, która wyraźnie opisuje jej przeznaczenie.
  • Utwórz wpis tajny dla rejestracji aplikacji: po utworzeniu rejestracji aplikacji utwórz dla niego wpis tajny. Ustaw datę wygaśnięcia na podstawie częstotliwości rotacji wpisu tajnego.
  • Bezpiecznie zapisz wartości: zapisz wpis tajny, identyfikator aplikacji (identyfikator klienta) i identyfikator dzierżawy, ponieważ będą one potrzebne do uwierzytelnienia za pomocą jednostki usługi. Użyj bezpiecznej lokalizacji, takiej jak magazyn haseł organizacji. (Jeśli musisz zażądać utworzenia rejestracji aplikacji z IT, określ, że te wartości są zwracane).
  • Utwórz grupę zabezpieczeń: utwórz (lub zażądaj) grupy zabezpieczeń, która będzie używana w usłudze Power BI. Rozważ użycie nazwy grupy, takiej jak jednostki usługi administracyjnej usługi Power BI, co oznacza, że grupa będzie używana do uzyskiwania dostępu do metadanych dotyczących całej dzierżawy.
  • Dodaj jednostkę usługi jako członka grupy zabezpieczeń: użyj identyfikatora aplikacji (identyfikatora klienta), aby dodać nową (lub istniejącą) jednostkę usługi jako członka nowej grupy zabezpieczeń.
  • Zaktualizuj ustawienie dzierżawy interfejsu API administratora w usłudze Power BI: w portalu administracyjnym usługi Power BI dodaj grupę zabezpieczeń do ustawienia dzierżawy Zezwalaj jednostkom usługi na używanie interfejsów API administratora usługi Power BI tylko do odczytu.
  • Pomiń przypisywanie uprawnień na platformie Azure: nie deleguj żadnych uprawnień do rejestracji aplikacji (uzyska dostęp do danych inspekcji na poziomie dzierżawy usługi Power BI za pomocą ustawienia dzierżawy Zezwalaj jednostkom usługi Power BI na używanie ustawień dzierżawy tylko do odczytu).
  • Zdecyduj, czy rejestracja aplikacji ma uzyskiwać dostęp do szczegółowych metadanych: określ, czy chcesz wyodrębnić szczegółowe informacje o tabelach, kolumnach i wyrażeniach miar semantycznych podczas kompilowania spisu dzierżawy.
  • Zaktualizuj szczegółowe ustawienia dzierżawy metadanych w usłudze Power BI: opcjonalnie w portalu administracyjnym usługi Power BI dodaj grupę zabezpieczeń do ustawienia Rozszerz odpowiedzi interfejsu API administratora za pomocą szczegółowych ustawień dzierżawy metadanych , a także ustawienia Rozszerz odpowiedzi interfejsu API administratora przy użyciu języka DAX i wyrażeń mashupu .
  • Przetestuj jednostkę usługi: utwórz prosty skrypt, aby się zalogować przy użyciu jednostki usługi i przetestuj, czy może pobrać dane z interfejsu API administratora.
  • Utwórz proces zarządzania wpisami tajnymi rejestracji aplikacji: utwórz dokumentację i proces regularnego obracania wpisów tajnych. Określ, w jaki sposób bezpiecznie przekażesz nowy wpis tajny wszystkim administratorom i deweloperom, którzy ich potrzebują.

Ustawianie ustawień dzierżawy usługi Power BI

W portalu administracyjnym usługi Power BI istnieje kilka ustawień dzierżawy, które są istotne dla wyodrębniania danych inspekcji na poziomie dzierżawy.

Interfejsy API administratora

Istnieją trzy ustawienia dzierżawy, które są istotne dla uruchamiania interfejsów API administratora.

Ważne

Ponieważ te ustawienia zapewniają dostęp do metadanych dla całej dzierżawy (bez przypisywania bezpośrednich uprawnień usługi Power BI), należy je ściśle kontrolować.

Ustawienie Zezwalaj jednostkom usługi na używanie interfejsów API administratora usługi Power BI tylko do odczytu umożliwia ustawienie, które jednostki usługi mogą wywoływać interfejsy API administratora. To ustawienie umożliwia również usłudze Microsoft Purview skanowanie całej dzierżawy usługi Power BI w celu wypełnienia wykazu danych.

Uwaga

Nie musisz jawnie przypisywać innych administratorów usługi Power BI do ustawienia dzierżawy Zezwalaj jednostkom usługi na używanie interfejsów API administratora usługi Power BI tylko do odczytu, ponieważ mają już dostęp do metadanych dotyczących całej dzierżawy .

Ulepszone odpowiedzi interfejsu API administratora za pomocą szczegółowego ustawienia dzierżawy metadanych umożliwia ustawienie, którzy użytkownicy i jednostki usługi mogą pobierać szczegółowe metadane. Metadane są pobierane przy użyciu interfejsów API skanowania metadanych i obejmują tabele, kolumny i inne. To ustawienie umożliwia również usłudze Microsoft Purview dostęp do informacji na poziomie schematu dotyczących modeli semantycznych usługi Power BI, dzięki czemu może przechowywać je w wykazie danych.

Ustawienie dzierżawy Rozszerz odpowiedzi interfejsu API administratora za pomocą języka DAX i wyrażeń mashupu umożliwia ustawienie, którzy użytkownicy i jednostki usługi mogą pobierać szczegółowe metadane. Metadane są pobierane z interfejsów API skanowania metadanych i mogą zawierać zapytania i wyrażenia miar modelu semantycznego.

Uwaga

Ustawienie dzierżawy Zezwalaj jednostkom usługi na używanie interfejsów API administratora usługi Power BI tylko do odczytu dotyczy szczególnie uzyskiwania dostępu do interfejsów API administratorów. Jego nazwa jest bardzo podobna do ustawienia dzierżawy przeznaczonego do uzyskiwania dostępu do interfejsów API użytkownika (opisane poniżej). Aby uzyskać więcej informacji na temat różnic między interfejsami API administratora i interfejsami API użytkownika, zobacz Wybieranie interfejsu API użytkownika lub interfejsu API administratora wcześniej w tym artykule.

Interfejsy API użytkownika

Istnieje jedno ustawienie dzierżawy, które ma zastosowanie do wywoływania interfejsów API użytkownika. W takiej sytuacji uprawnienia usługi Power BI są również wymagane dla jednostki usługi (na przykład roli obszaru roboczego).

Ustawienie Zezwalaj jednostkom usługi na używanie interfejs API usługi Power BI dzierżawy umożliwia ustawienie, które jednostki usługi mają dostęp do uruchamiania interfejsów API REST (z wyłączeniem interfejsów API administratora, które są przyznawane przez inne ustawienie dzierżawy, opisane powyżej).

Istnieją inne ustawienia dzierżawy związane z interfejsami API, które umożliwiają dostęp do osadzonych interfejsów API, interfejsów API przesyłania strumieniowego, interfejsów API eksportu i interfejsu API wykonywania zapytań . Te interfejsy API są jednak poza zakresem tego artykułu.

Aby uzyskać więcej informacji na temat ustawień dzierżawy metryk użycia, zobacz Inspekcja na poziomie raportu.

Lista kontrolna — podczas konfigurowania ustawień dzierżawy usługi Power BI kluczowe decyzje i akcje obejmują:

  • Sprawdź, czy każda jednostka usługi znajduje się w odpowiedniej grupie: upewnij się, że grupa jednostek usługi administracyjnej usługi Power BI zawiera prawidłowe jednostki usługi.
  • Zaktualizuj ustawienie dzierżawy interfejsu API administratora w usłudze Power BI: dodaj grupę zabezpieczeń do ustawienia dzierżawy Zezwalaj jednostkom usługi na używanie interfejsów API administratora usługi Power BI tylko do odczytu, co umożliwia pobieranie metadanych dla całej dzierżawy przy użyciu interfejsów API administratora.
  • Zaktualizuj szczegółowe ustawienia dzierżawy metadanych w usłudze Power BI: w razie potrzeby dodaj grupę zabezpieczeń do ustawienia Rozszerz odpowiedzi interfejsu API administratora przy użyciu szczegółowych ustawień dzierżawy metadanych i rozszerz odpowiedzi interfejsu API administratora przy użyciu języka DAX i wyrażeń mashupu .
  • Upewnij się, do których interfejsów API użytkownika będzie uzyskiwany dostęp: sprawdź, czy będzie potrzebny co najmniej jeden interfejs API użytkownika (oprócz interfejsów API administratora).
  • Zaktualizuj ustawienie dzierżawy interfejsu API użytkownika w usłudze Power BI: dodaj grupę zabezpieczeń do ustawienia Zezwalaj jednostkom usługi na używanie ustawień dzierżawy interfejs API usługi Power BI s, które jest przeznaczone dla interfejsów API użytkowników.

Faza 3. Opracowywanie rozwiązań i analiza

Trzecia faza planowania i wdrażania rozwiązania do inspekcji na poziomie dzierżawy koncentruje się na tworzeniu i analizie rozwiązań. W tym momencie wystąpiły wszystkie etapy planowania i podejmowania decyzji oraz zostały spełnione wymagania wstępne i ukończono konfigurację. Teraz możesz rozpocząć tworzenie rozwiązań, aby móc wykonywać analizy i uzyskiwać szczegółowe informacje na podstawie danych inspekcji.

Diagram przepływu opisujący fazę 3, która koncentruje się na tworzeniu rozwiązań i analizie rozwiązania do inspekcji na poziomie dzierżawy.

Wyodrębnianie i przechowywanie danych pierwotnych

W tym momencie wymagania i priorytety powinny być jasne. Podjęto kluczowe decyzje techniczne dotyczące uzyskiwania dostępu do danych inspekcji i lokalizacji do przechowywania danych inspekcji. Wybrano preferowane narzędzia, a wymagania wstępne i ustawienia zostały skonfigurowane. W dwóch poprzednich fazach można ukończyć co najmniej jeden mały projekt (dowód koncepcji), aby udowodnić wykonalność. Następnym krokiem jest skonfigurowanie procesu wyodrębniania i przechowywania nieprzetworzonych danych inspekcji.

Podobnie jak w przypadku danych zwracanych przez większość interfejsów API firmy Microsoft, dane inspekcji są formatowane jako dane JSON. Dane w formacie JSON opisują się samodzielnie, ponieważ jest to tekst czytelny dla człowieka, który zawiera strukturę i dane.

Kod JSON reprezentuje obiekty danych składające się z par atrybut-wartość i tablic. Na przykład jest to przykład, "state": "Active" w którym wartość atrybutu stanu jest Aktywna. Tablica JSON zawiera uporządkowaną listę elementów rozdzielonych przecinkami, które znajdują się w nawiasach kwadratowych ([ ]). Często można znaleźć zagnieżdżone tablice w wynikach JSON. Po zapoznaniu się ze strukturą hierarchiczną wyniku JSON łatwo jest zrozumieć strukturę danych, na przykład listę (tablicę) modeli semantycznych w obszarze roboczym.

Poniżej przedstawiono niektóre zagadnienia dotyczące wyodrębniania i przechowywania danych pierwotnych pobranych z interfejsów API.

  • Jaka konwencja nazewnictwa zostanie użyta? W przypadku systemu opartego na plikach konwencja nazewnictwa jest niezbędna dla plików, folderów i stref typu data lake. W przypadku bazy danych konwencja nazewnictwa jest niezbędna dla tabel i kolumn.
  • Jaki format będzie używany do przechowywania danych pierwotnych? Ponieważ usługa Power BI nadal wprowadza nowe funkcje, nowe działania będą wyświetlane, które nie istnieją już dzisiaj. Z tego powodu zalecamy wyodrębnianie i zachowywanie oryginalnych wyników JSON. Nie analizuj, filtruj ani nie formatuj danych podczas wyodrębniania. Dzięki temu można użyć oryginalnych danych pierwotnych do ponownego wygenerowania wyselekcjonowanych danych inspekcji.
  • Jaka lokalizacja magazynu będzie używana? Magazyn typu data lake lub blob jest często używany do przechowywania danych pierwotnych. Aby uzyskać więcej informacji, zobacz Określanie miejsca przechowywania danych inspekcji wcześniej w tym artykule.
  • Ile historii będziesz przechowywać? Wyeksportuj dane inspekcji do lokalizacji, w której można przechowywać historię. Zaplanuj zebranie co najmniej dwóch lat historii. Dzięki temu można analizować trendy i zmiany poza domyślnym 30-dniowym okresem przechowywania. Możesz zdecydować się na przechowywanie danych na czas nieokreślony lub zdecydować się na krótszy okres, w zależności od zasad przechowywania danych w organizacji.
  • Jak będzie śledzić czas ostatniego uruchomienia procesu? Skonfiguruj plik konfiguracji lub odpowiednik, aby zarejestrować sygnatury czasowe po rozpoczęciu i zakończeniu procesu. Przy następnym uruchomieniu procesu można pobrać te sygnatury czasowe. Szczególnie ważne jest przechowywanie sygnatur czasowych podczas wyodrębniania danych przy użyciu interfejsów API skanowania metadanych.
  • Jak będziesz obsługiwać ograniczanie przepustowości? Niektóre interfejsy API REST usługi Power BI i interfejs API programu Microsoft Graph implementują ograniczanie przepustowości. Jeśli żądanie interfejsu API zostanie ograniczone, zostanie wyświetlony błąd 429 (zbyt wiele żądań). Ograniczanie przepustowości może być typowym problemem dla większych organizacji, które muszą pobrać dużą ilość danych. Sposób unikania nieudanych prób z powodu ograniczania przepustowości zależy od technologii używanej do uzyskiwania dostępu do danych i ich wyodrębniania. Jedną z opcji jest opracowanie logiki w skryptach, która odpowiada na błąd 429 "Zbyt wiele żądań", ponawiając próbę po upływie okresu oczekiwania.
  • Czy dane inspekcji są potrzebne do zapewnienia zgodności? Wiele organizacji używa nieprzetworzonych rekordów dziennika inspekcji w celu przeprowadzania inspekcji zgodności lub reagowania na badania zabezpieczeń. W takich przypadkach zdecydowanie zalecamy przechowywanie danych pierwotnych w magazynie niezmiennym. Dzięki temu po zapisaniu danych nie można ich zmienić ani usunąć przez administratora ani innego użytkownika.
  • Jakie warstwy magazynu są niezbędne do obsługi wymagań? Najlepsze miejsca do przechowywania danych pierwotnych to magazyn typu data lake (na przykład Azure Data Lake Storage Gen2) lub magazyn obiektów (na przykład Azure Blob Storage). System plików może być również używany, jeśli usługi w chmurze nie są opcją.

Lista kontrolna — podczas wyodrębniania i przechowywania danych pierwotnych kluczowe decyzje i akcje obejmują:

  • Potwierdź wymagania i priorytety: Wyjaśnij wymagania i priorytety dla danych, które wyodrębnisz jako pierwsze.
  • Potwierdź źródło danych do wyodrębnienia: sprawdź źródło dla każdego potrzebnego typu danych.
  • Skonfiguruj proces wyodrębniania danych i ładowania ich do nieprzetworzonej strefy danych: Utwórz proces początkowy w celu wyodrębnienia i załadowania danych pierwotnych w ich pierwotnym stanie bez żadnych przekształceń. Przetestuj, czy proces działa zgodnie z oczekiwaniami.
  • Utwórz harmonogram uruchamiania procesów: skonfiguruj cykliczny harmonogram uruchamiania procesów wyodrębniania, ładowania i przekształcania.
  • Sprawdź, czy poświadczenia są zarządzane bezpiecznie: upewnij się, że hasła, wpisy tajne i klucze są przechowywane i przekazywane w bezpieczny sposób.
  • Upewnij się, że zabezpieczenia są poprawnie skonfigurowane: sprawdź, czy uprawnienia dostępu są poprawnie skonfigurowane dla danych pierwotnych. Upewnij się, że administratorzy i audytorzy mogą uzyskiwać dostęp do danych pierwotnych.

Aby uzyskać więcej informacji na temat zwiększania się rozwiązania do inspekcji i monitorowania w miarę upływu czasu, zobacz Operacjonalizacja i ulepszanie w dalszej części tego artykułu.

Tworzenie wyselekcjonowanych danych

W tym momencie dane pierwotne są wyodrębniane i przechowywane. Następnym krokiem jest utworzenie oddzielnej warstwy danych złota dla wyselekcjonowanych danych. Jego celem jest przekształcenie i zapisanie plików danych w schemacie gwiazdy. Schemat gwiazdy składa się z tabel wymiarów i tabel faktów oraz jest celowo zoptymalizowany pod kątem analizy i raportowania. Pliki w wyselekcjonowanej warstwie danych stają się źródłem modelu danych usługi Power BI (opisanym w następnym temacie).

Porada

Jeśli spodziewasz się, że istnieje więcej niż jeden model danych, inwestowanie w scentralizowaną wyselekcjonowaną warstwę danych jest szczególnie przydatne.

Lista kontrolna — podczas tworzenia wyselekcjonowanych warstw danych kluczowe decyzje i akcje obejmują:

  • Potwierdź wymagania i priorytety: jeśli zamierzasz użyć pośredniej warstwy srebra dla przekształconych danych, wyjaśnij wymagania i cele dotyczące tego, co należy osiągnąć.
  • Skonfiguruj proces przekształcania danych pierwotnych i ładowania ich do wyselekcjonowanych stref danych: utwórz proces przekształcania i ładowania danych do schematu gwiazdy. Przetestuj, czy proces działa zgodnie z oczekiwaniami.
  • Utwórz harmonogram uruchamiania procesów: skonfiguruj cykliczny harmonogram wypełniania wyselekcjonowanych warstw danych.
  • Upewnij się, że zabezpieczenia są poprawnie skonfigurowane: sprawdź, czy uprawnienia dostępu są poprawnie skonfigurowane dla wyselekcjonowanych danych. Upewnij się, że deweloperzy modelu danych mogą uzyskać dostęp do wyselekcjonowanych danych.

Tworzenie modelu danych

Temat dotyczy konfigurowania modelu danych analitycznych. Model danych to zasób danych umożliwiający wykonywanie zapytań zoptymalizowany pod kątem analizy. Czasami jest określany jako model semantyczny lub po prostu model. W przypadku rozwiązania do inspekcji i monitorowania model danych prawdopodobnie zostanie zaimplementowany jako semantyczny model usługi Power BI.

W kontekście inspekcji i monitorowania dane modelu danych są źródła danych z wyselekcjonowanych (złotych) warstwy danych. Jeśli zdecydujesz się nie tworzyć wyselekcjonowanych warstw danych, model danych źródła danych bezpośrednio z danych pierwotnych.

Zalecamy, aby model danych usługi Power BI implementuje projekt schematu gwiazdy. Gdy dane źródłowe są wyselekcjonowaniem warstwy danych, schemat gwiazdy modelu danych usługi Power BI powinien odzwierciedlać schemat wyselekcjonowanych warstw danych gwiazdy warstwy danych.

Porada

Aby zapoznać się z omówieniem projektu schematu gwiazdy, zobacz Omówienie schematu gwiazdy i znaczenia usługi Power BI.

Podobnie jak w przypadku dowolnego projektu usługi Power BI tworzenie modelu danych jest procesem iteracyjnym. W razie potrzeby można dodawać nowe miary. Możesz również dodać nowe tabele i kolumny, gdy nowe zdarzenia inspekcji staną się dostępne. W czasie możesz nawet zintegrować nowe źródła danych.

Poniżej przedstawiono kilka przydatnych tabel wymiarów, które można uwzględnić w modelu danych.

  • Data: zestaw atrybutów daty umożliwiających analizę (fragmentowanie i tworzenie fragmentów) danych według dnia, tygodnia, miesiąca, kwartału, roku i innych odpowiednich okresów czasowych.
  • Godzina: Jeśli chcesz przeanalizować według godziny dnia i masz bardzo dużą ilość danych inspekcji, rozważ przechowywanie części czasu oddzielnie od daty. Takie podejście może pomóc zwiększyć wydajność zapytań.
  • Użytkownicy: atrybuty opisujące użytkowników (takich jak dział i region geograficzny), które mogą filtrować wiele tematów danych inspekcji. Celem jest usunięcie wszystkich szczegółów użytkownika z tabel faktów i zapisanie ich w tej tabeli wymiarów, aby umożliwić filtrowanie wielu tabel faktów. W tej tabeli można również przechowywać jednostki usługi.
  • Zdarzenia działania: atrybuty, które grupuje i opisują zdarzenia działania (operacje). Aby ulepszyć raportowanie, możesz utworzyć słownik danych opisujący każde zdarzenie działania. Można również utworzyć hierarchię, która grupuje i klasyfikuje podobne zdarzenia aktywności. Możesz na przykład zgrupować wszystkie zdarzenia tworzenia elementów, usunąć zdarzenia itd.
  • Obszary robocze: lista obszarów roboczych we właściwościach dzierżawy i obszaru roboczego, takich jak typ (osobisty lub standardowy) i opis. Niektóre organizacje rejestrują więcej szczegółów na temat obszarów roboczych (prawdopodobnie przy użyciu listy programu SharePoint). Te szczegóły można zintegrować z tą tabelą wymiarów. Należy zdecydować, czy ta tabela wymiarów przechowuje tylko bieżący stan obszaru roboczego, czy przechowuje wersjonowane dane odzwierciedlające znaczące zmiany obszaru roboczego w czasie. Na przykład gdy nazwa obszaru roboczego zmieni się, czy w raportach historycznych jest wyświetlana bieżąca nazwa obszaru roboczego, czy nazwa obszaru roboczego, która była bieżąca w tym czasie? Aby uzyskać więcej informacji na temat przechowywania wersji, zobacz Slowly changing dimensions (Powolne zmienianie wymiarów).
  • Typy elementów: lista typów elementów usługi Power BI (semantycznych modeli, raportów i innych).
  • Pojemności: lista pojemności Premium w dzierżawie.
  • Bramy: lista bram danych w dzierżawie.
  • Źródła danych: lista źródeł danych używanych przez dowolny model semantyczny, przepływ danych lub schemat danych.

Poniżej przedstawiono kilka przydatnych tabel faktów (podmiotów), które można uwzględnić w modelu danych.

  • Działania użytkownika: dane faktów, które pochodzą z oryginalnych danych JSON. Wszystkie atrybuty, które nie mają wartości analitycznej, są usuwane. Wszystkie atrybuty należące do tabel wymiarów (powyżej) również zostaną usunięte.
  • Spis dzierżawy: migawka punktu w czasie wszystkich elementów opublikowanych w dzierżawie. Aby uzyskać więcej informacji, zobacz Spis dzierżawy we wcześniejszej części tego artykułu.
  • Modele semantyczne: obejmuje aktywność użytkownika obejmującą modele semantyczne (takie jak zmiany modelu semantycznego) lub powiązane źródła danych.
  • Odświeżanie modelu semantycznego: przechowuje operacje odświeżania danych, w tym szczegółowe informacje o typie (zaplanowanym lub na żądanie), czasie trwania, stanie i tym, który użytkownik zainicjował operację.
  • Role obszaru roboczego: migawka ról obszaru roboczego w punkcie w czasie.
  • Licencje użytkowników: migawka licencji użytkownika do punktu w czasie. Chociaż możesz być kuszony do przechowywania licencji użytkownika w tabeli wymiarów Użytkownicy , takie podejście nie będzie obsługiwać analizy zmian licencji i trendów w czasie.
  • Członkostwa w grupach użytkowników: migawka użytkowników (i jednostek usługi) przypisanych do grupy zabezpieczeń w punkcie w czasie.
  • Działania społeczności: obejmuje fakty związane ze społecznością, takie jak wydarzenia szkoleniowe. Na przykład możesz analizować działania użytkowników usługi Power BI w porównaniu z obecnością na szkoleniach. Te dane mogą pomóc Centrum Doskonałości zidentyfikować potencjalnych nowych mistrzów.

Tabele faktów nie powinny zawierać kolumn, które będą filtrować twórcy raportów. Zamiast tego te kolumny należą do powiązanych tabel wymiarów. Nie tylko ten projekt jest bardziej wydajny w przypadku zapytań, ale także promuje ponowne użycie tabel wymiarów przez wiele faktów (nazywanych przechodzeniem do szczegółów). Ten ostatni punkt jest ważny, aby utworzyć przydatny i przyjazny dla użytkownika model danych, który jest rozszerzalny podczas dodawania nowych tabel faktów (tematów).

Na przykład tabela wymiarów Użytkownicy będzie powiązana z każdą tabelą faktów. Powinna być powiązana z tabelą faktów Aktywności użytkownika (która wykonała działanie), tabelą faktów spisu dzierżawy (która utworzyła opublikowany element) i wszystkimi innymi tabelami faktów. Gdy raport filtruje według użytkownika w tabeli wymiarów Użytkownicy , wizualizacje w tym raporcie mogą wyświetlać fakty dla tego użytkownika z dowolnej powiązanej tabeli faktów.

Podczas projektowania modelu upewnij się, że atrybut jest widoczny raz i tylko raz w modelu. Na przykład adres e-mail użytkownika powinien być widoczny tylko w tabeli wymiarów Użytkownicy . Będzie również istnieć w innych tabelach faktów (jako klucz wymiaru do obsługi relacji modelu). Należy jednak ukryć ją w każdej tabeli faktów.

Zalecamy utworzenie modelu danych niezależnie od raportów. Oddzielenie modelu semantycznego i jego raportów powoduje scentralizowany model semantyczny, który może obsługiwać wiele raportów. Aby uzyskać więcej informacji na temat korzystania z udostępnionego modelu semantycznego, zobacz scenariusz użycia samoobsługowej analizy biznesowej zarządzanych.

Rozważ skonfigurowanie zabezpieczeń na poziomie wiersza, aby inni użytkownicy — poza Centrum doskonałości, audytorzy i administratorzy — mogli analizować i zgłaszać dane inspekcji. Na przykład można użyć reguł zabezpieczeń na poziomie wiersza, aby umożliwić twórcom zawartości i użytkownikom raportowanie własnych działań użytkownika lub wysiłków programistycznych.

Lista kontrolna — podczas tworzenia modelu danych kluczowe decyzje i akcje obejmują:

  • Planowanie i tworzenie modelu danych: Projektowanie modelu danych jako schematu gwiazdy. Weryfikowanie relacji działa zgodnie z oczekiwaniami. Podczas opracowywania modelu iteracyjne tworzenie miar i dodawanie dodatkowych danych na podstawie wymagań analitycznych. Uwzględnij przyszłe ulepszenia listy prac, jeśli to konieczne.
  • Konfigurowanie zabezpieczeń na poziomie wiersza: jeśli zamierzasz udostępnić model danych innym użytkownikom ogólnym, skonfiguruj zabezpieczenia na poziomie wiersza, aby ograniczyć dostęp do danych. Sprawdź, czy role zabezpieczeń na poziomie wiersza zwracają poprawne dane.

Ulepszanie modelu danych

Aby skutecznie analizować użycie zawartości i działania użytkowników, zalecamy wzbogacanie modelu danych. Ulepszenia modelu danych można wykonywać stopniowo i iteracyjnie w miarę odnajdywania możliwości i nowych wymagań.

Tworzenie klasyfikacji

Jednym ze sposobów zwiększenia modelu i zwiększenia wartości danych jest dodanie klasyfikacji do modelu danych. Upewnij się, że te klasyfikacje są używane spójnie przez raporty.

Możesz sklasyfikować użytkowników na podstawie ich poziomu użycia lub sklasyfikować zawartość na podstawie poziomu użycia.

Klasyfikacja użycia użytkowników

Rozważ następujące klasyfikacje dotyczące użycia użytkownika.

  • Częsty użytkownik: aktywność zarejestrowana w ostatnim tygodniu, a w dziewięciu z ostatnich 12 miesięcy.
  • Aktywny użytkownik: aktywność zarejestrowana w ubiegłym miesiącu.
  • Od czasu do czasu użytkownik: aktywność zarejestrowana w ciągu ostatnich dziewięciu miesięcy, ale bez aktywności w ciągu ostatniego miesiąca.
  • Nieaktywny użytkownik: brak aktywności zarejestrowanej w ciągu ostatnich dziewięciu miesięcy.

Porada

Warto wiedzieć, kim są od czasu do czasu lub nieaktywni użytkownicy, zwłaszcza gdy mają licencje Pro lub PPU (które wiążą się z kosztami). Warto również wiedzieć, kim są twoi częsti i najbardziej aktywni użytkownicy. Rozważ zaproszenie ich do dołączenia do godzin pracy lub uczęszczania na szkolenia. Twoi najbardziej aktywni twórcy zawartości mogą być kandydatami do dołączenia do sieci mistrzów.

Klasyfikacja użycia zawartości

Rozważ następujące klasyfikacje dotyczące użycia zawartości.

  • Często używana zawartość: aktywność zarejestrowana w ciągu ostatniego tygodnia i w dziewięciu z ostatnich 12 miesięcy.
  • Aktywnie używana zawartość: aktywność zarejestrowana w ubiegłym miesiącu.
  • Czasami używana zawartość: aktywność zarejestrowana w ciągu ostatnich dziewięciu miesięcy, ale bez aktywności w ciągu ostatniego miesiąca.
  • Nieużywane treści: brak aktywności zarejestrowanej w ciągu ostatnich dziewięciu miesięcy.
Klasyfikacja typów użytkowników

Rozważ następujące klasyfikacje dla typu użytkownika.

  • Twórca zawartości: działanie zarejestrowane w ciągu ostatnich sześciu miesięcy, które utworzyło, opublikowano lub edytowaną zawartość.
  • Przeglądarka zawartości: działanie zarejestrowane w ciągu ostatnich sześciu miesięcy, które wyświetlało zawartość, ale bez żadnych działań tworzenia zawartości.

Należy zdecydować, czy klasyfikacje użycia dla użytkowników lub zawartości powinny być oparte tylko na tym, jak ostatnio wystąpiło działanie. Warto również rozważyć faktoring w średnim lub trendowym użyciu w czasie.

Rozważ kilka przykładów, które pokazują, jak prosta logika klasyfikacji może błędnie przedstawiać rzeczywistość.

  • Menedżer wyświetlił jeden raport w tym tygodniu. Jednak przed tym tygodniem menedżer nie widział żadnych raportów w ciągu ostatnich sześciu miesięcy. Nie należy traktować tego menedżera jako częstego użytkownika w oparciu o ostatnie użycie.
  • Twórca raportu publikuje nowy raport co tydzień. Podczas analizowania użycia przez częstych użytkowników regularne działanie twórcy raportu wydaje się być pozytywne. Jednak po dalszym zbadaniu można stwierdzić, że ten użytkownik ponownie publikuje nowy raport (z nową nazwą raportu) za każdym razem, gdy edytuje raport. Byłoby przydatne, aby twórca raportu miał więcej szkoleń.
  • Kierownictwo przegląda raport sporadycznie i dlatego ich klasyfikacja użycia często się zmienia. Może być konieczne analizowanie niektórych typów użytkowników, takich jak kierownictwo, w inny sposób.
  • Wewnętrzny audytor wyświetla krytyczne raporty raz w roku. Audytor wewnętrzny może wydawać się nieaktywny ze względu na rzadko występujące użycie. Ktoś może wykonać kroki w celu usunięcia licencji Pro lub PPU. Lub ktoś może uwierzyć, że raport powinien zostać wycofany, ponieważ jest używany rzadko.

Porada

Średnią i trendy można obliczyć przy użyciu funkcji analizy czasowej języka DAX. Aby dowiedzieć się, jak używać tych funkcji, zapoznaj się z modułem szkoleniowym Korzystanie z funkcji analizy czasowej języka DAX w modelach programu Power BI Desktop.

Lista kontrolna — podczas tworzenia klasyfikacji danych użycia kluczowe decyzje i akcje obejmują:

  • Uzyskaj konsensus w sprawie definicji klasyfikacji: Omówienie definicji klasyfikacji z odpowiednimi uczestnikami projektu. Upewnij się, że podczas podejmowania decyzji istnieje umowa.
  • Tworzenie dokumentacji: upewnij się, że definicje klasyfikacji są zawarte w dokumentacji dla twórców zawartości i użytkowników.
  • Tworzenie pętli opinii: upewnij się, że użytkownicy mogą zadawać pytania lub zaproponować zmiany definicji klasyfikacji.

Tworzenie raportów analitycznych

W tym momencie dane inspekcji zostały wyodrębnione i przechowywane, a model danych został opublikowany. Następnym krokiem jest utworzenie raportów analitycznych.

Skoncentruj się na kluczowych informacjach, które są najbardziej istotne dla poszczególnych odbiorców. Może istnieć kilka odbiorców raportów inspekcji. Każdy odbiorca będzie zainteresowany różnymi informacjami i w różnych celach. Grupy odbiorców, które mogą być używane w raportach, obejmują:

  • Główny sponsor
  • Centrum doskonałości
  • Administratorzy usługi Power BI
  • Administratorzy obszarów roboczych
  • Administratorzy pojemności Premium
  • Administratorzy bramy
  • Deweloperzy i twórcy zawartości usługi Power BI
  • Audytorzy

Poniżej przedstawiono niektóre z najbardziej typowych wymagań analitycznych, od których warto zacząć od utworzenia raportów inspekcji.

  • Najważniejsze widoki zawartości: Sponsor wykonawczy i zespoły kierownicze mogą być głównie zainteresowane podsumowaniem informacji i trendów w czasie. Administratorzy obszaru roboczego, deweloperzy i twórcy zawartości będą bardziej zainteresowani szczegółami.
  • Najważniejsze działania użytkowników: Centrum doskonałości będzie interesujące, kto korzysta z usługi Power BI, jak i kiedy. Administratorzy pojemności Premium będą zainteresowani tym, kto korzysta z pojemności, aby zapewnić jej kondycję i stabilność.
  • Spis dzierżaw: Administratorzy usługi Power BI, administratorzy obszarów roboczych i audytorzy będą zainteresowani zrozumieniem, jaka zawartość istnieje, gdzie, pochodzenie i jej ustawienia zabezpieczeń.

Ta lista nie jest all-inclusive. Ma to na celu przedstawienie pomysłów dotyczących tworzenia raportów analitycznych przeznaczonych dla określonych potrzeb. Aby uzyskać więcej zagadnień, zobacz Wymagania dotyczące danych we wcześniejszej sekcji tego artykułu oraz Omówienie inspekcji i monitorowania. Te zasoby obejmują wiele pomysłów na korzystanie z danych inspekcji oraz typy informacji, które można przedstawić w raportach.

Porada

Chociaż jest kuszące prezentowanie wielu danych, obejmują tylko informacje, nad którymi chcesz działać. Upewnij się, że każda strona raportu ma jasny cel, jakie działania należy podjąć i przez kogo.

Aby dowiedzieć się, jak tworzyć raporty analityczne, zapoznaj się ze ścieżką szkoleniową Projektowanie efektywnych raportów w usłudze Power BI .

Lista kontrolna — podczas planowania raportów inspekcji analitycznych kluczowe decyzje i akcje obejmują:

  • Przejrzyj wymagania: określanie priorytetów tworzenia raportów na podstawie znanych potrzeb i konkretnych pytań, na które należy odpowiedzieć.
  • Potwierdź odbiorców: wyjaśnij, kto będzie używać raportów inspekcji i jakie będą ich przeznaczenie.
  • Tworzenie i wdrażanie raportów: tworzenie pierwszego zestawu podstawowych raportów. Rozszerzanie i zwiększanie ich stopniowo w miarę upływu czasu.
  • Dystrybuowanie raportów w aplikacji: rozważ utworzenie aplikacji zawierającej wszystkie raporty inspekcji i monitorowania.
  • Sprawdź, kto ma dostęp do raportów: Upewnij się, że raporty (lub aplikacja) są udostępniane prawidłowym zestawom użytkowników.
  • Tworzenie pętli opinii: upewnij się, że użytkownicy raportu mogą przekazywać opinie lub sugestie lub zgłaszać problemy.

Podejmowanie akcji na podstawie danych

Inspekcja danych jest cenna, ponieważ pomaga zrozumieć, co dzieje się w dzierżawie usługi Power BI. Chociaż może się wydawać oczywiste, jawne działanie na temat tego, czego uczysz się na podstawie danych inspekcji, można łatwo pominąć. Z tego powodu zalecamy przypisanie osoby odpowiedzialnej za śledzenie mierzalnych ulepszeń, a nie tylko przeglądanie raportów inspekcji. Dzięki temu możesz stopniowo, wymiernie rozwijać wdrożenie i poziom dojrzałości w usłudze Power BI.

Możesz wykonywać wiele różnych akcji na podstawie celów i tego, czego uczysz się na podstawie danych inspekcji. Pozostała część tej sekcji zawiera kilka pomysłów.

Użycie zawartości

Poniżej przedstawiono kilka akcji, które można wykonać w oparciu o sposób użycia zawartości.

  • Zawartość jest często używana (codziennie lub co tydzień): sprawdź, czy każda zawartość krytyczna jest certyfikowana. Upewnij się, że własność jest jasna, a rozwiązanie jest odpowiednio obsługiwane.
  • Duża liczba widoków obszaru roboczego: gdy wystąpi duża liczba widoków obszaru roboczego, sprawdź, dlaczego aplikacje usługi Power BI nie są używane.
  • Zawartość jest rzadko używana: skontaktuj się z użytkownikami docelowymi, aby określić, czy rozwiązanie spełnia ich potrzeby, czy też ich wymagania uległy zmianie.
  • Działanie odświeżania występuje częściej niż w widokach: Skontaktuj się z właścicielem zawartości, aby dowiedzieć się, dlaczego model semantyczny jest regularnie odświeżany bez ostatniego użycia modelu semantycznego lub powiązanych raportów.

Działania użytkownika

Oto kilka akcji, które można wykonać na podstawie działań użytkownika.

  • Pierwsza akcja publikowania przez nowego użytkownika: określ, kiedy typ użytkownika zmienia się od użytkownika do twórcy, co można zidentyfikować podczas publikowania zawartości po raz pierwszy. Jest to świetna okazja, aby wysłać do nich standardową wiadomość e-mail zawierającą wskazówki i linki do przydatnych zasobów.
  • Zaangażowanie z najczęstszymi twórcami zawartości: zaproś najbardziej aktywnych twórców do dołączenia do sieci mistrzów lub zaangażowania się w twoją społeczność praktyk.
  • Zarządzanie licencjami: sprawdź, czy nieaktywni twórcy nadal potrzebują licencji Pro lub PPU.
  • Aktywacja wersji próbnej użytkownika: aktywacja licencji próbnej może monitować o przypisanie stałej licencji do użytkownika przed zakończeniem okresu próbnego.

Możliwości szkolenia użytkowników

Poniżej przedstawiono niektóre możliwości szkolenia użytkowników, które można zidentyfikować na podstawie danych inspekcji.

  • Duża liczba modeli semantycznych publikowanych przez tego samego twórcę zawartości: Naucz użytkowników o udostępnionych modelach semantycznych i dlaczego ważne jest unikanie tworzenia zduplikowanych modeli semantycznych.
  • Nadmierne udostępnianie z obszaru roboczego osobistego: skontaktuj się z użytkownikiem, który wykonuje wiele czynności udostępnianych w swoim osobistym obszarze roboczym. Naucz ich o standardowych obszarach roboczych.
  • Znaczące widoki raportów z osobistego obszaru roboczego: skontaktuj się z użytkownikiem, który jest właścicielem zawartości z dużą liczbą widoków raportu. Naucz ich, jak standardowe obszary robocze są lepsze niż osobiste obszary robocze.

Porada

Możesz również ulepszyć zawartość szkoleniową lub dokumentację, przeglądając pytania zadawane przez wewnętrzną społeczność usługi Power BI i problemy przesłane do działu pomocy technicznej.

Zabezpieczenia

Poniżej przedstawiono niektóre sytuacje zabezpieczeń, które warto aktywnie monitorować.

Aby uzyskać więcej informacji, zobacz artykuły dotyczące planowania zabezpieczeń.

Ograniczanie ładu i ryzyka

Poniżej przedstawiono niektóre sytuacje, które mogą wystąpić. Rozważ jawne wyszukanie tych typów sytuacji w raportach inspekcji, aby móc działać szybko.

  • Duża liczba wyświetleń raportów (i podstawowych modeli semantycznych), które nie są zatwierdzone.
  • Znaczące użycie nieznanych lub niezatwierdzonych źródeł danych.
  • Lokalizacje plików, które nie są zgodne z wytycznymi dotyczącymi ładu dotyczącymi lokalizacji plików źródłowych.
  • Nazwy obszarów roboczych nie są zgodne z wymaganiami dotyczącymi ładu.
  • Etykiety poufności są używane do ochrony informacji.
  • Spójne niepowodzenia odświeżania danych.
  • Znaczące i cykliczne korzystanie z drukowania.
  • Nieoczekiwane lub nadmierne użycie subskrypcji.
  • Nieoczekiwane użycie bram osobistych.

Konkretne działania, które należy wykonać w każdej sytuacji, będą zależeć od zasad ładu. Aby uzyskać więcej informacji, zobacz Ład w harmonogramie wdrażania sieci szkieletowej.

Lista kontrolna — podczas planowania potencjalnych akcji na podstawie danych inspekcji kluczowe decyzje i akcje obejmują:

  • Wyjaśnienie oczekiwań: Tworzenie raportów inspekcji z wyraźnym zestawem oczekiwań dotyczących oczekiwanych działań.
  • Wyjaśnij, kto będzie odpowiedzialny za działania: Upewnij się, że przypisano role i obowiązki.
  • Tworzenie automatyzacji: jeśli to możliwe, zautomatyzuj znane akcje, które są powtarzalne.
  • Użyj systemu śledzenia: użyj systemu, aby śledzić zaobserwowaną sytuację, w tym kontakt, następną planowaną akcję, osoby odpowiedzialne, rozwiązanie i stan.

Faza 4. Utrzymywanie, ulepszanie i monitorowanie

Czwarta faza planowania i wdrażania rozwiązania do inspekcji na poziomie dzierżawy koncentruje się na konserwacji, ulepszeniach i monitorowaniu. Na tym etapie rozwiązanie do inspekcji jest używane w środowisku produkcyjnym. Teraz zajmujesz się głównie konserwowaniem, ulepszaniem i monitorowaniem rozwiązania.

Diagram przepływu opisujący fazę 4, która koncentruje się na utrzymywaniu, ulepszaniu i monitorowaniu rozwiązania do inspekcji na poziomie dzierżawy.

Operacjonalizacja i ulepszanie

Procesy inspekcji są zwykle uważane za uruchomione w środowisku produkcyjnym po zakończeniu początkowego programowania i testowania i zautomatyzowaniu procesu. Zautomatyzowane procesy inspekcji działające w środowisku produkcyjnym mają większe oczekiwania (niż procesy ręczne) dla jakości, niezawodności, stabilności i obsługi.

Proces inspekcji na poziomie produkcyjnym został zoperacjonalizowany. Rozwiązanie zoperacjonalizowane często zawiera wiele z następujących cech.

  • Bezpieczne: poświadczenia są przechowywane i zarządzane bezpiecznie. Skrypty nie zawierają haseł ani kluczy w postaci zwykłego tekstu.
  • Planowanie: istnieje niezawodny system planowania.
  • Zarządzanie zmianami: korzystanie z praktyk zarządzania zmianami i wielu środowisk służy do zapewnienia ochrony środowiska produkcyjnego. Możesz również pracować ze środowiskami projektowymi i testowymi lub tylko środowiskiem projektowym.
  • Pomoc techniczna: zespół, który obsługuje rozwiązanie, jest jasno zdefiniowany. Członkowie zespołu zostali przeszkoleni i rozumieją oczekiwania operacyjne. Elementy członkowskie kopii zapasowych zostały zidentyfikowane, a trenowanie krzyżowe odbywa się, gdy jest to konieczne.
  • Alerty: gdy coś pójdzie nie tak, alerty automatycznie powiadomią zespół pomocy technicznej. Najlepiej, alerty obejmują zarówno dzienniki, jak i wiadomości e-mail (a nie tylko wiadomości e-mail). Dziennik jest przydatny do analizowania zarejestrowanych błędów i ostrzeżeń.
  • Rejestrowanie: procesy są rejestrowane, więc istnieje historia aktualizowania danych inspekcji. Zarejestrowane informacje powinny rejestrować czas rozpoczęcia, godzinę zakończenia oraz tożsamość użytkownika lub aplikacji, która uruchomiła proces.
  • Obsługa błędów: skrypty i procesy bezpiecznie obsługują i rejestrują błędy (takie jak natychmiastowe zakończenie pracy, kontynuowanie lub oczekiwanie i spróbuj ponownie). Powiadomienia o alertach są wysyłane do zespołu pomocy technicznej po wystąpieniu błędu.
  • Standardy kodowania: używane są dobre techniki kodowania, które dobrze działają. Na przykład pętle są celowo unikane z wyjątkiem sytuacji, gdy jest to konieczne. Używane są spójne standardy kodowania, komentarze, formatowanie i składnia, dzięki czemu rozwiązanie jest łatwiejsze do obsługi i obsługi.
  • Ponowne użycie i modułyzacja: aby zminimalizować duplikowanie, kod i wartości konfiguracji (takie jak parametry połączenia lub adresy e-mail dla powiadomień) są modularyzowane, aby inne skrypty i procesy mogły je ponownie wykorzystać.

Porada

Nie musisz robić wszystkiego wymienionego powyżej naraz. W miarę zdobywania doświadczenia możesz przyrostowo ulepszyć rozwiązanie, aby stało się kompletne i niezawodne. Należy pamiętać, że większość przykładów dostępnych w trybie online to proste fragmenty kodu jednorazowego skryptu, które mogą nie być jakością produkcji.

Lista kontrolna — podczas planowania operacji i ulepszania rozwiązania do inspekcji kluczowe decyzje i akcje obejmują:

  • Ocena poziomu istniejących rozwiązań: określ, czy istnieją możliwości poprawy i stabilizacji istniejących rozwiązań inspekcji, które są zautomatyzowane.
  • Ustanów standardy na poziomie produkcyjnym: zdecyduj, jakie standardy mają być używane dla zautomatyzowanych procesów inspekcji. Współczynnik ulepszeń, które można realistycznie dodać w czasie.
  • Utwórz plan poprawy: Zaplanuj poprawę jakości i stabilności rozwiązań inspekcji produkcji.
  • Określ, czy konieczne jest oddzielne środowisko programistyczne: oceń poziom ryzyka i poleganie na danych produkcyjnych. Zdecyduj, kiedy utworzyć oddzielne środowiska programistyczne i produkcyjne (i testowe).
  • Rozważ strategię przechowywania danych: określ, czy musisz zaimplementować proces przechowywania danych, który czyści dane po określonym czasie, czy na żądanie.

Dokumentacja i pomoc techniczna

Dokumentacja i obsługa techniczna mają kluczowe znaczenie dla dowolnego rozwiązania na poziomie produkcyjnym. Warto utworzyć kilka typów dokumentacji w zależności od docelowej grupy odbiorców i celu.

Dokumentacja techniczna

Dokumentacja techniczna jest przeznaczona dla zespołu technicznego, który zbudował rozwiązanie i będzie stopniowo ulepszać i rozszerzać rozwiązanie w czasie. Jest to również przydatny zasób dla zespołu pomocy technicznej.

Dokumentacja techniczna powinna zawierać następujące elementy:

  • Podsumowanie składników architektury i wymagań wstępnych.
  • Kto jest właścicielem rozwiązania i zarządza nim.
  • Kto obsługuje rozwiązanie.
  • Diagram architektury.
  • Decyzje projektowe, w tym cele, powody, dla których podjęto pewne wybory techniczne i ograniczenia (takie jak koszty lub umiejętności).
  • Decyzje i wybory dotyczące zabezpieczeń.
  • Używane konwencje nazewnictwa.
  • Kodowanie i standardy techniczne oraz wytyczne.
  • Wymagania dotyczące zarządzania zmianami.
  • Instrukcje dotyczące wdrażania, instalacji i instalacji.
  • Znane obszary długu technicznego (obszary, które można poprawić, jeśli istnieje możliwość tego).

Dokumentacja pomocy technicznej

W zależności od poziomu krytycznego dla rozwiązania do inspekcji może wystąpić zespół pomocy technicznej lub zespół pomocy technicznej. Mogą być dostępne przez cały dzień, każdego dnia.

Dokumentacja pomocy technicznej jest czasami nazywana baza wiedzy lub elementem Runbook. Ta dokumentacja jest przeznaczona dla działu pomocy technicznej lub zespołu pomocy technicznej i powinna zawierać następujące elementy:

  • Wskazówki dotyczące rozwiązywania problemów w przypadku wystąpienia błędu. Na przykład w przypadku niepowodzenia odświeżania danych.
  • Działania, które mają być podejmowane w sposób ciągły. Na przykład może istnieć kilka ręcznych kroków, które ktoś musi wykonać regularnie, dopóki problem nie zostanie rozwiązany.

Dokumentacja twórcy zawartości

Uzyskujesz większą wartość od rozwiązania do inspekcji, zapewniając analizę użycia i wdrażania innym zespołom w całej organizacji (z wymuszanymi zabezpieczeniami na poziomie wiersza, w razie potrzeby).

Dokumentacja twórcy zawartości jest przeznaczona dla twórców zawartości samoobsługi, którzy tworzą raporty i modele danych, które tworzą wyselekcjonowane dane inspekcji. Zawiera on informacje o modelu danych, w tym typowe definicje danych.

Lista kontrolna — podczas planowania dokumentacji i obsługi rozwiązania do inspekcji kluczowe decyzje i akcje obejmują:

  • Potwierdź, kto ma obsługiwać rozwiązanie: określ, kto będzie obsługiwał rozwiązania inspekcji, które są uznawane za poziom produkcji (lub mają zależności raportów podrzędnych).
  • Zapewnianie gotowości zespołu pomocy technicznej: sprawdź, czy zespół pomocy technicznej jest przygotowany do obsługi rozwiązania do inspekcji. Określ, czy istnieją luki w gotowości, które wymagają rozwiązania problemu.
  • Organizuj szkolenia krzyżowe: Przeprowadź sesje transferu wiedzy lub sesje między szkoleniami dla zespołu pomocy technicznej.
  • Wyjaśnienie oczekiwań zespołu pomocy technicznej: Upewnij się, że oczekiwania dotyczące odpowiedzi i rozwiązania są jasno udokumentowane i przekazane. Zdecyduj, czy ktoś musi być na wezwanie, aby szybko rozwiązać problemy związane z rozwiązaniem inspekcji.
  • Tworzenie dokumentacji technicznej: tworzenie dokumentacji dotyczącej architektury technicznej i decyzji projektowych.
  • Utwórz dokumentację pomocy technicznej: zaktualizuj bazę wiedzy pomocy technicznej, aby uwzględnić informacje o sposobie obsługi rozwiązania.
  • Tworzenie dokumentacji dla twórców zawartości: tworzenie dokumentacji ułatwiającej autorom samoobsługi korzystanie z modelu danych. Opis typowych definicji danych w celu zwiększenia spójności ich użycia.

Włączanie alertów

Możesz zgłaszać alerty na podstawie określonych warunków w danych inspekcji. Możesz na przykład zgłosić alert, gdy ktoś usunie bramę lub gdy administrator usługi Power BI zmieni ustawienie dzierżawy.

Aby uzyskać więcej informacji, zobacz Monitorowanie na poziomie dzierżawy.

Bieżące zarządzanie

Musisz wykonać bieżące zarządzanie całym rozwiązaniem inspekcji. Może być konieczne rozszerzenie lub zmiana rozwiązania inspekcji w przypadku:

  • Organizacja odnajduje nowe wymagania dotyczące danych.
  • Nowe zdarzenia inspekcji są wyświetlane w danych pierwotnych dokładnie z interfejsów API REST usługi Power BI.
  • Firma Microsoft wprowadza zmiany w interfejsach API REST usługi Power BI.
  • Pracownicy identyfikują sposoby ulepszania rozwiązania.

Ważne

Zmiany powodujące niezgodność są rzadkie, ale mogą wystąpić. Ważne jest, aby ktoś był dostępny, kto może szybko rozwiązywać problemy lub aktualizować rozwiązanie inspekcji w razie potrzeby.

Lista kontrolna — podczas planowania bieżącego zarządzania rozwiązaniem do inspekcji kluczowe decyzje i akcje obejmują:

  • Przypisz właściciela technicznego: upewnij się, że istnieje wyraźna własność i odpowiedzialność za całe rozwiązanie inspekcji.
  • Sprawdź, czy istnieje kopia zapasowa: upewnij się, że istnieje właściciel techniczny kopii zapasowej, który może zaangażować się, jeśli wystąpi pilny problem, który nie może rozwiązać pomocy technicznej.
  • Zachowaj system śledzenia: upewnij się, że masz sposób przechwytywania nowych żądań i sposobu określania priorytetów natychmiastowych, a także priorytetów krótkoterminowych, średnioterminowych i długoterminowych (listy prac).

Powiązana zawartość

W następnym artykule z tej serii dowiesz się więcej o monitorowaniu na poziomie dzierżawy.