Firewall en Application Gateway voor virtuele netwerken

Voor het beveiligen van Azure-toepassingsworkloads moet u beschermende maatregelen gebruiken, zoals verificatie en versleuteling, in de toepassingen zelf. 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 die eindpunten die uw toepassing nodig heeft. In dit artikel worden azure Virtual Network-beveiligingsservices beschreven, zoals Azure DDoS Protection, Azure Firewall en Azure-toepassing Gateway, wanneer u elke service gebruikt en opties voor netwerkontwerp die beide combineren.

• Azure DDoS Protection, gecombineerd met best practices voor toepassingsontwerp, biedt verbeterde DDoS-risicobeperkingsfuncties om meer bescherming te bieden tegen DDoS-aanvallen. Schakel Azure DDOS Protection in voor elk virtueel perimeternetwerk.
• Azure Firewall is een beheerde firewall van de volgende generatie die NETWORK Address Translation (NAT) 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-toepassing Gateway is een load balancer voor beheerd webverkeer en volledige omgekeerde proxy (HTTP(S) die SSL-versleuteling (Secure Socket Layer) en ontsleuteling kunnen uitvoeren. Application Gateway behoudt het oorspronkelijke CLIENT-IP-adres 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 Application Gateway-documentatie voor meer informatie.
• Azure Web Application Firewall (WAF) is een optionele toevoeging aan Azure-toepassing Gateway. Het biedt inspectie van HTTP-aanvragen en voorkomt schadelijke aanvallen op de weblaag, zoals SQL-injectie of scripting op meerdere sites. Zie de documentatie van Web Application Firewall voor meer informatie.

Deze Azure-services zijn complementair. Een of de andere kan het beste zijn voor uw workloads of u kunt ze samen gebruiken voor optimale beveiliging op zowel de netwerk- als 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-toepassing Gateway gebruiken verschillende technologieën en 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 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 aanbevolen ontwerpen van het stroomdiagram behandeld en andere die van toepassing zijn in minder gangbare scenario's:

• Alleen Azure Firewall wanneer er geen webtoepassingen in het virtuele netwerk aanwezig zijn. 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 functionaliteiten van Azure Firewall kunnen veel aanvalsscenario's voorkomen (zoals gegevensexfiltratie, IDPS, enzovoort). Daarom wordt het scenario alleen van Application Gateway niet aanbevolen en daarom niet gedocumenteerd en bevindt het bovenstaande stroomdiagram zich niet in het bovenstaande stroomdiagram.
• Azure Firewall en Application Gateway parallel, een van de meest voorkomende ontwerpen. Gebruik deze combinatie als u wilt dat Azure-toepassing Gateway HTTP(S)-toepassingen beveiligt tegen webaanvallen en Azure Firewall om alle andere workloads te beveiligen en uitgaand verkeer te filteren.
• Application Gateway vóó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 bereikt. Omdat 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 toepassingsclients.
• Hub- en spoke-netwerken.
• AKS-implementaties (Azure Kubernetes Service).

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 in dit geval is eenvoudig, maar door de pakketstroom te bekijken, krijgt u meer inzicht in complexere ontwerpen. In dit ontwerp wordt al het binnenkomende verkeer via door de gebruiker gedefinieerde routes (UDR's) naar de Azure Firewall verzonden voor verbindingen vanaf on-premises of andere Azure-VNets. Het adres is gericht op het openbare IP-adres van 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:

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

• Azure Firewall Standard inspecteert alleen laag 3 - en laag 4-kenmerken van de pakketten in netwerkregels en de HTTP-hostheader 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 diepere pakketanalyse. Azure Firewall is niet gelijk aan een Web Application Firewall. Als u webworkloads in uw virtuele netwerk hebt, wordt het gebruik van WAF ten zeerste aanbevolen.

In het volgende voorbeeld van een pakketwandeling ziet u hoe een client toegang heeft tot een door een VM gehoste toepassing vanaf het openbare internet. Het diagram bevat slechts één virtuele machine om het eenvoudig te maken. Voor 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 subnet-VM van de toepassing met behulp van de UDR.

• De Azure Firewall-service implementeert verschillende exemplaren onder de dekking, 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 het verschil is in sommige gevallen handig, bijvoorbeeld bij het oplossen van netwerkproblemen.
• Als verkeer afkomstig is van een on-premises VPN (virtueel particulier netwerk) of Een 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 gestart en de firewall voert geen bron-NAT standaard uit.

Architectuur

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

Workflow

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 voor het openbare IP-adres van Azure Firewall wordt gedistribueerd naar een back-endinstantie van de firewall, in dit geval 192.168.100.7. De AZURE Firewall Destination NAT-regel (DNAT) vertaalt het doel-IP-adres naar het IP-adres van de toepassing in het virtuele netwerk. De Azure Firewall bron-NAT's (SNATs) van het pakket als het DNAT doet. Zie bekende problemen met 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 toepassingsaanvraag, waarbij de 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 van Azure Firewall het IP-adres is. De UDR in het diagram voor 0.0.0.0.0/0 is bedoeld 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 maakt Azure Firewall de SNAT- en DNAT-bewerkingen ongedaan en levert het antwoord op de client:
   • Ip-adres van bron: AzFwPIP
   • Doel-IP-adres: ClientPIP

Alleen Application Gateway

Dit ontwerp behandelt 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 application gateway niet als routeringsapparaat met NAT fungeert. Het gedraagt zich als een volledige omgekeerde toepassingsproxy. Dat wil gezegd, Application Gateway stopt de websessie van de client en brengt een afzonderlijke sessie tot stand 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 van de gateway. Retourverkeer van de Azure-VM's volgt standaard-VNet-routering terug naar de Application Gateway (zie de stapsgewijze instructies voor het pakket 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 een pakketwandeling ziet u hoe een client toegang heeft tot de door de VM gehoste toepassing vanaf het openbare internet.

Workflow

1. De client start de verbinding met het openbare IP-adres van de Azure-toepassing-gateway:
   • Bron-IP-adres: ClientPIP
   • Doel-IP-adres: AppGwPIP
2. De aanvraag voor het openbare IP-adres van Application Gateway wordt gedistribueerd naar een back-endinstantie 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 CLIENT-IP-adres.
   • 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 toepassingsaanvraag, waarbij de bron- en doel-IP-adressen worden omgedraaid. De VIRTUELE machine weet al hoe de Application Gateway kan worden bereikt, dus u hebt 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-toepassing Gateway metagegevens toevoegt 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-toepassing Gateway-service onder de dekking implementeert, hier met het interne, privé-front-end-IP-adres192.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 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 parallel uitvoeren van Application Gateway en Azure Firewall vaak het beste scenario.

Implementeer dit ontwerp als er een combinatie is van web- en niet-webworkloads in het virtuele netwerk. Azure WAF in Azure-toepassing Gateway beveiligt binnenkomend verkeer naar de webworkloads en de Azure Firewall inspecteert binnenkomend verkeer voor de andere toepassingen. De Azure Firewall behandelt uitgaande stromen van beide workloadtypen.

Binnenkomende HTTP(S)-verbindingen vanaf 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 de stapsgewijze instructies voor meer informatie). Voor binnenkomende niet-HTTP(S)-verbindingen moet verkeer gericht zijn op het openbare IP-adres van de Azure Firewall (als dit 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 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 filters dan NSG's. Als toepassingen bijvoorbeeld verbinding nodig hebben met een specifiek 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. Dat scenario kan niet worden voorkomen door gebruik te maken van NSG's. Dit ontwerp wordt vaak gebruikt waarbij uitgaand verkeer FQDN-filtering vereist. Een voorbeeldsituatie is wanneer uitgaand verkeer van een Azure Kubernetes Services-cluster wordt beperkt.

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 is om verbinding te maken met back-endsystemen of besturingssysteemupdates op te halen:

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

Application Gateway vóór Firewall

Dit ontwerp wordt in meer detail uitgelegd in zero-trust-netwerk voor webtoepassingen met Azure Firewall en Application Gateway. Dit document is gericht op de vergelijking met de andere ontwerpopties. In deze topologie gaat binnenkomend webverkeer via zowel Azure Firewall als WAF. De WAF biedt beveiliging op de laag van de webtoepassing. Azure Firewall fungeert als een centraal logboek- en controlepunt en inspecteert verkeer tussen de Application Gateway en de back-endservers. De Application Gateway en Azure Firewall zitten niet parallel, maar één na de andere.

Met Azure Firewall Premium kan dit ontwerp end-to-end-scenario's ondersteunen, waarbij TLS-inspectie wordt toegepast door azure Firewall om IDPS uit te voeren op het versleutelde verkeer tussen de Application Gateway en de webback-end.

Dit ontwerp is geschikt voor toepassingen die ip-adressen van binnenkomende clientbronnen 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 door X doorgestuurde 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. Vanuit de Application Gateway UDR's zorgt u ervoor dat de pakketten worden gerouteerd via de Azure Firewall (zie de stapsgewijze instructies voor het pakket voor meer informatie). Voor binnenkomende niet-HTTP(S)-verbindingen moet verkeer gericht zijn op het openbare IP-adres van de Azure Firewall (als dit 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 door UDR's doorgestuurd naar de Azure Firewall.

Een belangrijke opmerking van dit ontwerp is dat Azure Firewall Premium verkeer ziet met een bron-IP-adres van het Application Gateway-subnet. Als dit subnet is geconfigureerd met een privé-IP-adres (in 10.0.0.0/8, 172.16.0.0/12 192.168.0.0/16of100.64.0.0/10), behandelt Azure Firewall Premium verkeer van application gateway als intern en past geen IDPS-regels toe voor inkomend verkeer. Meer informatie over de routebeschrijvingen voor azure Firewall IDPS-regels en privé-IP-voorvoegsels voor IDPS vindt u in Azure Firewall IDPS-regels. Daarom wordt aanbevolen om de privé-IDPS-voorvoegsels in het Azure Firewall-beleid te wijzigen, zodat het Application Gateway-subnet niet wordt beschouwd als een interne bron, om binnenkomende en uitgaande IDPS-handtekeningen toe te passen op het verkeer.

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 application Gateway back-endverkeer versleutelt (verkeer van de Application Gateway naar de toepassingsservers), hebt u verschillende mogelijke scenario's:

1. Application Gateway versleutelt verkeer volgens nulvertrouwensprincipes (end-to-end TLS-versleuteling) en de Azure Firewall ontvangt versleuteld verkeer. Azure Firewall Standard kan nog steeds inspectieregels toepassen, zoals laag 3 en 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 TLS-inspectie, 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 duidelijke 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 dat doel heeft deze naamomzetting nodig voor de FQDN die is opgegeven in de hostheader. Deze naamomzetting kan worden bereikt met azure DNS-privézones en de standaardinstellingen voor Azure Firewall DNS met behulp van Azure DNS. Het kan ook worden bereikt met aangepaste DNS-servers die moeten worden geconfigureerd in de Azure Firewall-instellingen. (Zie voor meer informatie Azure Firewall DNS-Instellingen.) Als er geen beheerderstoegang is tot het virtuele netwerk waar de Azure Firewall is geïmplementeerd, is de laatste methode de enige mogelijkheid. Een voorbeeld hiervan is azure Firewalls die zijn geïmplementeerd in met Virtual WAN beveiligde hubs.

Architectuur

Voor de rest van de stromen (binnenkomend 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.

Workflow

Netwerkverkeer van het openbare internet volgt deze stroom:

1. De client start de verbinding met het openbare IP-adres van de Azure-toepassing-gateway:
   • Bron-IP-adres: ClientPIP
   • Doel-IP-adres: AppGwPIP
2. De aanvraag voor het openbare IP-adres van Application Gateway wordt gedistribueerd naar een back-endinstantie van de gateway, in dit geval 192.168.200.7. Het Application Gateway-exemplaar stopt de verbinding van 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 behouden blijft 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 biedt geen SNAT-verkeer, omdat het verkeer naar een privé-IP-adres gaat. Het verkeer wordt doorgestuurd naar de toepassings-VM als regels dit toestaan. Zie Azure Firewall SNAT voor meer informatie. Als het verkeer echter een toepassingsregel in de firewall bereikt, ziet de workload het bron-IP-adres van het specifieke firewallexemplaren dat het pakket heeft verwerkt, omdat de Azure Firewall de verbinding zal proxyen:
   • 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 de bron- en doel-IP-adressen worden omgedraaid. De UDR voor 192.168.200.0/24 het vastleggen van het pakket dat wordt teruggestuurd naar de Application Gateway en deze omleidt naar Azure Firewall, terwijl het doel-IP-adres naar de Toepassingsgateway behouden blijft.
   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7
5. Hier wordt het verkeer van Azure Firewall niet door de Azure Firewall, omdat het naar een privé-IP-adres gaat en het verkeer doorstuurt naar de Toepassingsgateway.
   • Bron-IP-adres: 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 kan Azure Firewall schadelijk verkeer filteren en negeren 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 inkomend als uitgaand verkeer, ongeacht protocol. Azure Firewall-SNATs echter het binnenkomende verkeer, zodat de toepassing geen inzicht heeft in het oorspronkelijke IP-adres van de HTTP-aanvragen. Vanuit het oogpunt van beheer, bijvoorbeeld voor probleemoplossingsdoeleinden, kunt u het werkelijke IP-adres van de client voor een specifieke verbinding verkrijgen door deze te correleren met de SNAT-logboeken van de Azure Firewall.

In dit scenario is er een beperkt voordeel, omdat Azure Firewall alleen versleuteld verkeer ziet dat naar de Application Gateway gaat. Er kunnen scenario's zijn waarin dit ontwerp de voorkeur heeft. Een geval is als een andere WAF eerder in het netwerk staat (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 veel openbare IP-adressen vereist zijn.

Binnenkomende HTTP(S)-stromen van het openbare internet moeten gericht zijn op het openbare IP-adres van de Azure Firewall en de Azure Firewall zal dnat (en SNAT) van 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 de Application Gateway en worden doorgestuurd via de Azure Firewall met UDR's. Standaard-VNet-routering zorgt ervoor dat verkeer 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 stapsgewijze instructies voor het pakket voor meer informatie). Al het uitgaande verkeer van de Virtuele Azure-machines naar internet wordt verzonden via de Azure Firewall door UDR's.

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

Voor binnenkomend HTTP(S)-verkeer zou de Azure Firewall doorgaans geen verkeer ontsleutelen. In plaats daarvan past het IDPS-beleid toe waarvoor GEEN TLS-inspectie 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-SNATs de pakketten wanneer ze binnenkomen in het virtuele netwerk. Gebruik Azure Front Door vóór de firewall om dit probleem te voorkomen. Azure Front Door injecteert het IP-adres van de client als een HTTP-header voordat het het virtuele Azure-netwerk binnenkomt.

Workflow

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 voor het openbare IP-adres van Azure Firewall wordt gedistribueerd naar een back-endinstantie van de firewall, in dit geval 192.168.100.7. De Azure Firewall DNATs van de webpoort, meestal TCP 443, naar het privé-IP-adres van het Application Gateway-exemplaar. Azure Firewall biedt ook SNAT's bij het uitvoeren van DNAT. Zie bekende problemen met Azure Firewall 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. Application Gateway reageert 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 bron-IP:
   • Bron-IP-adres: 192.168.200.4
   • Doel-IP-adres: 192.168.100.7
6. Ten slotte wordt SNAT en DNAT ongedaan gemaakt door Azure Firewall en wordt de client beantwoord:
   • Ip-adres van bron: AzFwPIP
   • Doel-IP-adres: ClientPIP

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

On-premises clients

De voorgaande ontwerpen tonen alle 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 voor Azure Firewall of Application Gateway.
• WAF maakt gebruik van 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 vanaf de VPN- of ExpressRoute-gateways.
• Zorg ervoor dat u twijfelt over geforceerde tunneling voor de Azure-toepassing Gateway en voor de Azure Firewall. Zelfs als uw workload geen uitgaande connectiviteit met het openbare internet nodig heeft, kunt u geen standaardroute injecteren, zoals 0.0.0.0/0 voor de Toepassingsgateway die verwijst naar het on-premises netwerk, of u breekt het controleverkeer. Voor Azure-toepassing Gateway moet de standaardroute verwijzen naar het openbare internet.

Architectuur

In het volgende diagram ziet u het parallelle ontwerp van Azure-toepassing Gateway en Azure Firewall. 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-toepassing Gateway en Azure Firewall beide openbare IP-adressen hebben. Met de openbare IP-adressen kan Microsoft de services beheren.

Stertopologie

De ontwerpen in dit artikel zijn nog steeds van toepassing op een stertopologie . 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 hoe u Application Gateway implementeert in de hub. Toepassingsteams beheren 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 instelt dat is geadresseerd aan de hub naar het IP-adres van de Azure Firewall (192.168.100.4 in de bovenstaande diagrammen), kunnen retourpakketten terechtkomen op een ander Azure Firewall-exemplaar, wat asymmetrische routering veroorzaakt. Zorg ervoor dat als u UDR's in de spoke-VNets hebt om verkeer te verzenden naar gedeelde services in de hub via de Azure Firewall, deze UDR's het voorvoegsel van het Azure Firewall-subnet niet bevatten.
• De vorige aanbeveling is evenzeer van toepassing op het Application Gateway-subnet en eventuele andere virtuele netwerkapparaten of omgekeerde proxy's die kunnen worden geïmplementeerd in het hub-VNet.
• U kunt de volgende hop voor de Application Gateway- of Azure Firewall-subnetten niet instellen via statische routes met een volgend hoptype Virtual Network. Dit volgende hoptype is alleen geldig in het lokale VNet en niet in VNet-peerings. Zie Routebeschrijving voor virtueel netwerkverkeer voor meer informatie over door de gebruiker gedefinieerde routes en volgende hoptypen.

Asymmetrische routering

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 alleen met 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. Het mag niet de hele 192.168.0.0/16 bevatten, zoals rood gemarkeerd.

Integratie met andere Azure-producten

U kunt Azure Firewall en Azure-toepassing 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 een API Management-gateway verandert de ontwerpen niet sterk. Het belangrijkste verschil is dat in plaats van de omgekeerde proxy van Application Gateway twee omgekeerde proxy's achter elkaar zijn gekoppeld.

Zie de ontwerphandleiding voor het integreren van API Management en Application Gateway in een virtueel netwerk en de API-gateways voor toepassingspatronen voor Microservices voor meer informatie.

Azure Kubernetes Service

Voor workloads die worden uitgevoerd op een AKS-cluster, kunt u Azure-toepassing Gateway onafhankelijk van het cluster implementeren. U kunt het ook integreren met het AKS-cluster met behulp van de Azure-toepassing Gateway-ingangscontroller. Bij het configureren van bepaalde objecten op kubernetes-niveaus (zoals services en ingresses), past Application Gateway zich automatisch aan 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 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 parallel ontwerpen gebruiken. Application Gateway met WAF verwerkt binnenkomende 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 parallel ontwerpen.

Azure Front Door

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

Soms kunt u het ontwerp van een virtueel netwerk vereenvoudigen door Application Gateway te vervangen door een gedecentraliseerd 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 interessante use-case is het gebruik van Azure Firewall vóór Application Gateway in uw virtuele netwerk. Zoals eerder beschreven, bevat de X-Forwarded-For header die door de Application Gateway is geïnjecteerd, 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 deze services wilt 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 afhandelen.
• Wanneer u NVA's in Azure gebruikt, gebruikt u setups voor actief-actief en automatisch schalen , zodat deze apparaten geen knelpunt vormen voor toepassingen die in het virtuele netwerk worden uitgevoerd.

Medewerkers

Dit artikel wordt onderhouden door Microsoft. De tekst is oorspronkelijk geschreven door de volgende Inzenders.

Hoofdauteur:

• Jose Moreno | Principal Customer Engineer

Volgende stappen

Meer informatie over de onderdeeltechnologieën:

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

Verwante resources

Gerelateerde architecturen verkennen:

• Een beveiligd hybride netwerk implementeren
• Veilig beheerde webtoepassingen
• Uw Microsoft Teams-kanaalbot en web-app beveiligen achter een firewall
• Portal voor consumentenstatus in Azure
• Beveiligingsoverwegingen voor zeer gevoelige IaaS-apps in Azure
• Multitenant SaaS in Azure
• Bedrijfsimplementatie met behulp van App Services Environment
• Bedrijfsimplementatie met hoge beschikbaarheid met Behulp van App Services Environment
• Basislijnarchitectuur voor een AKS-cluster (Azure Kubernetes Service)