Hvitbok om Power BI-sikkerhet

Sammendrag: Power BI er en nettbasert programvaretjeneste (SaaS eller Software as a Service) fra Microsoft som lar deg enkelt og raskt opprette selvbetjente Instrumentbord for forretningsintelligens, rapporter, semantiske modeller (tidligere kjent som datasett) og visualiseringer. Med Power BI kan du koble til mange forskjellige datakilder, kombinere og forme data fra disse tilkoblingene, og deretter opprette rapporter og instrumentbord som kan deles med andre.

Forfattere: Yitzhak Kesselman, Paddy Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Ronald Chang, Ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Paul Inbar, Igor Uzhviev, Michael Roth, Jaime Tarquino, Gennady Pats, Orion Lee, Yury Berezansky, Maya Shenhav, Romit Chattopadhyay, Yariv Maimon, Bogdan Crivat

Tekniske anmeldere: Cristian Petculescu, Amir Netz, Sergei Gundorov

Gjelder for: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI for mobilenheter.

Merk

Du kan lagre eller skrive ut denne hvitboken ved å velge Skriv ut fra nettleseren, og deretter velge Lagre som PDF.

Innledning

Power BI er en online programvaretjeneste (SaaS eller Software as a Service) fra Microsoft som lar deg enkelt og raskt opprette selvbetjente Instrumentbord for forretningsintelligens, rapporter, semantiske modeller og visualiseringer. Med Power BI kan du koble til mange forskjellige datakilder, kombinere og forme data fra disse tilkoblingene, og deretter opprette rapporter og instrumentbord som kan deles med andre.

Verden er i rask endring; organisasjoner går gjennom en akselerert digital transformasjon, og vi ser en massiv økning i eksternt arbeid, økt kundeetterspørsel etter onlinetjenester og økt bruk av avansert teknologi i drift og forretningsbeslutningsprosesser. Og alt dette drives av skyen.

Etter hvert som overgangen til skyen har endret seg fra en drypp til en flom, og med det nye, eksponerte overflateområdet som følger med den, spør flere selskaper hvor sikre er dataene mine i skyen? Og Hvilken ende-til-ende-beskyttelse er tilgjengelig for å hindre at sensitive data lekker? Og for BI-plattformene som ofte håndterer noe av den mest strategiske informasjonen i virksomheten, er disse spørsmålene dobbelt viktige.

De tiår gamle grunnlaget for BI-sikkerhetsmodellen - objektnivå og sikkerhet på radnivå - mens det fortsatt er viktig, er tydeligvis ikke lenger nok for å gi den typen sikkerhet som trengs i skytiden. I stedet må organisasjoner se etter en skybasert, flerlags, forsvar-i-dybde sikkerhetsløsning for sine forretningsanalysedata.

Power BI ble bygget for å gi bransjeledende fullstendig og hermetisk beskyttelse for data. Produktet har tjent de høyeste sikkerhetsklassifiseringene som er tilgjengelige i bransjen, og i dag overlater mange nasjonale sikkerhetsbyråer, finansinstitusjoner og helsepersonell det med sin mest sensitive informasjon.

Det hele starter med grunnlaget. Etter en tøff periode tidlig på 2000-tallet gjorde Microsoft massive investeringer for å håndtere sine sikkerhetssårbarheter, og i de følgende tiårene bygget en sterk sikkerhetsstakk som går så dypt som maskinens on-chip bios kjerne og strekker seg helt opp til sluttbrukeropplevelser. Disse dype investeringene fortsetter, og i dag er over 3500 Microsoft-ingeniører engasjert i å bygge og forbedre Microsofts sikkerhetsstakk og proaktivt adressere det stadig skiftende trussellandskapet. Med milliarder av datamaskiner, billioner av pålogginger og utallige zettabyte med informasjon som er betrodd Microsofts beskyttelse, har selskapet nå den mest avanserte sikkerhetsstakken i teknologiindustrien og blir bredt sett på som den globale lederen i kampen mot ondsinnede aktører.

Power BI bygger på dette sterke grunnlaget. Den bruker den samme sikkerhetsstakken som ga Azure rett til å betjene og beskytte verdens mest sensitive data, og den integreres med de mest avanserte verktøyene for informasjonsbeskyttelse og samsvar i Microsoft 365. På toppen av disse leverer den sikkerhet gjennom flerlags sikkerhetstiltak, noe som resulterer i ende-til-ende-beskyttelse som er utformet for å håndtere de unike utfordringene i skytiden.

For å gi en ende-til-ende-løsning for å beskytte sensitive ressurser, måtte produktteamet håndtere utfordrende kundebekymringer på flere samtidige fronter:

• Hvordan kontrollerer vi hvem som kan koble til, hvor de kobler til fra, og hvordan de kobler seg til?Hvordan kan vi kontrollere tilkoblingene?
• Hvordan lagres dataene?Hvordan krypteres den?Hvilke kontroller har jeg på dataene mine?
• Hvordan kontrollere og beskytte sensitive data?Hvordan sikre at disse dataene ikke kan lekke utenfor organisasjonen?
• Hvordan revisjon hvem som utfører hvilke operasjoner?Hvordan reagere raskt hvis det er mistenkelig aktivitet på tjenesten?

Denne artikkelen gir et omfattende svar på alle disse spørsmålene. Det starter med en oversikt over tjenestearkitekturen og forklarer hvordan hovedflytene i systemet fungerer. Den går deretter videre for å beskrive hvordan brukere godkjenner til Power BI, hvordan datatilkoblinger etableres, og hvordan Power BI lagrer og flytter data gjennom tjenesten. Den siste delen tar for seg sikkerhetsfunksjonene som lar deg, som tjenesteadministrator, beskytte de mest verdifulle ressursene dine.

Den Power Bi-tjeneste er underlagt vilkårene for Microsoft Online Services og personvernerklæringen for Microsoft Enterprise. Hvis du vil se plasseringen av databehandling, kan du se vilkårene for plassering av databehandling i vilkårene for Microsoft Online Services og til databeskyttelsestillegget. Microsoft Trust Center er den primære ressursen for Power BI for samsvarsinformasjon. Power BI-teamet jobber hardt for å gi kundene de nyeste innovasjonene og produktiviteten. Mer informasjon om samsvar i Microsoft-samsvarstilbud.

Den Power Bi-tjeneste følger sikkerhetsutviklingens livssyklus (SDL), strenge sikkerhetspraksiser som støtter sikkerhetssikring og samsvarskrav. SDL hjelper utviklere med å bygge sikrere programvare ved å redusere antallet og alvorlighetsgraden av sårbarheter i programvaren, samtidig som utviklingskostnadene reduseres. Finn ut mer på Microsofts praksiser i livssyklusen for sikkerhetsutvikling.

Power BI-arkitektur

Den Power Bi-tjeneste er bygget på Azure, Microsofts skydatabehandlingsplattform. Power BI distribueres for øyeblikket i mange datasentre over hele verden – det er mange aktive distribusjoner som er gjort tilgjengelige for kunder i områdene som betjenes av disse datasentrene, og et likt antall passive distribusjoner som fungerer som sikkerhetskopier for hver aktive distribusjon.

Webfrontklynge (WFE)

WFE-klyngen gir brukerens nettleser det første HTML-sideinnholdet ved områdeinnlasting, og pekere til CDN-innhold som brukes til å gjengi nettstedet i nettleseren.

En WFE-klynge består av et ASP.NET nettsted som kjører i Azure App Service Environment. Når brukere prøver å koble til Power Bi-tjeneste, kan klientens DNS-tjeneste kommunisere med Azure Traffic Manager for å finne det mest hensiktsmessige (vanligvis nærmeste) datasenteret med en Power BI-distribusjon. Hvis du vil ha mer informasjon om denne prosessen, kan du se ytelsestrafikkrutingsmetoden for Azure Traffic Manager.

Statiske ressurser som *.js, *.css og bildefiler lagres for det meste på et Azure Content Delivery Network (CDN) og hentes direkte av nettleseren. Vær oppmerksom på at distribusjoner av sovereign government-klynger er et unntak fra denne regelen, og av samsvarsårsaker utelates CDN og i stedet bruker en WFE-klynge fra et kompatibelt område for å drifte statisk innhold.

Power BI-bakklynge (BE)

Bakklyngen er ryggraden i all funksjonaliteten som er tilgjengelig i Power BI. Den består av flere tjenesteendepunkter som forbrukes av Web Front End- og API-klienter, samt bakgrunnsarbeidstjenester, databaser, hurtigbuffere og ulike andre komponenter.

Bakenden er tilgjengelig i de fleste Azure-områder, og distribueres i nye områder etter hvert som de blir tilgjengelige. Et enkelt Azure-område er vert for én eller flere bakklynger som tillater ubegrenset vannrett skalering av Power Bi-tjeneste når de loddrette og vannrette skaleringsgrensene for én enkelt klynge er oppbrukt.

Hver serverdelklynge er tilstandsfull og er vert for alle dataene for alle leierne som er tilordnet denne klyngen. En klynge som inneholder dataene til en bestemt leier, kalles leierens hjemmeklynge. En godkjent brukers hjemmeklyngeinformasjon leveres av global tjeneste og brukes av Web Front End til å rute forespørsler til leierens hjemmeklynge.

Hver bakklynge består av flere virtuelle maskiner kombinert i flere resizable-skalasett som er innstilt for å utføre bestemte oppgaver, tilstandsfulle ressurser som SQL-databaser, lagringskontoer, tjenestebusser, buffere og andre nødvendige skykomponenter.

Tenantmetadata og -data lagres innenfor klyngegrenser, bortsett fra datareplikering til en sekundær serverdelklynge i et sammenkoblet Azure-område i samme Azure-geografi. Den sekundære back-end klyngen fungerer som en failover klynge i tilfelle regionale strømbrudd, og er passiv til enhver tid.

Back-end funksjonalitet betjenes av mikrotjenester som kjører på forskjellige maskiner i klyngens virtuelle nettverk som ikke er tilgjengelige fra utsiden, bortsett fra to komponenter som kan nås fra det offentlige Internett:

• Gatewaytjeneste
• Azure API Management

Power BI Premium-infrastruktur

Power BI Premium tilbyr en tjeneste for abonnenter som krever premium Power BI-funksjoner, for eksempel avansert kunstig intelligens, distribusjon til ulisensierte brukere osv. Når en kunde registrerer seg for et Power BI Premium-abonnement, opprettes Premium-kapasiteten gjennom Azure Resource Manager.

Power BI Premium-kapasiteter driftes i bakklynger som er uavhengige av den vanlige Power BI-bakenden – se ovenfor). Dette gir bedre isolasjon, ressursallokering, støtte, sikkerhetsisolering og skalerbarhet for Premium-tilbudet.

Diagrammet nedenfor illustrerer arkitekturen til Power BI Premium-infrastrukturen:

Tilkoblingen til Power BI Premium-infrastrukturen kan gjøres på mange måter, avhengig av brukerscenarioet. Power BI Premium-klienter kan være en brukers nettleser, en vanlig Power BI-bakende, direkte tilkoblinger via XMLA-klienter, ARM-API-er osv.

Power BI Premium-infrastrukturen i et Azure-område består av flere Power BI Premium-klynger (minimum er én). De fleste Premium-ressurser er innkapslet i en klynge (for eksempel databehandling), og det finnes noen vanlige regionale ressurser (for eksempel metadatalagring). Premium-infrastruktur gir to måter å oppnå vannrett skalerbarhet på i et område: øke ressursene i klynger og/eller legge til flere klynger ved behov (hvis klyngeressurser nærmer seg grensene).

Ryggraden i hver klynge er databehandlingsressurser som administreres av Virtual Machine Scale Sets og Azure Service Fabric. Virtual Machine Scale Sets and Service Fabric tillater rask og smertefri økning av databehandlingsnoder etter hvert som bruken vokser og orkestrerer distribusjon, administrasjon og overvåking av Power BI Premium-tjenester og -programmer.

Det finnes mange omkringliggende ressurser som sikrer en sikker og pålitelig infrastruktur: belastningsfordelinger, virtuelle nettverk, nettverkssikkerhetsgrupper, servicebuss, lagring osv. Alle hemmeligheter, nøkler og sertifikater som kreves for Power BI Premium, administreres utelukkende av Azure Key Vault . All godkjenning utføres via integrasjon med Microsoft Entra ID (tidligere kjent som Azure Active Directory) utelukkende.

Alle forespørsler som kommer til Power BI Premium-infrastruktur, går til frontnoder først – de er de eneste nodene som er tilgjengelige for eksterne tilkoblinger. Resten av ressursene er skjult bak virtuelle nettverk. Frontnodene godkjenner forespørselen, håndterer den eller videresender den til de aktuelle ressursene (for eksempel baknoder).

Serverdelnoder gir de fleste Power BI Premium-funksjonene og -funksjonene.

Power BI for mobilenheter

Power BI for mobilenheter er en samling apper som er utformet for de tre primære mobilplattformene: Android, iOS og Windows (UWP). Sikkerhetshensyn for Power BI for mobilenheter apper faller inn i to kategorier:

• Enhetskommunikasjon
• Programmet og dataene på enheten

For enhetskommunikasjon kommuniserer alle Power BI for mobilenheter programmer med Power Bi-tjeneste, og bruker de samme tilkoblings- og godkjenningssekvensene som brukes av nettlesere, som er beskrevet i detalj tidligere i denne hvitboken. Power BI-mobilappene for iOS og Android tar opp en nettleserøkt i selve programmet, mens Windows-mobilappen tar opp en megler for å etablere kommunikasjonskanalen med Power BI (for påloggingsprosessen).

Tabellen nedenfor viser støtte for sertifikatbasert godkjenning (CBA) for Power BI for mobilenheter, basert på plattformen for mobilenheter:

Støtte for sertifikatbasert autentisering	iOS	Android	Vinduer
Power BI (logg på tjeneste)	Støttes	Støttes	Støttes ikke
Lokal SSRS ADFS (koble til SSRS-server)	Støttes ikke	Støttes	Støttes ikke
SSRS-approxy	Støttes	Støttes	Støttes ikke

Power BI for mobilenheter apper kommuniserer aktivt med Power Bi-tjeneste. Telemetri brukes til å samle inn bruksstatistikk for mobilapper og lignende data, som sendes til tjenester som brukes til å overvåke bruk og aktivitet. ingen kundedata sendes med telemetri.

Power BI-programmet lagrer data på enheten som forenkler bruken av appen:

• Microsoft Entra ID og oppdateringstokener lagres i en sikker mekanisme på enheten ved hjelp av bransjestandard sikkerhetstiltak.
• Data og innstillinger (nøkkelverdipar for brukerkonfigurasjon) bufres i lagring på enheten, og kan krypteres av operativsystemet. I iOS gjøres dette automatisk når brukeren angir et passord. I Android kan dette konfigureres i innstillingene. I Windows oppnås det ved hjelp av BitLocker.
• For Android- og iOS-appene bufres data og innstillinger (nøkkelverdipar for brukerkonfigurasjon) i lagring på enheten i en sandkasse og intern lagringsplass som bare er tilgjengelig for appen. For Windows-appen er dataene bare tilgjengelige for brukeren (og systemansvarlig).
• Geoplassering aktiveres eller deaktiveres eksplisitt av brukeren. Hvis den er aktivert, blir geoplasseringsdata verken lagret på enheten eller delt med Microsoft.
• Varslinger aktiveres eller deaktiveres eksplisitt av brukeren. Hvis aktivert, støtter ikke Android og iOS geografiske krav til datalagring for varsler.

Datakryptering kan forbedres ved å bruke kryptering på filnivå via Microsoft Intune, en programvaretjeneste som tilbyr administrasjon av mobilenheter og programmer. Alle tre plattformene som Power BI for mobilenheter er tilgjengelig for, støtter Intune. Når Intune er aktivert og konfigurert, krypteres data på den mobile enheten, og Selve Power BI-programmet kan ikke installeres på et SD-kort. Mer informasjon om Microsoft Intune.

Windows-appen støtter også Windows Information Protection (WIP).

For å implementere SSO er noen sikrede lagringsverdier relatert til tokenbasert godkjenning tilgjengelig for andre Microsoft-apper (for eksempel Microsoft Authenticator) og administreres av Microsoft Authentication Library (MSAL).

Power BI for mobilenheter bufrede data slettes når appen fjernes, når brukeren logger seg av Power BI for mobilenheter, eller når brukeren ikke logger på (for eksempel etter en utløpshendelse eller passordendring). Databufferen inneholder instrumentbord og rapporter som tidligere ble åpnet fra Power BI for mobilenheter-appen.

Power BI for mobilenheter får ikke tilgang til andre programmapper eller filer på enheten.

Power BI-appene for iOS og Android lar deg beskytte dataene dine ved å konfigurere ekstra identifikasjon, for eksempel å gi Face ID, Touch ID eller et passord for iOS, og biometriske data (fingeravtrykks-ID) for Android. Mer informasjon om ytterligere identifikasjon.

Godkjenning til Power Bi-tjeneste

Brukergodkjenning til Power Bi-tjeneste består av en rekke forespørsler, svar og omdirigeringer mellom brukerens nettleser og Power Bi-tjeneste eller Azure-tjenestene som brukes av Power BI. Denne sekvensen beskriver prosessen med brukergodkjenning i Power BI, som følger godkjenningsflyten for Microsoft Entra-godkjenningskode. Hvis du vil ha mer informasjon om alternativer for organisasjonens brukergodkjenningsmodeller (påloggingsmodeller), kan du se Velge en påloggingsmodell for Microsoft 365.

Godkjenningssekvens

Brukergodkjenningssekvensen for Power Bi-tjeneste skjer som beskrevet i følgende trinn, som er illustrert i bildet som følger dem.

1. En bruker starter en tilkobling til Power Bi-tjeneste fra en nettleser, enten ved å skrive inn Power BI-adressen på adresselinjen eller ved å velge Logg på fra markedsføringssiden for Power BI (https://powerbi.microsoft.com). Tilkoblingen opprettes ved hjelp av TLS og HTTPS, og all etterfølgende kommunikasjon mellom nettleseren og Power Bi-tjeneste bruker HTTPS.

2. Azure Traffic Manager kontrollerer brukerens DNS-post for å finne det mest hensiktsmessige (vanligvis nærmeste) datasenteret der Power BI distribueres, og svarer på DNS med IP-adressen til WFE-klyngen som brukeren skal sendes til.

3. WFE returnerer deretter en HTML-side til nettleserklienten, som inneholder en MSAL.js bibliotekreferanse som er nødvendig for å starte påloggingsflyten.

4. Nettleserklienten laster inn HTML-siden som mottas fra WFE, og omdirigerer brukeren til påloggingssiden for Microsoft Online Services.

5. Når brukeren er godkjent, omdirigerer påloggingssiden brukeren tilbake til Power BI WFE-siden med en godkjenningskode.

6. Nettleserklienten laster inn HTML-siden og bruker godkjenningskoden til å be om tokener (tilgang, ID, oppdatering) fra Microsoft Entra ID.

7. Brukerens leier-ID brukes av nettleserklienten til å spørre den globale Power BI-tjenesten, som opprettholder en liste over leiere og deres Plasseringer for Power BI-bakklynger. Den globale Power BI-tjenesten bestemmer hvilken Power BI-servertjenesteklynge som inneholder brukerens leier, og returnerer nettadressen for power BI-serverdelklyngen tilbake til klienten.

8. Klienten kan nå kommunisere med URL-API-en for power BI-serverklyngen ved hjelp av tilgangstokenet i autorisasjonshodet for HTTP-forespørsler. Microsoft Entra-tilgangstokenet har angitt en utløpsdato i henhold til Microsoft Entra-policyer, og for å opprettholde den gjeldende økten vil Power BI-klienten i brukerens nettleser sende periodiske forespørsler om å fornye tilgangstokenet før det utløper.

I sjeldne tilfeller der godkjenning på klientsiden mislykkes på grunn av en uventet feil, forsøker koden å falle tilbake til bruk av godkjenning på serversiden i WFE. Se delen spørsmål og svar på slutten av dette dokumentet for mer informasjon om godkjenningsflyten på serversiden.

Datalagring

Med mindre annet er angitt i dokumentasjonen, lagrer Power BI kundedata i en Azure-geografi som tilordnes når en Microsoft Entra-leier registrerer seg for Power Bi-tjeneste for første gang. En Microsoft Entra-leier huser bruker- og programidentiteter, grupper og annen relevant informasjon som gjelder for en organisasjon og dens sikkerhet.

Tildelingen av en Azure-geografi for tenantdatalagring utføres ved å tilordne landet eller området som er valgt som en del av leieroppsettet for Microsoft Entra, til den mest passende Azure-geografien der det finnes en Power BI-distribusjon. Når denne avgjørelsen er gjort, lagres alle Power BI-kundedata i denne valgte Azure-geografien (også kjent som home geo), unntatt i tilfeller der organisasjoner bruker multi-geo-distribusjoner.

Flere geografiske områder (multi-geo)

Noen organisasjoner har en global tilstedeværelse og kan kreve Power Bi-tjeneste i flere Azure-geografiske områder. En bedrift kan for eksempel ha sitt hovedkvarter i USA men kan også gjøre forretninger i andre geografiske områder, for eksempel Australia. I slike tilfeller kan virksomheten kreve at visse Power BI-data forblir lagret i det eksterne området for å overholde lokale forskrifter. Denne funksjonen i Power Bi-tjeneste kalles multi-geo.

Spørringskjøringslaget, spørringsbufferne og artefaktdataene som er tilordnet til et multi-geo-arbeidsområde, driftes og forblir i Azure-geografien med ekstern kapasitet. Imidlertid kan noen artefaktmetadata, for eksempel rapportstruktur, forbli lagret i hvile i tenantens hjemgeo. I tillegg kan noen datatransitt og behandling fortsatt skje i tenantens hjemgeo, selv for arbeidsområder som driftes i en multi-geo Premium-kapasitet.

Se Konfigurere Multi-Geo-støtte for Power BI Premium for mer informasjon om oppretting og administrasjon av Power BI-distribusjoner som strekker seg over flere Azure-geografiske områder.

Områder og datasentre

Power Bi-tjeneste er tilgjengelige i bestemte Azure-geografiske områder som beskrevet i Microsoft Klareringssenter. Hvis du vil ha mer informasjon om hvor dataene lagres og hvordan de brukes, kan du se Microsoft Klareringssenter. Forpliktelser vedrørende plasseringen av inaktive kundedata er angitt i vilkårene for databehandling i Microsofts vilkår for elektroniske tjenester.

Microsoft tilbyr også datasentre for nasjonale enheter. Hvis du vil ha mer informasjon om Power Bi-tjeneste tilgjengelighet for nasjonale/regionale skyer, kan du se nasjonale/regionale skyer i Power BI.

Datahåndtering

Denne delen beskriver fremgangsmåter for databehandling i Power BI når det gjelder lagring, behandling og overføring av kundedata.

Inaktive data

Power BI bruker to primære datalagringsressurstyper:

• Azure Lagring
• Azure SQL Databaser

I de fleste scenarioer brukes Azure Storage til å beholde dataene for Power BI-artefakter, mens Azure SQL Databases brukes til å beholde metadata for artefakter.

Alle data som vedvares av Power BI, krypteres som standard ved hjelp av Microsoft-administrerte nøkler. Kundedata som er lagret i Azure SQL Databases, krypteres fullstendig ved hjelp av Azure SQL's Transparent Data Encryption (TDE) -teknologi. Kundedata som er lagret i Azure Blob-lagring, krypteres ved hjelp av Azure Storage Encryption.

Organisasjoner kan eventuelt bruke Power BI Premium til å bruke sine egne nøkler til å kryptere data som er importert til en semantisk modell. Denne fremgangsmåten beskrives ofte som å ta med din egen nøkkel (BYOK). Bruk av BYOK bidrar til å sikre at selv i tilfelle en tjenesteoperatorfeil, vises ikke kundedata – noe som ikke lett kan oppnås ved hjelp av gjennomsiktig kryptering på tjenestesiden. Se Ta med dine egne krypteringsnøkler for Power BI for mer informasjon.

Semantiske Power BI-modeller tillater ulike datakildetilkoblingsmoduser som bestemmer om datakildedataene beholdes i tjenesten eller ikke.

Semantisk modellmodus (type)	Data vedvart i Power BI
Importer	Ja
DirectQuery	No
Direkte Koble til	No
Sammensatt	Hvis inneholder en importdatakilde
Strømming	Hvis konfigurert til å vedvare

Uavhengig av semantisk modellmodus som brukes, kan Power BI midlertidig bufre alle hentede data for å optimalisere ytelsen for spørring og rapportinnlasting.

Data som behandles

Data behandles når de brukes aktivt av én eller flere brukere som en del av et interaktivt scenario, eller når en bakgrunnsprosess, for eksempel oppdatering, berører disse dataene. Power BI laster aktivt behandlede data inn i minneområdet til én eller flere tjenestearbeidsbelastninger. For å forenkle funksjonaliteten som kreves av arbeidsbelastningen, krypteres ikke de behandlede dataene i minnet.

Data under overføring

Power BI krever at all innkommende HTTP-trafikk krypteres ved hjelp av TLS 1.2 eller nyere. Alle forespørsler som prøver å bruke tjenesten med TLS 1.1 eller lavere, blir avvist.

Godkjenning til datakilder

Når du kobler til en datakilde, kan en bruker velge å importere en kopi av dataene til Power BI eller koble direkte til datakilden.

Når det gjelder import, etablerer en bruker en tilkobling basert på brukerens pålogging og får tilgang til dataene med legitimasjonen. Når den semantiske modellen er publisert til Power Bi-tjeneste, bruker Power BI alltid denne brukerens legitimasjon til å importere data. Når dataene er importert, får ikke visning av dataene i rapporter og instrumentbord tilgang til den underliggende datakilden. Power BI støtter enkel påloggingsgodkjenning for valgte datakilder. Hvis tilkoblingen er konfigurert til å bruke enkel pålogging, brukes den semantiske modelleierens legitimasjon til å koble til datakilden.

Hvis en datakilde er koblet direkte til ved hjelp av forhåndskonfigurert legitimasjon, brukes den forhåndskonfigurerte legitimasjonen til å koble til datakilden når en bruker viser dataene. Hvis en datakilde er koblet direkte til ved hjelp av enkel pålogging, brukes den gjeldende brukerens legitimasjon til å koble til datakilden når en bruker viser dataene. Når den brukes med enkel pålogging, kan sikkerhet på radnivå (RLS) og/eller sikkerhet på objektnivå (OLS) implementeres på datakilden. Dette gjør det mulig for brukere å vise bare data de har tilgang til. Når tilkoblingen er til datakilder i skyen, brukes Microsoft Entra-godkjenning for enkel pålogging. for lokale datakilder støttes Kerberos, Security Assertion Markup Language (SAML) og Microsoft Entra ID.

Hvis datakilden er Azure Analysis Services eller lokale Analysis Services, og RLS og/eller OLS er konfigurert, vil Power Bi-tjeneste bruke sikkerhet på radnivå, og brukere som ikke har tilstrekkelig legitimasjon til å få tilgang til de underliggende dataene (som kan være en spørring som brukes i et instrumentbord, en rapport eller en annen dataartefakt), vil ikke se dataene de ikke har tilstrekkelige rettigheter til.

Premium-funksjoner

Arkitektur for dataflyter

Dataflyter gir brukerne muligheten til å konfigurere bakdatabehandlingsoperasjoner som vil trekke ut data fra polymorfe datakilder, utføre transformasjonslogikk mot dataene og deretter lande den i en målmodell for bruk på tvers av ulike rapporteringspresentasjonsteknologier. Alle brukere som enten har medlems-, bidragsyter- eller administratorrolle i et arbeidsområde, kan opprette en dataflyt. Brukere i visningsrollen kan vise data som behandles av dataflyten, men kan ikke gjøre endringer i sammensetningen. Når en dataflyt er opprettet, kan alle medlemmer, bidragsytere eller administratorer av arbeidsområdet planlegge oppdateringer, samt vise og redigere dataflyten ved å ta eierskap over den.

Hver konfigurerte datakilde er bundet til en klientteknologi for tilgang til denne datakilden. Legitimasjonsstrukturen som kreves for å få tilgang til dem, dannes for å samsvare med nødvendige implementeringsdetaljer for datakilden. Transformasjonslogikk brukes av Power Query-tjenester mens dataene er i bruk. For premium-dataflyter kjører Power Query-tjenester i serverdelnoder. Data kan hentes direkte fra skykildene eller via en gateway som er installert lokalt. Når den trekkes direkte fra en skykilde til tjenesten eller til gatewayen, bruker transporten beskyttelsesmetodikk som er spesifikk for klientteknologien, hvis aktuelt. Når data overføres fra gatewayen til skytjenesten, krypteres den. Se delen Data i transitt ovenfor.

Når angitte datakilder for kunde krever legitimasjon for tilgang, vil eieren/oppretteren av dataflyten gi dem under redigering. De lagres ved hjelp av standard lagringsplass for legitimasjon for hele produktet. Se delen Godkjenning til datakilder ovenfor. Det finnes ulike tilnærminger brukere kan konfigurere for å optimalisere datavedvarighet og tilgang. Dataene plasseres som standard i en Power BI-eid og beskyttet lagringskonto. Lagringskryptering er aktivert på Blob-lagringsbeholderne for å beskytte dataene mens de er i ro. Se delen Data ved hvile nedenfor. Brukere kan imidlertid konfigurere sin egen lagringskonto knyttet til sitt eget Azure-abonnement. Når du gjør dette, får en Power Bi-tjeneste hovedstol tilgang til denne lagringskontoen, slik at den kan skrive dataene der under oppdateringen. I dette tilfellet er eieren av lagringsressursen ansvarlig for å konfigurere kryptering på den konfigurerte ADLS-lagringskontoen. Data sendes alltid til Blob-lagring ved hjelp av kryptering.

Siden ytelsen ved tilgang til lagringskontoer kan være suboptimal for enkelte data, har brukerne også muligheten til å bruke en Power BI-vertsbasert databehandlingsmotor for å øke ytelsen. I dette tilfellet lagres data overflødig i en SQL-database som er tilgjengelig for DirectQuery gjennom tilgang av baksystemet i Power BI. Data krypteres alltid på filsystemet. Hvis brukeren har en nøkkel for å kryptere dataene som er lagret i SQL-databasen, brukes denne nøkkelen til å kryptere dem dobbelt.

Når du spør ved hjelp av DirectQuery, brukes den krypterte transportprotokollen HTTPS til å få tilgang til API-en. All sekundær eller indirekte bruk av DirectQuery styres av de samme tilgangskontrollene som tidligere er beskrevet. Siden dataflyter alltid er bundet til et arbeidsområde, blir tilgang til dataene alltid inngjerdet av brukerens rolle i arbeidsområdet. En bruker må ha minst lesetilgang for å kunne spørre dataene på alle måter.

Når Power BI Desktop brukes til å få tilgang til data i en dataflyt, må den først godkjenne brukeren ved hjelp av Microsoft Entra ID for å avgjøre om brukeren har tilstrekkelige rettigheter til å vise dataene. I så fall anskaffes en SaS-nøkkel og brukes til å få tilgang til lagring direkte ved hjelp av den krypterte transportprotokollen HTTPS.

Behandlingen av data i hele datasamlebåndet avgir overvåkingshendelser i Office 365. Noen av disse hendelsene fanger opp sikkerhets- og personvernrelaterte operasjoner.

Paginerte rapporter

Paginerte rapporter er utformet for å skrives ut eller deles. De kalles paginerte fordi de er formatert slik at de passer godt på en side. De viser alle dataene i en tabell, selv om tabellen strekker seg over flere sider. Du kan kontrollere oppsettet for rapportsiden nøyaktig.

Paginerte rapporter støtter rike og kraftige uttrykk skrevet i Microsoft Visual Basic .NET. Uttrykk brukes mye i Power BI Report Builder-paginerte rapporter for å hente, beregne, vise, gruppere, sortere, filtrere, parametere og formatere data.

Uttrykk opprettes av forfatteren av rapporten med tilgang til det brede utvalget av funksjoner i .NET Framework. Behandling og kjøring av paginerte rapporter utføres i en sandkasse.

Sideformaterte rapportdefinisjoner (RDL) lagres i Power BI, og for å publisere og/eller gjengi en paginert rapport må en bruker godkjenne og godkjenne på samme måte som beskrevet i delen Godkjenning til Power BI-tjenesten ovenfor.

Microsoft Entra-tokenet som innhentes under godkjenningen, brukes til å kommunisere direkte fra nettleseren til Power BI Premium-klyngen.

I Power BI Premium gir Power Bi-tjeneste kjøretid et passende isolert utførelsesmiljø for hver rapportgjengivelse. Dette omfatter tilfeller der rapportene som gjengis tilhører arbeidsområder som er tilordnet til samme kapasitet.

En paginert rapport har tilgang til et bredt sett med datakilder som en del av gjengivelsen av rapporten. Sandkassen kommuniserer ikke direkte med noen av datakildene, men kommuniserer i stedet med den klarerte prosessen for å be om data, og deretter tilføyer den klarerte prosessen den nødvendige legitimasjonen til tilkoblingen. På denne måten har sandkassen aldri tilgang til legitimasjon eller hemmelighet.

For å støtte funksjoner som Bing-kart eller anrop til Azure Functions, har sandkassen tilgang til Internett.

Innebygd analyse med Power BI

Uavhengige programvareleverandører og løsningsleverandører har to hovedmoduser for innebygging av Power BI-artefakter i sine nettprogrammer og portaler: bygg inn for organisasjonen og bygg inn for kundene dine. Artefakten er innebygd i en IFrame i programmet eller portalen. En IFrame har ikke tillatelse til å lese eller skrive data fra det eksterne webprogrammet eller portalen, og kommunikasjonen med IFrame gjøres ved hjelp av SDK for Power BI-klienten ved hjelp av POST-meldinger.

I en innebygging for organisasjonsscenarioet får Microsoft Entra-brukere tilgang til sitt eget Power BI-innhold gjennom portaler som er tilpasset av virksomheter og IT-er. Alle Power BI-policyer og -funksjoner som er beskrevet i denne artikkelen, for eksempel Sikkerhet på radnivå (RLS) og sikkerhet på objektnivå (OLS), brukes automatisk for alle brukere uavhengig av om de får tilgang til Power BI gjennom Power BI-portalen eller gjennom tilpassede portaler.

I et innebyggingsscenario for kundene dine eier ISV-er vanligvis Power BI-leiere og Power BI-elementer (instrumentbord, rapporter, semantiske modeller og andre). Det er ansvaret til en ISV-serverdeltjeneste å godkjenne sluttbrukerne og bestemme hvilke artefakter og hvilket tilgangsnivå som passer for sluttbrukeren. ISV-policybeslutninger krypteres i et innebyggingstoken generert av Power BI og sendes til ISV-serverdelen for videre distribusjon til sluttbrukerne i henhold til forretningslogikken til ISV. Sluttbrukere som bruker en nettleser eller andre klientprogrammer, kan ikke dekryptere eller endre innebyggingstokener. Klientside-SDK-er, for eksempel Power BI-klient-API-er , tilføyer automatisk det krypterte innebyggingstokenet til Power BI-forespørsler som en autorisasjon: EmbedToken-topptekst . Basert på dette toppteksten vil Power BI fremtvinge alle policyer (for eksempel tilgang eller RLS) nøyaktig slik det ble angitt av ISV under generering.

For å aktivere innebygging og automatisering, og for å generere innebyggingstokenene som er beskrevet ovenfor, viser Power BI et rikt sett med REST-API-er. Disse REST-API-ene for Power BI støtter både brukerdelegerte og tjenestekontohaver microsoft Entra-metoder for godkjenning og godkjenning.

Innebygd analyse med Power BI og REST-API-er støtter alle power BI-nettverksisolasjonsfunksjoner som er beskrevet i denne artikkelen: For eksempel servicekoder og private koblinger.

AI-funksjoner

Power BI støtter for øyeblikket to brede kategorier av AI-funksjoner i produktet i dag: ai-visualobjekter og ai-berikelser. Funksjonene for kunstig intelligens på visuelt nivå inkluderer funksjoner som Key-Influencers, Decomposition-Tree, Smart-Narrative, Anomaly Detection, R-visual, Python-visualobjekt, Clustering, Forecasting, Q&A, Quick-Insights osv. Funksjonene for ai-berikelse omfatter funksjoner som AutoML, Azure Machine Læring, CognitiveServices, R/Python transformeringer osv.

De fleste av funksjonene nevnt ovenfor støttes både i delte arbeidsområder og Premium-arbeidsområder i dag. AutoML og CognitiveServices støttes imidlertid bare i Premium-arbeidsområder på grunn av IP-begrensninger. I dag, med AutoML-integreringen i Power BI, kan en bruker bygge og lære opp en egendefinert ML-modell (for eksempel prognose, klassifisering, regresjon osv.) og bruke den til å få prognoser mens de laster inn data i en dataflyt som er definert i et Premium-arbeidsområde. I tillegg kan Power BI-brukere bruke flere CognitiveServices-API-er, for eksempel TextAnalytics og ImageTagging, til å transformere data før de lastes inn i en dataflyt/semantisk modell som er definert i et Premium-arbeidsområde.

Premium AI-berikelsesfunksjonene kan best vises som en samling av tilstandsløse AI-funksjoner/transformeringer som kan brukes av Power BI-brukere i dataintegreringssamlebånd som brukes av en Semantisk Power BI-modell eller dataflyt. Vær oppmerksom på at disse funksjonene også kan åpnes fra gjeldende redigeringsmiljøer for dataflyt/semantisk modell i Power BI-tjenesten og Power BI Desktop. Disse AI-funksjonene/transformeringene kjører alltid i et Premium-arbeidsområde/kapasitet. Disse funksjonene vises i Power BI som en datakilde som krever et Microsoft Entra-token for Power BI-brukeren som bruker AI-funksjonen. Disse AI-datakildene er spesielle fordi de ikke viser noen av sine egne data, og de leverer bare disse funksjonene/transformeringene. Under kjøring foretar ikke disse funksjonene utgående anrop til andre tjenester for å overføre kundens data. La oss se på Premium-scenariene individuelt for å forstå kommunikasjonsmønstrene og relevante sikkerhetsrelaterte detaljer som gjelder dem.

For opplæring og bruk av en AutoML-modell bruker Power BI Azure AutoML SDK og kjører all opplæring i kundens Power BI-kapasitet. Under opplæring av gjentakelser kaller Power BI en eksperimentering av Azure Machine Læring-tjenesten for å velge en passende modell og hyperparametere for gjeldende gjentakelse. I dette utgående kallet sendes bare relevante eksperimentmetadata (for eksempel nøyaktighet, ml-algoritme, algoritmeparametere osv.) fra forrige gjentakelse. AutoML-opplæringen produserer en ONNX-modell og opplæringsrapportdata som deretter lagres i dataflyten. Senere kan Power BI-brukere deretter bruke den opplærte ML-modellen som en transformering for å operasjonalisere ML-modellen på planlagt basis. For TextAnalytics og ImageTagging API-er kaller ikke Power BI API-ene direkte for CognitiveServices-tjenesten, men bruker heller en intern SDK til å kjøre API-ene i Power BI Premium-kapasiteten. I dag støttes disse API-ene i både Power BI-dataflyter og semantiske modeller. Selv om de redigerer en datamodell i Power BI Desktop, kan brukere bare få tilgang til denne funksjonaliteten hvis de har tilgang til et Premium Power BI-arbeidsområde. Derfor blir kunder bedt om å oppgi Microsoft Entra-legitimasjonen sin.

nettverksisolasjon

Denne delen beskriver avanserte sikkerhetsfunksjoner i Power BI. Noen av funksjonene har spesifikke lisensieringskrav. Se avsnittene nedenfor for mer informasjon.

Servicemerker

En tjenestekode representerer en gruppe IP-adresseprefikser fra en gitt Azure-tjeneste. Det bidrar til å minimere kompleksiteten i hyppige oppdateringer av nettverkssikkerhetsregler. Kunder kan bruke servicekoder til å definere nettverkstilgangskontroller i Nettverkssikkerhetsgrupper eller Azure Firewall. Kunder kan bruke servicekoder i stedet for bestemte IP-adresser når de oppretter sikkerhetsregler. Ved å angi navnet på tjenestekoden (for eksempel PowerBI) i det aktuelle kilde- eller målfeltet (for API-er) i en regel, kan kunder tillate eller nekte trafikk for den tilsvarende tjenesten. Microsoft administrerer adresseprefiksene som omfattes av tjenestekoden, og oppdaterer automatisk servicekoden etter hvert som adressene endres.

Privat koblingsintegrering

Azure-nettverk gir Azure Private Link-funksjonen som gjør det mulig for Power BI å gi sikker tilgang via private endepunkter for Azure Networking. Med Azure Private Link og private endepunkter sendes datatrafikk privat ved hjelp av Microsofts infrastruktur for ryggradsnettverk, og dermed krysser ikke dataene Internett.

Private Link sikrer at Power BI-brukere bruker microsofts private nettverksrad når de går til ressurser i Power Bi-tjeneste.

Bruk av privat kobling med Power BI gir følgende fordeler:

• Private Link sikrer at trafikken flyter over Azure-ryggraden til et privat endepunkt for Azure-skybaserte ressurser.
• Nettverkstrafikkisolasjon fra ikke-Azure-basert infrastruktur, for eksempel lokal tilgang, krever at kunder har ExpressRoute eller et virtuelt privat nettverk (VPN) konfigurert.

Se Private koblinger for å få tilgang til Power BI for mer informasjon.

VNet-tilkobling (forhåndsversjon – kommer snart)

Selv om integreringsfunksjonen private koblinger gir sikre innkommende tilkoblinger til Power BI, aktiverer VNet-tilkoblingsfunksjonen sikker utgående tilkobling fra Power BI til datakilder i et VNet.

VNet-gatewayer (Microsoft-administrerte) eliminerer kostnadene ved å installere og overvåke lokale datagatewayer for tilkobling til datakilder som er knyttet til et VNet. De vil imidlertid fortsatt følge den velkjente prosessen med å administrere sikkerhet og datakilder, som med en lokal datagateway.

Følgende er en oversikt over hva som skjer når du samhandler med en Power BI-rapport som er koblet til en datakilde i et VNet ved hjelp av VNet-gatewayer:

1. Power BI-skytjenesten (eller en av de andre støttede skytjenestene) starter en spørring og sender spørringen, datakildedetaljene og legitimasjonen til Power Platform VNet-tjenesten (PP VNet).

2. PP VNet-tjenesten setter deretter sikkert inn en beholder som kjører en VNet-gateway i delnettet. Denne beholderen kan nå koble til datatjenester som er tilgjengelige fra dette delnettet.

3. PP VNet-tjenesten sender deretter spørringen, datakildedetaljene og legitimasjonen til VNet-gatewayen.

4. VNet-gatewayen henter spørringen og kobler til datakildene med denne legitimasjonen.

5. Spørringen sendes deretter til datakilden for kjøring.

6. Etter kjøring sendes resultatene til VNet-gatewayen, og PP VNet-tjenesten sender dataene sikkert fra beholderen til Power BI-skytjenesten.

Denne funksjonen vil snart være tilgjengelig i offentlig forhåndsvisning.

Tjenesteprinsipper

Power BI støtter bruk av tjenestekontohavere. Lagre alle legitimasjoner for tjenestekontohaver som brukes til å kryptere eller få tilgang til Power BI i et nøkkelhvelv, tilordne riktige tilgangspolicyer til hvelvet og regelmessig se gjennom tilgangstillatelser.

Se Automate Premium-arbeidsområdet og semantiske modelloppgaver med tjenestekontohavere for mer informasjon.

Microsoft Purview for Power BI

Microsoft Purview informasjonsbeskyttelse

Power BI er dypt integrert med Microsoft Purview informasjonsbeskyttelse. Microsoft Purview informasjonsbeskyttelse gjør det mulig for organisasjoner å ha én enkelt, integrert løsning for klassifisering, merking, revisjon og samsvar på tvers av Azure, Power BI og Office.

Når informasjonsbeskyttelse er aktivert i Power BI:

• Sensitive data, både i Power Bi-tjeneste og i Power BI Desktop, kan klassifiseres og merkes ved hjelp av de samme følsomhetsetikettene som brukes i Office og i Azure.
• Styringspolicyer kan håndheves når Power BI-innhold eksporteres til Excel-, PowerPoint-, PDF-, Word- eller PBIX-filer , for å sikre at dataene beskyttes selv når de forlater Power BI.
• Det er enkelt å klassifisere og beskytte PBIX-filer i Power BI Desktop, akkurat som det er gjort i Excel-, Word- og PowerPoint-programmer. Filer kan enkelt merkes i henhold til følsomhetsnivået. Videre kan de krypteres hvis de inneholder forretningskonfidensialitetsdata, slik at bare autoriserte brukere kan redigere disse filene.
• Excel-arbeidsbøker arver automatisk følsomhetsetiketter når de kobler til Power BI (forhåndsversjon), noe som gjør det mulig å opprettholde klassifisering fra ende til ende og bruke beskyttelse når Semantiske Power BI-modeller analyseres i Excel.
• Følsomhetsetiketter som brukes på Power BI-rapporter og instrumentbord, er synlige i Power BI iOS- og Android-mobilappene.
• Følsomhetsetiketter vedvarer når en Power BI-rapport er innebygd i Teams, SharePoint eller et sikkert nettsted. Dette hjelper organisasjoner med å opprettholde klassifisering og beskyttelse ved eksport ved innebygging av Power BI-innhold.
• Etikettarv ved oppretting av nytt innhold i Power Bi-tjeneste sikrer at etiketter som brukes på semantiske modeller eller datamarts i Power Bi-tjeneste vil bli brukt på nytt innhold som er opprettet på toppen av de semantiske modellene og datamartene.
• Power BI admin scan API-er kan trekke ut følsomhetsetiketten for et Power BI-element, slik at Power BI- og InfoSec-administratorer kan overvåke merking i Power Bi-tjeneste og produsere utøvende rapporter.
• API-er for Power BI-administratorer gjør det mulig for sentrale team å programmatisk bruke følsomhetsetiketter på innhold i Power Bi-tjeneste.
• Sentrale team kan opprette obligatoriske etikettpolicyer for å fremtvinge bruk av etiketter på nytt eller redigert innhold i Power BI.
• Sentrale team kan opprette standard etikettpolicyer for å sikre at en følsomhetsetikett brukes på alt nytt eller endret Power BI-innhold.
• Automatisk nedstrøms følsomhetsetiketter i Power Bi-tjeneste sikrer at når en etikett på en semantisk modell eller datamart brukes eller endres, brukes eller endres etiketten automatisk på alt nedstrøms innhold som er koblet til semantisk modell eller datamart.

Hvis du vil ha mer informasjon, kan du se Følsomhetsetiketter i Power BI.

policyer for Microsoft Purview hindring av datatap (DLP) for Power BI (forhåndsversjon)

Microsoft Purviews DLP-policyer kan hjelpe organisasjoner med å redusere risikoen for sensitive forretningsdatalekkasjer fra Power BI. DLP-policyer kan hjelpe dem med å oppfylle samsvarskravene i statlige eller bransjeforskrifter, for eksempel GDPR (EUs personvernforordning) eller CCPA (California Consumer Privacy Act) og sørge for at dataene deres i Power BI administreres.

Når DLP-policyer for Power BI er konfigurert:

• Alle semantiske modeller i arbeidsområdene som er angitt i policyen, evalueres av policyen.
• Du kan oppdage når sensitive data lastes opp til Premium-kapasitetene dine. DLP-policyer kan oppdage:
  • Følsomhetsetiketter.
  • Sensitive informasjonstyper. Over 260 typer støttes. Gjenkjenning av sensitiv informasjonstype er avhengig av microsoft Purview-innholdsskanning.
• Når du støter på en semantisk modell som er identifisert som sensitiv, kan du se et tilpasset policytips som hjelper deg med å forstå hva du bør gjøre.
• Hvis du er semantisk modelleier, kan du overstyre en policy og forhindre at den semantiske modellen identifiseres som «sensitiv» hvis du har en gyldig grunn til å gjøre det.
• Hvis du er semantisk modelleier, kan du rapportere et problem med en policy hvis du konkluderer med at en sensitiv informasjonstype er feilaktig identifisert.
• Automatiske risikoreduksjoner, for eksempel varsler til sikkerhetsadministratoren, kan aktiveres.

Hvis du vil ha mer informasjon, kan du se Policyer for hindring av tap av data for Power BI.

Microsoft Defender for Cloud Apps for Power BI

Microsoft Defender for Cloud Apps er en av verdens ledende sikkerhetsmeglere for skytilgang, navngitt som leder i Gartners Magic Quadrant for skytilgangssikkerhetsmeglermarkedet (CASB). Defender for Cloud Apps brukes til å sikre bruken av skyapper. Det gjør det mulig for organisasjoner å overvåke og kontrollere, i sanntid, risikable Power BI-økter, for eksempel brukertilgang fra uadministrerte enheter. Sikkerhetsadministratorer kan definere policyer for å kontrollere brukerhandlinger, for eksempel nedlasting av rapporter med sensitiv informasjon.

Med Defender for Cloud Apps kan organisasjoner få følgende DLP-funksjoner:

• Angi sanntidskontroller for å fremtvinge risikable brukerøkter i Power BI. Hvis for eksempel en bruker kobler til Power BI fra utenfor landet eller området, kan økten overvåkes av sanntidskontrollene Defender for Cloud Apps, og risikable handlinger, for eksempel nedlasting av data merket med en svært konfidensiell følsomhetsetikett, kan blokkeres umiddelbart.
• Undersøk Power BI-brukeraktivitet med aktivitetsloggen Defender for Cloud Apps. Aktivitetsloggen Defender for Cloud Apps inkluderer Power BI-aktivitet som er registrert i overvåkingsloggen for Office 365, som inneholder informasjon om alle bruker- og administratoraktiviteter, samt følsomhetsetikettinformasjon for relevante aktiviteter som bruk, endring og fjerning av etikett. Administratorer kan dra nytte av avanserte filtre for Defender for Cloud Apps og hurtighandlinger for effektive problemundersøkelser.
• Opprett egendefinerte policyer for å varsle om mistenkelig brukeraktivitet i Power BI. Aktivitetspolicyfunksjonen Defender for Cloud Apps kan utnyttes til å definere dine egne egendefinerte regler, for å hjelpe deg med å oppdage brukeratferd som avviker fra normen, og til og med muligens handle på den automatisk, hvis det virker for farlig.
• Arbeid med innebygd avviksgjenkjenning av Defender for Cloud Apps. Avviksgjenkjenningspolicyene for Defender for Cloud Apps gir ut-av-boksen-brukeratferdsanalyse og maskinlæring, slik at du er klar fra begynnelsen for å kjøre avansert trusselgjenkjenning på tvers av skymiljøet. Når en policy for avviksregistrering identifiserer en mistenkelig atferd, utløser den et sikkerhetsvarsel.
• Power BI-administratorrolle i Defender for Cloud Apps-portalen. Defender for Cloud Apps gir en appspesifikk administratorrolle som kan brukes til å gi Power BI-administratorer bare tillatelsene de trenger for å få tilgang til Power BI-relevante data i portalen, for eksempel varsler, brukere i fare, aktivitetslogger og annen Power BI-relatert informasjon.

Se Bruke Microsoft Defender for cloud apps-kontroller i Power BI for mer informasjon.

Forhåndsvis sikkerhetsfunksjoner

Denne delen viser funksjoner som er planlagt å lanseres til mars 2021. Fordi dette emnet viser funksjoner som kanskje ikke er utgitt ennå, kan leveringstidslinjene endres og den forventede funksjonaliteten kan utgis senere enn mars 2021, eller de kan ikke utgis i det hele tatt. Hvis du vil ha mer informasjon om forhåndsvisninger, kan du se vilkårene for nettbaserte tjenester.

Ta med din egen logganalyse (BYOLA)

Bring Your Own Log Analytics muliggjør integrering mellom Power BI og Azure Log Analytics. Denne integreringen inkluderer Azure Log Analytics' avanserte analytiske motor, interaktive spørringsspråk og innebygde maskinlæringskonstruksjoner.

Spørsmål og svar om Power BI-sikkerhet

Følgende spørsmål er vanlige sikkerhetsspørsmål og svar for Power BI. Disse er organisert basert på når de ble lagt til i denne hvitboken, slik at du raskt kan finne nye spørsmål og svar når denne artikkelen oppdateres. De nyeste spørsmålene legges til på slutten av denne listen.

Hvordan kobler brukere til og får tilgang til datakilder mens de bruker Power BI?

• Power BI administrerer legitimasjon til datakilder for hver bruker for skylegitimasjon eller for tilkobling gjennom en personlig gateway. Datakilder som administreres av en lokal datagateway, kan deles på tvers av virksomheten, og tillatelser til disse datakildene kan administreres av gatewayadministratoren. Når du konfigurerer en semantisk modell, kan brukeren velge en legitimasjon fra det personlige lageret eller bruke en lokal datagateway til å bruke en delt legitimasjon.

  I importtilfellet etablerer en bruker en tilkobling basert på brukerens pålogging og får tilgang til dataene med legitimasjonen. Når den semantiske modellen er publisert til Power Bi-tjeneste, bruker Power BI alltid denne brukerens legitimasjon til å importere data. Når dataene er importert, får ikke visning av dataene i rapporter og instrumentbord tilgang til den underliggende datakilden. Power BI støtter enkel påloggingsgodkjenning for valgte datakilder. Hvis tilkoblingen er konfigurert til å bruke enkel pålogging, brukes den semantiske modelleierens legitimasjon til å koble til datakilden.

  For rapporter som er koblet til DirectQuery, kobles datakilden direkte til ved hjelp av en forhåndskonfigurert legitimasjon, den forhåndskonfigurerte legitimasjonen brukes til å koble til datakilden når en bruker viser dataene. Hvis en datakilde er koblet direkte til ved hjelp av enkel pålogging, brukes den gjeldende brukerens legitimasjon til å koble til datakilden når brukeren viser dataene. Når du bruker med enkel pålogging, kan sikkerhet på radnivå (RLS) og/eller sikkerhet på objektnivå (OLS) implementeres på datakilden, og dette gjør det mulig for brukere å vise data de har tilgangsrettigheter til. Når tilkoblingen er til datakilder i skyen, brukes Microsoft Entra-godkjenning for enkel pålogging. for lokale datakilder støttes Kerberos, SAML og Microsoft Entra ID.

  Når du kobler til Kerberos, sendes brukerens UPN til gatewayen og bruker Kerberos-avgrenset delegering, brukeren representeres og kobles til de respektive datakildene. SAML støttes også på gatewayen for SAP HANA-datakilden. Mer informasjon er tilgjengelig i oversikten over enkel pålogging for gatewayer.

  Hvis datakilden er Azure Analysis Services eller lokal Analysis Services og Sikkerhet på radnivå (RLS) og/eller sikkerhet på objektnivå (OLS) er konfigurert, vil Power Bi-tjeneste bruke sikkerhet på radnivå, og brukere som ikke har tilstrekkelig legitimasjon til å få tilgang til de underliggende dataene (som kan være en spørring som brukes i et instrumentbord, en rapport eller en annen dataartefakt), vil ikke se data som brukeren ikke har tilstrekkelige rettigheter for.

  Sikkerhet på radnivå med Power BI kan brukes til å begrense datatilgang for gitte brukere. Filtre begrenser datatilgang på radnivå, og du kan definere filtre i rollen.

  Sikkerhet på objektnivå (OLS) kan brukes til å sikre sensitive tabeller eller kolonner. Men i motsetning til sikkerhet på radnivå sikrer sikkerhet på objektnivå også objektnavn og metadata. Dette bidrar til å hindre at ondsinnede brukere oppdager selv eksistensen av slike objekter. Sikrede tabeller og kolonner skjules i feltlisten når du bruker rapporteringsverktøy som Excel eller Power BI, og dessuten får ikke brukere uten tillatelse tilgang til sikrede metadataobjekter via DAX eller noen annen metode. Fra synspunktet til brukere uten riktige tilgangstillatelser finnes ikke sikre tabeller og kolonner.

  Sikkerhet på objektnivå, sammen med sikkerhet på radnivå, muliggjør forbedret sikkerhet på bedriftsnivå på rapporter og semantiske modeller, slik at bare brukere med nødvendige tillatelser har tilgang til å vise og samhandle med sensitive data.

Hvordan overføres data til Power BI?

• Alle data som er forespurt og overført av Power BI, krypteres i transitt ved hjelp av HTTPS (bortsett fra når datakilden som er valgt av kunden, ikke støtter HTTPS) for å koble fra datakilden til Power Bi-tjeneste. En sikker tilkobling opprettes med dataleverandøren, og bare når tilkoblingen er opprettet, vil data krysse nettverket.

Hvordan bufrer Power BI rapport- eller instrumentbord eller modelldata, og er det sikkert?

• Når en datakilde åpnes, følger Power Bi-tjeneste prosessen som er beskrevet i delen Godkjenning til datakilder tidligere i dette dokumentet.

Bufrer klienter nettsidedata lokalt?

• Når nettleserklienter får tilgang til Power BI, angir Power BI-nettserverne Cache-Control-direktivet til no-store. Direktivet om ikke-lagring instruerer nettlesere om ikke å bufre nettsiden som vises av brukeren, og ikke lagre nettsiden i klientens hurtigbuffermappe.

Hva med rollebasert sikkerhet, deling av rapporter eller instrumentbord og datatilkoblinger? Hvordan fungerer dette når det gjelder datatilgang, instrumentbordvisning, rapporttilgang eller oppdatering?

• For ikke-rollenivåsikkerhet (RLS) aktiverte datakilder, hvis et instrumentbord, en rapport eller en datamodell deles med andre brukere via Power BI, er dataene tilgjengelige for brukere som de er delt med for å vise og samhandle med. Power BI godkjenner ikke brukere på nytt mot den opprinnelige datakilden. Når dataene er lastet opp til Power BI, er brukeren som godkjente mot kildedataene, ansvarlig for å administrere hvilke andre brukere og grupper som kan vise dataene.

  Når datatilkoblinger opprettes til en RLS-kompatibel datakilde, for eksempel en Analysis Services-datakilde, bufres bare instrumentborddata i Power BI. Hver gang en rapport eller semantisk modell vises eller åpnes i Power BI som bruker data fra den RLS-kompatible datakilden, får Power Bi-tjeneste tilgang til datakilden for å hente data basert på brukerens legitimasjon, og hvis det finnes tilstrekkelige tillatelser, lastes dataene inn i rapporten eller datamodellen for denne brukeren. Hvis godkjenningen mislykkes, vil brukeren se en feil.

  Hvis du vil ha mer informasjon, kan du se delen Godkjenning til datakilder tidligere i dette dokumentet.

Brukerne våre kobler seg til de samme datakildene hele tiden, hvorav noen krever legitimasjon som er forskjellig fra domenelegitimasjonen. Hvordan kan de unngå å måtte skrive inn denne legitimasjonen hver gang de oppretter en datatilkobling?

• Power BI tilbyr Power BI Personal Gateway, som er en funksjon som lar brukere opprette legitimasjon for flere forskjellige datakilder, og deretter automatisk bruke denne legitimasjonen når de senere får tilgang til hver av disse datakildene. Hvis du vil ha mer informasjon, kan du se Power BI Personal Gateway.

Hvilke porter brukes av lokal datagateway og personlig gateway? Er det noen domenenavn som må tillates for tilkoblingsformål?

• Det detaljerte svaret på dette spørsmålet er tilgjengelig på følgende kobling: Gateway-porter

Når du arbeider med den lokale datagatewayen, hvordan brukes gjenopprettingsnøkler og hvor lagres de? Hva med sikker legitimasjonsbehandling?

• Administratoren skriver inn en gateway-gjenopprettingsnøkkel under installasjon og konfigurasjon av gateway. Denne gjenopprettingsnøkkelen brukes til å generere en sterk AES-symmetrisk nøkkel. En RSA-asymmetrisk nøkkel opprettes også samtidig.

  Disse genererte nøklene (RSA og AES) lagres i en fil på den lokale maskinen. Denne filen er også kryptert. Innholdet i filen kan bare dekrypteres av den bestemte Windows-maskinen, og bare av den bestemte gateway-tjenestekontoen.

  Når en bruker skriver inn legitimasjon for datakilder i brukergrensesnittet for Power Bi-tjeneste, krypteres legitimasjonen med fellesnøkkelen i nettleseren. Gatewayen dekrypterer legitimasjonen ved hjelp av RSA-privatnøkkelen og krypterer dem på nytt med en AES-symmetrisk nøkkel før dataene lagres i Power Bi-tjeneste. Med denne prosessen har Power Bi-tjeneste aldri tilgang til de ukrypterte dataene.

Hvilke kommunikasjonsprotokoller brukes av den lokale datagatewayen, og hvordan sikres de?

• Gatewayen støtter følgende to kommunikasjonsprotokoller:

  • AMQP 1.0 – TCP + TLS: Denne protokollen krever at portene 443, 5671-5672 og 9350-9354 er åpne for utgående kommunikasjon. Denne protokollen er foretrukket, siden den har lavere kommunikasjonsoverliggende.

  • HTTPS – WebSockets over HTTPS + TLS: Denne protokollen bruker bare port 443. WebSocket startes av én enkelt HTTP CONNECT-melding. Når kanalen er etablert, er kommunikasjonen i hovedsak TCP+TLS. Du kan tvinge gatewayen til å bruke denne protokollen ved å endre en innstilling som er beskrevet i den lokale gatewayartikkelen.

Hva er rollen til Azure CDN i Power BI?

• Som nevnt tidligere bruker Power BI Azure Content Delivery Network (CDN) til effektivt å distribuere nødvendig statisk innhold og filer til brukere basert på geografisk nasjonal innstilling. Hvis du vil gå i detalj, bruker Power Bi-tjeneste flere CDN-er til effektivt å distribuere nødvendig statisk innhold og filer til brukere via offentlig Internett. Disse statiske filene inkluderer produktnedlastinger (for eksempel Power BI Desktop, den lokale datagatewayen eller Power BI-apper fra ulike uavhengige tjenesteleverandører), nettleserkonfigurasjonsfiler som brukes til å starte og etablere eventuelle etterfølgende tilkoblinger med Power Bi-tjeneste, samt den første sikre Power BI-påloggingssiden.

  Basert på informasjon som ble oppgitt under en innledende tilkobling til Power Bi-tjeneste, kontakter en brukers nettleser den angitte Azure CDN (eller for enkelte filer, WFE) for å laste ned samlingen av angitte fellesfiler som er nødvendige for å aktivere nettleserens samhandling med Power Bi-tjeneste. Nettlesersiden inneholder deretter Microsoft Entra-tokenet, øktinformasjonen, plasseringen til den tilknyttede bakklyngen og samlingen av filer som er lastet ned fra Azure CDN- og WFE-klyngen, så lenge Power Bi-tjeneste nettleserøkten varer.

Utfører Microsoft noen sikkerhets- eller personvernvurdering av den egendefinerte visuelle koden før du publiserer elementer til galleriet for Power BI-visualobjekter?

• Nei. Det er kundens ansvar å se gjennom og avgjøre om egendefinert visuell kode skal stoles på. All egendefinert visuell kode drives i et sandkassemiljø, slik at eventuelle feilkoder i et egendefinert visualobjekt ikke påvirker resten av Power Bi-tjeneste negativt.

Finnes det andre Power BI-visualobjekter som sender informasjon utenfor kundenettverket?

• Ja. Bing-Kart- og ESRI-visualobjekter overfører data ut av Power Bi-tjeneste for visualobjekter som bruker disse tjenestene.

Utfører Microsoft noen sikkerhets- eller personvernvurdering av malappen før du publiserer elementer til galleriet for malapper?

• Nei. Apputgiveren er ansvarlig for innholdet mens det er kundens ansvar å se gjennom og avgjøre om du vil klarere malapputgiveren.

Finnes det malapper som kan sende informasjon utenfor kundenettverket?

• Ja. Det er kundens ansvar å se gjennom utgiverens personvernerklæring og avgjøre om malappen skal installeres på leieren. Utgiveren er ansvarlig for å informere kunden om appens virkemåte og funksjoner.

Hva med datasuverenitet? Kan vi klargjøre leiere i datasentre som befinner seg i bestemte geografiske områder, for å sikre at data ikke forlater landet eller områdegrensene?

• Enkelte kunder i bestemte geografiske områder har mulighet til å opprette en leier i en nasjonal/regional sky, der datalagring og behandling holdes atskilt fra alle andre datasentre. Nasjonale/regionale skyer har en litt annen type sikkerhet, siden en egen dataforstyrer driver den nasjonale/regionale skyen Power Bi-tjeneste på vegne av Microsoft.

  Kunder kan også konfigurere en leier i et bestemt område. Slike leiere har imidlertid ikke en egen datastyrer fra Microsoft. Priser for nasjonale/regionale skyer er forskjellig fra de generelt tilgjengelige kommersielle Power Bi-tjeneste. Hvis du vil ha mer informasjon om Power Bi-tjeneste tilgjengelighet for nasjonale/regionale skyer, kan du se nasjonale/regionale skyer i Power BI.

Hvordan behandler Microsoft tilkoblinger for kunder som har Power BI Premium-abonnementer? Er disse tilkoblingene annerledes enn de som er etablert for ikke-Premium-Power Bi-tjeneste?

• Tilkoblingene som er opprettet for kunder med Power BI Premium-abonnementer implementerer en godkjenningsprosess for Microsoft Entra business-to-business (B2B), ved hjelp av Microsoft Entra ID for å aktivere tilgangskontroll og godkjenning. Power BI håndterer tilkoblinger fra Power BI Premium-abonnenter til Power BI Premium-ressurser på samme måte som alle andre Microsoft Entra-brukere.

Hvordan fungerer godkjenning på serversiden i WFE?

• Godkjenningen av brukergodkjenningssekvensen for tjenestesiden forekommer som beskrevet i følgende trinn, som er illustrert i bildet som følger dem.

1. En bruker starter en tilkobling til Power Bi-tjeneste fra en nettleser, enten ved å skrive inn Power BI-adressen på adresselinjen eller ved å velge Logg på fra markedsføringssiden for Power BI (https://powerbi.microsoft.com). Tilkoblingen opprettes ved hjelp av TLS 1.2 og HTTPS, og all etterfølgende kommunikasjon mellom nettleseren og Power Bi-tjeneste bruker HTTPS.

2. Azure Traffic Manager kontrollerer brukerens DNS-post for å finne det mest hensiktsmessige (vanligvis nærmeste) datasenteret der Power BI distribueres, og svarer på DNS med IP-adressen til WFE-klyngen som brukeren skal sendes til.

3. WFE omdirigerer deretter brukeren til påloggingssiden for Microsoft Online Services.

4. Når brukeren er godkjent, omdirigerer påloggingssiden brukeren til den tidligere bestemte nærmeste Power Bi-tjeneste WFE-klyngen med en godkjenningskode.

5. WFE-klyngen kontrollerer med Microsoft Entra ID for å få et Microsoft Entra-sikkerhetstoken ved hjelp av godkjenningskoden. Når Microsoft Entra ID returnerer den vellykkede godkjenningen av brukeren og returnerer et Microsoft Entra-sikkerhetstoken, ser WFE-klyngen power bi global tjeneste, som opprettholder en liste over leiere og deres Power BI-serverdelklyngeplasseringer og bestemmer hvilken Power BI-serverdeltjenesteklynge som inneholder brukerens leier. WFE-klyngen returnerer deretter en programside til brukerens nettleser med økt-, tilgangs- og rutinginformasjonen som kreves for operasjonen.

6. Når klientens nettleser krever kundedata, sender den forespørsler til serverdelklyngeadressen med Microsoft Entra-tilgangstokenet i autorisasjonshodet. Power BI-bakklyngen leser Microsoft Entra-tilgangstokenet og validerer signaturen for å sikre at identiteten for forespørselen er gyldig. Microsoft Entra-tilgangstokenet har angitt en utløpsdato i henhold til Microsoft Entra-policyer, og for å opprettholde den gjeldende økten vil Power BI-klienten i brukerens nettleser sende periodiske forespørsler om å fornye tilgangstokenet før det utløper.

Tilleggsressurser

Hvis du vil ha mer informasjon om Power BI, kan du se følgende ressurser.

• Komme i gang med Power BI Desktop
• Rest-API for Power BI – oversikt
• Power BI-API referanse
• Lokal datagateway
• Nasjonale/regionale skyer i Power BI
• Power BI Premium
• Oversikt over enkel pålogging (SSO) for gatewayer i Power BI