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

API clés en aval et identifiants 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. D'autres comptes apparaissent ensuite : un projet fournisseur pour la production, un autre pour l'évaluation, un Anthropic espace de travail pour une unité commerciale, un Google projet 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 de fournisseurs exposent différentes limites de compte et types d'identifiants. OpenAI documente les projets et les comptes de service, et les autorisations clés du compte de service API sont par défaut un accès en lecture et en écriture pour les API ressources du projet. OpenAI expose également les objets clés de l'administrateur API séparément de l'utilisation ordinaire du projet/exécution API. Anthropic documente les espaces de travail en tant que limite organisationnelle et indique que les points de terminaison Admin API nécessitent des clés Admin API distinctes des clés 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 des clés Gemini API de Google indique que chaque clé Gemini API est associée à un projet Google Cloud et recommande API restrictions 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 d'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, selon 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 l'utilisation, les factures, les coûts ou les rapports 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 reporting ne puissent pas générer l'utilisation du modèle.
• Identifiants d'évaluation uniquement : utilisés par les workflows de référence, d'assurance qualité, de migration ou de préparation. Ils doivent avoir des quotas faibles, des étiquettes d'environnement claires et aucune éligibilité à un repli de production.
• 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 stratégie, 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 étendu à 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 un point de terminaison du fournisseur.

Un dossier de certification pratique comprend :

• credential_id : identifiant immuable interne.
• 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, staging, développement, évaluation, sandbox.
• 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 : classes de rétention, classes de journalisation, exigences de résidence et restrictions de fonctionnalités autorisées.
• budget_scope : centre de coûts, client revendeur, service interne ou contrat.
• propriétaire : équipe nommé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 : bloc 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é Anthropic liée à l'espace de travail 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 politique de sélection d'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 au 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 des données et de résidence.
• 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": "runtime",
    "environment": "production",
    "tenant_binding": "tenant_42",
    "allowed_model_family": "text",
    "health_status": "healthy"
  },
  "decision": "allow",
  "credential_id": "cred_8f2...",
  "audit_reason": "tenant BYOK credential matches runtime text profile and data policy"
}

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 invalide 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.
• Pas de routage entre locataires via les informations d'identification 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'identification, profil de modèle et ID de trace de demande.

Pour l'automatisation des agences, des revendeurs et des partenaires API, 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 contrôles de santé 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 du quota, 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 vérifications d'état qui valident la fonctionnalité 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 de l'état devraient s'exécuter :

• Lors de l'importation des informations d'identification.
• 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 informations d'identification éligibles à la production.

Compromis : les contrôles automatisés détectent très tôt les clés expirées ou sous-portées, mais des contrôles mal conçus peuvent créer des appels inutiles au fournisseur, du bruit de facturation ou de fausses alarmes lors de pannes de 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 identifiants ne doit pas être une opération de suppression et de prière. Utilisez un modèle de rotation à deux emplacements :

1. Importer les informations d'identification de remplacement comme inactives, avec les métadonnées complètes et le propriétaire.
2. 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.
3. Activez l'éligibilité du shadow pour une petite tranche de trafic synthétique sûr ou à faible risque, le cas échéant.
4. Transférer progressivement le trafic de production de l'ancien identifiant au nouveau identifiant.
5. Surveillez les erreurs, la latence, les quotas et l'attribution des coûts par ID d'identifiant.
6. Geler le retour à l'ancien identifiant une fois que le nouveau identifiant est stable.
7. Révoquer l'ancien identifiant auprès du fournisseur et marquer l'enregistrement du coffre-fort comme révoqué.
8. Vérifiez qu'aucun décryptage ou appel au fournisseur ne se produit 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 côté fournisseur réduisent le rayon d'explosion si une clé est compromise ou utilisée à mauvais escient. Pour Gemini et les autres clés de plateforme cloud API, utilisez les restrictions API/service et les restrictions d'application appropriées, le cas échéant. 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 : maintenez 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 de l'importation 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 une surcharge opérationnelle. 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 clé pourrait accéder à chaque charge de travail d'un projet partagé.

Conserver un journal d'audit des informations d'identification en annexe 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 :

• Identifiant créé ou importé.
• 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 requête.
• Déchiffrement des informations d'identification 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 déplacé, ancien identifiant révoqué.
• Désactivation d'urgence activée ou désactivée.
• Accès aux identifiants 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 informations d'identification 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.
• Exécutez des vérifications d'état rapides et sécurisées avant l'éligibilité à 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 partout où elles sont disponibles.
• Maintenir les journaux d'audit en 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 en cas de bris de vitre : durée de vie courte, approbation nommée, journalisation renforcée, aucune utilisation du runtime.

Conclusion exploitable

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 lorsque les fournisseurs, les projets, les espaces de travail et les clients BYOK se multiplient.

Lecture connexe

• face à l'équipe API gestion des clés et réponse aux fuites
• routage tenant compte de la rétention des données politiques
• grand livre de facturation et contrôles d'attribution des coûts