Autorisations héritantes et accès aux ressources requis dans Identifiant d’assistant Microsoft Entra

Lorsque vous générez un blueprint d’identité d’agent, il existe deux configurations liées aux autorisations clés : l’accès aux ressources requis et les autorisations pouvant être héritées. Ces configurations fonctionnent ensemble pour définir ce dont un agent a besoin, ce que les administrateurs examinent lors du consentement, et comment les autorisations sont attribuées aux identités des agents.

Comprendre la relation entre ces configurations et leur impact sur l’autorisation est essentielle pour les développeurs qui conçoivent des blueprints d’agent et les administrateurs qui intègrent des agents dans leurs organisations.

Accès aux ressources requis

L’accès aux ressources requis correspond à la déclaration initiale, dans le modèle d’identité d’agent, des API et des autorisations nécessaires au fonctionnement des identités d’agent enfants du modèle. Elle est exprimée sous la forme d’un ensemble d’applications de ressources cibles et des étendues déléguées et rôles d’application spécifiques demandés par l’agent.

L’accès aux ressources requis sert de liste d’autorisations de consentement statiques de l’agent. Lorsqu’un administrateur client examine l’agent pour approbation, cette liste rend la décision de consentement explicite et modifiable. Il répond à la question suivante : « Qu'est-ce dont cet agent a besoin pour fonctionner ? »

Le consentement dynamique peut toujours accorder des autorisations héritées lorsque l’autorisation est explicitement demandée et que l’application de ressource est configurée comme héritable. Toutefois, les autorisations demandées dynamiquement ne sont pas visibles avant, sauf si elles sont également déclarées dans l’accès aux ressources requis.

Caractéristiques clés de l’accès aux ressources requis :

  • Déclare le jeu d’autorisations de référence dont l’agent a besoin pour son expérience initiale.
  • Est visible par les administrateurs clients pendant le processus de consentement et d’intégration.
  • Déclaration, et non octroi d’autorisations. L’autorisation nécessite le consentement de l’administrateur.

Autorisations pouvant être héritées

Les autorisations héritées sont une liste d’applications de ressources configurées sur un blueprint d’identité d’agent qui définit les autorisations qui peuvent être héritées automatiquement par les identités d’agent créées à partir de ce blueprint. Lorsqu’un administrateur accorde des autorisations au principal du blueprint d’identité de l’agent et que ces autorisations proviennent d’applications de ressources répertoriées comme héritantes, toutes les identités d’agent présentes et futures créées à partir de ce blueprint dans l’organisation reçoivent automatiquement ces autorisations avec leurs jetons.

Les autorisations héritantes répondent à un défi de déploiement courant : lorsque vous avez plusieurs instances du même agent dans des environnements ou des unités commerciales, vous ne souhaitez pas que les administrateurs acceptent de nouveau les mêmes autorisations sur chaque identité d’agent. Les autorisations héritantes permettent à l’administrateur d’approuver une fois au niveau du blueprint et d’appliquer automatiquement cette approbation.

Deux conditions d’héritage

Pour qu’une permission soit héritée par une identité d’agent, les deux conditions suivantes doivent être respectées :

  • Les étendues de ressources, les rôles, ou les deux, doivent être présents dans la configuration des permissions héritables du modèle d’identité d’agent.
  • L’autorisation doit être accordée avec :
    • consentement statique utilisant l'accès aux ressources requis, ou
    • consentement dynamique avec les autorisations explicitement déclarées sur la demande de consentement.

Si l’une ou l’autre condition est manquante, l’héritage ne se produit pas.

Les autorisations pouvant être héritées sont les suivantes :

Les autorisations héritées sont compatibles avec les deux :

  • Étendues déléguées : apparaissent dans la revendication « scp » du jeton d’accès aux permissions d’application déléguées de l’agent.
  • Rôles d’application : apparaissent dans la revendication roles du jeton de permission d’application de l’agent.

Modèles d’héritage

Les modèles suivants sont pris en charge par application de ressource :

Modèle Description
Tous autorisés Héritez de toutes les étendues déléguées ou rôles d’application disponibles pour l’application de ressource spécifiée. Les nouvelles étendues ou les nouveaux rôles accordés au principal du modèle sont automatiquement inclus.
Aucune N'héritez d'aucune étendue ni de rôles pour l'application ressource spécifiée. Utilisez ce modèle afin de désactiver explicitement l’héritage des étendues ou des rôles de manière indépendante.

Vous pouvez configurer des étendues et des rôles indépendamment sur la même application de ressources. Par exemple, vous pouvez hériter de toutes les étendues sans hériter d'aucun rôle, ou, inversement, hériter de tous les rôles sans hériter d'aucune étendue.

Déclaration, octroi et héritage

L’accès aux ressources requis et les autorisations pouvant être héritées sont des configurations : elles n’accordent aucune autorisation par eux-mêmes. Il est important de comprendre la distinction entre ce qui est déclaré, ce qui est accordé et ce qui est hérité.

Couche Qu’est-ce que c’est ? Qui le contrôle Effet
Accès aux ressources requis Liste des API et autorisations dont l’agent a besoin pour fonctionner Développeur (sur le plan) Visible par les administrateurs lors de la révision du consentement. N’accorde pas l’accès.
Autorisations pouvant être héritées Liste des applications de ressources éligibles pour l’héritage Développeur (sur le plan) Définit les applications de ressources qui peuvent avoir un flux d’autorisations vers des identités d’agent. N’accorde pas l’accès.
Consentement sur l'élément principal du plan Permissions accordées par un administrateur au principal du modèle dans un locataire. Administrateur d'abonné Octroie une autorisation. Si l’application de ressource est également définie comme héritable, la permission est propagée à toutes les identités d’agent.
Consentement de l’utilisateur ou de l’agent sur l’identité de l’agent Autorisations accordées directement à une identité d’agent spécifique Administrateur d'abonné Accorde l’autorisation pour cette identité d’agent spécifique uniquement.
Autorisations effectives dans le jeton Ensemble fusionné d’autorisations héritées + accordées directement Plateforme (lors de l’émission de jetons) Ce que l’identité d’agent est réellement autorisée à effectuer lors de l’exécution.

Note

Les autorisations héritées ne sont pas visibles en tant qu'autorisations sur les identités d'agent dans le centre d’administration Microsoft Entra ou via Microsoft Graph. Elles ne sont visibles que dans le contenu du jeton au moment de l’exécution. La plateforme fusionne les autorisations héritées et directement accordées pendant l’émission de jetons.

Guide pratique de configuration des autorisations

Utilisez ces règles rapides :

  • Le consentement statique au niveau du modèle dépend de la présence de la permission dans l’accès aux ressources requis.
  • Le consentement dynamique au niveau du blueprint peut fonctionner même si l’autorisation n’est pas dans l’accès aux ressources requis, mais l’autorisation doit être demandée explicitement.
  • L’héritage vers les identités d’agent dépend du fait que l’application de ressource soit configurée comme héritable.
  • La visibilité initiale dépend de la présence de la permission dans l’accès aux ressources requis.
Autorisation requise pour l'accès aux ressources ? L'application de ressources peut-elle être héritée ? Hérité par les identités d’agent ? Visible pour les administrateurs au début ?
Yes Yes Yes Yes
Yes No No Yes
No Yes No No
No No No No
L'autorisation pour l'accès aux ressources est-elle requise ? L'application de ressources est-elle transmissible ? Hérité par des identités d’agent ? Visible pour les administrateurs au début ?
Yes Yes Yes Yes
Yes No No Yes
No Yes Yes No
No No No No

Le consentement direct sur une identité d’agent reste disponible dans tous les cas, mais ces autorisations s’appliquent uniquement à cette identité d’agent spécifique.

Meilleures pratiques

Lorsque vous configurez l’accès aux ressources requis et les autorisations pouvant être héritées pour les blueprints de l’agent, équilibrez la sécurité, la facilité d’utilisation et la scalabilité future.

  • Réduisez les autorisations initiales. Incluez uniquement l’accès aux ressources qui est essentiel pour les fonctionnalités principales de l’agent dans l’accès aux ressources requis. La demande des autorisations inutiles lors de l’installation augmente les frictions et réduit la confiance avec les administrateurs de locataires.

  • Prédéclarer les autorisations futures potentielles. Spécifiez les applications de ressources qui peuvent être nécessaires pour les futures fonctionnalités de l’agent dans la liste des autorisations héritées. Cette transparence permet aux administrateurs d’anticiper les demandes de consentement futures et facilite les déploiements plus lisses entre les environnements.

  • Utilisez des autorisations héritées pour la réutilisation. Utilisez des autorisations héritées pour permettre aux administrateurs d’accorder le consentement une fois au niveau du blueprint et que cette approbation s’applique automatiquement à toutes les identités de l’agent, notamment sur plusieurs déploiements et environnements. Si vous avez besoin d’une autorisation, il est recommandé de rendre son application de ressource héritée afin que les administrateurs n’aient pas à l’accorder individuellement à chaque identité de l’agent.

  • Gardez la gouvernance simple et prévisible. La définition explicite des autorisations requises et qui peuvent être demandées ultérieurement aide les organisations à maintenir un contrôle d’accès clair et à éviter les escalades d’autorisations inattendues.

  • Passez en revue les implications de sécurité. Assurez-vous que les autorisations héritantes n’accordent pas d’accès excessif ou n’exposent pas les ressources sensibles au-delà de ce qui est nécessaire. Auditez régulièrement les listes d’autorisations pour maintenir la conformité et réduire les risques.

Exemple de scénarios

Les scénarios suivants illustrent la façon dont différentes configurations d’autorisation remplissent différents besoins de déploiement.

Scénario 1 : L’agent a des fonctionnalités facultatives qui nécessitent des autorisations ultérieures

Priya crée un agent de support informatique qui répond aux questions d’une base de connaissances. Priya s’attend à ce que les clients activent ultérieurement des actions facultatives telles que la création d’incidents ou la publication dans Teams. Priya laisse l'accès requis aux ressources vide ou minimal. Elle définit les applications de ressources que son agent utilise dans la liste des autorisations héritées. Lorsque son entreprise active une fonctionnalité d’action, l’administrateur accorde une seule fois la permission requise au principal du blueprint, puis cette approbation est réutilisée pour tous les déploiements.

Scénario 2 : L’agent nécessite des autorisations préalables qui doivent être héritées

Mateo crée un agent d'intégration pour les nouveaux employés qui a besoin de l'accès à Microsoft Graph pour lire les profils des utilisateurs et créer des tâches. Mateo répertorie les autorisations Graph de référence dans l’accès aux ressources requis et ajoute également l’application de ressource Graph à la liste des autorisations héritées. Lorsque son entreprise déploie l’agent dans plusieurs unités opérationnelles, la revue administrative reste cohérente : les mêmes permissions sont demandées à chaque fois, et la désignation « héritable » réduit les efforts d’approbation récurrents.

Scénario 3 : L’agent requiert des autorisations qui ne doivent pas être héritées

Lin crée un agent d’opérations privilégié utilisé par une petite équipe d’administrateurs pour effectuer des tâches sensibles. L’agent a besoin d’autorisations à privilèges élevés immédiatement. Lin inclut ceux-ci dans l’accès aux ressources requis, mais intentionnellement ne les ajoute pas à la liste des autorisations héritées. Pour son entreprise, chaque installation nécessite une nouvelle décision d’administration explicite, réduisant ainsi l’étendue des autorisations pour un accès hautement privilégié.

Scénario 4 : L’agent nécessite des autorisations différentes dans différentes organisations

Aisha crée un agent collecteur de preuves de conformité. Certains locataires en ont besoin pour extraire des sources d’audit Microsoft 365 ; d’autres pour extraire des sites SharePoint. Aisha définit un petit ensemble de base pour l'accès aux ressources requises et répertorie la liste complète des ressources possibles dans la liste des autorisations héritées. Chaque organisation accorde uniquement les autorisations qui correspondent à leur architecture, et l’approche héritée réduit les approbations répétées lors du déploiement.

Contenu connexe

  • Last updated on