Power BI säkerhetssäkerhet white paper

Sammanfattning: Power BI är en online-programvarutjänst (SaaS eller Programvara som en tjänst) från Microsoft som gör att du snabbt och enkelt kan skapa business intelligence-instrumentpaneler, rapporter, datauppsättningar och visualiseringar med 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.

Skrivare: Y casshak Kemarkman, Paddy Osborne, Matt Neely,Trin Bencic, Srinivasan Turuvekere,Provan Petculescu, Adi Regev, Naveen Sivaraj, Ben Glastein, Evgeny Tshiorny, Arthi Ramasubramanian Iyer, Sid Jayadevan, Jeff Chang, Ori Eduar,DirigeringItor, Idan Sheinberg, Ron Cread, Sagiv Hadima, Paul Inbar, Igor Uzhviev, MichaelSamling, Jaime Tartageo, Gennady Pats, Orion Sydney, Yury Beretrappsky, Maya Shenhav, Romit Chattopadhyay, YarivKinmon, Bugdan Crivat

Tekniska granskare: Istanan Petculescu, Amir Netz,Udi Gundorov

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

Introduktion

Power BI är en onlinebaserad programvarutjänst (SaaS, programvara som en tjänst) från Microsoft som gör att du snabbt och enkelt kan instrumentpaneler, rapporter, datamängder och visualiseringar för Business Intelligence som självservice. 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 går igenom en accelererad digital omvandling och vi ser en enorm ökning av distansarbetet, ökad kundefterfrågan på onlinetjänster och ökad användning av avancerade tekniker inom drift och affärsbeslut. Allt detta drivs av molnet.

Allt eftersom övergången till molnet har ändrats från en rickle till en översvämmad, och med det nya exponerade ytområde som medföljer, frågar sig fler och fler företag Hur säkra är mina data i molnet? och Vilket skydd från hela slutet är tillgängligt för att förhindra att 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å – samtidigt som det fortfarande är viktigt, räcker helt klart inte längre för att tillhandahålla den typ av säkerhet som krävs i molneran. I stället måste organisationer leta efter en molnbaserad säkerhetslösning med flera nivåer för att kunna 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 som är tillgängliga i branschen, och i dag litar många nationella säkerhetsorganisationer, finansiella institutioner och vårdgivare på den känsligaste informationen.

Allt börjar med grunden. Efter en ungefärlig period i början av 2000-talet gjorde Microsoft enorma investeringar för att åtgärda säkerhetsproblemen, och under följande årtionden skapade de en mycket stark säkerhetsstack som går lika djupt som datorns bios kernel i chip och sträcker sig hela vägen fram till slutanvändarupplevelsen. Dessa stora investeringar fortsätter och idag arbetar över 3 500 Microsoft-tekniker med att skapa och förbättra Microsofts säkerhetsstack och proaktivt hantera hotlandskapet som ständigt förändras. Med miljarder datorer, biljontals inloggningar och oräkneliga zbyte med information som microsofts skydd har tilldelats, har företaget nu den mest avancerade säkerhetsstacken i teknikbranschen och betraktas allmänt som global ledare i strid mot illvilliga aktörer.

Power BI bygger på den här mycket starka grunden. Den använder samma säkerhetsstack som gav Azure rätt att hantera och skydda världens känsligaste data, och den integreras med de mest avancerade verktygen för informationsskydd och efterlevnad för Microsoft 365. Dessutom ger det säkerhet via säkerhetsåtgärder i flera lager, vilket resulterar i ett skydd från början till slut som utformats för att hantera de unika utmaningarna i molnerollen.

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

• Hur kontrollerar vi vem som kan ansluta, var de ansluter från och hur de ansluter? Hur kan vi kontrollera anslutningarna?
• Hur lagras data? Hur krypteras det? Vilka kontroller har jag på mina data?
• Hur gör jag för att styra och skydda mina känsliga data? Hur gör jag för att 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 tjänsten är misstänkt?

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 de viktigaste flödena i systemet fungerar. Den går sedan vidare till att beskriva hur användare autentiserar Power BI, hur dataanslutningar upprättas och hur Power BI lagrar och flyttar data genom 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änsten regleras av villkoren för Microsoft Online Services och Microsofts sekretesspolicy för företag. Information om platsen för databehandling finns i termerna Plats för databehandling i Microsoft Villkor för Onlinetjänster och i tillägget för dataskydd. När det gäller information om efterlevnad är Microsoft Trust Center den primära resursen för Power BI. Power BI-teamet arbetar ständigt med att ge sina kunder de senaste innovationerna och ökad produktivitet. Läs mer om efterlevnad i Microsofts efterlevnadserbjudanden.

Tjänsten Power BI security development lifecycle (SDL), strikt säkerhetspraxis som stöder krav på säkerhet och efterlevnad. SDL hjälper utvecklare att skapa säkrare program genom att minska antalet och allvarlighetsgraden för sårbarheter i programvara, samtidigt som utvecklingskostnaden minskar. Läs mer på Microsoft Security Development Lifecycle Practices.

Power BI arkitektur

Tjänsten Power BI bygger på Azure, Microsofts plattform för molnbaserad databehandling. Power BI distribueras för närvarande i många datacenter runtom i världen – det finns många aktiva distributioner som är tillgängliga för kunder i de regioner som hanteras av dessa datacenter. Det finns även lika många passiva distributioner som reserv för varje aktiv distribution.

Frontwebbkluster (WFE)

WFE-klustret förser användarens webbläsare med det första HTML-sidinnehållet vid webbplatsinläsning och hanterar den första anslutningen och autentiseringsprocessen för Power BI med hjälp av Azure Active Directory (Azure AD) för att autentisera klienter och tillhandahålla token för efterföljande klientanslutningar till Power BI-serversidetjänsten.

Ett WFE-kluster består av en ASP.NET webbplats som körs i Azure App Service-miljön. När användarna försöker ansluta till Power BI-tjänsten 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 Trafikroutningsmetod för prestanda för Azure Traffic Manager.

WFE-klustret som tilldelats användaren hanterar inloggnings- och autentiseringssekvensen (beskrivs längre fram i den här artikeln) och hämtar en Azure AD-åtkomsttoken när autentiseringen har lyckats. Den ASP.NET komponenten i WFE-klustret parsar token för att avgöra vilken organisation användaren tillhör och hör sedan till Power BI Global Service. WFE anger för webbläsaren vilket serverkluster som innehåller organisationens klientorganisation. När en användare har autentiserats sker efterföljande klientinteraktioner för kunddata direkt med serversidan eller Premium-klustret, utan att WFE är en koordinator för dessa begäranden.

Statiska resurser som .js,.css och bildfiler lagras huvudsakligen på Azure Content Delivery Network (CDN) och hämtas direkt av webbläsaren. Observera att distributioner av nationella myndighetskluster är ett undantag till 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 vara värd för statiskt innehåll.

Power BI serverkluster (BE)

Serverklustret är grunden till alla funktioner som är tillgängliga i Power BI. Den består av flera tjänstslutpunkter som används av webbklientdels- och API-klienter samt bakgrundstjänster, databaser, cacheminnen och olika andra komponenter.

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

Varje serverkluster är tillståndsful och är värd för alla data för alla klienter som är tilldelade till klustret. Ett kluster som innehåller data för en specifik klient kallas klientens hemkluster. En autentiserad användares hemklusterinformation tillhandahålls av global tjänst och används av webbklientdelen för att dirigera begäranden till klientens hemkluster.

Varje serverkluster består av flera virtuella datorer som kombineras till flera skalningsuppsättningar som kan skalas om för att utföra specifika uppgifter, tillståndsful-resurser som SQL-databaser, lagringskonton, tjänstbussningar, cacheminnen och andra nödvändiga molnkomponenter.

Klientmetadata och data lagras inom klustergränser förutom för datareplikering till ett sekundärt serverkluster i en länkad Azure-region i samma Azure-geografi. Det sekundära serverklustret fungerar som ett redundanskluster vid ett regionalt avbrott och är passivt vid något annat tillfälle.

Serverfunktionaliteten betjänas 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:

• Gateway-tjänst
• Azure API Management

Power BI Premium infrastruktur

Power BI Premium en tjänst för prenumeranter som behöver premiumfunktioner Power BI, till exempel dataflöden, sidnumrerade rapporter, AI osv. När en kund registrerar sig för en Power BI Premium-prenumeration skapas Premium kapacitet via Azure Resource Manager.

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

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

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

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

Stamnätet i varje kluster är beräkningsresurser som hanteras av Virtual Machine Scale Sets (VMSS) och Azure Service Fabric. MED VMSS Service Fabric kan du snabbt och enkelt öka antalet beräkningsnoder när användningen växer och dirigerar 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, Service Bus, lagring osv. Hemligheter, nycklar och certifikat som krävs för Power BI Premium hanteras av Azure Key Vault exklusivt. All autentisering görs endast via integrering med Azure AD.

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

Backend-noder ger 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 är indela i två kategorier:

• Enhetskommunikation
• Programmen och data på enheten

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

Följande tabell visar stöd för certifikatbaserad autentisering (CBA) för Power BI Mobile, baserat på mobil enhetsplattform:

Power BI Mobile-appar kommunicerar aktivt med Power BI-tjänsten. 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.

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

• Azure AD 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 sker 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).
• Geoplats aktiveras eller inaktiveras explicit av användaren. Om den här inställningen är aktiverad sparas inte geoplatsdata på enheten och delas inte med Microsoft.
• Meddelanden aktiveras eller inaktiveras explicit av användaren. Om det här alternativet är aktiverat har Android och iOS inte stöd för 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 plattformarna som Power BI Mobile tillgängliga har stöd för Intune. Med Intune 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 att Microsoft Intune.

Appen Windows stöder även Windows Information Protection (WIP).

För att implementera enkel inloggning är vissa säkra lagringsvärden relaterade till den tokenbaserade autentiseringen tillgängliga för andra Appar från Microsofts första part (till exempel Microsoft Authenticator) och hanteras av ADAL SDK (Azure Active Directory Authentication Library).

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 händelse för tokens upphörande eller lösenordsändring). Datacachen omfattar instrumentpaneler och rapporter som tidigare öppnats från Power BI Mobile-appen.

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

Med Power BI för iOS och Android kan du skydda dina data genom att konfigurera ytterligare identifiering, till exempel ange Face 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änsten

Användarautentisering till Power BI-tjänsten består av en serie begäranden, svar och omdirigeringar mellan användarens webbläsare och den 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 Azure Active Directory autentiseringskodens beviljandeflöde. Mer information om alternativ för en organisations modeller för användarautentisering (inloggningsmodeller) finns i Choosing a sign-in model for Microsoft 365.

Autentiseringssekvens

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

1. En användare initierar en anslutning till Power BI-tjänsten 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 landningssidan ( https://powerbi.microsoft.com) . Anslutningen upprättas med hjälp av TLS 1.2 och HTTPS, och all efterföljande kommunikation mellan webbläsaren och Power BI-tjänsten använder HTTPS.

2. Den Azure Traffic Manager kontrollerar användarens DNS-post för att fastställa det lämpligaste (vanligtvis närmaste) datacentret 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 Power BI WFE-klustret med en autentiseringskod.

5. WFE-klustret söker med Azure AD-tjänsten för att hämta en Azure AD-säkerhetstoken med hjälp av autentiseringskoden. När Azure AD returnerar autentiseringen av användaren och returnerar en Azure AD-säkerhetstoken, rådgör WFE-klustret med Power BI Global Service, som upprätthåller en lista över klienter och deras Power BI-serverklusterplatser och avgör vilket Power BI-servertjä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 serversidans klusteradress med Azure AD-åtkomsttoken i auktoriseringshuvudet. Server Power BI-klustret läser Azure AD-åtkomsttoken och verifierar signaturen för att säkerställa att identiteten för begäran är giltig. Azure AD-åtkomsttokenhar en standardlivslängd på 1 timme och för att underhålla den aktuella sessionen kommer användarens webbläsare regelbundet att göra förfrågningar om att förnya åtkomsttoken innan den upphör att gälla.

Dataplacering

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

Tilldelningen av ett Azure-geografiskt område för lagring av klientdata görs genom att mappa det land eller den region som valts som en del av azure AD-klientkonfigurationen till den lämpligaste Azure-geografin där det Power BI finns en distribution. När detta fastställs lagras alla Power BI-kunddata i det valda Azure-geografin (även kallat 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änster i flera Azure-geografiska områden. Ett företag kan till exempel ha sitt huvudkontor i USA men kan även 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 uppfylla lokala föreskrifter. Den här funktionen Power BI tjänsten kallas multi-geo.

Frågekörningslagret, frågecacheminnen och artefaktdata som tilldelats till en multi-geo-arbetsyta finns kvar i Azure-fjärrkapacitetens geografiska område. Vissa artefaktmetadata, till exempel rapportstruktur, kan dock finnas kvar i vila i klientens hem-geo. Dessutom kan viss dataöverföring och bearbetning fortfarande ske i klientens hemområde, även för arbetsytor som finns i en multi-geo-Premium kapacitet.

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

Regioner och datacenter

Power BI tjänster är tillgängliga i specifika Azure-geografiska områden enligt beskrivningen i Microsoft Trust Center. Mer information om var dina data lagras och hur de används finns i Microsoft Trust Center. Åtaganden avseende platsen för vilade kunddata anges i databehandlingsvillkoren för Microsoft Villkor för Onlinetjänster.

Microsoft tillhandahåller också datacenter för suveräna entiteter. Mer information om tillgänglighet för Power BI-tjänsten för nationella moln finns i Power BI för nationella moln.

Datahantering

I det här Power BI beskrivs hur du hanterar data när det gäller lagring, bearbetning och överföring av kunddata.

Vilande data

Power BI använder två primära datalagringsresurstyper:

• 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-databaser används för att bevara artefaktmetadata.

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

Organisationer kan också använda Power BI Premium använda sina egna nycklar för att kryptera vilodata som importeras till en datauppsättning. 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 en tjänstoperatör, – något som inte är lätt att uppnå med transparent kryptering på tjänstsidan. Mer information finns i Ta med dina Power BI krypteringsnycklar.

Power BI datauppsättningar möjliggör en mängd olika anslutningslägen för datakällan som avgör om datakällans data bevaras i tjänsten eller inte.

Oavsett vilket datauppsättningsläge som används kan Power BI tillfälligt cachelagra hämtade data för att optimera prestanda för fråge- och rapportbelastning.

Data som bearbetas

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 aktivt bearbetade data till minnesutrymmet för en eller flera tjänstarbetsbelastningar. För att underlätta de funktioner som krävs av arbetsbelastningen krypteras inte bearbetade data i minnet.

Data under överföring

Power BI kräver att all inkommande HTTP-trafik krypteras med TLS 1.2 eller högre. 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 datauppsättningen har publicerats Power BI tjänsten Power BI alltid den här användarens autentiseringsuppgifter för att importera data. När data har importerats kommer visning av data i rapporter och instrumentpaneler inte åt den underliggande datakällan. Power BI har stöd för enkel inloggningsautentisering för valda datakällor. Om anslutningen är konfigurerad för enkel inloggning används datauppsättningens ägares autentiseringsuppgifter 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 alla 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ändarna endast visa data som de har behörighet att komma åt. När anslutningen är till datakällor i molnet används Azure AD-autentisering för enkel inloggning. för lokala datakällor stöds Kerberos, Security Assertion Markup Language (SAML) och Azure AD.

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

Premium funktioner

Arkitektur för dataflöden

Dataflöden ger användarna möjlighet att konfigurera databearbetningsåtgärder på backend-servern som extraherar data från polymorfiska datakällor, kör transformeringslogik mot data och sedan hamnar i en målmodell för användning i olika tekniker för rapporteringspresentation. 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 de kanske inte gör ändringar i dess sammansättning. När ett dataflöde har redigerats kan alla medlemmar, deltagare eller administratörer för arbetsytan schemalägga uppdateringar, samt visa och redigera dataflödet genom att bli ägare till 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 är utformad för att matcha nödvändig implementeringsinformation för datakällan. Transformeringslogiken tillämpas Power Query tjänster medan data är i färd med att användas. För Premium-dataflöden Power Query-tjänster i backend-noder. Data kan hämtas direkt från molnkällorna eller via en gateway som installerats lokalt. När den hämtas direkt från en molnkälla till tjänsten eller till gatewayen använder transporten skyddsmetodik 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 bearbetning ovan.

När kundens angivna datakällor kräver autentiseringsuppgifter för åtkomst tillhandahåller ägaren/skaparen av dataflödet dem under redigeringen. De lagras med standardlagring av produktomfattande autentiseringsuppgifter. Se avsnittet Autentisering till datakällor ovan. Det finns olika metoder som användare kan konfigurera för att optimera datapersistence och åtkomst. Som standard placeras data i ett Power BI och skyddat lagringskonto. Storage kryptering har aktiverats på Blob Storage-containrar för att skydda data medan de är i vila. Se avsnittet Vilodata nedan. Användarna kan dock konfigurera ett eget lagringskonto som är associerat med sin egen Azure-prenumeration. När du gör det beviljas Power BI tjänsthuvudnamn åtkomst till det 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 icke-optimala för vissa data, har användarna också möjlighet att använda en Power BI värdbaserade 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 serversystemet. 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 dubbla kryptera den.

När du frågar med DirectQuery används DET krypterade transportprotokollet HTTPS för att få åtkomst till API:et. All sekundär eller indirekt användning av DirectQuery styrs av samma åtkomstkontroller som beskrevs tidigare. Eftersom dataflöden alltid är bundna till en arbetsyta, är åtkomsten till data alltid begränsad av användarens roll i arbetsytan. En användare måste minst ha 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 den först autentisera användaren med hjälp av Azure AD för att avgöra om användaren har tillräcklig behörighet för att visa data. I så fall förvärvas en SaS-nyckel och används för att få åtkomst till lagring direkt med hjälp av det krypterade transportprotokollet HTTPS.

Bearbetningen av data i hela pipelinen Office 365 granskningshändelser. Några 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 på en sida. De visar alla data i en tabell, även om tabellen sträcker sig över flera sidor. Rapporterna kallas också för pixelperfekta eftersom du kan kontrollera deras sidlayout i minsta detalj.

Sidnumrerade rapporter stöder omfattande och kraftfulla uttryck som skrivits i Microsoft Visual Basic .NET. Uttryck används mycket i rapporter i Power BI Paginated Report Builder för att hämta. beräkna, visa, gruppera, sortera, filtrera, parametrisera och formatera data.

Uttryck skapas av rapportens författare med åtkomst till de många funktionerna i .NET Framework. 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.

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

För Premium Gen1 finns en enda sandbox-miljö per var och en av klientorganisationens kapaciteter och delas av de arbetsytor som tilldelats till kapaciteten.

För Premium Gen2 skapas en individuell och exklusiv oanvänd sandbox-miljö för var och en av renderingarna av en rapport, vilket ger en högre isoleringsnivå mellan användare.

En sidnumrerad rapport kan komma åt en mängd olika datakällor som en del av rapportens återgivning. 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 autentiseringsuppgifter som krävs i anslutningen. På så sätt har sandbox-miljön aldrig åtkomst till 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 inbäddad 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 tillåts 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 hjälp av POST-meddelanden.

I ett scenario med inbäddning för din organisation får Azure AD-användare åtkomst till Power BI innehåll via portaler som anpassats av deras företag och IT.er. 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 kommer åt Power BI via Power BI-portalen eller via anpassade portaler.

I ett scenario med inbäddning för dina kunder äger ISV:er vanligtvis Power BI klientorganisation och Power BI (instrumentpaneler, rapporter, datauppsättningar osv.). Det är en ISV-backend-tjä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-backend för vidare distribution till slutanvändarna enligt ISV:s affärslogik. Slutanvändare som använder en webbläsare eller andra klientprogram kan inte dekryptera eller ändra inbäddningstoken. KLIENT-API:er på klientsidan, till exempel Power BI-API:er, lägger automatiskt till den krypterade inbäddningstoken till Power BI begäranden som ett Authorization: EmbedToken-huvud. Baserat på det här Power BI att tillämpa alla principer (till exempel åtkomst eller RLS) exakt som angavs av ISV:n under genereringen.

Om du vill aktivera inbäddning och automatisering, och generera de inbäddningstoken som beskrivs ovan, Power BI en omfattande uppsättning REST-API:er. Dessa Power BI REST-API:er stöder både användardelegering och Azure AD-metoder för autentisering och auktorisering för tjänstens huvudnamn.

Power BI inbäddad analys och dess REST-API:er stöder alla Power BI för nätverksisolering som beskrivs i den här artikeln: t.ex. tjänsttaggar och privata länkar.

AI-funktioner

Power BI stöder för närvarande två breda kategorier av AI-funktioner i produkten: AI-visualiseringar och AI-berikande. AI-funktionerna på visuell nivå innehåller funktioner som key-influencers, decomposition-tree, smart-narrative, anomaly-detection, R-visual, Python-visual, clustering, forecasting, Q&A, Quick-Insights osv. AI-berikningsfunktioner omfattar funktioner som AutoML, AzureML, CognitiveServices, R/Python-transformeringar osv.

De flesta av funktionerna som nämns ovan stöds i både delade och Premium arbetsytor i dag. AutoML och CognitiveServices stöds dock endast i Premium arbetsytor på grund av IP-begränsningar. Med AutoML-integrering i Power BI kan en användare idag skapa och träna en anpassad ML-modell (t.ex. förutsägelse, klassificering, regression osv.) och tillämpa den för att få förutsägelser vid inläsning av data i 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äses in i ett dataflöde/en datauppsättning som definierats i Premium arbetsyta.

Funktionerna Premium AI-berikning kan bäst ses som en samling tillståndslösa AI-funktioner/transformeringar som kan användas av Power BI-användare i deras pipelines för dataintegrering som används av en Power BI datauppsättning eller ett dataflöde. Observera att dessa funktioner också kan nås från aktuella dataflöden/redigeringsmiljöer för datauppsättningar i Power BI Service och Power BI Desktop. Dessa AI-funktioner/-transformeringar körs alltid i en Premium arbetsyta/kapacitet. Dessa funktioner visas i Power BI som en datakälla som kräver en Azure AD-token för Power BI som använder AI-funktionen. Dessa AI-datakällor är speciella eftersom de inte visar några av sina egna data och de bara 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 scenarier 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 AzureML-experimenteringstjänst 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 (t.ex. noggrannhet, ML-algoritm, algoritmparametrar osv.) från den föregående iterationen. AutoML-träningen skapar en ONNX-modell och träningsrapportdata som sedan sparas i dataflödet. Senare kan Power BI sedan tillämpa 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 istället ett internt 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 datauppsättningar. Vid redigering av en datauppsättning 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 autentiseringsuppgifter för Azure AD.

Nätverksisolering

Det här avsnittet beskriver 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 med 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änsttaggnamnet (t.ex. PowerBI) i lämplig källa eller målfält (för API:er) för en regel kan kunder tillåta eller neka trafiken för motsvarande tjänst. Microsoft hanterar de adressprefix 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 funktion som gör det Power BI att ge säker åtkomst via Azure-nätverkstjänster privata slutpunkter. Med Azure Private Link slutpunkter och privata slutpunkter skickas datatrafik privat med hjälp av Microsofts stamnätverksinfrastruktur, och därför skickas inte data via Internet.

Private Link ser till Power BI användarna använder Microsofts privata stamnät när de går till resurser i Power BI tjänsten.

Att 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 molnbaserade Azure-resurser.
• Isolering av nätverkstrafik från icke-Azure-baserad infrastruktur, till exempel lokal åtkomst, kräver att kunderna har ExpressRoute eller ett virtuellt privat nätverk (VPN) konfigurerat.

Se Privata länkar för att komma Power BI för ytterligare information.

VNet-anslutning (förhandsversion – kommer snart)

Även om Private Link-integrationsfunktionen ger säkra inkommande anslutningar till Power BI möjliggör funktionen för VNet-anslutning säkra utgående anslutningar från Power BI till datakällor i ett VNet.

VNet-gatewayer (Microsoft-hanterade) eliminerar arbetet med att installera och övervaka lokala datagatewayer för att ansluta till datakällor som är associerade med ett VNet. De kommer dock fortfarande att följa den välbekanta processen för att hantera säkerhet och datakällor, precis 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. Den 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 autentiseringsuppgifter till den virtuella Power Platform-tjänsten (PP VNet).

2. PP VNet-tjänsten matar sedan in en container som kör en VNet-gateway i undernätet på ett säkert sätt. 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 autentiseringsuppgifter 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 resultatet till VNet-gatewayen och PP VNet-tjänsten skickar data från containern till den virtuella Power BI tjänsten på ett säkert sätt.

Den här funktionen blir snart tillgänglig som offentlig förhandsversion.

Tjänstens huvudnamn

Power BI har stöd för användning av tjänstens huvudnamn. Lagra autentiseringsuppgifter för tjänstens huvudnamn som används för kryptering eller Power BI i en Key Vault, tilldela rätt åtkomstprinciper till valvet och granska regelbundet åtkomstbehörigheter.

Se Automatisera Premium och datauppsättningsuppgifter med tjänstens huvudnamn för mer information.

Dataförlustskydd (DLP)

Microsoft 365 känslighetsetiketter

Power BI har en djupgående integrering med känslighetsetiketter för Microsoft Information Protection (MIP), vilket gör det möjligt för organisationer att ha en enda integrerad lösning för hantering, granskning och efterlevnad av DLP-policyer i hela Office programsviten.

När känslighetsetiketter är aktiverade i Power BI:

• Känsliga data, både i Power BI-tjänsten och i Power BI Desktop, kan klassificeras och märkas med samma välbekanta Microsoft Information Protection känslighetsetiketter som används i Office och Azure Purview.
• Styrningsprinciper kan tillämpas även när Power BI-innehåll exporteras till Excel-, PowerPoint-, PDF- eller .pbix-filer för att säkerställa att data skyddas även när de Power BI.
• .pbix-filer kan krypteras enligt MIP-etikettprinciper när en MIP-etikett tillämpas på .pbix-filen i Desktop, vilket säkerställer att endast behöriga användare kan redigera den här filen.
• Det är enkelt att klassificera och skydda .pbix-filer precis som med filer Excel, Word och PowerPoint. Med bara två klickningar kan en fil taggas efter känslighetsnivå och krypteras ytterligare om den innehåller affärshemlighetsdata.
• Excel arbetsböcker ärver automatiskt känslighetsetiketterna när de ansluter till Power BI (förhandsversion), vilket gör det möjligt att upprätthålla klassificering från slut till slut och tillämpa skydd när Power BI-datauppsättningen analyseras i Excel.
• Känslighetsetiketter som tillämpas Power BI rapporter och instrumentpaneler visas i Power BI iOS- och Android-appar.
• Känslighetsetiketter bevaras när en Power BI rapport bäddas in i Teams, SharePoint eller en säker webbplats (förhandsversion). Detta hjälper organisationer att upprätthålla klassificering och skydd vid export vid inbäddning Power BI innehåll.
• Etikettarv när nytt innehåll skapas i Power BI-tjänsten säkerställer att etiketten som tillämpas på en datauppsättning i Power BI-tjänsten tillämpas på nytt innehåll som skapats ovanpå datauppsättningen.
• Power BI-API:er för administratörsgenomsökning kan extrahera en Power BI-artefakts känslighetsetikett, vilket gör att Power BI- och InfoSec-administratörer kan övervaka etiketter i Power BI-tjänsten och skapa chefsrapporter.
• Power BI ser till att endast behöriga användare kan ändra eller ta bort etiketter med skyddsinställningar i Power BI tjänsten.
• Kommer snart
  • Power BI administratörs-API:er för att tillämpa MIP-etiketter för att göra det möjligt för centrala team att programmatiskt märka innehåll Power BI tjänsten.
  • Administratörer kommer att kunna tillämpa etiketter på nytt eller redigerat innehåll med en obligatorisk etikettprincip i Power BI tjänsten (förhandsversion).
  • Automatisk etikettering av underordnade artefakter i Power BI tjänsten. När en etikett på en datauppsättning tillämpas eller ändras tillämpas etiketten automatiskt på allt nedströmsinnehåll som är anslutet till den här artefakten.

Mer information Microsoft Information Protection dokumentationen om känslighetsetiketter Power BI i dokumentationen.

Microsoft Cloud App Security (MCAS) för Power BI

Microsoft Cloud App Security är en av världens ledande a brokers för säkerhet för molnåtkomst, namngiven som ledare i Gartners Magic Quadrant för Cloud Access Security Broker (CASB)-marknaden. Cloud App Security används för att skydda användningen av molnappar. Det gör att organisationer kan övervaka och kontrollera riskfyllda sessioner i Power BI 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 Cloud App Security kan organisationer få följande DLP-funktioner:

• Ange realtidskontroller för att tillämpa riskfyllda användarsessioner i Power BI. Om en användare till exempel ansluter till Power BI utanför sitt land kan sessionen övervakas av Cloud App Security:s realtidskontroller och riskfyllda åtgärder, till exempel att ladda ned data som taggats med känslighetsetiketten "Strikt konfidentiell" kan blockeras omedelbart.
• Undersök Power BI användaraktivitet med Cloud App Security aktivitetsloggen. Aktivitetsloggen Cloud App Security innehåller Power BI-aktivitet som avbildas i Office 365-granskningsloggen, som innehåller information om alla användar- och administratörsaktiviteter, samt känslighetsetikettinformation för relevanta aktiviteter, till exempel tillämpa, ändra och ta bort etikett. Administratörer kan använda Cloud App Security avancerade filter och snabbåtgärder för effektiv problemundersökning.
• Skapa anpassade principer för att varna om misstänkt användaraktivitet i Power BI. Cloud App Security aktivitetsprincipfunktionen kan användas för att definiera egna anpassade regler, för att hjälpa dig att identifiera användarbeteende som avviker från normen och även eventuellt agera på det automatiskt om det verkar för riskabelt.
• Arbeta med Cloud App Security den inbyggda avvikelseidentifieringen. Cloud App Security:s principer för avvikelseidentifiering tillhandahåller direkt analys av användarbeteende och maskininlärning så att du redan från början är redo att köra avancerad hotidentifiering i molnmiljön. När en princip för avvikelseidentifiering identifierar ett misstänkt beteende utlöser den en säkerhetsavisering.
• Power BI administratörsrollen i Cloud App Security portalen. Cloud App Security tillhandahåller en appspecifik administratörsroll som kan användas för att bevilja Power BI-administratörer endast de behörigheter som de behöver för att få åtkomst till Power BI-relevanta data i portalen, till exempel aviseringar, användare i riskzonen, aktivitetsloggar och annan Power BI-relaterad information.

Se Använda Microsoft Cloud App Security-kontroller i Power BI för ytterligare information.

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 projicerade funktioner kan släppas senare än mars 2021 eller kanske inte släppas alls. Mer information om förhandsversioner finns i Villkor för Onlinetjänster.

Bring Your Own Log Analytics (BYOLA)

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.

Power BI säkerhetsfrågor och svar

Följande frågor är vanliga frågor och svar om säkerhet för Power BI. Dessa organiseras baserat på när de lades till i den här white paper, för att underlätta din möjlighet att snabbt hitta nya frågor och svar när det här dokumentet uppdateras. De nyaste frågorna läggs till i slutet av den här listan.

Hur ansluter användare 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 i företaget och behörigheter till dessa datakällor kan hanteras av gatewayadministratören. När du konfigurerar en datauppsättning kan användaren välja en autentiseringsuppgifterna från sitt personliga arkiv eller använda en lokal datagateway för att använda delade autentiseringsuppgifter.

  I importfallet upprättar en användare en anslutning baserat på användarens inloggning och kommer åt data med autentiseringsuppgifterna. När datauppsättningen har publicerats Power BI tjänsten Power BI alltid den här användarens autentiseringsuppgifter för att importera data. När data har importerats kommer visning av data i rapporter och instrumentpaneler inte åt den underliggande datakällan. Power BI har stöd för enkel inloggningsautentisering för valda datakällor. Om anslutningen är konfigurerad att använda enkel inloggning används datauppsättningens ägares autentiseringsuppgifter för att ansluta till datakällan.

  För rapporter som är anslutna till DirectQuery ansluts datakällan direkt med hjälp av en förkonfigurerad autentiseringsuppgifterna. De förkonfigurerade autentiseringsuppgifterna används för att ansluta till datakällan när alla 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 Azure AD-autentisering för enkel inloggning. för lokala datakällor stöds Kerberos, SAML och Azure AD.

  Vid anslutning med Kerberos skickas användarens UPN till gatewayen, och med kerberos-begränsad delegering personifieras användaren och ansluts till respektive datakällor. SAML stöds också på gatewayen för SAP HANA datakälla. 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, tillämpar Power BI-tjänsten den säkerheten på radnivå och användare som inte har tillräcklig behörighet för att komma åt underliggande data (som kan vara en fråga som används i en instrumentpanel, eller andra dataartefakter) ser inte data som användaren inte har tillräcklig behörighet för.

  Säkerhet på radnivå med Power BI kan användas för att begränsa dataåtkomst för givna användare. Filter begränsar dataåtkomsten på radnivå och du kan definiera filter i 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 förhindrar att obehöriga användare upptäcker ä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. För användare utan rätt åtkomstbehörighet finns helt enkelt inte skyddade tabeller och kolumner.

  Säkerhet på objektnivå, tillsammans med säkerhet på radnivå, ger förbättrad säkerhet i företagsklass för rapporter och datauppsättningar, 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 valts av kunden inte stöder HTTPS) för att ansluta från datakällan till Power BI-tjänsten. En säker anslutning upprättas med dataprovidern, och det är först när den anslutningen har upprättats som data överförs i nätverket.

Hur cachelagrar Power BI data för rapporter, instrumentpaneler eller modeller, och sker det på ett säkert sätt?

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

Cachelagrar klienter webbplatsdata lokalt?

• När webbläsarklienter använder Power BI anger Power BI-webbservrarna direktivet Cache-Control till no-store. Direktivet no-store instruerar webbläsare att inte cachelagra den webbplats som visas av användaren och att inte lagra webbplatsen i klientens cachemapp.

Vad gäller för 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 datakällor som inte aktiverats för säkerhet på rollnivå (RLS) gäller att om en instrumentpanel, rapport eller datamodell delas med andra användare via Power BI så är data tillgängliga för användare som de delas med för visning och interaktion. Power BI autentiserar inte användare på nytt mot den ursprungliga datakällan. När data har laddats upp till Power BI ansvarar den användare 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 datamängd visas eller läses i Power BI och använder data från den RLS-kompatibla datakällan läser Power BI-tjänsten datakällan för att hämta data baserat på användarens autentiseringsuppgifter. Om det finns tillräckligt med behörigheter läses data in i rapporten eller modellen för den användaren. Om autentiseringen misslyckas ser användaren 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, en funktion som gör att användarna kan skapa autentiseringsuppgifter för flera olika datakällor och sedan automatiskt använda dessa autentiseringsuppgifter vid åtkomst till alla 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 installation och konfiguration av gateway skriver administratören in en återställningsnyckel för gatewayen. Återställningsnyckeln används för att generera en stark symmetrisk AES-nyckel. En asymmetrisk RSA-nyckel skapas också samtidigt.

  De genererade nycklarna (RSA och AES) lagras i en fil som finns på den lokala datorn. Den filen krypteras också. Filens innehåll kan endast dekrypteras av den specifika Windows-datorn och endast av det specifika gatewaytjänstkontot.

  När en användare anger autentiseringsuppgifterna för datakällan i Power BI-tjänstens användargränssnitt krypteras autentiseringsuppgifterna med den offentliga nyckeln i webbläsaren. Gatewayen dekrypterar autentiseringsuppgifterna med hjälp av den privata RSA-nyckeln och krypterar om dem med en symmetrisk AES-nyckel innan data lagras i Power BI tjänsten. Med den här processen har Power BI-tjänsten 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 föredras eftersom det medför lägre omkostnader för kommunikation.

  • HTTPS – WebSockets över 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 sker är kommunikationen i stort sett via TCP + TLS. Du kan tvinga gatewayen att använda det här protokollet genom att ändra en inställning som beskrivs i artikeln om lokal gateway.

Vad har Azure CDN för funktion i Power BI?

• Som tidigare nämnts använder Power BI Azure Content Delivery Network (CDN) till att distribuera det statiska innehåll och de filer som behövs till användarna baserat på nationella inställningar. Närmare bestämt använder Power BI-tjänsten flera CDN för att effektivt distribuera statiskt innehåll och filer som behövs till användarna via offentligt Internet. Dessa statiska filer innefattar produktnedladdningar (till exempel Power BI Desktop, den lokala datagatewayen eller Power BI-appar från olika oberoende tjänstleverantörer), webbläsarkonfigurationsfiler som används för att initiera och upprätta efterföljande anslutningar med Power BI-tjänsten samt den första säkra inloggningssidan till Power BI.

  Baserat på information som uppges under den första anslutningen till Power BI-tjänsten kontaktar användarens webbläsare angivet Azure CDN (eller WFE för vissa av filerna) för att ladda ned samlingen av angivna delade filer som behövs för att aktivera webbläsarens interaktion med Power BI-tjänsten. Webbläsarsidan innehåller sedan Azure AD-token, sessionsinformation, platsen för det associerade serverklustret och den samling filer som laddats ned från Azure CDN- och WFE-klustret under hela Power BI-tjänstens webbläsarsession.

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

• Nej. Det är kundens ansvar att granska och avgöra huruvida koden för anpassade visuella objekt ska användas. All kod för anpassade visuella objekt används i en sandbox-miljö. Eventuell avvikande kod i ett anpassat objekt påverkar därför inte resten av Power BI-tjänst negativt.

Finns det andra visuella Power BI-objekt som skickar information utanför kundens nätverk?

• Ja. Bing Maps och visuella ESRI-objekt överför data ut ur Power BI-tjänsten för visuella objekt som använder dessa tjänster.

Utför Microsoft någon säkerhets- eller sekretessutvärdering 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 lita på den.

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 klienter i datacenter som finns i specifika geografiska områden för att säkerställa att data inte lämnar landsgränserna?

• En del kunder i vissa geografiska områden har ett alternativ för att skapa en klientorganisation i ett nationellt moln där lagring och bearbetning av data sker separat från alla andra datacenter. Nationella moln har en något annorlunda typ av säkerhet, eftersom en separat dataförvaltning använder Power BI-tjänsten för nationella moln för Microsofts räkning.

  Kunder kan också konfigurera en klientorganisation i en viss region. Sådana klientorganisationsklienter har dock ingen separat dataval från Microsoft. Priser för nationella moln skiljer sig från den allmänt tillgängliga kommersiella Power BI-tjänsten. Mer information om tillgänglighet för Power BI-tjänsten för nationella moln finns i Power BI för nationella moln.

Hur behandlar Microsoft anslutningar för kunder som har Power BI Premium prenumerationer? Skiljer sig dessa anslutningar från de som upprättas för den Premium Power BI tjänsten?

• Anslutningarna som upprättas för kunder med Power BI Premium-prenumerationer implementerar en B2B-auktoriseringsprocess (Business-to-Business) i Azure med hjälp av Azure AD 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 för andra Azure AD-användare.

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
• On-premises data gateway (Lokal datagateway)
• Nationella moln i Power BI
• Power BI Premium
• Översikt över enkel inloggning (SSO) för gatewayer i Power BI