Vitbok om Power BI-säkerhet

Sammanfattning: Power BI är en online-programvarutjänst (SaaS eller Programvara som en tjänst) från Microsoft som gör att du enkelt och snabbt kan skapa business intelligence-instrumentpaneler, rapporter, semantiska modeller och visualiseringar via självbetjäning. Med Power BI kan du ansluta till många olika datakällor, kombinera och forma data från dessa anslutningar och sedan skapa rapporter och instrumentpaneler som kan delas med andra.

Författare: 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

Tekniska granskare: Cristian Petculescu, Amir Netz, Sergei Gundorov

Gäller för: Power BI SaaS, Power BI Desktop, Power BI Premium, Power BI Embedded Analytics, Power BI Mobile.

Kommentar

Du kan spara eller skriva ut det här vitboken genom att välja Skriv ut i webbläsaren och sedan välja Spara som PDF.

Introduktion

Power BI är en online-programvarutjänst (SaaS eller Programvara som en tjänst) från Microsoft som gör att du enkelt och snabbt kan skapa business intelligence-instrumentpaneler, rapporter, semantiska modeller och visualiseringar via självbetjäning. Med Power BI kan du ansluta till många olika datakällor, kombinera och forma data från dessa anslutningar och sedan skapa rapporter och instrumentpaneler som kan delas med andra.

Världen förändras snabbt. organisationer genomgår en accelererad digital omvandling, och vi ser en massiv ökning av distansarbete, ökad kundefterfrågan på onlinetjänster och ökad användning av avancerad teknik i drift och affärsbeslut. Och allt detta drivs av molnet.

När övergången till molnet har ändrats från en sippring till en översvämning, och med den nya, exponerade ytan som medföljer den, frågar fler företag Hur säkra är mina data i molnet? och Vilket skydd från slutpunkt till slutpunkt är tillgängligt för att förhindra att mina känsliga data läcker? Och för DE BI-plattformar som ofta hanterar en del av den mest strategiska informationen i företaget är dessa frågor dubbelt viktiga.

De årtionden gamla grunderna i BI-säkerhetsmodellen – säkerhet på objektnivå och radnivå – även om de fortfarande är viktiga, räcker uppenbarligen inte längre för att tillhandahålla den typ av säkerhet som behövs i molntiden. I stället måste organisationer leta efter en molnbaserad, flernivåbaserad, djupskyddslösning för sina business intelligence-data.

Power BI har skapats för att ge branschledande fullständigt och hermetiskt skydd för data. Produkten har fått de högsta säkerhetsklassificeringarna i branschen, och idag anförtror många nationella säkerhetsmyndigheter, finansinstitut och vårdgivare den med sin känsligaste information.

Allt börjar med grunden. Efter en tuff period i början av 2000-talet gjorde Microsoft enorma investeringar för att hantera sina säkerhetsproblem, och under de följande årtiondena byggde en stark säkerhetsstack som går lika djupt som datorns bios-bios-kernel på chip och sträcker sig hela vägen upp till slutanvändarupplevelser. Dessa djupa investeringar fortsätter och idag arbetar över 3 500 Microsoft-tekniker med att skapa och förbättra Microsofts säkerhetsstack och proaktivt hantera det ständigt skiftande hotlandskapet. Med miljarder datorer, biljoner inloggningar och otaliga zettabyte information som anförtrotts Microsofts skydd, har företaget nu den mest avancerade säkerhetsstacken i teknikindustrin och ses i stort sett som den globala ledaren i kampen mot skadliga aktörer.

Power BI bygger på den här starka grunden. Den använder samma säkerhetsstack som gav Azure rätt att hantera och skydda världens känsligaste data och integreras med de mest avancerade verktygen för informationsskydd och efterlevnad i Microsoft 365. Dessutom ger den säkerhet genom säkerhetsåtgärder i flera lager, vilket resulterar i heltäckande skydd som utformats för att hantera de unika utmaningarna i molntiden.

För att tillhandahålla en lösning från slutpunkt till slutpunkt för att skydda känsliga tillgångar behövde produktteamet hantera utmanande kundproblem på flera samtidiga fronter:

• Hur styr vi vem som kan ansluta, var de ansluter från och hur de ansluter? Hur kan vi kontrollera anslutningarna?
• Hur lagras data? Hur krypteras den? Vilka kontroller har jag för mina data?
• Hur gör jag för att kontrollera och skydda mina känsliga data? Hur gör jag för att se till att dessa data inte kan läcka utanför organisationen?
• Hur gör jag för att granskar vem som utför vilka åtgärder? Hur gör jag för att reagera snabbt om det finns misstänkt aktivitet i tjänsten?

Den här artikeln innehåller ett omfattande svar på alla dessa frågor. Den börjar med en översikt över tjänstarkitekturen och förklarar hur huvudflödena i systemet fungerar. Sedan fortsätter den med att beskriva hur användare autentiserar till Power BI, hur dataanslutningar upprättas och hur Power BI lagrar och flyttar data via tjänsten. I det sista avsnittet beskrivs de säkerhetsfunktioner som gör att du som tjänstadministratör kan skydda dina mest värdefulla tillgångar.

Power BI-tjänst styrs av Villkoren för Microsoft Online Services och Sekretesspolicy för Microsoft Enterprise. Information om platsen för databehandling finns i Villkoren för databearbetning i Villkoren för Microsoft Online-tjänster och dataskyddstillägget. För efterlevnadsinformation är Microsoft Trust Center den primära resursen för Power BI. Power BI-teamet arbetar hårt för att ge sina kunder de senaste innovationerna och produktiviteten. Läs mer om efterlevnad i Microsofts efterlevnadserbjudanden.

Power BI-tjänst följer SDL (Security Development Lifecycle), strikta säkerhetsmetoder som stöder säkerhetskrav och efterlevnadskrav. SDL hjälper utvecklare att skapa säkrare programvara genom att minska antalet och allvarlighetsgraden för sårbarheter i programvara, samtidigt som utvecklingskostnaden minskar. Mer information finns på Microsoft Security Development Lifecycle metoder.

Power BI-arkitektur

Power BI-tjänst bygger på Azure, Microsofts plattform för molnbaserad databehandling. Power BI distribueras för närvarande i många datacenter runt om i världen – det finns många aktiva distributioner som görs tillgängliga för kunder i de regioner som hanteras av dessa datacenter och lika många passiva distributioner som fungerar som säkerhetskopior för varje aktiv distribution.

Webbklientdelskluster (WFE)

WFE-klustret ger användarens webbläsare det första HTML-sidinnehållet vid webbplatsinläsning och pekare på CDN-innehåll som används för att återge webbplatsen i webbläsaren.

Ett WFE-kluster består av en ASP.NET webbplats som körs i Azure App Service-miljön. När användare försöker ansluta till Power BI-tjänst kan klientens DNS-tjänst kommunicera med Azure Traffic Manager för att hitta det lämpligaste (vanligtvis närmaste) datacentret med en Power BI-distribution. Mer information om den här processen finns i Prestandatrafikdirigeringsmetod för Azure Traffic Manager.

Statiska resurser som *.js, *.css och bildfiler lagras mestadels i ett Azure Content Delivery Network (CDN) och hämtas direkt av webbläsaren. Observera att distributioner av nationella myndigheter är ett undantag från den här regeln och av efterlevnadsskäl utelämnar CDN och använder i stället ett WFE-kluster från en kompatibel region för att hantera statiskt innehåll.

Power BI-serverdelskluster (BE)

Serverdelsklustret är stamnätet för alla funktioner som är tillgängliga i Power BI. Den består av flera tjänstslutpunkter som används av Klientwebb- och API-klienter samt bakgrundstjänster, databaser, cacheminnen och olika andra komponenter.

Serverdelen är tillgänglig i de flesta Azure-regioner och distribueras i nya regioner när de blir tillgängliga. En enskild Azure-region är värd för ett eller flera serverdelskluster som tillåter obegränsad horisontell skalning av Power BI-tjänst när de lodräta och vågräta skalningsgränserna för ett enskilt kluster är uttömda.

Varje serverdelskluster är tillståndskänsligt och är värd för alla data för alla klienter som tilldelats klustret. Ett kluster som innehåller data för en specifik klient kallas klientorganisationens hemkluster. En autentiserad användares hemklusterinformation tillhandahålls av Global Service och används av webbklientdelen för att dirigera begäranden till klientorganisationens hemkluster.

Varje serverdelskluster består av flera virtuella datorer som kombinerats till flera skalningsuppsättningar som är anpassade för att utföra specifika uppgifter, tillståndskänsliga resurser som SQL-databaser, lagringskonton, servicebussar, cacheminnen och andra nödvändiga molnkomponenter.

Klientmetadata och data lagras inom klustergränser förutom datareplikering till ett sekundärt serverdelskluster i en länkad Azure-region i samma Azure-geografi. Det sekundära serverdelsklustret fungerar som ett redundanskluster vid regionala avbrott och är passivt vid andra tidpunkter.

Serverdelsfunktioner hanteras av mikrotjänster som körs på olika datorer i klustrets virtuella nätverk som inte är tillgängliga utifrån, förutom två komponenter som kan nås från det offentliga Internet:

• Gatewaytjänst
• Azure API Management

Power BI Premium-infrastruktur

Power BI Premium erbjuder en tjänst för prenumeranter som behöver Premium Power BI-funktioner, till exempel avancerad AI, distribution till olicensierade användare osv. När en kund registrerar sig för en Power BI Premium-prenumeration skapas Premium-kapaciteten via Azure Resource Manager.

Power BI Premium-kapaciteter finns i serverdelskluster som är oberoende av den vanliga Power BI-serverdelen – se ovan). Detta ger bättre isolering, resursallokering, support, säkerhetsisolering och skalbarhet för Premium-erbjudandet.

Följande diagram illustrerar arkitekturen för Power BI Premium-infrastrukturen:

Anslutningen till Power BI Premium-infrastrukturen kan göras på många sätt, beroende på användarscenariot. Power BI Premium-klienter kan vara en användares webbläsare, en vanlig Power BI-serverdel, direkta anslutningar via XMLA-klienter, ARM-API:er osv.

Power BI Premium-infrastrukturen i en Azure-region består av flera Power BI Premium-kluster (minst ett). De flesta Premium-resurser kapslas in i ett kluster (till exempel beräkning) och det finns några vanliga regionala resurser (till exempel metadatalagring). Premium-infrastrukturen möjliggör två sätt att uppnå horisontell skalbarhet i en region: öka resurserna i kluster och/eller lägga till fler kluster på begäran efter behov (om klusterresurser närmar sig sina gränser).

Stamnätet för varje kluster är beräkningsresurser som hanteras av Vm-skalningsuppsättningar och Azure Service Fabric. Vm-skalningsuppsättningar och Service Fabric tillåter snabb och smärtfri ökning av beräkningsnoder när användningen växer och orkestrerar distribution, hantering och övervakning av Power BI Premium-tjänster och -program.

Det finns många omgivande resurser som säkerställer en säker och tillförlitlig infrastruktur: lastbalanserare, virtuella nätverk, nätverkssäkerhetsgrupper, servicebussar, lagring osv. Hemligheter, nycklar och certifikat som krävs för Power BI Premium hanteras uteslutande av Azure Key Vault . All autentisering görs via integrering med Microsoft Entra-ID exklusivt.

Alla förfrågningar som kommer till Power BI Premium-infrastrukturen går först till klientdelsnoder – de är de enda noderna som är tillgängliga för externa anslutningar. Resten av resurserna är dolda bakom virtuella nätverk. Klientdelsnoderna autentiserar begäran, hanterar den eller vidarebefordrar den till lämpliga resurser (till exempel serverdelsnoder).

Serverdelsnoder tillhandahåller de flesta power BI Premium-funktioner.

Power BI Mobile

Power BI Mobile är en samling appar som är utformade för de tre primära mobila plattformarna: Android, iOS och Windows (UWP). Säkerhetsöverväganden för Power BI Mobile-appar finns i två kategorier:

• Enhetskommunikation
• Programmen och data på enheten

För enhetskommunikation kommunicerar alla Power BI Mobile-program med Power BI-tjänst och använder samma anslutnings- och autentiseringssekvenser som används av webbläsare, som beskrivs i detalj tidigare i det här vitboken. Power BI-mobilapparna för iOS och Android skapar en webbläsarsession i själva programmet, medan Windows-mobilappen skapar en asynkron meddelandekö för att upprätta kommunikationskanalen med Power BI (för inloggningsprocessen).

I följande tabell visas stöd för certifikatbaserad autentisering (CBA) för Power BI Mobile baserat på den mobila enhetsplattformen:

CBA-support	iOS	Android	Fönster
Power BI (logga in på tjänsten)	Stöds	Stöds	Stöds inte
SSRS ADFS lokalt (anslut till SSRS-servern)	Stöds inte	Stöds	Stöds inte
SSRS program-proxyn	Stöds	Stöds	Stöds inte

Power BI Mobile-appar kommunicerar aktivt med Power BI-tjänst. Telemetri används för att samla in användningsstatistik för mobilappar och liknande data som överförs till tjänster som används för att övervaka användning och aktivitet. inga kunddata skickas med telemetri.

Power BI-programmet lagrar data på enheten som underlättar användningen av appen:

• Microsoft Entra-ID och uppdateringstoken lagras i en säker mekanism på enheten med hjälp av branschstandardsäkerhetsåtgärder.
• Data och inställningar (nyckel/värde-par för användarkonfiguration) cachelagras i lagring på enheten och kan krypteras av operativsystemet. I iOS görs detta automatiskt när användaren anger ett lösenord. I Android kan detta konfigureras i inställningarna. I Windows utförs det med hjälp av BitLocker.
• För Android- och iOS-appar cachelagras data och inställningar (nyckel/värde-par för användarkonfiguration) i lagring på enheten i en sandbox-miljö och intern lagring som endast är tillgänglig för appen. För Windows-appen är data endast tillgängliga för användaren (och systemadministratören).
• Omlokalisering aktiveras eller inaktiveras explicit av användaren. Om funktionen är aktiverad sparas inte platsdata på enheten och delas inte med Microsoft.
• Aviseringar aktiveras eller inaktiveras uttryckligen av användaren. Om det är aktiverat stöder Android och iOS inte geografiska datahemvistkrav för meddelanden.

Datakryptering kan förbättras genom att tillämpa kryptering på filnivå via Microsoft Intune, en programvarutjänst som tillhandahåller hantering av mobila enheter och program. Alla tre plattformar som Power BI Mobile är tillgängligt för stöder Intune. När Intune är aktiverat och konfigurerat krypteras data på den mobila enheten och själva Power BI-programmet kan inte installeras på ett SD-kort. Läs mer om Microsoft Intune.

Windows-appen har också stöd för Windows Information Protection (WIP).

För att implementera enkel inloggning är vissa skyddade lagringsvärden relaterade till tokenbaserad autentisering tillgängliga för andra Microsoft-appar från första part (till exempel Microsoft Authenticator) och hanteras av Microsoft Authentication Library (MSAL).

Power BI Mobile-cachelagrade data tas bort när appen tas bort, när användaren loggar ut från Power BI Mobile eller när användaren inte kan logga in (till exempel efter en tokens förfallohändelse eller lösenordsändring). Datacachen innehåller instrumentpaneler och rapporter som tidigare använts från Power BI Mobile-appen.

Power BI Mobile har inte åtkomst till andra programmappar eller filer på enheten.

Med Power BI-apparna för iOS och Android kan du skydda dina data genom att konfigurera ytterligare identifiering, till exempel att tillhandahålla Ansikts-ID, Touch ID eller ett lösenord för iOS och biometriska data (fingeravtrycks-ID) för Android. Läs mer om ytterligare identifiering.

Autentisering till Power BI-tjänst

Användarautentisering till Power BI-tjänst består av en serie begäranden, svar och omdirigeringar mellan användarens webbläsare och Power BI-tjänst eller De Azure-tjänster som används av Power BI. Den sekvensen beskriver processen för användarautentisering i Power BI, som följer beviljandeflödet för Microsoft Entra-autentiseringskod. Mer information om alternativ för en organisations användarautentiseringsmodeller (inloggningsmodeller) finns i Välja en inloggningsmodell för Microsoft 365.

Autentiseringssekvens

Användarautentiseringssekvensen för Power BI-tjänst sker enligt beskrivningen i följande steg, som illustreras i bilden som följer dem.

1. En användare initierar en anslutning till Power BI-tjänst från en webbläsare, antingen genom att skriva in Power BI-adressen i adressfältet eller genom att välja Logga in från Power BI-marknadsföringssidan (https://powerbi.microsoft.com). Anslutningen upprättas med TLS och HTTPS och all efterföljande kommunikation mellan webbläsaren och Power BI-tjänst använder HTTPS.

2. Azure Traffic Manager kontrollerar användarens DNS-post för att fastställa det lämpligaste (vanligtvis närmaste) datacenter där Power BI distribueras och svarar på DNS med IP-adressen för det WFE-kluster som användaren ska skickas till.

3. WFE returnerar sedan en HTML-sida till webbläsarklienten, som innehåller en MSAL.js biblioteksreferens som krävs för att initiera inloggningsflödet.

4. Webbläsarklienten läser in HTML-sidan som tagits emot från WFE och omdirigerar användaren till inloggningssidan för Microsoft Online Services.

5. När användaren har autentiserats omdirigerar inloggningssidan användaren tillbaka till Power BI WFE-sidan med en autentiseringskod.

6. Webbläsarklienten läser in HTML-sidan och använder autentiseringskoden för att begära token (åtkomst, ID, uppdatering) från Microsoft Entra-ID.

7. Användarens klient-ID används av webbläsarklienten för att fråga den globala Power BI-tjänsten, som upprätthåller en lista över klienter och deras Power BI-serverdelsklusterplatser. Den globala Power BI-tjänsten avgör vilket Power BI-serverdelstjänstkluster som innehåller användarens klientorganisation och returnerar URL:en för Power BI-serverdelsklustret tillbaka till klienten.

8. Klienten kan nu kommunicera med API:et för Power BI-serverdelsklustrets URL med hjälp av åtkomsttoken i auktoriseringshuvudet för HTTP-begäranden. Microsoft Entra-åtkomsttoken har ett förfallodatum inställt enligt Microsoft Entra-principer, och för att upprätthålla den aktuella sessionen gör Power BI-klienten i användarens webbläsare regelbundna begäranden om att förnya åtkomsttoken innan den upphör att gälla.

I sällsynta fall där autentisering på klientsidan misslyckas på grund av ett oväntat fel försöker koden återgå till att använda autentisering på serversidan i WFE. Mer information om autentiseringsflödet på serversidan finns i avsnittet frågor och svar i slutet av det här dokumentet.

Dataresidens

Om inget annat anges i dokumentationen lagrar Power BI kunddata i ett Azure-geografiskt område som tilldelas när en Microsoft Entra-klientorganisation registrerar sig för Power BI-tjänst för första gången. En Microsoft Entra-klientorganisation innehåller användar- och programidentiteter, grupper och annan relevant information som gäller för en organisation och dess säkerhet.

Tilldelningen av ett Azure-geografiskt område för klientdatalagring görs genom att mappa det land eller den region som valts som en del av Microsoft Entra-klientinstallationen till det lämpligaste Azure-geografiska området där det finns en Power BI-distribution. När den här bestämningen har gjorts lagras alla Power BI-kunddata i det här valda Azure-geografiska området (kallas även hem-geo), förutom i fall där organisationer använder multi-geo-distributioner.

Flera geografiska områden (multi-geo)

Vissa organisationer har en global närvaro och kan kräva Power BI-tjänst i flera Azure-geografiska områden. Ett företag kan till exempel ha sitt huvudkontor i USA men kan också göra affärer i andra geografiska områden, till exempel Australien. I sådana fall kan företaget kräva att vissa Power BI-data lagras i vila i fjärrregionen för att följa lokala regler. Den här funktionen i Power BI-tjänst kallas multi-geo.

Frågekörningslagret, frågecacheminnen och artefaktdata som tilldelats till en arbetsyta med flera geo-platser finns och finns kvar i azure-geografin för fjärrkapacitet. Vissa artefaktmetadata, till exempel rapportstruktur, kan dock förbli lagrade i vila i klientens hem-geo. Dessutom kan viss dataöverföring och bearbetning fortfarande ske i klientorganisationens hemgeo, även för arbetsytor som finns i en Premium-kapacitet med flera geo-platser.

Mer information om hur du skapar och hanterar Power BI-distributioner som omfattar flera Azure-geografiska områden finns i Konfigurera Multi-Geo-stöd för Power BI Premium .

Regioner och datacenter

Power BI-tjänst är tillgängliga i specifika Azure-geografiska områden enligt beskrivningen iMicrosoft Trust Center. Mer information om var dina data lagras och hur de används finns i Microsoft Trust Center. Åtaganden om platsen för vilande kunddata anges i databehandlingsvillkoren i villkoren för Microsoft Online Services-villkor.

Microsoft tillhandahåller även datacenter för nationella entiteter. Mer information om Power BI-tjänst tillgänglighet för nationella/regionala moln finns i Nationella/regionala Moln i Power BI.

Datahantering

I det här avsnittet beskrivs metoder för datahantering i Power BI när det gäller lagring, bearbetning och överföring av kunddata.

Vilande data

Power BI använder två resurstyper för primär datalagring:

• Azure Storage
• Azure SQL Databases

I de flesta scenarier används Azure Storage för att bevara data från Power BI-artefakter, medan Azure SQL Databases används för att bevara artefaktmetadata.

Alla data som sparas av Power BI krypteras som standard med hjälp av Microsoft-hanterade nycklar. Kunddata som lagras i Azure SQL Databases är fullständigt krypterade med hjälp av Azure SQL:s transparent datakryptering-teknik (TDE). Kunddata som lagras i Azure Blob Storage krypteras med Azure Storage Encryption.

Organisationer kan också använda Power BI Premium för att använda sina egna nycklar för att kryptera vilande data som importeras till en semantisk modell. Den här metoden beskrivs ofta som BYOK (Bring Your Own Key). Genom att använda BYOK ser du till att kunddata inte exponeras även om det uppstår ett fel hos tjänstoperatören – något som inte enkelt kan uppnås med transparent kryptering på tjänstsidan. Mer information finns i Ta med egna krypteringsnycklar för Power BI .

Power BI-semantiska modeller tillåter olika anslutningslägen för datakällor som avgör om datakällans data sparas i tjänsten eller inte.

Semantiskt modellläge (typ)	Data som sparats i Power BI
Importera	Ja
DirectQuery	Nej
Live Connect	Nej
Sammansatt	Om innehåller en importdatakälla
Strömning	Om den är konfigurerad för att sparas

Oavsett det semantiska modellläge som används kan Power BI tillfälligt cachelagra alla hämtade data för att optimera prestanda för fråge- och rapportinläsning.

Data under behandling

Data bearbetas när de antingen aktivt används av en eller flera användare som en del av ett interaktivt scenario eller när en bakgrundsprocess, till exempel uppdatering, berör dessa data. Power BI läser in aktivt bearbetade data i minnesutrymmet för en eller flera tjänstarbetsbelastningar. För att underlätta de funktioner som krävs av arbetsbelastningen krypteras inte de bearbetade data i minnet.

Data under överföring

Power BI kräver att all inkommande HTTP-trafik krypteras med TLS 1.2 eller senare. Begäranden som försöker använda tjänsten med TLS 1.1 eller lägre avvisas.

Autentisering till datakällor

När du ansluter till en datakälla kan en användare välja att importera en kopia av data till Power BI eller ansluta direkt till datakällan.

Vid import upprättar en användare en anslutning baserat på användarens inloggning och kommer åt data med autentiseringsuppgifterna. När den semantiska modellen har publicerats till Power BI-tjänst använder Power BI alltid användarens autentiseringsuppgifter för att importera data. När data har importerats får du inte åtkomst till den underliggande datakällan om du visar data i rapporter och instrumentpaneler. Power BI stöder enkel inloggningsautentisering för valda datakällor. Om anslutningen är konfigurerad för att använda enkel inloggning används autentiseringsuppgifterna för semantikmodellens ägare för att ansluta till datakällan.

Om en datakälla ansluts direkt med förkonfigurerade autentiseringsuppgifter används de förkonfigurerade autentiseringsuppgifterna för att ansluta till datakällan när någon användare visar data. Om en datakälla ansluts direkt med enkel inloggning används den aktuella användarens autentiseringsuppgifter för att ansluta till datakällan när en användare visar data. När det används med enkel inloggning kan säkerhet på radnivå (RLS) och/eller säkerhet på objektnivå (OLS) implementeras på datakällan. På så sätt kan användare endast visa data som de har behörighet att komma åt. När anslutningen är till datakällor i molnet används Microsoft Entra-autentisering för enkel inloggning. för lokala datakällor, Kerberos, Security Assertion Markup Language (SAML) och Microsoft Entra ID stöds.

Om datakällan är Azure Analysis Services eller lokala Analysis Services, och RLS och/eller OLS har konfigurerats, kommer Power BI-tjänst att tillämpa säkerhet på radnivå och användare som inte har tillräckliga autentiseringsuppgifter för att komma åt underliggande data (vilket kan vara en fråga som används i en instrumentpanel, rapport eller annan dataartefakt) ser inte data som de inte har tillräckliga behörigheter för.

Premiumfunktioner

Arkitektur för dataflöden

Dataflöden ger användarna möjlighet att konfigurera serverdelsdatabearbetningsåtgärder som extraherar data från polymorfa datakällor, kör transformeringslogik mot data och sedan landar dem i en målmodell för användning i olika rapportpresentationstekniker. Alla användare som har rollen medlem, deltagare eller administratör på en arbetsyta kan skapa ett dataflöde. Användare i visningsrollen kan visa data som bearbetas av dataflödet men kanske inte gör ändringar i dess sammansättning. När ett dataflöde har skapats kan alla medlemmar, deltagare eller administratörer på arbetsytan schemalägga uppdateringar, samt visa och redigera dataflödet genom att ta över ägarskapet för det.

Varje konfigurerad datakälla är bunden till en klientteknik för åtkomst till datakällan. Strukturen för de autentiseringsuppgifter som krävs för att komma åt dem skapas för att matcha nödvändig implementeringsinformation för datakällan. Transformeringslogik tillämpas av Power Query-tjänster medan data är under flygning. För premiumdataflöden körs Power Query-tjänster i serverdelsnoder. Data kan hämtas direkt från molnkällorna eller via en gateway som är installerad lokalt. När transporten hämtas direkt från en molnkälla till tjänsten eller till gatewayen använder den skyddsmetod som är specifik för klienttekniken, om tillämpligt. När data överförs från gatewayen till molntjänsten krypteras de. Se avsnittet Data i överföring ovan.

När kundens angivna datakällor kräver autentiseringsuppgifter för åtkomst, ger ägaren/skaparen av dataflödet dem under redigeringen. De lagras med standardlagring av autentiseringsuppgifter för hela produkten. Se avsnittet Autentisering till datakällor ovan. Det finns olika metoder som användare kan konfigurera för att optimera datapersistens och åtkomst. Som standard placeras data i ett Power BI-ägt och skyddat lagringskonto. Lagringskryptering är aktiverat på Blob Storage-containrar för att skydda data medan de är i vila. Se avsnittet Vilande data nedan. Användare kan dock konfigurera ett eget lagringskonto som är associerat med en egen Azure-prenumeration. När du gör det beviljas ett Power BI-tjänst huvudnamn åtkomst till lagringskontot så att det kan skriva data där under uppdateringen. I det här fallet ansvarar lagringsresursägaren för att konfigurera kryptering på det konfigurerade ADLS-lagringskontot. Data överförs alltid till Blob Storage med hjälp av kryptering.

Eftersom prestanda vid åtkomst till lagringskonton kan vara suboptimal för vissa data, har användarna också möjlighet att använda en Power BI-värdbaserad beräkningsmotor för att öka prestandan. I det här fallet lagras data redundant i en SQL-databas som är tillgänglig för DirectQuery via åtkomst av power BI-backend-systemet. Data krypteras alltid i filsystemet. Om användaren tillhandahåller en nyckel för kryptering av data som lagras i SQL-databasen används den nyckeln för att kryptera dem dubbelt.

När du frågar med DirectQuery används HTTPS för krypterat transportprotokoll för att komma åt API:et. All sekundär eller indirekt användning av DirectQuery styrs av samma åtkomstkontroller som beskrivits tidigare. Eftersom dataflöden alltid är bundna till en arbetsyta begränsas åtkomsten till data alltid av användarens roll i arbetsytan. En användare måste ha minst läsbehörighet för att kunna köra frågor mot data på något sätt.

När Power BI Desktop används för att komma åt data i ett dataflöde måste det först autentisera användaren med hjälp av Microsoft Entra-ID för att avgöra om användaren har tillräcklig behörighet för att visa data. I så fall hämtas en SaS-nyckel och används för att komma åt lagringen direkt med hjälp av HTTPS för krypterat transportprotokoll.

Bearbetningen av data i hela pipelinen genererar Office 365-granskningshändelser. Vissa av dessa händelser samlar in säkerhets- och sekretessrelaterade åtgärder.

Sidnumrerade rapporter

Sidnumrerade rapporter är utformade för att skrivas ut eller delas. De kallas sidnumrerade eftersom de är formaterade för att passa bra på en sida. De visar alla data i en tabell, även om tabellen sträcker sig över flera sidor. Du kan styra rapportsidans layout exakt.

Sidnumrerade rapporter stöder omfattande och kraftfulla uttryck skrivna i Microsoft Visual Basic .NET. Uttryck används ofta i sidnumrerade Power BI Report Builder-rapporter för att hämta, beräkna, visa, gruppera, sortera, filtrera, parameterisera och formatera data.

Uttryck skapas av rapportens författare med åtkomst till det breda utbudet av funktioner i .NET-ramverket. Bearbetning och körning av sidnumrerade rapporter utförs i en sandbox-miljö.

Sidnumrerade rapportdefinitioner (.rdl) lagras i Power BI och för att publicera och/eller återge en sidnumrerad rapport måste en användare autentisera och auktorisera på samma sätt som beskrivs i avsnittet Autentisering till Power BI-tjänsten ovan.

Microsoft Entra-token som erhölls under autentiseringen används för att kommunicera direkt från webbläsaren till Power BI Premium-klustret.

I Power BI Premium tillhandahåller Power BI-tjänst-körningen en lämpligt isolerad körningsmiljö för varje rapportåtergivning. Detta inkluderar fall där rapporterna som återges tillhör arbetsytor som tilldelats samma kapacitet.

En sidnumrerad rapport kan komma åt en bred uppsättning datakällor som en del av återgivningen av rapporten. Sandbox-miljön kommunicerar inte direkt med någon av datakällorna utan kommunicerar i stället med den betrodda processen för att begära data och sedan lägger den betrodda processen till de nödvändiga autentiseringsuppgifterna till anslutningen. På så sätt har sandbox-miljön aldrig åtkomst till några autentiseringsuppgifter eller hemligheter.

För att stödja funktioner som Bing-kartor eller anrop till Azure Functions har sandbox-miljön åtkomst till Internet.

Power BI Embedded-analys

Oberoende programvaruleverantörer (ISV:er) och lösningsleverantörer har två huvudsakliga lägen för att bädda in Power BI-artefakter i sina webbprogram och portaler: bädda in för din organisation och bädda in för dina kunder. Artefakten bäddas in i en IFrame i programmet eller portalen. En IFrame får inte läsa eller skriva data från det externa webbprogrammet eller portalen, och kommunikationen med IFrame görs med hjälp av Power BI Client SDK med postmeddelanden.

I ett inbäddningsscenario för din organisation får Microsoft Entra-användare åtkomst till sitt eget Power BI-innehåll via portaler som anpassats av deras företag och IT. Alla Power BI-principer och funktioner som beskrivs i det här dokumentet, till exempel säkerhet på radnivå (RLS) och säkerhet på objektnivå (OLS) tillämpas automatiskt på alla användare oberoende av om de har åtkomst till Power BI via Power BI-portalen eller via anpassade portaler.

I ett inbäddningsscenario för dina kunder äger ISV:er vanligtvis Power BI-klienter och Power BI-objekt (instrumentpaneler, rapporter, semantiska modeller och andra). Det är en ISV-serverdelstjänsts ansvar att autentisera sina slutanvändare och bestämma vilka artefakter och vilken åtkomstnivå som är lämplig för slutanvändaren. ISV-principbeslut krypteras i en inbäddningstoken som genereras av Power BI och skickas till ISV-serverdelen för ytterligare distribution till slutanvändarna enligt ISV:ns affärslogik. Slutanvändare som använder en webbläsare eller andra klientprogram kan inte dekryptera eller ändra inbäddningstoken. SDK:er på klientsidan, till exempel Power BI-klient-API:er , lägger automatiskt till den krypterade inbäddningstoken i Power BI-begäranden som auktorisering : EmbedToken-huvud . Baserat på det här huvudet framtvingar Power BI alla principer (till exempel åtkomst eller RLS) precis som isv:n angav under genereringen.

För att aktivera inbäddning och automatisering och för att generera de inbäddningstoken som beskrivs ovan exponerar Power BI en omfattande uppsättning REST-API:er. Dessa Power BI REST-API:er stöder både användardelegering och Microsoft Entra-metoder för autentisering och auktorisering för tjänstens huvudnamn.

Power BI Embedded-analys och dess REST-API:er stöder alla power BI-nätverksisoleringsfunktioner som beskrivs i den här artikeln: Till exempel tjänsttaggar och privata länkar.

AI-funktioner

Power BI har för närvarande stöd för två breda kategorier av AI-funktioner i produkten idag: VISUELLA AI-objekt och AI-berikanden. AI-funktionerna på visuell nivå omfattar funktioner som Key-Influencers, Decomposition-Tree, Smart-Narrative, Anomaly Detection, R-visual, Python-visual, Clustering, Forecasting, Q&A, Quick-Insights osv. AI-berikningsfunktionerna omfattar funktioner som AutoML, Azure Machine Learning, CognitiveServices, R/Python-transformeringar osv.

De flesta av de funktioner som nämns ovan stöds i både delade och Premium-arbetsytor idag. AutoML och CognitiveServices stöds dock endast i Premium-arbetsytor på grund av IP-begränsningar. I dag, med AutoML-integreringen i Power BI, kan en användare skapa och träna en anpassad ML-modell (till exempel Förutsägelse, Klassificering, Regression osv.) och tillämpa den för att få förutsägelser vid inläsning av data till ett dataflöde som definierats i en Premium-arbetsyta. Dessutom kan Power BI-användare använda flera CognitiveServices-API:er, till exempel TextAnalytics och ImageTagging, för att transformera data innan de läser in dem i en dataflödes-/semantisk modell som definierats i en Premium-arbetsyta.

Premium AI-berikande funktioner kan bäst ses som en samling tillståndslösa AI-funktioner/transformeringar som kan användas av Power BI-användare i deras dataintegreringspipelines som används av en Power BI-semantisk modell eller ett dataflöde. Observera att dessa funktioner också kan nås från aktuella redigeringsmiljöer för dataflöden/semantiska modeller i Power BI-tjänsten och Power BI Desktop. Dessa AI-funktioner/transformeringar körs alltid på en Premium-arbetsyta/-kapacitet. Dessa funktioner visas i Power BI som en datakälla som kräver en Microsoft Entra-token för Den Power BI-användare som använder AI-funktionen. Dessa AI-datakällor är speciella eftersom de inte visar upp några egna data och endast tillhandahåller dessa funktioner/transformeringar. Under körningen gör dessa funktioner inga utgående anrop till andra tjänster för att överföra kundens data. Låt oss titta på Premium-scenarierna individuellt för att förstå kommunikationsmönster och relevant säkerhetsrelaterad information som rör dem.

För träning och tillämpning av en AutoML-modell använder Power BI Azure AutoML SDK och kör all utbildning i kundens Power BI-kapacitet. Under tränings iterationer anropar Power BI en experimenteringstjänst för Azure Machine Learning för att välja en lämplig modell och hyperparametrar för den aktuella iterationen. I det här utgående anropet skickas endast relevanta experimentmetadata (till exempel noggrannhet, ml-algoritm, algoritmparametrar osv.) från den tidigare iterationen. AutoML-träningen genererar en ONNX-modell och träningsrapportdata som sedan sparas i dataflödet. Senare kan Power BI-användare sedan använda den tränade ML-modellen som en transformering för att operationalisera ML-modellen enligt ett schema. För Api:er för TextAnalytics och ImageTagging anropar Power BI inte api:erna för CognitiveServices-tjänsten direkt, utan använder i stället en intern SDK för att köra API:erna i Power BI Premium-kapaciteten. Idag stöds dessa API:er i både Power BI-dataflöden och semantiska modeller. När du redigerar en datamodell i Power BI Desktop kan användarna bara komma åt den här funktionen om de har åtkomst till en Premium Power BI-arbetsyta. Därför uppmanas kunderna att ange sina Microsoft Entra-autentiseringsuppgifter.

Nätverksisolering

I det här avsnittet beskrivs avancerade säkerhetsfunktioner i Power BI. Vissa av funktionerna har specifika licensieringskrav. Mer information finns i avsnitten nedan.

Tjänsttaggar

En tjänsttagg representerar en grupp IP-adressprefix från en viss Azure-tjänst. Det hjälper till att minimera komplexiteten i frekventa uppdateringar av nätverkssäkerhetsregler. Kunder kan använda tjänsttaggar för att definiera nätverksåtkomstkontroller i nätverkssäkerhetsgrupper eller Azure Firewall. Kunder kan använda tjänsttaggar i stället för specifika IP-adresser när de skapar säkerhetsregler. Genom att ange tjänsttaggens namn (till exempel PowerBI) i fältet för lämplig källa eller mål (för API:er) i en regel kan kunderna tillåta eller neka trafik för motsvarande tjänst. Microsoft hanterar adressprefixen som omfattas av tjänsttaggen och uppdaterar automatiskt tjänsttaggen när adresserna ändras.

Private Link-integrering

Azure-nätverk tillhandahåller Azure Private Link-funktionen som gör att Power BI kan ge säker åtkomst via privata Slutpunkter i Azure Networking. Med Azure Private Link och privata slutpunkter skickas datatrafik privat med hjälp av Microsofts stamnätverksinfrastruktur, och därför passerar inte data internet.

Private Link ser till att Power BI-användare använder Microsofts privata nätverksstomme när de går till resurser i Power BI-tjänst.

Att använda Private Link med Power BI ger följande fördelar:

• Private Link ser till att trafiken flödar över Azure-stamnätet till en privat slutpunkt för Azure-molnbaserade resurser.
• Isolering av nätverkstrafik från icke-Azure-baserad infrastruktur, till exempel lokal åtkomst, skulle kräva att kunderna har Konfigurerat ExpressRoute eller ett virtuellt privat nätverk (VPN).

Mer information finns i Privata länkar för åtkomst till Power BI .

VNet-anslutning

Integreringsfunktionen Private Link ger säkra inkommande anslutningar till Power BI, men funktionen för VNet-anslutning möjliggör säker utgående anslutning från Power BI till datakällor i ett virtuellt nätverk.

VNet-gatewayer (Microsoft-hanterade) eliminerar kostnaden för att installera och övervaka lokala datagatewayer för att ansluta till datakällor som är associerade med ett virtuellt nätverk. De följer dock fortfarande den välbekanta processen för att hantera säkerhets- och datakällor, som med en lokal datagateway.

Följande är en översikt över vad som händer när du interagerar med en Power BI-rapport som är ansluten till en datakälla i ett VNet med hjälp av VNet-gatewayer:

1. Power BI-molntjänsten (eller någon av de andra molntjänsterna som stöds) startar en fråga och skickar frågan, information om datakällan och autentiseringsuppgifterna till Power Platform VNet-tjänsten (PP VNet).

2. PP VNet-tjänsten matar sedan säkert in en container som kör en VNet-gateway i undernätet. Den här containern kan nu ansluta till datatjänster som är tillgängliga från det här undernätet.

3. PP VNet-tjänsten skickar sedan frågan, information om datakällan och autentiseringsuppgifterna till VNet-gatewayen.

4. VNet-gatewayen hämtar frågan och ansluter till datakällorna med dessa autentiseringsuppgifter.

5. Frågan skickas sedan till datakällan för körning.

6. Efter körningen skickas resultaten till VNet-gatewayen och PP VNet-tjänsten skickar data på ett säkert sätt från containern till Power BI-molntjänsten.

Tjänstens huvudnamn

Power BI stöder användning av tjänstens huvudnamn. Lagra alla autentiseringsuppgifter för tjänstens huvudnamn som används för att kryptera eller komma åt Power BI i ett Nyckelvalv, tilldela rätt åtkomstprinciper till valvet och granska åtkomstbehörigheterna regelbundet.

Mer information finns i Automatisera Premium-arbetsytor och semantiska modelluppgifter med tjänstens huvudnamn.

Microsoft Purview för Power BI

Microsoft Purview Information Protection

Power BI är djupt integrerat med Microsoft Purview Information Protection. Med Microsoft Purview Information Protection kan organisationer ha en enda integrerad lösning för klassificering, etikettering, granskning och efterlevnad i Azure, Power BI och Office.

När informationsskydd är aktiverat i Power BI:

• Känsliga data, både i Power BI-tjänst och i Power BI Desktop, kan klassificeras och märkas med samma känslighetsetiketter som används i Office och i Azure.
• Styrningsprinciper kan tillämpas när Power BI-innehåll exporteras till Excel-, PowerPoint-, PDF-, Word- eller .pbix-filer för att säkerställa att data skyddas även när de lämnar Power BI.
• Det är enkelt att klassificera och skydda .pbix-filer i Power BI Desktop, precis som i Excel-, Word- och PowerPoint-program. Filer kan enkelt taggas enligt deras känslighetsnivå. Dessutom kan de krypteras om de innehåller affärshemliga data, vilket säkerställer att endast behöriga användare kan redigera dessa filer.
• Excel-arbetsböcker ärver automatiskt känslighetsetiketter när de ansluter till Power BI (förhandsversion), vilket gör det möjligt att upprätthålla klassificering från slutpunkt till slutpunkt och tillämpa skydd när Power BI-semantiska modeller analyseras i Excel.
• Känslighetsetiketter som tillämpas på Power BI-rapporter och instrumentpaneler visas i Power BI-mobilapparna iOS och Android.
• Känslighetsetiketter bevaras när en Power BI-rapport är inbäddad i Teams, SharePoint eller en säker webbplats. Detta hjälper organisationer att upprätthålla klassificering och skydd vid export vid inbäddning av Power BI-innehåll.
• Etikettarv när nytt innehåll skapas i Power BI-tjänst säkerställer att etiketter som tillämpas på semantiska modeller eller datamarter i Power BI-tjänst tillämpas på nytt innehåll som skapats ovanpå dessa semantiska modeller och datamarter.
• Power BI-administratörsgenomsöknings-API:er kan extrahera ett Power BI-objekts känslighetsetikett, vilket gör det möjligt för Power BI- och InfoSec-administratörer att övervaka etiketter i Power BI-tjänst och skapa exekutiva rapporter.
• Power BI-administratörs-API:er gör det möjligt för centrala team att programmatiskt tillämpa känslighetsetiketter på innehåll i Power BI-tjänst.
• Centrala team kan skapa obligatoriska etikettprinciper för att tillämpa etiketter på nytt eller redigerat innehåll i Power BI.
• Centrala team kan skapa standardetikettprinciper för att säkerställa att en känslighetsetikett tillämpas på allt nytt eller ändrat Power BI-innehåll.
• Automatisk nedströmskänslighetsetiketter i Power BI-tjänst säkerställer att när en etikett på en semantisk modell eller datamart tillämpas eller ändras, tillämpas eller ändras etiketten automatiskt på allt nedströmsinnehåll som är anslutet till den semantiska modellen eller datamarten.

Mer information finns i Känslighetsetiketter i Power BI.

Dataförlustskydd i Microsoft Purview principer (DLP) för Power BI

Microsoft Purviews DLP-principer hjälper organisationer att minska risken för känsliga affärsdataläckage från Power BI. DLP-principer hjälper dem att uppfylla efterlevnadskraven för myndighets- eller branschbestämmelser, till exempel GDPR (EU:s allmänna dataskyddsförordning) eller CCPA (California Consumer Privacy Act) och se till att deras data i Power BI hanteras.

När DLP-principer för Power BI konfigureras:

• Alla semantiska modeller inom de arbetsytor som anges i principen utvärderas av principen.
• Du kan identifiera när känsliga data laddas upp till dina Premium-kapaciteter. DLP-principer kan identifiera:
  • Känslighetsetiketter.
  • Typer av känslig information. Över 260 typer stöds. Identifiering av känslig informationstyp förlitar sig på Microsoft Purview-innehållsgenomsökning.
• När du stöter på en semantisk modell som identifieras som känslig kan du se ett anpassat principtips som hjälper dig att förstå vad du bör göra.
• Om du är en semantisk modellägare kan du åsidosätta en princip och förhindra att din semantiska modell identifieras som "känslig" om du har en giltig anledning att göra det.
• Om du är en semantisk modellägare kan du rapportera ett problem med en princip om du drar slutsatsen att en typ av känslig information har identifierats felaktigt.
• Automatiska riskreduceringar, till exempel aviseringar till säkerhetsadministratören, kan anropas.

Mer information finns i Principer för dataförlustskydd för Fabric Power BI.

Microsoft Defender för molnet-appar för Power BI

Microsoft Defender för molnet Apps är en av världens ledande molnåtkomstsäkerhetsmäklare, utsedda som ledande på Gartners Magic Quadrant för CASB-marknaden (Cloud Access Security Broker). Defender för molnet Apps används för att skydda användningen av molnappar. Det gör det möjligt för organisationer att övervaka och kontrollera, i realtid, riskfyllda Power BI-sessioner, till exempel användaråtkomst från ohanterade enheter. Säkerhetsadministratörer kan definiera principer för att styra användaråtgärder, till exempel att ladda ned rapporter med känslig information.

Med Defender för molnet Apps kan organisationer få följande DLP-funktioner:

• Ange realtidskontroller för att framtvinga riskfyllda användarsessioner i Power BI. Om en användare till exempel ansluter till Power BI utanför sitt land eller sin region kan sessionen övervakas av Defender för molnet Apps realtidskontroller och riskfyllda åtgärder, till exempel att ladda ned data som taggats med känslighetsetiketten "Strikt konfidentiellt", kan blockeras omedelbart.
• Undersök Power BI-användaraktivitet med aktivitetsloggen Defender för molnet Apps. Aktivitetsloggen Defender för molnet Apps innehåller Power BI-aktivitet som samlas in i Office 365-granskningsloggen, som innehåller information om alla användar- och administratörsaktiviteter samt information om känslighetsetiketter för relevanta aktiviteter som att tillämpa, ändra och ta bort etikett. Administratörer kan använda avancerade filter för Defender för molnet Apps och snabbåtgärder för effektiv problemundersökning.
• Skapa anpassade principer för att avisera om misstänkt användaraktivitet i Power BI. Funktionen Defender för molnet Apps-aktivitetsprincip kan användas för att definiera dina egna anpassade regler, för att hjälpa dig att identifiera användarbeteenden som avviker från normen, och till och med eventuellt agera på det automatiskt, om det verkar för farligt.
• Arbeta med den inbyggda avvikelseidentifieringen Defender för molnet Apps. Avvikelseidentifieringsprinciperna för Defender för molnet Apps tillhandahåller färdiga användarbeteendeanalyser och maskininlärning så att du redan från början är redo att köra avancerad hotidentifiering i din molnmiljö. När en princip för avvikelseidentifiering identifierar ett misstänkt beteende utlöser den en säkerhetsavisering.
• Power BI-administratörsroll i portalen Defender för molnet Apps. Defender för molnet Apps tillhandahåller en appspecifik administratörsroll som kan användas för att endast ge Power BI-administratörer de behörigheter de behöver för att komma åt Power BI-relevanta data i portalen, till exempel aviseringar, användare i riskzonen, aktivitetsloggar och annan Power BI-relaterad information.

Mer information finns i Använda Microsoft Defender för molnet Apps-kontroller i Power BI.

Förhandsversion av säkerhetsfunktioner

Det här avsnittet innehåller funktioner som planeras att släppas till och med mars 2021. Eftersom det här avsnittet innehåller funktioner som kanske inte har släppts ännu kan leveranstidslinjen ändras och planerade funktioner kan släppas senare än mars 2021, eller så kanske de inte släpps alls. Mer information om förhandsversioner finns i villkoren för onlinetjänster.

ByOLA (Bring Your Own Log Analytics)

Bring Your Own Log Analytics möjliggör integrering mellan Power BI och Azure Log Analytics. Den här integreringen omfattar Azure Log Analytics avancerade analysmotor, interaktiva frågespråk och inbyggda maskininlärningskonstruktioner.

Frågor och svar om Power BI-säkerhet

Följande frågor är vanliga säkerhetsfrågor och svar för Power BI. Dessa organiseras baserat på när de lades till i denna vitbok, för att underlätta din förmåga att snabbt hitta nya frågor och svar när detta dokument uppdateras. De senaste frågorna läggs till i slutet av den här listan.

Hur ansluter användarna till och får åtkomst till datakällor när de använder Power BI?

• Power BI hanterar autentiseringsuppgifter till datakällor för varje användare för molnautentiseringsuppgifter eller för anslutning via en personlig gateway. Datakällor som hanteras av en lokal datagateway kan delas över företaget och behörigheter till dessa datakällor kan hanteras av gatewayadministratören. När du konfigurerar en semantisk modell kan användaren välja en autentiseringsuppgift från sitt personliga arkiv eller använda en lokal datagateway för att använda en delad autentiseringsuppgift.

  I importfallet upprättar en användare en anslutning baserat på användarens inloggning och kommer åt data med autentiseringsuppgifterna. När den semantiska modellen har publicerats till Power BI-tjänst använder Power BI alltid användarens autentiseringsuppgifter för att importera data. När data har importerats får du inte åtkomst till den underliggande datakällan om du visar data i rapporter och instrumentpaneler. Power BI stöder enkel inloggningsautentisering för valda datakällor. Om anslutningen är konfigurerad för att använda enkel inloggning används den semantiska modellägarens autentiseringsuppgifter för att ansluta till datakällan.

  För rapporter som är anslutna till DirectQuery ansluts datakällan direkt med en förkonfigurerad autentiseringsuppgift. Den förkonfigurerade autentiseringsuppgiften används för att ansluta till datakällan när någon användare visar data. Om en datakälla ansluts direkt med enkel inloggning används den aktuella användarens autentiseringsuppgifter för att ansluta till datakällan när användaren visar data. När du använder med enkel inloggning kan säkerhet på radnivå (RLS) och/eller säkerhet på objektnivå (OLS) implementeras på datakällan, vilket gör att användarna kan visa data som de har behörighet att komma åt. När anslutningen är till datakällor i molnet används Microsoft Entra-autentisering för enkel inloggning. för lokala datakällor stöds Kerberos, SAML och Microsoft Entra ID.

  När du ansluter med Kerberos skickas användarens UPN till gatewayen, och med kerberos-begränsad delegering personifieras och ansluts användaren till respektive datakällor. SAML stöds också på gatewayen för SAP HANA-datakällan. Mer information finns i översikten över enkel inloggning för gatewayer.

  Om datakällan är Azure Analysis Services eller lokal Analysis Services och säkerhet på radnivå (RLS) och/eller säkerhet på objektnivå (OLS) har konfigurerats kommer Power BI-tjänst att tillämpa säkerhet på radnivå och användare som inte har tillräckliga autentiseringsuppgifter för att komma åt underliggande data (vilket kan vara en fråga som används i en instrumentpanel, rapport eller annan dataartefakt) ser inte data som användaren inte har tillräckliga behörigheter för.

  Säkerhet på radnivå med Power BI kan användas för att begränsa dataåtkomsten för angivna användare. Filter begränsar dataåtkomsten på radnivå och du kan definiera filter inom rollen.

  Säkerhet på objektnivå (OLS) kan användas för att skydda känsliga tabeller eller kolumner. Men till skillnad från säkerhet på radnivå skyddar säkerhet på objektnivå även objektnamn och metadata. Detta hjälper till att förhindra skadliga användare från att upptäcka även förekomsten av sådana objekt. Skyddade tabeller och kolumner döljs i fältlistan när du använder rapporteringsverktyg som Excel eller Power BI, och dessutom kan användare utan behörighet inte komma åt skyddade metadataobjekt via DAX eller någon annan metod. Från användarnas synvinkel utan rätt åtkomstbehörigheter finns skyddade tabeller och kolumner helt enkelt inte.

  Säkerhet på objektnivå, tillsammans med säkerhet på radnivå, möjliggör förbättrad säkerhet i företagsklass för rapporter och semantiska modeller, vilket säkerställer att endast användare med nödvändiga behörigheter har åtkomst till att visa och interagera med känsliga data.

Hur överförs data till Power BI?

• Alla data som begärs och överförs av Power BI krypteras under överföring med HTTPS (förutom när den datakälla som kunden väljer inte stöder HTTPS) för att ansluta från datakällan till Power BI-tjänst. En säker anslutning upprättas med dataprovidern, och endast när anslutningen har upprättats passerar data nätverket.

Hur cachelagar Power BI rapport-, instrumentpanels- eller modelldata och är det säkert?

• När en datakälla används följer Power BI-tjänst den process som beskrivs i avsnittet Autentisering till datakällor tidigare i det här dokumentet.

Cachelagrade klienter webbsidesdata lokalt?

• När webbläsarklienter får åtkomst till Power BI anger Power BI-webbservrarna cachekontrolldirektivet till no-store. Direktivet no-store instruerar webbläsare att inte cachelagrar webbsidan som visas av användaren och inte att lagra webbsidan i klientens cachemapp.

Hur är det med rollbaserad säkerhet, delning av rapporter eller instrumentpaneler och dataanslutningar? Hur fungerar det när det gäller dataåtkomst, instrumentpanelsvisning, rapportåtkomst eller uppdatering?

• För icke-rollnivåsäkerhet (RLS) aktiverade datakällor, om en instrumentpanel, rapport eller datamodell delas med andra användare via Power BI, är data sedan tillgängliga för användare som den delas med för att visa och interagera med. Power BI autentiserar inte om användare mot den ursprungliga datakällan. När data har laddats upp till Power BI ansvarar användaren som autentiserade mot källdata för att hantera vilka andra användare och grupper som kan visa data.

  När dataanslutningar görs till en RLS-kompatibel datakälla, till exempel en Analysis Services-datakälla, cachelagras endast instrumentpanelsdata i Power BI. Varje gång en rapport eller semantisk modell visas eller används i Power BI som använder data från den RLS-kompatibla datakällan, kommer Power BI-tjänst åt datakällan för att hämta data baserat på användarens autentiseringsuppgifter, och om det finns tillräckliga behörigheter läses data in i rapporten eller datamodellen för användaren. Om autentiseringen misslyckas visas ett fel.

  Mer information finns i avsnittet Autentisering till datakällor tidigare i det här dokumentet.

Våra användare ansluter till samma datakällor hela tiden, varav vissa kräver autentiseringsuppgifter som skiljer sig från deras domänautentiseringsuppgifter. Hur kan de undvika att behöva ange dessa autentiseringsuppgifter varje gång de upprättar en dataanslutning?

• Power BI erbjuder Power BI Personal Gateway, som är en funktion som låter användare skapa autentiseringsuppgifter för flera olika datakällor och sedan automatiskt använda dessa autentiseringsuppgifter när de senare kommer åt var och en av dessa datakällor. Mer information finns i Power BI Personal Gateway.

Vilka portar används av lokal datagateway och personlig gateway? Finns det några domännamn som måste tillåtas i anslutningssyfte?

• Det detaljerade svaret på den här frågan finns på följande länk: Gatewayportar

Hur används återställningsnycklar och var lagras de när du arbetar med den lokala datagatewayen? Hur är det med säker hantering av autentiseringsuppgifter?

• Under gatewayinstallationen och konfigurationen skriver administratören in en gateway-återställningsnyckel. Återställningsnyckeln används för att generera en stark AES-symmetrisk nyckel. En Asymmetrisk RSA-nyckel skapas också samtidigt.

  De genererade nycklarna (RSA och AES) lagras i en fil som finns på den lokala datorn. Filen är också krypterad. Innehållet i filen kan bara dekrypteras av den specifika Windows-datorn och endast av det specifika gatewaytjänstkontot.

  När en användare anger autentiseringsuppgifter för datakällan i användargränssnittet för Power BI-tjänst krypteras autentiseringsuppgifterna med den offentliga nyckeln i webbläsaren. Gatewayen dekrypterar autentiseringsuppgifterna med den privata RSA-nyckeln och krypterar dem igen med en AES-symmetrisk nyckel innan data lagras i Power BI-tjänst. Med den här processen har Power BI-tjänst aldrig åtkomst till okrypterade data.

Vilka kommunikationsprotokoll används av den lokala datagatewayen och hur skyddas de?

• Gatewayen stöder följande två kommunikationsprotokoll:

  • AMQP 1.0 – TCP + TLS: Det här protokollet kräver att portarna 443, 5671-5672 och 9350-9354 är öppna för utgående kommunikation. Det här protokollet är att föredra eftersom det har lägre kommunikationskostnader.

  • HTTPS – WebSockets via HTTPS + TLS: Det här protokollet använder endast port 443. WebSocket initieras av ett enda HTTP CONNECT-meddelande. När kanalen har upprättats är kommunikationen i princip TCP+TLS. Du kan tvinga gatewayen att använda det här protokollet genom att ändra en inställning som beskrivs i artikeln lokal gateway.

Vilken roll har Azure CDN i Power BI?

• Som tidigare nämnts använder Power BI Azure Content Delivery Network (CDN) för att effektivt distribuera nödvändigt statiskt innehåll och filer till användare baserat på geografiska nationella inställningar. För att gå in närmare använder Power BI-tjänst flera CDN:er för att effektivt distribuera nödvändigt statiskt innehåll och filer till användare via det offentliga Internet. Dessa statiska filer omfattar produktnedladdningar (till exempel Power BI Desktop, den lokala datagatewayen eller Power BI-appar från olika oberoende tjänsteleverantörer), webbläsarkonfigurationsfiler som används för att initiera och upprätta efterföljande anslutningar med Power BI-tjänst, samt den första säkra Power BI-inloggningssidan.

  Baserat på information som tillhandahålls under en första anslutning till Power BI-tjänst kontaktar en användares webbläsare det angivna Azure CDN (eller för vissa filer, WFE) för att ladda ned samlingen av angivna vanliga filer som krävs för att aktivera webbläsarens interaktion med Power BI-tjänst. Webbläsarsidan innehåller sedan Microsoft Entra-token, sessionsinformation, platsen för det associerade serverdelsklustret och samlingen av filer som laddats ned från Azure CDN- och WFE-klustret under den Power BI-tjänst webbläsarsessionen.

Utför Microsoft någon säkerhets- eller sekretessbedömning av den anpassade visuella koden innan objekt publiceras i galleriet för visuella Power BI-objekt?

• Nej. Det är kundens ansvar att granska och avgöra om anpassad visuell kod ska användas. All anpassad visuell kod används i en sandbox-miljö, så att eventuell felaktig kod i ett anpassat visuellt objekt inte påverkar resten av Power BI-tjänst negativt.

Finns det andra visuella Power BI-objekt som skickar information utanför kundnätverket?

• Ja. Visuella Bing Maps- och ESRI-objekt överför data från Power BI-tjänst för visuella objekt som använder dessa tjänster.

Utför Microsoft någon säkerhets- eller sekretessbedömning av mallappen innan objekt publiceras i galleriet för mallappar?

• Nej. Apputgivaren ansvarar för innehållet medan det är kundens ansvar att granska och avgöra om mallappens utgivare ska vara betrodd.

Finns det mallappar som kan skicka information utanför kundnätverket?

• Ja. Det är kundens ansvar att granska utgivarens sekretesspolicy och avgöra om mallappen ska installeras på klientorganisationen. Utgivaren ansvarar för att informera kunden om appens beteende och funktioner.

Hur är det med datasuveränitet? Kan vi etablera klientorganisationer i datacenter som finns i specifika geografiska områden för att säkerställa att data inte lämnar landets eller regionens gränser?

• Vissa kunder i vissa geografiska områden har möjlighet att skapa en klientorganisation i ett nationellt/regionalt moln, där datalagring och bearbetning hålls åtskilda från alla andra datacenter. Nationella/regionala moln har en något annorlunda typ av säkerhet, eftersom en separat dataförvaltare driver det nationella/regionala molnet Power BI-tjänst för Microsofts räkning.

  Alternativt kan kunder också konfigurera en klientorganisation i en viss region. Sådana klienter har dock ingen separat dataförvaltare från Microsoft. Prissättningen för nationella/regionala moln skiljer sig från de allmänt tillgängliga kommersiella Power BI-tjänst. Mer information om Power BI-tjänst tillgänglighet för nationella/regionala moln finns i Nationella/regionala Moln i Power BI.

Hur hanterar Microsoft anslutningar för kunder som har Power BI Premium-prenumerationer? Skiljer sig dessa anslutningar från de som upprättats för icke-Premium-Power BI-tjänst?

• De anslutningar som upprättas för kunder med Power BI Premium-prenumerationer implementerar en Auktoriseringsprocess för Microsoft Entra business-to-business (B2B) med hjälp av Microsoft Entra-ID för att aktivera åtkomstkontroll och auktorisering. Power BI hanterar anslutningar från Power BI Premium-prenumeranter till Power BI Premium-resurser på samma sätt som andra Microsoft Entra-användare.

Hur fungerar autentisering på serversidan i WFE?

• Autentisering på tjänstsidan för användarautentisering sker enligt beskrivningen i följande steg, som illustreras i bilden som följer dem.

1. En användare initierar en anslutning till Power BI-tjänst från en webbläsare, antingen genom att skriva in Power BI-adressen i adressfältet eller genom att välja Logga in från Power BI-marknadsföringssidan (https://powerbi.microsoft.com). Anslutningen upprättas med TLS 1.2 och HTTPS och all efterföljande kommunikation mellan webbläsaren och Power BI-tjänst använder HTTPS.

2. Azure Traffic Manager kontrollerar användarens DNS-post för att fastställa det lämpligaste (vanligtvis närmaste) datacenter där Power BI distribueras och svarar på DNS med IP-adressen för det WFE-kluster som användaren ska skickas till.

3. WFE omdirigerar sedan användaren till inloggningssidan för Microsoft Online Services.

4. När användaren har autentiserats omdirigerar inloggningssidan användaren till det tidigare fastställda närmaste Power BI-tjänst WFE-kluster med en autentiseringskod.

5. WFE-klustret kontrollerar med Microsoft Entra-ID för att hämta en Microsoft Entra-säkerhetstoken med hjälp av autentiseringskoden. När Microsoft Entra-ID returnerar lyckad autentisering av användaren och returnerar en Microsoft Entra-säkerhetstoken, konsulterar WFE-klustret den globala Power BI-tjänsten, som upprätthåller en lista över klienter och deras Power BI-serverdelsklusterplatser och avgör vilket Power BI-serverdelstjänstkluster som innehåller användarens klientorganisation. WFE-klustret returnerar sedan en programsida till användarens webbläsare med den session, åtkomst och routningsinformation som krävs för åtgärden.

6. När klientens webbläsare kräver kunddata skickar den nu begäranden till serverdelsklustrets adress med Microsoft Entra-åtkomsttoken i auktoriseringshuvudet. Power BI-serverdelsklustret läser Microsoft Entra-åtkomsttoken och validerar signaturen för att säkerställa att identiteten för begäran är giltig. Microsoft Entra-åtkomsttoken har ett förfallodatum inställt enligt Microsoft Entra-principer, och för att upprätthålla den aktuella sessionen gör Power BI-klienten i användarens webbläsare regelbundna begäranden om att förnya åtkomsttoken innan den upphör att gälla.

Ytterligare resurser

Mer information om Power BI finns i följande resurser.

• Komma igång med Power BI Desktop
• Power BI REST API – Översikt
• Power BI-API referens
• Lokal datagateway
• Nationella/regionala Moln i Power BI
• Power BI Premium
• Översikt över enkel inloggning (SSO) för gatewayer i Power BI