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.
L’intégration du réseau virtuel (VNet) contrôle les destinations vers lesquelles l’agent SRE peut envoyer du trafic sortant. Sans cela, les appels sortants circulent sur Internet public. Avec lui, le trafic passe par votre Réseau virtuel Azure. Cette intégration réseau vous offre les mêmes contrôles au niveau réseau que vous utilisez pour d’autres charges de travail Azure : intégration avec les pare-feu, communication avec les ressources derrière des terminaux privés, et visibilité dans vos journaux réseau.
Modes de contrôle réseau
L’agent SRE offre trois modes de contrôle réseau. Sélectionnez le mode qui correspond à votre posture de sécurité et à votre contexte opérationnel.
| Mode | Description | Idéal pour |
|---|---|---|
| Non restreint | Aucune restriction réseau. L’agent peut atteindre n’importe quel point de terminaison Internet. | Charges de travail de développement, de test et non critiques. |
| Limitée | L’URL générique autorise les contrôles de liste des points de terminaison que l’agent peut appeler. | Contrôle au niveau de l’hôte sans routage de réseau virtuel complet. |
| réseau virtuel Azure | Tout le trafic sortant hors plateforme transite par votre réseau virtuel (VNet), avec application de vos règles DNS et de pare-feu. | Déploiements de production nécessitant un contrôle de sortie et une conformité d’audit. |
Choisir un mode de contrôle réseau pour votre charge de travail
Utilisez les critères suivants pour sélectionner un mode :
Azure réseau virtuel : choisissez ce mode si la charge de travail gère les données sensibles ou réglementées, nécessite une piste d’audit complète de l’activité réseau sortante ou doit se conformer aux stratégies de sécurité d’entreprise. Ce mode est recommandé pour les déploiements d’entreprise de production.
Limité : choisissez ce mode si vous souhaitez restreindre des destinations externes spécifiques sans router tout le trafic via un réseau virtuel. Ce mode fonctionne bien lorsque vous avez besoin d’un contrôle partiel sans la surcharge de la configuration complète du réseau virtuel.
Sans restriction : choisissez ce mode si la charge de travail est un environnement de développement ou de test à court terme sans accès aux données sensibles. Ce mode est la valeur par défaut.
Pour sélectionner un mode, ouvrez votre agent dans le portail Azure et sélectionnez Configurationde l’espace de travail>. Basculez entre les modes sur un agent en cours d’exécution. Les paramètres persistent entre les modifications du mode.
Fonctionnement du mode réseau virtuel Azure
En mode réseau virtuel Azure, le trafic sortant prend l’un des deux chemins suivants :
Votre réseau virtuel. Par défaut, tout le trafic sortant non plateforme passe par un sous-réseau délégué dans votre réseau virtuel. Vos règles NSG, stratégies de pare-feu, DNS personnalisés et journaux du réseau s’appliquent. L’agent est soumis aux mêmes contrôles que toute autre charge de travail sur ce sous-réseau. Il peut atteindre ce que le sous-réseau peut atteindre, et rien de plus.
L’agent peut atteindre des ressources derrière des points de terminaison privés, des services internes et des systèmes locaux connectés via ExpressRoute ou VPN, tant que vos itinéraires et règles réseau l’autorisent.
Réseau d’infrastructure de l’agent SRE Azure. Les services de plateforme dont dépend l'agent (orchestration, points de terminaison de modèle, télémétrie) sont toujours acheminés via l'infrastructure managée de Microsoft. Ces services ne sont pas configurables. Certaines fonctionnalités d’agent telles que l’installation de package, l’accès au référentiel de code et les serveurs MCP distants nécessitent d’atteindre les services publics. Pour utiliser ces fonctionnalités en mode réseau virtuel Azure, activez le bouton bascule correspondant. Si un commutateur est désactivé, cette capacité n’est pas disponible, sauf si votre réseau virtuel peut acheminer le trafic directement vers ces services (par exemple, via des règles de pare-feu basées sur des noms de domaine complets [FQDN]). Consultez le réseau d’infrastructure de l’agent SRE Azure pour plus de détails.
Résumé du routage du trafic
| Type de trafic | Chemin | Paramétrable? |
|---|---|---|
| Votre infrastructure de Azure (Log Analytics, App Insights, AKS, bases de données, Coffres de clés) | Votre réseau virtuel | Yes. Routé par défaut via votre réseau virtuel. |
| Systèmes locaux (ExpressRoute / VPN) | Votre réseau virtuel | Yes. Accessible si vos itinéraires réseau l’autorisent. |
| Services de plateforme (orchestration, points de terminaison de modèle, télémétrie) | réseau d’infrastructure de l’agent SRE Azure | Non. Toujours routé via une infrastructure managée. |
| Dépôts de paquets (PyPI, npm, NuGet, apt) | Infrastructure réseau de l’agent SRE (activation) ou votre VNet (règle FQDN) | Yes. Option pour chaque registre ou paquets préinstallés |
| Référentiels de code (GitHub, GHE, Azure DevOps) | Infrastructure réseau de l’agent SRE (activation) ou votre VNet (règle FQDN) | Yes. Bascule par fournisseur |
| Serveurs MCP distants | Infrastructure réseau de l’agent SRE (activation) ou votre VNet (règle FQDN) | Yes. Bascule unique |
| Noms d’hôte supplémentaires | Réseau infra de l’agent SRE (pour les hôtes de la liste) | Yes. Liste personnalisée |
| Trafic du connecteur | Internet public | Non. Pas routé via VNet. |
| Entrant (point de terminaison privé) | Non pris en charge | Non. Sortie uniquement. |
Configurer Azure mode de réseau virtuel
Configuration requise du sous-réseau
Le mode Réseau virtuel Azure nécessite un sous-réseau dédié dans votre réseau virtuel :
- Taille : /27 ou plus.
-
Délégation : le sous-réseau doit être délégué à
Microsoft.App/environments. - Région : le sous-réseau doit se trouver dans la même région que la ressource de votre agent SRE.
- Dédié : le sous-réseau ne peut pas être partagé avec d’autres services.
Configurer Azure mode de réseau virtuel
- Allez dans Paramètres>Configuration de l’espace de travail>Réseau.
- Sélectionnez Azure réseau virtuel comme mode de sortie.
- Sélectionnez Parcourir les sous-réseaux.
- Sélectionnez votre abonnement, votre groupe de ressources, votre réseau virtuel et votre sous-réseau qui répondent aux exigences du sous-réseau.
- Cliquez sur Enregistrer.
- Testez l’agent avec un incident représentatif pour confirmer qu’il peut atteindre les ressources dont il a besoin.
réseau d’infrastructure de l’agent SRE Azure
Certaines fonctionnalités des agents reposent sur des services publics qu’il est difficile de mettre en liste blanche sur la base des adresses IP. En mode Azure VNet, ces fonctionnalités nécessitent soit une option de réseau d’infrastructure (qui achemine cette catégorie via le réseau d’infrastructure de l’agent SRE Azure), soit des règles de pare-feu basées sur le FQDN dans votre VNet qui autorisent directement le trafic. Consultez le résumé du routage du trafic pour obtenir la liste complète des catégories et des chemins d’accès.
Si vous désactivez une bascule et que votre réseau virtuel ne peut pas atteindre le service, cette fonctionnalité n’est pas disponible.
Note
Vous pouvez appliquer une Azure Policy pour restreindre ou désactiver les bascules de réseau infra, ce qui garantit qu’aucun opérateur ne peut acheminer le trafic en dehors du réseau virtuel.
Packages préinstallés
Préinstaller les packages dans l’image de disque de base du bac à sable afin qu’ils soient disponibles chaque fois que l’agent s’exécute. Cette fonctionnalité est utile lorsque vos outils ou scripts dépendent de packages spécifiques qui ne sont pas inclus dans l’environnement de bac à sable par défaut.
Pour configurer des packages préinstallés :
Ouvrez votre agent dans le portail Azure, puis sélectionnez Settings>Workspace configuration.
Sélectionnez l’onglet Packages .
Entrez le nom du package, sélectionnez le gestionnaire de package (pip ou NuGet) et spécifiez éventuellement une version.
Sélectionnez + Ajouter un package.
Note
Les entrées NuGet doivent être .NET outils CLI (par exemple, dotnet-ef). Vous ne pouvez pas installer les packages de bibliothèque globalement.
Contrôles de contournement de réseau virtuel
Lorsque vous activez Azure mode réseau virtuel, la section Sur le réseau infra de la page de configuration de l’espace de travail vous permet de router les catégories de trafic en dehors de votre réseau virtuel via l’Internet public. Si vous n’activez aucun de ces contrôles, tout le trafic de l’agent transite par votre VNet.
Tous les services externes ne fournissent pas de balise de service Azure. GitHub, par exemple, n'est pas un service Azure et n'expose pas d'étiquette de service. Si votre agent doit atteindre GitHub, votre seule option avec un pare-feu basé sur ip de couche 4 consiste à conserver une liste des adresses IP du fournisseur. Ces listes changent fréquemment, et un pare-feu qui n’est pas maintenu à jour empêche l’agent de fonctionner.
Il en va de même pour plusieurs services publics majeurs tels que PyPI, npm, NuGet et registres de conteneurs. Ces services fonctionnent à partir de plages d'adresses IP globales volumineuses et fréquemment modifiées, et ils ne sont pas couverts par des étiquettes de service Azure.
Les bascules de contournement permettent à l’agent d’accéder à ces hôtes via la sortie de la plateforme. Votre équipe réseau met à jour les règles de pare-feu ou passe à un pare-feu qui prend en charge le filtrage de noms d’hôte ou le filtrage de nom de domaine complet (FQDN). Les exemples incluent Pare-feu Azure Premium avec des règles de nom de domaine complet ou une appliance virtuelle réseau qui prend en charge l’inspection de la sécurité de la couche transport.
Considérez les mécanismes de contournement comme une solution transitoire, et non comme un substitut permanent au filtrage de sortie basé sur les noms d’hôte.
Les contrôles suivants sont disponibles :
| Contrôle | Description |
|---|---|
| Accès au serveur MCP (Model Context Protocol) | Lorsqu’il est activé, le trafic du serveur MCP est acheminé via l’Internet public au lieu de votre réseau virtuel. |
| Accès au gestionnaire de package | Lorsqu’il est activé, le trafic du gestionnaire de package (PyPI, npm, NuGet) est acheminé sur l’Internet public au lieu de votre réseau virtuel. |
| Référentiels de code | Choisissez les fournisseurs de dépôts de code (GitHub, GitHub Enterprise, Azure DevOps) qui passent par l’Internet public plutôt que par votre réseau virtuel. |
| Hôtes supplémentaires | Entrez des noms d’hôte supplémentaires ou des modèles génériques (par exemple, github.com, , *.example.comraw.contoso.io) pour router sur l’Internet public au lieu de votre réseau virtuel. Vos packages configurés autorisent automatiquement leurs propres hôtes. |
Considérations sur la gouvernance
L’accès à ces contrôles est limité aux utilisateurs disposant du rôle Administrateur de l’agent SRE. La création d’un agent SRE dans un environnement d’entreprise est elle-même un acte de gouvernance important, car les organisations nécessitent généralement une approbation substantielle pour déployer des services en production. Les mécanismes de contournement font partie du cadre plus large de la gouvernance d’entreprise, qui comprend l’identité managée, les informations d’identification on-behalf-of (OBO) et les autorisations RBAC. L’agent ne peut faire que ce que ses autorisations permettent, et la configuration réseau détermine où va ce trafic.
Inspecter l’activité réseau
Les administrateurs peuvent ouvrir Paramètres>>Inspection et utiliser Audit réseau pour examiner les requêtes sortantes de l’agent, filtrées entre celles autorisées et celles refusées. Utilisez l’hôte, la méthode, le chemin et la décision pour identifier les destinations bloquées par la politique Limited ou Azure VNet.
L’audit réseau ne couvre que les décisions liées à la politique de sortie des agents. Ce n’est pas une trace d’audit réseau complète et n’inclut pas chaque temps d’exécution, connecteur, plateforme, pare-feu, DNS ou événement proxy.
Que se passe-t-il lorsque le réseau bloque un appel
Si une requête sortante est refusée par une règle de NSG ou ne dispose d’aucune route, l’agent voit la même erreur réseau que n’importe quelle charge de travail sur ce sous-réseau. L’agent signale l’échec dans le résultat de son investigation (par exemple, « Impossible d’atteindre l’espace de travail Log Analytics : délai d’attente de la connexion dépassé ») et continue avec les outils et les données auxquels il a accès. Si une source de données critique est inaccessible, l’investigation est incomplète et l’agent signale cette condition.
Limitations
Les limitations suivantes s’appliquent.
Trafic sortant uniquement : l’intégration au réseau virtuel contrôle uniquement le trafic sortant (egress). Les connexions entrantes vers l’agent depuis un réseau privé ne sont pas prises en charge.
Les connecteurs ne passent pas par le réseau virtuel : le trafic des connecteurs passe par l’internet public.