Firewall en Application Gateway voor virtuele netwerken

Als u azure-toepassingsworkloads wilt beveiligen, moet u beschermende maatregelen, zoals verificatie en versleuteling, in de toepassingen zelf gebruiken. U kunt ook beveiligingslagen toevoegen aan de virtuele netwerken (VNets) die als host fungeren voor de toepassingen. Deze beveiligingslagen beschermen de binnenkomende stromen van de toepassing tegen onbedoeld gebruik. Ze beperken ook uitgaande stromen naar internet tot alleen de eindpunten die uw toepassing nodig heeft. In dit artikel worden Azure Virtual Network beveiligingsservices zoals Azure DDoS Protection, Azure Firewall en Azure Application Gateway, wanneer u elke service gebruikt en netwerkontwerpopties die beide combineren, beschreven.

• Azure DDoS Protection Standard, gecombineerd met best practices voor toepassingsontwerp, biedt verbeterde DDoS-risicobeperkingsfuncties om meer bescherming te bieden tegen DDoS-aanvallen. U moet Azure DDOS Protection Standard inschakelen op elk virtueel perimeternetwerk.
• Azure Firewall is een beheerde firewall van de volgende generatie die NAT (Network Address Translation) biedt. Azure Firewall baseert pakketfiltering op IP-adressen (Internet Protocol) en Transmission Control Protocol- en TCP/UDP-poorten (User Datagram Protocol), of op http(S) of SQL-kenmerken op basis van toepassingen. Azure Firewall past ook bedreigingsinformatie van Microsoft toe om schadelijke IP-adressen te identificeren. Zie de documentatie voor Azure Firewall voor 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 load balancer voor beheerd webverkeer en een volledige omgekeerde HTTP(S) proxy die SSL-versleuteling (Secure Socket Layer) en ontsleuteling kan uitvoeren. Application Gateway behoudt het oorspronkelijke IP-adres van de client in een X-Forwarded-For HTTP-header. Application Gateway maakt ook gebruik van Web Application Firewall om webverkeer te inspecteren en aanvallen op de HTTP-laag te detecteren. Zie de documentatie voor Application Gateway voor 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 documentatie voor Web Application Firewall voor meer informatie.

Deze Azure-services zijn complementair. Het ene of het andere kan het beste zijn voor uw workloads, of u kunt ze samen gebruiken voor optimale beveiliging op zowel de 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 ze ondersteunen securitisatie van verschillende stromen:

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

In dit artikel worden de algemeen aanbevolen ontwerpen uit het stroomdiagram behandeld, en andere die van toepassing zijn in minder algemene scenario's:

• Azure Firewall alleen, wanneer het virtuele netwerk geen webtoepassingen bevat. Hiermee wordt zowel inkomend verkeer naar de toepassingen als uitgaand verkeer beheerd.
• Application Gateway alleen wanneer alleen webtoepassingen zich in het virtuele netwerk bevinden en netwerkbeveiligingsgroepen (NSG's) voldoende uitvoerfilters bieden. De functies van Azure Firewall kunnen veel aanvalsscenario's voorkomen (zoals gegevensexfiltratie, IDPS, enzovoort). Om deze reden wordt het scenario Application Gateway alleen doorgaans niet aanbevolen en daarom niet gedocumenteerd en staat het niet in het bovenstaande stroomdiagram.
• Azure Firewall en Application Gateway parallel, wat een van de meest voorkomende ontwerpen is. Gebruik deze combinatie als u wilt dat Azure Application Gateway HTTP(S)-toepassingen beschermt tegen webaanvallen en Azure Firewall om alle andere werkbelastingen te beveiligen en uitgaand verkeer te filteren.
• Application Gateway vóór Azure Firewall, als u wilt dat Azure Firewall al het verkeer inspecteert, WAF om webverkeer te beveiligen en de toepassing het bron-IP-adres van de client kent. Met Azure Firewall Premium- en TLS-inspectie ondersteunt dit ontwerp ook het end-to-end SSL-scenario.
• Azure Firewall voor Application Gateway wanneer u wilt dat Azure Firewall verkeer inspecteert en filtert voordat het de Application Gateway bereikt. Omdat de Azure Firewall HTTPS-verkeer niet gaat ontsleutelen, is de functionaliteit die het toevoegt 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 toepassingsclients.
• Hub- en spoke-netwerken.
• Azure Kubernetes Service (AKS)-implementaties.

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.

alleen Azure Firewall

Als er geen webworkloads 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 door de gebruiker gedefinieerde routes (UDR's) voor verbindingen van on-premises of andere Azure-VNets. Het is geadresseerd aan het openbare IP-adres van de Azure Firewall voor verbindingen van 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:

Azure Firewall binnenkomende HTTP(S)-verkeer niet inspecteert. Maar het kan regels voor laag 3 & laag 4 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 & laag 4-kenmerken van de pakketten in netwerkregels en de HTTP-header host in toepassingsregels.
• Azure Firewall Premium voegt mogelijkheden toe, zoals het inspecteren van andere HTTP-headers (zoals de user-agent) en het inschakelen van TLS-inspectie voor een diepere pakketanalyse. Azure Firewall is niet gelijk aan een Web Application Firewall. Als uw Virtual Network webworkloads bevat, wordt het gebruik van WAF ten zeerste aanbevolen.

Het volgende voorbeeld van een pakketverloop laat zien hoe een client toegang heeft tot een vm-gehoste toepassing via het openbare internet. Het diagram bevat slechts één VM voor het gemak. Voor een hogere beschikbaarheid en schaalbaarheid hebt u meerdere toepassingsexemplaren achter een load balancer. 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.

• Azure Firewall service implementeert verschillende exemplaren, hier met het front-end-IP-adres 192.168.100.4 en interne adressen uit het bereik 192.168.100.0/26. Deze afzonderlijke exemplaren zijn normaal gesproken onzichtbaar voor de Azure-beheerder. Maar in sommige gevallen is het handig om het verschil op te merken, bijvoorbeeld bij het oplossen van netwerkproblemen.
• Als verkeer afkomstig is van een on-premises VPN (Virtueel Particulier Netwerk) of Azure ExpressRoute-gateway in plaats van internet, start de client de verbinding met het IP-adres van de VM. De verbinding met het IP-adres van de firewall wordt niet gestart en de firewall voert standaard geen bron-NAT uit.

Architectuur

In het volgende diagram ziet u de verkeersstroom, ervan uitgaande dat het IP-adres van het exemplaar is 192.168.100.7.

Werkstroom

1. De client start de verbinding met het openbare IP-adres van de Azure Firewall:
   • Bron-IP-adres: ClientPIP
   • Doel-IP-adres: AzFwPIP
2. De aanvraag naar het Azure Firewall openbare IP-adres wordt gedistribueerd naar een back-endexemplaar van de firewall, in dit geval 192.168.100.7. Met de regel Azure Firewall Destination NAT (DNAT) wordt het doel-IP-adres omgezet in het IP-adres van de toepassing in het virtuele netwerk. De Azure Firewall ook bron-NAT's (SNAT's) het pakket als het DNAT doet. Zie bekende problemen Azure Firewall voor meer informatie. 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, waarbij bron- en doel-IP-adressen worden omgedraaid. Voor de binnenkomende stroom is geen door de gebruiker gedefinieerde route (UDR) vereist, omdat het bron-IP-adres Azure Firewall 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 gaan.
   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.100.7
4. Ten slotte worden de SNAT- en DNAT-bewerkingen ongedaan Azure Firewall en wordt het antwoord aan de client geleverd:
   • Bron-IP-adres: AzFwPIP
   • Doel-IP-adres: ClientPIP

alleen Application Gateway

Dit ontwerp heeft betrekking op de situatie waarin alleen webtoepassingen aanwezig zijn 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 fungeert als een routeringsapparaat met NAT. Het gedraagt zich als een volledig omgekeerde toepassingsproxy. Dat wil Application Gateway de websessie van de client stopt en een afzonderlijke sessie tot stand brengt met een van de back-endservers. Inkomende 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 van de gateway. Retourverkeer van de Azure-VM's volgt de standaard-VNet-routering terug naar de Application Gateway (zie het pakketpad verderop voor meer informatie). Uitgaande internetstromen van Azure-VM's gaan rechtstreeks naar internet.

De volgende tabel bevat een overzicht van verkeersstromen:

Architectuur

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

Werkstroom

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 aanvraag naar het Application Gateway openbare IP-adres wordt gedistribueerd naar een back-endexemplaar van de gateway, in dit geval 192.168.200.7. Het Application Gateway exemplaar dat 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-exemplaar als het bron-IP-adres. De Application Gateway voegt een X-Forwarded-For HTTP-header in met het oorspronkelijke IP-adres van de 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, waarbij bron- en doel-IP-adressen worden omgedraaid. De VM weet al hoe de Application Gateway te bereiken, dus heeft geen UDR nodig.
   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
4. Ten slotte beantwoordt het 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 met het IP-adres van de oorspronkelijke client. 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 192.168.200.7 is een van de exemplaren die de Azure Application Gateway-service onder de dekking implementeert, hier met het interne, privé-front-end-IP-adres 192.168.200.4. Deze afzonderlijke exemplaren zijn normaal gesproken onzichtbaar voor de Azure-beheerder. Maar in sommige gevallen is het handig om het verschil op te merken, 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 toegang heeft tot 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 vaak het beste scenario om Application Gateway en Azure Firewall parallel uit te voeren.

Implementeer dit ontwerp als het virtuele netwerk een combinatie van web- en niet-webworkloads bevat. Azure WAF in Azure Application Gateway beveiligt inkomend verkeer naar de webworkloads en de Azure Firewall inspecteert binnenkomend verkeer voor de andere toepassingen. De Azure Firewall behandelt uitgaande stromen van beide typen werkbelastingen.

Inkomende 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, evenals van de doel-VM's terug naar de Application Gateway (zie het pakketpad 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 (indien afkomstig van andere Azure-VNets of on-premises netwerken). Alle uitgaande stromen van Azure-VM's worden door UDR's doorgestuurd naar de Azure Firewall.

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

Dit ontwerp biedt veel gedetailleerdere uitgaande filtering dan NSG's. Als toepassingen bijvoorbeeld connectiviteit met een specifiek Azure Storage-account nodig hebben, kunt u FQDN-filters (Fully Qualified Domain Name) gebruiken. Met FQDN-filters verzenden toepassingen geen gegevens naar malafide opslagaccounts. Dit scenario kan niet worden voorkomen door alleen NSG's te gebruiken. Dit ontwerp wordt vaak gebruikt wanneer uitgaand verkeer filteren op basis van FQDN vereist. Een voorbeeld van een situatie is het beperken van uitgaand verkeer van een Azure Kubernetes Services-cluster.

Architecturen

In het volgende diagram ziet u de verkeersstroom voor binnenkomende HTTP(S)-verbindingen van een externe client:

In het volgende diagram ziet u de verkeersstroom voor uitgaande verbindingen van de netwerk-VM's naar internet. Een voorbeeld hiervan is om verbinding te maken met back-endsystemen of updates van het besturingssysteem op te halen:

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

Application Gateway vóór firewall

Bij deze optie gaat inkomend webverkeer via zowel Azure Firewall als WAF. 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 zitten niet parallel, maar achter elkaar.

Met Azure Firewall Premium kan dit ontwerp end-to-end-scenario's ondersteunen, waarbij de Azure Firewall TLS-inspectie toepast 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 de clientbron moeten kennen, bijvoorbeeld voor geolocatiespecifieke inhoud of voor logboekregistratie. Application Gateway vóór 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.

Inkomende 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. Vanuit de Application Gateway UDR's ervoor zorgen dat de pakketten worden gerouteerd via de Azure Firewall (zie de pakketbeschrijving 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-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:

Voor webverkeer van on-premises of internet naar Azure inspecteert de Azure Firewall stromen die de WAF al heeft toegestaan. Afhankelijk van of het Application Gateway back-endverkeer versleutelt (verkeer van de Application Gateway naar de toepassingsservers), hebt u 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 laag 3 & laag 4-filtering in netwerkregels of FQDN-filtering in toepassingsregels met behulp van de SNI-header (TLS Server Name Indication). 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 verzendt, ziet de Azure Firewall binnenkomend verkeer in niet-versleutelde 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. Voor dat doel is naamomzetting nodig voor de FQDN die is opgegeven in de hostheader. Deze naamomzetting kan worden bereikt met Azure DNS Private Zones en de standaard Azure Firewall DNS-instellingen 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-instellingen Azure Firewall voor meer informatie.) 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 dat Azure Firewalls zijn geïmplementeerd in Virtual WAN Secured Hubs.

Architectuur

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

Werkstroom

Netwerkverkeer van het openbare internet volgt deze stroom:

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 aanvraag naar het openbare IP-adres van de Application Gateway wordt gedistribueerd naar een back-endexemplaren van de gateway, in dit geval 192.168.200.7. De Application Gateway-instantie stopt de verbinding vanaf de client en brengt een nieuwe verbinding tot stand met een van de back-ends. De UDR naar 192.168.1.0/24 in het Application Gateway subnet stuurt het pakket door naar de Azure Firewall, terwijl het doel-IP-adres naar de webtoepassing behouden blijft:
   • 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 SNAT het verkeer niet, omdat het verkeer naar een privé-IP-adres gaat. Het verkeer wordt doorgestuurd naar de toepassings-VM als dit volgens de regels is toegestaan. Zie SNAT Azure Firewall voor meer informatie. Als het verkeer echter een toepassingsregel in de firewall raakt, ziet de werkbelasting het bron-IP-adres van het specifieke firewall-exemplaar dat het pakket heeft verwerkt, omdat de Azure Firewall de verbinding als proxy gebruikt:
   • Bron-IP-adres als het verkeer is toegestaan door een Azure Firewall netwerkregel: 192.168.200.7 (het privé-IP-adres van een van de Application Gateway exemplaren).
   • Bron-IP-adres als het verkeer is toegestaan door een Azure Firewall toepassingsregel: 192.168.100.7 (het privé-IP-adres van een van de Azure Firewall exemplaren).
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For-header: ClientPIP
4. De VM beantwoordt de aanvraag, waarbij bron- en doel-IP-adressen worden omgedraaid. De UDR voor 192.168.200.0/24 het vastleggen van het pakket dat naar de Application Gateway is verzonden, wordt omgeleid naar Azure Firewall, met behoud van het doel-IP-adres naar de Application Gateway.
   • Ip-adres van bron: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
5. Ook hier wordt het verkeer niet door de Azure Firewall gebruikt, omdat het naar een privé-IP-adres gaat en het verkeer doorstuurt naar de Application Gateway.
   • Ip-adres van bron: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
6. Ten slotte beantwoordt het Application Gateway exemplaar de client:
   • Bron-IP-adres: 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 kunt Azure Firewall schadelijk verkeer filteren en verwijderen voordat het de Application Gateway bereikt. 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 binnenkomend als uitgaand verkeer, ongeacht het protocol. Azure Firewall SNT's echter het binnenkomende verkeer, zodat de toepassing geen zichtbaarheid heeft voor het oorspronkelijke IP-adres van de HTTP-aanvragen. Vanuit het oogpunt van beheer, bijvoorbeeld voor probleemoplossingsdoeleinden, kunt u het werkelijke client-IP-adres voor een specifieke verbinding verkrijgen door deze te correleren met de SNAT-logboeken van de Azure Firewall.

Dit scenario heeft beperkte voordelen, omdat Azure Firewall alleen versleuteld verkeer naar de Application Gateway ziet gaan. Er kunnen scenario's zijn waarin dit ontwerp de voorkeur heeft. Een geval is als een andere WAF eerder in het netwerk is (bijvoorbeeld met Azure Front Door), waarmee het oorspronkelijke bron-IP-adres in de X-Forwarded-For HTTP-header kan worden vastgelegd. Of het ontwerp heeft de voorkeur als er veel openbare IP-adressen zijn vereist.

Binnenkomende HTTP(S)-stromen van het openbare internet moeten gericht zijn op het openbare IP-adres van de Azure Firewall en de Azure Firewall dnat (en SNAT) de pakketten 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 privé-IP-adres van het Application Gateway en worden doorgestuurd via de Azure Firewall met UDR's. Standaard VNet-routering zorgt ervoor dat 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-premises of Azure UDR's in het Application Gateway subnet moet worden gebruikt (zie de pakket-walk 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:

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

Architectuur

De toepassing kan het oorspronkelijke BRON-IP-adres van het webverkeer niet zien; de Azure Firewall SNT's de pakketten wanneer ze binnenkomen in het virtuele netwerk. Als u dit probleem wilt voorkomen, gebruikt u Azure Front Door vóór de firewall. Azure Front Door injecteert het IP-adres van de client als een HTTP-header voordat deze het virtuele Azure-netwerk binnenkomt.

Werkstroom

Netwerkverkeer van het openbare internet volgt deze stroom:

1. De client start de verbinding met het openbare IP-adres van de Azure Firewall:
   • Bron-IP-adres: ClientPIP
   • Doel-IP-adres: AzFWPIP
2. De aanvraag naar het Azure Firewall openbare IP-adres wordt gedistribueerd naar een back-endexemplaar van de firewall, in dit geval 192.168.100.7. De Azure Firewall DNAT's de webpoort, meestal TCP 443, naar het privé-IP-adres van de Application Gateway-instantie. Azure Firewall ook SNAT's bij het uitvoeren van DNAT. Zie Azure Firewall bekende problemen voor meer informatie:
   • Bron-IP-adres: 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 verwerkt en een van de back-endservers. Het oorspronkelijke IP-adres van de client bevindt zich 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, waarbij bron- en doel-IP-adressen worden omgedraaid:
   • Bron-IP-adres: 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 .7, ziet Azure Firewall het interne IP-adres van de Application Gateway .4 als het 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 maken en de client antwoorden:
   • Bron-IP-adres: AzFwPIP
   • Doel-IP-adres: ClientPIP

Zelfs als de Application Gateway geen listeners heeft geconfigureerd voor toepassingen, heeft het nog steeds een openbaar IP-adres nodig, zodat Microsoft het kan beheren.

On-premises clients

De voorgaande ontwerpen tonen allemaal toepassingsclients 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 internetclients, maar er zijn enkele belangrijke verschillen:

• Een VPN-gateway of ExpressRoute-gateway bevindt zich vóór 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 UDR's gebruiken om binnenkomend verkeer naar Azure Firewall te verzenden vanuit de VPN- of ExpressRoute-gateways.
• Zorg ervoor dat u de opmerkingen over geforceerde tunneling controleert voor de Azure Application Gateway en voor de Azure Firewall. Zelfs als uw workload geen uitgaande connectiviteit met het openbare internet nodig heeft, kunt u geen standaardroute invoeren, zoals 0.0.0.0/0 voor de Application Gateway die naar het on-premises netwerk verwijst, of u onderbreekt het verkeer. Voor Azure Application Gateway moet de standaardroute verwijzen naar het openbare internet.

Architectuur

In het volgende diagram ziet u de Azure Application Gateway en Azure Firewall parallelle ontwerp. Toepassingsclients 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, moeten 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 hub-virtueel netwerk maken verbinding met toepassingen in afzonderlijke virtuele spoke-netwerken via peerings voor virtuele netwerken.

Architectuur

Overwegingen

Enkele overwegingen voor deze topologie zijn:

• De Azure Firewall wordt geïmplementeerd in het virtuele netwerk van de centrale hub. In het bovenstaande diagram ziet u de praktijk van het implementeren van de Application Gateway in de hub. Toepassingsteams beheren echter vaak onderdelen zoals Azure-toepassing-gateways of Azure API Management-gateways. In dit geval worden deze onderdelen geïmplementeerd in de virtuele spoke-netwerken.
• Let vooral op UDR's in de spoke-netwerken: wanneer een toepassingsserver in een spoke verkeer ontvangt van een specifiek Azure Firewall exemplaar, zoals het 192.168.100.7 adres in de vorige voorbeelden, moet het retourverkeer terugsturen naar hetzelfde exemplaar. Als een UDR in de spoke de volgende hop van verkeer naar de hub naar het Azure Firewall IP-adres (192.168.100.4in de bovenstaande diagrammen) instelt, kunnen retourpakketten op een ander Azure Firewall exemplaar terechtkomen, waardoor asymmetrische routering wordt veroorzaakt. Zorg ervoor dat als u UDR's in de spoke-VNets hebt voor het verzenden van verkeer naar gedeelde services in de hub via de Azure Firewall, deze UDR's niet het voorvoegsel van het Azure Firewall subnet bevatten.
• De vorige aanbeveling is evenzeer van toepassing op het Application Gateway subnet en alle andere virtuele netwerkapparaten of omgekeerde proxy's die in het hub-VNet kunnen worden geïmplementeerd.
• U kunt de volgende hop niet instellen voor de Application Gateway of Azure Firewall subnetten via statische routes met een volgend hoptype.Virtual Network Dit type volgende hop is alleen geldig in het lokale VNet en niet in VNet-peerings. Zie Virtuele netwerkverkeersroutering voor meer informatie over door de gebruiker gedefinieerde routes en volgende hoptypen.

Asymmetrisch routeren

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

Om dit probleem op te lossen, definieert u UDR's in de spoke zonder het Azure Firewall subnet, maar met alleen de subnetten waarin de gedeelde services zich bevinden. In het voorbeeld mag de juiste UDR in de spoke alleen 192.168.1.0/24 bevatten. Het mag niet de hele 192.168.0.0/16 bevatten, zoals rood aangegeven.

Integratie met andere Azure-producten

U kunt 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. Het integreren van een API Management-gateway heeft geen grote invloed op de ontwerpen. Het belangrijkste verschil is dat er in plaats van de enkele Application Gateway omgekeerde proxy 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 de API-gateways voor microservices met een toepassingspatroon voor meer informatie.

Azure Kubernetes Service

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

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

Wanneer u Application Gateway en Azure Firewall combineert om een AKS-cluster te beveiligen, kunt u het beste de optie voor parallel ontwerpen gebruiken. De Application Gateway met WAF verwerkt inkomende verbindingsaanvragen voor webtoepassingen in het cluster. Azure Firewall staat alleen expliciet toegestane uitgaande verbindingen toe. Zie Basislijnarchitectuur voor een AKS-cluster (Azure Kubernetes Service) voor een voorbeeld van de optie voor parallel ontwerpen.

Azure Front Door

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

Soms kunt u het ontwerp van virtuele netwerken vereenvoudigen door Application Gateway te 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 te plaatsen.

Een interessant gebruiksvoorbeeld is het gebruik van Azure Firewall vóór Application Gateway in uw virtuele netwerk. Zoals eerder beschreven, bevat de X-Forwarded-For header die wordt geïnjecteerd door de Application Gateway het IP-adres van het firewallexemplaren, niet het 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 X-Forwarded-For te injecteren voordat het verkeer het virtuele netwerk binnenkomt en de Azure Firewall bereikt. Een tweede optie is om uw origin te beveiligen met Private Link in Azure Front Door Premium.

Zie Veelgestelde vragen over Azure Front Door voor meer informatie over de verschillen tussen de twee services of wanneer u elk van deze services moet gebruiken.

Andere virtuele netwerkapparaten

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

• Partner-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 NVA's (zoals Application Gateway en Azure Firewall) verminderen de complexiteit in vergelijking met NVA's waar gebruikers schaalbaarheid en tolerantie op veel apparaten moeten verwerken.
• Wanneer u NVA's in Azure gebruikt, gebruikt u instellingen voor actief-actief en automatisch schalen , zodat deze apparaten geen knelpunt vormen voor toepassingen die worden uitgevoerd in het virtuele netwerk.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.

Hoofdauteur:

• Jose Moreno | Principal Customer Engineer

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 resources

Verken gerelateerde architecturen:

• Veilig hybride netwerk implementeren
• Veilig beheerde webtoepassingen
• Uw Microsoft Teams-kanaalbot en web-app achter een firewall beveiligen
• Portal voor consumentenstatus 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)