Del via

Tjenestekontohaverprofiler for apper for fleretenancy-apper i Power BI Embedded

  • Artikkel

Denne artikkelen forklarer hvordan en ISV eller en annen Power BI Embedded-appeier med mange kunder kan bruke tjenestekontohaverprofiler til å tilordne og administrere hver kundes data som en del av Power BI-innebyggingen for kundenes løsning. Tjenestekontohaverprofiler gjør det mulig for ISV å bygge skalerbare programmer som muliggjør bedre isolering av kundedata og etablerer tettere sikkerhetsgrenser mellom kunder. Denne artikkelen tar for seg fordelene og begrensningene for denne løsningen.

Merk

Ordet tenant i Power BI kan noen ganger referere til en Microsoft Entra-leier. I denne artikkelen bruker vi imidlertid begrepet multitenancy til å beskrive en løsning der en enkelt forekomst av et program betjener flere kunder eller organisasjoner (leiere) som krever fysisk og logisk fordeling av data. Power BI App Builder kan for eksempel tildele et eget arbeidsområde for hver av sine kunder (eller leiere) som vi viser nedenfor. Disse kundene er ikke nødvendigvis Microsoft Entra-leiere, så ikke forveksle begrepet multitenant program som vi bruker her, med Microsoft Entra multitenant-programmet.

En tjenestekontohaverprofil er en profil opprettet av en tjenestekontohaver. ISV-appen kaller Power BI-API s ved hjelp av en tjenestekontohaverprofil, som forklart i denne artikkelen.

Isv-programtjenestekontohaveren oppretter en annen Power BI-profil for hver kunde eller leier. Når en kunde besøker ISV-appen, bruker appen den tilsvarende profilen til å generere et innebyggingstoken som skal brukes til å gjengi en rapport i nettleseren.

Ved hjelp av tjenestekontohaverprofiler kan ISV-appen være vert for flere kunder på én enkelt Power BI-leier. Hver profil representerer én kunde i Power BI. Med andre ord oppretter og administrerer hver profil Power BI-innhold for én bestemt kundes data.

Diagram over SP-profiler og multitenancy.

Merk

Denne artikkelen er rettet mot organisasjoner som ønsker å konfigurere en flertenant app ved hjelp av tjenestekontohaverprofiler. Hvis organisasjonen allerede har en app som støtter multitenancy, og du vil overføre til profilmodellen for tjenestekontohaver, kan du se Overfør til tjenestekontohaverprofilmodellen.

Konfigurasjon av Power BI-innhold omfatter følgende fremgangsmåte:

Alle trinnene ovenfor kan automatiseres ved hjelp av REST-API-er for Power BI.

Forutsetning

Før du kan opprette tjenestekontohaverprofiler, må du:

  • Konfigurer tjenestekontohaveren ved å følge de tre første trinnene i Bygg inn Power BI-innhold med tjenestekontohaver.
  • Fra en administratorkonto for Power BI-leier kan du aktivere oppretting av profiler i leieren ved hjelp av den samme sikkerhetsgruppen du brukte da du opprettet tjenestekontohaveren.

Skjermbilde av bryteren for administrasjonsportalen.

Opprett en profil

Profiler kan opprettes, oppdateres og slettes ved hjelp av REST-API-en for profiler.

Hvis du for eksempel vil opprette en 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"}

En tjenestekontohaver kan også kalle GET Profiles REST API for å få en liste over profilene. Eksempel:

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

Profiltillatelser

Alle API-er som gir en brukertillatelse til Power BI-elementer, kan også gi en profiltillatelse til Power BI-elementer. API for legg til gruppebruker kan for eksempel brukes til å gi en profiltillatelse til et arbeidsområde.

Følgende punkter er viktige å forstå når du bruker profiler:

  • En profil tilhører tjenestekontohaveren som opprettet den, og kan bare brukes av denne tjenestekontohaveren.
  • En profileier kan ikke endres etter oppretting.
  • En profil er ikke en frittstående identitet. Det trenger tjenestekontohaveren Microsoft Entra-token for å kalle Power BI REST API-er.

ISV-apper kaller Power BI REST-API-er ved å gi tjenestekontohaveren Microsoft Entra-token i autorisasjonshodet og profil-ID-en i toppteksten X-PowerBI-Profile-ID . Eksempel:

  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

Opprette et arbeidsområde

Power BI-arbeidsområder brukes til å være vert for Power BI-elementer som rapporter og semantiske modeller.

Hver profil må:

  • Opprett minst ett Power BI-arbeidsområde 

    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"
}

  • Gi tilgangstillatelser til arbeidsområdet. Tjenestekontohaverprofilen må ha administratortilgang til arbeidsområdet.

  • Tilordne arbeidsområdet til en kapasitet

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

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

Les mer om Power BI-arbeidsområder.

Importere rapporter og semantiske modeller

Bruk Power BI Desktop til å klargjøre rapporter som er koblet til kundens data eller eksempeldata. Deretter kan du bruke import-API-en til å importere innholdet til det opprettede arbeidsområdet.

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

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Bruk datasettparametere til å opprette en semantisk modell som kan koble til ulike kunders datakilder. Bruk deretter API-en for oppdateringsparametere til å definere hvilke kunders data den semantiske modellen kobler til.

Angi semantisk modelltilkobling

ISV-er lagrer vanligvis kundenes data på én av to måter:

I begge tilfeller bør du ende opp med semantiske modeller med én leier (én semantisk modell per kunde) i Power BI.

En separat database for hver kunde

Hvis ISV-programmet har en egen database for hver kunde, oppretter du semantiske modeller for én leier i Power BI. Gi hver semantisk modell tilkoblingsdetaljer som peker til den samsvarende databasen. Bruk én av følgende metoder for å unngå å opprette flere identiske rapporter med ulike tilkoblingsdetaljer:

  • Semantiske modellparametere: Opprett en semantisk modell med parametere i tilkoblingsdetaljene (for eksempel SQL Server-navn, SQL-databasenavn). Deretter importerer du en rapport til kundens arbeidsområde og endrer parameterne slik at de samsvarer med kundens databasedetaljer.

  • Oppdater API-en for datakilde: Opprett en PBIX som peker til en datakilde med eksempelinnhold. Deretter importerer du PBIX-en til kundens arbeidsområde og endrer tilkoblingsdetaljene ved hjelp av API-en Oppdater datakilde.

Én enkelt flertenant database

Hvis ISV-programmet bruker én database for alle sine kunder, skiller du kundene i forskjellige semantiske modeller i Power BI på følgende måte:

Opprett en rapport ved hjelp av parametere som bare henter de relevante kundens data. Deretter importerer du en rapport til kundens arbeidsområde og endrer parameterne for å hente bare den aktuelle kundens data.

Bygge inn en rapport

Når installasjonen er fullført, kan du bygge inn kunderapporter og andre elementer i programmet ved hjelp av et innebyggingstoken.

Når en kunde besøker programmet, kan du bruke den tilsvarende profilen til å kalle GenerateToken-API-en. Bruk det genererte innebyggingstokenet til å bygge inn en rapport eller andre elementer i kundens nettleser.

Slik genererer du et innebyggingstoken:

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"
    }
  ]
}

Utform aspekter

Før du konfigurerer en profilbasert flertenantløsning, bør du være oppmerksom på følgende problemer:

Skalerbarhet

Ved å skille dataene i separate semantiske modeller for hver kunde minimerer du behovet for store semantiske modeller. Når kapasiteten blir overbelastet, kan den kaste ut ubrukte semantiske modeller for å frigjøre minne for aktive semantiske modeller. Denne optimaliseringen er umulig for en enkelt stor semantisk modell. Ved å bruke flere semantiske modeller kan du også skille leiere i flere Power BI-kapasiteter om nødvendig.

Uten profiler er en tjenestekontohaver begrenset til 1000 arbeidsområder. Hvis du vil overvinne denne grensen, kan en tjenestekontohaver opprette flere profiler, der hver profil kan få tilgang til/opprette opptil 1000 arbeidsområder. Med flere profiler kan ISV-appen isolere hver kundes innhold ved hjelp av distinkte logiske beholdere.

Når en tjenestekontohaverprofil har tilgang til et arbeidsområde, kan den overordnede tjenestekontohaverens tilgang til arbeidsområdet fjernes for å unngå skalerbarhetsproblemer.

Selv med disse fordelene bør du vurdere den potensielle omfanget av programmet. Antallet arbeidsområdeelementer en profil kan få tilgang til, er for eksempel begrenset. I dag har en profil de samme grensene som en vanlig bruker. Hvis ISV-programmet tillater sluttbrukere å lagre en personlig kopi av de innebygde rapportene, får kundens profil tilgang til alle de opprettede rapportene til alle brukerne. Denne modellen kan etter hvert overskride grensen.

Automatisering og driftskompleksitet

Med profilbasert separasjon i Power BI må du kanskje administrere hundrevis eller tusenvis av elementer. Derfor er det viktig å definere prosessene som ofte skjer i programmets livssyklusbehandling, og sikre at du har riktig sett med verktøy for å utføre disse operasjonene i stor skala. Noen av disse operasjonene omfatter:

  • Legge til en ny leier
  • Oppdatere en rapport for noen eller alle leiere
  • Oppdatere det semantiske modellskjemaet for noen eller alle leiere
  • Ikke-planlagte tilpassinger for bestemte leiere
  • Hyppigheten av semantiske modelloppdateringer

Oppretting av en profil og et arbeidsområde for en ny leier er for eksempel en vanlig oppgave, som kan automatiseres fullstendig med REST-API-en for Power BI.

Multi-Geo-behov

Multi-Geo-støtte for Power BI Embedded betyr at ISV-er og organisasjoner som bygger programmer ved hjelp av Power BI Embedded for å bygge inn analyser i appene sine, nå kan distribuere dataene sine i forskjellige områder rundt om i verden. Hvis du vil støtte ulike kunder i forskjellige områder, tilordner du kundens arbeidsområde til en kapasitet i ønsket område. Denne aktiviteten er en enkel operasjon som ikke innebærer ekstra kostnader. Hvis du imidlertid har kunder som trenger data fra flere områder, bør leierprofilen duplisere alle elementer i flere arbeidsområder som er tilordnet ulike regionale kapasiteter. Denne dupliseringen kan øke både kostnads- og administrasjonskompleksiteten.

Av samsvarsårsaker vil du kanskje fortsatt opprette flere Power BI-leiere i forskjellige områder. Les mer om multi-geo.

Kostnadseffektivitet

Programutviklere som bruker Power BI Embedded, må kjøpe en Power BI Embedded-kapasitet. Den profilbaserte separasjonsmodellen fungerer bra med kapasiteter fordi:

  • Det minste objektet du uavhengig kan tilordne til en kapasitet, er et arbeidsområde (du kan for eksempel ikke tilordne en rapport). Ved å skille kunder etter profiler får du forskjellige arbeidsområder – én per kunde. På denne måten får du full fleksibilitet til å administrere hver kunde i henhold til deres ytelsesbehov, og optimalisere kapasitetsutnyttelsen ved å skalere opp eller ned. Du kan for eksempel administrere store og viktige kunder med høyt volum og volatilitet i en egen kapasitet for å sikre et konsekvent servicenivå, samtidig som du grupperer mindre kunder i en annen kapasitet for å optimalisere kostnadene.

  • Skille arbeidsområder betyr også å skille semantiske modeller mellom leiere slik at datamodeller er i mindre deler, i stedet for en enkelt stor semantisk modell. Disse mindre modellene gjør det mulig å administrere minnebruken mer effektivt. Små, ubrukte semantiske modeller kan utestenges etter en periode med inaktivitet, for å opprettholde god ytelse.

Når du kjøper en kapasitet, bør du vurdere grensen for antall parallelle oppdateringer, da oppdateringsprosesser kan trenge ekstra kapasitet når du har flere semantiske modeller.

Sikkerhet på radnivå

Denne artikkelen forklarer hvordan du bruker profiler til å opprette en egen semantisk modell for hver kunde. Alternativt kan ISV-programmer lagre alle kundenes data i én stor semantisk modell og bruke sikkerhet på radnivå (RLS) for å beskytte hver kundes data. Denne tilnærmingen kan være praktisk for uavhengige programvareleverandører som har relativt få kunder og små og mellomstore semantiske modeller fordi:

  • Det er bare én rapport og én semantisk modell å vedlikeholde
  • Pålastingsprosessen for nye kunder kan forenkles

Før du bruker RLS, må du imidlertid sørge for at du forstår begrensningene. Alle dataene for alle kunder er i én stor Semantisk Power BI-modell. Denne semantiske modellen kjører i én enkelt kapasitet med egen skalering og andre begrensninger.

Selv om du bruker tjenestekontohaverprofiler til å skille kundenes data, kan du fortsatt bruke RLS i en enkelt kundes semantiske modell for å gi forskjellige grupper tilgang til ulike deler av dataene. Du kan for eksempel bruke RLS til å hindre at medlemmer av én avdeling får tilgang til data fra en annen avdeling i samme organisasjon.

Hensyn og begrensninger

  • Tjenestekontohaverprofiler støttes bare gjennom REST-API-en for Power BI, Power BI .NET SDK og gjennom XMLA-endepunktet og tabellobjektmodellen (TOM) når du bruker Analysis Services-klientbiblioteker versjon 16.0.139.27 eller nyere. Tjenestekontohaverprofiler støttes ikke i Power BI gjennom XMLA-endepunktet eller tabellobjektmodellen (TOM) med eldre klientbiblioteker.
  • Tjenestekontohaverprofiler støttes ikke med Azure Analysis Services (AAS) i live-tilkoblingsmodus.
  • Den maksimale profilen en enkelt tjenestekontohaver kan ha, er 100 000.

Kapasitetsbegrensninger for Power BI

Administrere tjenestekontohavere

Endre en tjenestekontohaver

I Power BI tilhører en profil tjenestekontohaveren som opprettet den. Det betyr at en profil ikke kan deles med andre hovedstoler. Med denne begrensningen, hvis du vil endre tjenestekontohaveren av en eller annen grunn, må du gjenopprette alle profilene og gi de nye profilene tilgang til de relevante arbeidsområdene. Isv-programmet må ofte lagre en tilordning mellom en profil-ID og en kunde-ID for å kunne velge riktig profil ved behov. Hvis du endrer tjenestekontohaveren og oppretter profilene på nytt, endres også ID-ene, og du må kanskje oppdatere tilordningen i ISV-programdatabasen.

Slette en tjenestekontohaver

Advarsel!

Vær svært forsiktig når du sletter en tjenestekontohaver. Du vil ikke ved et uhell miste data fra alle tilknyttede profiler.

Hvis du sletter tjenestekontohaveren i active directory, slettes alle profilene i Power BI. Power BI sletter imidlertid ikke innholdet umiddelbart, så leieradministratoren kan fortsatt få tilgang til arbeidsområdene. Vær forsiktig når du sletter en tjenestekontohaver som brukes i et produksjonssystem, spesielt når du opprettet profiler ved hjelp av denne tjenestekontohaveren i Power BI. Hvis du sletter en tjenestekontohaver som har opprettet profiler, må du være oppmerksom på at du må gjenopprette alle profilene, gi de nye profilene tilgang til de relevante arbeidsområdene og oppdatere profil-ID-ene i ISV-programdatabasen.

Dataseparasjon

Når data er atskilt med tjenestekontohaverprofiler, forhindrer en enkel tilordning mellom en profil og kunde at én kunde ser innholdet til en annen kunde. Bruk av én enkelt tjenestekontohaver krever at tjenestekontohaveren har tilgang til alle de forskjellige arbeidsområdene i alle profilene.

Hvis du vil legge til ekstra separasjon, tilordner du en separat tjenestekontohaver til hver leier, i stedet for å ha en enkel tjenestekontohaver tilgang til flere arbeidsområder ved hjelp av forskjellige profiler. Tilordning av separate tjenestekontohavere har flere fordeler, inkludert:

  • Menneskelig feil eller en legitimasjonslekkasje vil ikke føre til at flere leieres data vises.
  • Sertifikatrotasjon kan gjøres separat for hver leier.

Bruk av flere tjenestekontohavere kommer imidlertid med en høy administrasjonskostnad. Velg denne banen bare hvis du trenger ekstra separasjon. Husk at konfigurasjonen av hvilke data som skal vises for en sluttbruker, er definert når du genererer innebyggingstokenet, en prosess som bare er en serverdel som sluttbrukerne ikke kan se eller endre. Hvis du ber om et innebyggingstoken ved hjelp av en leierspesifikk profil, genereres et innebyggingstoken for den bestemte profilen, noe som gir deg kundeseparasjon i forbruk.

Én rapport, flere semantiske modeller

Vanligvis har du én rapport og én semantisk modell per leier. Hvis du har hundrevis av rapporter, har du hundrevis av semantiske modeller. Noen ganger kan det hende du har ett rapportformat, med ulike semantiske modeller (for eksempel forskjellige parametere eller tilkoblingsdetaljer). Hver gang du har en ny versjon av rapporten, må du oppdatere alle rapportene for alle leiere. Selv om du kan automatisere dette, er det enklere å administrere hvis du bare har én kopi av rapporten. Opprett et arbeidsområde som inneholder rapporten som skal bygges inn. Under en øktkjøring binder du rapporten til den leierspesifikke semantiske modellen. Les dynamiske bindinger for mer informasjon.

Tilpasse og redigere innhold

Når du oppretter innhold, bør du vurdere hvem som har tillatelse til å redigere det. Hvis du tillater flere brukere i hver leier å redigere, er det enkelt å overskride semantiske modellbegrensninger. Hvis du bestemmer deg for å gi brukerne redigeringsfunksjonalitet, kan du overvåke innholdsgenereringen nøye og skalere opp etter behov. Av samme grunn anbefaler vi ikke å bruke denne funksjonen for innholdstilpassing, der hver bruker kan gjøre små endringer i en rapport og lagre den for seg selv. Hvis ISV-programmet tillater innholdstilpassing, bør du vurdere å innføre policyer for oppbevaring av arbeidsområder for brukerspesifikkt innhold. Oppbevaringspolicyer gjør det enklere å slette innhold når brukere flytter til en ny stilling, forlater firmaet eller slutter å bruke plattformen.

Systemadministrert identitet

I stedet for en tjenestekontohaver kan du bruke en brukertilordet eller systemtilordetadministrert identitet til å opprette profiler. Administrerte identiteter reduserer behovet for hemmeligheter og sertifikater.

Vær forsiktig når du bruker en systemadministrert identitet fordi:

  • Hvis en systemtilknyttet administrert identitet ved et uhell er deaktivert, mister du tilgangen til profilene. Denne situasjonen ligner på en sak der en tjenestekontohaver slettes.
  • En systemtildelt administrert identitet er koblet til en ressurs i Azure (nettapp). Hvis du sletter ressursen, slettes identiteten.
  • Bruk av flere ressurser (forskjellige nettapper i forskjellige områder) vil resultere i flere identiteter som må administreres separat (hver identitet vil ha sine egne profiler).

På grunn av de ovennevnte vurderingene anbefaler vi at du bruker en brukertilordet administrert identitet.

Eksempel

Hvis du vil ha et eksempel på hvordan du bruker tjenestekontohaverprofiler til å administrere et flertenantmiljø med Innebygging av Power BI og App-Owns-Data, kan du laste ned appen som eier datarepositoriet for flere enheter fra Power BI Dev Camp (tredjeparts nettsted).

Relatert innhold