Dela via

Säker anslutning med TLS i Azure Database for PostgreSQL

Azure Database for PostgreSQL tillämpar anslutning av klientprogram till en flexibel Azure Database for PostgreSQL-serverinstans 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). Termerna SSL och TLS används fortfarande omväxlande.

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.

Anmärkning

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 en flexibel Azure Database for PostgreSQL-serverinstans.

Även om vi inte rekommenderar det, kan du, om det behövs, inaktivera TLS/SSL för anslutningar till din Azure Database for PostgreSQL–flexibel-serverinstans. 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:

Anmärkning

Microsoft har gjort rotcertifikatutfärdarändringar för olika Azure-tjänster, inklusive Azure Database for PostgreSQL. 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 din Azure Database for PostgreSQL flexibla serverinstans SSL-användning av processer, klienter och applikationer 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 en flexibel Azure Database for PostgreSQL-serverinstans anger du ssl_min_protocol_version till 1.3. Den inställningen kräver att klienter som ansluter till din flexibla serverinstans i Azure Database for PostgreSQL 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 Explanation
    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ändnings verify-ca - och verify-fullsslmode 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-fullsslmode 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-fullsslmode 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 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.

Chiffersviter

En chiffersvit är en uppsättning kryptografiska algoritmer. 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 många chiffersviter med protokollversionen TLS 1.2 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-serverinstans 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