Säkerhetsöverväganden när du flyttar data i Azure Data Factory

• Aktuell version

GÄLLER FÖR: Azure Data Factory Azure Synapse Analytics

Dricks

Prova Data Factory i Microsoft Fabric, en allt-i-ett-analyslösning för företag. Microsoft Fabric omfattar allt från dataflytt till datavetenskap, realtidsanalys, business intelligence och rapportering. Lär dig hur du startar en ny utvärderingsversion kostnadsfritt!

Den här artikeln beskriver grundläggande säkerhetsinfrastruktur som dataflyttstjänster i Azure Data Factory använder för att skydda dina data. Data Factory-hanteringsresurser bygger på Azures säkerhetsinfrastruktur och använder alla möjliga säkerhetsåtgärder som erbjuds av Azure.

I en Data Factory-lösning skapar du en eller flera datapipelines. En pipeline är en logisk gruppering av aktiviteter som tillsammans utför en uppgift. Dessa pipelines finns i regionen där Data Factory-instansen skapades.

Även om Data Factory endast är tillgängligt i ett fåtal regioner är dataflytttjänsten tillgänglig globalt för att säkerställa dataefterlevnad, effektivitet och minskade kostnader för utgående nätverk.

Azure Data Factory, inklusive Azure Integration Runtime och Lokalt installerad integrationskörning, lagrar inte temporära data, cachedata eller loggar förutom länkade tjänstautentiseringsuppgifter för molndatalager som krypteras med hjälp av certifikat. Med Data Factory skapar du datadrivna arbetsflöden för att samordna förflyttning av data mellan datalager som stöds och bearbetning av data med hjälp av beräkningstjänster i andra regioner eller i en lokal miljö. Du kan också övervaka och hantera arbetsflöden med hjälp av SDK:er och Azure Monitor.

Data Factory har certifierats för:

CSA STAR-certifiering
ISO 20000-1:2011
ISO 22301:2012
ISO 27001:2013
ISO 27017:2015
ISO 27018:2014
ISO 9001:2015
SOC 1, 2, 3
HIPAA BAA
HITRUST

Om du är intresserad av Azure-efterlevnad och hur Azure skyddar sin egen infrastruktur kan du besöka Microsoft Trust Center. Den senaste listan över alla Azure Compliance-erbjudanden finns i – https://aka.ms/AzureCompliance.

I den här artikeln granskar vi säkerhetsöverväganden i följande två scenarier för dataflytt:

• Molnscenario: I det här scenariot är både källan och målet offentligt tillgängliga via Internet. Dessa omfattar hanterade molnlagringstjänster som Azure Storage, Azure Synapse Analytics, Azure SQL Database, Azure Data Lake Store, Amazon S3, Amazon Redshift, SaaS-tjänster som Salesforce och webbprotokoll som FTP och OData. Hitta en fullständig lista över datakällor som stöds i datalager och format som stöds.
• Hybridscenario: I det här scenariot ligger antingen källan eller målet bakom en brandvägg eller i ett lokalt företagsnätverk. Eller så finns datalagret i ett privat nätverk eller virtuellt nätverk (oftast källan) och är inte offentligt tillgängligt. Databasservrar som finns på virtuella datorer omfattas också av det här scenariot.

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Information om hur du kommer igång finns i Installera Azure PowerShell. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Molnscenarier

Skydda autentiseringsuppgifter för datalager

• Lagra krypterade autentiseringsuppgifter i ett hanterat Azure Data Factory-lager. Data Factory hjälper till att skydda dina autentiseringsuppgifter för datalager genom att kryptera dem med certifikat som hanteras av Microsoft. Dessa certifikat roteras vartannat år (vilket inkluderar certifikatförnyelse och migrering av autentiseringsuppgifter). Mer information om Azure Storage-säkerhet finns i Översikt över Azure Storage-säkerhet.
• Lagra autentiseringsuppgifter i Azure Key Vault. Du kan också lagra datalagrets autentiseringsuppgifter i Azure Key Vault. Data Factory hämtar autentiseringsuppgifterna under körningen av en aktivitet. Mer information finns i Lagra autentiseringsuppgifter i Azure Key Vault.

När dina programhemligheter lagras lokalt i Azure Key Vault kan du styra spridningen av dem. Key Vault minskar kraftigt risken för att hemligheter sprids av misstag. Istället för att lagra anslutningssträngen i appkoden så kan du lagra den säkert i Key Vault. Dina program får säker åtkomst till den information de behöver med hjälp av URI:er. Dessa URI:er gör det möjligt för programmen att hämta specifika versioner av en hemlighet. Du behöver inte skriva anpassad kod för att skydda någon hemlig information som lagras i Key Vault.

Datakryptering under överföring

Om molndatalagret stöder HTTPS eller TLS sker alla dataöverföringar mellan dataförflyttningstjänster i Data Factory och ett molndatalager via säker kanal HTTPS eller TLS.

Kommentar

Alla anslutningar till Azure SQL Database och Azure Synapse Analytics kräver kryptering (SSL/TLS) medan data överförs till och från databasen. När du redigerar en pipeline med hjälp av JSON lägger du till krypteringsegenskapen och anger den till true i niska veze. För Azure Storage kan du använda HTTPS i niska veze.

Kommentar

Om du vill aktivera kryptering under överföring när du flyttar data från Oracle följer du något av alternativen nedan:

1. I Oracle-servern går du till Oracle Advanced Security (OAS) och konfigurerar krypteringsinställningarna, som stöder Triple-DES Encryption (3DES) och Advanced Encryption Standard (AES), se här för mer information. ADF förhandlar automatiskt om krypteringsmetoden för att använda den som du konfigurerar i OAS när du upprättar en anslutning till Oracle.
2. I ADF kan du lägga till EncryptionMethod=1 i niska veze (i den länkade tjänsten). Detta använder SSL/TLS som krypteringsmetod. Om du vill använda detta måste du inaktivera icke-SSL-krypteringsinställningar i OAS på Oracle-serversidan för att undvika krypteringskonflikter.

Kommentar

TLS-versionen som används är 1.2.

Datakryptering i vila

Vissa datalager stöder kryptering av vilande data. Vi rekommenderar att du aktiverar datakrypteringsmekanismen för dessa datalager.

Azure Synapse Analytics

Transparent datakryptering (TDE) i Azure Synapse Analytics hjälper till att skydda mot hot om skadlig aktivitet genom att utföra realtidskryptering och dekryptering av dina vilande data. Det här beteendet är transparent för klienten. Mer information finns i Skydda en databas i Azure Synapse Analytics.

Azure SQL Database

Azure SQL Database har också stöd för transparent datakryptering (TDE), som hjälper till att skydda mot hot om skadlig aktivitet genom att utföra realtidskryptering och dekryptering av data, utan att kräva ändringar i programmet. Det här beteendet är transparent för klienten. Mer information finns i Transparent datakryptering för SQL Database och Data Warehouse.

Azure Data Lake Store

Azure Data Lake Store tillhandahåller även kryptering för data som lagras i kontot. När det är aktiverat krypterar Data Lake Store automatiskt data innan de bevaras och dekrypterar innan de hämtas, vilket gör dem transparenta för klienten som har åtkomst till data. Mer information finns i Säkerhet i Azure Data Lake Store.

Azure Blob Storage och Azure Table Storage

Azure Blob Storage och Azure Table Storage har stöd för Storage Service Encryption (SSE), som automatiskt krypterar dina data innan de bevaras till lagring och dekrypterar innan de hämtas. Mer information finns i Azure-kryptering för lagringstjänst för vilande data.

Amazon S3

Amazon S3 stöder både klient- och serverkryptering av vilande data. Mer information finns i Skydda data med kryptering.

Amazon Redshift

Amazon Redshift stöder klusterkryptering för vilande data. Mer information finns i Amazon Redshift Database Encryption.

Salesforce

Salesforce stöder Shield Platform Encryption som tillåter kryptering av alla filer, bifogade filer och anpassade fält. Mer information finns i Förstå webbserverns OAuth-autentiseringsflöde.

Hybridscenarier

Hybridscenarier kräver att lokalt installerad integreringskörning installeras i ett lokalt nätverk, i ett virtuellt nätverk (Azure) eller i ett virtuellt privat moln (Amazon). Den lokalt installerade integrationskörningen måste kunna komma åt de lokala datalager. Mer information om lokalt installerad integrationskörning finns i Skapa och konfigurera lokalt installerad integrationskörning.

Kommandokanalen tillåter kommunikation mellan dataförflyttningstjänster i Data Factory och lokalt installerad integrationskörning. Kommunikationen innehåller information som rör aktiviteten. Datakanalen används för att överföra data mellan lokala datalager och molndatalager.

Autentiseringsuppgifter för lokalt datalager

Autentiseringsuppgifterna kan lagras i datafabriken eller refereras av datafabriken under körningen från Azure Key Vault. Om du lagrar autentiseringsuppgifter i datafabriken lagras den alltid krypterad på den lokala integrationskörningen.

• Lagra autentiseringsuppgifter lokalt. Om du använder cmdleten Set-AzDataFactoryV2LinkedService direkt med niska veze och autentiseringsuppgifterna i JSON krypteras och lagras den länkade tjänsten på lokalt installerad integrationskörning. I det här fallet flödar autentiseringsuppgifterna via Azure-serverdelstjänsten, som är extremt säker, till den lokalt installerade integrationsdatorn där den slutligen krypteras och lagras. Den lokalt installerade integrationskörningen använder Windows DPAPI för att kryptera känslig data och information om autentiseringsuppgifter.

• Lagra autentiseringsuppgifter i Azure Key Vault. Du kan också lagra datalagrets autentiseringsuppgifter i Azure Key Vault. Data Factory hämtar autentiseringsuppgifterna under körningen av en aktivitet. Mer information finns i Lagra autentiseringsuppgifter i Azure Key Vault.

• Lagra autentiseringsuppgifter lokalt utan att flöda autentiseringsuppgifterna via Azure-serverdelen till den lokala integrationskörningen. Om du vill kryptera och lagra autentiseringsuppgifter lokalt på den lokala integrationskörningen utan att behöva flöda autentiseringsuppgifterna via datafabrikens serverdel följer du stegen i Kryptera autentiseringsuppgifter för lokala datalager i Azure Data Factory. Alla anslutningsappar stöder det här alternativet. Den lokalt installerade integrationskörningen använder Windows DPAPI för att kryptera känslig data och information om autentiseringsuppgifter.

• Använd cmdleten New-AzDataFactoryV2LinkedServiceEncryptedCredential för att kryptera länkade tjänstautentiseringsuppgifter och känslig information i den länkade tjänsten. Du kan sedan använda JSON som returneras (med encryptedCredential-elementet i niska veze) för att skapa en länkad tjänst med hjälp av cmdleten Set-AzDataFactoryV2LinkedService.

Portar som används vid kryptering av länkad tjänst på lokalt installerad integrationskörning

När fjärråtkomst från intranätet är aktiverat använder PowerShell som standard port 8060 på datorn med lokalt installerad integrationskörning för säker kommunikation. Om det behövs kan den här porten ändras från Integration Runtime Configuration Manager på fliken Inställningar:

Kryptering vid överföring

Alla dataöverföringar sker via säker kanal HTTPS och TLS via TCP för att förhindra man-in-the-middle-attacker under kommunikation med Azure-tjänster.

Du kan också använda IPSec VPN eller Azure ExpressRoute för att ytterligare skydda kommunikationskanalen mellan ditt lokala nätverk och Azure.

Azure Virtual Network är en logisk representation av nätverket i molnet. Du kan ansluta ett lokalt nätverk till ditt virtuella nätverk genom att konfigurera IPSec VPN (plats-till-plats) eller ExpressRoute (privat peering).

I följande tabell sammanfattas konfigurationsrekommendationerna för nätverks- och lokalt installerad integreringskörning baserat på olika kombinationer av käll- och målplatser för hybriddataflytt.

Källa	Mål	Konfiguration av nätverk	Installation av Integration Runtime
Lokal	Virtuella datorer och molntjänster som distribueras i virtuella nätverk	IPSec VPN (punkt-till-plats eller plats-till-plats)	Den lokalt installerade integrationskörningen bör installeras på en virtuell Azure-dator i det virtuella nätverket.
Lokal	Virtuella datorer och molntjänster som distribueras i virtuella nätverk	ExpressRoute (privat peering)	Den lokalt installerade integrationskörningen bör installeras på en virtuell Azure-dator i det virtuella nätverket.
Lokal	Azure-baserade tjänster som har en offentlig slutpunkt	ExpressRoute (Microsoft-peering)	Den lokalt installerade integrationskörningen kan installeras lokalt eller på en virtuell Azure-dator.

Följande bilder visar användningen av lokalt installerad integrationskörning för att flytta data mellan en lokal databas och Azure-tjänster med hjälp av ExpressRoute och IPSec VPN (med Azure Virtual Network):

Express Route

IPSec VPN

Brandväggskonfigurationer och tillåt listkonfiguration för IP-adresser

Kommentar

Du kan behöva hantera portar eller konfigurera listan över tillåtna för domäner på företagsbrandväggsnivå efter behov av respektive datakällor. Den här tabellen använder endast Azure SQL Database, Azure Synapse Analytics och Azure Data Lake Store som exempel.

Kommentar

Mer information om strategier för dataåtkomst via Azure Data Factory finns i den här artikeln.

Brandväggskrav för lokala/privata nätverk

I ett företag körs en företagsbrandvägg på organisationens centrala router. Windows-brandväggen körs som en daemon på den lokala datorn där den lokalt installerade integrationskörningen är installerad.

Följande tabell innehåller utgående port- och domänkrav för företagets brandväggar:

Domännamn	Utgående portar	beskrivning
*.servicebus.windows.net	443	Krävs av den lokalt installerade integrationskörningen för interaktiv redigering.
{datafactory}.{region}.datafactory.azure.net eller *.frontend.clouddatahub.net	443	Krävs av den lokalt installerade integrationskörningen för att ansluta till Data Factory-tjänsten. För nyskapad Data Factory hittar du FQDN från din lokalt installerad Integration Runtime-nyckel som är i formatet {datafactory}. {region}.datafactory.azure.net. Om du inte ser FQDN i din lokalt installerad integrationsnyckel för gamla datafabriker använder du *.frontend.clouddatahub.net i stället.
download.microsoft.com	443	Krävs av den lokalt installerade integrationskörningen för nedladdning av uppdateringarna. Om du har inaktiverat automatisk uppdatering kan du hoppa över att konfigurera den här domänen.
*.core.windows.net	443	Används av den lokalt installerade integrationskörningen för att ansluta till Azure Storage-kontot när du använder den mellanlagrade kopieringsfunktionen .
*.database.windows.net	1433	Krävs endast när du kopierar från eller till Azure SQL Database eller Azure Synapse Analytics och på annat sätt är valfritt. Använd funktionen för stegvis kopiering för att kopiera data till SQL Database eller Azure Synapse Analytics utan att öppna port 1433.
*.azuredatalakestore.net login.microsoftonline.com/<tenant>/oauth2/token	443	Krävs endast när du kopierar från eller till Azure Data Lake Store och annat valfritt.

Kommentar

Du kan behöva hantera portar eller konfigurera listan över tillåtna för domäner på företagsbrandväggsnivå efter behov av respektive datakällor. Den här tabellen använder endast Azure SQL Database, Azure Synapse Analytics och Azure Data Lake Store som exempel.

Följande tabell innehåller krav på inkommande portar för Windows-brandväggen:

Ingående portar	beskrivning
8060 (TCP)	Krävs av PowerShell-krypterings-cmdleten enligt beskrivningen i Kryptera autentiseringsuppgifter för lokala datalager i Azure Data Factory och av autentiseringshanterarens program för att på ett säkert sätt ange autentiseringsuppgifter för lokala datalager på den lokala integrationskörningen.

IP-konfigurationer och tillåt listkonfiguration i datalager

Vissa datalager i molnet kräver också att du tillåter IP-adressen för den dator som har åtkomst till arkivet. Kontrollera att IP-adressen för den lokalt installerade integrationskörningsdatorn tillåts eller konfigureras i brandväggen på rätt sätt.

Följande molndatalager kräver att du tillåter IP-adressen för den lokalt installerade integrationskörningsdatorn. Vissa av dessa datalager kräver som standard kanske inte tillåtna listor.

• Azure SQL Database
• Azure Synapse Analytics
• Azure Data Lake Store
• Azure Cosmos DB
• Amazon Redshift

Vanliga frågor och svar

Kan den lokalt installerade integrationskörningen delas mellan olika datafabriker?

Ja. Mer information finns här.

Vilka är portkraven för att den lokalt installerade integrationskörningen ska fungera?

Den lokalt installerade integrationskörningen gör HTTP-baserade anslutningar för åtkomst till Internet. De utgående portarna 443 måste öppnas för den lokalt installerade integrationskörningen för att anslutningen ska kunna upprättas. Öppna endast inkommande port 8060 på datornivå (inte på företagets brandväggsnivå) för program för autentiseringshanteraren. Om Azure SQL Database eller Azure Synapse Analytics används som källa eller mål måste du även öppna port 1433. Mer information finns i avsnittet Brandväggskonfigurationer och tillåt listkonfiguration för IP-adresser .

Relaterat innehåll

Information om prestanda för Kopieringsaktivitet i Azure Data Factory finns i prestanda- och justeringsguiden för kopieringsaktivitet.