Konfigurowanie profilów service principal dla aplikacji wielodzierżawnych

W tym artykule wyjaśniono, jak skonfigurować i obsługiwać profile jednostki usługi głównej po wybraniu ich dla rozwiązania Power BI Embedded osadzanie dla Twoich klientów. Profile obsługują zarządzanie zawartością ograniczoną do klienta i dużą liczbę obszarów roboczych. Separacja klientów zależy od prawidłowego routingu aplikacji, uprawnień obszaru roboczego i odpowiednio określonych tokenów osadzania; profile nie tworzą niezależnej tożsamości Microsoft Entra ani kryptograficznej granicy izolacji klienta.

Uwaga

W przypadku nowych rozwiązań wielodostępności należy zacząć od dedykowanych jednostek usługi klienta, używając tożsamości zarządzanej i poświadczeń federacyjnych tam, gdzie wymagania dotyczące hostingu i zaufania są spełnione. Profile nadal stanowią prawidłowe, opcjonalne rozwiązanie dla nowych i istniejących aplikacji, których wymagania pasują do ich zalet i ograniczeń. Jeśli spełniają Twoje wymagania, możesz nadal korzystać z profilów.

Profile nie są tożsamościami Microsoft Entra i nie mogą być używane z interfejsami API REST Fabric. Jeśli Twoje rozwiązanie wymaga tożsamości klientów dla usług zależnych, oddzielnych dzienników logowania do Microsoft Entra, dostępu warunkowego tożsamości obciążenia roboczego lub możliwości w inny sposób ograniczonych przez model profilu, rozważ zastąpienie profili jednostek usługi jednostkami usługi.

Uwaga

Słowo tenant w usłudze Power BI może czasami odnosić się do tenant firmy Microsoft Entra. W tym artykule używamy jednak terminu multitenancy do opisania rozwiązania, w którym pojedyncze wystąpienie aplikacji oprogramowania obsługuje wielu klientów lub organizacje (najemcy), wymagających fizycznego i logicznego rozdzielenia danych. Na przykład twórca aplikacji Power BI może przydzielić oddzielny obszar roboczy dla każdego z klientów (lub dzierżaw), jak omówiono w tym artykule. Ci użytkownicy nie muszą być podmiotami korzystającymi z Microsoft Entra, więc nie należy mylić terminu wielodostępna aplikacja, którego używamy tutaj, z wielodostępną aplikacją Microsoft Entra.

Profil jednostki usługi to profil utworzony przez jednostkę usługi. Aplikacja ISV wywołuje interfejsy API Power BI za pomocą profilu jednostki usługi, jak wyjaśniono w tym artykule.

Aplikacja ISV główny serwis tworzy inny profil Power BI dla każdego klienta lub dzierżawy. Gdy klient odwiedza aplikację niezależnego dostawcy oprogramowania, aplikacja używa odpowiedniego profilu do generowania tokenu osadzania używanego do renderowania raportu w przeglądarce.

Użycie profilów jednostki usługi umożliwia aplikacji niezależnego dostawcy oprogramowania (ISV) hostowanie wielu klientów w jednym dzierżawcy usługi Power BI. Każdy profil reprezentuje jednego klienta w usłudze Power BI. Innymi słowy każdy profil tworzy zawartość usługi Power BI i zarządza nią dla danych określonego klienta.

Diagram profilów jednostek usługi i wielodostępności.

Uwaga

Aby zapoznać się z omówieniem tej alternatywy, zobacz Profile nazwy głównej usługi: opcjonalne rozwiązanie wielodzierżawności. Poniższe kroki konfiguracji mają zastosowanie po wybraniu modelu profilu.

Konfigurowanie zawartości usługi Power BI obejmuje następujące kroki:

Wszystkie powyższe kroki można w pełni zautomatyzować przy użyciu interfejsów API REST usługi Power BI.

Wymagania wstępne

Zanim utworzysz profile jednostki usługi, musisz:

Zrzut ekranu przedstawiający przełącznik portalu administracyjnego.

Tworzenie profilu

Profile można tworzyć, aktualizować i usuwać przy użyciu interfejsu API REST Profilów.

Aby na przykład utworzyć profil:

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

{"displayName":"ContosoProfile"}

Obiekt usługi może również wywołać interfejs REST API GET Profiles, aby uzyskać listę swoich profilów. Na przykład:

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

Uprawnienia profilu

Każdy interfejs API, który przyznaje użytkownikowi uprawnienia do elementów usługi Power BI, może również udzielić uprawnień profilu do elementów usługi Power BI. Na przykład interfejs API dodawania użytkownika do grupy może być używany do przyznawania uprawnień profilowi do obszaru roboczego.

Podczas korzystania z profilów ważne są następujące kwestie:

  • Profil należy do jednostki usługi, która ją utworzyła, i może jej używać tylko jednostka usługi.
  • Nie można zmienić właściciela profilu po utworzeniu.
  • Profil nie jest tożsamością autonomiczną. Potrzebuje tokenu tożsamości usługi Microsoft Entra do wywoływania interfejsów API REST Power BI.

Aplikacje niezależnego dostawcy oprogramowania wywołują interfejsy API REST usługi Power BI, podając token jednostki usługi Microsoft Entra w nagłówku Autoryzacja oraz identyfikator profilu w nagłówku X-PowerBI-Profile-Id. Na przykład:

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

Tworzenie obszaru roboczego

Obszary robocze usługi Power BI są używane do hostowania elementów usługi Power BI, takich jak raporty i modele semantyczne.

Każdy profil musi:

  • Tworzenie co najmniej jednego obszaru roboczego usługi Power BI

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

{
  "name": "ContosoWorkspace"
}

  • Udziel uprawnień dostępu do obszaru roboczego. Profil głównej usługi musi mieć dostęp administratora do obszaru roboczego.

  • Przypisywanie obszaru roboczego do pojemności

    POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

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

Przeczytaj więcej na temat obszarów roboczych usługi Power BI.

Importowanie raportów i modeli semantycznych

Użyj programu Power BI Desktop , aby przygotować raporty połączone z danymi klienta lub przykładowymi danymi. Następnie możesz użyć interfejsu API importu, aby zaimportować zawartość do utworzonego obszaru roboczego.

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

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Użyj parametrów zestawu danych, aby utworzyć semantyczny model, który może łączyć się ze źródłami danych różnych klientów. Następnie użyj interfejsu API aktualizacji parametrów , aby zdefiniować dane klientów, z którymi łączy się model semantyczny.

Ustawianie połączenia modelu semantycznego

Dostawcy oprogramowania internetowego zwykle przechowują dane swoich klientów na jeden z dwóch sposobów:

W obu przypadkach powinieneś mieć w usłudze Power BI modele semantyczne o architekturze jeden-tenantowej (jeden model semantyczny na klienta).

Oddzielna baza danych dla każdego klienta

Jeśli aplikacja niezależnego dostawcy oprogramowania ma oddzielną bazę danych dla każdego klienta, utwórz jednodzierżawcze modele semantyczne w usłudze Power BI. Podaj każdy model semantyczny ze szczegółami połączenia wskazującymi pasującą bazę danych. Użyj jednej z następujących metod, aby uniknąć tworzenia wielu identycznych raportów z różnymi szczegółami połączenia:

  • Parametry modelu semantycznego: utwórz model semantyczny z parametramiw szczegółach połączenia (np. nazwa serwera SQL, nazwa bazy danych SQL). Następnie zaimportuj raport do obszaru roboczego klienta i zmień parametry tak, aby odpowiadały szczegółom bazy danych klienta.

  • Aktualizowanie interfejsu API źródła danych: Utwórz plik .pbix, który wskazuje na źródło danych z przykładową zawartością. Następnie zaimportuj plik .pbix do obszaru roboczego klienta i zmień szczegóły połączenia, korzystając z Update Datasource API.

Pojedyncza wielonajemcowa baza danych

Jeśli aplikacja niezależnego dostawcy oprogramowania używa jednej bazy danych dla wszystkich swoich klientów, rozdziel klientów na różne modele semantyczne w usłudze Power BI w następujący sposób:

Utwórz raport przy użyciu parametrów , które pobierają tylko dane odpowiedniego klienta. Następnie zaimportuj raport do obszaru roboczego klienta i zmień parametry , aby pobrać tylko dane odpowiedniego klienta.

Embed a report (Osadzanie raportu)

Po zakończeniu instalacji można osadzać raporty klientów i inne elementy w aplikacji przy użyciu tokenu osadzania.

Gdy klient odwiedza Twoją aplikację, użyj odpowiedniego profilu, aby wywołać interfejs API GenerateToken. Użyj wygenerowanego tokenu osadzania, aby osadzić raport lub inne elementy w przeglądarce klienta.

Aby wygenerować token osadzania:

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

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

Aspekty projektowania

Przed skonfigurowaniem wielodostępnego rozwiązania opartego na profilu należy pamiętać o następujących problemach:

Skalowalność

Oddzielając dane na oddzielne modele semantyczne dla każdego klienta, można zminimalizować potrzebę dużych modeli semantycznych. Gdy pojemność zostanie przeciążona, można wykluczyć nieużywane modele semantyczne, aby zwolnić pamięć dla aktywnych modeli semantycznych. Ta optymalizacja jest niemożliwa dla pojedynczego dużego modelu semantycznego. Korzystając z wielu modeli semantycznych, można w razie potrzeby również rozdzielić dzierżawców na wiele pojemności usługi Power BI.

Bez profilów, jednostka usługi może obsłużyć maksymalnie 1000 obszarów roboczych. Aby wyeliminować ten limit, jednostka usługi może utworzyć wiele profilów, w których każdy profil może uzyskiwać dostęp do 1000 obszarów roboczych. W przypadku wielu profilów aplikacja niezależnego dostawcy oprogramowania może odizolować zawartość każdego klienta przy użyciu odrębnych kontenerów logicznych.

Gdy profil jednostki usługi ma dostęp do obszaru roboczego, można usunąć dostęp jednostki usługi nadrzędnej do obszaru roboczego, aby uniknąć problemów ze skalowalnością.

Nawet w przypadku tych zalet należy wziąć pod uwagę potencjalną skalę aplikacji. Na przykład liczba elementów obszaru roboczego, do których może uzyskać dostęp profil, jest ograniczona. Obecnie profil ma takie same limity jak zwykły użytkownik. Jeśli aplikacja niezależnego dostawcy oprogramowania umożliwia użytkownikom końcowym zapisywanie spersonalizowanej kopii osadzonych raportów, profil klienta ma dostęp do wszystkich utworzonych raportów wszystkich użytkowników. Ten model może ostatecznie przekroczyć limit.

Automatyzacja i złożoność operacyjna

W przypadku separacji opartej na profilu usługi Power BI może być konieczne zarządzanie setkami lub tysiącami elementów. Dlatego ważne jest, aby zdefiniować procesy, które często występują w zarządzaniu cyklem życia aplikacji, i upewnić się, że masz odpowiedni zestaw narzędzi do wykonywania tych operacji na dużą skalę. Niektóre z tych operacji obejmują:

  • Dodawanie nowego najemcy
  • Aktualizowanie raportu dla niektórych lub wszystkich najemców
  • Aktualizacja schematu modelu semantycznego dla niektórych lub wszystkich najemców
  • Włączanie nieplanowanych dostosowań dla określonych najemców
  • Ustawianie częstotliwości odświeżania modelu semantycznego

Na przykład utworzenie profilu i obszaru roboczego dla nowego najemcy jest typowym zadaniem, które można w pełni zautomatyzować za pomocą interfejsu API REST usługi Power BI.

Wymagania dotyczące wielu regionów geograficznych

Obsługa funkcji Multi-Geo dla usługi Power BI Embedded oznacza, że dostawcy oprogramowania i organizacje tworzące aplikacje korzystające z usługi Power BI Embedded do osadzania analizy w aplikacjach mogą teraz wdrażać swoje dane w różnych regionach na całym świecie. Aby obsługiwać różnych klientów w różnych regionach, przypisz obszar roboczy klienta do zasobów w preferowanym regionie. To zadanie jest prostą operacją, która nie wiąże się z dodatkowymi kosztami. Jeśli jednak masz klientów, którzy potrzebują danych z wielu regionów, profil dzierżawy powinien zduplikować wszystkie elementy do wielu obszarów roboczych przypisanych do różnych pojemności regionalnych. Takie duplikowanie może zwiększyć złożoność zarówno kosztów, jak i zarządzania.

Ze względów zgodności możesz nadal tworzyć wiele dzierżaw usługi Power BI w różnych regionach. Przeczytaj więcej na temat multi-geo.

Efektywność kosztowa

Deweloperzy aplikacji korzystający z usługi Power BI Embedded muszą zakupić pojemność usługi Power BI Embedded. Model separacji oparty na profilu działa dobrze z pojemnościami, ponieważ:

  • Najmniejszy obiekt, który można przypisać niezależnie do pojemności, to obszar roboczy (na przykład nie można przypisać raportu). Oddzielając klientów według profilów, uzyskujesz różne obszary robocze — jeden na klienta. Dzięki temu uzyskasz pełną elastyczność zarządzania poszczególnymi klientami zgodnie z ich potrzebami w zakresie wydajności i zoptymalizuj wykorzystanie pojemności przez skalowanie w górę lub w dół. Na przykład można zarządzać dużymi i istotnymi klientami z dużą ilością i zmiennością w oddzielnej pojemności, aby zapewnić spójny poziom usług, jednocześnie grupując mniejszych klientów w innej pojemności w celu optymalizacji kosztów.

  • Oddzielenie obszarów roboczych oznacza również oddzielenie modeli semantycznych między dzierżawami, dzięki czemu modele danych znajdują się w mniejszych częściach, zamiast jednej dużej całości semantycznej. Te mniejsze modele umożliwiają wydajniejsze zarządzanie użyciem pamięci. Małe, nieużywane modele semantyczne można usuwać po nieaktywnym okresie, aby zachować dobrą wydajność.

Podczas zakupu pojemności należy wziąć pod uwagę limit liczby odświeżeń równoległych, ponieważ procesy odświeżania mogą potrzebować dodatkowej pojemności, jeśli masz wiele modeli semantycznych.

Zabezpieczenia na poziomie wiersza

W tym artykule wyjaśniono, jak używać profilów do tworzenia oddzielnego modelu semantycznego dla każdego klienta. Alternatywnie, aplikacje niezależnych dostawców oprogramowania mogą przechowywać wszystkie dane swoich klientów w jednym dużym modelu semantycznym i używać zabezpieczeń na poziomie wiersza do ochrony danych każdego klienta. Takie podejście może być wygodne dla niezależnych dostawców oprogramowania, które mają stosunkowo niewielu klientów i małe i średnie modele semantyczne, ponieważ:

  • Muszą one obsługiwać tylko jeden raport i jeden model semantyczny
  • Proces dołączania dla nowych klientów można uprościć

Przed użyciem RLS upewnij się jednak, że rozumiesz jego ograniczenia. Wszystkie dane dla wszystkich klientów znajdują się w jednym dużym modelu semantycznym usługi Power BI. Ten semantyczny model działa w jednej instancji z własnym mechanizmem skalowania i innymi ograniczeniami.

Nawet jeśli używasz profilów głównych usług do oddzielania danych klientów, nadal możesz używać zabezpieczeń na poziomie wiersza w ramach modelu semantycznego pojedynczego klienta, aby zapewnić różnym grupom dostęp do różnych części danych. Na przykład można użyć RLS (zabezpieczeń na poziomie wiersza), aby uniemożliwić członkom jednego działu uzyskiwanie dostępu do danych innego działu w tej samej organizacji.

Rozważania i ograniczenia

Przed wybraniem lub rozszerzeniem modelu profilu oceń limity tożsamości, interfejsu API i skali.

Ograniczenia tożsamości i interfejsu API

Przed wdrożeniem profilów lub rozszerzaniem istniejącego rozwiązania opartego na profilu zapoznaj się z tymi ograniczeniami:

Limitation Co to oznacza dla Twojego rozwiązania
To nie jest tożsamość Microsoft Entra Profil istnieje tylko w Power BI. Nie można niezależnie zarządzać ani kontrolować go za pomocą narzędzi Microsoft Entra ani udzielać uprawnień jako tożsamości w usługach podrzędnych. Na przykład profil nie może być tożsamością połączenia usługi Direct Lake z modelu semantycznego do lakehouse lub magazynu danych.
Brak obsługi interfejsu API REST Fabric Profile działają za pośrednictwem interfejsu API REST Power BI, zestawu SDK .NET Power BI i obsługiwanych interfejsów XMLA/TOM. Fabric interfejsy API REST nie obsługują ich, a obsługa nie jest planowana.
Brak niezależnej tożsamości logowania Operacje o zakresie ograniczonym do profilu nie generują niezależnych rekordów logowań Microsoft Entra dla poszczególnych klientów. Dzienniki aktywności Power BI nadal mogą identyfikować profile.
Brak dostępu warunkowego na profil Profil nie jest jednostką zabezpieczeń, której nie może dotyczyć dostęp warunkowy dla tożsamości obciążenia. Zasady dotyczące kwalifikujących się dedykowanych nazw głównych usługi mają oddzielne wymagania dotyczące licencjonowania i konfiguracji.
Powiązany z podmiotem zabezpieczeń, który go utworzył Nie można przenosić profilów między nadrzędnymi jednostkami usługi. Zmiana elementu nadrzędnego wymaga ponownego utworzenia profilów, przywrócenia dostępu do obszaru roboczego i zaktualizowania mapowań klientów.
Administracja tylko przez API Profile nie mają dedykowanego interfejsu użytkownika administracyjnego do przeglądania i zarządzania nimi. Nie są wyświetlane w centrum administracyjne Microsoft Entra.

Jeśli te ograniczenia ograniczają możliwości Twojego rozwiązania, zobacz Zastąp profile nazw głównych usługi nazwami głównymi usługi. W przypadku klientów, którzy zdecydują się przeprowadzić migrację, przewodnik zaleca tożsamość zarządzaną i poświadczenia federacyjne tam, gdzie spełnione są wymagania dotyczące hostingu i zaufania. Bezpośrednie uwierzytelnianie nazwy głównej usługi pozostaje alternatywą.

Obsługiwane interfejsy i limity skalowania

  • Profile jednostki usługi są obsługiwane tylko za pośrednictwem interfejsu API REST usługi Power BI, zestawu .NET SDK usługi Power BI oraz punktu końcowego XMLA i modelu obiektów tabelarycznych (TOM) w przypadku korzystania z bibliotek klienckich usług Analysis Services w wersji 16.0.139.27 lub nowszej. Profile jednostki usługi nie są obsługiwane w usłudze Power BI za pośrednictwem punktu końcowego XMLA ani modelu obiektów tabelarycznych (TOM) ze starszymi bibliotekami klienckimi.
  • Profile głównych usług nie są obsługiwane przez Azure Analysis Services (AAS) w trybie połączenia na żywo.
  • Maksymalna liczba profilów, które może mieć jedna jednostka usługi, wynosi 100 000.

Ograniczenia pojemności usługi Power BI

  • Każda pojemność może używać tylko przydzielonej pamięci i rdzeni wirtualnych, zgodnie z zakupionym SKU. W przypadku zalecanego rozmiaru modelu semantycznego dla każdej jednostki SKU zapoznaj się z tematem Duże modele semantyczne Premium.
  • Aby użyć modelu semantycznego większego niż 10 GB, użyj pojemności Premium i włącz ustawienie duże modele semantyczne.
  • W przypadku liczby odświeżeń, które mogą być uruchamiane współbieżnie w ramach pojemności, należy odwołać się do zarządzania zasobami i optymalizacji.

Zarzadzanie jednostkami usługi

Zmienianie jednostki usługi

W usłudze Power BI profil należy do jednostki usługi, która ją utworzyła. Oznacza to, że profil nie może być udostępniany innym użytkownikom. Z tym ograniczeniem, jeśli chcesz zmienić główne konto usługi z jakiegokolwiek powodu, musisz ponownie utworzyć wszystkie profile i przyznać nowym profilom dostęp do odpowiednich obszarów roboczych. Często aplikacja niezależnego dostawcy oprogramowania musi zapisywać mapowanie między identyfikatorem profilu a identyfikatorem klienta, aby w razie potrzeby wybrać odpowiedni profil. Jeśli zmienisz jednostkę usługi i ponownie utworzysz profile, identyfikatory również zmienią się i może być konieczne zaktualizowanie mapowania w bazie danych aplikacji niezależnego dostawcy oprogramowania.

Usuwanie podmiotu usługi

Ostrzeżenie

Podczas usuwania jednostki usługi należy zachować ostrożność. Nie chcesz przypadkowo stracić danych ze wszystkich swoich powiązanych profilów.

Jeśli usuniesz jednostkę usługi w usłudze Active Directory, wszystkie jego profile w usłudze Power BI zostaną usunięte. Jednak usługa Power BI nie usuwa zawartości natychmiast, więc administrator dzierżawy nadal może uzyskiwać dostęp do obszarów roboczych. Należy zachować ostrożność podczas usuwania jednostki usługi używanej w systemie produkcyjnym, szczególnie podczas tworzenia profilów przy użyciu tej jednostki usługi w usłudze Power BI. Jeśli usuniesz jednostkę usługi, która utworzyła profile, musisz ponownie utworzyć wszystkie profile, przyznać nowym profilom dostęp do odpowiednich obszarów roboczych i zaktualizować identyfikatory profilów w bazie danych aplikacji niezależnego dostawcy oprogramowania.

Separacja danych

W przypadku korzystania z profilów jednostki usługi głównej aplikacja musi mapować każdego uwierzytelnionego klienta na prawidłowy profil i dozwolone zasoby. Uprawnienia obszaru roboczego i odpowiednio ograniczone tokeny osadzania kontrolują dostęp. Profil nie jest niezależną tożsamością Microsoft Entra, a jego nadrzędna jednostka usługi może działać za pośrednictwem dowolnego utworzonego profilu.

Rozważ dedykowane nazwy główne usług, gdy rozwiązanie wymaga nadzoru w Microsoft Entra, niezależnego monitorowania logowania, zasad dostępu warunkowego dla kwalifikujących się tożsamości obciążeń, tożsamości usług podrzędnych lub dostępu do interfejsu API REST usługi Fabric. Są one również alternatywą, gdy powiązanie profilu z elementem nadrzędnym lub administrowanie tylko interfejsem API powoduje trudności operacyjne. Jeśli profile spełniają twoje wymagania, możesz nadal z nich korzystać.

Dedykowane nazwy główne usług umożliwiają niezależne zarządzanie uprawnieniami klienta i uwierzytelnianiem. Jeśli używasz przechowywanych certyfikatów, możesz rotować je oddzielnie dla każdego klienta. Jednak wpływ wycieku poświadczeń lub naruszenia środowiska uruchomieniowego zależy od tego, które poświadczenia klienta lub federacyjne relacje zaufania mogą być używane przez środowisko uruchomieniowe. Żadna architektura nie gwarantuje automatycznej izolacji między klientami.

Zarządzanie dedykowanymi tożsamościami wiąże się z limitami obiektów katalogu i obsługą cyklu życia. Oceń te kompromisy i postępuj zgodnie z Zamień profile jednostki usługi na jednostki usługi, jeśli zdecydujesz się przeprowadzić migrację. Zachowaj konfigurację danych, które mają być wyświetlane użytkownikowi końcowemu w backendzie podczas generowania tokenu osadzania. Przed wybraniem tożsamości, obszaru roboczego lub zawartości zweryfikuj członkostwo klienta.

Jeden raport, wiele modeli semantycznych

Ogólnie rzecz biorąc, masz jeden raport i jeden model semantyczny na najemcę. Jeśli masz setki raportów, będziesz mieć setki modeli semantycznych. Czasami może istnieć jeden format raportu z różnymi modelami semantycznymi (na przykład różnymi parametrami lub szczegółami połączenia). Za każdym razem, gdy masz nową wersję raportu, musisz zaktualizować wszystkie raporty dla wszystkich klientów. Chociaż można zautomatyzować ten proces, łatwiej jest zarządzać, jeśli masz tylko jedną kopię raportu. Utwórz obszar roboczy zawierający raport do osadzenia. Podczas trwania sesji powiąż raport z semantycznym modelem specyficznym dla dzierżawy. Przeczytaj powiązania dynamiczne, aby uzyskać więcej szczegółów.

Dostosowywanie i tworzenie zawartości

Podczas tworzenia zawartości należy dokładnie rozważyć, kto ma uprawnienia do jej edytowania. Jeśli zezwolisz wielu użytkownikom w każdym dzierżawcy na edycję, łatwo przekroczyć ograniczenia modelu semantycznego. Jeśli zdecydujesz się na zapewnienie użytkownikom możliwości edytowania, uważnie monitoruj generowanie zawartości i skaluj w górę zgodnie z potrzebami. Z tego samego powodu nie zalecamy używania tej funkcji do personalizacji zawartości, gdzie każdy użytkownik może wprowadzać małe zmiany w raporcie i zapisywać je samodzielnie. Jeśli aplikacja niezależnego dostawcy oprogramowania zezwala na personalizację zawartości, rozważ wprowadzenie zasad przechowywania obszaru roboczego dla zawartości specyficznej dla użytkownika. Zasady przechowywania ułatwiają usuwanie zawartości, gdy użytkownicy przechodzą na nowe stanowisko, opuszczają firmę lub przestają korzystać z platformy.

Tożsamość zarządzana przez system

Zamiast jednostki usługi, możesz użyć przypisanej przez użytkownika lub zarządzanej tożsamości przypisanej przez system do tworzenia profili. Tożsamości zarządzane zmniejszają potrzebę używania haseł i certyfikatów.

Uwaga

Tożsamość zarządzana, która tworzy profile i używa ich, nie przekształca tych profilów w Microsoft Entra tożsamości ani umożliwia ich używania z interfejsami API REST Fabric. Ten warunek różni się od używania tożsamości zarządzanej i poświadczeń federacyjnych do uwierzytelniania jako dedykowanych nazw głównych usług klienta. Zobacz Jak zastąpić profile nazwy głównej usługi nazwami głównymi usługi.

Podczas korzystania z tożsamości zarządzanej przez system należy zachować ostrożność, ponieważ:

  • Jeśli tożsamość zarządzana przypisana przez system zostanie przypadkowo wyłączona, utracisz dostęp do profilów. Taka sytuacja jest podobna do przypadku, gdy podmiot usługi zostaje usunięty.
  • Tożsamość zarządzana przypisana przez system jest połączona z zasobem na platformie Azure (aplikacja internetowa). Jeśli usuniesz zasób, tożsamość zostanie również usunięta.
  • Użycie wielu zasobów (różnych aplikacji internetowych w różnych regionach) powoduje oddzielne zarządzanie wieloma tożsamościami (każda tożsamość ma własne profile).

Ze względu na powyższe zagadnienia zalecamy użycie tożsamości zarządzanej przypisanej przez użytkownika.

Przykład

Aby uzyskać przykład użycia profili głównej usługi do zarządzania środowiskiem wielu dzierżawców za pomocą osadzania Power BI i App-Owns-Data, pobierz repozytorium App owns data multitenant z Power BI Dev Camp (strona zewnętrzna).

Powiązana zawartość

  • Ostatnia aktualizacja o