Een Zero Trust-netwerk implementeren voor webtoepassingen met behulp van Azure Firewall en Azure Application Gateway

In dit artikel wordt beschreven hoe u Zero Trust-beveiliging voor web-apps implementeert om inspectie en end-to-end-versleuteling in te schakelen. Het Zero Trust-model bevat veel andere concepten, zoals continue identiteitsverificatie en het minimaliseren van de grootte van de impliciete vertrouwensgebieden.

Dit artikel richt zich op het versleutelings- en inspectieonderdeel van een Zero Trust-architectuur voor inkomend verkeer van het openbare internet. Zie de Zero Trust-documentatie voor meer informatie over andere aspecten van het veilig implementeren van uw toepassing, zoals verificatie en autorisatie. In het voorbeeld in dit artikel wordt een meerlaagse benadering gebruikt. In een meerlaagse benadering bestaat netwerkbeveiliging uit een van de lagen van het Zero Trust-model. In deze laag inspecteren netwerkapparaten pakketten om ervoor te zorgen dat alleen legitiem verkeer toepassingen bereikt.

Normaal gesproken inspecteren verschillende soorten netwerkapparaten verschillende aspecten van netwerkpakketten:

• Web Application Firewalls zoeken naar patronen die duiden op een aanval op de laag van de webtoepassing.

• Firewalls van de volgende generatie kunnen ook zoeken naar algemene bedreigingen.

Deze architectuur is gericht op een gemeenschappelijk patroon voor het maximaliseren van beveiliging, waarbij Azure Application Gateway verkeer inspecteert en verwerkt voordat Azure Firewall Premium wordt bereikt. In sommige scenario's kunt u verschillende typen netwerkbeveiligingsapparaten combineren om de beveiliging te verbeteren. Zie Azure Firewall en Application Gateway voor virtuele netwerken voor meer informatie.

Architectuur

In dit diagram wijst een pijl met het label HTTPS van een pictogram dat clients vertegenwoordigt naar pictogrammen die Application Gateway en Azure Web Application Firewall vertegenwoordigen. Een andere pijl met het label HTTPS wijst van deze pictogrammen naar een Azure Firewall Premium-pictogram. Twee pijlen wijzen vanaf het pictogram Azure Firewall Premium. Eén pijl heeft het label Domain Name System (DNS) en verwijst naar een DNS-server of een privézone. De andere pijl heeft het label HTTPS en verwijst naar een pictogram dat azure Virtual Machines vertegenwoordigt.

Een Visio-bestand van deze architectuur downloaden.

Deze architectuur maakt gebruik van het TLS-protocol (Transport Layer Security) om verkeer bij elke stap te versleutelen.

1. Een client verzendt pakketten naar Application Gateway, een load balancer. Deze wordt uitgevoerd met de optionele toevoeging van Azure Web Application Firewall.

2. Application Gateway ontsleutelt de pakketten en zoekt naar bedreigingen voor webtoepassingen. Als er geen bedreigingen worden gevonden, worden zero Trust-principes gebruikt om de pakketten te versleutelen. Vervolgens worden ze vrijgegeven.

3. Azure Firewall Premium voert de volgende beveiligingscontroles uit:

   • TLS-inspectie ontsleutelt en onderzoekt de pakketten.
   • Inbraakdetectie- en preventiesysteemfuncties (IDPS) controleren de pakketten op schadelijke bedoelingen.

4. Als de pakketten aan de tests voldoen, voert Azure Firewall Premium de volgende stappen uit:

   • De pakketten worden versleuteld.
   • Er wordt een DNS-service (Domain Name System) gebruikt om de virtuele machine (VM) van de toepassing te bepalen.
   • De pakketten worden doorgestuurd naar de vm van de toepassing.

Verschillende inspectie-engines in deze architectuur zorgen voor verkeersintegriteit:

• Azure Web Application Firewall maakt gebruik van regels om aanvallen op de weblaag te voorkomen. Voorbeelden van aanvallen zijn het injecteren van SQL-code en het uitvoeren van scripts op meerdere sites. Zie Web applicatie firewall CRS-regelgroepen en -regels voor meer informatie over regels en de Open Worldwide Application Security Project (OWASP) Core Rule Set (CRS).

• Azure Firewall Premium maakt gebruik van algemene regels voor inbraakdetectie en -preventie. Deze regels helpen bij het identificeren van schadelijke bestanden en andere bedreigingen die gericht zijn op webtoepassingen.

Deze architectuur ondersteunt de volgende typen netwerkontwerp, die in dit artikel worden besproken:

• Traditionele hub- en spoke-netwerken
• Netwerken die Azure Virtual WAN als platform gebruiken
• Netwerken die Gebruikmaken van Azure Route Server om dynamische routering te vereenvoudigen

Azure Firewall Premium en naamomzetting

Wanneer Azure Firewall Premium controleert op schadelijk verkeer, wordt gecontroleerd of de HTTP-hostheader overeenkomt met het IP-adres van het pakket en tcp-poort (Transmission Control Protocol). Stel dat Application Gateway webpakketten verzendt naar het IP-adres 172.16.1.4 en TCP-poort 443. De waarde van de HTTP-hostheader moet worden omgezet in dat IP-adres.

HTTP-hostheaders bevatten meestal geen IP-adressen. In plaats daarvan bevatten de headers namen die overeenkomen met het digitale certificaat van de server. In dit geval gebruikt Azure Firewall Premium DNS om de naam van de hostheader om te voeren naar een IP-adres. Het netwerkontwerp bepaalt welke DNS-oplossing het beste werkt.

Opmerking

Application Gateway biedt geen ondersteuning voor poortnummers in HTTP-hostheaders. Als gevolg hiervan:

• Azure Firewall Premium gaat uit van een standaard-HTTPS TCP-poort van 443.
• De verbinding tussen Application Gateway en de webserver biedt alleen ondersteuning voor TCP-poort 443, niet voor niet-standaardpoorten.

Digitale certificaten

In het volgende diagram ziet u de algemene namen (CN's) en certificeringsinstanties (CA's) die door de TLS-sessies en certificaten van deze architectuur worden gebruikt.

In dit diagram wijst een pijl met het label HTTPS van een pictogram dat clients vertegenwoordigt naar pictogrammen die Application Gateway en Azure Web Application Firewall vertegenwoordigen. Aan de linkerkant van deze pictogrammen staan de CN, myapp.contoso.com en de CA, DigiCert. Aan de rechterkant van deze pictogrammen bevindt zich de Basis-CA van Azure Firewall in HTTP-instellingen. Een andere pijl met het label HTTPS wijst van deze pictogrammen naar een Azure Firewall Premium-pictogram. Aan de linkerkant van dit pictogram ziet u de CN, myapp.contoso.com en de CA, Azure Firewall CA. Een andere pijl met het label HTTPS verwijst naar een pictogram dat azure Virtual Machines vertegenwoordigt. Aan de linkerkant van dit pictogram bevindt zich de CN, myapp.contoso.com en de CA, DigiCert.

Azure Firewall genereert dynamisch eigen certificaten. Deze mogelijkheid is een van de belangrijkste redenen waarom deze achter Application Gateway wordt geplaatst. Anders wordt de toepassingsclient geconfronteerd met zelf gegenereerde certificaten die als beveiligingsrisico worden gemarkeerd.

TLS-verbindingen

Deze architectuur bevat drie afzonderlijke TLS-verbindingen. Digitale certificaten valideren elk certificaat.

Van clients naar Application Gateway

In Application Gateway implementeert u het digitale certificaat dat clients zien. Een bekende CA, zoals DigiCert of Let's Encrypt, geeft doorgaans een dergelijk certificaat uit. Dit mechanisme is fundamenteel anders dan de manier waarop Azure Firewall dynamisch digitale certificaten genereert van een zelfondertekende of interne openbare-sleutelinfrastructuur-CA.

Van Application Gateway naar Azure Firewall Premium

Voor het ontsleutelen en inspecteren van TLS-verkeer genereert Azure Firewall Premium dynamisch certificaten. Azure Firewall Premium presenteert zich ook als webserver aan Application Gateway. Een privé-CA ondertekent de certificaten die Azure Firewall Premium genereert. Zie Azure Firewall Premium-certificatenvoor meer informatie. Application Gateway moet deze certificaten valideren. In de HTTP-instellingen van de toepassing configureert u de basis-CA die azure Firewall Premium gebruikt.

Van Azure Firewall Premium naar de webserver

Azure Firewall Premium brengt een TLS-sessie tot stand met de doelwebserver. Azure Firewall Premium controleert of een bekende CA de TLS-pakketten van de webserver ondertekent.

Onderdeelrollen

Application Gateway en Azure Firewall Premium verwerken certificaten anders dan elkaar, omdat hun rollen verschillen:

• Application Gateway is een omgekeerde webproxy. Het beveiligt webservers tegen kwaadwillende clients door HTTP- en HTTPS-aanvragen te onderscheppen. U declareert elke beveiligde server die zich in de back-endpool van Application Gateway bevindt met het IP-adres of de volledig gekwalificeerde domeinnaam. Legitieme clients moeten toegang hebben tot elke toepassing. U configureert Application Gateway dus met een digitaal certificaat dat een openbare CA ondertekent. Gebruik een CA die door een TLS-client wordt geaccepteerd.

• Azure Firewall Premium is een webproxy doorsturen of gewoon een webproxy. Clients worden beschermd tegen schadelijke webservers door TLS-aanroepen van de beveiligde clients te onderscheppen. Wanneer een beveiligde client een HTTP-aanvraag doet, imiteert de doorstuurwebproxy de doelwebserver door digitale certificaten te genereren en deze aan de client te presenteren. Azure Firewall Premium maakt gebruik van een privé-CA, die de dynamisch gegenereerde certificaten ondertekent. U configureert de beveiligde clients om die privé-CA te vertrouwen. In deze architectuur beveiligt Azure Firewall Premium aanvragen van Application Gateway naar de webserver. Application Gateway vertrouwt de privé-CA die azure Firewall Premium gebruikt.

Routering en doorsturen van verkeer

Routering verschilt enigszins, afhankelijk van de topologie van uw netwerkontwerp. In de volgende secties worden voorbeelden van hub- en spoke-, Virtual WAN- en Route Server-topologieën beschreven. Alle topologieën hebben de volgende aspecten gemeen:

• Application Gateway fungeert altijd als proxy. Azure Firewall Premium fungeert ook als proxy wanneer deze is geconfigureerd voor TLS-inspectie. Application Gateway beëindigt de TLS-sessies van clients en nieuwe TLS-sessies worden gebouwd op basis van Azure Firewall. Azure Firewall ontvangt en beëindigt de TLS-sessies die afkomstig zijn van Application Gateway en bouwt nieuwe TLS-sessies voor de workloads. Dit proces is van invloed op de IDPS-configuratie van Azure Firewall Premium. Zie IDPS- en privé-IP-adressen voor meer informatie.

• De workload ziet verbindingen die afkomstig zijn van het IP-adres van het Azure Firewall-subnet. Het oorspronkelijke IP-adres van de client blijft behouden in de X-Forwarded-For HTTP-header die Application Gateway invoegt. Azure Firewall biedt ook ondersteuning voor het injecteren van het IP-adres van de bronclient in de X-Forwarded-For header. In dit scenario is het IP-adres van de bronclient het IP-adres van de toepassingsgateway.

• Verkeer van Application Gateway naar de workload wordt doorgaans verzonden naar Azure Firewall met behulp van Azure-routeringsmechanismen. Deze mechanismen omvatten door de gebruiker gedefinieerde routes (UDR's) die zijn geconfigureerd in het Application Gateway-subnet of routes die door de Virtual WAN of Route Server worden geïnjecteerd. Het expliciet definiëren van het privé-IP-adres van Azure Firewall in de back-endpool van Application Gateway is mogelijk, maar we raden dit niet aan, omdat hiermee een deel van de systeemeigen functionaliteit van Application Gateway wordt verwijderd, zoals taakverdeling en sessiestickerbaarheid.

In de volgende secties worden enkele van de meest voorkomende topologieën beschreven die u kunt gebruiken met Azure Firewall en Application Gateway.

Hub- en spaaktopologie

Een hub- en spoke-ontwerp implementeert doorgaans gedeelde netwerkonderdelen in het virtuele hubnetwerk en toepassingsspecifieke onderdelen in de spokes. In de meeste systemen is Azure Firewall Premium een gedeelde resource. Azure Web Application Firewall kan een gedeeld netwerkapparaat of een toepassingsspecifiek onderdeel zijn. Het is een best practice om Application Gateway als een toepassingsonderdeel te behandelen en om de volgende redenen in een virtueel spoke-netwerk te implementeren:

• Het kan lastig zijn om problemen met Azure Web Application Firewall-waarschuwingen op te lossen. Over het algemeen hebt u uitgebreide kennis van de toepassing nodig om te bepalen of de berichten die deze waarschuwingen activeren legitiem zijn.

• Als u Application Gateway als een gedeelde resource behandelt, kunt u de limieten van Application Gateway overschrijden.

• Mogelijk ondervindt u problemen met op rollen gebaseerd toegangsbeheer als u Application Gateway in de hub implementeert. Deze situatie kan optreden wanneer teams verschillende toepassingen beheren, maar hetzelfde exemplaar van Application Gateway gebruiken. Elk team heeft vervolgens toegang tot de volledige Application Gateway-configuratie.

In traditionele hub- en spoke-architecturen biedt DNS-privézones een eenvoudige manier om DNS te gebruiken:

1. Configureer een privé-DNS-zone.
2. Koppel de zone aan het virtuele netwerk dat Azure Firewall Premium bevat.
3. Zorg ervoor dat er een adresrecord bestaat voor de waarde die Application Gateway gebruikt voor verkeer en voor statuscontroles.

In het volgende diagram ziet u de pakketstroom wanneer Application Gateway zich in een virtueel spoke-netwerk bevindt. In dit geval maakt een client verbinding vanaf het openbare internet.

Het diagram bestaat uit twee hoofdsecties, het virtuele hubnetwerk en het virtuele spoke-netwerk. Een blauwe pijl vertegenwoordigt het traject van een clientaanvraag van internet naar het toepassingssubnet in het virtuele spoke-netwerk. De blauwe pijl begint bij een pictogram dat het internet vertegenwoordigt en verwijst naar het Application Gateway-subnet in het virtuele spoke-netwerk. De blauwe pijl gaat verder van het Application Gateway-subnet naar het Azure Firewall-subnet in het virtuele hubnetwerk. Het verwijst vervolgens van het Azure Firewall-subnet naar het toepassingssubnet in het virtuele spoke-netwerk. Een dubbelzijdige pijl met het label peering van virtuele netwerken verbindt het virtuele hubnetwerk en de secties van het virtuele spoke-netwerk. Een groene pijl vertegenwoordigt het traject van de clientaanvraag van het toepassingssubnet terug naar de client. De groene pijl begint bij het subnet van de toepassing en verwijst naar het Azure Firewall-subnet. De groene pijl gaat verder van het Azure Firewall-subnet naar het Application Gateway-subnet en terug naar de client.

1. Een client verzendt een aanvraag naar een webserver.

2. Application Gateway onderschept de clientpakketten en onderzoekt deze. Als de pakketten worden gecontroleerd, verzendt Application Gateway de pakketten naar de back-end-VM. Wanneer de pakketten Azure bereiken, stuurt een UDR in het Application Gateway-subnet deze door naar Azure Firewall Premium.

3. Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze de tests doorstaan, stuurt Azure Firewall Premium de pakketten door naar de toepassings-VM.

4. De VIRTUELE machine reageert en stelt het doel-IP-adres in op de toepassingsgateway. Met een UDR in het VM-subnet worden de pakketten omgeleid naar Azure Firewall Premium.

5. Azure Firewall Premium stuurt de pakketten door naar Application Gateway.

6. Application Gateway beantwoordt de client.

Verkeer kan ook binnenkomen vanaf een on-premises netwerk in plaats van het openbare internet. Het verkeer stroomt via een site-naar-site virtueel particulier netwerk (VPN) of via Azure ExpressRoute. In dit scenario bereikt het verkeer eerst een virtuele netwerkgateway in de hub. De rest van de netwerkstroom is hetzelfde als het vorige diagram.

Het diagram bestaat uit twee hoofdsecties, het virtuele hubnetwerk en het virtuele spoke-netwerk. Een blauwe pijl vertegenwoordigt het traject van een clientaanvraag van on-premises naar de toepassings-VM. De blauwe pijl begint bij de on-premises client en verwijst naar het gatewaysubnet van het virtuele netwerk in het virtuele hubnetwerk. De blauwe pijl gaat verder van het gatewaysubnet van het virtuele netwerk naar het Application Gateway-subnet in het virtuele spoke-netwerk. Het verwijst vervolgens naar het Azure Firewall-subnet in het virtuele hubnetwerk en gaat door naar het toepassingssubnet in het virtuele spoke-netwerk. Een dubbelzijdige pijl met het label peering van virtuele netwerken verbindt het virtuele hubnetwerk en de secties van het virtuele spoke-netwerk. Een groene pijl vertegenwoordigt het traject van de clientaanvraag van de toepassings-VM terug naar de on-premises client. De groene pijl begint bij de toepassings-VM en verwijst naar het Azure Firewall-subnet. Het verwijst vervolgens naar het Application Gateway-subnet, naar de gateway van het virtuele netwerk en vervolgens naar de client.

1. Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.

2. De virtuele netwerkgateway stuurt de clientpakketten door naar Application Gateway.

3. Application Gateway onderzoekt de pakketten. Als ze inspectie doorgeven, stuurt een UDR in het Application Gateway-subnet de pakketten door naar Azure Firewall Premium.

4. Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze de tests doorstaan, stuurt Azure Firewall Premium de pakketten door naar de toepassings-VM.

5. De VIRTUELE machine reageert en stelt het doel-IP-adres in op Application Gateway. Met een UDR in het VM-subnet worden de pakketten omgeleid naar Azure Firewall Premium.

6. Azure Firewall Premium stuurt de pakketten door naar Application Gateway.

7. Application Gateway verzendt de pakketten naar de gateway van het virtuele netwerk.

8. De gateway van het virtuele netwerk beantwoordt de client.

Virtual WAN-topologie

U kunt de netwerkservice ook gebruiken Virtual WAN- in deze architectuur. Dit onderdeel biedt veel voordelen. Het elimineert bijvoorbeeld de noodzaak voor door de gebruiker onderhouden UDR's in virtuele spoke-netwerken. U kunt in plaats daarvan statische routes definiëren in routetabellen van virtuele hubs. Het programmeren van elk virtueel netwerk dat u met de hub verbindt, bevat deze routes.

Wanneer u Virtual WAN als netwerkplatform gebruikt, zijn er twee belangrijke verschillen:

• U kunt privézones voor DNS niet koppelen aan een virtuele hub, omdat Microsoft virtuele hubs beheert. Als eigenaar van het abonnement hebt u geen machtigingen om privé-DNS-zones te koppelen. Als gevolg hiervan kunt u een PRIVÉ-DNS-zone niet koppelen aan de beveiligde hub die Azure Firewall Premium bevat.

  Als u DNS-omzetting voor Azure Firewall Premium wilt implementeren, gebruikt u in plaats daarvan DNS-servers:

  • Configureer de DNS-instellingen van Azure Firewall voor het gebruik van aangepaste DNS-servers.

  • Implementeer de servers in een virtueel netwerk van gedeelde services dat u verbindt met het virtuele WAN.

  • Koppel een privé-DNS-zone aan het virtuele netwerk van de gedeelde services. De DNS-servers kunnen vervolgens de namen omzetten die Application Gateway gebruikt in HTTP-hostheaders. Zie Dns-instellingen voor Azure Firewall voor meer informatie.

• U kunt Virtual WAN alleen gebruiken om routes in een spoke te programmeren als het voorvoegsel korter is (minder specifiek) dan het voorvoegsel van het virtuele netwerk. In de voorgaande diagrammen heeft het virtuele spoke-netwerk bijvoorbeeld het voorvoegsel 172.16.0.0/16. In dit geval kan Virtual WAN geen route invoeren die overeenkomt met het voorvoegsel van het virtuele netwerk (172.16.0.0/16) of een van de subnetten (172.16.0.0/24, 172.16.1.0/24). Met andere woorden, Virtual WAN kan geen verkeer omleiden tussen twee subnetten die zich in hetzelfde virtuele netwerk bevinden.

  Deze beperking wordt duidelijk wanneer Application Gateway en de doelwebserver zich in hetzelfde virtuele netwerk bevinden. Virtual WAN kan het verkeer tussen Application Gateway en de webserver niet forceren om via Azure Firewall Premium te gaan. Eén oplossing is het handmatig configureren van UDR's in de Application Gateway- en webserversubnetten.

In het volgende diagram ziet u de pakketstroom in een architectuur die gebruikmaakt van Virtual WAN. In dit scenario is toegang tot Application Gateway afkomstig van een on-premises netwerk. Een site-naar-site-VPN- of ExpressRoute-exemplaar verbindt dat netwerk met Virtual WAN. Internettoegang volgt een vergelijkbaar pad.

Het diagram bestaat uit vier secties, het virtuele hubnetwerk, het virtuele Application Gateway-netwerk, het virtuele toepassingsnetwerk en het virtuele netwerk van de gedeelde services. Een blauwe pijl vertegenwoordigt het traject van een clientaanvraag van on-premises naar de toepassings-VM. De blauwe pijl begint bij de on-premises client en verwijst naar de VPN-gateway in het virtuele hubnetwerk. De blauwe pijl wijst vervolgens van de VPN-gateway naar het Application Gateway-subnet in het virtuele Application Gateway-netwerk. Het gaat verder van het Application Gateway-subnet naar een pictogram dat Azure Firewall Premium vertegenwoordigt in het virtuele hubnetwerk. Vervolgens verwijst het van het pictogram Azure Firewall Premium naar het DNS-subnet in het virtuele netwerk van de gedeelde services. Een groene pijl vertegenwoordigt de reis van de clientaanvraag terug naar de on-premises client. De groene pijl begint bij het DNS-subnet en verwijst naar het pictogram Azure Firewall Premium in het virtuele hubnetwerk. Een blauwe pijl vertegenwoordigt pakketten die de Azure Firewall Premium-beveiligingscontroles doorstaan. Deze verwijst naar de toepassings-VM in het virtuele netwerk van de toepassing. De groene pijl wijst terug naar Azure Firewall Premium en gaat verder met het Application Gateway-subnet, vervolgens de VPN-gateway en ten slotte terug naar de client.

1. Een on-premises client maakt verbinding met de VPN-gateway.

2. De VPN-gateway stuurt de clientpakketten door naar Application Gateway.

3. Application Gateway onderzoekt de pakketten. Als deze worden gecontroleerd, stuurt het Application Gateway-subnet de pakketten door naar Azure Firewall Premium.

4. Azure Firewall Premium vraagt DNS-omzetting aan van een DNS-server in het virtuele netwerk van gedeelde services.

5. De DNS-server beantwoordt de omzettingsaanvraag.

6. Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze de tests doorstaan, stuurt Azure Firewall Premium de pakketten door naar de toepassings-VM.

7. De VIRTUELE machine reageert en stelt het doel-IP-adres in op Application Gateway. Het subnet van de toepassing stuurt de pakketten om naar Azure Firewall Premium.

8. Azure Firewall Premium stuurt de pakketten door naar Application Gateway.

9. Application Gateway verzendt de pakketten naar de VPN-gateway.

10. De VPN-gateway beantwoordt de client.

Als u dit ontwerp gebruikt, moet u mogelijk de routering wijzigen die door de hub wordt aangeboden aan de virtuele spoke-netwerken. Application Gateway v2 ondersteunt met name alleen een 0.0.0.0/0 route die naar internet verwijst. Routes met dit adres die niet verwijzen naar internet, verbreken de connectiviteit die Microsoft nodig heeft voor het beheren van Application Gateway. Als uw virtuele hub een 0.0.0.0/0 route adverteert, voorkomt u dat deze route wordt doorgegeven aan het Application Gateway-subnet door een van de volgende stappen uit te voeren:

• Maak een routetabel met een route voor 0.0.0.0/0 en een volgend hoptype van Internet. Koppel deze route aan het subnet waarin u Application Gateway implementeert.

• Als u Application Gateway in een toegewezen spoke implementeert, schakelt u de doorgifte van de standaardroute uit in de instellingen voor de virtuele netwerkverbinding.

Topologie van routeserver

RouteServer biedt een andere manier om routes automatisch in spokes te injecteren. Gebruik deze functionaliteit om de administratieve overhead van het onderhouden van routetabellen te voorkomen. Route Server combineert de virtual WAN- en hub- en spoke-varianten:

• U kunt Route Server gebruiken om virtuele hubnetwerken te beheren. Als gevolg hiervan kunt u het virtuele hubnetwerk koppelen aan een privé-DNS-zone.

• RouteServer heeft dezelfde beperking als virtual WAN met betrekking tot IP-adresvoorvoegsels. U kunt routes alleen in een spoke injecteren als het voorvoegsel korter (minder specifiek) is dan het voorvoegsel van het virtuele netwerk. Vanwege deze beperking moeten Application Gateway en de doelwebserver zich in verschillende virtuele netwerken bevinden.

In het volgende diagram ziet u de pakketstroom wanneer Route Server dynamische routering vereenvoudigt. Houd rekening met de volgende punten:

• Routeserver vereist momenteel het apparaat dat de routes injecteert om ze te verzenden via Border Gateway Protocol (BGP). Azure Firewall Premium biedt geen ondersteuning voor BGP, dus gebruik in plaats daarvan een virtueel netwerkapparaat (NVA) dat niet van Microsoft is.

• De functionaliteit van de NVA in de hub bepaalt of uw implementatie DNS nodig heeft.

Het diagram bestaat uit vier secties, het virtuele hubnetwerk, het virtuele Application Gateway-netwerk, het virtuele toepassingsnetwerk en het virtuele netwerk van de gedeelde services. Het virtuele hubnetwerk bevat drie vakken die het gatewaysubnet van het virtuele netwerk, het subnet routeserver en het NVA-subnet vertegenwoordigen. Een blauwe pijl vertegenwoordigt het traject van een clientaanvraag van on-premises naar de toepassings-VM. De blauwe pijl begint bij de on-premises client en verwijst naar de gateway van het virtuele netwerk in de sectie virtueel hubnetwerk. De blauwe pijl wijst vervolgens naar het Application Gateway-subnet in het virtuele netwerk van Application Gateway. De blauwe pijl gaat door naar het NVA-subnet in het virtuele hubnetwerk. Het wijst vervolgens van het NVA-subnet naar het DNS-subnet in het virtuele netwerk van de gedeelde services. Een groene pijl vertegenwoordigt de reis van de clientaanvraag terug naar de on-premises client. Het begint bij het DNS-subnet en verwijst naar het NVA-subnet in het virtuele hubnetwerk. Een blauwe pijl vertegenwoordigt pakketten die de NVA-beveiligingscontroles doorstaan. Deze verwijst naar de toepassings-VM in het virtuele netwerk van de toepassing. De groene pijl wijst terug naar het NVA-subnet en gaat verder met het Application Gateway-subnet, vervolgens naar de gateway van het virtuele netwerk en ten slotte terug naar de client.

1. Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.

2. De virtuele netwerkgateway stuurt de clientpakketten door naar Application Gateway.

3. Application Gateway onderzoekt de pakketten. Als ze voor de inspectie slagen, stuurt het Application Gateway-subnet de pakketten door naar een back-endcomputer. Routeserver injecteert een route in het Application Gateway-subnet dat het verkeer doorstuurt naar een NVA.

4. Het NVA-subnet vraagt DNS-omzetting aan van een DNS-server in het virtuele netwerk van de gedeelde services.

5. De DNS-server beantwoordt de omzettingsaanvraag.

6. De NVA voert beveiligingscontroles uit op de pakketten. Als ze de tests doorstaan, stuurt de NVA de pakketten door naar de toepassings-VM.

7. De toepassings-VM reageert en stelt het doel-IP-adres in op Application Gateway. RouteServer injecteert een route in het VM-subnet waarmee de pakketten worden omgeleid naar de NVA.

8. De NVA stuurt de pakketten door naar Application Gateway.

9. Application Gateway verzendt de pakketten naar de gateway van het virtuele netwerk.

10. De gateway van het virtuele netwerk beantwoordt de client.

Net als bij Virtual WAN moet u de routering mogelijk wijzigen wanneer u RouteServer gebruikt. Als u de 0.0.0.0/0 route adverteert, kan deze worden doorgegeven aan het Application Gateway-subnet. Maar Application Gateway biedt geen ondersteuning voor die route. In dit geval configureert u een routetabel voor het Application Gateway-subnet. Neem een route voor 0.0.0.0/0 en een volgend hoptype Internet in die tabel op.

IDPS en privé-IP-adressen

Azure Firewall Premium bepaalt welke IDPS-regels moeten worden toegepast op basis van de bron- en doel-IP-adressen van de pakketten. Standaard behandelt Azure Firewall privé-IP-adressen in de RFC 1918-bereiken (10.0.0.0/8, 192.168.0.0/16, en 172.16.0.0/12) en het RFC 6598-bereik (100.64.0.0/10) als intern. Dus als u Application Gateway in een subnet in een van deze bereiken implementeert, beschouwt Azure Firewall Premium verkeer tussen Application Gateway en de workload als intern. Daarom worden alleen IDPS-handtekeningen gebruikt die zijn gemarkeerd om te worden toegepast op intern verkeer of op al het verkeer. IDPS-handtekeningen die zijn gemarkeerd om te worden toegepast op binnenkomend of uitgaand verkeer, worden niet toegepast op verkeer tussen Application Gateway en de workload. Zie Azure Firewall IDPS-regels voor meer informatie.

De eenvoudigste manier om binnenkomende IDPS-handtekeningregels toe te passen op het verkeer tussen Application Gateway en de workload, is door Application Gateway te plaatsen in een subnet dat gebruikmaakt van een voorvoegsel buiten de privébereiken. U hoeft niet per se openbare IP-adressen voor dit subnet te gebruiken. In plaats daarvan kunt u de IP-adressen aanpassen die Door Azure Firewall Premium worden behandeld als intern voor IDPS. Als uw organisatie bijvoorbeeld het bereik niet gebruikt 100.64.0.0/10 , kunt u dit bereik verwijderen uit de lijst met interne voorvoegsels voor IDPS en Application Gateway implementeren in een subnet dat is geconfigureerd met een IP-adres in 100.64.0.0/10. Zie de privé-IPDS-bereiken van Azure Firewall Premium voor meer informatie.

Bijdragers

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

Hoofdauteur:

• Jose Moreno- | Principal Customer Engineer

Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.

Volgende stappen

• Netwerken beveiligen met Zero Trust
• Routering van verkeer in virtuele netwerken
• Hoe een toepassingsgateway werkt

Verwante middelen

• Een beveiligd hybride netwerk implementeren
• Hub-spoke-netwerktopologie in Azure
• Hub-spoke-netwerktopologie die gebruikmaakt van Virtual WAN