whitepaper om Power BI-sikkerhedsrapport

oversigt: Power BI er en tjeneste til online software service (SaaS eller software som en service) fra Microsoft, der gør det muligt for dig nemt og hurtigt at oprette dashboards, rapporter, datasæt og visualiseringer, der er selvbetjenings relaterede. Med Power BI kan du oprette forbindelse til mange forskellige datakilder, kombinere og forme data fra disse forbindelser og derefter oprette rapporter og dashboards, som kan deles med andre.

Skrivere: Yitzhak Kesselman, uafskallet Osborne, Matt Neely, Tony Bencic, Srinivasan Turuvekere, Cristian Petculescu, ADI Regev, Naveen Sivaraj, Benjamin Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, SID Jayadevan, Ronald Chang, ori Eduar, Anton Fritz, Idan Sheinberg, Ron Gilad, Sagiv Hadaya, Inbar Igor, Uzhviev Roth, Jaime Tarquino, Gennady Pats, Orion Yury, Berezansky Maya, Shenhav Romit Bogdan Crivat

Tekniske reviewere: 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

Introduktion

Power BI er en onlinesoftwaretjeneste (SaaS eller Software as a Service) fra Microsoft, der gør det nemt og hurtigt for dig at oprette dashboards, rapporter, datasæt og visualiseringer i forbindelse med selvbetjenings-business intelligence. Med Power BI kan du oprette forbindelse til mange forskellige datakilder, kombinere og forme data fra disse forbindelser og derefter oprette rapporter og dashboards, som kan deles med andre.

Verden ændrer sig hurtigt. organisationer gennemgår en accelereret digital transformation, og vi får vist en omfattende stigning i Fjern arbejdet, øget kundebehov for onlinetjenester og øget brug af avancerede teknologier i drift og forretningsmæssige beslutninger. Og det hele er baseret på clouden.

I takt med at overgangen til clouden er ændret fra et Trickle til et oversvømmelse, og med det nye, eksponerede overflade område, der følger med det, kan du bruge flere og flere virksomheder, hvor sikkerheden er mine data i clouden? og hvilken end-to-end-beskyttelse der er tilgængelig for at forhindre, at mine følsomme data er ved at blive utæt? Og på BI-platforme, der ofte håndterer nogle af de mest strategiske oplysninger i virksomheden, er disse spørgsmål lidt vigtige.

Det gamle funda mente BI-sikkerhedsmodel – sikkerhed på objektniveau og sikkerhed på rækkeniveau – mens den stadig er vigtig, er ikke længere tilstrækkelig til at kunne vise den type sikkerhed, der kræves i clouden. Organisationer skal i stedet søge efter en skybaseret sikkerhedsløsning med flere niveauer, som er baseret på flere niveauer, til deres business intelligence data.

Power BI blev bygget til at levere branchens førende komplette og hermetisk beskyttelse af data. Produktet har opnået de højeste sikkerheds klassifikationer, der er tilgængelige i branchen, og i dag mange nationale sikkerhedsmyndigheder, finansielle institutioner og sundhedspleje udbydere overdrager det de mest følsomme oplysninger.

Det alle starter med fundamentet. Efter en grov periode i de tidlige 2000 har Microsoft skabt store investeringer til at udbedre sikkerhedssvagheder, og i de følgende årtier bygger en meget stærk sikkerheds stak, som er lige så dyb som maskinens BIOS-kerne på chip. der er en udvidelse af hele vejen op til slutbruger oplevelser. Disse omfattende investeringer fortsætter, og i 3.500 dag er Microsoft-teknikere i gang med at bygge og forbedre Microsofts sikkerheds stakke og ved proaktivt at adressere den stadigt mere robuste trussel. Med milliarder af computere, lokale virksomheder og utallige zettabytes af oplysninger, der overdrages til Microsofts beskyttelse, er virksomheden nu den mest avancerede sikkerheds stak i den tekniske branche og vises bredt som global leder i kampen mod skadelige agenter.

Power BI bygger på dette meget stærke fundament. Den bruger samme sikkerheds stak, der optjente Azure til at håndtere og beskytte verdens mest følsomme data, og den integreres med de mest avancerede oplysninger om beskyttelse og overholdelse af Microsoft 365. Oven på disse leverer den sikkerhed ved hjælp af sikkerhedsforanstaltninger med flere lag, hvilket resulterer i end-to-end-beskyttelse, der er designet til at håndtere de unikke udfordringer, der er forbundet med cloudens ERA.

Hvis du vil levere en end-to-end-løsning til beskyttelse af følsomme aktiver, skal du bruge det produktteam, der er nødvendigt for at håndtere potentielle kunde bekymringer, på flere samtidige forkanter:

• Hvordan styrer vi, hvem der kan oprette forbindelse, hvor de opretter forbindelse fra, og hvordan de opretter forbindelse? Hvordan kan vi kontrollere forbindelserne?
• Hvordan gemmes dataene? Hvordan krypteres den? Hvilke kontrolelementer har jeg på mine data?
• Hvordan gør jeg du kontrollere og beskytte følsomme data? Hvordan gør jeg sikrer du, at disse data ikke kan være i et uden for organisationen?
• Vil du Hvordan gør jeg overvåge, hvem der foretager handlinger? Hvordan gør jeg reagere hurtigt, hvis der er mistænkelig aktivitet i tjenesten?

I denne artikel får du et omfattende svar på alle disse spørgsmål. Det starter med en oversigt over tjenestens arkitektur og forklarer, hvordan systemets hoved flows fungerer. derefter flyttes den til for at beskrive, hvordan brugerne kan godkende Power BI, hvordan dataforbindelser oprettes, og hvordan Power BI lagrer 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-tjenesten er underlagt servicebetingelserne for Microsoft Online og erklæringen om beskyttelse af personlige oplysninger for Microsoft Enterprise. Du kan finde placeringen af databehandling ved at referere til placeringen af databehandlings vilkårene i vilkår for Microsoft-online tjenester og til tillægget om databeskyttelse. Hvis du vil have flere oplysninger om overholdelse af angivne standarder, skal du gå til Microsoft Trust Center, som er den primære ressource for Power BI. Power BI-teamet arbejder hårdt på at give kunderne de nyeste innovationer og produktivitet. Få mere at vide om overholdelse af Microsofts overholdelses tilbud.

den Power BI tjeneste følger SDL (Security Development Lifecycle), strenge sikkerhedsmetoder, der understøtter krav om sikkerhed og overholdelse af standarder. SDL hjælper udviklere med at skabe mere sikker software ved at reducere antallet og alvorsgraden af sårbarheder i software, samtidig med at vi reducerer udviklingsomkostningerne. Få mere at vide på Microsofts praksis for Security Development Lifecycle.

Power BI arkitektur

tjenesten Power BI er bygget på Azure, som er microsofts skybaseret computerplatform. Power BI er i øjeblikket udrullet i mange datacentre overalt i verden. Der er mange aktive udrulninger tilgængelige for kunder i de områder, der betjenes af disse datacentre, og et lige antal så stort antal passive udrulninger, der fungerer som sikkerhedskopier for hver aktiv udrulning.

Web front-end-klynge (WFE)

WFE-klyngen giver brugerens browser med indholdet i den oprindelige HTML-side, når du indlæser webstedet, og administrerer den indledende forbindelse og godkendelsesprocessen for Power BI ved hjælp af Azure Active Directory (Azure AD) til at godkende klienter og angive tokens for efterfølgende klientforbindelser til den Power BI back-end-tjeneste.

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 tjenesten Power BI, kan klientens DNS-tjeneste kommunikere med Azure-Traffic Manager for at finde det mest relevante (normalt nærmeste) datacenter med en Power BI-installation. Du kan finde flere oplysninger om denne proces under routing Traffic-routingmetode til Azure Traffic Manager.

Den WFE-klynge, der er tildelt til brugeren, administrerer logon-og godkendelses sekvensen (beskrevet senere i denne artikel) og henter et Azure AD-adgangstoken, når godkendelsen er gennemført. ASP.NET-komponenten i WFE-klyngen analyserer tokenet for at afgøre, hvilken organisation brugeren tilhører, og derefter hører den Power BI globale tjeneste. Egenskaben WFE angiver den browser, hvor back-end-klynge huser organisationens lejer. når en bruger er godkendt, indtræffer efterfølgende kundeinteraktioner til kundedata med back-end-eller Premium klynge direkte, uden at WFE er en interaktions opgave for disse anmodninger.

statiske ressourcer som f. eks. *.js, *. css og billedfiler lagres hovedsageligt på Azure Content Delivery Network (CDN) og hentes direkte af browseren. bemærk, at de amerikanske myndigheders klynge udrulninger er en undtagelse til denne regel, og af hensyn til overensstemmelses årsager vil udelade CDN og i stedet bruge en WFE-klynge fra en kompatibel region til hosting af statisk indhold.

Power BI back-end cluster (være)

Back-end-klyngen er den grund sten, der findes i Power BI. Det består af flere tjeneste slutpunkter, der bruges af web frontend-og API-klienter samt Baggrundstjenester, databaser, cachelagre og forskellige andre komponenter.

Backend er tilgængelig i de fleste Azure-områder, og den 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 giver mulighed for ubegrænset vandret skalering af Power BI-tjenesten, når de lodrette og vandrette skalerings grænser for en enkelt klynge er opbrugt.

Hver back-end-klynge er i stand til at være vært for alle dataene for alle de lejere, der er tildelt til den pågældende klynge. En klynge, der indeholder dataene fra en bestemt lejer, kaldes lejerens hjemme klynge. En godkendt brugers oplysninger om hjemme klynger leveres af den globale tjeneste og bruges af webfrontend til at dirigere anmodninger til lejerens hjemme klynge.

hver back-end-klynge består af flere virtuelle maskiner, som er samlet i flere sæt, der kan tilpasses, og som er justeret til at udføre bestemte opgaver, ressourcer med høj sikkerhed, f. eks. SQL databaser, lagerkonti, tjeneste busser, cacher og andre nødvendige cloud-komponenter.

Lejerens metadata og data lagres i klynge grænser, undtagen til data replikering, til en sekundær back-end-klynge i et parret Azure-område i det samme Azure-geografiske område. Den sekundære back-end-klynge fungerer som en failover-klynge i tilfælde af regional afbrydelse og er passiv på ethvert andet tidspunkt.

Back-end-funktionaliteten betjenes af Micro Services, der kører på forskellige maskiner i klyngens virtuelle netværk, som ikke er tilgængeligt fra ydersiden, med undtagelse af to komponenter, der kan opnås adgang til fra det offentlige Internet:

• Gateway tjeneste
• Azure API Management

Power BI Premium infrastruktur

Power BI Premium tilbyder en tjeneste til abonnenter, der kræver Premium Power BI-funktioner, f. eks. Dataflows, sideinddelte rapporter, AI osv. når en kunde tilmelder sig et Power BI Premium abonnement, oprettes Premium kapacitet via Azure Resource Manager.

Power BI Premium kapaciteter hostes i back-end-klynger, der er uafhængige af den almindelige Power BI-back-end – se ovenfor). det giver en bedre isolering, ressourceallokering, support, sikkerheds isolation og skalerbarhed i det Premium tilbud.

følgende diagram illustrerer arkitekturen i Power BI Premium infrastruktur:

forbindelsen til Power BI Premium infrastruktur kan udføres på flere forskellige måder, afhængigt af brugerscenariet. Power BI Premium-klienter kan være en brugers browser, en regulær Power BI back-end, direkte forbindelser via XMLA-klienter, ARM-api'er osv.

den Power BI Premium infrastruktur i et Azure-område består af flere Power BI Premium klynger (minimum er en). størstedelen af de Premium ressourcer er indkapslet i en klynge (f. eks. en forekomst, beregning), og der er nogle almindelige regionale ressourcer (f. eks. metadatalager). Premium infrastructure giver mulighed for at opnå en horisontal skalerbarhed i et område: forøgelse af ressourcer i klynger og/eller tilføjelse af flere klynger efter behov efter behov (hvis klyngeressourcer nærmer sig deres grænser).

Backbonen for hver klynge er beregnings ressourcer, der administreres af Virtual Machine Scale Sets (VMSS) og Azure-service Fabric. VMSS og Service Fabric muliggør hurtig og problemfri forøgelse af beregnings noder, efterhånden som forbruget vokser og arrangerer udrulningen, administrationen og overvågningen af Power BI Premium tjenester og programmer.

Der er mange omgivende ressourcer, som sikrer en sikker og pålidelig infrastruktur: belastnings balancer, virtuelle netværk, netværks sikkerhedsgrupper, service bus, lager osv. alle hemmelige oplysninger, nøgler og certifikater, der kræves til Power BI Premium, administreres af Azure Key Vault eksklusivt. Enhver godkendelse foretages via integration med Azure AD eksklusivt.

alle anmodninger, der sendes til Power BI Premium-infrastruktur, går først til front-end-noder først – de er de eneste noder, der er tilgængelige for eksterne forbindelser. Resten af ressourcerne er skjulte bag Virtual Networks. Front-end-noderne godkender anmodningen, håndterer den eller videresender den til de relevante ressourcer (f. eks. back-end-noder).

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

Power BI Mobile

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

• Enhedskommunikation
• Appen og dataene på enheden

I forbindelse med enhedskommunikation kommunikerer alle Power BI – Mobil-programmer med Power BI-tjenesten og bruger de samme forbindelses- og godkendelsessekvenser, som bruges af browsere, hvilket er beskrevet i detaljer tidligere i dette whitepaper. Power BI-mobilapps til iOS og Android åbner en browsersession i selve appen, mens Windows-mobilappen åbner en mægler for at etablere kommunikationskanalen med Power BI (til logonprocessen).

I følgende tabel vises understøttelse af certifikatbaseret godkendelse for Power BI – Mobil, der er baseret på mobilenhedens platform:

Apps til Power BI – Mobil kommunikerer aktivt med Power BI-tjenesten. Telemetri bruges til at indsamle brugsstatistikker for mobilappen og lignende data, som sendes til tjenester, der bruges til at overvåge brug og aktivitet. der sendes ingen kundedata med telemetri.

I Power BI der gemmes data på enheden, der gør brug af appen:

• Azure AD og opdateringstokens gemmes i en sikker mekanisme på enheden ved hjælp af branchestandardens sikkerhedsforanstaltninger.
• Data og indstillinger (nøgleværdipar for brugerkonfiguration) cachelagres i lageret på enheden og 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 dette ved hjælp af BitLocker.
• For Android- og iOS-apps cachelagres dataene og indstillingerne (nøgleværdipar for brugerkonfiguration) i lageret på enheden i en sandkasse og et internt lager, som kun appen kan få adgang til. For Windows app er dataene kun tilgængelige for brugeren (og systemadministratoren).
• Geolocation er aktiveret eller deaktiveret eksplicit af brugeren. Hvis indstillingen er aktiveret, gemmes geoplaceringsdata ikke på enheden og 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, der er en softwaretjeneste, som leverer administration af mobilenheder og programmer. Alle tre platforme, som Power BI – Mobil adgang til, 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 Microsoft Intune.

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

For at kunne implementere SSO er nogle sikrede lagerværdier, der er relateret til den tokenbaserede godkendelse, tilgængelige for andre Microsoft 1st-partsapps (f.eks. Microsoft Authenticator) og administreres af ADAL-SDK'et (Azure Active Directory Authentication Library).

Power BI – Mobil cachelagrede data slettes, når appen fjernes, når brugeren logger af Power BI – Mobil, eller når brugeren ikke kan logge på (f.eks. efter en tokenudløbshændelse eller ændring af adgangskoden). Datacachen omfatter dashboards og rapporter, der tidligere blev tilgået fra appen Power BI – Mobil.

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

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

Godkendelse til Power BI tjenesten

Godkendelse af brugeren til Power BI-tjenesten består af en række anmodninger, svar og omdirigeringer mellem brugerens browser og Power BI-tjenesten eller de Azure-tjenester, som bruges af Power BI. I sekvensen beskrives processen for godkendelse af brugeren i Power BI, der følger efter Azure Active Directory godkendelseskodes tildelingsflow. Du kan finde flere oplysninger om mulighederne for en organisations modeller til godkendelse af brugeren (logonmodeller) under Sådan vælges en logonmodel til Microsoft 365.

Godkendelsessekvens

Sekvensen til godkendelse af brugeren Power BI tjenesten, som beskrevet i følgende trin, som er vist på det billede, der følger efter dem.

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

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

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

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

5. WFE-klyngen kontrollerer med Azure AD-tjenesten, om der skal indhentes et Azure AD-sikkerhedstoken ved hjælp af godkendelseskoden. Når Azure AD returnerer vellykket godkendelse af brugeren og returnerer et Azure AD-sikkerhedstoken, konsulterer WFE-klyngen global service Power BI, som bevarer en liste over lejere og deres placeringer for back end-klyngerne i deres Power BI og bestemmer, hvilke Power BI back end-tjenesteklynger der indeholder brugerens lejer. WFE-klyngen returnerer derefter en programside til brugerens browser med de sessions-, adgangs- og routingoplysninger, der kræves for handlingen.

6. Når klientens browser kræver kundedata, sender den nu anmodninger til back end-klyngeadressen med Azure AD-adgangstokenet i godkendelsesheaderen. Den Power BI back end-klyngen læser Azure AD-adgangstokenet og validerer signaturen for at sikre, at identiteten for anmodningen er gyldig. Azure AD-adgangstokenethar en standardlevetid på 1 time, og for at bevare den aktuelle session foretager brugerens browser periodiske anmodninger om at forny adgangstokenet, før det udløber.

Dataopbevaring

Medmindre andet er angivet i dokumentationen, Power BI kundedata i et geografisk Azure-område, der er tildelt, når en Azure AD-lejer tilmelder sig Power BI-tjenester for første gang. En Azure AD-lejer indeholder bruger- og programidentiteter, grupper og andre relevante oplysninger, der vedrører en organisation og dens sikkerhed.

Tildelingen af et geografisk Azure-område for lejerdatalageret udføres ved at knytte det land eller område, der er valgt som en del af Azure AD-lejerkonfigurationen, til det mest passende Azure-område, hvor der findes en Power BI udrulning. Når denne bestemmelse er truffet, gemmes alle Power BI-kundedata i det valgte Azure-område (også kendt som geografisk område for startsiden) undtagen i de tilfælde, hvor organisationer bruger 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 geografiske Azure-områder. En virksomhed kan f.eks. have sit hovedkontor i USA men kan også gøre forretninger i andre geografiske områder, f.eks. Australien. I sådanne tilfælde kan virksomheden kræve, at visse lagrede Power BI in rest-data i det eksterne område for at overholde lokale bestemmelser. Denne funktion i Power BI kaldes multi-geo.

Laget til udførelse af forespørgslen, forespørgselscachen og artefaktdata, der er tildelt til et multi-geo-arbejdsområde, hostes og forbliver i Azure-fjernkapaciteten. Nogle metadata for artefakter, f.eks. rapportstruktur, kan dog forblive gemt som in rest af lejerens geografiske placering på startsiden. Derudover kan nogle datatransitler og -behandling stadig forekomme i lejerens geografiske placering, også for arbejdsområder, der hostes i en multi-geo-Premium kapacitet.

Se Konfigurer multi-Geo-understøttelse for at få Power BI Premium oplysninger om, hvordan du opretter og administrerer Power BI udrulninger, der strækker sig over flere Azure-geografiske områder.

Områder og datacentre

Power BI er tilgængelige i bestemte Azure-geografiske områder, som beskrevet i Microsoft Sikkerhedscenter. Du kan finde flere oplysninger om, hvor dine data gemmes, og hvordan de bruges, i Microsoft Trust Center. Forpligtelser vedrørende placeringen af kundedata som in restdata er angivet under Vilkår for databehandling i Microsoft Vilkår for Onlinetjenester.

Microsoft leverer også datacentre til nationale enheder. Du kan finde flere oplysninger om tilgængeligheden af Power BI-tjenesten i nationale cloudmiljøer i Power BI i nationale cloudmiljøer.

Håndtering af data

I dette afsnit beskrives Power BI praksis for håndtering af data, hvad angår lagring, behandling og overførsel af kundedata.

Inaktive data

Power BI bruger to primære ressourcetyper for datalager:

• Azure Storage
• Azure SQL Databases

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

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

Organisationer kan eventuelt bruge gruppering til Power BI Premium deres egne nøgler til at kryptere restdata, der importeres til et datasæt. Denne fremgangsmåde beskrives ofte som BYOK (Bring Your Own Key – medbring din egen nøgle). Brug af BYOK hjælper med at sikre, at kundedata ikke eksponeres, selv i tilfælde af fejl i en serviceoperator – noget, der ikke nemt kan opnås ved hjælp af gennemsigtig kryptering på tjenestesiden. Du kan finde flere oplysninger under Brug dine Power BI krypteringsnøgler.

Power BI datasæt giver mulighed for en række forskellige forbindelsestilstande for datakilder, som afgør, om datakildedataene er permanente i tjenesten eller ej.

Uanset hvilken datasættilstand der bruges, kan Power BI cachelagre alle hentede data midlertidigt for at optimere ydeevnen for forespørgsels- og rapportindlæsning.

Data under behandling

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

Data under overførsel

Power BI kræver, at al indgående HTTP-trafik krypteres ved hjælp af TLS 1.2 eller højere. Alle anmodninger, der forsøger at bruge tjenesten sammen 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 på baggrund af brugerens logon og får adgang til dataene med legitimationsoplysningerne. Når datasættet er publiceret i Power BI-tjenesten, Power BI bruger altid denne brugers legitimationsoplysninger til at importere data. Når dataene er importeret, får du ikke adgang til den underliggende datakilde, når dataene vises i rapporter og på dashboards. Power BI understøtter godkendelse af enkelt logon for valgte datakilder. Hvis forbindelsen er konfigureret til at bruge enkelt logon, bruges legitimationsoplysningerne for ejeren af datasættet til at oprette forbindelse til datakilden.

Hvis en datakilde har oprettet forbindelse direkte ved hjælp af forudkonfigurerede legitimationsoplysninger, bruges de forudkonfigurerede legitimationsoplysninger til at oprette forbindelse til datakilden, når en hvilken som helst bruger får forhåndsvisning af dataene. Hvis en datakilde har forbindelse direkte ved hjælp af enkelt logon, bruges den aktuelle brugers legitimationsoplysninger til at oprette forbindelse til datakilden, når en bruger får visninger af dataene. Når den bruges med enkelt logon, kan sikkerhed på rækkeniveau (RLS) og/eller sikkerhed på objektniveau implementeres på datakilden. Dette gør det muligt for brugerne kun at få vist de data, de har rettigheder til at få adgang til. Når forbindelsen er til datakilder i cloudmiljøet, bruges Azure AD-godkendelse til enkelt logon. I forbindelse med datakilder i det stedet understøttes Kerberos, SAML (Security Assertion Markup Language) og Azure AD.

Hvis datakilden er Azure Analysis Services eller Analysis Services i det lokale miljø, og RLS og/eller OLS er konfigureret, anvender Power BI-tjenesten 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 et andet dataartefakt), kan ikke se de data, de ikke har tilstrækkelige rettigheder til.

Premium funktioner

Arkitektur for dataflow

Dataflow giver brugerne mulighed for at konfigurere back end-databehandlingshandlinger, der udtrækker data fra polymorfe datakilder, udfører transformationslogik i forhold til dataene og derefter lander i en destinationsmodel, der kan bruges på tværs af forskellige rapporteringspræsentationsteknologier. Alle brugere, der har rollen som medlem, bidragyder eller administrator i et arbejdsområde, kan oprette et dataflow. Brugere med rollen som seer kan få vist data, der er behandlet af dataflowet, men kan ikke foretage ændringer af dets komposition. Når et dataflow er blevet skrevet, kan et hvilket som helst medlem, bidragyder eller administrator 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 legitimationsoplysninger, der kræves for at få adgang til dem, er udformet, så de matcher de påkrævede implementeringsoplysninger om datakilden. Transformationslogik anvendes af Power Query tjenester, mens dataene er på et fly. I forbindelse med Premium-dataflow udfører Power Query services i back end-noder. Data kan trækkes direkte fra kilder i cloudmiljøet eller via en gateway, der er installeret i det lokale miljø. Når de trækkes direkte fra en kilde i cloudmiljøet til tjenesten eller til gatewayen, anvender transportmetoden 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 behandling ovenfor.

Når kundens angivne datakilder kræver legitimationsoplysninger for at få adgang, leverer ejeren/opretteren af dataflowet dem under oprettelse. De gemmes ved hjælp af standardlageret for legitimationsoplysninger til hele produktet. Se afsnittet Godkendelse til datakilder ovenfor. Der er forskellige metoder, som brugerne kan konfigurere for at optimere fastholdelse og adgang til data. Dataene er som standard placeret på en af Power BI og beskyttede lagerkonto. Storage kryptering er aktiveret på blob storage-objektbeholderne for at beskytte dataene, mens de er in rest. Se afsnittet Om restdata nedenfor. Brugerne kan dog konfigurere deres egen lagerkonto, der er knyttet til deres eget Azure-abonnement. Når du gør dette, Power BI en tjenestekonto have 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 sendes altid til Blob Storage ved hjælp af kryptering.

Da ydeevnen ved adgang til lagerkonti kan være underoptimal for nogle data, har brugerne også mulighed for at bruge et Power BI hostet beregningsprogram for 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 leverer en nøgle til kryptering af de data, der er gemt SQL i en SQL database, bruges denne nøgle til at kryptere dem.

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 adgangskontrolelementer, der tidligere er beskrevet. Da dataflows altid er bundet til et arbejdsområde, begrænses adgangen til dataene altid af brugerens rolle i dette arbejdsområde. En bruger skal som minimum have læseadgang til at kunne forespørge om dataene på en hvilken som helst måde.

Når Power BI Desktop til at få adgang til data i et dataflow, skal den først godkende brugeren ved hjælp af Azure AD for at afgøre, om brugeren har tilstrækkelige rettigheder til at få vist dataene. Hvis det er nødvendigt, anskaffes og bruges en SaS-nøgle til at få adgang til et lager direkte ved hjælp af HTTPS-protokollen til krypteret transport.

Behandlingen af data i hele pipelinen udsendes Office 365 overvågningshændelser. Nogle af disse hændelser henter handlinger, der vedrører sikkerhed og beskyttelse af personlige oplysninger.

Sideinddelte rapporter

Sideinddelte rapporter er designet til at skulle udskrives eller deles. De kaldes sideinddelte, fordi de er formateret til at passe godt på en side. De viser alle data i en tabel, selvom tabellen strækker sig over flere sider. De kaldes også perfekt pixel, fordi du kan styre layoutet af rapportsiderne helt præcist.

Sideindderede rapporter understøtter omfattende og effektive udtryk, der er skrevet i Microsoft Visual Basic .NET. Udtryk bruges i stor udstrækning overalt 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 sideindde sidende rapporter udføres i en sandkasse.

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

Det Azure AD-token, der hentes under godkendelsen, bruges til at kommunikere direkte fra browseren til Power BI Premium klyngen.

I Premium Gen1 findes der en enkelt sandkasse pr. hver af lejerens kapaciteter, og den deles af de arbejdsområder, der er tildelt til kapaciteten.

I Premium Gen2 oprettes der en individuel og eksklusiv ephemerlig sandkasse for hver gengivelse af en rapport, hvilket giver et højere niveau af isolation mellem brugerne.

En sideinddelt rapport kan få adgang til et bredt sæt 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 legitimationsoplysninger eller en hemmelighed.

Sandkassen har adgang til internettet for at understøtte funktioner som Bing kort eller opkald til Azure Functions forbindelse.

Power BI integreret analyse

Uafhængige softwareleverandører (ISV'er) og løsningsudbydere har to primære tilstande for integrering af Power BI-artefakter i deres webprogrammer og portaler: Integrer til din organisation og integrer til 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 Azure AD-brugere adgang til deres Power BI-indhold via portaler, der er tilpasset af deres virksomheder og IT'er. Alle Power BI-politikker og -egenskaber, der er beskrevet i denne rapport, f.eks. sikkerhed på rækkeniveau (RLS) og sikkerhed på objektniveau anvendes automatisk for alle brugere uafhængigt af, om de får adgang til Power BI via Power BI-portalen eller via tilpassede portaler.

I en scenarie, hvor ISV'er integrerer til dine kunder, ejer Power BI lejere og Power BI artefakter (dashboards, rapporter, datasæt osv.). Det er en ISV-back end-tjenestes ansvar at godkende dens slutbrugere 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-back end til yderligere distribution til slutbrugerne i henhold til ISV'ens forretningslogik. Slutbrugere, der bruger en browser eller andre klientprogrammer, kan ikke dekryptere eller ændre integreringstokens. KLIENT-ID'er, f.eks. Power BI. klient-API'er, tilføjer automatisk det krypterede integreringstoken for at Power BI anmodninger som en Godkendelse: EmbedToken-header. På baggrund af denne overskrift gennemtvinger Power BI alle politikker (f.eks adgang eller sikkerhed på sidefoden) præcist, som den blev angivet af ISV'en under generering.

Hvis du vil aktivere integrering og automatisering og generere de integreringstokens, der er beskrevet ovenfor, Power BI vise et omfattende sæt REST-API'er. Disse Power BI REST API'er understøtter både brugerdelegering og tjeneste principalmetoder til godkendelse og godkendelse i Azure AD.

Power BI integrerede analyser og dens REST API'er understøtter alle Power BI egenskaber for netværksisolation, der er beskrevet i denne artikel: f.eks. Tjenestetags 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-understøttelser. AI-funktionerne på visualiseringsniveau omfatter funktioner som f.eks. nøgle influencere, opdelingstræ, smart-narrative, anormal-registrering, R-visual, Python-visual, klyngedannelse, prognose, spørgsmål&A, Quick-Insights osv. Funktionaliteten til AI-funktionalitet omfatter funktioner som AutoML, AzureML, 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 de Premium arbejdsområder på grund af IP-begrænsninger. Med AutoML-integration i Power BI kan en bruger i dag oprette og oplære en brugerdefineret ML-model (f.eks. forudsigelse, klassificering, regression osv.) og anvende den til at få forudsigelser, mens der indlæses data i et dataflow, som er defineret i et Premium arbejdsområde. Desuden kan Power BI-brugere anvende flere CognitiveServices-API'er, f.eks. Tekstanalytics og Billedtagging, til at transformere data, før de indlæses i et dataflow/datasæt, der er defineret i et Premium arbejdsområde.

Funktionerne til AI-Premium kan bedst ses som en samling af stateless AI-funktioner/-transformationer, der kan bruges af Power BI-brugere i deres dataintegrationspipelines, som bruges af et Power BI datasæt eller et dataflow. Bemærk, at der også kan opnås adgang til disse funktioner fra de aktuelle miljøer til oprettelse af dataflow/datasæt i Power BI Service og Power BI Desktop. Disse AI-funktioner/-transformationer kører altid i Premium arbejdsområde/kapacitet. Disse funktioner vises som Power BI datakilde, der kræver et Azure AD-token til den Power BI bruger, der bruger funktionen AI. 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 ingen udgående kald til andre tjenester for at overføre kundens data. Lad os se på Premium individuelle scenarier for at forstå kommunikationsmønstre og relevante sikkerhedsrelaterede detaljer vedrørende dem.

Til oplæring og anvendelse af en AutoML-model Power BI du Azure AutoML SDK og kører al oplæring i kundens Power BI kapacitet. Under oplæringen kalder Power BI AzureML-tjenesten et eksperiment for at vælge en passende model og hyperparametre for den aktuelle gentagelse. I dette udgående kald er det kun relevante eksperimentmetadata (f.eks. nøjagtighed, ml-algoritme, algoritmeparametre osv.) fra den tidligere iteration, der sendes. AutoML-træningen producerer en ONNX-model og data om oplæringsrapport, som derefter gemmes i dataflowet. På et senere Power BI kan brugerne derefter anvende den oplærte ML-model som en transformering for at udnytte ML-modellen efter en tidsplan. I forbindelse med Tekstanalyse og Billedtagging-API'er kalder Power BI ikke direkte CognitiveServices-tjeneste-API'erne, 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 både Power BI dataflow og datasæt. Når et datasæt oprettes i Power BI Desktop, kan brugerne kun få adgang til denne funktionalitet, hvis de har adgang til Premium Power BI arbejdsområde. Derfor bliver kunderne bedt om at angive deres legitimationsoplysninger til Azure AD.

Netværksisolation

I dette afsnit beskrives avancerede sikkerhedsfunktioner i Power BI. Nogle af funktionerne har specifikke licenskrav. Du kan finde flere oplysninger i afsnittene nedenfor.

Tjenestetags

En tjenestekode repræsenterer en gruppe præfikser for IP-adresser fra en given Azure-tjeneste. Det hjælper med at minimere kompleksiteten af hyppige opdateringer af reglerne 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 specifikke IP-adresser, når de opretter sikkerhedsregler. Ved at angive tjenestekodenavnet (f.eks. PowerBI) i den relevante kilde eller destination (for API'er) i et regelfelt kan kunder 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.

Private Link integration

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

Private Link sikrer, Power BI brugerne anvender backbone i Microsofts private netværk, når de går til ressourcer i Power BI tjenesten.

Hvis Private Link med Power BI får du følgende fordele:

• Private Link sikrer, at trafikken går gennem Azures backbone-netværk til et privat slutpunkt for Azure-cloudbaserede ressourcer.
• Isolering af netværkstrafik fra ikke-Azure-baseret infrastruktur, f.eks. adgang i det lokale miljø, kræver, at kunderne har ExpressRoute eller et VPN (Virtuelt privat netværk) konfigureret.

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

VNet-forbindelse (prøveversion – kommer snart)

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

VNet-gateways (Microsoft-administreret) fjerner omkostninger i forbindelse med installation og overvågning af datagateways i det lokale miljø for at oprette forbindelse til datakilder, der er knyttet til en VNet. De følger dog stadig den velkendte proces med at administrere sikkerhed og datakilder, ligesom 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 en 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 undernet. 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 legitimationsoplysningerne 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 eksekvering.

6. Efter udførelsen sendes resultaterne til VNet-gatewayen, og PP VNet-tjenesten sender på sikker måde dataene fra objektbeholderen til Power BI cloudtjenesten.

Denne funktion bliver snart tilgængelig som offentlig prøveversion.

Tjenesteprincipaler

Power BI understøtter brugen af tjeneste principaler. Store legitimationsoplysninger til tjenestelederen, der bruges til at kryptere eller få adgang til Power BI i en Key Vault, tildele relevante adgangspolitikker til din Vault og jævnligt gennemse adgangstilladelser.

Du kan finde flere Premium få mere at vide under Automate Premium opgaver for arbejdsområder og datasæt med tjeneste principaler.

DLP (Forebyggelse af datatab)

Microsoft 365 over følsomhedsmærkater

Power BI har en omfattende integration med Microsoft Information Protection-følsomhedsmærkater (MIP), hvilket giver organisationer mulighed for at have en enkelt integreret løsning til administration af DLP-politikker, overvågning og overholdelse på tværs af Office pakke.

Når følsomhedsmærkater er aktiveret Power BI:

• Følsomme data, både i Power BI-tjenesten og i Power BI Desktop, kan klassificeres og mærkes ved hjælp af de samme velkendte Microsoft Information Protection-følsomhedsmærkater, der bruges i Office og i Azure Purview.
• Styringspolitikker kan gennemtvinges, selv når Power BI-indhold eksporteres til Excel-, PowerPoint-, PDF- eller .pbix-filer, for at sikre, at dataene er beskyttet, selvom de stadig Power BI.
• .pbix-filer kan krypteres i henhold til politikker for MIP-mærkater, når der anvendes et MIP-mærkat på .pbix-filen i Desktop, hvilket sikrer, at det kun er godkendte brugere, der kan redigere denne fil.
• Det er nemt at klassificere og beskytte PBIX-filer på samme måde, som det gøres med Excel, Word og PowerPoint filer. Med blot to klik kan en fil mærkes i henhold til følsomhedsniveauet og krypteres yderligere, hvis den indeholder forretningsfortrolige data.
• Excel projektmapper nedarver automatisk følsomhedsmærkaterne, 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 Power BI-datasættet analyseres i Excel.
• Følsomhedsmærkater, der Power BI på rapporter og dashboards, er synlige i Power BI iOS- og Android-mobilapps.
• Følsomhedsmærkater bevares, når Power BI rapport integreres i Teams, SharePoint et sikkert websted (prøveversion). Dette hjælper organisationer med at bevare klassificering og beskyttelse ved eksport, når de integrerer Power BI indhold.
• Nedarvning af mærkater ved oprettelse af nyt indhold i Power BI-tjenesten sikrer, at den mærkat, der anvendes på et datasæt i Power BI-tjenesten, anvendes på nyt indhold, der er oprettet oven på datasættet.
• Power BI api'er til scanning af Power BI kan udtrække en Power BI-artefakts følsomhedsmærkat og give administratorer af Power BI og InfoSec mulighed for at overvåge mærkning i Power BI-tjenesten og oprette ledelsesrapporter.
• Power BI sikrer, at det kun er godkendte brugere, der kan ændre eller fjerne mærkater med beskyttelsesindstillinger Power BI tjenesten.
• Kommer snart
  • Power BI API'er til anvendelse af MIP-mærkater for at gøre det muligt for centrale teams at navngive indhold i Power BI tjenesten.
  • Administratorer kan gennemtvinge anvendelse af mærkater på nyt eller redigeret indhold med en obligatorisk mærkatpolitik i Power BI-tjenesten (prøveversion).
  • Automatisk mærkning af downstreamartefakter i Power BI tjenesten. Når en mærkat på et datasæt anvendes eller ændres, anvendes etiketten automatisk på alt downstreamindhold, der er forbundet til dette artefakt.

Du kan Microsoft Information Protection flere oplysninger i dokumentationen til Power BI med følsomhedsmærkater.

Microsoft Cloud App Security (MCAS) til Power BI

Microsoft Cloud App Security er en af verdens førende sikkerhedsmæglere i cloudadgang, der er navngivet som leder på Gartners Magic Quadrant for CASB-markedet (Cloud Access Security Broker). Cloud App Security bruges til at sikre brugen af cloudapps. Det gør det muligt for organisationer at overvåge og styre risky-Power BI, f.eks. brugeradgang fra ikke-administrerede enheder i realtid. Sikkerhedsadministratorer kan definere politikker til at styre brugerhandlinger, f.eks. downloade rapporter med følsomme oplysninger.

Med Cloud App Security kan organisationer få følgende DLP-funktioner:

• Angiv kontrolelementer i realtid for at gennemtvinge risikobehændede brugersessioner Power BI. Hvis en bruger f.eks. opretter forbindelse til Power BI fra et sted uden for sit land, kan sessionen overvåges af Cloud App Security's kontrolelementer i realtid og risikobaserede handlinger, f.eks. download af data, der er mærket med følsomhedsmærkaten "Stærkt fortroligt", kan blokeres med det samme.
• Undersøg Power BI brugeraktivitet med Cloud App Security s aktivitetslog. Cloud App Security-aktivitetsloggen inkluderer Power BI-aktivitet, som registreres i Office 365-overvågningsloggen, som indeholder oplysninger om alle bruger- og administratoraktiviteter samt oplysninger om følsomhedsmærkater for relevante aktiviteter, f.eks. anvend, skift og fjern mærkat. Administratorer kan udnytte Cloud App Security avancerede filtre og hurtige handlinger til effektiv undersøgelse af problemer.
• Opret brugerdefinerede politikker for at give besked om mistænkelig brugeraktivitet i Power BI. Cloud App Security's aktivitetspolitik kan bruges til at definere dine egne brugerdefinerede regler, så du kan registrere brugerfunktionsmåder, der afviger fra normen, og endda reagere på den automatisk, hvis det virker for farlige.
• Arbejd med Cloud App Security's indbyggede registrering af uregelmæssigheder. Cloud App Securitys politikker for registrering af uregelmæssigheder leverer bruger adfærds analyse og maskinel indlæring, der er klar til brug, så du er klar til at køre avanceret trussels registrering på tværs af dit skybaserede miljø. Når en politik for registrering af uregelmæssigheder identificerer en mistænkelig funktionsmåde, udløser den en sikkerhedsadvarsel.
• rollen Power BI administrator i Cloud App Security-portalen. Cloud App Security indeholder en App-specifik administratorrolle, der kan bruges til at give Power BI administratorer kun de tilladelser, de har brug for til at få adgang til Power BI relevante data på portalen, f. eks. beskeder, brugere i risiko, aktivitets logge og andre Power BI relaterede oplysninger.

du kan finde flere oplysninger under brug af Microsoft Cloud App Securitys kontrolelementer i Power BI .

Funktioner til eksempelvisning af sikkerhed

Dette emne indeholder en liste over de funktioner, der er planlagt til udgivelse frem til og med marts 2021. Da dette emne indeholder en liste over funktioner, der muligvis ikke er frigivet endnu, kan leverings tidslinjerne blive ændret, og den projekterede funktionalitet kan blive frigivet senere end 2021, eller de frigives måske ikke. Hvis du vil have flere oplysninger om prøveversioner, skal du gennemse vilkårene for Online Services.

Hent dine egne Log Analytics (BYOLA)

få dine egne Log Analytics muliggør integration mellem Power BI og Azure-Log Analytics. Denne integration omfatter Azure Log Analytics Advanced Analytics Engine, Interactive Query Language og indbyggede Machine Learning-strukturer.

Power BI sikkerhedsspørgsmål og-svar

Følgende spørgsmål er almindelige spørgsmål og svar om sikkerhed i Power BI. Disse er organiseret, afhængigt af hvornår de blev føjet til dette whitepaper, 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 brugere forbindelse og får adgang til datakilder under brug af Power BI?

• Power BI administrerer legitimationsoplysninger til datakilder for hver bruger i forbindelse med legitimationsoplysninger til skyen eller til forbindelser via en personlig gateway. Datakilder, der administreres af en data gateway i det lokale miljø, kan deles på tværs af virksomheden, og tilladelserne til disse datakilder kan administreres af Gatewayadministratoren. Når du konfigurerer et datasæt, kan brugeren vælge et sæt legitimationsoplysninger fra deres personlige lager eller bruge en data gateway i det lokale miljø til at bruge et delt sæt legitimationsoplysninger.

  I import tilfælde opretter en bruger en forbindelse på baggrund af brugerens logon og får adgang til dataene med legitimationsoplysningerne. når datasættet er publiceret til Power BI tjeneste, bruger Power BI altid denne brugers legitimationsoplysninger til at importere data. Når dataene er importeret, kan du ikke få adgang til den underliggende datakilde, når dataene vises i rapporter og Dashboard. Power BI understøtter godkendelse med enkeltlogon for udvalgte datakilder. Hvis forbindelsen er konfigureret til at bruge Single Sign-on, bruges legitimationsoplysningerne for datasættet til at oprette forbindelse til datakilden.

  For rapporter, der er forbundet med DirectQuery, er datakilden forbundet direkte ved hjælp af forudkonfigurerede legitimationsoplysninger, og 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 legitimationsoplysningerne for den aktuelle bruger til at oprette forbindelse til datakilden, når brugeren får vist dataene. Når du bruger med Single Sign-on, kan sikkerhed på rækkeniveau (RLS) og/eller OLS (Object-level security) implementeres i datakilden, og det gør det muligt for brugerne at få vist de data, de har tilladelse til at få adgang til. Når forbindelsen er til datakilder i clouden, bruges Azure AD-godkendelse til enkeltlogon. for datakilder i Prem understøttes Kerberos, SAML og Azure AD.

  Når der oprettes forbindelse til Kerberos, sendes brugerens UPN til gatewayen, og hvis du bruger Kerberos-begrænset delegering, repræsenteres brugeren, og der oprettes forbindelse til de respektive datakilder. SAML understøttes også på gatewayen for SAP HANA data source. Du kan finde flere oplysninger i oversigten over enkeltlogon for gateways.

  hvis datakilden er Azure Analysis Services eller i det lokale miljø Analysis Services og sikkerhed på rækkeniveau (RLS) og/eller sikkerhed på objektniveau (OLS) er konfigureret, vil den Power BI tjeneste anvende den pågældende sikkerhed på rækkeniveau 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 data artefakt kan ikke se de 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 adgangen til data på rækkeniveau, og du kan definere filtre i rollen.

  Sikkerhed på objektniveau (OLS) kan bruges til at sikre følsomme tabeller eller kolonner. Men i modsætning til sikkerhed på rækkeniveau sikrer sikkerhed på objektniveau også objektnavne og metadata. Det hjælper med til at forhindre ondsindede brugere i selv at opdage, at sådanne objekter ikke findes. sikre tabeller og kolonner vises 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. Fra syns punktet for brugere uden korrekte adgangstilladelser findes der ikke sikre tabeller og kolonner, som ikke findes.

  Sikkerhed på objektniveau, sammen med sikkerhed på rækkeniveau, gør det muligt at forbedre sikkerheden i forbindelse med sikkerhed på rapporter og datasæt, hvilket sikrer, at 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 i transit ved hjælp af HTTPS (undtagen når den datakilde, der er valgt af kunden, ikke understøtter HTTPS), så der kan oprettes forbindelse fra datakilden til den Power BI tjeneste. Der etableres en sikker forbindelse med dataprovideren, og det er først, når der er etableret en sikker forbindelse, at data krydser netværket.

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

• når der opnås adgang til en datakilde, følger Power BI-tjenesten den proces, der er beskrevet i afsnittet godkendelse til datakilder tidligere i dette dokument.

Cachelagrer klienter data for websiden lokalt?

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

Hvad med rollebaseret sikkerhed, deling af rapporter eller dashboards og dataforbindelser? Hvordan fungerer det sammen med dataadgang, Dashboard visning, rapport adgang eller opdatering?

• Hvis et dashboard, en rapport eller en datamodel deles med andre brugere via Power BI i forbindelse med datakilder, der ikke understøtter sikkerhed på rolleniveau, bliver dataene tilgængelige for brugerne, som de deles med, og brugerne kan få dem vist og interagere med dem. Power BI godkender ikke brugerne igen i forhold til den oprindelige datakilde. Når data uploades til Power BI, er den bruger, som blev 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 er i RLS, f. eks. en Analysis Services datakilde, cachelagres kun Dashboard data i Power bi. Hver gang en rapport eller et datasæt vises eller tilgås i Power BI, som bruger data fra en datakilde, der understøtter sikkerhed på rolleniveau, tilgår Power BI-tjenesten datakilden for at hente data på baggrund af brugerens legitimationsoplysninger. Hvis der er tilstrækkelige tilladelser, indlæses dataene i rapporten eller datamodellen for den pågældende bruger. Hvis godkendelse mislykkes, får brugeren vist en fejl.

  Du kan finde flere oplysninger i afsnittet godkendelse til data kilder tidligere i dette dokument.

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

• Power BI tilbyder Power BI Personal Gateway, som er en funktion, der giver brugerne mulighed for at oprette legitimationsoplysninger til flere forskellige datakilder og derefter bruge disse legitimationsoplysninger automatisk, når hver af disse datakilder efterfølgende tilgås. Du kan finde flere oplysninger under Power BI Personal Gateway.

Hvilke porte bruges af data gatewayen i det lokale miljø og den personlige gateway? Er der nogle domænenavne, der skal tillades til forbindelses formål?

• Det detaljerede svar på dette spørgsmål er tilgængelig på følgende link: gateway porte

Hvordan bruges genoprettelses nøgler, når der arbejdes med data gatewayen i det lokale miljø, og hvor gemmes de? Hvad med sikker administration af legitimationsoplysninger?

• Under installationen og konfigurationen af gatewayen skriver administratoren 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. Denne fil er også krypteret. Indholdet af filen kan kun dekrypteres af denne specifikke Windows-computer og kun af denne specifikke konto for gatewaytjenesten.

  Når en bruger angiver legitimationsoplysninger for datakilden i brugergrænsefladen i Power BI-tjenesten, 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 AES symmetrisk nøgle, før dataene gemmes i den Power BI tjeneste. Denne proces sikrer, at Power BI-tjenesten aldrig har adgang til 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 Ports 443, 5671-5672 og 9350-9354 er åbne for udgående kommunikation. Denne protokol foretrækkes, da den har lavere kommunikationsspild.

  • HTTPS – WebSockets over 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ø.

Hvilke 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 brugerne på baggrund af geografisk landestandard. Sagt mere detaljeret, så bruger Power BI-tjenesten 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 produktdownloads (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 relevante efterfølgende forbindelser med Power BI-tjenesten, samt den indledende sikre Power BI-logonside.

  På baggrund af de oplysninger, der angives under den indledende forbindelse til Power BI-tjenesten, kontakter en brugers browser det angivne Azure CDN (eller for nogle filer den angivne WFE) for at downloade samlingen af angivne fælles filer, som er nødvendige for at muliggøre browserens interaktion med Power BI-tjenesten. browsersiden inkluderer derefter Azure AD-tokenet, sessionsoplysningerne, placeringen af den tilknyttede back-end-klynge og den samling af filer, der er hentet fra Azure CDN-og WFE-klyngen, for varigheden af den Power BI tjenestes browsersession.

i forbindelse med Power BI visuelle elementer udfører Microsoft enhver sikkerheds-eller beskyttelses vurdering af den brugerdefinerede visuelle kode, før de udgiver elementer til galleriet?

• Nej. Det er kundens ansvar at gennemse og afgøre, om der kan være tillid til koden for den brugerdefinerede visualisering. Alle koder for brugerdefinerede visualiseringer håndteres i et sandkassemiljø, så en evt. fejlbehæftet kode i en brugerdefineret visualisering ikke påvirker resten af Power BI-tjenesten.

Er der andre Power BI-visualiseringer, som sender oplysninger uden for kundens netværk?

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

I forbindelse med skabelon apps udfører Microsoft enhver sikkerheds-eller beskyttelses vurdering af skabelon-appen, før der publiceres elementer i galleriet?

• Nej. App-udgiveren er ansvarlig for indholdet, mens det er kundens ansvar at gennemgå og finde ud af, om du har tillid til udgiveren af skabelon appen.

Er der skabelon apps, der kan sende oplysninger uden for kunde netværket?

• Ja. Det er kundens ansvar at gennemgå udgiverens politik til beskyttelse af personlige oplysninger og finde ud af, om du skal installere skabelon programmet på lejeren. Udgiveren er ansvarlig for at undersøge kunden om appens funktionsmåde og funktioner.

Hvad med data højhedsområde? Kan vi klargøre lejere i datacentre, der er placeret i bestemte geografiske områder, for at sikre, at dataene ikke efterlader landegrænserne?

• Nogle kunder i visse geografiske områder har mulighed for at oprette en lejer i et nationalt cloudmiljø, hvor datalagring og -behandling er isoleret fra alle andre datacentre. Nationale cloudmiljøer har en lidt anderledes type sikkerhed, da en separat dataforvalter driver det nationale cloudmiljø i Power BI-tjenesten på vegne af Microsoft.

  Alternativt kan kunder også konfigurere en lejer i et bestemt område. Disse lejere har dog ikke en separat data uafhængig person fra Microsoft. Priserne på nationale cloudmiljøer er forskellig fra den offentligt tilgængelige kommercielle Power BI-tjeneste. Du kan finde flere oplysninger om tilgængeligheden af Power BI-tjenesten i nationale cloudmiljøer i Power BI i nationale cloudmiljøer.

hvordan behandler Microsoft forbindelser til kunder, der har Power BI Premium abonnementer? er disse forbindelser forskellige fra dem, der er oprettet for den ikke-Premium Power BI tjeneste?

• de forbindelser, der er oprettet for kunder med Power BI Premium abonnementer, implementerer en Azure Business-to-Business -autorisations proces (B2B) ved hjælp af azure AD for at aktivere adgangskontrol og godkendelse. Power BI håndterer forbindelser fra Power BI Premium-abonnenter til Power BI Premium-ressourcer på samme måde som for alle andre Azure AD-brugere.

Yderligere ressourcer

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

• Introduktion til Power BI Desktop
• REST API til Power BI – oversigt
• Reference til Power BI-API
• On-premises data gateway (Datagateway i det lokale miljø)
• Nationale Power BI-cloudmiljøer
• Power BI Premium
• Oversigt over enkeltlogon (SSO) til gateways i Power BI