Planlegging av Power BI-implementering: Sikkerhetsplanlegging for innholdsoppretter

Merk

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Denne serien fokuserer hovedsakelig på Power BI-arbeidsbelastningen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se Planlegging av Power BI-implementering.

Denne artikkelen om sikkerhetsplanlegging beskriver strategier for innholdsopprettere som er ansvarlige for å opprette semantiske modeller (tidligere kalt datasett), dataflyter, datamarts, rapporter eller instrumentbord. Det er primært rettet mot:

• Power BI-administratorer: Administratorene som er ansvarlige for å overvåke Power BI i organisasjonen.
• Center of Excellence- og IT- og BI-teamet: Teamene som også er ansvarlige for å overvåke Power BI. De må kanskje samarbeide med Power BI-administratorer, informasjonssikkerhetsteam og andre relevante team.
• Innholdsopprettere og eiere: Selvbetjente BI-opprettere som trenger å opprette, publisere, sikre og administrere innhold som andre bruker.

Serien med artikler er ment å utvide innholdet i power bi-sikkerhetsmeldingen. Selv om power BI-sikkerhetsmeldingen fokuserer på viktige tekniske emner som godkjenning, datalagring og nettverksisolasjon, er det primære målet med serien å gi deg hensyn og beslutninger som hjelper deg med å planlegge sikkerhet og personvern.

I en organisasjon er mange brukere innholdsopprettere. Innholdsopprettere produserer og publiserer innhold som vises av andre. Innholdsopprettere er i fokus i denne artikkelen.

Tips

Vi anbefaler at du ser gjennom artikkelen om planlegging av rapportforbrukersikkerhet først. Den beskriver strategier for sikker levering av innhold til skrivebeskyttede forbrukere, inkludert hvordan du håndhever datasikkerhet.

Strategi for innholdsopprettere

Grunnlaget for et velstyrt selvbetjent BI-system begynner med innholdsopprettere og eiere. De oppretter og validerer semantiske modeller og rapporter. I mange tilfeller har innholdsopprettere også konfigurert tillatelser til å administrere sikkerhet for innholdet.

Tips

Vi anbefaler at du fremmer en datakultur som gjør sikkerhet og beskyttelse av data til en normal del av alles rolle. For å oppnå dette målet er brukerutdanning, støtte og opplæring avgjørende.

Når det gjelder sikkerhet og tillatelser, bør du vurdere at det finnes to typer innholdsopprettere: dataopprettere og rapportopprettere. De kan være ansvarlige for å opprette og administrere enterprise BI eller selvbetjent BI-innhold .

Dataopprettere

En dataoppretter er alle Power BI-brukere som oppretter semantiske modeller, dataflyter eller datamarts.

Her er noen vanlige scenarioer for dataoppretter.

• Opprett en ny semantisk modell: Opprett og test en ny datamodell i Power BI Desktop. Den publiseres deretter til Power Bi-tjeneste slik at den kan brukes som en delt semantisk modell for mange rapporter. Hvis du vil ha mer informasjon om gjenbruk av delte semantiske modeller, kan du se det administrerte selvbetjente BI-bruksscenarioet .
• Utvide og tilpasse en semantisk modell: Opprett en live-tilkobling til en eksisterende delt semantisk modell i Power BI Desktop. Konverter live-tilkoblingen til en lokal modell, som gjør det mulig å utvide modellutformingen med nye tabeller eller kolonner. Hvis du vil ha mer informasjon om å utvide og tilpasse delte semantiske modeller, kan du se det tilpassbare administrerte selvbetjente BI-bruksscenarioet .
• Opprett en ny dataflyt: Opprett en ny dataflyt i Power Bi-tjeneste, slik at den kan brukes som en kilde av mange semantiske modeller. Hvis du vil ha mer informasjon om gjenbruk av dataforberedelsesaktiviteter, kan du se det selvbetjente dataforberedelsesbruksscenarioet .
• Opprett et nytt datamart. Opprett et nytt datamart i Power Bi-tjeneste.

Dataopprettere finnes ofte i enterprise BI-team og i Center of Excellence (COE). De har også en nøkkelrolle å spille i desentraliserte forretningsenheter og avdelinger som vedlikeholder og administrerer sine egne data.

Hvis du vil ha andre vurderinger om forretningsledet BI, administrert selvbetjent BI og enterprise BI, kan du se artikkelen om eierskap og administrasjon av innhold.

Rapportopprettere

Rapportopprettere oppretter rapporter og instrumentbord for å visualisere data som er hentet fra eksisterende semantiske modeller.

Her er noen vanlige scenarioer for rapportoppretter.

• Opprett en ny rapport, inkludert en datamodell: Opprett og test en ny rapport- og datamodell i Power BI Desktop. Power BI Desktop-filen som inneholder én eller flere rapportsider og inneholder en datamodell, publiseres til Power Bi-tjeneste. Nye innholdsopprettere bruker ofte denne metoden før de er klar over å bruke delte semantiske modeller. Det er også egnet for smale brukstilfeller som ikke har behov for gjenbruk av data.
• Opprett en direkte tilkoblingsrapport: Opprett en ny Power BI-rapport som kobler til en delt semantisk modell i Power Bi-tjeneste. Hvis du vil ha mer informasjon om gjenbruk av delte semantiske modeller, kan du se det administrerte selvbetjente BI-bruksscenarioet .
• Opprett en tilkoblet Excel-arbeidsbok: Opprett en ny Excel-rapport som kobler til en delt semantisk modell i Power Bi-tjeneste. Koble til excel-opplevelser, i stedet for nedlastinger av data, er svært oppmuntret.
• Opprett en DirectQuery-rapport: Opprett en ny Power BI-rapport som kobler til en støttet datakilde i DirectQuery-modus. Én situasjon når denne metoden er nyttig, er når du vil dra nytte av brukersikkerheten som implementeres av kildesystemet.

Rapportopprettere finnes i alle forretningsenheter i organisasjonen. Det finnes vanligvis mange flere rapportopprettere i en organisasjon enn dataopprettere.

Tips

Selv om ikke alle semantiske modeller er en delt semantisk modell, er det fortsatt verdt å ta i bruk en administrert selvbetjent BI-strategi . Denne strategien bruker delte semantiske modeller på nytt når det er mulig. På denne måten blir rapportoppretting og dataoppretting koblet fra. Enhver innholdsoppretter fra en hvilken som helst forretningsenhet kan effektivt bruke denne strategien.

Tillatelser for opprettere

Denne delen beskriver de vanligste tillatelsene for opprettere av data og rapportopprettere.

Denne delen er ikke ment å være en all-inclusive-liste over alle mulige tillatelser. Det er heller ment å hjelpe deg med å planlegge strategien din for å støtte ulike typer innholdsopprettere. Målet ditt bør være å følge prinsippet om minst mulig rettighet. Dette prinsippet gir brukere nok tillatelser til å være produktive, uten tillatelser for over klargjøring.

Opprette nytt innhold

Følgende tillatelser kreves vanligvis for å opprette nytt innhold.

Tillatelse	Rapportoppretter	Semantisk modelloppretter	Oppretter av dataflyt	Oppretter av Datamart
Tilgang til den underliggende datakilden
Lese- og bygg-tillatelser for semantisk modell
Lesetillatelse for dataflyt (når en dataflyt brukes som kilde, via rollen visningsprogram for arbeidsområdet)
Access der den opprinnelige Power BI Desktop-filen er lagret
Tillatelse til å bruke egendefinerte visualobjekter

Publisere innholdstillatelser

Følgende tillatelser kreves vanligvis for publisering av innhold.

Tillatelse	Rapportoppretter	Semantisk modelloppretter	Oppretter av dataflyt	Oppretter av Datamart
Arbeidsområderolle: Bidragsyter, medlem eller administrator
Skrivetillatelse for semantisk modell (når brukeren ikke tilhører en arbeidsområderolle)
Distribusjonssamlebåndrolle for publisering av elementer (valgfritt)

Oppdatere data

Følgende tillatelser kreves vanligvis for oppdatering av data.

Tillatelse	Rapportoppretter	Semantisk modelloppretter	Oppretter av dataflyt	Oppretter av Datamart
Eier tilordnet (som har konfigurert innstillinger eller overtatt elementet)
Tilgang til den underliggende datakilden (når en gateway ikke brukes)
Tilgang til datakilden i en gateway (når kilden er lokal eller i et virtuelt nettverk)

Resten av denne artikkelen beskriver vurderinger for innholdsopprettertillatelser.

Tips

Hvis du vil ha tillatelser relatert til visning av innhold, kan du se artikkelen om planlegging av rapportforbrukersikkerhet.

Sjekkliste – Når du planlegger sikkerhetsstrategien for innholdsopprettere, omfatter viktige beslutninger og handlinger:

• Bestem hvem dataoppretterne er: Sørg for at du er kjent med hvem som oppretter semantiske modeller, dataflyter og datamarts. Kontroller at du forstår hva deres behov er før du starter sikkerhetsplanleggingsaktivitetene.
• Bestem hvem rapportoppretterne er: Sørg for at du er kjent med hvem som oppretter rapporter, instrumentbord, arbeidsbøker og målstyringer. Kontroller at du forstår hva deres behov er før du starter sikkerhetsplanleggingsaktivitetene.

Oppdag innhold for opprettere

Brukere kan stole på dataoppdagelse for å finne semantiske modeller og datamarts. Dataoppdagelse er en Power BI-funksjon som gjør det mulig for innholdsopprettere å finne eksisterende dataressurser – selv når de ikke har noen tillatelser for innholdet.

Søk etter eksisterende data er nyttig for:

• Rapportopprettere som ønsker å bruke en eksisterende semantisk modell for en ny rapport.
• Rapportopprettere som ønsker å spørre etter data fra et eksisterende datamart.
• Semantiske modellopprettere som ønsker å bruke en eksisterende semantisk modell for en ny sammensatt modell.

Merk

Dataoppdagelse i Power BI er ikke en datasikkerhetstillatelse. Det er en innstilling som gjør det mulig for rapportopprettere å lese metadata, slik at de kan oppdage data og be om tilgang til dem.

Du kan konfigurere en semantisk modell eller datamart som synlig når den er godkjent (sertifisert eller forfremmet). Når det er synlig, kan innholdsopprettere finne det i datahuben.

En innholdsoppretter kan også be om tilgang til semantisk modell eller datamart. I hovedsak ber en tilgangsforespørsel om kompileringstillatelse, som kreves for å opprette nytt innhold basert på det. Når du svarer på forespørsler om tilgang, bør du vurdere å bruke grupper i stedet for individuelle brukere. Hvis du vil ha mer informasjon om hvordan du bruker grupper til dette formålet, kan du se Be om tilgangsarbeidsflyt for forbrukere.

Vurder følgende tre eksempler.

• Semantisk salgssammendragsmodell er sertifisert. Det er den klarerte og autoritative kilden for salgssporing. Mange selvbetjente rapportopprettere i hele organisasjonen bruker denne semantiske modellen. Så det finnes mange eksisterende rapporter og sammensatte modeller basert på den semantiske modellen. For å oppmuntre andre opprettere til å finne og bruke den semantiske modellen, er den angitt som synlig.
• Semantisk lagerstatistikkmodell er sertifisert. Det er en klarert og autoritativ kilde for lageranalyse. Semantisk modell og relaterte rapporter opprettholdes og distribueres av enterprise BI-teamet. På grunn av den komplekse utformingen av den semantiske modellen har bare enterprise BI-teamet tillatelse til å opprette og vedlikeholde lagerinnhold. Siden målet er å hindre rapportopprettere fra å bruke den semantiske modellen, er den ikke angitt som synlig.
• Executive Bonuses-semantiske modellen inneholder svært konfidensiell informasjon. Tillatelser til å vise eller oppdatere denne semantiske modellen er begrenset til noen få brukere. Denne semantiske modellen er ikke angitt som synlig.

Skjermbildet nedenfor viser en semantisk modell i datahuben i Power Bi-tjeneste. Nærmere bestemt viser den et eksempel på en forespørsel om tilgangsmelding for en synlig semantisk modell. Denne meldingen vises når brukeren ikke har tilgang. Forespørselstilgangsmeldingen er tilpasset i innstillingene for semantisk modell.

Forespørselstilgangsmeldingen lyder: For standard salgsrapportering av MTD/QTD/YTD er denne semantiske modellen den autoritative og sertifiserte kilden. Be om tilgang til den semantiske modellen ved å fylle ut skjemaet som er plassert på https://COE.contoso.com/RequestAccess. Du vil bli bedt om en kort forretningsmessig begrunnelse, og lederen av Center of Excellence vil bli pålagt å godkjenne forespørselen også. Access overvåkes hvert halvår.

Merk

Datakulturen og din holdning til datademokratisering bør ha stor innvirkning på om du aktiverer dataoppdagelse. Hvis du vil ha mer informasjon om dataoppdagelse, kan du se det tilpassbare, administrerte selvbetjente BI-bruksscenarioet .

Det finnes tre leierinnstillinger relatert til søk.

• Med innstillingen Oppdag innholdsleietaker kan Power BI-administratorer angi hvilke grupper med brukere som har tillatelse til å oppdage data. Det er først og fremst rettet mot rapportopprettere som kanskje må finne eksisterende semantiske modeller når de oppretter rapporter. Det er også nyttig for semantiske modellopprettere som kan se etter eksisterende data som de kan bruke i sin sammensatte modellutvikling. Selv om det er mulig å angi det for bestemte sikkerhetsgrupper, er det lurt å aktivere innstillingen for hele organisasjonen. Søkeinnstillingen for individuelle semantiske modeller og dataflyter kontrollerer hva som kan oppdages. Mindre vanlig kan du vurdere å begrense denne funksjonen bare til godkjente innholdsopprettere.
• Med innstillingen Gjør sertifisert innhold synlig for leier kan Power BI-administratorer angi hvilke grupper som kan angi at innhold skal kunne oppdages (når de også har tillatelse til å redigere elementet, samt tillatelse til å sertifisere innhold, som gis av innstillingen for sertifiseringsleier). Muligheten til å sertifisere innhold bør kontrolleres tett. I de fleste tilfeller bør de samme brukerne som har tillatelse til å sertifisere innhold, ha tillatelse til å angi det som synlig. I enkelte situasjoner vil du kanskje begrense denne funksjonen bare til godkjente dataopprettere.
• Med innstillingen Gjør forfremmet innhold synlig for leier kan Power BI-administratorer angi hvilke grupper som kan angi innholdet som synlig (når de også har tillatelse til å redigere dataene). Siden muligheten til å heve innhold er åpen for alle innholdsopprettere, bør denne funksjonen i de fleste tilfeller være tilgjengelig for alle brukere. Mindre vanlig kan du vurdere å begrense denne funksjonen til bare godkjente innholdsopprettere.

Sjekkliste – Når du planlegger dataoppdagelse for innholdsoppretterne, omfatter viktige beslutninger og handlinger:

• Klargjør behov for dataoppdagelse: Vurder hva organisasjonens posisjon er når det gjelder å oppmuntre innholdsopprettere til å finne eksisterende semantiske modeller og datamarts. Når det er aktuelt, oppretter du en styringspolicy for hvordan dataoppdagelse skal brukes.
• Bestem hvem som kan oppdage innhold: Bestem om en Power BI-bruker har tillatelse til å oppdage innhold, eller om søk skal begrenses til bestemte brukergrupper (for eksempel en gruppe godkjente innholdsopprettere). Angi innstillingen for Discover-innholdsleietakeren slik at den samsvarer med denne beslutningen.
• Bestem hvem som kan angi at sertifisert innhold skal kunne oppdages: Bestem om en Power BI-bruker (som har tillatelse til å redigere semantisk modell eller datamart, samt tillatelse til å sertifisere det) kan angi det som synlig. Angi innstillingen For å gjøre sertifisert innhold synlig for tenanten slik at den samsvarer med denne beslutningen.
• Bestem hvem som kan angi at forfremmet innhold skal kunne oppdages: Bestem om en Power BI-bruker (som har tillatelse til å redigere semantisk modell eller datamart) kan angi det som synlig. Angi innstillingen For å gjøre forfremmet innhold synlig for leier for å samsvare med denne beslutningen.
• Inkluder i dokumentasjon og opplæring for semantiske modellopprettere: Inkluder veiledning for semantiske modellopprettere om når det er riktig å bruke dataoppdagelse for semantiske modeller og datamarts de eier og administrerer.
• Inkluder i dokumentasjon og opplæring for rapportopprettere: Inkluder veiledning for innholdsopprettere om hvordan dataoppdagelse fungerer, og hva de kan forvente.

Be om tilgangsarbeidsflyt for opprettere

En bruker kan be om tilgang til innhold på to måter.

• For innholdsforbrukere: En bruker mottar en kobling til en eksisterende rapport eller app i Power Bi-tjeneste. Hvis du vil vise elementet, kan forbrukeren velge Be om tilgang-knappen . Hvis du vil ha mer informasjon, kan du se artikkelen om planlegging av rapportforbrukersikkerhet.
• For innholdsopprettere: Brukeren oppdager en semantisk modell eller datamart i datahuben. Hvis du vil opprette en ny rapport eller sammensatt modell basert på eksisterende data, kan innholdsoppretteren velge Be om tilgang-knappen . Denne opplevelsen er fokus for denne inndelingen.

Som standard går en forespørsel om tilgang til en semantisk modell eller et datamart til eieren. Eieren er brukeren som sist planla dataoppdatering eller inndatalegitimasjon. Det kan være akseptabelt å bruke én bruker til å behandle tilgangsforespørsler for semantiske modeller for teamet. Det kan imidlertid ikke være praktisk eller pålitelig.

I stedet for å stole på én eier, kan du definere egendefinerte instruksjoner som presenteres for brukere når de ber om tilgang til en semantisk modell eller datamart. Egendefinerte instruksjoner er nyttige når:

• Den semantiske modellen er angitt som synlig.
• Godkjenning av tilgangsforespørselen utføres av andre enn eieren av dataene.
• Det finnes en eksisterende prosess som må følges for tilgangsforespørsler.
• Sporing av hvem som ba om tilgang, når og hvorfor er nødvendig for revisjons- eller samsvarsårsaker.
• Forklaring er nødvendig for hvordan du ber om tilgang, og for å angi forventninger.

Skjermbildet nedenfor viser et eksempel på hvordan du konfigurerer egendefinerte instruksjoner som en bruker ser når de ber om kompileringstillatelse. De egendefinerte instruksjonene lyder: For standard salgsrapportering av MTD/QTD/YTD er denne semantiske modellen den autoritative og sertifiserte kilden. Be om tilgang til den semantiske modellen ved å fylle ut skjemaet som er plassert på https://COE.contoso.com/RequestAccess. Du vil bli bedt om en kort forretningsmessig begrunnelse, og lederen av Center of Excellence vil bli pålagt å godkjenne forespørselen også. Access overvåkes hvert halvår.

Det finnes mange alternativer for å opprette et skjema. Power Apps og Microsoft Forms er begge lavkodede, brukervennlige alternativer. Vi anbefaler at du oppretter et skjema på en måte som er uavhengig av én enkelt bruker. Det er avgjørende at skjemaet opprettes, administreres og overvåkes av det riktige teamet.

Vi anbefaler at du oppretter nyttig informasjon for:

• Innholdsopprettere slik at de vet hva de kan forvente når de ber om tilgang.
• Innholdseiere og administratorer slik at de vet hvordan de skal behandle forespørsler som sendes inn.

Tips

Hvis du vil ha mer informasjon om å svare på forespørsler om lesetilgang fra forbrukere, kan du se Be om tilgangsarbeidsflyt for forbrukere. Den inneholder også informasjon om bruk av grupper (i stedet for individuelle brukere).

Sjekkliste – Når du planlegger arbeidsflyten for forespørselstilgang , omfatter viktige beslutninger og handlinger:

• Klargjør preferanser for hvordan du håndterer tilgangsforespørsler: Bestem hvilke situasjoner det er akseptabelt for eiergodkjenning, og når en annen prosess skal brukes. Når det er aktuelt, oppretter du en styringspolicy for hvordan tilgangsforespørsler skal håndteres.
• Inkluder i dokumentasjon og opplæring for semantiske modell- og datamartopprettere: Inkluder veiledning for semantiske modeller og datamartopprettere om hvordan og når du skal angi egendefinerte instruksjoner for tilgangsforespørsler.
• Inkluder i dokumentasjon og opplæring for rapportopprettere: Inkluder veiledning for rapportopprettere om hva de kan forvente når de ber om kompileringstillatelser for semantiske modeller og datamarts.

Opprette og publisere innhold

Denne delen inneholder sikkerhetsaspekter som gjelder for innholdsopprettere.

Merk

For forbrukere som viser rapporter, instrumentbord og målstyringer, kan du se artikkelen om planlegging av rapportforbrukersikkerhet. Vurderinger relatert til apptillatelser dekkes også i denne artikkelen.

Arbeidsområderoller

Du gir arbeidsområdetilgang ved å legge til brukere eller grupper (inkludert sikkerhetsgrupper, Microsoft 365-grupper og distribusjonslister) i arbeidsområderoller. Hvis du tilordner brukere til arbeidsområderoller, kan du angi hva de kan gjøre med arbeidsområdet og innholdet.

Merk

Hvis du vil ha mer informasjon om vurderinger for planlegging av arbeidsområder, kan du se planleggingsartiklene for arbeidsområdet. Hvis du vil ha mer informasjon om grupper, kan du se artikkelen om sikkerhetsplanlegging på leiernivå.

Fordi hovedformålet med et arbeidsområde er samarbeid, er arbeidsområdetilgang for det meste relevant for brukerne som eier og administrerer innholdet. Når du begynner å planlegge for arbeidsområderoller, er det nyttig å stille deg selv følgende spørsmål.

• Hva er forventningene til hvordan samarbeid skjer i arbeidsområdet?
• Hvem vil være ansvarlig for å administrere innholdet i arbeidsområdet?
• Er det meningen å tilordne individuelle brukere eller grupper til arbeidsområderoller?

Det finnes fire roller i Power BI-arbeidsområdet: Administrator, Medlem, Bidragsyter og Seer. De tre første rollene er relevante for innholdsopprettere, som oppretter og publiserer innhold. Seer-rollen er relevant for skrivebeskyttede forbrukere.

De fire rolletillatelsene for arbeidsområdet er nestet. Det betyr at administratorer for arbeidsområdet har alle funksjonene som er tilgjengelige for medlemmer, bidragsytere og brukere. På samme måte har medlemmene alle funksjonene som er tilgjengelige for bidragsytere og seere. Bidragsytere har alle funksjonene som er tilgjengelige for brukere.

Tips

Se dokumentasjonen for arbeidsområderoller for den autoritative referansen for hver av de fire rollene.

Arbeidsområdeadministrator

Brukere som er tilordnet administratorrollen, blir administratorer for arbeidsområdet. De kan administrere alle innstillinger og utføre alle handlinger, inkludert å legge til eller fjerne brukere (inkludert andre administratorer for arbeidsområdet).

Administratorer for arbeidsområdet kan oppdatere eller slette Power BI-appen (hvis det finnes). De kan eventuelt tillate bidragsytere å oppdatere appen for arbeidsområdet. Hvis du vil ha mer informasjon, kan du se Variasjoner i arbeidsområderoller senere i denne artikkelen.

Tips

Når du henviser til en administrator, må du passe på å klargjøre om du snakker om en administrator for arbeidsområdet eller en administrator på leiernivå i Power BI.

Pass på at bare klarerte og pålitelige personer er administratorer for arbeidsområdet. En administrator for arbeidsområdet har høye rettigheter. De har tilgang til å vise og administrere alt innhold i arbeidsområdet. De kan legge til og fjerne brukere (inkludert andre administratorer) i en hvilken som helst arbeidsområderolle. De kan også slette arbeidsområdet.

Vi anbefaler at det finnes minst to administratorer, slik at én fungerer som en sikkerhetskopi hvis den primære administratoren ikke er tilgjengelig. Et arbeidsområde som ikke har en administrator, kalles et frittstående arbeidsområde. Den frittstående statusen oppstår når en bruker forlater organisasjonen og det ikke er tilordnet en alternativ administrator til arbeidsområdet. Hvis du vil ha mer informasjon om hvordan du oppdager og korrigerer frittstående arbeidsområder, kan du se artikkelen Vis arbeidsområder.

Ideelt sett bør du kunne finne ut hvem som er ansvarlig for arbeidsområdeinnholdet av hvem administratorer og medlemmer av arbeidsområdet er (og kontaktene som er angitt for arbeidsområdet). Noen organisasjoner bruker imidlertid en strategi for eierskap og administrasjon av innhold som begrenser oppretting av arbeidsområder til bestemte brukere eller grupper. De har vanligvis en etablert arbeidsområdeopprettelsesprosess som administreres av IT-avdelingen. I dette tilfellet vil administratorene for arbeidsområdet være IT-avdelingen i stedet for brukerne som oppretter og publiserer innholdet direkte.

Arbeidsområdemedlem

Brukere som er tilordnet medlemsrollen, kan legge til andre brukere av arbeidsområdet (men ikke administratorer). De kan også administrere tillatelser for alt innhold i arbeidsområdet.

Medlemmer av arbeidsområdet kan publisere eller oppheve publiseringen av appen for arbeidsområdet, dele et arbeidsområdeelement eller appen og la andre brukere dele arbeidsområdeelementer i appen.

Medlemmer av arbeidsområdet bør være begrenset til brukerne som trenger å administrere oppretting av arbeidsområdeinnhold og publisere appen. I noen tilfeller oppfyller arbeidsområdeadministratorene dette formålet, så det kan hende du ikke trenger å tilordne brukere eller grupper til medlemsrollen. Når administratorer for arbeidsområdet ikke er direkte relatert til arbeidsområdeinnholdet (for eksempel fordi IT administrerer opprettingsprosessen for arbeidsområdet), kan medlemmene av arbeidsområdet være de sanne eierne som er ansvarlige for innholdet i arbeidsområdet.

Bidragsyter for arbeidsområde

Brukere som er tilordnet bidragsyterrollen, kan opprette, redigere eller slette arbeidsområdeinnhold.

Bidragsytere kan ikke oppdatere Power BI-appen (når den finnes for arbeidsområdet) med mindre det er tillatt av innstillingen for arbeidsområdet. Hvis du vil ha mer informasjon, kan du se Variasjoner i arbeidsområderoller senere i denne artikkelen.

De fleste innholdsopprettere i organisasjonen er bidragsytere for arbeidsområdet.

Visningsprogram for arbeidsområde

Brukere som er tilordnet til Seer-rollen, kan vise og samhandle med alt arbeidsområdeinnhold.

Seer-rollen er relevant for skrivebeskyttede forbrukere for små team og uformelle scenarioer. Den er fullstendig beskrevet i artikkelen om planlegging av forbrukersikkerhet i rapporten.

Vurderinger for eierskap av arbeidsområder

Vurder et eksempel der følgende handlinger utføres for å konfigurere et nytt arbeidsområde.

1. Bestemte Power BI-mestere og satellittmedlemmer av Center of Excellence (COE) har fått tillatelse i leierinnstillingene til å opprette nye arbeidsområder. De har fått opplæring i strategier for innholdsorganisasjoner og navnestandarder.
2. Du (en innholdsoppretter) sender inn en forespørsel om å opprette et arbeidsområde for et nytt prosjekt som du skal administrere. Arbeidsområdet inneholder rapporter som sporer fremdriften for prosjektet.
3. En Power BI-mester for forretningsenheten mottar forespørselen. De finner ut at et nytt arbeidsområde er berettiget. Deretter oppretter de et arbeidsområde og tilordner sikkerhetsgruppen Power BI-mestere (for forretningsenheten) til administratorrollen for arbeidsområdet.
4. Power BI-mesteren tilordner deg (innholdsoppretteren) til medlemsrollen for arbeidsområdet.
5. Du tilordner en klarert kollega til medlemsrollen for arbeidsområdet for å sikre at det finnes en sikkerhetskopi hvis du er borte.
6. Du tilordner andre kolleger til rollen som bidragsyter for arbeidsområdet fordi de er ansvarlige for å opprette arbeidsområdeinnholdet, inkludert semantiske modeller og rapporter.
7. Du tilordner lederen til rollen som visningsprogram for arbeidsområdet fordi de har bedt om tilgang til å overvåke fremdriften til prosjektet. Din overordnede vil se gjennom innhold i arbeidsområdet før du publiserer en app.
8. Du tar ansvar for å administrere andre egenskaper for arbeidsområdet, for eksempel beskrivelse og kontakter. Du tar også ansvar for å administrere arbeidsområdetilgang kontinuerlig.

Det forrige eksemplet viser en effektiv måte å gi en desentralisert forretningsenhet muligheten til å handle uavhengig av hverandre. Det viser også prinsippet om minst privilegium.

For styrt innhold eller kritisk innhold som er tettere administrert, er det en anbefalt fremgangsmåte å tilordne grupper i stedet for individuelle brukerkontoer til arbeidsområderoller. På den måten kan du administrere gruppemedlemskapet separat fra arbeidsområdet. Når du tilordner grupper til roller, er det imidlertid mulig at brukere blir tilordnet flere arbeidsområderoller (fordi brukeren tilhører flere grupper). I så fall er deres effektive tillatelser basert på den høyeste rollen de er tilordnet til. Hvis du vil ha mer informasjon, kan du se Strategi for bruk av grupper.

Når et arbeidsområde eies av flere personer eller team, kan det gjøre administrasjon av innholdet komplisert. Prøv å unngå scenarioer for eierskap med flere team ved å skille ut arbeidsområder. På den måten er ansvarsområder klare, og rolletildelinger er enkle å konfigurere.

Variasjoner i arbeidsområderoller

Det finnes to variasjoner i de fire arbeidsområderollene (beskrevet tidligere).

• Som standard er det bare administratorer og medlemmer av arbeidsområdet som kan opprette, publisere og oppdatere appen for arbeidsområdet. Tillat bidragsytere å oppdatere appalternativet for denne innstillingen for arbeidsområdet er en innstilling på arbeidsområdenivå, som lar administratorer av arbeidsområdet delegere muligheten til å oppdatere appen for arbeidsområdet til bidragsytere. Bidragsytere kan imidlertid ikke publisere en ny app eller endre hvem som har tillatelse til å redigere den. Denne innstillingen er nyttig når du vil at bidragsytere skal kunne oppdatere appen (når den finnes for arbeidsområdet), men ikke gi de andre tillatelsene som er tilgjengelige for medlemmer.
• Innstillingen For blokkpublisering og deaktiver leierinnstilling for pakkeoppdatering tillater bare semantiske modelleiere å publisere oppdateringer. Når det er aktivert, kan ikke administratorer, medlemmer og bidragsytere i arbeidsområdet publisere endringer med mindre de først overtar den semantiske modellen som eier. Fordi denne innstillingen gjelder for hele organisasjonen, kan du aktivere den med et mål av forsiktighet fordi den påvirker alle semantiske modeller for leieren. Pass på å kommunisere til de semantiske modelloppretterne hva du kan forvente, fordi det endrer normal virkemåte for arbeidsområderoller.

Viktig

Tillatelser per element kan også betraktes som en overstyring av standard arbeidsområderoller. Hvis du vil ha mer informasjon om tillatelser per element, kan du se artikkelen om planlegging av rapportforbrukersikkerhet.

Sjekkliste – Når du planlegger arbeidsområderoller, omfatter viktige beslutninger og handlinger:

• Opprett en ansvarsmatrise: Tilordne hvem som forventes å håndtere hver funksjon når du oppretter, vedlikeholder, publiserer, sikrer og støtter innhold. Bruk denne informasjonen når du planlegger arbeidsområderollene.
• Bestem deg for strategien for å tilordne arbeidsområderoller for innholdsopprettere: Bestem hvilke brukere som skal være administrator, medlem eller bidragsyter, og under hvilke omstendigheter (for eksempel jobbrolle eller emneområde). Hvis det er uoverensstemmelser som forårsaker et sikkerhetsproblem, kan du revurdere hvordan arbeidsområdene kan organiseres bedre.
• Bestem hvordan sikkerhetsgrupper kontra enkeltpersoner skal brukes til arbeidsområderoller: Bestem brukstilfeller og formål du må bruke grupper. Vær spesifikk om når sikkerhet skal brukes ved hjelp av brukerkontoer kontra når en gruppe kreves eller foretrekkes.
• Gi veiledning for innholdsopprettere om administrasjon av arbeidsområderoller: Inkluder dokumentasjon for innholdsopprettere om hvordan du administrerer arbeidsområderoller. Publiser denne informasjonen i den sentraliserte portalen og opplæringsmateriellet.
• Konfigurere og teste rolletildelinger for arbeidsområder: Kontroller at innholdsopprettere har den funksjonaliteten de trenger for redigering og publisering av innhold.

Appopprettertillatelser

Innholdsopprettere som er administratorer eller medlemmer av arbeidsområdet, kan opprette og publisere en Power BI-app.

En arbeidsområdeadministrator kan også angi en innstilling i arbeidsområdet som gjør det mulig for bidragsytere i arbeidsområdet å oppdatere appen. Det er en variasjon i sikkerhet for arbeidsområderolle fordi det gir bidragsytere en annen tillatelse de normalt ikke ville hatt. Denne innstillingen angis per arbeidsområde.

Tips

Hvis du vil ha mer informasjon om hvordan du leverer innhold til skrivebeskyttede forbrukere, kan du se artikkelen om planlegging av rapportforbrukersikkerhet. Denne artikkelen inneholder informasjon om apptillatelser for appforbrukere, inkludert målgrupper for appen.

Sjekkliste – Når du planlegger for appopprettertillatelser, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien din for hvem som kan opprette og publisere Power BI-apper: Klargjør hvem som skal ha tillatelse til å opprette og publisere Power BI-apper.
• Bestem når bidragsytere kan oppdatere Power BI-apper: Avklar situasjonene når en bidragsyter skal få lov til å oppdatere Power BI-apper. Oppdater innstillingen for arbeidsområdet når denne funksjonen er nødvendig.

Datakildetillatelser

Når en dataoppretter starter et nytt prosjekt, er tillatelser som kreves for å få tilgang til eksterne datakilder, en av de første sikkerhetsrelaterte vurderingene. De kan også trenge veiledning om andre datakilderelaterte forhold, inkludert personvernnivåer, opprinnelige databasespørringer og egendefinerte koblinger.

Tilgang til datakilde

Når en dataoppretter oppretter en semantisk modell, dataflyt eller datamart, må de godkjenne med datakilder for å hente data. Godkjenning innebærer vanligvis brukerlegitimasjon (konto og passord), som kan være for en tjenestekonto.

Noen ganger er det nyttig å opprette bestemte tjenestekontoer for tilgang til datakilder. Ta kontakt med IT-avdelingen for å få veiledning om hvordan tjenestekontoer skal brukes i organisasjonen. Når de er tillatt, kan bruk av tjenestekontoer:

• Sentraliser tillatelser som kreves for datakilder.
• Reduser antall individuelle brukere som trenger tillatelser til en datakilde.
• Unngå dataoppdateringsfeil når en bruker forlater organisasjonen.

Tips

Hvis du velger å bruke tjenestekontoer, anbefaler vi at du kontrollerer hvem som har tilgang til legitimasjonen. Roter passord regelmessig (for eksempel hver tredje måned) eller når noen som har tilgang, forlater organisasjonen.

Når du får tilgang til datakilder, bruker du prinsippet om minst mulig rettighet for å sikre at brukere (eller tjenestekontoer) har tillatelse til å lese bare dataene de trenger. De skal aldri ha tillatelse til å utføre dataendringer. Databaseadministratorer som oppretter disse tjenestekontoene, bør spørre om forventede spørringer og arbeidsbelastninger og utføre tiltak for å sikre at tilstrekkelige optimaliseringer (for eksempel indekser) og ressurser er på plass.

Tips

Hvis det er vanskelig å gi direkte datakildetilgang til selvbetjente dataopprettere, kan du vurdere å bruke en indirekte tilnærming. Du kan opprette dataflyter i Power Bi-tjeneste og tillate selvbetjente dataopprettere å hente data fra dem. Denne fremgangsmåten har de ekstra fordelene ved å redusere spørringsbelastningen på datakilden og levere et konsekvent øyeblikksbilde av data. Hvis du vil ha mer informasjon, kan du se selvbetjent dataforberedelse og avanserte dataforberedelsesbruksscenarioer .

Legitimasjonen (konto og passord) kan brukes på én av to måter.

• Power BI Desktop: Legitimasjonen krypteres og lagres lokalt på brukermaskinen.
• Power Bi-tjeneste: Legitimasjonen krypteres og lagres sikkert for begge:
  • Semantisk modell (når en datagateway ikke er i bruk for å nå datakilden).
  • Gateway-datakilden (når en standard gateway eller en virtuell nettverksgatewaytjeneste er i bruk for å nå datakilden).

Tips

Når du allerede har angitt legitimasjon for en semantisk modelldatakilde, binder Power Bi-tjeneste automatisk denne legitimasjonen til andre datakilder for semantisk modell når det er et nøyaktig samsvar med tilkoblingsstreng- og databasenavn. Både Power Bi-tjeneste og Power BI Desktop får det til å se ut som om du skriver inn legitimasjon for hver datakilde. Den kan imidlertid bruke samme legitimasjon på samsvarende datakilder som har samme eier. I så måte er semantisk modelllegitimasjon begrenset til eieren.

Legitimasjon krypteres og lagres separat fra datamodellen i både Power BI Desktop og Power Bi-tjeneste. Denne dataseparasjonen har følgende sikkerhetsfordeler.

• Det forenkler gjenbruk av legitimasjon for flere semantiske modeller, dataflyter og datamarts.
• Når noen analyserer metadataene til en semantisk modell, kan de ikke trekke ut legitimasjonen.
• I Power BI Desktop kan ikke en annen bruker koble til den opprinnelige datakilden for å oppdatere data uten først å bruke legitimasjonen.

Noen datakilder støtter enkel pålogging (SSO), som kan angis når du skriver inn legitimasjon i Power Bi-tjeneste (for semantisk modell eller gateway-datakilder). Når du aktiverer SSO, sender Power BI legitimasjonen til den godkjente brukeren til datakilden. Dette alternativet gjør det mulig for Power BI å overholde sikkerhetsinnstillingene som er konfigurert i datakilden, for eksempel sikkerhet på radnivå. SSO er spesielt nyttig når tabeller i datamodellen bruker DirectQuery-lagringsmodus.

Personvernnivåer

Datavernnivåer angir isoleringsnivåer som definerer i hvilken grad én datakilde er isolert fra andre datakilder. Når de er riktig angitt, sikrer de at Power Query bare overfører kompatible data mellom kilder. Når Power Query kan overføre data mellom datakilder, kan det føre til mer effektive spørringer som reduserer datavolumet som sendes til Power BI. Når det ikke kan overføre data mellom datakilder, kan det føre til lavere ytelse.

Det finnes tre personvernnivåer.

• Privat: Inneholder sensitive eller konfidensielle data som må isoleres fra alle andre datakilder. Dette nivået er det mest restriktive. Private datakildedata kan ikke deles med andre datakilder. En personaldatabase som inneholder ansattes lønnsverdier, bør for eksempel settes til privat personvernnivå.
• Organisasjonsmessig: Isolert fra offentlige datakilder, men er synlig for andre organisatoriske datakilder. Dette nivået er det vanligste. Data for organisasjonsdata kan deles med private datakilder eller andre organisatoriske datakilder. De fleste interne driftsdatabaser kan angis med organisasjonens personvernnivå.
• Offentlig: Ikke-sensitive data som kan gjøres synlige for alle datakilder. Dette nivået er minst restriktivt. Offentlige datakildedata kan deles med andre datakilder. En folketellingsrapport hentet fra et offentlig nettsted kan for eksempel settes til offentlig personvernnivå.

Når du kombinerer spørringer fra ulike datakilder, er det viktig at du angir riktige personvernnivåer. Når personvernnivåene er riktig angitt, er det mulig at data fra én datakilde overføres til en annen datakilde for effektiv spørring av data.

Vurder et scenario der en semantisk modelloppretter har to datakilder: en Excel-arbeidsbok og en tabell i en Azure SQL Database. De ønsker å filtrere dataene i Tabellen Azure SQL Database ved hjelp av en verdi som er hentet fra Excel-arbeidsboken. Den mest effektive måten Power Query kan generere en SQL-setning for Azure SQL Database på, er å bruke en WHERE-setningsdel for å utføre den nødvendige filtreringen. SQL-setningen vil imidlertid inneholde et WHERE-setningspredikat med en verdi som er hentet fra Excel-arbeidsboken. Hvis Excel-arbeidsboken inneholder sensitive data, kan det representere et sikkerhetsbrudd fordi databaseadministratoren kan vise SQL-setningen ved hjelp av et sporingsverktøy. Selv om det er mindre effektivt, er alternativet at Power Query-nettflettingsmotoren laster ned hele resultatsettet i databasetabellen og utfører selve filtreringen i Power Bi-tjeneste. Denne tilnærmingen vil være mindre effektiv og treg, men sikker.

Personvernnivåer kan angis for hver datakilde:

• Av datamodellerere i Power BI Desktop.
• Av semantiske modelleiere i Power Bi-tjeneste (for skydatakilder, som ikke krever en gateway).
• Av gateway-datakildeopprettere og eiere i Power Bi-tjeneste (for gateway-datakilder).

Viktig

Personvernnivåene du angir i Power BI Desktop, overføres ikke til Power Bi-tjeneste.

Det finnes et sikkerhetsalternativ for Power BI Desktop som gjør det mulig å ignorere personvernnivåer for å forbedre ytelsen. Du kan bruke dette alternativet til å forbedre spørringsytelsen mens du utvikler en datamodell når det ikke er noen risiko for brudd på datasikkerhet (fordi du arbeider med utvikling eller test data som ikke er følsomme). Denne innstillingen er imidlertid ikke beæret av Power Bi-tjeneste.

Hvis du vil ha mer informasjon, kan du se Personvernnivåer for Power BI Desktop.

Opprinnelige databasespørringer

Hvis du vil opprette effektive Power Query-spørringer, kan du bruke en opprinnelig spørring til å få tilgang til data. En opprinnelig spørring er en setning skrevet på et språk som støttes av datakilden. Opprinnelige spørringer støttes bare av bestemte datakilder, som vanligvis er relasjonelle databaser som Azure SQL Database.

Opprinnelige spørringer kan utgjøre en sikkerhetsrisiko fordi de kan kjøre en ondsinnet SQL-setning. En ondsinnet setning kan utføre dataendringer eller slette databaseposter (når brukeren har de nødvendige tillatelsene i datakilden). Derfor krever opprinnelige spørringer som standard brukergodkjenning for å kjøre i Power BI Desktop.

Det finnes et sikkerhetsalternativ for Power BI Desktop som lar deg deaktivere kravet om forhåndsgodkjenning. Vi anbefaler at du forlater standardinnstillingen som krever brukergodkjenning, spesielt når du forventer at Power BI Desktop-filen kan oppdateres av andre brukere.

Egendefinerte koblinger

Utviklere kan bruke Power Query SDK til å opprette egendefinerte koblinger. Egendefinerte koblinger gir tilgang til proprietære datakilder eller implementerer spesifikk godkjenning med egendefinerte datautvidelser. Noen egendefinerte koblinger er sertifisert og distribuert av Microsoft som sertifiserte koblinger. Sertifiserte koblinger er revidert og gjennomgått for å sikre at de oppfyller bestemte angitte kodekrav som Microsoft har testet og godkjent.

Det finnes et sikkerhetsalternativ for power BI Desktop-datautvidelse som begrenser bruken av ikke-sertifiserte koblinger. Som standard utløses en feil når det gjøres et forsøk på å laste inn en ikke-sertifisert kobling. Ved å angi dette alternativet for å tillate ikke-sertifiserte koblinger lastes egendefinerte koblinger inn uten validering eller advarsel.

Vi anbefaler at du holder sikkerhetsnivået for datautvidelsen på høyere nivå, noe som hindrer innlasting av ikke-sertifisert kode. Det kan imidlertid være tilfeller der du vil laste inn bestemte koblinger, kanskje koblinger som du har utviklet, eller koblinger som leveres til deg av en klarert konsulent eller leverandør utenfor Microsofts sertifiseringsbane.

Merk

Utviklere av innebygde utviklede koblinger kan utføre trinn for å signere en kobling med et sertifikat, slik at du kan bruke koblingen uten å måtte endre sikkerhetsinnstillingene. Hvis du vil ha mer informasjon, kan du se Klarerte tredjepartskoblinger.

Sjekkliste – Når du planlegger datakildetillatelser, omfatter viktige beslutninger og handlinger:

• Bestem hvem som har direkte tilgang til hver datakilde: Bestem hvilke dataopprettere som har tillatelse til å få tilgang til en datakilde direkte. Hvis det finnes en strategi for å redusere antall personer med direkte tilgang, kan du klargjøre hva det foretrukne alternativet er (kanskje ved hjelp av dataflyter).
• Bestem hvordan datakilder skal åpnes: Bestem om individuell brukerlegitimasjon skal brukes til å få tilgang til en datakilde, eller om en tjenestekonto skal opprettes for dette formålet. Bestem når enkel pålogging er riktig.
• Gi veiledning for semantiske modellopprettere om tilgang til datakilder: Inkluder dokumentasjon for innholdsopprettere om hvordan du får tilgang til organisatoriske datakilder. Publiser informasjonen i den sentraliserte portalen og opplæringsmateriellet.
• Gi veiledning for semantiske modellopprettere om personvernnivåer: Gi veiledning til semantiske modellopprettere for å gjøre dem oppmerksomme på personvernnivåer og deres implikasjoner når de arbeider med sensitive eller konfidensielle data. Publiser denne informasjonen i den sentraliserte portalen og opplæringsmateriellet.
• Gi veiledning for opprettere av gateway-tilkobling om personvernnivåer: Gi veiledning til semantiske modellopprettere for å gjøre dem oppmerksomme på personvernnivåer og deres implikasjoner når de arbeider med sensitive eller konfidensielle data. Publiser denne informasjonen i den sentraliserte portalen og opplæringsmateriellet.
• Bestem deg for strategien for bruk av opprinnelige databasespørringer: Vurder strategien for å bruke opprinnelige databasespørringer. Lær semantiske modellopprettere om hvordan og når du skal angi alternativet for opprinnelige databasespørringer i Power BI Desktop for å deaktivere forhåndsgodkjenning når Power Query kjører opprinnelige spørringer.
• Bestem deg for strategien for bruk av egendefinerte koblinger: Vurder strategien for å bruke egendefinerte koblinger. Bestem om bruken av ikke-sertifiserte koblinger er berettiget, i så fall lære opp semantiske modellopprettere om hvordan og når du skal angi alternativet for power BI Desktop-datautvidelse.

Tillatelser for semantisk modelloppretter

Du kan tilordne tillatelse til å redigere en semantisk modell til en bruker eller gruppe på forskjellige måter.

• Arbeidsområderolle: Tildeling til en av arbeidsområderollene gir tilgang til alle semantiske modeller i arbeidsområdet. Muligheten til å vise eller redigere en eksisterende semantisk modell avhenger av arbeidsområderollen du tilordner. Administratorer, medlemmer og bidragsytere kan publisere eller redigere innhold i et arbeidsområde.
• Tillatelseskoblinger per element: Hvis en delingskobling ble opprettet for en rapport, gis også tillatelse til å lese den semantiske modellen (og eventuelt bygge, skrive og/eller dele på nytt) indirekte av koblingen.
• Direkte tilgangstillatelser per element: Du kan tilordne direkte tilgangstillatelse til en bestemt semantisk modell.

Legg merke til tillatelsene som er tilordnet til semantisk modell for data i anropssenteret , i skjermbildet nedenfor. Én bruker har lesetillatelse, som ble gitt ved hjelp av direkte tilgangstillatelser per element. De gjenværende brukerne og gruppene har tillatelser fordi de er tilordnet til arbeidsområderoller.

Tips

Bruk av tillatelser per element (koblinger eller direkte tilgang) fungerer best når hensikten er at en bruker eller gruppe skal kunne vise eller redigere ett bestemt element i arbeidsområdet. Det passer best når brukeren ikke har tilgang til alle elementer i arbeidsområdet. I de fleste tilfeller anbefaler vi at du utformer arbeidsområdene slik at sikkerheten er enklere å administrere med arbeidsområderoller. Unngå å angi tillatelser per element når det er mulig.

Semantiske modelltillatelser

Du kan tilordne følgende semantiske modelltillatelser.

• Les: Denne tillatelsen er hovedsakelig rettet mot rapportforbrukere, og gir en rapport mulighet til å spørre etter data i den semantiske modellen. Hvis du vil ha mer informasjon om tillatelser for visning av skrivebeskyttet innhold, kan du se artikkelen om planlegging av rapportforbrukersikkerhet.
• Bygg: Denne tillatelsen er rettet mot rapportopprettere, slik at brukere kan opprette nye rapporter basert på den delte semantiske modellen. Hvis du vil ha mer informasjon, kan du se inndelingen Rapportopprettertillatelser senere i denne artikkelen.
• Skriv: Denne tillatelsen er rettet mot semantiske modellopprettere som oppretter, publiserer og administrerer semantiske modeller, slik at brukere kan redigere den semantiske modellen. Det er beskrevet senere i denne delen.
• Del på nytt: Denne tillatelsen er rettet mot alle med eksisterende tillatelse til den semantiske modellen, slik at brukere kan dele den semantiske modellen med en annen bruker. Det er beskrevet senere i denne delen.

En administrator eller medlem av arbeidsområdet kan redigere tillatelsene for en semantisk modell.

Lesetillatelse for semantisk modell

Lesetillatelsen for semantisk modell er primært rettet mot forbrukere. Denne tillatelsen kreves for at brukere skal kunne vise data som vises i rapporter. Vær oppmerksom på at rapporter basert på den semantiske modellen også må ha lesetillatelse. Ellers lastes ikke rapporten inn. Hvis du vil ha mer informasjon om hvordan du angir lesetillatelser for rapporten, kan du se artikkelen om planlegging av rapportforbrukersikkerhet.

Kompileringstillatelse for semantisk modell

I tillegg til lesetillatelse for semantisk modell, trenger innholdsopprettere også tillatelsen for semantisk modellbygg. Nærmere bestemt gjør kompileringstillatelsen det mulig for rapportopprettere å:

• Opprett nye Power BI-rapporter basert på semantisk modell.
• Koble til til semantisk modell ved hjelp avAnalyser i Excel.
• Spør den semantiske modellen ved hjelp av XMLA-endepunktet.
• Eksporter underliggende data for power BI-rapportvisualobjekt (i stedet for de summerte dataene som hentes av visualobjektet).
• Opprett en DirectQuery-tilkobling til en semantisk Power BI-modell. I dette tilfellet kobler den nye semantiske modellen til én eller flere eksisterende Semantiske Power BI-modeller (kjent som kjeder). Hvis du vil spørre kjedede semantiske modeller, trenger den semantiske modelloppretteren kompileringstillatelse for alle oppstrøms semantiske modeller. Hvis du vil ha mer informasjon, kan du se Kjedede semantiske modeller senere i denne artikkelen.

Du kan gi kompileringstillatelse til en bruker eller gruppe, direkte eller indirekte, på forskjellige måter.

• Gi bygg direkte etter:
  • Angi semantiske modelltillatelser på siden for semantiske modellinnstillinger i Power Bi-tjeneste.
  • Angi semantiske modelltillatelser ved hjelp av REST-API-en for Power BI.
• Gi bygg indirekte av:
  • Dele en rapport eller et instrumentbord og angi alternativet for å gi semantisk modell build-tillatelse.
  • Publisere en Power BI-app og angi det avanserte alternativet (for en målgruppe) for å gi kompileringstillatelse på relaterte semantiske modeller.
  • Tilordne brukere til rollene administrator, medlem eller bidragsyterarbeidsområde.

Det er riktig å angi kompileringstillatelse direkte for en semantisk modell når du vil administrere sikkerhet på en detaljert basis per element. Angivelse av kompileringstillatelse er indirekte passende når brukerne som skal vise eller bruke innholdet gjennom en av de indirekte metodene, også oppretter nytt innhold.

Tips

Ofte er brukerne som viser en rapport eller en Power BI-app forskjellig fra brukerne som oppretter nytt innhold ved hjelp av de underliggende semantiske modellene. De fleste forbrukere er bare seere, så de trenger ikke å opprette nytt innhold. Vi anbefaler at du lærer opp innholdsoppretterne til å gi det minste antallet tillatelser som kreves.

Skrivetillatelse for semantisk modell

Vanligvis vil det å angi tillatelser for hvem som kan redigere og administrere semantiske modeller, gjøres ved å tilordne brukere til rollen som administrator, medlem eller bidragsyterarbeidsområde. Det er imidlertid også mulig å angi skrivetillatelse for en bestemt semantisk modell.

Vi anbefaler at du bruker arbeidsområderoller når det er mulig, fordi det er den enkleste måten å administrere og overvåke tillatelser på. Bruk skrivetillatelsene for semantisk modell per element når du har valgt å opprette færre arbeidsområder, og et arbeidsområde inneholder semantiske modeller for ulike emneområder som krever forskjellige tillatelsesadministrasjoner.

Tips

Hvis du vil ha veiledning om hvordan du organiserer arbeidsområder, kan du se artikler om planlegging av arbeidsområder.

Semantic model Reshare-tillatelse

Den semantiske modellen Reshare tillatelse tillater en bruker med eksisterende tillatelse til å dele semantisk modell med andre brukere. Du kan gi denne tillatelsen når innhold i semantisk modell kan deles fritt, basert på brukerens skjønn.

I mange tilfeller anbefaler vi at du begrenser bruken av tillatelsen For å sikre at semantiske modelltillatelser kontrolleres nøye. Få godkjenning fra de semantiske modelleierne før du gir tillatelsen Tildel på nytt.

Datasikkerhet for semantisk modell

Du kan planlegge å opprette færre semantiske modeller og rapporter ved å fremtvinge datasikkerhet. Målet er å fremtvinge datasikkerhet basert på identiteten til brukeren som viser innholdet.

En semantisk modelloppretter kan fremtvinge datasikkerhet på to måter.

• Sikkerhet på radnivå (RLS) gjør det mulig for en datamodellerer å begrense tilgangen til et delsett med data.
• Sikkerhet på objektnivå (OLS) gjør det mulig for en datamodellerer å begrense tilgangen til bestemte tabeller og kolonner og metadataene deres.

Implementeringen av RLS og OLS er rettet mot rapportforbrukere. Hvis du vil ha mer informasjon, kan du se artikkelen om planlegging av forbrukersikkerhet for rapport. Den beskriver hvordan og når RLS og OLS håndheves for forbrukere som bare har visningstillatelse til den semantiske modellen.

Hvis du vil ha RLS og OLS rettet mot andre rapportopprettere, kan du se datasikkerhet i delen Rapportopprettertillatelser senere i denne artikkelen.

Kjedede semantiske modeller

Semantiske Modeller for Power BI kan koble til andre semantiske modeller i en prosess som kalles kjede, som er tilkoblinger til oppstrøms semantiske modeller. Hvis du vil ha mer informasjon, kan du se Bruke DirectQuery for Semantiske Modeller og Analysis Services for Power BI.

Med leierinnstillingen Tillat DirectQuery-tilkoblinger til Semantiske modeller for Power BI kan Power BI-administratorer konfigurere hvilke grupper av innholdsopprettere som kan opprette kjedede semantiske modeller. Hvis du ikke vil begrense semantiske modellopprettere fra å kjede semantiske modeller, kan du la denne innstillingen være aktivert for hele organisasjonen og stole på tilgang til arbeidsområdet og semantiske modelltillatelser. I noen tilfeller kan du vurdere å begrense denne funksjonen til godkjente innholdsopprettere.

Merk

Som en semantisk modelloppretter kan du begrense kjeder til den semantiske modellen. Det gjøres ved å aktivere Discourage DirectQuery-tilkoblingen til dette semantiske modellalternativet i Power BI Desktop. Hvis du vil ha mer informasjon, kan du se Administrere DirectQuery-tilkoblinger til en publisert semantisk modell.

API-spørringer for semantisk modell

I enkelte situasjoner vil du kanskje kjøre en DAX-spørring ved hjelp av REST-API-en for Power BI. Du kan for eksempel utføre valideringer av datakvalitet. Hvis du vil ha mer informasjon, kan du se Datasett – Kjøre spørringer.

Innstillingen rest-API-leier for datasett utfører spørringer, gjør det mulig for Power BI-administratorer å angi hvilke grupper av brukere som kan sende DAX-spørringer ved hjelp av REST-API-en for Power BI. I de fleste tilfeller kan du la denne innstillingen være aktivert for hele organisasjonen og stole på tilgang til arbeidsområdet og semantiske modelltillatelser. I noen tilfeller kan du vurdere å begrense denne funksjonen til godkjente innholdsopprettere.

Sjekkliste – Når du planlegger for semantiske modellopprettertillatelser, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for semantiske modellopprettertillatelser: Bestem hvilke preferanser og krav som finnes for administrasjon av sikkerhet for semantiske modellopprettere. Vurder emneområdet og nivået for datafølsomhet. Vurder også hvem som har lov til å ta ansvar for å administrere data og tillatelser i sentraliserte og desentraliserte forretningsenheter.
• Se gjennom hvordan arbeidsområderoller håndteres for semantiske modellopprettere: Bestem hva som har innvirkning på utformingsprosessen for arbeidsområdet. Opprett separate dataarbeidsområder for hvert emneområde, slik at du lettere kan administrere arbeidsområderollene og semantisk modellsikkerhet for hvert emneområde.
• Gi veiledning for semantiske modellopprettere om administrasjon av tillatelser: Inkluder dokumentasjon for semantiske modellopprettere om hvordan du administrerer semantiske modelltillatelser. Publiser denne informasjonen i den sentraliserte portalen og opplæringsmateriellet.
• Bestem hvem som kan bruke DirectQuery-tilkoblinger for Semantiske Power BI-modeller: Bestem om det skal være noen begrensninger for hvilke power BI semantiske modellopprettere (med eksisterende build-tillatelse for en semantisk modell) kan opprette en tilkobling til en Semantisk Power BI-modell. Angi leierinnstillingen Tillat DirectQuery-tilkoblinger til semantiske modeller for Power BI for å justere denne beslutningen. Hvis du bestemmer deg for å begrense denne funksjonaliteten, bør du vurdere å bruke en gruppe, for eksempel Power BI-godkjente semantiske modellopprettere.
• Bestem hvem som kan spørre Power BI-semantiske modeller ved hjelp av REST-API-en: Bestem om du vil begrense Power BI-innholdsopprettere fra å spørre Power BI-semantiske modeller ved hjelp av POWER BI REST-API-en. Angi innstillingen rest-API-leier for datasettkjøringsspørringer slik at den samsvarer med denne beslutningen. Hvis du bestemmer deg for å begrense denne funksjonen, kan du vurdere å bruke en gruppe, for eksempel Power BI-godkjente rapportopprettere.
• Bestem deg for strategien for bruk av RLS eller OLS for semantiske modellopprettere: Vurder hvilke brukstilfeller og formål du har tenkt å bruke RLS eller OLS. Faktor i utformingsstrategien for arbeidsområdet, og hvem som har lese- og redigeringstillatelser, når du vil fremtvinge RLS eller OLS for semantiske modellopprettere.

Tillatelser for rapportoppretter

Rapportopprettere trenger arbeidsområdetilgang for å opprette rapporter i Power Bi-tjeneste eller publisere dem fra Power BI Desktop. De må være enten administrator, medlem eller bidragsyter i målarbeidsområdet.

Når det er mulig, bør rapportopprettere bruke en eksisterende delt semantisk modell (via en live-tilkobling eller DirectQuery). På den måten kobles rapportopprettingsprosessen fra den semantiske modellopprettingsprosessen. Denne typen separasjon gir mange fordeler for sikkerhets- og teamutviklingsscenarioer.

En rapportoppretter må være administrator for arbeidsområdet, medlem eller bidragsyter.

I motsetning til semantiske modeller finnes det ingen skrivetillatelse for rapporter. Arbeidsområderoller må brukes for å støtte rapportopprettere. Derfor er optimal utforming av arbeidsområdet viktig for å balansere organisasjons- og sikkerhetsbehov for innhold.

Tips

Hvis du vil ha tillatelser til å støtte rapportforbrukere (inkludert lese- og delingstillatelser per element), kan du se artikkelen om planlegging av rapportforbrukersikkerhet.

Lese- og byggtillatelser for underliggende semantisk modell

Rapportopprettere må ha lese- og byggtillatelser på semantiske modeller som rapportene deres vil bruke, som inkluderer kjedede semantiske modeller. Denne tillatelsen kan gis eksplisitt på de individuelle semantiske modellene, eller den kan gis implisitt for semantiske modeller for arbeidsområdet når rapportoppretteren er administrator for arbeidsområdet, medlem eller bidragsyter.

Med innstillingen Bruk semantiske modeller på tvers av leierinnstillinger for arbeidsområder kan Power BI-administratorer konfigurere hvilke grupper av brukere som kan opprette rapporter som bruker semantiske modeller i andre arbeidsområder. Denne innstillingen er rettet mot semantiske modell- og rapportopprettere. Vanligvis anbefaler vi at du lar denne innstillingen være aktivert for hele organisasjonen og er avhengig av tilgangsinnstillinger for arbeidsområdet og semantiske modelltillatelser. På den måten kan du oppmuntre til bruk av eksisterende semantiske modeller. I noen tilfeller kan du vurdere å begrense denne funksjonen bare til godkjente innholdsopprettere.

Det finnes også leierinnstillingen Tillat live-tilkoblinger , som gjør det mulig for Power BI-administratorer å konfigurere hvilke grupper av brukere som kan opprette live-tilkoblinger til semantiske modeller i Power BI Desktop eller Excel. Det er spesielt rettet mot rapportopprettere, og det krever også at de får lese- og byggtillatelse på den semantiske modellen som rapporten skal bruke. Vi anbefaler at du lar denne innstillingen være aktivert for hele organisasjonen og er avhengig av tilgang til arbeidsområdet og semantiske modelltillatelser. På den måten kan du oppmuntre til bruk av eksisterende semantiske modeller. I noen tilfeller kan du vurdere å begrense denne funksjonen bare til godkjente innholdsopprettere.

Datasikkerhet for underliggende semantisk modell

RLS og OLS (beskrevet tidligere i denne artikkelen) er rettet mot rapportforbrukere. Noen ganger må det imidlertid også håndheves for rapportopprettere. Oppretting av separate arbeidsområder er berettiget når RLS må håndheves for rapportopprettere og også rapportere forbrukere.

Tenk deg følgende scenario.

• Sentraliserte delte semantiske modeller med RLS: Enterprise BI-teamet publiserte semantiske modeller for salg til salgsdataarbeidsområdet . Disse semantiske modellene fremtvinger RLS for å vise salgsdata for det tilordnede salgsområdet til rapportforbrukeren.
• Desentraliserte selvbetjente rapportopprettere: Forretningsenheten for salg og markedsføring har mange dyktige analytikere som oppretter sine egne rapporter. De publiserer rapportene sine til salgsanalysearbeidsområdet .
• Lese- og byggtillatelser for semantiske modeller: Når det er mulig, bruker analytikerne semantiske modeller fra salgsdataarbeidsområdet for å unngå unødvendig duplisering av data. Fordi analytikerne bare har tillatelsen Lese og bygg på disse semantiske modellene (uten tillatelser for skriving eller redigering), håndheves RLS for rapportoppretterne (og også rapportforbrukerne).
• Rediger tillatelser for arbeidsområdet for rapportering: Analytikerne har flere rettigheter i arbeidsområdet for salgsanalyse . Rollene administrator, medlem eller bidragsyterarbeidsområder gjør det mulig for dem å publisere og administrere rapportene sine.

Hvis du vil ha mer informasjon om RLS og OLS, kan du se artikkelen om planlegging av forbrukersikkerhet for rapporter. Den beskriver hvordan og når RLS og OLS håndheves for forbrukere som bare har visningstillatelse til den semantiske modellen.

Koble til til eksterne semantiske modeller

Når en rapportoppretter kobler til en delt semantisk modell for rapporten, kobler de vanligvis til en delt semantisk modell som er publisert i sin egen Power BI-leier. Når tillatelse er gitt, er det også mulig å koble til en delt semantisk modell i en annen leier. Den andre leieren kan være en partner, kunde eller leverandør.

Denne funksjonaliteten kalles semantisk modelldeling på stedet (også kjent som semantisk deling på tvers av leier). Rapportene som opprettes av rapportoppretteren (eller nye sammensatte modeller opprettet av en semantisk modelloppretter), lagres og sikres i Power BI-leieren ved hjelp av den normale prosessen. Den opprinnelige, delte semantiske modellen forblir i den opprinnelige Power BI-leieren, og alle tillatelser administreres der.

Hvis du vil ha mer informasjon, kan du se artikkelen om sikkerhetsplanlegging på leiernivå. Den inneholder informasjon om leierinnstillinger og innstillinger for semantisk modell som får ekstern deling til å fungere.

Utvalgte tabeller

I Power BI Desktop kan semantiske modellopprettere angi en modelltabell til å bli en utvalgt tabell. Når den semantiske modellen publiseres til Power Bi-tjeneste, kan rapportopprettere bruke datatypegalleriet i Excel til å finne den utvalgte tabellen, slik at de kan legge til utvalgte tabelldata for å utvide Excel-regnearkene.

Med leierinnstillingen Tillat tilkoblinger til utvalgte tabeller kan Power BI-administratorer konfigurere hvilke grupper av brukere som har tilgang til utvalgte tabeller. Den er rettet mot Excel-brukere som ønsker å få tilgang til utvalgte Power BI-tabeller i Excel-organisasjonsdatatyper. Vi anbefaler at du lar denne innstillingen være aktivert for hele organisasjonen og er avhengig av tilgang til arbeidsområdet og semantiske modelltillatelser. På den måten kan du oppmuntre til bruk av utvalgte tabeller.

Egendefinerte visualobjekttillatelser

I tillegg til kjernevisualobjekter kan rapportopprettere i Power BI bruke egendefinerte visualobjekter. Egendefinerte visualobjekter kan lastes ned fra Microsoft AppSource i Power BI Desktop. De kan også utvikles internt ved hjelp av Power BI SDK, og installeres ved å åpne den visuelle filen (PBVIZ).

Noen visualobjekter som er tilgjengelige for nedlasting fra AppSource, er sertifiserte visualobjekter. Sertifiserte visualobjekter oppfyller bestemte angitte kodekrav som Power BI-teamet har testet og godkjent. Testene kontrollerer at visualobjekter ikke får tilgang til eksterne tjenester eller ressurser.

Med innstillingen Tillat visualobjekter som er opprettet av Power BI SDK-tenanten , kan Power BI-administratorer kontrollere hvilke grupper av brukere som kan bruke egendefinerte visualobjekter.

Det finnes også leierinnstillingen Legg til og bruk bare sertifiserte visualobjekter, som gjør det mulig for Power BI-administratorer å blokkere bruken av ikke-sertifiserte visualobjekter i Power Bi-tjeneste. Denne innstillingen kan aktiveres eller deaktiveres for hele organisasjonen.

Merk

Hvis du blokkerer bruken av ikke-sertifiserte visualobjekter, gjelder det bare for Power Bi-tjeneste. Hvis du vil begrense bruken i Power BI Desktop, kan du be systemansvarlige om å bruke en gruppepolicyinnstilling til å blokkere bruken i Power BI Desktop. Hvis du tar dette trinnet, sikrer du at rapportopprettere ikke kaster bort tid og krefter på å opprette en rapport som ikke fungerer når de publiseres til Power Bi-tjeneste. Vi anbefaler på det sterkeste at du konfigurerer brukerne til å ha konsekvente opplevelser i Power Bi-tjeneste (med leierinnstillingen) og Power BI Desktop (med gruppepolicy).

Power BI Desktop har et alternativ for å vise en sikkerhetsadvarsel når en rapportoppretter legger til et egendefinert visualobjekt i rapporten. Rapportopprettere kan deaktivere dette alternativet. Dette alternativet tester ikke om visualobjektet er sertifisert.

Power BI-administratorer kan godkjenne og distribuere egendefinerte visualobjekter for organisasjonen. Rapportopprettere kan deretter enkelt oppdage, oppdatere og bruke disse visualobjektene. Administratorer kan deretter administrere disse visualobjektene ved å oppdatere versjoner eller deaktivere og aktivere bestemte egendefinerte visualobjekter. Denne fremgangsmåten er nyttig når du vil gjøre et internt utviklet visualobjekt tilgjengelig for rapportoppretterne, eller når du skaffer deg et egendefinert visualobjekt fra en leverandør som ikke er i AppSource. Hvis du vil ha mer informasjon, kan du se Power BI-visualobjekter for organisasjoner.

Vurder en balansert strategi for å aktivere bare sertifiserte egendefinerte visualobjekter i organisasjonen (med leierinnstillingen og gruppepolicyen som tidligere er beskrevet), mens du distribuerer organisatoriske visualobjekter for å håndtere eventuelle unntak.

Sjekkliste – Når du planlegger for rapportopprettertillatelser, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for rapportopprettertillatelser: Bestem hvilke preferanser og krav som finnes for administrasjon av sikkerhet for rapportopprettere. Vurder emneområdet og nivået for datafølsomhet. Vurder også hvem som har lov til å ta ansvar for å opprette og administrere rapporter i sentraliserte og desentraliserte forretningsenheter.
• Se gjennom hvordan arbeidsområderoller håndteres for rapportopprettere: Bestem hva som har innvirkning på utformingsprosessen for arbeidsområdet. Opprett separate dataarbeidsområder og rapporteringsarbeidsområder for hvert emneområde, slik at arbeidsområderollene (og den underliggende semantiske modellsikkerheten) forenkles for emneområdet.
• Gi veiledning for rapportopprettere om administrasjon av tillatelser: Inkluder dokumentasjon for rapportopprettere om hvordan du administrerer tillatelser for rapportforbrukere. Publiser denne informasjonen i den sentraliserte portalen og opplæringsmateriellet.
• Bestem hvem som kan bruke delte semantiske modeller: Bestem om det skal være noen begrensninger for hvilke Power BI-rapportopprettere (som allerede har lese- og byggtillatelser for en semantisk modell) kan bruke semantiske modeller på tvers av arbeidsområder. Angi innstillingen Bruk semantiske modeller på tvers av leierinnstillingene for arbeidsområder for å samsvare med denne beslutningen. Hvis du bestemmer deg for å begrense denne funksjonen, kan du vurdere å bruke en gruppe, for eksempel Power BI-godkjente rapportopprettere.
• Bestem hvem som kan bruke live-tilkoblinger: Bestem om det skal være noen begrensninger for hvilke Power BI-rapportopprettere (som allerede har lese- og byggtillatelse for en semantisk modell) kan bruke live-tilkoblinger. Angi leierinnstillingen Tillat live-tilkoblinger slik at den samsvarer med denne beslutningen. Hvis du bestemmer deg for å begrense denne funksjonen, kan du vurdere å bruke en gruppe, for eksempel Power BI-godkjente rapportopprettere.
• Bestem deg for strategien for bruk av RLS for rapportopprettere: Vurder hvilke brukstilfeller og formål du har tenkt å bruke sikkerhet på radnivå. Faktor i utformingsstrategien for arbeidsområdet for å sikre at RLS håndheves for rapportopprettere.
• Bestem deg for strategien for bruk av egendefinerte visualobjekter: Vurder strategien som rapportopprettere kan bruke egendefinerte visualobjekter for. Angi innstillingene for Tillat visualobjekter som er opprettet av Power BI SDK-tenanten, slik at de samsvarer med denne beslutningen. Opprett en prosess for bruk av organisatoriske visualobjekter når det er aktuelt.

Tillatelser for oppretting av dataflyt

Dataflyter er nyttige for sentralisering av dataforberedelser , slik at arbeidet som gjøres i Power Query, ikke gjentas på tvers av mange semantiske modeller. De er en byggestein for å oppnå en enkelt kilde til sannhet, og hindrer analytikere i å kreve direkte tilgang til kilder, og for å bidra til å utføre ekstraherings-, transformerings- og belastningsoperasjoner (ETL) i stor skala.

En dataflytoppretter må være administrator for arbeidsområdet, medlem eller bidragsyter.

Hvis du vil bruke en dataflyt (for eksempel fra en ny datamodell opprettet i Power BI Desktop eller i et annet arbeidsområde), kan en semantisk modelloppretter tilhøre en hvilken som helst arbeidsområderolle, inkludert Seer-rollen. Det finnes ikke noe konsept for RLS for dataflyter.

I tillegg til arbeidsområderoller må tenantinnstillingen Opprett og bruk av dataflyter være aktivert. Denne leierinnstillingen gjelder for hele organisasjonen.

Tenk deg følgende scenario.

• Mange semantiske modeller i organisasjonen må håndheve dynamisk RLS. Det krever at brukerhovednavn (UPN-er) lagres i den semantiske modellen (for å filtrere etter identiteten til rapportforbrukeren).
• En dataflytoppretter, som tilhører personalavdelingen, oppretter en dataflyt av gjeldende ansattdetaljer, inkludert DERES UPN-er. De konfigurerer dataflyten slik at den oppdateres daglig.
• Semantiske modellopprettere bruker deretter dataflyten i modellutformingene for å konfigurere RLS.

Hvis du vil ha mer informasjon om hvordan du bruker dataflyter, kan du se de selvbetjente dataforberedelses - og avanserte bruksscenarioene for dataforberedelser .

Sjekkliste – Når du planlegger oppretting av dataflyttillatelser, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for opprettertillatelser for dataflyt: Bestem hvilke preferanser og krav som finnes for administrasjon av sikkerhet for dataflytopprettere. Vurder hvem som har tillatt, eller oppfordret, å ta ansvar for å administrere dataforberedelsesaktiviteter i sentraliserte og desentraliserte forretningsenheter.
• Bestem hvem som kan opprette dataflyter: Bestem om det skal være noen begrensninger for hvilke Power BI-dataopprettere som kan opprette dataflyter. Angi leierinnstillingen Opprett og bruk dataflyter til å samsvare med denne beslutningen.
• Se gjennom hvordan arbeidsområderoller håndteres for opprettere av dataflyter: Bestem hva som har innvirkning på utformingsprosessen for arbeidsområdet. Opprett separate dataflytarbeidsområder per emneområde, slik at du kan håndtere arbeidsområderoller og tillatelser separat for hvert emneområde, når det er aktuelt.

Opprettertillatelser for Datamart

Et datamart er en selvbetjent analyseløsning som gjør det mulig for brukere å lagre og utforske data som er lastet inn i en fullstendig administrert relasjonsdatabase. Den består også av en automatisk generert semantisk modell.

Datamarts gir en enkel lavkodeopplevelse for å innta data fra forskjellige datakilder, og for å trekke ut, transformere og laste inn (ETL) dataene ved hjelp av Power Query Online. Dataene lastes inn i en Azure SQL Database som er fullstendig administrert og krever ingen justering eller optimalisering. Den automatisk genererte semantiske modellen synkroniseres alltid med den administrerte databasen fordi den er i DirectQuery-modus.

Du kan opprette et datamart når du enten er administrator for arbeidsområdet, medlem eller bidragsyter. Arbeidsområderoller tilordnes også til roller på databasenivå i Azure SQL Database (men fordi databasen er fullstendig administrert, kan ikke brukertillatelser redigeres eller administreres i relasjonsdatabasen).

Med leierinnstillingen Opprett datamarts kan Power BI-administratorer konfigurere hvilke grupper av brukere som kan opprette datamarts.

Datamart-deling

For datamarts får termdelingen en betydning som er forskjellig fra andre Power BI-innholdstyper. Vanligvis er en delingsoperasjon rettet mot en forbruker fordi den gir skrivebeskyttet tillatelse til ett element, for eksempel en rapport.

Deling av et datamart er rettet mot innholdsopprettere (i stedet for forbrukere). Det gir tillatelsene Lese og bygg, som gjør det mulig for brukere å spørre enten den semantiske modellen eller relasjonsdatabasen, avhengig av hva de foretrekker.

Hvis du deler et datamart, kan innholdsopprettere:

• Bygg innhold ved hjelp av den automatisk genererte semantiske modellen: Den semantiske modellen er det semantiske laget som Power BI-rapporter kan bygges på. De fleste rapportopprettere bør bruke semantisk modell.
• Koble til til og spør Azure SQL Database: Relasjonsdatabasen er nyttig for innholdsopprettere som ønsker å opprette nye semantiske modeller eller paginerte rapporter. De kan skrive strukturerte spørringsspråkspørringer (SQL) for å hente data ved hjelp av SQL-endepunktet.

Sikkerhet på radnivå for Datamart

Du kan definere RLS for datamarts for å begrense datatilgang for angitte brukere. RLS er konfigurert i redigeringsprogrammet for datamart i Power Bi-tjeneste, og brukes automatisk på den automatisk genererte semantiske modellen og Azure SQL Database (som sikkerhetsregler).

Uansett hvordan en bruker velger å koble til datamart (til semantisk modell eller database), håndheves identiske RLS-tillatelser.

Sjekkliste – Når du planlegger opprettertillatelser for datamart, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for opprettertillatelser for datamart: Bestem hvilke preferanser og krav som finnes for administrasjon av sikkerhet for opprettere av datamart. Vurder hvem som har tillatt, eller oppfordret, å ta ansvar for å administrere data i sentraliserte og desentraliserte forretningsenheter.
• Bestem hvem som kan opprette datamarts: Bestem om det skal være noen begrensninger for hvilke Power BI-dataopprettere som kan opprette et datamart. Angi leierinnstillingen Opprett datamarts til å samsvare med denne beslutningen. Hvis du bestemmer deg for å begrense hvem som kan opprette datamarts, kan du vurdere å bruke en gruppe, for eksempel Power BI-godkjente datamartopprettere.
• Se gjennom hvordan arbeidsområderoller håndteres for opprettere av datamart: Finn ut hva innvirkningen er på utformingsprosessen for arbeidsområdet. Opprett separate dataarbeidsområder per emneområde, slik at arbeidsområderollene og semantisk modellsikkerhet kan forenkles for emneområdet.
• Gi veiledning for opprettere av datamart om administrasjon av tillatelser: Inkluder dokumentasjon for opprettere av datamart om hvordan du administrerer datamart-tillatelser. Publiser denne informasjonen i den sentraliserte portalen og opplæringsmateriellet.
• Bestem deg for strategien for å bruke RLS i datamarts: Vurder hvilke brukstilfeller og formål du har tenkt å bruke RLS i et datamart.

Opprettingstillatelser for målstyring

Med måledata i Power BI kan du kuratere bestemte måledata og spore dem mot viktige forretningsmål. Måledata legges til målstyringer, som kan deles med andre brukere og vises i én enkelt rute.

Målstyringer kan sikres med tre tillatelsesnivåer:

• Arbeidsområdet.
• Målstyringstillatelser (per element).
• Måledata (innenfor målstyringen).

En bruker som oppretter eller administrerer en målstyring, må være administrator for arbeidsområdet, medlem eller bidragsyter.

Siden måledata ofte strekker seg over flere emneområder, anbefaler vi at du oppretter et eget arbeidsområde, slik at du uavhengig kan administrere tillatelser for opprettere og forbrukere.

Med leierinnstillingen Opprett og bruk av metrikkdata kan Power BI-administratorer konfigurere hvilke grupper av brukere som kan opprette målstyringsmåledata.

Målstyringstillatelser

Du kan tilordne følgende målstyringstillatelser.

• Les: Denne tillatelsen gjør det mulig for en bruker å vise målstyringen.
• Del på nytt: Denne tillatelsen er rettet mot alle med eksisterende tillatelse til målstyringen, slik at brukere kan dele målstyringen med en annen bruker.

I samsvar med andre innholdstyper i Power Bi-tjeneste er tillatelsene per element nyttige når hensikten er å dele ett element med en annen bruker. Vi anbefaler at du bruker arbeidsområderoller og apptillatelser når det er mulig.

Tillatelser på metrisk nivå

Hver målstyring har et sett med tillatelser på metrisk nivå som du kan konfigurere i innstillingene for målstyring. Tillatelsene på metrisk nivå (innenfor en målstyring) kan gis forskjellig fra arbeidsområdet eller målstyringstillatelsene (per element).

Med rollene på metrisk nivå kan du angi:

• Hvem kan vise individuelle måledata på en målstyring.
• Hvem kan oppdatere individuelle måledata ved å:
  • Oppdaterer statusen under en innsjekking.
  • Legge til notater under en innsjekking.
  • Oppdaterer gjeldende verdi under en innsjekking.

Hvis du vil redusere nivået for fremtidig vedlikehold, er det mulig å angi standardtillatelser som skal arves av submetriske enheter du oppretter i fremtiden.

Sjekkliste – Når du planlegger for metriske opprettertillatelser, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for opprettertillatelser for målstyring: Bestem hvilke preferanser og krav som finnes for administrasjon av sikkerhet for målstyringsopprettere. Vurder hvem som har tillatt, eller oppfordret, å ta ansvar for å administrere data i sentraliserte og desentraliserte forretningsenheter.
• Bestem hvem som kan opprette målstyringer: Bestem om det skal være noen begrensninger for hvilke Power BI-dataopprettere som kan opprette målstyringer. Angi tenantinnstillingen Opprett og bruk måledata til å justere med denne beslutningen. Hvis du bestemmer deg for å begrense hvem som kan opprette målstyringer, bør du vurdere å bruke en gruppe, for eksempel Power BI-godkjente målstyringsopprettere.
• Se gjennom hvordan arbeidsområderoller håndteres for målstyringsopprettere: Bestem hva innvirkningen er på utformingsprosessen for arbeidsområdet. Vurder å opprette separate arbeidsområder for målstyringer når innholdet strekker seg over emneområder.
• Gi veiledning for målstyringsopprettere om administrasjon av tillatelser: Inkluder dokumentasjon for målstyringsopprettere om hvordan du administrerer tillatelser på metrisk nivå. Publiser denne informasjonen i den sentraliserte portalen og opplæringsmateriellet.

Publisere innhold

Denne delen inneholder emner relatert til publisering av innhold som er relevante for innholdsopprettere.

Arbeidsområder

Innholdsopprettere trenger administrator-, medlems- eller bidragsyterrolletilgang for å publisere innhold til et arbeidsområde. Hvis du vil ha mer informasjon, kan du se arbeidsområderollene som er beskrevet tidligere i denne artikkelen.

Bortsett fra personlig BI, bør innholdsopprettere oppfordres til å publisere innhold til standard arbeidsområder, i stedet for deres personlige arbeidsområde.

Innstillingen For blokkpublisering og deaktiver leier for pakkeoppdatering endrer virkemåten for publisering av semantiske modeller. Når det er aktivert, kan ikke administratorer, medlemmer eller bidragsytere for arbeidsområdet publisere endringer i en semantisk modell. Bare den semantiske modelleieren har lov til å publisere en oppdatering (tvinge overtakelsen av en semantisk modell før du publiserer en oppdatert semantisk modell). Fordi denne leierinnstillingen gjelder for hele organisasjonen, kan du aktivere den med et mål av forsiktighet fordi den påvirker alle semantiske modeller for hele leieren. Pass på å kommunisere til de semantiske modelloppretterne hva du kan forvente, fordi det endrer normal virkemåte for arbeidsområderoller.

Power Apps-synkronisering

Det er mulig å opprette en Power Apps-løsning som inkluderer innebygde Power BI-rapporter. Power Apps-prosessen oppretter automatisk et dedikert Power BI-arbeidsområde for lagring og sikring av Power BI-rapporter og semantiske modeller. Hvis du vil administrere elementer som finnes i både Power Apps og Power BI, finnes det en synkroniseringsprosess.

Prosessen synkroniserer sikkerhetsroller for å sikre at Power BI arver de samme rollene som opprinnelig ble konfigurert i Power Apps. Den gjør det også mulig for innholdsoppretteren å administrere tillatelser for hvem som kan vise Power BI-rapporter (og relaterte semantiske modeller) som er innebygd i en Power App.

Hvis du vil ha mer informasjon om synkronisering av Power Apps-roller med Power BI-arbeidsområderoller, kan du se Tillatelsessynkronisering mellom Power Apps-miljøet og Power BI-arbeidsområdet.

Tilgang til utrullingssamlebånd

Innholdsopprettere og eiere kan bruke Power BI-utrullingssamlebånd for selvbetjent innholdspublisering . Utrullingssamlebånd forenkler publiseringsprosessen og forbedrer kontrollnivået når du slipper nytt innhold.

Du administrerer datasamlebåndtillatelser (for brukere som kan distribuere innhold med et utrullingssamlebånd) separat fra arbeidsområderollene. Tilgang til både arbeidsområdet og utrullingssamlebåndet kreves for brukerne som utfører en distribusjon.

Innholdsopprettere kan også trenge:

• Opprettingstillatelser for arbeidsområde (når arbeidsområder må opprettes av datasamlebåndet).
• Kapasitetstillatelser for Premium eller Fabric (når arbeidsområder tilordnes av datasamlebåndet).

Viktig

Til tider refererer denne artikkelen til Power BI Premium eller dets kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft for øyeblikket konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.

Hvis du vil ha mer informasjon, kan du se Viktige oppdateringer som kommer til Power BI Premium-lisensiering og vanlige spørsmål om Power BI Premium.

Hvis du vil ha mer informasjon, kan du se Datasamlebåndtilgang for distribusjon.

XMLA-endepunkt

XMLA-endepunktet bruker XMLA-protokollen til å vise alle funksjonene i en tabelldatamodell, inkludert noen datamodelleringsoperasjoner som ikke støttes av Power BI Desktop. Du kan bruke TABULAR Object Model (TOM)-API-en til å gjøre programmatiske endringer i en datamodell.

XMLA-endepunktet gir også tilkobling. Du kan bare koble til en semantisk modell når arbeidsområdet har sin lisensmodus satt til Premium per bruker, Premium per kapasitet eller Embedded. Når en tilkobling er opprettet, kan et XMLA-kompatibelt verktøy fungere på datamodellen for å lese eller skrive data. Hvis du vil ha mer informasjon om hvordan du kan bruke XMLA-endepunktet til å administrere en semantisk modell, kan du se det avanserte bruksscenariet for datamodellbehandling .

Tilgang gjennom XMLA-endepunktet vil overholde eksisterende tillatelser. Administratorer for arbeidsområder, medlemmer og bidragsytere har implisitt skrivetillatelse for semantisk modell, noe som betyr at de kan distribuere nye semantiske modeller fra Visual Studio og kjøre TMSL-skript (Tabular Modeling Scripting Language) i SQL Server Management Studio (SSMS).

Brukere med tillatelsen semantisk modellbygg kan bruke XMLA-endepunktet til å koble til og bla gjennom semantiske modeller for dataforbruk og visualisering. RLS-regler overholdes, og brukere kan ikke se interne semantiske modellmetadata.

Tillat XMLA-endepunkter og Analyser i Excel med lokale semantiske modeller-leierinnstillingen refererer til to funksjoner: Den kontrollerer hvilke grupper av brukere som kan bruke XMLA-endepunktet til å spørre og/eller vedlikeholde semantiske modeller i Power Bi-tjeneste. Den bestemmer også om Analyser i Excel kan brukes med lokale SSAS-modeller (SQL Server Analysis Services).

Merk

Analyser i Excel-aspektet av denne leierinnstillingen gjelder bare for lokale SQL Server Analysis Services-modeller (SSAS). Standardanalyse i Excel-funksjonalitet, som kobles til en semantisk Power BI-modell i Power Bi-tjeneste, styres av leierinnstillingen Tillat direkte Koble til ions.

Publiser på nettet

Publiser på nettet er en funksjon som gir tilgang til Power BI-rapporter til alle på Internett. Det krever ikke godkjenning, og tilgang er ikke logget for overvåkingsformål. Fordi rapportforbrukere ikke trenger å tilhøre organisasjonen eller ha en Power BI-lisens, er denne teknikken godt egnet til datajournalistikk, en prosess der rapporter er innebygd i blogginnlegg, nettsteder, e-postmeldinger eller sosiale medier.

Forsiktig!

Publiser på nettet har potensial til å vise sensitive eller konfidensielle data, enten ved et uhell eller med vilje. Av denne grunn er denne funksjonen deaktivert som standard. Publiser på nett bør bare brukes for rapporter som inneholder data som kan vises av offentligheten.

Med innstillingen Publiser til nettleier kan Power BI-administratorer kontrollere hvilke grupper av brukere som kan publisere rapporter på nettet. Hvis du vil opprettholde et høyere kontrollnivå, anbefaler vi at du ikke inkluderer andre grupper i denne leierinnstillingen (for eksempel Power BI-administratorer eller andre typer innholdsopprettere). I stedet kan du fremtvinge spesifikk brukertilgang ved hjelp av en sikkerhetsgruppe, for eksempel offentlig publisering av Power BI. Kontroller at sikkerhetsgruppen er godt administrert.

Innebygging i egendefinerte apper

Med leierinnstillingen Bygg inn innhold i apper kan Power BI-administratorer kontrollere hvilke brukere som kan bygge inn Power BI-innhold utenfor Power Bi-tjeneste. Når du planlegger å bygge inn Power BI-innhold i egendefinerte programmer, aktiverer du denne innstillingen for bestemte grupper, for eksempel apputviklere.

Innebygging i PowerPoint

Med innstillingen Aktiver Power BI-tillegg for PowerPoint-leier kan Power BI-administratorer kontrollere hvilke brukere som kan bygge inn Power BI-rapportsider i PowerPoint-presentasjoner. Når det er aktuelt, kan du aktivere denne innstillingen for bestemte grupper, for eksempel rapportopprettere.

Merk

For at denne funksjonen skal fungere, må brukerne installere Power BI-tillegget for PowerPoint. Hvis du vil bruke tillegget, må brukerne enten ha tilgang til Office-tilleggslageret, eller tillegget må gjøres tilgjengelig for dem som et administrert administratortillegg. Hvis du vil ha mer informasjon, kan du se Power BI-tillegget for PowerPoint.

Lær rapportopprettere å være forsiktige med hvor de lagrer PowerPoint-presentasjoner og hvem de deler dem med. Det er fordi et bilde av visualobjektene i Power BI-rapporten vises for brukerne når de åpner presentasjonen. Dette bildet er tatt fra siste gang PowerPoint-filen ble koblet til. Bildet kan imidlertid utilsiktet vise data som den mottakende brukeren ikke har tillatelse til å se.

Merk

Bildet kan være nyttig når den mottakende brukeren ennå ikke har tillegget, eller før tillegget kobler til Power Bi-tjeneste for å hente data. Når brukeren kobler til, hentes bare data som brukeren kan se (fremtvinge RLS) fra Power BI.

Mal-apper

Malapper gjør det mulig for Power BI-partnere og programvareleverandører å bygge Power BI-apper med lite eller ingen koding, og distribuere dem til alle Power BI-kunder.

Leierinnstillingen publiser malapper gjør det mulig for Power BI-administratorer å kontrollere hvilke brukere som kan publisere malapper utenfor organisasjonen, for eksempel via Microsoft AppSource. For de fleste organisasjoner bør denne leierinnstillingen deaktiveres eller kontrolleres tett. Vurder å bruke en sikkerhetsgruppe, for eksempel opprettere av eksterne malapper for Power BI.

E-postabonnementer

Du kan abonnere på deg selv og andre i Power BI-rapporter, instrumentbord og paginerte rapporter. Power BI sender deretter en e-postmelding etter en tidsplan du angir. E-postmeldingen inneholder et øyeblikksbilde og en kobling til rapporten eller instrumentbordet.

Du kan opprette et abonnement som inkluderer andre brukere når du er administrator for arbeidsområdet, medlem eller bidragsyter. Hvis rapporten er i et Premium-arbeidsområde, kan du abonnere på grupper (enten de er i domenet eller ikke) og eksterne brukere. Når du konfigurerer abonnementet, er det også mulig å gi tillatelser til elementet. Direkte tilgangstillatelser per element brukes til dette formålet, som er beskrevet i artikkelen om planlegging av forbrukersikkerhet i rapporten.

Forsiktig!

Funksjonen for e-postabonnement har potensial til å dele innhold til interne og eksterne målgrupper. Når RLS håndheves på den underliggende semantiske modellen, genereres også vedlegg og bilder ved hjelp av sikkerhetskonteksten til brukeren som abonnerer.

Leierinnstillingen for e-postabonnementer gjør det mulig for Power BI-administratorer å kontrollere om denne funksjonen er aktivert eller deaktivert for hele organisasjonen.

Det finnes noen begrensninger vedrørende vedlegg knyttet til begrensninger for lisensiering og leierinnstilling. Hvis du vil ha mer informasjon, kan du se E-postabonnementer for rapporter og instrumentbord i Power Bi-tjeneste.

Sjekkliste – Når du planlegger publisering av innhold, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for hvor innhold skal publiseres, hvordan og av hvem: Bestem hvilke preferanser og krav som finnes for hvor innholdet skal publiseres.
• Bekreft tilgang til arbeidsområdet: Bekreft utformingstilnærmingen for arbeidsområdet. Kontroller hvordan du bruker tilgangsrollene for arbeidsområdet til å støtte strategien for hvor innholdet skal publiseres.
• Bestem hvordan du skal håndtere datasamlebåndtillatelser for distribusjon: Bestem hvilke brukere som har tillatelse til å publisere innhold ved hjelp av et utrullingssamlebånd. Angi tillatelsene for utrullingssamlebåndet tilsvarende. Kontroller at tilgang til arbeidsområdet også er angitt.
• Bestem hvem som kan koble til semantiske modeller ved hjelp av XMLA-endepunktet: Bestem hvilke brukere som har tillatelse til å spørre eller administrere semantiske modeller ved hjelp av XMLA-endepunktet. Angi innstillingen Tillat XMLA-endepunkter og Analyser i Excel med lokale semantiske modeller for leier for å justere med denne beslutningen. Når du bestemmer deg for å begrense denne funksjonen, bør du vurdere å bruke en gruppe, for eksempel Power BI-godkjente innholdsopprettere.
• Bestem hvem som kan publisere rapporter offentlig: Bestem hvilke brukere som har tillatelse til å publisere Power BI-rapporter offentlig, om noen. Angi innstillingen Publiser til nettleietaker for å justere med denne beslutningen. Bruk en gruppe, for eksempel offentlig publisering av Power BI.
• Bestem hvem som kan bygge inn innhold i egendefinerte apper: Bestem hvem som skal kunne bygge inn innhold utenfor Power Bi-tjeneste. Angi innbyggingsinnholdet i leierinnstillingene for apper slik at det samsvarer med denne beslutningen.
• Bestem hvem som kan bygge inn innhold i PowerPoint: Bestem hvem som skal kunne bygge inn innhold i PowerPoint. Angi innstillingen Aktiver Power BI-tillegg for PowerPoint-leier for å justere med denne beslutningen.
• Bestem hvem som kan publisere malapper: Bestem hva strategien din er for å bruke malapper utenfor organisasjonen. Angi tenantinnstillingen publiser malapper slik at den samsvarer med denne beslutningen.
• Bestem om du vil aktivere abonnementer: Bekreft hva strategien din er for å bruke abonnementer. Angi leierinnstillingen for e-postabonnementer slik at den samsvarer med denne beslutningen.

Oppdater data

Når de er publisert, bør dataopprettere sørge for at semantiske modeller og dataflyter (som inneholder importerte data) oppdateres regelmessig. Du bør også bestemme deg for riktige strategier for semantiske modell- og dataflyteiere.

Semantisk modelleier

Hver semantiske modell har en eier, som er én enkelt brukerkonto. Eieren av semantisk modell kreves for å konfigurere semantisk modelloppdatering og angi semantiske modellparametere.

Som standard mottar den semantiske modelleieren også tilgangsforespørsler fra rapportopprettere som ønsker kompileringstillatelser (med mindre tilgangsinnstillingene for forespørsel for den semantiske modellen er satt til å gi egendefinerte instruksjoner). Hvis du vil ha mer informasjon, kan du se delen Be om tilgang til arbeidsflyt for opprettere i denne artikkelen.

Det finnes to måter Power BI kan få legitimasjon for å oppdatere en semantisk modell på.

• Eieren av den semantiske modellen lagrer legitimasjon i innstillingene for semantisk modell.
• Eieren av semantisk modell refererer til en gateway i innstillingene for semantisk modell (som inneholder en datakilde med lagret legitimasjon).

Hvis en annen bruker må konfigurere oppdatering eller angi semantiske modellparametere, må de ta eierskap over den semantiske modellen. semantisk modelleierskap kan overtas av en arbeidsområdeadministrator, medlem eller bidragsyter.

Forsiktig!

Hvis du tar eierskap av semantisk modell permanent, fjernes alle lagrede legitimasjoner for den semantiske modellen. Legitimasjonen må angis på nytt for å tillate at dataoppdateringsoperasjoner gjenopptas.

Ideelt sett er den semantiske modelleieren brukeren som er ansvarlig for semantisk modell. Du bør oppdatere eieren av den semantiske modellen når de forlater organisasjonen eller endrer roller. Vær også oppmerksom på at når den semantiske modelleierens brukerkonto er deaktivert i Microsoft Entra ID (tidligere kjent som Azure Active Directory), deaktiveres dataoppdatering automatisk. I dette tilfellet må en annen bruker ta eierskap over den semantiske modellen for å tillate at dataoppdateringsoperasjoner gjenopptas.

Dataflyteier

I likhet med semantiske modeller har dataflyter også en eier, som er én enkelt brukerkonto. Informasjonen og veiledningen i det forrige emnet om eiere av semantiske modeller gjelder også for eiere av dataflyter.

Sjekkliste – Når du planlegger sikkerhet relatert til dataoppdateringsprosesser, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for semantiske modelleiere: Bestem hvilke preferanser og krav som finnes for administrasjon av semantiske modelleiere.
• Bestem deg for strategien for eiere av dataflyt: Bestem hvilke preferanser og krav som finnes for administrasjon av dataflyteiere.
• Inkluder i dokumentasjon og opplæring for semantiske modellopprettere: Inkluder veiledning for dataopprettere om hvordan du administrerer eiere for hver type element.

Relatert innhold

Hvis du vil ha andre hensyn, handlinger, beslutningskriterier og anbefalinger for å hjelpe deg med implementeringsbeslutninger i Power BI, kan du se emneområdene du bør vurdere.