Coffres d'informations d'identification des fournisseurs pour les passerelles IA multimodèles : accès séparé au temps d'exécution, à l'administration, à la facturation et au BYOK
Un modèle de coffre-fort d'informations d'identification pratique pour les passerelles IA multimodèles : classez les clés des fournisseurs en amont, isolez le runtime de l'accès administrateur, liez les informations d'identification BYOK aux locataires, effectuez une rotation en toute sécurité et auditez chaque décision d'identification.
Les clés API en aval et les informations d'identification du fournisseur en amont résolvent différents problèmes. Une clé de développeur émise par votre passerelle identifie l'application, l'équipe, le locataire, le budget et le contexte politique. Une clé de fournisseur en amont permet à la passerelle de dépenser de l'argent et d'accéder aux modèles dans un compte de fournisseur. En les traitant comme le même type de secret, les équipes se retrouvent avec une clé sans restriction dans un projet partagé, des informations d'identification d'administrateur dans les services d'exécution et aucun moyen fiable de répondre à quel locataire a causé quels frais côté fournisseur.
Le modèle pratique est un coffre-fort d'informations d'identification de fournisseur : un plan de contrôle dédié pour l'importation, la classification, le stockage, la sélection, la rotation et l'audit des informations d'identification en amont. Il doit se trouver derrière le routeur, le grand livre de facturation, le moteur de stratégie et le flux de travail des opérations, et non dans le code de l'application, les fichiers de configuration du modèle, les enregistrements des locataires ou les événements d'analyse.
Le problème du lecteur : les identifiants en amont deviennent une infrastructure invisible
La plupart des déploiements multimodèles commencent par un objectif simple : acheminer une requête compatible OpenAI vers le meilleur fournisseur disponible. Ensuite, d'autres comptes apparaissent : un projet de fournisseur pour la production, un autre pour l'évaluation, un espace de travail Anthropic pour une unité commerciale, un projet Google Cloud pour Gemini et plusieurs clés fournies par le client pour les contrats BYOK.
Le risque ne réside pas simplement dans une fuite secrète. C'est une perte de contexte d'autorisation. Une clé de fournisseur valide peut être techniquement capable d'appeler un point de terminaison, mais la passerelle doit toujours savoir si cette clé est autorisée pour ce locataire, cette famille de modèles, cette politique de conservation des données, ce budget, cette région et ce chemin d'automatisation.
Fait : les plates-formes des fournisseurs exposent différentes limites de compte et types d'identifiants. OpenAI documente les projets et les comptes de service, ainsi que les autorisations de clé API du compte de service par défaut pour un accès en lecture et en écriture aux ressources API du projet. OpenAI expose également les objets clés de l'API d'administration séparément de l'utilisation ordinaire de l'API de projet/d'exécution. Anthropic documente les espaces de travail comme une limite organisationnelle et indique que les points de terminaison de l'API d'administration nécessitent des clés d'API d'administration distinctes des clés d'API standard ; Anthropic note également que les clés API sont liées à l'espace de travail dans lequel elles sont créées et ne peuvent pas être déplacées entre les espaces de travail. La documentation sur la clé API Gemini de Google indique que chaque clé API Gemini est associée à un projet Google Cloud et recommande des restrictions d'API pour réduire les dommages si une clé est compromise.
Recommandation : ne créez pas un champ générique « provider_key » et dites que c'est terminé. Créez un inventaire des informations d'identification qui préserve les limites spécifiques au fournisseur tout en exposant un modèle de politique normalisé à la passerelle.
Définir une taxonomie des identifiants avant d'accepter les clés
Un coffre-fort doit rejeter les informations d'identification ambiguës. Au moment de l'importation, l'opérateur ou le flux de travail d'automatisation doit classer les informations d'identification. Utilisez au minimum ces catégories :
- Identifiants d'inférence d'exécution : utilisés par la passerelle pour appeler des points de terminaison d'inférence de modèle tels que le chat, les réponses, les intégrations, la modération, la transcription ou la génération d'images, en fonction de la prise en charge du fournisseur.
- Identifiants d'automatisation de l'administrateur : utilisés pour gérer les organisations, les espaces de travail, les projets, les utilisateurs, les clés ou les ressources administratives côté fournisseur. Ceux-ci ne doivent jamais figurer sur le chemin de la requête d'exécution.
- Identifiants de facturation et de création de rapports : utilisés pour récupérer des rapports d'utilisation, de factures, de coûts ou d'organisation lorsque les fournisseurs prennent en charge ces API. Gardez-les séparés des clés d'inférence afin que les tâches de création de rapports ne puissent pas générer l'utilisation du modèle.
- Identifiants d'évaluation uniquement : utilisés par les workflows d'analyse comparative, d'assurance qualité, de migration ou de préparation. Ils doivent avoir des quotas faibles, des labels environnementaux clairs et aucune éligibilité en matière de production de secours.
- Identifiants BYOK du client : clés fournies par le client liées à un locataire, un compte de fournisseur, un contrat et une politique de données spécifiques. Ils ne doivent pas être regroupés dans un routage partagé, sauf si le client l'accepte explicitement.
Cette taxonomie n'est pas qu'une simple documentation. Il doit piloter les workflows de contrôle d’accès, d’éligibilité au routage, d’alerte et de rotation. Si un identifiant est importé sans catégorie, propriétaire, limite de compte fournisseur et utilisation autorisée, il doit rester désactivé.
Stockez les secrets dans un coffre-fort, pas dans les enregistrements de produits
Le coffre-fort doit être le seul composant capable de déchiffrer les informations d'identification en amont. D'autres systèmes peuvent stocker des références, des hachages, des champs de statut et des métadonnées de politique, mais pas la valeur des informations d'identification elle-même.
Ne stockez pas les secrets en amont à ces endroits
- Lignes du profil du locataire.
- Fichiers de configuration de routage de modèle.
- Journaux d'invites ou étendues de trace.
- Charges utiles des événements Analytics.
- Variables CI destinées aux développeurs.
- Tickets d'assistance, outils de chat ou captures d'écran.
Une conception de coffre-fort utilisable comporte deux plans. Le plan secret stocke les informations d'identification cryptées et contrôle étroitement les opérations de décryptage. Le plan de métadonnées stocke les attributs non secrets utilisés par le routage et la gouvernance. Le routeur ne devrait généralement avoir besoin que d'un identifiant d'identification et d'une récupération secrète de courte durée en mémoire au moment de l'envoi, et non d'un accès large à la base de données à chaque clé de fournisseur.
Protégez le coffre-fort en tant qu'infrastructure à haute valeur : chiffrement d'enveloppe ou KMS géré, identités de service strictes, procédures de bris de vitre, tests de sauvegarde et de restauration, examen des accès et alertes en cas de volume de déchiffrement inhabituel. Un coffre-fort central simplifie la gouvernance, mais il concentre également les risques. C'est le compromis.
Joindre des métadonnées de stratégie à chaque identifiant
Le modèle de métadonnées doit être suffisamment explicite pour que la passerelle puisse décider si un identifiant est éligible avant qu'il ne touche le point de terminaison d'un fournisseur.
Un dossier de certification pratique comprend :
- credential_id : identifiant interne immuable.
- fournisseur : OpenAI, Anthropic, Gemini, Azure OpenAI ou un autre adaptateur.
- provider_account_boundary : organisation, projet, espace de travail, projet cloud, abonnement ou équivalent.
- credential_class : environnement d'exécution, administration, facturation, évaluation ou BYOK.
- environnement : production, préparation, développement, évaluation, bac à sable.
- tenant_binding : identifiant de plate-forme partagée, locataire unique, groupe de locataires ou locataire BYOK du client.
- allowed_model_families : par exemple, génération de texte, intégrations, vision, image, audio ou profils de modèle spécifiques.
- allowed_endpoints : capacités de passerelle normalisées mappées aux points de terminaison du fournisseur.
- data_policy : classe de rétention autorisée, classe de journalisation, exigences de résidence et restrictions de fonctionnalités.
- budget_scope : centre de coûts, client revendeur, service interne ou contrat.
- propriétaire : équipe désignée ou personne responsable.
- created_at, expires_at, rotation_due_at, last_used_at.
- health_status : inconnu, sain, dégradé, non autorisé, quota_exhausted, désactivé.
- emergency_disable : blocage de routage immédiat, indépendant de l'état normal de la stratégie.
Conservez ce modèle neutre à l'égard des fournisseurs, mais n'effacez pas les réalités des fournisseurs. Une clé liée à l'espace de travail Anthropic et une clé Gemini liée à un projet Google Cloud ne sont pas interchangeables simplement parce que les deux peuvent générer du texte. La passerelle a besoin de cette provenance pour les audits, la rétrofacturation et le basculement sécurisé.
Accès séparé à l'exécution, à l'administration et à la facturation
La règle la plus importante est simple : une clé utilisée pour l'inférence d'exécution ne doit pas gérer les organisations fournisseurs, les espaces de travail, les utilisateurs, les projets ou les ressources administratives.
Le trafic d'exécution est élevé et exposé à la plus grande surface opérationnelle. Il passe par les routeurs de requêtes, la logique de nouvelle tentative, les gestionnaires de streaming, les adaptateurs de modèle et les workflows d'incidents. Les informations d’identification d’administrateur sont peu fréquentes et ont un impact élevé. Ils doivent vivre derrière un chemin d'approbation distinct avec des durées de vie courtes, appelées approbation humaine le cas échéant, une journalisation solide et aucune éligibilité au routage d'exécution.
Les informations de facturation méritent également d'être séparées. Une tâche de reporting qui rapproche les factures ne devrait pas être en mesure de générer des complétions, et une clé d'inférence d'exécution ne devrait pas être le seul moyen de récupérer des rapports d'utilisation. Lorsqu'un fournisseur n'offre pas de séparation fine, compensez dans la passerelle : isolez les informations d'identification, limitez l'identité de service interne qui peut les récupérer et enregistrez chaque utilisation.
Recommandation : faites de la classe d'informations d'identification une limite d'autorisation stricte, et non une étiquette. Un répartiteur d'exécution ne devrait pas être en mesure de demander le décryptage d'un identifiant d'administrateur même si une erreur de configuration fait référence à son ID.
Créer un moteur de stratégie de sélection des informations d'identification
La sélection des informations d'identification doit avoir lieu après que la passerelle a authentifié l'appelant en aval et avant toute tentative d'appel auprès du fournisseur. Le moteur de stratégie doit joindre plusieurs entrées :
- ID du locataire et portée de la clé API en aval.
- Profil de modèle demandé ou ID de modèle spécifique au fournisseur.
- Capacité de point de terminaison : chat, intégrations, images, audio, lots, fichiers, outils ou automatisation de l'administration.
- Exigences en matière de conservation et de résidence des données.
- Budget, réservation de crédit et centre de coûts
- État limite de débit et pression sur les quotas.
- Métadonnées des informations d'identification, état de santé, environnement et liaison de locataire.
Le moteur doit renvoyer l'un des trois résultats suivants : autoriser avec un identifiant sélectionné, refuser avec un motif de politique ou exiger une approbation. Les refus doivent être suffisamment précis pour que les équipes opérationnelles puissent résoudre le problème sans révéler d'éléments secrets aux développeurs.
Exemple de décision :
{
"tenant_id": "tenant_42",
"requested_profile": "fast-text-prod",
"endpoint": "chat.completions",
"data_policy": "no_prompt_logging",
"credential_requirements": {
"class": "environnement d'exécution",
"environnement": "production",
"tenant_binding": "tenant_42",
"allowed_model_family": "texte",
"health_status": "en bonne santé"
},
"decision": "autoriser",
"credential_id": "cred_8f2...",
"audit_reason": "Les informations d'identification BYOK du locataire correspondent au profil de texte d'exécution et à la politique de données"
N'implémentez pas de solution de secours telle que « essayez la clé suivante ». La solution de secours doit réexécuter la stratégie. Un identifiant de plateforme partagée peut être valide pour l'accès au fournisseur mais non valide pour un client BYOK uniquement. Un identifiant dans un autre projet peut avoir un quota, mais il peut enfreindre les exigences d'attribution des coûts ou de conservation.
Gérez BYOK comme un accès appartenant au locataire, et non comme une capacité de réserve
BYOK change le modèle de confiance. Le client a fourni les informations d'identification afin que son trafic puisse être facturé, régi par ou isolé au sein de son compte fournisseur. Ces informations d'identification doivent être liées à la provenance du client locataire et du compte fournisseur.
Contrôles BYOK recommandés :
- Un enregistrement de coffre-fort par client, fournisseur, limite de compte et environnement.
- Aucun routage entre locataires via les identifiants BYOK.
- Ne pas utiliser comme capacité de secours partagée, sauf si le client l'accepte explicitement.
- État d'intégrité visible par le client qui ne révèle pas la clé brute.
- Flux de travail de rotation séparé qui permet au client d'ajouter un remplacement avant que l'ancienne clé ne soit désactivée.
- Attribution claire dans les analyses d'utilisation et les factures : locataire de la passerelle, limite du compte du fournisseur, ID d'identifiant, profil de modèle et ID de trace de demande.
Pour les agences, les revendeurs et l'automatisation des API des partenaires, BYOK peut être plus complexe, car un service peut fournir des locataires et des informations d'identification par programmation. La même règle s'applique toujours : l'automatisation peut importer et lier des informations d'identification, mais elle ne doit pas brouiller la propriété des locataires.
Ajouter des vérifications d'état en amont sans fuite d'invites
Un identifiant peut échouer pour de nombreuses raisons : clé révoquée, espace de travail incorrect, accès au modèle manquant, facturation désactivée, épuisement des quotas, restriction du point de terminaison, non-concordance des politiques régionales ou panne du fournisseur. Découvrir cela seulement après l'arrivée d'une demande de production crée des incidents bruyants.
Utilisez des contrôles d'état qui valident les fonctionnalités sans envoyer d'invites au client. Une vérification synthétique peut appeler un point de terminaison minimal, répertorier les modèles autorisés le cas échéant ou envoyer une invite fixe inoffensive si c'est la seule option pratique. Gardez ces contrôles bon marché, à taux limité et étiquetés comme trafic synthétique dans la télémétrie et la facturation.
Les vérifications d'état doivent être exécutées :
- Lors de l'importation des identifiants.
- Avant d'activer un identifiant pour le routage de production.
- Après les modifications des restrictions côté fournisseur.
- Pendant le basculement de la rotation.
- Périodiquement pour les diplômes éligibles à la production.
Compromis : les contrôles automatisés détectent très tôt les clés expirées ou dont la portée est insuffisante, mais des contrôles mal conçus peuvent créer des appels inutiles auprès du fournisseur, des bruits de facturation ou de fausses alarmes en cas de panne du fournisseur. Stockez le résultat d’intégrité avec l’horodatage, la classe d’erreur du fournisseur, le point de terminaison testé et la famille de modèles testée. Ne stockez pas de valeurs secrètes ou d'invites sensibles.
Rotation avec deux emplacements, pas un seul remplacement risqué
La rotation des informations d'identification ne doit pas être une opération de suppression et de prière. Utilisez un modèle de rotation à deux emplacements :
- Importer les informations d'identification de remplacement comme inactives, avec les métadonnées complètes et le propriétaire.
- Exécutez des vérifications d'état synthétiques pour les points de terminaison, les familles de modèles et les limites de compte prévus.
- Activez l'éligibilité fantôme pour une petite partie du trafic synthétique sûr ou à faible risque, le cas échéant.
- Transférer progressivement le trafic de production de l'ancien identifiant au nouveau identifiant.
- Surveillez les erreurs, la latence, les quotas et l'attribution des coûts par ID d'identifiant.
- Geler le retour à l'ancien identifiant une fois que le nouveau identifiant est stable.
- Révoquer l'ancien identifiant auprès du fournisseur et marquer l'enregistrement du coffre-fort comme révoqué.
- Vérifiez qu'aucun décryptage ou appel au fournisseur n'a lieu via l'ancien identifiant après la révocation.
Les délais de rotation doivent être visibles dans les vues des opérations et dans les alertes. La rotation d'urgence nécessite un chemin plus court : désactivez les informations d'identification, bloquez le routage, activez le remplacement approuvé et conservez tous les enregistrements d'audit pour l'examen des incidents.
Restreindre les clés du fournisseur là où le fournisseur les prend en charge
Une politique de passerelle est nécessaire, mais les restrictions du côté du fournisseur réduisent le rayon d'action si une clé est compromise ou utilisée à mauvais escient. Pour Gemini et d'autres clés API de plate-forme cloud, utilisez les restrictions d'API/service et les restrictions d'application appropriées lorsqu'elles sont disponibles. Pour les projets de fournisseur, les espaces de travail et les comptes de service, évitez les privilèges organisationnels étendus lorsqu'une clé d'exécution au niveau du projet suffit.
Recommandation : conservez une liste de contrôle des restrictions côté fournisseur pour chaque classe d'informations d'identification. La liste de contrôle doit faire partie de l'approbation des importations et de la rotation, et non une tâche de sécurité distincte qui peut être ignorée sous la pression.
Compromis : les restrictions côté fournisseur ajoutent des frais opérationnels. Les nouveaux points de terminaison, familles de modèles, régions ou fonctionnalités d'automatisation peuvent nécessiter des modifications de stratégie et de restriction. C'est préférable plutôt que de découvrir après une fuite qu'une seule clé pourrait accéder à chaque charge de travail d'un projet partagé.
Conserver un journal d'audit des informations d'identification avec ajouts uniquement
Une piste d'audit doit indiquer qui a importé un identifiant, ce qu'il était autorisé à faire, quelles décisions de routage l'ont sélectionné, quand il a échoué et quand il a été alterné ou révoqué.
Consignez ces événements :
- Credential created or imported.
- Métadonnées modifiées, y compris les points de terminaison autorisés, la liaison de locataire ou la stratégie de données.
- Bilan de santé exécuté et résultat enregistré.
- Identifiant sélectionné par la stratégie de routage pour une demande.
- Déchiffrement des identifiants demandé par une identité de service interne.
- L'appel du fournisseur a échoué en raison d'une erreur d'authentification, d'autorisation, de quota ou de restriction.
- Rotation démarrée, trafic modifié, anciens identifiants révoqués.
- Emergency disable enabled or cleared.
- Accès aux informations d'identification d'administrateur ou de bris de glace.
Ne mettez pas de valeurs d'identification brutes dans les événements d'audit. Utilisez les identifiants d'identification, les limites des comptes de fournisseur, les identifiants de trace des demandes, les identités des acteurs et les raisons des décisions politiques. Pour le trafic d'exécution à volume élevé, vous pouvez échantillonner la télémétrie de décryptage détaillée, mais la sélection du routage et l'attribution des coûts doivent rester suffisamment complètes pour la facturation et la réponse aux incidents.
Liste de contrôle de mise en œuvre
- Créez une taxonomie des identifiants et rejetez les importations non classifiées.
- Déplacez tous les secrets du fournisseur vers un coffre-fort chiffré dédié.
- Stockez les métadonnées de routage séparément des éléments secrets.
- Séparez les classes d'autorisation d'exécution, d'administration, de facturation, d'évaluation et BYOK.
- Lier les identifiants BYOK à la provenance du compte du locataire et du fournisseur.
- Exiger l'approbation du moteur de stratégie avant de sélectionner un identifiant en amont.
- Effectuez des contrôles d'état rapides et sécurisés avant d'être éligible à la production.
- Utilisez une rotation sur deux emplacements avec un déplacement progressif du trafic et une révocation côté fournisseur.
- Appliquer les restrictions côté fournisseur chaque fois qu'elles sont disponibles.
- Gérez les journaux d'audit avec ajout uniquement pour l'importation, l'utilisation, les échecs, la rotation et la révocation.
- Conservez les informations d'identification de l'administrateur derrière des contrôles inviolables : durée de vie courte, approbation nommée, journalisation sécurisée, aucune utilisation du runtime.
Actionable conclusion
Commencez par inventorier tous les identifiants de fournisseur en amont actuellement utilisés par la passerelle, les scripts, les tâches CI, les harnais d'évaluation et l'automatisation des partenaires. Pour chacun, attribuez une classe, un propriétaire, une limite de compte fournisseur, une liaison de locataire, des points de terminaison autorisés, des familles de modèles autorisées, une date limite de rotation et un statut de désactivation d'urgence. Tout ce que vous ne pouvez pas classifier doit être désactivé ou mis en quarantaine jusqu'à ce qu'il ait un objectif clair.
Ensuite, appliquez une règle architecturale : les développeurs en aval reçoivent des clés au niveau de la passerelle ; la passerelle contrôle seule l’accès du fournisseur en amont. Cette séparation vous permet de préserver le moindre privilège, l'attribution des locataires, l'exactitude de la facturation, le routage des politiques de données et l'automatisation sécurisée, même si les fournisseurs, les projets, les espaces de travail et les clients BYOK se multiplient.