Accès conditionnel pour les agents

L’accès conditionnel pour les agents est une extension du moteur de stratégie d’accès conditionnel qui contrôle la façon dont les agents accèdent aux ressources protégées par Microsoft Entra ID. Il réunit des signaux en temps réel, tels que le contexte, l’appareil, l’emplacement et les informations sur les risques de l’utilisateur, pour déterminer quand autoriser, bloquer ou limiter l’accès, ou exiger davantage de étapes de vérification.

Comprendre le modèle d’accès de l’agent vous aide à cibler l’identité correcte. Un agent peut agir pour le compte d’un utilisateur connecté, utiliser son propre identité d’agent ou utiliser son propre compte d’utilisateur agent.

En savoir plus sur l’accès conditionnel pour les agents :

• Vue d’ensemble générale de l’accès conditionnel : Qu’est-ce que l’accès conditionnel ?
• Guide de gestion des identités d’agent au sein de votre organisation : gérez les identités d’agent dans votre organisation.
• Guide pratique pour cibler des identités d’agent dans l’accès conditionnel
• Sécuriser des agents autonomes avec accès conditionnel
• Sécuriser les utilisateurs de l’agent avec Accès conditionnel Microsoft Entra

Conditions requises et licences

Microsoft Entra ID l’accès conditionnel pour les agents nécessite l’un des plans de licence suivants :

• Microsoft 365 E7, qui inclut agent 365 et Suite Microsoft Entra.
• licence Microsoft Agent 365 associée à au moins Microsoft Entra P1 ou Microsoft 365 E3.

Pour plus d’informations, consultez les offres et tarifs de Microsoft 365 Agent.

Comment l’accès conditionnel évalue l’accès de l’agent

Pour accéder à une ressource telle qu’un fichier SharePoint, un serveur MCP ou un service Open API, un utilisateur ou un agent demande un jeton d’accès à partir de Microsoft Entra ID.

Lorsqu’une stratégie d’accès conditionnel s’applique, Microsoft Entra ID évalue les exigences de stratégie avant qu’elle n’émet le jeton. Si les exigences sont satisfaites, Microsoft Entra ID émet le jeton. La ressource cible valide le jeton et utilise ses revendications pour prendre des décisions d’autorisation.

Chaque jeton d’accès a un sujet et une audience :

• Objet : identité qui reçoit le jeton.
  • Dans l’accès délégué, le jeton représente l’utilisateur tout en identifiant l’application ou l’agent appelant.
  • Dans l’accès à l’application uniquement, l’identité de l’agent est l’objet.
  • Dans l’accès agent-utilisateur, le compte utilisateur de l’agent est le sujet.
• Audience : ressource cible pour laquelle le jeton doit être inscrit dans Entra ID. Si un objet accède à plusieurs ressources, il a généralement besoin d’un jeton distinct pour chaque ressource.

L’accès conditionnel évalue à la fois l’entité qui tente d’accéder et la ressource à laquelle l’accès est demandé. Elle évalue les stratégies quand Microsoft Entra ID émet ou actualise un jeton d’accès. Certaines ressources prennent également en charge l’évaluation continue de l’accès, ce qui peut déclencher une mise en application quasi en temps réel lors de certains événements spécifiques.

Comment les décisions relatives à l’accès conditionnel sont prises

Les stratégies d’accès conditionnel fonctionnent comme des instructions if-then :

• Si les conditions définies dans une stratégie sont remplies, les contrôles d’accès configurés sont appliqués.
• Si les contrôles requis sont satisfaits, l’accès est accordé.
• Si les contrôles requis ne sont pas satisfaits, l’accès est refusé.

Par exemple, une organisation peut nécessiter une authentification multifacteur avant qu’un utilisateur puisse autoriser un agent à accéder à son e-mail. De même, une organisation peut configurer une stratégie pour bloquer l’accès à partir d’agents identifiés comme présentant un risque élevé.

Quand l’accès conditionnel est évalué

L’accès conditionnel est évalué chaque fois que Microsoft Entra ID émet ou actualise un jeton d’accès. Certaines ressources prennent également en charge l’évaluation continue de l’accès, ce qui peut déclencher une mise en application quasi en temps réel lors de certains événements spécifiques.

Modèles d’accès de l’agent

Les agents peuvent accéder aux ressources protégées par Microsoft Entra à l’aide de l’un des modèles suivants :

Un agent peut utiliser plusieurs modèles d’accès. Créez des stratégies distinctes pour chaque sujet de jeton utilisé par l’agent. Une stratégie qui cible une identité d’agent ne s’applique pas au compte d’utilisateur de l’agent, et une stratégie qui cible le compte d’utilisateur de l’agent ne s’applique pas à l’identité de l’agent.

Agents qui agissent pour le compte d’un utilisateur

Le flux OBO (on-behalf-of) est le modèle d’accès le plus courant. Dans le flux OBO, un utilisateur se connecte à une application agent. L’agent accède aux ressources en aval avec l’identité de l’utilisateur et les autorisations déléguées. Par exemple, lorsqu’un agent lit vos e-mails, il accède à votre boîte aux lettres en votre nom. Pour plus d’informations sur la façon dont fonctionne le flux OBO pour les agents, consultez Flux OAuth pour les agents : On-behalf-of.

Dans ce flux, l’agent ne peut pas réutiliser le jeton d’origine de l’utilisateur, car il a été émis pour un public différent. Au lieu de cela, l’agent utilise le flux OBO pour échanger des jetons avec Microsoft Entra ID afin d’obtenir un nouveau jeton limité à la ressource cible. Cet échange de jetons est également évalué par l’accès conditionnel, ce qui permet aux administrateurs d’appliquer des contrôles granulaires sur les ressources auxquelles les agents peuvent accéder pour le compte de l’utilisateur.

Étant donné que l’utilisateur connecté est le sujet du jeton dans ce flux, l’Accès conditionnel évalue les stratégies affectées à cet utilisateur, que l’utilisateur soit ciblé directement, via un groupe ou via un autre mécanisme de ciblage d’utilisateur pris en charge. La sélection d’une identité d’agent en tant que sujet de stratégie ne couvre pas les demandes d’agent effectuées au nom de l’utilisateur.

Agents qui agissent en tant qu’applications

Les agents peuvent accéder aux ressources sans utilisateur connecté. Dans ce cas, l’agent accède à la ressource avec sa propre identité. Ce flux est également appelé flux d’informations d’identification du client ou accès à l’application uniquement. Tous les types d’agents peuvent utiliser ce flux. Pour plus d’informations sur la façon dont les agents s’authentifient avec leur propre identité, consultez Les flux OAuth de l’agent : applications autonomes.

Ce flux s’applique dans les scénarios courants suivants :

• Les agents autonomes qui fonctionnent indépendamment s’exécutent en arrière-plan, répondent aux événements ou s’exécutent selon une planification.
  • Par exemple, un agent qui génère un rapport quotidien et envoie le résultat à un groupe d’employés.
  • Dans ce scénario, il n’y a aucun utilisateur présent et l’agent fonctionne seul.
• Les agents interactifs qui utilisent leur propre identité n’accèdent pas toujours aux ressources pour le compte d’un utilisateur ; parfois ils utilisent leur propre identité.
  • Par exemple, si un agent appelle un service SMS principal auquel les utilisateurs n’ont pas accès, le flux OBO ne s’applique pas et l’agent s’authentifie directement comme lui-même.
• Les agents publiés sur le web pour une utilisation publique n’authentifient pas l’utilisateur ou ne prennent pas en charge la délégation du contexte de l’utilisateur aux ressources d’entreprise.

Dans ces scénarios, l’agent demande un jeton d’accès à l’aide de ses propres identités d’agent et d’informations d’identification gérées via le blueprint d’identité de l’agent. Le jeton est émis à l’identité de l’agent (et non à l’utilisateur). Par conséquent, les stratégies d’accès conditionnel sont limitées à l’identité de l’agent plutôt qu’à l’utilisateur. Pour obtenir une configuration de stratégie pas à pas, consultez Sécuriser les agents autonomes avec l’accès conditionnel.

Agents qui agissent en tant qu’utilisateurs

Parfois, il n’est pas suffisant qu’un agent effectue des tâches pour le compte d’un utilisateur ou fonctionne avec sa propre identité. Dans certains scénarios, un agent dispose de son propre compte utilisateur d’agent, qui fonctionne comme un travailleur numérique avec sa propre boîte aux lettres, un accès au chat et la capacité de participer à des flux de travail collaboratifs en tant que membre de l’équipe.

Dans ce modèle, un administrateur crée un compte d’utilisateur dans l’annuaire et le lie à l’identité de l’agent. À partir de là, c’est comme n’importe quel autre compte d’utilisateur. Les licences peuvent être affectées pour accéder à des ressources Microsoft 365 telles qu’une boîte aux lettres et un calendrier. Le compte peut être ajouté aux unités administratives et aux groupes de sécurité comme un compte d’utilisateur humain.

Les agents utilisant ce flux sont également considérés comme des agents autonomes, car ils n’impliquent pas d’interface utilisateur pour l’interaction humaine. Dans ce modèle, le jeton d’accès est émis au compte d’utilisateur de l’agent (objet du jeton) et la stratégie est évaluée par rapport au compte d’utilisateur de l’agent, et non à l’identité de l’agent. Pour obtenir une configuration de stratégie pas à pas, consultez l’accès conditionnel pour les agents autonomes. Pour plus d’informations sur le flux OAuth utilisateur de l’agent, consultez Le flux OAuth utilisateur de l’agent.

Les agents s’exécutant sur des points de terminaison gérés tels que des PC cloud Windows 365 pour les agents peuvent également être soumis à des contrôles de réseau conforme et à la conformité des appareils. Utilisez la condition Environnements d’exécution de l’agent (version préliminaire) pour limiter ces stratégies aux seules sessions basées sur les points de terminaison. Pour plus d’informations, consultez Exiger un appareil conforme pour les comptes d’utilisateur des agents.

Stratégies d’accès conditionnel et blueprints d’identité d’agent

Outre les modèles d’accès d’agent spécifiques, vous pouvez également sélectionner des blueprints d’identité d’agent pour appliquer des stratégies d’accès conditionnel à une classe d’agents. Un blueprint d’identité d’agent définit le modèle de configuration et de gouvernance pour les identités d’agent créées à partir de celui-ci. Une stratégie qui cible un blueprint s’applique à toutes les identités d’agent créées à partir de ce blueprint, y compris les identités d’agent créées ultérieurement.

Le diagramme suivant montre que seules les identités d’agent associées au blueprint « A » sont autorisées à accéder ; tous les autres agents sont exclus et bloqués.

Par exemple, imaginez un projet où vous avez plusieurs agents, chacun ayant son propre objectif. Certains fonctionnent indépendamment, tandis que d’autres collaborent avec d’autres agents (A2A) pour effectuer des tâches. S’ils sont tous créés sous le même blueprint, une stratégie unique appliquée à ce blueprint applique des contrôles d’accès cohérents dans l’ensemble de la collection.

Accès conditionnel piloté par les attributs

Au fur et à mesure que le nombre d’identités d’agent augmente, la gestion individuelle de chaque stratégie devient insoutenable. Les attributs de sécurité personnalisés vous permettent de classer les identités et les ressources d’agent avec des étiquettes spécifiques à l’entreprise, puis de cibler ces attributs dans les stratégies d’accès conditionnel. Les stratégies s’appliquent automatiquement à chaque agent avec des attributs correspondants, y compris ceux ajoutés à l’avenir.

Pour obtenir un exemple de stratégie, consultez Autoriser les agents approuvés à l’aide d’attributs de sécurité personnalisés.

Limites et contraintes

Les stratégies d’accès conditionnel ne s’appliquent pas quand :

• Un blueprint d'identité d'agent acquiert un jeton pour Microsoft Graph afin de créer un identité d'agent ou un compte utilisateur d'agent.
  • Les blueprints d’agent ont des fonctionnalités limitées. Ils ne peuvent pas agir indépendamment pour accéder aux ressources et sont uniquement impliqués dans la création d’identités d’agent et de comptes d’utilisateur des agents.
  • Les tâches d'agent sont toujours exécutées par l'identité d'agent.
• Un plan d'identité d'agent ou une identité d'agent effectue un échange de jeton intermédiaire au point de terminaison AAD Token Exchange Endpoint: Public (ID de ressource : fb60f99c-7a34-4190-8149-302f77469936).
  • Les jetons limités au AAD Token Exchange Endpoint: Public ne peuvent pas appeler Microsoft Graph.
  • Les flux d'agent sont protégés car l'accès conditionnel protège l'acquisition de jetons depuis l'identité de l'agent ou le compte utilisateur de l'agent.
• Les valeurs par défaut de sécurité sont activées .
• L’accès conditionnel protège uniquement les ressources sécurisées par Microsoft Entra ID. Par exemple, si un agent accède aux ressources à l'aide d'une clé API, il contourne entièrement le pipeline d'authentification et d'émission de jetons Microsoft Entra ID, et les stratégies d'accès conditionnel ne s'appliquent pas à celles-ci.

Les configurations suivantes ne sont actuellement pas prises en charge :

• Les stratégies délimitées par l’attribution « Utilisateurs » ne s’appliquent pas aux comptes d’utilisateur de l’agent. Cette limite s’applique que la stratégie cible tous les utilisateurs, des utilisateurs sélectionnés, des groupes, des rôles d’annuaire ou des utilisateurs externes. Pour protéger les comptes des utilisateurs d’agent, créez une politique qui cible « Utilisateurs d’agent ».
• Étendue d’une stratégie d’accès conditionnel pour inclure ou exclure le compte d’utilisateur de l’agent en fonction de son appartenance au groupe.
• Une stratégie d’accès conditionnel ciblant les identités d’agent ne s’applique pas au compte d’utilisateur de l’agent.
• Une stratégie d’accès conditionnel ciblant les identités de l’agent à l’aide du blueprint d’identité de l’agent couvre uniquement l’identité de l’agent, et non le compte d’utilisateur de l’agent.

Au lieu de cela, pour appliquer les stratégies aux utilisateurs d’agent, sous Affectations>, sélectionnez Agents, puis ciblez tous les utilisateurs d’agent ou des utilisateurs d’agent spécifiques.

Contenu connexe

• Identités d’agent cible dans les stratégies d’accès conditionnel
• Sécuriser des agents autonomes avec accès conditionnel
• Sécuriser les agents qui agissent en tant qu’utilisateurs disposant d’un accès conditionnel