Implementera ett Zero Trust-nätverk för webbprogram med hjälp av Azure Firewall och Azure Application Gateway

Den här artikeln beskriver hur du implementerar Zero Trust-säkerhet för webbappar för att aktivera kontroll och kryptering från slutpunkt till slutpunkt. Zero Trust-modellen innehåller många andra begrepp, till exempel kontinuerlig identitetsverifiering och minimering av storleken på implicita förtroendeområden.

Den här artikeln fokuserar på krypterings- och inspektionskomponenten i en Zero Trust-arkitektur för inkommande trafik från det offentliga Internet. Mer information om andra aspekter av att distribuera ditt program på ett säkert sätt, till exempel autentisering och auktorisering, finns i dokumentationen om Noll förtroende. Exemplet i den här artikeln använder en metod med flera lager. I en metod med flera lager utgör nätverkssäkerhet ett av lagren i Zero Trust-modellen. 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.

Den här arkitekturen fokuserar på ett vanligt mönster för att maximera säkerheten, där Azure Application Gateway inspekterar och bearbetar trafik innan den når Azure Firewall Premium. I vissa scenarier kan du kombinera olika typer av nätverkssäkerhetsenheter för att öka skyddet. Mer information finns i Azure Firewall och Application Gateway för virtuella nätverk.

Arkitektur

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.

1. En klient skickar paket till Application Gateway, en lastbalanserare. Det körs med det valfria tillägg av Azure Web Application Firewall.

2. Application Gateway dekrypterar paketen och söker efter hot mot webbprogram. Om den inte hittar några hot använder den Zero Trust-principer för att kryptera paketen. Sedan släpper den dem.

3. Azure Firewall Premium kör följande säkerhetskontroller:

   • TLS-inspektion dekrypterar och undersöker paketen.
   • Funktioner för intrångsidentifiering och skyddssystem (IDPS) kontrollerar paketen efter skadlig avsikt.

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

   • Den krypterar paketen.
   • Den använder en DNS-tjänst (Domain Name System) för att fastställa den virtuella programdatorn (VM).
   • Paketen vidarebefordras till den virtuella programdatorn.

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

• Azure Web Application Firewall använder regler för att förhindra attacker på webbskiktet. Exempel på attacker är SQL-kodinmatning och skript för flera platser. Mer information om regler och CRS (Open Worldwide Application Security Project) (OWASP) Core Rule Set (CRS) finns i CRS-regelgrupper och regler för brandvägg för webbprogram.

• 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 följande 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 Azure Firewall Premium söker efter skadlig trafik verifierar det att HTTP-värdhuvudet matchar paketets IP-adress och TCP-port (Transmission Control Protocol). 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.

Digitala certifikat

Följande diagram visar de vanliga namn (CN) och certifikatutfärdare (CA) som används av den här arkitekturens TLS-sessioner och certifikat.

Azure Firewall genererar dynamiskt sina egna certifikat. Den här funktionen är en av de främsta orsakerna till att den placeras bakom Application Gateway. Annars konfronteras programklienten med självgenererade certifikat som flaggas som en säkerhetsrisk.

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. Den här mekanismen skiljer sig i grunden från hur Azure Firewall dynamiskt genererar digitala certifikat från en självsignerad eller intern certifikatutfärdare för offentlig nyckelinfrastruktur.

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 signerar. Använd en ca som alla TLS-klienter accepterar.

• Azure Firewall Premium är en vidarebefordra 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 webbproxyn 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

Routning skiljer sig något beroende på nätverksdesignens topologi. I följande avsnitt beskrivs exempel på hubb- och eker-, Virtual WAN- och Route Server-topologier. Alla topologier har följande aspekter gemensamt:

• Application Gateway fungerar alltid som en proxy. Azure Firewall Premium fungerar också som en proxy när den har konfigurerats för TLS-inspektion. Application Gateway avslutar TLS-sessioner från klienter 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. Den här processen påverkar IDPS-konfigurationen av Azure Firewall Premium. Mer information finns i IDPS och privata IP-adresser.

• Arbetsbelastningen ser anslutningar som kommer från IP-adressen för Azure Firewall-undernätet. Den ursprungliga klientens IP-adress bevaras i X-Forwarded-For HTTP-huvudet som Application Gateway infogar. Azure Firewall har också stöd för att mata in källklientens IP-adress i X-Forwarded-For huvudet. I det här scenariot är källklientens IP-adress programgatewayens IP-adress.

• Trafik från Application Gateway till arbetsbelastningen skickas vanligtvis till Azure Firewall med hjälp av Azure-routningsmekanismer. Dessa mekanismer omfattar användardefinierade vägar (UDR) som konfigurerats i Application Gateway-undernätet eller vägar som Virtual WAN eller Route Server matar in. Det är möjligt att uttryckligen definiera den privata IP-adressen för Azure Firewall i Application Gateway-serverdelspoolen, men vi rekommenderar inte att du gör det eftersom den tar bort några av de inbyggda funktionerna i Application Gateway, till exempel belastningsutjämning och sessionsstinne.

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

Topologi med nav och ekrar

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

• Det kan vara svårt att felsöka Azure Web Application Firewall-aviseringar. 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 Application Gateway.

• Du kan stöta på problem med rollbaserad åtkomstkontroll om du distribuerar Application Gateway i hubben. Den här situationen kan inträffa när team hanterar olika program men använder samma instans av Application Gateway. Varje team har sedan åtkomst till hela Application Gateway-konfigurationen.

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

1. Konfigurera en privat DNS-zon.
2. Länka zonen till det virtuella nätverk som innehåller Azure Firewall Premium.
3. Säkerställ att det finns ett adressuppslag för det värde som används av Application Gateway 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 paketen till den virtuella serverdelsdatorn. När paketen når Azure vidarebefordrar en UDR i Application Gateway-undernätet dem 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 programgatewayen. 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) från plats till plats eller via Azure 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 diagram.

1. En lokal klient ansluter till den virtuella nätverksgatewayen.

2. Den virtuella nätverksgatewayen 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. Den virtuella nätverksgatewayen svarar klienten.

Virtual WAN-topologi

Du kan också använda nätverkstjänsten Virtual WAN- i den här arkitekturen. Den här komponenten ger 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 DNS-inställningarna för Azure Firewall så att de använder 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 DNS-inställningar för Azure Firewall.

• 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 föregående diagram har till exempel det virtuella ekernätverket prefixet 172.16.0.0/16. I det här fallet kan Virtual WAN inte mata in en väg som matchar prefixet för det virtuella nätverket (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 dirigera 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 är att manuellt konfigurera UDR:er i Application Gateway- och webbserverundernäten.

Följande diagram visar paketflödet i en arkitektur som använder Virtual WAN. I det här scenariot kommer åtkomsten till Application Gateway från ett lokalt nätverk. En plats-till-plats-VPN- eller ExpressRoute-instans ansluter nätverket till Virtual WAN. Internetbaserad åtkomst följer en liknande väg.

1. En lokal klient ansluter till VPN-gatewayen.

2. VPN-gatewayen 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-gatewayen.

10. VPN-gatewayen svarar klienten.

Om du använder den här designen kan du behöva ändra de routningstabeller som hubben annonserar till de virtuella spoke-nä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 kan du förhindra att den 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 ger ett annat sätt att automatiskt implementera rutter i spokes. Använd den här funktionen för att undvika administrativa kostnader för att underhålla routningstabeller. Route Server kombinerar virtual WAN- och hubb- och ekervarianterna:

• Du kan använda Route Server för att hantera 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. Tänk på följande:

• Routningsservern kräver för närvarande den enhet som matar in vägarna för att skicka dem via Border Gateway Protocol (BGP). Azure Firewall Premium stöder inte BGP, så använd en virtuell nätverksinstallation (NVA) som inte kommer från Microsoft 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. Den virtuella nätverksgatewayen vidarebefordrar klientpaketen till Application Gateway.

3. Application Gateway undersöker paketen. Om de godkänns vidarebefordrar Application Gateway-undernätet paketen till en serverdelsdator. Route Server matar in en väg i Application Gateway-undernätet som vidarebefordrar trafiken till en NVA.

4. NVA-undernätet 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. NVA kör säkerhetskontroller på paketen. Om de klarar testerna vidarebefordrar NVA paketen till den virtuella programdatorn.

7. Den virtuella programdatorn svarar och anger mål-IP-adressen till Application Gateway. Route Server matar in en väg i det virtuella datorundernätet som omdirigerar paketen till NVA.

8. NVA vidarebefordrar paketen till Application Gateway.

9. Application Gateway skickar paketen till den virtuella nätverksgatewayen.

10. Den virtuella nätverksgatewayen svarar klienten.

Precis som med Virtual WAN kan du behöva ändra routningen när du använder Route Server. Om du annonserar 0.0.0.0/0 vägen 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

Azure Firewall Premium bestämmer vilka IDPS-regler som ska tillämpas baserat på paketens käll- och mål-IP-adresser. Som standard behandlar Azure Firewall privata IP-adresser i RFC 1918-intervallen (10.0.0.0/8, 192.168.0.0/16och ) och 172.16.0.0/12RFC 6598-intervallet (100.64.0.0/10) som interna. Om du distribuerar Application Gateway i ett undernät i något av dessa intervall anser Azure Firewall Premium att trafiken mellan Application Gateway och arbetsbelastningen är intern. Därför används endast IDPS-signaturer som har markerats för att tillämpas på intern trafik eller på någon trafik. IDPS-signaturer som har markerats för inkommande eller utgående trafik tillämpas inte på trafik mellan Application Gateway och arbetsbelastningen. Mer information finns i Azure Firewall IDPS-regler.

Det enklaste sättet att tvinga IDPS-regler för inkommande signaturer att tillämpas på trafiken mellan Application Gateway och arbetsbelastningen är genom att placera Application Gateway i ett undernät som använder 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. I stället kan du anpassa IP-adresserna 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 och distribuera Application Gateway i ett undernät som konfigurerats med en IP-adress i 100.64.0.0/10. Mer information finns i Privata IPDS-intervall för Azure Firewall Premium.

Bidragsgivare

Microsoft ansvarar för den här artikeln. 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

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

Relaterade resurser

• Implementera ett säkert hybridnätverk
• Nätverkstopologi av typen hub-spoke i Azure
• Nätverkstopologi med nav-eker som använder Virtual WAN