Poskytnutí vlastního ověřování službě Azure OpenAI prostřednictvím brány

Inteligentní aplikace, které používají službu Azure OpenAI prostřednictvím nativních služeb Azure, poskytují bezproblémové ověřování a autorizaci uživatelů. Některé scénáře jsou ale složité a vyžadují různé návrhy architektury. Mezi tyto scénáře patří topologie, které mají klientské aplikace, které nejsou hostované v Azure, používají externí zprostředkovatele identity a nasazují více klientů, kteří přistupují ke stejným instancím Azure OpenAI. V těchto scénářích může zavedení brány před Azure OpenAI výrazně zlepšit zabezpečení přidáním vrstvy, která zajišťuje konzistentní ověřování nasazených instancí.

Tento článek popisuje klíčové scénáře, které poskytují ověřování pro Azure OpenAI:

• Ověřování klientských aplikací prostřednictvím externího zprostředkovatele identity

• Ověřování klientských aplikací prostřednictvím certifikátů

• Ověřování více klientských aplikací prostřednictvím klíčů pro přístup ke sdílené instanci Azure OpenAI

• Ověřování klientských aplikací, které přistupují k více instancím Azure OpenAI

Každý scénář popisuje výzvy, které zavádějí, a výhody začlenění brány.

Ověřování klientských aplikací prostřednictvím externího zprostředkovatele identity

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

Omezení scénáře

Tento scénář má následující omezení:

• Klientské aplikace používají externího zprostředkovatele identity s podporou OpenID Connect (OIDC), jako je Okta, Auth0 nebo zprostředkovatelé sociálních identit.

• Klientské aplikace se ověřují v tenantovi Microsoft Entra, který se liší od tenanta roviny dat Azure OpenAI.

Tato omezení se můžou vztahovat na následující příklady:

• Existující klientské aplikace, které se již ověřují vůči externímu poskytovateli OIDC nebo ID Microsoft Entra a které se integrují s instancemi Azure OpenAI.

• Klientské aplikace, které musí konzistentně ověřovat uživatele z více zprostředkovatelů identity.

Připojení přímo k Azure OpenAI

Pokud se klientské aplikace v těchto scénářích přímo připojují k Azure OpenAI bez použití brány, musí k ověření ve službě Azure OpenAI použít ověřování na základě klíčů. Ověřování založené na klíčích přináší další obavy týkající se zabezpečení. Klíče musíte bezpečně ukládat a otáčet a nemůžete udělit různým klientům konfigurace řízení přístupu na základě role (RBAC) pro jednotlivá nasazení modelu.

Zavedení brány

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

Brána řeší problémy tohoto scénáře následujícími způsoby:

• Brána používá open authorization (OAuth) k ověřování uživatelů prostřednictvím stávajících externích zprostředkovatelů identity. Brána ověří ověřené přístupové tokeny uživatelů, jako je například webový token JSON (JWT), který vygeneruje zprostředkovatel identity. Brána pak udělí autorizaci k backingové instanci Azure OpenAI.

• Nemusíte spravovat klíče klienta. Tento přístup eliminuje rizika zabezpečení ověřování založeného na klíčích.

• Brána se připojí k Azure OpenAI pomocí spravované identity, která zlepšuje zabezpečení prostřednictvím azure RBAC s nejnižšími oprávněními.

Doporučení pro tento scénář

• Přidejte do registrace vaší aplikace ve zprostředkovateli identity další obory OAuth, abyste uživatelům umožnili podrobná oprávnění. Tyto obory umožňují klientským aplikacím požadovat oprávnění k provádění konkrétních operací ve vaší bráně, včetně přístupu k Azure OpenAI.

• Tento scénář nakonfigurujte pro službu API Management pomocí příchozích zásad. validate-jwt Pomocí zásad vynucujte hodnoty existence, platnosti a atributu podporovaného JWT.

Důvody, proč se v tomto scénáři vyhnout bráně

Pokud jedna inteligentní aplikace přistupuje k Azure OpenAI, je jednodušší nakonfigurovat ověřování a autorizaci uživatelů v rámci aplikace, a ne prostřednictvím brány. Tento přístup použijte k přiřazení nezbytného Azure RBAC k bezpečnému ověření inteligentní aplikace pomocí Azure OpenAI.

Ověřování klientských aplikací prostřednictvím certifikátů

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

Omezení scénáře

Tento scénář má následující omezení:

• K ověřování klientských aplikací chcete použít certifikáty.

• Klientské aplikace nemůžou používat nebo nechcete používat, Microsoft Entra ID ani jiné zprostředkovatele OIDC k ověřování.

• Klienti nemůžou používat nebo nechcete používat federovanou identitu pro ověřování.

Tato omezení se můžou vztahovat na následující příklady:

• Klient, který se ověřuje v Azure OpenAI, je počítač nebo zařízení a nedojde k žádné interakci uživatele.

• Vaše organizace vyžaduje, abyste k ověřování používali certifikáty kvůli standardům zabezpečení a předpisům dodržování předpisů.

• Chcete poskytnout více klientských aplikací s možnostmi ověřování na základě jejich prostředí, včetně použití klientských certifikátů.

Připojení přímo k Azure OpenAI

Azure OpenAI nativně nepodporuje ověřování certifikace klientů. Aby bylo možné tento scénář podporovat bez brány, musí inteligentní aplikace k ověřování požadavků na instanci Azure OpenAI použít ověřování certifikátů pro uživatele a klíč rozhraní API nebo spravovanou identitu. Logiku ověřování certifikátu musíte implementovat v každém klientovi. V tomto scénáři představuje ověřování na základě klíčů rizika a režijní náklady na správu, pokud se z klientů připojujete přímo k Azure OpenAI.

Zavedení brány

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

Bránu můžete zavést do této architektury, která přesměruje ověření certifikace klienta z klientů. Brána ověří klientský digitální certifikát , že inteligentní aplikace prezentuje a kontroluje vystavitele, datum vypršení platnosti, kryptografický otisk a seznamy odvolaných certifikátů. Brána by měla používat spravovanou identitu k ověření pomocí Azure OpenAI. Brána by také měla používat Azure Key Vault k uložení kořenové certifikační autority (CA). Tento přístup použijte k centralizaci ověřování klientských certifikátů, což snižuje režijní náklady na údržbu.

Brána nabízí v tomto scénáři několik výhod:

• Spravovanou identitu brány používáte místo přístupových klíčů, což eliminuje riziko odcizení klíčů a snižuje zatížení údržby obměny klíčů.

• Můžete centralizovat ověřování certifikátů, což zajistí, že použijete konzistentní zásady zabezpečení k vyhodnocení digitálních certifikátů klientů pro všechny inteligentní aplikace.

• Ověření certifikátu můžete přesměrovat na bránu, což zjednodušuje klientský kód.

Doporučení pro tento scénář

• Při ověřování certifikátů ověřte celý řetěz certifikátů, včetně kořenové certifikační autority a zprostředkujících certifikátů. Úplné ověření zajišťuje pravost certifikátu a zabraňuje neoprávněnému přístupu.

• Pravidelně obměňujte a obnovujte klientské certifikáty, abyste minimalizovali riziko ohrožení zabezpečení certifikátů. Pomocí služby Key Vault můžete tento proces automatizovat a udržovat certifikáty aktuální. Nastavte upozornění na nadcházející vypršení platnosti certifikátů, abyste zabránili přerušení služeb v bráně.

• Implementujte vzájemné zabezpečení vrstvy (mTLS), abyste zajistili, že se klient i server vzájemně ověřují. Tato strategie poskytuje další vrstvu zabezpečení. Pokud chcete bránu nakonfigurovat tak, aby vynucuje mTLS, nastavte příslušné zásady a omezení.

• Pomocí zásad ve službě validate-client-certificate API Management ověřte klientské certifikáty, na které odkazuje trezor klíčů Azure. Tato zásada ověří klientský certifikát, který klientská aplikace prezentuje a kontroluje vystavitele, datum vypršení platnosti, kryptografický otisk a seznamy odvolaných certifikátů.

Důvody, proč se v tomto scénáři vyhnout bráně

V jednoduchých prostředích, která mají několik klientů, můžou náklady na zpracování správy zabezpečení a certifikátů v klientovi převažovat nad přidanou složitostí zavedení brány. Brány se také můžou stát kritickými body selhání, zvýšit latenci kvůli přidaným vrstvám a vést k uzamčení dodavatele, pokud místo vlastních implementací zvolíte komerční řešení.

Před implementací brány pro ověřování klientským certifikátem musíte pečlivě posoudit konkrétní potřeby, dostupnost prostředků a důležitost aplikací.

Ověřování více klientských aplikací prostřednictvím klíčů pro přístup ke sdílené instanci Azure OpenAI

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

Omezení scénáře

Tento scénář má následující omezení:

• Několik klientských aplikací přistupuje ke sdílené instanci Azure OpenAI.
• Klienti nemůžou použít nebo nechcete používat ID Microsoft Entra pro ověřování.
• Klienti nemůžou používat nebo nechcete používat federovanou identitu pro ověřování.
• Pro klientské aplikace chcete použít ověřování založené na klíčích.

Tato omezení se můžou vztahovat na následující příklady:

• Klientské aplikace nasazujete napříč několika prostředími, včetně Azure, místních nebo jiných poskytovatelů cloudu.

• Organizace musí poskytnout Azure OpenAI různým týmům a nastavit jedinečné limity přístupu a využití pro každý tým.

Připojení přímo k Azure OpenAI

Azure OpenAI podporuje ověřování na základě klíčů prostřednictvím sdílených klíčů. Azure OpenAI zveřejňuje primární klíč a sekundární klíč. Účelem sekundárního klíče je podpora obměně klíčů. Neposkytuje izolaci identity klienta. Když v tomto scénáři ověříte více klientů přímo ve službě Azure OpenAI, každý klient sdílí stejný klíč. Tato implementace má následující výzvy:

• Oprávnění pro konkrétní klienty nemůžete odvolat, protože každý klient sdílí stejný klíč.

• V nasazení instance Azure OpenAI nemůžete různým klientům udělit různá přístupová práva k různým modelům.

• Jednoho klienta nemůžete odlišit od druhého z hlediska protokolování.

Zavedení brány

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

Bránu můžete zavést do této architektury, která vydává vyhrazený klíč pro každou klientskou aplikaci. Služba API Management používá koncept předplatných k poskytování vyhrazených klientských klíčů. Brána by měla používat spravovanou identitu k ověření pomocí Azure OpenAI.

Brána nabízí v tomto scénáři několik výhod:

• Přístup k jedné klientské aplikaci můžete odvolat, aniž by to mělo vliv na ostatní klienty.

• Před otočením klíčů nemusíte aktualizovat všechny konfigurace klíčů klienta, takže obměna klíčů je logisticky jednodušší. Po aktualizaci konfigurace klienta můžete obměňovat vyhrazené klíče pro každého klienta.

• Jednotlivé klienty můžete jednoznačně identifikovat z pohledu protokolování.

• Brána vynucuje limity rychlosti a kvóty pro každého klienta nezávisle.

Doporučení pro tento scénář

• Vylepšení monitorování metrik souvisejících s požadavky rozhraní API Při použití spravované identity z brány se sledovatelnost uživatele a klientské aplikace v protokolech Azure OpenAI nezlepší. Brána by měla poskytovat protokolování přidružené k požadavku, jako jsou id klienta a uživatele.

• Ujistěte se, že brána provádí rozhodnutí o směrování odpovídajících nasazení modelu na základě identity klienta při směrování více požadavků klientské aplikace přes bránu do sdílené instance Azure OpenAI. Další informace najdete v tématu Použití brány před několika nasazeními Azure OpenAI.

Ověřování klientských aplikací, které přistupují k více instancím Azure OpenAI

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

Omezení scénáře

Tento scénář má následující omezení:

• Klientské aplikace se připojují k několika instancím Azure OpenAI v jedné nebo více oblastech.
• Klienti nemůžou použít nebo nechcete používat, Microsoft Entra ID nebo jiné zprostředkovatele OIDC k ověřování.
• Pro klientské aplikace chcete použít ověřování založené na klíčích.

Tato omezení se můžou vztahovat na následující příklady:

• Klientské aplikace musí distribuovat své úlohy geograficky, aby se snížila latence a zlepšil výkon.

• Klientské aplikace se pokoušejí optimalizovat kvóty tokenů za minutu nasazením instancí napříč několika oblastmi.

• Organizace vyžaduje bezproblémové převzetí služeb při selhání a zotavení po havárii k zajištění nepřetržitého provozu. Proto spravují strategii duálního nasazení, například strategii, která se skládá z zřízeného nasazení propustnosti a průběžného nasazení.

• Klientské aplikace musí používat specifické funkce modelu, které jsou dostupné jenom v určitých oblastech Azure.

Přímé připojení k několika instancím Azure OpenAI

Když se klientské aplikace připojují přímo k více instancím Azure OpenAI, musí každý klient uložit klíč pro každou instanci. Spolu s aspekty zabezpečení při používání klíčů existuje zvýšená zátěž správy týkající se obměny klíčů.

Zavedení brány

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

Když používáte bránu ke zpracování klientských aplikací, které přistupují k více nasazením Azure OpenAI, získáte stejné výhody jako brána, která zpracovává více klientských aplikací prostřednictvím klíčů pro přístup ke sdílené instanci Azure OpenAI. Proces ověřování také zjednodušíte, protože k ověřování požadavků z brány do několika instancí Azure OpenAI používáte jednu spravovanou identitu definovanou uživatelem. Implementujte tento přístup, abyste snížili celkovou provozní režii a minimalizovali rizika chybné konfigurace klienta při práci s více instancemi.

Doporučení pro tento scénář

• Implementujte techniky vyrovnávání zatížení pro distribuci požadavků rozhraní API napříč několika instancemi Azure OpenAI za účelem zpracování vysokého provozu a zajištění vysoké dostupnosti. Další informace najdete v tématu Použití brány před několika nasazeními nebo instancemi Azure OpenAI.

• Korelace využití tokenů pro každého tenanta v bráně při implementaci scénářů s více tenanty s několika instancemi Azure OpenAI Tento přístup zajišťuje, že budete sledovat celkové využití tokenů bez ohledu na instanci Azure OpenAI back-endu, na kterou se požadavek předá.

Obecná doporučení

Když integrujete Azure OpenAI prostřednictvím brány, existuje několik doporučení, která je potřeba zvážit ve všech scénářích.

Místo vytváření vlastního řešení pro efektivní orchestraci rozhraní API používejte službu API Management, bezproblémovou integraci s jinými službami Azure a úspory nákladů snížením úsilí o vývoj a údržbu. SLUŽBA API Management zajišťuje zabezpečenou správu rozhraní API přímo podporující ověřování a autorizaci. Integruje se s zprostředkovateli identity, jako je Id Microsoft Entra, které umožňuje OAuth 2.0 a poskytuje autorizaci založenou na zásadách. Kromě toho služba API Management používá spravované identity k zabezpečení a přístupu s nízkou údržbou k Azure OpenAI.

Kombinování scénářů pro komplexní řešení brány

V reálných aplikacích můžou vaše případy použití zahrnovat více scénářů z tohoto článku. Můžete mít například klientské aplikace, které se ověřují prostřednictvím externího zprostředkovatele identity a vyžadují přístup k více instancím Azure OpenAI.

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

Pokud chcete vytvořit bránu, která podporuje vaše konkrétní požadavky, zkombinujte doporučení z těchto scénářů pro komplexní přístup.

Vynucení zásad brány

Před odesláním požadavků do instancí Azure OpenAI se ujistěte, že vynucujete příchozí ověřování a zásady autorizace. Pokud chcete zajistit, aby brána předávala jenom ověřené a autorizované požadavky, použijte k implementaci tohoto přístupu přístup pomocí přístupových tokenů uživatele od zprostředkovatele identity nebo ověření certifikátu.

Pokud chcete povolit podrobné řízení, implementujte více oboru autorizace s rolemi a oprávněními pro klientské aplikace ve vaší bráně. Pomocí těchto oborů můžete povolit konkrétní operace na základě potřeb klientské aplikace. Tento přístup zlepšuje zabezpečení a možnosti správy.

Pro ověření přístupového tokenu nezapomeňte ověřit všechny registrované deklarace klíčů, jako issjsou , expauda nbf všechny relevantní deklarace identity specifické pro úlohy, jako jsou členství ve skupinách nebo aplikační role.

Použití spravovaných identit Azure

Pokud chcete zjednodušit ověřování ve všech scénářích klientských aplikací, využijte spravované identity Azure k centralizaci správy ověřování. Tento přístup snižuje složitost a rizika spojená se správou více klíčů rozhraní API nebo přihlašovacích údajů v klientských aplikacích.

Spravované identity ze své podstaty podporují Azure RBAC, takže zajišťují, že brána má pouze nejnižší úroveň oprávnění potřebná pro přístup k instancím Azure OpenAI. Pokud chcete snížit riziko neoprávněného přístupu a zjednodušit dodržování zásad zabezpečení, zkombinujte spravované identity s jinými metodami, které zakazují alternativní ověřování.

Implementace komplexní pozorovatelnosti

Když implementujete bránu se spravovanou identitou, sníží se sledovatelnost, protože spravovaná identita představuje samotnou bránu, ne uživatele nebo aplikaci, která požadavek provede. Proto je nezbytné zlepšit pozorovatelnost metrik, které souvisejí s požadavky rozhraní API. Aby se zachoval přehled o vzorech přístupu a využití, měly by brány poskytovat další metadata trasování, jako jsou například požadovaná ID klienta a uživatelů.

Centralizované protokolování všech požadavků, které procházejí bránou, pomáhá udržovat záznam auditu. Centralizovaný záznam auditu je zvlášť důležitý pro řešení potíží, dodržování předpisů a zjišťování pokusů o neoprávněný přístup.

Implementace brány

Azure neposkytuje řešení na klíč ani referenční architekturu pro sestavení brány v tomto článku, takže musíte bránu sestavit a provozovat. Azure poskytuje příklady implementací podporovaných komunitou, které se týkají případů použití v tomto článku. Na tyto ukázky se můžete odkazovat při vytváření vlastního řešení brány. Další informace najdete ve videu Learn Live: Identita a zabezpečení aplikací Azure OpenAI.

Přispěvatelé

Tento článek původně napsali následující přispěvatelé.

Hlavní autoři:

• Lizet Pena De Sola | Vedoucí zákaznický inženýr, FastTrack pro Azure
• Bappaditya Banerjee | Vedoucí zákaznický inženýr, FastTrack pro Azure
• James Croft | Customer Engineer, ISV & Digital Native Center of Excellence

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

Další kroky

• RBAC pro Azure OpenAI
• Použití spravovaných identit ve službě API Management
• Zásady ve službě API Management
• Ověřování a autorizace pro rozhraní API ve službě API Management
• Ochrana rozhraní API ve službě API Management pomocí OAuth 2.0 a ID Microsoft Entra
• Zabezpečení back-endových služeb pomocí ověřování klientských certifikátů ve službě API Management

Související prostředky

• Přístup k Azure OpenAI a dalším jazykovým modelům prostřednictvím brány