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 omvat vele andere concepten, zoals constante verificatie van de identiteit van de actoren of het tot een minimum beperken van de omvang van de impliciete vertrouwensgebieden. Dit artikel verwijst naar de versleutelings- en inspectiecomponent van een zero-trust-architectuur voor verkeer dat afkomstig is van het openbare internet. Lees andere zero-trust-documenten 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. Een afzonderlijke handleiding, Firewall en Application Gateway voor virtuele netwerken, beschrijft ontwerppatronen 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 werkt. 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. Het wordt uitgevoerd met de optionele toevoeging Azure Web Application Firewall.
Application Gateway ontsleutelt de pakketten en zoekt naar bedreigingen voor webtoepassingen. Als er geen bedreigingen worden gevonden, worden nulvertrouwensprincipes gebruikt om de pakketten te versleutelen. Dan worden ze vrijgegeven.
Azure Firewall Premium voert beveiligingscontroles uit:
- Tls-inspectie (Transport Layer Security) ontsleutelt en onderzoekt de pakketten.
- Functies voor inbraakdetectie en -beveiliging controleren de pakketten op schadelijke bedoelingen.
Als de pakketten de tests doorstaan, voert Azure Firewall Premium de volgende stappen uit:
- Versleutelt de pakketten
- Maakt gebruik van een DNS-service (Domain Name System) om de virtuele machine (VM) van de toepassing 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 sql-codeinjectie en cross-site scripting. Zie voor meer informatie over regels en de Open Web Application Security Project (OWASP) Core Rule Set Web Application Firewall CRS-regelgroepen en -regels.
- 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 netwerkontwerpen, 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
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 zet naar 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 uitgegaan van een standaard HTTPS TCP-poort van 443.
- De verbinding tussen Application Gateway en de webserver ondersteunt alleen TCP-poort 443, niet-standaardpoorten.
Digitale certificaten
In het volgende diagram ziet u de algemene namen (CA's) en certificeringsinstanties (CA's) die door de TLS-sessies en certificaten van de architectuur worden gebruikt:
TLS-verbindingen
Deze architectuur bevat drie verschillende 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 voor Application Gateway als de webserver. 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 beschermt webservers tegen schadelijke clients door HTTP- en HTTPS-aanvragen te onderscheppen. U declareert elke beveiligde server die zich in de back-endpool van Application Gateway met het IP-adres of de FQDN-naam. 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 elke TLS-client accepteert.
- Azure Firewall Premium is een doorsturende webproxy of eenvoudigweg een webproxy. Het beschermt clients tegen schadelijke webservers door TLS-aanroepen van de beveiligde clients te onderscheppen. Wanneer een beveiligde client een HTTP-aanvraag indient, 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.
Voorbeeld van hub en spoke
Normaal gesproken worden in een hub- en spoke-ontwerp gedeelde netwerkonderdelen geïmplementeerd in het virtuele hubnetwerk en toepassingsspecifieke onderdelen in de spokes. In de meeste systemen is Azure Firewall Premium een gedeelde resource. Maar Web Application Firewall kan een gedeeld netwerkapparaat of een toepassingsspecifiek onderdeel zijn. Om de volgende redenen is het meestal het beste om Application Gateway te behandelen als een toepassingsonderdeel en dit te 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 diepgaande 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, overschrijdt u mogelijk Azure Application Gateway limieten.
- U kunt problemen ondervinden met op rollen gebaseerd toegangsbeheer als u Application Gateway in de hub implementeert. Deze situatie kan zich voordoen wanneer teams verschillende toepassingen beheren, maar hetzelfde exemplaar van Application Gateway gebruiken. Elk team heeft vervolgens toegang tot de hele Application Gateway configuratie.
Met traditionele hub- en spoke-architecturen bieden 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.
- Een client verzendt een aanvraag naar een webserver.
- Application Gateway onderschept de clientpakketten en onderzoekt deze. Als de pakketten door de inspectie komen, verzendt de Application Gateway het pakket naar de back-end-VM. Wanneer het pakket Azure bereikt, stuurt een door de gebruiker gedefinieerde route (UDR) in het subnet Application Gateway de pakketten door naar Azure Firewall Premium.
- Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze slagen voor de tests, stuurt Azure Firewall Premium de pakketten door naar de vm van de toepassing.
- De VM reageert en stelt het doel-IP-adres in op de Application Gateway. Een UDR in het VM-subnet leidt de pakketten om naar Azure Firewall Premium.
- Azure Firewall Premium stuurt de pakketten door naar Application Gateway.
- Application Gateway antwoordt de client.
Verkeer kan ook afkomstig zijn van een on-premises netwerk in plaats van van 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 de vorige case.
- Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.
- De gateway stuurt de clientpakketten door naar Application Gateway.
- Application Gateway onderzoekt de pakketten. Als ze de inspectie doorstaan, stuurt een UDR in het Application Gateway-subnet de pakketten door naar Azure Firewall Premium.
- Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze slagen voor de tests, stuurt Azure Firewall Premium de pakketten door naar de vm van de toepassing.
- De VM reageert en stelt het doel-IP-adres in op Application Gateway. Een UDR in het VM-subnet leidt de pakketten om naar Azure Firewall Premium.
- Azure Firewall Premium stuurt de pakketten door naar Application Gateway.
- Application Gateway verzendt de pakketten naar de gateway van het virtuele netwerk.
- 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 routetabellen voor virtuele hubs. De programmering van elk virtueel netwerk dat u verbindt met de hub bevat vervolgens deze routes.
Wanneer u Virtual WAN als netwerkplatform gebruikt, zijn er twee belangrijke verschillen:
U kunt privé-DNS-zones 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 wilt implementeren voor Azure Firewall Premium, 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 van gedeelde services die 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 Host-headers. Zie dns-instellingen Azure Firewall voor meer informatie.
U kunt Virtual WAN alleen gebruiken om routes in een spoke te programmeren als het voorvoegsel korter (minder specifiek) is dan het voorvoegsel van het virtuele netwerk. In de diagrammen boven heeft het spoke-VNet bijvoorbeeld het voorvoegsel 172.16.0.0/16: in dit geval, Virtual WAN zou geen route kunnen injecteren 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 geen verkeer aan te trekken 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 afdwingen via Azure Firewall Premium (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 case die gebruikmaakt van Virtual WAN. In dit geval is toegang tot Application Gateway vanuit een on-premises netwerk. Een site-naar-site-VPN of ExpressRoute verbindt dat netwerk met Virtual WAN. Toegang vanaf internet is vergelijkbaar.
- Een on-premises client maakt verbinding met het VPN.
- De VPN stuurt de clientpakketten door naar Application Gateway.
- Application Gateway onderzoekt de pakketten. Als ze de inspectie doorstaan, stuurt het Application Gateway-subnet de pakketten door naar Azure Firewall Premium.
- Azure Firewall Premium vraagt DNS-omzetting aan van een DNS-server in het virtuele netwerk van gedeelde services.
- De DNS-server beantwoordt de omzettingsaanvraag.
- Azure Firewall Premium voert beveiligingscontroles uit op de pakketten. Als ze slagen voor de tests, stuurt Azure Firewall Premium de pakketten door naar de vm van de toepassing.
- De VM reageert en stelt het doel-IP-adres in op Application Gateway. Het subnet van de toepassing leidt de pakketten om naar Azure Firewall Premium.
- Azure Firewall Premium stuurt de pakketten door naar Application Gateway.
- Application Gateway verzendt de pakketten naar het VPN.
- De VPN beantwoordt de client.
Met dit ontwerp moet u mogelijk de routering wijzigen die de hub adverteert naar de virtuele spoke-netwerken. Met name Application Gateway v2 ondersteunt alleen een 0.0.0.0/0-route die naar internet verwijst. Routes met dit adres die niet naar internet verwijzen, 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 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 Application Gateway in een toegewezen spoke implementeert, schakelt u de doorgifte van de standaardroute uit in de instellingen voor de virtuele netwerkverbinding.
Voorbeeld van routeserver
RouteServer biedt een andere manier om routes automatisch in spaken 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 netwerk van de hub koppelen aan een privé-DNS-zone.
- Routeserver heeft dezelfde beperking die Virtual WAN heeft met betrekking tot IP-adresvoorvoegsels. U kunt alleen routes in een spaak invoegen 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 routeserver dynamische routering vereenvoudigt. Let op de volgende punten:
- RouteServer vereist momenteel het apparaat dat de routes injecteert om ze via Border Gateway Protocol (BGP) te verzenden. Aangezien Azure Firewall Premium geen ondersteuning biedt voor BGP, moet u in plaats daarvan een NVA (Network Virtual Appliance) van derden gebruiken.
- De functionaliteit van de NVA in de hub bepaalt of uw implementatie DNS nodig heeft.
- Een on-premises client maakt verbinding met de gateway van het virtuele netwerk.
- De gateway stuurt de clientpakketten door naar Application Gateway.
- 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 wordt geïnjecteerd, stuurt het verkeer door naar een NVA.
- De NVA voert beveiligingscontroles uit op de pakketten. Als ze slagen voor de tests, stuurt de NVA de pakketten door naar de toepassings-VM.
- De VM reageert en stelt het doel-IP-adres in op Application Gateway. Een route die door de routeserver in het VM-subnet wordt geïnjecteerd, leidt de pakketten om naar de NVA.
- De NVA stuurt de pakketten door naar Application Gateway.
- Application Gateway verzendt de pakketten naar de gateway van het virtuele netwerk.
- De gateway beantwoordt de client.
Net als bij Virtual WAN moet u mogelijk de routering wijzigen wanneer u routeserver gebruikt. Als u de route 0.0.0.0/0 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 in Internet die tabel op.
Medewerkers
Dit artikel wordt onderhouden door Microsoft. Het is oorspronkelijk geschreven door de volgende inzenders.
Hoofdauteur:
- Jose Moreno | Principal Customer Engineer
Volgende stappen
- Netwerken beveiligen met zero trust
- Routering van verkeer in virtuele netwerken
- Hoe een toepassingsgateway werkt