Udostępnij za pośrednictwem

Zabezpieczanie łączności przy użyciu protokołów TLS i SSL w usłudze Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

Serwer elastyczny usługi Azure Database for PostgreSQL wymusza łączenie aplikacji klienckich z serwerem elastycznym usługi Azure Database for PostgreSQL przy użyciu protokołu Transport Layer Security (TLS). TLS to standardowy protokół branżowy, który zapewnia szyfrowane połączenia sieciowe między serwerem bazy danych a aplikacjami klienckimi. PROTOKÓŁ TLS to zaktualizowany protokół Secure Sockets Layer (SSL).

Co to jest protokół TLS?

Protokół TLS wykonany z netscape Communications Corp. Protokół Secure Sockets Layer pokazuje i regularnie go zastępował, jednak terminy SSL lub SSL/TLS są nadal czasami używane zamiennie. Protokół TLS jest wykonany z dwóch warstw: pokaz rekordów TLS i uzgadnianie protokołu TLS. Pokaz rekordów zapewnia bezpieczeństwo skojarzenia, podczas gdy pokaz uzgadniania umożliwia serwerowi i klientowi potwierdzenie siebie nawzajem oraz koordynowanie ocen szyfrowania i kluczy kryptograficznych przed wymianą jakichkolwiek informacji.

Diagram przedstawiający typową sekwencję uzgadniania protokołu TLS 1.2.

Na powyższym diagramie przedstawiono typową sekwencję uzgadniania protokołu TLS 1.2 składającą się z następujących elementów:

  1. Klient rozpoczyna się od wysłania komunikatu o nazwie ClientHello, który zasadniczo wyraża gotowość do komunikacji za pośrednictwem protokołu TLS 1.2 z zestawem pakietów szyfrowania obsługuje klienta
  2. Serwer otrzymuje te odpowiedzi z serwerem ServerHello, który zgadza się na komunikację z klientem za pośrednictwem protokołu TLS 1.2 przy użyciu określonego zestawu szyfrowania
  3. Wraz z tym serwer wysyła swój udział kluczy. Specyfika tego udziału kluczy zmienia się na podstawie wybranego zestawu szyfrowania. Należy pamiętać, że aby klient i serwer uzgodnili klucz kryptograficzny, muszą otrzymać część lub udział nawzajem.
  4. Serwer wysyła certyfikat (podpisany przez urząd certyfikacji) i podpis w części ClientHello i ServerHello, w tym udział kluczy, aby klient wiedział, że są one autentyczne.
  5. Gdy klient pomyślnie odbierze wymienione powyżej dane, a następnie wygeneruje własny udział kluczy, połączy go z udziałem klucza serwera, a tym samym wygeneruje klucze szyfrowania dla sesji.
  6. W ramach ostatnich kroków klient wysyła serwerowi swój udział kluczy, włącza szyfrowanie i wysyła gotowy komunikat (który jest skrótem transkrypcji tego, co wydarzyło się do tej pory). Serwer wykonuje to samo: miesza udziały kluczy w celu pobrania klucza i wysyła własny komunikat Zakończono.
  7. W tym czasie dane aplikacji mogą być wysyłane zaszyfrowane na połączeniu.

Łańcuchy certyfikatów

Łańcuch certyfikatów to uporządkowana lista certyfikatów, zawierająca certyfikaty SSL/TLS i certyfikaty urzędu certyfikacji, które umożliwiają odbiorcy sprawdzenie, czy nadawca i wszystkie urzędy certyfikacji są wiarygodne. Łańcuch lub ścieżka rozpoczyna się od certyfikatu SSL/TLS, a każdy certyfikat w łańcuchu jest podpisany przez jednostkę zidentyfikowaną przez następny certyfikat w łańcuchu. Łańcuch kończy się certyfikatem głównego urzędu certyfikacji. Certyfikat głównego urzędu certyfikacji jest zawsze podpisany przez sam urząd certyfikacji. Podpisy wszystkich certyfikatów w łańcuchu muszą zostać zweryfikowane do certyfikatu głównego urzędu certyfikacji. Każdy certyfikat, który znajduje się między certyfikatem SSL/TLS i certyfikatem głównego urzędu certyfikacji w łańcuchu, jest nazywany certyfikatem pośrednim.

Wersje protokołu TLS

Istnieje kilka jednostek rządowych na całym świecie, które utrzymują wytyczne dotyczące protokołu TLS dotyczące zabezpieczeń sieci, w tym Departamentu Zdrowia i Usług Ludzkich (HHS) lub Narodowego Instytutu Standardów i Technologii (NIST) w Stany Zjednoczone. Poziom zabezpieczeń zapewniany przez protokół TLS jest najbardziej dotknięty wersją protokołu TLS i obsługiwanymi zestawami szyfrowania. Zestaw szyfrowania to zestaw algorytmów, w tym szyfr, algorytm wymiany kluczy i algorytm wyznaczania wartości skrótu, który jest używany razem do ustanowienia bezpiecznego połączenia TLS. Większość klientów i serwerów TLS obsługuje wiele alternatyw, więc muszą negocjować podczas ustanawiania bezpiecznego połączenia, aby wybrać typową wersję protokołu TLS i pakiet szyfrowania.

Usługa Azure Database for PostgreSQL obsługuje protokół TLS w wersji 1.2 lub nowszej. 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 wersji protokołu TLS, takich jak TLS 1.0 i TLS 1.1, są domyślnie odrzucane.

Internet Engineering Task Force (IETF) wydała specyfikację PROTOKOŁU TLS 1.3 w dokumencie RFC 8446 w sierpniu 2018 r. i jest obecnie najbardziej popularną i zalecaną wersją protokołu TLS. Protokół TLS 1.3 jest szybszy i bezpieczniejszy niż TLS 1.2.

Uwaga

Certyfikaty SSL i TLS certyfikowają, że połączenie jest zabezpieczone za pomocą najnowocześniejszych protokołów szyfrowania. Szyfrując połączenie w sieci, zapobiegasz nieautoryzowanemu dostępowi do danych podczas przesyłania. Dlatego zdecydowanie zalecamy używanie najnowszych wersji protokołu TLS do szyfrowania połączeń z serwerem elastycznym usługi Azure Database for PostgreSQL.
Mimo że nie jest to zalecane, w razie potrzeby istnieje możliwość wyłączenia protokołu TLS\SSL dla połączeń z serwerem elastycznym usługi Azure Database for PostgreSQL przez zaktualizowanie parametru serwera require_secure_transport do pozycji WYŁĄCZONE. Wersję protokołu TLS można również ustawić, ustawiając parametry serwera ssl_min_protocol_version i ssl_max_protocol_version .

Uwierzytelnianie certyfikatu jest wykonywane przy użyciu certyfikatów klienta SSL na potrzeby uwierzytelniania. W tym scenariuszu serwer PostgreSQL porównuje atrybut CN (nazwa pospolita) przedstawionego certyfikatu klienta względem żądanego użytkownika bazy danych. Serwer elastyczny usługi Azure Database for PostgreSQL nie obsługuje obecnie uwierzytelniania opartego na certyfikatach SSL.

Uwaga

Azure Database for PostgreSQL — serwer elastyczny nie obsługuje obecnie niestandardowych certyfikatów SSL\TLS.

Uwaga

Firma Microsoft przechodzi zmiany głównego urzędu certyfikacji dla różnych usług platformy Azure, w tym usługi Azure Database for PostgreSQL — serwer elastyczny, zgodnie z opisem w tym dokumencie i Konfigurowanie protokołu SSL w sekcji Klient poniżej.

Aby określić bieżący stan połączenia TLS\SSL, możesz załadować rozszerzenie sslinfo, a następnie wywołać ssl_is_used() funkcję w celu określenia, czy jest używany protokół SSL. Funkcja zwraca wartość t, jeśli połączenie używa protokołu SSL, w przeciwnym razie zwraca wartość f. Możesz również zebrać wszystkie informacje o użyciu protokołu SSL wystąpienia serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu procesu, klienta i aplikacji, korzystając z następującego zapytania:

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;

Do testowania można również użyć polecenia openssl bezpośrednio, na przykład:

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

To polecenie wyświetla wiele informacji o protokole niskiego poziomu, w tym wersję protokołu TLS, szyfrowanie itd. Należy użyć opcji -starttls postgres lub w przeciwnym razie to polecenie zgłasza, że nie jest używany protokół SSL. Użycie tego polecenia wymaga co najmniej biblioteki OpenSSL 1.1.1.

Uwaga

Aby wymusić najnowszą, najbezpieczniejszą wersję protokołu TLS na potrzeby ochrony łączności od klienta do serwera elastycznego usługi Azure Database for PostgreSQL ssl_min_protocol_version do wersji 1.3. Wymagałoby to, aby klienci łączący się z wystąpieniem serwera elastycznego usługi Azure Database for PostgreSQL używali tej wersji protokołu tylko w celu bezpiecznego komunikowania się. Jednak starsi klienci, ponieważ nie obsługują tej wersji, mogą nie być w stanie komunikować się z serwerem.

Konfigurowanie protokołu SSL na kliencie

Domyślnie usługa PostgreSQL nie wykonuje żadnej weryfikacji certyfikatu serwera. Oznacza to, że 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. Wszystkie opcje protokołu SSL przeniosą obciążenie w postaci szyfrowania i wymiany kluczy, więc istnieje kompromis, który musi zostać wykonany między wydajnością a zabezpieczeniami. Aby zapobiec fałszowaniu, należy użyć weryfikacji certyfikatu SSL na kliencie. Istnieje wiele parametrów połączenia do konfigurowania klienta dla protokołu SSL. Niewiele ważnych dla nas jest:

  1. ssl. Nawiązywanie połączenia przy użyciu protokołu SSL. Ta właściwość nie wymaga skojarzonej z nią wartości. Sama obecność określa połączenie SSL. Jednak w przypadku zgodności z przyszłymi wersjami preferowana jest wartość "true". W tym trybie podczas nawiązywania połączenia SSL sterownik klienta weryfikuje tożsamość serwera, zapobiegając atakom typu "człowiek w środku". W tym celu należy sprawdzić, czy certyfikat serwera jest podpisany przez zaufany urząd i że host, z którym nawiązujesz połączenie, jest taki sam jak nazwa hosta w certyfikacie.
  2. 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. Gwarantuje to, że serwer jest skonfigurowany do akceptowania połączeń SSL dla tego hosta/adresu IP i że serwer rozpoznaje certyfikat klienta. Innymi słowy, jeśli serwer nie akceptuje połączeń SSL lub certyfikat klienta nie zostanie rozpoznany, połączenie zakończy się niepowodzeniem. Poniższa tabela zawiera wartości listy dla tego ustawienia:
Tryb SSL Wyjaśnienie
Wyłącz Szyfrowanie nie jest używane
pozwolić Szyfrowanie jest używane, jeśli ustawienia serwera f wymagają\wymuszenia
woleć Szyfrowanie jest używane, jeśli zezwalają na to ustawienia serwera
wymagać Używane jest szyfrowanie. Dzięki temu serwer jest skonfigurowany do akceptowania połączeń SSL dla tego adresu IP hosta i że serwer rozpoznaje certyfikat klienta.
verify-ca Używane jest szyfrowanie. Ponadto zweryfikuj podpis certyfikatu serwera względem certyfikatu przechowywanego na kliencie
verify-full Używane jest szyfrowanie. Ponadto zweryfikuj podpis certyfikatu serwera i nazwę hosta względem certyfikatu przechowywanego na kliencie

Domyślny używany tryb sslmode różni się między klientami opartymi na libpq (takimi jak psql) i JDBC. Klienci oparty na libpq są domyślnie preferowani, a klienci JDBC są domyślnie weryfikowani.

  1. sslcert, sslkey i sslrootcert. Te parametry mogą zastąpić domyślną lokalizację certyfikatu klienta, klucz klienta PKCS-8 i certyfikat główny. Te wartości domyślne to /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 i /defaultdir/root.crt odpowiednio, gdzie defaultdir to ${user.home}/.postgresql/ w systemach *nix i %appdata%/postgresql/ w systemie Windows.

Urzędy certyfikacji są instytucjami odpowiedzialnymi za wystawianie certyfikatów. Zaufany urząd certyfikacji to jednostka, która ma prawo zweryfikować, kim są osoby, które mówią. Aby ten model działał, wszyscy uczestnicy muszą uzgodnić zestaw zaufanych urzędów certyfikacji. Wszystkie systemy operacyjne i większość przeglądarek internetowych są dostarczane z zestawem zaufanych urzędów certyfikacji.

Uwaga

Przy użyciu funkcji verify-ca i verify-full sslmode configuration settings (Weryfikowanie i weryfikowanie pełnych ustawień konfiguracji protokołu sslmode ) można również znać jako przypinanie certyfikatu. W takim przypadku certyfikaty głównego urzędu certyfikacji na serwerze PostgreSQL muszą być zgodne z podpisem certyfikatu, a nawet nazwą hosta względem certyfikatu na kliencie. Ważne, aby pamiętać, może być okresowo konieczne zaktualizowanie przechowywanych certyfikatów klienta, gdy urzędy certyfikacji zmieniają lub wygasają na certyfikatach serwera PostgreSQL. Aby określić, czy przypinasz urzędy certyfikacji, zapoznaj się z tematem Przypinanie certyfikatów i usługi platformy Azure.

Aby uzyskać więcej informacji na temat konfiguracji protokołu SSL\TLS na kliencie, zobacz dokumentację bazy danych PostgreSQL.

Uwaga

W przypadku klientów korzystających z ustawień konfiguracji verify-ca i verify-full sslmode, tj. przypinania certyfikatów, muszą wdrożyć trzy certyfikaty głównego urzędu certyfikacji w magazynach certyfikatów klienta: DigiCert Global Root G2 i Microsoft RSA Główny urząd certyfikacji 2017, ponieważ usługi są migrowane z digicert do urzędu certyfikacji firmy Microsoft. W przypadku starszej zgodności globalny urząd certyfikacji firmy Digicert.

Pobieranie certyfikatów głównego urzędu certyfikacji i aktualizowanie klientów aplikacji w scenariuszach przypinania certyfikatów

Aby zaktualizować aplikacje klienckie w scenariuszach przypinania certyfikatów, możesz pobrać certyfikaty z następujących identyfikatorów URI:

Aby zaimportować certyfikaty do magazynów certyfikatów klienta, może być konieczne przekonwertowanie plików crt certyfikatu na format pem, po pobraniu plików certyfikatów z powyższych identyfikatorów URI. Możesz użyć narzędzia OpenSSL, aby wykonać te konwersje plików, jak pokazano w poniższym przykładzie:

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

Szczegółowe informacje na temat aktualizowania magazynów certyfikatów aplikacji klienckich przy użyciu nowych certyfikatów głównego urzędu certyfikacji zostały udokumentowane w tym dokumencie z instrukcjami.

Ważne

Niektóre biblioteki klienta Postgres, korzystając z ustawienia sslmode=verify-full , mogą wystąpić błędy połączeń z certyfikatami głównego urzędu certyfikacji, które są podpisane krzyżowo z certyfikatami pośrednimi, co powoduje alternatywne ścieżki zaufania. W takim przypadku zaleca się jawne określenie parametru sslrootcert, wyjaśnione powyżej lub ustawienie zmiennej środowiskowej PGSSLROOTCERT na ścieżkę lokalną, w której znajduje się główny urząd certyfikacji 2017 firmy Microsoft, z domyślnej wartości %APPDATA%\postgresql\root.crt.

Repliki do odczytu ze scenariuszami przypinania certyfikatów

W przypadku migracji głównego urzędu certyfikacji do głównego urzędu certyfikacji Firmy Microsoft RSA 2017 jest możliwe, aby nowo utworzone repliki znajdowały się w nowszym certyfikacie głównego urzędu certyfikacji niż utworzony wcześniej serwer podstawowy. W związku z tym w przypadku klientów korzystających z ustawień konfiguracji verify-ca i verify-full sslmode, oznacza to, że przypinanie certyfikatu jest konieczne, aby przerwać łączność w celu akceptowania trzech certyfikatów głównego urzędu certyfikacji:

Uwaga

Azure Database for PostgreSQL — serwer elastyczny nie obsługuje obecnie uwierzytelniania opartego na certyfikatach .

Testowanie certyfikatów klienta przez nawiązanie połączenia za pomocą narzędzia psql w scenariuszach przypinania certyfikatów

Możesz użyć wiersza polecenia psql od klienta, aby przetestować łączność z serwerem w scenariuszach przypinania certyfikatów, jak pokazano w poniższym przykładzie:


$ 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"

Aby uzyskać więcej informacji na temat parametrów protokołu SSL i certyfikatu, możesz skorzystać z dokumentacji narzędzia psql.

Testowanie łączności SSL/TLS

Przed próbą uzyskania dostępu do serwera z obsługą protokołu SSL z poziomu aplikacji klienckiej upewnij się, że możesz uzyskać do niego dostęp za pośrednictwem narzędzia psql. Powinny zostać wyświetlone dane wyjściowe podobne do poniższych, jeśli nawiązaliśmy połączenie SSL.

psql (14.5)Połączenie SSL (protokół: TLSv1.2, szyfr: ECDHE-RSA-AES256-GCM-SHA384, bity: 256, kompresja: off)Wpisz "pomoc", aby uzyskać pomoc.

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

Zestawy szyfrowania

Zestaw szyfrowania to pakiet algorytmów kryptograficznych. Protokoły TLS/SSL używają algorytmów z zestawu szyfrowania do tworzenia kluczy i szyfrowania informacji. Zestaw szyfrowania jest wyświetlany jako długi ciąg pozornie losowych informacji — ale każdy segment tego ciągu zawiera podstawowe informacje. Zazwyczaj ten ciąg danych składa się z kilku kluczowych składników:

  • Protokół (tj. TLS 1.2 lub TLS 1.3)
  • Algorytm wymiany kluczy lub umowy
  • Algorytm podpisu cyfrowego (uwierzytelniania)
  • Algorytm szyfrowania zbiorczego
  • Algorytm kodu uwierzytelniania komunikatów (MAC)

Różne wersje protokołu SSL/TLS obsługują różne zestawy szyfrowania. Nie można negocjować zestawów szyfrowania TLS 1.2 z połączeniami TLS 1.3 i odwrotnie. Obecnie serwer elastyczny usługi Azure Database for PostgreSQL obsługuje wiele zestawów szyfrowania z protokołem TLS 1.2, które należą do kategorii HIGH:!aNULL .

Rozwiązywanie problemów z błędami łączności SSL\TLS

  1. Pierwszym krokiem rozwiązywania problemów ze zgodnością wersji protokołu SSL/TLS jest zidentyfikowanie komunikatów o błędach wyświetlanych podczas próby uzyskania dostępu do usługi Azure Database for PostgreSQL — serwer elastyczny w ramach szyfrowania TLS od klienta. W zależności od aplikacji i platformy komunikaty o błędach mogą się różnić, ale w wielu przypadkach wskazują na podstawowy problem.
  2. Aby zapewnić zgodność wersji protokołu SSL/TLS, należy sprawdzić konfigurację protokołu SSL/TLS serwera bazy danych i klienta aplikacji, aby upewnić się, że obsługują one zgodne wersje i zestawy szyfrowania.
  3. Przeanalizuj wszelkie rozbieżności lub przerwy między serwerem bazy danych a wersjami protokołu SSL/TLS klienta i zestawami szyfrowania, a następnie spróbuj je rozwiązać, włączając lub wyłączając niektóre opcje, uaktualnianie lub obniżanie poziomu oprogramowania albo zmienianie certyfikatów lub kluczy. Na przykład może być konieczne włączenie lub wyłączenie określonych wersji protokołu SSL/TLS na serwerze lub kliencie w zależności od wymagań dotyczących zabezpieczeń i zgodności , takich jak wyłączenie protokołów TLS 1.0 i TLS 1.1, które są uważane za niezabezpieczone i przestarzałe, oraz włączenie protokołów TLS 1.2 i TLS 1.3, które są bezpieczniejsze i nowoczesne.
  4. Najnowszy certyfikat wystawiony przez główny urząd certyfikacji RSA firmy Microsoft 2017 ma pośrednictwa w łańcuchu podpisanym krzyżowo przez globalny główny urząd certyfikacji firmy Digicert G2. Niektóre biblioteki klienta Postgres, podczas korzystania z protokołu sslmode=verify-full lub sslmode=verify-ca settings, mogą wystąpić błędy połączeń z certyfikatami głównego urzędu certyfikacji, które są podpisane krzyżowo z certyfikatami pośrednimi, co powoduje alternatywne ścieżki zaufania. Aby obejść te problemy, dodaj wszystkie trzy niezbędne certyfikaty do magazynu certyfikatów klienta lub jawnie określ parametr sslrootcert , wyjaśnione powyżej lub ustaw zmienną środowiskową PGSSLROOTCERT na ścieżkę lokalną, w której znajduje się główny urząd certyfikacji Microsoft RSA 2017 główny urząd certyfikacji, z wartości domyślnej %APPDATA%\postgresql\root.crt.

Powiązana zawartość

  • Dowiedz się, jak utworzyć wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu opcji Dostęp prywatny (integracja z siecią wirtualną) w witrynie Azure Portal lub w interfejsie wiersza polecenia platformy Azure.
  • Dowiedz się, jak utworzyć wystąpienie serwera elastycznego usługi Azure Database for PostgreSQL przy użyciu opcji Dostęp publiczny (dozwolone adresy IP) w witrynie Azure Portal lub w interfejsie wiersza polecenia platformy Azure.