Web Application Firewall dla sieci Azure

Azure Web Application Firewall (WAF) chroni aplikacje internetowe przed typowymi atakami w warstwie HTTP, takimi jak wstrzyknięcie kodu SQL, wykonywanie skryptów między witrynami (XSS) i przechodzenie ścieżki. W przeciwieństwie do Azure Firewall, który analizuje ruch w warstwach od 3 do 7 modelu OSI pod kątem zagrożeń na poziomie sieciowym, WAF działa tylko w warstwie 7 i rozumie semantykę protokołu HTTP, w tym nagłówki żądań, parametry ciągu zapytania, treści żądań i pliki cookie. Wdróż WAF w postaci zasad przypisanych do usługi Azure Application Gateway (w warstwie regionalnej) lub Azure Front Door (na globalnej krawędzi), aby dostosować zakres ochrony do architektury aplikacji. Web Application Firewall jest jedną z trzech podstawowych usług bezpieczeństwa sieci Azure, obok Azure Firewall i Azure DDoS Protection.

Co opisano w tym artykule

W tym artykule opisano ochronę warstwy HTTP przy użyciu Azure Web Application Firewall. Dowiesz się więcej o:

  • Porównanie platform WAF w usłudze Application Gateway v2 i w usłudze Azure Front Door.
  • Zestawy reguł oparte na programie OWASP, w tym domyślny zestaw reguł (DRS) i podstawowy zestaw reguł (CRS).
  • Tryb wykrywania a tryb zapobiegania i kiedy należy ich używać.
  • Opcje zakresu obowiązywania zasad WAF: globalne, dla poszczególnych witryn oraz powiązania z poszczególnymi nasłuchami.
  • Niestandardowe reguły ograniczania szybkości, filtrowania geograficznego i logiki specyficznej dla aplikacji.
  • Rozróżnienie między WAF (warstwa 7 protokołu HTTP) a usługą Azure Firewall (warstwy sieciowe 3–7).

Kto potrzebuje tego artykułu

Wdróż WAF, gdy Twoje obciążenia spełniają co najmniej jedno z następujących kryteriów:

  • Publiczne aplikacje internetowe: Aplikacje akceptują przychodzący ruch HTTP/HTTPS z Internetu, ujawniając je lukom w zabezpieczeniach OWASP Top 10, w tym atakom polegającym na wstrzyknięciu, przerwanym nadużyciom uwierzytelniania i próbom ujawnienia poufnych danych.
  • Wymagania dotyczące zgodności: Struktury regulacyjne, takie jak PCI DSS (Payment Card Industry Data Security Standard) upoważniają zaporę aplikacji internetowej przed dowolną aplikacją przetwarzającą dane karty płatniczej.
  • Ochrona interfejsu API: Interfejsy API są publicznie dostępne i wymagają ochrony przed przemytem żądań, przeładowanymi ładunkami i atakami na poziomie protokołu, których zapory sieciowe nie sprawdzają.
  • Ograniczenie ryzyka bota: Należy kategoryzować i kontrolować zautomatyzowany ruch, blokując złośliwe boty, zezwalając na legalne przeszukiwarki i usługi monitorowania.

Organizacje, które potrzebują tylko filtrowania ruchu na poziomie sieci (adres IP, port i protokół) bez inspekcji żądań HTTP, powinny zamiast tego używać Azure Firewall lub sieciowych grup zabezpieczeń.

Nacisk na strategię lift-and-shift: Wiele wewnętrznych aplikacji przeniesionych metodą rehostingu nie jest dostępnych z internetu i nie wymaga WAF. Dodaj WAF tylko wtedy, gdy udostępniasz aplikację internetową w Internecie podczas migracji lub po migracji.

Priorytet modernizacji: Umieść publicznie dostępne aplikacje internetowe za usługą WAF w Azure Front Door w przypadku aplikacji globalnych lub w usłudze Application Gateway w przypadku aplikacji wdrożonych w jednym regionie, zgodnie z wybranym sposobem dostarczania: Front Door lub Traffic Manager.

Podejście wielochmurowe: Umieść zaporę aplikacyjną warstwy 7 (WAF) w usłudze Application Gateway w sieci spoke dla zmigrowanych publicznie dostępnych aplikacji internetowych i odpowiednio przypisz mechanizmy ochrony aplikacji internetowych w innych chmurach (takie jak Google Cloud Armor) do usługi Azure WAF.

Porównanie platformy Azure WAF

Azure WAF jest dostępny na dwóch platformach. Każda platforma integruje inspekcję WAF w innym punkcie przepływu ruchu.

Diagram przedstawiający architekturę Azure Web Application Firewall z opcjami wdrażania usługi Application Gateway i usługi Front Door

Capability WAF w usłudze Application Gateway v2 WAF w usłudze Azure Front Door
Zakres wdrożenia Regionalny (pojedynczy region platformy Azure) Globalnie (ponad 192 brzegowe punkty PoP na całym świecie)
Punkt inspekcji Po dotarciu ruchu sieciowego do Twojego regionu Na krawędzi poP, zanim ruch osiągnie źródło
Obsługiwane zestawy reguł DRS 2.2, DRS 2.1, CRS 3.2 DRS 2.2, DRS 2.1, DRS 2.0
Reguły niestandardowe ✔ ✔
Ochrona przed botami ✔ ✔ (Tylko warstwa Premium)
Ograniczanie szybkości ✔ ✔
Geo-filtering ✔ ✔
Zasady dla poszczególnych lokacji ✔ (na nasłuch, na ścieżkę) ✔ (dla każdego punktu końcowego)
Zarządzane zestawy reguł ✔ ✔ (Tylko warstwa Premium; Standard obsługuje tylko reguły niestandardowe)
Żądanie kontroli jednostki Do 128 KB (można skonfigurować) Do 128 KB (można skonfigurować)
Obsługa źródeł Private Link N/A (wbudowane w usłudze App Gateway) ✔ (łączność ze źródłem prywatnym)
Najlepsze dla Aplikacje jednoregionowe, równoważenie obciążenia L7 + zapora aplikacji webowych Aplikacje wieloregionowe, globalna akceleracja + WAF

Note

Azure Front Door ma dwie warstwy: Standardowa i Premium. Zarządzane zestawy reguł (w tym DRS i ochrona przed botami) są dostępne tylko w usłudze Front Door Premium. Usługa Front Door Standard obsługuje tylko reguły niestandardowe. Usługa Front Door (wersja klasyczna) obsługuje tylko usługę DRS 1.1 lub starszą.

Jak wybrać platformę WAF

Użyj następujących kryteriów decyzyjnych:

  • Wybierz usługę WAF w usłudze Application Gateway, gdy aplikacja jest wdrożona w jednym regionie, a używasz już usługi Application Gateway do równoważenia obciążenia warstwy 7, terminacji protokołu TLS lub routingu opartego na ścieżkach. WAF dodaje inspekcję protokołu HTTP w trybie inline bez wprowadzania dodatkowego przeskoku do usługi.
  • Wybierz usługę WAF w usłudze Azure Front Door, gdy aplikacja obejmuje wiele regionów, wymaga globalnego równoważenia obciążenia lub korzysta na akceleracji za pomocą sieci dostarczania zawartości (CDN). Usługa Front Door WAF analizuje ruch w najbliższym punkcie obecności na brzegu sieci (PoP). Usługa blokuje złośliwe żądania, zanim przejdą przez sieć szkieletową Azure w celu uzyskania dostępu do źródła. Takie podejście ogranicza ekspozycję powierzchni ataku i pochłania wolumetryczne ataki warstwy 7 na brzegu sieci.
  • Wybierz obie opcje (warstwowo), gdy aplikacja wieloregionowa obsługiwana przez usługę Front Door wymaga również regionalnych zasad WAF, które są różne dla każdego zaplecza. Usługa Front Door zapewnia pierwszą linię ochrony globalnej, podczas gdy usługa Application Gateway WAF stosuje reguły niestandardowe specyficzne dla danego regionu bliżej obciążenia roboczego.

Uwagi dotyczące projektowania

Główne założenia projektowe WAF typu lift-and-shift

  • Pomiń usługę WAF dla ponownie hostowanych obciążeń dostępnych wyłącznie wewnętrznie, które nie mają ścieżki ruchu przychodzącego z Internetu; wróć do tego, gdy opublikujesz aplikację w Internecie.
  • Gdy udostępniasz aplikację internetową publicznie, uruchom WAF w trybie wykrywania, aby ustalić bazowy poziom ruchu, a następnie przełącz go w tryb zapobiegania po wyeliminowaniu fałszywych alarmów.
  • Użyj zapory WAF usługi Application Gateway dla aplikacji internetowej po rehostingu wdrożonej w jednym regionie, dla której usługa Application Gateway została już wdrożona jako warstwa frontowa do routingu warstwy 7.
  • Wykorzystaj założenia lokalnych reguł ochrony aplikacji internetowych (na przykład zakres ochrony OWASP) jako politykę wyjściową.

Zmodernizuj podejście do projektowania WAF

  • Uruchom WAF w trybie prewencji od samego początku w przypadku aplikacji dostępnych dla klientów i zastosuj najnowszy zarządzany zestaw reguł, aby zakres ochrony automatycznie nadążał za nowymi zagrożeniami OWASP.
  • Włącz zarządzanie botami, aby odróżniać uprawnione boty indeksujące od złośliwych zautomatyzowanych działań wymierzonych w Twoje publiczne aplikacje.
  • Zarządzaj polityką WAF jako kodem, aby regionalne backendy w trybie active-active pozostawały zsynchronizowane w całym potoku wdrożeniowym.
  • Połącz brzegową zaporę WAF z zaporą centrum, aby uzyskać ochronę warstwową, i włącz rabat rozliczeniowy dla usługi Application Gateway WAF, włączając usługę DDoS Network Protection w sieci wirtualnej (VNet).

Nacisk na projektowanie wielochmurowego WAF-u

  • Hostuj WAF warstwy 7 w usłudze Application Gateway w sieci wirtualnej typu spoke, aby publiczny ruch internetowy był inspekcjonowany bez przypisywania publicznych adresów IP bezpośrednio do maszyn wirtualnych.
  • Przypisz istniejące zabezpieczenia aplikacji internetowych z innych chmur (na przykład AWS WAF lub Google Cloud Armor) do zarządzanych zestawów reguł usługi Azure WAF, aby zachować ten sam zakres ochrony.
  • Poddawaj inspekcji komunikację publicznie dostępną za pośrednictwem zapory aplikacji internetowych (WAF), a inspekcję ruchu wschód-zachód i między chmurami utrzymuj na zaporze w centrum Virtual WAN.
  • Podczas przełączenia najpierw uruchom WAF w trybie wykrywania (uczenia), a następnie włącz wymuszanie po potwierdzeniu prawidłowych wzorców ruchu.

Prerequisites

Przed wdrożeniem Azure Web Application Firewall upewnij się, że masz następujące elementy:

  • Zasób Application Gateway v2 lub Azure Front Door: WAF jest wdrażany jako zasada dołączona do jednej z tych platform. Przed utworzeniem i skojarzeniem zasad WAF musisz mieć wdrożone istniejące wystąpienie usługi Application Gateway v2 lub profil usługi Azure Front Door.
  • Obciążenie HTTP/HTTPS dostępne publicznie: Aplikacja musi odbierać przychodzący ruch HTTP/HTTPS. WAF analizuje semantykę na poziomie żądań i nie przynosi korzyści w przypadku obciążeń innych niż HTTP ani usług działających wyłącznie wewnętrznie.
  • Informacje o wzorcach ruchu HTTP: Znajomość normalnych wzorców żądań aplikacji (nagłówków, parametrów zapytania i zawartości treści) ułatwia konfigurowanie wykluczeń i dostrajanie reguł w celu zminimalizowania wyników fałszywie dodatnich podczas przejścia w tryb wykrywania do zapobiegania.

Zestawy reguł i przetwarzanie reguł

WAF używa zestawów reguł do wykrywania złośliwych wzorców w żądaniach HTTP. Zrozumienie hierarchii reguł i kolejności przetwarzania pomaga dostroić WAF do konkretnych aplikacji.

Zarządzane zestawy reguł

Microsoft obsługuje zarządzane zestawy reguł oparte na wzorcach OWASP Core Rule Set (CRS). Zalecanym zestawem reguł dla nowych wdrożeń jest DRS 2.2 (domyślny zestaw reguł). Usługa DRS 2.2 jest oparta na OWASP CRS 3.3.4 i dodaje podpisy analizy zagrożeń Microsoft.

Zestaw reguł Na podstawie Obsługa platformy Rekomendacja
DRS 2.2 OWASP CRS 3.3.4 + Microsoft Threat Intel App Gateway v2, Front Door Premium Zalecane w przypadku nowych wdrożeń
DRS 2.1 (wersja 2.1) OWASP CRS 3.3 App Gateway v2, Front Door Premium Poprzednie generowanie; obsługiwane na obu platformach
DRS 2.0 OWASP CRS 3.2 Tylko usługa Front Door Premium Obsługiwane; Front Door w wersji N-2
CRS 3.2 OWASP CRS 3.2 Tylko usługa App Gateway w wersji 2 Obsługiwane; do nowych wdrożeń używaj DRS 2.2

Zestawy reguł DRS i CRS wykorzystują punktację anomalii. Każda pasująca reguła dodaje punkty do wyniku zamiast natychmiast blokować żądanie. Gdy skumulowany wynik anomalii przekroczy konfigurowalny próg, WAF podejmuje działanie (blokowanie lub rejestrowanie). Takie podejście zmniejsza liczbę fałszywych alarmów w porównaniu z blokowaniem opartym na pojedynczych regułach, ponieważ pojedyncze dopasowanie o niskim poziomie pewności nie powoduje zastosowania wymuszania.

Reguły niestandardowe

Reguły niestandardowe są wykonywane przed zarządzanymi regułami i używają numerów priorytetów do kontrolowania kolejności oceny (niższa liczba = wyższy priorytet). Użyj niestandardowych reguł dla:

  • Ograniczanie liczby żądań: Ogranicz liczbę żądań z każdego adresu IP klienta w określonym przedziale czasowym, aby ograniczyć ataki polegające na masowym użyciu danych uwierzytelniających oraz ataki brute force.
  • Filtrowanie geograficzne: Zezwalaj na ruch lub odmawiaj go na podstawie kraju lub regionu pochodzenia klienta.
  • Listy dozwolonych adresów IP i listy blokowanych adresów IP: Zezwalaj na adresy IP znanych partnerów lub blokuj znane złośliwe podmioty, zanim reguły zarządzane zostaną ocenione.
  • Inspekcja nagłówka żądania: Wymuszanie wymagań specyficznych dla aplikacji, takich jak obowiązkowe klucze interfejsu API lub oczekiwane typy zawartości.

Zestaw reguł ochrony botów

Obie platformy oferują zestaw reguł ochrony botów, który kategoryzuje zautomatyzowany ruch do dobrych botów (zweryfikowanych aparatów wyszukiwania), nieprawidłowych botów (znanych złośliwych skanerów) i nieznanych botów. Konfigurowanie akcji dla każdej kategorii: zezwalaj na dobre boty, blokuj złe boty i rzucaj wyzwanie nieznanym botom za pomocą ograniczania szybkości lub CAPTCHA.

Tryb wykrywania vs. tryb zapobiegania

Zasady WAF działają w jednym z dwóch trybów, które określają sposób obsługi żądań spełniających regułę:

Mode Behavior Przypadek użycia
Wykrywanie Rejestruje dopasowane żądania, ale ich nie blokuje. Żądania nadal trafiają do serwera zaplecza. Wstępne wdrażanie i dostrajanie reguł. Monitoruj, które reguły są uruchamiane, bez wpływu na ruch w środowisku produkcyjnym.
Profilaktyka Blokuje dopasowane żądania i zwraca odpowiedź 403. Rejestruje zablokowane żądanie. Obciążenia produkcyjne po zakończeniu dostrajania reguł. Aktywna ochrona przed atakami.
  1. Wdróż w trybie wykrywania: Włącz WAF z wybranym zestawem reguł w trybie wykrywania. Kieruj ruch produkcyjny przez WAF.
  2. Analizuj dzienniki: Przejrzyj dzienniki WAF, aby zidentyfikować fałszywe alarmy. Określ reguły wyzwalające prawidłowy ruch aplikacji.
  3. Tworzenie wykluczeń: W przypadku reguł, które generują wyniki fałszywie dodatnie, zdefiniuj wykluczenia określające pola żądania (nagłówki, pliki cookie i parametry zapytania), aby pominąć określone reguły.
  4. Przełącz się do trybu zapobiegania: Po 1–2 tygodniach czystych dzienników wykrywania z akceptowalnymi współczynnikami fałszywie dodatnimi przełącz się do trybu zapobiegania aktywnemu blokowaniu.
  5. Bieżące monitorowanie: Kontynuuj monitorowanie dzienników po przełączeniu do trybu zapobiegania. Nowe funkcje aplikacji lub zmiany interfejsu API mogą wprowadzać nowe wzorce fałszywie dodatnie.

Ważna

Zawsze uruchamiaj obciążenia produkcyjne w trybie zapobiegania. Tryb wykrywania nie zapewnia ochrony. Rejestruje tylko potencjalne ataki. Użyj trybu wykrywania tylko podczas początkowej fazy dostrajania lub podczas rozwiązywania określonego problemu fałszywie dodatniego.

Zakres zasad WAF i powiązanie

Zasada WAF to samodzielny zasób platformy Azure zawierający wybrany tryb, konfigurację zestawu reguł, reguły niestandardowe i wykluczenia. Przypisz zasadę do co najmniej jednego celu, aby określić zakres ochrony.

Zakres zasady WAF usługi Application Gateway

W usłudze Application Gateway skojarz zasady WAF na trzech poziomach szczegółowości:

  • Globalne (dla całej bramy): Zasada dotyczy wszystkich detektorów nasłuchu i reguł ścieżek w bramie Application Gateway. Użyj zakresu globalnego, gdy wszystkie aplikacje za bramą mają te same wymagania dotyczące ochrony.
  • Na poziomie odbiornika: Do określonego odbiornika (kombinacji nazwy hosta i portu) ma zastosowanie inna zasada WAF. Użyj zakresu na poziomie odbiornika, gdy wiele aplikacji współużytkuje bramę, ale wymaga różnych dostrajania lub wykluczeń reguł.
  • Poziom reguły ścieżki: Zasada WAF ma zastosowanie do określonej reguły ścieżki adresu URL w listenerze. Użyj zakresu reguł ścieżek, aby precyzyjnie kontrolować aplikacje o zróżnicowanej wrażliwości backendów.

Jeśli do pojedynczego żądania ma zastosowanie wiele zakresów obowiązywania, pierwszeństwo ma najbardziej szczegółowa polityka: reguła ścieżki jest nadrzędna względem poziomu nasłuchu, a ten względem poziomu globalnego.

Zakres zasad WAF usługi Front Door

W usłudze Front Door zasady WAF są przypisywane na poziomie punktu końcowego lub trasy. Każdy punkt końcowy usługi Front Door może mieć własną politykę WAF. Takie podejście umożliwia stosowanie profilów ochrony specyficznych dla aplikacji w ramach pojedynczego wystąpienia usługi Front Door.

Udostępnianie zasad między zasobami

Udostępnij pojedynczą zasadę zapory aplikacji webowych (WAF) między wieloma wystąpieniami usługi Application Gateway lub punktami końcowymi usługi Front Door. Azure Firewall Manager zapewnia scentralizowany wgląd w wszystkie zasady WAF i zarządzanie nimi, niezależnie od używanej platformy. Użyj zasad udostępnionych, gdy wiele zasobów wymaga identycznej ochrony, aby uprościć zarządzanie i zachować spójny stan zabezpieczeń.

Rozróżnienie od Azure Firewall

WAF i Azure Firewall chronią różne warstwy stosu sieciowego i pełnią uzupełniające się role. Wdróż oba mechanizmy w ramach obrony warstwowej.

Atrybut Web Application Firewall Azure Firewall
Warstwa OSI Warstwa 7 (tylko protokół HTTP/HTTPS) Warstwy 3–7 (sieć i aplikacja)
Typ ruchu Przychodzące żądania HTTP/HTTPS do aplikacji internetowych Wszystkie kierunki ruchu (północ-południe, wschód-zachód)
Fokus inspekcji Semantyka HTTP: nagłówki, treść, pliki cookie, identyfikatory URI Adresy IP, porty, protokoły, nazwy FQDN, adresy URL
Aparat reguł Dopasowywanie wzorca opartego na programie OWASP i ocenianie anomalii Reguły sieci, reguły aplikacji, reguły NAT
Model wdrażania Integracja z usługą App Gateway lub usługą Front Door Samodzielnie w podsieci typu hub z routingiem UDR
Typowe ataki zablokowane Iniekcja SQL, XSS, CSRF, przechodzenie ścieżki Skanowanie portów, wywołania zwrotne C2, eksfiltracja DNS

Użyj WAF do ochrony aplikacji internetowych HTTP, a Azure Firewall do scentralizowanej inspekcji ruchu sieciowego. W architekturze typu hub-and-spoke ruch z internetu do aplikacji internetowej zwykle przechodzi przez usługę Azure Firewall (na potrzeby translacji DNAT i inspekcji na poziomie sieci), a następnie przez usługę Application Gateway z modułem WAF (na potrzeby inspekcji na warstwie HTTP). Zobacz Azure Firewall i inspekcja ruchu, aby uzyskać informacje o komponencie na poziomie sieci.

Zagadnienia dotyczące zabezpieczeń

Poniższe praktyki zabezpieczeń pomagają zapewnić maksymalną ochronę dzięki zaporze aplikacji internetowych (WAF):

  • Tryb zapobiegania dla środowiska produkcyjnego: Nigdy nie pozostawiaj obciążeń roboczych w środowisku produkcyjnym w trybie wykrywania. Tryb wykrywania zapewnia widoczność, ale nie wymusza, pozostawiając aplikacje narażone na ataki.
  • Trwa dostrajanie reguł: Aplikacje ewoluują. Nowe endpointy API, parametry i typy treści mogą powodować wyniki fałszywie dodatnie w istniejących zestawach reguł. Regularnie przeglądaj dzienniki WAF po każdym wdrożeniu.
  • Integracja z usługą Log Analytics: Wyślij dzienniki diagnostyczne WAF do obszaru roboczego usługi Log Analytics. Użyj skoroszytu WAF do wizualizacji zablokowanych żądań, reguł, które zostały wyzwolone, oraz rozkładów ocen anomalii.
  • DDoS i WAF razem: WAF chroni przed atakami na poziomie warstwy 7, ale nie łagodzi wolumetrycznych ataków DDoS na poziomie warstwy sieci. Połącz usługę WAF z Azure DDoS Protection, aby zapewnić pełną ochronę całego stosu.
  • Ograniczenie dostępu do źródła: Jeśli używasz usługi Front Door WAF, skonfiguruj źródło tak, aby akceptowało ruch wyłącznie z tagu usługi Front Door. Bez blokady źródła osoby atakujące mogą pomijać usługę Front Door i wysyłać żądania bezpośrednio do adresu IP źródła.
  • Ochrona poufnych danych: Dzienniki WAF mogą zawierać dane z żądań. Skonfiguruj reguły oczyszczania dzienników, aby maskować pola poufne (nagłówki autoryzacyjne, pliki cookie lub treść żądania) w dziennikach diagnostycznych WAF.

W poniższych artykułach omówiono powiązane tematy dotyczące zabezpieczeń sieci:

Learn more

Następne kroki

Tip

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

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

Skonfiguruj monitorowanie migrowanej sieci: zweryfikuj łączność i wydajność po skonfigurowaniu zapory aplikacji internetowej.

Kolejny etap procesu modernizacji:

Włącz ochronę przed atakami DDoS dla publicznych punktów końcowych: chroń zasoby publicznego adresu IP przed rozproszonymi atakami typu "odmowa usługi".

Kolejny krok w Twojej wielochmurowej podróży:

Wdrażanie zmigrowanych aplikacji: Przypisz moduły równoważenia obciążenia z AWS i Google Cloud do ich odpowiedników w Azure na potrzeby obciążeń wielochmurowych.

  • Last updated on