Een split-brain DNS-configuratie gebruiken om een web-app in Azure te hosten

Teams die workloads beheren, zijn vaak afhankelijk van FQDN's (Fully Qualified Domain Names) voor klanttoegang. FQDN's worden doorgaans gecombineerd met TLS-servernaamindicatie (Transport Layer Security). Wanneer openbare klanten met deze methode toegang hebben tot een workload vanaf het openbare internet of zakelijke klanten, hebben ze intern toegang tot een workload, kan de routering naar de toepassing vaste paden volgen en verschillende niveaus van beveiliging of kwaliteit van de service (QoS) hebben.

In de volgende architectuur ziet u een benadering om onderscheid te maken tussen hoe verkeer wordt behandeld op basis van dns (Domain Name System) en of de klant afkomstig is van internet of van een bedrijfsnetwerk.

Architectuur

Een Visio-bestand van deze architectuur downloaden.

In de volgende werkstroomsecties worden twee configuraties beschreven: een openbare internetwerkstroom en een privéwerkstroom. Combineer de twee werkstromen om een split-brain hostingarchitectuur te implementeren.

Openbare internetwerkstroom

Een Visio-bestand van deze architectuur downloaden.

1. Klanten verzenden een aanvraag voor de app.contoso.com toepassing via het openbare internet.

2. Er is een Azure DNS-zone geconfigureerd voor het contoso.com domein. De juiste CNAME-vermeldingen (Canonical Name) zijn geconfigureerd voor de Azure Front Door-eindpunten.

3. Externe klanten hebben toegang tot de webtoepassing via Azure Front Door, die fungeert als een globale load balancer en een WAF (Web Application Firewall).

   • Binnen Azure Front Door app.contoso.com wordt deze toegewezen als de FQDN via routes op een geconfigureerd eindpunt. Azure Front Door host ook de TLS SNI-certificaten voor de toepassingen.

     Notitie

     Azure Front Door biedt geen ondersteuning voor zelfondertekende certificaten.

   • Azure Front Door stuurt de aanvragen naar de geconfigureerde oorspronkelijke groep op basis van de HTTP-header van Host de klant.

   • De oorspronkelijke groep is geconfigureerd om te verwijzen naar het Azure-toepassing Gateway-exemplaar via het openbare IP-adres van Application Gateway.

4. Een netwerkbeveiligingsgroep (NSG) is geconfigureerd in het AppGW-subnet om binnenkomende toegang op poort 80 en poort 443 toe te staan vanuit de servicetag AzureFrontDoor.Backend . De netwerkbeveiligingsgroep staat binnenkomend verkeer op poort 80 en poort 443 niet toe vanuit de internetservicetag.

   Notitie

   De servicetag AzureFrontDoor.Backend beperkt verkeer niet alleen tot uw exemplaar van Azure Front Door. Validatie vindt plaats in de volgende fase.

5. Het Application Gateway-exemplaar heeft een listener op poort 443. Verkeer wordt doorgestuurd naar de back-end op basis van de hostnaam die is opgegeven in de listener.

   • Om ervoor te zorgen dat verkeer afkomstig is van uw Azure Front Door-profiel, configureert u een aangepaste WAF-regel om de X-Azure-FDID headerwaarde te controleren.

   • Azure genereert een unieke id voor elk Azure Front Door-profiel. De unieke id is de Front Door ID-waarde op de overzichtspagina van Azure Portal.

6. Verkeer bereikt de rekenresource die is geconfigureerd als een back-endpool in Application Gateway.

Werkstroom voor privé-ondernemingen

Een Visio-bestand van deze architectuur downloaden.

1. Klanten initiëren een aanvraag voor de app.contoso.com toepassing vanuit een on-premises omgeving.

2. FQDN's voor toepassingen worden geconfigureerd op de on-premises DNS-provider. Deze DNS-provider kan on-premises Dns-servers van Windows Server Active Directory of andere partneroplossingen zijn. De DNS-vermeldingen voor elk van de FQDN's van de toepassing zijn geconfigureerd om te verwijzen naar het privé-IP-adres van het Application Gateway-exemplaar.

3. Een Azure ExpressRoute-circuit of een site-naar-site-VPN vereenvoudigt de toegang tot Application Gateway.

4. Een NSG is geconfigureerd in het AppGW-subnet om binnenkomende privéaanvragen van on-premises klantnetwerken toe te staan waaruit verkeer afkomstig is. Deze configuratie zorgt ervoor dat andere bronnen van privéverkeer het privé-IP-adres van Application Gateway niet rechtstreeks kunnen bereiken.

5. Application Gateway heeft een listener die is geconfigureerd op poort 80 en poort 443. Verkeer wordt doorgestuurd naar de back-end op basis van de hostnaam die is opgegeven in de listener.

6. Alleen privénetwerkverkeer bereikt de berekening die is geconfigureerd als een back-endpool in Application Gateway.

Onderdelen

• DNS: Voor een openbare internetwerkstroom moet u een openbare Azure DNS-zone configureren met de juiste CNAME van de Azure Front Door-eindpunt-FQDN. Configureer aan de privézijde (enterprise) de lokale DNS-provider (Windows Server Active Directory DNS of een partneroplossing) om elke toepassings-FQDN te laten verwijzen naar het privé-IP-adres van Application Gateway.

• Privé-resolver van Azure DNS: u kunt dns-privéomzetting gebruiken voor de resolutie van on-premises klanten. Enterprise-klanten kunnen deze split-brain DNS-oplossing gebruiken om toegang te krijgen tot toepassingen zonder het openbare internet te doorlopen.

• Azure Front Door: Azure Front Door is een wereldwijde load balancer en WAF die snelle en veilige levering van webtoepassingen biedt aan klanten over de hele wereld. In deze architectuur stuurt Azure Front Door externe klanten naar het Application Gateway-exemplaar en biedt caching- en optimalisatieopties om de klantervaring te verbeteren.

• Application Gateway: Application Gateway is een regionale load balancer en WAF die hoge beschikbaarheid, schaalbaarheid en beveiliging biedt voor webtoepassingen. In deze architectuur stuurt Application Gateway aanvragen van externe en interne klanten naar de back-end-berekening en beschermt de webtoepassing tegen veelvoorkomende webaanvallen.

  Zowel Azure Front Door als Application Gateway bieden WAF-mogelijkheden, maar de privéwerkstroom in deze oplossing maakt geen gebruik van Azure Front Door. Daarom gebruiken beide architecturen de WAF-functionaliteit van Application Gateway.

• ExpressRoute: U kunt ExpressRoute gebruiken om uw on-premises netwerken uit te breiden naar de Microsoft Cloud via een privéverbinding, met behulp van een connectiviteitsprovider. In deze architectuur kunt u ExpressRoute gebruiken om privéconnectiviteit met Application Gateway te vergemakkelijken voor on-premises klanten.

Alternatieven

Als alternatieve oplossing kunt u Azure Front Door verwijderen en in plaats daarvan de openbare Azure DNS-record verwijzen naar het openbare IP-adres van Application Gateway. Op basis van de vereisten van deze architectuur moet u caching en optimalisatie uitvoeren op het toegangspunt in Azure. Daarom is de alternatieve oplossing geen optie voor dit scenario. Zie Kostenoptimalisatie voor meer informatie.

Een Visio-bestand van deze architectuur downloaden.

Andere mogelijke alternatieven voor het openbare inkomend verkeer in deze architectuur zijn:

• Azure Traffic Manager: Traffic Manager is een op DNS gebaseerde verkeersrouteringsservice die verkeer distribueert over verschillende regio's en eindpunten. U kunt Traffic Manager gebruiken in plaats van Azure Front Door om externe klanten naar het dichtstbijzijnde Application Gateway-exemplaar te routeren. Azure Front Door biedt echter functies, zoals WAF-mogelijkheden, caching en sessieaffiniteit. Traffic Manager biedt deze functies niet.

• Azure Load Balancer: Azure Load Balancer is een netwerk load balancer die hoge beschikbaarheid en schaalbaarheid biedt voor UDP-verkeer (Transmission Control Protocol) en User Datagram Protocol (UDP). U kunt Load Balancer gebruiken in plaats van Application Gateway om aanvragen van externe en interne klanten naar back-endwebservers te routeren. Application Gateway biedt echter functies, zoals WAF-mogelijkheden, SSL-beëindiging (Secure Sockets Layer) en sessieaffiniteit op basis van cookies. Load Balancer biedt deze functies niet.

Scenariodetails

Dit scenario lost het probleem op van het hosten van een webtoepassing die zowel externe als interne klanten bedient. Deze architectuur zorgt ervoor dat verkeer een geschikt pad volgt op basis van de oorsprong van een klant. Deze architectuur:

• Biedt snelle en betrouwbare toegang via internet tot een webtoepassing voor niet-zakelijke klanten over de hele wereld.

• Biedt zakelijke klanten de mogelijkheid om toegang te krijgen tot een toepassing zonder het openbare internet te doorlopen.

• Beschermt een webtoepassing tegen veelvoorkomende webaanvallen en schadelijk verkeer.

Potentiële gebruikscases

Gebruik deze architectuur voor scenario's waarvoor het volgende is vereist:

• Split-brain DNS: deze oplossing maakt gebruik van Azure Front Door voor externe klanten en Application Gateway voor interne klanten, met verschillende DNS-records voor elke service. Deze aanpak helpt bij het optimaliseren van de netwerkprestaties, beveiliging en beschikbaarheid voor verschillende klanten.

• Schaalbaarheid van toepassingen: deze oplossing maakt gebruik van Application Gateway, waarmee verkeer kan worden verdeeld over geconfigureerde back-end-rekenresources. Deze aanpak helpt de prestaties en beschikbaarheid van toepassingen te verbeteren en horizontaal schalen te ondersteunen.

Overwegingen

Met deze overwegingen worden de pijlers van het Azure Well-Architected Framework geïmplementeerd. Dit is een set richtlijnen die kunnen worden gebruikt om de kwaliteit van een workload te verbeteren. Zie Microsoft Azure Well-Architected Framework voor meer informatie.

Betrouwbaarheid

Betrouwbaarheid zorgt ervoor dat uw toepassing kan voldoen aan de toezeggingen die u aan uw klanten hebt gedaan. Zie de controlelijst ontwerpbeoordeling voor betrouwbaarheid voor meer informatie.

• Identificeer storingspunten: In deze split-brain DNS-architectuur is betrouwbaarheid afhankelijk van de juiste werking van belangrijke onderdelen, zoals Azure Front Door, Application Gateway en DNS-configuraties. U moet potentiële foutpunten identificeren, zoals onjuiste configuraties, problemen met SSL-certificaten of overbelasting van capaciteit.

• Impact beoordelen: u moet de impact van fouten beoordelen. Voor externe klanten kan elke onderbreking van Azure Front Door, die als gateway fungeert, invloed hebben op wereldwijde toegang. Voor interne klanten kan elke onderbreking van Application Gateway bedrijfsactiviteiten belemmeren.

• Risicobeperkingsstrategieën implementeren: om risico's te beperken, redundantie in meerdere beschikbaarheidszones te implementeren, statustests te gebruiken voor realtime-bewaking en ervoor te zorgen dat de juiste configuratie van DNS-routering voor zowel extern als intern verkeer wordt uitgevoerd. Zorg ervoor dat u DNS-records regelmatig bijwerkt en een noodherstelplan hebt.

• Continu bewaken: Gebruik Azure Monitor-functies om de status van uw systeem in de gaten te houden. Stel waarschuwingen in voor afwijkingen en laat een plan voor incidentrespons gereed om mogelijke problemen onmiddellijk op te lossen.

Houd zich aan deze principes om een robuust en betrouwbaar systeem te garanderen dat bestand is tegen uitdagingen en servicecontinuïteit kan behouden.

Beveiliging

Beveiliging biedt garanties tegen opzettelijke aanvallen en misbruik van uw waardevolle gegevens en systemen. Zie de controlelijst ontwerpbeoordeling voor beveiliging voor meer informatie.

• Gebruik de Zero Trust-benadering: Pas in de DNS-installatie van split-brain de Zero Trust-benadering toe. Controleer expliciet de identiteit van een klant, ongeacht of deze afkomstig zijn van internet of een bedrijfsnetwerk. Deze aanpak zorgt ervoor dat alleen vertrouwde entiteiten geautoriseerde acties uitvoeren.

• Implementatie: Implementeer Microsoft Entra ID voor robuust identiteitsbeheer. Gebruik beleid voor voorwaardelijke toegang van Microsoft Entra om strikte toegangsbeheer af te dwingen op basis van klantcontext, apparaatstatus en locatie.

• Beveiligingseffectiviteit beoordelen: evalueer de effectiviteit van de beveiligingsmaatregelen voor uw workload met dubbele toegang door het implementeren van:

  • Defensieve investeringen: evalueer regelmatig de effectiviteit van Azure Front Door en Application Gateway. Zorg ervoor dat ze zinvolle bescherming bieden tegen bedreigingen.

  • Straalbeperking: Zorg ervoor dat u beveiligingsschendingen binnen een beperkt bereik bevat. U kunt bijvoorbeeld externe en interne verkeersstromen effectief isoleren.

• Stel een inbreuk in: bevestig dat aanvallers beveiligingscontroles kunnen schenden. Bereid u voor op dergelijke scenario's.

• Beveiligingsmaatregelen implementeren: netwerksegmentatie, microsegmentatie en NSG's implementeren. Stel dat een aanvaller toegang kan krijgen en de besturingselementen dienovereenkomstig compenseert.

Integreer deze beveiligingsprincipes in uw split-brain DNS-architectuur om een robuust en tolerant systeem te maken dat interne en externe toegang tot uw workload beschermt.

Andere beveiligingsverbeteringen

• Application Gateway: U kunt een WAF op Application Gateway gebruiken om uw webtoepassingen te beschermen tegen veelvoorkomende beveiligingsproblemen en aanvallen op internet. U kunt Azure Private Link ook gebruiken om veilig toegang te krijgen tot uw back-endtoepassingsservers vanuit Application Gateway zonder ze beschikbaar te maken op het openbare internet.

• Azure Firewall: U kunt een Azure-firewall toevoegen aan het virtuele hubnetwerk en azure Firewall-bedreigingsinformatie gebruiken om schadelijk verkeer van bekende schadelijke IP-adressen en domeinen te blokkeren. U kunt Azure Firewall ook gebruiken als EEN DNS-proxy om DNS-verkeer te onderscheppen en te inspecteren en regels voor DNS-filtering toe te passen.

• Azure Front Door: u kunt Azure Web Application Firewall gebruiken om uw webtoepassingen te beschermen tegen veelvoorkomende beveiligingsproblemen en aanvallen aan de rand. U kunt Private Link ook gebruiken met de Azure Front Door Premium-laag om veilig toegang te krijgen tot uw back-endtoepassingsservers van Azure Front Door zonder ze beschikbaar te maken voor het openbare internet.

Kostenoptimalisatie

Kostenoptimalisatie gaat over manieren om onnodige uitgaven te verminderen en operationele efficiëntie te verbeteren. Zie de controlelijst ontwerpbeoordeling voor Kostenoptimalisatie voor meer informatie.

• Back-end berekenen: Veel factoren, zoals SKU-selectie, aantal replica's en regio's, stimuleren de kosten voor het uitvoeren van back-end-rekenservices. Zorg ervoor dat u rekening houdt met alle elementen van een rekenresource voordat u de beste optie voor uw workload selecteert.

• Application Gateway: de kosten van Application Gateway zijn afhankelijk van het aantal exemplaren, de grootte van exemplaren en de hoeveelheid verwerkte gegevens. U kunt kosten optimaliseren door automatisch schalen te gebruiken om het aantal exemplaren aan te passen op basis van de vraag naar verkeer. U kunt ook zone-redundante SKU's implementeren in beschikbaarheidszones om de behoefte aan extra exemplaren voor hoge beschikbaarheid te verminderen.

• Azure Front Door: Azure Front Door-kosten zijn afhankelijk van het aantal routeringsregels, het aantal HTTP- of HTTPS-aanvragen en de hoeveelheid overgedragen gegevens. U kunt de Azure Front Door Standard-laag of Premium-laag gebruiken om een uniforme ervaring te krijgen met Azure Content Delivery Network, Azure Web Application Firewall en Private Link. U kunt ook de azure Front Door-regelenginefunctie gebruiken om verkeerbeheer aan te passen en de prestaties en kosten te optimaliseren.

  Als uw scenario geen globale toegang of de extra functies van Azure Front Door vereist, kunt u deze oplossing gebruiken met alleen Application Gateway. U kunt alle openbare DNS-records laten verwijzen naar het openbare IP-adres dat is geconfigureerd op de Application Gateway-listeners.

Bekijk een voorbeeld van deze oplossing waarmee het typische gebruik van de onderdelen in deze architectuur wordt geschat. Pas de kosten aan op uw scenario.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Troy Hite | Senior Cloud Solution Architect

Andere Inzenders:

• Mays Algebary | Senior Azure Networking Global Blackbelt
• Adam Torkar | Senior Azure Networking Global Blackbelt
• Michael McKechney | Principal Azure Technology Specialist

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Infrastructuurconfiguratie van Application Gateway
• End-to-end TLS met Azure Front Door
• Voeg een aangepast domein toe aan Azure Front Door
• Wat is geofiltering op een domein voor Azure Front Door?

Verwante resources

• Firewall en Application Gateway voor virtuele netwerken
• Azure Front Door gebruiken in een multitenant-oplossing