Sicherheitsüberlegungen für die Datenverschiebung in Azure Data Factory

• Aktuelle Version

Gilt für: Azure Data Factory Azure Synapse Analytics

In diesem Artikel wird die grundlegende Sicherheitsinfrastruktur beschrieben, die Datenbewegungsdienste in Azure Data Factory verwenden, um Ihre Daten zu schützen. Data Factory-Verwaltungsressourcen basieren auf Azure Sicherheitsinfrastruktur und verwenden alle möglichen Sicherheitsmaßnahmen, die von Azure angeboten werden.

In einer Data Factory-Lösung erstellen Sie mindestens eine Pipeline. Bei einer Pipeline handelt es sich um eine logische Gruppierung von Aktivitäten, die zusammen eine Aufgabe bilden. Diese Pipelines befinden sich in der Region, in der die Data Factory erstellt wurde.

Obwohl Data Factory nur in einigen Regionen verfügbar ist, ist der Datenverschiebungsdienst weltweit verfügbar, um Datenkonformität, Effizienz und niedrigere Kosten für ausgehenden Netzwerkdatenverkehr sicherzustellen.

Azure Data Factory, einschließlich Azure Integration Runtime und Self-hosted Integration Runtime, speichert keine temporären Daten, Zwischenspeicher oder Protokolle, mit Ausnahme der Anmeldeinformationen verknüpfter Dienste für Cloud-Datenspeicher, die mithilfe von Zertifikaten verschlüsselt werden. Mit Data Factory können Sie datengesteuerte Workflows erstellen, um die Verschiebung von Daten zwischen unterstützten Datenspeichern und die Verarbeitung von Daten mithilfe von Computediensten in anderen Regionen oder in einer lokalen Umgebung zu orchestrieren. Sie können Workflows auch mithilfe von SDKs und Azure Monitor überwachen und verwalten.

Data Factory ist zertifiziert für:

Wenn Sie an Azure Compliance interessiert sind und wie Azure ihre eigene Infrastruktur sichert, besuchen Sie das Microsoft Trust Center. Die aktuelle Liste aller Azure Complianceangebote finden Sie unter https://aka.ms/AzureCompliance.

In diesem Artikel werden Sicherheitsüberlegungen zu den beiden folgenden Datenverschiebungsszenarien erläutert:

• Cloudszenario: In diesem Szenario sind sowohl Ihre Quelle als auch das Ziel über das Internet öffentlich zugänglich. Dazu gehören verwaltete Cloudspeicherdienste wie Azure Storage, Azure Synapse Analytics, Azure SQL-Datenbank, Azure Data Lake Store, Amazon S3, Amazon Redshift, SaaS-Dienste wie Salesforce und Webprotokolle wie FTP und OData. Eine vollständige Liste unterstützter Datenquellen finden Sie unter Unterstützte Datenspeicher und -formate.
• Hybridszenario: In diesem Szenario befindet sich entweder Ihre Quelle oder Ihr Ziel hinter einer Firewall oder in einem lokalen Unternehmensnetzwerk. Oder der Datenspeicher befindet sich in einem privaten oder virtuellen Netzwerk (meist die Quelle) und ist nicht öffentlich zugänglich. Zu diesem Szenario zählen auch Datenbankserver, die auf virtuellen Computern gehostet werden.

Cloudszenarien

Schützen von Datenspeicher-Anmeldeinformationen

• Speichern Sie verschlüsselte Anmeldeinformationen in einem Azure Data Factory verwalteten Speicher. Data Factory hilft, Ihre Datenspeicheranmeldeinformationen zu schützen, indem sie mit von Microsoft verwalteten Zertifikaten verschlüsselt werden. Diese Zertifikate werden alle zwei Jahre ausgetauscht (wozu Erneuerung der Zertifikate und Migration von Anmeldeinformationen gehören). Weitere Informationen zu Azure Storage Sicherheit finden Sie unter Azure Storage Sicherheitsübersicht.
• Speichern Sie Anmeldeinformationen in Azure Key Vault. Sie können die Anmeldeinformationen des Datenspeichers auch in Azure Key Vault speichern. Die Anmeldeinformationen werden dann von Data Factory beim Ausführen einer Aktivität abgerufen. Weitere Informationen finden Sie unter Anmeldeinformationen im Azure Key Vault speichern.

Durch die zentrale Speicherung geheimer Anwendungsschlüssel in Azure Key Vault können Sie deren Verteilung steuern. Key Vault reduziert erheblich die Wahrscheinlichkeit, dass Geheimnisse versehentlich durchleckt werden. Anstatt die Verbindungszeichenfolge im App-Code zu speichern, können Sie sie sicher in Key Vault speichern. Ihre Anwendungen können mithilfe von URIs sicher auf benötigte Informationen zugreifen. Diese URIs bieten den Anwendungen die Möglichkeit, bestimmte Versionen eines geheimen Schlüssels abzurufen. Es ist nicht erforderlich, benutzerdefinierten Code zu schreiben, um die in Key Vault gespeicherten geheimen Informationen zu schützen.

Datenverschlüsselung während der Übertragung

Wenn der Clouddatenspeicher HTTPS oder TLS unterstützt, erfolgen alle Datenübertragungen zwischen Datenverschiebungsdiensten in Data Factory und einem Clouddatenspeicher über einen sicheren Kanal (HTTPS oder TLS).

Datenverschlüsselung im Ruhezustand

Einige Datenspeicher unterstützen die Verschlüsselung von ruhenden Daten. Es empfiehlt sich, dass Sie einen Datenverschlüsselungsmechanismus für solche Datenspeicher aktivieren.

Azure Synapse Analytics

Transparent Data Encryption (TDE) in Azure Synapse Analytics bietet Schutz vor der Bedrohung durch schädliche Aktivitäten, indem die ruhenden Daten in Echtzeit ver- und entschlüsselt werden. Dieses Verhalten ist für den Client transparent. Weitere Informationen finden Sie unter Secure a database in Azure Synapse Analytics.

Azure SQL-Datenbank

Azure SQL-Datenbank unterstützt auch die transparente Datenverschlüsselung (TDE), die vor der Bedrohung bösartiger Aktivitäten schützt, indem die Daten in Echtzeit verschlüsselt und entschlüsselt werden, ohne dass Änderungen an der Anwendung erforderlich sind. Dieses Verhalten ist für den Client transparent. Weitere Informationen finden Sie unter Transparente Datenverschlüsselung für SQL-Datenbank und Data Warehouse.

Azure Data Lake Store

Azure Data Lake Store bietet auch Verschlüsselung für Daten, die im Konto gespeichert sind. Wenn diese Option aktiviert ist, verschlüsselt Data Lake Store automatisch Daten, bevor sie vor dem Abruf beibehalten und entschlüsselt werden, wodurch sie für den Client transparent ist, der auf die Daten zugreift. Weitere Informationen finden Sie unter Security in Azure Data Lake Store.

Azure Blob-Speicher und Azure Tabellenspeicher

Azure Blob-Speicher und Azure Tabellenspeicher unterstützen die Speicherdienstverschlüsselung (Storage Service Encryption, SSE), die Ihre Daten automatisch verschlüsselt, bevor sie vor dem Abruf gespeichert und entschlüsselt werden. Weitere Informationen finden Sie unter Azure Storage Service Encryption for Data at Rest.

Amazon S3

Amazon S3 unterstützt die Client- und Serververschlüsselung von ruhenden Daten. Weitere Informationen finden Sie unter Schutz von Daten mittels Verschlüsselung.

Amazon Redshift

Amazon Redshift unterstützt die Clusterverschlüsselung für ruhende Daten. Weitere Informationen finden Sie unter Amazon Redshift-Datenbankverschlüsselung.

Salesforce

Salesforce unterstützt Shield Platform Encryption, die eine Verschlüsselung aller Dateien, Anlagen und benutzerdefinierten Felder ermöglicht. Weitere Informationen finden Sie unter Grundlegendes zum OAuth-Webserver-Authentifizierungsfluss.

Hybridszenario

Hybridszenarien erfordern die selbst gehostete Integrationslaufzeit, die in einem lokalen Netzwerk, in einem virtuellen Netzwerk (Azure) oder in einer virtuellen privaten Cloud (Amazon) installiert werden muss. Die selbstgehostete Integrationslaufzeit muss auf die lokalen Datenspeicher zugreifen können. Weitere Informationen zur selbstgehosteten Integration Runtime finden Sie unter Erstellen und Konfigurieren einer selbstgehosteten Integrationslaufzeit.

Der Befehlskanal ermöglicht Kommunikation zwischen Datenverschiebungsdiensten in Data Factory und der selbstgehosteten Integration Runtime. Die Kommunikation enthält die Informationen, die sich auf die Aktivität beziehen. Der Datenkanal wird dazu verwendet, Daten zwischen lokalen Datenspeichern und Clouddatenspeichern zu übertragen.

Anmeldeinformationen für lokale Datenspeicher

Die Anmeldeinformationen können in Data Factory gespeichert oder während der Laufzeit von Azure Key Vault von Data Factory referenziert werden. Beim Speichern von Anmeldeinformationen innerhalb von Data Factory werden diese immer verschlüsselt auf der selbstgehosteten Integration Runtime gespeichert.

• Lokales Speichern von Anmeldeinformationen. Wenn Sie das Cmdlet Set-AzDataFactoryV2LinkedService mit den Verbindungszeichenfolgen und Anmeldeinformationen direkt inline im JSON verwenden, wird der verknüpfte Dienst verschlüsselt und für die selbstgehostete Integration Runtime gespeichert. In diesem Fall fließen die Anmeldeinformationen über Azure Back-End-Dienst, der äußerst sicher ist, an den selbst gehosteten Integrationscomputer, auf dem sie schließlich verschlüsselt und gespeichert wird. Die selbst gehostete Integrationslaufzeit verwendet Windows DPAPI zum Verschlüsseln der vertraulichen Daten und Anmeldeinformationen.

• Speichern von Anmeldeinformationen im Azure Key Vault. Sie können die Anmeldeinformationen des Datenspeichers auch in Azure Key Vault speichern. Die Anmeldeinformationen werden dann von Data Factory beim Ausführen einer Aktivität abgerufen. Weitere Informationen finden Sie unter Anmeldeinformationen in Azure Key Vault speichern.

• Anmeldeinformationen lokal speichern, ohne die Anmeldeinformationen über das Azure-Backend zur selbstgehosteten Integrationslaufzeit zu leiten. Wenn Sie Anmeldeinformationen lokal in der selbst gehosteten Integrationslaufzeit verschlüsseln und speichern möchten, ohne die Anmeldeinformationen über das Data Factory-Back-End fließen zu müssen, führen Sie die Schritte in Encrypt-Anmeldeinformationen für lokale Datenspeicher in Azure Data Factory aus. Diese Option wird von allen Anschlüssen unterstützt. Die selbst gehostete Integrationslaufzeit verwendet Windows DPAPI zum Verschlüsseln der vertraulichen Daten und Anmeldeinformationen.

• Verwenden Sie das Cmdlet New-AzDataFactoryV2LinkedServiceEncryptedCredential, um Anmeldeinformationen des verknüpften Diensts bzw. vertrauliche Details im verknüpften Dienst zu verschlüsseln. Anschließend können Sie den zurückgegebenen JSON-Code (mit dem EncryptedCredential-Element im Verbindungszeichenfolge) verwenden, um einen verknüpften Dienst mithilfe des Cmdlets Set-AzDataFactoryV2LinkedService zu erstellen.

Beim Verschlüsseln des verknüpften Diensts auf der selbstgehosteten Integration Runtime verwendete Ports

Wenn der Remotezugriff aus dem Intranet aktiviert ist, verwendet PowerShell standardmäßig Port 8060 auf dem Computer mit selbstgehosteter Integration Runtime für die sichere Kommunikation. Bei Bedarf kann dieser Port vom Integration Runtime Konfigurations-Manager auf der Registerkarte "Einstellungen" geändert werden:

Verschlüsselung während der Übertragung

Alle Datenübertragungen erfolgen über sicheres Kanal-HTTPS und TLS über TCP, um Man-in-the-Middle-Angriffe während der Kommunikation mit Azure-Diensten zu verhindern.

Sie können auch IPsec VPN oder Azure ExpressRoute verwenden, um den Kommunikationskanal zwischen Ihrem lokalen Netzwerk und Azure weiter zu sichern.

Azure Virtual Network ist eine logische Darstellung Ihres Netzwerks in der Cloud. Sie können ein lokales Netzwerk mit Ihrem virtuellen Netzwerk verbinden, indem Sie IPSec-VPN (Standort-zu-Standort) oder ExpressRoute (privates Peering) einrichten.

In der folgenden Tabelle sind die Empfehlungen für die Konfiguration von Netzwerk und selbstgehosteter Integrationslaufzeit zusammengefasst, die sich aus verschiedenen Kombinationen von Quell- und Zielstandort für hybride Datenverschiebung ergeben.

Die folgenden Bilder zeigen die Verwendung der selbst gehosteten Integrationslaufzeit zum Verschieben von Daten zwischen einer lokalen Datenbank und Azure Diensten mithilfe von ExpressRoute und IPsec VPN (mit Azure Virtual Network):

ExpressRoute

IPSec-VPN

Einrichten von Firewallkonfigurationen und Zulassungsliste für IP-Adressen

Firewallanforderungen für lokales/privates Netzwerk

In einem Unternehmen wird eine Unternehmensfirewall auf dem zentralen Router der Organisation ausgeführt. Windows Firewall wird als Daemon auf dem lokalen Computer ausgeführt, auf dem die selbst gehostete Integrationslaufzeit installiert ist.

Die folgende Tabelle enthält die Anforderungen für ausgehende Ports und die Domänenanforderungen für die Unternehmensfirewalls:

Die folgende Tabelle enthält Anforderungen an eingehende Ports für die Windows-Firewall.

Einrichten von Firewallkonfigurationen und Zulassungsliste in Datenspeichern

Einige Datenspeicher in der Cloud erfordern auch, dass die IP-Adresse des Computers, über den auf den Speicher zugegriffen wird, zugelassen wird. Stellen Sie sicher, dass die IP-Adresse des Computers der selbstgehosteten Integration Runtime in der Firewall ordnungsgemäß zugelassen bzw. konfiguriert ist.

Die folgenden Clouddatenspeicher erfordern, dass die IP-Adresse des Computers der selbstgehosteten Internet Runtime zugelassen wird. Einige dieser Datenspeicher erfordern standardmäßig möglicherweise keine Zulassungsliste.

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

Häufig gestellte Fragen

Kann die selbstgehostete Integration Runtime für unterschiedliche Data Factorys gemeinsam genutzt werden?

Ja. Ausführlichere Informationen finden Sie hier.

Welche Portanforderungen sind erforderlich, damit die selbstgehostete Integration Runtime funktioniert?

Die selbstgehostete Integration Runtime erstellt HTTP-basierte Verbindungen für den Zugriff auf das Internet. Der ausgehende Ports 443 muss geöffnet sein, damit die selbstgehostete Integration Runtime diese Verbindung herstellen kann. Öffnen Sie den eingehenden Port 8060 nur auf Computerebene (nicht auf Ebene der Unternehmensfirewall) für die Anwendung zur Anmeldeinformationsverwaltung. Wenn Azure SQL-Datenbank oder Azure Synapse Analytics als Quelle oder Ziel verwendet wird, müssen Sie auch Port 1433 öffnen. Weitere Informationen finden Sie im Abschnitt Einrichten von Firewallkonfigurationen und Zulassungsliste für IP-Adressen.

Zugehöriger Inhalt

Informationen zur Leistung der Azure Data Factory Kopieraktivität finden Sie im Handbuch zur Leistung und Optimierung der Kopieraktivität.