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

Usługa Azure Database for PostgreSQL — serwer elastyczny wymusza łączenie aplikacji klienckich z usługą Azure Database for PostgreSQL — serwer elastyczny 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 został wykonany z protokołu SSL netscape i regularnie go zastąpił. Terminy SSL lub TLS/SSL są nadal czasami używane zamiennie. Protokół TLS składa się z dwóch warstw: pokaz rekordów TLS i uzgadnianie protokołu TLS. Pokaz rekordów zapewnia bezpieczeństwo skojarzeń. 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, która składa się z następujących kroków:

  1. Klient rozpoczyna się od wysłania komunikatu o nazwie ClientHello , który wyraża gotowość do komunikacji za pośrednictwem protokołu TLS 1.2 z zestawem zestawów szyfrowania, które obsługuje klient.
  2. Serwer odbiera komunikat, odpowiedzi z adresem i zgadza się na komunikację z ServerHelloklientem za pośrednictwem protokołu TLS 1.2 przy użyciu określonego zestawu szyfrowania.
  3. Serwer wysyła również swój udział kluczy. Specyfika tego udziału klucza zmienia się na podstawie wybranego pakietu szyfrowania. Aby klient i serwer uzgodnili klucz kryptograficzny, muszą otrzymać część lub udostępnić.
  4. Serwer wysyła certyfikat (podpisany przez urząd certyfikacji [CA]) i podpis na części i ClientHello ServerHello. Zawiera również udział kluczy. W ten sposób klient wie, że jest on autentyczny.
  5. Gdy klient pomyślnie odbierze dane, a następnie wygeneruje własny udział kluczy, połączy je z udziałem klucza serwera w celu wygenerowania kluczy szyfrowania dla sesji.
  6. Klient wysyła serwer swój udział kluczy, włącza szyfrowanie i wysyła Finished komunikat. Ta wiadomość jest skrótem transkrypcji tego, co wydarzyło się do tej pory. Serwer robi to samo. Miesza ona udziały kluczy, aby uzyskać klucz i wysyła własny Finished komunikat.
  7. Teraz dane aplikacji można wysyłać zaszyfrowane w połączeniu.

Łańcuchy certyfikatów

Łańcuch certyfikatów to uporządkowana lista certyfikatów, które zawierają certyfikat TLS/SSL i certyfikaty urzędu certyfikacji. Umożliwiają one odbiorcy sprawdzenie, czy nadawca i wszystkie urzędy certyfikacji są wiarygodne. Łańcuch lub ścieżka zaczyna się od certyfikatu TLS/SSL. 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. Ten certyfikat 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 TLS/SSL i certyfikatem głównego urzędu certyfikacji w łańcuchu, jest nazywany certyfikatem pośrednim.

Wersje protokołu TLS

Kilka jednostek rządowych na całym świecie utrzymuje wytyczne dotyczące protokołu TLS dotyczące zabezpieczeń sieci. W Stany Zjednoczone 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.

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 do ustanawiania bezpiecznego połączenia TLS. Większość klientów i serwerów TLS obsługuje wiele alternatyw. Muszą negocjować podczas nawiązywania bezpiecznego połączenia, aby wybrać wspólną 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.

W sierpniu 2018 r. program IETF wydał specyfikację PROTOKOŁU TLS 1.3 w dokumencie RFC 8446, a protokół TLS 1.3 jest obecnie najbardziej typową 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. Zdecydowanie zalecamy używanie najnowszych wersji protokołu TLS do szyfrowania połączeń z usługą Azure Database for PostgreSQL — serwer elastyczny.

Chociaż nie zalecamy tego, w razie potrzeby można wyłączyć protokół TLS\SSL dla połączeń z usługą Azure Database for PostgreSQL — serwer elastyczny. Możesz zaktualizować require_secure_transport parametr serwera do OFF. Wersję protokołu TLS można również ustawić, ustawiając ssl_min_protocol_version parametry serwera i ssl_max_protocol_version .

Uwierzytelnianie certyfikatów odbywa się przy użyciu certyfikatów klienta SSL na potrzeby uwierzytelniania. W tym scenariuszu serwer PostgreSQL porównuje atrybut nazwy pospolitej (CN) certyfikatu klienta przedstawionego względem żądanego użytkownika bazy danych.

Obecnie usługa Azure Database for PostgreSQL — serwer elastyczny nie obsługuje:

Uwaga

Firma Microsoft dokonała zmian głównego urzędu certyfikacji dla różnych usług platformy Azure, w tym usługi Azure Database for PostgreSQL — serwer elastyczny. Aby uzyskać więcej informacji, zobacz Zmiany certyfikatów TLS platformy Azure i sekcję Konfigurowanie protokołu SSL na kliencie.

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 t wartość , jeśli połączenie korzysta z protokołu SSL. W przeciwnym razie zwraca wartość f. Możesz również zebrać wszystkie informacje o użyciu protokołu SSL 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 openssl można również użyć polecenia bezpośrednio:

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

To polecenie wyświetla informacje o protokole niskiego poziomu, takie jak wersja protokołu TLS i szyfrowanie. Należy użyć opcji -starttls postgres. W przeciwnym razie to polecenie zgłasza, że żaden protokół SSL nie jest używany. Użycie tego polecenia wymaga co najmniej biblioteki OpenSSL 1.1.1.

Aby wymusić najnowszą, najbezpieczniejszą wersję protokołu TLS na potrzeby ochrony łączności od klienta do usługi Azure Database for PostgreSQL — serwer elastyczny, ustaw wartość ssl_min_protocol_version 1.3. To ustawienie wymaga , aby klienci łączący się z serwerem elastycznym usługi Azure Database for PostgreSQL używali tej wersji protokołu tylko w celu bezpiecznego komunikowania się. Starsi klienci mogą nie być w stanie komunikować się z serwerem, ponieważ nie obsługują tej wersji.

Konfigurowanie protokołu SSL na kliencie

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. Wszystkie opcje protokołu SSL przeniosą obciążenie w postaci szyfrowania i wymiany kluczy, aby kompromis 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. Oto kilka ważnych:

  • 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. Aby uzyskać zgodność z przyszłymi wersjami, preferowana jest wartość true . W tym trybie podczas nawiązywania połączenia SSL sterownik klienta weryfikuje tożsamość serwera, aby zapobiec atakom typu man-in-the-middle. Sprawdza, czy certyfikat serwera jest podpisany przez zaufany urząd i czy host, z którym nawiązujesz połączenie, jest taki sam jak nazwa hosta w certyfikacie.

  • 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ń SSL dla tego hosta/adresu IP i że serwer rozpoznaje certyfikat klienta. Jeśli serwer nie akceptuje połączeń SSL lub certyfikat klienta nie jest rozpoznawany, połączenie nie powiedzie się. W poniższej tabeli wymieniono wartości dla tego ustawienia:

    Tryb SSL Wyjaśnienie
    disable Szyfrowanie nie jest używane.
    allow Szyfrowanie jest używane, jeśli ustawienia serwera wymagają lub wymuszają.
    prefer Szyfrowanie jest używane, jeśli zezwalają na to ustawienia serwera.
    require Używane jest szyfrowanie. Gwarantuje to, że 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. Sprawdź podpis certyfikatu serwera względem certyfikatu przechowywanego na kliencie.
    verify-full Używane jest szyfrowanie. Sprawdź podpis certyfikatu serwera i nazwę hosta względem certyfikatu przechowywanego na kliencie.

    Używany tryb domyślny sslmode różni się między klientami opartymi na libpq (takimi jak psql) i JDBC. Klienci oparty na libpq domyślnie mają wartość prefer. Klienci JDBC 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 , i /defaultdir/root.crt, odpowiednio, gdzie defaultdir znajduje się ${user.home}/.postgresql/ w systemach nix i %appdata%/postgresql/ w systemie /defaultdir/postgresql.pk8Windows./defaultdir/postgresql.crt

Urzędy certyfikacji są instytucjami odpowiedzialnymi za wystawianie certyfikatów. Zaufany urząd certyfikacji to jednostka, która ma prawo sprawdzić, czy ktoś jest tym, kim są. 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.

Ustawienia użycia verify-ca i verify-full sslmode konfiguracji mogą być również nazywane przypinaniem 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.

W przypadku zmiany lub wygaśnięcia certyfikatów serwera PostgreSQL może być okresowo konieczne zaktualizowanie certyfikatów przechowywanych przez klienta. Aby określić, czy przypinasz urzędy certyfikacji, zobacz 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.

W przypadku klientów korzystających z verify-ca ustawień konfiguracji i verify-full sslmode (czyli przypinania certyfikatów) muszą wdrożyć trzy certyfikaty głównego urzędu certyfikacji w magazynach certyfikatów klienta:

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:

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 poprzednich identyfikatorów URI. Możesz użyć narzędzia OpenSSL, aby wykonać następujące konwersje plików:

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

Informacje na temat aktualizowania magazynów certyfikatów aplikacji klienckich przy użyciu nowych certyfikatów głównego urzędu certyfikacji są udokumentowane w temacie Aktualizowanie certyfikatów TLS klienta dla klientów aplikacji.

Ważne

Niektóre biblioteki klienta Postgres, korzystając z sslmode=verify-full tego ustawienia, mogą wystąpić błędy połączeń z certyfikatami głównego urzędu certyfikacji, które są podpisane krzyżowo z certyfikatami pośrednimi. Wynikiem są alternatywne ścieżki zaufania. W takim przypadku zalecamy jawne określenie parametru sslrootcert . 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ą .

Repliki do odczytu ze scenariuszami przypinania certyfikatów

W przypadku migracji głównego urzędu certyfikacji do głównego urzędu certyfikacji microsoft RSA 2017 możliwe jest, aby nowo utworzone repliki znajdowały się na nowszym certyfikacie głównego urzędu certyfikacji niż wcześniej utworzony serwer podstawowy. W przypadku klientów korzystających z verify-ca ustawień konfiguracji i verify-full sslmode (czyli przypinania certyfikatów) konieczne jest przerwanie łączności w celu akceptowania trzech certyfikatów głównego urzędu certyfikacji:

Obecnie usługa Azure Database for PostgreSQL — serwer elastyczny nie obsługuje 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ć psql wiersza polecenia od klienta, aby przetestować łączność z serwerem w scenariuszach przypinania certyfikatów:


$ 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, zobacz dokumentację programu psql.

Testowanie łączności TLS/SSL

Przed podjęciem próby 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. Jeśli nawiązaliśmy połączenie SSL, powinny zostać wyświetlone dane wyjściowe podobne do następującego przykładu:

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ć ssl_is_used() funkcję, aby określić, czy jest używany protokół SSL. Funkcja zwraca t wartość , jeśli połączenie korzysta z 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. Ogólnie rzecz biorąc, ten ciąg danych zawiera kilka 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 TLS/SSL 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 usługa Azure Database for PostgreSQL — serwer elastyczny 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 TLS/SSL

  1. Pierwszym krokiem rozwiązywania problemów ze zgodnością wersji protokołu TLS/SSL jest zidentyfikowanie komunikatów o błędach wyświetlanych przez Ciebie lub użytkowników podczas próby uzyskania dostępu do serwera elastycznego usługi Azure Database for PostgreSQL w ramach szyfrowania TLS od klienta. W zależności od aplikacji i platformy komunikaty o błędach mogą się różnić. W wielu przypadkach wskazują one na podstawowy problem.

  2. Aby mieć pewność zgodności wersji protokołu TLS/SSL, sprawdź konfigurację protokołu TLS/SSL 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 luki między serwerem bazy danych a wersjami protokołu TLS/SSL klienta i zestawami szyfrowania. 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 TLS/SSL na serwerze lub kliencie, w zależności od wymagań dotyczących zabezpieczeń i zgodności. Na przykład może być konieczne wyłączenie protokołów TLS 1.0 i TLS 1.1, które są uznawane 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 G2 firmy Digicert. Niektóre biblioteki klienta Postgres, podczas używania sslmode=verify-full lub sslmode=verify-ca ustawień, mogą wystąpić błędy połączeń z certyfikatami głównego urzędu certyfikacji, które są podpisane krzyżowo z certyfikatami pośrednimi. Wynikiem są alternatywne ścieżki zaufania.

    Aby obejść te problemy, dodaj wszystkie trzy niezbędne certyfikaty do magazynu certyfikatów klienta lub jawnie określ sslrootcert parametr . Możesz też ustawić zmienną PGSSLROOTCERT środowiskową na ścieżkę lokalną, w której znajduje się certyfikat głównego urzędu certyfikacji 2017 urzędu certyfikacji firmy Microsoft RSA z wartością %APPDATA%\postgresql\root.crtdomyślną .

Powiązana zawartość

  • Dowiedz się, jak utworzyć serwer elastyczny 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ć serwer elastyczny 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.