App Service-netwerkfuncties

U kunt toepassingen op meerdere manieren implementeren in Azure-app Service. Apps die in App Service worden gehost, zijn standaard rechtstreeks toegankelijk via internet en kunnen alleen eindpunten op internet bereiken. Maar voor veel toepassingen moet u het binnenkomende en uitgaande netwerkverkeer beheren. Er zijn verschillende functies in App Service om u te helpen aan deze behoeften te voldoen. De uitdaging is weten welke functie moet worden gebruikt om een bepaald probleem op te lossen. In dit artikel kunt u bepalen welke functie moet worden gebruikt, op basis van enkele voorbeeldgebruiksscenario's.

Er zijn twee hoofdimplementatietypen voor Azure-app Service:

• De openbare service met meerdere tenants host App Service-abonnementen in de prijs-SKU's Free, Shared, Basic, Standard, PremiumV2 en PremiumV3.
• De App Service Environment (ASE) met één tenant host isolated SKU App Service-abonnementen rechtstreeks in uw virtuele Azure-netwerk.

De functies die u gebruikt, zijn afhankelijk van of u zich in de service voor meerdere tenants of in een ASE bevindt.

Notitie

Netwerkfuncties zijn niet beschikbaar voor apps die zijn geïmplementeerd in Azure Arc.

Multitenant App Service-netwerkfuncties

Azure-app Service is een gedistribueerd systeem. De rollen die binnenkomende HTTP- of HTTPS-aanvragen verwerken, worden front-ends genoemd. De rollen die de workload van de klant hosten, worden werkrollen genoemd. Alle rollen in een App Service-implementatie bestaan in een netwerk met meerdere tenants. Omdat er veel verschillende klanten in dezelfde App Service-schaaleenheid staan, kunt u het App Service-netwerk niet rechtstreeks met uw netwerk verbinden.

In plaats van de netwerken te verbinden, hebt u functies nodig om de verschillende aspecten van toepassingscommunicatie af te handelen. De functies die aanvragen voor uw app verwerken, kunnen niet worden gebruikt om problemen op te lossen wanneer u oproepen doet vanuit uw app. Op dezelfde manier kunnen de functies die problemen voor oproepen vanuit uw app oplossen, niet worden gebruikt om problemen met uw app op te lossen.

Binnenkomende functies	Uitgaande functies
Door de app toegewezen adres	Hybride verbindingen
Toegangsbeperkingen	Gateway-vereiste integratie van virtueel netwerk
Service-eindpunten	Integratie van virtueel netwerk
Privé-eindpunten

Behalve genoteerde uitzonderingen kunt u al deze functies samen gebruiken. U kunt de functies combineren om uw problemen op te lossen.

Use cases en functies

Voor een bepaalde use-case zijn er mogelijk een aantal manieren om het probleem op te lossen. Het kiezen van de beste functie gaat soms verder dan de use-case zelf. De volgende inkomende gebruiksvoorbeelden stellen voor hoe u App Service-netwerkfuncties kunt gebruiken om problemen met het beheren van verkeer naar uw app op te lossen:

Inkomende use case	Functie
Ondersteuning voor OP IP gebaseerde SSL-behoeften voor uw app	Door de app toegewezen adres
Ondersteuning voor niet-gedeelde toegewezen binnenkomende adressen voor uw app	Door de app toegewezen adres
Toegang tot uw app beperken vanaf een set goed gedefinieerde adressen	Toegangsbeperkingen
Toegang tot uw app beperken vanuit resources in een virtueel netwerk	Service-eindpunten Interne Load Balancer (ILB) ASE-privé-eindpunten
Uw app beschikbaar maken op een privé-IP-adres in uw virtuele netwerk	Privé-IP van ILB ASE-eindpunten voor inkomend verkeer op een Application Gateway-exemplaar met service-eindpunten
Uw app beveiligen met een Web Application Firewall (WAF)	Application Gateway en ILB ASE Application Gateway met privé-eindpunten Application Gateway met service-eindpunten Azure Front Door met toegangsbeperkingen
Verkeer verdelen over uw apps in verschillende regio's	Azure Front Door met toegangsbeperkingen
Taakverdeling voor verkeer in dezelfde regio	Application Gateway met service-eindpunten

De volgende uitgaande gebruiksscenario's stellen voor hoe u App Service-netwerkfuncties kunt gebruiken om uitgaande toegangsbehoeften voor uw app op te lossen:

Uitgaande use-case	Functie
Toegang tot resources in een virtueel Azure-netwerk in dezelfde regio	ASE voor virtuele netwerkintegratie
Toegang tot resources in een virtueel Azure-netwerk in een andere regio	Integratie van virtuele netwerken en peering van virtuele netwerken die vereist zijn voor gateway-integratie van virtuele netwerken ASE en peering van virtuele netwerken
Toegang tot resources die zijn beveiligd met service-eindpunten	ASE voor virtuele netwerkintegratie
Toegang krijgen tot resources in een particulier netwerk dat niet is verbonden met Azure	Hybride verbindingen
Toegang tot resources in Azure ExpressRoute-circuits	ASE voor virtuele netwerkintegratie
Uitgaand verkeer van uw web-app beveiligen	INTEGRATIE van virtuele netwerken en netwerkbeveiligingsgroepen ASE
Uitgaand verkeer routeren vanuit uw web-app	ASE voor integratie van virtuele netwerken en routetabellen

Standaardnetwerkgedrag

Azure-app serviceschaaleenheden ondersteunen veel klanten in elke implementatie. De gratis en gedeelde SKU-abonnementen hosten werkbelastingen van klanten voor werkrollen met meerdere tenants. De Basic- en hogere abonnementen hosten klantworkloads die zijn toegewezen aan slechts één App Service-plan. Als u een Standard App Service-plan hebt, worden alle apps in dat plan uitgevoerd op dezelfde werkrol. Als u de werkrol uitschaalt, worden alle apps in dat App Service-plan gerepliceerd op een nieuwe werkrol voor elk exemplaar in uw App Service-plan.

Uitgaande adressen

De werkrol-VM's worden in grote mate onderverdeeld in de App Service-abonnementen. De gratis, gedeelde, Basic-, Standard- en Premium-abonnementen gebruiken allemaal hetzelfde type werkrol-VM. Het PremiumV2-abonnement maakt gebruik van een ander VM-type. PremiumV3 maakt gebruik van nog een ander VM-type. Wanneer u de VM-familie wijzigt, krijgt u een andere set uitgaande adressen. Als u schaalt van Standard naar PremiumV2, worden uw uitgaande adressen gewijzigd. Als u van PremiumV2 naar PremiumV3 schaalt, worden uw uitgaande adressen gewijzigd. In sommige oudere schaaleenheden worden zowel de binnenkomende als de uitgaande adressen gewijzigd wanneer u schaalt van Standard naar PremiumV2.

Er zijn veel adressen die worden gebruikt voor uitgaande oproepen. De uitgaande adressen die door uw app worden gebruikt voor het maken van uitgaande oproepen, worden weergegeven in de eigenschappen voor uw app. Deze adressen worden gedeeld door alle apps die worden uitgevoerd op dezelfde werkrol-VM-familie in de App Service-implementatie. Als u alle adressen wilt zien die uw app in een schaaleenheid kan gebruiken, wordt deze door de eigenschap aangeroepen possibleOutboundAddresses .

App Service heeft veel eindpunten die worden gebruikt om de service te beheren. Deze adressen worden gepubliceerd in een afzonderlijk document en bevinden zich ook in de AppServiceManagement IP-servicetag. De AppServiceManagement tag wordt alleen gebruikt in App Service Environments waar u dergelijk verkeer moet toestaan. De binnenkomende App Service-adressen worden bijgehouden in de AppService IP-servicetag. Er is geen IP-servicetag die de uitgaande adressen bevat die door App Service worden gebruikt.

Door de app toegewezen adres

De door de app toegewezen adresfunctie is een offshoot van de OP IP gebaseerde SSL-functie. U opent deze door SSL in te stellen met uw app. U kunt deze functie gebruiken voor OP IP gebaseerde SSL-aanroepen. U kunt deze ook gebruiken om uw app een adres te geven dat alleen de app heeft.

Wanneer u een door de app toegewezen adres gebruikt, loopt uw verkeer nog steeds via dezelfde front-endrollen die al het binnenkomende verkeer in de App Service-schaaleenheid verwerken. Maar het adres dat aan uw app is toegewezen, wordt alleen door uw app gebruikt. Gebruiksvoorbeelden voor deze functie:

• Ondersteuning voor OP IP gebaseerde SSL-behoeften voor uw app.
• Stel een toegewezen adres in voor uw app die niet wordt gedeeld.

Zie Een TLS/SSL-certificaat toevoegen in Azure-app Service voor meer informatie over het instellen van een adres in uw app.

Toegangsbeperkingen

Met toegangsbeperkingen kunt u binnenkomende aanvragen filteren. De filteractie vindt plaats op de front-endrollen die upstream zijn van de werkrollen waarop uw apps worden uitgevoerd. Omdat de front-endrollen upstream zijn van de werknemers, kunt u toegangsbeperkingen beschouwen als beveiliging op netwerkniveau voor uw apps. Zie het overzicht van toegangsbeperkingen voor meer informatie over toegangsbeperkingen.

Met deze functie kunt u een lijst maken met regels voor toestaan en weigeren die in volgorde van prioriteit worden geëvalueerd. Het is vergelijkbaar met de netwerkbeveiligingsgroepfunctie (NSG) in Azure-netwerken. U kunt deze functie gebruiken in een ASE of in de service voor meerdere tenants. Wanneer u deze gebruikt met een ILB AS-omgeving, kunt u de toegang van privé-adresblokken beperken. Zie Toegangsbeperkingen configureren voor meer informatie over het inschakelen van deze functie.

Notitie

Er kunnen maximaal 512 toegangsbeperkingsregels per app worden geconfigureerd.

Privé-eindpunt

Privé-eindpunt is een netwerkinterface waarmee u privé en veilig verbinding maakt met uw web-app via een privékoppeling van Azure. Privé-eindpunt maakt gebruik van een privé-IP-adres van uw virtuele netwerk, waardoor de web-app effectief in uw virtuele netwerk wordt gebracht. Deze functie is alleen bedoeld voor binnenkomende stromen naar uw web-app. Zie Privé-eindpunten gebruiken voor Azure Web App voor meer informatie.

Enkele gebruiksvoorbeelden voor deze functie:

• Beperk de toegang tot uw app vanuit resources in een virtueel netwerk.
• Uw app beschikbaar maken op een privé-IP-adres in uw virtuele netwerk.
• Bescherm uw app met een WAF.

Privé-eindpunten voorkomen exfiltratie van gegevens, omdat het enige wat u kunt bereiken via het privé-eindpunt, de app is waarmee deze is geconfigureerd.

Netwerkbeveiligingsperimeter

Azure Network Security Perimeter (NSP) is een service die een beveiligde perimeter biedt voor communicatie van PaaS-services (Platform as a Service). Deze PaaS-services kunnen met elkaar communiceren binnen de perimeter en kunnen ook communiceren met resources buiten de perimeter met behulp van openbare regels voor binnenkomende en uitgaande toegang.

Het afdwingen van NSP-regels maakt voornamelijk gebruik van beveiliging op basis van identiteiten die niet volledig kunnen worden afgedwongen in platformservices zoals App Services en Functions waarmee u uw eigen code kunt implementeren en de identiteit kunt gebruiken om het platform te vertegenwoordigen. Als u moet communiceren met PaaS-services die deel uitmaken van een NSP, moet u virtuele netwerkintegratie toevoegen aan uw App Service- of Functions-exemplaren en communiceren met de PaaS-resources met behulp van privé-eindpunten.

Hybride verbindingen

Met Hybride verbindingen van App Service kunnen uw apps uitgaande aanroepen uitvoeren naar opgegeven TCP-eindpunten. Het eindpunt kan zich on-premises bevinden, in een virtueel netwerk of overal waar uitgaand verkeer naar Azure is toegestaan op poort 443. Als u de functie wilt gebruiken, moet u een relayagent met de naam Hybrid Verbindingsbeheer installeren op een Windows Server 2012- of nieuwere host. Hybride Verbindingsbeheer moet Azure Relay kunnen bereiken op poort 443. U kunt hybride Verbindingsbeheer downloaden vanuit de gebruikersinterface voor hybride verbindingen van App Service in de portal.

Hybride Verbindingen van App Service is gebaseerd op de mogelijkheid voor hybride Verbindingen van Azure Relay. App Service maakt gebruik van een speciale vorm van de functie die alleen ondersteuning biedt voor het maken van uitgaande aanroepen van uw app naar een TCP-host en -poort. Deze host en poort hoeven alleen te worden omgezet op de host waarop Hybrid Verbindingsbeheer is geïnstalleerd.

Wanneer de app in App Service een DNS-zoekopdracht uitvoert op de host en poort die is gedefinieerd in uw hybride verbinding, wordt het verkeer automatisch omgeleid om via de hybride verbinding en via hybride Verbindingsbeheer te gaan. Zie Hybride verbindingen van App Service voor meer informatie.

Deze functie wordt vaak gebruikt voor het volgende:

• Toegang tot resources in privénetwerken die niet zijn verbonden met Azure met een VPN of ExpressRoute.
• Ondersteuning voor de migratie van on-premises apps naar App Service zonder dat u ondersteunende databases hoeft te verplaatsen.
• Biedt toegang met verbeterde beveiliging voor één host en poort per hybride verbinding. De meeste netwerkfuncties hebben open toegang tot een netwerk. Met hybride verbindingen kunt u alleen de enkele host en poort bereiken.
• Behandelt scenario's die niet worden gedekt door andere uitgaande connectiviteitsmethoden.
• Ontwikkel in App Service op een manier waarmee de apps eenvoudig on-premises resources kunnen gebruiken.

Omdat deze functie toegang biedt tot on-premises resources zonder een binnenkomende firewallgat, is dit populair bij ontwikkelaars. De andere uitgaande App Service-netwerkfuncties zijn gerelateerd aan Azure Virtual Network. Hybride verbindingen zijn niet afhankelijk van het doorlopen van een virtueel netwerk. Het kan worden gebruikt voor een breder scala aan netwerkbehoeften.

Hybride verbindingen van App Service weten niet wat u er bovenop doet. U kunt deze dus gebruiken voor toegang tot een database, een webservice of een willekeurige TCP-socket op een mainframe. De functie tunnels in wezen TCP-pakketten.

Hybride verbindingen is populair voor ontwikkeling, maar wordt ook gebruikt in productietoepassingen. Het is handig voor toegang tot een webservice of database, maar het is niet geschikt voor situaties waarin veel verbindingen moeten worden gemaakt.

Integratie van virtueel netwerk

Dankzij de integratie van een virtueel App Service-netwerk kan uw app uitgaande aanvragen indienen in een virtueel Azure-netwerk.

Met de functie voor integratie van virtuele netwerken kunt u de back-end van uw app in een subnet in een virtueel Resource Manager-netwerk plaatsen. Het virtuele netwerk moet zich in dezelfde regio bevinden als uw app. Deze functie is niet beschikbaar vanuit een App Service-omgeving, die zich al in een virtueel netwerk bevindt. Gebruiksvoorbeelden voor deze functie:

• Toegang tot resources in virtuele Resource Manager-netwerken in dezelfde regio.
• Toegang tot resources in gekoppelde virtuele netwerken, inclusief verbindingen tussen regio's.
• Toegang tot resources die zijn beveiligd met service-eindpunten.
• Toegang tot resources die toegankelijk zijn via ExpressRoute- of VPN-verbindingen.
• Toegang tot resources in privénetwerken zonder de noodzaak en kosten van een virtuele netwerkgateway.
• Hulp bij het beveiligen van al het uitgaande verkeer.
• Alle uitgaande verkeer geforceerd tunnelen.

Zie Integratie van virtueel netwerk van App Service voor meer informatie.

Gateway-vereiste integratie van virtueel netwerk

Gateway-vereiste integratie van virtuele netwerken was de eerste editie van de integratie van virtuele netwerken in App Service. De functie werkt door de host te verbinden waarop uw app wordt uitgevoerd met een gateway van een virtueel netwerk in uw virtuele netwerk met behulp van een punt-naar-site-VPN. Wanneer u de functie configureert, ontvangt uw app een van de punt-naar-site toegewezen adressen die aan elk exemplaar zijn toegewezen.

Met de vereiste integratie van de gateway kunt u rechtstreeks verbinding maken met een virtueel netwerk in een andere regio zonder peering en verbinding te maken met een klassiek virtueel netwerk. De functie is beperkt tot App Service Windows-abonnementen en werkt niet met met ExpressRoute verbonden virtuele netwerken. Het is raadzaam om de integratie van het regionale virtuele netwerk te gebruiken. Zie De integratie van virtuele netwerken van App Service voor meer informatie over deze functie.

App Service-omgeving

Een App Service Environment (ASE) is een implementatie met één tenant van de Azure-app Service die wordt uitgevoerd in uw virtuele netwerk. Sommige gevallen, zoals voor deze functie:

• Toegang tot resources in uw virtuele netwerk.
• Toegang tot resources in ExpressRoute.
• Uw apps beschikbaar maken met een privéadres in uw virtuele netwerk.
• Toegang tot resources tussen service-eindpunten.
• Toegang tot resources in privé-eindpunten.

Met een ASE hoeft u geen integratie van virtuele netwerken te gebruiken omdat de ASE zich al in uw virtuele netwerk bevindt. Als u toegang wilt krijgen tot resources zoals SQL of Azure Storage via service-eindpunten, schakelt u service-eindpunten in op het ASE-subnet. Als u toegang wilt krijgen tot resources in het virtuele netwerk of privé-eindpunten in het virtuele netwerk, hoeft u geen extra configuratie uit te voeren. Als u toegang wilt krijgen tot resources in ExpressRoute, bevindt u zich al in het virtuele netwerk en hoeft u niets te configureren in de ASE of de apps erin.

Omdat de apps in een ILB AS-omgeving beschikbaar kunnen worden gesteld op een privé-IP-adres, kunt u eenvoudig WAF-apparaten toevoegen om alleen de apps beschikbaar te maken die u op internet wilt gebruiken en de rest veilig te houden. Met deze functie kunt u de ontwikkeling van toepassingen met meerdere lagen eenvoudiger maken.

Sommige dingen zijn momenteel niet mogelijk vanuit de service voor meerdere tenants, maar zijn mogelijk vanuit een AS-omgeving. Hieronder volgen een aantal voorbeelden:

• Uw apps hosten in een service met één tenant.
• Schaal omhoog naar veel meer exemplaren dan mogelijk is in de service voor meerdere tenants.
• Laad persoonlijke CA-clientcertificaten voor gebruik door uw apps met privé-CA-beveiligde eindpunten.
• Dwing TLS 1.2 af voor alle apps die in het systeem worden gehost zonder dat u dit op app-niveau kunt uitschakelen.

De ASE biedt het beste verhaal over geïsoleerde en toegewezen app-hosting, maar het omvat wel enkele beheeruitdagingen. Enkele aandachtspunten voordat u een operationele ASE gebruikt:

• Een ASE wordt uitgevoerd binnen uw virtuele netwerk, maar heeft wel afhankelijkheden buiten het virtuele netwerk. Deze afhankelijkheden moeten zijn toegestaan. Zie Netwerkoverwegingen voor een App Service-omgeving voor meer informatie.
• Een ASE schaalt niet onmiddellijk zoals de multitenant-service. U moet anticiperen op schaalbehoeften in plaats van reactief schalen.
• Een ASE heeft een hogere kosten vooraf. Als u optimaal gebruik wilt maken van uw ASE, moet u van plan zijn om veel workloads in één ASE te plaatsen in plaats van deze te gebruiken voor kleine inspanningen.
• De apps in een ASE kunnen de toegang tot sommige apps in de ASE en niet tot andere apps selectief beperken.
• Een ASE bevindt zich in een subnet en alle netwerkregels zijn van toepassing op al het verkeer van en naar die ASE. Als u regels voor inkomend verkeer voor slechts één app wilt toewijzen, gebruikt u toegangsbeperkingen.

Functies combineren

De functies die worden vermeld voor de service voor meerdere tenants, kunnen samen worden gebruikt om uitgebreidere gebruiksvoorbeelden op te lossen. Hier worden twee veelvoorkomende gebruiksvoorbeelden beschreven, maar dat zijn slechts voorbeelden. Door te begrijpen wat de verschillende functies doen, kunt u voldoen aan bijna al uw systeemarchitectuurbehoeften.

Een app in een virtueel netwerk plaatsen

U vraagt zich misschien af hoe u een app in een virtueel netwerk plaatst. Als u uw app in een virtueel netwerk plaatst, bevinden de binnenkomende en uitgaande eindpunten voor de app zich binnen het virtuele netwerk. Een ASE is de beste manier om dit probleem op te lossen. U kunt echter voldoen aan de meeste behoeften binnen de service voor meerdere tenants door functies te combineren. U kunt bijvoorbeeld alleen-intranettoepassingen hosten met privé-binnenkomende en uitgaande adressen door:

• Een toepassingsgateway maken met privé-binnenkomende en uitgaande adressen.
• Binnenkomend verkeer naar uw app beveiligen met service-eindpunten.
• Gebruik de functie voor integratie van virtuele netwerken, zodat de back-end van uw app zich in uw virtuele netwerk bevindt.

Deze implementatiestijl geeft u geen speciaal adres voor uitgaand verkeer naar internet of de mogelijkheid om al het uitgaande verkeer vanuit uw app te vergrendelen. Het geeft u een groot deel van wat u alleen zou krijgen met een ASE.

Toepassingen met meerdere lagen maken

Een toepassing met meerdere lagen is een toepassing waarin de API-back-end-apps alleen toegankelijk zijn vanuit de front-endlaag. Er zijn twee manieren om een toepassing met meerdere lagen te maken. Beide beginnen met het gebruik van integratie van virtuele netwerken om uw front-endweb-app te verbinden met een subnet in een virtueel netwerk. Als u dit doet, kan uw web-app oproepen doen naar uw virtuele netwerk. Nadat uw front-end-app is verbonden met het virtuele netwerk, moet u beslissen hoe u de toegang tot uw API-toepassing vergrendelt. U kunt:

• Host zowel de front-end als de API-app in dezelfde ILB ASE en maak de front-end-app beschikbaar op internet met behulp van een toepassingsgateway.
• Host de front-end in de service voor meerdere tenants en de back-end in een ILB AS-omgeving.
• Host zowel de front-end als de API-app in de service voor meerdere tenants.

Als u zowel de front-end- als de API-app host voor een toepassing met meerdere lagen, kunt u het volgende doen:

• Uw API-toepassing beschikbaar maken met behulp van privé-eindpunten in uw virtuele netwerk:

  

• Gebruik service-eindpunten om ervoor te zorgen dat binnenkomend verkeer naar uw API-app alleen afkomstig is van het subnet dat wordt gebruikt door uw front-endweb-app:

  

Hier volgen enkele overwegingen waarmee u kunt bepalen welke methode u wilt gebruiken:

• Wanneer u service-eindpunten gebruikt, hoeft u alleen verkeer naar uw API-app te beveiligen naar het integratiesubnet. Service-eindpunten helpen de API-app te beveiligen, maar u kunt nog steeds gegevensexfiltratie van uw front-end-app naar andere apps in de app-service hebben.
• Wanneer u privé-eindpunten gebruikt, hebt u twee subnetten die aan het spel zijn, wat complexiteit toevoegt. Het privé-eindpunt is ook een resource op het hoogste niveau en voegt beheeroverhead toe. Het voordeel van het gebruik van privé-eindpunten is dat u niet over de mogelijkheid beschikt om gegevensexfiltratie uit te voeren.

Beide methoden werken met meerdere front-ends. Op kleine schaal zijn service-eindpunten eenvoudiger te gebruiken, omdat u service-eindpunten voor de API-app in het front-endintegratiesubnet inschakelt. Wanneer u meer front-end-apps toevoegt, moet u elke API-app aanpassen om service-eindpunten op te nemen met het integratiesubnet. Wanneer u privé-eindpunten gebruikt, is er meer complexiteit, maar hoeft u niets te wijzigen in uw API-apps nadat u een privé-eindpunt hebt ingesteld.

Line-Of-Business-toepassingen

Lob-toepassingen (Line-Of-Business) zijn interne toepassingen die normaal gesproken niet beschikbaar zijn voor toegang via internet. Deze toepassingen worden aangeroepen vanuit bedrijfsnetwerken waar de toegang strikt kan worden beheerd. Als u een ILB ASE gebruikt, kunt u eenvoudig uw Line-Of-Business-toepassingen hosten. Als u de service voor meerdere tenants gebruikt, kunt u privé-eindpunten gebruiken of service-eindpunten gebruiken in combinatie met een toepassingsgateway. Er zijn twee redenen om een toepassingsgateway met service-eindpunten te gebruiken in plaats van privé-eindpunten te gebruiken:

• U hebt WAF-beveiliging nodig voor uw LOB-apps.
• U wilt taken verdelen over meerdere exemplaren van uw LOB-apps.

Als geen van deze behoeften van toepassing is, kunt u beter privé-eindpunten gebruiken. Met privé-eindpunten die beschikbaar zijn in App Service, kunt u uw apps beschikbaar maken op privéadressen in uw virtuele netwerk. Het privé-eindpunt dat u in uw virtuele netwerk plaatst, kan worden bereikt via ExpressRoute- en VPN-verbindingen.

Als u privé-eindpunten configureert, worden uw apps beschikbaar gesteld op een privéadres, maar u moet DNS configureren om dat adres vanaf on-premises te bereiken. Als u deze configuratie wilt laten werken, moet u de privézone van Azure DNS die uw privé-eindpunten bevat doorsturen naar uw on-premises DNS-servers. Privézones van Azure DNS bieden geen ondersteuning voor het doorsturen van zones, maar u kunt zone forwarding ondersteunen met behulp van privé-resolver van Azure DNS.

App Service-poorten

Als u App Service scant, vindt u verschillende poorten die beschikbaar zijn voor inkomende verbindingen. Er is geen manier om de toegang tot deze poorten in de multitenantservice te blokkeren of te beheren. Hier volgt de lijst met weergegeven poorten:

Gebruik	Poort of poorten
HTTP/HTTPS	80, 443
Beheer	454, 455
FTP/FTPS	21, 990, 10001-10300
Externe foutopsporing in Visual Studio	4020, 4022, 4024
Web Deploy-service	8172
Gebruik van infrastructuur	7654, 1221