Connexions sans mot de passe pour les services Azure

Remarque

Les connexions sans mot de passe sont une fonctionnalité indépendante de la langue qui s’étend sur plusieurs services Azure. Bien que la documentation actuelle se concentre sur quelques langues et services, nous sommes actuellement en train de produire de la documentation supplémentaire pour d’autres langues et services.

Cet article décrit les défis de sécurité liés aux mots de passe et présente les connexions sans mot de passe pour les services Azure.

Défis de sécurité liés aux mots de passe et aux secrets

Les mots de passe et les clés secrètes doivent être utilisés avec prudence, et les développeurs ne doivent jamais les placer dans un endroit non sécurisé. De nombreuses applications se connectent à la base de données principale, au cache, à la messagerie et aux services d’événements à l’aide de noms d’utilisateur, de mots de passe et de clés d’accès. Si elles sont exposées, ces informations d’identification peuvent être utilisées pour obtenir un accès non autorisé à des informations sensibles telles qu’un catalogue de ventes que vous avez créé pour une campagne à venir ou des données client qui doivent être privées.

L’incorporation de mots de passe dans une application elle-même présente un risque de sécurité énorme pour de nombreuses raisons, notamment la découverte via un référentiel de code. De nombreux développeurs externalisent ces mots de passe à l’aide de variables d’environnement afin que les applications puissent les charger à partir de différents environnements. Toutefois, cela déplace uniquement le risque du code lui-même vers un environnement d’exécution. Toute personne qui accède à l’environnement peut voler des mots de passe, ce qui augmente à son tour le risque d’exfiltration des données.

L’exemple de code suivant montre comment se connecter au stockage Azure à l’aide d’une clé de compte de stockage. De nombreux développeurs se tournent vers cette solution parce qu’elle semble familière aux options avec lesquelles ils ont travaillé dans le passé, même si ce n’est pas une solution idéale. Si votre application utilise actuellement des clés d’accès, envisagez de migrer vers des connexions sans mot de passe.

// Connection using secret access keys
BlobServiceClient blobServiceClient = new(
    new Uri("https://<storage-account-name>.blob.core.windows.net"),
    new StorageSharedKeyCredential("<storage-account-name>", "<your-access-key>"));

Les développeurs doivent faire preuve de diligence pour ne jamais exposer ces types de clés ou de secrets dans un endroit non sécurisé. De nombreuses entreprises ont des exigences de sécurité strictes pour se connecter aux services Azure sans exposer les mots de passe aux développeurs, aux opérateurs ou à toute autre personne. Ils utilisent souvent un coffre-fort pour stocker et charger les mots de passe dans les applications, et réduisent encore le risque en ajoutant des exigences et des procédures de rotation des mots de passe. Cette approche, à son tour, augmente la complexité opérationnelle et, parfois, entraîne des interruptions de connexion aux applications.

Connexions sans mot de passe et Zero Trust

Vous pouvez désormais utiliser des connexions sans mot de passe dans vos applications pour vous connecter aux services basés sur Azure sans avoir à changer de mot de passe. Dans certains cas, tout ce dont vous avez besoin est la configuration, aucun nouveau code n’est requis. Le Zero Trust utilise le principe « ne jamais faire confiance, toujours vérifier et sans informations d’identification ». Cela signifie sécuriser toutes les communications en ne faisant confiance aux machines ou aux utilisateurs qu’après avoir vérifié leur identité et avant de leur accorder l’accès aux services backend.

L’option d’authentification recommandée pour les connexions sécurisées et sans mot de passe consiste à utiliser conjointement des identités managées et le contrôle d’accès en fonction du rôle (RBAC) Azure. Avec cette approche, vous n’avez pas besoin de suivre et de gérer manuellement de nombreux secrets différents pour les identités managées, car ces tâches sont gérées en interne de manière sécurisée par Azure.

Vous pouvez configurer des connexions sans mot de passe aux services Azure à l’aide de Service Connector ou les configurer manuellement. Service Connector active les identités managées dans les services d’hébergement d’applications comme Azure Spring Apps, Azure App Service et Azure Container Apps. Service Connector configure également les services backend avec des connexions sans mot de passe à l’aide d’identités managées et d’Azure RBAC, et enrichit les applications avec les informations de connexion nécessaires.

Si vous inspectez l’environnement d’exécution d’une application configurée pour les connexions sans mot de passe, vous pouvez voir la chaîne de connexion complète. La chaîne de connexion porte, par exemple, une adresse de serveur de base de données, un nom de base de données et une instruction pour déléguer l’authentification à un plug-in d’authentification Azure, mais elle ne contient aucun mot de passe ni secret.

La vidéo suivante illustre les connexions sans mot de passe entre les applications et les services Azure, en utilisant les applications Java comme exemple. Une couverture similaire pour d’autres langues est à venir.

Présentation de DefaultAzureCredential

Les connexions sans mot de passe aux services Azure via Microsoft Entra ID et le contrôle d’accès en fonction du rôle (RBAC) peuvent être implémentées DefaultAzureCredential à partir des bibliothèques clientes Azure Identity.

Important

Certains langages doivent être implémentés DefaultAzureCredential explicitement dans leur code, tandis que d’autres utilisent DefaultAzureCredential en interne via des plug-ins ou des pilotes sous-jacents.

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 les recherches d’informations d’identification varient selon les langues :

• .FILET
• C++
• Allez
• Java
• JavaScript
• Python

Par exemple, lors de l’utilisation locale avec .NET, DefaultAzureCredential s’authentifie généralement à l’aide du compte utilisé par le développeur pour se connecter à Visual Studio, Azure CLI, ou Azure PowerShell. Lorsque l’application est déployée sur Azure, DefaultAzureCredential découvrira et utilisera automatiquement l’identité managée du service d’hébergement associé, tel que Azure App Service. Aucune modification du code n’est nécessaire pour cette transition.

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 que vous approvisionniez ou alterniez les secrets. Vous pouvez en savoir plus sur les identités managées dans la documentation vue d’ensemble .

L’exemple de code suivant montre comment se connecter à Service Bus à l’aide de connexions sans mot de passe. D’autres documents décrivent plus en détail comment migrer vers cette configuration pour un service spécifique. Une application .NET peut transmettre une instance de dans DefaultAzureCredential le constructeur d’une classe cliente de service. DefaultAzureCredential détecte automatiquement les informations d’identification disponibles dans cet environnement.

ServiceBusClient serviceBusClient = new(
    new Uri("https://<your-service-bus-namespace>.blob.core.windows.net"),
    new DefaultAzureCredential());

Voir aussi

Pour plus d’informations sur les connexions sans mot de passe, consultez le guide du développeur Configurer les connexions sans mot de passe entre plusieurs applications et services Azure.