Brána firewall a Application Gateway pro virtuální sítě

Pokud chcete zabezpečit úlohy aplikací Azure, měli byste v samotných aplikacích používat ochranná opatření, jako je ověřování a šifrování. Do virtuálních sítí můžete také přidat vrstvy zabezpečení, které hostují aplikace. Tyto vrstvy zabezpečení chrání příchozí toky aplikace před nezamýšleným využitím. Omezují také odchozí toky na internet jenom na ty koncové body, které vaše aplikace vyžaduje. Tento článek popisuje služby zabezpečení virtuální sítě Azure, jako jsou Azure DDoS Protection, Azure Firewall a Aplikace Azure Gateway, kdy použít jednotlivé služby a možnosti návrhu sítě, které kombinují obě možnosti.

• Azure DDoS Protection v kombinaci s osvědčenými postupy návrhu aplikací poskytuje vylepšené funkce pro zmírnění rizik DDoS, které poskytují větší ochranu před útoky DDoS. Službu Azure DDOS Protection byste měli povolit v jakékoli hraniční virtuální síti.
• Azure Firewall je spravovaná brána firewall nové generace, která nabízí překlad síťových adres (NAT). Azure Firewall zakládají filtrování paketů na ip adresách a portech TCP/UDP (Transmission Control Protocol) a TCP/UDP (Transmission Control Protocol) nebo na atributech HTTP(S) nebo SQL založených na aplikacích. Azure Firewall také používá analýzu hrozeb Od Microsoftu k identifikaci škodlivých IP adres. Další informace najdete v dokumentaci ke službě Azure Firewall.
• Azure Firewall Premium zahrnuje všechny funkce služby Azure Firewall Standard a další funkce, jako je kontrola protokolu TLS a detekce neoprávněných vniknutí a ochrana (IDPS).
• Aplikace Azure Gateway je nástroj pro vyrovnávání zatížení spravovaného webového provozu a úplný reverzní proxy server HTTP,který může provádět šifrování a dešifrování protokolu SSL (Secure Socket Layer). Application Gateway zachovává původní IP adresu klienta v hlavičce HTTP s předáváním X. Application Gateway také používá firewall webových aplikací ke kontrole webového provozu a detekci útoků na vrstvě HTTP. Další informace najdete v dokumentaci ke službě Application Gateway.
• Firewall webových aplikací Azure (WAF) je volitelný doplněk ke službě Aplikace Azure Gateway. Poskytuje kontrolu požadavků HTTP a brání škodlivým útokům ve webové vrstvě, jako je injektáž SQL nebo skriptování mezi weby. Další informace najdete v dokumentaci ke službě Firewall webových aplikací.

Tyto služby Azure doplňují. Jedna nebo druhá může být pro vaše úlohy nejvhodnější, nebo je můžete použít společně pro optimální ochranu v síťové i aplikační vrstvě. Pomocí následujícího rozhodovacího stromu a příkladů v tomto článku určete nejlepší možnost zabezpečení pro virtuální síť vaší aplikace.

Azure Firewall a Aplikace Azure Gateway používají různé technologie a podporují cenné papíry různých toků:

V závislosti na síťových tocích, které aplikace vyžaduje, se návrh může lišit podle jednotlivých aplikací. Následující diagram nabízí zjednodušený rozhodovací strom, který pomáhá zvolit doporučený přístup pro aplikaci. Rozhodnutí závisí na tom, jestli je aplikace publikovaná prostřednictvím HTTP(S) nebo jiného protokolu:

Tento článek se zabývá široce doporučenými návrhy z vývojového diagramu a dalšími, které jsou použitelné v méně běžných scénářích:

• Samotná služba Azure Firewall, pokud ve virtuální síti nejsou žádné webové aplikace. Bude řídit příchozí provoz do aplikací i odchozí provoz.
• Samotná služba Application Gateway, pokud jsou ve virtuální síti jenom webové aplikace, a skupiny zabezpečení sítě (NSG) poskytují dostatečné filtrování výstupu. Funkce poskytované službou Azure Firewall můžou bránit mnoha scénářům útoku (například exfiltrace dat, IDPS atd.). Z tohoto důvodu se samotný scénář služby Application Gateway obvykle nedoporučuje a proto není zdokumentovaný a není ve vývojovém diagramu výše.
• Azure Firewall a Application Gateway paralelně, což je jeden z nejběžnějších návrhů. Tuto kombinaci použijte, pokud chcete Aplikace Azure Gateway chránit aplikace HTTP(S) před webovými útoky a azure Firewall k ochraně všech ostatních úloh a filtrování odchozího provozu.
• Application Gateway před službou Azure Firewall, když chcete, aby služba Azure Firewall kontroluje veškerý provoz, WAF chrání webový provoz a aplikaci, aby věděla zdrojovou IP adresu klienta. Tento návrh s kontrolou služby Azure Firewall Premium a TLS podporuje také kompletní scénář SSL.
• Azure Firewall před službou Application Gateway, pokud chcete, aby služba Azure Firewall kontroluje a filtruje provoz před dosažením služby Application Gateway. Vzhledem k tomu, že Azure Firewall nešifruje provoz HTTPS, jsou funkce, které přidává do služby Application Gateway, omezené. Tento scénář není zdokumentovaný ve vývojovém diagramu výše.

V poslední části tohoto článku jsou popsány varianty předchozích základních návrhů. Mezi tyto varianty patří:

• Místní klienti aplikací.
• Hvězdicové sítě.
• Implementace Azure Kubernetes Service (AKS)

Můžete přidat další reverzní proxy služby, jako je brána SLUŽBY API Management nebo Azure Front Door. Nebo můžete prostředky Azure nahradit síťovými virtuálními zařízeními třetích stran.

Pouze azure Firewall

Pokud ve virtuální síti nejsou žádné webové úlohy, které by mohly využívat WAF, můžete použít pouze službu Azure Firewall. Návrh v tomto případě je jednoduchý, ale kontrola toku paketů pomůže pochopit složitější návrhy. V tomto návrhu se veškerý příchozí provoz odesílá do služby Azure Firewall prostřednictvím tras definovaných uživatelem pro připojení z místních nebo jiných virtuálních sítí Azure. Je adresovaná veřejné IP adrese služby Azure Firewall pro připojení z veřejného internetu, jak ukazuje následující diagram. Odchozí provoz z virtuálních sítí Azure se odesílá do brány firewall přes trasy definované uživatelem, jak je znázorněno v následujícím dialogovém okně.

Následující tabulka shrnuje toky provozu pro tento scénář:

Azure Firewall nezkontroluje příchozí provoz HTTP.S. Bude ale moct použít pravidla vrstvy 3 a 4 a pravidla aplikací založená na plně kvalifikovaném názvu domény. Azure Firewall zkontroluje odchozí provoz HTTP(S) v závislosti na úrovni služby Azure Firewall a na tom, jestli nakonfigurujete kontrolu protokolu TLS:

• Azure Firewall Standard bude kontrolovat pouze atributy vrstvy 3 a 4 paketů v pravidlech sítě a hlavičku HTTP hostitele v pravidlech aplikace.
• Azure Firewall Premium přidává funkce, jako je kontrola dalších hlaviček HTTP (například user-agent) a povolení kontroly protokolu TLS pro hlubší analýzu paketů. Azure Firewall není ekvivalentem firewallu webových aplikací. Pokud máte ve virtuální síti webové úlohy, důrazně doporučujeme používat WAF.

Následující příklad procházky paketem ukazuje, jak klient přistupuje k aplikaci hostované virtuálním počítačem z veřejného internetu. Diagram obsahuje jenom jeden virtuální počítač pro zjednodušení. Pro zajištění vyšší dostupnosti a škálovatelnosti byste měli za nástrojem pro vyrovnávání zatížení několik instancí aplikace. V tomto návrhu azure Firewall kontroluje příchozí připojení z veřejného internetu i odchozí připojení z virtuálního počítače podsítě aplikace pomocí trasy definované uživatelem.

• Služba Azure Firewall nasadí několik instancí pod kryty, tady s front-endOVOU IP adresou 192.168.100.4 a interními adresami z rozsahu 192.168.100.0/26. Tyto jednotlivé instance jsou obvykle pro správce Azure neviditelné. Rozdíl je ale užitečný v některých případech, například při řešení potíží se sítí.
• Pokud provoz pochází z místní virtuální privátní sítě (VPN) nebo brány Azure ExpressRoute místo internetu, klient spustí připojení k IP adrese virtuálního počítače. Nespustí připojení k IP adrese brány firewall a brána firewall nebude ve výchozím nastavení provádět žádný zdrojový překlad adres (NAT).

Architektura

Následující diagram znázorňuje tok provozu za předpokladu, že je 192.168.100.7IP adresa instance .

Workflow

1. Klient spustí připojení k veřejné IP adrese brány Azure Firewall:
   • Zdrojová IP adresa: ClientPIP
   • Cílová IP adresa: AzFwPIP
2. Požadavek na veřejnou IP adresu služby Azure Firewall se distribuuje do back-endové instance brány firewall, v tomto případě 192.168.100.7. Pravidlo překladu adres (DNAT) cílové služby Azure Firewall přeloží cílovou IP adresu na IP adresu aplikace uvnitř virtuální sítě. Azure Firewall také zdrojové překlady adres (SNAT) paketů, pokud se jedná o DNAT. Další informace najdete v tématu Známé problémy se službou Azure Firewall. Virtuální počítač uvidí v příchozím paketu následující IP adresy:
   • Zdrojová IP adresa: 192.168.100.7
   • Cílová IP adresa: 192.168.1.4
3. Virtuální počítač odpoví na žádost aplikace a vrátí zpět zdrojové a cílové IP adresy. Příchozí tok nevyžaduje trasu definovanou uživatelem, protože zdrojová IP adresa je IP adresa služby Azure Firewall. Trasy definované uživatelem v diagramu pro verzi 0.0.0.0/0 jsou určené pro odchozí připojení, aby se zajistilo, že pakety do veřejného internetu procházejí bránou Azure Firewall.
   • Zdrojová IP adresa: 192.168.1.4
   • Cílová IP adresa: 192.168.100.7
4. Nakonec Azure Firewall vrátí zpět operace SNAT a DNAT a doručí odpověď klientovi:
   • Zdrojová IP adresa: AzFwPIP
   • Cílová IP adresa: ClientPIP

Pouze služba Application Gateway

Tento návrh se zabývá situací, kdy ve virtuální síti existují jenom webové aplikace, a kontrola odchozího provozu pomocí skupin zabezpečení sítě stačí k ochraně odchozích toků do internetu.

Hlavní rozdíl oproti předchozímu návrhu pouze se službou Azure Firewall spočívá v tom, že Služba Application Gateway nefunguje jako směrovací zařízení s překladem adres (NAT). Chová se jako úplný reverzní proxy aplikace. To znamená, že Služba Application Gateway zastaví webovou relaci od klienta a vytvoří samostatnou relaci s jedním ze svých back-endových serverů. Příchozí připojení HTTP z internetu se musí odesílat na veřejnou IP adresu služby Application Gateway, připojení z Azure nebo z místního prostředí k privátní IP adrese brány. Vrácení provozu z virtuálních počítačů Azure bude postupovat podle standardního směrování virtuální sítě zpět do služby Application Gateway (další podrobnosti najdete v další části. Odchozí internetové toky z virtuálních počítačů Azure se přesunou přímo na internet.

Následující tabulka shrnuje toky provozu:

Architektura

Následující příklad procházky paketem ukazuje, jak klient přistupuje k aplikaci hostované virtuálním počítačem z veřejného internetu.

Workflow

1. Klient spustí připojení k veřejné IP adrese brány Aplikace Azure:
   • Zdrojová IP adresa: ClientPIP
   • Cílová IP adresa: AppGwPIP
2. Požadavek na veřejnou IP adresu služby Application Gateway se distribuuje do back-endové instance brány, v tomto případě 192.168.200.7. Instance služby Application Gateway, která obdrží požadavek, zastaví připojení z klienta a vytvoří nové připojení s jedním z back-endů. Back-end uvidí instanci služby Application Gateway jako zdrojovou IP adresu. Application Gateway vloží hlavičku HTTP se zprávou X forwarded-For HTTP s původní IP adresou klienta.
   • Zdrojová IP adresa: 192.168.200.7 (privátní IP adresa instance služby Application Gateway)
   • Cílová IP adresa: 192.168.1.4
   • Hlavička X-Forwarded-For: ClientPIP
3. Virtuální počítač odpoví na žádost aplikace a vrátí zpět zdrojové a cílové IP adresy. Virtuální počítač už ví, jak se dostat ke službě Application Gateway, takže nepotřebuje trasu definovanou uživatelem.
   • Zdrojová IP adresa: 192.168.1.4
   • Cílová IP adresa: 192.168.200.7
4. Nakonec instance služby Application Gateway odpoví klientovi:
   • Zdrojová IP adresa: AppGwPIP
   • Cílová IP adresa: ClientPIP

Aplikace Azure Gateway přidá metadata do hlaviček HTTP paketů, jako je napříkladHlavička X-Forwarded-For obsahující IP adresu původního klienta. Některé aplikační servery potřebují zdrojovou IP adresu klienta pro obsluhu obsahu specifického pro geografickou polohu nebo pro protokolování. Další informace najdete v tématu Jak funguje aplikační brána.

• IP adresa 192.168.200.7 je jednou z instancí, které služba Aplikace Azure Gateway nasadí pod kryty, zde s interní privátní front-endOVOU IP adresou 192.168.200.4. Tyto jednotlivé instance jsou obvykle pro správce Azure neviditelné. Rozdíl je ale užitečný v některých případech, například při řešení potíží se sítí.

• Tok je podobný, pokud klient pochází z místní sítě přes vpn nebo bránu ExpressRoute. Rozdíl je, že klient přistupuje k privátní IP adrese služby Application Gateway místo veřejné adresy.

Brána firewall a služba Application Gateway paralelně

Z důvodu jednoduchosti a flexibility je často nejlepším scénářem paralelní spouštění služby Application Gateway a služby Azure Firewall.

Tento návrh implementujte, pokud ve virtuální síti existuje kombinace webových a ne webových úloh. Azure WAF ve službě Aplikace Azure Gateway chrání příchozí provoz do webových úloh a Azure Firewall kontroluje příchozí provoz pro ostatní aplikace. Azure Firewall bude zahrnovat odchozí toky z obou typů úloh.

Příchozí připojení HTTP z internetu by se měla odesílat na veřejnou IP adresu služby Application Gateway, připojení HTTP(S) z Azure nebo z místního prostředí k jeho privátní IP adrese. Směrování standardních virtuálních sítí odešle pakety ze služby Application Gateway do cílových virtuálních počítačů i z cílových virtuálních počítačů zpět do služby Application Gateway (další podrobnosti najdete v procházení paketů). U příchozích připojení bez protokolu HTTP (S) by měl provoz cílit na veřejnou IP adresu služby Azure Firewall (pokud pochází z veřejného internetu), nebo se bude odesílat přes trasy definované uživatelem (pokud pocházejí z jiných virtuálních sítí Azure nebo místních sítí). Všechny odchozí toky z virtuálních počítačů Azure se přesměrují do služby Azure Firewall pomocí trasy definované uživatelem.

Následující tabulka shrnuje toky provozu pro tento scénář:

Tento návrh poskytuje mnohem podrobnější filtrování výchozího přenosu dat než skupiny zabezpečení sítě. Pokud například aplikace potřebují připojení ke konkrétnímu účtu služby Azure Storage, můžete použít plně kvalifikované filtry na základě názvu domény (FQDN). U filtrů založených na plně kvalifikovaném názvu domény aplikace neodesílají data do podvodných účtů úložiště. Tento scénář se nedá zabránit jenom pomocí skupin zabezpečení sítě. Tento návrh se často používá, když odchozí provoz vyžaduje filtrování na základě plně kvalifikovaného názvu domény. Příkladem situace je omezení odchozího provozu z clusteru Azure Kubernetes Services.

Architektury

Následující diagram znázorňuje tok provozu pro příchozí připojení HTTP(S) z vnějšího klienta:

Následující diagram znázorňuje tok provozu pro odchozí připojení ze síťových virtuálních počítačů k internetu. Jedním z příkladů je připojení k back-endovým systémům nebo získání aktualizací operačního systému:

Kroky toku paketů pro každou službu jsou stejné jako v předchozích samostatných možnostech návrhu.

Application Gateway před bránou firewall

Tento návrh je podrobněji vysvětlen v síti nulové důvěryhodnosti pro webové aplikace se službou Azure Firewall a application Gateway. Tento dokument se zaměří na porovnání s dalšími možnostmi návrhu. V této topologii prochází příchozí webový provoz přes Azure Firewall i WAF. WAF poskytuje ochranu ve vrstvě webové aplikace. Azure Firewall funguje jako centrální bod protokolování a řízení a kontroluje provoz mezi službou Application Gateway a back-endovými servery. Služba Application Gateway a Azure Firewall nejsou paralelně, ale jedna za druhou.

V případě služby Azure Firewall Premium může tento návrh podporovat kompletní scénáře, kdy Azure Firewall používá kontrolu protokolu TLS k provádění šifrovaného provozu mezi službou Application Gateway a webovým back-endem.

Tento návrh je vhodný pro aplikace, které potřebují znát příchozí zdrojové IP adresy klienta, například obsluhovat obsah specifický pro geografickou polohu nebo pro protokolování. Application Gateway před službou Azure Firewall zachytí zdrojovou IP adresu příchozího paketu v hlavičce X forwarded-for , aby webový server viděl původní IP adresu v této hlavičce. Další informace najdete v tématu Jak funguje aplikační brána.

Příchozí připojení HTTP z internetu se musí odesílat na veřejnou IP adresu služby Application Gateway, připojení HTTP(S) z Azure nebo z místního prostředí k privátní IP adrese. Z tras definovaných uživatelem služby Application Gateway se ujistěte, že se pakety směrují přes službu Azure Firewall (další podrobnosti najdete v další části postupu paketů). U příchozích připojení bez protokolu HTTP (S) by měl provoz cílit na veřejnou IP adresu služby Azure Firewall (pokud pochází z veřejného internetu), nebo se bude odesílat přes trasy definované uživatelem (pokud pocházejí z jiných virtuálních sítí Azure nebo místních sítí). Všechny odchozí toky z virtuálních počítačů Azure se přesměrují do služby Azure Firewall pomocí trasy definované uživatelem.

Důležitou poznámkou k tomuto návrhu je, že Azure Firewall Premium uvidí provoz se zdrojovou IP adresou z podsítě služby Application Gateway. Pokud je tato podsíť nakonfigurovaná s privátní IP adresou (v 10.0.0.0/8192.168.0.0/16172.16.0.0/12 , nebo100.64.0.0/10), Azure Firewall Premium bude zpracovávat provoz ze služby Application Gateway jako interní a nepoužije pravidla IDPS pro příchozí provoz. Další informace o směrech pravidel IDPS služby Azure Firewall a předponách privátních IP adres pro IDPS najdete v pravidlech IDPS služby Azure Firewall. Proto doporučujeme upravit privátní předpony IDPS v zásadách služby Azure Firewall tak, aby podsíť služby Application Gateway nebyla považována za interní zdroj, aby se na provoz použily příchozí a odchozí podpisy IDPS.

Následující tabulka shrnuje toky provozu pro tento scénář:

U webového provozu z místního prostředí nebo z internetu do Azure brána Azure Firewall zkontroluje toky, které waF už povolil. V závislosti na tom, jestli služba Application Gateway šifruje back-endový provoz (provoz ze služby Application Gateway na aplikační servery), budete mít různé potenciální scénáře:

1. Služba Application Gateway šifruje provoz podle principů nulové důvěryhodnosti (kompletní šifrování TLS) a azure Firewall bude přijímat šifrovaný provoz. Přesto bude moct Standard služby Azure Firewall použít pravidla kontroly, jako je filtrování vrstvy 3 a 4 v pravidlech sítě nebo filtrování plně kvalifikovaného názvu domény v pravidlech aplikace pomocí hlavičky SNI (TLS Server Name Indication). Azure Firewall Premium poskytuje hlubší přehled o kontrole protokolu TLS, jako je filtrování na základě adresy URL.
2. Pokud služba Application Gateway odesílá nešifrovaný provoz na aplikační servery, azure Firewall zobrazí příchozí provoz ve formátu prostého textu. Kontrola protokolu TLS není ve službě Azure Firewall nutná.
3. Pokud je ve službě Azure Firewall povolený protokol IDPS, ověří se, že hlavička hostitele HTTP odpovídá cílové IP adrese. Za tímto účelem bude potřebovat překlad názvů pro plně kvalifikovaný název domény zadaný v hlavičce hostitele. Tento překlad názvů je možné dosáhnout pomocí privátních zón Azure DNS a výchozího nastavení DNS služby Azure Firewall pomocí Azure DNS. Dá se také dosáhnout pomocí vlastních serverů DNS, které je potřeba nakonfigurovat v nastavení služby Azure Firewall. (Další informace najdete v tématu Nastavení DNS služby Azure Firewall.) Pokud není přístup správce k virtuální síti, ve které je nasazená brána Azure Firewall, je jedinou možností druhá metoda. Jedním z příkladů je použití bran Azure Firewall nasazených ve službě Virtual WAN Secured Hubs.

Architektura

Pro zbývající toky (příchozí provoz mimo PROTOKOL HTTP a veškerý odchozí provoz) azure Firewall poskytne kontrolu zprostředkovatele identity a kontrolu protokolu TLS tam, kde je to vhodné. Poskytuje také filtrování na základě plně kvalifikovaného názvu domény v pravidlech sítě na základě DNS.

Workflow

Síťový provoz z veřejného internetu se řídí tímto tokem:

1. Klient spustí připojení k veřejné IP adrese brány Aplikace Azure:
   • Zdrojová IP adresa: ClientPIP
   • Cílová IP adresa: AppGwPIP
2. Požadavek na veřejnou IP adresu služby Application Gateway se distribuuje do back-endové instance brány, v tomto případě 192.168.200.7. Instance služby Application Gateway zastaví připojení z klienta a vytvoří nové připojení s jedním z back-endů. Trasu definovanou 192.168.1.0/24 uživatelem v podsíti služby Application Gateway předává paket do služby Azure Firewall a zachová cílovou IP adresu webové aplikaci:
   • Zdrojová IP adresa: 192.168.200.7 (privátní IP adresa instance služby Application Gateway)
   • Cílová IP adresa: 192.168.1.4
   • Hlavička X-Forwarded-For: ClientPIP
3. Azure Firewall provoz neschová, protože provoz směřuje na privátní IP adresu. Přesměruje provoz na virtuální počítač aplikace, pokud to pravidla povolují. Další informace najdete v tématu SNAT služby Azure Firewall. Pokud ale provoz dorazí do pravidla aplikace v bráně firewall, úloha uvidí zdrojovou IP adresu konkrétní instance brány firewall, která paket zpracovala, protože Azure Firewall připojení zprostředkuje:
   • Zdrojová IP adresa, pokud je provoz povolený pravidlem sítě služby Azure Firewall: 192.168.200.7 (privátní IP adresa jedné z instancí služby Application Gateway).
   • Zdrojová IP adresa, pokud je provoz povolený pravidlem aplikace služby Azure Firewall: 192.168.100.7 (privátní IP adresa jedné z instancí služby Azure Firewall).
   • Cílová IP adresa: 192.168.1.4
   • Hlavička X-Forwarded-For: ClientPIP
4. Virtuální počítač odpoví na žádost a vrátí zpět zdrojové a cílové IP adresy. Trasu definovanou uživatelem zachytí 192.168.200.0/24 paket odesílaný zpět do služby Application Gateway a přesměruje ho do služby Azure Firewall a zachová cílovou IP adresu směrem ke službě Application Gateway.
   • Zdrojová IP adresa: 192.168.1.4
   • Cílová IP adresa: 192.168.200.7
5. V této části azure Firewall provoz nenasadí, protože přejde na privátní IP adresu a přesměruje provoz do služby Application Gateway.
   • Zdrojová IP adresa: 192.168.1.4
   • Cílová IP adresa: 192.168.200.7
6. Nakonec instance služby Application Gateway odpoví klientovi:
   • Zdrojová IP adresa: AppGwPIP
   • Cílová IP adresa: ClientPIP

Odchozí toky z virtuálních počítačů do veřejného internetu procházejí bránou Azure Firewall, jak je definováno uživatelem definovaným uživatelem .0.0.0.0/0

Application Gateway po bráně firewall

Tento návrh umožňuje službě Azure Firewall filtrovat a zahodit škodlivý provoz, než dosáhne služby Application Gateway. Může například používat funkce, jako je filtrování na základě analýzy hrozeb. Další výhodou je, že aplikace získá stejnou veřejnou IP adresu pro příchozí i odchozí provoz bez ohledu na protokol. Azure Firewall však příchozí provoz nasměruje, takže aplikace nebude mít přehled o původní IP adrese požadavků HTTP. Z pohledu správy, například pro účely řešení potíží, můžete získat skutečnou IP adresu klienta pro konkrétní připojení tím, že ji propojíte s protokoly SNAT služby Azure Firewall.

V tomto scénáři existuje omezená výhoda, protože Azure Firewall uvidí šifrovaný provoz jenom do služby Application Gateway. Tento návrh může být upřednostňovaný. Jedním z případů je, že jiná WAF je starší v síti (například pomocí služby Azure Front Door), která by mohla zachytit původní zdrojovou IP adresu v X-Forwarded-For hlavičce HTTP. Pokud je vyžadováno mnoho veřejných IP adres, je tento návrh upřednostňovaný.

Příchozí toky HTTP z veřejného internetu by měly cílit na veřejnou IP adresu služby Azure Firewall a Služba Azure Firewall bude dnat (a SNAT) pakety na privátní IP adresu služby Application Gateway. Z jiných virtuálních sítí Azure nebo místních sítí by se měl odesílat provoz HTTP(S) do privátní IP adresy služby Application Gateway a předávat přes Azure Firewall s trasy definovanými uživatelem. Standardní směrování virtuální sítě zajistí, aby se v případě použití pravidel DNAT vrátil provoz z virtuálních počítačů Azure do služby Application Gateway a ze služby Application Gateway do služby Azure Firewall. Pro provoz z místního prostředí nebo trasy definované uživatelem Azure v podsíti služby Application Gateway by se měl použít (další podrobnosti najdete v další části. Veškerý odchozí provoz z virtuálních počítačů Azure do internetu se odešle přes trasy definované uživatelem přes bránu Azure Firewall.

Následující tabulka shrnuje toky provozu pro tento scénář:

U příchozího provozu HTTP (S) by azure Firewall obvykle nešifroval provoz. Místo toho by se použily zásady IDPS, které nevyžadují kontrolu protokolu TLS, jako je filtrování na základě PROTOKOLU IP nebo použití hlaviček HTTP.

Architektura

Aplikace nevidí původní zdrojovou IP adresu webového provozu; Azure Firewall SNAT pakety při jejich připojení do virtuální sítě. Pokud se chcete tomuto problému vyhnout, před bránou firewall použijte Službu Azure Front Door . Azure Front Door před vstupem do virtuální sítě Azure vloží IP adresu klienta jako hlavičku HTTP.

Workflow

Síťový provoz z veřejného internetu se řídí tímto tokem:

1. Klient spustí připojení k veřejné IP adrese brány Azure Firewall:
   • Zdrojová IP adresa: ClientPIP
   • Cílová IP adresa: AzFWPIP
2. Požadavek na veřejnou IP adresu služby Azure Firewall se distribuuje do back-endové instance brány firewall, v tomto případě 192.168.100.7. Dnatuje webový port služby Azure Firewall, obvykle TCP 443, na privátní IP adresu instance služby Application Gateway. Azure Firewall také SNAT při provádění DNAT. Další informace najdete v tématu Známé problémy se službou Azure Firewall:
   • Zdrojová IP adresa: 192.168.100.7 (privátní IP adresa instance služby Azure Firewall)
   • Cílová IP adresa: 192.168.200.4
3. Služba Application Gateway vytvoří novou relaci mezi instancí, která zpracovává připojení, a jedním z back-endových serverů. Původní IP adresa klienta není v paketu:
   • Zdrojová IP adresa: 192.168.200.7 (privátní IP adresa instance služby Application Gateway)
   • Cílová IP adresa: 192.168.1.4
   • X-Forwarded-For header: 192.168.100.7
4. Virtuální počítač odpovídá službě Application Gateway, která vrací zdrojové a cílové IP adresy:
   • Zdrojová IP adresa: 192.168.1.4
   • Cílová IP adresa: 192.168.200.7
5. Application Gateway odpoví na zdrojovou IP adresu SNAT instance služby Azure Firewall. I když připojení pochází z konkrétní instance služby Application Gateway, například .7, azure Firewall jako zdrojovou IP adresu služby Application Gateway uvidí interní IP adresu služby Application Gateway .4 :
   • Zdrojová IP adresa: 192.168.200.4
   • Cílová IP adresa: 192.168.100.7
6. Nakonec Azure Firewall vrátí zpět SNAT a DNAT a odpoví na klienta:
   • Zdrojová IP adresa: AzFwPIP
   • Cílová IP adresa: ClientPIP

I když služba Application Gateway nemá nakonfigurované žádné naslouchací procesy pro aplikace, stále potřebuje veřejnou IP adresu, aby ji mohl spravovat Microsoft.

Místní klienti

Předchozí návrhy zobrazují všechny klienty aplikací pocházející z veřejného internetu. Místní sítě také přistupují k aplikacím. Většina předchozích informací a toků provozu je stejná jako u internetových klientů, ale existují některé důležité rozdíly:

• Brána VPN nebo brána ExpressRoute se nachází před bránou Azure Firewall nebo službou Application Gateway.
• WAF používá privátní IP adresu služby Application Gateway.
• Azure Firewall nepodporuje DNAT pro privátní IP adresy. Proto musíte použít trasy definované uživatelem k odesílání příchozího provozu do služby Azure Firewall z bran VPN nebo ExpressRoute.
• Nezapomeňte ověřit upozornění týkající se vynuceného tunelování pro bránu Aplikace Azure a pro bránu Azure Firewall. I když vaše úloha nepotřebuje odchozí připojení k veřejnému internetu, nemůžete vložit výchozí trasu, jako je 0.0.0.0/0 služba Application Gateway, která odkazuje na místní síť, nebo přerušíte řízení provozu. Pro službu Aplikace Azure Gateway musí výchozí trasa odkazovat na veřejný internet.

Architektura

Následující diagram znázorňuje paralelní návrh brány Aplikace Azure a brány Azure Firewall. Klienti aplikací pocházejí z místní sítě připojené k Azure přes VPN nebo ExpressRoute:

I když se všichni klienti nacházejí místně nebo v Azure, Aplikace Azure Gateway a Azure Firewall musí mít veřejné IP adresy. Veřejné IP adresy umožňují Společnosti Microsoft spravovat služby.

Hvězdicová topologie

Návrhy v tomto článku se stále týkají hvězdicové topologie. Sdílené prostředky v centrální centrální virtuální síti se připojují k aplikacím v samostatných paprskových virtuálních sítích prostřednictvím partnerských vztahů virtuálních sítí.

Architektura

Důležité informace

Mezi důležité informace pro tuto topologii patří:

• Azure Firewall je nasazený ve virtuální síti centrálního centra. Výše uvedený diagram znázorňuje postup nasazení služby Application Gateway v centru. Aplikační týmy ale často spravují komponenty, jako jsou brány Aplikace Azure Gateway nebo brány služby Azure API Management. V tomto případě se tyto komponenty nasadí do paprskových virtuálních sítí.
• Věnujte zvláštní pozornost trasy definované uživatelem v paprskových sítích: Když aplikační server v paprsku přijímá provoz z konkrétní instance služby Azure Firewall, jako je 192.168.100.7 adresa v předchozích příkladech, měla by posílat zpětný provoz zpět do stejné instance. Pokud trasa definovaná uživatelem v paprsku nastaví další segment směrování provozu adresovaný do centra na IP adresu služby Azure Firewall (192.168.100.4 v diagramech výše), můžou návratové pakety skončit na jiné instanci služby Azure Firewall, což způsobí asymetrické směrování. Ujistěte se, že pokud máte trasy definované uživatelem v paprskových virtuálních sítích k odesílání provozu do sdílených služeb v centru prostřednictvím služby Azure Firewall, tyto trasy definované uživatelem nezahrnují předponu podsítě služby Azure Firewall.
• Předchozí doporučení platí stejně pro podsíť služby Application Gateway a všechna ostatní síťová virtuální zařízení nebo reverzní proxy servery, které by mohly být nasazeny ve virtuální síti centra.
• Další segment směrování pro podsítě služby Application Gateway nebo Azure Firewall nemůžete nastavit prostřednictvím statických tras s typem dalšího Virtual Networksegmentu směrování . Tento typ dalšího segmentu směrování je platný pouze v místní virtuální síti, nikoli v rámci partnerských vztahů virtuálních sítí. Další informace o trasách definovaných uživatelem a typech dalšího směrování najdete v tématu Směrování provozu virtuální sítě.

Asymetrické směrování

Následující diagram znázorňuje, jak paprsky odesílají zpětný provoz SNATted zpět do ALB služby Azure Firewall. Toto nastavení způsobí asymetrické směrování:

Pokud chcete tento problém vyřešit, definujte trasy definované uživatelem v paprsku bez podsítě služby Azure Firewall, ale pouze s podsítěmi, ve kterých se nacházejí sdílené služby. V tomto příkladu by správné trasy definované uživatelem v paprsku měly obsahovat pouze 192.168.1.0/24. Neměl by obsahovat celý kód 192.168.0.0/16, jak je označeno červeně.

Integrace s dalšími produkty Azure

Službu Azure Firewall a Aplikace Azure Gateway můžete integrovat s dalšími produkty a službami Azure.

Brána služby API Management

Integrujte služby reverzního proxy serveru, jako je brána API Management , do předchozích návrhů, které poskytují funkce, jako je omezování rozhraní API nebo proxy ověřování. Integrace brány SLUŽBY API Management nijak výrazně nemění návrhy. Hlavním rozdílem je, že místo jednoho reverzního proxy služby Application Gateway jsou dvě reverzní proxy servery zřetězený za sebou.

Další informace najdete v průvodci návrhem integrace služby API Management a služby Application Gateway ve virtuální síti a vzorových bran api pro mikroslužby.

Azure Kubernetes Service

U úloh spuštěných v clusteru AKS můžete nasadit Aplikace Azure Gateway nezávisle na clusteru. Nebo ho můžete integrovat s clusterem AKS pomocí kontroleru příchozího přenosu dat brány Aplikace Azure. Při konfiguraci určitých objektů na úrovních Kubernetes (jako jsou služby a příchozí přenos dat) se služba Application Gateway automaticky přizpůsobí bez nutnosti dalších ručních kroků.

Azure Firewall hraje důležitou roli v zabezpečení clusteru AKS. Nabízí požadovanou funkci pro filtrování odchozího provozu z clusteru AKS na základě plně kvalifikovaného názvu domény, nejen IP adresy. Další informace najdete v tématu Řízení výchozího přenosu dat pro uzly clusteru AKS.

Při kombinování služby Application Gateway a služby Azure Firewall za účelem ochrany clusteru AKS je nejlepší použít možnost paralelního návrhu. Application Gateway s WAF zpracovává příchozí požadavky na připojení k webovým aplikacím v clusteru. Azure Firewall povoluje pouze explicitně povolená odchozí připojení. Příklad možnosti paralelního návrhu najdete v architektuře standardních hodnot pro cluster Azure Kubernetes Service (AKS).

Azure Front Door

Funkce služby Azure Front Door se částečně překrývají s Aplikace Azure Gateway. Například obě služby nabízejí firewall webových aplikací, přesměrování zpracování SSL a směrování na základě adresy URL. Jedním z hlavních rozdílů je, že zatímco Aplikace Azure Gateway se nachází ve virtuální síti, azure Front Door je globální decentralizovaná služba.

Návrh virtuální sítě můžete někdy zjednodušit nahrazením služby Application Gateway decentralizovanou službou Azure Front Door. Většina zde popsaných návrhů zůstává platná, s výjimkou možnosti umístění služby Azure Firewall před Azure Front Door.

Zajímavý případ použití je použití služby Azure Firewall před službou Application Gateway ve vaší virtuální síti. Jak je popsáno výše, hlavička X-Forwarded-For vložená službou Application Gateway bude obsahovat IP adresu instance brány firewall, nikoli IP adresu klienta. Alternativním řešením je použít Službu Azure Front Door před bránou firewall k vložení IP adresy klienta jako hlavičky X-Forwarded-For před vstupem do virtuální sítě a přístup k bráně Azure Firewall. Druhou možností je zabezpečení vašeho původu pomocí služby Private Link ve službě Azure Front Door Premium.

Další informace orozdílch

Další síťová virtuální zařízení

Produkty Microsoftu nejsou jedinou volbou pro implementaci firewallu webových aplikací ani funkcí brány firewall nové generace v Azure. Široká škála partnerů Microsoftu poskytuje síťová virtuální zařízení (NVA). Koncepty a návrhy jsou v podstatě stejné jako v tomto článku, ale existují některé důležité aspekty:

• Partnerské síťové virtuální zařízení pro bránu firewall nové generace můžou nabízet větší kontrolu a flexibilitu pro konfigurace překladu adres (NAT) nepodporované službou Azure Firewall. Mezi příklady patří DNAT z místního prostředí nebo DNAT z internetu bez SNAT.
• Síťová virtuální zařízení spravovaná v Azure (například Application Gateway a Azure Firewall) snižují složitost v porovnání se síťovými virtuálními zařízeními, kde uživatelé potřebují zpracovávat škálovatelnost a odolnost napříč mnoha zařízeními.
• Při používání síťových virtuálních zařízení v Azure použijte nastavení aktivní-aktivní a automatické škálování , takže tato zařízení nejsou kritickým bodem pro aplikace spuštěné ve virtuální síti.

Přispěvatelé

Tento článek spravuje Microsoft. Původně byla napsána následujícími přispěvateli.

Hlavní autor:

• Jose Moreno | Hlavní zákaznický inženýr

Další kroky

Další informace o technologiích komponent:

• Co je Aplikace Azure Gateway?
• Co je Azure Firewall?
• Co je Azure Front Door?
• Azure Kubernetes Service
• Co je Azure Virtual Network?
• Co je Azure Web Application Firewall?

Související prostředky

Prozkoumejte související architektury:

• Implementace zabezpečené hybridní sítě
• Bezpečně spravované webové aplikace
• Zabezpečení robota kanálu Microsoft Teams a webové aplikace za bránou firewall
• Portál Consumer Health v Azure
• Důležité informace o zabezpečení pro vysoce citlivé aplikace IaaS v Azure
• Víceklientské SaaS v Azure
• Podnikové nasazení s využitím služby App Services Environment
• Nasazení podniku s vysokou dostupností pomocí služby App Services Environment
• Základní architektura pro cluster Azure Kubernetes Service (AKS)