Udostępnij przez

Łączenie klientów z zabezpieczeniami protokołu TLS z bazą danych

Połączenia między aplikacjami klienckimi a serwerem bazy danych zawsze używają szyfrowania ze standardem branżowym Transport Layer Security (TLS), wcześniej znanym jako Secure Sockets Layer (SSL).

Uwaga / Notatka

Baza danych PostgreSQL typu open source używa starszej nazwy SSL w poleceniach, zmiennych i dokumentacji, aby uniknąć przerywania istniejących implementacji. W tym artykule użyto skrótu TLS podczas używania protokołu SSL w nazwach poleceń i zmiennych.

Usługa Azure Database for PostgreSQL obsługuje połączenia szyfrowane przy użyciu protokołów TLS 1.2 i 1.3. Serwer odrzuca wszystkie połączenia przychodzące, które próbują zaszyfrować ruch przy użyciu protokołów TLS 1.0 i TLS 1.1.

Domyślnie serwer wymusza bezpieczną łączność między klientem a serwerem. Aby wyłączyć to wymuszanie i zezwalać zarówno na szyfrowaną, jak i niezaszyfrowaną komunikację klienta, zmień parametr require_secure_transport serwera na OFF. Wersję protokołu TLS można również ustawić, ustawiając ssl_max_protocol_version parametr serwera. Nie wyłączaj TLS.

Ważne

Firma Microsoft uruchomiła rotację certyfikatów TLS dla usługi Azure Database for PostgreSQL , aby zaktualizować certyfikaty pośredniego urzędu certyfikacji i wynikowy łańcuch certyfikatów. Korzenie CA pozostają takie same.

Jeśli konfiguracja klienta używa zalecanych konfiguracji dla protokołu TLS, nie musisz podejmować żadnych działań.

Harmonogram rotacji certyfikatów

  • Regiony Azure West Central US, East Asia i UK South rozpoczęły rotację certyfikatów TLS 11 listopada 2025 r.
  • Od 19 stycznia 2026 r. ta rotacja certyfikatów ma zostać rozszerzona do pozostałych (z wyjątkiem Chin) regionów, w tym platformy Azure Government.
  • Po Festiwalu Wiosny (Chiński Nowy Rok) 2026 regiony Chin również zostaną poddane rotacji certyfikatów, która obejmuje zmianę jednego z głównych urzędów certyfikacji.

Konfiguracja protokołu TLS klienta

Domyślnie usługa PostgreSQL nie weryfikuje certyfikatu serwera. Z powodu tego domyślnego zachowania klient nie może wykryć, czy tożsamość serwera jest fałszowana (na przykład jeśli ktoś modyfikuje rekord DNS lub przejmuje adres IP serwera). Aby zapobiec fałszowaniu tego rodzaju, włącz weryfikację certyfikatu TLS na kliencie.

Dla konfiguracji protokołu TLS klienta można skonfigurować wiele parametrów połączenia. Oto kilka ważnych:

  • ssl: Nawiązywanie połączenia przy użyciu protokołu TLS. Ta właściwość nie wymaga wartości. Jego obecność określa połączenie TLS. Aby uzyskać zgodność z przyszłymi wersjami, użyj wartości true. W tym trybie po nawiązaniu połączenia TLS sterownik klienta weryfikuje tożsamość serwera, aby zapobiec atakom typu man-in-the-middle.

  • sslmode: ustaw ten parametr na require wartość , jeśli potrzebujesz szyfrowania i chcesz, aby połączenie nie powiodło się, jeśli nie można go zaszyfrować. To ustawienie zapewnia, że serwer jest skonfigurowany do akceptowania połączeń TLS dla tego hosta lub adresu IP i że serwer rozpoznaje certyfikat klienta. Jeśli serwer nie akceptuje połączeń TLS lub certyfikat klienta nie jest rozpoznawany, połączenie nie powiedzie się. W poniższej tabeli wymieniono wartości dla tego ustawienia:

    sslmode Explanation
    disable Szyfrowanie nie jest używane. Usługa Azure Database for PostgreSQL wymaga połączeń TLS, więc nie używaj tego ustawienia.
    allow Szyfrowanie jest używane, jeśli ustawienia serwera wymagają lub wymuszają. Usługa Azure Database for PostgreSQL wymaga połączeń TLS, więc to ustawienie jest równoważne .prefer
    prefer Szyfrowanie jest używane, jeśli zezwalają na to ustawienia serwera. Usługa Azure Database for PostgreSQL wymaga połączeń TLS.
    require Używane jest szyfrowanie. Gwarantuje to, że serwer jest skonfigurowany do akceptowania połączeń TLS.
    verify-ca Używane jest szyfrowanie. Sprawdź certyfikat serwera względem zaufanych certyfikatów głównych przechowywanych na kliencie.
    verify-full Używane jest szyfrowanie. Sprawdź certyfikat serwera względem certyfikatu przechowywanego na kliencie. Sprawdza również, czy certyfikaty serwera używają tej samej nazwy hosta co połączenie. Użyj tego ustawienia, chyba że prywatne narzędzia rozpoznawania nazw DNS używają innej nazwy do odwołowania się do serwera usługi Azure Database for PostgreSQL.

Tryb domyślny sslmode różni się pomiędzy klientami bazującymi na libpq (takimi jak PSQL i JDBC). Klienci oparty na libpq domyślnie mają wartość prefer. JDBC klienci domyślnie mają wartość verify-full.

  • sslcert, sslkeyi sslrootcert: Te parametry zastępują domyślną lokalizację certyfikatu klienta, klucz klienta PKCS-8 i certyfikat główny. Domyślnie są to /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8i /defaultdir/root.crt, odpowiednio, gdzie defaultdir znajduje się ${user.home}/.postgresql/ w systemach Linux i %appdata%/postgresql/ w systemie Windows.

Ważne

Niektóre biblioteki klienta Postgres mogą nie nawiązać połączenia przy używaniu ustawienia sslmode=verify-full z certyfikatami głównego urzędu certyfikacji, które służą do podpisywania krzyżowego certyfikatów pośrednich. Ta konfiguracja powoduje alternatywne ścieżki zaufania. W takim przypadku jawnie określ sslrootcert parametr . Możesz też ustawić PGSSLROOTCERT zmienną środowiskową na ścieżkę lokalną, w której znajduje się certyfikat głównego urzędu certyfikacji 2017 firmy Microsoft RSA z wartością %APPDATA%\postgresql\root.crtdomyślną .

Instalowanie zaufanych głównych urzędów certyfikacji

Pobieranie i konwertowanie certyfikatów głównego urzędu certyfikacji

W przypadku klientów systemu Windows korzystających z magazynu certyfikatów systemowych dla zaufanych certyfikatów głównych nie jest wymagana żadna akcja, ponieważ system Windows wdraża nowe certyfikaty głównego urzędu certyfikacji za pośrednictwem usługi Windows Update.

W przypadku klientów Java, rozszerzenia programu VS Code i innych klientów (na przykład PSQL, Perl), którzy nie korzystają ze sklepu systemowego, oraz dla klientów w systemie Linux: należy pobrać i połączyć certyfikaty głównego urzędu certyfikacji w plik PEM. Uwzględnij co najmniej następujące certyfikaty root CA:

Uwaga / Notatka

W przypadku regionów Chin i klientów z rozszerzeniami dotyczącymi rotacji: DigiCert Global Root CA (plik pem) jest nadal ważny; uwzględnij go w połączonym pliku PEM.

Uwzględnij wszystkie certyfikaty głównych urzędów certyfikacji Azure, aby zmniejszyć potrzebę przyszłych aktualizacji zbiorczego pliku, jeśli nastąpią zmiany w głównych urzędach certyfikacji używanych przez Azure Database dla PostgreSQL. Listę certyfikatów głównego urzędu certyfikacji platformy Azure można znaleźć na stronie Szczegóły urzędu certyfikacji platformy Azure.

Aby zaimportować certyfikaty do magazynów certyfikatów klienta, może być konieczne przekonwertowanie dowolnych certyfikatów formatu CRT na format PEM i połączenie plików PEM w jeden plik. Możesz użyć narzędzia OpenSSL X509 , aby przekonwertować pliki CRT na PEM.

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

Łączenie głównych certyfikatów urzędu certyfikacji w jeden plik PEM

W przypadku niektórych klientów połączysz wszystkie pliki PEM w jeden plik przy użyciu dowolnego edytora tekstów lub narzędzia wiersza polecenia.

-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

W przypadku regionów Chin i klientów, którzy korzystają z rozszerzeń rotacji:

-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Łączenie i aktualizowanie podstawowych certyfikatów urzędu certyfikacji dla aplikacji Java

Niestandardowe aplikacje Java używają domyślnego magazynu kluczy o nazwie cacerts, który zawiera certyfikaty zaufanego urzędu certyfikacji. cacerts Plik certyfikatów znajduje się w katalogu właściwości zabezpieczeń w java.home\lib\security, gdzie java.home jest katalogiem środowiska uruchomieniowego (katalogiem jre w zestawie SDK lub głównym katalogiem środowiska uruchomieniowego Java™ 2). Aby zaktualizować certyfikaty głównego urzędu certyfikacji klienta dla scenariuszy przypinania certyfikatów klienta za pomocą bazy danych PostgreSQL, użyj następujących wskazówek:

  1. cacerts Sprawdź magazyn kluczy Java, aby sprawdzić, czy zawiera już wymagane certyfikaty. Certyfikaty można wyświetlić w magazynie kluczy Java przy użyciu następującego polecenia:

    keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt

    Jeśli wymagane certyfikaty są nieobecne w magazynie kluczy Java na kliencie, co można sprawdzić w wynikach, postępuj zgodnie z następującymi wskazówkami:

  2. Utwórz kopię zapasową niestandardowego magazynu kluczy.

  3. Pobierz pliki certyfikatów i zapisz je lokalnie, gdzie można się do nich odwoływać.

  4. Wygeneruj połączony magazyn certyfikatów urzędu certyfikacji zawierający wszystkie wymagane certyfikaty głównego urzędu certyfikacji. W poniższym przykładzie pokazano użycie elementu DefaultJavaSSLFactory dla użytkowników języka Java postgreSQL.

    keytool -importcert -alias PostgreSQLServerCACert  -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt

keytool -importcert -alias PostgreSQLServerCACert2  -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password  -noprompt

...

Aktualizowanie certyfikatów urzędu certyfikacji nadrzędnego w usłudze Azure App Services

W przypadku usługi Azure App Services łączących się z elastycznym serwerem usługi Azure Database for PostgreSQL istnieją dwa możliwe scenariusze aktualizacji certyfikatów klienta. Scenariusze zależą od tego, jak używasz SSL z aplikacją wdrożoną w usłudze Azure App Services.

  • Dodaj nowe certyfikaty do usługi App Service na poziomie platformy przed wprowadzeniem zmian w wystąpieniu serwera elastycznego usługi Azure Database for PostgreSQL. Jeśli używasz certyfikatów SSL zawartych na platformie App Service w aplikacji, nie jest wymagana żadna akcja. Aby uzyskać więcej informacji, zobacz Dodawanie certyfikatów TLS/SSL i zarządzanie nimi w usłudze Azure App Service w dokumentacji usługi Azure App Service.
  • Jeśli jawnie dołączasz ścieżkę do pliku certyfikatu SSL w kodzie, musisz pobrać nowy certyfikat i zaktualizować go, aby go używać.

Aktualizowanie certyfikatów głównych CA podczas używania klientów w usłudze Azure Kubernetes Service (AKS)

Jeśli próbujesz nawiązać połączenie z usługą Azure Database for PostgreSQL przy użyciu aplikacji hostowanych w usługach Azure Kubernetes Services (AKS), dostęp jest podobny do dostępu ze środowiska hosta dedykowanego klienta. Zobacz szczegółową instrukcję w dokumentacji usługi AKS.

Aktualizowanie certyfikatów głównego urzędu certyfikacji dla użytkowników platformy .NET (Npgsql) w systemie Windows

W przypadku użytkowników platformy .NET (Npgsql) w systemie Windows, którzy łączą się z instancjami Azure Database for PostgreSQL flexible server, upewnij się, że wszystkie certyfikaty głównych urzędów certyfikacji znajdują się w magazynie certyfikatów systemu Windows w obszarze Zaufane główne urzędy certyfikacji. Usługa Windows Update utrzymuje standardową główną listę urzędów certyfikacji platformy Azure. Jeśli jakiekolwiek certyfikaty wymienione w zalecanej konfiguracji nie są uwzględnione, zaimportuj brakujące certyfikaty.

Jak używać protokołu TLS z weryfikacją certyfikatu

Niektóre struktury aplikacji korzystające z bazy danych PostgreSQL domyślnie nie włączają protokołu TLS podczas instalacji. Wystąpienie usługi Azure Database for PostgreSQL wymusza połączenia TLS, ale jeśli aplikacja nie jest skonfigurowana do obsługi protokołu TLS, aplikacja może zakończyć się niepowodzeniem. Zapoznaj się z dokumentacją aplikacji, aby dowiedzieć się, jak włączyć połączenia TLS.

Nawiązywanie połączenia przy użyciu PSQL

W poniższym przykładzie pokazano, jak nawiązać połączenie z serwerem przy użyciu interfejsu PSQL wiersza polecenia. Użyj ustawienia parametrów ciągu połączenia sslmode=verify-full lub sslmode=verify-ca, aby wymusić weryfikację certyfikatu TLS. Przekaż ścieżkę pliku certyfikatu lokalnego do parametru sslrootcert .

 psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"

Testowanie łączności TLS

Przed podjęciem próby uzyskania dostępu do serwera z obsługą protokołu TLS z poziomu aplikacji klienckiej upewnij się, że możesz uzyskać do niego dostęp za pośrednictwem usługi PSQL. Jeśli nawiązaliśmy połączenie TLS, powinny zostać wyświetlone dane wyjściowe podobne do następującego przykładu:

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

Można również załadować rozszerzenie sslinfo, a następnie wywołać funkcję ssl_is_used(), aby określić, czy używany jest protokół TLS. Funkcja zwraca t wartość , jeśli połączenie korzysta z protokołu TLS. W przeciwnym razie zwraca f.

Programowe pobieranie listy zaufanych certyfikatów w magazynie kluczy Java

Domyślnie język Java przechowuje zaufane certyfikaty w specjalnym pliku o nazwie cacerts , który znajduje się w folderze instalacyjnym Java na kliencie. Poniższy przykład odczytuje cacerts i ładuje do obiektu KeyStore.

private KeyStore loadKeyStore() {
    String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
    String filename = System.getProperty("java.home") + relativeCacertsPath;
    FileInputStream is = new FileInputStream(filename);
    KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
    String password = "changeit";
    keystore.load(is, password.toCharArray());

    return keystore;
}

Domyślne hasło dla cacerts to changeit, ale powinno być inne na aktualnym kliencie. Administratorzy zaleca zmianę hasła bezpośrednio po zainstalowaniu języka Java. Po załadowaniu obiektu KeyStore można użyć klasy PKIXParameters do odczytywania certyfikatów znajdujących się.

public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
    KeyStore keyStore = loadKeyStore();
    PKIXParameters params = new PKIXParameters(keyStore);
    Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
    List<Certificate> certificates = trustAnchors.stream()
      .map(TrustAnchor::getTrustedCert)
      .collect(Collectors.toList());

    assertFalse(certificates.isEmpty());
}

Treści powiązane

  • Last updated on