Usługa Azure Firewall i usługa Application Gateway dla sieci wirtualnych

Usługa Azure Application Gateway

Azure Firewall

Azure Front Door

Azure Virtual Network

Azure Web Application Firewall

Aby ułatwić zabezpieczanie obciążeń aplikacji platformy Azure, należy użyć środków ochronnych, takich jak uwierzytelnianie i szyfrowanie w samych aplikacjach. Warstwy zabezpieczeń można dodawać do sieci wirtualnych hostujących aplikacje. Te warstwy zabezpieczeń ułatwiają ochronę przepływów przychodzących aplikacji przed niezamierzonym użyciem. Ograniczają one również przepływy wychodzące do Internetu tylko do tych punktów końcowych, których wymaga aplikacja. W tym artykule opisano usług zabezpieczeń usługi Azure Virtual Network, takich jak Azure DDoS Protection, Azure Firewall i Azure Application Gateway. Opisano również, kiedy należy używać każdej usługi i opcji projektowania sieci, które je łączą.

• usługi DDoS Protection, w połączeniu z najlepszymi rozwiązaniami dotyczącymi projektowania aplikacji, udostępnia ulepszone funkcje ograniczania ryzyka ataków DDoS, które zwiększają ochronę przed atakami DDoS. Należy włączyć ochronę przed atakami DDoS w każdej sieci wirtualnej obwodowej.

• usługa Azure Firewall to zarządzana zapora nowej generacji, która zapewnia funkcji translatora adresów sieciowych (NAT). Usługa Azure Firewall filtruje pakiety na podstawie adresów IP i portów protokołu TCP (Transmission Control Protocol) lub UDP (User Datagram Protocol). Może filtrować ruch przy użyciu atrybutów opartych na aplikacji, takich jak HTTP(S) i SQL. Usługa Azure Firewall stosuje również analizę zagrożeń firmy Microsoft, aby ułatwić identyfikowanie złośliwych adresów IP. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Firewall.

• usługa Azure Firewall — wersja Premium obejmuje wszystkie funkcje usługi Azure Firewall Standard, a także funkcje takie jak inspekcja protokołu TLS (Transport Layer Security) i system wykrywania i zapobiegania włamaniom (IDPS).

• Application Gateway jest zarządzanym modułem równoważenia obciążenia ruchu internetowego i pełnym zwrotnym serwerem proxy HTTP(S), który może wykonywać szyfrowanie i odszyfrowywanie protokołu Secure Socket Layer (SSL). Usługa Application Gateway zachowuje oryginalny adres IP klienta w nagłówku http X-Forwarded-For. Usługa Application Gateway używa również usługi Azure Web Application Firewall do sprawdzania ruchu internetowego i wykrywania ataków w warstwie HTTP. Aby uzyskać więcej informacji, zobacz dokumentację usługi Application Gateway.

• zapory aplikacji internetowej jest opcjonalnym dodatkiem do usługi Application Gateway. Sprawdza żądania HTTP i zapobiega atakom warstwy internetowej, takim jak wstrzyknięcie kodu SQL i wykonywanie skryptów między witrynami. Aby uzyskać więcej informacji, zobacz dokumentację Web Application Firewall.

Te usługi platformy Azure uzupełniają się wzajemnie. W zależności od potrzeb użycie jednej usługi może lepiej odpowiadać twoim obciążeniom. Można jednak używać tych usług razem, aby zapewnić optymalną ochronę zarówno w warstwach sieci, jak i aplikacji. Użyj następującego drzewa decyzyjnego i przykładów w tym artykule, aby wybrać najlepszą opcję zabezpieczeń dla sieci wirtualnej aplikacji.

Usługi Azure Firewall i Application Gateway używają różnych technologii, aby zabezpieczyć różne typy przepływów danych.

Przepływ aplikacji	Można filtrować za pomocą usługi Azure Firewall	Można filtrować według zapory aplikacji internetowej w usłudze Application Gateway
Ruch HTTP (S) z lokalnego lub internetowego do platformy Azure (ruch przychodzący)	Tak	Tak
Ruch HTTP(S) z platformy Azure do lokalnego lub internetowego (wychodzącego)	Tak	Nie
Ruch inny niż HTTP (ruch przychodzący lub wychodzący)	Tak	Nie

Projekt może się różnić w zależności od wymaganego przepływu sieci. Na poniższym diagramie przedstawiono uproszczone drzewo decyzyjne, które ułatwia wybranie zalecanego podejścia dla aplikacji. Wybór zależy od tego, czy aplikacja jest publikowana za pośrednictwem protokołu HTTP,czy innego protokołu.

W tym artykule opisano szeroko zalecane projekty pokazane na wykresie blokowym i projektach dostosowanych do mniej typowych scenariuszy:

• usługi Azure Firewall tylko: Użyj tego projektu, jeśli w sieci wirtualnej nie ma żadnych aplikacji internetowych. Steruje zarówno ruchem przychodzącym do aplikacji, jak i ruchem wychodzącym.

• usługi Application Gateway tylko: Użyj tego projektu, gdy tylko aplikacje internetowe znajdują się w sieci wirtualnej i sieciowych grup zabezpieczeń (NSG) zapewniają wystarczające filtrowanie danych wyjściowych. Usługa Azure Firewall udostępnia funkcje, które mogą pomóc w zapobieganiu kilku scenariuszom ataku, takim jak eksfiltracja danych i dostawcy tożsamości. W związku z tym projekt tylko w usłudze Application Gateway nie jest zwykle zalecany, więc nie jest uwzględniony na poprzednim wykresie blokowym.

• usługi Azure Firewall i Application Gateway równolegle: Użyj tego projektu, jeśli chcesz, aby usługa Application Gateway chroniła aplikacje HTTP przed atakami internetowymi i usługą Azure Firewall w celu ochrony wszystkich innych obciążeń i filtrowania ruchu wychodzącego. Usługa Azure Firewall i usługa Application Gateway równolegle to typowy projekt.

• Application Gateway przed usługą Azure Firewall: Użyj tego projektu, jeśli chcesz, aby usługa Azure Firewall sprawdzała cały ruch, zaporę aplikacji internetowej w celu ochrony ruchu internetowego oraz aplikację w celu zidentyfikowania źródłowego adresu IP klienta. W przypadku inspekcji usługi Azure Firewall Premium i TLS ten projekt obsługuje również kompleksowe scenariusze ssl.

• usługi Azure Firewall przed usługą Application Gateway: Użyj tego projektu, jeśli chcesz, aby usługa Azure Firewall sprawdzała i filtrować ruch przed dotarciem do usługi Application Gateway. Ponieważ usługa Azure Firewall nie odszyfrowuje ruchu HTTPS, jej dodatkowe funkcje w usłudze Application Gateway są ograniczone. Ten scenariusz nie jest udokumentowany na poprzednim wykresie blokowym.

Odmiany tych podstawowych projektów zostały opisane w dalszej części tego artykułu i obejmują:

• klientów aplikacji lokalnych.
• sieci piasty i szprych.
• implementacje usługi Azure Kubernetes Service (AKS).

Możesz dodać inne usługi zwrotnego serwera proxy, takie jak brama usługi Azure API Management lub azure Front Door. Możesz też zastąpić zasoby platformy Azure wirtualnymi urządzeniami sieciowymi (WUS) innej firmy niż Microsoft.

Nuta

W poniższych scenariuszach maszyna wirtualna platformy Azure jest używana jako przykład obciążenia aplikacji internetowej. Te scenariusze są również prawidłowe dla innych typów obciążeń, takich jak kontenery lub usługa Azure Web Apps. W przypadku konfiguracji obejmujących prywatne punkty końcowe należy wziąć pod uwagę zalecenia w scenariuszach usługi Azure Firewall w celu sprawdzenia ruchu kierowanego do prywatnego punktu końcowego.

Projekt tylko w usłudze Azure Firewall

Jeśli w sieci wirtualnej nie ma żadnych obciążeń internetowych, które mogą korzystać z zapory aplikacji internetowej, możesz użyć projektu tylko usługi Azure Firewall. Projekt w tym przykładzie jest prosty, ale możesz przejrzeć przepływ pakietów, aby lepiej zrozumieć bardziej złożone projekty. W tym projekcie cały ruch przychodzący jest wysyłany do usługi Azure Firewall za pośrednictwem tras zdefiniowanych przez użytkownika (UDR) dla połączeń lokalnych lub innych sieci wirtualnych platformy Azure. Adres jest adresowany do publicznego adresu IP usługi Azure Firewall dla połączeń z publicznego Internetu, jak pokazano na poniższym diagramie. Trasy zdefiniowane przez użytkownika kierują ruch wychodzący z sieci wirtualnych platformy Azure do usługi Azure Firewall, jak pokazano w poniższym oknie dialogowym.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	N/A	Tak
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	N/A	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	N/A	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	N/A	Tak

Usługa Azure Firewall nie sprawdza ruchu przychodzącego HTTP(S). Można jednak zastosować reguły warstwy 3 i warstwy 4 oraz reguły aplikacji oparte na w pełni kwalifikowanej nazwy domeny (FQDN). Usługa Azure Firewall sprawdza wychodzący ruch HTTP(S) w zależności od warstwy usługi Azure Firewall i określa, czy skonfigurować inspekcję protokołu TLS:

• Usługa Azure Firewall Standard sprawdza tylko atrybuty warstwy 3 i 4 pakietów w regułach sieciowych oraz nagłówek HTTP hosta w regułach aplikacji.

• Usługa Azure Firewall Premium dodaje funkcje, takie jak inspekcja innych nagłówków HTTP (takich jak agent użytkownika) i włączanie inspekcji protokołu TLS w celu dokładniejszej analizy pakietów. Jednak usługa Azure Firewall nie jest taka sama jak zapora aplikacji internetowej. Jeśli masz obciążenia internetowe w sieci wirtualnej, zalecamy użycie zapory aplikacji internetowej.

Poniższy przykładowy przewodnik po pakiecie pokazuje, jak klient uzyskuje dostęp do aplikacji hostowanej przez maszynę wirtualną z publicznego Internetu. Diagram zawiera tylko jedną maszynę wirtualną dla uproszczenia. W celu zwiększenia dostępności i skalowalności istnieje wiele wystąpień aplikacji za modułem równoważenia obciążenia. W tym projekcie usługa Azure Firewall sprawdza połączenia przychodzące z publicznego Internetu i połączeń wychodzących z maszyny wirtualnej podsieci aplikacji przy użyciu trasy zdefiniowanej przez użytkownika.

• W tym przykładzie usługa Azure Firewall automatycznie wdraża kilka wystąpień z adresem IP frontonu 192.168.100.4 i adresami wewnętrznymi w zakresie 192.168.100.0/26. Zwykle te wystąpienia nie są widoczne dla administratora platformy Azure. Jednak ich świadomość może być przydatna do rozwiązywania problemów z siecią.

• Jeśli ruch pochodzi z lokalnej wirtualnej sieci prywatnej (VPN) lub bramy usługi Azure ExpressRoute zamiast z Internetu, klient uruchamia połączenie z adresem IP maszyny wirtualnej. Nie uruchamia połączenia z adresem IP zapory, a zapora domyślnie nie wykonuje źródłowego translatora adresów sieciowych.

Architektura

Na poniższym diagramie przedstawiono przepływ ruchu i przyjęto założenie, że adres IP wystąpienia jest 192.168.100.7.

Przepływ pracy

1. Klient uruchamia połączenie z publicznym adresem IP usługi Azure Firewall.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AzFwPIP

2. Żądanie do publicznego adresu IP usługi Azure Firewall jest dystrybuowane do wystąpienia zaplecza zapory, które jest 192.168.100.7 w tym przykładzie. Reguła translacji docelowych adresów sieciowych (DNAT) usługi Azure Firewall tłumaczy docelowy adres IP na adres IP aplikacji wewnątrz sieci wirtualnej. Usługa Azure Firewall implementuje również translacji adresów sieciowych (SNAT) w pakiecie, jeśli używa DNAT. Aby uzyskać więcej informacji, zobacz znane problemy z usługą Azure Firewall. Maszyna wirtualna widzi następujące adresy IP w pakiecie przychodzącym:

   • Źródłowy adres IP: 192.168.100.7
   • Docelowy adres IP: 192.168.1.4

3. Maszyna wirtualna odpowiada na żądanie aplikacji, co odwraca zarówno źródłowe, jak i docelowe adresy IP. Przepływ przychodzący nie wymaga trasy zdefiniowanej przez użytkownika, ponieważ źródłowy adres IP jest adresem IP usługi Azure Firewall. Trasa zdefiniowana przez użytkownika na diagramie dla 0.0.0.0/0 dotyczy połączeń wychodzących w celu zapewnienia, że pakiety do publicznego Internetu przechodzą przez usługę Azure Firewall.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.100.7

4. Usługa Azure Firewall cofa operacje SNAT i DNAT i dostarcza odpowiedź na klienta.

   • Źródłowy adres IP: AzFwPIP
   • Docelowy adres IP: ClientPIP

Projekt tylko w usłudze Application Gateway

W tym projekcie opisano scenariusz, w którym istnieją tylko aplikacje internetowe w sieci wirtualnej, a inspekcja ruchu wychodzącego za pomocą sieciowych grup zabezpieczeń jest wystarczająca do ochrony przepływów wychodzących do Internetu.

Nuta

Nie zalecamy tego projektu, ponieważ używanie usługi Azure Firewall do kontrolowania przepływów wychodzących zamiast polegania wyłącznie na sieciowych grupach zabezpieczeń pomaga zapobiegać scenariuszom ataku, takim jak eksfiltracja danych. Za pomocą usługi Azure Firewall możesz zapewnić, że obciążenia wysyłają tylko dane do zatwierdzonej listy adresów URL. Ponadto sieciowe grupy zabezpieczeń działają tylko w warstwie 3 i warstwie 4 i nie obsługują nazw FQDN.

Kluczową różnicą w stosunku do poprzedniego projektu usługi Azure Firewall jest to, że usługa Application Gateway nie służy jako urządzenie routingu z translatorem adresów sieciowych. Zamiast tego działa jako pełny zwrotny serwer proxy aplikacji. Takie podejście oznacza, że usługa Application Gateway zatrzymuje sesję internetową od klienta i ustanawia oddzielną sesję z jednym z serwerów zaplecza. Przychodzące połączenia HTTP (S) z Internetu są wysyłane do publicznego adresu IP usługi Application Gateway, a połączenia z platformy Azure lub lokalnie używają prywatnego adresu IP bramy. Ruch powrotny z maszyn wirtualnych platformy Azure jest zgodny ze standardowym routingiem sieci wirtualnej z powrotem do usługi Application Gateway. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu. Wychodzące przepływy internetowe z maszyn wirtualnych platformy Azure przechodzą bezpośrednio do Internetu.

Poniższa tabela zawiera podsumowanie przepływów ruchu.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	N/A
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	N/A
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	N/A
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	N/A

Architektura

Poniższy przykład przewodnika po pakiecie pokazuje, jak klient uzyskuje dostęp do aplikacji hostowanej na maszynie wirtualnej z publicznego Internetu.

Przepływ pracy

1. Klient uruchamia połączenie z publicznym adresem IP usługi Application Gateway.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AppGwPIP

2. Żądanie do publicznego adresu IP usługi Application Gateway jest dystrybuowane do wystąpienia zaplecza bramy, które jest 192.168.200.7 w tym przykładzie. Wystąpienie usługi Application Gateway, które odbiera żądanie, zatrzymuje połączenie z klientem i ustanawia nowe połączenie z jednym z zaplecza. Zaplecze widzi wystąpienie usługi Application Gateway jako źródłowy adres IP. Usługa Application Gateway wstawia nagłówek HTTP X-Forwarded-For z adresem IP oryginalnego klienta.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Application Gateway: 192.168.200.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: ClientPIP

3. Maszyna wirtualna odpowiada na żądanie aplikacji i odwraca zarówno źródłowe, jak i docelowe adresy IP. Maszyna wirtualna może nawiązać połączenie z usługą Application Gateway, więc nie wymaga trasy zdefiniowanej przez użytkownika.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

4. Wystąpienie usługi Application Gateway odpowiada na klienta.

   • Źródłowy adres IP: AppGwPIP
   • Docelowy adres IP: ClientPIP

Usługa Application Gateway dodaje metadane do nagłówków HTTP pakietu, takich jak nagłówek X-Forwarded-For zawierający oryginalny adres IP klienta. Niektóre serwery aplikacji wymagają źródłowego adresu IP klienta do obsługi zawartości specyficznej dla lokalizacji geograficznej lub rejestrowania. Aby uzyskać więcej informacji, zobacz Jak działa brama aplikacji.

• W tym przykładzie adres IP 192.168.200.7 jest jednym z wystąpień wdrożonych automatycznie przez usługę Application Gateway. Ma wewnętrzny, prywatny adres IP frontonu 192.168.200.4. Te poszczególne wystąpienia są zwykle niewidoczne dla administratora platformy Azure. Jednak zauważenie różnicy może być przydatne, na przykład podczas rozwiązywania problemów z siecią.

• Przepływ jest podobny, jeśli klient pochodzi z sieci lokalnej za pośrednictwem sieci VPN lub bramy usługi ExpressRoute. Różnica polega na tym, że klient uzyskuje dostęp do prywatnego adresu IP usługi Application Gateway zamiast publicznego adresu IP.

Nuta

Aby uzyskać więcej informacji na temat nagłówka X-Forwarded-For i sposobu zachowania nazwy hosta w żądaniu, zobacz Zachowaj oryginalny host HTTP.

Równoległe projektowanie usług Azure Firewall i Application Gateway

Ze względu na prostotę i elastyczność, często najlepiej jest uruchamiać usługę Application Gateway i usługę Azure Firewall równolegle.

Zaimplementuj ten projekt, jeśli w sieci wirtualnej znajdują się obciążenia internetowe i inne niż internetowe. Zapora aplikacji internetowej w usłudze Application Gateway pomaga chronić ruch przychodzący do obciążeń internetowych. Usługa Azure Firewall sprawdza ruch przychodzący dla innych aplikacji. Usługa Azure Firewall obejmuje przepływy wychodzące z obu typów obciążeń.

Przychodzące połączenia HTTP (S) z Internetu powinny być wysyłane do publicznego adresu IP usługi Application Gateway. Połączenia HTTP(S) z platformy Azure lub środowiska lokalnego powinny być wysyłane do jego prywatnego adresu IP. Routing w standardowej sieci wirtualnej wysyła pakiety z usługi Application Gateway do docelowych maszyn wirtualnych i z docelowych maszyn wirtualnych z powrotem do usługi Application Gateway. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu.

W przypadku połączeń przychodzących innych niż HTTP ruch powinien być kierowany do publicznego adresu IP usługi Azure Firewall, jeśli pochodzi z publicznego Internetu. Ruch powinien być wysyłany za pośrednictwem usługi Azure Firewall przez trasy zdefiniowane przez użytkownika, jeśli pochodzi z innych sieci wirtualnych platformy Azure lub sieci lokalnych. Wszystkie przepływy wychodzące z maszyn wirtualnych platformy Azure są przekazywane do usługi Azure Firewall przez trasy zdefiniowane przez użytkownika.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	Nie
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak

Ten projekt zapewnia znacznie bardziej szczegółowe filtrowanie ruchu wychodzącego niż wyłącznie przy użyciu sieciowych grup zabezpieczeń. Jeśli na przykład aplikacje potrzebują łączności z określonym kontem usługi Azure Storage, możesz użyć filtrów opartych na nazwach FQDN. W przypadku filtrów opartych na nazwach FQDN aplikacje nie wysyłają danych do nieautoryzowanych kont magazynu. Jeśli używasz tylko sieciowych grup zabezpieczeń, nie możesz zapobiec temu scenariuszowi. Ten projekt jest często używany, gdy ruch wychodzący wymaga filtrowania opartego na nazwie FQDN. Jednym ze scenariuszy jest to, że ograniczyć ruch wychodzący z klastra usługi AKS.

Architektury

Na poniższym diagramie przedstawiono przepływ ruchu dla przychodzących połączeń HTTP(S) z klienta zewnętrznego.

Na poniższym diagramie przedstawiono przepływ ruchu dla połączeń wychodzących z maszyn wirtualnych sieciowych do Internetu. Jednym z przykładów jest nawiązanie połączenia z systemami zaplecza lub pobranie aktualizacji systemu operacyjnego.

Kroki przepływu pakietów dla każdej usługi są takie same jak w poprzednich autonomicznych opcjach projektowania.

Usługa Application Gateway przed projektem usługi Azure Firewall

Ten projekt wyjaśniono bardziej szczegółowo w sieci zerowej zaufania dla aplikacji internetowych za pomocą usługi Azure Firewall i usługi Application Gateway. Ten artykuł koncentruje się na porównaniu z innymi opcjami projektowania. W tej topologii przychodzący ruch internetowy przechodzi zarówno przez usługę Azure Firewall, jak i zaporę aplikacji internetowej. Zapora aplikacji internetowej zapewnia ochronę w warstwie aplikacji internetowej. Usługa Azure Firewall służy jako centralny punkt rejestrowania i kontroli oraz sprawdza ruch między usługą Application Gateway i serwerami zaplecza. W tym projekcie usługa Application Gateway i usługa Azure Firewall nie znajdują się równolegle, ale znajdują się przed sobą.

W przypadku usługi Azure Firewall w wersji Premiumten projekt może obsługiwać kompleksowe scenariusze, w których usługa Azure Firewall stosuje inspekcję protokołu TLS w celu przeprowadzania idPS na zaszyfrowanym ruchu między usługą Application Gateway a zapleczem internetowym.

Ten projekt jest odpowiedni dla aplikacji, które muszą identyfikować przychodzące źródłowe adresy IP klienta. Na przykład może służyć do udostępniania zawartości specyficznej dla lokalizacji geograficznej lub rejestrowania. Usługa Application Gateway przed projektem usługi Azure Firewall przechwytuje źródłowy adres IP pakietu przychodzącego w nagłówku X-Forwarded-For, aby serwer internetowy mógł zobaczyć oryginalny adres IP w tym nagłówku. Aby uzyskać więcej informacji, zobacz Jak działa brama aplikacji.

Przychodzące połączenia HTTP (S) z Internetu muszą być wysyłane do publicznego adresu IP usługi Application Gateway. Połączenia HTTP(S) z platformy Azure lub środowiska lokalnego powinny być wysyłane do jego prywatnego adresu IP. W usłudze Application Gateway trasy zdefiniowane przez użytkownika zapewniają, że pakiety są kierowane przez usługę Azure Firewall. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu.

W przypadku połączeń przychodzących innych niż HTTP ruch powinien być kierowany do publicznego adresu IP usługi Azure Firewall, jeśli pochodzi z publicznego Internetu. Ruch powinien być wysyłany za pośrednictwem usługi Azure Firewall przez trasy zdefiniowane przez użytkownika, jeśli pochodzi z innych sieci wirtualnych platformy Azure lub sieci lokalnych. Wszystkie przepływy wychodzące z maszyn wirtualnych platformy Azure są przekazywane do usługi Azure Firewall przez trasy zdefiniowane przez użytkownika.

Ważnym aspektem tego projektu jest to, że usługa Azure Firewall Premium widzi ruch ze źródłowym adresem IP z podsieci usługi Application Gateway. Jeśli ta podsieć jest skonfigurowana przy użyciu prywatnego adresu IP (w 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12lub 100.64.0.0/10), usługa Azure Firewall Premium traktuje ruch z usługi Application Gateway jako wewnętrzny i nie stosuje reguł IDPS dla ruchu przychodzącego. W związku z tym zalecamy zmodyfikowanie prywatnych prefiksów IDPS w zasadach usługi Azure Firewall. Ta modyfikacja gwarantuje, że podsieć usługi Application Gateway nie jest uznawana za źródło wewnętrzne, które umożliwia stosowanie podpisów IDPS dla ruchu przychodzącego i wychodzącego. Więcej informacji na temat wskazówek reguł idPS usługi Azure Firewall i prywatnych prefiksów adresów IP dla dostawcy tożsamości można znaleźć w reguł idPS usługi Azure Firewall.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	Tak
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak

W przypadku ruchu internetowego ze środowiska lokalnego lub z Internetu do platformy Azure usługa Azure Firewall sprawdza przepływy dozwolone przez zaporę aplikacji internetowej. W zależności od tego, czy usługa Application Gateway szyfruje ruch zaplecza, który jest ruchem z usługi Application Gateway do serwerów aplikacji, mogą wystąpić różne scenariusze:

• Usługa Application Gateway szyfruje ruch, postępując zgodnie z zasadami zerowego zaufania, takimi jak kompleksowe szyfrowanie TLS, a usługa Azure Firewall odbiera zaszyfrowany ruch. Usługa Azure Firewall w warstwie Standardowa może nadal stosować reguły inspekcji, takie jak filtrowanie warstwy 3 i 4 w regułach sieciowych lub filtrowanie nazw FQDN w regułach aplikacji przy użyciu nagłówka SNI (TLS Server Name Indication). Azure Firewall Premium zapewnia lepszy wgląd w inspekcję protokołu TLS, taką jak filtrowanie oparte na adresach URL.

• Jeśli usługa Application Gateway wysyła niezaszyfrowany ruch do serwerów aplikacji, usługa Azure Firewall widzi ruch przychodzący w postaci zwykłego tekstu. Inspekcja protokołu TLS nie jest wymagana w usłudze Azure Firewall.

• Jeśli usługa IDPS jest włączona w usłudze Azure Firewall, sprawdza, czy nagłówek hosta HTTP jest zgodny z docelowym adresem IP. Aby przeprowadzić tę weryfikację, potrzebuje rozpoznawania nazw dla nazwy FQDN określonej w nagłówku hosta. To rozpoznawanie nazw można wykonać przy użyciu stref prywatnych usługi Azure DNS i domyślnych ustawień DNS usługi Azure Firewall. Można go również osiągnąć za pomocą niestandardowych serwerów DNS, które należy skonfigurować w ustawieniach usługi Azure Firewall. Jeśli nie masz dostępu administracyjnego do sieci wirtualnej, w której wdrożono usługę Azure Firewall, jedyną opcją jest ta ostatnia metoda. Jednym z przykładów jest użycie wystąpień usługi Azure Firewall wdrożonych w koncentratorach zabezpieczonych za pomocą usługi Azure Virtual WAN.

Architektura

W przypadku pozostałych przepływów, które obejmują ruch przychodzący bez protokołu HTTP i dowolny ruch wychodzący, usługa Azure Firewall zapewnia inspekcję dostawcy tożsamości i inspekcję protokołu TLS tam, gdzie jest to odpowiednie. Zapewnia również filtrowanie oparte na nazwach FQDN w regułach sieciowych na podstawie systemu DNS.

Przepływ pracy

Ruch sieciowy z publicznego Internetu jest zgodny z tym przepływem:

1. Klient uruchamia połączenie z publicznym adresem IP usługi Application Gateway.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AppGwPIP

2. Żądanie do publicznego adresu IP usługi Application Gateway jest dystrybuowane do wystąpienia zaplecza bramy, które jest 192.168.200.7 w tym przykładzie. Wystąpienie usługi Application Gateway zatrzymuje połączenie z klientem i ustanawia nowe połączenie z jednym z zaplecza. Trasa zdefiniowana przez użytkownika do 192.168.1.0/24 w podsieci usługi Application Gateway przekazuje pakiet do usługi Azure Firewall i zachowuje docelowy adres IP aplikacji internetowej.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Application Gateway: 192.168.200.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: ClientPIP

3. Usługa Azure Firewall nie stosuje protokołu SNAT do ruchu, ponieważ ruch przechodzi do prywatnego adresu IP. Przekazuje ruch do maszyny wirtualnej aplikacji, jeśli zezwalają na to reguły. Aby uzyskać więcej informacji, zobacz Usługa SNAT dla zakresów prywatnych adresów IP w usłudze Azure Firewall. Jeśli jednak ruch osiągnie regułę aplikacji w zaporze, obciążenie zobaczy źródłowy adres IP określonego wystąpienia zapory, które przetworzyło pakiet, ponieważ serwer proxy usługi Azure Firewall nawiązał połączenie.

   • Źródłowy adres IP, jeśli ruch jest dozwolony przez regułę sieciową usługi Azure Firewall i jest prywatnym adresem IP jednego z wystąpień usługi Application Gateway: 192.168.200.7
   • Źródłowy adres IP, jeśli ruch jest dozwolony przez regułę aplikacji usługi Azure Firewall i jest prywatnym adresem IP jednego z wystąpień usługi Azure Firewall: 192.168.100.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: ClientPIP

4. Maszyna wirtualna odpowiada na żądanie, które odwraca zarówno źródłowe, jak i docelowe adresy IP. Trasa zdefiniowana przez użytkownika do 192.168.200.0/24 przechwytuje pakiet wysyłany z powrotem do usługi Application Gateway, przekierowuje go do usługi Azure Firewall i zachowuje docelowy adres IP w kierunku usługi Application Gateway.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

5. Ponownie usługa Azure Firewall nie stosuje protokołu SNAT do ruchu, ponieważ przechodzi do prywatnego adresu IP i przekazuje ruch do usługi Application Gateway.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

6. Wystąpienie usługi Application Gateway odpowiada na klienta.

   • Źródłowy adres IP: AppGwPIP
   • Docelowy adres IP: ClientPIP

Przepływy wychodzące z maszyn wirtualnych do publicznego Internetu przechodzą przez usługę Azure Firewall, którą zdefiniowano przez trasę zdefiniowaną przez trasę zdefiniowaną przez 0.0.0.0/0 użytkownika.

Jako odmiana tego projektu można skonfigurować prywatne DNAT w usłudze Azure Firewall, aby obciążenie aplikacji wyświetlało adresy IP wystąpień usługi Azure Firewall jako źródła, a nie są wymagane żadne trasy zdefiniowane przez użytkownika. Źródłowy adres IP klientów aplikacji jest już zachowywany w nagłówku HTTP X-Forwarded-For przez usługę Application Gateway. Jeśli więc usługa Azure Firewall stosuje dnaT do ruchu, żadne informacje nie zostaną utracone. Aby uzyskać więcej informacji, zobacz Filter inbound Internet or intranet traffic with Azure Firewall policy DNAT by using the Azure Portal.

Usługa Azure Firewall przed projektem usługi Application Gateway

Ten projekt umożliwia usłudze Azure Firewall filtrowanie i odrzucanie złośliwego ruchu przed dotarciem do usługi Application Gateway. Może na przykład stosować funkcje, takie jak filtrowanie oparte na inteligencji zagrożeń. Kolejną korzyścią jest to, że aplikacja pobiera ten sam publiczny adres IP zarówno dla ruchu przychodzącego, jak i wychodzącego, niezależnie od protokołu. Istnieją trzy tryby, w których teoretycznie można skonfigurować usługę Azure Firewall:

• azure Firewall z regułami DNAT: usługa Azure Firewall zamienia tylko adresy IP w warstwie adresów IP, ale nie przetwarza ładunku. W związku z tym nie zmienia żadnego nagłówka HTTP.

• usługę Azure Firewall z wyłączonymi regułami aplikacji i inspekcją protokołu TLS: usługa Azure Firewall może przyjrzeć się nagłówkowi SNI w protokole TLS, ale nie odszyfruje go. Nowe połączenie TCP jest tworzone z zapory do następnego przeskoku. W tym przykładzie jest to usługa Application Gateway.

• usługę Azure Firewall z włączonymi regułami aplikacji i inspekcją protokołu TLS: usługa Azure Firewall analizuje zawartość pakietu i odszyfrowuje je. Służy jako serwer proxy HTTP i może ustawić nagłówki HTTP X-Forwarded-For, aby zachować adres IP. Jednak przedstawia on klientowi certyfikat wygenerowany samodzielnie. W przypadku aplikacji internetowych używanie certyfikatu generowanego samodzielnie nie jest opcją, ponieważ do klientów aplikacji jest wysyłane ostrzeżenie o zabezpieczeniach z przeglądarki.

W dwóch pierwszych opcjach, które są jedynymi prawidłowymi opcjami dla aplikacji internetowych, usługa Azure Firewall stosuje uwierzytelnianie SNAT do ruchu przychodzącego bez ustawiania nagłówka X-Forwarded-For. W związku z tym aplikacja nie może zobaczyć oryginalnego adresu IP żądań HTTP. W przypadku zadań administracyjnych, takich jak rozwiązywanie problemów, można uzyskać rzeczywisty adres IP klienta dla określonego połączenia, korelując go z dziennikami SNAT usługi Azure Firewall.

Korzyści wynikające z tego scenariusza są ograniczone, ponieważ jeśli nie korzystasz z inspekcji protokołu TLS i przedstawiasz samodzielnie wygenerowane certyfikaty klientom, usługa Azure Firewall widzi tylko zaszyfrowany ruch kierowany do usługi Application Gateway. Ten scenariusz jest zwykle możliwy tylko w przypadku aplikacji wewnętrznych. Jednak mogą wystąpić scenariusze, w których ten projekt jest preferowany. Jednym ze scenariuszy jest to, że inna zapora aplikacji internetowej istnieje wcześniej w sieci (na przykład z usługi Azure Front Door), która może przechwytywać oryginalny źródłowy adres IP w nagłówku http X-Forwarded-For. Ten projekt może być również preferowany, jeśli wymagana jest wiele publicznych adresów IP, ponieważ usługa Application Gateway obsługuje jeden adres IP.

Przepływy przychodzące HTTP(S) z publicznego Internetu powinny być kierowane do publicznego adresu IP usługi Azure Firewall. Usługa Azure Firewall będzie dnat i SNAT pakiety do prywatnego adresu IP usługi Application Gateway. Z innych sieci wirtualnych platformy Azure lub sieci lokalnych ruch HTTP(S) powinien być wysyłany do prywatnego adresu IP usługi Application Gateway i przekazywany za pośrednictwem usługi Azure Firewall z trasami zdefiniowanymi przez użytkownika. Standardowy routing sieci wirtualnej zapewnia, że ruch powrotny z maszyn wirtualnych platformy Azure wraca do usługi Application Gateway i z usługi Application Gateway do usługi Azure Firewall, jeśli zostały użyte reguły DNAT. W przypadku ruchu ze środowiska lokalnego lub platformy Azure użyj tras zdefiniowanych przez użytkownika w podsieci usługi Application Gateway. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu. Cały ruch wychodzący z maszyn wirtualnych platformy Azure do Internetu jest wysyłany przez usługę Azure Firewall przez trasy zdefiniowane przez użytkownika.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	Tak
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak

W przypadku ruchu przychodzącego HTTP(S) usługa Azure Firewall zwykle nie odszyfrowuje ruchu. Zamiast tego stosuje zasady idPS, które nie wymagają inspekcji protokołu TLS, takich jak filtrowanie oparte na adresach IP lub używanie nagłówków HTTP.

Architektura

Aplikacja nie widzi oryginalnego źródłowego adresu IP ruchu internetowego. Usługa Azure Firewall stosuje protokół SNAT do pakietów w miarę ich ściągniania do sieci wirtualnej. Aby uniknąć tego problemu, użyj usługi Azure Front Door przed zaporą. Usługa Azure Front Door wprowadza adres IP klienta jako nagłówek HTTP przed wejściem do sieci wirtualnej platformy Azure.

Przepływ pracy

Ruch sieciowy z publicznego Internetu jest zgodny z tym przepływem:

1. Klient uruchamia połączenie z publicznym adresem IP usługi Azure Firewall.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AzFWPIP

2. Żądanie do publicznego adresu IP usługi Azure Firewall jest dystrybuowane do wystąpienia zaplecza zapory, które jest 192.168.100.7 w tym przykładzie. Usługa Azure Firewall stosuje dnaT do portu internetowego, zwykle TCP 443, do prywatnego adresu IP wystąpienia usługi Application Gateway. Usługa Azure Firewall stosuje również protokół SNAT podczas wykonywania funkcji DNAT. Aby uzyskać więcej informacji, zobacz znane problemy z usługą Azure Firewall.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Azure Firewall: 192.168.100.7
   • Docelowy adres IP: 192.168.200.4

3. Usługa Application Gateway ustanawia nową sesję między wystąpieniem, które obsługuje połączenie i jeden z serwerów zaplecza. Oryginalny adres IP klienta nie znajduje się w pakiecie.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Application Gateway: 192.168.200.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: 192.168.100.7

4. Maszyna wirtualna odpowiada na usługę Application Gateway, która odwraca zarówno źródłowe, jak i docelowe adresy IP:

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

5. Usługa Application Gateway odpowiada na źródłowy adres IP SNAT wystąpienia usługi Azure Firewall. Usługa Azure Firewall widzi wewnętrzny adres IP usługi Application Gateway, .4, jako źródłowy adres IP, nawet jeśli połączenie pochodzi z określonego wystąpienia usługi Application Gateway, takiego jak .7.

   • Źródłowy adres IP: 192.168.200.4
   • Docelowy adres IP: 192.168.100.7

6. Usługa Azure Firewall cofa żądania SNAT i DNAT oraz odpowiada na klienta.

   • Źródłowy adres IP: AzFwPIP
   • Docelowy adres IP: ClientPIP

Usługa Application Gateway potrzebuje publicznego adresu IP, aby firma Microsoft mogła nim zarządzać, nawet jeśli nie ma odbiorników skonfigurowanych dla aplikacji.

Nuta

Domyślna trasa do 0.0.0.0/0 w podsieci usługi Application Gateway wskazująca usługę Azure Firewall nie jest obsługiwana, ponieważ przerywa ruch płaszczyzny sterowania wymagany przez usługę Application Gateway do prawidłowego działania.

Klienci lokalni

Powyższe projekty pokazują wszystkich klientów aplikacji przychodzących z publicznego Internetu. Sieci lokalne również uzyskują dostęp do aplikacji. Większość poprzednich informacji i przepływów ruchu jest taka sama jak w przypadku klientów internetowych, ale istnieją pewne istotne różnice:

• Brama sieci VPN lub brama usługi ExpressRoute znajduje się przed usługą Azure Firewall lub application Gateway.

• Zapora aplikacji internetowej używa prywatnego adresu IP usługi Application Gateway.

• Usługa Azure Firewall nie obsługuje protokołu DNAT dla prywatnych adresów IP, dlatego należy użyć tras zdefiniowanych przez użytkownika do wysyłania ruchu przychodzącego do usługi Azure Firewall z bram sieci VPN lub usługi ExpressRoute.

• Upewnij się, że w wymuszone tunelowanieApplication Gateway i azure firewall. Nawet jeśli obciążenie nie wymaga łączności wychodzącej z publicznym Internetem, nie można wstrzyknąć trasy domyślnej, takiej jak 0.0.0.0/0 dla usługi Application Gateway, która wskazuje sieć lokalną, ponieważ przerywa ruch. W przypadku usługi Application Gateway domyślna trasa musi wskazywać publiczny Internet.

Architektura

Na poniższym diagramie przedstawiono równoległe projektowanie usługi Application Gateway i usługi Azure Firewall. Klienci aplikacji pochodzą z sieci lokalnej połączonej z platformą Azure za pośrednictwem sieci VPN lub usługi ExpressRoute:

Nawet jeśli wszyscy klienci znajdują się lokalnie lub na platformie Azure, usługa Application Gateway i usługa Azure Firewall muszą mieć publiczne adresy IP. Te publiczne adresy IP umożliwiają firmie Microsoft zarządzanie usługami.

Topologia piasty i szprych

Projekty w tym artykule dotyczą topologii piasty i szprych. Udostępnione zasoby w centralnej sieci wirtualnej koncentratora łączą się z aplikacjami w oddzielnych sieciach wirtualnych szprych za pośrednictwem komunikacji równorzędnej sieci wirtualnych.

Architektura

• Usługa Azure Firewall jest wdrażana w centralnej sieci wirtualnej koncentratora. Na poprzednim diagramie pokazano, jak wdrożyć usługę Application Gateway w centrum. Zespoły aplikacji często zarządzają składnikami, takimi jak bramy usługi Application Gateway lub bramy usługi API Management. W tym scenariuszu te składniki są wdrażane w sieciach wirtualnych szprych.

• Zwróć szczególną uwagę na trasy zdefiniowane przez użytkownika w sieciach szprych. Gdy serwer aplikacji w szprychy odbiera ruch z określonego wystąpienia usługi Azure Firewall, na przykład adres IP 192.168.100.7 w poprzednich przykładach, powinien wysyłać ruch powrotny do tego samego wystąpienia. Jeśli trasa zdefiniowana przez użytkownika w szprychach ustawia następny przeskok ruchu skierowanego do centrum do adresu IP usługi Azure Firewall (192.168.100.4 na poprzednich diagramach), pakiety zwrotne mogą trafić do innego wystąpienia usługi Azure Firewall. Taka sytuacja powoduje routing asymetryczny. Jeśli masz trasy zdefiniowane przez użytkownika w sieciach wirtualnych szprych, pamiętaj, aby wysłać ruch do usług udostępnionych w centrum za pośrednictwem usługi Azure Firewall. Te trasy zdefiniowane przez użytkownika nie zawierają prefiksu podsieci usługi Azure Firewall.

• Poprzednie zalecenie dotyczy jednakowo podsieci usługi Application Gateway i innych urządzeń WUS lub zwrotnych serwerów proxy, które mogą zostać wdrożone w sieci wirtualnej koncentratora.

• Nie można ustawić następnego przeskoku dla podsieci usługi Application Gateway lub usługi Azure Firewall za pośrednictwem tras statycznych z typem następnego przeskoku Virtual Network. Ten typ następnego przeskoku jest prawidłowy tylko w lokalnej sieci wirtualnej, a nie w sieciach równorzędnych sieci wirtualnych. Aby uzyskać więcej informacji na temat tras zdefiniowanych przez użytkownika i typów następnego przeskoku, zobacz Routing ruchu w sieci wirtualnej.

Routing asymetryczny

Na poniższym diagramie pokazano, jak szprycha wysyła ruch SNAT z powrotem do modułu równoważenia obciążenia platformy Azure w usłudze Azure Firewall. Ta konfiguracja powoduje routing asymetryczny.

Aby rozwiązać ten problem, zdefiniuj trasy zdefiniowane przez użytkownika w szprychach bez podsieci usługi Azure Firewall i tylko z podsieciami, w których znajdują się usługi udostępnione. Na poprzednim diagramie prawidłowa trasa zdefiniowana przez użytkownika w szprychach powinna zawierać tylko 192.168.1.0/24. Nie powinien zawierać całego zakresu 192.168.0.0/16, który jest oznaczony na czerwono.

Integracja z innymi produktami platformy Azure

Usługę Azure Firewall i usługę Application Gateway można zintegrować z innymi produktami i usługami platformy Azure.

Brama usługi API Management

Integrowanie usług zwrotnego serwera proxy, takich jak brama usługi API Management z poprzednimi projektami, aby zapewnić funkcje, takie jak ograniczanie przepustowości interfejsu API lub serwer proxy uwierzytelniania. Integracja bramy usługi API Management nie wpływa znacząco na projekty. Kluczową różnicą jest to, że zamiast pojedynczego zwrotnego serwera proxy usługi Application Gateway istnieją dwa odwrotne serwery proxy powiązane ze sobą.

Aby uzyskać więcej informacji, zobacz przewodnik projektowania , aby zintegrować usługę API Management i usługę Application Gateway w sieci wirtualnej oraz wzorzec aplikacji bram interfejsu API dla mikrousług.

Usługa AKS

W przypadku obciążeń uruchamianych w klastrze usługi AKS można wdrożyć usługę Application Gateway niezależnie od klastra. Możesz też zintegrować go z klastrem usługi AKS przy użyciu kontrolera ruchu przychodzącego usługi Application Gateway . Podczas konfigurowania określonych obiektów na poziomach platformy Kubernetes, takich jak usługi i ruch przychodzący, usługa Application Gateway automatycznie dostosowuje się bez konieczności wykonywania dodatkowych kroków ręcznych.

Usługa Azure Firewall odgrywa ważną rolę w zabezpieczeniach klastra usługi AKS. Zapewnia ona wymaganą funkcję filtrowania ruchu wychodzącego z klastra usługi AKS na podstawie nazwy FQDN, a nie tylko adresu IP. Aby uzyskać więcej informacji, zobacz Ograniczanie ruchu sieciowego za pomocą usługi Azure Firewall w usłudze AKS.

Łącząc usługę Application Gateway i usługę Azure Firewall w celu ochrony klastra usługi AKS, najlepiej użyć opcji projektowania równoległego. Usługa Application Gateway z zaporą aplikacji internetowej przetwarza przychodzące żądania połączeń do aplikacji internetowych w klastrze. Usługa Azure Firewall zezwala tylko na jawne dozwolone połączenia wychodzące. Aby uzyskać więcej informacji na temat opcji projektowania równoległego, zobacz Architektura punktu odniesienia dla klastra usługi AKS.

Usługa Azure Front Door

usługa Azure Front Door ma funkcje nakładające się na usługę Application Gateway w kilku obszarach. Obie usługi zapewniają zaporę aplikacji internetowej, odciążanie protokołu SSL i routing oparty na adresach URL. Jednak kluczową różnicą jest to, że chociaż usługa Application Gateway działa w sieci wirtualnej, usługa Azure Front Door jest globalną, zdecentralizowaną usługą.

Czasami można uprościć projektowanie sieci wirtualnej, zastępując usługę Application Gateway zdecentralizowaną usługą Azure Front Door. Większość projektów opisanych w tym artykule nadal ma zastosowanie, z wyjątkiem opcji umieszczenia usługi Azure Firewall przed usługą Azure Front Door.

Jednym ze scenariuszy jest użycie usługi Azure Firewall przed usługą Application Gateway w sieci wirtualnej. Usługa Application Gateway wprowadza nagłówek X-Forwarded-For z adresem IP wystąpienia zapory, a nie adresem IP klienta. Obejściem jest użycie usługi Azure Front Door przed zaporą w celu wstrzyknięcia adresu IP klienta jako nagłówka X-Forwarded-For przed wejściem ruchu do sieci wirtualnej i dotarciem do usługi Azure Firewall. Możesz również zabezpieczyć źródło za pomocą usługi Azure Private Link w usłudze Azure Front Door Premium.

Aby uzyskać więcej informacji na temat różnic między dwiema usługami lub kiedy należy ich używać, zobacz często zadawane pytania dotyczące usługi Azure Front Door.

Inne urządzenia WUS

Produkty firmy Microsoft nie są jedynym wyborem do zaimplementowania zapory aplikacji internetowej ani funkcji zapory nowej generacji na platformie Azure. Szeroki zakres partnerów firmy Microsoft zapewnia urządzenia WUS. Pojęcia i projekty są zasadniczo takie same jak w tym artykule, ale istnieją pewne ważne zagadnienia:

• Wirtualne urządzenia WUS partnera na potrzeby zapory nowej generacji mogą zapewnić większą kontrolę i elastyczność konfiguracji translatora adresów sieciowych, których usługa Azure Firewall nie obsługuje. Przykłady obejmują DNAT ze środowiska lokalnego lub DNAT z Internetu bez protokołu SNAT.

• Zarządzane przez platformę Azure urządzenia WUS, takie jak Application Gateway i Azure Firewall, zmniejszają złożoność w porównaniu z urządzeniami WUS, w których użytkownicy muszą obsługiwać skalowalność i odporność na wiele urządzeń.

• W przypadku korzystania z urządzeń WUS na platformie Azure użyj aktywne-aktywne i automatyczne skalowanie konfiguracji, aby te urządzenia nie były wąskim gardłem dla aplikacji działających w sieci wirtualnej.

Współpracowników

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Jose Moreno | Główny inżynier klienta

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Dowiedz się więcej o technologiach składników:

• Co to jest usługa Application Gateway?
• Co to jest usługa Azure Firewall?
• Co to jest usługa Azure Front Door?
• Usługa AKS
• Co to jest sieć wirtualna?
• Co to jest zapora aplikacji internetowej?
• Architektura linii bazowej dla klastra usługi AKS

Powiązane zasoby

Zapoznaj się z powiązanymi architekturami:

• Implementowanie bezpiecznej sieci hybrydowej
• bezpiecznie zarządzane aplikacje internetowe
• wielodostępne oprogramowanie jako usługa na platformie Azure
• wdrażanie Enterprise przy użyciu środowiska App Service Environment
• wdrażanie w przedsiębiorstwie o wysokiej dostępności przy użyciu środowiska App Service Environment

Aby ułatwić zabezpieczanie obciążeń aplikacji platformy Azure, należy użyć środków ochronnych, takich jak uwierzytelnianie i szyfrowanie w samych aplikacjach. Warstwy zabezpieczeń można dodawać do sieci wirtualnych hostujących aplikacje. Te warstwy zabezpieczeń ułatwiają ochronę przepływów przychodzących aplikacji przed niezamierzonym użyciem. Ograniczają one również przepływy wychodzące do Internetu tylko do tych punktów końcowych, których wymaga aplikacja. W tym artykule opisano usług zabezpieczeń usługi Azure Virtual Network, takich jak Azure DDoS Protection, Azure Firewall i Azure Application Gateway. Opisano również, kiedy należy używać każdej usługi i opcji projektowania sieci, które je łączą.

• usługi DDoS Protection, w połączeniu z najlepszymi rozwiązaniami dotyczącymi projektowania aplikacji, udostępnia ulepszone funkcje ograniczania ryzyka ataków DDoS, które zwiększają ochronę przed atakami DDoS. Należy włączyć ochronę przed atakami DDoS w każdej sieci wirtualnej obwodowej.

• usługa Azure Firewall to zarządzana zapora nowej generacji, która zapewnia funkcji translatora adresów sieciowych (NAT). Usługa Azure Firewall filtruje pakiety na podstawie adresów IP i portów protokołu TCP (Transmission Control Protocol) lub UDP (User Datagram Protocol). Może filtrować ruch przy użyciu atrybutów opartych na aplikacji, takich jak HTTP(S) i SQL. Usługa Azure Firewall stosuje również analizę zagrożeń firmy Microsoft, aby ułatwić identyfikowanie złośliwych adresów IP. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Firewall.

• usługa Azure Firewall — wersja Premium obejmuje wszystkie funkcje usługi Azure Firewall Standard, a także funkcje takie jak inspekcja protokołu TLS (Transport Layer Security) i system wykrywania i zapobiegania włamaniom (IDPS).

• Application Gateway jest zarządzanym modułem równoważenia obciążenia ruchu internetowego i pełnym zwrotnym serwerem proxy HTTP(S), który może wykonywać szyfrowanie i odszyfrowywanie protokołu Secure Socket Layer (SSL). Usługa Application Gateway zachowuje oryginalny adres IP klienta w nagłówku http X-Forwarded-For. Usługa Application Gateway używa również usługi Azure Web Application Firewall do sprawdzania ruchu internetowego i wykrywania ataków w warstwie HTTP. Aby uzyskać więcej informacji, zobacz dokumentację usługi Application Gateway.

• zapory aplikacji internetowej jest opcjonalnym dodatkiem do usługi Application Gateway. Sprawdza żądania HTTP i zapobiega atakom warstwy internetowej, takim jak wstrzyknięcie kodu SQL i wykonywanie skryptów między witrynami. Aby uzyskać więcej informacji, zobacz dokumentację Web Application Firewall.

Te usługi platformy Azure uzupełniają się wzajemnie. W zależności od potrzeb użycie jednej usługi może lepiej odpowiadać twoim obciążeniom. Można jednak używać tych usług razem, aby zapewnić optymalną ochronę zarówno w warstwach sieci, jak i aplikacji. Użyj następującego drzewa decyzyjnego i przykładów w tym artykule, aby wybrać najlepszą opcję zabezpieczeń dla sieci wirtualnej aplikacji.

Usługi Azure Firewall i Application Gateway używają różnych technologii, aby zabezpieczyć różne typy przepływów danych.

Przepływ aplikacji	Można filtrować za pomocą usługi Azure Firewall	Można filtrować według zapory aplikacji internetowej w usłudze Application Gateway
Ruch HTTP (S) z lokalnego lub internetowego do platformy Azure (ruch przychodzący)	Tak	Tak
Ruch HTTP(S) z platformy Azure do lokalnego lub internetowego (wychodzącego)	Tak	Nie
Ruch inny niż HTTP (ruch przychodzący lub wychodzący)	Tak	Nie

Projekt może się różnić w zależności od wymaganego przepływu sieci. Na poniższym diagramie przedstawiono uproszczone drzewo decyzyjne, które ułatwia wybranie zalecanego podejścia dla aplikacji. Wybór zależy od tego, czy aplikacja jest publikowana za pośrednictwem protokołu HTTP,czy innego protokołu.

W tym artykule opisano szeroko zalecane projekty pokazane na wykresie blokowym i projektach dostosowanych do mniej typowych scenariuszy:

• usługi Azure Firewall tylko: Użyj tego projektu, jeśli w sieci wirtualnej nie ma żadnych aplikacji internetowych. Steruje zarówno ruchem przychodzącym do aplikacji, jak i ruchem wychodzącym.

• usługi Application Gateway tylko: Użyj tego projektu, gdy tylko aplikacje internetowe znajdują się w sieci wirtualnej i sieciowych grup zabezpieczeń (NSG) zapewniają wystarczające filtrowanie danych wyjściowych. Usługa Azure Firewall udostępnia funkcje, które mogą pomóc w zapobieganiu kilku scenariuszom ataku, takim jak eksfiltracja danych i dostawcy tożsamości. W związku z tym projekt tylko w usłudze Application Gateway nie jest zwykle zalecany, więc nie jest uwzględniony na poprzednim wykresie blokowym.

• usługi Azure Firewall i Application Gateway równolegle: Użyj tego projektu, jeśli chcesz, aby usługa Application Gateway chroniła aplikacje HTTP przed atakami internetowymi i usługą Azure Firewall w celu ochrony wszystkich innych obciążeń i filtrowania ruchu wychodzącego. Usługa Azure Firewall i usługa Application Gateway równolegle to typowy projekt.

• Application Gateway przed usługą Azure Firewall: Użyj tego projektu, jeśli chcesz, aby usługa Azure Firewall sprawdzała cały ruch, zaporę aplikacji internetowej w celu ochrony ruchu internetowego oraz aplikację w celu zidentyfikowania źródłowego adresu IP klienta. W przypadku inspekcji usługi Azure Firewall Premium i TLS ten projekt obsługuje również kompleksowe scenariusze ssl.

• usługi Azure Firewall przed usługą Application Gateway: Użyj tego projektu, jeśli chcesz, aby usługa Azure Firewall sprawdzała i filtrować ruch przed dotarciem do usługi Application Gateway. Ponieważ usługa Azure Firewall nie odszyfrowuje ruchu HTTPS, jej dodatkowe funkcje w usłudze Application Gateway są ograniczone. Ten scenariusz nie jest udokumentowany na poprzednim wykresie blokowym.

Odmiany tych podstawowych projektów zostały opisane w dalszej części tego artykułu i obejmują:

• klientów aplikacji lokalnych.
• sieci piasty i szprych.
• implementacje usługi Azure Kubernetes Service (AKS).

Możesz dodać inne usługi zwrotnego serwera proxy, takie jak brama usługi Azure API Management lub azure Front Door. Możesz też zastąpić zasoby platformy Azure wirtualnymi urządzeniami sieciowymi (WUS) innej firmy niż Microsoft.

Nuta

W poniższych scenariuszach maszyna wirtualna platformy Azure jest używana jako przykład obciążenia aplikacji internetowej. Te scenariusze są również prawidłowe dla innych typów obciążeń, takich jak kontenery lub usługa Azure Web Apps. W przypadku konfiguracji obejmujących prywatne punkty końcowe należy wziąć pod uwagę zalecenia w scenariuszach usługi Azure Firewall w celu sprawdzenia ruchu kierowanego do prywatnego punktu końcowego.

Projekt tylko w usłudze Azure Firewall

Jeśli w sieci wirtualnej nie ma żadnych obciążeń internetowych, które mogą korzystać z zapory aplikacji internetowej, możesz użyć projektu tylko usługi Azure Firewall. Projekt w tym przykładzie jest prosty, ale możesz przejrzeć przepływ pakietów, aby lepiej zrozumieć bardziej złożone projekty. W tym projekcie cały ruch przychodzący jest wysyłany do usługi Azure Firewall za pośrednictwem tras zdefiniowanych przez użytkownika (UDR) dla połączeń lokalnych lub innych sieci wirtualnych platformy Azure. Adres jest adresowany do publicznego adresu IP usługi Azure Firewall dla połączeń z publicznego Internetu, jak pokazano na poniższym diagramie. Trasy zdefiniowane przez użytkownika kierują ruch wychodzący z sieci wirtualnych platformy Azure do usługi Azure Firewall, jak pokazano w poniższym oknie dialogowym.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	N/A	Tak
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	N/A	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	N/A	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	N/A	Tak

Usługa Azure Firewall nie sprawdza ruchu przychodzącego HTTP(S). Można jednak zastosować reguły warstwy 3 i warstwy 4 oraz reguły aplikacji oparte na w pełni kwalifikowanej nazwy domeny (FQDN). Usługa Azure Firewall sprawdza wychodzący ruch HTTP(S) w zależności od warstwy usługi Azure Firewall i określa, czy skonfigurować inspekcję protokołu TLS:

• Usługa Azure Firewall Standard sprawdza tylko atrybuty warstwy 3 i 4 pakietów w regułach sieciowych oraz nagłówek HTTP hosta w regułach aplikacji.

• Usługa Azure Firewall Premium dodaje funkcje, takie jak inspekcja innych nagłówków HTTP (takich jak agent użytkownika) i włączanie inspekcji protokołu TLS w celu dokładniejszej analizy pakietów. Jednak usługa Azure Firewall nie jest taka sama jak zapora aplikacji internetowej. Jeśli masz obciążenia internetowe w sieci wirtualnej, zalecamy użycie zapory aplikacji internetowej.

Poniższy przykładowy przewodnik po pakiecie pokazuje, jak klient uzyskuje dostęp do aplikacji hostowanej przez maszynę wirtualną z publicznego Internetu. Diagram zawiera tylko jedną maszynę wirtualną dla uproszczenia. W celu zwiększenia dostępności i skalowalności istnieje wiele wystąpień aplikacji za modułem równoważenia obciążenia. W tym projekcie usługa Azure Firewall sprawdza połączenia przychodzące z publicznego Internetu i połączeń wychodzących z maszyny wirtualnej podsieci aplikacji przy użyciu trasy zdefiniowanej przez użytkownika.

• W tym przykładzie usługa Azure Firewall automatycznie wdraża kilka wystąpień z adresem IP frontonu 192.168.100.4 i adresami wewnętrznymi w zakresie 192.168.100.0/26. Zwykle te wystąpienia nie są widoczne dla administratora platformy Azure. Jednak ich świadomość może być przydatna do rozwiązywania problemów z siecią.

• Jeśli ruch pochodzi z lokalnej wirtualnej sieci prywatnej (VPN) lub bramy usługi Azure ExpressRoute zamiast z Internetu, klient uruchamia połączenie z adresem IP maszyny wirtualnej. Nie uruchamia połączenia z adresem IP zapory, a zapora domyślnie nie wykonuje źródłowego translatora adresów sieciowych.

Architektura

Na poniższym diagramie przedstawiono przepływ ruchu i przyjęto założenie, że adres IP wystąpienia jest 192.168.100.7.

Przepływ pracy

1. Klient uruchamia połączenie z publicznym adresem IP usługi Azure Firewall.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AzFwPIP

2. Żądanie do publicznego adresu IP usługi Azure Firewall jest dystrybuowane do wystąpienia zaplecza zapory, które jest 192.168.100.7 w tym przykładzie. Reguła translacji docelowych adresów sieciowych (DNAT) usługi Azure Firewall tłumaczy docelowy adres IP na adres IP aplikacji wewnątrz sieci wirtualnej. Usługa Azure Firewall implementuje również translacji adresów sieciowych (SNAT) w pakiecie, jeśli używa DNAT. Aby uzyskać więcej informacji, zobacz znane problemy z usługą Azure Firewall. Maszyna wirtualna widzi następujące adresy IP w pakiecie przychodzącym:

   • Źródłowy adres IP: 192.168.100.7
   • Docelowy adres IP: 192.168.1.4

3. Maszyna wirtualna odpowiada na żądanie aplikacji, co odwraca zarówno źródłowe, jak i docelowe adresy IP. Przepływ przychodzący nie wymaga trasy zdefiniowanej przez użytkownika, ponieważ źródłowy adres IP jest adresem IP usługi Azure Firewall. Trasa zdefiniowana przez użytkownika na diagramie dla 0.0.0.0/0 dotyczy połączeń wychodzących w celu zapewnienia, że pakiety do publicznego Internetu przechodzą przez usługę Azure Firewall.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.100.7

4. Usługa Azure Firewall cofa operacje SNAT i DNAT i dostarcza odpowiedź na klienta.

   • Źródłowy adres IP: AzFwPIP
   • Docelowy adres IP: ClientPIP

Projekt tylko w usłudze Application Gateway

W tym projekcie opisano scenariusz, w którym istnieją tylko aplikacje internetowe w sieci wirtualnej, a inspekcja ruchu wychodzącego za pomocą sieciowych grup zabezpieczeń jest wystarczająca do ochrony przepływów wychodzących do Internetu.

Nuta

Nie zalecamy tego projektu, ponieważ używanie usługi Azure Firewall do kontrolowania przepływów wychodzących zamiast polegania wyłącznie na sieciowych grupach zabezpieczeń pomaga zapobiegać scenariuszom ataku, takim jak eksfiltracja danych. Za pomocą usługi Azure Firewall możesz zapewnić, że obciążenia wysyłają tylko dane do zatwierdzonej listy adresów URL. Ponadto sieciowe grupy zabezpieczeń działają tylko w warstwie 3 i warstwie 4 i nie obsługują nazw FQDN.

Kluczową różnicą w stosunku do poprzedniego projektu usługi Azure Firewall jest to, że usługa Application Gateway nie służy jako urządzenie routingu z translatorem adresów sieciowych. Zamiast tego działa jako pełny zwrotny serwer proxy aplikacji. Takie podejście oznacza, że usługa Application Gateway zatrzymuje sesję internetową od klienta i ustanawia oddzielną sesję z jednym z serwerów zaplecza. Przychodzące połączenia HTTP (S) z Internetu są wysyłane do publicznego adresu IP usługi Application Gateway, a połączenia z platformy Azure lub lokalnie używają prywatnego adresu IP bramy. Ruch powrotny z maszyn wirtualnych platformy Azure jest zgodny ze standardowym routingiem sieci wirtualnej z powrotem do usługi Application Gateway. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu. Wychodzące przepływy internetowe z maszyn wirtualnych platformy Azure przechodzą bezpośrednio do Internetu.

Poniższa tabela zawiera podsumowanie przepływów ruchu.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	N/A
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	N/A
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	N/A
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	N/A

Architektura

Poniższy przykład przewodnika po pakiecie pokazuje, jak klient uzyskuje dostęp do aplikacji hostowanej na maszynie wirtualnej z publicznego Internetu.

Przepływ pracy

1. Klient uruchamia połączenie z publicznym adresem IP usługi Application Gateway.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AppGwPIP

2. Żądanie do publicznego adresu IP usługi Application Gateway jest dystrybuowane do wystąpienia zaplecza bramy, które jest 192.168.200.7 w tym przykładzie. Wystąpienie usługi Application Gateway, które odbiera żądanie, zatrzymuje połączenie z klientem i ustanawia nowe połączenie z jednym z zaplecza. Zaplecze widzi wystąpienie usługi Application Gateway jako źródłowy adres IP. Usługa Application Gateway wstawia nagłówek HTTP X-Forwarded-For z adresem IP oryginalnego klienta.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Application Gateway: 192.168.200.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: ClientPIP

3. Maszyna wirtualna odpowiada na żądanie aplikacji i odwraca zarówno źródłowe, jak i docelowe adresy IP. Maszyna wirtualna może nawiązać połączenie z usługą Application Gateway, więc nie wymaga trasy zdefiniowanej przez użytkownika.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

4. Wystąpienie usługi Application Gateway odpowiada na klienta.

   • Źródłowy adres IP: AppGwPIP
   • Docelowy adres IP: ClientPIP

Usługa Application Gateway dodaje metadane do nagłówków HTTP pakietu, takich jak nagłówek X-Forwarded-For zawierający oryginalny adres IP klienta. Niektóre serwery aplikacji wymagają źródłowego adresu IP klienta do obsługi zawartości specyficznej dla lokalizacji geograficznej lub rejestrowania. Aby uzyskać więcej informacji, zobacz Jak działa brama aplikacji.

• W tym przykładzie adres IP 192.168.200.7 jest jednym z wystąpień wdrożonych automatycznie przez usługę Application Gateway. Ma wewnętrzny, prywatny adres IP frontonu 192.168.200.4. Te poszczególne wystąpienia są zwykle niewidoczne dla administratora platformy Azure. Jednak zauważenie różnicy może być przydatne, na przykład podczas rozwiązywania problemów z siecią.

• Przepływ jest podobny, jeśli klient pochodzi z sieci lokalnej za pośrednictwem sieci VPN lub bramy usługi ExpressRoute. Różnica polega na tym, że klient uzyskuje dostęp do prywatnego adresu IP usługi Application Gateway zamiast publicznego adresu IP.

Nuta

Aby uzyskać więcej informacji na temat nagłówka X-Forwarded-For i sposobu zachowania nazwy hosta w żądaniu, zobacz Zachowaj oryginalny host HTTP.

Równoległe projektowanie usług Azure Firewall i Application Gateway

Ze względu na prostotę i elastyczność, często najlepiej jest uruchamiać usługę Application Gateway i usługę Azure Firewall równolegle.

Zaimplementuj ten projekt, jeśli w sieci wirtualnej znajdują się obciążenia internetowe i inne niż internetowe. Zapora aplikacji internetowej w usłudze Application Gateway pomaga chronić ruch przychodzący do obciążeń internetowych. Usługa Azure Firewall sprawdza ruch przychodzący dla innych aplikacji. Usługa Azure Firewall obejmuje przepływy wychodzące z obu typów obciążeń.

Przychodzące połączenia HTTP (S) z Internetu powinny być wysyłane do publicznego adresu IP usługi Application Gateway. Połączenia HTTP(S) z platformy Azure lub środowiska lokalnego powinny być wysyłane do jego prywatnego adresu IP. Routing w standardowej sieci wirtualnej wysyła pakiety z usługi Application Gateway do docelowych maszyn wirtualnych i z docelowych maszyn wirtualnych z powrotem do usługi Application Gateway. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu.

W przypadku połączeń przychodzących innych niż HTTP ruch powinien być kierowany do publicznego adresu IP usługi Azure Firewall, jeśli pochodzi z publicznego Internetu. Ruch powinien być wysyłany za pośrednictwem usługi Azure Firewall przez trasy zdefiniowane przez użytkownika, jeśli pochodzi z innych sieci wirtualnych platformy Azure lub sieci lokalnych. Wszystkie przepływy wychodzące z maszyn wirtualnych platformy Azure są przekazywane do usługi Azure Firewall przez trasy zdefiniowane przez użytkownika.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	Nie
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak

Ten projekt zapewnia znacznie bardziej szczegółowe filtrowanie ruchu wychodzącego niż wyłącznie przy użyciu sieciowych grup zabezpieczeń. Jeśli na przykład aplikacje potrzebują łączności z określonym kontem usługi Azure Storage, możesz użyć filtrów opartych na nazwach FQDN. W przypadku filtrów opartych na nazwach FQDN aplikacje nie wysyłają danych do nieautoryzowanych kont magazynu. Jeśli używasz tylko sieciowych grup zabezpieczeń, nie możesz zapobiec temu scenariuszowi. Ten projekt jest często używany, gdy ruch wychodzący wymaga filtrowania opartego na nazwie FQDN. Jednym ze scenariuszy jest to, że ograniczyć ruch wychodzący z klastra usługi AKS.

Architektury

Na poniższym diagramie przedstawiono przepływ ruchu dla przychodzących połączeń HTTP(S) z klienta zewnętrznego.

Na poniższym diagramie przedstawiono przepływ ruchu dla połączeń wychodzących z maszyn wirtualnych sieciowych do Internetu. Jednym z przykładów jest nawiązanie połączenia z systemami zaplecza lub pobranie aktualizacji systemu operacyjnego.

Kroki przepływu pakietów dla każdej usługi są takie same jak w poprzednich autonomicznych opcjach projektowania.

Usługa Application Gateway przed projektem usługi Azure Firewall

Ten projekt wyjaśniono bardziej szczegółowo w sieci zerowej zaufania dla aplikacji internetowych za pomocą usługi Azure Firewall i usługi Application Gateway. Ten artykuł koncentruje się na porównaniu z innymi opcjami projektowania. W tej topologii przychodzący ruch internetowy przechodzi zarówno przez usługę Azure Firewall, jak i zaporę aplikacji internetowej. Zapora aplikacji internetowej zapewnia ochronę w warstwie aplikacji internetowej. Usługa Azure Firewall służy jako centralny punkt rejestrowania i kontroli oraz sprawdza ruch między usługą Application Gateway i serwerami zaplecza. W tym projekcie usługa Application Gateway i usługa Azure Firewall nie znajdują się równolegle, ale znajdują się przed sobą.

W przypadku usługi Azure Firewall w wersji Premiumten projekt może obsługiwać kompleksowe scenariusze, w których usługa Azure Firewall stosuje inspekcję protokołu TLS w celu przeprowadzania idPS na zaszyfrowanym ruchu między usługą Application Gateway a zapleczem internetowym.

Ten projekt jest odpowiedni dla aplikacji, które muszą identyfikować przychodzące źródłowe adresy IP klienta. Na przykład może służyć do udostępniania zawartości specyficznej dla lokalizacji geograficznej lub rejestrowania. Usługa Application Gateway przed projektem usługi Azure Firewall przechwytuje źródłowy adres IP pakietu przychodzącego w nagłówku X-Forwarded-For, aby serwer internetowy mógł zobaczyć oryginalny adres IP w tym nagłówku. Aby uzyskać więcej informacji, zobacz Jak działa brama aplikacji.

Przychodzące połączenia HTTP (S) z Internetu muszą być wysyłane do publicznego adresu IP usługi Application Gateway. Połączenia HTTP(S) z platformy Azure lub środowiska lokalnego powinny być wysyłane do jego prywatnego adresu IP. W usłudze Application Gateway trasy zdefiniowane przez użytkownika zapewniają, że pakiety są kierowane przez usługę Azure Firewall. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu.

W przypadku połączeń przychodzących innych niż HTTP ruch powinien być kierowany do publicznego adresu IP usługi Azure Firewall, jeśli pochodzi z publicznego Internetu. Ruch powinien być wysyłany za pośrednictwem usługi Azure Firewall przez trasy zdefiniowane przez użytkownika, jeśli pochodzi z innych sieci wirtualnych platformy Azure lub sieci lokalnych. Wszystkie przepływy wychodzące z maszyn wirtualnych platformy Azure są przekazywane do usługi Azure Firewall przez trasy zdefiniowane przez użytkownika.

Ważnym aspektem tego projektu jest to, że usługa Azure Firewall Premium widzi ruch ze źródłowym adresem IP z podsieci usługi Application Gateway. Jeśli ta podsieć jest skonfigurowana przy użyciu prywatnego adresu IP (w 10.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12lub 100.64.0.0/10), usługa Azure Firewall Premium traktuje ruch z usługi Application Gateway jako wewnętrzny i nie stosuje reguł IDPS dla ruchu przychodzącego. W związku z tym zalecamy zmodyfikowanie prywatnych prefiksów IDPS w zasadach usługi Azure Firewall. Ta modyfikacja gwarantuje, że podsieć usługi Application Gateway nie jest uznawana za źródło wewnętrzne, które umożliwia stosowanie podpisów IDPS dla ruchu przychodzącego i wychodzącego. Więcej informacji na temat wskazówek reguł idPS usługi Azure Firewall i prywatnych prefiksów adresów IP dla dostawcy tożsamości można znaleźć w reguł idPS usługi Azure Firewall.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	Tak
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak

W przypadku ruchu internetowego ze środowiska lokalnego lub z Internetu do platformy Azure usługa Azure Firewall sprawdza przepływy dozwolone przez zaporę aplikacji internetowej. W zależności od tego, czy usługa Application Gateway szyfruje ruch zaplecza, który jest ruchem z usługi Application Gateway do serwerów aplikacji, mogą wystąpić różne scenariusze:

• Usługa Application Gateway szyfruje ruch, postępując zgodnie z zasadami zerowego zaufania, takimi jak kompleksowe szyfrowanie TLS, a usługa Azure Firewall odbiera zaszyfrowany ruch. Usługa Azure Firewall w warstwie Standardowa może nadal stosować reguły inspekcji, takie jak filtrowanie warstwy 3 i 4 w regułach sieciowych lub filtrowanie nazw FQDN w regułach aplikacji przy użyciu nagłówka SNI (TLS Server Name Indication). Azure Firewall Premium zapewnia lepszy wgląd w inspekcję protokołu TLS, taką jak filtrowanie oparte na adresach URL.

• Jeśli usługa Application Gateway wysyła niezaszyfrowany ruch do serwerów aplikacji, usługa Azure Firewall widzi ruch przychodzący w postaci zwykłego tekstu. Inspekcja protokołu TLS nie jest wymagana w usłudze Azure Firewall.

• Jeśli usługa IDPS jest włączona w usłudze Azure Firewall, sprawdza, czy nagłówek hosta HTTP jest zgodny z docelowym adresem IP. Aby przeprowadzić tę weryfikację, potrzebuje rozpoznawania nazw dla nazwy FQDN określonej w nagłówku hosta. To rozpoznawanie nazw można wykonać przy użyciu stref prywatnych usługi Azure DNS i domyślnych ustawień DNS usługi Azure Firewall. Można go również osiągnąć za pomocą niestandardowych serwerów DNS, które należy skonfigurować w ustawieniach usługi Azure Firewall. Jeśli nie masz dostępu administracyjnego do sieci wirtualnej, w której wdrożono usługę Azure Firewall, jedyną opcją jest ta ostatnia metoda. Jednym z przykładów jest użycie wystąpień usługi Azure Firewall wdrożonych w koncentratorach zabezpieczonych za pomocą usługi Azure Virtual WAN.

Architektura

W przypadku pozostałych przepływów, które obejmują ruch przychodzący bez protokołu HTTP i dowolny ruch wychodzący, usługa Azure Firewall zapewnia inspekcję dostawcy tożsamości i inspekcję protokołu TLS tam, gdzie jest to odpowiednie. Zapewnia również filtrowanie oparte na nazwach FQDN w regułach sieciowych na podstawie systemu DNS.

Przepływ pracy

Ruch sieciowy z publicznego Internetu jest zgodny z tym przepływem:

1. Klient uruchamia połączenie z publicznym adresem IP usługi Application Gateway.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AppGwPIP

2. Żądanie do publicznego adresu IP usługi Application Gateway jest dystrybuowane do wystąpienia zaplecza bramy, które jest 192.168.200.7 w tym przykładzie. Wystąpienie usługi Application Gateway zatrzymuje połączenie z klientem i ustanawia nowe połączenie z jednym z zaplecza. Trasa zdefiniowana przez użytkownika do 192.168.1.0/24 w podsieci usługi Application Gateway przekazuje pakiet do usługi Azure Firewall i zachowuje docelowy adres IP aplikacji internetowej.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Application Gateway: 192.168.200.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: ClientPIP

3. Usługa Azure Firewall nie stosuje protokołu SNAT do ruchu, ponieważ ruch przechodzi do prywatnego adresu IP. Przekazuje ruch do maszyny wirtualnej aplikacji, jeśli zezwalają na to reguły. Aby uzyskać więcej informacji, zobacz Usługa SNAT dla zakresów prywatnych adresów IP w usłudze Azure Firewall. Jeśli jednak ruch osiągnie regułę aplikacji w zaporze, obciążenie zobaczy źródłowy adres IP określonego wystąpienia zapory, które przetworzyło pakiet, ponieważ serwer proxy usługi Azure Firewall nawiązał połączenie.

   • Źródłowy adres IP, jeśli ruch jest dozwolony przez regułę sieciową usługi Azure Firewall i jest prywatnym adresem IP jednego z wystąpień usługi Application Gateway: 192.168.200.7
   • Źródłowy adres IP, jeśli ruch jest dozwolony przez regułę aplikacji usługi Azure Firewall i jest prywatnym adresem IP jednego z wystąpień usługi Azure Firewall: 192.168.100.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: ClientPIP

4. Maszyna wirtualna odpowiada na żądanie, które odwraca zarówno źródłowe, jak i docelowe adresy IP. Trasa zdefiniowana przez użytkownika do 192.168.200.0/24 przechwytuje pakiet wysyłany z powrotem do usługi Application Gateway, przekierowuje go do usługi Azure Firewall i zachowuje docelowy adres IP w kierunku usługi Application Gateway.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

5. Ponownie usługa Azure Firewall nie stosuje protokołu SNAT do ruchu, ponieważ przechodzi do prywatnego adresu IP i przekazuje ruch do usługi Application Gateway.

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

6. Wystąpienie usługi Application Gateway odpowiada na klienta.

   • Źródłowy adres IP: AppGwPIP
   • Docelowy adres IP: ClientPIP

Przepływy wychodzące z maszyn wirtualnych do publicznego Internetu przechodzą przez usługę Azure Firewall, którą zdefiniowano przez trasę zdefiniowaną przez trasę zdefiniowaną przez 0.0.0.0/0 użytkownika.

Jako odmiana tego projektu można skonfigurować prywatne DNAT w usłudze Azure Firewall, aby obciążenie aplikacji wyświetlało adresy IP wystąpień usługi Azure Firewall jako źródła, a nie są wymagane żadne trasy zdefiniowane przez użytkownika. Źródłowy adres IP klientów aplikacji jest już zachowywany w nagłówku HTTP X-Forwarded-For przez usługę Application Gateway. Jeśli więc usługa Azure Firewall stosuje dnaT do ruchu, żadne informacje nie zostaną utracone. Aby uzyskać więcej informacji, zobacz Filter inbound Internet or intranet traffic with Azure Firewall policy DNAT by using the Azure Portal.

Usługa Azure Firewall przed projektem usługi Application Gateway

Ten projekt umożliwia usłudze Azure Firewall filtrowanie i odrzucanie złośliwego ruchu przed dotarciem do usługi Application Gateway. Może na przykład stosować funkcje, takie jak filtrowanie oparte na inteligencji zagrożeń. Kolejną korzyścią jest to, że aplikacja pobiera ten sam publiczny adres IP zarówno dla ruchu przychodzącego, jak i wychodzącego, niezależnie od protokołu. Istnieją trzy tryby, w których teoretycznie można skonfigurować usługę Azure Firewall:

• azure Firewall z regułami DNAT: usługa Azure Firewall zamienia tylko adresy IP w warstwie adresów IP, ale nie przetwarza ładunku. W związku z tym nie zmienia żadnego nagłówka HTTP.

• usługę Azure Firewall z wyłączonymi regułami aplikacji i inspekcją protokołu TLS: usługa Azure Firewall może przyjrzeć się nagłówkowi SNI w protokole TLS, ale nie odszyfruje go. Nowe połączenie TCP jest tworzone z zapory do następnego przeskoku. W tym przykładzie jest to usługa Application Gateway.

• usługę Azure Firewall z włączonymi regułami aplikacji i inspekcją protokołu TLS: usługa Azure Firewall analizuje zawartość pakietu i odszyfrowuje je. Służy jako serwer proxy HTTP i może ustawić nagłówki HTTP X-Forwarded-For, aby zachować adres IP. Jednak przedstawia on klientowi certyfikat wygenerowany samodzielnie. W przypadku aplikacji internetowych używanie certyfikatu generowanego samodzielnie nie jest opcją, ponieważ do klientów aplikacji jest wysyłane ostrzeżenie o zabezpieczeniach z przeglądarki.

W dwóch pierwszych opcjach, które są jedynymi prawidłowymi opcjami dla aplikacji internetowych, usługa Azure Firewall stosuje uwierzytelnianie SNAT do ruchu przychodzącego bez ustawiania nagłówka X-Forwarded-For. W związku z tym aplikacja nie może zobaczyć oryginalnego adresu IP żądań HTTP. W przypadku zadań administracyjnych, takich jak rozwiązywanie problemów, można uzyskać rzeczywisty adres IP klienta dla określonego połączenia, korelując go z dziennikami SNAT usługi Azure Firewall.

Korzyści wynikające z tego scenariusza są ograniczone, ponieważ jeśli nie korzystasz z inspekcji protokołu TLS i przedstawiasz samodzielnie wygenerowane certyfikaty klientom, usługa Azure Firewall widzi tylko zaszyfrowany ruch kierowany do usługi Application Gateway. Ten scenariusz jest zwykle możliwy tylko w przypadku aplikacji wewnętrznych. Jednak mogą wystąpić scenariusze, w których ten projekt jest preferowany. Jednym ze scenariuszy jest to, że inna zapora aplikacji internetowej istnieje wcześniej w sieci (na przykład z usługi Azure Front Door), która może przechwytywać oryginalny źródłowy adres IP w nagłówku http X-Forwarded-For. Ten projekt może być również preferowany, jeśli wymagana jest wiele publicznych adresów IP, ponieważ usługa Application Gateway obsługuje jeden adres IP.

Przepływy przychodzące HTTP(S) z publicznego Internetu powinny być kierowane do publicznego adresu IP usługi Azure Firewall. Usługa Azure Firewall będzie dnat i SNAT pakiety do prywatnego adresu IP usługi Application Gateway. Z innych sieci wirtualnych platformy Azure lub sieci lokalnych ruch HTTP(S) powinien być wysyłany do prywatnego adresu IP usługi Application Gateway i przekazywany za pośrednictwem usługi Azure Firewall z trasami zdefiniowanymi przez użytkownika. Standardowy routing sieci wirtualnej zapewnia, że ruch powrotny z maszyn wirtualnych platformy Azure wraca do usługi Application Gateway i z usługi Application Gateway do usługi Azure Firewall, jeśli zostały użyte reguły DNAT. W przypadku ruchu ze środowiska lokalnego lub platformy Azure użyj tras zdefiniowanych przez użytkownika w podsieci usługi Application Gateway. Aby uzyskać więcej informacji, zobacz przewodnik po pakiecie w dalszej części tego artykułu. Cały ruch wychodzący z maszyn wirtualnych platformy Azure do Internetu jest wysyłany przez usługę Azure Firewall przez trasy zdefiniowane przez użytkownika.

Poniższa tabela zawiera podsumowanie przepływów ruchu dla tego scenariusza.

Płynąć	Przechodzi przez usługę Application Gateway/Zaporę aplikacji internetowej	Przechodzi przez usługę Azure Firewall
Ruch HTTP (S) z Internetu lub lokalnie do platformy Azure	Tak	Tak
Ruch HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak
Ruch inny niż HTTP (S) z Internetu lub lokalnie do platformy Azure	Nie	Tak
Ruch inny niż HTTP (S) z platformy Azure do Internetu lub lokalnie	Nie	Tak

W przypadku ruchu przychodzącego HTTP(S) usługa Azure Firewall zwykle nie odszyfrowuje ruchu. Zamiast tego stosuje zasady idPS, które nie wymagają inspekcji protokołu TLS, takich jak filtrowanie oparte na adresach IP lub używanie nagłówków HTTP.

Architektura

Aplikacja nie widzi oryginalnego źródłowego adresu IP ruchu internetowego. Usługa Azure Firewall stosuje protokół SNAT do pakietów w miarę ich ściągniania do sieci wirtualnej. Aby uniknąć tego problemu, użyj usługi Azure Front Door przed zaporą. Usługa Azure Front Door wprowadza adres IP klienta jako nagłówek HTTP przed wejściem do sieci wirtualnej platformy Azure.

Przepływ pracy

Ruch sieciowy z publicznego Internetu jest zgodny z tym przepływem:

1. Klient uruchamia połączenie z publicznym adresem IP usługi Azure Firewall.

   • Źródłowy adres IP: ClientPIP
   • Docelowy adres IP: AzFWPIP

2. Żądanie do publicznego adresu IP usługi Azure Firewall jest dystrybuowane do wystąpienia zaplecza zapory, które jest 192.168.100.7 w tym przykładzie. Usługa Azure Firewall stosuje dnaT do portu internetowego, zwykle TCP 443, do prywatnego adresu IP wystąpienia usługi Application Gateway. Usługa Azure Firewall stosuje również protokół SNAT podczas wykonywania funkcji DNAT. Aby uzyskać więcej informacji, zobacz znane problemy z usługą Azure Firewall.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Azure Firewall: 192.168.100.7
   • Docelowy adres IP: 192.168.200.4

3. Usługa Application Gateway ustanawia nową sesję między wystąpieniem, które obsługuje połączenie i jeden z serwerów zaplecza. Oryginalny adres IP klienta nie znajduje się w pakiecie.

   • Źródłowy adres IP, który jest prywatnym adresem IP wystąpienia usługi Application Gateway: 192.168.200.7
   • Docelowy adres IP: 192.168.1.4
   • nagłówek X-Forwarded-For: 192.168.100.7

4. Maszyna wirtualna odpowiada na usługę Application Gateway, która odwraca zarówno źródłowe, jak i docelowe adresy IP:

   • Źródłowy adres IP: 192.168.1.4
   • Docelowy adres IP: 192.168.200.7

5. Usługa Application Gateway odpowiada na źródłowy adres IP SNAT wystąpienia usługi Azure Firewall. Usługa Azure Firewall widzi wewnętrzny adres IP usługi Application Gateway, .4, jako źródłowy adres IP, nawet jeśli połączenie pochodzi z określonego wystąpienia usługi Application Gateway, takiego jak .7.

   • Źródłowy adres IP: 192.168.200.4
   • Docelowy adres IP: 192.168.100.7

6. Usługa Azure Firewall cofa żądania SNAT i DNAT oraz odpowiada na klienta.

   • Źródłowy adres IP: AzFwPIP
   • Docelowy adres IP: ClientPIP

Usługa Application Gateway potrzebuje publicznego adresu IP, aby firma Microsoft mogła nim zarządzać, nawet jeśli nie ma odbiorników skonfigurowanych dla aplikacji.

Nuta

Domyślna trasa do 0.0.0.0/0 w podsieci usługi Application Gateway wskazująca usługę Azure Firewall nie jest obsługiwana, ponieważ przerywa ruch płaszczyzny sterowania wymagany przez usługę Application Gateway do prawidłowego działania.

Klienci lokalni

Powyższe projekty pokazują wszystkich klientów aplikacji przychodzących z publicznego Internetu. Sieci lokalne również uzyskują dostęp do aplikacji. Większość poprzednich informacji i przepływów ruchu jest taka sama jak w przypadku klientów internetowych, ale istnieją pewne istotne różnice:

• Brama sieci VPN lub brama usługi ExpressRoute znajduje się przed usługą Azure Firewall lub application Gateway.

• Zapora aplikacji internetowej używa prywatnego adresu IP usługi Application Gateway.

• Usługa Azure Firewall nie obsługuje protokołu DNAT dla prywatnych adresów IP, dlatego należy użyć tras zdefiniowanych przez użytkownika do wysyłania ruchu przychodzącego do usługi Azure Firewall z bram sieci VPN lub usługi ExpressRoute.

• Upewnij się, że w wymuszone tunelowanieApplication Gateway i azure firewall. Nawet jeśli obciążenie nie wymaga łączności wychodzącej z publicznym Internetem, nie można wstrzyknąć trasy domyślnej, takiej jak 0.0.0.0/0 dla usługi Application Gateway, która wskazuje sieć lokalną, ponieważ przerywa ruch. W przypadku usługi Application Gateway domyślna trasa musi wskazywać publiczny Internet.

Architektura

Na poniższym diagramie przedstawiono równoległe projektowanie usługi Application Gateway i usługi Azure Firewall. Klienci aplikacji pochodzą z sieci lokalnej połączonej z platformą Azure za pośrednictwem sieci VPN lub usługi ExpressRoute:

Nawet jeśli wszyscy klienci znajdują się lokalnie lub na platformie Azure, usługa Application Gateway i usługa Azure Firewall muszą mieć publiczne adresy IP. Te publiczne adresy IP umożliwiają firmie Microsoft zarządzanie usługami.

Topologia piasty i szprych

Projekty w tym artykule dotyczą topologii piasty i szprych. Udostępnione zasoby w centralnej sieci wirtualnej koncentratora łączą się z aplikacjami w oddzielnych sieciach wirtualnych szprych za pośrednictwem komunikacji równorzędnej sieci wirtualnych.

Architektura

• Usługa Azure Firewall jest wdrażana w centralnej sieci wirtualnej koncentratora. Na poprzednim diagramie pokazano, jak wdrożyć usługę Application Gateway w centrum. Zespoły aplikacji często zarządzają składnikami, takimi jak bramy usługi Application Gateway lub bramy usługi API Management. W tym scenariuszu te składniki są wdrażane w sieciach wirtualnych szprych.

• Zwróć szczególną uwagę na trasy zdefiniowane przez użytkownika w sieciach szprych. Gdy serwer aplikacji w szprychy odbiera ruch z określonego wystąpienia usługi Azure Firewall, na przykład adres IP 192.168.100.7 w poprzednich przykładach, powinien wysyłać ruch powrotny do tego samego wystąpienia. Jeśli trasa zdefiniowana przez użytkownika w szprychach ustawia następny przeskok ruchu skierowanego do centrum do adresu IP usługi Azure Firewall (192.168.100.4 na poprzednich diagramach), pakiety zwrotne mogą trafić do innego wystąpienia usługi Azure Firewall. Taka sytuacja powoduje routing asymetryczny. Jeśli masz trasy zdefiniowane przez użytkownika w sieciach wirtualnych szprych, pamiętaj, aby wysłać ruch do usług udostępnionych w centrum za pośrednictwem usługi Azure Firewall. Te trasy zdefiniowane przez użytkownika nie zawierają prefiksu podsieci usługi Azure Firewall.

• Poprzednie zalecenie dotyczy jednakowo podsieci usługi Application Gateway i innych urządzeń WUS lub zwrotnych serwerów proxy, które mogą zostać wdrożone w sieci wirtualnej koncentratora.

• Nie można ustawić następnego przeskoku dla podsieci usługi Application Gateway lub usługi Azure Firewall za pośrednictwem tras statycznych z typem następnego przeskoku Virtual Network. Ten typ następnego przeskoku jest prawidłowy tylko w lokalnej sieci wirtualnej, a nie w sieciach równorzędnych sieci wirtualnych. Aby uzyskać więcej informacji na temat tras zdefiniowanych przez użytkownika i typów następnego przeskoku, zobacz Routing ruchu w sieci wirtualnej.

Routing asymetryczny

Na poniższym diagramie pokazano, jak szprycha wysyła ruch SNAT z powrotem do modułu równoważenia obciążenia platformy Azure w usłudze Azure Firewall. Ta konfiguracja powoduje routing asymetryczny.

Aby rozwiązać ten problem, zdefiniuj trasy zdefiniowane przez użytkownika w szprychach bez podsieci usługi Azure Firewall i tylko z podsieciami, w których znajdują się usługi udostępnione. Na poprzednim diagramie prawidłowa trasa zdefiniowana przez użytkownika w szprychach powinna zawierać tylko 192.168.1.0/24. Nie powinien zawierać całego zakresu 192.168.0.0/16, który jest oznaczony na czerwono.

Integracja z innymi produktami platformy Azure

Usługę Azure Firewall i usługę Application Gateway można zintegrować z innymi produktami i usługami platformy Azure.

Brama usługi API Management

Integrowanie usług zwrotnego serwera proxy, takich jak brama usługi API Management z poprzednimi projektami, aby zapewnić funkcje, takie jak ograniczanie przepustowości interfejsu API lub serwer proxy uwierzytelniania. Integracja bramy usługi API Management nie wpływa znacząco na projekty. Kluczową różnicą jest to, że zamiast pojedynczego zwrotnego serwera proxy usługi Application Gateway istnieją dwa odwrotne serwery proxy powiązane ze sobą.

Aby uzyskać więcej informacji, zobacz przewodnik projektowania , aby zintegrować usługę API Management i usługę Application Gateway w sieci wirtualnej oraz wzorzec aplikacji bram interfejsu API dla mikrousług.

Usługa AKS

W przypadku obciążeń uruchamianych w klastrze usługi AKS można wdrożyć usługę Application Gateway niezależnie od klastra. Możesz też zintegrować go z klastrem usługi AKS przy użyciu kontrolera ruchu przychodzącego usługi Application Gateway . Podczas konfigurowania określonych obiektów na poziomach platformy Kubernetes, takich jak usługi i ruch przychodzący, usługa Application Gateway automatycznie dostosowuje się bez konieczności wykonywania dodatkowych kroków ręcznych.

Usługa Azure Firewall odgrywa ważną rolę w zabezpieczeniach klastra usługi AKS. Zapewnia ona wymaganą funkcję filtrowania ruchu wychodzącego z klastra usługi AKS na podstawie nazwy FQDN, a nie tylko adresu IP. Aby uzyskać więcej informacji, zobacz Ograniczanie ruchu sieciowego za pomocą usługi Azure Firewall w usłudze AKS.

Łącząc usługę Application Gateway i usługę Azure Firewall w celu ochrony klastra usługi AKS, najlepiej użyć opcji projektowania równoległego. Usługa Application Gateway z zaporą aplikacji internetowej przetwarza przychodzące żądania połączeń do aplikacji internetowych w klastrze. Usługa Azure Firewall zezwala tylko na jawne dozwolone połączenia wychodzące. Aby uzyskać więcej informacji na temat opcji projektowania równoległego, zobacz Architektura punktu odniesienia dla klastra usługi AKS.

Usługa Azure Front Door

usługa Azure Front Door ma funkcje nakładające się na usługę Application Gateway w kilku obszarach. Obie usługi zapewniają zaporę aplikacji internetowej, odciążanie protokołu SSL i routing oparty na adresach URL. Jednak kluczową różnicą jest to, że chociaż usługa Application Gateway działa w sieci wirtualnej, usługa Azure Front Door jest globalną, zdecentralizowaną usługą.

Czasami można uprościć projektowanie sieci wirtualnej, zastępując usługę Application Gateway zdecentralizowaną usługą Azure Front Door. Większość projektów opisanych w tym artykule nadal ma zastosowanie, z wyjątkiem opcji umieszczenia usługi Azure Firewall przed usługą Azure Front Door.

Jednym ze scenariuszy jest użycie usługi Azure Firewall przed usługą Application Gateway w sieci wirtualnej. Usługa Application Gateway wprowadza nagłówek X-Forwarded-For z adresem IP wystąpienia zapory, a nie adresem IP klienta. Obejściem jest użycie usługi Azure Front Door przed zaporą w celu wstrzyknięcia adresu IP klienta jako nagłówka X-Forwarded-For przed wejściem ruchu do sieci wirtualnej i dotarciem do usługi Azure Firewall. Możesz również zabezpieczyć źródło za pomocą usługi Azure Private Link w usłudze Azure Front Door Premium.

Aby uzyskać więcej informacji na temat różnic między dwiema usługami lub kiedy należy ich używać, zobacz często zadawane pytania dotyczące usługi Azure Front Door.

Inne urządzenia WUS

Produkty firmy Microsoft nie są jedynym wyborem do zaimplementowania zapory aplikacji internetowej ani funkcji zapory nowej generacji na platformie Azure. Szeroki zakres partnerów firmy Microsoft zapewnia urządzenia WUS. Pojęcia i projekty są zasadniczo takie same jak w tym artykule, ale istnieją pewne ważne zagadnienia:

• Wirtualne urządzenia WUS partnera na potrzeby zapory nowej generacji mogą zapewnić większą kontrolę i elastyczność konfiguracji translatora adresów sieciowych, których usługa Azure Firewall nie obsługuje. Przykłady obejmują DNAT ze środowiska lokalnego lub DNAT z Internetu bez protokołu SNAT.

• Zarządzane przez platformę Azure urządzenia WUS, takie jak Application Gateway i Azure Firewall, zmniejszają złożoność w porównaniu z urządzeniami WUS, w których użytkownicy muszą obsługiwać skalowalność i odporność na wiele urządzeń.

• W przypadku korzystania z urządzeń WUS na platformie Azure użyj aktywne-aktywne i automatyczne skalowanie konfiguracji, aby te urządzenia nie były wąskim gardłem dla aplikacji działających w sieci wirtualnej.

Współpracowników

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

Główny autor:

• Jose Moreno | Główny inżynier klienta

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następne kroki

Dowiedz się więcej o technologiach składników:

• Co to jest usługa Application Gateway?
• Co to jest usługa Azure Firewall?
• Co to jest usługa Azure Front Door?
• Usługa AKS
• Co to jest sieć wirtualna?
• Co to jest zapora aplikacji internetowej?
• Architektura linii bazowej dla klastra usługi AKS

Powiązane zasoby

Zapoznaj się z powiązanymi architekturami:

• Implementowanie bezpiecznej sieci hybrydowej
• bezpiecznie zarządzane aplikacje internetowe
• wielodostępne oprogramowanie jako usługa na platformie Azure
• wdrażanie Enterprise przy użyciu środowiska App Service Environment
• wdrażanie w przedsiębiorstwie o wysokiej dostępności przy użyciu środowiska App Service Environment