Sdílet prostřednictvím

Přístupy architektury pro sítě ve víceklientských řešeních

  • Článek

Všechna řešení nasazená do Azure vyžadují síť určitého druhu. V závislosti na návrhu vašeho řešení a úlohách se můžou lišit způsoby interakce se síťovými službami Azure. V tomto článku poskytujeme důležité informace a pokyny k aspektům sítí víceklientských řešení v Azure. Mezi informace o síťových komponentách nižší úrovně, jako jsou virtuální sítě, patří prostřednictvím přístupů vyšší úrovně a aplikační vrstvy.

Poznámka:

Samotná Platforma Azure je víceklientské prostředí a síťové komponenty Azure jsou navržené pro víceklientskou architekturu. I když není nutné porozumět podrobnostem při návrhu vlastního řešení, můžete se dozvědět více o tom, jak Azure izoluje provoz virtuální sítě od provozu jiných zákazníků.

Klíčové aspekty a požadavky

Služby infrastruktury a platformy

Obavy, které máte pro síťové komponenty, se budou lišit v závislosti na kategorii služeb, které používáte.

Služby infrastruktury

Kdykoli používáte služby infrastruktury, jako jsou virtuální počítače nebo Azure Kubernetes Service, musíte zvážit a navrhnout virtuální sítě nebo virtuální sítě, které podporují připojení vašich služeb. Musíte také zvážit další vrstvy zabezpečení a izolace, které potřebujete začlenit do návrhu. Vyhněte se výhradně kontrole síťových vrstev.

Služby platformy

Pokud používáte služby platformy Azure, jako jsou App Service, Azure Cosmos DB nebo Azure SQL Database, určí konkrétní architektura, kterou používáte, síťové služby, které potřebujete.

Pokud potřebujete izolovat služby platformy od internetu, musíte použít virtuální síť. V závislosti na konkrétních službách, které používáte, můžete pracovat s privátními koncovými body nebo prostředky integrovanými do virtuální sítě, jako je Application Gateway. Můžete se ale také rozhodnout zpřístupnit služby platformy prostřednictvím jejich veřejných IP adres a používat vlastní ochranu služeb, jako jsou brány firewall a řízení identit. V těchto situacích možná nebudete potřebovat virtuální síť.

Rozhodnutí o použití virtuálních sítí pro služby platformy vychází z mnoha požadavků, včetně následujících faktorů:

  • Požadavky na dodržování předpisů: Možná budete muset splnit konkrétní standard dodržování předpisů. Některé standardy vyžadují, aby vaše prostředí Azure bylo nakonfigurované určitým způsobem.
  • Požadavky vašich tenantů: I když vaše vlastní organizace nemá specifické požadavky na izolaci nebo ovládací prvky vrstvy sítě, můžou to být vaše tenanti. Ujistěte se, že máte jasné znalosti o tom, jak budou vaši tenanti přistupovat k vašemu řešení a jestli mají nějaké předpoklady týkající se návrhu sítě.
  • Složitost: Pochopení a práce s virtuálními sítěmi může být složitější. Ujistěte se, že váš tým jasně rozumí principům, nebo pravděpodobně nasadíte nezabezpečené prostředí.

Ujistěte se, že rozumíte důsledkům používání privátních sítí.

Určení velikosti podsítí

Pokud potřebujete nasadit virtuální síť, je důležité pečlivě zvážit velikost a adresní prostor celé virtuální sítě a podsítí v rámci virtuální sítě.

Ujistěte se, že máte jasné znalosti o tom, jak nasadíte prostředky Azure do virtuálních sítí, a počet IP adres, které jednotlivé prostředky spotřebovávají. Pokud nasadíte výpočetní uzly specifické pro tenanta, databázové servery nebo jiné prostředky, ujistěte se, že vytvoříte podsítě, které jsou dostatečně velké pro očekávaný růst tenanta a horizontální automatické škálování prostředků.

Podobně když pracujete se spravovanými službami, je důležité pochopit, jak se POUŽÍVAJÍ IP adresy. Když například použijete Azure Kubernetes Service s rozhraním CNI (Azure Container Networking Interface), počet IP adres spotřebovaných z podsítě bude vycházet z faktorů, jako je počet uzlů, horizontální škálování a proces nasazení služby, který používáte. Pokud používáte Aplikace Azure Service a Azure Functions s integrací virtuální sítě, počet spotřebovaných IP adres vychází z počtu instancí plánu.

Při plánování podsítí si projděte pokyny k segmentaci podsítě.

Veřejný nebo soukromý přístup

Zvažte, jestli budou vaši tenanti přistupovat k vašim službám přes internet nebo prostřednictvím privátních IP adres.

Pro internetový (veřejný) přístup můžete použít pravidla brány firewall, seznam povolených IP adres a seznam odepření, sdílené tajné klíče a klíče a ovládací prvky založené na identitách k zabezpečení vaší služby.

Pokud potřebujete povolit připojení ke službě pomocí privátních IP adres, zvažte použití služby Azure Private Link nebopartnerského vztahu virtuálních sítí mezi tenanty. V některých omezených scénářích můžete také zvážit použití služby Azure ExpressRoute nebo Azure VPN Gateway k povolení privátního přístupu k vašemu řešení. Tento přístup doporučujeme použít jenom v případě, že máte malý počet tenantů a pro každého tenanta nasadíte vyhrazené virtuální sítě.

Přístup ke koncovým bodům tenantů

Zvažte, jestli potřebujete odesílat data do koncových bodů v sítích tenantů, a to buď v rámci Azure, nebo mimo Azure. Budete například muset vyvolat webhook, který poskytuje zákazník, nebo potřebujete odeslat zprávy do tenanta v reálném čase?

Pokud potřebujete odesílat data do koncových bodů tenantů, zvažte následující běžné přístupy:

  • Zahajte připojení z vašeho řešení ke koncovým bodům tenantů přes internet. Zvažte, jestli připojení musí pocházet ze statické IP adresy. V závislosti na službách Azure, které používáte, možná budete muset nasadit službu NAT Gateway, bránu firewall nebo nástroj pro vyrovnávání zatížení.
  • Nasaďte agenta, který umožňuje připojení mezi vašimi službami hostovanými v Azure a sítěmi vašich zákazníků bez ohledu na to, kde se nacházejí.
  • Pro jednosměrné zasílání zpráv zvažte použití služby, jako je Azure Event Grid, s doménami událostí nebo bez nich.

Přístupy a vzory, které je potřeba zvážit

V této části popisujeme některé klíčové síťové přístupy, které můžete zvážit v víceklientských řešeních. Začneme popisem přístupů na nižší úrovni základních síťových komponent a pak budeme postupovat podle přístupů, které můžete zvážit pro http a další aspekty aplikační vrstvy.

Virtuální sítě specifické pro tenanta s vybranými IP adresami poskytovatele služeb

V některých situacích je potřeba spustit vyhrazené prostředky připojené k virtuální síti v Azure jménem tenanta. Můžete například spustit virtuální počítač pro každého tenanta nebo pro přístup k databázím pro konkrétní tenanty použít privátní koncové body.

Zvažte nasazení virtuální sítě pro každého tenanta pomocí adresního prostoru IP, který řídíte. Tento přístup umožňuje vytvořit partnerský vztah mezi virtuálními sítěmi pro vlastní účely, například pokud potřebujete vytvořit hvězdicovou topologii pro centrální řízení příchozího a výchozího přenosu dat.

Ip adresy vybrané poskytovatelem služeb ale nejsou vhodné, pokud se tenanti potřebují připojit přímo k virtuální síti, kterou jste vytvořili, například pomocí partnerského vztahu virtuálních sítí. Je pravděpodobné, že vybraný adresní prostor nebude kompatibilní s vlastními adresními prostory.

Virtuální sítě specifické pro tenanty s vybranými IP adresami tenanta

Pokud klienti potřebují vytvořit partnerský vztah mezi vlastními virtuálními sítěmi s virtuální sítí, kterou spravujete jejich jménem, zvažte nasazení virtuálních sítí specifických pro tenanty s adresním prostorem IP, který tenant vybere. Tento systém umožňuje každému tenantovi zajistit, aby se rozsahy IP adres ve virtuální síti vašeho systému nepřekrývaly s vlastními virtuálními sítěmi. Pomocí nepřekrývajících se rozsahů IP adres může zajistit, aby jejich sítě byly kompatibilní s partnerským vztahem.

Tento přístup ale znamená, že je nepravděpodobné, že byste mohli propojit virtuální sítě tenantů dohromady nebo přijmout hvězdicovou topologii, protože mezi virtuálními sítěmi různých tenantů pravděpodobně překrývají rozsahy IP adres.

Hvězdicová topologie

Topologie hvězdicové virtuální sítě umožňuje vytvořit partnerský vztah centrální virtuální sítě s více paprskovými virtuálními sítěmi. Můžete centrálně řídit příchozí a výchozí přenos dat pro vaše virtuální sítě a řídit, jestli mezi sebou můžou komunikovat prostředky ve virtuální síti jednotlivých paprsků. Každá paprsková virtuální síť má také přístup ke sdíleným komponentám, jako je Azure Firewall, a může být schopná používat služby, jako je Azure DDoS Protection.

Pokud používáte hvězdicovou topologii, ujistěte se, že plánujete limity, jako je maximální počet partnerských virtuálních sítí, a ujistěte se, že nepoužíváte překrývající se adresní prostory pro virtuální síť každého tenanta.

Hvězdicová topologie může být užitečná při nasazování virtuálních sítí specifických pro tenanta s vybranými IP adresami. Virtuální síť každého tenanta se stane paprskem a může sdílet společné prostředky ve virtuální síti centra. Hvězdicovou topologii můžete použít také při škálování sdílených prostředků napříč více virtuálními sítěmi pro účely škálování nebo při použití vzoru Razítka nasazení.

Tip

Pokud vaše řešení běží napříč několika geografickými oblastmi, je obvykle vhodné nasadit samostatná centra a prostředky centra v každé oblasti. Tento postup sice způsobuje vyšší náklady na prostředky, ale zbytečně se vyhne provozu v několika oblastech Azure, což může zvýšit latenci požadavků a účtovat globální poplatky za partnerský vztah.

Statické IP adresy

Zvažte, jestli vaši tenanti potřebují, aby vaše služba používala statické veřejné IP adresy pro příchozí provoz, odchozí provoz nebo obojí. Různé služby Azure umožňují statické IP adresy různými způsoby.

Při práci s virtuálními počítači a dalšími komponentami infrastruktury zvažte použití nástroje pro vyrovnávání zatížení nebo brány firewall pro příchozí i odchozí statické PŘIDĚLOVÁNÍ IP adres. Zvažte použití služby NAT Gateway k řízení IP adresy odchozího provozu. Další informace o používání služby NAT Gateway ve víceklientském řešení najdete v tématu Aspekty služby Azure NAT Gateway pro víceklientské prostředí.

Když pracujete se službami platformy, konkrétní služba, kterou používáte, určuje, jestli a jak můžete řídit IP adresy. Možná budete muset prostředek nakonfigurovat určitým způsobem, například nasazením prostředku do virtuální sítě a pomocí služby NAT Gateway nebo brány firewall. Nebo můžete požádat o aktuální sadu IP adres, které služba používá pro odchozí provoz. App Service například poskytuje rozhraní API a webové rozhraní pro získání aktuálních odchozích IP adres pro vaši aplikaci.

Agenti

Pokud potřebujete svým tenantům povolit příjem zpráv iniciovaných vaším řešením nebo pokud potřebujete získat přístup k datům, která existují v vlastních sítích tenantů, zvažte poskytnutí agenta (někdy označovaného jako místní brána), který může nasadit v rámci své sítě. Tento přístup může fungovat bez ohledu na to, jestli jsou sítě tenantů v Azure, v jiném poskytovateli cloudu nebo místně.

Agent zahájí odchozí připojení ke koncovému bodu, který zadáte a řídíte, a buď udržuje dlouhotrvající připojení aktivní, nebo se občas dotazuje. Zvažte použití služby Azure Relay k navázání a správě připojení z vašeho agenta k vaší službě. Když agent naváže připojení, ověří se a zahrne některé informace o identifikátoru tenanta, aby vaše služba mohl namapovat připojení ke správnému tenantovi.

Agenti obvykle zjednodušují konfiguraci zabezpečení pro vaše tenanty. Otevření příchozích portů, zejména v místním prostředí, může být složité a rizikové. Agent se vyhne potřebě tenantů, aby toto riziko převzali.

Mezi příklady služby Microsoft, které poskytují agenty pro připojení k sítím tenantů, patří:

Služba Azure Private Link poskytuje privátní připojení z prostředí Azure tenanta k vašemu řešení. Tenanti můžou také používat službu Private Link s vlastní virtuální sítí pro přístup k vaší službě z místního prostředí. Azure bezpečně směruje provoz do služby pomocí privátních IP adres.

Další informace o službě Private Link a víceklientské architektury najdete v tématu Víceklientská architektura a Azure Private Link.

Názvy domén, subdomény a TLS

Při práci s názvy domén a protokolem TLS (Transport-Layer Security) ve víceklientských řešeních je potřeba vzít v úvahu celou řadu aspektů. Projděte si důležité informace týkající se víceklientské architektury a názvů domén.

Vzory směrování brány a přesměrování zpracování brány

Model směrování brány a model přesměrování zpracování brány zahrnují nasazení reverzního proxy serveru nebo brány vrstvy 7. Brány jsou užitečné k poskytování základních služeb pro víceklientských aplikací, včetně následujících funkcí:

  • Směrování požadavků na back-endy specifické pro tenanty nebo razítka nasazení
  • Zpracování názvů domén specifických pro tenanta a certifikátů TLS
  • Kontrola požadavků na bezpečnostní hrozby pomocí firewallu webových aplikací (WAF)
  • Ukládání do mezipaměti odpovědi na zlepšení výkonu.

Azure poskytuje několik služeb, které je možné použít k dosažení některých nebo všech těchto cílů, včetně služby Azure Front Door, Aplikace Azure Gateway a Služby Azure API Management. Vlastní řešení můžete nasadit také pomocí softwaru, jako je NGINX nebo HAProxy.

Pokud plánujete nasadit bránu pro vaše řešení, osvědčeným postupem je nejprve sestavit kompletní prototyp, který zahrnuje všechny potřebné funkce, a ověřit, že komponenty vaší aplikace budou fungovat podle očekávání. Měli byste také pochopit, jak bude komponenta brány škálovat, aby podporovala váš provoz a růst tenanta.

Model hostování statického obsahu

Model Hostování statického obsahu zahrnuje poskytování webového obsahu ze služby cloudového nativního úložiště a použití sítě pro doručování obsahu (CDN) k ukládání obsahu do mezipaměti.

Azure Front Door nebo jiný CDN můžete použít pro statické komponenty vašeho řešení, jako jsou jednostránkové javascriptové aplikace, a pro statický obsah, jako jsou soubory obrázků a dokumenty.

V závislosti na tom, jak je vaše řešení navržené, můžete být také schopni ukládat soubory nebo data specifická pro tenanta do mezipaměti v rámci CDN, jako jsou odpovědi rozhraní API ve formátu JSON. Tento postup vám může pomoct zlepšit výkon a škálovatelnost vašeho řešení, ale je důležité zvážit, jestli jsou data specifická pro tenanty izolovaná dostatečně, aby nedocházelo k úniku dat mezi tenanty. Zvažte, jak plánujete vyprázdnit obsah specifický pro tenanta z mezipaměti, například při aktualizaci dat nebo nasazení nové verze aplikace. Zahrnutím identifikátoru tenanta do cesty URL můžete určit, jestli vyprázdníte určitý soubor, všechny soubory, které se vztahují ke konkrétnímu tenantovi, nebo všechny soubory pro všechny tenanty.

Antipatterny, aby se zabránilo

Nedaří se naplánovat připojení virtuální sítě

Nasazením prostředků do virtuálních sítí máte velkou kontrolu nad tím, jak provoz prochází komponentami vašeho řešení. Integrace virtuální sítě ale také přináší další složitost, náklady a další faktory, které je potřeba zvážit. Tento účinek platí zejména u komponent PaaS (platforma jako služba).

Je důležité otestovat a naplánovat strategii sítě, abyste před implementací v produkčním prostředí odhalili případné problémy.

Neplánuje se limity

Azure vynucuje řadu omezení, která ovlivňují síťové prostředky. Mezi tyto limity patří limity prostředků Azure a základní limity protokolů a platforem. Když například vytvoříte vysoce škálovatelné víceklientské řešení na platformových službách, jako je Aplikace Azure Služba a Azure Functions, budete možná muset zvážit počet připojení TCP a portů SNAT. Při práci s virtuálními počítači a nástroji pro vyrovnávání zatížení je také potřeba zvážit omezení pro odchozí pravidla a porty SNAT.

Malé podsítě

Je důležité zvážit velikost každé podsítě, aby umožňovala počet prostředků nebo instancí prostředků, které nasadíte, zejména při škálování. Pokud pracujete s prostředky PaaS (Platforma jako služba), ujistěte se, že rozumíte tomu, jak bude konfigurace a škálování vašeho prostředku ovlivnit počet IP adres, které jsou v její podsíti potřeba.

Nesprávná segmentace sítě

Pokud vaše řešení vyžaduje virtuální sítě, zvažte, jak nakonfigurovat segmentaci sítě, abyste mohli řídit příchozí a odchozí toky (severojižní) toky provozu a toky v rámci vašeho řešení (východ– západ). Rozhodněte se, jestli mají mít tenanti vlastní virtuální sítě nebo jestli nasadíte sdílené prostředky ve sdílených virtuálních sítích. Změna přístupu může být obtížná, proto zajistěte, abyste zvážili všechny vaše požadavky, a pak vyberte přístup, který bude fungovat pro vaše budoucí cíle růstu.

Spoléhání se pouze na ovládací prvky zabezpečení vrstvy sítě

V moderních řešeních je důležité zkombinovat zabezpečení vrstvy sítě s jinými bezpečnostními prvky a neměli byste se spoléhat jenom na brány firewall nebo segmentaci sítě. Někdy se tomu říká síť s nulovou důvěryhodností. Pomocí ovládacích prvků založených na identitách ověřte klienta, volajícího nebo uživatele v každé vrstvě vašeho řešení. Zvažte použití služeb, které umožňují přidat další vrstvy ochrany. Dostupné možnosti závisí na službách Azure, které používáte. V AKS zvažte použití sítě služeb pro vzájemné ověřování TLS a zásady sítě k řízení provozu východ-západ. Ve službě App Service zvažte použití integrované podpory pro ověřování a autorizaci a omezení přístupu.

Přepsání hlaviček hostitele bez testování

Při použití vzoru Přesměrování načítání brány můžete zvážit přepsání Host hlavičky požadavků HTTP. Tento postup může zjednodušit konfiguraci služby back-endové webové aplikace tím, že přesměruje vlastní doménu a správu protokolu TLS do brány.

Host Přepsání hlaviček ale může způsobit problémy u některých back-endových služeb. Pokud vaše aplikace problémy s přesměrováním http nebo soubory cookie, může neshoda názvů hostitelů narušit funkčnost aplikace. Konkrétně k tomuto problému může dojít, když používáte back-endové služby, které jsou samy o sobě víceklientských, jako jsou Aplikace Azure Service, Azure Functions a Azure Spring Apps. Další informace najdete v osvědčených postupech pro zachování názvů hostitelů.

Ujistěte se, že testujete chování aplikace s konfigurací brány, kterou plánujete použít.

Přispěvatelé

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

Hlavní autor:

  • John Downs | Hlavní zákaznický inženýr, FastTrack pro Azure

Další přispěvatelé:

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

Další kroky