Binnenkomend verkeer naar een App Service-omgeving beheren

Overzicht

Een App Service-omgeving kan worden gemaakt in een virtueel Azure Resource Manager-netwerk of een virtueel netwerk van een klassiek implementatiemodel. Er kan een nieuw virtueel netwerk en een nieuw subnet worden gedefinieerd op het moment dat een App Service-omgeving wordt gemaakt. In plaats daarvan kan een App Service-omgeving worden gemaakt in een bestaand virtueel netwerk en een bestaand subnet. Vanaf juni 2016 kunnen ASE's ook worden geïmplementeerd in virtuele netwerken die gebruikmaken van openbare adresbereiken of RFC1918 adresruimten (privéadressen). Zie Een ASEv1 maken op basis van een sjabloon voor meer informatie.

Maak altijd een App Service-omgeving binnen een subnet. Een subnet biedt een netwerkgrens die kan worden gebruikt om binnenkomend verkeer achter upstream-apparaten en -services te vergrendelen. Met deze instelling kunnen alleen specifieke upstream-IP-adressen HTTP- en HTTPS-verkeer accepteren.

Binnenkomend en uitgaand netwerkverkeer op een subnet wordt beheerd met behulp van een netwerkbeveiligingsgroep. Als u inkomend verkeer wilt beheren, maakt u netwerkbeveiligingsregels in een netwerkbeveiligingsgroep. Wijs vervolgens de netwerkbeveiligingsgroep toe aan het subnet met de App Service-omgeving.

Zodra u een netwerkbeveiligingsgroep aan een subnet hebt toegewezen, wordt inkomend verkeer naar apps in de App Service-omgeving toegestaan of geblokkeerd op basis van de regels voor toestaan en weigeren die zijn gedefinieerd in de netwerkbeveiligingsgroep.

Inkomende netwerkpoorten gebruikt in een App Service Environment

Voordat u binnenkomend netwerkverkeer met een netwerkbeveiligingsgroep vergrendelt, moet u de set vereiste en optionele netwerkpoorten kennen die worden gebruikt door een App Service-omgeving. Het per ongeluk afsluiten van verkeer naar sommige poorten kan leiden tot verlies van functionaliteit in een App Service-omgeving.

De volgende lijst bevat de poorten die worden gebruikt door een App Service Environment. Alle poorten zijn TCP, tenzij anders vermeld:

• 454: Vereiste poort die wordt gebruikt door de Azure-infrastructuur voor het beheren en onderhouden van App Service Environments via TLS. Verkeer naar deze poort niet blokkeren. Deze poort is altijd gebonden aan het openbare VIP van een ASE.
• 455: Vereiste poort die wordt gebruikt door de Azure-infrastructuur voor het beheren en onderhouden van App Service Environments via TLS. Verkeer naar deze poort niet blokkeren. Deze poort is altijd gebonden aan het openbare VIP van een ASE.
• 80: Standaardpoort voor binnenkomend HTTP-verkeer naar apps die worden uitgevoerd in App Service-plannen in een App Service-omgeving. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.
• 443: Standaardpoort voor binnenkomend TLS-verkeer naar apps die worden uitgevoerd in App Service-plannen in een App Service-omgeving. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.
• 21: Besturingskanaal voor FTP. Deze poort kan veilig worden geblokkeerd als FTP niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit kan deze poort worden gebonden aan het ILB-adres voor een ASE.
• 990: Besturingskanaal voor FTPS. Deze poort kan veilig worden geblokkeerd als FTPS niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit kan deze poort worden gebonden aan het ILB-adres voor een ASE.
• 10001-10020: Gegevenskanalen voor FTP. Net als bij het besturingskanaal kunnen deze poorten veilig worden geblokkeerd als FTP niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit kan deze poort worden gebonden aan het ILB-adres van de ASE.
• 4016: Wordt gebruikt voor externe foutopsporing met Visual Studio 2012. Deze poort kan veilig worden geblokkeerd als de functie niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.
• 4018: Wordt gebruikt voor externe foutopsporing met Visual Studio 2013. Deze poort kan veilig worden geblokkeerd als de functie niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.
• 4020: Wordt gebruikt voor externe foutopsporing met Visual Studio 2015. Deze poort kan veilig worden geblokkeerd als de functie niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.
• 4022: Wordt gebruikt voor externe foutopsporing met Visual Studio 2017. Deze poort kan veilig worden geblokkeerd als de functie niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.
• 4024 Gebruikt voor externe foutopsporing met Visual Studio 2019. Deze poort kan veilig worden geblokkeerd als de functie niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.
• 4026: Wordt gebruikt voor externe foutopsporing met Visual Studio 2022. Deze poort kan veilig worden geblokkeerd als de functie niet wordt gebruikt. Op een AS-omgeving met ILB-functionaliteit is deze poort gebonden aan het ILB-adres van de ASE.

Vereisten voor uitgaande verbindingen en DNS

Om een App Service-omgeving goed te laten functioneren, is ook uitgaande toegang tot verschillende eindpunten vereist. Een volledige lijst met de externe eindpunten die door een ASE worden gebruikt, bevindt zich in de sectie Vereist netwerk Verbinding maken iviteit van het artikel Netwerkconfiguratie voor ExpressRoute.

Voor App Service Environments is een geldige DNS-infrastructuur vereist die is geconfigureerd voor het virtuele netwerk. Als de DNS-configuratie wordt gewijzigd na het maken van een App Service Environment, kunnen ontwikkelaars afdwingen dat een App Service Environment de nieuwe DNS-configuratie ophaalt. Als u een rolling omgeving opnieuw opstart met behulp van het pictogram Opnieuw opstarten, wordt de nieuwe DNS-configuratie door de omgeving opgehaald. (De Het pictogram Opnieuw opstarten bevindt zich boven aan de blade App Service Environment-beheer in Azure Portal.)

Het wordt ook aanbevolen dat aangepaste DNS-servers op het vnet van tevoren worden ingesteld voordat u een App Service-omgeving maakt. Als de DNS-configuratie van een virtueel netwerk wordt gewijzigd tijdens het maken van een App Service Environment, mislukt het maken van de App Service-omgeving. Als er een aangepaste DNS-server is die niet bereikbaar is of niet beschikbaar is aan het andere uiteinde van een VPN-gateway, mislukt het maken van de App Service-omgeving ook.

Een netwerkbeveiligingsgroep maken

Zie de volgende informatie voor meer informatie over de werking van netwerkbeveiligingsgroepen. In het onderstaande voorbeeld van Azure Service Management worden de hoogtepunten van netwerkbeveiligingsgroepen beschreven. In het voorbeeld wordt een netwerkbeveiligingsgroep geconfigureerd en toegepast op een subnet dat een App Service-omgeving bevat.

Opmerking: netwerkbeveiligingsgroepen kunnen grafisch worden geconfigureerd met behulp van Azure Portal of via Azure PowerShell.

Netwerkbeveiligingsgroepen worden eerst gemaakt als een zelfstandige entiteit die is gekoppeld aan een abonnement. Omdat netwerkbeveiligingsgroepen worden gemaakt in een Azure-regio, maakt u de netwerkbeveiligingsgroep in dezelfde regio als de App Service-omgeving.

De volgende opdracht laat zien hoe u een netwerkbeveiligingsgroep maakt:

New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"

Zodra een netwerkbeveiligingsgroep is gemaakt, worden er een of meer netwerkbeveiligingsregels aan toegevoegd. Aangezien de set regels na verloop van tijd kan veranderen, moet u het nummeringsschema dat wordt gebruikt voor regelprioriteiten uitzetten. Met deze procedure kunt u eenvoudig aanvullende regels in de loop van de tijd invoegen.

In het onderstaande voorbeeld verleent een regel expliciet toegang tot de beheerpoorten die nodig zijn voor de Azure-infrastructuur voor het beheren en onderhouden van een App Service-omgeving. Alle beheerverkeersstromen via TLS en worden beveiligd door clientcertificaten. Hoewel de poorten worden geopend, zijn ze niet toegankelijk voor elke andere entiteit dan de Azure-beheerinfrastructuur.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

Wanneer u de toegang tot poort 80 en 443 vergrendelt om een App Service Environment achter upstream-apparaten of -services te verbergen, moet u het upstream-IP-adres onthouden. Als u bijvoorbeeld een Web Application Firewall (WAF) gebruikt, heeft de WAF een eigen IP-adres of -adressen. De WAF gebruikt deze bij het proxyen van verkeer naar een downstream App Service Environment. U moet dit IP-adres gebruiken in de parameter SourceAddressPrefix van een netwerkbeveiligingsregel.

In het onderstaande voorbeeld is binnenkomend verkeer van een specifiek upstream IP-adres expliciet toegestaan. Het adres 1.2.3.4 wordt gebruikt als tijdelijke aanduiding voor het IP-adres van een upstream WAF. Wijzig de waarde zodat deze overeenkomt met het adres dat wordt gebruikt door uw upstream-apparaat of -service.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTP" -Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTPS" -Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Als FTP-ondersteuning is vereist, gebruikt u de volgende regels als sjabloon om toegang te verlenen tot de FTP-besturingspoort en gegevenskanaalpoorten. Omdat FTP een stateful protocol is, kunt u MOGELIJK GEEN FTP-verkeer routeren via een traditionele HTTP/HTTPS-firewall of proxyapparaat. In dit geval moet u sourceAddressPrefix instellen op een andere waarde, zoals het IP-adresbereik van ontwikkelaars- of implementatiemachines waarop FTP-clients worden uitgevoerd.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPCtrl" -Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '21' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPDataRange" -Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '10001-10020' -Protocol TCP

(Opmerking: het poortbereik van het gegevenskanaal kan tijdens de preview-periode veranderen.)

Als externe foutopsporing met Visual Studio wordt gebruikt, laten de volgende regels zien hoe u toegang kunt verlenen. Er is een afzonderlijke regel voor elke ondersteunde versie van Visual Studio, omdat elke versie een andere poort gebruikt voor externe foutopsporing. Net als bij FTP-toegang kan extern foutopsporingsverkeer mogelijk niet goed stromen via een traditioneel WAF- of proxyapparaat. Het SourceAddressPrefix kan in plaats daarvan worden ingesteld op het IP-adresbereik van ontwikkelaarsmachines waarop Visual Studio wordt uitgevoerd.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2012" -Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4016' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2013" -Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4018' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2015" -Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4020' -Protocol TCP

Een netwerkbeveiligingsgroep toewijzen aan een subnet

Een netwerkbeveiligingsgroep heeft een standaardbeveiligingsregel die de toegang tot al het externe verkeer weigert. Wanneer u deze regel combineert met de bovenstaande netwerkbeveiligingsregels, kan alleen verkeer van bronadresbereiken die zijn gekoppeld aan een actie Toestaan verkeer verzenden naar apps die worden uitgevoerd in een App Service-omgeving.

Nadat een netwerkbeveiligingsgroep is gevuld met beveiligingsregels, wijst u deze toe aan het subnet met de App Service-omgeving. De opdrachttoewijzing verwijst naar twee namen: de naam van het virtuele netwerk waar de App Service-omgeving zich bevindt en de naam van het subnet waarin de App Service-omgeving is gemaakt.

In het onderstaande voorbeeld ziet u een netwerkbeveiligingsgroep die wordt toegewezen aan een subnet en een virtueel netwerk:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

De toewijzing is een langdurige bewerking en het kan enkele minuten duren voordat de toewijzing is voltooid. Zodra de toewijzing van de netwerkbeveiligingsgroep is geslaagd, bereikt u alleen inkomend verkeer dat overeenkomt met regels voor toestaan apps in de App Service-omgeving.

Voor volledigheid ziet u in het volgende voorbeeld hoe u de netwerkbeveiligingsgroep uit het subnet verwijdert en ontkoppelt:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

Speciale overwegingen voor expliciete IP-SSL

Als een app is geconfigureerd met een expliciet IP-SSL-adres (alleen van toepassing op AS's met een openbaar VIP), in plaats van het standaard-IP-adres van de App Service-omgeving te gebruiken, stromen zowel HTTP- als HTTPS-verkeer naar het subnet via poorten anders dan poort 80 en 443.

Als u het afzonderlijke paar poorten wilt vinden dat door elk IP-SSL-adres wordt gebruikt, gaat u naar de portal en bekijkt u de UX-blade met details van de App Service Environment. Selecteer Alle IP-adressen voor instellingen>. Op de blade IP-adressen ziet u een tabel met alle expliciet geconfigureerde IP-SSL-adressen voor de App Service Environment. Op de blade ziet u ook het speciale poortpaar dat wordt gebruikt voor het routeren van HTTP- en HTTPS-verkeer dat is gekoppeld aan elk IP-SSL-adres. Gebruik dit poortpaar voor de Parameters DestinationPortRange bij het configureren van regels in een netwerkbeveiligingsgroep.

Wanneer een app op een ASE is geconfigureerd voor het gebruik van IP-SSL, zien externe klanten de speciale toewijzing van poortenpaar niet of hoeven ze zich geen zorgen te maken. Verkeer naar de apps stroomt normaal naar het geconfigureerde IP-SSL-adres. De vertaling naar het speciale poortpaar vindt automatisch intern plaats, tijdens het laatste been van het routeringsverkeer in het subnet dat de ASE bevat.

Aan de slag

Zie Inleiding tot App Service Environment om aan de slag te gaan met App Service Environment.

Zie Veilig verbinding maken met back-endresources vanuit een App Service-omgeving voor meer informatie.