Delen via

Beveiligde connectiviteit met TLS en SSL in Azure Database for PostgreSQL - Flexibele server

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

Azure Database for PostgreSQL - Flexible Server dwingt het verbinden van uw clienttoepassingen af met Azure Database for PostgreSQL - Flexible Server met behulp van Transport Layer Security (TLS). TLS is een industriestandaard protocol dat zorgt voor versleutelde netwerkverbindingen tussen uw databaseserver en clienttoepassingen. TLS is een bijgewerkt protocol van Secure Sockets Layer (SSL).

Wat is TLS?

TLS is gemaakt van het SSL-protocol van Netscape en is regelmatig vervangen. De termen SSL of TLS/SSL worden soms nog steeds door elkaar gebruikt. TLS bestaat uit twee lagen: de TLS-record wordt weergegeven en de TLS-handshake-show. De recordvoorstelling geeft koppelingsbeveiliging. De handshake geeft de server en de klant de mogelijkheid om elkaar te bevestigen en versleutelingsevaluaties en cryptografische sleutels te coördineren voordat informatie wordt verhandeld.

Diagram met typische TLS 1.2-handshakereeks.

In het voorgaande diagram ziet u een typische TLS 1.2-handshakereeks, die uit deze stappen bestaat:

  1. De client begint met het verzenden van een bericht ClientHello dat de wil uitdrukt om te communiceren via TLS 1.2 met een set coderingssuites die de client ondersteunt.
  2. De server ontvangt het bericht, antwoorden met ServerHelloen stemt ermee in om via TLS 1.2 met behulp van een bepaalde coderingssuite te communiceren met de client.
  3. De server verzendt ook de sleutelshare. De details van deze sleutelshare worden gewijzigd op basis van de geselecteerde coderingssuite. De client en server moeten elkaars gedeelte of share ontvangen om akkoord te gaan met een cryptografische sleutel.
  4. De server verzendt het certificaat (ondertekend door de certificeringsinstantie [CA]) en een handtekening op delen van ClientHello en ServerHello. Het bevat ook de sleutelshare. Op deze manier weet de klant dat ze authentiek zijn.
  5. Nadat de client de gegevens heeft ontvangen en vervolgens een eigen sleutelshare heeft gegenereerd, wordt deze gemengd met de serversleutelshare om versleutelingssleutels voor de sessie te genereren.
  6. De client verzendt de sleutelshare van de server, schakelt versleuteling in en verzendt een Finished bericht. Dit bericht is een hash van een transcriptie van wat er tot nu toe is gebeurd. De server doet hetzelfde. Het combineert de sleutelshares om de sleutel op te halen en verzendt een eigen Finished bericht.
  7. Toepassingsgegevens kunnen nu worden versleuteld verzonden op de verbinding.

Certificaatketens

Een certificaatketen is een geordende lijst met certificaten die een TLS/SSL-certificaat en CA-certificaten bevatten. Ze stellen de ontvanger in staat om te controleren of de afzender en alle CA's betrouwbaar zijn. De keten of het pad begint met het TLS/SSL-certificaat. Elk certificaat in de keten wordt ondertekend door de entiteit die is geïdentificeerd door het volgende certificaat in de keten.

De keten wordt beëindigd met een basis-CA-certificaat. Dit certificaat wordt altijd ondertekend door de CA zelf. De handtekeningen van alle certificaten in de keten moeten worden geverifieerd tot aan het basis-CA-certificaat.

Elk certificaat dat zich tussen het TLS/SSL-certificaat en het basis-CA-certificaat in de keten bevindt, wordt een tussenliggend certificaat genoemd.

TLS-versies

Verschillende overheidsentiteiten wereldwijd onderhouden richtlijnen voor TLS met betrekking tot netwerkbeveiliging. In de Verenigde Staten omvatten deze organisaties het Ministerie van Gezondheid en Human Services en het National Institute of Standards and Technology. Het beveiligingsniveau dat TLS biedt, wordt het meest beïnvloed door de TLS-protocolversie en de ondersteunde coderingssuites.

Een coderingssuite is een set algoritmen die een codering, een algoritme voor sleuteluitwisseling en een hash-algoritme bevatten. Ze worden samen gebruikt om een beveiligde TLS-verbinding tot stand te brengen. De meeste TLS-clients en -servers ondersteunen meerdere alternatieven. Ze moeten onderhandelen wanneer ze een beveiligde verbinding tot stand brengen om een gemeenschappelijke TLS-versie en coderingssuite te selecteren.

Azure Database for PostgreSQL ondersteunt TLS-versie 1.2 en hoger. In RFC 8996 geeft de Internet Engineering Task Force (IETF) expliciet aan dat TLS 1.0 en TLS 1.1 niet mogen worden gebruikt. Beide protocollen zijn eind 2019 afgeschaft.

Alle binnenkomende verbindingen die gebruikmaken van eerdere versies van het TLS-protocol, zoals TLS 1.0 en TLS 1.1, worden standaard geweigerd.

De IETF heeft de TLS 1.3-specificatie uitgebracht in RFC 8446 in augustus 2018 en TLS 1.3 is nu de meest voorkomende en aanbevolen TLS-versie die wordt gebruikt. TLS 1.3 is sneller en veiliger dan TLS 1.2.

Notitie

SSL- en TLS-certificaten certificeren dat uw verbinding is beveiligd met geavanceerde versleutelingsprotocollen. Door uw verbinding op de kabel te versleutelen, voorkomt u onbevoegde toegang tot uw gegevens tijdens de overdracht. We raden u ten zeerste aan om de nieuwste versies van TLS te gebruiken om uw verbindingen met Azure Database for PostgreSQL - Flexible Server te versleutelen.

Hoewel we het niet aanbevelen, kunt u, indien nodig, TLS\SSL uitschakelen voor verbindingen met Azure Database for PostgreSQL - Flexible Server. U kunt de require_secure_transport serverparameter bijwerken naar OFF. U kunt ook de TLS-versie instellen door parameters in te stellen ssl_min_protocol_version en ssl_max_protocol_version serverparameters.

Certificaatverificatie wordt uitgevoerd met SSL-clientcertificaten voor verificatie. In dit scenario vergelijkt de PostgreSQL-server het kenmerk common name (CN) van het clientcertificaat dat wordt gepresenteerd aan de aangevraagde databasegebruiker.

Op dit moment biedt Azure Database for PostgreSQL - Flexible Server geen ondersteuning voor:

Notitie

Microsoft heeft hoofd-CA-wijzigingen aangebracht voor verschillende Azure-services, waaronder Azure Database for PostgreSQL - Flexible Server. Zie azure TLS-certificaatwijzigingen en de sectie SSL configureren op de client voor meer informatie.

Als u de huidige TLS\SSL-verbindingsstatus wilt bepalen, kunt u de sslinfo-extensie laden en vervolgens de ssl_is_used() functie aanroepen om te bepalen of SSL wordt gebruikt. De functie retourneert t als de verbinding SSL gebruikt. Anders wordt het geretourneerd f. U kunt ook alle informatie verzamelen over het SSL-gebruik van uw flexibele Azure Database for PostgreSQL-server per proces, client en toepassing met behulp van de volgende query:

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;

Voor het testen kunt u de openssl opdracht ook rechtstreeks gebruiken:

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

Met deze opdracht worden protocolgegevens op laag niveau afgedrukt, zoals de TLS-versie en codering. U moet de optie -starttls postgresgebruiken. Anders meldt deze opdracht dat er geen SSL wordt gebruikt. Voor het gebruik van deze opdracht is ten minste OpenSSL 1.1.1 vereist.

Als u de nieuwste, veiligste TLS-versie wilt afdwingen voor connectiviteitsbeveiliging van de client naar Azure Database for PostgreSQL - Flexible Server, ingesteld ssl_min_protocol_version op 1.3. Voor deze instelling moeten clients die verbinding maken met uw flexibele Azure Database for PostgreSQL-server deze versie van het protocol alleen gebruiken om veilig te communiceren. Oudere clients kunnen mogelijk niet communiceren met de server omdat ze deze versie niet ondersteunen.

SSL configureren op de client

PostgreSQL voert standaard geen verificatie uit van het servercertificaat. Daarom is het mogelijk om de serveridentiteit te spoofen (bijvoorbeeld door een DNS-record te wijzigen of door het IP-adres van de server over te nemen) zonder dat de client dat weet. Alle SSL-opties dragen overhead in de vorm van versleuteling en sleuteluitwisseling, dus er wordt een afweging gemaakt tussen prestaties en beveiliging.

Om adresvervalsing te voorkomen, moet ssl-certificaatverificatie op de client worden gebruikt.

Er zijn veel verbindingsparameters voor het configureren van de client voor SSL. Enkele belangrijke zijn:

  • ssl: Verbinding maken met SSL. Aan deze eigenschap is geen waarde gekoppeld. De aanwezigheid ervan geeft alleen een SSL-verbinding aan. Voor compatibiliteit met toekomstige versies heeft de waarde true de voorkeur. In deze modus valideert het clientstuurprogramma bij het tot stand brengen van een SSL-verbinding de identiteit van de server om man-in-the-middle-aanvallen te voorkomen. Er wordt gecontroleerd of het servercertificaat is ondertekend door een vertrouwde instantie en dat de host waarmee u verbinding maakt, hetzelfde is als de hostnaam in het certificaat.

  • sslmode: Als u versleuteling nodig hebt en de verbinding wilt laten mislukken als deze niet kan worden versleuteld, stelt u deze in sslmode=require. Deze instelling zorgt ervoor dat de server is geconfigureerd voor het accepteren van SSL-verbindingen voor dit host-/IP-adres en dat de server het clientcertificaat herkent. Als de server geen SSL-verbindingen accepteert of het clientcertificaat niet wordt herkend, mislukt de verbinding. De volgende tabel bevat waarden voor deze instelling:

    SSL-modus Uitleg
    disable Versleuteling wordt niet gebruikt.
    allow Versleuteling wordt gebruikt als serverinstellingen deze vereisen of afdwingen.
    prefer Versleuteling wordt gebruikt als serverinstellingen dit toestaan.
    require Versleuteling wordt gebruikt. Het zorgt ervoor dat de server is geconfigureerd voor het accepteren van SSL-verbindingen voor dit host-IP-adres en dat de server het clientcertificaat herkent.
    verify-ca Versleuteling wordt gebruikt. Controleer de handtekening van het servercertificaat op basis van het certificaat dat is opgeslagen op de client.
    verify-full Versleuteling wordt gebruikt. Controleer de handtekening van het servercertificaat en de hostnaam op basis van het certificaat dat is opgeslagen op de client.

    De standaardmodus sslmode die wordt gebruikt, verschilt tussen libpq-clients (zoals psql) en JDBC. De libpq-clients zijn standaard preferingesteld op . JDBC-clients zijn standaard ingesteld op verify-full.

  • sslcert, sslkeyen sslrootcert: Deze parameters kunnen de standaardlocatie van het clientcertificaat, de PKCS-8-clientsleutel en het basiscertificaat overschrijven. Ze zijn standaard ingesteld op /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8respectievelijk , en /defaultdir/root.crt, waar defaultdir zich ${user.home}/.postgresql/ in nix-systemen en %appdata%/postgresql/ in Windows bevindt.

CA's zijn de instellingen die verantwoordelijk zijn voor het uitgeven van certificaten. Een vertrouwde certificeringsinstantie is een entiteit die recht heeft om te controleren of iemand is wie hij of zij zegt. Om dit model te laten werken, moeten alle deelnemers akkoord gaan met een set vertrouwde CA's. Alle besturingssystemen en de meeste webbrowsers worden geleverd met een set vertrouwde CA's.

Het gebruik verify-ca en verify-full sslmode de configuratie-instellingen kunnen ook wel certificaatpinning worden genoemd. In dit geval moeten basis-CA-certificaten op de PostgreSQL-server overeenkomen met de certificaathandtekening en zelfs de hostnaam voor het certificaat op de client.

Mogelijk moet u periodiek op de client opgeslagen certificaten bijwerken wanneer CA's worden gewijzigd of verlopen op PostgreSQL-servercertificaten. Zie Certificaatpinning en Azure-services om te bepalen of u CA's vastmaken.

Zie de PostgreSQL-documentatie voor meer informatie over SSL\TLS-configuratie op de client.

Voor clients die gebruikmaken van en verify-full sslmode configuratie-instellingen (dat wil gezegdverify-ca: certificaatpinning), moeten ze drie basis-CA-certificaten implementeren in de clientcertificaatarchieven:

Basis-CA-certificaten downloaden en toepassingsclients bijwerken in scenario's voor het vastmaken van certificaten

Als u clienttoepassingen wilt bijwerken in scenario's voor het vastmaken van certificaten, kunt u certificaten downloaden:

Als u certificaten wilt importeren in clientcertificaatarchieven, moet u certificaat.crt-bestanden mogelijk converteren naar PEM-indeling nadat u certificaatbestanden van de voorgaande URI's hebt gedownload. U kunt het Hulpprogramma OpenSSL gebruiken om deze bestandsconversies uit te voeren:

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

Informatie over het bijwerken van certificaatarchieven voor clienttoepassingen met nieuwe basis-CA-certificaten wordt beschreven in TLS-certificaten van updateclients voor toepassingsclients.

Belangrijk

Sommige Postgres-clientbibliotheken kunnen tijdens het gebruik van de sslmode=verify-full instelling verbindingsfouten ondervinden met basis-CA-certificaten die kruislings zijn ondertekend met tussenliggende certificaten. Het resultaat is alternatieve vertrouwenspaden. In dit geval wordt u aangeraden de parameter expliciet op te geven sslrootcert . Of stel de PGSSLROOTCERT omgevingsvariabele in op een lokaal pad waar het Basis-CA 2017-basiscertificaat van Microsoft RSA wordt geplaatst, van de standaardwaarde van %APPDATA%\postgresql\root.crt.

Replica's lezen met scenario's voor het vastmaken van certificaten

Met migratie van basis-CA naar Microsoft RSA-basis-CA 2017 is het mogelijk dat nieuwe replica's zich op een nieuwere basis-CA-certificaat bevinden dan de primaire server die eerder is gemaakt. Voor clients die gebruikmaken van verify-ca en verify-full sslmode configuratie-instellingen (d.w.z. certificaatpinning), is het noodzakelijk dat de connectiviteit wordt onderbroken om drie basis-CA-certificaten te accepteren:

Op dit moment biedt Azure Database for PostgreSQL - Flexible Server geen ondersteuning voor verificatie op basis van certificaten.

Clientcertificaten testen door verbinding te maken met psql in scenario's voor het vastmaken van certificaten

U kunt de psql opdrachtregel van uw client gebruiken om de verbinding met de server te testen in scenario's voor het vastmaken van certificaten:


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

Zie de psql-documentatie voor meer informatie over SSL- en certificaatparameters.

TLS/SSL-connectiviteit testen

Voordat u toegang probeert te krijgen tot uw server met SSL vanuit een clienttoepassing, moet u ervoor zorgen dat u deze kunt openen via psql. Als u een SSL-verbinding tot stand hebt gebracht, ziet u uitvoer die vergelijkbaar is met het volgende voorbeeld:

psql (14.5)SSL-verbinding (protocol: TLSv1.2, codering: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compressie: uit)Typ 'help' voor hulp.

U kunt ook de sslinfo-extensie laden en vervolgens de ssl_is_used() functie aanroepen om te bepalen of SSL wordt gebruikt. De functie retourneert t als de verbinding SSL gebruikt. Anders wordt het geretourneerd f.

Coderingssuites

Een suite met coderingsmethoden is een set cryptografische algoritmen. TLS/SSL-protocollen maken gebruik van algoritmen uit een coderingssuite om sleutels te maken en informatie te versleutelen.

Een coderingssuite wordt weergegeven als een lange tekenreeks met schijnbaar willekeurige informatie, maar elk segment van die tekenreeks bevat essentiële informatie. Over het algemeen bevat deze gegevensreeks verschillende belangrijke onderdelen:

  • Protocol (dat wil gezegd TLS 1.2 of TLS 1.3)
  • Algoritme voor sleuteluitwisseling of overeenkomst
  • Algoritme voor digitale handtekening (verificatie)
  • Algoritme voor bulkversleuteling
  • Algoritme voor berichtverificatiecode (MAC)

Verschillende versies van TLS/SSL ondersteunen verschillende coderingssuites. TLS 1.2-coderingssuites kunnen niet worden onderhandeld met TLS 1.3-verbindingen en omgekeerd.

Op dit moment ondersteunt Azure Database for PostgreSQL - Flexible Server veel coderingssuites met de TLS 1.2-protocolversie die in de categorie HIGH:!aNULL vallen.

Problemen met TLS/SSL-connectiviteit oplossen

  1. De eerste stap voor het oplossen van problemen met de compatibiliteit van TLS/SSL-protocolversies is het identificeren van de foutberichten die u of uw gebruikers zien wanneer ze toegang proberen te krijgen tot uw flexibele Azure Database for PostgreSQL-server onder TLS-versleuteling vanaf de client. Afhankelijk van de toepassing en het platform kunnen de foutberichten verschillen. In veel gevallen wijzen ze op het onderliggende probleem.

  2. Als u zeker wilt zijn van compatibiliteit met tls-/SSL-protocollen, controleert u de TLS/SSL-configuratie van de databaseserver en de toepassingsclient om ervoor te zorgen dat deze compatibele versies en coderingssuites ondersteunen.

  3. Analyseer eventuele verschillen of hiaten tussen de databaseserver en de TLS/SSL-versies van de client en coderingssuites van de client. Probeer ze op te lossen door bepaalde opties in of uit te schakelen, software te upgraden of downgraden, of certificaten of sleutels te wijzigen. Mogelijk moet u specifieke TLS/SSL-versies op de server of de client in- of uitschakelen, afhankelijk van de beveiligings- en compatibiliteitsvereisten. U moet bijvoorbeeld TLS 1.0 en TLS 1.1 uitschakelen, die worden beschouwd als niet-beveiligd en afgeschaft, en TLS 1.2 en TLS 1.3 inschakelen, die veiliger en moderner zijn.

  4. Het nieuwste certificaat dat is uitgegeven met Microsoft RSA Root CA 2017, heeft tussenliggend in de keten die is ondertekend door digicert Global Root G2 CA. Sommige postgres-clientbibliotheken kunnen tijdens het gebruik of sslmode=verify-ca de sslmode=verify-full instellingen verbindingsfouten ondervinden met basis-CA-certificaten die kruislings zijn ondertekend met tussenliggende certificaten. Het resultaat is alternatieve vertrouwenspaden.

    Als u deze problemen wilt omzeilen, voegt u alle drie de benodigde certificaten toe aan het certificaatarchief van de client of geeft u de sslrootcert parameter expliciet op. Of stel de PGSSLROOTCERT omgevingsvariabele in op het lokale pad waar het Basis-CA 2017-basiscertificaat van Microsoft RSA wordt geplaatst, van de standaardwaarde van %APPDATA%\postgresql\root.crt.

Gerelateerde inhoud

  • Meer informatie over het maken van een flexibele Azure Database for PostgreSQL-server met behulp van de optie Privétoegang (VNet-integratie) in Azure Portal of de Azure CLI.
  • Meer informatie over het maken van een flexibele Azure Database for PostgreSQL-server met behulp van de optie Openbare toegang (toegestane IP-adressen) in Azure Portal of de Azure CLI.