Freigeben über

Azure Private Link für Azure SQL-Datenbank und Azure Synapse Analytics

  • Artikel

Gilt für: Azure SQL-Datenbank Azure Synapse Analytics (nur dedizierte SQL-Pools)

Azure Private Link ermöglicht das Herstellen von Verbindungen mit verschiedenen PaaS-Diensten in Azure über einen privaten Endpunkt. Eine Liste der PaaS-Dienste, die die Private Link-Funktion unterstützen, finden Sie in der Private Link-Dokumentation. Ein privater Endpunkt ist eine private IP-Adresse in einem bestimmten VNET und Subnetz.

Wichtig

Dieser Artikel gilt für Azure SQL-Datenbank und den dedizierten SQL-Pool (vormals SQL DW) in Azure Synapse Analytics. Diese Einstellungen gelten für alle SQL-Datenbank-Datenbanken und die Datenbanken des dedizierten SQL-Pools (früher „SQL DW“), die dem Server zugeordnet sind. Der Einfachheit halber wird der Begriff „Datenbank“ verwendet, wenn auf Datenbanken sowohl in Azure SQL-Datenbank als auch in Azure Synapse Analytics verwiesen wird. Ebenso bezieht sich der Begriff „Server“ auf den logischen Server, der Azure SQL-Datenbank und den dedizierten SQL-Pool (vormals SQL DW) in Azure Synapse Analytics hostet. Dieser Artikel gilt nicht für Azure SQL Managed Instance oder dedizierte SQL-Pools in Azure Synapse Analytics-Arbeitsbereichen.

Erstellungsprozess

Private Endpunkte können über das Azure-Portal, mithilfe von PowerShell oder über die Azure CLI erstellt werden:

Genehmigungsprozess

Nachdem der Netzwerkadministrator den privaten Endpunkt (PE) erstellt hat, kann der SQL-Administrator die private Endpunktverbindung (Private Endpoint Connection, PEC) mit SQL-Datenbank verwalten.

  1. Navigieren Sie im Azure-Portal zu Ihrer Server-Ressource.

  2. Navigieren Sie zur Genehmigungsseite für private Endpunkte:

    • Wählen Sie in der SQL Server-Ressource unter Sicherheit die Option Netzwerk aus. Wählen Sie die Registerkarte Privater Zugriff aus.
    • Wählen Sie im Synapse-Arbeitsbereich unter Sicherheit im Ressourcenmenü Private Endpunktverbindungen aus.

  3. Die Seite zeigt Folgendes:

    • Eine Liste aller privaten Endpunktverbindungen (Private Endpoint Connections, PECs)
    • Erstellte private Endpunkte (PE)

    Screenshot, der zeigt, wie Sie die Liste der privaten Endpunktverbindungen für die Serverressource suchen.

  4. Wenn keine privaten Endpunkte vorhanden sind, erstellen Sie einen mit der Schaltfläche Privaten Endpunkt erstellen. Andernfalls wählen Sie eine einzelne PEC aus der Liste aus, indem Sie sie markieren.

    Screenshot, der zeigt, wie Sie eine private Endpunktverbindung im Azure-Portal auswählen.

  5. Der SQL-Administrator kann eine PEC genehmigen oder ablehnen und optional eine kurze Textantwort hinzufügen.

    Screenshot, der zeigt, wie Sie eine PEC im Azure-Portal genehmigen.

  6. Nach der Genehmigung oder Ablehnung wird der entsprechende Zustand zusammen mit dem Antworttext in der Liste angezeigt.

    Screenshot, der die PEC im Status „Genehmigt“ nach der Genehmigung durch den Administrator zeigt.

  7. Wählen Sie schließlich den Namen des privaten Endpunkts aus

    Screenshot mit PEC-Details mit dem Endpunktnamen.

    Dadurch gelangen Sie zur Übersichtsseite des privaten Endpunkts. Wählen Sie den Link Netzwerkschnittstellen, um die Details der Netzwerkschnittstelle für die private Endpunktverbindung zu erhalten.

    Screenshot, der die NIC-Details für die private Endpunktverbindung zeigt.

    Auf der Seite Netzwerkschnittstelle wird die private IP-Adresse für die private Endpunktverbindung angezeigt.

    Screenshot, der die private IP-Adresse für die private Endpunktverbindung zeigt.

Wichtig

Beim Hinzufügen einer Verbindung mit einem privaten Endpunkt wird das öffentliche Routing zu Ihrem logischen Server standardmäßig nicht blockiert. Im Bereich Firewall und virtuelle Netzwerke ist die Einstellung Zugriff auf öffentliches Netzwerk verweigern nicht standardmäßig ausgewählt. Wählen Sie zum Deaktivieren des Zugriffs auf öffentliche Netzwerke unbedingt Zugriff auf öffentliches Netzwerk verweigern aus.

Deaktivieren Sie den öffentlichen Zugriff auf Ihren logischen Server

Nehmen wir an, dass Sie in der Azure SQL-Datenbank alle öffentlichen Zugriffe auf Ihren logischen Server deaktivieren und nur Verbindungen aus Ihrem virtuellen Netzwerk zulassen möchten.

Stellen Sie zunächst sicher, dass Ihre Verbindungen mit privaten Endpunkten aktiviert und konfiguriert sind. So deaktivieren Sie anschließend den öffentlichen Zugriff auf Ihren logischen Server

  1. Wechseln Sie zur Seite Netzwerk Ihres logischen Servers.

  2. Aktivieren Sie das Kontrollkästchen Zugriff auf öffentliches Netzwerk verweigern.

    Screenshot, der zeigt, wie Sie den öffentlichen Netzwerkzugriff für die private Endpunktverbindung deaktivieren.

Testen der Konnektivität mit SQL-Datenbank über einen virtuellen Azure-Computer im gleichen virtuellen Netzwerk

In diesem Szenario wird davon ausgegangen, dass Sie einen virtuellen Azure-Computer (VM) erstellt haben, auf dem eine aktuelle Version von Windows im gleichen virtuellen Netzwerk wie der private Endpunkt ausgeführt wird.

  1. Starten Sie eine RDP-Sitzung (Remotedesktop), und stellen Sie eine Verbindung mit dem virtuellen Computer her.

  2. Anschließend können Sie mithilfe der folgenden Tools einige grundlegende Konnektivitätsprüfungen durchführen, um sicherzugehen, dass der virtuelle Computer die Verbindung mit SQL-Datenbank über den privaten Endpunkt herstellt:

Überprüfen der Konnektivität mithilfe von Telnet

Der Telnet-Client ist ein Windows-Feature zum Testen der Konnektivität. Je nach Version des Windows-Betriebssystems muss dieses Feature ggf. explizit aktiviert werden.

Öffnen Sie nach der Installation von Telnet ein Eingabeaufforderungsfenster. Führen Sie den Telnet-Befehl aus, und geben Sie dabei die IP-Adresse und den privaten Endpunkt der Datenbank in SQL-Datenbank an:

telnet 10.9.0.4 1433

Wenn Telnet erfolgreich eine Verbindung herstellt, wird im Befehlsfenster ein leerer Bildschirm angezeigt, wie in der folgenden Abbildung dargestellt:

Diagramm des Telnet-Fensters mit leerem Bildschirm.

Verwenden des PowerShell-Befehls zum Überprüfen der Konnektivität

Test-NetConnection -computer myserver.database.windows.net -port 1433

Überprüfen der Konnektivität mithilfe von PsPing

PsPing kann wie folgt verwendet werden, um sich zu vergewissern, dass der private Endpunkt auf Verbindungen am Port 1433 lauscht.

Führen Sie PsPing wie folgt aus, und geben Sie dabei den FQDN für den logischen Server und den Port 1433 an:

PsPing.exe mysqldbsrvr.database.windows.net:1433

Dies ist ein Beispiel für die erwartete Ausgabe:

TCP connect to 10.9.0.4:1433:
5 iterations (warmup 1) ping test:
Connecting to 10.9.0.4:1433 (warmup): from 10.6.0.4:49953: 2.83ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49954: 1.26ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49955: 1.98ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49956: 1.43ms
Connecting to 10.9.0.4:1433: from 10.6.0.4:49958: 2.28ms

Die Ausgabe zeigt, dass PsPing die private IP-Adresse pingen konnte, die dem privaten Endpunkt zugeordnet ist.

Überprüfen der Konnektivität mithilfe von Nmap

Nmap (Network Mapper) ist ein kostenloses Open-Source-Tool für die Netzwerkermittlung und Sicherheitsüberwachung. Weitere Informationen sowie den Downloadlink finden Sie unter https://Nmap.org. Mithilfe dieses Tools können Sie sich vergewissern, dass der private Endpunkt am Port 1433 auf Verbindungen lauscht.

Führen Sie Nmap wie folgt aus, und geben Sie dabei den Adressbereich des Subnetzes an, in dem der private Endpunkt gehostet wird:

Nmap -n -sP 10.9.0.0/24

Dies ist ein Beispiel für die erwartete Ausgabe:

Nmap scan report for 10.9.0.4
Host is up (0.00s latency).
Nmap done: 256 IP addresses (1 host up) scanned in 207.00 seconds

Das Ergebnis zeigt, dass eine einzelne IP-Adresse aktiv ist. Diese entspricht der IP-Adresse für den privaten Endpunkt.

Überprüfen der Konnektivität mithilfe von SQL Server Management Studio (SSMS)

Hinweis

Verwenden Sie den vollqualifizierten Domänennamen (Fully Qualified Domain Name, FQDN) des Servers in Verbindungszeichenfolgen für Ihre Clients (<server>.database.windows.net). Alle direkt für die IP-Adresse vorgenommenen Anmeldeversuche oder die Verwendung des Private Link-FQDN (<server>.privatelink.database.windows.net) schlagen fehl. Dieses Verhalten ist entwurfsbedingt, da ein privater Endpunkt Datenverkehr an das SQL-Gateway in der Region weiterleitet und der richtige FQDN angegeben werden muss, damit Anmeldungen erfolgreich sind.

Führen Sie die Schritte zur Verwendung von SSMS zum Herstellen einer Verbindung mit der SQL-Datenbank-Instanz aus. Nachdem Sie mithilfe von SSMS eine Verbindung mit der SQL-Datenbank hergestellt haben, sollte die folgende Abfrage client_net_address zurückgeben, die der privaten IP-Adresse des virtuellen Azure-Computers entspricht, von dem aus Sie eine Verbindung herstellen:

SELECT client_net_address
FROM sys.dm_exec_connections
WHERE session_id = @@SPID;

Verwenden der Umleitungsverbindungsrichtlinie für private Endpunkte

Wir empfehlen Kunden, die private Verbindung mit der Umleitungsverbindungsrichtlinie zu verwenden, um die Latenz zu verringern und den Durchsatz zu verbessern. Damit Verbindungen diesen Modus verwenden können, müssen Clients die folgenden Voraussetzungen erfüllen:

  • Erlauben Sie eingehende Kommunikation zum VNET, das den privaten Endpunkt hostet, zum Portbereich 1433 bis 65535.

  • Erlauben Sie ausgehende Kommunikation vom VNET, das den Client hostet, zum Portbereich 1433 bis 65535.

  • Verwenden Sie die neuste Version des Treibers mit integrierter. Umleitungsunterstützung ist in ODBC-, OLEDB-, NET SqlClient Data Provider-, Core .NET SqlClient Data Provider- und JDBC-Treibern (Version 9.4 oder höher) enthalten. Verbindungen, die von allen anderen Treibern ausgehen, werden über einen Proxy geleitet.

Nach der Erfüllung der Voraussetzungen müssen Clients explizit die Verbindungsrichtlinie für die Umleitung auswählen.

Wenn es nicht möglich ist, die Firewalleinstellungen so zu ändern, dass der ausgehende Zugriff auf den Portbereich 1433-65535 zugelassen wird, besteht eine alternative Lösung darin, die Verbindungsrichtlinie auf Proxy zu ändern.

Vorhandene private Endpunkte, die die Standard-Verbindungsrichtlinie verwenden, verwenden die Proxy-Verbindungsrichtlinie mit Port 1433. Der Grund dafür besteht darin, jegliche Unterbrechung des Datenverkehrs des Clients zur SQL-Datenbank zu vermeiden, da erforderliche Port-Bereiche für die Umleitung nicht geöffnet werden.

Hinweis

Bei dedizierten SQL-Pools lautet die Verbindungsrichtlinie bei Nutzung privater Endpunkte stets Proxy. Das Ändern der Einstellung wirkt sich bei Nutzung privater Endpunkte nicht auf dedizierte SQL-Pools aus.

Lokale Konnektivität über privates Peering

Wenn Kunden von lokalen Computern aus eine Verbindung mit dem öffentlichen Endpunkt herstellen, muss ihre IP-Adresse mithilfe einer Firewallregel auf Serverebene der IP-basierten Firewall hinzugefügt werden. Dieses Modell eignet sich zwar gut, um den Zugriff auf einzelne Computer für Entwicklungs- oder Testworkloads zuzulassen, in einer Produktionsumgebung gestaltet sich die Verwaltung jedoch schwierig.

Mit Private Link können Kunden standortübergreifenden Zugriff auf den privaten Endpunkt mittels ExpressRoute, privatem Peering oder VPN-Tunneling ermöglichen. Kunden haben dann die Möglichkeit, den gesamten Zugriff über den öffentlichen Endpunkt zu deaktivieren und nicht die IP-basierte Firewall zu verwenden, um IP-Adressen zuzulassen.

Clients können über das gleiche virtuelle Netzwerk, über ein mittels Peering verknüpftes virtuelles Netzwerk in derselben Region oder über eine regionsübergreifende VNET-zu-VNET-Verbindung eine Verbindung mit dem privaten Endpunkt herstellen. Darüber hinaus können Clients von der lokalen Umgebung aus eine Verbindung über ExpressRoute, privates Peering oder VPN-Tunneling herstellen. Das folgende vereinfachte Diagramm zeigt die gängigen Anwendungsfälle.

Abbildung der Konnektivitätsoption

Außerdem können Dienste, die nicht direkt im virtuellen Netzwerk ausgeführt werden, aber darin integriert sind (z. B. App Service-Web-Apps oder Azure Functions), auch eine private Konnektivität mit der Datenbank herstellen. Weitere Informationen zu diesem speziellen Anwendungsfall finden Sie im Architekturszenario Private Konnektivität von Web-Apps mit Azure SQL-Datenbank.

Herstellen einer Verbindung über einen virtuellen Azure-Computer in einem virtuellen Netzwerk mit Peering

Konfigurieren Sie das Peering virtueller Netzwerke, um über einen virtuellen Azure-Computer in einem virtuellen Netzwerk mit Peering eine Verbindung mit der SQL-Datenbank-Instanz herzustellen.

Herstellen einer Verbindung von einem virtuellen Azure-Computer in einem virtuellen Netzwerk mit einer virtuellen Netzwerkumgebung

Konfigurieren Sie eine VNET-zu-VNET-VPN-Gatewayverbindung, um über einen virtuellen Azure-Computer in einer anderen Region oder in einem anderen Abonnement eine Verbindung mit einer Datenbank in SQL-Datenbank herzustellen.

Herstellen einer VPN-Verbindung in einer lokalen Umgebung

Verwenden oder implementieren Sie eine der folgenden Optionen, um in einer lokalen Umgebung eine Verbindung mit der Datenbank in SQL-Datenbank herzustellen:

Berücksichtigen Sie auch DNS-Konfigurationsszenarien, da der FQDN des Diensts in die öffentliche IP-Adresse aufgelöst werden kann.

Herstellen einer Verbindung zwischen Azure Synapse Analytics und Azure Storage mit PolyBase und der COPY-Anweisung

PolyBase und die COPY-Anweisung werden häufig verwendet, um Daten aus Azure Storage-Konten in Azure Synapse Analytics zu laden. Wenn das Azure Storage-Konto, aus dem Sie Daten laden, den Zugriff auf einen Satz von Subnetzen virtueller Netzwerke über private Endpunkte, Dienstendpunkte oder IP-basierte Firewalls einschränkt, wird die Konnektivität von PolyBase und der COPY-Anweisung mit dem Konto unterbrochen. Führen Sie die hier angegebenen Schritte aus, um Import- und Exportszenarien zu ermöglichen, in denen Azure Synapse Analytics eine Verbindung mit Azure Storage (mit VNET-Schutz) herstellt.

Verhinderung der Datenexfiltration

Datenexfiltration in Azure SQL-Datenbank bedeutet, dass ein Benutzer (etwa ein Datenbankadministrator) Daten aus einem System extrahieren und an einen anderen Ort oder in ein anderes System außerhalb der Organisation verschieben kann. So kann ein Benutzer beispielsweise Daten in ein Speicherkonto einer Nicht-Microsoft-Gesellschaft verschieben.

Stellen Sie sich ein Szenario vor, in dem ein Benutzer SQL Server Management Studio (SSMS) auf einem virtuellen Azure-Computer ausführt, von dem eine Verbindung mit einer Datenbank in SQL-Datenbank hergestellt wird. Die Datenbank befindet sich im Rechenzentrum „USA, Westen“. Das folgende Beispiel zeigt, wie Sie den Zugriff mit öffentlichen Endpunkten in SQL-Datenbank unter Verwendung von Netzwerkzugriffssteuerungen einschränken.

  1. Deaktivieren Sie den gesamten Datenverkehr von Azure-Diensten zur SQL-Datenbank-Instanz über den öffentlichen Endpunkt, indem Sie die Option zum Zulassen von Azure-Diensten auf AUS festlegen. Vergewissern Sie sich, dass durch die Firewallregeln auf Server- und Datenbankebene keine IP-Adressen zugelassen werden. Weitere Informationen finden Sie unter Netzwerkzugriffssteuerung für Azure SQL-Datenbank und Data Warehouse.
  2. Lassen Sie nur Datenverkehr für die Datenbank in SQL-Datenbank mit der privaten IP-Adresse des virtuellen Computers zu. Weitere Informationen finden Sie in den Artikeln Verwenden von Virtual Network-Dienstendpunkten und -Regeln für Server in Azure SQL-Datenbank und IP-Firewallregeln für Azure SQL-Datenbank und Azure Synapse.
  3. Beschränken Sie auf dem virtuellen Azure-Computer den Bereich der ausgehenden Verbindung mithilfe von Netzwerksicherheitsgruppen (NSGs) und Diensttags.
    • Geben Sie eine NSG-Regel an, um Datenverkehr für das Diensttag „SQL.WestUs“ zuzulassen. Dadurch ist nur eine Verbindung mit der SQL-Datenbank-Instanz in „USA, Westen“ möglich.
    • Geben Sie eine NSG-Regel (mit einer höheren Priorität) an, um Datenverkehr für das Diensttag „SQL“ zu verweigern. Dadurch werden Verbindungen mit der SQL-Datenbank-Instanz in allen Regionen verweigert.

Am Ende dieser Einrichtung kann der virtuelle Azure-Computer nur eine Verbindung mit einer Datenbank in SQL-Datenbank in der Region „USA, Westen“ herstellen. Die Konnektivität ist jedoch nicht auf ein Singleton in SQL-Datenbank beschränkt. Der virtuelle Computer kann weiterhin eine Verbindung mit beliebigen Datenbanken in der Region „USA, Westen“ herstellen – also auch mit den Datenbanken, die nicht Teil des Abonnements sind. Wir haben den Bereich der Datenexfiltration im obigen Szenario auf eine bestimmte Region reduziert, sie aber nicht vollständig unterbunden.

Mit Private Link können Kunden jetzt Netzwerkzugriffssteuerungen wie NSGs einrichten, um den Zugriff auf den privaten Endpunkt einzuschränken. Einzelne Azure-PaaS-Ressourcen werden dann bestimmten privaten Endpunkten zugeordnet. Ein böswilliger Insider kann somit nur auf die zugeordnete PaaS-Ressource (etwa eine Datenbank in SQL-Datenbank), aber nicht auf andere Ressourcen zugreifen.

Zugehöriger Inhalt