Comprendre les identités et les autorisations de l’agent
Les agents de Microsoft Security Copilot ont besoin d’une identité pour authentifier et accéder aux ressources lorsqu’ils s’exécutent. L’identité détermine les données que l’agent peut accéder et quelles actions elle peut effectuer. Comprendre le fonctionnement des identités et des autorisations pour les agents est essentiel pour le déploiement et la gestion sécurisés dans votre organisation.
Types d’identités d’agent
Pendant la configuration de l’agent, vous choisissez parmi deux types d’identités.
Identités d’agent (ID microsoft Entra Agent)
Une identité d’agent est une identité dédiée créée spécifiquement pour un agent IA à l’aide de la fonctionnalité d’ID d’agent Microsoft Entra. Ces identités fournissent une identification et une authentification uniques pour les agents IA et aident à relever les principaux défis de sécurité :
- Distinguer les opérations de l’agent IA de celles associées à la main-d'œuvre, aux clients ou aux identités liées aux charges de travail.
- Fournir aux agents un accès adapté entre les systèmes.
- Empêcher les agents d’accéder aux rôles de sécurité les plus critiques.
- Mise à l’échelle de la gestion des identités pour les agents qui peuvent être rapidement créés et supprimés.
Lorsque vous créez une identité d’agent, vous lui accordez uniquement les autorisations spécifiques nécessaires. Les organisations peuvent créer des identités d’agent en masse, appliquer des stratégies cohérentes et mettre les agents hors service sans laisser d’informations d’identification orphelines.
Note
Actuellement, l’option permettant de créer une identité d’agent n’est disponible que pour les agents intégrés à Microsoft.
Compte d’utilisateur existant
Cette option permet à l’agent d’utiliser les informations d’identification d’un utilisateur existant pour s’exécuter. L’agent hérite de l’accès et des autorisations de cet utilisateur tout en étant actif, ce qui signifie qu’il peut accéder aux mêmes données et services que le compte connecté.
Différences entre les identités d’agent et d’autres types d’identités
- Versus identités d’application : les identités d’application (principaux de service) dans Microsoft Entra ID sont conçues pour les services de longue durée avec une propriété stable. Les agents sont souvent créés dynamiquement et peuvent exister uniquement brièvement. Les identités d’agent sont conçues pour cette échelle et cette éphémère, ce qui réduit la complexité opérationnelle de la gestion des systèmes autonomes de courte durée.
- Par rapport aux identités utilisateur humaines : les identités humaines sont liées à des mécanismes d’authentification tels que les mots de passe, l’authentification multifacteur et les clés secrètes, et ont des données associées telles que les boîtes aux lettres et la hiérarchie organisationnelle. Les identités d’agent représentent des systèmes logiciels, pas des êtres humains et n’utilisent pas de mécanismes d’authentification humaine. Toutefois, certains scénarios nécessitent que les agents fonctionnent comme s’ils sont des utilisateurs humains. Pour ces scénarios, les identités d’agent peuvent être associées à des comptes d’utilisateur spéciaux qui gèrent une relation un-à-un avec leur identité d’agent, ce qui assure la compatibilité du système tout en conservant une séparation claire.
Ce que permettent les identités d’agent
Un agent IA peut utiliser son identité pour :
- Accès aux services web : demandez des jetons d’accès à partir de Microsoft Entra pour appeler Microsoft Graph, des services construits par l'organisation, ou des API non-Microsoft.
- Accès autonome : agir indépendamment à l’aide des droits attribués directement à l’identité de l’agent, notamment les autorisations Microsoft Graph, les rôles RBAC Azure et les rôles d’annuaire Microsoft Entra.
- Accès délégué (au nom de l’utilisateur) : agir pour le compte d’un utilisateur humain, en utilisant les droits que l’utilisateur contrôle et délègue. Dans ce flux, l’agent accède aux ressources avec l’identité et les autorisations de l’utilisateur pour récupérer des données ou effectuer des actions que l’utilisateur peut également effectuer.
- Authenticate les messages entrants : acceptez et validez les demandes d’autres clients, utilisateurs ou agents à l’aide de jetons d’accès Microsoft Entra.
Autorisations pour les agents
Les autorisations définissent le niveau d’autorisation qu’un agent reçoit pendant la configuration, ce qui lui permet d’accéder à des informations spécifiques ou d’effectuer ses tâches. Il peut s’agir de lire des données à partir de solutions telles que Microsoft Defender External Attack Surface Management ou Microsoft Threat Intelligence.
Lorsqu’une identité d’agent est créée, les autorisations requises sont attribuées automatiquement. Par exemple, l’Agent d’optimisation de l’accès conditionnel reçoit des autorisations telles que Policy.Read.All, User.Read.Allet RoleManagement.Read.Directory. Les autorisations qu’une identité d’agent reçoit ne peuvent pas être modifiées ou supprimées par les administrateurs. Elles sont limitées à ce que l’agent doit effectuer ses tâches définies.
Sécurisation des identités d’agent
Microsoft Entra étend la plupart des mêmes protections aux identités d’agent qu’elle fournit pour les identités utilisateur :
- Accès conditionnel pour les agents : les organisations peuvent définir et appliquer des stratégies adaptatives qui évaluent le contexte et le risque de l’agent avant d’accorder l’accès aux ressources. Cela inclut l’application de stratégies de contrôle d’accès entre les types de comptes d’utilisateur d’assistance, autonomes et agent, en utilisant des signaux de risque en temps réel pour bloquer les agents compromis et déployer des stratégies à grande échelle à l’aide d’attributs de sécurité personnalisés.
- ID Protection pour les agents : Protection Microsoft Entra ID détecte et bloque les menaces en signalant les activités anormales impliquant des agents, en fournissant des signaux de risque à l’accès conditionnel et en activant la correction automatique des agents compromis.
- Gouvernance des ID pour les agents : les identités d’agent sont introduites dans les mêmes processus de gouvernance que les utilisateurs, ce qui permet la gestion du cycle de vie du déploiement à l’expiration. Les sponsors et les propriétaires peuvent être affectés à chaque identité d'agent, empêchant les agents orphelins, et l'accès peut être limité dans le temps par le biais de paquets d'accès.
Contrôle d’accès en fonction du rôle et agents
RBAC détermine qui peut afficher et gérer les sorties de l’agent dans Security Copilot. La plateforme Security Copilot définit deux rôles :
- Security Copilot propriétaire : configurer des agents, gérer les paramètres, attribuer des autorisations et effectuer toutes les tâches de plateforme. Générez, testez et publiez des agents à l’étendue de l’espace de travail.
- Security Copilot contributeur : exécuter des agents, créer des sessions et interagir avec les sorties de l’agent. Générez, testez et publiez des agents dans le périmètre utilisateur.
Ces rôles sont gérés dans Security Copilot et sont séparés des rôles d’ID Microsoft Entra. Ils contrôlent uniquement l’accès à la plateforme et n’accordent pas l’accès aux données de sécurité par eux-mêmes. Les données auxquelles un agent peut accéder sont toujours régies par les rôles Microsoft Entra et Azure RBAC existants de l’utilisateur . Security Copilot ne dépasse jamais l’accès qu’un utilisateur a déjà.
Certains rôles Microsoft Entra et Microsoft Purview, tels qu'Administrateur global, Administrateur de la sécurité et Administrateur de la conformité, héritent automatiquement de l'accès propriétaire à Security Copilot, ce qui garantit qu'il y ait toujours au moins deux propriétaires de la plateforme.
Autorisations de l’agent partenaire
La configuration d’un agent intégré à un partenaire qui accède aux données de produit Microsoft (telles que Microsoft Intune, Microsoft Entra, Microsoft Sentinel ou Microsoft Defender) nécessite qu’un administrateur général approuve les autorisations requises. Après approbation, les propriétaires et contributeurs de Security Copilot peuvent terminer la configuration de l’agent. Les agents qui n’accèdent pas aux données de produit Microsoft ne nécessitent pas cette approbation.