Sikkerhet på radnivå med Power BI Embedded

Du kan bruke sikkerhet på radnivå (RLS) til å begrense brukertilgang til data i instrumentbord, fliser, rapporter og datasett. Forskjellige brukere kan arbeide med de samme artefaktene samtidig og se ulike data. Innebygging støtter RLS.

Hvis du bygger inn innhold for brukere som ikke har Power BI (appen eier dataene), som vanligvis er et ISV-scenario, er denne artikkelen for deg! Konfigurer innebyggingstokenet slik at det tar høyde for brukeren og rollen.

Hvis du bygger inn innhold for Power BI-brukere (brukerne eier dataene), fungerer RLS i organisasjonen på samme måte som det gjør direkte i Power BI-tjenesten. Du trenger ikke gjøre noe mer i programmet. Hvis du vil ha mer informasjon, kan du se Sikkerhet på radnivå (RLS) med Power BI.

Items involved with Row-Level Security.

Hvis du vil dra nytte av RLS, er det viktig at du forstår de tre viktigste begrepene: Brukere, Roller og Regler. La oss ta en nærmere titt på disse begrepene:

Brukere – sluttbrukere som viser artefakten (instrumentbord, flis, rapport eller datasett). Brukere identifiseres av egenskapen brukernavn i et innebyggingstoken i Power BI Embedded.

Roller – brukere tilhører roller. En rolle er en beholder for regler og kan for eksempel kalles Salgssjef eller Salgsrepresentant. Du oppretter roller i Power BI Desktop. Hvis du vil ha mer informasjon, kan du se Sikkerhet på radnivå (RLS) med Power BI Desktop.

Regler – roller har regler, og disse reglene er de faktisk filtrene som skal brukes på dataene. Reglen kan være enkel, som for eksempel at «Land = USA», men den kan også være mye mer dynamisk. Resten av denne artikkelen inneholder et eksempel på å skrive RLS og deretter bruke det i et innebygd program. Eksemplet bruker PBIX-filen Eksempel på detaljhandelanalyse.

Report example

Legge til roller med Power BI Desktop

Eksemplet på detaljhandelanalyse viser salg for alle butikkene i en butikkjede. Uten RLS vil de se de samme dataene uansett hvilken distriktssjef som logger seg på og viser rapporten. Toppledelsen har fastslått at distriktssjefene bare skal se salget for sine egne butikker. Hvis du bruker RLS, kan toppledelsen begrense dataene basert på en distriktssjef.

RLS skrives i Power BI Desktop. Når datasettet og rapporten åpnes, kan vi bytte til diagramvisning for å vise skjemaet:

Diagram view within Power BI Desktop

Her er noen ting du bør merke deg med dette skjemaet:

  • Alle mål, for eksempel Totalt salg, lagres i faktatabellen Salg.

  • Det finnes fire relaterte dimensjonstabeller til: Vare, Tid, Butikk og Distrikt.

  • Pilene på relasjonslinjene angir hvilken vei filtre kan flyte fra én tabell til en annen. Hvis et filter for eksempel er plassert på Tid [dato] i gjeldende skjema, filtreres bare verdiene i Salg-tabellen. Ingen andre tabeller blir påvirket av dette filteret, fordi alle pilene på relasjonslinjene peker mot salgstabellen og ikke bort fra den.

  • Distrikt-tabellen angir hvem lederen er for hvert distrikt:

    Rows within District table

Hvis vi basert på dette skjemaet bruker et filter på Distriktssjef-kolonnen i Distrikt-tabellen, og hvis dette filteret samsvarer med brukeren som viser rapporten, blir dette filtrert ned til Butikk- og Salg-tabellene, slik at de viser data for denne distriktssjefen.

Slik gjør du det:

  1. Velg Behandle rollerModellering-fanen.

    Modeling tab within Power BI Desktop

  2. Opprett en ny rolle kalt Leder.

    Create new role

  3. Skriv inn dette DAX-uttrykket i Distrikt-tabellen: [Distriktssjef] = BRUKERNAVN() .

    DAX statement for RLS rule

  4. Kontroller at disse reglene fungerer, ved å gå til Modellering-fanen og velge Vis som roller. Velg deretter både Leder-rollen du nettopp opprettet, og Andre brukere. Angi Andrew Ma for brukeren.

    View as role dialog

    Rapportene viser data som om du var logget på som Andrew Ma.

Når du bruker filteret, slik vi gjorde her, filtreres alle poster i Distrikt-, Butikk- og Salg-tabellene ned. Men på grunn av filterretningen på relasjonene mellom Salg og Tid, filtreres ikke tabellene Salg, Element, Element og Tid ned. Hvis du vil lære mer om toveis kryssfiltrering, kan du laste ned hvitboken Bidirectional cross-filtering in SQL Server Analysis Services 2016 and Power BI Desktop.

Bruke bruker og rolle på et innebyggingstoken

Nå som du har konfigurert rollene i Power BI Desktop er det et par ting til som må ordnes i programmet, før du kan dra nytte av rollene.

Brukere godkjennes og autoriseres av programmet, og innebyggingstokener brukes til å gi disse brukerne tilgang til en bestemt Power BI Embedded-rapport. Power BI Embedded har ikke noen bestemt informasjon om hvem disse brukerne er. For at RLS skal fungere, må du sende litt ekstra kontekst som en del av innebyggingstokenet i form av identiteter. Du kan sende identiteter ved hjelp av innebyggingstokenet for programmeringsgrensesnitt (API).

API-et godtar en liste over identiteter med indikasjon på de relevante datasettene. Du må sende dette som en del av identiteten for at RLS skal fungere.

  • brukernavn (obligatorisk) – En streng som kan brukes til å identifisere brukeren når du bruker RLS-regler. Bare én enkelt bruker kan være oppført. Brukernavnet kan opprettes med ASCII-tegn.
  • roller (obligatorisk) – en streng som inneholder rollene som skal velges når du bruker regler for sikkerhet på radnivå. Hvis du sender mer enn én rolle, skal de sendes som en strengmatrise.
  • datasett (obligatorisk) – Datasettet som gjelder for artefakten du bygger inn.

Du kan opprette innebyggingstokenet ved hjelp av metoden GenerateTokenInGroupPowerBIClient.Reports.

du kan For eksempel endre PowerBI-Developer-samples .NET Framework bygge inn for kundene >> eksempel.

public EmbedToken GetEmbedToken(Guid reportId, IList<Guid> datasetIds, [Optional] Guid targetWorkspaceId)
    {
        PowerBIClient pbiClient = this.GetPowerBIClient();

        // Create a request for getting an embed token
        // This method works only with new Power BI V2 workspace experience
        var tokenRequest = new GenerateTokenRequestV2(
            reports: new List<GenerateTokenRequestV2Report>() { new GenerateTokenRequestV2Report(reportId) },
            datasets: datasetIds.Select(datasetId => new GenerateTokenRequestV2Dataset(datasetId.ToString())).ToList(),
            targetWorkspaces: targetWorkspaceId != Guid.Empty ? new List<GenerateTokenRequestV2TargetWorkspace>() { new GenerateTokenRequestV2TargetWorkspace(targetWorkspaceId) } : null,
            identities: new List<EffectiveIdentity> { rls }
        );

        // Generate an embed token
        var embedToken = pbiClient.EmbedToken.GenerateToken(tokenRequest);

        return embedToken;
    }

Hvis du kaller REST-API-en, godtar den oppdaterte API-en nå en ekstra JSON-matrise kalt identiteter. Den inneholder et brukernavn, en liste over strengroller og en liste over strengdatasett.

Bruk denne koden som et eksempel:

{
    "accessLevel": "View",
    "identities": [
        {
            "username": "EffectiveIdentity",
            "roles": [ "Role1", "Role2" ],
            "datasets": [ "fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc" ]
        }
    ]
}

Nå som alle delene er samlet, ser de som logger seg på programmet ditt for å vise denne artefakten, bare de dataene de har tillatelse til, som definert av sikkerheten på radnivået.

Arbeide med live-tilkoblinger i Analysis Services

Sikkerhet på radnivå kan brukes med live-tilkoblinger i Analysis Services for lokale servere. Det finnes noen spesifikke begreper du bør forstå når du bruker denne typen tilkobling.

Den faktiske identiteten som angis for egenskapen brukernavn, må være en Windows-bruker med tillatelser på Analysis Services-serveren.

Obs!

Når du bruker tjenestekontohaver med en datakilde fra Azure Analysis Services må tjenestekontohaveren selv ha tillatelser til en forekomst av Azure Analysis Services. Å bruke en sikkerhetsgruppe som inneholder tjenestekontohaveren til dette formålet virker ikke.

Konfigurasjon av lokal datagateway

Det brukes en lokal datagateway når du arbeider med live-tilkoblinger i Analysis Services. Når du genererer et innebyggingstoken med en identitet som er oppført, må hovedkontoen være oppført som administrator for gatewayen. Hvis hovedkontoen ikke er oppført, blir ikke sikkerhet på radnivå brukt riktig på dataene. En bruker som ikke er administrator for gatewayen, kan gi roller, men må angi sitt eget brukernavn for den faktiske identiteten.

Bruk av roller

Roller kan gis med identiteten i et innebyggingstoken. Hvis det ikke blir angitt noen rolle, brukes brukernavnet som ble angitt, til å løse de tilknyttede rollene.

Bruk av CustomData-funksjonen

Med CustomData-funksjonen kan du legge til et rad filter ved å sende en fri tekst (streng) ved hjelp av egenskapen CustomData Connection string. I motsetning til brukere og roller kan CustomData ikke angis i en pbix-fil.

CustomData kan brukes i en rolle Dax-spørring og kan brukes uten en rolle i en mål -Dax-spørring.

CustomData-funksjonen er en del av funksjonaliteten for token-generering for instrument bord-, rapport-og flis artefakter. Instrument bord kan ha flere CustomData-identiteter (én per kart del eller et data sett).

Obs!

Når du genererer et token med CustomData-funksjonen, må du angi et bruker navn på maksimalt 256 tegn.

CustomData SDK-tillegg

Egenskapen for CustomData-strengen ble lagt til i den faktiske identiteten i scenariet for tokengenerering.

[JsonProperty(PropertyName = "customData")]
public string CustomData { get; set; }

Identiteten kan opprettes med egendefinerte data ved hjelp av følgende kall:

public EffectiveIdentity(string username, IList<string> datasets, IList<string> roles = null, string customData = null);

CustomData SDK-bruk

Hvis du kaller REST-API-en, kan du legge til egendefinerte data i hver identitet, for eksempel:

{
    "accessLevel": "View",
    "identities": [
        {
            "username": "EffectiveIdentity",
            "roles": [ "Role1", "Role2" ],
            "customData": "MyCustomData",
            "datasets": [ "fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc" ]
        }
    ]
}

Her er fremgangsmåten for å starte konfigurasjonen av CustomData()-funksjonen med Power BI Embedded-programmet.

  1. Opprett Azure Analysis Services-databasen. Deretter logger du deg på Azure Analysis Services-serveren via SQL Server Management Studio.

    Create an Azure Analysis Services database

    Analysis Services database

  2. Opprett en rolle i Analysis Services-serveren.

    Create Role

  3. Angi Generelt-innstillingene. Her angir du rollenavnet og databasetillatelsene til bare Les.

    Create Role - Set General Settings

  4. Angi innstillingene for Medlemskap. Her kan du legge til brukerne som er berørt av denne rollen.

    Create Role - Set Membership Settings

  5. Angi DAX-spørringen for radfiltrene ved hjelp av CUSTOMDATA() -funksjonen.

    Create Role - Set Row Filters

  6. Bygg en rapport i PBI, og publiser den til et arbeidsområde med kapasitet.

    PBI report sample

  7. Bruk Power BI API-ene til å bruke CustomData-funksjonen i programmet. Når du genererer et token med funksjonen for egendefinerte data, må du ha et brukernavn. Brukernavnet må være likt UPN for hovedbrukeren. Hovedbrukeren må være medlem av rollen(e) som du opprettet. Hvis ingen roller er angitt, brukes alle rollene som hovedbrukeren er medlem av, til RLS evaluering.

    Når du arbeider med en tjenestekontohaver, må du også utføre trinnene ovenfor i stedet for å bruke en hovedkonto. Ved generering av innebyggingstoken, kan du bruke objekt-ID-en til tjenestekontohaver som brukernavn.

    Obs!

    Når du er klar til å distribuere programmet til produksjon, vises ikke kontofeltet eller -alternativet for hovedbrukeren for sluttbrukeren.

    Vis koden for å legge til CustomData-funksjonen.

  8. Nå kan du vise rapporten i programmet før du bruker de egendefinerte dataverdiene til å se alle dataene rapporten inneholder.

    Before Custom Data is applied

    Deretter bruker du de egendefinerte dataverdiene til å se hvordan rapporten vises i et annet sett med data. After CustomData is applied

Bruk av RLS vs. JavaScript-filtre

Når du skal bestemme filtrering av data i en rapport, kan du bruke sikkerhet på radnivå (RLS) eller JavaScript-filtre.

Sikkerhet på radnivå er en funksjon som filtrerer data på datamodellnivå. Serverdeldatakilden kontrollerer RLS-innstillingene. Basert på datamodellen angir generering av innebyggingstokenet brukernavnet og rollene for økten. Den kan ikke overstyres, fjernes eller kontrolleres av koden på klientsiden og derfor anses den som sikker. Vi anbefaler at du bruker RLS til å filtrere data på en sikker måte. Du kan filtrere data med RLS ved hjelp av ett av alternativene nedenfor.

  • Konfigurering av roller i en Power BI-rapport.
  • Konfigurering av roller på datakildenivået (bare Analysis Services live-tilkobling).
  • Programmatisk med et embed-token ved hjelp av . Når du bruker et innebyggingstoken, går det faktiske filteret gjennom innebyggingstokenet for en bestemt økt.

JavaScript-filtre brukes til å tillate at brukeren forbruker en redusert visning, en områdevisning eller en filtrert visning av dataene. Imidlertid har brukeren fremdeles tilgang til tabeller, kolonner og mål for modellskjemaet og kan potensielt få tilgang til alle dataene her. Begrenset tilgang til dataene kan bare brukes med RLS og ikke gjennom API-er for filtrering på klientsiden.

Token-basert identitet med Azure SQL Database

med den tokens-baserte identiteten kan du angi den effektive identiteten for et embed-token ved hjelp av et Azure Active Directory (AAD) tilgangstoken for en Azure-SQL Database.

Kunder som holder dataene i Azure SQL Database, får nå en ny egenskap for administrering av brukere og deres tilgang til data i Azure SQL ved integrering med Power BI Embedded.

Når du genererer innebyggingstokenet, kan du angi den faktiske identiteten til en bruker i Azure SQL. Du kan angi den faktiske identiteten til en bruker ved å sende AAD-tilgangstokenet til serveren. Tokenet brukes bare til å hente relevante data for denne brukeren fra Azure SQL, for den bestemte økten.

Den kan brukes til å administrere hver brukers visning i Azure SQL, eller til å logge på Azure SQL som en bestemt kunde i en database med flere leiere. Det kan også anvende sikkerhet på radnivå på den økten i Azure SQL og hente bare relevante data for den økten, og dermed fjerne behovet for å administrere RLS i Power BI.

Slike problemer med faktisk identitet gjelder for RLS-regler direkte på Azure SQL Server. Power BI Embedded bruker det angitte tilgangstokenet ved spørring etter data fra Azure SQL Server. UPN for brukeren (som tokenet ble angitt for) er tilgjengelig som et resultat av SQL-funksjonen for USER_NAME().

Den tokenbaserte identiteten fungerer bare for DirectQuery-modeller med kapasitet – koblet til en Azure SQL Database, som er konfigurert til å tillate AAD-godkjenningen (Finn ut mer om AAD-godkjenningen for Azure SQL Database). Datakilden til datasettet må være konfigurert til å bruke sluttbrukernes OAuth2-legitimasjon for bruk av tokenbasert identitet.

Configure Azure SQL server

SDK-tillegg for tokenbasert identitet

Egenskapen for identitets-BLOB ble lagt til i den faktiske identiteten i scenarioet for tokengenerering.

[JsonProperty(PropertyName = "identityBlob")]
public IdentityBlob IdentityBlob { get; set; }

IdentityBlob-typen er en enkel JSON-struktur som holder en strengegenskap for verdi

[JsonProperty(PropertyName = "value")]
public string value { get; set; }

Den faktiske identiteten kan opprettes med en identitets-BLOB ved hjelp av følgende oppkall:

public EffectiveIdentity(string username, IList<string> datasets, IList<string> roles = null, string customData = null, IdentityBlob identityBlob = null);

Identitets-BLOB kan opprettes ved hjelp av følgende oppkall.

public IdentityBlob(string value);

Bruk av REST-API for tokenbasert identitet

Hvis du kaller REST-API-en, kan du legge til identitets-BLOB i hver identitet.

{
    "accessLevel": "View",
    "identities": [
        {
            "datasets": ["fe0a1aeb-f6a4-4b27-a2d3-b5df3bb28bdc"],
        "identityBlob": {
            "value": "eyJ0eXAiOiJKV1QiLCJh…."
         }
        }
    ]
}

Verdien som er angitt i identitets-BLOB-en, må være et gyldig tilgangstoken til Azure SQL Server (med nettadresse (https://database.windows.net/ for ressursen).

Obs!

Hvis du vil være i stand til å opprette et tilgangstoken for Azure SQL, må programmet ha delegert tillatelse fra Access Azure SQL DB og Data Warehouse til API for Azure SQL Database på registreringskonfigurasjon for AAD-appen i Azure Portal.

App registration

Lokal datagateway med tjenestekontohaver

Kunder som bruker SQL Server Analysis Services-datakilder (SSAS) med live-tilkobling, kan dra nytte av funksjonen som gjør det mulig for tjenestekontohaveren å administrere brukere og tilgangen deres til data i SSAS ved integrering med Power BI Embedded.

Ved bruk av REST-API-er for Power BI kan du spesifisere den effektive identiteten for lokale live-tilkoblinger for SSAS for et innebyggingstoken ved bruk av et tjenestekontohaverobjekt.

Frem til nå måtte hovedbrukeren som genererte innebyggingstokenet, være en administrator for gatewayen for å kunne spesifisere den effektive identiteten for lokal live-tilkobling for SSAS. I stedet for å kreve at brukeren skal være gateway-administrator, kan gateway-administratoren nå gi brukeren tillatelse som er dedikert til den datakilden, som lar brukeren overstyre den effektive identiteten ved generering av innebyggingstokenet. Denne nye egenskapen gjør det mulig å bygge inn med tjenestekontohaver for en live-tilkobling for SSAS.

Gateway-administratoren bruker, for å aktivere dette scenarioet, Legg til REST-API for datakildebruker til å gi tjenestekontohaveren ReadOverrideEffectiveIdentity-tillatelse for SSAS-datakilden.

Du kan ikke angi denne tillatelsen ved hjelp av administrasjonsportalen. Denne tillatelsen er bare angitt med API-en. I administrasjonsportalen ser du en indikasjon for brukere og SPN-er med slike tillatelser.

Obs!

Hvis du er koblet til en SSAS-database som ikke er konfigurert med RLS, må du fremdeles oppgi en faktisk identitet (identiteten til SSAS-serveradministratoren) i det innebygde tokengenereringsoppkallet.

Viktige faktorer og begrensninger

  • Tilordning av brukere til roller i Power BI-tjenesten har ikke innvirkning på RLS når det brukes et innebyggingstoken.
  • RLS-innstillingen bruker ikke administratorer eller medlemmer med redigeringstillatelser i Power BI-tjenesten, men når du angir en identitet med et innebyggingstoken, brukes den på dataene.
  • Live-tilkoblinger i Analysis Services støttes for lokale servere.
  • Live-tilkoblinger i Azure Analysis Services støtter filtrering av roller. Dynamisk filtrering kan utføres ved hjelp av CustomData.
  • Hvis det underliggende datasettet ikke krever RLS, må GenerateToken-forespørselen ikke inneholde en faktisk identitet.
  • Hvis det underliggende datasettet er en skymodell (hurtigbufret modell eller DirectQuery), må den faktiske identiteten inneholde minst én rolle, ellers forekommer det ingen rolletildeling.
  • En liste over identiteter muliggjør flere identitetstokener for innebygging av instrumentbordet. For alle andre artefakter inneholder listen én enkelt identitet.

Token-baserte identitetsbegrensninger

  • Du kan bruke RLS bare hvis du har en kapasitet.
  • RLS fungerer ikke med Microsoft SQL Servere lokalt.

Har du flere spørsmål? Prøv å spørre Power BI-fellesskapet