Nätverk med noll förtroende för webbprogram med Azure Firewall och Application Gateway

Den här guiden beskriver en strategi för att implementera säkerhet utan förtroende för webbappar för inspektion och kryptering. Paradigmet noll förtroende innehåller många andra begrepp, till exempel konstant verifiering av aktörernas identitet eller att minska storleken på implicita förtroendeområden till ett minimum. Den här artikeln refererar till krypterings- och inspektionskomponenten i en nollförtroendearkitektur för inkommande trafik från det offentliga Internet. Läs andra dokument med noll förtroende för fler aspekter av att distribuera programmet på ett säkert sätt, till exempel autentisering. I den här artikeln fungerar en metod med flera lager bäst, där nätverkssäkerhet utgör ett av lagren i nollförtroendemodellen. I det här lagret inspekterar nätverksinstallationer paket för att säkerställa att endast legitim trafik når program.

Vanligtvis inspekterar olika typer av nätverksinstallationer olika aspekter av nätverkspaket:

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

I vissa situationer kan du kombinera olika typer av nätverkssäkerhetsenheter för att öka skyddet. En separat guide, Brandvägg 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 före Azure Firewall Premium. Följande diagram illustrerar det här mönstret:

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

Den här arkitekturen använder TLS-protokollet (Transport Layer Security) för att kryptera trafiken i varje steg.

• En klient skickar paket till Application Gateway, en lastbalanserare. Den körs med den 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 nollförtroendeprinciper för att kryptera paketen. Sedan släpper den dem.

• Azure Firewall Premium kör säkerhetskontroller:

  • TLS-inspektionen (Transport Layer Security) dekrypterar och undersöker paketen.
  • Intrångsidentifierings- och skyddsfunktioner kontrollerar paketen efter skadlig avsikt.

• Om paketen klarar testerna utför Azure Firewall Premium följande steg:

  • Krypterar paketen
  • Använder en DNS-tjänst (Domain Name System) 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:

• Brandväggen för webbaserade program använder regler för att förhindra attacker på webblagret. Exempel på attacker är SQL-kodinmatning och skript för flera platser. Mer information om regler och OWASP-huvudregeluppsättningen (Open Web Application Security Project) finns i CRS-regelgrupper och regler för brandväggen för webbaserade program.
• Azure Firewall Premium använder allmänna regler för intrångsidentifiering och skydd. Dessa regler hjälper dig 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 en 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 kontrollerar Azure Firewall Premium att HTTP-värdhuvudet matchar paketets IP-adress och TCP-port. Anta till exempel att Application Gateway skickar webbpaket till IP-adressen 172.16.1.4 och TCP-port 443. Värdet för HTTP-värdhuvudet bör matchas mot den IP-adressen.

HTTP-värdhuvuden innehåller vanligtvis inte IP-adresser. Rubrikerna innehåller i stället namn som matchar serverns digitala certifikat. I det här fallet använder 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, vilket beskrivs i senare avsnitt.

Digitala certifikat

Följande diagram visar de vanliga namn (CN) och certifikatutfärdare (CA) som arkitekturens TLS-sessioner och certifikat använder:

TLS-anslutningar

Den här arkitekturen innehåller tre distinkta TLS-anslutningar. Digitala certifikat verifierar var och en:

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

För att dekryptera och inspektera TLS-trafik genererar Azure Firewall Premium dynamiskt certifikat. Azure Firewall Premium presenterar sig också för Application Gateway som webbserver. En privat certifikatutfärdare signerar de certifikat som 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ärdarorganisation som Azure Firewall Premium använder.

Från Azure Firewall Premium till webbservern

Azure Firewall Premium upprättar en TLS-session med målwebbservern. Azure Firewall Premium verifierar att en välkänd ca signerar webbserverns TLS-paket.

Komponentroller

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

• Application Gateway är en omvänd webbproxy. Den skyddar webbservrar från skadliga klienter genom att http- och HTTPS-begäranden fångas upp. Du deklarerar varje skyddad server som finns i serverdelspoolen för Application Gateway med dess IP-adress eller fullständigt kvalificerade domännamn. Legitima klienter bör kunna komma åt varje program. Så du konfigurerar Application Gateway med ett digitalt certifikat som en offentlig certifikatutfärdare har signerat. Använd en ca som alla TLS-klienter accepterar.
• Azure Firewall Premium är en vidarebefordrad webbproxy eller helt enkelt en webbproxy. Det skyddar klienter från skadliga webbservrar genom att fånga upp TLS-anrop från de skyddade klienterna. När en skyddad klient gör en HTTP-begäran personifierar den vidarebefordrade 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 dynamiskt genererade certifikat. Du konfigurerar de skyddade klienterna så att de litar på den privata ca:en. I den här arkitekturen skyddar Azure Firewall Premium begäranden från Application Gateway till webbservern. Application Gateway litar på den privata CA:en som Azure Firewall Premium använder.

Vidarebefordran av routning och trafik

Routningen skiljer sig något beroende på nätverksdesignens topologi. Följande avsnitt beskriver detaljerna i topologiexempel för Hub and Spoke, Virtual WAN och Route Server. Det finns dock vissa aspekter som är gemensamma för alla topologier:

• Azure Application Gateway fungerar alltid som en proxy och Azure Firewall Premium fungerar också när det konfigureras för TLS-inspektion: TLS-sessioner från klienter avslutas av Application Gateway och nya TLS-sessioner skapas mot Azure Firewall. Azure Firewall tar emot och avslutar TLS-sessioner från Application Gateway och skapar nya TLS-sessioner mot arbetsbelastningarna. Detta faktum har konsekvenser för IDPS-konfigurationen av Azure Firewall Premium, avsnitten nedan innehåller mer information om detta.
• Arbetsbelastningen ser anslutningar som kommer från Azure Firewalls IP-adress för undernätet. Den ursprungliga klientens IP-adress bevaras i X-Forwarded-For HTTP-huvudet som infogas av Application Gateway.
• Trafik från Application Gateway till arbetsbelastningen skickas vanligtvis till Azure Firewall med hjälp av Azure-routningsmekanismer, antingen med användardefinierade vägar som konfigurerats i Application Gateways undernät eller med vägar som matas in av Azure Virtual WAN eller Azure Route Server. Även om det är möjligt att uttryckligen definiera Azure Firewalls privata IP-adress i Application Gateways serverdelspool, rekommenderas det tekniskt sett inte eftersom det tar bort några av funktionerna i Azure Firewall, till exempel belastningsutjämning och fasthet.

I följande avsnitt beskrivs några av de vanligaste topologierna som används med Azure Firewall och Application Gateway.

Topologi med nav och ekrar

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

• Det kan vara svårt att felsöka brandväggsaviseringar för webbaserade program. Du behöver vanligtvis djupgående kunskaper om programmet för att avgöra om de meddelanden som utlöser dessa larm är legitima.
• Om du behandlar Application Gateway som en delad resurs kan du överskrida Gränserna för Azure Application Gateway.
• Du kan stöta på problem med rollbaserad åtkomstkontroll om du distribuerar Application Gateway i hubben. Den här situationen kan uppstå 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 som Application Gateway använder för trafik och för hälsokontroller.

Följande diagram visar paketflödet när Application Gateway finns 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 godkänns skickar Application Gateway paketet till den virtuella serverdelsdatorn. När paketet når Azure vidarebefordrar en användardefinierad väg (UDR) i Application Gateway-undernätet paketen till Azure Firewall Premium.
3. Azure Firewall Premium kör säkerhetskontroller på paketen. Om de klarar testerna vidarebefordrar 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 det virtuella datorundernätet omdirigerar paketen till Azure Firewall Premium.
5. Azure Firewall Premium vidarebefordrar paketen till Application Gateway.
6. Application Gateway svarar klienten.

Trafik kan också komma 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) 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 detsamma 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 godkänns vidarebefordrar en UDR i Application Gateway-undernätet paketen till Azure Firewall Premium.
4. Azure Firewall Premium kör säkerhetskontroller på paketen. Om de klarar testerna vidarebefordrar 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 det virtuella datorundernä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-topologi

Du kan också använda nätverkstjänsten Virtual WAN i den här arkitekturen. Den här komponenten har många fördelar. Det eliminerar till exempel behovet av användarunderhållna UDR:er i virtuella ekernätverk. Du kan definiera statiska vägar i routningstabeller för virtuell hubb i stället. Programmeringen av 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 resulterar 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 hubb som innehåller Azure Firewall Premium. Om du vill implementera DNS-matchning för Azure Firewall Premium använder du DNS-servrar i stället:

  • Konfigurera Azure Firewall DNS-Inställningar att använda anpassade DNS-servrar.
  • Distribuera servrarna i ett virtuellt nätverk för delade tjänster som du ansluter till det virtuella WAN-nätverket.
  • Länka en privat DNS-zon till det virtuella nätverket för delade tjänster. DNS-servrarna kan sedan matcha namnen som 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 (mindre specifikt) än prefixet för det virtuella nätverket. I diagrammen ovanför det virtuella ekernätverket finns till exempel prefixet 172.16.0.0/16: i det här fallet Virtual WAN skulle inte kunna mata in en väg som matchar VNet-prefixet (172.16.0.0/16) eller något av undernäten (172.16.0.0/24, 172.16.1.0/24). Virtual WAN kan med andra ord inte locka trafik mellan två undernät som finns i samma virtuella nätverk. Den här begränsningen blir uppenbar när Application Gateway och målwebbservern finns i samma virtuella nätverk: Virtual WAN kan inte tvinga trafiken mellan Application Gateway och webbservern att gå via Azure Firewall Premium (en lösning skulle vara att manuellt konfigurera användardefinierade vägar i undernäten för Application Gateway och webbservern).

Följande diagram visar paketflödet i ett fall som använder Virtual WAN. I det här fallet kommer åtkomsten till Application Gateway 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 godkänns vidarebefordrar Application Gateway-undernätet paketen till Azure Firewall Premium.
4. Azure Firewall Premium begär DNS-matchning från en DNS-server i det virtuella nätverket för delade tjänster.
5. DNS-servern svarar på matchningsbegäran.
6. Azure Firewall Premium kör säkerhetskontroller på paketen. Om de klarar testerna vidarebefordrar Azure Firewall Premium paketen till den virtuella programdatorn.
7. Den virtuella datorn svarar och anger mål-IP-adressen till Application Gateway. Programundernätet omdirigerar paketen till Azure Firewall Premium.
8. Azure Firewall Premium vidarebefordrar paketen till Application Gateway.
9. Application Gateway skickar paketen till VPN.
10. VPN svarar klienten.

Med den här designen kan du behöva ändra den routning som hubben annonserar till de virtuella ekernätverken. Mer specifikt stöder 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 den anslutning som Microsoft behö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 utföra något av följande steg:

• Skapa en routningstabell 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 i.
• Om du distribuerar Application Gateway i en dedikerad eker inaktiverar du spridningen av standardvägen i inställningarna för den virtuella nätverksanslutningen.

Routningsservertopologi

Route Server erbjuder ett annat sätt att mata in vägar automatiskt i ekrar. Med den här funktionen undviker du de administrativa kostnaderna för att underhålla routningstabeller. Route Server kombinerar virtual WAN- och hubb- och ekervarianterna:

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

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

• Routningsservern kräver för närvarande den enhet som matar in vägarna för att skicka dem via Border Gateway Protocol (BGP). Eftersom Azure Firewall Premium inte stöder BGP använder du en virtuell nätverksinstallation från tredje part (NVA) i stället.
• Funktionen för NVA 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 godkänns vidarebefordrar Application Gateway-undernätet paketen till en serverdelsdator. En väg i ApplicationGateway-undernätet som matas in av routningsservern vidarebefordrar trafiken till en NVA.
4. NVA kör säkerhetskontroller på paketen. Om de klarar testerna vidarebefordrar NVA paketen till den virtuella programdatorn.
5. Den virtuella datorn svarar och anger mål-IP-adressen till Application Gateway. En väg som matas in i det virtuella datorundernätet av routningsservern omdirigerar paketen till NVA.
6. NVA vidarebefordrar paketen till Application Gateway.
7. Application Gateway skickar paketen till den virtuella nätverksgatewayen.
8. Gatewayen svarar klienten.

Precis som med Virtual WAN kan du behöva ändra routningen när du använder Route Server. 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 routningstabell för Application Gateway-undernätet. Inkludera en väg för 0.0.0.0/0 och en nästa hopptyp Internet i tabellen.

IDPS och privata IP-adresser

Som beskrivs i Azure Firewall IDPS-regler bestämmer Azure Firewall Premium vilka IDPS-regler som ska tillämpas beroende på paketens käll- och mål-IP-adresser. Azure Firewall behandlar per standard privat IP-adresser i RFC 1918-intervallen (10.0.0.0/8192.168.0.0/16och 172.16.0.0/12) och RFC 6598-intervallet (100.64.0.0/10) som interna. Om som i diagrammen i den här artikeln distribueras Application Gateway i ett undernät i något av dessa intervall (172.16.0.0/24 i exemplen ovan) kommer Azure Firewall Premium att betrakta trafik mellan Application Gateway och arbetsbelastningen som intern, och endast IDPS-signaturer som har markerats för att tillämpas på intern trafik eller för all trafik kommer att användas. IDPS-signaturer som har markerats för inkommande eller utgående trafik tillämpas inte på trafik mellan Application Gateway och arbetsbelastningen.

Det enklaste sättet att tvinga regler för inkommande IDPS-signaturer att tillämpas på trafiken mellan Application Gateway och arbetsbelastningen är att placera Application Gateway i ett undernät med ett prefix utanför de privata intervallen. Du behöver inte nödvändigtvis använda offentliga IP-adresser för det här undernätet, utan i stället kan du anpassa DE IP-adresser som Azure Firewall Premium behandlar som interna för IDPS. Om din organisation till exempel inte använder 100.64.0.0/10 intervallet kan du eliminera det här intervallet från listan över interna prefix för IDPS (se Privata IPDS-intervall för Azure Firewall Premium för mer information om hur du gör detta) och distribuera Application Gateway i ett undernät som konfigurerats med en IP-adress i 100.64.0.0/10.

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

• Skydda 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 för hub-spoke i Azure
• Nätverkstopologi med hub-spoke med Azure Virtual WAN