Le déploiement de Microsoft Foundry au sein de mon organisation

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.

Conditions préalables

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 pour le déploiement de base

Utilisez cette liste de contrôle avant le premier déploiement de production :

1. Définissez les limites de l’environnement entre le développement, les tests et la production.
2. Assignez la responsabilité pour chaque ressource Foundry et la portée du projet.
3. 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. Lors de ces cas, la séparation par ressource Foundry est recommandée.
4. Définissez les affectations RBAC pour les administrateurs, les responsables de projet et les utilisateurs de projet.
5. Définissez l’approche réseau pour chaque environnement (accès public, point de terminaison privé ou hybride).
6. Déterminez si les clés gérées par le client sont requises par la stratégie.
7. Définissez le coût et la responsabilité de la surveillance pour chaque groupe d'affaires.
8. Identifiez les connexions partagées requises et les connexions délimitées par le 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 la mise en réseau et la gestion centralisée des données, tout en permettant l’accès libre-service à Foundry pour chaque équipe au sein d’un environnement régi et sécurisé pour gérer leurs cas d’usage.

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 outils du développeur Foundry.

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 l’accès 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 les ressources Foundry distinctes lorsque les équipes ont besoin d'API d'IA classiques d'Azure qui ne prennent pas en charge l'accès limité à un projet.

• 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 au niveau du projet, vérifiez que les API que votre équipe envisage 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 du projet pour un contrôle affiné. Pour plus d’informations, consultez contrôle d’accès en fonction du rôle dans Foundry.

Réseautage

Déployez Foundry dans un Réseau virtuel 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 Comment configurer une liaison privée 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 en fonction du rôle 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 des ressources 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’entreprises se connecte via un réseau virtuel 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 dirigent les projets spécifiques
• Les utilisateurs interagissent avec les outils GenAI

Pour la plupart des cas d’usage, Contoso s’appuie sur le chiffrement géré par Microsoft par défaut et n’utilise pas les clés gérées par le client.

Planifier l’accès utilisateur

Une gestion efficace des accès est fondamentale pour 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 l’accès à 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 :

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 assignations 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 des privilèges minimum, commencez par le rôle utilisateur Azure AI pour les développeurs et les identités gérées de projet, puis ajoutez les rôles à privilèges élevés uniquement en cas de besoin. Pour plus d’informations, consultez contrôle d’accès en fonction du rôle 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 répartiteurs 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 stockage Azure ou Key Vault. Limitez les connexions à un projet spécifique pour des intégrations sensibles ou spécifiques à un 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 soit des jetons d'accès partagé, tels que des identités managées Microsoft Entra ID ou des clés API, afin de simplifier la gestion et l'intégration, soit des jetons utilisateur via transmission directe Entra ID, qui offrent un meilleur contrôle lors de l'accès à des 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.

Gouvernance

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 stratégies pour restreindre les modèles ou les familles de modèles auxquels des groupes d’entreprises spécifiques peuvent accéder. Exemple : Le groupe Finance &Risk de Contoso est limité à l’utilisation de modèles en préversion ou non conformes en appliquant une stratégie 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 journalisation, l’utilisation des jetons et la latence pour faciliter l’audit et 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 du 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 à partir 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 : les responsables des coûts et de la surveillance sont affectés pour chaque groupe d'entreprises.
• 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 nécessitant des performances prévisibles, un contrôle des coûts et le verrouillage de version du modèle.

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 activant l’accès à partir de projets distribués. Pour les charges de travail de production, envisagez d’avoir des cas d'utilisation qui gèrent leurs propres déploiements pour garantir un contrôle plus étroit sur le cycle de vie, la gestion des versions et les stratégies de retour arrière 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 des ressources, de se protéger contre les pics accidentels et d’aligner l’utilisation avec les budgets de projet ou les quotas. Envisagez de définir des limites conservatrices pour les déploiements partagés et des seuils supérieurs pour les services de production critiques.

Pour en savoir plus

• Sécuriser l’environnement Foundry

  • Authentification et RBAC : contrôle d’accès en fonction du rôle dans Foundry
  • Mise en réseau : utiliser un réseau virtuel 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 de modèles avec des exemples de modèles d’infrastructure
  • Récupérer ou vider les ressources Foundry supprimées

• Établir une connectivité avec d’autres services Azure

  • Vue d’ensemble des connexions : Ajouter une nouvelle connexion dans Foundry

Étape suivante