Vzor gatekeeper

Chraňte aplikace a služby pomocí vyhrazené komponenty ke zprostředkování požadavků mezi klienty a aplikací nebo službou. Zprostředkovatel ověří a sanituje požadavky a může poskytnout další vrstvu zabezpečení a omezit prostor pro útoky na systém.

Kontext a problém

Mnoho cloudových služeb zveřejňuje koncové body, které klientským aplikacím umožňují volat svá rozhraní API přes internet nebo jinou nedůvěryhodnou síť. Kód, který implementuje rozhraní API, spouští nebo provádí několik úloh, mimo jiné ověřování, autorizaci, validaci parametrů a některé nebo všechny kroky zpracování požadavků. Kód rozhraní API bude pravděpodobně přistupovat k úložišti a dalším službám jménem klienta.

Pokud uživatel se zlými úmysly ohrožuje systém a získá přístup k hostitelskému prostředí aplikace, zpřístupní se jeho bezpečnostní mechanismy a přístup k datům a dalším službám. V důsledku toho může uživatel se zlými úmysly získat neomezený přístup k přihlašovacím údajům, klíčům úložiště, citlivým informacím a dalším službám.

Solution

Jedním z řešení tohoto problému je oddělení kódu, který implementuje veřejné koncové body od kódu, který zpracovává požadavky a přistupuje k úložišti. Oddělte kód pomocí vrstvy fasády, která komunikuje s klienty a směruje schválené požadavky prostřednictvím interního koncového bodu, fronty nebo zprostředkovatele, na komponenty úloh, které zpracovávají obchodní operaci. Diagram poskytuje základní přehled tohoto modelu.

Model Gatekeeper můžete použít k ochraně úložiště nebo ho můžete použít jako komplexnější fasádu k ochraně všech funkcí aplikace. Mezi důležité faktory patří:

Řízené ověřování: Vrátný ověří všechny požadavky a odmítne žádosti, které nesplňují požadavky na ověření.
Omezené riziko a expozice: Rizika a expozice se snižují, protože vrátný nemá přístup k přihlašovacím údajům nebo klíčům, které důvěryhodný hostitel používá pro přístup k úložišti a službám. Pokud se vrátný stane ohroženým, útočníci nemají přístup k těmto přihlašovacím údajům ani klíčům.
Odpovídající zabezpečení: Vrátný běží v režimu omezeného oprávnění, zatímco zbytek aplikace běží v režimu úplného vztahu důvěryhodnosti vyžadovaný pro přístup k úložišti a službám. Pokud dojde k ohrožení vrátného, nemá přímý přístup ke službám nebo datům aplikace.

Tento vzor funguje jako firewall v typické síťové topologii. Na rozdíl od tradičního firewallu umožňuje vrátnému podrobně analyzovat požadavky a rozhodnout, zda požadavek předat důvěryhodnému hostiteli, který provádí požadované úlohy. Toto rozhodnutí obvykle vyžaduje, aby vrátný ověřil a sanitizoval obsah požadavku, než ho předá důvěryhodnému hostiteli. Vrátní můžou žádost autorizovat, hledat neočekávaný nebo neplatný obsah datové části, provádět omezování rychlosti a provádět různé další kontroly.

Problémy a důležité informace

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

Ujistěte se, že důvěryhodní hostitelé zpřístupňují pouze interní nebo chráněné koncové body, které používá pouze vrátný. Důvěryhodní hostitelé by neměli vystavovat žádné externí koncové body nebo rozhraní.
Vrátný musí běžet v režimu s omezenými oprávněními. V praxi hostujte vrátného a důvěryhodný back-end na samostatných hranicích výpočetních prostředků a udržujte back-endové koncové body privátní.
Vrátný by neměl provádět zpracování související s aplikacemi nebo službami nebo přístupem k datům. Její funkce slouží pouze k ověření a sanitizaci požadavků. Důvěryhodní hostitelé můžou potřebovat provést dodatečné ověření požadavků, ale vrátný by měl provést základní ověření.
Používejte zabezpečený komunikační kanál, jako je HTTPS, SSL (Secure Sockets Layer) nebo TLS (Transport Layer Security) mezi vrátným a důvěryhodnými hostiteli nebo úlohami, pokud je to možné. Některá hostitelská prostředí ale nepodporují HTTPS na interních koncových bodech.
Přidání další vrstvy pro implementaci modelu Gatekeeper pravděpodobně ovlivní výkon kvůli dodatečnému zpracování a síťové komunikaci.
Kontrolní mechanismus může být jediným bodem selhání (SPoF). Pokud chcete minimalizovat dopad selhání, zvažte nasazení redundantních instancí a použití mechanismu automatického škálování k zajištění kapacity a zachování dostupnosti.

Kdy použít tento vzor

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

Zpracováváte citlivé informace.
Zveřejňujete služby, které vyžadují silnou ochranu před škodlivým provozem.
Provádíte klíčové operace, které nemůžou tolerovat přímé vystavení back-endových služeb.
K oddělení od základního obchodního zpracování potřebujete ověření a sanitizaci požadavků.

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

Požadavky na zabezpečení a ověřování můžete splnit prostřednictvím integrovaných ovládacích prvků platformy v back-end službě bez přidání vyhrazené vrstvy gatekeeperu.
Dodatečné síťové skoky a latence validace porušují přísné požadavky na end-to-end latenci.

Návrh úloh

Vyhodnoťte, jak použít model Gatekeeper v návrhu úlohy k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Následující tabulka obsahuje pokyny, jak tento model podporuje cíle jednotlivých pilířů.

Pilíř	Jak tento model podporuje cíle pilíře
Rozhodnutí o návrhu zabezpečení pomáhají zajistit důvěrnost, integritu a dostupnost dat a systémů vaší úlohy.	Řídicí vrstva v toku zpracování požadavku vám pomůže centralizovat bezpečnostní funkce, jako jsou webové aplikační firewally, ochrana před útoky DDoS, detekce botů, úpravy požadavků, zahájení ověřování a kontroly oprávnění. - SE:06 Řízení sítě - SE:10 Monitorování a detekce hrozeb
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.	Tento model můžete použít k implementaci omezování na úrovni vrátného místo implementace kontrol rychlosti na úrovni uzlu. Koordinace stavu rychlosti mezi všemi uzly není ze své podstaty 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

Model Gatekeeper obvykle implementuje vrstvenou cestu požadavku, kde každá vrstva má určitou odpovědnost a omezený obor důvěryhodnosti.

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

V tomto návrhu plní Azure Application Gateway s Azure Web Application Firewall roli vnější brány. Kontroluje internetový provoz a používá bezpečnostní prvky před tím, než provoz dosáhne úrovně rozhraní API. Azure API Management je interní strážce přístupu. Používá ovládací prvky specifické pro rozhraní API a předává jenom schválený provoz na privátní back-endy.

Například Azure Web Application Firewall může detekovat a blokovat injektáž SQL a vzory skriptování mezi weby, vynucovat pravidla protokolu a velikosti požadavků a používat filtrování založené na robotech a IP adresách předtím, než požadavky dosáhnou služby API Management nebo privátní back-endy.

Při použití služby API Management ve vnitřní vrstvě se zásady vztahují na příchozí požadavky a odchozí odpovědi v kanálu brány. Další informace o tom, jak API Management zpracovává požadavky a odpovědi, najdete v tématu Zásady ve službě API Management. Možnosti zásad, jako je ověřování webového tokenu JSON (JWT), omezování rychlosti, transformace hlaviček a tvarování odpovědí, najdete v referenčních informacích k zásadám služby API Management.

V této cestě používejte spravované identity pro prostředky Azure konzistentně pro ověřování mezi službami. Například služba API Management může použít zásadu ověřování pomocí spravované identity k získání tokenů Microsoft Entra pro back-endová volání bez ukládání tajných klíčů.

Back-end zůstává neveřejný. Back-end může být například aplikace Azure App Service, která používá koncový bod private, aby k aplikaci bylo možné přistupovat soukromě.

U kontejnerizovaných úloh může alternativní řešení nahradit službu API Management a vnitřní cestu služby App Service výpočetními prostředky založenými na příchozím přenosu dat:

Azure Kubernetes Service (AKS), což vám dává větší kontrolu nad volbami kontroleru příchozího přenosu dat, zásadami Kubernetes, topologií sítě a provozem clusteru.
Azure Container Apps, což je bezserverová spravovaná kontejnerová platforma, která poskytuje možnosti ingress a snižuje správu infrastruktury.

V těchto alternativách může ingress směrovat podle hostitele nebo cesty, ukončovat TLS a zpřístupňovat pouze interní služby. Konkrétní možnosti, jako jsou limity požadavků a pravidla povolení nebo zamítnutí, závisí na vybrané implementaci příchozího přenosu dat. Ve všech případech zachovejte hranice gatekeeperu: ověřování a vynucování zásad provádějte na vstupu a zajistěte, aby backendové služby byly dostupné pouze prostřednictvím tohoto gatekeeperu.

Každá vrstva v této cestě generuje protokoly a metriky, které byste měli centralizovat. Diagnostické protokoly Azure Web Application Firewall zaznamenávají pro každý požadavek odpovídající a blokovaná pravidla. API Management generuje protokoly brány, které zaznamenávají dobu trvání požadavku, kódy odpovědí a výsledky vyhodnocení zásad. Back-endové služby generují telemetrii na úrovni aplikace. Shromážděte tyto protokoly a metriky v Azure Monitor a nasměrujte je do pracovního prostoru Log Analytics pro jednotné dotazování. Standardizujte korelaci mezi koncovými požadavky generováním nebo předáváním ID korelace na okraji a jeho šířením prostřednictvím služby API Management a back-endových služeb (například prostřednictvím hlaviček požadavků a kontextu distribuovaného trasování), aby jedna transakce zůstala trasovatelná napříč všemi vrstvami. Pomocí Microsoft Defender for Cloud můžete zjistit doporučení zabezpečení napříč komponentami gatekeeperu. Nakonfigurujte upozornění na neobvyklou míru blokování ve službě Azure Web Application Firewall nebo na nárůsty chyb v API Managementu, abyste odhalili hrozby dříve, než se dostanou k privátním backendovým službám.

Další kroky

Při implementaci tohoto modelu můžou být relevantní následující pokyny:

Následující vzory návrhu cloudu se často používají společně s modelem Gatekeeper:

Váš názor

Byla tato stránka užitečná?

Last updated on 2026-06-03