Intelligenta program som använder Azure OpenAI-tjänsten via Azure-inbyggda tjänster ger sömlös användarautentisering och auktorisering. Vissa scenarier är dock komplexa och kräver olika arkitekturdesign. Dessa scenarier omfattar topologier som har klientprogram som inte finns i Azure, använder externa identitetsprovidrar och distribuerar flera klienter som har åtkomst till samma Azure OpenAI-instanser. I dessa scenarier kan införandet av en gateway framför Azure OpenAI avsevärt förbättra säkerheten genom att lägga till ett lager som säkerställer konsekvent autentisering till distribuerade instanser.
Den här artikeln beskriver viktiga scenarier som tillhandahåller autentisering till Azure OpenAI:
Autentisera flera klientprogram via nycklar för att få åtkomst till en delad Azure OpenAI-instans
Autentisera klientprogram som har åtkomst till flera Azure OpenAI-instanser
Varje scenario beskriver de utmaningar som de medför och fördelarna med att införliva en gateway.
Viktigt!
Du kan använda följande vägledning för alla gatewayimplementeringar, inklusive Azure API Management. För att illustrera den här flexibiliteten använder arkitekturdiagrammen allmänna representationer av komponenter i de flesta scenarier.
Autentisera klientprogram via en extern identitetsprovider
Ladda ned en Visio-fil med den här arkitekturen.
Scenariobegränsningar
Det här scenariot har följande begränsningar:
Klientprogram använder en extern OpenID Connect-aktiverad identitetsprovider (OIDC), till exempel Okta, Auth0 eller sociala identitetsprovidrar.
Klientprogram autentiseras mot en Microsoft Entra-klientorganisation som skiljer sig från Azure OpenAI-dataplanets klientorganisation.
Dessa begränsningar kan gälla för följande exempel:
Befintliga klientprogram som redan autentiserar mot en extern OIDC-provider eller Microsoft Entra-ID och som integreras med Azure OpenAI-instanser.
Klientprogram som konsekvent måste autentisera användare från flera identitetsprovidrar.
Ansluta direkt till Azure OpenAI
Om klientprogrammen i dessa scenarier ansluter direkt till Azure OpenAI utan att använda en gateway måste de använda nyckelbaserad autentisering för att autentisera till Azure OpenAI. Nyckelbaserad autentisering medför extra säkerhetsproblem. Du måste lagra och rotera nycklar på ett säkert sätt och du kan inte ge olika klienter rollbaserade åtkomstkontrollkonfigurationer (RBAC) för enskilda modelldistributioner.
Introducera en gateway
Ladda ned en Visio-fil med den här arkitekturen.
En gateway löser det här scenariots utmaningar på följande sätt:
Gatewayen använder OAuth (Open Authorization) för att autentisera användare via sina befintliga externa identitetsprovidrar. Gatewayen verifierar de autentiserade användaråtkomsttoken, till exempel en JSON-webbtoken (JWT), som identitetsprovidern genererar. Sedan beviljar gatewayen auktorisering till azure OpenAI-instansen.
Du behöver inte hantera klientnycklar. Den här metoden eliminerar säkerhetsriskerna med nyckelbaserad autentisering.
Gatewayen ansluter till Azure OpenAI med hjälp av en hanterad identitet, vilket förbättrar säkerheten via minst privilegierade Azure RBAC.
Rekommendationer för det här scenariot
Lägg till fler OAuth-omfång i programregistreringen i identitetsprovidern för att aktivera detaljerad behörighet för konsumenter. Dessa omfång gör det möjligt för klientprogram att begära behörighet att utföra specifika åtgärder i din gateway, inklusive åtkomst till Azure OpenAI.
Konfigurera det här scenariot för API Management med hjälp av inkommande principer. Använd principen
validate-jwtför att framtvinga existens-, giltighets- och attributvärden för en JWT som stöds.
Orsaker till att undvika en gateway för det här scenariot
Om ett enda intelligent program har åtkomst till Azure OpenAI är det enklare att konfigurera användarautentisering och auktorisering i appen i stället för via gatewayen. Använd den här metoden för att tilldela nödvändiga Azure RBAC för att på ett säkert sätt autentisera det intelligenta programmet med Azure OpenAI.
Autentisera klientprogram via certifikat
Ladda ned en Visio-fil med den här arkitekturen.
Scenariobegränsningar
Det här scenariot har följande begränsningar:
Du vill använda certifikat för att autentisera klientprogram.
Klientprogram kan inte använda, eller så vill du inte använda, Microsoft Entra-ID eller andra OIDC-leverantörer för autentisering.
Klienter kan inte använda, eller så vill du inte använda, federerad identitet för autentisering.
Dessa begränsningar kan gälla för följande exempel:
En klient som autentiserar till Azure OpenAI är en dator eller enhet och ingen användarinteraktion sker.
Din organisation kräver att du använder certifikat för autentisering på grund av säkerhetsstandarder och efterlevnadsregler.
Du vill ge flera klientprogram alternativ för att autentisera baserat på deras miljö, inklusive användning av klientcertifikat.
Ansluta direkt till Azure OpenAI
Azure OpenAI har inte inbyggt stöd för klientcertifieringsautentisering. För att stödja det här scenariot utan en gateway måste det intelligenta programmet använda certifikatautentisering för användaren och antingen en API-nyckel eller hanterad identitet för att autentisera begäranden till Azure OpenAI-instansen. Du måste implementera logiken för certifikatautentisering i varje klient. I det här scenariot medför nyckelbaserad autentisering risker och hanteringskostnader om du ansluter direkt till Azure OpenAI från klienter.
Introducera en gateway
Ladda ned en Visio-fil med den här arkitekturen.
Du kan introducera en gateway i den här arkitekturen som avlastar klientcertifieringsvalidering från klienterna. Gatewayen validerar det digitala klientcertifikat som det intelligenta programmet presenterar och kontrollerar utfärdaren, utgångsdatum, tumavtryck och återkallningslistor. Gatewayen bör använda en hanterad identitet för att autentisera sig själv med Azure OpenAI. Gatewayen bör också använda Azure Key Vault för att lagra rotcertifikatutfärdare (CA). Använd den här metoden för att centralisera validering av klientcertifikat, vilket minskar underhållskostnaderna.
En gateway ger flera fördelar i det här scenariot:
Du använder gatewayens hanterade identitet i stället för åtkomstnycklar, vilket eliminerar risken för stulna nycklar och minskar underhållsbelastningen för nyckelrotation.
Du kan centralisera certifikatverifiering, vilket säkerställer att du använder konsekventa säkerhetsprinciper för att utvärdera digitala klientcertifikat för alla intelligenta program.
Du kan avlasta certifikatverifieringen till gatewayen, vilket förenklar klientkoden.
Rekommendationer för det här scenariot
Kontrollera hela certifikatkedjan, inklusive rotcertifikatutfärdare och mellanliggande certifikat, när du validerar certifikat. Fullständig verifiering säkerställer certifikatets äkthet och förhindrar obehörig åtkomst.
Rotera och förnya klientcertifikat regelbundet för att minimera risken för att certifikatet komprometteras. Använd Key Vault för att automatisera den här processen och hålla certifikaten uppdaterade. Ställ in aviseringar för kommande förfallodatum för certifikat för att förhindra tjänststörningar på gatewayen.
Implementera ömsesidig transportnivåsäkerhet (mTLS) för att säkerställa att både klienten och servern autentiserar varandra. Den här strategin ger ett extra säkerhetslager. Om du vill konfigurera gatewayen för att framtvinga mTLS anger du lämpliga principer och begränsningar.
validate-client-certificateAnvänd principen i API Management för att verifiera klientcertifikat som ett Azure-nyckelvalv refererar till. Den här principen verifierar klientcertifikatet som klientprogrammet visar och kontrollerar utfärdaren, förfallodatum, tumavtryck och återkallningslistor.
Orsaker till att undvika en gateway för det här scenariot
I enkla miljöer med få klienter kan kostnaden för hantering av säkerhet och certifikathantering i klienten uppväga den extra komplexiteten med att introducera en gateway. Dessutom kan gatewayer bli enstaka felpunkter, öka svarstiden på grund av tillagda lager och leda till leverantörslåsning om du väljer kommersiella lösningar i stället för anpassade implementeringar.
Du måste noggrant utvärdera dina specifika behov, resurstillgänglighet och kritiskhet för dina program innan du implementerar en gateway för klientcertifikatautentisering.
Autentisera flera klientprogram via nycklar för att få åtkomst till en delad Azure OpenAI-instans
Ladda ned en Visio-fil med den här arkitekturen.
Scenariobegränsningar
Det här scenariot har följande begränsningar:
- Flera klientprogram har åtkomst till en delad Azure OpenAI-instans.
- Klienter kan inte använda, eller så vill du inte använda, Microsoft Entra-ID för autentisering.
- Klienter kan inte använda, eller så vill du inte använda, federerad identitet för autentisering.
- Du vill använda nyckelbaserad autentisering för klientprogram.
Dessa begränsningar kan gälla för följande exempel:
Du distribuerar klientprogram i flera miljöer, inklusive Azure, lokalt eller andra molnleverantörer.
En organisation måste tillhandahålla Azure OpenAI till olika team och ange unika åtkomst- och användningsgränser för varje team.
Ansluta direkt till Azure OpenAI
Azure OpenAI stöder nyckelbaserad autentisering via delade nycklar. Azure OpenAI exponerar en primärnyckel och en sekundär nyckel. Syftet med den sekundära nyckeln är att stödja nyckelrotation. Den tillhandahåller inte klientidentitetsisolering. När du autentiserar flera klienter direkt till Azure OpenAI i det här scenariot delar varje klient samma nyckel. Den här implementeringen har följande utmaningar:
Du kan inte återkalla behörigheter för specifika klienter eftersom varje klient delar samma nyckel.
Du kan inte ge olika klienter olika åtkomsträttigheter till olika modeller i samma Azure OpenAI-instansdistribution.
Du kan inte skilja en klient från en annan från ett loggningsperspektiv.
Introducera en gateway
Ladda ned en Visio-fil med den här arkitekturen.
Du kan introducera en gateway i den här arkitekturen som utfärdar en dedikerad nyckel till varje klientprogram. API Management använder begreppet prenumerationer för att tillhandahålla dedikerade klientnycklar. Gatewayen bör använda en hanterad identitet för att autentisera sig själv med Azure OpenAI.
En gateway ger flera fördelar i det här scenariot:
Du kan återkalla åtkomsten till ett enda klientprogram utan att påverka andra klienter.
Du behöver inte uppdatera alla klientens nyckelkonfigurationer innan du roterar nycklar, så nyckelrotationen är logistiskt enklare. Du kan rotera de dedikerade nycklarna för varje klient när du har uppdaterat klientkonfigurationen.
Du kan identifiera varje klient unikt ur ett loggningsperspektiv.
Gatewayen tillämpar hastighetsgränser och kvoter för varje klient oberoende av varandra.
Rekommendationer för det här scenariot
Förbättra övervakningen av mått som är relaterade till API-begäranden. När du använder en hanterad identitet från en gateway förbättras inte spårningen av användar- och klientprogrammet i Azure OpenAI-loggarna. Gatewayen bör tillhandahålla loggning som är associerad med begäran, till exempel de begärande klient- och användar-ID:t.
Se till att gatewayen fattar routningsbeslut till lämpliga modelldistributioner baserat på klientidentiteten när du dirigerar flera klientprogrambegäranden via en gateway till en delad Azure OpenAI-instans. Mer information finns i Använda en gateway framför flera Azure OpenAI-distributioner.
Autentisera klientprogram som har åtkomst till flera Azure OpenAI-instanser
Ladda ned en Visio-fil med den här arkitekturen.
Scenariobegränsningar
Det här scenariot har följande begränsningar:
- Klientprogram ansluter till flera Azure OpenAI-instanser i en eller flera regioner.
- Klienter kan inte använda, eller så vill du inte använda, Microsoft Entra-ID eller andra OIDC-leverantörer för autentisering.
- Du vill använda nyckelbaserad autentisering för klientprogram.
Dessa begränsningar kan gälla för följande exempel:
Klientprogram måste distribuera sina arbetsbelastningar geografiskt för att minska svarstiden och förbättra prestanda.
Klientprogram försöker optimera sina token per minut-kvoter genom att distribuera instanser i flera regioner.
En organisation kräver sömlös redundans och haveriberedskap för att säkerställa kontinuerlig drift. De hanterar därför en strategi för dubbel distribution, till exempel en strategi som består av en etablerad distribution av dataflöde och en distribution med betala per användning.
Klientprogram måste använda specifika modellfunktioner som endast är tillgängliga i vissa Azure-regioner.
Ansluta direkt till flera Azure OpenAI-instanser
När klientprogram ansluter direkt till flera Azure OpenAI-instanser måste varje klient lagra nyckeln för varje instans. Tillsammans med säkerhetsövervägandena med att använda nycklar finns det en ökad hanteringsbörda när det gäller roterande nycklar.
Introducera en gateway
Ladda ned en Visio-fil med den här arkitekturen.
När du använder en gateway för att hantera klientprogram som har åtkomst till flera Azure OpenAI-distributioner får du samma fördelar som en gateway som hanterar flera klientprogram via nycklar för att få åtkomst till en delad Azure OpenAI-instans. Du effektiviserar också autentiseringsprocessen eftersom du använder en enda användardefinierad hanterad identitet för att autentisera begäranden från gatewayen till flera Azure OpenAI-instanser. Implementera den här metoden för att minska den totala driftbelastningen och minimera risken för felkonfiguration av klienter när du arbetar med flera instanser.
Ett exempel på hur en gateway används i Azure för att avlasta identitet till en mellanhand är Azure AI Services-resursen. I den implementeringen autentiserar du till gatewayen och gatewayen hanterar autentisering till de olika Azure AI-tjänsterna, till exempel Custom Vision eller Speech. Även om implementeringen liknar den tar den inte upp det här scenariot.
Rekommendationer för det här scenariot
Implementera belastningsutjämningstekniker för att distribuera API-begäranden över flera instanser av Azure OpenAI för att hantera hög trafik och säkerställa hög tillgänglighet. Mer information finns i Använda en gateway framför flera Azure OpenAI-distributioner eller instanser.
Korrelera tokenanvändningen för varje klientorganisation i gatewayen när du implementerar scenarier med flera Azure OpenAI-instanser. Den här metoden säkerställer att du spårar total tokenanvändning, oavsett vilken Azure OpenAI-instans i serverdelen som begäran vidarebefordras till.
Allmänna rekommendationer
När du integrerar Azure OpenAI via en gateway finns det flera övergripande rekommendationer att tänka på som gäller i alla scenarier.
Använd Azure API Management i stället för att skapa en egen lösning för effektiv API-orkestrering, sömlös integrering med andra Azure-tjänster och kostnadsbesparingar genom att minska utvecklings- och underhållsinsatserna. API Management säkerställer säker API-hantering genom direkt stöd för autentisering och auktorisering. Den integreras med identitetsprovidrar, till exempel Microsoft Entra-ID, som möjliggör OAuth 2.0 och ger principbaserad auktorisering. Dessutom använder API Management hanterade identiteter för säker och låg underhållsåtkomst till Azure OpenAI.
Kombinera scenarier för en omfattande gatewaylösning
I verkliga program kan dina användningsfall omfatta flera scenarier från den här artikeln. Du kan till exempel ha klientprogram som autentiserar via en extern identitetsprovider och kräver åtkomst till flera Azure OpenAI-instanser.
Ladda ned en Visio-fil med den här arkitekturen.
Om du vill skapa en gateway som stöder dina specifika krav kombinerar du rekommendationerna från dessa scenarier för en omfattande metod.
Framtvinga gatewayprinciper
Innan en gateway skickar begäranden till Azure OpenAI-instanser kontrollerar du att du tillämpar principer för inkommande autentisering och auktorisering. För att säkerställa att gatewayen endast vidarebefordrar autentiserade och auktoriserade begäranden använder du användaråtkomsttoken från en identitetsprovider eller certifikatverifiering för att implementera den här metoden.
Om du vill aktivera detaljerad kontroll implementerar du mer auktoriseringsomfång med roller och behörigheter för klientprogram i din gateway. Använd dessa omfång för att tillåta specifika åtgärder baserat på klientprogrammets behov. Den här metoden förbättrar säkerheten och hanterbarheten.
För validering av åtkomsttoken kontrollerar du alla nyckelregistrerade anspråk, till exempel iss, aud, expoch nbf eventuella relevanta arbetsbelastningsspecifika anspråk, till exempel gruppmedlemskap eller programroller.
Använda hanterade Azure-identiteter
För att förenkla autentiseringen i alla klientprogramscenarier använder du Hanterade Azure-identiteter för att centralisera autentiseringshantering. Den här metoden minskar komplexiteten och riskerna med att hantera flera API-nycklar eller autentiseringsuppgifter i klientprogram.
Hanterade identiteter har i sig stöd för Azure RBAC, så de ser till att gatewayen bara har den lägsta behörighetsnivån som krävs för att få åtkomst till Azure OpenAI-instanser. Om du vill minska risken för obehörig åtkomst och förenkla efterlevnaden av säkerhetsprinciper kombinerar du hanterade identiteter med andra metoder som inaktiverar alternativ autentisering.
Implementera omfattande observerbarhet
När du implementerar en gateway med en hanterad identitet minskar spårningsbarheten eftersom den hanterade identiteten representerar själva gatewayen, inte användaren eller programmet som skickar begäran. Därför är det viktigt att förbättra observerbarheten för mått som är relaterade till API-begäranden. För att hålla insyn i åtkomstmönster och användning bör gatewayer tillhandahålla mer spårningsmetadata, till exempel de begärande klient- och användar-ID:t.
Centraliserad loggning av alla begäranden som passerar via gatewayen hjälper dig att upprätthålla en spårningslogg. En centraliserad spårningslogg är särskilt viktig för felsökning, efterlevnad och identifiering av obehöriga åtkomstförsök.
Hantera cachelagring på ett säkert sätt
Om din API-gateway ansvarar för slutförande av cachelagring eller andra slutsatsdragningsresultat kontrollerar du att begärandegivarens identitet beaktas i cachelogik. Returnera inte cachelagrade resultat för identiteter som inte har behörighet att ta emot dessa data.
Gatewayimplementeringar
Azure tillhandahåller inte någon komplett nyckelfärdig lösning eller referensarkitektur för att skapa gatewayen i den här artikeln, så du måste skapa och använda gatewayen. Azure API-hantering kan användas för att skapa en PaaS-baserad lösning via inbyggda och anpassade principer. Azure innehåller också exempel på implementeringar som stöds av communityn och som täcker användningsfallen i den här artikeln. Referera till de här exemplen när du skapar en egen gatewaylösning. Mer information finns i videon Learn Live: Azure OpenAI-programidentitet och -säkerhet.
Deltagare
Följande deltagare skrev ursprungligen den här artikeln.
Huvudsakliga författare:
- Lizet Pena De Sola | Senior kundtekniker, FastTrack för Azure
- Bappaditya Banerjee | Senior kundtekniker, FastTrack för Azure
- James Croft | Kundtekniker, ISV och Digital Native Center of Excellence
Om du vill se linkedin-profiler som inte är offentliga loggar du in på LinkedIn.
Nästa steg
- RBAC för Azure OpenAI
- Använda hanterade identiteter i API Management
- Principer i API Management
- Autentisering och auktorisering till API:er i API Management
- Skydda ett API i API Management med OAuth 2.0 och Microsoft Entra ID
- Skydda serverdelstjänster med hjälp av klientcertifikatautentisering i API Management