Sdílet prostřednictvím

Sítě a možnosti připojení pro klíčové úlohy v Azure

  • Článek

Sítě jsou základní oblastí pro kritickou aplikaci vzhledem k doporučenému globálně distribuovanému přístupu k návrhu typu aktivní-aktivní.

Tato oblast návrhu zkoumá různá témata topologie sítě na úrovni aplikace s ohledem na požadované připojení a redundantní správu provozu. Konkrétněji zdůrazňuje důležité aspekty a doporučení, která mají informovat návrh zabezpečené a škálovatelné globální síťové topologie pro nepostradatelnou aplikaci.

Důležité

Tento článek je součástí řady úloh, která je důležitá pro architekturu Azure. Pokud tuto řadu neznáte, doporučujeme začít tím , co je kritická úloha?

Globální směrování provozu

Použití několika razítek aktivního místního nasazení vyžaduje globální směrovací službu k distribuci provozu do každého aktivního razítka.

Azure Front Door, Azure Traffic Manager a Azure Standard Load Balancer poskytují potřebné možnosti směrování ke správě globálního provozu napříč více oblastmi aplikace.

Alternativně je možné zvážit technologie globálního směrování třetích stran. Tyto možnosti je možné téměř bezproblémově vyměnit za účelem nahrazení nebo rozšíření používání globálních směrovacích služeb nativních pro Azure. Mezi oblíbené volby patří technologie směrování od poskytovatelů CDN.

V této části se seznámíte s klíčovými rozdíly mezi službami směrování Azure a definujete, jak je možné jednotlivé služby použít k optimalizaci různých scénářů.

Aspekty návrhu

  • Směrovací služba vázaná na jednu oblast představuje kritický bod selhání a významné riziko týkající se oblastních výpadků.

  • Pokud úloha aplikace zahrnuje řízení klienta, například u mobilních nebo desktopových klientských aplikací, je možné zajistit redundanci služeb v rámci logiky směrování klientů.

    • Několik globálních technologií směrování, jako je Azure Front Door a Azure Traffic Manager, se dá paralelně zvážit kvůli redundanci a klienti nakonfigurovaní tak, aby převzali služby při selhání alternativní technologií, pokud jsou splněny určité podmínky selhání. Zavedení několika globálních směrovacích služeb představuje významné složitosti týkající se ukládání do mezipaměti edge a funkcí firewallu webových aplikací a správy certifikátů pro přesměrování zpracování SSL a ověřování aplikací pro cesty příchozího přenosu dat.
    • Je také možné zvážit technologie třetích stran, které poskytují odolnost globálního směrování pro všechny úrovně selhání platformy Azure.

  • Rozdíly schopností mezi službou Azure Front Door a Traffic Managerem znamenají, že pokud jsou tyto dvě technologie umístěny vedle sebe pro redundanci, bude potřeba provést jinou cestu příchozího přenosu dat nebo změny návrhu, aby se zajistila konzistentní a přijatelná úroveň služby.

  • Azure Front Door a Azure Traffic Manager jsou globálně distribuované služby s integrovanou redundancí a dostupností ve více oblastech.

    • Hypotetické scénáře selhání dostatečně velkého rozsahu, aby ohrožovaly globální dostupnost těchto odolných směrovacích služeb, představují širší riziko pro aplikaci z hlediska kaskádových a korelovaných selhání.
      • Scénáře selhání tohoto škálování jsou možné pouze kvůli sdíleným základním službám, jako je Azure DNS nebo Microsoft Entra ID, které slouží jako závislosti globální platformy pro téměř všechny služby Azure. Pokud se použije redundantní technologie Azure, je pravděpodobné, že sekundární služba bude mít také nedostupnost nebo degradovanou službu.
      • Scénáře selhání globální služby směrování výrazně ovlivňují mnoho dalších služeb používaných pro klíčové komponenty aplikací prostřednictvím závislostí mezi službami. I když se použije technologie třetí strany, bude aplikace pravděpodobně ve špatném stavu kvůli širšímu dopadu základního problému, což znamená, že směrování na koncové body aplikace v Azure přesto poskytuje malou hodnotu.

  • Redundance globální služby směrování poskytuje omezení pro extrémně malý počet hypotetických scénářů selhání, kdy dopad globálního výpadku je omezený na samotnou směrovací službu.

    Pokud chcete poskytnout širší redundanci pro globální scénáře výpadků, je možné zvážit přístup k nasazení typu aktivní-aktivní s více cloudy. Přístup k nasazení s více cloudy aktivní-aktivní představuje významné provozní složitosti, které představují významná rizika odolnosti, což pravděpodobně výrazně převáží hypotetická rizika globálního výpadku.

  • V situacích, kdy není možné řízení klienta, musí být závislost přijata v jedné globální směrovací službě, aby poskytovala jednotný vstupní bod pro všechny aktivní oblasti nasazení.

    • Při použití v izolaci představují kritický bod selhání na úrovni služby kvůli globálním závislostem, i když jsou k dispozici integrovaná redundance a dostupnost ve více oblastech.
    • Smlouva SLA poskytovaná vybranou globální službou směrování představuje maximální dosažitelný složený cíl úrovně služeb bez ohledu na to, kolik oblastí nasazení se považuje za.

  • Pokud řízení klienta není možné, je možné zvážit omezení provozu a definovat proces migrace do sekundární globální směrovací služby, pokud globální výpadek zakáže primární službu. Migrace z jedné globální směrovací služby na jinou je obvykle zdlouhavý proces trvající několik hodin, zejména v případě, že se považuje šíření DNS.

  • Některé globální směrovací služby třetích stran poskytují smlouvu SLA o 100 %. Historická a dosažitelná smlouva SLA poskytovaná těmito službami je však obvykle nižší než 100 %.

    • I když tyto služby poskytují finanční reparace pro nedostupnost, má malý význam, pokud je dopad nedostupnosti významný, například při bezpečnostních kritických scénářích, kdy je lidský život v konečném důsledku v sázce. Technologická redundance nebo dostatečná provozní zmírnění rizik by proto měla být stále považována i v případě, že inzerovaná právní smlouva SLA je 100 %.

Azure Front Door

  • Azure Front Door poskytuje globální vyrovnávání zatížení HTTP/S a optimalizované připojení pomocí protokolu Anycast s rozděleným protokolem TCP, abyste mohli využívat globální páteřní síť Microsoftu.

    • Pro každý z back-endových koncových bodů se udržuje řada připojení.
    • Příchozí požadavky klientů se nejprve ukončí na hraničním uzlu, který je nejblíže původnímu klientovi.
    • Po jakékoli požadované kontrole provozu se požadavky buď přes páteřní síť Microsoftu přesměrují na příslušný back-end pomocí existujících připojení, nebo se obsluhují z interní mezipaměti hraničního uzlu.
    • Tento přístup je efektivní při šíření velkých objemů provozu přes back-endová připojení.

  • Poskytuje integrovanou mezipaměť, která obsluhuje statický obsah z hraničních uzlů. V mnoha případech použití to může také eliminovat potřebu vyhrazené sítě pro doručování obsahu (CDN).

  • Firewall webových aplikací Azure (WAF) je možné použít ve službě Azure Front Door a protože je nasazený do hraničních umístění sítě Azure po celém světě, všechny příchozí požadavky doručované službou Front Door kontrolované na hraničních zařízeních sítě.

  • Azure Front Door chrání koncové body aplikací před útoky DDoS pomocí služby Azure DDoS Protection Basic. Azure DDoS Standard poskytuje další a pokročilejší možnosti ochrany a detekce a lze je přidat jako další vrstvu do služby Azure Front Door.

  • Azure Front Door nabízí plně spravovanou službu certifikátů. Umožňuje zabezpečení připojení TLS pro koncové body bez nutnosti spravovat životní cyklus certifikátu.

  • Azure Front Door Premium podporuje privátní koncové body, které umožňují tok provozu z internetu přímo do virtuálních sítí Azure. Tím by se eliminovala potřeba použití veřejných IP adres ve virtuální síti pro zpřístupnění back-endů přes Azure Front Door Premium.

  • Azure Front Door spoléhá na sondy stavu a koncové body stavu back-endu (adresy URL), které se volají v intervalu, aby vrátil stavový kód HTTP, který odráží, pokud back-end funguje normálně, s odpovědí HTTP 200 (OK) odrážející stav v pořádku. Jakmile back-end odráží stav, který není v pořádku, z pohledu určitého hraničního uzlu přestane posílat požadavky tam. Back-endy, které nejsou v pořádku, se proto transparentně odeberou z oběhu provozu bez jakéhokoli zpoždění.

  • Podporuje pouze protokoly HTTP/S.

  • WaF služby Azure Front Door a WAF služby Application Gateway poskytují mírně odlišnou sadu funkcí, i když podporují předdefinovaná i vlastní pravidla a dají se nastavit tak, aby fungovaly v režimu detekce nebo v režimu prevence.

  • Prostor back-endových IP adres služby Front Door se může změnit, ale Microsoft zajistí integraci s rozsahy IP adres Azure a značkami služeb. Můžete se přihlásit k odběru rozsahů IP adres Azure a značek služeb, abyste dostávali oznámení o jakýchkoli změnách nebo aktualizacích.

  • Azure Front Door podporuje různé konfigurace distribuce zatížení:

    • Na základě latence: výchozí nastavení, které směruje provoz do back-endu "nejbližšího" z klienta; na základě latence požadavku.
    • Na základě priority: užitečné pro nastavení aktivní-pasivní, kde se provoz musí vždy odesílat do primárního back-endu, pokud není dostupný.
    • Vážené: platí pro kanárná nasazení, ve kterých se určité procento provozu odesílá do konkrétního back-endu. Pokud je přiřazeno více back-endů se stejnou váhou, použije se směrování na základě latence.

  • Ve výchozím nastavení Azure Front Door používá směrování založené na latenci, které může vést k situacím, kdy některé back-endy získávají mnohem více příchozího provozu než ostatní v závislosti na tom, odkud klienti pocházejí.

  • Pokud musí být řada požadavků klientů zpracována stejným back-endem, je možné na front-endu nakonfigurovat spřažení relací. Používá soubor cookie na straně klienta k odesílání následných požadavků do stejného back-endu jako první požadavek za předpokladu, že back-end je stále dostupný.

Azure Traffic Manager

  • Azure Traffic Manager je služba přesměrování DNS.

    • Skutečná datová část požadavku není zpracována, ale Traffic Manager vrátí název DNS jednoho z back-endů, které fond na základě nakonfigurovaných pravidel pro vybranou metodu směrování provozu.
    • Název DNS back-endu se pak přeloží na konečnou IP adresu, která je následně volána přímo klientem.

  • Odpověď DNS se uloží do mezipaměti a znovu použije klient pro zadané období TTL (Time-To Live) a požadavky provedené během tohoto období budou přímo do back-endového koncového bodu bez interakce Traffic Manageru. Eliminuje dodatečný krok připojení, který ve srovnání se službou Front Door poskytuje nákladové výhody.

  • Vzhledem k tomu, že požadavek se provádí přímo z klienta do back-endové služby, je možné využít jakýkoli protokol podporovaný back-endem.

  • Podobně jako služba Azure Front Door spoléhá Azure Traffic Manager také na sondy stavu, aby bylo jasné, jestli je back-end v pořádku a funguje normálně. Pokud se vrátí jiná hodnota nebo se nic nevrátí, služba směrování rozpozná probíhající problémy a zastaví směrování požadavků na tento konkrétní back-end.

    • Na rozdíl od služby Azure Front Door ale není okamžité odebrání back-endů, které nejsou v pořádku, protože klienti budou nadále vytvářet připojení k back-endu, který není v pořádku, dokud nevyprší platnost hodnoty TTL DNS a ze služby Traffic Manager se vyžádá nový koncový bod back-endu.
    • Kromě toho, i když platnost hodnoty TTL vyprší, neexistuje žádná záruka, že veřejné servery DNS tuto hodnotu budou respektovat, takže šíření DNS může ve skutečnosti trvat mnohem déle. To znamená, že provoz se může dál posílat do koncového bodu, který není v pořádku, po dlouhou dobu.

Azure Standard Load Balancer

Důležité

Load Balancer úrovně Standard napříč oblastmi je k dispozici ve verzi Preview s technickými omezeními. Tato možnost se nedoporučuje pro klíčové úlohy.

Doporučení k návrhu

  • Azure Front Door použijte jako primární globální službu směrování provozu pro scénáře HTTP/S. Azure Front Door se důrazně doporučuje pro úlohy HTTP/S, protože poskytuje optimalizované směrování provozu, transparentní převzetí služeb při selhání, privátní back-endové koncové body (s skladovou položku Premium), ukládání do mezipaměti edge a integraci se službou Firewall webových aplikací (WAF).

  • V případě scénářů aplikace, kde je možné řízení klienta, použijte logiku směrování na straně klienta, abyste zvážili scénáře převzetí služeb při selhání, kdy primární globální směrovací technologie selže. Dvě nebo více globálních technologií směrování by se měly umístit paralelně pro přidání redundance, pokud smlouva SLA s jednou službou nestačí. Logika klienta se vyžaduje pro směrování do redundantní technologie v případě globálního selhání služby.

    • Měly by se použít dvě odlišné adresy URL, přičemž jedna se použije pro každou z různých globálních směrovacích služeb, aby se zjednodušilo celkové prostředí správy certifikátů a logika směrování pro převzetí služeb při selhání.
    • Upřednostněte použití technologií směrování třetích stran jako sekundární služby převzetí služeb při selhání, protože tím se zmírní největší počet scénářů globálního selhání a možnosti nabízené předními poskytovateli CDN budou umožňovat konzistentní přístup k návrhu.
    • Je třeba vzít v úvahu také přímé směrování do jednoho regionálního razítka místo samostatné směrovací služby. I když to bude mít za následek snížení úrovně služby, představuje mnohem jednodušší přístup k návrhu.

Tento obrázek ukazuje redundantní globální konfiguraci nástroje pro vyrovnávání zatížení s převzetím služeb při selhání klienta pomocí služby Azure Front Door jako primárního globálního nástroje pro vyrovnávání zatížení.

Konfigurace klíčového globálního nástroje pro vyrovnávání zatížení

Důležité

Aby bylo možné skutečně zmírnit riziko globálních selhání v rámci platformy Azure, je potřeba zvážit přístup k nasazení s více cloudovými aktivními nasazeními s razítky aktivního nasazení hostovanými ve dvou nebo více poskytovatelích cloudu a redundantními technologiemi směrování třetích stran, které se používají pro globální směrování.

Azure je možné efektivně integrovat s jinými cloudovými platformami. Důrazně se ale nedoporučuje používat přístup s více cloudy, protože představuje významnou provozní složitost s různými definicemi kolků nasazení a reprezentací provozního stavu napříč různými cloudovými platformami. Tato složitost přináší v rámci normálního provozu aplikace řadu rizik odolnosti, která výrazně převáží hypotetická rizika globálního výpadku platformy.

  • I když se nedoporučuje, pro úlohy HTTP, které používají Azure Traffic Manager pro globální redundanci směrování do služby Azure Front Door, zvažte přesměrování zátěže firewallu webových aplikací (WAF) do služby Application Gateway, aby se přijatelný provoz procházel přes Azure Front Door.
    • Tím se zavede další bod selhání na standardní cestu příchozího přenosu dat, další komponentu kritické cesty ke správě a škálování a také se účtují další náklady, které zajistí globální vysokou dostupnost. Výrazně ale zjednoduší scénář selhání tím, že zajistí konzistenci mezi přijatelnými a neakceptovatelnými cestami příchozího přenosu dat prostřednictvím služby Azure Front Door a Azure Traffic Manageru, a to jak z hlediska provádění WAF, tak i koncových bodů privátních aplikací.
    • Ztráta ukládání do mezipaměti edge ve scénáři selhání bude mít vliv na celkový výkon a to musí být v souladu s přijatelnou úrovní služeb nebo zmírněním přístupu k návrhu. Pokud chcete zajistit konzistentní úroveň služby, zvažte přesměrování ukládání do mezipaměti edge na poskytovatele CDN třetí strany pro obě cesty.

Doporučujeme zvážit globální směrovací službu třetí strany místo dvou globálních směrovacích služeb Azure. To poskytuje maximální úroveň zmírnění chyb a jednodušší přístup k návrhu, protože většina špičkových poskytovatelů CDN nabízí možnosti hraničních zařízení z velké části konzistentní s možnostmi nabízenými službou Azure Front Door.

Azure Front Door

  • Pomocí spravované certifikační služby Azure Front Door povolte připojení TLS a odeberte nutnost spravovat životní cyklus certifikátů.

  • Pomocí firewallu webových aplikací Služby Azure Front Door (WAF) můžete poskytnout ochranu na hraničních zařízeních před běžnými webovými zneužitími a ohroženími zabezpečení, jako je injektáž SQL.

  • K poskytování statického obsahu z hraničních uzlů použijte integrovanou mezipaměť služby Azure Front Door.

    • Ve většině případů se tím také eliminuje potřeba vyhrazené sítě pro doručování obsahu (CDN).

  • Nakonfigurujte body příchozího přenosu dat aplikační platformy tak, aby ověřovaly příchozí požadavky prostřednictvím filtrování na základě hlaviček pomocí X-Azure-FDID , aby se zajistilo, že veškerý provoz prochází přes nakonfigurovanou instanci služby Front Door. Zvažte také konfiguraci ACLLing PROTOKOLU IP pomocí značek služby Front Door k ověření provozu pocházejícího z back-endového adresního prostoru IP služby Azure Front Door a služeb infrastruktury Azure. Tím zajistíte, že provoz prochází službou Azure Front Door na úrovni služby, ale filtrování na základě hlaviček se bude dál vyžadovat, aby se zajistilo použití nakonfigurované instance služby Front Door.

  • Definujte vlastní koncový bod stavu PROTOKOLU TCP, který ověří kritické podřízené závislosti v rámci razítka místního nasazení, včetně replik datové platformy, jako je Azure Cosmos DB v příkladu poskytnutém základní referenční implementací. Pokud jedna nebo více závislostí není v pořádku, sonda stavu by to měla odrážet ve vrácené odpovědi, aby bylo možné z oběhu vyčíst celé regionální razítko.

  • Zajistěte, aby se odpovědi sondy stavu protokolovaly a ingestovaly všechna provozní data vystavená službou Azure Front Door do globálního pracovního prostoru služby Log Analytics, aby se usnadnilo jednotné jímky dat a jediné provozní zobrazení v celé aplikaci.

  • Pokud není úloha extrémně citlivá na latenci, rozložte provoz rovnoměrně napříč všemi považovaným za regionální razítka, aby bylo možné efektivně používat nasazené prostředky.

    • Abyste toho dosáhli, nastavte parametr Latency Sensitivity (Additional Latency) na hodnotu, která je dostatečně vysoká, aby vyhovovala rozdílům latence mezi různými oblastmi back-endů. Ujistěte se, že je tolerance přijatelná pro úlohu aplikace týkající se celkové latence požadavků klienta.

  • Nepovolujte spřažení relace, pokud to aplikace nevyžaduje, protože může mít negativní dopad na rovnováhu distribuce provozu. Pokud se použije plně bezstavová aplikace, bude-li následovat doporučený přístup k návrhu klíčové aplikace, může být jakýkoli požadavek zpracován některým z regionálních nasazení.

Azure Traffic Manager

  • Traffic Manager použijte pro jiné scénáře než HTTP/S jako náhradu za Azure Front Door. Rozdíly v možnostech schopností budou řídit různá rozhodnutí o návrhu pro možnosti mezipaměti a WAF a správu certifikátů TLS.

  • Funkce WAF by se měly zvážit v rámci každé oblasti pro cestu příchozího přenosu dat Traffic Manageru pomocí brány Aplikace Azure lication Gateway.

  • Nakonfigurujte vhodnou nízkou hodnotu TTL pro optimalizaci času potřebného k odebrání špatného back-endového koncového bodu z oběhu v případě, že back-end není v pořádku.

  • Podobně jako u služby Azure Front Door by se měl definovat vlastní koncový bod stavu PROTOKOLU TCP, který ověří kritické podřízené závislosti v rámci razítka místního nasazení, které by se měly promítnout do odpovědi poskytované koncovými body stavu.

    Pro další aspekty traffic Manageru byste ale měli vzít v úvahu regionální převzetí služeb při selhání na úrovni služeb. pokud chcete zmírnit potenciální zpoždění spojené s odebráním back-endu, který není v pořádku kvůli selhání závislostí, zejména pokud není možné nastavit nízkou hodnotu TTL pro záznamy DNS.

  • Je třeba vzít v úvahu poskytovatele CDN třetích stran, aby bylo možné dosáhnout ukládání do mezipaměti hraničních zařízení při použití Azure Traffic Manageru jako primární globální směrovací služby. Pokud jsou hraniční funkce WAF nabízeny také službou třetí strany, je třeba vzít v úvahu zjednodušení cesty příchozího přenosu dat a potenciálně odebrat potřebu služby Application Gateway.

Služby doručování aplikací

Cesta příchozího přenosu dat sítě pro kritickou aplikaci musí také zvážit služby doručování aplikací, aby se zajistil zabezpečený, spolehlivý a škálovatelný provoz příchozího přenosu dat.

Tato část vychází z doporučení globálního směrování prozkoumáním klíčových možností doručování aplikací s ohledem na relevantní služby, jako je Azure Standard Load Balancer, Aplikace Azure lication Gateway a Azure API Management.

Aspekty návrhu

  • Šifrování TLS je důležité k zajištění integrity příchozího provozu uživatelů do klíčové aplikace s použitím přesměrování zpracování TLS pouze v okamžiku příchozího přenosu dat razítka k dešifrování příchozího provozu. Přesměrování zpracování PROTOKOLU TLS vyžaduje privátní klíč certifikátu TLS k dešifrování provozu.

  • Firewall webových aplikací poskytuje ochranu před běžnými webovými zneužitími a ohroženími zabezpečení, jako je injektáž SQL nebo skriptování mezi weby, a je nezbytné k dosažení maximální spolehlivosti spolehlivosti klíčové aplikace.

  • Azure WAF poskytuje ochranu před 10 hlavními ohroženími zabezpečení OWASP pomocí sad spravovaných pravidel.

    • Vlastní pravidla je možné přidat také k rozšíření sady spravovaných pravidel.
    • Azure WAF je možné povolit v rámci služby Azure Front Door, Aplikace Azure lication Gateway nebo Azure CDN (aktuálně ve verzi Public Preview).
      • Funkce nabízené na jednotlivých službách se mírně liší. Azure Front Door WAF například poskytuje omezení rychlosti, geografické filtrování a ochranu robotů, které ještě nejsou nabízeny v rámci WAF služby Application Gateway. Všechny však podporují předdefinovaná i vlastní pravidla a dají se nastavit tak, aby fungovaly v režimu detekce nebo v režimu prevence.
      • Plán pro Azure WAF zajistí, aby byla zajištěna konzistentní sada funkcí WAF napříč všemi integracemi služeb.

  • Technologie WAF třetích stran, jako jsou síťové virtuální zařízení a pokročilé kontrolery příchozího přenosu dat v rámci Kubernetes, se také dají považovat za účelem zajištění požadované ochrany před ohrožením zabezpečení.

  • Optimální konfigurace WAF obvykle vyžaduje jemné ladění bez ohledu na použitou technologii.

    Azure Front Door

  • Azure Front Door přijímá pouze provoz HTTP a HTTPS a bude zpracovávat pouze požadavky se známou Host hlavičkou. Toto blokování protokolu pomáhá zmírnit multilicenční útoky rozložené mezi protokoly a porty a amplifikace DNS a útoky na otravu TCP.

  • Azure Front Door je globální prostředek Azure, takže konfigurace se nasadí globálně do všech hraničních umístění.

    • Konfiguraci prostředků je možné distribuovat v masivním měřítku, aby bylo možné zpracovat stovky tisíc požadavků za sekundu.
    • Aktualizace konfigurace, včetně tras a back-endových fondů, jsou bezproblémové a během nasazování nezpůsobí žádné výpadky.

  • Azure Front Door poskytuje plně spravovanou službu certifikátů i metodu bring-your-own-certificate pro certifikáty SSL určené pro klienty. Plně spravovaná certifikační služba poskytuje zjednodušený provozní přístup a pomáhá snížit složitost celkového návrhu provedením správy certifikátů v rámci jedné oblasti řešení.

  • Služba Azure Front Door automaticky obměňuje spravované certifikáty nejméně 60 dnů před vypršením platnosti certifikátu, aby se chránily před riziky certifikátů, jejichž platnost vypršela. Pokud se používají certifikáty spravované svým držitelem, měly by se aktualizované certifikáty nasadit nejpozději do 24 hodin před vypršením platnosti stávajícího certifikátu, jinak mohou klienti obdržet chyby certifikátu s vypršenou platností.

  • Aktualizace certifikátů způsobí výpadek jenom v případě, že se služba Azure Front Door přepne mezi spravovanými a vlastními certifikáty.

  • Služba Azure Front Door je chráněná službou Azure DDoS Protection Basic, která je ve výchozím nastavení integrovaná do služby Front Door. To poskytuje nepřetržité monitorování provozu, zmírnění rizik v reálném čase a také ochranu před běžnými útoky dns vrstvy 7 nebo útoky vrstvy 3/4.

    • Tyto ochrany pomáhají udržovat dostupnost služby Azure Front Door i v případě útoku DDoS. Útoky DDoS (Distributed Denial of Service) můžou způsobit nedostupný cílový prostředek tím, že ho zahlcují nelegitimním provozem.

  • Azure Front Door také poskytuje funkce WAF na globální úrovni provozu, zatímco WAF služby Application Gateway musí být k dispozici v rámci každého místního razítka nasazení. Mezi možnosti patří sady pravidel brány firewall, které chrání před běžnými útoky, geografickým filtrováním, blokováním adres, omezováním rychlosti a porovnáváním podpisů.

    Azure Load Balancer

  • Skladová položka Azure Basic Load Balanceru není zajištěná smlouvou SLA a má v porovnání se skladovou jednotkou Standard několik omezení schopností.

Doporučení k návrhu

  • Pokud chcete zachovat zabezpečení a zároveň zjednodušit životní cyklus správy certifikátů, proveďte snižování zátěže protokolu TLS na co několika místech.

  • Používejte šifrovaná připojení (např. HTTPS) z místa, kde dochází k přesměrování zpracování PROTOKOLU TLS do skutečných back-endů aplikace. Koncové body aplikací nebudou viditelné koncovým uživatelům, takže domény spravované v Azure, jako azurewebsites.net jsou nebo cloudapp.net, se dají používat se spravovanými certifikáty.

  • U přenosů http(S) se ujistěte, že jsou možnosti WAF použity v rámci cesty příchozího přenosu dat pro všechny veřejně zveřejněné koncové body.

  • Povolte funkce WAF v jednom umístění služby, ať už globálně pomocí služby Azure Front Door, nebo v místním prostředí s Aplikace Azure lication Gateway, protože to zjednodušuje vyladění konfigurace a optimalizuje výkon a náklady.

    Nakonfigurujte WAF v režimu prevence pro přímé blokování útoků. WaF používejte pouze v režimu detekce (tj. protokolování, ale neblokuje podezřelé požadavky), pokud je výkon režimu prevence příliš vysoký. Předpokládané další riziko musí být plně srozumitelné a v souladu s konkrétními požadavky scénáře úlohy.

  • Upřednostněte použití WAF služby Azure Front Door, protože poskytuje nejbohatší sadu funkcí nativní pro Azure a používá ochranu na globálním hraničním zařízení, což zjednodušuje celkový návrh a zvyšuje efektivitu.

  • Azure API Management používejte jenom při vystavení velkého počtu rozhraní API externím klientům nebo různým aplikačním týmům.

  • Skladovou položku Azure Standard Load Balancer použijte pro všechny scénáře interní distribuce provozu v rámci úloh mikros-service.

    • Poskytuje smlouvu SLA 99,99 % při nasazení napříč Zóny dostupnosti.
    • Poskytuje důležité funkce, jako jsou diagnostika nebo pravidla odchozích přenosů.

  • Azure DDoS Network Protection vám pomůže chránit veřejné koncové body hostované v rámci každé virtuální sítě aplikace.

Ukládání do mezipaměti a doručování statického obsahu

Zvláštní zacházení se statickým obsahem, jako jsou obrázky, JavaScript, CSS a další soubory, můžou mít významný dopad na celkové uživatelské prostředí a také na celkové náklady na řešení. Ukládání statického obsahu do mezipaměti na hraničních zařízeních může urychlit dobu načítání klienta, což vede k lepšímu uživatelskému prostředí a může také snížit náklady na provoz, operace čtení a výpočetní výkon v back-endových službách.

Aspekty návrhu

  • Ne veškerý obsah, který řešení zpřístupňuje přes internet, se generuje dynamicky. Aplikace obsluhují statické prostředky (obrázky, JavaScript, CSS, lokalizační soubory atd.) i dynamický obsah.
  • Úlohy s často používaným statickým obsahem výrazně využívají ukládání do mezipaměti, protože snižuje zatížení back-endových služeb a snižuje latenci přístupu k obsahu pro koncové uživatele.
  • Ukládání do mezipaměti je možné nativně implementovat v Rámci Azure pomocí služby Azure Front Door nebo Azure Content Delivery Network (CDN).
    • Azure Front Door poskytuje funkce ukládání do mezipaměti nativních pro Azure a směrování, které umožňují dělit statický a dynamický obsah.
      • Vytvořením odpovídajících pravidel směrování ve službě Azure Front Door /static/* je možné transparentně přesměrovat provoz na statický obsah.
    • Složitější scénáře ukládání do mezipaměti je možné implementovat pomocí služby Azure CDN k vytvoření plnohodnotné sítě pro doručování obsahu pro významné objemy statického obsahu.
      • Služba Azure CDN bude pravděpodobně nákladově efektivnější, ale neposkytuje stejné pokročilé možnosti směrování a firewallu webových aplikací (WAF), které se doporučují pro jiné oblasti návrhu aplikace. Nabízí ale větší flexibilitu integrace s podobnými službami z řešení třetích stran, jako jsou Akamai a Verizon.
    • Při porovnávání služeb Azure Front Door a Azure CDN je potřeba prozkoumat následující rozhodovací faktory:
      • Je možné provést pravidla ukládání do mezipaměti pomocí stroje pravidel.
      • Velikost uloženého obsahu a přidružených nákladů
      • Cena za měsíc při provádění modulu pravidel (naúčtovaná za požadavek ve službě Azure Front Door)
      • Odchozí požadavky na provoz (cena se liší podle cíle).

Doporučení k návrhu

  • Vygenerovaný statický obsah, jako jsou kopie velikostí souborů obrázků, které se nikdy nebo jen zřídka mění, můžou také těžit z ukládání do mezipaměti. Ukládání do mezipaměti se dá nakonfigurovat na základě parametrů adresy URL a s různou dobou ukládání do mezipaměti.
  • Oddělte doručování statického a dynamického obsahu uživatelům a doručujte relevantní obsah od mezipaměti, abyste snížili zatížení back-endových služeb a optimalizovali výkon pro koncové uživatele.
  • Vzhledem k silnému doporučení (oblast návrhu sítě a připojení ) k používání služby Azure Front Door pro účely globálního směrování a firewallu webových aplikací (WAF) se doporučuje určit prioritu použití funkcí ukládání do mezipaměti služby Azure Front Door, pokud neexistují mezery.

Integrace virtuální sítě

Nepostradatelná aplikace obvykle zahrnuje požadavky na integraci s jinými aplikacemi nebo závislými systémy, které by mohly být hostovány v Azure, jiném veřejném cloudu nebo místních datových centrech. Tuto integraci aplikace je možné provést pomocí veřejných koncových bodů a internetu nebo privátních sítí prostřednictvím integrace na úrovni sítě. V konečném důsledku bude mít metoda, pomocí které se integrace aplikace dosáhne, významný dopad na zabezpečení, výkon a spolehlivost řešení a výrazně ovlivní rozhodnutí o návrhu v jiných oblastech návrhu.

Nepostradatelnou aplikaci je možné nasadit v rámci jedné ze tří konfigurací sítě, která určuje, jak může integrace aplikací na úrovni sítě nastat.

  1. Veřejná aplikace bez připojení k podnikové síti
  2. Veřejná aplikace s připojením k podnikové síti
  3. Privátní aplikace s připojením k podnikové síti

Upozornění

Při nasazování v cílové zóně Azure konfigurace 1. měla by být nasazena v rámci online cílové zóny, zatímco 2) i 3) by měly být nasazeny v rámci corp. Propojená cílová zóna pro usnadnění integrace na úrovni sítě.

Tato část popisuje tyto scénáře integrace sítě, vrstvení v vhodném použití virtuálních sítí Azure a okolních síťových služeb Azure, aby se zajistilo optimální splnění požadavků na integraci.

Na co dát pozor při navrhování

Žádné virtuální sítě

  • Nejjednodušším přístupem k návrhu je nenasazovat aplikaci ve virtuální síti.

    • Připojení mezi všemi považovaými službami Azure bude poskytováno výhradně prostřednictvím veřejných koncových bodů a páteřní sítě Microsoft Azure. Připojení mezi veřejnými koncovými body hostovanými v Azure prochází pouze páteřní sítí Microsoftu a nebude procházet přes veřejný internet.
    • Připojení k jakýmkoli externím systémům mimo Azure bude poskytováno veřejným internetem.

  • Tento přístup návrhu přijímá identitu jako hraniční síť zabezpečení, aby poskytoval řízení přístupu mezi různými komponentami služby a závislým řešením. To může být přijatelné řešení pro scénáře, které jsou méně citlivé na zabezpečení. Všechny aplikační služby a závislosti jsou přístupné prostřednictvím veřejného koncového bodu, takže jsou zranitelné vůči dalším vektorům útoku orientovaným na získání neoprávněného přístupu.

  • Tento přístup k návrhu se také nevztahuje na všechny služby Azure, protože mnoho služeb, jako je AKS, má pevný požadavek na základní virtuální síť.

Izolované virtuální sítě

  • Pokud chcete zmírnit rizika spojená s nepotřebnými veřejnými koncovými body, je možné aplikaci nasadit v samostatné síti, která není připojená k jiným sítím.

  • Příchozí požadavky klientů budou nadále vyžadovat zveřejnění veřejného koncového bodu na internetu, ale veškerá následná komunikace může být ve virtuální síti pomocí privátních koncových bodů. Při použití Služby Azure Front Door Premium je možné směrovat přímo z hraničních uzlů do koncových bodů privátních aplikací.

  • I když dojde k privátnímu připojení mezi komponentami aplikace přes virtuální sítě, veškeré připojení k externím závislostem bude stále záviset na veřejných koncových bodech.

    • Připojení ke službám platformy Azure je možné navázat s privátními koncovými body v případě podpory. Pokud v Azure existují další externí závislosti, jako je jiná podřízená aplikace, bude připojení poskytováno prostřednictvím veřejných koncových bodů a páteřní sítě Microsoft Azure.
    • Připojení k jakýmkoli externím systémům mimo Azure by bylo poskytováno veřejným internetem.

  • V situacích, kdy neexistují žádné požadavky na integraci sítě pro externí závislosti, nasazení řešení v izolovaném síťovém prostředí poskytuje maximální flexibilitu návrhu. Žádná omezení adresování a směrování spojená s širší integrací sítě.

  • Azure Bastion je plně platforma spravovaná služba PaaS, která se dá nasadit ve virtuální síti a poskytuje zabezpečené připojení RDP/SSH k virtuálním počítačům Azure. Když se připojíte přes Azure Bastion, virtuální počítače nepotřebují veřejnou IP adresu.

  • Použití aplikačních virtuálních sítí představuje významné složitosti nasazení v kanálech CI/CD, protože k usnadnění nasazení aplikací se vyžaduje přístup roviny dat i řídicí roviny k prostředkům hostovaným v privátních sítích.

    • Aby nástroje CI/CD mohly provádět požadované akce, musí být navázána zabezpečená cesta k privátní síti.
    • Agenty privátního sestavení je možné nasadit v rámci virtuálních sítí aplikací pro přístup k prostředkům zabezpečeným virtuální sítí.

Připojené virtuální sítě

  • V případě scénářů s požadavky na integraci externí sítě je možné virtuální sítě aplikací připojit k jiným virtuálním sítím v Rámci Azure, jinému poskytovateli cloudu nebo místním sítím s využitím různých možností připojení. Některé scénáře aplikací můžou například zvážit integraci na úrovni aplikace s jinými obchodními aplikacemi hostovanými soukromě v rámci místní podnikové sítě.

  • Návrh aplikační sítě musí odpovídat širší architektuře sítě, zejména pokud jde o témata, jako je adresování a směrování.

  • Překrývající se adresní prostory IP adres napříč oblastmi Azure nebo místními sítěmi vytvoří při zvažování integrace sítě hlavní kolize.

    • Prostředek virtuální sítě je možné aktualizovat, aby zvážil další adresní prostor, ale když adresní prostor virtuální sítě partnerské sítě změní synchronizaci propojení partnerského vztahu, což dočasně zakáže partnerský vztah.
    • Azure si v rámci každé podsítě vyhrazuje pět IP adres, které je potřeba zvážit při určování vhodných velikostí pro virtuální sítě aplikací a zahrnující podsítě.
    • Některé služby Azure vyžadují vyhrazené podsítě, jako je Azure Bastion, Azure Firewall nebo Brána virtuální sítě Azure. Velikost těchto podsítí služeb je velmi důležitá, protože by měly být dostatečně velké, aby podporovaly všechny aktuální instance služby s ohledem na budoucí požadavky na škálování, ale ne tak velké, aby zbytečně ztrácely adresy.

  • Když se vyžaduje místní nebo multicloudová integrace sítě, Azure nabízí dvě různá řešení pro vytvoření zabezpečeného připojení.

    • Okruh ExpressRoute může mít velikost, aby poskytoval šířku pásma až 100 Gb/s.
    • Virtuální privátní síť (VPN) může mít velikost tak, aby poskytovala agregovanou šířku pásma až 10 Gb/s v hvězdicových sítích a až 20 Gb/s ve službě Azure Virtual WAN.

Poznámka:

Při nasazování v cílové zóně Azure mějte na paměti, že implementace cílové zóny by měla poskytovat veškeré požadované připojení k místním sítím. Návrh může používat ExpressRoute a další virtuální sítě v Azure pomocí služby Virtual WAN nebo návrhu hvězdicové sítě.

  • Zahrnutí dalších síťových cest a prostředků přináší pro aplikaci další aspekty spolehlivosti a provozu, aby se zajistilo zachování stavu.

Doporučení k návrhu

  • Doporučuje se nasadit důležitá řešení v rámci virtuálních sítí Azure, pokud je to možné, abyste odebrali nepotřebné veřejné koncové body a omezili prostor pro útoky na aplikace, aby se maximalizovalo zabezpečení a spolehlivost.

    • Privátní koncové body slouží k připojení ke službám platformy Azure. Koncové body služby je možné zvážit pro služby, které nepodporují službu Private Link, za předpokladu, že rizika exfiltrace dat jsou přijatelná nebo zmírněná prostřednictvím alternativních ovládacích prvků.

  • Ve scénářích aplikací, které nevyžadují připojení k podnikové síti, zacházejte se všemi virtuálními sítěmi jako s dočasnými prostředky, které se nahradí při novém regionálním nasazení.

  • Při připojování k jiným sítím Azure nebo místním sítím by se virtuální sítě aplikací neměly považovat za dočasné, protože vytváří významné komplikace, kdy se jedná o partnerské vztahy virtuálních sítí a prostředky brány virtuální sítě. Všechny relevantní prostředky aplikace ve virtuální síti by měly být i nadále dočasné s paralelními podsítěmi používanými k usnadnění modrých nasazení aktualizovaných místních razítek nasazení.

  • Ve scénářích, kdy se k usnadnění integrace aplikací do privátních sítí vyžaduje připojení podnikové sítě, zajistěte, aby se adresní prostor IPv4 používaný pro místní aplikační virtuální sítě nepřekrýval s jinými připojenými sítěmi a je správně velký, aby usnadnil požadované škálování, aniž by bylo nutné aktualizovat prostředek virtuální sítě a dojít k výpadku.

    • Důrazně doporučujeme používat pouze IP adresy z přidělování adres pro privátní internet (RFC 1918).
      • Pro prostředí s omezenou dostupností privátních IP adres (RFC 1918) zvažte použití protokolu IPv6.
      • Pokud se vyžaduje použití veřejné IP adresy, ujistěte se, že se použijí jenom bloky vlastněných adres.
    • V souladu s plány organizace pro přidělování IP adres v Azure zajistěte, aby se adresní prostor IP adres aplikační sítě nepřekrývaly s jinými sítěmi v místních umístěních nebo oblastech Azure.
    • Nevytvářejte zbytečně velké virtuální sítě aplikací, aby se zajistilo, že adresní prostor IP adres není plýtvání.

  • Určete prioritu použití Azure CNI pro integraci sítě AKS, protože podporuje bohatší sadu funkcí.

    • Zvažte Kubenet pro scénáře s omezenou dostupnou IP adresou, aby se aplikace vešla do omezeného adresního prostoru.

    • Určete prioritu použití síťového plug-inu Azure CNI pro integraci sítě AKS a zvažte Kubenet pro scénáře s omezeným rozsahem dostupných IP adres. Další podrobnosti najdete v tématu Mikro segmentace a zásady sítě Kubernetes.

  • V případě scénářů vyžadujících integraci místní sítě upřednostňujte použití ExpressRoute, abyste zajistili zabezpečené a škálovatelné připojení.

    • Ujistěte se, že úroveň spolehlivosti použitá pro ExpressRoute nebo VPN plně splňuje požadavky na aplikace.
    • Pokud je to potřeba, měli byste zvážit více síťových cest, aby bylo možné zajistit dodatečnou redundanci, například mezi připojenými okruhy ExpressRoute nebo použití sítě VPN jako mechanismus připojení převzetí služeb při selhání.

  • Zajistěte, aby všechny komponenty na kritických síťových cestách byly v souladu se spolehlivostí a požadavky na dostupnost přidružených toků uživatelů bez ohledu na to, jestli je správa těchto cest a přidružených komponent poskytována aplikačním týmem centrálních IT týmů.

    Poznámka:

    Při nasazování v cílové zóně Azure a integraci s širší topologií sítě organizace zvažte pokyny k síti, abyste zajistili, že základní síť bude v souladu s osvědčenými postupy Microsoftu.

  • K přístupu k rovině dat prostředků Azure nebo provádění operací správy použijte privátní připojení Azure Bastion neboxiovaná privátní připojení.

Internetový výchozí přenos dat

Internetový výchozí přenos dat je základním požadavkem sítě pro nepostradatelnou aplikaci, která usnadňuje externí komunikaci v kontextu:

  1. Přímá interakce uživatele aplikace
  2. Integrace aplikací s externími závislostmi mimo Azure
  3. Přístup k externím závislostem vyžadovaným službami Azure, které aplikace používá.

V této části se dozvíte, jak lze dosáhnout výchozího internetového přenosu dat a zároveň zajistit zachování zabezpečení, spolehlivosti a udržitelného výkonu, a zdůrazňuje klíčové požadavky na výchozí přenos dat pro služby doporučené v klíčovém kontextu.

Na co dát pozor při navrhování

  • Mnoho služeb Azure vyžaduje přístup k veřejným koncovým bodům, aby různé funkce roviny správy a řídicí roviny fungovaly podle očekávání.

  • Azure poskytuje různé přímé metody odchozího připojení k internetu, jako je Azure NAT Gateway nebo Azure Load Balancer, pro virtuální počítače nebo výpočetní instance ve virtuální síti.

  • Když se provoz z virtuální sítě přesune do internetu, musí proběhnout překlad adres (NAT). Jedná se o výpočetní operaci, která se vyskytuje v rámci síťového zásobníku, a to může mít vliv na výkon systému.

  • Pokud se překlad adres (NAT) provádí v malém měřítku, dopad na výkon by měl být zanedbatelný, ale pokud může dojít k velkému počtu problémů se sítí odchozích požadavků. Tyto problémy obvykle mají podobu vyčerpání portů zdrojového překladu adres (NEBO SNAT).

  • V prostředí s více tenanty, jako je například služba Aplikace Azure, je pro každou instanci k dispozici omezený počet odchozích portů. Pokud tyto porty vyprší, není možné zahájit žádná nová odchozí připojení. Tento problém můžete zmírnit snížením počtu procházení privátních nebo veřejných hraničních zařízení nebo použitím škálovatelného řešení NAT, jako je Azure NAT Gateway.

  • Kromě omezení překladu adres (NAT) může odchozí provoz podléhat také požadovaným kontrolám zabezpečení.

    • Azure Firewall poskytuje vhodné možnosti zabezpečení pro zabezpečení výchozího přenosu dat sítě.

    • Azure Firewall (nebo ekvivalentní síťové virtuální zařízení) je možné použít k zabezpečení požadavků na výchozí přenos dat Kubernetes tím, že poskytuje podrobnou kontrolu nad odchozími toky provozu.

  • Za velké objemy odchozích přenosů dat se budou účtovat poplatky za přenos dat.

Azure NAT Gateway

  • Azure NAT Gateway podporuje 64 000 připojení pro TCP a UDP na přiřazenou odchozí IP adresu.

    • K jedné bráně NAT je možné přiřadit až 16 IP adres.
    • Výchozí časový limit nečinnosti PROTOKOLU TCP 4 minuty. Pokud se časový limit nečinnosti změní na vyšší hodnotu, budou se toky uchovávat déle, což zvýší tlak na inventář portů SNAT.

  • Služba NAT Gateway nemůže poskytovat zónovou izolaci. Pokud chcete získat zónovou redundanci, musí být podsíť obsahující zónové prostředky v souladu s odpovídajícími zónovými bránami NAT.

Doporučení k návrhu

  • Minimalizujte počet odchozích internetových připojení, protože to bude mít vliv na výkon překladu adres (NAT).

    • Pokud se vyžaduje velký počet připojení vázaných na internet, zvažte použití služby Azure NAT Gateway k abstrakci odchozích toků provozu.

  • Použijte Azure Firewall, kde existují požadavky na řízení a kontrolu odchozího internetového provozu.

    • Ujistěte se, že azure Firewall nepoužívá ke kontrole provozu mezi službami Azure.

Poznámka:

Při nasazování v cílové zóně Azure zvažte použití prostředku brány Azure Firewall základní platformy (nebo ekvivalentního síťového virtuálního zařízení). Pokud je závislost převzata z prostředku centrální platformy pro internetový výchozí přenos dat, měla by být úroveň spolehlivosti tohoto prostředku a přidružené síťové cesty úzce sladěna s požadavky aplikace. Provozní data z prostředku by měla být také zpřístupněna aplikaci, aby mohla informovat potenciální provozní akci ve scénářích selhání.

Pokud existují požadavky vysoké úrovně spojené s odchozím provozem, je potřeba vzít v úvahu vyhrazený prostředek služby Azure Firewall pro kritickou aplikaci, aby se zmírnit rizika spojená s používáním centrálně sdíleného prostředku, jako jsou scénáře hlučných sousedů.

  • Při nasazení v prostředí Virtual WAN je potřeba vzít v úvahu Správce brány firewall, aby poskytoval centralizovanou správu instancí služby Azure Firewall vyhrazených aplikací, aby se zajistilo, že se stav zabezpečení organizace bude sledovat prostřednictvím globálních zásad brány firewall.
  • Ujistěte se, že jsou zásady přírůstkové brány firewall delegovány týmům zabezpečení aplikací prostřednictvím řízení přístupu na základě role, aby bylo možné zajistit autonomii zásad aplikace.

Připojení mezi zónami a mezi oblastmi

I když návrh aplikace důrazně podporuje nezávislé razítka místního nasazení, mnoho scénářů aplikací může i nadále vyžadovat integraci sítě mezi komponentami aplikací nasazenými v různých zónách nebo oblastech Azure, i když jsou to jen za snížených okolností služby. Metoda, kterou se dosahuje komunikace mezi zónami a mezi oblastmi, má významný vliv na celkový výkon a spolehlivost, která se bude zkoumat prostřednictvím aspektů a doporučení v této části.

Na co dát pozor při navrhování

  • Přístup návrhu aplikace pro nepostradatelnou aplikaci podporuje použití nezávislých regionálních nasazení s zónovou redundancí použitou na všech úrovních komponent v rámci jedné oblasti.

  • Zóna dostupnosti (AZ) je fyzicky oddělené umístění datového centra v rámci oblasti Azure, které poskytuje fyzickou a logickou izolaci chyb až do úrovně jednoho datového centra.

    Latence odezvy menší než 2 ms je zaručena pro komunikaci mezi zónami. Zóny budou mít malou odchylku latence vzhledem k různým vzdálenostem a optickým cestám mezi zónami.

  • Připojení zóny dostupnosti závisí na regionálních charakteristikách, a proto provoz, který vstupuje do oblasti přes hraniční umístění, může být potřeba směrovat mezi zónami, aby se dostal do cíle. Tím se přidá latence ~1ms-2ms vzhledem ke směrování mezi zónami a omezení rychlosti světla, ale to by mělo mít pouze vliv na hypercitlivá zatížení.

  • Zóny dostupnosti jsou považovány za logické entity v kontextu jednoho předplatného, takže různá předplatná můžou mít jiné zónové mapování pro stejnou oblast. Například zóna 1 v předplatném A může odpovídat stejnému fyzickému datovému centru jako zóna 2 v předplatném B.

  • Díky scénářům aplikací, které jsou velmi chatty mezi komponentami aplikace, může šíření aplikačních vrstev napříč zónami představovat významnou latenci a zvýšené náklady. To je možné zmírnit v rámci návrhu omezením razítka nasazení na jednu zónu a nasazením několika razítek napříč různými zónami.

  • Komunikace mezi různými oblastmi Azure způsobuje větší poplatek za přenos dat za GB šířky pásma.

    • Použitelná rychlost přenosu dat závisí na kontinentu považovaných oblastí Azure.
    • Procházení kontinentů dat se účtuje výrazně vyšší rychlostí.

  • Metody připojení ExpressRoute a VPN je také možné použít k přímému propojení různých oblastí Azure pro určité scénáře nebo dokonce k různým cloudovým platformám.

  • Pro služby komunikace private Link je možné použít pro přímou komunikaci pomocí privátních koncových bodů.

  • Provoz je možné připnout pomocí okruhů ExpressRoute používaných pro místní připojení, aby bylo možné usnadnit směrování mezi virtuálními sítěmi v rámci oblasti Azure a mezi různými oblastmi Azure ve stejné zeměpisné oblasti.

    • Přenosy připnutí vlasů přes Express Route obcházejí náklady na přenos dat spojené s partnerskými vztahy virtuálních sítí, takže je můžete použít jako způsob optimalizace nákladů.
    • Tento přístup vyžaduje další segmenty směrování sítě pro integraci aplikací v Azure, což přináší rizika latence a spolehlivosti. Rozšiřuje roli ExpressRoute a přidružených komponent brány z Azure nebo místního prostředí, aby zahrnovala také připojení Azure nebo Azure.

  • Pokud se mezi službami vyžaduje latence v milisekundách, dají se skupiny umístění bezkontaktní komunikace použít v případě, že jsou podporovány používanými službami.

Doporučení k návrhu

  • Partnerský vztah virtuálních sítí použijte k propojení sítí v rámci oblasti a napříč různými oblastmi. Důrazně doporučujeme vyhnout se připnutí vlasů v Express Route.

  • Pomocí služby Private Link můžete navázat komunikaci přímo mezi službami ve stejné oblasti nebo napříč oblastmi (služba v oblasti A komunikuje se službou v oblasti B.

  • U úloh aplikací, které jsou mezi komponentami velmi chattní, zvažte omezení razítka nasazení na jednu zónu a nasazení několika kolků napříč různými zónami. Tím se zajistí zachování zónové redundance na úrovni zapouzdřeného razítka nasazení místo jedné součásti aplikace.

  • Pokud je to možné, zacházejte s každým razítkem nasazení jako s nezávislými a odpojenými od ostatních razítek.

    • Pomocí technologií datové platformy můžete synchronizovat stav napříč oblastmi místo dosažení konzistence na úrovni aplikace s přímými síťovými cestami.
    • Vyhýbejte se provozu "psí legging" mezi různými oblastmi, pokud to není nutné, ani ve scénáři selhání. Použijte globální služby směrování a kompletní sondy stavu k tomu, abyste v případě selhání jedné kritické vrstvy komponenty vytáhli celé razítko z oběhu, a ne ke směrování provozu na této úrovni vadných komponent do jiné oblasti.

  • V případě scénářů citlivých na hyper latenci aplikací upřednostnit použití zón s regionálními síťovými bránami za účelem optimalizace latence sítě pro cesty příchozího přenosu dat.

Zásady sítě mikro segmentace a Kubernetes

Mikrose segmentace je model návrhu zabezpečení sítě, který se používá k izolaci a zabezpečení jednotlivých aplikačních úloh. Zásady se použijí k omezení síťového provozu mezi úlohami na základě modelu nulová důvěra (Zero Trust). Obvykle se používá ke snížení prostoru pro útoky na síť, ke zlepšení omezování porušení zabezpečení a posílení zabezpečení prostřednictvím síťových kontrol na úrovni aplikací řízených zásadami.

Nepostradatelná aplikace může vynutit zabezpečení sítě na úrovni aplikace pomocí skupin zabezpečení sítě (NSG) na úrovni podsítě nebo síťového rozhraní, seznamů řízení přístupu služby (ACL) a zásad sítě při použití služby Azure Kubernetes Service (AKS).

Tato část zkoumá optimální využití těchto funkcí a poskytuje klíčové aspekty a doporučení k dosažení mikrose segmentace na úrovni aplikace.

Na co dát pozor při navrhování

  • AKS je možné nasadit ve dvou různých síťových modelech:

    • Sítě Kubenet: Uzly AKS jsou integrované v existující virtuální síti, ale pody existují v rámci virtuální překryvné sítě na každém uzlu. Provoz mezi pody na různých uzlech se směruje přes kube-proxy server.
    • Sítě Azure Container Networking Interface (CNI): Cluster AKS je integrovaný v existující virtuální síti a jeho uzlech, podech a službách přijatých IP adresy ze stejné virtuální sítě, ke které jsou uzly clusteru připojené. To je relevantní pro různé síťové scénáře, které vyžadují přímé připojení z podů a k podům. Různé fondy uzlů je možné nasadit do různých podsítí.

    Poznámka:

    Azure CNI vyžaduje v porovnání s Kubenetem více adresního prostoru IP adres. Je vyžadováno správné počáteční plánování a nastavení velikosti sítě. Další informace najdete v dokumentaci k Azure CNI.

  • Ve výchozím nastavení jsou pody neizolované a přijímají provoz z libovolného zdroje a můžou odesílat provoz do libovolného cíle; pod může komunikovat s každým dalším podem v daném clusteru Kubernetes; Kubernetes nezajistí žádnou izolaci na úrovni sítě a neizoluje obory názvů na úrovni clusteru.

  • Komunikaci mezi pody a obory názvů je možné izolovat pomocí zásad sítě. Zásady sítě jsou specifikace Kubernetes, která definuje zásady přístupu pro komunikaci mezi pody. Pomocí zásad sítě lze definovat uspořádanou sadu pravidel pro řízení způsobu odesílání a přijetí provozu a aplikování na kolekci podů, které odpovídají jednomu nebo více selektorům popisků.

    • AKS podporuje dva moduly plug-in, které implementují zásady sítě, Azure a Calico. Oba moduly plug-in používají linuxové IPTables k vynucení zadaných zásad. Další podrobnosti najdete v tématu Rozdíly mezi zásadami Azure a Calico a jejich funkcemi .
    • Zásady sítě nejsou v konfliktu, protože se sčítají.
    • Aby bylo možné povolit tok sítě mezi dvěma pody, musí tok výchozího přenosu dat na zdrojovém podu i zásady příchozího přenosu dat na cílovém podu povolit provoz.
    • Funkci zásad sítě je možné povolit pouze v době vytváření instancí clusteru. V existujícím clusteru AKS není možné povolit zásady sítě.
    • Doručování zásad sítě je konzistentní bez ohledu na to, jestli se používá Azure nebo Calico.
    • Calico poskytuje bohatší sadu funkcí, včetně podpory pro uzly windows a podporuje Azure CNI i Kubenet.

  • AKS podporuje vytváření různých fondů uzlů pro oddělení různých úloh pomocí uzlů s různými vlastnostmi hardwaru a softwaru, jako jsou uzly s možnostmi GPU a bez těchto funkcí.

    • Použití fondů uzlů neposkytuje žádnou izolaci na úrovni sítě.
    • Fondy uzlů můžou používat různé podsítě ve stejné virtuální síti. Skupiny zabezpečení sítě je možné použít na úrovni podsítě k implementaci mikrosegmentace mezi fondy uzlů.

Doporučení k návrhu

  • Nakonfigurujte skupinu zabezpečení sítě ve všech považovaných podsítích tak, aby poskytovala seznam ACL protokolu IP pro zabezpečení cest příchozího přenosu dat a izolaci komponent aplikace na základě modelu nulová důvěra (Zero Trust).

    • Použijte značky služby Front Door v rámci skupin zabezpečení sítě ve všech podsítích obsahujících back-endy aplikací definované ve službě Azure Front Door, protože tím se ověří provoz pocházející z legitimního back-endového adresního prostoru IP adres služby Azure Front Door. Tím se zajistí, že provoz prochází službou Azure Front Door na úrovni služby, ale filtrování na základě hlaviček se bude dál vyžadovat, aby se zajistilo použití konkrétní instance služby Front Door a aby se také zmírnit rizika zabezpečení falšování identity IP adres.

    • Veřejný internetový provoz by měl být zakázaný na portech RDP a SSH napříč všemi příslušnými skupinami zabezpečení sítě.

    • Určete prioritu použití síťového modulu plug-in Azure CNI a zvažte Kubenet pro scénáře s omezeným rozsahem dostupných IP adres tak, aby vyhovovala aplikaci v rámci omezeného adresního prostoru.

      • AKS podporuje použití Azure CNI i Kubenetu. Tato volba sítě je vybrána v době nasazení.
      • Síťový modul plug-in Azure CNI je robustnější a škálovatelný síťový modul plug-in a doporučuje se pro většinu scénářů.
      • Kubenet je odlehčený síťový modul plug-in a doporučuje se pro scénáře s omezeným rozsahem dostupných IP adres.
      • Další podrobnosti najdete v Azure CNI.

  • Funkce Zásady sítě v Kubernetes by se měla použít k definování pravidel pro příchozí a odchozí provoz mezi pody v clusteru. Definujte podrobné zásady sítě, které omezují a omezují komunikaci mezi pody.

    • Povolte zásady sítě pro službu Azure Kubernetes Service v době nasazení.
    • Upřednostnit použití Calico , protože poskytuje bohatší sadu funkcí s širším přechodem a podporou komunity.

Další krok

Projděte si aspekty kvantifikace a sledování stavu aplikace.

Modelování stavu a pozorovatelnost