Vzorec odlehčování brány

Přesměrovává zpracování sdílených nebo specializovaných funkcí služby na proxy brány. Tento přístup zjednodušuje vývoj aplikací tím, že centralizuje průřezové aspekty, jako je ukončení certifikátu TLS na straně klienta, v bráně místo jejich duplikování napříč službami.

Pokud více služeb sdílí povinnosti, jako je ověřování, monitorování nebo překlad protokolů, konsolidace těchto obav do jedné brány snižuje režijní náklady na konfiguraci jednotlivých služeb a riziko nasazení.

Kontext a problém

Některé funkce se běžně používají ve více službách a tyto funkce vyžadují konfiguraci, správu a údržbu. Sdílená nebo specializovaná služba, kterou distribuujete s každým nasazením aplikace, přidává režijní náklady na správu a zvyšuje pravděpodobnost chyby nasazení. Všechny aktualizace sdílené funkce musíte nasadit napříč všemi službami, které tuto funkci sdílejí.

Problémy se zabezpečením, jako je ověřování tokenů, šifrování a správa certifikátů TLS, můžou vyžadovat, aby členové týmu měli vysoce specializované dovednosti. Například bez brány možná budete muset nakonfigurovat a nasadit klientský certifikát pro každou instanci aplikace. Musíte sledovat jeho vypršení platnosti a aktualizaci, testovat a ověřit v rámci těchto instancí.

Další běžné služby jako ověřování, autorizace, protokolování, monitorování nebo omezování využití sítě můžou být náročné z hlediska implementace a správy v rámci velkého počtu nasazení. Konsolidace tohoto typu funkcí snižuje režii a pravděpodobnost chyb.

Solution

Přenést některé funkce na bránu. Brána pak zajišťuje průřezové funkce, jako je správa certifikátů směrem ke klientům, autentizace, ukončení TLS, monitorování, překlad protokolů a omezování požadavků pro back-endové služby.

Následující diagram znázorňuje bránu, která ukončuje příchozí připojení TLS a používá sdílené funkce. Brána ověří back-endový certifikát a znovu zašifruje provoz přes samostatné připojení TLS k back-endové službě.

Diagram klienta, který se připojuje k bráně přes protokol TLS

K výhodám tohoto modelu patří:

  • Zjednodušte vývoj služeb tím, že centralizujete sdílenou konfiguraci, jako je ověřování, omezování a protokolování požadavků, a nemusíte je implementovat v každé back-endové službě. Centralizace zlepšuje konzistenci a usnadňuje upgrady služeb.

  • Implementaci funkcí, které vyžadují specializované znalosti, třeba zabezpečení, můžete svěřit vyhrazeným týmům. Váš základní tým se pak může soustředit na funkčnost aplikací a nechat tyto specializované, ale průřezové obavy relevantním odborníkům.

  • Umožňuje zajistit do určité míry konzistentní protokolování a monitorování žádostí a odpovědí. I když služba není správně instrumentovaná, může brána poskytnout základní úroveň monitorování a protokolování.

  • Centralizujte správu provozu s ohledem na emise uhlíku. Brána může upravit caching, rychlostní omezení a protokolovací funkce na základě signálů reálné intenzity emisí uhlíku. Azure API Management tyto funkce poskytuje v omezené verzi Preview ve vybraných oblastech a klasických úrovních (Developer, Basic, Standard a Premium). Podrobnosti o dostupnosti a konfiguraci naleznete v článku Environmentálně udržitelná rozhraní API ve službě Azure API Management.

Problémy a důležité informace

Při rozhodování o implementaci tohoto modelu zvažte následující body:

  • Vysoká dostupnost a odolnost. Ujistěte se, že je brána vysoce dostupná a odolná vůči selhání. Vyhněte se jednotlivým bodům selhání provozováním více instancí vaší brány. Vzhledem k tomu, že brána ukončuje připojení klientů a může ukládat požadavky do vyrovnávací paměti, zvažte, jak se požadavky v testovacích verzích zpracovávají během selhání instance. Používejte mechanismy pro řízení ukončování připojení nebo řízené vypnutí, aby odebrání nebo restartování instance brány nevedlo k ukončení aktivních relací.

  • Kapacita a škálování Ujistěte se, že je brána navržená pro požadavky na kapacitu a škálování vaší aplikace a koncových bodů. Ujistěte se, že brána není kritickým bodem aplikace a je dostatečně škálovatelná. Brána musí být zřízená, aby zvládla nárůsty provozu ve špičce, nejen průměrné zatížení. Nedostatečně zřízená brána za účelem snížení nákladů přímo snižuje výkon každé služby za ní.

  • Rozsah odlehčení. Přesměrování zátěže funkcí sdílených více službami nebo trasami při jejich centralizaci snižuje duplicitní implementaci a správu.

  • Oddělení obchodní logiky. Nikdy neusměrovávejte obchodní logiku do brány.

  • Sledování transakcí. Pokud potřebujete sledovat transakce, zvažte generování ID korelace pro účely protokolování.

  • Režie způsobená latencí Brána přidává ke každému požadavku síťový skok. Každá přesměrovaná funkce, kterou brána provádí, jako je ukončení protokolu TLS, ověřování nebo kontrola požadavku, přidává do cesty požadavku dobu zpracování. Sdružování připojení v bráně a udržování aktivních připojení k backendovým službám mohou částečně kompenzovat dopad latence tím, že znovu používají existující připojení místo navazování nových pro každý požadavek. Vyhodnoťte, zda je kombinovaná latence průchodu přes bránu a odlehčených funkcí přijatelná vzhledem k výkonnostním cílům úlohy.

  • Provozní složitost. Centralizovaná brána konsoliduje správu, ale také se soustředí na provozní odpovědnost. Konfiguraci brány, životní cyklus certifikátů, aktualizace zásad a přechody na novější verze musíte spravovat jako společnou odpovědnost. Ujistěte se, že tým zodpovědný za bránu má kapacitu a nástroje pro správu ve velkém měřítku všech služeb, které na ní závisejí.

  • Vliv na zabezpečení. Brána je vysoce hodnotný cíl, protože centralizuje průřezové funkce zabezpečení, jako je ověřování, ukončení protokolu TLS a kontrola požadavků. Kompromitace brány může ohrozit všechny navazující služby. Zpevnit bránu, omezit její plochu pro správu a monitorovat neobvyklé chování nezávisle na back-endových službách, které chrání.

  • Prevence obejití brány Nakonfigurujte back-endové služby tak, aby přijímaly požadavky pouze prostřednictvím zamýšlené cesty brány. Jinak se klienti můžou připojit přímo k back-endu a obejít ověřování, omezování, kontrolu požadavků a protokolování v bráně.

  • Šíření identity Definujte, jestli každý back-end autorizuje původního volajícího, identitu úlohy brány nebo obojí. Zachovejte tokeny volajícího nebo důvěryhodné deklarace pouze tehdy, když backend vyžaduje delegovaný kontext uživatele. Bránu vždy autentizujte vůči backendu samostatně. Nepovažujte neověřené přeposlané hlavičky za důkaz identity.

  • Údržba protokolu TLS. Pokud brána ukončí TLS, znovu navažte TLS spojení s backendem. Nepřesměrovávejte provoz přes nešifrovaný protokol HTTP. Považovat všechny sítě za nedůvěryhodné. Tato topologie stále vyžaduje proces vydávání, obměny a odvolávání back-endových certifikátů.

  • Přeposílané hlavičky a kontext klienta. Když brána ukončí připojení klientů a vytvoří nová připojení k back-endovým službám, informace, jako je IP adresa klienta, původní protokol a název hostitele, se ztratí, pokud ji brána explicitně nepředá. Strategie zmírnění rizik najdete v tématu Zachování původního názvu hostitele HTTP mezi reverzním proxy serverem a back-endovou webovou aplikací.

Kdy použít tento vzor

Tento model použijte v těchto případech:

  • Nasazení aplikace má sdílený problém, jako jsou certifikáty TLS nebo šifrování.
  • Funkce společná pro nasazení aplikací může mít různé požadavky na prostředky, jako jsou paměťové prostředky, kapacita úložiště nebo síťová připojení.
  • Chcete přesunout odpovědnost za problémy, jako je zabezpečení sítě, omezování nebo jiné aspekty hranic sítě, do specializovaného týmu.

Tento vzor nemusí být vhodný v těchto případech:

  • Brána musí obsahovat logiku specifickou pro službu nebo pravidla směrování, která úzce propojte změny back-endové služby s změnami konfigurace brány. Párování úrovně brány s interními službami znamená, že back-endové aktualizace můžou vynutit opětovné nasazení brány a snížit nezávislost nasazení.
  • Přenesená úloha je nenáročná a pracovní zátěž je citlivá na latenci. Další síťový mezikrok přes bránu nemusí být opodstatněný, pokud režijní náklady převáží přínos centralizace.
  • Soustředění odpovědností do společné brány vytváří úzké hrdlo při řízení změn. Pokud je cyklus vydávání týmu brány pomalejší než cyklus týmů služeb, může přenesení zpracování na bránu zpozdit aktualizace certifikátů, zásad ověřování nebo síťových pravidel.

Návrh úloh

Architekt by měl vyhodnotit, jak se dá model snižování zátěže brány použít v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklady:

Pilíř Jak tento model podporuje cíle pilíře
Spolehlivostní rozhodnutí o návrhu pomáhají vaší pracovní zátěži stát se odolná proti poruchám a zajistit, aby se po selhání obnovila do plně funkčního stavu. Přesměrování této zodpovědnosti na bránu snižuje složitost kódu aplikace na back-endových uzlech. V některých případech snižování zátěže zcela nahrazuje funkce spolehlivou funkcí poskytovanou platformou.

- RE:01 Jednoduchost a efektivita
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy. Zařazení brány do toku požadavků vám umožní centralizovat mechanismy, jako jsou firewally webových aplikací a zásady klientského TLS. Všechny odložené funkce, které jsou poskytované platformou, už nabízejí lepší zabezpečení.

- SE:06 Řízení sítě
- SE:08 Posílení zabezpečení prostředků
Optimalizace nákladů se zaměřuje na udržení a zlepšenínávratnosti vašich úloh. Tento model umožňuje přesměrovat náklady z prostředků, které by se utratily za uzel do implementace brány. Náklady v modelu centralizovaného zpracování jsou často nižší než náklady distribuovaného modelu.

- CO:14 Konsolidace
Efektivita provozu pomáhá poskytovat kvalitu úloh prostřednictvím standardizovaných procesů a týmové soudržnosti. V tomto vzoru jsou konfigurace a údržba externě zajišťovaných funkcí spojeny s jediným bodem namísto toho, aby vyžadovaly správu z více uzlů. Tato centralizace standardizuje způsob uplatňování průřezových aspektů, takže rutinní i ad hoc provozní změny jsou konzistentní a předvídatelné.

- Operace standardizace OE:02
efektivita výkonu pomáhá vašim úlohám efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu. Přidání offloadovací brány do procesu zpracování požadavků vám umožňuje využívat méně prostředků na uzel, protože funkcionalita je centralizována v bráně. Implementaci přetěžované funkce můžete optimalizovat nezávisle na kódu aplikace. Funkce poskytované odlehčenou platformou již pravděpodobně jsou vysoce výkonné.

- PE:03 Výběr služeb

Pokud tento model představuje kompromisy v rámci pilíře, zvažte je proti cílům ostatních pilířů.

Example

Azure Application Gateway WAF_v2 může tento model implementovat pro regionální webovou aplikaci. Brána ukončí připojení TLS klienta, použije zásady WAF a směrování a vytvoří nová připojení TLS k back-endovým službám. Tento návrh uchovává obavy týkající se sdíleného zpracování požadavků mimo kód back-endové aplikace.

Application Gateway s odlehčením TLS

Následující diagram znázorňuje, jak služba Application Gateway ukončí příchozí připojení TLS, zkontroluje a vyfiltruje provoz a před předáním do back-endového fondu přes protokol TLS ho znovu zašifruje.

Diagram znázorňující, jak služba Application Gateway ukončuje příchozí spojení TLS od klientů, používá WAF a pravidla směrování a znovu šifruje provoz přes TLS do back-endového fondu serverů.

Tato architektura používá následující komponenty služby Application Gateway k přesměrování zátěže sdílených funkcí a opětovnému šifrování back-endového provozu:

  • Naslouchací proces HTTPS. Naslouchací proces HTTPS na portu 443 přijímá příchozí připojení TLS z klientů.
  • Certifikát TLS. K naslouchači HTTPS je připojen certifikát PFX pocházející z Azure Key Vault. Application Gateway dešifruje příchozí provoz za účelem kontroly a směrování a pak ho znovu zašifruje do back-endového fondu. Back-endové servery stále potřebují certifikáty pro znovu zašifrovaná připojení, ale v mnoha případech je možné použít certifikáty spravované platformou.
  • Fond backendů Fond back-endu definuje množinu serverů HTTPS, které přijímají přešifrovaný provoz. Back-endové cíle můžou být virtuální počítače, Škálovací sady virtuálních počítačů Azure, IP adresy nebo instance Azure App Service. Omezte přístup k back-endu, aby klienti nemohli obejít službu Application Gateway a její zásady WAF připojením přímo.
  • Nastavení back-endu HTTP Nastavte back-endový protokol na HTTPS a port na port TLS back-endu, například 443. Nakonfigurujte důvěryhodnost certifikátu a název hostitele, který odpovídá back-endovému certifikátu. Pro privátní certifikační autoritu nakonfigurujte důvěryhodný kořenový certifikát. Podrobnosti naleznete v tématu Komplexní šifrování TLS s tarifem SKU v2.
  • Pravidlo směrování Pravidlo směrování požadavků přiřazuje naslouchač k fondu back-endu a nastavení HTTP back-endu. Pravidla založená na cestě můžou směrovat různé cesty URL do různých back-endových fondů.
  • Zásady WAF. Zásada definuje spravovaná a vlastní pravidla používaná ke kontrole požadavků, včetně všech pravidel Geomatch.

Vzhledem k tomu, že Application Gateway dešifruje provoz, může kontrolovat obsah požadavku pro inteligentní směrování, přepisovat hlavičky a adresy URL PROTOKOLU HTTP a používat pravidla WAF. Potom znovu zašifruje provoz před předáním požadavků do back-endu.

Pokyny ke konfiguraci najdete v tématu Kompletní šifrování TLS se službou Application Gateway.

Podpůrné technologie

Následující Azure služby vám můžou pomoct implementovat tento model:

Další kroky

  • Last updated on