Zapora i usługa Application Gateway dla sieci wirtualnych

Aby zabezpieczyć obciążenia aplikacji platformy Azure, należy użyć środków ochronnych, takich jak uwierzytelnianie i szyfrowanie, w samych aplikacjach. Warstwy zabezpieczeń można również dodać do sieci wirtualnych hostujących aplikacje. Te warstwy zabezpieczeń chronią przychodzące przepływy aplikacji przed niezamierzonym wykorzystaniem. 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ługi zabezpieczeń usługi Azure Virtual Network, takie jak Azure DDoS Protection, Azure Firewall i aplikacja systemu Azure Gateway, kiedy należy używać każdej usługi oraz opcje projektowania sieci, które łączą obie te usługi.

• Usługa Azure DDoS Protection w połączeniu z najlepszymi rozwiązaniami dotyczącymi projektowania aplikacji zapewnia ulepszone funkcje ograniczania ryzyka ataków DDoS w celu zapewnienia większej ochrony przed atakami DDoS. Należy włączyć usługę Azure DDOS Protection w dowolnej sieci wirtualnej obwodowej.
• Usługa Azure Firewall to zarządzana zapora nowej generacji, która oferuje translacja adresów sieciowych (NAT). Usługa Azure Firewall opiera filtrowanie pakietów na adresach IP (Internet Protocol) i portach protokołu Transmission Control Protocol i Protokołu TCP/UDP (User Datagram Protocol) lub na atrybutach HTTP lub SQL opartych na aplikacji. Usługa Azure Firewall stosuje również analizę zagrożeń firmy Microsoft do identyfikowania złośliwych adresów IP. Aby uzyskać więcej informacji, zobacz dokumentację usługi Azure Firewall.
• Usługa Azure Firewall Premium obejmuje wszystkie funkcje usługi Azure Firewall w warstwie Standardowa i inne funkcje, takie jak inspekcja protokołu TLS i system wykrywania i ochrony przed włamaniami (IDPS).
• aplikacja systemu Azure Gateway to zarządzany moduł równoważenia obciążenia ruchu internetowego i pełny zwrotny serwer 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 X-Forwarded-For HTTP. Usługa Application Gateway używa również zapory aplikacji internetowej do sprawdzania ruchu internetowego i wykrywania ataków w warstwie HTTP. Aby uzyskać więcej informacji, zobacz dokumentację usługi Application Gateway.
• Usługa Azure Web Application Firewall (WAF) jest opcjonalnym dodatkiem do usługi aplikacja systemu Azure Gateway. Zapewnia inspekcję żądań HTTP i zapobiega złośliwym atakom w warstwie internetowej, takim jak wstrzyknięcie kodu SQL lub wykonywanie skryptów między witrynami. Aby uzyskać więcej informacji, zobacz dokumentację zapory aplikacji internetowej.

Te usługi platformy Azure uzupełniają się. Jedna lub druga może być najlepsza dla obciążeń lub można ich używać razem w celu optymalnej ochrony zarówno w warstwach sieci, jak i aplikacji. Użyj następującego drzewa decyzyjnego i przykładów w tym artykule, aby określić najlepszą opcję zabezpieczeń dla sieci wirtualnej aplikacji.

Usługa Azure Firewall i usługa aplikacja systemu Azure Gateway korzystają z różnych technologii i obsługują sekurytację różnych przepływów:

W zależności od przepływów sieci, których wymaga aplikacja, projekt może być inny dla poszczególnych aplikacji. Na poniższym diagramie przedstawiono uproszczone drzewo decyzyjne, które ułatwia wybór zalecanego podejścia do aplikacji. Decyzja zależy od tego, czy aplikacja jest publikowana za pośrednictwem protokołu HTTP(S), czy innego protokołu:

W tym artykule omówiono szeroko zalecane projekty z wykresu blokowego i inne, które mają zastosowanie w mniej typowych scenariuszach:

• Sama usługa Azure Firewall, jeśli w sieci wirtualnej nie ma żadnych aplikacji internetowych. Będzie on kontrolować zarówno ruch przychodzący do aplikacji, jak i ruch wychodzący.
• Tylko usługa Application Gateway, gdy tylko aplikacje internetowe znajdują się w sieci wirtualnej, a sieciowe grupy zabezpieczeń zapewniają wystarczające filtrowanie danych wyjściowych. Funkcje udostępniane przez usługę Azure Firewall mogą zapobiegać wielu scenariuszom ataku (takim jak eksfiltracja danych, dostawcy tożsamości itd.). Z tego powodu sam scenariusz usługi Application Gateway nie jest zwykle zalecany i dlatego nie jest udokumentowany i nie znajduje się na powyższym wykresie blokowym.
• Usługa Azure Firewall i usługa Application Gateway równolegle, która jest jednym z najbardziej typowych projektów. Użyj tej kombinacji, jeśli chcesz aplikacja systemu Azure Gateway, aby chronić aplikacje HTTP przed atakami internetowymi, a usługa Azure Firewall chroni wszystkie inne obciążenia i filtruje ruch wychodzący.
• Usługa Application Gateway przed usługą Azure Firewall, gdy chcesz, aby usługa Azure Firewall zbadała cały ruch, zaporę aplikacji internetowej w celu ochrony ruchu internetowego oraz aplikację, aby znać źródłowy adres IP klienta. W przypadku inspekcji usługi Azure Firewall Premium i TLS ten projekt obsługuje również kompleksowe scenariusze SSL.
• Usługa Azure Firewall przed usługą Application Gateway, gdy chcesz, aby usługa Azure Firewall sprawdzała i filtrować ruch przed dotarciem do usługi Application Gateway. Ponieważ usługa Azure Firewall nie będzie odszyfrowywać ruchu HTTPS, funkcjonalność dodaną do usługi Application Gateway jest ograniczona. Ten scenariusz nie jest udokumentowany na powyższym wykresie blokowym.

W ostatniej części tego artykułu opisano odmiany poprzednich podstawowych projektów. Te odmiany obejmują:

• Klienci 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 API Management lub usługa Azure Front Door. Możesz też zastąpić zasoby platformy Azure wirtualnymi urządzeniami sieciowymi innych firm.

Tylko usługa 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ć tylko usługi Azure Firewall. Projekt w tym przypadku jest prosty, ale przejrzenie przepływu pakietów pomoże 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. Ruch wychodzący z sieci wirtualnych platformy Azure jest wysyłany do zapory za pośrednictwem tras zdefiniowanych przez użytkownika, jak pokazano w poniższym oknie dialogowym.

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

Usługa Azure Firewall nie będzie sprawdzać ruchu przychodzącego HTTP(S). Jednak będzie można zastosować reguły warstwy 3 i warstwy 4 oraz reguły aplikacji oparte na nazwach FQDN. Usługa Azure Firewall przeprowadzi inspekcję ruchu wychodzącego HTTP(S) w zależności od warstwy usługi Azure Firewall i tego, czy skonfigurowana jest inspekcja protokołu TLS:

• Usługa Azure Firewall w warstwie Standardowa 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 User-Agent) i włączanie inspekcji protokołu TLS w celu dokładniejszej analizy pakietów. Usługa Azure Firewall nie jest równoważna zaporze aplikacji internetowej. Jeśli masz obciążenia internetowe w sieci wirtualnej, zdecydowanie zaleca się korzystanie z 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. Aby zapewnić większą dostępność i skalowalność, będziesz mieć wiele wystąpień aplikacji za modułem równoważenia obciążenia. W tym projekcie usługa Azure Firewall sprawdza zarówno połączenia przychodzące z publicznego Internetu, jak i połączenia wychodzące z maszyny wirtualnej podsieci aplikacji przy użyciu trasy zdefiniowanej przez użytkownika.

• Usługa Azure Firewall wdraża kilka wystąpień w ramach okładek, tutaj z adresem IP frontonu 192.168.100.4 i adresami wewnętrznymi z zakresu 192.168.100.0/26. Te poszczególne wystąpienia są zwykle niewidoczne dla administratora platformy Azure. Jednak zauważenie różnicy jest przydatne w niektórych przypadkach, na przykład podczas rozwiązywania problemów z siecią.
• Jeśli ruch pochodzi z lokalnej wirtualnej sieci prywatnej (VPN) lub bramy usługi Azure ExpressRoute zamiast Internetu, klient uruchamia połączenie z adresem IP maszyny wirtualnej. Nie uruchamia połączenia z adresem IP zapory, a zapora nie będzie wykonywać translatora adresów sieciowych źródła na wartość domyślną.

Architektura

Na poniższym diagramie przedstawiono przepływ ruchu przy założeniu, że adres IP wystąpienia to 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, w tym przypadku 192.168.100.7. Reguła translatora 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 udostępnia również źródłowe punkty dostępu do sieci (SNATs), jeśli pakiet wykonuje 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, odwracając źródłowe i docelowe adresy IP. Przepływ przychodzący nie wymaga trasy zdefiniowanej przez użytkownika, ponieważ źródłowy adres IP to adres IP usługi Azure Firewall. Trasa zdefiniowana przez użytkownika na diagramie dla wersji 0.0.0.0/0 dotyczy połączeń wychodzących, aby upewnić się, ż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. Na koniec usługa Azure Firewall cofa operacje SNAT i DNAT i dostarcza odpowiedź na klienta:
   • Źródłowy adres IP: AzFwPIP
   • Docelowy adres IP: ClientPIP

Tylko usługa Application Gateway

Ten projekt obejmuje sytuację, w której istnieją tylko aplikacje internetowe w sieci wirtualnej, a inspekcja ruchu wychodzącego z sieciowymi grupami zabezpieczeń jest wystarczająca do ochrony przepływów wychodzących do Internetu.

Główną różnicą w stosunku do poprzedniego projektu tylko z usługą Azure Firewall jest to, że usługa Application Gateway nie działa jako urządzenie routingu z translatorem adresów sieciowych. Zachowuje się jako pełny zwrotny serwer proxy aplikacji. Oznacza to, że usługa Application Gateway zatrzymuje sesję internetową od klienta i ustanawia oddzielną sesję z jednym z jego serwerów zaplecza. Przychodzące połączenia HTTP (S) z Internetu muszą być wysyłane do publicznego adresu IP usługi Application Gateway, połączeń z platformy Azure lub lokalnego do prywatnego adresu IP bramy. Ruch powrotny z maszyn wirtualnych platformy Azure będzie podążał za standardowym routingiem sieci wirtualnej z powrotem do usługi Application Gateway (zobacz przewodnik po pakiecie w dół, aby uzyskać więcej informacji). Wychodzące przepływy internetowe z maszyn wirtualnych platformy Azure będą przechodzić prosto do Internetu.

W poniższej tabeli przedstawiono podsumowanie przepływów ruchu:

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 bramy aplikacja systemu Azure:
   • Ź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, w tym przypadku 192.168.200.7. Wystąpienie usługi Application Gateway odbierające żą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 X-Forwarded-For HTTP z oryginalnym adresem IP klienta.
   • Źródłowy adres IP: 192.168.200.7 (prywatny adres IP wystąpienia usługi Application Gateway)
   • Docelowy adres IP: 192.168.1.4
   • Nagłówek X-Forwarded-For: ClientPIP
3. Maszyna wirtualna odpowiada na żądanie aplikacji, odwracając źródłowe i docelowe adresy IP. Maszyna wirtualna już wie, jak 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. Na koniec wystąpienie usługi Application Gateway odpowiada klientowi:
   • Źródłowy adres IP: AppGwPIP
   • Docelowy adres IP: ClientPIP

aplikacja systemu Azure 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.

• Adres 192.168.200.7 IP jest jednym z wystąpień, które usługa aplikacja systemu Azure Gateway wdraża w ramach okładek, tutaj z wewnętrznym, prywatnym adresem 192.168.200.4IP frontonu . Te poszczególne wystąpienia są zwykle niewidoczne dla administratora platformy Azure. Jednak zauważenie różnicy jest przydatne w niektórych przypadkach, 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 adresu publicznego.

Zapora i usługa Application Gateway równolegle

Ze względu na prostotę i elastyczność równoległe uruchamianie usługi Application Gateway i usługi Azure Firewall jest często najlepszym scenariuszem.

Zaimplementuj ten projekt, jeśli w sieci wirtualnej istnieje połączenie obciążeń internetowych i innych niż sieci Web. Zapora aplikacji internetowej platformy Azure w usłudze aplikacja systemu Azure Gateway chroni ruch przychodzący do obciążeń internetowych, a usługa Azure Firewall sprawdza ruch przychodzący dla innych aplikacji. Usługa Azure Firewall obejmie 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łączeń HTTP(S) z platformy Azure lub lokalnego z prywatnym adresem IP. Routing w standardowej sieci wirtualnej wyśle pakiety z usługi Application Gateway do docelowych maszyn wirtualnych, a także z docelowych maszyn wirtualnych z powrotem do usługi Application Gateway (zobacz przewodnik po pakiecie, aby uzyskać więcej szczegółów). 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) lub będzie wysyłany przez usługę Azure Firewall przez trasy zdefiniowane przez użytkownika (jeśli pochodzą z innych sieci wirtualnych platformy Azure lub sieci lokalnych). Wszystkie przepływy wychodzące z maszyn wirtualnych platformy Azure będą przekazywane do usługi Azure Firewall przez trasy zdefiniowane przez użytkownika.

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

Ten projekt zapewnia znacznie bardziej szczegółowe filtrowanie ruchu wychodzącego niż sieciowe grupy zabezpieczeń. Jeśli na przykład aplikacje potrzebują łączności z określonym kontem usługi Azure Storage, możesz użyć w pełni kwalifikowanych filtrów opartych na nazwie domeny (FQDN). W przypadku filtrów opartych na nazwach FQDN aplikacje nie wysyłają danych do nieautoryzowanych kont magazynu. Nie można zapobiec temu scenariuszowi tylko przy użyciu sieciowych grup zabezpieczeń. Ten projekt jest często używany, gdy ruch wychodzący wymaga filtrowania opartego na nazwach FQDN. Przykładem jest ograniczenie ruchu wychodzącego z klastra usługi Azure Kubernetes Services.

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. Przykładem 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 zaporą

Ten projekt wyjaśniono bardziej szczegółowo w temacie Zero-trust network for web applications with Azure Firewall and Application Gateway (Sieć bez zaufania dla aplikacji internetowych za pomocą usługi Azure Firewall i application Gateway). Ten dokument 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 działa jako centralny punkt rejestrowania i kontroli i sprawdza ruch między usługą Application Gateway i serwerami zaplecza. Usługa Application Gateway i usługa Azure Firewall nie siedzą równolegle, ale jedna po drugiej.

Dzięki usłudze Azure Firewall Premium ten projekt może obsługiwać kompleksowe scenariusze, w których usługa Azure Firewall stosuje inspekcję protokołu TLS w celu przeprowadzenia idPS na zaszyfrowanym ruchu między usługą Application Gateway i zapleczem internetowym.

Ten projekt jest odpowiedni dla aplikacji, które muszą znać przychodzące adresy IP źródłowe klienta, na przykład do obsługi zawartości specyficznej dla lokalizacji geograficznej lub rejestrowania. Usługa Application Gateway przed usługą 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łączeń HTTP(S) z platformy Azure lub lokalnego do prywatnego adresu IP. W przypadku tras zdefiniowanych przez użytkownika usługi Application Gateway upewnij się, że pakiety są kierowane przez usługę Azure Firewall (zobacz przewodnik po pakiecie w dół, aby uzyskać więcej informacji). 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) lub będzie wysyłany przez usługę Azure Firewall przez trasy zdefiniowane przez użytkownika (jeśli pochodzą z innych sieci wirtualnych platformy Azure lub sieci lokalnych). Wszystkie przepływy wychodzące z maszyn wirtualnych platformy Azure będą przekazywane do usługi Azure Firewall przez trasy zdefiniowane przez użytkownika.

Ważną uwagą tego projektu jest to, że usługa Azure Firewall Premium będzie widzieć 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/8systemie , 192.168.0.0/16172.16.0.0/12 lub 100.64.0.0/10), usługa Azure Firewall Premium będzie traktować ruch z usługi Application Gateway jako wewnętrzny i nie będzie stosować reguł IDPS dla ruchu przychodzącego. Więcej informacji o kierunkach reguł idPS usługi Azure Firewall i prywatnych prefiksach adresów IP dla dostawcy tożsamości można znaleźć w regułach IDPS usługi Azure Firewall. W związku z tym zaleca się zmodyfikowanie prywatnych prefiksów IDPS w zasadach usługi Azure Firewall, aby podsieć usługi Application Gateway nie była traktowana jako źródło wewnętrzne, aby zastosować podpisy idPS ruchu przychodzącego i wychodzącego do ruchu.

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

W przypadku ruchu internetowego ze środowiska lokalnego lub internetowego na platformę Azure usługa Azure Firewall sprawdzi przepływy, które zapora aplikacji internetowej już zezwoliła. W zależności od tego, czy usługa Application Gateway szyfruje ruch zaplecza (ruch z usługi Application Gateway do serwerów aplikacji), będziesz mieć różne potencjalne scenariusze:

1. Usługa Application Gateway szyfruje ruch zgodnie z zasadami zerowego zaufania (kompleksowe szyfrowanie TLS), a usługa Azure Firewall otrzyma zaszyfrowany ruch. Mimo to usługa Azure Firewall w warstwie Standardowa będzie mogła stosować reguły inspekcji, takie jak filtrowanie warstwy 3 i warstwy 4 w regułach sieciowych lub filtrowanie nazw FQDN w regułach aplikacji przy użyciu nagłówka SNI (Tls Server Name Indication). Usługa Azure Firewall Premium zapewnia dokładniejszy wgląd w inspekcję protokołu TLS, taką jak filtrowanie oparte na adresach URL.
2. Jeśli usługa Application Gateway wysyła niezaszyfrowany ruch do serwerów aplikacji, usługa Azure Firewall zobaczy ruch przychodzący w postaci zwykłego tekstu. Inspekcja protokołu TLS nie jest wymagana w usłudze Azure Firewall.
3. Jeśli usługa IDPS jest włączona w usłudze Azure Firewall, sprawdzi, czy nagłówek hosta HTTP jest zgodny z docelowym adresem IP. W tym celu będzie potrzebne rozpoznawanie nazw dla nazwy FQDN określonej w nagłówku hosta. To rozpoznawanie nazw można osiągnąć za pomocą stref prywatnych usługi Azure DNS i domyślnych ustawień DNS usługi Azure Firewall przy użyciu usługi Azure DNS. Można go również osiągnąć za pomocą niestandardowych serwerów DNS, które należy skonfigurować w ustawieniach usługi Azure Firewall. (Aby uzyskać więcej informacji, zobacz Ustawienia DNS usługi Azure Firewall). Jeśli nie ma dostępu administracyjnego do sieci wirtualnej, w której wdrożono usługę Azure Firewall, jedyną możliwością jest ta ostatnia metoda. Przykładem jest użycie usługi Azure Firewalls wdrożonych w usłudze Virtual WAN Secured Hubs.

Architektura

W przypadku pozostałych przepływów (ruchu przychodzącego bez protokołu HTTP i dowolnego ruchu wychodzącego) usługa Azure Firewall zapewni inspekcję dostawcy tożsamości i inspekcję protokołu TLS, jeśli jest to konieczne. Zapewnia również filtrowanie oparte na nazwach FQDN w regułach sieci 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 bramy aplikacja systemu Azure:
   • Ź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, w tym przypadku 192.168.200.7. 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, zachowując docelowy adres IP aplikacji internetowej:
   • Źródłowy adres IP: 192.168.200.7 (prywatny adres IP wystąpienia usługi Application Gateway)
   • Docelowy adres IP: 192.168.1.4
   • Nagłówek X-Forwarded-For: ClientPIP
3. Usługa Azure Firewall nie sNAT 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 Azure Firewall SNAT. 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 pakiet, ponieważ usługa Azure Firewall będzie serwerem proxy połączenia:
   • Źródłowy adres IP, jeśli ruch jest dozwolony przez regułę sieciową usługi Azure Firewall: 192.168.200.7 (prywatny adres IP jednego z wystąpień usługi Application Gateway).
   • Źródłowy adres IP, jeśli ruch jest dozwolony przez regułę aplikacji usługi Azure Firewall: 192.168.100.7 (prywatny adres IP jednego z wystąpień usługi Azure Firewall).
   • Docelowy adres IP: 192.168.1.4
   • Nagłówek X-Forwarded-For: ClientPIP
4. Maszyna wirtualna odpowiada na żądanie, odwracając źródłowe i docelowe adresy IP. Trasa zdefiniowana przez użytkownika przechwytuje 192.168.200.0/24 pakiet wysyłany z powrotem do usługi Application Gateway i przekierowuje go do usługi Azure Firewall, zachowując 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. W tym miejscu ponownie usługa Azure Firewall nie sNAT 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. Na koniec wystąpienie usługi Application Gateway odpowiada klientowi:
   • Ź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 zgodnie z definicją trasy zdefiniowanej przez trasę zdefiniowaną przez użytkownika do 0.0.0.0/0.

Usługa Application Gateway po zaporze

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. Jednak usługa Azure Firewall SNATs ruchu przychodzącego, więc aplikacja nie będzie miała wglądu w oryginalny adres IP żądań HTTP. Z perspektywy administracji, na przykład w celach rozwiązywania problemów, można uzyskać rzeczywisty adres IP klienta dla określonego połączenia, korelując go z dziennikami SNAT usługi Azure Firewall.

W tym scenariuszu jest ograniczona korzyść, ponieważ usługa Azure Firewall będzie widzieć tylko zaszyfrowany ruch przechodzący do usługi Application Gateway. Mogą istnieć scenariusze, w których ten projekt jest preferowany. Jeden przypadek polega na tym, że inna zapora aplikacji internetowej znajduje się wcześniej w sieci (na przykład w usłudze Azure Front Door), co może przechwycić oryginalny źródłowy adres IP w nagłówku X-Forwarded-For HTTP. Lub projekt jest preferowany, jeśli wymagane jest wiele publicznych adresów IP.

Przepływy przychodzące HTTP (S) z publicznego Internetu powinny być kierowane do publicznego adresu IP usługi Azure Firewall, a 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 przy użyciu tras zdefiniowanych przez użytkownika. Routing w standardowej sieci wirtualnej zapewnia, że ruch powrotny z maszyn wirtualnych platformy Azure wraca do usługi Application Gateway, a z usługi Application Gateway do usługi Azure Firewall, jeśli zostały użyte reguły DNAT. Aby uzyskać więcej informacji, należy użyć ruchu ze środowiska lokalnego lub tras zdefiniowanych przez użytkownika platformy Azure w podsieci usługi Application Gateway (zobacz dalsze przechodzenie pakietów w dół). Cały ruch wychodzący z maszyn wirtualnych platformy Azure do Internetu zostanie wysłany za pośrednictwem usługi Azure Firewall przez trasy zdefiniowane przez użytkownika.

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

W przypadku ruchu przychodzącego HTTP(S) usługa Azure Firewall zwykle nie odszyfruje ruchu. Zamiast tego stosuje się 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; sieci SNATs usługi Azure Firewall pakiety są dostarczane 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, w tym przypadku 192.168.100.7. Dna Usługi Azure Firewall port internetowy, zazwyczaj TCP 443, do prywatnego adresu IP wystąpienia usługi Application Gateway. Usługa Azure Firewall również sieci SNATs podczas wykonywania DNAT. Aby uzyskać więcej informacji, zobacz Znane problemy z usługą Azure Firewall:
   • Źródłowy adres IP: 192.168.100.7 (prywatny adres IP wystąpienia usługi Azure Firewall)
   • Docelowy adres IP: 192.168.200.4
3. Usługa Application Gateway ustanawia nową sesję między wystąpieniem obsługującym połączenie a jednym z serwerów zaplecza. Oryginalny adres IP klienta nie znajduje się w pakiecie:
   • Źródłowy adres IP: 192.168.200.7 (prywatny adres IP wystąpienia usługi Application Gateway)
   • 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, odwracając źródłowe 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. Nawet jeśli połączenie pochodzi z określonego wystąpienia usługi Application Gateway, takiego jak .7, usługa Azure Firewall widzi wewnętrzny adres IP usługi Application Gateway .4 jako źródłowy adres IP:
   • Źródłowy adres IP: 192.168.200.4
   • Docelowy adres IP: 192.168.100.7
6. Na koniec usługa Azure Firewall cofa elementy SNAT i DNAT oraz odpowiada klientowi:
   • Źródłowy adres IP: AzFwPIP
   • Docelowy adres IP: ClientPIP

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

Klienci lokalni

Powyższe projekty pokazują wszystkich klientów aplikacji pochodzących z publicznego Internetu. Sieci lokalne również uzyskują dostęp do aplikacji. Większość powyższych 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żywać 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 należy sprawdzić zastrzeżenia dotyczące wymuszonego tunelowania dla bramy aplikacja systemu Azure i usługi 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ą, ani nie będzie prowadzić kontroli ruchu. W przypadku bramy aplikacja systemu Azure trasa domyślna musi wskazywać publiczny Internet.

Architektura

Na poniższym diagramie przedstawiono równoległe projektowanie bramy aplikacja systemu Azure 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, aplikacja systemu Azure Gateway i Azure Firewall muszą mieć publiczne adresy IP. Publiczne adresy IP umożliwiają firmie Microsoft zarządzanie usługami.

Topologia gwiazdy

Projekty w tym artykule nadal mają zastosowanie w 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

Kwestie wymagające rozważenia

Oto niektóre zagadnienia dotyczące tej topologii:

• Usługa Azure Firewall jest wdrażana w centralnej sieci wirtualnej koncentratora. Na powyższym diagramie przedstawiono praktykę wdrażania usługi Application Gateway w centrum. Zespoły aplikacji często zarządzają jednak składnikami, takimi jak bramy aplikacja systemu Azure lub bramy usługi Azure API Management. W takim przypadku 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, podobnie jak 192.168.100.7 adres w poprzednich przykładach, powinien wysyłać ruch powrotny z powrotem 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 powyższych diagramach), zwracane pakiety mogą trafić do innego wystąpienia usługi Azure Firewall, powodując routing asymetryczny. Upewnij się, że jeśli masz trasy zdefiniowane przez użytkownika w sieciach wirtualnych szprych do wysyłania ruchu 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 wirtualnych urządzeń sieciowych lub zwrotnych serwerów proxy, które mogą być wdrażane w sieci wirtualnej piasty.
• 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 Virtual Networknastępnego przeskoku . 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 SNATted z powrotem do usługi ALB usługi 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, ale tylko z podsieciami, w których znajdują się usługi udostępnione. W tym przykładzie prawidłowa trasa zdefiniowana przez użytkownika w szprychach powinna zawierać tylko 192.168.1.0/24. Nie powinien zawierać całej wersji 192.168.0.0/16, jak oznaczono na czerwono.

Integracja z innymi produktami platformy Azure

Usługę Azure Firewall i usługę aplikacja systemu Azure 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 , do poprzednich projektów w celu zapewnienia funkcjonalności, takich jak ograniczanie przepustowości interfejsu API lub serwer proxy uwierzytelniania. Integracja bramy usługi API Management nie zmienia znacznie projektów. Główną 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 bramy interfejsów API wzorca aplikacji dla mikrousług.

Azure Kubernetes Service

W przypadku obciążeń uruchomionych w klastrze usługi AKS można wdrożyć aplikacja systemu Azure Gateway niezależnie od klastra. Możesz też zintegrować go z klastrem usługi AKS przy użyciu kontrolera ruchu przychodzącego bramy aplikacja systemu Azure. Podczas konfigurowania niektórych 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. Oferuje 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 Kontrolowanie ruchu wychodzącego dla węzłów klastra usługi 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 żądania połączeń przychodzących do aplikacji internetowych w klastrze. Usługa Azure Firewall zezwala tylko na jawne dozwolone połączenia wychodzące. Zobacz Architektura linii bazowej dla klastra usługi Azure Kubernetes Service (AKS), aby zapoznać się z przykładem opcji projektowania równoległego.

Azure Front Door

Funkcje usługi Azure Front Door częściowo nakładają się na usługę aplikacja systemu Azure Gateway. Na przykład obie usługi oferują zaporę aplikacji internetowej, odciążanie protokołu SSL i routing oparty na adresach URL. Jedną z głównych różnic jest to, że chociaż aplikacja systemu Azure Gateway znajduje się wewnątrz sieci wirtualnej, usługa Azure Front Door to globalna, zdecentralizowana usługa.

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

Interesujący przypadek użycia to użycie usługi Azure Firewall przed usługą Application Gateway w sieci wirtualnej. Zgodnie z wcześniejszym opisem X-Forwarded-For nagłówek wstrzykiwany przez usługę Application Gateway będzie zawierać adres IP wystąpienia zapory, a nie adres IP klienta. Obejściem jest użycie usługi Azure Front Door przed zaporą w celu wstrzyknięcia adresu IP klienta jako nagłówka przed wejściem X-Forwarded-For do sieci wirtualnej i trafi do usługi Azure Firewall. Drugą opcją jest zabezpieczenie źródła za pomocą usługi 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 wirtualne urządzenia sieciowe

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 wirtualne urządzenia sieciowe (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ą oferować większą kontrolę i elastyczność konfiguracji translatora adresów sieciowych nieobsługiwanych przez usługę Azure Firewall. 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 należy używać konfiguracji aktywne-aktywne i automatyczne skalowanie , więc te urządzenia nie są wąskim gardłem dla aplikacji działających w sieci wirtualnej.

Współautorzy

Ten artykuł jest obsługiwany przez firmę Microsoft. Pierwotnie został napisany przez następujących współautorów.

Główny autor:

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

Następne kroki

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

• Co to jest aplikacja systemu Azure Gateway?
• Co to jest usługa Azure Firewall?
• Co to jest usługa Azure Front Door?
• Azure Kubernetes Service
• Co to jest usługa Azure Virtual Network?
• Co to jest usługa Azure Web Application Firewall?

Powiązane zasoby

Zapoznaj się z powiązanymi architekturami:

• Implementowanie bezpiecznej sieci hybrydowej
• Bezpieczne zarządzane aplikacje internetowe
• Zabezpieczanie bota kanału usługi Microsoft Teams i aplikacji internetowej za zaporą
• Portal kondycji konsumentów na platformie Azure
• Zagadnienia dotyczące zabezpieczeń dla wysoce wrażliwych aplikacji IaaS na platformie Azure
• Wielodostępna usługa SaaS na platformie Azure
• Wdrażanie w przedsiębiorstwie przy użyciu środowiska App Services Environment
• Wdrażanie w przedsiębiorstwie o wysokiej dostępności przy użyciu środowiska App Services Environment
• Architektura linii bazowej dla klastra usługi Azure Kubernetes Service (AKS)