Herstellen einer Verbindung mit PostgreSQL
Zum Herstellen sicherer Verbindungen mit Azure-Datenbank für PostgreSQL ist es erforderlich, Verbindungszeichenfolgenkomponenten, Authentifizierungsoptionen und Sicherheitskonfiguration der Transportschicht zu verstehen. Bei KI-Anwendungen, die häufig Daten lesen und schreiben, verhindert das Abrufen der Verbindungskonfiguration von Anfang an Authentifizierungsfehler und Sicherheitsrisiken in der Produktion.
Grundlagen der Verbindung
PostgreSQL-Verbindungen erfordern mehrere Parameter, die den Server, die Datenbank und die Benutzeranmeldeinformationen identifizieren. Azure Database for PostgreSQL verwendet ein bestimmtes Endpunktformat und erzwingt standardmäßig den sicheren Transport.
Ihr Serverendpunkt folgt dem Muster <server-name>.postgres.database.azure.com, wobei <server-name> es sich um den eindeutigen Namen handelt, den Sie beim Erstellen des Servers angegeben haben. Der vollqualifizierte Domänenname (Fully Qualified Domain Name, FQDN) wird entweder in die öffentliche IP-Adresse des Servers aufgelöst, wenn der öffentliche Zugang verwendet wird, oder in eine private IP-Adresse, wenn die VNet-Integration verwendet wird.
Für eine PostgreSQL-Verbindung sind diese Kernparameter erforderlich: host (Server-FQDN), Port (5432 für direkte Verbindungen oder 6432 für PgBouncer), Datenbankname, Benutzername (für Entra-Authentifizierung, Format verwenden username@servername ), Kennwort (statisches oder Entra-Token) und SSL-Modus. Unterschiedliche Clientbibliotheken und -tools akzeptieren diese Parameter in verschiedenen Formaten, einschließlich Verbindungszeichenfolgen, Schlüsselwortwertpaaren oder einzelnen Parametern.
Authentifizierungsmethoden
Azure Database for PostgreSQL unterstützt zwei Authentifizierungsansätze: Die Microsoft Entra-Authentifizierung bietet eine stärkere Sicherheit durch tokenbasierten Zugriff, während die native PostgreSQL-Authentifizierung herkömmliche Benutzernamen- und Kennwortanmeldeinformationen verwendet.
Die Microsoft Entra-Authentifizierung verwendet OAuth 2.0-Token anstelle von Kennwörtern. Dieser Ansatz ist in die Identitätsplattform von Azure integriert und bietet eine zentrale Identitätsverwaltung, beseitigt die Kennwortspeicherung (Token sind kurzlebig), unterstützt verwaltete Identitäten für von Azure gehostete Anwendungen und erstellt Überwachungspfade in Entra-Anmeldeprotokollen. Um entra-Authentifizierung zu verwenden, konfigurieren Sie einen Microsoft Entra-Administrator auf Ihrem Server (ein Benutzerkonto, eine Gruppe oder einen Dienstprinzipal). Nach der Konfiguration stellen Entra-Identitäten eine Verbindung her, indem sie ein Token aus der https://ossrdbms-aad.database.windows.net Ressource abrufen.
Der Verbindungsvorgang funktioniert wie folgt:
- Ihre Anwendung fordert ein Zugriffstoken von microsoft Entra ID an.
- Entra überprüft die Identität und gibt ein Token zurück.
- Ihre Anwendung stellt eine Verbindung mit PostgreSQL unter Verwendung des Tokens als Passwort her.
- PostgreSQL überprüft das Token für den konfigurierten Entra-Administrator.
In Python können Sie die azure-identity Bibliothek verwenden, um Token abzurufen:
from azure.identity import DefaultAzureCredential
credential = DefaultAzureCredential()
token = credential.get_token("https://ossrdbms-aad.database.windows.net/.default")
# Use token.token as the password in your connection string
Die DefaultAzureCredential Klasse versucht automatisch mehrere Authentifizierungsmethoden, einschließlich verwalteter Identität (bei Ausführung unter Azure), Azure CLI-Anmeldeinformationen (für die lokale Entwicklung) und andere Optionen.
Die native PostgreSQL-Authentifizierung speichert Benutzernamen und verschlüsselte Kennwörter in der Datenbank. Dieser Ansatz eignet sich, wenn Anwendungen Entra-Authentifizierung (Legacyanwendungen) nicht verwenden können, Sie Zugriff auf Identitäten außerhalb Ihres Entra-Mandanten gewähren müssen, oder wenn Sie während der Entwicklung in einer Umgebung ohne Azure-Konnektivität arbeiten. Wenn Sie die PostgreSQL-Authentifizierung verwenden, speichern Sie Kennwörter in Azure Key Vault anstelle der Anwendungskonfiguration, drehen Sie regelmäßig Kennwörter, verwenden Sie stark zufällig generierte Kennwörter und beschränken Sie die Berechtigungen jedes Datenbankbenutzers. Der Administratorbenutzername und das Kennwort, den Sie während der Servererstellung angeben, verwenden die PostgreSQL-Authentifizierung.
TLS/SSL-Konfiguration
Azure Database for PostgreSQL verschlüsselt alle Verbindungen mit Transport Layer Security (TLS). Der Server erfordert TLS standardmäßig und unterstützt TLS 1.2 und 1.3. Verbindungen mit älteren TLS-Versionen werden abgelehnt.
PostgreSQL-Clients verwenden den Parameter zum Steuern der sslmode Verschlüsselung und Zertifikatüberprüfung. Folgende Modi sind verfügbar:
- Deaktivieren: Keine Verschlüsselung. Azure lehnt Verbindungen mit diesem Modus ab.
- Ermöglichen: Verschlüsselt, wenn der Server dies erfordert, aber keine Zertifikate überprüft.
- Bevorzugen: Verschlüsselt, wenn der Server es unterstützt, aber keine Zertifikate überprüft.
- Erfordern: Erzwingt verschlüsselung, überprüft jedoch keine Zertifikate.
- verify-ca: Erzwingt verschlüsselung und überprüft das Serverzertifikat für vertrauenswürdige Zertifizierungsstellen.
- verify-full: Erzwingt Verschlüsselung, überprüft die Zertifizierungsstelle und bestätigt, dass der Zertifikat-Hostname mit dem Server übereinstimmt.
Verwenden Sie verify-full für Produktionsanwendungen, um sicherzustellen, dass Sie eine Verbindung mit dem echten Azure PostgreSQL-Server herstellen. Dieser Modus überprüft, ob der Server ein von einer vertrauenswürdigen Zertifizierungsstelle signiertes Zertifikat darstellt und dass der gemeinsame Name oder alternative Antragstellername des Zertifikats dem Serverhostnamen entspricht.
Die verify-ca und verify-full Modi erfordern, dass Ihr Client Zugriff auf die Root-CA-Zertifikate hat, die das Serverzertifikat signiert haben. Die meisten Betriebssysteme und Azure-Hostingumgebungen enthalten bereits die DigiCert- und Microsoft-Stamm-CAs, die Azure-Datenbank für PostgreSQL verwendet. Wenn die Zertifikatüberprüfung fehlschlägt, müssen Sie möglicherweise die Stammzertifikate aus dem PKI-Repository von Microsoft herunterladen und Ihren Client für die Verwendung konfigurieren.
Verbindungspooling mit PgBouncer
Azure Database for PostgreSQL umfasst integrierte PgBouncer, die Sie über die Konfigurationseinstellungen des Servers im Azure-Portal oder mithilfe der Azure CLI aktivieren können. Nach der Aktivierung verbinden Sie sich an Port 6432 anstelle von 5432.
Von Bedeutung
PgBouncer ist nur auf den Computeebenen "General Purpose" und "Memory Optimized" verfügbar. Wenn Ihr Server die Burstable-Stufe verwendet, können Sie den integrierten PgBouncer nicht aktivieren.
PgBouncer verwaltet einen Pool von Verbindungen zum Datenbankserver und multiplexen die Client-Verbindungen auf diesen Pool. Dies reduziert den Aufwand der Verbindungseinrichtung, was für Anwendungen nützlich ist, die viele kurzlebige Verbindungen machen.
So aktivieren Sie PgBouncer mithilfe der Azure CLI:
az postgres flexible-server parameter set \
--resource-group myResourceGroup \
--server-name myserver \
--name pgbouncer.enabled \
--value true
Aktualisieren Sie nach dem Aktivieren die Verbindungszeichenfolge so, dass Port 6432 verwendet wird:
postgresql://user@myserver.postgres.database.azure.com:6432/mydb?sslmode=require
Optimierungsstrategien für Verbindungspooling, einschließlich Poolgröße und Transaktions- und Sitzungsmodi, werden im Modul "Optimieren der Leistung, Indizierung und Skalierung" behandelt.
Überlegungen zum Netzwerkzugriff
Azure Database for PostgreSQL unterstützt zwei Netzwerkmodelle: öffentlicher Zugriff mit Firewallregeln und privaten Zugriff mit VNet-Integration. Ihr Plattform- oder Betriebsteam konfiguriert diese Einstellungen in der Regel, aber das Verständnis dieser Einstellungen hilft Ihnen bei der Behandlung von Verbindungsproblemen.
Bei öffentlichem Zugriff verfügt der Server über eine öffentliche IP-Adresse und Firewallregeln, die steuern, welche Client-IPs eine Verbindung herstellen können. Wenn Sie keine Verbindung von Ihrem Entwicklungscomputer herstellen können, überprüfen Sie, ob Ihre IP-Adresse in den Firewallregeln zulässig ist.
Bei privatem Zugriff verfügt der Server nur über eine private IP-Adresse in einem virtuellen Azure-Netzwerk. Sie können nur Verbindungen von Ressourcen innerhalb desselben VNet, gekoppelten Netzwerken oder über VPN/ExpressRoute herstellen. Privater Zugriff ist in Produktionsumgebungen üblich, in denen die Netzwerkisolation erforderlich ist.
Beispiele für Verbindungszeichenfolgen
Die folgenden Beispiele zeigen allgemeine Verbindungszeichenfolgenmuster für Azure Database für PostgreSQL.
# Basic connection with SSL required
postgresql://myuser:mypassword@myserver.postgres.database.azure.com/mydb?sslmode=require
# Connection with certificate verification
postgresql://myuser:mypassword@myserver.postgres.database.azure.com/mydb?sslmode=verify-full&sslrootcert=/etc/ssl/certs/ca-certificates.crt
# Connection through PgBouncer (note port 6432)
postgresql://myuser:mypassword@myserver.postgres.database.azure.com:6432/mydb?sslmode=require