Partager via

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

  • 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 MySQL.

Les demandes d’application à Azure Database pour MySQL doivent être authentifiées. Azure Database pour MySQL 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 MySQL, elle fournit une paire nom d’utilisateur et mot de passe pour se 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 MySQL.

Authentification Microsoft Entra

L’authentification Microsoft Entra est un mécanisme de connexion à Azure Database pour MySQL à l’aide des 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 MySQL pour authentifier les identités au niveau de la base de données.
  • Prise en charge de l’authentification basée sur des jetons pour les applications qui se connectent à Azure Database pour MySQL.

Authentification MySQL

Vous pouvez créer des comptes dans MySQL. 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. Étant donné que ces mots de passe sont stockés dans MySQL, vous devez gérer la rotation des mots de passe par vous-même.

Bien qu’il soit possible de se connecter à Azure Database pour MySQL 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_MYSQL_AD_NON_ADMIN_USERNAME=<YOUR_AZURE_AD_NON_ADMIN_USER_DISPLAY_NAME>
export AZ_MYSQL_AD_MI_USERNAME=<YOUR_AZURE_AD_MI_DISPLAY_NAME>
export AZ_USER_IDENTITY_NAME=<YOUR_USER_ASSIGNED_MANAGEMED_IDENTITY_NAME>
export CURRENT_USERNAME=$(az ad signed-in-user show --query userPrincipalName --output tsv)
export CURRENT_USER_OBJECTID=$(az ad signed-in-user show --query id --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 MySQL, qui doit être unique dans 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_AZURE_AD_MI_DISPLAY_NAME>: nom complet de l’utilisateur Microsoft Entra pour votre identité managée. Vérifiez que le nom est un utilisateur valide dans votre locataire Microsoft Entra.
  • <YOUR_USER_ASSIGNED_MANAGEMED_IDENTITY_NAME>: nom de votre serveur d’identité managée affectée par l’utilisateur, qui doit être unique dans Azure.

1) Configurer Azure Database pour MySQL

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 MySQL, 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.

Si vous utilisez Azure CLI, exécutez la commande suivante pour vous assurer de disposer d’une autorisation suffisante :

az login --scope https://graph.microsoft.com/.default

Exécutez la commande suivante pour créer une identité utilisateur pour l’affectation :

az identity create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_USER_IDENTITY_NAME

Important

Après avoir créé l’identité affectée par l’utilisateur, demandez à votre Administrateur général ou Administrateur de rôle privilégié d’accorder les autorisations suivantes pour cette identité : User.Read.All, GroupMember.Read.All et Application.Read.ALL. Pour plus d’informations, consultez la section Autorisations d’Authentification Active Directory.

Exécutez la commande suivante pour affecter l’identité au serveur MySQL pour créer l’administrateur Microsoft Entra :

az mysql flexible-server identity assign \
    --resource-group $AZ_RESOURCE_GROUP \
    --server-name $AZ_DATABASE_SERVER_NAME \
    --identity $AZ_USER_IDENTITY_NAME

Exécutez ensuite la commande suivante pour définir l’administrateur Microsoft Entra :

az mysql flexible-server ad-admin create \
    --resource-group $AZ_RESOURCE_GROUP \
    --server-name $AZ_DATABASE_SERVER_NAME \
    --display-name $CURRENT_USERNAME \
    --object-id $CURRENT_USER_OBJECTID \
    --identity $AZ_USER_IDENTITY_NAME

Cette commande définit l’administrateur Microsoft Entra sur l’utilisateur connecté actuel.

Remarque

Vous ne pouvez créer qu’un seul administrateur Microsoft Entra par serveur MySQL. La sélection d’un autre remplacera l’administrateur Microsoft Entra existant configuré pour le serveur.

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

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

Les instances Azure Database pour MySQL sont sécurisées par défaut. Elles ont un pare-feu qui n’autorise aucune connexion entrante.

Vous pouvez ignorer cette étape si vous utilisez Bash, car la commande flexible-server create a déjà détecté votre adresse IP locale et l’a définie sur le serveur MySQL.

Si vous vous connectez à votre serveur MySQL à 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 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 mysql server firewall-rule create \
    --resource-group $AZ_RESOURCE_GROUP \
    --name $AZ_DATABASE_SERVER_NAME-database-allow-local-ip-wsl \
    --server $AZ_DATABASE_SERVER_NAME \
    --start-ip-address $AZ_WSL_IP_ADDRESS \
    --end-ip-address $AZ_WSL_IP_ADDRESS \
    --output tsv

2.2) Créer un utilisateur non administrateur MySQL 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.sql pour créer un utilisateur non administrateur. Ajoutez le contenu suivant et enregistrez-le localement :

export AZ_MYSQL_AD_NON_ADMIN_USERID=$(az ad signed-in-user show --query id --output tsv)

cat << EOF > create_ad_user.sql
SET aad_auth_validate_oids_in_tenant = OFF;
CREATE AADUSER '$AZ_MYSQL_AD_NON_ADMIN_USERNAME' IDENTIFIED BY '$AZ_MYSQL_AD_NON_ADMIN_USERID';
GRANT ALL PRIVILEGES ON $AZ_DATABASE_NAME.* TO '$AZ_MYSQL_AD_NON_ADMIN_USERNAME'@'%';
FLUSH privileges;
EOF

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

mysql -h $AZ_DATABASE_SERVER_NAME.mysql.database.azure.com --user $CURRENT_USERNAME --enable-cleartext-plugin --password=$(az account get-access-token --resource-type oss-rdbms --output tsv --query accessToken) < create_ad_user.sql

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

rm create_ad_user.sql

Remarque

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

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 MySQL. 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 MySQL dans l’URL JDBC. Identifiez les emplacements de votre code qui créent actuellement une java.sql.Connection connexion à Azure Database pour MySQL. Mettez à jour url et dans votre fichier application.properties pour qu’il corresponde user aux valeurs suivantes :

    url=jdbc:mysql://$AZ_DATABASE_SERVER_NAME.mysql.database.azure.com:3306/$AZ_DATABASE_NAME?serverTimezone=UTC&sslMode=REQUIRED&defaultAuthenticationPlugin=com.azure.identity.extensions.jdbc.mysql.AzureMysqlAuthenticationPlugin&authenticationPlugins=com.azure.identity.extensions.jdbc.mysql.AzureMysqlAuthenticationPlugin
user=$AZ_MYSQL_AD_NON_ADMIN_USERNAME

    Remarque

    Si vous utilisez la MysqlConnectionPoolDataSource classe comme source de données dans votre application, veillez à supprimer defaultAuthenticationPlugin=com.azure.identity.extensions.jdbc.mysql.AzureMysqlAuthenticationPlugin de l’URL.

    url=jdbc:mysql://$AZ_DATABASE_SERVER_NAME.mysql.database.azure.com:3306/$AZ_DATABASE_NAME?serverTimezone=UTC&sslMode=REQUIRED&authenticationPlugins=com.azure.identity.extensions.jdbc.mysql.AzureMysqlAuthenticationPlugin
user=$AZ_MYSQL_AD_NON_ADMIN_USERNAME

  3. Remplacez la variable, $AZ_DATABASE_SERVER_NAME une $AZ_DATABASE_NAME variable et une $AZ_MYSQL_AD_NON_ADMIN_USERNAME variable par les valeurs que vous avez configurées au début de cet article.

  4. Supprimez l’URL password JDBC.

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 MySQL.

Ces étapes créent un utilisateur Microsoft Entra pour l’identité managée et lui accordent toutes les autorisations pour la base de données $AZ_DATABASE_NAME . Vous pouvez modifier le nom $AZ_DATABASE_NAME de la base de données en fonction de vos besoins.

Tout d’abord, créez un script SQL appelé create_ad_user.sql pour créer un utilisateur non administrateur. Ajoutez le contenu suivant et enregistrez-le localement :

export AZ_MYSQL_AD_MI_USERID=$(az ad sp show --id $AZ_MI_OBJECT_ID --query appId --output tsv)

cat << EOF > create_ad_user.sql
SET aad_auth_validate_oids_in_tenant = OFF;
CREATE AADUSER '$AZ_MYSQL_AD_MI_USERNAME' IDENTIFIED BY '$AZ_MYSQL_AD_MI_USERID';
GRANT ALL PRIVILEGES ON $AZ_DATABASE_NAME.* TO '$AZ_MYSQL_AD_MI_USERNAME'@'%';
FLUSH privileges;
EOF

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

mysql -h $AZ_DATABASE_SERVER_NAME.mysql.database.azure.com --user $CURRENT_USERNAME --enable-cleartext-plugin --password=$(az account get-access-token --resource-type oss-rdbms --output tsv --query accessToken) < create_ad_user.sql

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

rm create_ad_user.sql

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 à MySQL à 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 :

properties.put("user", "$AZ_MYSQL_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 MySQL 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 :