Redigera

Dela via


Använda en DNS-konfiguration med delad hjärna som värd för en webbapp i Azure

Azure Front Door
Azure Application Gateway
Azure ExpressRoute
Azure DNS

Team som hanterar arbetsbelastningar förlitar sig ofta på fullständigt kvalificerade domännamn (FQDN) för kundåtkomst. FQDN kombineras vanligtvis med TLS (Transport Layer Security) Server Name Indication (SNI). Med den här metoden kan routningen till programmet följa fasta sökvägar och ha olika nivåer av säkerhet eller tjänstkvalitet (QoS) när offentliga kunder får åtkomst till en arbetsbelastning från det offentliga Internet eller företagskunder som har åtkomst till en arbetsbelastning internt.

Följande arkitektur visar en metod för att särskilja hur trafik behandlas baserat på DNS (Domain Name System) och om kunden kommer från Internet eller från ett företagsnätverk.

Arkitektur

Diagram över programvärdarkitekturen.

Ladda ned en Visio-fil med den här arkitekturen.

I följande arbetsflödesavsnitt beskrivs två konfigurationer: ett offentligt internetarbetsflöde och ett privat arbetsflöde. Kombinera de två arbetsflödena för att implementera en arkitektur för delad hjärna.

Offentligt internetarbetsflöde

Diagram över det offentliga internetarbetsflödet.

Ladda ned en Visio-fil med den här arkitekturen.

  1. Kunder skickar en begäran om app.contoso.com programmet via det offentliga Internet.

  2. En Azure DNS-zon har konfigurerats för den contoso.com domänen. Lämpliga poster för kanoniskt namn (CNAME) konfigureras för Azure Front Door-slutpunkterna.

  3. Externa kunder får åtkomst till webbprogrammet via Azure Front Door, som fungerar som en global lastbalanserare och en brandvägg för webbprogram (WAF).

    • I Azure Front Door app.contoso.com tilldelas som FQDN via vägar på en konfigurerad slutpunkt. Azure Front Door är också värd för TLS SNI-certifikaten för programmen.

      Kommentar

      Azure Front Door stöder inte självsignerade certifikat.

    • Azure Front Door dirigerar begäranden till den konfigurerade ursprungsgruppen baserat på kundens Host HTTP-huvud.

    • Ursprungsgruppen är konfigurerad för att peka på Azure Application Gateway-instansen via Application Gateways offentliga IP-adress.

  4. En nätverkssäkerhetsgrupp (NSG) konfigureras i AppGW-undernätet för att tillåta inkommande åtkomst på port 80 och port 443 från azurefrontdoor.backend-tjänsttaggen . NSG tillåter inte inkommande trafik på port 80 och port 443 från internettjänsttaggen.

    Kommentar

    Tjänsttaggen AzureFrontDoor.Backend begränsar inte enbart trafik till din instans av Azure Front Door. Verifieringen sker i nästa steg.

  5. Application Gateway-instansen har en lyssnare på port 443. Trafiken dirigeras till serverdelen baserat på det värdnamn som anges i lyssnaren.

    • För att säkerställa att trafiken kommer från din Azure Front Door-profil konfigurerar du en anpassad WAF-regel för att kontrollera X-Azure-FDID rubrikvärdet.

    • Azure genererar en unik identifierare för varje Azure Front Door-profil. Den unika identifieraren är frontdörrens ID-värde som finns på översiktssidan i Azure-portalen.

  6. Trafiken når beräkningsresursen som har konfigurerats som en serverdelspool i Application Gateway.

Arbetsflöde för privat företag

Diagram över arbetsflödet för privat företag.

Ladda ned en Visio-fil med den här arkitekturen.

  1. Kunder initierar en begäran för app.contoso.com programmet från en lokal miljö.

  2. Program-FQDN:er konfigureras på den lokala DNS-providern. Den här DNS-providern kan vara lokala Windows Server Active Directory DNS-servrar eller andra partnerlösningar. DNS-posterna för vart och ett av programmets FQDN:er är konfigurerade för att peka på den privata IP-adressen för Application Gateway-instansen.

  3. En Azure ExpressRoute-krets eller ett plats-till-plats-VPN underlättar åtkomsten till Application Gateway.

  4. En NSG konfigureras i AppGW-undernätet för att tillåta inkommande privata begäranden från lokala kundnätverk där trafiken kommer från. Den här konfigurationen säkerställer att andra källor för privat trafik inte direkt kan nå den privata IP-adressen för Application Gateway.

  5. Application Gateway har en lyssnare som är konfigurerad på port 80 och port 443. Trafiken dirigeras till serverdelen baserat på det värdnamn som anges i lyssnaren.

  6. Endast privat nätverkstrafik når den beräkning som har konfigurerats som en serverdelspool i Application Gateway.

Komponenter

  • DNS: För ett offentligt internetarbetsflöde måste du konfigurera en offentlig Azure DNS-zon med rätt CNAME för Azure Front Door-slutpunktens FQDN. På den privata sidan (företag) konfigurerar du den lokala DNS-providern (Windows Server Active Directory DNS eller en partnerlösning) för att peka varje program-FQDN till den privata IP-adressen för Application Gateway.

  • Privat Lösning för Azure DNS: Du kan använda DNS Private Resolver för lösning av lokala kunder. Företagskunder kan använda den här DNS-lösningen med delad hjärna för att få åtkomst till program utan att gå igenom det offentliga Internet.

  • Azure Front Door: Azure Front Door är en global lastbalanserare och WAF som ger snabb och säker leverans av webbprogram till kunder runt om i världen. I den här arkitekturen dirigerar Azure Front Door externa kunder till Application Gateway-instansen och tillhandahåller alternativ för cachelagring och optimering för att förbättra kundupplevelsen.

  • Application Gateway: Application Gateway är en regional lastbalanserare och WAF som ger hög tillgänglighet, skalbarhet och säkerhet för webbprogram. I den här arkitekturen dirigerar Application Gateway externa och interna kundförfrågningar till serverdelsberäkningen och skyddar webbprogrammet från vanliga webbattacker.

    Både Azure Front Door och Application Gateway tillhandahåller WAF-funktioner, men det privata arbetsflödet i den här lösningen använder inte Azure Front Door. Därför använder båda arkitekturerna WAF-funktionerna i Application Gateway.

  • ExpressRoute: Du kan använda ExpressRoute för att utöka dina lokala nätverk till Microsoft Cloud via en privat anslutning med hjälp av en anslutningsleverantör. I den här arkitekturen kan du använda ExpressRoute för att underlätta privat anslutning till Application Gateway för lokala kunder.

Alternativ

Som en alternativ lösning kan du ta bort Azure Front Door och i stället peka den offentliga Azure DNS-posten på den offentliga IP-adressen för Application Gateway. Baserat på den här arkitekturens krav måste du göra cachelagring och optimering vid startpunkten i Azure. Därför är den alternativa lösningen inte ett alternativ för det här scenariot. Mer information finns i Kostnadsoptimering.

Diagram över den alternativa DNS-värdarkitekturen för delad hjärna.

Ladda ned en Visio-fil med den här arkitekturen.

Andra möjliga alternativ för den offentliga ingresstrafiken i den här arkitekturen är:

  • Azure Traffic Manager: Traffic Manager är en DNS-baserad trafikroutningstjänst som distribuerar trafik mellan olika regioner och slutpunkter. Du kan använda Traffic Manager i stället för Azure Front Door för att dirigera externa kunder till närmaste Application Gateway-instans. Azure Front Door innehåller dock funktioner som WAF-funktioner, cachelagring och sessionstillhörighet. Traffic Manager tillhandahåller inte dessa funktioner.

  • Azure Load Balancer: Azure Load Balancer är en lastbalanserare för nätverk som ger hög tillgänglighet och skalbarhet för TCP-trafik (Transmission Control Protocol) och UDP-trafik (User Datagram Protocol). Du kan använda Load Balancer i stället för Application Gateway för att dirigera externa och interna kundförfrågningar till serverdelswebbservrar. Application Gateway tillhandahåller dock funktioner, till exempel WAF-funktioner, SSL-avslutning (Secure Sockets Layer) och cookiebaserad sessionstillhörighet. Load Balancer tillhandahåller inte dessa funktioner.

Information om scenario

Det här scenariot löser problemet med att vara värd för ett webbprogram som betjänar både externa och interna kunder. Den här arkitekturen säkerställer att trafiken följer en lämplig sökväg baserat på kundens ursprung. Den här arkitekturen:

  • Ger snabb och tillförlitlig åtkomst via Internet till ett webbprogram för icke-företagskunder runt om i världen.

  • Ger företagskunder möjlighet att komma åt ett program utan att passera det offentliga Internet.

  • Skyddar ett webbprogram från vanliga webbattacker och skadlig trafik.

Potentiella användningsfall

Använd den här arkitekturen för scenarier som kräver:

  • Split-brain DNS: Den här lösningen använder Azure Front Door för externa kunder och Application Gateway för interna kunder, med olika DNS-poster för varje tjänst. Den här metoden hjälper till att optimera nätverksprestanda, säkerhet och tillgänglighet för olika kunder.

  • Skalbarhet för program: Den här lösningen använder Application Gateway, som kan distribuera trafik mellan konfigurerade beräkningsresurser för serverdelen. Den här metoden hjälper till att förbättra programmets prestanda och tillgänglighet och stöder horisontell skalning.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Checklista för designgranskning för tillförlitlighet.

  • Identifiera felpunkter: I den här DNS-arkitekturen med delad hjärna beror tillförlitligheten på att viktiga komponenter fungerar korrekt, till exempel Azure Front Door, Application Gateway och DNS-konfigurationer. Du måste identifiera potentiella felpunkter, till exempel felkonfigurationer, SSL-certifikatproblem eller kapacitetsöverbelastningar.

  • Utvärdera påverkan: Du måste utvärdera effekten av fel. För externa kunder kan eventuella störningar i Azure Front Door, som fungerar som en gateway, påverka den globala åtkomsten. För interna kunder kan eventuella avbrott i Application Gateway hindra företagsåtgärder.

  • Implementera åtgärdsstrategier: För att minska riskerna implementerar du redundans i flera tillgänglighetszoner, använder hälsoavsökningar för realtidsövervakning och säkerställer rätt konfiguration av DNS-routning för både extern och intern trafik. Se till att du regelbundet uppdaterar DNS-poster och har en haveriberedskapsplan.

  • Övervaka kontinuerligt: Använd Azure Monitor-funktioner för att hålla ett vaksamt öga på systemets hälsa. Konfigurera aviseringar för avvikelser och ha en plan för incidenthantering redo att snabbt åtgärda potentiella problem.

Följ dessa principer för att säkerställa ett robust och tillförlitligt system som kan stå emot utmaningar och upprätthålla tjänstkontinuitet.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Checklista för designgranskning för säkerhet.

  • Använd den Nolltillit metoden: Använd den Nolltillit metoden i DNS-konfigurationen med delad hjärna. Verifiera uttryckligen en kunds identitet, oavsett om de kommer från Internet eller ett företagsnätverk. Den här metoden säkerställer att endast betrodda entiteter utför auktoriserade åtgärder.

  • Implementering: Implementera Microsoft Entra-ID för robust identitetshantering. Använd principer för villkorsstyrd åtkomst i Microsoft Entra för att tillämpa strikta åtkomstkontroller baserat på kundkontext, enhetens hälsa och plats.

  • Utvärdera säkerhetseffektivitet: Utvärdera effektiviteten hos säkerhetsåtgärderna för din arbetsbelastning med dubbel åtkomst genom att implementera:

    • Defensiva investeringar: Utvärdera regelbundet effektiviteten i Azure Front Door och Application Gateway. Se till att de ger ett meningsfullt skydd mot hot.

    • Begränsning av sprängradie: Se till att du innehåller säkerhetsöverträdelser inom ett begränsat omfång. Isolera till exempel effektivt externa och interna trafikflöden.

  • Anta ett intrång: Bekräfta att angripare kan bryta mot säkerhetskontroller. Förbered för sådana scenarier.

  • Implementera säkerhetsåtgärder: Implementera nätverkssegmentering, mikrosegmentering och NSG:er. Anta att en angripare kan få åtkomst och utforma kompenserande kontroller i enlighet med detta.

Integrera dessa säkerhetsprinciper i din DNS-arkitektur med delad hjärna för att skapa ett robust och motståndskraftigt system som skyddar intern och extern åtkomst till din arbetsbelastning.

Andra säkerhetsförbättringar

  • Application Gateway: Du kan använda en WAF på Application Gateway för att skydda dina webbprogram från vanliga webbsårbarheter och sårbarheter. Du kan också använda Azure Private Link för att på ett säkert sätt komma åt dina serverdelsprogramservrar från Application Gateway utan att exponera dem för det offentliga Internet.

  • Azure Firewall: Du kan lägga till en Azure-brandvägg i det virtuella hubbnätverket och använda Hotinformation om Azure Firewall för att blockera skadlig trafik från kända skadliga IP-adresser och domäner. Du kan också använda Azure Firewall som EN DNS-proxy för att fånga upp och inspektera DNS-trafik och tillämpa DNS-filtreringsregler.

  • Azure Front Door: Du kan använda Azure Web Application Firewall för att skydda dina webbprogram mot vanliga webbsårbarheter och sårbarheter på gränsen. Du kan också använda Private Link med Azure Front Door Premium-nivån för att få säker åtkomst till serverdelsprogramservrarna från Azure Front Door utan att exponera dem för det offentliga Internet.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Checklista för designgranskning för kostnadsoptimering.

  • Serverdelsberäkning: Många faktorer, till exempel SKU-val, antal repliker och region, driver kostnaden för att köra serverdelsberäkningstjänster. Se till att du överväger alla element i en beräkningsresurs innan du väljer det bästa alternativet för din arbetsbelastning.

  • Application Gateway: Kostnaderna för Application Gateway beror på antalet instanser, instansernas storlek och mängden bearbetade data. Du kan optimera kostnaden med hjälp av autoskalning för att justera antalet instanser baserat på trafikefterfrågan. Du kan också distribuera zonredundanta SKU:er mellan tillgänglighetszoner för att minska behovet av ytterligare instanser för hög tillgänglighet.

  • Azure Front Door: Kostnaderna för Azure Front Door beror på antalet routningsregler, antalet HTTP- eller HTTPS-begäranden och mängden överförda data. Du kan använda Azure Front Door Standard-nivån eller Premium-nivån för att få en enhetlig upplevelse med Azure Content Delivery Network, Azure Web Application Firewall och Private Link. Du kan också använda funktionen Azure Front Door-regelmotor för att anpassa trafikhantering och optimera prestanda och kostnader.

    Om ditt scenario inte kräver global åtkomst eller de extra funktionerna i Azure Front Door kan du använda den här lösningen med endast Application Gateway. Du kan peka alla offentliga DNS-poster på den offentliga IP-adress som har konfigurerats på Application Gateway-lyssnarna.

Se ett exempel på den här lösningen som approximeras den typiska användningen av komponenterna i den här arkitekturen. Justera kostnaderna så att de passar ditt scenario.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

  • Troy Hite | Senior Cloud Solution Architect

Övriga medarbetare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg