Application Gateway-integratie

Voor drie variaties van Azure-app Service is een iets andere configuratie van de integratie met Azure-toepassing Gateway vereist. De variaties omvatten reguliere App Service (ook wel multitenant genoemd), een interne load balancer (ILB) App Service Environment en een externe App Service-omgeving.

In dit artikel wordt uitgelegd hoe u Application Gateway configureert met App Service (multitenant) met behulp van service-eindpunten om verkeer te beveiligen. In het artikel worden ook overwegingen besproken over het gebruik van privé-eindpunten en het integreren met ILB en externe App Service Environments. Ten slotte wordt in het artikel beschreven hoe u toegangsbeperkingen instelt op een SCM-site (Source Control Manager).

Integratie met App Service (multitenant)

App Service (multitenant) heeft een openbaar internetgericht eindpunt. Met behulp van service-eindpunten kunt u verkeer van alleen een specifiek subnet in een virtueel Azure-netwerk toestaan en alles anders blokkeren. In het volgende scenario gebruikt u deze functionaliteit om ervoor te zorgen dat een App Service-exemplaar alleen verkeer van een specifieke toepassingsgateway kan ontvangen.

Er zijn twee onderdelen voor deze configuratie, afgezien van het maken van het App Service-exemplaar en de toepassingsgateway. Het eerste deel is het inschakelen van service-eindpunten in het subnet van het virtuele netwerk waar de toepassingsgateway wordt geïmplementeerd. Service-eindpunten zorgen ervoor dat al het netwerkverkeer dat het subnet naar App Service verlaat, wordt gelabeld met de specifieke subnet-id.

Het tweede deel is het instellen van een toegangsbeperking voor de specifieke web-app om ervoor te zorgen dat alleen verkeer dat is getagd met deze specifieke subnet-id is toegestaan. U kunt de toegangsbeperking configureren met behulp van verschillende hulpprogramma's, afhankelijk van uw voorkeur.

Services instellen met behulp van Azure Portal

Met Azure Portal volgt u vier stappen om de installatie van App Service en Application Gateway te maken en te configureren. Als u bestaande resources hebt, kunt u de eerste stappen overslaan.

1. Maak een App Service-exemplaar met behulp van een van de quickstarts in de App Service-documentatie. Een voorbeeld hiervan is de quickstart voor .NET Core.
2. Maak een toepassingsgateway met behulp van de quickstart van de portal, maar sla de sectie over het toevoegen van back-enddoelen over.
3. Configureer App Service als back-end in Application Gateway, maar sla de sectie over het beperken van de toegang over.
4. Maak de toegangsbeperking met behulp van service-eindpunten.

U hebt nu toegang tot App Service via Application Gateway. Als u rechtstreeks toegang probeert te krijgen tot App Service, ontvangt u een HTTP-fout van 403 met de mededeling dat de web-app uw toegang heeft geblokkeerd.

Services instellen met behulp van een Azure Resource Manager-sjabloon

Met de Azure Resource Manager-implementatiesjabloon wordt een volledig scenario gemaakt. Het scenario bestaat uit een App Service-exemplaar dat is vergrendeld met service-eindpunten en een toegangsbeperking om alleen verkeer van Application Gateway te ontvangen. De sjabloon bevat veel slimme standaardwaarden en unieke postfixes die aan de resourcenamen zijn toegevoegd om deze eenvoudig te houden. Als u deze wilt overschrijven, moet u de opslagplaats klonen of de sjabloon downloaden en bewerken.

Als u de sjabloon wilt toepassen, kunt u de knop Implementeren in Azure gebruiken in de beschrijving van de sjabloon. U kunt ook de juiste PowerShell- of Azure CLI-code gebruiken.

Services instellen met behulp van de Azure CLI

Het Azure CLI-voorbeeld maakt een App Service-exemplaar dat is vergrendeld met service-eindpunten en een toegangsbeperking om alleen verkeer van Application Gateway te ontvangen. Als u alleen verkeer naar een bestaand App Service-exemplaar van een bestaande toepassingsgateway hoeft te isoleren, gebruikt u de volgende opdracht:

az webapp config access-restriction add --resource-group myRG --name myWebApp --rule-name AppGwSubnet --priority 200 --subnet mySubNetName --vnet-name myVnetName

In de standaardconfiguratie zorgt de opdracht voor het instellen van de configuratie van het service-eindpunt in het subnet en de toegangsbeperking in App Service.

Overwegingen voor het gebruik van privé-eindpunten

Als alternatief voor service-eindpunten kunt u privé-eindpunten gebruiken om verkeer tussen Application Gateway en App Service (multitenant) te beveiligen. U moet ervoor zorgen dat Application Gateway DNS kan gebruiken om het privé-IP-adres van de App Service-apps om te zetten. U kunt ook het privé-IP-adres in de back-endpool gebruiken en de hostnaam overschrijven in de HTTP-instellingen.

Application Gateway slaat de DNS-opzoekresultaten in de cache op. Als u FQDN's (Fully Qualified Domain Names) gebruikt en afhankelijk bent van DNS-zoekacties om het privé-IP-adres op te halen, moet u de toepassingsgateway mogelijk opnieuw opstarten als de DNS-update of de koppeling naar een privé-DNS-zone van Azure is opgetreden nadat u de back-endpool hebt geconfigureerd.

Als u de toepassingsgateway opnieuw wilt starten, stopt u deze en start u deze met behulp van de Azure CLI:

az network application-gateway stop --resource-group myRG --name myAppGw
az network application-gateway start --resource-group myRG --name myAppGw

Overwegingen voor een ILB App Service-omgeving

Een ILB App Service Environment wordt niet blootgesteld aan internet. Verkeer tussen het exemplaar en een toepassingsgateway is al geïsoleerd naar het virtuele netwerk. Als u een ILB App Service Environment wilt configureren en deze wilt integreren met een toepassingsgateway met behulp van Azure Portal, raadpleegt u de handleiding.

Als u ervoor wilt zorgen dat alleen verkeer van het Application Gateway-subnet de App Service-omgeving bereikt, kunt u een netwerkbeveiligingsgroep (NSG) configureren die van invloed is op alle web-apps in de App Service-omgeving. Voor de NSG kunt u het IP-adresbereik van het subnet en eventueel de poorten (80/443) opgeven. Zorg ervoor dat u de vereiste NSG-regels niet overschrijft om de App Service Environment correct te laten functioneren.

Als u verkeer naar een afzonderlijke web-app wilt isoleren, moet u op IP gebaseerde toegangsbeperkingen gebruiken, omdat service-eindpunten niet werken met een App Service-omgeving. Het IP-adres moet het privé-IP-adres van de toepassingsgateway zijn.

Overwegingen voor een externe App Service-omgeving

Een externe App Service-omgeving heeft een openbare load balancer, zoals multitenant App Service. Service-eindpunten werken niet voor een App Service Environment. Daarom moet u op IP gebaseerde toegangsbeperkingen gebruiken met behulp van het openbare IP-adres van de toepassingsgateway. Als u een externe App Service-omgeving wilt maken met behulp van Azure Portal, kunt u deze quickstart volgen.

Overwegingen voor een Kudu/SCM-site

De SCM-site, ook wel Kudu genoemd, is een beheersite die bestaat voor elke web-app. Het is niet mogelijk om omgekeerde proxy te gebruiken voor de SCM-site. U wilt deze waarschijnlijk ook vergrendelen naar afzonderlijke IP-adressen of een specifiek subnet.

Als u dezelfde toegangsbeperkingen wilt gebruiken als de hoofdsite, kunt u de instellingen overnemen met behulp van de volgende opdracht:

az webapp config access-restriction set --resource-group myRG --name myWebApp --use-same-restrictions-for-scm-site

Als u afzonderlijke toegangsbeperkingen voor de SCM-site wilt toevoegen, kunt u de --scm-site vlag gebruiken:

az webapp config access-restriction add --resource-group myRG --name myWebApp --scm-site --rule-name KudoAccess --priority 200 --ip-address 208.130.0.0/16

Overwegingen voor het gebruik van het standaarddomein

Het configureren van Application Gateway om de hostnaam te overschrijven en het standaarddomein van App Service (meestal azurewebsites.net) te gebruiken, is de eenvoudigste manier om de integratie te configureren. Hiervoor hoeft u geen aangepast domein en certificaat in App Service te configureren.

In dit artikel worden de algemene overwegingen besproken voor het overschrijven van de oorspronkelijke hostnaam. In App Service zijn er twee scenario's waarin u aandacht moet besteden aan deze configuratie.

Verificatie

Wanneer u de verificatiefunctie in App Service (ook wel Easy Auth genoemd) gebruikt, wordt uw app doorgaans omgeleid naar de aanmeldingspagina. Omdat App Service de oorspronkelijke hostnaam van de aanvraag niet kent, wordt de omleiding uitgevoerd op de standaarddomeinnaam en resulteert dit meestal in een fout.

Als u de standaardomleiding wilt omzeilen, kunt u verificatie configureren om een doorgestuurde header te controleren en het omleidingsdomein aan te passen aan het oorspronkelijke domein. Application Gateway maakt gebruik van een header met de naam X-Original-Host. Met behulp van configuratie op basis van bestanden om verificatie te configureren, kunt u App Service configureren om zich aan te passen aan de oorspronkelijke hostnaam. Voeg deze configuratie toe aan uw configuratiebestand:

{
    ...
    "httpSettings": {
        "forwardProxy": {
            "convention": "Custom",
            "customHostHeaderName": "X-Original-Host"
        }
    }
    ...
}

ARR-affiniteit

Bij implementaties met meerdere exemplaren zorgt ARR-affiniteit ervoor dat clientaanvragen worden gerouteerd naar hetzelfde exemplaar voor de levensduur van de sessie. ARR-affiniteit werkt niet met onderdrukkingen van hostnamen. Sessieaffiniteit werkt alleen als u een identiek aangepast domein en certificaat in App Service en in Application Gateway configureert en de hostnaam niet overschrijft.

Volgende stappen

Zie de Documentatie voor App Service Environment voor meer informatie over App Service Environment-omgevingen.

Als u uw web-app verder wilt beveiligen, vindt u informatie over Azure Web Application Firewall in Application Gateway in de documentatie van Azure Web Application Firewall.

Zie deze zelfstudie voor het implementeren van een beveiligde, flexibele site met een aangepast domein in App Service met behulp van Azure Front Door of Application Gateway.