Dela via

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

  • Artikel

Viktigt!

Den här artikeln handlar om App Service Environment v1. App Service Environment v1 och v2 dras tillbaka den 31 augusti 2024. Det finns en ny version av App Service Environment som är enklare att använda och körs 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 Environment v1 följer du stegen i den här artikeln för att migrera till den nya versionen.

Efter den 31 augusti 2024 påbörjas avvecklingen av App Service Environment v1- och v2-maskinvaran, vilket kan påverka tillgängligheten och prestandan för dina appar och data. Serviceavtal (SLA) och tjänstkrediter gäller inte längre för App Service Environment v1- och v2-arbetsbelastningar som fortsätter att vara i produktion efter den 31 augusti 2024.

Du måste slutföra migreringen till App Service Environment v3 före den 31 augusti 2024 eller så kan dina appar och resurser tas bort. Vi försöker automatiskt migrera alla återstående App Service Environment 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.

Den senaste informationen om tillbakadragning av App Service Environment v1/v2 finns i apptjänstmiljön v1 och v2.

Eftersom App Service-miljöer 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öer för att begränsa offentlig åtkomst till API-program.

Diagrammet nedan visar en exempelarkitektur med en WebAPI-baserad app som distribueras i en App Service-miljö. Tre separata webbappsinstanser, distribuerade i tre separata App Service-miljöer, 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 ska blockeras.

Eftersom nätverkssäkerhetsgrupper (NSG:er) tillämpas på undernät och App Service-miljöer distribueras till undernät gäller reglerna i en NSG för alla appar som körs i en App Service-miljö. När en nätverkssäkerhetsgrupp tillämpas på undernätet som innehåller "apiase" med hjälp av exempelarkitekturen för den här artikeln skyddas alla appar som körs i apptjänstmiljön "apiase" 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 nätverkssäkerhetsgruppen. Eftersom anrop mellan App Service-miljöer betraktas som "Internet"-anrop måste den utgående IP-adressen som tilldelats var och en av de tre överordnade App Service-miljöerna 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ö 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 i en App Service-miljö behöver anropa sig själv, behandlas det också som ett "Internet"-anrop. I exempelarkitekturen kräver detta att du även tillåter åtkomst från den utgående IP-adressen för apptjänstmiljön "apiase".

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. Exemplen nedan visar 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 vad som anges i artikeln om inkommande trafik för App Service-miljöer.

#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 överordnade 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 Environment 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 nedan. Observera hur den sista regeln, som är markerad, blockerar inkommande åtkomst från alla anropare, förutom anropare som uttryckligen har beviljats åtkomst.

NSG-konfiguration

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

#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öerna 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öer.

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

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.