Planlegging av Power BI-implementering: Planlegging av rapportforbrukersikkerhet

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 skrivebeskyttede forbrukere. Fokuset er på visningstillatelser for rapporter og apper, og hvordan du håndhever datasikkerhet. 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 brukere 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 klassifiseres mange brukere som forbrukere. Forbrukere viser innhold som andre brukere har opprettet og publisert. Forbrukerne er i fokus i denne artikkelen. Hvis du vil ha sikkerhetsplanlegging fokusert på innholdsopprettere og eiere, kan du se artikkelen om sikkerhetsplanlegging for innholdsopprettere.

For å få mest mulig ut av denne artikkelen er det nyttig å forstå betydningen av termdeling og distribusjon i konteksten til Power BI.

Deling er der én bruker gir en annen bruker (eller gruppe brukere) tilgang til et bestemt innholdselement. Delingsfunksjonen i Power Bi-tjeneste er begrenset til ett element. Det foregår oftest mellom personer som kjenner hverandre og arbeider tett sammen.

Distribusjonen er der innhold leveres til andre brukere, som er kjent som mottakere. Det involverer ofte et større antall brukere på tvers av flere team. Mottakere har kanskje ikke eksplisitt bedt om innholdet, men det er gjenkjent at de trenger det for å utføre sin rolle. Mottakere som bruker distribuert innhold, kjenner kanskje kanskje ikke den opprinnelige oppretteren av innholdet. Distribusjon som konsept er derfor mer formell enn deling.

Når du snakker med andre, må du avgjøre om de bruker termdeling på en generell måte, eller bokstavelig talt. Bruk av termdelingen kan tolkes på to måter.

• Termdeling brukes ofte på en generell måte relatert til deling av innhold med kolleger. Det finnes flere teknikker for å levere skrivebeskyttet innhold, som er beskrevet i denne artikkelen.
• Deling er også en bestemt funksjon i Power BI. Det er en funksjon der en bruker eller gruppe får tilgang til ett enkelt element. Deling av koblinger og deling av direkte tilgang er beskrevet i denne artikkelen.

Viktig

Administratorrollen for Power BI har fått nytt navn. Det nye navnet på rollen er Fabric-administrator.

Strategi for skrivebeskyttede forbrukere

I Power Bi-tjeneste kan forbrukere vise en rapport eller et instrumentbord når de har tillatelse til begge deler:

• Vis Power BI-elementet som inneholder visualiseringene (for eksempel en rapport eller et instrumentbord).
• Les de underliggende dataene (semantisk modell – tidligere kalt et datasett – eller en annen kilde).

Du kan gi skrivebeskyttet tilgang til forbrukere ved hjelp av ulike teknikker. De vanlige teknikkene som brukes av selvbetjente innholdsopprettere inkluderer:

• Gi brukere og grupper tilgang til en Power BI-app.
• Legge til brukere og grupper i en visningsrolle i Power BI-arbeidsområdet.
• Gi brukere og grupper tillatelser per element ved hjelp av en delingskobling.
• Gir brukere og grupper tillatelser per element ved hjelp av direkte tilgang.

Rollealternativene Power BI-appen og Visningsprogram for Power BI-arbeidsområdet omfatter administrasjon av tillatelser for et sett med elementer. De to tillatelsesteknikkene per element innebærer administrasjon av tillatelser for ett enkelt element.

Tips

Generelt sett er det en anbefalt fremgangsmåte å bruke en Power BI-app for de fleste forbrukere. Noen ganger kan visningsrollen for arbeidsområdet også være passende. Både Power BI-apper og rollen visningsprogram for arbeidsområdet tillater administrasjon av tillatelser for mange elementer, og bør brukes når det er mulig. Administrasjon av tillatelser for individuelle elementer kan være kjedelig, tidkrevende og feilutsatt. Administrasjon av et sett med elementer reduserer derimot vedlikeholdet og forbedrer nøyaktigheten.

Når du ser gjennom sikkerhetsinnstillingene for et element, ser du kanskje at tillatelsene er enten:

• Arvet fra arbeidsområdet eller en app.
• Brukes direkte på elementet.

I skjermbildet nedenfor vises tillatelsene for direkte tilgang for en rapport. I dette tilfellet tilordnes administrator- og medlemsrollene for arbeidsområdet til en gruppe. Disse rollene vises for rapporten fordi tilgangen på rapportnivå arves fra arbeidsområdet. Det finnes også én bruker som har lesetillatelser brukt direkte i rapporten.

Strategien du velger for skrivebeskyttede forbrukere kan være forskjellig. Den bør være basert på den individuelle løsningen, preferansene til hvem som administrerer løsningen, eller behovene til forbrukeren. Resten av denne delen beskriver når du skal vurdere å bruke hver av de tilgjengelige teknikkene.

Sjekkliste – Når du oppretter strategien for hvordan du leverer innhold til skrivebeskyttede forbrukere, omfatter viktige beslutninger og handlinger:

• Vurder din eksisterende strategi for skrivebeskyttede forbrukere: Kontroller hvordan innholdet for øyeblikket distribueres og deles til forbrukere. Identifiser om det finnes muligheter for forbedring.
• Bestem deg for strategien din for skrivebeskyttede forbrukere: Vurder hva preferansene dine er for å bruke apptillatelser, arbeidsområderoller eller per element-tillatelser. Hvis det er nødvendig med endringer for å oppfylle disse innstillingene, oppretter du en plan for forbedringer.

Power BI-apptillatelser

En Power BI-app leverer en samling rapporter, instrumentbord og arbeidsbøker til forbrukere. En app gir den beste brukeropplevelsen for forbrukere fordi:

• Navigasjonsruten for appen gir en enkel og intuitiv brukeropplevelse. Det er en bedre opplevelse enn å få tilgang til innhold direkte i et arbeidsområde.
• Innhold kan organiseres logisk i inndelinger (som er som mapper) i appens navigasjonsrute.
• Forbrukere har bare tilgang til bestemte elementer som er eksplisitt inkludert i appen for publikum.
• Koblinger til tilleggsinformasjon, dokumentasjon eller annet innhold kan legges til i navigasjonsruten for målgruppen.
• Det finnes en innebygd arbeidsflyt for forespørselstilgang .

Merk

Alle referanser til en app i denne artikkelen refererer til en Power BI-app. Det er et annet konsept enn Power Apps. Det er også et annet konsept enn Power BI-mobilappene. I denne delen er fokuset på organisasjonsapper i stedet for malapper.

Du kan opprette én app for hvert arbeidsområde som en formell måte å distribuere noe eller alt arbeidsområdeinnhold på. Apper er en god måte å distribuere innhold bredt i en organisasjon, spesielt til brukere som du ikke kjenner eller ikke samarbeider tett med.

Tips

Hvis du vil ha mer informasjon om hvordan du bruker en Power BI-app for bred innholdsdistribusjon, kan du se enterprise BI-bruksscenarioet . Vi anbefaler at innholdsopprettere som trenger å distribuere innhold, vurderer å opprette en app som førstevalg.

Du administrerer apptillatelser separat fra arbeidsområderoller. Fordelingen av tillatelser har to fordeler. Det oppmuntrer:

• Gi arbeidsområdetilgang til innholdsopprettere. Det inkluderer brukere som aktivt samarbeider om innholdet, for eksempel semantiske modellopprettere, rapportopprettere og testere.
• Gi apptillatelser til forbrukere. I motsetning til arbeidsområdetillatelser er apptillatelser alltid skrivebeskyttet (eller ingen).

Alle brukere med tilgang til arbeidsområdet kan automatisk vise appen (når en Power BI-app er publisert for arbeidsområdet). På grunn av denne virkemåten kan du tenke på arbeidsområderoller som arvet av hver app-målgruppe. Noen brukere med tilgang til arbeidsområdet kan også oppdatere Power BI-appen, avhengig av den tilordnede arbeidsområderollen.

Tips

Hvis du vil ha mer informasjon om tilgang til arbeidsområdet, kan du se artikkelen om sikkerhetsplanlegging for Innholdsoppretter.

Bruk av en app til å distribuere innhold til skrivebeskyttede forbrukere er det beste valget når:

• Du vil at brukerne bare skal kunne vise bestemte elementer som er synlige for målgruppen (i stedet for alle elementer i det underliggende arbeidsområdet).
• Du vil behandle skrivebeskyttede tillatelser for appen separat fra arbeidsområdet.
• Du vil ha enklere tillatelsesbehandling for skrivebeskyttede brukere enn tillatelser per element.
• Du vil sikre at sikkerhet på radnivå håndheves for forbrukere (når de har skrivebeskyttet tillatelse på den underliggende semantiske modellen).
• Du vil sikre at forbrukerne ikke kan vise nye og endrede rapporter før appen publiseres på nytt.

Selv om det er sant at endringer i rapporter og instrumentbord ikke er synlige for brukere av appen før appen publiseres på nytt, er det to hensyn som krever forsiktighet.

• Umiddelbare endringer i semantisk modell: Semantiske modellendringer trer alltid i kraft umiddelbart. Hvis du for eksempel introduserer bruddendringer i en semantisk modell i arbeidsområdet, kan det utilsiktet føre til at rapporter blir ustabile (selv om de ikke har blitt publisert på nytt i appen). Det finnes to måter å redusere denne risikoen på: Først må du utføre alt utviklingsarbeid i Power BI Desktop (atskilt fra arbeidsområdet). For det andre isolerer du produksjonsappen ved hjelp av separate arbeidsområder for utvikling og test. (Du kan eventuelt oppnå et høyere kontrollnivå over distribusjon av arbeidsområdeinnhold fra utvikling til test og produksjon ved hjelp av utrullingssamlebånd.)
• Innhold og tillatelser publiseres sammen: Når du publiserer en app, publiseres tillatelsene samtidig som innholdet. Du kan for eksempel ha rapportendringer i et arbeidsområde som ennå ikke er fullført, fullstendig testet eller godkjent. Du kan derfor ikke publisere appen på nytt bare for å oppdatere tillatelser. Hvis du vil redusere denne risikoen, tilordner du apptillatelser til sikkerhetsgrupper og bruker sikkerhetsgruppemedlemskap (i stedet for individuelle brukere) når du gir apptillatelser. Unngå å publisere en app på nytt bare for å bruke tillatelsesendringer.

App-målgruppe

Hvert arbeidsområde i Power Bi-tjeneste kan bare ha én Power BI-app. I appen kan du imidlertid opprette én eller flere målgrupper. Tenk deg følgende scenario.

• Du har fem salgsrapporter som distribueres til mange brukere i hele den globale salgsorganisasjonen.
• Én målgruppe er definert i appen for salgsrepresentantene. Denne målgruppen kan vise tre av de fem rapportene.
• En annen målgruppe er definert i appen for salgslederteamet. Denne målgruppen kan vise alle de fem rapportene, inkludert de to rapportene som ikke er tilgjengelige for selgere.

Denne funksjonen for å blande og samsvare med innhold og målgrupper har følgende fordeler.

• Enkelte rapporter kan være tilgjengelige for visning av flere målgrupper. Hvis du oppretter flere målgrupper, fjernes behovet for å duplisere innhold på tvers av ulike arbeidsområder.
• Enkelte rapporter skal bare være tilgjengelige for én målgruppe. Så innhold for den ene målgruppen kan ligge i samme arbeidsområde som annet relatert innhold.

Følgende skjermbilde viser en app med to målgrupper: Salgsledelse og Salgsrepresentanter. Administrer målgruppetilgang-ruten gir tilgang til målgruppegruppen for salgsledelse for to sikkerhetsgrupper: Sales Leadership-Nord-Amerika og Sales Leadership-Europe. Rapporten bruttofortjenesteanalyse som vises i skjermbildet for målgruppen for salgsledelse , er ikke tilgjengelig for målgruppen for salgsrepresentanter .

Merk

Termgruppegruppen brukes noen ganger. Det er ikke en direkte referanse til bruken av sikkerhetsgrupper. Det inkluderer medlemmer av målgruppen som vil se samlingen av innhold i en Power BI-app. Selv om du kan tilordne individuelle brukere til en målgruppe, er det en anbefalt fremgangsmåte å tilordne sikkerhetsgrupper, Microsoft 365-grupper eller distribusjonsgrupper når det er praktisk. Hvis du vil ha mer informasjon, kan du se strategien for å bruke grupper i artikkelen om sikkerhetsplanlegging på leiernivå.

Når du administrerer tillatelser for en app, kan du vise medlemmene av hver målgruppe på Direktetilgang-siden . Du kan også se brukere med en arbeidsområderolle oppført under Alle målgrupper. Du kan ikke oppdatere apptillatelsene fra Direktetilgang-siden . I stedet må du publisere appen på nytt. Du kan imidlertid oppdatere apptillatelser fra Ventende-sidennår det er åpne tilgangsforespørsler for appen.

Tips

Det primære brukstilfellet for bruk av appmålgrupper er å definere bestemte tillatelser for ulike sett med brukere. Du kan imidlertid bli litt kreativ når du bruker målgrupper. En bruker kan være medlem av flere målgrupper, og hver målgruppe vises til brukere av appen som et sekundært sett med menyer. Du kan for eksempel opprette en målgruppe med navnet Start her som inneholder informasjon om hvordan du bruker appen, hvem du skal kontakte, hvordan du gir tilbakemelding og hvordan du får hjelp. Du kan også opprette en målgruppe kalt KPI-definisjoner som inneholder en dataordliste. Hvis du gir denne typen informasjon, hjelper nye brukere og forbedrer løsningsinnføringsarbeidet.

Alternativer for apptillatelse

Når du oppretter (eller publiserer på nytt) en app, har hver målgruppe en Behandle målgruppetilgang-rute . I denne ruten er følgende tillatelser tilgjengelige.

• Gi tilgang til: For hver målgruppe kan du gi tilgang til individuelle brukere og grupper. Det er mulig å publisere appen til hele organisasjonen når den aktiveres av Publiser-appene til hele organisasjonens leierinnstilling, og appen installeres ikke automatisk. Når det er mulig, anbefaler vi at du tilordner grupper til målgrupper fordi det å legge til eller fjerne brukere innebærer å publisere appen på nytt. Alle med tilgang til arbeidsområdet har automatisk tillatelse til å vise eller oppdatere appen avhengig av arbeidsområderollen.
• Semantiske modelltillatelser: To typer semantiske modelltillatelser kan gis under publisering av en app:
  • Semantic model Reshare: Når det er aktivert, får appbrukere tillatelsen Reshare til den underliggende semantiske modellen(e) med andre. Det er fornuftig å aktivere dette alternativet når de underliggende semantiske modellene lett kan deles på nytt med hvem som helst. Vi anbefaler at du får godkjenning fra de semantiske modelleierne før du gir reshare-tillatelsen til en app-målgruppe.
  • Semantisk modellbygg: Når det er aktivert, får appbrukere kompileringstillatelsen for semantiske modeller. Med byggtillatelse kan brukere opprette nye rapporter, eksportere underliggende data fra rapporter med mer. Vi anbefaler at du får godkjenning fra de semantiske modelleierne før du gir kompileringstillatelse til en app-målgruppe.

Muligheten til å legge til semantisk modell Reshare- eller Build-tillatelser mens du publiserer en app, er praktisk. Vi anbefaler imidlertid at du vurderer å administrere apptillatelser og semantiske modelltillatelser separat. Her er årsakene til hvorfor.

• Delt semantisk modell kan være i et eget arbeidsområde: Hvis den semantiske modellen publiseres til et eget arbeidsområde fra appen, må du administrere tillatelsene direkte. Muligheten til å legge til lese-, bygg- eller delingstillatelser mens du publiserer en app, fungerer bare for semantiske modeller som er i samme arbeidsområde som appen. Av denne grunn anbefaler vi at du kommer inn i vanen med å administrere semantiske modelltillatelser uavhengig av hverandre.
• Semantiske modelltillatelser administreres separat: Hvis du fjerner eller endrer tillatelser for en app, påvirker denne handlingen bare appen. Den fjerner ikke automatisk semantiske modelltillatelser som tidligere ble tilordnet. På denne måten kan du tenke på apptillatelser og semantiske modelltillatelser som koblet fra. Du må administrere semantisk modell direkte, separat fra appen, når semantiske modelltillatelser endres eller må fjernes.
• Semantiske modelltillatelser bør kontrolleres: Hvis du gir semantiske modelltillatelser gjennom en app, fjernes kontrollen fra eieren av den semantiske modellen. Ved å gi tillatelsen Tildel på nytt er avhengig av god vurdering av brukere som velger å dele semantiske modeller på nytt. Intern styring eller sikkerhetsretningslinjer kan bli vanskeligere å administrere når deling er tillatt.
• Forbrukere og opprettere har forskjellige mål: Vanligvis er det mange flere innholdsforbrukere enn opprettere i en organisasjon. I tråd med prinsippet om minst rettigheter trenger forbrukere bare lesetillatelse for den underliggende semantiske modellen. De trenger ikke kompileringstillatelse med mindre de har tenkt å opprette nye rapporter.

Tips

Hvis du vil ha mer informasjon om når du skal bruke separate dataarbeidsområder og arbeidsområder for rapportering, kan du se artikkelen om planlegging på arbeidsområdenivå.

Rettigheter for forhåndsinstallasjon av apper

Når du har publisert en Power BI-app, må en bruker vanligvis installere den slik at de kan åpne den. En bruker kan installere en app fra Apper-siden i Power Bi-tjeneste, eller ved hjelp av en kobling de har mottatt fra en annen bruker. De vil kunne finne (og installere) en app når de er inkludert i minst ett publikum av appen.

En alternativ tilnærming til å installere en app er å sende den til appforbrukere. Det resulterer i forhåndsinstallasjonen av appen, slik at den automatisk vises på Apper-siden i Power Bi-tjeneste. Denne fremgangsmåten er en praktisk metode for forbrukere fordi de ikke trenger å finne og installere appen. Forhåndsinstallerte apper kan imidlertid bli en irritasjon for brukerne fordi de kan bli overveldet av for mange apper som ikke er relevante for dem.

Innstillingen For Push-apper til sluttbrukere av leier kontrollerer hvem som har tillatelse til å installere apper automatisk. Vi anbefaler at du bruker denne funksjonen fordi den er praktisk for brukere. Vi anbefaler imidlertid også at du informerer innholdsoppretterne om når du skal bruke det, slik at det ikke overbrukes.

Tips

Hvis du velger alternativet for å installere appen automatisk når du publiserer en app, kan du ikke angi at målgruppen skal være hele organisasjonen (hvis det aktiveres av push-appene for å avslutte brukernes leierinnstilling).

Sjekkliste – Når du oppretter strategien din for å bruke apper for innholdslesere, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for bruk av apper: Definer preferansene dine for hvordan du bruker apper. Sørg for at den samsvarer med den overordnede strategien for skrivebeskyttede forbrukere.
• Bestem hvem som kan publisere apper til hele organisasjonen: Bestem hvilke rapportopprettere som kan publisere til hele organisasjonen. Angi publiseringsappene til hele organisasjonens leierinnstilling slik at de samsvarer med denne beslutningen.
• Bestem hvem som kan sende apper til sluttbrukere: Bestem hvilke rapportopprettere i Power BI som kan forhåndsinstallere apper. Angi innstillingen for Push-apper til sluttbrukere for leier for å justere med denne beslutningen.
• Opprett og publiser veiledning for innholdsopprettere: Gi dokumentasjon og opplæring for innholdsopprettere. Inkluder krav og preferanser for hvordan du bruker apper mest effektivt.
• Bestem hvordan du skal håndtere apptilgangsforespørsler: Sørg for at en prosess er på plass for å tilordne kontakter og håndtere forespørsler om tilgang til apper i tide.

Arbeidsområdevisningsrolle

Som beskrevet i planleggingsartiklene for arbeidsområdet, er hovedformålet med et arbeidsområde samarbeid. Samarbeidspartnere for arbeidsområder, for eksempel semantiske modellopprettere, rapportopprettere og testere, bør tilordnes til én av tre roller: Bidragsyter, medlem eller administrator. Disse rollene er beskrevet i sikkerhetsplanleggingsartikkelen for innholdsoppretteren.

Du kan tilordne rollen visningsprogram for arbeidsområdet til forbrukere. Å gi forbrukere tilgang til innhold direkte i et arbeidsområde kan være fornuftig for små team og uformelle team som jobber tett sammen.

Det er et godt valg å gi forbrukere tilgang til arbeidsområdeinnhold direkte når:

• Formaliteten til en app, med egne tillatelser, er ikke nødvendig.
• Brukere har tillatelse til å vise alle elementer som er lagret i arbeidsområdet.
• Du vil ha enklere tillatelsesbehandling enn tillatelser per element.
• Arbeidsområdebrukere kan også vise en app (når en app publiseres for arbeidsområdet).
• Hensikten er at brukerne skal se gjennom innhold før det publiseres i en app.

Her er noen forslag til støtte for visning av arbeidsområder.

• Organiser innhold i hvert arbeidsområde, slik at elementene enkelt plasseres av rapportforbrukere, slik at de passer godt til sikkerheten. Arbeidsområde etter emneområde eller prosjekt fungerer vanligvis bra.
• Skill utvikling og test innhold fra produksjonsinnhold, slik at pågående elementer ikke kan åpnes av brukere.
• Bruk apper (eller tillatelser per element når det er aktuelt) når du forventer å ha mange tilgangsforespørsler å behandle. Det finnes ikke en forespørsel om tilgangsarbeidsflyt for arbeidsområder.

Sjekkliste – Når du oppretter strategien for å bruke arbeidsområder for innholdslesere, omfatter viktige beslutninger og handlinger:

• Bestem deg for en strategi for å bruke rollen visningsprogram for arbeidsområdet: Definer hva preferansene dine er for hvordan du bruker arbeidsområder for forbrukere. Sørg for at den samsvarer med den overordnede strategien for skrivebeskyttede forbrukere.
• Opprett og publiser veiledning for innholdsopprettere: Gi dokumentasjon og opplæring for innholdsopprettere. Inkluder krav og innstillinger for hvordan du bruker arbeidsområdetillatelser mest effektivt.

Tillatelser per element

Deling av enkeltelementer gir tillatelse til ett enkelt element. Mindre erfarne innholdsopprettere bruker vanligvis denne teknikken som den primære delingsteknikken fordi delingskommandoene vises tydelig i Power Bi-tjeneste. Derfor er det viktig å lære innholdsoppretterne om de ulike delingsalternativene, blant annet når du skal bruke apptillatelser i stedet for arbeidsområderoller.

Tillatelser per element er et godt valg når:

• Du vil gi skrivebeskyttet tilgang til ett element (rapport eller instrumentbord).
• Du vil ikke at forbrukeren skal vise alt innhold som er publisert til et arbeidsområde.
• Du vil ikke at forbrukeren skal vise alt innhold som er publisert til en app-målgruppe.

Bruk tillatelser per element sparsomt fordi deling gir lesetillatelse til ett enkelt element. På en måte kan du tenke på tillatelser per element som en overstyring av arbeidsområderoller eller apptillatelser.

Tips

Vi anbefaler at du bruker apptillatelser når det er mulig. Vurder deretter å bruke arbeidsområderoller for å aktivere direkte tilgang til arbeidsområdet. Til slutt kan du bruke per element-tillatelser når de oppfyller vilkårene ovenfor. Både apptillatelser og arbeidsområderoller angir sikkerhet for en samling av innhold (i stedet for individuelle elementer), noe som er en bedre sikkerhetspraksis.

Deling av mange elementer ved hjelp av tillatelser per element kan være kjedelig og feilutsatt, spesielt når du deler til individuelle brukere i stedet for grupper. Vurder dette scenarioet: Du har 40 rapporter som du har delt med kolleger ved hjelp av deres individuelle brukerkontoer. Når én kollega overfører til en annen avdeling, må du tilbakekalle tilgangen deres, noe som vil innebære redigeringstillatelser for alle de 40 rapportene.

Viktig

Deling av innhold fra et personlig arbeidsområde bør gjøres sjeldent. Personlige arbeidsområder passer best til ikke-kritisk, uformelt eller midlertidig innhold. Hvis du har en situasjon der innholdsopprettere ofte deler viktig eller kritisk innhold fra sine personlige arbeidsområder, bør du utføre nødvendige tiltak for å flytte innholdet til et standard arbeidsområde. Hvis du vil ha mer informasjon, kan du se det personlige BI-bruksscenarioet .

Når du deler et enkeltelement, har du flere tillatelsesalternativer.

• Dele tillatelse på nytt: Når det er aktivert, kan brukere dele elementet med andre brukere, inkludert de underliggende semantiske modellene. Det er fornuftig å gi denne tillatelsen når elementet lett kan deles med hvem som helst. Den fjerner kontrollen fra personen eller teamet som administrerer elementet. Så, det er avhengig av god dømmekraft av brukere som er gitt Reshare tillatelse. Intern styring eller sikkerhetsretningslinjer kan imidlertid bli vanskeligere å administrere når deling er tillatt.
• Kompileringstillatelse: Når det er aktivert, får brukerne kompileringstillatelse for den underliggende semantiske modellen. Med kompileringstillatelse kan brukere opprette nytt innhold som er basert på den semantiske modellen. Det gjør det også mulig for dem å eksportere underliggende data fra rapporter med mer. Vurderinger for å gi kompileringstillatelse er beskrevet i sikkerhetsplanleggingsartikkelen for innholdsoppretteren.

Tillatelser per element for rapporter og instrumentbord kan være fornuftige for uformelle scenarioer når innhold deles med noen få brukere. Det er lurt å lære brukerne å administrere tillatelser med apper og arbeidsområder i stedet, spesielt når de deler innhold til et stort antall brukere eller brukere utenfor teamet. Det er viktig å fremheve følgende punkter.

• Det blir vanskeligere å fastslå hvilket innhold som er delt med hvilke brukere, fordi tillatelsene på hver rapport og hvert instrumentbord må gjennomgås enkeltvis.
• I mange tilfeller angis Tillatelse for deling på nytt fordi brukeropplevelsen aktiverer dette alternativet som standard. Det er derfor en risiko for at innhold deles til et bredere sett med brukere enn det som er tiltenkt. Dette resultatet kan forhindres ved å fjerne merket for Tillat mottakere å dele dette rapportalternativet når de deler. Å minimere overdeling på denne måten er et brukeropplæringsproblem. Innholdsoppretteren som angir delingstillatelsene, bør vurdere dette valget hver gang.
• Alle endringer i rapporter og instrumentbord kan vises av andre umiddelbart, noe som kan forvirre brukere når innholdsendringer pågår. Denne bekymringen kan reduseres ved å distribuere innhold i en app, eller ved å bruke separate arbeidsområder til å skille utvikling, test og produksjonsinnhold. Hvis du vil ha mer informasjon, kan du se det selvbetjente bruksscenarioet for innholdspublisering .
• Når en bruker deler innhold fra sitt personlige arbeidsområde og de forlater organisasjonen, deaktiverer IT vanligvis brukerkontoen. I dette tilfellet vil alle mottakere av det delte innholdet umiddelbart miste tilgang til innholdet.

Det finnes tre bestemte typer deling: deling av koblinger, deling av direkte tilgang og delte visninger.

Tillatelseskoblinger per element

Når du deler et enkeltelement, resulterer standardopplevelsen i en delingskobling. Det finnes tre typer delingskoblinger.

• Folk i organisasjonen: Når den er aktivert i power bi-leierinnstillingene, er denne typen delingskobling en enkel måte å gi skrivebeskyttet tilgang til alle i organisasjonen på. Delingskoblingen fungerer imidlertid ikke for eksterne brukere. Dette alternativet passer best når alle kan vise innholdet, og koblingen kan deles fritt i hele organisasjonen. Med mindre den er deaktivert av koblingene Tillat deling for å gi tilgang til alle i organisasjonens leierinnstilling, er denne typen deling standard.
• Folk med eksisterende tilgang: Dette alternativet oppretter ikke en ny delingskobling. I stedet kan du hente nettadressen slik at du kan sende den til noen som allerede har tilgang.
• Bestemte personer: Dette alternativet produserer en delingskobling for bestemte brukere eller grupper. Vi anbefaler at du bruker dette alternativet mesteparten av tiden fordi det gir spesifikk tilgang. Hvis du vanligvis arbeider med eksterne brukere, kan du bruke denne typen kobling for gjestebrukere som allerede finnes i Microsoft Entra ID (tidligere kalt Azure Active Directory). Hvis du vil ha mer informasjon om den planlagte invitasjonsprosessen for å opprette gjestebrukere, kan du se artikkelen om sikkerhetsplanlegging på leiernivå.

Viktig

Vi anbefaler at du vurderer å begrense tillat delingskoblinger for å gi tilgang til alle i organisasjonens leierinnstilling til medlemmer av en gruppe. Du kan opprette et gruppenavn som Power BI Share i hele organisasjonen, og deretter legge til et lite antall brukere som forstår konsekvensene av deling over hele organisasjonen. Hvis du er bekymret for eksisterende koblinger for hele organisasjonen, kan du bruke administrator-API-en til å finne alle elementer som har blitt delt med hele organisasjonen.

En delingskobling legger til lesetillatelse i elementet. Tillatelsen Del på nytt er valgt som standard. Det er også mulig å legge til kompileringstillatelse i den underliggende semantiske modellen samtidig som delingskoblingen opprettes.

Tips

Vi anbefaler at du lærer innholdsopprettere å aktivere alternativet Kompileringstillatelse bare når forbrukeren av rapporten også er en innholdsoppretter som kanskje må opprette rapporter, eksportere data eller opprette en sammensatt modell fra den underliggende semantiske modellen.

Deling av koblinger er enklere å vedlikeholde enn deling av direkte tilgang, spesielt når du må gjøre masseendringer. Det er en betydelig fordel når individuelle brukere får delingstillatelser, mer enn grupper (som vanligvis oppstår når selvbetjente brukere er ansvarlige for å administrere tillatelser). Vurder følgende sammenligninger.

• Delingskobling: 20 individuelle brukere får tilgang med en delingskobling. Med én enkelt endring i koblingen påvirker den alle de 20 brukerne.
• Direkte tilgang: 20 personer får direkte tilgang til et element. Hvis du vil gjøre en endring, må alle de 20 brukertillatelsene endres.

Direkte tilgangstillatelser per element

Du kan også oppnå tillatelser per element ved hjelp av direkte tilgang. Direkte tilgang innebærer å konfigurere tillatelsene for ett enkelt element. Du kan også bestemme eventuelle arvede tillatelser som er avledet fra arbeidsområderoller.

Når du gir en bruker direkte tilgang, får de lesetillatelse for elementet. Reshare-tillatelsen er valgt som standard, det samme gjelder kompileringstillatelsen for den underliggende semantiske modellen. Vi anbefaler at du lærer innholdsopprettere å aktivere kompileringstillatelse bare når forbrukeren av denne rapporten også er en innholdsoppretter som kanskje må opprette rapporter, eksportere data eller opprette sammensatte modeller fra den underliggende semantiske modellen.

Tips

Brukeropplevelsen gjør det veldig enkelt å gi tillatelser for videre deling og bygg, men brukeren som gjør delingen, bør alltid kontrollere om disse tillatelsene er nødvendige.

Delte visninger

Bruk en delt visning til å dele et filtrert perspektiv på en rapport med en annen bruker. Du kan publisere en delt visning ved hjelp av en delingskobling eller direkte tilgang.

Delte visninger er et midlertidig konsept. De utløper automatisk etter 180 dager. Av denne grunn er delte visninger best egnet til uformelle og midlertidige delingsscenarioer. Pass på at brukerne er oppmerksomme på denne begrensningen.

Sjekkliste – Når du oppretter strategien for bruk av tillatelser per element, omfatter viktige beslutninger og handlinger:

• Bestem deg for strategien for bruk av delingsfunksjonen: Definer hva innstillingene dine er for hvordan du bruker per element-tillatelser. Sørg for at den samsvarer med den overordnede strategien for skrivebeskyttede forbrukere.
• Bestem hvem som kan publisere koblinger til hele organisasjonen: Bestem hvilke rapportopprettere som kan publisere koblinger for hele organisasjonen. Angi koblinger som kan deles for å gi tilgang til alle i organisasjonens leierinnstilling, slik at de samsvarer med denne beslutningen.
• Opprett og publiser veiledning for innholdsopprettere: Gi dokumentasjon og opplæring for innholdsopprettere som inneholder krav og preferanser for hvordan du bruker tillatelser per element mest effektivt. Sørg for at de er tydelige på fordelene og ulempene ved per element-tillatelser. Inkluder veiledning for når du skal bruke delingskoblinger og når du skal bruke direkte tilgangsdeling.

Andre teknikker for forbrukerspørring

De vanligste måtene for forbrukere å samhandle med Power BI på, er med apper, arbeidsområder og per element-tillatelser (tidligere beskrevet i denne artikkelen).

Det finnes andre teknikker som forbrukere kan bruke til å spørre Power BI-data. Hver av følgende spørringsteknikker krever semantisk modell eller datamart build-tillatelse.

• Analyser i Excel: Forbrukere som foretrekker å bruke Excel, kan spørre en semantisk Power BI-modell ved hjelp av Analyser i Excel. Denne funksjonen er et flott alternativ til å eksportere data til Excel fordi dataene ikke er duplisert. Med en live-tilkobling til den semantiske modellen kan brukere opprette pivottabeller, diagrammer og slicere. De kan deretter publisere arbeidsboken til et arbeidsområde i Power Bi-tjeneste som gjør det mulig for forbrukere å åpne den og samhandle med den.
• XMLA-endepunkt: Forbrukere kan spørre etter en semantisk modell ved å koble til XMLA-endepunktet. Et program som er XMLA-kompatibelt, kan koble til, spørre og bruke en semantisk modell som er lagret i et Premium-arbeidsområde. Denne funksjonen er nyttig når forbrukere ønsker å bruke en semantisk Power BI-modell som datakilde for et datavisualiseringsverktøy utenfor Microsoft-økosystemet.
• Redigeringsprogram for datamart: Forbrukere kan spørre etter et Power BI-datamart ved hjelp av redigeringsprogrammet for datamart. Det er et nettbasert redigeringsprogram for visualobjekter for oppretting av spørringer uten kode. Det finnes også et nettbasert SQL-redigeringsprogram for når forbrukere foretrekker å skrive SQL-spørringer. Begge redigeringsprogrammer spør den administrerte Azure SQL Database som ligger til grunn for Power BI-datamart (i stedet for den innebygde semantiske modellen).
• SQL-endepunkt: Forbrukere kan spørre etter et Power BI-datamart ved hjelp av SQL-endepunktet. De kan bruke verktøy som Azure Data Studio eller SQL Server Management Studio (SSMS) til å kjøre SQL-spørringer. SQL-endepunktet dirigerer spørringer til den administrerte Azure SQL Database som ligger til grunn for Power BI-datamarten (i stedet for den innebygde semantiske modellen).

Hvis du vil ha mer informasjon om kompileringstillatelsen, kan du se artikkelen om sikkerhetsplanlegging for Innholdsoppretter.

Sjekkliste – Når du planlegger hvilke spørringsteknikker forbrukerne skal bruke, omfatter viktige beslutninger og handlinger:

• Opprett veiledning for brukere om hvordan du bruker Analyser i Excel: Gi dokumentasjon og opplæring for forbrukere på den beste måten å bruke eksisterende semantiske modeller på nytt med Excel.
• Opprett veiledning for brukere om bruk av XMLA-endepunktet: Gi dokumentasjon og opplæring for forbrukere på den beste måten å bruke eksisterende semantiske modeller på nytt med XMLA-endepunktet.
• Opprett veiledning for brukere om datamart-spørringer: Gi dokumentasjon og opplæring for forbrukere om de tilgjengelige teknikkene for spørring av Power BI-datamarts.

Be om tilgangsarbeidsflyt for forbrukere

Når du deler innhold, er det vanlig at én bruker videresender en kobling (URL) til en annen bruker. Når mottakeren prøver å vise innholdet og oppdager at de ikke har tilgang til det, kan de velge Be om tilgang-knappen . Denne handlingen starter arbeidsflyten for forespørselstilgang . Brukeren blir deretter bedt om å oppgi en melding for å forklare hvorfor de vil ha tilgang.

Det finnes en forespørselstilgangsarbeidsflyt for:

• Tilgang til en Power BI-app.
• Tilgang til et element, for eksempel en rapport eller et instrumentbord.
• Tilgang til en semantisk modell. Hvis du vil ha mer informasjon om arbeidsflyten for forespørselstilgang når en semantisk modell kan oppdages, kan du se artikkelen om sikkerhetsplanlegging for innholdsoppretter.

Apptilgangsforespørsler

Det finnes to måter å lære om ventende tilgangsforespørsler som er sendt inn for en app.

• E-post: Kontakten(e) for appen mottar et e-postvarsel. Som standard er denne kontakten apputgiveren. Hvis du vil gi bedre støtte for kritiske apper, anbefaler vi at du angir kontakten til en gruppe som kan svare raskt på tilgangsforespørsler.
• Behandle tillatelsesmenyen: Administratorer og medlemmer av arbeidsområdet kan vise, godkjenne eller avslå tilgangsforespørsler. Siden Behandle tillatelser er tilgjengelig på Apper-siden, og kan åpnes for hver app. Denne funksjonen er også tilgjengelig for bidragsytere i arbeidsområdet når Tillat bidragsytere å oppdatere appen for denne innstillingen for arbeidsområdet er aktivert.

Ventende tilgangsforespørsler for en app viser meldingen fra brukeren. Hver ventende forespørsel kan godkjennes eller avslås. Når du velger å godkjenne en forespørsel, må en app-målgruppe velges.

Skjermbildet nedenfor viser en ventende tilgangsforespørsel fra en bruker. Hvis du vil godkjenne det, må én av de to appmålgruppene, salgsrepresentantene eller salgsledelsen, velges.

Når du publiserer en app, publiseres innholdet og tillatelsene samtidig. Som tidligere beskrevet er det ikke mulig å publisere bare apptillatelsene uten innholdsendringer også. Det finnes imidlertid ett unntak: Når du godkjenner en ventende tilgangsforespørsel (for eksempel den som vises i forrige skjermbilde), skjer tillatelsesendringen uten å publisere det nyeste innholdet i arbeidsområdet.

Tilgangsforespørsler for arbeidsområde

Arbeidsområdetilgang gis av brukere som tilhører administratorrollen eller medlemsrollen.

En bruker som prøver å vise et arbeidsområde, får en melding om at de ikke er medlem av en arbeidsområderolle. Siden det ikke finnes en innebygd arbeidsflyt for tilgang til forespørsler for arbeidsområder, brukes de best for små team og uformelle team som jobber tett sammen. Det er én grunn til at en Power BI-app passer bedre til større team og bredere innholdsdistribusjonsscenarioer.

Tilgangsforespørsler per element

Det finnes to måter å lære om ventende tilgangsforespørsler som er sendt inn for et enkeltelement, for eksempel en rapport.

• E-post: Kontakten(e) for elementet mottar et e-postvarsel. Hvis du vil gi bedre støtte for kritiske rapporter, anbefaler vi at du angir kontakten til en gruppe som kan svare raskt på tilgangsforespørsler.
• Behandle tillatelser-menyen: Administratorer og medlemmer av arbeidsområdet har tilgang til siden Behandle tillatelser for hvert element. De kan vise, godkjenne eller avslå ventende forespørsler om tilgang.

Behandle tilgangsforespørsler med grupper

Når en bruker sender forespørselstilgangsskjemaet for et Power BI-element (for eksempel en rapport eller semantisk modell) eller en Power BI-app, sendes forespørselen til en enkeltbruker. Mange store organisasjoner må imidlertid bruke grupper for å overholde de interne sikkerhetspolicyene.

Vi anbefaler at du bruker grupper, i stedet for enkeltpersoner, til å sikre innhold når det er praktisk. Hvis du vil ha mer informasjon om planlegging for grupper, kan du se artikkelen om sikkerhetsplanlegging på leiernivå.

Hvis du har tenkt å gi tilgang til grupper i stedet for individuelle brukere, må innholdseieren eller administratoren som behandler forespørselen om tilgang, fullføre forespørselen i flere trinn:

1. Avslå ventende forespørsel i Power BI (fordi den er knyttet til en enkeltbruker).
2. Legg til anmoderen i riktig gruppe i henhold til gjeldende prosess.
3. Varsle anmoderen om at de nå har tilgang.

Tips

Se Be om tilgangsarbeidsflyt for opprettere for informasjon om å svare på forespørsler om kompileringstilgang fra innholdsopprettere. Den inneholder også anbefalinger om bruk av et skjema for tilgangsforespørsler.

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

• Bestem hvem som skal håndtere apptilgangsforespørsler: Sørg for at en prosess er på plass for å håndtere apptilgangsforespørsler i tide. Kontroller at appkontakter er tilordnet til å støtte prosessen.
• Bestem hvem som skal håndtere forespørsler per element: Kontroller at en prosess er på plass for å håndtere tilgangsforespørsler i tide. Kontroller at kontakter er tilordnet til hvert element for å støtte prosessen.
• Inkluder i dokumentasjon og opplæring for innholdsopprettere: Sørg for at innholdsopprettere forstår hvordan de håndterer tilgangsforespørsler i tide. Gjør dem oppmerksomme på hvordan de skal håndtere forespørsler når en gruppe skal brukes i stedet for en enkeltbruker.
• Inkluder i dokumentasjon og opplæring: Inkluder veiledning for innholdsopprettere om hvordan du administrerer tilgangsforespørsler effektivt. Inkluder også veiledning for forbrukere om hvilken informasjon som skal inkluderes i tilgangsforespørselsmeldingen.

Fremtving datasikkerhet basert på forbrukeridentitet

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.

Tenk deg for eksempel at du kan dele én enkelt salgsrapport med alle selgere (forbrukere), vel vitende om at hver selger bare vil se salgsresultater for området. Med denne fremgangsmåten kan du unngå kompleksiteten ved å opprette separate rapporter per område som må deles med selgerne fra dette salgsområdet.

Noen organisasjoner har spesifikke krav for godkjente (sertifiserte eller forfremmede) semantiske modeller eller datamarts. For data som vil bli mye brukt, kan det være et krav om å bruke datasikkerhet.

Du kan utføre datasikkerhet på flere måter.

• Semantisk Power BI-modell: Som power BI-dataoppretter kan du fremtvinge sikkerhet på radnivå (RLS) og sikkerhet på objektnivå (OLS). RLS innebærer å definere roller og regler som filtrerer datamodellrader, mens OLS begrenser tilgangen til bestemte tabeller eller kolonner. Disse definerte RLS- og OLS-reglene gjelder ikke for referanser som er lagret utenfor den semantiske modellen, for eksempel slicer og filtreringsvalg. Både RLS- og OLS-teknikker beskrives ytterligere senere i denne delen.
• Analysis Services: En semantisk modell for live-tilkobling kan koble til en ekstern datamodell, som driftes av enten Azure Analysis Services (AAS) eller SQL Server Analysis Services (SSAS). Den eksterne modellen kan fremtvinge RLS eller OLS basert på forbrukeridentiteten.
• Datakilde: Noen datakilder, for eksempel Azure SQL Database, kan fremtvinge RLS. I dette tilfellet kan Power BI-modellen dra nytte av den eksisterende sikkerheten i stedet for å omdefinere den. Denne tilnærmingen kan være en betydelig fordel når RLS definert i kilden er kompleks. Du kan utvikle og publisere en DirectQuery-modell og angi datakildelegitimasjonen for semantisk modell i Power Bi-tjeneste for å aktivere enkel pålogging (SSO). Når en rapportforbruker åpner en rapport, sender Power BI identiteten sin til datakilden. Datakilden håndhever deretter RLS basert på identiteten til rapportforbrukeren. Hvis du vil ha mer informasjon om Azure SQL Database RLS, kan du se denne artikkelen.

Merk

Kildesystemer, for eksempel Azure SQL Database, kan også bruke teknikker som visninger for å begrense hva brukeren kan se. Selv om det er en gyldig teknikk, er det ikke relevant for fokuset på denne inndelingen.

Sikkerhet på radnivå

Sikkerhet på radnivå (RLS) gjør det mulig for en datamodellerer å begrense tilgangen til et delsett med data. Det brukes vanligvis til å sikre at enkelte rapportforbrukere ikke kan se spesifikke data, for eksempel salgsresultater fra andre salgsområder.

Tips

Hvis du har lagt merke til at noen oppretter flere datamodeller for å støtte ulike grupper av forbrukere, må du kontrollere om RLS oppfyller kravene deres. Det er vanligvis bedre å opprette, teste og vedlikeholde én datamodell i stedet for flere datamodeller.

Vær forsiktig, fordi hvis en Power BI-rapport refererer til en rad med RLS konfigurert, vises den samme meldingen som for et slettet eller ikke-eksisterende felt. For disse brukerne ser det ut til at rapporten er brutt.

Det finnes to trinn for å konfigurere RLS: regler og rolletilordninger.

RLS-regler

For semantiske modeller kan en datamodellerer konfigurere RLS i Power BI Desktop ved å opprette én eller flere roller. En rolle har et unikt navn i modellen, og den inneholder vanligvis én eller flere regler. Regler fremtvinger filtre på modelltabeller ved hjelp av DAX-filteruttrykk (Data Analysis Expressions). Som standard har en modell ingen roller.

Viktig

En modell uten roller betyr at brukere (som har tillatelse til å spørre etter datamodellen) har tilgang til alle modelldata.

Regeluttrykk evalueres i radkontekst. Radkontekst betyr at uttrykket evalueres for hver rad ved hjelp av kolonneverdiene for denne raden. Når uttrykket returneres TRUE, kan brukeren se raden. Du kan definere regler som enten er statiske eller dynamiske.

• Statiske regler: Bruk DAX-uttrykk som refererer til konstanter, for eksempel [Region] = "Midwest".
• Dynamiske regler: Bruk bestemte DAX-funksjoner som returnerer miljøverdier (i motsetning til konstanter). Miljøverdier returneres fra tre spesifikke DAX-funksjoner: USERNAME, USERPRINCIPALNAME og CUSTOMDATA. Det er enkelt og effektivt å definere dynamiske regler når en modelltabell lagrer brukernavnverdier. De lar deg fremtvinge en datadrevet RLS-utforming.

Rolletilordninger for RLS

Når du har publisert modellen til Power Bi-tjeneste, må du konfigurere rolletilordninger før brukere får tilgang til relaterte rapporter. Rolletilordning innebærer å tilordne Microsoft Entra-sikkerhetsobjekter til roller. Sikkerhetsobjekter kan være brukerkontoer eller sikkerhetsgrupper.

Når det er mulig, er det en anbefalt fremgangsmåte å tilordne roller til sikkerhetsgrupper. På denne måten blir det færre tilordninger, og gruppemedlemskapsadministrasjon kan håndteres av eieren av gruppen.

Vi anbefaler at du gjør sikkerhetskontoinformasjon fra Microsoft Entra tilgjengelig for innholdsoppretterne. Ett alternativ er å opprette en dataflyt med data som holdes synkronisert med Microsoft Entra ID. På den måten kan innholdsopprettere integrere dataflytdataene for å produsere en datadrevet semantisk modell.

Tips

Det er mulig å definere en rolle som ikke har noen regler. I dette tilfellet gir rollen tilgang til alle rader i alle modelltabeller. Det er passende å konfigurere denne typen rolle når en administrator eller bruker har tillatelse til å vise alle dataene i modellen.

Brukeropplevelse for RLS

Noen organisasjoner velger å bruke RLS som et sekundært sikkerhetslag, i tillegg til standard Power BI-tillatelser. Vurder følgende scenario: Du deler en kobling til en rapport med hele organisasjonen. Alle brukere som viser rapporten, må tilordnes en RLS-rolle for å kunne se data i rapporten. Hvis de ikke er tilordnet til en RLS-rolle, ser de ingen data.

Tilstedeværelsen av RLS endrer standardopplevelsen for forbrukere.

• Når RLS ikke er definert for semantisk modell: Opprettere og forbrukere med minst lesetillatelse på semantisk modell kan vise alle dataene i den semantiske modellen.
• Når RLS er definert på semantisk modell: Opprettere og forbrukere med bare lesetillatelse på den semantiske modellen vil bare kunne vise dataene de har lov til å se (basert på deres rolletilordning for RLS).

Merk

Noen organisasjoner håndhever RLS som et ekstra sikkerhetslag, spesielt når sensitive data er involvert. Derfor kan du velge å kreve RLS for semantiske modeller som er sertifiserte. Dette kravet kan utføres med en intern gjennomgangs- og godkjenningsprosess før sertifisering av semantisk modell.

Når en bruker viser en rapport i et arbeidsområde eller en app, kan det hende at RLS eller kanskje ikke håndheves avhengig av semantiske modelltillatelser. Derfor er det viktig at innholdsforbrukere og opprettere bare har lesetillatelse på den underliggende semantiske modellen når RLS må håndheves.

Her er tillatelsesreglene som bestemmer om RLS håndheves.

• Brukeren har lesetillatelse på den semantiske modellen: RLS håndheves for brukeren.
• Brukeren har lese- og byggtillatelser på semantisk modell: RLS håndheves for brukeren.
• Brukeren har skrivetillatelse på semantisk modell: RLS håndheves ikke for brukeren, noe som betyr at de kan se alle dataene i den semantiske modellen. Skrivetillatelsen gir mulighet til å redigere en semantisk modell. Det kan gis på én av to måter:
  • Med rollene bidragsyter, medlem eller administratorarbeidsområde (for arbeidsområdet der den semantiske modellen er lagret).
  • Med tillatelsen skriv semantisk modell per element.

Tips

Hvis du vil ha mer informasjon om hvordan du bruker separate arbeidsområder slik at RLS fungerer for innholdsopprettere, kan du se det administrerte selvbetjente BI-bruksscenarioet .

Hvis du vil ha mer informasjon om RLS, kan du se Begrense tilgang til Power BI-modelldata.

RLS for datamarts

Power BI-datamarts kan også fremtvinge RLS. Implementeringen er imidlertid forskjellig.

Hovedforskjellen er at RLS for datamarts er konfigurert i Power Bi-tjeneste i stedet for i Power BI Desktop.

En annen forskjell er at datamarts fremtvinger RLS på både semantisk modell og den administrerte Azure SQL Database som er knyttet til datamart. Bruk av RLS på begge lag gir konsekvens og fleksibilitet. De samme RLS-filtrene brukes uansett hvordan brukeren spør etter dataene, enten det er ved å koble til den semantiske modellen eller til den administrerte Azure SQL Database.

Hvis du vil ha mer informasjon, kan du se RLS for datamarts.

Sikkerhet på objektnivå

Sikkerhet på objektnivå (OLS) gjør det mulig for en datamodellerer å begrense tilgangen til bestemte tabeller og kolonner og metadataene deres. Du bruker vanligvis OLS til å sikre at sensitive kolonner, for eksempel ansattes lønn, ikke er synlige for bestemte brukere. Selv om det ikke er mulig å begrense tilgangen til mål, blir alle mål som refererer til en begrenset kolonne, begrenset.

Vurder et eksempel på en ansatttabell. Den inneholder kolonner som lagrer ansattes navn og telefonnummer, og også lønn. Du kan bruke OLS til å sikre at bare enkelte brukere, for eksempel personaladministrasjon, kan se lønnsverdier. For brukere som ikke kan se lønnsverdier, er det som om kolonnen ikke finnes.

Vær forsiktig, fordi hvis et visualobjekt for Power BI-rapporter inkluderer lønn, vil brukere som ikke har tilgang til dette feltet, få en feilmelding. Meldingen informerer dem om at objektet ikke finnes. For disse brukerne ser det ut til at rapporten er brutt.

Merk

Du kan også definere perspektiver i en datamodell. Et perspektiv definerer synlige delsett av modellobjekter for å bidra til å gi et bestemt fokus for rapportopprettere. Perspektiver er ikke ment å begrense tilgangen til modellobjekter. En bruker kan fortsatt spørre etter en tabell eller kolonne selv når den ikke er synlig for dem. Vurder derfor perspektiver som en brukervennlighet i stedet for en sikkerhetsfunksjon.

Det finnes for øyeblikket ikke et grensesnitt i Power BI Desktop for å konfigurere OLS. Du kan bruke Tabellredigering, som er et tredjepartsverktøy for å opprette, vedlikeholde og administrere modeller. Hvis du vil ha mer informasjon, kan du se det avanserte bruksscenarioet for datamodellbehandling .

Hvis du vil ha mer informasjon om OLS, kan du se Begrense tilgang til Power BI-modellobjekter.

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

• Bestem deg for strategien for bruk av RLS: Vurder hvilke brukstilfeller og formål du har tenkt å bruke sikkerhet på radnivå.
• Bestem deg for strategien for bruk av OLS: Vurder hvilke brukstilfeller og formål du har tenkt å bruke sikkerhet på objektnivå.
• Vurder krav for sertifisert innhold: Hvis du har en prosess for hva som kreves for å sertifisere en semantisk modell, må du bestemme om du vil inkludere bestemte krav for bruk av RLS eller OLS.
• Opprett og publiser brukerveiledning: Opprett dokumentasjon for brukere som inkluderer krav og innstillinger for bruk av RLS og OLS. Beskriv hvordan du henter informasjon om brukertilordning hvis den finnes på en sentralisert plassering.
• Oppdater opplæringsmateriell: Inkluder viktig informasjon om krav og preferanser for RLS og OLS i brukeropplæringsmateriell. Angi eksempler som brukerne kan forstå når det er riktig å bruke en av teknikkene for datasikkerhet.

Relatert innhold

I den neste artikkelen i denne serien kan du lære om sikkerhetsplanlegging for innholdsopprettere som er ansvarlige for å opprette semantiske modeller, dataflyter, datamarts, rapporter eller instrumentbord.