Tillhandahålla alternativ autentisering till Azure OpenAI-tjänster via en gateway

Intelligenta program som använder Azure OpenAI-tjänster via plattformsbaserade Azure-tjänster erbjuder en smidig användarautentiserings- och auktoriseringsmetod. Det finns dock olika scenarier som presenterar komplexitet som kräver olika arkitekturdesign. Dessa scenarier omfattar topologier med klientprogram som inte finns i Azure, användning av externa identitetsprovidrar och distribution av flera klienter som har åtkomst till samma Azure OpenAI-instanser. I dessa scenarier kan införandet av en gateway framför Azure OpenAI ge betydande säkerhetsförbättringar genom att lägga till ett lager som säkerställer konsekvens i autentisering till distribuerade instanser.

Den här artikeln utforskar följande viktiga scenarier när du autentiserar med Azure OpenAI-tjänster.

• Klientprogram autentiserade med en extern identitetsprovider
• Klientprogram autentiserade med certifikat
• Flera klientprogram som har åtkomst till en delad Azure OpenAI-instans
• Klientprogram som har åtkomst till flera Azure OpenAI-instanser

Varje scenario beskriver de utmaningar som de medför och fördelarna med att inkludera en gateway.

Klientprogram autentiserade med en extern identitetsprovider

Scenariobegränsningar

Följande är begränsningarna i det här scenariot:

• Klientprogram använder en extern OpenID Connect-aktiverad identitetsprovider (OIDC), till exempel Okta, Auth0 eller sociala identitetsprovidrar.
• Klientprogram autentiserar mot en Annan Microsoft Entra-klientorganisation än Azure OpenAI-dataplanets klientorganisation.

Dessa begränsningar kan gälla för scenarier där:

• Befintliga klientprogram som redan autentiseras mot en extern OIDC-provider eller Microsoft Entra-ID integreras med Azure OpenAI-instanser.
• Klientprogram måste autentisera användare från flera identitetsprovidrar på ett konsekvent sätt.

Ansluta direkt till Azure OpenAI

Om klientprogrammen i dessa scenarier ansluter direkt till Azure OpenAI (inte använder en gateway) måste de använda nyckelbaserad autentisering för att autentisera till Azure OpenAI. Nyckelbaserad autentisering medför extra säkerhetsproblem, till exempel säker lagring av nycklar, rotation av nycklar och oförmåga att tillhandahålla olika klienter sina egna rollbaserade rbac-konfigurationer (åtkomstkontroll) för enskilda modelldistributioner.

Introduktion till en gateway

Introduktionen av en gateway hanterar utmaningarna i det här scenariot på flera sätt:

• Gatewayen kan använda OAuth för att autentisera användare med sina befintliga externa identitetsprovidrar. Gatewayen validerar de autentiserade användaråtkomsttoken, till exempel en JSON-webbtoken (JWT), som genereras av identitetsprovidern innan du beviljar auktorisering till den säkerhetskopierade Azure OpenAI-instansen.
• Det är inte längre nödvändigt att hantera nycklar för klienter och de säkerhetsrisker som är kopplade till att använda nyckelbaserad autentisering är borta.
• Gatewayen kan ansluta till Azure OpenAI med hjälp av en hanterad identitet, vilket förbättrar säkerheten med hjälp av minst privilegierade Azure RBAC.

Rekommendationer och vägledning för det här scenariot

• Fler OAuth-omfång kan läggas till i programregistreringen i identitetsprovidern för att ge konsumenter detaljerad behörighet. Med dessa omfång kan klientprogram begära behörighet att utföra specifika åtgärder i din gateway, inklusive åtkomst till Azure OpenAI.
• Du kan konfigurera det här scenariot för Azure API Management med hjälp av inkommande principer. Använd principen validate-jwt för att framtvinga förekomsten, giltigheten och attributvärdena för en JWT som stöds.

Orsaker till att undvika en gateway för det här scenariot

Om du har ett enda intelligent program som har åtkomst till Azure OpenAI kan det vara enklare att konfigurera användarautentisering och auktorisering i programmet jämfört med gatewayen. Du kan tilldela nödvändiga Azure RBAC för att på ett säkert sätt autentisera det intelligenta programmet med Azure OpenAI med den här metoden.

Klientprogram autentiserade med certifikat

Scenariobegränsningar

Följande är begränsningarna i det här scenariot:

• 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 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 scenarier där:

• En klient som autentiserar till Azure OpenAI-tjänster är en dator eller enhet där det inte finns någon användarinteraktion.
• Din organisation kräver användning av 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 skulle det intelligenta programmet begränsas till att använda certifikatautentisering för användaren och använda en API-nyckel eller hanterad identitet för att autentisera begäranden till Azure OpenAI-instansen. Logiken för certifikatautentisering måste implementeras i varje klient. Riskerna och hanteringskostnaderna för att använda nyckelbaserad autentisering skulle gälla om du ansluter direkt till Azure OpenAI från klienter i det här scenariot.

Introduktion till en gateway

Du kan introducera en gateway i den här arkitekturen som avlastar klientcertifieringsvalidering från klienterna. Gatewayen ansvarar för att verifiera det digitala klientcertifikatet som presenteras av det intelligenta programmet och kontrollera utfärdaren, förfallodatum, tumavtryck och återkallningslistor. Gatewayen bör använda hanterad identitet för att autentisera sig själv med Azure OpenAI. Gatewayen bör använda Azure Key Vault för att lagra rotcertifikatutfärdare (CA) för att säkerställa att verifieringen av klientcertifikat hanteras på en central plats, vilket minskar underhållskostnaderna.

Det finns flera fördelar med att introducera en gateway för att hantera det här scenariot, bland annat:

• Genom att använda gatewayens hanterade identitet jämfört med åtkomstnycklar eliminerar du risken för att nycklar blir stulna och minskar underhållsbördan för roterande nycklar.
• Genom att centralisera certifikatverifieringen ser du till att du använder konsekventa säkerhetsprinciper för att utvärdera digitala klientcertifikat för alla intelligenta program.
• Om du avlastar certifikatverifieringen till gatewayen kan klientkoden förenklas.

Rekommendationer och vägledning för det här scenariot

• När du verifierar certifikat kontrollerar du hela certifikatkedjan, inklusive rotcertifikatutfärdare och mellanliggande 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. Automatisera den här processen med Hjälp av Azure Key Vault för att säkerställa att certifikaten alltid är uppdaterade. Om du anger aviseringar för kommande förfallodatum för certifikat förhindras även tjänstavbrott på gatewayen.
• Implementera ömsesidig TLS (mTLS) för att säkerställa att både klienten och servern autentiserar varandra, vilket ger ett extra säkerhetslager. Konfigurera gatewayen för att framtvinga mTLS genom att ange lämpliga principer och begränsningar.
• Med Azure API Management kan du använda principen validate-client-certificate för att validera klientcertifikat, som refereras till i ett Azure-nyckelvalv. Den här principen validerar klientcertifikatet som presenteras av klientprogrammet 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 framför anpassade implementeringar.

Du måste noggrant utvärdera dina specifika behov, resurstillgänglighet och kritiskhet för dina program innan du bestämmer dig för att implementera en gateway för klientcertifikatautentisering.

Flera klientprogram som använder nycklar för att få åtkomst till en delad Azure OpenAI-instans

Scenariobegränsningar

Följande är begränsningarna i det här scenariot:

• 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 scenarier där:

• Klientprogram distribueras i flera miljöer, inklusive Azure, andra molnleverantörer eller lokalt.
• Organisationer måste tillhandahålla Azure OpenAI-tjänster till olika team, var och en med unika åtkomst- och användningsgränser.

Ansluta direkt till Azure OpenAI

Azure OpenAI stöder nyckelbaserad autentisering med delade nycklar. Azure OpenAI exponerar en primärnyckel och en sekundär nyckel, men syftet med den sekundära nyckeln är att stödja nyckelrotation, inte för klientidentitetsisolering. När du autentiserar flera klienter direkt till Azure OpenAI i det här scenariot delar varje klient samma nyckel. Följande är utmaningar med den här implementeringen:

• Du har inte möjlighet att å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.

Introduktion till en gateway

Du kan introducera en gateway i den här arkitekturen som utfärdar en dedikerad nyckel till varje klientprogram. Azure API Management använder begreppet prenumerationer för att tillhandahålla dedikerade klientnycklar. Gatewayen bör använda hanterad identitet för att autentisera sig själv med Azure OpenAI.

Det finns flera fördelar med att introducera en gateway för att hantera det här scenariot, bland annat:

• Du kan återkalla åtkomsten till ett enda klientprogram utan att påverka andra klienter.
• Roterande nycklar blir mindre logistiskt utmanande eftersom du inte behöver uppdatera alla klienters nyckelkonfiguration innan du roterar dem. De dedikerade nycklarna kan roteras för varje klient när klientkonfigurationen har uppdaterats.
• Varje klient kan identifieras unikt ur ett loggningsperspektiv.
• Gatewayen blir ansvarig för att tillämpa hastighetsgränser och kvoter för varje klient oberoende av varandra.

Rekommendationer och vägledning för det här scenariot

• Eftersom användningen av en hanterad identitet från en gateway inte förbättrar spårningsbarheten för slutanvändaren och klientprogrammet i Azure OpenAI-loggarna kan du förbättra övervakningen av mått relaterade till API-begäranden. Gatewayen bör tillhandahålla loggning som är associerad med begäran, till exempel de begärande klient- och användar-ID:t.
• När du dirigerar flera klientprogrambegäranden via en gateway till en delad Azure OpenAI-tjänst kontrollerar du att gatewayen fattar routningsbeslut baserat på klientidentitet till lämpliga modelldistributioner. Mer metodtips för gatewayimplementeringar för flera Azure OpenAI-distributioner finns i Använda en gateway framför flera Azure OpenAI-distributioner.

Klientprogram som har åtkomst till flera Azure OpenAI-instanser

Scenariobegränsningar

Följande är begränsningarna i det här scenariot:

• 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 OIDC-leverantörer för autentisering.
• Du vill använda nyckelbaserad autentisering för klientprogram.

Dessa begränsningar kan gälla för scenarier där:

• Klientprogram måste distribuera sina arbetsbelastningar geografiskt för att minska svarstiden och förbättra prestanda.
• Klientprogram försöker optimera sina TPM-kvoter (token per minut) genom att distribuera instanser i flera regioner.
• Organisationer behöver sömlösa redundans- och haveriberedskapsfunktioner för att säkerställa kontinuerlig drift genom att hantera en strategi för dubbel distribution, som eventuellt 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 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.

Introduktion till en gateway

Introduktionen av en gateway för att hantera klientprogram som har åtkomst till flera Azure OpenAI-distributioner har samma fördelar som genom att introducera en gateway för att hantera flera klientprogram med hjälp av nycklar för att få åtkomst till en delad Azure OpenAI-instans. Utöver dessa orsaker effektiviseras autentiseringsprocessen genom att använda en enda användardefinierad hanterad identitet för att autentisera begäranden från gatewayen till flera Azure OpenAI-instanser. Implementeringen av den här metoden minskar den övergripande driftsbelastningen och minimerar risken för felkonfiguration av klienten när du arbetar med flera instanser.

Rekommendationer och vägledning för det här scenariot

• Implementera belastningsutjämningstekniker för att distribuera API-begäranden över flera instanser av Azure OpenAI-tjänsten för att hantera hög trafik och säkerställa hög tillgänglighet. Mer information om den här implementeringen finns i Använda en gateway framför flera Azure OpenAI-distributioner eller instanser.
• När du implementerar scenarier med flera klientorganisationer med flera Azure OpenAI-instanser måste spårningstokenanvändningen för en specifik klientorganisation korreleras vid gatewayen. Genom att korrelera tokenanvändningen på gatewayen ser du till att du spårar den totala tokenanvändningen oavsett vilken Azure OpenAI-instans som begäran vidarebefordras till.

Allmänna rekommendationer

När du integrerar Azure OpenAI-tjänster via en gateway finns det flera övergripande rekommendationer att tänka på som gäller i alla scenarier.

Att välja Azure API Management (APIM) i stället för att skapa en egen lösning har flera fördelar. Det ger effektiv API-orkestrering, enkel integrering med andra Azure-tjänster och kostnadsbesparingar genom att minska utvecklings- och underhållsinsatserna. APIM tillhandahåller säker API-hantering genom att stödja autentisering och auktorisering direkt. Den integreras med identitetsprovidrar, till exempel Microsoft Entra-ID, aktivering av OAuth 2.0 och erbjuder principbaserad auktorisering. Dessutom kan den dra nytta av hanterade identiteter för säker och låg underhållsåtkomst till Azure OpenAI.

Kombinera scenarier för en omfattande gatewaylösning

I praktiken kan dina användningsfall omfatta flera scenarier som beskrivs i den här guiden. Du kan till exempel ha klientprogram som autentiserar med en extern identitetsprovider och som kräver åtkomst till flera Azure OpenAI-instanser.

Genom att kombinera rekommendationerna från dessa scenarier kan du skapa en gateway som stöder dina specifika krav.

Tvingande gatewayprincip

Innan begäranden till Azure OpenAI-instanser skickas via en gateway bör principer för inkommande autentisering och auktorisering tillämpas. Oavsett om det gäller användaråtkomsttoken från en identitetsprovider eller certifikatverifiering säkerställer implementeringen av den här metoden att endast autentiserade och auktoriserade begäranden vidarebefordras.

Om du implementerar mer auktoriseringsomfång med roller och behörigheter för klientprogram i gatewayen kan du också kontrollera detaljerat. Med dessa omfång kan specifika åtgärder tillåtas baserat på klientprogrammets behov, vilket förbättrar säkerheten och hanterbarheten.

För validering av åtkomsttoken måste du verifiera alla nyckelregistrerade anspråk, isstill exempel , aud, expoch nbf utöver relevanta arbetsbelastningsspecifika anspråk, till exempel gruppmedlemskap eller programroller.

Använda hanterade Azure-identiteter

Med azure-hanterade identiteter förenklas autentiseringen i alla klientprogramscenarier genom centralisering av autentiseringshantering. Den här metoden minskar komplexiteten och riskerna med att hantera flera API-nycklar eller autentiseringsuppgifter i klientprogram.

Eftersom hanterade identiteter i sig stöder rollbaserad åtkomstkontroll i Azure ser de till att gatewayen bara har den lägsta behörighetsnivån som krävs för att få åtkomst till Azure OpenAI-instanser. I kombination med att inaktivera alternativa autentiseringsmetoder minskar hanterade identiteter risken för obehörig åtkomst och förenklar efterlevnaden av säkerhetsprinciper.

Implementera omfattande observerbarhet

När du implementerar en gateway med hanterad identitet kan spårningen minskas eftersom en hanterad identitet representerar gatewayen, inte slutanvändaren eller programmet som gjorde begäran. Därför är det viktigt att förbättra observerbarheten för mått relaterade till API-begäranden. Gatewayer bör tillhandahålla mer spårningsmetadata, inklusive de begärande klient- och användar-ID:na, för att upprätthålla synlighet över åtkomstmönster och användning.

Centraliserad loggning av alla begäranden som skickas via gatewayen hjälper också till att upprätthålla en spårningslogg. En centraliserad spårningslogg är särskilt viktig för felsökning, efterlevnad och säkerställande av att obehöriga åtkomstförsök kan identifieras.

Gatewayimplementeringar

Azure erbjuder ingen nyckelfärdig lösning eller referensarkitektur för att skapa en sådan gateway. Som du nämnde i introduktionsartikeln måste du skapa och använda den här gatewayen. Följande är exempel på implementeringar som stöds av communityn och som täcker de tidigare nämnda användningsfallen. Överväg att referera till dessa exempel när du skapar en egen gatewaylösning.

Nästa steg

Implementering av en gateway för din arbetsbelastning ger fördelar utöver scenarierna för att förbättra autentisering och auktorisering som beskrivs i den här artikeln. Lär dig mer om de andra viktiga utmaningar som en gateway kan lösa.

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.

Relaterade resurser

• Rollbaserad åtkomstkontroll för Azure OpenAI
• Använda hanterade identiteter i Azure API Management
• Principer i Azure API Management
• Autentisering och auktorisering till API:er i Azure API Management
• Skydda ett API i API Management med OAuth 2.0 och Microsoft Entra ID
• Säker API Management-serverdel med klientcertifikatautentisering