Jak kontrolować ruch przychodzący do środowiska App Service Environment

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.

Omówienie

Środowisko App Service Environment można utworzyć w sieci wirtualnej usługi Azure Resource Manager lub w klasycznej sieci wirtualnej modelu wdrażania. W momencie utworzenia środowiska App Service Environment można zdefiniować nową sieć wirtualną i nową podsieć. Zamiast tego środowisko App Service Environment można utworzyć w istniejącej sieci wirtualnej i wstępnie istniejącej podsieci. Od czerwca 2016 r. środowiska ASE mogą być również wdrażane w sieciach wirtualnych, które używają zakresów adresów publicznych lub RFC1918 przestrzeni adresowych (adresów prywatnych). Aby uzyskać więcej informacji, zobacz How to Create an ASEv1 from template (Jak utworzyć asev1 na podstawie szablonu).

Zawsze twórz środowisko App Service Environment w podsieci. Podsieć udostępnia granicę sieci, która może służyć do blokowania ruchu przychodzącego za urządzeniami i usługami nadrzędnymi. Ta konfiguracja umożliwia akceptowanie ruchu HTTP i HTTPS tylko określonych nadrzędnych adresów IP.

Przychodzący i wychodzący ruch sieciowy w podsieci jest kontrolowany przy użyciu sieciowej grupy zabezpieczeń. Aby kontrolować ruch przychodzący, utwórz reguły zabezpieczeń sieci w sieciowej grupie zabezpieczeń. Następnie przypisz sieciową grupę zabezpieczeń podsieć zawierającą środowisko App Service Environment.

Po przypisaniu sieciowej grupy zabezpieczeń do podsieci ruch przychodzący do aplikacji w środowisku App Service Environment jest dozwolony lub blokowany na podstawie reguł zezwalania i odmowy zdefiniowanych w sieciowej grupie zabezpieczeń.

Uwaga

Mimo że ten artykuł dotyczy aplikacji internetowych, ma również zastosowanie do aplikacji interfejsu API i aplikacji mobilnych.

Porty sieciowe dla ruchu przychodzącego używane w środowisku App Service Environment

Przed zablokowaniem przychodzącego ruchu sieciowego przy użyciu sieciowej grupy zabezpieczeń należy poznać zestaw wymaganych i opcjonalnych portów sieciowych używanych przez środowisko App Service Environment. Przypadkowe zamknięcie ruchu do niektórych portów może spowodować utratę funkcjonalności w środowisku App Service Environment.

Poniższa lista zawiera porty używane przez środowisko App Service Environment. Wszystkie porty są portami TCP, chyba że określono inaczej:

  • 454: Wymagany port używany przez infrastrukturę platformy Azure do zarządzania środowiskami App Service Environment i ich obsługi za pośrednictwem protokołu TLS. Nie blokuj ruchu na tym porcie. Ten port jest zawsze powiązany z publicznym adresem VIP środowiska ASE.
  • 455: Wymagany port używany przez infrastrukturę platformy Azure do zarządzania środowiskami App Service Environment i ich obsługi za pośrednictwem protokołu TLS. Nie blokuj ruchu na tym porcie. Ten port jest zawsze powiązany z publicznym adresem VIP środowiska ASE.
  • 80: Domyślny port dla przychodzącego ruchu HTTP do aplikacji działających w planach usługi App Service w środowisku App Service Environment. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.
  • 443: Domyślny port dla przychodzącego ruchu TLS do aplikacji uruchamianych w planach usługi App Service w środowisku App Service Environment. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.
  • 21: Kanał sterowania dla protokołu FTP. Ten port można bezpiecznie zablokować, jeśli protokół FTP nie jest używany. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port może być powiązany z adresem wewnętrznym modułu równoważenia obciążenia dla środowiska ASE.
  • 990: Kanał sterowania dla protokołu FTPS. Ten port można bezpiecznie zablokować, jeśli usługa FTPS nie jest używana. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port może być powiązany z adresem wewnętrznym modułu równoważenia obciążenia dla środowiska ASE.
  • 10001-10020: Kanały danych dla protokołu FTP. Podobnie jak w przypadku kanału sterowania, te porty można bezpiecznie zablokować, jeśli protokół FTP nie jest używany. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port może być powiązany z adresem wewnętrznym modułu równoważenia obciążenia środowiska ASE.
  • 4016: służy do zdalnego debugowania w programie Visual Studio 2012. Ten port można bezpiecznie zablokować, jeśli funkcja nie jest używana. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.
  • 4018: służy do zdalnego debugowania w programie Visual Studio 2013. Ten port można bezpiecznie zablokować, jeśli funkcja nie jest używana. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.
  • 4020: służy do zdalnego debugowania w programie Visual Studio 2015. Ten port można bezpiecznie zablokować, jeśli funkcja nie jest używana. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.
  • 4022: służy do zdalnego debugowania w programie Visual Studio 2017. Ten port można bezpiecznie zablokować, jeśli funkcja nie jest używana. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.
  • 4024 Używany do zdalnego debugowania w programie Visual Studio 2019. Ten port można bezpiecznie zablokować, jeśli funkcja nie jest używana. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.
  • 4026: służy do zdalnego debugowania w programie Visual Studio 2022. Ten port można bezpiecznie zablokować, jeśli funkcja nie jest używana. W przypadku środowiska ASE z włączoną wewnętrznym modułem równoważenia obciążenia ten port jest powiązany z adresem ILB środowiska ASE.

Outbound Connectivity and DNS Requirements (Wymagania dotyczące łączności wychodzącej i systemu DNS)

Aby środowisko App Service Environment działało prawidłowo, wymaga również dostępu wychodzącego do różnych punktów końcowych. Pełna lista zewnętrznych punktów końcowych używanych przez środowisko ASE znajduje się w sekcji "Wymagana Połączenie ivity sieci" artykułu Konfiguracja sieci dla usługi ExpressRoute.

Środowiska App Service Environment wymagają prawidłowej infrastruktury DNS skonfigurowanej dla sieci wirtualnej. Jeśli konfiguracja DNS zostanie zmieniona po utworzeniu środowiska App Service Environment, deweloperzy mogą wymusić, aby środowisko App Service Environment odebrało nową konfigurację DNS. Jeśli wyzwalasz ponowne uruchomienie środowiska operacyjnego przy użyciu ikony Ponowne uruchamianie , środowisko pobiera nową konfigurację DNS. (Ikona ponownego uruchamiania znajduje się w górnej części bloku zarządzania środowiska App Service Environment w witrynie Azure Portal).

Zaleca się również, aby przed utworzeniem środowiska App Service Environment skonfigurować wszystkie niestandardowe serwery DNS w sieci wirtualnej. Jeśli konfiguracja DNS sieci wirtualnej zostanie zmieniona podczas tworzenia środowiska App Service Environment, proces tworzenia środowiska App Service Environment zakończy się niepowodzeniem. Podobnie, jeśli istnieje niestandardowy serwer DNS, który jest nieosiągalny lub niedostępny na drugim końcu bramy sieci VPN, proces tworzenia środowiska App Service Environment również zakończy się niepowodzeniem.

Tworzenie sieciowej grupy zabezpieczeń

Aby uzyskać szczegółowe informacje na temat sposobu działania sieciowych grup zabezpieczeń, zobacz następujące informacje. Poniższy przykład zarządzania usługami platformy Azure dotyczy wyróżniania sieciowych grup zabezpieczeń. Przykład konfiguruje i stosuje sieciową grupę zabezpieczeń do podsieci zawierającej środowisko App Service Environment.

Uwaga: sieciowe grupy zabezpieczeń można skonfigurować graficznie przy użyciu witryny Azure Portal lub programu Azure PowerShell.

Sieciowe grupy zabezpieczeń są najpierw tworzone jako autonomiczna jednostka skojarzona z subskrypcją. Ponieważ sieciowe grupy zabezpieczeń są tworzone w regionie świadczenia usługi Azure, utwórz sieciową grupę zabezpieczeń w tym samym regionie co środowisko App Service Environment.

Następujące polecenie demonstruje tworzenie sieciowej grupy zabezpieczeń:

New-AzureNetworkSecurityGroup -Name "testNSGexample" -Location "South Central US" -Label "Example network security group for an app service environment"

Po utworzeniu sieciowej grupy zabezpieczeń zostanie do niej dodana co najmniej jedna reguła zabezpieczeń sieci. Ponieważ zestaw reguł może ulec zmianie w czasie, należy określić schemat numerowania używany dla priorytetów reguł. Ta praktyka ułatwia wstawianie dodatkowych reguł w czasie.

W poniższym przykładzie reguła jawnie udziela dostępu do portów zarządzania wymaganych przez infrastrukturę platformy Azure do zarządzania środowiskiem App Service Environment i zarządzania nim. Cały ruch zarządzania przepływa przez protokół TLS i jest zabezpieczony przez certyfikaty klienta. Mimo że porty są otwarte, są one niedostępne dla dowolnej jednostki innej niż infrastruktura zarządzania platformy Azure.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "ALLOW AzureMngmt" -Type Inbound -Priority 100 -Action Allow -SourceAddressPrefix 'INTERNET'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '454-455' -Protocol TCP

Jeśli zablokujesz dostęp do portu 80 i 443 w celu "ukrycia" środowiska App Service Environment za nadrzędnymi urządzeniami lub usługami, pamiętaj o nadrzędnym adresie IP. Jeśli na przykład używasz zapory aplikacji internetowej (WAF), zapora aplikacji internetowej będzie mieć własny adres IP lub adresy. Zapora aplikacji internetowej używa ich podczas proxy ruchu do podrzędnego środowiska App Service Environment. Należy użyć tego adresu IP w parametrze SourceAddressPrefix reguły zabezpieczeń sieci.

W poniższym przykładzie ruch przychodzący z określonego nadrzędnego adresu IP jest jawnie dozwolony. Adres 1.2.3.4 jest używany jako symbol zastępczy adresu IP nadrzędnej zapory aplikacji internetowej. Zmień wartość tak, aby była zgodna z adresem używanym przez urządzenie lub usługę nadrzędną.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTP" -Type Inbound -Priority 200 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '80' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT HTTPS" -Type Inbound -Priority 300 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '443' -Protocol TCP

Jeśli jest poszukiwana obsługa protokołu FTP, użyj następujących reguł jako szablonu, aby udzielić dostępu do portów kontroli FTP i portów kanału danych. Ponieważ protokół FTP jest protokołem stanowym, może nie być możliwe kierowanie ruchu FTP przez tradycyjną zaporę HTTP/HTTPS lub urządzenie proxy. W takim przypadku należy ustawić wartość SourceAddressPrefix na inną wartość, taką jak zakres adresów IP deweloperów lub maszyn wdrożeniowych, na których działają klienci FTP.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPCtrl" -Type Inbound -Priority 400 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '21' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT FTPDataRange" -Type Inbound -Priority 500 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '10001-10020' -Protocol TCP

(Uwaga: zakres portów kanału danych może ulec zmianie w okresie obowiązywania wersji zapoznawczej).

Jeśli używane jest zdalne debugowanie za pomocą programu Visual Studio, poniższe reguły pokazują, jak udzielić dostępu. Istnieje oddzielna reguła dla każdej obsługiwanej wersji programu Visual Studio, ponieważ każda wersja używa innego portu do zdalnego debugowania. Podobnie jak w przypadku dostępu do protokołu FTP, ruch zdalnego debugowania może nie przepływać prawidłowo za pośrednictwem tradycyjnej zapory aplikacji internetowej lub urządzenia proxy. Zamiast tego można ustawić wartość SourceAddressPrefix na zakres adresów IP maszyn deweloperskich z uruchomionym programem Visual Studio.

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2012" -Type Inbound -Priority 600 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4016' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2013" -Type Inbound -Priority 700 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4018' -Protocol TCP
Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityRule -Name "RESTRICT RemoteDebuggingVS2015" -Type Inbound -Priority 800 -Action Allow -SourceAddressPrefix '1.2.3.4/32'  -SourcePortRange '*' -DestinationAddressPrefix '*' -DestinationPortRange '4020' -Protocol TCP

Przypisywanie sieciowej grupy zabezpieczeń do podsieci

Sieciowa grupa zabezpieczeń ma domyślną regułę zabezpieczeń, która odmawia dostępu do całego ruchu zewnętrznego. Po połączeniu tej reguły z powyższymi regułami zabezpieczeń sieci tylko ruch z zakresów adresów źródłowych skojarzonych z akcją Zezwalaj będzie mógł wysyłać ruch do aplikacji uruchamianych w środowisku App Service Environment.

Po wypełnieniu sieciowej grupy zabezpieczeń regułami zabezpieczeń przypisz ją do podsieci zawierającej środowisko App Service Environment. Polecenie przypisania odwołuje się do dwóch nazw: nazwy sieci wirtualnej, w której znajduje się środowisko App Service Environment, oraz nazwy podsieci, w której utworzono środowisko App Service Environment.

W poniższym przykładzie przedstawiono sieciową grupę zabezpieczeń przypisaną do podsieci i sieci wirtualnej:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

Przypisanie jest długotrwałą operacją i ukończenie jej może potrwać kilka minut. Po pomyślnym pomyślnym przypisaniu sieciowej grupy zabezpieczeń tylko ruch przychodzący zgodny z regułami Zezwalaj będzie pomyślnie docierać do aplikacji w środowisku App Service Environment.

W przypadku kompletności w poniższym przykładzie pokazano, jak usunąć i usunąć skojarzenie sieciowej grupy zabezpieczeń z podsieci:

Get-AzureNetworkSecurityGroup -Name "testNSGexample" | Remove-AzureNetworkSecurityGroupFromSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-test'

Specjalne zagadnienia dotyczące jawnego protokołu IP-SSL

Jeśli aplikacja jest skonfigurowana z jawnym adresem IP-SSL (dotyczy tylko środowisk ASE, które mają publiczny adres VIP), zamiast używać domyślnego adresu IP środowiska App Service Environment, ruch HTTP i HTTPS przepływa do podsieci przez porty inne niż porty 80 i 443.

Aby znaleźć pojedynczą parę portów używanych przez każdy adres IP SSL, przejdź do portalu i wyświetl blok środowiska użytkownika środowiska App Service Environment. Wybierz pozycję Wszystkie ustawienia>Adresy IP. Blok Adresy IP zawiera tabelę wszystkich jawnie skonfigurowanych adresów IP SSL dla środowiska App Service Environment. Blok zawiera również specjalną parę portów używaną do kierowania ruchu HTTP i HTTPS skojarzonego z każdym adresem IP-SSL. Użyj tej pary portów dla parametrów DestinationPortRange podczas konfigurowania reguł w sieciowej grupie zabezpieczeń.

Gdy aplikacja w usłudze ASE jest skonfigurowana do korzystania z protokołu IP-SSL, klienci zewnętrzni nie zobaczą ani nie będą musieli martwić się o specjalne mapowanie par portów. Ruch do aplikacji będzie przepływać normalnie do skonfigurowanego adresu IP SSL. Tłumaczenie na specjalną parę portów odbywa się automatycznie wewnętrznie, podczas końcowego etapu ruchu routingu do podsieci zawierającej środowisko ASE.

Wprowadzenie

Aby rozpocząć pracę ze środowiskami App Service Environment, zobacz Wprowadzenie do środowiska App Service Environment.

Aby uzyskać więcej informacji, zobacz Bezpieczne łączenie z zasobami zaplecza ze ś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ń.