Hvidbog om Sikkerhed i Power BI

Resumé: Power BI er en onlinesoftwaretjeneste (SaaS eller Software as a Service) fra Microsoft, der gør det nemt og hurtigt at oprette selvbetjente Business Intelligence-dashboards, rapporter, semantiske modeller (tidligere kendt som datasæt) og visualiseringer. Med Power BI kan du oprette forbindelse til mange forskellige datakilder, kombinere og forme data fra disse forbindelser og derefter oprette rapporter og dashboards, der 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 korrekturlæsere: Cristian Petculescu, Amir Netz, Sergei Gundorov

Gælder for: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics Power BI – Mobil.

Bemærk

Du kan gemme eller udskrive dette whitepaper ved at vælge Udskriv i browseren og derefter vælge Gem som PDF.

Introduktion

Power BI er en onlinesoftwaretjeneste (SaaS eller Software as a Service) fra Microsoft, der gør det nemt og hurtigt at oprette selvbetjente Business Intelligence-dashboards, rapporter, semantiske modeller og visualiseringer. Med Power BI kan du oprette forbindelse til mange forskellige datakilder, kombinere og forme data fra disse forbindelser og derefter oprette rapporter og dashboards, der kan deles med andre.

Verden ændrer sig hurtigt. organisationer gennemgår en accelereret digital transformation, og vi oplever en massiv stigning i fjernarbejde, øget kundeefterspørgsel efter onlinetjenester og øget brug af avancerede teknologier i drift og forretningsprocesser. Og alt dette er drevet af clouden.

Efterhånden som overgangen til cloudmiljøet er ændret fra en strøm til en oversvømmelse og med det nye synlige overfladeområde, der følger med, spørger flere virksomheder, hvor sikre mine data er i cloudmiljøet? og Hvilken komplette beskyttelse er tilgængelig for at forhindre, at mine følsomme data lækker? Og for de BI-platforme, der ofte håndterer nogle af de mest strategiske oplysninger i virksomheden, er disse spørgsmål dobbelt vigtige.

Det årtier gamle fundament for BI-sikkerhedsmodellen – sikkerhed på objektniveau og på rækkeniveau – mens den stadig er vigtig, er helt klart ikke længere tilstrækkelig til at levere den type sikkerhed, der er behov for i cloudtiden. Organisationer skal i stedet søge efter en cloudbaseret sikkerhedsløsning med flere niveauer til deres business intelligence-data.

Power BI er bygget til at levere brancheførende komplet og hermetisk beskyttelse af data. Produktet har optjent de højeste sikkerhedsklassificeringer, der er tilgængelige i branchen, og i dag overlader mange nationale sikkerhedsbureauer, finansielle institutioner og sundhedsudbydere det til deres mest følsomme oplysninger.

Det hele starter med fundamentet. Efter en hård periode i begyndelsen af 2000'erne foretog Microsoft massive investeringer for at håndtere sine sikkerhedsrisici og i de følgende årtier bygget en stærk sikkerhedsstak, der går lige så dybt som maskinens bioskerne på chip og udvider hele vejen op til slutbrugeroplevelser. Disse omfattende investeringer fortsætter, og i dag beskæftiger mere end 3.500 Microsoft-teknikere sig med at bygge og forbedre Microsofts sikkerhedsstak og proaktivt håndtere det stadigt skiftende trusselslandskab. Med milliarder af computere, billioner af logins og utallige zettabytes af oplysninger, der er betroet microsofts beskyttelse, har virksomheden nu den mest avancerede sikkerhedsstak i den tekniske branche og betragtes bredt som den globale leder i kampen mod ondsindede aktører.

Power BI bygger på dette stærke fundament. Den bruger den samme sikkerhedsstak, der gav Azure ret til at betjene og beskytte verdens mest følsomme data, og den integreres med de mest avancerede værktøjer til beskyttelse af oplysninger og overholdelse af angivne standarder i Microsoft 365. Derudover leverer den sikkerhed via flere lags sikkerhedsforanstaltninger, hvilket resulterer i end-to-end-beskyttelse, der er designet til at håndtere de unikke udfordringer i cloud-æraen.

For at levere en komplette løsning til beskyttelse af følsomme aktiver skal produktteamet håndtere udfordrende kundeproblemer på flere samtidige fronter:

• Hvordan styrer vi, hvem der kan oprette forbindelse, hvor de opretter forbindelse fra, og hvordan de opretter forbindelse?Hvordan kan vi styre forbindelserne?
• Hvordan gemmes dataene?Hvordan krypteres den?Hvilke kontrolelementer har jeg på mine data?
• Hvordan gør jeg styre og beskytte mine følsomme data?Hvordan gør jeg sikre, at disse data ikke kan lække uden for organisationen?
• Hvordan gør jeg revision, der udfører hvilke handlinger?Hvordan gør jeg reagere hurtigt, hvis der er mistænkelig aktivitet på tjenesten?

Denne artikel indeholder et omfattende svar på alle disse spørgsmål. Det starter med en oversigt over tjenestearkitekturen og forklarer, hvordan de primære flow i systemet fungerer. Derefter fortsætter den med at beskrive, hvordan brugerne godkendes i Power BI, hvordan dataforbindelser oprettes, og hvordan Power BI gemmer og flytter data gennem tjenesten. I det sidste afsnit beskrives de sikkerhedsfunktioner, der gør det muligt for dig som tjenesteadministrator at beskytte dine mest værdifulde aktiver.

Power BI-tjeneste er underlagt vilkårene for Microsoft Online Services og Microsoft Enterprise-erklæringen om beskyttelse af personlige oplysninger. Du kan finde placeringen af databehandlingen under Vilkår for databehandlingsplacering i Vilkårene for Microsoft Online-tjenester og i tilføjelsesprogrammet Databeskyttelse. Microsoft Trust Center er den primære ressource til Power BI for at få oplysninger om overholdelse af angivne standarder. Power BI-teamet arbejder hårdt på at give kunderne de nyeste innovationer og produktivitet. Få mere at vide om overholdelse af angivne standarder i Microsofts tilbud om overholdelse af angivne standarder.

Power BI-tjeneste følger SDL (Security Development Lifecycle), strenge sikkerhedspraksisser, der understøtter krav til sikkerhed og overholdelse af angivne standarder. SDL hjælper udviklere med at bygge mere sikker software ved at reducere antallet og alvorsgraden af sårbarheder i software, samtidig med at udviklingsomkostningerne reduceres. Få mere at vide i Praksis for Microsoft Security Development Lifecycle.

Power BI-arkitektur

Power BI-tjeneste er bygget på Azure, Microsofts cloudcomputingplatform. Power BI er i øjeblikket udrullet i mange datacentre over hele verden – der er mange aktive udrulninger, der er gjort tilgængelige for kunder i de områder, der betjenes af disse datacentre, og et lige antal passive udrulninger, der fungerer som sikkerhedskopier for hver aktiv udrulning.

Webfrontendklynge (WFE)

WFE-klyngen giver brugerens browser det indledende HTML-sideindhold ved indlæsning af webstedet og peger på CDN-indhold, der bruges til at gengive webstedet i browseren.

En WFE-klynge består af et ASP.NET websted, der kører i Azure App Service-miljøet. Når brugerne forsøger at oprette forbindelse til Power BI-tjeneste, kan klientens DNS-tjeneste kommunikere med Azure Traffic Manager for at finde det mest relevante (normalt nærmeste) datacenter med en Power BI-udrulning. Du kan få flere oplysninger om denne proces under Metoden performance traffic-routing for Azure Traffic Manager.

Statiske ressourcer, f.eks. *.js, *.css og billedfiler, gemmes hovedsageligt på et CDN (Azure Content Delivery Network) og hentes direkte af browseren. Bemærk, at udrulninger af nationale offentlige klynger er en undtagelse fra denne regel, og af hensyn til overholdelse af angivne standarder udelades CDN og i stedet bruges en WFE-klynge fra et kompatibelt område til hosting af statisk indhold.

Power BI-back end-klynge (BE)

Back end-klyngen er rygraden i alle de funktioner, der er tilgængelige i Power BI. Den består af flere tjenesteslutpunkter, der forbruges af webfrontend- og API-klienter samt arbejdstjenester i baggrunden, databaser, cachelagre og forskellige andre komponenter.

Back end er tilgængelig i de fleste Azure-områder og udrulles i nye områder, efterhånden som de bliver tilgængelige. Et enkelt Azure-område er vært for en eller flere back end-klynger, der tillader ubegrænset vandret skalering af Power BI-tjeneste, når de lodrette og vandrette skaleringsgrænser for en enkelt klynge er opbrugt.

Hver back end-klynge er stateful og hoster alle data for alle de lejere, der er tildelt til den pågældende klynge. En klynge, der indeholder dataene for en bestemt lejer, kaldes lejerens hjemmeklynge. En godkendt brugers hjemmeklyngeoplysninger leveres af den globale tjeneste og bruges af webfrontend til at dirigere anmodninger til lejerens hjemmeklynge.

Hver back-end-klynge består af flere virtuelle maskiner kombineret i flere sæt, der kan tilpasses til at udføre bestemte opgaver, tilstandsfulde ressourcer, f.eks. SQL-databaser, lagerkonti, servicebusser, cachelagre og andre nødvendige cloudkomponenter.

Lejermetadata og -data gemmes inden for klyngegrænser undtagen datareplikering til en sekundær back end-klynge i et parvis Azure-område i samme Azure-geografi. Den sekundære back end-klynge fungerer som en failoverklynge i tilfælde af regional afbrydelse og er passiv når som helst.

Back end-funktionalitet betjenes af mikrotjenester, der kører på forskellige maskiner i klyngens virtuelle netværk, som ikke er tilgængelige udefra, bortset fra to komponenter, der kan tilgås fra det offentlige internet:

• Gatewaytjeneste
• Azure API Management

Power BI Premium-infrastruktur

Power BI Premium tilbyder en tjeneste til abonnenter, der kræver Premium Power BI-funktioner, f.eks. avanceret AI, distribution til brugere uden licens osv. Når en kunde tilmelder sig et Power BI Premium-abonnement, oprettes Premium-kapaciteten via Azure Resource Manager.

Power BI Premium-kapaciteter hostes i back end-klynger, der er uafhængige af den almindelige Power BI-backend – se ovenfor). Dette giver bedre isolation, ressourceallokering, supportabilitet, sikkerhedsisolering og skalerbarhed af Premium-tilbuddet.

I følgende diagram illustreres arkitekturen af Power BI Premium-infrastrukturen:

Forbindelsen til Power BI Premium-infrastrukturen kan udføres på mange måder, afhængigt af brugerscenariet. Power BI Premium-klienter kan være en brugers browser, en almindelig Power BI-backend, direkte forbindelser via XMLA-klienter, ARM-API'er osv.

Power BI Premium-infrastrukturen i et Azure-område består af flere Power BI Premium-klynger (minimum er en). De fleste Premium-ressourcer er indkapslet i en klynge (f.eks. beregning), og der er nogle almindelige regionale ressourcer (f.eks. metadatalager). Premium-infrastruktur giver mulighed for to måder at opnå horisontal skalerbarhed på i et område: øge ressourcerne i klynger og/eller tilføje flere klynger efter behov (hvis klyngeressourcer nærmer sig deres grænser).

Rygraden i hver klynge er beregningsressourcer, der administreres af Virtual Machine Scale Sets og Azure Service Fabric. Virtual Machine Scale Sets og Service Fabric muliggør hurtig og smertefri forøgelse af beregningsnoder i takt med, at forbruget vokser og organiserer udrulning, administration og overvågning af Power BI Premium-tjenester og -programmer.

Der er mange omkringliggende ressourcer, der sikrer en sikker og pålidelig infrastruktur: belastningsjusteringer, virtuelle netværk, netværkssikkerhedsgrupper, servicebus, lager osv. Alle hemmeligheder, nøgler og certifikater, der kræves til Power BI Premium, administreres udelukkende af Azure Key Vault . Al godkendelse udføres udelukkende via integration med Microsoft Entra-id (tidligere kaldet Azure Active Directory).

Alle anmodninger, der kommer til Power BI Premium-infrastruktur, går først til frontendnoder – de er de eneste noder, der er tilgængelige for eksterne forbindelser. Resten af ressourcerne er skjult bag virtuelle netværk. Frontendnoderne godkender anmodningen, håndterer den eller videresender den til de relevante ressourcer (f.eks. back end-noder).

Back end-noder indeholder de fleste funktioner og funktioner i Power BI Premium.

Power BI Mobile

Power BI – Mobil er en samling apps, der er udviklet til de tre primære mobilplatforme: Android, iOS og Windows (UWP). Sikkerhedsovervejelser i forbindelse med de Power BI – Mobil apps falder i to kategorier:

• Enhedskommunikation
• Appen og dataene på enheden

I forbindelse med enhedskommunikation kommunikerer alle Power BI – Mobil programmer med Power BI-tjeneste og bruger de samme forbindelses- og godkendelsessekvenser, der bruges af browsere, hvilket beskrives detaljeret tidligere i dette whitepaper. Power BI-mobilapps til iOS og Android åbner en browsersession i selve programmet, mens Windows-mobilappen viser en mægler til at etablere kommunikationskanalen med Power BI (til logonprocessen).

I følgende tabel vises understøttelse af certifikatbaseret godkendelse (CBA) for Power BI – Mobil baseret på platformen til mobilenheder:

CBA-understøttelse	iOS	Android	Vinduer
Power BI (log på tjenesten)	Understøttet	Understøttet	Ikke understøttet
SSRS ADFS i det lokale miljø (opret forbindelse til SSRS-server)	Ikke understøttet	Understøttet	Ikke understøttet
SSRS-app-proxy	Understøttet	Understøttet	Ikke understøttet

Power BI – Mobil apps kommunikerer aktivt med Power BI-tjeneste. Telemetri bruges til at indsamle statistik for brug af mobilapps og lignende data, som sendes til tjenester, der bruges til at overvåge forbrug og aktivitet. der sendes ingen kundedata med telemetri.

Power BI-programmet gemmer data på enheden, der letter brugen af appen:

• Microsoft Entra ID- og opdateringstokens gemmes i en sikker mekanisme på enheden ved hjælp af branchestandardsikkerhedsforanstaltninger.
• Data og indstillinger (nøgleværdipar til brugerkonfiguration) cachelagres i lageret på enheden og kan krypteres af operativsystemet. I iOS sker dette automatisk, når brugeren angiver en adgangskode. I Android kan dette konfigureres i indstillingerne. I Windows opnås det ved hjælp af BitLocker.
• For Android- og iOS-apps cachelagres data og indstillinger (nøgleværdipar til brugerkonfiguration) i lageret på enheden i en sandkasse og internt lager, der kun er tilgængeligt for appen. For Windows-appen er dataene kun tilgængelige for brugeren (og systemadministratoren).
• Geografisk placering aktiveres eller deaktiveres eksplicit af brugeren. Hvis indstillingen er aktiveret, gemmes geografiske data ikke på enheden, og de deles ikke med Microsoft.
• Meddelelser aktiveres eller deaktiveres eksplicit af brugeren. Hvis indstillingen er aktiveret, understøtter Android og iOS ikke krav til geografisk dataopbevaring for meddelelser.

Datakryptering kan forbedres ved at anvende kryptering på filniveau via Microsoft Intune, en softwaretjeneste, der leverer administration af mobilenheder og programmer. Alle tre platforme, som Power BI – Mobil er tilgængelig for, understøtter Intune. Når Intune er aktiveret og konfigureret, krypteres data på mobilenheden, og selve Power BI-programmet kan ikke installeres på et SD-kort. Få mere at vide om Microsoft Intune.

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

For at implementere SSO er nogle sikre lagerværdier, der er relateret til den tokenbaserede godkendelse, tilgængelige for andre Microsoft-førstepartsapps (f.eks. Microsoft Authenticator) og administreres af Microsoft Authentication Library (MSAL).

Power BI – Mobil cachelagrede data slettes, når appen fjernes, når brugeren logger af Power BI – Mobil, eller når brugeren ikke logger på (f.eks. efter en udløbshændelse for tokenet eller ændring af adgangskode). Datacachen indeholder dashboards og rapporter, der tidligere er tilgået fra Power BI – Mobil-appen.

Power BI – Mobil har ikke adgang til andre programmapper eller -filer på enheden.

Med Power BI-apps til iOS og Android kan du beskytte dine data ved at konfigurere yderligere identifikation, f.eks. at angive Face ID, Touch ID eller en adgangskode til iOS og biometriske data (fingeraftryks-id) til Android. Få mere at vide om yderligere identifikation.

Godkendelse til Power BI-tjeneste

Brugergodkendelse til Power BI-tjeneste består af en række anmodninger, svar og omdirigeringer mellem brugerens browser og Power BI-tjeneste eller de Azure-tjenester, der bruges af Power BI. I denne sekvens beskrives processen for brugergodkendelse i Power BI, som følger microsoft Entra-godkendelseskodens tildelingsflow. Du kan finde flere oplysninger om indstillinger for en organisations brugergodkendelsesmodeller (logonmodeller) under Vælg en logonmodel til Microsoft 365.

Godkendelsessekvens

Brugergodkendelsessekvensen for Power BI-tjeneste forekommer som beskrevet i følgende trin, som illustreres på det billede, der følger efter dem.

1. En bruger starter en forbindelse til Power BI-tjeneste fra en browser, enten ved at skrive Power BI-adressen på adresselinjen eller ved at vælge Log på på på Power BI-marketingsiden (https://powerbi.microsoft.com). Forbindelsen oprettes ved hjælp af TLS og HTTPS, og al efterfølgende kommunikation mellem browseren og Power BI-tjeneste bruger HTTPS.

2. Azure Traffic Manager kontrollerer brugerens DNS-post for at bestemme det mest relevante (normalt nærmeste) datacenter, hvor Power BI er installeret, og reagerer på DNS med IP-adressen på den WFE-klynge, som brugeren skal sendes til.

3. WFE returnerer derefter en HTML-side til browserklienten, som indeholder en MSAL.js biblioteksreference, der er nødvendig for at starte logonflowet.

4. Browserklienten indlæser den HTML-side, der er modtaget fra WFE, og omdirigerer brugeren til logonsiden til Microsoft Online Services.

5. Når brugeren er blevet godkendt, omdirigerer logonsiden brugeren tilbage til Power BI WFE-siden med en godkendelseskode.

6. Browserklienten indlæser HTML-siden og bruger godkendelseskoden til at anmode om tokens (adgang, id, opdatering) fra Microsoft Entra-id.

7. Brugerens lejer-id bruges af browserklienten til at forespørge på den globale Power BI-tjeneste, som vedligeholder en liste over lejere og deres Back End-klyngeplaceringer i Power BI. Den globale Power BI-tjeneste bestemmer, hvilken Power BI-backendtjenesteklynge der indeholder brugerens lejer, og returnerer URL-adressen til Power BI-backend-klyngen til klienten igen.

8. Klienten kan nu kommunikere med URL-API'en til Power BI-back end-klyngen ved hjælp af adgangstokenet i godkendelsesheaderen for HTTP-anmodningerne. Microsoft Entra-adgangstokenet har en udløbsdato, der er angivet i henhold til Microsoft Entra-politikker, og for at bevare den aktuelle session foretager Power BI-klienten i brugerens browser periodiske anmodninger om at forny adgangstokenet, før det udløber.

I de sjældne tilfælde, hvor godkendelse på klientsiden mislykkes på grund af en uventet fejl, forsøger koden at falde tilbage til at bruge serverbaseret godkendelse i WFE. Se afsnittet spørgsmål og svar i slutningen af dette dokument for at få flere oplysninger om godkendelsesflowet på serversiden.

Dataopbevaring

Medmindre andet er angivet i dokumentationen, gemmer Power BI kundedata i et Azure-geografi, der tildeles, når en Microsoft Entra-lejer tilmelder sig Power BI-tjeneste for første gang. En Microsoft Entra-lejer indeholder bruger- og programidentiteter, grupper og andre relevante oplysninger, der vedrører en organisation og dens sikkerhed.

Tildelingen af et Azure-geografi for lejerdatalager udføres ved at knytte det land eller område, der er valgt som en del af konfigurationen af Microsoft Entra-lejeren, til det mest egnede Azure-geografi, hvor der findes en Power BI-udrulning. Når denne bestemmelse er truffet, gemmes alle Power BI-kundedata i dette valgte Azure-geografiske område (også kendt som det lokale geo), undtagen i de tilfælde, hvor organisationer anvender multi-geo-udrulninger.

Flere geografiske områder (multi-geo)

Nogle organisationer har en global tilstedeværelse og kan kræve Power BI-tjeneste i flere Azure-geografiske områder. En virksomhed kan f.eks. have sit hovedkvarter i USA, men også gøre forretninger i andre geografiske områder, f.eks. Australien. I sådanne tilfælde kan virksomheden kræve, at visse Power BI-data forbliver gemt som inaktive i fjernområdet for at overholde lokale bestemmelser. Denne funktion i Power BI-tjeneste kaldes multi-geo.

Det forespørgselsudførelseslag, forespørgselscacher og artefaktdata, der er tildelt til et multi-geo-arbejdsområde, hostes og forbliver i Azure-fjernkapacitetens geografiske område. Nogle metadata for artefakter, f.eks. rapportstrukturen, kan dog forblive gemt inaktivt i lejerens lokale geo. Derudover kan nogle datatransit og behandling stadig ske i lejerens lokale geo, selv for arbejdsområder, der hostes i en Multi-Geo Premium-kapacitet.

Se Konfigurer Multi-Geo-understøttelse af Power BI Premium for at få flere oplysninger om oprettelse og administration af Power BI-udrulninger, der strækker sig over flere Azure-geografiske områder.

Områder og datacentre

Power BI-tjeneste s er tilgængelige i bestemte Azure-geografiske områder, som beskrevet i Microsoft Center for sikkerhed og rettighedsadministration. Du kan finde flere oplysninger om, hvor dine data gemmes, og hvordan de bruges, i Microsoft Center for sikkerhed og rettighedsadministration. Forpligtelser i forbindelse med placeringen inaktive kundedata er angivet under Vilkår for databehandling i Servicevilkår for Microsofts onlinetjenester.

Microsoft leverer også datacentre til nationale enheder. Du kan få flere oplysninger om Power BI-tjeneste tilgængelighed for nationale/regionale cloudmiljøer i Nationale/regionale Clouds i Power BI.

Datahåndtering

I dette afsnit beskrives praksis for håndtering af Power BI-data, når det gælder lagring, behandling og overførsel af kundedata.

Inaktive data

Power BI bruger to primære datalagerressourcetyper:

• Azure Storage
• Azure SQL Databases

I de fleste scenarier bruges Azure Storage til at bevare dataene for Power BI-artefakter, mens Azure SQL Databases bruges til at bevare metadata for artefakter.

Alle data, der bevares af Power BI, krypteres som standard ved hjælp af Microsoft-administrerede nøgler. Kundedata, der er gemt i Azure SQL Databases, krypteres fuldt ud ved hjælp af Azure SQL's TDE-teknologi (Transparent Data Encryption). Kundedata, der er gemt i Azure Blob Storage, krypteres ved hjælp af Azure Storage Encryption.

Organisationer kan eventuelt bruge Power BI Premium til at bruge deres egne nøgler til at kryptere inaktive data, der importeres til en semantisk model. Denne fremgangsmåde beskrives ofte som byok (bring your own key). Brug af BYOK hjælper med at sikre, at kundedata ikke eksponeres , selv i tilfælde af en tjenesteoperatørfejl – noget, der ikke nemt kan opnås ved hjælp af gennemsigtig kryptering på tjenestesiden. Se Medbring dine egne krypteringsnøgler til Power BI for at få flere oplysninger.

Semantiske Power BI-modeller giver mulighed for forskellige datakildeforbindelsestilstande, der bestemmer, om datakildedataene bevares i tjenesten eller ej.

Semantisk modeltilstand (type)	Data bevares i Power BI
Importér	Ja
DirectQuery	Nr.
Live Forbind	Nr.
Sammensat	Hvis indeholder en importdatakilde
Streaming	Hvis konfigureret til at fortsætte

Uanset hvilken semantisk modeltilstand der er anvendt, kan Power BI midlertidigt cachelagre alle hentede data for at optimere ydeevnen for indlæsning af forespørgsler og rapporter.

Data under behandling

Data behandles, når de enten aktivt bruges af en eller flere brugere som en del af et interaktivt scenarie, eller når en baggrundsproces, f.eks. opdatering, berører disse data. Power BI indlæser aktivt behandlede data i hukommelsesområdet for en eller flere arbejdsbelastninger i tjenesten. For at lette den funktionalitet, der kræves af arbejdsbelastningen, krypteres de behandlede data i hukommelsen ikke.

Data i transit

Power BI kræver, at al indgående HTTP-trafik krypteres ved hjælp af TLS 1.2 eller nyere. Anmodninger, der forsøger at bruge tjenesten med TLS 1.1 eller lavere, afvises.

Godkendelse til datakilder

Når der oprettes forbindelse til en datakilde, kan en bruger vælge at importere en kopi af dataene til Power BI eller oprette direkte forbindelse til datakilden.

I tilfælde af import opretter en bruger en forbindelse baseret på brugerens logon og får adgang til dataene med legitimationsoplysningerne. Når den semantiske model er publiceret til Power BI-tjeneste, bruger Power BI altid denne brugers legitimationsoplysninger til at importere data. Når data er importeret, har visning af dataene i rapporter og dashboards ikke adgang til den underliggende datakilde. Power BI understøtter enkeltlogongodkendelse for valgte datakilder. Hvis forbindelsen er konfigureret til at bruge enkeltlogon, bruges legitimationsoplysningerne for den semantiske modelejer til at oprette forbindelse til datakilden.

Hvis en datakilde er forbundet direkte ved hjælp af forudkonfigurerede legitimationsoplysninger, bruges de forudkonfigurerede legitimationsoplysninger til at oprette forbindelse til datakilden, når en bruger får vist dataene. Hvis en datakilde er forbundet direkte ved hjælp af enkeltlogon, bruges den aktuelle brugers legitimationsoplysninger til at oprette forbindelse til datakilden, når en bruger får vist dataene. Når det bruges med enkeltlogon, kan sikkerhed på rækkeniveau og/eller sikkerhed på objektniveau implementeres på datakilden. Dette giver brugerne mulighed for kun at få vist data, de har rettigheder til at få adgang til. Når forbindelsen er til datakilder i cloudmiljøet, bruges Microsoft Entra-godkendelse til enkeltlogon. For datakilder i det lokale miljø understøttes Kerberos, SAML (Security Assertion Markup Language) og Microsoft Entra ID.

Hvis datakilden er Azure Analysis Services eller Analysis Services i det lokale miljø, og sikkerhed på rækkeniveau og/eller OLS er konfigureret, anvender Power BI-tjeneste denne sikkerhed på rækkeniveau, og brugere, der ikke har tilstrækkelige legitimationsoplysninger til at få adgang til de underliggende data (hvilket kan være en forespørgsel, der bruges i et dashboard, en rapport eller en anden dataartefakt), kan ikke se data, de ikke har tilstrækkelige rettigheder til.

Premium-funktioner

Dataflowarkitektur

Dataflow giver brugerne mulighed for at konfigurere back end-databehandlingshandlinger, der udtrækker data fra polymorf datakilder, udfører transformationslogik i forhold til dataene og derefter lander dem i en målmodel til brug på tværs af forskellige præsentationsteknologier til rapportering. Alle brugere, der har enten en rolle som medlem, bidragyder eller administrator i et arbejdsområde, kan oprette et dataflow. Brugere med fremviserrollen kan få vist data, der behandles af dataflowet, men kan ikke foretage ændringer i dets sammensætning. Når et dataflow er oprettet, kan alle medlemmer, bidragydere eller administratorer af arbejdsområdet planlægge opdateringer samt få vist og redigere dataflowet ved at overtage ejerskabet af det.

Hver konfigureret datakilde er bundet til en klientteknologi for at få adgang til den pågældende datakilde. Strukturen af de legitimationsoplysninger, der kræves for at få adgang til dem, er udformet, så de stemmer overens med de påkrævede implementeringsoplysninger for datakilden. Transformationslogik anvendes af Power Query-tjenester, mens dataene er på flugt. I forbindelse med Premium-dataflow udføres Power Query-tjenester i back end-noder. Data kan hentes direkte fra cloudkilderne eller via en gateway, der er installeret i det lokale miljø. Når transporten trækkes direkte fra en cloudkilde til tjenesten eller gatewayen, bruger den beskyttelsesmetode, der er specifik for klientteknologien, hvis det er relevant. Når data overføres fra gatewayen til cloudtjenesten, krypteres de. Se afsnittet Data i transit ovenfor.

Når kundede angivne datakilder kræver legitimationsoplysninger for at få adgang, giver ejeren/forfatteren af dataflowet dem under oprettelse. De gemmes ved hjælp af standardlager med legitimationsoplysninger for hele produktet. Se afsnittet Godkendelse til datakilder ovenfor. Der er forskellige metoder, som brugerne kan konfigurere for at optimere dataholdenhed og -adgang. Dataene placeres som standard i en Power BI-ejet og beskyttet lagerkonto. Lagerkryptering er aktiveret på Blob Storage-objektbeholderne for at beskytte dataene, mens de er inaktive. Se afsnittet Data i rest nedenfor. Brugerne kan dog konfigurere deres egen lagerkonto, der er knyttet til deres eget Azure-abonnement. Når du gør det, får en Power BI-tjeneste principal adgang til den pågældende lagerkonto, så den kan skrive dataene der under opdateringen. I dette tilfælde er ejeren af lagerressourcen ansvarlig for at konfigurere kryptering på den konfigurerede ADLS-lagerkonto. Data overføres altid til Blob Storage ved hjælp af kryptering.

Da ydeevnen ved adgang til lagerkonti kan være underordnet for nogle data, har brugerne også mulighed for at bruge et Power BI-hostet beregningsprogram til at øge ydeevnen. I dette tilfælde gemmes data redundant i en SQL-database, der er tilgængelig til DirectQuery via adgang fra back end Power BI-systemet. Data krypteres altid på filsystemet. Hvis brugeren angiver en nøgle til kryptering af de data, der er gemt i SQL-databasen, bruges denne nøgle dobbelt så meget til at kryptere den.

Når du forespørger ved hjælp af DirectQuery, bruges den krypterede transportprotokol HTTPS til at få adgang til API'en. Al sekundær eller indirekte brug af DirectQuery styres af de samme adgangskontroller, der tidligere er beskrevet. Da dataflow altid er bundet til et arbejdsområde, er adgangen til dataene altid afgrænset af brugerens rolle i det pågældende arbejdsområde. En bruger skal som minimum have læseadgang for at kunne forespørge dataene på en hvilken som helst måde.

Når Power BI Desktop bruges til at få adgang til data i et dataflow, skal det først godkende brugeren ved hjælp af Microsoft Entra-id for at afgøre, om brugeren har tilstrækkelige rettigheder til at få vist dataene. Hvis det er tilfældet, anskaffes en SaS-nøgle og bruges til at få adgang til lagerplads direkte ved hjælp af den krypterede transportprotokol HTTPS.

Behandlingen af data i hele pipelinen udsender Office 365-overvågningshændelser. Nogle af disse hændelser registrerer handlinger, der er relateret til sikkerhed og beskyttelse af personlige oplysninger.

Sideinddelte rapporter

Sideinddelte rapporter er designet til at blive udskrevet eller delt. De kaldes sideinddelte, fordi de er formateret til at passe godt på en side. De viser alle dataene i en tabel, selvom tabellen strækker sig over flere sider. Du kan styre deres rapportsidelayout præcist.

Sideinddelte rapporter understøtter avancerede og effektive udtryk, der er skrevet i Microsoft Visual Basic .NET. Udtryk bruges i vid udstrækning i sideinddelte rapporter i Power BI Report Builder til at hente, beregne, vise, gruppere, sortere, filtrere, parameterisere og formatere data.

Udtryk oprettes af forfatteren af rapporten med adgang til den brede vifte af funktioner i .NET framework. Behandling og udførelse af sideinddelte rapporter udføres i en sandkasse.

Definitioner af sideinddelte rapporter (.rdl) gemmes i Power BI, og for at publicere og/eller gengive en sideinddelt rapport skal en bruger godkende og godkende på samme måde som beskrevet i afsnittet Godkendelse til Power BI-tjenesten ovenfor.

Det Microsoft Entra-token, der opnås under godkendelsen, bruges til at kommunikere direkte fra browseren til Power BI Premium-klyngen.

I Power BI Premium giver den Power BI-tjeneste kørsel et korrekt isoleret udførelsesmiljø for hver rapportgengivelse. Dette omfatter tilfælde, hvor de rapporter, der gengives, tilhører arbejdsområder, der er tildelt den samme kapacitet.

En sideinddelt rapport kan få adgang til en lang række datakilder som en del af gengivelsen af rapporten. Sandkassen kommunikerer ikke direkte med nogen af datakilderne, men kommunikerer i stedet med den proces, der er tillid til, for at anmode om data, og derefter føjer den proces, der er tillid til, de påkrævede legitimationsoplysninger til forbindelsen. På denne måde har sandkassen aldrig adgang til nogen legitimationsoplysninger eller hemmelighed.

For at understøtte funktioner som bingkort eller opkald til Azure Functions har sandkassen adgang til internettet.

Integreret Power BI-analyse

Uafhængige softwareleverandører (ISV'er) og løsningsudbydere har to primære tilstande til integrering af Power BI-artefakter i deres webprogrammer og portaler: Integrer for din organisation og integrer for dine kunder. Artefaktet er integreret i en IFrame i programmet eller portalen. En IFrame har ikke tilladelse til at læse eller skrive data fra det eksterne webprogram eller den eksterne portal, og kommunikationen med IFrame sker ved hjælp af Power BI Client SDK ved hjælp af POST-meddelelser.

I et scenarie med integrering for din organisation får Microsoft Entra-brugere adgang til deres eget Power BI-indhold via portaler, der er tilpasset af deres virksomheder og IT'er. Alle Power BI-politikker og -funktioner, der er beskrevet i dette dokument, f.eks. sikkerhed på rækkeniveau og sikkerhed på objektniveau, anvendes automatisk på alle brugere uafhængigt af, om de får adgang til Power BI via Power BI-portalen eller via brugerdefinerede portaler.

I et scenarie med integrering for dine kunder ejer ISV'er typisk Power BI-lejere og Power BI-elementer (dashboards, rapporter, semantiske modeller m.m.). Det er en ISV-back end-tjenestes ansvar at godkende slutbrugerne og beslutte, hvilke artefakter og hvilket adgangsniveau der er relevant for den pågældende slutbruger. ISV-politikbeslutninger krypteres i et integreringstoken , der genereres af Power BI, og overføres til ISV-backend for yderligere distribution til slutbrugerne i henhold til ISV'ens forretningslogik. Slutbrugere, der bruger en browser eller andre klientprogrammer, kan ikke dekryptere eller ændre integreringstokens. Sdk'er på klientsiden, f.eks . Power BI-klient-API'er , føjer automatisk det krypterede integreringstoken til Power BI-anmodninger som en godkendelse: EmbedToken-header . Baseret på denne header gennemtvinger Power BI alle politikker (f.eks. adgang eller sikkerhed på rækkeniveau), præcis som det blev angivet af ISV'en under generering.

Hvis du vil aktivere integrering og automatisering og generere de integreringstokens, der er beskrevet ovenfor, viser Power BI et omfattende sæt REST API'er. Disse Power BI REST API'er understøtter både brugerdelegeret og tjenesteprincipalen Microsoft Entra-metoder til godkendelse og godkendelse.

En integreret Power BI-analyse og dens REST API'er understøtter alle funktioner til netværksisolering i Power BI, der er beskrevet i denne artikel: f.eks. tjenestekoder og private links.

AI-funktioner

Power BI understøtter i øjeblikket to brede kategorier af AI-funktioner i produktet i dag: AI-visualiseringer og AI-berigelser. AI-funktionerne på visualiseringsniveau omfatter funktioner som Nøglefaktorer, Opdelingstræ, Smart-Narrative, Registrering af uregelmæssigheder, R-visual, Python-visual, Klyngedannelse, Prognoser, Q&A, Hurtig indsigt osv. Ai-berigelsesfunktionerne omfatter funktioner som f.eks. AutoML, Azure Machine Learning, CognitiveServices, R/Python-transformationer osv.

De fleste af de ovennævnte funktioner understøttes i både Delte og Premium-arbejdsområder i dag. AutoML og CognitiveServices understøttes dog kun i Premium-arbejdsområder på grund af IP-begrænsninger. I dag kan en bruger med AutoML-integration i Power BI bygge og oplære en brugerdefineret ML-model (f.eks. Forudsigelse, Klassificering, Regression osv.) og anvende den til at hente forudsigelser, mens der indlæses data i et dataflow, der er defineret i et Premium-arbejdsområde. Desuden kan Power BI-brugere anvende flere CognitiveServices-API'er, f.eks. TextAnalytics og ImageTagging, til at transformere data, før de indlæses i en dataflow/semantisk model, der er defineret i et Premium-arbejdsområde.

Premium AI-berigelsesfunktionerne kan bedst ses som en samling tilstandsløse AI-funktioner/-transformationer, der kan bruges af Power BI-brugere i deres dataintegrationspipelines, der bruges af en semantisk power BI-model eller dataflow. Bemærk, at disse funktioner også kan tilgås fra de aktuelle miljøer til oprettelse af dataflow/semantiske modeller i Power BI-tjenesten og Power BI Desktop. Disse AI-funktioner/transformeringer kører altid i et Premium-arbejdsområde/en Premium-kapacitet. Disse funktioner vises i Power BI som en datakilde, der kræver et Microsoft Entra-token til den Power BI-bruger, der bruger AI-funktionen. Disse AI-datakilder er specielle, fordi de ikke viser nogen af deres egne data, og de leverer kun disse funktioner/transformeringer. Under udførelsen foretager disse funktioner ikke nogen udgående opkald til andre tjenester for at sende kundens data. Lad os se på Premium-scenarierne individuelt for at forstå de kommunikationsmønstre og relevante sikkerhedsrelaterede oplysninger, der vedrører dem.

Til oplæring og anvendelse af en AutoML-model bruger Power BI Azure AutoML SDK og kører al oplæring i kundens Power BI-kapacitet. Under oplæring af gentagelser kalder Power BI en Azure Machine Learning-tjeneste for at vælge en passende model og hyperparametre til den aktuelle gentagelse. I dette udgående kald sendes der kun relevante eksperimentmetadata (f.eks. nøjagtighed, ml-algoritme, algoritmeparametre osv.) fra den forrige gentagelse. AutoML-oplæringen producerer en ONNX-model og oplæringsrapportdata, der derefter gemmes i dataflowet. Senere kan Power BI-brugere derefter anvende den oplærte ML-model som en transformering for at operationalisere ML-modellen på en planlagt basis. For TextAnalytics- og ImageTagging-API'er kalder Power BI ikke api'erne til CognitiveServices-tjenesten direkte, men bruger i stedet et internt SDK til at køre API'erne i Power BI Premium-kapaciteten. I dag understøttes disse API'er i både Power BI-dataflow og semantiske modeller. Når brugerne opretter en datamodel i Power BI Desktop, kan de kun få adgang til denne funktionalitet, hvis de har adgang til et Premium Power BI-arbejdsområde. Derfor bliver kunderne bedt om at angive deres Microsoft Entra-legitimationsoplysninger.

Netværksisolering

I dette afsnit beskrives avancerede sikkerhedsfunktioner i Power BI. Nogle af funktionerne har specifikke licenskrav. Se afsnittene nedenfor for at få flere oplysninger.

Servicemærker

En tjenestekode repræsenterer en gruppe IP-adressepræfikser fra en given Azure-tjeneste. Det hjælper med at minimere kompleksiteten af hyppige opdateringer af regler for netværkssikkerhed. Kunder kan bruge tjenestekoder til at definere kontrolelementer for netværksadgang i Netværkssikkerhedsgrupper eller Azure Firewall. Kunder kan bruge tjenestekoder i stedet for bestemte IP-adresser, når de opretter sikkerhedsregler. Ved at angive navnet på tjenestekoden (f.eks. PowerBI) i det relevante kilde- eller destinationsfelt (for API'er) i en regel kan kunderne tillade eller afvise trafikken for den tilsvarende tjeneste. Microsoft administrerer de adressepræfikser, der er omfattet af tjenestekoden, og opdaterer automatisk tjenestekoden, efterhånden som adresserne ændres.

Integration af private links

Azure-netværk leverer funktionen Azure Private Link, der gør det muligt for Power BI at give sikker adgang via private slutpunkter i Azure Networking. Med Azure Private Link og private slutpunkter sendes datatrafik privat ved hjælp af Microsofts backbone-netværksinfrastruktur, og derfor krydser dataene ikke internettet.

Private Link sikrer, at Power BI-brugere bruger Microsofts private netværks backbone, når de går til ressourcer i Power BI-tjeneste.

Brug af Privat link med Power BI giver følgende fordele:

• Private Link sikrer, at trafikken overføres via Azure-backbone til et privat slutpunkt for cloudbaserede Azure-ressourcer.
• Netværkstrafikisolation fra ikke-Azure-baseret infrastruktur, f.eks. adgang i det lokale miljø, kræver, at kunderne har ExpressRoute eller et VPN (Virtual Private Network) konfigureret.

Se Private links for at få adgang til Power BI for at få flere oplysninger.

VNet-forbindelse (prøveversion – kommer snart)

Selvom integrationsfunktionen Privat link leverer sikre indgående forbindelser til Power BI, muliggør VNet-forbindelsesfunktionen sikker udgående forbindelse fra Power BI til datakilder i et VNet.

VNet-gateways (Microsoft-administreret) eliminerer omkostningerne ved at installere og overvåge datagateways i det lokale miljø for at oprette forbindelse til datakilder, der er knyttet til et VNet. De vil dog stadig følge den velkendte proces med administration af sikkerhed og datakilder som med en datagateway i det lokale miljø.

Følgende er en oversigt over, hvad der sker, når du interagerer med en Power BI-rapport, der er forbundet til en datakilde i et VNet ved hjælp af VNet-gateways:

1. Power BI-cloudtjenesten (eller en af de andre understøttede cloudtjenester) starter en forespørgsel og sender forespørgslen, oplysninger om datakilden og legitimationsoplysninger til Power Platform VNet-tjenesten (PP VNet).

2. PP VNet-tjenesten indsætter derefter sikkert en objektbeholder, der kører en VNet-gateway, i undernettet. Denne objektbeholder kan nu oprette forbindelse til datatjenester, der er tilgængelige fra dette undernet.

3. PP VNet-tjenesten sender derefter forespørgslen, oplysninger om datakilden og legitimationsoplysninger til VNet-gatewayen.

4. VNet-gatewayen henter forespørgslen og opretter forbindelse til datakilderne med disse legitimationsoplysninger.

5. Forespørgslen sendes derefter til datakilden til udførelse.

6. Efter udførelsen sendes resultaterne til VNet-gatewayen, og PP VNet-tjenesten sender sikkert dataene fra objektbeholderen til Power BI-cloudtjenesten.

Denne funktion vil snart være tilgængelig i en offentlig prøveversion.

Tjenesteprincipaler

Power BI understøtter brugen af tjenesteprincipaler. Gem alle legitimationsoplysninger for tjenesteprincipaler, der bruges til at kryptere eller få adgang til Power BI i en Key Vault, tildel korrekte adgangspolitikker til vaulten, og gennemse regelmæssigt adgangstilladelser.

Se Automate Premium-arbejdsområde- og semantiske modelopgaver med tjenesteprincipaler for at få flere oplysninger.

Microsoft Purview til Power BI

Microsoft Purview Information Protection

Power BI er dybt integreret med Microsoft Purview Information Protection. Microsoft Purview Information Protection gør det muligt for organisationer at have en enkelt, integreret løsning til klassificering, mærkning, overvågning og overholdelse på tværs af Azure, Power BI og Office.

Når beskyttelse af oplysninger er aktiveret i Power BI:

• Følsomme data, både i Power BI-tjeneste og i Power BI Desktop, kan klassificeres og mærkes ved hjælp af de samme følsomhedsmærkater, der bruges i Office og Azure.
• Styringspolitikker kan gennemtvinges, når Power BI-indhold eksporteres til Excel-, PowerPoint-, PDF-, Word- eller .pbix-filer , for at sikre, at dataene er beskyttet, selv når de forlader Power BI.
• Det er nemt at klassificere og beskytte .pbix-filer i Power BI Desktop på samme måde som i Excel-, Word- og PowerPoint-programmer. Filer kan let mærkes i henhold til deres følsomhedsniveau. Desuden kan de krypteres, hvis de indeholder forretningsfortrolige data, så det sikres, at det kun er godkendte brugere, der kan redigere disse filer.
• Excel-projektmapper arver automatisk følsomhedsmærkater, når de opretter forbindelse til Power BI (prøveversion), hvilket gør det muligt at bevare klassificeringen fra ende til anden og anvende beskyttelse, når semantiske Power BI-modeller analyseres i Excel.
• Følsomhedsmærkater, der anvendes på Power BI-rapporter og -dashboards, er synlige i Power BI iOS- og Android-mobilapps.
• Følsomhedsmærkater bevares, når en Power BI-rapport er integreret i Teams, SharePoint eller et sikkert websted. Dette hjælper organisationer med at vedligeholde klassificering og beskyttelse ved eksport, når power BI-indhold integreres.
• Mærk nedarvning ved oprettelse af nyt indhold i Power BI-tjeneste sikrer, at mærkater, der anvendes på semantiske modeller eller datamarts i Power BI-tjeneste, anvendes på nyt indhold, der er oprettet oven på disse semantiske modeller og datamarts.
• Scannings-API'er til Power BI-administratorer kan udtrække følsomhedsmærkaten for et Power BI-element, så Power BI- og InfoSec-administratorer kan overvåge mærkater i Power BI-tjeneste og oprette chefrapporter.
• Api'er til Power BI-administratorer gør det muligt for centrale teams at anvende følsomhedsmærkater programmeringsmæssigt på indhold i Power BI-tjeneste.
• Centrale teams kan oprette obligatoriske mærkatpolitikker for at gennemtvinge anvendelse af mærkater på nyt eller redigeret indhold i Power BI.
• Centrale teams kan oprette standardmærkatpolitikker for at sikre, at der anvendes en følsomhedsmærkat på alt nyt eller ændret Power BI-indhold.
• Automatisk følsomhedsmærkatering i downstream i Power BI-tjeneste sikrer, at når en mærkat på en semantisk model eller datamart anvendes eller ændres, anvendes eller ændres mærkaten automatisk på alt downstreamindhold, der er forbundet med den semantiske model eller datamart.

Du kan få flere oplysninger under Følsomhedsmærkater i Power BI.

DLP-politikker (Microsoft Purview Forebyggelse af datatab) til Power BI (prøveversion)

Microsoft Purviews DLP-politikker kan hjælpe organisationer med at reducere risikoen for lækage af følsomme forretningsdata fra Power BI. DLP-politikker kan hjælpe dem med at overholde kravene til overholdelse af offentlige eller branchemæssige bestemmelser, f.eks. GDPR (EU's generelle forordning om databeskyttelse) eller CCPA (California Consumer Privacy Act) og sikre, at deres data i Power BI administreres.

Når DLP-politikker for Power BI konfigureres:

• Alle semantiske modeller i de arbejdsområder, der er angivet i politikken, evalueres af politikken.
• Du kan registrere, når følsomme data uploades til dine Premium-kapaciteter. DLP-politikker kan registrere:
  • Følsomhedsmærkater.
  • Følsomme oplysningstyper. Mere end 260 typer understøttes. Registrering af følsomme oplysninger er afhængig af Microsoft Purview-indholdsscanning.
• Når du støder på en semantisk model, der er identificeret som følsom, kan du se et tilpasset politiktip, der hjælper dig med at forstå, hvad du skal gøre.
• Hvis du ejer en semantisk model, kan du tilsidesætte en politik og forhindre, at din semantiske model identificeres som "følsom", hvis du har en gyldig grund til at gøre det.
• Hvis du ejer en semantisk model, kan du rapportere et problem med en politik, hvis du konkluderer, at en følsom oplysningstype er blevet identificeret forkert.
• Automatiske risikoreduktioner, f.eks. beskeder til sikkerhedsadministratoren, kan aktiveres.

Du kan få flere oplysninger under Politikker til forebyggelse af datatab for Power BI.

Microsoft Defender for Cloud Apps for Power BI

Microsoft Defender for Cloud Apps er en af verdens førende cloudadgangssikkerhedsmæglere, der er udnævnt som førende i Gartners Magic Quadrant for CASB-markedet (Cloud Access Security Broker). Defender for Cloud Apps bruges til at sikre brugen af cloudapps. Det gør det muligt for organisationer at overvåge og styre Power BI-sessioner i realtid, f.eks. brugeradgang fra ikke-administrerede enheder. Sikkerhedsadministratorer kan definere politikker til styring af brugerhandlinger, f.eks. download af rapporter med følsomme oplysninger.

Med Defender for Cloud Apps kan organisationer få følgende DLP-funktioner:

• Angiv kontrolelementer i realtid for at gennemtvinge risikobebyrdede brugersessioner i Power BI. Hvis en bruger f.eks. opretter forbindelse til Power BI uden for sit land eller område, kan sessionen overvåges af Defender for Cloud Apps-kontrolelementerne i realtid, og risikobetonede handlinger, f.eks. download af data, der er mærket med følsomhedsmærkaten "Meget fortroligt", kan blokeres med det samme.
• Undersøg Power BI-brugeraktivitet med aktivitetsloggen Defender for Cloud Apps. Aktivitetsloggen Defender for Cloud Apps indeholder Power BI-aktivitet, som registreres i Office 365-overvågningsloggen, som indeholder oplysninger om alle bruger- og administratoraktiviteter samt oplysninger om følsomhedsmærkat for relevante aktiviteter, f.eks. anvend, skift og fjern mærkat. Administration s kan udnytte avancerede filtre og hurtige handlinger i Defender for Cloud Apps til effektiv problemundersøgelse.
• Opret brugerdefinerede politikker for at advare om mistænkelig brugeraktivitet i Power BI. Aktivitetspolitikfunktionen Defender for Cloud Apps kan udnyttes til at definere dine egne brugerdefinerede regler for at hjælpe dig med at registrere brugeradfærd, der afviger fra normen, og endda muligvis reagere på den automatisk, hvis det virker for farligt.
• Arbejd med den indbyggede registrering af uregelmæssigheder i Defender for Cloud Apps. Defender for Cloud Apps-politikker for registrering af uregelmæssigheder leverer standardanalyser af brugeradfærd og maskinel indlæring, så du fra starten er klar til at køre avanceret trusselsregistrering på tværs af dit cloudmiljø. Når en politik for registrering af uregelmæssigheder identificerer en mistænkelig funktionsmåde, udløser den en sikkerhedsadvarsel.
• Power BI-administratorrolle i Defender for Cloud Apps-portalen. Defender for Cloud Apps indeholder en appspecifik administratorrolle, der kan bruges til kun at give Power BI-administratorer de tilladelser, de har brug for til at få adgang til Power BI-relevante data på portalen, f.eks. beskeder, brugere i fare, aktivitetslogge og andre Power BI-relaterede oplysninger.

Se Brug af Microsoft Defender til Cloud Apps-kontrolelementer i Power BI for at få flere oplysninger.

Vis sikkerhedsfunktioner

I dette afsnit vises de funktioner, der er planlagt til at blive udgivet i marts 2021. Da dette emne indeholder en liste over funktioner, der muligvis ikke er udgivet endnu, kan leveringstidslinjer blive ændret, og den forventede funktionalitet kan blive udgivet senere end marts 2021, eller de udgives muligvis slet ikke. Du kan få flere oplysninger om prøveversioner under Vilkår for onlinetjenester.

Bring Your Own Log Analytics (BYOLA)

Bring Your Own Log Analytics muliggør integration mellem Power BI og Azure Log Analytics. Denne integration omfatter Azure Log Analytics' avancerede analyseprogram, interaktivt forespørgselssprog og indbyggede konstruktioner til maskinel indlæring.

Spørgsmål og svar om sikkerhed i Power BI

Følgende spørgsmål er almindelige sikkerhedsspørgsmål og svar til Power BI. Disse er organiseret på baggrund af, hvornår de blev føjet til denne hvidbog, for at gøre det nemmere for dig hurtigt at finde nye spørgsmål og svar, når dette dokument opdateres. De nyeste spørgsmål føjes til slutningen af denne liste.

Hvordan opretter brugerne forbindelse til og får adgang til datakilder, mens de bruger Power BI?

• Power BI administrerer legitimationsoplysninger til datakilder for hver bruger for legitimationsoplysninger i skyen eller for forbindelse via en personlig gateway. Datakilder, der administreres af en datagateway i det lokale miljø, kan deles på tværs af virksomheden, og tilladelser til disse datakilder kan administreres af gatewayen Administration. Når du konfigurerer en semantisk model, har brugeren tilladelse til at vælge en legitimationsoplysninger fra deres personlige lager eller bruge en datagateway i det lokale miljø til at bruge en delt legitimationsoplysninger.

  I importcasen opretter en bruger en forbindelse baseret på brugerens logon og får adgang til dataene med legitimationsoplysningerne. Når den semantiske model er publiceret til Power BI-tjeneste, bruger Power BI altid denne brugers legitimationsoplysninger til at importere data. Når dataene er importeret, får du ikke adgang til den underliggende datakilde, når du får vist dataene i rapporter og dashboards. Power BI understøtter enkeltlogongodkendelse for valgte datakilder. Hvis forbindelsen er konfigureret til at bruge enkeltlogon, bruges den semantiske modelejers legitimationsoplysninger til at oprette forbindelse til datakilden.

  For rapporter, der er forbundet med DirectQuery, er datakilden forbundet direkte ved hjælp af forudkonfigurerede legitimationsoplysninger. De forudkonfigurerede legitimationsoplysninger bruges til at oprette forbindelse til datakilden, når en bruger får vist dataene. Hvis en datakilde er forbundet direkte ved hjælp af enkeltlogon, bruges den aktuelle brugers legitimationsoplysninger til at oprette forbindelse til datakilden, når brugeren får vist dataene. Når du bruger med enkeltlogon, kan sikkerhed på rækkeniveau og/eller sikkerhed på objektniveau implementeres på datakilden, og det giver brugerne mulighed for at få vist data, de har rettigheder til at få adgang til. Når forbindelsen er til datakilder i cloudmiljøet, bruges Microsoft Entra-godkendelse til enkeltlogon. for datakilder i det lokale miljø understøttes Kerberos, SAML og Microsoft Entra ID.

  Når der oprettes forbindelse til Kerberos, overføres brugerens UPN til gatewayen, og ved hjælp af begrænset Kerberos-delegering repræsenteres brugeren og har forbindelse til de respektive datakilder. SAML understøttes også på gatewayen til SAP HANA-datakilden. Du kan få flere oplysninger i en oversigt over enkeltlogon for gateways.

  Hvis datakilden er Azure Analysis Services eller Analysis Services i det lokale miljø og sikkerhed på rækkeniveau (RLS) og/eller sikkerhed på objektniveau (OLS) er konfigureret, anvender Power BI-tjeneste denne sikkerhed på rækkeniveau, og brugere, der ikke har tilstrækkelige legitimationsoplysninger til at få adgang til de underliggende data (hvilket kan være en forespørgsel, der bruges i et dashboard, en rapport eller andre dataartefakter), kan ikke se data, som brugeren ikke har tilstrækkelige rettigheder til.

  Sikkerhed på rækkeniveau med Power BI kan bruges til at begrænse adgang til data for bestemte brugere. Filtre begrænser dataadgangen på rækkeniveau, og du kan definere filtre i rollen.

  Sikkerhed på objektniveau (OLS) kan bruges til at sikre følsomme tabeller eller kolonner. I modsætning til sikkerhed på rækkeniveau sikrer sikkerhed på objektniveau dog også objektnavne og metadata. Dette hjælper med at forhindre ondsindede brugere i at opdage selv eksistensen af sådanne objekter. Sikre tabeller og kolonner skjules på feltlisten, når du bruger rapporteringsværktøjer som Excel eller Power BI, og desuden kan brugere uden tilladelser ikke få adgang til sikre metadataobjekter via DAX eller andre metoder. Set fra brugernes synspunkt uden de rette adgangstilladelser findes sikre tabeller og kolonner ganske enkelt ikke.

  Sikkerhed på objektniveau muliggør sammen med sikkerhed på rækkeniveau forbedret sikkerhed i virksomhedsklassen for rapporter og semantiske modeller, så det kun er brugere med de nødvendige tilladelser, der har adgang til at få vist og interagere med følsomme data.

Hvordan overføres data til Power BI?

• Alle data, der anmodes om og sendes af Power BI, krypteres under overførsel ved hjælp af HTTPS (undtagen når den datakilde, der er valgt af kunden, ikke understøtter HTTPS) for at oprette forbindelse fra datakilden til Power BI-tjeneste. Der oprettes en sikker forbindelse til dataprovideren, og først når denne forbindelse er oprettet, gennemgås netværket af data.

Hvordan cachelagrer Power BI rapport-, dashboard- eller modeldata, og er det sikkert?

• Når der åbnes en datakilde, følger Power BI-tjeneste den proces, der er beskrevet i afsnittet Godkendelse til datakilder tidligere i dette dokument.

Cachelagrer klienter websidedata lokalt?

• Når browserklienter får adgang til Power BI, angiver Power BI-webserverne direktivet Cache-Control til no-store. No-store-direktivet instruerer browsere i ikke at cachelagre den webside, brugeren får vist, og ikke at gemme websiden i klientens cachemappe.

Hvad med rollebaseret sikkerhed, deling af rapporter eller dashboards og dataforbindelser? Hvordan fungerer det med hensyn til dataadgang, visning af dashboards, rapportadgang eller opdatering?

• Hvis en dashboard-, rapport- eller datamodel deles med andre brugere via Power BI, er dataene tilgængelige for brugere, som de er delt med, for at få vist og interagere med datakilder, der ikke er RLS-aktiverede datakilder. Power BI godkender ikke brugerne igen i forhold til den oprindelige datakilde. Når data er uploadet til Power BI, er den bruger, der er godkendt i forhold til kildedataene, ansvarlig for at administrere, hvilke andre brugere og grupper der kan få vist dataene.

  Når der oprettes dataforbindelser til en datakilde, der understøtter sikkerhed på rækkeniveau, f.eks. en Analysis Services-datakilde, cachelagres kun dashboarddata i Power BI. Hver gang en rapport eller semantisk model vises eller tilgås i Power BI, der bruger data fra den datakilde, der understøtter sikkerhed på rækkeniveau, får Power BI-tjeneste adgang til datakilden for at hente data baseret på brugerens legitimationsoplysninger, og hvis der findes tilstrækkelige tilladelser, indlæses dataene i rapporten eller datamodellen for den pågældende bruger. Hvis godkendelsen mislykkes, får brugeren vist en fejl.

  Du kan få flere oplysninger i afsnittet Godkendelse til datakilder tidligere i dette dokument.

Vores brugere opretter hele tiden forbindelse til de samme datakilder, hvoraf nogle kræver legitimationsoplysninger, der adskiller sig fra deres legitimationsoplysninger til domænet. Hvordan undgår de at skulle angive disse legitimationsoplysninger, hver gang de opretter en dataforbindelse?

• Power BI tilbyder Power BI Personal Gateway, som er en funktion, der gør det muligt for brugerne at oprette legitimationsoplysninger for flere forskellige datakilder og derefter automatisk bruge disse legitimationsoplysninger, når de efterfølgende får adgang til hver af disse datakilder. Du kan få flere oplysninger under Power BI Personal Gateway.

Hvilke porte bruges af datagatewayen i det lokale miljø og den personlige gateway? Er der nogen domænenavne, der skal være tilladt til forbindelsesformål?

• Det detaljerede svar på dette spørgsmål er tilgængeligt på følgende link: Gatewayporte

Hvordan bruges genoprettelsesnøgler, og hvor gemmes de, når du arbejder med datagatewayen i det lokale miljø? Hvad med sikker administration af legitimationsoplysninger?

• Under installationen og konfigurationen af gatewayen skriver administratoren i en genoprettelsesnøgle til gatewayen. Denne genoprettelsesnøgle bruges til at generere en stærk AES-symmetrisk nøgle. Der oprettes også en asymmetrisk RSA-nøgle på samme tid.

  Disse genererede nøgler (RSA og AES) gemmes i en fil, der er placeret på den lokale computer. Filen er også krypteret. Indholdet af filen kan kun dekrypteres af den pågældende Windows-computer og kun af den pågældende gatewaytjenestekonto.

  Når en bruger angiver legitimationsoplysninger for datakilden i Power BI-tjeneste brugergrænseflade, krypteres legitimationsoplysningerne med den offentlige nøgle i browseren. Gatewayen dekrypterer legitimationsoplysningerne ved hjælp af den private RSA-nøgle og krypterer dem igen med en symmetrisk AES-nøgle, før dataene gemmes i Power BI-tjeneste. Med denne proces har Power BI-tjeneste aldrig adgang til de ukrypterede data.

Hvilke kommunikationsprotokoller bruges af datagatewayen i det lokale miljø, og hvordan sikres de?

• Gatewayen understøtter følgende to kommunikationsprotokoller:

  • AMQP 1.0 – TCP + TLS: Denne protokol kræver, at portene 443, 5671-5672 og 9350-9354 er åbne for udgående kommunikation. Denne protokol foretrækkes, da den har lavere kommunikationsomkostninger.

  • HTTPS – WebSockets via HTTPS + TLS: Denne protokol bruger kun port 443. WebSocket startes af en enkelt HTTP CONNECT-meddelelse. Når kanalen er etableret, er kommunikationen i bund og grund TCP+TLS. Du kan tvinge gatewayen til at bruge denne protokol ved at ændre en indstilling, der er beskrevet i artiklen gateway i det lokale miljø.

Hvilken rolle spiller Azure CDN i Power BI?

• Som tidligere nævnt bruger Power BI Azure Content Delivery Network (CDN) til effektivt at distribuere det nødvendige statiske indhold og de nødvendige statiske filer til brugere baseret på geografisk landestandard. For at gå mere i detaljer bruger Power BI-tjeneste flere CDN'er til effektivt at distribuere det nødvendige statiske indhold og de nødvendige statiske filer til brugerne via det offentlige internet. Disse statiske filer omfatter produktoverførsler (f.eks. Power BI Desktop, datagatewayen i det lokale miljø eller Power BI-apps fra forskellige uafhængige tjenesteudbydere), browserkonfigurationsfiler, der bruges til at starte og etablere efterfølgende forbindelser med Power BI-tjeneste samt den indledende sikre Power BI-logonside.

  Baseret på oplysninger, der angives under en indledende forbindelse til Power BI-tjeneste, kontakter en brugers browser det angivne Azure CDN (eller for nogle filer, WFE) for at downloade samlingen af angivne fælles filer, der er nødvendige for at aktivere browserens interaktion med Power BI-tjeneste. Browsersiden indeholder derefter Microsoft Entra-tokenet, sessionsoplysninger, placeringen af den tilknyttede back end-klynge og samlingen af filer, der er downloadet fra Azure CDN- og WFE-klyngen, i hele den Power BI-tjeneste browsersession.

For Power BI-visualiseringer udfører Microsoft så en vurdering af sikkerhed eller beskyttelse af personlige oplysninger for den brugerdefinerede visualkode, før elementer publicerer i galleriet?

• Nej. Det er kundens ansvar at gennemse og afgøre, om der skal være tillid til brugerdefineret visualkode. Al brugerdefineret visualkode styres i et sandkassemiljø, så eventuel afvigende kode i en brugerdefineret visualisering ikke påvirker resten af Power BI-tjeneste negativt.

Er der andre Power BI-visualiseringer, der sender oplysninger uden for kundenetværket?

• Ja. Bing-Kort- og ESRI-visualiseringer overfører data ud af Power BI-tjeneste for visualiseringer, der bruger disse tjenester.

I forbindelse med skabelonapps udfører Microsoft så en vurdering af sikkerhed eller beskyttelse af personlige oplysninger for skabelonappen, før elementer publicerer i galleriet?

• Nej. Appudgiveren er ansvarlig for indholdet, mens det er kundens ansvar at gennemse og afgøre, om der skal være tillid til udgiveren af skabelonappen.

Er der skabelonapps, der kan sende oplysninger uden for kundenetværket?

• Ja. Det er kundens ansvar at gennemse udgiverens politik om beskyttelse af personlige oplysninger og afgøre, om skabelonappen skal installeres på lejeren. Udgiveren er ansvarlig for at informere kunden om appens funktionsmåde og egenskaber.

Hvad med datasuverænitet? Kan vi klargøre lejere i datacentre, der er placeret i bestemte geografiske områder, for at sikre, at data ikke forlader lande- eller områdegrænserne?

• Nogle kunder i visse geografiske områder har mulighed for at oprette en lejer i en national/regional cloud, hvor datalagring og -behandling holdes adskilt fra alle andre datacentre. Nationale/regionale cloudmiljøer har en lidt anden type sikkerhed, da en separat datatillidsmand driver den nationale/regionale cloud Power BI-tjeneste på vegne af Microsoft.

  Alternativt kan kunder også konfigurere en lejer i et bestemt område. Sådanne lejere har dog ikke en separat dataadministrator fra Microsoft. Priserne for nationale/regionale cloudmiljøer adskiller sig fra de offentligt tilgængelige kommercielle Power BI-tjeneste. Du kan få flere oplysninger om Power BI-tjeneste tilgængelighed for nationale/regionale cloudmiljøer i Nationale/regionale Clouds i Power BI.

Hvordan behandler Microsoft forbindelser for kunder, der har Power BI Premium-abonnementer? Er disse forbindelser anderledes end dem, der er etableret for ikke-Premium-Power BI-tjeneste?

• De forbindelser, der er oprettet for kunder med Power BI Premium-abonnementer, implementerer en Microsoft Entra business-to-business-godkendelsesproces (B2B) ved hjælp af Microsoft Entra ID til at aktivere adgangskontrol og autorisation. Power BI håndterer forbindelser fra Power BI Premium-abonnenter til Power BI Premium-ressourcer på samme måde som enhver anden Microsoft Entra-bruger.

Hvordan fungerer serverbaseret godkendelse i WFE?

• Godkendelse på tjenestesiden for brugergodkendelse sker som beskrevet i følgende trin, som illustreres på det billede, der følger efter dem.

1. En bruger starter en forbindelse til Power BI-tjeneste fra en browser, enten ved at skrive Power BI-adressen på adresselinjen eller ved at vælge Log på på på Power BI-marketingsiden (https://powerbi.microsoft.com). Forbindelsen oprettes ved hjælp af TLS 1.2 og HTTPS, og al efterfølgende kommunikation mellem browseren og Power BI-tjeneste bruger HTTPS.

2. Azure Traffic Manager kontrollerer brugerens DNS-post for at bestemme det mest relevante (normalt nærmeste) datacenter, hvor Power BI er installeret, og reagerer på DNS med IP-adressen på den WFE-klynge, som brugeren skal sendes til.

3. WFE omdirigerer derefter brugeren til logonsiden til Microsoft Online Services.

4. Når brugeren er blevet godkendt, omdirigerer logonsiden brugeren til den tidligere bestemte nærmeste Power BI-tjeneste WFE-klynge med en godkendelseskode.

5. WFE-klyngen kontrollerer med Microsoft Entra ID for at få et Microsoft Entra-sikkerhedstoken ved hjælp af godkendelseskoden. Når Microsoft Entra ID returnerer den vellykkede godkendelse af brugeren og returnerer et Microsoft Entra-sikkerhedstoken, konsulterer WFE-klyngen Den globale Power BI-tjeneste, som vedligeholder en liste over lejere og deres Placeringer for Power BI-backend-klynger og bestemmer, hvilken Power BI-back end-tjenesteklynge der indeholder brugerens lejer. WFE-klyngen returnerer derefter en programside til brugerens browser med de oplysninger om session, adgang og distribution, der kræves til handlingen.

6. Når klientens browser nu kræver kundedata, sender den anmodninger til back end-klyngeadressen med Microsoft Entra-adgangstokenet i autorisationsheaderen. Power BI-back end-klyngen læser Microsoft Entra-adgangstokenet og validerer signaturen for at sikre, at identiteten for anmodningen er gyldig. Microsoft Entra-adgangstokenet har en udløbsdato, der er angivet i henhold til Microsoft Entra-politikker, og for at bevare den aktuelle session foretager Power BI-klienten i brugerens browser periodiske anmodninger om at forny adgangstokenet, før det udløber.

Flere ressourcer

Du kan få flere oplysninger om Power BI i følgende ressourcer.

• Introduktion til Power BI Desktop
• Rest API til Power BI – oversigt
• Power BI-API reference
• Datagateway i det lokale miljø
• Nationale/regionale Power BI-cloudmiljøer
• Power BI Premium
• Oversigt over enkeltlogon (SSO) for gateways i Power BI