App Service-nätverksfunktioner

Du kan distribuera program i Azure App Service på flera sätt. Som standard är appar som finns i App Service tillgängliga direkt via Internet och kan bara nå internetbaserade slutpunkter. Men för många program måste du styra inkommande och utgående nätverkstrafik. Det finns flera funktioner i App Service som hjälper dig att uppfylla dessa behov. Utmaningen är att veta vilken funktion som ska användas för att lösa ett visst problem. Den här artikeln hjälper dig att avgöra vilken funktion som ska användas, baserat på några exempel på användningsfall.

Det finns två huvudsakliga distributionstyper för Azure App Service:

• Den offentliga tjänsten för flera innehavare är värd för App Service-planer i pris-SKU:erna Kostnadsfri, Delad, Basic, Standard, Premium, PremiumV2 och PremiumV3.
• Den enskilda klientorganisationen App Service-miljön (ASE) är värd för isolerade SKU App Service-planer direkt i ditt virtuella Azure-nätverk.

Vilka funktioner du använder beror på om du är i tjänsten för flera klientorganisationer eller i en ASE.

App Service-nätverksfunktioner för flera klientorganisationer

Azure App Service är ett distribuerat system. De roller som hanterar inkommande HTTP- eller HTTPS-begäranden kallas klientdelar. De roller som är värdar för kundens arbetsbelastning kallas arbetare. Alla roller i en App Service-distribution finns i ett nätverk med flera klientorganisationer. Eftersom det finns många olika kunder i samma App Service-skalningsenhet kan du inte ansluta App Service-nätverket direkt till nätverket.

I stället för att ansluta nätverken behöver du funktioner för att hantera de olika aspekterna av programkommunikation. De funktioner som hanterar begäranden till din app kan inte användas för att lösa problem när du gör anrop från din app. På samma sätt kan inte de funktioner som löser problem med anrop från din app användas för att lösa problem med din app.

Förutom angivna undantag kan du använda alla dessa funktioner tillsammans. Du kan blanda funktionerna för att lösa dina problem.

Användningsfall och funktioner

För alla angivna användningsfall kan det finnas några sätt att lösa problemet. Att välja den bästa funktionen går ibland utöver själva användningsfallet. Följande användningsfall för inkommande trafik tyder på hur du använder App Service-nätverksfunktioner för att lösa problem med att kontrollera trafik som går till din app:

Följande utgående användningsfall föreslår hur du använder App Service-nätverksfunktioner för att lösa utgående åtkomstbehov för din app:

Standardbeteende för nätverk

Azure App Service-skalningsenheter stöder många kunder i varje distribution. Den kostnadsfria och delade SKU-planen är värd för kundarbetsbelastningar för arbetare med flera klientorganisationer. De grundläggande och högre abonnemangen är värdar för kundarbetsbelastningar som endast är dedikerade till en App Service-plan. Om du har en Standard App Service-plan körs alla appar i planen på samma arbetare. Om du skalar ut arbetaren replikeras alla appar i App Service-planen på en ny arbetare för varje instans i din App Service-plan.

Utgående adresser

De virtuella arbetsdatorerna delas till stor del upp av App Service-planerna. De kostnadsfria, delade, grundläggande, standard- och Premium-abonnemangen använder alla samma typ av arbetsdator. PremiumV2-planen använder en annan typ av virtuell dator. PremiumV3 använder ännu en vm-typ. När du ändrar vm-familjen får du en annan uppsättning utgående adresser. Om du skalar från Standard till PremiumV2 ändras dina utgående adresser. Om du skalar från PremiumV2 till PremiumV3 ändras dina utgående adresser. I vissa äldre skalningsenheter ändras både inkommande och utgående adresser när du skalar från Standard till PremiumV2.

Det finns många adresser som används för utgående anrop. De utgående adresser som används av din app för att göra utgående anrop visas i egenskaperna för din app. Dessa adresser delas av alla appar som körs i samma arbetsdatorfamilj i App Service-distributionen. Om du vill se alla adresser som appen kan använda i en skalningsenhet finns det en egenskap som heter possibleOutboundAddresses som visar dem.

App Service har många slutpunkter som används för att hantera tjänsten. Dessa adresser publiceras i ett separat dokument och finns också i AppServiceManagement IP-tjänsttaggen. Taggen AppServiceManagement används endast i App Service-miljön där du behöver tillåta sådan trafik. Inkommande Adresser för App Service spåras i AppService IP-tjänsttaggen. Det finns ingen IP-tjänsttagg som innehåller de utgående adresser som används av App Service.

Apptilldelad adress

Den apptilldelade adressfunktionen är en avsökning av DEN IP-baserade SSL-funktionen. Du kommer åt det genom att konfigurera SSL med din app. Du kan använda den här funktionen för IP-baserade SSL-anrop. Du kan också använda den för att ge din app en adress som bara den har.

När du använder en apptilldelad adress går trafiken fortfarande igenom samma klientdelsroller som hanterar all inkommande trafik till App Service-skalningsenheten. Men den adress som har tilldelats din app används endast av din app. Användningsfall för den här funktionen:

• Stöd för IP-baserade SSL-behov för din app.
• Ange en dedikerad adress för din app som inte delas.

Information om hur du anger en adress i din app finns i Lägga till ett TLS/SSL-certifikat i Azure App Service.

Åtkomstbegränsningar

Med åtkomstbegränsningar kan du filtrera inkommande begäranden. Filtreringsåtgärden sker på klientdelsrollerna som är överordnade från arbetsrollerna där dina appar körs. Eftersom klientdelsrollerna är överordnade från arbetarna kan du betrakta åtkomstbegränsningar som skydd på nätverksnivå för dina appar. Mer information om åtkomstbegränsningar finns i Översikt över åtkomstbegränsningar.

Med den här funktionen kan du skapa en lista över tillåtna och neka regler som utvärderas i prioritetsordning. Det liknar funktionen nätverkssäkerhetsgrupp (NSG) i Azure-nätverk. Du kan använda den här funktionen i en ASE eller i tjänsten för flera klientorganisationer. När du använder den med en ILB ASE kan du begränsa åtkomsten från privata adressblock. Information om hur du aktiverar den här funktionen finns i Konfigurera åtkomstbegränsningar.

Privat slutpunkt

Privat slutpunkt är ett nätverksgränssnitt som ansluter dig privat och säkert till din webbapp via en privat Azure-länk. Privat slutpunkt använder en privat IP-adress från ditt virtuella nätverk, vilket effektivt för webbappen till ditt virtuella nätverk. Den här funktionen är endast avsedd för inkommande flöden till din webbapp. Mer information finns i Använda privata slutpunkter för Azure Web App.

Vissa användningsfall för den här funktionen:

• Begränsa åtkomsten till din app från resurser i ett virtuellt nätverk.
• Exponera din app på en privat IP-adress i ditt virtuella nätverk.
• Skydda din app med en WAF.

Privata slutpunkter förhindrar dataexfiltrering eftersom det enda du kan nå över den privata slutpunkten är appen som den har konfigurerats med.

Nätverkssäkerhetsperimeter

Azure Network Security Perimeter (NSP) är en tjänst som tillhandahåller en säker perimeter för kommunikation av PaaS-tjänster (Platform as a Service). Dessa PaaS-tjänster kan kommunicera med varandra inom perimetern och kan även kommunicera med resurser utanför perimetern med hjälp av offentliga regler för inkommande och utgående åtkomst.

NSP-regeltillämpning använder främst identitetsbaserad säkerhet som inte kan tillämpas fullt ut i plattformstjänster som App Services och Functions som gör att du kan distribuera din egen kod och använda identiteten för att representera plattformen. Om du behöver kommunicera med PaaS-tjänster som ingår i en NSP måste du lägga till integrering av virtuella nätverk i App Service- eller Functions-instanser och kommunicera med PaaS-resurserna med hjälp av privata slutpunkter.

Hybridanslutningar

Med App Service Hybrid-anslutningar kan dina appar göra utgående anrop till angivna TCP-slutpunkter. Slutpunkten kan finnas lokalt, i ett virtuellt nätverk eller var som helst som tillåter utgående trafik till Azure på port 443. Om du vill använda funktionen måste du installera en reläagent med namnet Hybridanslutningshanteraren på en Windows Server 2012- eller senare värd. Hybridanslutningshanteraren måste kunna nå Azure Relay på port 443. Du kan ladda ned Hybridanslutningshanteraren från apptjänstens användargränssnitt för hybridanslutningar i portalen.

Hybridanslutningar i App Service bygger på azure relay-hybridanslutningar. App Service använder en specialiserad form av funktionen som endast stöder utgående anrop från din app till en TCP-värd och port. Den här värden och porten behöver bara matcha på värden där Hybridanslutningshanteraren är installerad.

När appen i App Service gör en DNS-sökning på värden och porten som definierats i din hybridanslutning omdirigeras trafiken automatiskt för att gå igenom hybridanslutningen och ut ur Hybridanslutningshanteraren. Mer information finns i Hybridanslutningar för App Service.

Den här funktionen används ofta för att:

• Få åtkomst till resurser i privata nätverk som inte är anslutna till Azure med vpn eller ExpressRoute.
• Stöd för migrering av lokala appar till App Service utan att behöva flytta stöddatabaser.
• Ge åtkomst med förbättrad säkerhet till en enda värd och port per hybridanslutning. De flesta nätverksfunktioner öppnar åtkomsten till ett nätverk. Med hybridanslutningar kan du bara nå den enda värden och porten.
• Omfattar scenarier som inte omfattas av andra utgående anslutningsmetoder.
• Utför utveckling i App Service på ett sätt som gör att apparna enkelt kan använda lokala resurser.

Eftersom den här funktionen ger åtkomst till lokala resurser utan ett inkommande brandväggshål är den populär bland utvecklare. De andra utgående App Service-nätverksfunktionerna är relaterade till Azure Virtual Network. Hybridanslutningar är inte beroende av att gå via ett virtuellt nätverk. Den kan användas för en bredare mängd olika nätverksbehov.

App Service Hybrid-anslutningar är inte medvetna om vad du gör ovanpå det. Du kan därför använda den för att komma åt en databas, en webbtjänst eller en godtycklig TCP-socket i en stordator. Funktionen tunnel t.ex. TCP-paket.

Hybridanslutningar är populära för utveckling, men används också i produktionsprogram. Det är bra för åtkomst till en webbtjänst eller databas, men det är inte lämpligt för situationer som innebär att skapa många anslutningar.

Virtual Network-integration

Med integrering av virtuella Nätverk i App Service kan din app göra utgående begäranden till ett virtuellt Azure-nätverk.

Med integreringsfunktionen för virtuella nätverk kan du placera appens serverdel i ett undernät i ett virtuellt Resource Manager-nätverk. Det virtuella nätverket måste finnas i samma region som din app. Den här funktionen är inte tillgänglig från en App Service-miljön, som redan finns i ett virtuellt nätverk. Användningsfall för den här funktionen:

• Få åtkomst till resurser i virtuella Resource Manager-nätverk i samma region.
• Få åtkomst till resurser i peer-kopplade virtuella nätverk, inklusive anslutningar mellan regioner.
• Få åtkomst till resurser som skyddas med tjänstslutpunkter.
• Åtkomst till resurser som är tillgängliga för ExpressRoute- eller VPN-anslutningar.
• Få åtkomst till resurser i privata nätverk utan behov och kostnad för en virtuell nätverksgateway.
• Hjälp med att skydda all utgående trafik.
• Tvinga tunnel all utgående trafik.

Mer information finns i Integrering av virtuella nätverk i App Service.

Gateway-nödvändig integrering av virtuellt nätverk

Gateway-nödvändig integrering av virtuella nätverk var den första utgåvan av integrering av virtuella nätverk i App Service. Funktionen fungerar genom att ansluta värden som appen körs på till en virtuell nätverksgateway i ditt virtuella nätverk med hjälp av ett punkt-till-plats-VPN. När du konfigurerar funktionen får appen en av de punkt-till-plats-tilldelade adresser som tilldelats till varje instans.

Med den gateway som krävs kan du ansluta direkt till ett virtuellt nätverk i en annan region utan peering och ansluta till ett klassiskt virtuellt nätverk. Funktionen är begränsad till App Service Windows-planer och fungerar inte med ExpressRoute-anslutna virtuella nätverk. Vi rekommenderar att du använder integreringen av det regionala virtuella nätverket. Mer information om den här funktionen finns i Integrering av virtuella nätverk i App Service.

App Service Environment

En App Service-miljön (ASE) är en distribution med en enda klientorganisation av Azure App Service som körs i ditt virtuella nätverk. Vissa fall, till exempel för den här funktionen:

• Få åtkomst till resurser i ditt virtuella nätverk.
• Få åtkomst till resurser i ExpressRoute.
• Exponera dina appar med en privat adress i ditt virtuella nätverk.
• Få åtkomst till resurser mellan tjänstslutpunkter.
• Få åtkomst till resurser mellan privata slutpunkter.

Med en ASE behöver du inte använda integrering av virtuella nätverk eftersom ASE redan finns i ditt virtuella nätverk. Om du vill komma åt resurser som SQL eller Azure Storage över tjänstslutpunkter aktiverar du tjänstslutpunkter i ASE-undernätet. Om du vill komma åt resurser i det virtuella nätverket eller privata slutpunkter i det virtuella nätverket behöver du inte göra någon extra konfiguration. Om du vill komma åt resurser i ExpressRoute är du redan i det virtuella nätverket och behöver inte konfigurera något i ASE eller apparna i det.

Eftersom apparna i en ILB ASE kan exponeras på en privat IP-adress kan du enkelt lägga till WAF-enheter för att exponera bara de appar som du vill ha på Internet och hjälpa till att skydda resten. Den här funktionen kan underlätta utvecklingen av program på flera nivåer.

Vissa saker är för närvarande inte möjliga från tjänsten för flera klientorganisationer, men är möjliga från en ASE. Nedan följer några exempel:

• Värdhantera dina appar i en tjänst med en enda klientorganisation.
• Skala upp till många fler instanser än vad som är möjligt i tjänsten för flera klientorganisationer.
• Läs in privata CA-klientcertifikat för användning av dina appar med privata CA-skyddade slutpunkter.
• Framtvinga TLS 1.2 för alla appar som finns i systemet utan möjlighet att inaktivera det på appnivå.

ASE ger den bästa historien om isolerade och dedikerade appvärdar, men det innebär vissa hanteringsutmaningar. Några saker att tänka på innan du använder en fungerande ASE:

• En ASE körs i ditt virtuella nätverk, men den har beroenden utanför det virtuella nätverket. Dessa beroenden måste tillåtas. Mer information finns i Nätverksöverväganden för en App Service-miljön.
• En ASE skalas inte omedelbart som tjänsten för flera klientorganisationer. Du måste förutse skalningsbehov i stället för reaktiv skalning.
• En ASE har en högre startkostnad. För att få ut mesta möjliga av din ASE bör du planera att lägga många arbetsbelastningar i en ASE i stället för att använda den för små ansträngningar.
• Apparna i en ASE kan inte selektivt begränsa åtkomsten till vissa appar i ASE och inte andra.
• En ASE finns i ett undernät och alla nätverksregler gäller för all trafik till och från den ASE:n. Om du bara vill tilldela regler för inkommande trafik för bara en app använder du åtkomstbegränsningar.

Kombinera funktioner

De funktioner som anges för tjänsten för flera klientorganisationer kan användas tillsammans för att lösa mer detaljerade användningsfall. Två av de vanligaste användningsfallen beskrivs här, men det är bara exempel. Genom att förstå vad de olika funktionerna gör kan du uppfylla nästan alla systemarkitekturbehov.

Placera en app i ett virtuellt nätverk

Du kanske undrar hur du placerar en app i ett virtuellt nätverk. Om du placerar din app i ett virtuellt nätverk finns de inkommande och utgående slutpunkterna för appen i det virtuella nätverket. En ASE är det bästa sättet att lösa det här problemet. Men du kan uppfylla de flesta av dina behov inom tjänsten för flera innehavare genom att kombinera funktioner. Du kan till exempel vara värd för program endast för intranät med privata inkommande och utgående adresser genom att:

• Skapa en programgateway med privata inkommande och utgående adresser.
• Skydda inkommande trafik till din app med tjänstslutpunkter.
• Använd integreringsfunktionen för virtuella nätverk så att appens serverdel finns i ditt virtuella nätverk.

Den här distributionsstilen ger dig ingen dedikerad adress för utgående trafik till Internet eller möjlighet att låsa all utgående trafik från din app. Det kommer att ge dig en mycket av vad du bara annars skulle få med en ASE.

Skapa program med flera nivåer

Ett program med flera nivåer är ett program där API-serverdelsapparna endast kan nås från klientdelsnivån. Det finns två sätt att skapa ett program med flera nivåer. Båda börjar med integrering av virtuella nätverk för att ansluta klientwebbappen till ett undernät i ett virtuellt nätverk. Om du gör det kan webbappen göra anrop till ditt virtuella nätverk. När klientdelsappen är ansluten till det virtuella nätverket måste du bestämma hur du ska låsa åtkomsten till ditt API-program. Du kan:

• Var värd för både klientdelen och API-appen i samma ILB ASE och exponera klientdelsappen på Internet med hjälp av en programgateway.
• Värd för klientdelen i tjänsten för flera klientorganisationer och serverdelen i en ILB ASE.
• Värd för både klientdelen och API-appen i tjänsten för flera klientorganisationer.

Om du är värd för både klientdelen och API-appen för ett program med flera nivåer kan du:

• Exponera DITT API-program med hjälp av privata slutpunkter i ditt virtuella nätverk:

  

• Använd tjänstslutpunkter för att säkerställa att inkommande trafik till din API-app endast kommer från det undernät som används av klientwebbappen:

  

Här följer några överväganden som hjälper dig att bestämma vilken metod du ska använda:

• När du använder tjänstslutpunkter behöver du bara skydda trafiken till DIN API-app till integrationsundernätet. Tjänstslutpunkter hjälper till att skydda API-appen, men du kan fortfarande ha dataexfiltrering från klientdelsappen till andra appar i apptjänsten.
• När du använder privata slutpunkter har du två undernät som är på spel, vilket ökar komplexiteten. Dessutom är den privata slutpunkten en resurs på den översta nivån och lägger till hanteringskostnader. Fördelen med att använda privata slutpunkter är att du inte har möjlighet till dataexfiltrering.

Båda metoderna fungerar med flera klientdelar. I liten skala är tjänstslutpunkter enklare att använda eftersom du bara aktiverar tjänstslutpunkter för API-appen i klientdelsintegreringsundernätet. När du lägger till fler klientdelsappar måste du justera varje API-app så att den inkluderar tjänstslutpunkter med integrationsundernätet. När du använder privata slutpunkter är det mer komplicerat, men du behöver inte ändra något i DINA API-appar när du har angett en privat slutpunkt.

Verksamhetsspecifika appar

Verksamhetsspecifika program (LOB) är interna program som normalt inte exponeras för åtkomst från Internet. Dessa program anropas inifrån företagsnätverk där åtkomsten kan kontrolleras strikt. Om du använder en ILB ASE är det enkelt att vara värd för dina verksamhetsspecifika program. Om du använder tjänsten för flera klientorganisationer kan du antingen använda privata slutpunkter eller använda tjänstslutpunkter i kombination med en programgateway. Det finns två skäl att använda en programgateway med tjänstslutpunkter i stället för att använda privata slutpunkter:

• Du behöver WAF-skydd på dina LOB-appar.
• Du vill belastningsutjämning till flera instanser av dina LOB-appar.

Om inget av dessa behov gäller är det bättre att använda privata slutpunkter. Med privata slutpunkter tillgängliga i App Service kan du exponera dina appar på privata adresser i det virtuella nätverket. Den privata slutpunkt som du placerar i ditt virtuella nätverk kan nås via ExpressRoute- och VPN-anslutningar.

Om du konfigurerar privata slutpunkter exponeras dina appar på en privat adress, men du måste konfigurera DNS för att nå den adressen lokalt. För att den här konfigurationen ska fungera måste du vidarebefordra den privata Azure DNS-zonen som innehåller dina privata slutpunkter till dina lokala DNS-servrar. Privata Azure DNS-zoner har inte stöd för zonvidarebefordring, men du kan stödja zonvidarebefordring med hjälp av en privat Lösning för Azure DNS.

App Service-portar

Om du genomsöker App Service hittar du flera portar som exponeras för inkommande anslutningar. Det finns inget sätt att blockera eller kontrollera åtkomsten till dessa portar i tjänsten för flera klientorganisationer. Här är listan över exponerade portar: