Azure Firewall i inspekcja ruchu

Azure Firewall to zarządzana, natywna dla chmury usługa zabezpieczeń sieci, która zapewnia scentralizowaną inspekcję ruchu i filtrowanie dla sieci wirtualnych Azure. W przeciwieństwie do sieciowych grup zabezpieczeń działających w warstwie 4, Azure Firewall sprawdza ruch w warstwach od 3 do 7. Ta funkcja umożliwia filtrowanie w pełni kwalifikowanej nazwy domeny (FQDN), analizę zagrożeń, wykrywanie i zapobieganie włamaniom (IDPS) oraz inspekcję protokołu TLS. Wdrażasz usługę Azure Firewall w dedykowanej podsieci centralnej sieci wirtualnej i kierujesz ruch z zasobów sieci podrzędnych przez zaporę w celu kontroli, zanim dotrze on do miejsca docelowego.

W tym artykule wyjaśniono, jak wybrać odpowiednią jednostkę SKU Azure Firewall, umieścić zaporę w topologii piasty i szprych, skonfigurować typy reguł i zintegrować je z usługami uzupełniającymi, takimi jak brama translatora adresów sieciowych i serwer routingu. Azure Firewall jest jedną z trzech podstawowych usług bezpieczeństwa sieci Azure, obok Azure DDoS Protection i Azure Web Application Firewall.

Co opisano w tym artykule

Ten artykuł opisuje scentralizowaną inspekcję ruchu sieciowego z wykorzystaniem Azure Firewall. Dowiesz się więcej o:

• Wybór warstwy SKU na podstawie wymagań w zakresie zabezpieczeń i wrażliwości obciążenia.
• Umiejscowienie koncentratora i wzorce tras zdefiniowanych przez użytkownika (UDR), które wymuszają kierowanie ruchu przez zaporę.
• Logika przetwarzania reguł dla reguł DNAT, sieci i aplikacji.
• Wymuszone tunelowanie w środowiskach wymagających inspekcji lokalnej.
• Funkcje inspekcji TLS i systemu IDPS w warstwie Premium.
• Integracja z usługą NAT Gateway do skalowania portów SNAT oraz z usługą Route Server do routingu opartego na BGP.

Kto potrzebuje tego artykułu

Wdróż Azure Firewall, gdy obciążenia wymagają co najmniej jednej z następujących funkcji:

• Scentralizowane zarządzanie ruchem wychodzącym: musisz ograniczyć, z którymi zewnętrznymi nazwami FQDN i adresami URL mogą łączyć się Twoje obciążenia, wykraczając poza to, co zapewniają reguły NSG oparte na adresach IP.
• Inspekcja ruchu wschód–zachód: Ruch między sieciami wirtualnymi typu spoke musi przechodzić przez punkt inspekcji stanowej, zanim zapora zezwoli na jego przepływ.
• Rejestrowanie wymagane przez przepisy: przepisy wymagają pełnej widoczności na poziomie warstwy 7 w zakresie dozwolonych i blokowanych połączeń, z dokładnością do poziomu FQDN.
• Ochrona przed zagrożeniami: do identyfikowania złośliwych wzorców ruchu, w tym połączeń zwrotnych do serwerów dowodzenia i kontroli (C2), prób wykorzystania luk oraz ruchu bocznego, potrzebujesz systemu wykrywania włamań i zapobiegania włamaniom opartego na sygnaturach.
• Inspekcja protokołu TLS: należy odszyfrować i sprawdzić zaszyfrowany ruch (HTTPS) pod kątem zagrożeń, zanim osiągnie obciążenia lub opuści sieć.

Organizacje, które potrzebują jedynie filtrowania pakietów warstwy 4 bez obsługi nazw FQDN, powinny rozważyć sieciowe grupy zabezpieczeń i grupy zabezpieczeń aplikacji jako prostszą i tańszą alternatywę.

Nacisk na strategię lift-and-shift: Przełóż bazę reguł lokalnej zapory do zasad Azure Firewall. Zacznij od reguł sieci dla ruchu innego niż HTTP/S oraz reguł aplikacji do filtrowania opartego na nazwach FQDN. Rozpocznij od szerokich zasad zezwalających podczas migracji, a następnie zaostrz reguły po przeanalizowaniu dzienników Azure Firewall.

Modernizuj fokus: Użyj Azure Firewall jako scentralizowanego punktu SNAT i DNAT w centrum. Kontroluj ruch między spoke’ami aplikacyjnymi oraz między spoke’ami a Internetem, używaj reguł aplikacji i tagów FQDN dla ruchu wychodzącego z usług AKS i Azure PaaS oraz zaplanuj inspekcję TLS tam, gdzie warstwy aplikacji wymieniają dane wrażliwe.

Fokus między chmurami: Wdróż Azure Firewall w zabezpieczonym koncentratonie wirtualnym, aby sprawdzić ruch tranzytowy między chmurami. Skonfiguruj reguły sieciowe dla ruchu przechodzącego przez tunel IPSec z AWS lub Google Cloud i użyj IDPS do monitorowania nietypowych wzorców ruchu między połączonymi chmurami.

Warstwy SKU usługi Azure Firewall

Azure Firewall jest dostępna w trzech wariantach SKU. Każda warstwa opiera się na możliwościach poprzedniej warstwy.

Capability	Basic	Standard	Premium
Stanowa inspekcja pakietów	✔	✔	✔
Filtrowanie FQDN (ruch wychodzący)	✔	✔	✔
Reguły sieci (IP, port, protokół)	✔	✔	✔
Reguły aplikacji (nazwa FQDN, adres URL)	✔	✔	✔
Reguły NAT (DNAT)	✔	✔	✔
Filtrowanie analizy zagrożeń	Tylko alert	✔ (Alert + Odmowa)	✔ (Alert + Odmowa)
Serwer proxy DNS	✗	✔	✔
Kategorie sieci Web	✗	✔	✔
IDPS (wykrywanie i zapobieganie włamaniom)	✗	✗	✔
Inspekcja TLS	✗	✗	✔
Filtrowanie adresów URL (pełna ścieżka)	✗	✗	✔
Jawny serwer pośredniczący	✗	✔	✔
Dostępność regionu	Ograniczone regiony	Wszystkie regiony	Wszystkie regiony
Najlepsze dla	Tworzenie i testowanie, małe obciążenia	Produkcja standardowa	Wysoki poziom zabezpieczeń oparty na zgodności

Jak wybrać SKU

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

• Wybierz opcję Basic, jeśli masz środowiska deweloperskie/testowe lub małe obciążenia robocze, które wymagają filtrowania ruchu wychodzącego opartego na nazwach FQDN bez filtrowania opartego na analizie zagrożeń (tryb blokowania) lub zaawansowanej inspekcji. Podstawowy SKU obejmuje dane analityczne o zagrożeniach w trybie tylko alertów, ale nie obsługuje trybu blokowania, serwera proxy DNS ani kategorii witryn internetowych. Podstawowa jednostka SKU wymaga dedykowanego AzureFirewallManagementSubnet (minimum /26) wraz z AzureFirewallSubnet i jest dostępna tylko w wybranych regionach.
• Wybierz standard dla obciążeń produkcyjnych, które wymagają filtrowania opartego na analizie zagrożeń, serwera proxy DNS na potrzeby rozpoznawania reguł FQDN, filtrowania kategorii sieci Web i scentralizowanego zarządzania zasadami za pośrednictwem Azure Firewall Manager. Standard zapewnia pełny mechanizm inspekcji stanowej z kanałami danych analizy zagrożeń, który blokuje połączenia z adresami IP i domenami znanymi jako złośliwe.
• Wybierz pozycję Premium , gdy wymagania prawne lub wymagania dotyczące zabezpieczeń nakazują inspekcję szyfrowanego ruchu, identyfikatory IDPS oparte na podpisach z stale aktualizowanymi regułami (ponad 67 000 podpisów w ponad 50 kategoriach, aktualizowane w czasie rzeczywistym) lub pełne filtrowanie ścieżek URL poza nazwą FQDN. Premium jest wymagana w przypadku takich branż jak usługi finansowe, opieka zdrowotna i instytucje rządowe, w których wymagana jest zaszyfrowana inspekcja ruchu.

Note

Uaktualnij z warstwy Standard do warstwy Premium bez ponownego wdrażania zapory. Przejście z warstwy Premium do Standard wymaga ponownego wdrożenia.

Wzorzec rozmieszczenia centrum i routingu UDR

Wdróż Azure Firewall w dedykowanej podsieci o nazwie dokładnie AzureFirewallSubnet w centralnej sieci wirtualnej. Ta podsieć wymaga minimalnego rozmiaru /26 (59 adresów IP do użycia).

Architektura routingu

W topologii piasty i szprych podsieci obciążenia szprych nie kierują ruchu bezpośrednio do Internetu ani do innych szprych. Zamiast tego trasy zdefiniowane przez użytkownika w każdej podsieci typu spoke ustawiają trasę domyślną (0.0.0.0/0) jako prywatny adres IP usługi Azure Firewall. Ten schemat gwarantuje, że cały ruch, zarówno północ–południe (skierowany do Internetu), jak i wschód–zachód (między odnogami), przechodzi przez zaporę sieciową w celu inspekcji.

Wzorzec konfiguracji UDR:

Tabela tras (zastosowana do)	Prefiks adresu	Typ następnego skoku	Adres następnego skoku
Podsieć podrzędna A	0.0.0.0/0	Urządzenie wirtualne	Prywatny adres IP zapory
Podsieć podrzędna A	10.1.0.0/16 (inna szprycha)	Urządzenie wirtualne	Prywatny adres IP zapory
Podsieć odgałęzienia B	0.0.0.0/0	Urządzenie wirtualne	Prywatny adres IP zapory
Podsieć odgałęzienia B	10.0.0.0/16 (inna szprycha)	Urządzenie wirtualne	Prywatny adres IP zapory

Sam element AzureFirewallSubnet nie wymaga tras UDR w większości scenariuszy, ponieważ zapora używa tras systemowych do docierania do sieci typu spoke poprzez komunikację równorzędną sieci wirtualnych. Podczas integracji z Azure Route Server podsieć zapory uczy się tras za pośrednictwem protokołu BGP. Takie podejście eliminuje konieczność ręcznej konserwacji tras w miarę wzrostu sieci.

Tip

Azure Virtual Network Manager może zautomatyzować konfigurację tabel tras tak, aby jako następny przeskok wykorzystywały usługę Azure Firewall, co zmniejsza potrzebę ręcznego zarządzania trasami zdefiniowanymi przez użytkownika (UDR) w wielu subskrypcjach typu spoke.

Wymagania dotyczące podsieci

Podsieć	Minimalny rozmiar	Purpose	Notatki
AzureFirewallSubnet	/26	Obsługuje wystąpienia usługi Azure Firewall	Musi być nazwana dokładnie AzureFirewallSubnet
AzureFirewallManagementSubnet	/26	Ruch zarządzania (tylko jednostka SKU w warstwie Podstawowa)	Wymagana dla jednostki SKU w warstwie Podstawowa; opcjonalne w przypadku wymuszonego tunelowania w innych jednostkach SKU

Aby uzyskać więcej informacji na temat projektowania topologii sieci wirtualnej typu koncentrator i planowania podsieci, zobacz Topologia koncentrator-szprycha.

Typy reguł i logika przetwarzania

Azure Firewall przetwarza reguły za pomocą zasad Azure Firewall. Reguły są zorganizowane w kolekcje reguł, które są pogrupowane w grupy kolekcji reguł. Zapora ocenia reguły w następującej kolejności priorytetu:

1. Reguły DNAT (translacja docelowych adresów sieciowych): Przetwarzane jako pierwsze. Przetłumacz ruch przychodzący z publicznego adresu IP na prywatny adres IP za zaporą.
2. Reguły sieci: przetworzone w sekundzie. Zezwalaj na ruch na podstawie źródłowego adresu IP, docelowego adresu IP, portu i protokołu (warstwa 3/4).
3. Reguły aplikowane: przetwarzane jako ostatnie. Zezwalaj lub blokuj ruch wychodzący na podstawie nazwy FQDN, adresu URL lub kategorii stron internetowych (warstwa 7).

W ramach każdego typu reguły grupy kolekcji reguł są oceniane według priorytetu (najniższa liczba = najwyższy priorytet). W grupie kolekcje reguł są oceniane według priorytetu. Pierwsza reguła dopasowania określa akcję (Zezwalaj lub Odmawiaj) i zatrzymuje dalszą ocenę.

Reguły DNAT

Użyj reguł DNAT, aby udostępnić usługi wewnętrzne przez publiczny adres IP zapory. Zapora tłumaczy adres docelowy z publicznego adresu IP na prywatny adres IP usługi zaplecza. Typowe scenariusze obejmują:

• Uwidacznianie wewnętrznego serwera internetowego za pośrednictwem publicznego adresu IP zapory na porcie 443
• Zapewnianie kontrolowanego dostępu RDP lub SSH do serwera przesiadkowego bez przypisywania publicznego adresu IP do maszyny wirtualnej
• Publikowanie usług innych niż HTTP/S, które wymagają dostępu przychodzącego z Internetu

Example: Translate inbound TCP 443 on firewall public IP → 10.1.2.4:443 (internal web server)

Reguły DNAT automatycznie dodają odpowiednią regułę sieciową, która zezwala na przetłumaczony ruch. Po dopasowaniu reguły DNAT ruch jest tłumaczony i dozwolony bez dalszego przetwarzania reguł sieci. W przypadku zabezpieczeń ogranicz źródłowy adres IP w regułach DNAT do określonych źródeł internetowych zamiast używać symboli wieloznacznych.

Reguły sieci

Reguły sieciowe filtrują ruch w warstwach 3 i 4. Użyj reguł sieciowych, gdy musisz zezwolić na ruch lub go zablokować na podstawie źródłowego adresu IP, docelowego adresu IP, portu docelowego i protokołu. Reguły sieciowe nie wykonują rozpoznawania nazw FQDN. Działają one ściśle na adresach IP. Typowe przypadki użycia to:

• Zezwalanie na komunikację szprychowo-szprychową dla określonych portów (na przykład SQL Server na tcp 1433).
• Zezwalanie NTP (UDP 123) na określone serwery czasowe.
• Blokowanie ruchu do znanych złośliwych zakresów adresów IP przy użyciu reguł odmowy.
• Zezwalanie na ICMP na potrzeby diagnostyki sieci między określonymi podsieciami.

Reguły sieci obsługują typy protokołów TCP, UDP, ICMP i Any. Jako źródło i miejsce docelowe można określić adresy IP, zakresy adresów IP, tagi usługi i grupy adresów IP.

Reguły aplikacji

Reguły aplikacji filtrują wychodzący ruch HTTP/S i MSSQL na podstawie nazw FQDN, adresów URL i kategorii sieci Web. Reguły aplikacji wymagają funkcji serwera proxy DNS na potrzeby rozpoznawania nazw FQDN. Użyj reguł aplikacji, gdy:

• Musisz zezwolić na dostęp do określonych nazw FQDN (na przykład *.microsoft.com lub storage.blob.core.windows.net).
• Chcesz filtrować według ścieżki adresu URL (tylko dla jednostki SKU Premium), na przykład zezwalając na github.com/myorg/*, ale blokując inne ścieżki GitHub.
• Musisz zezwolić na całe kategorie witryn internetowych lub je zablokować (na przykład zezwolić na „Narzędzia dla deweloperów” i zablokować „Hazard”).

Reguły aplikacji udostępniają tagi FQDN dla typowych usług Azure (takich jak Windows Update, Azure Backup i HDInsight), które upraszczają tworzenie reguł przez grupowanie wymaganych nazw FQDN w jeden tag.

Ważna

Po włączeniu proxy DNS w usłudze Azure Firewall zapora działa jako resolver DNS dla obciążeń roboczych. Skonfiguruj ustawienia DNS sieci wirtualnej, aby wskazywały na prywatny adres IP zapory, aby reguły oparte na FQDN poprawnie się rozwiązywały. Aby uzyskać szczegółowe informacje na temat architektury DNS, zobacz Zabezpieczenia DNS i rozpoznawanie nazw prywatnych.

Działanie SNAT

Domyślnie usługa Azure Firewall stosuje mechanizm SNAT (translację źródłowego adresu sieciowego) do ruchu wychodzącego kierowanego do publicznych adresów IP. Zapora nie obsługuje ruchu SNAT, gdy miejsce docelowe jest prywatnym zakresem adresów IP (RFC 1918) ani wspólną przestrzenią adresową (RFC 6598). Zapora tłumaczy źródłowy adres IP połączeń powiązanych z Internetem na jeden z jego publicznych adresów IP. Każdy publiczny adres IP zapewnia 2 496 portów SNAT dla każdego wystąpienia zaplecza.

W przypadku obciążeń z dużą liczbą połączeń wychodzących należy zintegrować je z bramą NAT, aby zwiększyć skalę do 64 512 portów na publiczny adres IP (do 16 publicznych adresów IP, co daje łącznie około miliona portów SNAT).

Po skojarzeniu bramy NAT z elementem AzureFirewallSubnet cały wychodzący ruch internetowy automatycznie korzysta z publicznych adresów IP bramy NAT. Zapora nadal inspekcjonuje ruch, ale translację SNAT realizuje brama NAT. Nie występuje podwójny NAT.

Note

Brama NAT używana ze strefowo nadmiarową usługą Azure Firewall wymaga jednostki SKU StandardV2 bramy NAT. Usługa NAT Gateway nie jest obsługiwana w architekturach zabezpieczonego koncentratora Virtual WAN.

Menedżer zapory i dziedziczenie polityk

Usługa Azure Firewall Manager udostępnia scentralizowane zarządzanie zasadami zabezpieczeń i trasami w wielu instancjach usługi Azure Firewall. Kluczowe możliwości to:

• Hierarchia zasad: utwórz podstawowe (nadrzędne) zasady z regułami dla całej organizacji i zezwól zespołom podrzędnym na tworzenie zasad podrzędnych dziedzicujących po obiekcie nadrzędnym. Reguły nadrzędne zawsze mają pierwszeństwo niezależnie od wartości priorytetu podrzędnego.
• Zarządzanie międzyregionalne: Zasada zapory jest zasobem globalnym, który można skojarzyć z zaporami w dowolnym regionie lub w ramach dowolnej subskrypcji.
• Zarządzanie wieloma zaporami: stosowanie spójnego stanu zabezpieczeń w zaporach koncentratora w różnych regionach lub w zabezpieczonych centrach Virtual WAN.

Reguły NAT są specyficzne dla zapory i nie są dziedziczone z zasad nadrzędnych. Tryb analizy zagrożeń jest dziedziczony, ale można go zastąpić tylko bardziej rygorystycznym trybem w zasadach podrzędnych. Polisa z zerowym lub jednym powiązaniem z zaporą jest dostępna bez dodatkowych opłat. Dodatkowe powiązania wiążą się z opłatami.

Wymuszone tunelowanie

W niektórych środowiskach regulacyjnych cały ruch związany z Internetem musi najpierw kierować się przez lokalny punkt kontrolny przed dotarciem do Internetu. Azure Firewall obsługuje wymuszone tunelowanie, aby spełnić to wymaganie.

Po włączeniu wymuszonego tunelowania:

• AzureFirewallManagementSubnet przenosi ruch związany z zarządzaniem zaporą bezpośrednio do internetu. Ta podsieć musi mieć trasę do 0.0.0.0/0 z następnym przeskokiem Internet. Nie można wymusić ruchu związanego z zarządzaniem przez inspekcję lokalną.
• AzureFirewallSubnet kieruje ruch obciążeń kierowany do internetu do lokalnej zapory sieciowej lub sieciowego urządzenia wirtualnego (NVA) innej firmy za pośrednictwem usługi ExpressRoute lub bramy VPN.
• Reguły DNAT nie są obsługiwane w trybie wymuszonego tunelowania, ponieważ ruch przychodzący nie może bezpośrednio dotrzeć do publicznego adresu IP zapory.
• Zapora nie wymaga publicznego adresu IP na urządzeniu AzureFirewallSubnet, gdy skonfigurujesz wymuszone tunelowanie, ponieważ cały ruch wychodzący jest kierowany ścieżką lokalną.

Użyj wymuszonego tunelowania, gdy zasady zgodności wymagają wglądu lokalnego całego ruchu powiązanego z Internetem lub gdy musisz połączyć Azure Firewall z istniejącym lokalnym stosem zabezpieczeń. Typowe scenariusze obejmują środowiska sektora usług finansowych podlegające przepisom dotyczącym lokalizacji danych oraz sieci rządowe z wymogami scentralizowanego wyjścia do internetu.

Ważna

W trybie wymuszonego tunelowania element AzureFirewallManagementSubnet wymaga własnego publicznego adresu IP oraz trasy zdefiniowanej przez użytkownika z adresem 0.0.0.0/0, ze wskazaniem Internetu jako następnego przeskoku. Ta konfiguracja zapewnia, że platforma Azure może utrzymać kanał zarządzania z zaporą.

Inspekcja protokołu TLS (Premium)

Azure Firewall Premium przechwytuje wychodzące połączenia HTTPS, odszyfrowuje ruch, sprawdza go pod kątem podpisów IDPS i reguł aplikacji, a następnie ponownie szyfruje i przekazuje je dalej. Ten proces wymaga pośredniego certyfikatu urzędu certyfikacji przechowywanego w Azure Key Vault.

Wymagania certyfikatu

Wymaganie	Specyfikacja
Typ certyfikatu	Pośredni urząd certyfikacji
Rozmiar klucza	Minimalna wersja RSA 2048-bitowa
Flaga urzędu certyfikacji	TRUE
Użycie klucza	KeyCertSign
Ważność	Co najmniej 1 rok do przodu
Magazyn	Azure Key Vault (musi być eksportowalny)

Zapora używa pośredniego certyfikatu urzędu certyfikacji do dynamicznego generowania certyfikatów serwera dla przechwyconych połączeń. Przeglądarki i aplikacje użytkowników końcowych muszą ufać głównemu urzędowi certyfikacji organizacji lub pośredniemu urzędowi certyfikacji w magazynie certyfikatów, aby uniknąć ostrzeżeń dotyczących zaufania.

System Wykrywania i Zapobiegania Włamaniom (IDPS)

Wersja Premium SKU obejmuje w pełni zarządzany silnik IDPS z ponad 67 000 reguł obejmujących ponad 50 kategorii. Sygnatury są aktualizowane na bieżąco — codziennie publikowanych jest od 20 do ponad 40 nowych reguł. IdPS działa w dwóch trybach:

• Tryb alertu: Rejestruje dopasowania sygnatur bez blokowania ruchu. Używaj podczas początkowego wdrożenia i dostrajania.
• Tryb alertu i odmowy: rejestruje i blokuje ruch zgodny z podpisami IDPS. Użyj w środowisku produkcyjnym po dostrajaniu.

Kategorie IDPS obejmują serwery dowodzenia i kontroli złośliwego oprogramowania, phishing, trojany, botnety, zestawy exploitów, luki w zabezpieczeniach oraz protokoły SCADA/ICS.

Caution

Inspekcja protokołu TLS wprowadza opóźnienie i ma wpływ na prywatność. Upewnij się, że zespoły ds. zgodności i prawnej organizacji zatwierdzają inspekcję zaszyfrowanego ruchu. W razie potrzeby wyklucz kategorie wrażliwe (opieka zdrowotna, bankowość), korzystając z reguł pomijania.

Filtrowanie ruchu wychodzącego w AKS

Gdy klastry Azure Kubernetes Service (AKS) wymagają kontrolowanego ruchu wychodzącego, Azure Firewall zapewnia filtrowanie wychodzące oparte na nazwie FQDN dla węzłów klastra. Bez filtrowania ruchu wychodzącego węzły usługi AKS mogą uzyskiwać dostęp do dowolnego internetowego punktu końcowego, co zwiększa obszar ataków na łańcuch dostaw i ataki eksfiltracji danych.

Aby zaimplementować ten wzorzec:

1. Wdróż AKS z wartością parametru outboundType ustawioną na userDefinedRouting oraz niestandardową tabelą tras w podsieci węzłów.
2. Ustaw trasę domyślną (0.0.0.0/0) na prywatny adres IP Azure Firewall.
3. Utwórz reguły aplikacji w zasadach zapory sieciowej, które zezwalają na nazwy FQDN wymagane przez usługę AKS (rejestry kontenerów, punkty końcowe serwera interfejsu API, repozytoria pakietów firmy Microsoft).
4. Utwórz reguły sieci dla wymaganych punktów końcowych innych niż HTTP/S (NTP, DNS, łączność tunelu).

Ten wzorzec zapewnia zespołom ds. zabezpieczeń wgląd i kontrolę nad tym, do jakich zewnętrznych punktów końcowych mogą dotrzeć węzły usługi AKS, umożliwiając jednocześnie prawidłowe działanie klastra. Wymagane nazwy FQDN różnią się w zależności od zestawu funkcji usługi AKS. Klastry korzystające z węzłów GPU, usługi Azure Monitor lub Azure Policy wymagają dodatkowych wpisów na liście zatwierdzonych.

Aby uzyskać szczegółowe informacje o wymaganiach dotyczących nazw FQDN i przykłady reguł, zobacz artykuł Używanie usługi Azure Firewall do ochrony wdrożeń AKS.

Note

Filtrowanie ruchu wychodzącego usługi AKS za pomocą Azure Firewall wymaga starannej koordynacji między zespołami platformy i aplikacji. Brak reguł FQDN powoduje niepowodzenia harmonogramowania podów i błędy pobierania obrazu. Zacznij od łagodnej polityki i zaostrz ją po zaobserwowaniu wzorców ruchu w dziennikach zapory.

Uwagi dotyczące projektowania

Fokus projektowania zapory typu lift-and-shift

• Przełóż reguły lokalnej zapory sieciowej do zasad Azure Firewall: używaj reguł sieciowych dla protokołów innych niż HTTP/S oraz reguł aplikacji dla miejsc docelowych korzystających z protokołu HTTP/S lub MSSQL, które wymagają filtrowania nazw FQDN.
• Zacznij od ogólnych reguł zezwalania, które odzwierciedlają bieżący stan zabezpieczeń, a następnie zaostrz je po migracji przy użyciu dzienników Azure Firewall w celu zidentyfikowania wymaganych miejsc docelowych i portów.
• Użyj grup adresów IP do modelowania stref źródłowych i docelowych, aby konserwacja reguł przebiegała zgodnie z istniejącymi granicami segmentacji.
• Włącz ustawienia diagnostyczne od razu, aby móc porównać wzorce ruchu w usłudze Azure z wzorcem bazowym środowiska lokalnego, zanim ograniczysz dostęp.

Modernizuj fokus projektu zapory

• Użyj zapory w centrum jako scentralizowanego punktu SNAT i DNAT dla aplikacyjnych sieci typu spoke, aby reguły ruchu przychodzącego i wychodzącego pozostawały w centrum zarządzanym przez dział IT.
• Włącz Azure Firewall Premium, gdy między warstwami aplikacji wymagana jest inspekcja ruchu TLS typu east-west lub wymuszanie zasad IDPS w środowisku produkcyjnym.
• Użyj tagów FQDN i reguł aplikacji, aby zezwolić na komunikację wymaganą przez usługę AKS i Azure PaaS bez konieczności utrzymywania długich list docelowych adresów IP.
• Zapoznaj się z wymaganiami DNAT w projekcie usługi Front Door lub Application Gateway, aby przepływy przychodzące docierały do szprych zaplecza tylko przez zatwierdzone ścieżki inspekcji.

Fokus projektowania zapory między chmurami

• Wdróż Azure Firewall w zabezpieczonym koncentratonie wirtualnym, gdy Azure jest punktem tranzytowym dla gałęzi, Azure i innych sieci w chmurze.
• Użyj reguł sieciowych, aby inspekcjonować ruch tunelu IPSec z usługi AWS Transit Gateway, wirtualnych bram prywatnych AWS lub przyłączy Google Cloud VPN po dotarciu tras do platformy Azure.
• Włącz usługę IDPS, aby wykrywać nietypowe wzorce ruchu wschód-zachód oraz ruchu między chmurami, które mogą wskazywać na ruch boczny między środowiskami chmurowymi.
• Włącz filtrowanie na podstawie analizy zagrożeń, aby blokować znane złośliwe cele we wszystkich połączonych chmurach za pomocą jednych zasad.

Prerequisites

Przed wdrożeniem Azure Firewall:

• AzureFirewallSubnet: Sieć wirtualna centrum musi zawierać dedykowaną podsieć o nazwie AzureFirewallSubnet o minimalnym rozmiarze /26. Zobacz Projektowanie sieci wirtualnej i podsieci , aby uzyskać wskazówki dotyczące planowania podsieci.
• Topologia piasty i szprych lub Virtual WAN: Wdróż usługę Azure Firewall w centralnej piaście, która kieruje ruchem z sieci szprych. Zobacz Topologia piasty i szprych lub Virtual WAN, aby uzyskać informacje o opcjach topologii.
• Plan adresów IP: Zarezerwuj przestrzeń adresową dla podsieci zapory, podsieć zarządzania (w przypadku korzystania z wymuszonego tunelowania) i wszystkie publiczne adresy IP. Zobacz Planowanie adresów IP.
• Azure Firewall Manager: Użyj Azure Firewall Manager, jeśli potrzebujesz hierarchii zasad, która umożliwia udostępnianie reguł bazowych między wieloma wystąpieniami zapory.
• Obszar roboczy usługi Log Analytics: Utwórz obszar roboczy dla dzienników diagnostycznych zapory przed wdrożeniem, aby można było monitorować ruch i rozwiązywać problemy z regułami już od pierwszego dnia.

Zagadnienia dotyczące zabezpieczeń

• Rejestrowanie: włącz ustawienia diagnostyczne, aby wysyłać dzienniki Azure Firewall do obszaru roboczego Log Analytics. Ustrukturyzowane dzienniki zapewniają widoczność na poziomie FQDN w odniesieniu do każdego dozwolonego i zablokowanego połączenia, wspierając audyt i analizę śledczą.
• Dostępność: wdróż Azure Firewall w różnych strefach dostępności, aby zmaksymalizować umowę SLA dostępności. Aby uzyskać informacje o bieżących wartościach procentowych umowy SLA, zobacz umowa SLA dla Azure Firewall.
• Ochrona warstwowa: Azure Firewall uzupełnia, ale nie zastępuje sieciowych grup zabezpieczeń. Zastosuj sieciowe grupy zabezpieczeń na poziomie podsieci i karty sieciowej na potrzeby mikrosegmentacji. Użyj zapory do centralnego zarządzania zasadami, wywiadu o zagrożeniach i inspekcji warstwy 7.
• Dostosuj zakres inspekcji do potrzeb: Wymuszanie każdego przepływu przez zaporę, w tym między warstwami wewnątrz aplikacji, takimi jak komunikacja od warstwy webowej do warstwy aplikacji oraz od aplikacji do bazy danych, zwiększa opóźnienia i koszt przetwarzania na gigabajt. Użyj NSG i ASG dla ruchu wschód-zachód między zaufanymi warstwami, a inspekcję zapory stosuj wyłącznie do ruchu przekraczającego granicę zaufania: do Internetu, między szprychami, hybrydowego lub między chmurami. Takie podejście utrzymuje zaporę skoncentrowaną na ruchu, który korzysta z inspekcji i pozwala uniknąć niepotrzebnych kosztów.
• Ochrona przed atakami DDoS: ochrona publicznych adresów IP skojarzonych z Azure Firewall przy użyciu usługi Azure DDoS Protection. Zobacz Ochrona przed atakami DDoS.
• Ruch ExpressRoute: Gdy używasz usługi ExpressRoute, skonfiguruj trasy UDR tak, aby kierować ruch prywatnego peeringu przez usługę Azure Firewall w celu inspekcji hybrydowych przepływów ruchu.

Powiązane artykuły

• Topologia sieci typu piasta-szprychy: Sieć wirtualna piasty, w której wdrażasz Azure Firewall.
• Dostęp wychodzący do Internetu: wzorce kontroli ruchu wychodzącego przy użyciu Azure Firewall i NAT Gateway.
• Web Application Firewall: Ochrona protokołu HTTP/S w warstwie 7, która uzupełnia inspekcję na poziomie sieci Azure Firewall.
• Zabezpieczenia DNS i rozpoznawanie nazw prywatnych: konfiguracja serwera proxy DNS, która umożliwia reguły oparte na nazwach FQDN.
• Czym jest zabezpieczenie sieci na platformie Azure?: Centrum wiedzy porównujące Azure Firewall, DDoS Protection i Web Application Firewall.

Learn more

• Dokumentacja usługi Azure Firewall
• Funkcje usługi Azure Firewall
• Funkcje usługi Azure Firewall — wersja Premium
• omówienie Azure Firewall Manager
• Wdrażanie i konfigurowanie Azure Firewall
• Cennik usługi Azure Firewall

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 zmigrowanej sieci: zweryfikuj łączność i wydajność przy użyciu Network Watcher po skonfigurowaniu zapory.

Kolejny etap procesu modernizacji:

Chroń swoje aplikacje internetowe za pomocą WAF: Dodaj zaporę Web Application Firewall w usłudze Front Door lub Application Gateway dla aplikacji internetowych skierowanych do klientów.

Kolejny krok w Twojej wielochmurowej podróży:

Skonfiguruj monitorowanie między chmurami: Środowiska wielochmurowe są trudniejsze w diagnozowaniu i rozwiązywaniu problemów operacyjnych. Monitorowanie jest niezbędne, a nie opcjonalne.