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

Przegląd

Połączenia między aplikacjami klienckimi i serwerem bazy danych są zawsze szyfrowane przy użyciu standardu branżowego Transport Layer Security (TLS), wcześniej znanego jako Secure Sockets Layer (SSL).

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

Domyślnie jest wymuszana bezpieczna łączność między klientem a serwerem. Jeśli chcesz wyłączyć wymuszanie protokołu TLS, zezwalając zarówno na szyfrowaną, jak i niezaszyfrowaną komunikację klienta, możesz zmienić parametr require_secure_transport serwera na OFF. Wersję protokołu TLS można również ustawić, ustawiając ssl_max_protocol_version parametr serwera. Zdecydowanie zalecamy wyłączenie protokołu TLS.

Konfiguracja protokołu TLS klienta

Domyślnie usługa PostgreSQL nie wykonuje żadnej weryfikacji certyfikatu serwera. Z tego powodu istnieje możliwość fałszowania tożsamości serwera (na przykład przez zmodyfikowanie rekordu DNS lub przejęcie adresu IP serwera) bez znajomości klienta. Aby zapobiec takiemu fałszowaniu, należy użyć weryfikacji certyfikatu TLS na kliencie.

Istnieje wiele parametrów połączenia do konfigurowania klienta dla protokołu TLS. Oto kilka ważnych:

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

• sslmode: Jeśli potrzebujesz szyfrowania i chcesz, aby połączenie nie powiodło się, jeśli nie można go zaszyfrować, ustaw wartość sslmode=require. To ustawienie zapewnia, że serwer jest skonfigurowany do akceptowania połączeń TLS dla tego hosta/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; w związku z tym nie stosuje się tego ustawienia.
  allow	Szyfrowanie jest używane, jeśli ustawienia serwera wymagają lub wymuszają. Usługa Azure Database for PostgreSQL wymaga połączeń TLS; dlatego to ustawienie jest równoważne ustawieniu 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. Zalecamy to ustawienie, chyba że prywatne narzędzia rozpoznawania nazw DNS używają innej nazwy do odwołowania się do serwera usługi Azure Database for PostgreSQL.

Używany tryb domyślny sslmode różni się między klientami opartymi na libpq (na przykład 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 mogą zastąpić 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.

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 itp.), którzy nie korzystają z magazynu systemowego, oraz klientów działających na systemach Linux: należy pobrać i połączyć certyfikaty głównego urzędu certyfikacji w plik PEM. Co najmniej obejmuje następujące certyfikaty głównego urzędu certyfikacji:

• Microsoft RSA Root CA 2017 (plik .crt)
• DigiCert Global Root G2 (plik pem)

Zdecydowanie zalecamy uwzględnienie wszystkich certyfikatów głównego urzędu certyfikacji platformy Azure, aby zmniejszyć potrzebę przyszłych aktualizacji połączonego pliku, jeśli istnieją zmiany w głównych urzędach certyfikacji używanych przez usługę Azure Database for 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 jednym pliku przy użyciu dowolnego edytora tekstu 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. Plik certyfikatów o nazwie cacerts znajduje się w katalogu właściwości zabezpieczeń java.home\lib\security, gdzie java.home jest katalogiem środowiska uruchomieniowego ( jre katalog w zestawie SDK lub katalogu najwyższego poziomu środowiska uruchomieniowego Java™ 2). Możesz użyć następujących wskazówek, aby zaktualizować certyfikaty root CA klienta dla scenariuszy przypinania certyfikatów klienta przy użyciu PostgreSQL.

1. Sprawdź cacerts 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 nie są obecne w magazynie kluczy java na kliencie, jak można zaewidencjonować w danych wyjściowych, należy postępować 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 ze wszystkimi wymaganymi certyfikatami 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 głównego urzędu certyfikacyjnego w usłudze Azure App Services

W przypadku usług Azure App Services, nawiązując połączenie z elastycznym serwerem bazy danych Azure Database for PostgreSQL, istnieją dwa możliwe scenariusze dotyczące aktualizowania certyfikatów klienta. Zależy to od tego, jak używasz protokołu SSL z aplikacją wdrożoną w usługę Azure App Services.

• Nowe certyfikaty są dodawane do App Service na poziomie platformowym przed wprowadzeniem zmian w elastycznym wystąpieniu serwera 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żyć.

Aktualizowanie certyfikatów głównego urzędu certyfikacji podczas korzystania z 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), jest ona podobna 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 .NET (Npgsql) w systemie Windows, łącząc się z wystąpieniami serwera elastycznego Azure Database for PostgreSQL, upewnij się, że wszystkie certyfikaty głównego urzędu certyfikacji znajdują się w magazynie certyfikatów systemu Windows, w zaufanych głównych urzędach certyfikacji. Usługa Windows Update utrzymuje standardową główną listę urzędów certyfikacji platformy Azure. Jeśli jakiekolwiek certyfikaty wymienione w naszej 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 znajdującym się w folderze instalacyjnym Java na kliencie. Poniższy przykład najpierw odczytuje i ładuje cacerts go 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 programu cacerts to changeit , ale powinno być inne na rzeczywistym kliencie, ponieważ administratorzy zaleca zmianę hasła natychmiast po zainstalowaniu języka Java. Po załadowaniu obiektu KeyStore możemy użyć klasy PKIXParameters do odczytywania certyfikatów obecnych.

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

• Weryfikowanie konfiguracji klienta i rozwiązywanie problemów z błędami połączenia
• Dokumentacja bazy danych PostgreSQL.