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žbě Azure Virtual Network služby zabezpečení, jako jsou Azure DDoS Protection, Azure Firewall a Azure Application Gateway, kdy používat jednotlivé služby a možnosti návrhu sítě, které kombinují obě možnosti.

• azure DDoS Protectionv kombinaci s osvědčenými postupy návrhu aplikací poskytuje vylepšené funkce omezení rizik DDoS, které poskytují lepší ochranu před útoky DDoS. Měli byste povolit azure DDOS Protection v jakékoli hraniční virtuální síti.
• azure Firewall je spravovaná brána firewall nové generace, která nabízípřekladu 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).
• azure Application 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 PROTOKOLU HTTPForwarded-For 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ě Azure Application 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 dokumentacifirewallu 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 Azure Application 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:

diagram

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:

• samotnou bránu Azure Firewall, pokud ve virtuální síti nejsou žádné webové aplikace. Bude řídit příchozí provoz do aplikací i odchozí provoz.
• samotnou službu 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, když chcete, aby služba Azure Application Gateway chránila aplikace HTTP 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, pokud chcete, aby služba Azure Firewall kontroluje veškerý provoz, WAF pro ochranu webového provozu 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.
• bráně Azure Firewall předslužby 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 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 & pravidla vrstvy 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 zkontroluje pouze atributy vrstvy 3 & vrstvy 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ánu 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 IP adresa instance 192.168.100.7.

Pracovní postup

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 cílového překladu adres (NAT) služby Azure Firewall přeloží cílovou IP adresu na IP adresu aplikace uvnitř virtuální sítě. Azure Firewall také zdrojových překladů 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žadujetrasy definované uživatelem , protože zdrojovou IP adresou 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.

Pracovní postup

1. Klient spustí připojení k veřejné IP adrese služby Azure Application Gateway:
   • 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 X-Forwarded-For 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čkaForwarded-For X: 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

Azure Application Gateway přidává metadata do hlaviček HTTP paketů, jako je hlavič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 Fungování aplikační brány.

• IP adresa 192.168.200.7 je jednou z instancí, které služba Azure Application Gateway nasadí v rámci krytů, 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ě Azure Application 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ý název domény (FQDN)filtry založené na azure. 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 je situace, kdy omezení výchozího přenosu dat 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:

diagram

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 službou Application Gateway, tento dokument se zaměří na porovnání s ostatní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.

S azure Firewall Premiummůže tento návrh podporovat kompletní scénáře, kdy Azure Firewall použije 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í. Služba Application Gateway před bránou Azure Firewall zachycuje zdrojovou IP adresu příchozího paketu v hlavičce předávání X pro, aby webový server viděl původní IP adresu v této hlavičce. Další informace najdete v tématu Fungování aplikační brány.

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/8, 192.168.0.0/16, 172.16.0.0/12 nebo 100.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 pravidla 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ího šifrování TLS) a azure Firewall přijímá šifrovaný provoz. Přesto bude moct standard služby Azure Firewall použít pravidla kontroly, jako je filtrování vrstvy 3 & vrstvy 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 podrobnější 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í plně kvalifikovaného názvu domény v pravidlech sítě na základě DNS.

Pracovní postup

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

1. Klient spustí připojení k veřejné IP adrese služby Azure Application Gateway:
   • 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 uživatelem 192.168.1.0/24 v podsíti služby Application Gateway předá paket bráně Azure Firewall a zachová cílovou IP adresu do webové aplikace:
   • 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čkaForwarded-For X: 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čkaForwarded-For X: ClientPIP
4. Virtuální počítač odpoví na žádost a vrátí zpět zdrojové a cílové IP adresy. Trasu definovanou uživatelem 192.168.200.0/24 zachytí paket odeslaný 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 trasou definovanou uživatelem pro 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 s Azure Front Door), což by mohlo zachytit původní zdrojovou IP adresu v hlavičce X-Forwarded-For 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žby Azure Front Door. Azure Front Door před vstupem do virtuální sítě Azure vloží IP adresu klienta jako hlavičku HTTP.

Pracovní postup

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 hlavička: 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, jako je .7, azure Firewall uvidí interní IP adresu služby Application Gateway .4 jako zdrojovou IP adresu:
   • 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 služby Azure Application Gateway a pro brány 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 pro službu Application Gateway, která odkazuje na místní síť, nebo přerušíte řízení provozu. Pro Azure Application Gateway musí výchozí trasa odkazovat na veřejný internet.

Architektura

Následující diagram znázorňuje paralelní návrh služby Azure Application Gateway a služby 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, musí mít obě služby Azure Application Gateway a Azure Firewall 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 používají v topologii hvězdicové. 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

Úvahy

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 azure Application Gateways nebo brány 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 adresa 192.168.100.7 v předchozích příkladech, měla by odesílat 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 ve výše uvedených diagramech), 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 segmentu směrování Virtual Network. 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 Azure Application 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 API Management, bránu do předchozích návrhů, aby poskytovaly 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 vzoru aplikací brány API pro mikroslužby.

Azure Kubernetes Service

Pro úlohy spuštěné v clusteru AKS můžete nasadit službu Azure Application Gateway nezávisle na clusteru. Nebo ho můžete integrovat s clusterem AKS pomocí kontroleru příchozího přenosu dat služby Azure Application Gateway. 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 základní architektuře pro cluster Azure Kubernetes Service (AKS).

Azure Front Door

funkce služby Azure Front Door se částečně překrývají se službou Azure Application 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 Azure Application Gateway je uvnitř virtuální sítě, 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žití služby 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 dosažením brány 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 o rozdílech mezi těmito dvěma službami nebo o tom, kdy je použít, najdete v tématu Nejčastější dotazy ke službě Azure Front Door.

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žívejte aktivní a nastavení automatického š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 Azure Application 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ého hybridního síťového
• bezpečně spravované webové aplikace
• zabezpečení robota kanálu Microsoft Teams a webové aplikace za bránou firewall
• aspekty zabezpečení pro vysoce citlivé aplikace IaaS v Azure
• Multitenant SaaS v Azure
• podnikové nasazení pomocí služby App Services Environment
• nasazení podniku s vysokou dostupností s využitím služby App Services Environment
• základní architektura pro cluster Azure Kubernetes Service (AKS)