Authentification et autorisation dans Microsoft Foundry

L’authentification et l’autorisation dans Microsoft Foundry contrôlent la façon dont les principaux prouvent l’identité et obtiennent l’autorisation d’effectuer des opérations. Foundry divise ses opérations en un plan de contrôle (gestion des ressources) et en un plan de données (utilisation en temps d'exécution), chacun avec sa propre authentification et sa surface d'application pour le contrôle d'accès basé sur les rôles (RBAC).

Foundry prend en charge deux méthodes d’authentification : Microsoft Entra ID et les clés API. Microsoft Entra ID active les access conditionnels, les identités managées et le RBAC granulaire. Les clés API restent disponibles pour le prototypage rapide, mais manquent de traçabilité par utilisateur. Cet article compare ces méthodes, mappe les identités aux rôles et décrit les scénarios courants de privilèges minimum.

Important

Utilisez Microsoft Entra ID pour les charges de travail de production afin d’activer l’accès conditionnel, les identités gérées et le RBAC avec privilèges minimaux. Les clés API sont pratiques pour une évaluation rapide, mais fournissent des accès granulaires.

Prerequisites

Un abonnement Azure. Si vous n'en avez pas, créez un compte gratuit.
Ressource Microsoft Foundry avec un sous-domaine custome configuré.
Compréhension des concepts de Azure RBAC.
Pour attribuer des rôles, vous avez besoin du rôle Owner ou Administrateur d'accès utilisateur au niveau de l’étendue appropriée.
(Facultatif) La CLI Azure ou le SDK Azure pour Python installé pour l'authentification programmée.
(Facultatif) Packages Python pour les exemples de code : pip install azure-identity requests

Plan de contrôle et plan de données

Les opérations Azure se répartissent en deux catégories : plan de contrôle et plan de données. Azure sépare la gestion des ressources (plan de contrôle) du runtime opérationnel (plan de données). Par conséquent, vous utilisez le plan de contrôle pour gérer les ressources de votre abonnement et utilisez le plan de données pour utiliser les fonctionnalités exposées par votre instance d’un type de ressource. Pour en savoir plus sur le plan de contrôle et le plan de données, consultez Azure plan de contrôle et plan de données. Dans Foundry, il existe une distinction claire entre les opérations de plan de contrôle et les opérations de plan de données. Le tableau suivant explique la différence entre les deux, la portée dans Foundry, les opérations classiques d’un utilisateur, des exemples d’outils et de fonctionnalités, et la surface d'autorisation pour utiliser chacune d'elles.

Avion	Étendue dans Foundry	Opérations classiques	Exemples d’outils	Surface d’autorisation
Plan de contrôle	Mise en place et configuration des ressources, des projets, du réseau, du chiffrement et des connexions	Créer ou supprimer des ressources, attribuer des rôles, faire pivoter des clés, configurer Private Link	Azure portal, Azure CLI, modèles ARM, Bicep, Terraform	Actions RBAC Azure
Plan de données	Exécution et utilisation de l'inférence de modèle, des interactions des agents, des tâches d'évaluation et des appels de sécurité du contenu	Achèvement de conversation, génération d'embeddings, lancement des tâches de fine-tuning, envoi de messages par l'agent, opérations de l'analyseur et du classifieur	SDK, API REST, espace de test du portail Foundry	dataActions RBAC Azure

Pour tous les exemples Bicep, Terraform et SDK, consultez le référentiel foundry-samples sur GitHub pour Foundry.

Les listes et diagrammes suivants illustrent la séparation entre les actions du plan de contrôle et du plan de données en détail. Les actions du plan de commande au sein de Foundry sont les suivantes :

Création de ressources Foundry
Création de projet Foundry
Création de la fonctionnalité d'hôte de compte
Création d’un hôte de fonctionnalité de projet
Déploiement de modèle
Création de connexion de compte et de projet

Les actions de plan de données dans Foundry sont les suivantes :

Création d’assistants
Exécution d’une évaluation
Suivi et surveillance
Fine-tuning

Le diagramme suivant montre la vue de la séparation entre le plan de contrôle et le plan de données dans Foundry, ainsi que les attributions du contrôle d'accès basé sur les rôles (RBAC) et l'accès dont un utilisateur peut disposer dans le plan de contrôle, le plan de données, ou les deux. Comme indiqué dans le diagramme, les « actions » RBAC sont associées au plan de contrôle, tandis que les « dataActions » RBAC sont associées au plan de données.

Méthodes d’authentification

Foundry prend en charge les Microsoft Entra ID (basées sur des jetons, sans clé) et les clés API.

Microsoft Entra ID

Microsoft Entra ID utilise des jetons porteurs OAuth 2.0 limités à https://ai.azure.com/.default.

Utilisez Microsoft Entra ID pour :

Charges de travail de production.
Access conditionnel, authentification multifacteur (MFA) et access juste-à-temps.
Intégration du RBAC à moindre privilège et de l’identité managée.

Avantages : affectations de rôles précises, audit par principal, durées de vie des jetons contrôlables, hygiène secrète automatique et identités managées pour les services.

Limitations : complexité de configuration initiale plus élevée. Nécessite une compréhension du contrôle d'accès basé sur les rôles (RBAC). Pour plus d’informations sur RBAC dans Foundry, consultez contrôle d'accès basé sur les rôles pour Microsoft Foundry.

Clés API

Les clés API sont des secrets statiques délimités à une ressource Foundry.

Utilisez des clés API pour :

Prototypage rapide.
Environnements de test isolés où la rotation à secret unique est acceptable.

Avantages : simple, indépendant du langage et ne nécessite pas d’acquisition de jetons.

Limitations : Impossible d’exprimer l’identité de l’utilisateur, est difficile à étendre de manière granulaire et est plus difficile à auditer. Généralement non accepté par les charges de travail de production d’entreprise et non recommandés par Microsoft.

Pour plus d’informations sur l’activation de l’authentification sans clé, consultez Authentification sans clé avec Microsoft Entra ID.

S’authentifier avec Microsoft Entra ID (Python)

L’exemple suivant montre comment s’authentifier avec Microsoft Entra ID à l’aide de la bibliothèque azure-identity et effectuer une demande à un point de terminaison Foundry :

from azure.identity import DefaultAzureCredential
import requests

# Create a credential object using DefaultAzureCredential
# This automatically uses environment variables, managed identity, or Azure CLI credentials
credential = DefaultAzureCredential()

# Get an access token for the Cognitive Services scope
token = credential.get_token("https://ai.azure.com/.default")

# Use the token in your API request
headers = {
    "Authorization": f"Bearer {token.token}",
    "Content-Type": "application/json"
}

# Replace with your Foundry endpoint
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

# Example: List deployments (adjust the path for your specific API)
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

Sortie attendue : une réponse JSON répertoriant vos déploiements de modèle ou une erreur d’authentification si les informations d’identification sont manquantes ou si l’attribution de rôle n’est pas configurée.

Reference : DefaultAzureCredential | azure-identity library

S’authentifier avec une clé API (Python)

L’exemple suivant montre comment s’authentifier à l’aide d’une clé API. Utilisez cette approche pour le prototypage rapide uniquement ; Microsoft Entra ID est recommandé pour la production.

import requests

# Replace with your actual API key and endpoint
api_key = "<your-api-key>"
endpoint = "https://<your-resource-name>.cognitiveservices.azure.com"

headers = {
    "api-key": api_key,
    "Content-Type": "application/json"
}

# Example: List deployments
response = requests.get(f"{endpoint}/openai/deployments?api-version=2024-10-21", headers=headers)
print(response.json())

Avertissement

Les clés API fournissent un accès complet à la ressource et ne peuvent pas être attribuées à des utilisateurs ou des actions spécifiques. Faites régulièrement pivoter les clés et évitez de les valider dans le contrôle de source.

Sortie attendue : une réponse JSON répertoriant vos déploiements de modèle ou une erreur 401 si la clé API n’est pas valide.

Reference : Faire tourner la clé d'accès API

Matrice de prise en charge des fonctionnalités

Consultez la matrice suivante pour comprendre les fonctionnalités dans Foundry prenant en charge la clé API par rapport à Microsoft Entra ID.

Capacité ou fonctionnalité	Clé API	Microsoft Entra ID	Remarques
Inférence de modèle basique (conversation, intégrations)	Oui	Oui	Entièrement pris en charge.
Opérations de réglage précis	Oui	Oui	Entra ID ajoute un audit par principal.
Service des agents	Non	Oui	Utilisez Entra ID pour accéder à l’outil d'identité managée.
Evaluations	Non	Oui	Utilisez l’ID Entra.
Analyse de la sécurité du contenu des appels	Oui	Oui	Utilisez RBAC pour limiter les opérations à haut risque.
Travaux d’analyse par lots (Content Understanding)	Oui	Oui	ID Entra recommandé pour la mise à l’échelle.
Utilisation du terrain de jeu du portail	Oui	Oui	Playground utilise le mode de connexion par projet.
Isolation réseau avec Private Link	Oui	Oui	Entra ID ajoute l'accès conditionnel.
Principe du moindre privilège avec des rôles intégrés et personnalisés	Non	Oui	Les clés sont tout ou rien pour chaque ressource.
Identité managée (système ou affectée par l’utilisateur)	Non	Oui	Active l’authentification sans secret.
Attribution de l’utilisateur par demande	Non	Oui	Le jeton comporte des ID d’abonné et d’objet.
Révocation (immédiate)	Faire pivoter la clé	Supprimer le rôle ou désactiver le compte principal	Une courte durée de vie du jeton s’applique.
Prise en charge dans les pipelines d’automatisation	Oui (secret)	Oui (principal de service ou identité managée)	Entra ID réduit la rotation des secrets.
API Assistants	Oui	Oui	Recommandé d’utiliser l’ID Entra.
Inférence par lot	Oui	Oui

Types d'identités

Azure ressources et applications s’authentifient à l’aide de différents types d’identités, chacun conçu pour des scénarios spécifiques. Les principaux utilisateurs représentent des utilisateurs humains, les principaux de service représentent des applications ou des processus automatisés, et les identités gérées offrent un moyen sécurisé et sans références d'identification pour les ressources Azure afin d'accéder à d'autres services. La compréhension de ces distinctions vous aide à choisir l’identité appropriée pour les connexions interactives, la communication d’application à application ou l’automatisation de la charge de travail.

Azure prend en charge les types d’identité suivants.

Type d'identité	Descriptif
Utilisateur principal	Utilisateur individuel dans Microsoft Entra ID
Principal de service (inscription d’application)	Identité d’application qui utilise une clé secrète client ou un certificat
Identité managée (affectée par le système)	Identité liée aux ressources Azure, gérée automatiquement par la plateforme.
Identité managée (affectée par l’utilisateur)	Identité autonome qui s’attache à plusieurs ressources.

Vue d’ensemble des rôles intégrés

Dans Foundry, utilisez les rôles intégrés pour séparer les actions autorisées pour un utilisateur. La plupart des entreprises souhaitent séparer les actions de contrôle et de plan de données pour leurs rôles intégrés. D’autres s’attendent à ce qu’un rôle de plan de contrôle et de données combiné réduise le nombre d’attributions de rôles requises. Le tableau suivant répertorie les scénarios et les rôles Foundry prédéfinis correspondants qui conviennent le mieux à chaque scénario.

Scénario	Rôles intégrés classiques	Remarques
Générer des agents avec des modèles prédéployés	utilisateur IA Azure	Utilisation du plan de données uniquement ; aucune écriture de gestion.
Gérer les déploiements ou ajuster les modèles	Azure Chef de Projet IA	Inclut la création et la mise à jour du déploiement de modèle.
Faire pivoter des clés ou gérer une ressource	propriétaire du compte IA Azure	Privilège élevé ; envisagez un rôle personnalisé pour un privilège minimal.
Administrez les ressources, gérez les déploiements et créez des agents.	Responsable de l'IA Azure	Rôle d'auto-administration hautement privilégié pour les utilisateurs qui ont besoin à la fois d'un accès au Plan de Contrôle et au Plan de Données. Combinez avec Azure Monitor Reader si l'observabilité est requise.
Observabilité, suivi, surveillance	Azure IA Utilisateur (minimum)	Ajoutez Lecteur Azure Monitor dans Application Insights.

Pour comprendre la répartition des rôles intégrés et des actions de contrôle et de plan de données, passez en revue le diagramme suivant.

Conseil / Astuce

Créez un rôle personnalisé si un rôle intégré accorde des autorisations excédentaires pour votre cas d’usage.

Configurer Microsoft Entra ID

Pour obtenir des conseils généraux sur la configuration de l’authentification Entra ID dans Foundry, consultez Configurer l’authentification sans clé.

Vérifiez que votre ressource Microsoft Foundry a un sous-domaine personnalisé configuré. Consultez les sous-domaines personnalisés . Un sous-domaine personnalisé est requis pour l’authentification basée sur les jetons.
Attribuez le rôle intégré ou personnalisé nécessaire à chaque principal. Vous avez besoin du rôle Owner ou Administrateur Accès Utilisateur au niveau de l’étendue cible pour pouvoir attribuer des rôles. Attributions de rôles courantes :
- Azure utilisateur IA : pour les développeurs qui doivent générer et tester avec des modèles prédéployés.
- Azure AI Project Manager : pour les responsables d’équipe qui doivent créer des projets et gérer des déploiements.
- Propriétaire de compte Azure AI : pour les administrateurs qui ont besoin d’une gestion complète des ressources et peuvent attribuer Utilisateur Azure AI pour l’accès au plan de données.
- Responsable Azure AI : pour les utilisateurs qui ont besoin à la fois d'une gestion complète des ressources et d'un accès au plan de données. Exemple de commande CLI pour affecter le rôle d’utilisateur IA Azure :
```
az role assignment create \
  --assignee <principal-id> \
  --role "Azure AI User" \
  --scope /subscriptions/<subscription-id>/resourceGroups/<resource-group>/providers/Microsoft.CognitiveServices/accounts/<resource-name>
```
Pour vérifier l’attribution de rôle, exécutez az role assignment list --assignee <principal-id> --scope <resource-scope> et confirmez que celui-ci apparaît dans la sortie.
(Facultatif) Pour un principal de service, créez une inscription d’application, ajoutez une clé secrète client ou un certificat, puis notez l’ID d’abonné, l’ID client et la clé secrète ou le certificat.
(Facultatif) Pour une identité managée, activez l’identité affectée par le système sur le service appelant ou attachez une identité affectée par l’utilisateur, puis attribuez-lui un rôle sur la ressource Foundry.
Supprimez l’authentification basée sur des clés après que tous les appelants utilisent l’authentification par jeton. Désactivez éventuellement l’authentification locale dans les modèles de déploiement.

Reference : Assigner des rôles Azure | Contrôle d'accès basé sur les rôles pour Foundry

Résoudre les erreurs d’authentification courantes

Erreur	La cause	Résolution
401 Non autorisé	Jeton manquant ou expiré ; Clé API non valide	Vérifiez que l’étendue d’acquisition de jeton est `https://ai.azure.com/.default`. Régénérez la clé API si vous utilisez l’authentification basée sur des clés.
403 Interdit	Attribution de rôle RBAC manquante	Attribuez le rôle intégré approprié (par exemple, Azure AI User) à la ressource ou à l'étendue du projet.
AADSTS700016	Application introuvable dans le locataire	Vérifiez que l’inscription de l’application existe dans le bon locataire et que l’ID client est correct.
Sous-domaine personnalisé requis	La ressource utilise un point de terminaison régional au lieu d’un sous-domaine personnalisé	Configurez un sous-domaine custome sur la ressource Foundry. L’authentification basée sur un jeton nécessite un sous-domaine personnalisé.

Commentaires

Est-ce que cette page vous a été utile?

Last updated on 2026-03-11