Sdílet prostřednictvím

Zabezpečené připojení pomocí protokolu TLS a SSL na flexibilním serveru Azure Database for PostgreSQL

  • Článek

PLATÍ PRO: Flexibilní server Azure Database for PostgreSQL

Flexibilní server Azure Database for PostgreSQL vynucuje připojení klientských aplikací k flexibilnímu serveru Azure Database for PostgreSQL pomocí protokolu TLS (Transport Layer Security). TLS je standardní protokol, který zajišťuje šifrovaná síťová připojení mezi databázovým serverem a klientskými aplikacemi. TLS je aktualizovaný protokol SSL (Secure Sockets Layer).

Co je TLS?

Protokol TLS byl vyroben z protokolu SSL netscape a pravidelně ho nahradil. Termíny SSL nebo TLS/SSL se někdy používají zaměnitelně. Tls je tvořen dvěma vrstvami: záznam TLS show a tls handshake show. Zobrazení záznamu poskytuje zabezpečení přidružení. Ukázka metody handshake umožňuje serveru a zákazníkovi navzájem potvrdit a koordinovat hodnocení šifrování a kryptografické klíče před obchodem s informacemi.

Diagram znázorňující typickou sekvenci handshake protokolu TLS 1.2

Předchozí diagram znázorňuje typickou posloupnost handshake protokolu TLS 1.2, která se skládá z těchto kroků:

  1. Klient začne odesláním zprávy s názvem ClientHello , která vyjadřuje ochotu komunikovat prostřednictvím protokolu TLS 1.2 se sadou šifrovacích sad, které klient podporuje.
  2. Server obdrží zprávu, odpovědi s klientem ServerHelloa souhlasí s tím, že komunikuje s klientem prostřednictvím protokolu TLS 1.2 pomocí konkrétní sady šifer.
  3. Server také odešle svoji sdílenou složku klíčů. Specifika této sdílené složky klíčů se mění na základě vybrané šifrovací sady. Aby klient a server souhlasili s kryptografickým klíčem, musí si navzájem přijmout část nebo sdílet.
  4. Server odešle certifikát (podepsaný certifikační autoritou [CA]) a podpis na částech ClientHello a ServerHello. Obsahuje také sdílenou složku klíčů. Tímto způsobem klient ví, že je autentický.
  5. Jakmile klient úspěšně přijme data a potom vygeneruje vlastní sdílenou složku klíčů, zkombinuje ji se sdílenou složkou klíčů serveru, aby vygenerovala šifrovací klíče pro relaci.
  6. Klient odešle server, který má sdílenou složku klíčů, povolí šifrování a odešle Finished zprávu. Tato zpráva představuje hodnotu hash přepisu toho, co se zatím stalo. Server dělá totéž. Zkombinuje sdílené složky klíčů, aby získal klíč a odeslal vlastní Finished zprávu.
  7. Data aplikace se teď dají odeslat zašifrovaná v připojení.

Řetězy certifikátů

Řetěz certifikátů je seřazený seznam certifikátů, které obsahují certifikát TLS/SSL a certifikáty certifikační autority. Umožňuje příjemci ověřit, že odesílatel a všechny certifikační autority jsou důvěryhodné. Řetězec nebo cesta začíná certifikátem TLS/SSL. Každý certifikát v řetězu je podepsaný entitou identifikovanou dalším certifikátem v řetězu.

Řetězec se ukončí kořenovým certifikátem certifikační autority. Tento certifikát je vždy podepsaný samotnou certifikační autoritou. Podpisy všech certifikátů v řetězu musí být ověřeny až do kořenového certifikátu certifikační autority.

Jakýkoli certifikát, který se nachází mezi certifikátem TLS/SSL a kořenovým certifikátem certifikační autority v řetězu, se nazývá zprostředkující certifikát.

Verze protokolu TLS

Několik subjektů státní správy po celém světě udržuje pokyny pro protokol TLS týkající se zabezpečení sítě. V USA zahrnují tyto organizace oddělení zdravotnictví a lidských služeb a Národní institut standardů a technologií. Úroveň zabezpečení, kterou protokol TLS poskytuje, je nejvíce ovlivněna verzí protokolu TLS a podporovanými šifrovacími sadami.

Šifrovací sada je sada algoritmů, které zahrnují šifru, algoritmus výměny klíčů a algoritmus hash. Společně se používají k vytvoření zabezpečeného připojení TLS. Většina klientů a serverů TLS podporuje více alternativ. Musí vyjednat, když naváže zabezpečené připojení, aby vybrali společnou verzi protokolu TLS a šifrovací sadu.

Azure Database for PostgreSQL podporuje protokol TLS verze 1.2 a novější. V dokumentu RFC 8996 explicitně uvádí IETF (Internet Engineering Task Force), že protokol TLS 1.0 a TLS 1.1 se nesmí používat. Oba protokoly byly na konci roku 2019 zastaralé.

Všechna příchozí připojení, která používají starší verze protokolu TLS, například TLS 1.0 a TLS 1.1, jsou ve výchozím nastavení odepřena.

IETF vydal specifikaci TLS 1.3 v DOKUMENTU RFC 8446 v srpnu 2018 a protokol TLS 1.3 je nyní nejběžnější a doporučenou verzí protokolu TLS, která se používá. Protokol TLS 1.3 je rychlejší a bezpečnější než protokol TLS 1.2.

Poznámka:

Certifikáty SSL a TLS certifikuje, že vaše připojení je zabezpečené pomocí špičkových šifrovacích protokolů. Šifrováním připojení na drátu zabráníte neoprávněnému přístupu k datům během přenosu. Důrazně doporučujeme používat nejnovější verze protokolu TLS k šifrování připojení k flexibilnímu serveru Azure Database for PostgreSQL.

I když ho nedoporučujeme, v případě potřeby můžete zakázat TLS\SSL pro připojení k flexibilnímu serveru Azure Database for PostgreSQL. Parametr serveru můžete aktualizovat require_secure_transport na OFF. Verzi protokolu TLS můžete nastavit také nastavením ssl_min_protocol_version a ssl_max_protocol_version parametry serveru.

Ověřování certifikátu se provádí pomocí klientských certifikátů SSL pro ověřování. V tomto scénáři server PostgreSQL porovnává atribut běžného názvu (CN) klientského certifikátu předaného požadovanému databázovému uživateli.

Flexibilní server Azure Database for PostgreSQL v tuto chvíli nepodporuje:

Poznámka:

Microsoft provedl změny kořenové certifikační autority pro různé služby Azure, včetně flexibilního serveru Azure Database for PostgreSQL. Další informace najdete v tématu Změny certifikátu Protokolu TLS v Azure a v části Konfigurace PROTOKOLU SSL v klientovi.

Pokud chcete zjistit aktuální stav připojení TLS\SSL, můžete načíst rozšíření sslinfo a potom volat ssl_is_used() funkci, která určí, jestli se ssl používá. Funkce vrátí t , pokud připojení používá protokol SSL. V opačném případě se vrátí f. Pomocí následujícího dotazu můžete také shromažďovat všechny informace o využití SSL flexibilního serveru Azure Database for PostgreSQL pomocí procesu, klienta a aplikace:

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;

K testování můžete také použít openssl příkaz přímo:

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

Tento příkaz vytiskne informace protokolu nízké úrovně, jako je verze protokolu TLS a šifra. Musíte použít možnost -starttls postgres. Jinak tento příkaz hlásí, že se nepoužívá žádný protokol SSL. Použití tohoto příkazu vyžaduje alespoň OpenSSL 1.1.1.

Pokud chcete vynutit nejnovější, nejbezpečnější verzi protokolu TLS pro ochranu připojení z klienta na flexibilní server Azure Database for PostgreSQL, nastavte ssl_min_protocol_version na 1.3hodnotu . Toto nastavení vyžaduje , aby klienti, kteří se připojují k flexibilnímu serveru Azure Database for PostgreSQL, používali tuto verzi protokolu pouze k bezpečné komunikaci. Starší klienti nemusí být schopni komunikovat se serverem, protože tuto verzi nepodporují.

Konfigurace SSL na klientovi

Ve výchozím nastavení PostgreSQL neprovádí žádné ověření certifikátu serveru. Z tohoto důvodu je možné falšování identity serveru (například úpravou záznamu DNS nebo převzetím IP adresy serveru) bez znalosti klienta. Všechny možnosti PROTOKOLU SSL mají režii ve formě šifrování a výměny klíčů, takže kompromis se provádí mezi výkonem a zabezpečením.

Aby se zabránilo falšování identity, musí se použít ověření certifikátu SSL v klientovi.

Pro konfiguraci klienta pro SSL existuje mnoho parametrů připojení. Mezi důležité patří:

  • ssl: Připojení pomocí PROTOKOLU SSL. Tato vlastnost nepotřebuje přidruženou hodnotu. Pouhá přítomnost určuje připojení SSL. Pro zajištění kompatibility s budoucími verzemi je tato hodnota true upřednostňovaná. Když v tomto režimu vytváříte připojení SSL, klientský ovladač ověří identitu serveru, aby se zabránilo útokům typu man-in-the-middle. Zkontroluje, jestli je certifikát serveru podepsaný důvěryhodnou autoritou a že hostitel, ke kterému se připojujete, je stejný jako název hostitele v certifikátu.

  • sslmode: Pokud požadujete šifrování a chcete, aby připojení selhalo, pokud ho nejde zašifrovat, nastavte sslmode=require. Toto nastavení zajistí, že server bude nakonfigurovaný tak, aby přijímal připojení SSL pro tohoto hostitele nebo IP adresu a že server rozpozná klientský certifikát. Pokud server nepřijme připojení SSL nebo se klientský certifikát nerozpozná, připojení selže. Následující tabulka uvádí hodnoty pro toto nastavení:

    Režim SSL Vysvětlení
    disable Šifrování se nepoužívá.
    allow Šifrování se používá, pokud ho nastavení serveru vyžadují nebo vynucuje.
    prefer Šifrování se používá, pokud to nastavení serveru umožňuje.
    require Používá se šifrování. Zajišťuje, že je server nakonfigurovaný tak, aby přijímal připojení SSL pro tuto IP adresu hostitele a aby server rozpoznal klientský certifikát.
    verify-ca Používá se šifrování. Ověřte podpis certifikátu serveru vůči certifikátu uloženému v klientovi.
    verify-full Používá se šifrování. Ověřte podpis certifikátu serveru a název hostitele vůči certifikátu uloženému v klientovi.

    Použitý výchozí sslmode režim se liší mezi klienty založenými na knihovně libpq (například psql) a JDBC. Klienti založené na knihovně libpq mají výchozí hodnotu prefer. Klienti JDBC mají výchozí hodnotu verify-full.

  • sslcert, sslkeya sslrootcert: Tyto parametry mohou přepsat výchozí umístění klientského certifikátu, klíč klienta PKCS-8 a kořenový certifikát. Ve výchozím ${user.home}/.postgresql/ defaultdir nastavení /defaultdir/postgresql.crtse nachází v /defaultdir/root.crt/defaultdir/postgresql.pk8systémech nix a %appdata%/postgresql/ ve Windows.

Certifikační autority jsou instituce zodpovědné za vydávání certifikátů. Důvěryhodná certifikační autorita je entita, která má právo ověřit, že někdo je tím, kdo říká, že je. Aby tento model fungoval, musí všichni účastníci souhlasit se sadou důvěryhodných certifikačních autorit. Všechny operační systémy a většina webových prohlížečů se dodávají se sadou důvěryhodných certifikačních autorit.

Použití verify-ca a verify-full sslmode nastavení konfigurace se také označuje jako připnutí certifikátu. V takovém případě musí certifikáty kořenové certifikační autority na serveru PostgreSQL odpovídat podpisu certifikátu a dokonce i názvu hostitele s certifikátem v klientovi.

Pokud se certifikační autority změní nebo vyprší platnost certifikátů serveru PostgreSQL, může být potřeba pravidelně aktualizovat certifikáty uložené klientem. Pokud chcete zjistit, jestli připnete certifikační autority, přečtěte si téma Připnutí certifikátů a služby Azure.

Další informace o konfiguraci PROTOKOLU SSL\TLS na klientovi najdete v dokumentaci k PostgreSQL.

Pro klienty, kteří používají verify-ca a sslmode verify-full konfigurační nastavení (to znamená připnutí certifikátu), musí do úložišť klientských certifikátů nasadit tři kořenové certifikáty certifikační autority:

Stažení certifikátů kořenové certifikační autority a aktualizace klientů aplikací ve scénářích připnutí certifikátu

Pokud chcete aktualizovat klientské aplikace ve scénářích připnutí certifikátů, můžete stáhnout certifikáty:

Pokud chcete importovat certifikáty do úložišť klientských certifikátů, možná budete muset po stažení souborů certifikátů z předchozích identifikátorů URI převést soubory .crt certifikátu do formátu .pem. Pomocí nástroje OpenSSL můžete provádět tyto převody souborů:

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

Informace o aktualizaci úložišť certifikátů klientských aplikací s novými kořenovými certifikáty certifikační autority jsou popsané v části Aktualizace klientských certifikátů TLS pro klienty aplikací.

Důležité

U některých klientských knihoven Postgres při sslmode=verify-full použití tohoto nastavení může docházet k chybám připojení s kořenovými certifikáty certifikační autority, které jsou křížově podepsané pomocí zprostředkujících certifikátů. Výsledkem jsou alternativní cesty důvěryhodnosti. V tomto případě doporučujeme explicitně zadat sslrootcert parametr. Nebo nastavte PGSSLROOTCERT proměnnou prostředí na místní cestu, kde je umístěn kořenový certifikát kořenové certifikační autority Microsoft RSA 2017 z výchozí hodnoty %APPDATA%\postgresql\root.crt.

Scénáře připnutí certifikátů pro čtení replik

Při migraci kořenové certifikační autority do kořenové certifikační autority Microsoft RSA 2017 je možné, aby nově vytvořené repliky byly na novějším kořenovém certifikátu certifikační autority než primární server, který byl vytvořen dříve. Pro klienty, kteří používají verify-ca a verify-full sslmode konfigurační nastavení (to znamená připnutí certifikátu), je nezbytné přerušit připojení, aby přijímali tři kořenové certifikáty certifikační autority:

V tuto chvíli flexibilní server Azure Database for PostgreSQL nepodporuje ověřování na základě certifikátů.

Testování klientských certifikátů připojením k psql ve scénářích připnutí certifikátů

Pomocí příkazového psql řádku z klienta můžete otestovat připojení k serveru ve scénářích připnutí certifikátu:


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

Další informace o parametrech SSL a certifikátu najdete v dokumentaci k psql.

Testování připojení TLS/SSL

Než se pokusíte získat přístup k serveru s povoleným protokolem SSL z klientské aplikace, ujistěte se, že se k němu můžete dostat přes psql. Pokud jste vytvořili připojení SSL, měl by se zobrazit výstup podobný následujícímu příkladu:

psql (14.5)Připojení SSL (protokol: TLSv1.2, šifra: ECDHE-RSA-AES256-GCM-SHA384, bity: 256, komprese: vypnuto)Zadejte nápovědu "help".

Můžete také načíst rozšíření sslinfo a potom volat ssl_is_used() funkci, abyste zjistili, jestli se používá SSL. Funkce vrátí t , pokud připojení používá protokol SSL. V opačném případě se vrátí f.

Šifrovací sady

Šifrovací sada je sada kryptografických algoritmů. Protokoly TLS/SSL používají algoritmy ze šifrovací sady k vytváření klíčů a šifrování informací.

Šifrovací sada se zobrazuje jako dlouhý řetězec zdánlivě náhodných informací, ale každý segment tohoto řetězce obsahuje základní informace. Obecně platí, že tento datový řetězec obsahuje několik klíčových komponent:

  • Protokol (tj. TLS 1.2 nebo TLS 1.3)
  • Algoritmus výměny klíčů nebo smlouvy
  • Algoritmus digitálního podpisu (ověřování)
  • Algoritmus hromadného šifrování
  • Algoritmus kódu ověřování zpráv (MAC)

Různé verze protokolu TLS/SSL podporují různé šifrovací sady. Šifrovací sady PROTOKOLU TLS 1.2 nelze vyjednat s připojeními TLS 1.3 a naopak.

Flexibilní server Azure Database for PostgreSQL v tuto chvíli podporuje mnoho šifrovacích sad s verzí protokolu TLS 1.2, která spadají do kategorie HIGH:!aNULL .

Řešení chyb připojení TLS/SSL

  1. Prvním krokem při řešení potíží s kompatibilitou verzí protokolu TLS/SSL je identifikace chybových zpráv, které se vám nebo vašim uživatelům zobrazují při pokusu o přístup k flexibilnímu serveru Azure Database for PostgreSQL v rámci šifrování TLS z klienta. V závislosti na aplikaci a platformě se můžou chybové zprávy lišit. V mnoha případech odkazují na základní problém.

  2. Pokud chcete mít jistotu kompatibility s verzí protokolu TLS/SSL, zkontrolujte konfiguraci protokolu TLS/SSL databázového serveru a klienta aplikace a ujistěte se, že podporuje kompatibilní verze a šifrovací sady.

  3. Analyzujte případné nesrovnalosti nebo mezery mezi databázovým serverem a verzemi TLS/SSL klienta a šifrovacími sadami. Zkuste je vyřešit povolením nebo zakázáním určitých možností, upgradem nebo downgradováním softwaru nebo změnou certifikátů nebo klíčů. V závislosti na požadavcích na zabezpečení a kompatibilitu může být například potřeba povolit nebo zakázat konkrétní verze TLS/SSL na serveru nebo klientovi. Můžete například potřebovat zakázat protokol TLS 1.0 a TLS 1.1, které jsou považovány za nezabezpečené a zastaralé, a povolit protokol TLS 1.2 a TLS 1.3, které jsou bezpečnější a modernější.

  4. Nejnovější certifikát vydaný u kořenové certifikační autority Microsoft RSA 2017 má v řetězu křížově podepsaný globální kořenovou certifikační autoritou Digicert G2. U některých klientských knihoven Postgres při používání sslmode=verify-full nebo sslmode=verify-ca nastavení může docházet k chybám připojení s kořenovými certifikáty certifikační autority, které jsou křížově podepsané pomocí zprostředkujících certifikátů. Výsledkem jsou alternativní cesty důvěryhodnosti.

    Chcete-li tyto problémy vyřešit, přidejte všechny tři nezbytné certifikáty do úložiště klientských certifikátů nebo explicitně zadejte sslrootcert parametr. Nebo nastavte proměnnou PGSSLROOTCERT prostředí na místní cestu, kde je umístěn kořenový certifikát kořenové certifikační autority Microsoft RSA 2017 z výchozí hodnoty %APPDATA%\postgresql\root.crt.

Související obsah

  • Zjistěte, jak vytvořit flexibilní server Azure Database for PostgreSQL pomocí možnosti Privátní přístup (integrace virtuální sítě) na webu Azure Portal nebo v Azure CLI.
  • Zjistěte, jak vytvořit flexibilní server Azure Database for PostgreSQL pomocí možnosti Veřejný přístup (povolené IP adresy) na webu Azure Portal nebo v Azure CLI.