Restrictions d’accès dans Azure App Service

Les restrictions d’accès dans App Service sont l’équivalent d’un pare-feu qui vous permet de bloquer et de filtrer le trafic. Les restrictions d’accès s’appliquent uniquement à l’accès entrant. La plupart des niveaux tarifaires App Service offrent aussi la possibilité d’ajouter des points de terminaison privés à l’application, ce qui constitue un autre point d’entrée à l’application. Les restrictions d’accès ne s’appliquent pas au trafic entrant via un point de terminaison privé. Pour toutes les applications hébergées sur App Service, le point d’entrée par défaut est disponible publiquement. Les seules exceptions sont les applications hébergées dans l’équilibreur de charge interne App Service Environment, où le point d’entrée par défaut est interne au réseau virtuel.

Fonctionnement

Lorsque le trafic atteint App Service, il évalue d’abord si le trafic provient d’un point de terminaison privé ou passe par le point de terminaison par défaut. Si le trafic est envoyé via un point de terminaison privé, il envoie directement au site sans aucune restriction. Les restrictions relatives aux points de terminaison privés sont configurées à l’aide de groupes de sécurité réseau.

Si vous envoyez du trafic via le point de terminaison par défaut (souvent un point de terminaison public), le trafic est d'abord évalué au niveau de l'accès à l'application. Ici, vous pouvez activer ou désactiver l’accès. Si vous activez l'accès aux applications, le trafic est évalué au niveau de l'accès au site. Pour n’importe quelle application, vous avez à la fois le site principal et le site d’outils avancés (également appelé site scm ou kudu).

Vous avez la possibilité de configurer un ensemble de règles de restriction d’accès pour chaque site. Les règles de restriction d'accès sont évaluées par ordre de priorité. Si certaines règles ont la même priorité, elles sont évaluées dans l'ordre dans lequel elles sont répertoriées lorsqu'elles sont renvoyées depuis l'API Azure Resource Manager et dans le portail Azure avant le tri. Vous pouvez également spécifier le comportement si aucune règle n’est mise en correspondance. Les sections suivantes vont plus dans le détail.

Accès de l’application

L’accès aux applications vous permet de configurer si l’accès est disponible via le point de terminaison par défaut (public). Vous configurez ce comportement pour être Disabled ou Enabled. Lorsque l’accès est activé, vous pouvez ajouter des règles de restriction d’accès au site pour contrôler l’accès à partir de réseaux virtuels et d’adresses IP sélectionnés. Si le paramètre n’est pas configuré, le comportement par défaut consiste à activer l’accès, sauf s’il existe un point de terminaison privé qui modifie le comportement de façon à désactiver l’accès.

Dans l’API Azure Resource Manager, l’accès à l’application est appelé publicNetworkAccess. Pour l’App Service Environment ILB, le point d'entrée par défaut pour les applications est toujours interne au réseau virtuel. L’activation de l’accès à l’application (publicNetworkAccess) n’accorde pas d’accès public direct aux applications. Au lieu de cela, elle autorise l’accès à partir du point d’entrée par défaut, qui correspond à l’adresse IP interne de l’App Service Environment. Si vous désactivez l’accès aux applications sur un App Service Environment ILB, vous pouvez uniquement accéder aux applications via des points de terminaison privés ajoutés aux applications individuelles.

Accès au site

Les restrictions d’accès au site vous permettent de filtrer les demandes entrantes. Les restrictions d’accès au site vous permettent 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.

La restriction d’accès au site comporte plusieurs types de règles que vous pouvez appliquer :

Règle sans correspondance

Vous pouvez configurer le comportement quand aucune règle n’est mise en correspondance (action par défaut). Il s’agit d’une règle spéciale qui apparaît toujours comme la dernière règle de la collection de règles. Si le paramètre n’est pas configuré, le comportement de règle sans correspondance dépend des règles configurées. S’il n’existe aucune règle, le comportement de règle sans correspondance consiste à autoriser tout accès, mais s’il existe une ou plusieurs règles, le comportement change implicitement de façon à refuser tout accès. Vous pouvez configurer explicitement ce comportement pour autoriser ou refuser l’accès indépendamment des règles définies.

Règles de restrictions d’accès basées sur IP

La fonctionnalité des restrictions d’accès basées sur IP est utile quand vous souhaitez limiter les adresses IP qui peuvent être utilisées pour atteindre votre application. IPv4 et IPv6 sont pris en charge. Cas d’usage de cette fonctionnalité :

• Restreindre l’accès à votre application à partir d’un ensemble d’adresses bien définies.
• Restreindre l’accès au trafic en provenance d’un service d’équilibrage de charge externe ou d’autres appliances réseau dont les adresses IP de sortie sont connues.

Pour découvrir comment activer cette fonctionnalité, voir Restrictions d’accès dans Azure App Service.

Notes

Les règles de restriction d’accès basées sur l’IP ne gèrent les plages d’adresses de réseau virtuel que lorsque votre application se trouve dans un App Service Environment. Si votre application se trouve dans le service multilocataire, vous devez utiliser des points de terminaison de service pour limiter le trafic à certains sous-réseaux de votre réseau virtuel.

Règles de restriction d’accès basées sur des points de terminaison de service

Les points de terminaison de service vous permettent de verrouiller l’accès entrant à votre application, de façon que l’adresse source doive faire partie d’un ensemble de sous-réseaux que vous sélectionnez. Cette fonctionnalité opère conjointement avec les restrictions d’accès IP. Les points de terminaison de service ne sont pas compatibles avec le débogage à distance. Si vous voulez utiliser le débogage à distance avec votre application, votre client ne peut pas se trouver dans un sous-réseau dans lequel des points de terminaison de service sont activés. Le processus de définition de points de terminaison de service est similaire au processus de définition de restrictions d’accès IP. Vous pouvez créer une liste d’autorisation/de refus des règles d’accès qui inclut des adresses publiques, ainsi que des sous-réseaux dans vos réseaux virtuels.

Notes

Les règles de restriction d’accès basées sur les points de terminaison de service ne sont pas prises en charge sur les applications qui ont un point de terminaison privé configuré ni sur les applications qui utilisent le protocole SSL basé sur IP (adresse affectée à l’application).

Pour en savoir plus sur la configuration des points de terminaison de service avec votre application, consultez Restrictions d’accès dans Azure App Service.

Toute source de point de terminaison de service

Pour les tests ou dans des scénarios spécifiques, vous pouvez autoriser le trafic à partir de n’importe quel sous-réseau compatible avec les points de terminaison de service. Pour ce faire, vous pouvez définir une règle basée sur IP avec le texte « AnyVnets » au lieu d’une plage d’adresses IP. Vous ne pouvez pas créer ces règles dans le portail, mais vous pouvez modifier une règle basée sur IP existante et remplacer l’adresse IP par la chaîne « AnyVnets ».

Règles de restriction d’accès basées sur des étiquettes de service

Les étiquettes de service Azure sont des ensembles bien définis d’adresses IP pour les services Azure. Les étiquettes de service regroupent les plages d’adresses IP utilisées dans différents services Azure et sont souvent également étendues à des régions spécifiques. Ce type de règle vous permet de filtrer le trafic entrant à partir de services Azure spécifiques.

Pour une liste complète des étiquettes et plus d'informations, visitez le lien de l'étiquette de service.

Pour découvrir comment activer cette fonctionnalité, voir Restrictions d’accès dans Azure App Service.

Règles à plusieurs sources

Les règles à plusieurs sources vous permettent de combiner jusqu’à huit plages d’adresses IP ou huit étiquettes de service dans une seule règle. Vous pouvez utiliser des règles multi-sources si vous avez plus de 512 plages d’adresses IP. Vous pouvez également utiliser des règles multi-sources si vous souhaitez créer des règles logiques où plusieurs plages d’adresses IP sont combinées avec un seul filtre d’en-tête HTTP.

Les règles à plusieurs sources sont définies de la même façon que vous définissez des règles à source unique, mais chaque plage est séparée par une virgule.

Vous ne pouvez pas créer ces règles dans le portail, mais vous pouvez modifier une balise de service existante ou une règle basée sur IP et ajouter d’autres sources à la règle.

Filtrage d’en-tête HTTP pour les règles de restriction d’accès au site

Pour n’importe quelle règle, quel que soit le type, vous pouvez ajouter le filtrage d’en-tête HTTP. Les filtres d’en-tête HTTP vous permettent d’examiner plus en détail la requête entrante et de filtrer selon des valeurs d’en-tête HTTP spécifiques. Chaque en-tête peut comporter jusqu’à huit valeurs par règle. Vous trouverez ci-dessous la liste des en-têtes HTTP pris en charge :

• X-Forwarded-For. En-tête standard pour identifier l’adresse IP d’origine d’un client qui se connecte via un serveur proxy. Accepte les valeurs CIDR valides.
• X-Forwarded-Host. En-tête standard pour identifier l’hôte d’origine demandé par le client. Accepte toute chaîne jusqu’à 64 caractères de longueur.
• X-Azure-FDID. En-tête personnalisé pour identifier l’instance de proxy inverse. Azure Front Door envoie un guid identifiant l’instance, mais il peut également être utilisé par des proxys non-Microsoft pour identifier l’instance spécifique. Accepte toute chaîne jusqu’à 64 caractères de longueur.
• X-FD-HealthProbe. En-tête personnalisé pour identifier la sonde d’intégrité du proxy inverse. Azure Front Door envoie « 1 » pour identifier de manière unique une demande de sonde d’intégrité. L’en-tête peut également être utilisé par des proxys non-Microsoft pour identifier les sondes d’intégrité. Accepte toute chaîne jusqu’à 64 caractères de longueur.

Voici quelques cas d’usage du filtrage d’en-tête HTTP :

• Restreindre l’accès au trafic des serveurs proxy qui transfèrent le nom d’hôte
• Restreindre l’accès à une instance d’Azure Front Door spécifique avec une règle d’étiquette de service et une restriction d’en-tête X-Azure-FDID

la journalisation des diagnostics.

App Service peut envoyer diverses catégories de journalisation à Azure Monitor. L’une de ces catégories est appelée IPSecurity Audit logs et représente les activités de restrictions d’accès. Toutes les requêtes qui correspondent à une règle (à l’exception de la règle sans correspondance), autorisent et refusent, sont journalisées et peuvent être utilisées pour valider la configuration des restrictions d’accès. La capacité de journalisation est également un outil puissant lors de la résolution des problèmes de configuration des règles.

Cas d’usage avancés

La combinaison des fonctionnalités ci-dessus vous permet de résoudre certains cas d’usage spécifiques décrits dans les sections suivantes.

Bloquer une adresse IP unique

Si vous souhaitez refuser/bloquer une ou plusieurs adresses IP spécifiques, vous pouvez ajouter les adresses IP en tant que règles de refus et configurer la règle sans correspondance pour autoriser tout le trafic sans correspondance.

Restreindre l’accès au site d’outils avancés

Le site d’outils avancés, également appelé scm ou kudu, possède une collection de règles individuelle que vous pouvez configurer. Vous pouvez également configurer la règle sans correspondance pour ce site. Un paramètre vous permet d’utiliser les règles configurées pour le site principal. Vous ne pouvez pas autoriser l’accès de manière sélective à certaines fonctionnalités du site d’outils avancés. Par exemple, vous ne pouvez pas autoriser l’accès de manière sélective uniquement à la console de gestion WebJobs du site d’outils avancés.

Déployer via un point de terminaison privé

Vous pouvez avoir un site accessible publiquement, mais votre système de déploiement se trouve dans un réseau virtuel. Vous pouvez garder le trafic de déploiement privé en ajoutant un point de terminaison privé. Vous devez ensuite vous assurer que l’accès à l’application publique est activé. Enfin, vous devez définir la règle sans correspondance pour que le site d’outils avancés refuse, ce qui bloque tout le trafic public vers ce point de terminaison.

Autoriser l’accès du partenaire externe au site protégé par un point de terminaison privé

Dans ce scénario, vous accédez à votre site via un point de terminaison privé et effectuez un déploiement via un point de terminaison privé. Vous pouvez inviter temporairement un partenaire externe à tester le site. Vous pouvez le faire en activant l’accès aux applications publiques. Ajoutez une règle (basée sur IP) pour identifier le client du partenaire. Configurez une action de règles sans correspondance pour refuser pour le site d’outils principaux et avancés.

Restreindre l’accès à une instance Azure Front Door spécifique

Le trafic entre Azure Front Door et votre application provient d’un ensemble bien connu de plages d’adresses IP définies dans l’étiquette de service AzureFrontDoor.Backend. Une règle de restriction d’étiquette de service vous permet de limiter le trafic à partir d’Azure Front Door. Pour garantir que le trafic provient uniquement de votre instance spécifique, vous devez filtrer davantage les demandes entrantes en fonction de l’en-tête HTTP unique envoyé par Azure Front Door et appelé X-Azure-FDID. Vous trouverez l’ID Front Door dans le portail.

Étapes suivantes

Notes

Les règles de restriction d’accès interdisant l’accès public à votre site peuvent également bloquer des services tels que le streaming de journaux. Si vous en avez besoin, vous devez autoriser l’adresse IP de votre App Service dans vos restrictions.

Procédure à suivre pour restreindre l’accès

Points de terminaison privés pour les applications App Service