Op een veilige manier verbinding maken met back-endresources vanuit een App Service-omgeving

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.

Omdat een App Service-omgeving altijd wordt gemaakt in een virtueel Azure Resource Manager-netwerk of een virtueel netwerk met een klassiek implementatiemodel, kunnen uitgaande verbindingen van een App Service-omgeving naar andere back-endresources uitsluitend via het virtuele netwerk stromen. Vanaf juni 2016 kunnen ASE's ook worden geïmplementeerd in virtuele netwerken die gebruikmaken van openbare adresbereiken of RFC1918 adresruimten (privéadressen).

Er kan bijvoorbeeld een SQL Server worden uitgevoerd op een cluster met virtuele machines waarop poort 1433 is vergrendeld. Het eindpunt kan ACLd zijn om alleen toegang van andere resources in hetzelfde virtuele netwerk toe te staan.

In een ander voorbeeld kunnen gevoelige eindpunten on-premises worden uitgevoerd en worden verbonden met Azure via site-naar-site - of Azure ExpressRoute-verbindingen . Als gevolg hiervan hebben alleen resources in virtuele netwerken die zijn verbonden met de site-naar-site- of ExpressRoute-tunnels toegang tot on-premises eindpunten.

Voor al deze scenario's kunnen apps die worden uitgevoerd in een App Service Environment veilig verbinding maken met de verschillende servers en resources. Als uitgaand verkeer van apps wordt uitgevoerd in een App Service-omgeving naar privé-eindpunten in hetzelfde virtuele netwerk of is verbonden met hetzelfde virtuele netwerk, stroomt het alleen via het virtuele netwerk. Uitgaand verkeer naar privé-eindpunten stroomt niet via het openbare internet.

Eén probleem is van toepassing op uitgaand verkeer van een App Service-omgeving naar eindpunten binnen een virtueel netwerk. App Service-omgevingen kunnen geen eindpunten bereiken van virtuele machines die zich in hetzelfde subnet bevinden als de App Service Environment. Deze beperking mag normaal gesproken geen probleem zijn, als App Service-omgevingen worden geïmplementeerd in een subnet dat exclusief door de App Service Environment is gereserveerd voor gebruik.

Notitie

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

Vereisten voor uitgaande verbindingen en DNS

Om een App Service-omgeving goed te laten functioneren, is 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. Selecteer boven aan de blade App Service Environment-beheer in de portal het pictogram Opnieuw opstarten om een doorlopende omgeving opnieuw op te starten, waardoor de omgeving de nieuwe DNS-configuratie ophaalt.

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-omgeving, mislukt het maken van de App Service-omgeving. Aan het andere uiteinde van een VPN-gateway, als er een aangepaste DNS-server is die niet bereikbaar of niet beschikbaar is, mislukt het maken van de App Service-omgeving ook.

Verbinding maken met een SQL Server

Een algemene SQL Server-configuratie heeft een eindpunt dat luistert op poort 1433:

Er zijn twee benaderingen voor het beperken van verkeer naar dit eindpunt:

• Netwerktoegangsbeheerlijsten (netwerk-ACL's)
• Netwerkbeveiligingsgroepen

Toegang beperken met een netwerk-ACL

Poort 1433 kan worden beveiligd met behulp van een netwerktoegangsbeheerlijst. In het onderstaande voorbeeld worden toewijzingsmachtigingen toegevoegd aan de clientadressen die afkomstig zijn uit een virtueel netwerk en worden de toegang tot alle andere clients geblokkeerd.

Alle toepassingen die worden uitgevoerd in App Service Environment, in hetzelfde virtuele netwerk als de SQL Server, kunnen verbinding maken met het SQL Server-exemplaar. Gebruik het interne IP-adres van het VNet voor de virtuele SQL Server-machine.

In het voorbeeld verbindingsreeks hieronder verwijst naar de SQL Server met behulp van het privé-IP-adres.

Server=tcp:10.0.1.6;Database=MyDatabase;User ID=MyUser;Password=PasswordHere;provider=System.Data.SqlClient

Hoewel de virtuele machine ook een openbaar eindpunt heeft, worden verbindingspogingen om het openbare IP-adres te gebruiken geweigerd vanwege de netwerk-ACL.

Toegang beperken met een netwerkbeveiligingsgroep

Een alternatieve benadering voor het beveiligen van de toegang is met een netwerkbeveiligingsgroep. Netwerkbeveiligingsgroepen kunnen worden toegepast op afzonderlijke virtuele machines of op een subnet met virtuele machines.

Eerst moet u een netwerkbeveiligingsgroep maken:

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

Het beperken van de toegang tot alleen intern VNet-verkeer is eenvoudig met een netwerkbeveiligingsgroep. De standaardregels in een netwerkbeveiligingsgroep staan alleen toegang toe van andere netwerkclients in hetzelfde virtuele netwerk.

Als gevolg hiervan is het vergrendelen van de toegang tot SQL Server eenvoudig. Pas een netwerkbeveiligingsgroep met de standaardregels toe op de virtuele machines waarop SQL Server wordt uitgevoerd of op het subnet met de virtuele machines.

In het onderstaande voorbeeld wordt een netwerkbeveiligingsgroep toegepast op het onderliggende subnet:

Get-AzureNetworkSecurityGroup -Name "testNSGExample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-1'

Het uiteindelijke resultaat is een set beveiligingsregels die externe toegang blokkeren, terwijl interne VNet-toegang wordt toegestaan:

Aan de slag

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

Zie Inkomend verkeer naar uw App Service-omgeving beheren voor meer informatie over het beheren van inkomend verkeer naar een App Service-omgeving

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.