Meilleures pratiques de sécurité pour les propriétés d’application dans Microsoft Entra ID

La sécurité est un concept important lors de l’inscription d’une application dans Microsoft Entra ID et constitue une partie essentielle de son utilisation dans l’organisation. Tout problème de configuration d’une application peut entraîner des temps d’arrêt ou une compromission. Selon les autorisations ajoutées à une application, il peut y avoir des effets à l’échelle de l’organisation.

Étant donné que les applications sécurisées sont essentielles à l’organisation, tout temps d’arrêt dû à des problèmes de sécurité peut affecter l’entreprise ou un service critique dont dépend l’entreprise. Il est donc important d’allouer du temps et des ressources pour garantir que les applications demeurent dans un état d’intégrité et de sécurité irréprochable. Procédez à une évaluation périodique de la sécurité et de l’intégrité de vos applications, à l’instar d’une évaluation du modèle de menaces de sécurité pour le code. Pour une perspective plus large sur la sécurité des organisations, consultez le cycle de vie de développement de la sécurité (SDL).

Cet article décrit les meilleures pratiques de sécurité pour les propriétés et scénarios d’application suivants :

• Type d'identité
• Informations d’identification
• URI de redirection
• Configuration de flux implicite
• URI d’ID d’application (également appelé URI d’identificateur)
• Version du jeton d’accès
• Verrou d’instance d’application
• Propriété de l’application

Type d'identité

Vous êtes probablement ici pour en savoir plus sur les meilleures pratiques de sécurité pour les applications Microsoft Entra , également appelées inscriptions d’applications ou objets d’application. Toutefois, il existe un autre type d’identité qui peut être utilisé pour accéder aux ressources protégées par Entra, appelées identités managées pour les ressources Azure.

Les identités managées Azure sont sécurisées par défaut et nécessitent peu à aucune maintenance ou surcharge en cours. Envisagez d’utiliser une identité managée au lieu d’une application Microsoft Entra pour votre identité d’application si toutes les valeurs suivantes sont vraies :

• Le service s’exécute dans le cloud Azure
• L’application n’a pas besoin de connecter des utilisateurs
• L’application n’a pas besoin d’agir comme ressource dans un flux de jetons (n’est pas une API web)
• L’application n’a pas besoin de fonctionner dans plusieurs locataires

Notez que les identités managées peuvent être utilisées pour accéder aux ressources en dehors d’Azure, y compris Microsoft Graph.

Le reste de cet article aborde les meilleures pratiques de sécurité pour les enregistrements d'applications Entra.

Informations d’identification (y compris les certificats et les secrets)

Les informations d’identification constituent une partie essentielle d’une application lorsqu’elle est utilisée en tant que client confidentiel. Dans la page Certificats et secrets de l’application dans le portail Azure, les informations d’identification peuvent être ajoutées ou supprimées.

Prenez en compte les conseils suivants concernant les certificats et les secrets :

• Utilisez une identité managée en tant qu’informations d’identification dans la mesure du possible. Ceci est fortement recommandé, car les identités managées sont à la fois l’option la plus sécurisée et ne nécessitent aucune gestion continue des informations d’identification. Suivez ces instructions pour configurer une identité managée en tant qu’informations d’identification. Toutefois, cette option peut être possible uniquement si le service utilisé par l’application s’exécute sur Azure.
• Si le service dans lequel l’application est utilisée ne s’exécute pas sur Azure, mais s’exécute sur une autre plateforme qui offre la gestion automatisée des informations d’identification, envisagez d’utiliser une identité à partir de cette plateforme en tant qu’informations d’identification. Par exemple, un workflow d’actions GitHub peut être configuré en tant qu’informations d’identification, ce qui élimine la nécessité de gérer et de sécuriser les informations d’identification pour le pipeline d’actions GitHub. Soyez prudent avec cette approche et configurez uniquement les informations d’identification fédérées à partir de plateformes approuvées. Une application a le niveau de sécurité de la plateforme d’identité qu’elle a configurée comme informations d’identification.
• Si l’utilisation d’une identité managée ou d’un autre fournisseur d’identité externe sécurisé n’est pas possible, utilisez des informations d’identification de certificat. N’utilisez pas d’informations d’identification de mot de passe, également appelées secrets. Bien qu’il soit pratique d’utiliser des secrets de mot de passe comme informations d’identification, les informations d’identification de mot de passe sont souvent mal gérées et peuvent être facilement compromises.
• Si un certificat doit être utilisé au lieu d’une identité managée, stockez ce certificat dans un coffre de clés sécurisé, comme Azure Key Vault.
• Si un certificat doit être utilisé au lieu d’une identité managée, utilisez un certificat d’une autorité de certification approuvée au lieu d’un certificat auto-signé. Configurez une stratégie pour appliquer que les certificats proviennent d’émetteurs approuvés. Toutefois, si l’utilisation d’une autorité de certification approuvée n’est pas possible, les certificats auto-signés sont toujours préférés aux mots de passe.
• Configurez des stratégies de gestion des applications pour régir l’utilisation des secrets en limitant leurs durées de vie ou en bloquant complètement leur utilisation.
• Si une application est utilisée uniquement en tant que client public ou installé (par exemple, les applications mobiles ou de bureau installées sur l’ordinateur utilisateur final), vérifiez qu’aucune information d’identification n’est spécifiée sur l’objet d’application.
• Passez en revue les informations d’identification utilisées dans les applications en vue de pouvoir les actualiser et de connaître leur date d’expiration. Une information d’identification non utilisée sur une application peut entraîner une violation de la sécurité. Substituez les informations d’identification de substitution fréquemment et ne partagez pas les informations d’identification entre les applications. Ne disposez pas de nombreuses informations d’identification sur une même application.
• Surveillez vos pipelines de production pour vous assurer que les informations d’identification de n’importe quel type ne sont jamais validées dans des référentiels de code. Credential Scanner est un outil d’analyse statique qui permet de détecter les informations d’identification (et tout autre contenu sensible) dans votre code source et la sortie de la build.

URI de redirection

Il est important de tenir à jour les URI de redirection de votre application. Sous l’option Authentification correspondant à l’application dans le Portail Azure, une plateforme doit être sélectionnée pour l’application, puis la propriété URI de redirection peut être définie.

Prenez en compte les conseils suivants pour les URI de redirection :

• Conservez la propriété de tous les URI. Une brèche dans la propriété de l’un des URI de redirection peut compromettre l’application.
• Assurez-vous que tous les enregistrements DNS sont régulièrement mis à jour et que leurs modifications sont surveillées.
• N’utilisez pas d’URL de réponse générique ou de schémas d’URI non sécurisés tels que http ou URN.
• Maîtrisez la taille de la liste. Supprimez les URI inutiles. Si possible, mettez à jour les URL de http vers https.

Configuration de flux implicite

Les scénarios qui requièrent un flux implicite peuvent désormais utiliser le flux de code d’authentification pour réduire le risque de compromission d’une utilisation incorrecte du flux implicite. Sous l’option Authentification correspondant à l’application dans le Portail Azure, une plateforme doit être sélectionnée pour l’application, puis la propriété Jetons d’accès (utilisés pour les flux implicites) peut être définie.

Prenez en compte les conseils suivants liés au flux implicite :

• Vérifiez si le flux implicite est requis. N’utilisez pas de flux implicite sauf spécification requise explicitement.
• Si l’application a été configurée pour recevoir des jetons d’accès à l’aide d’un flux implicite, mais ne les utilise pas activement, désactivez le paramètre pour protéger contre une utilisation incorrecte.
• Utilisez des applications distinctes pour des scénarios de flux implicites valides.

URI d’ID d’application (également appelé URI d’identificateur)

La propriété URI d’ID d’application de l’application spécifie l’URI global unique utilisé pour identifier l’API web. C'est le préfixe de la valeur de périmètre dans les requêtes adressées à Microsoft Entra. Il s’agit également de la valeur de revendication d’audience (aud) dans les jetons d’accès v1.0. Pour les applications mutualisées, la valeur doit également être globalement unique. C'est ce qu’on appelle aussi l’URI d’identificateur. Sous Exposer une API pour l’application dans le Portail Azure, la propriété URI d’ID d’application peut être définie.

Meilleures pratiques pour définir la modification de l’URI de l’ID d’application en fonction de l’émission de jetons d’accès v1.0 ou v2.0. Si vous ne savez pas si une application reçoit des jetons d’accès v1.0, vérifiez-le requestedAccessTokenVersion du manifeste de l’application. La valeur null ou 1 indique que l’application reçoit des jetons d’accès v1.0. Une valeur de 2 indique que l’application reçoit des jetons d’accès v2.0.

Pour les applications qui sont émises des jetons d’accès v1.0, seules les URI par défaut doivent être utilisés. Les URI par défaut sont api://<appId> et api://<tenantId>/<appId>. - Configurez la restriction dans les nonDefaultUriAdditionstratégies de gestion des applications pour appliquer cette meilleure pratique pour les futures mises à jour des applications de votre organisation.

Pour les applications qui sont émises des jetons d’accès v2.0, utilisez les instructions suivantes lors de la définition de l’URI d’ID d’application :

• Les schémas d’URI api ou https sont recommandés. Définissez la propriété dans les formats pris en charge pour éviter les collisions d’URI dans votre organisation. N’utilisez pas de caractères génériques.
• Utilisez un domaine vérifié de votre organisation.
• Conservez un inventaire des URI de votre organisation pour vous aider à maintenir la sécurité.

L’API et les formats d’URI d’ID d’application basée sur le schéma HTTP suivants sont pris en charge. Remplacez les valeurs d’espace réservé comme décrit dans la liste qui suit le tableau.

ID d’application pris en charge Formats d’URI	Exemples d’URI d’ID d’application
api://<appId>	api://00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<appId>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/00001111-aaaa-2222-bbbb-3333cccc4444
api://<tenantId>/<string>	api://aaaabbbb-0000-cccc-1111-dddd2222eeee/api
api://<string>/<appId>	api://productapi/00001111-aaaa-2222-bbbb-3333cccc4444
https://<tenantInitialDomain>.onmicrosoft.com/<string>	https://contoso.onmicrosoft.com/productsapi
https://<verifiedCustomDomain>/<string>	https://contoso.com/productsapi
https://<string>.<verifiedCustomDomain>	https://product.contoso.com
https://<string>.<verifiedCustomDomain>/<string>	https://product.contoso.com/productsapi
api://<string>.<verifiedCustomDomainOrInitialDomain>/<string>	api://contoso.com/productsapi

• <appId> : propriété d’identificateur d’application (appId) de l’objet application.
• <string> : valeur de chaîne pour l’hôte ou le segment de chemin d’accès de l’API.
• <tenantId> : GUID généré par Azure pour représenter le locataire dans Azure.
• <tenantInitialDomain> - <tenantInitialDomain>.onmicrosoft.com, où <tenantInitialDomain> est le nom de domaine initial que le créateur du locataire a spécifié lors de la création du locataire.
• <verifiedCustomDomain> : domaine personnalisé vérifié configuré pour votre locataire Microsoft Entra.

Note

Si vous utilisez le schéma api:// , vous ajoutez une valeur de chaîne directement après « api:// ». Par exemple, api://<chaîne>. Cette valeur de chaîne peut être un GUID ou une chaîne arbitraire. Si vous ajoutez une valeur GUID, elle doit correspondre à l’ID d’application ou à l’ID de locataire. Si vous utilisez une valeur de chaîne, elle doit utiliser un domaine personnalisé vérifié ou un domaine initial de votre locataire. La recommandation consiste à utiliser api://< appId>.

Importante

La valeur de l’URI d’ID d’application ne doit pas se terminer par une barre oblique « / ».

Importante

La valeur de l’URI de l’ID d’application doit être unique pour votre locataire.

Version du jeton d’accès

Cette section s’applique uniquement aux applications de ressources, c’est-à-dire aux applications qui agissent en qualité de public dans les jetons d’accès. Les applications de ressources sont généralement des API web. Si une application agit uniquement en tant que client (ce qui signifie qu’elle acquiert des jetons à envoyer à des ressources telles que Microsoft Graph), cette section ne s’applique pas.

Les applications de ressources qui ont configuré des URI d’identificateur personnalisés doivent utiliser le format de jeton d’accès v2.0. Pour vérifier si une application doit utiliser des jetons d’accès v2.0, examinez la propriété dans la page manifeste des inscriptions d'application de l'application.

S'il existe des valeurs configurées qui ne sont pas au format api://{appId} ou api://{tenantId}/{appId}, alors l'application doit utiliser des jetons d'accès v2.0.

Pour effectuer une mise à niveau vers des jetons d’accès v2.0, vérifiez d’abord que l’application peut gérer les revendications de jeton v2.0. Ensuite, mettez à jour la version du jeton d’accès délivré à l’application en utilisant l’éditeur de manifeste.

Une fois la configuration de l’application mise à jour pour utiliser des jetons v2.0, vérifiez que la logique de validation de l’audience de l’application est modifiée de façon à accepter uniquement ses propres appId.

Verrou de propriété de l’instance d’application

Lorsqu'une application a un principal de service provisionné dans un locataire, ce principal de service peut être personnalisé par un administrateur du locataire. Cela est vrai, que ce locataire soit celui d'origine de l'application ou un locataire externe. Ces capacités de personnalisation peuvent permettre des modifications que le propriétaire de l’application n’attendait pas, ce qui entraîne des risques de sécurité. Par exemple, les informations d’identification peuvent être ajoutées au principal de service, même si les informations d’identification doivent généralement être détenues et contrôlées par le développeur et le propriétaire de l’application.

Pour réduire ce risque, les applications doivent configurer le verrou d’instance d’application. Lors de la configuration du verrou d’instance d’application, verrouillez toujours chaque propriété sensible disponible. La configuration de cette propriété est particulièrement critique pour les applications multi-locataires, c'est-à-dire utilisées dans plusieurs locataires ou organisations, mais elle peut et doit être définie par toutes les applications.

Autorisations

Votre application peut avoir besoin d’autorisations pour accéder aux ressources protégées ou aux API. Lors de la demande d’autorisations, vérifiez toujours ce qui suit :

• Suivez les principes des privilèges minimum . Demandez uniquement l’autorisation qui accorde le moins d’accès permissif requis pour effectuer l’action que l’application doit effectuer. Si vous appelez Microsoft Graph, utilisez la documentation de l’API pour identifier les autorisations les moins permissives pour un appel d’API donné. Passez régulièrement en revue les autorisations de votre application pour vérifier si une option moins privilégiée est disponible. Si une application n’a plus besoin d’une autorisation, supprimez-la.
• Dans la mesure du possible, utilisez l’accès délégué au lieu d’un accès d’application uniquement.
• Passez en revue les autorisations et la documentation de consentement pour vous assurer que vous comprenez les principes fondamentaux des autorisations.

Configuration de la propriété de l’application

Les propriétaires peuvent gérer tous les aspects d’une application inscrite. Il est important d’examiner régulièrement la propriété de toutes les applications de l’organisation. Pour plus d’informations, consultez les révisions d’accès dans Microsoft Entra. Sous l’option Propriétaires correspondant à l’application dans le Portail Azure, les propriétaires de l’application peuvent être gérés.

Tenez compte des instructions suivantes relatives à la spécification des propriétaires d’applications :

• La propriété des applications doit être limitée à un nombre minimal de personnes au sein de l’organisation.
• Un administrateur doit examiner la liste des propriétaires une fois par mois pour s’assurer que les propriétaires font toujours partie de l’organisation et doivent toujours posséder une application.

Vérifiez les recommandations Entra

La fonctionnalité de recommandations Microsoft Entra permet de surveiller l’état de votre locataire afin que vous n’ayez pas à le faire. Ces recommandations permettent de garantir que votre locataire est dans un état sécurisé et sain tout en vous aidant à optimiser la valeur des fonctionnalités disponibles dans Microsoft Entra ID. Passez régulièrement en revue les recommandations Microsoft Entra actives relatives aux propriétés de l’application ou à la configuration d’application pour maintenir votre écosystème d’applications dans un état sain.