Edytuj

Sieć o zerowym zaufaniu dla aplikacji internetowych za pomocą usługi Azure Firewall i usługi Application Gateway

Azure Application Gateway
Azure Firewall
Azure Virtual Network
Azure Virtual WAN
Azure Web Application Firewall

W tym przewodniku opisano strategię implementowania zabezpieczeń zerowego zaufania dla aplikacji internetowych na potrzeby inspekcji i szyfrowania. Model zerowego zaufania obejmuje wiele innych pojęć, takich jak ciągła weryfikacja tożsamości podmiotów lub zmniejszenie rozmiaru niejawnych obszarów zaufania do minimum. W tym artykule opisano składnik szyfrowania i inspekcji architektury zerowej zaufania dla ruchu przychodzącego z publicznego Internetu. Przeczytaj inne dokumenty o zerowym zaufaniu, aby uzyskać więcej aspektów bezpiecznego wdrażania aplikacji, takich jak uwierzytelnianie. W tym artykule najlepiej działa wielowarstwowe podejście, w którym zabezpieczenia sieci składają się na jedną z warstw modelu zerowego zaufania. W tej warstwie urządzenia sieciowe sprawdzają pakiety, aby upewnić się, że tylko legalny ruch dociera do aplikacji.

Zazwyczaj różne typy urządzeń sieciowych sprawdzają różne aspekty pakietów sieciowych:

  • Zapory aplikacji internetowej szukają wzorców wskazujących atak na warstwę aplikacji internetowej.
  • Zapory nowej generacji mogą również szukać ogólnych zagrożeń.

W niektórych sytuacjach można połączyć różne typy urządzeń zabezpieczeń sieciowych w celu zwiększenia ochrony. Oddzielny przewodnik , Zapora i usługa Application Gateway dla sieci wirtualnych, opisuje wzorce projektowe, których można użyć do rozmieszczania różnych urządzeń. Ten dokument koncentruje się na typowym wzorcu maksymalizacji zabezpieczeń, w którym aplikacja systemu Azure Gateway działa przed usługą Azure Firewall Premium. Na poniższym diagramie przedstawiono ten wzorzec:

Diagram architektury przedstawiający przepływ pakietów w sieci aplikacji internetowej, która korzysta z usługi Application Gateway przed usługą Azure Firewall Premium.

Pobierz plik programu Visio z tą architekturą.

Ta architektura używa protokołu Transport Layer Security (TLS) do szyfrowania ruchu na każdym kroku.

  • Klient wysyła pakiety do usługi Application Gateway, modułu równoważenia obciążenia. Działa z opcjonalnym dodatkiem usługi Azure Web Application Firewall.

  • Usługa Application Gateway odszyfrowuje pakiety i wyszukuje zagrożenia dla aplikacji internetowych. Jeśli nie znajdzie żadnych zagrożeń, szyfruje pakiety przy użyciu zasad zerowego zaufania. Następnie zwalnia je.

  • Usługa Azure Firewall Premium uruchamia kontrole zabezpieczeń:

  • Jeśli pakiety przechodzą testy, usługa Azure Firewall Premium wykonuje następujące czynności:

    • Szyfruje pakiety
    • Używa usługi systemu nazw domen (DNS) do określania maszyny wirtualnej aplikacji
    • Przekazuje pakiety do maszyny wirtualnej aplikacji

Różne aparaty inspekcji w tej architekturze zapewniają integralność ruchu:

  • Zapora aplikacji internetowej używa reguł, aby zapobiec atakom w warstwie internetowej. Przykłady ataków obejmują iniekcję kodu SQL i wykonywanie skryptów między witrynami. Aby uzyskać więcej informacji na temat reguł i podstawowego zestawu reguł open Web Application Security Project (OWASP), zobacz Web Application Firewall CRS rule groups and rules (Grupy i reguły CRS zapory aplikacji internetowej).
  • Usługa Azure Firewall Premium używa ogólnych reguł wykrywania i zapobiegania włamaniom. Te reguły ułatwiają identyfikowanie złośliwych plików i innych zagrożeń przeznaczonych dla aplikacji internetowych.

Ta architektura obsługuje różne typy projektów sieci, które omówiono w tym artykule:

  • Tradycyjne sieci piasty i szprych
  • Sieci korzystające z usługi Azure Virtual WAN jako platformy
  • Sieci korzystające z usługi Azure Route Server w celu uproszczenia routingu dynamicznego

Usługa Azure Firewall — wersja Premium i rozpoznawanie nazw

Podczas sprawdzania złośliwego ruchu usługa Azure Firewall Premium sprawdza, czy nagłówek hosta HTTP jest zgodny z adresem IP pakietu i portem TCP. Załóżmy na przykład, że usługa Application Gateway wysyła pakiety internetowe do adresu IP 172.16.1.4 i portu TCP 443. Wartość nagłówka hosta HTTP powinna zostać rozpoznana dla tego adresu IP.

Nagłówki hosta HTTP zwykle nie zawierają adresów IP. Zamiast tego nagłówki zawierają nazwy zgodne z certyfikatem cyfrowym serwera. W takim przypadku usługa Azure Firewall Premium używa usługi DNS do rozpoznawania nazwy nagłówka hosta na adres IP. Projekt sieci określa, które rozwiązanie DNS działa najlepiej, jak opisano w kolejnych sekcjach.

Uwaga

Usługa Application Gateway nie obsługuje numerów portów w nagłówkach hosta HTTP. W efekcie:

  • Usługa Azure Firewall Premium zakłada domyślny port TCP HTTPS 443.
  • Połączenie między usługą Application Gateway i serwerem sieci Web obsługuje tylko port TCP 443, a nie standardowe porty.

Certyfikaty cyfrowe

Na poniższym diagramie przedstawiono nazwy pospolite (CN) i urzędy certyfikacji (CA), których używają sesje i certyfikaty protokołu TLS architektury:

Diagram architektury przedstawiający nazwy pospolite i urzędy certyfikacji używane przez sieć aplikacji internetowej, gdy moduł równoważenia obciążenia znajduje się przed zaporą.

Połączenia TLS

Ta architektura zawiera trzy odrębne połączenia TLS. Certyfikaty cyfrowe weryfikują każdy z nich:

Z klientów do usługi Application Gateway

W usłudze Application Gateway wdrażasz certyfikat cyfrowy, który widzą klienci. Dobrze znany urząd certyfikacji, taki jak DigiCert lub Let's Encrypt, zwykle wystawia taki certyfikat.

Z usługi Application Gateway do usługi Azure Firewall — wersja Premium

Aby odszyfrować i sprawdzić ruch TLS, usługa Azure Firewall Premium dynamicznie generuje certyfikaty. Usługa Azure Firewall Premium udostępnia również usługę Application Gateway jako serwer internetowy. Prywatny urząd certyfikacji podpisuje certyfikaty generowane przez usługę Azure Firewall Premium. Aby uzyskać więcej informacji, zobacz Certyfikaty usługi Azure Firewall — wersja Premium. Usługa Application Gateway musi zweryfikować te certyfikaty. W ustawieniach PROTOKOŁU HTTP aplikacji należy skonfigurować główny urząd certyfikacji używany przez usługę Azure Firewall Premium.

Z usługi Azure Firewall — wersja Premium do serwera internetowego

Usługa Azure Firewall Premium ustanawia sesję protokołu TLS z docelowym serwerem internetowym. Usługa Azure Firewall Premium sprawdza, czy dobrze znany urząd certyfikacji podpisuje pakiety TLS serwera internetowego.

Role składników

Usługa Application Gateway i usługa Azure Firewall — wersja Premium obsługują certyfikaty inaczej niż między sobą, ponieważ ich role różnią się:

  • Usługa Application Gateway jest zwrotnym serwerem proxy sieci Web. Chroni serwery internetowe przed złośliwymi klientami przez przechwytywanie żądań HTTP i HTTPS. Każdy chroniony serwer znajduje się w puli zaplecza usługi Application Gateway z jego adresem IP lub w pełni kwalifikowaną nazwą domeny. Wiarygodni klienci powinni mieć dostęp do każdej aplikacji. Dlatego należy skonfigurować usługę Application Gateway przy użyciu certyfikatu cyfrowego podpisanego przez publiczny urząd certyfikacji. Użyj urzędu certyfikacji, który będzie akceptowany przez dowolnego klienta tls.
  • Usługa Azure Firewall — wersja Premium to serwer proxy sieci Web, czyli po prostu internetowy serwer proxy. Chroni klientów przed złośliwymi serwerami internetowymi, przechwytując wywołania TLS od chronionych klientów. Gdy chroniony klient wysyła żądanie HTTP, serwer proxy przesyłania dalej personifikuje docelowy serwer internetowy przez wygenerowanie certyfikatów cyfrowych i przedstawienie ich klientowi. Usługa Azure Firewall Premium używa prywatnego urzędu certyfikacji, który podpisuje dynamicznie generowane certyfikaty. Należy skonfigurować chronionych klientów tak, aby ufali temu prywatnemu urzędowi certyfikacji. W tej architekturze usługa Azure Firewall Premium chroni żądania z usługi Application Gateway na serwer internetowy. Usługa Application Gateway ufa prywatnemu urzędowi certyfikacji używanemu przez usługę Azure Firewall Premium.

Routing i przekazywanie ruchu

Routing będzie nieco inny w zależności od topologii projektu sieci. W poniższych sekcjach szczegółowo opisano szczegóły przykładów topologii piasty i szprych, sieci Virtual WAN i Route Server. Istnieją jednak pewne aspekty wspólne dla wszystkich topologii:

  • aplikacja systemu Azure Gateway zawsze zachowuje się jako serwer proxy, a usługa Azure Firewall — wersja Premium również podczas konfigurowania inspekcji protokołu TLS: sesje protokołu TLS od klientów zostaną zakończone przez usługę Application Gateway, a nowe sesje protokołu TLS zostaną utworzone w usłudze Azure Firewall. Usługa Azure Firewall otrzyma i zakończy sesje protokołu TLS pochodzące z usługi Application Gateway i skompiluje nowe sesje protokołu TLS w kierunku obciążeń. Ten fakt ma wpływ na konfigurację usługi IDPS usługi Azure Firewall Premium, sekcje poniżej zawierają więcej szczegółów na ten temat.
  • Obciążenie będzie widzieć połączenia pochodzące z adresu IP podsieci usługi Azure Firewall. Oryginalny adres IP klienta jest zachowywany w nagłówku X-Forwarded-For HTTP wstawianym przez usługę Application Gateway.
  • Ruch z usługi Application Gateway do obciążenia jest zwykle wysyłany do usługi Azure Firewall przy użyciu mechanizmów routingu platformy Azure, z trasami zdefiniowanymi przez użytkownika skonfigurowanymi w podsieci usługi Application Gateway lub trasami wstrzykiwanymi przez usługę Azure Virtual WAN lub Azure Route Server. Chociaż jawne zdefiniowanie prywatnego adresu IP usługi Azure Firewall w puli zaplecza usługi Application Gateway jest możliwe, technicznie nie jest zalecane, ponieważ pobiera niektóre funkcje usługi Azure Firewall, takie jak równoważenie obciążenia i stickiness.

W poniższych sekcjach opisano szczegółowo niektóre z najbardziej typowych topologii używanych z usługami Azure Firewall i Application Gateway.

Topologia gwiazdy

Zazwyczaj projekt piasty i szprych wdraża współużytkowane składniki sieciowe w sieci wirtualnej piasty i składników specyficznych dla aplikacji w szprychach. W większości systemów usługa Azure Firewall Premium jest zasobem udostępnionym. Zapora aplikacji internetowej może być jednak udostępnionym urządzeniem sieciowym lub składnikiem specyficznym dla aplikacji. Z następujących powodów zazwyczaj najlepiej traktować usługę Application Gateway jako składnik aplikacji i wdrożyć ją w sieci wirtualnej będącej szprychą:

  • Rozwiązywanie problemów z alertami zapory aplikacji internetowej może być trudne. Zazwyczaj potrzebna jest dogłębna wiedza na temat aplikacji, aby zdecydować, czy komunikaty wyzwalające te alarmy są uzasadnione.
  • Jeśli traktujesz usługę Application Gateway jako zasób udostępniony, możesz przekroczyć limity bramy aplikacja systemu Azure.
  • Jeśli wdrożysz usługę Application Gateway w centrum, możesz napotkać problemy z kontrolą dostępu opartą na rolach. Taka sytuacja może pojawić się, gdy zespoły zarządzają różnymi aplikacjami, ale używają tego samego wystąpienia usługi Application Gateway. Następnie każdy zespół ma dostęp do całej konfiguracji usługi Application Gateway.

W przypadku tradycyjnych architektur piasty i szprych prywatne strefy DNS zapewniają łatwy sposób korzystania z systemu DNS:

  • Skonfiguruj strefę prywatną DNS.
  • Połącz strefę z siecią wirtualną zawierającą usługę Azure Firewall Premium.
  • Upewnij się, że istnieje rekord A dla wartości używanej przez usługę Application Gateway dla ruchu i kontroli kondycji.

Na poniższym diagramie przedstawiono przepływ pakietów, gdy usługa Application Gateway znajduje się w sieci wirtualnej będącej szprychą. W takim przypadku klient łączy się z publicznego Internetu.

Diagram architektury przedstawiający przepływ pakietów w sieci piasty i szprych z modułem równoważenia obciążenia i zaporą. Klienci łączą się z publicznego Internetu.

  1. Klient przesyła żądanie do serwera internetowego.
  2. Usługa Application Gateway przechwytuje pakiety klienta i analizuje je. Jeśli pakiety przechodzą inspekcję, usługa Application Gateway wyśle pakiet do maszyny wirtualnej zaplecza. Gdy pakiet trafi na platformę Azure, trasa zdefiniowana przez użytkownika (UDR) w podsieci usługi Application Gateway przekazuje pakiety do usługi Azure Firewall Premium.
  3. Usługa Azure Firewall Premium uruchamia kontrole zabezpieczeń pakietów. Jeśli przejdą testy, usługa Azure Firewall Premium przekazuje pakiety do maszyny wirtualnej aplikacji.
  4. Maszyna wirtualna odpowiada i ustawia docelowy adres IP na usługę Application Gateway. Trasa zdefiniowana przez użytkownika w podsieci maszyny wirtualnej przekierowuje pakiety do usługi Azure Firewall Premium.
  5. Usługa Azure Firewall Premium przekazuje pakiety do usługi Application Gateway.
  6. Usługa Application Gateway odpowiada na klienta.

Ruch może również pochodzić z sieci lokalnej zamiast z publicznego Internetu. Ruch przepływa przez wirtualną sieć prywatną typu lokacja-lokacja (VPN) lub za pośrednictwem usługi ExpressRoute. W tym scenariuszu ruch najpierw dociera do bramy sieci wirtualnej w centrum. Pozostała część przepływu sieci jest taka sama jak w poprzednim przypadku.

Diagram architektury przedstawiający przepływ pakietów w sieci piasty i szprych z modułem równoważenia obciążenia i zaporą. Klienci łączą się z sieci lokalnej.

  1. Klient lokalny łączy się z bramą sieci wirtualnej.
  2. Brama przekazuje pakiety klienta do usługi Application Gateway.
  3. Usługa Application Gateway analizuje pakiety. Jeśli przejdą inspekcję, trasa zdefiniowana przez użytkownika w podsieci usługi Application Gateway przekazuje pakiety do usługi Azure Firewall Premium.
  4. Usługa Azure Firewall Premium uruchamia kontrole zabezpieczeń pakietów. Jeśli przejdą testy, usługa Azure Firewall Premium przekazuje pakiety do maszyny wirtualnej aplikacji.
  5. Maszyna wirtualna odpowiada i ustawia docelowy adres IP na usługę Application Gateway. Trasa zdefiniowana przez użytkownika w podsieci maszyny wirtualnej przekierowuje pakiety do usługi Azure Firewall Premium.
  6. Usługa Azure Firewall Premium przekazuje pakiety do usługi Application Gateway.
  7. Usługa Application Gateway wysyła pakiety do bramy sieci wirtualnej.
  8. Brama odpowiada klientowi.

Topologia usługi Virtual WAN

Możesz również użyć usługi sieciowej Virtual WAN w tej architekturze. Ten składnik oferuje wiele korzyści. Na przykład eliminuje konieczność obsługi tras zdefiniowanych przez użytkownika w sieciach wirtualnych szprych. Zamiast tego można definiować trasy statyczne w tabelach tras koncentratora wirtualnego. Programowanie każdej sieci wirtualnej, którą łączysz z koncentratorem, zawiera te trasy.

W przypadku korzystania z usługi Virtual WAN jako platformy sieciowej dwie główne różnice powodują:

  • Nie można połączyć stref prywatnych DNS z koncentratorem wirtualnym, ponieważ firma Microsoft zarządza koncentratorami wirtualnymi. Jako właściciel subskrypcji nie masz uprawnień do łączenia prywatnych stref DNS. W związku z tym nie można skojarzyć strefy prywatnej DNS z bezpiecznym koncentratorem zawierającym usługę Azure Firewall Premium. Aby zaimplementować rozpoznawanie nazw DNS dla usługi Azure Firewall Premium, użyj zamiast tego serwerów DNS:

    • Skonfiguruj Ustawienia DNS usługi Azure Firewall do używania niestandardowych serwerów DNS.
    • Wdróż serwery w sieci wirtualnej usług udostępnionych, która łączy się z wirtualną siecią WAN.
    • Połącz strefę prywatną DNS z siecią wirtualną usług udostępnionych. Serwery DNS mogą następnie rozpoznawać nazwy używane przez usługę Application Gateway w nagłówkach hosta HTTP. Aby uzyskać więcej informacji, zobacz Ustawienia DNS usługi Azure Firewall.

  • Usługi Virtual WAN można używać tylko do programowania tras w szprychach, jeśli prefiks jest krótszy (mniej specyficzny) niż prefiks sieci wirtualnej. Na przykład na diagramach powyżej sieci wirtualnej szprychy ma prefiks 172.16.0.0/16: w tym przypadku, Usługa Virtual WAN nie może wstrzyknąć trasy zgodnej z prefiksem sieci wirtualnej (172.16.0.0/16) ani żadnej z podsieci (172.16.0.0/24, 172.16.1.0/24). Innymi słowy usługa Virtual WAN nie może przyciągnąć ruchu między dwiema podsieciami, które znajdują się w tej samej sieci wirtualnej. To ograniczenie staje się widoczne, gdy usługa Application Gateway i docelowy serwer internetowy znajdują się w tej samej sieci wirtualnej: usługa Virtual WAN nie może wymusić ruchu między usługą Application Gateway a serwerem internetowym przechodzącym przez usługę Azure Firewall Premium (obejściem byłoby ręczne skonfigurowanie tras zdefiniowanych przez użytkownika w podsieciach usługi Application Gateway i serwera internetowego).

Na poniższym diagramie przedstawiono przepływ pakietów w przypadku, który korzysta z usługi Virtual WAN. W takiej sytuacji dostęp do usługi Application Gateway pochodzi z sieci lokalnej. Sieć VPN typu lokacja-lokacja lub usługa ExpressRoute łączy tę sieć z usługą Virtual WAN. Dostęp z Internetu jest podobny.

Diagram architektury przedstawiający przepływ pakietów w sieci piasty i szprych, który obejmuje moduł równoważenia obciążenia, zaporę i usługę Virtual WAN.

  1. Klient lokalny łączy się z siecią VPN.
  2. Sieć VPN przekazuje pakiety klienta do usługi Application Gateway.
  3. Usługa Application Gateway analizuje pakiety. Jeśli przejdą inspekcję, podsieć usługi Application Gateway przekazuje pakiety do usługi Azure Firewall Premium.
  4. Usługa Azure Firewall Premium żąda rozpoznawania nazw DNS z serwera DNS w sieci wirtualnej usług udostępnionych.
  5. Serwer DNS odpowiada na żądanie rozwiązania.
  6. Usługa Azure Firewall Premium uruchamia kontrole zabezpieczeń pakietów. Jeśli przejdą testy, usługa Azure Firewall Premium przekazuje pakiety do maszyny wirtualnej aplikacji.
  7. Maszyna wirtualna odpowiada i ustawia docelowy adres IP na usługę Application Gateway. Podsieć Application przekierowuje pakiety do usługi Azure Firewall Premium.
  8. Usługa Azure Firewall Premium przekazuje pakiety do usługi Application Gateway.
  9. Usługa Application Gateway wysyła pakiety do sieci VPN.
  10. Sieć VPN odpowiada klientowi.

W tym projekcie może być konieczne zmodyfikowanie routingu, który centrum anonsuje do sieci wirtualnych szprych. W szczególności usługa Application Gateway w wersji 2 obsługuje tylko trasę 0.0.0.0.0/0 wskazującą Internet. Trasy z tym adresem, które nie wskazują na internet, przerywają łączność wymaganą przez firmę Microsoft do zarządzania usługą Application Gateway. Jeśli koncentrator wirtualny anonsuje trasę 0.0.0.0/0, uniemożliwić propagację tej trasy do podsieci usługi Application Gateway, wykonując jedną z następujących czynności:

  • Utwórz tabelę tras z trasą dla 0.0.0.0/0 i typem Internetnastępnego przeskoku . Skojarz tę trasę z podsiecią, w której wdrażasz usługę Application Gateway.
  • W przypadku wdrożenia usługi Application Gateway w dedykowanej szprychy wyłącz propagację trasy domyślnej w ustawieniach połączenia sieci wirtualnej.

Topologia serwera tras

Usługa Route Server oferuje inny sposób automatycznego wstrzykiwania tras w szprychach. Dzięki tej funkcji można uniknąć obciążeń administracyjnych związanych z utrzymywaniem tabel tras. Serwer Route Server łączy warianty usługi Virtual WAN i piasty i szprych:

  • Dzięki usłudze Route Server klienci zarządzają sieciami wirtualnymi centrum. W związku z tym można połączyć sieć wirtualną koncentratora ze strefą prywatną DNS.
  • Usługa Route Server ma to samo ograniczenie, które usługa Virtual WAN ma dotyczące prefiksów adresów IP. Trasy można wstrzyknąć tylko do szprychy, jeśli prefiks jest krótszy (mniej specyficzny) niż prefiks sieci wirtualnej. Ze względu na to ograniczenie usługa Application Gateway i docelowy serwer internetowy muszą znajdować się w różnych sieciach wirtualnych.

Na poniższym diagramie przedstawiono przepływ pakietów, gdy usługa Route Server upraszcza routing dynamiczny. Zwróć uwagę na następujące kwestie:

  • Usługa Route Server wymaga obecnie urządzenia, które wprowadza trasy do wysyłania ich za pośrednictwem protokołu BGP (Border Gateway Protocol). Ponieważ usługa Azure Firewall Premium nie obsługuje protokołu BGP, zamiast tego użyj wirtualnego urządzenia sieciowego innej firmy (WUS).
  • Funkcjonalność urządzenia WUS w centrum określa, czy implementacja wymaga systemu DNS.

Diagram architektury przedstawiający przepływ pakietów w sieci piasty i szprych, który obejmuje moduł równoważenia obciążenia, zaporę i serwer tras.

  1. Klient lokalny łączy się z bramą sieci wirtualnej.
  2. Brama przekazuje pakiety klienta do usługi Application Gateway.
  3. Usługa Application Gateway analizuje pakiety. Jeśli przejdą inspekcję, podsieć usługi Application Gateway przekazuje pakiety do maszyny zaplecza. Trasa w podsieci ApplicationGateway wstrzyknięta przez serwer Route Server będzie przekazywać ruch do urządzenia WUS.
  4. Urządzenie WUS uruchamia kontrole zabezpieczeń pakietów. Jeśli przejdą testy, urządzenie WUS przekazuje pakiety do maszyny wirtualnej aplikacji.
  5. Maszyna wirtualna odpowiada i ustawia docelowy adres IP na usługę Application Gateway. Trasa wstrzyknięta w podsieci maszyny wirtualnej przez serwer route server przekierowuje pakiety do urządzenia WUS.
  6. Urządzenie WUS przekazuje pakiety do usługi Application Gateway.
  7. Usługa Application Gateway wysyła pakiety do bramy sieci wirtualnej.
  8. Brama odpowiada klientowi.

Podobnie jak w przypadku usługi Virtual WAN, może być konieczne zmodyfikowanie routingu podczas korzystania z serwera Route Server. Jeśli anonsujesz trasę 0.0.0.0/0, może ona być propagowana do podsieci usługi Application Gateway. Jednak usługa Application Gateway nie obsługuje tej trasy. W takim przypadku skonfiguruj tabelę tras dla podsieci usługi Application Gateway. Uwzględnij trasę dla 0.0.0.0/0 i typ Internet następnego przeskoku w tej tabeli.

Adresy IP i prywatne adresy IP

Jak wyjaśniono w temacie Reguły idPS usługi Azure Firewall, usługa Azure Firewall — wersja Premium decyduje, które reguły IDPS mają być stosowane w zależności od źródłowych i docelowych adresów IP pakietów. Usługa Azure Firewall będzie traktować domyślne prywatne adresy IP w zakresach RFC 1918 (10.0.0.0/8192.168.0.0/16i ) i 172.16.0.0/12RFC 6598 (100.64.0.0/10) jako wewnętrzne. W związku z tym, jeśli tak jak na diagramach w tym artykule usługa Application Gateway jest wdrażana w podsieci w jednym z tych zakresów (172.16.0.0/24 w powyższych przykładach), usługa Azure Firewall Premium rozważy ruch między usługą Application Gateway a obciążeniem, które ma być wewnętrzne, a tylko sygnatury IDPS oznaczone jako stosowane do ruchu wewnętrznego lub do dowolnego ruchu będą używane. Sygnatury IDPS oznaczone do zastosowania dla ruchu przychodzącego lub wychodzącego nie będą stosowane do ruchu między usługą Application Gateway a obciążeniem.

Najprostszym sposobem wymuszania stosowania reguł sygnatur przychodzących idPS do ruchu między usługą Application Gateway a obciążeniem jest umieszczenie usługi Application Gateway w podsieci z prefiksem poza zakresami prywatnymi. Nie musisz używać publicznych adresów IP dla tej podsieci, ale zamiast tego możesz dostosować adresy IP, które usługa Azure Firewall Premium traktuje jako wewnętrzne dla dostawców tożsamości. Jeśli na przykład organizacja nie używa 100.64.0.0/10 zakresu, możesz wyeliminować ten zakres z listy wewnętrznych prefiksów dla dostawcy tożsamości (zobacz zakresy prywatnych adresów IPDS usługi Azure Firewall Premium, aby uzyskać więcej informacji na temat tego sposobu) i wdrożyć usługę Application Gateway w podsieci skonfigurowanej przy użyciu adresu IP w systemie 100.64.0.0/10.

Współautorzy

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

Główny autor:

Następne kroki