Delen via

Binnenkomend verkeer naar een App Service-omgeving beheren

  • Artikel

Belangrijk

Dit artikel gaat over App Service Environment v1. App Service Environment v1 en v2 worden vanaf 31 augustus 2024 buiten gebruik gesteld. Er is een nieuwe versie van App Service Environment die eenvoudiger te gebruiken is en wordt uitgevoerd op een krachtigere infrastructuur. Voor meer informatie over de nieuwe versie begint u met de inleiding tot de App Service-omgeving. Als u momenteel App Service Environment v1 gebruikt, volgt u de stappen in dit artikel om te migreren naar de nieuwe versie.

Vanaf 31 augustus 2024 zijn Service Level Agreement (SLA) en servicetegoeden niet langer van toepassing op App Service Environment v1- en v2-workloads die in productie blijven omdat ze buiten gebruik worden gesteld. Het buiten gebruik stellen van de App Service Environment v1- en v2-hardware is gestart. Dit kan van invloed zijn op de beschikbaarheid en prestaties van uw apps en gegevens.

U moet de migratie naar App Service Environment v3 onmiddellijk voltooien of uw apps en resources kunnen worden verwijderd. We proberen alle resterende App Service Environment v1 en v2 automatisch te migreren met behulp van de in-place migratiefunctie, maar Microsoft maakt geen claim of garanties over de beschikbaarheid van toepassingen na automatische migratie. Mogelijk moet u handmatige configuratie uitvoeren om de migratie te voltooien en de SKU-keuze van uw App Service-plan te optimaliseren om aan uw behoeften te voldoen. Als automatische migratie niet haalbaar is, worden uw resources en bijbehorende app-gegevens verwijderd. We dringen er ten zeerste op aan dat u nu actie moet ondernemen om een van deze extreme scenario's te voorkomen.

Als u extra tijd nodig hebt, kunnen we een eenmalige respijtperiode van 30 dagen aanbieden om uw migratie te voltooien. Raadpleeg het overzicht van de respijtperiode voor meer informatie en om deze respijtperiode aan te vragen. Ga vervolgens naar Azure Portal en ga naar de blade Migratie voor elk van uw App Service-omgevingen.

Zie de buitengebruikstelling van App Service Environment v1/v2 voor de meest recente informatie over de buitengebruikstelling van App Service Environment v1 en v2.

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 vooraf 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.

Notitie

Hoewel dit artikel naar web-apps verwijst, is het ook van toepassing op API Apps en mobiele apps.

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, vindt u in de sectie Vereiste netwerkverbinding 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 pagina App Service Environment-beheer in Azure Portal.)

Het wordt ook aanbevolen dat aangepaste DNS-servers in het virtuele netwerk 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-omgeving, 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 andere regels in de loop van de tijd invoegen.

In het volgende 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 volgende 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 andere poorten 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.

Notitie

Als u aan de slag wilt met Azure App Service voordat u zich aanmeldt voor een Azure-account, gaat u naar App Service uitproberen. Hier kunt u direct een tijdelijke web-app maken in App Service. U hebt geen creditcard nodig en u gaat geen verplichtingen aan.