Ruch przychodzący z Internetu: udostępnij swoją aplikację w Internecie

Ten artykuł pomaga wybrać odpowiednią usługę Azure, aby aplikacja mogła być osiągalna z Internetu. Porównuje publiczne adresy IP, Azure Load Balancer, Application Gateway, Azure Front Door i Azure Traffic Manager. Wybierz opcję zgodną z wymaganiami dotyczącymi protokołu, skalowania i zabezpieczeń obciążenia.

Co opisano w tym artykule

Każde obciążenie Azure, które obsługuje użytkowników zewnętrznych, wymaga ścieżki ruchu przychodzącego: sposób bezpiecznego i niezawodnego dotarcia do aplikacji przez internet. Wybranie niewłaściwej usługi ingress prowadzi do nadmiarowej alokacji zasobów, luk w zabezpieczeniach lub niepotrzebnej złożoności. Ten artykuł ułatwia ocenę siedmiu usług Azure, które akceptują połączenia przychodzące od użytkowników zewnętrznych i kierują te połączenia do zasobów zaplecza wewnątrz sieci wirtualnej. Możesz wybrać kombinację zgodną z protokołem, skalowaniem, lokalizacją geograficzną i stanem zabezpieczeń.

Note

Ten artykuł koncentruje się na tym, jak ruch przechodzi do sieci Azure z Internetu. Aby dowiedzieć się, jak równoważyć i dostarczać ten ruch w zapleczach aplikacji (w tym szczegółowe porównania Azure Load Balancer, usługi Application Gateway i Azure Front Door), zobacz Dostarczanie aplikacji i wydajność.

Kto potrzebuje tego artykułu

Przeczytaj ten artykuł, jeśli ma zastosowanie co najmniej jeden z następujących warunków:

  • Aplikacja musi akceptować połączenia przychodzące od użytkowników lub systemów w Internecie.
  • Musisz wybrać publiczny adres IP, Load Balancer, usługę Application Gateway, usługę Front Door lub usługę Traffic Manager na podstawie protokołu i zakresu.
  • Należy zaprojektować bezpieczny publiczny punkt wejścia dla obciążeń internetowych, interfejsów API lub TCP/UDP.
  • Należy połączyć udostępnienie do internetu z mechanizmem WAF, ochroną przed atakami DDoS, terminacją TLS lub regionalną i globalną dystrybucją ruchu.

Tip

Podążasz ścieżką scenariusza? Wybierz swój scenariusz w górnej części strony, aby uzyskać dostosowane wskazówki. Poniższe podstawowe wskazówki dotyczą wszystkich czytelników.

Fokus lift-and-shift: Zmigrowana aplikacja musi być osiągalna z Internetu. Oceń, czy potrzebujesz usługi Application Gateway, usługi Front Door, czy prostszego podejścia do publicznego adresu IP. Wiele obciążeń metodą „lift-and-shift” ma charakter wyłącznie wewnętrzny, więc możesz całkowicie pominąć ten artykuł, jeśli zmigrowane aplikacje nie są używane przez użytkowników zewnętrznych.

Przeczytaj ten artykuł, jeśli:

  • Migrują lokalną aplikację internetową do Azure i muszą zdecydować, jak udostępnić ją publicznie.
  • Należy ocenić, czy ruch przychodzący z Internetu jest wymagany w ogóle dla zmigrowanych obciążeń.
  • Chcesz zrozumieć najprostszą, gotową do użycia w środowisku produkcyjnym opcję ingress dla zmigrowanej aplikacji.

Fokus modernizacji: Wzorce ruchu skierowane do klientów określają zewnętrzny kształt architektury. Usługa Front Door obsługuje aplikacje internetowe, usługa Traffic Manager obsługuje aplikacje mobilne i interfejsy API. Zmodernizowane obciążenia PaaS (App Service, AKS) wymagają jasno zdefiniowanej ścieżki ruchu przychodzącego, która integruje się z modelem bezpieczeństwa hub-and-spoke.

Przeczytaj ten artykuł, jeśli:

  • Wdróż aplikację publiczną, do którego użytkownicy zewnętrzni uzyskują dostęp za pośrednictwem Internetu.
  • Należy wybrać między Azure Front Door dla aplikacji internetowych a usługą Traffic Manager dla obciążeń mobilnych lub interfejsów API.
  • Chcesz dowiedzieć się, jak ruch przychodzący integruje się z zaporą centrum jako obiekt docelowy DNAT.
  • Należy chronić punkty końcowe dostępne z Internetu za pomocą zapory aplikacji internetowej (WAF) lub ochrony przed atakami DDoS.

Fokus między chmurami: Uwzględnianie ruchu przychodzącego z Internetu tylko wtedy, gdy zmigrowana aplikacja jest dostępna publicznie. Wiele aplikacji wielochmurowych działa wyłącznie wewnętrznie, komunikując się między chmurami za pośrednictwem prywatnych ścieżek przesyłowych. Jeśli obciążenie jest dostępne publicznie (na przykład aplikacja internetowa dostępna dla klientów zmigrowana z innej chmury), potrzebna jest ścieżka ruchu przychodzącego w Azure.

Przeczytaj ten artykuł, jeśli:

  • Migruje aplikację publiczną z platformy AWS lub Google Cloud do usługi Azure.
  • Potrzebny jest Application Gateway z usługą WAF w sieci wirtualnej typu spoke dla zmigrowanego obciążenia.
  • Chcesz uniknąć bezpośredniego przypisania publicznego adresu IP do maszyn wirtualnych podczas migracji między chmurami.

Usługi i funkcje platformy Azure

Azure oferuje kilka usług do obsługi ruchu przychodzącego z Internetu. Każda usługa działa w innej warstwie stosu sieci i obsługuje inny przypadek użycia.

Service Warstwa Scope Co zapewnia Kiedy należy go używać
Publiczny adres IP (jednostka SKU w warstwie Standardowa) 3 Regionalne Bezpośrednio przypisany routowalny adres IPv4 lub IPv6. Domyślnie z nadmiarowością strefową. Proste scenariusze o niskim natężeniu ruchu. Niezalecane w środowisku produkcyjnym bez modułu równoważenia obciążenia.
Azure Load Balancer (Standardowa, publiczna) 4 (TCP/UDP) Regionalne Rozdziela przychodzący ruch TCP/UDP pomiędzy maszynami wirtualnymi zaplecza. Fronton strefowo nadmiarowy. Sondy kondycji usuwają wystąpienia w złej kondycji. Obciążenia inne niż HTTP/S wymagające wysokiej dostępności. Serwery gier, punkty końcowe IoT lub inne usługi TCP/UDP.
Azure Load Balancer (Standard, wewnętrzna) 4 (TCP/UDP) Regionalne Równoważenie obciążenia warstwy 4 w sieci wirtualnej. Brak publicznego adresu IP. Kieruje ruchem między warstwami wewnętrznymi. Aplikacje wielowarstwowe, w których publiczny fronton dystrybuuje do maszyn wirtualnych zaplecza. Ruch wschód-zachód w architekturze piasta-szprychy. Nie bezpośrednio połączone z Internetem, ale często sparowane z publiczną usługą ruchu przychodzącego.
Azure Application Gateway 7 (HTTP/S) Regionalne Równoważenie obciążenia HTTP/S z routingiem opartym na adresach URL, terminacją SSL/TLS, trwałością sesji i automatycznym skalowaniem. Aplikacje HTTP/S z jednym regionem wymagające routingu opartego na ścieżkach, koligacji opartej na plikach cookie lub odciążania protokołu SSL.
Application Gateway + WAF 7 (HTTP/S) Regionalne Brama aplikacji z zaporą aplikacji internetowych. Chroni przed 10 najpoważniejszymi zagrożeniami OWASP za pomocą domyślnego zestawu reguł (DRS), w tym reguł Microsoft Threat Intelligence. Dostępne publicznie aplikacje internetowe z funkcjami równoważenia obciążenia warstwy 7 i ochrony WAF w jednym regionie.
Azure Front Door 7 (HTTP/S) Global Globalny moduł równoważenia obciążenia HTTP/S ze zintegrowanymi funkcjami CDN, WAF i routingu ruchu. Kończy połączenia TCP/TLS w brzegowych punktach PoP blisko użytkowników, z wykorzystaniem akceleracji Split TCP. Aplikacje z wieloma regionami z globalną bazą użytkowników. Obciążenia robocze wymagające buforowania w CDN, globalnego WAF i automatycznego przełączania awaryjnego.
Azure Traffic Manager DNS Global Routing ruchu oparty na systemie DNS. Zwraca wartość CNAME do najbliższego lub najzdrowszego regionalnego punktu końcowego. Klienci łączą się bezpośrednio. Usługa Traffic Manager nigdy nie widzi ruchu aplikacji. Wieloregionowe przełączanie awaryjne na poziomie DNS. Protokoły inne niż HTTP/S, w których usługa Front Door nie ma zastosowania. Routing według lokalizacji geograficznej, wydajności lub priorytetu.

Note

Publiczne adresy IP w warstwie Basic SKU zostaną wycofane (wrzesień 2025 r.). Istniejące adresy IP w warstwie Basic pozostają aktywne, ale nie są objęte pomocą techniczną ani umową SLA. Używaj jednostki SKU w warstwie Standard we wszystkich nowych wdrożeniach.

Jak działa każda usługa

Zrozumienie wewnętrznej architektury każdej usługi pomaga przewidywać wydajność, rozwiązywać problemy i planować ustalanie rozmiaru podsieci.

Publiczny adres IP

Publiczny adres IP w warstwie Standard to zasób definiowany programowo, który przypisuje publicznie routowalny adres IPv4 lub IPv6 bezpośrednio do interfejsu sieciowego, interfejsu frontonu modułu równoważenia obciążenia lub bramy. Adres jest domyślnie nadmiarowy między strefami w obsługiwanych regionach, co oznacza, że platforma obsługuje automatyczne przełączanie awaryjne między strefami dostępności bez konieczności wprowadzania przez Ciebie jakichkolwiek zmian. Publiczne adresy IP nie mają przetwarzania ruchu. Pakiety przepływają bezpośrednio do podłączonego zasobu, bez kontroli stanu ani logiki rozdzielania.

Azure Load Balancer (Standardowa, publiczna)

usługa Load Balancer w warstwie Standardowa używa algorytmu dystrybucji opartego na haszowaniu dla przepływów 5-elementowych (źródłowy adres IP, port źródłowy, docelowy adres IP, port docelowy, protokół). Działa całkowicie w ścieżce danych w warstwie 4, więc nigdy nie przerywa połączeń ani nie sprawdza ładunków. Testy kondycji (TCP, HTTP lub HTTPS) stale sprawdzają wystąpienia zaplecza i wyłączają niezdrowe wystąpienia z rotacji w ciągu kilku sekund. Load Balancer skaluje się automatycznie. Nie ma planowania pojemności ani określania rozmiaru wystąpienia.

Azure Load Balancer (Standard, wewnętrzna)

Wewnętrzny moduł równoważenia obciążenia działa tak samo jak jego publiczny odpowiednik, ale używa prywatnego adresu IP interfejsu frontonu z podsieci sieci wirtualnej. Dystrybuuje ruch między warstwami wewnętrznymi, takimi jak warstwa internetowa wysyłająca ruch do klastra interfejsu API warstwy środkowej. Ponieważ nie ma publicznego adresu IP, jest niewidoczny dla Internetu. Połącz ją z publiczną usługą wejściową, taką jak Front Door, Application Gateway lub publiczny moduł równoważenia obciążenia, która obsługuje ruch na granicy zewnętrznej.

Azure Application Gateway

Application Gateway to dedykowane urządzenie wirtualne wdrożone w podsieci sieci wirtualnej. Terminuje połączenia TLS na bramie, sprawdza nagłówki HTTP i adresy URL oraz kieruje żądania do pul zaplecza na podstawie reguł ścieżek, nagłówków Host lub niestandardowych sond kondycji. Jednostka SKU v2 obsługuje automatyczne skalowanie (od 0 do 125 instancji) i nadmiarowość strefową. Ponieważ jest ona rezydentem sieci wirtualnej, może ona uzyskiwać dostęp do prywatnych zapleczy bez konieczności używania publicznych adresów IP na tych zapleczach.

Brama aplikacyjna z zaporą WAF

Po dodaniu warstwy WAF włączasz podstawowy zestaw reguł OWASP oraz reguły usługi Microsoft Threat Intelligence bezpośrednio w potoku przetwarzania usługi Application Gateway. Każde żądanie HTTP przechodzi przez moduł WAF, zanim dotrze do reguł routingu. WAF obsługuje zasady dla poszczególnych witryn, dzięki czemu można stosować różne konfiguracje reguł dla różnych kombinacji odbiornika lub hosta w obrębie tej samej bramy. WAF działa w trybie wykrywania (tylko rejestrowanie) lub zapobiegania (blokowanie i rejestrowanie).

Azure Front Door

Usługa Front Door działa w oparciu o globalną sieć brzegową firmy Microsoft (190+ punktów obecności). Gdy użytkownik nawiązuje połączenie, uzgadnianie połączenia TCP i negocjacja TLS odbywają się w najbliższym punkcie obecności z wykorzystaniem mechanizmu Split TCP. Punkt obecności utrzymuje stale aktywne połączenie z serwerem źródłowym, dzięki czemu eliminuje opóźnienie zimnego startu, którego doświadczyliby użytkownicy, łącząc się bezpośrednio. Usługa Front Door wykonuje trasowanie na warstwie 7, inspekcję WAF, buforowanie i kompresję na brzegu sieci przed przekazaniem żądania do najbliższego sprawnego źródła za pośrednictwem sieci szkieletowej firmy Microsoft.

Azure Traffic Manager

Traffic Manager to usługa oparta na systemie DNS bez udziału ścieżki danych. Gdy klient rozwiązuje nazwę hosta usługi Traffic Manager, zwracany jest rekord CNAME wskazujący najzdrowszy lub najbliższy punkt końcowy w zależności od wybranej metody routingu (priorytetowej, ważonej, wydajnościowej, geograficznej, wielowartościowej lub podsieci). Usługa Traffic Manager stale sonduje kondycję punktu końcowego i aktualizuje odpowiednio odpowiedzi DNS. Ponieważ nigdy nie widzi ruchu aplikacji, działa z dowolnym protokołem: HTTP, TCP, UDP lub zastrzeżonymi protokołami.

Porównanie modelu kosztów

Każda usługa wejściowa podlega innemu modelowi rozliczeń. Użyj tej tabeli, aby oszacować koszty na oczekiwanym woluminie ruchu.

Service Model rozliczania Kluczowe czynniki kosztów Poziom bezpłatny lub funkcje wliczone
Publiczny adres IP Na godzinę (załączone) + za GB ruchu wychodzącego Liczba przypisanych godzin; opłaty za ruch wychodzący Pierwsze 100 GB ruchu wychodzącego na miesiąc bezpłatnie (globalny)
usługa Load Balancer w warstwie Standardowa Za godzinę za regułę + za przetworzony GB Liczba reguł równoważenia obciążenia; dane przetwarzane przez moduł LB Żadne
Application Gateway Za godzinę za instancję + zużyte jednostki pojemności Godziny wystąpienia; jednostki mocy obliczeniowej, połączenia i przepływności Żadne
Application Gateway + WAF Za godzinę za instancję (cennik warstwy WAF) + jednostki wydajności Taki sam jak Application Gateway, ale z godzinową stawką dla warstwy WAF Żadne
Azure Front Door Za żądanie + transfer za GB + żądania WAF Kierowanie żądań, transfer danych z sieci brzegowej do klienta, ocena reguł zapory aplikacji internetowej Poziom Standard obejmuje podstawowe funkcje routingu
Azure Traffic Manager Za milion zapytań DNS + za punkt końcowy kontroli kondycji Wolumin zapytań DNS; liczba monitorowanych punktów końcowych Pierwsze 1 miliard zapytań ma warstwowe ceny

Tip

W przypadku obciążeń o niskim natężeniu ruchu (poniżej 1 miliona żądań miesięcznie) model usługi Front Door na żądanie może być bardziej ekonomiczny niż koszt stały usługi Application Gateway na godzinę. Wraz ze wzrostem ruchu modele na godzinę stają się bardziej przewidywalne. Uruchom Kalkulator cen platformy Azure dla oczekiwanej przepustowości, aby porównać.

Jak wybrać

Skorzystaj z poniższych tabel decyzyjnych, aby wybrać odpowiednią usługę wejściową dla swojego obciążenia roboczego. Zacznij od tabeli decyzji wysokiego poziomu, a następnie użyj szczegółowego porównania, aby potwierdzić wybór.

Application Gateway vs. Front Door vs. Traffic Manager

Ta tabela ułatwia wybór spośród trzech najczęściej używanych usług ruchu przychodzącego HTTP i HTTPS.

Twoja potrzeba Zalecana usługa Dlaczego
Ruch HTTP/S, pojedynczy region, ochrona zapory aplikacji internetowej Brama aplikacyjna z zaporą WAF Regionalna usługa warstwy 7 z routingiem opartym na ścieżce i WAF. Działa wewnątrz sieci wirtualnej.
Ruch HTTP/S, wiele regionów, użytkownicy globalni, CDN + WAF Azure Front Door Globalna usługa warstwy 7, terminowana w brzegowych punktach PoP. Wbudowana usługa CDN, zapora aplikacji webowych i automatyczne przełączanie awaryjne.
Routing na wielu regionach tylko dla protokołów innych niż HTTP/S lub routingu na poziomie DNS Azure Traffic Manager Routing oparty na systemie DNS, który działa z dowolnym protokołem. Brak zakończenia połączenia.
Wieloregionowe HTTP/S z regionalnymi wymaganiami dotyczącymi przetwarzania powiązanego z siecią wirtualną VNet Brama aplikacji + Menedżer ruchu Odpowiednie dla obciążeń wymagających ścisłej integracji z siecią VNet lub regionalnej suwerenności danych z regionalną inspekcją WAF. W przypadku większości scenariuszy HTTP/S w wielu regionach preferuj usługę Front Door.

Tip

W przypadku większości wieloregionowych obciążeń HTTP i HTTPS usługa Front Door jest preferowanym wyborem niż połączenie usług Application Gateway i Traffic Manager. Usługa Front Door zapewnia wbudowaną usługę WAF, sieć CDN i automatyczne przełączanie awaryjne bez konieczności zarządzania wieloma regionalnymi wystąpieniami usługi Application Gateway. Połączenie usług Application Gateway i Traffic Manager nadal jest odpowiednim rozwiązaniem w przypadku obciążeń roboczych wymagających regionalnego przetwarzania ograniczonego do sieci wirtualnej (VNet), źródeł Private Link dostępnych wyłącznie w obrębie sieci wirtualnej lub wymogów regulacyjnych nakazujących suwerenność danych w danym regionie.

Porównanie usług Ingress

Użyj tego szczegółowego porównania, aby zrozumieć możliwości każdej usługi.

Service Warstwa Globalny lub regionalny Kończenie połączenia WAF dostępny Sondy kondycji Najlepsze dla
Publiczny adres IP 3 Regionalne Nie (bezpośrednio do maszyny wirtualnej) No No Obciążenia deweloperskie/testowe z pojedynczą instancją, niewymagające wysokiej dostępności
usługa Load Balancer w warstwie Standardowa (publiczne) 4 Regionalne Nie (przepuszczanie) No Tak (TCP, HTTP, HTTPS) Obciążenia inne niż HTTP: gry, IoT, niestandardowe protokoły TCP/UDP
usługa Load Balancer w warstwie Standardowa (wewnętrzny) 4 Regionalne Nie (przekazywanie dalej) No Tak (TCP, HTTP, HTTPS) Warstwa wewnętrzna za publiczną usługą wejściową
Application Gateway 7 Regionalne Tak (zakończenie protokołu TLS) Nie (dodaj warstwę WAF) Tak (niestandardowy protokół HTTP/S) Jednoregionowy protokół HTTP/S z routingiem opartym na ścieżkach
Application Gateway + WAF 7 Regionalne Tak (zakończenie protokołu TLS) Tak (zestaw reguł DRS) Tak (niestandardowy protokół HTTP/S) Jednoregionowe aplikacje internetowe wymagające zapory WAF
Azure Front Door 7 Global Tak (z podziałem TCP w PoP) Tak (wbudowane) Tak (HTTP/S) Wieloregionowy HTTP/S z globalną akceleracją
Azure Traffic Manager DNS Global Nie (tylko DNS) No Tak (HTTP/S, TCP) Wieloregionowe przełączanie awaryjne na poziomie DNS, dla dowolnego protokołu

Internetowa architektura wejściowa

Na poniższym diagramie przedstawiono typowe wzorce łańcucha usług dla ruchu przychodzącego do obciążeń Azure. Każdy wzorzec łączy usługi warstwy 7 i warstwy 4 w celu dopasowania do określonego protokołu, zakresu regionalnego i stanu zabezpieczeń.

Diagram przedstawiający cztery typowe wzorce internetowego ruchu przychodzącego w usłudze Azure: globalny ruch HTTP/S przez Front Door z usługą WAF do Application Gateway i dalej do App Service; wieloregionowy ruch inny niż HTTP przez routing DNS usługi Traffic Manager do usługa Load Balancer w warstwie Standardowa i dalej do VM Scale Sets; regionalny ruch HTTP/S przez Application Gateway z usługą WAF do VM Scale Sets; oraz źródła prywatne przez Front Door Premium z użyciem Private Link i Internal Load Balancer do backendowych maszyn wirtualnych.

Typowe wzorce ruchu przychodzącego

Poniższe wzorce łączą wiele usług, tworząc kompletną architekturę wejściową. Wybierz wzorzec zgodny z wymaganiami protokołu, zakresem regionalnym i stanem zabezpieczeń.

Wzorzec 1: Globalna aplikacja internetowa z zabezpieczeniami brzegowymi

Usługi: Front Door → Application Gateway (z WAF) → maszyny wirtualne/kontenery

Scenariusz: Aplikacja SaaS obsługująca klientów w Ameryce Północnej, Europie i Azji wymaga globalnego przyspieszenia, ochrony przed atakami DDoS na brzegu i routingu opartego na ścieżkach regionalnych do różnych mikrousług.

Usługa Front Door obsługuje zakończenie połączeń użytkowników w najbliższym punkcie obecności (PoP), stosuje globalne reguły WAF i buforuje statyczną zawartość. Ruch jest trasowany przez sieć szkieletową Microsoft do regionalnej usługi Application Gateway, która wykonuje routing oparty na adresach URL (na przykład /api/* do puli interfejsów API, /static/* do zaplecza magazynowego). Ten schemat zapewnia dwie warstwy inspekcji WAF: jedną na warstwie brzegowej i jedną w warstwie regionalnej.

Wzorzec 2: Wiele regionów spoza protokołu HTTP z trybem failover DNS

Usługi: Traffic Manager → usługa Load Balancer w warstwie Standardowa (na region) → maszyny wirtualne

Scenariusz: Firma zajmująca się grami działa na dedykowanych serwerach gier na porcie UDP 7777 w trzech regionach. Gracze łączą się automatycznie z najbliższym regionem dobrej kondycji.

Usługa Traffic Manager używa metody routingu wydajnościowego, aby zwrócić rekord DNS dla regionu o najniższym opóźnieniu. Każdy region ma moduł usługa Load Balancer w warstwie Standardowa, który rozdziela ruch UDP w obrębie zestawu skalowania maszyn wirtualnych. Jeśli sondy kondycji wykryją awarię regionalną, usługa Traffic Manager aktualizuje system DNS w celu kierowania graczy do następnego najbliższego regionu.

Wzorzec 3: Prosta regionalna aplikacja internetowa z WAF

Usługi: Application Gateway (z usługą WAF) → maszyny wirtualne

Scenariusz: Wewnętrzna aplikacja biznesowa jest widoczna dla partnerów zewnętrznych. Pojedynczy region, umiarkowany ruch, wymaga ochrony OWASP i zakończenia protokołu TLS.

Usługa Application Gateway zapewnia routing oparty na ścieżkach, skojarzenie sesji oparte na plikach cookie oraz ochronę WAF, a wszystko to w ramach jednego zasobu regionalnego w sieci wirtualnej. Ten wzorzec pozwala uniknąć złożoności i kosztów usługi globalnej, gdy ruch jest skoncentrowany geograficznie.

Wzorzec 4: Usługa Front Door z zablokowanymi prywatnymi źródłami

Usługi: Front Door Premium → Private Link → wewnętrzny moduł równoważenia obciążenia → maszyny wirtualne

Scenariusz: Aplikacja usług finansowych z rygorystycznymi wymaganiami, zgodnie z którymi źródło nie może być publicznie dostępne pod adresem IP. Cały ruch musi przechodzić przez sieć szkieletową Microsoft bez publicznych przeskoków internetowych.

Usługa Front Door Premium łączy się ze źródłem za pośrednictwem punktu końcowego Private Link. Zaplecze pochodzenia nie ma publicznego adresu IP i nie ma ekspozycji na Internet. Ten wzorzec łączy bezpieczeństwo w pełni prywatnego źródła z korzyściami w zakresie wydajności, jakie zapewnia globalna sieć brzegowa usługi Front Door.

Ruch wejściowy w wielu regionach za pomocą usługi Front Door

Poniższy diagram przedstawia usługę Azure Front Door jako globalny punkt wejścia, kierujący użytkowników do najbliższego sprawnego regionalnego źródła pochodzenia z automatycznym przełączaniem awaryjnym.

Zrzut ekranu przedstawiający usługę Azure Front Door z brzegowymi punktami obecności (PoP) w Europie, obu Amerykach oraz regionie Azji i Pacyfiku, kierującą ruch do regionalnych źródeł (Application Gateway z usługą WAF lub usługa Load Balancer w warstwie Standardowa) w wielu regionach platformy Azure, z przerywanymi ścieżkami przełączania awaryjnego między regionami.

Prerequisites

Przed udostępnieniem aplikacji w Internecie upewnij się, że masz wdrożone następujące elementy:

  • Wdrożono sieć wirtualną: Zasoby zaplecza muszą działać w sieci wirtualnej platformy Azure z podsieciami o odpowiednim rozmiarze. Zobacz Projektowanie sieci wirtualnej i podsieci , aby uzyskać wskazówki dotyczące planowania podsieci.
  • Uruchomione obciążenie: Potrzebujesz co najmniej jednego zasobu zaplecza (maszyny wirtualnej, kontenera lub usługi platformy) gotowego do obsługi ruchu.
  • Nazwa DNS: Publiczna nazwa DNS używana przez użytkowników zewnętrznych do uzyskiwania dostępu do aplikacji. Możesz użyć Azure DNS lub innego dostawcy DNS.
  • Planowanie podsieci dla usług przychodzących: Application Gateway wymaga dedykowanej podsieci (w środowisku produkcyjnym zalecana jest co najmniej /24). Wystąpienia zaplecza usługi usługa Load Balancer w warstwie Standardowa mogą współużytkować podsieć z innymi zasobami.

Uwagi dotyczące projektowania

Oceń, czy ruch przychodzący z Internetu jest wymagany dla podniesionych obciążeń. Wiele aplikacji lokalnych jest tylko wewnętrznych i pozostają w ten sposób po migracji. Jeśli ruch przychodzący jest potrzebny, zachowaj prostą architekturę:

  • Application Gateway z funkcją WAF zapewnia obsługę ruchu przychodzącego warstwy 7 w pojedynczym regionie, z terminacją TLS i ochroną opartą na regułach OWASP. Takie podejście jest najczęstsze w przypadku zmigrowanych aplikacji internetowych, które wcześniej działały za lokalnym serwerem proxy odwrotnym.
  • Publiczny adres IP z NSG (sieciową grupą zabezpieczeń) jest akceptowalny w przypadku obciążeń roboczych innych niż HTTP o niewielkim natężeniu ruchu (na przykład usługa TCP, z którą łączą się partnerzy). Ogranicz NSG do znanych źródłowych adresów IP.
  • Unikaj przypisywania publicznych adresów IP bezpośrednio do maszyn wirtualnych. Umieść moduł równoważenia obciążenia lub usługę Application Gateway między Internetem a zapleczem.

Jeśli zniesione aplikacje nie obsługują użytkowników zewnętrznych, pomiń ten artykuł i przejdź do pozycji Wychodzący dostęp do Internetu.

Zmodernizowane obciążenia robocze mają różne wzorce ruchu wejściowego w zależności od typu aplikacji:

  • Azure Front Door dla aplikacji internetowych przeznaczonych dla klientów (na przykład ContosoBiz). Usługa Front Door zapewnia globalną akcelerację, wbudowaną usługę WAF, buforowanie w usłudze CDN oraz automatyczne przełączanie awaryjne między regionami. Użyj routingu ważonego dla wdrożeń aktywnych-aktywnych.
  • Azure Traffic Manager dla aplikacji mobilnych i interfejsów API (na przykład ContosoCare). Usługa Traffic Manager zapewnia routing oparty na systemie DNS dla protokołów innych niż HTTP lub gdy klienci potrzebują bezpośredniej łączności regionalnej.
  • Zapora Azure Firewall w koncentratorze jako cel DNAT: Cały ruch przychodzący przechodzi przez zaporę Azure Firewall w koncentratorze, zanim dotrze do warstw aplikacyjnych. Zapora wykonuje translację docelowych adresów sieciowych (DNAT), aby skierować oczyszczony ruch do właściwego spoke’a. Ten wzorzec gwarantuje, że żaden niezachwiany ruch internetowy nie pomija scentralizowanych mechanizmów kontroli zabezpieczeń.

Połącz usługę Front Door z usługą Application Gateway w każdym regionie, aby zapewnić dwupoziomową inspekcję WAF: jedną na globalnej krawędzi i jedną na granicy regionu.

W przypadku aplikacji dostępnych publicznie migrowanych z platform AWS lub Google Cloud wdroż usługę Application Gateway z funkcją WAF w sieci wirtualnej typu spoke, w której działa obciążenie:

  • Application Gateway + WAF w sieci wirtualnej typu spoke: Wdróż regionalną usługę Application Gateway z włączonym mechanizmem WAF w trybie prewencji. Takie podejście utrzymuje ruch przychodzący blisko obciążenia roboczego, bez konieczności przechodzenia przez koncentrator w celu inspekcji ruchu HTTP.
  • Brak bezpośrednich publicznych adresów IP na maszynach wirtualnych: Nigdy nie przypisz publicznych adresów IP bezpośrednio do migrowanych maszyn wirtualnych. Cały ruch dostępny z Internetu przechodzi przez usługę Application Gateway.
  • Ogranicz dostęp ze źródeł: Jeśli aplikacja była wcześniej umieszczona za usługą AWS Application Load Balancer (ALB) lub Google Cloud Load Balancing, odwzoruj ten wzorzec ruchu wejściowego w usłudze Application Gateway dla obciążeń regionalnych lub Front Door dla obciążeń globalnych.

Jeśli obciążenie działające w wielu chmurach jest wyłącznie wewnętrzne (komunikacja między chmurami przez prywatną sieć tranzytową), pomiń ten artykuł i przejdź do artykułu Azure Firewall i inspekcja ruchu.

Zagadnienia dotyczące zabezpieczeń

Ruch przychodzący z Internetu to drzwi wejściowe Twojej aplikacji. Jest to granica, w której niezaufany ruch internetowy przechodzi do środowiska Azure. Postępuj zgodnie z tymi rozwiązaniami, aby zabezpieczyć ścieżkę ruchu przychodzącego.

Nigdy nie ujawniaj maszyn wirtualnych bezpośrednio za pomocą publicznych adresów IP

Nie przypisuj publicznego adresu IP bezpośrednio do interfejsu sieciowego maszyny wirtualnej do obsługi ruchu aplikacji na portach 80 lub 443. Zamiast tego umieść moduł równoważenia obciążenia lub usługę Application Gateway między Internetem a maszynami wirtualnymi. Takie podejście zapewnia:

  • Kontrole kondycji umożliwiające usuwanie niesprawnych instancji z puli ruchu
  • Pojedynczy punkt zakończenia protokołu SSL lub TLS
  • Miejsce do konfigurowania reguł WAF i ograniczania liczby żądań
  • Scentralizowane rejestrowanie całego ruchu przychodzącego

Caution

Publiczny adres IP bezpośrednio na maszynie wirtualnej uwidacznia każdy otwarty port w Internecie. Jeśli sieciowa grupa zabezpieczeń maszyny wirtualnej ma nieprawidłowo skonfigurowaną regułę, osoby atakujące uzyskują bezpośredni dostęp do systemu operacyjnego.

Włącz WAF w trybie ochrony

Jeśli wdrażasz usługę Application Gateway z usługą WAF lub usługę Azure Front Door z usługą WAF, ustaw usługę WAF w trybie Prevention dla obciążeń produkcyjnych. Tryb zapobiegania blokuje złośliwe żądania przed dotarciem do aplikacji. Tryb wykrywania rejestruje zagrożenia tylko bez blokowania ich. Użyj trybu wykrywania tylko podczas testowania początkowego, aby dostroić reguły i zidentyfikować wyniki fałszywie dodatnie.

Domyślny zestaw reguł zapory aplikacji internetowej (DRS) chroni przed atakami OWASP top 10, w tym wstrzyknięciem kodu SQL, wykonywaniem skryptów między witrynami i zdalnym wykonywaniem kodu. Usługa DRS obejmuje również Microsoft reguły analizy zagrożeń, które wykrywają znane złośliwe adresy IP i ładunki.

Włączanie ochrony przed atakami DDoS

Wszystkie sieci wirtualne z zasobami publicznymi powinny mieć włączoną ochronę przed atakami DDoS. Usługa Azure DDoS Network Protection zapewnia adaptacyjne dostosowywanie, telemetrię ataków oraz ochronę przed kosztami związanymi z publicznymi adresami IP. Bez ochrony przed atakami DDoS atak wolumetryczny może usycić przepustowość ruchu przychodzącego i sprawić, że aplikacja będzie niedostępna.

Aby uzyskać szczegółowe informacje, zobacz Ochrona przed atakami DDoS dla sieci.

Używanie sieciowych grup zabezpieczeń do ochrony w głębi systemu

Nawet jeśli używasz modułu równoważenia obciążenia lub usługi Application Gateway, skonfiguruj reguły sieciowej grupy zabezpieczeń w podsieciach backendowych, aby ograniczyć, które źródła ruchu mogą docierać do Twoich maszyn wirtualnych. Poprawnie skonfigurowana sieciowa grupa zabezpieczeń:

  • Zezwala na ruch tylko z podsieci modułu równoważenia obciążenia lub tagu usługi
  • Odrzuca bezpośredni ruch przychodzący z Internetu do maszyn wirtualnych zaplecza
  • Rejestruje odrzucony ruch na potrzeby monitorowania bezpieczeństwa.

Informacje na temat planowania NSG można znaleźć w artykule Sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji.

Wymuszanie protokołu TLS 1.2 lub nowszego

Skonfiguruj wszystkie usługi ruchu przychodzącego tak, aby akceptowały tylko protokół TLS 1.2 lub TLS 1.3. Wyłącz protokoły TLS 1.0 i 1.1, które mają znane luki w zabezpieczeniach. Zarówno usługa Application Gateway, jak i usługa Front Door obsługują minimalną konfigurację wersji protokołu TLS za pośrednictwem ustawień zasad protokołu TLS. Użyj wstępnie zdefiniowanych zasad, takich jak AppGwSslPolicy20220101 dla usługi Application Gateway, a nie niestandardowych konfiguracji szyfrowania, chyba że masz określone wymagania dotyczące zgodności.

Blokowanie źródeł dla usługi Front Door

Jeśli używasz Azure Front Door, ogranicz serwery pochodzenia do akceptowania ruchu tylko z usługi Front Door. Jeśli serwer źródłowy akceptuje ruch z dowolnego źródła, atakujący mogą ominąć usługę WAF w usłudze Front Door, łącząc się bezpośrednio z adresem IP serwera źródłowego, co sprawia, że cała inwestycja w usługę WAF staje się nieskuteczna.

Blokada źródła używa dwóch niezależnych mechanizmów weryfikacji. Zastosuj oba w ramach ochrony warstwowej:

Ograniczenie tagu usługi (warstwa sieciowa)

Skonfiguruj sieciową grupę zabezpieczeń źródła lub Azure Firewall, aby zezwolić na przychodzący ruch HTTP/HTTPS tylko z tagu AzureFrontDoor.Backend usługi. Ten tag usługi zawiera wszystkie zakresy adresów IP używane przez usługę Front Door do nawiązywania połączenia z źródłami. Zastosuj tę regułę w podsieci lub karcie sieciowej, w której znajduje się źródło:

  • Reguła NSG: Priorytet = 100, Źródło = Service Tag AzureFrontDoor.Backend, Miejsce docelowe = Twoja podsieć zaplecza, Porty = 80, 443, Akcja = Zezwalaj.
  • Odmowa domyślna: Upewnij się, że żadna inna reguła nie zezwala na ruch przychodzący na portach 80/443 z Internetu. Domyślna reguła DenyAllInbound sieciowej grupy zabezpieczeń obsługuje tę regułę, chyba że dodasz szerszą regułę Zezwalaj.

Sam tag usługi jest niewystarczający, ponieważ wszystkie wystąpienia usługi Front Door u wszystkich klientów platformy Azure korzystają z tych samych zakresów adresów IP tagu usługi. Atakujący może utworzyć własny profil usługi Front Door i skierować go do adresu IP pochodzenia, omijając reguły WAF.

Walidacja nagłówka X-Azure-FDID (warstwa aplikacji)

Każde żądanie z usługi Front Door zawiera X-Azure-FDID nagłówek zawierający unikatowy identyfikator (GUID) wystąpienia usługi Front Door, które wysłało żądanie. Zweryfikuj ten nagłówek w aplikacji lub na odwrotnym serwerze proxy, aby potwierdzić, że żądanie pochodzi z profilu usługi Front Door Twojego, a nie od osoby atakującej:

  1. Znajdź swój identyfikator usługi Front Door w portalu Azure na stronie Przegląd profilu usługi Front Door (pole "Identyfikator usługi Front Door").
  2. W kodzie aplikacji lub konfiguracji serwera internetowego odrzuć wszelkie żądania, w których X-Azure-FDID nie są zgodne z oczekiwanym identyfikatorem GUID.
  3. Zwróć kod HTTP 403 w przypadku żądań z brakującą lub nieprawidłową wartością nagłówka.

Połączenie tagu usługi (blokującego ruch spoza usługi Front Door na poziomie sieci) z walidacją nagłówka (blokującą ruch z usługi Front Door innych klientów na poziomie aplikacji) zapewnia, że tylko instancja usługi Front Door może dotrzeć do źródła.

W przypadku obciążeń wymagających najwyższego poziomu izolacji źródła usługa Front Door Premium obsługuje źródła Private Link. Źródło nie wymaga publicznego adresu IP. Usługa Front Door łączy się za pośrednictwem prywatnego punktu końcowego przez sieć szkieletową firmy Microsoft. Takie podejście eliminuje konieczność stosowania reguł tagów usługi lub walidacji nagłówka, ponieważ źródło jest całkowicie niedostępne z publicznego Internetu.

Learn more

Następne kroki

Tip

Eksplorowanie na własną rękę? Wróć do nawigatora przeglądu , aby znaleźć następny artykuł według możliwości.

Kolejny etap w procesie migracji typu lift-and-shift:

Dostarczanie i wydajność aplikacji: dodaj równoważenie obciążenia warstwy 7 i globalne dostarczanie dla zmigrowanego obciążenia.

Jeśli zniesione obciążenie nie wymaga równoważenia obciążenia warstwy 7, przejdź do sekcji Wychodzący dostęp do Internetu.

Kolejny etap procesu modernizacji:

Dostarczanie i wydajność aplikacji: optymalizowanie globalnego dostarczania i wydajności dla obciążeń PaaS przeznaczonych dla klientów.

Kolejny krok w Twojej wielochmurowej podróży:

Web Application Firewall: Ochrona aplikacji publicznych przed atakami w warstwie HTTP w infrastrukturze chmury.

Jeśli obciążenie robocze nie korzysta z protokołu HTTP/HTTPS, przejdź od razu do Zapora Azure i inspekcja ruchu.

  • Last updated on