Share via

Säker anslutning med TLS och SSL i Azure Database for PostgreSQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Azure Database for PostgreSQL – flexibel server tvingar dig att ansluta dina klientprogram till en flexibel Azure Database for PostgreSQL-server med hjälp av TLS (Transport Layer Security). TLS är ett branschstandardprotokoll som säkerställer krypterade nätverksanslutningar mellan databasservern och klientprogrammen. TLS är ett uppdaterat protokoll för Secure Sockets Layer (SSL).

Vad är TLS? 

TLS tillverkad av Netscape Communications Corp's. Secure Sockets Layer visar och har regelbundet ersatt det, men termerna SSL eller SSL/TLS används fortfarande ibland omväxlande. TLS består av två lager: TLS-postshowen och TLS-handskakningsshowen. Arkivhandlingsshowen ger associationsäkerhet, medan handskakningsshowen ger servern och kunden möjlighet att bekräfta varandra och samordna krypteringsutvärderingar och kryptografiska nycklar innan någon information handlas.

Diagram som visar typisk TLS 1.2-handskakningssekvens.

Diagrammet ovan visar typisk TLS 1.2-handskakningssekvens, bestående av följande:

  1. Klienten börjar med att skicka ett meddelande med namnet ClientHello, som i huvudsak uttrycker vilja att kommunicera via TLS 1.2 med en uppsättning chiffersviter som klienten stöder
  2. Servern tar emot det och svarar med en ServerHello som samtycker till kommunikation med klienten via TLS 1.2 med hjälp av en viss chiffersvit
  3. Tillsammans med att servern skickar sin nyckelresurs. Detaljerna för den här nyckelresursen ändras baserat på vilken chiffersvit som valdes. Den viktiga informationen att notera är att för att klienten och servern ska kunna komma överens om en kryptografisk nyckel måste de ta emot varandras del eller dela.
  4. Servern skickar certifikatet (signerat av certifikatutfärdare) och en signatur på delar av ClientHello och ServerHello, inklusive nyckelresursen, så att klienten vet att de är äkta.
  5. När klienten har tagit emot ovan nämnda data och sedan genererar en egen nyckelresurs, blandas den med servernyckelresursen och genererar därmed krypteringsnycklarna för sessionen.
  6. Som de sista stegen skickar klienten sin nyckelresurs till servern, aktiverar kryptering och skickar ett slutfört meddelande (vilket är en hash av en avskrift av vad som hände hittills). Servern gör samma sak: den blandar nyckelresurserna för att hämta nyckeln och skickar ett eget slutfört meddelande.
  7. Vid den tidpunkten kan programdata skickas krypterade på anslutningen.

Certifikatkedjor

En certifikatkedja är en ordnad lista över certifikat som innehåller ett SSL/TLS-certifikat och certifikatutfärdarcertifikat (CA) som gör det möjligt för mottagaren att kontrollera att avsändaren och alla CA:er är betrodda. Kedjan eller sökvägen börjar med SSL/TLS-certifikatet och varje certifikat i kedjan signeras av entiteten som identifieras av nästa certifikat i kedjan. Kedjan avslutas med ett rotcertifikatutfärdarcertifikat. Rotcertifikatutfärdarcertifikatet signeras alltid av certifikatutfärdare (CA). Signaturerna för alla certifikat i kedjan måste verifieras upp till rotcertifikatutfärdarcertifikatet. Alla certifikat som finns mellan SSL/TLS-certifikatet och rotcertifikatutfärdarcertifikatet i kedjan kallas för ett mellanliggande certifikat.

TLS-versioner

Det finns flera statliga entiteter över hela världen som upprätthåller riktlinjer för TLS när det gäller nätverkssäkerhet, inklusive Department of Health and Human Services (HHS) eller National Institute of Standards and Technology (NIST) i USA. Den säkerhetsnivå som TLS tillhandahåller påverkas mest av TLS-protokollversionen och de chiffersviter som stöds. En chiffersvit är en uppsättning algoritmer, inklusive ett chiffer, en nyckelutbytesalgoritm och en hashalgoritm, som används tillsammans för att upprätta en säker TLS-anslutning. De flesta TLS-klienter och -servrar stöder flera alternativ, så de måste förhandla när de upprättar en säker anslutning för att välja en gemensam TLS-version och chiffersvit.

Azure Database for PostgreSQL stöder TLS version 1.2 och senare. I RFC 8996 anger IETF (Internet Engineering Task Force) uttryckligen att TLS 1.0 och TLS 1.1 inte får användas. Båda protokollen var inaktuella i slutet av 2019.

Alla inkommande anslutningar som använder tidigare versioner av TLS-protokollet, till exempel TLS 1.0 och TLS 1.1, nekas som standard.

Kommentar

SSL- och TLS-certifikat intygar att anslutningen skyddas med toppmoderna krypteringsprotokoll. Genom att kryptera anslutningen på kabeln förhindrar du obehörig åtkomst till dina data under överföring. Därför rekommenderar vi starkt att du använder de senaste versionerna av TLS för att kryptera dina anslutningar till en flexibel Azure Database for PostgreSQL-server.
Även om det inte rekommenderas kan du, om det behövs, inaktivera TLS\SSL för anslutningar till azure database for PostgreSQL – flexibel server genom att uppdatera require_secure_transport-serverparametern till OFF. Du kan också ange TLS-version genom att ange ssl_min_protocol_version och ssl_max_protocol_version serverparametrar.

Certifikatautentisering utförs med SSL-klientcertifikat för autentisering. I det här scenariot jämför PostgreSQL-servern attributet CN (common name) för klientcertifikatet som visas mot den begärda databasanvändaren. Azure Database for PostgreSQL – flexibel server stöder för närvarande inte SSL-certifikatbaserad autentisering.

Kommentar

Azure Database for PostgreSQL – flexibel server stöder för närvarande inte anpassade SSL\TLS-certifikat .

För att fastställa din aktuella TLS\SSL-anslutningsstatus kan du läsa in sslinfo-tillägget och sedan anropa ssl_is_used() funktionen för att avgöra om SSL används. Funktionen returnerar t om anslutningen använder SSL, annars returneras f. Du kan också samla in all information om azure Database for PostgreSQL-flexibel serverinstans SSL-användning per process, klient och program med hjälp av följande fråga:

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;

För testning kan du också använda kommandot openssl direkt, till exempel:

openssl s_client -connect localhost:5432 -starttls postgres

Det här kommandot skriver ut många protokollinformation på låg nivå, inklusive TLS-versionen, chiffer och så vidare. Du måste använda alternativet -starttls postgres, eller annars rapporterar det här kommandot att ingen SSL används. Om du använder det här kommandot krävs minst OpenSSL 1.1.1.

Kommentar

För att framtvinga den senaste, säkraste TLS-versionen för anslutningsskydd från klient till Azure Database for PostgreSQL – flexibel serveruppsättning ssl_min_protocol_version till 1.3. Det skulle kräva att klienter som ansluter till din flexibla Azure Database for PostgreSQL-serverinstans endast använder den här versionen av protokollet för att kommunicera på ett säkert sätt. Äldre klienter kan dock inte kommunicera med servern eftersom de inte stöder den här versionen.

Konfigurera SSL på klienten

PostgreSQL utför som standard ingen verifiering av servercertifikatet. Det innebär att det går att förfalska serveridentiteten (till exempel genom att ändra en DNS-post eller genom att ta över serverns IP-adress) utan att klienten vet om det. Alla SSL-alternativ medför omkostnader i form av kryptering och nyckelutbyte, så det finns en kompromiss som måste göras mellan prestanda och säkerhet. För att förhindra förfalskning måste SSL-certifikatverifiering på klienten användas. Det finns många anslutningsparametrar för att konfigurera klienten för SSL. Några viktiga för oss är:

  1. ssl. Anslut med SSL. Den här egenskapen behöver inte något associerat värde. Blotta förekomsten av den anger en SSL-anslutning. För kompatibilitet med framtida versioner föredras dock värdet "true". I det här läget validerar klientdrivrutinen när en SSL-anslutning upprättas serverns identitet och förhindrar "man i mitten"-attacker. Det gör det genom att kontrollera att servercertifikatet är signerat av en betrodd utfärdare och att värden som du ansluter till är samma som värdnamnet i certifikatet.
  2. sslmode. Om du behöver kryptering och vill att anslutningen ska misslyckas om den inte kan krypteras anger du sslmode=require. Detta säkerställer att servern är konfigurerad för att acceptera SSL-anslutningar för den här värden/IP-adressen och att servern känner igen klientcertifikatet. Med andra ord misslyckas anslutningen om servern inte accepterar SSL-anslutningar eller om klientcertifikatet inte identifieras. Tabellen nedan visar värden för den här inställningen:
SSL-läge Förklaring
disable Kryptering används inte
Tillåta Kryptering används om f serverinställningarna kräver\framtvingar det
Föredrar Kryptering används om serverinställningarna tillåter det
Kräver Kryptering används. Detta säkerställer att servern är konfigurerad för att acceptera SSL-anslutningar för den här värd-IP-adressen och att servern känner igen klientcertifikatet.
verify-ca Kryptering används. Kontrollera dessutom servercertifikatets signatur mot certifikatet som lagras på klienten
verify-full Kryptering används. Kontrollera dessutom servercertifikatets signatur och värdnamn mot certifikatet som lagras på klienten

Standardläget för sslmode skiljer sig mellan libpq-baserade klienter (till exempel psql) och JDBC. De libpq-baserade klienterna föredrar som standard, och JDBC-klienterna är som standard verifierade.

  1. sslcert, sslkey och sslrootcert. Dessa parametrar kan åsidosätta standardplatsen för klientcertifikatet, PKCS-8-klientnyckeln och rotcertifikatet. Dessa standardvärden är /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8 och /defaultdir/root.crt där defaultdir är ${user.home}/.postgresql/ i *nix-system och %appdata%/postgresql/ i windows.

Certifikatutfärdare är de institutioner som ansvarar för att utfärda certifikat. En betrodd certifikatutfärdare är en entitet som har rätt att verifiera att någon är den de säger sig vara. För att den här modellen ska fungera måste alla deltagare komma överens om en uppsättning betrodda certifikatutfärdare. Alla operativsystem och de flesta webbläsare levereras med en uppsättning betrodda certifikatutfärdare.

Kommentar

Med hjälp av konfigurationsinställningarna verify-ca och verify-full sslmode kan du även kallas för certifikatstiftning. I det här fallet måste rotcertifikatutfärdarcertifikat på PostgreSQL-servern matcha certifikatsignaturen och till och med värdnamnet mot certifikatet på klienten. Viktigt att komma ihåg är att du med jämna mellanrum behöver uppdatera klient lagrade certifikat när certifikatutfärdare ändras eller upphör att gälla för PostgreSQL-servercertifikat. Om du vill ta reda på om du fäster certifikatutfärdare kan du läsa Mer information om att fästa certifikat och Azure-tjänster.

Mer information om SSL\TLS-konfiguration på klienten finns i PostgreSQL-dokumentationen.

Kommentar

För klienter som använder konfigurationsinställningarna verify-ca och verify-full sslmode, d.v.s. certifikatanslutning, måste de acceptera båda rotcertifikatutfärdarcertifikaten:

Ladda ned rotcertifikatutfärdarcertifikat och uppdatera programklienter i scenarier för att fästa certifikat

Om du vill uppdatera klientprogram i scenarier för certifikatanslutning kan du ladda ned certifikat från följande URI:er:

Om du vill importera certifikat till klientcertifikatarkiv kan du behöva konvertera .crt-certifikatfiler till .pem-format när du har laddat ned certifikatfiler från URI:er ovan. Du kan använda OpenSSL-verktyget för att utföra dessa filkonverteringar, som du ser i exemplet nedan:

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

Detaljerad information om hur du uppdaterar certifikatarkiv för klientprogram med nya rotcertifikatutfärdarcertifikat har dokumenterats i det här instruktioner-dokumentet.

Viktigt!

Vissa av Postgres-klientbiblioteken kan, när du använder inställningen sslmode=verify-full , uppleva anslutningsfel med rotcertifikatutfärdarcertifikat som är korssignerade med mellanliggande certifikat, vilket resulterar i alternativa förtroendesökvägar. I det här fallet rekommenderar vi att du uttryckligen anger parametern sslrootcert , som beskrivs ovan, eller anger miljövariabeln PGSSLROOTCERT till lokal sökväg där Microsoft RSA Root Certificate Authority 2017 Root CA-certifikatet placeras, från standardvärdet %APPDATA%\postgresql\root.crt.

Läsa repliker med scenarier för certifikatanslutning

Med rotcertifikatutfärdares migrering till Microsoft RSA Root Certificate Authority 2017 är det möjligt att nyligen skapade repliker finns på ett nyare rotcertifikatutfärdarcertifikat än den primära server som skapades tidigare. För klienter som använder konfigurationsinställningarna verify-ca och verify-full sslmode är det därför absolut nödvändigt att avbryta anslutningen för att acceptera båda rotcertifikatutfärdarcertifikaten:

Kommentar

Azure Database for PostgreSQL – flexibel server stöder inte certifikatbaserad autentisering just nu.

Testa klientcertifikat genom att ansluta med psql i scenarier för certifikatanslutning

Du kan använda psql-kommandoraden från klienten för att testa anslutningen till servern i scenarier för certifikatanslutning, som du ser i exemplet nedan:


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

Mer information om ssl- och certifikatparametrar finns i psql-dokumentationen.

Testa SSL/TLS-Anslut ivitet

Innan du försöker komma åt din SSL-aktiverade server från klientprogrammet kontrollerar du att du kan komma åt den via psql. Du bör se utdata som liknar följande om du har upprättat en SSL-anslutning.

psql (14.5)SSL-anslutning (protokoll: TLSv1.2, chiffer: ECDHE-RSA-AES256-GCM-SHA384, bitar: 256, komprimering: av)Skriv "hjälp" för hjälp.

Du kan också läsa in sslinfo-tillägget och sedan anropa funktionen ssl_is_used() för att avgöra om SSL används. Funktionen returnerar t om anslutningen använder SSL, annars returneras f.

Chiffersviter

En chiffersvit är en uppsättning krypteringsalgoritmer. TLS/SSL-protokoll använder algoritmer från en chiffersvit för att skapa nycklar och kryptera information. En chiffersvit visas som en lång sträng med till synes slumpmässig information, men varje segment i strängen innehåller viktig information. I allmänhet består den här datasträngen av flera viktiga komponenter:

  • Protokoll (t.ex. TLS 1.2 eller TLS 1.3)
  • Nyckelutbytes- eller avtalsalgoritm
  • Algoritm för digital signatur (autentisering)
  • Masskrypteringsalgoritm
  • Kodalgoritm för meddelandeautentisering (MAC)

Olika versioner av SSL/TLS stöder olika chiffersviter. TLS 1.2-chiffersviter kan inte förhandlas med TLS 1.3-anslutningar och vice versa. Från och med den här gången stöder Azure Database for PostgreSQL flexibel server många chiffersviter med TLS 1.2-protokollversion som ingår i kategorin HIGH:!aNULL .

Felsöka SSL\TLS-anslutningsfel

  1. Det första steget för att felsöka SSL/TLS-protokollversionskompatibilitet är att identifiera de felmeddelanden som du eller dina användare ser när de försöker komma åt din Azure Database for PostgreSQL – flexibel server under TLS-kryptering från klienten. Beroende på program och plattform kan felmeddelandena vara olika, men i många fall peka på underliggande problem.
  2. För att vara säker på SSL/TLS-protokollversionskompatibilitet bör du kontrollera SSL/TLS-konfigurationen för databasservern och programklienten för att se till att de stöder kompatibla versioner och chiffersviter.
  3. Analysera eventuella avvikelser eller luckor mellan databasservern och klientens SSL/TLS-versioner och chiffersviter och försök att lösa dem genom att aktivera eller inaktivera vissa alternativ, uppgradera eller nedgradera programvara eller ändra certifikat eller nycklar. Du kan till exempel behöva aktivera eller inaktivera specifika SSL/TLS-versioner på servern eller klienten beroende på säkerhet och kompatibilitetskrav – till exempel att inaktivera TLS 1.0 och TLS 1.1, som anses vara osäkra och inaktuella, samt aktivera TLS 1.2 och TLS 1.3, som är säkrare och modernare.

Relaterat innehåll

  • Lär dig hur du skapar en flexibel Azure Database for PostgreSQL-serverinstans med alternativet Privat åtkomst (VNet-integrering) i Azure-portalen eller Azure CLI.
  • Lär dig hur du skapar en flexibel Azure Database for PostgreSQL-serverinstans med alternativet Offentlig åtkomst (tillåtna IP-adresser) i Azure-portalen eller Azure CLI.