Transport Layer Security (TLS) w usłudze Azure Database for PostgreSQL

Wprowadzenie

Usługa Azure Database for PostgreSQL wymaga, aby wszystkie połączenia klienckie używały protokołu Transport Layer Security (TLS), standardowego protokołu, który szyfruje komunikację między serwerem bazy danych a aplikacjami klienckimi. Protokół TLS zastępuje starszy protokół SSL, a tylko protokoły TLS w wersji 1.2 i 1.3 są uznawane za bezpieczne. Integralność zabezpieczeń protokołu TLS opiera się na trzech filarach:

• Używanie tylko protokołu TLS w wersji 1.2 lub 1.3.
• Klient weryfikuje certyfikat TLS serwera wystawiony przez urząd certyfikacji w łańcuchu, który zaczyna się od zaufanego głównego urzędu certyfikacji.
• Negocjowanie bezpiecznego zestawu szyfrowania między serwerem a klientem.

Zaufane certyfikaty główne i rotacje certyfikatów

Główne urzędy certyfikacji używane przez usługę Azure Database for PostgreSQL

Główne urzędy certyfikacji to urzędy najwyższego poziomu w łańcuchu certyfikatów. Usługa Azure Database for PostgreSQL obecnie używa certyfikatów z podwójnym podpisem wystawionych przez certyfikaty ICA zakotwiczone przez następujące główne urzędy certyfikacji:

• Globalny katalog główny G2 firmy DigiCert
• Główny urząd certyfikacji RSA firmy Microsoft 2017

Regiony w Chinach używają obecnie następujących urzędów certyfikacji:

• Główny urząd certyfikacji RSA firmy Microsoft 2017
• Globalny urząd certyfikacji firmy DigiCert
• Po Festiwalu Wiosny (Chiński Nowy Rok) 2026: Digicert Global Root G2. Zalecamy przygotowanie się do tej zmiany z wyprzedzeniem przez dodanie nowego głównego urzędu certyfikacji do zaufanego magazynu głównego.

Informacje o pośrednich urzędach certyfikacji

Usługa Azure Database for PostgreSQL używa pośrednich urzędów certyfikacji (ICA) do wystawiania certyfikatów serwera. Firma Microsoft okresowo wymienia te certyfikaty ICA oraz certyfikaty serwerowe, które wystawiają, w celu zachowania bezpieczeństwa. Rotacje te są rutynowe i nie ogłaszane z wyprzedzeniem.

Bieżąca rotacja pośrednich urzędów certyfikacji dla DigiCert Global Root CA (zobacz Rotacja certyfikatów) rozpoczęła się w listopadzie 2025 r. i zaplanowano jej ukończenie w pierwszym kwartale 2026 r., bieżąca rotacja zastępuje pośrednie urzędy certyfikacji w następujący sposób. Jeśli wykonano zalecane rozwiązania, ta zmiana nie wymaga żadnych zmian w środowisku.

Stary łańcuch urzędu certyfikacji

Te informacje są udostępniane tylko do celów referencyjnych. Nie używaj pośrednich urzędów certyfikacji ani certyfikatów serwera w zaufanym magazynie głównym.

• DigiCert Global Root G2
  • Microsoft Azure RSA TLS Issuing CA 03 / 04 / 07 / 08
    • Certyfikat serwera

Nowy łańcuch CA

Te informacje są udostępniane tylko do celów referencyjnych. Nie używaj pośrednich urzędów certyfikacji ani certyfikatów serwera w zaufanym magazynie głównym.

• DigiCert Global Root G2
  • Microsoft TLS RSA Root G2
    • Microsoft TLS G2 RSA CA OCSP 02 / 04 / 06 / 08 / 10 / 12 / 14 / 16
      • Certyfikat serwera

Repliki do odczytu

Migracja głównego urzędu certyfikacji z globalnego urzędu certyfikacji DigiCert do globalnego głównego urzędu certyfikacji DigiCert G2 nie jest ukończona we wszystkich regionach. W związku z tym nowo utworzone repliki do odczytu mogą używać nowszego certyfikatu głównego urzędu certyfikacji (CA) niż serwer podstawowy. W związku z tym należy dodać DigiCert Global Root CA do zaufanego magazynu read replica.

Łańcuchy certyfikatów

Łańcuch certyfikatów jest hierarchiczną sekwencją certyfikatów wystawionych przez zaufane urzędy certyfikacji ( CA), począwszy od głównego urzędu certyfikacji, który wystawia certyfikaty pośredniego urzędu certyfikacji (ICA). ICA może wystawiać certyfikaty dla niższych ICA. Najniższy ICA w łańcuchu wystawia poszczególne certyfikaty serwera. Łańcuch zaufania jest ustanawiany przez zweryfikowanie każdego certyfikatu w łańcuchu do certyfikatu głównego urzędu certyfikacji.

Zmniejszenie liczby niepowodzeń połączeń

Użycie zalecanych konfiguracji protokołu TLS pomaga zmniejszyć ryzyko awarii połączenia z powodu rotacji certyfikatów lub zmian w pośrednich urzędach certyfikacji. W szczególności należy unikać ufania pośrednim urzędom certyfikacji lub poszczególnym certyfikatom serwera, ponieważ te rozwiązania mogą prowadzić do nieoczekiwanych problemów z połączeniem, gdy firma Microsoft aktualizuje łańcuch certyfikatów.

Zalecane konfiguracje protokołu TLS

Najlepsza konfiguracja

• Wymuś najnowszą, najbezpieczniejszą wersję protokołu TLS, ustawiając parametr serwera ssl_min_protocol_version na TLSv1.3.
• Użyj polecenia sslmode=verify-all dla połączeń PostgreSQL, aby zapewnić pełną weryfikację certyfikatu i nazwy hosta. W zależności od konfiguracji DNS z prywatnymi punktami końcowymi lub integracją z siecią wirtualną, użycie verify-all może nie być możliwe; w takim przypadku można zamiast tego użyć verify-ca.
• Zawsze zachowaj pełny zestaw certyfikatów głównych Azure w zaufanym repozytorium głównym.

Dobra konfiguracja

• Ustaw parametr serwera ssl_min_protocol_version na wartość TLSv1.3. Jeśli musisz obsługiwać protokół TLS 1.2, nie ustawiaj minimalnej wersji.
• Użyj sslmode=verify-all lub sslmode=verify-ca dla połączeń PostgreSQL, aby zapewnić pełną lub częściową weryfikację certyfikatu.
• Upewnij się, że zaufany magazyn główny zawiera certyfikat głównego urzędu certyfikacji używany obecnie przez usługę Azure Database for PostgreSQL:
  • Globalny katalog główny G2 firmy DigiCert
  • Główny urząd certyfikacji RSA firmy Microsoft 2017

Obsługiwane, niezalecane

Zdecydowanie odradzamy wykonywanie następujących konfiguracji:

• Wyłącz protokół TLS całkowicie, ustawiając require_secure_transport na OFF i ustawiając po stronie klienta sslmode=disable.
• Zapobiegaj atakom typu man-in-the-middle, unikając ustawień sslmode po stronie klienta disable, allow, prefer lub require.

Nieobsługiwane konfiguracje; nie używaj

Usługa Azure PostgreSQL nie ogłasza zmian dotyczących zmian pośredniego urzędu certyfikacji ani rotacji poszczególnych certyfikatów serwera; w związku z tym następujące konfiguracje nie są obsługiwane w przypadku używania sslmode ustawień verify-ca lub verify-all:

• Używasz certyfikatów pośrednich urzędu certyfikacji w swoim zaufanym magazynie.
• Używasz przypinania certyfikatów, na przykład poprzez użycie poszczególnych certyfikatów serwera w zaufanym magazynie.

Problemy z przypinaniem certyfikatu

Nigdy nie używaj przypinania certyfikatów w aplikacjach, ponieważ przerywa rotację certyfikatów, taką jak bieżąca zmiana certyfikatu pośredniego urzędów certyfikacji. Jeśli nie wiesz, jakie jest przypinanie certyfikatu, jest mało prawdopodobne, że używasz go. Aby sprawdzić przypinanie certyfikatów:

• Sporządź listę certyfikatów znajdujących się w zaufanym magazynie głównym.
  • Łącz i aktualizuj certyfikaty CA root dla aplikacji Java.
  • Otwórz zaufany magazyn główny na komputerze klienckim, aby wyeksportować listę certyfikatów.
• Stosujesz przypinanie certyfikatów, jeśli masz pośrednie certyfikaty urzędów certyfikacji lub poszczególne certyfikaty serwera PostgreSQL w zaufanym magazynie głównym.
• Aby usunąć przypinanie certyfikatu, usuń wszystkie certyfikaty z zaufanego magazynu głównego i dodaj zalecane certyfikaty głównego urzędu certyfikacji.

Jeśli występują problemy z certyfikatem pośrednim nawet po wykonaniu tych kroków, skontaktuj się z pomocą techniczną firmy Microsoft. Uwzględnij w tytule ICA Rotation 2026.

Inne zagadnienia dotyczące protokołu TLS

Niezabezpieczone i bezpieczne wersje protokołu TLS

Kilka jednostek rządowych na całym świecie utrzymuje wytyczne dotyczące protokołu TLS dotyczące zabezpieczeń sieci. W Stanach Zjednoczonych organizacje te obejmują Departament Zdrowia i Usług Ludzkich oraz Narodowy Instytut Standardów i Technologii. Poziom zabezpieczeń zapewniany przez protokół TLS jest najbardziej dotknięty wersją protokołu TLS i obsługiwanymi zestawami szyfrowania.

Usługa Azure Database for PostgreSQL obsługuje protokół TLS w wersji 1.2 i 1.3. W standardzie RFC 8996 grupa zadań inżynierów internetowych (IETF) jawnie stwierdza, że protokoły TLS 1.0 i TLS 1.1 nie mogą być używane. Oba protokoły zostały wycofane do końca 2019 r. Wszystkie połączenia przychodzące korzystające z wcześniejszych niezabezpieczonych wersji protokołu TLS, takich jak TLS 1.0 i TLS 1.1, są domyślnie odrzucane.

W sierpniu 2018 r. program IETF wydał specyfikację PROTOKOŁU TLS 1.3 w dokumencie RFC 8446, a protokół TLS 1.3 jest zalecaną wersją, ponieważ jest szybszy i bezpieczniejszy niż TLS 1.2.

Chociaż nie zalecamy tego, w razie potrzeby można wyłączyć protokół TLS dla połączeń z usługą Azure Database for PostgreSQL. Możesz zaktualizować require_secure_transport parametr serwera do OFF.

Zestawy szyfrowania

Zestaw szyfrowania to zestaw algorytmów, które obejmują szyfr, algorytm wymiany kluczy i algorytm wyznaczania wartości skrótu. Są one używane razem z certyfikatem TLS i wersją protokołu TLS w celu ustanowienia bezpiecznego połączenia TLS. Większość klientów i serwerów TLS obsługuje wiele zestawów szyfrowania, a czasami wiele wersji protokołu TLS. Podczas nawiązywania połączenia klient i serwer negocjują wersję protokołu TLS i zestaw szyfrowania do użycia za pośrednictwem uzgadniania. Podczas tego handshake'u następuje:

• Klient wysyła listę dopuszczalnych zestawów szyfrowania.
• Serwer wybiera najlepszy (z własnej definicji) zestaw szyfrowania z listy i informuje klienta o wyborze.

Funkcje protokołu TLS nie są dostępne w usłudze Azure Database for PostgreSQL

Obecnie usługa Azure Database for PostgreSQL nie implementuje następujących funkcji protokołu TLS:

• Uwierzytelnianie klienta oparte na certyfikatach TLS za pośrednictwem protokołu TLS z uwierzytelnianiem wzajemnym (mTLS).
• Niestandardowe certyfikaty serwera (użyj własnych certyfikatów TLS).

Treści powiązane

• Konfigurowanie ustawień klienta protokołu TLS w celu nawiązania połączenia z usługą Azure Database for PostgreSQL
• Weryfikowanie konfiguracji klienta i rozwiązywanie problemów z błędami połączenia