Partager via


L'architecture de Microsoft Foundry

Microsoft Foundry fournit un ensemble complet d’outils pour aider les équipes de développement à créer, personnaliser, évaluer et exploiter des agents IA et les modèles et outils qu’ils utilisent.

Cet article fournit aux équipes informatiques et aux équipes de sécurité des informations détaillées sur la ressource Foundry et l’architecture de service Azure sous-jacente, ses composants et sa relation avec d’autres types de ressources Azure. Utilisez ces informations pour guider la personnalisation de votre déploiement Foundry en fonction des exigences de votre organisation. Pour plus d’informations sur le déploiement de Foundry dans votre organisation, consultez Foundry Rollout.

Azure types de ressources et fournisseurs d’IA

Dans la famille de produits IA Azure, vous pouvez utiliser ces fournisseurs de ressources Azure qui prennent en charge les besoins des utilisateurs dans différentes couches de la pile.

Fournisseur de ressources Objectif Prend en charge les types de ressources
Microsoft.CognitiveServices Prend en charge le développement d’applications Agentic et GenAI qui composent et personnalisent des modèles prédéfinis. Fonderie; Azure OpenAI service ; Azure Speech ; Azure Vision
Microsoft.Search Soutien à la recherche de connaissances sur vos données Azure AI Search

Pour de nombreux scénarios, la ressource Foundry est le point de départ recommandé. Les ressources foundry partagent l’espace de noms du fournisseur Microsoft.CognitiveServices avec des services tels que Azure OpenAI, Azure Speech, Azure Vision et Azure Language. Cet espace de noms de fournisseur partagé permet d’aligner les API de gestion, les modèles access control, la mise en réseau et le comportement de stratégie entre les ressources IA associées.

Type de ressource Fournisseur et type de ressource Type Fonctionnalités prises en charge
Microsoft Foundry Microsoft.CognitiveServices/account AIServices Agents, évaluations, Azure OpenAI, Parole, Vision, Langage et Compréhension de contenu
Projet de fonderie Microsoft.CognitiveServices/account/project AIServices Sous-ressource en relation avec ci-dessus
Azure Speech dans les outils Foundry Microsoft.CognitiveServices/account Speech Speech
Service de Langage Azure dans les outils Foundry Microsoft.CognitiveServices/account Language Language
Azure Vision dans les outils Foundry Microsoft.CognitiveServices/account Vision Vision

Les types de ressources sous les mêmes espaces de noms de fournisseur partagent les mêmes API de gestion et utilisent des actions de contrôle d'accès basé sur un rôle Azure, des configurations réseau et des alias similaires pour la configuration de la stratégie Azure. Si vous effectuez une mise à niveau de Azure OpenAI vers Foundry, vos stratégies de Azure personnalisées existantes et les actions Azure basées sur des rôles Access Control continuent d'être appliquées.

Relation des ressources dans Foundry

Utilisez ce modèle lors de la planification de l'architecture et des limites d'accès :

  • RessourceFoundry : ressource de Azure de niveau supérieur où vous gérez les paramètres de gouvernance tels que la mise en réseau, la sécurité et les déploiements de modèles.
  • Project : limite de développement à l’intérieur de la ressource Foundry où les équipes créent et évaluent les cas d’usage.
  • Ressources du projet : fichiers, agents, évaluations et artefacts connexes attribués à un projet.

Cette séparation permet aux équipes informatiques d’appliquer des contrôles centralisés au niveau des ressources pendant que les équipes de développement travaillent dans les limites des projets.

Séparation des préoccupations axée sur la sécurité

Foundry applique une séparation claire entre les opérations de gestion et de développement pour garantir des charges de travail IA sécurisées et évolutives.

  • Gouvernance des ressources au niveau supérieur : Les opérations de gestion, telles que la configuration de la sécurité, l’établissement d’une connectivité avec d’autres services Azure et la gestion des déploiements, sont limitées à la ressource Foundry de niveau supérieur. Les activités de développement sont isolées dans des conteneurs de projet dédiés, qui encapsulent les cas d'usage et fournissent des limites pour le contrôle d'accès, les fichiers, les agents et les évaluations.

  • Contrôle d’accès basé sur les rôles (RBAC) : les actions RBAC Azure reflètent cette séparation des préoccupations. Les actions de plan de contrôle, telles que la création de déploiements et de projets, sont distinctes des actions de plan de données, telles que la création d’agents, l’exécution d’évaluations et le chargement de fichiers. Vous pouvez définir l’étendue des attributions RBAC au niveau des ressources de haut niveau et au niveau des projets individuels. Affectez des identités gérées à l’une ou l’autre des étendues pour prendre en charge l’automatisation sécurisée et l’accès aux services. Pour plus d’informations, consultez le contrôle d'accès basé sur les rôles pour Microsoft Foundry.

    Les tâches initiales courantes pour l'intégration selon le principe du moindre privilège sont les suivantes :

    • Utilisateur Azure AI pour chaque principal d’utilisateur développeur au niveau de la ressource Foundry.
    • Utilisateur Azure AI pour chaque identité managée de projet dans le périmètre des ressources Foundry.

    Pour obtenir des instructions relatives aux définitions de rôle et à la planification de l'étendue, consultez contrôle d'accès basé sur les rôles pour Microsoft Foundry.

  • Monitoring et Observabilité : Les métriques Azure Monitor sont segmentées par étendue. Vous pouvez afficher les métriques de gestion et d'utilisation au niveau de la ressource de niveau supérieur, tandis que les métriques spécifiques à un projet, telles que les performances d'évaluation ou l'activité de l'agent, sont limitées aux conteneurs individuels de projet.

Infrastructure de calcul

  • L’architecture d’hébergement de modèle est fournie par le déploiement standard dans les ressources Foundry. Pour obtenir une vue d’ensemble des données, de la confidentialité et des considérations relatives à la sécurité avec le déploiement, consultez Données, confidentialité et sécurité pour l’utilisation des modèles.

  • Exécution de la charge de travail : Les agents, les évaluations et les travaux Batch s’exécutent en tant que calcul de conteneur managé, entièrement gérés par Microsoft.

  • Intégration réseau : Pour renforcer la sécurité et la conformité lorsque vos agents se connectent avec des systèmes externes, l’injection de conteneurs permet au réseau de plateforme d’héberger des API et d’injecter un sous-réseau dans votre réseau. Cette configuration permet la communication locale de vos ressources Azure au sein du même virtual network.

    Si vous avez besoin d’une isolation réseau de bout en bout, passez en revue les limitations actuelles avant le déploiement. Dans la nouvelle expérience du portail Foundry, les scénarios d’isolation de bout en bout ne sont pas entièrement pris en charge. Utilisez l’expérience classique, le Kit de développement logiciel (SDK) ou l’interface CLI pour les déploiements isolés du réseau. Pour plus d’informations, consultez How to configure a private link for Foundry.

Storage de données

Foundry fournit des options de storage de données flexibles et sécurisées pour prendre en charge un large éventail de charges de travail IA.

  • Managed storage pour le chargement de fichiers : Dans la configuration par défaut, Foundry utilise des comptes gérés par Microsoft storage qui sont séparés logiquement et prennent en charge les chargements directs de fichiers pour certains cas d’usage, tels que les modèles OpenAI, les Assistants et les Agents, sans nécessiter de compte storage fourni par le client.

  • Bring your own storage (optional) : Les utilisateurs peuvent éventuellement connecter leurs propres comptes Azure Storage. Les outils de fonderie peuvent lire les entrées de ces comptes et y écrire les sorties, selon l'outil et le cas d'utilisation.

  • Apportez votre propre stockage pour enregistrer l'état de l'Agent :

    • Dans la configuration de base, le service Agent stocke les threads, les messages et les fichiers dans les storage multilocataire gérés par Microsoft, avec séparation logique.
    • Avec la configuration standard Agent, vous pouvez apporter votre propre storage pour les données de thread et de message. Dans cette configuration, les données sont isolées par project dans le compte storage du client.
  • Chiffrement de clé gérée par le client : par défaut, les services Azure utilisent des clés de chiffrement gérées par Microsoft pour chiffrer les données en transit et au repos. Les données sont chiffrées et déchiffrées à l’aide du chiffrement AES 256 bits conforme à FIPS 140-2. Le chiffrement et le déchiffrement sont transparents, ce qui veut dire que le chiffrement et les accès sont gérés pour vous. Vos données étant sécurisées par défaut, vous n’avez pas besoin de modifier votre code ou vos applications pour tirer parti du chiffrement.

    Avant d’activer les clés gérées par le client pour Foundry, vérifiez les conditions préalables suivantes :

    • Key Vault est déployé dans la même région Azure que votre ressource Foundry.
    • La suppression logique et la protection contre la purge sont activées sur le gestionnaire de clés Key Vault.
    • Les identités managées ont besoin d’autorisations de clé, telles que le rôle utilisateur Key Vault Crypto lors de l’utilisation de Azure RBAC.
  • Bring your own Key Vault : Par défaut, Foundry stocke tous les secrets de connexion avec clé API dans un Azure Key Vault géré. Pour les utilisateurs qui préfèrent gérer cela eux-mêmes, ils peuvent connecter leur key vault à la ressource Foundry. Une connexion Azure Key Vault gère tous les secrets de connexion, au niveau du projet et des ressources. Pour plus d’informations, consultez how pour configurer une connexion Azure Key Vault à Foundry.

    Lorsque vous utilisez des clés gérées par le client, vos données sur l’infrastructure gérée par Microsoft sont chiffrées à l’aide de vos clés.

    Pour en savoir plus sur le chiffrement des données, consultez les clés gérées par le client pour le chiffrement avec Foundry.

Valider les décisions d’architecture

Avant le déploiement, validez les éléments suivants pour votre environnement cible :

  1. Vérifiez que les modèles et fonctionnalités requis sont disponibles dans vos régions de déploiement. Pour plus d’informations, consultez La disponibilité des fonctionnalités dans les régions cloud.
  2. Vérifiez que les attributions de rôles sont correctement délimitées à la fois au niveau de la ressource Foundry et aux niveaux des projets. Pour plus d'informations, consultez Contrôle d'accès basé sur les rôles pour Microsoft Foundry.
  3. Confirmez les exigences d’isolation du réseau et les chemins d’accès privés. Pour plus d’informations, consultez How to configure a private link for Foundry.
  4. Vérifiez les exigences de chiffrement et de gestion des secrets, notamment les clés gérées par le client et l’intégration de Azure Key Vault. Pour plus d’informations, consultez Clés gérées par le client pour le chiffrement avec Foundry et comment configurer une connexion Azure Key Vault à Foundry.