Azure Firewall och Application Gateway för virtuella nätverk

För att skydda Azure-programarbetsbelastningar använder du skyddsåtgärder som autentisering och kryptering i själva programmen. Du kan lägga till säkerhetslager i de virtuella nätverk som är värdar för programmen. Dessa säkerhetslager hjälper till att skydda 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. I den här artikeln beskrivs Azure Virtual Network säkerhetstjänster som Azure DDoS Protection, Azure Firewall och Azure Application Gateway. Den beskriver också när du ska använda varje tjänst- och nätverksdesignalternativ som kombinerar dem.

• DDoS Protection, kombinerat med metodtips för programdesign, ger förbättrade DDoS-åtgärdsfunktioner som förbättrar skyddet mot DDoS-attacker. Du bör aktivera DDoS Protection i varje virtuellt perimeternätverk.

• Azure Firewall är en hanterad nästa generations brandvägg som tillhandahåller nat--funktioner (network address translation). Azure Firewall filtrerar paket baserat på IP-adresser och TCP-portar (Transmission Control Protocol) eller UDP-portar (User Datagram Protocol). Den kan filtrera trafik med hjälp av programbaserade attribut, till exempel HTTP(S) och SQL. Azure Firewall använder även Microsofts hotinformation för att identifiera skadliga IP-adresser. Mer information finns i Dokumentation om Azure Firewall.

• Azure Firewall Premium- innehåller alla funktioner i Azure Firewall Standard, utöver funktioner som TLS-inspektion (Transport Layer Security) och intrångsidentifiering och skyddssystem (IDPS).

• 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 ett X-Forwarded-For HTTP-huvud. Application Gateway använder också Azure Web Application Firewall för att inspektera webbtrafik och identifiera attacker på HTTP-lagret. Mer information finns i Application Gateway-dokumentation.

• Brandvägg för webbaserade program är ett valfritt tillägg till Application Gateway. Den inspekterar HTTP-begäranden och förhindrar attacker på webblager, till exempel SQL-inmatning och skript mellan webbplatser. Mer information finns i dokumentationen Web Application Firewall.

Dessa Azure-tjänster kompletterar varandra. Beroende på dina behov kan användning av en tjänst passa dina arbetsbelastningar bättre. Du kan dock använda dessa tjänster tillsammans för att ge 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 välja det bästa säkerhetsalternativet för programmets virtuella nätverk.

Azure Firewall och Application Gateway använder olika tekniker för att skydda olika typer av dataflöden.

Designen kan variera för varje program baserat på de nätverksflöden som krävs. Följande diagram innehåller ett förenklat beslutsträd som hjälper dig att välja den rekommenderade metoden för ditt program. Det här valet beror på om programmet publiceras via HTTP(S) eller något annat protokoll.

Den här artikeln beskriver de ofta rekommenderade designerna som visas i flödesdiagrammet och designerna som lämpar sig för mindre vanliga scenarier:

• Endast Azure Firewall: Använd den här designen 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.

• Application Gateway endast: Använd den här designen när endast webbprogram finns i det virtuella nätverket och nätverkssäkerhetsgrupper (NSG:er) tillhandahålla tillräcklig utdatafiltrering. Azure Firewall innehåller funktioner som kan hjälpa till att förhindra flera attackscenarier, till exempel dataexfiltrering och IDPS. Därför rekommenderas inte designen endast för Application Gateway vanligtvis, så den ingår inte i det tidigare flödesdiagrammet.

• Azure Firewall och Application Gateway parallellt: Använd den här designen när du vill att 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. Azure Firewall och Application Gateway parallellt är en vanlig design.

• Application Gateway framför Azure Firewall: Använd den här designen när du vill att Azure Firewall ska inspektera all trafik, Brandvägg för webbprogram för att skydda webbtrafik och programmet för att identifiera 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: Använd den här designen när du vill att Azure Firewall ska inspektera och filtrera trafik innan den når Application Gateway. Eftersom Azure Firewall inte dekrypterar HTTPS-trafik är dess tillagda funktioner i Application Gateway begränsade. Det här scenariot dokumenteras inte i föregående flödesdiagram.

Varianter av dessa grundläggande design beskrivs senare i den här artikeln och omfattar:

• lokala programklienter.
• Hub-and-spoke-nätverk.
• Azure Kubernetes Service (AKS) implementeringar.

Du kan lägga till andra omvända proxytjänster, till exempel en Azure API Management- gateway eller Azure Front Door-. Eller så kan du ersätta Azure-resurserna med virtuella nätverksinstallationer (NVA) som inte är microsoft (NVA).

Design endast för Azure Firewall

Om det inte finns några webbaserade arbetsbelastningar i det virtuella nätverket som kan dra nytta av brandväggen för webbaserade program kan du använda azure firewall-designen. Designen i det här exemplet är enkel, men du kan granska paketflödet för att bättre 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 den offentliga IP-adressen för Azure Firewall för anslutningar från det offentliga Internet, enligt följande diagram. UDR:er dirigerar utgående trafik från virtuella Azure-nätverk till Azure Firewall, som du ser i följande dialogruta.

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

Azure Firewall inspekterar inte inkommande HTTP(S)-trafik. Men den kan tillämpa layer 3- och layer 4-regler och fullständigt kvalificerade domännamn (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-attribut för paket i nätverksregler och VÄRD-HTTP-huvudet i programregler.

• Azure Firewall Premium lägger till funktioner, till exempel att inspektera andra HTTP-huvuden (t.ex. användaragenten) och aktivera TLS-inspektion för djupare paketanalys. Azure Firewall är dock inte detsamma som brandväggen för webbprogram. Om du har webbarbetsbelastningar i det virtuella nätverket rekommenderar vi att du använder Brandvägg för webbprogram.

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 finns det flera programinstanser bakom en lastbalanserare. I den här designen inspekterar Azure Firewall inkommande anslutningar från det offentliga Internet och utgående anslutningar från den virtuella datorn för programundernätet med hjälp av UDR.

• I det här exemplet distribuerar Azure Firewall automatiskt flera instanser med klientdelens IP-adress 192.168.100.4 och interna adresser inom intervallet 192.168.100.0/26. Normalt sett är dessa instanser inte synliga för Azure-administratören. Men att vara medveten om dem kan vara till hjälp för att felsöka nätverksproblem.

• Om trafiken kommer från ett lokalt virtuellt privat nätverk (VPN) eller 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 inte käll-NAT som standard.

Arkitektur

Följande diagram visar trafikflödet och förutsätter 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ällans 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, vilket är 192.168.100.7 i det här exemplet. Azure Firewall DNAT-regel (Destination Network Address Translation) översätter mål-IP-adressen till programmets IP-adress i det virtuella nätverket. Azure Firewall implementerar även källnätverksadressöversättning (SNAT) på paketet om det använder 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, som vänder både käll- och mål-IP-adresserna. Det inkommande flödet kräver ingen UDR eftersom käll-IP-adressen är Ip-adressen för Azure Firewall. UDR i diagrammet för 0.0.0.0/0 är för utgående anslutningar för att säkerställa 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. Azure Firewall ångrar SNAT- och DNAT-åtgärderna och levererar svaret till klienten.

   • Källans IP-adress: AzFwPIP
   • Mål-IP-adress: ClientPIP

Design endast för Application Gateway

Den här designen beskriver scenariot 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 för endast Azure Firewall är att Application Gateway inte fungerar som en routningsenhet med NAT. I stället fungerar den som en fullständig omvänd programproxy. Den här metoden innebär att Application Gateway stoppar webbsessionen från klienten och upprättar en separat session med en av dess serverdelsservrar. Inkommande HTTP(S)-anslutningar från Internet skickas till den offentliga IP-adressen för Application Gateway och anslutningar från Azure eller lokalt använder gatewayens privata IP-adress. Returnera trafik från de virtuella Azure-datorerna följer standarddirigeringen av virtuella nätverk tillbaka till Application Gateway. Mer information finns i paketpromenaden senare i den här artikeln. 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 Application Gateway.

   • Källans 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, vilket är 192.168.200.7 i det här exemplet. 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äll-IP-adress, som är den privata IP-adressen för Application Gateway-instansen: 192.168.200.7
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For rubrik: ClientPIP

3. Den virtuella datorn svarar på programbegäran och återställer både käll- och mål-IP-adresserna. Den virtuella datorn kan nå Application Gateway, så den behöver ingen UDR.

   • Källans IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7

4. Application Gateway-instansen svarar klienten.

   • Källans IP-adress: AppGwPIP
   • Mål-IP-adress: ClientPIP

Application Gateway lägger till metadata i paketets HTTP-huvuden, till exempel det X-Forwarded-For huvudet 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 Hur en programgateway fungerar.

• I det här exemplet är IP-adressen 192.168.200.7 en av de instanser som distribueras av Application Gateway-tjänsten automatiskt. Den har 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 kan vara användbart, 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 IP-adressen.

Azure Firewall och Application Gateway i parallell design

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

Implementera den här designen om det finns både webb- och icke-webbarbetsbelastningar i det virtuella nätverket. Brandväggen för webbprogram i Application Gateway hjälper till att skydda inkommande trafik till webbarbetsbelastningarna. Azure Firewall inspekterar inkommande trafik för de andra programmen. Azure Firewall omfattar 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-anslutningar från Azure eller lokalt ska skickas till dess privata IP-adress. Standarddirigering av virtuella nätverk skickar paketen från Application Gateway till de virtuella måldatorerna och från de virtuella måldatorerna tillbaka till Application Gateway. Mer information finns i paketpromenaden senare i den här artikeln.

För inkommande icke-HTTP(S)-anslutningar bör trafiken rikta in sig på den offentliga IP-adressen för Azure Firewall om den kommer från det offentliga Internet. Trafik ska skickas via Azure Firewall av UDR:er 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 att bara använda NSG:er. Om program till exempel behöver anslutning till ett specifikt Azure Storage-konto kan du använda FQDN-baserade filter. Med FQDN-baserade filter skickar program inte data till oseriösa lagringskonton. Om du bara använder NSG:er kan du inte förhindra det här scenariot. Den här designen används ofta när utgående trafik kräver FQDN-baserad filtrering. Ett scenario är när du begränsa utgående trafik från ett AKS-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 framför Azure Firewall-design

Den här designen beskrivs mer detaljerat i Nollförtroendenätverk för webbprogram med Azure Firewall och Application Gateway. Den här artikeln fokuserar på jämförelsen med de andra designalternativen. I den här topologin går inkommande webbtrafik genom både Azure Firewall och Web Application Firewall. Brandväggen för webbaserade program ger skydd på webbprogramlagret. Azure Firewall fungerar som en central loggnings- och kontrollpunkt och inspekterar trafiken mellan Application Gateway och serverdelsservrarna. I den här designen sitter Inte Application Gateway och Azure Firewall parallellt utan sitter en framför den andra.

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 passar för program som behöver identifiera inkommande IP-adresser för klientkällan. Det kan till exempel användas för att hantera geoplatsspecifikt innehåll eller för loggning. Application Gateway framför Azure Firewall-designen samlar in det inkommande paketets käll-IP-adress i X-Forwarded-For-huvudet, så att webbservern kan se den ursprungliga IP-adressen i det här huvudet. Mer information finns i Hur en programgateway fungerar.

Inkommande HTTP(S)-anslutningar från Internet måste skickas till den offentliga IP-adressen för Application Gateway. HTTP-anslutningar från Azure eller lokalt ska skickas till dess privata IP-adress. Från Application Gateway ser UDR:er till att paketen dirigeras via Azure Firewall. Mer information finns i paketpromenaden senare i den här artikeln.

För inkommande icke-HTTP(S)-anslutningar bör trafiken rikta in sig på den offentliga IP-adressen för Azure Firewall om den kommer från det offentliga Internet. Trafik ska skickas via Azure Firewall av UDR:er 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 aspekt av 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/16, 172.16.0.0/12eller 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. Därför rekommenderar vi att du ändrar de privata IDPS-prefixen i Azure Firewall-principen. Den här ändringen säkerställer att Application Gateway-undernätet inte betraktas som en intern källa, vilket gör att inkommande och utgående IDPS-signaturer kan tillämpas på trafiken. Du hittar mer information om Azure Firewall IDPS-regelriktningar och privata IP-prefix för IDPS i Azure Firewall IDPS-regler.

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

För webbtrafik från lokalt eller från Internet till Azure inspekterar Azure Firewall flöden som brandväggen för webbaserade program tillåter. Beroende på om Application Gateway krypterar serverdelstrafik, vilket är trafik från Application Gateway till programservrarna, kan olika scenarier inträffa:

• Application Gateway krypterar trafiken genom att följa nollförtroendeprinciper som TLS-kryptering från slutpunkt till slutpunktoch Azure Firewall tar emot krypterad trafik. Azure Firewall Standard kan fortfarande 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.

• Om Application Gateway skickar okrypterad trafik till programservrarna ser Azure Firewall inkommande trafik i klartext. TLS-inspektion behövs inte i Azure Firewall.

• Om IDPS är aktiverat i Azure Firewall verifierar det att HTTP-värdhuvudet matchar mål-IP-adressen. För att utföra den här verifieringen behöver den namnmatchning för det FQDN som anges i värdhuvudet. Den här namnmatchningen kan utföras med hjälp av privata Azure DNS-zoner och standardinställningarna för Azure Firewall DNS. Det kan också uppnås med anpassade DNS-servrar som måste konfigureras i Azure Firewall-inställningarna. Om du inte har administrativ åtkomst till det virtuella nätverk där Azure Firewall distribueras är den senare metoden det enda alternativet. Ett exempel är azure firewall-instanser som distribueras i Azure Virtual WAN-skyddade hubbar.

Arkitektur

För resten av flödena, som omfattar 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 baserat 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 Application Gateway.

   • Källans 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, vilket är 192.168.200.7 i det här exemplet. Application Gateway-instansen stoppar anslutningen från klienten och upprättar en ny anslutning med en av serverdelarna. DEN UDR som ska 192.168.1.0/24 i Application Gateway-undernätet vidarebefordrar paketet till Azure Firewall och bevarar mål-IP-adressen till webbprogrammet.

   • Käll-IP-adress, som är den privata IP-adressen för Application Gateway-instansen: 192.168.200.7
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For rubrik: ClientPIP

3. Azure Firewall tillämpar inte SNAT på 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 avsnittet om Azure Firewall och SNAT med privata IP-adressintervall. 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 proxyservrar anslutningen.

   • Käll-IP-adress om trafiken tillåts av en Azure Firewall-nätverksregel och är den privata IP-adressen för en av Application Gateway-instanserna: 192.168.200.7
   • Käll-IP-adress om trafiken tillåts av en Azure Firewall-programregel och är den privata IP-adressen för en av Azure Firewall-instanserna: 192.168.100.7
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For rubrik: ClientPIP

4. Den virtuella datorn svarar på begäran, som återställer både käll- och mål-IP-adresserna. UDR för att 192.168.200.0/24 samlar in paketet som skickas tillbaka till Application Gateway, omdirigerar det till Azure Firewall och bevarar mål-IP-adressen mot Application Gateway.

   • Källans IP-adress: 192.168.1.4
   • Mål-IP-adress: 192.168.200.7

5. Återigen tillämpar Inte Azure Firewall SNAT på trafiken 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. Application Gateway-instansen svarar 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, som UDR till 0.0.0.0/0 definierar.

Som en variant av den här designen kan du konfigurera privat DNAT i Azure Firewall så att programarbetsbelastningen ser IP-adresserna för Azure Firewall-instanserna som källa, och inga UDR krävs. Programklienternas käll-IP-adress bevaras redan i X-Forwarded-For HTTP-huvudet av Application Gateway. Så om Azure Firewall tillämpar DNAT på trafiken går ingen information förlorad. Mer information finns i Filtrera inkommande Internet- eller intranättrafik med Azure Firewall-princip-DNAT med hjälp av Azure-portalen.

Azure Firewall framför Application Gateway-design

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. Det finns tre lägen där du teoretiskt kan konfigurera Azure Firewall:

• Azure Firewall med DNAT-regler: Azure Firewall byter bara IP-adresser på IP-adresslagret, men den bearbetar inte nyttolasten. Det innebär att det inte ändrar något av HTTP-huvudena.

• Azure Firewall med programregler och TLS-inspektion inaktiverad: Azure Firewall kan titta på SNI-huvudet i TLS, men det dekrypterar det inte. En ny TCP-anslutning skapas från brandväggen till nästa hopp. I det här exemplet är det Application Gateway.

• Azure Firewall med programregler och TLS-inspektion aktiverat: Azure Firewall tittar på paketinnehållet och dekrypterar dem. Den fungerar som en HTTP-proxy och kan ange HTTP-huvuden X-Forwarded-For för att bevara IP-adressen. Det visar dock ett självgenererat certifikat för klienten. För internetbaserade program är det inte ett alternativ att använda ett självgenererat certifikat eftersom en säkerhetsvarning skickas till programklienterna från deras webbläsare.

I de två första alternativen, som är de enda giltiga alternativen för Internetbaserade program, tillämpar Azure Firewall SNAT på inkommande trafik utan att ange X-Forwarded-For-huvudet. Därför kan programmet inte se den ursprungliga IP-adressen för HTTP-begäranden. För administrativa uppgifter, till exempel felsökning, kan du hämta den faktiska klientens IP-adress för en specifik anslutning genom att korrelera den med SNAT-loggarna i Azure Firewall.

Fördelarna med det här scenariot är begränsade eftersom Azure Firewall endast ser krypterad trafik som går till Application Gateway om du inte använder TLS-inspektion och presenterar självgenererade certifikat för klienterna. Det här scenariot är vanligtvis bara möjligt för interna program. Det kan dock finnas scenarier där den här designen föredras. Ett scenario är om det finns en annan brandvägg för webbprogram tidigare i nätverket (till exempel med Azure Front Door), som kan avbilda den ursprungliga käll-IP-adressen i X-Forwarded-For HTTP-huvud. Du kanske också föredrar den här designen om många offentliga IP-adresser krävs eftersom Application Gateway stöder en enda IP-adress.

HTTP(S) inkommande flöden från det offentliga Internet bör rikta in sig på den offentliga IP-adressen för Azure Firewall. Azure Firewall dnat och SNAT paketen till den privata IP-adressen för Application Gateway. Från andra virtuella Azure-nätverk eller lokala nätverk ska HTTP(S)-trafik skickas till den privata IP-adressen för Application Gateway och vidarebefordras via Azure Firewall med UDR. Standarddirigering av virtuella nätverk säkerställer att returtrafik 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 lokal plats eller Azure använder du UDR:er i Application Gateway-undernätet. Mer information finns i paketpromenaden senare i den här artikeln. 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. I stället tillämpas IDPS-principer som inte kräver TLS-inspektion, till exempel IP-adressbaserad filtrering eller http-huvuden.

Arkitektur

Programmet kan inte se den ursprungliga käll-IP-adressen för webbtrafiken. Azure Firewall tillämpar SNAT på 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ällans 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, vilket är 192.168.100.7 i det här exemplet. Azure Firewall tillämpar DNAT på webbporten, vanligtvis TCP 443, på den privata IP-adressen för Application Gateway-instansen. Azure Firewall tillämpar även SNAT när du utför DNAT. Mer information finns i kända problem med Azure Firewall.

   • Källans IP-adress, som är den privata IP-adressen för Azure Firewall-instansen: 192.168.100.7
   • Mål-IP-adress: 192.168.200.4

3. Application Gateway upprättar en ny session mellan instansen som hanterar anslutningen och en av serverdelsservrarna. Klientens ursprungliga IP-adress finns inte i paketet.

   • Käll-IP-adress, som är den privata IP-adressen för Application Gateway-instansen: 192.168.200.7
   • Mål-IP-adress: 192.168.1.4
   • X-Forwarded-For rubrik: 192.168.100.7

4. Den virtuella datorn svarar på Application Gateway, som vänder både käll- och mål-IP-adresserna:

   • 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. Azure Firewall ser den interna IP-adressen för Application Gateway, .4, som källans IP-adress, även om anslutningen kommer från en specifik Application Gateway-instans som .7.

   • Källans IP-adress: 192.168.200.4
   • Mål-IP-adress: 192.168.100.7

6. Azure Firewall ångrar SNAT och DNAT och svarar klienten.

   • Källans IP-adress: AzFwPIP
   • Mål-IP-adress: ClientPIP

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

Lokala klienter

De föregående designerna visar alla inkommande programklienter från det offentliga Internet. Lokala nätverk har också åtkomst till program. De flesta tidigare 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.

• Brandväggen för webbaserade program använder den privata IP-adressen för Application Gateway.

• Azure Firewall stöder inte DNAT för privata IP-adresser, så du måste 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 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 eftersom den bryter kontrolltrafiken. För Application Gateway måste standardvägen peka på det offentliga Internet.

Arkitektur

Följande diagram visar parallell design för 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 Application Gateway och Azure Firewall ha offentliga IP-adresser. Med dessa offentliga IP-adresser kan Microsoft hantera tjänsterna.

Topologi för nav och eker

Designerna i den här artikeln gäller för en hub-and-spoke- topologi. 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

Överväganden

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

• Azure Firewall distribueras i det centrala virtuella hubbnätverket. Föregående diagram visar hur du distribuerar Application Gateway i hubben. Programteam hanterar ofta komponenter som Application Gateways eller API Management-gatewayer. I det här scenariot distribueras dessa komponenter i de virtuella ekernätverken.

• Var särskilt uppmärksam på UDR i ekernätverken. När en programserver i en eker tar emot trafik från en specifik Azure Firewall-instans, som den 192.168.100.7 IP-adressen i föregående exempel, bör den skicka tillbaka trafiken till samma instans. Om en UDR i ekern anger nästa hopp av trafik som är adresserad till hubben till Azure Firewall IP-adressen (192.168.100.4 i föregående diagram) kan returpaket hamna på en annan Azure Firewall-instans. Den här situationen orsakar asymmetrisk routning. Om du har UDR:er i de virtuella ekernätverken ska du skicka trafik till delade tjänster i hubben via Azure Firewall. Dessa UDF:er innehåller inte prefixet för Azure Firewall-undernätet.

• Den tidigare rekommendationen gäller även för Application Gateway-undernätet och andra NVA:er 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ät 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 peerings för virtuella nätverk. Mer information om UDR:er och nästa hopptyper finns i Trafikdirigering för virtuella nätverk.

Asymmetrisk routning

Följande diagram visar hur en eker skickar SNAT-trafik tillbaka till Azure-lastbalanseraren i Azure Firewall. Den här konfigurationen orsakar asymmetrisk routning.

Lös problemet genom att definiera UDR:er i ekern utan Azure Firewall-undernätet och endast med de undernät där de delade tjänsterna finns. I föregående diagram ska rätt UDR i ekern endast innehålla 192.168.1.0/24. Det får inte innehålla hela intervallet 192.168.0.0/16, som är markerat i rött.

Integrering med andra Azure-produkter

Du kan integrera Azure Firewall och 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 API Management-gatewayen påverkar inte designerna nämnvärt. Den viktigaste 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 för att integrera API Management och Application Gateway i ett virtuellt nätverk och programmönstret API-gatewayer för mikrotjänster.

AKS

För arbetsbelastningar som körs i ett AKS-kluster kan du distribuera Application Gateway oberoende av klustret. Eller så kan du integrera det med AKS-klustret med hjälp av Application Gateway-ingresskontrollanten. När du konfigurerar specifika 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 tillhandahåller de funktioner som krävs för att filtrera utgående trafik från AKS-klustret baserat på FQDN, inte bara IP-adressen. Mer information finns i Begränsa nätverkstrafik med Azure Firewall i AKS.

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 Web Application Firewall bearbetar inkommande anslutningsbegäranden till webbprogram i klustret. Azure Firewall tillåter endast uttryckligen utgående anslutningar. Mer information om alternativet parallell design finns i Originalplansarkitektur för ett AKS-kluster.

Azure Front Door

Azure Front Door har funktioner som överlappar Application Gateway på flera områden. Båda tjänsterna tillhandahåller brandvägg för webbprogram, SSL-avlastning och URL-baserad routning. En viktig skillnad är dock att Även om Application Gateway fungerar i ett virtuellt nätverk är Azure Front Door en global, decentraliserad tjänst.

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 i den här artikeln gäller fortfarande, förutom alternativet att placera Azure Firewall framför Azure Front Door.

Ett scenario är att använda Azure Firewall framför Application Gateway i ditt virtuella nätverk. Application Gateway matar in X-Forwarded-For-huvudet med 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 når Azure Firewall. Du kan också skydda ditt ursprung med Azure 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 NVA:er

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 NVA:er. 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 Azure Firewall inte stöder. 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 aktiv-aktiv och automatisk skalning installationer så att dessa enheter inte är en flaskhals för program som körs i det virtuella nätverket.

Bidragsgivare

Microsoft ansvarar för denna artikel. Följande deltagare skrev den här artikeln.

Huvudförfattare:

• Jose Moreno | Huvudkundtekniker

Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.

Nästa steg

Läs mer om komponentteknikerna:

• Vad är Application Gateway?
• Vad är Azure Firewall?
• Vad är Azure Front Door?
• AKS
• Vad är virtuellt nätverk?
• Vad är brandvägg för webbprogram?
• Baslinjearkitektur för ett AKS-kluster

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
• programvara för flera klientorganisationer som en tjänst i Azure
• Enterprise-distribution med hjälp av App Service Environment
• Företagsdistribution med hög tillgänglighet med hjälp av App Service Environment