Brandvägg och Application Gateway för virtuella nätverk

För att skydda Azure-programarbetsbelastningar bör du använda skyddsåtgärder, till exempel autentisering och kryptering, i själva programmen. Du kan också lägga till säkerhetslager i de virtuella nätverk (VNet) som är värdar för programmen. Dessa säkerhetslager skyddar programmets inkommande flöden från oavsiktlig användning. De begränsar också utgående flöden till Internet till endast de slutpunkter som programmet kräver. Den här artikeln beskriver Azure Virtual Network-säkerhetstjänster som Azure DDoS Protection, Azure Firewall och Azure Application Gateway, när du ska använda varje tjänst och alternativ för nätverksdesign som kombinerar båda.

• Azure DDoS Protection, kombinerat med metodtips för programdesign, ger förbättrade DDoS-åtgärdsfunktioner för att ge mer skydd mot DDoS-attacker. Du bör aktivera Azure DDOS Protection i alla virtuella perimeternätverk.
• Azure Firewall är en hanterad nästa generations brandvägg som erbjuder NAT (Network Address Translation). Azure Firewall baserar paketfiltrering på IP-adresser (Internet Protocol) och TCP/UDP-portar (Transmission Control Protocol och User Datagram Protocol) eller på programbaserade HTTP(S) eller SQL-attribut. Azure Firewall tillämpar även Microsofts hotinformation för att identifiera skadliga IP-adresser. Mer information finns i dokumentationen om Azure Firewall.
• Azure Firewall Premium innehåller alla funktioner i Azure Firewall Standard och andra funktioner, till exempel TLS-inspektion och Intrångsidentifiering och skyddssystem (IDPS).
• Azure Application Gateway är en hanterad lastbalanserare för webbtrafik och HTTP(S) fullständig omvänd proxy som kan utföra SSL-kryptering (Secure Socket Layer) kryptering och dekryptering. Application Gateway bevarar den ursprungliga klientens IP-adress i en HTTP-rubrik för X-Forwarded-For. Application Gateway använder också brandväggen för webbprogram för att inspektera webbtrafik och identifiera attacker på HTTP-lagret. Mer information finns i Application Gateway-dokumentationen.
• Azure Web Application Firewall (WAF) är ett valfritt tillägg till Azure Application Gateway. Den tillhandahåller kontroll av HTTP-begäranden och förhindrar skadliga attacker på webblagret, till exempel SQL-inmatning eller skript för flera webbplatser. Mer information finns i dokumentationen om brandväggen för webbaserade program.

Dessa Azure-tjänster kompletterar varandra. Det ena eller det andra kan vara bäst för dina arbetsbelastningar, eller så kan du använda dem tillsammans för optimalt skydd i både nätverks- och programskikten. Använd följande beslutsträd och exemplen i den här artikeln för att fastställa det bästa säkerhetsalternativet för programmets virtuella nätverk.

Azure Firewall och Azure Application Gateway använder olika tekniker och de stöder värdepapperisering av olika flöden:

Beroende på vilka nätverksflöden ett program kräver kan designen skilja sig åt per program. Följande diagram innehåller ett förenklat beslutsträd som hjälper dig att välja den rekommenderade metoden för ett program. Beslutet beror på om programmet publiceras via HTTP(S) eller något annat protokoll:

Den här artikeln beskriver de ofta rekommenderade designerna från flödesdiagrammet och andra som är tillämpliga i mindre vanliga scenarier:

• Enbart Azure Firewall när det inte finns några webbprogram i det virtuella nätverket. Den styr både inkommande trafik till programmen och utgående trafik.
• Enbart Application Gateway, när endast webbprogram finns i det virtuella nätverket, och nätverkssäkerhetsgrupper (NSG:er) ger tillräcklig utdatafiltrering. Funktionerna i Azure Firewall kan förhindra många attackscenarier (till exempel dataexfiltrering, IDPS och så vidare). Av den anledningen rekommenderas normalt inte enbart Application Gateway-scenariot och dokumenteras därför inte och finns inte i flödesdiagrammet ovan.
• Azure Firewall och Application Gateway parallellt, vilket är en av de vanligaste designerna. Använd den här kombinationen när du vill att Azure Application Gateway ska skydda HTTP(S)-program från webbattacker och Azure Firewall för att skydda alla andra arbetsbelastningar och filtrera utgående trafik.
• Application Gateway framför Azure Firewall, när du vill att Azure Firewall ska inspektera all trafik, WAF för att skydda webbtrafik och programmet för att känna till klientens käll-IP-adress. Med Azure Firewall Premium- och TLS-inspektion stöder den här designen även SSL-scenariot från slutpunkt till slutpunkt.
• Azure Firewall framför Application Gateway när du vill att Azure Firewall ska inspektera och filtrera trafik innan den når Application Gateway. Eftersom Azure Firewall inte kommer att dekryptera HTTPS-trafik är funktionerna som läggs till i Application Gateway begränsade. Det här scenariot dokumenteras inte i flödesdiagrammet ovan.

I den sista delen av den här artikeln beskrivs variationer av de tidigare grundläggande designerna. Dessa varianter omfattar:

• Lokala programklienter.
• Nav- och ekernätverk.
• Azure Kubernetes Service-implementeringar (AKS).

Du kan lägga till andra omvända proxytjänster som en API Management-gateway eller Azure Front Door. Eller så kan du ersätta Azure-resurserna med virtuella nätverksinstallationer från tredje part.

Endast Azure Firewall

Om det inte finns några webbaserade arbetsbelastningar i det virtuella nätverket som kan dra nytta av WAF kan du endast använda Azure Firewall. Designen i det här fallet är enkel, men att granska paketflödet hjälper dig att förstå mer komplexa design. I den här designen skickas all inkommande trafik till Azure Firewall via användardefinierade vägar (UDR) för anslutningar från lokala eller andra virtuella Azure-nätverk. Den är adresserad till Azure Firewalls offentliga IP-adress för anslutningar från det offentliga Internet, som diagrammet nedan visar. Utgående trafik från virtuella Azure-nätverk skickas till brandväggen via UDR:er, som du ser i dialogrutan nedan.

I följande tabell sammanfattas trafikflödena för det här scenariot:

Azure Firewall inspekterar inte inkommande HTTP(S)-trafik. Men det kommer att kunna tillämpa layer 3 & layer 4-regler och FQDN-baserade programregler. Azure Firewall inspekterar utgående HTTP(S)-trafik beroende på Azure Firewall-nivån och om du konfigurerar TLS-inspektion:

• Azure Firewall Standard inspekterar endast layer 3- och layer 4-attributen för paketen i nätverksregler och VÄRD-HTTP-huvudet i programregler.
• Azure Firewall Premium lägger till funktioner som att inspektera andra HTTP-huvuden (till exempel användaragenten) och aktivera TLS-inspektion för djupare paketanalys. Azure Firewall motsvarar inte en brandvägg för webbprogram. Om du har webbarbetsbelastningar i ditt virtuella nätverk rekommenderas det starkt att använda WAF.

I följande exempel på paketvandring visas hur en klient får åtkomst till ett program som värdhanteras av en virtuell dator från det offentliga Internet. Diagrammet innehåller bara en virtuell dator för enkelhetens skull. För högre tillgänglighet och skalbarhet skulle du ha flera programinstanser bakom en lastbalanserare. I den här designen inspekterar Azure Firewall både inkommande anslutningar från det offentliga Internet och utgående anslutningar från den virtuella programundernätets virtuella dator med hjälp av UDR.

• Azure Firewall-tjänsten distribuerar flera instanser under täcket, här med klientdelens IP-adress 192.168.100.4 och interna adresser från intervallet 192.168.100.0/26. Dessa enskilda instanser är normalt osynliga för Azure-administratören. Men att märka skillnaden är användbart i vissa fall, till exempel när du felsöker nätverksproblem.
• Om trafiken kommer från ett lokalt virtuellt privat nätverk (VPN) eller En Azure ExpressRoute-gateway i stället för internet startar klienten anslutningen till den virtuella datorns IP-adress. Den startar inte anslutningen till brandväggens IP-adress och brandväggen gör ingen NAT-källa per standard.

Arkitektur

Följande diagram visar trafikflödet förutsatt att instansens IP-adress är 192.168.100.7.

Arbetsflöde

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Firewall:
   • Käll-IP-adress: ClientPIP
   • Mål-IP-adress: AzFwPIP
2. Begäran till den offentliga IP-adressen för Azure Firewall distribueras till en serverdelsinstans av brandväggen, i det här fallet 192.168.100.7. Dnat-regeln (Azure Firewall Destination NAT) översätter mål-IP-adressen till programmets IP-adress i det virtuella nätverket. Azure Firewall har även käll-NAT(SNAT) paketet om det gör DNAT. Mer information finns i Kända problem med Azure Firewall. Den virtuella datorn ser följande IP-adresser i det inkommande paketet:
   • Källans IP-adress: 192.168.100.7
   • Mål-IP-adress: 192.168.1.4
3. Den virtuella datorn svarar på programbegäran och återställer käll- och mål-IP-adresser. Det inkommande flödet kräver ingen användardefinierad väg (UDR) eftersom käll-IP-adressen är Azure Firewalls IP-adress. UDR i diagrammet för 0.0.0.0/0 är för utgående anslutningar för att se till att paket till det offentliga Internet går via Azure Firewall.
   • Källans IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.100.7
4. Slutligen ångrar Azure Firewall SNAT- och DNAT-åtgärderna och levererar svaret till klienten:
   • Källans IP-adress: AzFwPIP
   • Mål-IP-adress: ClientPIP

Endast Application Gateway

Den här designen beskriver situationen där det bara finns webbprogram i det virtuella nätverket, och att inspektera utgående trafik med NSG:er räcker för att skydda utgående flöden till Internet.

Den största skillnaden jämfört med den tidigare designen med endast Azure Firewall är att Application Gateway inte fungerar som en routningsenhet med NAT. Den fungerar som en fullständig omvänd programproxy. Application Gateway stoppar alltså webbsessionen från klienten och upprättar en separat session med en av dess serverdelsservrar. Inkommande HTTP(S)-anslutningar från Internet måste skickas till den offentliga IP-adressen för Application Gateway, anslutningar från Azure eller lokalt till gatewayens privata IP-adress. Returnera trafik från de virtuella Azure-datorerna följer standarddirigering av virtuella nätverk tillbaka till Application Gateway (se paketpromenaden längre ned för mer information). Utgående Internetflöden från virtuella Azure-datorer går direkt till Internet.

I följande tabell sammanfattas trafikflöden:

Arkitektur

Följande exempel på paketvandring visar hur en klient får åtkomst till det vm-värdbaserade programmet från det offentliga Internet.

Arbetsflöde

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Application Gateway:
   • Käll-IP-adress: ClientPIP
   • Mål-IP-adress: AppGwPIP
2. Begäran till den offentliga IP-adressen för Application Gateway distribueras till en serverdelsinstans av gatewayen, i det här fallet 192.168.200.7. Application Gateway-instansen som tar emot begäran stoppar anslutningen från klienten och upprättar en ny anslutning med en av serverdelarna. Serverdelen ser Application Gateway-instansen som källans IP-adress. Application Gateway infogar ett X-Forwarded-For HTTP-huvud med den ursprungliga klientens IP-adress.
   • Källans IP-adress: 192.168.200.7 (den privata IP-adressen för Application Gateway-instansen)
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-huvud: ClientPIP
3. Den virtuella datorn svarar på programbegäran och återställer käll- och mål-IP-adresser. Den virtuella datorn vet redan hur man når Application Gateway, så behöver ingen UDR.
   • Källans IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
4. Slutligen svarar Application Gateway-instansen på klienten:
   • Källans IP-adress: AppGwPIP
   • Mål-IP-adress: ClientPIP

Azure Application Gateway lägger till metadata i paketets HTTP-huvuden, till exempel rubriken X-Forwarded-For som innehåller den ursprungliga klientens IP-adress. Vissa programservrar behöver källklientens IP-adress för att hantera geoplatsspecifikt innehåll eller för loggning. Mer information finns i Så här fungerar en programgateway.

• IP-adressen 192.168.200.7 är en av de instanser som Azure Application Gateway-tjänsten distribuerar under täcket, här med den interna, privata IP-adressen för klientdelen 192.168.200.4. Dessa enskilda instanser är normalt osynliga för Azure-administratören. Men att märka skillnaden är användbart i vissa fall, till exempel när du felsöker nätverksproblem.

• Flödet liknar det om klienten kommer från ett lokalt nätverk via en VPN- eller ExpressRoute-gateway. Skillnaden är att klienten har åtkomst till den privata IP-adressen för Application Gateway i stället för den offentliga adressen.

Brandvägg och Application Gateway parallellt

På grund av dess enkelhet och flexibilitet är det ofta det bästa scenariot att köra Application Gateway och Azure Firewall parallellt.

Implementera den här designen om det finns en blandning av webb- och icke-webbarbetsbelastningar i det virtuella nätverket. Azure WAF i Azure Application Gateway skyddar inkommande trafik till webbarbetsbelastningarna och Azure Firewall inspekterar inkommande trafik för de andra programmen. Azure Firewall täcker utgående flöden från båda arbetsbelastningstyperna.

Inkommande HTTP(S)-anslutningar från Internet ska skickas till den offentliga IP-adressen för Application Gateway, HTTP(S) anslutningar från Azure eller lokalt till dess privata IP-adress. Standard-VNet-routning skickar paketen från Application Gateway till de virtuella måldatorerna samt från de virtuella måldatorerna tillbaka till Application Gateway (se paketpromenaden längre ned för mer information). För inkommande icke-HTTP(S)-anslutningar bör trafiken riktas mot den offentliga IP-adressen för Azure Firewall (om den kommer från det offentliga Internet), eller så skickas den via Azure Firewall av UDR (om den kommer från andra virtuella Azure-nätverk eller lokala nätverk). Alla utgående flöden från virtuella Azure-datorer vidarebefordras till Azure Firewall av UDR:er.

I följande tabell sammanfattas trafikflödena för det här scenariot:

Den här designen ger mycket mer detaljerad utgående filtrering än NSG:er. Om program till exempel behöver anslutning till ett specifikt Azure Storage-konto kan du använda fullständigt kvalificerade domännamnsbaserade filter (FQDN). Med FQDN-baserade filter skickar program inte data till oseriösa lagringskonton. Det scenariot kunde inte förhindras bara med hjälp av NSG:er. Den här designen används ofta där utgående trafik kräver FQDN-baserad filtrering. Ett exempel är när utgående trafik begränsas från ett Azure Kubernetes Services-kluster.

Arkitekturer

Följande diagram illustrerar trafikflödet för inkommande HTTP(S) anslutningar från en extern klient:

Följande diagram illustrerar trafikflödet för utgående anslutningar från de virtuella nätverksdatorerna till Internet. Ett exempel är att ansluta till serverdelssystem eller hämta operativsystemuppdateringar:

Paketflödesstegen för varje tjänst är desamma som i de tidigare fristående designalternativen.

Application Gateway före brandväggen

Den här designen förklaras mer detaljerat i Nätverket med noll förtroende för webbprogram med Azure Firewall och Application Gateway. Det här dokumentet fokuserar på jämförelsen med de andra designalternativen. I den här topologin går inkommande webbtrafik genom både Azure Firewall och WAF. WAF ger skydd på webbprogramlagret. Azure Firewall fungerar som en central loggnings- och kontrollpunkt och inspekterar trafiken mellan Application Gateway och serverdelsservrarna. Application Gateway och Azure Firewall sitter inte parallellt, utan en efter en.

Med Azure Firewall Premium kan den här designen stödja scenarier från slutpunkt till slutpunkt, där Azure Firewall tillämpar TLS-inspektion för att utföra IDPS på den krypterade trafiken mellan Application Gateway och webbserverdelen.

Den här designen är lämplig för program som behöver känna till inkommande IP-adresser för klientkällan, till exempel för att hantera geoplatsspecifikt innehåll eller för loggning. Application Gateway framför Azure Firewall samlar in det inkommande paketets käll-IP-adress i rubriken X-forwarded-for , så att webbservern kan se den ursprungliga IP-adressen i det här huvudet. Mer information finns i Så här fungerar en programgateway.

Inkommande HTTP(S) anslutningar från Internet måste skickas till den offentliga IP-adressen för Application Gateway, HTTP(S) anslutningar från Azure eller lokalt till den privata IP-adressen. Från Application Gateway-UDR:erna ser du till att paketen dirigeras via Azure Firewall (se paketet gå längre ned för mer information). För inkommande icke-HTTP(S)-anslutningar bör trafiken riktas mot den offentliga IP-adressen för Azure Firewall (om den kommer från det offentliga Internet), eller så skickas den via Azure Firewall av UDR (om den kommer från andra virtuella Azure-nätverk eller lokala nätverk). Alla utgående flöden från virtuella Azure-datorer vidarebefordras till Azure Firewall av UDR:er.

En viktig kommentar till den här designen är att Azure Firewall Premium ser trafik med en käll-IP-adress från Application Gateway-undernätet. Om det här undernätet har konfigurerats med en privat IP-adress (i 10.0.0.0/8, 192.168.0.0/16172.16.0.0/12 eller 100.64.0.0/10) behandlar Azure Firewall Premium trafik från Application Gateway som intern och tillämpar inte IDPS-regler för inkommande trafik. Du hittar mer information om Azure Firewall IDPS-regelriktningar och privata IP-prefix för IDPS i Azure Firewall IDPS-regler. Därför rekommenderar vi att du ändrar de privata IDPS-prefixen i Azure Firewall-principen så att Application Gateway-undernätet inte betraktas som en intern källa för att tillämpa inkommande och utgående IDPS-signaturer på trafiken.

I följande tabell sammanfattas trafikflödena för det här scenariot:

För webbtrafik från lokalt eller Internet till Azure kontrollerar Azure Firewall flöden som WAF redan har tillåtit. Beroende på om Application Gateway krypterar serverdelstrafik (trafik från Application Gateway till programservrarna) har du olika möjliga scenarier:

1. Application Gateway krypterar trafik efter nollförtroendeprinciper (TLS-kryptering från slutpunkt till slutpunkt) och Azure Firewall tar emot krypterad trafik. Azure Firewall Standard kommer dock att kunna tillämpa inspektionsregler, till exempel lager 3 och lager 4-filtrering i nätverksregler eller FQDN-filtrering i programregler med hjälp av SNI-huvudet (TLS Server Name Indication). Azure Firewall Premium ger djupare synlighet med TLS-inspektion, till exempel URL-baserad filtrering.
2. Om Application Gateway skickar okrypterad trafik till programservrarna ser Azure Firewall inkommande trafik i klartext. TLS-inspektion behövs inte i Azure Firewall.
3. Om IDPS är aktiverat i Azure Firewall kontrollerar den att HTTP-värdhuvudet matchar mål-IP-adressen. I det syftet behöver den namnmatchning för det FQDN som anges i värdrubriken. Den här namnmatchningen kan uppnås med privata Azure DNS-zoner och standardinställningarna för Azure Firewall DNS med hjälp av Azure DNS. Det kan också uppnås med anpassade DNS-servrar som måste konfigureras i Azure Firewall-inställningarna. (Mer information finns i Azure Firewall DNS-Inställningar.) Om det inte finns administrativ åtkomst till det virtuella nätverket där Azure Firewall distribueras är den senare metoden den enda möjligheten. Ett exempel är med Azure Firewalls distribuerade i Virtual WAN Secured Hubs.

Arkitektur

För resten av flödena (inkommande icke-HTTP(S)-trafik och eventuell utgående trafik tillhandahåller Azure Firewall IDPS-inspektion och TLS-inspektion där det är lämpligt. Det ger också FQDN-baserad filtrering i nätverksregler baserade på DNS.

Arbetsflöde

Nätverkstrafik från det offentliga Internet följer det här flödet:

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Application Gateway:
   • Käll-IP-adress: ClientPIP
   • Mål-IP-adress: AppGwPIP
2. Begäran till den offentliga IP-adressen för Application Gateway distribueras till en serverdelsinstans av gatewayen, i det här fallet 192.168.200.7. Application Gateway-instansen stoppar anslutningen från klienten och upprättar en ny anslutning med en av serverdelarna. UDR till 192.168.1.0/24 i Application Gateway-undernätet vidarebefordrar paketet till Azure Firewall, samtidigt som mål-IP-adressen bevaras till webbprogrammet:
   • Källans IP-adress: 192.168.200.7 (privat IP-adress för Application Gateway-instansen)
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-huvud: ClientPIP
3. Azure Firewall snatar inte trafiken eftersom trafiken går till en privat IP-adress. Den vidarebefordrar trafiken till den virtuella programdatorn om reglerna tillåter det. Mer information finns i Azure Firewall SNAT. Men om trafiken träffar en programregel i brandväggen ser arbetsbelastningen käll-IP-adressen för den specifika brandväggsinstansen som bearbetade paketet, eftersom Azure Firewall proxy för anslutningen:
   • Käll-IP-adress om trafiken tillåts av en Azure Firewall-nätverksregel: 192.168.200.7 (den privata IP-adressen för en av Application Gateway-instanserna).
   • Käll-IP-adress om trafiken tillåts av en Azure Firewall-programregel: 192.168.100.7 (den privata IP-adressen för en av Azure Firewall-instanserna).
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-huvud: ClientPIP
4. Den virtuella datorn svarar på begäran, återställer käll- och mål-IP-adresser. UDR för att 192.168.200.0/24 samla in paketet som skickas tillbaka till Application Gateway och omdirigerar det till Azure Firewall, samtidigt som mål-IP-adressen bevaras mot Application Gateway.
   • Källans IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
5. Här snatar inte Azure Firewall trafiken igen, eftersom den går till en privat IP-adress och vidarebefordrar trafiken till Application Gateway.
   • Källans IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
6. Slutligen svarar Application Gateway-instansen på klienten:
   • Källans IP-adress: AppGwPIP
   • Mål-IP-adress: ClientPIP

Utgående flöden från de virtuella datorerna till det offentliga Internet går via Azure Firewall, enligt definitionen i UDR till 0.0.0.0/0.

Application Gateway efter brandvägg

Med den här designen kan Azure Firewall filtrera och ignorera skadlig trafik innan den når Application Gateway. Den kan till exempel använda funktioner som hotinformationsbaserad filtrering. En annan fördel är att programmet får samma offentliga IP-adress för både inkommande och utgående trafik, oavsett protokoll. Men Azure Firewall SNATs inkommande trafik, så programmet kommer inte att ha insyn i den ursprungliga IP-adressen för HTTP-begäranden. Ur ett administrationsperspektiv, till exempel i felsökningssyfte, kan du hämta den faktiska klient-IP-adressen för en specifik anslutning genom att korrelera den med SNAT-loggarna i Azure Firewall.

Det finns begränsade fördelar i det här scenariot eftersom Azure Firewall endast ser krypterad trafik gå till Application Gateway. Det kan finnas scenarier där den här designen föredras. Ett fall är om en annan WAF är tidigare i nätverket (till exempel med Azure Front Door), som kan avbilda den ursprungliga käll-IP-adressen i X-Forwarded-For HTTP-huvudet. Eller designen är att föredra om många offentliga IP-adresser krävs.

INKOMMANDE HTTP-flöden från det offentliga Internet ska riktas mot den offentliga IP-adressen för Azure Firewall, och Azure Firewall dnat (och SNAT) paketen till application gatewayens privata IP-adress. Från andra virtuella Azure-nätverk eller lokala nätverk ska HTTP(S)-trafik skickas till Application Gateways privata IP-adress och vidarebefordras via Azure Firewall med UDR:er. Standard-VNet-routning ser till att returtrafiken från de virtuella Azure-datorerna går tillbaka till Application Gateway och från Application Gateway till Azure Firewall om DNAT-regler användes. För trafik från lokala eller Azure UDR:er i Application Gateway-undernätet bör du använda (se paketsteget längre ned för mer information). All utgående trafik från de virtuella Azure-datorerna till Internet skickas via Azure Firewall av UDR:er.

I följande tabell sammanfattas trafikflödena för det här scenariot:

För inkommande HTTP(S)-trafik dekrypterar Azure Firewall vanligtvis inte trafik. Det skulle i stället tillämpa IDPS-principer som inte kräver TLS-inspektion, till exempel IP-baserad filtrering eller användning av HTTP-huvuden.

Arkitektur

Programmet kan inte se den ursprungliga käll-IP-adressen för webbtrafiken. Azure Firewall SNATs paketen när de kommer in i det virtuella nätverket. Undvik det här problemet genom att använda Azure Front Door framför brandväggen. Azure Front Door matar in klientens IP-adress som en HTTP-rubrik innan den går in i det virtuella Azure-nätverket.

Arbetsflöde

Nätverkstrafik från det offentliga Internet följer det här flödet:

1. Klienten startar anslutningen till den offentliga IP-adressen för Azure Firewall:
   • Käll-IP-adress: ClientPIP
   • Mål-IP-adress: AzFWPIP
2. Begäran till den offentliga IP-adressen för Azure Firewall distribueras till en serverdelsinstans av brandväggen, i det här fallet 192.168.100.7. Azure Firewall DNATs webbporten, vanligtvis TCP 443, till den privata IP-adressen för Application Gateway-instansen. Azure Firewall även SNATs när du gör DNAT. Mer information finns i Kända problem med Azure Firewall:
   • Källans IP-adress: 192.168.100.7 (den privata IP-adressen för Azure Firewall-instansen)
   • Mål-IP-adress: 192.168.200.4
3. Application Gateway upprättar en ny session mellan den instans som hanterar anslutningen och en av serverdelsservrarna. Klientens ursprungliga IP-adress finns inte i paketet:
   • Källans IP-adress: 192.168.200.7 (den privata IP-adressen för Application Gateway-instansen)
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For-rubrik: 192.168.100.7
4. Den virtuella datorn svarar på Application Gateway och återställer käll- och mål-IP-adresser:
   • Källans IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7
5. Application Gateway svarar på SNAT-käll-IP-adressen för Azure Firewall-instansen. Även om anslutningen kommer från en specifik Application Gateway-instans som .7, ser Azure Firewall den interna IP-adressen för Application Gateway .4 som käll-IP:
   • Källans IP-adress: 192.168.200.4
   • Mål-IP-adress: 192.168.100.7
6. Slutligen ångrar Azure Firewall SNAT och DNAT och svarar klienten:
   • Källans IP-adress: AzFwPIP
   • Mål-IP-adress: ClientPIP

Även om Application Gateway inte har några lyssnare konfigurerade för program behöver den fortfarande en offentlig IP-adress så att Microsoft kan hantera den.

Lokala klienter

De föregående designerna visar alla programklienter som kommer från det offentliga Internet. Lokala nätverk har också åtkomst till program. De flesta av ovanstående informations- och trafikflöden är desamma som för Internetklienter, men det finns några anmärkningsvärda skillnader:

• En VPN-gateway eller ExpressRoute-gateway finns framför Azure Firewall eller Application Gateway.
• WAF använder den privata IP-adressen för Application Gateway.
• Azure Firewall stöder inte DNAT för privata IP-adresser. Därför måste du använda UDR för att skicka inkommande trafik till Azure Firewall från VPN- eller ExpressRoute-gatewayerna.
• Kontrollera varningar kring tvingad tunneltrafik för Azure Application Gateway och för Azure Firewall. Även om din arbetsbelastning inte behöver utgående anslutning till det offentliga Internet kan du inte mata in en standardväg som 0.0.0.0/0 för Application Gateway som pekar på det lokala nätverket, eller så bryter du kontrollen över trafiken. För Azure Application Gateway måste standardvägen peka på det offentliga Internet.

Arkitektur

Följande diagram visar den parallella designen för Azure Application Gateway och Azure Firewall. Programklienter kommer från ett lokalt nätverk som är anslutet till Azure via VPN eller ExpressRoute:

Även om alla klienter finns lokalt eller i Azure måste Både Azure Application Gateway och Azure Firewall ha offentliga IP-adresser. Med de offentliga IP-adresserna kan Microsoft hantera tjänsterna.

Topologi med nav och ekrar

Designerna i den här artikeln gäller fortfarande i en nav- och ekertopologi . Delade resurser i ett virtuellt nätverk med central hubb ansluter till program i separata virtuella ekernätverk via peerings för virtuella nätverk.

Arkitektur

Att tänka på

Några saker att tänka på för den här topologin är:

• Azure Firewall distribueras i det centrala virtuella hubbnätverket. Diagrammet ovan visar hur du distribuerar Application Gateway i hubben. Programteam hanterar ofta komponenter som Azure Application Gateways eller Azure API Management-gatewayer. I det här fallet distribueras dessa komponenter i de virtuella ekernätverken.
• Var särskilt uppmärksam på UDR:er i ekernätverken: När en programserver i en eker tar emot trafik från en specifik Azure Firewall-instans, som 192.168.100.7 adressen i föregående exempel, bör den skicka tillbaka returtrafiken till samma instans. Om en UDR i ekern anger nästa hopp av trafik adresserad till hubben till Azure Firewall IP-adressen (192.168.100.4 i diagrammen ovan) kan returpaket hamna på en annan Azure Firewall-instans, vilket orsakar asymmetrisk routning. Se till att om du har UDR:er i de virtuella ekernätverken för att skicka trafik till delade tjänster i hubben via Azure Firewall, inkluderar dessa UDR inte prefixet för Azure Firewall-undernätet.
• Den tidigare rekommendationen gäller även för Application Gateway-undernätet och andra virtuella nätverksinstallationer eller omvända proxyservrar som kan distribueras i det virtuella hubbnätverket.
• Du kan inte ange nästa hopp för Application Gateway- eller Azure Firewall-undernäten via statiska vägar med nästa hopptyp .Virtual Network Nästa hopptyp är endast giltig i det lokala virtuella nätverket och inte mellan VNet-peerings. Mer information om användardefinierade vägar och nästa hopptyper finns i Trafikdirigering för virtuellt nätverk.

Asymmetrisk dirigering

Diagrammet nedan visar hur en eker skickar tillbaka SNATted-trafik tillbaka till ALB för en Azure Firewall. Den här konfigurationen orsakar asymmetrisk routning:

Du kan lösa det här problemet genom att definiera UDR:er i ekern utan Azure Firewall-undernätet, men endast med de undernät där de delade tjänsterna finns. I exemplet ska rätt UDR i ekern endast innehålla 192.168.1.0/24. Den får inte innehålla hela 192.168.0.0/16, som markerat i rött.

Integrering med andra Azure-produkter

Du kan integrera Azure Firewall och Azure Application Gateway med andra Produkter och tjänster i Azure.

API Management Gateway

Integrera omvända proxytjänster som API Management-gateway i de tidigare designerna för att tillhandahålla funktioner som API-begränsning eller autentiseringsproxy. Integreringen av en API Management-gateway ändrar inte designen i någon större utsträckning. Den största skillnaden är att i stället för den enda omvända Application Gateway-proxyn finns det två omvända proxyservrar som är länkade bakom varandra.

Mer information finns i designguiden för att integrera API Management och Application Gateway i ett virtuellt nätverk och programmönstret API Gateways for Microservices.

Azure Kubernetes Service

För arbetsbelastningar som körs i ett AKS-kluster kan du distribuera Azure Application Gateway oberoende av klustret. Eller så kan du integrera det med AKS-klustret med ingresskontrollanten för Azure Application Gateway. När du konfigurerar vissa objekt på Kubernetes-nivåerna (till exempel tjänster och ingresser) anpassas Application Gateway automatiskt utan att du behöver några extra manuella steg.

Azure Firewall spelar en viktig roll i AKS-klustersäkerhet. Den erbjuder de funktioner som krävs för att filtrera utgående trafik från AKS-klustret baserat på FQDN, inte bara IP-adress. Mer information finns i Kontrollera utgående trafik för AKS-klusternoder.

När du kombinerar Application Gateway och Azure Firewall för att skydda ett AKS-kluster är det bäst att använda alternativet parallell design. Application Gateway med WAF bearbetar inkommande anslutningsbegäranden till webbprogram i klustret. Azure Firewall tillåter endast uttryckligen utgående anslutningar. Se Baslinjearkitektur för ett AKS-kluster (Azure Kubernetes Service) för ett exempel på alternativet parallell design.

Azure Front Door

Azure Front Door-funktioner överlappar delvis Azure Application Gateway. Båda tjänsterna erbjuder till exempel brandvägg för webbprogram, SSL-avlastning och URL-baserad routning. En stor skillnad är att Azure Front Door är en global, decentraliserad tjänst medan Azure Application Gateway finns i ett virtuellt nätverk.

Ibland kan du förenkla designen av virtuella nätverk genom att ersätta Application Gateway med en decentraliserad Azure Front Door. De flesta designerna som beskrivs här är giltiga, förutom alternativet att placera Azure Firewall framför Azure Front Door.

Ett intressant användningsfall är att använda Azure Firewall framför Application Gateway i ditt virtuella nätverk. Som tidigare X-Forwarded-For beskrivits innehåller huvudet som matas in av Application Gateway brandväggsinstansens IP-adress, inte klientens IP-adress. En lösning är att använda Azure Front Door framför brandväggen för att mata in klientens IP-adress som ett X-Forwarded-For huvud innan trafiken kommer in i det virtuella nätverket och träffar Azure Firewall. Ett annat alternativ är att skydda ditt ursprung med Private Link i Azure Front Door Premium.

Mer information om skillnaderna mellan de två tjänsterna eller när du ska använda var och en finns i Vanliga frågor och svar om Azure Front Door.

Andra virtuella nätverksinstallationer

Microsoft-produkter är inte det enda valet för att implementera brandväggen för webbprogram eller nästa generations brandväggsfunktioner i Azure. Ett brett utbud av Microsoft-partner tillhandahåller virtuella nätverksinstallationer (NVA). Begreppen och designerna är i stort sett desamma som i den här artikeln, men det finns några viktiga överväganden:

• Partner-NVA:er för nästa generations brandvägg kan ge mer kontroll och flexibilitet för NAT-konfigurationer som inte stöds av Azure Firewall. Exempel är DNAT från lokala enheter eller DNAT från Internet utan SNAT.
• Azure-hanterade NVA:er (som Application Gateway och Azure Firewall) minskar komplexiteten jämfört med NVA:er där användarna behöver hantera skalbarhet och återhämtning i många olika enheter.
• När du använder NVA:er i Azure använder du active-active - och autoskalningsinställningar , så att dessa enheter inte är en flaskhals för program som körs i det virtuella nätverket.

Deltagare

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

Huvudförfattare:

• Jose Moreno | Huvudkundtekniker

Nästa steg

Läs mer om komponentteknikerna:

• Vad är Azure Application Gateway?
• Vad är Azure Firewall?
• Vad är Azure Front Door?
• Azure Kubernetes Service
• Vad är Azure Virtual Network?
• Vad är Azure Web Application Firewall?

Relaterade resurser

Utforska relaterade arkitekturer:

• Implementera ett säkert hybridnätverk
• Säkert hanterade webbprogram
• Skydda din Microsoft Teams-kanalrobot och webbapp bakom en brandvägg
• Konsumenthälsoportalen i Azure
• Säkerhetsöverväganden för mycket känsliga IaaS-appar i Azure
• SaaS för flera klientorganisationer i Azure
• Företagsdistribution med App Services-miljö
• Företagsdistribution med hög tillgänglighet med App Services Environment
• Baslinjearkitektur för ett AKS-kluster (Azure Kubernetes Service)