Obligatoire
La clé est stockée dans un gestionnaire de secrets côté serveur ou dans une configuration d’environnement protégée.
Ne l’intégrez pas au contrôle de version.
Guide de sécurité
Créez des intégrations plus sûres grâce aux bonnes pratiques de sécurité des clés API
Les bonnes pratiques de sécurité des clés API contribuent à maintenir l’utilité d’une connexion à une API d’IA sans faciliter l’exposition de données d’identification sensibles. Ce guide explique les contrôles pratiques à mettre en place avant, pendant et après une intégration.
Comment cela se faisait auparavant
Les anciennes intégrations d’API d’IA traitaient souvent une clé comme une simple chaîne pratique plutôt que comme un identifiant doté d’un cycle de vie.
- ExpositionUne clé placée directement dans le code du navigateur peut être copiée par toute personne qui charge l’application.
- ContrôleLes variables d’environnement réduisent les fuites dans le code source, mais elles ne remplacent ni le contrôle d’accès ni la rotation des clés.
- SéparationUne clé distincte pour chaque environnement permet d’enquêter sur les incidents et de révoquer les accès avec davantage de précision.
- Par défautLe choix par défaut le plus sûr consiste à conserver la clé sur un serveur et à n’y envoyer que les requêtes approuvées.
Comment cela se fait aujourd’hui
Un plan de sécurité pour une API d’IA doit préciser ce que l’intégration ne peut pas garantir, puis proposer une solution pratique pour chaque limitation.
- Elle ne peut pas rendre une clé côté client privée
-
Tout ce qui est intégré à un navigateur, à un package mobile ou à un dépôt public peut finir par être extrait et réutilisé.
Solution de contournementDéplacez les identifiants vers un proxy côté serveur et n’exposez que l’opération précise dont le client a besoin.
- Elle ne peut pas empêcher toute requête valide d’être coûteuse
-
Un identifiant volé ou utilisé à mauvais escient peut malgré tout générer du trafic, même lorsque le format de la requête semble légitime.
Solution de contournementDéfinissez des limites par fournisseur, des quotas d’application, des budgets de requêtes et des alertes en cas de volume inhabituel.
- Il ne peut pas identifier une personne à partir d’un identifiant partagé
-
Une seule clé utilisée par toute une équipe rend difficile l’attribution de l’activité ou l’investigation d’un workflow compromis.
Solution de contournementUtilisez des identifiants distincts ou des identités de service authentifiées pour les personnes, les environnements et les services.
- Il ne peut pas réparer une clé qui a déjà fuité
-
Supprimer une publication publique ou retirer une entrée de journal n’efface pas les copies effectuées par des robots d’exploration, des forks ou des systèmes de surveillance.
Solution de contournementRévoquez la clé exposée, émettez-en une nouvelle, examinez l’utilisation et documentez l’incident.
Ce qui a changé
Les pratiques modernes liées aux API d’IA traitent les identifiants comme des secrets gérés. Avant de connecter une application, vérifiez ces exigences au lieu de vous fier à une seule variable cachée.
Obligatoire
La production, la préproduction, le développement local et les tests automatisés utilisent des identifiants distincts.
L’isolation limite l’étendue des dommages.
Obligatoire
L’application authentifie les utilisateurs avant d’autoriser les requêtes qui consomment l’API d’IA.
Une clé de fournisseur n’est pas une identité d’utilisateur final.
Obligatoire
Les journaux excluent les en-têtes d’autorisation, les corps de requête complets et les détails d’erreur contenant des secrets.
Examinez les journaux de l’application et du fournisseur.
Obligatoire
La rotation et la révocation ont un responsable, une procédure documentée et un processus de récupération testé.
Un plan n’est utile que lorsqu’il peut être mis en œuvre.
Facultatif
Les alertes d’utilisation et les limites de requêtes sont configurées pour le fournisseur et l’application.
Fortement recommandé pour la production.
Qui a changé
Le changement est particulièrement visible dans les équipes qui sont passées d’un simple script expérimental à un service d’API d’IA partagé, utilisé par de vrais utilisateurs et soumis à des responsabilités opérationnelles.
-
1
L’API d’IA est-elle sûre à utiliser
Ce guide axé sur la confiance explique comment évaluer les risques avant de s’appuyer sur un flux de travail utilisant une API d’IA.
-
2
clé API d’IA gratuite
Ce guide d’accès précise les points à vérifier avant d’utiliser un identifiant gratuit dans un test ou un prototype.
-
3
fournisseurs d’API d’IA
Cette présentation des fournisseurs aide à comparer l’authentification, les limites, l’accès aux modèles et les politiques opérationnelles.
Qui a changé
Choisissez le modèle de contrôle qui correspond à l’étape et à la configuration de votre intégration d’API d’IA, plutôt que celui qui est simplement le plus rapide à intégrer dans une démonstration.
1
Vous créez un client pour navigateur ou mobile
Utilisez un proxy côté serveur avec authentification des utilisateurs, validation des requêtes et limites par utilisateur.
Le client a besoin d’accéder à une fonctionnalité d’API d’IA, et non aux identifiants du fournisseur.
2
Vous exécutez un service backend privé
Stockez la clé en dehors du dépôt, limitez sa portée lorsque cela est possible et séparez-la par environnement.
Un backend peut protéger le secret tout en permettant à l’application d’accéder à l’API d’IA de manière contrôlée.
3
Vous testez localement une intégration d’API d’IA
Utilisez une clé de développement temporaire, un petit budget de requêtes et des fixtures ou des mocks lorsque les appels réels ne sont pas nécessaires.
Les scripts locaux, les terminaux partagés, les captures d’écran et les journaux de débogage sont des points d’exposition accidentelle fréquents.
Qui a changé
La différence entre avant et après ne tient pas à un prompt ou à un modèle plus complexe. Elle réside dans la façon dont l’autorité est répartie et dans la rapidité avec laquelle un identifiant compromis peut être neutralisé.
Clé dans le client
Gardez l’autorité derrière la limite de l’application.
Qui a changé
Les contrôles de sécurité sont plus faciles à adopter avant qu’une intégration à une API d’IA ne devienne difficile à modifier.
Mettez en pratique un accès plus sûr à l’API d’IA
Commencez par une route serveur protégée, un identifiant de développement distinct et une réponse documentée en cas d’exposition présumée. Ajoutez ensuite une journalisation rigoureuse, des limites, la rotation et la revue à mesure que l’intégration évolue. L’objectif n’est pas le secret absolu, mais un accès contrôlé, une responsabilité clairement définie et un rayon d’impact limité en cas de problème.
- Gardez les clés des fournisseurs hors des navigateurs et des dépôts publics.
- Séparez les identifiants par environnement et par service.
- Effectuez immédiatement une rotation en cas d’exposition présumée.
Sa propre FAQ
Ces réponses abordent les questions pratiques que se posent les personnes qui appliquent les bonnes pratiques de sécurité des clés API à un projet utilisant une API d’IA.
Stockez-la sur le serveur, dans une configuration d’environnement protégée ou dans un gestionnaire de secrets dédié. La clé ne doit pas apparaître dans le code JavaScript du navigateur, les bundles d’applications mobiles, le contrôle de version, les captures d’écran ou les journaux d’application ordinaires.
Une variable d’environnement est plus sûre qu’une clé inscrite en dur dans le code, mais elle ne constitue qu’une seule couche de protection. L’accès à l’hôte, au système de déploiement, aux journaux, au processus de compilation et aux rapports d’erreur doit également être restreint et contrôlé.
Non. Des identifiants distincts permettent de révoquer une clé de développement sans interrompre la production et facilitent l’attribution d’une activité inhabituelle. Utilisez des clés différentes pour le travail local, la préproduction, la production et les tests automatisés lorsque cela est possible.
Révoquez ou désactivez immédiatement la clé, puis créez un remplacement par un canal fiable. Examinez l’utilisation et les journaux pour détecter toute activité non autorisée, supprimez le secret de son emplacement d’origine et consignez ce qui s’est passé afin de réduire les risques de récurrence.
Vous devez considérer toute clé fournie à un navigateur ou à un client mobile comme publique. Placez l’identifiant derrière une route côté serveur, authentifiez l’appelant, validez la requête et appliquez des limites avant de transmettre les appels approuvés à l’API d’IA.