Intelligente toepassingen die gebruikmaken van Azure OpenAI Service via systeemeigen Azure-services bieden naadloze gebruikersverificatie en autorisatie. Sommige scenario's zijn echter complex en vereisen verschillende architectuurontwerpen. Deze scenario's omvatten topologieën met clienttoepassingen die niet worden gehost in Azure, externe id-providers gebruiken en meerdere clients implementeren die toegang hebben tot dezelfde Azure OpenAI-exemplaren. In deze scenario's kan het introduceren van een gateway vóór Azure OpenAI de beveiliging aanzienlijk verbeteren door een laag toe te voegen die zorgt voor consistente verificatie voor geïmplementeerde exemplaren.
In dit artikel worden belangrijke scenario's beschreven die verificatie bieden voor Azure OpenAI:
In elk scenario worden de uitdagingen beschreven die ze introduceren en de voordelen van het integreren van een gateway.
Belangrijk
U kunt de volgende richtlijnen gebruiken voor elke gatewayimplementatie, waaronder Azure API Management. Ter illustratie van deze flexibiliteit gebruiken de architectuurdiagrammen algemene weergaven van onderdelen in de meeste scenario's.
Clienttoepassingen verifiëren via een externe id-provider
Een Visio-bestand van deze architectuur downloaden.
Scenariobeperkingen
Dit scenario heeft de volgende beperkingen:
Clienttoepassingen gebruiken een externe Id-provider met OpenID Connect (OIDC), zoals Okta, Auth0 of sociale id-providers.
Clienttoepassingen verifiëren zich met een Microsoft Entra-tenant die anders is dan de tenant van het Azure OpenAI-gegevensvlak.
Deze beperkingen kunnen van toepassing zijn op de volgende voorbeelden:
Bestaande clienttoepassingen die al worden geverifieerd op basis van een externe OIDC-provider of Microsoft Entra-id en die kunnen worden geïntegreerd met Azure OpenAI-exemplaren.
Clienttoepassingen die gebruikers consistent moeten verifiëren bij meerdere id-providers.
Rechtstreeks verbinding maken met Azure OpenAI
Als de clienttoepassingen in deze scenario's rechtstreeks verbinding maken met Azure OpenAI zonder een gateway te gebruiken, moeten ze verificatie op basis van sleutels gebruiken om te verifiëren bij Azure OpenAI. Verificatie op basis van sleutels introduceert extra beveiligingsproblemen. U moet sleutels veilig opslaan en roteren en u kunt geen verschillende RBAC-configuraties (op rollen gebaseerd toegangsbeheer) voor clients verlenen voor afzonderlijke modelimplementaties.
Een gateway introduceren
Een Visio-bestand van deze architectuur downloaden.
Een gateway lost de uitdagingen van dit scenario op de volgende manieren op:
De gateway gebruikt Open Authorization (OAuth) om gebruikers te verifiëren via hun bestaande externe id-providers. De gateway valideert de geverifieerde tokens voor gebruikerstoegang, zoals een JSON-webtoken (JWT), dat de id-provider genereert. Vervolgens verleent de gateway autorisatie aan het back-upexemplaren van Azure OpenAI.
U hoeft geen clientsleutels te beheren. Deze aanpak elimineert de beveiligingsrisico's van verificatie op basis van sleutels.
De gateway maakt verbinding met Azure OpenAI met behulp van een beheerde identiteit, waardoor de beveiliging wordt verbeterd via minst bevoegde Azure RBAC.
Aanbevelingen voor dit scenario
Voeg meer OAuth-bereiken toe aan uw toepassingsregistratie in uw id-provider om gedetailleerde machtigingen voor consumenten mogelijk te maken. Met deze bereiken kunnen clienttoepassingen toestemming vragen om specifieke bewerkingen uit te voeren in uw gateway, inclusief toegang tot Azure OpenAI.
Configureer dit scenario voor API Management met behulp van inkomend beleid. Gebruik het
validate-jwtbeleid om het bestaan, de geldigheid en de kenmerkwaarden van een ondersteunde JWT af te dwingen.
Redenen om een gateway voor dit scenario te voorkomen
Als één intelligente toepassing toegang heeft tot Azure OpenAI, is het eenvoudiger om gebruikersverificatie en autorisatie in de app te configureren in plaats van via de gateway. Gebruik deze methode om de benodigde Azure RBAC toe te wijzen om de intelligente toepassing veilig te verifiëren met Azure OpenAI.
Clienttoepassingen verifiëren via certificaten
Een Visio-bestand van deze architectuur downloaden.
Scenariobeperkingen
Dit scenario heeft de volgende beperkingen:
U wilt certificaten gebruiken om clienttoepassingen te verifiëren.
Clienttoepassingen kunnen niet worden gebruikt of u wilt geen Microsoft Entra-id of andere OIDC-providers gebruiken voor verificatie.
Clients kunnen geen federatieve identiteit gebruiken of u wilt geen federatieve identiteit gebruiken voor verificatie.
Deze beperkingen kunnen van toepassing zijn op de volgende voorbeelden:
Een client die bij Azure OpenAI wordt geverifieerd, is een machine of apparaat en er vindt geen interactie van de gebruiker plaats.
Uw organisatie vereist dat u certificaten voor verificatie gebruikt vanwege beveiligingsstandaarden en nalevingsregels.
U wilt meerdere clienttoepassingen voorzien van opties voor verificatie op basis van hun omgeving, waaronder het gebruik van clientcertificaten.
Rechtstreeks verbinding maken met Azure OpenAI
Azure OpenAI biedt geen systeemeigen ondersteuning voor verificatie van clientcertificering. Ter ondersteuning van dit scenario zonder een gateway moet de intelligente toepassing certificaatverificatie gebruiken voor de gebruiker en een API-sleutel of beheerde identiteit om aanvragen te verifiëren bij het Azure OpenAI-exemplaar. U moet de certificaatverificatielogica in elke client implementeren. In dit scenario introduceert sleutelgebaseerde verificatie risico's en beheeroverhead als u rechtstreeks vanuit clients verbinding maakt met Azure OpenAI.
Een gateway introduceren
Een Visio-bestand van deze architectuur downloaden.
U kunt een gateway introduceren in deze architectuur waarmee clientcertificeringsvalidatie van de clients wordt offload. De gateway valideert het digitale clientcertificaat dat de intelligente toepassing presenteert en controleert de uitgever, vervaldatum, vingerafdruk en intrekkingslijsten. De gateway moet een beheerde identiteit gebruiken om zichzelf te verifiëren met Azure OpenAI. De gateway moet ook Azure Key Vault gebruiken om de basiscertificeringsinstantie (CA) op te slaan. Gebruik deze methode om validatie van clientcertificaten te centraliseren, waardoor de onderhoudsoverhead wordt verminderd.
Een gateway biedt verschillende voordelen in dit scenario:
U gebruikt de beheerde identiteit van de gateway in plaats van toegangssleutels, waardoor het risico van gestolen sleutels wordt geëlimineerd en de onderhoudslast van sleutelrotatie wordt verminderd.
U kunt certificaatvalidatie centraliseren, zodat u consistent beveiligingsbeleid gebruikt om digitale clientcertificaten voor alle intelligente toepassingen te evalueren.
U kunt certificaatvalidatie offloaden naar de gateway, wat clientcode vereenvoudigt.
Aanbevelingen voor dit scenario
Controleer de volledige certificaatketen, inclusief de basis-CA en tussenliggende certificaten, wanneer u certificaten valideert. Volledige verificatie zorgt voor de echtheid van het certificaat en voorkomt onbevoegde toegang.
Draai en vernieuw clientcertificaten regelmatig om het risico op inbreuk op certificaten te minimaliseren. Gebruik Key Vault om dit proces te automatiseren en certificaten up-to-date te houden. Stel waarschuwingen in voor toekomstige vervaldatums van certificaten om serviceonderbrekingen op de gateway te voorkomen.
Implementeer wederzijdse MTLS (Transport Layer Security) om ervoor te zorgen dat zowel de client als de server elkaar verifiëren. Deze strategie biedt een extra beveiligingslaag. Als u de gateway wilt configureren voor het afdwingen van mTLS, stelt u het juiste beleid en de juiste beperkingen in.
Gebruik het
validate-client-certificatebeleid in API Management om clientcertificaten te valideren waarnaar een Azure-sleutelkluis verwijst. Dit beleid valideert het clientcertificaat dat de clienttoepassing presenteert en controleert de uitgever, vervaldatum, vingerafdruk en intrekkingslijsten.
Redenen om een gateway voor dit scenario te voorkomen
In eenvoudige omgevingen met weinig clients kunnen de kosten voor het afhandelen van beveiliging en certificaatbeheer in de client opwegen tegen de toegevoegde complexiteit van het introduceren van een gateway. Gateways kunnen ook single points of failure worden, de latentie verhogen vanwege toegevoegde lagen en leiden tot vergrendeling van leveranciers als u commerciële oplossingen kiest in plaats van aangepaste implementaties.
U moet zorgvuldig uw specifieke behoeften, de beschikbaarheid van resources en de ernst van uw toepassingen beoordelen voordat u een gateway implementeert voor clientcertificaatverificatie.
Meerdere clienttoepassingen verifiëren via sleutels voor toegang tot een gedeeld Azure OpenAI-exemplaar
Een Visio-bestand van deze architectuur downloaden.
Scenariobeperkingen
Dit scenario heeft de volgende beperkingen:
- Meerdere clienttoepassingen hebben toegang tot een gedeeld Azure OpenAI-exemplaar.
- Clients kunnen geen microsoft-entra-id voor verificatie gebruiken of u wilt deze niet gebruiken.
- Clients kunnen geen federatieve identiteit gebruiken of u wilt geen federatieve identiteit gebruiken voor verificatie.
- U wilt verificatie op basis van sleutels gebruiken voor clienttoepassingen.
Deze beperkingen kunnen van toepassing zijn op de volgende voorbeelden:
U implementeert clienttoepassingen in meerdere omgevingen, waaronder Azure, on-premises of andere cloudproviders.
Een organisatie moet Azure OpenAI aan verschillende teams bieden en unieke toegangs- en gebruikslimieten instellen voor elk team.
Rechtstreeks verbinding maken met Azure OpenAI
Azure OpenAI ondersteunt verificatie op basis van sleutels via gedeelde sleutels. Azure OpenAI maakt een primaire sleutel en een secundaire sleutel beschikbaar. Het doel van de secundaire sleutel is het ondersteunen van sleutelrotatie. Het biedt geen isolatie van clientidentiteit. Wanneer u in dit scenario meerdere clients rechtstreeks verifieert bij Azure OpenAI, deelt elke client dezelfde sleutel. Deze implementatie heeft de volgende uitdagingen:
U kunt machtigingen voor specifieke clients niet intrekken omdat elke client dezelfde sleutel deelt.
U kunt verschillende clients geen verschillende toegangsrechten geven voor verschillende modellen in dezelfde Azure OpenAI-exemplaarimplementatie.
U kunt de ene client niet onderscheiden van een andere client vanuit het perspectief van logboekregistratie.
Een gateway introduceren
Een Visio-bestand van deze architectuur downloaden.
U kunt een gateway introduceren in deze architectuur die een toegewezen sleutel voor elke clienttoepassing uitgeeft. API Management maakt gebruik van het concept van abonnementen om toegewezen clientsleutels te bieden. De gateway moet een beheerde identiteit gebruiken om zichzelf te verifiëren met Azure OpenAI.
Een gateway biedt verschillende voordelen in dit scenario:
U kunt de toegang tot één clienttoepassing intrekken zonder dat dit van invloed is op andere clients.
U hoeft niet alle sleutelconfiguraties van de client bij te werken voordat u sleutels draait, dus sleutelrotatie is logistiek eenvoudiger. U kunt de toegewezen sleutels voor elke client draaien nadat u de clientconfiguratie hebt bijgewerkt.
U kunt elke client uniek identificeren vanuit het perspectief van logboekregistratie.
De gateway dwingt frequentielimieten en quota voor elke client onafhankelijk af.
Aanbevelingen voor dit scenario
Verbeter de bewaking van metrische gegevens die betrekking hebben op API-aanvragen. Wanneer u een beheerde identiteit van een gateway gebruikt, wordt de traceerbaarheid van de gebruiker en clienttoepassing in Azure OpenAI-logboeken niet verbeterd. De gateway moet logboekregistratie opgeven die is gekoppeld aan de aanvraag, zoals de aanvragende client- en gebruikers-id's.
Zorg ervoor dat de gateway routeringsbeslissingen neemt voor de juiste modelimplementaties op basis van de clientidentiteit wanneer u meerdere aanvragen van clienttoepassingen routert via een gateway naar een gedeeld Azure OpenAI-exemplaar. Zie Een gateway gebruiken voor meerdere Azure OpenAI-implementaties voor meer informatie.
Clienttoepassingen verifiëren die toegang hebben tot meerdere Azure OpenAI-exemplaren
Een Visio-bestand van deze architectuur downloaden.
Scenariobeperkingen
Dit scenario heeft de volgende beperkingen:
- Clienttoepassingen maken verbinding met meerdere Azure OpenAI-exemplaren in een of meer regio's.
- Clients kunnen niet worden gebruikt of u wilt geen Microsoft Entra-id of andere OIDC-providers gebruiken voor verificatie.
- U wilt verificatie op basis van sleutels gebruiken voor clienttoepassingen.
Deze beperkingen kunnen van toepassing zijn op de volgende voorbeelden:
Clienttoepassingen moeten hun workloads geografisch distribueren om de latentie te verminderen en de prestaties te verbeteren.
Clienttoepassingen proberen hun tokens per minuut te optimaliseren door exemplaren in meerdere regio's te implementeren.
Een organisatie vereist naadloze failover- en noodherstelmogelijkheden om continue werking te garanderen. Ze beheren dus een strategie voor dubbele implementatie, zoals een strategie die bestaat uit een ingerichte doorvoerimplementatie en een implementatie met betalen per gebruik.
Clienttoepassingen moeten gebruikmaken van specifieke modelmogelijkheden die alleen beschikbaar zijn in bepaalde Azure-regio's.
Rechtstreeks verbinding maken met meerdere Azure OpenAI-exemplaren
Wanneer clienttoepassingen rechtstreeks verbinding maken met meerdere Azure OpenAI-exemplaren, moet elke client de sleutel voor elk exemplaar opslaan. Naast de beveiligingsoverwegingen voor het gebruik van sleutels is er een verhoogde beheerlast met betrekking tot het roteren van sleutels.
Een gateway introduceren
Een Visio-bestand van deze architectuur downloaden.
Wanneer u een gateway gebruikt om clienttoepassingen te verwerken die toegang hebben tot meerdere Azure OpenAI-implementaties, krijgt u dezelfde voordelen als een gateway die meerdere clienttoepassingen verwerkt via sleutels voor toegang tot een gedeeld Azure OpenAI-exemplaar. U stroomlijnt ook het verificatieproces omdat u één door de gebruiker gedefinieerde beheerde identiteit gebruikt voor het verifiëren van aanvragen van de gateway naar meerdere Azure OpenAI-exemplaren. Implementeer deze aanpak om de algehele operationele overhead te verminderen en de risico's van onjuiste configuratie van clients te minimaliseren wanneer u met meerdere exemplaren werkt.
Een voorbeeld van hoe een gateway in Azure wordt gebruikt om identiteit naar een intermediair te offloaden, is de Azure AI Services-resource. In die implementatie verifieert u zich bij de gateway en de gateway zorgt voor verificatie bij de verschillende Azure AI-services, zoals Custom Vision of Speech. Hoewel deze implementatie vergelijkbaar is, wordt dit scenario niet aangepakt.
Aanbevelingen voor dit scenario
Implementeer taakverdelingstechnieken om de API-aanvragen te distribueren over meerdere exemplaren van Azure OpenAI om veel verkeer te verwerken en hoge beschikbaarheid te garanderen. Zie Een gateway gebruiken voor meerdere Azure OpenAI-implementaties of -exemplaren voor meer informatie.
Correleer tokengebruik voor elke tenant bij de gateway wanneer u scenario's met meerdere Azure OpenAI-exemplaren implementeert. Deze aanpak zorgt ervoor dat u het totale tokengebruik bijhoudt, ongeacht de back-end Azure OpenAI-instantie waarnaar de aanvraag wordt doorgestuurd.
Algemene aanbevelingen
Wanneer u Azure OpenAI integreert via een gateway, zijn er verschillende kruislingse aanbevelingen om rekening mee te houden die in alle scenario's van toepassing zijn.
Gebruik Azure API Management in plaats van uw eigen oplossing te maken voor efficiënte API-indeling, naadloze integratie met andere Azure-services en kostenbesparingen door ontwikkelings- en onderhoudsinspanningen te verminderen. API Management zorgt voor veilig API-beheer door verificatie en autorisatie rechtstreeks te ondersteunen. Het kan worden geïntegreerd met id-providers, zoals Microsoft Entra ID, waarmee OAuth 2.0 wordt ingeschakeld en op beleid gebaseerde autorisatie wordt geboden. Daarnaast maakt API Management gebruik van beheerde identiteiten voor veilige en weinig-onderhoudstoegang tot Azure OpenAI.
Scenario's combineren voor een uitgebreide gatewayoplossing
In echte toepassingen kunnen uw use cases meerdere scenario's uit dit artikel omvatten. U hebt bijvoorbeeld clienttoepassingen die worden geverifieerd via een externe id-provider en toegang tot meerdere Azure OpenAI-exemplaren vereisen.
Een Visio-bestand van deze architectuur downloaden.
Als u een gateway wilt bouwen die uw specifieke vereisten ondersteunt, combineert u de aanbevelingen uit deze scenario's voor een uitgebreide benadering.
Gatewaybeleid afdwingen
Voordat een gateway aanvragen naar Azure OpenAI-exemplaren verzendt, moet u binnenkomende verificatie- en autorisatiebeleid afdwingen. Gebruik tokens voor gebruikerstoegang van een id-provider of certificaatvalidatie om deze aanpak te implementeren om ervoor te zorgen dat de gateway alleen geverifieerde en geautoriseerde aanvragen doorstuurt.
Als u gedetailleerde controle wilt inschakelen, implementeert u meer autorisatiebereiken met rollen en machtigingen voor clienttoepassingen in uw gateway. Gebruik deze bereiken om specifieke bewerkingen toe te staan op basis van de behoeften van de clienttoepassing. Deze aanpak verbetert de beveiliging en beheerbaarheid.
Voor validatie van toegangstokens moet u alle geregistreerde sleutelclaims, zoals iss, audexpen nbf eventuele relevante workloadspecifieke claims, zoals groepslidmaatschappen of toepassingsrollen, valideren.
Beheerde Identiteiten van Azure gebruiken
Gebruik door Azure beheerde identiteiten om verificatie te vereenvoudigen in alle scenario's voor clienttoepassingen om verificatiebeheer te centraliseren. Deze aanpak vermindert de complexiteit en risico's die zijn gekoppeld aan het beheren van meerdere API-sleutels of referenties in clienttoepassingen.
Beheerde identiteiten ondersteunen inherent Azure RBAC, zodat ze ervoor zorgen dat de gateway alleen het laagste machtigingsniveau heeft dat nodig is voor toegang tot Azure OpenAI-exemplaren. Als u het risico op onbevoegde toegang wilt verminderen en de naleving van beveiligingsbeleid wilt vereenvoudigen, combineert u beheerde identiteiten met andere methoden waarmee alternatieve verificatie wordt uitgeschakeld.
Uitgebreide waarneembaarheid implementeren
Wanneer u een gateway met een beheerde identiteit implementeert, vermindert dit de traceerbaarheid omdat de beheerde identiteit de gateway zelf vertegenwoordigt, niet de gebruiker of de toepassing die de aanvraag doet. Daarom is het essentieel om de waarneembaarheid van metrische gegevens te verbeteren die betrekking hebben op API-aanvragen. Om de zichtbaarheid van toegangspatronen en het gebruik te behouden, moeten gateways meer traceringsmetagegevens bieden, zoals de aanvragende client- en gebruikers-id's.
Gecentraliseerde logboekregistratie van alle aanvragen die via de gateway worden doorgegeven, helpt u bij het onderhouden van een audittrail. Een gecentraliseerd audittrail is met name belangrijk voor het oplossen van problemen, naleving en het detecteren van onbevoegde toegangspogingen.
Adrescaching veilig
Als uw API-gateway verantwoordelijk is voor het in de cache opslaan van voltooiingen of andere deductieresultaten, moet u ervoor zorgen dat de identiteit van de aanvrager wordt beschouwd in de cachelogica. Retourneert geen resultaten in de cache voor identiteiten die niet zijn gemachtigd om die gegevens te ontvangen.
Gateway-implementaties
Azure biedt geen volledige kant-en-klare oplossing of referentiearchitectuur voor het bouwen van de gateway in dit artikel, dus u moet de gateway bouwen en gebruiken. Azure API Management kan worden gebruikt om een paaS-oplossing te bouwen via ingebouwd en aangepast beleid. Azure biedt ook voorbeelden van door de community ondersteunde implementaties die betrekking hebben op de gebruiksvoorbeelden in dit artikel. Raadpleeg deze voorbeelden wanneer u uw eigen gatewayoplossing bouwt. Zie de video Learn Live: Identiteit en beveiliging van Azure OpenAI-toepassingen voor meer informatie.
Medewerkers
De volgende inzenders hebben dit artikel oorspronkelijk geschreven.
Belangrijkste auteurs:
- Lizet Pena De Sola | Senior klanttechnicus, FastTrack voor Azure
- Bappaditya Banerjee | Senior klanttechnicus, FastTrack voor Azure
- James Shire | Customer Engineer, ISV & Digital Native Center of Excellence
Als u niet-openbare LinkedIn-profielen wilt zien, meldt u zich aan bij LinkedIn.
Volgende stappen
- RBAC voor Azure OpenAI
- Beheerde identiteiten gebruiken in API Management
- Beleid in API Management
- Verificatie en autorisatie voor API's in API Management
- Een API beveiligen in API Management met behulp van OAuth 2.0 en Microsoft Entra-id
- Back-endservices beveiligen met behulp van clientcertificaatverificatie in API Management