Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les paramètres principaux vous permettent de gérer les configurations des connexions principales établies à partir d’une ressource de passerelle d’application vers un serveur du pool principal. Une configuration des paramètres principaux peut être associée à une ou plusieurs règles de routage.
Types de paramètres principaux dans Application Gateway
Bien que les utilisateurs du portail voient uniquement l’option « Paramètres principaux », les utilisateurs d’API ont accès à deux types de paramètres. Vous devez utiliser la configuration correcte, en fonction du protocole.
- Paramètres HTTP principaux : il s’agit des configurations de proxy de couche 7 qui prennent en charge les protocoles HTTP et HTTPS.
- Paramètres Backend : il s’agit des configurations de proxy Layer 4 (préversion) qui prennent en charge les protocoles TLS et TCP.
Affinité basée sur les cookies
Azure Application Gateway utilise des cookies gérés par passerelle pour gérer les sessions utilisateur. Lorsqu’un utilisateur envoie la première requête à Application Gateway, il définit un cookie d’affinité dans la réponse avec une valeur de hachage qui contient les détails de la session. Ce processus permet aux requêtes suivantes qui transportent le cookie d’affinité d’être routés vers le même serveur back-end, ce qui permet de maintenir l’adhérence.
Cette fonctionnalité est pratique quand vous voulez conserver une session utilisateur sur le même serveur et quand l’état de session est enregistré localement sur le serveur pour une session utilisateur. Si l’application ne peut pas gérer l’affinité basée sur les cookies, vous ne pouvez pas utiliser cette fonctionnalité. Pour l’utiliser, assurez-vous que les clients prennent en charge les cookies.
Remarque
Certaines analyses de vulnérabilité peuvent marquer le cookie d’affinité Application Gateway, car les indicateurs Secure ou HttpOnly ne sont pas définis. Ces analyses ne tiennent pas compte du fait que les données du cookie sont générées à l’aide d’un hachage unidirectionnel. Le cookie ne contient pas d’informations utilisateur et est utilisé exclusivement pour le routage.
La mise à jour v80 du navigateur Chromium a imposé que les cookies HTTP sans attribut SameSite soient traités comme SameSite=Lax. Pour les requêtes CORS (Cross-Origin Resource Sharing), si le cookie doit être envoyé dans un contexte tiers, il doit utiliser les attributs SameSite=None; Secure et il doit être envoyé seulement via HTTPS. Dans le cas contraire, dans un scénario HTTP uniquement, le navigateur n’envoie pas les cookies dans le contexte tiers. L’objectif de cette mise à jour à partir de Chrome est d’améliorer la sécurité et d’éviter les attaques par falsification de requête intersites (CSRF).
Pour prendre en charge ce changement, à partir du 17 février 2020, Application Gateway (tous les types de références SKU) injecte un autre cookie appelé ApplicationGatewayAffinityCORS en plus du cookie ApplicationGatewayAffinity existant. Deux attributs supplémentaires (« SameSite=None; Secure ») ont été ajoutés au cookie ApplicationGatewayAffinityCORS de sorte que les sessions persistantes soient maintenues même pour les requêtes cross-origin.
Le nom du cookie d’affinité par défaut est ApplicationGatewayAffinity et vous pouvez le modifier. Si, dans votre topologie de réseau, vous déployez plusieurs passerelles d’application en ligne, vous devez définir des noms de cookies uniques pour chaque ressource. Si vous utilisez un nom de cookie d’affinité personnalisé, un cookie supplémentaire est ajouté avec le suffixe CORS. Par exemple : CustomCookieNameCORS.
Remarque
Si l’attribut SameSite=None est défini, il est obligatoire que le cookie contienne également l’indicateur Sécurisé et qu’il doit être envoyé via HTTPS. Si l’affinité de session est exigée sur CORS, vous devez migrer votre charge de travail vers HTTPS. Reportez-vous à la documentation sur le déchargement TLS et le TLS de bout en bout pour l'Application Gateway. Consultez la vue d’ensemble du protocole SSL, Configurer une passerelle d’application avec arrêt TLS et configurer le protocole TLS de bout en bout.
Vidage des connexions
Le drainage des connexions vous permet de supprimer correctement les membres d’un pool de back-ends pendant les mises à jour de service planifiées. Elle s’applique aux instances principales qui sont explicitement supprimées du pool principal.
Vous pouvez appliquer ce paramètre à tous les membres d’un pool de backend en activant le drainage des connexion dans les paramètres du backend. Cela garantit que toutes les instances de désinscription dans un pool principal ne reçoivent pas de nouvelles requêtes/connexions tout en conservant les connexions existantes jusqu’à la valeur de délai d’expiration configurée. Ce processus est également vrai pour les connexions WebSocket.
| Type de configuration | Valeur |
|---|---|
| Valeur par défaut lorsque le drainage de connexion n’est pas activé dans le paramètre principal | 30 secondes |
| Valeur définie par l’utilisateur quand le drainage de connexion est activé dans le paramètre du back-end | 1 à 3 600 secondes |
La seule exception à ce processus est que les demandes sont liées à la désinscription des instances en raison de l’affinité de session gérée par la passerelle. Ces demandes continuent d’être transférées aux instances de désinscription.
Remarque
Il existe une limitation selon laquelle une mise à jour de configuration met fin aux connexions en cours après le délai de drainage de connexion. Pour résoudre cette limitation, vous devez augmenter le délai d’expiration de la connexion dans les paramètres back-end à une valeur supérieure à la durée de téléchargement maximale attendue du client.
Protocole
Application Gateway prend en charge les protocoles HTTP et HTTPS pour router les requêtes vers les serveurs back-end. Si vous choisissez HTTP, le trafic vers les serveurs back-end n’est pas chiffré. Si des communications non chiffrées ne sont pas acceptables, sélectionnez HTTPS.
Ce paramètre combiné avec HTTPS dans l’écouteur prend en charge le chiffrement TLS de bout en bout. Celui-ci vous permet de transmettre en toute sécurité des données sensibles chiffrées au serveur back-end. Chaque serveur back-end du pool de back-ends pour lequel un chiffrement TLS de bout en bout est activé doit être configuré avec un certificat afin de sécuriser la communication.
Port
Ce paramètre spécifie le port où les serveurs back-end écoutent le trafic provenant de la passerelle applicative Application Gateway. Vous pouvez configurer des ports allant de 1 à 65535.
Certificat racine approuvé
Lors de la sélection du protocole HTTPS dans les paramètres principaux, la ressource application gateway utilise son magasin de certificats d’autorité de certification racine approuvé par défaut pour vérifier la chaîne et l’authenticité du certificat fourni par le serveur principal.
Par défaut, la ressource Application Gateway inclut des certificats d’autorité de certification populaires, autorisant des connexions TLS principales transparentes lorsque le certificat de serveur principal est émis par une autorité de certification publique. Toutefois, si vous envisagez d’utiliser une autorité de certification privée ou un certificat auto-généré avec validation TLS complète, vous devez fournir le certificat d’autorité de certification racine correspondant (.cer) dans la configuration des paramètres principaux.
Paramètres de validation HTTPS du back-end
Lorsque HTTPS est sélectionné dans les paramètres principaux d’Azure Application Gateway, la passerelle effectue une validation de négociation TLS complète tout en établissant une connexion sécurisée avec des serveurs principaux. Ces validations comprennent :
- Vérification de la chaîne de certificats pour vérifier que le certificat est approuvé.
- Vérification du nom d’objet du certificat par rapport à l’indication de nom de serveur (SNI) envoyée par Application Gateway.
- Vérification de l’expiration du certificat pour confirmer si le certificat est toujours valide.
Les paramètres de validation par défaut garantissent une communication TLS sécurisée entre la passerelle et les services principaux. Dans certains scénarios, il peut être nécessaire d’ajuster un ou plusieurs de ces paramètres de validation. Pour répondre à diverses exigences des clients, Application Gateway propose les options configurables suivantes. Vous pouvez utiliser l’une ou l’autre des options en fonction des besoins.
| Propriétés | Valeurs |
|---|---|
| validateCertChainAndExpiry | Type : booléen (true ou false). Le paramètre par défaut est true. Cela vérifie ou ignore à la fois la chaîne de certificats et les vérifications d’expiration. |
| validateSNI | Type : booléen (true ou false). Le paramètre par défaut est true. Il vérifie si le nom commun du certificat fourni par le serveur principal correspond à la valeur SNI (Server Name Indication) envoyée par Application Gateway. |
| sniName | Type : chaîne. Cette propriété est requise uniquement lorsque validateSNI a la valeur true. Vous pouvez spécifier une valeur SNI pour qu’elle corresponde au nom commun du certificat sur le serveur principal. Par défaut, la passerelle d’application utilise l’en-tête d’hôte de la demande entrante en tant que SNI. |
Remarque
- Nous vous recommandons de conserver toutes les validations activées pour les environnements de production. La désactivation de certaines validations ou de toutes les validations est suggérée uniquement à des fins de test et de développement, par exemple lorsque des certificats auto-signés sont utilisés.
- Ces paramètres ne s’appliquent pas à la fonctionnalité de sonde de test lors de l’ajout d’une sonde de santé personnalisée. Par conséquent, vous pouvez constater des différences dans les résultats en les comparant à des sondes de santé périodiques.
- Actuellement, non pris en charge pour le proxy TLS.
- PowerShell et CLI seront bientôt pris en charge.
Délai d’expiration de la demande
Ce paramètre spécifie le nombre de secondes pendant lesquelles la passerelle applicative attend de recevoir une réponse du serveur back-end. La valeur par défaut est de 20 secondes. Toutefois, vous souhaiterez peut-être ajuster ce paramètre aux besoins de votre application. Les valeurs acceptables sont comprises entre 1 seconde et 86400 secondes (24 heures).
Remplacer le chemin back-end
Ce paramètre vous permet de configurer un chemin de transfert personnalisé facultatif à utiliser quand la demande est transférée au back-end. Toute partie du chemin entrant qui correspond au chemin personnalisé dans le champ Remplacer le chemin back-end est copiée dans le chemin transféré. Le tableau suivant montre comment agit cette fonctionnalité :
Quand le paramètre HTTP est attaché à une règle de routage des demandes de base :
Demande d’origine Remplacer le chemin back-end Demande transférée au back-end /domicile/ /override/ /override/home/ /home/secondhome/ /override/ /override/home/secondhome/ Quand le paramètre HTTP est attaché à une règle de routage des demandes basée sur un chemin :
Demande d’origine Règle de chemin Remplacer le chemin back-end Demande transférée au back-end /pathrule/accueil/ /pathrule* /override/ /override/home/ /pathrule/home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /domicile/ /pathrule* /override/ /override/home/ /home/secondhome/ /pathrule* /override/ /override/home/secondhome/ /pathrule/accueil/ /pathrule/home* /override/ /override/ /pathrule/home/secondhome/ /pathrule/home* /override/ /override/secondhome/ /règledechemin/ /règledechemin/ /override/ /override/
Utiliser une sonde personnalisée
Ce paramètre associe une sonde personnalisée à un paramètre HTTP. Vous pouvez associer une seule sonde personnalisée à un paramètre HTTP. Si vous n’associez pas explicitement une sonde personnalisée, la sonde par défaut est utilisée pour superviser l’intégrité du back-end. Nous vous recommandons de créer une sonde personnalisée pour mieux contrôler la supervision de l’intégrité de vos back-ends.
Remarque
La sonde personnalisée ne supervise pas l’intégrité du pool de back-ends, sauf si le paramètre HTTP correspondant est explicitement associé à un écouteur.
Configuration du nom d’hôte
Application Gateway permet à la connexion établie au back-end d’utiliser un nom d’hôte différent de celui utilisé par le client pour se connecter à Application Gateway. Bien que cette configuration puisse être utile dans certains cas, faites preuve de prudence en remplaçant le nom d’hôte de sorte qu’il soit différent entre la passerelle d’application et le client par rapport à la cible back-end.
Dans les environnements de production, il est recommandé d’utiliser le même nom d’hôte pour la connexion du client à la passerelle d’application et de la passerelle d’application à la cible du serveur principal. Cette pratique évite les problèmes potentiels liés aux URL absolues, aux URL de redirection et aux cookies liés à l’hôte.
Avant de configurer Application Gateway qui s’écarte de cela, passez en revue les implications de cette configuration, comme expliqué plus en détail dans Le Centre d’architecture : conservez le nom d’hôte HTTP d’origine entre un proxy inverse et son application web back-end.
Un paramètre HTTP influence l’en-tête HTTP Host dont se sert Application Gateway pour se connecter au back-end sur deux plans :
- « Choisir un nom d’hôte à partir d’une adresse back-end »
- « Remplacement du nom d’hôte »
Choisir un nom d’hôte à partir d’une adresse back-end
Cette fonctionnalité définit dynamiquement l’en-tête de l’hôte dans la requête sur le nom d’hôte du pool de back-ends. Elle utilise une adresse IP ou un nom de domaine complet.
Cette fonctionnalité s’avère utile quand le nom de domaine du back end est différent du nom DNS de la passerelle d’application et que le back-end s’appuie sur un en-tête d’hôte spécifique pour se résoudre en point de terminaison correct.
Exemple : des services multilocataires en tant que back-end. Un service d’application est un service multilocataire qui utilise un espace partagé avec une seule adresse IP. Ainsi, un service d’application est uniquement accessible par le biais des noms d’hôte configurés dans les paramètres du domaine personnalisé.
Par défaut, le nom de domaine personnalisé est example.azurewebsites.net. Pour accéder à votre service d’application via une passerelle applicative en utilisant un nom d’hôte qui n’est pas explicitement inscrit dans le service d’application ou le nom de domaine complet de la passerelle applicative, vous pouvez remplacer le nom d’hôte dans la demande d’origine par celui du service d’application. Pour cela, activez le paramètre Choisir un nom d’hôte à partir d’une adresse back-end.
Pour un domaine personnalisé dont le nom DNS personnalisé existant est mappé au service d’application, la configuration recommandée n’est pas pour activer le nom d’hôte choisi à partir de l’adresse principale.
Remarque
Ce paramètre n’est pas obligatoire pour App Service Environment, qui est un déploiement dédié.
Remplacement du nom d’hôte
Cette fonctionnalité remplace l’en-tête de l’hôte dans la demande entrante sur la passerelle d’application par le nom d’hôte que vous spécifiez.
Par exemple, si www.contoso.com elle est spécifiée dans le paramètre nom d’hôte , la requête d’origine *https://appgw.eastus.cloudapp.azure.com/path1 est remplacée par *https://www.contoso.com/path1 lorsque la requête est transférée au serveur principal.
Connexion back-end dédiée
Azure Application Gateway, par défaut, réutilise les connexions back-end inactives pour optimiser l’utilisation des ressources des connexions TCP pour application Gateway et le serveur principal. Pour prendre en charge les fonctions de sécurité dans les chemins de données client nécessitant des connexions principales uniques par client, Azure Application Gateway V2 fournit des connexions dédiées aux serveurs principaux.
Cette fonctionnalité établit un mappage direct et un-à-un entre les connexions frontend et back-end, ce qui garantit une connectivité persistante pour chaque client individuel.
Remarque
Pour activer l’authentification directe NTLM ou Kerberos, vérifiez que le paramètre de connexion principale dédiée est activé. Cette configuration gère un mappage un-à-un entre les connexions front-end et back-end, ce qui est essentiel pour préserver l’intégrité de session requise par ces protocoles d’authentification.
Important
La connexion principale dédiée entraîne une augmentation du nombre de connexions back-end et peut donc nécessiter davantage de ressources pour prendre en charge les connexions simultanées accrues sur Application Gateway et les serveurs principaux. Sur Application Gateway, vous devez envisager d’augmenter le nombre d’instances ou d’activer la mise à l’échelle automatique.
Lorsque le serveur principal est un serveur distant, les instances Application Gateway utilisent des ports SNAT pour chaque connexion. À mesure que chaque connexion cliente établit une connexion back-end dédiée, la consommation de port SNAT augmente de façon correspondante. Par conséquent, il est important de tenir compte de l’épuisement potentiel du port SNAT. Visitez les meilleures pratiques d’architecture pour obtenir des conseils.
La connexion back-end dédiée n’est pas prise en charge avec HTTP/2.