Se connecter à PostgreSQL

  • 10 minutes

L’établissement de connexions sécurisées à Azure Database pour PostgreSQL nécessite la compréhension des composants de chaîne de connexion, des options d’authentification et de la configuration de la sécurité de la couche de transport. Pour les applications IA qui lisent et écrivent fréquemment des données, l’obtention de la configuration de la connexion dès le début empêche les défaillances d’authentification et les vulnérabilités de sécurité en production.

Notions de base de la connexion

Les connexions PostgreSQL nécessitent plusieurs paramètres qui identifient le serveur, la base de données et les informations d’identification utilisateur. Azure Database pour PostgreSQL utilise un format de point de terminaison spécifique et applique le transport sécurisé par défaut.

Votre point de terminaison de serveur suit le modèle <server-name>.postgres.database.azure.com, où <server-name> est le nom unique que vous avez spécifié lors de la création du serveur. Le nom de domaine complet (FQDN) se résout en l'adresse IP publique du serveur lors de l'utilisation d'un accès public, ou en une adresse IP privée lors de l'intégration au réseau virtuel.

Une connexion PostgreSQL nécessite ces paramètres principaux : l’hôte (nom de domaine complet du serveur), le port (5432 pour les connexions directes ou 6432 pour PgBouncer), le nom de la base de données, le nom d’utilisateur (pour Entra auth, utiliser username@servername le format), le mot de passe (jeton statique ou Entra) et le mode SSL. Différentes bibliothèques clientes et outils acceptent ces paramètres dans différents formats, notamment les chaînes de connexion, les paires mot clé-valeur ou les paramètres individuels.

Méthodes d’authentification

Azure Database pour PostgreSQL prend en charge deux approches d’authentification : l’authentification Microsoft Entra offre une sécurité renforcée via un accès basé sur les jetons, tandis que l’authentification native PostgreSQL utilise des informations d’identification de nom d’utilisateur et de mot de passe traditionnelles.

L’authentification Microsoft Entra utilise des jetons OAuth 2.0 plutôt que des mots de passe. Cette approche s’intègre à la plateforme d’identités d’Azure et fournit une gestion centralisée des identités, élimine le stockage par mot de passe (les jetons sont de courte durée), prend en charge les identités managées pour les applications hébergées par Azure et crée des pistes d’audit dans les journaux de connexion Entra. Pour utiliser l’authentification Entra, configurez un administrateur Microsoft Entra sur votre serveur (un compte d’utilisateur, un groupe ou un principal de service). Une fois configurées, les identités Entra se connectent en obtenant un jeton à partir de la https://ossrdbms-aad.database.windows.net ressource.

Le processus de connexion fonctionne comme suit :

  1. Votre application demande un jeton d’accès à partir de Microsoft Entra ID.
  2. Entra valide l’identité et retourne un jeton.
  3. Votre application se connecte à PostgreSQL à l’aide du jeton comme mot de passe.
  4. PostgreSQL valide le jeton par rapport à l’administrateur Entra configuré.

En Python, vous pouvez utiliser la azure-identity bibliothèque pour obtenir des jetons :

from azure.identity import DefaultAzureCredential

credential = DefaultAzureCredential()
token = credential.get_token("https://ossrdbms-aad.database.windows.net/.default")
# Use token.token as the password in your connection string

La DefaultAzureCredential classe tente automatiquement plusieurs méthodes d’authentification, notamment l’identité managée (lors de l’exécution sur Azure), les informations d’identification Azure CLI (pour le développement local) et d’autres options.

L’authentification native PostgreSQL stocke les noms d’utilisateur et les mots de passe chiffrés dans la base de données. Cette approche est appropriée lorsque les applications ne peuvent pas utiliser l’authentification Entra (applications héritées), vous devez accorder l’accès aux identités en dehors de votre locataire Entra, ou si vous êtes en cours d’exécution dans un environnement sans connectivité Azure pendant le développement. Lorsque vous utilisez l’authentification PostgreSQL, stockez les mots de passe dans Azure Key Vault plutôt que la configuration de l’application, faites pivoter régulièrement les mots de passe, utilisez des mots de passe générés de manière aléatoire forte et limitez les autorisations de chaque utilisateur de base de données. Le nom d’utilisateur administrateur et le mot de passe que vous spécifiez lors de la création du serveur utilisent l’authentification PostgreSQL.

Configuration TLS/SSL

Azure Database pour PostgreSQL chiffre toutes les connexions à l’aide du protocole TLS (Transport Layer Security). Le serveur requiert TLS par défaut et prend en charge TLS 1.2 et 1.3. Les connexions utilisant des versions TLS antérieures sont rejetées.

Les clients PostgreSQL utilisent le paramètre pour contrôler le sslmode chiffrement et la validation des certificats. Les modes disponibles sont les suivants :

  • Désactiver: Aucun chiffrement. Azure rejette les connexions à l’aide de ce mode.
  • Permettre: Chiffre si le serveur l’exige, mais ne valide pas les certificats.
  • Préfère: Chiffre si le serveur le prend en charge, mais ne valide pas les certificats.
  • Exigent: Applique le chiffrement, mais ne valide pas les certificats.
  • verify-ca : Applique le chiffrement et valide le certificat de serveur auprès des autorités de certification approuvées.
  • verify-full : Applique le chiffrement, valide l’autorité de certification et confirme que le nom d’hôte du certificat correspond au serveur.

Pour les applications de production, utilisez cette option verify-full pour vous assurer que vous vous connectez au serveur Azure PostgreSQL authentique. Ce mode valide que le serveur présente un certificat signé par une autorité de certification approuvée, et que le nom commun ou le nom d’objet du certificat correspond au nom d’hôte du serveur.

Les modes verify-ca et verify-full nécessitent que votre client ait accès aux certificats d’autorité de certification racine qui ont signé le certificat du serveur. La plupart des systèmes d’exploitation et des environnements d’hébergement Azure incluent les autorités de certification racines DigiCert et Microsoft qu’Azure Database pour PostgreSQL utilise déjà. Si la validation de certificat échoue, vous devrez peut-être télécharger les certificats racines à partir du référentiel PKI de Microsoft et configurer votre client pour les utiliser.

Regroupement de connexions avec PgBouncer

Azure Database pour PostgreSQL inclut PgBouncer intégré, que vous pouvez activer via les paramètres de configuration du serveur dans le portail Azure ou à l’aide d’Azure CLI. Une fois activé, connectez-vous sur le port 6432 au lieu de 5432.

Important

PgBouncer est disponible uniquement sur les niveaux de calcul Usage Général et Mémoire Optimisée. Si votre serveur utilise le niveau Burstable, vous ne pouvez pas activer PgBouncer intégré.

PgBouncer gère un pool de connexions au serveur de base de données et multiplexe les connexions clientes sur ce pool. Cela réduit la surcharge liée à l’établissement de connexions, qui est utile pour les applications qui établissent de nombreuses connexions à courte durée.

Pour activer PgBouncer à l’aide d’Azure CLI :

az postgres flexible-server parameter set \
    --resource-group myResourceGroup \
    --server-name myserver \
    --name pgbouncer.enabled \
    --value true

Après l’activation, mettez à jour votre chaîne de connexion pour utiliser le port 6432 :

postgresql://user@myserver.postgres.database.azure.com:6432/mydb?sslmode=require

Les stratégies d’optimisation du regroupement de connexions, notamment le dimensionnement et la transaction du pool et les modes de session, sont abordées dans le module « Optimiser les performances, l’indexation et la mise à l’échelle ».

Considérations relatives à l’accès réseau

Azure Database pour PostgreSQL prend en charge deux modèles de mise en réseau : un accès public avec des règles de pare-feu et un accès privé avec l’intégration au réseau virtuel. Votre équipe de plateforme ou d’exploitation configure généralement ces paramètres, mais la compréhension de ces paramètres vous aide à résoudre les problèmes de connexion.

Avec l’accès public, le serveur dispose d’une adresse IP publique et de règles de pare-feu qui contrôlent les adresses IP clientes pouvant se connecter. Si vous ne pouvez pas vous connecter à partir de votre ordinateur de développement, vérifiez que votre adresse IP est autorisée dans les règles de pare-feu.

Avec un accès privé, le serveur n’a qu’une adresse IP privée au sein d’un réseau virtuel Azure. Vous pouvez uniquement vous connecter à partir de ressources au sein du même réseau virtuel, des réseaux appairés ou via VPN/ExpressRoute. L’accès privé est courant dans les environnements de production où l’isolation réseau est requise.

Exemples de chaîne de connexion

Les exemples suivants montrent des modèles de chaîne de connexion courants pour Azure Database pour PostgreSQL.

# Basic connection with SSL required
postgresql://myuser:mypassword@myserver.postgres.database.azure.com/mydb?sslmode=require

# Connection with certificate verification
postgresql://myuser:mypassword@myserver.postgres.database.azure.com/mydb?sslmode=verify-full&sslrootcert=/etc/ssl/certs/ca-certificates.crt

# Connection through PgBouncer (note port 6432)
postgresql://myuser:mypassword@myserver.postgres.database.azure.com:6432/mydb?sslmode=require

Ressources supplémentaires