Connecter des clients avec la sécurité TLS à votre base de données

Les connexions entre vos applications clientes et le serveur de base de données utilisent toujours le chiffrement avec le protocole TLS (Transport Layer Security), précédemment appelé SSL (Secure Sockets Layer).

Azure Database pour PostgreSQL prend en charge les connexions chiffrées à l’aide de TLS 1.2 et 1.3. Le serveur refuse toutes les connexions entrantes qui tentent de chiffrer le trafic à l’aide de TLS 1.0 et TLS 1.1.

Par défaut, le serveur applique une connectivité sécurisée entre le client et le serveur. Pour désactiver cette contrainte et autoriser les communications client chiffrées et non chiffrées, changez le paramètre du serveur de require_secure_transport à OFF. Vous pouvez également définir la version TLS en définissant le paramètre de ssl_max_protocol_version serveur. Ne désactivez pas TLS.

Configuration TLS du client

Par défaut, PostgreSQL ne vérifie pas le certificat de serveur. En raison de ce comportement par défaut, le client ne peut pas détecter si l’identité du serveur est usurpée (par exemple, si quelqu’un modifie un enregistrement DNS ou prend en charge l’adresse IP du serveur). Pour empêcher ce type d’usurpation d’identité, activez la vérification des certificats TLS sur le client.

Vous pouvez configurer de nombreux paramètres de connexion pour la configuration tls du client. Voici quelques éléments importants :

• ssl: Se connecter à l’aide de TLS. Cette propriété n’a pas besoin d’une valeur. Sa présence spécifie une connexion TLS. Pour la compatibilité avec les futures versions, utilisez la valeur true. Dans ce mode, lorsque vous établissez une connexion TLS, le pilote client valide l’identité du serveur pour empêcher les attaques man-in-the-middle.

• sslmode: définissez ce paramètre require si vous avez besoin de chiffrement et souhaitez que la connexion échoue si elle ne peut pas être chiffrée. Ce paramètre garantit que le serveur est configuré pour accepter les connexions TLS pour cet hôte ou cette adresse IP et que le serveur reconnaît le certificat client. Si le serveur n’accepte pas les connexions TLS ou si le certificat client n’est pas reconnu, la connexion échoue. Le tableau suivant répertorie les valeurs de ce paramètre :

  sslmode	Explanation
  disable	Le chiffrement n’est pas utilisé. Azure Database pour PostgreSQL nécessite des connexions TLS. N’utilisez donc pas ce paramètre.
  allow	Le chiffrement est utilisé si les paramètres du serveur l’exigent ou l’appliquent. Azure Database pour PostgreSQL nécessite des connexions TLS. Ce paramètre est donc équivalent à prefer.
  prefer	Le chiffrement est utilisé si les paramètres de serveur l’autorisent. Azure Database pour PostgreSQL nécessite des connexions TLS.
  require	Le chiffrement est utilisé. Il garantit que le serveur est configuré pour accepter les connexions TLS.
  verify-ca	Le chiffrement est utilisé. Vérifiez le certificat de serveur par rapport aux certificats racines approuvés stockés sur le client.
  verify-full	Le chiffrement est utilisé. Vérifiez le certificat de serveur par rapport au certificat stocké sur le client. Il valide également que les certificats de serveur utilisent le même nom d’hôte que la connexion. Utilisez ce paramètre, sauf si les résolveurs DNS privés utilisent un autre nom pour référencer le serveur Azure Database pour PostgreSQL.

Le mode par défaut sslmode diffère entre les clients basés sur libpq (comme PSQL et JDBC). Les clients libpq utilisent par défaut prefer. JDBC clients utilisent par défaut verify-full.

• sslcert, sslkeyet sslrootcert: Ces paramètres remplacent l’emplacement par défaut du certificat client, la clé client PKCS-8 et le certificat racine. Ils sont par défaut /defaultdir/postgresql.crt, /defaultdir/postgresql.pk8et /defaultdir/root.crt, respectivement, où defaultdir se trouve ${user.home}/.postgresql/ dans les systèmes Linux et %appdata%/postgresql/ sur Windows.

Installer les autorités de certification de base approuvées

Télécharger et convertir des certificats CA racine

Pour les clients Windows qui utilisent le magasin de certificats système pour les certificats racine approuvés, aucune action n’est nécessaire, car Windows installe de nouveaux certificats d’autorité de certification racine via Windows Update.

Pour les clients Java, l’extension VS Code et d’autres clients (par exemple, PSQLPerl) qui n’utilisent pas le magasin système et pour les clients sur Linux : vous devez télécharger et combiner les certificats d’autorité de certification racine dans un fichier PEM. Au minimum, incluez les certificats d’autorité de certification racine suivants :

• Microsoft RSA Root CA 2017 (fichier crt)
• DigiCert Global Root G2 (fichier pem)

Incluez tous les certificats d’autorité de certification racine Azure pour réduire la nécessité de futures mises à jour du fichier combiné s’il existe des modifications apportées aux autorités de certification racines utilisées par Azure Database pour PostgreSQL. Vous trouverez la liste des certificats d’autorité de certification racine Azure dans les détails de l’autorité de certification Azure.

Pour importer des certificats dans des magasins de certificats clients, vous devrez peut-être convertir les certificats de format CRT au format PEM et concaténer les fichiers PEM en un seul fichier. Vous pouvez utiliser l’utilitaire OpenSSL X509 pour convertir les fichiers CRT en PEM.

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

Combiner les certificats d’autorité de certification racine dans un seul fichier PEM

Pour certains clients, vous concatènez tous les fichiers PEM en un seul fichier à l’aide d’un éditeur de texte ou d’un outil en ligne de commande.

-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Pour les régions de Chine et pour les clients avec des extensions de rotation :

-----BEGIN CERTIFICATE-----
(Root CA0 content: DigiCertGlobalRootCA.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA1 content: DigiCertGlobalRootG2.crt.pem)
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
(Root CA2 content: Microsoft ECC Root Certificate Authority 2017.crt.pem)
-----END CERTIFICATE-----

Combiner et mettre à jour des certificats d’autorité de certification racine pour les applications Java

Les applications Java personnalisées utilisent un magasin de clés par défaut appelé cacerts, qui contient des certificats d’autorité de certification approuvée. Le cacerts fichier de certificats se trouve dans le répertoire des propriétés de sécurité à l’emplacement java.home\lib\security, où java.home se trouve le répertoire d’environnement d’exécution (répertoire jre du Kit de développement logiciel (SDK) ou le répertoire de niveau supérieur de l’environnement d’exécution Java™ 2. Pour mettre à jour les certificats d’autorité de certification racine du client pour les scénarios d’épinglage de certificats clients avec PostgreSQL, suivez les instructions suivantes :

1. Vérifiez le cacerts magasin de clés Java pour voir s’il contient déjà les certificats requis. Vous pouvez répertorier les certificats dans le magasin de clés Java à l’aide de la commande suivante :

   keytool -list -v -keystore ..\lib\security\cacerts > outputfile.txt
   

   Si les certificats nécessaires ne sont pas présents dans le magasin de clés Java sur le client, car vous pouvez vérifier la sortie, suivez les instructions suivantes :

2. Effectuez une copie de sauvegarde de votre magasin de clés personnalisé.

3. Téléchargez les fichiers de certificat et enregistrez-les localement où vous pouvez les référencer.

4. Générez un ensemble de certificats d'autorité de certification combiné incluant tous les certificats racine nécessaires. L’exemple suivant montre l’utilisation de DefaultJavaSSLFactory pour les utilisateurs Java PostgreSQL.

   keytool -importcert -alias PostgreSQLServerCACert  -file "DigiCertGlobalRootG2.crt.pem" -keystore truststore -storepass password -noprompt
   
   keytool -importcert -alias PostgreSQLServerCACert2  -file "Microsoft ECC Root Certificate Authority 2017.crt.pem" -keystore truststore -storepass password  -noprompt
   
   ...
   

Mettre à jour les certificats d’autorité de certification racine dans Azure App Services

Pour la connexion d’Azure App Services à une instance de serveur flexible Azure Database pour PostgreSQL, deux scénarios possibles existent pour la mise à jour des certificats clients. Les scénarios dépendent de la façon dont vous utilisez SSL avec votre application déployée sur Azure App Services.

• Ajoutez de nouveaux certificats à App Service au niveau de la plateforme avant que les modifications ne se produisent dans votre instance de serveur flexible Azure Database pour PostgreSQL. Si vous utilisez les certificats SSL inclus sur la plateforme App Service dans votre application, aucune action n’est nécessaire. Pour plus d’informations, consultez Ajouter et gérer des certificats TLS/SSL dans Azure App Service dans la documentation Azure App Service.
• Si vous incluez explicitement le chemin d’accès à un fichier de certificat SSL dans votre code, vous devez télécharger le nouveau certificat et mettre à jour le code pour l’utiliser.

Mettre à jour les certificats d’autorité de certification racine lors de l’utilisation de clients dans Azure Kubernetes Service (AKS)

Si vous essayez de vous connecter à Azure Database pour PostgreSQL à l’aide d’applications hébergées dans Azure Kubernetes Services (AKS), il est similaire à l’accès à partir de l’environnement hôte d’un client dédié. Consultez des instructions détaillées dans la documentation AKS.

Mettre à jour les certificats d'autorité de certification racine pour les utilisateurs de .NET (Npgsql) sur Windows

Pour les utilisateurs .NET (Npgsql) sur Windows qui se connectent à des instances de serveur flexible d'Azure Database pour PostgreSQL, vérifiez que tous les certificats de l'autorité de certification racine sont inclus dans le Magasin de certificats Windows sous Autorités de certification racines approuvées. Windows Update gère la liste d’autorité de certification racine Azure standard. Si des certificats répertoriés dans la configuration recommandée ne sont pas inclus, importez les certificats manquants.

Comment utiliser TLS avec la validation de certificat

Certaines infrastructures d’application qui utilisent PostgreSQL pour leurs services de base de données n’activent pas TLS par défaut pendant l’installation. Votre instance Azure Database pour PostgreSQL applique des connexions TLS, mais si l’application n’est pas configurée pour TLS, l’application risque d’échouer. Consultez la documentation de votre application pour savoir comment activer les connexions TLS.

Se connecter à l’aide de PSQL

L’exemple suivant montre comment se connecter à votre serveur à l’aide de l’interface PSQL de ligne de commande. Utilisez le paramètre de chaîne de connexion sslmode=verify-full ou sslmode=verify-ca pour appliquer la vérification des certificats TLS. Passez le chemin d’accès du fichier de certificat local au paramètre sslrootcert.

 psql "sslmode=verify-full sslrootcert=<path-of-pem-file> host=mydemoserver.postgres.database.azure.com dbname=postgres user=myadmin"

Tester la connectivité TLS

Avant d’essayer d’accéder à votre serveur compatible TLS à partir d’une application cliente, assurez-vous que vous pouvez y accéder via PSQL. Si vous avez établi une connexion TLS, vous devez voir une sortie similaire à l’exemple suivant :

psql (14.5)
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.

Vous pouvez également charger l’extension sslinfo , puis appeler la ssl_is_used() fonction pour déterminer si TLS est utilisé. La fonction retourne t si la connexion utilise TLS. Sinon, fest retourné.

Obtenir la liste des certificats approuvés dans le magasin de clés Java par programmation

Par défaut, Java stocke les certificats approuvés dans un fichier spécial nommé cacerts situé dans le dossier d’installation Java sur le client. L’exemple suivant lit cacerts et le charge dans un objet KeyStore :

private KeyStore loadKeyStore() {
    String relativeCacertsPath = "/lib/security/cacerts".replace("/", File.separator);
    String filename = System.getProperty("java.home") + relativeCacertsPath;
    FileInputStream is = new FileInputStream(filename);
    KeyStore keystore = KeyStore.getInstance(KeyStore.getDefaultType());
    String password = "changeit";
    keystore.load(is, password.toCharArray());

    return keystore;
}

Le mot de passe cacerts par défaut est changeit, mais il doit être différent sur un client réel. Les administrateurs recommandent de modifier le mot de passe immédiatement après l’installation de Java. Une fois que vous avez chargé l’objet KeyStore , vous pouvez utiliser la classe PKIXParameters pour lire les certificats présents.

public void whenLoadingCacertsKeyStore_thenCertificatesArePresent() {
    KeyStore keyStore = loadKeyStore();
    PKIXParameters params = new PKIXParameters(keyStore);
    Set<TrustAnchor> trustAnchors = params.getTrustAnchors();
    List<Certificate> certificates = trustAnchors.stream()
      .map(TrustAnchor::getTrustedCert)
      .collect(Collectors.toList());

    assertFalse(certificates.isEmpty());
}

Contenu connexe

• Valider la configuration du client et résoudre les échecs de connexion
• Documentation PostgreSQL