Dela 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 tillämpar anslutning av dina klientprogram till Azure Database for PostgreSQL – flexibel 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 tillverkades från Netscapes SSL-protokoll och har regelbundet ersatt det. Termerna SSL eller TLS/SSL används fortfarande ibland omväxlande. TLS består av två lager: TLS-postshowen och TLS-handskakningsshowen. Arkivhandlingsshowen ger associationsäkerhet. 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.

Föregående diagram visar en typisk TLS 1.2-handskakningssekvens, som består av följande steg:

  1. Klienten börjar med att skicka ett meddelande med namnet ClientHello som uttrycker viljan att kommunicera via TLS 1.2 med en uppsättning chiffersviter som klienten stöder.
  2. Servern tar emot meddelandet, svarar med ServerHellooch samtycker till att kommunicera med klienten via TLS 1.2 med hjälp av en viss chiffersvit.
  3. Servern skickar också sin nyckelresurs. Detaljerna för den här nyckelresursen ändras baserat på chiffersviten som valdes. 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 [CA]) och en signatur för delar av ClientHello och ServerHello. Den innehåller även nyckelresursen. På så sätt vet klienten att de är autentiska.
  5. När klienten har tagit emot data och sedan genererar en egen nyckelresurs blandas den med servernyckelresursen för att generera krypteringsnycklar för sessionen.
  6. Klienten skickar sin nyckelresurs till servern, aktiverar kryptering och skickar ett Finished meddelande. Det här meddelandet är en hash av en avskrift av vad som har hänt hittills. Servern gör samma sak. Den blandar nyckelresurserna för att hämta nyckeln och skickar ett eget Finished meddelande.
  7. Nu kan programdata skickas krypterade på anslutningen.

Certifikatkedjor

En certifikatkedja är en ordnad lista över certifikat som innehåller ett TLS/SSL-certifikat och CA-certifikat. De gör det möjligt för mottagaren att kontrollera att avsändaren och alla certifikatutfärdare är betrodda. Kedjan eller sökvägen börjar med TLS/SSL-certifikatet. Varje certifikat i kedjan signeras av entiteten som identifieras av nästa certifikat i kedjan.

Kedjan avslutas med ett rotcertifikatutfärdarcertifikat. Certifikatet signeras alltid av certifikatutfärdare själv. Signaturerna för alla certifikat i kedjan måste verifieras upp till rotcertifikatutfärdarcertifikatet.

Alla certifikat som finns mellan TLS/SSL-certifikatet och rotcertifikatutfärdarcertifikatet i kedjan kallas för ett mellanliggande certifikat.

TLS-versioner

Flera statliga entiteter över hela världen upprätthåller riktlinjer för TLS när det gäller nätverkssäkerhet. I USA inkluderar dessa organisationer Department of Health and Human Services och National Institute of Standards and Technology. 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 som innehåller ett chiffer, en nyckelutbytesalgoritm och en hashalgoritm. De används tillsammans för att upprätta en säker TLS-anslutning. De flesta TLS-klienter och -servrar stöder flera alternativ. 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.

IETF släppte TLS 1.3-specifikationen i RFC 8446 i augusti 2018 och TLS 1.3 är nu den vanligaste och rekommenderade TLS-versionen som används. TLS 1.3 är snabbare och säkrare än TLS 1.2.

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. Vi rekommenderar starkt att du använder de senaste versionerna av TLS för att kryptera dina anslutningar till Azure Database for PostgreSQL – flexibel server.

Även om vi inte rekommenderar det kan du inaktivera TLS\SSL för anslutningar till Azure Database for PostgreSQL – flexibel server om det behövs. Du kan uppdatera serverparametern require_secure_transport till OFF. Du kan också ange TLS-versionen genom att ange ssl_min_protocol_version och ssl_max_protocol_version serverparametrar.

Certifikatautentisering utförs med hjälp av SSL-klientcertifikat för autentisering. I det här scenariot jämför PostgreSQL-servern det gemensamma namnattributet (CN) för klientcertifikatet som visas mot den begärda databasanvändaren.

För närvarande stöder inte Azure Database for PostgreSQL – flexibel server:

Kommentar

Microsoft har gjort rotcertifikatutfärdarändringar för olika Azure-tjänster, inklusive Azure Database for PostgreSQL – flexibel server. Mer information finns i Ändringar av Azure TLS-certifikat och avsnittet Konfigurera SSL på klienten.

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 den flexibla SSL-användningen för din Azure Database for PostgreSQL-server efter 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 openssl kommandot direkt:

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

Det här kommandot skriver ut protokollinformation på låg nivå, t.ex. TLS-versionen och chiffer. Du måste använda alternativet -starttls postgres. 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.

Om du vill framtvinga den senaste säkraste TLS-versionen för anslutningsskydd från klienten till Azure Database for PostgreSQL – flexibel server anger du ssl_min_protocol_version till 1.3. Den inställningen kräver att klienter som ansluter till din flexibla Azure Database for PostgreSQL-server endast använder den här versionen av protokollet för att kommunicera på ett säkert sätt. Äldre klienter kanske inte kan 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. Därför är det möjligt 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 kostnader i form av kryptering och nyckelutbyte, så en kompromiss görs 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 är:

  • 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 är värdet true att föredra. När du upprättar en SSL-anslutning i det här läget validerar klientdrivrutinen serverns identitet för att förhindra man-in-the-middle-attacker. Den kontrollerar att servercertifikatet är signerat av en betrodd utfärdare och att värden som du ansluter till är samma som värdnamnet i certifikatet.

  • sslmode: Om du behöver kryptering och vill att anslutningen ska misslyckas om den inte kan krypteras anger du sslmode=require. Den här inställningen 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. Om servern inte accepterar SSL-anslutningar eller om klientcertifikatet inte identifieras misslyckas anslutningen. I följande tabell visas värden för den här inställningen:

    SSL-läge Förklaring
    disable Kryptering används inte.
    allow Kryptering används om serverinställningarna kräver eller framtvingar den.
    prefer Kryptering används om serverinställningarna tillåter det.
    require Kryptering används. Det 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. Verifiera servercertifikatsignaturen mot certifikatet som lagras på klienten.
    verify-full Kryptering används. Verifiera servercertifikatets signatur och värdnamn mot certifikatet som lagras på klienten.

    sslmode Standardläget som används skiljer sig mellan libpq-baserade klienter (till exempel psql) och JDBC. De libpq-baserade klienterna är som standard prefer. JDBC-klienter är som standard verify-full.

  • sslcert, sslkey, och sslrootcert: Dessa parametrar kan åsidosätta standardplatsen för klientcertifikatet, PKCS-8-klientnyckeln och rotcertifikatet. De är som standard /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8respektive /defaultdir/root.crt, var defaultdir finns ${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 att de är. 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.

Användningsverify-ca- och sslmode verify-full konfigurationsinställningar kan också kallas för certifikatanslutning. I det här fallet måste rotcertifikatutfärdarcertifikat på PostgreSQL-servern matcha certifikatsignaturen och till och med värdnamnet mot certifikatet på klienten.

Du kan regelbundet behöva uppdatera klientlagrade certifikat när certifikatutfärdare ändras eller upphör att gälla på PostgreSQL-servercertifikat. Information om hur du fäster certifikatutfärdare finns i Fäst certifikat och Azure-tjänster.

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

För klienter som använder verify-ca och verify-full sslmode konfigurationsinställningar (d.s. certifikatanslutning) måste de distribuera tre rotcertifikatutfärdarcertifikat till klientcertifikatarkivet:

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

Du kan ladda ned certifikat om du vill uppdatera klientprogram i scenarier för certifikatanslutning:

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 föregående URI:er. Du kan använda OpenSSL-verktyget för att utföra dessa filkonverteringar:

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

Information om hur du uppdaterar certifikatarkiv för klientprogram med nya rotcertifikatutfärdarcertifikat finns i Uppdatera klient-TLS-certifikat för programklienter.

Viktigt!

Vissa av Postgres-klientbiblioteken sslmode=verify-full kan, när du använder inställningen, uppleva anslutningsfel med rotcertifikatutfärdarcertifikat som är korssignerade med mellanliggande certifikat. Resultatet är alternativa förtroendesökvägar. I det här fallet rekommenderar vi att du uttryckligen anger parametern sslrootcert . Eller ange PGSSLROOTCERT miljövariabeln till en lokal sökväg där Rotcertifikatutfärdarcertifikatutfärdare för Microsoft RSA 2017 placeras, från standardvärdet %APPDATA%\postgresql\root.crtför .

Läsa repliker med scenarier för certifikatstiftning

Med rot-CA-migrering till Microsoft RSA Root CA 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 verify-ca och verify-full sslmode konfigurationsinställningar (d.s.a. certifikatanslutning) är det absolut nödvändigt att avbryta anslutningen för att acceptera tre rotcertifikatutfärdarcertifikat:

För närvarande stöder Inte Azure Database for PostgreSQL – flexibel server certifikatbaserad autentisering.

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

Du kan använda kommandoraden psql från klienten för att testa anslutningen till servern i scenarier med certifikatsanknering:


$ 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 TLS/SSL-anslutning

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

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 ssl_is_used() funktionen för att avgöra om SSL används. Funktionen returnerar t om anslutningen använder SSL. Annars returneras f.

Chiffreringssviter

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 innehåller den här datasträngen 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 TLS/SSL stöder olika chiffersviter. TLS 1.2-chiffersviter kan inte förhandlas med TLS 1.3-anslutningar och vice versa.

För närvarande stöder Azure Database for PostgreSQL – Flexibel server många chiffersviter med TLS 1.2-protokollversionen som tillhör kategorin HIGH:!aNULL .

Felsöka TLS/SSL-anslutningsfel

  1. Det första steget för att felsöka TLS/SSL-protokollversionskompatibilitet är att identifiera de felmeddelanden som du eller dina användare ser när de försöker komma åt din flexibla Azure Database for PostgreSQL-server under TLS-kryptering från klienten. Beroende på program och plattform kan felmeddelandena vara olika. I många fall pekar de på det underliggande problemet.

  2. För att vara säker på TLS/SSL-protokollversionskompatibilitet kontrollerar du TLS/SSL-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 TLS/SSL-versioner och chiffersviter. 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 TLS/SSL-versioner på servern eller klienten, beroende på säkerhet och kompatibilitetskrav. Du kan till exempel behöva inaktivera TLS 1.0 och TLS 1.1, som anses vara inaktuella och inaktuella, och aktivera TLS 1.2 och TLS 1.3, som är säkrare och modernare.

  4. Det senaste certifikatet som utfärdats med Microsoft RSA Root CA 2017 har mellanliggande i kedjan som korssignerats av Digicert Global Root G2 CA. Vissa av Postgres-klientbiblioteken kan uppleva anslutningsfel med rotcertifikatutfärdarcertifikat som är korssignerade med mellanliggande certifikat när du använder sslmode=verify-full eller sslmode=verify-ca inställningar. Resultatet är alternativa förtroendesökvägar.

    Om du vill undvika dessa problem lägger du till alla tre nödvändiga certifikaten i klientcertifikatarkivet eller anger uttryckligen parametern sslrootcert . Du kan också ange PGSSLROOTCERT miljövariabeln till den lokala sökväg där Rotcertifikatutfärdarcertifikatutfärdare för Microsoft RSA 2017 placeras från standardvärdet %APPDATA%\postgresql\root.crt.

Relaterat innehåll

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