Zero Trust-netwerk voor webtoepassingen met Azure Firewall en Application Gateway

Application Gateway
Firewall
Virtual Network
Virtuele WAN
Web Application Firewall

Deze handleiding bevat een overzicht van een strategie voor het implementeren van zero-trust-beveiliging voor web-apps. Met dit type beveiligingsmodel wordt de betrouwbaarheid gecontroleerd van netwerkpakketten die naar toepassingen stromen. Een meerlaagse benadering werkt het beste, waarbij netwerkbeveiliging één laag is. In deze laag inspecteren netwerkapparaten pakketten om ervoor te zorgen dat alleen legitiem verkeer toepassingen bereikt.

Doorgaans inspecteren verschillende typen netwerkapparaten verschillende aspecten van netwerkpakketten:

  • Web Application Firewalls zoeken naar patronen die wijzen op een aanval op de laag van de webtoepassing.
  • Firewalls van de volgende generatie kunnen ook zoeken naar algemene bedreigingen.

In sommige gevallen kunt u verschillende typen netwerkbeveiligingsapparaten combineren om de beveiliging te verbeteren. In een afzonderlijke handleiding, Firewall en Application Gatewayvoor virtuele netwerken, worden ontwerppatronen beschreven die u kunt gebruiken om de verschillende apparaten te rangschikken. Dit document is gericht op een algemeen patroon voor het maximaliseren van de beveiliging, waarbij Azure Application Gateway vóór Azure Firewall Premium. Het volgende diagram illustreert dit patroon:

Architectuurdiagram met de pakketstroom in een web-app-netwerk dat gebruikmaakt van Application Gateway vóór Azure Firewall Premium.

Deze architectuur maakt gebruik van het SSL-protocol (Secure Sockets Layer) om verkeer bij elke stap te versleutelen.

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

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

  • Azure Firewall Premium voert beveiligingscontroles uit:

  • Als de pakketten slagen voor de tests, voert Azure Firewall Premium de volgende stappen uit:

    • Versleutelt de pakketten
    • Gebruikt een Domain Name System service (DNS) om de virtuele machine (VM) van de toepassing te bepalen
    • De pakketten worden doorgestuurd naar de toepassings-VM

Verschillende inspectie-engines in deze architectuur zorgen voor de integriteit van het verkeer:

  • Web Application Firewall maakt gebruik van regels om aanvallen op de weblaag te voorkomen. Voorbeelden van aanvallen zijn SQL code-injectie en cross-site scripting. Zie crs-regelgroepen en -regels voor meer informatie over regels en de basisregelset van Open Web Application Security Project (OWAS Web Application Firewall P).
  • 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 verschillende typen netwerkontwerp. In dit artikel wordt het volgende besproken:

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

Azure Firewall Premium en naamresolutie

Bij het controleren op schadelijk verkeer controleert Azure Firewall Premium of de HTTP-hostheader overeenkomt met het IP-adres van het pakket en de TCP-poort. Stel bijvoorbeeld dat Application Gateway webpakketten verzendt naar het IP-adres 172.16.1.4 en TCP-poort 443. De waarde van de HTTP Host-header moet worden opgelost naar dat IP-adres.

HTTP-hostheaders bevatten doorgaans 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 zet in een IP-adres. Het netwerkontwerp bepaalt welke DNS-oplossing het beste werkt, zoals in latere secties wordt beschreven.

Notitie

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

  • Azure Firewall Premium wordt uitgemaakt van een standaard HTTPS TCP-poort van 443.
  • De verbinding tussen Application Gateway en de webserver ondersteunt alleen TCP-poort 443, niet niet-standaardpoorten.

Digitale certificaten

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

Architectuurdiagram met de algemene namen en certificeringsinstanties die een web-app-netwerk gebruikt wanneer een load balancer zich vóór een firewall.

SSL-verbindingen

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

Van clients naar Application Gateway

In Application Gateway implementeert u het digitale certificaat dat clients te zien krijgen. Een bekende CA, zoals DigiCert of Let's Encrypt, geeft doorgaans een dergelijk certificaat uit.

Van Application Gateway naar Azure Firewall Premium

Als u TLS-verkeer wilt ontsleutelen en controleren, Azure Firewall Premium certificaten dynamisch genereren. Azure Firewall Premium wordt ook aan Application Gateway als de webserver. Een persoonlijke CA ondertekent de certificaten die Azure Firewall Premium gegenereerd. Zie voor meer informatie Azure Firewall Premium certificaten. 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 wordt een SSL-sessie met de doelwebserver tot leven gebracht. Azure Firewall Premium controleert of een bekende CA de SSL-pakketten van de webserver ondertekent.

Onderdeelrollen

Application Gateway en Azure Firewall Premium certificaten verschillend van elkaar verwerken omdat hun rollen verschillen:

  • Application Gateway is een omgekeerde webproxy. Webservers worden beschermd tegen schadelijke clients door HTTP- en HTTPS-aanvragen te onderscheppen. U declareer elke beveiligde server die zich in de back-endpool van de Application Gateway met het IP-adres of de fully qualified domain name. Legitieme clients moeten toegang hebben tot elke toepassing. U configureert Application Gateway met een digitaal certificaat dat door een openbare CA is ondertekend. Gebruik een CA die elke SSL-client accepteert.
  • Azure Firewall Premium is een doorgestuurde webproxy of gewoon een webproxy. Clients worden beschermd tegen schadelijke webservers door SSL-aanroepen van de beveiligde clients te onderscheppen. Wanneer een beveiligde client een HTTP-aanvraag indient, imiteert de doorsturende proxy de doelwebserver door digitale certificaten te genereren en deze aan de client te presenteren. Azure Firewall Premium maakt gebruik van een persoonlijke CA, die de dynamisch gegenereerde certificaten ondertekent. U configureert de beveiligde clients om die persoonlijke CA te vertrouwen. In deze architectuur beschermt Azure Firewall Premium aanvragen van Application Gateway naar de webserver. Application Gateway vertrouwt de persoonlijke CA die Azure Firewall Premium gebruikt.

Voorbeeld van hub en spoke

Normaal gesproken implementeert een hub en spoke-ontwerp gedeelde netwerkonderdelen in het virtuele hubnetwerk en toepassingsspecifieke onderdelen in de spokes. In de meeste systemen Azure Firewall Premium een gedeelde resource. Maar Web Application Firewall kan een gedeeld netwerkapparaat of een toepassingssspecifieke component zijn. Om de volgende redenen is het meestal het beste om Application Gateway te behandelen als een toepassingsonderdeel en deze te implementeren in een virtueel spoke-netwerk:

  • Het kan lastig zijn om problemen met Web Application Firewall oplossen. Over het algemeen hebt u diepgaande kennis van de toepassing nodig om te bepalen of de berichten die deze alarmen activeren, legitiem zijn.
  • Als u Application Gateway als een gedeelde resource behandelt, kunt u de limieten Azure Application Gateway overschrijden.
  • U kunt problemen met op rollen gebaseerd toegangsbeheer krijgen als u een Application Gateway in de hub implementeert. Deze situatie kan zich voor doen wanneer teams verschillende toepassingen beheren, maar dezelfde instantie van Application Gateway. Elk team heeft vervolgens toegang tot de Application Gateway configuratie.

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

  • Configureer een privé-DNS-zone.
  • Koppel de zone aan het virtuele netwerk met Azure Firewall Premium.
  • Zorg ervoor dat er een A-record bestaat voor de waarde Application Gateway gebruikt voor verkeer en voor statuscontroles.

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

Architectuurdiagram met de pakketstroom in een hub en spoke-netwerk met een load balancer en een firewall. Clients maken verbinding vanaf het openbare internet.

  1. Een client dient een aanvraag in bij een webserver.
  2. Application Gateway onderschept de clientpakketten en onderzoekt ze. Als de pakketten door de inspectie komen, worden de pakketten door een door de gebruiker gedefinieerde route (UDR) in het Application Gateway doorgestuurd naar Azure Firewall Premium.
  3. Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze slagen voor de tests, Azure Firewall Premium pakketten doorsturen naar de toepassings-VM.
  4. De VM reageert en stelt het doel-IP-adres in op Application Gateway. Een UDR in het Application Gateway subnet leidt de pakketten om naar Azure Firewall Premium.
  5. Azure Firewall Premium de pakketten doorsturen naar Application Gateway.
  6. Application Gateway antwoord op de client.

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

Architectuurdiagram met de pakketstroom in een hub en spoke-netwerk met een load balancer en een firewall. Clients maken verbinding vanaf een on-premises netwerk.

  1. Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.
  2. De gateway wordt de clientpakketten doorgestuurd naar Application Gateway.
  3. Application Gateway onderzoekt de pakketten. Als ze de inspectie doorgeven, worden de pakketten door een UDR in Application Gateway subnet doorgestuurd naar Azure Firewall Premium.
  4. Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze slagen voor de tests, Azure Firewall Premium pakketten doorsturen naar de toepassings-VM.
  5. De VM reageert en stelt het doel-IP-adres in op Application Gateway. Een UDR in het Application Gateway subnet leidt de pakketten om naar Azure Firewall Premium.
  6. Azure Firewall Premium de pakketten doorsturen naar Application Gateway.
  7. Application Gateway verzendt de pakketten naar de gateway van het virtuele netwerk.
  8. De gateway beantwoordt de client.

Virtual WAN voorbeeld

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

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

  • U kunt geen privé-DNS-zones koppelen aan een virtuele hub omdat Microsoft virtuele hubs beheert. Als eigenaar van het abonnement hebt u geen machtigingen voor het koppelen van privé-DNS-zones. Als gevolg hiervan kunt u geen privé-DNS-zone koppelen aan de beveiligde hub die Azure Firewall Premium. Als u DNS-resolutie voor Azure Firewall Premium wilt implementeren, gebruikt u in plaats daarvan DNS-servers:

    • Configureer de Azure Firewall DNS-Instellingen om aangepaste DNS-servers te gebruiken.
    • Implementeer de servers in een virtueel netwerk voor gedeelde services dat u verbindt met het virtuele WAN.
    • Een privé-DNS-zone koppelen aan het virtuele netwerk met gedeelde services. De DNS-servers kunnen vervolgens de namen oplossen die Application Gateway gebruikt in HTTP Host-headers. Zie DNS-Azure Firewall voor meer Instellingen.
  • U kunt alleen Virtual WAN om routes in een spoke te programmeren als het voorvoegsel korter is dan het voorvoegsel van het virtuele netwerk. Deze beperking wordt duidelijk wanneer Application Gateway en de doelwebserver zich in hetzelfde virtuele netwerk. In dat geval kan Virtual WAN een route injecteren die de systeemroute voor het virtuele netwerk overschrijven. Als gevolg hiervan wordt het verkeer tussen Application Gateway en de webserver omzeild Azure Firewall Premium.

In het volgende diagram ziet u de pakketstroom in een case die gebruikmaakt van Virtual WAN. In dit geval is de toegang tot Application Gateway afkomstig van een on-premises netwerk. Een site-naar-site-VPN of ExpressRoute verbindt dat netwerk met Virtual WAN. Toegang via internet is vergelijkbaar.

Architectuurdiagram met de pakketstroom in een hub en spoke-netwerk met een load balancer, een firewall en Virtual WAN.

  1. Een on-premises client maakt verbinding met het VPN.
  2. De VPN-verbinding zorgt dat de clientpakketten worden doorgestuurd naar Application Gateway.
  3. Application Gateway onderzoekt de pakketten. Als de pakketten door de inspectie worden Application Gateway, worden de pakketten doorgestuurd naar Azure Firewall Premium.
  4. Azure Firewall Premium dns-resolutie aanvragen van een DNS-server in het virtuele netwerk van de gedeelde services.
  5. De DNS-server beantwoordt de oplossingsaanvraag.
  6. Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze slagen voor de tests, Azure Firewall Premium pakketten doorsturen naar de toepassings-VM.
  7. De VM reageert en stelt het doel-IP-adres in op Application Gateway. Het Application Gateway subnet stuurt de pakketten om naar Azure Firewall Premium.
  8. Azure Firewall Premium de pakketten doorsturen naar Application Gateway.
  9. Application Gateway verzendt de pakketten naar het VPN.
  10. De VPN-verbinding beantwoordt de client.

Met dit ontwerp moet u mogelijk de routering wijzigen die de hub aan de virtuele spoke-netwerken adverteert. Met name Application Gateway v2 ondersteunt alleen een 0.0.0.0/0-route die naar internet wijst. Routes met dit adres die niet naar internet wijzen, hebben een onderbreking van de connectiviteit die Microsoft nodig heeft voor het beheren van Application Gateway. Als uw virtuele hub een route van 0.0.0.0/0 adverteert, voorkomt u dat die 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 die route aan het subnet waarin u Application Gateway implementeert.
  • Als u een Application Gateway in een toegewezen spoke implementeert, schakelt u de doorvoer van de standaardroute uit in de instellingen voor de virtuele netwerkverbinding.

Voorbeeld van routeserver

Routeserver biedt een andere manier om routes automatisch in spokes te injecteren. Met deze functionaliteit vermijdt u de administratieve overhead van het onderhouden van routetabellen. Route Server combineert de Virtual WAN en hub en spoke-varianten:

  • Met Route Server beheren klanten virtuele hubnetwerken. Als gevolg hiervan kunt u het virtuele hubnetwerk koppelen aan een privé-DNS-zone.
  • Routeserver heeft dezelfde beperking die Virtual WAN heeft met betrekking tot IP-adres voorvoegsels. U kunt alleen routes in een spoke injecteren als het voorvoegsel korter is dan het voorvoegsel van het virtuele netwerk. Vanwege deze beperking moeten Application Gateway en de doelwebserver zich in verschillende virtuele netwerken.

Het volgende diagram toont de pakketstroom wanneer Route Server dynamische routering vereenvoudigt. Let op de volgende punten:

  • Route Server vereist momenteel het apparaat dat de routes injecteert om ze via Border Gateway Protocol (BGP) te verzenden. Omdat Azure Firewall Premium geen ondersteuning biedt voor BGP, gebruikt u in plaats daarvan een virtueel netwerkapparaat (NVA) van derden.
  • De functionaliteit van de NVA in de hub bepaalt of uw implementatie DNS nodig heeft.

Architectuurdiagram met de pakketstroom in een hub en spoke-netwerk met een load balancer, een firewall en routeserver.

  1. Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.
  2. De gateway wordt de clientpakketten doorgestuurd naar Application Gateway.
  3. Application Gateway onderzoekt de pakketten. Als ze de inspectie doorgeven, Application Gateway het subnet de pakketten doorsturen naar een NVA.
  4. De NVA vraagt OM DNS-resolutie van een DNS-server in het virtuele netwerk van de gedeelde services.
  5. De DNS-server beantwoordt de oplossingsaanvraag.
  6. De NVA voert beveiligingscontroles uit op de pakketten. Als ze de tests doorstaan, worden de pakketten door de NVA doorgestuurd naar de toepassings-VM.
  7. De VM reageert en stelt het doel-IP-adres in op Application Gateway. Het Application Gateway subnet stuurt de pakketten om naar de NVA.
  8. De NVA worden de pakketten doorgestuurd naar Application Gateway.
  9. Application Gateway verzendt de pakketten naar de gateway van het virtuele netwerk.
  10. De gateway beantwoordt de client.

Net als Virtual WAN, moet u mogelijk de routering wijzigen wanneer u Route Server gebruikt. Als u de route 0.0.0.0/0 adverteert, wordt deze mogelijk 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 op voor 0.0.0.0/0 en een volgend hoptype Internet van in die tabel.

Volgende stappen