Fonctionnalités de mise en réseau App Service

Vous pouvez déployer des applications dans Azure App Service de plusieurs façons. Par défaut, les applications hébergées dans App Service sont accessibles directement via Internet et peuvent atteindre uniquement des points de terminaison hébergés sur Internet. Toutefois, pour bon nombre d’applications, vous devez contrôler le trafic réseau entrant et sortant. App Service inclut plusieurs fonctionnalités destinées à vous aider à répondre à ces besoins. Le défi consiste à savoir quelle fonctionnalité utiliser pour résoudre un problème donné. Cet article vous aidera à déterminer la fonctionnalité à utiliser, sur la base d’exemples de cas d’usage.

Il existe deux types de déploiement principaux pour Azure App Service :

• Le service multilocataire public multi héberge des plans App Service dans les niveaux tarifaires Gratuit, Partagé, De base, Standard, Premium, PremiumV2 et PremiumV3.
• L’environnement Azure App Service Environment (ASE) de locataire unique héberge les plans App Service de référence SKU Isolé directement dans votre réseau virtuel Azure.

Les fonctionnalités que vous utilisez varient selon que vous êtes dans le service multilocataire ou dans un environnement ASE.

Notes

Les fonctionnalités de réseau ne sont pas disponibles pour les applications déployées dans Azure Arc.

Fonctionnalités de mise en réseau App Service multilocataire

Azure App Service est un système distribué. Les rôles qui gèrent les requêtes HTTP/HTTPS entrantes sont appelés serveurs frontaux. Les rôles qui hébergent la charge de travail du client sont appelés rôles de travail. Tous les rôles d’un déploiement App Service existent dans un réseau multilocataire. Comme il existe de nombreux clients différents dans la même unité d’échelle App Service, vous ne pouvez pas connecter le réseau App Service directement à votre réseau.

Au lieu de connecter les réseaux, vous avez besoin de fonctionnalités pour gérer les différents aspects de la communication de l’application. Les fonctionnalités qui gèrent les demandes vers votre application ne peuvent pas être utilisées pour résoudre des problèmes lorsque des appels sont effectués depuis votre application. De même, les fonctionnalités qui résolvent des problèmes pour les appels depuis votre application ne peuvent pas être utilisées pour résoudre des problèmes vers votre application.

Fonctionnalités en entrée	Fonctionnalités en sortie
Adresse attribuée par l’application	les connexions hybrides
Restrictions d'accès	Intégration au réseau virtuel avec passerelle obligatoire
Points de terminaison de service	Intégration du réseau virtuel
Instances Private Endpoint

À part les exceptions notées, vous pouvez utiliser toutes ces fonctionnalités ensemble. Vous pouvez combiner les fonctionnalités pour résoudre vos problèmes.

Cas d’usage et fonctionnalités

Pour tout cas d’usage, il peut y avoir plusieurs façons de résoudre le problème. Le choix de la meilleure fonctionnalité va parfois au-delà du cas d’usage. Les cas d’usage en entrée suivants suggèrent comment utiliser des fonctionnalités réseau App Service pour résoudre des problèmes en lien avec le contrôle du trafic vers votre application :

Cas d’usage en entrée	Fonctionnalité
Prendre en charge les besoins SSL en fonction des adresses IP pour votre application	Adresse attribuée par l’application
Prendre en charge une adresse entrante dédiée non partagée pour votre application	Adresse attribuée par l’application
Restreindre l’accès à votre application à partir d’un ensemble d’adresses bien définies	Restrictions d'accès
Restreindre l’accès à votre application à partir des ressources d’un réseau virtuel	Points de terminaison de service ASE Internal Load Balancer (ILB) Points de terminaison privés
Exposer votre application sur une adresse IP privée dans votre réseau virtuel	ASE ILB Points de terminaison privés Adresse IP privée pour le trafic entrant sur une instance Application Gateway avec des points de terminaison de service
Protéger votre application avec un pare-feu d’applications web (WAF)	Application Gateway et ASE ILB Application Gateway avec des points de terminaison privés Application Gateway avec des points de terminaison de service Azure Front Door avec restrictions d’accès
Équilibrer la charge du trafic vers vos applications dans différentes régions	Azure Front Door avec des restrictions d’accès
Équilibrer la charge du trafic dans la même région	Application Gateway avec des points de terminaison de service

Les cas d’usage en sortie suivants suggèrent comment utiliser les fonctionnalités réseau d’App Service pour répondre aux besoins d’accès sortant de votre application :

Cas d’usage en sortie	Fonctionnalité
Accéder à des ressources dans un réseau virtuel Azure situé dans la même région	Intégration au réseau virtuel ASE
Accéder à des ressources dans un réseau virtuel Azure situé dans une région différente	Intégration au réseau virtuel et appairage de réseaux virtuels Intégration au réseau virtuel requise par la passerelle ASE et appairage de réseaux virtuels
Accéder à des ressources sécurisées avec des points de terminaison de service	intégration au réseau virtuel ASE
Accéder à des ressources dans un réseau privé non connecté à Azure	les connexions hybrides
Accéder à des ressources via des circuits Azure ExpressRoute	intégration au réseau virtuel ASE
Sécuriser le trafic sortant à partir de votre application web	intégration au réseau virtuel et groupes de sécurité réseau ASE
Router le trafic sortant à partir de votre application web	intégration au réseau virtuel et tables de rouage ASE

Comportement de mise en réseau par défaut

Des unités d’échelle Azure App Service prennent en charge de nombreux clients dans chaque déploiement. Les plans de référence SKU Gratuit et Partagé hébergent des charges de travail clientes sur les rôles de travail multilocataires. Les plans De base et supérieurs hébergent les charges de travail client dédiées sur un seul plan App Service. Si vous avez un plan App Service Standard, toutes les applications dans ce plan s’exécutent sur le même rôle de travail. Si vous effectuez un scale-out du rôle de travail, toutes les applications de ce plan App Service sont répliquées sur un nouveau rôle de travail pour chaque instance de votre plan App Service.

Adresses sortantes

Les machines virtuelles de travail sont décomposées en grande partie par les plans App Service. Les plans Gratuit, Partagé, De base, Standard et Premium utilisent tous le même type de machine virtuelle de travail. Le plan PremiumV2 utilise un autre type de machine virtuelle. Le plan PremiumV3 utilise encore un autre type de machine virtuelle. Lorsque vous modifiez la famille de machines virtuelles, vous recevez un autre ensemble d’adresses sortantes. Si vous passez d’un plan Standard à un plan Premiumv2, vos adresses sortantes changent. Si vous passez d’un plan Premiumv2 à un plan Premiumv3, vos adresses sortantes changent. Dans certaines unités d’échelle plus anciennes, les adresses tant entrantes que sortantes changent lorsque vous effectuez une mise à l’échelle d’un plan Standard vers un plan PremiumV2.

Un grand nombre d’adresses sont utilisées pour des appels sortants. Les adresses sortantes utilisées par votre application pour effectuer des appels sortants sont répertoriées dans les propriétés de votre application. Ces adresses sont partagées par toutes les applications qui s’exécutent sur la même famille de machines virtuelles de travail dans le déploiement App Service. Si vous souhaitez voir toutes les adresses que votre application peut utiliser dans une unité d’échelle, il existe une propriété appelée possibleOutboundAddresses qui les répertorie.

App Service a un grand nombre de points de terminaison qui sont utilisés pour gérer le service. Ces adresses sont publiées dans un document distinct, et figurent également dans la balise de service d’adresse IP AppServiceManagement. La balise AppServiceManagement est utilisée uniquement dans les environnements ASE où vous devez autoriser un tel trafic. Les adresses App Service entrantes sont suivies dans la balise de service d’adresse IP AppService. Il n’y a aucune balise de service d’adresse IP contenant les adresses sortantes qu’App Service utilise.

Adresse attribuée par l’application

La fonctionnalité d’adresse attribuée par l’application est une ramification de la fonctionnalité SSL basée sur IP. Vous y accédez en configurant SSL avec votre application. Vous pouvez utiliser cette fonctionnalité pour les appels SSL basés sur IP. Vous pouvez également l’utiliser pour fournir à votre application une adresse dont elle seule dispose.

Lorsque vous utilisez une adresse attribuée par l’application, votre trafic traverse toujours les mêmes rôles de serveur frontal qui gèrent tout le trafic entrant dans l’unité d’échelle App Service. Toutefois, l’adresse attribuée à votre application est utilisée uniquement par celle-ci. Cas d’usage de cette fonctionnalité :

• Prendre en charge les besoins SSL basés sur IP pour votre application.
• Définir une adresse dédiée non partagée pour votre application.

Pour découvrir comment définir une adresse sur votre application, consultez Ajouter un certificat TLS/SSL dans Azure App Service.

Restrictions d'accès

Les restrictions d’accès vous permettent de filtrer les demandes entrantes. L’action de filtrage a lieu sur les rôles front-end situés en amont des déploiements des rôles de travail où vos applications s’exécutent. Étant donné que les rôles de serveur frontal sont en amont des rôles de travail, vous pouvez considérer les restrictions d’accès comme une protection de vos applications au niveau du réseau. Pour plus d’informations sur les restrictions d’accès, consultez Vue d’ensemble des restrictions d’accès.

Cette fonctionnalité vous permet de créer une liste de règles d’autorisation et de refus qui sont évaluées par ordre de priorité. Elle est similaire à la fonctionnalité de groupe de sécurité réseau (NSG) dans Azure Networking. Vous pouvez utiliser cette fonctionnalité dans un ASE ou dans le service multilocataire. Lorsqu’elle est utilisée avec un ASE ILB, vous pouvez restreindre l’accès à partir de blocs d’adresses privées. Pour découvrir comment activer cette fonctionnalité, voir Restrictions d’accès dans Azure App Service.

Notes

Vous pouvez configurer Jusqu’à 512 règles de restrictions par application.

Point de terminaison privé

Private Endpoint est une interface réseau qui vous permet de vous connecter de façon privée et sécurisée à votre application Web Azure Private Link. Un point de terminaison privé utilise une adresse IP privée de votre réseau virtuel, ce qui a pour effet d’introduire l’application Web dans votre réseau virtuel. Cette fonctionnalité s’applique uniquement aux flux entrants dans votre application web. Pour plus d’informations, consultez Utilisation de points de terminaison privés pour une application web Azure.

Cas d’usage de cette fonctionnalité :

• Limiter l’accès à votre application à partir de ressources d’un réseau virtuel.
• Exposer votre application sur une adresse IP privée dans votre réseau virtuel.
• Protéger votre application avec un pare-feu d’applications web (WAF).

Les points de terminaison privés empêchent l’exfiltration de données, car la seule chose que vous pouvez atteindre sur le point de terminaison privé est l’application avec laquelle il est configuré.

les connexions hybrides

La fonctionnalité Connexions hybrides App Service permet à vos applications d’effectuer des appels sortants vers des points de terminaison TCP spécifiés. Le point de terminaison peut être local, dans un réseau virtuel, ou dans n’importe quel emplacement autorisant le trafic sortant vers Azure sur le port 443. Pour utiliser cette fonctionnalité, vous devez installer un agent de relais appelé Hybrid Connection Manager sur un serveur Windows Server 2012 ou un hôte plus récent. L’agent de relais Hybrid Connection Manager doit être en mesure d’atteindre Azure Relay sur le port 443. Vous pouvez télécharger Hybrid Connection Manager à partir de l’interface utilisateur des connexions hybrides d’App Service dans le portail.

Les connexions hybrides d’App Service reposent sur la capacité de connexions hybrides d’Azure Relay. App Service utilise une forme spécialisée de la fonctionnalité qui prend uniquement en charge les appels sortants de votre application vers un port et un hôte TCP. Cet hôte et ce port doivent être résolus uniquement sur l’hôte sur lequel Hybrid Connection Manager est installé.

Lorsque l’application, dans App Service, effectue une recherche DNS sur l’hôte et le port définis dans votre connexion hybride, le trafic est redirigé automatiquement pour traverser la connexion hybride et sortir de Hybrid Connection Manager. Pour plus d’informations, consultez Connexions hybrides d’App Service.

Cette fonctionnalité est couramment utilisée pour :

• Accéder aux ressources dans des réseaux privés qui ne sont pas connectés à Azure via un VPN ou un circuit ExpressRoute.
• Prendre en charge la migration d’applications locales vers App Service sans avoir à déplacer les bases de données associées.
• Fournir un accès avec une sécurité améliorée à un hôte et un port uniques par connexion hybride. La plupart des fonctionnalités réseau ouvrent l’accès à un réseau. Avec des connexions hybrides, vous ne pouvez atteindre que l’hôte et le port uniques.
• Couvrir des scénarios non couverts par d’autres méthodes de connectivité sortante.
• Effectuer du développement dans App Service de manière à permettre aux applications d’utiliser facilement des ressources locales.

Étant donné que cette fonctionnalité permet d’accéder aux ressources locales sans un trou dans le pare-feu de trafic entrant, elle est populaire auprès des développeurs. Les autres fonctionnalités réseau d’App Service sortantes ont trait au réseau virtuel Azure. Les connexions hybrides ne dépendent pas d’un passage par un réseau virtuel. Elles peuvent être utilisées pour couvrir un éventail plus vaste de besoins de réseau.

Les connexions hybrides d’App Service ignorent ce que vous en faites. Vous pouvez les utiliser pour accéder à une base de données, à un service web ou à un socket TCP arbitraire sur un ordinateur mainframe. La fonctionnalité crée essentiellement des tunnels pour les paquets TCP.

Les connexions hybrides sont populaires pour le développement, mais sont également utilisées dans des applications de production. Elles sont très utiles pour accéder à un service web ou à une base de données, mais ne conviennent pas pour des situations impliquant la création de nombreuses connexions.

Intégration du réseau virtuel

L’intégration du réseau virtuel App Service permet à votre application d’effectuer des requêtes sortantes sur un réseau virtuel Azure.

La fonctionnalité d’intégration du réseau virtuel vous permet de placer le back-end de votre application dans un sous-réseau d’un réseau virtuel Resource Manager. Le réseau virtuel doit se trouver dans la même région que votre application. Cette fonctionnalité n’est pas disponible à partir d’un environnement ASE, qui se trouve déjà dans un réseau virtuel. Cas d’usage de cette fonctionnalité :

• Accéder à des ressources de réseaux virtuels Resource Manager dans la même région.
• Accédez aux ressources des réseaux virtuels appairés, y compris les connexions inter-régions.
• Accéder à des ressources sécurisées avec des points de terminaison de service.
• Accéder à des ressources accessibles via des connexions ExpressRoute ou VPN.
• Accédez aux ressources des réseaux privés sans le besoin ni les frais associés à une passerelle de Réseau virtuel.
• Aider à sécuriser tout le trafic sortant.
• Forcer le tunneling de tout le trafic sortant.

Pour plus d’informations, consultez Intégration au réseau virtuel App Service.

Intégration au réseau virtuel avec passerelle obligatoire

L’intégration de réseau virtuel requise par la passerelle a été la première édition de l’intégration de réseau virtuel dans App Service. La fonctionnalité fonctionne en connectant l’hôte sur lequel votre application s’exécute à une passerelle de réseau virtuel sur votre réseau virtuel en utilisant une connexion VPN point à site. Lorsque vous configurez cette fonctionnalité, votre application obtient l’une des adresses de point à site attribuées à chaque instance.

L’intégration requise par la passerelle vous permet de vous connecter directement à un réseau virtuel dans une autre région sans peering et de vous connecter à un réseau virtuel classique. La fonctionnalité est limitée au plans Windows App Service et ne fonctionne pas avec les réseaux virtuels connectés à ExpressRoute. Il est recommandé d’utiliser l’intégration du réseau virtuel régional. Pour plus d’informations sur cette fonctionnalité, consultez Intégration au réseau virtuel App Service.

Environnement App Service

Un environnement ASE est un déploiement monolocataire d’Azure App Service, qui s’exécute dans votre réseau virtuel. Cas d’usage de cette fonctionnalité :

• Accéder aux ressources de votre réseau virtuel.
• Accéder à des ressources via ExpressRoute.
• Exposer vos applications avec une adresse privée dans votre réseau virtuel.
• Accéder à des ressources via des points de terminaison de service.
• Accéder à des ressources via des points de terminaison privés.

Avec un environnement ASE, vous n’avez pas besoin d’utiliser l’intégration au réseau virtuel car l’ASE est déjà dans votre réseau virtuel. Si vous souhaitez accéder à des ressources telles que SQL ou Stockage Azure sur des points de terminaison de service, activez les points de terminaison de service sur le sous-réseau ASE. Si vous souhaitez accéder à des ressources dans le réseau virtuel ou à des points de terminaison privés, vous n’avez pas besoin d’effectuer de configuration supplémentaire. Si vous souhaitez accéder à des ressources via ExpressRoute, vous êtes déjà dans le réseau virtuel et n’avez pas besoin de configurer quoi que ce soit sur l’environnement ASE ou les applications qu’il contient.

Étant donné que les applications dans un ASE ILB peuvent être exposées sur une adresse IP privée, vous pouvez facilement ajouter des appareils de pare-feu d’applications web pour exposer uniquement les applications que vous souhaitez sur Internet tout en sécurisant le reste. Cette fonctionnalité peut faciliter le développement d’applications multiniveaux.

Certaines choses ne sont actuellement pas possibles à partir du service multilocataire, mais le sont à partir d’un environnement ASE. Voici quelques exemples :

• Héberger vos applications dans un service monolocataire.
• Effectuer un scale-up vers beaucoup plus d’instances que ce qui est possible dans le service multilocataire.
• Charger des certificats clients d’autorité de certification privée à l’usage de vos applications avec des points de terminaison sécurisés par l’autorité de certification privée.
• Forcer l’utilisation du protocole TLS 1.2 pour toutes les applications hébergées dans le système, sans possibilité de le désactiver au niveau de l’application.

L’environnement ASE offre la meilleure solution en ce qui concerne l’hébergement d’applications dédiées et isolées, mais soulève également quelques problèmes de gestion. Voici quelques points à prendre en compte avant d’utiliser un environnement ASE opérationnel :

• Un environnement ASE s’exécute à l’intérieur de votre réseau virtuel, mais présente des dépendances extérieures au réseau virtuel. Ces dépendances doivent être autorisées. Pour plus d’informations, consultez Considérations relatives à la mise en réseau pour un environnement App Service.
• Un environnement ASE n’évolue pas immédiatement comme le service multilocataire. Vous devez anticiper les besoins de mise à l’échelle, plutôt que d’effectuer une mise à l’échelle quand il est trop tard.
• Un environnement ASE a un coût initial supérieur. Afin de tirer le meilleur parti de votre ASE, vous devez planifier l’ajout de nombreuses charges de travail dans un seul ASE au lieu de ne l’utiliser que pour quelques tâches.
• Les applications dans un ASE ne peuvent pas restreindre de manière sélective l’accès à certaines applications dans l’ASE et pas à d’autres.
• Un environnement ASE se trouve dans un sous-réseau, et des règles de réseau s’appliquent à tout le trafic vers et depuis cet environnement. Si vous souhaitez attribuer des règles de trafic entrant pour une seule application, utilisez des restrictions d’accès.

Combinaison de fonctionnalités

Les fonctionnalités indiquées pour le service multilocataire peuvent être utilisées ensemble pour traiter des cas d’usage plus complexes. Deux des cas d’usage plus courants sont décrits ici, mais il s’agit uniquement d’exemples. En comprenant le fonctionnement des différentes fonctionnalités, vous pouvez répondre à pratiquement tous les besoins architecturaux de votre système.

Placer une application dans un réseau virtuel

Vous vous demandez peut-être comment placer une application dans un réseau virtuel. Si vous placez votre application dans un réseau virtuel, les points de terminaison entrants et sortants pour l’application se trouvent dans le réseau virtuel. Un environnement ASE est la meilleure façon de résoudre ce problème. Toutefois, vous pouvez répondre à la plupart de vos besoins au sein du service multilocataire en combinant des fonctionnalités. Par exemple, vous pouvez héberger des applications intranet uniquement avec des adresses entrantes et sortantes privées comme suit :

• En créant une passerelle applicative avec des adresse entrante et sortante privées.
• En sécurisant le trafic entrant vers votre application avec des points de terminaison de service.
• En utilisant la fonctionnalité d’intégration au réseau virtuel de façon à ce que le back end de votre application se trouve dans votre réseau virtuel.

Ce style de déploiement ne vous donne pas d’adresse dédiée pour le trafic sortant vers Internet, ou la possibilité de verrouiller tout le trafic sortant de votre application. Il vous apporte essentiellement ce que vous ne pourriez obtenir autrement qu’avec un environnement ASE.

Créer des applications avec plusieurs niveaux

Une application multiniveau est une application dans laquelle les applications back end d’API sont accessibles uniquement à partir du niveau frontal. Deux méthodes de création d’une application multiniveau sont possibles. Toutes deux commencent par utiliser une intégration au réseau virtuel pour connecter votre application web frontale à un sous-réseau dans un réseau virtuel. Cela permet à votre application web d’effectuer des appels dans votre réseau virtuel. Une fois votre application frontale est connectée au réseau virtuel, vous devez choisir comment verrouiller l’accès à votre application d’API. Vous pouvez :

• Héberger l’application frontale et l’application d’API dans le même ASE ILB, et exposer l’application frontale sur Internet en utilisant une passerelle applicative.
• Héberger l’application frontale dans le service multilocataire et le serveur principal dans un environnement ASE ILB.
• Héberger l’application frontale et l’application d’API dans le service multilocataire.

Si vous hébergez l’application frontale et l’application API pour une application multiniveau, vous pouvez :

• Exposer votre application d’API à l’aide de points de terminaison privés dans votre réseau virtuel :

  

• Utiliser des points de terminaison de service pour vous assurer que le trafic entrant dans votre application d’API provienne uniquement du sous-réseau qu’utilise votre application web frontale :

  

Voici quelques éléments à prendre en considération pour vous aider à choisir la méthode à utiliser :

• Lorsque vous utilisez des points de terminaison de service, vous devez uniquement sécuriser le trafic vers votre application d’API sur le sous-réseau d’intégration. Les point de terminaison de service permettent de sécuriser l’application API, mais vous pouvez toujours exfiltrer des données de votre application front-end vers d’autres applications dans App Service.
• Lorsque vous utilisez des points de terminaison privés, vous avez deux sous-réseaux en lecture, ce qui ajoute de la complexité. En outre, le point de terminaison privé est une ressource de niveau supérieur et ajoute une surcharge de gestion. L’avantage de l’utilisation de points de terminaison privés est qu’ils éliminent la possibilité d’exfiltration de données.

Les deux méthodes fonctionnent avec plusieurs serveurs frontaux. À petite échelle, les points de terminaison de service sont plus faciles à utiliser, car il vous suffit d’activer les points de terminaison de service pour l’application d’API sur le sous-réseau d’intégration frontal. À mesure que vous ajoutez des applications frontales, vous devez ajuster chaque application d’API pour inclure des points de terminaison de service avec le sous-réseau d’intégration. Lorsque vous utilisez des points de terminaison privés, vous avez plus de complexité, mais vous n’avez rien à modifier sur vos applications d’API après avoir défini un point de terminaison privé.

applications métier ;

Les applications métier sont des applications internes qui ne sont normalement pas exposées pour un accès depuis Internet. Ces applications sont appelées à partir de réseaux d’entreprise où l’accès peut être strictement contrôlé. Si vous utilisez un ASE ILB, il est facile d’héberger vos applications métier. Si vous utilisez le service multilocataire, vous pouvez utiliser des points de terminaison privés ou des points de terminaison de service associés à une passerelle applicative. Il existe deux raisons d’utiliser une passerelle applicative avec des points de terminaison de service plutôt que des points de terminaison privés :

• Vous avez besoin d’une protection WAF sur vos applications métier.
• Vous souhaitez équilibrer la charge sur plusieurs instances de vos applications métier.

Si aucun de ces besoins ne s’applique, il est préférable d’utiliser des points de terminaison privés. Avec les points de terminaison privés disponibles dans App Service, vous pouvez exposer vos applications sur des adresses privées de votre réseau virtuel. Le point de terminaison privé que vous placez dans votre réseau virtuel peut être atteint via des connexions ExpressRoute et VPN.

La configuration de points de terminaison privés expose vos applications sur une adresse privée, mais vous devez configurer un DNS pour atteindre cette adresse en local. Pour que cette configuration fonctionne, vous devez transférer la zone Azure DNS privée contenant vos points de terminaison privés vers vos serveurs DNS locaux. Les zones privées Azure DNS ne prennent pas en charge le transfert de zone, mais vous pouvez le prendre en charge à l’aide d’Azure DNS Private Resolver.

Ports App Service

Si vous analysez App Service, vous trouverez plusieurs ports exposés pour les connexions entrantes. Il n’existe aucun moyen de bloquer ou de contrôler l’accès à ces ports dans le service multilocataire. Voici la liste des ports exposés :

Utilisation	Port ou ports
HTTP/HTTPS	80, 443
Gestion	454, 455
FTP/FTPS	21, 990, 10001-10300
Débogage distant de Visual Studio	4020, 4022, 4024
Service Web Deploy	8172
Utilisation de l’infrastructure	7654, 1221