Fournir des informations d’identification d’identité d’application en l’absence 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 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
- Certificat
- Identités managées pour les ressources Azure
- Identifiants fédérés
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
- Les types d’identité et de compte pris en charge pour les applications à locataire unique et multilocataire expliquent comment choisir si votre application autorise uniquement les utilisateurs de votre locataire Microsoft Entra, n’importe quel locataire Microsoft Entra ou les utilisateurs disposant de comptes Microsoft personnels.
- Le développement d’une stratégie d’autorisations d’application vous aide à décider de l’approche des autorisations d’application pour le gestionnaire d'informations d’identification.
- La fourniture d'identifiants d'application en l'absence d'utilisateur explique pourquoi la meilleure pratique en matière d'identifiants client Zero Trust pour les services (applications non-utilisateurs) sur Azure est Managed Identities (Identités gérées) pour les ressources Azure.
- Les meilleures pratiques d’autorisation vous aident à implémenter les modèles d’autorisation, d’autorisation et de consentement les mieux adaptés à vos applications.
- Utilisez les meilleures pratiques de développement de la gestion des identités et des accès Confiance Zéro dans votre cycle de développement d'applications pour créer des applications sécurisées.
- La création d’applications avec une approche Confiance Zéro de l’identité fournit une vue d’ensemble des autorisations et des meilleures pratiques d’accès.
Commentaires
https://aka.ms/ContentUserFeedback.
Bientôt disponible : Tout au long de 2024, nous allons supprimer progressivement GitHub Issues comme mécanisme de commentaires pour le contenu et le remplacer par un nouveau système de commentaires. Pour plus d’informations, consultezEnvoyer et afficher des commentaires pour