Fournir des informations d’identification d’identité d’application en l’absence d’utilisateur

  • Article

Lorsque vous, en tant que développeur, créez des applications non-utilisateur, vous n’avez pas d’utilisateur que vous pouvez demander un nom d’utilisateur et un mot de passe ou l’authentification multifacteur (MFA). Vous devez fournir l’identité de l’application elle-même. Cet article explique pourquoi la meilleure pratique des informations d’identification client Confiance Zéro pour les services (applications non utilisateur) sur Azure est Des identités managées pour les ressources Azure.

Problèmes liés aux comptes de service

L’utilisation d’un « compte de service » (création d’un compte d’utilisateur et de son utilisation pour un service) n’est pas une bonne solution. Microsoft Entra ID n’a pas de concept de compte de service. Lorsque les administrateurs créent des comptes d’utilisateur pour un service, puis partagent des mots de passe avec des développeurs, il est non sécurisé. Il ne peut pas s’agir d’une authentification multifacteur sans mot de passe ou d’une authentification multifacteur. Au lieu d’utiliser un compte d’utilisateur en tant que compte de service, votre meilleure solution consiste à utiliser l’une des options d’informations d’identification du client décrites ci-dessous.

Options d’informations d’identification du client

Il existe quatre types d’informations d’identification client qui peuvent identifier une application.

Clé secrète ou certificat ?

Les clés secrètes sont acceptables lorsque vous disposez d’une infrastructure de gestion des secrets sophistiquée (par exemple , Azure Key Vault) dans votre entreprise. Toutefois, les clés secrètes dans les scénarios où le professionnel de l’informatique génère une clé secrète, puis l’envoie par email à un développeur qui peut ensuite le stocker dans un emplacement non sécurisé comme une feuille de calcul, ce qui empêche la protection correcte des clés secrètes.

Les informations d'identification du client basées sur des certificats sont plus sûres que les clés secrètes. Les certificats sont mieux gérés, car ils ne sont pas le secret lui-même. Le secret ne fait pas partie d’une transmission. Lorsque vous utilisez une clé secrète, votre client envoie la valeur réelle de la clé secrète à Microsoft Entra ID. Lorsque vous utilisez un certificat, la clé privée du certificat ne quitte jamais l’appareil. Même si quelqu’un intercepte, décode et déchiffre la transmission, le secret est toujours sécurisé, car la partie d’interception n’a pas la clé privée.

Meilleure pratique : utiliser les identités managées pour les ressources Azure

Lorsque vous développez des services (applications non-utilisateurs) dans Azure, les identités managées pour les ressources Azure fournissent une identité gérée automatiquement dans Microsoft Entra ID. L'application peut s'authentifier auprès de n'importe quel service prenant en charge l'authentification Microsoft Entra sans avoir à gérer les informations d'identification. Vous n’avez pas besoin de gérer les secrets ; vous n’avez pas besoin de traiter la possibilité de perdre ou de les mal gérer. Les secrets ne peuvent pas être interceptés, car ils ne se déplacent pas sur le réseau. Les identités managées pour les ressources Azure sont les meilleures pratiques si vous créez des services sur Azure.

Étapes suivantes