Se connecter en toute sécurité aux ressources principales à partir d'un environnement App Service

Important

Cet article traite de l’environnement App Service Environment v1. App Service Environment v1 sera mis hors service le 31 août 2024. Il existe une nouvelle version d’App Service Environment, plus facile à utiliser et qui s’exécute sur des infrastructures plus puissantes. Pour en savoir plus sur la nouvelle version, commencez par consulter Présentation de l’environnement App Service Environment. Si vous utilisez actuellement App Service Environment v1, suivez les étapes de cet article pour migrer vers la nouvelle version.

À compter du 29 janvier 2024, vous ne pouvez plus créer de ressources App Service Environment v1 en utilisant une des méthodes disponibles, y compris les modèles ARM/Bicep, le portail Microsoft Azure, Azure CLI ou l’API REST. Vous devez migrer vers App Service Environment v3 avant le 31 août 2024 pour empêcher la suppression des ressources et la perte de données.

Étant donné qu’un environnement App Service est toujours créé soit dans un réseau virtuel Azure Resource Manager ou un réseau virtuel de modèle de déploiement classique, les connexions sortantes d’un environnement App Service à destination d’autres ressources de back-end peuvent passer exclusivement sur le réseau virtuel. Depuis juin 2016, les environnements ASE peuvent également être déployés dans les réseaux virtuels qui utilisent soit des plages d’adresses publiques, soit des espaces d’adressage RFC1918 (adresses privées).

Par exemple, un serveur SQL Server peut être en cours d'exécution sur un cluster de machines virtuelles dont le port 1433 est verrouillé. Le point de terminaison peut être placé dans une liste de contrôle d'accès pour autoriser uniquement l'accès à partir d'autres ressources se trouvant sur le même réseau virtuel.

De même, les points de terminaison sensibles peuvent s’exécuter localement et être connectés à Azure via des connexions de site à site ou Azure ExpressRoute. Par conséquent, seules les ressources des réseaux virtuels connectés aux tunnels de site à site ou ExpressRoute peuvent accéder aux points de terminaison locaux.

Dans tous ces scénarios, les applications s’exécutant dans un environnement ASE peuvent se connecter de façon sécurisée aux différents serveurs et aux différentes ressources. Si le trafic sortant des applications s’effectue dans un environnement ASE vers des points de terminaison privés se trouvant sur le même réseau virtuel ou connectés au même réseau virtuel, il ne circule que sur le réseau virtuel. Le trafic sortant vers des points de terminaison privés ne passe pas par l’Internet public.

Le trafic sortant d’un environnement ASE vers des points de terminaison se trouvant sur un réseau virtuel présente un problème. En effet, les environnements ASE ne peuvent pas atteindre les points de terminaison de machines virtuelles situés dans le même sous-réseau qu’eux. Cette limitation ne devrait normalement pas poser de problème tant que les environnements ASE sont déployés dans un sous-réseau réservé à leur usage exclusif.

Notes

Même si cet article fait référence aux applications Web, il s’applique également aux applications API et aux applications mobiles.

Connectivité sortante et configuration DNS requise

Pour qu’un environnement App Service fonctionne correctement, il requiert un accès sortant à différents points de terminaison. Une liste complète des points de terminaison externes utilisés par un ASE est disponible dans la section « Connectivité réseau requise » de l’article Configuration réseau pour ExpressRoute .

Les environnements App Service nécessitent une infrastructure DNS valide configurée pour le réseau virtuel. Si la configuration DNS est modifiée après la création d’un environnement ASE, les développeurs peuvent forcer ce dernier à utiliser la nouvelle configuration DNS. En haut du panneau de gestion de l’environnement ASE du portail, sélectionnez l’icône Redémarrer pour déclencher le redémarrage d’un environnement propagé, à la suite de quoi celui-ci récupère la nouvelle configuration DNS.

Il est également recommandé de configurer les serveurs DNS personnalisés sur le réseau virtuel à l’avance, avant de créer un environnement ASE. Si la configuration DNS d’un réseau virtuel est modifiée pendant la création d’un environnement ASE, ce processus de création échoue. À l’autre extrémité d’une passerelle VPN, si un serveur DNS personnalisé n’est pas accessible ou disponible, le processus de création de l’environnement ASE échoue également.

Connexion à un serveur SQL Server

Une configuration courante de SQL Server comprend un point de terminaison qui écoute sur le port 1433 :

SQL Server Endpoint

Pour limiter le trafic sur ce point de terminaison, vous avez le choix entre deux approches :

Restriction de l'accès à l'aide d'une ACL réseau

Le port 1433 peut être sécurisé à l'aide d'une liste de contrôle d'accès réseau. L’exemple ci-dessous ajoute aux autorisations d’affectation les adresses de clients provenant d’un réseau virtuel, et bloque l’accès à tous les autres clients.

Network Access Control List Example

Toutes les applications qui s’exécutent dans un environnement ASE, sur le même réseau virtuel que SQL Server, peuvent se connecter à l’instance SQL Server. Utilisez l’adresse IP interne du réseau virtuel pour la machine virtuelle SQL Server.

L'exemple de chaîne de connexion ci-dessous fait référence au serveur SQL Server en utilisant son adresse IP privée.

Server=tcp:10.0.1.6;Database=MyDatabase;User ID=MyUser;Password=PasswordHere;provider=System.Data.SqlClient

Même si la machine virtuelle possède également un point de terminaison public, les tentatives de connexion visant à utiliser l’adresse IP publique sont rejetées en raison de la liste ACL réseau.

Restriction de l'accès à l'aide d'un groupe de sécurité réseau

Un groupe de sécurité réseau constitue une autre approche de sécurisation de l'accès. Les groupes de sécurité réseau peuvent être appliqués à des machines virtuelles individuelles ou à un sous-réseau comprenant des machines virtuelles.

Tout d’abord, vous devez créer un groupe de sécurité réseau :

New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"

Il est facile de restreindre l’accès au seul trafic interne du réseau virtuel à l’aide d’un groupe de sécurité réseau. Les règles par défaut d'un groupe de sécurité réseau autorisent l'accès uniquement à partir d'autres clients réseau du même réseau virtuel.

Par conséquent, le verrouillage de l’accès à SQL Server est simple. Il suffit d’appliquer un groupe de sécurité réseau avec ses règles par défaut aux machines virtuelles exécutant SQL Server ou au sous-réseau dans lequel elles se trouvent.

L'exemple ci-dessous applique un groupe de sécurité réseau au sous-réseau conteneur :

Get-AzureNetworkSecurityGroup -Name "testNSGExample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-1'

Le résultat final est un ensemble de règles de sécurité qui bloquent l’accès externe, tout en autorisant l’accès interne au réseau virtuel :

Default Network Security Rules

Bien démarrer

Pour prendre en main les environnements App Service, consultez Présentation de l'environnement App Service

Pour plus d’informations sur le contrôle du trafic entrant vers votre environnement App Service, consultez Contrôle du trafic entrant vers un environnement App Service

Notes

Si vous voulez vous familiariser avec Azure App Service avant d’ouvrir un compte Azure, accédez à la page Essayer App Service, où vous pourrez créer immédiatement une application web temporaire dans App Service. Aucune carte de crédit n’est requise ; vous ne prenez aucun engagement.