Vue d’ensemble de l’API des stratégies de gestion des applications Microsoft Entra
Espace de noms: microsoft.graph
Les stratégies de gestion des applications permettent aux administrateurs informatiques d’appliquer les meilleures pratiques relatives à la configuration des applications de leur organisation. 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 permettent d’inclure ou d’exclure des 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 contrôler séparément la configuration des applications qui proviennent de son locataire par rapport à la instance de son locataire d’une application appartenant à l’externe.
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 pour remplacer la stratégie par défaut du locataire.
Lorsque la stratégie de locataire par défaut et une stratégie de gestion des applications définissent la même restriction, la stratégie de gestion des applications est prioritaire. Si une restriction est définie sur une stratégie de gestion des applications dans un disabled état, cette restriction ne s’applique pas aux applications avec cette stratégie liée à celles-ci, indépendamment de ce que la stratégie par défaut du locataire appliquerait normalement. De même, si une restriction est définie sur une stratégie de gestion des applications dans un enabled état, cette restriction s’applique aux applications dont cette stratégie est liée. Toutefois, si la stratégie de gestion des applications ne définit aucun comportement pour une certaine restriction, elle revient au comportement de la stratégie par défaut du locataire. Une seule stratégie de gestion des applications peut être affectée à une application ou à un principal de service.
Remarque
Ni le 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 continue de fonctionner. seule l’opération de création/mise à jour de l’application qui enfreint la stratégie est bloquée.
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. | Limitez tous les nouveaux secrets de mot de passe personnalisés (non générés par Azure AD) 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).
L’application de la restriction customPasswordAddition bloque tous les modules PowerShell hérités qui ajoutent un secret de mot de passe généré par le client aux applications ou aux principaux de service. Cette restriction ne bloque pas Microsoft Entra ID secrets de mot de passe d’application ou de principal de service 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. |
| 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 les restrictions configurées dans la stratégie de ressources à l’application ou au principal de service spécifié. Tout ce qui n’est pas défini hérite de la stratégie par défaut. |
Configuration requise
- 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.