Příchozí přístup z internetu: zpřístupněte svou aplikaci z internetu

Tento článek vám pomůže zvolit správnou Azure službu, aby byla vaše aplikace přístupná z internetu. Porovnává veřejné IP adresy, Azure Load Balancer, Application Gateway, Azure Front Door a Azure Traffic Manager. Vyberte možnost, která odpovídá požadavkům na protokol, škálování a zabezpečení vaší úlohy.

Co tento článek popisuje

Každá Azure úloha, která obsluhuje externí uživatele, potřebuje cestu příchozího přenosu dat: způsob, jak se internetový provoz bezpečně a spolehlivě dostane k vaší aplikaci. Volba nesprávné služby příchozího přenosu dat vede k nadměrnému zřízení, mezerám v zabezpečení nebo zbytečné složitosti. Tento článek vám pomůže vyhodnotit sedm Azure služeb, které přijímají příchozí připojení od externích uživatelů a směrují tato připojení k back-endovým prostředkům ve virtuální síti. Můžete vybrat kombinaci, která odpovídá vašemu protokolu, škálování, zeměpisné poloze a stavu zabezpečení.

Note

Tento článek se zaměřuje na to, jak provoz vstupuje do vaší Azure sítě z internetu. Informace o tom, jak vyrovnávat a dodávat provoz napříč back-endy vaší aplikace (včetně podrobných porovnání Azure Load Balancer, služby Application Gateway a Azure Front Door), najdete v tématu Doručování a výkon aplikací.

Kdo potřebuje tento článek

Pokud platí jedna nebo více z těchto podmínek, přečtěte si tento článek:

• Vaše aplikace musí přijímat příchozí připojení od uživatelů nebo systémů na internetu.
• Na základě protokolu a rozsahu musíte zvolit veřejnou IP adresu, Load Balancer, Application Gateway, Front Door nebo Traffic Manager.
• Potřebujete navrhnout zabezpečený veřejný vstupní bod pro webové úlohy, rozhraní API nebo TCP/UDP.
• Musíte zkombinovat vystavení internetu s WAF, ochranou DDoS, ukončením protokolu TLS nebo regionální a globální distribucí provozu.

Tip

Postupujete podle scénáře? V horní části stránky vyberte svůj scénář pro přizpůsobené pokyny. Následující základní pokyny platí pro všechny čtenáře.

Přesun fokusu metodou "lift and shift": Vaše migrovaná aplikace musí být dostupná z internetu. Vyhodnoťte, jestli potřebujete Application Gateway, Front Door nebo jednodušší přístup k veřejné IP adrese. Mnoho úloh metodou "lift and shift" je interních, takže tento článek můžete zcela přeskočit, pokud migrované aplikace nebudou obsluhovat externí uživatele.

Přečtěte si tento článek, pokud:

• Migrují místní webovou aplikaci na Azure a musí se rozhodnout, jak ji veřejně zveřejnit.
• Je potřeba vyhodnotit, jestli se pro migrované úlohy vyžaduje příchozí přenos dat z internetu vůbec.
• Chcete pochopit nejjednodušší možnost příchozího přenosu dat připraveného pro produkční prostředí pro liftovanou aplikaci.

Zaměření modernizace: Vzory provozu orientované na zákazníky určují externí tvar vaší architektury. Front Door zpracovává webové aplikace, Traffic Manager zpracovává mobilní aplikace a aplikace API. Vaše modernizované úlohy PaaS (App Service, AKS) potřebují dobře definovanou příchozí přístupovou cestu, která je integrována s vaším modelem zabezpečení hub-and-spoke.

Přečtěte si tento článek, pokud:

• Nasaďte veřejně přístupnou aplikaci, ke které mají externí uživatelé přístup přes internet.
• Je potřeba zvolit mezi Azure Front Door webových aplikací a Traffic Managerem pro mobilní úlohy nebo úlohy rozhraní API.
• Chcete porozumět tomu, jak je ingress integrován s firewallem centrálního uzlu jako cíl DNAT.
• Potřebujete chránit internetové koncové body pomocí firewallu webových aplikací (WAF) nebo ochrany před útoky DDoS.

Zaměření napříč cloudovými prostředími: Zahrňte příchozí internetový provoz pouze v případě, že migrovaná aplikace je veřejně přístupná. Mnoho multicloudových aplikací je určeno pouze pro interní použití a komunikuje mezi cloudy po soukromých přenosových trasách. Pokud je vaše úloha veřejně přístupná (například webová aplikace určená pro zákazníky migrovaná z jiného cloudu), potřebujete cestu příchozího přenosu dat v Azure.

Přečtěte si tento článek, pokud:

• Migrují veřejnou aplikaci z AWS nebo Google Cloudu na Azure.
• Pro migrovanou zátěž potřebujete službu Application Gateway s WAF ve virtuální síti typu spoke.
• Chcete se vyhnout přímému přiřazení veřejných IP adres virtuálním počítačům během migrace mezi cloudy.

Azure služby a funkce

Azure poskytuje několik služeb pro příchozí provoz z internetu. Každá služba funguje v jiné vrstvě síťového zásobníku a obsluhuje jiný případ použití.

Service	Vrstva	Scope	Co poskytuje	Kdy ji použít
Veřejná IP adresa (standardní skladová položka)	3	Regionální	Přímo přiřazená směrovatelná adresa IPv4 nebo IPv6 Zónově redundantní ve výchozím nastavení.	Jednoduché scénáře s nízkým provozem. Nedoporučuje se pro produkční prostředí bez nástroje pro vyrovnávání zatížení.
Azure Load Balancer (standardní, veřejná)	4 (TCP/UDP)	Regionální	Distribuuje příchozí provoz TCP/UDP mezi back-endové virtuální počítače. Front-end s redundancí napříč zónami. Kontroly stavu vyřadí instance v nevyhovujícím stavu.	Úlohy jiné než HTTP/S vyžadující vysokou dostupnost Herní servery, koncové body IoT nebo jiné služby TCP/UDP.
Azure Load Balancer (standard, interní)	4 (TCP/UDP)	Regionální	Vyrovnávání zatížení vrstvy 4 ve virtuální síti Žádná veřejná IP adresa. Směruje provoz mezi interními úrovněmi.	Vícevrstvé aplikace, ve kterých veřejný frontend distribuuje provoz mezi backendové virtuální počítače. Provoz východ-západ v topologii hub-and-spoke. Ne přímo internetové, ale běžně spárované s veřejnou službou příchozího přenosu dat.
Azure Application Gateway	7 (HTTP/S)	Regionální	Vyrovnávání zatížení HTTP/S se směrováním podle adresy URL, ukončením SSL/TLS, afinitou relací a automatickým škálováním.	Jednoregionální aplikace HTTP/S vyžadující směrování na základě cest, afinitu na základě souborů cookie nebo odlehčení SSL.
Application Gateway + WAF	7 (HTTP/S)	Regionální	Application Gateway s Web Application Firewallem. Chrání před útoky OWASP top 10 pomocí výchozí sady pravidel (DRS), včetně pravidel analýzy hrozeb Microsoft.	Veřejné webové aplikace vyžadující vyrovnávání zatížení vrstvy 7 a ochranu WAF v jedné oblasti.
Azure Front Door	7 (HTTP/S)	Globální	Globální nástroj pro vyrovnávání zátěže HTTP/S s integrovanými funkcemi CDN, WAF a směrování provozu. Ukončuje TCP/TLS v edge PoP v blízkosti uživatelů pomocí akcelerace Split TCP.	Aplikace pro více oblastí s globální uživatelskou základnou. Úlohy vyžadující ukládání do mezipaměti prostřednictvím CDN, globální WAF a automatické přepnutí při selhání
Azure Traffic Manager	DNS	Globální	Směrování provozu založeného na DNS Vrátí CNAME do nejbližšího nebo nejzdravějšího regionálního koncového bodu. Klienti se připojují přímo. Traffic Manager nikdy neuvidí provoz aplikací.	Přepnutí při selhání na úrovni DNS ve více regionech Jiné protokoly než HTTP/S, kde se služba Front Door nepoužívá. Směrování podle zeměpisné oblasti, výkonu nebo priority

Note

Veřejné IP adresy SKU Basic budou vyřazeny z provozu (září 2025). Stávající základní IP adresy zůstanou v provozu, ale nejsou podporovány a nevztahuje se na ně smlouva SLA. Pro všechna nová nasazení použijte skladovou položku Standard.

Jak jednotlivé služby fungují

Porozumění interní architektuře každé služby vám pomůže předpovědět výkon, řešit problémy a plánovat velikost podsítě.

Veřejná IP adresa

Veřejná IP adresa Standard SKU je softwarově definovaný prostředek, který přiřazuje směrovatelnou adresu IPv4 nebo IPv6 přímo k síťovému rozhraní, frontendu nástroje pro vyrovnávání zatížení nebo bráně. Adresa je v podporovaných oblastech standardně redundantní napříč zónami, což znamená, že platforma zajišťuje převzetí služeb při selhání napříč zónami dostupnosti, aniž byste museli cokoli měnit. Veřejné IP adresy nemají žádné zpracování provozu. Pakety proudí přímo do připojeného prostředku bez kontroly stavu nebo distribuční logiky.

Azure Load Balancer (standardní, veřejná)

Standard Load Balancer používá hašovací distribuční algoritmus pro toky definované pěticí parametrů (zdrojová IP adresa, zdrojový port, cílová IP adresa, cílový port, protokol). Funguje výhradně v datové cestě na 4. vrstvě, takže nikdy neukončuje spojení ani neinspektuje datovou část paketů. Testy stavu (TCP, HTTP nebo HTTPS) průběžně kontrolují instance back-endu a během několika sekund vyřazují nefunkční instance z rozdělování provozu. Load Balancer se škáluje automaticky. Neexistuje žádné plánování kapacity ani určení velikosti instancí.

Azure Load Balancer (standard, interní)

Interní Load Balancer funguje stejně jako její veřejný protějšek, ale používá privátní front-endovou IP adresu z podsítě virtuální sítě. Distribuuje provoz mezi interní úrovně, jako je například webová vrstva odesílající provoz do clusteru rozhraní API střední vrstvy. Protože nemá žádnou veřejnou IP adresu, není pro internet neviditelná. Zkombinujte ji s veřejnou službou pro příchozí provoz, například Front Door, Application Gateway nebo veřejným nástrojem pro vyrovnávání zatížení, která obsluhuje externí hraniční vrstvu.

Azure Application Gateway

Application Gateway je vyhrazené virtuální zařízení nasazené do podsítě virtuální sítě. Ukončuje připojení TLS na bráně, kontroluje hlavičky HTTP a adresy URL a směruje požadavky do fondů backendu na základě pravidel cest, hlaviček hostitele nebo vlastních testů stavu. Skladová položka v2 podporuje automatické škálování (0 až 125 instancí) a zónovou redundanci. Vzhledem k tomu, že je v síti VNet rezident, může přistupovat k privátním back-endům bez nutnosti veřejných IP adres na těchto back-endech.

Systém Application Gateway s WAF

Když přidáte vrstvu WAF, povolíte sadu základních pravidel OWASP a pravidla analýzy hrozeb Microsoft přímo v kanálu zpracování služby Application Gateway. Před dosažením pravidel směrování prochází každý požadavek HTTP přes modul WAF. WAF podporuje zásady pro jednotlivé weby, takže můžete mít odlišné konfigurace pravidel pro různé kombinace listeneru nebo hostitele v rámci stejné brány. WAF funguje buď v režimu detekce (pouze protokol), nebo v režimu prevence (blok a protokol).

Azure Front Door

Front Door funguje v rámci globální hraniční sítě Microsoftu (190+ bodů přítomnosti). Když se uživatel připojí, k navázání spojení TCP a vyjednání TLS dojde v nejbližším bodě přítomnosti pomocí technologie Split TCP. Bod přítomnosti (PoP) udržuje trvale navázané připojení k vašemu původnímu serveru, čímž eliminuje latenci při studeném startu, kterou by uživatelé zaznamenali při přímém připojení. Front Door provádí směrování na 7. vrstvě, inspekci WAF, ukládání do mezipaměti a kompresi na okraji sítě před předáním požadavku k nejbližšímu zdravému zdroji po páteřní síti Microsoftu.

Azure Traffic Manager

Traffic Manager je služba založená na DNS bez zapojení cesty k datům. Když klient přeloží název hostitele Traffic Manageru, vrátí hodnotu CNAME, která odkazuje na nejzdravější nebo nejbližší koncový bod na základě vaší metody směrování (priorita, vážená hodnota, výkon, geografická, vícehodnota nebo podsíť). Traffic Manager průběžně testuje stav koncového bodu a odpovídajícím způsobem aktualizuje odpovědi DNS. Protože nikdy neuvidí provoz aplikací, funguje s jakýmkoli protokolem: HTTP, TCP, UDP nebo proprietárními protokoly.

Porovnání nákladových modelů

Každá služba ingress má odlišný model účtování. Pomocí této tabulky můžete odhadnout náklady na očekávaný objem provozu.

Service	Model fakturace	Klíčové faktory ovlivňující náklady	Bezplatná úroveň nebo zahrnuté funkce
Veřejná IP adresa	Za hodinu (připojeno) + za odchozí GB	Počet připojených hodin; Poplatky za výchozí přenos dat	Prvních 100 GB odchozích dat měsíčně zdarma (globálně)
Standard Load Balancer	Za hodinu za pravidlo + za každý zpracovaný GB	Počet pravidel vyvažování zátěže; data zpracovaná pomocí LB	None
Aplikační brána	Za hodinu za instanci + spotřebované jednotky kapacity	Instanční hodiny; výpočetní, připojovací a propustnostní kapacitní jednotky	None
Application Gateway + WAF	Za hodinu na instanci (ceny na úrovni WAF) + jednotky kapacity	Stejné jako Application Gateway, ale s hodinovou sazbou pro úroveň WAF	None
Azure Front Door	Za požadavek + přenos za GB + požadavky na WAF	Směrování požadavků, přenos dat z edge do klienta, vyhodnocování pravidel WAF	Úroveň Standard zahrnuje některé základní směrování.
Azure Traffic Manager	Za milion dotazů DNS + za koncový bod kontroly stavu	Objem dotazů DNS; počet monitorovaných koncových bodů	Prvních 1 miliard dotazů má vrstvené ceny

Tip

U úloh s nízkým provozem (pod 1 milion požadavků za měsíc) může být model služby Front Door pro jednotlivé požadavky cenově výhodnější než pevné náklady na službu Application Gateway za hodinu. S růstem provozu se hodinové modely stávají předvídatelnějšími. Spusťte cenovou kalkulačku Azure s očekávanou propustností, která se má porovnat.

Jak zvolit

Pomocí následujících rozhodovacích tabulek vyberte správnou službu příchozího přenosu dat pro vaši úlohu. Začněte tabulkou rozhodnutí vysoké úrovně a pak pomocí podrobného porovnání potvrďte svou volbu.

Application Gateway vs. Front Door vs. Traffic Manager

Tato tabulka vám pomůže vybrat si mezi třemi nejběžnějšími službami HTTP a HTTPS příchozího přenosu dat.

Vaše potřeby	Doporučená služba	Proč
Provoz HTTP/S, jedna oblast, ochrana WAF	Systém Application Gateway s WAF	Služba regionální vrstvy 7 se směrováním na základě cest a WAF Běží ve vaší virtuální síti.
Provoz HTTP/S, více oblastí, globální uživatelé, CDN + WAF	Azure Front Door	Globální služba vrstvy 7, která je ukončena na okrajových PoPs. Integrované CDN, WAF a automatické přepnutí při selhání.
Směrování více oblastí pro protokoly jiné než HTTP/S nebo pouze směrování na úrovni DNS	Azure Traffic Manager	Směrování založené na DNS, které funguje s jakýmkoli protokolem. Žádné ukončení připojení.
Více oblastí HTTP/S s regionálními požadavky na zpracování vázané na virtuální síť	Application Gateway + Traffic Manager	Platné pro úlohy, které vyžadují hlubokou integraci virtuální sítě nebo regionální suverenitu dat s regionální kontrolou WAF. U většiny scénářů HTTP/S s více oblastmi raději upřednostněte službu Front Door.

Tip

U většiny úloh HTTP a HTTPS ve více oblastech je služba Front Door upřednostňovanou volbou oproti službě Application Gateway v kombinaci s Traffic Managerem. Front Door poskytuje integrované WAF, CDN a automatické převzetí služeb při selhání, aniž byste museli spravovat více regionálních instancí služby Application Gateway. Kombinace služby Application Gateway + Traffic Manager zůstává platná pro úlohy, které vyžadují místní zpracování vázané na virtuální síť, Private Link původy přístupné pouze v rámci virtuální sítě nebo zákonné požadavky, které vyžadují regionální suverenitu dat.

Porovnání služeb ingress

Toto podrobné porovnání použijte, když potřebujete porozumět možnostem jednotlivých služeb.

Service	Vrstva	Globální nebo regionální	Ukončení připojení	K dispozici WAF	Sondy stavu	Nejvhodnější pro
Veřejná IP adresa	3	Regionální	Ne (přímo na virtuální počítač)	No	No	Úlohy pro vývoj/testování s jednou instancí bez požadavků na vysokou dostupnost
Standard Load Balancer (veřejné)	4	Regionální	Ne (průchozí)	No	Ano (TCP, HTTP, HTTPS)	Úlohy mimo HTTP: hraní, IoT, vlastní TCP/UDP
Standard Load Balancer (interní)	4	Regionální	Ne (průchozí)	No	Ano (TCP, HTTP, HTTPS)	Interní úroveň za veřejnou službou příchozího přenosu dat
Aplikační brána	7	Regionální	Ano (ukončení protokolu TLS)	Ne (přidání vrstvy WAF)	Ano (vlastní HTTP/S)	HTTP/S pro jednu oblast se směrováním podle cest
Application Gateway + WAF	7	Regionální	Ano (ukončení protokolu TLS)	Ano (sada pravidel DRS)	Ano (vlastní HTTP/S)	Webové aplikace v jedné oblasti, které potřebují WAF
Azure Front Door	7	Globální	Ano (rozdělení protokolu TCP v PoP)	Ano (integrované)	Ano (HTTP/S)	Http/S s více oblastmi s globální akcelerací
Azure Traffic Manager	DNS	Globální	Ne (pouze DNS)	No	Ano (HTTP/S, TCP)	Převzetí služeb při selhání na úrovni DNS ve více oblastech, jakýkoli protokol

Architektura vstupu do internetu

Následující diagram znázorňuje běžné vzorce řetězení služeb pro příchozí provoz do Azure úloh. Každý vzor kombinuje služby vrstvy 7 a vrstvy 4 tak, aby odpovídaly konkrétnímu protokolu, oblastnímu rozsahu a stavu zabezpečení.

Běžné vzory příchozího přenosu dat

Následující vzorce kombinují více služeb a vytvářejí ucelenou ingress architekturu. Zvolte vzor, který odpovídá vašim požadavkům na protokol, oblastnímu rozsahu a stavu zabezpečení.

Model 1: Globální webová aplikace s hraničním zabezpečením

Služby: Front Door → Application Gateway (s WAF) → virtuální počítače a kontejnery

Scénář: Aplikace SaaS obsluhující zákazníky v Severní Americe, Evropě a Asii potřebuje globální akceleraci, ochranu před útoky DDoS na okraji sítě a regionální směrování podle cest k různým mikroslužbám.

Front Door ukončí uživatelská připojení v nejbližším místě přítomnosti (PoP), použije globální pravidla WAF a ukládá statický obsah do mezipaměti. Provoz je směrován přes páteřní síť Microsoftu do regionální brány Application Gateway, která provádí směrování na základě URL (například /api/* do fondu API, /static/* do back-endu úložiště). Tento model poskytuje dvě vrstvy kontroly WAF: jednu na okraji a druhou v oblasti.

Model 2: Více oblastí bez PROTOKOLU HTTP s převzetím služeb při selhání DNS

Služby: Traffic Manager → Standard Load Balancer (pro každou oblast) → virtuální počítače

Scénář: Herní společnost provozuje vyhrazené herní servery na portu UDP 7777 napříč třemi oblastmi. Hráči se automaticky připojí k nejbližšímu funkčnímu regionu.

Traffic Manager používá metodu směrování výkonu k vrácení záznamu DNS pro oblast s nejnižší latencí. Každá oblast má Standard Load Balancer, který distribuuje provoz UDP v rámci škálovací sady virtuálních počítačů. Pokud testy stavu zjistí selhání oblasti, Traffic Manager aktualizuje DNS tak, aby přesměroval hráče do další nejbližší oblasti.

Vzor 3: Jednoduchá regionální webová aplikace s WAF

Služby: Application Gateway (s WAF) → VM

Scénář: Interní obchodní aplikace, která je vystavená externím partnerům. Jedna oblast, střední provoz, vyžaduje ochranu OWASP a ukončení protokolu TLS.

Application Gateway poskytuje směrování podle cest, afinitu na základě souborů cookie pro správu relací a ochranu pomocí WAF, a to vše z jediného regionálního prostředku v rámci virtuální sítě. Tento model zabraňuje složitosti a nákladům globální služby, pokud je provoz geograficky soustředěný.

Vzor 4: Front Door s privátními zdroji původu se zakázaným veřejným přístupem

Služby: Front Door Premium → Private Link → interní nástroj pro vyrovnávání zatížení → virtuální počítače

Scénář: Aplikace finančních služeb s přísnými požadavky, že původ nesmí mít žádné vystavení veřejné IP adresy. Veškerý provoz musí procházet páteřní sítí společnosti Microsoft bez přeskoků přes veřejný internet.

Front Door Premium se připojuje ke zdroji přes koncový bod Private Link. Back-end původu nemá žádnou veřejnou IP adresu a není vystaven internetu. Tento vzor poskytuje zabezpečení plně privátního zdroje v kombinaci s výkonnostními výhodami globální edge sítě služby Front Door.

Příchozí provoz pro více oblastí se službou Front Door

Následující diagram znázorňuje Azure Front Door jako globální vstupní bod a směruje uživatele k nejbližšímu funkčnímu regionálnímu zdroji s automatickým přesměrováním při selhání.

Předpoklady

Než aplikaci zveřejníte na internetu, ujistěte se, že máte splněné následující součásti:

• Nasazená virtuální síť: Vaše back-endové prostředky musí běžet uvnitř Azure virtuální sítě s podsítěmi s správnou velikostí. Pokyny k plánování podsítí najdete v tématu Návrh virtuální sítě a podsítí .
• Spuštěná úloha: K poskytování provozu potřebujete alespoň jeden back-endový prostředek (virtuální počítač, kontejner nebo služba platformy).
• Název DNS: Veřejný název DNS, který externí uživatelé používají pro přístup k vaší aplikaci. Můžete použít Azure DNS nebo poskytovatele DNS třetí strany.
• Plánování podsítě pro služby příchozího přenosu dat: Application Gateway vyžaduje vyhrazenou podsíť (minimálně /24 doporučeno pro produkční prostředí). Standard Load Balancer back-endové instance můžou sdílet podsíť s jinými prostředky.

Aspekty návrhu

Vyhodnoťte, jestli je pro vaše zvedané úlohy potřeba příchozí přenos dat z internetu. Mnoho místních aplikací je interních a zůstává po migraci. Pokud se vyžaduje příchozí přenos dat, ponechte architekturu jednoduchou:

• Application Gateway s WAF poskytuje vstupní bod na 7. vrstvě pro jeden region s ukončením TLS a ochranou podle OWASP. Tento přístup je nejběžnější u webových aplikací, které byly dříve migrovány a běžely za lokálním reverzním proxy serverem.
• Veřejná IP adresa s NSG je přijatelná pro úlohy s nízkým provozem, které nepoužívají protokol HTTP (například pro službu TCP, ke které se partneři připojují). Omezte NSG pouze na známé zdrojové IP adresy.
• Vyhněte se přiřazování veřejných IP adres přímo k virtuálním počítačům. Umístěte nástroj pro vyrovnávání zatížení nebo službu Application Gateway mezi internetem a back-endem.

Pokud vaše zvedané aplikace neslouží externím uživatelům, přeskočte tento článek a pokračujte v odchozím přístupu k internetu.

Vaše modernizované úlohy mají odlišné vzory příchozího přenosu dat na základě typu aplikace:

• Azure Front Door pro webové aplikace určené pro zákazníky (například ContosoBiz). Front Door poskytuje globální akceleraci, integrovanou WAF, ukládání do mezipaměti CDN a automatické převzetí služeb při selhání napříč oblastmi. Použijte vážené směrování pro nasazení typu aktivní-aktivní.
• Azure Traffic Manager pro mobilní aplikace a aplikace API (například ContosoCare). Traffic Manager poskytuje směrování založené na DNS pro protokoly jiné než HTTP nebo v případě, že klienti potřebují přímé regionální připojení.
• Firewall v centru jako cíl pro DNAT: Veškerý příchozí datový provoz prochází firewallem Azure Firewall v centru, než dosáhne aplikačních vrstev. Firewall provádí překlad cílové adresy (DNAT), aby směroval filtrovaný provoz do správného spoke uzlu. Tento model zajišťuje, že žádný nescrubovaný internetový provoz obchází centralizované bezpečnostní prvky.

Zkombinujte službu Front Door se službou Application Gateway v každém regionu pro dvouvrstvou inspekci WAF: jednu na globálním okraji sítě a druhou na hranici regionu.

U veřejně přístupných aplikací migrovaných z AWS nebo Google Cloudu nasaďte službu Application Gateway s WAF v paprskové virtuální síti, ve které se nachází úloha:

• Application Gateway + WAF ve spoke virtuální síti: Nasaďte regionální bránu Application Gateway s aktivovaným WAF v režimu Prevention. Tento přístup zachovává ingress blízko úlohy, aniž by provoz musel procházet přes uzel hub kvůli inspekci HTTP.
• Žádné přímé veřejné IP adresy na virtuálních počítačích: Nikdy nepřiřazujte veřejné IP adresy přímo migrovaným virtuálním počítačům. Veškerý internetový provoz vstupuje prostřednictvím služby Application Gateway.
• Omezte přístup ke zdrojům původu: Pokud byla aplikace dříve za službou AWS Application Load Balancer (ALB) nebo Google Cloud Load Balancing, převeďte tento model příchozí komunikace na Application Gateway pro regionální pracovní zátěže nebo na Front Door pro globální pracovní zátěže.

Pokud je vaše úloha napříč cloudy pouze interní (komunikuje mezi cloudy prostřednictvím privátního tranzitu), přeskočte tento článek a pokračujte na článek Azure Firewall a inspekce provozu.

Bezpečnostní aspekty

Internetový ingress je vstupní branou vaší aplikace. Je to hranice, kde nedůvěryhodný internetový provoz vstupuje do vašeho Azure prostředí. Dodržujte tyto postupy, abyste zabezpečili cestu příchozího provozu.

Nikdy nezpřístupňujte virtuální počítače přímo s veřejnými IP adresami

Nepřiřazujte veřejnou IP adresu přímo síťovému rozhraní virtuálního počítače pro obsluhu provozu aplikací na portech 80 nebo 443. Místo toho umístěte nástroj pro vyrovnávání zatížení nebo službu Application Gateway mezi internetem a virtuálními počítači. Tento přístup nabízí:

• Kontroly stavu pro odebrání selhaných instancí z provozu
• Jeden bod pro ukončení protokolu SSL nebo TLS
• Místo pro použití pravidel WAF a omezování rychlosti
• Centralizované protokolování veškerého příchozího provozu

Caution

Veřejná IP adresa přímo na virtuálním počítači zveřejňuje každý otevřený port pro internet. Pokud má skupina zabezpečení sítě virtuálního počítače chybně nakonfigurované pravidlo, útočníci získají přímý přístup k operačnímu systému.

Povolení WAF v režimu prevence

Pokud nasadíte Službu Application Gateway s WAF nebo Azure Front Door s WAF, nastavte pro produkční úlohy režim prevence WAF. Režim prevence blokuje škodlivé požadavky předtím, než se dostanou k vaší aplikaci. Režim detekce protokoluje pouze hrozby, aniž by je blokoval. Režim detekce použijte pouze během počátečního testování k ladění pravidel a identifikaci falešně pozitivních výsledků.

Výchozí sada pravidel WAF (DRS) chrání před útoky OWASP top 10, včetně injektáže SQL, skriptování mezi weby a vzdáleného spuštění kódu. DrS obsahuje také pravidla Microsoft analýzy hrozeb, která detekují známé škodlivé IP adresy a datové části.

Povolení ochrany před útoky DDoS

Všechny virtuální sítě s veřejnými prostředky by měly mít povolenou ochranu před útoky DDoS. Azure DDoS Network Protection poskytuje adaptivní ladění, telemetrii útoků a ochranu nákladů pro vaše veřejné IP adresy. Bez ochrany před útoky DDoS může objemový útok zahltit vaše příchozí šířku pásma a způsobit, že vaše aplikace bude nedostupná.

Podrobnosti najdete v tématu Ochrana před útoky DDoS pro vaši síť.

Používejte skupiny zabezpečení sítě k zajištění vícevrstvé ochrany

I když používáte nástroj pro vyrovnávání zatížení nebo službu Application Gateway, nakonfigurujte pravidla skupiny zabezpečení sítě v back-endových podsítích tak, aby omezovala, které zdroje provozu se dostanou k vašim virtuálním počítačům. Správně nakonfigurovaná NSG:

• Povoluje provoz pouze z podsítě nástroje pro vyrovnávání zátěže nebo z jeho značky služby.
• Odepření přímého příchozího provozu z internetu do back-endových virtuálních počítačů
• Zaznamenává zamítnutý provoz pro bezpečnostní monitorování

Plánování NSG najdete v tématu Skupiny zabezpečení sítě a skupiny zabezpečení aplikací.

Vynucení protokolu TLS 1.2 nebo novějšího

Nakonfigurujte všechny služby příchozího přenosu dat tak, aby přijímaly pouze protokol TLS 1.2 nebo TLS 1.3. Zakažte protokol TLS 1.0 a 1.1, který má známé chyby zabezpečení. Služba Application Gateway i Front Door podporují konfiguraci minimální verze protokolu TLS prostřednictvím nastavení zásad PROTOKOLU TLS. Pokud nemáte specifické požadavky na dodržování předpisů, použijte předdefinované zásady, například AppGwSslPolicy20220101 pro službu Application Gateway, místo vlastních konfigurací šifer.

Uzamknout původ pro Službu Front Door

Pokud používáte Azure Front Door, omezte servery původu tak, aby přijímaly provoz jenom ze služby Front Door. Pokud váš původ přijímá provoz z libovolného zdroje, můžou chybní aktéři obejít WAF služby Front Door tak, že se připojí přímo k ip adrese původu a zneefektivní vaši investici do WAF.

Uzamčení původu používá dva nezávislé ověřovací mechanismy. Použijte obě v rámci vícevrstvé obrany:

Omezení značek služeb (síťová vrstva)

Nakonfigurujte skupinu zabezpečení sítě (NSG) vašeho zdroje původu nebo Azure Firewall tak, aby povolovaly příchozí provoz HTTP/HTTPS pouze z tagu služby AzureFrontDoor.Backend. Tato značka služby obsahuje všechny rozsahy IP adres používané službou Front Door pro připojení ke zdrojům. Toto pravidlo použijte na podsíť nebo rozhraní NIC, kde se nachází váš původní server:

• Pravidlo NSG: Priorita 100, Zdroj = značka AzureFrontDoor.Backendslužby , cíl = vaše back-endová podsíť, porty = 80, 443, akce = Povolit.
• Ve výchozím nastavení zakázat: Ujistěte se, že žádné jiné pravidlo neumožňuje příchozí provoz na portech 80/443 z internetu. O to se postará výchozí pravidlo DenyAllInbound v NSG, pokud nepřidáte obecnější pravidlo Povolit.

Samotný tag služby nestačí, protože všechny instance služby Front Door u všech zákazníků Azure sdílejí stejné rozsahy IP adres tagu služby. Škodlivý aktér by si mohl vytvořit vlastní profil služby Front Door a směrovat ho na vaši zdrojovou IP adresu, čímž by obešel vaše pravidla WAF.

X-Azure-FDID ověřování hlaviček (aplikační vrstva)

Každý požadavek ze služby Front Door obsahuje hlavičku X-Azure-FDID obsahující jedinečný identifikátor (GUID) instance služby Front Door, která požadavek odeslala. Ověřte tuto hlavičku v aplikaci nebo v reverzní proxy, abyste potvrdili, že požadavek přišel z vašeho profilu Front Door, a ne od útočníka:

1. Id služby Front Door najdete na portálu Azure na stránce Přehled profilu služby Front Door (pole ID služby Front Door).
2. V konfiguraci kódu aplikace nebo webového serveru zamítněte všechny požadavky, u kterých X-Azure-FDID neodpovídá očekávanému identifikátoru GUID.
3. Vrátí http 403 pro požadavky s chybějící nebo nesprávnou hodnotou hlavičky.

Kombinace značky služby (blokuje provoz, který nepřichází přes Front Door, na úrovni sítě) s ověřováním hlaviček (blokuje provoz z instancí Front Door jiných zákazníků na úrovni aplikace) zajišťuje, že k vašemu zdroji může přistupovat pouze vaše instance služby Front Door.

Zdroje Private Link (nejpřísnější uzamčení)

Pro úlohy vyžadující nejvyšší úroveň izolace původu podporuje Front Door Premium Private Link původu. Váš původ nepotřebuje žádnou veřejnou IP adresu. Front Door se připojuje prostřednictvím privátního koncového bodu přes páteřní síť Microsoftu. Tento přístup eliminuje potřebu pravidel značek služeb nebo ověřování hlaviček, protože původ je zcela nedostupný z veřejného internetu.

Související články

• Návrh virtuální sítě a podsítí: Určení velikosti podsítě pro službu Application Gateway a Load Balancer back-endy
• Skupiny zabezpečení sítě a skupiny zabezpečení aplikací: Pravidla NSG pro omezení přístupu k back-endu po příchozím provozu
• Doručování a výkon aplikace: Ladění výkonu po vytvoření cesty příchozího přenosu dat
• Odchozí přístup k internetu: Řízení odchozího provozu, odchozí protějšek příchozího provozu
• Zabezpečený administrativní přístup: Způsoby administrativního přístupu, odlišné od příchozího internetového provozu pro uživatele aplikace
• Firewall webových aplikací: Podrobná konfigurace WAF a ladění pravidel
• Ochrana před útoky DDoS pro vaši síť: Plánování ochrany před útoky DDoS pro všechny veřejné prostředky

Další informace

• Co je Azure Load Balancer?
• Co je Azure Application Gateway?
• Co je Azure Front Door?
• Co je Azure Traffic Manager?
• Veřejné IP adresy v Azure
• Azure Web Application Firewall ve službě Application Gateway
• Přehled služby Azure DDoS Network Protection

Další kroky

Tip

Prozkoumáváte to sami? Vraťte se do navigátoru přehledu a vyhledejte další článek podle možností.

V dalším kroku na cestě metodou "lift and shift":

Doručování a výkon aplikací: Přidejte vyrovnávání zatížení vrstvy 7 a globální doručování pro migrované úlohy.

Pokud zvednutá úloha nepotřebuje vyrovnávání zatížení vrstvy 7, přeskočte k odchozímu přístupu k internetu.

Další na cestě k modernizaci:

Doručování a výkon aplikací: Optimalizujte globální doručování a výkon pro úlohy PaaS, které jsou určené pro zákazníky.

Dále na vaší cestě mezi cloudy:

Firewall webových aplikací: Chraňte veřejně přístupné aplikace před útoky na vrstvě HTTP v celém vašem cloudovém prostředí.

Pokud vaše úloha nepoužívá PROTOKOL HTTP/HTTPS, přeskočte k Azure Firewall a kontrole provozu.