Verwenden von Virtual Network-Dienstendpunkten und -Regeln für Azure Synapse Analytics

Gilt für: Dedizierte SQL-Pools in Azure Synapse Analytics

Die Regeln für virtuelle Netzwerke sind eine Firewall-Sicherheitsfunktion, die steuert, ob der logische Server für Ihre dedizierten SQL-Pool-Datenbanken (früher SQL DW) in Azure Synapse Analytics Kommunikationen von bestimmten Subnetzen in virtuellen Netzwerken akzeptiert. Dieser Artikel erklärt, warum virtuelle Netzwerkregeln manchmal die beste Option sind, um die Kommunikation mit Ihrem dedizierten SQL-Pool sicher zu ermöglichen.

Um eine virtuelle Netzwerkregel zu erstellen, muss es zunächst einen virtuellen Netzwerkdienst-Endpunkt geben, auf den die Regel verweisen kann.

Erstellen einer Regel für ein virtuelles Netzwerk

Wenn Sie nur eine virtuelle Netzwerkregel erstellen möchten, können Sie später in diesem Artikel zu den Schritten und Erklärungen springen.

Details zu den Regeln für virtuelle Netzwerke

Dieser Abschnitt beschreibt mehrere Details zu den Regeln virtueller Netzwerke.

Nur eine geografische Region

Jeder virtuelle Netzwerk-Service-Endpunkt gilt nur für eine Azure-Region. Der Endpunkt ermöglicht anderen Regionen nicht das Akzeptieren von Kommunikation aus dem Subnetz.

Jede virtuelle Netzwerkregel ist auf die Region beschränkt, der ihr zugrunde liegender Endpunkt zugeordnet ist.

Serverebene, nicht Datenbankebene

Jede virtuelle Netzwerkregel gilt für deinen gesamten Server, nicht nur für eine bestimmte Datenbank auf dem Server. Mit anderen Worten: Die Regeln für virtuelle Netzwerke gelten auf Serverebene, nicht auf Datenbankebene.

Rollen in der Sicherheitsverwaltung

Es gibt eine Trennung der Sicherheitsrollen bei der Verwaltung virtueller Netzwerkservice-Endpunkte. Jede der folgenden Rollen muss tätig werden:

• Netzwerkadministrator (Rolle Netzwerkmitwirkender): Aktivieren des Endpunkts.
• Datenbankadministrator (Rolle Mitwirkender von SQL Server): Aktualisieren der Zugriffssteuerungsliste, um das angegebene Subnetz dem Server hinzuzufügen.

Azure RBAC-Alternative

Die Rollen des Netzwerkadministrators und des Datenbankadministrators verfügen über mehr Funktionen, als zur Verwaltung virtueller Netzwerkregeln erforderlich sind. Es wird nur ein Teil ihrer Funktionen benötigt.

Sie haben die Möglichkeit, rollenbasierte Zugriffskontrolle (RBAC) in Azure zu verwenden, um eine einzelne benutzerdefinierte Rolle zu erstellen, die nur die notwendige Teilmenge an Funktionen besitzt. Die benutzerdefinierte Rolle kann definiert werden, anstatt den Netzwerk- oder Datenbankadministrator einzubeziehen. Die auf die Sicherheit bezogene Angriffsfläche ist kleiner, wenn Sie einen Benutzer einer benutzerdefinierte Rolle hinzufügen und ihn nicht den beiden anderen wichtigen Administratorrollen hinzufügen.

Einschränkungen

Für eigenständige dedizierte SQL-Pools hat die Funktion der virtuellen Netzwerkregeln folgende Einschränkungen:

• In der Firewall für deinen logischen Server verweist jede virtuelle Netzwerkregel auf ein Subnetz. Alle referenzierten Subnetze müssen in derselben geografischen Region wie der dedizierte SQL-Pool gehostet werden.
• Jeder Server kann bis zu 128 ACL-Einträge für ein beliebiges virtuelles Netzwerk haben.
• Die Regeln für virtuelle Netzwerke gelten nur für virtuelle Netzwerke im Azure Resource Manager und nicht für klassische Bereitstellungsmodellnetzwerke.
• Auf der Firewall gelten IP-Adressbereiche für die folgenden Netzwerkelemente, aber die Regeln für virtuelle Netzwerke nicht:
  • Site-to-Site (S2S) virtuelles privates Netzwerk (VPN)
  • On-premises via Azure ExpressRoute
• Beide Abonnements müssen im selben Microsoft Entra-Tenant liegen.

Überlegungen bei der Nutzung von Service-Endpunkten

Wenn Sie Service-Endpunkte für einen dedizierten SQL-Pool verwenden, prüfen Sie die folgende Überlegung:

• Outbound Access zu öffentlichen IPs von Azure Synapse Analytics ist erforderlich. Netzwerksicherheitsgruppen (NSGs) müssen die Verbindung zu den Dienst-IPs erlauben. Du kannst das SqlNSG-Service-Tag verwenden.

ExpressRoute

Wenn Sie ExpressRoute von Ihren Räumlichkeiten aus verwenden, müssen Sie für öffentliches Peering oder Microsoft-Peering die verwendeten NAT-IP-Adressen identifizieren. Für öffentliches Peering verwendet jede ExpressRoute-Leitung standardmäßig zwei NAT-IP-Adressen, die auf den Azure-Serviceverkehr angewendet werden, wenn der Datenverkehr in das Microsoft Azure-Netzwerkrückgrat eintritt. Beim Microsoft-Peering werden die verwendeten NAT-IP-Adressen entweder vom Kunden oder vom Dienstleister bereitgestellt. Um den Zugriff auf Ihre Dienstressourcen zuzulassen, müssen Sie diese öffentlichen IP-Adressen in der Ressourceneinstellung der IP-Firewall zulassen. Um Ihre öffentlichen Peering-IP-Adressen der ExpressRoute-Leitung zu finden, eröffnen Sie ein Support-Ticket bei ExpressRoute über das Azure-Portal. Um mehr über NAT für ExpressRoute Public und Microsoft Peering zu erfahren, siehe NAT-Anforderungen für Azure Public Peering.

Um die Kommunikation aus Ihrer Leitung mit Azure Synapse Analytics zu ermöglichen, müssen Sie IP-Netzwerkregeln für die öffentlichen IP-Adressen Ihres NAT erstellen.

Auswirkungen der Nutzung von Virtual Network Service Endpoints mit Azure Storage

In Azure Storage ist dasselbe Feature implementiert, mit dem Sie die Konnektivität mit Ihrem Azure Storage-Konto beschränken können. Wenn du diese Funktion mit einem Azure Storage-Konto nutzt, das Azure Synapse Analytics nutzt, kannst du Probleme bekommen.

Die folgenden Abschnitte behandeln die betroffenen Funktionen von Azure Synapse Analytics.

Azure Synapse Analytics PolyBase and COPY statement

PolyBase und die COPY-Anweisung werden häufig verwendet, um Daten in Azure Synapse Analytics aus Azure Storage-Accounts für die Datenaufnahme mit hoher Durchsatzrate zu laden. Wenn das Azure Storage-Konto, von dem du Daten lädst, die Zugriffe nur auf eine Reihe virtueller Netzwerk-Subnetze beschränkt, funktioniert die Verbindung beim Einsatz von PolyBase und der COPY-Anweisung mit dem Speicherkonto nicht mehr. Um Import- und Exportszenarien durch COPY und PolyBase mit Azure Synapse Analytics zu aktivieren, das sich mit Azure Storage verbindet, das mit einem virtuellen Netzwerk gesichert ist, folgen Sie den Schritten in diesem Abschnitt.

Prerequisites

• Installieren Sie Azure PowerShell. Weitere Informationen finden Sie unter Installieren des Azure Az PowerShell-Moduls.
• Wenn Sie ein Allzweck-v1- oder Azure Blob Storage-Konto haben, müssen Sie zunächst auf ein Allzweck-v2-Speicherkonto upgraden, indem Sie die Schritte in Upgrade auf ein Allzweck-v2-Speicherkonto befolgen.
• Sie müssen unter dem Einstellungsmenü Firewalls und virtuelle Netzwerke des Azure Storage-Kontos die Option Vertrauenswürdigen Microsoft-Diensten den Zugriff auf dieses Speicherkonto erlauben aktivieren. Die Aktivierung dieser Konfiguration ermöglicht es PolyBase und der COPY-Anweisung, sich mit dem Speicherkonto zu verbinden, indem sie eine starke Authentifizierung verwenden, bei der der Netzwerkverkehr auf dem Azure-Backbone verbleibt. Weitere Informationen finden Sie in diesem Leitfaden.

Steps

1. Wenn Sie einen eigenständigen dedizierten SQL-Pool (früher SQL DW) haben, registrieren Sie Ihren SQL-Server mit Microsoft Entra ID per PowerShell:

   Connect-AzAccount
   Select-AzSubscription -SubscriptionId <subscriptionId>
   Set-AzSqlServer -ResourceGroupName your-database-server-resourceGroup -ServerName your-SQL-servername -AssignIdentity
   

   Dieser Schritt ist für die dedizierten SQL-Pools innerhalb eines Azure Synapse Analytics-Arbeitsbereichs nicht erforderlich. Die vom System zugewiesene verwaltete Identität (SA-MI) des Arbeitsbereichs ist ein Mitglied der Synapse-Administratorrolle und verfügt daher über erhöhte Rechte für die dedizierten SQL-Pools des Arbeitsbereichs.

2. Erstellen Sie anhand der Schritte unter Erstellen eines Speicherkontos ein Speicherkonto vom Typ „Universell V2“ .

   • Wenn Sie ein universelles v1- oder Blob Storage-Konto haben, müssen Sie zunächst auf v2 upgraden, indem Sie die Schritte in Upgrade to a General Purpose v2 Storage Account befolgen.
   • Für bekannte Probleme mit Azure Data Lake Storage Gen2 siehe Bekannte Probleme mit Azure Data Lake Storage Gen2.

3. Wählen Sie auf Ihrer Speicherkontoseite Access control (IAM) aus.

4. Wählen Sie Hinzufügen>Rollenzuweisung hinzufügen aus, um die Seite Rollenzuweisung hinzufügen zu öffnen.

5. Weisen Sie die folgende Rolle zu. Ausführliche Schritte finden Sie unter Zuweisen von Azure-Rollen mithilfe des Azure-Portals.

   Setting	Wert
   Role	Storage Blob-Datenmitwirkender
   Zugriff zuweisen an	Benutzer, Gruppe oder Dienstprinzipal
   Elemente	Server oder Arbeitsbereich, auf bzw. in dem Ihr bei Microsoft Entra ID registrierter dedizierter SQL-Pool gehostet wird

   

   Note

   Nur Mitglieder mit Eigentümerrechten auf dem Speicherkonto können diesen Schritt ausführen. Für verschiedene Azure-Built-in-Rollen siehe Azure built-in Roles.

6. Um die PolyBase-Verbindung zum Azure Storage-Konto zu aktivieren:

   1. Erstelle einen Datenbank-Masterschlüssel, falls du noch keinen erstellt hast.

      CREATE MASTER KEY [ENCRYPTION BY PASSWORD = '<password>'];
      

   2. Erstellen Sie mit IDENTITY = 'Managed Service Identity' datenbankweit gültige Anmeldeinformationen.

      CREATE DATABASE SCOPED CREDENTIAL msi_cred WITH IDENTITY = 'Managed Service Identity';
      

      • Es ist nicht nötig, SECRET mit einem Azure Storage-Zugriffsschlüssel anzugeben, da dieser Mechanismus im Hintergrund Managed Identity verwendet. Dieser Schritt ist für die dedizierten SQL-Pools innerhalb eines Azure Synapse Analytics-Arbeitsbereichs nicht erforderlich. Die vom System zugewiesene verwaltete Identität (SA-MI) des Arbeitsbereichs ist ein Mitglied der Synapse-Administratorrolle und verfügt daher über erhöhte Rechte für die dedizierten SQL-Pools des Arbeitsbereichs.

      • Der IDENTITY-Name muss 'Managed Service Identity' lauten, damit die PolyBase-Konnektivität mit dem im virtuellen Netzwerk geschützten Azure Storage-Konto funktioniert.

   3. Erstellen Sie mit dem Schema abfss:// eine externe Datenquelle für die Verbindungsherstellung mit Ihrem Speicherkonto vom Typ „Universell V2“ unter Verwendung von PolyBase.

      CREATE EXTERNAL DATA SOURCE ext_datasource_with_abfss WITH (TYPE = hadoop, LOCATION = 'abfss://myfile@mystorageaccount.dfs.core.windows.net', CREDENTIAL = msi_cred);
      

      • Wenn Sie bereits externe Tabellen haben, die mit einem allgemeinen v1- oder Blob Storage-Konto verknüpft sind, sollten Sie diese externen Tabellen zuerst löschen. Dann droppe die entsprechende externe Datenquelle. Erstellen Sie als Nächstes wie oben gezeigt mit dem Schema abfss:// eine externe Datenquelle, die mit Ihrem Speicherkonto vom Typ „Universell V2“ verbunden ist. Erstellen Sie dann alle externen Tabellen mit dieser neuen externen Datenquelle neu. Du könntest den Generate and Publish Scripts Wizard verwenden, um der Einfachheit halber Create-Scripts für alle externen Tabellen zu generieren.
      • Weitere Informationen zum abfss://Schema finden Sie unter Verwenden des Azure Data Lake Storage Gen2-URI.
      • Für weitere Informationen zu den T-SQL-Befehlen siehe CREATE EXTERNAL DATA SOURCE.

   4. Abfragen wie gewohnt mit externen Tabellen.

Azure Synapse Analytics-Auditing in Blob Storage

Azure Synapse Analytics Auditing kann SQL-Audit-Logs auf Ihr eigenes Speicherkonto schreiben. Wenn dieses Speicherkonto die Funktion Virtual Network Service Endpoints verwendet, sehen Sie sich an, wie man Überwachungsprotokolle in ein Speicherkonto hinter VNet und Firewall schreibt.

Füge deinem dedizierten SQL-Pool-SQL-Server eine virtuelle Netzwerk-Firewall-Regel hinzu

Vor langer Zeit, bevor diese Funktion erweitert wurde, musste man virtuelle Netzwerkdienst-Endpunkte aktivieren, bevor man eine Live-Virtual-Network-Regel in der Firewall implementieren konnte. Die Endpunkte ordnen ein bestimmtes virtuelles Netzwerksubnetz einem dedizierten SQL-Pool zu. Seit Januar 2018 können Sie diese Anforderung umgehen, indem Sie die Flag IgnoreMissingVNetServiceEndpoint setzen. Jetzt können Sie eine virtuelle Netzwerk-Firewallregel zu Ihrem Server hinzufügen, ohne die Dienstendpunkte für virtuelle Netzwerke einzuschalten.

Nur eine Firewall-Regel zu setzen, hilft nicht, den Server zu sichern. Sie müssen auch VNET-Dienstendpunkte aktivieren, damit der Server geschützt wird. Wenn Sie Service-Endpunkte einschalten, erlebt Ihr virtuelles Netzwerk-Subnetz Ausfallzeiten, bis es den Übergang von ausgeschaltet auf eingeschaltet abgeschlossen hat. Diese Ausfallzeit gilt besonders im Kontext großer virtueller Netzwerke. Sie können das Flag IgnoreMissingVNetServiceEndpoint verwenden, um die Ausfallzeiten während des Übergangs zu reduzieren oder zu eliminieren.

Du kannst das Flag IgnoreMissingVNetServiceEndpoint mit PowerShell setzen. Weitere Informationen finden Sie unter New-AzSqlServerVirtualNetworkRule.

Verwenden Sie Azure Portal, um eine virtuelle Netzwerkregel zu erstellen

In diesem Abschnitt erfahren Sie, wie Sie das Azure-Portal nutzen können, um eine virtuelle Netzwerkregel für einen eigenständigen dedizierten SQL-Pool zu erstellen. Die Regel weist den logischen Server an, Kommunikation von einem bestimmten Subnetz zu akzeptieren, das als Dienstendpunkt für virtuelle Netzwerke markiert wurde.

Prerequisites

Sie müssen bereits ein Subnetz haben, das mit dem von Azure Synapse Analytics verwendeten VNET-Dienstendpunkt Typname markiert ist.

• Der relevante Endpunkttypname ist Microsoft.Sql.
• Wenn Ihr Subnetz möglicherweise nicht mit dem Typnamen markiert ist, finden Sie unter Überprüfen, ob der Dienstendpunkt aktiviert ist weitere Informationen.

Schritte im Azure-Portal

1. Melden Sie sich im Azure-Portal an.

2. Suche nach und wähle SQL-Server aus, und wähle dann deinen Server aus. Wählen Sie unter Sicherheit die Option Netzwerk aus.

3. Unter dem Reiter Öffentlicher Zugriff stellen Sie sicher, dass der öffentliche Netzwerkzugang auf Netzwerke auswählen eingestellt ist, andernfalls sind die Einstellungen für virtuelle Netzwerke versteckt. Wählen Sie + Bestehendes virtuelles Netzwerk hinzufügen im Bereich Virtuelle Netzwerke aus.

4. Im neuen Create/Update-Bereich füllen Sie die Felder mit den Namen Ihrer Azure-Ressourcen aus.

   Tip

   Du musst das korrekte Adresspräfix für dein Subnetz angeben. Den Wert des Adresspräfixes findest du im Portal. Gehe zu Alle Ressourcen>Alle Typen>Virtuelle Netzwerke. Der Filter zeigt deine virtuellen Netzwerke an. Wählen Sie Ihr virtuelles Netzwerk aus und wählen Sie dann Subnetze. Die Spalte ADDRESS RANGE enthält das benötigte Adresspräfix.

5. Siehe die resultierende virtuelle Netzwerkregel im Firewall-Bereich.

6. Legen Sie Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben auf Nein fest.

   Important

   Wenn Sie "Azure-Diensten und -Ressourcen den Zugriff auf diesen Server erlauben aktiviert lassen, akzeptiert Ihr Server die Kommunikation von jedem Subnetz innerhalb der Azure-Grenze. Dies umfasst die gesamte Kommunikation, die von einer der IP-Adressen stammt, die innerhalb der für Azure-Rechenzentren definierten Bereiche liegen. Wenn Sie das Steuerelement nicht deaktivieren, kann das unter Sicherheitsaspekten zu einem übermäßigen Zugriff führen. Die Microsoft Azure Virtual Network Service Endpoint-Funktion zusammen mit den virtuellen Netzwerkregeln von Azure Synapse Analytics kann Ihre Angriffsfläche verringern.

7. Wählen Sie die OK-Schaltfläche am unteren Rand des Bereichs.

Verwenden Sie PowerShell, um eine virtuelle Netzwerkregel zu erstellen

Ein Skript kann auch virtuelle Netzwerkregeln erstellen, indem es das PowerShell-Cmdlet New-AzSqlServerVirtualNetworkRule oder az network vnet create verwendet. Weitere Informationen finden Sie unter New-AzSqlServerVirtualNetworkRule.

Verwenden Sie die REST API, um eine virtuelle Netzwerkregel zu erstellen

Intern rufen die PowerShell-Cmdlets für Synapse SQL Virtual Network Actions REST-APIs auf. Du kannst die REST-APIs direkt aufrufen. Weitere Informationen finden Sie unter Virtuelle Netzwerkregeln: Operationen.

Fehler 40914 und 40615 beheben

Verbindungsfehler 40914 bezieht sich auf virtuelle Netzwerkregeln, wie sie auf der Firewall-Seite im Azure-Portal angegeben sind.
Beim Fehler 40615 verhält es sich ähnlich, nur dass sich dieser Fehler auf IP-Adressregeln in der Firewall bezieht.

Fehler 40914

Nachrichtentext: "Server '[Servername]', der vom Login angefordert wurde, kann nicht geöffnet werden. Dem Client ist der Zugriff auf den Server nicht gestattet.“

Fehlerbeschreibung: Der Client befindet sich in einem Subnetz mit virtuellen Netzwerkserver-Endpunkten. Der Server hat jedoch keine virtuelle Netzwerkregel, die dem Subnetz das Recht gibt, mit der Datenbank zu kommunizieren.

Fehlerbehebung: Verwenden Sie im Azure-Portal im Bereich Firewall die Steuerung von VNET-Regeln, um eine VNET-Regel für das Subnetz hinzuzufügen.

Fehler 40615

Meldungstext: „Der bei der Anmeldung angeforderte Server „{0}“ kann nicht geöffnet werden.“ Der Client mit der IP-Adresse '{1}' hat keine Zugriffsberechtigung für den Server.“

Fehlerbeschreibung: Der Client versucht, eine Verbindung über eine IP-Adresse herzustellen, die nicht zum Herstellen einer Verbindung mit dem Server autorisiert ist. Die Server-Firewall hat keine IP-Adressregel, die es einem Client erlaubt, von der angegebenen IP-Adresse zur Datenbank zu kommunizieren.

Fehlerbehebung: Geben Sie die IP-Adresse des Clients als IP-Regel ein. Verwenden Sie den Firewall-Bereich im Azure-Portal, um diesen Schritt durchzuführen.

Verwandte Inhalte

• Azure-VNET-Dienstendpunkte
• Azure Synapse IP-Firewallregeln
• Verwenden New-AzSqlServerVirtualNetworkRule Sie zur Erstellung einer virtuellen Netzwerkregel
• Regeln für virtuelle Netzwerke: Operationen