Entrée Internet : exposer votre application à Internet

Cet article vous aide à choisir le bon service Azure pour rendre votre application accessible à partir d’Internet. Il compare les adresses IP publiques, Azure Load Balancer, Application Gateway, Azure Front Door et Azure Traffic Manager. Choisissez l’option qui correspond au protocole, à la mise à l’échelle et aux exigences de sécurité de votre charge de travail.

Présentation de cet article

Chaque charge de travail Azure qui répond aux utilisateurs externes a besoin d’un chemin d’entrée : un moyen pour que le trafic Internet atteigne votre application de manière sécurisée et fiable. Le choix du mauvais service d’entrée entraîne un surprovisionnement, des lacunes de sécurité ou une complexité inutile. Cet article vous aide à évaluer sept services Azure qui acceptent des connexions entrantes à partir d’utilisateurs externes et routent ces connexions vers vos ressources back-end à l’intérieur d’un réseau virtuel. Vous pouvez sélectionner la combinaison qui correspond à votre protocole, mise à l’échelle, géographie et posture de sécurité.

Qui a besoin de cet article

Lisez cet article si une ou plusieurs de ces conditions s’appliquent :

• Votre application doit accepter les connexions entrantes à partir d’utilisateurs ou de systèmes sur Internet.
• Vous devez choisir parmi les adresses IP publiques, Load Balancer, Application Gateway, Front Door ou Traffic Manager en fonction du protocole et de l’étendue.
• Vous devez concevoir un point d’entrée public sécurisé pour les charges de travail web, API ou TCP/UDP.
• Vous devez combiner l’exposition à Internet avec waf, protection DDoS, arrêt TLS ou distribution régionale et mondiale du trafic.

Azure services et fonctionnalités

Azure fournit plusieurs services pour l’entrée Internet. Chaque service fonctionne sur une couche différente de la pile réseau et répond à un cas d’usage différent.

Fonctionnement de chaque service

Comprendre l’architecture interne de chaque service vous permet de prédire les performances, de résoudre les problèmes et de planifier le dimensionnement du sous-réseau.

Adresse IP publique

Une adresse IP publique de référence SKU standard est une ressource définie par logiciel qui mappe une adresse IPv4 routable ou IPv6 directement à une interface réseau, un front-end d’équilibreur de charge ou une passerelle. L’adresse est redondante interzone par défaut dans les régions prises en charge, ce qui signifie que la plateforme gère le basculement entre les zones de disponibilité sans aucune modification de votre part. Les adresses IP publiques n’ont aucun traitement du trafic. Les paquets circulent directement vers la ressource jointe sans vérification d’intégrité ni logique de distribution.

Azure Load Balancer (Standard, public)

Standard Load Balancer utilise un algorithme de distribution basé sur un hachage sur 5 tuples (adresse IP source, port source, adresse IP de destination, port de destination, protocole). Il fonctionne entièrement dans le chemin des données au niveau de la couche 4, de sorte qu’il n’arrête jamais les connexions ou inspecte les charges utiles. Les sondes d’intégrité (TCP, HTTP ou HTTPS) interrogent en permanence les instances back-end et suppriment les instances non saines de la rotation en quelques secondes. Load Balancer s’adapte automatiquement. Il n’y a pas de planification de capacité ou de dimensionnement d’instance.

Azure Load Balancer (Standard, interne)

Les Load Balancer internes fonctionnent de la même façon que son équivalent public, mais utilisent une adresse IP frontale privée à partir du sous-réseau de réseau virtuel. Il distribue le trafic entre les niveaux internes, tels qu’un niveau web envoyant du trafic à un cluster d’API de niveau intermédiaire. Comme il n’a pas d’adresse IP publique, il est invisible à Internet. Associez-le à un service d’entrée public, tel que Front Door, Application Gateway ou un Load Balancer public, qui gère la limite externe.

Azure Application Gateway

Application Gateway est une appliance virtuelle dédiée déployée dans votre sous-réseau de réseau virtuel. Il met fin aux connexions TLS au niveau de la passerelle, inspecte les en-têtes et URL HTTP, et route les requêtes vers les pools principaux en fonction des règles de chemin d’accès, des en-têtes d’hôte ou des sondes d’intégrité personnalisées. La référence SKU v2 prend en charge la mise à l’échelle automatique (0 à 125 instances) et la redondance de zone. Étant donné qu’il est résident de réseau virtuel, il peut atteindre des back-ends privés sans nécessiter d’adresses IP publiques sur ces back-ends.

Application Gateway avec WAF

Lorsque vous ajoutez la couche WAF, vous activez le jeu de règles de base OWASP et les règles Microsoft Threat Intelligence directement dans le pipeline de traitement de l’Application Gateway. Chaque requête HTTP passe par le moteur WAF avant d’atteindre les règles de routage. Le WAF prend en charge les stratégies par site, ce qui vous permet d'avoir différentes configurations de règles pour différentes combinaisons d'écouteurs ou d'hôtes sur la même passerelle. Le WAF fonctionne en mode Détection (journalisation uniquement) ou Prévention (blocage et journalisation).

Azure Front Door - Service de passerelle réseau de Microsoft

Front Door fonctionne à partir du réseau de périphérie global Microsoft (190 points de présence). Lorsqu’un utilisateur se connecte, l’établissement de la connexion TCP et la négociation TLS s’effectuent au point de présence le plus proche grâce à Split TCP. Le point de présence maintient une connexion persistante préchauffée à votre origine, ce qui élimine la latence de démarrage à froid que les utilisateurs rencontreraient en se connectant directement. Front Door effectue le routage de couche 7, l’inspection waf, la mise en cache et la compression à la périphérie avant de transférer la requête vers l’origine saine la plus proche sur le réseau principal Microsoft.

Azure Traffic Manager

Traffic Manager est un service DNS sans intervention de chemin d’accès aux données. Lorsqu’un client résout votre nom d’hôte Traffic Manager, il retourne un CNAME qui pointe vers le point de terminaison le plus sain ou le plus proche en fonction de votre méthode de routage (priorité, pondération, performances, géographique, multivalue ou sous-réseau). Traffic Manager sonde en permanence l’intégrité du point de terminaison et met à jour les réponses DNS en conséquence. Étant donné qu’il ne voit jamais le trafic d’application, il fonctionne avec n’importe quel protocole : HTTP, TCP, UDP ou protocoles propriétaires.

Comparaison des modèles de coût

Chaque service d’entrée suit un modèle de facturation différent. Utilisez ce tableau pour estimer les coûts au volume de trafic attendu.

Comment choisir

Utilisez les tableaux de décision suivants pour sélectionner le service d’entrée approprié pour votre charge de travail. Commencez par la table de décision générale, puis utilisez la comparaison détaillée pour confirmer votre choix.

Application Gateway et Front Door et Traffic Manager

Ce tableau vous aide à choisir entre les trois services d’entrée HTTP et HTTPS les plus courants.

Comparaison des services d’entrée

Utilisez cette comparaison détaillée lorsque vous devez comprendre les fonctionnalités de chaque service.

Architecture d’entrée Internet

Le schéma suivant illustre des modèles courants de chaînage de services pour le trafic entrant à destination des charges de travail Azure. Chaque modèle combine les services de couche 7 et de couche 4 pour correspondre à un protocole, une étendue régionale et une posture de sécurité spécifiques.

Modèles d’entrée courants

Les modèles suivants combinent plusieurs services pour une architecture d’entrée complète. Choisissez le modèle qui correspond aux exigences de votre protocole, à l’étendue régionale et à la posture de sécurité.

Modèle 1 : Application web globale avec sécurité de périphérie

Services: Front Door → Application Gateway (avec WAF) → machines virtuelles/conteneurs

Scénario : Une application SaaS qui sert des clients en Amérique du Nord, en Europe et en Asie a besoin d’accélération mondiale, de protection DDoS à la périphérie et d’un routage basé sur des chemins régionaux vers différents microservices.

Front Door met fin aux connexions utilisateur au point de présence (PoP) le plus proche, applique des règles WAF globales et met en cache le contenu statique. Le trafic est acheminé via le backbone de Microsoft jusqu’à la passerelle d’application régionale, qui effectue un routage basé sur les URL (par exemple, /api/* vers le pool d’API, /static/* vers un backend de stockage). Ce modèle fournit deux couches d’inspection WAF : une en périphérie et une au niveau régional.

Modèle 2 : non-HTTP multirégion avec basculement DNS

Services: Traffic Manager → Standard Load Balancer (par région) → machines virtuelles

Scénario: Une société de jeux exécute des serveurs de jeux dédiés sur le port UDP 7777 dans trois régions. Les joueurs se connectent automatiquement à la région saine la plus proche.

Traffic Manager utilise la méthode de routage des performances pour retourner l’enregistrement DNS pour la région à latence la plus faible. Chaque région dispose d'un Standard Load Balancer qui répartit le trafic UDP entre les instances d'un Virtual Machine Scale Set. Si des sondes d’intégrité détectent une défaillance régionale, Traffic Manager met à jour le DNS pour acheminer les joueurs vers la région disponible la plus proche.

Modèle 3 : Application web régionale simple avec WAF

Services: Application Gateway (avec WAF) → machines virtuelles

Scénario: Application métier interne exposée à des partenaires externes. Une seule région, un trafic modéré, a besoin de la protection OWASP et de l’arrêt TLS.

Application Gateway fournit un routage basé sur le chemin, l’affinité de cookie pour la gestion de session et la protection WAF, tous à partir d’une seule ressource régionale au sein du réseau virtuel. Ce modèle évite la complexité et le coût d’un service global lorsque le trafic est concentré géographiquement.

Modèle 4 : Front Door avec origines privées verrouillées

Services: Front Door Premium → Private Link → équilibreur de charge interne → machines virtuelles

Scénario: Une application de services financiers avec des exigences strictes que l’origine ne doit pas avoir d’exposition à l’adresse IP publique. Tout le trafic doit traverser le réseau principal Microsoft sans tronçons Internet publics.

Front Door Premium se connecte à l’origine via un point de terminaison Private Link. Le back-end d’origine n’a aucune adresse IP publique et aucune exposition à Internet. Ce modèle offre la sécurité d’une origine entièrement privée combinée aux avantages de performances du réseau de périphérie global de Front Door.

Trafic d'entrée multirégion avec Front Door

Le schéma suivant montre Azure Front Door comme point d'entrée global, acheminant les utilisateurs vers l'origine régionale saine la plus proche avec basculement automatique.

Prerequisites

Avant d’exposer votre application à Internet, vérifiez que vous disposez des composants suivants :

• Réseau virtuel déployé : Vos ressources principales doivent s’exécuter à l’intérieur d’un réseau virtuel Azure avec des sous-réseaux correctement dimensionnés. Consultez Concevoir votre réseau virtuel et vos sous-réseaux pour obtenir des conseils de planification de sous-réseau.
• Charge de travail en cours d’exécution : Vous avez besoin d’au moins une ressource principale (machine virtuelle, conteneur ou service de plateforme) prête à servir le trafic.
• Nom DNS : Nom DNS public utilisé par les utilisateurs externes pour atteindre votre application. Vous pouvez utiliser Azure DNS ou un fournisseur DNS tiers.
• Planification du sous-réseau pour les services d’entrée : Application Gateway nécessite un sous-réseau dédié (minimum /24 recommandé pour la production). Les instances de back-end du Standard Load Balancer peuvent partager un sous-réseau avec d’autres ressources.

Considérations relatives à la conception

Considérations relatives à la sécurité

L’entrée Internet est la porte d’entrée de votre application. Il s'agit de la limite où le trafic Internet non approuvé entre dans votre environnement de Azure. Suivez ces pratiques pour sécuriser votre chemin d’entrée.

N’exposez jamais de machines virtuelles directement avec des adresses IP publiques

N’attribuez pas d’adresse IP publique directement à l’interface réseau d’une machine virtuelle pour traiter le trafic d’application sur les ports 80 ou 443. Au lieu de cela, placez un équilibreur de charge ou Application Gateway entre Internet et vos machines virtuelles. Cette approche vous offre les points suivants :

• Sondes d'intégrité pour retirer les instances défaillantes de la rotation
• Point unique pour l’arrêt SSL ou TLS
• Un endroit où appliquer des règles WAF et une limitation de débit
• Journalisation centralisée de tout le trafic entrant

Activer le WAF en mode de prévention

Si vous déployez Application Gateway avec WAF ou Azure Front Door avec WAF, réglez le WAF en mode Prevention pour les charges de travail de production. Le mode de prévention bloque les demandes malveillantes avant d’atteindre votre application. Le mode de détection journalise uniquement les menaces sans les bloquer. Utilisez le mode détection uniquement pendant les tests initiaux pour régler les règles et identifier les faux positifs.

L’ensemble de règles par défaut WAF protège contre les 10 principales attaques OWASP, notamment l’injection SQL, les scripts intersites et l’exécution de code à distance. DRS inclut également des règles Microsoft Threat Intelligence qui détectent des adresses IP et des charges actives malveillantes connues.

Activer la protection DDos

Tous les réseaux virtuels dotés de ressources publiques doivent avoir la protection DDoS activée. Azure protection réseau DDoS fournit un réglage adaptatif, une télémétrie d’attaque et une protection des coûts pour vos adresses IP publiques. Sans protection DDoS, une attaque volumétrique peut saturer votre bande passante d’entrée et rendre votre application inaccessible.

Pour plus d’informations, consultez protection DDoS pour votre réseau.

Utiliser les NSG pour une défense en profondeur

Même lorsque vous utilisez un équilibreur de charge ou Application Gateway, configurez des règles de groupe de sécurité réseau sur vos sous-réseaux principaux pour limiter les sources de trafic pouvant atteindre vos machines virtuelles. Un groupe de sécurité réseau correctement configuré :

• Autorise le trafic uniquement à partir du sous-réseau ou de l’étiquette de service de l’équilibreur de charge
• Refuse le trafic entrant direct d’Internet vers les machines virtuelles principales
• Journalise le trafic refusé à des fins de supervision de la sécurité

Pour la planification du groupe de sécurité réseau, consultez groupes de sécurité réseau et groupes de sécurité d’application.

Appliquer TLS 1.2 ou version ultérieure

Configurez tous les services d’entrée pour accepter uniquement TLS 1.2 ou TLS 1.3. Désactivez TLS 1.0 et 1.1, qui présentent des vulnérabilités connues. Application Gateway et Front Door prennent en charge la configuration minimale de la version TLS par le biais de leurs paramètres de stratégie TLS. Utilisez des stratégies prédéfinies, telles que AppGwSslPolicy20220101 pour Application Gateway, plutôt que des configurations de chiffrement personnalisées, sauf si vous avez des exigences de conformité spécifiques.

Verrouiller les origines pour Front Door

Lorsque vous utilisez Azure Front Door, limitez vos serveurs d’origine à accepter le trafic uniquement à partir de Front Door. Si votre origine accepte le trafic provenant de n’importe quelle source, les acteurs malveillants peuvent contourner le WAF de Front Door en se connectant directement à l’adresse IP d’origine, ce qui rend votre investissement WAF complet inefficace.

Le verrouillage d’origine utilise deux mécanismes de vérification indépendants. Appliquez les deux pour la défense en profondeur :

Restriction des étiquettes de service (couche réseau)

Configurez le groupe de sécurité réseau de votre origine ou Pare-feu Azure pour autoriser le trafic HTTP/HTTPS entrant uniquement à partir de l'étiquette de AzureFrontDoor.Backend service. Cette balise de service contient toutes les plages d’adresses IP utilisées par Front Door pour se connecter aux origines. Appliquez cette règle au niveau du sous-réseau ou de l’interface réseau où se trouve votre origine :

• Règle de groupe de sécurité réseau : Priorité 100, Source = Balise AzureFrontDoor.Backendde service, Destination = votre sous-réseau principal, Ports = 80, 443, Action = Autoriser.
• Refus par défaut : Vérifiez qu’aucune autre règle n’autorise le trafic entrant sur les ports 80/443 à partir d’Internet. La règle DenyAllInbound par défaut du groupe de sécurité réseau gère cela, sauf si vous ajoutez une règle d’autorisation plus large.

L’étiquette de service seule est insuffisante, car toutes les instances Front Door de toutes les Azure clients partagent les mêmes plages d’adresses IP d’étiquette de service. Un acteur malveillant pourrait créer son propre profil Front Door et le faire pointer vers votre adresse IP d’origine, contournant ainsi vos règles WAF.

Validation de l’en-tête X-Azure-FDID (couche Application)

Chaque requête de Front Door inclut un X-Azure-FDID en-tête contenant l’identificateur unique (GUID) de l’instance Front Door qui a envoyé la requête. Validez cet en-tête dans votre application ou votre proxy inverse pour confirmer que la demande provient de votre profil Front Door, et non d'un acteur malveillant :

1. Recherchez votre ID Front Door dans le portail Azure sous la page Vue d'ensemble de votre profil Front Door (champ « ID Front Door »).
2. Dans le code de votre application ou dans la configuration de votre serveur web, refusez toute requête pour laquelle X-Azure-FDID ne correspond pas au GUID attendu.
3. Retournez HTTP 403 pour les requêtes avec une valeur d’en-tête manquante ou incorrecte.

La combinaison de la balise de service (bloque le trafic non Front Door au niveau du réseau) avec la validation d’en-tête (bloque le trafic Front Door des autres clients au niveau de l’application) garantit que seule votre instance Front Door peut atteindre votre origine.

Origines Private Link (verrouillage le plus strict)

Pour les charges de travail nécessitant le plus haut niveau d'isolation de l'origine, Front Door Premium prend en charge les origines Private Link. Votre origine n’a pas besoin d’adresse IP publique. Front Door se connecte via un point de terminaison privé sur le réseau principal de Microsoft. Cette approche élimine la nécessité de règles d’étiquette de service ou de validation d’en-tête, car l’origine n’est pas accessible entièrement à partir de l’Internet public.

Articles connexes

• Concevoir votre réseau virtuel et vos sous-réseaux : dimensionnement de sous-réseau pour Application Gateway et Load Balancer back-ends
• Groupes de sécurité réseau et groupes de sécurité d’application : règles de groupe de sécurité réseau pour restreindre l’accès back-end après l’entrée
• Remise et performances des applications : réglage des performances après l’établissement de votre chemin d’entrée
• Accès internet sortant : contrôlez le trafic sortant, le pendant du trafic entrant
• Accès administratif sécurisé : modèles d’accès administrateur, distincts de l’entrée Internet pour les utilisateurs d’application
• Pare-feu d’applications web : configuration et réglage des règles waf détaillés
• Protection DDoS pour votre réseau : planification de la protection DDoS pour toutes les ressources publiques

Learn more

• Qu’est-ce qu’Azure Load Balancer ?
• Qu’est-ce que Azure Application Gateway ?
• Qu’est-ce qu’Azure Front Door ?
• Qu’est-ce que Azure Traffic Manager ?
• Les adresses IP publiques dans Azure
• Azure Web Application Firewall sur Application Gateway
• Vue d'ensemble de la protection réseau DDoS d'Azure

Étapes suivantes