« Point de terminaison privé activé » n’est pas une architecture complète
Les équipes d’entreprise traitent souvent le réseau privé comme une case à cocher à la fin d’un prototype IA. À ce stade, l’application dépend peut-être déjà de modèles publics, de sources de paquets externes, d’outils web non restreints, d’une résolution DNS publique ou de chemins de télémétrie jamais documentés.
Microsoft Foundry prend en charge l’isolation réseau, notamment avec Private Link, des points de terminaison privés et des réseaux virtuels. La conception sûre commence néanmoins par une carte des flux et des dépendances.
Dessiner trois frontières
La documentation Microsoft distingue trois sujets :
- L’accès entrant à la ressource Foundry et aux projets.
- L’accès sortant de Foundry vers les services Azure et autres dépendances.
- L’accès sortant du client agent vers les sources privées, services approuvés ou destinations internet.
Traitez-les comme des questions indépendantes. Restreindre l’entrée ne limite pas automatiquement chaque sortie.
Pour chaque flux, consignez l’identité source, la destination, le protocole, les classes de données, la résolution de noms, l’autorisation, les journaux produits et le comportement en cas d’échec.
Commencer par la charge, pas par le sous-réseau
Identifiez tout ce que le système touche réellement :
- prompts et fichiers chargés ;
- magasins de recherche et documents sources ;
- API métier et résultats des outils ;
- état de conversation ou d’agent ;
- jeux d’évaluation et résultats ;
- traces, journaux, métriques et exports de support ;
- téléchargements de modèles et de paquets ;
- accès des administrateurs et développeurs.
Des informations sensibles peuvent apparaître dans la télémétrie et les artefacts d’évaluation même si la base principale reste privée. Incluez les données opérationnelles dans la frontière.
Accès entrant et DNS
L’accès réseau public peut être désactivé ou limité, les points de terminaison privés permettant alors l’accès depuis les réseaux approuvés. Le DNS est une partie fonctionnelle du contrôle. Depuis le réseau virtuel prévu, le nom Foundry doit se résoudre vers l’adresse privée. Un DNS personnalisé ou local nécessite les délégations ou enregistrements appropriés.
Validez la résolution en empruntant les mêmes chemins que les développeurs, le CI/CD, les applications et les opérateurs. Une configuration réussie dans le portail ne prouve pas que chaque client utilise la route privée.
Testez également depuis un réseau non approuvé. L’échec attendu fait partie des preuves d’acceptation.
Dépendances sortantes et agents
Une application incapable d’atteindre ses sources, son fournisseur d’identité, sa supervision ou ses API n’est pas prête. Une application capable d’atteindre n’importe quoi n’est pas isolée.
Utilisez une liste d’autorisation issue de l’architecture de mission. Private Link et les points de terminaison privés peuvent protéger les dépendances Azure PaaS prises en charge. Le réseau des agents peut utiliser un sous-réseau délégué et l’injection dans un réseau virtuel pour atteindre les dépendances définies par le client.
Décidez explicitement si l’accès web est nécessaire. Si oui, faites-le passer par une route inspectée et contrôlée, et traitez le contenu internet comme une entrée non fiable. Sinon, ne laissez pas une sortie large ouverte « pour plus tard ».
L’identité reste la frontière d’autorisation principale
Le réseau réduit la joignabilité. Il ne décide pas si un utilisateur ou un agent peut lire un dossier client ou exécuter une action métier.
Utilisez les identités Microsoft Entra et le moindre privilège. Séparez déploiement, exploitation, évaluation et accès aux données. Pour les outils, préservez l’identité du demandeur lorsque l’autorisation utilisateur est requise ; sinon, utilisez une identité de charge dédiée à un objectif étroit.
Évitez les clés partagées dans la configuration quand l’identité gérée est disponible. Faites tourner et surveillez tout identifiant qui ne peut être supprimé.
Valider les chemins négatifs
Un déploiement privé nécessite des tests qui prouvent le rejet du mauvais comportement :
- l’accès public échoue lorsqu’il est désactivé ;
- le DNS privé se résout correctement depuis chaque environnement approuvé ;
- une identité non autorisée n’accède ni au projet ni aux données en aval ;
- les destinations sortantes non approuvées sont inaccessibles ;
- les journaux ne capturent pas de contenu interdit ;
- l’agent échoue de manière sûre si une dépendance privée disparaît ;
- les opérateurs conservent une voie approuvée d’incident et de reprise.
Répétez ces tests après les changements réseau, DNS, runtime d’agent ou dépendances.
Le caractère privé est une propriété opérationnelle
L’isolation ajoute de la complexité au déploiement et au support. Décrivez l’architecture comme du code, surveillez les points privés et le DNS, et attribuez la responsabilité des changements de politique. Prévoyez l’accès d’urgence sans créer une dérogation permanente.
L’affirmation crédible n’est pas « nous utilisons des points de terminaison privés », mais : nous connaissons chaque chemin pertinent, imposons les routes et identités prévues, et testons continuellement l’échec des chemins non autorisés.
Référence officielle
Microsoft documente les accès entrants, sortants, du client agent, Private Link et le DNS dans Configurer l’isolation réseau pour Microsoft Foundry.