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

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

Azure Database for PostgreSQL – Flexibler Server erzwingt das Verbinden Ihrer Clientanwendungen mit Azure Database for PostgreSQL – Flexibler 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 wurde aus dem SSL-Protokoll von Netscape entwickelt und hat es regelmäßig ersetzt. Die Begriffe SSL oder TLS/SSL werden manchmal immer noch austauschbar verwendet. TLS besteht aus zwei Ebenen: dem TLS-Datensatz- und dem TLS-Handshake-Show. Der Datensatz-Show bietet Zuordnungssicherheit. Der Handshake-Show ermöglicht es dem Server und dem Kunden, sich gegenseitig zu bestätigen und Verschlüsselungsbewertungen und Kryptografieschlüssel zu koordinieren, bevor irgendwelche Informationen ausgetauscht werden.

Das vorangehende Diagramm zeigt eine typische TLS 1.2-Handshakesequenz, die aus den folgenden Schritten besteht:

1. Der Client beginnt mit dem Senden einer Nachricht namens ClientHello, die die Bereitschaft zur Kommunikation über TLS 1.2 mit einer Reihe von Verschlüsselungssammlungen ausdrückt, die der Client unterstützt.
2. Der Server empfängt die Nachricht und antwortet mit ServerHello, womit er der Kommunikation mit dem Client über TLS 1.2 mit einer bestimmten Verschlüsselungssammlung zustimmt.
3. Der Server sendet außerdem seine Schlüsselfreigabe. Die Einzelheiten dieser Schlüsselfreigabe hängen davon ab, welche Verschlüsselungssammlung ausgewählt wurde. Damit sich Client und Server auf einen Kryptografieschlüssel einigen können, müssen sie den Teil bzw. die Freigabe des anderen erhalten.
4. Der Server sendet das Zertifikat (signiert von der Zertifizierungsstelle [CA]) und eine Signatur mit den Teilen ClientHello und ServerHello. Außerdem ist die Schlüsselfreigabe enthalten. Auf diese Weise weiß der Client, dass er authentisch ist.
5. Nachdem der Client die Daten empfangen und seinen eigenen Schlüsselanteil generiert hat, wird er mit dem Schlüsselanteil des Servers gemischt, und so werden die Verschlüsselungsschlüssel für die Sitzung erzeugt.
6. Der Client sendet dem Server seine Schlüsselfreigabe, aktiviert die Verschlüsselung und sendet eine Finished-Nachricht. Diese Nachricht ist ein Hash einer Transkription dessen, was bisher passiert ist. Der Server führt dieselben Aktionen aus. Er kombiniert die Schlüsselfreigaben, um den Schlüssel abzurufen, und sendet seine eigene Finished-Nachricht.
7. Jetzt können Anwendungsdaten verschlüsselt über die Verbindung gesendet werden.

Zertifikatketten

Eine Zertifikatkette ist eine sortierte Liste von Zertifikaten, die ein TLS/SSL-Zertifikat und Zertifizierungsstellenzertifikate umfassen. 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.

Azure Database for PostgreSQL – Flexibler Server unterstützt Folgendes derzeit 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-Nutzung Ihrer Instanz von Azure Database for PostgreSQL – Flexibler Server 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:

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.

Legen Sie zum Erzwingen der neuesten, sichersten TLS-Version für den Konnektivitätsschutz vom Client zu Azure Database for PostgreSQL-Server –Flexibler Server ssl_min_protocol_version auf 1.3 fest. Diese Einstellung erfordert, dass Clients, die eine Verbindung mit Ihrer Instanz von Azure Database for PostgreSQL – Flexibler Server herstellen, nur diese Version des Protokolls verwenden, um sicher zu kommunizieren. 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	Erklärung
  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 Nix-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.

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

Azure Database for PostgreSQL – Flexibler Server unterstützt derzeit 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 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 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.

Zurzeit 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 häufiger TLS/SSL-Konnektivitätsfehler

1. Der erste Schritt zur Problembehandlung bei der Kompatibilität der TLS/SSL-Protokollversion besteht darin, die Fehlermeldungen zu identifizieren, die Sie oder Ihre Benutzer sehen, wenn Sie versuchen, mit TLS-Verschlüsselung vom Client auf Azure Database for PostgreSQL – Flexibler Server 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.

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 von Azure Database for PostgreSQL – Flexible Server erstellen.