Nollförtroendenätverk för webbprogram med Azure Firewall och Application Gateway

Den här guiden beskriver en strategi för att implementera noll förtroende för webbappar. Den här typen av säkerhetsmodell verifierar tillförlitligheten för nätverkspaket som flödar till program. En metod med flera lager fungerar bäst, där nätverkssäkerhet utgör ett lager. I det här lagret inspekterar nätverkstillämpningar paket för att säkerställa att endast legitim trafik når program.

Normalt inspekterar olika typer av nätverksutrustning olika aspekter av nätverkspaket:

• Brandväggar för webbaserade program letar efter mönster som indikerar en attack på webbprogramlagret.
• Nästa generations brandväggar kan också leta efter allmänna hot.

I vissa situationer kan du kombinera olika typer av nätverkssäkerhetsapparater för att öka skyddet. En separat guide, Firewall och Application Gateway för virtuella nätverk,beskriver designmönster som du kan använda för att ordna de olika apparaterna. Det här dokumentet fokuserar på ett vanligt mönster för att maximera säkerheten, där Azure Application Gateway agerar innan Azure Firewall Premium. Följande diagram illustrerar det här mönstret:

Den här arkitekturen använder SSL-protokollet (Secure Sockets Layer) för att kryptera trafiken i varje steg.

• En klient skickar paket till Application Gateway, en lastbalanserare. Den körs med det valfria tillägget Azure Web Application Firewall.

• Application Gateway dekrypterar paketen och söker efter hot mot webbprogram. Om den inte hittar några hot använder den noll förtroendeprinciper för att kryptera paketen. Sedan släpps de.

• Azure Firewall Premium kör säkerhetskontroller:

  • TLS-kontroll (Transport Layer Security) dekrypterar och undersöker paketen.
  • Intrångsidentifiering och skyddsfunktioner kontrollerar paketen för skadlig avsikt.

• Om paketen klarar testerna Azure Firewall Premium de här stegen:

  • Krypterar paketen
  • Använder en Domain Name System (DNS)-tjänst för att fastställa den virtuella programdatorn (VM)
  • Vidarebefordrar paketen till den virtuella programdatorn

Olika inspektionsmotorer i den här arkitekturen säkerställer trafikintegriteten:

• Web Application Firewall använder regler för att förhindra attacker på webblagret. Exempel på attacker är SQL kodinjektion och skriptning mellan webbplatser. Mer information om regler och Open Web Application Security Project (OWASP) Core Rule Set finns i Web Application Firewall CRS-regelgrupper och -regler.
• Azure Firewall Premium använder allmänna intrångsidentifierings- och skyddsregler. De här reglerna hjälper till att identifiera skadliga filer och andra hot som riktar sig mot webbprogram.

Den här arkitekturen stöder olika typer av nätverksdesign, som beskrivs i den här artikeln:

• Traditionella nav- och ekernätverk
• Nätverk som använder Azure Virtual WAN som plattform
• Nätverk som använder Azure Route Server för att förenkla dynamisk routning

Azure Firewall Premium och namnmatchning

När du söker efter skadlig trafik Azure Firewall Premium att HTTP-värdhuvudet matchar paketets IP-adress och TCP-port. Anta till exempel Application Gateway skickar webbpaket till IP-adressen 172.16.1.4 och TCP-port 443. Värdet för HTTP-värdhuvudet ska matchas mot den IP-adressen.

HTTP-värdhuvuden innehåller vanligtvis inte IP-adresser. I stället innehåller rubrikerna namn som matchar serverns digitala certifikat. I det här Azure Firewall Premium DNS för att matcha värdhuvudnamnet till en IP-adress. Nätverksdesignen avgör vilken DNS-lösning som fungerar bäst, enligt beskrivningen i senare avsnitt.

Digitala certifikat

I följande diagram visas de vanliga namn (CN) och certifikatutfärdare (CAs) som arkitekturens SSL-sessioner och certifikat använder:

SSL-anslutningar

Den här arkitekturen innehåller tre olika SSL-anslutningar. Digitala certifikat verifierar vart och ett:

Från klienter till Application Gateway

I Application Gateway distribuerar du det digitala certifikat som klienterna ser. En välkänd certifikatutfärdare som DigiCert eller Let's Encrypt utfärdar vanligtvis ett sådant certifikat.

Från Application Gateway till Azure Firewall Premium

Om du vill dekryptera och inspektera TLS-Azure Firewall Premium genererar certifikat dynamiskt. Azure Firewall Premium också presenterar sig Application Gateway som webbservern. En privat certifikatutfärdare signerar de certifikat Azure Firewall Premium genererar. Mer information finns i Azure Firewall Premium certifikat. Application Gateway måste verifiera dessa certifikat. I programmets HTTP-inställningar konfigurerar du den rotcertifikatutfärdare som Azure Firewall Premium använder.

Från Azure Firewall Premium till webbservern

Azure Firewall Premium upprättar en SSL-session med målwebbservern. Azure Firewall Premium verifierar att en välkänd certifikatutfärdare signerar webbserver-SSL-paketen.

Komponentroller

Application Gateway och Azure Firewall Premium hanterar certifikat på olika sätt eftersom deras roller skiljer sig åt:

• Application Gateway är en omvänd webbproxy. Den skyddar webbservrar från skadliga klienter genom att fånga upp HTTP- och HTTPS-begäranden. Du deklarerar varje skyddad server som finns i serverpoolen i Application Gateway med dess IP-adress eller fullständigt kvalificerade domännamn. Legitima klienter ska kunna komma åt varje program. Så du konfigurerar Application Gateway med ett digitalt certifikat som en offentlig certifikatutfärdare har signerat. Använd en certifikatutfärdare som alla SSL-klienter accepterar.
• Azure Firewall Premium är en webbproxy för vidarebefordran eller helt enkelt en webbproxy. Den skyddar klienter från skadliga webbservrar genom att fånga upp SSL-anrop från de skyddade klienterna. När en skyddad klient gör en HTTP-begäran personifierar den vidarebefordrande proxyn målwebbservern genom att generera digitala certifikat och presentera dem för klienten. Azure Firewall Premium använder en privat certifikatutfärdare som signerar de dynamiskt genererade certifikaten. Du konfigurerar de skyddade klienterna så att de litar på den privata certifikatutfärdaren. I den här Azure Firewall Premium skyddar Application Gateway till webbservern. Application Gateway den privata certifikatutfärdare som Azure Firewall Premium använder.

Exempel på nav och ekrar

Normalt distribuerar en hubb- och ekerdesign delade nätverkskomponenter i det virtuella navnätverket och programspecifika komponenter i ekrarna. I de flesta Azure Firewall Premium en delad resurs. Men Web Application Firewall kan vara en delad nätverksenhet eller en programspecifik komponent. Av följande skäl är det vanligtvis bäst att hantera Application Gateway en programkomponent och distribuera den i ett virtuellt ekernätverk:

• Det kan vara svårt att felsöka Web Application Firewall aviseringar. Du behöver vanligtvis djupgående kunskap om programmet för att avgöra om de meddelanden som utlöser dessa larm är legitima.
• Om du hanterar Application Gateway som en delad resurs kan du överskrida Azure Application Gateway gränserna.
• Problem med rollbaserad åtkomstkontroll kan uppstå om du distribuerar Application Gateway i hubben. Den här situationen kan uppdaga när team hanterar olika program men använder samma instans av Application Gateway. Varje team har sedan åtkomst till hela Application Gateway konfigurationen.

Med traditionella nav- och ekerarkitekturer är privata DNS-zoner ett enkelt sätt att använda DNS:

• Konfigurera en privat DNS-zon.
• Länka zonen till det virtuella nätverk som innehåller Azure Firewall Premium.
• Kontrollera att det finns en A-post för det värde Application Gateway använder för trafik och för hälsokontroller.

I följande diagram visas paketflödet när Application Gateway är i ett virtuellt ekernätverk. I det här fallet ansluter en klient från det offentliga Internet.

1. En klient skickar en begäran till en webbserver.
2. Application Gateway fångar upp klientpaketen och undersöker dem. Om paketen passerar inspektion vidarebefordrar en användardefinierad väg (UDR) Application Gateway undernätet paketen till Azure Firewall Premium.
3. Azure Firewall Premium kör säkerhetskontroller på paketen. Om de klarar testerna Azure Firewall Premium paketen till den virtuella programdatorn.
4. Den virtuella datorn svarar och anger mål-IP-adressen till Application Gateway. En UDR i Application Gateway-undernätet omdirigerar paketen till Azure Firewall Premium.
5. Azure Firewall Premium vidarebefordrar paketen till Application Gateway.
6. Application Gateway svarar klienten.

Trafik kan också tas emot från ett lokalt nätverk i stället för det offentliga Internet. Trafiken flödar antingen via ett virtuellt privat nätverk (VPN) från plats till plats eller via ExpressRoute. I det här scenariot når trafiken först en virtuell nätverksgateway i hubben. Resten av nätverksflödet är samma som i föregående fall.

1. En lokal klient ansluter till den virtuella nätverksgatewayen.
2. Gatewayen vidarebefordrar klientpaketen till Application Gateway.
3. Application Gateway undersöker paketen. Om de inspekteras vidarebefordrar en UDR Application Gateway undernätet paketen till Azure Firewall Premium.
4. Azure Firewall Premium kör säkerhetskontroller på paketen. Om de klarar testerna Azure Firewall Premium paketen till den virtuella programdatorn.
5. Den virtuella datorn svarar och anger mål-IP-adressen till Application Gateway. En UDR i Application Gateway-undernätet omdirigerar paketen till Azure Firewall Premium.
6. Azure Firewall Premium vidarebefordrar paketen till Application Gateway.
7. Application Gateway skickar paketen till den virtuella nätverksgatewayen.
8. Gatewayen svarar klienten.

Virtual WAN exempel

Du kan också använda nätverkstjänsttjänsten Virtual WAN den här arkitekturen. Den här komponenten har många fördelar. Det eliminerar till exempel behovet av användar underhållna användarbaserade UDR:er i virtuella ekernätverk. Du kan definiera statiska vägar i virtuella hubbruttertabeller i stället. Programmeringen för varje virtuellt nätverk som du ansluter till hubben innehåller sedan dessa vägar.

När du använder Virtual WAN som nätverksplattform leder det till två huvudsakliga skillnader:

• Du kan inte länka privata DNS-zoner till en virtuell hubb eftersom Microsoft hanterar virtuella hubbar. Som prenumerationsägare har du inte behörighet att länka privata DNS-zoner. Därför kan du inte associera en privat DNS-zon med den säkra hubben som innehåller Azure Firewall Premium. Om du vill implementera DNS-Azure Firewall Premium använder du DNS-servrar i stället:

  • Konfigurera dns-Azure Firewall att Inställningar använda anpassade DNS-servrar.
  • Distribuera servrarna i ett virtuellt nätverk med delade tjänster som du ansluter till det virtuella WAN-nätverket.
  • Länka en privat DNS-zon till det virtuella nätverket med delade tjänster. DNS-servrarna kan sedan matcha de namn Application Gateway använder i HTTP-värdhuvuden. Mer information finns i Azure Firewall DNS Inställningar.

• Du kan bara använda Virtual WAN för att programmera vägar i en eker om prefixet är kortare än prefixet för det virtuella nätverket. Den här begränsningen blir Application Gateway när målwebbservern finns i samma virtuella nätverk. I så fall Virtual WAN inte mata in en väg som åsidosätter systemvägen för det virtuella nätverket. Därför kringgår trafik mellan Application Gateway och webbservern Azure Firewall Premium.

Följande diagram visar paketflödet i ett fall som använder Virtual WAN. I den här situationen Application Gateway åtkomsten från ett lokalt nätverk. Ett plats-till-plats-VPN eller ExpressRoute ansluter nätverket till Virtual WAN. Åtkomsten från Internet är liknande.

1. En lokal klient ansluter till VPN.
2. VPN vidarebefordrar klientpaketen till Application Gateway.
3. Application Gateway undersöker paketen. Om de inspekteras vidarebefordrar Application Gateway undernätet paketen till Azure Firewall Premium.
4. Azure Firewall Premium begär DNS-upplösning från en DNS-server i det virtuella nätverket för delade tjänster.
5. DNS-servern svarar på begäran om lösning.
6. Azure Firewall Premium kör säkerhetskontroller på paketen. Om de klarar testerna Azure Firewall Premium paketen till den virtuella programdatorn.
7. Den virtuella datorn svarar och anger mål-IP-adressen till Application Gateway. Det Application Gateway undernätet omdirigerar paketen till Azure Firewall Premium.
8. Azure Firewall Premium vidarebefordrar paketen till Application Gateway.
9. Application Gateway skickar paketen till VPN-nätverket.
10. VPN-anslutningen svarar klienten.

Med den här designen kan du behöva ändra routningen som hubben annonserar till de virtuella ekernätverken. Mer specifikt Application Gateway v2 endast en 0.0.0.0/0-väg som pekar på Internet. Vägar med den här adressen som inte pekar på Internet bryter anslutningen som Microsoft kräver för att hantera Application Gateway. Om din virtuella hubb annonserar en 0.0.0.0/0-väg förhindrar du att vägen sprids till Application Gateway-undernätet genom att göra något av följande:

• Skapa en vägtabell med en väg för 0.0.0.0/0 och en nästa hopptyp av Internet . Associera den vägen med det undernät som du distribuerar Application Gateway in.
• Om du Application Gateway i en dedikerad eker inaktiverar du spridningen av standardvägen i inställningarna för den virtuella nätverksanslutningen.

Exempel på vägserver

Route Server erbjuder ett annat sätt att mata in vägar automatiskt i ekrar. Med den här funktionen undviker du det administrativa arbetet med att underhålla vägtabeller. Route Server kombinerar varianter Virtual WAN och nav och ekrar:

• Med Route Server hanterar kunderna virtuella hubbnätverk. Därför kan du länka det virtuella hubbnätverket till en privat DNS-zon.
• Route Server har samma begränsning som Virtual WAN ip-adressprefix. Du kan bara mata in vägar i en eker om prefixet är kortare än det virtuella nätverksprefixet. På grund av den här Application Gateway måste servern och målwebbservern finnas i olika virtuella nätverk.

Följande diagram visar paketflödet när Routningsserver förenklar dynamisk routning. Observera följande punkter:

• Route Server kräver för närvarande att enheten som matar in vägarna skickar dem via Border Gateway Protocol (BGP). Eftersom Azure Firewall Premium inte stöder BGP använder du en virtuell nätverksinstallation (NVA) från tredje part i stället.
• Nva-funktionen i hubben avgör om implementeringen behöver DNS.

1. En lokal klient ansluter till den virtuella nätverksgatewayen.
2. Gatewayen vidarebefordrar klientpaketen till Application Gateway.
3. Application Gateway undersöker paketen. Om de inspekteras vidarebefordrar Application Gateway-undernätet paketen till en NVA.
4. NVA begär DNS-upplösning från en DNS-server i det virtuella nätverket för delade tjänster.
5. DNS-servern svarar på begäran om lösning.
6. NVA kör säkerhetskontroller på paketen. Om de klarar testerna vidarebefordrar NVA paketen till den virtuella programdatorn.
7. Den virtuella datorn svarar och anger mål-IP-adressen till Application Gateway. Den Application Gateway undernätet omdirigerar paketen till nva.
8. NVA vidarebefordrar paketen till Application Gateway.
9. Application Gateway skickar paketen till den virtuella nätverksgatewayen.
10. Gatewayen svarar klienten.

Precis som Virtual WAN kan du behöva ändra routningen när du använder Routningsserver. Om du annonserar vägen 0.0.0.0/0 kan den spridas till Application Gateway undernätet. Men Application Gateway stöder inte den vägen. I det här fallet konfigurerar du en vägtabell för Application Gateway undernätet. Inkludera en väg för 0.0.0.0/0 och nästa hopptyp Internet i tabellen.

Nästa steg

• Säkra nätverk utan förtroende
• Trafikdirigering i virtuella nätverk
• Så här fungerar en programgateway

Relaterade resurser

• Skydda och styra arbetsbelastningar med segmentering på nätverksnivå
• Implementera ett säkert hybridnätverk
• Nätverkstopologi av typen hub-spoke i Azure
• Nätverkstopologi av hub-spoke-ekrar med Azure Virtual WAN