Överväganden för dataexfiltrering och metodtips för dataflöden

Infrastrukturdataflöden och Power Platform-dataflöden är Microsoft 365-tjänster som gör det möjligt för användare att enkelt ansluta till, extrahera, flytta och transformera data över hundratals datakällor som stöds. Dataflöden bygger på en underliggande tjänst som heter Power Query Online, som är värd för dataflyttmotorn (Mashup Engine) som en molntjänst. Som standard kommer anslutningen från den här molnplatsen och har obegränsad åtkomst till Internet. När du använder dataflöden för att komma åt och flytta känsliga data bör organisationer därför överväga strategier för att avskräcka insiders från oavsiktlig eller skadlig dataexfiltrering. Den här artikeln beskriver kända riskfaktorer och metodtips för skydd.

Överväganden

Godtycklig körning av kod

Dataflödes-ETL-jobb definieras via program som skrivits på ett språk som kallas Power Query M. I sin standardkonfiguration kör Mashup Engine dessa program i molnet, utanför klientorganisationens nätverksgräns och med obegränsad internetåtkomst. Användare kan skapa program som ansluter till flera datakällor och efter medgivande tillåta att data flödar mellan dessa källor.

En betrodd användare som har åtkomst till känsliga data kan skapa ett program för att skicka data till ett datalager som inte är betrott. Eftersom Mashup-motorn körs helt i molnet går den inte igenom företagets brandväggar och proxyservrar. Därför omfattas den inte av några principer för dataförlustskydd (DLP) som kan tillämpas av dessa nätverk. Eftersom åtkomstpunkten finns på det offentliga Internet kan data resa till alla mål som användaren har åtkomst till – antingen via autentisering eller anonym åtkomst. Här följer några exempel på hur dessa program kan exfiltera känsliga data:

• Anonyma webbbegäranden: Genom att använda Web.Contents kan användare göra webbbegäranden med känsliga data i brödtexten i begäran.
• Filtrering och kopplingar mellan datakällor: Känsliga data kan användas som filtrerings- eller kopplingsvillkor mot en annan ej betrodd datakälla. Mer specifikt kan data resa till den ej betrodda datakällan i form av frågesträngar eller parametrar.
• Utdatamål: Med hjälp av Fabric-dataflöden kan användarna ange utdatamål för sina frågor och därmed överföra data till en lista över stödda datamål, vilket inkluderar Azure SQL-databaser och datalager, Fabric Lakehouses, datalager och KQL-databaser.

Dataflytt mellan hyresgäster

Kombinationsmotorn kräver att datakällor uttryckligen definieras innan anslutningar upprättas. Datakällorna är bundna till program med en typ- och sökvägsnyckel (till exempel SQL;contoso.database.windows.net). Den här bindningen ger organisationer möjlighet att styra vilka datakällor som tillåts genom filtrering baserat på datakällans sökvägar. Det finns dock vissa datakällor där sökvägen är vanlig för alla anslutningar och data endast segmenteras av klientorganisationen för den inloggade användarens OAuth-autentiseringsuppgifter. Det här scenariot skapar en riskfaktor för dataexfiltrering, där en användare loggar in på en högre säkerhetsklient och en lägre säkerhetsklient och flyttar data mellan dem. Den här exfiltreringen kan vanligtvis göras på två sätt:

• Utgående: En betrodd användare i en klientorganisation med högre säkerhet definierar ett dataflöde i den miljön och skapar en utdata destination till en tillåten datamottagare, men autentiserar mot datamottagaren med ett konto från en lägre säkerhetsklient.
• Inkommande: En användare i en klientorganisation med lägre säkerhet definierar ett dataflöde som läser data från en känslig datakälla i den högre säkerhetsklientorganisationen. Den här definitionen kan uppnås genom att autentisera mot den känsliga datakällan med hjälp av ett betrott konto i högre säkerhetstjänst.

Rekommenderade metodtips

DLP-principer kan användas i olika OSI-lager. I allmänhet, ju känsligare data, desto lägre lager där principerna måste tillämpas. Protokoll med lägre lager är vanligtvis dyrare att implementera, svårare att skala och svårare att använda. Organisationer med lägre styrningskrav kanske bara behöver tillämpa principer på programnivå. Vissa organisationer och entiteter som bearbetar mycket känsliga data kan dock kräva extrema åtgärder, till exempel fysisk isolering. Vi rekommenderar att organisationer som hanterar känsliga data använder en kombination av principer på program- och nätverksnivå för att skydda mot insiderhot.

Nätverksisolering

Vi rekommenderar att alla datalager som innehåller känsliga data är nätverksisolerade för att endast tillåta åtkomst från valda nätverk. Den här isoleringsbegränsningen måste definieras och användas på nätverksskiktet eller lägre. Till exempel är layer 3-brandväggar, nätverkssäkerhetsgrupper (NSG:er) och Privata Azure-länkar bra exempel på mekanismer som kan användas. Platsbaserade principer för villkorlig åtkomst i Microsoft Entra-ID fungerar dock på programnivå och anses otillräckliga för detta ändamål.

Dessa nätverksisoleringsprinciper måste hindra siktlinjen från dataflödens molnkörningsmotor till känsliga datalager (eftersom molnmotorn körs på det offentliga Internet). Dataflödens anslutning till dessa datalager tvingas sedan att komma från ett av de tillåtna nätverken genom att binda anslutningar till en lokal datagateway eller VNet-datagateway. En viktig utförandeegenskap för dataflöden är att molnbaserad utvärdering och gatewaybaserad utvärdering aldrig blandas. Om ett dataflöde behöver komma åt ett isolerat nätverksdatalager (och därför är bundet till en gateway) krävs all dataåtkomst för att flöda genom gatewayen. Eftersom gatewayer fysiskt finns i nätverk som styrs av användarklientorganisationen följer de dessutom nätverksnivåbegränsningar som brandväggar och DLP-skyddslösningar. Dessa begränsningar gör gatewaymiljöerna lika säkra och säkra som alla företagshanterade enheter och minskar riskerna med godtycklig kodkörning i en molnmiljö.

Det är värt att notera att nätverksisolering måste tillämpas på alla datalager som kan innehålla känsliga data. Tänk dig ett exempel där en användare skapar ett dataflöde för att läsa data från OneDrive för företag till Power BI. Sedan skapar användaren senare ett länkat dataflöde för att omvandla data i Power BI till underordnade entiteter. I det här scenariot räcker det inte att bara isolera OneDrive för företag till betrodda nätverk. Eftersom känsliga data också kan finnas i Power BI är det viktigt att isolera sådana data genom att aktivera privata länkar och inaktivera offentlig Internetåtkomst för Power BI. Läs mer om säker åtkomst till Power BI med hjälp av privata slutpunkter.

Tvinga gateway-körning

Målet med att isolera känsligt datalager till valda nätverk är att tvinga åtkomstens ursprung tillbaka till betrodda nätverk, så att befintliga principer som styr hanterade enheter kan användas för att styra dataflytt från dataflöden. I vissa fall kan det ta tid att utveckla, testa och distribuera en fullständig nätverksisoleringslösning. Alternativt kan du skicka ett supportärende för Dataflows för att tillämpa en princip för hela klientorganisationen som inaktiverar Mashup Engine. Den här principen påverkar alla frågeutvärderingar som använder Power Query Online Mashup Engine. Här är några av de funktioner som påverkas:

• Infrastrukturdataflöden
• Power Platform-dataflöden
• Dataflöden för datamanipulering i Azure Data Factory
• Dataflöden i Dynamics 365 (Customer Insights, Intelligent Order Management och så vidare)
• Power BI Datamart
• Snabbimport av Power BI från SharePoint

När principen har tillämpats misslyckas all molnbaserad körning med följande fel: Cloud evaluation request denied based on tenant policies. Please use a data gateway and try again. Det här felet tvingar effektivt alla frågeutvärderingar i klientorganisationen att ske på gatewayer, utan att först lansera en fullständig nätverksisoleringslösning. Observera att principen tillämpas på hela klientorganisationen och inte på en delmängd av arbetsbelastningar. Den här principen innebär att befintliga arbetsbelastningar misslyckas omedelbart och kräver manuella åtgärder för att konvertera till att köras på gatewayer. Organisationer som tillämpar den här principen bör också se till att de har tillräckligt med kapacitet i sina gatewaykluster för att hantera alla sina arbetsbelastningar.

Hyresgästisolering

För de flesta SaaS-lagerlager (software-as-a-service), till exempel Fabric Lakehouse och Power Platform Dataverse, finns det vanligtvis en slutpunkt för flera klientorganisationer som man kommunicerar med för att få åtkomst till data. Dessa slutpunkter är vanliga för alla användare av tjänsten, så de kan vara svåra att isolera och skydda enbart med hjälp av nätverksisoleringstekniker (Layer 3). Den rekommenderade metoden för den här typen av datalager är att använda Layer 7-principer, som vanligtvis tillhandahålls av Microsoft Entra ID:

• Tillåt endast Microsoft Entra-ID-autentisering. Ta bort autentiseringsscheman för anonyma och användarnamn/lösenord från datalagret.
• Använd platsprinciper för att tillåta inloggning till den skyddade klientorganisationen endast från hanterade enheter. Läs mer.
• Tillåt inte okända klientinloggningar från hanterade enheter med hjälp av klientbegränsningar för Microsoft Entra-ID. Använd klientbegränsningar för att hantera åtkomst till SaaS-appar. Läs mer.

Den här metoden begränsar åtkomsten till klientorganisationens känsliga datalager till en uppsättning hanterade enheter där inloggning till en annan klient inte är tillåten, vilket effektivt isolerar dataflytten i klientorganisationen.

Översikt

Följande lista innehåller några av de funktioner som för närvarande planeras för att hjälpa organisationer att bättre hantera dataexfiltreringsrisker i Fabric:

• Tillåtlistning av datakällanslutning: Tillåter Fabric-klientadministratörer att styra vilka typer av kopplingar som kan användas inom klienten och de slutpunkter som kopplingarna kan ansluta till.
• Granskning av anslutningsanvändning: Stöd för granskningsloggar som spårar skapande, uppdatering, borttagning och användning av anslutningar.