Meilleures pratiques pour Front Door
Cet article résume les meilleures pratiques d’utilisation d’Azure Front Door.
Bonnes pratiques générales
Comprendre quand combiner Traffic Manager et Front Door
Pour la plupart des solutions, nous vous recommandons d’utiliser soit Front Door soit Azure Traffic Manager, mais pas les deux. Azure Traffic Manager est un équilibreur de charge basé sur DNS. Il envoie le trafic directement aux points de terminaison de votre origine. En revanche, Azure Front Door termine les connexions aux points de présence (PoP) proches du client et établit des connexions de longue durée distinctes aux origines. Les produits fonctionnent différemment et sont destinés à différents cas d’usage.
Si vous avez besoin d’une mise en cache et d’une distribution de contenu (CDN), d’une terminaison TLS, de fonctionnalités de routage avancées ou d’un pare-feu d’applications web (WAF), envisagez d’utiliser Front Door. Pour un équilibrage de charge global simple avec des connexions directes de votre client à vos points de terminaison, envisagez d’utiliser Traffic Manager. Pour plus d’informations sur la sélection d’une option d’équilibrage de charge, consultez Options d’équilibrage de charge.
Toutefois, dans le cadre d’une architecture complexe nécessitant une haute disponibilité, vous pouvez placer Azure Traffic Manager devant Azure Front Door. Dans le cas peu probable où Azure Front Door n’est pas disponible, Azure Traffic Manager peut alors acheminer le trafic vers une autre destination, comme Azure Application Gateway ou un réseau de distribution de contenu (CDN) partenaire.
Important
Ne placez pas Azure Traffic Manager derrière Azure Front Door. Azure Traffic Manager doit toujours être devant Azure Front Door.
Limiter le trafic vers vos origines
Les fonctionnalités de Front Door sont optimales lorsque le trafic transite uniquement par Front Door. Vous devez configurer votre origine pour bloquer le trafic qui n’a pas été envoyé via Front Door. Pour plus d’informations, consultez Sécuriser le trafic vers les origines Azure Front Door.
Utiliser les dernières versions de l’API et du Kit de développement logiciel (SDK)
Lorsque vous utilisez Front Door à l’aide d’API, de modèles ARM, de Bicep ou de kits de développement logiciel (SDK) Azure, il est important d’utiliser les dernières versions disponibles des API ou des kits de développement logiciel (SDK). Les mises à jour des API et des kits de développement logiciel (SDK) se produisent lorsque de nouvelles fonctionnalités sont disponibles, et contiennent également des correctifs importants de sécurité et de bogues.
Configurer les journaux
Front Door suit les données de télémétrie étendues sur chaque requête. Lorsque vous activez la mise en cache, vos serveurs d’origine peuvent ne pas recevoir toutes les demandes. Il est donc important que vous utilisiez les journaux Front Door pour comprendre comment votre solution s’exécute et répond à vos clients. Pour plus d’informations sur les métriques et journaux enregistrés par Azure Front Door, consultez Surveiller les métriques et journaux dans Azure Front Door et Journaux du pare-feu d'applications web (WAF).
Pour configurer la journalisation pour votre propre application, consultez Configurer les journaux Azure Front Door
Meilleures pratiques TLS
Utiliser TLS de bout en bout
Front Door termine les connexions TCP et TLS des clients. Il établit ensuite de nouvelles connexions de chaque point de présence (PoP) à l’origine. Il est recommandé de sécuriser chacune de ces connexions avec TLS, même pour des origines hébergées dans Azure. Cette approche garantit que vos données sont toujours chiffrées pendant le transit.
Pour plus d’informations, consultez TLS de bout en bout avec Azure Front Door.
Utiliser une redirection de HTTP vers HTTPS
Il est recommandé aux clients d’utiliser HTTPS pour se connecter à votre service. Toutefois, vous devez parfois accepter des requêtes HTTP pour autoriser des clients plus anciens ou des clients qui comprendraient pas la meilleure pratique.
Vous pouvez configurer Front Door pour rediriger automatiquement les requêtes HTTP afin d’utiliser le protocole HTTPS. Vous devriez activer le paramètre Rediriger tout le trafic pour utiliser HTTPS sur votre itinéraire.
Utiliser des certificats TLS managés
Lorsque Front Door gère vos certificats TLS, il réduit vos coûts opérationnels et vous aide à éviter des pannes coûteuses résultant d’un oubli de renouvellement de certificat. Front Door émet automatiquement des certificats TLS managés et assure leur rotation.
Pour plus d’informations, consultez Configurer HTTPS sur un domaine personnalisé Azure Front Door à l’aide du portail Azure.
Utiliser la dernière version pour les certificats gérés par le client
Si vous décidez d’utiliser vos propres certificats TLS, envisagez de définir la version du certificat du Key Vault sur « Dernière ». Vous évitez ainsi d’avoir à reconfigurer Front Door pour utiliser de nouvelles versions de votre certificat, et à attendre que le certificat soit déployé dans les environnements de Front Door.
Pour plus d’informations, consultez Sélectionner le certificat à déployer pour Azure Front Door.
Meilleures pratiques relatives aux noms de domaine
Utiliser le même nom de domaine sur Front Door et votre origine
Front Door peut réécrire l’en-tête Host des demandes entrantes. Cette fonctionnalité peut être utile lorsque vous gérez un ensemble de noms de domaine personnalisés visibles par les clients, qui routent vers une seule origine. Cette fonctionnalité peut également être utile quand vous souhaitez éviter de configurer des noms de domaine personnalisés dans Front Door et à votre origine. Toutefois, lorsque vous réécrivez l’en-tête Host, les cookies de requête et les redirections d’URL pourraient être perturbés. En particulier, lorsque vous utilisez des plateformes comme Azure App Service, des fonctionnalités telles que l’affinité de session et l’authentification et l’autorisation pourraient ne pas fonctionner correctement.
Avant de réécrire l’en-tête Host de vos demandes, examinez attentivement si votre application va fonctionner correctement.
Pour plus d’informations, consultez Conserver le nom d’hôte HTTP d’origine entre un proxy inverse et son application web de back-end.
Pare-feu d’applications web (WAF)
Activer le pare-feu d’applications web (WAF)
Pour les applications accessibles sur Internet, nous vous recommandons d’activer le pare-feu d’applications web (WAF) pour Front Door et de le configurer pour utiliser des règles gérées. Lorsque vous utilisez un pare-feu d’applications web et des règles gérées par Microsoft, votre application est protégée contre toute une série d’attaques.
Pour plus d’informations, consultez Pare-feu d’applications web (WAF) sur Azure Front Door.
Suivre les meilleures pratiques de WAF
Le WAF pour Front Door a son propre ensemble de meilleures pratiques en lien avec sa configuration et son utilisation. Pour plus d’informations, consultez Meilleures pratiques pour le pare-feu d’applications web sur Azure Front Door.
Meilleures pratiques relatives aux sondes d’intégrité
Désactiver les sondes d’intégrité quand ’il n’existe qu’une seule origine dans un groupe d’origines
Les sondes d’intégrité de Front Door sont conçues pour détecter les situations où une origine est indisponible ou non saine. Quand une sonde d’intégrité détecte un problème lié à une origine, Front Door peut être configuré pour envoyer le trafic à une autre origine dans le groupe d’origines.
Si vous n’avez qu’une seule origine, Front Door route toujours le trafic vers celle-ci, même si sa sonde d’intégrité signale un état non sain. L’état de la sonde d’intégrité ne change en rien le comportement de Front Door. Dans ce scénario, les sondes d’intégrité n’apportent pas d’avantage et vous devez les désactiver pour réduire le trafic sur votre origine.
Pour plus d’informations, veuillez consulter la section Sondes d’intégrité.
Sélectionner de bons points de terminaison de sonde d’intégrité
Réfléchissez à l’endroit que la sonde d’intégrité de Front Door doit surveiller. Il est généralement judicieux de surveiller une page web ou un emplacement spécialement conçu pour le monitoring de l’intégrité. Votre logique d’application peut prendre en compte l’état de tous les composants critiques nécessaires pour servir le trafic de production, notamment les serveurs d’applications, les bases de données et les caches. De cette façon, en cas de défaillance d’un composant, Front Door peut acheminer votre trafic vers une autre instance de votre service.
Pour plus d’informations, consultez Modèle de surveillance des points de terminaison d’intégrité.
Utiliser des sondes d’intégrité HEAD
Les sondes d’intégrité peuvent utiliser la méthode HTTP GET ou HEAD. Il est recommandé d’utiliser la méthode HEAD pour les sondes d’intégrité, car elle réduit la charge de trafic sur vos origines.
Pour plus d’informations, consultez Méthodes HTTP prises en charge pour les sondes d’intégrité.
Étapes suivantes
Découvrez comment créer un profil Front Door.