Partager via

Migrer une application pour utiliser des connexions sans mot de passe avec Azure Database pour PostgreSQL

  • Article

Cet article explique comment migrer des méthodes d’authentification traditionnelles vers des connexions sans mot de passe plus sécurisées avec Azure Database pour PostgreSQL.

Les demandes d’application à Azure Database pour PostgreSQL doivent être authentifiées. Azure Database pour PostgreSQL fournit plusieurs façons différentes pour les applications de se connecter en toute sécurité. L’une des façons d’utiliser des mots de passe. Toutefois, vous devez hiérarchiser les connexions sans mot de passe dans vos applications lorsque cela est possible.

Comparer les options d’authentification

Lorsque l’application s’authentifie avec Azure Database pour PostgreSQL, elle fournit une paire nom d’utilisateur et mot de passe pour connecter la base de données. Selon l’emplacement de stockage des identités, il existe deux types d’authentification : l’authentification Microsoft Entra et l’authentification PostgreSQL.

Authentification Microsoft Entra

L’authentification Microsoft Entra est un mécanisme de connexion à Azure Database pour PostgreSQL utilisant les identités définies dans Microsoft Entra ID. Avec l’authentification Microsoft Entra, vous pouvez gérer les identités des utilisateurs de base de données et d’autres services Microsoft dans un emplacement centralisé, ce qui simplifie la gestion des autorisations.

L’utilisation de l’ID Microsoft Entra pour l’authentification offre les avantages suivants :

  • Authentification des utilisateurs dans les services Azure de manière uniforme.
  • Gestion des stratégies de mot de passe et de la rotation de mot de passe dans un emplacement unique.
  • Plusieurs formes d’authentification prises en charge par l’ID Microsoft Entra, qui peuvent éliminer la nécessité de stocker les mots de passe.
  • Les clients peuvent gérer les autorisations de base de données à l’aide de groupes externes (Microsoft Entra ID).
  • L’authentification Microsoft Entra utilise les utilisateurs de base de données PostgreSQL pour authentifier les identités au niveau de la base de données.
  • Prise en charge de l’authentification basée sur les jetons pour les applications qui se connectent à Azure Database pour PostgreSQL.

Authentification PostgreSQL

Vous pouvez créer des comptes dans PostgreSQL. Si vous choisissez d’utiliser des mots de passe comme informations d’identification pour les comptes, ces informations d’identification sont stockées dans la table user. Comme ces mots de passe sont stockés dans PostgreSQL, vous devez gérer vous-même la rotation des mots de passe.

Bien qu’il soit possible de se connecter à Azure Database pour PostgreSQL avec des mots de passe, vous devez les utiliser avec précaution. Vous devez être vigilant pour ne jamais exposer les mots de passe dans un emplacement non sécurisé. Toute personne qui accède aux mots de passe est en mesure de s’authentifier. Par exemple, il existe un risque qu’un utilisateur malveillant puisse accéder à l’application si un chaîne de connexion est accidentellement archivé dans le contrôle de code source, envoyé via un e-mail non sécurisé, collé dans une conversation incorrecte ou consulté par une personne qui ne doit pas avoir d’autorisation. Au lieu de cela, envisagez de mettre à jour votre application pour utiliser des connexions sans mot de passe.

Présentation des connexions sans mot de passe

Avec une connexion sans mot de passe, vous pouvez vous connecter aux services Azure sans stocker d’informations d’identification dans le code de l’application, ses fichiers de configuration ou dans les variables d’environnement.

De nombreux services Azure prennent en charge les connexions sans mot de passe, par exemple via Azure Managed Identity. Ces techniques fournissent des fonctionnalités de sécurité robustes que vous pouvez implémenter à l’aide de DefaultAzureCredential à partir des bibliothèques clientes Azure Identity. Dans ce tutoriel, vous allez apprendre à mettre à jour une application existante à utiliser DefaultAzureCredential au lieu d’alternatives telles que des chaîne de connexion.

DefaultAzureCredential prend en charge plusieurs méthodes d’authentification et détermine automatiquement celle qui doit être utilisée au moment de l’exécution. Cette approche permet à votre application d’utiliser différentes méthodes d’authentification dans différents environnements (développement local et production) sans implémenter de code spécifique à l’environnement.

L’ordre et les emplacements dans lesquels DefaultAzureCredential les recherches d’informations d’identification sont disponibles dans la vue d’ensemble de la bibliothèque d’identités Azure. Par exemple, lorsque vous travaillez localement, DefaultAzureCredential s’authentifie généralement à l’aide du compte utilisé par le développeur pour se connecter à Visual Studio. Lorsque l’application est déployée sur Azure, DefaultAzureCredential bascule automatiquement pour utiliser une identité managée. Aucune modification du code n’est requise pour cette transition.

Pour vous assurer que les connexions sont sans mot de passe, vous devez prendre en compte le développement local et l’environnement de production. Si une chaîne de connexion est requise à l’un ou l’autre endroit, l’application n’est pas sans mot de passe.

Dans votre environnement de développement local, vous pouvez vous authentifier auprès d’Azure CLI, d’Azure PowerShell, de Visual Studio ou de plug-ins Azure pour Visual Studio Code ou IntelliJ. Dans ce cas, vous pouvez utiliser ces informations d’identification dans votre application au lieu de configurer des propriétés.

Lorsque vous déployez des applications dans un environnement d’hébergement Azure, tel qu’une machine virtuelle, vous pouvez affecter une identité managée dans cet environnement. Ensuite, vous n’avez pas besoin de fournir des informations d’identification pour vous connecter aux services Azure.

Remarque

Une identité managée fournit une identité de sécurité pour représenter une application ou un service. Managée par la plateforme Azure, l’identité ne nécessite pas que vous approvisionniez ou permutiez de secrets. Vous pouvez en savoir plus sur les identités managées dans la documentation vue d’ensemble .

Migrer une application existante pour utiliser des connexions sans mot de passe

Les étapes suivantes expliquent comment migrer une application existante pour utiliser des connexions sans mot de passe au lieu d’une solution basée sur un mot de passe.

0) Préparer l’environnement de travail

Tout d’abord, utilisez la commande suivante pour configurer certaines variables d’environnement.

export AZ_RESOURCE_GROUP=<YOUR_RESOURCE_GROUP>
export AZ_DATABASE_SERVER_NAME=<YOUR_DATABASE_SERVER_NAME>
export AZ_DATABASE_NAME=demo
export AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME=<YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>
export AZ_LOCAL_IP_ADDRESS=<YOUR_LOCAL_IP_ADDRESS>
export CURRENT_USERNAME=$(az ad signed-in-user show --query userPrincipalName --output tsv)

Remplacez les espaces réservés par les valeurs suivantes, qui sont utilisées dans cet article :

  • <YOUR_RESOURCE_GROUP>: nom du groupe de ressources dans lequel se trouvent vos ressources.
  • <YOUR_DATABASE_SERVER_NAME>: nom de votre serveur PostgreSQL. Il doit être unique dans tout Azure.
  • <YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>: nom complet de votre utilisateur non administrateur Microsoft Entra. Vérifiez que le nom est un utilisateur valide dans votre locataire Microsoft Entra.
  • <YOUR_LOCAL_IP_ADDRESS>: adresse IP de votre ordinateur local, à partir duquel vous exécuterez l’application Spring Boot. Un moyen pratique de le trouver est d’ouvrir whatismyip.akamai.com.

1) Configurer Azure Database pour PostgreSQL

1.1) Activer l’authentification basée sur l’ID Microsoft Entra

Pour utiliser l’accès à l’ID Microsoft Entra avec Azure Database pour PostgreSQL, vous devez d’abord définir l’utilisateur administrateur Microsoft Entra. Seuls les utilisateurs administrateurs Microsoft Entra peuvent créer ou activer des utilisateurs pour l’authentification basée sur Microsoft Entra ID.

Pour configurer un administrateur Microsoft Entra après avoir créé le serveur, suivez les étapes décrites dans Gérer les rôles Microsoft Entra dans Azure Database pour PostgreSQL – Serveur flexible.

Remarque

Le serveur flexible PostgreSQL peut créer plusieurs administrateurs Microsoft Entra.

2) Configurer Azure Database pour PostgreSQL pour le développement local

2.1) Configurer une règle de pare-feu pour l’adresse IP locale

Les instances Azure Database pour PostgreSQL sont sécurisées par défaut. Elles ont un pare-feu qui n’autorise aucune connexion entrante. Pour pouvoir utiliser notre base de données, vous devez ajouter une règle de pare-feu qui permet à l’adresse IP locale d’accéder au serveur de base de données.

Comme vous avez configuré votre adresse IP locale au début de cet article, vous pouvez ouvrir le pare-feu du serveur en exécutant la commande suivante :

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_LOCAL_IP_ADDRESS \
    --end-ip-address $AZ_LOCAL_IP_ADDRESS \
    --output tsv

Si vous vous connectez à votre serveur PostgreSQL à partir de Sous-système Windows pour Linux (WSL) sur un ordinateur Windows, vous devez ajouter l’ID d’hôte WSL à votre pare-feu.

Obtenez l’adresse IP de votre ordinateur hôte en exécutant la commande suivante dans WSL :

cat /etc/resolv.conf

Copiez l’adresse IP suivant le terme nameserver, puis utilisez la commande suivante pour définir une variable d’environnement pour l’adresse IP de WSL :

export AZ_WSL_IP_ADDRESS=<the-copied-IP-address>

Ensuite, utilisez la commande suivante pour ouvrir le pare-feu du serveur sur votre application WSL :

az postgres flexible-server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME \
    --rule-name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip \
    --start-ip-address $AZ_WSL_IP_ADDRESS \
    --end-ip-address $AZ_WSL_IP_ADDRESS \
    --output tsv

2.2) Créer un utilisateur non administrateur PostgreSQL et accorder une autorisation

Ensuite, créez un utilisateur Microsoft Entra non administrateur et accordez-lui toutes les autorisations sur la $AZ_DATABASE_NAME base de données. Vous pouvez modifier le nom $AZ_DATABASE_NAME de la base de données en fonction de vos besoins.

Créez un script SQL appelé create_ad_user_local.sql pour créer un utilisateur non administrateur. Ajoutez le contenu suivant et enregistrez-le localement :

cat << EOF > create_ad_user_local.sql
select * from pgaadauth_create_principal('$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME', false, false);
EOF

Utilisez ensuite la commande suivante pour exécuter le script SQL pour créer l’utilisateur non administrateur Microsoft Entra :

psql "host=$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com user=$CURRENT_USERNAME dbname=postgres port=5432 password=$(az account get-access-token --resource-type oss-rdbms --output tsv --query accessToken) sslmode=require" < create_ad_user_local.sql

Utilisez maintenant la commande suivante pour supprimer le fichier de script SQL temporaire :

rm create_ad_user_local.sql

Remarque

Vous pouvez lire des informations plus détaillées sur la création d’utilisateurs PostgreSQL dans Créer des utilisateurs dans Azure Database pour PostgreSQL.

3) Connectez-vous et migrez le code de l’application pour utiliser des connexions sans mot de passe

Pour le développement local, vérifiez que vous êtes authentifié avec le même compte Microsoft Entra auquel vous avez affecté le rôle sur votre PostgreSQL. Vous pouvez vous authentifier via Azure CLI, Visual Studio, Azure PowerShell ou d’autres outils tels qu’IntelliJ.

Connectez-vous à Azure via Azure CLI à l’aide de la commande suivante :

az login

Ensuite, procédez comme suit pour mettre à jour votre code pour utiliser des connexions sans mot de passe. Bien que conceptuellement similaire, chaque langage utilise des détails d’implémentation différents.

  1. Dans votre projet, ajoutez la référence suivante au azure-identity-extensions package. Cette bibliothèque contient toutes les entités nécessaires pour implémenter des connexions sans mot de passe.

    <dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-identity-extensions</artifactId>
    <version>1.0.0</version>
</dependency>

  2. Activez le plug-in d’authentification Azure PostgreSQL dans l’URL JDBC. Identifiez les emplacements de votre code qui créent actuellement une java.sql.Connection connexion à Azure Database pour PostgreSQL. Mettez à jour url et dans votre fichier application.properties pour qu’il corresponde user aux valeurs suivantes :

    url=jdbc:postgresql://$AZ_DATABASE_SERVER_NAME.postgres.database.azure.com:5432/$AZ_DATABASE_NAME?sslmode=require&authenticationPluginClassName=com.azure.identity.extensions.jdbc.postgresql.AzurePostgresqlAuthenticationPlugin
user=$AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME

  3. Remplacez les $AZ_POSTGRESQL_AD_NON_ADMIN_USERNAME deux $AZ_DATABASE_SERVER_NAME variables par la valeur que vous avez configurée au début de cet article.

Exécutez l’application localement.

Après avoir apporté ces modifications de code, exécutez votre application localement. La nouvelle configuration doit récupérer vos informations d’identification locales si vous êtes connecté à un outil en ligne de commande ou IDE compatible, tel qu’Azure CLI, Visual Studio ou IntelliJ. Les rôles que vous avez attribués à votre utilisateur de développement local dans Azure permettent à votre application de se connecter au service Azure localement.

4) Configurer l’environnement d’hébergement Azure

Une fois que votre application est configurée pour utiliser des connexions sans mot de passe et qu’elle s’exécute localement, le même code peut s’authentifier auprès des services Azure après son déploiement sur Azure. Par exemple, une application déployée sur une instance Azure App Service qui a une identité managée affectée peut se connecter à Stockage Azure.

Dans cette section, vous allez exécuter deux étapes pour permettre à votre application de s’exécuter dans un environnement d’hébergement Azure de manière sans mot de passe :

  • Attribuez l’identité managée pour votre environnement d’hébergement Azure.
  • Attribuez des rôles à l’identité managée.

Remarque

Azure fournit également Service Connector, qui peut vous aider à connecter votre service d’hébergement à PostgreSQL. Avec Service Connector pour configurer votre environnement d’hébergement, vous pouvez omettre l’étape d’attribution de rôles à votre identité managée, car Service Connector le fera pour vous. La section suivante explique comment configurer votre environnement d’hébergement Azure de deux façons : une via Service Connector et l’autre en configurant directement chaque environnement d’hébergement.

Important

Les commandes de Service Connector nécessitent Azure CLI 2.41.0 ou version ultérieure.

Attribuer l’identité managée à l’aide du Portail Azure

Les étapes suivantes vous montrent comment attribuer une identité managée affectée par le système pour différents services d’hébergement web. L’identité managée peut se connecter en toute sécurité à d’autres services Azure à l’aide des configurations d’application que vous avez configurées.

  1. Dans la page de vue d’ensemble principale de votre instance Azure App Service, sélectionnez Identité dans le volet de navigation.

  2. Sous l’onglet Affecté par le système, veillez à définir le champ État sur activé. Une identité affectée par le système est gérée par Azure en interne et gère les tâches d’administration pour vous. Les détails et ID de l’identité ne sont jamais exposés dans votre code.

Vous pouvez également affecter une identité managée sur un environnement d’hébergement Azure à l’aide d’Azure CLI.

Vous pouvez affecter une identité managée à une instance Azure App Service avec la commande az webapp identity assign, comme illustré dans l’exemple suivant :

export AZ_MI_OBJECT_ID=$(az webapp identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <service-instance-name> \
    --query principalId \
    --output tsv)

Attribuer des rôles à l’identité managée

Ensuite, accordez des autorisations à l’identité managée que vous avez affectée pour accéder à votre instance PostgreSQL.

Si vous avez connecté vos services à l’aide de Service Connector, les commandes de l’étape précédente ont déjà attribué le rôle. Vous pouvez donc ignorer cette étape.

Tester l'application

Avant de déployer l’application dans l’environnement d’hébergement, vous devez apporter une modification supplémentaire au code, car l’application va se connecter à PostgreSQL à l’aide de l’utilisateur créé pour l’identité managée.

Mettez à jour votre code pour utiliser l’utilisateur créé pour l’identité managée :

Remarque

Si vous avez utilisé la commande Service Connector, ignorez cette étape.

properties.put("user", "$AZ_POSTGRESQL_AD_MI_USERNAME");

Après avoir apporté ces modifications de code, vous pouvez générer et redéployer l’application. Ensuite, accédez à votre application hébergée dans le navigateur. Votre application doit être en mesure de se connecter à la base de données PostgreSQL avec succès. N’oubliez pas qu’il peut falloir plusieurs minutes pour que les attributions de rôle se propagent dans l’environnement Azure. Votre application est désormais configurée pour s’exécuter localement et dans un environnement de production sans que les développeurs n’aient à gérer les secrets dans l’application elle-même.

Étapes suivantes

Dans ce didacticiel, vous avez appris à migrer une application vers des connexions sans mot de passe.

Vous pouvez lire les ressources suivantes pour explorer les concepts abordés dans cet article plus en détails :