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. Pour de nombreuses 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é. Utilisez cet article pour vous aider à déterminer quelle fonctionnalité utiliser, en fonction d’exemples de cas d’utilisation.

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

• Le service public mutualisé 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 dépendent du fait que vous soyez dans le service multilocataire ou dans un ASE.

Remarque

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

Fonctionnalités réseau App Service mutualisées

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 mutualisé. 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 requêtes adressées à votre application ne peuvent pas être utilisées pour résoudre les problèmes lorsque vous passez des appels à partir de 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 client sur des rôles de travail mutualisés. 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 réparties en grande partie selon les plans App Service. Les plans Gratuit, Partagé, Essentiel, Standard et Premium utilisent tous le même type de machine virtuelle de travail. Le plan PremiumV2 utilise un autre type de machine virtuelle. PremiumV3 utilise un autre type de machine virtuelle.

Lorsque vous modifiez la famille de machines virtuelles, vous obtenez un ensemble différent d’adresses sortantes. Si vous passez de Standard à PremiumV2, vos adresses sortantes changent. Si vous passez de PremiumV2 à PremiumV3, vos adresses sortantes changent. Dans certaines unités d'échelle plus anciennes, les adresses entrantes et sortantes changent lorsque vous passez de Standard à 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. Toutes les applications qui s’exécutent sur la même famille de machines virtuelles de travail dans le déploiement App Service partagent ces adresses. 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. Pour y accéder, configurez 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. L'adresse attribuée à votre application est utilisée uniquement par votre application. 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 frontaux qui sont en amont des rôles de travail sur lesquels 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, consultez Restrictions d’accès à Azure App Service.

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 environnement ASE ou dans le service mutualisé. Lorsqu’elle est utilisée avec un ASE ILB, vous pouvez restreindre l’accès à partir de blocs d’adresses privées. Pour plus d’informations, consultez Configurer des restrictions d’accès Azure App Service.

Remarque

Vous pouvez configurer jusqu'à 512 règles de restriction d'accès 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 Utiliser des points de terminaison privés pour les application App service.

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. La seule chose que vous pouvez atteindre via le point de terminaison privé est l'application avec laquelle il est configuré.

Périmètre de sécurité réseau

Le périmètre de sécurité réseau (NSP) Azure est un service qui fournit un périmètre sécurisé pour la communication des services Platform as a service (PaaS). Ces services PaaS peuvent communiquer entre eux au sein du périmètre. Ils peuvent également communiquer avec des ressources extérieures au périmètre à l’aide de règles d’accès entrant et sortant publiques.

L’application des règles NSP utilise principalement la sécurité basée sur l’identité. Cette approche ne peut pas être entièrement appliquée dans les services de plateforme tels que App Services et Functions qui vous permettent de déployer votre propre code et d'utiliser l'identité pour représenter la plateforme. Si vous devez communiquer avec des services PaaS qui font partie d'un NSP, ajoutez l'intégration de réseau virtuel à vos instances App Service ou Functions. Communiquez avec les ressources PaaS à l’aide de points de terminaison privés.

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 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 les connexions hybrides, vous ne pouvez atteindre qu'un seul hôte et un seul port.
• 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 l'utiliser pour accéder à une base de données, à un service Web ou à un socket TCP arbitraire sur un mainframe. La fonctionnalité crée essentiellement des tunnels pour les paquets TCP.

Les connexions hybrides sont populaires pour le développement. Vous pouvez également l'utiliser 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 avoir besoin ni coûter une passerelle de réseau virtuelle.
• 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é utilise un VPN point à site pour connecter l’hôte sur lequel votre application s’exécute à une passerelle de réseau virtuel sur votre réseau virtuel. 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. Nous vous recommandons d’utiliser l’intégration du réseau virtuel régional. Pour plus d’informations, voir Configurer l’intégration du réseau virtuel requise par la passerelle.

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 d’un ASE ILB peuvent être exposées sur une adresse IP privée, vous pouvez ajouter des périphériques WAF pour exposer uniquement certaines applications à Internet. Ne pas exposer les autres permet de préserver la sécurité des autres. Cette fonctionnalité peut faciliter le développement d’applications multiniveaux.

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

• Hébergez vos applications dans un service locataire unique.
• Effectuer un scale-up vers beaucoup plus d’instances que ne le permet le service mutualisé.
• 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'ASE fournit la meilleure histoire autour de Hosting d'applications isolées et dédiées. Cette approche implique certains défis de gestion. Voici quelques points à prendre en compte avant d’utiliser un environnement ASE opérationnel :

• Un ASE s’exécute à l’intérieur de votre réseau virtuel, mais il possède des dépendances en dehors du 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 mutualisé. Vous devez anticiper les besoins de mise à l’échelle, plutôt que d’effectuer une mise à l’échelle quand il est trop tard.
• Un ASE a un coût initial plus élevé. 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 ASE est dans un sous-réseau. Toutes les règles de mise en réseau s’appliquent à tout le trafic vers et depuis cet ASE. 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 mutualisé peuvent être utilisées ensemble pour traiter des cas d’usage plus complexes. Deux des cas d’utilisation les plus courants sont décrits ici à titre 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 mutualisée 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 ni la possibilité de verrouiller tout le trafic sortant de votre application. Il vous offre une grande partie de ce que vous n'obtiendriez autrement qu'avec un 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 vers votre réseau virtuel. Une fois votre application front-end connectée au réseau virtuel, décidez comment verrouiller l’accès à votre application 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 le serveur frontal dans le service mutualisé et le back end dans un ASE ILB.
• Héberger le serveur frontal et l’application d’API dans le service mutualisé.

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 interfaces front-end. À 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 mutualisé, 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. Vous devez configurer le DNS pour atteindre cette adresse à partir de vos locaux. Pour que cette configuration fonctionne, transférez Azure DNS Private Zone qui contient 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 mutualisé. 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