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

GILT FÜR: Azure SQL Database Azure Synapse Analytics

Private Link ermöglicht die Verbindungsherstellung 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 sowohl für Azure SQL-Datenbank als auch für Azure Synapse Analytics. 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 SQL-Server, der Azure SQL-Datenbank und Azure Synapse Analytics hostet. Dieser Artikel gilt nicht für Azure SQL Managed Instance.

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 der Serverressource, wie im folgenden Screenshot gezeigt:

    • (1) Wählen Sie im linken Bereich die private Endpunktverbindung aus.
    • (2) Liste mit allen privaten Endpunktverbindungen (Private Endpoint Connections, PECs)
    • (3) Der entsprechende erstellte private Endpunkt (PE) Screenshot: Alle PECs
  2. Wählen Sie eine einzelne PEC aus der Liste aus. Screenshot: Ausgewählte PEC

  3. Der SQL-Administrator kann eine PEC genehmigen oder ablehnen und optional eine kurze Textantwort hinzufügen. Screenshot: PEC-Genehmigung

  4. Nach der Genehmigung oder Ablehnung wird der entsprechende Zustand zusammen mit dem Antworttext in der Liste angezeigt. Screenshot: Alle PECs nach der Genehmigung

  5. Der Klick auf den Namen des privaten Endpunkts Screenshot: PEC-Details

    führt zu den Details der Netzwerkschnittstelle  Screenshot: NIC-Details

    die schließlich zur IP-Adresse für den privaten Endpunkt führen  Screenshot: private IP-Adresse

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:

    1. Telnet
    2. PsPing
    3. Nmap
    4. SQL Server Management Studio (SSMS)

Ü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:

Diagramm: Telnet

Ü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
...
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
...
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

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. Die gängigen Anwendungsfälle sind im folgenden Diagramm vereinfacht dargestellt:

Diagramm: Konnektivitätsoptionen

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:

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 eines Dritten 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.

Nächste Schritte