Partager via


Vue d’ensemble de l’API des méthodes d’authentification d’application Microsoft Entra

Espace de noms: microsoft.graph

Les méthodes d’authentification des applications telles que les certificats et les secrets de mot de passe permettent aux applications d’acquérir des jetons pour accéder aux données dans Microsoft Entra ID. Les stratégies permettent aux administrateurs informatiques d’appliquer les meilleures pratiques concernant la façon dont les applications de leur organisation utilisent ces méthodes d’authentification d’application. Par exemple, un administrateur peut configurer une stratégie pour bloquer l’utilisation ou limiter la durée de vie des secrets de mot de passe, et utiliser la date de création de l’objet pour appliquer la stratégie.

Ces stratégies permettent aux organisations de tirer parti des nouvelles fonctionnalités de renforcement de la sécurité des applications. En appliquant des restrictions basées sur la date de création de l’application ou du principal de service, un organization peut passer en revue sa posture actuelle de sécurité des applications, inventorier les applications et appliquer des contrôles en fonction de ses planifications et besoins en matière de ressources. Cette approche à l’aide de la date de création permet au organization d’appliquer la stratégie pour les nouvelles applications et également de l’appliquer aux applications existantes.

Il existe deux types de contrôles de stratégie :

  • Stratégie de locataire par défaut qui s’applique à toutes les applications ou principaux de service.
  • Stratégies de gestion d’application (application ou principal de service) qui autorisent l’inclusion ou l’exclusion d’applications individuelles de la stratégie par défaut du locataire.

Stratégie de gestion des applications par défaut du locataire

Une stratégie de locataire par défaut est un objet unique qui existe toujours et est désactivé par défaut. Il est défini par la ressource tenantAppManagementPolicy et applique des restrictions sur les objets application et principal de service. Il contient les deux propriétés suivantes :

  • applicationRestrictions permet de cibler les applications appartenant au locataire (objets d’application).
  • servicePrincipalRestrictions autorise le ciblage approvisionné à partir d’un autre locataire (objets de principal de service.

Ces propriétés permettent à un organization de verrouiller l’utilisation des informations d’identification dans les applications qui proviennent de leur locataire et fournissent un mécanisme pour contrôler l’ajout d’informations d’identification dans les applications approvisionnées en externe afin de les protéger contre l’utilisation abusive des informations d’identification. Le propriétaire d’application d’une application multilocataire peut toujours utiliser n’importe quel type d’informations d’identification dans son objet d’application, mais la stratégie protège uniquement le principal de service contre les abus d’informations d’identification.

Stratégie de gestion des applications pour les applications et les principaux de service

Les stratégies de gestion des applications sont définies dans la ressource appManagementPolicy , qui contient une collection de stratégies avec des restrictions ou des dates d’application différentes de celles définies dans la stratégie par défaut du locataire. L’une de ces stratégies peut être affectée à une application ou à un principal de service, en les excluant de la stratégie par défaut du locataire.

Quand la stratégie de locataire par défaut et une stratégie de gestion des applications existent, la stratégie de gestion des applications est prioritaire et l’application ou le principal de service affecté n’hérite pas de la stratégie par défaut du locataire. Une seule stratégie peut être affectée à une application ou à un principal de service.

Remarque

Ni les stratégies de locataire par défaut ni les stratégies de gestion des applications ne bloquent l’émission de jetons pour les applications existantes. Une application qui ne répond pas aux exigences de la stratégie continuera de fonctionner jusqu’à ce qu’elle tente de mettre à jour la ressource pour ajouter un nouveau secret.

Quelles restrictions peuvent être gérées dans Microsoft Graph ?

L’API de stratégie des méthodes d’authentification d’application offre les restrictions suivantes :

Nom de la restriction Description Exemples
passwordAddition Limitez complètement les secrets de mot de passe sur les applications. Bloquez les nouveaux mots de passe sur les applications créées à compter du « 01/01/01/2019 ».
passwordLifetime Appliquez une plage de durée de vie maximale pour un secret de mot de passe. Limitez tous les nouveaux secrets de mot de passe à un maximum de 30 jours pour les applications créées après le 01/01/2015.
customPasswordAddition Restreindre un secret de mot de passe personnalisé sur l’application ou le principal de service. Restreindre tous les nouveaux secrets de mot de passe personnalisés sur les applications créées après le 01/01/2015.
symmetricKeyAddition Restreindre les clés symétriques sur les applications. Bloquer les nouvelles clés symétriques sur les applications créées à compter du 01/01/2019.
symmetricKeyLifetime Appliquez une plage de durée de vie maximale pour une clé symétrique. Limitez toutes les nouvelles clés symétriques à un maximum de 30 jours pour les applications créées après le 01/01/2019.
asymmetricKeyLifetime Appliquer une plage de durée de vie maximale pour une clé asymétrique (certificat). Limitez toutes les nouvelles informations d’identification de clé asymétrique à un maximum de 30 jours pour les applications créées après le 01/01/2019.

Remarque

Toutes les restrictions de durée de vie sont exprimées au format de durée ISO-8601 (par exemple : P4DT12H30M5S). La restriction customPasswordAddition bloque tous les modules PowerShell hérités qui fournissent un secret de mot de passe généré par le client pour les applications. Cette restriction permet toujours au développeur d’applications de demander Microsoft Entra ID secrets de mot de passe d’application générés.

Applications monolocataires ou multilocataires

Selon que votre application est une application monolocataire ou multilocataire, vous appliquez la stratégie sur une application ou sur l’objet principal de service comme suit :

  • Pour les applications monolocataires, appliquez la stratégie à l’objet application.
  • Pour restreindre les applications multilocataires hébergés dans un locataire client, appliquez la stratégie à l’objet d’application.
  • Pour limiter les applications multilocataires approvisionnées à partir d’un autre locataire, appliquez la stratégie à l’objet principal de service.

Résumé des principales différences entre la stratégie de locataire par défaut et les stratégies de gestion des applications

Stratégie par défaut du locataire Stratégie de gestion des applications
La stratégie existe toujours. Les objets de stratégie peuvent être créés ou mis à jour pour remplacer la stratégie par défaut.
Les restrictions sont désactivées par défaut pour l’application/le fournisseur de services. Autorise la personnalisation pour un locataire unique ou multilocataire (application de stockage dans le locataire d’origine ou les applications approvisionnées).
Autorise une seule définition d’objet de restriction pour toutes les ressources. Autorise la définition de plusieurs objets de stratégie, mais un seul peut être appliqué à une ressource.
Permet de distinguer les restrictions pour les objets d’application et les principaux de service. La stratégie peut être appliquée à une application ou à un objet principal de service.
Applique toutes les restrictions configurées à toutes les applications ou principaux de service. Applique uniquement les restrictions configurées dans la stratégie de ressources à l’application ou au principal de service spécifié, et n’hérite pas de la stratégie par défaut.

Conditions requises

  • Les rôles de Microsoft Entra les moins privilégiés pour la gestion des stratégies de méthode d’authentification des applications sont Administrateur d’application et Administrateur d’application cloud.
  • Toutes les opérations de gestion des stratégies d’application nécessitent une licence ID de charge de travail Microsoft Entra Premium.

Prochaines étapes