Sichere Konnektivität mit TLS in Azure Database for PostgreSQL

Azure Database for PostgreSQL erzwingt die Verbindung Ihrer Clientanwendungen mit einer flexiblen Azure-Serverinstanz für PostgreSQL mithilfe von Transport Layer Security (TLS). TLS ist ein Standardprotokoll der Branche, das verschlüsselte Netzwerkverbindungen zwischen dem Datenbankserver und Clientanwendungen gewährleistet. Bei der TLS handelt es sich um eine aktualisierte Version von Secure Sockets Layer (SSL). Die Begriffe SSL und TLS werden immer noch austauschbar verwendet.

Zertifikatketten

Eine Zertifikatkette ist eine geordnete Liste von Zertifikaten, die ein TLS/SSL-Zertifikat und Zertifikate von Zertifizierungsstellen enthalten. Sie ermöglichen dem Empfänger zu überprüfen, ob der Absender und alle CAs vertrauenswürdig sind. Die Kette oder der Pfad beginnt mit dem TLS/SSL-Zertifikat. Jedes Zertifikat in der Kette wird von der Entität signiert, die durch das nächste Zertifikat in der Kette identifiziert wird.

Die Kette wird mit einem Zertifikat der Stammzertifizierungsstelle abgeschlossen. Dieses Zertifikat wird immer von der Zertifizierungsstelle selbst signiert. Die Signaturen aller Zertifikate in der Kette müssen bis zum Zertifikat der Stammzertifizierungsstelle überprüft werden.

Jedes Zertifikat, das sich in der Kette zwischen dem SSL/TLS-Zertifikat und dem Zertifikat der Stammzertifizierungsstelle befindet, wird als Zwischenzertifikat bezeichnet.

TLS-Versionen

Mehrere Behörden verwalten weltweit Richtlinien für TLS bezüglich der Netzwerksicherheit. In den Vereinigten Staaten umfassen diese Organisationen das Department of Health and Human Services und das National Institute of Standards and Technology. Das von TSL gebotene Sicherheitsniveau wird am stärksten von der TLS-Protokollversion und den unterstützten Verschlüsselungssammlungen beeinflusst.

Eine Verschlüsselungssammlung ist eine Reihe von Algorithmen, die eine Verschlüsselung, einen Schlüsselaustauschalgorithmus und einen Hashingalgorithmus enthalten. Sie werden gemeinsam verwendet, um eine sichere TLS-Verbindung herzustellen. Die meisten TLS-Clients und -Server unterstützen mehrere Alternativen. Sie müssen verhandeln, wenn sie eine sichere Verbindung herstellen, um eine gemeinsame TLS-Version und Verschlüsselungssammlung auszuwählen.

Azure Database for PostgreSQL unterstützt die TLS-Versionen 1.2 und höher. In RFC 8996 gibt die Internet Engineering Task Force (IETF) explizit an, dass TLS 1.0 und TLS 1.1 nicht verwendet werden dürfen. Beide Protokolle wurden Ende 2019 als veraltet gekennzeichnet.

Alle eingehenden Verbindungen, die frühere Versionen des TLS-Protokolls (z. B. TLS 1.0 und TLS 1.1) verwenden, werden standardmäßig verweigert.

Die IETF veröffentlichte die TLS 1.3-Spezifikation in RFC 8446 im August 2018, und dies ist jetzt die am häufigsten verwendete und empfohlene TLS-Version. TLS 1.3 ist schneller und sicherer als TLS 1.2.

Die Zertifikatauthentifizierung wird mithilfe von SSL-Clientzertifikaten zur Authentifizierung durchgeführt. In diesem Szenario vergleicht der PostgreSQL-Server das CN-Attribut (allgemeiner Name) des angezeigten Clientzertifikats mit dem angeforderten Datenbankbenutzer.

Zu diesem Zeitpunkt unterstützt Azure Database for PostgreSQL nicht:

• Auf SSL-Zertifikaten basierende Authentifizierung.
• Benutzerdefinierte SSL/TLS-Zertifikate.

Um ihren aktuellen TLS\SSL-Verbindungsstatus zu ermitteln, können Sie die sslinfo-Erweiterung laden und dann die Funktion „ssl_is_used()“ aufrufen, um zu ermitteln, ob SSL verwendet wird. Die Funktion gibt t zurück, wenn die Verbindung SSL verwendet. Andernfalls wird fzurückgegeben. Sie können auch alle Informationen zur SSL-Verwendung der flexiblen Serverinstanz Ihrer Azure-Datenbank für PostgreSQL gegliedert nach Prozess, Client und Anwendung mithilfe der folgenden Abfrage sammeln.

SELECT datname as "Database name", usename as "User name", ssl, client_addr, application_name, backend_type
   FROM pg_stat_ssl
   JOIN pg_stat_activity
   ON pg_stat_ssl.pid = pg_stat_activity.pid
   ORDER BY ssl;

Sie können als Test auch den Befehl openssl direkt verwenden:

openssl s_client -starttls postgres -showcerts -connect <your-postgresql-server-name>:5432

Dieser Befehl gibt zahlreiche Protokollinformationen auf niedriger Ebene aus, z. B. die TLS-Version und das Verschlüsselungsverfahren. Sie müssen die Option -starttls postgres verwenden. Andernfalls meldet dieser Befehl, dass kein SSL verwendet wird. Die Verwendung dieses Befehls erfordert mindestens OpenSSL 1.1.1.

Um die neueste, sicherste TLS-Version für den Konnektivitätsschutz vom Client zu einer flexiblen Serverinstanz von Azure Database für PostgreSQL zu erzwingen, setzen Sie ssl_min_protocol_version auf 1.3. Diese Einstellung erfordert Clients, die eine Verbindung mit Ihrer Azure-Datenbank auf einer flexiblen PostgreSQL-Serverinstanz herstellen, nur diese Version des Protokolls für die sichere Kommunikation zu verwenden. Da ältere Clients diese Version nicht unterstützen, können sie möglicherweise nicht mit dem Server kommunizieren.

Konfigurieren von SSL auf dem Client

Standardmäßig führt PostgreSQL keine Überprüfung des Serverzertifikats durch. Das bedeutet, dass es möglich ist, die Identität des Servers zu spoofen (z. B. durch Änderung eines DNS-Eintrags oder durch Übernahme der IP-Adresse des Servers), ohne dass der Client davon weiß. Alle SSL-Optionen sind mit Mehraufwand in Form von Verschlüsselung und Schlüsselaustausch verbunden, daher muss ein Kompromiss zwischen Leistung und Sicherheit eingegangen werden.

Um Spoofing zu verhindern, muss die SSL-Zertifikatüberprüfung auf dem Client verwendet werden.

Es gibt viele Verbindungsparameter zum Konfigurieren des Clients für SSL. Dies sind einige wichtige:

• ssl: Herstellen einer Verbindung mit SSL. Diese Eigenschaft benötigt keinen zugeordneten Wert. Das bloße Vorhandensein gibt eine SSL-Verbindung an. Aus Gründen der Kompatibilität mit zukünftigen Versionen wird der Wert true bevorzugt. In diesem Modus überprüft der Clienttreiber bei der Einrichtung einer SSL-Verbindung die Identität des Servers, um Man-in-the-Middle-Angriffe zu verhindern. Dazu wird überprüft, ob das Serverzertifikat von einer vertrauenswürdigen Autorität signiert ist und dass der Host, mit dem Sie eine Verbindung herstellen, mit dem Hostnamen im Zertifikat identisch ist.

• sslmode: Wenn Sie eine Verschlüsselung benötigen und möchten, dass die Verbindung fehlschlägt, wenn sie nicht verschlüsselt werden kann, legen Sie sslmode=require fest. Dadurch wird sichergestellt, dass der Server so konfiguriert ist, dass SSL-Verbindungen für diesen Host/diese IP-Adresse akzeptiert werden und dass der Server das Clientzertifikat erkennt. Wenn der Server keine SSL-Verbindungen akzeptiert oder das Clientzertifikat nicht erkannt wird, schlägt die Verbindung fehl. In der folgenden Tabelle sind gültige Werte für diese Einstellung aufgeführt:

  SSL-Modus	Explanation
  disable	Verschlüsselung wird nicht verwendet.
  allow	Verschlüsselung wird verwendet, wenn die Servereinstellungen dies erfordern oder erzwingen.
  prefer	Verschlüsselung wird verwendet, wenn Servereinstellungen dies zulassen.
  require	Verschlüsselung wird verwendet. Dadurch wird sichergestellt, dass der Server so konfiguriert ist, dass SSL-Verbindungen für diese Host-IP-Adresse akzeptiert werden und dass der Server das Clientzertifikat erkennt.
  verify-ca	Verschlüsselung wird verwendet. Überprüft die Serverzertifikatsignatur anhand des Zertifikats, das auf dem Client gespeichert ist.
  verify-full	Verschlüsselung wird verwendet. Überprüft die Serverzertifikatsignatur und den Hostnamen anhand des Zertifikats, das auf dem Client gespeichert ist.

Der verwendete sslmode-Standardmodus unterscheidet sich zwischen libpq-basierten Clients (z. B. psql) und JDBC-Clients. Die libpq-basierten Clients werden standardmäßig auf prefer festgelegt. JDBC-Clients verwenden standardmäßig verify-full.

• sslcert, sslkey und sslrootcert: Diese Parameter können den Standardspeicherort des Clientzertifikats, den PKCS-8-Clientschlüssel und das Stammzertifikat außer Kraft setzen. Sie sind standardmäßig /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 bzw. /defaultdir/root.crt, wobei defaultdir in Linux-Systemen ${user.home}/.postgresql/ und unter Windows %appdata%/postgresql/ ist.

Zertifizierungsstellen (Certificate Authorities, CAs) sind die für die Ausstellung von Zertifikaten zuständigen Institutionen. Eine vertrauenswürdige Zertifizierungsstelle ist eine Entität, die berechtigt ist, die Identität Anderer zu überprüfen. Damit dieses Modell funktioniert, müssen sich alle Teilnehmer auf eine Reihe vertrauenswürdiger Zertifizierungsstellen einigen. Alle Betriebssysteme und die meisten Webbrowser enthalten eine Reihe vertrauenswürdiger Zertifizierungsstellen.

Die Verwendung der sslmode-Konfigurationseinstellungen verify-ca und verify-full kann auch als Anheften von Zertifikaten bezeichnet werden. In diesem Fall müssen Stamm-Zertifizierungsstellenzertifikate auf dem PostgreSQL-Server mit der Zertifikatsignatur und sogar dem Hostnamen des Clientzertifikats übereinstimmen.

Unter Umständen müssen Sie regelmäßig auf dem Client gespeicherte Zertifikate aktualisieren, wenn sich Zertifizierungsstellen in PostgreSQL-Serverzertifikaten ändern oder ablaufen. Um festzustellen, ob Sie Zertifizierungsstellenzertifikate anheften, lesen Sie den Artikel zum Anheften von Zertifikaten und Azure-Diensten.

Weitere Informationen zur SSL\TLS-Konfiguration auf dem Client finden Sie in der PostgreSQL-Dokumentation.

Für Clients, die die sslmode-Konfigurationseinstellungen verify-ca und verify-full verwenden (d. h. das Anheften von Zertifikaten), müssen sie drei Stammzertifizierungsstellenzertifikate in den Clientzertifikatspeichern bereitstellen:

• Die Stammzertifizierungsstellenzertifikate DigiCert Global Root G2 und Microsoft RSA Root CA 2017, da Dienste von Digicert zu Microsoft CA migriert werden.
• Digicert Global Root CA für die Legacykompatibilität.

Herunterladen von Stamm-CA-Zertifikaten und Aktualisieren von Anwendungsclients in Szenarien zum Anheften von Zertifikaten

Um Clientanwendungen in Szenarien zum Anheften von Zertifikaten zu aktualisieren, können Sie Zertifikate herunterladen:

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• Digicert Global Root CA

Um Zertifikate in Clientzertifikatspeicher zu importieren, müssen Sie die Zertifikate möglicherweise von CRT-Dateien in das PEM-Format konvertieren, nachdem Sie die Zertifikatsdateien von den obigen URIs heruntergeladen haben. Sie können das OpenSSL-Hilfsprogramm verwenden, um diese Dateikonvertierungen durchzuführen:

openssl x509 -inform DER -in certificate.crt -out certificate.pem -outform PEM

Informationen zum Aktualisieren von Zertifikatspeichern von Clientanwendungen mit neuen Stamm-Zertifizierungsstellenzertifikaten finden Sie unter Aktualisieren von Client-TLS-Zertifikaten für Anwendungsclients.

1. Erleben Sie einen Verlust der Konnektivität von der Clientanwendung mit der flexiblen Serverinstanz für Azure Database for PostgreSQL – Supportticket geöffnet.
2. Wenn Ihr Zwischenzertifikat rotiert wurde, müssen Sie möglicherweise Ihren Clientzertifikatsspeicher mit dem neuen Zwischenzertifikat aktualisieren.
3. So überprüfen Sie, ob Ihr Zwischenzertifikat angeheftet ist – siehe Anheften von Zertifikaten und Azure-Dienste.

Lesereplikate mit Szenarien zum Anheften von Zertifikaten

Mit der Migration der Stammzertifizierungsstelle zu Microsoft RSA Root Certificate Authority 2017 ist es möglich, dass neu erstellte Replikate in einem neueren Stamm-Zertifizierungsstellenzertifikat als der zuvor erstellte primäre Server vorhanden sind. Daher müssen Clients, welche die sslmode-Konfigurationseinstellungen verify-ca und verify-full (d. h. das Anheften von Zertifikaten) verwenden, für eine ununterbrochene Konnektivität drei Stamm-Zertifizierungsstellenzertifikate akzeptieren:

• Microsoft RSA Root CA 2017
• DigiCert Global Root G2
• Digicert Global Root CA

Zurzeit unterstützt Azure Database for PostgreSQL keine zertifikatbasierte Authentifizierung.

Testen von Clientzertifikaten durch Herstellen einer Verbindung mit psql in Szenarien mit Anheften von Zertifikaten

Sie können die psql-Befehlszeile auf Ihrem Client verwenden, um die Konnektivität mit dem Server in Szenarien zum Anheften von Zertifikaten zu testen:

$ psql "host=hostname.postgres.database.azure.com port=5432 user=myuser dbname=mydatabase sslmode=verify-full sslcert=client.crt sslkey=client.key sslrootcert=ca.crt"

Weitere Informationen zu SSL- und Zertifikatparametern finden Sie in der psql-Dokumentation.

Testen der TLS-/SSL-Konnektivität

Bevor Sie versuchen, von der Clientanwendung aus auf Ihren Server mit SSL-Unterstützung zuzugreifen, stellen Sie sicher, dass Sie über „psql“ darauf zugreifen können. Wenn Sie eine SSL-Verbindung eingerichtet haben, sollte die Ausgabe ähnlich wie im folgenden Beispiel angezeigt werden:

psql (14.5)SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)Type "help" for help.

Sie können auch die sslinfo-Erweiterung laden und dann die ssl_is_used()-Funktion aufrufen, um zu ermitteln, ob SSL verwendet wird. Die Funktion gibt t zurück, wenn die Verbindung SSL verwendet. Andernfalls wird fzurückgegeben.

Verschlüsselungssammlungen

Eine Verschlüsselungssammlung ist eine Reihe von kryptografischen Algorithmen. TLS- und SSL-Protokoll verwenden Algorithmen einer Verschlüsselungssammlung zum Erstellen von Schlüsseln und Verschlüsseln von Informationen.

Eine Verschlüsselungssammlung wird als lange Zeichenfolge von scheinbar zufälligen Informationen angezeigt. Jedoch enthält jedes Segment dieser Zeichenfolge wichtige Informationen. Im Allgemeinen besteht diese Datenzeichenfolge aus mehreren Schlüsselkomponenten:

• Protokoll (d. h. TLS 1.2 oder TLS 1.3)
• Schlüsselaustausch- oder Vereinbarungsalgorithmus
• Algorithmus für digitale Signatur (Authentifizierung)
• Massenverschlüsselungsalgorithmus
• Nachrichtenauthentifizierungscode-Algorithmus (MAC)

Unterschiedliche Versionen von SSL/TLS unterstützen unterschiedliche Verschlüsselungssammlungen. TLS 1.2-Verschlüsselungssammlungen können nicht mit TLS 1.3-Verbindungen ausgehandelt werden und umgekehrt.

Derzeit unterstützt Azure Database for PostgreSQL viele Verschlüsselungssammlungen mit der TLS 1.2-Protokollversion, die in die Kategorie HIGH:!aNULL fällt.

Troubleshoot

Verwenden Sie die Anleitungen in diesem Abschnitt "Problembehandlung", um häufige TLS/SSL-Probleme schnell zu identifizieren und zu beheben. Beginnen Sie mit der Wiedergabe des Problems und sammeln Sie Diagnosedaten (clientseitige Fehlermeldungen, psql-Ausgabe, OpenSSL-s_client Ausgabe und Serverprotokolle), und überprüfen Sie dann die Serverparameter (require_secure_transport, ssl_min_protocol_version, ssl_max_protocol_version), die Zertifikatkette und die Client-Sslmode/sslrootcert-Einstellungen, um Konflikte in Protokollversionen, Verschlüsselungssammlungen oder fehlenden/gedrehten Zertifikaten zu ermitteln.

TLS/SSL-Konnektivitätsfehler

1. Der erste Schritt zur Problembehandlung der TLS/SSL-Protokollversionskompatibilität besteht darin, die Fehlermeldungen zu identifizieren, die Ihnen oder Ihren Benutzern angezeigt werden, wenn sie versuchen, auf Ihre Azure-Datenbank für PostgreSQL flexible Serverinstanz unter TLS-Verschlüsselung vom Client zuzugreifen. Je nach Anwendung und Plattform können die Fehlermeldungen unterschiedlich sein. In vielen Fällen weisen sie jedoch auf das zugrunde liegende Problem hin.
2. Um die Kompatibilität der TLS/SSL-Protokollversion zu gewährleisten, sollten Sie die TLS/SSL-Konfiguration des Datenbankservers und des Anwendungsclients überprüfen, um sicherzustellen, dass sie kompatible Versionen und Verschlüsselungssammlungen unterstützen.
3. Analysieren Sie Diskrepanzen oder Lücken zwischen dem Datenbankserver und den TLS/SSL-Versionen und Verschlüsselungssammlungen des Clients. Versuchen Sie, sie zu beheben, indem Sie bestimmte Optionen aktivieren oder deaktivieren, Software aktualisieren oder herabstufen oder Zertifikate oder Schlüssel ändern. Beispielsweise müssen Sie je nach Sicherheits- und Kompatibilitätsanforderungen bestimmte TLS/SSL-Versionen auf dem Server oder Client aktivieren oder deaktivieren. Beispielsweise müssen Sie TLS 1.0 und TLS 1.1 deaktivieren, die als unsicher und veraltet gelten, und TLS 1.2 und TLS 1.3 aktivieren, die sicherer und moderner sind.
4. Das neueste Zertifikat, das mit „Microsoft RSA Root CA 2017“ ausgestellt wurde, hat in der Zertifikatkette ein Zwischenzertifikat, das von „Digicert Global Root G2 CA“ quersigniert ist. Bei einigen Clientbibliotheken von Postgres, die die Einstellung sslmode=verify-full oder sslmode=verify-ca verwenden, kann es zu Verbindungsfehlern mit Stammzertifizierungsstellen-Zertifikaten kommen, die mit Zwischenzertifikaten quersigniert sind. Dies führt zu alternativen Vertrauenspfaden.

Um diese Probleme zu umgehen, fügen Sie dem Clientzertifikatspeicher alle drei erforderlichen Zertifikate hinzu, oder geben Sie den Parameter sslrootcert explizit an. Oder legen Sie die PGSSLROOTCERT-Umgebungsvariable vom Standardwert %APPDATA%\postgresql\root.crt auf den lokalen Pfad fest, in dem das Stammzertifizierungsstellenzertifikat „Microsoft RSA Root CA 2017“ platziert wird.

Probleme beim Anheften von Zertifikaten

1. Überprüfen Sie, ob Sie das Anheften von Zertifikaten in Ihrer Anwendung verwenden.
2. Erstellen Sie eine Liste der Zertifikate, die sich in Ihrem vertrauenswürdigen Stammspeicher befinden
   1. Sie können beispielsweise programmgesteuert eine Liste vertrauenswürdiger Zertifikate im Java Key Store abrufen.
   2. Sie können z. B. den Java-Keystore "cacerts" überprüfen, um festzustellen, ob er bereits erforderliche Zertifikate enthält.
3. Sie verwenden Zertifikat-Pinning, wenn Sie einzelne Zwischenzertifikate oder einzelne PostgreSQL-Serverzertifikate haben.
4. Um das Anheften von Zertifikaten zu entfernen, entfernen Sie alle Zertifikate aus Ihrem vertrauenswürdigen Stammspeicher, und fügen Sie die neuen Zertifikate hinzu.
   1. Sie können die aktualisierten Zertifikate aus dem offiziellen Repository von Microsoft herunterladen: Details der Azure-Zertifizierungsstelle.
      1. Aktuelle Kette:
         1. DigiCert Global Root G2
         2. Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
      2. Neue Kette:
         1. DigiCert Global Root G2
         2. Microsoft TLS RSA Root G2
         3. Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16

Wenn Probleme auftreten, auch nachdem Sie diese Schritte ausgeführt haben, wenden Sie sich an den Microsoft-Support. Schließen Sie den Titel ICA Rotation 2026 ein.

Verwandte Inhalte

• Azure-Portal
• Azure CLI
• Azure-Portal
• Azure CLI