Dela via

Implementera en säkerhetsarkitektur i flera lager med App Service-miljön

  • Artikel

Viktigt!

Den här artikeln handlar om App Service-miljön v1. App Service-miljön v1 och v2 dras tillbaka från och med den 31 augusti 2024. Det finns en ny version av App Service-miljön som är enklare att använda och köra på kraftfullare infrastruktur. Om du vill veta mer om den nya versionen börjar du med Introduktion till App Service-miljön. Om du för närvarande använder App Service-miljön v1 följer du stegen i den här artikeln för att migrera till den nya versionen.

Från och med den 31 augusti 2024 gäller serviceavtal (SLA) och tjänstkrediter inte längre för App Service-miljön v1- och v2-arbetsbelastningar som fortsätter att vara i produktion eftersom de är tillbakadragna produkter. Avvecklingen av maskinvaran App Service-miljön v1 och v2 har påbörjats, vilket kan påverka tillgängligheten och prestandan för dina appar och data.

Du måste slutföra migreringen till App Service-miljön v3 omedelbart eller så kan dina appar och resurser tas bort. Vi försöker automatiskt migrera eventuella återstående App Service-miljön v1 och v2 på bästa sätt med hjälp av migreringsfunktionen på plats, men Microsoft gör inga anspråk eller garantier om programtillgänglighet efter automatisk migrering. Du kan behöva utföra manuell konfiguration för att slutföra migreringen och optimera ditt SKU-val för App Service-plan för att uppfylla dina behov. Om automatisk migrering inte är möjlig tas dina resurser och associerade appdata bort. Vi uppmanar dig starkt att agera nu för att undvika något av dessa extrema scenarier.

Om du behöver ytterligare tid kan vi erbjuda en respitperiod på 30 dagar för att slutföra migreringen. Mer information och för att begära den här respitperioden finns i översikten över respitperioden och gå sedan till Azure Portal och gå till migreringsbladet för var och en av dina App Service-miljön.

Den senaste informationen om App Service-miljön v1/v2-tillbakadragning finns i App Service-miljön v1- och v2-pensionsuppdateringen.

Eftersom App Service-miljön tillhandahåller en isolerad körningsmiljö som distribueras till ett virtuellt nätverk kan utvecklare skapa en säkerhetsarkitektur i flera lager som ger olika nivåer av nätverksåtkomst för varje fysisk programnivå.

En vanlig önskan är att dölja API-serverdelar från allmän Internetåtkomst och endast tillåta att API:er anropas av överordnade webbappar. Nätverkssäkerhetsgrupper (NSG:er) kan användas i undernät som innehåller App Service-miljön för att begränsa offentlig åtkomst till API-program.

Diagrammet nedan visar en exempelarkitektur med en WebAPI-baserad app som distribuerats på en App Service-miljön. Tre separata webbappsinstanser, distribuerade på tre separata App Service-miljön, gör backend-anrop till samma WebAPI-app.

Konceptuell arkitektur

De gröna plusskyltarna anger att nätverkssäkerhetsgruppen i undernätet som innehåller "apiase" tillåter inkommande anrop från de överordnade webbapparna samt anrop från sig själv. Samma nätverkssäkerhetsgrupp nekar dock uttryckligen åtkomst till allmän inkommande trafik från Internet.

Resten av den här artikeln går igenom de steg som krävs för att konfigurera nätverkssäkerhetsgruppen i undernätet som innehåller "apiase".

Fastställa nätverksbeteendet

För att veta vilka nätverkssäkerhetsregler som behövs måste du bestämma vilka nätverksklienter som ska kunna nå App Service-miljön som innehåller API-appen och vilka klienter som blockeras.

Eftersom nätverkssäkerhetsgrupper (NSG: er) tillämpas på undernät och App Service-miljön distribueras till undernät gäller reglerna i en NSG för alla appar som körs på en App Service-miljön. Med hjälp av exempelarkitekturen för den här artikeln, när en nätverkssäkerhetsgrupp har tillämpats på undernätet som innehåller "apiase", skyddas alla appar som körs på "apiase" App Service-miljön av samma uppsättning säkerhetsregler.

  • Fastställa den utgående IP-adressen för uppströmsuppringare: Vad är IP-adressen eller adresserna för de överordnade anroparna? Dessa adresser måste uttryckligen tillåtas åtkomst i NSG. Eftersom anrop mellan App Service-miljön betraktas som "Internet"-anrop måste den utgående IP-adressen som tilldelats var och en av de tre överordnade App Service-miljön tillåtas åtkomst i NSG för undernätet "apiase". Mer information om hur du fastställer den utgående IP-adressen för appar som körs i en App Service-miljön finns i artikeln Översikt över nätverksarkitektur.
  • Måste serverdels-API-appen anropa sig själv? En ibland förbisedd och subtil punkt är scenariot där serverdelsprogrammet måste anropa sig själv. Om ett serverdels-API-program på en App Service-miljön behöver anropa sig själv behandlas det också som ett "Internet"-anrop. I exempelarkitekturen kräver detta att du tillåter åtkomst från den utgående IP-adressen för "apiase" App Service-miljön också.

Konfigurera nätverkssäkerhetsgruppen

När uppsättningen utgående IP-adresser är kända är nästa steg att skapa en nätverkssäkerhetsgrupp. Nätverkssäkerhetsgrupper kan skapas för både Resource Manager-baserade virtuella nätverk och klassiska virtuella nätverk. I följande exempel visas hur du skapar och konfigurerar en NSG i ett klassiskt virtuellt nätverk med hjälp av PowerShell.

För exempelarkitekturen finns miljöerna i USA, södra centrala, så en tom NSG skapas i den regionen:

New-AzureNetworkSecurityGroup -Name "RestrictBackendApi" -Location "South Central US" 
-Label "Only allow web frontend and loopback traffic"

Först läggs en explicit tillåt-regel till för Azure-hanteringsinfrastrukturen enligt artikeln om inkommande trafik för App Service-miljön.

#Open ports for access by Azure management infrastructure
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" 
-Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET' -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

Därefter läggs två regler till för att tillåta HTTP- och HTTPS-anrop från den första överordnade App Service-miljön ("fe1ase").

#Grant access to requests from the first upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe1ase" 
-Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '65.52.xx.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe1ase" 
-Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '65.52.xx.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Skölj och upprepa för den andra och tredje uppströms App Service-miljön ("fe2ase" och "fe3ase").

#Grant access to requests from the second upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe2ase" 
-Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '191.238.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe2ase" 
-Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '191.238.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

#Grant access to requests from the third upstream web front-end
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP fe3ase" 
-Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '23.98.abc.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS fe3ase" 
-Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '23.98.abc.xyz'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Slutligen beviljar du åtkomst till den utgående IP-adressen för serverdels-API:ets App Service-miljön så att den kan anropa tillbaka till sig själv.

#Allow apps on the apiase environment to call back into itself
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTP apiase" 
-Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '70.37.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityRule -Name "ALLOW HTTPS apiase" 
-Type Inbound -Priority 900 -Action Allow -SourceAddressPrefix '70.37.xyz.abc'  -SourcePortRange '*' 
-DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Inga andra nätverkssäkerhetsregler krävs eftersom varje NSG har en uppsättning standardregler som blockerar inkommande åtkomst från Internet som standard.

Den fullständiga listan över regler i nätverkssäkerhetsgruppen visas. Observera hur den sista regeln, som är markerad, blockerar inkommande åtkomst från alla anropare, förutom anropare som uttryckligen beviljas åtkomst.

NSG-konfiguration

Det sista steget är att tillämpa NSG på det undernät som innehåller "apiase" App Service-miljön.

#Apply the NSG to the backend API subnet
Get-AzureNetworkSecurityGroup -Name "RestrictBackendApi" | Set-AzureNetworkSecurityGroupToSubnet 
-VirtualNetworkName 'yourvnetnamehere' -SubnetName 'API-ASE-Subnet'

Med den NSG som tillämpas på undernätet tillåts endast de tre överordnade App Service-miljön och App Service-miljön som innehåller API-serverdelen att anropa till "apiase"-miljön.

Information om nätverkssäkerhetsgrupper.

Förstå utgående IP-adresser och App Service-miljön.

Nätverksportar som används av App Service-miljön.

Kommentar

Om du vill komma igång med Azure App Service innan du registrerar dig för ett Azure-konto kan du gå till Prova App Service. Där kan du direkt skapa en tillfällig startwebbapp i App Service. Inga kreditkort krävs. Inga åtaganden.