Whitepaper zur Azure Synapse Analytics-Sicherheit: Netzwerksicherheit

Hinweis

Dieser Artikel ist Teil der Artikelserie zum Whitepaper Azure Synapse Analytics-Sicherheit. Eine Übersicht über die Artikelserie finden Sie unter Whitepaper zur Azure Synapse Analytics-Sicherheit.

Um Azure Synapse zu schützen, gibt es eine Reihe von Netzwerksicherheitsoptionen zu berücksichtigen.

Terminologie zur Netzwerksicherheit

Dieser Eröffnungsabschnitt enthält eine Übersicht und Definitionen einiger wichtiger Azure Synapse-Begriffe im Zusammenhang mit der Netzwerksicherheit. Beachten Sie diese Definitionen beim Lesen dieses Artikels.

Synapse-Arbeitsbereich

Ein Synapse-Arbeitsbereich ist eine sicherungsfähige logische Sammlung aller von Azure Synapse angebotenen Dienste. Er umfasst dedizierte SQL-Pools (früher SQL DW), serverlose SQL-Pools, Apache Spark-Pools, Pipelines und andere Dienste. Bestimmte Netzwerkkonfigurationseinstellungen, z. B. IP-Firewallregeln, verwaltete virtuelle Netzwerke und genehmigte Mandanten für den Exfiltrationsschutz, werden auf Arbeitsbereichsebene konfiguriert und geschützt.

Synapse-Arbeitsbereichsendpunkte

Ein Endpunkt ist ein Punkt einer eingehenden Verbindung für den Zugriff auf einen Dienst. Jeder Synapse-Arbeitsbereich verfügt über drei unterschiedliche Endpunkte:

• Dedizierter SQL-Endpunkt für den Zugriff auf dedizierte SQL-Pools.
• Serverloser SQL-Endpunkt für den Zugriff auf serverlose SQL-Pools.
• Entwicklungsendpunkt für den Zugriff auf Apache Spark-Pools und Pipelineressourcen im Arbeitsbereich.

Diese Endpunkte werden automatisch erstellt, wenn der Synapse-Arbeitsbereich erstellt wird.

Synapse Studio

Synapse Studio ist eine sichere Web-Front-End-Entwicklungsumgebung für Azure Synapse. Sie unterstützt verschiedene Rollen, einschließlich Technische Fachkraft für Daten, Wissenschaftliche Fachkraft für Daten, Datenentwickler, Datenanalyst und Synapse-Administrator.

Sie können Synapse Studio verwenden, um verschiedene Daten- und Verwaltungsvorgänge in Azure Synapse durchzuführen, z. B.:

• Herstellen einer Verbindung mit dedizierten SQL-Pools, serverlosen SQL-Pools und das Ausführen von SQL-Skripts.
• Entwickeln und Ausführen von Notebooks in Apache Spark-Pools.
• Entwickeln und Ausführen von Pipelines.
• Überwachen dedizierter SQL-Pools, serverloser SQL-Pools, von Apache Spark-Pools und Pipelineaufträgen.
• Verwalten von Synapse RBAC-Berechtigungen von Arbeitsbereichselementen.
• Erstellen verwalteter privater Endpunktverbindungen mit Datenquellen und Senken.

Verbindungen mit Arbeitsbereichsendpunkten können mithilfe von Synapse Studio hergestellt werden. Außerdem ist es möglich, private Endpunkte zu erstellen, um sicherzustellen, dass die Kommunikation mit den Arbeitsbereichsendpunkten privat ist.

Zugriffs- und Firewallregeln für öffentliche Netzwerke

Standardmäßig sind die Arbeitsbereichsendpunkte öffentliche Endpunkte, wenn sie bereitgestellt werden. Der Zugriff auf diese Arbeitsbereichsendpunkte über ein beliebiges öffentliches Netzwerk ist aktiviert, einschließlich Netzwerken, die sich außerhalb der Organisation des Kunden befinden, ohne dass eine VPN- oder ExpressRoute-Verbindung mit Azure erforderlich ist.

Alle Azure-Dienste, einschließlich PaaS-Diensten wie Azure Synapse, werden durch DDoS-Basisschutz geschützt, um böswillige Angriffe abzumildern (Überwachung des aktiven Datenverkehrs, Always On-Erkennung und automatische Angriffsminderungen).

Der gesamte Datenverkehr an Arbeitsbereichsendpunkte – auch über öffentliche Netzwerke – wird während der Übertragung durch das TLS-Protokoll (Transport Level Security) verschlüsselt und geschützt.

Um vertrauliche Daten zu schützen, wird empfohlen, den öffentlichen Zugriff auf die Arbeitsbereichsendpunkte vollständig zu deaktivieren. Dadurch wird sichergestellt, dass auf alle Arbeitsbereichsendpunkte nur über private Endpunkte zugegriffen werden kann.

Das Deaktivieren des öffentlichen Zugriffs für alle Synapse-Arbeitsbereiche in einem Abonnement oder einer Ressourcengruppe wird erzwungen durch Zuweisen einer Azure-Richtlinie. Es ist auch möglich, den Zugriff über öffentliche Netzwerke auf Arbeitsbereichsbasis zu deaktivieren, basierend auf der Vertraulichkeit der vom Arbeitsbereich verarbeiteten Daten.

Wenn jedoch der öffentliche Zugriff aktiviert werden muss, wird dringend empfohlen, die IP-Firewallregeln so zu konfigurieren, dass eingehende Verbindungen nur aus der angegebenen Liste öffentlicher IP-Adressen zulässig sind.

Erwägen Sie die Aktivierung des öffentlichen Zugriffs, wenn die lokale Umgebung keinen VPN- oder ExpressRoute-Zugriff auf Azure hat und Zugriff auf die Arbeitsbereichsendpunkte erfordert. Geben Sie in diesem Fall eine Liste öffentlicher IP-Adressen der lokalen Rechenzentren und Gateways in den IP-Firewallregeln an.

Private Endpunkte

Ein privater Azure-Endpunkt ist eine virtuelle Netzwerkschnittstelle mit einer privaten IP-Adresse, die im eigenen Azure Virtual Network-Subnetz (VNet) des Kunden erstellt wird. Ein privater Endpunkt kann für jeden Azure-Dienst erstellt werden, der private Endpunkte unterstützt, z. B. Azure Synapse, dedizierte SQL-Pools (früher SQL DW), Azure SQL-Datenbanken, Azure Storage oder einen vom Azure Private Link-Dienst unterstützten Dienst in Azure.

Es ist möglich, für alle drei Synapse-Arbeitsbereichsendpunkte einzeln private Endpunkte im VNet zu erstellen. Auf diese Weise können drei private Endpunkte für drei Endpunkte eines Synapse-Arbeitsbereichs erstellt werden: einer für einen dedizierten SQL-Pool, einer für einen serverlosen SQL-Pool und einer für den Entwicklungsendpunkt.

Private Endpunkte bieten im Vergleich zu den öffentlichen Endpunkten viele Sicherheitsvorteile. Auf private Endpunkte in einem Azure VNet kann nur von folgenden Orten aus zugegriffen werden:

• Dasselbe VNet, das diesen privaten Endpunkt enthält.
• Regional oder global gepeerte Azure VNets.
• Lokale Netzwerke, die über ein VPN Gateway oder ExpressRoute mit Azure verbunden sind.

Der Hauptvorteil privater Endpunkte besteht darin, dass Arbeitsbereichsendpunkte nicht mehr für das öffentliche Internet verfügbar gemacht werden müssen. Je geringer die Exponiertheit, desto besser.

Das folgende Diagramm stellt private Endpunkte dar.

Das obige Diagramm stellt die folgenden Hauptaspekte dar:

Element	Beschreibung
	Arbeitsstationen innerhalb des Kunden-VNets greifen auf private Azure Synapse-Endpunkte zu.
	Peering zwischen Kunden-VNet und einem anderen VNet.
	Arbeitsstationen greifen aus dem gepeerten VNet auf die privaten Azure Synapse-Endpunkte zu.
	Lokales Netzwerk greift über VPN oder ExpressRoute auf die privaten Azure Synapse-Endpunkte zu.
	Arbeitsbereichsendpunkte werden dem VNet des Kunden über private Endpunkte mithilfe von Azure Private Link zugeordnet.
	Öffentlicher Zugriff ist im Synapse-Arbeitsbereich deaktiviert.

Im folgenden Diagramm ist ein privater Endpunkt einer Instanz einer PaaS-Ressource zugeordnet, anstatt dem gesamten Dienst. Bei einem Sicherheitsvorfall innerhalb des Netzwerks wird nur die zugeordnete Ressourceninstanz verfügbar gemacht, wodurch die Exponiertheit und Bedrohung durch Datenlecks und Exfiltration minimiert wird.

Das obige Diagramm stellt die folgenden Hauptaspekte dar:

Element	Beschreibung
	Der private Endpunkt im Kunden-VNet ist einem einzelnen dedizierten SQL-Poolendpunkt (früher SQL DW) in Arbeitsbereich A zugeordnet.
	Andere SQL-Poolendpunkte in den anderen Arbeitsbereichen (B und C) sind über diesen privaten Endpunkt nicht zugänglich, was die Exponiertheit minimiert.

Der private Endpunkt funktioniert über Microsoft Entra-Mandanten und -Regionen hinweg, sodass private Endpunkteverbindungen mit Synapse-Arbeitsbereichen mandanten- und regionsübergreifend erstellt werden können. In diesem Fall durchläuft er den Genehmigungsworkflow für private Endpunktverbindungen. Der Ressourcenbesitzer kontrolliert, welche privaten Endpunktverbindungen genehmigt oder verweigert werden. Der Ressourcenbesitzer besitzt die vollständige Kontrolle darüber, wer eine Verbindung mit seinen Arbeitsbereichen herstellen kann.

Das folgende Diagramm stellt einen Genehmigungsworkflow für private Endpunktverbindungen dar.

Das obige Diagramm stellt die folgenden Hauptaspekte dar:

Element	Beschreibung
	Auf den dedizierten SQL-Pool (früher SQL DW) in Arbeitsbereich A in Mandant A wird von einem privaten Endpunkt im Kunden-VNet in Mandant A zugegriffen.
	Auf denselben dedizierten SQL-Pool (früher SQL DW) in Arbeitsbereich A in Mandant A wird von einem privaten Endpunkt im Kunden-VNet in Mandant B über einen Workflow für die Verbindungsgenehmigung zugegriffen.

Verwaltetes VNet

Das Synapse-Feature für verwaltete VNets bietet eine vollständig verwaltete Netzwerkisolation für den Apache Spark-Pool und die Pipelinecomputeressourcen zwischen Synapse-Arbeitsbereichen. Sie kann zum Zeitpunkt der Erstellung des Arbeitsbereichs konfiguriert werden. Darüber hinaus bietet es noch Netzwerkisolation für Spark-Cluster innerhalb desselben Arbeitsbereichs. Jeder Arbeitsbereich verfügt über ein eigenes virtuelles Netzwerk, das vollständig von Synapse verwaltet wird. Das verwaltete VNet ist für die Benutzer nicht sichtbar, sodass sie keine Änderungen vornehmen können. Alle Pipeline- oder Apache Spark-Poolcomputeressourcen, die von Azure Synapse in einem verwalteten VNet hochgefahren werden, werden in einem eigenen VNet bereitgestellt. Auf diese Weise besteht vollständige Netzwerkisolation von anderen Arbeitsbereichen.

Durch diese Konfiguration entfällt die Notwendigkeit, VNets und Netzwerksicherheitsgruppen für den Apache Spark-Pool und die Pipelineressourcen zu erstellen und zu verwalten, wie dies in der Regel durch VNet-Einschleusung erfolgt.

Daher werden mehrinstanzenfähige Dienste in einem Synapse-Arbeitsbereich, z. B. dedizierte SQL-Pools und serverlose SQL-Pools, nicht im verwalteten VNet bereitgestellt.

Das folgende Diagramm stellt die Netzwerkisolation zwischen zwei verwalteten VNets der Arbeitsbereiche A und B mit ihren Apache Spark-Pools und Pipelineressourcen innerhalb der verwalteten VNets dar.

Verwaltete private Endpunktverbindung

Eine verwaltete private Endpunktverbindung ermöglicht Verbindungen mit jedem PaaS-Dienst von Azure (der Private Link unterstützt), sicher und nahtlos, ohne dass ein privater Endpunkt für diesen Dienst aus dem VNet des Kunden erstellt werden muss. Synapse erstellt und verwaltet den privaten Endpunkt automatisch. Diese Verbindungen werden von den Computeressourcen verwendet, die im verwalteten Synapse VNet bereitgestellt werden, z. B. Apache Spark-Pools und Pipelineressourcen, um eine private Verbindung mit den Azure PaaS-Diensten herzustellen.

Wenn Sie beispielsweise aus Ihrer Pipeline eine private Verbindung mit Ihrem Azure-Speicherkonto herstellen möchten, wird normalerweise ein privater Endpunkt für das Speicherkonto erstellt und eine selbstgehostete Integration Runtime verwendet, um eine Verbindung mit Ihrem privaten Speicherendpunkt herzustellen. Mit verwalteten Synapse VNets können Sie mithilfe der Azure Integration Runtime eine private Verbindung mit Ihrem Speicherkonto herstellen, indem Sie einfach eine verwaltete private Endpunktverbindung direkt mit diesem Speicherkonto herstellen. Bei diesem Ansatz ist keine selbstgehostete Integration Runtime erforderlich, um eine private Verbindung mit Ihren Azure PaaS-Diensten herzustellen.

Daher werden mehrinstanzenfähige Dienste in einem Synapse-Arbeitsbereich, z. B. dedizierte SQL-Pools und serverlose SQL-Pools, nicht im verwalteten VNet bereitgestellt. Daher verwenden sie nicht die mit verwalteten privaten Endpunktverbindungen, die im Arbeitsbereich für ausgehende Verbindungen erstellt wurden.

Das folgende Diagramm stellt einen verwalteten privaten Endpunkt dar, der aus einem verwalteten VNet in Arbeitsbereich A eine Verbindung mit einem Azure-Speicherkonto herstellt.

Erweiterte Spark-Sicherheit

Ein verwaltetes VNet bietet auch einige zusätzliche Vorteile für Apache Spark-Poolbenutzer. Sie müssen sich keine Gedanken über die Konfiguration eines festen Subnetzadressraums machen, wie dies bei der VNet-Einschleusung der Fall wäre. Azure Synapse übernimmt automatisch die dynamische Zuweisung dieser Adressräume für Workloads.

Darüber hinaus fungieren Spark-Pools als Auftragscluster. Dies bedeutet, dass jeder Benutzer bei der Interaktion mit dem Arbeitsbereich seinen eigenen Spark-Cluster erhält. Das Erstellen eines Spark-Pools innerhalb des Arbeitsbereichs sind Metadateninformationen für das, was dem Benutzer beim Ausführen von Spark-Workloads zugewiesen wird. Dies bedeutet, dass jeder Benutzer seinen eigenen Spark-Cluster in einem dedizierten Subnetz innerhalb des verwalteten VNets erhält, um Workloads auszuführen. Spark-Poolsitzungen desselben Benutzers werden auf denselben Computeressourcen ausgeführt. Durch die Bereitstellung dieser Funktionalität ergeben sich drei Hauptvorteile:

• Höhere Sicherheit durch Workloadisolation, basierend auf dem Benutzer.
• Reduzierung von „Noisy Neighbors“ (störenden Nachbarn).
• Höhere Leistung.

Schutz vor Datenexfiltration

Synapse-Arbeitsbereiche mit verwaltetem VNet verfügen über ein zusätzliches Sicherheitsfeature namens Schutz vor Datenexfiltration. Es schützt den gesamten von allen Azure Synapse-Diensten ausgehenden Datenverkehr, einschließlich dedizierter SQL-Pools, serverloser SQL-Pools, Apache Spark-Pools und Pipelines. Es wird konfiguriert, indem der Schutz vor Datenexfiltration auf Arbeitsbereichsebene (zum Zeitpunkt der Erstellung des Arbeitsbereichs) aktiviert wird, um die ausgehenden Verbindungen auf eine zulässige Liste von Microsoft Entra-Mandanten zu beschränken. Standardmäßig wird der Liste nur der Stammmandant des Arbeitsbereichs hinzugefügt, aber es ist möglich, die Liste der Microsoft Entra-Mandanten jederzeit nach der Erstellung des Arbeitsbereichs zu erweitern oder zu ändern. Das Hinzufügen zusätzlicher Mandanten ist ein Vorgang mit sehr hohen Berechtigungen, für den die RolleSynapse-Administrator erforderlich ist. Sie kontrolliert effektiv die Exfiltration von Daten aus Azure Synapse in andere Organisationen und Mandanten, ohne dass komplizierte Netzwerksicherheitsrichtlinien vorhanden sein müssen.

Für Arbeitsbereiche mit aktiviertem Schutz vor Datenexfiltration müssen Synapse-Pipelines und Apache Spark-Pools verwaltete private Endpunktverbindungen für alle ausgehenden Verbindungen verwenden.

Dedizierter SQL-Pool und serverloser SQL-Pool verwenden keine verwalteten privaten Endpunkte für ihre ausgehende Konnektivität. Ausgehende Verbindungen von SQL-Pools können jedoch nur mit den genehmigten Zielen hergestellt werden, bei denen es sich um die Ziele verwalteter privater Endpunktverbindungen handelt.

Private Link-Hubs für Synapse Studio

Synapse Private Link-Hubs ermöglichen eine sichere Verbindung mit Synapse Studio aus dem VNet des Kunden über Azure Private Link. Dieses Feature ist für Kunden nützlich, die über Synapse Studio aus einer kontrollierten und eingeschränkten Umgebung, in der der ausgehende Internetdatenverkehr auf eine begrenzte Anzahl von Azure-Diensten beschränkt ist, auf den Synapse-Arbeitsbereich zugreifen möchten.

Dies wird erreicht, indem eine Private Link-Hubressource und ein privater Endpunkt für diesen Hub aus dem VNet erstellt werden. Dieser private Endpunkt wird dann verwendet, um mithilfe des vollqualifizierten Domänennamens (Fully Qualified Domain Name, FQDN) von Studio (web.azuresynapse.net) mit einer privaten IP-Adresse aus dem VNet auf Studio zuzugreifen. Die Private Link-Hubressource lädt den statischen Inhalt von Synapse Studio über Azure Private Link auf die Arbeitsstation des Benutzers herunter. Darüber hinaus müssen separate private Endpunkte für die einzelnen Arbeitsbereichsendpunkte erstellt werden, um sicherzustellen, dass die Kommunikation mit den Arbeitsbereichsendpunkten privat ist.

Das folgende Diagramm stellt Private Link-Hubs für Synapse Studio dar.

Das obige Diagramm stellt die folgenden Hauptaspekte dar:

Element	Beschreibung
	Die Arbeitsstation in einem eingeschränkten Kunden-VNet greift über einen Webbrowser auf Synapse Studio zu.
	Ein privater Endpunkt, der für die Private Link-Hubsressource erstellt wurde, wird verwendet, um die statischen Studio-Inhalte mithilfe von Azure Private Link herunterzuladen.
	Private Endpunkte, die für Synapse-Arbeitsbereichsendpunkte erstellt wurden, greifen über Azure Private Links sicher auf die Arbeitsbereichsressourcen zu.
	Netzwerksicherheitsgruppen-Regeln im eingeschränkten Kundschafts-VNet lassen ausgehenden Datenverkehr über Port 443 auf eine begrenzte Anzahl von Azure-Diensten zu, z. B. Azure Resource Manager, Azure Front Door und Microsoft Entra ID.
	Netzwerksicherheitsgruppen-Regeln im eingeschränkten Kunden-VNet verweigern den gesamten anderen ausgehenden Datenverkehr aus dem VNet.
	Öffentlicher Zugriff ist im Synapse-Arbeitsbereich deaktiviert.

Dedizierter SQL-Pool (früher SQL DW)

Vor dem Azure Synapse-Angebot wurde ein Azure SQL Data Warehouse-Produkt mit dem Namen „SQL DW“ angeboten. Es wurde nun umbenannt in dedizierter SQL-Pool (früher SQL DW).

Dedizierter SQL-Pool (früher SQL DW) wird auf einem logischen Azure SQL-Server erstellt. Es handelt sich um ein sicherungsfähiges logisches Konstrukt, das als zentraler Verwaltungspunkt für eine Sammlung von Datenbanken fungiert, einschließlich SQL DW und anderer Azure SQL-Datenbanken.

Die meisten der wichtigsten Netzwerksicherheitsfeatures, die in den vorherigen Abschnitten dieses Artikels für Azure Synapse besprochen wurden, gelten ebenfalls für dedizierter SQL-Pool (früher SQL DW). Dazu gehören:

• IP-Firewallregeln
• Deaktivieren des Zugriffs über öffentliche Netzwerke
• Private Endpunkte
• Schutz vor Datenexfiltration durch Firewallregeln für ausgehenden Datenverkehr

Da dedizierter SQL-Pool (früher SQL DW) ein mehrinstanzenfähiger Dienst ist, wird er nicht in einem verwalteten VNet bereitgestellt. Dies bedeutet, dass einige der Features, z. B. verwaltetes VNet und verwaltete private Endpunktverbindungen, nicht darauf anwendbar sind.

Matrix der Netzwerksicherheitsfeatures

Die folgende Vergleichstabelle bietet eine allgemeine Übersicht über die Netzwerksicherheitsfeatures, die von den Azure Synapse-Angeboten unterstützt werden:

Feature	Azure Synapse Apache Spark-Pool	Azure Synapse: Dedizierter SQL-Pool	Azure Synapse: Serverloser SQL-Pool	Dedizierter SQL-Pool (früher SQL DW)
IP-Firewallregeln	Ja	Ja	Ja	Ja
Deaktivieren des öffentlichen Zugriffs	Ja	Ja	Ja	Ja
Private Endpunkte	Ja	Ja	Ja	Ja
Schutz vor Datenexfiltration	Ja	Ja	Ja	Ja
Schützen des Zugriffs mit Synapse Studio	Ja	Ja	Ja	Nein
Zugriff aus eingeschränktem Netzwerk mithilfe des Private Link-Hubs von Synapse	Ja	Ja	Ja	Nein
Verwaltetes VNet und Netzwerkisolation auf Arbeitsbereichsebene	Ja	–	–	–
Verwaltete private Endpunktverbindungen für ausgehende Verbindungen	Ja	–	–	–
Netzwerkisolation auf Benutzerebene	Ja	–	–	–

Nächste Schritte

Im nächsten Artikel dieser Whitepaperserie erfahren Sie mehr über Bedrohungsschutz.