Planering av Power BI-implementering: Rapportera konsumentsäkerhetsplanering

Kommentar

Den här artikeln är en del av planeringsserien för Power BI-implementering. Den här serien fokuserar främst på Power BI-upplevelsen i Microsoft Fabric. En introduktion till serien finns i Implementeringsplanering för Power BI.

Den här artikeln om säkerhetsplanering beskriver strategier för skrivskyddade konsumenter. Fokus ligger på visningsbehörigheter för rapporter och appar och hur du framtvingar datasäkerhet. Det är främst inriktat på:

• Power BI-administratörer: De administratörer som ansvarar för att övervaka Power BI i organisationen.
• Center of Excellence-, IT- och BI-teamet: De team som också ansvarar för att övervaka Power BI. De kan behöva samarbeta med Power BI-administratörer, informationssäkerhetsteam och andra relevanta team.
• Innehållsskapare och ägare: Bi-skapare med självbetjäning som behöver skapa, publicera, skydda och hantera innehåll som andra användare använder.

Serien med artiklar är avsedd att utöka innehållet i vitboken om Power BI-säkerhet. I vitboken om Power BI-säkerhet fokuserar vi på viktiga tekniska ämnen som autentisering, datahemvist och nätverksisolering, men seriens främsta mål är att ge dig överväganden och beslut som hjälper dig att planera för säkerhet och sekretess.

I en organisation klassificeras många användare som konsumenter. Konsumenter visar innehåll som andra användare har skapat och publicerat. Konsumenterna står i fokus för den här artikeln. Säkerhetsplanering som fokuserar på innehållsskapare och ägare finns i artikeln Innehållsskapares säkerhetsplanering .

För att få ut mesta möjliga av den här artikeln är det bra att förstå innebörden av termer som delas och distribueras i power BI-kontexten.

Delning är där en användare ger en annan användare (eller grupp av användare) åtkomst till ett visst innehåll. Delningsfunktionen i Power BI-tjänst är begränsad till ett objekt. Det sker oftast mellan individer som känner varandra och arbetar nära varandra.

Distribution är platsen där innehåll levereras till andra användare, som kallas mottagare. Det handlar ofta om ett större antal användare i flera team. Mottagarna kanske inte uttryckligen har begärt innehållet, men det är känt att de behöver det för att utföra sin roll. Mottagare som använder distribuerat innehåll kanske eller kanske inte känner till den ursprungliga skaparen av innehållet. Därför är distribution som ett begrepp mer formellt än delning.

När du pratar med andra kan du avgöra om de använder termen delning på ett allmänt sätt, eller bokstavligen. Användning av termen delning kan tolkas på två sätt.

• Termen delning används ofta på ett allmänt sätt som rör delning av innehåll med kollegor. Det finns flera tekniker för att leverera skrivskyddat innehåll, som beskrivs i den här artikeln.
• Delning är också en specifik funktion i Power BI. Det är en funktion där en användare eller grupp beviljas åtkomst till ett enda objekt. Delningslänkar och direktåtkomstdelning beskrivs i den här artikeln.

Viktigt!

Power BI-administratörsrollen har bytt namn. Det nya namnet på rollen är Infrastrukturadministratör.

Strategi för skrivskyddade konsumenter

I Power BI-tjänst kan konsumenter visa en rapport eller instrumentpanel när de har behörighet till båda:

• Visa Det Power BI-objekt som innehåller visualiseringarna (till exempel en rapport eller instrumentpanel).
• Läs underliggande data (semantisk modell– tidigare känd som en datauppsättning – eller annan källa).

Du kan ge skrivskyddad åtkomst till konsumenter med hjälp av olika tekniker. De vanliga teknikerna som används av innehållsskapare med självbetjäning är:

• Bevilja användare och grupper åtkomst till en Power BI-app.
• Lägga till användare och grupper i en Power BI-arbetsytevisningsroll.
• Ge användare och grupper behörigheter per objekt med hjälp av en delningslänk.
• Ge användare och grupper behörigheter per objekt med direkt åtkomst.

Rollalternativen Power BI-appen och Power BI-arbetsytan Viewer omfattar hantering av behörigheter för en uppsättning objekt. De två teknikerna för behörigheter per objekt omfattar hantering av behörigheter för ett enskilt objekt.

Dricks

I allmänhet är det bästa praxis att använda en Power BI-app för de flesta konsumenter. Ibland kan arbetsytans visningsroll också vara lämplig. Både Power BI-appar och arbetsytans visningsroll tillåter hantering av behörigheter för många objekt och bör användas när det är möjligt. Att hantera behörigheter för enskilda objekt kan vara omständligt, tidskrävande och felbenäget. Att hantera en uppsättning objekt minskar däremot underhållet och förbättrar noggrannheten.

När du granskar säkerhetsinställningarna för ett objekt kan du se att dess behörigheter antingen är:

• Ärvd från arbetsytan eller en app.
• Tillämpas direkt på objektet.

I följande skärmbild visas behörigheter för direktåtkomst för en rapport. I det här fallet tilldelas arbetsytans administratörs- och medlemsroller var och en till en grupp. De här rollerna visas för rapporten eftersom åtkomsten på rapportnivå ärvs från arbetsytan. Det finns också en användare som har läsbehörigheter som tillämpas direkt på rapporten.

Den strategi du väljer för skrivskyddade konsumenter kan vara annorlunda. Den bör baseras på den enskilda lösningen, inställningarna för vem som hanterar lösningen eller konsumentens behov. Resten av det här avsnittet beskriver när du ska överväga att använda var och en av de tillgängliga teknikerna.

Checklista – När du skapar din strategi för hur du tillhandahåller innehåll till skrivskyddade konsumenter är viktiga beslut och åtgärder:

• Utvärdera din befintliga strategi för skrivskyddade konsumenter: Kontrollera hur innehållet för närvarande distribueras och delas till konsumenter. Identifiera om det finns möjligheter till förbättringar.
• Bestäm din strategi för skrivskyddade konsumenter: Tänk på vad dina inställningar är för att använda appbehörigheter, arbetsyteroller eller behörigheter per objekt. Om det behövs ändringar för att uppfylla dessa inställningar skapar du en plan för att göra förbättringar.

Power BI-appbehörigheter

En Power BI-app levererar en samling rapporter, instrumentpaneler och arbetsböcker till konsumenter. En app ger den bästa användarupplevelsen för konsumenter eftersom:

• Appens navigeringsfönster ger en enkel och intuitiv användarupplevelse. Det är en trevligare upplevelse än att komma åt innehåll direkt på en arbetsyta.
• Innehållet kan ordnas logiskt i avsnitt (som är som mappar) i appens navigeringsfönster.
• Konsumenter har bara åtkomst till specifika objekt som uttryckligen har inkluderats i appen för deras målgrupp.
• Länkar till ytterligare information, dokumentation eller annat innehåll kan läggas till i navigeringsfönstret för målgruppen.
• Det finns ett inbyggt arbetsflöde för begärandeåtkomst .

Kommentar

Alla referenser till en app i den här artikeln refererar till en Power BI-app. Det är ett annat koncept än Power Apps. Det är också ett annat koncept än Power BI-mobilapparna. I det här avsnittet fokuserar vi på organisationsappar i stället för mallappar.

Du kan skapa en app för varje arbetsyta som ett formellt sätt att distribuera innehåll på en eller flera arbetsytor. Appar är ett bra sätt att distribuera innehåll brett inom en organisation, särskilt till användare som du inte känner till eller inte samarbetar nära med.

Dricks

Mer information om hur du använder en Power BI-app för bred innehållsdistribution finns i företags-BI-användningsscenariot . Vi rekommenderar att innehållsskapare som behöver distribuera innehåll överväger att skapa en app som sitt första val.

Du hanterar appbehörigheter separat från arbetsyteroller. Separationen av behörigheter har två fördelar. Det uppmuntrar:

• Bevilja arbetsytan åtkomst till innehållsskapare. Den innehåller användare som aktivt samarbetar med innehållet, till exempel skapare av semantiska modeller, rapportskapare och testare.
• Bevilja appbehörigheter till konsumenter. Till skillnad från arbetsytebehörigheter är appbehörigheter alltid skrivskyddade (eller inga).

Alla användare med åtkomst till arbetsytan kan automatiskt visa appen (när en Power BI-app har publicerats för arbetsytan). På grund av det här beteendet kan du begreppsmässigt betrakta arbetsyteroller som ärvda av varje apppublik. Vissa användare med åtkomst till arbetsytan kan också uppdatera Power BI-appen, beroende på deras tilldelade arbetsyteroll.

Dricks

Mer information om åtkomst till arbetsytor finns i artikeln Innehållsskapares säkerhetsplanering .

Att använda en app för att distribuera innehåll till skrivskyddade konsumenter är det bästa valet när:

• Du vill att användarna endast ska kunna visa specifika objekt som är synliga för den målgruppen (i stället för alla objekt på den underliggande arbetsytan).
• Du vill hantera skrivskyddade behörigheter för appen separat från arbetsytan.
• Du vill ha enklare behörighetshantering för skrivskyddade användare än behörigheter per objekt.
• Du vill se till att säkerhet på radnivå tillämpas för konsumenter (när de har skrivskyddad behörighet för den underliggande semantiska modellen).
• Du vill se till att konsumenterna inte kan visa nya och ändrade rapporter förrän appen publiceras på nytt.

Det är sant att ändringar i rapporter och instrumentpaneler inte är synliga för användare av appen förrän appen har publicerats på nytt, men det finns två överväganden som kräver försiktighet.

• Omedelbara ändringar av semantiska modeller: Ändringar av semantiska modeller börjar alltid gälla omedelbart. Om du till exempel introducerar icke-bakåtkompatibla ändringar i en semantisk modell på arbetsytan kan det oavsiktligt leda till att rapporter blir instabila (även om de inte har publicerats på nytt i appen). Det finns två sätt att minska den här risken: För det första utför du allt utvecklingsarbete i Power BI Desktop (separat från arbetsytan). För det andra isolerar du produktionsappen med hjälp av separata arbetsytor för utveckling och testning. (Du kan också få en högre kontroll över distributionen av arbetsyteinnehåll från utveckling till test och produktion med hjälp av distributionspipelines.)
• Innehåll och behörigheter publiceras tillsammans: När du publicerar en app publiceras dess behörigheter samtidigt som innehållet. Du kan till exempel ha rapportändringar på en arbetsyta som ännu inte har slutförts, testats fullständigt eller godkänts. Därför kan du inte publicera om appen bara för att uppdatera behörigheter. För att minska den här risken tilldelar du appbehörigheter till säkerhetsgrupper och använder medlemskap i säkerhetsgrupper (i stället för enskilda användare) när du beviljar appbehörigheter. Undvik att publicera om en app bara för att tillämpa behörighetsändringar.

Apppublik

Varje arbetsyta i Power BI-tjänst kan bara ha en Power BI-app. I appen kan du dock skapa en eller flera målgrupper. Föreställ dig följande scenario.

• Du har fem försäljningsrapporter som distribueras till många användare i din globala försäljningsorganisation.
• En målgrupp definieras i appen för säljrepresentanterna. Den här målgruppen kan visa tre av de fem rapporterna.
• En annan målgrupp definieras i appen för säljledarteamet. Den här målgruppen kan visa alla fem rapporter, inklusive de två rapporter som inte är tillgängliga för säljrepresentanter.

Den här funktionen för att blanda och matcha innehåll och målgrupper har följande fördelar.

• Vissa rapporter kan vara tillgängliga för visning av flera målgrupper. Att skapa flera målgrupper tar därför bort behovet av att duplicera innehåll på olika arbetsytor.
• Vissa rapporter bör endast vara tillgängliga för en målgrupp. Därför kan innehåll för den målgruppen finnas på samma arbetsyta som annat relaterat innehåll.

Följande skärmbild visar en app med två målgrupper: Sales Leadership och Sales Reps. Fönstret Hantera målgruppsåtkomst ger åtkomst till målgruppsgruppen Sales Leadership för två säkerhetsgrupper: Sales Leadership-Nordamerika och Sales Leadership-Europe. Rapporten Bruttomarginalanalys som visas i skärmbilden för målgruppsgruppen Sales Leadership är inte tillgänglig för målgruppsgruppen Säljare .

Kommentar

Termen målgruppsgrupp används ibland. Det är inte en direkt referens till användningen av säkerhetsgrupper. Den innehåller medlemmar i målgruppen som kommer att se samlingen med innehåll i en Power BI-app. Du kan tilldela enskilda användare till en målgrupp, men det är en bra idé att tilldela säkerhetsgrupper, Microsoft 365-grupper eller distributionsgrupper när det är praktiskt möjligt. Mer information finns i artikeln om hur du använder grupper i säkerhetsplanering på klientorganisationsnivå.

När du hanterar behörigheter för en app kan du på sidan Direktåtkomst visa medlemmarna i varje målgrupp. Du kan också se användare med en arbetsyteroll som visas under Alla målgrupper. Du kan inte uppdatera appbehörigheterna från sidan Direktåtkomst . I stället måste du publicera om appen. Du kan dock uppdatera appbehörigheter från sidan Väntar när det finns öppna åtkomstbegäranden för appen.

Dricks

Det primära användningsfallet för att använda apppubliker är att definiera specifika behörigheter för olika uppsättningar användare. Du kan dock bli lite kreativ när du använder målgrupper. En användare kan vara medlem i flera målgrupper och varje målgrupp visas för appens tittare som en sekundär uppsättning menyer. Du kan till exempel skapa en målgrupp med namnet Start Here som innehåller information om hur du använder appen, vem du ska kontakta, hur du ger feedback och hur du får hjälp. Eller så kan du skapa en målgrupp med namnet KPI-definitioner som innehåller en dataordlista. Att tillhandahålla den här typen av information hjälper nya användare och förbättrar arbetet med att implementera lösningar.

Alternativ för appbehörighet

När du skapar (eller publicerar om) en app har varje målgrupp fönstret Hantera målgruppsåtkomst . I det fönstret är följande behörigheter tillgängliga.

• Bevilja åtkomst till: För varje målgrupp kan du bevilja åtkomst till enskilda användare och grupper. Det går att publicera appen till hela organisationen när den aktiveras av inställningen Publicera appar till hela organisationens klientorganisation och appen inte installeras automatiskt. När det är möjligt rekommenderar vi att du tilldelar grupper till målgrupper eftersom tillägg eller borttagning av användare innebär att appen publiceras på nytt. Alla med åtkomst till arbetsytan har automatiskt behörighet att visa eller uppdatera appen beroende på deras arbetsyteroll.
• Semantisk modellbehörighet: Två typer av semantiska modellbehörigheter kan beviljas när du publicerar en app:
  • Semantisk modell Dela om: När den är aktiverad beviljas appanvändare behörigheten Dela om till de underliggande semantiska modellerna med andra. Det är klokt att aktivera det här alternativet när den underliggande semantiska modellen eller de underliggande semantikmodellerna enkelt kan delas igen med vem som helst. Vi rekommenderar att du får godkännande från semantikmodellens ägare innan du beviljar behörigheten Dela om till en apppublik.
  • Semantisk modellVersion: När den är aktiverad beviljas appanvändare behörigheten Skapa för semantiska modeller. Med byggbehörighet kan användare skapa nya rapporter, exportera underliggande data från rapporter med mera. Vi rekommenderar att du får godkännande från semantikmodellens ägare innan du beviljar Build-behörighet till en apppublik.

Det är praktiskt att lägga till semantikmodellen Dela om eller skapa behörigheter när du publicerar en app. Vi rekommenderar dock att du överväger att hantera appbehörigheter och semantiska modellbehörigheter separat. Här är anledningarna till varför.

• Delad semantisk modell kan finnas i en separat arbetsyta: Om den semantiska modellen publiceras till en separat arbetsyta från appen måste du hantera dess behörigheter direkt. Möjligheten att lägga till läs-, bygg- eller delningsbehörigheter när du publicerar en app fungerar bara för semantiska modeller som finns på samma arbetsyta som appen. Därför rekommenderar vi att du använder för vana att hantera semantiska modellbehörigheter oberoende av varandra.
• Semantiska modellbehörigheter hanteras separat: Om du tar bort eller ändrar behörigheter för en app påverkar åtgärden endast appen. Den tar inte automatiskt bort de semantiska modellbehörigheter som tidigare tilldelats. På så sätt kan du betrakta appbehörigheter och semantiska modellbehörigheter som frikopplade. Du måste hantera den semantiska modellen direkt, separat från appen, när semantiska modellbehörigheter ändras eller måste tas bort.
• Semantiska modellbehörigheter bör kontrolleras: Om du beviljar semantiska modellbehörigheter via en app tas kontrollen bort från semantikmodellens ägare. Att bevilja behörigheten Dela om bygger på ett gott omdöme av användare som väljer att dela om semantiska modeller. Dina interna styrnings- eller säkerhetsriktlinjer kan bli svårare att hantera när omdelning tillåts.
• Konsumenter och skapare har olika mål: Vanligtvis finns det många fler innehållskonsumenter än skapare i en organisation. I enlighet med principen om lägsta behörighet behöver konsumenterna bara läsbehörighet för den underliggande semantiska modellen. De behöver inte skapa-behörighet om de inte tänker skapa nya rapporter.

Dricks

Mer information om när du ska använda separata dataarbetsytor och rapporteringsarbetsytor finns i artikeln Planering på arbetsytenivå.

Förinstallationsrättigheter för appar

När du har publicerat en Power BI-app måste en användare vanligtvis installera den så att de kan öppna den. En användare kan installera en app från sidan Appar i Power BI-tjänst eller genom att använda en länk som de har fått från en annan användare. De kommer att kunna hitta (och installera) en app när de ingår i minst en målgrupp i appen.

En annan metod för att installera en app är att push-överföra den till appkonsumenter. Det resulterar i förinstallationen av appen så att den automatiskt visas på sidan Appar i Power BI-tjänst. Den här metoden är en bekvämlighet för konsumenterna eftersom de inte behöver hitta och installera appen. Förinstallerade appar kan dock bli irriterande för användare eftersom de kan bli överväldigade av för många appar som inte är relevanta för dem.

Inställningen Push-appar till slutanvändares klientorganisation styr vem som får installera appar automatiskt. Vi rekommenderar att du använder den här funktionen eftersom den är praktisk för användarna. Men vi rekommenderar också att du utbildar innehållsskaparna om när de ska använda det så att det inte överanvänds.

Dricks

Om du väljer alternativet att installera appen automatiskt när du publicerar en app kan du inte ange att målgruppen ska vara hela organisationen (om den aktiveras av inställningen Push-appar till slutanvändares klientorganisation).

Checklista – När du skapar din strategi för att använda appar för innehållsvisning är viktiga beslut och åtgärder:

• Besluta om strategin för användning av appar: Definiera dina inställningar för hur du använder appar. Se till att den överensstämmer med din övergripande strategi för skrivskyddade konsumenter.
• Bestäm vem som kan publicera appar till hela organisationen: Bestäm vilka rapportskapare som ska kunna publicera till hela organisationen. Ange inställningen Publicera appar till hela organisationens klientorganisation så att den överensstämmer med det här beslutet.
• Bestäm vem som kan skicka appar till slutanvändare: Bestäm vilka Power BI-rapportskapare som kan förinstallera appar. Ställ in inställningen Push apps to end users tenant to align with this decision (Push apps to end users tenant setting to end users tenant) så att den överensstämmer med det här beslutet.
• Skapa och publicera vägledning för innehållsskapare: Tillhandahålla dokumentation och utbildning för innehållsskapare. Inkludera krav och inställningar för hur du använder appar mest effektivt.
• Fastställ hur appåtkomstbegäranden ska hanteras: Se till att det finns en process för att tilldela kontakter och hantera appåtkomstbegäranden i tid.

Arbetsytevisningsroll

Enligt beskrivningen i arbetsyteplaneringsartiklarna är det primära syftet med en arbetsyta samarbete. Medarbetare på arbetsytan, till exempel semantiska modellskapare, rapportskapare och testare, bör tilldelas till någon av tre roller: Deltagare, Medlem eller Administratör. De här rollerna beskrivs i artikeln Innehållsskapares säkerhetsplanering .

Du kan tilldela arbetsytans visningsroll till konsumenter. Att tillåta konsumenter att komma åt innehåll direkt på en arbetsyta kan vara meningsfullt för små team och informella team som arbetar nära varandra.

Att tillåta konsumenter att komma åt innehåll på arbetsytan direkt är ett bra val när:

• Formaliteten för en app, med dess separata behörigheter, är inte nödvändig.
• Visningsprogram får visa alla objekt som lagras på arbetsytan.
• Du vill ha enklare behörighetshantering än behörigheter per objekt.
• Arbetsyteanvändare kan också visa en app (när en app publiceras för arbetsytan).
• Avsikten är att tittarna ska granska innehåll innan det publiceras i en app.

Här följer några förslag för att stödja arbetsytevisning.

• Ordna innehåll på varje arbetsyta så att objekten enkelt kan hittas av rapportkonsumenter och så att de överensstämmer väl med säkerheten. Arbetsytans organisation efter ämnesområde eller projekt fungerar vanligtvis bra.
• Separera utvecklings- och testinnehåll från produktionsinnehåll så att objekt som pågår i arbetet inte kan nås av tittarna.
• Använd appar (eller behörigheter per objekt när det är lämpligt) när du förväntar dig att ha många åtkomstbegäranden att bearbeta. Det finns inget arbetsflöde för begärandeåtkomst för arbetsytor.

Checklista – När du skapar din strategi för att använda arbetsytor för innehållsvisning är viktiga beslut och åtgärder:

• Bestäm en strategi för att använda arbetsytans visningsroll: Definiera vad dina inställningar är för hur du använder arbetsytor för konsumenter. Se till att den överensstämmer med din övergripande strategi för skrivskyddade konsumenter.
• Skapa och publicera vägledning för innehållsskapare: Tillhandahålla dokumentation och utbildning för innehållsskapare. Inkludera krav och inställningar för hur du använder arbetsytebehörigheter mest effektivt.

Behörigheter per objekt

Delning av enskilda objekt ger behörighet till ett enskilt objekt. Mindre erfarna innehållsskapare använder ofta den här tekniken som den primära delningstekniken eftersom delningskommandona visas på ett framträdande sätt i Power BI-tjänst. Därför är det viktigt att utbilda innehållsskapare om de olika delningsalternativen, inklusive när appbehörigheter ska användas i stället för arbetsyteroller.

Behörigheter per objekt är ett bra alternativ när:

• Du vill ge skrivskyddad åtkomst till ett objekt (rapport eller instrumentpanel).
• Du vill inte att konsumenten ska visa allt innehåll som publicerats på en arbetsyta.
• Du vill inte att konsumenten ska visa allt innehåll som publicerats till en apppublik.

Använd behörigheter per objekt sparsamt eftersom delning ger läsbehörighet till ett enda objekt. På sätt och vis kan du se behörigheter per objekt som en åsidosättning av arbetsyteroller eller appbehörigheter.

Dricks

Vi rekommenderar att du använder appbehörigheter när det är möjligt. Överväg sedan att använda arbetsyteroller för att aktivera direkt åtkomst till arbetsytor. Slutligen använder du behörigheter per objekt när de uppfyller ovanstående villkor. Både appbehörigheter och arbetsyteroller anger säkerhet för en samling innehåll (snarare än enskilda objekt), vilket är en bättre säkerhetspraxis.

Att dela många objekt med hjälp av behörigheter per objekt kan vara omständligt och felbenäget, särskilt när du delar till enskilda användare i stället för grupper. Tänk på det här scenariot: Du har 40 rapporter som du har delat med kollegor med hjälp av deras enskilda användarkonton. När en kollega överförs till en annan avdelning måste du återkalla deras åtkomst, vilket innebär redigeringsbehörigheter för alla 40 rapporter.

Viktigt!

Det bör göras sällan att dela innehåll från en personlig arbetsyta. Personliga arbetsytor passar bäst för icke-kritiskt, informellt eller tillfälligt innehåll. Om du har en situation där innehållsskapare ofta delar viktigt eller kritiskt innehåll från sina personliga arbetsytor bör du vidta lämpliga åtgärder för att flytta innehållet till en standardarbetsyta. Mer information finns i scenariot för personlig BI-användning .

När du delar ett enskilt objekt har du flera behörighetsalternativ.

• Delningsbehörighet: När det är aktiverat kan användarna dela objektet med andra användare, inklusive dess underliggande semantiska modeller. Det är klokt att bevilja den här behörigheten när objektet enkelt kan delas med vem som helst. Den tar bort kontrollen från den person eller det team som hanterar objektet. Därför förlitar den sig på ett gott omdöme av användare som har beviljats behörigheten Dela vidare. Dina interna styrnings- eller säkerhetsriktlinjer kan dock bli svårare att hantera när omdelning tillåts.
• Byggbehörighet: När den är aktiverad beviljas användarna byggbehörighet för den underliggande semantiska modellen. Med byggbehörighet kan användare skapa nytt innehåll som baseras på den semantiska modellen. Det gör det också möjligt för dem att exportera underliggande data från rapporter med mera. Överväganden för att bevilja build-behörighet beskrivs i artikeln Innehållsskapares säkerhetsplanering .

Behörigheter per objekt för rapporter och instrumentpaneler kan vara meningsfulla för informella scenarier när innehåll delas med några användare. Det är en bra idé att utbilda användare om att hantera behörigheter med appar och arbetsytor i stället, särskilt när de delar innehåll till ett stort antal användare eller användare utanför teamet. Det är viktigt att betona följande punkter.

• Det blir svårare att avgöra vilket innehåll som har delats med vilka användare, eftersom behörigheterna för varje rapport och instrumentpanel måste granskas individuellt.
• I många fall anges behörigheten Dela igen eftersom användarupplevelsen aktiverar det här alternativet som standard. Det finns därför en risk att innehållet delas till en bredare uppsättning användare än avsett. Det här resultatet kan förhindras genom att avmarkera alternativet Tillåt mottagare att dela den här rapporten vid delning. Att minimera överdelning på det här sättet är ett problem med användarträning. Den innehållsskapare som anger delningsbehörigheter bör överväga det här valet varje gång.
• Alla ändringar i rapporter och instrumentpaneler kan visas av andra omedelbart, vilket kan förvirra användare när innehållsändringar pågår. Det här problemet kan åtgärdas genom att distribuera innehåll i en app eller genom att använda separata arbetsytor för att särskilja innehåll för utveckling, testning och produktion. Mer information finns i användningsscenariot för självbetjäning av innehållspublicering .
• När en användare delar innehåll från sin personliga arbetsyta och de lämnar organisationen inaktiverar IT vanligtvis deras användarkonto. I det här fallet förlorar alla mottagare av det delade innehållet omedelbart åtkomsten till innehållet.

Det finns tre specifika typer av delning: delningslänkar, direkt åtkomstdelning och delade vyer.

Behörighetslänkar per objekt

När du delar ett enskilt objekt resulterar standardupplevelsen i en delningslänk. Det finns tre typer av delningslänkar.

• Personer i din organisation: När den här typen av delningslänk är aktiverad i dina Power BI-klientinställningar är det ett enkelt sätt att ge skrivskyddad åtkomst till alla i organisationen. Delningslänken fungerar dock inte för externa användare. Det här alternativet passar bäst när vem som helst kan visa innehållet och länken kan delas fritt i hela organisationen. Om den inte inaktiveras av inställningen Tillåt delningsbara länkar för att bevilja åtkomst till alla i organisationens klientorganisation är den här typen av delning standard.
• Personer med befintlig åtkomst: Det här alternativet skapar ingen ny delningslänk. I stället kan du hämta URL:en så att du kan skicka den till någon som redan har åtkomst.
• Specifika personer: Det här alternativet skapar en delningslänk för specifika användare eller grupper. Vi rekommenderar att du använder det här alternativet för det mesta eftersom det ger specifik åtkomst. Om du ofta arbetar med externa användare kan du använda den här typen av länk för gästanvändare som redan finns i Microsoft Entra-ID (tidigare kallat Azure Active Directory). Mer information om den planerade inbjudan att skapa gästanvändare finns i artikeln Säkerhetsplanering på klientorganisationsnivå.

Viktigt!

Vi rekommenderar att du överväger att begränsa inställningen Tillåt delningsbara länkar för att ge åtkomst till alla i organisationens klientorganisation till medlemmar i en grupp. Du kan skapa ett gruppnamn som Power BI-resurs till hela organisationen och sedan lägga till ett litet antal användare som förstår konsekvenserna av delning över hela organisationen. Om du är orolig för befintliga organisationsomfattande länkar kan du använda administratörs-API:et för att hitta alla objekt som har delats med hela organisationen.

En delningslänk lägger till läsbehörighet för objektet. Behörigheten Dela om är markerad som standard. Det går också att lägga till Build-behörighet till den underliggande semantiska modellen samtidigt som delningslänken skapas.

Dricks

Vi rekommenderar att du lär innehållsskapare att aktivera alternativet Skapa-behörighet endast när rapportkonsumenten också är en innehållsskapare som kan behöva skapa rapporter, exportera data eller skapa en sammansatt modell från den underliggande semantiska modellen.

Delningslänkar är enklare att underhålla än direktåtkomstdelning, särskilt när du behöver göra massändringar. Det är en stor fördel när enskilda användare beviljas delningsbehörigheter, mer än grupper (vilket ofta inträffar när självbetjäningsanvändare ansvarar för att hantera behörigheter). Ta följande jämförelser som exempel.

• Delningslänk: 20 enskilda användare beviljas åtkomst med en delningslänk. Med en enda ändring av länken påverkar den alla 20 användare.
• Direkt åtkomst: 20 personer beviljas direkt åtkomst till ett objekt. Om du vill göra en ändring måste alla 20 användarbehörigheter ändras.

Direktåtkomstbehörigheter per objekt

Du kan också uppnå behörigheter per objekt med direkt åtkomst. Direktåtkomst innebär att du konfigurerar behörigheter för ett enskilt objekt. Du kan också fastställa ärvda behörigheter som härleds från arbetsyteroller.

När du beviljar en användare direkt åtkomst beviljas de läsbehörighet för objektet. Behörigheten Dela om är markerad som standard, liksom build-behörigheten för den underliggande semantiska modellen. Vi rekommenderar att du lär innehållsskapare att endast aktivera build-behörighet när användaren av den här rapporten också är en innehållsskapare som kan behöva skapa rapporter, exportera data eller skapa sammansatta modeller från den underliggande semantiska modellen.

Dricks

Användarupplevelsen gör det mycket enkelt att bevilja behörigheter för att dela om och skapa, men användaren som utför delning bör alltid kontrollera om dessa behörigheter är nödvändiga.

Delade vyer

Använd en delad vy för att dela ett filtrerat perspektiv på en rapport med en annan användare. Du kan publicera en delad vy med hjälp av en delningslänk eller direktåtkomst.

Delade vyer är ett tillfälligt begrepp. De upphör automatiskt att gälla efter 180 dagar. Därför passar delade vyer bäst för informella och tillfälliga delningsscenarier. Se till att användarna är medvetna om den här begränsningen.

Checklista – När du skapar din strategi för att använda behörigheter per objekt inkluderar viktiga beslut och åtgärder:

• Besluta om strategin för användning av delningsfunktionen: Definiera vad dina inställningar är för hur du använder behörigheter per objekt. Se till att den överensstämmer med din övergripande strategi för skrivskyddade konsumenter.
• Bestäm vem som kan publicera länkar till hela organisationen: Bestäm vilka rapportskapare som ska kunna publicera länkar för hela organisationen. Ange inställningen Tillåt delningsbara länkar för att bevilja åtkomst till alla i organisationens klientorganisation så att de överensstämmer med det här beslutet.
• Skapa och publicera vägledning för innehållsskapare: Tillhandahåll dokumentation och utbildning för innehållsskapare som innehåller krav och inställningar för hur du använder behörigheter per objekt mest effektivt. Se till att de är tydliga med fördelarna och nackdelarna med behörigheter per objekt. Ta med vägledning för när delningslänkar ska användas och när direktåtkomstdelning ska användas.

Andra tekniker för konsumentfrågor

De vanligaste sätten för konsumenter att interagera med Power BI är med appar, arbetsytor och behörigheter per objekt (beskrivs tidigare i den här artikeln).

Det finns andra tekniker som konsumenter kan använda för att köra frågor mot Power BI-data. Var och en av följande frågetekniker kräver semantisk modell eller datamart Build-behörighet.

• Analysera i Excel: Konsumenter som föredrar att använda Excel kan köra frågor mot en Power BI-semantisk modell med hjälp av Analysera i Excel. Den här funktionen är ett bra alternativ till att exportera data till Excel eftersom data inte dupliceras. Med en live-anslutning till den semantiska modellen kan användarna skapa pivottabeller, diagram och utsnitt. De kan sedan publicera arbetsboken till en arbetsyta i Power BI-tjänst som gör att användarna kan öppna den och interagera med den.
• XMLA-slutpunkt: Konsumenter kan fråga en semantisk modell genom att ansluta till XMLA-slutpunkten. Ett program som är XMLA-kompatibelt kan ansluta till, fråga och använda en semantisk modell som lagras på en Premium-arbetsyta. Den här funktionen är användbar när konsumenter vill använda en Power BI-semantisk modell som datakälla för ett datavisualiseringsverktyg utanför Microsofts ekosystem.
• Datamart-redigerare: Konsumenter kan köra frågor mot en Power BI-datamart med hjälp av datamartredigeraren. Det är en webbaserad visuell frågeredigerare för att skapa frågor utan kod. Det finns också en webbaserad SQL-redigerare för när konsumenter föredrar att skriva SQL-frågor. Båda redigerarna frågar den hanterade Azure SQL Database som ligger till grund för Power BI-datamart (i stället för den inbyggda semantiska modellen).
• SQL-slutpunkt: Konsumenter kan köra frågor mot en Power BI-datamart med hjälp av SQL-slutpunkten. De kan använda verktyg som Azure Data Studio eller SQL Server Management Studio (SSMS) för att köra SQL-frågor. SQL-slutpunkten dirigerar frågor till den hanterade Azure SQL Database som ligger till grund för Power BI-datamart (i stället för den inbyggda semantiska modellen).

Mer information om behörigheten Skapa finns i artikeln Innehållsskapares säkerhetsplanering .

Checklista – När du planerar vilka frågetekniker som konsumenter ska använda, omfattar viktiga beslut och åtgärder:

• Skapa vägledning för användare om hur de använder Analysera i Excel: Tillhandahålla dokumentation och utbildning för konsumenter på det bästa sättet att återanvända befintliga semantiska modeller med Excel.
• Skapa vägledning för användare om hur de använder XMLA-slutpunkten: Ange dokumentation och utbildning för konsumenter på det bästa sättet att återanvända befintliga semantiska modeller med XMLA-slutpunkten.
• Skapa vägledning för användare om datamartfrågor: Ange dokumentation och utbildning för konsumenter om tillgängliga tekniker för att köra frågor mot Power BI-datamarter.

Begär åtkomstarbetsflöde för konsumenter

När du delar innehåll är det vanligt att en användare vidarebefordrar en länk (URL) till en annan användare. När mottagaren försöker visa innehållet och upptäcker att de inte har åtkomst till det kan de välja knappen Begär åtkomst . Den här åtgärden initierar arbetsflödet Begär åtkomst . Användaren uppmanas sedan att ange ett meddelande för att förklara varför de vill ha åtkomst.

Det finns ett arbetsflöde för begärandeåtkomst för:

• Åtkomst till en Power BI-app.
• Åtkomst till ett objekt, till exempel en rapport eller instrumentpanel.
• Åtkomst till en semantisk modell. Mer information om arbetsflödet begär åtkomst när en semantisk modell kan identifieras finns i artikeln Innehållsskapares säkerhetsplanering .

Begäranden om appåtkomst

Det finns två sätt att lära dig mer om väntande åtkomstbegäranden som har skickats för en app.

• E-post: Kontakterna för appen får ett e-postmeddelande. Som standard är den här kontakten apputgivaren. För att ge bättre stöd för kritiska appar rekommenderar vi att du ställer in kontakten på en grupp som snabbt kan svara på åtkomstbegäranden.
• Menyn Hantera behörigheter: Arbetsyteadministratörer och medlemmar kan visa, godkänna eller avvisa åtkomstbegäranden. Sidan Hantera behörigheter är tillgänglig på sidan Appar och kan öppnas för varje app. Den här funktionen är också tillgänglig för arbetsytedeltagare när inställningen Tillåt deltagare att uppdatera appen för den här arbetsytan är aktiverad.

Väntande åtkomstbegäranden för en app visar meddelandet från användaren. Varje väntande begäran kan godkännas eller avvisas. När du väljer att godkänna en begäran måste en apppublik väljas.

Följande skärmbild visar en väntande åtkomstbegäran från en användare. För att godkänna det måste en av de två apppublikerna, Sales Reps eller Sales Leadership, väljas.

När du publicerar en app publiceras innehållet och behörigheterna samtidigt. Som tidigare beskrivits går det inte att endast publicera appbehörigheterna utan innehållsändringar. Det finns dock ett undantag: När du godkänner en väntande åtkomstbegäran (till exempel den som visas i föregående skärmbild) sker behörighetsändringen utan att det senaste innehållet på arbetsytan publiceras.

Åtkomstbegäranden för arbetsyta

Åtkomst till arbetsyta beviljas av användare som tillhör administratörsrollen eller medlemsrollen.

En användare som försöker visa en arbetsyta får ett meddelande om nekad åtkomst när de inte är medlemmar i en arbetsyteroll. Eftersom det inte finns något inbyggt arbetsflöde för begärandeåtkomst för arbetsytor används de bäst för små team och informella team som arbetar nära varandra. Det är en av anledningarna till att en Power BI-app passar bättre för större team och bredare scenarier för innehållsdistribution.

Åtkomstbegäranden per objekt

Det finns två sätt att lära dig mer om väntande åtkomstbegäranden som har skickats för ett enskilt objekt, till exempel en rapport.

• E-post: Kontakterna för objektet får ett e-postmeddelande. För att ge bättre stöd för kritiska rapporter rekommenderar vi att du ställer in kontakten på en grupp som snabbt kan svara på åtkomstbegäranden.
• Menyn Hantera behörigheter: Arbetsyteadministratörer och medlemmar kan komma åt sidan Hantera behörigheter för varje objekt. De kan visa, godkänna eller neka åtkomst till väntande begäranden.

Hantera åtkomstbegäranden med grupper

När en användare skickar formuläret Begär åtkomst för ett Power BI-objekt (till exempel en rapport eller semantisk modell) eller en Power BI-app skickas begäran för en enskild användare. Många stora organisationer måste dock använda grupper för att följa sina interna säkerhetsprinciper.

Vi rekommenderar att du använder grupper, snarare än enskilda personer, för att skydda innehåll när det är praktiskt. Mer information om hur du planerar för grupper finns i artikeln Säkerhetsplanering på klientorganisationsnivå.

Om du tänker ge åtkomst till grupper i stället för enskilda användare måste innehållsägaren eller administratören som bearbetar begäran om åtkomst slutföra begäran i flera steg:

1. Avvisa den väntande begäran i Power BI (eftersom den är associerad med en enskild användare).
2. Lägg till beställaren i rätt grupp enligt din aktuella process.
3. Meddela beställaren att de nu har åtkomst.

Dricks

Mer information om hur du svarar på begäranden om skapa åtkomst från innehållsskapare finns i Begär åtkomstarbetsflöde för skapare . Den innehåller även rekommendationer om hur du använder ett formulär för åtkomstbegäranden.

Checklista – När du planerar arbetsflödet för begärandeåtkomst omfattar viktiga beslut och åtgärder:

• Avgör vem som ska hantera appåtkomstbegäranden: Kontrollera att det finns en process för att hantera appåtkomstbegäranden i tid. Kontrollera att appkontakter har tilldelats för att stödja processen.
• Avgör vem som ska hantera begäranden per objekt: Se till att det finns en process för att hantera åtkomstbegäranden i tid. Se till att kontakter tilldelas till varje objekt för att stödja processen.
• Inkludera i dokumentation och utbildning för innehållsskapare: Se till att innehållsskapare förstår hur åtkomstbegäranden hanteras i tid. Gör dem medvetna om hur du hanterar begäranden när en grupp ska användas i stället för en enskild användare.
• Inkludera i dokumentation och utbildning: Inkludera vägledning för innehållsskapare om hur du hanterar åtkomstbegäranden effektivt. Inkludera även vägledning för konsumenter om vilken information som ska ingå i deras meddelande om åtkomstbegäran.

Framtvinga datasäkerhet baserat på konsumentidentitet

Du kan planera att skapa färre semantiska modeller och rapporter genom att framtvinga datasäkerhet. Målet är att framtvinga datasäkerhet baserat på identiteten för den användare som visar innehållet.

Anta till exempel att du kan dela en enskild försäljningsrapport med alla säljare (konsumenter) och veta att varje säljare bara ser försäljningsresultat för sin region. Med den här metoden kan du undvika komplexiteten i att skapa separata rapporter per region som skulle behöva delas med säljarna från den försäljningsregionen.

Vissa organisationer har specifika krav för godkända (certifierade eller upphöjda) semantiska modeller eller datamarter. För data som används i stor utsträckning kan det finnas ett krav på att använda datasäkerhet.

Du kan utföra datasäkerhet på flera sätt.

• Power BI-semantisk modell: Som Power BI-dataskapare kan du framtvinga säkerhet på radnivå (RLS) och säkerhet på objektnivå (OLS). RLS handlar om att definiera roller och regler som filtrerar datamodellrader, medan OLS begränsar åtkomsten till specifika tabeller eller kolumner. Dessa definierade RLS- och OLS-regler gäller inte för referenser som lagras utanför den semantiska modellen, till exempel utsnitts- och filterval. Både RLS- och OLS-tekniker beskrivs ytterligare senare i det här avsnittet.
• Analysis Services: En semantisk modell för liveanslutning kan ansluta till en fjärrdatamodell som hanteras av antingen Azure Analysis Services (AAS) eller SQL Server Analysis Services (SSAS). Fjärrmodellen kan framtvinga RLS eller OLS baserat på konsumentidentiteten.
• Datakälla: Vissa datakällor, till exempel Azure SQL Database, kan framtvinga RLS. I det här fallet kan Power BI-modellen dra nytta av den befintliga säkerheten i stället för att omdefiniera den. Den metoden kan vara en betydande fördel när RLS som definieras i källan är komplext. Du kan utveckla och publicera en DirectQuery-modell och ange autentiseringsuppgifterna för datakällan för den semantiska modellen i Power BI-tjänst för att aktivera enkel inloggning (SSO). När en rapportkonsument öppnar en rapport skickar Power BI sin identitet till datakällan. Datakällan tillämpar sedan RLS baserat på rapportkonsumentens identitet. Mer information om Azure SQL Database RLS finns i den här artikeln.

Kommentar

Källsystem, till exempel Azure SQL Database, kan också använda tekniker som vyer för att begränsa vad användaren kan se. Även om det är en giltig teknik är den inte relevant för fokus i det här avsnittet.

Säkerhet på radnivå

Med säkerhet på radnivå (RLS) kan en datamodellerare begränsa åtkomsten till en delmängd data. Den används vanligtvis för att säkerställa att vissa rapportkonsumenter inte kan se specifika data, till exempel försäljningsresultat från andra försäljningsregioner.

Dricks

Om du har märkt att någon har skapat flera datamodeller för att stödja olika konsumentgrupper kontrollerar du om RLS uppfyller deras krav. Det är vanligtvis bättre att skapa, testa och underhålla en datamodell i stället för flera datamodeller.

Var försiktig, för om en Power BI-rapport refererar till en rad med RLS konfigurerat visas samma meddelande som för ett borttaget eller icke-befintligt fält. För dessa användare ser det ut som att rapporten är bruten.

Det finns två steg för att konfigurera RLS: regler och rollmappningar.

RLS-regler

För semantiska modeller kan en datamodellerare konfigurera RLS i Power BI Desktop genom att skapa en eller flera roller. En roll har ett unikt namn i modellen och innehåller vanligtvis en eller flera regler. Regler tillämpar filter på modelltabeller med hjälp av DAX-filteruttryck (Data Analysis Expressions). Som standard har en modell inga roller.

Viktigt!

En modell utan roller innebär att användare (som har behörighet att fråga datamodellen) har åtkomst till alla modelldata.

Regeluttryck utvärderas i radkontext. Radkontext innebär att uttrycket utvärderas för varje rad med hjälp av kolumnvärdena för den raden. När uttrycket returnerar TRUEkan användaren se raden. Du kan definiera regler som antingen är statiska eller dynamiska.

• Statiska regler: Använd DAX-uttryck som refererar till konstanter, till exempel [Region] = "Midwest".
• Dynamiska regler: Använd specifika DAX-funktioner som returnerar miljövärden (i stället för konstanter). Miljövärden returneras från tre specifika DAX-funktioner: USERNAME, USERPRINCIPALNAME och CUSTOMDATA. Det är enkelt och effektivt att definiera dynamiska regler när en modelltabell lagrar användarnamnsvärden. De gör att du kan framtvinga en datadriven RLS-design.

RLS-rollmappningar

När du har publicerat modellen till Power BI-tjänst måste du konfigurera rollmappningar innan användare får åtkomst till relaterade rapporter. Rollmappning omfattar tilldelning av Microsoft Entra-säkerhetsobjekt till roller. Säkerhetsobjekt kan vara användarkonton eller säkerhetsgrupper.

När det är möjligt är det bästa praxis att mappa roller till säkerhetsgrupper. På så sätt blir det färre mappningar och gruppmedlemskapshantering kan hanteras av gruppens ägare.

Vi rekommenderar att du gör säkerhetskontoinformation från Microsoft Entra tillgänglig för dina innehållsskapare. Ett alternativ är att skapa ett dataflöde med data som hålls synkroniserade med Microsoft Entra-ID. På så sätt kan innehållsskapare integrera dataflödesdata för att skapa en datadriven semantisk modell.

Dricks

Det går att definiera en roll som inte har några regler. I det här fallet ger rollen åtkomst till alla rader i alla modelltabeller. Det är lämpligt att konfigurera den här typen av roll när en administratör eller användare får visa alla data i modellen.

RLS-användarupplevelse

Vissa organisationer väljer att målmedvetet använda RLS som ett sekundärt säkerhetslager, utöver standardbehörigheter för Power BI. Tänk på följande scenario: Du delar en länk till en rapport med hela organisationen. Alla användare som visar rapporten måste mappas till en RLS-roll för att kunna se data i rapporten. Om de inte mappas till en RLS-roll ser de inga data.

Förekomsten av RLS ändrar standardupplevelsen för konsumenter.

• När RLS inte har definierats för den semantiska modellen: Skapare och konsumenter med minst läsbehörighet för semantikmodellen kan visa alla data i den semantiska modellen.
• När RLS definieras på den semantiska modellen: Skapare och konsumenter med endast läsbehörighet för den semantiska modellen kan bara visa de data som de får se (baserat på deras RLS-rollmappning).

Kommentar

Vissa organisationer tillämpar RLS som ett extra säkerhetslager, särskilt när känsliga data är inblandade. Därför kan du välja att kräva RLS för semantiska modeller som är certifierade. Detta krav kan uppnås med en intern gransknings- och godkännandeprocess innan den semantiska modellen certifieras.

När en användare visar en rapport i antingen en arbetsyta eller en app kanske RLS tillämpas eller inte beroende på deras semantiska modellbehörigheter. Därför är det viktigt att innehållskonsumenter och innehållsskapare bara har läsbehörighet för den underliggande semantiska modellen när RLS måste tillämpas.

Här är de behörighetsregler som avgör om RLS tillämpas.

• Användaren har läsbehörighet för den semantiska modellen: RLS tillämpas för användaren.
• Användaren har läs- och byggbehörighet för den semantiska modellen: RLS tillämpas för användaren.
• Användaren har skrivbehörighet för den semantiska modellen: RLS tillämpas inte för användaren, vilket innebär att de kan se alla data i semantikmodellen. Med skrivbehörigheten kan du redigera en semantisk modell. Det kan beviljas på något av två sätt:
  • Med rollerna Deltagare, Medlem eller Administratör (för arbetsytan där semantikmodellen lagras).
  • Med behörigheten Skriv semantisk modell per objekt.

Dricks

Mer information om hur du använder separata arbetsytor så att RLS fungerar för innehållsskapare finns i scenariot för hanterad bi-användning med självbetjäning .

Mer information om RLS finns i Begränsa åtkomsten till Power BI-modelldata.

RLS för datamarter

Power BI-datamarter kan också framtvinga RLS. Implementeringen är dock annorlunda.

Den största skillnaden är att RLS för datamarter har konfigurerats i Power BI-tjänst i stället för i Power BI Desktop.

En annan skillnad är att datamarts framtvingar RLS på både den semantiska modellen och den hanterade Azure SQL Database som är associerad med datamarten. Att framtvinga RLS i båda lagren ger konsekvens och flexibilitet. Samma RLS-filter tillämpas oavsett hur användaren frågar efter data, oavsett om det är genom att ansluta till den semantiska modellen eller till den hanterade Azure SQL Database.

Mer information finns i RLS för datamarter.

Säkerhet på objektnivå

Med säkerhet på objektnivå (OLS) kan en datamodellerare begränsa åtkomsten till specifika tabeller och kolumner samt deras metadata. Du använder vanligtvis OLS för att säkerställa att känsliga kolumner, till exempel lön för anställda, inte är synliga för vissa användare. Det går inte att begränsa åtkomsten till mått, men alla mått som refererar till en begränsad kolumn begränsas.

Överväg ett exempel på en tabell med anställda. Den innehåller kolumner som lagrar medarbetarens namn och telefonnummer samt lön. Du kan använda OLS för att se till att endast vissa användare, till exempel personalavdelningen, kan se lönevärden. För de användare som inte kan se lönevärden är det som om kolumnen inte finns.

Var försiktig, för om ett visuellt Power BI-rapportobjekt innehåller lön får användare som inte har åtkomst till det fältet ett felmeddelande. Meddelandet informerar dem om att objektet inte finns. För dessa användare ser det ut som att rapporten är bruten.

Kommentar

Du kan också definiera perspektiv i en datamodell. Ett perspektiv definierar visningsbara delmängder av modellobjekt för att ge rapportskapare ett specifikt fokus. Perspektiv är inte avsedda att begränsa åtkomsten till modellobjekt. En användare kan fortfarande köra frågor mot en tabell eller kolumn även om den inte är synlig för dem. Därför bör du betrakta perspektiv som en användar bekvämlighet snarare än en säkerhetsfunktion.

Det finns för närvarande inget gränssnitt i Power BI Desktop för att konfigurera OLS. Du kan använda Tabellredigeraren, som är ett verktyg från tredje part för att skapa, underhålla och hantera modeller. Mer information finns i användningsscenariot för hantering av avancerade datamodeller.

Mer information om OLS finns i Begränsa åtkomsten till Power BI-modellobjekt.

Checklista – När du planerar för RLS och OLS är viktiga beslut och åtgärder:

• Besluta om strategin för användning av RLS: Överväg för vilka användningsfall och syften du tänker använda säkerhet på radnivå.
• Besluta om strategin för användning av OLS: Överväg för vilka användningsfall och syften du tänker använda säkerhet på objektnivå.
• Överväg krav för certifierat innehåll: Om du har en process för vad som krävs för att certifiera en semantisk modell ska du bestämma om du vill inkludera några specifika krav för att använda RLS eller OLS.
• Skapa och publicera användarvägledning: Skapa dokumentation för användare som innehåller krav och inställningar för användning av RLS och OLS. Beskriv hur du hämtar information om användarmappning om den finns på en central plats.
• Uppdatera utbildningsmaterial: Inkludera viktig information om krav och inställningar för RLS och OLS i användarutbildningsmaterial. Ge exempel för användare att förstå när det är lämpligt att använda någon av datasäkerhetsteknikerna.

Relaterat innehåll

I nästa artikel i den här serien får du lära dig mer om säkerhetsplanering för innehållsskapare som ansvarar för att skapa semantiska modeller, dataflöden, datamarter, rapporter eller instrumentpaneler.