Méthodes d’authentification prises en charge par Azure OpenAI
Azure OpenAI prend en charge plusieurs méthodes d’authentification pour garantir un accès sécurisé et contrôlé à ses ressources. Les méthodes principales sont les suivantes :
- Clés API : Azure OpenAI prend également en charge l’authentification basée sur des clés API. Les clés API sont générées dans le portail Azure et peuvent être utilisées pour authentifier les requêtes auprès du service Azure OpenAI. Cette méthode d’authentification n’est pas recommandée du point de vue de la sécurité et ne doit être utilisée qu’en dernier recours. Si vous devez utiliser cette méthode d’authentification, il est important de gérer en toute sécurité les clés API et de les faire pivoter régulièrement pour réduire le risque d’accès non autorisé.
- ID Microsoft Entra : Cette méthode tire parti des fonctionnalités robustes de gestion des identités et des accès de Microsoft Entra. Les utilisateurs et les applications s’authentifient à l’aide d’identités Microsoft Entra, qui peuvent être des comptes d’utilisateur traditionnels ou des identités managées. Cette méthode garantit que seuls les utilisateurs authentifiés et autorisés peuvent accéder aux ressources Azure OpenAI.
- EntraIdentités Managées : Les identités gérées pour les ressources Azure fournissent une identité gérée automatiquement dans Microsoft Entra pour les applications à utiliser lors de la connexion aux ressources qui prennent en charge l’authentification Microsoft Entra. Ces identités peuvent être affectées par le système, ce qui signifie qu’elles sont liées à une ressource Azure spécifique, ou affectées par l’utilisateur, ce qui permet de partager une identité unique entre plusieurs ressources. Les identités managées simplifient la gestion des informations d’identification et améliorent la sécurité en éliminant la nécessité d’informations d’identification codées en dur dans le code de l’application.
Pourquoi les identités managées sont plus sécurisées que les clés API
Les identités managées dans Microsoft Azure offrent une alternative plus sécurisée aux clés API pour plusieurs raisons :
- Les identités managées éliminent la nécessité pour les développeurs de gérer directement les informations d’identification, ce qui réduit le risque d’exposition accidentelle ou d’utilisation abusive.
- Lorsque vous utilisez des clés API, les développeurs doivent incorporer ces clés dans leur code d’application ou leurs fichiers de configuration.
Les clés API peuvent être exposées par inadvertance via des référentiels de code source, des journaux ou d’autres moyens. Cette exposition peut entraîner des accès non autorisés et de potentielles violations de sécurité. En revanche, les identités managées fournissent une identité managée automatiquement que les applications utilisent lors de la connexion aux ressources qui prennent en charge l’authentification Microsoft Entra (précédemment Azure AD). Cela signifie que les informations d’identification ne sont pas stockées dans le code de l’application, ce qui réduit le risque de fuites et d’accès non autorisés.
En outre, les identités managées simplifient le processus d’authentification en permettant aux services Azure de s’authentifier auprès d’autres services Azure en toute sécurité, sans avoir besoin d’informations d’identification explicites. Pour ce faire, utilisez des jetons émis par Microsoft Entra, qui sont automatiquement gérés et renouvelés, ce qui garantit que les informations d’identification sont toujours à jour et réduisent le risque de vol d’informations d’identification. Les clés API, d’autre part, sont statiques et nécessitent une rotation manuelle, qui peut être sujette à des erreurs et souvent négligée, ce qui entraîne des vulnérabilités potentielles. En utilisant des identités managées, les développeurs peuvent tirer parti des fonctionnalités de sécurité intégrées d’Azure, telles que le contrôle d’accès en fonction du rôle (RBAC), pour accorder des autorisations précises aux ressources, en améliorant davantage la sécurité.
Microsoft vous recommande d’utiliser l’identité managée plutôt que des clés API lors de l’authentification auprès d’Azure OpenAI ou d’un autre service Azure qui prend en charge l’identité managée.
Différences entre l’utilisation des clés API et des identités managées dans Azure OpenAI
Évaluons l'impact d'une fuite d'ID client par rapport à une fuite de clé API.
Une clé API fonctionne de la même façon qu’un mot de passe normal. Si elle est compromise, toute personne disposant de la clé peut accéder à la ressource. Pour Azure OpenAI, cela signifie une utilisation illimitée des modèles d’IA comme GPT-4. Si le réseau est accessible publiquement, l’impact sur la sécurité pourrait être encore plus grand.
À l’inverse, si l’ID client est divulguée, les risques sont minimes. Cela est dû au fait que l’ID client seul ne peut pas établir de connexion à Azure OpenAI. Pour utiliser une identité managée, le service doit fonctionner sur Azure et même si Azure OpenAI est public, vous ne pouvez pas vous connecter à partir d’un environnement local ou sur un réseau à l’aide d’une application.
En résumé, comparé aux conséquences d'une fuite de clé API, l'exploitation d'un ID client divulgué implique plusieurs étapes, ce qui rend son exploitation plus difficile pour les acteurs malveillants.
Pour ces raisons, les identités managées offrent une méthode plus sûre pour gérer les opérations par rapport aux clés API. Il est recommandé dans les termes les plus forts possibles d’utiliser l’identité managée plutôt que des clés API lors de l’authentification auprès d’Azure OpenAI ou d’un autre service Azure qui prend en charge l’identité managée.
Identités attribuées par le système et l’utilisateur
Lors de la création d’une application Azure OpenAI, il est essentiel de comprendre la distinction entre les identités affectées par le système et les identités affectées par l’utilisateur pour une gestion optimale de la sécurité et des ressources.
- Les identités affectées par le système sont créées et gérées par Azure pour une ressource spécifique. Lorsqu’une ressource est supprimée, son identité affectée par le système associée est également supprimée, ce qui garantit que le cycle de vie de l’identité est étroitement lié à la ressource à laquelle elle appartient. Ce type d’identité est idéal pour les scénarios où l’identité doit uniquement être utilisée par une seule ressource, en fournissant de la simplicité et en réduisant la surcharge administrative, car Azure gère les informations d’identification.
- Les identités affectées par l’utilisateur sont créées indépendamment de n’importe quelle ressource spécifique et peuvent être partagées entre plusieurs ressources. Cela les rend hautement polyvalentes pour les applications qui nécessitent une identité cohérente entre différentes ressources, ce qui facilite la gestion des autorisations et des contrôles d’accès. Les identités affectées par l’utilisateur persistent même après la suppression des ressources, ce qui permet une plus grande flexibilité dans le redéploiement et la réutilisation des identités.
Le choix entre les identités affectées par le système et les identités affectées par l’utilisateur dépend des besoins spécifiques de votre application. Pour les applications à ressource unique où la simplicité et la gestion minimale sont des priorités, les identités affectées par le système sont généralement le meilleur choix. À l’inverse, pour les applications qui nécessitent une identité partagée entre plusieurs ressources, les identités affectées par l’utilisateur offrent une plus grande flexibilité et sont réutilisables.
