Implementowanie architektury zabezpieczeń warstwowych za pomocą środowisk App Service Environment

  • Artykuł

Ważne

Ten artykuł dotyczy środowiska App Service Environment w wersji 1. Środowisko App Service Environment w wersji 1 zostanie wycofane 31 sierpnia 2024 r. Jest dostępna nowa wersja środowiska App Service Environment, która jest łatwiejsza do użycia i działa w bardziej wydajnej infrastrukturze. Aby dowiedzieć się więcej o nowej wersji, zacznij od wprowadzenia do środowiska App Service Environment. Jeśli obecnie używasz środowiska App Service Environment w wersji 1, wykonaj kroki opisane w tym artykule , aby przeprowadzić migrację do nowej wersji.

Od 29 stycznia 2024 r. nie można już tworzyć nowych zasobów środowiska App Service Environment w wersji 1 przy użyciu dowolnej z dostępnych metod, w tym szablonów usługi ARM/Bicep, witryny Azure Portal, interfejsu wiersza polecenia platformy Azure lub interfejsu API REST. Aby zapobiec usunięciu zasobów i utracie danych, musisz przeprowadzić migrację do środowiska App Service Environment w wersji 3 przed 31 sierpnia 2024 r.

Ponieważ środowiska App Service Environment zapewniają izolowane środowisko uruchomieniowe wdrożone w sieci wirtualnej, deweloperzy mogą utworzyć architekturę zabezpieczeń warstwową zapewniającą różne poziomy dostępu sieciowego dla każdej warstwy aplikacji fizycznej.

Typowym pragnieniem jest ukrycie zapleczy interfejsu API przed ogólnym dostępem do Internetu i zezwolenie tylko na wywoływanie interfejsów API przez nadrzędne aplikacje internetowe. Sieciowe grupy zabezpieczeń mogą być używane w podsieciach zawierających środowiska App Service Environment w celu ograniczenia publicznego dostępu do aplikacji interfejsu API.

Na poniższym diagramie przedstawiono przykładową architekturę z aplikacją opartą na interfejsie WebAPI wdrożonym w środowisku App Service Environment. Trzy oddzielne wystąpienia aplikacji internetowej, wdrożone w trzech oddzielnych środowiskach App Service Environment, tworzą wywołania zaplecza do tej samej aplikacji WebAPI.

Conceptual Architecture

Zielony znak plus wskazuje, że sieciowa grupa zabezpieczeń w podsieci zawierającej "apiase" zezwala na wywołania przychodzące z nadrzędnych aplikacji internetowych, a także wywołania z samego siebie. Jednak ta sama sieciowa grupa zabezpieczeń jawnie odmawia dostępu do ogólnego ruchu przychodzącego z Internetu.

W pozostałej części tego artykułu przedstawiono kroki niezbędne do skonfigurowania sieciowej grupy zabezpieczeń w podsieci zawierającej "apiase".

Określanie zachowania sieci

Aby dowiedzieć się, jakie reguły zabezpieczeń sieci są potrzebne, należy określić, którzy klienci sieci będą mogli dotrzeć do środowiska App Service Environment zawierającego aplikację interfejsu API i które klienci będą blokowani.

Ponieważ sieciowe grupy zabezpieczeń są stosowane do podsieci, a środowiska App Service Environment są wdrażane w podsieciach, reguły zawarte w sieciowej grupie zabezpieczeń mają zastosowanie do wszystkich aplikacji uruchomionych w środowisku App Service Environment. Korzystając z przykładowej architektury tego artykułu, po zastosowaniu sieciowej grupy zabezpieczeń do podsieci zawierającej "apiase", wszystkie aplikacje uruchomione w środowisku App Service Environment "apiase" będą chronione przez ten sam zestaw reguł zabezpieczeń.

  • Ustal wychodzący adres IP nadrzędnych wywołujących: jaki jest adres IP lub adresy nadrzędnych osób wywołujących? Te adresy muszą być jawnie dozwolone w sieciowej grupie zabezpieczeń. Ponieważ wywołania między środowiskami App Service Environment są uznawane za wywołania "Internetowe", wychodzący adres IP przypisany do każdego z trzech nadrzędnych środowisk App Service Environment musi mieć dozwolony dostęp w sieciowej grupie zabezpieczeń dla podsieci "apiase". Aby uzyskać więcej informacji na temat określania wychodzącego adresu IP dla aplikacji działających w środowisku App Service Environment, zobacz artykuł Omówienie architektury sieci.
  • Czy aplikacja interfejsu API zaplecza będzie musiała wywoływać się samodzielnie? Czasami pomijany i subtelny punkt to scenariusz, w którym aplikacja zaplecza musi wywołać samą siebie. Jeśli aplikacja interfejsu API zaplecza w środowisku App Service Environment musi wywołać samą siebie, jest ona również traktowana jako wywołanie "Internet". W przykładowej architekturze wymaga to również zezwolenia na dostęp z wychodzącego adresu IP środowiska App Service Environment "apiase".

Konfigurowanie sieciowej grupy zabezpieczeń

Po zdaniu zestawu wychodzących adresów IP następnym krokiem jest utworzenie sieciowej grupy zabezpieczeń. Sieciowe grupy zabezpieczeń można tworzyć zarówno dla sieci wirtualnych opartych na usłudze Resource Manager, jak i klasycznych sieciach wirtualnych. W poniższych przykładach pokazano tworzenie i konfigurowanie sieciowej grupy zabezpieczeń w klasycznej sieci wirtualnej przy użyciu programu PowerShell.

W przypadku przykładowej architektury środowiska znajdują się w południowo-środkowych stanach USA, więc w tym regionie jest tworzona pusta sieciowa grupa zabezpieczeń:

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

Najpierw dodano jawną regułę zezwalania dla infrastruktury zarządzania platformy Azure, jak wspomniano w artykule dotyczącym ruchu przychodzącego dla środowisk App Service Environment.

#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

Następnie dodano dwie reguły zezwalania na wywołania HTTP i HTTPS z pierwszego nadrzędnego środowiska App Service Environment ("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

Wypłukać i powtarzać dla drugiego i trzeciego nadrzędnego środowiska App Service Environment ("fe2ase" i "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

Na koniec przyznaj dostęp do wychodzącego adresu IP środowiska App Service Environment interfejsu API zaplecza, aby można było wywołać go z powrotem do samego siebie.

#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

Nie są wymagane żadne inne reguły zabezpieczeń sieci, ponieważ każda sieciowa grupa zabezpieczeń ma zestaw domyślnych reguł, które domyślnie blokują dostęp przychodzący z Internetu.

Poniżej przedstawiono pełną listę reguł w sieciowej grupie zabezpieczeń. Zwróć uwagę, jak ostatnia reguła, która jest wyróżniona, blokuje dostęp przychodzący ze wszystkich osób wywołujących, innych niż osoby wywołujące, którym jawnie udzielono dostępu.

NSG Configuration

Ostatnim krokiem jest zastosowanie sieciowej grupy zabezpieczeń do podsieci zawierającej środowisko App Service Environment "apiase".

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

Po zastosowaniu sieciowej grupy zabezpieczeń do podsieci tylko trzy nadrzędne środowiska App Service Environment i środowisko App Service Environment zawierające zaplecze interfejsu API mogą wywoływać środowisko "apiase".

Informacje o sieciowych grupach zabezpieczeń.

Opis wychodzących adresów IP i środowisk App Service Environment.

Porty sieciowe używane przez środowiska App Service Environment.

Uwaga

Jeśli chcesz rozpocząć pracę z usługą Azure App Service przed utworzeniem nowego konta Azure, przejdź do strony Wypróbuj usługę App Service, na której możesz od razu utworzyć startową tymczasową aplikację internetową przy użyciu usługi App Service. Bez kart kredytowych i bez zobowiązań.