Vejledning til sikkerhed på rækkeniveau i Power BI Desktop

  • Artikel

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).

Opret roller

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 .

Optimer sikkerhed på rækkeniveau

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.

Måling af RLS-indvirkning

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.

Konfigurer rolletilknytninger

Når du har publiceret til Power BI, skal du knytte medlemmer til semantiske modelroller (tidligere kaldet et datasæt). 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 (tidligere kendt som Azure Active Directory). Den uddelegerer muligvis opgaven til netværksadministratorerne.

Valider roller

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()
    )
)

Design delvis sikkerhed på rækkeniveau

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:

Der vises et billede af et modeldiagram. Det er beskrevet i følgende afsnit.

Modellen består af fire tabeller:

  • Tabellen Salesperson gemmer én række pr. sælger. Den indeholder kolonnen EmailAddress , som gemmer mailadressen for hver sælger. Denne tabel er skjult.
  • Tabellen Sales gemmer én række pr. ordre. Den indeholder målingen Revenue % All Region , som er designet til at returnere et forhold mellem den indtægt, som rapportbrugerens område har tjent, og indtægten for alle områder.
  • Tabellen Date gemmer én række pr. dato og gør det muligt at filtrere og gruppere år og måned.
  • SalesRevenueSummary er en beregnet tabel. Den gemmer den samlede omsætning for hver ordredato. Denne tabel er skjult.

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
Afslutning af rutediagram 1. 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 .
Afslutning 2 i rutediagrammet. Der er en en til mange-relation mellem tabellerne Dato og Salg .
Afslutning af rutediagram 3. 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.

Hvornår skal du undgå at bruge sikkerhed på rækkeniveau?

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:

  • Forbedret forespørgselsydeevne: Det kan resultere i forbedret ydeevne på grund af færre filtre.
  • Mindre modeller: Selvom det resulterer i flere modeller, er de mindre. Mindre modeller kan forbedre svartid for forespørgsels- og dataopdateringer, især hvis hostingkapaciteten oplever pres på ressourcer. Det er også nemmere at holde modelstørrelser under størrelsesgrænser, der pålægges af din kapacitet. Endelig er det nemmere at balancere arbejdsbelastninger på tværs af forskellige kapaciteter, fordi du kan oprette arbejdsområder på – eller flytte arbejdsområder til – forskellige kapaciteter.
  • Yderligere funktioner: Power BI-funktioner, der ikke fungerer sammen med sikkerhed på rækkeniveau, f.eks . Publicer på internettet, kan bruges.

Der er dog ulemper forbundet med at undgå sikkerhed på rækkeniveau:

  • Flere arbejdsområder: Der kræves ét arbejdsområde for hver rapportbrugermålgruppe. Hvis apps publiceres, betyder det også, at der er én app pr. rapportbrugermålgruppe.
  • Duplikering af indhold: Rapporter og dashboards skal oprettes i hvert arbejdsområde. Det kræver en større indsats og tid at konfigurere og vedligeholde.
  • Brugere med høj rettighed: Brugere med høj rettighed, der tilhører flere rapportbrugermålgrupper, kan ikke se en samlet visning af dataene. De skal åbne flere rapporter (fra forskellige arbejdsområder eller apps).

Foretag fejlfinding af sikkerhed på rækkeniveau

Hvis sikkerhed på rækkeniveau giver uventede resultater, skal du kontrollere, om der er følgende problemer:

  • Der findes forkerte relationer mellem modeltabeller, hvad angår kolonnetilknytninger og filterretninger. Vær opmærksom på, at RLS-filtre kun overføres via aktive relationer.
  • Egenskaben Anvend sikkerhedsfilter i begge retninger er ikke angivet korrekt. Du kan finde flere oplysninger i Vejledning til tovejsrelationer.
  • Tabeller indeholder ingen data.
  • Forkerte værdier indlæses i tabeller.
  • Brugeren er knyttet til flere roller.
  • Modellen indeholder sammenlægningstabeller, og regler for sikkerhed på rækkeniveau filtrerer ikke sammenlægninger og detaljer på en ensartet måde. Du kan få flere oplysninger under Brug sammenlægninger i Power BI Desktop (RLS til sammenlægninger).

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.

Relateret indhold

Du kan få flere oplysninger, der er relateret til denne artikel, i følgende ressourcer: