Planlægning af Power BI-implementering: Rapportér planlægning af forbrugersikkerhed

Bemærk

Denne artikel er en del af power BI-implementeringsplanlægningsserierne. I denne serie fokuseres der primært på Power BI-oplevelsen i Microsoft Fabric. Du kan få en introduktion til serien under Planlægning af implementering af Power BI.

I denne artikel om sikkerhedsplanlægning beskrives strategier for skrivebeskyttede forbrugere. Fokus er på visningstilladelser til rapporter og apps, og hvordan du gennemtvinger datasikkerhed. Det er primært rettet mod:

• Power BI-administratorer: De administratorer, der er ansvarlige for at styre Power BI i organisationen.
• Center of Excellence, IT og BI-teamet: De teams, der også er ansvarlige for at holde tilsyn med Power BI. De skal muligvis samarbejde med Power BI-administratorer, informationssikkerhedsteams og andre relevante teams.
• Indholdsoprettere og -ejere: Selvbetjente BI-oprettere, der har brug for at oprette, publicere, sikre og administrere indhold, som andre brugere bruger.

Serien af artikler er beregnet til at udvide indholdet i Hvidbogen om Sikkerhed i Power BI. Selvom hvidbogen om sikkerhed i Power BI fokuserer på vigtige tekniske emner som godkendelse, dataopbevaring og netværksisolering, er det primære mål for serien at give dig overvejelser og beslutninger, der kan hjælpe dig med at planlægge sikkerhed og beskyttelse af personlige oplysninger.

I en organisation klassificeres mange brugere som forbrugere. Forbrugere får vist indhold, som andre brugere har oprettet og publiceret. Forbrugerne er i fokus i denne artikel. Hvis du vil have sikkerhedsplanlægning med fokus på indholdsoprettere og -ejere, skal du se artiklen Planlægning af sikkerhed for indholdsforfattere.

Hvis du vil have mest ud af denne artikel, er det nyttigt at forstå betydningen af begreberne deling og distribution i forbindelse med Power BI.

Deling er det område, hvor en bruger giver en anden bruger (eller gruppe af brugere) adgang til et bestemt indholdselement. Delingsfunktionen i Power BI-tjeneste er begrænset til ét element. Det sker oftest mellem personer, der kender hinanden og arbejder tæt sammen.

Distribution er det, hvor indhold leveres til andre brugere, der er kendt som modtagere. Det involverer ofte et større antal brugere på tværs af flere teams. Modtagerne har muligvis ikke udtrykkeligt anmodet om indholdet, men det anerkendes, at de skal bruge det til at udføre deres rolle. Modtagere, der forbruger distribueret indhold, kender muligvis ikke den oprindelige forfatter af indholdet. Distribution som et begreb er derfor mere formel end deling.

Når du taler med andre personer, skal du afgøre, om de bruger begrebet deling på en generel måde eller bogstaveligt talt. Brugen af orddeling kan fortolkes på to måder.

• Begrebet deling bruges ofte generelt i forbindelse med deling af indhold med kolleger. Der er flere teknikker til levering af skrivebeskyttet indhold, som er beskrevet i denne artikel.
• Deling er også en bestemt funktion i Power BI. Det er en funktion, hvor en bruger eller gruppe tildeles adgang til et enkelt element. Delingslinks og direkte adgangsdeling er beskrevet i denne artikel.

Vigtigt

Rollen Power BI-administrator er blevet omdøbt. Det nye navn på rollen er Fabric-administrator.

Strategi for skrivebeskyttede forbrugere

I Power BI-tjeneste kan forbrugere få vist en rapport eller et dashboard, når de har tilladelse til begge dele:

• Få vist det Power BI-element, der indeholder visualiseringerne (f.eks. en rapport eller et dashboard).
• Læs de underliggende data (semantisk model – tidligere kendt som et datasæt – eller en anden kilde).

Du kan give skrivebeskyttet adgang til forbrugere ved hjælp af forskellige teknikker. De almindelige teknikker, der bruges af oprettere af indhold via selvbetjening, omfatter:

• Give brugere og grupper adgang til en Power BI-app.
• Tilføjelse af brugere og grupper til en Rolle i Power BI-arbejdsområdefremviser.
• Giver brugere og grupper tilladelser pr. element ved hjælp af et delingslink.
• Giver brugere og grupper tilladelser pr. element ved hjælp af direkte adgang.

Rolleindstillingerne for Power BI-appen og Power BI-arbejdsområdefremviseren omfatter administration af tilladelser til et sæt elementer. De to teknikker til tilladelser pr. element omfatter administration af tilladelser for ét enkelt element.

Tip

Generelt er det bedste praksis at bruge en Power BI-app til de fleste forbrugere. Nogle gange kan rollen som læser af arbejdsområdet også være passende. Både Power BI-apps og rollen arbejdsområdefremviser tillader administration af tilladelser for mange elementer og bør bruges, når det er muligt. Det kan være kedeligt, tidskrævende og fejludseende at administrere tilladelser for individuelle elementer. I modsætning hertil reducerer administrationen af et sæt elementer vedligeholdelsen og forbedrer nøjagtigheden.

Når du gennemser sikkerhedsindstillingerne for et element, kan du muligvis se, at dets tilladelser er:

• Nedarvet fra arbejdsområdet eller en app.
• Anvendes direkte på elementet.

På følgende skærmbillede vises tilladelserne til direkte adgang for en rapport. I dette tilfælde tildeles rollerne Administration og Medlem til en gruppe. Disse roller vises for rapporten, fordi adgangen på rapportniveau nedarves fra arbejdsområdet. Der er også én bruger, der har tilladelsen Læs anvendt direkte på rapporten.

Den strategi, du vælger for skrivebeskyttede forbrugere, kan være anderledes. Den bør baseres på den enkelte løsning, præferencerne for, hvem der administrerer løsningen, eller forbrugernes behov. I resten af dette afsnit beskrives det, hvornår du skal overveje at bruge hver af de tilgængelige teknikker.

Tjekliste – Når du opretter din strategi for, hvordan du leverer indhold til skrivebeskyttede forbrugere, omfatter vigtige beslutninger og handlinger:

• Vurder din eksisterende strategi for skrivebeskyttede forbrugere: Kontrollér, hvordan indhold i øjeblikket distribueres og deles med forbrugere. Identificer, om der er muligheder for forbedring.
• Beslut din strategi for skrivebeskyttede forbrugere: Overvej, hvad dine indstillinger er for at bruge apptilladelser, arbejdsområderoller eller tilladelser pr. element. Hvis det er nødvendigt at ændre disse indstillinger, skal du oprette en plan for at foretage forbedringer.

Tilladelser til Power BI-apps

En Power BI-app leverer en samling af rapporter, dashboards og projektmapper til forbrugere. En app giver forbrugerne den bedste brugeroplevelse, fordi:

• Appens navigationsrude giver en enkel og intuitiv brugeroplevelse. Det er en bedre oplevelse end at få adgang til indhold direkte i et arbejdsområde.
• Indhold kan organiseres logisk i sektioner (som mapper) i appens navigationsrude.
• Forbrugere har kun adgang til bestemte elementer, der udtrykkeligt er inkluderet i appen for deres målgruppe.
• Links til yderligere oplysninger, dokumentation eller andet indhold kan føjes til navigationsruden for deres målgruppe.
• Der er en indbygget arbejdsproces for anmodningsadgang .

Bemærk

Alle referencer til en app i denne artikel henviser til en Power BI-app. Det er et andet koncept end Power Apps. Det er også et andet koncept end Power BI-mobilappsene. I dette afsnit fokuseres der på organisationsapps i stedet for skabelonapps.

Du kan oprette én app for hvert arbejdsområde som en formel måde at distribuere noget eller alt arbejdsområdeindhold på. Apps er en god måde at distribuere indhold bredt i en organisation, især til brugere, som du ikke kender eller ikke arbejder tæt sammen med.

Tip

Du kan finde flere oplysninger om, hvordan du bruger en Power BI-app til bred indholdsdistribution, i virksomhedsscenariet for BI-forbrug . Vi anbefaler, at indholdsoprettere, der har brug for at distribuere indhold, overvejer at oprette en app som deres første valg.

Du administrerer apptilladelser separat fra arbejdsområderoller. Adskillelsen af tilladelser har to fordele. Det opfordrer til:

• Tildeling af arbejdsområdeadgang til indholdsoprettere. Det omfatter brugere, der aktivt samarbejder om indholdet, f.eks. semantiske modeloprettere, rapportoprettere og testere.
• Tildeling af apptilladelser til forbrugere. I modsætning til arbejdsområdetilladelser er apptilladelser altid skrivebeskyttede (eller ingen).

Alle brugere med adgang til arbejdsområdet kan automatisk få vist appen (når der er publiceret en Power BI-app til arbejdsområdet). På grund af denne funktionsmåde kan du konceptuelt tænke på arbejdsområderoller som nedarvet af hver appmålgruppe. Nogle brugere med adgang til arbejdsområdet kan også opdatere Power BI-appen, afhængigt af deres tildelte arbejdsområderolle.

Tip

Du kan finde flere oplysninger om adgang til arbejdsområdet i artiklen Planlægning af sikkerhed for indholdsoprettere.

Det bedste valg er at bruge en app til at distribuere indhold til skrivebeskyttede forbrugere, når:

• Du ønsker, at brugerne kun skal kunne få vist bestemte elementer, der er synlige for den pågældende målgruppe (i stedet for alle elementer i det underliggende arbejdsområde).
• Du vil administrere skrivebeskyttede tilladelser for appen separat fra arbejdsområdet.
• Du vil have mere enkel administration af tilladelser for skrivebeskyttede brugere end tilladelser pr. element.
• Du vil sikre, at sikkerhed på rækkeniveau gennemtvinges for forbrugere (når de har skrivebeskyttet tilladelse til den underliggende semantiske model).
• Du vil sikre dig, at forbrugerne ikke kan få vist nye og ændrede rapporter, før appen publiceres igen.

Selvom det er sandt, at ændringer af rapporter og dashboards ikke er synlige for brugerne af appen, før appen publiceres igen, er der to overvejelser, der kræver forsigtighed.

• Øjeblikkelige ændringer af semantiske modeller: Semantiske modelændringer træder altid i kraft med det samme. Hvis du f.eks. introducerer banebrydende ændringer af en semantisk model i arbejdsområdet, kan det utilsigtet resultere i, at rapporter bliver ustabile (selvom de ikke er blevet publiceret igen i appen). Der er to måder at afhjælpe denne risiko på: Først skal du udføre alt udviklingsarbejde i Power BI Desktop (adskilt fra arbejdsområdet). For det andet skal du isolere produktionsappen ved hjælp af separate arbejdsområder til udvikling og test. (Du kan også opnå et højere niveau af kontrol over udrulning af arbejdsområdeindhold fra udvikling til test og produktion ved hjælp af udrulningspipelines).
• Indhold og tilladelser publiceres sammen: Når du publicerer en app, publiceres tilladelserne samtidig med indholdet. Du kan f.eks. have rapportændringer i et arbejdsområde, der endnu ikke er fuldført, fuldt testet eller godkendt. Så du kan ikke publicere appen igen blot for at opdatere tilladelser. Du kan afhjælpe denne risiko ved at tildele apptilladelser til sikkerhedsgrupper og bruge medlemskaber af sikkerhedsgrupper (i stedet for individuelle brugere), når du tildeler apptilladelser. Undgå at publicere en app igen blot for at anvende ændringer af tilladelser.

Appmålgruppe

Hvert arbejdsområde i Power BI-tjeneste kan kun have én Power BI-app. Du kan dog oprette en eller flere målgrupper i appen. Overvej følgende scenarie.

• Du har fem salgsrapporter, der distribueres til mange brugere i hele din globale salgsorganisation.
• Der er defineret én målgruppe i appen for sælgerne. Denne målgruppe kan få vist tre af de fem rapporter.
• Der er defineret en anden målgruppe i appen for salgsledelsesteamet. Denne målgruppe kan få vist alle fem rapporter, herunder de to rapporter, der ikke er tilgængelige for sælgere.

Denne mulighed for at blande og matche indhold og målgrupper har følgende fordele.

• Visse rapporter kan være tilgængelige for visning af flere målgrupper. Oprettelse af flere målgrupper fjerner derfor behovet for at duplikere indhold på tværs af forskellige arbejdsområder.
• Visse rapporter bør kun være tilgængelige for én målgruppe. Indhold for den ene målgruppe kan derfor være placeret i det samme arbejdsområde som andet relateret indhold.

Følgende skærmbillede viser en app med to målgrupper: Sales Leadership og Sales Reps. Ruden Administrer målgruppeadgang giver adgang til målgruppegruppen Sales Leadership for to sikkerhedsgrupper: Sales Leadership-Nordamerika og Sales Leadership-Europe. Rapporten Bruttoavanceanalyse , der vises på skærmbilledet for målgruppegruppen Salgsledelse , er ikke tilgængelig for målgruppegruppen Sælgere .

Bemærk

Begrebet målgruppegruppe bruges nogle gange. Det er ikke en direkte reference til brugen af sikkerhedsgrupper. Det omfatter medlemmer af målgruppen, der kan se samlingen af indhold i en Power BI-app. Selvom du kan tildele individuelle brugere til en målgruppe, er det bedste praksis at tildele sikkerhedsgrupper, Microsoft 365-grupper eller distributionsgrupper, når det er praktisk. Du kan få flere oplysninger i strategien for brug af grupper i artiklen Planlægning af sikkerhed på lejerniveau.

Når du administrerer tilladelser for en app, kan du på siden Direkte adgang få vist medlemmerne af hver målgruppe. Du kan også se brugere med en arbejdsområderolle, der er angivet under Målgruppen Alle . Du kan ikke opdatere apptilladelserne fra siden Direct Access . Du skal i stedet publicere appen igen. Du kan dog opdatere apptilladelser fra siden Ventende, når der er anmodninger om åben adgang for appen.

Tip

Den primære use case til brug af appmålgrupper er at definere specifikke tilladelser for forskellige brugersæt. Du kan dog blive lidt kreativ, når du bruger målgrupper. En bruger kan være medlem af flere målgrupper, og hver målgruppe vises for brugerne af appen som et sekundært sæt menuer. Du kan f.eks. oprette en målgruppe med navnet Start her , der indeholder oplysninger om, hvordan du bruger appen, hvem du skal kontakte, hvordan du giver feedback, og hvordan du får hjælp. Du kan også oprette en målgruppe med navnet KPI-definitioner , der indeholder en dataordbog. Hvis du angiver denne type oplysninger, hjælper det nye brugere og gør det nemmere at indføre løsninger.

Indstillinger for apptilladelser

Når du opretter (eller publicerer) en app igen, har hver målgruppe ruden Administrer målgruppeadgang . I ruden er følgende tilladelser tilgængelige.

• Giv adgang til: For hver målgruppe kan du give adgang til individuelle brugere og grupper. Det er muligt at publicere appen til hele organisationen, når den er aktiveret af lejerindstillingen Publicer apps til hele organisationen , og appen ikke installeres automatisk. Når det er muligt, anbefaler vi, at du tildeler grupper til målgrupper, fordi tilføjelse eller fjernelse af brugere omfatter publicering af appen igen. Alle med adgang til arbejdsområdet har automatisk tilladelse til at få vist eller opdatere appen, afhængigt af deres rolle i arbejdsområdet.
• Semantiske modeltilladelser: Der kan tildeles to typer semantiske modeltilladelser under publicering af en app:
  • Deling af semantisk model: Når den er aktiveret, tildeles appbrugerne tilladelsen Del igen til den eller de underliggende semantiske modeller med andre. Det giver mening at aktivere denne indstilling, når den eller de underliggende semantiske modeller nemt kan deles med alle. Vi anbefaler, at du får godkendelse fra den eller de semantiske modelejere, før du tildeler tilladelsen Del igen til en appmålgruppe.
  • Semantisk modelbuild: Når den er aktiveret, tildeles appbrugerne tilladelsen Opret for de semantiske modeller. Tilladelsen Opret giver brugerne mulighed for at oprette nye rapporter, eksportere underliggende data fra rapporter med mere. Vi anbefaler, at du får godkendelse fra den eller de semantiske modelejere, før du tildeler tilladelsen Opret til en appmålgruppe.

Det er praktisk at tilføje tilladelserne Tildel semantisk model igen eller Opret, mens du publicerer en app. Vi anbefaler dog, at du overvejer at administrere apptilladelser og semantiske modeltilladelser separat. Her er årsagerne.

• Delt semantisk model kan være i et separat arbejdsområde: Hvis den semantiske model publiceres til et separat arbejdsområde fra appen, skal du administrere dens tilladelser direkte. Muligheden for at tilføje tilladelserne Læs, Opret eller Del igen, mens du publicerer en app, fungerer kun for semantiske modeller, der er i det samme arbejdsområde som appen. Derfor anbefaler vi, at du bruger den vane at administrere semantiske modeltilladelser uafhængigt af hinanden.
• Semantiske modeltilladelser administreres separat: Hvis du fjerner eller ændrer tilladelser for en app, påvirker denne handling kun appen. Den fjerner ikke automatisk semantiske modeltilladelser, der tidligere er tildelt. På denne måde kan du tænke på apptilladelser og semantiske modeltilladelser som afkoblet. Du skal administrere den semantiske model direkte, separat fra appen, når semantiske modeltilladelser ændres eller skal fjernes.
• Semantiske modeltilladelser skal styres: Tildeling af semantiske modeltilladelser via en app fjerner kontrolelementet fra ejeren af den semantiske model. Tildeling af tilladelsen Del igen afhænger af god dømmekraft fra brugere, der vælger at dele den eller de semantiske modeller igen. Dine retningslinjer for intern styring eller sikkerhed kan blive vanskeligere at administrere, når videredeling er tilladt.
• Forbrugere og oprettere har forskellige mål: Der er typisk mange flere indholdsforbrugere end oprettere i en organisation. I overensstemmelse med princippet om færrest mulige rettigheder skal forbrugerne kun have læsetilladelse til den underliggende semantiske model. De behøver ikke tilladelsen Opret, medmindre de har til hensigt at oprette nye rapporter.

Tip

Du kan få flere oplysninger om, hvornår du skal bruge separate dataarbejdsområder og rapporteringsarbejdsområder, i artiklen Planlægning på arbejdsområdeniveau .

Rettigheder til forudinstallation af app

Når du har publiceret en Power BI-app, skal en bruger typisk installere den, så vedkommende kan åbne den. En bruger kan installere en app fra siden Apps i Power BI-tjeneste eller ved hjælp af et link, vedkommende har modtaget fra en anden bruger. De kan finde (og installere) en app, når de er inkluderet i mindst én målgruppe af appen.

En alternativ metode til at installere en app er at pushe den til appforbrugere. Det resulterer i forudinstallationen af appen, så den automatisk vises på siden Apps i Power BI-tjeneste. Denne fremgangsmåde er praktisk for forbrugerne, fordi de ikke behøver at finde og installere appen. Forudinstallerede apps kan dog blive en irritation for brugerne, fordi de kan blive overvældet af for mange apps, der ikke er relevante for dem.

Lejerindstillingen Push apps til slutbrugere styrer, hvem der har tilladelse til automatisk at installere apps. Vi anbefaler, at du bruger denne funktion, fordi den er praktisk for brugerne. Vi anbefaler dog også, at du oplære dine indholdsoprettere i, hvornår de skal bruge det, så det ikke overforbruges.

Tip

Hvis du vælger indstillingen for at installere appen automatisk, når du publicerer en app, kan du ikke angive, at målgruppen skal være hele organisationen (hvis den er aktiveret af lejerindstillingen Push-apps til slutbrugere ).

Tjekliste – Når du opretter din strategi for brug af apps til indholdsfremvisere, omfatter vigtige beslutninger og handlinger:

• Beslut strategien for brug af apps: Definer dine indstillinger for, hvordan du bruger apps. Sørg for, at den stemmer overens med din overordnede strategi for skrivebeskyttede forbrugere.
• Beslut, hvem der kan publicere apps til hele organisationen: Beslut, hvilke rapportoprettere der kan publicere til hele organisationen. Angiv indstillingen Publicer apps til hele organisationens lejer for at justere denne beslutning.
• Beslut, hvem der kan pushe apps til slutbrugere: Beslut, hvilke power BI-rapportoprettere der kan forudinstallere apps. Angiv lejerindstillingen Push apps til slutbrugere for at tilpasse sig denne beslutning.
• Opret og udgiv vejledning til indholdsoprettere: Angiv dokumentation og oplæring for indholdsforfattere. Medtag krav og indstillinger for, hvordan du bruger apps mest effektivt.
• Bestem, hvordan du skal håndtere anmodninger om appadgang: Sørg for, at der er en proces på plads for at tildele kontakter og håndtere anmodninger om appadgang rettidigt.

Rollen Arbejdsområdefremviser

Som beskrevet i artiklerne om planlægning af arbejdsområdet er det primære formål med et arbejdsområde samarbejde. Arbejdsområdepartnere, f.eks. semantiske modeloprettere, rapportoprettere og testere, skal tildeles til en af tre roller: Bidragyder, Medlem eller Administration. Disse roller er beskrevet i artiklen Sikkerhedsplanlægning for indholdsforfattere.

Du kan tildele rollen læser i arbejdsområdet til forbrugere. Det kan give mening for små teams og uformelle teams, der arbejder tæt sammen, at give forbrugerne adgang til indhold direkte i et arbejdsområde.

Det er et godt valg at give forbrugere adgang til indhold i arbejdsområdet direkte, når:

• Formaliteten for en app med separate tilladelser er ikke nødvendig.
• Seere har tilladelse til at få vist alle elementer, der er gemt i arbejdsområdet.
• Du vil have mere enkel administration af tilladelser end tilladelser pr. element.
• Brugere af arbejdsområdet kan også få vist en app (når en app publiceres til arbejdsområdet).
• Det er meningen, at seerne skal gennemse indhold, før det publiceres i en app.

Her er nogle forslag til, hvordan du understøtter brugere af arbejdsområder.

• Organiser indhold i hvert arbejdsområde, så elementerne nemt kan lokaliseres af rapportforbrugere, så de passer godt sammen med sikkerheden. Arbejdsområdeorganisation efter emneområde eller projekt fungerer normalt godt.
• Adskil udviklings- og testindhold fra produktionsindhold, så seere ikke kan få adgang til igangværende elementer.
• Brug apps (eller tilladelser pr. element, når det er relevant), når du forventer at have mange adgangsanmodninger at behandle. Der er ikke en arbejdsproces for anmodning om adgang til arbejdsområder.

Tjekliste – Når du opretter din strategi for brug af arbejdsområder til indholdsfremvisere, omfatter vigtige beslutninger og handlinger:

• Beslut en strategi for brug af rollen arbejdsområdefremviser: Definer dine indstillinger for, hvordan du bruger arbejdsområder til forbrugere. Sørg for, at den stemmer overens med din overordnede strategi for skrivebeskyttede forbrugere.
• Opret og udgiv vejledning til indholdsoprettere: Angiv dokumentation og oplæring for indholdsforfattere. Medtag krav og indstillinger for, hvordan du bruger tilladelser til arbejdsområdet mest effektivt.

Tilladelser pr. element

Deling af individuelle elementer giver tilladelse til et enkelt element. Mindre erfarne indholdsforfattere bruger ofte denne teknik som den primære delingsteknik, fordi delingskommandoerne vises tydeligt i Power BI-tjeneste. Derfor er det vigtigt at oplære dine indholdsoprettere i de forskellige delingsindstillinger, herunder hvornår du skal bruge apptilladelser i stedet for arbejdsområderoller.

Tilladelser pr. element er et godt valg, når:

• Du vil give skrivebeskyttet adgang til ét element (rapport eller dashboard).
• Du ønsker ikke, at forbrugeren skal se alt indhold, der er publiceret i et arbejdsområde.
• Du ønsker ikke, at forbrugeren skal se alt indhold, der er publiceret til en appmålgruppe.

Brug tilladelser pr. element sparsomt, fordi deling giver læsetilladelse til et enkelt element. På en måde kan du tænke på tilladelser pr. element som en tilsidesættelse af arbejdsområderoller eller apptilladelser.

Tip

Vi anbefaler, at du bruger apptilladelser, når det er muligt. Overvej derefter at bruge arbejdsområderoller til at aktivere direkte adgang til arbejdsområder. Endelig skal du bruge tilladelser pr. element, når de opfylder ovenstående kriterier. Apptilladelser og arbejdsområderoller angiver begge sikkerhed for en samling af indhold (i stedet for individuelle elementer), hvilket er en bedre sikkerhedspraksis.

Det kan være kedeligt at dele mange elementer ved hjælp af tilladelser pr. element, og der kan opstå fejl, især når du deler med individuelle brugere i stedet for grupper. Overvej dette scenarie: Du har 40 rapporter, som du har delt med kolleger ved hjælp af deres individuelle brugerkonti. Når en kollega overføres til en anden afdeling, skal du tilbagekalde vedkommendes adgang, hvilket omfatter redigeringstilladelser til alle 40 rapporter.

Vigtigt

Deling af indhold fra et personligt arbejdsområde bør ske sjældent. Personlige arbejdsområder er bedst egnet til ikke-kritisk, uformelt eller midlertidigt indhold. Hvis du har en situation, hvor indholdsoprettere ofte deler vigtigt eller kritisk indhold fra deres personlige arbejdsområder, skal du træffe de nødvendige foranstaltninger for at flytte indholdet til et standardarbejdsområde. Du kan få flere oplysninger i det personlige BI-forbrugsscenarie .

Når du deler et enkelt element, har du flere tilladelsesindstillinger.

• Tilladelse til at dele igen: Når den er aktiveret, kan brugerne dele elementet med andre brugere, herunder de underliggende semantiske modeller. Det giver mening at give denne tilladelse, når elementet nemt kan deles med alle. Det fjerner kontrolelementet fra den person eller det team, der administrerer elementet. Så den er afhængig af god dømmekraft fra brugere, der har fået tilladelsen Del igen. Dine retningslinjer for intern styring eller sikkerhed kan dog blive vanskeligere at administrere, når videredeling er tilladt.
• Tilladelsen Opret: Når indstillingen er aktiveret, tildeles brugerne tilladelsen Opret for den underliggende semantiske model. Tilladelsen Opret giver brugerne mulighed for at oprette nyt indhold, der er baseret på den semantiske model. Det giver dem også mulighed for at eksportere underliggende data fra rapporter og meget mere. Overvejelser i forbindelse med tildeling af tilladelsen Opret er beskrevet i artiklen Planlægning af sikkerhed for indholdsforfattere.

Tilladelser pr. element for rapporter og dashboards kan give mening for uformelle scenarier, når indhold deles med nogle få brugere. Det er en god idé at oplære brugerne i at administrere tilladelser med apps og arbejdsområder i stedet, især når de deler indhold med et stort antal brugere eller brugere uden for deres team. Det er vigtigt at understrege følgende punkter.

• Det bliver sværere at afgøre, hvilket indhold der er blevet delt med hvilke brugere, fordi tilladelserne til hver rapport og hvert dashboard skal gennemses individuelt.
• I mange tilfælde er tilladelsen Del igen angivet, fordi brugeroplevelsen som standard aktiverer denne indstilling. Der er derfor en risiko for, at indhold deles med et bredere sæt brugere end tiltænkt. Dette resultat kan forhindres ved at fjerne markeringen af indstillingen Tillad, at modtagerne deler denne rapport , når de deler. Minimering af overdeling på denne måde er et problem med brugertræning. Den indholdsopretter, der angiver delingstilladelserne, bør overveje dette valg hver gang.
• Alle ændringer af rapporter og dashboards kan straks ses af andre, hvilket kan forvirre brugerne, når indholdsændringer er et igangværende arbejde. Dette problem kan afhjælpes ved at distribuere indhold i en app eller ved at bruge separate arbejdsområder til at adskille udviklings-, test- og produktionsindhold. Du kan finde flere oplysninger i brugsscenariet for publicering af indhold via selvbetjening.
• Når en bruger deler indhold fra sit personlige arbejdsområde, og vedkommende forlader organisationen, deaktiverer it-virksomheden normalt sin brugerkonto. I dette tilfælde mister alle modtagere af det delte indhold straks adgang til indholdet.

Der er tre specifikke typer deling: delingslinks, direkte adgangsdeling og delte visninger.

Links til tilladelser pr. element

Når du deler et individuelt element, resulterer standardoplevelsen i et delingslink. Der er tre typer delingslinks.

• Mennesker i din organisation: Når indstillingen er aktiveret i dine Power BI-lejerindstillinger, er denne type delingslink en nem måde at give skrivebeskyttet adgang til alle i organisationen. Delingslinket fungerer dog ikke for eksterne brugere. Denne indstilling er bedst egnet til, når alle kan få vist indholdet, og linket kan frit deles i hele organisationen. Medmindre den er deaktiveret af lejerindstillingen Tillad, at links, der kan deles, giver adgang til alle i organisationen , er denne type deling standard.
• Mennesker med eksisterende adgang: Denne indstilling opretter ikke et nyt delingslink. Det giver dig i stedet mulighed for at hente URL-adressen, så du kan sende den til en person, der allerede har adgang.
• Bestemte personer: Denne indstilling opretter et delingslink til bestemte brugere eller grupper. Vi anbefaler, at du bruger denne indstilling det meste af tiden, fordi den giver specifik adgang. Hvis du ofte arbejder med eksterne brugere, kan du bruge denne type link til gæstebrugere, der allerede findes i Microsoft Entra ID (tidligere kendt som Azure Active Directory). Du kan få flere oplysninger om den planlagte invitationsproces til oprettelse af gæstebrugere i artiklen Planlægning af sikkerhed på lejerniveau.

Vigtigt

Vi anbefaler, at du overvejer at begrænse indstillingen Tillad links, der kan deles, for at give adgang til alle i organisationens lejer til medlemmer af en gruppe. Du kan oprette et gruppenavn, f.eks . Power BI Del i hele organisationen, og derefter tilføje et lille antal brugere, der forstår konsekvenserne af deling i hele organisationen. Hvis du er bekymret for eksisterende links for hele organisationen, kan du bruge administrations-API'en til at finde alle elementer, der er blevet delt med hele organisationen.

Et delingslink føjer tilladelsen Læs til elementet. Tilladelsen Del igen er valgt som standard. Det er også muligt at føje tilladelsen Opret til den underliggende semantiske model på samme tid, som delingslinket oprettes.

Tip

Vi anbefaler, at du lærer indholdsforfattere at aktivere tilladelsen Opret kun , når forbrugeren af rapporten også er indholdsopretter, som muligvis skal oprette rapporter, eksportere data eller oprette en sammensat model ud fra den underliggende semantiske model.

Delingslinks er nemmere at vedligeholde end direkte adgangsdeling, især når du har brug for at foretage masseændringer. Det er en betydelig fordel, når individuelle brugere tildeles delingstilladelser, i højere grad end grupper (hvilket ofte forekommer, når brugere med selvbetjening er ansvarlige for at administrere tilladelser). Overvej følgende sammenligninger.

• Delingslink: 20 individuelle brugere får adgang med et delingslink. Med en enkelt ændring af linket påvirker det alle 20 brugere.
• Direkte adgang: 20 personer får direkte adgang til et element. Hvis du vil foretage en ændring, skal alle 20 brugertilladelser ændres.

Tilladelser til direkte adgang pr. element

Du kan også opnå tilladelser pr. element ved hjælp af direkte adgang. Direkte adgang omfatter konfiguration af tilladelserne for et enkelt element. Du kan også bestemme nedarvede tilladelser, der er afledt af arbejdsområderoller.

Når du giver en bruger direkte adgang, får vedkommende tilladelsen Læs for elementet. Tilladelsen Del igen er valgt som standard, og det samme er tilladelsen Opret for den underliggende semantiske model. Vi anbefaler, at du kun lærer indholdsforfattere at aktivere tilladelsen Opret, når forbrugeren af denne rapport også er en indholdsforfatter, der muligvis skal oprette rapporter, eksportere data eller oprette sammensatte modeller ud fra den underliggende semantiske model.

Tip

Brugeroplevelsen gør det meget nemt at tildele tilladelserne Del igen og Opret, men den bruger, der foretager delingen, skal altid kontrollere, om disse tilladelser er nødvendige.

Delte visninger

Brug en delt visning til at dele et filtreret perspektiv i en rapport med en anden bruger. Du kan publicere en delt visning ved hjælp af et delingslink eller ved hjælp af direkte adgang.

Delte visninger er et midlertidigt koncept. De udløber automatisk efter 180 dage. Delte visninger er derfor bedst egnet til uformelle og midlertidige delingsscenarier. Sørg for, at brugerne er opmærksomme på denne begrænsning.

Tjekliste – Når du opretter din strategi for brug af tilladelser pr. element, omfatter vigtige beslutninger og handlinger:

• Beslut strategien for brug af delingsfunktionen: Definer, hvad dine indstillinger er for, hvordan tilladelser pr. element skal bruges. Sørg for, at den stemmer overens med din overordnede strategi for skrivebeskyttede forbrugere.
• Beslut, hvem der kan publicere links til hele organisationen: Beslut, hvilke rapportoprettere der kan publicere links for hele organisationen. Angiv indstillingen Tillad deling af links for at give adgang til alle i din organisations lejer for at tilpasse sig denne beslutning.
• Opret og udgiv vejledning til indholdsforfattere: Angiv dokumentation og oplæring for indholdsforfattere, der indeholder krav og indstillinger for, hvordan tilladelser pr. element bruges mest effektivt. Sørg for, at de er klar over fordelene og ulemperne ved tilladelser pr. element. Medtag vejledning til, hvornår du skal bruge delingslinks, og hvornår du skal bruge direkte adgangsdeling.

Andre teknikker til forbrugerforespørgslen

De mest almindelige måder for forbrugere at interagere med Power BI er med apps, arbejdsområder og tilladelser pr. element (tidligere beskrevet i denne artikel).

Der er andre teknikker, som forbrugerne kan bruge til at forespørge Power BI-data. Hver af følgende forespørgselsteknikker kræver semantisk model eller tilladelse til oprettelse af datamart.

• Analysér i Excel: Forbrugere, der foretrækker at bruge Excel, kan forespørge en semantisk Power BI-model ved hjælp af Analysér i Excel. Denne funktion er et godt alternativ til eksport af data til Excel, fordi dataene ikke duplikeres. Med en direkte forbindelse til den semantiske model kan brugerne oprette pivottabeller, diagrammer og udsnit. De kan derefter publicere projektmappen til et arbejdsområde i Power BI-tjeneste, hvilket giver forbrugerne mulighed for at åbne den og interagere med den.
• XMLA-slutpunkt: Forbrugere kan forespørge en semantisk model ved at oprette forbindelse til XMLA-slutpunktet. Et program, der er XMLA-kompatibelt, kan oprette forbindelse til, forespørge på og bruge en semantisk model, der er gemt i et Premium-arbejdsområde. Denne funktion er nyttig, når forbrugere vil bruge en semantisk Power BI-model som datakilde til et datavisualiseringsværktøj uden for Microsofts økosystem.
• Datamart-editor: Forbrugere kan forespørge en Power BI-datamart ved hjælp af datamarteditoren. Det er en webbaseret forespørgselseditor til visualiseringer til oprettelse af forespørgsler uden kode. Der er også en webbaseret SQL-editor, når forbrugere foretrækker at skrive SQL-forespørgsler. Begge editorer forespørger den administrerede Azure SQL Database, der ligger til grund for Power BI-datamart (i stedet for den indbyggede semantiske model).
• SQL-slutpunkt: Forbrugere kan forespørge en Power BI-datamart ved hjælp af SQL-slutpunktet. De kan bruge værktøjer som Azure Data Studio eller SQL Server Management Studio (SSMS) til at køre SQL-forespørgsler. SQL-slutpunktet sender forespørgsler til den administrerede Azure SQL Database, der ligger til grund for Power BI-datamart (i stedet for den indbyggede semantiske model).

Du kan finde flere oplysninger om tilladelsen Opret i artiklen Planlægning af sikkerhed for indholdsoprettere.

Tjekliste – Når du planlægger, hvilke forespørgselsteknikker forbrugerne skal bruge, omfatter vigtige beslutninger og handlinger:

• Opret vejledning til brugere om brug af Analysér i Excel: Angiv dokumentation og oplæring til forbrugere på den bedste måde at genbruge eksisterende semantiske modeller med Excel.
• Opret vejledning til brugere om brug af XMLA-slutpunktet: Angiv dokumentation og oplæring til forbrugere på den bedste måde til at genbruge eksisterende semantiske modeller med XMLA-slutpunktet.
• Opret vejledning til brugere om datamartforespørgsler: Angiv dokumentation og oplæring til forbrugere om de tilgængelige teknikker til forespørgsel af Power BI-datamarts.

Anmod om adgangsarbejdsproces for forbrugere

Når du deler indhold, er det almindeligt, at én bruger videresender et link (URL-adresse) til en anden bruger. Når modtageren forsøger at få vist indholdet og opdager, at vedkommende ikke har adgang til det, kan vedkommende vælge knappen Anmod om adgang . Denne handling starter arbejdsprocessen Anmod om adgang . Brugeren bliver derefter bedt om at angive en meddelelse for at forklare, hvorfor vedkommende ønsker adgang.

Der findes en arbejdsproces for anmodning om adgang til:

• Adgang til en Power BI-app.
• Adgang til et element, f.eks. en rapport eller et dashboard.
• Adgang til en semantisk model. Du kan finde flere oplysninger om arbejdsprocessen for anmodning om adgang, når en semantisk model kan findes, i artiklen Planlægning af sikkerhed for indholdsoprettere.

Anmodninger om appadgang

Der er to måder at få mere at vide om ventende adgangsanmodninger, der er sendt til en app.

• Mail: Kontakterne for appen modtager en mailmeddelelse. Denne kontakt er som standard appudgiveren. Hvis du vil yde bedre support til vigtige apps, anbefaler vi, at du angiver kontakten til en gruppe, der kan svare hurtigt på anmodninger om adgang.
• Menuen Administrer tilladelser: Administratorer og medlemmer af arbejdsområdet kan få vist, godkende eller afvise anmodninger om adgang. Siden Administrer tilladelser er tilgængelig på siden Apps og kan åbnes for hver app. Denne funktion er også tilgængelig for bidragydere til arbejdsområder, når indstillingen Tillad, at bidragydere opdaterer appen for dette arbejdsområde er aktiveret.

Ventende adgangsanmodninger for en app viser den meddelelse, som brugeren har angivet. Hver ventende anmodning kan godkendes eller afvises. Når du vælger at godkende en anmodning, skal der vælges en appmålgruppe.

På følgende skærmbillede vises en ventende anmodning om adgang fra en bruger. Hvis du vil godkende den, skal en af de to appmålgrupper, Sælgere eller Salgsledelse, vælges.

Når du publicerer en app, publiceres indholdet og tilladelserne på samme tid. Som tidligere beskrevet er det ikke muligt kun at publicere apptilladelserne uden indholdsændringer. Der er dog én undtagelse: Når du godkender en ventende adgangsanmodning (f.eks. den, der blev vist på det forrige skærmbillede), sker tilladelsesændringen uden at publicere det seneste indhold i arbejdsområdet.

Anmodninger om adgang til arbejdsområde

Adgang til arbejdsområdet tildeles af brugere, der tilhører rollen Administration eller rollen Medlem.

En bruger, der forsøger at få vist et arbejdsområde, modtager en meddelelse om adgang nægtet , når vedkommende ikke er medlem af en arbejdsområderolle. Da der ikke er en indbygget arbejdsproces for anmodningsadgang for arbejdsområder, bruges de bedst til små teams og uformelle teams, der arbejder tæt sammen. Det er en af grundene til, at en Power BI-app er bedre egnet til større teams og bredere scenarier med indholdsdistribution.

Anmodninger om adgang pr. element

Der er to måder at få mere at vide om ventende adgangsanmodninger, der er sendt for et enkelt element, f.eks. en rapport.

• Mail: Kontakterne for elementet modtager en mailmeddelelse. For at yde bedre support til kritiske rapporter anbefaler vi, at du angiver kontakten til en gruppe, der kan svare hurtigt på anmodninger om adgang.
• Menuen Administrer tilladelser: Administratorer og medlemmer af arbejdsområdet kan få adgang til siden Administrer tilladelser for hvert element. De kan få vist, godkende eller afvise ventende anmodninger om adgang.

Administrer adgangsanmodninger med grupper

Når en bruger sender formularen Anmod om adgang for et Power BI-element (f.eks. en rapport eller semantisk model) eller en Power BI-app, sendes anmodningen til en enkelt bruger. Mange store organisationer skal dog bruge grupper til at overholde deres interne sikkerhedspolitikker.

Vi anbefaler, at du bruger grupper i stedet for enkeltpersoner til at beskytte indhold, når det er praktisk. Du kan få flere oplysninger om planlægning af grupper i artiklen Planlægning af sikkerhed på lejerniveau.

Hvis du vil give adgang til grupper i stedet for individuelle brugere, skal den indholdsejer eller -administrator, der behandler anmodningen om adgang, fuldføre anmodningen i flere trin:

1. Afvis den ventende anmodning i Power BI (fordi den er knyttet til en enkelt bruger).
2. Føj anmoderen til den korrekte gruppe i henhold til din aktuelle proces.
3. Giv anmoderen besked om, at vedkommende nu har adgang.

Tip

Se Arbejdsproces for anmodning om adgang for oprettere for at få oplysninger om besvarelse af anmodninger om oprettelse af adgang fra indholdsoprettere. Den indeholder også anbefalinger om brug af en formular til adgangsanmodninger.

Tjekliste – Når du planlægger arbejdsprocessen for anmodning om adgang , omfatter vigtige beslutninger og handlinger:

• Bestem, hvem der skal håndtere anmodninger om appadgang: Sørg for, at der er en proces på plads til at håndtere anmodninger om appadgang rettidigt. Sørg for, at appkontakter er tildelt til at understøtte processen.
• Bestem, hvem der skal håndtere anmodninger pr. element: Sørg for, at en proces er på plads til at håndtere adgangsanmodninger rettidigt. Sørg for, at kontakterne er tildelt til hvert element for at understøtte processen.
• Medtag i dokumentation og oplæring af indholdsforfattere: Sørg for, at indholdsforfattere forstår, hvordan de kan håndtere adgangsanmodninger rettidigt. Gør dem opmærksomme på, hvordan de håndterer anmodninger, når en gruppe skal bruges i stedet for en enkelt bruger.
• Medtag i dokumentation og oplæring: Medtag vejledning til dine indholdsoprettere om, hvordan du administrerer adgangsanmodninger effektivt. Omfatter også vejledning til forbrugere om, hvilke oplysninger der skal medtages i deres meddelelse om adgangsanmodning.

Gennemtving datasikkerhed baseret på forbrugeridentitet

Du kan planlægge at oprette færre semantiske modeller og rapporter ved at gennemtvinge datasikkerhed. Formålet er at gennemtvinge datasikkerhed baseret på identiteten af den bruger, der får vist indholdet.

Du kan f.eks. overveje, at du kan dele en enkelt salgsrapport med alle sælgere (forbrugere), vel vidende at hver sælger kun får vist salgsresultater for deres område. Med denne fremgangsmåde kan du undgå kompleksiteten ved at oprette separate rapporter pr. område , der skal deles med sælgere fra det pågældende salgsområde.

Nogle organisationer har specifikke krav til godkendte (certificerede eller fremhævede) semantiske modeller eller datamarts. Der kan være et krav om at bruge datasikkerhed i forbindelse med data, der vil blive brugt i vid udstrækning.

Du kan opnå datasikkerhed på flere måder.

• Semantisk Power BI-model: Som Power BI-dataopretter kan du gennemtvinge sikkerhed på rækkeniveau (RLS) og sikkerhed på objektniveau (OLS). Sikkerhed på rækkeniveau omfatter definition af roller og regler, der filtrerer datamodelrækker, mens OLS begrænser adgangen til bestemte tabeller eller kolonner. Disse definerede RLS- og OLS-regler gælder ikke for referencer, der er gemt uden for den semantiske model, f.eks. udsnit og filtervalg. Både RLS- og OLS-teknikker beskrives yderligere senere i dette afsnit.
• Analysis Services: En semantisk model med direkte forbindelse kan oprette forbindelse til en ekstern datamodel, som hostes af enten Azure Analysis Services (AAS) eller SQL Server Analysis Services (SSAS). Fjernmodellen kan gennemtvinge sikkerhed på rækkeniveau eller OLS baseret på forbrugeridentiteten.
• Datakilde: Nogle datakilder, f.eks. Azure SQL Database, kan gennemtvinge sikkerhed på rækkeniveau. I dette tilfælde kan Power BI-modellen drage fordel af den eksisterende sikkerhed i stedet for at omdefinere den. Denne fremgangsmåde kan være en betydelig fordel, når sikkerhed på rækkeniveau, der er defineret i kilden, er kompleks. Du kan udvikle og publicere en DirectQuery-model og angive legitimationsoplysningerne for datakilden for den semantiske model i Power BI-tjeneste for at aktivere enkeltlogon (SSO). Når en forbruger af en rapport åbner en rapport, overfører Power BI sin identitet til datakilden. Datakilden gennemtvinger derefter sikkerhed på rækkeniveau baseret på rapportens forbrugers identitet. Du kan få flere oplysninger om Azure SQL Database RLS i denne artikel.

Bemærk

Kildesystemer, f.eks. Azure SQL Database, kan også bruge teknikker som visninger til at indsnævre, hvad brugeren kan se. Selvom det er en gyldig teknik, er det ikke relevant for fokus i dette afsnit.

Sikkerhed på rækkeniveau

Sikkerhed på rækkeniveau (RLS) gør det muligt for en dataudformer at begrænse adgangen til et undersæt af data. Den bruges typisk til at sikre, at nogle rapportforbrugere ikke kan se bestemte data, f.eks. salgsresultater for andre salgsområder.

Tip

Hvis du har bemærket, at en person opretter flere datamodeller for at understøtte forskellige forbrugergrupper, skal du kontrollere, om sikkerhed på rækkeniveau opfylder deres krav. Det er typisk bedre at oprette, teste og vedligeholde én datamodel i stedet for flere datamodeller.

Vær forsigtig, for hvis en Power BI-rapport refererer til en række med RLS konfigureret, vises den samme meddelelse som for et slettet eller ikke-eksisterende felt. For disse brugere ser det ud til, at rapporten er brudt.

Der er to trin til konfiguration af sikkerhed på rækkeniveau: regler og rolletilknytninger.

RLS-regler

For semantiske modeller kan en dataudformer konfigurere sikkerhed på rækkeniveau i Power BI Desktop ved at oprette en eller flere roller. En rolle har et entydigt navn i modellen, og den indeholder normalt en eller flere regler. Regler gennemtvinger filtre på modeltabeller ved hjælp af DAX-filterudtryk (Data Analysis Expressions). En model har som standard ingen roller.

Vigtigt

En model uden roller betyder, at brugere (der har tilladelse til at forespørge datamodellen) har adgang til alle modeldata.

Regeludtryk evalueres i rækkekontekst. Rækkekontekst betyder, at udtrykket evalueres for hver række ved hjælp af kolonneværdierne for den pågældende række. Når udtrykket returnerer TRUE, kan brugeren se rækken. Du kan definere regler, der enten er statiske eller dynamiske.

• Statiske regler: Brug DAX-udtryk, der refererer til konstanter, f.eks [Region] = "Midwest". .
• Dynamiske regler: Brug bestemte DAX-funktioner, der returnerer miljøværdier (i modsætning til konstanter). Miljøværdier returneres fra tre specifikke DAX-funktioner: USERNAME, USERPRINCIPALNAME og CUSTOMDATA. Det er nemt og effektivt at definere dynamiske regler, når en modeltabel gemmer brugernavnsværdier. De giver dig mulighed for at gennemtvinge et datadrevet RLS-design.

RLS-rolletilknytninger

Når du har publiceret modellen på Power BI-tjeneste, skal du konfigurere rolletilknytninger, før brugerne får adgang til relaterede rapporter. Rolletilknytning omfatter tildeling af Microsoft Entra-sikkerhedsobjekter til roller. Sikkerhedsobjekter kan være brugerkonti eller sikkerhedsgrupper.

Når det er muligt, er det bedste praksis at knytte roller til sikkerhedsgrupper. På den måde vil der være færre tilknytninger, og administration af gruppemedlemskab kan håndteres af ejeren af gruppen.

Vi anbefaler, at du gør sikkerhedskontooplysninger fra Microsoft Entra tilgængelige for dine indholdsforfattere. En mulighed er at oprette et dataflow med data, der holdes synkroniseret med Microsoft Entra ID. På den måde kan indholdsoprettere integrere dataflowdataene for at oprette en datadrevet semantisk model.

Tip

Det er muligt at definere en rolle, der ikke har nogen regler. I dette tilfælde giver rollen adgang til alle rækker i alle modeltabeller. Konfiguration af denne type rolle er velegnet, når en administrator eller bruger har tilladelse til at få vist alle data i modellen.

RLS-brugeroplevelse

Nogle organisationer vælger bevidst at bruge sikkerhed på rækkeniveau som et sekundært sikkerhedslag ud over standardtilladelser til Power BI. Overvej følgende scenarie: Du deler et link til en rapport med hele organisationen. Alle brugere, der får vist rapporten, skal knyttes til en rolle for sikkerhed på rækkeniveau for at kunne se data i rapporten. Hvis de ikke er knyttet til en rolle for sikkerhed på rækkeniveau, kan de ikke se nogen data.

Tilstedeværelsen af sikkerhed på rækkeniveau ændrer standardoplevelsen for forbrugere.

• Når sikkerhed på rækkeniveau ikke er defineret for den semantiske model: Oprettere og forbrugere med mindst læsetilladelse til den semantiske model kan få vist alle data i den semantiske model.
• Når sikkerhed på rækkeniveau er defineret i den semantiske model: Oprettere og forbrugere, der kun har læsetilladelse til den semantiske model, kan kun få vist de data, de har tilladelse til at se (baseret på deres rolletilknytning for sikkerhed på rækkeniveau).

Bemærk

Nogle organisationer gennemtvinger sikkerhed på rækkeniveau som et ekstra lag af sikkerhed, især når der er tale om følsomme data. Derfor kan du vælge at kræve sikkerhed på rækkeniveau for semantiske modeller, der er certificeret. Dette krav kan opfyldes med en intern gennemgangs- og godkendelsesproces, før den semantiske model certificeres.

Når en bruger får vist en rapport i enten et arbejdsområde eller en app, gennemtvinges sikkerhed på rækkeniveau muligvis eller måske ikke, afhængigt af deres semantiske modeltilladelser. Det er derfor vigtigt, at indholdsforbrugere og -oprettere kun har læsetilladelse til den underliggende semantiske model, når sikkerhed på rækkeniveau skal gennemtvinges.

Her er de tilladelsesregler, der bestemmer, om sikkerhed på rækkeniveau gennemtvinges.

• Brugeren har læsetilladelse til den semantiske model: Sikkerhed på rækkeniveau gennemtvinges for brugeren.
• Brugeren har læse- og buildtilladelser til den semantiske model: Sikkerhed på rækkeniveau gennemtvinges for brugeren.
• Brugeren har skrivetilladelse til den semantiske model: Sikkerhed på rækkeniveau gennemtvinges ikke for brugeren, hvilket betyder, at brugeren kan se alle data i den semantiske model. Tilladelsen Skriv giver mulighed for at redigere en semantisk model. Den kan tildeles på to måder:
  • Med rollerne Bidragyder, Medlem eller Administration arbejdsområde (for det arbejdsområde, hvor den semantiske model er gemt).
  • Med tilladelsen Skriv semantisk model pr. element.

Tip

Du kan finde flere oplysninger om, hvordan du bruger separate arbejdsområder, så sikkerhed på rækkeniveau fungerer for oprettere af indhold, i det administrerede selvbetjente BI-forbrugsscenarie .

Du kan få flere oplysninger om sikkerhed på rækkeniveau under Begræns adgang til Power BI-modeldata.

Sikkerhed på rækkeniveau for datamarts

Power BI-datamarts kan også gennemtvinge sikkerhed på rækkeniveau. Men implementeringen er anderledes.

Den største forskel er, at sikkerhed på rækkeniveau for datamarts er konfigureret i Power BI-tjeneste i stedet for i Power BI Desktop.

En anden forskel er, at datamarts gennemtvinger sikkerhed på rækkeniveau for både den semantiske model og den administrerede Azure SQL Database, der er knyttet til datamarten. Gennemtvingelse af sikkerhed på rækkeniveau i begge lag giver ensartethed og fleksibilitet. De samme RLS-filtre anvendes, uanset hvordan brugeren forespørger dataene, uanset om det er ved at oprette forbindelse til den semantiske model eller til den administrerede Azure SQL Database.

Du kan få flere oplysninger under Sikkerhed på rækkeniveau for datamarts.

Sikkerhed på objektniveau

Sikkerhed på objektniveau (OLS) gør det muligt for en dataudformer at begrænse adgangen til bestemte tabeller og kolonner og deres metadata. Du bruger typisk OLS til at sikre, at følsomme kolonner, f.eks. medarbejderløn, ikke er synlige for visse brugere. Selvom det ikke er muligt at begrænse adgangen til målinger, begrænses alle målinger, der refererer til en begrænset kolonne.

Overvej et eksempel på en medarbejdertabel. Den indeholder kolonner, der gemmer medarbejdernavnet og telefonnummeret samt løn. Du kan bruge OLS til at sikre, at det kun er bestemte brugere, f.eks. ledende personalemedarbejdere, der kan se lønværdier. For de brugere, der ikke kan se lønværdier, er det som om, at kolonnen ikke findes.

Vær forsigtig, for hvis en Power BI-rapportvisualisering indeholder løn, modtager brugere, der ikke har adgang til dette felt, en fejlmeddelelse. Meddelelsen informerer dem om, at objektet ikke findes. For disse brugere ser det ud til, at rapporten er brudt.

Bemærk

Du kan også definere perspektiver i en datamodel. Et perspektiv definerer undersæt af modelobjekter, der kan ses, for at hjælpe med at give rapportoprettere et bestemt fokus. Perspektiver er ikke beregnet til at begrænse adgangen til modelobjekter. En bruger kan stadig forespørge en tabel eller kolonne, selvom den ikke er synlig for vedkommende. Overvej derfor perspektiver som en praktisk bruger i stedet for en sikkerhedsfunktion.

Der er i øjeblikket ikke en grænseflade i Power BI Desktop til konfiguration af OLS. Du kan bruge Tabular Editor, som er et tredjepartsværktøj til oprettelse, vedligeholdelse og administration af modeller. Du kan få flere oplysninger i brugsscenariet for administration af avancerede datamodeller.

Du kan få flere oplysninger om OLS under Begræns adgang til Power BI-modelobjekter.

Tjekliste – Når du planlægger sikkerhed på rækkeniveau og OLS, omfatter vigtige beslutninger og handlinger:

• Beslut, hvilken strategi der skal bruges til sikkerhed på rækkeniveau: Overvej, hvilke use cases og formål du vil bruge sikkerhed på rækkeniveau til.
• Beslut, hvilken strategi der skal bruges af OLS: Overvej, hvilke use cases og formål du vil bruge sikkerhed på objektniveau til.
• Overvej krav til certificeret indhold: Hvis du har en proces for, hvad der kræves for at certificere en semantisk model, skal du beslutte, om du vil inkludere specifikke krav til brug af sikkerhed på rækkeniveau eller OLS.
• Opret og udgiv brugervejledning: Opret dokumentation til brugere, der indeholder krav og indstillinger til brug af sikkerhed på rækkeniveau og OLS. Beskriv, hvordan du henter oplysninger om brugertilknytning, hvis de findes på en central placering.
• Opdater undervisningsmateriale: Medtag vigtige oplysninger om krav og præferencer for sikkerhed på rækkeniveau og OLS i brugertræningsmaterialet. Angiv eksempler, så brugerne kan forstå, hvornår det er hensigtsmæssigt at bruge en af datasikkerhedsteknikken.

Relateret indhold

I den næste artikel i denne serie kan du få mere at vide om sikkerhedsplanlægning for indholdsforfattere, der er ansvarlige for at oprette semantiske modeller, dataflow, datamarts, rapporter eller dashboards.