Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Un plan de déploiement structuré vous permet d’éviter les lacunes de sécurité, les dépassements de coûts et l’étendue de l’accès lors de l’adoption de Microsoft Foundry à grande échelle. Ce guide décrit les principales décisions relatives au déploiement de Foundry, notamment la configuration de l’environnement, l’isolation des données, l’intégration à d’autres services Azure, la gestion de la capacité et la surveillance. Utilisez ce guide comme point de départ et adaptez-le à vos besoins. Pour plus d’informations sur l’implémentation, consultez les articles liés.
Prerequisites
Avant de commencer la planification du déploiement, vérifiez que vous disposez des points suivants :
- Une stratégie d’abonnement et de groupe de ressources Azure cible pour les environnements de développement, de test et de production.
- Microsoft Entra ID groupes (ou groupes d’identité équivalents) définis pour les administrateurs, les responsables de projet et les utilisateurs de projet.
- Plan de région initial basé sur la disponibilité des modèles et des fonctionnalités. Pour plus d’informations, consultez La disponibilité des fonctionnalités dans les régions cloud.
- Accord sur les exigences de sécurité pour la mise en réseau, le chiffrement et l’isolation des données dans votre organisation.
Liste de contrôle de référence pour le déploiement
Utilisez cette liste de contrôle avant le premier déploiement de production :
- Définissez les limites de l’environnement entre le développement, les tests et la production.
- Attribuez la responsabilité pour chaque ressource Foundry et la portée du projet.
- Déterminez les fonctionnalités de Foundry que vous envisagez d’utiliser. Toutes les API de fonctionnalité ne sont pas disponibles dans le contexte du projet. Si vous envisagez d’attribuer des autorisations au niveau de l’étendue de projet la plus basse pour l’isolation des cas d’usage, cela peut ne pas être pris en charge pour les API d’ia classiques Azure telles que Translator. Ceux-ci nécessitent que chaque utilisateur dispose d’autorisations sur le niveau de ressource Foundry parent. Dans ces cas, la séparation par ressource Foundry est recommandée.
- Définissez les affectations RBAC pour les administrateurs, les gestionnaires de projet et les utilisateurs de projet.
- Définissez l’approche réseau pour chaque environnement (access public, point de terminaison privé ou hybride).
- Déterminez si les clés gérées par le client sont requises par la stratégie.
- Définissez le coût et la responsabilité de la surveillance pour chaque groupe commercial.
- Identifiez les connexions partagées requises et les connexions à portée de projet.
Exemple d’organisation
Contoso est une entreprise mondiale qui explore l’adoption de GenAI dans cinq groupes d’entreprises, chacun ayant des besoins distincts et une maturité technique.
Pour accélérer l’adoption tout en conservant la supervision, Contoso Enterprise IT vise à permettre un modèle avec des ressources partagées communes, notamment le réseau et la gestion des données centralisées, tout en permettant l'accès en libre-service à Foundry pour chaque équipe au sein d’un environnement régi et sécurisé pour la gestion de leurs cas d'utilisation.
Considérations relatives au déploiement
La ressource Foundry définit l’étendue de la configuration, de la sécurisation et de la supervision de l’environnement de votre équipe. Il est disponible dans le portail Foundry et via Azure API. Les projets sont comme des dossiers pour organiser votre travail dans ce contexte de ressource. Les projets contrôlent également l’accès et les autorisations aux API et aux outils de développement de Foundry.
Important
Les projets fournissent un environnement de bac à sable préconfiguré optimisé pour la création d’agents et les fonctionnalités natives de Foundry. Toutefois, étant donné que Foundry est basé sur un certain nombre de Azure AI services classiques, toutes les API classiques ne sont pas disponibles dans le contexte du projet. Identifiez les fonctionnalités que vos équipes prévoient d’utiliser et de vérifier si elles prennent en charge l’accès au niveau du projet. Pour les services tels que Translator qui nécessitent des autorisations au niveau de la ressource Foundry parent, envisagez d’utiliser des ressources Foundry distinctes pour l’isolation des coûts et le contrôle d’accès.
Pour garantir la cohérence, la scalabilité et la gouvernance entre les équipes, tenez compte des pratiques de configuration d’environnement suivantes lors du déploiement de Foundry :
Établissez des environnements distincts pour le développement, les tests et la production. Utilisez des groupes de ressources ou des abonnements distincts et des ressources Foundry pour isoler les flux de travail, gérer access et prendre en charge l’expérimentation avec des versions contrôlées.
Créez une ressource Foundry distincte pour chaque groupe d’entreprise. Alignez les déploiements avec des limites logiques telles que des domaines de données ou des fonctions métier pour garantir l’autonomie, la gouvernance et le suivi des coûts. Prenez également en compte des ressources Foundry distinctes lorsque les équipes ont besoin des API classiques d’IA d’Azure qui ne prennent pas en charge un accès limité aux projets.
Associez des projets aux cas d’usage. Les projets Foundry représentent des cas d’usage spécifiques et fournissent des conteneurs pour organiser des composants tels que des agents ou des fichiers pour une application. Bien qu'ils héritent des paramètres de sécurité de leur ressource parente, ils peuvent également implémenter leurs propres contrôles d'accès, intégration des données et autres contrôles de gouvernance. Avant d’attribuer des autorisations de portée projet, vérifiez que les API que votre équipe prévoit d’utiliser prennent en charge l’accès au niveau du projet.
Sécurisation de l’environnement Foundry
Foundry est basé sur la plateforme Azure, ce qui vous permet de personnaliser les contrôles de sécurité pour répondre aux besoins de votre organisation.
Identité
Utilisez Microsoft Entra ID pour gérer l’accès des utilisateurs et des services. Foundry prend en charge les identités managées pour autoriser l’authentification sécurisée sans mot de passe à d’autres services Azure. Vous pouvez affecter des identités managées au niveau de la ressource Foundry et éventuellement au niveau project pour un contrôle affiné. Pour plus d’informations, consultez Contrôle d'accès basé sur les rôles dans Foundry.
Mise en réseau
Déployez Foundry dans un Virtual Network pour isoler le trafic et contrôler l’accès à l’aide de groupes de sécurité réseau (NSG). Pour les scénarios de connectivité privée, utilisez des points de terminaison privés et validez l’état d’approbation du DNS et du point de terminaison. Pour plus d’informations sur l’implémentation et les limitations, consultez How to configure a private link for Foundry.
Important
Certaines fonctionnalités, telles que les agents et les évaluations, nécessitent une configuration réseau supplémentaire pour l’isolation de bout en bout. Pour plus d’informations sur l’implémentation et les limitations actuelles, consultez Comment configurer l’isolation réseau pour Foundry.
Clés gérées par le client
Azure prend en charge les clés gérées par le client (CMK) pour le chiffrement des données au repos. Foundry prend en charge CMK éventuellement pour les clients ayant des besoins de conformité stricts. Pour plus d’informations, consultez clés gérées par le client dans Foundry.
Authentification et autorisation
Foundry prend en charge l’accès par clé API pour une intégration simple et Azure RBAC pour un contrôle affiné. Les clés API peuvent simplifier la configuration, mais elles ne fournissent pas la même granularité basée sur les rôles que Microsoft Entra ID avec RBAC. Azure applique une séparation claire entre le plan contrôle (opérations de gestion des ressources telles que la création ou la configuration de ressources) et le plan data (opérations d’exécution telles que l’appel de modèles et l’accès aux données). Commencez par des rôles intégrés et définissez des rôles personnalisés en fonction des besoins. Pour plus d’informations, consultez Contrôle d'accès basé sur les rôles dans Foundry.
Modèles
Utilisez des modèles ARM ou des Bicep pour automatiser des déploiements sécurisés. Explorez les exemples de modèles d’infrastructure.
Stockage
Vous pouvez choisir d’utiliser des fonctionnalités de stockage intégrées dans Foundry ou utiliser vos propres ressources de stockage. Pour le service agent, les threads et les messages peuvent éventuellement être stockés dans resources gérées par vous.
Exemple : approche de sécurité de Contoso
Contoso sécurise ses déploiements Foundry à l’aide d’une mise en réseau privée avec le service informatique d’entreprise gérant un réseau hub central. Chaque groupe d’affaires se connecte via un virtual network spoke. Ils utilisent le contrôle d’accès en fonction du rôle intégré (RBAC) pour séparer l’accès :
- Les administrateurs gèrent les déploiements , les connexions et les ressources partagées
- Project Managers supervisent des projets spécifiques
- Les utilisateurs interagissent avec les outils GenAI
Pour la plupart des cas d'utilisation, Contoso s’appuie par défaut sur le chiffrement géré par Microsoft et n’utilise pas les clés gérées par le client.
Planifier les accès utilisateur
La gestion efficace des accès est fondamentale pour garantir une configuration sécurisée et évolutive de Foundry.
Définir les rôles d’accès et les responsabilités
Identifiez les groupes d’utilisateurs qui nécessitent access à différents aspects de l’environnement Foundry. Attribuez des rôles RBAC intégrés ou personnalisés Azure en fonction des responsabilités telles que :
- Propriétaire du compte : gérez les configurations de niveau supérieur, telles que la sécurité et les connexions de ressources partagées.
- Chefs de projet : Créez et gérez des projets Foundry et leurs contributeurs.
- Utilisateurs du projet : Contribuer à des projets existants.
Utilisez ce mappage initial rôle-à-portée pour la planification du déploiement :
| Persona | Rôle débutant | Étendue recommandée |
|---|---|---|
| Administrateurs | Propriétaire ou propriétaire du compte Azure AI | Abonnement ou ressource Foundry |
| Gestionnaires de projet | Gestionnaire de Projet Azure Intelligence Artificielle | Ressource Foundry |
| utilisateurs Project | utilisateur IA Azure | Projet de fonderie |
Ajustez les affectations en fonction des exigences des privilèges minimum et des stratégies d’entreprise.
Déterminer l’étendue d’accès
Choisissez l’étendue appropriée pour les affectations d’accès :
- Niveau d’abonnement : accès le plus large, généralement adapté aux équipes informatiques centrales ou aux équipes de plateforme ou aux organisations plus petites.
- Niveau du groupe de ressources : utile pour regrouper les ressources associées avec des stratégies d’accès partagé. Par exemple, une fonction Azure qui suit le même cycle de vie d’application que votre environnement Foundry.
- Niveau de ressource ou de projet : idéal pour un contrôle précis, en particulier quand vous traitez des données sensibles ou activez le libre-service.
Aligner la stratégie d’identité
Pour les sources de données et les outils intégrés à Foundry, déterminez si les utilisateurs doivent s’authentifier à l’aide de :
- Identités managées ou clé API : adaptée aux services automatisés et à l’accès partagé entre les utilisateurs.
- Identités utilisateur : par défaut lorsque la responsabilité ou l’audit au niveau de l’utilisateur est requise.
Utilisez Microsoft Entra ID groupes pour simplifier la gestion des accès et garantir la cohérence entre les environnements.
Pour l’intégration avec des privilèges minimums, commencez par le rôle Utilisateur Azure AI pour les développeurs et les identités gérées de projet, puis ajoutez uniquement des rôles élevés lorsque cela est requis. Pour plus d’informations, consultez Contrôle d'accès basé sur les rôles dans Foundry.
Établir une connectivité avec d’autres services Azure
Foundry prend en charge les connexions , qui sont des configurations réutilisables qui permettent d’accéder aux composants d’application sur les services Azure et non-Azure. Ces connexions agissent également en tant que courtiers d'identité, ce qui permet à Foundry de s’authentifier auprès de systèmes externes à l’aide d’identités managées ou de principaux de service pour le compte des utilisateurs du projet.
Créez des connexions au niveau de la ressource Foundry pour les services partagés tels que Azure Storage ou Key Vault. Connexions d’étendue à un projet spécifique pour les intégrations sensibles ou spécifiques au projet. Cette flexibilité permet aux équipes d’équilibrer la réutilisation et l’isolation en fonction de leurs besoins. En savoir plus sur les connexions dans Foundry.
Configurez l’authentification de connexion pour utiliser des jetons d’accès partagé, tels que les identités gérées Microsoft Entra ID ou des clés d'API, afin de simplifier la gestion et l’intégration, ou des jetons utilisateur via la fonction de transit Entra ID, qui offrent un meilleur contrôle lors de l’accès aux sources de données sensibles.
Exemple : stratégie de connectivité de Contoso
- Contoso crée une ressource Foundry pour chaque groupe d’entreprises, ce qui garantit que les projets ayant des besoins de données similaires partagent les mêmes ressources connectées.
- Par défaut, les ressources connectées utilisent des jetons d’authentification partagés et sont partagées entre tous les projets.
- Les projets qui utilisent des charges de travail de données sensibles se connectent à des sources de données au moyen de connexions étendues au projet et de l’authentification directe Microsoft Entra ID.
Governance
Une gouvernance efficace dans Foundry garantit des opérations sécurisées, conformes et rentables entre les groupes d’entreprise.
- Model Access Control avec Azure Policy Azure Policy applique des règles entre les ressources Azure. Dans Foundry, utilisez des politiques pour restreindre l'accès à certains modèles ou familles de modèles que des groupes d'entreprises spécifiques peuvent avoir. Exemple : Le groupe Finance et Risque de Contoso est interdit d'utiliser des modèles en préversion ou non conformes en appliquant une politique au niveau de l’abonnement de leur groupe d’entreprise.
- Cost Management by Business Group En déployant Foundry par groupe d’entreprises, Contoso peut suivre et gérer les coûts indépendamment. Utilisez la calculatrice de prix Azure pour les estimations de prédéploiement et les Microsoft Cost Management pour l’utilisation réelle et le suivi des tendances en cours. Traitez les coûts de Foundry comme une partie du coût total de la solution.
- Usage Tracking avec Azure Monitor Azure Monitor fournit des métriques et des tableaux de bord pour suivre les modèles d’utilisation, les performances et l’intégrité des ressources Foundry.
- Verbose Logging with Azure Log Analytics Azure Log Analytics permet une inspection approfondie des journaux d’activité pour les insights opérationnels. Par exemple, l’utilisation des requêtes de journal, l’utilisation des jetons et le temps de latence à l’appui de l’audit et de l’optimisation.
Valider les décisions de déploiement
Après avoir défini votre plan de déploiement, validez les résultats suivants :
- Identité et accès : les attributions de rôles correspondent aux personas et aux portées approuvées.
- Mise en réseau : le chemin de connectivité et le modèle d’isolation sont documentés pour chaque environnement.
- Vérification réseau : l’état de la connexion du point de terminaison privé est Approuvé et le DNS résout les points de terminaison Foundry en adresses IP privées depuis l'intérieur du réseau virtuel.
- Protection des données : l’approche de chiffrement (clés gérées par Microsoft ou clés gérées par le client) est documentée et approuvée.
- Opérations : des responsables des coûts et de la supervision sont désignés pour chaque groupe métier.
- Vérification des opérations : les vues de coût et les tableaux de bord sont définis dans Microsoft Cost Management et la surveillance est connectée à Application Insights pour chaque projet de production.
- Opérations de modèle : la stratégie de déploiement (standard ou approvisionnée) est documentée par cas d’usage.
- Préparation de la région : les modèles et services requis sont confirmés dans les régions cibles avant le déploiement.
Configurer et optimiser les déploiements de modèles
Lors du déploiement de modèles dans Foundry, les équipes peuvent choisir entre les types de déploiement standard et provisionnés. Les déploiements standard sont idéaux pour le développement et l’expérimentation, offrant une flexibilité et une facilité d’installation. Les déploiements provisionnés sont recommandés pour les scénarios de production où des performances prévisibles, un contrôle des coûts et un verrouillage de version de modèle sont nécessaires.
Pour prendre en charge les scénarios interrégions et vous permettre d’accéder aux déploiements de modèles existants, Foundry autorise connections aux déploiements de modèles hébergés dans d’autres instances Foundry ou Azure OpenAI. En utilisant des connexions, les équipes peuvent centraliser les déploiements pour l'expérimentation tout en permettant l'accès depuis les projets distribués. Pour vos charges de travail en production, privilégiez une gestion des déploiements par cas d'usage afin de garantir un contrôle accru sur le cycle de vie, le versionnage et les stratégies de restauration des modèles.
Pour éviter l’utilisation excessive et garantir une allocation de ressources équitable, vous pouvez appliquer des limites de jetons par minute (TPM) au niveau du déploiement. Les limites de TPM permettent de contrôler la consommation, de se protéger contre les pics accidentels et d’aligner l’utilisation sur des budgets ou des quotas de projet. Envisagez de définir des limites conservatrices pour les déploiements partagés et des seuils supérieurs pour les services de production critiques.
Learn more
Sécuriser l’environnement Foundry
- Authentification et RBAC : Contrôle d'accès basé sur les rôles dans Foundry
- Mise en réseau : Utilisez un virtual network avec Foundry
- Clés gérées par le client (CMK) : clés gérées par le client dans Foundry
- Exemple d’infrastructure : référentiel templates avec des exemples de modèles d’infrastructure
- Récupérer ou purger les ressources Foundry supprimées
Établir une connectivité avec d’autres services Azure
- Vue d’ensemble des connexions : Ajouter une nouvelle connexion dans Foundry