Udostępnij za pośrednictwem


Omówienie zasad usługi Azure Web Application Firewall (WAF)

Zasady zapory aplikacji internetowej zawierają wszystkie jej ustawienia i konfiguracje. Obejmuje to wykluczenia, reguły niestandardowe, reguły zarządzane itd. Te zasady są następnie skojarzone z bramą aplikacji (globalną), odbiornikiem (na lokację) lub regułą opartą na ścieżkach (per-URI), aby zaczęły obowiązywać.

Nie ma limitu liczby zasad, które można utworzyć. Po utworzeniu zasad należy skojarzyć je z bramą aplikacji, aby zaczęły obowiązywać. Może być kojarzona z dowolną kombinacją bram aplikacyjnych, odbiorników i reguł opartych na ścieżkach.

Uwaga

Usługa Application Gateway ma dwie wersje SKU WAF: Application Gateway WAF_v1 i Application Gateway WAF_v2. Powiązania zasad WAF są obsługiwane tylko dla jednostki SKU Application Gateway WAF_v2.

Globalna polityka zapory aplikacji internetowej

Po globalnym skojarzeniu zasad zapory aplikacji internetowej Application Gateway każda witryna za zaporą WAF jest chroniona tymi samymi regułami zarządzanymi, regułami niestandardowymi, wykluczeniami i innymi skonfigurowanymi ustawieniami.

Jeśli chcesz, aby jedna zasada obowiązywała we wszystkich lokalizacjach, możesz skojarzyć ją z bramą aplikacyjną. Aby uzyskać więcej informacji, zobacz Tworzenie zasad zapory aplikacji internetowej dla usługi Application Gateway w celu utworzenia i zastosowania zasad WAF przy użyciu portalu Azure.

Zasady zapory aplikacji internetowej dla strony

Za pomocą zasad zapory aplikacji internetowej dla poszczególnych witryn można chronić wiele witryn z różnymi potrzebami dotyczącymi zabezpieczeń w ramach jednej zapory aplikacji internetowej przy użyciu zasad dla poszczególnych witryn. Jeśli na przykład za zaporą aplikacji internetowej (WAF) znajduje się pięć witryn, można mieć pięć oddzielnych zasad WAF (jedną dla każdego nasłuchującego), aby dostosować wykluczenia, reguły niestandardowe, zarządzane zestawy reguł oraz wszystkie inne ustawienia WAF dla każdej witryny.

Przypuśćmy, że do twojej bramy aplikacji zastosowano zasady globalne. Należy zastosować różne zasady do odbiornika w tej bramie aplikacji. Polityka słuchacza teraz zaczyna obowiązywać tylko dla tego słuchacza. Globalna polityka bramy aplikacji nadal ma zastosowanie do wszystkich innych odbiorników i zasad opartych na ścieżce, do których nie są przypisane określone polityki.

Polityka dla poszczególnych identyfikatorów URI

Aby jeszcze bardziej dostosować ustawienia na poziomie identyfikatora URI, można skojarzyć politykę WAF z regułą opartą na ścieżkach. Jeśli w jednej witrynie istnieją pewne strony, które wymagają różnych zasad, możesz wprowadzić zmiany w zasadach zapory aplikacji internetowej, które mają wpływ tylko na dany identyfikator URI. Może to dotyczyć strony płatności lub strony do logowania, lub jakichkolwiek innych URI, które wymagają jeszcze bardziej szczegółowej polityki zapory aplikacji internetowej niż inne strony chronione przez WAF.

Podobnie jak w przypadku zasad zapory aplikacji internetowej dla lokacji, bardziej szczegółowe zasady zastępują mniej szczegółowe. Oznacza to, że zasada dla każdego URI na mapie ścieżek URL zastępuje wszystkie zasady WAF na poziomie witryny lub globalne zasady WAF wyżej w hierarchii.

Przykład

Załóżmy, że masz trzy witryny: contoso.com, fabrikam.com i adatum.com wszystkie za tą samą bramą aplikacji. Chcesz zastosować zaporę aplikacji internetowej do wszystkich trzech witryn, ale potrzebujesz dodatkowych zabezpieczeń dla adatum.com, ponieważ to jest miejsce, gdzie klienci odwiedzają, przeglądają i kupują produkty.

Możesz zastosować globalne zasady dla zapory aplikacji internetowej (WAF), używając podstawowych ustawień, wykluczeń lub reguł niestandardowych, jeśli to konieczne, aby zapobiec blokowaniu ruchu przez fałszywe alarmy. W takim przypadku nie ma potrzeby uruchamiania globalnych reguł iniekcji SQL, ponieważ fabrikam.com i contoso.com to strony statyczne bez zaplecza SQL. Dzięki temu można wyłączyć te reguły w zasadach globalnych.

Ta globalna zasada jest odpowiednia dla contoso.com i fabrikam.com, ale należy zachować większą ostrożność w przypadku adatum.com, gdzie są obsługiwane informacje logowania i płatności. Zasady dla poszczególnych lokacji można zastosować do odbiornika Adatum i pozostawić uruchomione reguły SQL. Załóżmy również, że istnieje plik cookie blokujący jakiś ruch, dzięki czemu można utworzyć wykluczenie dla tego pliku cookie, aby zatrzymać wynik fałszywie dodatni.

Identyfikator URI adatum.com/payments to miejsce, w którym należy zachować ostrożność. Dlatego zastosuj inne zasady dla tego identyfikatora URI i pozostaw włączone wszystkie reguły, a także usuń wszystkie wykluczenia.

W tym przykładzie masz zasady globalne, które mają zastosowanie do dwóch lokacji. Masz politykę dla każdej witryny, która ma zastosowanie do jednej witryny, a następnie politykę URI, która dotyczy jednej określonej reguły opartej na ścieżce. Zobacz Konfigurowanie zasad zapory aplikacji internetowej dla witryn przy użyciu programu Azure PowerShell, aby uzyskać odpowiedni skrypt PowerShell do tego przykładu.

Istniejące konfiguracje zapory aplikacji internetowej

Wszystkie nowe ustawienia zapory aplikacji internetowej (reguły niestandardowe, konfiguracje zestawu reguł zarządzanych, wykluczenia itd.) istnieją w polityce zapory aplikacji internetowej. Jeśli masz istniejący WAF, te ustawienia mogą wciąż być obecne w jego konfiguracji. Aby uzyskać więcej informacji na temat przejścia na nową politykę WAF, migrowanie konfiguracji WAF do polityki WAF.

Następne kroki