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 et v2 ont été 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 31 août 2024, le Contrat de niveau de service (SLA) et les crédits de service ne s’appliquent plus aux charges de travail App Service Environment v1 et v2 qui sont toujours en production depuis que ce sont des produits mis hors service. La mise hors service du matériel App Service Environment v1 et v2 a commencé, ce qui risque d’avoir une incidence sur la disponibilité et les performances de vos applications et de vos données.
Vous devez effectuer la migration vers App Service Environment v3 immédiatement, sans quoi vos applications et ressources risquent d’être supprimées. Nous ferons tout notre possible pour migrer automatiquement les charges de travail App Service v1 et v2 restantes à l’aide de la fonctionnalité de migration sur place, mais Microsoft ne garantit nullement ni n’affirme que les applications seront disponibles après la migration automatique. Vous serez peut-être amené à effectuer une configuration manuelle pour finaliser la migration et choisir la référence SKU du plan App Service la mieux adaptée à vos besoins. Si la migration automatique n’est pas possible, vos ressources et les données d’application associées seront supprimées. Nous vous recommandons vivement d’agir dès maintenant pour éviter l’un ou l’autre de ces scénarios extrêmes.
Si vous avez besoin de plus de temps, nous pouvons offrir une seule période de grâce de 30 jours pour vous permettre d’effectuer votre migration. Pour plus d’informations et pour demander cette période de grâce, passez en revue la vue d’ensemble de la période de grâce, puis accédez au portail Azure et au panneau Migration pour chacun de vos environnements App Service.
Pour obtenir les informations les plus à jour sur la mise hors service d’App Service Environment v1/v2, consultez la Mise à jour sur la mise hors service d’App Service Environment v1 et v2.
É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 :
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.
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 :
Prise en main
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.