Bezpieczne łączenie z zasobami zaplecza ze środowiska App Service Environment

Ważne

Ten artykuł dotyczy środowiska App Service Environment w wersji 1. Środowisko App Service Environment w wersji 1 i v2 jest wycofyzowane od 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 31 sierpnia 2024 r. umowa dotycząca poziomu usług (SLA) i środki na usługi nie mają już zastosowania do obciążeń środowiska App Service Environment w wersji 1 i w wersji 2, które nadal znajdują się w środowisku produkcyjnym, ponieważ są wycofane produkty. Rozpoczęto likwidowanie sprzętu środowiska App Service Environment w wersji 1 i 2. Może to mieć wpływ na dostępność i wydajność aplikacji i danych.

Musisz natychmiast ukończyć migrację do środowiska App Service Environment w wersji 3 lub usunąć aplikacje i zasoby. Podejmiemy próbę automatycznej migracji wszystkich pozostałych środowisk App Service Environment w wersji 1 i 2 w oparciu o najlepsze rozwiązanie przy użyciu funkcji migracji w miejscu, ale firma Microsoft nie udziela żadnych oświadczeń ani gwarancji dotyczących dostępności aplikacji po migracji automatycznej. Może być konieczne wykonanie ręcznej konfiguracji w celu ukończenia migracji i zoptymalizowania wybranej jednostki SKU planu usługi App Service w celu spełnienia Twoich potrzeb. Jeśli automatyczna migracja nie jest wykonalna, zasoby i skojarzone dane aplikacji zostaną usunięte. Zdecydowanie zachęcamy do podjęcia działań, aby uniknąć jednego z tych ekstremalnych scenariuszy.

Jeśli potrzebujesz dodatkowego czasu, możemy zaoferować jednorazowy 30-dniowy okres prolongaty umożliwiający ukończenie migracji. Aby uzyskać więcej informacji i zażądać tego okresu prolongaty, zapoznaj się z omówieniem okresu prolongaty, a następnie przejdź do witryny Azure Portal i odwiedź blok Migracja dla każdego środowiska App Service Environment.

Aby uzyskać najbardziej aktualne informacje na temat wycofania środowiska App Service Environment w wersji 1/2, zobacz aktualizację wycofania środowiska App Service Environment w wersji 1 i 2.

Ponieważ środowisko App Service Environment jest zawsze tworzone w sieci wirtualnej usługi Azure Resource Manager lub klasycznej sieci wirtualnej modelu wdrażania, połączenia wychodzące ze środowiska App Service Environment do innych zasobów zaplecza mogą przepływać wyłącznie za pośrednictwem sieci wirtualnej. 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).

Na przykład na klastrze maszyn wirtualnych z zablokowanym portem 1433 może istnieć program SQL Server uruchomiony w klastrze maszyn wirtualnych. Punkt końcowy może być ALD, aby zezwolić tylko na dostęp z innych zasobów w tej samej sieci wirtualnej.

W innym przykładzie poufne punkty końcowe mogą działać lokalnie i być połączone z platformą Azure za pośrednictwem połączeń typu lokacja-lokacja lub usługi Azure ExpressRoute . W związku z tym tylko zasoby w sieciach wirtualnych połączonych z tunelami lokacja-lokacja lub ExpressRoute mogą uzyskiwać dostęp do lokalnych punktów końcowych.

W przypadku wszystkich tych scenariuszy aplikacje działające w środowisku App Service Environment mogą bezpiecznie łączyć się z różnymi serwerami i zasobami. Jeśli ruch wychodzący z aplikacji działa w środowisku App Service Environment do prywatnych punktów końcowych w tej samej sieci wirtualnej lub połączony z tą samą siecią wirtualną, przepływa tylko za pośrednictwem sieci wirtualnej. Ruch wychodzący do prywatnych punktów końcowych nie będzie przepływać przez publiczny Internet.

Jednym z problemów jest ruch wychodzący ze środowiska App Service Environment do punktów końcowych w sieci wirtualnej. Środowiska App Service Environment nie mogą uzyskać dostępu do punktów końcowych maszyn wirtualnych znajdujących się w tej samej podsieci co środowisko App Service Environment. To ograniczenie zwykle nie powinno być problemem, jeśli środowiska App Service Environment są wdrażane w podsieci zarezerwowanej wyłącznie przez środowisko App Service Environment.

Uwaga

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

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 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 łączność sieciowa" 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. W górnej części bloku zarządzania środowiska App Service Environment w portalu wybierz ikonę Uruchom ponownie , aby wyzwolić ponowny rozruch środowiska operacyjnego, co powoduje, że środowisko pobiera nową konfigurację DNS.

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, spowoduje to niepowodzenie procesu tworzenia środowiska App Service Environment. Na drugim końcu bramy sieci VPN, jeśli istnieje niestandardowy serwer DNS, który jest nieosiągalny lub niedostępny, proces tworzenia środowiska App Service Environment również zakończy się niepowodzeniem.

Nawiązywanie połączenia z programem SQL Server

Typowa konfiguracja programu SQL Server ma punkt końcowy nasłuchujący na porcie 1433:

Istnieją dwie metody ograniczania ruchu do tego punktu końcowego:

• Listy kontroli dostępu do sieci (listy ACL sieci)
• Grupy zabezpieczeń sieci

Ograniczanie dostępu przy użyciu listy ACL sieci

Port 1433 można zabezpieczyć przy użyciu listy kontroli dostępu do sieci. W poniższym przykładzie dodano uprawnienia do przypisywania adresy klientów pochodzące z sieci wirtualnej i blokuje dostęp do wszystkich innych klientów.

Wszystkie aplikacje uruchamiane w środowisku App Service Environment w tej samej sieci wirtualnej co program SQL Server mogą łączyć się z wystąpieniem programu SQL Server. Użyj wewnętrznego adresu IP sieci wirtualnej dla maszyny wirtualnej z programem SQL Server.

Poniższy przykład parametry połączenia odwołuje się do programu SQL Server przy użyciu jego prywatnego adresu IP.

Server=tcp:10.0.1.6;Database=MyDatabase;User ID=MyUser;Password=PasswordHere;provider=System.Data.SqlClient

Mimo że maszyna wirtualna ma również publiczny punkt końcowy, próby nawiązania połączenia z publicznym adresem IP zostaną odrzucone z powodu sieciowej listy ACL.

Ograniczanie dostępu za pomocą sieciowej grupy zabezpieczeń

Alternatywną metodą zabezpieczania dostępu jest użycie sieciowej grupy zabezpieczeń. Sieciowe grupy zabezpieczeń można stosować do poszczególnych maszyn wirtualnych lub do podsieci zawierającej maszyny wirtualne.

Najpierw należy utworzyć sieciową grupę zabezpieczeń:

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

Ograniczenie dostępu tylko do ruchu wewnętrznego sieci wirtualnej jest proste w przypadku sieciowej grupy zabezpieczeń. Domyślne reguły w sieciowej grupie zabezpieczeń zezwalają tylko na dostęp z innych klientów sieci w tej samej sieci wirtualnej.

W związku z tym blokowanie dostępu do programu SQL Server jest proste. Po prostu zastosuj sieciową grupę zabezpieczeń z jej domyślnymi regułami do maszyn wirtualnych z uruchomionym programem SQL Server lub podsiecią zawierającą maszyny wirtualne.

Poniższy przykład stosuje sieciową grupę zabezpieczeń do zawierającej podsieci:

Get-AzureNetworkSecurityGroup -Name "testNSGExample" | Set-AzureNetworkSecurityGroupToSubnet -VirtualNetworkName 'testVNet' -SubnetName 'Subnet-1'

Końcowy wynik jest zestawem reguł zabezpieczeń, które blokują dostęp zewnętrzny, jednocześnie zezwalając na dostęp wewnętrzny sieci wirtualnej:

Wprowadzenie

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

Aby uzyskać szczegółowe informacje na temat kontrolowania ruchu przychodzącego do środowiska App Service Environment, zobacz Kontrolowanie ruchu przychodzącego do ś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ń.