Planering av Power BI-implementering: Granskning på klientorganisationsnivå

Den här artikeln om granskningsplanering på klientorganisationsnivå riktar sig främst till:

• Power BI-administratörer: De administratörer som ansvarar för att övervaka Power BI i organisationen. Power BI-administratörer kan behöva samarbeta med IT, säkerhet, intern granskning och andra relevanta team.
• 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 och andra relevanta team.

Syftet med en granskningslösning på klientorganisationsnivå är att samla in och analysera data för alla användare, aktiviteter och lösningar som distribuerats till en Power BI-klientorganisation. Dessa granskningsdata på klientorganisationsnivå är värdefulla för många ändamål, så att du kan analysera implementeringsinsatser, förstå användningsmönster, utbilda användare, stödja användare, minska risker, förbättra efterlevnaden, hantera licenskostnader och övervaka prestanda.

Att skapa en slutpunkt-till-slutpunkt-granskningslösning som är säker och produktionsklar är ett viktigt projekt som tar tid. Tänk på det som att skapa business intelligence på Business Intelligence (BI på BI). Information om varför granskningsdata är så värdefulla finns i Översikt över granskning och övervakning.

För granskning på rapportnivå, som riktar sig till rapportskapare, se Granskning på rapportnivå.

Information om hur du granskar datatillgångar, som riktar sig till dataskapare, finns i Granskning på datanivå.

Resten av den här artikeln fokuserar på granskning på klientorganisationsnivå.

När du planerar att skapa en granskningslösning på klientorganisationsnivå planerar du att ägna tid åt följande fyra faser.

• Fas 1: Planering och beslut
  • Krav och prioriteringar
  • Databehov
  • Typ av granskningslösning
  • Behörigheter och ansvarsområden
  • Tekniska beslut
  • Beslut om datakälla
• Fas 2: Förutsättningar och installation
  • Skapa lagringskonto
  • Installera programvara och konfigurera tjänster
  • Registrera ett Microsoft Entra-program
  • Ange inställningar för Power BI-klientorganisationen
• Fas 3: Utveckling och analys av lösningar
  • Extrahera och lagra rådata
  • Skapa de kurerade data
  • Skapa en datamodell
  • Förbättra datamodellen
  • Skapa analysrapporter
  • Vidta åtgärder baserat på data
• Fas 4: Underhålla, förbättra och övervaka
  • Operationalisera och förbättra
  • Dokumentation och support
  • Aktivera aviseringar
  • Löpande hantering

Fas 1: Planering och beslut

Den första fasen fokuserar på planering och beslutsfattande. Det finns många krav och prioriteringar att tänka på, så vi rekommenderar att du ägnar tillräckligt med tid åt att förstå de ämnen som beskrivs i det här avsnittet. Målet är att fatta bra beslut i förväg så att nedströmsfaserna går smidigt.

Krav och prioriteringar

I den inledande fasen är målet att identifiera vad som är viktigast. Fokusera på det som är viktigast och hur du ska mäta påverkan i din organisation. Sträva efter att definiera affärsorienterade krav snarare än teknikorienterade krav.

Här följer några frågor som du bör besvara.

• Vilka viktiga frågor behöver du besvara? Det finns en stor mängd granskningsdata som du kan utforska. Det mest effektiva sättet att hantera granskning är att fokusera på att besvara specifika frågor.
• Vilka är dina mål för implementering och datakultur ? Du kanske till exempel har ett mål att öka antalet BI-innehållsskapare med självbetjäning i organisationen. I så fall måste du mäta användaraktiviteter relaterade till att skapa, redigera och publicera innehåll.
• Vilka omedelbara risker finns det? Du kanske till exempel vet att överdelning av innehåll har inträffat tidigare. Användarutbildningen har sedan dess förbättrats och du vill nu granska säkerhetsinställningar och aktiviteter kontinuerligt.
• Finns det aktuella nyckeltal (KPI:er) eller organisationsmål? Du kanske till exempel har en organisations-KPI som relaterar till digital omvandling eller blir en mer datadriven organisation. Granskningsdata på klientnivå kan hjälpa dig att mäta om din Power BI-implementering är i linje med dessa mål.

Mer information om hur du kan använda granskningsdata finns i Översikt över granskning och övervakning.

Checklista – När du identifierar krav och prioriteringar omfattar viktiga beslut och åtgärder:

Databehov

När du har definierat kraven och prioriteringarna (beskrivs tidigare) är du redo att identifiera de data som du behöver. Fyra datakategorier beskrivs i det här avsnittet.

• Användaraktivitetsdata
• Klientinventering
• Data om användare och grupper
• Säkerhetsdata

De flesta data som du behöver kommer från administratörs-API :erna, som tillhandahåller en mängd metadata om Power BI-klientorganisationen. Mer information finns i Välj ett användar-API eller administratörs-API senare i den här artikeln.

Användaraktivitetsdata

Gör det till din första prioritet att hämta data om användaraktiviteter. Användaraktiviteterna, som även kallas händelser eller åtgärder, är användbara för en mängd olika syften.

Oftast kallas dessa data för aktivitetsloggen eller händelseloggen. Tekniskt sett finns det flera sätt att hämta användaraktivitetsdata (aktivitetsloggen är en metod). Mer information om de beslut och aktiviteter som berörs finns i Komma åt användaraktivitetsdata senare i den här artikeln.

Här följer några vanliga frågor som användaraktivitetsdata kan besvara.

• Hitta de främsta användarna och det viktigaste innehållet
  • Vilket innehåll visas oftast och av vilka användare?
  • Vilka är de dagliga, veckovisa och månatliga trenderna för att visa innehåll?
  • Trendar rapportvyer uppåt eller nedåt?
  • Hur många användare är aktiva?
• Förstå användarbeteende
  • Vilken typ av säkerhet används oftast (appar, arbetsytor eller delning per objekt)?
  • Använder användare webbläsare eller mobilappar oftast?
  • Vilka innehållsskapare publicerar och uppdaterar innehåll mest aktivt?
  • Vilket innehåll publiceras eller uppdateras, när och av vilka användare?
• Identifiera användarutbildning och utbildningsmöjligheter
  • Vem delar (för mycket) från sin personliga arbetsyta?
  • Vem exporterar en betydande mängd?
  • Vem laddar regelbundet ned innehåll?
  • Vem publicerar många nya semantiska modeller?
  • Vem använder prenumerationer kraftigt?
• Förbättra styrnings- och efterlevnadsarbetet
  • När ändras klientinställningarna och med vilken Power BI-administratör?
  • Vem startade en Power BI-utvärderingsversion?
  • Vilket innehåll används av externa användare, vem, när och hur?
  • Vem har lagt till eller uppdaterat en känslighetsetikett?
  • Vilken procentandel av rapportvyerna baseras på certifierade semantiska modeller?
  • Vilken procentandel av semantiska modeller stöder mer än en rapport?
  • När skapas eller uppdateras en gateway eller datakälla och av vilken användare?

Mer information om hur du använder dessa data finns i Förstå användningsmönster.

Mer information finns i Komma åt användaraktivitetsdata senare i den här artikeln.

Klientinventering

Ofta är den andra prioriteten att hämta data för att skapa en klientinventering. Ibland kallas det för arbetsyteinventering, metadata för arbetsytor eller klientmetadata.

En klientinventering är en ögonblicksbild vid en viss tidpunkt. Den beskriver vad som publiceras i klientorganisationen. Klientinventeringen innehåller inte faktiska data eller faktiska rapporter. I stället är det metadata som beskriver alla arbetsytor och deras objekt (till exempel semantiska modeller och rapporter).

Här följer några vanliga frågor som klientinventeringen kan besvara.

• Förstå hur mycket innehåll du har och var
  • Vilka arbetsytor har mest innehåll?
  • Vilken typ av innehåll publiceras på varje arbetsyta (särskilt när du separerar rapportering av arbetsytor och dataarbetsytor)?
  • Vilka beroenden finns mellan objekt (till exempel dataflöden som stöder många semantiska modeller eller en semantisk modell som är en källa för andra sammansatta modeller)?
  • Vad är data härstamningen (beroenden mellan Power BI-objekt, inklusive externa datakällor)?
  • Finns det överblivna rapporter (som är frånkopplade från sin semantiska modell)?
• Förstå förhållandet mellan semantiska modeller och rapporter
  • Hur mycket återanvändning av semantisk modell sker?
  • Finns det duplicerade, eller mycket lika, semantiska modeller?
  • Finns det möjligheter att konsolidera semantiska modeller?
• Förstå trender mellan tidpunkter
  • Ökar antalet rapporter över tid?
  • Ökar antalet semantiska modeller med tiden?
• Hitta oanvänt innehåll
  • Vilka rapporter är oanvända (eller underutnyttjade)?
  • Vilka semantiska modeller är oanvända (eller underutnyttjade)?
  • Finns det möjligheter att dra tillbaka innehåll?

En klientinventering hjälper dig att använda aktuella namn när du analyserar historiska aktiviteter. Ögonblicksbilden av objekten i klientorganisationen innehåller namnen på alla objekt vid den tidpunkten. Det är bra att använda aktuella objektnamn för historisk rapportering. Om en rapport till exempel bytte namn för tre månader sedan registrerar aktivitetsloggen då det gamla rapportnamnet. Med en korrekt definierad datamodell kan du använda den senaste klientinventeringen för att hitta ett objekt med dess aktuella namn (i stället för dess tidigare namn). Mer information finns i Skapa en datamodell senare i den här artikeln.

Mer information om hur du använder en klientinventering finns i Förstå publicerat innehåll.

Eftersom en klientinventering är en ögonblicksbild vid en viss tidpunkt måste du bestämma hur ofta metadata ska extraheras och lagras. En veckovis ögonblicksbild är användbar för att göra jämförelser mellan de två tidpunkterna. Om du till exempel vill undersöka säkerhetsinställningar för en arbetsyta behöver du den tidigare ögonblicksbilden av klientinventering, aktivitetslogghändelserna och den aktuella ögonblicksbilden av klientinventering.

Det finns två huvudsakliga sätt att skapa en klientinventering. Mer information om de beslut och aktiviteter som berörs finns i Åtkomst till klientinventeringsdata senare i den här artikeln.

Data om användare och grupper

När dina analytiska behov växer kommer du förmodligen att avgöra att du vill inkludera data om användare och grupper i din slutpunkt-till-slutpunkt-granskningslösning. Om du vill hämta dessa data kan du använda Microsoft Graph, som är den auktoritativa källan för information om Microsoft Entra ID-användare och -grupper.

Data som hämtas från Power BI REST-API:er innehåller en e-postadress för att beskriva användaren eller namnet på en säkerhetsgrupp. Dessa data är en ögonblicksbild vid en viss tidpunkt.

Här följer några vanliga frågor som Microsoft Graph kan besvara.

• Identifiera användare och grupper
  • Vad är det fullständiga användarnamnet (utöver e-postadressen), avdelningen eller platsen som hämtas från användarprofilen?
  • Vilka är medlemmar i en säkerhetsgrupp?
  • Vem är ägare till en säkerhetsgrupp (för att hantera medlemmar)?
• Hämta ytterligare användarinformation
  • Vilka licenser – Power BI Pro eller Power BI Premium per användare (PPU) – tilldelas till användare?
  • Vilka användare loggar in oftast?
  • Vilka användare har inte loggat in på Power BI-tjänst nyligen?

Mer information och rekommendationer om hur du kommer åt data från Microsoft Graph finns i Komma åt användar- och gruppdata senare i den här artikeln.

Säkerhetsdata

Du kan ha ett krav på att utföra regelbundna säkerhetsgranskningar.

Här följer några vanliga frågor som Power BI REST API:er kan besvara.

• Identifiera personer och program
  • Vilka rapporter har en användare, grupp eller tjänstens huvudnamn åtkomst till?
  • Vilka användare, grupper eller tjänstens huvudnamn är prenumeranter för att ta emot rapporter med en e-postprenumeration?
• Förstå innehållsbehörigheter
  • Vilka arbetsyteroller tilldelas till vilka användare och grupper?
  • Vilka användare och grupper tilldelas till varje Power BI-apppublik?
  • Vilka behörigheter per objekt tilldelas, för vilka rapporter och för vilka användare?
  • Vilka behörigheter per objekt tilldelas, för vilka semantiska modeller och för vilka användare?
  • Vilka semantiska modeller och datamarter har säkerhet på radnivå (RLS) definierat?
  • Vilka objekt delas till personer i hela organisationen?
  • Vilka objekt publiceras offentligt på Internet?
• Förstå andra behörigheter
  • Vem har behörighet att publicera med hjälp av en distributionspipeline?
  • Vem har behörighet att hantera gatewayer och dataanslutningar?
  • Vem har behörighet att hantera en Premium-kapacitet?

De här vanliga frågorna är inte en fullständig lista. Det finns en mängd olika Power BI REST-API:er tillgängliga. Mer information finns i Använda Power BI REST-API:er.

Mer information om hur du använder administratörs-API:er jämfört med användar-API:er (inklusive hur det påverkar behörigheter som krävs för den användare som extraherar data) finns i Välj ett användar-API eller administratörs-API senare i den här artikeln.

Checklista – När du identifierar de data som behövs för granskning är viktiga beslut och åtgärder:

Typ av granskningslösning

Granskning på klientorganisationsnivå görs antingen manuellt eller med automatiserade processer.

De flesta nya granskningsprocesser börjar som en manuell process, särskilt under utveckling och under testning. En manuell granskningsprocess kan utvecklas till en automatiserad process. Alla granskningsprocesser behöver dock inte vara helt automatiserade.

Manuella granskningsprocesser

Manuell granskning förlitar sig på skript och processer som körs på begäran av en användare (vanligtvis en Power BI-administratör). Vid behov kör användaren frågor interaktivt för att hämta granskningsdata.

Manuell granskning passar bäst för:

• Nya skript som utvecklas och testas.
• Tillfälliga, engångsgranskningsbehov.
• Undersökande granskningsbehov.
• Nonessential auditing-processer som inte kräver fullständigt stöd.

Automatiserade granskningsprocesser

Granskning av data som behövs regelbundet bör automatiseras. Den extraheras och bearbetas enligt ett regelbundet schema och kallas för en automatiserad process. Ibland kallas det för en obevakad process.

Målet med en automatiserad process är att minska den manuella ansträngningen, minska risken för fel, öka konsekvensen och eliminera beroendet av en enskild användare för att köra den.

Automatiserad granskning passar bäst för:

• Granskningsprocesser som körs i produktion.
• Obevakade processer som körs enligt ett regelbundet schema.
• Skript som har testats fullständigt.
• Viktiga granskningsprocesser som har andra rapporter (eller andra processer) som är beroende av den som datakälla.
• Granskningsprocesser som dokumenteras och stöds.

Typen av process – manuell eller automatiserad – kan påverka hur du hanterar autentisering. En Power BI-administratör kan till exempel använda användarautentisering för en manuell granskningsprocess men använda tjänstens huvudnamn för en automatiserad process. Mer information finns i Fastställa autentiseringsmetoden senare i den här artikeln.

Checklista – När du överväger vilken typ av granskningslösning som ska utvecklas, omfattar viktiga beslut och åtgärder:

Behörigheter och ansvarsområden

Nu bör du ha en tydlig uppfattning om vad du vill åstadkomma och de data som du först behöver. Nu är det dags att fatta beslut om användarbehörigheter samt roller och ansvarsområden.

Användarbehörigheter

När du planerar att skapa en slutpunkt-till-slutpunkt-granskningslösning bör du överväga användarbehörigheter för andra användare som behöver komma åt data. Mer specifikt bestämmer du vem som ska tillåtas att komma åt och visa granskningsdata.

Här följer några saker att tänka på.

Direkt åtkomst till granskningsdata

Du bör bestämma vem som kan komma åt granskningsdata direkt. Det finns flera sätt att tänka på det.

• Vem ska vara Power BI-administratör? En Power BI-administratör har åtkomst till alla klientmetadata, inklusive administratörs-API :er. Mer information om hur du bestämmer vem som ska vara Power BI-administratör finns i Säkerhetsplanering på klientorganisationsnivå.
• Vem kan använda ett befintligt huvudnamn för tjänsten? Om du vill använda tjänstens huvudnamn (i stället för användarbehörigheter) för åtkomst till granskningsdata måste en hemlighet tillhandahållas behöriga användare så att de kan utföra lösenordsbaserad autentisering. Åtkomsten till hemligheter (och nycklar) bör kontrolleras mycket noggrant.
• Måste åtkomsten kontrolleras noggrant? Vissa branscher med regel- och efterlevnadskrav måste kontrollera åtkomsten hårdare än andra branscher.
• Finns det stora aktivitetsdatavolymer? För att undvika att nå API-begränsningsgränser kan du behöva kontrollera vem som har rätt att komma åt API:erna direkt som producerar granskningsdata. I det här fallet är det bra att se till att det inte finns duplicerade eller överlappande åtgärder.

Åtkomst till extraherade rådata

Du bör bestämma vem som ska kunna visa rådata som extraheras och skrivs till en lagringsplats. Oftast är åtkomsten till rådata begränsad till administratörer och granskare. Center of Excellence (COE) kan också kräva åtkomst. Mer information finns i Fastställa var granskningsdata ska lagras senare i den här artikeln.

Åtkomst till kurerade analysdata

Du bör bestämma vem som ska kunna visa de utvalda och transformerade data som är redo för analys. Dessa data bör alltid göras tillgängliga för administratörer och granskare. Ibland görs en datamodell tillgänglig för andra användare i organisationen, särskilt när du skapar en Power BI-semantisk modell med säkerhet på radnivå. Mer information finns i Planera för att skapa kurerade data senare i den här artikeln.

Roller och ansvar

När du har bestämt hur användarbehörigheter ska fungera kan du börja tänka på roller och ansvarsområden. Vi rekommenderar att du engagerar rätt personer tidigt, särskilt när flera utvecklare eller team kommer att vara involverade i att skapa granskningslösningen från slutpunkt till slutpunkt.

Bestäm vilka användare eller team som ska ansvara för följande aktiviteter.

Roll	Typer av ansvarsområden	Rollen utförs vanligtvis av
Kommunicera med intressenter	Kommunikationsaktiviteter och kravinsamling.	COE i samarbete med IT. Kan också inkludera utvalda personer från viktiga affärsenheter.
Bestäm prioriteringar och ge vägledning om krav	Beslutsaktiviteter relaterade till slutpunkt-till-slutpunkt-granskningslösningen, inklusive hur du uppfyller kraven.	Teamet som övervakar Power BI i organisationen, till exempel COE. Den verkställande sponsorn eller en styrkommitté för datastyrning kan bli involverad för att fatta kritiska beslut eller eskalera frågor.
Extrahera och lagra rådata	Skapa skript och processer för att komma åt och extrahera data. Det handlar också om att skriva rådata till lagring.	Datateknikpersonal, vanligtvis inom IT och i samarbete med COE.
Skapa de kurerade data	Datarensning, transformering och skapande av kurerade data i star-schemadesign.	Datateknikpersonal, vanligtvis inom IT och i samarbete med COE.
Skapa en datamodell	Skapa en analysdatamodell baserat på de kurerade data.	Power BI-innehållsskapare, vanligtvis i IT eller COE.
Skapa analysrapporter	Skapa rapporter för att analysera de granskade data. Pågående ändringar av rapporter baserat på nya krav och när nya granskningsdata blir tillgängliga.	Power BI-rapportskapare, vanligtvis i IT eller COE.
Analysera data och agera på resultaten	Analysera data och agera som svar på granskningsdata.	Teamet som övervakar Power BI i organisationen, vanligtvis COE. Kan även omfatta andra team beroende på granskningsresultat och åtgärd. Andra team kan vara säkerhet, efterlevnad, juridik, riskhantering eller ändringshantering.
Testa och verifiera	Testa för att säkerställa att granskningskraven uppfylls och att de data som presenteras är korrekta.	Power BI-innehållsskapare, i samarbete med teamet som övervakar Power BI i organisationen.
Skydda data	Ange och hantera säkerhet för varje lagringslager, inklusive rådata och kurerade data. Hantera åtkomst till semantiska modeller som skapas för att analysera data.	Systemadministratör för systemet som lagrar data i samarbete med teamet som övervakar Power BI i organisationen.
Schemaläggning och automatisering	Operationalisera en lösning och schemalägg processen med valfritt verktyg.	Datateknikpersonal, vanligtvis inom IT och i samarbete med COE.
Stöd för lösningen	Övervaka granskningslösningen, inklusive jobbkörningar, fel och support för tekniska problem.	Teamet som hanterar Power BI-systemstöd, vilket vanligtvis är IT eller COE.

Många av ovanstående roller och ansvarsområden kan konsolideras om de ska utföras av samma team eller samma person. Dina Power BI-administratörer kan till exempel utföra några av dessa roller.

Det är också möjligt att olika personer utför olika roller, beroende på omständigheterna. Åtgärderna kommer att vara kontextuella beroende på granskningsdata och den föreslagna åtgärden.

Överväg flera exempel.

• Exempel 1: Granskningsdata visar att vissa användare ofta exporterar data till Excel. Åtgärd: COE kontaktar de specifika användarna för att förstå deras behov och för att lära dem bättre alternativ.
• Exempel 2: Granskningsdata visar att extern användaråtkomst sker på ett oväntat sätt. Åtgärder som vidtas: En IT-systemadministratör uppdaterar relevanta Microsoft Entra-ID-inställningar för extern användaråtkomst. Power BI-administratören uppdaterar klientinställningen som är relaterad till extern användaråtkomst. COE uppdaterar dokumentationen och utbildningen för innehållsskapare som hanterar säkerhet. Mer information finns i Strategi för externa användare.
• Exempel 3: Granskningsdata visar att flera datamodeller definierar samma mått på olika sätt (tillgängliga från API:erna för metadatagenomsökning, om det tillåts av de detaljerade klientinställningarna för metadata). Åtgärd: Datastyrningskommittén startar ett projekt för att definiera gemensamma definitioner. COE uppdaterar dokumentationen och utbildningen för innehållsskapare som skapar datamodeller. COE fungerar också med innehållsskapare för att uppdatera sina modeller efter behov. Mer information om hur du hämtar detaljerade metadata finns i Åtkomst till klientinventeringsdata senare i den här artikeln.

Checklista – När du överväger behörigheter och ansvarsområden omfattar viktiga beslut och åtgärder:

Tekniska beslut

När du planerar för en granskningslösning på klientorganisationsnivå måste du fatta några viktiga tekniska beslut. För att förbättra konsekvensen, undvika omarbetning och förbättra säkerheten rekommenderar vi att du fattar dessa beslut så tidigt som möjligt.

I den första planeringsfasen ingår att fatta följande beslut.

• Välj en teknik för att komma åt granskningsdata
• Fastställa autentiseringsmetoden
• Välj ett användar-API eller ett administratörs-API
• Välj API:er eller PowerShell-cmdletar
• Ta reda på var granskningsdata ska lagras
• Planera för att skapa kurerade data

Välj en teknik för att komma åt granskningsdata

Det första du behöver bestämma är hur du ska komma åt granskningsdata.

Det enklaste sättet att komma igång är att använda de färdiga rapporterna som är tillgängliga på arbetsytan för administratörsövervakning.

När du behöver komma åt data direkt och skapa en egen lösning använder du ett API (programgränssnitt). API:er är utformade för att utbyta data via Internet. Power BI REST-API:erna stöder begäranden om data med hjälp av HTTP-protokollet. Valfritt språk eller verktyg kan anropa Power BI REST-API:er när det kan skicka en HTTP-begäran och ta emot ett JSON-svar.

Det här avsnittet fokuserar på ditt teknikval. Mer information om källan för åtkomst till specifika typer av granskningsdata finns i Beslut om datakälla senare i den här artikeln.

Plattformsalternativ

Det finns många olika sätt att komma åt granskningsdata. Beroende på vilken teknik du väljer kan du luta dig mot ett föredraget språk. Du kan också behöva fatta ett specifikt beslut om hur du schemalägger körningen av skripten. Teknikerna skiljer sig mycket åt i inlärningskurvan och hur enkelt det är att komma igång.

Här följer några tekniker som du kan använda för att hämta data med hjälp av Power BI REST API:er.

Teknik	Bra val för manuella granskningsprocesser	Bra val för automatiserade granskningsprocesser
Arbetsyta för administratörsövervakning
Prova
PowerShell
Power BI Desktop
Power Automate
Prioriterad Azure-tjänst
Önskat verktyg/språk
Microsoft Purview-granskningsloggsökning
Defender för molnappar
Microsoft Sentinel

Resten av det här avsnittet innehåller en kort introduktion till vart och ett av de alternativ som visas i tabellen.

Arbetsyta för administratörsövervakning

Arbetsytan för administratörsövervakning innehåller fördefinierade rapporter och semantiska modeller i Power BI-tjänst. Det är ett praktiskt sätt för Infrastrukturadministratörer att visa de senaste granskningsdata och hjälpa dem att förstå användaraktiviteter.

Dokumentation om Try-it i API

Try-it är ett interaktivt verktyg som gör att du kan uppleva Power BI REST API direkt i Microsoft-dokumentationen. Det är ett enkelt sätt att utforska API:erna eftersom det inte kräver andra verktyg eller någon konfiguration på datorn.

Du kan använda Try-it för att:

• Skicka en begäran manuellt till ett API för att avgöra om den returnerar den information du vill ha.
• Lär dig hur URL:en skapas innan du skriver ett skript.
• Kontrollera data på ett informellt sätt.

Eftersom det är interaktivt passar Try-it bäst för inlärning, utforskning och nya manuella granskningsprocesser.

PowerShell och Azure Cloud Shell

Du kan skapa och köra PowerShell-skript på flera olika sätt.

Här är flera vanliga alternativ.

• Visual Studio Code: En modern, lätt källkodsredigerare. Det är ett kostnadsfritt verktyg med öppen källkod som stöds på flera plattformar, inklusive Windows, macOS och Linux. Du kan använda Visual Studio Code med många språk, inklusive PowerShell (med hjälp av PowerShell-tillägget).
• Azure Data Studio: Ett verktyg för att skapa skript och notebook-filer. Den bygger på Visual Studio Code. Azure Data Studio är tillgängligt oberoende av varandra eller med SQL Server Management Studio (SSMS). Det finns många tillägg, inklusive ett tillägg för PowerShell.
• Azure Cloud Shell: Ett alternativ till att arbeta med PowerShell lokalt. Du kan komma åt Azure Cloud Shell från en webbläsare.
• Azure Functions: Ett alternativ till att arbeta med PowerShell lokalt. Azure Functions är en Azure-tjänst som gör att du kan skriva och köra kod i en serverlös miljö. PowerShell är ett av flera språk som stöds.

Du kan använda PowerShell på flera olika sätt. Mer information om det här tekniska beslutet finns i Välj API:er eller PowerShell-cmdletar senare i den här artikeln.

Det finns många tillgängliga onlineresurser för att använda PowerShell, och det är ofta möjligt att hitta erfarna utvecklare som kan skapa och hantera PowerShell-lösningar. PowerShell är ett bra alternativ för att skapa både manuella och automatiserade granskningsprocesser.

Power BI Desktop

Eftersom Power BI Desktop kan ansluta till API:er kan du vara frestad att använda det för att skapa din granskningslösning. Det finns dock några betydande nackdelar och komplexitet.

• Ackumulerande historik: Eftersom Power BI-aktivitetsloggen innehåller upp till 30 dagars data kan du skapa hela granskningslösningen genom att samla in en uppsättning filer över tid som lagrar alla historiska händelser. Det är enklare att samla historiska filer med andra verktyg.
• Hantera autentiseringsuppgifter och nycklar på ett säkert sätt: Många lösningar som du hittar online från communitybloggare är inte säkra eftersom de hårdkodar autentiseringsuppgifter och nycklar i klartext i Power Query-frågor. Även om den metoden är enkel rekommenderas den inte eftersom alla som hämtar din Power BI Desktop-fil kan läsa värdena. Du kan inte lagra lösenordet (när du använder användarautentisering) eller hemligheten (när du använder tjänstens huvudnamn) på ett säkert sätt i Power BI Desktop om du inte:
  • Använd en anpassad anslutningsapp som har utvecklats med Power Query SDK. En anpassad anslutningsapp kan till exempel läsa konfidentiella värden från Azure Key Vault eller en annan tjänst som lagrar det krypterade värdet på ett säkert sätt. Det finns också olika alternativ för anpassade anslutningsappar från den globala Power BI-communityn.
  • Använd alternativet ApiKeyName, som fungerar bra i Power BI Desktop. Det går dock inte att lagra nyckelvärdet i Power BI-tjänst.
• Typer av begäranden: Du kan stöta på vissa begränsningar för vad du kan köra i Power BI Desktop. Power Query stöder till exempel inte alla typer av API-begäranden. Till exempel stöds endast GET- och POST-begäranden när du använder funktionen Web.Contents . För granskning skickar du vanligtvis GET-begäranden.
• Möjlighet att uppdatera: Du måste följa specifika Power Query-utvecklingsmönster för att uppdatera en semantisk modell i Power BI-tjänst. Alternativet måste till exempel RelativePath finnas när du använder Web.Contents så att Power BI kan verifiera platsen för en datakälla korrekt utan att generera ett fel i Power BI-tjänst.

I de flesta fall rekommenderar vi att du endast använder Power BI Desktop för två syften. Du bör använda den för att:

• Skapa din datamodell baserat på befintliga kurerade data (i stället för att använda den för att först extrahera granskningsdata).
• Skapa analysrapporter baserat på din datamodell.

Power Automate

Du kan använda Power Automate med Power BI på många sätt. När det gäller granskning kan du använda Power Automate för att skicka begäranden till Power BI REST-API:erna och sedan lagra extraherade data på valfri plats.

Om du vill ha andra idéer om hur du använder Power Automate kan du söka efter Power BI i Power Automate-mallarna.

Prioriterad Azure-tjänst

Det finns flera Azure-tjänster som kan skicka begäranden till Power BI REST-API:erna. Du kan använda din önskade Azure-tjänst, till exempel:

• Azure Functions
• Azure Automation
• Azure Data Factory
• Azure Synapse Analytics

I de flesta fall kan du kombinera en beräkningstjänst som hanterar logiken för dataextrahering med en lagringstjänst som lagrar rådata (och kurerade data, när det är lämpligt). Överväganden för att fatta beslut om teknisk arkitektur beskrivs senare i den här artikeln.

Önskat verktyg och/eller språk

Du kan använda önskat verktyg och önskat språk för att skicka begäranden till Power BI REST-API:erna. Det är en bra metod när ditt team har expertis med ett specifikt verktyg eller språk, till exempel:

• Python
• C# i .NET-ramverket. Du kan också använda Power BI .NET SDK, som fungerar som omslutning ovanpå Power BI REST-API:erna för att förenkla vissa processer och öka produktiviteten.
• JavaScript

Microsoft Purview-granskningssökning

Efterlevnadsportal i Microsoft Purview (tidigare Microsoft 365 Efterlevnadscenter) innehåller ett användargränssnitt som gör att du kan visa och söka i granskningsloggarna. De enhetliga granskningsloggarna omfattar Power BI och alla andra tjänster som stöder microsoft 365-enhetliga granskningsloggar.

Data som samlas in i den enhetliga granskningsloggen är exakt samma data som finns i Power BI-aktivitetsloggen. När du gör en granskningsloggsökning i efterlevnadsportal i Microsoft Purview läggs din begäran till i kön. Det kan ta några minuter (eller längre, beroende på mängden data) för att data ska vara klara.

Här följer några vanliga sätt att använda sökverktyget för granskningsloggar. Du kan:

• Välj Power BI-arbetsbelastningen för att visa händelser för en serie datum.
• Leta efter en eller flera specifika aktiviteter, till exempel:
  • Borttagen Power BI-rapport
  • Administratörsåtkomst till en personlig arbetsyta i Power BI har lagts till
• Visa aktiviteter för en eller flera användare.

För administratörer med tillräcklig behörighet är granskningsloggsökningsverktyget i efterlevnadsportal i Microsoft Purview ett bra alternativ för manuella granskningsprocesser. Mer information finns i efterlevnadsportal i Microsoft Purview senare i den här artikeln.

användargränssnittet för Defender för molnet Apps

Defender för molnet Apps är tillgängligt för administratörer i Microsoft Defender XDR (Microsoft 365-portalen). Den innehåller ett användargränssnitt för att visa och söka efter aktivitetsloggar för olika molntjänster, inklusive Power BI. Den visar samma logghändelser som har sitt ursprung i efterlevnadsportal i Microsoft Purview, förutom andra händelser som användarinloggningsaktivitet från Microsoft Entra-ID.

Granskningslogggränssnittet i Defender för molnet Apps är ett bra alternativ för manuella granskningsprocesser. Mer information finns i Defender för molnet Appar senare i den här artikeln.

Microsoft Sentinel och KQL

Microsoft Sentinel är en Azure-tjänst som gör att du kan samla in, identifiera, undersöka och svara på säkerhetsincidenter och hot. Power BI kan konfigureras i Microsoft Sentinel som en dataanslutning så att granskningsloggar strömmas från Power BI till Microsoft Sentinel Azure Log Analytics (som är en komponent i Azure Monitor-tjänsten ). Du kan använda Kusto-frågespråk (KQL) för att analysera de aktivitetslogghändelser som lagras i Azure Log Analytics.

Att använda KQL för att söka efter data i Azure Monitor är ett bra alternativ för att visa en del av granskningsloggen. Det är också ett bra alternativ för manuella granskningsprocesser. Mer information finns i Microsoft Sentinel senare i den här artikeln.

Plattformsöverväganden

Här följer några överväganden för hur du kan komma åt granskningsdata.

• Implementerar du en manuell eller automatiserad granskningsprocess? Vissa verktyg överensstämmer starkt med manuell bearbetning eller automatiserad bearbetning. En användare kör till exempel alltid Try-it-funktionen interaktivt, så den passar bara för manuella granskningsprocesser.
• Hur ska du autentisera? Alla alternativ stöder inte alla autentiseringsalternativ. Till exempel stöder Try-it-funktionen endast användarautentisering.
• Hur lagrar du autentiseringsuppgifter på ett säkert sätt? Olika tekniker har olika alternativ för att lagra autentiseringsuppgifter. Mer information finns i Fastställa autentiseringsmetoden senare i den här artikeln.
• Vilken teknik är ditt team redan skickligt på? Om det finns ett verktyg som ditt team föredrar och är bekvämt att använda, börja där.
• Vad kan ditt team stödja? Om ett annat team har stöd för den distribuerade lösningen bör du överväga om det teamet har tillräckligt stöd för den. Tänk också på att dina interna team kan stödja utveckling som utförs av konsulter.
• Vilket verktyg har du godkännande att använda? Vissa verktyg och tekniker kan kräva godkännande. Det kan bero på kostnaden. Det kan också bero på IT-säkerhetsprinciper.
• Vad föredrar du för schemaläggning? Vissa tekniker fattar beslutet åt dig. Andra gånger blir det ett annat beslut du måste fatta. Om du till exempel väljer att skriva PowerShell-skript finns det olika sätt att schemalägga körningen av dem. Om du däremot använder en molntjänst som Azure Data Factory är schemaläggning inbyggd.

Vi rekommenderar att du granskar resten av den här artikeln innan du väljer en teknik för att komma åt granskningsdata.

Checklista – När du bestämmer vilken teknik som ska användas för att komma åt granskningsdata omfattar viktiga beslut och åtgärder:

Fastställa autentiseringsmetoden

Hur du planerar att konfigurera autentisering är ett viktigt beslut. Det är ofta en av de svåraste aspekterna när du kommer igång med granskning och övervakning. Du bör noga överväga tillgängliga alternativ för att fatta ett välgrundat beslut.

Alla API:er på Internet kräver inte autentisering. Alla Power BI REST-API:er kräver dock autentisering. När du kommer åt granskningsdata på klientorganisationsnivå hanteras autentiseringsprocessen av Microsofts identitetsplattform. Det är en utveckling av Microsoft Entra-identitetstjänsten som bygger på branschstandardprotokoll.

Innan du hämtar granskningsdata måste du först autentisera, vilket kallas inloggning. Begreppen autentisering och auktorisering är separata, men ändå relaterade. En autentiseringsprocess verifierar identiteten på vem som gör begäran. En auktoriseringsprocess ger (eller nekar) åtkomst till ett system eller en resurs genom att verifiera vad användaren eller tjänstens huvudnamn har behörighet att göra.

När en användare eller tjänstens huvudnamn autentiseras utfärdas en Microsoft Entra-åtkomsttoken till en resursserver, till exempel ett Power BI REST API eller ett Microsoft Graph API. Som standard upphör en åtkomsttoken att gälla efter en timme. En uppdateringstoken kan begäras om det behövs.

Det finns två typer av åtkomsttoken:

• Användartoken: Utfärdas för en användare med en känd identitet.
• Endast apptoken: Utfärdas för ett Microsoft Entra-program (tjänstens huvudnamn).

Mer information finns i Program- och tjänsthuvudnamnsobjekt i Microsoft Entra-ID.

I följande tabell beskrivs de två autentiseringsalternativen.

Typ av autentisering	Beskrivning	Avsedd för	Bra val för manuella granskningsprocesser	Bra val för automatiserade granskningsprocesser
Användarautentisering	Logga in som användare med hjälp av användarens huvudnamn (e-postadress) och ett lösenord.	Tillfällig, interaktiv användning
Tjänstens huvudautentisering	Logga in som tjänstens huvudnamn med hjälp av en hemlighet (nyckel) som tilldelats en appregistrering.	Pågående, schemalagda, obevakade åtgärder

Varje autentiseringsalternativ beskrivs mer detaljerat i följande avsnitt.

Användarautentisering

Användarautentisering är användbart i följande situationer.

• Manuella granskningsprocesser: Du vill köra ett skript med hjälp av dina användarbehörigheter. Behörigheter kan finnas på en av två nivåer, beroende på typen av API-begäran:
  • Administratörsbehörigheter för administratörs-API:er: Du måste använda dina Power BI-administratörsbehörigheter för att skicka en begäran till ett administratörs-API.
  • Användarbehörigheter för användar-API:er: Du måste använda dina Power BI-användarbehörigheter för att skicka en begäran till ett användar-API. Mer information finns i Välj ett användar-API eller administratörs-API.
• Interaktiv inloggning: Du vill logga in interaktivt, vilket kräver att du anger din e-postadress och ditt lösenord. Du måste till exempel logga in interaktivt för att använda Try-it-upplevelsen , som finns i Microsoft API-dokumentationen.
• Spåra vem som har åtkomst till klientmetadata: När enskilda användare och administratörer skickar API-begäranden kanske du vill granska vilka dessa personer är. När du autentiserar med ett huvudnamn för tjänsten (beskrivs härnäst) är användar-ID:t som samlas in av aktivitetsloggen program-ID:t. Om flera administratörer autentiserar med samma tjänsthuvudnamn kan det vara svårt att veta vilken administratör som har åtkomst till data.
• Delat administratörskonto: Vissa IT-team använder ett delat administratörskonto. Beroende på hur det implementeras och kontrolleras kanske det inte är en bästa praxis. I stället för ett delat konto bör du överväga att använda Microsoft Entra Privileged Identity Management (PIM), som kan bevilja tillfälliga och tillfälliga Power BI-administratörsrättigheter för en användare.
• API:er som endast stöder användarautentisering: Ibland kan du behöva använda ett API som inte stöder autentisering av tjänstens huvudnamn. I dokumentationen anger varje API om ett huvudnamn för tjänsten kan anropa det.

Tjänstens huvudautentisering

De flesta organisationer har en Microsoft Entra-klientorganisation, så villkoren appregistrering och tjänstens huvudnamn tenderar att användas omväxlande. När du registrerar en Microsoft Entra-app finns det två komponenter.

• Appregistrering: En appregistrering är globalt unik. Det är den globala definitionen av en registrerad Microsoft Entra-app som kan användas av flera klienter. En appregistrering kallas även för ett klientprogram eller aktören. Termen klientprogram innebär vanligtvis en användardator. Det är dock inte fallet för appregistreringar. I Azure Portal finns Microsoft Entra-program på sidan Appregistreringar i Microsoft Entra-ID.
• Tjänstens huvudnamn: Ett huvudnamn för tjänsten är den lokala representationen av appregistreringen för användning i din specifika klientorganisation. Tjänstens huvudnamn härleds från den registrerade Microsoft Entra-appen. För organisationer med flera Microsoft Entra-klienter kan samma appregistrering refereras av mer än ett huvudnamn för tjänsten. I Azure Portal finns tjänstens huvudnamn på sidan Företagsprogram i Microsoft Entra-ID.

Eftersom tjänstens huvudnamn är den lokala representationen är termen tjänsthuvudnamnsautentisering det vanligaste sättet att referera till inloggningar.

Autentisering med tjänstens huvudnamn är användbart i följande situationer.

• Automatiserade granskningsprocesser: Du vill köra en obevakad process enligt ett schema.
• Du behöver inte logga in på Power BI-tjänst: Du behöver bara ansluta och extrahera data. Tjänstens huvudnamn kan inte logga in på Power BI-tjänst.
• Delad åtkomst till data: Du (personligen) är inte Power BI-administratör, men du har behörighet att använda tjänstens huvudnamn. Tjänstens huvudnamn har behörighet att köra administratörs-API:er för att hämta data på klientorganisationsnivå (eller andra specifika behörigheter).
• Använd av flera administratörer: Du vill tillåta att flera administratörer eller användare använder samma tjänsthuvudnamn.
• Tekniska blockerare: Det finns en teknisk blockerare som förhindrar användning av användarautentisering. Vanliga tekniska blockerare är:
  • Multifaktorautentisering (MFA): Automatiserade granskningsprocesser (som körs obevakad) kan inte autentiseras med hjälp av ett användarkonto när multifaktorautentisering är aktiverat.
  • Synkronisering av lösenordshash: Microsoft Entra-ID kräver synkronisering av lösenordshash för att ett användarkonto ska kunna autentiseras. Ibland kan IT-avdelningen eller ett cybersäkerhetsteam inaktivera den här funktionen.

Syfte och namngivningskonvention för appregistrering

Varje appregistrering bör ha ett tydligt namn som beskriver dess syfte och målgruppen (vem som kan använda appregistreringen).

Överväg att implementera en namngivningskonvention som: <Arbetsbelastning> – <Syfte> – <Målgrupp> – <Objekttyp>

Här är de delar av namngivningskonventionen.

• Arbetsbelastning: Motsvarar vanligtvis en datakälla (till exempel Power BI-data eller Microsoft Graph-data).
• Syfte: Liknar behörighetsnivån (till exempel Läs jämfört med ReadWrite). Enligt beskrivningen nedan hjälper syftet dig att följa principen om minsta behörighet när du skapar separata appregistreringar som bara kan läsa data.
• Målgrupp: Valfritt. Beroende på arbetsbelastning och syfte kan målgruppen bestämma vilka användare som ska använda appregistreringen.
• Objekttyp: EntraApp ingår för tydlighetens skull.

Din namngivningskonvention kan vara mer specifik när du har flera klienter eller flera miljöer (till exempel utveckling och produktion).

I följande tabell visas exempel på appregistreringar som kan användas för att extrahera granskningsdata på klientnivå:

Namn på appregistrering	Syfte	Målgrupp
PowerBIData-Read-AdminAPIs-EntraApp	Extrahera metadata för hela klientorganisationen för granskning och administration av Power BI. Administratörs-API:er är alltid skrivskyddade och kanske inte har behörigheter som beviljats i Microsoft Entra-ID (endast Power BI-klientinställning).	Power BI-administratörer och Center of Excellence
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp	Hantera Power BI-klientorganisationen. Kräver läs-/skrivbehörighet för att skapa eller uppdatera resurser.	Power BI-administratörer och Center of Excellence
GraphData-Read-PowerBIAdministrators-EntraApp	Extrahera användar- och gruppdata för granskning och administration av Power BI. Kräver läsbehörigheter.	Power BI-administratörer och Center of Excellence

Att hantera flera appregistreringar i olika syften innebär mer arbete. Du kan dock dra nytta av flera fördelar.

• Se vad appregistreringen är avsedd att användas för och varför: När du ser klient-ID:t från appregistreringen visas i dina granskningsdata får du en uppfattning om vad den användes till och varför. Det är en stor fördel med att skapa separata appregistreringar (i stället för att bara använda en för alla ändamål).
• Se vem appregistreringen är avsedd att användas av: När du ser klient-ID:t från appregistreringen visas i dina granskningsdata får du en uppfattning om vem som använde den.
• Undvik överetableringsbehörigheter: Du kan följa principen om minsta behörighet genom att tillhandahålla separata appregistreringar till olika uppsättningar personer som har olika behov. Du kan undvika överetableringsbehörigheter med hjälp av en skrivskyddad appregistrering när skrivbehörigheter inte behövs. Du kan till exempel ha några mycket kompatibla självbetjäningsanvändare som vill samla in data om sina semantiska modeller. de behöver åtkomst till ett huvudnamn för tjänsten med läsbehörighet . Det kan finnas satellitmedlemmar i Center of Excellence som arbetar för finansteamet som programmatiskt hanterar semantiska modeller. de behöver åtkomst till ett huvudnamn för tjänsten med skrivbehörighet .
• Vet vem som ska ha hemligheten: Hemligheten för varje appregistrering bör endast delas med de personer som behöver den. När hemligheten roteras (beskrivs senare i det här avsnittet) blir effekten mindre när du använder separata appregistreringar för olika behov. Det är användbart när du behöver rotera hemligheten eftersom en användare lämnar organisationen eller ändrar roller.

Behörigheter för appregistrering

Det finns två huvudsakliga sätt som en appregistrering kan komma åt data och resurser på. Det omfattar behörigheter och medgivande.

• Endast appbehörigheter: Åtkomst och auktorisering hanteras av tjänstens huvudnamn utan en inloggad användare. Den autentiseringsmetoden är användbar för automatiseringsscenarier. När du använder endast appbehörigheter är det viktigt att förstå att behörigheter inte tilldelas i Microsoft Entra-ID. Behörigheter tilldelas i stället på något av två sätt:
  • För att köra administratörs-API:er: Vissa Power BI-klientinställningar tillåter åtkomst till slutpunkterna för administratörs-API:erna (som returnerar granskningsmetadata för hela klientorganisationen). Mer information finns i Ange Power BI-klientinställningar senare i den här artikeln.
  • För att köra användar-API:er: Behörigheter för Power BI-arbetsyta och objekt gäller. Standard power BI-behörigheter styr vilka data som kan returneras till ett huvudnamn för tjänsten när du kör användar-API:er (som returnerar granskningsdata baserat på behörigheter för användaren eller tjänstens huvudnamn som anropar API:et).
• Delegerade behörigheter: Omfångsbaserade behörigheter används. Tjänstens huvudnamn har åtkomst till data för den användare som för närvarande är inloggad. Det innebär att tjänstens huvudnamn inte kan komma åt något utöver vad den inloggade användaren kan komma åt. Tänk på att det här är ett annat begrepp än autentisering endast för användare, som beskrevs tidigare. Eftersom ett anpassat program krävs för att hantera kombinationen av användar- och appbehörigheter korrekt används delegerade behörigheter sällan för granskningsscenarier. Det här konceptet är ofta missförstått, vilket leder till många appregistreringar som är överetablerade med behörigheter.

Mer information finns i Registrera en Microsoft Entra-app senare i den här artikeln.

Appregistreringshemligheter

En appregistrering har ofta en hemlighet tilldelad till sig. Hemligheten används som en nyckel för autentisering och har ett förfallodatum. Därför måste du planera hur du roterar nyckeln regelbundet och hur du kommunicerar den nya nyckeln till behöriga användare.

Du måste också bry dig om var du ska lagra hemligheten på ett säkert sätt. Ett lösenordsvalv för organisationen, till exempel Azure Key Vault, är ett utmärkt val.

Hantera autentiseringsuppgifter på ett säkert sätt

Oavsett om du använder användarautentisering eller autentisering med tjänstens huvudnamn är en av de största utmaningarna hur du på ett säkert sätt hanterar lösenord, hemligheter och nycklar.

Här följer flera säkra metoder som du kan använda för att hantera lösenord, hemligheter och nycklar.

• Integrera med Azure Key Vault eller ett annat system för lösenordsvalv i organisationen när det är möjligt.
• Använd autentiseringsuppgifter och säkra strängar i dina PowerShell-skript. En autentiseringsuppgift fungerar för både användarautentisering och autentisering med tjänstens huvudnamn. Du kan dock inte använda en autentiseringsuppgift när multifaktorautentisering är aktiverat för ett användarkonto.
• Fråga efter ett lösenord i PowerShell-skriptet eller använd interaktiv autentisering med en webbläsare.
• Använd modulen Secret Management för PowerShell som har publicerats av Microsoft. Den kan lagra värden med hjälp av ett lokalt valv. Den kan också integreras med ett fjärranslutet Azure Key Vault, vilket är användbart när det finns flera administratörer i din organisation som arbetar med samma skript.
• Skapa en anpassad anslutningsapp för Power BI Desktop så att den kan hantera autentiseringsuppgifter på ett säkert sätt. Vissa anpassade anslutningsappar är tillgängliga från communitymedlemmar (vanligtvis på GitHub).

Microsofts autentiseringsbibliotek

Stödet för Azure AD Authentication Library (ADAL) upphörde i december 2022. Framöver bör du använda Microsoft Authentication Library (MSAL). Säkerhetsteamet i din organisation bör känna till den här betydande ändringen.

Även om det inte är viktigt för Power BI-proffs att förstå övergången till MSAL på djupet bör du följa följande rekommendationer.

• Använd den senaste versionen av Power BI-hanteringsmodulen när du autentiserar med PowerShell-cmdleten Connect-PowerBIServiceAccount . Den bytte från ADAL till MSAL i version 1.0.946 (26 februari 2021).
• Använd Microsoft Entra V2-slutpunkten när du autentiserar direkt i skriptet. Microsoft Entra V2-slutpunkten använder MSAL, medan Microsoft Entra V1-slutpunkten använder ADAL.
• Avbryt användningen av API:er och moduler som är inaktuella. Mer information finns i Inaktuella API:er och moduler senare i den här artikeln.
• Om du hittar en community-lösning online måste du se till att den använder MSAL för autentisering i stället för ADAL.

Checklista – När du bestämmer hur du ska hantera autentisering är viktiga beslut och åtgärder:

Välj ett användar-API eller ett administratörs-API

När du planerar att hämta granskningsdata är det viktigt att använda rätt typ av API.

Det finns två typer av API:er att tänka på.

• Användar-API:er: Förlita dig på behörigheterna för den inloggade användaren (eller tjänstens huvudnamn) för att skicka begäranden till API:et. Ett sätt att till exempel returnera en lista över semantiska modeller på en arbetsyta är med ett användar-API. Behörighet att läsa semantiska modeller kan beviljas antingen av arbetsyteroll eller per objektbehörighet. Det finns två sätt att köra användar-API:er:
  • Användarautentisering: Den inloggade användaren måste ha behörighet att komma åt arbetsytan eller objektet.
  • Autentisering med tjänstens huvudnamn: Tjänstens huvudnamn måste ha behörighet att komma åt arbetsytan eller objektet.
• Administratörs-API:er: Hämta metadata från klientorganisationen. Det kallas ibland organisationens omfång. Om du till exempel vill returnera en lista över alla semantiska modeller i klientorganisationen använder du ett administratörs-API. Det finns två sätt att köra administratörs-API:er:
  • Användarautentisering: Den inloggade användaren måste vara Power BI-administratör för att kunna köra administratörs-API:er.
  • Autentisering med tjänstens huvudnamn: Tjänstens huvudnamn måste ha behörighet att köra administratörs-API:er (utan att förlita sig på säkerhetsbehörigheter som ett användar-API gör).

Tänk dig ett exempel där du behöver hämta en lista över semantiska modeller. I följande tabell visas sex API-alternativ som du kan använda för att göra det. Fyra alternativ är användar-API:er och två alternativ är administratörs-API:er. Omfånget och antalet objekt som returneras är olika beroende på vilket API du väljer.

API-namn	Typ av API	Definitionsområde	Antal semantiska modeller
Hämta datauppsättning	User	Personlig arbetsyta	En
Hämta datauppsättningar	User	Personlig arbetsyta	Alla
Hämta datauppsättning i grupp	User	En arbetsyta	Ett, förutsatt att den inloggade användaren har behörighet att läsa semantikmodellen
Hämta datauppsättningar i grupp	User	En arbetsyta	Alla, förutsatt att den inloggade användaren har behörighet att läsa varje semantisk modell
Hämta datauppsättningar i grupp som administratör	Administratör	En arbetsyta	Alla
Hämta datauppsättningar som administratör	Administratör	Hela klientorganisationen	Alla

Information om klientinställningar finns i Ange inställningar för Power BI-klientorganisationen senare i den här artikeln.

Checklista – När du väljer om du vill använda ett användar-API eller ett administratörs-API inkluderar viktiga beslut och åtgärder:

Välj API:er eller PowerShell-cmdletar

Ett viktigt beslut att fatta är om du vill använda PowerShell-cmdletar när de är tillgängliga för de specifika data som du vill hämta. Det här beslutet är viktigt om du har bestämt dig för att PowerShell är en av de tekniker som du använder för att komma åt granskningsdata.

PowerShell är en lösning för uppgiftsautomatisering. Termen PowerShell är en kollektiv term som refererar till skriptspråket, ett kommandoradsgränssnittsprogram och ett konfigurationshanteringsramverk. PowerShell Core är den senaste versionen av PowerShell, som körs i Windows, Linux och macOS.

En PowerShell-cmdlet är ett kommando som utför en åtgärd. En PowerShell-modul är ett paket som innehåller PowerShell-medlemmar, till exempel cmdletar, providers, funktioner, arbetsflöden, variabler och alias. Du laddar ned och installerar moduler.

En PowerShell-modul skapar ett abstraktionslager över API:erna. Till exempel hämtar cmdleten Get-PowerBIActivityEvent (eller hämtar) granskningshändelser för en Power BI-klientorganisation. Den här PowerShell-cmdleten hämtar sina data från REST-API:et Hämta aktivitetshändelser . I allmänhet är det enklare att komma igång med hjälp av cmdletarna eftersom det förenklar åtkomsten till de underliggande API:erna.

Endast en delmängd av API:erna är tillgängliga som PowerShell-cmdletar. När du fortsätter att expandera hela granskningslösningen är det troligt att du använder en kombination av cmdletar och API:er. Resten av det här avsnittet hjälper dig att bestämma hur du ska komma åt data.

PowerShell-moduler

Microsoft har publicerat två PowerShell-moduler som innehåller cmdletar relaterade till Power BI. De är Power BI-hanteringsmodulen och Data Gateway-modulen. Dessa PowerShell-moduler fungerar som en API-omslutning ovanpå de underliggande Power BI REST-API:erna. Om du använder dessa PowerShell-moduler blir det enklare att skriva skript.

Power BI-hanteringsmodul

Power BI-hanteringsmodulen är en sammanslagningsmodul som innehåller specifika Power BI-moduler för administration, kapaciteter, arbetsytor med mera. Du kan välja att installera sammanslagningsmodulen för att hämta alla moduler, eller så kan du installera specifika moduler. Alla Power BI-hanteringsmoduler stöds i både Windows PowerShell och PowerShell Core.

Här är flera vanliga cmdletar som du kan använda för att hämta granskningsdata.

Hanteringsmodul	Cmdlet	Syfte
Profil	Connect-PowerBIServiceAccount	Autentisera en Power BI-användare eller tjänstens huvudnamn.
Administratör	Get-PowerBIActivityEvent	Visa eller extrahera Power BI-aktivitetslogghändelser för klientorganisationen.
Arbetsytor	Get-PowerBIWorkspace	Kompilera en lista över arbetsytor.
Rapporter	Get-PowerBIReport	Kompilera en lista över rapporter för en arbetsyta eller klientorganisationen.
Data	Get-PowerBIDataset	Kompilera en lista över semantisk modell för en arbetsyta eller klientorganisation.
Profil	Invoke-PowerBIRestMethod	Skicka en REST API-begäran (kommando). Den här cmdleten är ett bra alternativ eftersom den kan anropa någon av Power BI REST-API:erna. Det är också ett bra val när du vill använda den enklare autentiseringsformen med hjälp av cmdleten Connect-PowerBIServiceAccount och kunna anropa ett API som inte har någon motsvarande PowerShell-cmdlet. Mer information finns i Överväganden för att använda PowerShell-cmdletar senare i det här avsnittet.

Du kan ladda ned Power BI-hanteringsmodulen från PowerShell-galleriet. Det enklaste sättet att installera moduler är att använda PowerShellGet.

Vi rekommenderar att du installerar sammanslagningsmodulen för Power BI-hantering. På så sätt är alla cmdletar som du kan behöva tillgängliga. Du behöver minst profilmodulen (för autentisering) och eventuella specifika moduler som innehåller de cmdletar som du vill använda.

Data Gateway-modul

Modulen Data Gateway innehåller cmdletar som hämtar data från en lokal datagateway och dess datakällor. Data Gateway-modulen stöds endast på PowerShell Core. Det stöds inte i Windows PowerShell.

Till skillnad från Power BI-hanteringsmodulen (tidigare beskrivet) innehåller Data Gateway-modulen inga administratörs-cmdletar. Många av cmdletarna (och motsvarande gateway-API:er) kräver att användaren har administratörsbehörighet för gatewayen.

Här är flera cmdletar från Modulen Data Gateway som du kan använda för att hämta granskningsdata.

Cmdlet	Syfte
Connect-DataGatewayServiceAccount	Autentisera en Power BI-användare (kräver vanligtvis att användaren tillhör gatewayadministratörsrollen).
Get-DataGatewayCluster	Kompilera en lista över gatewaykluster.
Get-DataGatewayClusterDataSource	Kompilera en lista över datakällor för ett gatewaykluster.
Get-DataGatewayInstaller	Kontrollera vilka användare som får installera och registrera gatewayer i organisationen.

Du kan ladda ned Data Gateway-modulen från PowerShell-galleriet.

Tekniker för att använda PowerShell

Du kan använda PowerShell på flera olika sätt. Det beslut du fattar är viktigt.

I följande tabell beskrivs tre olika tekniker för att använda PowerShell.

Teknik	Beskrivning	Exempel
Använd PowerShell-cmdletar för att förenkla autentiseringen och för att anropa API:er direkt. Rekommenderad metod	Med den här tekniken finns det en balans mellan enkelhet och flexibilitet. Cmdleten Invoke-PowerBIRestMethod är tillgänglig från Modulen Power BI-hanteringsprofil. Den här cmdleten kallas ofta för en schweizisk armékniv eftersom du kan använda den för att anropa någon av Power BI REST-API:erna. Fördelen med att använda den här tekniken är att du kan förenkla autentiseringen och sedan anropa någon av Power BI REST-API:erna. Vi rekommenderar starkt att du använder den här tekniken.	När du har autentiserat med cmdleten Connect-PowerBIServiceAccount använder du cmdleten Invoke-PowerBIRestMethod för att hämta data från önskat API (till exempel Hämta pipelineanvändare som administratör).
Använd cmdletar från PowerShell så mycket som möjligt, både för autentisering och för att hämta data.	Med den här tekniken används PowerShell i stor utsträckning. PowerShell används för att samordna körningen av skriptet, och PowerShell-moduler används när det är möjligt för åtkomst till data. Detta skapar ett större beroende av PowerShell från flera aspekter.	När du har autentiserat med cmdleten Connect-PowerBIServiceAccount använder du en cmdlet (till exempel Get-PowerBIActivityEvent) för att hämta data.
Använd endast PowerShell för att samordna körningen av processen. PowerShell-moduler används så lite som möjligt.	Med den här tekniken är det mindre beroende av PowerShell som ett verktyg eftersom dess primära användning är att orkestrera anropande API-anrop. Endast en allmän PowerShell-modul används för att komma åt API:er (ingen av modulerna från Power BI-hanteringsmodulerna används).	När du har autentiserat med hjälp av Microsoft Authentication Library (MSAL) anropar du önskat API (till exempel Hämta pipelineanvändare som administratör) med hjälp av den generiska cmdleten Invoke-RestMethod för att hämta data.

I tabellen ovan beskriver den första tekniken en metod som balanserar användarvänlighet med flexibilitet. Den här metoden ger den bästa balansen för de flesta organisationers behov, vilket är anledningen till att det rekommenderas. Vissa organisationer kan ha befintliga IT-principer och personalinställningar som påverkar hur du bestämmer dig för att använda PowerShell.

Tekniska användare (och administratörer) kan använda Power BI-hanteringsmodulerna för att hämta data eller automatisera vissa aspekter av innehållshantering.

• För administratörer: Ange parametern -Scope till Organization för åtkomst till entiteter i hela klientorganisationen (till exempel för att hämta en lista över alla arbetsytor).
• För tekniska användare: Ange parametern -Scope till Individual (eller utelämna parametern) för åtkomst till entiteter som tillhör användaren (till exempel för att hämta en lista över arbetsytor som användaren har behörighet att komma åt).

Tänk dig ett scenario där du behöver hämta en lista över semantiska modeller. Om du väljer att arbeta direkt med API:erna måste du ange vilket API som ska anropas. Men om du väljer att använda cmdleten Get-PowerBIDataset kan du ange parametern -Scope för att hämta en användarspecifik eller klientomfattande lista över semantiska modeller. Vilket val du väljer beror på ditt beslut om hur du ska använda PowerShell (som beskrivs i föregående tabell).

I följande tabell beskrivs hur parametrarna som används i PowerShell-cmdleten översätts till API PowerShell-anropen.

Cmdlet-parametrar	API som cmdleten använder	Typ av API	Definitionsområde	Hämtade objekt
-DatasetID {DatasetID} -Scope Individual	Hämta datauppsättning	User	Personlig arbetsyta	En semantisk modell
-Scope Individual	Hämta datauppsättningar	User	Personlig arbetsyta	Alla semantiska modeller
-DatasetID {DatasetID} -GroupID {WorkspaceID}	Hämta datauppsättning i grupp	User	En arbetsyta	En semantisk modell, förutsatt att den inloggade användaren har behörighet att läsa semantikmodellen
-GroupID {WorkspaceID}	Hämta datauppsättningar i grupp	User	En arbetsyta	Alla semantiska modeller, förutsatt att den inloggade användaren har behörighet att komma åt arbetsytan och läsa semantikmodellen
-GroupID {WorkspaceID} -Scope Organization	Hämta datauppsättningar i grupp som administratör	Administratör	En arbetsyta	Alla semantiska modeller
-Scope Organization	Hämta datauppsättningar som administratör	Administratör	Hela klientorganisationen	Alla semantiska modeller

Överväganden för att använda PowerShell-cmdletar

Power BI PowerShell-cmdletar är enklare att använda eftersom de sammanfattar en del av komplexiteten i REST API-anropen.

Här är några av de sätt som cmdletarna förenklar åtkomsten till granskningsdata på.

• Autentisering: Det enklaste sättet att autentisera i ett PowerShell-skript är att använda cmdleten Connect-PowerBIServiceAccount .
• Enkelhet: Det är enklare att komma igång eftersom det är enkelt att hämta granskningsdata. Tänk på att när du använder cmdleten Get-PowerBIActivityEvent hämtar du en dag med granskningsdata. Men när du anropar REST-API:et hämta aktivitetshändelser direkt hämtar du en timmes granskningsdata. När du använder REST-API:et för att hämta en dag med granskningsdata måste du därför använda en loop för att anropa API:et 24 gånger för att extrahera varje timme på dagen.
• Sidnumrering av stora resultatuppsättningar: Stora resultatuppsättningar hämtas effektivt genom sidnumrering. Sidnumrering innebär att du hämtar ett segment av resultaten i taget. Cmdletarna hanterar sidnumrering automatiskt åt dig. Men när du använder REST-API:erna direkt måste skriptet kontrollera en fortsättningstoken för att avgöra om det kommer några fler resultat. Skriptet bör fortsätta att hämta resultatsegment tills ingen fortsättningstoken tas emot. Ett exempel på hur du använder en fortsättningstoken finns i REST API för aktivitetshändelser.
• Förfallodatum för åtkomsttoken: Vid autentisering returneras en åtkomsttoken. Som standard upphör den att gälla efter en timme. Cmdletarna hanterar förfallodatum för åtkomsttoken åt dig. På så sätt behöver du inte skriva logik för att begära en uppdateringstoken.
• Formatering: Data som returneras av en cmdlet formateras något finare än de data som returneras av REST-API:et. Utdata är mer användarvänliga. För automatiserade granskningsprocesser är det sannolikt inte ett problem. För manuella granskningsprocesser kan dock den snyggare formateringen vara till hjälp.

Överväganden för att använda REST-API:er direkt

Ibland finns det fördelar med att anropa Power BI REST API:er direkt.

• Många fler API:er är tillgängliga: Det finns fler REST-API:er tillgängliga än PowerShell-cmdletar. Men glöm inte flexibiliteten i cmdleten Invoke-PowerBIRestMethod , som du kan använda för att anropa någon av Power BI REST-API:erna.
• Uppdateringsfrekvens: Microsoft uppdaterar REST-API:erna oftare än de uppdaterar PowerShell-modulerna. Om ett nytt attribut till exempel läggs till i api-svaret Hämta datauppsättning kan det ta lite tid innan det blir tillgängligt i resultatet av cmdleten Get-PowerBIDataset .
• Mindre språk-/verktygsberoende: När du använder REST-API:erna direkt (i stället för en cmdlet) behöver du inte använda PowerShell. Eller så kan du välja att endast använda PowerShell för att orkestrera anrop till många API:er i ett skript. Genom att ta bort (eller undvika) eventuella beroenden av PowerShell kan du någon gång i framtiden skriva om logiken på ett annat språk. När it- eller utvecklarteamet har starka inställningar för verktyg och språk kan mindre beroende vara viktigt att ta hänsyn till.

Oavsett vilken metod du väljer att använda kan REST-API:erna ändras över tid. När en teknik utvecklas kan API:er (och PowerShell-moduler) bli inaktuella och ersatta. Därför rekommenderar vi att du avsiktligt skapar skript som är enkla att underhålla och motståndskraftiga mot ändringar.

Checklista – När du väljer om du vill komma åt REST-API:erna direkt eller med hjälp av PowerShell-cmdletar, omfattar viktiga beslut och åtgärder:

Ta reda på var granskningsdata ska lagras

När du planerar att skapa en slutpunkt-till-slutpunkt-granskningslösning måste du bestämma var rådata ska lagras (och de granskade data som beskrivs i nästa avsnitt). Dina beslut om datalagring är relaterade till dina inställningar för hur du hanterar dataintegrering.

När du extraherar rådata för granskning ska du hålla det enkelt. Vi rekommenderar att du inte väljer specifika attribut, utför transformeringar eller använder någon formatering när du först extraherar data. Extrahera i stället alla tillgängliga attribut och lagra data i dess ursprungliga tillstånd.

Här är flera orsaker till varför det är bra att lagra rådata i sitt ursprungliga tillstånd.

• Alla tillgängliga data i historiken: Nya attribut och nya händelsetyper blir tillgängliga över tid. Att lagra alla rådata är ett bra sätt att se till att du alltid har åtkomst till de data som var tillgängliga när du extraherade dem. Även när det tar tid – vilket kan vara veckor eller månader – att inse att nya dataattribut är tillgängliga, är det möjligt att analysera dem historiskt eftersom du har samlat in dem i rådata.
• Motståndskraftig mot ändring: Om rådataformatet ändras påverkas inte processen som extraherar data. Eftersom vissa granskningsdata är tidskänsliga är det viktigt att du utformar en dataextraheringsprocess som inte misslyckas när en ändring sker i källan.
• Roller och ansvarsområden: Olika teammedlemmar (till exempel datatekniker eller infrastrukturadministratörer) kan vara ansvariga för att skapa processerna för att komma åt, extrahera och lagra rådata för granskning. Genom att förenkla dataextraheringsprocessen blir det enklare för flera team att arbeta tillsammans.

Här följer några alternativ för att lagra rådata.

• Datasjö- eller objektlagring: En molntjänst som OneLake som specialiserar sig på att lagra filer i valfri struktur. Det är ett idealiskt val för att lagra rådata för granskning. I en datasjöarkitektur bör rådata lagras i bronsskiktet.
• Filsystem: Ett filsystem (till exempel Windows eller Linux) är ett vanligt val för att lagra rådata för granskning.
• Databas: Det går att lagra JSON-data i en relationsdatabas, till exempel Azure SQL Database. Det är dock mindre vanligt än att lagra data i en datasjö eller ett filsystem. Det beror på att det kan bli svårt och dyrt att fråga och underhålla JSON-data, särskilt när datavolymerna växer.

Överväg ett exempel som omfattar en rådatazon i en datasjö. Zonen har en mapphierarki för lagring av aktivitetsloggdata: Raw > ActivityLog > ÅÅÅÅ MM > . Mapparna partitioneras efter år och månad. En fil som lagras i månadsmappen använder följande format: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. YYYYYMMDD representerar faktiska data och YYYYMMDDTTTT representerar tidsstämpeln för extrahering. Genom att inkludera tidsstämpeln för extrahering kan du avgöra vilken fil som är den senaste (om du behöver extrahera data igen). Om du till exempel extraherar data kl. 09.00 (UTC) den 25 april 2023 för aktivitet den 23 april 2023 blir filnamnet PBIActivityLog-20230523-202305250900.

Vi rekommenderar starkt att du använder en teknik som gör att du kan skriva rådata till oföränderlig lagring. Oföränderlig lagring garanterar att när data skrivs kan de inte skrivas över eller tas bort. Den skillnaden är viktig för granskarna och gör att du kan lita på att rådata är tillförlitliga.

Du måste också överväga hur du på ett säkert sätt lagrar rådata. Vanligtvis kräver mycket få användare åtkomst till rådata. Åtkomst till rådata tillhandahålls vanligtvis på behovsbasis, vanligtvis för datatekniker och systemadministratörer. Dina interna granskare kan också behöva åtkomst. De teammedlemmar som ansvarar för att skapa de kurerade data (beskrivs härnäst) kräver också åtkomst till rådata.

Här följer några överväganden som hjälper dig att välja din rådatalagring.

• Är det en manuell eller automatiserad granskningsprocess? En automatiserad granskningsprocess har vanligtvis strängare krav på hur och var data lagras.
• Är ämnesområdet särskilt känsligt? Beroende på typen av data och hur känslig den är kan din organisation ha ett krav på hur och var de lagras. Power BI-granskningsdata innehåller identifierande användarinformation och IP-adresser, så de bör lagras i ett säkert område.
• Finns det någon önskad lagringsteknik? Det kan finnas en befintlig lagringsteknik som används i organisationen, så det är ett logiskt val.
• Kommer användarna att komma åt lagringen direkt? Säkerhetsmodellen är en viktig faktor. Vanligtvis beviljas mycket få användare åtkomst till rådata. Åtkomst till de granskade data görs vanligtvis tillgänglig för Power BI-innehållsskapare som ansvarar för att skapa den centraliserade datamodellen (den semantiska modell som fungerar som lager för rapportering).
• Har du krav på datahemvist? Vissa organisationer har juridiska eller regelmässiga krav på datahemvist för att lagra data i en specifik dataregion.
• Hur organiseras data? Användning av medaljongarkitekturen är en vanlig metod, särskilt i implementeringar av datasjöar och sjöhus. Målet är att lagra dina data i brons-, silver- och gulddatalager. Bronsskiktet innehåller de ursprungliga rådata. Silverskiktet innehåller verifierade och deduplicerade data som används för transformeringar. Det guldfärgade lagret innehåller de kuraterade, mycket raffinerade data som är redo för analys.

Checklista – När du planerar platsen för att lagra rådata omfattar viktiga beslut och åtgärder:

Planera för att skapa kurerade data

Kuraterade data stöder analys och är utformade för att vara användarvänliga. Du måste fatta några beslut om hur och var kurerade data ska skapas. Den teknik som du väljer att lagra de kurerade data kan vara någon av de tekniker som anges i föregående avsnitt.

Målet med kurerade data är att omvandla data till ett mer användarvänligt format som är optimerat för analys och rapportering. Den utgör datakällan för en Power BI-datamodell, så det innebär att du använder en Power BI-datamodell för att analysera användningen av Power BI i din organisation. Grundläggande vägledning för datamodeller gäller: Du bör använda en star-schemadesign som är optimerad för prestanda och användbarhet.

Du kan välja att skapa kurerade data på olika sätt. Du måste bestämma hur dataintegrering ska göras och hur långt uppströms du ska tillämpa transformeringar som förbereder data för inläsning i ett star-schema.

Datasjö

Du kan använda transformeringar och skapa kurerade datafiler i en datasjö. Du bör använda ett guldlager för kurerade data så att det är logiskt separat från rådata som lagras i bronsskiktet. Om du separerar data i lager blir det också enklare att ange olika behörigheter för användaråtkomst.

Använd en datasjö för att transformera och kurera data när:

• Du förväntar dig att det kommer att finnas flera Power BI-datamodeller som hanterar rapportering (vilket motiverar skapandet av ett mellanliggande silverlager).
• Du måste ha stöd för flera innehållsskapare med självbetjäning som behöver åtkomst till granskningsdata på klientorganisationsnivå.
• Du har befintliga verktyg och processer som du vill använda för att transformera och läsa in data.
• Du vill minimera den dataförberedelse som behöver göras (och eventuellt dupliceras) inom en eller flera Power BI-datamodeller.

Power BI-datamodell

Du kanske kan slutföra allt transformeringsarbete i Power BI. Använd Power Query för att komma åt och transformera data från dess råtillstånd till det kuraterade formatet.

Använd en Power BI-datamodell när:

• Du vill förenkla arkitekturen från slutpunkt till slutpunkt och läsa in datamodellen direkt från rådata. (Inkrementell uppdatering kan bidra till att minska uppdateringsvaraktigheterna.)
• Du föredrar att utföra allt transformeringsarbete när du läser in datamodellen.
• Du förväntar dig att ha en centraliserad datamodell för granskningsdata på klientnivå. Alla rapporter (eller andra datamodeller) kan använda den centraliserade Power BI-semantikmodellen som källa.
• Du vill endast ge användaren åtkomst till den centraliserade Power BI-semantikmodellen (och inte till någon av källdata).

Mer information om vilka dimensionstabeller och faktatabeller du kan inkludera i ditt stjärnschema finns i Skapa en datamodell senare i den här artikeln.

Checklista – När du planerar att skapa kurerade data omfattar viktiga beslut och åtgärder:

Beslut om datakälla

Nu bör du vara tydlig med krav, databehov och behörigheter. Viktiga tekniska beslut har fattats. Nu måste du fatta några beslut om metoden för hur du ska hämta vissa typer av data.

Komma åt användaraktivitetsdata

Power BI-användaraktivitetsdata, som ibland kallas aktivitetsloggar eller granskningsloggar, innehåller en mängd information som hjälper dig att förstå vad som händer i din Power BI-klientorganisation. Mer information om hur du identifierar dina databehov finns i Användaraktivitetsdata tidigare i den här artikeln.

Power BI integrerar sina loggar med den enhetliga granskningsloggen för Microsoft Purview (kallades tidigare microsoft 365 enhetlig granskningslogg). Den här integreringen är en fördel eftersom det innebär att alla tjänster i Microsoft 365 inte behöver implementera sitt eget unika sätt att logga. Som standard är den aktiverad.

Du har flera alternativ för att hämta användaraktivitetsdata.

Teknik	Beskrivning	Standarddagar för tillgänglig historik	Bra val för manuella granskningsprocesser	Bra val för automatiserade granskningsprocesser	Bra val för att konfigurera aviseringar	Bra val att komma igång snabbt
Manuell (användargränssnitt)	Efterlevnadsportal i Microsoft Purview	90
Manuell (användargränssnitt)	Defender för molnappar	30
Programmässig	Power BI-aktivitetslogg (API eller PowerShell-cmdlet)	30
Programmässig	Api för Office 365-hanteringsaktivitet	7
Programmässig	Microsoft Sentinel (Azure Monitor)	30

Resten av det här avsnittet beskriver var och en av de tekniker som presenteras i tabellen.

Efterlevnadsportal i Microsoft Purview

Granskningssökningsverktyget i efterlevnadsportal i Microsoft Purview (kallades tidigare Microsoft 365 Efterlevnadscenter) är en praktisk plats för att visa aktiviteter och aviseringar. Det här verktyget kräver inte att du skapar ett skript för att extrahera och ladda ned data. Du kan välja en Power BI-arbetsbelastning för att visa alla granskningsloggposter under en viss tidsperiod. Du kan också begränsa resultatet genom att välja specifika aktiviteter och användare. En chef ber dig till exempel att ta reda på vem som tog bort en arbetsyta tidigare den dagen så att de snabbt kan kontakta personen för att diskutera situationen.

De senaste 90 dagarnas historik är tillgängliga med Granskning (Standard). Med Granskning (Premium) kan du med långsiktig kvarhållning (valfritt) behålla granskningsloggar längre. Eftersom långsiktig kvarhållning endast gäller för licensierade E5-användare exkluderar den granskningsposter för icke-E5-användare och gästanvändare. Därför rekommenderar vi att du bara förlitar dig på standardhistoriken på 90 dagar för att säkerställa att all aktivitet registreras.

Det finns licenskrav för åtkomst till granskningsloggarna i efterlevnadsportal i Microsoft Purview. Utökade Exchange Online-behörigheter krävs också för att få åtkomst till granskningsloggarna.

Användargränssnittet i efterlevnadsportal i Microsoft Purview är användbart för manuella granskningsprocesser och tillfälliga undersökningar av användaraktiviteter.

Defender för molnappar

Portalen i Defender för molnet Apps är en praktisk plats där du kan visa aktiviteter och aviseringar utan att behöva skapa ett skript för att extrahera och ladda ned data. Du kan också visa data från Power BI-aktivitetsloggen och användarinloggningar.

Defender för molnet Apps innehåller ett användargränssnitt för att visa och söka efter aktivitetsloggar för olika molntjänster, inklusive Power BI. Den visar samma logghändelser som har sitt ursprung i den enhetliga granskningsloggen för Microsoft Purview och innehåller andra händelser som användarinloggningsaktivitet från Microsoft Entra-ID.

Precis som efterlevnadsportal i Microsoft Purview (beskrivs i föregående avsnitt) har Defender för molnet Apps ett sökbart användargränssnitt. Filteralternativen är dock olika. Förutom standardhistoriken för 30 dagar kan du använda Defender för molnet-appar för att visa upp till sex månaders aktivitetslogghistorik (i sju dagars steg).

Det finns licenskrav för åtkomst till Defender för molnet-appar. Separata behörigheter krävs också.

Användargränssnittet i Defender för molnet Apps är användbart för manuella granskningsprocesser och engångsundersökningar av användaraktiviteter.

Power BI-aktivitetslogg

Power BI-aktivitetsloggen kommer från den enhetliga granskningsloggen. Den innehåller endast användaraktiviteter som är relaterade till Power BI-tjänst.

Du har två alternativ för att komma åt Power BI-aktivitetsloggen.

• Anropa REST-API:et hämta aktivitetshändelser med hjälp av det verktyg du väljer.
• Använd PowerShell-cmdleten Get-PowerBIActivityEvent . Den är tillgänglig från power BI-hanteringsadministratörsmodulen.

Information om vilket alternativ du vill använda finns i Välj API:er eller PowerShell-cmdletar tidigare i den här artikeln.

Power BI-aktivitetsloggdata är tillgängliga för alla Infrastrukturadministratörer och Power Platform-administratörer. Data kan nås från den enhetliga granskningsloggen, som är tillgänglig för vissa Exchange Online-roller. Mer information finns i Spåra användaraktiviteter i Power BI.

Vi rekommenderar att du använder Power BI-aktivitetsloggen när din avsikt är att endast hämta Power BI-granskningsloggposter.

Api för Office 365-hanteringsaktivitet

Du kan extrahera data från den enhetliga granskningsloggen för andra tjänster, till exempel SharePoint Online, Teams, Exchange Online, Dynamics 365 och Power BI. När målet är att implementera en gransknings- och övervakningslösning för flera tjänster rekommenderar vi att du använder Office 365 Management Activity API. Eftersom det här API:et returnerar data från många tjänster kallas det unified auditing API (eller den enhetliga granskningsloggen). Det är en av Api:erna för Office 365-hantering.

Innan du skapar en ny lösning rekommenderar vi att du kontaktar IT-avdelningen för att avgöra om befintliga Power BI-granskningsposter är tillgängliga. Det är möjligt att en process redan extraherar och lagrar data. Det är också möjligt att du kan få behörighet att komma åt dessa data i stället för att skapa en ny lösning.

Du kan komma åt data på ett av två sätt.

• Anropa API:et för Hanteringsaktivitet för Office 365 direkt med hjälp av det verktyg du väljer. Som standard returnerar API:et 24 timmars data. Du kan hämta högst sju dagars historik.
• Använd PowerShell-cmdleten Search-UnifiedAuditLog . Det är en Exchange Online PowerShell-cmdlet. Du kan hämta högst 90 dagars historik.

I allmänhet är det svårare att komma igång med Office 365 Management Activity-API:et än att använda Power BI-aktivitetsloggen (beskrivs tidigare). Det beror på att API:et returnerar innehållsblobar och varje innehållsblob innehåller enskilda granskningsposter. För stora organisationer kan det finnas tusentals innehållsblobar per dag. Eftersom kunder och program från tredje part använder det här API:et i hög grad implementerar Microsoft begränsningar för att säkerställa att deras användning av tjänsten inte påverkar andra negativt (kallas det bullriga granneproblemet). Därför kan det vara en utmaning att hämta stora mängder historik i större organisationer. Mer information finns i den här felsökningsartikeln.

Om du vill använda det här API:et måste du autentisera med ett huvudnamn för tjänsten som har beviljats behörighet att hämta data från Office 365 Management Activity API.

Att hämta granskningsdata programmatiskt från Office 365 Management Activity API är ett bra val när IT behöver extrahera och lagra granskningsloggar från olika tjänster (utöver Power BI).

Microsoft Sentinel

Microsoft Sentinel är en Azure-tjänst som gör att du kan samla in, identifiera, undersöka och svara på säkerhetsincidenter och hot. Du kan konfigurera Power BI i Microsoft Sentinel som en dataanslutning. När de är anslutna strömmas granskningsloggar (som innehåller en delmängd data) från Power BI till Azure Log Analytics, vilket är en funktion i Azure Monitor.

Eftersom det är en separat Azure-tjänst måste alla administratörer eller användare som du vill köra Kusto-frågespråk (KQL)-frågor beviljas behörigheter i Azure Log Analytics (Azure Monitor). När de har behörighet kan de köra frågor mot granskningsdata som lagras i tabellen PowerBIActivity . Tänk dock på att du i de flesta fall ger användarna åtkomst till de kuraterade data i guldlagret i stället för rådata i bronslagret.

Du använder KQL för att analysera de aktivitetslogghändelser som lagras i Azure Log Analytics. Om du har SQL-erfarenhet hittar du många likheter med KQL.

Det finns flera sätt att komma åt de händelser som lagras i Azure Log Analytics. Du kan använda:

• Den fördefinierade mallappen Log Analytics för Power BI Semantic Models .
• Power BI Desktop-anslutningsprogram för Azure Data Explorer (Kusto).
• Webbaserad frågeupplevelse i Azure Data Explorer.
• Alla frågeverktyg som kan skicka KQL-frågor.

Den historikperiod som du kan hämta beror på datakvarhållningsprincipen för Azure Log Analytics-arbetsytan. Överväg kostnad och åtkomst till rådata när du bestämmer hur mycket data som ska behållas.

Microsoft Sentinel och Azure Monitor är bra alternativ när IT redan har gjort en investering med Microsoft Sentinel, detaljnivån uppfyller dina behov och aktiviteter som hotidentifiering är en prioritet. Men eftersom Microsoft Sentinel inte samlar in alla Power BI-aktivitetsdata har det inte stöd för att utföra omfattande analys av Användning och implementering av Power BI.

Överväganden för användaraktivitetsdata

Här följer några överväganden som hjälper dig att välja källa för användaraktivitetsdata.

• Kommer det att vara en manuell eller automatiserad granskningsprocess? Alternativen för användargränssnitt fungerar bra för manuella granskningsprocesser och enstaka engångsfrågor, särskilt när du behöver undersöka en viss aktivitet. En automatiserad granskningsprocess som extraherar användaraktivitetsdata enligt ett schema kommer också att vara nödvändig för att stödja historisk dataanalys.
• Hur ofta behöver du användaraktivitetsdata? För automatiserade granskningsprocesser planerar du att extrahera data som är minst en dag före det aktuella datumet med hjälp av Coordinated Universal Time (UTC) i stället för din lokala tid. Om processen till exempel körs på fredag morgon (UTC-tid) bör du extrahera data från onsdag. Det finns flera orsaker till varför du bör extrahera data med en dags svarstid.
  • Dina filer blir enklare att arbeta med när du alltid extraherar hela 24 timmar i taget, vilket undviker deldagsresultat.
  • Du minimerar risken för att vissa granskningshändelser saknas. Vanligtvis kommer granskningshändelser inom 30 minuter. Ibland kan det ta upp till 24 timmar innan vissa händelser tas emot i den enhetliga granskningsloggen.
• Behöver du mer än Power BI-data? Överväg det mest effektiva sättet att komma åt det du behöver.
  • När du bara behöver Power BI-användaraktivitetsdata använder du Power BI-aktivitetsloggen.
  • När du behöver granskningsloggar från flera tjänster använder du OFFICE 365 Management Activity API för att komma åt den enhetliga granskningsloggen.
• Vem kommer att utveckla lösningen? Planera att investera lite tid för att bygga ut lösningen. Det kan ta mycket tid att skapa ett produktionsklart skript.

Checklista – När du planerar att komma åt användaraktivitetsdata omfattar viktiga beslut och åtgärder:

Åtkomst till klientinventeringsdata

En klientinventering är en ovärderlig och nödvändig del av en mogen gransknings- och övervakningslösning. Det hjälper dig att förstå vilka arbetsytor och innehåll (semantiska modeller, rapporter och andra objekt) som finns i Power BI, och det är ett utmärkt komplement till användaraktivitetsdata (beskrivs i föregående avsnitt). Mer information om hur du identifierar dina databehov finns i Klientinventering tidigare i den här artikeln.

Användaraktiviteter (tidigare beskrivna) är granskade händelser. de är en post med åtgärder som en användare vidtog vid ett visst datum och en viss tidpunkt. Klientinventeringen är dock annorlunda. Klientinventeringen är en ögonblicksbild vid en viss tidpunkt. Den beskriver det aktuella tillståndet för alla publicerade objekt i Power BI-tjänst när du extraherade det.

För att kunna analysera vad som händer i Din Power BI-klientorganisation behöver du både användaraktivitetsdata och klientinventeringen. Genom att kombinera dem kan du förstå hur mycket innehåll du har och var det finns. Du kan också hitta oanvänt eller underutnyttjat innehåll (eftersom det inte finns några händelser för det i aktivitetsloggen). Klientinventeringen hjälper dig också att kompilera en lista med aktuella namn för alla objekt, vilket är användbart när objektnamnen ändras.

Mer information om värdet för klientinventeringen finns i Klientinventering tidigare i den här artikeln.

Du kan hämta klientinventeringsdata på två olika sätt.

Teknik	Beskrivning	Passar bäst för	Bra val för manuella granskningsprocesser	Bra val för automatiserade granskningsprocesser
Programmässig	Get Groups as Admin API:et eller PowerShell-cmdleten Get-PowerBIWorkspace kan tillhandahålla en lista över arbetsytor för hela klientorganisationen. Du kan också inkludera enskilda objekt (till exempel semantiska modeller och rapporter) per arbetsyta.	Mindre organisationer eller låg datavolym
Programmässig	En uppsättning asynkrona administratörs-API:er, gemensamt kallade API:er för metadatagenomsökning eller skanner-API:er, kan returnera en lista över arbetsytor och enskilda objekt. Du kan också inkludera detaljerade metadata (t.ex. tabeller, kolumner och måttuttryck).	Organisationer med hög datavolym och/eller behov av att få detaljerade resultat

Resten av det här avsnittet beskriver var och en av de tekniker som presenteras i tabellen.

Cmdlet för grupper av API:er eller arbetsytor

Om du vill hämta en lista över arbetsytor kan du använda någon av flera REST-API:er, till exempel API:et Hämta grupper som administratör (med det verktyg du väljer). Resultatet inkluderar extra metadata, till exempel beskrivningen och om arbetsytan lagras i en Premium-kapacitet.

Get Groups as Admin REST-API:et innehåller den användbara $expand parametern. Med den här parametern kan du expandera resultaten så att de innehåller en lista över objekt som publicerats till arbetsytan (till exempel semantiska modeller och rapporter). Du kan också skicka users datatypen till parametern $expand för att inkludera de användare som har tilldelats en arbetsyteroll.

Du kan också använda PowerShell-cmdleten Get-PowerBIWorkspace . Den kommer från modulen Power BI-hanteringsarbetsytor. När du anger parametern -Scope organizationfungerar den som API:et Get Groups as Admin . Cmdleten accepterar också parametern -Include (som motsvarar parametern $expand i REST-API:et) för att inkludera objekt som publicerats på arbetsytan (till exempel semantiska modeller och rapporter).

Information om hur du väljer vilket alternativ du vill använda finns i Välj API:er eller PowerShell-cmdletar tidigare i den här artikeln.

Get Groups as Admin REST-API:et eller PowerShell-cmdleten Get-PowerBIWorkspace passar bäst för manuella granskningsprocesser och engångsundersökningar. Större organisationer med hög datavolym tycker vanligtvis att dessa alternativ är svåra att använda. REST-API:et och cmdleten extraherar alltid en fullständig uppsättning data så att de kan ta lång tid att köra. Så det är också troligt att större organisationer kommer att stöta på begränsningar för antalet begäranden som tillåts per timme (kallas begränsning, vilket görs för att skydda tjänstens hälsa). API:er för metadatagenomsökning (beskrivs härnäst) är ett mer tillförlitligt och skalbart alternativ.

API:er för metadatagenomsökning

API:erna för metadatagenomsökning, som ofta kallas skanner-API:er, är en uppsättning API:er som returnerar en lista över arbetsytor och deras Power BI-objekt (semantiska modeller, rapporter och andra objekt). Konceptuellt tillhandahåller de samma data (och mer) som grupp-API:erna eller arbetsytans cmdlet, som beskrivs i föregående avsnitt. Den metod som du använder för att hämta data är dock annorlunda och passar bättre för att extrahera klientinventeringen.

Det finns två huvudsakliga orsaker till varför du bör överväga att använda API:erna för metadatagenomsökning i stället för REST-API:et Get Groups as Admin eller cmdleten Get-PowerBIWorkspace (beskrivs tidigare).

• Extrahering av inkrementella data: Skanner-API:erna extraherar endast data som har ändrats sedan den senast kördes. Omvänt är REST-API:et Get Groups as Admin och cmdleten Get-PowerBIWorkspace synkrona åtgärder som extraherar den fullständiga uppsättningen data varje gång de körs.
• Mer detaljerad informationsnivå: Skanner-API:erna kan hämta detaljerad information (t.ex. tabeller, kolumner och måttuttryck) och ge behörighet beviljas av de två klientinställningarna för detaljerade metadata. Omvänt är den lägsta detaljnivån som är tillgänglig med REST-API:et Get Groups as Admin och cmdleten Get-PowerBIWorkspace efter objekttyp (till exempel en lista med rapporter på en arbetsyta).

Att använda skanner-API:erna innebär mer arbete eftersom du behöver anropa en serie API:er. Dessutom körs de som en asynkron process. En asynkron process körs i bakgrunden, så du behöver inte vänta tills den har slutförts. Du kan behöva samarbeta med IT eller en utvecklare när det är dags att skapa ett produktionsklart skript som ska schemaläggas.

Här är sekvensen med steg som processen bör följa när du använder skanner-API:erna.

1. Logga in: Logga in på Power BI-tjänst med hjälp av ett Power BI-administratörskonto eller ett tjänsthuvudnamn som har behörighet att köra administratörs-API:er. Mer information finns i Fastställa autentiseringsmetoden tidigare i den här artikeln.
2. Hämta arbetsyte-ID:t: Skicka en begäran om att hämta en lista över arbetsyte-ID:t. Första gången det körs har du inget ändrat datum, så det returnerar en fullständig lista över arbetsytor. Vanligtvis skickar du det ändrade datumet för att endast hämta arbetsytor som har ändrats sedan den tidpunkten. Det ändrade datumet måste vara inom de senaste 30 dagarna.
3. Initiera en metadatagenomsökning: Initiera ett anrop för att begära en genomsökning av arbetsyteinformation genom att skicka in de arbetsyte-ID:t som hämtades i steg 2. Observera att detta är ett POST-API (i stället för ett GET-API , vilket är vanligare vid hämtning av granskningsdata). ETT POST-API är en HTTP-begäran som skapar eller skriver data för en angiven resurs. Den här frågan anger den detaljnivå som ska extraheras, till exempel information om datakällor, semantiskt modellschema, semantiska modelluttryck eller användare. När det skickas returneras ett ID för genomsökningen av API:et. Den returnerar också datum och tid för genomsökningen, som du bör registrera som ögonblicksbildsdatum.
4. Kontrollera genomsökningsstatusen: Använd genomsöknings-ID:t som hämtades i steg 3 för att hämta genomsökningsstatusen. Du kan behöva anropa det här API:et mer än en gång. När den returnerade statusen är Lyckades kan du gå vidare till nästa steg. Hur lång tid det tar att skanna beror på hur mycket data du begär.
5. Hämta resultaten: Använd genomsöknings-ID:t som erhölls i steg 3 för att hämta genomsökningsresultatet och extrahera data. Du måste göra det här steget inom 24 timmar efter att du slutfört steg 4. Tänk på att tidsstämpeln för ögonblicksbilder bör korreleras med steg 3 i stället för steg 5 (när det uppstår en betydande fördröjning). På så sätt får du en korrekt tidsstämpel för ögonblicksbilder. Spara resultatet på önskad datalagringsplats. Som vi redan beskrivit i den här artikeln rekommenderar vi att du lagrar rådata i dess ursprungliga tillstånd.
6. Förbered för nästa process: Registrera tidsstämpeln för genomsökningen från steg 3 så att du kan använda den i steg 2 nästa gång du kör processen. På så sätt extraherar du bara data som har ändrats sedan den tidpunkten. Framöver kommer alla efterföljande dataextrakt att vara inkrementella ändringar i stället för fullständiga ögonblicksbilder.

Checklista – När du planerar för åtkomst till klientinventeringsdata inkluderar viktiga beslut och åtgärder:

Få åtkomst till användar- och gruppdata

Förutom den identifierande information (till exempel en e-postadress) som ingår i användaraktivitetsdata är det värdefullt att hämta ytterligare information, till exempel plats- eller organisationsinformation. Du kan använda Microsoft Graph för att hämta data om användare, grupper, tjänstens huvudnamn och licenser. Microsoft Graph består av en uppsättning API:er och klientbibliotek som gör att du kan hämta granskningsdata från en mängd olika tjänster.

Här följer lite information om De Microsoft Entra-objekt som du kan komma åt.

• Användare: En identitet som finns i Microsoft Entra-ID som ett arbets-, skol- eller Microsoft-konto. Termen domänanvändare används ofta för att beskriva organisationsanvändare, medan den formella termen är användarens huvudnamn (UPN). Ett UPN är vanligtvis samma värde som användarens e-postadress (men om en e-postadress ändras ändras inte UPN eftersom det är oföränderligt). Det finns också ett unikt Microsoft Graph-ID för varje användare. Ofta är ett användarkonto associerat med en person. Vissa organisationer skapar användare som är tjänstkonton som används för automatiserade aktiviteter eller för administrativa uppgifter.
• Tjänstens huvudnamn: En annan typ av identitet som etableras när du skapar en appregistrering. Tjänstens huvudnamn är avsett för obevakade, automatiserade aktiviteter. Mer information finns i Fastställa autentiseringsmetoden tidigare i den här artikeln.
• Grupp: En samling användare och tjänstens huvudnamn. Det finns flera typer av grupper som du kan använda för att förenkla behörighetshanteringen. Mer information finns i Strategi för att använda grupper.

De användare och grupper som du hämtar är en ögonblicksbild som beskriver det aktuella tillståndet vid en viss tidpunkt.

Analytiska attribut

För granskning på Power BI-klientnivå kan du extrahera och lagra följande attribut från Microsoft Graph.

• Fullständigt namn på användare: Många datakällor innehåller bara e-postadressen för användaren som utförde en aktivitet eller som har tilldelats till en roll. Använd det här attributet när du vill visa det fullständiga namnet (visningsnamnet) i analysrapporter. Om du använder det fullständiga namnet blir rapporterna mer användarvänliga.
• Andra användaregenskaper: Andra beskrivande attribut om användare kan vara tillgängliga i Microsoft Entra-ID. Några exempel på inbyggda användarprofilattribut som har analysvärde är jobbtitel, avdelning, chef, region och kontorsplats.
• Medlemmar i en säkerhetsgrupp: De flesta datakällor anger namnet på en grupp (till exempel posterna i Power BI-aktivitetsloggen som en säkerhetsgrupp har tilldelats till en arbetsyteroll). När du hämtar gruppmedlemskapet kan du analysera vad en enskild användare gör eller har åtkomst till.
• Användarlicenser: Det är användbart att analysera vilka användarlicenser – kostnadsfria, Power BI Pro eller Power BI Premium per användare (PPU)– som har tilldelats användarna. Dessa data kan hjälpa dig att identifiera vem som inte använder deras licens. Det hjälper dig också att analysera alla användare (distinkta användare med en licens) jämfört med aktiva användare (med de senaste aktiviteterna). Om du överväger att lägga till eller utöka dina Power BI Premium-licenser rekommenderar vi att du analyserar användarlicensdata tillsammans med användaraktivitetsdata för att utföra en kostnadsanalys.
• Medlemmar i administratörsrollerna: Du kan kompilera en lista över dina Power BI-administratörer (som inkluderar Power Platform-administratörer).

Den auktoritativa referensen för Licensinformation för Power BI som du hittar i granskningsdata från Microsoft Graph finns i Produktnamn och tjänstplansidentifierare för licensiering.

Här följer några andra attribut som du kan extrahera och lagra.

• Användartyp: Användare är antingen medlemmar eller gäster. Oftast är medlemmar interna användare och gäster är externa (B2B) användare. Det är användbart att lagra användartypen när du behöver analysera externa användares aktiviteter.
• Rolländringar: När du utför en säkerhetsgranskning är det användbart att förstå när en användare har ändrat roller i organisationen (till exempel när de överförs till en annan avdelning). På så sätt kan du kontrollera om deras Power BI-säkerhetsinställningar har uppdaterats eller bör uppdateras.
• Inaktiverade användare: När en användare lämnar organisationen inaktiverar vanligtvis en administratör sitt konto. Du kan skapa en process för att kontrollera om inaktiverade användare är arbetsyteadministratörer eller semantiska modellägare.

Hämta data för användare och grupper

Du kan hämta data om användare och grupper på olika sätt.

Teknik	Beskrivning	Bra val för manuella granskningsprocesser	Bra val för automatiserade granskningsprocesser
Manuell	Graph-testaren
Programmässig	Api:er och SDK:er för Microsoft Graph
Programmässig	Az PowerShell-modul

Resten av det här avsnittet beskriver var och en av de tekniker som presenteras i tabellen. Andra tekniker, som är inaktuella och inte bör användas för nya lösningar, beskrivs i slutet av det här avsnittet.

Microsoft Graph Explorer

Microsoft Graph Explorer är ett utvecklarverktyg där du kan lära dig mer om Microsoft Graph-API:er. Det är ett enkelt sätt att komma igång eftersom det inte krävs några andra verktyg eller installationer på datorn. Du kan logga in för att hämta data från din klientorganisation eller hämta exempeldata från en standardklientorganisation.

Du kan använda Graph Explorer för att:

• Skicka en begäran manuellt till ett Microsoft Graph-API för att kontrollera om den returnerar den information du vill ha.
• Se hur du skapar URL:en, rubrikerna och brödtexten innan du skriver ett skript.
• Kontrollera data på ett informellt sätt.
• Fastställa vilka behörigheter som krävs för varje API. Du kan också ge medgivande för nya behörigheter.
• Hämta kodfragment som ska användas när du skapar skript.

Använd den här länken om du vill öppna Graph Explorer.

Api:er och SDK:er för Microsoft Graph

Använd Microsoft Graph-API:erna för att hämta användare och grupper. Du kan också använda den för att hämta data från tjänster som Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook med mera.

Microsoft Graph SDK:er fungerar som en API-omslutning ovanpå de underliggande Microsoft Graph-API:erna. En SDK är ett programutvecklingspaket som buntar ihop verktyg och funktioner. Microsoft Graph SDK:er exponerar hela uppsättningen Med Microsoft Graph-API:er.

Du kan välja att skicka begäranden direkt till API:erna. Du kan också lägga till ett förenklingslager med hjälp av önskat språk och en av SDK:erna. Mer information finns i Välj API:er eller PowerShell-cmdletar tidigare i den här artikeln.

Microsoft Graph SDK:er stöder flera språk, och det finns även Microsoft Graph PowerShell-moduler . Andra SDK:er är tillgängliga för Python, C# och andra språk.

Du kan installera Microsoft Graph PowerShell-modulerna från PowerShell-galleriet. Eftersom Microsoft Graph fungerar med många Microsoft 365-tjänster finns det många PowerShell-moduler som du installerar.

För granskning på klientorganisationsnivå i Power BI finns här de vanligaste PowerShell-modulerna som du behöver installera.

• Autentisering (för inloggning)
• Användare
• Grupper
• Program (och tjänstens huvudnamn)
• Katalogobjekt (och licensinformation)

Az PowerShell-modul

Du kan också använda Az PowerShell-modulen för att hämta användare och grupper. Den fokuserar på Azure-resurser.

Du kan använda cmdleten Invoke-AzRestMethod när det inte finns någon motsvarande cmdlet för ett API. Det är en flexibel metod som gör att du kan skicka en begäran till alla Microsoft Graph-API:er med hjälp av Az PowerShell-modulen.

Från och med Az version 7 refererar Az-cmdletarna nu till Microsoft Graph-API:et. Därför fungerar Az-modulen som en API-omslutning ovanpå Microsoft Graph. Az-modulerna har en delmängd funktioner som finns i Microsoft Graph-API:erna och PowerShell-modulerna. För nya lösningar rekommenderar vi att du använder Microsoft Graph PowerShell SDK.

Inaktuella API:er och moduler

Du kan hitta artiklar och blogginlägg online som föreslår alternativa alternativ som inte visas i det här avsnittet. Vi rekommenderar starkt att du inte skapar nya lösningar (och/eller migrerar dina befintliga lösningar) med hjälp av någon av följande API:er eller moduler.

• AzureRM PowerShell-moduler: Inaktuella och dras tillbaka. De har ersatts med Az PowerShell-modulen.
• Azure AD Graph API och Azure AD PowerShell-modulen: Inaktuell och kommer att dras tillbaka. Den här ändringen är resultatet av migreringen från Azure AD Graph till Microsoft Graph (observera att Graph visas i båda namnen, men Microsoft Graph är den framtida riktningen). Alla framtida PowerShell-investeringar kommer att göras i Microsoft Graph PowerShell SDK.
• MS Online (MSOL) PowerShell-modul: Inaktuell och kommer att dras tillbaka. Alla framtida PowerShell-investeringar kommer att göras i Microsoft Graph PowerShell SDK.

Checklista – När du planerar att komma åt data för användare och grupper är viktiga beslut och åtgärder:

Komma åt data från Power BI REST-API:er

Kanske som en lägre prioritet kan du också hämta andra data med hjälp av Power BI REST-API:er.

Du kan till exempel hämta data om:

• Alla appar i organisationen.
• Alla importerade semantiska modeller i organisationen.
• Alla distributionspipelines i organisationen.
• Alla Premium-kapaciteter i organisationen.

Under en säkerhetsgranskning kanske du vill identifiera:

• Objekt som har delats i stor utsträckning med hela organisationen.
• Objekt som är tillgängliga på det offentliga Internet med publicera på webben.

Mer information om andra typer av API:er finns i Välj ett användar-API eller administratörs-API tidigare i den här artikeln.

Checklista – När du planerar att komma åt data från Power BI-API är viktiga beslut och åtgärder:

Fas 2: Förutsättningar och installation

Den andra fasen av planering och implementering av en granskningslösning på klientorganisationsnivå fokuserar på krav och konfiguration som måste göras innan du påbörjar lösningsutvecklingen.

Skapa lagringskonto

Nu har du bestämt dig för en plats där rådata ska lagras och hur du skapar kurerade data. Baserat på dessa beslut är du nu redo att skapa ett lagringskonto. Beroende på organisationens processer kan det innebära att skicka en begäran till IT-avdelningen.

Som vi beskrev tidigare rekommenderar vi att du använder en teknik som gör att du kan skriva rådata till oföränderlig lagring. När data har skrivits kan de inte ändras eller tas bort. Du kan sedan ha förtroende för rådata eftersom du vet att en administratör med åtkomst inte kan ändra dem på något sätt. De kurerade data behöver dock inte (vanligtvis) lagras i oföränderlig lagring. Kuraterade data kan ändras eller återskapas.

Checklista – När du skapar ett lagringskonto omfattar viktiga beslut och åtgärder:

Installera programvara och konfigurera tjänster

Nu har du fattat dina beslut om vilken teknik som ska användas för åtkomst till granskningsdata. Baserat på dessa beslut är du nu redo att installera programvara och konfigurera tjänster.

Konfigurera önskad utvecklingsmiljö för varje administratör. Utvecklingsmiljön gör att de kan skriva och testa skript. Visual Studio Code är ett modernt verktyg för att utveckla skript, så det är ett bra alternativ. Många tillägg är också tillgängliga för att fungera med Visual Studio Code.

Om du har fattat beslutet (tidigare beskrivit) att använda PowerShell bör du installera PowerShell Core och de nödvändiga PowerShell-modulerna på:

• Datorn för varje administratör/utvecklare som ska skriva eller testa granskningsskript.
• Varje virtuell dator eller server som ska köra schemalagda skript.
• Varje onlinetjänst (till exempel Azure Functions eller Azure Automation).

Om du har valt att använda azure-tjänster (till exempel Azure Functions, Azure Automation, Azure Data Factory eller Azure Synapse Analytics) bör du även etablera och konfigurera dem.

Checklista – När du installerar programvara och konfigurerar tjänster är viktiga beslut och åtgärder:

Registrera ett Microsoft Entra-program

Nu har du bestämt dig för hur du ska autentisera. Vi rekommenderar att du registrerar ett Microsoft Entra-program (tjänstens huvudnamn). Den kallas ofta för en appregistrering och bör användas för obevakade åtgärder som du automatiserar.

Mer information om hur du skapar en appregistrering för att hämta granskningsdata på klientorganisationsnivå finns i Aktivera autentisering med tjänstens huvudnamn för skrivskyddade administratörs-API:er.

Checklista – När du registrerar ett Microsoft Entra-program omfattar viktiga beslut och åtgärder:

Ange inställningar för Power BI-klientorganisationen

Det finns flera klientinställningar i Power BI-administratörsportalen som är relevanta för att extrahera granskningsdata på klientnivå.

Administratörs-API:er

Det finns tre klientinställningar som är relevanta för att köra administratörs-API:er.

Med inställningen Tillåt att tjänstens huvudnamn använder skrivskyddade Power BI-administratörs-API:er kan du ange vilka tjänsthuvudnamn som kan anropa administratörs-API:er. Den här inställningen gör också att Microsoft Purview kan genomsöka hela Power BI-klientorganisationen så att den kan fylla i datakatalogen.

Med inställningen Förbättra admin-API:et med detaljerade metadataklientinställningar kan du ange vilka användare och tjänstens huvudnamn som kan hämta detaljerade metadata. Metadata hämtas med api:erna för metadatagenomsökning och innehåller tabeller, kolumner med mera. Den här inställningen gör det också möjligt för Microsoft Purview att komma åt information på schemanivå om Power BI-semantiska modeller så att den kan lagras i datakatalogen.

Med inställningen Förbättra admin-API:et med DAX- och kombinationsuttryck kan du ange vilka användare och tjänstens huvudnamn som kan hämta detaljerade metadata. Metadata hämtas från API:erna för metadatagenomsökning och kan innehålla frågor och semantiska modellmåttuttryck.

Användar-API:er

Det finns en klientinställning som gäller för anropande användar-API:er. I det här fallet krävs även Power BI-behörigheter för tjänstens huvudnamn (till exempel en arbetsyteroll).

Med inställningen Tillåt att tjänstens huvudnamn använder Power BI-API s klientorganisation kan du ange vilka tjänsthuvudnamn som har åtkomst till att köra REST-API:er (exklusive administratörs-API:er, som beviljas av en annan klientinställning, som beskrivs ovan).

Det finns andra klientinställningar som är relaterade till API:er, som ger åtkomst till api:er för inbäddning, strömmande API:er, exportera API:er och köra fråge-API:et. Dessa API:er ligger dock utanför omfånget för den här artikeln.

Mer information om klientinställningarna för användningsstatistik finns i Granskning på rapportnivå.

Checklista – När du konfigurerar Power BI-klientinställningarna omfattar viktiga beslut och åtgärder:

Fas 3: Utveckling och analys av lösningar

Den tredje fasen av planering och implementering av en granskningslösning på klientorganisationsnivå fokuserar på lösningsutveckling och analys. Nu har all planering och beslutsfattande inträffat och du har uppfyllt kraven och slutfört installationen. Nu är du redo att börja utveckla lösningar så att du kan utföra analyser och få insikter från dina granskningsdata.

Extrahera och lagra rådata

I det här läget bör dina krav och prioriteringar vara tydliga. De viktigaste tekniska besluten har fattats om hur du får åtkomst till granskningsdata och var granskningsdata ska lagras. Önskade verktyg har valts och förutsättningarna och inställningarna har konfigurerats. Under de föregående två faserna kan du ha slutfört ett eller flera små projekt (konceptbevis) för att bevisa genomförbarhet. Nästa steg är att konfigurera en process för att extrahera och lagra rådata för granskning.

Precis som med data som returneras av de flesta Microsoft-API:er formateras granskningsdata som JSON. JSON-formaterade data är självbeskrivande eftersom det är mänsklig läsbar text som innehåller struktur och data.

JSON representerar dataobjekt som består av attribut/värde-par och matriser. Är till exempel "state": "Active" ett exempel där värdet för tillståndsattributet är Aktivt. En JSON-matris innehåller en ordnad lista över element avgränsade med ett kommatecken och som omges av hakparenteser ([ ]). Det är vanligt att hitta kapslade matriser i JSON-resultat. När du har bekantat dig med den hierarkiska strukturen för ett JSON-resultat är det enkelt att förstå datastrukturen, till exempel en lista (matris) med semantiska modeller på en arbetsyta.

Här följer några saker att tänka på när du extraherar och lagrar rådata som hämtats från API:erna.

• Vilken namngivningskonvention kommer att användas? För ett filbaserat system krävs en namngivningskonvention för filer, mappar och datasjözoner. För en databas krävs en namngivningskonvention för tabeller och kolumner.
• Vilket format kommer att användas för att lagra rådata? När Power BI fortsätter att introducera nya funktioner visas nya aktiviteter som inte finns i dag. Därför rekommenderar vi att du extraherar och behåller de ursprungliga JSON-resultaten. Parsa, filtrera eller formatera inte data medan de extraheras. På så sätt kan du använda de ursprungliga rådata för att återskapa dina granskade granskningsdata.
• Vilken lagringsplats kommer att användas? En datasjö eller bloblagring används ofta för att lagra rådata. Mer information finns i Fastställa var granskningsdata ska lagras tidigare i den här artikeln.
• Hur mycket historik kommer du att lagra? Exportera granskningsdata till en plats där du kan lagra historiken. Planera att ackumulera minst två års historia. På så sätt kan du analysera trender och ändringar utöver standardperioden på 30 dagar. Du kan välja att lagra data på obestämd tid, eller så kan du bestämma dig för en kortare period, beroende på organisationens datakvarhållningsprinciper.
• Hur spårar du när processen senast kördes? Konfigurera en konfigurationsfil, eller motsvarande, för att registrera tidsstämplar när en process startas och avslutas. Nästa gång processen körs kan den hämta dessa tidsstämplar. Det är särskilt viktigt att du lagrar tidsstämplar när du extraherar data med hjälp av API:erna för metadatagenomsökning.
• Hur hanterar du begränsning? Vissa Power BI REST-API:er och Microsoft Graph API implementerar begränsning. Du får ett 429-fel (för många begäranden) om DIN API-begäran begränsas. Begränsning kan vara ett vanligt problem för större organisationer som behöver hämta en stor mängd data. Hur du undviker misslyckade försök på grund av begränsning beror på vilken teknik du använder för att komma åt och extrahera data. Ett alternativ är att utveckla logik i dina skript som svarar på ett 429-fel med "För många begäranden" genom att försöka igen efter en väntetid.
• Behövs granskningsdata för efterlevnad? Många organisationer använder råa granskningsloggposter för att utföra efterlevnadsgranskningar eller för att svara på säkerhetsundersökningar. I dessa fall rekommenderar vi starkt att du lagrar rådata i oföränderlig lagring. På så sätt kan de inte ändras eller tas bort av en administratör eller annan användare när data har skrivits.
• Vilka lagringslager krävs för att stödja dina krav? De bästa platserna för att lagra rådata är en datasjö (som Azure Data Lake Storage Gen2) eller objektlagring (som Azure Blob Storage). Ett filsystem kan också användas om molntjänster inte är ett alternativ.

Checklista – När du extraherar och lagrar rådata omfattar viktiga beslut och åtgärder:

Mer information om hur en gransknings- och övervakningslösning växer över tid finns i Operationalisera och förbättra senare i den här artikeln.

Skapa de kurerade data

Nu extraheras och lagras rådata. Nästa steg är att skapa ett separat gulddatalager för de kurerade data. Målet är att transformera och lagra datafilerna i ett stjärnschema. Ett star-schema består av dimensionstabeller och faktatabeller och är avsiktligt optimerat för analys och rapportering. Filerna i det kurerade datalagret blir källan till en Power BI-datamodell (beskrivs i nästa avsnitt).

Checklista – När du skapar det kurerade datalagret omfattar viktiga beslut och åtgärder:

Skapa en datamodell

Ämnet handlar om att konfigurera en analysdatamodell. En datamodell är frågeaktiverad dataresurs som är optimerad för analys. Ibland kallas det för en semantisk modell, eller helt enkelt en modell. För din gransknings- och övervakningslösning implementeras datamodellen sannolikt som en Power BI-semantisk modell.

I samband med granskning och övervakning hämtar en datamodell data från det kurerade datalagret (guld). Om du väljer att inte skapa ett kuraterat datalager hämtar datamodellen sina data direkt från rådata.

Vi rekommenderar att din Power BI-datamodell implementerar en star-schemadesign. När källdata är det kurerade datalagret bör Star-schemat för Power BI-datamodellen spegla det kuraterade dataskiktets stjärnschema.

Precis som med alla Power BI-projekt är det en iterativ process att skapa en datamodell. Du kan lägga till nya mått efter behov. Du kan också lägga till nya tabeller och kolumner när nya granskningshändelser blir tillgängliga. Med tiden kanske du till och med integrerar nya datakällor.

Här följer några användbara dimensionstabeller som du kan inkludera i datamodellen.

• Datum: En uppsättning datumattribut för att aktivera analys (segmentering och diktering) av data efter dag, vecka, månad, kvartal, år och andra relevanta tidsperioder.
• Tid: Om du behöver analysera efter tid på dagen och du har en mycket stor mängd granskningsdata bör du överväga att lagra tidsdelen separat från datumet. Den här metoden kan hjälpa till att förbättra frågeprestanda.
• Användare: Attribut som beskriver användare (till exempel avdelning och geografisk region) som kan filtrera många ämnen för granskningsdata. Målet är att ta bort all användarinformation från faktatabellerna och lagra dem i den här dimensionstabellen så att de kan filtrera många faktatabeller. Du kan också lagra tjänstens huvudnamn i den här tabellen.
• Aktivitetshändelser: Attribut som grupperar och beskriver aktivitetshändelserna (åtgärderna). För att förbättra din rapportering kan du skapa en dataordlista som beskriver varje aktivitetshändelse. Du kan också skapa en hierarki som grupperar och klassificerar liknande aktivitetshändelser. Du kan till exempel gruppera alla händelser för att skapa objekt, ta bort händelser och så vidare.
• Arbetsytor: En lista över arbetsytor i egenskaperna för klientorganisationen och arbetsytan, till exempel typ (personlig eller standard) och beskrivning. Vissa organisationer registrerar mer information om arbetsytor (eventuellt med hjälp av en SharePoint-lista). Du kan integrera den här informationen i den här dimensionstabellen. Du måste bestämma om den här dimensionstabellen endast lagrar arbetsytans aktuella tillstånd eller om den lagrar versionsdata som återspeglar betydande ändringar av arbetsytan över tid. När ett arbetsytenamn till exempel ändras, visar historisk rapportering det aktuella arbetsytans namn eller namnet på arbetsytan som var aktuell vid den tidpunkten? Mer information om versionshantering finns i Långsamt föränderliga dimensioner.
• Objekttyper: En lista över Power BI-objekttyper (semantiska modeller, rapporter och andra).
• Kapaciteter: En lista över Premium-kapaciteter i klientorganisationen.
• Gatewayer: En lista över datagatewayer i klientorganisationen.
• Datakällor: En lista över datakällor som används av en semantisk modell, dataflöde eller datamart.

Här följer några användbara faktatabeller (ämnen) som du kan inkludera i datamodellen.

• Användaraktiviteter: Faktadata som kommer från de ursprungliga JSON-data. Alla attribut som inte har något analysvärde tas bort. Alla attribut som hör till dimensionstabellerna (ovan) tas också bort.
• Klientinventering: En ögonblicksbild av alla objekt som publicerats i klientorganisationen. Mer information finns i Klientinventering tidigare i den här artikeln.
• Semantiska modeller: Innehåller användaraktivitet som involverar semantiska modeller (till exempel ändringar i semantiska modeller) eller relaterade datakällor.
• Semantiska modelluppdateringar: Lagrar datauppdateringsåtgärder, inklusive information om typ (schemalagd eller på begäran), varaktighet, status och vilken användare som initierade åtgärden.
• Arbetsyteroller: En ögonblicksbild av rolltilldelningar för arbetsytor.
• Användarlicenser: En ögonblicksbild av användarlicenser till en tidpunkt. Du kan vara frestad att lagra användarlicensen i dimensionstabellen Användare , men den metoden stöder inte analys av licensändringar och trender över tid.
• Medlemskap i användargrupper: En ögonblicksbild av användare (och tjänstens huvudnamn) som tilldelats en säkerhetsgrupp.
• Community-aktiviteter: Innehåller communityrelaterade fakta, till exempel utbildningsevenemang. Du kan till exempel analysera Power BI-användaraktiviteter jämfört med träningsnärvaro. Dessa data kan hjälpa Center of Excellence att identifiera potentiella nya mästare.

Faktatabeller får inte innehålla kolumner som rapportskapare filtrerar. I stället tillhör dessa kolumner relaterade dimensionstabeller. Den här designen är inte bara effektivare för frågor, utan främjar även återanvändning av dimensionstabeller med flera fakta (kallas för detaljgranskning). Den sista punkten är viktig för att skapa en användbar och användarvänlig datamodell som är utökningsbar när du lägger till nya faktatabeller (ämnen).

Dimensionstabellen Användare är till exempel relaterad till varje faktatabell. Den bör vara relaterad till faktatabellen Användaraktiviteter (vem som utförde aktiviteten), faktatabellen för klientinventering (som skapade det publicerade objektet) och alla andra faktatabeller. När en rapport filtreras av en användare i dimensionstabellen Användare kan visuella objekt i rapporten visa fakta för användaren från alla relaterade faktatabeller.

När du utformar din modell kontrollerar du att ett attribut visas en gång, och bara en gång, i modellen. Användarens e-postadress bör till exempel bara visas i dimensionstabellen Användare . Den finns även i andra faktatabeller (som en dimensionsnyckel för att stödja en modellrelation). Du bör dock dölja den i varje faktatabell.

Vi rekommenderar att du skapar din datamodell separat från rapporter. Avkopplingen av en semantisk modell och dess rapporter resulterar i en centraliserad semantisk modell som kan hantera många rapporter. Mer information om hur du använder en delad semantisk modell finns i scenariot för hanterad bi-användning med självbetjäning .

Överväg att konfigurera säkerhet på radnivå (RLS) så att andra användare – utöver Center of Excellence, granskare och administratörer – kan analysera och rapportera om granskningsdata. Du kan till exempel använda RLS-regler för att låta innehållsskapare och konsumenter rapportera om sina egna användaraktiviteter eller utvecklingsinsatser.

Checklista – När du skapar datamodellen omfattar viktiga beslut och åtgärder:

Förbättra datamodellen

För att effektivt analysera innehållsanvändning och användaraktiviteter rekommenderar vi att du utökar din datamodell. Förbättringar av datamodeller kan göras gradvis och iterativt över tid när du upptäcker möjligheter och nya krav.

Skapa klassificeringar

Ett sätt att förbättra modellen och öka värdet på dina data är att lägga till klassificeringar i datamodellen. Se till att dessa klassificeringar används konsekvent av dina rapporter.

Du kan välja att klassificera användare baserat på deras användningsnivå eller klassificera innehåll baserat på dess användningsnivå.

Klassificering av användaranvändning

Överväg följande klassificeringar för användaranvändning.

• Frekvent användare: Aktivitet som registrerats under den senaste veckan och under nio av de senaste 12 månaderna.
• Aktiv användare: Aktivitet som registrerats under den senaste månaden.
• Tillfällig användare: Aktivitet som registrerats under de senaste nio månaderna, men utan aktivitet under den senaste månaden.
• Inaktiv användare: Ingen aktivitet har registrerats under de senaste nio månaderna.

Klassificering av innehållsanvändning

Överväg följande klassificeringar för innehållsanvändning.

• Innehåll som används ofta: Aktivitet som registrerats under den senaste veckan och under nio av de senaste 12 månaderna.
• Aktivt använt innehåll: Aktivitet som registrerats under den senaste månaden.
• Ibland använt innehåll: Aktivitet som registrerats under de senaste nio månaderna, men utan aktivitet under den senaste månaden.
• Oanvänt innehåll: Ingen aktivitet har registrerats under de senaste nio månaderna.

Klassificering av användartyp

Överväg följande klassificeringar för användartyp.

• Innehållsskapare: Aktivitet som registrerats under de senaste sex månaderna som skapat, publicerat eller redigerat innehåll.
• Innehållsvisningsprogram: Aktivitet som registrerats under de senaste sex månaderna som visat innehåll, men utan någon aktivitet för att skapa innehåll.

Överväg att ta hänsyn till rekency kontra trender

Du bör bestämma om användningsklassificeringarna för användare eller innehåll endast ska baseras på hur nyligen en aktivitet har inträffat. Du kanske också vill överväga att ta hänsyn till genomsnittlig eller trendande användning över tid.

Tänk dig några exempel som visar hur enkel klassificeringslogik kan förvränga verkligheten.

• En chef visade en rapport den här veckan. Men före den veckan hade chefen inte sett några rapporter under de senaste sex månaderna. Du bör inte betrakta den här chefen som en frekvent användare enbart baserat på den senaste användningen.
• En rapportskapare publicerar en ny rapport varje vecka. När du analyserar användningen av frekventa användare verkar rapportskapares regelbundna aktivitet vara positiv. Men vid ytterligare undersökning upptäcker du att den här användaren har publicerat en ny rapport (med ett nytt rapportnamn) varje gång de redigerar rapporten. Det skulle vara användbart för rapportskapare att ha mer utbildning.
• En chef visar en rapport sporadiskt och därför ändras deras användningsklassificering ofta. Du kan behöva analysera vissa typer av användare, till exempel chefer, på olika sätt.
• En intern granskare granskar kritiska rapporter en gång per år. Internrevisorn kan verka vara en inaktiv användare på grund av deras ovanliga användning. Någon kan vidta åtgärder för att ta bort sin Pro- eller PPU-licens. Eller så kan någon tro att en rapport bör dras tillbaka eftersom den används sällan.

Checklista – När du skapar klassificering av användningsdata omfattar viktiga beslut och åtgärder:

Skapa analysrapporter

Nu har granskningsdata extraherats och lagrats och du har publicerat en datamodell. Nästa steg är att skapa analysrapporter.

Fokusera på den viktigaste informationen som är mest relevant för varje målgrupp. Du kan ha flera målgrupper för dina granskningsrapporter. Varje målgrupp kommer att vara intresserad av olika information och för olika ändamål. De målgrupper som du kan ha med dina rapporter är:

• Projektägare
• Center of Excellence
• Power BI-administratörer
• Administratörer för arbetsyta
• Premium-kapacitetsadministratörer
• Gatewayadministratörer
• Power BI-utvecklare och innehållsskapare
• Granskare

Här är några av de vanligaste analytiska kraven som du kanske vill börja med när du skapar granskningsrapporter.

• Toppinnehållsvyer: Din chefssponsor och ledningsgrupp kan främst vara intresserad av sammanfattningsinformation och trender över tid. Dina arbetsyteadministratörer, utvecklare och innehållsskapare är mer intresserade av informationen.
• Främsta användaraktiviteter: Ditt center för excellens är intresserad av vem som använder Power BI, hur och när. Dina Premium-kapacitetsadministratörer är intresserade av vem som använder kapaciteten för att säkerställa dess hälsa och stabilitet.
• Innehavarinventering: Dina Power BI-administratörer, arbetsyteadministratörer och granskare är intresserade av att förstå vilket innehåll som finns, var, ursprung och dess säkerhetsinställningar.

Den här listan är inte allomfattande. Den är avsedd att ge dig idéer om hur du skapar analysrapporter som riktar sig till specifika behov. Mer information finns i Databehov tidigare i den här artikeln och Översikt över granskning och övervakning. Dessa resurser innehåller många idéer för hur du kan använda granskningsdata och vilka typer av information du kan välja att presentera i dina rapporter.

Checklista – När du planerar för analytiska granskningsrapporter inkluderar viktiga beslut och åtgärder:

Vidta åtgärder baserat på data

Granskningsdata är värdefulla eftersom det hjälper dig att förstå vad som händer i din Power BI-klientorganisation. Även om det kan verka uppenbart kan du enkelt bortse från vad du lär dig av granskningsdata. Därför rekommenderar vi att du tilldelar någon som ansvarar för att spåra mätbara förbättringar i stället för att bara granska granskningsrapporter. På så sätt kan du göra gradvisa, mätbara framsteg i din implementering och mognadsnivå med Power BI.

Du kan vidta många olika åtgärder baserat på dina mål och vad du lär dig av granskningsdata. Resten av det här avsnittet innehåller flera idéer.

Innehållsanvändning

Här följer några åtgärder som du kan vidta baserat på hur innehåll används.

• Innehåll används ofta (dagligen eller varje vecka): Kontrollera att kritiskt innehåll är certifierat. Bekräfta att ägarskapet är tydligt och att lösningen stöds på lämpligt sätt.
• Stort antal arbetsytevyer: När ett stort antal arbetsytevyer inträffar undersöker du varför Power BI-appar inte används.
• Innehållet används sällan: Kontakta målanvändare för att avgöra om lösningen uppfyller deras behov eller om deras krav har ändrats.
• Uppdateringsaktivitet sker oftare än vyer: Kontakta innehållsägaren för att förstå varför en semantisk modell uppdateras regelbundet utan att semantikmodellen eller relaterade rapporter används nyligen.

Användaraktiviteter

Här följer några åtgärder som du kan vidta baserat på användaraktiviteter.

• Första publiceringsåtgärden av en ny användare: Identifiera när en användartyp ändras från konsument till skapare, som du kan identifiera när de publicerar innehåll för första gången. Det är ett bra tillfälle att skicka ett standardmeddelande till dem som ger vägledning och länkar till användbara resurser.
• Engagemang med de vanligaste innehållsskaparna: Bjud in dina mest aktiva skapare att gå med i ditt champions-nätverk eller engagera dig i din community.
• Licenshantering: Kontrollera om inaktiva skapare fortfarande behöver en Pro- eller PPU-licens.
• Aktivering av användarutvärdering: En aktivering av utvärderingslicenser kan uppmana dig att tilldela användaren en permanent licens innan utvärderingsversionen avslutas.

Utbildningsmöjligheter för användare

Här följer några möjligheter till användarträning som du kan identifiera från granskningsdata.

• Ett stort antal semantiska modeller som publicerats av samma innehållsskapare: Lär användarna om delade semantiska modeller och varför det är viktigt att undvika att skapa dubbletter av semantiska modeller.
• Överdriven delning från en personlig arbetsyta: Kontakta en användare som delar mycket från sin personliga arbetsyta. Lär dem om standardarbetsytor.
• Viktiga rapportvyer från en personlig arbetsyta: Kontakta en användare som äger innehåll som har ett stort antal rapportvyer. Lär dem hur standardarbetsytor är bättre än personliga arbetsytor.

Säkerhet

Här följer några säkerhetssituationer som du kanske vill övervaka aktivt.

• För många användare som har tilldelats administratörsrollen infrastrukturresurser med hög behörighet.
• För många arbetsyteadministratörer (när arbetsyterollen Medlem, Deltagare eller Visningsprogram räcker).
• Överdrivna build-behörigheter som tilldelats semantiska modeller (när läsbehörigheten skulle vara tillräcklig).
• Hög användning av behörigheter per objekt, när Power BI-appbehörigheter eller arbetsytans visningsroll skulle vara ett bättre val för innehållskonsumenter.
• Hur innehåll delas med externa användare.

Mer information finns i artiklarna om säkerhetsplanering .

Styrning och riskreducering

Här följer några situationer som du kan stöta på. Överväg att uttryckligen söka efter dessa typer av situationer i granskningsrapporterna, så att du är beredd att agera snabbt.

• Stort antal vyer för rapporter (och underliggande semantiska modeller) som inte stöds.
• Betydande användning av okända eller icke-sanktionerade datakällor.
• Filplatser som inte överensstämmer med styrningsriktlinjerna för var källfiler ska finnas.
• Namn på arbetsytor överensstämmer inte med styrningskraven.
• Känslighetsetiketter används för informationsskydd.
• Konsekventa datauppdateringsfel.
• Betydande och återkommande utskriftsanvändning.
• Oväntad eller överdriven användning av prenumerationer.
• Oväntad användning av personliga gatewayer.

De specifika åtgärder som ska vidtas i varje situation beror på dina styrningsprinciper. Mer information finns i Styrning i översikten för infrastrukturimplementering.

Checklista – När du planerar för potentiella åtgärder baserat på granskningsdata inkluderar viktiga beslut och åtgärder:

Fas 4: Underhålla, förbättra och övervaka

Den fjärde fasen av planering och implementering av en granskningslösning på klientorganisationsnivå fokuserar på underhåll, förbättringar och övervakning. Nu används granskningslösningen i produktion. Nu handlar det främst om att underhålla, förbättra och övervaka lösningen.

Operationalisera och förbättra

Granskningsprocesser anses vanligtvis köras i produktion när den inledande utvecklingen och testningen är klar och du har automatiserat processen. Automatiserade granskningsprocesser som körs i produktion har större förväntningar (än manuella processer) på kvalitet, tillförlitlighet, stabilitet och support.

En granskningsprocess på produktionsnivå har operationaliserats. En operationaliserad lösning innehåller ofta många av följande egenskaper.

• Säker: Autentiseringsuppgifter lagras och hanteras på ett säkert sätt. Skript innehåller inte lösenord eller nycklar i klartext.
• Schemaläggning: Ett tillförlitligt schemaläggningssystem finns på plats.
• Ändringshantering: Användning av ändringshanteringsmetoder och flera miljöer används för att säkerställa att produktionsmiljön skyddas. Du kan också arbeta med utvecklings- och testmiljöer, eller bara en utvecklingsmiljö.
• Support: Det team som stöder lösningen är tydligt definierat. Teammedlemmar har utbildats och de förstår driftsförväntningarna. Säkerhetskopieringsmedlemmar har identifierats och korsträning sker när det är lämpligt.
• Aviseringar: När något går fel meddelar aviseringar supportteamet automatiskt. Helst innehåller aviseringar både loggar och e-post (i stället för endast e-post). En logg är användbar för att analysera loggade fel och varningar.
• Loggning: Processer loggas så det finns en historik över när granskningsdata uppdaterades. Loggad information ska registrera starttid, sluttid och identiteten för den användare eller app som körde processen.
• Felhantering: Skript och processer hanterar korrekt och loggar fel (till exempel om du vill avsluta omedelbart, fortsätta eller vänta och försöka igen). Aviseringsmeddelanden skickas till supportteamet när ett fel inträffar.
• Kodningsstandarder: Bra kodningstekniker som fungerar bra används. Till exempel undviks loopar avsiktligt förutom när det behövs. Konsekventa kodningsstandarder, kommentarer, formatering och syntax används så att lösningen blir enklare att underhålla och stödja.
• Återanvändning och modularisering: För att minimera duplicering är kod- och konfigurationsvärden (till exempel anslutningssträng eller e-postadresser för meddelanden) modulariserade så att andra skript och processer kan återanvända dem.

Checklista – När du planerar att operationalisera och förbättra en granskningslösning är viktiga beslut och åtgärder:

Dokumentation och support

Dokumentation och support är viktiga för alla lösningar på produktionsnivå. Det är bra att skapa flera typer av dokumentation, beroende på målgrupp och syfte.

Teknisk dokumentation

Teknisk dokumentation riktar sig till det tekniska teamet som har skapat lösningen och som gradvis kommer att förbättra och utöka lösningen över tid. Det är också en användbar resurs för supportteamet.

Teknisk dokumentation bör omfatta:

• En sammanfattning av arkitekturkomponenter och krav.
• Vem som äger och hanterar lösningen.
• Vem stöder lösningen.
• Ett arkitekturdiagram.
• Designbeslut, inklusive mål, orsaker till att vissa tekniska val har gjorts och begränsningar (till exempel kostnad eller färdigheter).
• Säkerhetsbeslut och val.
• Namngivningskonventioner som används.
• Kodning och tekniska standarder och riktlinjer.
• Krav för ändringshantering.
• Instruktioner för distribution, installation och installation.
• Kända områden med teknisk skuld (områden som kan förbättras om det finns möjlighet att göra det).

Supportdokumentation

Beroende på hur kritisk din granskningslösning är kan du ha en supportavdelning eller supportteam om brådskande problem skulle uppstå. De kan vara tillgängliga hela dagen, varje dag.

Supportdokumentation kallas ibland för en kunskapsbas eller en runbook. Den här dokumentationen riktar sig till supportavdelningen eller supportteamet och bör innehålla:

• Felsökningsvägledning för när något går fel. Till exempel när det uppstår ett datauppdateringsfel.
• Åtgärder som ska utföras löpande. Det kan till exempel finnas några manuella steg som någon behöver utföra regelbundet tills ett problem har lösts.

Dokumentation om innehållsskapare

Du härleder mer värde från granskningslösningen genom att tillhandahålla användnings- och implementeringsanalys till andra team i hela organisationen (med säkerhet på radnivå framtvingad om det behövs).

Dokumentation om innehållsskapare riktar sig till innehållsskapare med självbetjäning som skapar rapporter och datamodeller som hämtar de granskade granskningsdata. Den innehåller information om datamodellen, inklusive vanliga datadefinitioner.

Checklista – När du planerar för dokumentation och support för din granskningslösning är viktiga beslut och åtgärder:

Aktivera aviseringar

Du kanske vill skapa aviseringar baserat på specifika villkor i granskningsdata. Du kan till exempel skapa en avisering när någon tar bort en gateway eller när en Power BI-administratör ändrar en klientinställning.

Mer information finns i Övervakning på klientorganisationsnivå.

Löpande hantering

Du måste utföra löpande hantering av hela granskningslösningen. Du kan behöva utöka eller ändra granskningslösningen när:

• Organisationen identifierar nya datakrav.
• Nya granskningshändelser visas i rådata som du exakt ser från Power BI REST-API:erna.
• Microsoft gör ändringar i Power BI REST-API:er.
• Medarbetarna identifierar sätt att förbättra lösningen.

Checklista – När du planerar för löpande hantering av granskningslösningen omfattar viktiga beslut och åtgärder:

Relaterat innehåll

I nästa artikel i den här serien får du lära dig mer om övervakning på klientorganisationsnivå.