Firewall en Application Gateway voor virtuele netwerken

Voor het beveiligen van workloads van Azure-toepassingen gebruikt u beschermende maatregelen, zoals verificatie en versleuteling, in de toepassingen zelf. U kunt ook beveiligingslagen toevoegen aan de VM-netwerken (virtuele machines) die als host voor de toepassingen worden gebruikt. De lagen beschermen inkomende stromen van gebruikers. Ze beschermen ook uitgaande stromen naar internet die uw toepassing mogelijk nodig heeft. In dit artikel worden Azure Virtual Network-beveiligingsservices zoals Azure Firewall en Azure Application Gateway, wanneer u elke service gebruikt en netwerkontwerpopties die beide combineren.

• Azure Firewall is een beheerde firewall van de volgende generatie die NAT (Network Address Translation) biedt. Azure Firewall baseert pakketfiltering op Internet Protocol-adressen (IP) en Transmission Control Protocol- en User Datagram Protocol-poorten (TCP/UDP), of op http(s) of SQL-kenmerken op basis van toepassingen. Azure Firewall ook bedreigingsinformatie van Microsoft toegepast om schadelijke IP-adressen te identificeren. Zie de documentatie Azure Firewall meer informatie.
• Azure Firewall Premium bevat alle functionaliteit van Azure Firewall Standard en andere functies, zoals TLS-inspectie en Inbraakdetectie en Beveiligingssysteem (IDPS).
• Azure Application Gateway is een beheerde webverkeers-load balancer en HTTP(S) volledige omgekeerde proxy die SSL-versleuteling en -ontsleuteling (Secure Socket Layer) kan gebruiken. Application Gateway maakt ook gebruik van Web Application Firewall om webverkeer te inspecteren en aanvallen op de HTTP-laag te detecteren. Zie de documentatie Application Gateway meer informatie.
• Azure Web Application Firewall (WAF) is een optionele aanvulling op Azure Application Gateway. Het biedt inspectie van HTTP-aanvragen en voorkomt schadelijke aanvallen op de weblaag, zoals SQL injectie of cross-site scripting. Zie de Web Application Firewall voor meer informatie.

Deze Azure-services zijn aanvullend. Het ene of het andere kan het beste zijn voor uw workloads, of u kunt ze samen gebruiken voor optimale beveiliging op zowel het netwerk als de toepassingslagen. Gebruik de volgende beslissingsstructuur en de voorbeelden in dit artikel om de beste beveiligingsoptie voor het virtuele netwerk van uw toepassing te bepalen.

Azure Firewall en Azure Application Gateway verschillende technologieën gebruiken en ondersteunen securitisatie van verschillende stromen:

Toepassings Flow	Kan worden gefilterd op Azure Firewall	Kan worden gefilterd door WAF op Application Gateway
HTTP(S) verkeer van on-premises/internet naar Azure (inkomende)	Ja	Ja
HTTP(S) verkeer van Azure naar on-premises/internet (uitgaand)	Ja	Nee
Niet-HTTP(S)-verkeer, inkomende/uitgaande	Ja	Nee

Afhankelijk van de netwerkstromen die een toepassing nodig heeft, kan het ontwerp per toepassing verschillen. Het volgende diagram biedt een vereenvoudigde beslissingsstructuur waarmee u de aanbevolen benadering voor een toepassing kunt kiezen. De beslissing is afhankelijk van of de toepassing wordt gepubliceerd via HTTP(S) of een ander protocol:

In dit artikel worden de veel aanbevolen ontwerpen uit het stroomdiagram en andere ontwerpen beschreven die van toepassing zijn in minder gangbare scenario's:

• Azure Firewall alleen ,wanneer er geen webtoepassingen in het virtuele netwerk zijn. Het beheert zowel het inkomende verkeer naar de toepassingen als het uitgaande verkeer.
• Application Gateway alleen ,wanneer alleen webtoepassingen zich in het virtuele netwerk en netwerkbeveiligingsgroepen (NSG's) voldoende uitvoerfilters bieden. Dit scenario wordt doorgaans niet aanbevolen vanwege de uitgebreide functionaliteit van Azure Firewall via NSG's. Deze functionaliteit kan veel aanvalsscenario's voorkomen (zoals gegevens exfiltratie), zodat dit scenario niet wordt beschreven in het bovenstaande stroomdiagram.
• Azure Firewall en Application Gateway parallel ,een van de meest voorkomende ontwerpen. Gebruik deze combinatie als u Azure Application Gateway HTTP(S)-toepassingen wilt beveiligen tegen webaanvallen en Azure Firewall om alle andere workloads te beveiligen en uitgaand verkeer te filteren.
• Application Gatewayvóór Azure Firewall , wanneer u wilt dat Azure Firewall al het verkeer inspecteert, WAF om webverkeer te beveiligen en de toepassing om het bron-IP-adres van de client te kennen. Met Azure Firewall Premium en TLS-inspectie ondersteunt dit ontwerp ook het end-to-end SSL-scenario.
• Azure Firewall vóór Application Gateway, wanneer u wilt dat Azure Firewall verkeer inspecteert en filtert voordat het de Application Gateway. Omdat de Azure Firewall HTTPS-verkeer niet gaat ontsleutelen, is de functionaliteit die wordt toegevoegd aan de Application Gateway beperkt. Dit scenario wordt niet beschreven in het bovenstaande stroomdiagram.

In het laatste deel van dit artikel worden variaties van de vorige fundamentele ontwerpen beschreven. Deze variaties zijn onder andere:

• On-premises toepassings-clients.
• Hub-en-spoke-netwerken.
• Azure Kubernetes Service -implementaties (AKS).

U kunt andere omgekeerde proxyservices toevoegen, zoals een API Management-gateway of Azure Front Door. U kunt de Azure-resources ook vervangen door virtuele netwerkapparaten van derden.

Azure Firewall alleen

Als er geen webgebaseerde workloads in het virtuele netwerk zijn die kunnen profiteren van WAF, kunt u alleen Azure Firewall gebruiken. Het ontwerp is in dit geval eenvoudig, maar als u de pakketstroom bekijkt, krijgt u meer inzicht in complexere ontwerpen. In dit ontwerp wordt al het inkomende verkeer naar de Azure Firewall verzonden via UDR's (voor verbindingen van on-premises of andere Azure-VNets), of wordt het adres van het openbare IP-adres van de Azure Firewall (voor verbindingen vanaf het openbare internet, zoals in het onderstaande diagram wordt weergegeven). Uitgaand verkeer van Azure VNets wordt via UDR's naar de firewall verzonden, zoals wordt weergegeven in het onderstaande dialoogvenster.

De volgende tabel bevat een overzicht van de verkeersstromen voor dit scenario:

Stroom	Loopt via Application Gateway/WAF	Gaat door Azure Firewall
HTTP(S) verkeer van internet/onprem naar Azure	N.v.t.	Ja (zie hieronder)
HTTP(S) verkeer van Azure naar internet/onprem	N.v.t.	Ja
Niet-HTTP(s) verkeer van internet/onprem naar Azure	N.v.t.	Ja
Niet-HTTP(s) verkeer van Azure naar internet/onprem	N.v.t.	Ja

Azure Firewall inspecteert geen inkomende HTTP(S)-verkeer. Maar het kan L3/L4-regels en op FQDN gebaseerde toepassingsregels toepassen. Azure Firewall controleert uitgaand HTTP(S)-verkeer, afhankelijk van de Azure Firewall-laag en of u TLS-inspectie configureert:

• Azure Firewall Standard inspecteert alleen laag 3-4-kenmerken van de pakketten in netwerkregels en de HOST-HTTP-header in toepassingsregels.
• Azure Firewall Premium voegt mogelijkheden toe, zoals het inspecteren van andere HTTP-headers (zoals de gebruikersagent) en het inschakelen van TLS-inspectie voor diepere pakketanalyse. Azure Firewall is niet gelijk aan een Web Application Firewall. Als u webworkloads in uw Virtual Network, wordt het gebruik van WAF sterk aanbevolen.

In het volgende pakketvoorbeeld ziet u hoe een client toegang heeft tot een VM-toepassing die wordt gehost via het openbare internet. Het diagram bevat slechts één VM voor het gemak. Voor hogere beschikbaarheid en schaalbaarheid hebt u meerdere toepassings instances achter een load balancer.

1. De client start de verbinding met het openbare IP-adres van de Azure Firewall:
   • IP-adres van bron: ClientPIP
   • Doel-IP-adres: AzFwPIP
2. Met Azure Firewall DNAT-regel (Destination NAT) wordt het doel-IP-adres omgezet in het IP-adres van de toepassing in het virtuele netwerk. De Azure Firewall bron-NAT's (SNAT's) het pakket als het DNAT gebruikt. Zie voor meer informatie Azure Firewall bekende problemen. De VM ziet de volgende IP-adressen in het binnenkomende pakket:
   • Bron-IP-adres: 192.168.100.7
   • Doel-IP-adres: 192.168.1.4
3. De VM beantwoordt de aanvraag van de toepassing en geeft de bron- en doel-IP-adressen om. Voor de binnenkomende stroom is geen door de gebruiker gedefinieerde route (UDR) vereist, omdat het bron-IP-adres Azure Firewall IP-adres is. De UDR in het diagram voor 0.0.0.0/0 is voor uitgaande verbindingen, om ervoor te zorgen dat pakketten naar het openbare internet via de Azure Firewall.
   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.100.7
4. Ten slotte Azure Firewall de SNAT- en DNAT-bewerkingen ongedaan gemaakt en wordt het antwoord aan de client gegeven:
   • Bron-IP-adres: AzFwPIP
   • Doel-IP-adres: ClientPIP

In dit ontwerp inspecteert Azure Firewall zowel binnenkomende verbindingen van het openbare internet als uitgaande verbindingen van de toepassingssubnet-VM met behulp van de UDR.

• Het IP-adres is een van de exemplaren die de Azure Firewall-service implementeert, hier met 192.168.100.7 het front-end-IP-adres 192.168.100.4 . Deze afzonderlijke exemplaren zijn normaal gesproken onzichtbaar voor de Azure-beheerder. Maar het verschil is in sommige gevallen handig, bijvoorbeeld bij het oplossen van netwerkproblemen.

• Als verkeer afkomstig is van een on-premises virtueel particulier netwerk (VPN) of Azure ExpressRoute-gateway in plaats van internet, start de client de verbinding met het IP-adres van de virtuele machine. De verbinding met het IP-adres van de firewall wordt niet geactiveerd en de firewall doet geen bron-NAT per standaard.

Application Gateway alleen

In dit ontwerp wordt de situatie belicht waarin alleen webtoepassingen bestaan in het virtuele netwerk en het inspecteren van uitgaand verkeer met NSG's voldoende is om uitgaande stromen naar internet te beveiligen.

Het belangrijkste verschil met het vorige ontwerp met alleen de Azure Firewall is dat de Application Gateway niet als routeringsapparaat met NAT werkt. Het gedraagt zich als een volledige omgekeerde toepassingsproxy. Dat wil zeggen dat Application Gateway websessie van de client stopt en een afzonderlijke sessie tot leven brengt met een van de back-endservers. Binnenkomende HTTP(S)-verbindingen van internet moeten worden verzonden naar het openbare IP-adres van de Application Gateway, verbindingen van Azure of on-premises naar het privé-IP-adres. Retourverkeer van de Azure-VM's volgt standaard VNet-routering terug naar de Application Gateway (zie het pakket verderop voor meer informatie). Uitgaande internetstromen van azure-VM's gaan direct naar internet.

De volgende tabel bevat een overzicht van verkeersstromen:

Stroom	Loopt via Application Gateway/WAF	Door de Azure Firewall
HTTP(S) verkeer van internet/onprem naar Azure	Ja	N.v.t.
HTTP(S) verkeer van Azure naar internet/onprem	Nee	N.v.t.
Niet-HTTP(s) verkeer van internet/onprem naar Azure	Nee	N.v.t.
Niet-HTTP(S)-verkeer van Azure naar internet/onprem	Nee	N.v.t.

In het volgende voorbeeld van een pakketuitje ziet u hoe een client toegang heeft tot de VM-gehoste toepassing vanaf het openbare internet.

1. De client start de verbinding met het openbare IP-adres van de Azure Application Gateway:
   • Bron-IP-adres: ClientPIP
   • DOEL-IP-adres: AppGwPIP
2. De Application Gateway die de aanvraag ontvangt, stopt de verbinding van de client en brengt een nieuwe verbinding tot stand met een van de back-ends. De back-end ziet het Application Gateway als het bron-IP-adres. De Application Gateway voegt een X-Forwarded-For HTTP-header toe met het ip-adres van de oorspronkelijke client.
   • Bron-IP-adres: 192.168.200.7 (het privé-IP-adres van het Application Gateway-exemplaar)
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For-header: ClientPIP
3. De VM beantwoordt de aanvraag van de toepassing en geeft de bron- en doel-IP-adressen om. De VM weet al hoe de Application Gateway bereikt, dus heeft geen UDR nodig.
   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
4. Ten slotte beantwoordt Application Gateway-exemplaar de client:
   • Bron-IP-adres: AppGwPIP
   • Doel-IP-adres: ClientPIP

Azure Application Gateway voegt metagegevens toe aan de HTTP-headers van het pakket, zoals de X-Forwarded-For-header die het IP-adres van de oorspronkelijke client bevat. Sommige toepassingsservers hebben het IP-adres van de bronclient nodig voor geolocatiespecifieke inhoud of voor logboekregistratie. Zie Hoe een toepassingsgateway werkt voor meer informatie.

• Het IP-adres is een van de exemplaren die de Azure Application Gateway-service implementeert, hier met 192.168.200.7 het front-end-IP-adres 192.168.200.4 . Deze afzonderlijke exemplaren zijn normaal gesproken onzichtbaar voor de Azure-beheerder. Maar het verschil is in sommige gevallen handig, bijvoorbeeld bij het oplossen van netwerkproblemen.

• De stroom is vergelijkbaar als de client afkomstig is van een on-premises netwerk via een VPN- of ExpressRoute-gateway. Het verschil is dat de client het privé-IP-adres van de Application Gateway in plaats van het openbare adres.

Firewall en Application Gateway parallel

Vanwege de eenvoud en flexibiliteit is het parallel Application Gateway en Azure Firewall vaak het beste scenario.

Implementeert dit ontwerp als er een combinatie van web- en niet-webworkloads in het virtuele netwerk is. Azure WAF beschermt het inkomende verkeer naar de webworkloads en de Azure Firewall inspecteert het inkomende verkeer voor de andere toepassingen. De Azure Firewall omvatten uitgaande stromen van beide typen workloads.

Binnenkomende HTTP(S)-verbindingen van internet moeten worden verzonden naar het openbare IP-adres van de Application Gateway,HTTP(S)-verbindingen van Azure of on-premises naar het privé-IP-adres. Standaard-VNet-routering verzendt de pakketten van de Application Gateway naar de doel-VM's en van de doel-VM's terug naar de Application Gateway (zie het pakket verderop voor meer informatie). Voor binnenkomende niet-HTTP(S)-verbindingen moet verkeer gericht zijn op het openbare IP-adres van de Azure Firewall (als het afkomstig is van het openbare internet), of het wordt verzonden via de Azure Firewall door UDRs (als het afkomstig is van andere Azure VNets of on-premises netwerken). Alle uitgaande stromen van Azure-VM's worden doorgestuurd naar de Azure Firewall door UDR's.

De volgende tabel bevat een overzicht van de verkeersstromen voor dit scenario:

Stroom	Loopt via Application Gateway/WAF	Door de Azure Firewall
HTTP(S) verkeer van internet/onprem naar Azure	Ja	Nee
HTTP(S) verkeer van Azure naar internet/onprem	Nee	Ja
Niet-HTTP(s) verkeer van internet/onprem naar Azure	Nee	Ja
Niet-HTTP(S)-verkeer van Azure naar internet/onprem	Nee	Ja

Dit ontwerp biedt veel gedetailleerdere filters voor egressie dan NSG's. Als toepassingen verbinding moeten hebben met een Azure Storage-account, kunt u op FQDN gebaseerde filters (Fully Qualified Domain Name) gebruiken. Met op FQDN gebaseerde filters verzenden toepassingen geen gegevens naar rogue opslagaccounts. Dit scenario kan niet worden voorkomen door NSG's te gebruiken. Dit ontwerp wordt vaak gebruikt wanneer uitgaand verkeer filteren op basis van FQDN vereist. Een voorbeeld hiervan is wanneer u het verkeer van een Azure Kubernetes Services-cluster beperkt.

Het volgende diagram illustreert de verkeersstroom voor binnenkomende verbindingen van een externe client:

In het volgende diagram ziet u de verkeersstroom voor uitgaande verbindingen van de netwerk-VM's naar internet. U kunt bijvoorbeeld verbinding maken met back-endsystemen of updates van het besturingssysteem downloaden:

De stappen voor pakketstromen voor elke service zijn hetzelfde als in de vorige zelfstandige ontwerpopties.

Application Gateway vóór firewall

In deze optie gaat het inkomende webverkeer via zowel Azure Firewall als WAF. De WAF biedt beveiliging op de laag van de webtoepassing. Azure Firewall fungeert als een centraal logboekregistratie- en controlepunt en inspecteert het verkeer tussen de Application Gateway en de back-endservers. De Application Gateway en Azure Firewall niet parallel zitten, maar de ene na de andere.

Met Azure Firewall Premiumbiedt dit ontwerp ondersteuning voor end-to-end-scenario's, waarbij de Azure Firewall TLS-inspectie van toepassing is om IDPS uit te voeren op het versleutelde verkeer tussen de Application Gateway en de webback-end.

Dit ontwerp is geschikt voor toepassingen die binnenkomende IP-adressen van clientbron moeten kennen, bijvoorbeeld voor geolocatiespecifieke inhoud of voor logboekregistratie. Azure Firewall SNAT's voor het binnenkomende verkeer, door het oorspronkelijke bron-IP-adres te wijzigen. Application Gateway voor Azure Firewall legt het bron-IP-adres van het binnenkomende pakket vast in de X-forwarded-for-header, zodat de webserver het oorspronkelijke IP-adres in deze header kan zien. Zie Hoe een toepassingsgateway werkt voor meer informatie.

Binnenkomende HTTP(S)-verbindingen van internet moeten worden verzonden naar het openbare IP-adres van de Application Gateway, HTTP(S)-verbindingen van Azure of on-premises naar het privé-IP-adres. Vanaf de Application Gateway UDR's zorgt u ervoor dat de pakketten via de Azure Firewall worden gerouteerd (zie het pakket verderop voor meer informatie). Voor binnenkomende niet-HTTP(S)-verbindingen moet verkeer gericht zijn op het openbare IP-adres van de Azure Firewall (als het afkomstig is van het openbare internet), of het wordt verzonden via de Azure Firewall door UDR's (als het afkomstig is van andere Azure-VNet's of on-premises netwerken). Alle uitgaande stromen van azure-VM's worden doorgestuurd naar de Azure Firewall door UDR's.

De volgende tabel bevat een overzicht van de verkeersstromen voor dit scenario:

Stroom	Loopt via Application Gateway/WAF	Gaat door Azure Firewall
HTTP(S) verkeer van internet/onprem naar Azure	Ja	Ja
HTTP(S) verkeer van Azure naar internet/onprem	Nee	Ja
Niet-HTTP(s) verkeer van internet/onprem naar Azure	Nee	Ja
Niet-HTTP(s) verkeer van Azure naar internet/onprem	Nee	Ja

Voor webverkeer van on-premises of internet naar Azure controleert de Azure Firewall stromen die de WAF al heeft toegestaan. Afhankelijk van of de Application Gateway back-endverkeer (verkeer van de Application Gateway naar de toepassingsservers) versleutelt, hebt u twee verschillende mogelijke scenario's:

1. De Application Gateway versleutelt verkeer volgens zero-trust-principes(End-to-End TLS-versleuteling)en de Azure Firewall ontvangt versleuteld verkeer. Toch kan Azure Firewall Standard inspectieregels toepassen, zoals L3/L4-filtering in netwerkregels of FQDN-filtering in toepassingsregels met behulp van de TLS Servernaamindicatie-header (SNI). Azure Firewall Premium biedt meer zichtbaarheid met IDPS, zoals filteren op basis van URL's.
2. Als de Application Gateway niet-versleuteld verkeer naar de toepassingsservers stuurt, ziet de Azure Firewall inkomende verkeer in ongecodeerde tekst. TLS-inspectie is niet nodig in de Azure Firewall.
3. Als IDPS is ingeschakeld in de Azure Firewall, wordt gecontroleerd of de HTTP-hostheader overeenkomt met het doel-IP-adres. Met dit doel moet de naam worden opgelost voor de FQDN die is opgegeven in de Host-header. Deze naamresolutie kan worden bereikt met Azure DNS Private Zones en de standaardinstellingen Azure Firewall DNS met behulp van Azure DNS. Dit kan ook worden bereikt met aangepaste DNS-servers die moeten worden geconfigureerd in de Azure Firewall instellingen. (Zie DNS-Azure Firewall voor Instellingen voor meerinformatie. Als er geen beheerderstoegang is tot de Virtual Network waar de Azure Firewall is geïmplementeerd, is de laatste methode de enige mogelijkheid. Een voorbeeld hiervan is wanneer Azure Firewalls is geïmplementeerd in Virtual WAN beveiligde hubs.

Voor de rest van de stromen (inkomende niet-HTTP(S)-verkeer en uitgaand verkeer) biedt de Azure Firewall waar nodig IDPS-inspectie en TLS-inspectie. Het biedt ook filteren op basis van FQDN in netwerkregels op basis van DNS.

Netwerkverkeer van het openbare internet volgt deze stroom:

1. De client start de verbinding met het openbare IP-adres van de Azure Application Gateway:
   • IP-adres van bron: ClientPIP
   • Doel-IP-adres: AppGwPIP
2. Het Application Gateway stopt de verbinding van de client en brengt een nieuwe verbinding tot stand met een van de back-ends. Met de UDR naar in het Application Gateway subnet wordt het pakket doorgestuurd naar de Azure Firewall, met behoud van het 192.168.1.0/24 doel-IP-adres naar de webtoepassing:
   • Bron-IP-adres: 192.168.200.7 (privé IP-adres van het Application Gateway-exemplaar)
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For-header: ClientPIP
3. Azure Firewall maakt geen SNAT van het verkeer, omdat het verkeer naar een privé-IP-adres gaat. Het verkeer wordt doorgestuurd naar de toepassings-VM als de regels dit toestaan. Zie SNATvoor Azure Firewall informatie.
   • Bron-IP-adres: 192.168.200.7 (het privé-IP-adres van het Application Gateway-exemplaar)
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For-header: ClientPIP
4. De VM beantwoordt de aanvraag en geeft de bron- en doel-IP-adressen om. De UDR voor legt het pakket vast dat is teruggestuurd naar de Application Gateway en stuurt het om naar Azure Firewall, met behoud van het doel-IP-adres naar 192.168.200.0/24 de Application Gateway.
   • Ip-adres van bron: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
5. Ook hier wordt Azure Firewall verkeer niet door SNAT gestuurd, omdat het naar een privé-IP-adres gaat en het verkeer doorsturen naar de Application Gateway.
   • Ip-adres van bron: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
6. Ten slotte beantwoordt Application Gateway-instantie de client:
   • IP-adres van bron: AppGwPIP
   • Doel-IP-adres: ClientPIP

Uitgaande stromen van de VM's naar het openbare internet gaan via Azure Firewall, zoals gedefinieerd door de UDR naar 0.0.0.0/0 .

Application Gateway na firewall

Met dit ontwerp Azure Firewall schadelijk verkeer filteren en verwijderen voordat het de Application Gateway. Het kan bijvoorbeeld functies toepassen zoals filteren op basis van bedreigingsinformatie. Een ander voordeel is dat de toepassing hetzelfde openbare IP-adres krijgt voor zowel binnenkomende als uitgaande verkeer.

Dit scenario heeft beperkte voordelen, omdat Azure Firewall alleen versleuteld verkeer naar de Application Gateway. Er zijn mogelijk scenario's waarin dit ontwerp de voorkeur heeft. Een voorbeeld hiervan is als een andere WAF eerder in het netwerk is (bijvoorbeeld met Azure Front Door). Of het ontwerp heeft de voorkeur als er veel openbare IP-adressen vereist zijn.

Inkomende HTTP(S)-stromen van het openbare internet moeten zijn gericht op het openbare IP-adres van de Azure Firewall en de Azure Firewall zal de pakketten dnat naar het privé-IP-adres van de Application Gateway. Vanuit andere Azure VNets of on-premises netwerken moet HTTP(S)-verkeer worden verzonden naar het IP-adres van de Application Gateway en worden doorgestuurd via de Azure Firewall met UDR's. Standaard-VNet-routering zorgt ervoor dat het retourverkeer van de Azure-VM's teruggaat naar de Application Gateway en van de Application Gateway naar de Azure Firewall als DNAT-regels zijn gebruikt. Voor verkeer van on-prem of Azure UDRs in het Application Gateway subnet moet worden gebruikt (zie het pakket verderop voor meer informatie). Al het uitgaande verkeer van de Azure-VM's naar internet wordt via de Azure Firewall door UDR's verzonden.

De volgende tabel bevat een overzicht van de verkeersstromen voor dit scenario:

Stroom	Loopt via Application Gateway/WAF	Gaat door Azure Firewall
HTTP(S) verkeer van internet/onprem naar Azure	Ja	Ja (zie hieronder)
HTTP(S) verkeer van Azure naar internet/onprem	Nee	Ja
Niet-HTTP(s) verkeer van internet/onprem naar Azure	Nee	Ja
Niet-HTTP(s) verkeer van Azure naar internet/onprem	Nee	Ja

Voor inkomende HTTP(S)-verkeer ontsleutelt Azure Firewall doorgaans geen verkeer. In plaats daarvan worden IDPS-beleidsregels toegepast waarvoor geen TLS-inspectie is vereist, zoals filteren op basis van IP of het gebruik van HTTP-headers.

De toepassing kan het oorspronkelijke bron-IP-adres van het webverkeer niet zien; De Azure Firewall SNAT's de pakketten wanneer ze het virtuele netwerk binnen komen. Om dit probleem te voorkomen, gebruikt Azure Front Door voor de firewall. Azure Front Door het IP-adres van de client als een HTTP-header voordat deze het virtuele Azure-netwerk binnenkomt.

Netwerkverkeer van het openbare internet volgt deze stroom:

1. De client start de verbinding met het openbare IP-adres van de Azure Firewall:
   • IP-adres van bron: ClientPIP
   • Doel-IP-adres: AzFWPIP
2. De Azure Firewall de webpoort, meestal TCP 443, naar het privé-IP-adres van de Application Gateway instantie. Azure Firewall ook SNAT's bij het gebruik van DNAT. Zie bekende problemen voor Azure Firewall meer informatie:
   • Ip-adres van bron: 192.168.100.7 (het privé-IP-adres van het Azure Firewall-exemplaar)
   • Doel-IP-adres: 192.168.200.4
3. De Application Gateway brengt een nieuwe sessie tot stand tussen het exemplaar dat de verbinding afhandelt en een van de back-endservers. Het oorspronkelijke IP-adres van de client staat niet in het pakket:
   • Bron-IP-adres: 192.168.200.7 (het privé-IP-adres van het Application Gateway-exemplaar)
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For-header: 192.168.100.7
4. De VM beantwoordt de Application Gateway, het omkeren van bron- en doel-IP-adressen:
   • Ip-adres van bron: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
5. De Application Gateway antwoordt op het IP-adres van de SNAT-bron van het Azure Firewall exemplaar. Zelfs als de verbinding afkomstig is van een specifiek Application Gateway-exemplaar zoals , Azure Firewall het interne IP-adres van de Application Gateway als het .7 .4 bron-IP-adres:
   • Bron-IP-adres: 192.168.200.4
   • Doel-IP-adres: 192.168.100.7
6. Ten slotte Azure Firewall SNAT en DNAT ongedaan gemaakt en antwoorden op de client:
   • IP-adres van bron: AzFwPIP
   • Doel-IP-adres: ClientPIP

Zelfs als voor de Application Gateway listeners zijn geconfigureerd voor toepassingen, is er nog steeds een openbaar IP-adres nodig, zodat Microsoft dit kan beheren.

On-premises clients

De voorgaande ontwerpen tonen alle toepassings-clients die afkomstig zijn van het openbare internet. On-premises netwerken hebben ook toegang tot toepassingen. De meeste voorgaande informatie en verkeersstromen zijn hetzelfde als voor internetklanten, maar er zijn enkele belangrijke verschillen:

• Een VPN-gateway of ExpressRoute-gateway bevindt zich voor Azure Firewall of Application Gateway.
• WAF gebruikt het privé-IP-adres van de Application Gateway.
• Azure Firewall biedt geen ondersteuning voor DNAT voor privé-IP-adressen. Daarom moet u UR's gebruiken om inkomende verkeer naar Azure Firewall VPN- of ExpressRoute-gateways te verzenden.
• Controleer de waarschuwingen voor geforceerd tunnelen voor de Azure Application Gateway en voor de Azure Firewall. Zelfs als uw workload geen uitgaande verbinding met het openbare internet nodig heeft, kunt u geen standaardroute zoals voor de Application Gateway injecteren die naar het on-premises netwerk wijst, of u gaat het controleverkeer 0.0.0.0/0 breken. Voor Azure Application Gateway moet de standaardroute naar het openbare internet wijzen.

In het volgende diagram ziet u de Azure Application Gateway en Azure Firewall parallel ontwerp. Toepassings-clients zijn afkomstig van een on-premises netwerk dat is verbonden met Azure via VPN of ExpressRoute:

Zelfs als alle clients zich on-premises of in Azure bevinden, Azure Application Gateway en Azure Firewall beide openbare IP-adressen hebben. Met de openbare IP-adressen kan Microsoft de services beheren.

Hub and spoke-topologie

De ontwerpen in dit artikel zijn nog steeds van toepassing in een hub en spoke-topologie. Gedeelde resources in een centraal virtueel hubnetwerk maken verbinding met toepassingen in afzonderlijke virtuele spoke-netwerken via peerings voor virtuele netwerken.

Enkele overwegingen voor deze topologie zijn:

• De Azure Firewall wordt geïmplementeerd in het virtuele netwerk van de centrale hub. Toepassingsteams beheren echter vaak onderdelen zoals Azure-toepassing gateways of Azure API Management-gateways. Deze onderdelen worden geïmplementeerd in de virtuele spoke-netwerken.
• Besteed speciale aandacht aan UR's in de spoke-netwerken: wanneer een toepassingsserver in een spoke verkeer ontvangt van een specifieke Azure Firewall-instantie, zoals het adres in de vorige voorbeelden, moet het retourverkeer terugsturen naar 192.168.100.7 hetzelfde exemplaar. Als met een UDR in de spoke de volgende hop van verkeer dat is geadresseerd aan de hub naar het IP-adres van de Azure Firewall (in de bovenstaande diagrammen), worden retourpakketten mogelijk op een ander Azure Firewall-exemplaar geplaatst, wat asymmetrische routering 192.168.100.4 veroorzaakt. Zorg ervoor dat als u UDR's in de spoke-VNets hebt om verkeer naar gedeelde services in de hub te verzenden via de Azure Firewall, deze UDR's niet het voorvoegsel van het Azure Firewall-subnet bevatten.
• De vorige aanbeveling geldt ook voor het Application Gateway subnet en andere virtuele netwerkapparaten of omgekeerde proxies die mogelijk worden geïmplementeerd in het hub-VNet.
• U kunt de volgende hop voor de subnetten Application Gateway of Azure Firewall via statische routes met een volgend hoptype van Virtual Network niet instellen. Dit 'volgende hoptype' is alleen geldig in het lokale VNet en niet tussen VNet-peerings. Zie Routering van virtueel netwerkverkeer voor meer informatie over door de gebruiker gedefinieerde routes en volgende hoptypen.

In het onderstaande diagram ziet u hoe een spoke SNATted-verkeer terugstaft naar de ALB van een Azure Firewall. Deze installatie veroorzaakt asymmetrische routering:

U kunt dit probleem oplossen door UDR's te definiëren in de spoke zonder het Azure Firewall-subnet, maar met alleen de subnetten waar de gedeelde services zich bevinden. In het voorbeeld mag de juiste UDR in de spoke alleen 192.168.1.0/24 bevatten. Deze mag niet de volledige 192.168.0.0/16 bevatten, zoals rood is gemarkeerd.

Integratie met andere Azure-producten

U kunt uw Azure Firewall en Azure Application Gateway integreren met andere Azure-producten en -services.

API Management-gateway

Integreer omgekeerde proxyservices zoals API Management gateway in de vorige ontwerpen om functionaliteit te bieden zoals API-beperking of verificatieproxy. De integratie van API Management gateway heeft geen grote invloed op de ontwerpen. Het belangrijkste verschil is dat er in plaats van de ene proxy Application Gateway, twee omgekeerde proxy's achter elkaar zijn geketend.

Zie de ontwerphandleiding voor het integreren van API Management en Application Gateway in een virtueel netwerk en het toepassingspatroon API Gateways for Microservices voor meer informatie.

Azure Kubernetes Service

Voor workloads die worden uitgevoerd op een AKS-cluster, kunt u Azure Application Gateway van het cluster implementeren. U kunt het ook integreren met het AKS-cluster met behulp van Azure Application Gateway ingress Controller. Bij het configureren van bepaalde objecten op Kubernetes-niveaus (zoals services en ingresses), wordt de Application Gateway automatisch aangepast zonder dat er extra handmatige stappen nodig zijn.

Azure Firewall speelt een belangrijke rol in de beveiliging van AKS-clusters. Het biedt de vereiste functionaliteit om het uitgaande verkeer van het AKS-cluster te filteren op basis van FQDN, niet alleen ip-adres. Zie Voor meer informatie Verkeersverkeer voor AKS-clusterknooppunten controleren.

Wanneer u de Application Gateway en Azure Firewall om een AKS-cluster te beveiligen, kunt u het beste de optie voor parallel ontwerp gebruiken. De Application Gateway met WAF verwerkt inkomende verbindingsaanvragen naar webtoepassingen in het cluster. Azure Firewall staat alleen expliciet uitgaande verbindingen toe.

Azure Front Door

Azure Front Door-functionaliteit overlapt gedeeltelijk met Azure Application Gateway. Beide services bieden bijvoorbeeld webtoepassingsfirewalling, SSL-offloading en routering op basis van URL's. Een belangrijk verschil is dat hoewel Azure Application Gateway zich in een virtueel netwerk Azure Front Door een globale, gedecentraliseerde service is.

Soms kunt u het ontwerp van virtuele netwerken vereenvoudigen door Application Gateway vervangen door een gedecentraliseerde Azure Front Door. De meeste ontwerpen die hier worden beschreven, blijven geldig, met uitzondering van de optie om Azure Firewall voor Azure Front Door.

Een interessant gebruikscase is het gebruik Azure Firewall voor een Application Gateway in uw virtuele netwerk. Zoals eerder beschreven, bevat de header die is geïnjecteerd door de Application Gateway het IP-adres van het firewall-exemplaar, niet het X-Forwarded-For IP-adres van de client. Een tijdelijke oplossing is om Azure Front Door vóór de firewall te gebruiken om het IP-adres van de client als header in te injecteren voordat het verkeer het virtuele netwerk binnenkomt en de X-Forwarded-For Azure Firewall.

Zie Veelgestelde vragen voor meer informatie over de verschillen tussen de twee services, of wanneer u deze gebruikt, veelgestelde vragen Azure Front Door.

Andere virtuele netwerkapparaten

Microsoft-producten zijn niet de enige keuze voor het implementeren van Web Application Firewall of de firewallfunctionaliteit van de volgende generatie in Azure. Een breed scala aan Microsoft-partners biedt virtuele netwerkapparaten (NNET's). De concepten en ontwerpen zijn in wezen hetzelfde als in dit artikel, maar er zijn enkele belangrijke overwegingen:

• Partner-N NVA's voor firewalls van de volgende generatie bieden mogelijk meer controle en flexibiliteit voor NAT-configuraties die niet worden ondersteund door de Azure Firewall. Voorbeelden zijn DNAT van on-premises of DNAT van internet zonder SNAT.
• Door Azure beheerde N NVA's (zoals Application Gateway en Azure Firewall) verminderen de complexiteit in vergelijking met N NVA's waar gebruikers schaalbaarheid en tolerantie moeten afhandelen voor veel apparaten.
• Wanneer u N NVA's in Azure gebruikt, gebruikt u actief-actief en automatisch schalen, zodat deze apparaten geen knelpunt vormen voor toepassingen die worden uitgevoerd in het virtuele netwerk.

Volgende stappen

Meer informatie over de onderdeeltechnologieën:

• Wat is Azure Application Gateway?
• Wat is Azure Firewall?
• Wat is Azure Front Door?
• Azure Kubernetes Service
• Wat is Azure Virtual Network?
• Wat is Azure Web Application Firewall?

Gerelateerde architecturen verkennen:

• Veilig hybride netwerk implementeren
• Veilig beheerde webtoepassingen
• Uw Microsoft Teams kanaalbot en web-app beveiligen achter een firewall
• Portal voor consumententoestand in Azure
• Beveiligingsoverwegingen voor zeer gevoelige IaaS-apps in Azure
• SaaS voor meerdere tenants in Azure
• Enterprise-implementatie met App Service Environment
• Enterprise-implementatie met hoge beschikbaarheid met App Service Environment
• Basislijnarchitectuur voor een Azure Kubernetes Service-cluster (AKS)