Fournir des informations d’identification d’identité d’application lorsqu’il n’y a pas d’utilisateur

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 pour les certificats client Zero Trust des services (applications non-utilisateur) sur Azure est les identités gérées des ressources Azure.

Problèmes liés aux comptes de service

L’utilisation d’un compte de service (utilisation d’un compte d’utilisateur 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 les services, puis partagent des mots de passe avec les développeurs, il est non sécurisé. Il ne peut pas être sans mot de passe ni disposer d'une MFA. 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 client suivantes.

Options d'identifiants 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 dans les infrastructures de gestion des secrets sophistiquées (telles qu’Azure Key Vault). Toutefois, vous ne pouvez pas protéger correctement 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 e-mail à un développeur.

Les informations d’identification client basées sur un certificat sont plus sécurisées que les clés secrètes. Vous pouvez mieux gérer les certificats, 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 à l’ID Microsoft Entra. 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.

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

Lorsque vous développez des services (applications non-utilisateur) dans Azure, les identités managées pour les ressources Azure fournissent une identité managée automatiquement dans l’ID Microsoft Entra. L’application peut s’authentifier auprès de n’importe quel service prenant en charge l’authentification Microsoft Entra sans gérer les informations d’identification. Vous n’avez pas besoin de gérer les secrets. Vous n’avez pas besoin de considérer la possibilité de les perdre ou de mal les gérer. Les acteurs malveillants ne peuvent pas intercepter les secrets qui ne transitent pas par le réseau. Les identités managées pour les ressources Azure sont les meilleures pratiques lorsque vous créez des services sur Azure.

Étapes suivantes