Azure Firewall och trafikkontroll

Azure Firewall är en hanterad, molnbaserad nätverkssäkerhetstjänst som tillhandahåller centraliserad trafikkontroll och filtrering för dina Azure virtuella nätverk. Till skillnad från nätverkssäkerhetsgrupper som körs på Layer 4 inspekterar Azure Firewall trafik vid lager 3 till och med 7. Den här funktionen möjliggör filtrering av fullständigt kvalificerade domännamn (FQDN), hotinformation, intrångsidentifiering och skydd (IDPS) och TLS-inspektion. Du driftsätter Azure Firewall i ett dedikerat undernät i ditt virtuella hubbnätverk och dirigerar trafik från arbetsbelastningar i spoke-nätverk via brandväggen för inspektion innan den når sin destination.

Den här artikeln beskriver hur du väljer rätt Azure Firewall SKU, placerar brandväggen i en topologi med nav-eker, konfigurerar regeltyper och integrerar med kompletterande tjänster som NAT Gateway och Route Server. Azure Firewall är en av tre kärntjänster för Azure-nätverkssäkerhet, tillsammans med Azure DDoS Protection och Azure Web Application Firewall.

Vad den här artikeln beskriver

Den här artikeln handlar om centraliserad nätverkstrafikinspektion med hjälp av Azure Firewall. Du lär dig mer om:

• SKU-nivåval baserat på säkerhetskrav och arbetsbelastningskänslighet.
• Placering av hubben och användardefinierade routningsmönster (UDR) som tvingar trafik genom brandväggen.
• Regelbearbetningslogik för DNAT, nätverk och programregler.
• Påtvingad tunnling för miljöer som kräver lokal inspektion.
• TLS-inspektions- och IDPS-funktioner på Premium-nivån.
• Integrering med NAT Gateway för SNAT-portskalning och routningsserver för BGP-baserad routning.

Vem behöver den här artikeln

Distribuera Azure Firewall när dina arbetsbelastningar kräver en eller flera av följande funktioner:

• Centraliserad utgående kontroll: Du måste begränsa vilka externa FQDN och URL:er som dina arbetsbelastningar kan nå, utöver vad NSG IP-baserade regler tillhandahåller.
• Öst-väst-inspektion: Trafik mellan virtuella ekernätverk måste passera genom en tillståndsbaserad inspektionspunkt innan brandväggen tillåter det.
• Efterlevnadsbaserad loggning: Regelverk kräver fullständig layer 7-insyn i tillåtna och nekade anslutningar med FQDN-nivåskornighet.
• Skydd mot hot: Du behöver signaturbaserad intrångsidentifiering och skydd för att identifiera skadliga trafikmönster, inklusive återanrop med kommando och kontroll, försök till exploatering och lateral förflyttning.
• TLS-inspektion: Du måste dekryptera och inspektera krypterad trafik (HTTPS) för hot innan den når arbetsbelastningar eller lämnar nätverket.

Organisationer som bara behöver Layer 4-paketfiltrering utan FQDN-medvetenhet bör betrakta NSG:er och ASG:er som ett enklare alternativ till lägre kostnad.

Azure Firewall SKU-nivåer

Azure Firewall finns på tre SKU-nivåer. Varje nivå bygger på funktionerna på den föregående nivån.

Så här väljer du din SKU

Använd följande beslutsvillkor:

• Välj Grundläggande när du har utvecklings-/testmiljöer eller små arbetsbelastningar som behöver FQDN-baserad utgående filtrering utan hotinformationsfiltrering (neka-läge) eller avancerad inspektion. SKU på grundnivå innehåller information om hot i läget endast avisering men stöder inte nekningsläge, DNS-proxy eller webbkategorier. Basic-SKU kräver en dedikerad AzureFirewallManagementSubnet (minst /26) tillsammans med AzureFirewallSubnet och är tillgänglig i ett begränsat antal regioner.
• Välj Standard för produktionsarbetsbelastningar som behöver hotinformationsbaserad filtrering, DNS-proxy för FQDN-regelmatchning, webbkategorifiltrering och centraliserad principhantering via Azure Firewall Manager. Standard tillhandahåller en fullständig motor för tillståndsbaserad inspektion med flöden med hotinformation som blockerar anslutningar till kända skadliga IP-adresser och domäner.
• Välj Premium när regler eller säkerhetskrav kräver TLS-inspektion av krypterad trafik, signaturbaserade IDPS med kontinuerligt uppdaterade regler (över 67 000 signaturer i fler än 50 kategorier, uppdaterade i realtid) eller fullständig URL-sökvägsfiltrering utöver FQDN. Premium krävs för branscher som finansiella tjänster, sjukvård och myndigheter där krypterad trafikinspektion är obligatorisk.

Navplacering och UDR-routningsmönster

Distribuera Azure Firewall i ett dedikerat undernät med namnet exakt AzureFirewallSubnet i ditt virtuella hubbnätverk. Det här undernätet kräver en minsta storlek på /26 (59 användbara IP-adresser).

Routningsarkitektur

I en hub-spoke-topologi dirigerar ekerarbetsbelastningsundernät inte trafik direkt till Internet eller till andra ekrar. I stället sätter UDR:erna i varje ekerundernät standardvägen (0.0.0.0/0) till Azure Firewalls privata IP-adress. Det här mönstret säkerställer att all trafik, både nord-syd (internetbunden) och öst-väst (eker-till-eker), passerar genom brandväggen för inspektion.

UDR-konfigurationsmönster:

Själva AzureFirewallSubnet kräver inte UDR:er i de flesta scenarier, eftersom brandväggen använder systemrutter för att nå spoke-nätverk via peering mellan virtuella nätverk. När du integrerar med Azure Route Server lär sig brandväggsundernätet vägar via BGP. Den här metoden tar bort behovet av manuellt vägunderhåll när nätverket växer.

Krav för undernät

Mer information om hubbdesign och planering av undernät finns i Hub-spoke-topologi.

Regeltyper och bearbetningslogik

Azure Firewall bearbetar regler via Azure Firewall Policy. Regler är ordnade i regelsamlingar som grupperas i regelsamlingsgrupper. Brandväggen utvärderar regler i följande prioritetsordning:

1. DNAT-regler (målnätverksadressöversättning): Bearbetas först. Översätt inkommande trafik från en offentlig IP-adress till en privat IP-adress bakom brandväggen.
2. Nätverksregler: Bearbetas som nummer två. Tillåt eller neka trafik baserat på källans IP-adress, mål-IP, port och protokoll (Layer 3/4).
3. Programregler: Bearbetas sist. Tillåt eller neka utgående trafik baserat på FQDN, URL eller webbkategori (Lager 7).

Inom varje regeltyp utvärderas regelsamlingsgrupper efter prioritet (lägst antal = högsta prioritet). I en grupp utvärderas regelsamlingar efter prioritet. Den första matchande regeln avgör åtgärden (Tillåt eller Neka) och stoppar ytterligare utvärdering.

DNAT-regler

Använd DNAT-regler för att publicera interna tjänster via brandväggens offentliga IP-adress. Brandväggen översätter måladressen från dess offentliga IP-adress till den privata IP-adressen för serverdelstjänsten. Vanliga scenarier är:

• Exponera en intern webbserver via brandväggens offentliga IP-adress på port 443
• Tillhandahålla kontrollerad RDP- eller SSH-åtkomst till en hoppruta utan att tilldela en offentlig IP-adress till den virtuella datorn
• Publicera icke-HTTP/S-tjänster som kräver inkommande åtkomst från Internet

Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

DNAT-regler lägger implicit till en motsvarande nätverksregel för att tillåta den översatta trafiken. När en DNAT-regel matchar översätts och tillåts trafiken utan ytterligare bearbetning av nätverksregler. För säkerhet begränsar du källans IP-adress i dina DNAT-regler till specifika Internetkällor i stället för att använda jokertecken.

Nätverksregler

Nätverksregler filtrerar trafik på Layer 3 och Layer 4. Använd nätverksregler när du behöver tillåta eller neka trafik baserat på källans IP-adress, mål-IP-adress, målport och protokoll. Nätverksregler utför inte FQDN-matchning. De fungerar strikt på IP-adresser. Vanliga användningsfall är:

• Att tillåta spoke-till-spoke-kommunikation för specifika portar (till exempel SQL Server på TCP 1433).
• Tillåter NTP-trafik (UDP 123) till specifika tidsservrar.
• Blockera trafik till kända skadliga IP-intervall med hjälp av neka-regler.
• Tillåta ICMP för nätverksdiagnostik mellan specifika undernät.

Nätverksregler stöder TCP-, UDP-, ICMP- och alla protokolltyper. Du kan ange IP-adresser, IP-intervall, tjänsttaggar och IP-grupper som källa och mål.

Ansökningsregler

Programregler filtrerar utgående HTTP/S- och MSSQL-trafik baserat på FQDN, URL:er och webbkategorier. Programregler kräver DNS-proxyfunktionen för FQDN-matchning. Använd programregler när:

• Du måste tillåta åtkomst till specifika FQDN (till exempel *.microsoft.com eller storage.blob.core.windows.net).
• Du vill filtrera efter URL-sökväg (endast Premium SKU), till exempel att tillåta github.com/myorg/* men blockera andra GitHub sökvägar.
• Du måste tillåta eller blockera hela webbkategorier (till exempel tillåta "Utvecklarverktyg" och blockera "Gambling").

Programregler tillhandahåller FQDN-taggar för vanliga Azure tjänster (till exempel Windows Update, Azure Backup och HDInsight) som förenklar skapande av regler genom att gruppera nödvändiga FQDN i en enda tagg.

SNAT-beteende

Som standard tillämpar Azure Firewall SNAT (Source Network Address Translation) på utgående trafik som är avsedd för offentliga IP-adresser. Brandväggen SNAT:ar inte trafik när destinationen är ett privat IP-intervall (RFC 1918) eller delat adressutrymme (RFC 6598). Brandväggen översätter käll-IP-adressen för internetbundna anslutningar till en av dess offentliga IP-adresser. Varje offentlig IP-adress tillhandahåller 2 496 SNAT-portar per serverdelsinstans.

För arbetsbelastningar med höga utgående anslutningshastigheter kan du integrera med NAT Gateway för att skala till 64 512 portar per offentlig IP-adress (upp till 16 offentliga IP-adresser, cirka en miljon SNAT-portar totalt).

När du associerar NAT Gateway med AzureFirewallSubnetanvänder all utgående Internettrafik automatiskt de offentliga IP-adresserna för NAT Gateway. Brandväggen fortsätter att inspektera trafiken, men NAT Gateway hanterar SNAT-översättningen. Ingen dubbel NAT förekommer.

Firewallhanteraren och policyarv

Azure Firewall Manager tillhandahåller centraliserad säkerhetsprincip och routningshantering över flera Azure Firewall instanser. Exempel på viktiga funktioner:

• Principhierarki: Skapa en basprincip (överordnad) med organisationsomfattande regler och tillåt underordnade team att skapa underordnade principer som ärver från den överordnade. Överordnade regler har alltid företräde oavsett underordnade prioritetsvärden.
• Hantering över flera regioner: En brandväggspolicy är en global resurs som du kan associera med brandväggar i valfri region eller prenumeration.
• Hantering av flera brandväggar: Tillämpa en konsekvent säkerhetsnivå för hubbbrandväggar i olika regioner eller i skyddade Virtual WAN-hubbar.

NAT-regler är brandväggsspecifika och ärvs inte från överordnade principer. Hotinformationsläget ärvs men kan bara åsidosättas med ett striktare läge i underordnade principer. En policy med högst en brandväggskoppling ingår utan extra kostnad. Ytterligare kopplingar medför debitering.

Tvingad tunneltrafik

I vissa regelmiljöer måste all internetbunden trafik först dirigeras via en lokal inspektionsplats innan den når Internet. Azure Firewall stöder tvingad tunneltrafik för att tillgodose detta krav.

När du aktiverar tvingad tunneltrafik:

• AzureFirewallManagementSubnet bär hanteringstrafiken för brandväggen direkt till internet. Detta undernät måste ha en rutt till 0.0.0.0/0 med Internet som nästa hopp. Du kan inte tvinga hanteringstrafik via lokal inspektion.
• Den AzureFirewallSubnet dirigerar internetbunden arbetsbelastningstrafik till en lokal brandvägg eller en tredjeparts nätverksvirtuell enhet (NVA) via ExpressRoute eller VPN Gateway.
• DNAT-regler stöds inte i läget för tvingad tunneltrafik eftersom inkommande trafik inte kan nå brandväggens offentliga IP-adress direkt.
• Brandväggen kräver ingen offentlig IP-adress på AzureFirewallSubnet när du konfigurerar forcerad tunnling, eftersom all utgående trafik går via den lokala nätverkssökvägen.

Använd tvingad tunneltrafik när efterlevnadsmandat kräver lokal synlighet för all internetbunden trafik, eller när du behöver länka Azure Firewall med en befintlig lokal säkerhetsstack. Vanliga scenarier är miljöer inom finanssektorn som omfattas av regler om datalagring inom landet och statliga nätverk med krav på centraliserad internetutgång.

Granskning av TLS (Premium)

Azure Firewall Premium fångar upp utgående HTTPS-anslutningar, dekrypterar trafiken, inspekterar den mot IDPS-signaturer och programregler och krypterar sedan om och vidarebefordrar den. Den här processen kräver ett mellanliggande CA-certifikat som lagras i Azure Key Vault.

Certifikatkrav

Brandväggen använder det mellanliggande CA-certifikatet för att dynamiskt generera servercertifikat för uppfångade anslutningar. Slutanvändarens webbläsare och program måste lita på organisationens rotcertifikatutfärdare eller mellanliggande certifikatutfärdare i certifikatarkivet för att undvika förtroendevarningar.

IDPS (Intrångsdetektions- och förebyggande system)

Premium SKU innehåller en fullständigt hanterad IDPS-motor med över 67 000 regler i över 50 kategorier. Signaturer uppdateras kontinuerligt, med 20–40+ nya regler som släpps varje dag. IDPS fungerar i två lägen:

• Aviseringsläge: Loggar signaturmatchningar utan att blockera trafik. Använd under den inledande distributionen och justeringen.
• Aviserings- och neka-läge: Loggar och blockerar trafik som matchar IDPS-signaturer. Använd i produktion efter justering.

IDPS-kategorier omfattar kommando och kontroll av skadlig kod, nätfiske, trojaner, botnät, exploateringspaket, sårbarheter och SCADA/ICS-protokoll.

AKS utgående filtrering

När Azure Kubernetes Service (AKS) kluster kräver kontrollerad utgående trafik tillhandahåller Azure Firewall FQDN-baserad utgående filtrering för klusternoder. Utan utgående filtrering kan AKS-noder nå valfri Internetslutpunkt, vilket ökar attackytan för leveranskedjan och dataexfiltreringsattacker.

Så här implementerar du det här mönstret:

1. Distribuera AKS med outboundType angivet till userDefinedRouting och en anpassad routningstabell i nodundernätet.
2. Ange standardvägen (0.0.0.0/0) till den Azure Firewall privata IP-adressen.
3. Skapa programregler i brandväggsprincipen som tillåter de AKS-FQDN:er som krävs (containerregister, API-serverslutpunkter och Microsofts paketrepositorier).
4. Skapa nätverksregler för nödvändiga icke-HTTP/S-slutpunkter (NTP, DNS, tunnelanslutning).

Det här mönstret ger säkerhetsteam insyn i och kontroll över vilka externa slutpunkter AKS-noder kan nå, samtidigt som klustret kan fungera korrekt. Nödvändiga FQDN:er varierar beroende på AKS-funktionsuppsättning. Kluster som använder GPU-noder, Azure Monitor eller Azure Policy kräver ytterligare poster i listan över godkända objekt.

Detaljerade FQDN-krav och regelexempel finns i Använda Azure Firewall för att skydda AKS-distributioner.

Designöverväganden

Förutsättningar

Innan du distribuerar Azure Firewall:

• AzureFirewallSubnet: Ditt virtuella hubbnätverk måste innehålla ett dedikerat undernät med namnet AzureFirewallSubnet med en minsta storlek på /26. Mer information finns i Design för virtuellt nätverk och undernät för planering av undernät.
• Hub-spoke- eller Virtual WAN-topologi: Distribuera Azure Firewall i en central hubb som dirigerar trafik från spoke-nätverk. Mer information om topologialternativ finns i Topologi för Hub-spoke eller Virtual WAN.
• IP-adressplan: Reservera adressutrymme för brandväggsundernätet, hanteringsundernätet (om du använder tvingad tunneltrafik) och eventuella offentliga IP-adresser. Se Planering av IP-adresser.
• Azure Firewall Manager: Använd Azure Firewall Manager om du behöver en principhierarki som delar basregler över flera brandväggsinstanser.
• Log Analytics-arbetsyta: Skapa en arbetsyta för diagnostikloggar för brandväggen före driftsättning så att du kan övervaka trafiken och felsöka regler från dag ett.

Säkerhetsfrågor

• Loggning: Aktivera diagnostikinställningar för att skicka Azure Firewall loggar till en Log Analytics arbetsyta. Strukturerade loggar ger FQDN-nivå insyn i varje tillåten och nekad anslutning, vilket stöder granskning och kriminalteknisk analys.
• Tillgänglighet: Distribuera Azure Firewall mellan tillgänglighetszoner för att maximera tillgänglighetsavtalet. Aktuella SLA-procentandelar finns i Serviceavtal för Azure Firewall.
• Lagerskydd: Azure Firewall kompletterar, men ersätter inte, NSG:er. Tillämpa NSG:er på undernäts- och nätverkskortsnivå för mikrosegmentering. Använd brandväggen för centraliserad princip, hotinformation och Layer 7-inspektion.
• Rätt storlek på det du inspekterar: Att tvinga varje flöde genom brandväggen, inklusive nivåer inom program, till exempel webb-till-app och app-till-databas, lägger till svarstid och bearbetningskostnad per gigabyte. Använd NSG:er och ASG:er för öst-väst-trafik mellan betrodda skikt, och använd brandväggsinspektion endast för trafik som korsar en förtroendegräns: trafik som går till internet, mellan ekrar, i hybridmiljöer eller mellan moln. Den här metoden håller brandväggen fokuserad på den trafik som drar nytta av inspektion och undviker onödiga kostnader.
• DDoS-skydd: Skydda offentliga IP-adresser som är associerade med Azure Firewall med hjälp av Azure DDoS Protection. Se DDoS-skydd.
• ExpressRoute-trafik: När du använder ExpressRoute konfigurerar du UDR:er för att dirigera privat peeringtrafik via Azure Firewall för kontroll av hybridtrafikflöden.

Relaterade artiklar

• Nätverkstopologi för hub-spoke: Virtuellt hubbnätverk där du distribuerar Azure Firewall.
• Utgående internetåtkomst: Mönster för utgående kontroll med Azure Firewall och NAT Gateway.
• Web Application Firewall: Layer 7 HTTP/S-skydd som kompletterar Azure Firewall inspektion på nätverksnivå.
• DNS-säkerhet och privat namnmatchning: DNS-proxykonfiguration som möjliggör FQDN-baserade regler.
• Vad är Azure-nätverkssäkerhet?: Översikt som jämför Azure Firewall, DDoS Protection och Web Application Firewall.

Learn more

• Dokumentation om Azure Firewall
• Azure Firewall-funktioner
• Funktioner i Azure Firewall Premium
• Azure Firewall Manager översikt
• Distribuera och konfigurera Azure Firewall
• Prissättning för Azure Firewall

Nästa steg