Teilen über

Sichere Konnektivität mit TLS und SSL in flexiblem Azure Database for PostgreSQL-Server

  • Artikel

GILT FÜR: Azure Database for PostgreSQL – Flexible Server

Ein flexibler Azure Database for PostgreSQL-Server erzwingt das Verbinden Ihrer Clientanwendungen mit dem flexiblen Azure Database for PostgreSQL-Server per TLS (Transport Layer Security). 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).

Was ist TLS?

TLS aus Netscape Communications Corp. Secure Sockets Layer Show verdrängt es regelmäßig, allerdings werden die Begriffe SSL oder SSL/TLS manchmal noch verwendet. TLS besteht aus zwei Ebenen: die TLS-Datensatz Show und die TLS-Handshake Show. Die Datensatz Show sorgt für die Sicherheit der Assoziation, während die Handshake-Show es dem Server und dem Kunden ermöglicht, sich gegenseitig zu bestätigen und Verschlüsselungsbewertungen und kryptografische Schlüssel zu koordinieren, bevor irgendwelche Informationen ausgetauscht werden.

Diagramm der typischen TLS 1.2-Handshakesequenz

Das obige Diagramm zeigt die typische TLS 1.2-Handshakesequenz, die aus folgenden Komponenten besteht:

  1. Der Client beginnt mit dem Senden einer Nachricht namens ClientHello, die im Wesentlichen die Bereitschaft zur Kommunikation über TLS 1.2 mit einer Reihe von Suites mit Verschlüsselungsverfahren ausdrückt, die der Client unterstützt
  2. Der Server empfängt dies und antwortet mit einem ServerHello, das der Kommunikation mit dem Client über TLS 1.2 mit einer bestimmten Suites mit Verschlüsselungsverfahren zustimmt
  3. Zusammen mit dem sendet der Server seine Schlüsselfreigabe. Die Einzelheiten dieser Schlüsselfreigabe hängen davon ab, welche Suites mit Verschlüsselungsverfahren ausgewählt wurde. Damit sich Client und Server auf einen kryptografischen Schlüssel einigen können, müssen sie den Teil des anderen erhalten, den sie gemeinsam nutzen.
  4. Der Server sendet das (von der CA signierte) Zertifikat und eine Signatur auf Teilen von ClientHello und ServerHello, einschließlich der Schlüsselfreigabe, so dass der Client weiß, dass diese authentisch sind.
  5. Nachdem der Client die oben genannten Daten erfolgreich empfangen hat, generiert er dann seinen eigenen Schlüsselanteil, mischt ihn mit dem Schlüsselanteil des Servers und erzeugt so die Verschlüsselungsschlüssel für die Sitzung.
  6. Als letzten Schritt sendet der Client dem Server seinen Schlüsselanteil, aktiviert die Verschlüsselung und sendet eine Nachricht Fertig (die ein Hash eines Protokolls der bisherigen Ereignisse ist). Der Server führt die gleichen Aktionen aus: Er kombiniert die Schlüsselfreigaben, um den Schlüssel abzurufen und sendet seine eigene „Fertig“-Nachricht.
  7. Zu diesem Zeitpunkt können Anwendungsdaten an die Verbindung verschlüsselt werden.

Zertifikatketten

Eine Zertifikatkette ist eine sortierte Liste von Zertifikaten, die ein SSL/TLS- und ein ZS-Zertifikat (Zertifizierungsstelle) enthalten, mit der Empfänger und Empfängerinnen überprüfen können, ob der Absender bzw. die Absenderin und alle Zertifizierungsstellen vertrauenswürdig sind. Die Kette oder der Pfad beginnt mit dem SSL/TLS-Zertifikat, und 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. Das Zertifikat der Stammzertifizierungsstelle wird immer von der Zertifizierungsstelle (ZS) 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

Es gibt mehrere Behörden weltweit, die Richtlinien für TLS in Bezug auf die Netzwerksicherheit bereitstellen, darunter das Department of Health and Human Services (HHS) oder das National Institute of Standards and Technology (NIST) in den USA. Das von TSL gebotene Sicherheitsniveau wird am stärksten von der TLS-Protokollversion und den unterstützten Verschlüsselungssammlungen beeinflusst. Eine Verschlüsselungssammlung besteht aus einer Reihe von Algorithmen, einschließlich einer Verschlüsselung, eines Schlüsselaustauschalgorithmus und eines Hashing-Algorithmus, die gemeinsam zum Herstellen einer sicheren TLS-Verbindung verwendet werden. Die meisten TLS-Clients und -Server unterstützen verschiedene Alternativen, sodass sie beim Herstellen einer sicheren Verbindung eine Aushandlung vornehmen müssen, um eine gemeinsame TLS-Version und eine 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 Internet Engineering Task Force (IETF) veröffentlichte die TLS 1.3-Spezifikation in RFC 8446 im August 2018 und ist jetzt die am häufigsten verwendete und empfohlene TLS-Version. TLS 1.3 ist schneller und sicherer als TLS 1.2.

Hinweis

SSL- und TLS-Zertifikate bestätigen, dass Ihre Verbindung durch moderne Verschlüsselungsprotokolle geschützt ist. Indem Sie Ihre Verbindung über das Netzwerk verschlüsseln, verhindern Sie den nicht autorisierten Zugriff auf Ihre Daten während der Übertragung. Daher empfehlen wir Ihnen dringend, die neuesten Versionen von TLS zum Verschlüsseln Ihrer Verbindungen mit einem flexiblen Azure Database for PostgreSQL-Server zu verwenden.
Obwohl dies nicht zu empfehlen ist, haben Sie bei Bedarf die Möglichkeit, TLS/SSL für Verbindungen mit einem flexiblen Azure Database for PostgreSQL-Server zu deaktivieren, indem Sie den Serverparameter require_secure_transport auf „OFF“ festlegen. Sie können auch die TLS-Version festlegen, indem Sie die Serverparameter ssl_min_protocol_version und ssl_max_protocol_version festlegen.

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. Flexible Azure Database for PostgreSQL-Server unterstützen derzeit keine Authentifizierung, die auf SSL-Zertifikaten basiert.

Hinweis

Azure Database for PostgreSQL – Flexibler Server unterstützt derzeit keine benutzerdefinierten SSL/TLS-Zertifikate.

Hinweis

Microsoft hat Stammzertifizierungsstellenänderungen für verschiedene Azure-Dienste durchlaufen, einschließlich Azure-Datenbank für PostgreSQL – Flexible Server , wie in diesem Dokument beschrieben und Konfigurieren von SSL im Abschnitt "Client" weiter unten.

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 „f“ zurückgegeben. Sie können auch alle Informationen zur SSL-Nutzung Ihrer Instanz des flexiblen Azure Database for PostgreSQL-Servers nach Prozess, Client und Anwendung erfassen, indem Sie die folgende Abfrage verwenden:

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, z. B.:

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

Dieser Befehl druckt zahlreiche Protokollinformationen auf niedriger Ebene, einschließlich der TLS-Version, des Verschlüsselungsverfahrens usw. Sie müssen die Option „-starttls postgres“ verwenden, ansonsten meldet dieser Befehl, dass kein SSL verwendet wird. Die Verwendung dieses Befehls erfordert mindestens OpenSSL 1.1.1.

Hinweis

Legen Sie zum Erzwingen der neuesten, sichersten TLS-Version für den Konnektivitätsschutz vom Client zum flexiblen Azure Database for PostgreSQL-Server ssl_min_protocol_version auf 1.3 fest. Dies würde erfordern, dass Clients, die eine Verbindung mit Ihrer Instanz des flexiblen Azure Database for PostgreSQL-Servers herstellen, nur diese Version des Protokolls benutzen, um sicher zu kommunizieren. Ältere Clients, da sie diese Version nicht unterstützen, können jedoch 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. Für uns sind nur wenige wichtig:

  1. ssl. Stellen Sie eine Verbindung mit SSL her. 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 Mittelsmannangriffe 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.
  2. 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 diese Host-/IP-Adresse akzeptiert werden und dass der Server das Clientzertifikat erkennt. Anders ausgedrückt, wenn der Server keine SSL-Verbindungen akzeptiert oder das Clientzertifikat nicht erkannt wird, schlägt die Verbindung fehl. Die unten stehende Tabelle listet Werte für diese Einstellung auf:
SSL-Modus Erklärung
disable Verschlüsselung wird nicht verwendet
allow Verschlüsselung wird verwendet, wenn die Servereinstellungen dies erfordern\erzwingen
Bevorzugen Verschlüsselung wird verwendet, wenn die 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 außerdem die Serverzertifikatsignatur anhand des Zertifikats, das auf dem Client gespeichert ist
verify-full Verschlüsselung wird verwendet. Überprüft außerdem 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. Bei libpq-basierten Clients lautet der Standardwert prefer, und bei JDBC-Clients lautet er verify-full.

  1. sslcert, sslkey und sslrootcert. Diese Parameter können den Standardspeicherort des Clientzertifikats, den PKCS-8-Clientschlüssel und das Stammzertifikat außer Kraft setzen. Diese werden standardmäßig auf „/defaultdir/postgresql.crt“, „/defaultdir/postgresql.pk8“ und „/defaultdir/root.crt“ festgelegt, wobei „defaultdir“ in +nix-Systemen „${user.home}/.postgresql/“ und unter Windows „%appdata%/postgresql/“ ist.

Zertifizierungsstellen (ZS) 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.

Hinweis

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. Es gilt zu beachten, dass Sie unter Umständen regelmäßig auf dem Client gespeicherte Zertifikate aktualisieren müssen, wenn sich Zertifizierungsstellen auf PostgreSQL-Serverzertifikaten ändern oder ablaufen. Um festzustellen, ob Sie Zertifizierungsstellenzertifikate anheften, lesen Sie bitte den Artikel zum Anheften von Zertifikaten.

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

Hinweis

Für Clients, die verify-ca und verify-full, d.h. die Konfigurationseinstellungen für den sslmode-Modus verwenden, müssen drei Stammzertifizierungsstellenzertifikate in den Clientzertifikatspeichern bereitstellen: Die Stammzertifizierungsstellenzertifikate DigiCert Global Root G2 und Microsoft RSA Root Certificate Authority 2017, da Dienste von Digicert zu Microsoft CA migrieren. Zur Legacykompatibilität Digicert Global Root CA.

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

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

Um Zertifikate in den 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 für diese Dateikonvertierungen das OpenSSL-Hilfsprogramm verwenden, wie im folgenden Beispiel gezeigt:

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

Detaillierte Informationen zum Aktualisieren von Zertifikatspeichern von Clientanwendungen mit neuen Stamm-Zertifizierungsstellenzertifikaten finden Sie in dieser Schrittanleitung.

Wichtig

Bei einigen Clientbibliotheken von Postgres, die die Einstellung sslmode=verify-full verwenden, kann es zu Verbindungsfehlern mit Stammzertifizierungsstellen-Zertifikaten kommen, die mit Zwischenzertifikaten quersigniert sind, was zu alternativen Vertrauenspfaden führt. In diesem Fall wird empfohlen, den Parameter sslrootcert (siehe oben) explizit anzugeben oder die Umgebungsvariable PGSSLROOTCERT auf den lokalen Pfad festzulegen, in dem das Stammzertifizierungsstellen-Zertifikat Root Certification Authority 2017 von Microsoft RSA abgelegt ist, anstatt des Standardwerts %APPDATA%\postgresql\root.crt.

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, drei Stamm-Zertifizierungsstellenzertifikate akzeptieren:

Hinweis

Azure Database for PostgreSQL – Flexibler Server unterstützt derzeit keine zertifikatbasierte Authentifizierung.

Testen von Clientzertifikaten durch Herstellen einer Verbindung mit psql in Zertifikatanheftungsszenarien

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


$ 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 SSL/TLS-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. Die Ausgabe sollte etwa wie folgt aussehen, wenn Sie eine SSL-Verbindung eingerichtet haben.

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 „f“ zurückgegeben.

Verschlüsselungssammlungen

Eine Cipher Suite ist eine Sammlung kryptografischer Algorithmen. TLS- und SSL-Protokoll verwenden Algorithmen einer Verschlüsselungssammlung zum Erstellen von Schlüsseln und Verschlüsseln von Informationen. Eine Suite mit Verschlüsselungsverfahren 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 Suites mit Verschlüsselungsverfahren. TLS 1.2-Suites mit Verschlüsselungsverfahren können nicht mit TLS 1.3-Verbindungen ausgehandelt werden und umgekehrt. Ab diesem Zeitpunkt unterstützt Azure Database for PostgreSQL – Flexibler Server viele Verschlüsselungssammlungen mit der TLS 1.2-Protokollversion, die in die Kategorie HIGH:!aNULL fallen.

Problembehandlung bei SSL\TLS-Konnektivitätsfehlern

  1. Der erste Schritt zur Problembehandlung der Kompatibilität der SSL/TLS-Protokollversion besteht darin, die Fehlermeldungen zu identifizieren, die Sie oder Ihre Benutzer sehen, wenn Sie versuchen, unter TLS-Verschlüsselung vom Client auf Ihren flexiblen Azure Database for PostgreSQL-Server zugreifen. 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 SSL/TLS-Protokollversion zu gewährleisten, sollten Sie die SSL/TLS-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 SSL/TLS-Versionen und Verschlüsselungssammlungen des Clients, und versuchen Sie, sie zu beheben, indem Sie bestimmte Optionen aktivieren oder deaktivieren, Software aktualisieren oder herabstufen oder Zertifikate oder Schlüssel ändern. Es kann beispielsweise sein, dass Sie je nach Sicherheits- und Kompatibilitätsanforderungen bestimmte SSL/TLS-Versionen auf dem Server oder Client aktivieren oder deaktivieren müssen, z. B. 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 der Microsoft RSA-Stammzertifizierungsstelle 2017 ausgestellt wurde, verfügt über zwischen der Kette, die von Digicert Global Root G2 CAsigniert wurde. 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, was zu alternativen Vertrauenspfaden führt. Um diese Probleme zu umgehen, fügen Sie alle drei erforderlichen Zertifikate zum Clientzertifikatspeicher hinzu, oder geben Sie explizit sslrootcert-Parameter an, wie oben erläutert, oder legen Sie die Umgebungsvariable PGSSLROOTCERT auf den lokalen Pfad fest, in dem das Zertifikat der Microsoft RSA-Stammzertifizierungsstelle 2017-Stammzertifizierungsstelle platziert wird, vom Standardwert %APPDATA%\postgresql\root.crt.

Zugehöriger Inhalt

  • 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.
  • Erfahren Sie, wie Sie mithilfe der Option Öffentlicher Zugriff (zulässige IP-Adresse) im Azure-Portal oder über die Azure CLI eine Instanz für einen flexiblen Azure Database for PostgreSQL-Server erstellen.