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

In deze handleiding wordt een strategie beschreven voor het implementeren van zero-trust-beveiliging voor web-apps voor inspectie en versleuteling. Het zero-trust paradigma bevat veel andere concepten, zoals constante verificatie van de identiteit van de actoren of het verminderen van de grootte van de impliciete vertrouwensgebieden tot een minimum. Dit artikel verwijst naar het versleutelings- en inspectieonderdeel van een zero-trust-architectuur voor binnenkomend verkeer vanaf het openbare internet. Lees andere documenten met nul vertrouwen voor meer aspecten van het veilig implementeren van uw toepassing, zoals verificatie. Voor dit artikel werkt een meerlaagse benadering het beste, waarbij netwerkbeveiliging een van de lagen van het zero-trust-model vormt. 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.

In sommige situaties kunt u verschillende typen netwerkbeveiligingsapparaten combineren om de beveiliging te verbeteren. In een afzonderlijke handleiding, Firewall en Application Gateway voor virtuele netwerken, worden ontwerppatronen beschreven die u kunt gebruiken om de verschillende apparaten te rangschikken. Dit document is gericht op een gemeenschappelijk patroon voor het maximaliseren van beveiliging, waarbij Azure-toepassing Gateway voor Azure Firewall Premium fungeert. In het volgende diagram ziet u dit patroon:

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.

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

• Application Gateway ontsleutelt de pakketten en zoekt naar bedreigingen voor webtoepassingen. Als er geen bedreigingen worden gevonden, worden er nulvertrouwensprincipes gebruikt om de pakketten te versleutelen. Vervolgens worden ze vrijgegeven.

• Azure Firewall Premium voert beveiligingscontroles uit:

  • Tls-inspectie (Transport Layer Security) ontsleutelt en onderzoekt de pakketten.
  • Inbraakdetectie- en beveiligingsfuncties controleren de pakketten op schadelijke bedoelingen.

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

  • Versleutelt de pakketten
  • Maakt gebruik van een DNS-service (Domain Name System) om de virtuele machine van de toepassing (VM) te bepalen
  • Stuurt de pakketten door naar de toepassings-VM

Verschillende inspectie-engines in deze architectuur zorgen voor verkeersintegriteit:

• 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 Crs-regelgroepen en -regels voor Web Application Firewall voor meer informatie over regels en de Core Rule Set open Web Application Security Project (OWASP).
• 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, waarin in dit artikel wordt 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

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 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, zoals in latere secties wordt beschreven.

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 de architectuur worden gebruikt:

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.

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-certificaten voor 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 heeft ondertekend. Gebruik een CA die door een TLS-client wordt geaccepteerd.
• Azure Firewall Premium is een doorstuurwebproxy 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 doorstuurproxy 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 de details beschreven van voorbeelden van hub- en spoke-, Virtual WAN- en routeservertopologie. Er zijn echter enkele aspecten die gebruikelijk zijn voor alle topologieën:

• Azure-toepassing Gateway gedraagt zich altijd als een proxy en Azure Firewall Premium doet dit ook wanneer deze is geconfigureerd voor TLS-inspectie: de TLS-sessies van clients worden beëindigd door Application Gateway en er worden nieuwe TLS-sessies gebouwd voor Azure Firewall. Azure Firewall ontvangt en beëindigt de TLS-sessies die afkomstig zijn van de Application Gateway en bouwt nieuwe TLS-sessies voor de workloads. Dit feit heeft gevolgen voor de IDPS-configuratie van Azure Firewall Premium, secties hieronder bevatten meer informatie hierover.
• De workload ziet verbindingen die afkomstig zijn van het IP-adres van het subnet van Azure Firewall. Het oorspronkelijke IP-adres van de client blijft behouden in de X-Forwarded-For HTTP-header die is ingevoegd door de Application Gateway.
• Verkeer van de Application Gateway naar de workload wordt doorgaans verzonden naar de Azure Firewall met behulp van Azure-routeringsmechanismen, met door de gebruiker gedefinieerde routes die zijn geconfigureerd in het subnet van Application Gateway of met routes die zijn geïnjecteerd door Azure Virtual WAN of Azure Route Server. Hoewel het expliciet definiëren van het privé-IP-adres van De Azure Firewall in de back-endpool van Application Gateway mogelijk is, wordt het technisch niet aanbevolen omdat het een deel van de functionaliteit van Azure Firewall wegneemt, zoals taakverdeling en plakbaarheid.

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

Stertopologie

Normaal gesproken implementeert een hub- en spoke-ontwerp gedeelde netwerkonderdelen in het virtuele hubnetwerk en toepassingsspecifieke onderdelen in de spokes. In de meeste systemen is Azure Firewall Premium een gedeelde resource. Web Application Firewall kan echter een gedeeld netwerkapparaat of een toepassingsspecifiek onderdeel zijn. Om de volgende redenen kunt u Application Gateway het beste behandelen als een toepassingsonderdeel en implementeren in een virtueel spoke-netwerk:

• Het kan lastig zijn om problemen met 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 Azure-toepassing 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.

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

• Configureer een privé-DNS-zone.
• Koppel de zone aan het virtuele netwerk dat Azure Firewall Premium bevat.
• Zorg ervoor dat er een A-record 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.

1. Een client verzendt een aanvraag naar een webserver.
2. Application Gateway onderschept de clientpakketten en onderzoekt deze. Als de pakketten worden gecontroleerd, stuurt application gateway het pakket naar de back-end-VM. Wanneer het pakket azure raakt, stuurt een door de gebruiker gedefinieerde route (UDR) in het Application Gateway-subnet de pakketten 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 Application Gateway. 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 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.

1. Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.
2. De gateway 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 beantwoordt de client.

Virtual WAN-topologie

U kunt de netwerkservice Virtual WAN ook in deze architectuur gebruiken. 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 voor het koppelen van privé-DNS-zones. 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 AZURE Firewall DNS-Instellingen 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 Azure Firewall DNS-Instellingen 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 diagrammen boven het spoke-VNet heeft bijvoorbeeld het voorvoegsel 172.16.0.0/16: in dit geval, Virtual WAN kan geen route invoeren die overeenkomt met het VNet-voorvoegsel (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 aantrekken tussen twee subnetten die zich in hetzelfde VNet 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 (een tijdelijke oplossing is het handmatig configureren van door de gebruiker gedefinieerde routes in de subnetten van de Application Gateway en webserver).

In het volgende diagram ziet u de pakketstroom in een geval waarin Virtual WAN wordt gebruikt. 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.

1. Een on-premises client maakt verbinding met het VPN.
2. De VPN 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 toepassingssubnet leidt 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.
10. De VPN beantwoordt de client.

Met dit ontwerp moet u mogelijk de routering wijzigen die door de hub naar de virtuele spoke-netwerken wordt geadverteerd. Application Gateway v2 ondersteunt alleen een route van 0.0.0.0/0 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 route van 0.0.0.0/0 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

Route Server biedt een andere manier om routes automatisch in spokes te injecteren. Met deze functionaliteit voorkomt 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 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. Let op deze punten:

• Routeserver vereist momenteel het apparaat dat de routes injecteert om ze te verzenden via Border Gateway Protocol (BGP). Omdat Azure Firewall Premium geen BGP ondersteunt, gebruikt u in plaats daarvan een NVA (Network Virtual Appliance) van derden.
• De functionaliteit van de NVA in de hub bepaalt of uw implementatie DNS nodig heeft.

1. Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.
2. De gateway stuurt de clientpakketten door naar Application Gateway.
3. Application Gateway onderzoekt de pakketten. Als ze de inspectie doorstaan, stuurt het Application Gateway-subnet de pakketten door naar een back-endcomputer. Een route in het ApplicationGateway-subnet dat door de routeserver is geïnjecteerd, stuurt het verkeer door naar een NVA.
4. De NVA voert beveiligingscontroles uit op de pakketten. Als ze de tests doorstaan, stuurt de NVA de pakketten door naar de toepassings-VM.
5. De VIRTUELE machine reageert en stelt het doel-IP-adres in op Application Gateway. Een route die door de routeserver is geïnjecteerd in het VM-subnet, leidt de pakketten om naar de NVA.
6. De NVA stuurt de pakketten door naar Application Gateway.
7. Application Gateway verzendt de pakketten naar de gateway van het virtuele netwerk.
8. De gateway beantwoordt de client.

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

IDPS en privé-IP-adressen

Zoals uitgelegd in Azure Firewall IDPS-regels, bepaalt Azure Firewall Premium welke IDPS-regels moeten worden toegepast, afhankelijk van de bron- en doel-IP-adressen van de pakketten. Azure Firewall behandelt standaard privé-IP-adressen in de RFC 1918-bereiken (10.0.0.0/8192.168.0.0/16en) en 172.16.0.0/12RFC 6598-bereik (100.64.0.0/10) als intern. Als in de diagrammen in dit artikel de Application Gateway wordt geïmplementeerd in een subnet in een van deze bereiken (172.16.0.0/24 in de bovenstaande voorbeelden), wordt in Azure Firewall Premium rekening gehouden met verkeer tussen de Application Gateway en de werkbelasting als intern en worden alleen IDPS-handtekeningen gebruikt die zijn gemarkeerd om te worden toegepast op intern verkeer of op verkeer. IDPS-handtekeningen die zijn gemarkeerd om te worden toegepast op binnenkomend of uitgaand verkeer, worden niet toegepast op verkeer tussen de Application Gateway en de workload.

De eenvoudigste manier om binnenkomende idPS-handtekeningregels toe te passen op het verkeer tussen Application Gateway en de workload, is door de Application Gateway in een subnet te plaatsen met een voorvoegsel buiten de privébereiken. U hoeft niet per se openbare IP-adressen voor dit subnet te gebruiken, maar in plaats daarvan kunt u de IP-adressen aanpassen die Azure Firewall Premium als intern behandelt 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 (zie privé-IPDS-bereiken van Azure Firewall Premium voor meer informatie over hoe u dit doet) en application gateway implementeren in een subnet dat is geconfigureerd met een IP-adres in 100.64.0.0/10.

Medewerkers

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

Hoofdauteur:

• Jose Moreno | Principal Customer Engineer

Volgende stappen

• Netwerken beveiligen met nul vertrouwen
• Routering van verkeer in virtuele netwerken
• Hoe een toepassingsgateway werkt

Verwante resources

• Workloads beveiligen en beheren met segmentatie op netwerkniveau
• Een beveiligd hybride netwerk implementeren
• Hub-spoke-netwerktopologie in Azure
• Sternetwerktopologie met Azure Virtual WAN