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

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

Les requêtes des applications adressées à Azure SQL Database doivent être authentifiées. Azure SQL Database 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 auprès d’Azure SQL Database, elle fournit une paire de nom d’utilisateur et de 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 Azure SQL Database.

Authentification Microsoft Entra

L’authentification Microsoft Entra est un mécanisme de connexion à Azure SQL Database à l’aide d’identités définies dans l’ID Microsoft Entra. 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 Azure SQL 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 SQL Database.

Authentification Azure SQL Database

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

Bien qu’il soit possible de se connecter à Azure SQL Database 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 .

Remarque

Étant donné que le pilote JDBC pour Azure SQL Database ne prend pas encore en charge les connexions sans mot de passe à partir d’environnements locaux, cet article se concentre uniquement sur les applications déployées dans des environnements d’hébergement Azure et sur la façon de les migrer pour utiliser des connexions sans mot de passe.

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 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 Azure SQL Database. Il doit être unique dans tout Azure.

1) Configurer Azure SQL Database

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

Pour utiliser l’accès à l’ID Microsoft Entra avec Azure SQL Database, 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 ensuite la commande suivante pour définir l’administrateur Microsoft Entra :

az sql server ad-admin create \
    --resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --display-name $CURRENT_USERNAME \
    --object-id $CURRENT_USER_OBJECTID

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 Azure SQL Database. La sélection d’un autre remplacera l’administrateur Microsoft Entra existant configuré pour le serveur.

2) Migrer le code de l’application pour utiliser des connexions sans mot de passe

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.

Java

1. Dans votre projet, ajoutez la référence suivante au azure-identity 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</artifactId>
        <version>1.5.4</version>
   </dependency>
   

2. Activez l’authentification d’identité managée Microsoft Entra dans JDBC URL.v Identifier les emplacements de votre code qui créent actuellement une java.sql.Connection connexion à Azure SQL Database. Mettez à jour votre code pour le faire correspondre à l’exemple suivant :

   String url = "jdbc:sqlserver://$AZ_DATABASE_SERVER_NAME.database.windows.net:1433;databaseName=$AZ_DATABASE_NAME;authentication=ActiveDirectoryMSI;"   
   Connection con = DriverManager.getConnection(url);
   

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

4. Supprimez l’URL user JDBC et password la supprimez.

Spring

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

   <dependency>
       <groupId>com.azure.spring</groupId>
       <artifactId>spring-cloud-azure-starter</artifactId>
   </dependency>
   

   Remarque

   Pour plus d’informations sur la gestion des versions de bibliothèque Spring Cloud Azure à l’aide d’une facture de documents (BOM), consultez la section Prise en main du guide du développeur Azure Spring Cloud.

2. Mettez à jour le fichier application.yaml ou application.properties , comme illustré dans l’exemple suivant. Supprimer spring.datasource.username et spring.datasource.password propriétés.

   spring:
     datasource:
       url: jdbc:sqlserver://${AZ_DATABASE_SERVER_NAME}.database.windows.net:1433;databaseName=${AZ_DATABASE_NAME};authentication=ActiveDirectoryMSI;
   

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

Une fois que votre application est configurée pour utiliser des connexions sans mot de passe, 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 avec SQL Server. 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 précédemment.

App Service

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.

Connecteur de service

Lorsque vous utilisez Service Connector, il peut vous aider à affecter l’identité managée affectée par le système pour votre environnement d’hébergement Azure. Toutefois, Portail Azure ne prend pas en charge la configuration d’Azure Database de cette façon. Vous devez donc utiliser Azure CLI pour attribuer l’identité.

Applications de conteneur

1. Dans la page de vue d’ensemble principale de votre instance Azure Container App, 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.

   

Azure Spring Apps

1. Dans la page de vue d’ensemble principale de votre instance Azure Spring Apps, 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.

   

Machines virtuelles

1. Dans la page de vue d’ensemble principale de votre machine virtuelle, 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.

   

AKS

Un cluster Azure Kubernetes Service (AKS) nécessite une identité managée pour accéder à des ressources Azure comme des équilibreurs de charge et des disques managés. Cette identité peut être une identité gérée ou un principal de service. Par défaut, lorsque vous créez un cluster AKS, une identité managée affectée par le système est automatiquement créée.

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

App Service

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)

Connecteur de service

Vous pouvez utiliser Service Connector pour créer une connexion entre un environnement d’hébergement de calcul Azure et un service cible à l’aide d’Azure CLI. Service Connector prend actuellement en charge les services de calcul suivants :

• Azure App Service
• Azure Spring Apps
• Azure Container Apps

Tout d’abord, installez l’extension sans mot de passe service Connector pour Azure CLI :

az extension add --name serviceconnector-passwordless --upgrade

Si vous utilisez Azure App Service, utilisez la az webapp connection commande, comme illustré dans l’exemple suivant :

az webapp connection create sql \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <app-service-name>
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

Si vous utilisez Azure Spring Apps, utilisez the az spring connection la commande, comme illustré dans l’exemple suivant :

az spring connection create sql \
    --resource-group $AZ_RESOURCE_GROUP \
    --service <service-name> \
    --app <service-instance-name> \
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

Si vous utilisez Azure Container Apps, utilisez la az containerapp connection commande, comme illustré dans l’exemple suivant :

az containerapp connection create sql \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <app-service-name>
    --target-resource-group $AZ_RESOURCE_GROUP \
    --server $AZ_DATABASE_SERVER_NAME \
    --database $AZ_DATABASE_NAME \
    --system-identity

Applications de conteneur

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

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

Azure Spring Apps

Vous pouvez affecter une identité managée à une instance Azure Spring Apps avec la commande az spring app identity assign, comme illustré dans l’exemple suivant :

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

Machines virtuelles

Vous pouvez affecter une identité managée à une machine virtuelle avec la commande az vm identity assign , comme illustré dans l’exemple suivant :

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

AKS

Vous pouvez affecter une identité managée à une instance Azure Kubernetes Service (AKS) avec la commande az aks update , comme illustré dans l’exemple suivant :

export AZ_MI_OBJECT_ID=$(az aks update \
    --resource-group $AZ_RESOURCE_GROUP \
    --name <AKS-cluster-name> \
    --enable-managed-identity \
    --query identityProfile.kubeletidentity.objectId \
    --output tsv)

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

Ensuite, accordez des autorisations à l’identité managée que vous avez créée pour accéder à votre base de données SQL.

Connecteur de service

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.

Azure CLI

Cette étape crée un utilisateur de base de données pour l’identité managée et lui accorde des autorisations de lecture et d’écriture.

La commande suivante récupère le nom complet de l’identité managée et construit les commandes pour créer un utilisateur pour l’identité managée et accorder des autorisations :

export AZ_DATABASE_AD_MI_USERNAME=$(az ad sp show \
    --id $AZ_MI_OBJECT_ID \
    --query displayName \
    --output tsv)
cat << EOF
CREATE USER "$AZ_DATABASE_AD_MI_USERNAME" FROM EXTERNAL PROVIDER;
ALTER ROLE db_datareader ADD MEMBER "$AZ_DATABASE_AD_MI_USERNAME";
ALTER ROLE db_datawriter ADD MEMBER "$AZ_DATABASE_AD_MI_USERNAME";
GO
EOF

Copiez la sortie de cette commande, puis accédez au Portail Azure et recherchez la base de données SQL. Connectez-vous à l’éditeur de requête en tant qu’utilisateur administrateur Microsoft Entra, comme illustré dans la capture d’écran suivante.

Après la sortie de la dernière commande dans l’éditeur de requête, puis exécutez les commandes SQL, comme illustré dans la capture d’écran suivante.

Tester l'application

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 Azure SQL 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 :

• Autoriser l’accès aux données d’objet blob avec des identités managées pour les ressources Azure.
• Autoriser l’accès aux objets blob à l’aide Microsoft Entra ID