Utiliser une configuration DNS fractionnée pour héberger une application web dans Azure

Azure Front Door
Application Gateway Azure
Azure ExpressRoute
Azure DNS

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 (FQDN) sont généralement combinés avec l’indication de nom de serveur (SNI) du protocole TLS (Transport Layer Security). Avec cette approche, lorsque les clients publics accèdent à une charge de travail à partir de l’Internet public ou des clients d’entreprise accèdent à une charge de travail en interne, le routage vers l’application peut suivre des chemins fixes et avoir différents niveaux de sécurité ou de qualité de service (QoS).

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

Architecture

Diagramme de l’architecture d’hébergement d’applications.

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

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

Flux de travail Internet public

Diagramme du flux de travail 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 Standard ou Premium, 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 FQDN via des routes sur un point de terminaison configuré. Azure Front Door héberge également les certificats TLS SNI pour les applications.

      Note

      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 Host du client.

    • Le groupe d’origine est configuré pour pointer vers l’instance de Azure Application Gateway via l’adresse IP publique 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 la balise de service Internet.

    Note

    La balise de service AzureFrontDoor.Backend ne limite pas le trafic uniquement à votre instance d’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 Azure Front Door ID 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.

Flux de travail d’entreprise privée

Diagramme du flux de travail d’entreprise privée.

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 des serveurs DNS locaux services de domaine Active Directory (AD DS) 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 NSG (groupe de sécurité réseau) est configuré sur le sous-réseau AppGW pour autoriser les requêtes privées entrantes provenant des réseaux clients sur site d'origine du 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.

Components

  • DNS est un système qui mappe les noms de domaine aux adresses IP, ce qui permet aux clients de localiser et de se connecter aux services. Pour un flux de travail Internet public dans cette architecture, vous devez configurer une zone DNS publique avec le nom de domaine complet du point de terminaison Azure Front Door approprié. Côté privé (entreprise), configurez le fournisseur DNS local (DNS AD DS ou une solution partenaire) pour pointer chaque nom de domaine complet d’application vers l’adresse IP privée d’Application Gateway.

  • Azure DNS Programme de résolution privé est un service entièrement managé qui permet la résolution DNS entre les environnements locaux et les Azure sans déployer de serveurs DNS personnalisés. Dans cette architecture, DNS Private Resolver permet la résolution des clients locaux, afin que les utilisateurs d’entreprise puissent utiliser cette solution DNS fractionnée pour accéder aux applications sans parcourir l’Internet public.

  • Azure Front Door est un équilibreur de charge global et waf qui fournit une livraison rapide et sécurisée d’applications web aux clients mondiaux. Dans cette architecture, Azure Front Door Standard ou Premium 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 est un équilibreur de charge régional et waf qui fournit une haute disponibilité, une scalabilité et une sécurité pour les applications web. Dans cette architecture, Application Gateway achemine les demandes client externes et internes vers le calcul principal et protège l’application web contre les attaques web courantes.

    Azure Front Door et Application Gateway offrent des fonctionnalités WAF, mais le flux de travail privé de cette solution n’utilise pas Azure Front Door. Par conséquent, les deux architectures utilisent la fonctionnalité WAF Application Gateway.

  • ExpressRoute est un service qui étend les réseaux locaux dans le cloud via une connexion privée établie par un fournisseur de connectivité. Dans cette architecture, ExpressRoute facilite la connectivité privée à Application Gateway pour les clients locaux.

Alternatives

En guise de solution alternative, vous pouvez supprimer Azure Front Door Standard ou Premium et pointer à la place l’enregistrement DNS public vers l’adresse IP publique d’Application Gateway. En fonction des exigences de cette architecture, vous devez cacher et optimiser le trafic au point d'entrée dans Azure. Par conséquent, vous ne pouvez pas utiliser la solution alternative pour ce scénario. Pour plus d’informations, consultez Optimisation des coûts.

Diagramme de l'architecture d'hébergement DNS à cerveau partagé alternative.

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

D’autres alternatives possibles pour le trafic d’entrée public dans cette architecture sont les suivantes :

  • 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 de Azure Front Door Standard ou Premium pour acheminer les clients externes vers l’instance Application Gateway la plus proche. Toutefois, Azure Front Door fournit des fonctionnalités, telles que les fonctionnalités WAF, la mise en cache et l’affinité de session. Traffic Manager ne fournit pas ces fonctionnalités.

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

Détails du scénario

Ce scénario résout le problème d’hébergement d’une application web qui sert à la fois des clients externes et internes. Cette architecture garantit que le trafic suit un chemin approprié en fonction de l’origine d’un client. Cette architecture :

  • Fournit un accès rapide et fiable via Internet à une application web pour les clients non commerciaux à l'échelle mondiale.

  • Fournit aux clients d’entreprise la possibilité d’accéder à une application sans traverser l’Internet public.

  • Protège une application web contre les attaques web courantes et le trafic malveillant.

Cas d’usage potentiels

Utilisez cette architecture pour les scénarios nécessitant :

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

  • Scalabilité des applications : Cette solution utilise Application Gateway, qui peut distribuer le trafic entre les ressources de calcul principales configurées. Cette approche permet d’améliorer les performances et la disponibilité des applications et de prendre en charge la mise à l’échelle horizontale.

Considerations

Ces considérations implémentent les piliers d’Azure Well-Architected Framework, un ensemble de principes directeurs que vous pouvez utiliser pour améliorer la qualité d’une charge de travail. Pour plus d’informations, consultez Well-Architected Framework.

Reliability

La fiabilité permet de s’assurer que votre application peut respecter les engagements que vous prenez à vos clients. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour la fiabilité.

  • Identifiez les points d’échec. Dans cette architecture DNS fractionnée, la fiabilité dépend du bon fonctionnement des composants clés, tels que Azure Front Door, Application Gateway et les configurations DNS. Vous devez identifier les points d’échec potentiels, tels que les erreurs de configuration, les problèmes de certificat SSL ou les surcharges de capacité.

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

  • Implémenter des stratégies d’atténuation. Pour atténuer les risques, implémentez la redondance entre plusieurs zones de disponibilité, utilisez des sondes d’intégrité pour la surveillance en temps réel et assurez-vous de 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 récupération d’urgence.

  • Surveillez en continu. Pour garder un œil vigilant sur la santé de votre système, utilisez Azure Monitor fonctionnalités. Configurez des alertes pour les anomalies et disposez d’un plan de réponse aux incidents prêt à résoudre rapidement les problèmes potentiels.

Respectez ces principes pour garantir un système robuste et fiable capable de résister aux défis et de maintenir la continuité des services.

Security

La sécurité offre des garanties contre les attaques délibérées et l’utilisation abusive de vos données et systèmes précieux. Pour plus d’informations, consultez la liste de vérification de la révision de conception pour la sécurité.

  • Utilisez l’approche Confiance nulle. Dans la configuration DNS fractionnée, appliquez l’approche Confiance nulle. Vérifiez explicitement l’identité d’un client, qu’il provient d’Internet ou d’un réseau d’entreprise. Cette approche garantit que seules les entités approuvées peuvent effectuer des actions autorisées.

  • Implémentez efficacement les contrôles d’identité et d’accès. Implémentez Microsoft Entra ID pour une gestion des identités robuste. Utilisez les stratégies 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 vos mesures de sécurité. Évaluez l’efficacité des mesures de sécurité pour votre charge de travail à double accès en implémentant :

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

      • Limitez l’étendue de l’impact des violations potentielles. Assurez-vous que vous contenez des violations de sécurité dans une étendue limitée. Par exemple, isolez efficacement les flux de trafic externe et interne.

  • Supposons qu’une violation soit toujours possible. Reconnaissez que les attaquants peuvent violer les contrôles de sécurité. Préparez-vous à de tels scénarios.

  • Implémentez des mesures de sécurité de manière complète. Implémentez la segmentation réseau, la micro-segmentation et les groupes de sécurité réseau. Supposons qu’un attaquant peut obtenir l’accès et concevoir des contrôles de compensation en conséquence.

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

Autres améliorations de sécurité

  • Application Gateway : Vous pouvez utiliser un WAF sur Application Gateway pour protéger vos applications web contre les vulnérabilités et les attaques web courantes. 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 Azure firewall au réseau virtuel hub et utiliser Pare-feu Azure renseignement sur les menaces pour bloquer le trafic malveillant provenant d’adresses IP et de domaines malveillants connus. Vous pouvez également utiliser le Pare-feu Azure comme 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 web courantes et les attaques en périphérie. Vous pouvez également utiliser Private Link avec le niveau Azure Front Door Premium pour accéder en toute sécurité à vos serveurs d’applications back-end à partir d’Azure Front Door sans les exposer à l’Internet public.

Optimisation des coûts

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

  • Calcul back-end : De nombreux facteurs, tels que la sélection de SKU, le nombre de réplicas et la région, influencent le coût d'exécution des services de calcul 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 la taille des instances 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 dans des zones de disponibilité afin de réduire le besoin d’instances supplémentaires pour la haute disponibilité.

  • Azure Front Door : Azure Front Door coûts 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 Azure Front Door Standard ou Premium 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 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 uniquement avec Application Gateway. Vous pouvez pointer tous les enregistrements DNS publics vers l’adresse IP publique configurée sur les écouteurs Application Gateway.

Consultez un exemple de cette solution qui correspond approximativement à l’utilisation classique des composants de cette architecture. Ajustez les coûts en fonction de votre scénario.

Contributors

Microsoft maintient cet article. Les contributeurs suivants ont écrit cet article.

Auteur principal :

Autres contributeurs :

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

Étapes suivantes