Partie 2 : Besoins d’authentification dans cet exemple de scénario

Partie précédente : Introduction et contexte

Dans cet exemple de scénario, l’application principale a trois exigences d’authentification distinctes :

• Azure Key Vault

  L’application doit s’authentifier auprès de Azure Key Vault pour récupérer une clé API stockée en toute sécurité nécessaire pour appeler un service tiers.

• API tierce

  Une fois que l’application récupère la clé API, elle utilise la clé pour s’authentifier auprès de l’API tierce externe.

• Stockage des files d'attente Azure

  Après avoir traité la demande, l'application doit s'authentifier auprès d'Stockage File d'attente Azure pour ajouter un message pour un traitement asynchrone ou différé.

Ces tâches nécessitent que l’application gère trois ensembles d’informations d’identification :

• Deux ensembles de ressources Azure (Key Vault et Stockage)

• Un ensemble pour un service externe (API tierce)

Problèmes d’authentification clés

La création d’applications cloud sécurisées nécessite une gestion minutieuse des informations d’identification, en particulier lorsque plusieurs services sont impliqués. Cet exemple de scénario présente plusieurs défis critiques :

• Dépendance circulaire sur Key Vault

  L’application utilise Azure Key Vault pour stocker en toute sécurité les secrets, tels que les clés API tierces ou les informations d’identification du stockage Azure. Toutefois, pour récupérer ces secrets, l’application doit d’abord s’authentifier auprès de Key Vault. Cette situation crée un problème circulaire : l’application a besoin d’informations d’identification pour accéder à Key Vault, mais vous devez stocker ces informations d’identification en toute sécurité. Sans solution sécurisée, ce problème peut entraîner des informations d’identification codées en dur ou des configurations non sécurisées dans les environnements de développement.

• Gestion sécurisée des clés API tierces

  Après avoir récupéré la clé API à partir de Key Vault, l’application doit l’utiliser pour appeler un service tiers externe. Manipulez cette clé avec le plus grand soin :

  • Ne jamais le coder en dur dans le code source ou les fichiers de configuration
  • Ne le consignez jamais dans stdout, stderr ou les journaux de l’application.
  • Maintenez-le uniquement en mémoire et accédez-y au moment de l’exécution, juste avant d’utiliser
  • Supprimez-la rapidement une fois la demande terminée

  Le fait de ne pas suivre ces pratiques augmente le risque de fuite d’informations d’identification ou d’utilisation non autorisée.

• Sécuriser les informations d'identification de stockage Azure Queue

  Pour écrire des messages vers le stockage de files d'attente Azure, l’application a généralement besoin d’une chaîne de connexion ou d’un jeton d’accès partagé. Ces informations d’identification :

  • Doit être stocké dans un emplacement sécurisé, tel que Key Vault
  • Ne doit pas apparaître dans les journaux, les traces de pile ou les outils de développement
  • Doit être accessible uniquement par le biais de mécanismes d’exécution sécurisés
  • Exiger une configuration RBAC appropriée si vous utilisez une identité managée

• Flexibilité de l’environnement

  L'application doit s'exécuter de manière fiable dans les environnements de développement local et de production cloud, en utilisant la même base de code et une logique conditionnelle minimale.

  Cette exigence signifie :

  • N’incorporez pas de secrets spécifiques à l’environnement dans le code
  • Ne basculez pas manuellement les informations d’identification ou les chemins d’accès logiques
  • Utiliser l’authentification basée sur l’identité de manière cohérente entre les environnements

Authentification axée sur Azure avec Microsoft Entra ID

À mesure que les applications cloud s’adaptent à la complexité et s’intègrent à davantage de services, l’authentification sécurisée et simplifiée devient essentielle. Azure offre un modèle d’identité Azure-first via Microsoft Entra ID, ce qui permet une gestion unifiée des identités et une intégration transparente avec Azure services pour une authentification sécurisée et sans informations d’identification.

Au lieu de gérer manuellement les secrets ou d’incorporer des informations d’identification dans le code d’application, une pratique sujette aux risques de sécurité, Microsoft Entra ID permet aux applications de s’authentifier en toute sécurité à l’aide d’identités managées.

Les principaux avantages des identités managées Microsoft Entra sont les suivants :

• Aucun secret dans le code

  Les applications ne nécessitent plus de chaînes de connexion codées en dur, de secrets client ou de clés.

• Identité intégrée pour les applications

  Azure pouvez affecter automatiquement une identité managée à votre application, afin qu’elle puisse accéder en toute sécurité aux services tels que Key Vault, Stockage et SQL sans informations d’identification supplémentaires.

• Cohérence de l’environnement

  Le même modèle d’identité et de code fonctionnent à la fois dans les environnements locaux de développement et d’Azure hébergés à l’aide des Kit de développement logiciel (SDK) Azure.DefaultAzureCredential

Flux d’identité spécifique à l’environnement

Les applications qui utilisent l’ID Microsoft Entra pour l’authentification bénéficient d’un modèle d’identité flexible qui fonctionne en toute transparence dans les environnements de développement hébergés par Azure et locaux. Le Kit de développement logiciel (SDK) Azure fournit cette cohérence en sélectionnant automatiquement la méthode d’identité DefaultAzureCredential appropriée en fonction de l’environnement.

Environnement Azure

Lorsque vous déployez l’application sur Azure :

• L’application obtient automatiquement une identité managée.
• Azure gère l'émission de jetons et le cycle de vie des informations d'identification en interne. Vous n'avez donc pas besoin de gérer les secrets.
• L’application accède aux services à l’aide de Role-Based Access Control (RBAC) ou de stratégies d’accès Key Vault.

Environnement de développement local

Pendant le développement local :

• Un principal de service correspond à l’identité de l’application.
• Les développeurs s’authentifient à l’aide des Azure CLI (az login), des variables d’environnement ou des intégrations Visual Studio/VS Code.
• Le même code d’application s’exécute sans modification : seule la source d’identité change.

Dans les deux environnements, les SDK Azure utilisent le DefaultAzureCredential, qui fait abstraction de la source d’identité et sélectionne automatiquement la méthode appropriée.

Meilleures pratiques pour le développement sécurisé

Bien que vous puissiez définir des secrets en tant que variables d’environnement (par exemple, via Azure App Paramètres), cette approche présente des inconvénients :

• Vous devez répliquer manuellement des secrets dans des environnements locaux.
• Il y a un risque de fuite de secrets dans le contrôle de code source.
• Il se peut que vous ayez besoin d’une logique supplémentaire pour différencier les environnements.

Utilisez plutôt l’approche suivante :

• Utilisez Key Vault pour stocker des clés API tierces et d’autres secrets.
• Attribuez une identité managée à votre application déployée.
• Utilisez un principal de service pour le développement local et attribuez-lui les mêmes droits d’accès.
• Utilisez-le DefaultAzureCredential dans votre code pour abstraction de la logique d’authentification.
• Évitez de stocker ou de journaliser les informations d’identification.

Flux d’authentification en pratique

Voici comment l’authentification fonctionne au moment de l’exécution :

• Votre code crée une DefaultAzureCredential instance.
• Vous utilisez ces informations d’identification pour instancier un client (par exemple, SecretClient, QueueServiceClient).
• Lorsque l’application appelle une méthode (par exemple, get_secret()), le client utilise les informations d’identification pour authentifier la demande.
• Azure vérifie l’identité et vérifie si elle a le rôle ou la stratégie appropriés pour effectuer l’opération.

Ce flux garantit que votre application peut accéder en toute sécurité aux services Azure sans incorporer de secrets dans du code ou des fichiers de configuration. Il vous permet également de basculer en toute transparence entre le développement local et le déploiement cloud sans modifier votre logique d’authentification.