Whitepaper zur Sicherheit von Azure Synapse Analytics: Netzwerksicherheit

Um Azure Synapse zu sichern, gibt es eine Reihe von Optionen für die Netzwerksicherheit.

Netzwerksicherheitsterminologie

Dieser Abschnitt 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 Dienste, die von Azure Synapse angeboten werden. Es umfasst dedizierte SQL-Pools (vormals SQL DW), serverlose SQL-Pools, Apache Spark-Pools, Pipelines und andere Dienste. Bestimmte Netzwerkkonfigurationseinstellungen, z. B. IP-Firewallregeln, verwaltetes virtuelles Netzwerk und genehmigte Mandanten zum Exfiltrationsschutz, werden auf Arbeitsbereichsebene konfiguriert und gesichert.

Synapse-Arbeitsbereichsendpunkte

Ein Endpunkt ist ein Punkt einer eingehenden Verbindung, um auf einen Dienst zuzugreifen. Jeder Synapse-Arbeitsbereich weist drei unterschiedliche Endpunkte auf:

• 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. Er unterstützt verschiedene Rollen, darunter dateningenieur, Data Scientist, Datenentwickler, Datenanalyst und Synapse-Administrator.

Verwenden Sie Synapse Studio, um verschiedene Daten- und Verwaltungsvorgänge in Azure Synapse auszuführen, z. B.:

• Herstellen einer Verbindung mit dedizierten SQL-Pools, serverlosen SQL-Pools und Ausführen von SQL-Skripts.
• Entwickeln und Ausführen von Notizbüchern in Apache Spark-Pools.
• Entwickeln und Ausführen von Pipelines.
• Überwachen dedizierter SQL-Pools, serverloser SQL-Pools, Apache Spark-Pools und Pipelineaufträge.
• Verwalten von Synapse RBAC-Berechtigungen für Arbeitsbereichselemente.
• Erstellen verwalteter privater Endpunktverbindungen mit Datenquellen und Senken.

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

Zugriffsregeln für öffentliche Netzwerke und Firewall

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 außerhalb der Organisation des Kunden, ohne dass eine VPN-Verbindung oder eine ExpressRoute-Verbindung mit Azure erforderlich ist.

Alle Azure-Dienste, einschließlich PaaS-Dienste wie Azure Synapse, werden durch den grundlegenden DDoS-Schutz geschützt, um böswillige Angriffe zu mindern (aktive Datenverkehrsüberwachung, immer auf Erkennung und automatische Angriffsminderungen).

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

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

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

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

Erwägen Sie die Aktivierung des öffentlichen Zugriffs, wenn die lokale Umgebung keinen VPN-Zugriff oder ExpressRoute auf Azure hat und Zugriff auf die Arbeitsbereichsendpunkte erfordert. Geben Sie in diesem Fall eine Liste der öffentlichen 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 (VNet)-Subnetz 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 (vormals SQL DW), Azure SQL-Datenbanken, Azure Storage oder einen beliebigen Dienst in Azure, der vom Azure Private Link-Dienst unterstützt wird.

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

Private Endpunkte haben im Vergleich zu den öffentlichen Endpunkten viele Sicherheitsvorteile. Private Endpunkte in einem Azure VNet können nur von innerhalb des Netzwerks aus zugegriffen werden.

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

Der Hauptvorteil privater Endpunkte besteht darin, dass es nicht mehr erforderlich ist, Arbeitsbereichsendpunkte für das öffentliche Internet verfügbar zu machen. Je weniger Belichtung, desto besser.

Das folgende Diagramm zeigt private Endpunkte.

Das obige Diagramm zeigt die folgenden wichtigen Punkte:

Element	Beschreibung
	Arbeitsstationen aus dem VNet des Kunden greifen auf die privaten Azure Synapse-Endpunkte zu.
	Peering zwischen Kunden-VNet und einem anderen VNet.
	Arbeitsstationen aus einem Peered-VNet greifen auf die privaten Azure Synapse-Endpunkte zu.
	Lokaler Netzwerkzugriff auf die privaten Azure Synapse-Endpunkte über VPN oder ExpressRoute.
	Arbeitsbereichsendpunkte werden dem VNet des Kunden über private Endpunkte mithilfe des Azure Private Link-Diensts zugeordnet.
	Der öffentliche Zugriff ist im Synapse-Arbeitsbereich deaktiviert.

Im folgenden Diagramm wird ein privater Endpunkt einer Instanz einer PaaS-Ressource anstelle des gesamten Diensts zugeordnet. Im Falle eines Sicherheitsvorfalls innerhalb des Netzwerks wird nur die zugeordnete Ressourceninstanz verfügbar gemacht, wodurch die Gefährdung und Bedrohung von Datenlecks und Exfiltration minimiert wird.

Das obige Diagramm zeigt die folgenden wichtigen Punkte:

Element	Beschreibung
	Der private Endpunkt im VNet des Kunden wird einem einzelnen dedizierten SQL-Poolendpunkt (ehemals SQL DW) in Arbeitsbereich A zugeordnet.
	Auf andere SQL-Poolendpunkte in den anderen Arbeitsbereichen (B und C) kann nicht über diesen privaten Endpunkt zugegriffen werden, wodurch die Angreifbarkeit minimiert wird.

Privater Endpunkt funktioniert über Microsoft Entra-Mandanten und Regionen hinweg, sodass es möglich ist, private Endpunktverbindungen zu Synapse-Arbeitsbereichen über Mandanten und Regionen hinweg zu erstellen. In diesem Fall durchläuft der Prozess den Genehmigungsworkflow für private Endpunkte. Der Ressourcenbesitzer steuert, welche privaten Endpunktverbindungen genehmigt oder verweigert werden. Der Ressourcenbesitzer hat die vollständige Kontrolle darüber, wer eine Verbindung mit seinen Arbeitsbereichen herstellen kann.

Das folgende Diagramm zeigt einen Workflow für die Genehmigung privater Endpunktverbindungen.

Das obige Diagramm zeigt die folgenden wichtigen Punkte:

Element	Beschreibung
	Auf einen dedizierten SQL-Pool (früher SQL DW) in Arbeitsbereich A in Mandant A wird über einen privaten Endpunkt im VNet des Kunden in Mandant A zugegriffen.
	Auf denselben dedizierten SQL-Pool (früher SQL DW) in Arbeitsbereich A in Mandant A wird über einen Verbindungsgenehmigungsworkflow über einen privaten Endpunkt im Kunden-VNet in Mandant B 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. Die Konfiguration kann bei der Erstellung des Arbeitsbereichs erfolgen. Darüber hinaus stellt sie die Netzwerkisolation für Spark-Cluster innerhalb desselben Arbeitsbereichs bereit. 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, um Änderungen vorzunehmen. Alle von Azure Synapse in einem verwalteten VNet hochgefahrenen Pipeline- oder Apache Spark-Cluster-Rechenressourcen werden innerhalb ihres eigenen VNets bereitgestellt. Auf diese Weise gibt es eine 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 mehrere Mandantendienste in einem Synapse-Arbeitsbereich, z. B. dedizierte SQL-Pools und serverlose SQL-Pools, nicht innerhalb des verwalteten VNet bereitgestellt.

Das folgende Diagramm zeigt die Netzwerkisolation zwischen zwei verwalteten VNets von Arbeitsbereichen A und B mit ihren Apache Spark-Pools und Pipelineressourcen innerhalb der verwalteten VNets.

Verwaltete private Endpunktverbindung

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

Wenn Sie beispielsweise private Verbindungen mit Ihrem Azure-Speicherkonto aus Ihrer Pipeline herstellen möchten, besteht der übliche Ansatz darin, einen privaten Endpunkt für das Speicherkonto zu erstellen und eine selbst gehostete Integrationslaufzeit zu verwenden, um eine Verbindung mit Ihrem privaten Speicherendpunkt herzustellen. Mit Synapse Managed VNets können Sie eine private Verbindung mit Ihrem Speicherkonto mithilfe der Azure-Integrationslaufzeit herstellen, indem Sie einfach eine verwaltete private Endpunktverbindung direkt mit diesem Speicherkonto erstellen. Dieser Ansatz beseitigt die Notwendigkeit, eine selbst gehostete Integrationslaufzeit zu haben, um private Verbindungen mit Ihren Azure PaaS-Diensten herzustellen.

Daher werden mehrere Mandantendienste in einem Synapse-Arbeitsbereich, z. B. dedizierte SQL-Pools und serverlose SQL-Pools, nicht innerhalb des verwalteten VNet bereitgestellt. Daher verwenden sie nicht die verwalteten privaten Endpunktverbindungen, die im Arbeitsbereich für ihre ausgehende Verbindung erstellt wurden.

Das folgende Diagramm zeigt einen verwalteten privaten Endpunkt, der eine Verbindung mit einem Azure-Speicherkonto über ein verwaltetes VNet in Arbeitsbereich A herstellt.

Erweiterte Spark-Sicherheit

Ein verwaltetes VNet bietet auch einige zusätzliche Vorteile für Apache Spark Pool-Benutzer. Es ist nicht erforderlich, sich Gedanken über das Konfigurieren eines festen Subnetzadressraums zu machen, wie es in VNet Injection der Fall wäre. Azure Synapse kümmert sich automatisch um die dynamische Zuordnung dieser Adressräume für Workloads.

Darüber hinaus werden Spark-Pools als Job-Cluster verwendet. Dies bedeutet, dass jeder Benutzer seinen eigenen Spark-Cluster erhält, wenn er mit dem Arbeitsbereich interagiert. 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 VNet erhält, um Workloads auszuführen. "Spark-Pool-Sitzungen desselben Benutzers werden auf denselben Computing-Ressourcen ausgeführt." Durch die Bereitstellung dieser Funktionalität gibt es drei Hauptvorteile:

• Höhere Sicherheit aufgrund der nutzerbasierten Workloadisolation.
• Reduzierung von lauten Nachbarn.
• Höhere Leistung.

Schutz vor Datenexfiltration

Synapse-Arbeitsbereiche mit verwaltetem VNet verfügen über ein zusätzliches Sicherheitsfeature, das als Datenexfiltrationsschutz bezeichnet wird. Er schützt den gesamten Ausgehenden Datenverkehr aus Azure Synapse vor allen Diensten, einschließlich dedizierter SQL-Pools, serverloser SQL-Pools, Apache-Sparkpools und Pipelines. Die Konfiguration erfolgt durch Aktivieren des Schutzes gegen Datenexfiltration auf Arbeitsbereichsebene (bei der Erstellung des Arbeitsbereichs), um die ausgehenden Verbindungen auf eine zulässige Liste von Microsoft Entra-Mandanten einzuschränken. Standardmäßig wird nur der Heimmandant des Arbeitsbereichs der Liste hinzugefügt, aber es ist möglich, die Liste der Microsoft Entra-Mandanten jederzeit hinzuzufügen oder zu ändern, nachdem der Arbeitsbereich erstellt wurde. Das Hinzufügen zusätzlicher Mandanten ist ein stark privilegierter Vorgang, der die höhere Rolle des Synapse-Administrators erfordert. Sie steuert 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 Datenexfiltrationsschutz 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; Allerdings können alle ausgehenden Verbindungen aus SQL-Pools nur an den genehmigten Zielen vorgenommen werden, bei denen es sich um die Ziele von verwalteten privaten Endpunktverbindungen handelt.

Private Link Hubs für Synapse Studio

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

Es wird erreicht, indem eine private Link Hub-Ressource und ein privater Endpunkt für diesen Hub über das VNet erstellt werden. Dieser private Endpunkt wird dann verwendet, um mithilfe seines vollqualifizierten Domänennamens (Fully Qualified Domain Name, FQDN) auf das Studio zuzugreifen, web.azuresynapse.net mit einer privaten IP-Adresse aus dem VNet. Die Private Link Hub-Ressource lädt den statischen Inhalt von Synapse Studio über azure Private Link zur 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 zeigt private Linkhubs für Synapse Studio.

Das obige Diagramm zeigt die folgenden wichtigen Punkte:

Element	Beschreibung
	Die Arbeitsstation in einem eingeschränkten Kunden-VNet greift mithilfe eines Webbrowsers auf das Synapse Studio zu.
	Ein für die Private Link-Hub-Ressource erstellter privater Endpunkt wird verwendet, um die statischen Studioinhalte mithilfe von Azure Private Link herunterzuladen.
	Private Endpunkte, die für Synapse-Arbeitsbereichsendpunkte erstellt wurden, greifen sicher mithilfe von Azure Private Links auf die Arbeitsbereichsressourcen zu.
	Netzwerksicherheitsgruppenregeln im eingeschränkten Kunden-VNet ermöglichen ausgehenden Datenverkehr über Port 443 zu einer begrenzten Gruppe von Azure-Diensten, 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.
	Der öffentliche 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 namens SQL DW angeboten. Sie wird jetzt als dedizierter SQL-Pool (ehemals SQL DW) umbenannt.

Dedizierter SQL-Pool (ehemals SQL DW) wird innerhalb eines logischen Azure SQL-Servers erstellt. Es handelt sich um ein sicherungsfähiges logisches Konstrukt, das als zentraler Administrativer Punkt für eine Sammlung von Datenbanken, einschließlich SQL DW und anderen Azure SQL-Datenbanken, fungiert.

Die meisten der wichtigsten Netzwerksicherheitsfeatures, die in den vorherigen Abschnitten dieses Artikels für Azure Synapse erläutert werden, gelten auch für dedizierten SQL-Pool (früher SQL DW). Dazu gehören:

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

Matrix der Netzwerksicherheitsmerkmale

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

Nächste Schritte

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