App Service funkcje sieciowe

Aplikacje można wdrażać na Azure App Service na wiele sposobów. Domyślnie aplikacje hostowane w App Service są dostępne bezpośrednio za pośrednictwem Internetu i mogą uzyskiwać dostęp tylko do punktów końcowych hostowanych przez Internet. Jednak w przypadku wielu aplikacji należy kontrolować ruch sieciowy przychodzący i wychodzący. Istnieje kilka funkcji w App Service, 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 Azure App Service:

• Usługa publiczna z wieloma dzierżawami hostuje plany App Service w jednostkach SKU cen bezpłatnych, udostępnionych, podstawowych, standardowych, Premium, PremiumV2 i PremiumV3.
• Jednodostępne App Service Environment (ASE) hostuje plany jednostki SKU izolowanej App Service 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 z wieloma dzierżawami App Service

Azure App Service jest systemem rozproszonym. 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 App Service istnieją w sieci wielodostępnej. Ponieważ w tej samej jednostce skalowania App Service istnieje wiele różnych klientów, nie można połączyć sieci 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ą być używane 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ą być używane 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

Oprócz zanotowania wyjątków 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 przypadki użycia dla ruchu przychodzącego sugerują, jak używać funkcji sieciowych App Service do rozwiązywania problemów z kontrolowaniem ruchu przechodzącego do aplikacji:

Przypadek użycia dla ruchu przychodzącego	Cecha
Obsługa potrzeb protokołu SSL opartego na protokole 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 Load Balancer środowiska ASE (ILB) — prywatne punkty końcowe środowiska ASE
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 Application Gateway z punktami końcowymi usługi
Ochrona aplikacji za pomocą zapory aplikacji internetowej (WAF)	Application Gateway i środowiska ASE z wewnętrznym modułem równoważenia obciążenia Application Gateway z prywatnymi punktami końcowymi Application Gateway z punktami końcowymi usługi Azure Front Door z ograniczeniami dostępu
Równoważenie obciążenia ruchu 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 App Service do rozwiązywania wymagań dotyczących dostępu wychodzącego dla aplikacji:

Przypadek użycia ruchu wychodzącego	Cecha
Uzyskiwanie dostępu do zasobów w sieci wirtualnej platformy Azure w tym samym regionie	Środowisko ASE integracji sieci wirtualnej
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ę integracji sieci wirtualnej ASE i komunikacji równorzędnej 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 z siecią wirtualną i tabele tras ASE

Domyślne zachowanie sieci

Azure App Service jednostki skalowania 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 ramach procesów roboczych z wieloma dzierżawami. Podstawowe i wyższe plany hostują obciążenia klientów dedykowane tylko do jednego planu App Service. Jeśli masz plan 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 App Service zostaną zreplikowane dla nowego procesu roboczego dla każdego wystąpienia w planie App Service.

Adresy wychodzące

Maszyny wirtualne procesu roboczego są podzielone w dużej części przez plany 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 otrzymujesz 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ą wyświetlane 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 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ć.

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

Adres przypisany do aplikacji

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

W przypadku korzystania z adresu przypisanego przez aplikację ruch nadal przechodzi przez te same role frontonu, które obsługują cały ruch przychodzący do jednostki skalowania App Service. Jednak adres przypisany do aplikacji jest używany tylko przez 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ępniona.

Aby dowiedzieć się, jak ustawić adres w aplikacji, zobacz Dodawanie certyfikatu TLS/SSL w Azure App Service.

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 procesu roboczego, 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 priorytetu. Jest ona podobna do funkcji sieciowej grupy zabezpieczeń w sieci platformy Azure. Tej funkcji można użyć w środowisku ASE lub w usłudze wielodostępnej. W przypadku korzystania z środowiska ASE z wewnętrznym modułem równoważenia obciążenia można ograniczyć dostęp z bloków prywatnych adresów. 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, skutecznie 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.
• Uwidocznij 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ą została skonfigurowana.

Połączenia hybrydowe

App Service połączenia hybrydowe umożliwiają aplikacjom wykonywanie wywołań wychodzących do określonych punktów końcowych PROTOKOŁU 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 przekaźnika o nazwie Menedżer połączeń hybrydowych na Windows Server 2012 lub nowszym hoście. Menedżer połączeń hybrydowych musi mieć możliwość nawiązania połączenia z usługą Azure Relay na porcie 443. Menedżer połączeń hybrydowych można pobrać z interfejsu użytkownika połączeń hybrydowych App Service w portalu.

App Service połączenia hybrydowe są oparte na możliwości połączeń hybrydowych usługi Azure Relay. 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 App Service, wykonuje wyszukiwanie DNS na hoście i porcie zdefiniowanym w połączeniu hybrydowym, ruch automatycznie przekierowuje, aby przejść przez połączenie hybrydowe i z Menedżer połączeń hybrydowych. Aby dowiedzieć się więcej, zobacz App Service połączenia hybrydowe.

Ta funkcja jest często używana do:

• Uzyskiwanie dostępu do zasobów w sieciach prywatnych, które nie są połączone z platformą Azure za pomocą sieci VPN ani usługi ExpressRoute.
• Obsługa migracji aplikacji lokalnych do App Service bez konieczności przenoszenia pomocniczych baz danych.
• Zapewnianie dostępu z ulepszonymi 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 nawiązać połączenie tylko z jednym hostem i portem.
• Omówienie scenariuszy, które nie są objęte innymi metodami łączności wychodzącej.
• Tworzenie aplikacji w App Service w sposób umożliwiający aplikacjom łatwe korzystanie z zasobów lokalnych.

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

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

Połączenia hybrydowe są popularne do 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 to odpowiednie w sytuacjach, które obejmują tworzenie wielu połączeń.

Integracja sieci wirtualnej

App Service integracja sieci wirtualnej umożliwia aplikacji wykonywanie żądań wychodzących w sieci wirtualnej platformy Azure.

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

• Dostęp do zasobów w sieciach wirtualnych 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.
• Uzyskiwanie dostępu do zasobów zabezpieczonych punktami końcowymi usługi.
• Uzyskiwanie dostępu do zasobów dostępnych za pośrednictwem połączeń usługi ExpressRoute lub sieci VPN.
• Dostęp do zasobów w sieciach prywatnych bez potrzeby i kosztów bramy Virtual Network.
• Pomoc w zabezpieczaniu całego ruchu wychodzącego.
• Wymuś tunelowanie całego ruchu wychodzącego.

Aby dowiedzieć się więcej, zobacz App Service integracja z siecią wirtualną.

Integracja z siecią wirtualną wymaganą przez bramę

Integracja z siecią wirtualną wymaganą przez bramę była pierwszą wersją integracji sieci wirtualnej w App Service. Ta funkcja działa przez połączenie hosta, na którym aplikacja jest uruchomiona z bramą Virtual Network w sieci wirtualnej przy użyciu sieci VPN typu punkt-lokacja. Po skonfigurowaniu tej funkcji aplikacja otrzymuje jeden z przypisanych do punktu do lokacji adresów przypisanych 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 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 App Service integracja sieci wirtualnej.

Środowisko usługi App Service

App Service Environment (ASE) to jednodostępne wdrożenie Azure App Service, które działa w sieci wirtualnej. Niektóre przypadki takie jak w przypadku 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 prywatnego adresu 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 jest 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 w aplikacjach w nim.

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 poziomu usługi wielodostępnej, ale są możliwe z poziomu ś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ę wokół 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 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 jak najlepiej wykorzystać swoje środowiska ASE, należy zaplanować umieszczenie wielu obciążeń w jednym ase, zamiast używać 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.
• AsE znajduje 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, które są przeznaczone dla usługi wielodostępnej, mogą być używane razem do rozwiązywania bardziej skomplikowanych przypadków użycia. Dwa z bardziej typowych przypadków użycia opisano tutaj, ale to tylko przykłady. Dzięki zrozumieniu, co robią różne funkcje, 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. Można na przykład hostować aplikacje tylko w intranecie 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 z siecią wirtualną 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 w przeciwnym razie dostaniesz 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 z siecią wirtualną w celu połączenia aplikacji internetowej 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. Możesz:

• 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 uwidacznia 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órej metody użyć:

• 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 z tych metod 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 kolejnych 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 istnieje większa złożoność, ale nie trzeba nic zmieniać w aplikacjach interfejsu API po ustawieniu prywatnego punktu końcowego.

Aplikacje biznesowe

Aplikacje biznesowe (LOB) to aplikacje wewnętrzne, które zwykle nie są uwidacznione w celu uzyskania dostępu z Internetu. Te aplikacje są wywoływane z sieci firmowych, w których 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 z wieloma dzierżawami, 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:

• Potrzebna jest ochrona 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 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 App Service

W przypadku skanowania App Service znajdziesz kilka portów uwidocznionych dla 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:

Zastosowanie	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
Korzystanie z infrastruktury	7654, 1221