Implementace sítě nulové důvěryhodnosti pro webové aplikace pomocí služby Azure Firewall a služby Azure Application Gateway

Tento článek popisuje, jak implementovat zabezpečení nulové důvěryhodnosti pro webové aplikace, aby bylo možné povolit kontrolu a kompletní šifrování. Model nulové důvěryhodnosti zahrnuje mnoho dalších konceptů, jako je průběžné ověřování identit a minimalizace velikosti implicitních oblastí důvěryhodnosti.

Tento článek se zaměřuje na součást šifrování a kontroly architektury nulové důvěryhodnosti pro příchozí provoz z veřejného internetu. Další informace o dalších aspektech bezpečného nasazení aplikace, jako je ověřování a autorizace, najdete v dokumentaci k nulové důvěryhodnosti. Příklad v tomto článku používá vícevrstevný přístup. V přístupu s více vrstvami tvoří zabezpečení sítě jednu z vrstev modelu nulové důvěryhodnosti. V této vrstvě síťová zařízení kontrolují pakety, aby se zajistilo, že do aplikací dorazí jenom legitimní provoz.

Různé typy síťových zařízení obvykle kontrolují různé aspekty síťových paketů:

• Firewally webových aplikací hledají vzory, které indikují útok na vrstvu webové aplikace.

• Brány firewall nové generace můžou také hledat obecné hrozby.

Tato architektura se zaměřuje na běžný vzor pro maximalizaci zabezpečení, ve kterém Azure Application Gateway kontroluje a zpracovává provoz před dosažením služby Azure Firewall Premium. V některých scénářích můžete zkombinovat různé typy zařízení zabezpečení sítě a zvýšit tak ochranu. Další informace najdete v tématu Azure Firewall a Application Gateway pro virtuální sítě.

Architektura

V tomto diagramu šipka označená jako HTTPS směřuje z ikony, která představuje klienty, k ikonám představujícím Application Gateway a Azure Web Application Firewall. Další šipka označená jako HTTPS ukazuje z těchto ikon na ikonu Azure Firewall Premium. Dvě šipky ukazují na ikonu Azure Firewall Premium. Jedna šipka je označená systémem DNS (Domain Name System) a odkazuje na server DNS nebo privátní zónu. Druhá šipka je označená jako HTTPS a odkazuje na ikonu, která představuje Azure Virtual Machines.

Stáhněte si soubor aplikace Visio s touto architekturou.

Tato architektura používá protokol TLS (Transport Layer Security) k šifrování provozu v každém kroku.

1. Klient odesílá pakety do služby Application Gateway, nástroje pro vyrovnávání zatížení. Spustí se s volitelným přidáním služby Azure Web Application Firewall.

2. Application Gateway dešifruje pakety a vyhledá hrozby pro webové aplikace. Pokud nenajde žádné hrozby, použije k šifrování paketů principy nulové důvěryhodnosti. Pak je uvolní.

3. Azure Firewall Premium spouští následující kontroly zabezpečení:

   • Kontrola protokolu TLS dešifruje a kontroluje pakety.
   • Funkce systému pro detekci a prevenci neoprávněných vniknutí kontrolují škodlivé záměry paketů.

4. Pokud pakety projdou testy, Azure Firewall Premium provede tyto kroky:

   • Zašifruje pakety.
   • K určení virtuálního počítače aplikace používá službu DNS (Domain Name System).
   • Předává pakety virtuálnímu počítači aplikace.

Různé kontrolní moduly v této architektuře zajišťují integritu provozu:

• Azure Web Application Firewall používá pravidla k prevenci útoků ve webové vrstvě. Mezi příklady útoků patří injektáž kódu SQL a skriptování mezi weby. Další informace o pravidlech a základní sadě pravidel (OWASP) Open Worldwide Application Security Project (OWASP) najdete v tématu Skupiny a pravidla firewallu webových aplikací CRS.

• Azure Firewall Premium používá obecná pravidla detekce neoprávněných vniknutí a prevence. Tato pravidla pomáhají identifikovat škodlivé soubory a další hrozby, které cílí na webové aplikace.

Tato architektura podporuje následující typy návrhu sítě, které tento článek popisuje:

• Tradiční hvězdicové sítě
• Sítě, které používají Azure Virtual WAN jako platformu
• Sítě, které používají Azure Route Server ke zjednodušení dynamického směrování

Azure Firewall Premium a překlad názvů

Když Azure Firewall Premium kontroluje škodlivý provoz, ověří, že hlavička hostitele HTTP odpovídá IP adrese paketu a portu TCP (Transmission Control Protocol). Předpokládejme například, že Application Gateway odesílá webové pakety na IP adresu 172.16.1.4 a port TCP 443. Hodnota hlavičky hostitele HTTP by se měla přeložit na tuto IP adresu.

Hlavičky hostitele HTTP obvykle neobsahují IP adresy. Místo toho hlavičky obsahují názvy, které odpovídají digitálnímu certifikátu serveru. V tomto případě Azure Firewall Premium používá DNS k překladu názvu hlavičky hostitele na IP adresu. Návrh sítě určuje, které řešení DNS funguje nejlépe.

Poznámka:

Application Gateway nepodporuje čísla portů v hlavičkách hostitele HTTP. Výsledek:

• Azure Firewall Premium předpokládá výchozí port HTTPS TCP 443.
• Připojení mezi službou Application Gateway a webovým serverem podporuje pouze port TCP 443, nikoli nestandardní porty.

Digitální certifikáty

Následující diagram znázorňuje běžné názvy (CNS) a certifikační autority(CA), které používají relace TLS a certifikáty této architektury.

V tomto diagramu šipka označená jako HTTPS směřuje z ikony, která představuje klienty, k ikonám představujícím Application Gateway a Azure Web Application Firewall. Na levé straně těchto ikon jsou CN, myapp.contoso.com a CA, DigiCert. Na pravé straně těchto ikon je kořenová certifikační autorita služby Azure Firewall v nastavení HTTP. Další šipka označená jako HTTPS ukazuje z těchto ikon na ikonu Azure Firewall Premium. Na levé straně této ikony je CN, myapp.contoso.com a CA, CA služby Azure Firewall. Další šipka označená https odkazuje na ikonu, která představuje Azure Virtual Machines. Na levé straně této ikony je CN, myapp.contoso.com a CA, DigiCert.

Azure Firewall dynamicky generuje vlastní certifikáty. Tato funkce je jedním z hlavních důvodů, proč se nachází za službou Application Gateway. Jinak se klient aplikace konfrontuje s certifikáty vygenerovanými vlastním systémem, které jsou označeny jako bezpečnostní riziko.

Připojení TLS

Tato architektura obsahuje tři různá připojení TLS. Digitální certifikáty ověřují každý z nich.

Z klientů do služby Application Gateway

Ve službě Application Gateway nasadíte digitální certifikát, který klienti uvidí. Dobře známá certifikační autorita, jako je DigiCert nebo Let's Encrypt, obvykle vydává takový certifikát. Tento mechanismus se v zásadě liší od toho, jak Azure Firewall dynamicky generuje digitální certifikáty ze samopodepsané nebo interní certifikační autority infrastruktury veřejných klíčů.

Z Application Gateway do služby Azure Firewall Premium

K dešifrování a kontrole provozu PROTOKOLU TLS služba Azure Firewall Premium dynamicky generuje certifikáty. Azure Firewall Premium se také prezentuje jako webový server ve službě Application Gateway. Privátní certifikační autorita podepíše certifikáty, které generuje Azure Firewall Premium. Další informace najdete v tématu certifikáty služby Azure Firewall Premium. Application Gateway musí tyto certifikáty ověřit. V nastavení HTTP aplikace nakonfigurujete kořenovou certifikační autoritu, kterou Azure Firewall Premium používá.

Z Azure Firewall Premium na webový server

Azure Firewall Premium vytvoří relaci TLS s cílovým webovým serverem. Azure Firewall Premium ověřuje, že známá certifikační autorita podepíše pakety TLS webového serveru.

Role komponent

Application Gateway a Azure Firewall Premium zpracovávají certifikáty odlišně od sebe, protože se jejich role liší:

• Application Gateway je reverzního webového proxy serveru. Chrání webové servery před škodlivými klienty zachycením požadavků HTTP a HTTPS. Deklarujete každý chráněný server, který je v back-endovém fondu služby Application Gateway, se svou IP adresou nebo plně kvalifikovaným názvem domény. Legitimní klienti by měli mít přístup ke každé aplikaci. Službu Application Gateway tedy nakonfigurujete pomocí digitálního certifikátu, který podepíše veřejná certifikační autorita. Použijte certifikační autoritu, kterou přijímá každý klient TLS.

• Azure Firewall Premium je předávat webový proxy nebo jednoduše webový proxy server. Chrání klienty před škodlivými webovými servery tím, že zachycuje volání PROTOKOLU TLS od chráněných klientů. Když chráněný klient vytvoří požadavek HTTP, předávající webový proxy server zosobní cílový webový server tím, že generuje digitální certifikáty a prezentuje je klientovi. Azure Firewall Premium používá privátní certifikační autoritu, která podepisuje dynamicky generované certifikáty. Konfigurujete chráněné klienty tak, aby důvěřovali této privátní certifikační autoritě. V této architektuře azure Firewall Premium chrání požadavky ze služby Application Gateway na webový server. Application Gateway důvěřuje privátní certifikační autoritě, kterou používá Azure Firewall Premium.

Směrování a přesměrování provozu

Směrování se mírně liší v závislosti na topologii návrhu sítě. Následující části popisují příklady topologií typu hub a spoke, Virtual WAN a topologií směrovačů. Všechny topologie mají společné následující aspekty:

• Application Gateway vždy slouží jako proxy server. Azure Firewall Premium slouží také jako proxy server, když je nakonfigurovaný pro kontrolu protokolu TLS. Application Gateway ukončuje relace TLS od klientů a nové relace TLS se vytvářejí směrem ke službě Azure Firewall. Azure Firewall přijímá a ukončuje relace TLS zdrojové ze služby Application Gateway a vytváří nové relace TLS směrem k úlohám. Tento proces má vliv na konfiguraci IDPS služby Azure Firewall Premium. Další informace najdete v tématu IDPS a privátní IP adresy.

• Úloha vidí připojení, která pocházejí z IP adresy podsítě služby Azure Firewall. Původní IP adresa klienta se zachovají v X-Forwarded-For hlavičce HTTP, kterou služba Application Gateway vloží. Azure Firewall také podporuje vložení IP adresy zdrojového klienta do hlavičky X-Forwarded-For . V tomto scénáři je IP adresa zdrojového klienta IP adresa aplikační brány.

• Provoz z Application Gateway do pracovní zátěže se obvykle odesílá do Azure Firewall pomocí směrovacích mechanismů Azure. Mezi tyto mechanismy patří trasy definované uživatelem (UDR) nakonfigurované v podsíti služby Application Gateway nebo trasy, které virtual WAN nebo směrovací server vloží. Explicitní definování privátní IP adresy služby Azure Firewall v back-endovém fondu služby Application Gateway je možné, ale nedoporučujeme to, protože odebírá některé z nativních funkcí služby Application Gateway, jako je vyrovnávání zatížení a trvalost relací.

Následující části popisují některé z nejběžnějších topologií, které můžete použít se službou Azure Firewall a službou Application Gateway.

Hub-and-spoke topologie

Návrh modelu hub and spoke obvykle nasazuje sdílené síťové komponenty v centrální virtuální síti a aplikaci specifické komponenty v sítích paprsků. Ve většině systémů je Azure Firewall Premium sdíleným prostředkem. Firewall webových aplikací Azure může být sdílené síťové zařízení nebo komponenta specifická pro aplikaci. Osvědčeným postupem je považovat službu Application Gateway za součást aplikace a nasadit ji ve vedlejší virtuální síti z následujících důvodů:

• Řešení potíží s upozorněními služby Azure Web Application Firewall může být obtížné. Obecně potřebujete podrobné znalosti aplikace, abyste se mohli rozhodnout, jestli jsou zprávy, které tyto alarmy aktivují, legitimní.

• Pokud se službou Application Gateway pracujete jako se sdíleným prostředkem, můžete překročit limity služby Application Gateway.

• Pokud nasadíte službu Application Gateway v centru, může dojít k problémům s řízením přístupu na základě role. K této situaci může dojít, když týmy spravují různé aplikace, ale používají stejnou instanci služby Application Gateway. Každý tým pak má přístup k celé konfiguraci služby Application Gateway.

V tradičních hvězdicových architekturách poskytují privátní zóny DNS snadný způsob použití DNS:

1. Nakonfigurujte privátní zónu DNS.
2. Propojte zónu s virtuální sítí, která obsahuje Azure Firewall Premium.
3. Ujistěte se, že záznam adresy existuje pro hodnotu, kterou Application Gateway používá pro provoz a kontroly stavu.

Následující diagram znázorňuje tok paketů, když je služba Application Gateway v paprskové virtuální síti. V takovém případě se klient připojí z veřejného internetu.

Diagram se skládá ze dvou hlavních částí, centrální virtuální sítě a vedlejší virtuální sítě. Modrá šipka představuje cestu požadavku klienta z internetu do podsítě aplikace v rámcové virtuální síti. Modrá šipka začíná ikonou, která představuje internet a odkazuje na podsíť služby Application Gateway v paprskové virtuální síti. Modrá šipka pokračuje z podsítě služby Application Gateway do podsítě služby Azure Firewall ve virtuální síti centra. Pak odkazuje z podsítě služby Azure Firewall na podsíť aplikace v paprskové virtuální síti. Dvojitá šipka označená jako propojení virtuální sítě propojuje centrální virtuální síť a části odchozí virtuální sítě. Zelená šipka představuje cestu požadavku klienta z podsítě aplikace zpět k klientovi. Zelená šipka začíná v podsíti aplikace a odkazuje na podsíť služby Azure Firewall. Zelená šipka pokračuje z podsítě služby Azure Firewall do podsítě služby Application Gateway a zpět do klienta.

1. Klient odešle požadavek na webový server.

2. Application Gateway zachytí pakety klienta a prozkoumá je. Pokud pakety projdou kontrolou, služba Application Gateway odešle pakety do back-endového virtuálního počítače. Když se pakety dostanou do Azure, trasa definovaná uživatelem v podsíti Application Gateway je předána službě Azure Firewall Premium.

3. Azure Firewall Premium spouští kontroly zabezpečení paketů. Pokud projdou testy, Azure Firewall Premium předává pakety virtuálnímu počítači aplikace.

4. Virtuální počítač odpoví a nastaví cílovou IP adresu na aplikační bránu. Trasu definovanou uživatelem v podsíti virtuálního počítače přesměruje pakety na Azure Firewall Premium.

5. Azure Firewall Premium předává pakety službě Application Gateway.

6. Application Gateway odpoví na klienta.

Provoz může také docházet z místní sítě místo z veřejného internetu. Provoz prochází buď přes virtuální privátní síť typu site-to-site (VPN), nebo přes Azure ExpressRoute. V tomto scénáři provoz nejprve dosáhne brány virtuální sítě v centru. Zbytek síťového toku je stejný jako předchozí diagram.

Diagram se skládá ze dvou hlavních částí, centrální virtuální sítě a vedlejší virtuální sítě. Modrá šipka představuje cestu požadavku klienta z místního prostředí na virtuální počítač aplikace. Modrá šipka začíná u místního klienta a odkazuje na podsíť brány virtuální sítě v centrální virtuální síti. Modrá šipka pokračuje z podsítě brány virtuální sítě do podsítě služby Application Gateway v paprskové virtuální síti. Pak směřuje na podsíť služby Azure Firewall ve virtuální síti hubu a pokračuje k podsíti aplikace v paprskové virtuální síti. Dvojitá šipka označená jako propojení virtuální sítě propojuje centrální virtuální síť a části odchozí virtuální sítě. Zelená šipka představuje cestu požadavku klienta z virtuálního počítače aplikace zpět k místnímu klientovi. Zelená šipka začíná na virtuálním počítači aplikace a odkazuje na podsíť služby Azure Firewall. Pak odkazuje na podsíť služby Application Gateway, na bránu virtuální sítě a pak na klienta.

1. Místní klient se připojí k bráně virtuální sítě.

2. Brána virtuální sítě předává pakety klienta službě Application Gateway.

3. Application Gateway prozkoumá pakety. Pokud projdou kontrolou, trasu definovanou uživatelem v podsíti služby Application Gateway předá pakety do služby Azure Firewall Premium.

4. Azure Firewall Premium spouští kontroly zabezpečení paketů. Pokud projdou testy, Azure Firewall Premium předává pakety virtuálnímu počítači aplikace.

5. Virtuální počítač odpoví a nastaví cílovou IP adresu na Službu Application Gateway. Trasu definovanou uživatelem v podsíti virtuálního počítače přesměruje pakety na Azure Firewall Premium.

6. Azure Firewall Premium předává pakety službě Application Gateway.

7. Application Gateway odesílá pakety do brány virtuální sítě.

8. Brána virtuální sítě odpovídá klientovi.

Topologie služby Virtual WAN

V této architektuře můžete také použít síťovou službu virtual WAN. Tato komponenta poskytuje mnoho výhod. Například eliminuje potřebu uživatelem udržovaných trasy definované uživatelem ve virtuálních sítích paprsků. Statické trasy můžete místo toho definovat ve směrovacích tabulkách virtuálního centra. Programování každé virtuální sítě, ke které se připojujete k centru, pak tyto trasy obsahuje.

Když jako síťovou platformu používáte Virtual WAN, výsledkem jsou dva hlavní rozdíly:

• Privátní zóny DNS nemůžete propojit s virtuálním centrem, protože microsoft spravuje virtuální centra. Jako vlastník předplatného nemáte oprávnění k propojení privátních zón DNS. V důsledku toho nemůžete přidružit privátní zónu DNS k zabezpečenému centru, které obsahuje Službu Azure Firewall Premium.

  Pokud chcete implementovat překlad DNS pro Azure Firewall Premium, použijte místo toho servery DNS:

  • Nakonfigurujte nastavení DNS služby Azure Firewall tak, aby používala vlastní servery DNS.

  • Nasaďte servery ve virtuální síti sdílených služeb, ke které se připojujete k virtuální síti WAN.

  • Propojte privátní zónu DNS s virtuální sítí sdílených služeb. Servery DNS pak můžou přeložit názvy, které Application Gateway používá v hlavičce hostitele HTTP. Další informace najdete v tématu Nastavení DNS služby Azure Firewall.

• Virtual WAN můžete použít pouze k programování tras v paprsku, pokud je předpona kratší (méně specifická) než předpona virtuální sítě. Například v předchozích diagramech má paprsková virtuální síť předponu 172.16.0.0/16. V takovém případě Virtual WAN není schopen vložit trasu, která odpovídá předponě virtuální sítě (172.16.0.0/16) ani žádné z podsítí (172.16.0.0/24, 172.16.1.0/24). Jinými slovy, Virtual WAN nemůže směrovat provoz mezi dvěma podsítěmi, které jsou ve stejné virtuální síti.

  Toto omezení se projeví v případě, že služba Application Gateway a cílový webový server jsou ve stejné virtuální síti. Virtual WAN nemůže vynutit provoz mezi službou Application Gateway a webovým serverem tak, aby procházel přes Azure Firewall Premium. Jedním z řešení je ruční konfigurace tras definovaných uživatelem (UDR) v podsítích Application Gateway a webového serveru.

Následující diagram znázorňuje tok paketů v architektuře, která používá Virtual WAN. V tomto scénáři pochází přístup ke službě Application Gateway z místní sítě. Instance VPN typu site-to-site nebo ExpressRoute se připojí k síti Virtual WAN. Internetový přístup se řídí podobnou cestou.

Diagram se skládá ze čtyř částí, centrální virtuální sítě, virtuální sítě služby Application Gateway, aplikační virtuální sítě a virtuální sítě sdílených služeb. Modrá šipka představuje cestu požadavku klienta z místního prostředí na virtuální počítač aplikace. Modrá šipka začíná u místního klienta a odkazuje na bránu VPN v centrální virtuální síti. Modrá šipka pak odkazuje z brány VPN na podsíť služby Application Gateway ve virtuální síti služby Application Gateway. Pokračuje z podsítě služby Application Gateway na ikonu, která představuje Azure Firewall Premium ve virtuální síti centra. Pak odkazuje z ikony služby Azure Firewall Premium na podsíť DNS ve virtuální síti sdílených služeb. Zelená šipka představuje cestu požadavku klienta zpět k místnímu klientovi. Zelená šipka začíná v podsíti DNS a odkazuje na ikonu Azure Firewall Premium v centrální virtuální síti. Modrá šipka představuje pakety, které projdou kontrolami zabezpečení služby Azure Firewall Premium. Odkazuje na virtuální počítač aplikace ve virtuální síti aplikace. Zelená šipka odkazuje zpět na Azure Firewall Premium a pokračuje v podsíti služby Application Gateway, pak bráně VPN a nakonec zpět ke klientovi.

1. Místní klient se připojuje k bráně VPN.

2. Brána VPN předává klientské pakety službě Application Gateway.

3. Application Gateway prozkoumá pakety. Pokud projdou kontrolou, podsíť služby Application Gateway předává pakety do služby Azure Firewall Premium.

4. Azure Firewall Premium požaduje překlad DNS ze serveru DNS ve virtuální síti sdílených služeb.

5. Server DNS odpoví na žádost o překlad.

6. Azure Firewall Premium spouští kontroly zabezpečení paketů. Pokud projdou testy, Azure Firewall Premium předává pakety virtuálnímu počítači aplikace.

7. Virtuální počítač odpoví a nastaví cílovou IP adresu na Službu Application Gateway. Podsíť aplikace přesměruje pakety na Azure Firewall Premium.

8. Azure Firewall Premium předává pakety službě Application Gateway.

9. Application Gateway odesílá pakety do brány VPN.

10. Brána VPN odpovídá klientovi.

Pokud použijete tento návrh, možná budete muset upravit směrování, které centrum distribuuje směrem k paprskovým virtuálním sítím. Konkrétně Application Gateway v2 podporuje pouze trasu 0.0.0.0/0 , která odkazuje na internet. Trasy s touto adresou, které neodkazuje na internet, přeruší připojení, které Microsoft vyžaduje ke správě služby Application Gateway. Pokud vaše virtuální centrum inzeruje trasu 0.0.0.0/0 , zabráníte jejímu šíření do podsítě služby Application Gateway provedením jednoho z těchto kroků:

• Vytvořte směrovací tabulku s trasou pro 0.0.0.0/0 a typem dalšího přeskoku Internet. Tuto trasu přidružte k podsíti, do které nasadíte službu Application Gateway.

• Pokud nasadíte službu Application Gateway ve vyhrazeném paprsku, zakažte šíření výchozí trasy v nastavení pro připojení k virtuální síti.

Topologie serveru směrování

Route Server nabízí jiný způsob, jak automaticky vkládat trasy do větví. Pomocí této funkce se vyhněte administrativní režii při údržbě směrovacích tabulek. Route Server kombinuje virtual WAN a hvězdicové varianty:

• Směrovací server můžete použít ke správě virtuálních sítí centra. V důsledku toho můžete virtuální síť centra propojit s privátní zónou DNS.

• Route Server má stejné omezení jako u služby Virtual WAN týkající se předpon IP adres. Trasy můžete vložit do paprsku pouze v případě, že je předpona kratší (méně specifická) než předpona virtuální sítě. Kvůli tomuto omezení musí být Služba Application Gateway a cílový webový server v různých virtuálních sítích.

Následující diagram znázorňuje tok paketů, když směrovací server zjednodušuje dynamické směrování. Vezměte v úvahu následující body:

• Směrovací server v současné době vyžaduje zařízení, které do nich vloží trasy, aby je odesílaly přes protokol BGP (Border Gateway Protocol). Azure Firewall Premium nepodporuje protokol BGP, proto místo toho použijte síťové virtuální zařízení jiné společnosti než Microsoft.

• Funkce síťového virtuálního zařízení v centru určuje, jestli vaše implementace potřebuje DNS.

Diagram se skládá ze čtyř částí, centrální virtuální sítě, virtuální sítě služby Application Gateway, aplikační virtuální sítě a virtuální sítě sdílených služeb. Virtuální síť centra obsahuje tři prvky, které představují podsíť brány virtuální sítě, podsíť směrovacího serveru a podsíť síťového virtuálního zařízení. Modrá šipka představuje cestu požadavku klienta z místního prostředí na virtuální počítač aplikace. Modrá šipka začíná u místního klienta a odkazuje na bránu virtuální sítě v části Virtuální síť centra. Modrá šipka pak odkazuje na podsíť služby Application Gateway ve virtuální síti služby Application Gateway. Modrá šipka pokračuje k podsíti NVA v hubové virtuální síti. Pak odkazuje z podsítě NVA na podsíť DNS ve virtuální síti sdílených služeb. Zelená šipka představuje cestu požadavku klienta zpět k místnímu klientovi. Začíná v podsíti DNS a směřuje k podsíti NVA v ústřední virtuální síti. Modrá šipka představuje pakety, které procházejí kontrolami zabezpečení síťového virtuálního zařízení (NVA). Odkazuje na virtuální počítač aplikace ve virtuální síti aplikace. Zelená šipka ukazuje zpět na podsíť NVA, pokračuje na podsíť Application Gateway, dále na bránu virtuální sítě a nakonec zpět k klientovi.

1. Místní klient se připojí k bráně virtuální sítě.

2. Brána virtuální sítě předává pakety klienta službě Application Gateway.

3. Application Gateway prozkoumá pakety. Pokud projdou kontrolou, podsíť služby Application Gateway přesměruje pakety do back-endového počítače. Route Server vloží trasu do podsítě Application Gateway, která předává provoz k síťovému virtuálnímu zařízení (NVA).

4. Podsíť virtuálního zařízení NVA požaduje rezoluci DNS ze serveru DNS ve virtuální síti sdílených služeb.

5. Server DNS odpoví na žádost o překlad.

6. Síťové virtuální zařízení spouští na paketech kontroly zabezpečení. Pokud projdou testy, síťové virtuální zařízení předá pakety virtuálnímu počítači aplikace.

7. Virtuální stroj aplikace odpoví a nastaví cílovou IP adresu na Application Gateway. Směrovací server vloží trasu do podsítě virtuálního počítače, která přesměruje pakety do NVA.

8. Síťové virtuální zařízení předává pakety službě Application Gateway.

9. Application Gateway odesílá pakety do brány virtuální sítě.

10. Brána virtuální sítě odpovídá klientovi.

Podobně jako u služby Virtual WAN možná budete muset změnit směrování, když používáte Route Server. Pokud inzerujete trasu 0.0.0.0/0 , může se rozšířit do podsítě služby Application Gateway. Služba Application Gateway ale danou trasu nepodporuje. V tomto případě nakonfigurujte směrovací tabulku pro podsíť služby Application Gateway. Do této tabulky zahrňte trasu pro 0.0.0.0/0 a typ dalšího směrování Internet.

IDPS a privátní IP adresy

Azure Firewall Premium rozhoduje, která pravidla IDPS se mají použít na základě zdrojových a cílových IP adres paketů. Azure Firewall ve výchozím nastavení zpracovává privátní IP adresy v rozsahech RFC 1918 (10.0.0.0/8, 192.168.0.0/16a) a 172.16.0.0/12RFC 6598 (100.64.0.0/10) jako interní. Pokud tedy službu Application Gateway nasadíte do podsítě v jednom z těchto rozsahů, Azure Firewall Premium považuje provoz mezi službou Application Gateway a úlohou za interní. Proto se používají pouze podpisy IDPS označené k použití na interní provoz nebo na jakýkoli provoz. Podpisy IDPS označené k použití pro příchozí nebo odchozí provoz se nepoužijí na provoz mezi službou Application Gateway a úlohou. Další informace najdete v tématu Pravidla IDPS služby Azure Firewall.

Nejjednodušší způsob, jak vynutit použití příchozích podpisových pravidel IDPS na provoz mezi službou Application Gateway a úlohou, je umístěním služby Application Gateway do podsítě, která používá předponu mimo privátní rozsahy. Pro tuto podsíť nemusíte nutně používat veřejné IP adresy. Místo toho můžete přizpůsobit IP adresy, které Azure Firewall Premium považuje za interní pro IDPS. Pokud například vaše organizace nepoužívá rozsah 100.64.0.0/10, můžete tento rozsah eliminovat ze seznamu interních předpon pro IDPS a nasadit službu Application Gateway v podsíti nakonfigurované s IP adresou v 100.64.0.0/10. Další informace najdete v tématu Rozsahy privátních IPDS služby Azure Firewall Premium.

Přispěvatelé

Microsoft udržuje tento článek. Tento článek napsali následující přispěvatelé.

Hlavní autor:

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

Pokud chcete zobrazit nepublikované profily LinkedIn, přihlaste se na LinkedIn.

Další kroky

• Zabezpečení sítí s nulovou důvěryhodností
• Směrování provozu virtuální sítě
• Jak funguje aplikační brána

Související prostředky

• Implementace zabezpečené hybridní sítě
• Hub-spoke síťová topologie v Azure
• Hvězdicová síťová topologie využívající Virtual WAN