Begivenhed
31. mar., 23 - 2. apr., 23
Den ultimative Microsoft Fabric-, Power BI-, SQL- og AI-communityledede begivenhed. 31. marts til 2. april 2025.
Tilmeld dig i dagDenne browser understøttes ikke længere.
Opgrader til Microsoft Edge for at drage fordel af de nyeste funktioner, sikkerhedsopdateringer og teknisk support.
Denne artikel henvender sig til dig som datamodel, der arbejder med Power BI Desktop. Den beskriver gode designpraksisser til gennemtvingelse af sikkerhed på rækkeniveau (RLS) i dine datamodeller.
Det er vigtigt at forstå tabelrækker i RLS-filtre. De kan ikke konfigureres til at begrænse adgangen til modelobjekter, herunder tabeller, kolonner eller målinger.
Bemærk
I denne artikel beskrives sikkerhed på rækkeniveau ikke, eller hvordan du konfigurerer den. Du kan få flere oplysninger under Begræns dataadgang med sikkerhed på rækkeniveau for Power BI Desktop.
Det dækker heller ikke gennemtvingelse af sikkerhed på rækkeniveau i direkte forbindelser til eksternt hostede modeller med Azure Analysis Services eller SQL Server Analysis Services. I disse tilfælde gennemtvinges sikkerhed på rækkeniveau af Analysis Services. Når Power BI opretter forbindelse ved hjælp af enkeltlogon (SSO), gennemtvinger Analysis Services sikkerhed på rækkeniveau (medmindre kontoen har administratorrettigheder).
Det er muligt at oprette flere roller. Når du overvejer tilladelsesbehovet for en enkelt rapportbruger, skal du bestræbe dig på at oprette en enkelt rolle, der giver alle disse tilladelser, i stedet for et design, hvor en rapportbruger vil være medlem af flere roller. Det skyldes, at en rapportbruger kan knytte til flere roller enten direkte ved hjælp af sin brugerkonto eller indirekte ved hjælp af medlemskab af sikkerhedsgrupper. Flere rolletilknytninger kan resultere i uventede resultater.
Når en rapportbruger tildeles til flere roller, bliver RLS-filtre additive. Det betyder, at rapportbrugere kan se tabelrækker, der repræsenterer foreningen af disse filtre. I nogle scenarier er det desuden ikke muligt at garantere, at en rapportbruger ikke kan se rækker i en tabel. Så i modsætning til tilladelser, der anvendes på SQL Server-databaseobjekter (og andre tilladelsesmodeller), gælder princippet "når nægtet altid nægtet" ikke.
Overvej en model med to roller: Den første rolle med navnet Arbejdere begrænser adgangen til alle rækker i tabellen Løn ved hjælp af følgende regeludtryk:
FALSE()
Bemærk
En regel returnerer ingen tabelrækker, når udtrykket evalueres til FALSE
.
En anden rolle med navnet Ledere giver dog adgang til alle rækker i tabellen Løn ved hjælp af følgende regeludtryk:
TRUE()
Vær forsigtig: Hvis en rapportbruger knyttes til begge roller, får vedkommende vist alle rækker i tabellen Løn .
Sikkerhed på rækkeniveau fungerer ved automatisk at anvende filtre på hver DAX-forespørgsel, og disse filtre kan have en negativ indvirkning på forespørgslens ydeevne. Så effektiv sikkerhed på rækkeniveau kommer ned til et godt modeldesign. Det er vigtigt at følge vejledningen til modeldesign, som beskrevet i følgende artikler:
Generelt er det ofte mere effektivt at gennemtvinge RLS-filtre på tabeller af dimensionstypen og ikke tabeller af faktatypen. Og brug veldesignede relationer for at sikre, at RLS-filtre overføres til andre modeltabeller. RLS-filtre overføres kun via aktive relationer. Undgå derfor at bruge DAX-funktionen LOOKUPVALUE , når modelrelationer kan opnå det samme resultat.
Når RLS-filtre gennemtvinges i DirectQuery-tabeller, og der er relationer til andre DirectQuery-tabeller, skal du sørge for at optimere kildedatabasen. Det kan omfatte design af relevante indekser eller brug af permanente beregnede kolonner. Du kan finde flere oplysninger i Vejledning til DirectQuery-model i Power BI Desktop.
Det er muligt at måle ydeevnen for RLS-filtre i Power BI Desktop ved hjælp af Effektivitetsanalyse. Først skal du bestemme forespørgselsvarighederne for rapportvisualiseringer, når sikkerhed på rækkeniveau ikke gennemtvinges. Brug derefter kommandoen Vis som på båndfanen Udformning til at gennemtvinge sikkerhed på rækkeniveau og bestemme og sammenligne forespørgselsvarighed.
Når du har publiceret til Power BI, skal du knytte medlemmer til semantiske modelroller. Det er kun semantiske modelejere eller administratorer af arbejdsområder, der kan føje medlemmer til roller. Du kan få flere oplysninger under Sikkerhed på rækkeniveau med Power BI (Administrer sikkerhed på din model).
Medlemmer kan være brugerkonti, sikkerhedsgrupper, distributionsgrupper eller mailaktiveret grupper. Når det er muligt, anbefaler vi, at du knytter sikkerhedsgrupper til semantiske modelroller. Det omfatter administration af medlemskaber af sikkerhedsgrupper i Microsoft Entra ID. Den uddelegerer muligvis opgaven til netværksadministratorerne.
Test hver rolle for at sikre, at den filtrerer modellen korrekt. Det gøres nemt ved hjælp af kommandoen Vis som på båndfanen Udformning .
Når modellen har dynamiske regler ved hjælp af DAX-funktionen USERNAME , skal du sørge for at teste for forventede og uventede værdier. Når du integrerer Power BI-indhold – specifikt ved hjælp af scenariet Integrer for dine kunder – kan applogik overføre enhver værdi som et effektivt identitetsbrugernavn. Når det er muligt, skal du sikre, at utilsigtede eller skadelige værdier resulterer i filtre, der ikke returnerer nogen rækker.
Overvej et eksempel på brug af Power BI Embedded, hvor appen overfører brugerens jobrolle som det effektive brugernavn: Det er enten "Leder" eller "Arbejder". Ledere kan se alle rækker, men arbejdere kan kun se rækker, hvor kolonneværdien Type er "Intern".
Følgende regeludtryk er defineret:
IF(
USERNAME() = "Worker",
[Type] = "Internal",
TRUE()
)
Problemet med dette regeludtryk er, at alle værdier undtagen "Worker" returnerer alle tabelrækker. En utilsigtet værdi, f.eks. "Wrker", returnerer derfor utilsigtet alle tabelrækker. Det er derfor sikrere at skrive et udtryk, der tester for hver forventet værdi. I følgende forbedrede regeludtryk medfører en uventet værdi, at tabellen ikke returnerer nogen rækker.
IF(
USERNAME() = "Worker",
[Type] = "Internal",
IF(
USERNAME() = "Manager",
TRUE(),
FALSE()
)
)
Nogle gange har beregninger brug for værdier, der ikke er begrænset af RLS-filtre. En rapport kan f.eks. have brug for at vise et forhold mellem den indtægt, der er optjent for rapportbrugerens salgsområde, i forhold til alle indtægter, der er optjent.
Selvom det ikke er muligt for et DAX-udtryk at tilsidesætte sikkerhed på rækkeniveau – faktisk kan det ikke engang afgøres, om sikkerhed på rækkeniveau gennemtvinges – du kan bruge en oversigtsmodeltabel. Oversigtsmodeltabellen forespørges for at hente indtægten for "alle områder", og den er ikke begrænset af nogen RLS-filtre.
Lad os se, hvordan du kan implementere dette designkrav. Først skal du overveje følgende modeldesign:
Modellen består af fire tabeller:
Følgende udtryk definerer den beregnede tabel SalesRevenueSummary :
SalesRevenueSummary =
SUMMARIZECOLUMNS(
Sales[OrderDate],
"RevenueAllRegion", SUM(Sales[Revenue])
)
Bemærk
En sammenlægningstabel kan opfylde det samme designkrav.
Følgende RLS-regel anvendes på tabellen Salesperson :
[EmailAddress] = USERNAME()
Hver af de tre modelrelationer er beskrevet i følgende tabel:
Relation | Beskrivelse |
---|---|
Der er en mange til mange-relation mellem tabellerne Salesperson og Sales . Reglen for sikkerhed på rækkeniveau filtrerer kolonnen EmailAddress i den skjulte tabel Salesperson ved hjælp af DAX-funktionen USERNAME . Kolonneværdien Region (for rapportbrugeren) overføres til tabellen Sales . | |
Der er en en til mange-relation mellem tabellerne Dato og Salg . | |
Der er en en til mange-relation mellem tabellerne Date og SalesRevenueSummary . |
Følgende udtryk definerer målingen Revenue % All Region :
Revenue % All Region =
DIVIDE(
SUM(Sales[Revenue]),
SUM(SalesRevenueSummary[RevenueAllRegion])
)
Bemærk
Vær forsigtig med at undgå at afsløre følsomme fakta. Hvis der kun er to områder i dette eksempel, er det muligt for en rapportbruger at beregne indtægten for det andet område.
Nogle gange giver det mening at undgå at bruge sikkerhed på rækkeniveau. Hvis du kun har nogle få forenklede RLS-regler, der anvender statiske filtre, kan du overveje at publicere flere semantiske modeller i stedet. Ingen af de semantiske modeller definerer roller, fordi hver semantiske model indeholder data for en bestemt rapportbrugermålgruppe, som har de samme datatilladelser. Opret derefter ét arbejdsområde pr. målgruppe, og tildel adgangstilladelser til arbejdsområdet eller appen.
Et firma, der kun har to salgsområder, beslutter f.eks. at publicere en semantisk model for hvert salgsområde til forskellige arbejdsområder. De semantiske modeller gennemtvinger ikke sikkerhed på rækkeniveau. De bruger dog forespørgselsparametre til at filtrere kildedata. På denne måde publiceres den samme model til hvert arbejdsområde – de har kun forskellige semantiske modelparameterværdier. Sælgere tildeles kun adgang til et af arbejdsområderne (eller publicerede apps).
Der er flere fordele ved at undgå sikkerhed på rækkeniveau:
Der er dog ulemper forbundet med at undgå sikkerhed på rækkeniveau:
Hvis sikkerhed på rækkeniveau giver uventede resultater, skal du kontrollere, om der er følgende problemer:
Når en bestemt bruger ikke kan se nogen data, kan det skyldes, at vedkommendes UPN ikke er gemt, eller at den er angivet forkert. Det kan ske pludseligt, fordi deres brugerkonto er ændret som følge af en navneændring.
Tip
Til testformål skal du tilføje en måling, der returnerer DAX-funktionen USERNAME . Du kan kalde det noget i stil med "Hvem er jeg". Føj derefter målingen til en kortvisualisering i en rapport, og publicer den i Power BI.
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).
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. Du kan finde oplysninger om de tilladelsesregler, der bestemmer, om sikkerhed på rækkeniveau gennemtvinges, i artiklen Rapportér planlægning af forbrugersikkerhed.
Du kan få flere oplysninger, der er relateret til denne artikel, i følgende ressourcer:
Begivenhed
31. mar., 23 - 2. apr., 23
Den ultimative Microsoft Fabric-, Power BI-, SQL- og AI-communityledede begivenhed. 31. marts til 2. april 2025.
Tilmeld dig i dagTræning
Modul
Implementer sikkerhed på rækkeniveau - Training
Sikkerhed på rækkeniveau giver dig mulighed for at oprette en enkelt eller en gruppe af rapporter, der er rettet mod data for en bestemt bruger. I dette modul lærer du, hvordan du implementerer sikkerhed på rækkeniveau ved hjælp af enten en statisk eller dynamisk metode, og hvordan Microsoft Power BI forenkler test af sikkerhed på rækkeniveau i Power BI Desktop og Power BI-tjeneste.
Certificering
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Demonstrate methods and best practices that align with business and technical requirements for modeling, visualizing, and analyzing data with Microsoft Power BI.
Dokumentation
Sikkerhed på rækkeniveau med Power BI - Microsoft Fabric
Sådan konfigurerer du sikkerhed på rækkeniveau for importerede semantiske modeller og DirectQuery i Power BI-tjeneste.
Sikkerhed på rækkeniveau i Power BI-rapportserver - Power BI
Få mere at vide om brug af sikkerhed på rækkeniveau i Power BI-rapportserver.
Sikkerhed på objektniveau med Power BI - Microsoft Fabric
Sådan konfigurerer du sikkerhed på objektniveau for importerede semantiske modeller i Power BI-tjeneste.