Partager via

Déploiement de Microsoft Foundry dans mon organisation

Ce guide décrit les principales décisions relatives au déploiement de Microsoft 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 pour obtenir des conseils supplémentaires.

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 gestionnaires 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 :

  1. Définissez les limites de l’environnement entre le développement, les tests et la production.
  2. Attribuez la responsabilité pour chaque ressource Foundry et la portée du projet.
  3. Définissez les affectations RBAC pour les administrateurs, les gestionnaires de projet et les utilisateurs de projet.
  4. Définissez l’approche réseau pour chaque environnement (access public, point de terminaison privé ou hybride).
  5. Déterminez si les clés gérées par le client sont requises par la stratégie.
  6. Définissez le coût et la responsabilité de la surveillance pour chaque groupe commercial.
  7. 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.

Capture d’écran d’un diagramme montrant la ressource 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 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.

  • Associez des projets aux cas d’usage. Les projets de fonderie sont conçus pour représenter des cas d’usage spécifiques. Il s’agit de 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.

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. Les zones de configuration clés sont les suivantes :

  • Identity : utilisez Microsoft Entra ID pour gérer les 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é.  Learn plus sur les identités managées.

  • Networking : Déployer Foundry dans un « réseau virtuel » pour isoler le trafic et contrôler les accès à l’aide de groupes de sécurité réseau (NSG).  Learn plus sur la sécurité réseau.

    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

    L’isolation réseau de bout en bout n’est pas entièrement prise en charge dans la nouvelle expérience du portail Foundry. Pour les déploiements isolés du réseau, utilisez les instructions relatives à l'interface classique, au SDK ou à la ligne de commande dans Comment configurer un lien privé pour Foundry.

  • Clés gérées par le client (CMK) : Azure prend en charge les CMK pour le chiffrement des données inactives. Foundry prend en charge CMK éventuellement pour les clients ayant des besoins de conformité stricts.  En savoir plus sur CMK.

  • Authentification et autorisation : Foundry prend en charge l'accès basé sur des clés 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 control (gestion des ressources) et le plan data (modèle et access de données). Commencez par des rôles intégrés et définissez des rôles personnalisés en fonction des besoins. En savoir plus sur l'authentification.

  • Modèles : utilisez des modèles ARM ou Bicep pour automatiser des déploiements sécurisés. Explorez les modèles sample.

  • Storage ressource : vous pouvez choisir d’utiliser des fonctionnalités de storage intégrées dans Foundry ou d’utiliser vos propres ressources storage. 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 basé sur les rôles (RBAC) intégré pour séparer les accès.

  • Les administrateurs gèrent les déploiements , les connexions et les ressources partagées
  • Project Managers supervisent 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 Customer-Managed.

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 requis 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.
      • Project Managers : 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 de compte Azure IA Abonnement ou ressource Foundry
    Gestionnaires de projets Azure Chef de Projet IA 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 la portée d'accès

    • Choisissez l’étendue appropriée pour les attributions d’accès :
      • Niveau d’abonnement : plus large access, généralement adapté aux équipes informatiques centrales ou aux équipes de plateforme ou aux petites organisations.
      • Niveau du groupe de ressources : utile pour regrouper les ressources associées avec des stratégies d’accès partagées. 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 granulaire, en particulier lors de la gestion des données sensibles ou de l’activation d’une solution 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 gérées ou clé API : adaptées aux services automatisés et aux accès partagés entre les utilisateurs.
      • Identités utilisateur : par défaut lorsque la responsabilité ou l’audit au niveau de l’utilisateur est requise.
    • Utilisez les groupes Microsoft Entra ID 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 Azure AI User pour les développeurs et les identités managées de projet, puis ajoutez uniquement des rôles privilégiés lorsque cela est nécessaire. 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 l'accès aux composants d’application sur des 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és, tels que les identités gérées de Microsoft Entra ID ou des clés API, afin de simplifier la gestion et l’intégration, ou des jetons utilisateur via la passerelle Entra ID, qui offrent un meilleur contrôle lors de l’accès aux sources de données sensibles.

Screenshot d’un diagramme montrant la connectivité et l’intégration de Foundry project à d’autres services Azure.

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 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 project 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égionaux et vous permettre d'accéder aux déploiements de modèles existants, Foundry autorise les connexions 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

  • Last updated on