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 demandes d’application 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 est 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 utilisateur de base de données et d’autres services Microsoft dans un emplacement central, 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 des mots de passe à un seul endroit.
• 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 de la base de données Azure SQL

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 une chaîne de connexion est accidentellement vérifiée dans le contrôle de code source, envoyée via un e-mail non sécurisé, collée dans une conversation incorrecte ou consultée 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 pour utiliser DefaultAzureCredential au lieu d’alternatives telles que des chaînes de connexion.

DefaultAzureCredential prend en charge plusieurs méthodes d’authentification et détermine automatiquement ce qui doit être utilisé 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 recherche des informations d'identification sont indiqués dans l'aperçu de la bibliothèque Azure Identity. 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 nécessaire 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. L’identité est gérée par la plateforme Azure et ne nécessite pas de provisionner ou de changer régulièrement des 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 Azure.

1) Configurer la base de données Azure SQL

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. Seul un utilisateur Administrateur Microsoft Entra peut créer/activer des utilisateurs pour l’authentification basée sur l’ID Microsoft Entra.

Si vous utilisez Azure CLI, exécutez la commande suivante pour vous assurer qu’elle dispose 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 de Microsoft Entra comme étant 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 package azure-identity. 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 un java.sql.Connection pour se connecter à Azure SQL Database. Mettez à jour votre code pour qu’il corresponde à 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 variables $AZ_DATABASE_SERVER_NAME et une variable $AZ_DATABASE_NAME par les valeurs que vous avez configurées au début de cet article.

4. Supprimez les user et les password de l’URL JDBC.

Printemps

1. Dans votre projet, ajoutez une référence au package spring-cloud-azure-starter. 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 librairies Azure Spring Cloud à l’aide d’une liste de matériaux (BOM), consultez la section Introduction du guide du développeur Spring Cloud Azure.

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

   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 au 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 Identity dans le volet de navigation.

2. Dans l'onglet Système affecté, veillez à ce que le champ État soit 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 les identifiants 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, le 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 Identity dans le volet de navigation.

2. Dans l'onglet Système affecté, veillez à ce que le champ État soit 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 les identifiants de l’identité ne sont jamais exposés dans votre code.

   

Les Azure Spring Apps

1. Dans la page de vue d’ensemble principale de votre instance Azure Spring Apps, sélectionnez Identity dans le volet de navigation.

2. Dans l'onglet Système affecté, veillez à ce que le champ État soit 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 les identifiants 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 Identity dans le volet de navigation.

2. Dans l'onglet Système affecté, veillez à ce que le champ État soit 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 les identifiants de l’identité ne sont jamais exposés dans votre code.

   

AKS

Un cluster Azure Kubernetes Service (AKS) nécessite une identité pour accéder aux ressources Azure telles que les équilibreurs de charge et les 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 l'az webapp identity assign commande, 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 Service Connector sans mot de passe pour Azure CLI :

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

Si vous utilisez Azure App Service, utilisez la commande az webapp connection, 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 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 commande az containerapp connection, 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 l'az containerapp identity assign commande, 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)

Les Azure Spring Apps

Vous pouvez affecter une identité managée à une instance Azure Spring Apps, 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 l'az vm identity assign commande, 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 az aks update commande, 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.

Collez la sortie de la dernière commande dans l’éditeur de requête, et 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. Gardez à l’esprit qu’il peut prendre plusieurs minutes pour que les attributions de rôles se propagent via votre 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’ont à gérer les secrets dans l’application elle-même.

Étapes suivantes

Dans ce tutoriel, 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étail :

• Autoriser l’accès aux données de blob avec des identités gérées pour les ressources Azure.
• Autoriser l'accès aux blobs à l'aide de Microsoft Entra ID