Fourniture d’informations d’identification d’identité d’application lorsqu’il n’existe aucun 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 par elle-même. Cet article explique pourquoi la meilleure pratique Confiance nulle des informations d’identification client 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 » dans lequel vous créez un compte d’utilisateur et l’utilisez pour un service n’est pas une bonne solution, car Azure Active Directory (Azure AD) n’a pas de concept de compte de service. Lorsque les administrateurs créent un compte d’utilisateur pour un service, puis partagent le mot de passe avec un développeur, il n’est pas sécurisé, car il ne peut pas être sans mot de passe ou avoir 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
  • Certificat
  • Identité managée pour Azure
  • Informations d’identification fédérées

Clé secrète ou certificat ?

Les clés secrètes sont acceptables lorsque vous disposez d’une infrastructure de gestion des secrets sophistiquée 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 e-mail à un développeur qui peut ensuite le stocker dans un emplacement non sécurisé comme une feuille de calcul entraîne la non-protection correcte des clés secrètes.

Les informations d’identification client basées sur des certificats sont plus sécurisées 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 à Azure AD. 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 interceptante 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 ressources Azure fournissent une identité managée automatiquement dans Azure AD. L’application peut s’authentifier auprès de n’importe quel service qui prend en charge l’authentification Azure AD sans gérer les informations d’identification. Vous n’avez pas besoin de gérer les secrets ; vous n’avez pas besoin de répondre à 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