Utiliser une configuration DNS split-brain pour héberger une application Web dans Azure

Les équipes qui gèrent les charges de travail s’appuient souvent sur des noms de domaine complets (FQDN) pour l’accès client. Les noms de domaine complets sont généralement combinés avec l’indication du nom de serveur (SNI) du protocole TLS (Transport Layer Security). Grâce à cette approche, lorsque des clients publics accèdent à une charge de travail à partir de l’internet public ou que des clients d’entreprise accèdent à une charge de travail en interne, l’acheminement vers l’application peut suivre des chemins fixes et présenter différents niveaux de sécurité ou de qualité de service (QoS).

L’architecture suivante illustre une approche permettant de différencier la façon dont le trafic est traité en fonction du système de noms de domaine (DNS) et indique si le client provient d’Internet ou d’un réseau d’entreprise.

Architecture

Téléchargez un fichier Visio de cette architecture.

Les sections de workflow suivantes décrivent deux configurations : un workflow Internet public et un workflow privé. Combinez les deux workflow pour implémenter une architecture d’hébergement split-brain.

Workflow Internet public

Téléchargez un fichier Visio de cette architecture.

1. Les clients envoient une demande pour l’application app.contoso.com via l’Internet public.

2. Une zone Azure DNS est configurée pour le domaine contoso.com. Les entrées de nom canonique (CNAME) appropriées sont configurées pour les points de terminaison Azure Front Door.

3. Les clients externes accèdent à l’application web via Azure Front Door, qui fonctionne comme un équilibreur de charge global et un pare-feu d’applications web (WAF).

   • Dans Azure Front Door, app.contoso.com est attribué en tant que nom de domaine complet via des itinéraires sur un point de terminaison configuré. Azure Front Door héberge également les certificats SNI TLS pour les applications.

     Remarque

     Azure Front Door ne prend pas en charge les certificats auto-signés.

   • Azure Front Door route les requêtes vers le groupe d’origine configuré en fonction de l’en-tête HTTP du client Host.

   • Le groupe d’origine est configuré pour pointer vers l’instance Azure Application Gateway via l’adresse IP publique d’Application Gateway.

4. Un groupe de sécurité réseau (NSG) est configuré sur le sous-réseau AppGW pour autoriser l’accès entrant sur le port 80 et le port 443 à partir de l’étiquette de service AzureFrontDoor.Backend. Le groupe de sécurité réseau n’autorise pas le trafic entrant sur le port 80 et le port 443 à partir de l’étiquette de service Internet.

   Remarque

   L’étiquette de service AzureFrontDoor.Backend ne limite pas le trafic uniquement à votre instance Azure Front Door. La validation se produit à l’étape suivante.

5. L’instance Application Gateway a un écouteur sur le port 443. Le trafic est acheminé vers le serveur principal en fonction du nom d’hôte spécifié dans l’écouteur.

   • Pour vous assurer que le trafic provient de votre profil Azure Front Door, configurez une règle WAF personnalisée pour vérifier la valeur d’en-tête X-Azure-FDID.

   • Azure génère un identificateur unique pour chaque profil Azure Front Door. L’identificateur unique est la valeur valeur ID Front Door située sur la page Vue d’ensemble du portail Azure.

6. Le trafic atteint la ressource de calcul configurée en tant que pool principal dans Application Gateway.

Workflow d’entreprise privé

Téléchargez un fichier Visio de cette architecture.

1. Les clients lancent une demande pour l’application app.contoso.com à partir d’un environnement local.

2. Les noms de domaine complets d’application sont configurés sur le fournisseur DNS local. Ce fournisseur DNS peut être un serveur DNS Windows Server Active Directory local ou d’autres solutions partenaires. Les entrées DNS pour chacun des noms de domaine complets d’application sont configurées pour pointer vers l’adresse IP privée de l’instance Application Gateway.

3. Un circuit Azure ExpressRoute ou un VPN de site à site facilite l’accès à Application Gateway.

4. Un groupe de sécurité réseau est configuré sur le sous-réseau AppGW pour autoriser les requêtes privées entrantes à partir de réseaux clients locaux d’où provient le trafic.. Cette configuration garantit que d’autres sources de trafic privé ne peuvent pas atteindre directement l’adresse IP privée d’Application Gateway.

5. Application Gateway dispose d’un écouteur configuré sur le port 80 et le port 443. Le trafic est acheminé vers le serveur principal en fonction du nom d’hôte spécifié dans l’écouteur.

6. Seul le trafic réseau privé atteint le calcul configuré en tant que pool principal dans Application Gateway.

Composants

• DNS : pour un workflow Internet public, il faut configurer une zone Azure DNS publique avec le CNAME approprié du nom de domaine complet du point de terminaison Azure Front Door. Côté privé (entreprise), il faut configurer le fournisseur DNS local (DNS Windows Server Active Directory ou une solution partenaire) pour pointer chaque nom de domaine complet d’application vers l’adresse IP privée d’Application Gateway.

• Azure DNS Private Resolver : vous pouvez utiliser DNS Private Resolver pour la résolution des clients locaux. Les clients d’entreprise peuvent utiliser cette solution DNS split-brain pour accéder aux applications sans passer par l’Internet public.

• Azure Front Door : Azure Front Door est un équilibreur de charge global et un WAF qui fournit des applications web rapides et sécurisées à des clients du monde entier. Dans cette architecture, Azure Front Door achemine les clients externes vers l’instance Application Gateway et fournit des options de mise en cache et d’optimisation pour améliorer l’expérience client.

• Application Gateway : Application Gateway est un équilibreur de charge régional et un WAF qui offre une disponibilité, une scalabilité et une sécurité élevées pour les applications web. Dans cette architecture, l’Application Gateway achemine les demandes des clients externes et internes vers le calculateur principal et protège l’application web contre les attaques communes sur le web.

  Azure Front Door et Application Gateway offrent des fonctionnalités WAF, mais le workflow privé de cette solution n’utilise pas Azure Front Door. Ainsi, les deux architectures utilisent les fonctionnalités WAF d’Application Gateway.

• ExpressRoute : vous pouvez utiliser ExpressRoute pour étendre vos réseaux locaux vers le cloud Microsoft via une connexion privée avec l’aide d’un fournisseur de connectivité. Dans cette architecture, vous pouvez utiliser ExpressRoute pour faciliter la connectivité privée à Application Gateway pour les clients locaux.

Autres solutions

Une autre solution consiste à supprimer Azure Front Door et à faire pointer l’enregistrement public Azure DNS vers l’adresse IP publique d’Application Gateway. Compte tenu des exigences de cette architecture, vous devez procéder à la mise en cache et à l’optimisation au niveau du point d’entrée dans Azure. Par conséquent, la solution de rechange n’est pas une option pour ce scénario. Pour plus d’informations, consultez Optimisation du coût.

Téléchargez un fichier Visio de cette architecture.

D’autres solutions sont envisageables pour le trafic d’entrée du public dans cette architecture :

• Azure Traffic Manager : Traffic Manager est un service de routage du trafic basé sur DNS qui distribue le trafic entre différentes régions et points de terminaison. Vous pouvez utiliser Traffic Manager au lieu d’Azure Front Door pour acheminer les clients externes vers l’instance Application Gateway la plus proche. Toutefois, Azure Front Door fournit des fonctionnalités, notamment le WAF, la mise en cache et l’affinité de session, que Traffic Manager ne fournit pas.

• Azure Load Balancer : Azure Load Balancer est un équilibreur de charge réseau qui fournit une disponibilité et une scalabilité élevées pour le trafic TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). Vous pouvez utiliser Load Balancer au lieu d’Application Gateway pour acheminer les demandes de client externes et internes vers des serveurs web principaux. Toutefois, Application Gateway fournit des fonctionnalités, notamment le WAF, la terminaison SSL (Secure Sockets Layer) et l’affinité de session basée sur les cookies, que Load Balancer ne fournit pas.

Détails du scénario

Ce scénario résout le problème d’hébergement d’une application web qui dessert à la fois des clients externes et internes. Une telle architecture offre la garantie que le trafic suit un chemin approprié en fonction de l’origine d’un client. Cette architecture présente plusieurs avantages :

• Elle fournit un accès rapide et fiable à une application web via Internet à des clients non professionnels dans le monde entier.

• Elle permet aux clients professionnels d'accéder à une application sans passer par l'internet public.

• Elle protège une application web contre les attaques web communes et le trafic malveillant.

Cas d’usage potentiels

Utilisez cette architecture pour les scénarios qui requièrent :

• Un DNS split-brain : cette solution utilise Azure Front Door pour les clients externes et Application Gateway pour les clients internes, avec différents enregistrements DNS pour chaque service. Une telle approche permet d’optimiser les performances, la sécurité et la disponibilité du réseau pour différents clients.

• Une scalabilité de l’application : cette solution utilise Application Gateway, qui peut distribuer le trafic entre les ressources de calcul du serveur principal configurées. Une telle approche permet d’améliorer les performances et la disponibilité des applications, prend en charge la mise à l’échelle horizontale.

Considérations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework qui est un ensemble de principes directeurs qui permettent d’améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Microsoft Azure Well-Architected Framework.

Fiabilité

La fiabilité permet de s’assurer que votre application tient vos engagements auprès de vos clients. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la fiabilité.

• Identifiez les points de défaillance : dans cette architecture DNS split-brain, la fiabilité dépend du fonctionnement adéquat des composants clés, notamment Azure Front Door, Application Gateway et les configurations DNS. Vous devez identifier les points de défaillance potentiels comme les erreurs de configuration, les problèmes liés aux certificats SSL ou les surcharges de capacité.

• Évaluez l’impact : vous devez évaluer l’impact des défaillances. Pour les clients externes, toute perturbation d’Azure Front Door, qui sert de passerelle, peut affecter l’accès global. Pour les clients internes, toute perturbation d’Application Gateway peut entraver les opérations de l'entreprise.

• Implémentez des stratégies d’atténuation : pour atténuer les risques, implémenter la redondance entre plusieurs zones de disponibilité, utiliser des sondes d’intégrité pour la surveillance en temps réel et garantir la configuration correcte du routage DNS pour le trafic externe et interne. Veillez à mettre régulièrement à jour les enregistrements DNS et à disposer d’un plan de reprise d’activité après sinistre.

• Surveillez de façon continue : pour surveiller de façon continue l’intégrité de votre système, utilisez des fonctionnalités d'Azure Monitor. Mettez en place des alertes en cas d'anomalies et préparez un plan d'intervention en cas d'incident afin de résoudre rapidement les problèmes potentiels.

Le respect de ces principes est la garantie d'un système robuste et fiable, capable de relever les défis et de maintenir la continuité des services.

Sécurité

La sécurité fournit des garanties contre les attaques délibérées, et contre l’utilisation abusive de vos données et systèmes importants. Pour en savoir plus, consultez Liste de contrôle de l'examen de la conception pour la sécurité.

• Utilisez l’approche Confiance Zéro : dans la configuration DNS split-brain, appliquez l’approche Confiance Zéro. Vérifiez explicitement l’identité d’un client, qu’il provienne d’Internet ou d’un réseau d’entreprise. Une telle approche permet de s'assurer que seules des entités de confiance effectuent des actions autorisées.

• Implémentation : implémentez Microsoft Entra ID pour une gestion robuste des identités. Utilisez les politiques d’accès conditionnel Microsoft Entra pour appliquer des contrôles d’accès stricts en fonction du contexte client, de l’intégrité de l’appareil et de l’emplacement.

• Évaluez l’efficacité de la sécurité : Évaluez l'efficacité des mesures de sécurité pour votre charge de travail à accès double en mettant en œuvre :

  • Des investissements défensifs : évaluez régulièrement l’efficacité d’Azure Front Door et d’Application Gateway. Assurez-vous qu’ils fournissent une protection significative contre les menaces.

  • Des restrictions de rayon d’impact : veillez à limiter la portée des failles de sécurité. Par exemple, isolez efficacement les flux de trafic externe et interne.

• Supposez une infraction : reconnaissez que les attaquants peuvent déjouer les contrôles de sécurité. Préparez-vous à de tels scénarios.

• Implémentez des mesures de sécurité : implémentez la segmentation du réseau, la micro-segmentation et les groupes de sécurité réseau. Supposez qu'un pirate peut obtenir un accès et concevez des contrôles compensatoires en conséquence.

Intégrez ces principes de sécurité à votre architecture DNS split-brain pour créer un système robuste et résilient qui protège votre charge de travail de l'accès interne et externe.

Autres améliorations de la sécurité

• Application Gateway : vous pouvez utiliser un WAF sur Application Gateway pour protéger vos applications web contre les vulnérabilités et le code malveillant exploitant une faille de sécurité les plus courants sur le web. Vous pouvez également utiliser Azure Private Link pour accéder en toute sécurité à vos serveurs d’applications principaux à partir d’Application Gateway sans les exposer à l’Internet public.

• Pare-feu Azure : vous pouvez ajouter un pare-feu Azure au réseau virtuel hub et utiliser Threat Intelligence du Pare-feu Azure pour bloquer le trafic malveillant provenant d’adresses IP et de domaines malveillants connus. Vous pouvez également utiliser le Pare-feu Azure en tant que proxy DNS pour intercepter et inspecter le trafic DNS et appliquer des règles de filtrage DNS.

• Azure Front Door : vous pouvez utiliser Azure Web Application Firewall pour protéger vos applications web contre les vulnérabilités et le code malveillant exploitant une faille de sécurité les plus courants sur le web à la périphérie. Vous pouvez également utiliser Private Link avec le niveau Premium d'Azure Front Door pour accéder en toute sécurité à vos serveurs d’applications principaux à partir d’Azure Front Door sans les exposer à l’Internet public.

Optimisation des coûts

L’optimisation des coûts consiste à examiner les moyens de réduire les dépenses inutiles et d’améliorer l’efficacité opérationnelle. Pour plus d'informations, consultez Liste de contrôle de la révision de la conception pour l'optimisation des coûts.

• Calcul en back-end : de nombreux facteurs, tels que la sélection de références SKU, le nombre de réplicas et la région déterminent le coût d'exécution des services de calcul en back-end. Veillez à prendre en compte tous les éléments d’une ressource de calcul avant de sélectionner la meilleure option pour votre charge de travail.

• Application Gateway : les coûts d’Application Gateway dépendent du nombre d’instances, de leur taille et de la quantité de données traitées. Vous pouvez optimiser les coûts à l’aide de la mise à l’échelle automatique pour ajuster le nombre d’instances en fonction de la demande de trafic. Vous pouvez également déployer des références SKU redondantes interzone entre plusieurs zones de disponibilité, afin de réduire le besoin d'instances supplémentaires pour la haute disponibilité.

• Azure Front Door : les coûts d’Azure Front Door dépendent du nombre de règles de routage, du nombre de requêtes HTTP ou HTTPS et de la quantité de données transférées. Vous pouvez utiliser le niveau Premium ou Standard d'Azure Front Door pour bénéficier d’une expérience unifiée avec Azure Content Delivery Network, Azure Web Application Firewall et Private Link. Vous pouvez également utiliser la fonctionnalité du moteur de règles pour Azure Front Door pour personnaliser la gestion du trafic et optimiser les performances et les coûts.

  Si votre scénario ne nécessite pas d’accès global ou les fonctionnalités supplémentaires d’Azure Front Door, vous pouvez utiliser cette solution avec Application Gateway uniquement. Vous pouvez faire pointer tous les enregistrements DNS publics vers l’adresse IP publique configurée sur les écouteurs Application Gateway.

Découvrez un exemple de cette solution qui se rapproche de l'utilisation typique des composants de cette architecture. Ajustez les coûts en fonction de votre scénario.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

• Troy Hite | Architecte de solutions cloud senior

Autres contributeurs :

• Mays Algebary | Spécialiste senior de mise en réseau Azure Global Blackbelt
• Adam Torkar | Spécialiste senior de mise en réseau Azure Global Blackbelt
• Michael McKechney | Spécialiste principal de la technologie Azure

Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.

Étapes suivantes

• Configuration de l’infrastructure Application Gateway
• TLS de bout en bout avec Azure Front Door
• Ajoutez un domaine personnalisé à Azure Front Door
• Présentation du filtrage géographique sur un domaine Azure Front Door

Ressources associées

• Pare-feu et Application Gateway pour réseaux virtuels
• Utiliser Azure Front Door dans une solution multilocataire