Planlegging av Power BI-implementering: Overvåking på leiernivå

  • Artikkel

Merk

Denne artikkelen er en del av planleggingsserien for power BI-implementering av artikler. Denne serien fokuserer hovedsakelig på Power BI-arbeidsbelastningen i Microsoft Fabric. Hvis du vil ha en innføring i serien, kan du se Planlegging av Power BI-implementering.

Denne revisjonsplanleggingsartikkelen på leiernivå er primært rettet mot:

  • Power BI-administratorer: Administratorene som er ansvarlige for å overvåke Power BI i organisasjonen. Power BI-administratorer må kanskje samarbeide med IT, sikkerhet, intern revisjon og andre relevante team.
  • Center of Excellence- og IT- og BI-teamet: Teamene som også er ansvarlige for å overvåke Power BI. De må kanskje samarbeide med Power BI-administratorer og andre relevante team.

Viktig

Vi anbefaler at du følger utgivelsesplanen for Power BI nøye for å lære om fremtidige forbedringer av revisjons- og overvåkingsfunksjonene.

Formålet med en overvåkingsløsning på leiernivå er å registrere og analysere data for alle brukere, aktiviteter og løsninger som er distribuert til en Power BI-tenant. Disse overvåkingsdataene på leiernivå er verdifulle for mange formål, slik at du kan analysere innføringstiltak, forstå bruksmønstre, lære opp brukere, støtte brukere, redusere risiko, forbedre samsvar, administrere lisenskostnader og overvåke ytelsen.

Oppretting av en løsning for ende-til-ende-overvåking som er sikker og produksjonsklar, er et betydelig prosjekt som tar tid. Tenk på det som å bygge forretningsintelligens på forretningsintelligens (BI på BI). Hvis du vil ha informasjon om hvorfor overvåkingsdataene er så verdifulle, kan du se Oversikt over overvåking og overvåking.

Hvis du vil se overvåking på rapportnivå, som er rettet mot rapportopprettere, kan du se overvåking på rapportnivå.

Hvis du vil overvåke dataressurser, som er rettet mot dataopprettere, kan du se Overvåking på datanivå.

Resten av denne artikkelen fokuserer på overvåking på leiernivå.

Tips

Hovedfokuset i denne artikkelen er å hjelpe deg med å planlegge å opprette en løsning for ende-til-ende-overvåking. Fordi innholdet i denne artikkelen er organisert i fire faser, trenger du informasjon på tvers av flere faser. Du finner for eksempel informasjon i fase 1 om planlegging av å bruke en tjenestekontohaver, og informasjon i fase 2 om forutsetninger og oppsett.

Derfor anbefaler vi at du leser hele artikkelen først, slik at du blir kjent med det som er involvert. Da bør du være godt forberedt på å planlegge og bygge revisjonsløsningen på en iterativ måte.

Når du planlegger å bygge en overvåkingsløsning på leiernivå, planlegger du å bruke tid på følgende fire faser.

Fase 1: Planlegging og beslutninger

Den første fasen fokuserer på planlegging og beslutningstaking. Det er mange krav og prioriteringer å vurdere, så vi anbefaler at du bruker nok tid til å forstå emnene som ble innført i denne delen. Målet er å ta gode beslutninger på forhånd, slik at nedstrømsfasene går greit.

Flytdiagram som beskriver fase 1, som fokuserer på planlegging og beslutninger for å bygge en revisjonsløsning på leiernivå.

Krav og prioriteringer

I den innledende fasen er målet å identifisere hva som er viktigst. Fokuser på det som er viktigst, og hvordan du skal måle innvirkning i organisasjonen. Strebe etter å definere forretningsorienterte krav i stedet for teknologiorienterte krav.

Her er noen spørsmål du bør svare på.

  • Hvilke viktige spørsmål trenger du å svare på? Det er et stort antall overvåkingsdata du kan utforske. Den mest effektive måten å nærme seg revisjon på, er å fokusere på å svare på bestemte spørsmål.
  • Hva er dine innførings- og datakulturmål ? Du har for eksempel kanskje et mål om å øke antall selvbetjente BI-innholdsopprettere i organisasjonen. I så fall må du måle brukeraktiviteter relatert til oppretting, redigering og publisering av innhold.
  • Hvilke umiddelbare risikoer finnes? Det kan for eksempel hende at det har oppstått overdeling av innhold tidligere. Brukeropplæring har siden blitt forbedret, og du ønsker nå å overvåke sikkerhetsinnstillinger og aktiviteter kontinuerlig.
  • Finnes det gjeldende nøkkelindikatorer (KPI-er) eller organisasjonsmål? Kanskje du for eksempel har en organisatorisk KPI som er relatert til digital transformasjon eller blir en mer datadrevet organisasjon. Overvåkingsdata på leiernivå kan hjelpe deg med å måle om Power BI-implementeringen er justert etter disse målene.

Tips

Bekreft revisjonskravene og angi prioriteringer med din overordnede sponsor og Kompetansesenter. Det er fristende å trekke ut overvåkingsdata og begynne å opprette rapporter basert på mange interessante data. Det er imidlertid usannsynlig at du får høy verdi fra overvåkingsløsningen når den ikke er drevet av spørsmål du må svare på og handlinger du har tenkt å utføre.

Hvis du vil ha flere ideer om hvordan du kan bruke overvåkingsdata, kan du se Oversikt over overvåking og overvåking.

Sjekkliste – Når du identifiserer krav og prioriteringer, omfatter viktige beslutninger og handlinger:

  • Identifiser krav: Samle inn og dokumenter de viktigste forretningskravene for å overvåke Power BI-leieren.
  • Prioriteringskrav: Angi prioriteringer for kravene, klassifisere dem som umiddelbare, kortsiktige, mellomlange og langsiktige (backlog).
  • Lag en plan for de umiddelbare prioriteringene: Sett inn en plan for å begynne å samle inn data, slik at den er tilgjengelig når du trenger den.
  • Revurderingskrav regelmessig: Opprett en plan for å revurdere krav regelmessig (for eksempel to ganger per år). Kontroller om overvåkings- og overvåkingsløsningen oppfyller de angitte kravene. Oppdater handlingselementer i planen etter behov.

Databehov

Når du har definert kravene og prioriteringene (beskrevet tidligere), er du klar til å identifisere dataene du trenger. Fire datakategorier dekkes i denne delen.

Mesteparten av dataene du trenger kommer fra administrator-API-ene, som gir et vell av metadata om Power BI-leieren. Hvis du vil ha mer informasjon, kan du se Velge en bruker-API eller administrator-API senere i denne artikkelen.

Brukeraktivitetsdata

Gjør det til din første prioritet å innhente data om brukeraktiviteter. Brukeraktivitetene, som også kalles hendelser eller operasjoner, er nyttige for en rekke ulike formål.

Vanligvis kalles disse dataene aktivitetsloggen eller hendelsesloggen. Teknisk sett finnes det flere måter å skaffe brukeraktivitetsdata på (aktivitetsloggen er én metode). Hvis du vil ha mer informasjon om beslutninger og aktiviteter som er involvert, kan du se Access-brukeraktivitetsdata senere i denne artikkelen.

Her er noen vanlige spørsmål som brukeraktivitetsdata kan svare på.

  • Finne toppbrukere og toppinnhold
    • Hvilket innhold vises oftest og av hvilke brukere?
    • Hva er de daglige, ukentlige og månedlige trendene for visning av innhold?
    • Er rapportvisninger populære opp eller ned?
    • Hvor mange brukere er aktive?
  • Forstå brukervirkemåte
    • Hvilken type sikkerhet brukes oftest (apper, arbeidsområder eller deling per element)?
    • Bruker brukere nettlesere eller mobilapper oftest?
    • Hvilke innholdsopprettere publiserer og oppdaterer innhold mest aktivt?
    • Hvilket innhold publiseres eller oppdateres, når og av hvilke brukere?
  • Identifisere muligheter for brukeropplæring og opplæring
    • Hvem deler (for mye) fra sitt personlige arbeidsområde?
    • Hvem gjør en betydelig mengde eksport?
    • Hvem laster du regelmessig ned innhold?
    • Hvem publiserer mange nye semantiske modeller – tidligere kalt datasett?
    • Hvem bruker abonnementer tungt?
  • Forbedre styrings- og samsvarsarbeidet
    • Når endres leierinnstillingene, og hvilken Power BI-administrator?
    • Hvem startet en prøveversjon av Power BI?
    • Hvilket innhold åpnes av eksterne brukere, hvem, når og hvordan?
    • Hvem lagt til eller oppdatert en følsomhetsetikett?
    • Hvilken prosentandel av rapportvisninger er basert på sertifiserte semantiske modeller?
    • Hvilken prosentandel av semantiske modeller støtter mer enn én rapport?
    • Når opprettes eller oppdateres en gateway eller datakilde, og av hvilken bruker?

Hvis du vil ha mer informasjon om hvordan du bruker disse dataene, kan du se Forstå bruksmønstre.

Viktig

Hvis du ikke allerede trekker ut og lagrer brukeraktivitetsdata, bør du prioritere dette raskt. På et minimum må du sørge for at du trekker ut rådataene og lagrer dem på et sikkert sted. På den måten vil dataene være tilgjengelige når du er klar til å analysere dem. Loggen er tilgjengelig i 30 dager eller 90 dager, avhengig av kilden du bruker.

Hvis du vil ha mer informasjon, kan du se Access-brukeraktivitetsdata senere i denne artikkelen.

Leierbeholdning

Den andre prioriteten er ofte å hente dataene for å opprette en leierbeholdning. Noen ganger kalles det arbeidsområdebeholdning, metadata for arbeidsområde eller tenantmetadata.

En leierbeholdning er et øyeblikksbilde på et gitt tidspunkt. Den beskriver hva som er publisert i leieren. Leierbeholdningen inneholder ikke de faktiske dataene eller de faktiske rapportene. I stedet er det metadata som beskriver alle arbeidsområder og deres elementer (for eksempel semantiske modeller og rapporter).

Her er noen vanlige spørsmål som leierbeholdningen kan svare på.

  • Forstå hvor mye innhold du har og hvor
    • Hvilke arbeidsområder har mest innhold?
    • Hvilken type innhold publiseres i hvert arbeidsområde (spesielt når du skiller rapporteringsarbeidsområder og dataarbeidsområder)?
    • Hvilke avhengigheter finnes mellom elementer (for eksempel dataflyter som støtter mange semantiske modeller, eller en semantisk modell som er en kilde for andre sammensatte modeller)?
    • Hva er dataavstammingen (avhengigheter mellom Power BI-elementer, inkludert eksterne datakilder)?
    • Finnes det frittstående rapporter (som er koblet fra semantisk modell)?
  • Forstå forholdet mellom semantiske modeller og rapporter
    • Hvor mye semantisk gjenbruk av modell forekommer?
    • Er det dupliserte, eller svært like, semantiske modeller?
    • Finnes det muligheter for å konsolidere semantiske modeller?
  • Forstå trender mellom tidspunkter
    • Øker antall rapporter over tid?
    • Øker antall semantiske modeller over tid?
  • Finne ubrukt innhold
    • Hvilke rapporter er ubrukte (eller underutnyttede)?
    • Hvilke semantiske modeller er ubrukte (eller underutnyttede)?
    • Finnes det muligheter for å trekke tilbake innhold?

En leierbeholdning hjelper deg med å bruke gjeldende navn når du analyserer historiske aktiviteter. Øyeblikksbildet av elementene i leieren inneholder navnene på alle elementene på det tidspunktet. Det er nyttig å bruke gjeldende elementnavn for historisk rapportering. Hvis for eksempel en rapport fikk nytt navn for tre måneder siden, registrerer aktivitetsloggen på det tidspunktet det gamle rapportnavnet. Med en riktig definert datamodell kan du bruke den nyeste leierbeholdningen til å finne et element etter gjeldende navn (i stedet for det tidligere navnet). Hvis du vil ha mer informasjon, kan du se Opprette en datamodell senere i denne artikkelen.

Hvis du vil ha mer informasjon om hvordan du bruker en leierbeholdning, kan du se Forstå publisert innhold.

Tips

Du vil ofte bruke kombinering av brukeraktivitetshendelser (beskrevet i forrige del) og leierbeholdningen til å produsere et fullstendig bilde. På den måten forbedrer du verdien av alle dataene.

Siden en leierbeholdning er et øyeblikksbilde på et gitt tidspunkt, må du bestemme hvor ofte metadataene skal trekkes ut og lagres. Et ukentlig øyeblikksbilde er nyttig for å gjøre sammenligninger mellom de to punktene i tid. Hvis du for eksempel vil undersøke sikkerhetsinnstillinger for et arbeidsområde, trenger du det forrige øyeblikksbildet av leierbeholdningen, aktivitetslogghendelsene og det gjeldende øyeblikksbildet av leierbeholdningen.

Det finnes to hovedmåter å bygge en leierbeholdning på. Hvis du vil ha mer informasjon om beslutninger og aktiviteter som er involvert, kan du se Access-leierlagerdata senere i denne artikkelen.

Brukere og grupper data

Etter hvert som de analytiske behovene vokser, vil du sannsynligvis fastslå at du vil inkludere data om brukere og grupper i overvåkingsløsningen fra ende til ende. Hvis du vil hente disse dataene, kan du bruke Microsoft Graph, som er den autoritative kilden for informasjon om Microsoft Entra ID (tidligere kjent som Azure Active Directory)-brukere og -grupper.

Data som hentes fra REST-API-ene for Power BI inkluderer en e-postadresse for å beskrive brukeren eller navnet på en sikkerhetsgruppe. Disse dataene er et øyeblikksbilde på et gitt tidspunkt.

Her er noen vanlige spørsmål som Microsoft Graph kan svare på.

  • Identifisere brukere og grupper
    • Hva er det fullstendige brukernavnet (i tillegg til e-postadressen), avdelingen eller plasseringen som er hentet fra brukerprofilen?
    • Hvem er medlemmene av en sikkerhetsgruppe?
    • Hvem er eieren av en sikkerhetsgruppe (for å administrere medlemmer)?
  • Få mer brukerinformasjon
    • Hvilke lisenser – Power BI Pro eller Power BI Premium per bruker (PPU)– tilordnes til brukere?
    • Hvilke brukere logger seg på oftest?
    • Hvilke brukere har ikke logget på Power Bi-tjeneste nylig?

Advarsel!

Noen eldre metoder (som er omfattende dokumentert på nettet) for tilgang til brukere og grupper data er avskrevet og bør ikke brukes. Når det er mulig, kan du bruke Microsoft Graph som den autoritative kilden til brukere og grupper data.

Hvis du vil ha mer informasjon og anbefalinger om hvordan du får tilgang til data fra Microsoft Graph, kan du se Access-bruker- og gruppere data senere i denne artikkelen.

Sikkerhetsdata

Du kan ha et krav om å utføre regelmessige sikkerhetsrevisjoner.

Her er noen vanlige spørsmål som REST-API-ene for Power BI kan svare på.

Viktig

Til tider refererer denne artikkelen til Power BI Premium eller dets kapasitetsabonnementer (P SKU-er). Vær oppmerksom på at Microsoft for øyeblikket konsoliderer kjøpsalternativer og trekker tilbake Power BI Premium per kapasitet sKU-er. Nye og eksisterende kunder bør vurdere å kjøpe Fabric-kapasitetsabonnementer (F SKU-er) i stedet.

Hvis du vil ha mer informasjon, kan du se Viktige oppdateringer som kommer til Power BI Premium-lisensiering og vanlige spørsmål om Power BI Premium.

Tips

Hvis du vil ha mer informasjon om sikkerhet, kan du se sikkerhetsplanleggingsartiklene .

Disse vanlige spørsmålene er ikke en uttømmende liste. Det finnes et bredt utvalg av REST-API-er for Power BI tilgjengelig. Hvis du vil ha mer informasjon, kan du se Bruke REST-API-ene for Power BI.

Hvis du vil ha mer informasjon om hvordan du bruker API-er for administratorer kontra bruker-API-er (inkludert hvordan det påvirker tillatelser som kreves for brukeren som trekker ut dataene), kan du se Velge en bruker-API eller administrator-API senere i denne artikkelen.

Sjekkliste – Når du identifiserer dataene som er nødvendige for overvåking, omfatter viktige beslutninger og handlinger:

  • Identifiser bestemte databehov for brukeraktivitetsdata: Valider kravene du har samlet inn. Identifiser hvilke overvåkingsdata som er nødvendige for å oppfylle hvert krav for brukeraktivitetsdata.
  • Identifiser spesifikke databehov for leierlagerdata: Valider kravene du har samlet inn. Identifiser hvilke overvåkingsdata som er nødvendige for å kompilere en leierbeholdning.
  • Identifiser bestemte databehov for brukere og grupper data: Valider kravene du har samlet inn. Identifiser hvilke overvåkingsdata som er nødvendige for å oppfylle hvert krav for brukere og grupper data.
  • Identifiser bestemte databehov for sikkerhetsdata: Valider kravene du har samlet inn. Identifiser hvilke overvåkingsdata som er nødvendige for å oppfylle hvert krav for sikkerhetsdata.
  • Bekreft prioriteringer: Kontroller rekkefølgen på prioriteringene, slik at du vet hva du skal utvikle først.
  • Bestem hvor ofte aktiviteter skal registreres: Bestem hvor ofte aktivitetshendelser skal registreres (for eksempel én gang per dag).
  • Bestem hvor ofte øyeblikksbilder skal registreres: Bestem hvilket intervall som skal registrere øyeblikksbildedata, for eksempel en leierbeholdning eller brukerne og grupperer data.

Type overvåkingsløsning

Overvåking på leiernivå utføres enten manuelt eller med automatiserte prosesser.

De fleste nye overvåkingsprosesser starter som en manuell prosess, spesielt under utvikling og under testing. En manuell overvåkingsprosess kan utvikle seg til å bli en automatisert prosess. Ikke alle revisjonsprosesser må imidlertid automatiseres fullstendig.

Manuelle overvåkingsprosesser

Manuell overvåking er avhengig av skript og prosesser som kjøres ved behov av en bruker (vanligvis en Power BI-administrator). Ved behov kjører brukeren spørringer interaktivt for å hente overvåkingsdata.

Manuell overvåking passer best til:

  • Nye skript som utvikles og testes.
  • Av og til trenger engangsovervåking.
  • Utforskende revisjonsbehov.
  • Ikke-essensielle revisjonsprosesser som ikke krever full støtte.

Automatiserte overvåkingsprosesser

Overvåking av data som kreves regelmessig, bør automatiseres. Det trekkes ut og behandles regelmessig, og det kalles en automatisert prosess. Noen ganger kalles det en uovervåket prosess.

Målet med en automatisert prosess er å redusere manuell innsats, redusere risikoen for feil, øke konsistensen og eliminere avhengigheten til en enkeltbruker for å kjøre den.

Automatisert overvåking passer best til:

  • Overvåkingsprosesser som kjører i produksjon.
  • Uovervåkede prosesser som kjører regelmessig.
  • Skript som er fullstendig testet.
  • Viktige overvåkingsprosesser som har andre rapporter (eller andre prosesser) som avhenger av det som en datakilde.
  • Overvåkingsprosesser som er dokumentert og støttet.

Prosesstypen – manuell eller automatisert – kan påvirke hvordan du håndterer godkjenning. En Power BI-administrator kan for eksempel bruke brukergodkjenning for en manuell overvåkingsprosess, men bruke en tjenestekontohaver for en automatisert prosess. Hvis du vil ha mer informasjon, kan du se Finne godkjenningsmetoden senere i denne artikkelen.

Tips

Hvis det er et regelmessig, regelmessig behov for å innhente overvåkingsdata som for øyeblikket håndteres manuelt, bør du vurdere å investere tid for å automatisere dem. Hvis en Power BI-administrator for eksempel kjører et skript manuelt hver dag for å hente data fra Power BI-aktivitetsloggen, er det en risiko for manglende data hvis denne personen skal være syk eller borte på ferie.

Sjekkliste – Når du vurderer hvilken type overvåkingsløsning som skal utvikles, omfatter viktige beslutninger og handlinger:

  • Bestem hovedformålet for hvert nye revisjonskrav: Bestem om du vil bruke en manuell eller automatisert prosess for hvert nye krav. Vurder om denne beslutningen er midlertidig eller permanent.
  • Opprett en plan for hvordan du automatiserer: Når det passer for et bestemt revisjonskrav, oppretter du en plan for hvordan du automatiserer det, når og etter hvem.

Tillatelser og ansvarsområder

På dette tidspunktet bør du ha en klar idé om hva du vil oppnå og dataene du trenger i utgangspunktet. Nå er det på tide å ta avgjørelser om brukertillatelser samt roller og ansvarsområder.

Brukertillatelser

Når du planlegger å bygge en ende-til-ende-overvåkingsløsning, bør du vurdere brukertillatelser for andre brukere som trenger tilgang til dataene. Bestemt må du bestemme hvem som skal få tilgang til og vise overvåkingsdata.

Her er noen hensyn du må ta hensyn til.

Direkte tilgang til overvåkingsdata

Du bør bestemme hvem som kan få tilgang til overvåkingsdataene direkte. Det finnes flere måter å tenke på det på.

  • Hvem bør være en Power BI-administrator? En Power BI-administrator har tilgang til alle tenantmetadata, inkludert administrator-API-er. Hvis du vil ha mer informasjon om hvordan du bestemmer hvem som skal være en Power BI-administrator, kan du se Sikkerhetsplanlegging på leiernivå.
  • Hvem kan bruke en eksisterende tjenestekontohaver? Hvis du vil bruke en tjenestekontohaver (i stedet for brukertillatelser) til å få tilgang til overvåkingsdata, må det oppgis en hemmelighet til autoriserte brukere, slik at de kan utføre passordbasert godkjenning. Tilgang til hemmeligheter (og nøkler) bør kontrolleres svært tett.
  • Må tilgangen kontrolleres tett? Enkelte bransjer med forskriftsmessige krav og samsvarskrav må kontrollere tilgangen tettere enn andre bransjer.
  • Er det store datavolumer for aktivitet? Hvis du vil unngå å nå API-begrensningsgrenser, må du kanskje kontrollere hvem som har tilgang direkte til API-ene som produserer overvåkingsdata. I dette tilfellet er det nyttig å sikre at det ikke er duplikat eller overlappende innsats.
Tilgang til utpakkede rådata

Du bør bestemme hvem som kan vise rådataene som er trukket ut og skrevet til en lagringsplassering. Vanligvis er tilgang til rådata begrenset til administratorer og revisorer. Center of Excellence (COE) kan også kreve tilgang. Hvis du vil ha mer informasjon, kan du se Finne ut hvor overvåkingsdata skal lagres senere i denne artikkelen.

Tilgang til kuraterte analytiske data

Du bør bestemme hvem som kan vise de kuraterte og transformerte dataene som er klare for analyse. Disse dataene bør alltid gjøres tilgjengelige for administratorer og revisorer. Noen ganger gjøres en datamodell tilgjengelig for andre brukere i organisasjonen, spesielt når du oppretter en semantisk Power BI-modell med sikkerhet på radnivå. Hvis du vil ha mer informasjon, kan du se Planlegge å opprette kuraterte data senere i denne artikkelen.

Roller og ansvar

Når du har bestemt deg for hvordan brukertillatelser fungerer, er du i en god posisjon til å begynne å tenke på roller og ansvarsområder. Vi anbefaler at du involverer de riktige personene tidlig, spesielt når flere utviklere eller team vil være involvert i å bygge den ende-til-ende overvåkingsløsningen.

Bestem hvilke brukere eller team som skal være ansvarlige for følgende aktiviteter.

Rolle Ansvarstyper Rolle utføres vanligvis av
Kommunisere til interessenter Kommunikasjonsaktiviteter og krav som samles inn. COE i samarbeid med IT. Kan også inkludere utvalgte personer fra viktige forretningsenheter.
Bestem prioriteringer, og gi veiledning om krav Beslutningsaktiviteter knyttet til ende-til-ende-overvåkingsløsningen, inkludert hvordan du oppfyller kravene. Teamet som fører tilsyn med Power BI i organisasjonen, for eksempel COE. Den utøvende sponsoren eller en styringskomité for datastyring kan bli involvert for å ta kritiske beslutninger eller eskalere problemer.
Trekke ut og lagre rådataene Oppretting av skript og prosesser for å få tilgang til og trekke ut dataene. Innebærer også å skrive rådata til lagring. Dataingeniører, vanligvis i IT og i samarbeid med COE.
Opprett de kuraterte dataene Datarensing, transformasjon og oppretting av de kuraterte dataene i utforming av stjerneskjema. Dataingeniører, vanligvis i IT og i samarbeid med COE.
Opprette en datamodell Oppretting av en analytisk datamodell, basert på de kuraterte dataene. Power BI-innholdsoppretter(er), vanligvis i IT eller coe.
Opprett analyserapporter Oppretting av rapporter for å analysere de kuraterte dataene. Pågående endringer i rapporter basert på nye krav og når nye overvåkingsdata blir tilgjengelige. Power BI-rapportoppretter(er), vanligvis i IT eller coe.
Analyser dataene og handle etter resultatene Analyser dataene og handle som svar på overvåkingsdataene. Teamet som fører tilsyn med Power BI i organisasjonen, vanligvis coe. Kan også inkludere andre team avhengig av revisjonsresultatene og handlingen. Andre team kan inkludere sikkerhet, samsvar, juridisk, risikostyring eller endringsadministrasjon.
Test og valider Test for å sikre at overvåkingskravene oppfylles og at dataene som presenteres, er nøyaktige. Power BI-innholdsopprettere, i samarbeid med teamet som fører tilsyn med Power BI i organisasjonen.
Sikre dataene Angi og administrer sikkerhet for hvert lagringslag, inkludert rådataene og de kuraterte dataene. Administrer tilgang til semantiske modeller som er opprettet for analyse av dataene. Systemansvarlig for systemet som lagrer dataene, i samarbeid med teamet som fører tilsyn med Power BI i organisasjonen.
Planlegging og automatisering Operasjonaliser en løsning og planlegg prosessen med det ønskede verktøyet. Dataingeniører, vanligvis i IT og i samarbeid med COE.
Støtte løsningen Overvåk overvåkingsløsningen, inkludert jobbkjøringer, feil og støtte for tekniske problemer. Teamet som håndterer systemstøtte for Power BI, som vanligvis er IT eller COE.

Mange av rollene og ansvarsoppgavene ovenfor kan konsolideres hvis de skal utføres av samme team eller samme person. Power BI-administratorene kan for eksempel utføre noen av disse rollene.

Det er også mulig at ulike personer utfører forskjellige roller, avhengig av omstendighetene. Handlinger vil være kontekstavhengige avhengig av overvåkingsdataene og den foreslåtte handlingen.

Vurder flere eksempler.

  • Eksempel 1: Overvåkingsdataene viser at enkelte brukere ofte eksporterer data til Excel. Handling utført: COE kontakter bestemte brukere for å forstå deres behov og lære dem bedre alternativer.
  • Eksempel 2: Overvåkingsdataene viser ekstern brukertilgang på en uventet måte. Handlinger som utføres: En IT-systemansvarlig oppdaterer de relevante Microsoft Entra ID-innstillingene for ekstern brukertilgang. Power BI-administratoren oppdaterer leierinnstillingen relatert til ekstern brukertilgang. COE oppdaterer dokumentasjon og opplæring for innholdsopprettere som administrerer sikkerhet. Hvis du vil ha mer informasjon, kan du se Strategi for eksterne brukere.
  • Eksempel 3: Overvåkingsdataene viser at flere datamodeller definerer samme mål på en annen måte (tilgjengelig fra metadataskannings-API-er, hvis de tillates av de detaljerte tenantinnstillingene for metadata). Handling utført: Datastyringskomiteen starter et prosjekt for å definere felles definisjoner. COE oppdaterer dokumentasjon og opplæring for innholdsopprettere som oppretter datamodeller. Coe fungerer også med innholdsopprettere for å oppdatere modellene etter behov. Hvis du vil ha mer informasjon om hvordan du henter detaljerte metadata, kan du se Access-leierlagerdata senere i denne artikkelen.

Merk

Konfigurasjonen av datautpakkingsprosesser er vanligvis en engangsinnsats med sporadiske forbedringer og feilsøking. Analyse og virkende på dataene er en kontinuerlig innsats som krever kontinuerlig innsats regelmessig.

Sjekkliste – Når du vurderer tillatelser og ansvarsområder, omfatter viktige beslutninger og handlinger:

  • Identifiser hvilke team som er involvert: Bestem hvilke team som skal være involvert i ende-til-ende-oppretting og støtte av revisjonsløsningen.
  • Bestem brukertillatelser: Bestem hvordan brukertillatelser skal konfigureres for tilgang til overvåkingsdata. Opprett dokumentasjon over viktige beslutninger for senere referanse.
  • Bestem roller og ansvarsområder: Sørg for at forventningene er klare for hvem som gjør hva, spesielt når flere team er involvert. Opprett dokumentasjon for roller og ansvarsområder, som inkluderer forventede handlinger.
  • Tilordne roller og ansvarsområder: Tilordne bestemte roller og ansvarsområder til bestemte personer eller team. Oppdater individuelle stillingsbeskrivelser med Personaladministrasjon når det er aktuelt.
  • Opprett en opplæringsplan: Opprett en plan for opplæringspersonell når de krever nye ferdigheter.
  • Opprett en plan for kryssopplæring: Sørg for at kryssopplæring og sikkerhetskopier er på plass for viktige roller.

Tekniske beslutninger

Når du planlegger en overvåkingsløsning på leiernivå, må du ta noen viktige tekniske beslutninger. Hvis du vil forbedre konsistensen, unngå å arbeide på nytt og forbedre sikkerheten, anbefaler vi at du tar disse beslutningene så tidlig som mulig.

Den første planleggingsfasen innebærer å ta følgende beslutninger.

Velg en teknologi for å få tilgang til overvåkingsdata

Det første du må bestemme deg for, er hvordan du får tilgang til overvåkingsdataene.

Den enkleste måten å komme i gang på, er å bruke de forhåndsbygde rapportene som er tilgjengelige i arbeidsområdet for administratorovervåking.

Når du trenger å få tilgang til dataene direkte og bygge din egen løsning, bruker du en API (programgrensesnitt). API-er er utformet for å utveksle data via Internett. Power BI REST API-er støtter forespørsler om data ved hjelp av HTTP-protokollen. Alle språk eller verktøy kan aktivere REST-API-er for Power BI når de kan sende en HTTP-forespørsel og motta et JSON-svar.

Tips

PowerShell-cmdletene bruker REST-API-ene for Power BI til å få tilgang til overvåkingsdataene. Hvis du vil ha mer informasjon, kan du se Velg API-er eller PowerShell-cmdleter senere i denne artikkelen.

Denne delen fokuserer på teknologivalget ditt. Hvis du vil ha vurderinger om kilden for tilgang til bestemte typer overvåkingsdata, kan du se Datakildebeslutninger senere i denne artikkelen.

Plattformalternativer

Det finnes mange forskjellige måter å få tilgang til overvåkingsdata på. Avhengig av teknologien du velger, kan du lene deg mot et foretrukket språk. Du må kanskje også ta en bestemt beslutning om hvordan du planlegger kjøringen av skriptene. Teknologier varierer mye i læringskurven og enkel å komme i gang.

Her er noen teknologier du kan bruke til å hente data ved hjelp av REST-API-ene for Power BI.

Teknologi Godt valg for manuelle overvåkingsprosesser Godt valg for automatiserte revisjonsprosesser
Arbeidsområde for administratorovervåking Arbeidsområde for administratorovervåking er et godt valg for manuelle overvåkingsprosesser.
Prøv det Prøv det er et godt valg for manuelle overvåkingsprosesser.
PowerShell PowerShell er et godt valg for manuelle overvåkingsprosesser. PowerShell er et godt valg for automatiserte revisjonsprosesser.
Power BI Desktop Power BI Desktop er et godt valg for manuelle overvåkingsprosesser.
Power Automate Power Automate er et godt valg for automatiserte revisjonsprosesser.
Foretrukket Azure-tjeneste Foretrukket Azure-tjeneste er et godt valg for automatiserte revisjonsprosesser.
Foretrukket verktøy/språk Foretrukket verktøy/språk er et godt valg for manuelle overvåkingsprosesser. Foretrukket verktøy/språk er et godt valg for automatiserte overvåkingsprosesser.
Søk i overvåkingslogg for Microsoft Purview Søk i overvåkingsloggen for Microsoft Purview er et godt valg for manuelle overvåkingsprosesser.
Defender for Cloud Apps Defender for Cloud Apps er et godt valg for manuelle overvåkingsprosesser.
Microsoft Sentinel Microsoft Sentinel er et godt valg for automatiserte revisjonsprosesser.

Resten av denne inndelingen gir en kort innføring i hvert av alternativene som presenteres i tabellen.

Arbeidsområde for administratorovervåking

Arbeidsområdet for administratorovervåking inneholder forhåndsdefinerte rapporter og semantiske modeller i Power Bi-tjeneste. Det er en praktisk måte for Fabric-administratorer og globale administratorer å vise nylige overvåkingsdata og hjelpe dem med å forstå brukeraktiviteter.

Prøv det i API-dokumentasjon

Prøv det er et interaktivt verktøy som lar deg oppleve REST-API-en for Power BI direkte i Microsoft-dokumentasjonen. Det er en enkel måte å utforske API-ene på, fordi det ikke krever andre verktøy eller noe oppsett på maskinen.

Du kan bruke Try-it til å:

  • Send en forespørsel til en API manuelt for å avgjøre om den returnerer ønsket informasjon.
  • Lær hvordan nettadressen er konstruert før du skriver et skript.
  • Kontroller dataene på en uformell måte.

Merk

Du må være en lisensiert og godkjent Power BI-bruker for å kunne bruke Try-it. Den følger standard tillatelsesmodell, noe som betyr at bruker-API-er er avhengige av brukertillatelser, og administrator-API-ene krever administratortillatelser for Power BI. Du kan ikke godkjenne med Try-it ved hjelp av en tjenestekontohaver.

Fordi det er interaktivt, er Prøv det best egnet til læring, utforskning og nye manuelle revisjonsprosesser.

PowerShell og Azure Cloud Shell

Du kan opprette og kjøre PowerShell-skript på flere måter.

Her er flere vanlige alternativer.

  • Visual Studio Code: Et moderne, lett kildekoderedigeringsprogram. Det er et fritt tilgjengelig åpen kildekode-verktøy som støttes på flere plattformer, inkludert Windows, macOS og Linux. Du kan bruke Visual Studio Code med mange språk, inkludert PowerShell (ved hjelp av PowerShell-utvidelsen).
  • Azure Data Studio: Et verktøy for å opprette skript og notatblokker. Den er bygget oppå Visual Studio Code. Azure Data Studio er tilgjengelig uavhengig, eller med SQL Server Management Studio (SSMS). Det finnes mange utvidelser, inkludert en utvidelse for PowerShell.
  • Azure Cloud Shell: Et alternativ til å arbeide med PowerShell lokalt. Du kan få tilgang til Azure Cloud Shell fra en nettleser.
  • Azure Functions: Et alternativ til å arbeide med PowerShell lokalt. Azure Functions er en Azure-tjeneste som lar deg skrive og kjøre kode i et serverløst miljø. PowerShell er ett av flere språk den støtter.

Viktig

Vi anbefaler at du bruker den nyeste versjonen av PowerShell (PowerShell Core) for alt nytt utviklingsarbeid. Du bør slutte å bruke Windows PowerShell (som ikke kan kjøre PowerShell Core) og i stedet bruke et av de moderne koderedigeringsprogrammene som støtter PowerShell Core. Vær forsiktig når du refererer til mange eksempler på nettet som bruker Windows PowerShell (versjon 5.1), fordi de kanskje ikke bruker de nyeste (og bedre) kodetilnærmingene.

Du kan bruke PowerShell på flere forskjellige måter. Hvis du vil ha mer informasjon om denne tekniske beslutningen, kan du se Velge API-er eller PowerShell-cmdleter senere i denne artikkelen.

Det finnes mange nettbaserte ressurser tilgjengelig for bruk av PowerShell, og det er ofte mulig å finne erfarne utviklere som kan opprette og administrere PowerShell-løsninger. PowerShell er et godt valg for å opprette både manuelle og automatiserte revisjonsprosesser.

Power BI Desktop

Siden Power BI Desktop kan koble til API-er, kan du bli fristet til å bruke det til å bygge overvåkingsløsningen. Det er imidlertid noen betydelige ulemper og kompleksiteter.

  • Akkumuleringslogg: Fordi Power BI-aktivitetsloggen inneholder opptil 30 dager med data, innebærer oppretting av hele overvåkingsløsningen å samle et sett med filer over tid som lagrer alle historiske hendelser. Akkumulering av historiske filer er enklere å utføre med andre verktøy.
  • Håndtere legitimasjon og nøkler på en sikker måte: Mange løsninger du finner på nettet fra fellesskapsbloggere, er ikke sikre fordi de har hardkodede legitimasjoner og nøkler i ren tekst i Power Query-spørringer. Selv om denne fremgangsmåten er enkel, anbefales det ikke fordi alle som henter Power BI Desktop-filen, kan lese verdiene. Du kan ikke lagre passordet (når du bruker brukergodkjenning) eller hemmeligheten (når du bruker en tjenestekontohaver) på en sikker måte i Power BI Desktop med mindre du:
    • Bruk en egendefinert kobling som ble utviklet med Power Query SDK. En egendefinert kobling kan for eksempel lese konfidensielle verdier fra Azure Key Vault eller en annen tjeneste som lagrer den krypterte verdien på en sikker måte. Det finnes også ulike egendefinerte koblingsalternativer som er tilgjengelige fra det globale Power BI-fellesskapet.
    • Bruk alternativet ApiKeyName, som fungerer bra i Power BI Desktop. Det er imidlertid ikke mulig å lagre nøkkelverdien i Power Bi-tjeneste.
  • Typer forespørsler: Du kan støte på noen begrensninger for hva du kan kjøre i Power BI Desktop. Power Query støtter for eksempel ikke alle typer API-forespørsler. Bare GET- og POST-forespørsler støttes for eksempel når du bruker web.contents-funksjonen . Når det gjelder overvåking, sender du vanligvis GET-forespørsler.
  • Mulighet til å oppdatere: Du må følge bestemte utviklingsmønstre for Power Query for å kunne oppdatere en semantisk modell i Power Bi-tjeneste. Alternativet må for eksempel være til stede når du bruker Web.Contents, RelativePath slik at Power BI kan bekrefte plasseringen av en datakilde på riktig måte uten å generere en feil i Power Bi-tjeneste.

I de fleste tilfeller anbefaler vi at du bare bruker Power BI Desktop til to formål. Du bør bruke den til å:

  • Bygg datamodellen basert på eksisterende kuraterte data (i stedet for å bruke den til å trekke ut overvåkingsdataene).
  • Opprett analytiske rapporter basert på datamodellen.
Power Automate

Du kan bruke Power Automate med Power BI på mange måter. Når det gjelder overvåking, kan du bruke Power Automate til å sende forespørsler til REST-API-ene for Power BI og deretter lagre de utpakkede dataene på ønsket sted.

Tips

Hvis du vil sende forespørsler til REST-API-ene for Power BI, kan du bruke en egendefinert kobling for Power Automate til å godkjenne og trekke ut overvåkingsdataene på en sikker måte. Du kan også bruke Azure Key Vault til å referere til et passord eller en hemmelighet. Begge alternativene er bedre enn å lagre passord og hemmeligheter i ren tekst i Power Automate-flyten.

Hvis du vil ha andre ideer om måter å bruke Power Automate på, kan du søke etter Power BI i Power Automate-malene.

Foretrukket Azure-tjeneste

Det finnes flere Azure-tjenester som kan sende forespørsler til REST-API-ene for Power BI. Du kan bruke din foretrukne Azure-tjeneste, for eksempel:

I de fleste tilfeller kan du kombinere en databehandlingstjeneste som håndterer logikken for datauthentingen med en lagringstjeneste som lagrer rådataene (og kuraterte data, når det er aktuelt). Vurderinger for å ta tekniske arkitekturbeslutninger er beskrevet senere i denne artikkelen.

Foretrukket verktøy og/eller språk

Du kan bruke det foretrukne verktøyet og det foretrukne språket til å sende forespørsler til REST-API-ene for Power BI. Det er en god tilnærming når teamet ditt har ekspertise med et bestemt verktøy eller språk, for eksempel:

  • Python
  • C# på .NET Framework. Du kan også bruke Power BI .NET SDK, som fungerer som en wrapper på toppen av REST-API-ene for Power BI for å forenkle enkelte prosesser og øke produktiviteten.
  • JavaScript

Microsoft Purview-samsvarsportal (tidligere samsvarssenteret for Microsoft 365) inneholder et brukergrensesnitt som lar deg vise og søke i overvåkingsloggene. De enhetlige overvåkingsloggene inkluderer Power BI og alle andre tjenester som støtter enhetlige overvåkingslogger for Microsoft 365.

Dataene som er registrert i den enhetlige overvåkingsloggen, er nøyaktig de samme dataene som finnes i aktivitetsloggen for Power BI. Når du gjør et søk i overvåkingsloggen i Microsoft Purview-samsvarsportal, legges forespørselen til i køen. Det kan ta noen minutter (eller lengre, avhengig av datavolumet) for at dataene skal være klare.

Her er noen vanlige måter å bruke søkeverktøyet for overvåkingslogg på. Du kan gjøre følgende:

  • Velg Power BI-arbeidsbelastningen for å vise hendelser for en rekke datoer.
  • Se etter én eller flere spesifikke aktiviteter, for eksempel:
    • Slettet Power BI-rapport
    • Lagt til administratortilgang i et personlig arbeidsområde i Power BI
  • Vis aktiviteter for én eller flere brukere.

For administratorer med tilstrekkelige tillatelser er søkeverktøyet for overvåkingslogg i Microsoft Purview-samsvarsportal et godt alternativ for manuelle overvåkingsprosesser. Hvis du vil ha mer informasjon, kan du se Microsoft Purview-samsvarsportal senere i denne artikkelen.

Brukergrensesnittet Defender for Cloud Apps

Defender for Cloud Apps er tilgjengelig for administratorer i Microsoft Defender XDR (Microsoft 365-portalen). Det inkluderer et brukergrensesnitt for å vise og søke i aktivitetslogger for ulike skytjenester, inkludert Power BI. Den viser de samme logghendelsene som kommer fra Microsoft Purview-samsvarsportal, i tillegg til andre hendelser som brukerpåloggingsaktivitet fra Microsoft Entra ID.

Overvåkingslogggrensesnittet i Defender for Cloud Apps er et godt alternativ for manuelle overvåkingsprosesser. Hvis du vil ha mer informasjon, kan du se Defender for Cloud Apps senere i denne artikkelen.

Microsoft Sentinel og KQL

Microsoft Sentinel er en Azure-tjeneste som lar deg samle inn, oppdage, undersøke og svare på sikkerhetshendelser og trusler. Power BI kan konfigureres i Microsoft Sentinel som en datakobling, slik at overvåkingslogger strømmes fra Power BI til Microsoft Sentinel Azure Log Analytics (som er en komponent i Azure Monitor-tjenesten ). Du kan bruke Kusto Query Language (KQL) til å analysere aktivitetslogghendelsene som er lagret i Azure Log Analytics.

Bruk av KQL til å søke i dataene i Azure Monitor er et godt alternativ for å vise en del av overvåkingsloggen. Det er også et godt alternativ for manuelle overvåkingsprosesser. Hvis du vil ha mer informasjon, kan du se Microsoft Sentinel senere i denne artikkelen.

Plattformhensyn

Her er noen vurderinger for hvordan du kan få tilgang til overvåkingsdata.

  • Implementerer du en manuell eller automatisert revisjonsprosess? Enkelte verktøy justeres sterkt med manuell behandling eller automatisert behandling. En bruker kjører for eksempel alltid Try-it-funksjonaliteten interaktivt, så den passer bare til manuelle overvåkingsprosesser.
  • Hvordan vil du godkjenne? Ikke alle alternativer støtter alle godkjenningsalternativer. Try-it-funksjonaliteten støtter for eksempel bare brukergodkjenning.
  • Hvordan lagrer du legitimasjonen på en sikker måte? Ulike teknologier har ulike alternativer for lagring av legitimasjon. Hvis du vil ha mer informasjon, kan du se Finne godkjenningsmetoden senere i denne artikkelen.
  • Hvilken teknologi er teamet ditt allerede dyktig med? Hvis det finnes et verktøy som teamet foretrekker og er komfortabel med å bruke, kan du starte der.
  • Hva er teamet ditt i stand til å støtte? Hvis et annet team støtter den distribuerte løsningen, bør du vurdere om teamet er i stand til å støtte den tilstrekkelig. Tenk også på at interne team kan støtte utvikling som er gjort av konsulenter.
  • Hvilket verktøy har du godkjenning til å bruke? Enkelte verktøy og teknologier kan kreve godkjenning. Det kan skyldes kostnadene. Det kan også skyldes IT-sikkerhetspolicyer.
  • Hva er din preferanse for planlegging? Noen teknologier tar avgjørelsen for deg. Andre ganger vil det være en annen beslutning du må ta. Hvis du for eksempel velger å skrive PowerShell-skript, finnes det ulike måter du kan planlegge å kjøre dem på. Hvis du derimot bruker en skytjeneste som Azure Data Factory, er planlegging innebygd.

Vi anbefaler at du går gjennom resten av denne artikkelen før du velger en teknologi for å få tilgang til overvåkingsdata.

Sjekkliste – Når du bestemmer deg for hvilken teknologi som skal brukes til å få tilgang til overvåkingsdata, omfatter viktige beslutninger og handlinger:

  • Diskuter med IT-personalet: Snakk med IT-teamene for å finne ut om det finnes bestemte verktøy som er godkjent eller foretrukket.
  • Utforsk alternativer med et lite konseptbevis (POC): Gjør noen eksperimenteringer med en teknisk poc. Fokuser først på læring. Deretter fokuserer du på din beslutning om hva du skal bruke fremover.

Fastslå godkjenningsmetoden

Hvordan du planlegger å konfigurere godkjenning er en kritisk beslutning. Det er ofte en av de vanskeligste aspektene når du kommer i gang med overvåking og overvåking. Du bør nøye vurdere tilgjengelige alternativer for å ta en informert beslutning.

Viktig

Ta kontakt med IT- og sikkerhetsteamene dine om denne saken. Ta deg tid til å lære det grunnleggende om hvordan sikkerhet i Microsoft Entra ID fungerer.

Ikke alle API-er på Internett krever godkjenning. Alle REST-API-ene for Power BI krever imidlertid godkjenning. Når du får tilgang til overvåkingsdata på leiernivå, administreres godkjenningsprosessen av Microsofts identitetsplattform. Det er en videreutvikling av Microsoft Entra-identitetstjenesten som er bygget på bransjestandardprotokoller.

Tips

Den Microsofts identitetsplattform ordlisten over termer er en ressurs som hjelper deg med å bli kjent med de grunnleggende begrepene.

Før du henter overvåkingsdata, må du først godkjenne, som kalles pålogging. Begrepene godkjenning og godkjenning er separate, men likevel relaterte. En godkjenningsprosess bekrefter identiteten til hvem som sender forespørselen. En godkjenningsprosess gir (eller nekter) tilgang til et system eller en ressurs ved å bekrefte hva brukeren eller tjenestekontohaveren har tillatelse til å gjøre.

Når en bruker eller tjenestekontohaver godkjenner, utstedes et Microsoft Entra-tilgangstoken til en ressursserver, for eksempel en REST-API for Power BI eller en Microsoft Graph-API. Som standard utløper et tilgangstoken etter én time. Et oppdateringstoken kan bes om nødvendig.

Det finnes to typer tilgangstokener:

  • Brukertokener: Utstedt på vegne av en bruker med en kjent identitet.
  • App-only-tokener: Utstedt på vegne av et Microsoft Entra-program (tjenestekontohaver).

Hvis du vil ha mer informasjon, kan du se Program- og tjenestekontohaverobjekter i Microsoft Entra ID.

Merk

Et Microsoft Entra-program er en identitetskonfigurasjon som gjør det mulig for en automatisert prosess å integrere med Microsoft Entra ID. I denne artikkelen kalles det en appregistrering. Termtjenestekontohaveren brukes også ofte i denne artikkelen. Disse termene beskrives mer detaljert senere i denne delen.

Tips

Den enkleste måten å godkjenne på, er å bruke Koble til-PowerBIServiceAccount-cmdleten fra Power BI Management-modulen. Du kan se andre godkjenningsrelaterte cmdleter i artikler og blogginnlegg på nettet. Det finnes Login-PowerBI for eksempel cmdleter og Login-PowerBIServiceAccount cmdleter, som er aliaser for Connect-PowerBIServiceAccount cmdlet. Det finnes også cmdleten Disconnect-PowerBIServiceAccount som du kan bruke til å logge av eksplisitt på slutten av en prosess.

Tabellen nedenfor beskriver de to godkjenningsalternativene.

Godkjenningstype Beskrivelse Beregnet for Godt valg for manuelle overvåkingsprosesser Godt valg for automatiserte revisjonsprosesser
Brukergodkjenning Logg på som bruker ved hjelp av brukerhovednavnet (e-postadressen) og et passord. Sporadisk, interaktiv bruk Brukergodkjenning er et godt valg for manuelle overvåkingsprosesser
Godkjenning av tjenestekontohaver Logg på som tjenestekontohaver ved hjelp av en hemmelig (nøkkel) som er tilordnet til en appregistrering. Pågående, planlagte, uovervåkede operasjoner Godkjenning av tjenestekontohaver er et godt valg for automatiserte overvåkingsprosesser

Hvert godkjenningsalternativ beskrives mer detaljert i avsnittet nedenfor.

Brukergodkjenning

Brukergodkjenning er nyttig i følgende situasjoner.

  • Manuelle overvåkingsprosesser: Du vil kjøre et skript ved hjelp av brukertillatelsene dine. Tillatelser kan være på ett av to nivåer, avhengig av typen API-forespørsel:
    • Administratortillatelser for administrator-API-er: Du må bruke Administratortillatelsene for Power BI til å sende en forespørsel til en administrator-API.
    • Brukertillatelser for bruker-API-er: Du må bruke Power BI-brukertillatelsene til å sende en forespørsel til en bruker-API. Hvis du vil ha mer informasjon, kan du se Velge en bruker-API eller administrator-API.
  • Interaktiv pålogging: Du vil logge deg på interaktivt, noe som krever at du skriver inn e-postadressen og passordet. Du må for eksempel logge deg på interaktivt for å bruke Try-it-opplevelsen , som finnes i Microsoft API-dokumentasjon.
  • Spor hvem som fikk tilgang til metadata for leier: Når individuelle brukere og administratorer sender API-forespørsler, kan det være lurt å overvåke hvem disse personene er. Når du godkjenner med en tjenestekontohaver (beskrevet neste), er bruker-ID-en som registreres av aktivitetsloggen, program-ID-en. Hvis flere administratorer godkjenner med samme tjenestekontohaver, kan det være vanskelig å vite hvilken administrator som har fått tilgang til dataene.
  • Delt administratorkonto: Noen IT-team bruker en delt administratorkonto. Avhengig av hvordan det implementeres og kontrolleres, er det kanskje ikke en anbefalt fremgangsmåte. I stedet for en delt konto bør du vurdere å bruke Microsoft Entra Privileged Identity Management (PIM), som kan gi sporadiske og midlertidige Administratorrettigheter for Power BI for en bruker.
  • API-er som bare støtter brukergodkjenning: Noen ganger må du kanskje bruke en API som ikke støtter godkjenning av en tjenestekontohaver. I dokumentasjonen bemerker hver API om en tjenestekontohaver kan kalle det.

Viktig

Når det er mulig, anbefaler vi at du bruker tjenestekontohavergodkjenning for automatiserte prosesser.

Godkjenning av tjenestekontohaver

De fleste organisasjoner har én Microsoft Entra-leier, så vilkårene for appregistrering og tjenestekontohaver har en tendens til å brukes om hverandre. Når du registrerer en Microsoft Entra-app, finnes det to komponenter.

  • Appregistrering: En appregistrering er globalt unik. Det er den globale definisjonen av en registrert Microsoft Entra-app som kan brukes av flere leiere. En appregistrering kalles også et klientprogram eller en aktør. Vanligvis innebærer termklientprogrammet en brukermaskin. Det er imidlertid ikke situasjonen for appregistreringer. I Azure-portalen finner du Microsoft Entra-programmer på appregistreringssiden i Microsoft Entra ID.
  • Tjenestekontohaver: En tjenestekontohaver er den lokale representasjonen av appregistreringen for bruk i den bestemte leieren. Tjenestekontohaveren er avledet fra den registrerte Microsoft Entra-appen. For organisasjoner med flere Microsoft Entra-leiere kan den samme appregistreringen refereres til av mer enn én tjenestekontohaver. I Azure-portalen finner du tjenestekontohavere på Enterprise-programsiden i Microsoft Entra ID.

Fordi tjenestekontohaveren er den lokale representasjonen, er godkjenning av termtjenestekontohaver den vanligste måten å referere til pålogginger på.

Tips

Microsoft Entra-administratoren kan fortelle deg hvem som har tillatelse til å opprette, og samtykke til, en appregistrering i organisasjonen.

Godkjenning av tjenestekontohaver er nyttig i følgende situasjoner.

  • Automatiserte overvåkingsprosesser: Du vil kjøre en uovervåket prosess etter en tidsplan.
  • Du trenger ikke å logge på Power Bi-tjeneste: Du trenger bare å koble til og trekke ut data. En tjenestekontohaver kan ikke logge på Power Bi-tjeneste.
  • Delt tilgang til data: Du (personlig) er ikke en Power BI-administrator, men du har tillatelse til å bruke en tjenestekontohaver. Tjenestekontohaveren har tillatelse til å kjøre administrator-API-er for å hente data på leiernivå (eller andre bestemte tillatelser).
  • Bruk av flere administratorer: Du vil tillate at flere administratorer eller brukere bruker samme tjenestekontohaver.
  • Tekniske blokkeringer: Det finnes en teknisk blokkering som hindrer bruk av brukergodkjenning. Vanlige tekniske blokkeringer inkluderer:
    • Godkjenning med flere faktorer (MFA): Automatiserte overvåkingsprosesser (som kjører uten tilsyn) kan ikke godkjennes ved hjelp av en brukerkonto når godkjenning med flere faktorer er aktivert.
    • Synkronisering av passord-hash: Microsoft Entra ID krever synkronisering av passord-hash for at en brukerkonto skal godkjennes. Noen ganger kan IT eller et cybersikkerhetsteam deaktivere denne funksjonaliteten.
Appregistreringsformål og navnekonvensjon

Hver appregistrering bør ha et klart navn som beskriver formålet og målgruppen (hvem som kan bruke appregistreringen).

Vurder å implementere en navnekonvensjon, for eksempel: <Arbeidsbelastning> – <formål> – <målgruppe> – <objekttype>

Her er delene av navnekonvensjonen.

  • Arbeidsbelastning: Vanligvis tilsvarer en datakilde (for eksempel Power BI-data eller Microsoft Graph-data).
  • Formål: Ligner på tillatelsesnivået (for eksempel Lese kontra Skrivebeskyttet). Som beskrevet nedenfor, hjelper formålet deg med å følge prinsippet om minst mulig tilgang når du oppretter separate appregistreringer som bare kan lese data.
  • Målgruppe: Valgfritt. Avhengig av arbeidsbelastningen og formålet, kan målgruppen bestemme de tiltenkte brukerne av appregistreringen.
  • Objekttype:EntraApp er inkludert for klarhet.

Navnekonvensjonen kan være mer spesifikk når du har flere leiere eller flere miljøer (for eksempel utvikling og produksjon).

Tabellen nedenfor viser eksempler på appregistreringer som kan brukes til å trekke ut overvåkingsdata på leiernivå:

Appregistreringsnavn Formål Målgruppen
PowerBIData-Read-AdminAPIs-EntraApp Trekk ut metadata for hele tenanten for overvåking og administrasjon av Power BI. Administrator-API-er er alltid skrivebeskyttet og har kanskje ikke tillatelser gitt i Microsoft Entra ID (bare Power BI-leierinnstilling). Power BI-administratorer og Kompetansesenteret
PowerBIData-ReadWrite-PowerBIAdministrators-EntraApp Administrer Power BI-leieren. Krever lese-/skrivetillatelser for å opprette eller oppdatere ressurser. Power BI-administratorer og Kompetansesenteret
GraphData-Read-PowerBIAdministrators-EntraApp Trekk ut brukere og grupper data for overvåking og administrasjon av Power BI. Krever lesetillatelser. Power BI-administratorer og Kompetansesenteret

Administrasjon av flere appregistreringer for ulike formål innebærer mer innsats. Du kan imidlertid dra nytte av flere fordeler.

  • Se hva appregistreringen er ment å brukes til, og hvorfor: Når du ser klient-ID-en fra appregistreringen vises i overvåkingsdataene, får du et inntrykk av hva den ble brukt til og hvorfor. Det er en betydelig fordel ved å opprette separate appregistreringer (i stedet for å bruke bare én til alle formål).
  • Se hvem appregistreringen er ment å brukes av: Når du ser klient-ID-en fra appregistreringen vises i overvåkingsdataene, får du en idé om hvem som brukte den.
  • Unngå overopprettelse av tillatelser: Du kan følge prinsippet om minst mulig rettighet ved å gi separate appregistreringer til ulike sett med personer som har ulike behov. Du kan unngå å overbestille tillatelser ved å bruke en skrivebeskyttet appregistrering når skrivetillatelser ikke er nødvendige. Du kan for eksempel ha noen svært dyktige selvbetjente brukere som ønsker å samle inn data om semantiske modeller. de trenger tilgang til en tjenestekontohaver med lesetillatelse . Mens det kan være satellittmedlemmer av Center of Excellence som arbeider for finansteamet som programmatisk administrerer semantiske modeller; de trenger tilgang til en tjenestekontohaver med skrivetillatelse .
  • Vit hvem som skal være i besittelse av hemmeligheten: Hemmeligheten bak hver appregistrering bør bare deles med personene som trenger det. Når hemmeligheten roterer (beskrevet senere i denne delen), er virkningen mindre når du bruker separate appregistreringer for ulike behov. Det er nyttig når du trenger å rotere hemmeligheten fordi en bruker forlater organisasjonen eller endrer roller.
Appregistreringstillatelser

Det finnes to hovedmåter en appregistrering kan få tilgang til data og ressurser på. Det innebærer tillatelser og samtykke.

  • App-only-tillatelser: Tilgang og godkjenning håndteres av tjenestekontohaveren uten en pålogget bruker. Denne godkjenningsmetoden er nyttig for automatiseringsscenarioer. Når du bruker bare apptillatelser, er det viktig å forstå at tillatelser ikke er tilordnet i Microsoft Entra ID. I stedet tilordnes tillatelser på én av to måter:
    • For kjøring av administrator-API-er: Visse power BI-leierinnstillinger gir tilgang til endepunktene for administrator-API-ene (som returnerer metadata for overvåking over hele tenanten). Hvis du vil ha mer informasjon, kan du se Angi leierinnstillinger for Power BI senere i denne artikkelen.
    • For å kjøre bruker-API-er: Power BI-arbeidsområde og elementtillatelser gjelder. Standard Power BI-tillatelser kontrollerer hvilke data som kan returneres til en tjenestekontohaver når du kjører bruker-API-er (som returnerer overvåkingsdata basert på tillatelser fra brukeren eller tjenestekontohaveren som aktiverer API-en).
  • Delegerte tillatelser: Omfangsbaserte tillatelser brukes. Tjenestekontohaveren får tilgang til data på vegne av brukeren som for øyeblikket er logget på. Det betyr at tjenestekontohaveren ikke får tilgang til noe utover det den påloggede brukeren har tilgang til. Vær oppmerksom på at dette er et annet konsept enn bare brukergodkjenning, beskrevet tidligere. Fordi et egendefinert program er nødvendig for å håndtere kombinasjonen av bruker- og apptillatelser på riktig måte, brukes delegerte tillatelser sjelden for overvåkingsscenarioer. Dette konseptet er ofte misforstått, noe som fører til mange appregistreringer som er overbeskyttet med tillatelser.

Viktig

I denne artikkelen er fokuset bare på brukergodkjenning eller app-godkjenning. Delegerte tillatelser (med en interaktiv bruker og tjenestekontohaver) kan spille en viktig rolle når du programmatisk bygger inn Power BI-innhold. Vi fraråder deg imidlertid på det sterkeste å konfigurere delegerte tillatelser for å trekke ut overvåkingsdata. Hver API begrenser hvor ofte det kan kjøres (med begrensning på plass), så det er ikke praktisk å ha forskjellige brukere direkte tilgang til rå overvåkingsdataene. I stedet anbefaler vi at du trekker ut rå overvåkingsdata én gang (med en sentralisert prosess), og deretter gjør de kuraterte overvåkingsdataene tilgjengelige for autoriserte brukere nedstrøms.

Hvis du vil ha mer informasjon, kan du se Registrere en Microsoft Entra-app senere i denne artikkelen.

Appregistreringshemmeligheter

En appregistrering har ofte en hemmelighet tilordnet den. Hemmeligheten brukes som en nøkkel for godkjenning, og den har en utløpsdato. Derfor må du planlegge hvordan du roterer nøkkelen regelmessig og hvordan du kommuniserer den nye nøkkelen til autoriserte brukere.

Du må også bekymre deg for hvor du skal lagre hemmeligheten på en sikker måte. Et organisatorisk passordhvelv, for eksempel Azure Key Vault, er et utmerket valg.

Tips

Som en alternativ tilnærming til å bruke en hemmelighet, kan du bruke en administrert identitet. En administrert identitet eliminerer behovet for å administrere legitimasjon. Hvis du har tenkt å bruke tjenester som Azure Functions eller Azure Data Factory til å trekke ut dataene, er en administrert identitet et godt alternativ for å undersøke.

Behandle legitimasjon på en sikker måte

Uansett om du bruker brukergodkjenning eller tjenestekontohavergodkjenning, er en av de største utfordringene hvordan du kan håndtere passord, hemmeligheter og nøkler på en sikker måte.

Forsiktig!

Den første regelen er en regel som mange bryter: passord og nøkler skal aldri vises i ren tekst i et skript. Mange artikler, blogger og eksempler på nettet gjør det for enkelhetshet. Det er imidlertid en dårlig praksis som bør unngås. Alle som henter skriptet (eller filen) kan potensielt få tilgang til de samme dataene som forfatteren har tilgang til.

Her er flere sikre metoder du kan bruke til å behandle passord, hemmeligheter og nøkler.

  • Integrer med Azure Key Vault eller et annet organisatorisk passordhvelvsystem når det er mulig.
  • Bruk legitimasjon og sikre strenger i PowerShell-skriptene. En legitimasjon fungerer for både brukergodkjenning og tjenestekontohavergodkjenning. Du kan imidlertid ikke bruke legitimasjon når godkjenning med flere faktorer er aktivert for en brukerkonto.
  • Be om et passord i PowerShell-skriptet, eller bruk interaktiv godkjenning med en nettleser.
  • Bruk Secret Management-modulen for PowerShell som er publisert av Microsoft. Den kan lagre verdier ved hjelp av et lokalt hvelv. Det kan også integreres med et eksternt Azure Key Vault, som er nyttig når det er flere administratorer i organisasjonen som arbeider med de samme skriptene.
  • Opprett en egendefinert kobling for Power BI Desktop, slik at den kan håndtere legitimasjon på en sikker måte. Noen egendefinerte koblinger er tilgjengelige fra fellesskapsmedlemmer (vanligvis på GitHub).

Tips

Vi anbefaler at du tar kontakt med IT- og sikkerhetsteamene for å hjelpe deg med å velge den beste metoden, eller validere at løsningen administrerer legitimasjon på en sikker måte.

Microsofts godkjenningsbibliotek

Støtte for Azure AD Authentication Library (ADAL) ble avsluttet i desember 2022. Fremover bør du bruke Microsoft Authentication Library (MSAL). Sikkerhetsteamet i organisasjonen bør være kjent med denne betydelige endringen.

Selv om det ikke er viktig for Power BI-eksperter å forstå overgangen til MSAL dypt, bør du følge følgende anbefalinger.

  • Bruk den nyeste versjonen av Power BI Management-modulen når du godkjenner med Koble til-PowerBIServiceAccount PowerShell-cmdleten. Den byttet fra ADAL til MSAL i versjon 1.0.946 (26. februar 2021).
  • Bruk Microsoft Entra V2-endepunktet når du godkjenner direkte i skriptet. Microsoft Entra V2-endepunktet bruker MSAL, mens Microsoft Entra V1-endepunktet bruker ADAL.
  • Avbryt bruken av API-er og moduler som er avskrevet. Hvis du vil ha mer informasjon, kan du se Avskrevne API-er og moduler senere i denne artikkelen.
  • Hvis du finner en fellesskapsløsning på nettet, må du kontrollere at den bruker MSAL til godkjenning i stedet for ADAL.

Sjekkliste – Når du bestemmer deg for hvordan du administrerer godkjenning, omfatter viktige beslutninger og handlinger:

  • Bestem hvilken type godkjenning som skal brukes: Bestem om brukergodkjenning eller tjenestekontohavergodkjenning er mest egnet, avhengig av hvilken type overvåkingsløsning du har tenkt å opprette.
  • Planlegg hvilke appregistreringer du trenger: Vurder dine krav, arbeidsbelastninger og målgruppe (brukere av hver appregistrering). Planlegg hvor mange appregistreringer du må opprette for å støtte disse behovene.
  • Opprett en navnekonvensjon for appregistreringer: Konfigurer en navnekonvensjon som gjør det enkelt å forstå det tiltenkte formålet og tiltenkte brukere av hver appregistrering.
  • Planlegg hvordan du kan behandle legitimasjon på en sikker måte: Vurder måter å behandle passord, hemmeligheter og nøkler på på en sikker måte. Vurder hvilken dokumentasjon og opplæring som kan være nødvendig.
  • Bekreft bruken av MSAL: Finn ut om det finnes noen eksisterende manuelle eller automatiserte overvåkingsløsninger som er avhengige av ADAL. Om nødvendig kan du opprette en plan for å skrive om disse løsningene for å bruke det nyere MSAL-godkjenningsbiblioteket.

Velg en bruker-API eller administrator-API

Når du planlegger å hente overvåkingsdata, er det viktig å bruke riktig type API.

Det finnes to typer API-er å vurdere.

  • Bruker-API-er: Bruk tillatelsene til den påloggede brukeren (eller tjenestekontohaveren) til å sende forespørsler til API-en. Én måte å returnere en liste over semantiske modeller i et arbeidsområde på, er for eksempel med en bruker-API. Tillatelse til å lese semantiske modeller kan gis enten av arbeidsområderolle eller per element-tillatelser. Det finnes to måter å kjøre bruker-API-er på:
    • Brukergodkjenning: Den påloggede brukeren må ha tillatelse til å få tilgang til arbeidsområdet eller elementet.
    • Tjenestekontohavergodkjenning: Tjenestekontohaveren må ha tillatelse til å få tilgang til arbeidsområdet eller elementet.
  • Administrator-API-er: Hent metadata fra leieren. Det kalles noen ganger organisasjonsomfanget. Hvis du for eksempel vil returnere en liste over alle semantiske modeller i leieren, bruker du en administrator-API. Det finnes to måter å kjøre API-er for administratorer på:
    • Brukergodkjenning: Den påloggede brukeren må være en Power BI-administrator for å kunne kjøre administrator-API-er.
    • Tjenestekontohavergodkjenning: Tjenestekontohaveren må ha tillatelse til å kjøre administrator-API-er (uten å stole på sikkerhetstillatelser som en bruker-API gjør).

Tips

Alle administrator-API-er tilhører administratoroperasjonsgruppen. Alle API-er som har suffikset som administrator , er en administrator-API. Alle gjenværende API-er er bruker-API-er.

Vurder et eksempel der du må få en liste over semantiske modeller. Tabellen nedenfor viser seks API-alternativer som du kan bruke til å gjøre dette. Fire alternativer er bruker-API-er, og to alternativer er administrator-API-er. Omfanget og antallet elementer som returneres, er forskjellig, avhengig av API-en du velger.

API-navn Type of API Scope Antall semantiske modeller
Hent datasett Bruker Personlig arbeidsområde Én
Hent datasett Bruker Personlig arbeidsområde Alle
Hent datasett i gruppe Bruker Ett arbeidsområde Én, forutsatt at den påloggede brukeren har tillatelse til å lese den semantiske modellen
Hent datasett i gruppe Bruker Ett arbeidsområde Alle, forutsatt at den påloggede brukeren har tillatelse til å lese hver semantisk modell
Hent datasett i gruppe som administrator Administrator Ett arbeidsområde Alle
Hent datasett som administrator Administrator Hele leieren Alle

Merk

Noen av API-navnene inkluderer termgruppen som en referanse til et arbeidsområde. Dette begrepet stammer fra den opprinnelige Power BI-sikkerhetsmodellen, som var avhengig av Microsoft 365-grupper. Selv om Power BI-sikkerhetsmodellen har utviklet seg betydelig gjennom årene, forblir de eksisterende API-navnene uendret for å unngå å bryte eksisterende løsninger.

Hvis du vil ha informasjon om leierinnstillinger, kan du se Angi leierinnstillinger for Power BI senere i denne artikkelen.

Sjekkliste – Når du velger om du vil bruke en bruker-API eller en administrator-API, omfatter viktige beslutninger og handlinger:

  • Se datakrav: Samle inn og dokumenter de viktigste forretningskravene for en overvåkingsløsning. Avhengig av hvilken type data som kreves, må du avgjøre om et brukeromfang eller organisasjonsomfang er riktig.
  • Test resultatene: Gjør noen eksperimenteringer. Test nøyaktigheten av resultatene som returneres av de ulike API-ene.
  • Se gjennom tillatelser: Bekreft at tillatelser tilordnes riktig for Power BI-administratorer og tjenestekontohavere for eventuelle eksisterende overvåkingsløsninger. Bekreft hvilken godkjenningsmetode som skal brukes for nye overvåkingsløsninger.

Velg API-er eller PowerShell-cmdleter

En viktig beslutning å ta er om du vil bruke PowerShell-cmdleter når de er tilgjengelige for de spesifikke dataene du vil hente. Denne beslutningen er viktig hvis du har bestemt deg for at PowerShell er en av teknologiene du bruker til å få tilgang til overvåkingsdata.

PowerShell er en løsning for oppgaveautomasjon. Begrepet PowerShell er et kollektivt begrep som refererer til skriptspråket, et kommandolinje-skallprogram og et rammeverk for konfigurasjonsadministrasjon. PowerShell Core er den nyeste versjonen av PowerShell, som kjører på Windows, Linux og macOS.

En PowerShell-cmdlet er en kommando som utfører en handling. En PowerShell-modul er en pakke som inneholder PowerShell-medlemmer, for eksempel cmdleter, leverandører, funksjoner, arbeidsflyter, variabler og aliaser. Du laster ned og installerer moduler.

En PowerShell-modul oppretter et lag med abstraksjon over API-ene. Cmdleten Get-PowerBIActivityEvent henter for eksempel (eller henter) overvåkingshendelser for en Power BI-tenant. Denne PowerShell-cmdleten henter dataene fra REST-API-en hent aktivitetshendelser . Vanligvis er det enklere å komme i gang ved hjelp av cmdletene fordi det forenkler tilgangen til de underliggende API-ene.

Bare et delsett av API-ene er tilgjengelige som PowerShell-cmdleter. Etter hvert som du fortsetter å utvide hele overvåkingsløsningen, er det sannsynlig at du bruker en kombinasjon av cmdleter og API-er. Resten av denne delen hjelper deg med å bestemme hvilken vei du skal få tilgang til dataene.

PowerShell-moduler

Microsoft har publisert to PowerShell-moduler som inneholder cmdleter relatert til Power BI. De er Power BI Management-modulen og Data Gateway-modulen. Disse PowerShell-modulene fungerer som en API-wrapper oppå de underliggende REST-API-ene for Power BI. Bruk av disse PowerShell-modulene kan gjøre det enklere å skrive skript.

Tips

I tillegg til modulene som er publisert av Microsoft, er det fritt tilgjengelige PowerShell-moduler og -skript publisert (vanligvis på GitHub) av Medlemmer av Power BI-fellesskapet, partnere og Microsoft Most Valued Professionals (MVPer).

Å starte med en fellesskapsløsning kan spille en viktig rolle i å bygge en løsning for ende-til-ende-overvåking. Hvis du velger å bruke en fritt tilgjengelig løsning, må du teste den fullstendig. Bli kjent med hvordan det fungerer, slik at du effektivt kan administrere løsningen over tid. IT-avdelingen kan ha kriterier for å bruke offentlig tilgjengelige fellesskapsløsninger.

Power BI Management-modul

Power BI Management-modulen er en modul for beregnet verdi som inneholder bestemte Power BI-moduler for administrasjon, kapasiteter, arbeidsområder og mer. Du kan velge å installere modulen for beregnet verdi for å hente alle modulene, eller du kan installere bestemte moduler. Alle Power BI Management-modulene støttes på både Windows PowerShell og PowerShell Core.

Viktig

Vi anbefaler at du avvikler bruken av Windows PowerShell (som ikke kan kjøre PowerShell Core). Bruk i stedet et av de moderne koderedigeringsprogramene som støtter PowerShell Core. Windows PowerShell ISE (integrert skriptmiljø) kan bare kjøre PowerShell versjon 5.1, som ikke lenger er oppdatert. Windows PowerShell er nå avskrevet, så vi anbefaler at du bruker PowerShell Core for alt nytt utviklingsarbeid.

Her er flere ofte brukte cmdleter som du kan bruke til å hente overvåkingsdata.

Administrasjonsmodul Cmdleten Formål
Profil Koble til-PowerBIServiceAccount Godkjenne en Power BI-bruker eller tjenestekontohaver.
Administrator Get-PowerBIActivityEvent Vis eller trekk ut aktivitetslogghendelser for Power BI for leieren.
Arbeidsområder Get-PowerBIWorkspace Kompiler en liste over arbeidsområder.
Rapporter Get-PowerBIReport Kompiler en liste over rapporter for et arbeidsområde eller leieren.
Data Get-PowerBIDataset Kompiler en liste over semantisk modell for et arbeidsområde eller leieren.
Profil Invoke-PowerBIRestMethod Send en REST-API-forespørsel (kommando). Denne cmdleten er et godt alternativ fordi den kan aktivere noen av REST-API-ene for Power BI. Det er også et godt valg når du vil bruke den enklere godkjenningsformen ved hjelp av cmdleten Connect-PowerBIServiceAccount og kunne aktivere en API som ikke har en tilsvarende PowerShell-cmdlet. Hvis du vil ha mer informasjon, kan du se Vurderinger for å bruke PowerShell-cmdleter senere i denne delen.

Tips

Det finnes andre cmdleter tilgjengelig for administrasjon og publisering av innhold. Fokuset i denne artikkelen er imidlertid på å hente overvåkingsdata.

Du kan laste ned Power BI Management-modulen fra PowerShell-galleriet. Den enkleste måten å installere moduler på, er å bruke PowerShellGet.

Vi anbefaler at du installerer modulen for beregnet power BI-administrasjon. På den måten er alle cmdletene du trenger, tilgjengelige. Som et minimum trenger du profilmodulen (for godkjenning) og eventuelle spesifikke moduler som inneholder cmdletene du vil bruke.

Forsiktig!

Pass på at du holder modulene oppdatert på hver server, brukermaskin og skytjeneste (for eksempel Azure Automation) der du bruker PowerShell. Hvis modulene ikke oppdateres regelmessig, kan det oppstå uforutsigbare feil eller problemer. Noen verktøy (for eksempel Visual Studio Code) hjelper deg med å holde modulene oppdatert. Vær også oppmerksom på at PowerShellGet ikke avinstallerer eldre versjoner av en modul automatisk når du installerer eller oppdaterer en nyere versjon. Den installerer nyere versjoner sammen med de eldre versjonene. Vi anbefaler at du ser etter installerte versjoner og avinstallerer eldre versjoner regelmessig.

DataGateway-modul

Data Gateway-modulen inneholder cmdleter som henter data fra en lokal datagateway og datakildene. DataGateway-modulen støttes bare i PowerShell Core. Det støttes ikke på Windows PowerShell.

I motsetning til Power BI Management-modulen (tidligere beskrevet), inkluderer ikke Data Gateway-modulen noen administrator-cmdleter. Mange av cmdletene (og de tilsvarende gateway-API-ene) krever at brukeren har administratorrettigheter for gatewayen.

Advarsel!

Det er ikke mulig å tilordne en tjenestekontohaver som gatewayadministrator (selv når tjenestekontohaveren er medlem av en sikkerhetsgruppe). Planlegg derfor å bruke brukerlegitimasjon når du henter informasjon om datagatewayer.

Her er flere cmdleter fra Data Gateway-modulen som du kan bruke til å hente overvåkingsdata.

Cmdleten Formål
Koble til-DataGatewayServiceAccount Godkjenne en Power BI-bruker (krever vanligvis at brukeren tilhører administratorrollen for gatewayen).
Get-DataGatewayCluster Kompiler en liste over gateway-klynger.
Get-DataGatewayClusterDataSource Kompiler en liste over datakilder for en gateway-klynge.
Get-DataGatewayInstaller Kontroller hvilke brukere som har tillatelse til å installere og registrere gatewayer i organisasjonen.

Du kan laste ned Data Gateway-modulen fra PowerShell-galleriet.

Teknikker for å bruke PowerShell

Du kan bruke PowerShell på flere forskjellige måter. Beslutningen du tar, er viktig.

Tabellen nedenfor beskriver tre ulike teknikker for bruk av PowerShell.

Teknikk Beskrivelse Eksempel
Bruk PowerShell-cmdleter til å forenkle godkjenning, og til å ringe API-er direkte. Anbefalt tilnærming Med denne teknikken er det en balanse mellom enkelhet og fleksibilitet. Invoke-PowerBIRestMethod-cmdleten er tilgjengelig fra Power BI Management Profile-modulen. Denne cmdlet er ofte referert til som en sveitsisk Army Knife fordi du kan bruke den til å ringe noen av Power BI REST API-er. Fordelen med å bruke denne teknikken er at du kan forenkle godkjenningen, og deretter ringe noen av REST-API-ene for Power BI. Vi anbefaler på det sterkeste at du bruker denne teknikken. Når du har godkjent med cmdleten Koble til-PowerBIServiceAccount, bruker du cmdleten Invoke-PowerBIRestMethod til å hente data fra din foretrukne API (for eksempel Hent datasamlebåndbrukere som administrator).
Bruk cmdleter fra PowerShell så mye som mulig, både for godkjenning og for å hente data. Med denne teknikken brukes PowerShell mye. PowerShell brukes til å koordinere kjøring av skriptet, og PowerShell-moduler brukes når det er mulig for tilgang til dataene. Dette oppretter en større avhengighet av PowerShell fra flere aspekter. Når du har godkjent med Koble til-PowerBIServiceAccount-cmdleten, bruker du en cmdlet (for eksempel Get-PowerBIActivityEvent) til å hente data.
Bruk PowerShell bare til å koordinere kjøring av prosessen. PowerShell-moduler brukes så lite som mulig. Med denne teknikken er det mindre avhengighet av PowerShell som et verktøy siden den primære bruken er å organisere aktivering av API-kall. Bare én generisk PowerShell-modul brukes til å få tilgang til API-er (ingen av modulene fra Power BI Management-modulene brukes). Når du har godkjent ved hjelp av Microsoft Authentication Library (MSAL), kan du kalle din foretrukne API (for eksempel Hent pipeline-brukere som administrator) ved hjelp av den generiske Invoke-RestMethod-cmdleten for å hente data.

I tabellen ovenfor beskriver den første teknikken en tilnærming som balanserer brukervennlighet med fleksibilitet. Denne tilnærmingen gir den beste balansen for behovene til de fleste organisasjoner, og derfor anbefales det. Noen organisasjoner kan ha eksisterende IT-policyer og personalinnstillinger som påvirker hvordan du bestemmer deg for å bruke PowerShell.

Tips

Du kan bruke Invoke-ASCmd PowerShell-cmdleten til å opprette og kjøre DAX-, XMLA- og TMSL-skript. Disse brukstilfellene er imidlertid utenfor omfanget for denne artikkelen. Hvis du vil ha mer informasjon om spørring av dynamiske administrasjonsvisninger (DMV-er), kan du se Overvåking på datanivå.

Tekniske brukere (og administratorer) kan bruke Power BI Management-modulene til å hente data eller automatisere bestemte aspekter ved innholdsbehandling.

  • For administratorer: Angi parameteren -Scope for å få tilgang til Organization enheter på tvers av hele leieren (for eksempel for å hente en liste over alle arbeidsområder).
  • For tekniske brukere: Angi parameteren -Scope til Individual (eller utelate parameteren) for å få tilgang til enheter som tilhører brukeren (for eksempel for å hente en liste over arbeidsområder som brukeren har tilgang til).

Vurder et scenario der du må få en liste over semantiske modeller. Hvis du velger å arbeide direkte med API-ene, må du angi hvilken API som skal ringes. Hvis du imidlertid velger å bruke Get-PowerBIDataset-cmdleten , kan du angi parameteren -Scope for å hente en brukerspesifikk eller leierliste over semantiske modeller. Valget du tar, avhenger av beslutningen din om hvordan du bruker PowerShell (dekket i forrige tabell).

Tabellen nedenfor beskriver hvordan parameterne som brukes i PowerShell-cmdleten, oversettes til API PowerShell-kall.

Cmdlet-parametere API som cmdleten bruker Type of API Scope Hentet elementer
-DatasetID {DatasetID}
-Scope Individual		 Hent datasett Bruker Personlig arbeidsområde Én semantisk modell
-Scope Individual Hent datasett Bruker Personlig arbeidsområde Alle semantiske modeller
-DatasetID {DatasetID}
-GroupID {WorkspaceID}		 Hent datasett i gruppe Bruker Ett arbeidsområde Én semantisk modell, forutsatt at den påloggede brukeren har tillatelse til å lese den semantiske modellen
-GroupID {WorkspaceID} Hent datasett i gruppe Bruker Ett arbeidsområde Alle semantiske modeller, forutsatt at den påloggede brukeren har tillatelse til å få tilgang til arbeidsområdet og lese den semantiske modellen
-GroupID {WorkspaceID}
-Scope Organization		 Hent datasett i gruppe som administrator Administrator Ett arbeidsområde Alle semantiske modeller
-Scope Organization Hent datasett som administrator Administrator Hele leieren Alle semantiske modeller
Vurderinger for bruk av PowerShell-cmdleter

Power BI PowerShell-cmdletene er enklere å bruke fordi de abstraherer noe av kompleksiteten til REST API-kall.

Her er noen av måtene cmdletene forenkler tilgangen til overvåkingsdata på.

  • Godkjenning: Den enkleste måten å godkjenne i et PowerShell-skript på, er å bruke cmdleten Connect-PowerBIServiceAccount .
  • Enkelhet: Det er enklere å komme i gang fordi teknikkene for å hente overvåkingsdata er enkle. Tenk på at når du bruker Get-PowerBIActivityEvent-cmdleten, henter du én dag med overvåkingsdata. Når du imidlertid kaller rest-API-en for Hent aktivitetshendelser direkte, henterdu én time med overvåkingsdata. Så når du bruker REST-API-en til å hente én dag med overvåkingsdata, må du bruke en løkke til å kalle API-en 24 ganger for å trekke ut hver time på dagen.
  • Paginering av store resultatsett: Store resultatsett hentes effektivt ved sideformatering. Paginering innebærer å hente én del av resultatene om gangen. Cmdletene administrerer automatisk paginering for deg. Når du imidlertid bruker REST-API-ene direkte, må skriptet kontrollere et fortsettelsestoken for å finne ut om det kommer flere resultater. Skriptet bør fortsette å hente biter av resultater til ingen fortsettelsestoken er mottatt. Hvis du vil ha et eksempel på hvordan du bruker et fortsettelsestoken, kan du se REST-API for aktivitetshendelser.
  • Utløp av tilgangstoken: Ved godkjenning returneres et tilgangstoken. Som standard utløper den etter én time. Cmdletene håndterer utløp av tilgangstoken for deg. På den måten trenger du ikke å skrive logikk for å be om et oppdateringstoken.
  • Formatering: Dataene som returneres av en cmdlet, er formatert litt bedre enn dataene som returneres av REST-API-en. Utdataene er mer brukervennlige. For automatiserte overvåkingsprosesser vil det sannsynligvis ikke være et problem. For manuelle overvåkingsprosesser kan imidlertid den bedre formateringen være nyttig.
Vurderinger for bruk av REST-API-er direkte

Noen ganger er det fordeler med å ringe REST-API-ene for Power BI direkte.

  • Mange flere API-er er tilgjengelige: Det finnes flere REST-API-er tilgjengelig enn PowerShell-cmdleter. Men ikke overse fleksibiliteten til Invoke-PowerBIRestMethod-cmdleten , som du kan bruke til å ringe noen av REST-API-ene for Power BI.
  • Hyppigheten av oppdateringer: Microsoft oppdaterer REST-API-ene oftere enn det oppdaterer PowerShell-modulene. Hvis for eksempel et nytt attributt legges til I API-svaret Hent datasett , kan det ta litt tid før det blir tilgjengelig i resultatene av Get-PowerBIDataset-cmdleten .
  • Mindre språk-/verktøyavhengighet: Når du bruker REST-API-ene direkte (i stedet for en cmdlet), trenger du ikke å bruke PowerShell. Du kan også velge å bruke PowerShell bare til å organisere kall til mange API-er i et skript. Ved å fjerne (eller unngå) enhver avhengighet av PowerShell, kan du på et tidspunkt i fremtiden skrive om logikken på et annet språk. Når IT- eller utviklerteamet har sterke preferanser for verktøy og språk, kan mindre avhengighet være en viktig vurdering å ta hensyn til.

Uavhengig av hvilken metode du velger å bruke, kan REST-API-ene endres over tid. Når en teknologi utvikler seg, kan API-er (og PowerShell-moduler) avskrives og erstattes. Derfor anbefaler vi at du med hensikt oppretter skript som er enkle å vedlikeholde og motstandsdyktige mot endring.

Sjekkliste – Når du velger om du vil ha tilgang til REST-API-ene direkte eller ved hjelp av PowerShell-cmdleter, omfatter viktige beslutninger og handlinger:

  • Ta kontakt med IT om bruken av PowerShell: Kontakt de relevante IT-teamene for å finne ut om det finnes eksisterende interne krav eller preferanser for hvordan PowerShell kan brukes.
  • Bestem hvordan du vil bruke PowerShell: Bestem hvilke PowerShell-teknikker du vil bruke, og om du vil øke eller redusere avhengigheten av PowerShell med vilje. Vurder om intern kommunikasjon eller opplæring er nødvendig.
  • Oppgrader til PowerShell Core: Oppslag ved hjelp av PowerShell Core. Finn ut om administratormaskiner må oppdateres. Vurder hvilke eksisterende skript som må testes. Finn ut om administratorer eller utviklere trenger ekstra opplæring for å oppgradere ferdighetene sine.
  • Bestem hvilke PowerShell-moduler som skal brukes: Vurder om Modulene for Power BI-administrasjon og/eller datagatewayen skal brukes.
  • Bestem om fellesskapsprosjekter er tillatt: Bestem om du har tillatelse (eller til og med oppfordret) til å bruke PowerShell-moduler som er tilgjengelige på nettet (kontra moduler publisert av Microsoft). Ta kontakt med IT for å finne ut om det finnes kriterier for fellesskapsprosjekter som er innhentet på nettet.
  • Klargjør hvordan du støtter fellesskapsprosjekter: Hvis PowerShell-fellesskapsprosjekter er tillatt, bør du vurdere hvem som vil være ansvarlig for å støtte dem når de brukes internt.
  • Fullfør et lite konseptbevis (POC): Eksperimenter med en teknisk poc. Bekreft de foretrukne klientverktøyene og metoden for å få tilgang til data.
  • Bestem hvordan du støtter avanserte brukere: Vurder hvordan du skal støtte tekniske brukere som oppretter automatisering på egen hånd ved hjelp av bruker-API-ene.

Finne ut hvor overvåkingsdata skal lagres

Når du planlegger å bygge en ende-til-ende-overvåkingsløsning, må du bestemme hvor rådataene skal lagres (og de kuraterte dataene, som dekkes i neste del). Dine beslutninger om datalagring er relatert til preferansene dine for hvordan du håndterer dataintegrering.

Når du trekker ut rå overvåkingsdata, gjør du det enkelt. Vi anbefaler at du ikke velger bestemte attributter, utfører transformasjoner eller bruker formatering når du først trekker ut dataene. I stedet kan du trekke ut alle tilgjengelige attributter og lagre dataene i den opprinnelige tilstanden.

Her er flere grunner til at lagring av rådata i den opprinnelige tilstanden er en anbefalt fremgangsmåte.

  • Alle data som er tilgjengelige i loggen: Nye attributter og nye hendelsestyper blir tilgjengelige over tid. Lagring av alle rådataene er en god måte å sikre at du alltid har tilgang til dataene som var tilgjengelige da du pakket dem ut. Selv når det tar deg tid , som kan være uker eller måneder - å innse at nye dataattributter er tilgjengelige, er det mulig å analysere dem historisk fordi du fanget dem i rådataene.
  • Motstandsdyktig mot endring: Hvis rådataformatet endres, påvirkes ikke prosessen som trekker ut dataene. Siden noen overvåkingsdata er tidssensitive, er det viktig å sørge for at du utformer en datautpakkingsprosess som ikke mislykkes når en endring skjer i kilden.
  • Roller og ansvarsområder: Ulike gruppemedlemmer (for eksempel datateknikere eller globale administratorer) kan være ansvarlige for å opprette prosessene for å få tilgang til, trekke ut og lagre rå overvåkingsdata. Enklere uttrekking av data gjør det enklere for flere team å samarbeide.

Her er noen alternativer for lagring av rådata.

  • Datainnsjø eller objektlagring: En skytjeneste, for eksempel OneLake , som spesialiserer seg på lagring av filer av enhver struktur. Det er et ideelt valg for lagring av rå overvåkingsdata. I en datainnsjøarkitektur bør rådata lagres i bronselaget.
  • Filsystem: Et filsystem (for eksempel Windows eller Linux) er et vanlig valg for lagring av rå overvåkingsdata.
  • Database: Det er mulig å lagre JSON-data i en relasjonsdatabase, for eksempel Azure SQL Database. Det er imidlertid mindre vanlig enn å lagre dataene i en datainnsjø eller et filsystem. Det er fordi spørring og vedlikehold av JSON-data kan bli utfordrende og dyrt, spesielt etter hvert som datavolumene vokser.

Tips

Når du bruker en datainnsjø, objektlagring eller et filsystem, anbefaler vi at du lagrer dataene på en måte som er enkel å organisere og sikre. Det er også viktig å være tydelig på om dataene består av hendelser (som vanligvis legges til) eller om det er et øyeblikksbilde (som krever at du velger en dato for å analysere).

Vurder et eksempel som involverer en rå datasone for en datainnsjø. Sonen har et mappehierarki for lagring av aktivitetsloggdata: Raw > ActivityLog > YYYY > MM. Mappene partisjoneres etter år og måned. En fil som er lagret i månedsmappen, bruker følgende format: PBIActivityLog-YYYYMMDD-YYYYMMDDTTTT.json. YYYYMMDD representerer de faktiske dataene, og YYYYMMDTTTTTT representerer tidsangivelsen for uttrekking. Ved å inkludere tidsangivelsen for uttrekking, kan du bestemme hvilken fil som er den nyeste (i tilfelle du må trekke ut dataene på nytt). Hvis du for eksempel trekker ut data klokken 09.00 (UTC) den 25. april 2023 for aktivitet 23. april 2023, vil filnavnet være PBIActivityLog-20230523-202305250900.

Vi anbefaler på det sterkeste at du bruker en teknologi som lar deg skrive rådataene til uforanderlig lagringsplass. Uforanderlig lagring garanterer at når dataene er skrevet, kan de ikke overskrives eller slettes. Dette skillet er viktig for revisorer, og det lar deg stole på at rådataene er pålitelige.

Du må også vurdere hvordan du kan lagre rådataene på en sikker måte. Vanligvis krever svært få brukere tilgang til rådata. Tilgang til rådata gis vanligvis etter behov, vanligvis for datateknikere og systemadministratorer. Interne revisorer kan også trenge tilgang. Gruppemedlemmene som er ansvarlige for å opprette de kuraterte dataene (beskrevet neste), krever også tilgang til rådataene.

Her er noen vurderinger for å hjelpe deg med å velge rå datalagring.

  • Er det en manuell eller automatisert revisjonsprosess? En automatisert revisjonsprosess har vanligvis strengere krav til hvordan og hvor dataene lagres.
  • Er emneområdet spesielt følsomt? Avhengig av datatypen og hvor sensitiv den er, kan organisasjonen ha et krav til hvordan og hvor den er lagret. Power BI-overvåkingsdata inneholder identifiserende brukerinformasjon og IP-adresser, så de bør lagres i et sikkert område.
  • Finnes det en foretrukket lagringsteknologi? Det kan være en eksisterende lagringsteknologi som er i bruk i organisasjonen, så det er et logisk valg.
  • Får brukerne tilgang til lagringsplassen direkte? Sikkerhetsmodellen er en viktig vurdering. Vanligvis får svært få brukere tilgang til rådata. Tilgang til de kuraterte dataene gjøres vanligvis tilgjengelig for Power BI-innholdsopprettere som er ansvarlige for å opprette den sentraliserte datamodellen (den semantiske modellen som fungerer som laget for rapportering).
  • Har du krav til datalagring? Noen organisasjoner har juridiske eller forskriftsmessige krav til datalagring for å lagre data i et bestemt dataområde.
  • Hvordan organiseres dataene? Bruk av medaljongarkitekturen er en vanlig praksis, spesielt i data lake og lakehouse implementeringer. Målet er å lagre dataene dine i bronse-, sølv- og gulldatalag. Bronselaget inneholder de opprinnelige rådataene. Sølvlaget inneholder validerte og deduplicated data som brukes til transformasjoner. Gulllaget inneholder de kuraterte, svært raffinerte dataene som er klare for analyse.

Sjekkliste – Når du planlegger plasseringen for å lagre rådata, omfatter viktige beslutninger og handlinger:

  • Rådfør deg med IT: Kontakt de relevante IT-teamene for å finne ut om det er eksisterende prosesser som kjører for å trekke ut rå overvåkingsdata. I så fall kan du finne ut om du har tilgang til eksisterende data. Hvis det kreves en ny datauttrekkingsprosess, må du avgjøre om det finnes innstillinger eller krav for hvor dataene skal lagres.
  • Bestem hvor rådataene skal lagres: Bestem den beste lagringsplasseringen og strukturen for lagring av rådata.
  • Bestem kravene for datalagring: Finn ut om det finnes juridiske eller forskriftsmessige krav til hvor dataene kan lagres.
  • Opprett en mappestruktur og navnekonvensjon: Bestem hvilken navnekonvensjon som skal brukes for rådatafiler, inkludert mappestrukturen. Inkluder disse detaljene i den tekniske dokumentasjonen.
  • Vurder hvordan sikkerhet for rådata vil fungere: Når du utformer lagringsplasseringen for rådata, bør du vurdere hvem som må få tilgang til dataene og hvordan tilgang vil bli gitt.

Planlegge å opprette kuraterte data

Kuraterte data støtter analyse og er utformet for å være brukervennlige. Du må ta noen avgjørelser om hvordan og hvor kuraterte data skal opprettes. Teknologien du velger å lagre de kuraterte dataene, kan være hvilken som helst av teknologiene som er oppført i forrige del.

Målet med kuraterte data er å transformere dataene til et mer vennlig format som er optimalisert for analyse og rapportering. Den danner datakilden til en Power BI-datamodell, så det betyr at du bruker en Power BI-datamodell til å analysere bruken av Power BI i organisasjonen. Grunnleggende veiledning for datamodell gjelder: Du bør ta i bruk en utforming av stjerneskjema, som er optimalisert for ytelse og brukervennlighet.

Du kan velge å opprette kuraterte data på forskjellige måter. Du må bestemme hvordan du utfører dataintegrering og hvor langt oppstrøms du skal bruke transformasjonene som klargjør dataene for innlasting i et stjerneskjema.

Datasjø

Du kan bruke transformasjoner og opprette kuraterte datafiler i en datainnsjø. Du bør bruke et gulllag for kuraterte data, slik at det er logisk atskilt fra rådataene som er lagret i bronselaget. Hvis du skiller dataene i lag, forenkles også innstillingen av ulike brukertilgangstillatelser.

Bruk en datainnsjø til å transformere og kuratere dataene når:

  • Du forventer at det finnes flere Power BI-datamodeller som betjener rapportering (som rettferdiggjør oppretting av et mellomliggende sølvlag).
  • Du må støtte flere selvbetjente innholdsopprettere som trenger tilgang til overvåkingsdata på leiernivå.
  • Du har eksisterende verktøy og prosesser som du vil bruke til å transformere og laste inn data.
  • Du vil minimere dataforberedelsen som må gjøres (og potensielt dupliseres) i én eller flere Power BI-datamodeller.
Power BI-datamodell

Du kan kanskje fullføre alt transformasjonsarbeidet i Power BI. Bruk Power Query til å få tilgang til og transformere dataene fra råtilstanden til det kuraterte formatet.

Bruk en Power BI-datamodell når:

  • Du vil forenkle ende-til-ende-arkitekturen og laste inn datamodellen direkte fra rådataene. (Trinnvis oppdatering kan bidra til å redusere varighet for oppdateringer.)
  • Din preferanse er å gjøre alt transformasjonsarbeidet mens du laster inn datamodellen.
  • Du forventer å ha én sentralisert datamodell for overvåkingsdataene på leiernivå. Alle rapporter (eller andre datamodeller) kan bruke den sentraliserte semantiske Power BI-modellen som kilde.
  • Du vil bare gi brukertilgang til den sentraliserte Semantiske Power BI-modellen (og ikke til noen av kildedataene).

Tips

Når du oppretter de kuraterte dataene, kan du konfigurere dem på en måte slik at du enkelt kan kjøre prosessen på nytt for tidligere datointervaller. Hvis du for eksempel oppdager at et nytt attributt dukket opp i overvåkingsloggene for tre måneder siden, vil du kunne analysere det siden det først ble vist. Muligheten til å laste inn den kuraterte dataloggen på nytt er én av flere grunner til at det er viktig å lagre rådataene i sin opprinnelige tilstand (beskrevet tidligere i denne artikkelen).

Hvis du vil ha mer informasjon om hvilke dimensjonstabeller og faktatabeller du kan inkludere i stjerneskjemaet, kan du se Opprette en datamodell senere i denne artikkelen.

Sjekkliste – Når du planlegger hvordan du oppretter kuraterte data, omfatter viktige beslutninger og handlinger:

  • Bestem hvor transformasjoner skal gjøres: Vurder hvor langt oppstrøms transformasjonsarbeidet skal gjøres, og hvor det passer inn i planen for hele arkitekturen.
  • Bestem hvilket verktøy som skal brukes til å transformere dataene til et stjerneskjema: Bekreft hvilke verktøy og tjenester som skal brukes til å transformere rådataene til kuraterte data.
  • Bestem hvor kuraterte data skal lagres: Bestem det beste valget for lagring av rådataene som er blitt forvandlet til et stjerneskjemaformat. Bestem om et mellomliggende sølvlag er nyttig i ende-til-ende-arkitekturen.
  • Opprett en navnekonvensjon: Bestem hvilken navnekonvensjon som skal brukes for kuraterte datafiler og mapper (hvis aktuelt). Inkluder detaljene i den tekniske dokumentasjonen.
  • Vurder hvordan sikkerhet for kuraterte data vil fungere: Når du utformer den kuraterte datalagringsplasseringen, bør du vurdere hvem som trenger tilgang til dataene og hvordan sikkerhet blir tilordnet.

Datakildebeslutninger

På dette tidspunktet bør du være tydelig på krav, databehov og tillatelser. Viktige tekniske beslutninger er tatt. Nå må du ta noen avgjørelser om hvordan du får tak i bestemte typer data.

Få tilgang til brukeraktivitetsdata

Aktivitetsdataene for Power BI-brukere, som noen ganger kalles aktivitetsloggeneller overvåkingsloggene, inneholder et vell av informasjon for å hjelpe deg med å forstå hva som skjer i Power BI-leieren. Hvis du vil ha mer informasjon om identifisering av databehov, kan du se Brukeraktivitetsdata tidligere i denne artikkelen.

Power BI integrerer loggene med den enhetlige overvåkingsloggen for Microsoft Purview (tidligere kjent som den enhetlige overvåkingsloggen for Microsoft 365). Denne integreringen er en fordel fordi det betyr at alle tjenester i Microsoft 365 ikke trenger å implementere sin egen unike måte å logge på. Den er aktivert som standard.

Viktig

Hvis du ikke allerede trekker ut brukeraktivitetsdata, bør du prioritere dette raskt. Brukeraktivitetsdataene er tilgjengelige de siste 30 eller 90 dagene (avhengig av kilden). Selv når du ikke er klar til å utføre grundig analyse, er det viktig å begynne å trekke ut og lagre dataene så snart som mulig. På den måten vil verdifull historie være tilgjengelig for analyse.

Du har flere alternativer for å hente brukeraktivitetsdata.

Teknikk Beskrivelse Standard dager med logg tilgjengelig Godt valg for manuelle overvåkingsprosesser Godt valg for automatiserte revisjonsprosesser Godt valg for å konfigurere varsling Godt valg for å komme raskt i gang
Manuell (brukergrensesnitt) Samsvarsportalen Microsoft Purview 90 Microsoft Purview-samsvarsportal er et godt valg for manuelle overvåkingsprosesser. Microsoft Purview-samsvarsportal er et godt valg for å komme raskt i gang.
Manuell (brukergrensesnitt) Defender for Cloud Apps 30 Defender for Cloud Apps er et godt valg for manuelle overvåkingsprosesser. Defender for Cloud Apps er et godt valg for å konfigurere varsling.
Programmatisk Power BI-aktivitetslogg (API eller PowerShell-cmdlet) 30 Power BI-aktivitetslogg (API eller PowerShell-cmdlet) er et godt valg for automatiserte overvåkingsprosesser. Power BI-aktivitetslogg (API eller PowerShell-cmdlet) er et godt valg for å komme raskt i gang.
Programmatisk API for administrasjonsaktivitet for Office 365 7 Office 365 Management Activity API er et godt valg for automatiserte overvåkingsprosesser.
Programmatisk Microsoft Sentinel (Azure Monitor) 30 Microsoft Sentinel (Azure Monitor) er et godt valg for automatiserte revisjonsprosesser. Microsoft Sentinel (Azure Monitor) er et godt valg for å konfigurere varsling.

Resten av denne delen introduserer hver av teknikkene som presenteres i tabellen.

Samsvarsportalen Microsoft Purview

Verktøyet for overvåkingssøk i Microsoft Purview-samsvarsportal (tidligere kjent som samsvarssenteret for Microsoft 365) er et praktisk sted å vise aktiviteter og varsler. Dette verktøyet krever ikke at du oppretter et skript for å trekke ut og laste ned dataene. Du kan velge en Power BI-arbeidsbelastning for å vise alle overvåkingsloggpostene for en tidsperiode. Du kan også begrense resultatene ved å velge bestemte aktiviteter og brukere. En leder ber deg for eksempel om å finne ut hvem som slettet et arbeidsområde tidligere på dagen, slik at de raskt kan kontakte personen for å diskutere situasjonen.

De siste 90 dagene av loggen er tilgjengelig med Audit (Standard). Med Audit (Premium) kan du (eventuelt) beholde overvåkingslogger lenger. Siden langsiktig oppbevaring bare gjelder for lisensierte E5-brukere, utelukker det overvåkingsposter for ikke-E5-brukere og gjestebrukere. Derfor anbefaler vi at du bare bruker standard 90-dagers logg for å sikre at all aktivitet fanges opp.

Det finnes lisensieringskrav for å få tilgang til overvåkingsloggene i Microsoft Purview-samsvarsportal. Forhøyede Exchange Online-tillatelser kreves også for å få tilgang til overvåkingsloggene.

Tips

Power BI-administratorer har som standard ikke tillatelse til å få tilgang til søk i den enhetlige overvåkingsloggen i Microsoft Purview-samsvarsportal. Fordi den inneholder data for mange Microsoft 365-tjenester, er det en rolle med høy rettighet. I de fleste organisasjoner er disse tillatelsene reservert for et lite antall IT-administratorer. Det finnes andre alternativer tilgjengelig for Power BI-administratorer, som er beskrevet senere i denne delen.

Brukergrensesnittet i Microsoft Purview-samsvarsportal er nyttig for manuelle overvåkingsprosesser og sporadiske undersøkelser av brukeraktiviteter.

Defender for Cloud Apps

Portalen i Defender for Cloud Apps er et praktisk sted å vise aktiviteter og varsler uten å måtte opprette et skript for å trekke ut og laste ned dataene. Den lar deg også vise data fra Power BI-aktivitetsloggen og brukerpålogginger.

Defender for Cloud Apps inkluderer et brukergrensesnitt for å vise og søke i aktivitetslogger for ulike skytjenester, inkludert Power BI. Den viser de samme logghendelsene som stammer fra den enhetlige overvåkingsloggen for Microsoft Purview, og den inneholder andre hendelser som brukerpåloggingsaktivitet fra Microsoft Entra ID.

I likhet med Microsoft Purview-samsvarsportal (beskrevet i forrige del) har Defender for Cloud Apps et søkbart brukergrensesnitt. Filteralternativene er imidlertid forskjellige. I tillegg til standard 30-dagers logg kan du bruke Defender for Cloud Apps til å vise opptil seks måneder med aktivitetslogglogglogg (i sju dagers intervaller).

Det finnes lisensieringskrav for å få tilgang til Defender for Cloud Apps. Separate tillatelser kreves også.

Tips

Power BI-administratorer har som standard ikke tillatelse til å få tilgang til Defender for Cloud Apps. Det finnes en Power BI-rolle i Defender for Cloud Apps. Å legge til Power BI-administratorer i denne rollen er en god måte å gi dem tilgang til et begrenset sett med data på.

Brukergrensesnittet i Defender for Cloud Apps er nyttig for manuelle overvåkingsprosesser og engangsundersøkelser av brukeraktiviteter.

Aktivitetslogg for Power BI

Power BI-aktivitetsloggen stammer fra den enhetlige overvåkingsloggen. Den inneholder bare brukeraktiviteter relatert til Power Bi-tjeneste.

Tips

For organisasjoner som planlegger å trekke ut brukeraktiviteter, anbefaler vi at de starter med aktivitetsloggen for Power BI. Det er den enkleste kilden til programmatisk tilgang.

Du har to alternativer for å få tilgang til Power BI-aktivitetsloggen.

Hvis du vil ha informasjon om hvilket alternativ du vil bruke, kan du se Velg API-er eller PowerShell-cmdleter tidligere i denne artikkelen.

Tips

Hvis du vil ha eksempler på hvordan du får tilgang til Power BI-aktivitetsloggen med PowerShell, kan du se Få tilgang til Power BI-aktivitetsloggen.

Aktivitetsloggdata for Power BI er tilgjengelig for alle Power BI-administratorer, Power Platform-administratorer og globale administratorer. Du kan få tilgang til dataene fra den enhetlige overvåkingsloggen, som er tilgjengelig for bestemte Exchange Online-roller. Hvis du vil ha mer informasjon, kan du se Spore brukeraktiviteter i Power BI.

Vi anbefaler at du bruker Power BI-aktivitetsloggen når intensjonen din bare er å hente oppføringer i Power BI-overvåkingsloggen.

Merk

Arbeidsområder kalles mapper i overvåkingsloggdataene. Arbeidsområder kalles grupper i REST-API-en for Power BI.

API for administrasjonsaktivitet for Office 365

Du kan trekke ut data fra den enhetlige overvåkingsloggen for andre tjenester, for eksempel SharePoint Online, Teams, Exchange Online, Dynamics 365 og Power BI. Når målet ditt er å implementere en overvåkings- og overvåkingsløsning for flere tjenester, anbefaler vi at du bruker API-en for administrasjonsaktivitet for Office 365. Siden denne API-en returnerer data fra mange tjenester, kalles den unified auditing-API-en (eller den enhetlige overvåkingsloggen). Det er en av API-ene for Administrasjon av Office 365.

Før du bygger en ny løsning, anbefaler vi at du kontakter IT-avdelingen for å finne ut om eksisterende Power BI-overvåkingsposter er tilgjengelige. Det er mulig at en prosess allerede trekker ut og lagrer dataene. Det er også mulig at du kan få tillatelse til å få tilgang til disse dataene i stedet for å bygge en ny løsning.

Du kan få tilgang til dataene på én av to måter.

  • Ring API-en for administrasjonsaktivitet for Office 365 direkte ved hjelp av verktøyet du ønsker. Som standard returnerer API-en 24 timer med data. Du kan hente maksimalt sju dager med logg.
  • Bruk Cmdleten Search-UnifiedAuditLog PowerShell. Det er en Exchange Online PowerShell-cmdlet. Du kan hente maksimalt 90 dager med logg.

Viktig

Cmdleten Search-UnifiedAuditLog skaleres ikke godt, og det krever at du implementerer en looping-strategi for å overvinne grensen på 5000 rader. Av disse grunnene er det egnet til sporadiske spørringer, eller for små organisasjoner som opplever lav aktivitet. Når du bare trenger Power BI-data, anbefaler vi at du bruker Get-PowerBIActivityEvent-cmdleten i stedet.

Generelt sett er det mer utfordrende å komme i gang med API-en for administrasjonsaktivitet for Office 365 enn å bruke Power BI-aktivitetsloggen (beskrevet tidligere). Det er fordi API-en returnerer innholdsblob, og hver innholdsblob inneholder individuelle overvåkingsposter. For store organisasjoner kan det være tusenvis av innholdsblob per dag. Siden kunder og tredjepartsprogrammer bruker denne API-en på en stor måte, implementerer Microsoft begrensninger for å sikre at bruken av tjenesten ikke påvirker andre negativt (kjent som det støyende naboproblemet ). Det kan derfor være en utfordring å hente store mengder historie i større organisasjoner. Hvis du vil ha mer informasjon, kan du se denne feilsøkingsartikkelen.

Hvis du vil bruke denne API-en, må du godkjenne med en tjenestekontohaver som har fått tillatelse til å hente data fra API-en for administrasjonsaktivitet for Office 365.

Tips

Power BI-administratorer har som standard ikke tillatelse til å få tilgang til API-en for administrasjon av Office 365. Siden den inneholder data for mange Microsoft 365-tjenester, krever tilgang administratoren eller revisjonsrollene med høy rettighet. I de fleste organisasjoner er disse rollene reservert for et lite antall IT-administratorer. Power BI-aktivitetsloggen er ment for bruk av Power BI-administratorer.

Henting av overvåkingsdata programmatisk fra API-en for administrasjonsaktivitet for Office 365 er et godt valg når IT må trekke ut og lagre overvåkingslogger fra ulike tjenester (utenfor Power BI).

Microsoft Sentinel

Microsoft Sentinel er en Azure-tjeneste som lar deg samle inn, oppdage, undersøke og svare på sikkerhetshendelser og trusler. Du kan konfigurere Power BI i Microsoft Sentinel som en datakobling. Når du er tilkoblet, strømmes overvåkingslogger (som inneholder et delsett med data) fra Power BI til Azure Log Analytics, som er en funksjon for Azure Monitor.

Tips

Azure Log Analytics er basert på den samme arkitekturen som brukes av hendelsesloggene for semantisk modell på arbeidsområdenivå. Hvis du vil ha mer informasjon om hendelseslogger for semantisk modell, kan du se Overvåking på datanivå.

Fordi det er en separat Azure-tjeneste, må alle administratorer eller brukere du vil kjøre KQL-spørringer (Kusto Query Language ) gis tillatelser i Azure Log Analytics (Azure Monitor). Når de har tillatelse, kan de spørre etter overvåkingsdataene som er lagret i PowerBIActivity-tabellen . Husk imidlertid at du i de fleste tilfeller vil gi brukere tilgang til de kuraterte dataene i gulllaget i stedet for rådataene i bronselaget.

Du bruker KQL til å analysere aktivitetslogghendelsene som er lagret i Azure Log Analytics. Hvis du har SQL-opplevelse, finner du mange likheter med KQL.

Det finnes flere måter å få tilgang til hendelsene som er lagret i Azure Log Analytics. Du kan bruke:

  • Malappen for den forhåndsbygde logganalysen for Power BI Semantic Models .
  • Power BI Desktop-kobling for Azure Data Explorer (Kusto).
  • Nettbasert spørringsopplevelse i Azure Data Explorer.
  • Alle spørringsverktøy som kan sende KQL-spørringer.

Forsiktig!

Vær oppmerksom på at bare et delsett av aktivitetsloggdataene for Power BI lagres i Azure Monitor. Når du planlegger å foreta omfattende analyser av Bruk og innføring av Power BI i organisasjonen, anbefaler vi at du bruker andre alternativer (beskrevet tidligere i denne delen) til å hente aktivitetsdata.

Loggperioden du kan hente, avhenger av policyen for dataoppbevaring for Azure Log Analytics-arbeidsområdet. Vurder kostnader og tilgang til rådata når du bestemmer deg for hvor mye data som skal beholdes.

Microsoft Sentinel og Azure Monitor er gode alternativer når IT allerede har gjort en investering med Microsoft Sentinel, detaljnivået som fanges opp oppfyller dine behov, og aktiviteter som trusselregistrering er en prioritet. Men fordi Microsoft Sentinel ikke registrerer alle Power BI-aktivitetsdata, støtter det ikke å utføre omfattende analyse av Bruk og innføring av Power BI.

Vurderinger av brukeraktivitetsdata

Her er noen vurderinger for å hjelpe deg med å velge kilden for brukeraktivitetsdata.

  • Vil det være en manuell eller automatisert revisjonsprosess? Alternativene for brukergrensesnittet fungerer bra for manuelle overvåkingsprosesser og sporadiske engangsspørringer, spesielt når du må undersøke en bestemt aktivitet. En automatisert overvåkingsprosess som trekker ut brukeraktivitetsdataene etter en tidsplan, vil også være nødvendig for å støtte historisk dataanalyse.
  • Hvor ofte trenger du brukeraktivitetsdataene? For automatiserte overvåkingsprosesser planlegger du å trekke ut data som er minst én dag før gjeldende dato ved hjelp av Coordinated Universal Time (UTC), i stedet for lokal tid. Hvis prosessen for eksempel kjører fredag morgen (UTC-tid), bør du trekke ut data fra onsdag. Det er flere grunner til at du bør trekke ut data med én dags ventetid.
    • Filene dine vil være enklere å arbeide med når du alltid trekker ut hele 24 timer om gangen, noe som unngår delvise dagsresultater.
    • Du vil minimere risikoen for å gå glipp av noen overvåkingshendelser. Vanligvis kommer overvåkingshendelser innen 30 minutter. Noen ganger kan noen hendelser ta opptil 24 timer å komme frem i den enhetlige overvåkingsloggen.
  • Trenger du mer enn Power BI-data? Vurder den mest effektive måten å få tilgang til det du trenger.
    • Når du bare trenger aktivitetsdata for Power BI-brukere, bruker du aktivitetsloggen for Power BI.
    • Når du trenger overvåkingslogger fra flere tjenester, bruker du API-en for administrasjonsaktivitet for Office 365 til å få tilgang til den enhetlige overvåkingsloggen.
  • Hvem vil utvikle løsningen? Planlegg å investere litt tid for å bygge ut løsningen. Det kan kreve betydelig innsats for å produsere et produksjonsklart skript.

Sjekkliste – Når du planlegger hvordan du får tilgang til brukeraktivitetsdata, omfatter viktige beslutninger og handlinger:

  • Klargjør omfanget av behov: Bestem om du bare trenger tilgang til Power BI-overvåkingsposter eller overvåkingsdata for flere tjenester.
  • Ta kontakt med IT: Finn ut om IT for øyeblikket trekker ut overvåkingslogger, og om det er mulig å få tilgang til rådataene, slik at du ikke trenger å bygge en ny løsning.
  • Bestem deg for en datakilde: Bestem den beste kilden som skal brukes til å få tilgang til brukeraktivitetsdata.
  • Fullfør et konseptbevis: Planlegg å fullføre et lite teknisk konseptbevis (POC). Bruk den til å validere avgjørelsene dine om hvordan den endelige løsningen skal bygges.
  • Spor flere databehov: Du kan koordinere aktivitetsloggdata med andre kilder for å forbedre verdien av dataene. Hold oversikt over disse mulighetene etter hvert som de oppstår, slik at de kan legges til i omfanget av prosjektet.

Få tilgang til lagerdata for leier

En leierbeholdning er en uvurderlig og nødvendig del av en moden overvåkings- og overvåkingsløsning. Det hjelper deg med å forstå hvilke arbeidsområder og innhold (semantiske modeller, rapporter og andre elementer) som finnes i Power BI, og det er et utmerket supplement til brukeraktivitetsdataene (beskrevet i forrige del). Hvis du vil ha mer informasjon om identifisering av databehov, kan du se Leierbeholdning tidligere i denne artikkelen.

Brukeraktiviteter (tidligere beskrevet) er overvåkede hendelser. de er en oppføring av handlinger som en bruker tok på en bestemt dato og klokkeslett. Leierbeholdningen er imidlertid forskjellig. Leierbeholdningen er et øyeblikksbilde på et gitt tidspunkt. Den beskriver gjeldende tilstand for alle publiserte elementer i Power Bi-tjeneste da du pakket det ut.

Merk

Power BI REST API-dokumentasjon refererer til publiserte elementer som artefakter.

Tips

Mange organisasjoner synes det er nyttig å trekke ut leierbeholdningen samtidig på dagen hver uke.

Hvis du vil analysere hva som skjer i Power BI-leieren, trenger du både brukeraktivitetsdataene og leierbeholdningen. Ved å kombinere dem kan du forstå hvor mye innhold du har og hvor det er plassert. Den lar deg også finne ubrukt eller underutnyttet innhold (fordi det ikke vil være noen hendelser for det i aktivitetsloggen). Leierbeholdningen hjelper deg også med å kompilere en liste over gjeldende navn for alle elementer, noe som er nyttig når elementnavn endres.

Hvis du vil ha mer informasjon om verdien av leierbeholdningen, kan du se Leierbeholdning tidligere i denne artikkelen.

Tips

Du kan bruke API-en Hent ubrukte artefakter som administrator til å søke etter elementer som ikke har noen brukeraktivitet de siste 30 dagene. Du kan imidlertid ikke tilpasse denne tidsperioden. Du kan for eksempel ha kritisk innhold som bare brukes kvartalsvis. Ved å kombinere leierbeholdningen med brukeraktivitetsdataene, kan du finne ubrukte elementer på måter du kan tilpasse.

Du kan hente lagerdata for leier på to forskjellige måter.

Teknikk Beskrivelse Mest egnet til Godt valg for manuelle overvåkingsprosesser Godt valg for automatiserte revisjonsprosesser
Programmatisk Get Groups as Admin API-en eller PowerShell-cmdleten Get-PowerBIWorkspace kan gi en liste over arbeidsområder for hele leieren. Enkeltelementer (for eksempel semantiske modeller og rapporter) per arbeidsområde kan også inkluderes. Mindre organisasjoner eller lavt datavolum Hent grupper som administrator-API eller Get-PowerBIWorkspace PowerShell-cmdleten er et godt valg for manuelle overvåkingsprosesser. Hent grupper som administrator-API eller Get-PowerBIWorkspace PowerShell-cmdleten er et godt valg for automatiserte overvåkingsprosesser.
Programmatisk Et sett med asynkrone API-er for administratorer, samlet kalt API-er for skanning av metadata eller skanner-API-er, kan returnere en liste over arbeidsområder og individuelle elementer. Du kan også inkludere detaljerte metadata (for eksempel tabeller, kolonner og måluttrykk). Organisasjoner med høyt datavolum og/eller et behov for å få detaljerte resultater API-er for skanning av metadata er et godt valg for automatiserte overvåkingsprosesser.

Resten av denne delen introduserer hver av teknikkene som presenteres i tabellen.

Cmdlet for gruppe-API-er eller arbeidsområder

Hvis du vil hente en liste over arbeidsområder, kan du bruke én av flere REST-API-er, for eksempel Hent grupper som administrator-API (ved hjelp av det valgte verktøyet). Resultatene inkluderer ekstra metadata, for eksempel beskrivelsen og om arbeidsområdet er lagret i en Premium-kapasitet.

Merk

API-en med navnet inkluderer termgruppen som en referanse til et arbeidsområde. Dette begrepet stammer fra den opprinnelige Power BI-sikkerhetsmodellen, som var avhengig av Microsoft 365-grupper. Selv om Power BI-sikkerhetsmodellen har utviklet seg betydelig gjennom årene, forblir de eksisterende API-navnene uendret for å unngå å bryte eksisterende løsninger.

Get Groups as Admin REST-API-en inneholder den nyttige $expand parameteren. Med denne parameteren kan du eventuelt utvide resultatene slik at de inkluderer en liste over elementer som er publisert i arbeidsområdet (for eksempel semantiske modeller og rapporter). Du kan også sende users datatypen til parameteren $expand for å inkludere brukerne som er tilordnet til en arbeidsområderolle.

Du kan også bruke Get-PowerBIWorkspace PowerShell-cmdleten. Det er fra modulen arbeidsområder for Power BI Management. Når du angir parameteren -Scopeorganization, fungerer den Get Groups as Admin som API-en. Cmdleten godtar også parameteren -Include (som tilsvarer parameteren $expand i REST-API-en) for å inkludere elementer publisert i arbeidsområdet (for eksempel semantiske modeller og rapporter).

Tips

Ved å sende inn parametere kan du bruke cmdleten på forskjellige måter. Denne delen fokuserer på å hente en beholdning for hele tenanten. Hvis du vil ha mer informasjon om hvordan du bruker parameteren -Scope , kan du se Velge en bruker-API eller administrator-API tidligere i denne artikkelen.

Hvis du vil hjelpe deg med å velge hvilket alternativ du vil bruke, kan du se Velg API-er eller PowerShell-cmdleter tidligere i denne artikkelen.

Get Groups as Admin REST-API-en eller PowerShell-cmdleten Get-PowerBIWorkspace passer best til manuelle overvåkingsprosesser og engangsundersøkelser. Større organisasjoner med høyt datavolum synes vanligvis disse alternativene er utfordrende å bruke. REST-API-en og cmdleten trekker alltid ut et fullstendig sett med data, slik at de kan ta lang tid å kjøre. Så det er også sannsynlig at større organisasjoner vil støte på begrensninger på antall forespørsler tillatt per time (kjent som begrensning, som er gjort for å beskytte tilstanden til tjenesten). API-er for skanning av metadata (beskrevet neste) gir et mer pålitelig og skalerbart alternativ.

API-er for skanning av metadata

API-er for skanning av metadata, ofte kalt skanner-API-er, er et sett med API-er som returnerer en liste over arbeidsområder og deres Power BI-elementer (semantiske modeller, rapporter og andre elementer). Begrepsmessig gir de de samme dataene (og mer) som gruppe-API-ene eller arbeidsområde-cmdleten, som er beskrevet i forrige del. Metoden du bruker til å hente dataene, er imidlertid forskjellig og bedre egnet til å trekke ut leierbeholdningen.

Merk

Legg merke til hvordan noen bruker termskanner-API-ene eller uttrykket som skanner leieren. De bruker ofte disse termene til å bety kompilering av en leierbeholdning, noe som skiller den fra brukeraktivitetshendelsene. De kan, eller kanskje ikke, bokstavelig talt referere til bruken av metadata skanning API-er.

Det er to hovedårsaker til at du bør vurdere å bruke API-ene for metadataskanning i stedet Get Groups as Admin for REST-API-en eller cmdleten Get-PowerBIWorkspace (beskrevet tidligere).

  • Trinnvis datautpakking: Skanner-API-ene trekker bare ut data som er endret siden forrige gang den ble kjørt. Rest-API-en Get Groups as Admin og cmdleten Get-PowerBIWorkspace er derimot synkrone operasjoner som trekker ut hele settet med data hver gang de kjører.
  • Mer detaljert detaljnivå: Skanner-API-ene kan hente detaljerte detaljer (for eksempel tabeller, kolonner og måluttrykk), forutsatt at tillatelse gis av de to leierinnstillingene for detaljerte metadata. Derimot er det laveste detaljnivået som er tilgjengelig med Get Groups as Admin REST-API-en, og cmdleten Get-PowerBIWorkspace etter elementtype (for eksempel en liste over rapporter i et arbeidsområde).

Bruk av skanner-API-er innebærer mer innsats fordi du må kalle opp en rekke API-er. De kjører også som en asynkron prosess. En asynkron prosess kjører i bakgrunnen, og derfor trenger du ikke vente på at den skal fullføres. Du må kanskje samarbeide med IT eller en utvikler når det er på tide å opprette et produksjonsklart skript som skal planlegges.

Her er rekkefølgen av trinnene prosessen bør følge når du bruker skanner-API-ene.

  1. Logg på: Logg på Power Bi-tjeneste ved hjelp av en Power BI-administratorkonto eller en tjenestekontohaver som har tillatelse til å kjøre administrator-API-er. Hvis du vil ha mer informasjon, kan du se Fastslå godkjenningsmetoden tidligere i denne artikkelen.
  2. Få arbeidsområde-ID-ene: Send en forespørsel om å hente en liste over arbeidsområde-ID-er. Første gang den kjøres, har du ikke en endret dato, så den returnerer en fullstendig liste over arbeidsområder. Vanligvis vil du sende den endrede datoen for å hente bare arbeidsområder som har endret seg siden det tidspunktet. Den endrede datoen må være innen de siste 30 dagene.
  3. Start en metadataskanning: Start et anrop for å be om en skanning av arbeidsområdeinformasjon ved å sende inn arbeidsområde-ID-ene som ble hentet i trinn 2. Vær oppmerksom på at dette er en POST-API (i stedet for en GET API, som er mer vanlig når du henter overvåkingsdata). En POST-API er en HTTP-forespørsel som oppretter eller skriver data for en angitt ressurs. Denne spørringen angir detaljnivået som skal trekkes ut, for eksempel datakildedetaljer, semantisk modellskjema, semantiske modelluttrykk eller brukere. Når den sendes inn, returneres en ID for skanningen av API-en. Den returnerer også datoen og klokkeslettet for skanningen, som du bør registrere som øyeblikksbildedato.
  4. Kontroller skannestatusen: Bruk skanne-ID-en som er hentet i trinn 3 for å få skannestatusen. Du må kanskje kalle dette API-et mer enn én gang. Når den returnerte statusen er fullført, kan du gå videre til neste trinn. Tiden det tar å skanne, avhenger av hvor mye data du ber om.
  5. Få resultatene: Bruk skanne-ID-en som er hentet i trinn 3 for å hente skanneresultatet og trekke ut dataene. Du må gjøre dette trinnet innen 24 timer etter at du har fullført trinn 4. Husk at tidsangivelsen for øyeblikksbildet skal være korrelert med trinn 3 i stedet for trinn 5 (når det er en betydelig forsinkelse). På den måten har du et nøyaktig tidsangivelse for øyeblikksbilde. Lagre resultatene på den foretrukne plasseringen for datalagring. Som beskrevet i denne artikkelen anbefaler vi at du lagrer rådataene i den opprinnelige tilstanden.
  6. Klargjør for neste prosess: Registrer tidsstempelet for skanningen fra trinn 3, slik at du kan bruke den i trinn 2 neste gang du kjører prosessen. Da trekker du bare ut data som er endret siden det tidspunktet. Fremover vil alle etterfølgende datautpakkinger være trinnvise endringer i stedet for fullstendige øyeblikksbilder.

Sjekkliste – Når du planlegger tilgang til leierens lagerdata, omfatter viktige beslutninger og handlinger:

  • Bekreft krav: Klargjør behov for kompilering av en leierbeholdning og de analytiske kravene for dataene.
  • Bestem hyppigheten for utpakking av leierbeholdning: Bekreft hvor ofte du trenger en ny leierbeholdning (for eksempel hver uke).
  • Bestem hvordan du trekker ut leierbeholdningen: Bekreft hvilken metode du vil bruke til å hente leierlagerdataene (API, cmdlet eller metadataskannings-API-er).
  • Fullfør et konseptbevis: Planlegg å fullføre et lite teknisk konseptbevis (POC). Bruk den til å validere avgjørelsene dine om hvordan den endelige løsningen skal bygges.

Få tilgang til bruker- og gruppedata

I tillegg til identifiseringsinformasjonen (for eksempel en e-postadresse) som er inkludert i brukeraktivitetsdataene, er det verdifullt å hente tilleggsinformasjon, for eksempel steds- eller organisasjonsdetaljer. Du kan bruke Microsoft Graph til å hente data om brukere, grupper, tjenestekontohavere og lisenser. Microsoft Graph består av et sett med API-er og klientbiblioteker som lar deg hente overvåkingsdata fra en rekke ulike tjenester.

Her er noen detaljer om Microsoft Entra-objektene du har tilgang til.

  • Bruker: En identitet som finnes i Microsoft Entra-ID som en jobb-, skole- eller Microsoft-konto. Termdomenebrukeren brukes ofte til å beskrive organisatoriske brukere, mens den formelle termen er brukerhovednavn (UPN). En UPN er vanligvis den samme verdien som brukerens e-postadresse (hvis en e-postadresse endres, endres ikke UPN fordi den er uforanderlig). Det finnes også en unik Microsoft Graph-ID for hver bruker. Ofte er en brukerkonto knyttet til én person. Noen organisasjoner oppretter brukere som er tjenestekontoer som brukes til automatiserte aktiviteter eller for administrative oppgaver.
  • Tjenestekontohaver: En annen type identitet, som klargjøres når du oppretter en appregistrering. En tjenestekontohaver er ment for uovervåkede, automatiserte aktiviteter. Hvis du vil ha mer informasjon, kan du se Fastslå godkjenningsmetoden tidligere i denne artikkelen.
  • Gruppe: En samling brukere og tjenestekontohavere. Det finnes flere typer grupper du kan bruke til å forenkle administrasjon av tillatelser. Hvis du vil ha mer informasjon, kan du se Strategi for bruk av grupper.

Merk

Når denne artikkelen refererer til brukere og grupper, omfatter denne termen tjenestekontohavere også. Denne kortere termen brukes for kortfattethet.

Brukerne og gruppedataene du henter, er et øyeblikksbilde som beskriver gjeldende tilstand på et gitt tidspunkt.

Tips

Hvis du vil ha mer informasjon om brukere, tjenestekontohavere og grupper, kan du se Integrasjon med Microsoft Entra ID.

Analytiske attributter

For power BI-overvåking på leiernivå kan du trekke ut og lagre følgende attributter fra Microsoft Graph.

  • Fullt navn på brukere: Mange datakilder inkluderer bare e-postadressen til brukeren som utførte en aktivitet eller som er tilordnet en rolle. Bruk dette attributtet når du vil vise hele navnet (visningsnavnet) i analytiske rapporter. Hvis du bruker det fullstendige navnet, blir rapportene mer brukervennlige.
  • Andre brukeregenskaper: Andre beskrivende attributter om brukere kan være tilgjengelige i Microsoft Entra ID. Noen eksempler på innebygde brukerprofilattributter som har analytisk verdi, omfatter stilling, avdeling, leder, område og kontorplassering.
  • Medlemmer av en sikkerhetsgruppe: De fleste datakilder oppgir navnet på en gruppe (for eksempel registrerer aktivitetsloggen for Power BI at en sikkerhetsgruppe ble tilordnet til en arbeidsområderolle). Hvis du henter gruppemedlemskapet, forbedres muligheten til å analysere hva en enkeltbruker gjør eller har tilgang til.
  • Brukerlisenser: Det er nyttig å analysere hvilke brukerlisenser – gratis, Power BI Pro eller Power BI Premium per bruker (PPU)– som er tilordnet brukere. Disse dataene kan hjelpe deg med å identifisere hvem som ikke bruker lisensen. Det hjelper deg også med å analysere alle brukere (distinkte brukere med en lisens) kontra aktive brukere (med nylige aktiviteter). Hvis du vurderer å legge til eller utvide Power BI Premium-lisensene, anbefaler vi at du analyserer brukerlisensdataene sammen med brukeraktivitetsdata for å utføre en kostnadsanalyse.
  • Medlemmer av administratorrollene: Du kan kompilere en liste over Power BI-administratorene (som inkluderer Power Platform-administratorer og globale administratorer).

Hvis du vil ha den autoritative referansen til Power BI-lisensinformasjon som du finner i overvåkingsdataene fra Microsoft Graph, kan du se Produktnavn og tjenesteplanidentifikatorer for lisensiering.

Tips

Henting av medlemmer fra grupper kan være en av de mest utfordrende aspektene ved å hente overvåkingsdata. Du må foreta et transitivt søk for å flate ut alle nestede medlemmer og nestede grupper. Du kan utføre et transitivt søk etter gruppemedlemmer. Denne typen søk er spesielt utfordrende når det er tusenvis av grupper i organisasjonen. I så fall kan det vurdere bedre alternativer for å hente dataene. Ett alternativ er å trekke ut alle grupper og gruppemedlemmer fra Microsoft Graph. Det kan imidlertid ikke være praktisk når bare et lite antall grupper brukes for Power BI-sikkerhet. Et annet alternativ er å forhåndsbygge en referanseliste over grupper som brukes av alle typer Power BI-sikkerhet (arbeidsområderoller, apptillatelser, deling per element, sikkerhet på radnivå og andre). Deretter kan du gå gjennom referanselisten for å hente gruppemedlemmer fra Microsoft Graph.

Her er noen andre attributter du kan trekke ut og lagre.

  • Brukertype: Brukere er enten medlemmer eller gjester. Medlemmer er vanligvis interne brukere, og gjester er eksterne (B2B)-brukere. Lagring av brukertype er nyttig når du trenger å analysere aktivitetene til eksterne brukere.
  • Rolleendringer: Når du utfører en sikkerhetsrevisjon, er det nyttig å forstå når en bruker endret roller i organisasjonen (for eksempel når de overføres til en annen avdeling). På den måten kan du bekrefte om sikkerhetsinnstillingene for Power BI har blitt – eller bør – oppdateres.
  • Deaktiverte brukere: Når en bruker forlater organisasjonen, deaktiverer vanligvis en administrator kontoen sin. Du kan opprette en prosess for å kontrollere om deaktiverte brukere er arbeidsområdeadministratorer eller semantiske modelleiere.

Tips

Power BI-aktivitetsloggen inneholder en hendelse som registrerer når en bruker registrerer seg for en prøvelisens. Du kan kombinere denne hendelsen med brukerlisensdataene (hentet fra Microsoft Entra ID) for å produsere et fullstendig bilde.

Hente brukere og grupper data

Du kan hente data om brukere og grupper på forskjellige måter.

Teknikk Beskrivelse Godt valg for manuelle overvåkingsprosesser Godt valg for automatiserte revisjonsprosesser
Manuell Graph Explorer Graph Explorer er et godt valg for manuelle overvåkingsprosesser.
Programmatisk Microsoft Graph API-er og SDK-er Microsoft Graph API-er og SDK-er er gode valg for automatiserte revisjonsprosesser.
Programmatisk Az PowerShell-modul Az PowerShell-modulen er et godt valg for automatiserte revisjonsprosesser.

Resten av denne delen introduserer hver av teknikkene som presenteres i tabellen. Andre teknikker, som er avskrevet og ikke skal brukes til nye løsninger, beskrives på slutten av denne delen.

Merk

Vær forsiktig når du leser informasjon på nettet fordi mange verktøynavn er like. Noen verktøy i Microsoft-økosystemet inkluderer begrepet Graph i navnet, for eksempel Azure Resource Graph, GraphQL og Microsoft Security Graph API. Disse verktøyene er ikke relatert til Microsoft Graph, og de er utenfor omfanget for denne artikkelen.

Microsoft Graph Explorer

Microsoft Graph Explorer er et utviklerverktøy som lar deg lære om Microsoft Graph API-er. Det er en enkel måte å komme i gang på, fordi det ikke krever andre verktøy eller oppsett på maskinen. Du kan logge på for å hente data fra leieren, eller hente eksempeldata fra en standard leier.

Du kan bruke Graph Explorer til å:

  • Send en forespørsel til en Microsoft Graph-API manuelt for å kontrollere om den returnerer informasjonen du vil bruke.
  • Se hvordan du konstruerer nettadressen, overskriftene og brødteksten før du skriver et skript.
  • Kontroller dataene på en uformell måte.
  • Bestem hvilke tillatelser som kreves for hver API. Du kan også gi samtykke til nye tillatelser.
  • Hent kodesnutter som skal brukes når du oppretter skript.

Bruk denne koblingen til å åpne Graph Explorer.

Microsoft Graph API-er og SDK-er

Bruk Microsoft Graph API-er til å hente brukere og grupper data. Du kan også bruke den til å hente data fra tjenester som Microsoft Entra ID, SharePoint Online, Teams, Exchange, Outlook og mer.

Microsoft Graph SDKs fungerer som en API-wrapper oppå de underliggende Microsoft Graph-API-ene. En SDK er et programvareutviklingssett som samler verktøy og funksjonalitet sammen. Microsoft Graph SDKs viser hele settet med Microsoft Graph-API-er.

Du kan velge å sende forespørsler direkte til API-ene. Alternativt kan du legge til et lag med forenkling ved hjelp av det foretrukne språket og en av SDK-ene. Hvis du vil ha mer informasjon, kan du se Velg API-er eller PowerShell-cmdleter tidligere i denne artikkelen.

Microsoft Graph SDKs støtter flere språk, og det finnes også Microsoft Graph PowerShell-moduler . Andre SDK-er er tilgjengelige for Python, C#og andre språk.

Viktig

Microsoft Graph PowerShell-modulen erstatter Azure AD PowerShell-modulene og MSOnline-modulene (MSOL), som begge er avskrevet. Du bør ikke opprette nye løsninger med avskrevne moduler. Microsoft Graph PowerShell-modulen har mange funksjoner og fordeler. Hvis du vil ha mer informasjon, kan du se Oppgradere fra Azure AD PowerShell til Microsoft Graph PowerShell.

Du kan installere Microsoft Graph PowerShell-modulene fra PowerShell-galleriet. Siden Microsoft Graph fungerer med mange Microsoft 365-tjenester, finnes det mange PowerShell-moduler du installerer .

Her er de vanligste PowerShell-modulene du må installere for power BI-overvåking på leiernivå.

Tips

Microsoft oppdaterer Microsoft Graph PowerShell-modulene regelmessig. Noen ganger gjøres forhåndsversjonsmoduler tilgjengelige på forhåndsversjonsbasis eller et betaendepunkt. Det kan være lurt å angi hvilken versjon du er interessert i når du installerer og oppdaterer modulene. Når du ser gjennom nettdokumentasjonen, må du også være oppmerksom på at gjeldende versjonsnummer automatisk legges til på slutten av nettadressen (så vær forsiktig når du lagrer eller deler nettadresser).

Az PowerShell-modul

Du kan også bruke Az PowerShell-modulen til å hente brukere og grupper data. Den fokuserer på Azure-ressurser.

Viktig

Az PowerShell-modulen erstatter AzureRM PowerShell-modulene, som er avskrevet. Du bør ikke opprette nye løsninger med avskrevne moduler.

Du kan bruke invoke-AzRestMethod-cmdleten når det ikke finnes en tilsvarende cmdlet for en API. Det er en fleksibel tilnærming som lar deg sende en forespørsel til en Microsoft Graph API ved hjelp av Az PowerShell-modulen.

Fra og med Az versjon 7 refererer Az-cmdletene nå til Microsoft Graph-API-en. Az-modulen fungerer derfor som en API-wrapper oppå Microsoft Graph. Az-modulene har et delsett av funksjonalitet som finnes i Modulene Microsoft Graph API-er og PowerShell. For nye løsninger anbefaler vi at du bruker Microsoft Graph PowerShell SDK.

Avskrevne API-er og moduler

Det kan hende du finner artikler og blogginnlegg på nettet som foreslår alternative alternativer som ikke presenteres i denne delen. Vi anbefaler på det sterkeste at du ikke oppretter nye løsninger (og/eller overfører eksisterende løsninger) ved hjelp av følgende API-er eller moduler.

  • AzureRM PowerShell-moduler: Avskrevet og vil bli fjernet. De har blitt erstattet med Az PowerShell-modulen.
  • Azure AD Graph API og Azure AD PowerShell-modulen: Avskrevet og vil bli fjernet. Denne endringen er resultatet av overføringen fra Azure AD Graph til Microsoft Graph (vær oppmerksom på at Graph vises i begge navnene, men Microsoft Graph er den fremtidige retningen). Alle fremtidige PowerShell-investeringer vil bli gjort i Microsoft Graph PowerShell SDK. (Microsoft Entra ID er nå kjent som Microsoft Entra ID.)
  • MS Online (MSOL) PowerShell-modul: Avskrevet og vil bli fjernet. Alle fremtidige PowerShell-investeringer vil bli gjort i Microsoft Graph PowerShell SDK.

Forsiktig!

Pass på at du bekrefter statusen for en avskrevet API eller modul du bruker for øyeblikket. Hvis du vil ha mer informasjon om pensjonering av AzureRM, kan du se denne kunngjøringen.

Hvis du vil ha mer informasjon om Microsoft Entra ID og MSOL, kan du se dette innlegget om kunngjøring om avvikling.

Hvis du har spørsmål eller krever en avklaring om den fremtidige retningen for programmatisk datatilgang, kan du kontakte Microsoft-kontoteamet.

Sjekkliste – Når du planlegger å få tilgang til brukere og grupper data, omfatter viktige beslutninger og handlinger:

  • Bekreft krav: Klargjør behov for kompilering av data relatert til brukere, grupper og lisenser.
  • Prioriter krav: Bekreft hva de viktigste prioriteringene er, slik at du vet hva du skal bruke tid på først.
  • Bestem deg for hyppigheten for å trekke ut data: Bestem hvor ofte du trenger et nytt øyeblikksbilde av brukere og grupper data (for eksempel hver uke eller hver måned).
  • Bestem hvordan du trekker ut data med Microsoft Graph: Bestem hvilken metode du vil bruke til å hente dataene.
  • Fullfør et konseptbevis: Planlegg å fullføre et lite teknisk konseptbevis (POC) for å trekke ut brukere og grupper data. Bruk den til å validere avgjørelsene dine om hvordan den endelige løsningen skal bygges.

Få tilgang til data fra REST-API-er for Power BI

Kanskje som en lavere prioritet, kan du også hente andre data ved hjelp av REST-API-ene for Power BI.

Du kan for eksempel hente data om:

Under en sikkerhetsrevisjon vil du kanskje identifisere:

Hvis du vil ha mer informasjon om de andre typene API-er, kan du se Velge en bruker-API eller administrator-API tidligere i denne artikkelen.

Sjekkliste – Når du planlegger å få tilgang til data fra Power BI-API, omfatter viktige beslutninger og handlinger:

  • Få krav: Kompiler analytiske krav etter hvert som de oppstår. Hold oversikt over dem i etterslepet.
  • Prioriteringskrav: Angi prioriteringer for de nye kravene som oppstår.

Fase 2: Forutsetninger og oppsett

Den andre fasen av planlegging og implementering av en overvåkingsløsning på leiernivå fokuserer på forutsetninger og oppsett som må gjøres før du begynner løsningsutviklingen.

Flytdiagram som beskriver fase 2, som fokuserer på forutsetninger og oppsett for å bygge en overvåkingsløsning på leiernivå.

Opprett lagringskonto

På dette tidspunktet har du bestemt deg for å lagre rådata og hvordan du oppretter kuraterte data. Basert på disse beslutningene er du nå klar til å opprette en lagringskonto. Avhengig av organisasjonens prosesser, kan det innebære å sende inn en forespørsel til IT.

Som beskrevet tidligere anbefaler vi at du bruker en teknologi som lar deg skrive rådata til uforanderlig lagringsplass. Når dataene er skrevet, kan de ikke endres eller slettes. Du kan da ha tillit til rådataene fordi du vet at en administrator med tilgang ikke kan endre dem på noen måte. De kuraterte dataene må imidlertid ikke (vanligvis) lagres i uforanderlig lagring. Kuraterte data kan endres, eller de kan genereres på nytt.

Sjekkliste – Når du oppretter en lagringskonto, omfatter viktige beslutninger og handlinger:

  • Opprett en lagringskonto: Opprett eller send inn en forespørsel for å opprette en lagringskonto. Bruk uforanderlige lagringsinnstillinger for rådataene når det er mulig.
  • Angi tillatelser: Bestem hvilke tillatelser som skal angis for lagringskontoen.
  • Testtilgang: Gjør en liten test for å sikre at du kan lese og skrive til lagringskontoen.
  • Bekreft ansvarsområder: Sørg for at du er tydelig på hvem som administrerer lagringskontoen kontinuerlig.

Installere programvare og konfigurere tjenester

Nå har du tatt avgjørelsene dine om hvilken teknologi du skal bruke for å få tilgang til overvåkingsdata. Basert på disse beslutningene er du nå klar til å installere programvare og konfigurere tjenester.

Konfigurer det foretrukne utviklingsmiljøet for hver administrator. Utviklingsmiljøet gjør det mulig for dem å skrive og teste skript. Visual Studio Code er et moderne verktøy for utvikling av skript, så det er et godt alternativ. Mange utvidelser er også tilgjengelige for arbeid med Visual Studio Code.

Hvis du har tatt beslutningen (tidligere beskrevet) om å bruke PowerShell, bør du installere PowerShell Core og de nødvendige PowerShell-modulene på:

  • Maskinen til hver administrator/utvikler som skal skrive eller teste revisjonsskript.
  • Hver virtuelle maskin eller server som skal kjøre planlagte skript.
  • Hver nettjeneste (for eksempel Azure Functions eller Azure Automation).

Hvis du har valgt å bruke azure-tjenester (for eksempel Azure Functions, Azure Automation, Azure Data Factory eller Azure Synapse Analytics), bør du klargjøre og konfigurere dem også.

Sjekkliste – Når du installerer programvare og konfigurerer tjenester, omfatter viktige beslutninger og handlinger:

  • Konfigurer administrator-/utviklermaskiner: Hvis det er aktuelt, må du installere de nødvendige verktøyene som skal brukes til utvikling.
  • Konfigurer servere: Hvis aktuelt, installerer du de nødvendige verktøyene på servere eller virtuelle maskiner som finnes i arkitekturen.
  • Konfigurer Azure-tjenester: Hvis aktuelt, klargjør og konfigurer hver Azure-tjeneste. Tilordne tillatelser for hver administrator/utvikler som skal utføre utviklingsarbeid.

Registrere et Microsoft Entra-program

Nå har du bestemt deg for hvordan du skal godkjenne. Vi anbefaler at du registrerer et Microsoft Entra-program (tjenestekontohaver). Vanligvis kalt en appregistrering, bør den brukes til uovervåkede operasjoner som du automatiserer.

Hvis du vil ha mer informasjon om hvordan du oppretter en appregistrering for å hente overvåkingsdata på leiernivå, kan du se Aktivere tjenestekontohavergodkjenning for skrivebeskyttede administrator-API-er.

Sjekkliste – Når du registrerer et Microsoft Entra-program, omfatter viktige beslutninger og handlinger:

  • Kontroller om det finnes en eksisterende appregistrering: Kontroller med IT om en eksisterende appregistrering er tilgjengelig med det formål å kjøre administrator-API-er. I så fall må du avgjøre om den eksisterende skal brukes, eller om en ny skal opprettes.
  • Opprett en ny appregistrering: Opprett en appregistrering når det er aktuelt. Vurder å bruke et appnavn, for eksempel PowerBI-AdminAPIs-EntraApp, som tydelig beskriver formålet.
  • Opprett en hemmelighet for appregistreringen: Når appregistreringen finnes, oppretter du en hemmelighet for den. Angi utløpsdatoen basert på hvor ofte du har tenkt å rotere hemmeligheten.
  • Lagre verdiene på en sikker måte: Lagre hemmeligheten, app-ID-en (klient-ID) og leier-ID-en på en sikker måte, fordi du trenger dem til å godkjenne med tjenestekontohaveren. Bruk en plassering som er sikker, for eksempel et organisatorisk passordhvelv. (Hvis du må be om oppretting av en appregistrering fra IT, angir du at du trenger disse verdiene returnert til deg.)
  • Opprett en sikkerhetsgruppe: Opprett (eller be om) en sikkerhetsgruppe som skal brukes for Power BI. Vurder å bruke gruppenavn, for eksempel tjenestekontohavere for Power BI-administratorer, noe som betyr at gruppen vil bli brukt til å få tilgang til metadata for hele tenanten.
  • Legg til tjenestekontohaveren som medlem av sikkerhetsgruppen: Bruk app-ID -en (klient-ID) til å legge til den nye (eller eksisterende) tjenestekontohaveren som medlem av den nye sikkerhetsgruppen.
  • Oppdater administrator-API-leierinnstillingen i Power BI: Legg til sikkerhetsgruppen i leierinnstillingene for Power BI-administratorer i administrasjonsportalen for Power BI .
  • Hopp over tilordning av tillatelser i Azure: Ikke deleger noen tillatelser til appregistreringen (den får tilgang til overvåkingsdataene på leiernivå i Power BI ved hjelp av Power BI Tillat tjenestekontohavere å bruke skrivebeskyttet leierinnstilling for Power BI-administratorer ).
  • Bestem om appregistreringen skal få tilgang til detaljerte metadata: Bestem om du vil trekke ut detaljert informasjon om semantiske modelltabeller, kolonner og måluttrykk når du bygger leierbeholdningen.
  • Oppdater de detaljerte leierinnstillingene for metadata i Power BI: I administrasjonsportalen for Power BI kan du eventuelt legge til sikkerhetsgruppen i API-svarene for forbedre administrator med detaljerte leierinnstillinger for metadata , og også API-svar for administratorer med leierinnstillingen for DAX- og mashup-uttrykk.
  • Test tjenestekontohaveren: Opprett et enkelt skript for å logge på ved hjelp av tjenestekontohaveren, og test at det kan hente data fra en administrator-API.
  • Opprett en prosess for å behandle appregistreringshemmeligheter: Opprett dokumentasjon og en prosess for regelmessig å rotere hemmeligheter. Bestem hvordan du trygt vil formidle en ny hemmelighet til alle administratorer og utviklere som trenger den.

Angi leierinnstillinger for Power BI

Det finnes flere leierinnstillinger i administrasjonsportalen for Power BI som er relevante for utpakking av overvåkingsdata på leiernivå.

API-er for administratorer

Det finnes tre leierinnstillinger som er relevante for kjøring av API-er for administratorer.

Viktig

Fordi disse innstillingene gir metadatatilgang for hele leieren (uten å tilordne direkte Power BI-tillatelser), bør du kontrollere dem tett.

Med leierinnstillingen Tillat tjenestekontohavere å bruke skrivebeskyttede API-er for Power BI-administratorer kan du angi hvilke tjenestekontohavere som kan kalle administrator-API-er. Denne innstillingen gjør det også mulig for Microsoft Purview å skanne hele Power BI-leieren slik at den kan fylle ut datakatalogen.

Merk

Du trenger ikke eksplisitt å tilordne andre Power BI-administratorer til Tillat tjenestekontohavere å bruke skrivebeskyttet leierinnstilling for Power BI-administratorer fordi de allerede har tilgang til metadata for hele leieren.

Med API-svarene for forbedre administrator med detaljert leierinnstilling for metadata kan du angi hvilke brukere og tjenestekontohavere som kan hente detaljerte metadata. Metadata hentes ved hjelp av API-ene for skanning av metadata, og inneholder tabeller, kolonner og mer. Denne innstillingen gjør det også mulig for Microsoft Purview å få tilgang til informasjon på skjemanivå om Semantiske Modeller for Power BI, slik at den kan lagre den i datakatalogen.

Med tenantinnstillingen Forbedre administrator-API-svar med DAX- og mashup-uttrykk kan du angi hvilke brukere og tjenestekontohavere som kan hente detaljerte metadata. Metadata hentes fra API-ene for skanning av metadata, og det kan inneholde spørringer og semantiske modellmåluttrykk.

Merk

Tillat tjenestekontohavere å bruke skrivebeskyttet leierinnstilling for Power BI-administrator-API-er handler spesifikt om tilgang til administrator-API-er. Navnet er svært likt leierinnstillingen som er ment for tilgang til bruker-API-er (beskrevet neste). Hvis du vil ha mer informasjon om forskjellen mellom API-er for administratorer og bruker-API-er, kan du se Velge en bruker-API eller administrator-API tidligere i denne artikkelen.

Bruker-API-er

Det finnes én leierinnstilling som gjelder for anrop av bruker-API-er. I denne situasjonen kreves også Power BI-tillatelser for tjenestekontohaveren (for eksempel en arbeidsområderolle).

Med leierinnstillingen Tillat tjenestekontohavere å bruke Power BI-API s tenant kan du angi hvilke tjenestekontohavere som har tilgang til å kjøre REST-API-er (unntatt administrator-API-ene, som gis av en annen leierinnstilling, beskrevet ovenfor).

Det finnes andre leierinnstillinger relatert til API-er, som gir tilgang til API-ene for innebygging, strømming av API-er, eksport-API-er og API-ene for kjøringsspørringer . Disse API-ene er imidlertid utenfor omfanget for denne artikkelen.

Hvis du vil ha mer informasjon om leierinnstillingene for bruksmetrikk, kan du se Overvåking på rapportnivå.

Sjekkliste – Når du konfigurerer leierinnstillingene for Power BI, omfatter viktige beslutninger og handlinger:

  • Kontroller at hver tjenestekontohaver er i riktig gruppe: Bekreft at tjenestekontohavergruppen for Power BI inneholder de riktige tjenestekontohaverne.
  • Oppdater administrator-API-leierinnstillingen i Power BI: Legg til sikkerhetsgruppen i Tillat tjenestekontohavere å bruke skrivebeskyttet leierinnstilling for Power BI-administratorer , som gjør det mulig å bruke administrator-API-ene til å hente metadata for hele tenanten.
  • Oppdater de detaljerte leierinnstillingene for metadata i Power BI: Hvis det er nødvendig, kan du legge til sikkerhetsgruppen i API-svarene for forbedre administrator med detaljerte tenantinnstillinger for metadata og API-svar for forbedre administrator med leierinnstillingen for DAX- og mashup-uttrykk.
  • Bekreft hvilke bruker-API-er som skal åpnes: Kontroller om det er behov for én eller flere bruker-API-er (i tillegg ved hjelp av administrator-API-er).
  • Oppdater innstillingen for bruker-API-tenanten i Power BI: Legg til sikkerhetsgruppen i Tillat tjenestekontohavere å bruke Power BI-API s-leierinnstillingen, som er ment for bruker-API-er.

Fase 3: Løsningsutvikling og analyse

Den tredje fasen av planlegging og implementering av en revisjonsløsning på leiernivå fokuserer på løsningsutvikling og analyse. På dette tidspunktet har all planlegging og beslutningstaking skjedd, og du har møtt forutsetninger og fullført oppsettet. Nå er du klar til å starte løsningsutvikling, slik at du kan utføre analyser og få innsikt fra overvåkingsdataene.

Flytdiagram som beskriver fase 3, som fokuserer på løsningsutvikling og analyse av en overvåkingsløsning på leiernivå.

Trekke ut og lagre rådataene

På dette tidspunktet bør dine krav og prioriteringer være klare. De viktigste tekniske beslutningene er tatt om hvordan du får tilgang til overvåkingsdata og plasseringen for å lagre overvåkingsdata. Foretrukne verktøy er valgt, og forutsetningene og innstillingene er konfigurert. I løpet av de to foregående fasene kan det hende du har fullført ett eller flere små prosjekter (konseptbevis) for å bevise muligheten. Det neste trinnet er å konfigurere en prosess for å trekke ut og lagre de rå overvåkingsdataene.

Som med data som returneres av de fleste Microsoft-API-er, formaterer overvåkingsdata som JSON. JSON-formaterte data er selvbeskrivende fordi det er menneskelig lesbar tekst som inneholder struktur og data.

JSON representerer dataobjekter som består av attributtverdipar og matriser. Er for eksempel "state": "Active" et eksempel der attributtverdien for tilstand er aktiv. En JSON-matrise inneholder en ordnet liste over elementer atskilt med komma og som er omsluttet av hakeparenteser ([ ]). Det er vanlig å finne nestede matriser i JSON-resultater. Når du blir kjent med den hierarkiske strukturen til et JSON-resultat, er det enkelt å forstå datastrukturen, for eksempel en liste (matrise) av semantiske modeller i et arbeidsområde.

Her er noen vurderinger for når du trekker ut og lagrer rådataene som hentes fra API-ene.

  • Hvilken navnekonvensjon vil bli brukt? En navnekonvensjon er nødvendig for filer, mapper og datainnsjøsoner for et filbasert system. En navnekonvensjon er nødvendig for tabeller og kolonner for en database.
  • Hvilket format brukes til å lagre rådataene? Etter hvert som Power BI fortsetter å introdusere nye funksjoner, vises nye aktiviteter som ikke finnes i dag. Derfor anbefaler vi at du trekker ut og beholder de opprinnelige JSON-resultatene. Ikke analyser, filtrer eller formater dataene mens de trekkes ut. På den måten kan du bruke de opprinnelige rådataene til å generere kuraterte overvåkingsdata på nytt.
  • Hvilken lagringsplassering vil bli brukt? En datainnsjø eller blob-lagring brukes vanligvis til å lagre rådata. Hvis du vil ha mer informasjon, kan du se Finne ut hvor overvåkingsdata skal lagres tidligere i denne artikkelen.
  • Hvor mye historie vil du lagre? Eksporter overvåkingsdataene til en plassering der du kan lagre loggen. Planlegg å samle minst to års historie. På den måten kan du analysere trender og endringer utover standard 30-dagers oppbevaringsperiode. Du kan velge å lagre dataene på ubestemt tid, eller du kan bestemme deg for en kortere periode, avhengig av policyene for dataoppbevaring for organisasjonen.
  • Hvordan sporer du når prosessen sist kjørte? Konfigurer en konfigurasjonsfil, eller tilsvarende, for å registrere tidsangivelsene når en prosess starter og fullføres. Neste gang prosessen kjøres, kan den hente disse tidsangivelsene. Det er spesielt viktig at du lagrer tidsangivelser når du trekker ut data ved hjelp av API-er for skanning av metadata.
  • Hvordan vil du håndtere begrensning? Noen REST-API-er for Power BI og Microsoft Graph API implementerer begrensning. Du får en 429-feil (for mange forespørsler) hvis API-forespørselen er begrenset. Begrensning kan være et vanlig problem for større organisasjoner som trenger å hente et stort datavolum. Hvordan du unngår mislykkede forsøk på grunn av begrensning, avhenger av teknologien du bruker til å få tilgang til og trekke ut dataene. Ett alternativ er å utvikle logikk i skriptene som svarer på en feilmelding på 429 «For mange forespørsler» ved å prøve på nytt etter en ventetid.
  • Er overvåkingsdataene nødvendige for samsvar? Mange organisasjoner bruker de rå overvåkingsloggpostene til å utføre samsvarsrevisjoner eller til å svare på sikkerhetsundersøkelser. I slike tilfeller anbefaler vi på det sterkeste at du lagrer rådataene i uforanderlig lagring. På den måten, når dataene er skrevet, kan de ikke endres eller slettes av en administrator eller annen bruker.
  • Hvilke lagringslag er nødvendige for å støtte kravene dine? De beste stedene å lagre rådata er en datainnsjø (for eksempel Azure Data Lake Storage Gen2) eller objektlagring (for eksempel Azure Blob Storage). Et filsystem kan også brukes hvis skytjenester ikke er et alternativ.

Sjekkliste – Når du trekker ut og lagrer rådataene, omfatter viktige beslutninger og handlinger:

  • Bekreft krav og prioriteringer: Klargjør kravene og prioriteringene for dataene du vil trekke ut først.
  • Bekreft datakilden som skal trekkes ut: Kontroller kilden for hver type data du trenger.
  • Konfigurer en prosess for å trekke ut dataene og laste dem inn i rådatasonen: Opprett den første prosessen for å trekke ut og laste inn rådataene i den opprinnelige tilstanden, uten transformasjoner. Test at prosessen fungerer som den skal.
  • Opprett en tidsplan for å kjøre prosessene: Konfigurer en regelmessig tidsplan for å kjøre prosessene for å trekke ut, laste inn og transformere.
  • Kontroller at legitimasjonen administreres på en sikker måte: Bekreft at passord, hemmeligheter og nøkler lagres og kommuniseres på sikre måter.
  • Bekreft at sikkerheten er riktig konfigurert: Kontroller at tilgangstillatelsene er riktig konfigurert for rådataene. Sørg for at administratorer og revisorer har tilgang til rådata.

Hvis du vil ha mer informasjon om hvordan en overvåkings- og overvåkingsløsning vokser over tid, kan du se Operasjonalisere og forbedre senere i denne artikkelen.

Opprett de kuraterte dataene

På dette tidspunktet trekkes rådataene ut og lagres. Neste trinn er å opprette et eget gulldatalag for de kuraterte dataene. Målet er å transformere og lagre datafilene i et stjerneskjema. Et stjerneskjema består av dimensjonstabeller og faktatabeller, og det er bevisst optimalisert for analyse og rapportering. Filene i det kuraterte datalaget blir kilden til en Power BI-datamodell (beskrevet i neste emne).

Tips

Når du forventer at det skal være mer enn én datamodell, er det spesielt nyttig å investere i et sentralisert kuratert datalag.

Sjekkliste – Når du oppretter det kuraterte datalaget, omfatter viktige beslutninger og handlinger:

  • Bekreft krav og prioriteringer: Hvis du har tenkt å bruke et mellomliggende sølvlag for de transformerte dataene, må du klargjøre kravene og målene for det du trenger for å oppnå.
  • Konfigurer en prosess for å transformere rådataene og laste dem inn i den kuraterte datasonen: Opprett en prosess for å transformere og laste inn dataene til et stjerneskjema. Test at prosessen fungerer som den skal.
  • Opprett en tidsplan for å kjøre prosessene: Konfigurer en regelmessig tidsplan for å fylle ut det kuraterte datalaget.
  • Bekreft at sikkerheten er riktig konfigurert: Kontroller at tilgangstillatelser er riktig konfigurert for de kuraterte dataene. Sørg for at utviklere av datamodellen har tilgang til de kuraterte dataene.

Opprette en datamodell

Emnet handler om å konfigurere en analytisk datamodell. En datamodell er dataressursoptimalisert for spørring for analyse. Noen ganger kalles det en semantisk modell, eller bare en modell. For overvåkings- og overvåkingsløsningen vil datamodellen sannsynligvis bli implementert som en semantisk Power BI-modell.

I sammenheng med overvåking og overvåking henter en datamodell data fra det kuraterte (gull) datalaget. Hvis du velger å ikke opprette et kuratert datalag, henter datamodellen dataene direkte fra rådataene.

Vi anbefaler at Power BI-datamodellen implementerer en utforming av stjerneskjema. Når kildedataene er det kuraterte datalaget, bør stjerneskjemaet for Power BI-datamodellen speile det kuraterte datalagsstjerneskjemaet.

Tips

Hvis du vil ha en oversikt over utforming av stjerneskjema, kan du se Forstå stjerneskjema og viktigheten for Power BI.

Som med alle Power BI-prosjekter er oppretting av en datamodell en iterativ prosess. Du kan legge til nye mål etter behov. Du kan også legge til nye tabeller og kolonner etter hvert som nye overvåkingshendelser blir tilgjengelige. Med tiden kan du til og med integrere nye datakilder.

Her er noen nyttige dimensjonstabeller som du kan inkludere i datamodellen.

  • Dato: Et sett med datoattributter for å aktivere analyse (oppdeling og diktering) av data etter dag, uke, måned, kvartal, år og andre relevante tidsperioder.
  • Tid: Hvis du trenger å analysere etter klokkeslett og du har et svært stort volum med overvåkingsdata, bør du vurdere å lagre tidsdelen separat fra datoen. Denne fremgangsmåten kan bidra til å forbedre spørringsytelsen.
  • Brukere: Attributter som beskriver brukere (for eksempel avdeling og geografisk område) som kan filtrere mange emner med overvåkingsdata. Målet er å fjerne alle brukerdetaljer fra faktatabellene og lagre dem i denne dimensjonstabellen, slik at de kan filtrere mange faktatabeller. Du kan også lagre tjenestekontohavere i denne tabellen.
  • Aktivitetshendelser: Attributter som grupperer og beskriver aktivitetshendelsene (operasjoner). Hvis du vil forbedre rapporteringen, kan du opprette en dataordliste som beskriver hver aktivitetshendelse. Du kan også opprette et hierarki som grupperer og klassifiserer lignende aktivitetshendelser. Du kan for eksempel gruppere alle elementopprettingshendelser, slette hendelser og så videre.
  • Arbeidsområder: En liste over arbeidsområder i leier- og arbeidsområdeegenskapene, for eksempel type (personlig eller standard) og beskrivelse. Noen organisasjoner registrerer flere detaljer om arbeidsområder (muligens ved hjelp av en SharePoint-liste). Du kan integrere disse detaljene i denne dimensjonstabellen. Du må avgjøre om denne dimensjonstabellen bare lagrer gjeldende tilstand for arbeidsområdet, eller om den lagrer versjonsdata som gjenspeiler betydelige endringer i arbeidsområdet over tid. Når for eksempel et arbeidsområdenavn endres, viser historisk rapportering gjeldende arbeidsområdenavn eller arbeidsområdenavnet som var gjeldende på det tidspunktet? Hvis du vil ha mer informasjon om versjonskontroll, kan du se Endre dimensjoner sakte.
  • Elementtyper: En liste over Power BI-elementtyper (semantiske modeller, rapporter og andre).
  • Kapasiteter: En liste over Premium-kapasiteter i leieren.
  • Gatewayer: En liste over datagatewayer i leieren.
  • Datakilder: En liste over datakilder som brukes av en semantisk modell, dataflyt eller datamart.

Her er noen nyttige faktatabeller (emner) som du kan inkludere i datamodellen.

  • Brukeraktiviteter: Faktadataene som er hentet fra de opprinnelige JSON-dataene. Alle attributter som ikke har en analyseverdi, fjernes. Alle attributter som hører til i dimensjonstabellene (ovenfor), fjernes også.
  • Leierbeholdning: Et øyeblikksbilde av alle elementer som er publisert i leieren. Hvis du vil ha mer informasjon, kan du se Leierbeholdning tidligere i denne artikkelen.
  • Semantiske modeller: Inkluderer brukeraktivitet som involverer semantiske modeller (for eksempel semantiske modellendringer) eller relaterte datakilder.
  • Semantiske modelloppdateringer: Lagrer dataoppdateringsoperasjoner, inkludert detaljer om type (planlagt eller behovsbetinget), varighet, status og hvilken bruker som startet operasjonen.
  • Arbeidsområderoller: Et øyeblikksbilde av rolletilordninger for arbeidsområde.
  • Brukerlisenser: Et øyeblikksbilde av brukerlisenser på et tidspunkt. Selv om du kan bli fristet til å lagre brukerlisensen i dimensjonstabellen Brukere , støtter ikke denne tilnærmingen analysen av lisensendringer og trender over tid.
  • Brukergruppemedlemskap: Et øyeblikksbilde av brukere (og tjenestekontohavere) som er tilordnet til en sikkerhetsgruppe.
  • Fellesskapsaktiviteter: Omfatter fellesskapsrelaterte fakta, for eksempel opplæringsarrangementer. Du kan for eksempel analysere Power BI-brukeraktiviteter sammenlignet med opplæringsdeltakelse. Disse dataene kan hjelpe Center of Excellence med å identifisere potensielle nye mestere.

Faktatabeller bør ikke inneholde kolonner som rapportopprettere filtrerer. I stedet tilhører disse kolonnene relaterte dimensjonstabeller. Ikke bare er denne utformingen mer effektiv for spørringer, men den fremmer også gjenbruk av dimensjonstabeller med flere fakta (kjent som drill over). Det siste punktet er viktig for å produsere en nyttig og brukervennlig datamodell som er utvidbar når du legger til nye faktatabeller (emner).

Dimensjonstabellen Brukere vil for eksempel være relatert til alle faktatabeller. Det bør være relatert til faktatabellen for brukeraktiviteter (som utførte aktiviteten), faktatabellen for leierlager (som opprettet det publiserte elementet) og alle andre faktatabeller. Når en rapport filtreres av en bruker i dimensjonstabellen Brukere , kan visualobjekter i rapporten vise fakta for denne brukeren fra en relatert faktatabell.

Når du utformer modellen, må du kontrollere at et attributt er synlig én gang, og bare én gang, i modellen. Brukerens e-postadresse skal for eksempel bare være synlig i dimensjonstabellen Brukere . Det finnes også i andre faktatabeller (som en dimensjonsnøkkel for å støtte en modellrelasjon). Du bør imidlertid skjule den i hver faktatabell.

Vi anbefaler at du oppretter datamodellen atskilt fra rapporter. Frakoblingen av en semantisk modell og rapportene resulterer i en sentralisert semantisk modell som kan betjene mange rapporter. Hvis du vil ha mer informasjon om hvordan du bruker en delt semantisk modell, kan du se det administrerte selvbetjente BI-bruksscenarioet .

Vurder å konfigurere sikkerhet på radnivå (RLS) slik at andre brukere – utenfor Kompetansesenteret, revisorer og administratorer – kan analysere og rapportere om overvåkingsdata. Du kan for eksempel bruke RLS-regler til å la innholdsopprettere og forbrukere rapportere om sine egne brukeraktiviteter eller utviklingsarbeid.

Sjekkliste – Når du oppretter datamodellen, omfatter viktige beslutninger og handlinger:

  • Planlegge og opprette datamodellen: Utforme datamodellen som et stjerneskjema. Valider relasjoner fungerer som tiltenkt. Etter hvert som du utvikler modellen, oppretter du iterativt mål og legger til flere data basert på analytiske krav. Inkluder fremtidige forbedringer på en etterslep, når det er nødvendig.
  • Konfigurer RLS: Hvis du har tenkt å gjøre datamodellen tilgjengelig for andre generelle brukere, konfigurerer du sikkerhet på radnivå for å begrense datatilgang. Valider at RLS-rollene returnerer de riktige dataene.

Forbedre datamodellen

Hvis du vil analysere innholdsbruk og brukeraktiviteter effektivt, anbefaler vi at du beriker datamodellen. Forbedringer for datamodell kan gjøres gradvis og iterativt over tid etter hvert som du oppdager muligheter og nye krav.

Opprett klassifiseringer

Én måte å forbedre modellen og øke verdien av dataene på, er å legge til klassifiseringer i datamodellen. Sørg for at disse klassifiseringene brukes konsekvent av rapportene dine.

Du kan velge å klassifisere brukere basert på bruksnivået, eller for å klassifisere innhold basert på bruksnivået.

Brukerbruksklassifisering

Vurder følgende klassifiseringer for brukerbruk.

  • Hyppig bruker: Aktivitet registrert den siste uken, og i ni av de siste 12 månedene.
  • Aktiv bruker: Aktivitet registrert den siste måneden.
  • En og annen bruker: Aktivitet registrert de siste ni månedene, men uten aktivitet den siste måneden.
  • Inaktiv bruker: Ingen aktivitet registrert de siste ni månedene.

Tips

Det er nyttig å vite hvem sporadiske eller inaktive brukere er, spesielt når de har Pro- eller PPU-lisenser (som innebærer kostnader). Det er også nyttig å vite hvem dine vanlige og mest aktive brukere er. Vurder å invitere dem til å bli med på kontortid eller delta på opplæring. De mest aktive innholdsoppretterne kan være kandidater til å bli med i mesternettverket.

Innholdsbruksklassifisering

Vurder følgende klassifiseringer for innholdsbruk.

  • Ofte brukt innhold: Aktivitet registrert den siste uken, og i ni av de siste 12 månedene.
  • Aktivt brukt innhold: Aktivitet registrert den siste måneden.
  • Av og til brukt innhold: Aktivitet registrert de siste ni månedene, men uten aktivitet den siste måneden.
  • Ubrukt innhold: Ingen aktivitet registrert i løpet av de siste ni månedene.
Klassifisering av brukertype

Vurder følgende klassifiseringer for brukertype.

  • Innholdsoppretter: Aktivitet registrert i løpet av de siste seks månedene som har opprettet, publisert eller redigert innhold.
  • Innholdsvisningsprogram: Aktivitet registrert i løpet av de siste seks månedene som viste innhold, men uten innholdsopprettingsaktivitet.

Du bør bestemme om bruksklassifiseringene for brukere eller innhold bare skal baseres på hvor nylig en aktivitet oppstod. Det kan være lurt å vurdere å ta hensyn til gjennomsnittlig eller populær bruk over tid.

Vurder noen eksempler som viser hvordan enkel klassifiseringslogikk kan gi en feilaktig fremstilling av virkeligheten.

  • En leder viste én rapport denne uken. Men før denne uken hadde ikke lederen sett noen rapporter i løpet av de siste seks månedene. Du bør ikke anse denne lederen for å være en hyppig bruker basert på nylig bruk alene.
  • En rapportoppretter publiserer en ny rapport hver uke. Når du analyserer bruk av vanlige brukere, ser rapportoppretterens vanlige aktivitet ut til å være positiv. Etter videre undersøkelser oppdager du imidlertid at denne brukeren har publisert en ny rapport på nytt (med et nytt rapportnavn) hver gang de redigerer rapporten. Det ville være nyttig for rapportoppretteren å ha mer opplæring.
  • En leder ser en rapport sporadisk, og derfor endres bruksklassifiseringen ofte. Det kan hende du må analysere bestemte typer brukere, for eksempel ledere, på en annen måte.
  • En intern revisor ser kritiske rapporter én gang i året. Den interne revisoren kan se ut til å være en inaktiv bruker på grunn av den sjeldne bruken. Noen kan utføre trinn for å fjerne Pro- eller PPU-lisensen. Eller noen tror kanskje at en rapport bør trekkes tilbake siden den brukes sjelden.

Tips

Du kan beregne gjennomsnitt og trender ved hjelp av DAX-tidsintelligensfunksjonene. Hvis du vil lære hvordan du bruker disse funksjonene, kan du arbeide gjennom læringsmodulen Bruk DAX-tidsintelligens i Power BI Desktop-modeller .

Sjekkliste – Når du oppretter klassifisering av bruksdata, omfatter viktige beslutninger og handlinger:

  • Få konsensus om klassifiseringsdefinisjoner: Diskuter klassifiseringsdefinisjoner med de relevante interessentene. Sørg for at det er enighet når du tar beslutningene.
  • Opprett dokumentasjon: Sørg for at klassifiseringsdefinisjonene er inkludert i dokumentasjonen for innholdsopprettere og forbrukere.
  • Opprett en tilbakemeldingssløyfe: Kontroller at det er mulig for brukere å stille spørsmål eller foreslå endringer i klassifiseringsdefinisjonene.

Opprette analytiske rapporter

På dette tidspunktet er overvåkingsdataene trukket ut og lagret, og du har publisert en datamodell. Det neste trinnet er å opprette analytiske rapporter.

Fokuser på den viktigste informasjonen som er mest relevant for hver målgruppe. Du kan ha flere målgrupper for overvåkingsrapportene. Hver målgruppe vil være interessert i forskjellig informasjon og for ulike formål. Målgruppene du kan betjene med rapportene inkluderer:

  • Overordnet sponsor
  • Senter for fremragende forskning
  • Power BI-administratorer
  • Arbeidsområdeadministratorer
  • Premium-kapasitetsadministratorer
  • Gatewayadministratorer
  • Power BI-utviklere og innholdsopprettere
  • Revisorer

Her er noen av de vanligste analytiske kravene som du kanskje vil begynne med når du oppretter overvåkingsrapportene.

  • Populære innholdsvisninger: Ledersponsoren og ledergruppene dine kan hovedsakelig være interessert i sammendragsinformasjon og trender over tid. Arbeidsområdeadministratorer, utviklere og innholdsopprettere vil være mer interessert i detaljene.
  • Toppbrukeraktiviteter: Kompetansesenteret vil være interessert i hvem som bruker Power BI, hvordan og når. Premium-kapasitetsadministratorene vil være interessert i hvem som bruker kapasiteten til å sikre tilstanden og stabiliteten.
  • Leierbeholdning: Power BI-administratorer, arbeidsområdeadministratorer og revisorer vil være interessert i å forstå hvilket innhold som finnes, hvor, avstamming og sikkerhetsinnstillingene.

Denne listen er ikke all-inclusive. Det er ment å gi deg ideer om hvordan du oppretter analytiske rapporter som retter seg mot bestemte behov. Hvis du vil ha mer informasjon, kan du se Databehov tidligere i denne artikkelen, og oversikt over overvåking og overvåking. Disse ressursene inneholder mange ideer til hvordan du kan bruke overvåkingsdata, og hvilke typer informasjon du kan velge å presentere i rapportene.

Tips

Selv om det er fristende å presentere mye data, kan du bare inkludere informasjon som du er forberedt på å gjøre noe med. Sørg for at hver rapportside er tydelig om formålet, hvilke tiltak som skal utføres, og av hvem.

Hvis du vil lære hvordan du oppretter analytiske rapporter, kan du arbeide gjennom effektive utformingsrapporter i Power BI-læringsbanen .

Sjekkliste – Når du planlegger analyserapporter, omfatter viktige beslutninger og handlinger:

  • Gjennomgangskrav: Prioriter oppretting av rapporter basert på kjente behov og spesifikke spørsmål som bør besvares.
  • Bekreft målgruppen(e): Avklar hvem som skal bruke overvåkingsrapportene, og hva deres tiltenkte formål vil være.
  • Opprett og distribuer rapporter: Utvikle det første settet med kjernerapporter. Utvid og forbedre dem gradvis over tid.
  • Distribuer rapporter i en app: Vurder å opprette en app som inkluderer alle overvåkings- og overvåkingsrapportene dine.
  • Kontroller hvem som har tilgang til rapporter: Sørg for at rapportene (eller appen) gjøres tilgjengelige for riktig sett med brukere.
  • Opprett en tilbakemeldingssløyfe: Kontroller at det finnes en måte for rapportforbrukere å gi tilbakemeldinger eller forslag eller rapportproblemer på.

Utføre handling basert på dataene

Overvåking av data er verdifullt fordi det hjelper deg med å forstå hva som skjer i Power BI-leieren. Selv om det kan virke åpenbart, kan eksplisitt det å handle på det du lærer av overvåkingsdataene lett overses. Derfor anbefaler vi at du tilordner noen som er ansvarlig for å spore målbare forbedringer, i stedet for bare å se gjennom overvåkingsrapporter. På den måten kan du gjøre gradvise, målbare fremskritt i innføring og modenhetsnivå med Power BI.

Du kan utføre mange forskjellige handlinger basert på målene dine og hva du lærer av overvåkingsdataene. Resten av denne inndelingen gir deg flere ideer.

Innholdsbruk

Her er noen handlinger du kan utføre basert på hvordan innhold brukes.

  • Innhold brukes ofte (daglig eller ukentlig): Kontroller at kritisk innhold er sertifisert. Bekreft at eierskapet er klart, og at løsningen støttes tilstrekkelig.
  • Høyt antall arbeidsområdevisninger: Når et høyt antall arbeidsområder vises, kan du undersøke hvorfor Power BI-apper ikke er i bruk.
  • Innhold brukes sjeldent: Kontakt målbrukerne for å finne ut om løsningen oppfyller behovene deres, eller om kravene deres er endret.
  • Oppdateringsaktivitet forekommer oftere enn visninger: Kontakt eieren av innholdet for å forstå hvorfor en semantisk modell oppdateres regelmessig uten nylig bruk av semantisk modell eller relaterte rapporter.

Brukeraktiviteter

Her er noen handlinger du kan utføre basert på brukeraktiviteter.

  • Første publiseringshandling av en ny bruker: Identifiser når en brukertype endres fra forbruker til oppretter, som du kan identifisere når de publiserer innhold for første gang. Det er en flott mulighet til å sende dem en standard e-postmelding som gir veiledning og koblinger til nyttige ressurser.
  • Engasjement med de vanligste innholdsoppretterne: Inviter de mest aktive oppretterne til å bli med i champions-nettverket, eller for å bli involvert i ditt fellesskap av praksis.
  • Lisensadministrasjon: Kontroller om inaktive opprettere fortsatt trenger en Pro- eller PPU-lisens.
  • Aktivering av prøveversjon av brukere: Aktivering av prøveversjonslisens kan be deg om å tilordne en permanent lisens til brukeren før prøveperioden avsluttes.

Brukeropplæringsmuligheter

Her er noen brukeropplæringsmuligheter som du kan identifisere fra overvåkingsdataene.

  • Stort antall semantiske modeller publisert av den samme innholdsoppretteren: Lær brukerne om delte semantiske modeller og hvorfor det er viktig å unngå å opprette dupliserte semantiske modeller.
  • Overdreven deling fra et personlig arbeidsområde: Kontakt en bruker som deler mye fra sitt personlige arbeidsområde. Lær dem om standard arbeidsområder.
  • Viktige rapportvisninger fra et personlig arbeidsområde: Kontakt en bruker som eier innhold som har et høyt antall rapportvisninger. Lær dem hvordan standard arbeidsområder er bedre enn personlige arbeidsområder.

Tips

Du kan også forbedre opplæringsinnholdet eller dokumentasjonen ved å se gjennom spørsmål besvart av det interne Power BI-fellesskapet og problemer som sendes til brukerstøtte.

Sikkerhet

Her er noen sikkerhetssituasjoner du kanskje vil overvåke aktivt.

Hvis du vil ha mer informasjon, kan du se sikkerhetsplanleggingsartiklene .

Styring og risikoreduksjon

Her er noen situasjoner du kan støte på. Vurder eksplisitt å se etter slike situasjoner i overvåkingsrapportene, slik at du er forberedt på å handle raskt.

  • Høyt antall visninger for rapporter (og underliggende semantiske modeller) som ikke er godkjent.
  • Betydelig bruk av ukjente eller ikke-sanksjonerte datakilder.
  • Filplasseringer som ikke samsvarer med styringsretningslinjene for hvor kildefilene skal være plassert.
  • Arbeidsområdenavn samsvarer ikke med styringskravene.
  • Følsomhetsetiketter brukes til informasjonsbeskyttelse.
  • Konsekvente dataoppdateringsfeil.
  • Betydelig og regelmessig bruk av utskrift.
  • Uventet eller overdreven bruk av abonnementer.
  • Uventet bruk av personlige gatewayer.

De spesifikke handlingene som skal utføres i hver situasjon, avhenger av styringspolicyene dine. Hvis du vil ha mer informasjon, kan du se Styring i stoffadopsjonsveikartet.

Sjekkliste – Når du planlegger potensielle handlinger basert på overvåkingsdataene, omfatter viktige beslutninger og handlinger:

  • Klargjør forventningene: Opprett overvåkingsrapporter med et klart sett med forventninger til hvilke handlinger som forventes.
  • Klargjør hvem som skal være ansvarlig for handlinger: Sørg for at roller og ansvar er tilordnet.
  • Opprett automatisering: Automatiser kjente handlinger som kan gjentas når det er mulig.
  • Bruk et sporingssystem: Bruk et system til å spore en observert situasjon, inkludert kontakter, neste planlagte handling, hvem som er ansvarlig, løsning og status.

Fase 4: Vedlikeholde, forbedre og overvåke

Den fjerde fasen av planlegging og implementering av en overvåkingsløsning på leiernivå fokuserer på vedlikehold, forbedringer og overvåking. På dette tidspunktet er overvåkingsløsningen i produksjonsbruk. Du er nå først og fremst opptatt av å vedlikeholde, forbedre og overvåke løsningen.

Flytdiagram som beskriver fase 4, som fokuserer på vedlikehold, forbedring og overvåking av en overvåkingsløsning på leiernivå.

Operasjonaliser og forbedre

Overvåkingsprosesser anses vanligvis å kjøre i produksjon når første utvikling og testing er fullført, og du har automatisert prosessen. Automatiserte overvåkingsprosesser som kjører i produksjon har større forventninger (enn manuelle prosesser) for kvalitet, pålitelighet, stabilitet og støtte.

En revisjonsprosess på produksjonsnivå er operasjonalisert. En operasjonalisert løsning omfatter vanligvis mange av følgende egenskaper.

  • Sikker: Legitimasjon lagres og administreres på en sikker måte. Skript inneholder ikke passord eller nøkler i ren tekst.
  • Planlegging: Et pålitelig planleggingssystem er på plass.
  • Endringsadministrasjon: Bruk av praksis for endringsbehandling og flere miljøer brukes til å sikre at produksjonsmiljøet er sikret. Du kan også arbeide med utviklings- og testmiljøer, eller bare et utviklingsmiljø.
  • Støtte: Teamet som støtter løsningen, er tydelig definert. Teammedlemmer har blitt opplært, og de forstår de operasjonelle forventningene. Sikkerhetskopimedlemmer er identifisert, og kryssopplæring skjer når det er aktuelt.
  • Varsler: Når noe går galt, varsler varsler du kundestøtteteamet automatisk. Fortrinnsvis omfatter varsling både logger og e-post (i stedet for bare e-post). En logg er nyttig for å analysere loggførte feil og advarsler.
  • Logging: Prosesser logges, slik at det er en logg over når overvåkingsdataene ble oppdatert. Loggført informasjon bør registrere starttidspunkt, sluttidspunkt og identiteten til brukeren eller appen som kjørte prosessen.
  • Feilbehandling: Skript og prosesser håndterer og logger feil på en grasiøs måte (for eksempel om du vil avslutte umiddelbart, fortsette eller vente og prøve på nytt). Varslinger sendes til kundestøtteteamet når det oppstår en feil.
  • Kodestandarder: Gode kodingsteknikker som fungerer bra, brukes. Løkker unngås for eksempel med hensikt unntatt når det er nødvendig. Konsekvente kodestandarder, kommentarer, formatering og syntaks brukes slik at løsningen blir enklere å vedlikeholde og støtte.
  • Gjenbruk og modulisering: Hvis du vil minimere duplisering, kode og konfigurasjonsverdier (for eksempel tilkoblingsstreng eller e-postadresser for varsler), er modulerte slik at andre skript og prosesser kan bruke dem på nytt.

Tips

Du trenger ikke å gjøre alt som er oppført fremfor alt samtidig. Etter hvert som du får erfaring, kan du forbedre løsningen trinnvis slik at den blir fullstendig og robust. Vær oppmerksom på at de fleste eksemplene du finner på nettet, er enkle, engangssnutt som kanskje ikke er produksjonskvalitet.

Sjekkliste – Når du planlegger å operasjonalisere og forbedre en revisjonsløsning, omfatter viktige beslutninger og handlinger:

  • Vurder nivået på eksisterende løsninger: Finn ut om det finnes muligheter til å forbedre og stabilisere eksisterende overvåkingsløsninger som er automatiserte.
  • Etablere standarder på produksjonsnivå: Bestem hvilke standarder du vil ha for dine automatiserte revisjonsprosesser. Faktor i forbedringer som du realistisk kan legge til over tid.
  • Opprett en plan for forbedring: Planlegg for å forbedre kvaliteten og stabiliteten til produksjonsrevisjonsløsninger.
  • Avgjør om et eget utviklingsmiljø er nødvendig: Vurder risikonivået og avhengigheten av produksjonsdataene. Bestem når du skal opprette separate utviklings- og produksjonsmiljøer (og test) miljøer.
  • Vurder en strategi for dataoppbevaring: Bestem om du må implementere en dataoppbevaringsprosess som tømmer data etter en viss tidsperiode, eller etter forespørsel.

Dokumentasjon og støtte

Dokumentasjon og støtte er avgjørende for alle løsninger på produksjonsnivå. Det er nyttig å opprette flere typer dokumentasjon, avhengig av målgruppen og formålet.

Teknisk dokumentasjon

Teknisk dokumentasjon er rettet mot det tekniske teamet som bygde løsningen, og som gradvis vil forbedre og utvide løsningen over tid. Det er også en nyttig ressurs for støtteteamet.

Teknisk dokumentasjon bør omfatte:

  • Et sammendrag av arkitekturkomponenter og forutsetninger.
  • Hvem eier og administrerer løsningen.
  • Hvem støtter løsningen.
  • Et arkitekturdiagram.
  • Utformingsbeslutninger, inkludert mål, grunner til at visse tekniske valg ble gjort, og begrensninger (for eksempel kostnader eller ferdigheter).
  • Sikkerhetsbeslutninger og valg.
  • Navnekonvensjoner som brukes.
  • Koding og tekniske standarder og retningslinjer.
  • Endre administrasjonskrav.
  • Instruksjoner for distribusjon, installasjon og installasjon.
  • Kjente områder av teknisk gjeld (områder som kan forbedres hvis det er mulighet til å gjøre det).

Støttedokumentasjon

Avhengig av kritisk nivå for overvåkingsløsningen, kan det hende du har en brukerstøtte eller kundestøttegruppe hvis det skulle oppstå hasteproblemer. De kan være tilgjengelige hele dagen, hver dag.

Støttedokumentasjon kalles noen ganger en kunnskapsbase eller en runbook. Denne dokumentasjonen er rettet mot brukerstøtte eller kundestøtte, og den bør omfatte:

  • Feilsøkingsveiledning for når noe går galt. Når det for eksempel oppstår en dataoppdateringsfeil.
  • Handlinger som skal utføres kontinuerlig. Det kan for eksempel være noen manuelle trinn som noen må gjøre regelmessig til et problem er løst.

Dokumentasjon for innholdsoppretter

Du henter mer verdi fra overvåkingsløsningen ved å tilby bruks- og innføringsanalyser til andre team i hele organisasjonen (med sikkerhet på radnivå håndhevet om nødvendig).

Dokumentasjon for innholdsoppretter er rettet mot selvbetjente innholdsopprettere som oppretter rapporter og datamodeller som henter de kuraterte overvåkingsdataene. Den inneholder informasjon om datamodellen, inkludert vanlige datadefinisjoner.

Sjekkliste – Når du planlegger dokumentasjon og støtte for overvåkingsløsningen, omfatter viktige beslutninger og handlinger:

  • Bekreft hvem som forventes å støtte løsningen: Bestem hvem som støtter overvåkingsløsninger som anses som produksjonsnivå (eller har nedstrøms rapportavhengigheter).
  • Sørg for at kundestøtteteamet er klargjort: Kontroller at kundestøtteteamet er forberedt på å støtte overvåkingsløsningen. Identifiser om det er noen klargjøringshull som trenger adressering.
  • Ordne for kryssopplæring: Gjennomføre kunnskapsoverføringsøkter eller økter på tvers av opplæringer for støtteteamet.
  • Klargjør forventningene til støtteteamet: Sørg for at forventningene til svar og løsning er tydelig dokumentert og kommunisert. Bestem om noen må være på vakt for raskt å løse problemer knyttet til overvåkingsløsningen.
  • Opprett teknisk dokumentasjon: Opprett dokumentasjon om de tekniske arkitektur- og utformingsbeslutningene.
  • Opprett støttedokumentasjon: Oppdater kunnskapsbasen for brukerstøtte for å inkludere informasjon om hvordan du støtter løsningen.
  • Opprett dokumentasjon for innholdsopprettere: Opprett dokumentasjon for å hjelpe selvbetjente opprettere med å bruke datamodellen. Beskriv vanlige datadefinisjoner for å forbedre konsekvensen av bruken.

Aktiver varsling

Det kan være lurt å heve varsler basert på bestemte betingelser i overvåkingsdataene. Du kan for eksempel heve et varsel når noen sletter en gateway, eller når en Power BI-administrator endrer en leierinnstilling.

Hvis du vil ha mer informasjon, kan du se Overvåking på leiernivå.

Løpende administrasjon

Du må utføre kontinuerlig administrasjon av hele overvåkingsløsningen. Du må kanskje utvide eller endre overvåkingsløsningen når:

  • Organisasjonen oppdager nye datakrav.
  • Nye overvåkingshendelser vises i rådataene du har nøyaktig fra REST-API-ene for Power BI.
  • Microsoft gjør endringer i REST-API-ene for Power BI.
  • Ansatte identifiserer måter å forbedre løsningen på.

Viktig

Brudd på endringer er sjeldne, men de kan oppstå. Det er viktig at du har noen tilgjengelig som raskt kan feilsøke problemer eller oppdatere overvåkingsløsningen når det er nødvendig.

Sjekkliste – Når du planlegger for kontinuerlig administrasjon av overvåkingsløsningen, omfatter viktige beslutninger og handlinger:

  • Tilordne en teknisk eier: Sørg for at det er klart eierskap og ansvar for hele overvåkingsløsningen.
  • Kontroller at det finnes en sikkerhetskopi: Kontroller at det finnes en teknisk reserveeier som kan involvere seg dersom det oppstår et presserende problem som støtte ikke kan løse.
  • Behold et sporingssystem: Sørg for at du har en metode for å registrere nye forespørsler og en måte å prioritere umiddelbare prioriteringer på, og også kortsiktige, mellomlang og langsiktige prioriteringer (backlog).

Relatert innhold

I den neste artikkelen i denne serien kan du lære mer om overvåking på leiernivå.