Azure Firewall en Application Gateway voor virtuele netwerken

Gebruik beschermende maatregelen zoals verificatie en versleuteling in de toepassingen zelf om workloads van Azure-toepassingen te beveiligen. U kunt beveiligingslagen toevoegen aan de virtuele netwerken waarop de toepassingen worden gehost. Deze beveiligingslagen helpen de binnenkomende stromen van de toepassing te beschermen tegen onbedoeld gebruik. Ze beperken ook uitgaande stromen naar internet tot alleen de eindpunten die uw toepassing nodig heeft. In dit artikel wordt beschreven Azure Virtual Network beveiligingsservices zoals Azure DDoS Protection, Azure Firewall en Azure Application Gateway. Ook wordt beschreven wanneer u elke service en netwerkontwerpopties gebruikt die deze combineren.

• DDoS Protection, gecombineerd met best practices voor toepassingsontwerp, biedt verbeterde DDoS-risicobeperkingsfuncties die de verdediging tegen DDoS-aanvallen verbeteren. Schakel DDoS Protection in op elk virtueel perimeternetwerk.

• Azure Firewall- is een beheerde firewall van de volgende generatie die nat- mogelijkheden (Network Address Translation) biedt. Azure Firewall filtert pakketten op basis van IP-adressen en TCP-poorten (Transmission Control Protocol) of UDP-poorten (User Datagram Protocol). Het kan verkeer filteren met behulp van op toepassingen gebaseerde kenmerken, zoals HTTP(S) en SQL. Azure Firewall past ook bedreigingsinformatie van Microsoft toe om schadelijke IP-adressen te identificeren. Zie Azure Firewall-documentatievoor meer informatie.

• Azure Firewall Premium- bevat alle functionaliteit van Azure Firewall Standard, naast functies zoals TLS-inspectie (Transport Layer Security) en inbraakdetectie en preventiesysteem (IDPS).

• Application Gateway is een load balancer voor beheerd webverkeer en volledige omgekeerde HTTP(S) proxy waarmee SSL-versleuteling (Secure Socket Layer) en ontsleuteling kunnen worden uitgevoerd. Application Gateway behoudt het oorspronkelijke IP-adres van de client in een X-Forwarded-For HTTP-header. Application Gateway maakt ook gebruik van Azure Web Application Firewall om webverkeer te inspecteren en aanvallen op de HTTP-laag te detecteren. Zie Application Gateway-documentatievoor meer informatie.

• Web Application Firewall- is een optionele toevoeging aan Application Gateway. Het inspecteert HTTP-aanvragen en voorkomt aanvallen op de weblaag, zoals SQL-injectie en cross-site scripting. Zie Web Application Firewall-documentatievoor meer informatie.

Deze Azure-services vullen elkaar aan. Afhankelijk van uw behoeften kan het gebruik van één service beter aansluiten bij uw workloads. U kunt deze services echter samen gebruiken om optimale beveiliging te bieden 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 kiezen.

Azure Firewall en Application Gateway gebruiken verschillende technologieën om verschillende typen gegevensstromen te beveiligen.

Het ontwerp kan per toepassing variëren op basis van de netwerkstromen die hiervoor nodig zijn. Het volgende diagram biedt een vereenvoudigde beslissingsstructuur waarmee u de aanbevolen benadering voor uw toepassing kunt kiezen. Deze keuze is afhankelijk van of de toepassing wordt gepubliceerd via HTTP(S) of een ander protocol.

In dit artikel worden de algemeen aanbevolen ontwerpen beschreven die worden weergegeven in het stroomdiagram en ontwerpen die geschikt zijn voor minder algemene scenario's:

• Azure Firewall alleen: Gebruik dit ontwerp wanneer er geen webtoepassingen in het virtuele netwerk zijn. Het regelt zowel inkomend verkeer naar de toepassingen als uitgaand verkeer.

• Application Gateway alleen: Gebruik dit ontwerp wanneer alleen webtoepassingen zich in het virtuele netwerk bevinden en netwerkbeveiligingsgroepen (NSG's) voldoende uitvoerfilters bieden. Azure Firewall biedt functionaliteit die kan helpen bij het voorkomen van verschillende aanvalsscenario's, zoals gegevensexfiltratie en IDPS. Als gevolg hiervan wordt het ontwerp alleen voor Application Gateway meestal niet aanbevolen, dus het is niet opgenomen in het vorige stroomdiagram.

• Azure Firewall en Application Gateway parallel: Gebruik dit ontwerp als u wilt dat HTTP(S)-toepassingen worden beveiligd tegen webaanvallen en Azure Firewall om alle andere workloads te beveiligen en uitgaand verkeer te filteren. Azure Firewall en Application Gateway zijn parallel ontworpen.

• Application Gateway vóór Azure Firewall: Gebruik dit ontwerp als u wilt dat Azure Firewall al het verkeer controleert, Web Application Firewall om webverkeer te beveiligen en de toepassing om het bron-IP-adres van de client te identificeren. Met Azure Firewall Premium- en TLS-inspectie ondersteunt dit ontwerp ook het end-to-end SSL-scenario.

• Azure Firewall vóór Application Gateway: Gebruik dit ontwerp als u wilt dat Azure Firewall verkeer inspecteert en filtert voordat het de Application Gateway bereikt. Omdat Azure Firewall HTTPS-verkeer niet ontsleutelt, is de toegevoegde functionaliteit voor application gateway beperkt. Dit scenario wordt niet gedocumenteerd in het vorige stroomdiagram.

Variaties van deze fundamentele ontwerpen worden verderop in dit artikel beschreven en omvatten:

• on-premises toepassingsclients.
• hub-and-spoke-netwerken.
• Azure Kubernetes Service (AKS) implementaties.

U kunt andere omgekeerde proxyservices toevoegen, zoals een Azure API Management-gateway of Azure Front Door-. U kunt de Azure-resources ook vervangen door niet-Microsoft virtuele netwerkapparaten (NVA's).

Ontwerp met alleen Azure Firewall

Als er geen webworkloads in het virtuele netwerk zijn die kunnen profiteren van Web Application Firewall, kunt u het azure Firewall-ontwerp gebruiken. Het ontwerp in dit voorbeeld is eenvoudig, maar u kunt de pakketstroom bekijken om complexere ontwerpen beter te begrijpen. In dit ontwerp wordt al het binnenkomende verkeer via door de gebruiker gedefinieerde routes (UDR's) naar Azure Firewall verzonden voor verbindingen vanuit on-premises of andere virtuele Azure-netwerken. Het adres is gericht op het openbare IP-adres van Azure Firewall voor verbindingen vanaf het openbare internet, zoals wordt weergegeven in het volgende diagram. UDR's leiden uitgaand verkeer van virtuele Azure-netwerken naar Azure Firewall, zoals wordt weergegeven in het volgende dialoogvenster.

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

Azure Firewall inspecteert geen inkomend HTTP(S)-verkeer. Maar het kan regels op basis van laag 3 en laag 4 en volledig gekwalificeerde domeinnaam (FQDN) toepassen op basis van toepassingsregels. 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 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 gebruikersagent) en het inschakelen van TLS-inspectie voor diepere pakketanalyse. Azure Firewall is echter niet hetzelfde als Web Application Firewall. Als u webworkloads in uw virtuele netwerk hebt, raden we u aan Web Application Firewall te gebruiken.

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 bevinden zich meerdere toepassingsexemplaren achter een load balancer. In dit ontwerp inspecteert Azure Firewall binnenkomende verbindingen vanaf het openbare internet en uitgaande verbindingen van de toepassingssubnet-VM met behulp van de UDR.

• In dit voorbeeld implementeert Azure Firewall automatisch verschillende exemplaren met het front-end-IP-adres 192.168.100.4 en interne adressen binnen het bereik 192.168.100.0/26. Normaal gesproken zijn deze exemplaren niet zichtbaar voor de Azure-beheerder. Het kan echter handig zijn om netwerkproblemen op te lossen.

• 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 virtuele machine. 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 en wordt ervan uitgegaan dat het IP-adres van het exemplaar 192.168.100.7is.

Werkstroom

1. De client start de verbinding met het openbare IP-adres van 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-endexemplaren van de firewall. Dit is 192.168.100.7 in dit voorbeeld. De AZURE Firewall DNAT-regel (Destination Network Address Translation) het doel-IP-adres vertaalt naar het IP-adres van de toepassing in het virtuele netwerk. Azure Firewall implementeert ook SNAT- (Source Network Address Translation) op het pakket als deze GEBRUIKMAAKT van DNAT. Zie bekende problemen met Azure Firewallvoor 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, waardoor zowel de bron- als de doel-IP-adressen worden omgekeerd. Voor de binnenkomende stroom is geen UDR vereist omdat het bron-IP-adres het IP-adres van de Azure Firewall is. De UDR in het diagram voor 0.0.0.0/0 is bedoeld voor uitgaande verbindingen om ervoor te zorgen dat pakketten naar het openbare internet via Azure Firewall gaan.

   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.100.7

4. Azure Firewall maakt de SNAT- en DNAT-bewerkingen ongedaan en levert het antwoord op de client.

   • Bron-IP-adres: AzFwPIP
   • Doel-IP-adres: ClientPIP

Alleen-toepassingsontwerp

In dit ontwerp wordt het scenario beschreven waarin alleen webtoepassingen aanwezig zijn in het virtuele netwerk en het controleren van uitgaand verkeer met NSG's voldoende is om uitgaande stromen naar internet te beveiligen.

Het belangrijkste verschil met het vorige azure Firewall-ontwerp is dat Application Gateway niet fungeert als routeringsapparaat met NAT. In plaats daarvan werkt het als een volledige omgekeerde toepassingsproxy. Deze methode betekent dat Application Gateway de websessie van de client stopt en een afzonderlijke sessie tot stand brengt met een van de back-endservers. Binnenkomende HTTP(S)-verbindingen van internet worden verzonden naar het openbare IP-adres van Application Gateway en verbindingen van Azure of on-premises maken gebruik van het privé-IP-adres van de gateway. Retourverkeer van de Virtuele Azure-machines volgt standaardroutering van virtuele netwerken naar Application Gateway. Zie de pakketwandeling verderop in dit artikel 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.

Werkstroom

1. De client start de verbinding met het openbare IP-adres van Application 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-endexemplaren van de gateway. Dit is 192.168.200.7 in dit voorbeeld. 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. Application Gateway voegt een X-Forwarded-For HTTP-header in met het IP-adres van de oorspronkelijke client.

   • Bron-IP-adres, het privé-IP-adres van het Application Gateway-exemplaar: 192.168.200.7
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For koptekst: ClientPIP

3. De VM beantwoordt de toepassingsaanvraag en keert zowel de bron- als doel-IP-adressen om. De VM kan Application Gateway bereiken, zodat er geen UDR nodig is.

   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7

4. Het Application Gateway-exemplaar beantwoordt de client.

   • Bron-IP-adres: AppGwPIP
   • Doel-IP-adres: ClientPIP

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 werktvoor meer informatie.

• In dit voorbeeld is het IP-adres 192.168.200.7 een van de exemplaren die automatisch door de Application Gateway-service zijn geïmplementeerd. Het heeft het interne, privé-front-end-IP-adres 192.168.200.4. Deze afzonderlijke exemplaren zijn normaal gesproken onzichtbaar voor de Azure-beheerder. Maar het verschil kan nuttig zijn, bijvoorbeeld wanneer u netwerkproblemen oplost.

• 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 Application Gateway in plaats van het openbare IP-adres.

Azure Firewall en Application Gateway parallel ontwerpen

Vanwege de eenvoud en flexibiliteit is het vaak het beste om Application Gateway en Azure Firewall parallel uit te voeren.

Implementeer dit ontwerp als het virtuele netwerk zowel web- als niet-webworkloads bevat. Web Application Firewall in Application Gateway helpt binnenkomend verkeer naar de webworkloads te beveiligen. Azure Firewall inspecteert binnenkomend verkeer voor de andere toepassingen. Azure Firewall behandelt uitgaande stromen van beide workloadtypen.

Binnenkomende HTTP(S)-verbindingen van internet moeten worden verzonden naar het openbare IP-adres van Application Gateway. HTTP(S)-verbindingen van Azure of on-premises moeten worden verzonden naar het privé-IP-adres. Standaardroutering van virtuele netwerken verzendt de pakketten van Application Gateway naar de doel-VM's en van de doel-VM's terug naar Application Gateway. Zie de pakketwandeling verderop in dit artikel voor meer informatie.

Voor binnenkomende niet-HTTP(S)-verbindingen moet verkeer zich richten op het openbare IP-adres van Azure Firewall als het afkomstig is van het openbare internet. Verkeer moet worden verzonden via Azure Firewall door UDR's als het afkomstig is van andere virtuele Azure-netwerken of on-premises netwerken. Alle uitgaande stromen van Virtuele Azure-machines worden door UDR's doorgestuurd naar Azure Firewall.

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

Dit ontwerp biedt veel gedetailleerdere uitgaande filtering dan alleen het gebruik van NSG's. Als toepassingen bijvoorbeeld verbinding nodig hebben met een specifiek Azure Storage-account, kunt u filters op basis van FQDN gebruiken. Met op FQDN gebaseerde filters verzenden toepassingen geen gegevens naar rogue opslagaccounts. Als u alleen NSG's gebruikt, kunt u dit scenario niet voorkomen. Dit ontwerp wordt vaak gebruikt wanneer uitgaand verkeer FQDN-filtering vereist. Een scenario is wanneer u uitgaand verkeer van een AKS-cluster beperken.

Platforms

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 het Azure Firewall-ontwerp

Dit ontwerp wordt in meer detail uitgelegd in Zero-trust-netwerk voor webtoepassingen met Azure Firewall en Application Gateway. Dit artikel richt zich op de vergelijking met de andere ontwerpopties. In deze topologie gaat binnenkomend webverkeer via zowel Azure Firewall als Web Application Firewall. Web Application Firewall biedt beveiliging op de laag van de webtoepassing. Azure Firewall fungeert als een centraal logboek- en controlepunt en inspecteert verkeer tussen Application Gateway en de back-endservers. In dit ontwerp zitten Application Gateway en Azure Firewall niet parallel, maar zitten ze voor de andere.

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

Dit ontwerp is geschikt voor toepassingen die ip-adressen van binnenkomende clientbronnen moeten identificeren. Het kan bijvoorbeeld worden gebruikt voor het leveren van geolocatiespecifieke inhoud of voor logboekregistratie. De Application Gateway vóór het Ontwerp van 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 werktvoor meer informatie.

Binnenkomende HTTP(S)-verbindingen van internet moeten worden verzonden naar het openbare IP-adres van Application Gateway. HTTP(S)-verbindingen van Azure of on-premises moeten worden verzonden naar het privé-IP-adres. Vanuit Application Gateway zorgen UDR's ervoor dat de pakketten worden gerouteerd via Azure Firewall. Zie de pakketwandeling verderop in dit artikel voor meer informatie.

Voor binnenkomende niet-HTTP(S)-verbindingen moet verkeer zich richten op het openbare IP-adres van Azure Firewall als het afkomstig is van het openbare internet. Verkeer moet worden verzonden via Azure Firewall door UDR's als het afkomstig is van andere virtuele Azure-netwerken of on-premises netwerken. Alle uitgaande stromen van Virtuele Azure-machines worden door UDR's doorgestuurd naar Azure Firewall.

Een belangrijk aspect van dit ontwerp is dat Azure Firewall Premium verkeer met een bron-IP-adres van het Application Gateway-subnet ziet. Als dit subnet is geconfigureerd met een privé-IP-adres (in 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12of 100.64.0.0/10), behandelt Azure Firewall Premium verkeer van Application Gateway als intern en past geen IDPS-regels toe voor inkomend verkeer. Daarom raden we u aan om de privé-voorvoegsels van IDPS in het Azure Firewall-beleid te wijzigen. Deze wijziging zorgt ervoor dat het Application Gateway-subnet niet wordt beschouwd als een interne bron, waardoor binnenkomende en uitgaande IDPS-handtekeningen op het verkeer kunnen worden toegepast. Meer informatie over de routebeschrijvingen van Azure Firewall IDPS-regels en privé-IP-voorvoegsels voor IDPS vindt u in Azure Firewall IDPS-regels.

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

Voor webverkeer van on-premises of van internet naar Azure inspecteert Azure Firewall stromen die Web Application Firewall toestaat. Afhankelijk van of Application Gateway back-endverkeer versleutelt, wat verkeer is van Application Gateway naar de toepassingsservers, kunnen er verschillende scenario's optreden:

• Application Gateway versleutelt verkeer door nulvertrouwensprincipes te volgen, zoals end-to-end TLS-versleuteling, en 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.

• Als Application Gateway niet-versleuteld verkeer naar de toepassingsservers verzendt, ziet Azure Firewall binnenkomend verkeer in duidelijke tekst. TLS-inspectie is niet nodig in Azure Firewall.

• Als IDPS is ingeschakeld in Azure Firewall, wordt gecontroleerd of de HTTP-hostheader overeenkomt met het doel-IP-adres. Om deze verificatie uit te voeren, heeft deze de naamomzetting nodig voor de FQDN die is opgegeven in de hostheader. Deze naamomzetting kan worden uitgevoerd met behulp van privézones van Azure DNS en de standaard-DNS-instellingen van Azure Firewall. Het kan ook worden bereikt met aangepaste DNS-servers die moeten worden geconfigureerd in de Azure Firewall-instellingen. Als u geen beheerderstoegang hebt tot het virtuele netwerk waar Azure Firewall is geïmplementeerd, is de laatste methode de enige optie. Een voorbeeld hiervan is azure Firewall-exemplaren die zijn geïmplementeerd in met Azure Virtual WAN beveiligde hubs.

Architectuur

Voor de rest van de stromen, waaronder binnenkomend niet-HTTP(S)-verkeer en uitgaand verkeer, biedt Azure Firewall IDPS-inspectie en TLS-inspectie, indien geschikt. 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 Application 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-endexemplaren van de gateway. Dit is 192.168.200.7 in dit voorbeeld. 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 Azure Firewall en behoudt het doel-IP-adres naar de webtoepassing.

   • Bron-IP-adres, het privé-IP-adres van het Application Gateway-exemplaar: 192.168.200.7
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For koptekst: ClientPIP

3. Azure Firewall past SNAT niet toe op het verkeer omdat het verkeer naar een privé-IP-adres gaat. Het verkeer wordt doorgestuurd naar de toepassings-VM als regels dit toestaan. Raadpleeg Azure Firewall SNAT voor privé-IP-adresbereiken voor meer informatie. Als het verkeer echter een toepassingsregel in de firewall raakt, ziet de workload het bron-IP-adres van het specifieke firewallexemplaren dat het pakket heeft verwerkt, omdat Azure Firewall de verbinding proxyt.

   • Bron-IP-adres als het verkeer is toegestaan door een Azure Firewall-netwerkregel en het privé-IP-adres is van een van de Application Gateway-exemplaren: 192.168.200.7
   • Bron-IP-adres als het verkeer is toegestaan door een Azure Firewall-toepassingsregel en het privé-IP-adres is van een van de Azure Firewall-exemplaren: 192.168.100.7
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For koptekst: ClientPIP

4. De VM beantwoordt de aanvraag, waardoor zowel de bron- als de doel-IP-adressen worden omgekeerd. De UDR voor 192.168.200.0/24 legt het pakket vast dat naar Application Gateway wordt verzonden, leidt het om naar Azure Firewall en behoudt het doel-IP-adres naar Application Gateway.

   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7

5. Azure Firewall past SNAT opnieuw niet toe op het verkeer omdat deze naar een privé-IP-adres gaat en het verkeer doorstuurt naar Application Gateway.

   • Bron-IP-adres: 192.168.1.4
   • Doel-IP-adres: 192.168.200.7

6. Het Application Gateway-exemplaar beantwoordt de client.

   • Bron-IP-adres: AppGwPIP
   • Doel-IP-adres: ClientPIP

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

Als variant van dit ontwerp kunt u privé-DNAT configureren in Azure Firewall, zodat de workload van de toepassing de IP-adressen van de Azure Firewall-exemplaren als bron ziet en er geen UDR's nodig zijn. Het bron-IP-adres van de toepassingsclients blijft al behouden in de X-Forwarded-For HTTP-header van Application Gateway. Dus als Azure Firewall DNAT toepast op het verkeer, gaan er geen gegevens verloren. Zie Binnenkomend internet- of intranetverkeer filteren met Azure Firewall policy DNAT met behulp van azure Portalvoor meer informatie.

Azure Firewall vóór het Application Gateway-ontwerp

Met dit ontwerp kan Azure Firewall schadelijk verkeer filteren en negeren voordat het 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. Er zijn drie modi waarin u Azure Firewall theoretisch kunt configureren:

• Azure Firewall met DNAT-regels: Azure Firewall alleen IP-adressen verwisselt op de IP-adreslaag, maar de nettolading wordt niet verwerkt. Als gevolg hiervan wordt geen van de HTTP-headers gewijzigd.

• Azure Firewall met toepassingsregels en TLS-inspectie uitgeschakeld: Azure Firewall kan de SNI-header in TLS bekijken, maar ontsleutelt deze niet. Er wordt een nieuwe TCP-verbinding gemaakt van de firewall naar de volgende hop. In dit voorbeeld is dit Application Gateway.

• Azure Firewall met toepassingsregels en TLS-inspectie ingeschakeld: Azure Firewall kijkt naar de inhoud van het pakket en ontsleutelt deze. Het fungeert als een HTTP-proxy en kan de HTTP-headers X-Forwarded-For instellen om het IP-adres te behouden. Er wordt echter een zelf gegenereerd certificaat aan de client gepresenteerd. Voor internettoepassingen is het gebruik van een zelf gegenereerd certificaat geen optie omdat er vanuit hun browser een beveiligingswaarschuwing naar de toepassingsclients wordt verzonden.

In de eerste twee opties, die de enige geldige opties voor internettoepassingen zijn, past Azure Firewall SNAT toe op het binnenkomende verkeer zonder de X-Forwarded-For header in te stellen. Als gevolg hiervan kan de toepassing het oorspronkelijke IP-adres van de HTTP-aanvragen niet zien. Voor beheertaken, zoals het oplossen van problemen, kunt u het werkelijke IP-adres van de client voor een specifieke verbinding verkrijgen door deze te correleren met de SNAT-logboeken van Azure Firewall.

De voordelen van dit scenario zijn beperkt omdat, tenzij u TLS-inspectie gebruikt en zelf gegenereerde certificaten voor de clients presenteert, Azure Firewall alleen versleuteld verkeer ziet dat naar Application Gateway gaat. Dit scenario is doorgaans alleen mogelijk voor interne toepassingen. Er kunnen echter scenario's zijn waarin dit ontwerp de voorkeur heeft. Een scenario is als een andere Web Application Firewall eerder in het netwerk bestaat (bijvoorbeeld met Azure Front Door), waarmee het oorspronkelijke bron-IP-adres in de X-Forwarded-For HTTP-header kan worden vastgelegd. U kunt dit ontwerp ook gebruiken als veel openbare IP-adressen vereist zijn, omdat Application Gateway één IP-adres ondersteunt.

Binnenkomende HTTP(S)-stromen van het openbare internet moeten gericht zijn op het openbare IP-adres van Azure Firewall. Azure Firewall zal DNAT en SNAT gebruiken voor de pakketten naar het privé-IP-adres van Application Gateway. Vanuit andere virtuele Azure-netwerken of on-premises netwerken moet HTTP(S) verkeer worden verzonden naar het privé-IP-adres van Application Gateway en worden doorgestuurd via Azure Firewall met UDR's. Standaardroutering van virtuele netwerken zorgt ervoor dat verkeer van de Virtuele Azure-machines teruggaat naar Application Gateway en van Application Gateway naar Azure Firewall als DNAT-regels zijn gebruikt. Gebruik UDR's in het Application Gateway-subnet voor verkeer van on-premises of Azure. Zie de pakketwandeling verderop in dit artikel voor meer informatie. Al het uitgaande verkeer van de Virtuele Azure-machines naar internet wordt verzonden via Azure Firewall door UDR's.

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

Voor binnenkomend HTTP(S)-verkeer ontsleutelt Azure Firewall meestal geen verkeer. In plaats daarvan wordt IDPS-beleid toegepast waarvoor tls-inspectie niet is vereist, zoals filteren op BASIS van IP-adressen of het gebruik van HTTP-headers.

Architectuur

De toepassing kan het oorspronkelijke bron-IP-adres van het webverkeer niet zien. Azure Firewall past SNAT toe op 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.

Werkstroom

Netwerkverkeer van het openbare internet volgt deze stroom:

1. De client start de verbinding met het openbare IP-adres van 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-endexemplaren van de firewall. Dit is 192.168.100.7 in dit voorbeeld. Azure Firewall past DNAT toe op de webpoort, meestal TCP 443, op het privé-IP-adres van het Application Gateway-exemplaar. Azure Firewall past ook SNAT toe wanneer u DNAT uitvoert. Zie bekende problemen met Azure Firewallvoor meer informatie.

   • Bron-IP-adres, het privé-IP-adres van het Azure Firewall-exemplaar: 192.168.100.7
   • Doel-IP-adres: 192.168.200.4

3. 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, het privé-IP-adres van het Application Gateway-exemplaar: 192.168.200.7
   • Doel-IP-adres: 192.168.1.4
   • X-Forwarded-For koptekst: 192.168.100.7

4. De VM beantwoordt Application Gateway, waardoor zowel de bron- als de doel-IP-adressen worden omgekeerd:

   • 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. Azure Firewall ziet het interne IP-adres van Application Gateway, .4, als het bron-IP-adres, zelfs als de verbinding afkomstig is van een specifiek Application Gateway-exemplaar, zoals .7.

   • Bron-IP-adres: 192.168.200.4
   • Doel-IP-adres: 192.168.100.7

6. Met Azure Firewall worden SNAT en DNAT ongedaan gemaakt en wordt de client beantwoord.

   • Bron-IP-adres: AzFwPIP
   • Doel-IP-adres: ClientPIP

Application Gateway heeft een openbaar IP-adres nodig, zodat Microsoft dit kan beheren, zelfs als er geen listeners zijn geconfigureerd voor toepassingen.

On-premises clients

In de voorgaande ontwerpen worden alle binnenkomende toepassingsclients van het openbare internet weergegeven. On-premises netwerken hebben ook toegang tot toepassingen. De meeste van de vorige 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.

• Web Application Firewall maakt gebruik van het privé-IP-adres van Application Gateway.

• Azure Firewall biedt geen ondersteuning voor DNAT voor privé-IP-adressen, dus u moet UDR's gebruiken om binnenkomend verkeer naar Azure Firewall te verzenden vanaf de VPN- of ExpressRoute-gateways.

• Controleer de opmerkingen bij geforceerde tunneling voor Application Gateway- en voor Azure Firewall-. Zelfs als uw werkbelasting geen uitgaande connectiviteit met het openbare internet nodig heeft, kunt u geen standaardroute zoals 0.0.0.0/0 voor Application Gateway invoeren die verwijst naar het on-premises netwerk, omdat het controleverkeer wordt verbroken. Voor Application Gateway moet de standaardroute verwijzen naar het openbare internet.

Architectuur

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

Hub-and-spoke-topologie

De ontwerpen in dit artikel zijn van toepassing op een hub-and-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:

• Azure Firewall wordt geïmplementeerd in het virtuele netwerk van de centrale hub. In het vorige diagram ziet u hoe u Application Gateway implementeert in de hub. Toepassingsteams beheren vaak onderdelen zoals Application Gateways of API Management-gateways. In dit scenario 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 IP-adres in de vorige voorbeelden, moet het verkeer terugsturen naar hetzelfde exemplaar. Als een UDR in de spoke de volgende hop van verkeer instelt die is geadresseerd aan de hub naar het IP-adres van Azure Firewall (192.168.100.4 in de vorige diagrammen), kunnen retourpakketten terechtkomen op een ander Azure Firewall-exemplaar. Deze situatie veroorzaakt asymmetrische routering. Als u UDR's in de virtuele spoke-netwerken hebt, moet u verkeer verzenden naar gedeelde services in de hub via Azure Firewall. Deze UDR's bevatten niet het voorvoegsel van het Azure Firewall-subnet.

• De vorige aanbeveling is evenzeer van toepassing op het Application Gateway-subnet en eventuele andere NVA's of omgekeerde proxy's die kunnen worden geïmplementeerd in het virtuele hubnetwerk.

• U kunt de volgende hop voor de Application Gateway- of Azure Firewall-subnetten niet instellen via statische routes met een volgend hoptype van Virtual Network. Dit type volgende hop is alleen geldig in het lokale virtuele netwerk en niet in peerings van virtuele netwerken. Zie Virtual Network Traffic Routingvoor meer informatie over UDR's en volgende hoptypen.

Asymmetrische routering

In het volgende diagram ziet u hoe een spoke SNAT-verkeer terugstuurt naar de Azure Load Balancer van 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 en alleen met de subnetten waar de gedeelde services zich bevinden. In het vorige diagram mag de juiste UDR in de spoke alleen 192.168.1.0/24bevatten. Het mag niet het hele bereik bevatten 192.168.0.0/16, dat rood is gemarkeerd.

Integratie met andere Azure-producten

U kunt Azure Firewall en 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-gateways heeft geen invloed op de ontwerpen. 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 het toepassingspatroon API-gateways voor microservicesvoor meer informatie.

AKS

Voor workloads die worden uitgevoerd op een AKS-cluster, kunt u Application Gateway onafhankelijk van het cluster implementeren. U kunt het ook integreren met het AKS-cluster met behulp van de Application Gateway-ingangscontroller. Wanneer u specifieke objecten op kubernetes-niveaus configureert, zoals services en ingresses, wordt Application Gateway automatisch aangepast zonder dat u extra handmatige stappen hoeft uit te voeren.

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 het IP-adres. Zie Netwerkverkeer beperken met Azure Firewall in AKSvoor 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 Web Application Firewall verwerkt binnenkomende verbindingsaanvragen voor webtoepassingen in het cluster. Azure Firewall staat alleen expliciet toegestane uitgaande verbindingen toe. Zie Basislijnarchitectuur voor een AKS-clustervoor meer informatie over de optie voor parallel ontwerpen.

Azure Front Door

Azure Front Door- heeft functionaliteit die overlapt met Application Gateway in verschillende gebieden. Beide services bieden firewalling voor webtoepassingen, SSL-offloading en routering op basis van URL's. Een belangrijk verschil is echter dat Azure Front Door een globale, gedecentraliseerde service is terwijl Application Gateway binnen een virtueel netwerk werkt.

U kunt het ontwerp van virtuele netwerken soms vereenvoudigen door Application Gateway te vervangen door een gedecentraliseerd Azure Front Door. De meeste ontwerpen die in dit artikel worden beschreven, zijn nog steeds van toepassing, met uitzondering van de optie om Azure Firewall voor Azure Front Door te plaatsen.

Een scenario is het gebruik van Azure Firewall vóór Application Gateway in uw virtuele netwerk. Application Gateway injecteert de X-Forwarded-For-header met 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 een X-Forwarded-For-header te injecteren voordat het verkeer het virtuele netwerk binnenkomt en Azure Firewall bereikt. U kunt uw oorsprong ook beveiligen met Azure Private Link in Azure Front Door Premium.

Zie Veelgestelde vragen over Azure Front Doorvoor meer informatie over de verschillen tussen de twee services of wanneer u deze services wilt gebruiken.

Andere NVA's

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 bieden 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 door Azure Firewall worden ondersteund. Voorbeelden zijn DNAT van on-premises of DNAT van internet zonder SNAT.

• Door Azure beheerde NVA's, zoals Application Gateway en Azure Firewall, verminderen 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 actief-actief- en automatische schaalaanpassing van-instellingen, zodat deze apparaten geen knelpunt vormen voor toepassingen die in het virtuele netwerk worden uitgevoerd.

Medewerkers

Microsoft onderhoudt dit artikel. De volgende inzenders hebben dit artikel geschreven.

Hoofdauteur:

• Jose Moreno- | Principal Customer Engineer

Meld u aan bij LinkedIn als u niet-openbare LinkedIn-profielen wilt zien.

Volgende stappen

Meer informatie over de onderdeeltechnologieën:

• Wat is Application Gateway?
• Wat is Azure Firewall?
• Wat is Azure Front Door?
• AKS
• Wat is Virtual Network?
• Wat is Web Application Firewall?
• Basislijnarchitectuur voor een AKS-cluster

Gerelateerde resources

Gerelateerde architecturen verkennen:

• een beveiligd hybride netwerk implementeren
• veilig beheerde webtoepassingen
• Uw Microsoft Teams-kanaalbot en web-app beveiligen achter een firewall
• Multitenant-software als een service in Azure
• Enterprise-implementatie met behulp van App Service Environment
• enterprise-implementatie met hoge beschikbaarheid met behulp van App Service Environment