Funkcje sieciowe usługi App Service

Aplikacje można wdrażać w usłudze aplikacja systemu Azure na wiele sposobów. Domyślnie aplikacje hostowane w usłudze App Service są dostępne bezpośrednio za pośrednictwem Internetu i mogą uzyskiwać dostęp tylko do punktów końcowych hostowanych w Internecie. Jednak w przypadku wielu aplikacji należy kontrolować przychodzący i wychodzący ruch sieciowy. Usługa App Service oferuje kilka funkcji, które ułatwiają spełnienie tych potrzeb. Wyzwanie polega na tym, która funkcja ma być używana do rozwiązania danego problemu. Ten artykuł pomoże Określić, która funkcja ma być używana, na podstawie przykładowych przypadków użycia.

Istnieją dwa główne typy wdrożeń dla usługi aplikacja systemu Azure:

• Wielodostępna usługa publiczna hostuje plany usługi App Service w jednostkach SKU cen Bezpłatna, Współdzielona, Podstawowa, Standardowa, Premium, PremiumV2 i PremiumV3.
• Jednodostępne środowisko App Service Environment (ASE) hostuje plany usługi App Service izolowanej jednostki SKU bezpośrednio w sieci wirtualnej platformy Azure.

Używane funkcje zależą od tego, czy jesteś w usłudze wielodostępnej, czy w środowisku ASE.

Uwaga

Funkcje sieciowe nie są dostępne dla aplikacji wdrożonych w usłudze Azure Arc.

Funkcje sieciowe usługi App Service z wieloma dzierżawami

aplikacja systemu Azure Service to system rozproszony. Role obsługujące przychodzące żądania HTTP lub HTTPS są nazywane frontonami. Role hostujące obciążenie klienta są nazywane procesami roboczymi. Wszystkie role we wdrożeniu usługi App Service istnieją w sieci wielodostępnej. Ponieważ w tej samej jednostce skalowania usługi App Service istnieje wiele różnych klientów, nie można połączyć sieci usługi App Service bezpośrednio z siecią.

Zamiast łączyć sieci, potrzebne są funkcje do obsługi różnych aspektów komunikacji aplikacji. Funkcje obsługujące żądania do aplikacji nie mogą służyć do rozwiązywania problemów podczas wykonywania wywołań z aplikacji. Podobnie funkcje, które rozwiązują problemy z wywołaniami z aplikacji, nie mogą służyć do rozwiązywania problemów z aplikacją.

Funkcje ruchu przychodzącego	Funkcje ruchu wychodzącego
Adres przypisany do aplikacji	Połączenia hybrydowe
Ograniczenia dostępu	Integracja z siecią wirtualną wymaganą przez bramę
Punkty końcowe usługi	Integracja sieci wirtualnej
Prywatne punkty końcowe

Inne niż zanotowano wyjątki, można używać wszystkich tych funkcji razem. Możesz mieszać funkcje, aby rozwiązać problemy.

Przypadki użycia i funkcje

W przypadku danego przypadku użycia może istnieć kilka sposobów rozwiązania problemu. Wybór najlepszej funkcji czasami wykracza poza sam przypadek użycia. Następujące przychodzące przypadki użycia sugerują, jak używać funkcji sieciowych usługi App Service do rozwiązywania problemów z kontrolowaniem ruchu przechodzącego do aplikacji:

Przypadek użycia dla ruchu przychodzącego	Funkcja
Obsługa potrzeb protokołu SSL opartego na adresach IP dla aplikacji	Adres przypisany do aplikacji
Obsługa nieudostępnianych dedykowanych adresów przychodzących dla aplikacji	Adres przypisany do aplikacji
Ograniczanie dostępu do aplikacji z zestawu dobrze zdefiniowanych adresów	Ograniczenia dostępu
Ograniczanie dostępu do aplikacji z zasobów w sieci wirtualnej	Punkty końcowe usługi — wewnętrzne punkty końcowe środowiska ASE (ILB) — prywatne punkty końcowe usługi Load Balancer (ILB)
Uwidacznianie aplikacji na prywatnym adresie IP w sieci wirtualnej	Prywatne punkty końcowe środowiska ASE z wewnętrznym modułem równoważenia obciążenia — prywatny adres IP dla ruchu przychodzącego w wystąpieniu usługi Application Gateway z punktami końcowymi usługi
Ochrona aplikacji za pomocą zapory aplikacji internetowej (WAF)	Usługa Application Gateway i usługa ASE z wewnętrznym modułem równoważenia obciążenia usługi Application Gateway z prywatnymi punktami końcowymi usługi Application Gateway z punktami końcowymi usługi Azure Front Door z ograniczeniami dostępu
Równoważenie obciążenia ruchem do aplikacji w różnych regionach	Usługa Azure Front Door z ograniczeniami dostępu
Równoważenie obciążenia ruchu w tym samym regionie	Usługa Application Gateway z punktami końcowymi usługi

Następujące przypadki użycia ruchu wychodzącego sugerują, jak używać funkcji sieciowych usługi App Service do rozwiązywania wymagań dotyczących dostępu wychodzącego dla aplikacji:

Przypadek użycia ruchu wychodzącego	Funkcja
Uzyskiwanie dostępu do zasobów w sieci wirtualnej platformy Azure w tym samym regionie	Środowisko ASE integracji z siecią wirtualną
Uzyskiwanie dostępu do zasobów w sieci wirtualnej platformy Azure w innym regionie	integracja sieci wirtualnej i komunikacja równorzędna sieci wirtualnych — wymagana przez bramę integracja sieci wirtualnej — środowisko ASE i komunikacja równorzędna sieci wirtualnych
Uzyskiwanie dostępu do zasobów zabezpieczonych za pomocą punktów końcowych usługi	środowisko ASE integracji z siecią wirtualną
Uzyskiwanie dostępu do zasobów w sieci prywatnej, która nie jest połączona z platformą Azure	Połączenia hybrydowe
Uzyskiwanie dostępu do zasobów w obwodach usługi Azure ExpressRoute	środowisko ASE integracji z siecią wirtualną
Zabezpieczanie ruchu wychodzącego z aplikacji internetowej	integracja sieci wirtualnej i sieciowe grupy zabezpieczeń ASE
Kierowanie ruchu wychodzącego z aplikacji internetowej	integracja sieci wirtualnej i tabele tras ASE

Domyślne zachowanie sieci

aplikacja systemu Azure jednostki skalowania usługi obsługują wielu klientów w każdym wdrożeniu. Plany bezpłatnej i udostępnionej jednostki SKU obsługują obciążenia klientów w wielodostępnych pracownikach. Podstawowe i wyższe plany hostują obciążenia klientów dedykowane tylko do jednego planu usługi App Service. Jeśli masz plan usługi App Service w warstwie Standardowa, wszystkie aplikacje w tym planie będą uruchamiane na tym samym pracowniku. W przypadku skalowania w poziomie procesu roboczego wszystkie aplikacje w tym planie usługi App Service zostaną zreplikowane dla nowego procesu roboczego dla każdego wystąpienia w planie usługi App Service.

Adresy wychodzące

Maszyny wirtualne procesu roboczego są podzielone w dużej mierze przez plany usługi App Service. Plany Bezpłatna, Współdzielona, Podstawowa, Standardowa i Premium używają tego samego typu maszyny wirtualnej procesu roboczego. Plan PremiumV2 używa innego typu maszyny wirtualnej. Usługa PremiumV3 używa jeszcze innego typu maszyny wirtualnej. Po zmianie rodziny maszyn wirtualnych uzyskujesz inny zestaw adresów wychodzących. W przypadku skalowania z warstwy Standardowa do PremiumV2 adresy wychodzące zmienią się. W przypadku skalowania z wersji PremiumV2 do PremiumV3 adresy wychodzące zmienią się. W niektórych starszych jednostkach skalowania zarówno adresy przychodzące, jak i wychodzące zmienią się podczas skalowania z warstwy Standardowa na PremiumV2.

Istnieje wiele adresów używanych do wywołań wychodzących. Adresy wychodzące używane przez aplikację do wykonywania wywołań wychodzących są wymienione we właściwościach aplikacji. Te adresy są współużytkowane przez wszystkie aplikacje uruchomione w tej samej rodzinie maszyn wirtualnych procesu roboczego we wdrożeniu usługi App Service. Jeśli chcesz wyświetlić wszystkie adresy, których aplikacja może używać w jednostce skalowania, istnieje właściwość o nazwie possibleOutboundAddresses , która będzie je wyświetlać.

Usługa App Service ma wiele punktów końcowych, które są używane do zarządzania usługą. Te adresy są publikowane w osobnym dokumencie i znajdują się również w tagu AppServiceManagement usługi IP. Tag AppServiceManagement jest używany tylko w środowiskach App Service Environment, w których należy zezwolić na taki ruch. Adresy przychodzące usługi App Service są śledzone w tagu AppService usługi IP. Nie ma tagu usługi IP zawierającego adresy wychodzące używane przez usługę App Service.

Adres przypisany do aplikacji

Funkcja adresu przypisanego przez aplikację jest elementem odłączanym od możliwości protokołu SSL opartego na protokole IP. Dostęp do niego można uzyskać, konfigurując protokół SSL przy użyciu aplikacji. Tej funkcji można używać w przypadku wywołań SSL opartych na protokole IP. Możesz również użyć go, aby nadać aplikacji adres, który ma tylko.

Jeśli używasz adresu przypisanego przez aplikację, ruch nadal przechodzi przez te same role frontonu, które obsługują cały ruch przychodzący do jednostki skalowania usługi App Service. Jednak adres przypisany do aplikacji jest używany tylko przez twoją aplikację. Przypadki użycia tej funkcji:

• Obsługa potrzeb protokołu SSL opartego na protokole IP dla aplikacji.
• Ustaw dedykowany adres dla aplikacji, która nie jest udostępniana.

Aby dowiedzieć się, jak ustawić adres w aplikacji, zobacz Dodawanie certyfikatu TLS/SSL w usłudze aplikacja systemu Azure.

Ograniczenia dostępu

Ograniczenia dostępu umożliwiają filtrowanie żądań przychodzących . Akcja filtrowania odbywa się w rolach frontonu, które są nadrzędne z ról procesów roboczych, w których działają aplikacje. Ponieważ role frontonu są nadrzędne od pracowników, można traktować ograniczenia dostępu jako ochronę na poziomie sieci dla aplikacji. Aby uzyskać więcej informacji na temat ograniczeń dostępu, zobacz Omówienie ograniczeń dostępu.

Ta funkcja umożliwia utworzenie listy reguł zezwalania i odmowy, które są oceniane w kolejności priorytetów. Jest ona podobna do funkcji sieciowej grupy zabezpieczeń w sieci platformy Azure. Tej funkcji można używać w środowisku ASE lub w usłudze wielodostępnej. Jeśli używasz go ze środowiskaMI ASE z wewnętrznym modułem równoważenia obciążenia, możesz ograniczyć dostęp z bloków adresów prywatnych. Aby dowiedzieć się, jak włączyć tę funkcję, zobacz Konfigurowanie ograniczeń dostępu.

Uwaga

Na aplikację można skonfigurować maksymalnie 512 reguł ograniczeń dostępu.

Prywatny punkt końcowy

Prywatny punkt końcowy to interfejs sieciowy, który łączy Cię prywatnie i bezpiecznie z aplikacją internetową za pomocą łącza prywatnego platformy Azure. Prywatny punkt końcowy używa prywatnego adresu IP z sieci wirtualnej, efektywnie przenosząc aplikację internetową do sieci wirtualnej. Ta funkcja jest przeznaczona tylko dla przepływów przychodzących do aplikacji internetowej. Aby uzyskać więcej informacji, zobacz Using private endpoints for Azure Web App (Używanie prywatnych punktów końcowych dla aplikacji internetowej platformy Azure).

Niektóre przypadki użycia tej funkcji:

• Ogranicz dostęp do aplikacji z zasobów w sieci wirtualnej.
• Uwidaczniaj aplikację na prywatnym adresie IP w sieci wirtualnej.
• Ochrona aplikacji za pomocą zapory aplikacji internetowej.

Prywatne punkty końcowe uniemożliwiają eksfiltrację danych, ponieważ jedyną rzeczą, którą można uzyskać w prywatnym punkcie końcowym, jest aplikacja, z którą jest skonfigurowana.

Obwód zabezpieczeń sieci

Azure Network Security Perimeter (NSP) to usługa, która zapewnia bezpieczny obwód komunikacji usług PaaS (Platform as a Service). Te usługi PaaS mogą komunikować się ze sobą w obrębie obwodu, a także komunikować się z zasobami spoza obwodu przy użyciu publicznych reguł dostępu przychodzącego i wychodzącego.

Wymuszanie reguł NSP korzysta głównie z zabezpieczeń opartych na tożsamościach, które nie mogą być w pełni wymuszane w usługach platformy, takich jak App Services i Functions, które umożliwiają wdrażanie własnego kodu i używanie tożsamości do reprezentowania platformy. Jeśli musisz komunikować się z usługami PaaS, które są częścią NSP, musisz dodać integrację sieci wirtualnej z usługą App Service lub wystąpieniami usługi Functions i komunikować się z zasobami PaaS przy użyciu prywatnych punktów końcowych.

Połączenia hybrydowe

Połączenia hybrydowe usługi App Service umożliwiają aplikacjom wykonywanie wywołań wychodzących do określonych punktów końcowych TCP. Punkt końcowy może być lokalny, w sieci wirtualnej lub w dowolnym miejscu, który zezwala na ruch wychodzący do platformy Azure na porcie 443. Aby użyć tej funkcji, należy zainstalować agenta przekazywania o nazwie Menedżer połączeń hybrydowych na hoście systemu Windows Server 2012 lub nowszym. Menedżer połączeń hybrydowych musi mieć możliwość nawiązania połączenia z usługą Azure Relay na porcie 443. Możesz pobrać Menedżer połączeń hybrydowych z interfejsu użytkownika połączeń hybrydowych usługi App Service w portalu.

Połączenia hybrydowe usługi App Service są oparte na możliwości połączeń hybrydowych usługi Azure Relay. Usługa App Service używa wyspecjalizowanej formy funkcji, która obsługuje tylko wykonywanie wywołań wychodzących z aplikacji do hosta i portu TCP. Ten host i port muszą być rozpoznawane tylko na hoście, na którym zainstalowano Menedżer połączeń hybrydowych.

Gdy aplikacja w usłudze App Service wykonuje wyszukiwanie DNS na hoście i porcie zdefiniowanym w połączeniu hybrydowym, ruch automatycznie przekierowuje do przejścia przez połączenie hybrydowe i poza Menedżer połączeń hybrydowych. Aby dowiedzieć się więcej, zobacz Połączenia hybrydowe usługi App Service.

Ta funkcja jest często używana do:

• Dostęp do zasobów w sieciach prywatnych, które nie są połączone z platformą Azure za pomocą sieci VPN lub usługi ExpressRoute.
• Obsługa migracji aplikacji lokalnych do usługi App Service bez konieczności przenoszenia pomocniczych baz danych.
• Zapewnianie dostępu z ulepszonym zabezpieczeniami pojedynczego hosta i portu na połączenie hybrydowe. Większość funkcji sieciowych otwiera dostęp do sieci. W przypadku połączeń hybrydowych można uzyskać dostęp tylko do pojedynczego hosta i portu.
• Omówienie scenariuszy, które nie są objęte innymi metodami łączności wychodzącej.
• Programowanie w usłudze App Service umożliwia aplikacjom łatwe korzystanie z zasobów lokalnych.

Ponieważ ta funkcja umożliwia dostęp do zasobów lokalnych bez przychodzącej zapory, jest popularna wśród deweloperów. Inne funkcje sieciowe usługi App Service dla ruchu wychodzącego są powiązane z usługą Azure Virtual Network. Połączenia hybrydowe nie zależą od przechodzenia przez sieć wirtualną. Może służyć do szerszej gamy potrzeb sieciowych.

Połączenia hybrydowe usługi App Service nie wiedzą o tym, co robisz. Dzięki temu można go użyć do uzyskiwania dostępu do bazy danych, usługi internetowej lub dowolnego gniazda TCP w komputerze mainframe. Funkcja zasadniczo tuneluje pakiety TCP.

Połączenia hybrydowe są popularne na potrzeby programowania, ale są również używane w aplikacjach produkcyjnych. Doskonale nadaje się do uzyskiwania dostępu do usługi internetowej lub bazy danych, ale nie jest odpowiednia w sytuacjach obejmujących tworzenie wielu połączeń.

Integracja sieci wirtualnej

Integracja sieci wirtualnej usługi App Service umożliwia aplikacji wykonywanie żądań wychodzących do sieci wirtualnej platformy Azure.

Funkcja integracji sieci wirtualnej umożliwia umieszczenie zaplecza aplikacji w podsieci w sieci wirtualnej usługi Resource Manager. Sieć wirtualna musi znajdować się w tym samym regionie co aplikacja. Ta funkcja nie jest dostępna w środowisku App Service Environment, które znajduje się już w sieci wirtualnej. Przypadki użycia tej funkcji:

• Uzyskiwanie dostępu do zasobów w sieciach wirtualnych usługi Resource Manager w tym samym regionie.
• Uzyskiwanie dostępu do zasobów w równorzędnych sieciach wirtualnych, w tym połączeń między regionami.
• Uzyskaj dostęp do zasobów zabezpieczonych za pomocą punktów końcowych usługi.
• Uzyskaj dostęp do zasobów dostępnych w ramach połączeń usługi ExpressRoute lub sieci VPN.
• Uzyskiwanie dostępu do zasobów w sieciach prywatnych bez potrzeby i kosztów bramy sieci wirtualnej.
• Pomoc w zabezpieczaniu całego ruchu wychodzącego.
• Wymuś tunelowanie całego ruchu wychodzącego.

Aby dowiedzieć się więcej, zobacz Integracja sieci wirtualnej usługi App Service.

Integracja z siecią wirtualną wymaganą przez bramę

Integracja sieci wirtualnej wymagana przez bramę była pierwszą wersją integracji sieci wirtualnej w usłudze App Service. Funkcja działa przez połączenie hosta, na którym aplikacja jest uruchomiona z bramą sieci wirtualnej w sieci wirtualnej przy użyciu sieci VPN typu punkt-lokacja. Podczas konfigurowania tej funkcji aplikacja pobiera jeden z przypisanych adresów punkt-lokacja do każdego wystąpienia.

Wymagana integracja bramy umożliwia bezpośrednie łączenie się z siecią wirtualną w innym regionie bez komunikacji równorzędnej i nawiązywanie połączenia z klasyczną siecią wirtualną. Ta funkcja jest ograniczona do planów systemu Windows usługi App Service i nie działa z sieciami wirtualnymi połączonymi z usługą ExpressRoute. Zaleca się korzystanie z regionalnej integracji sieci wirtualnej. Aby uzyskać więcej informacji na temat tej funkcji, zobacz Integracja sieci wirtualnej usługi App Service.

Środowisko usługi App Service

Środowisko App Service Environment (ASE) to jednodostępne wdrożenie usługi aplikacja systemu Azure, która działa w sieci wirtualnej. Niektóre przypadki takie dla tej funkcji:

• Uzyskiwanie dostępu do zasobów w sieci wirtualnej.
• Uzyskiwanie dostępu do zasobów w usłudze ExpressRoute.
• Uwidaczniaj aplikacje przy użyciu adresu prywatnego w sieci wirtualnej.
• Uzyskiwanie dostępu do zasobów w punktach końcowych usługi.
• Uzyskiwanie dostępu do zasobów w prywatnych punktach końcowych.

W środowisku ASE nie trzeba używać integracji z siecią wirtualną, ponieważ środowisko ASE znajduje się już w sieci wirtualnej. Jeśli chcesz uzyskać dostęp do zasobów, takich jak SQL lub Azure Storage za pośrednictwem punktów końcowych usługi, włącz punkty końcowe usługi w podsieci środowiska ASE. Jeśli chcesz uzyskać dostęp do zasobów w sieci wirtualnej lub prywatnych punktach końcowych w sieci wirtualnej, nie musisz wykonywać żadnej dodatkowej konfiguracji. Jeśli chcesz uzyskać dostęp do zasobów w usłudze ExpressRoute, jesteś już w sieci wirtualnej i nie musisz konfigurować żadnych elementów w środowisku ASE ani aplikacjach w niej.

Ponieważ aplikacje w środowisku ASE z wewnętrznym modułem równoważenia obciążenia mogą być uwidocznione na prywatnym adresie IP, możesz łatwo dodać urządzenia zapory aplikacji internetowych, aby uwidocznić tylko aplikacje, które chcesz połączyć z Internetem i zapewnić bezpieczeństwo pozostałym. Ta funkcja może ułatwić tworzenie aplikacji wielowarstwowych.

Niektóre elementy nie są obecnie możliwe z usługi wielodostępnej, ale są możliwe z środowiska ASE. Oto kilka przykładów:

• Hostowanie aplikacji w usłudze z jedną dzierżawą.
• Skalowanie w górę do wielu wystąpień, niż jest to możliwe w usłudze wielodostępnej.
• Załaduj certyfikaty klienta prywatnego urzędu certyfikacji do użycia przez aplikacje z prywatnymi punktami końcowymi zabezpieczonymi przez urząd certyfikacji.
• Wymuś protokół TLS 1.2 we wszystkich aplikacjach hostowanych w systemie bez możliwości wyłączenia go na poziomie aplikacji.

Środowisko ASE zapewnia najlepszą historię na temat izolowanego i dedykowanego hostingu aplikacji, ale wiąże się z pewnymi wyzwaniami w zakresie zarządzania. Niektóre kwestie, które należy wziąć pod uwagę przed użyciem operacyjnego środowiska ASE:

• Środowisko ASE działa wewnątrz sieci wirtualnej, ale ma zależności poza siecią wirtualną. Te zależności muszą być dozwolone. Aby uzyskać więcej informacji, zobacz Zagadnienia dotyczące sieci dla środowiska App Service Environment.
• Usługa ASE nie jest skalowana natychmiast, podobnie jak usługa wielodostępna. Należy przewidzieć potrzeby skalowania, a nie reaktywne skalowanie.
• AsE ma wyższy koszt z góry. Aby maksymalnie wykorzystać swoje środowiska ASE, należy zaplanować umieszczenie wielu obciążeń w jednym ase, a nie używanie go do małych wysiłków.
• Aplikacje w środowisku ASE nie mogą selektywnie ograniczać dostępu do niektórych aplikacji w środowisku ASE, a nie innych.
• Środowiska ASE znajdują się w podsieci, a wszystkie reguły sieciowe mają zastosowanie do całego ruchu do i z tego środowiska ASE. Jeśli chcesz przypisać reguły ruchu przychodzącego tylko dla jednej aplikacji, użyj ograniczeń dostępu.

Łączenie funkcji

Funkcje znane dla usługi wielodostępnej mogą służyć razem do rozwiązywania bardziej skomplikowanych przypadków użycia. Dwa z bardziej typowych przypadków użycia są opisane tutaj, ale to tylko przykłady. Dzięki zrozumieniu różnych funkcji można spełnić niemal wszystkie potrzeby architektury systemu.

Umieszczanie aplikacji w sieci wirtualnej

Możesz się zastanawiać, jak umieścić aplikację w sieci wirtualnej. Jeśli aplikacja zostanie umieszczona w sieci wirtualnej, przychodzące i wychodzące punkty końcowe aplikacji znajdują się w sieci wirtualnej. Środowisko ASE to najlepszy sposób rozwiązania tego problemu. Jednak większość Twoich potrzeb można spełnić w ramach usługi wielodostępnej, łącząc funkcje. Na przykład można hostować aplikacje tylko intranetowe z prywatnymi adresami przychodzącymi i wychodzącymi, wykonując następujące czynności:

• Tworzenie bramy aplikacji z prywatnymi adresami przychodzącymi i wychodzącymi.
• Zabezpieczanie ruchu przychodzącego do aplikacji za pomocą punktów końcowych usługi.
• Dzięki funkcji integracji sieci wirtualnej zaplecze aplikacji znajduje się w sieci wirtualnej.

Ten styl wdrożenia nie zapewnia dedykowanego adresu dla ruchu wychodzącego do Internetu ani możliwości zablokowania całego ruchu wychodzącego z aplikacji. Da ci to wiele z tego, co byłoby tylko w przeciwnym razie dostać ze środowiska ASE.

Tworzenie aplikacji wielowarstwowych

Aplikacja wielowarstwowa to aplikacja, w której aplikacje zaplecza interfejsu API mogą być dostępne tylko z poziomu warstwy frontonu. Istnieją dwa sposoby tworzenia aplikacji wielowarstwowej. Obie metody zaczynają się od korzystania z integracji sieci wirtualnej, aby połączyć aplikację internetową frontonu z podsiecią w sieci wirtualnej. Dzięki temu aplikacja internetowa będzie mogła wykonywać wywołania w sieci wirtualnej. Po połączeniu aplikacji frontonu z siecią wirtualną należy zdecydować, jak zablokować dostęp do aplikacji interfejsu API. Masz następujące możliwości:

• Hostuj zarówno fronton, jak i aplikację interfejsu API w tym samym środowisku ASE z wewnętrznym modułem równoważenia obciążenia i uwidaczniaj aplikację frontonu w Internecie przy użyciu bramy aplikacji.
• Hostowanie frontonu w usłudze wielodostępnej i zapleczu w środowisku ASE z wewnętrznym modułem równoważenia obciążenia.
• Hostowanie zarówno frontonu, jak i aplikacji interfejsu API w usłudze wielodostępnej.

Jeśli hostujesz zarówno aplikację frontonu, jak i interfejsu API dla aplikacji wielowarstwowej, możesz:

• Uwidaczniaj aplikację interfejsu API przy użyciu prywatnych punktów końcowych w sieci wirtualnej:

  

• Użyj punktów końcowych usługi, aby upewnić się, że ruch przychodzący do aplikacji interfejsu API pochodzi tylko z podsieci używanej przez aplikację internetową frontonu:

  

Poniżej przedstawiono kilka zagadnień, które pomogą Ci zdecydować, która metoda ma być używana:

• W przypadku korzystania z punktów końcowych usługi wystarczy zabezpieczyć ruch do aplikacji interfejsu API do podsieci integracji. Punkty końcowe usługi pomagają zabezpieczyć aplikację interfejsu API, ale nadal można mieć eksfiltrację danych z aplikacji frontonu do innych aplikacji w usłudze App Service.
• W przypadku korzystania z prywatnych punktów końcowych masz dwie podsieci w grze, co zwiększa złożoność. Ponadto prywatny punkt końcowy jest zasobem najwyższego poziomu i dodaje obciążenie związane z zarządzaniem. Zaletą korzystania z prywatnych punktów końcowych jest to, że nie masz możliwości eksfiltracji danych.

Każda metoda będzie działać z wieloma frontonami. Na małą skalę punkty końcowe usługi są łatwiejsze do użycia, ponieważ wystarczy włączyć punkty końcowe usługi dla aplikacji interfejsu API w podsieci integracji frontonu. W miarę dodawania większej liczby aplikacji frontonu należy dostosować każdą aplikację interfejsu API w celu uwzględnienia punktów końcowych usługi z podsiecią integracji. W przypadku korzystania z prywatnych punktów końcowych jest większa złożoność, ale nie trzeba zmieniać żadnych zmian w aplikacjach interfejsu API po ustawieniu prywatnego punktu końcowego.

Aplikacje biznesowe

Aplikacje biznesowe (LOB) to aplikacje wewnętrzne, które nie są zwykle udostępniane w celu uzyskania dostępu z Internetu. Te aplikacje są wywoływane z wewnątrz sieci firmowych, gdzie dostęp można ściśle kontrolować. Jeśli używasz środowiska ASE z wewnętrznym modułem równoważenia obciążenia, łatwo jest hostować aplikacje biznesowe. Jeśli używasz usługi wielodostępnej, możesz użyć prywatnych punktów końcowych lub użyć punktów końcowych usługi w połączeniu z bramą aplikacji. Istnieją dwa powody używania bramy aplikacji z punktami końcowymi usługi zamiast używania prywatnych punktów końcowych:

• Potrzebujesz ochrony zapory aplikacji internetowych w aplikacjach biznesowych.
• Chcesz równoważyć obciążenie do wielu wystąpień aplikacji biznesowych.

Jeśli żadna z tych potrzeb nie ma zastosowania, lepiej jest korzystać z prywatnych punktów końcowych. Dzięki prywatnym punktom końcowym dostępnym w usłudze App Service możesz uwidaczniać aplikacje na prywatnych adresach w sieci wirtualnej. Prywatny punkt końcowy, który znajduje się w sieci wirtualnej, można uzyskać za pośrednictwem połączeń usługi ExpressRoute i sieci VPN.

Skonfigurowanie prywatnych punktów końcowych spowoduje uwidocznienie aplikacji na adresie prywatnym, ale należy skonfigurować usługę DNS, aby uzyskać dostęp do tego adresu ze środowiska lokalnego. Aby ta konfiguracja działała, należy przekazać prywatną strefę usługi Azure DNS zawierającą prywatne punkty końcowe do lokalnych serwerów DNS. Strefy prywatne usługi Azure DNS nie obsługują przekazywania stref, ale można obsługiwać przekazywanie stref przy użyciu prywatnego rozpoznawania nazw usługi Azure DNS.

Porty usługi App Service

Podczas skanowania usługi App Service znajdziesz kilka portów uwidocznionych na potrzeby połączeń przychodzących. Nie ma możliwości blokowania ani kontrolowania dostępu do tych portów w usłudze wielodostępnej. Oto lista uwidocznionych portów:

Używanie	Port lub porty
HTTP/HTTPS	80, 443
Zarządzanie	454, 455
FTP/FTPS	21, 990, 10001-10300
Zdalne debugowanie programu Visual Studio	4020, 4022, 4024
Usługa Web Deploy	8172
Użycie infrastruktury	7654, 1221