Connexions sans mot de passe pour les services Azure

  • Article

Remarque

Les connexions sans mot de passe sont une fonctionnalité sans langage spécifié qui couvre 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 problèmes de sécurité liés aux mots de passe et introduit des connexions sans mot de passe pour les services Azure.

Problèmes 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 précaution, et les développeurs ne doivent jamais les placer dans un emplacement 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 gravitent vers cette solution, car il se sent familier des options avec lesquelles ils ont travaillé dans le passé, même s’il 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 être attentifs à ne jamais exposer ces types de clés ou de secrets dans un emplacement non sécurisé. De nombreuses entreprises ont des exigences de sécurité strictes pour se connecter aux services Azure sans exposer de mots de passe aux développeurs, aux opérateurs ou à toute autre personne. Ils utilisent souvent un coffre pour stocker et charger des mots de passe dans des applications, et réduisent davantage le risque en ajoutant des exigences et procédures de rotation de mot de passe. Cette approche, à son tour, augmente la complexité opérationnelle et, parfois, entraîne des pannes de connexion d’application.

Connexions sans mot de passe et Confiance Zéro

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 besoin de faire pivoter les mots de passe. Dans certains cas, tout ce dont vous avez besoin est la configuration : aucun nouveau code n’est requis. Confiance Zéro utilise le principe « jamais confiance, toujours vérifier et sans informations d’identification ». Cela signifie la sécurisation de toutes les communications en faisant confiance aux ordinateurs ou aux utilisateurs uniquement après avoir vérifié l’identité et avant de leur accorder l’accès aux services principaux.

L’option d’authentification recommandée pour les connexions sécurisées et sans mot de passe consiste à utiliser des identités managées et un contrôle d’accès en fonction du rôle Azure (RBAC) en combinaison. 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 en toute sécurité par Azure.

Vous pouvez configurer des connexions sans mot de passe aux services Azure à l’aide du service Connecter or ou vous pouvez 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. Le Connecter or de service configure également les services principaux avec des connexions sans mot de passe à l’aide d’identités managées et d’Azure RBAC, et hydrate les applications avec les informations de connexion nécessaires.

Si vous inspectez l’environnement en cours 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. Le 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 secrets.

La vidéo suivante illustre les connexions sans mot de passe des applications aux services Azure, à l’aide d’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 l’ID Microsoft Entra 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 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 varient entre les langues :

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 requise pour cette transition.

Notes

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 vous oblige pas à provisionner ou à faire pivoter 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 expliquent comment migrer vers cette configuration pour un service spécifique plus en détail. Une application .NET peut passer une instance du DefaultAzureCredential 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 obtenir une explication plus détaillée des connexions sans mot de passe, consultez le guide du développeur Configurer les connexions sans mot de passe entre plusieurs applications et services Azure.