Chraňte aplikace a služby pomocí vyhrazené instance hostitele ke zprostředkování požadavků mezi klienty a aplikací nebo službou. Zprostředkovatel ověří a sanitizuje požadavky a může poskytnout další vrstvu zabezpečení a omezit prostor pro útoky na systém.
Kontext a problém
Cloudové služby zveřejňují koncové body, které klientským aplikacím umožňují volat svá rozhraní API. Kód použitý k implementaci triggerů rozhraní API nebo provádí několik úloh, včetně ověřování, autorizace, ověření parametru a některých nebo všech 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.
Řešení
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ělení můžete dosáhnout pomocí fasády nebo vyhrazené úlohy, která komunikuje s klienty, a pak žádost předá prostřednictvím odděleného rozhraní hostitelům nebo úkolům, které žádost zpracovávají. Obrázek znázorňuje přehled vysoké úrovně tohoto modelu.
Vzor vrátného lze použít k ochraně úložiště, nebo ho lze použít jako komplexnější fasádu k ochraně všech funkcí aplikace. Důležité faktory jsou:
- Ří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 vystavení. Vrátný nemá přístup k přihlašovacím údajům nebo klíčům používaným důvěryhodným hostitelem pro přístup k úložišti a službám. Pokud dojde k ohrožení vrátného, útočník k přihlašovacím údajům nebo klíčům nezíská přístup.
- Náležité 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, který je 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 model funguje jako brána firewall v typické topografii sítě. Umožňuje vrátného zkoumat požadavky a rozhodovat o tom, jestli má požadavek předat důvěryhodnému hostiteli, který provádí požadované úlohy. Toto rozhodnutí obvykle vyžaduje, aby vrátný obsah požadavku před předáním důvěryhodnému hostiteli ověřil a sanitizoval.
Problémy a důležité informace
Když se budete rozhodovat, jak tento model implementovat, měli byste vzít v úvahu následující skutečnosti:
- 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 omezeného oprávnění, který obvykle vyžaduje spuštění vrátného a důvěryhodného hostitele v samostatných hostovaných službách nebo virtuálních počítačích.
- Vrátný by neměl provádět žádné zpracování související s aplikací nebo službami ani přistupovat k žádným datům. Jeho funkcí je jenom ověřit a sanitizovat požadavky. Důvěryhodní hostitelé můžou potřebovat provést další ověření požadavků, ale vrátný by měl provést základní ověření.
- Pokud je to možné, použijte zabezpečený komunikační kanál (HTTPS, SSL nebo TLS) mezi vrátným a důvěryhodnými hostiteli nebo úlohami. 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 dalšímu zpracování a požadované síťové komunikaci.
- Instance vrátného může být kritickým prvkem způsobujícím selhání. Pokud chcete minimalizovat dopad selhání, zvažte nasazení redundantních instancí a použití mechanismu automatického škálování, aby se zajistila kapacita pro zachování dostupnosti.
Kdy se má tento model použít
Tento vzor je užitečný pro aplikace, které:
- zpracování citlivých informací
- zveřejnění služeb, které vyžadují vysokou úroveň ochrany před škodlivými útoky
- provádět klíčové operace, které nelze narušit.
- vyžadování ověření požadavku odděleně od hlavních úloh nebo k centralizaci tohoto ověření za účelem zjednodušení údržby a správy
Návrh úloh
Architekt by měl vyhodnotit způsob použití modelu Gatekeeper v návrhu úloh k řešení cílů a principů popsaných v pilířích architektury Azure Well-Architected Framework. Příklad:
| 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. | Přidání brány do toku požadavků umožňuje centralizovat funkce zabezpečení, jako jsou brány firewall webových aplikací, ochrana před útoky DDoS, detekce robotů, manipulace s požadavky, inicializace ověřování a kontrola autorizace. - SE:06 Řízení sítě - SE:10 Monitorování a detekce hrozeb |
| Efektivita výkonu pomáhá vaší úloze efektivně splňovat požadavky prostřednictvím optimalizací škálování, dat a kódu. | Tento model je způsob, jakým můžete implementovat omezování na úrovni brány a neimplementovat kontroly rychlosti na úrovni uzlu. Koordinace stavu rychlosti mezi všemi uzly není ze své podstaty výkonná. - PE:03 Výběr služeb |
Stejně jako u jakéhokoli rozhodnutí o návrhu zvažte jakékoli kompromisy proti cílům ostatních pilířů, které by mohly být s tímto vzorem zavedeny.
Příklad
Ve scénáři hostovaném v cloudu je možné tento model implementovat oddělením role vrátného nebo virtuálního počítače od důvěryhodných rolí a služeb v aplikaci. Implementace může jako zprostředkující komunikační mechanismus použít interní koncový bod, frontu nebo úložiště. Obrázek znázorňuje použití interního koncového bodu.
Související prostředky
Při implementaci modelu vrátného může být důležitý také model osobního klíče. Při komunikaci mezi gatekeeperem a důvěryhodnými rolemi je vhodné zlepšit zabezpečení pomocí klíčů nebo tokenů, které omezují oprávnění pro přístup k prostředkům. Tento model popisuje použití tokenu nebo klíče, který klientům poskytuje omezený přímý přístup ke konkrétnímu prostředku nebo službě.