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 d’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 la clé API récupérée, l’application l’utilise 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'Azure Queue Storage 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 pour les ressources Azure (Key Vault et Stockage)

• Un 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. Cela crée un problème circulaire : l’application a besoin d’informations d’identification pour accéder à Key Vault, mais ces informations d’identification doivent être stockées en toute sécurité. Sans solution sécurisée, cela 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. Cette clé doit être manipulée avec soin extrême :

  • Jamais codé en dur dans le code source ou les fichiers de configuration
  • Jamais enregistré dans stdout, stderr ou dans les journaux d'application
  • Conservé uniquement en mémoire et accessible au moment de l’exécution, juste avant l’utilisation
  • Supprimé 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.

  En d’autres termes :

  • Aucun secret spécifique à l’environnement incorporé dans le code
  • Il n’est pas nécessaire d'alterner manuellement les informations d’identification ou les chemins logiques
  • Utilisation cohérente de l’authentification basée sur l’identité dans les environnements

Authentification Azure-First avec l’ID Microsoft Entra

À 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, permettant la gestion unifiée des identités et une intégration transparente avec les services Azure 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é, l’ID Microsoft Entra 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 peut attribuer automatiquement une identité managée à votre application, ce qui permet un accès sécurisé aux services, tels que Key Vault, Storage et SQL sans informations d’identification supplémentaires.

• Cohérence de l’environnement

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

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. Cette cohérence est obtenue à l’aide du Kit de DefaultAzureCredentialdéveloppement logiciel (SDK) Azure, qui sélectionne automatiquement la méthode d’identité appropriée en fonction de l’environnement.

Environnement Azure

Lorsque l’application est déployée sur Azure :

• Une identité managée est automatiquement affectée à l’application.
• Azure gère en interne l’émission de jetons et le cycle de vie des informations d’identification : aucun secret manuel n’est requis.
• L’application utilise Role-Based contrôle d’accès (RBAC) ou des stratégies d’accès Key Vault pour accéder aux services

Environnement de développement local

Pendant le développement local :

• Un principal de service agit comme l’identité de l’application.
• Les développeurs s’authentifient à l’aide d’Azure CLI (az login), de variables d’environnement ou d’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 masque la source d’identité et sélectionne automatiquement la méthode appropriée.

Meilleures pratiques pour le développement sécurisé

Bien qu’il soit possible de définir des secrets en tant que variables d’environnement (par exemple, via les paramètres d’application Azure), 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.
• Une logique supplémentaire peut être nécessaire pour différencier les environnements.

Au lieu de cela, l’approche recommandée est la 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.

Partie 3 - Implémentation d’API tierce >>>