Les applications intelligentes qui utilisent Azure OpenAI Service via des services natifs Azure offrent une authentification et une autorisation utilisateur transparentes. Cependant, certains scénarios sont complexes et nécessitent des conceptions d’architecture différentes. Ces scénarios incluent des topologies dans lesquelles les applications clientes ne sont pas hébergées sur Azure, utilisent des fournisseurs d’identité externes et déploient plusieurs clients accédant aux mêmes instances Azure OpenAI. Dans ces scénarios, introduire une passerelle devant Azure OpenAI peut considérablement améliorer la sécurité en ajoutant une couche garantissant une authentification cohérente aux instances déployées.
Cet article décrit les scénarios clés qui fournissent une authentification à Azure OpenAI :
Authentifier les applications clientes via un fournisseur d’identité externe
Authentifier les applications clientes qui accèdent à plusieurs instances Azure OpenAI
Chaque scénario décrit les défis qu’il introduit et les avantages d’incorporer une passerelle.
Important
Vous pouvez utiliser les conseils suivants pour toute mise en œuvre de passerelle, y compris Azure API Management. Pour illustrer cette flexibilité, les diagrammes d’architecture utilisent des représentations génériques des composants dans la plupart des scénarios.
Authentifier les applications clientes via un fournisseur d’identité externe
Téléchargez un fichier Visio de cette architecture.
Contraintes du scénario
Ce scénario présente les contraintes suivantes :
Les applications clientes utilisent un fournisseur d’identité externe compatible avec OpenID Connect (OIDC) tel qu’Okta, Auth0, ou des fournisseurs d’identité sociale.
Les applications clientes s’authentifient contre un locataire Microsoft Entra différent de celui du plan de données Azure OpenAI.
Ces contraintes peuvent s’appliquer aux exemples suivants :
Applications clientes existantes qui s’authentifient déjà contre un fournisseur OIDC externe ou Microsoft Entra ID et qui s’intègrent aux instances Azure OpenAI.
Applications clientes qui doivent authentifier de manière cohérente les utilisateurs de plusieurs fournisseurs d’identité.
Connexion directe à Azure OpenAI
Si les applications clientes dans ces scénarios se connectent directement à Azure OpenAI sans utiliser de passerelle, elles doivent utiliser une authentification basée sur des clés pour s’authentifier auprès d’Azure OpenAI. L’authentification basée sur des clés introduit des préoccupations de sécurité supplémentaires. Vous devez stocker et faire tourner les clés en toute sécurité, et vous ne pouvez pas attribuer à différents clients des configurations de contrôle d’accès en fonction des rôles (RBAC) pour les déploiements de modèles individuels.
Introduire une passerelle
Téléchargez un fichier Visio de cette architecture.
Une passerelle résout les défis de ce scénario de la manière suivante :
La passerelle utilise Open Authorization (OAuth) pour authentifier les utilisateurs via leurs fournisseurs d’identité externes existants. La passerelle valide les jetons d’accès des utilisateurs authentifiés, tels qu’un JSON Web Token (JWT), que le fournisseur d’identité génère. Ensuite, la passerelle accorde l’autorisation à l’instance Azure OpenAI sous-jacente.
Vous n’avez pas besoin de gérer les clés des clients. Cette approche élimine les risques de sécurité liés à l’authentification basée sur des clés.
La passerelle se connecte à Azure OpenAI en utilisant une identité managée, ce qui améliore la sécurité via un RBAC Azure avec les privilèges les plus faibles.
Recommandations pour ce scénario
Ajoutez plus d’étendues OAuth à l’enregistrement de votre application dans votre fournisseur d’identité pour permettre des autorisations granulaires aux consommateurs. Ces étendues permettent aux applications clientes de demander l’autorisation d’effectuer des opérations spécifiques dans votre passerelle, y compris l’accès à Azure OpenAI.
Configurez ce scénario pour API Management en utilisant des stratégies entrantes. Utilisez la
validate-jwtstratégie pour appliquer l’existence, la validité et les valeurs d’attributs d’un JWT pris en charge.
Raisons d’éviter une passerelle pour ce scénario
Si une seule application intelligente accède à Azure OpenAI, il est plus facile de configurer l’authentification et l’autorisation des utilisateurs au sein de l’application plutôt que via la passerelle. Utilisez cette approche pour attribuer le RBAC Azure nécessaire afin d’authentifier de manière sécurisée l’application intelligente avec Azure OpenAI.
Authentifier les applications clientes via des certificats
Téléchargez un fichier Visio de cette architecture.
Contraintes du scénario
Ce scénario présente les contraintes suivantes :
Vous souhaitez utiliser des certificats pour authentifier les applications clientes.
Les applications clientes ne peuvent pas utiliser, ou vous ne souhaitez pas utiliser, Microsoft Entra ID ou d’autres fournisseurs OIDC pour l’authentification.
Les clients ne peuvent pas utiliser, ou vous ne souhaitez pas utiliser, une identité fédérée pour l’authentification.
Ces contraintes peuvent s’appliquer aux exemples suivants :
Un client qui s’authentifie auprès d’Azure OpenAI est une machine ou un appareil, et aucune interaction utilisateur n’a lieu.
Votre organisation exige que vous utilisiez des certificats pour l’authentification en raison des normes de sécurité et des réglementations de conformité.
Vous souhaitez fournir à plusieurs applications clientes des options d’authentification basées sur leur environnement, y compris l’utilisation de certificats clients.
Connexion directe à Azure OpenAI
Azure OpenAI ne prend pas en charge nativement l’authentification par certificat client. Pour prendre en charge ce scénario sans passerelle, l’application intelligente doit utiliser l’authentification par certificat pour l’utilisateur et soit une clé API, soit une identité managée pour authentifier les requêtes à l’instance Azure OpenAI. Vous devez mettre en œuvre la logique d’authentification par certificat dans chaque client. Dans ce scénario, l’authentification basée sur des clés introduit des risques et une surcharge de gestion si vous vous connectez directement à Azure OpenAI depuis les clients.
Introduire une passerelle
Téléchargez un fichier Visio de cette architecture.
Vous pouvez introduire une passerelle dans cette architecture qui décharge la validation des certificats clients des clients. La passerelle valide le certificat numérique client que l’application intelligente présente et vérifie l’émetteur, la date d’expiration, l’empreinte numérique et les listes de révocation. La passerelle doit utiliser une identité managée pour s’authentifier auprès d’Azure OpenAI. La passerelle doit également utiliser Azure Key Vault pour stocker l’autorité de certification (CA) racine. Utilisez cette approche pour centraliser la validation des certificats clients, ce qui réduit la surcharge de maintenance.
Une passerelle offre plusieurs avantages dans ce scénario :
Vous utilisez l’identité managée de la passerelle au lieu des clés d’accès, ce qui élimine le risque de vol de clés et réduit la charge de maintenance liée à la rotation des clés.
Vous pouvez centraliser la validation des certificats, garantissant ainsi que vous appliquez des politiques de sécurité cohérentes pour évaluer les certificats numériques des clients pour toutes les applications intelligentes.
Vous pouvez décharger la validation des certificats sur la passerelle, ce qui simplifie le code client.
Recommandations pour ce scénario
Vérifiez toute la chaîne de certificats, y compris l’AC racine et les certificats intermédiaires, lorsque vous validez les certificats. Une vérification complète garantit l’authenticité du certificat et empêche l’accès non autorisé.
Faites tourner et renouvelez régulièrement les certificats clients pour minimiser le risque de compromission des certificats. Utilisez Key Vault pour automatiser ce processus et garder les certificats à jour. Définissez des alertes pour les prochaines expirations de certificats afin d’éviter des interruptions de service au niveau de la passerelle.
Mettez en œuvre la sécurité de transport mutuelle (mTLS) pour garantir que le client et le serveur s’authentifient mutuellement. Cette stratégie offre une couche de sécurité supplémentaire. Pour configurer la passerelle afin d’appliquer le mTLS, définissez les politiques et les contraintes appropriées.
Utilisez la
validate-client-certificatestratégie dans API Management pour valider les certificats clients référencés par un Azure Key Vault. Cette politique valide le certificat client que l’application cliente présente et vérifie l’émetteur, la date d’expiration, l’empreinte numérique et les listes de révocation.
Raisons d’éviter une passerelle pour ce scénario
Dans des environnements simples avec peu de clients, le coût de gestion de la sécurité et de la gestion des certificats dans le client peut l’emporter sur la complexité ajoutée de l’introduction d’une passerelle. De plus, les passerelles peuvent devenir des points de défaillance uniques, augmenter la latence en raison des couches ajoutées et entraîner une dépendance aux fournisseurs si vous choisissez des solutions commerciales plutôt que des implémentations personnalisées.
Vous devez évaluer soigneusement vos besoins spécifiques, la disponibilité des ressources et l’importance de vos applications avant de mettre en œuvre une passerelle pour l’authentification par certificat client.
Authentifier plusieurs applications clientes via des clés pour accéder à une instance Azure OpenAI partagée
Téléchargez un fichier Visio de cette architecture.
Contraintes du scénario
Ce scénario présente les contraintes suivantes :
- Plusieurs applications clientes accèdent à une instance Azure OpenAI partagée.
- Les clients ne peuvent pas utiliser, ou vous ne souhaitez pas utiliser, Microsoft Entra ID pour l’authentification.
- Les clients ne peuvent pas utiliser, ou vous ne souhaitez pas utiliser, une identité fédérée pour l’authentification.
- Vous souhaitez utiliser l’authentification basée sur les clés pour les applications clientes.
Ces contraintes peuvent s’appliquer aux exemples suivants :
Vous déployez des applications clientes dans plusieurs environnements, y compris Azure, sur site ou d’autres fournisseurs de cloud.
Une organisation doit fournir Azure OpenAI à différentes équipes et définir des limites d’accès et d’utilisation spécifiques pour chaque équipe.
Connexion directe à Azure OpenAI
Azure OpenAI prend en charge l’authentification basée sur des clés partagées. Azure OpenAI expose une clé primaire et une clé secondaire. La clé secondaire sert à faciliter la rotation des clés. Elle ne fournit pas d’isolation d’identité client. Lorsque vous authentifiez plusieurs clients directement avec Azure OpenAI dans ce scénario, chaque client partage la même clé. Cette implémentation présente les défis suivants :
Vous ne pouvez pas révoquer les autorisations pour des clients spécifiques car chaque client partage la même clé.
Vous ne pouvez pas donner à différents clients des droits d’accès différents à différents modèles dans le même déploiement d’instance Azure OpenAI.
Vous ne pouvez pas différencier un client d’un autre du point de vue de la journalisation.
Introduire une passerelle
Téléchargez un fichier Visio de cette architecture.
Vous pouvez introduire une passerelle dans cette architecture qui délivre une clé dédiée à chaque application cliente. API Management utilise le concept d’abonnements pour fournir des clés dédiées aux clients. La passerelle doit utiliser une identité managée pour s’authentifier auprès d’Azure OpenAI.
Une passerelle offre plusieurs avantages dans ce scénario :
Vous pouvez révoquer l’accès à une application cliente sans affecter les autres clients.
Vous n’avez pas besoin de mettre à jour toutes les configurations des clés des clients avant de faire tourner les clés, ce qui rend la rotation des clés plus facile logiquement. Vous pouvez faire tourner les clés dédiées à chaque client après avoir mis à jour la configuration client.
Vous pouvez identifier de manière unique chaque client d’un point de vue journalisation.
La passerelle applique des limites de débit et des quotas pour chaque client indépendamment.
Recommandations pour ce scénario
Améliorez la surveillance des métriques liées aux requêtes API. Lorsque vous utilisez une identité managée depuis une passerelle, la traçabilité de l’utilisateur et de l’application cliente dans les journaux Azure OpenAI ne s’améliore pas. La passerelle doit fournir des journaux associés à la demande, tels que les ID des clients et des utilisateurs demandeurs.
Assurez-vous que la passerelle prend des décisions de routage vers les déploiements de modèles appropriés en fonction de l’identité du client lorsque vous routez plusieurs requêtes d’applications clientes via une passerelle vers une instance Azure OpenAI partagée. Pour plus d’informations, consultez Utiliser une passerelle devant plusieurs déploiements Azure OpenAI.
Authentifier les applications clientes qui accèdent à plusieurs instances Azure OpenAI
Téléchargez un fichier Visio de cette architecture.
Contraintes du scénario
Ce scénario présente les contraintes suivantes :
- Les applications clientes se connectent à plusieurs instances Azure OpenAI dans une ou plusieurs régions.
- Les clients ne peuvent pas utiliser, ou vous ne souhaitez pas utiliser, Microsoft Entra ID ou d’autres fournisseurs OIDC pour l’authentification.
- Vous souhaitez utiliser l’authentification basée sur les clés pour les applications clientes.
Ces contraintes peuvent s’appliquer aux exemples suivants :
Les applications clientes doivent répartir leurs charges de travail géographiquement pour réduire la latence et améliorer les performances.
Les applications clientes tentent d’optimiser leurs quotas de jetons par minute en déployant des instances dans plusieurs régions.
Une organisation exige des capacités de basculement transparentes et de récupération d’urgence pour garantir une continuité d’exploitation. Ainsi, ils gèrent une stratégie de double déploiement, telle qu’une stratégie consistant en un déploiement à débit provisionné et un déploiement en fonction de la consommation.
Les applications clientes doivent utiliser des fonctionnalités spécifiques du modèle qui ne sont disponibles que dans certaines régions Azure.
Connexion directe à plusieurs instances Azure OpenAI
Lorsque les applications clientes se connectent directement à plusieurs instances Azure OpenAI, chaque client doit stocker la clé pour chaque instance. En plus des considérations de sécurité liées à l’utilisation des clés, il y a une charge de gestion accrue concernant la rotation des clés.
Introduire une passerelle
Téléchargez un fichier Visio de cette architecture.
Lorsque vous utilisez une passerelle pour gérer les applications clientes qui accèdent à plusieurs déploiements Azure OpenAI, vous obtenez les mêmes avantages qu’une passerelle qui gère plusieurs applications clientes via des clés pour accéder à une instance Azure OpenAI partagée. Vous rationalisez également le processus d’authentification car vous utilisez une seule identité managée définie par l’utilisateur pour authentifier les requêtes de la passerelle vers plusieurs instances Azure OpenAI. Mettez en œuvre cette approche pour réduire la surcharge opérationnelle globale et minimiser les risques de mauvaise configuration des clients lorsque vous travaillez avec plusieurs instances.
Un exemple de la façon dont une passerelle est utilisée dans Azure pour décharger l’identité vers un intermédiaire est la ressource Azure AI Services. Dans cette implémentation, vous vous authentifiez auprès de la passerelle et la passerelle gère l’authentification auprès des différents services Azure AI tels que Custom Vision ou Speech. Bien que cette implémentation soit similaire, elle ne traite pas de ce scénario.
Recommandations pour ce scénario
Mettez en œuvre des techniques de répartition de charge pour distribuer les requêtes API sur plusieurs instances d’Azure OpenAI afin de gérer un trafic important et de garantir une haute disponibilité. Pour plus d’informations, consultez Utiliser une passerelle devant plusieurs déploiements ou instances Azure OpenAI.
Corrélez l’utilisation des jetons pour chaque locataire au niveau de la passerelle lorsque vous implémentez des scénarios multitenant avec plusieurs instances Azure OpenAI. Cette approche garantit que vous suivez l’utilisation totale des jetons, quel que soit le backend d’instance Azure OpenAI auquel la requête est transférée.
Recommandations générales
Lorsque vous intégrez Azure OpenAI via une passerelle, il y a plusieurs recommandations transversales à considérer qui s’appliquent à tous les scénarios.
Utilisez Gestion des API Azure au lieu de créer votre propre solution pour une orchestration d’API efficace, une intégration transparente avec d’autres services Azure et des économies de coûts en réduisant les efforts de développement et de maintenance. API Management assure une gestion sécurisée des API en prenant directement en charge l’authentification et l’autorisation. Il s’intègre avec des fournisseurs d’identité, tels que Microsoft Entra ID, qui permet OAuth 2.0 et fournit une autorisation basée sur des politiques. De plus, API Management utilise des identités managées pour un accès sécurisé et peu de maintenance à Azure OpenAI.
Combiner les scénarios pour une solution de passerelle complète
Dans des applications réelles, vos cas d’utilisation peuvent couvrir plusieurs scénarios de cet article. Par exemple, vous pourriez avoir des applications clientes qui s’authentifient via un fournisseur d’identité externe et nécessitent un accès à plusieurs instances Azure OpenAI.
Téléchargez un fichier Visio de cette architecture.
Pour construire une passerelle qui prend en charge vos exigences spécifiques, combinez les recommandations de ces scénarios pour une approche complète.
Appliquer des politiques de passerelle
Avant qu’une passerelle n’envoie des requêtes aux instances Azure OpenAI, assurez-vous d’appliquer des politiques d’authentification et d’autorisation entrantes. Pour garantir que la passerelle ne transfère que des requêtes authentifiées et autorisées, utilisez des jetons d’accès utilisateur provenant d’un fournisseur d’identité ou une validation de certificats pour mettre en œuvre cette approche.
Pour permettre un contrôle plus granulaire, mettez en œuvre plus d’étendues d’autorisation avec des rôles et des permissions pour les applications clientes dans votre passerelle. Utilisez ces étendues pour permettre des opérations spécifiques en fonction des besoins de l’application cliente. Cette approche améliore la sécurité et la gestion.
Pour la validation des jetons d’accès, assurez-vous de valider toutes les revendications clés enregistrées telles que iss, aud, exp et nbf, ainsi que toute revendication spécifique à la charge de travail, telle que les appartenances à des groupes ou les rôles d’application.
Utiliser les identités managées Azure
Pour simplifier l’authentification dans tous les scénarios d’applications clientes, utilisez les identités managées Azure pour centraliser la gestion de l’authentification. Cette approche réduit la complexité et les risques associés à la gestion de plusieurs clés API ou identifiants dans les applications clientes.
Les identités managées prennent en charge nativement le RBAC Azure, elles garantissent donc que la passerelle n’a que le niveau le plus bas de permissions nécessaire pour accéder aux instances Azure OpenAI. Pour réduire le risque d’accès non autorisé et simplifier la conformité avec les politiques de sécurité, combinez les identités managées avec d’autres méthodes qui désactivent l’authentification alternative.
Implémentez une observabilité complète
Lorsque vous mettez en œuvre une passerelle avec une identité managée, cela réduit la traçabilité car l’identité managée représente la passerelle elle-même, et non l’utilisateur ou l’application qui fait la requête. Il est donc essentiel d’améliorer l’observabilité des métriques liées aux requêtes API. Pour maintenir la visibilité sur les modèles d’accès et l’utilisation, les passerelles devraient fournir plus de métadonnées de traçabilité, telles que les identifiants du client et de l’utilisateur demandeur.
La journalisation centralisée de toutes les requêtes qui passent par la passerelle vous aide à maintenir une piste d’audit. Une piste d’audit centralisée est particulièrement importante pour le dépannage, la conformité et la détection des tentatives d’accès non autorisées.
Mise en cache des adresses en toute sécurité
Si votre passerelle d’API est responsable de la mise en cache des achèvements ou d’autres résultats d’inférence, vérifiez que l’identité du demandeur est considérée dans la logique du cache. Ne retournez pas de résultats mis en cache pour les identités qui ne sont pas autorisées à recevoir ces données.
Implémentations de passerelle
Azure ne fournit pas de solution clé en main ou une architecture de référence complète pour générer la passerelle dans cet article. Vous devez donc générer et exploiter la passerelle. La gestion des API Azure peut être utilisée pour créer une solution PaaS par le biais de stratégies intégrées et personnalisées. Azure fournit également des exemples d’implémentations prises en charge par la communauté qui couvrent les cas d’usage dans cet article. Consultez ces exemples lorsque vous construisez votre propre solution de passerelle. Pour plus d’informations, consultez la vidéo Learn Live : identité et sécurité des applications Azure OpenAI.
Contributeurs
Les contributeurs suivants ont initialement écrit cet article.
Principaux auteurs :
- Lizet Pena De Sola | Ingénieure cliente senior, FastTrack pour Azure
- Bappaditya Banerjee | Ingénieur client senior, FastTrack pour Azure
- James Croft | Ingénieur client, ISV & Digital Native Center of Excellence
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.
Étapes suivantes
- RBAC pour Azure OpenAI
- Utiliser des identités managées dans API Management
- Stratégies dans Gestion des API
- Authentification et autorisation des API dans Gestion des API
- Protéger une API dans API Management en utilisant OAuth 2.0 et Microsoft Entra ID
- Sécuriser les services backend en utilisant l’authentification par certificat client dans API Management