Contrôle d’accès en fonction du rôle pour Microsoft Foundry

Dans cet article, vous allez découvrir les principaux concepts de contrôle d’accès en fonction du rôle (RBAC) pour Microsoft Foundry, notamment les étendues, les rôles intégrés et les modèles d’affectation d’entreprise courants.

Pour plus d’informations sur l’authentification et l’autorisation dans Microsoft Foundry, consultez Authentication et autorisation.

Attributions de rôles minimales pour commencer

Pour les nouveaux utilisateurs d'Azure et de Microsoft Foundry, commencez par ces affectations de base afin que votre principal de l'utilisateur et votre identité managée pour le projet puissent tous deux accéder aux fonctionnalités de Foundry.

Vous pouvez vérifier les affectations actuelles à l’aide de vérifier l'accès d'un utilisateur à une ressource Azure unique.

• Attribuez le rôle Utilisateur Foundry sur votre ressource Foundry à votre principal d’utilisateur.

  Important

  Les rôles Foundry RBAC ont été récemment renommés. Foundry User, Foundry Owner, Propriétaire du compteFoundry et Foundry Project Manager ont été précédemment nommés Azure utilisateur IA, Azure propriétaire d’IA, propriétaire Azure compte IA et Azure gestionnaire Project IA. Il se peut que vous voyiez encore les anciens noms à certains endroits pendant le déploiement de ce changement de nom. Les ID de rôle et les autorisations de base ne sont pas modifiés par ce changement de nom.

• Attribuez le rôle Utilisateur Foundry sur votre ressource Foundry à l’identité managée de votre projet.

Si l’utilisateur qui a créé le projet peut attribuer des rôles (par exemple, en ayant le rôle propriétaire Azure dans l’étendue de l’abonnement ou du groupe de ressources), les deux affectations sont ajoutées automatiquement lorsque le projet est créé via l’interface utilisateur du portail Microsoft Foundry.

Pour attribuer ces rôles manuellement, suivez les étapes rapides suivantes.

Attribuer un rôle à votre utilisateur principal

Dans le portail Azure, ouvrez votre ressource Foundry et accédez à Access control (IAM). Créez une attribution de rôle pour Foundry User, définissez Membres sur Utilisateur, groupe ou principal de service, sélectionnez votre principal d’utilisateur, puis sélectionnez Vérifier + affecter.

Attribuer un rôle à l’identité managée de votre projet

Dans le portail Azure, ouvrez votre projet Foundry et accédez à Access control (IAM). Créez une attribution de rôle pour Foundry User, définissez Membres sur Identité managée, sélectionnez l’identité managée de votre projet, puis sélectionnez Vérifier + affecter.

Terminologie pour le contrôle d’accès en fonction du rôle dans Foundry

Pour comprendre le contrôle d’accès en fonction du rôle dans Microsoft Foundry, tenez compte de deux questions pour votre entreprise.

• Quelles sont les autorisations que mon équipe doit avoir lors de la génération dans Microsoft Foundry ?
• À quelle étendue dois-je attribuer des autorisations à mon équipe ?

Pour répondre à ces questions, voici des descriptions de certaines terminologies utilisées dans cet article.

• Autorisations : actions autorisées ou refusées qu’une identité peut effectuer sur une ressource, comme la lecture, l’écriture, la suppression ou la gestion des opérations de plan de contrôle et de plan de données.
• Scope : ensemble de ressources Azure auxquelles une attribution de rôle s’applique. Les étendues classiques incluent l’abonnement, le groupe de ressources, la ressource Foundry, le projet Foundry ou un agent individuel.
• Role : collection nommée d’autorisations qui définit les actions qui peuvent être effectuées sur Azure ressources dans une étendue donnée.

Une identité obtient un rôle avec des autorisations spécifiques dans une étendue sélectionnée en fonction des besoins de votre entreprise.

Dans Microsoft Foundry, tenez compte des étendues suivantes lors de l’achèvement des attributions de rôles.

• ressource Foundry : étendue de niveau supérieur qui définit la limite d’administration, de sécurité et de surveillance d’un environnement Microsoft Foundry.
• Projet Foundry : sous-étendue au sein d’une ressource Foundry utilisée pour organiser le travail et appliquer le contrôle d’accès pour les API, outils et flux de travail des développeurs Foundry.
• Agent : étendue plus étroite au sein d’un projet Foundry qui s’applique à un agent individuel. Les attributions de rôles dans cette étendue sont actuellement évaluées uniquement pour l’accès au point de terminaison de l’agent. Utilisez cette étendue pour accorder l’accès aux points de terminaison d’un agent spécifique sans accorder l’accès au point de terminaison à tous les agents du projet. Pour plus d’informations, consultez Attributions de rôles au niveau de l’agent.

Rôles intégrés

Un rôle intégré dans Foundry est un rôle créé par Microsoft qui couvre les scénarios d’accès courants que vous pouvez affecter aux membres de votre équipe. Les rôles intégrés clés utilisés dans Azure incluent Propriétaire, Contributeur et Lecteur. Ces rôles ne sont pas spécifiques aux autorisations de ressources Foundry.

Pour les ressources Foundry, utilisez des rôles intégrés supplémentaires pour suivre le principe du moindre privilège. Le tableau suivant répertorie les rôles intégrés clés pour Foundry et les liens vers les définitions de rôles exactes dans AI + Machine Learning rôles intégrés.

Pour plus d’informations sur l’attribution d’un rôle à un agent donné, consultez Attributions de rôles au niveau de l’agent.

Autorisations pour chaque rôle intégré

Utilisez le tableau suivant pour afficher les autorisations autorisées pour chaque rôle intégré dans Microsoft Foundry.

Utilisez le tableau suivant pour voir les autorisations accordées pour chaque rôle clé intégré d'Azure (Propriétaire, Contributeur, Lecteur).

Pour publier des agents, vous avez besoin du rôle Foundry Project Manager (minimum) dans l’étendue de la ressource Foundry. Pour plus d’informations, consultez Applications d'agent dans Microsoft Foundry.

Utilisez ces onglets pour explorer les différences entre les rôles intégrés, attribués au niveau de la ressource Foundry (à l’exception du propriétaire, qui est affecté au niveau de l’abonnement)

Exemples de mappages RBAC d’entreprise pour les projets

Voici un exemple d’implémentation du contrôle d’accès en fonction du rôle (RBAC) pour une ressource Foundry d’entreprise.

Gérer les attributions de rôles

Pour gérer les rôles dans Foundry, vous devez avoir l’autorisation d’attribuer et de supprimer des rôles dans Azure. Le rôle Azure intégré Owner inclut cette autorisation. Vous pouvez attribuer des rôles via le portail Foundry (volet Gérer), Azure portail IAM ou Azure CLI. Vous pouvez supprimer des rôles à l’aide Azure portail IAM ou Azure CLI.

az role assignment create --role "53ca6127-db72-4b80-b1b0-d745d6d5456d" --assignee "joe@contoso.com" --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/this-rg 

PROJECT_SCOPE="/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.CognitiveServices/accounts/<accountName>/projects/<projectName>"

az role assignment create \
    --assignee-object-id "<principalId>" \
    --assignee-principal-type ServicePrincipal \
    --role "eed3b665-ab3a-47b6-8f48-c9382fb1dad6" \
    --scope "$PROJECT_SCOPE"

Attributions de rôles à portée de l’agent

Attribuez des rôles à l’étendue d’un agent spécifique plutôt qu’à l’ensemble du projet. Cette approche vous permet d’accorder l’accès au point de terminaison à un seul agent sans accorder l’accès au point de terminaison à tous les agents du projet. L’URI de portée d’un agent suit le modèle suivant :

/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.CognitiveServices/accounts/<accountName>/projects/<projectName>/agents/<agentName>

Par exemple, la commande suivante attribue le rôle Consommateur d'agents Foundry (ID de définition de rôle eed3b665-ab3a-47b6-8f48-c9382fb1dad6) à un principal de service à l'étendue d'un agent spécifique.

AGENT_SCOPE="/subscriptions/<subscriptionId>/resourceGroups/<resourceGroupName>/providers/Microsoft.CognitiveServices/accounts/<accountName>/projects/<projectName>/agents/<agentName>"

az role assignment create \
    --assignee-object-id "<principalId>" \
    --assignee-principal-type ServicePrincipal \
    --role "eed3b665-ab3a-47b6-8f48-c9382fb1dad6" \
    --scope "$AGENT_SCOPE"

Les mécanismes d’attribution des rôles pour les portées de l’agent suivent le même modèle RBAC Azure que les attributions au niveau du projet. Tout rôle pouvant être attribué au niveau du projet peut également être attribué au niveau de l’agent. Toutefois, au niveau de l’étendue de l’agent, les attributions de rôles sont actuellement évaluées uniquement pour l’accès au point de terminaison de l’agent et n’accordent pas d’autorisations de gestion ou de plan de contrôle plus larges.

Créer des rôles personnalisés pour les projets

Si les rôles intégrés ne répondent pas aux exigences de votre entreprise, créez un rôle personnalisé qui permet un contrôle précis sur les actions et les étendues autorisées. Voici un exemple de définition de rôle personnalisé au niveau de l’abonnement :

{
  "properties": {
    "roleName": "My Enterprise Foundry User",
    "description": "Custom role for Foundry at my enterprise to only allow building Agents. Assign at subscription level.",
    "assignableScopes": ["/subscriptions/<your-subscription-id>"],
    "permissions": [ { 
        "actions": ["Microsoft.CognitiveServices/*/read", "Microsoft.Authorization/*/read", "Microsoft.CognitiveServices/accounts/listkeys/action","Microsoft.Resources/deployments/*"], 
        "notActions": [], 
        "dataActions": ["Microsoft.CognitiveServices/accounts/AIServices/agents/*"], 
        "notDataActions": []     
    } ]
  }
}

Pour plus d’informations sur la création d’un rôle personnalisé, consultez les articles suivants.

• portail Azure
• Service de contrôle d’accès Azure (CLI)
• Azure PowerShell
• Désactiver les fonctionnalités d’aperçu dans Microsoft Foundry. Cet article fournit plus d’informations sur les autorisations spécifiques dans Foundry sur le plan de contrôle et de données que vous pouvez utiliser lors de la création de rôles personnalisés.

Notes et limitations

• Pour afficher et vider les comptes Foundry supprimés, vous devez avoir le rôle Contributeur affecté à l’étendue de l’abonnement.

• Les utilisateurs disposant du rôle Contributeur peuvent déployer des modèles dans Foundry.

• Vous avez besoin du rôle Propriétaire sur l’étendue d’une ressource pour créer des rôles personnalisés dans la ressource.

• Si vous disposez des autorisations d’attribution de rôle dans Azure (par exemple, le rôle Propriétaire attribué sur l’étendue du compte) à votre principal d’utilisateur et que vous déployez une ressource Foundry à partir du portail Azure ou de l’interface utilisateur du portail Foundry, le rôle Utilisateur Foundry est automatiquement affecté à votre principal d’utilisateur. Cette affectation ne s’applique pas lors du déploiement de Foundry à partir du Kit de développement logiciel (SDK) ou de l’interface CLI.

  Important

  Les rôles Foundry RBAC ont été récemment renommés. Foundry User, Foundry Owner, Propriétaire du compteFoundry et Foundry Project Manager ont été précédemment nommés Azure utilisateur IA, Azure propriétaire d’IA, propriétaire Azure compte IA et Azure gestionnaire Project IA. Il se peut que vous voyiez encore les anciens noms à certains endroits pendant le déploiement de ce changement de nom. Les ID de rôle et les autorisations de base ne sont pas modifiés par ce changement de nom.

• Lorsque vous créez une ressource Foundry, les autorisations de contrôle d’accès en fonction du rôle (RBAC) intégrées vous donnent accès à la ressource. Pour utiliser des ressources créées en dehors de Foundry, vérifiez que la ressource dispose d’autorisations qui vous permettent d’y accéder. Voici quelques exemples :

  • Pour utiliser un nouveau compte Stockage Blob Azure, ajoutez l'identité managée de la ressource de compte Foundry au rôle Lecteur de données Blob de ce compte de stockage.
  • Pour utiliser une nouvelle source Recherche Azure AI, ajoutez Foundry aux attributions de rôles Recherche Azure AI.

• Pour affiner un modèle dans Foundry, vous avez besoin des autorisations de plan de données et de plan de contrôle. Le déploiement d’un modèle optimisé relève des autorisations du plan de contrôle. Par conséquent, le seul rôle intégré disposant à la fois des autorisations du plan de données et du plan de contrôle est le rôle Foundry Owner. Si vous préférez, vous pouvez également attribuer le rôle Utilisateur Foundry pour les autorisations de plan de données et le rôle Propriétaire du compte Foundry pour les autorisations du plan de contrôle.

Autorisations spécifiques au type de déploiement

Les sections suivantes couvrent la surface d’autorisation pour des types de déploiement spécifiques. Utilisez-les en même temps que les tables de rôles intégrées dans Autorisations pour chaque rôle intégré lors de la planification des attributions de rôles pour une charge de travail particulière.

Opérations du plan de contrôle du calcul géré

Déploiements de calcul managés (préversion) sont régis par leur propre ensemble d’opérations de fournisseur de ressources Azure sous le fournisseur Microsoft.CognitiveServices. Ces opérations contrôlent qui peut créer, lire, mettre à jour et supprimer un déploiement de calcul managé, et qui peut lire la capacité d’accélérateur disponible et l’utilisation du quota pour un compte Foundry.

Cette section répertorie les cinq opérations de plan de contrôle requises, les rôles intégrés qui les accordent et la façon dont le mappage de rôle à autorisation diffère des déploiements standard (paiement par jeton et PTU).

Opérations requises

Cinq opérations sont nécessaires pour gérer entièrement les déploiements de calcul gérés sur un compte Foundry :

Correspondance entre rôles et autorisations

Le tableau suivant indique quels rôles intégrés confèrent chacune des cinq opérations du plan de contrôle du calcul géré.

Les rôles intégrés à Azure Owner et Contributor autorisent les cinq opérations grâce à leur autorisation d’action générique sur l’abonnement ou le groupe de ressources.

Comparaison : déploiements standard et déploiements de calcul managés

Le périmètre des autorisations du plan de contrôle pour les déploiements de calcul managés est identique à celui des déploiements standard (paiement par jeton et PTU) ; les noms des opérations diffèrent uniquement par le segment de type de ressource (deployments vs managedComputeDeployments, et modelCapacities vs managedComputeCapacities).

Le tableau suivant résume la façon dont la couverture CRUD de chaque rôle compare les deux familles de déploiement :

Attributions de rôles recommandées

Utilisez les points de départ suivants lors de l’attribution d’accès pour ces opérations avec le calcul managé :

• Déployez et exploitez des déploiements de calcul managés : attribuez un contributeur Cognitive Services dans l’étendue du compte Foundry.
• Afficheur en lecture seule pour les déploiements et les quotas : attribuez Cognitive Services User ou Foundry User sur l’étendue du compte Foundry.
• Gérer un projet Foundry sans pouvoir déployer de modèles : attribuez Foundry Project Manager au niveau du compte Foundry. Les chefs de projet peuvent consulter les déploiements et le quota, mais ne peuvent pas les créer ni les supprimer.
• Appeler un déploiement de calcul managé avec Microsoft Entra ID au moment de l’inférence : attribuez Foundry User au niveau de l’étendue du compte Foundry, en plus de tout rôle de plan de contrôle attribué à l’utilisateur (ou sans aucun rôle de plan de contrôle pour les utilisateurs effectuant uniquement de l’inférence).

Pour le flux de travail de déploiement de bout en bout, consultez Déployer des modèles open source avec un calcul managé.

Contenu connexe

• Tâches de rôle élevé dans Microsoft Foundry : exigences de rôle pour toutes les tâches d’administration, notamment l’attribution de rôle et l’infrastructure de l’agent.
• Créez un projet.
• Vérifier l'accès d'un utilisateur à une ressource Azure unique.
• Authentification et autorisation dans Foundry.
• Désactiver les fonctionnalités d’aperçu dans Microsoft Foundry.
• Informations de référence sur les autorisations de l’agent hébergé.

Annexe

Exemples d’isolation d’accès

Chaque organisation peut avoir des exigences d’isolation d’accès différentes en fonction des personnes de l’utilisateur dans leur entreprise. L’isolation de l’accès est la manière dont les utilisateurs de votre entreprise reçoivent des attributions de rôles, qu'il s'agisse d'une séparation des autorisations à l'aide de nos rôles intégrés ou d'un rôle unifié et hautement permissif. Il existe trois options d’isolation d’accès pour Foundry que vous pouvez sélectionner pour votre organisation en fonction de vos exigences d’isolation d’accès.

Aucune isolation d’accès. Cela signifie que dans votre entreprise, vous n’avez pas de conditions de séparation des autorisations entre un développeur, un responsable de projet ou un administrateur. Les autorisations pour ces rôles peuvent être attribuées à l’ensemble des équipes.

Par conséquent, vous devriez...

• Attribuer à tous les utilisateurs de votre entreprise le rôle Foundry Owner sur la portée de la ressource

  Important

  Les rôles Foundry RBAC ont été récemment renommés. Foundry User, Foundry Owner, Propriétaire du compteFoundry et Foundry Project Manager ont été précédemment nommés Azure utilisateur IA, Azure propriétaire d’IA, propriétaire Azure compte IA et Azure gestionnaire Project IA. Il se peut que vous voyiez encore les anciens noms à certains endroits pendant le déploiement de ce changement de nom. Les ID de rôle et les autorisations de base ne sont pas modifiés par ce changement de nom.

Isolation de l’accès partiel. Cela signifie que le responsable de projet de votre entreprise doit être en mesure de développer au sein de projets, ainsi que de créer des projets. Mais vos administrateurs ne doivent pas être en mesure de développer dans Foundry, uniquement de créer des projets et des comptes Foundry.

Par conséquent, vous devriez...

• Accordez à votre administrateur le rôle Propriétaire du compte Foundry à l’échelle de la ressource
• Attribuez le rôle Foundry Project Manager à vos développeurs et chefs de projet sur la ressource

Isolation totale de l’accès. Cela signifie que vos administrateurs, responsables de projets et développeurs disposent d’autorisations claires qui ne se chevauchent pas pour leurs différentes fonctions au sein d’une entreprise.

Par conséquent, vous devriez...

• Attribuez à votre administrateur le rôle Propriétaire du compte Foundry à l’échelle de la ressource
• Accordez à votre développeur le rôle Reader au niveau de la ressource Foundry et le rôle Foundry User au niveau du projet
• Accordez à votre gestionnaire de projet le rôle Gestionnaire de projet Foundry à l’échelle des ressources.
• Accordez aux utilisateurs de votre agent le rôle Consommateur de l’agent Foundry au niveau du projet (ou au niveau de l’agent pour un contrôle agent par agent)

Utiliser des groupes Microsoft Entra avec Foundry

Microsoft Entra ID offre plusieurs façons de gérer l’accès aux ressources, aux applications et aux tâches. En utilisant Microsoft Entra groupes, vous pouvez accorder l’accès et les autorisations à un groupe d’utilisateurs au lieu de chaque utilisateur individuel. Les administrateurs informatiques d’entreprise peuvent créer des groupes Microsoft Entra dans le portail Azure pour simplifier le processus d’attribution de rôle pour les développeurs. Lorsque vous créez un groupe Microsoft Entra, vous pouvez réduire le nombre d’attributions de rôles requises pour les nouveaux développeurs travaillant sur des projets Foundry en affectant au groupe l’attribution de rôle requise sur la ressource nécessaire.

Effectuez les étapes suivantes pour utiliser des groupes Microsoft Entra ID avec Foundry :

1. Créez un groupe Security dans Groups dans le portail Azure.
2. Ajoutez un propriétaire et les principaux d’utilisateur de votre organisation qui ont besoin d’un accès partagé.
3. Ouvrez la ressource cible et accédez au contrôle d’accès (IAM).
4. Attribuez le rôle requis à l’utilisateur, au groupe ou au principal du service, puis sélectionnez le nouveau groupe de sécurité.
5. Sélectionnez Vérifier + affecter afin que l’attribution de rôle s’applique à tous les membres du groupe.

Exemples courants :

• Pour générer des agents, exécuter des traces et utiliser les fonctionnalités principales de Foundry, affectez Foundry User au groupe Microsoft Entra.
• Pour autoriser l’interaction avec les agents sans disposer d’un accès plus étendu au développement, affectez Foundry Agent Consumer au groupe Microsoft Entra.
• Pour utiliser les fonctionnalités de suivi et de surveillance, affectez lecteur sur la ressource Application Insights connectée au même groupe.

Pour en savoir plus sur les groupes Microsoft Entra ID, les prérequis et les limitations, consultez :

• Découvrez les groupes, l’appartenance aux groupes et l’accès dans Microsoft Entra.
• Comment gérer des groupes dans Microsoft Entra.