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 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.

Indførelsen

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 – selvom det stadig er vigtigt, er helt klart ikke længere tilstrækkeligt til at levere den type sikkerhed, der kræves 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 tilsvarende antal passive udrulninger, der fungerer som sikkerhedskopier for hver aktiv installation.

Webfrontendklynge (WFE)

Webfrontendklyngeklyngen (WFE) giver brugerens browser det indledende HTML-sideindhold ved indlæsning af webstedet og peger på CDN-indhold (Azure Content Delivery Network), 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-tjenesten, kommunikerer klientens DNS-tjeneste muligvis 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 som *.js, *.css og billedfiler gemmes hovedsageligt på et Azure CDN 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.

Backendklynge i Power BI

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 WFE- og API-klienter, samt arbejdstjenester i baggrunden, databaser, cacher 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 Global Service og bruges af WFE 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, som beskrevet 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 . Enhver godkendelse udføres udelukkende via integration med Microsoft Entra ID.

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	Androide	Windows
Power BI (log på tjenesten)	Understøttet	Understøttet	Understøttes ikke
SSRS ADFS i det lokale miljø (opret forbindelse til SSRS-server)	Understøttes ikke	Understøttet	Understøttes ikke
SSRS-app-proxy	Understøttet	Understøttet	Understøttes ikke

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.
• 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-tjenester 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-tjenester i flere Azure-geografiske områder. En virksomhed kan f.eks. have sit hovedkvarter i USA, men den kan 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 regler. 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. rapportstruktur, 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.

Du kan få flere oplysninger om oprettelse og administration af udrulninger, der strækker sig over flere Azure-geografiske områder, under Konfigurer Multi-Geo-understøttelse af Fabric.

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-databaser

I de fleste scenarier bruges Azure Storage til at bevare dataene for Power BI-artefakter, mens Azure SQL-databaser 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-databaser, krypteres fuldt ud ved hjælp af Azure SQL's gennemsigtige TDE-teknologi (Data Encryption ). Kundedata, der er gemt i Azure Blob Storage, krypteres ved hjælp af Azure Storage-kryptering.

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. Du kan få flere oplysninger under Medbring dine egne krypteringsnøgler til Power BI.

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	Nej
Live Connect	Nej
Sammensat	Hvis indeholder en importdatakilde
Streaming	Hvis konfigureret til at fortsætte

Uanset hvilken semantisk modeltilstand der bruges, 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 den 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-tjenesten dette niveau af sikkerhed, og brugere, der ikke har tilstrækkelige legitimationsoplysninger til at få adgang til de underliggende data (som kan være en forespørgsel, der bruges i et dashboard, en rapport eller andre dataartefakter), 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 enten har rollen Medlem, Bidragyder eller Administrator i et arbejdsområde, opretter muligvis et dataflow. Brugere med rollen Læser 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 under overførsel ovenfor.

Når kundespecifikke 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 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 Data i hvile 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 Azure Data Lake Storage-konto. Data overføres altid til Blob Storage ved hjælp af kryptering.

Da ydeevnen ved adgang til lagerkonti kan være underoptimering 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 Godkendelse til Power BI-tjenesten.

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 f.eks. Bing Maps 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 OLS, anvendes automatisk på alle brugere uafhængigt af, om de får adgang til Power BI via Power BI-portalen eller via tilpassede 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.

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, herunder 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 Narrativ, Registrering af uregelmæssigheder, R-visualisering, Python-visualisering, Klynger, 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 model til maskinel indlæring (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ærksisolation

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 på 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 en VPN konfigureret.

Se Private links for at få sikker adgang til Fabric for at få flere oplysninger.

VNet-forbindelse

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 følger dog stadig 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 legitimationsoplysningerne til Tjenesten Power Platform VNet (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.

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, 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

Microsoft Purviews DLP-politikker (Data Loss Prevention) hjælper organisationer med at reducere risikoen for lækage af følsomme forretningsdata fra Power BI. DLP-politikker hjælper dem med at overholde kravene til overholdelse af offentlige eller branchemæssige bestemmelser, f.eks. EU's generelle forordning om databeskyttelse (GDPR) 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 Fabric og 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. Administratorer kan bruge 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.

Du kan finde flere oplysninger under Brug af Microsoft Defender for Cloud Apps-kontrolelementer i Power BI.

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 gatewayadministratoren. 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 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 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 RLS og/eller OLS 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 RLS og/eller OLS er konfigureret, anvender Power BI-tjenesten sikkerhed på dette niveau, og brugere, der ikke har tilstrækkelige legitimationsoplysninger til at få adgang til de underliggende data (som kan være en forespørgsel, der bruges i et dashboard, en rapport eller en anden dataartefakt), 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 en rolle.

  OLS kan bruges til at sikre følsomme tabeller eller kolonner. I modsætning til sikkerhed på rækkeniveau sikrer OLS 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.

  OLS 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-tjenesten den proces, der er beskrevet i Godkendelse til datakilder.

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 et dashboard, en rapport eller en datamodel deles med andre brugere via Power BI for datakilder, der ikke er RLS-aktiverede , er dataene derefter tilgængelige for brugere, som de er delt med, og som de kan få vist og interagere med. 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 under Godkendelse af datakilder.

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 Brug en personlig gateway i Power BI.

Hvilke porte bruges af en datagateway i det lokale miljø og en personlig 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 i følgende artikel: Juster kommunikationsindstillinger for datagatewayen i det lokale miljø.

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 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-tjenesten flere CDN'er til effektivt at distribuere nødvendigt statisk indhold og filer til brugere 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 ISV'er), browserkonfigurationsfiler, der bruges til at starte og etablere efterfølgende forbindelser til Power BI-tjenesten 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 Maps- 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.

Yderligere ressourcer

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

• Introduktion til Power BI Desktop
• Power BI-API reference
• datagateway i det lokale miljø
• Nationale/regionale Power BI-cloudmiljøer
• Microsoft Fabric grundlæggende sikkerhedsprincipper
• Beskyttelse af personlige oplysninger, sikkerhed og ansvarlig brug af Copilot i Power BI