Azure Database for PostgreSQL – Flexibler Server: Netzwerke mit Private Link

Azure Private Link ermöglicht Ihnen das Erstellen privater Endpunkte für Azure Database for PostgreSQL Flexible Server, um sie in Ihr virtuelles Netzwerk (VNet) zu integrieren. Diese Funktionalität wird zusätzlich zu den bereits vorhandenen Netzwerkfunktionen der VNET-Integration eingeführt, die derzeit mit flexiblen Azure Database for PostgreSQL-Servern allgemein verfügbar ist. Mit Private Link verläuft der Datenverkehr zwischen Ihrem virtuellen Netzwerk und dem Dienst über das Microsoft-Backbone-Netzwerk. Es ist nicht mehr erforderlich, dass Sie Ihren Dienst über das öffentliche Internet verfügbar machen. Sie können Ihren eigenen Private Link-Dienst in Ihrem virtuellen Netzwerk erstellen und Ihren Kunden zur Verfügung stellen. Die Einrichtung und Nutzung von Azure Private Link ist in Azure PaaS-, Kunden- und gemeinsam genutzten Partnerdiensten einheitlich.

Private Link wird Benutzern über zwei Azure-Ressourcentypen verfügbar gemacht:

  • Private Endpunkte (Microsoft.Network/PrivateEndpoints)
  • Private Link-Dienste (Microsoft.Network/PrivateLinkServices)

Private Endpunkte

Ein privater Endpunkt fügt einer Ressource eine Netzwerkschnittstelle hinzu, die ihr eine private IP-Adresse von Ihrem VNet (Virtuelles Netzwerk) zuweist. Nach der Anwendung können Sie ausschließlich über das virtuelle Netzwerk (VNet) mit dieser Ressource kommunizieren. Eine Liste der PaaS-Dienste, die die Private Link-Funktion unterstützen, finden Sie in der Dokumentation zu Private Link. Ein privater Endpunkt ist eine private IP-Adresse in einem bestimmten VNet und Subnetz.

Auf dieselbe öffentliche Dienstinstanz kann von mehreren privaten Endpunkten in verschiedenen VNets/Subnetzen verwiesen werden, auch wenn sie überlappende Adressräume aufweisen.

Azure Private Link bietet folgende Vorteile:

  • Privates Zugreifen auf Dienste auf der Azure-Plattform: Verbinden Sie Ihr virtuelles Netzwerk mit privaten Endpunkten mit allen Diensten, die als Anwendungskomponenten in Azure verwendet werden können. Dienstanbieter können ihre Dienste in ihrem eigenen virtuellen Netzwerk rendern, und Consumer können in ihrem lokalen virtuellen Netzwerk auf diese Dienste zugreifen. Die Private Link-Plattform verarbeitet die Konnektivität zwischen dem Consumer und den Diensten über das Azure-Backbone-Netzwerk.

  • Lokale Netzwerke und Peernetzwerke: Greifen Sie mithilfe privater Endpunkte von einer lokalen Umgebung über privates ExpressRoute-Peering, VPN-Tunnel und virtuelle Netzwerke mit Peering auf Dienste zu, die in Azure ausgeführt werden. Es ist nicht erforderlich, ExpressRoute-Microsoft-Peering einzurichten oder über das Internet auf den Dienst zuzugreifen. Private Link ist eine sichere Möglichkeit, um Workloads zu Azure zu migrieren.

  • Schutz vor Datenlecks: Ein privater Endpunkt wird nicht dem gesamten Dienst, sondern der Instanz einer PaaS-Ressource zugeordnet. Consumer können nur eine Verbindung mit der entsprechenden Ressource herstellen. Der Zugriff auf alle anderen Ressourcen des Diensts ist blockiert. Dieser Mechanismus ermöglicht den Schutz vor Risiken aufgrund von Datenlecks.

  • Globale Reichweite: Stellen Sie private Verbindungen zu Diensten her, die in anderen Regionen ausgeführt werden. Das virtuelle Netzwerk des Consumers kann sich beispielsweise in Region A befinden und eine Verbindung mit Diensten hinter Private Link in Region B herstellen.

Clients können eine Verbindung mit dem privaten Endpunkt über das gleiche VNet, über das mittels Peering verbundene VNet in der gleichen Region oder regionsübergreifend über eine VNet-to-VNet-Verbindung 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 zur Funktionsweise von Azure Private Link mit privaten Endpunkten

Matrix der Funktionsverfügbarkeit für private Endpunkte in Azure Database for PostgreSQL – Flexibler Server

Feature Verfügbarkeit Hinweise
Hochverfügbarkeit (High Availability, HA) Ja Funktioniert wie vorgesehen
Lesereplikat Ja Funktioniert wie vorgesehen
Lesereplikat mit virtuellen Endpunkten Ja Funktioniert wie vorgesehen
Zeitpunktwiederherstellung (PITR) Ja Funktioniert wie vorgesehen
Auch Zulassen des öffentlichen/Internetzugriffs mit Firewallregeln Ja Funktioniert wie vorgesehen
Hauptversionsupgrade (MVU) Ja Funktioniert wie vorgesehen
Microsoft Entra-Authentifizierung (Entra-Auth) Ja Funktioniert wie vorgesehen
Verbindungspooling mit PgBouncer Ja Funktioniert wie vorgesehen
DNS des privaten Endpunkts Ja Funktioniert wie vorgesehen und dokumentiert
Verschlüsselung mit kundenseitig verwalteten Schlüsseln (CMKs) Ja Funktioniert wie vorgesehen

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

Konfigurieren Sie das Peering virtueller Netzwerke, um über eine Azure-VM in einem VNet mit Peering eine Verbindung mit einer Instanz von Azure Database for PostgreSQL – Flexibler Server herzustellen.

Herstellen einer Verbindung über einen virtuellen Azure-Computer in einer VNET-zu-VNET-Umgebung

Konfigurieren Sie eine VNet-zu-VNet-VPN-Gatewayverbindung, um eine Verbindung mit einer Instanz eines flexiblen Azure Database for MySQL-Servers von einer Azure-VM in einer anderen Region oder einem anderen Abonnement herzustellen.

Herstellen einer VPN-Verbindung in einer lokalen Umgebung

Um die Konnektivität von einer lokalen Umgebung zur Instanz eines flexiblen Azure Database for PostgreSQL-Servers herzustellen, wählen Sie eine der Optionen aus, und implementieren Sie diese:

Bei der Verwendung privater Endpunkte ist der Datenverkehr zu Private Link-Ressourcen geschützt. Die Plattform überprüft die Netzwerkverbindungen und lässt nur solche zu, die die angegebene Private Link-Ressource erreichen. Für den Zugriff auf weitere Unterressourcen innerhalb desselben Azure-Diensts sind weitere private Endpunkte mit entsprechenden Zielen erforderlich. Im Fall von Azure Storage würden Sie beispielsweise separate private Endpunkte benötigen, um auf die Unterressourcen Datei und Blob zuzugreifen.

Private Endpunkte bieten eine privat zugängliche IP-Adresse für den Azure-Dienst, beschränken aber nicht unbedingt den öffentlichen Netzwerkzugriff darauf. Alle anderen Azure-Dienste erfordern jedoch zusätzliche Zugriffssteuerungen. Diese Steuerungen stellen eine zusätzliche Ebene der Netzwerksicherheit für Ihre Ressourcen dar und bieten einen Schutz, der den Zugriff auf den der Private Link-Ressource zugeordneten Azure-Dienst verhindern hilft.

Private Endpunkte unterstützen Netzwerkrichtlinien. Netzwerkrichtlinien ermöglichen die Unterstützung von Netzwerksicherheitsgruppen (NSG), benutzerdefinierten Routen (UDR) und Anwendungssicherheitsgruppen (ASG). Weitere Informationen zum Aktivieren von Netzwerkrichtlinien für einen privaten Endpunkt finden Sie unter Verwalten von Netzwerkrichtlinien für private Endpunkte. Informationen zur Verwendung einer ASG mit einem privaten Endpunkt finden Sie unter Konfigurieren einer Anwendungssicherheitsgruppe (ASG) mit einem privaten Endpunkt.

Bei Verwendung eines privaten Endpunkts müssen Sie eine Verbindung mit demselben Azure-Dienst herstellen, aber die IP-Adresse des privaten Endpunkts verwenden. Für die enge Endpunktverbindung sind separate DNS-Einstellungen erforderlich, um die private IP-Adresse in den Ressourcennamen aufzulösen. Private DNS-Zonen ermöglichen die Domänennamensauflösung in einem virtuellen Netzwerk ohne eine benutzerdefinierte DNS-Lösung. Sie verknüpfen die privaten DNS-Zonen mit jedem virtuellen Netzwerk, um DNS-Dienste für dieses Netzwerk bereitzustellen.

Private DNS-Zonen stellen separate DNS-Zonennamen für jeden Azure-Dienst bereit. Wenn Sie beispielsweise eine private DNS-Zone für den Blob-Dienst des Speicherkontos im vorherigen Bild konfiguriert haben, lautet der Name der DNS-Zonen privatelink.blob.core.windows.net. In der Microsoft-Dokumentation finden Sie weitere Informationen zu den Namen der privaten DNS-Zonen für alle Azure-Dienste.

Hinweis

Konfigurationen privater Endpunkte für private DNS-Zonen werden nur dann automatisch erstellt, wenn Sie das empfohlene Benennungsschema verwenden: privatelink.postgres.database.azure.com. Auf neu bereitgestellten Servern mit öffentlichem Zugriff (nicht ins VNet eingefügt) gibt es eine vorübergehende Änderung des DNS-Layouts. Der FQDN des Servers ist nun ein CName, der in einen Datensatz im Format servername.privatelink.postgres.database.azure.com aufgelöst wird. In naher Zukunft gilt dieses Format nur, wenn private Endpunkte auf dem Server erstellt werden.

Hybrid-DNS für Azure und lokale Ressourcen

Domain Name System (DNS) ist ein wichtiges Entwurfsthema in der allgemeinen Architektur der Zielzone. Einige Organisationen möchten möglicherweise ihr vorhandenes DNS verwenden, während in anderen Organisationen native Azure-Funktionen für alle DNS-Anforderungen bevorzugt werden. Sie können den Azure DNS Private Resolver-Dienst in Verbindung mit privaten Azure-DNS-Zonen für die standortübergreifende Namensauflösung verwenden. DNS Private Resolver kann DNS-Anforderungen an einen anderen DNS-Server weiterleiten und stellt außerdem eine IP-Adresse bereit, die von externen DNS-Servern zum Weiterleiten von Anforderungen verwendet werden kann. Daher können externe lokale DNS-Server den Namen in einer privaten DNS-Zone auflösen.

Weitere Informationen zur Verwendung von DNS Private Resolver mit lokaler DNS-Weiterleitung zum Weiterleiten von DNS-Datenverkehr an Azure DNS finden Sie in diesem Dokument und in diesem Dokument. Die beschriebenen Lösungen ermöglichen das Erweitern des lokalen Netzwerks, das bereits über eine DNS-Lösung verfügt, um Ressourcen in Azure aufzulösen. Microsoft-Architektur.

Private DNS-Zonen werden in der Regel zentral in demselben Azure-Abonnement gehostet, in dem auch das Hub-VNet bereitgestellt wird. Diese Praxis des zentralen Hostings wird durch die standortübergreifende DNS-Namensauflösung und andere Anforderungen an die zentrale DNS-Auflösung, z. B. Active Directory, gesteuert. In den meisten Fällen verfügen nur Netzwerk- und Identitätsadministratoren über die Berechtigung, DNS-Einträge in den Zonen zu verwalten.

In einer solchen Architektur wird Folgendes konfiguriert:

  • Lokale DNS-Server verfügen über bedingte Forwarder, die für jede öffentliche DNS-Zone des privaten Endpunkts konfiguriert sind und auf den im Hub-VNet gehosteten Private DNS Resolver verweisen.
  • Der im Hub VNet gehostete Private DNS Resolver verwendet den von Azure bereitgestellten DNS (168.63.129.16) als Forwarder.
  • Das Hub-VNet muss mit den Namen der privaten DNS-Zone für Azure-Dienste (z. B. privatelink.postgres.database.azure.com für Azure Database for PostgreSQL – Flexibler Server) verknüpft werden.
  • Alle Azure-VNets verwenden den im Hub-VNet gehosteten DNS Private Resolver-Dienst.
  • Da der DNS Private Resolver-Dienst für die Unternehmensdomänen des Kunden nicht autoritativ und lediglich ein Weiterleitungsdienst (z. B. Active Directory-Domänennamen) ist, sollte er ausgehende Endpunktweiterleitungen für die Unternehmensdomänen des Kunden aufweisen, die auf die lokalen DNS-Server oder die in Azure bereitgestellten DNS-Server verweisen, die für solche Zonen autoritativ sind.

Standardmäßig sind Netzwerkrichtlinien für ein Subnetz in einem virtuellen Netzwerk deaktiviert. Damit Netzwerkrichtlinien wie benutzerdefinierte Routen- und Netzwerksicherheitsgruppen-Unterstützung genutzt werden können, muss die Netzwerkrichtlinienunterstützung für das Subnetz aktiviert sein. Diese Einstellung gilt nur für private Endpunkte innerhalb des Subnetzes. Diese Einstellung wirkt sich auf alle privaten Endpunkte innerhalb des Subnetzes aus. Für andere Ressourcen im Subnetz wird der Zugriff basierend auf Sicherheitsregeln in der Netzwerksicherheitsgruppe gesteuert.

Netzwerkrichtlinien können entweder nur für Netzwerksicherheitsgruppen, nur für benutzerdefinierte Routen oder für beide aktiviert werden. Weitere Informationen finden Sie in den Azure-Dokumenten.

Einschränkungen für Netzwerksicherheitsgruppen (NSG) und private Endpunkte sind hier aufgeführt.

Wichtig

Schutz vor Datenlecks: Ein privater Endpunkt wird nicht dem gesamten Dienst, sondern der Instanz einer PaaS-Ressource zugeordnet. Consumer können nur eine Verbindung mit der entsprechenden Ressource herstellen. Der Zugriff auf alle anderen Ressourcen des Diensts ist blockiert. Dieser Mechanismus ermöglicht Basisschutz vor Risiken aufgrund von Datenlecks.

Folgende Fälle und Ergebnisse sind bei Verwendung von Private Link in Verbindung mit Firewallregeln möglich:

  • Wenn Sie keine Firewallregeln konfigurieren, ist standardmäßig kein Datenverkehrszugriff auf die Instanz des flexiblen Azure Database for PostgreSQL-Servers möglich.

  • Wenn Sie öffentlichen Datenverkehr oder einen Dienstendpunkt konfigurieren und private Endpunkte erstellen, werden verschiedene Arten von eingehendem Datenverkehr durch den entsprechenden Typ der Firewallregel autorisiert.

  • Wenn Sie keinen öffentlichen Datenverkehr oder Dienstendpunkt konfigurieren und private Endpunkte erstellen, kann auf die Instanz des flexiblen Azure Database for PostgreSQL-Servers nur über die privaten Endpunkte zugegriffen werden. Wenn Sie keinen öffentlichen Datenverkehr oder Dienstendpunkt konfigurieren, ist nach dem Ablehnen oder Löschen aller genehmigten privaten Endpunkte kein Datenverkehrszugriff auf die Instanz des flexiblen Azure Database for PostgreSQL-Servers möglich.

Behandeln von Konnektivitätsproblemen in auf privaten Endpunkten basierenden Netzwerken

Im Folgenden finden Sie grundlegende Bereiche, die Sie überprüfen sollten, wenn Konnektivitätsprobleme mit auf privaten Endpunkten basierenden Netzwerken auftreten:

  1. Überprüfen von IP-Adresszuweisungen: Stellen Sie sicher, dass dem privaten Endpunkt die richtige IP-Adresse zugewiesen ist und dass keine Konflikte mit anderen Ressourcen vorliegen. Weitere Informationen zu privaten Endpunkten und IP finden Sie in diesem Dokument.
  2. Überprüfen von Netzwerksicherheitsgruppen (NSGs): Überprüfen Sie die NSG-Regeln für das Subnetz des privaten Endpunkts, um sicherzustellen, dass der erforderliche Datenverkehr zugelassen wird und keine widersprüchlichen Regeln vorliegen. Weitere Informationen zu NSGs finden Sie in diesem Dokument.
  3. Überprüfen der Routingtabellenkonfiguration: Stellen Sie sicher, dass die Routingtabellen, die dem Subnetz des privaten Endpunkts zugeordnet sind, und die verbundenen Ressourcen ordnungsgemäß mit den entsprechenden Routen konfiguriert sind.
  4. Verwenden von Netzwerküberwachung und -diagnose: Nutzen Sie Azure Network Watcher, um Netzwerkdatenverkehr mithilfe von Tools wie Verbindungsmonitor oder Paketerfassung zu überwachen und zu diagnostizieren. Weitere Informationen zur Netzwerkdiagnose finden Sie in diesem Dokument.

Weitere Details zur Problembehandlung bei privaten Endpunkten finden Sie auch in diesem Leitfaden.

Behandeln von Problemen mit der DNS-Auflösung in auf privaten Endpunkten basierenden Netzwerken

Im Folgenden finden Sie grundlegende Bereiche, die Sie überprüfen sollten, wenn Probleme mit der DNS-Auflösung mit auf privaten Endpunkten basierenden Netzwerken auftreten:

  1. Überprüfen der DNS-Auflösung: Überprüfen Sie, ob der vom privaten Endpunkt verwendete DNS-Server oder -Dienst und die verbundenen Ressourcen ordnungsgemäß funktionieren. Stellen Sie sicher, dass die DNS-Einstellungen des privaten Endpunkts korrekt sind. Weitere Informationen zu privaten Endpunkten und DNS-Zoneneinstellungen finden Sie in diesem Dokument.
  2. Löschen des DNS-Caches: Löschen Sie den DNS-Cache auf dem privaten Endpunkt oder Clientcomputer, um sicherzustellen, dass die neuesten DNS-Informationen abgerufen und Fehler aufgrund von Inkonsistenz vermieden werden.
  3. Analysieren von DNS-Protokollen: Überprüfen Sie DNS-Protokolle auf Fehlermeldungen oder ungewöhnliche Muster wie DNS-Abfragefehler, Serverfehler oder Timeouts. Weitere Informationen zu DNS-Metriken finden Sie in diesem Dokument.

Nächste Schritte

  • Erfahren Sie, wie Sie eine Instanz für einen flexiblen Azure Database for PostgreSQL-Server mithilfe der Option Privater Zugriff (VNET-Integration) im Azure-Portal oder über die Azure CLI erstellen.