Upravit

Omezení komunikace mezi službami

Azure
Microsoft Entra ID
Azure App Service

Tento ukázkový scénář omezuje komunikaci mezi dvěma back-endovými službami Azure na aplikační i síťové vrstvě. Komunikace může proudit pouze mezi službami, které ji explicitně umožňují, a to v souladu se zásadou nejnižších oprávnění. V tomto příkladu se k hostování služeb používá služba Aplikace Azure Service, ale pro aplikace Azure Functions můžete použít podobné techniky.

Omezení komunikace mezi službami jsou pouze jednou částí celkové strategie zabezpečení na základě pečlivého plánování, modelování hrozeb a životního cyklu vývoje zabezpečení. Celkové plánování zabezpečení by mělo zahrnovat obchodní, dodržování předpisů, regulační a další požadavky na nefunkční požadavky.

Potenciální případy použití

I když se aktuální scénář zaměřuje na omezení sítě, řada organizací teď využívá model zabezpečení nulové důvěryhodnosti, který předpokládá porušení zabezpečení, takže síťová vrstva má sekundární důležitost.

Architektura

Diagram showing both network layer and application layer communications restrictions between two Azure App Service backend services.

Stáhněte si soubor Visia této architektury.

Tok dat

Diagram znázorňuje omezenou komunikaci ze služby A do služby B. Autorizace založená na tokenech omezuje přístup na aplikační vrstvě a koncové body služby omezují přístup v síťové vrstvě.

Autorizace založená na tokenech

Knihovna kompatibilní s openID Připojení (OIDC), jako je knihovna MSAL (Microsoft Authentication Library), podporuje tento tok přihlašovacích údajů klienta založený na tokenech. Další informace najdete v tématu Scénář: Aplikace démona, která volá webová rozhraní API , a ukázkovou aplikaci pro scénář démona.

  1. Service A i Service B se registrují v Microsoft Entra ID. Služba A má přihlašovací údaje klienta ve sdíleném tajném kódu nebo formuláři certifikátu.
  2. Služba A může k vyžádání přístupového tokenu pro službu B použít vlastní přihlašovací údaje klienta.
  3. Microsoft Entra ID poskytuje přístupový token s cílovou skupinou služby B nebo deklarací identity aud .
  4. Služba A vloží token jako nosný token do hlavičky AUTORIZACE HTTP požadavku na službu B podle specifikace OAuth 2.0 Nosný token.
  5. Služba B ověří token , aby se zajistilo, že aud deklarace identity odpovídá aplikaci Service B.

Služba B používá jednu z následujících metod k zajištění, že přístup může získat pouze konkrétně povolený klient, service A v tomto případě:

  • Ověřte deklaraci identity appid tokenu. Služba B může ověřit deklaraci identity appid tokenu, která identifikuje, o kterou aplikaci zaregistrovaná Microsoft Entra požádala o token. Služba B explicitně zkontroluje deklaraci identity v seznamu známých volajících řízení přístupu.

  • Zkontrolujte role v tokenu. Podobně služba B může zkontrolovat určité role deklarované v příchozím tokenu, aby služba A měla explicitní přístupová oprávnění.

  • Vyžadovat přiřazení uživatele. Případně může vlastník nebo správce služby B nakonfigurovat ID Microsoft Entra tak, aby vyžadovalo přiřazení uživatele, takže pouze aplikace, které mají explicitní oprávnění k aplikaci Service B, můžou získat token vůči službě B. Služba B pak nemusí kontrolovat konkrétní role, pokud to obchodní logika nevyžaduje.

    Nastavení požadavku na přiřazení uživatele pro přístup ke službě B:

    1. V Microsoft Entra ID povolte přiřazení uživatele ve službě B.
    2. Zveřejnění aspoň jedné role aplikace ve službě B, ke které může služba A požádat o oprávnění. Pole AllowedMemberTypes pro tuto roli musí obsahovat Application.
    3. Požádejte o oprávnění aplikace pro službu A k vystavené roli Služby B.
      1. V části Oprávnění rozhraní API registrace aplikace Service A vyberte Přidat oprávnění a pak ze seznamu vyberte aplikaci Service B.
      2. Na obrazovce Požádat o oprávnění rozhraní API vyberte oprávnění aplikace, protože tato back-endová aplikace běží bez přihlášeného uživatele. Vyberte vystavenou roli Service B a pak vyberte Přidat oprávnění.
    4. Udělte správci souhlas s žádostí o oprávnění aplikace Service A. Žádost o oprávnění služby A může udělit souhlas pouze vlastník nebo správce služby B.

Koncové body služby

Nižší polovina diagramu architektury ukazuje, jak omezit komunikaci mezi službami na síťové vrstvě:

  1. Webová aplikace Service A používá místní integraci virtuální sítě ke směrování veškeré odchozí komunikace přes privátní IP adresu v rozsahu IP podsítě integrace.
  2. Služba B obsahuje koncové body služby, které umožňují příchozí komunikaci pouze z webových aplikací v podsíti integrace služby B.

Další informace najdete v tématu Nastavení omezení přístupu ke službě Aplikace Azure Service.

Součásti

Tento scénář používá následující služby Azure:

  • Aplikace Azure Služba hostuje službu A i službu B, což umožňuje automatické škálování a vysokou dostupnost bez nutnosti spravovat infrastrukturu.
  • Microsoft Entra ID je cloudová služba pro správu identit a přístupu, která ověřuje služby a umožňuje autorizaci na základě tokenů OAuth 2.0.
  • Azure Virtual Network je základním stavebním blokem privátních sítí v Azure. Azure Virtual Network umožňuje prostředkům, jako jsou virtuální počítače Azure, zabezpečeně komunikovat mezi sebou, internetem a místními sítěmi.
  • Koncové body služby Azure poskytují zabezpečené a přímé připojení ke službám Azure přes optimalizovanou trasu v páteřní síti Azure a umožňují přístup pouze z rozsahu IP adres privátních zdrojů v podsíti integrace.
  • Knihovna MSAL (Microsoft Authentication Library) je knihovna kompatibilní s OIDC, která službě umožňuje načíst přístupové tokeny z ID Microsoft Entra pomocí toku přihlašovacích údajů klienta.

Alternativy

Existuje několik alternativ k ukázkovém scénáři.

Spravovaná identita

Místo registrace jako aplikace v Microsoft Entra ID může služba A použít spravovanou identitu k načtení přístupového tokenu. Spravované identity umožňují operátorům spravovat přihlašovací údaje pro registraci aplikace.

Spravovaná identita sice umožňuje službě A načíst token, ale neposkytuje registraci aplikace Microsoft Entra. Aby ostatní služby požadovaly přístupový token pro samotnou službu A, služba A stále potřebuje registraci aplikace Microsoft Entra.

Spravovanou identitu nemůžete přiřadit k roli aplikace prostřednictvím webu Azure Portal, pouze prostřednictvím příkazového řádku Azure PowerShellu. Další informace najdete v tématu Přiřazení přístupu spravované identity k roli aplikace pomocí PowerShellu.

Azure Functions

Služby můžete hostovat ve službě Azure Functions místo služby App Service. Pokud chcete omezit přístup na síťové vrstvě pomocí integrace místní virtuální sítě, musíte hostovat aplikace Functions v plánu služby App Service nebo plánu Premium. Další informace najdete v tématu Možnosti sítě Azure Functions.

Integrované ověřování a autorizace služby App Service

Tento scénář záměrně přiděluje autorizační kód se zbytkem obchodní logiky provedením ověření tokenu v rámci kódu aplikace. Integrované ověřování a autorizace služby App Service nebo Easy Auth může před odesláním žádosti službě také provést základní ověření tokenu. Služba pak spoléhá na infrastrukturu hostování, aby odmítla neoprávněné požadavky.

Pokud chcete nakonfigurovat ověřování a autorizaci služby App Service, nastavte chování autorizace tak, aby se přihlásilo pomocí ID Microsoft Entra. Toto nastavení ověřuje tokeny a omezuje přístup pouze k platným tokenům.

Nevýhodou použití easy Auth je, že služba ztratí ověřování a autorizační ochranu, pokud se přesune jinam. I když ověřování a autorizace služby App Service funguje pro jednoduché scénáře, složité požadavky na autorizaci by měly používat logiku z kódu aplikace.

Koncové body služby vs. privátní koncové body

Tento scénář používá koncové body služby místo privátních koncových bodů, protože pouze koncové body služby umožňují omezit přístup k webové aplikaci z dané podsítě. Filtrování příchozího provozu na privátních koncových bodech se nepodporuje prostřednictvím skupin zabezpečení sítě (NSG) ani pomocí omezení přístupu ke službě App Service. Každá služba se síťovým dohledem může komunikovat s privátním koncovým bodem webové aplikace. Tím se omezí užitečnost privátního koncového bodu pro uzamčení provozu na síťové vrstvě.

Požadavky

  • Integrace místní virtuální sítě služby App Service poskytuje jednu podsíť integrace pro každý plán služby App Service. Všechny webové aplikace ve stejném plánu se integrují se stejnou podsítí a sdílejí stejnou sadu privátních odchozích IP adres. Přijímající služby nemůžou rozlišit, ze které webové aplikace provoz pochází. Pokud potřebujete identifikovat původní webovou aplikaci, musíte webové aplikace nasadit do samostatných plánů služby App Service, z nichž každá má vlastní podsíť integrace.

  • Každá instance pracovního procesu v plánu služby App Service zabírá samostatnou privátní IP adresu v rámci podsítě integrace. Pokud chcete naplánovat škálování, ujistěte se, že je podsíť integrace dostatečně velká, aby vyhovovala očekávanému škálování.

Optimalizace nákladů

Ceny pro tento scénář závisí na konkrétní infrastruktuře a požadavcích. Id Microsoft Entra má v závislosti na potřebách úroveň Free až Premium. Náklady na službu Aplikace Azure Service nebo jiné hostitele se liší podle konkrétních požadavků na škálování a zabezpečení, jak je popsáno v tématu Alternativy a aspekty.

Pokud chcete vypočítat náklady pro váš scénář, podívejte se na cenovou kalkulačku Azure.

Přispěvatelé

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

Hlavní autor:

Další kroky