Les clés AWS Bedrock sont désormais protégées par une passerelle LLM interne qui permet à chaque équipe d'une entreprise de fintech d'appeler les modèles, tout en liant chaque requête à un budget de tokens par équipe. Ce changement met fin à la pratique consistant à disperser les identifiants IAM dans les dépôts et les notebooks, une habitude qui menaçait déjà d'épuiser les dépenses en IA de l'entreprise en un seul après-midi.

Pourquoi la distribution de clés AWS devient rapidement problématique

Les groupes non techniques de l'organisation ont demandé un accès direct aux modèles de langage de l'entreprise. Sur le papier, la réponse la plus simple consistait à activer les modèles dans AWS et à accorder une permission IAM à chaque groupe. Dix minutes de travail, quelques modifications de politiques, et le travail était fait — du moins en théorie.

En pratique, la distribution d'identifiants IAM crée trois coûts cachés :

  • Dispersion des identifiants – Les clés finissent dans des fichiers .env, des pipelines CI, des notebooks Jupyter et des scripts ad hoc. Chaque copie devient un point de défaillance lorsqu'une rotation est nécessaire.
  • Visibilité nulle – Une clé partagée unique ne permet pas de savoir quelle équipe ou quel morceau de code génère l'utilisation. Lorsqu'une boucle incontrôlée démarre, l'intégralité du budget peut être consommée avant que quiconque ne s'en aperçoive.
  • Surcharge opérationnelle – Suivre qui possède quelle permission, révoquer les accès et auditer l'utilisation se transforme rapidement en un processus manuel et sujet aux erreurs.

L'équipe fintech a réalisé que cette « solution rapide » allait bientôt devenir un cauchemar en matière de sécurité et de coûts.

Mettre en place une passerelle de type reverse-proxy à la place

La solution a consisté à insérer un léger reverse proxy entre chaque application interne et AWS Bedrock. Le proxy conserve les véritables identifiants AWS dans un emplacement unique sécurisé par un coffre-fort et délivre des tokens à courte durée de vie et lisibles par l'homme (par exemple, lllkey_9f3c) aux appelants.

Points clés de la conception :

  • Aucune clé AWS ne quitte la passerelle – Les développeurs et les services ne voient jamais les véritables clés IAM.
  • Application de politiques par token – Chaque token peut être limité à une famille de modèles spécifique ou à un nombre maximum de tokens.
  • Piste d'audit complète – Chaque requête est journalisée avec un nom.

Comment la passerelle traite une requête

  1. Réception du token – Le client inclut son token llmkey_… dans l'en-tête HTTP.
  2. Validation du token – La passerelle vérifie le statut du token (actif, non expiré) et si la requête respecte le budget alloué.
  3. Liste blanche de modèles – Elle confirme que le modèle demandé est autorisé pour ce token.
  4. Transmission à Bedrock – La requête est envoyée à AWS en utilisant les identifiants IAM stockés.
  5. Journalisation et facturation – L'utilisation des tokens, le nom du modèle et l'estimation du coût sont écrits dans une base de données centrale pour le reporting.

Comme l'entreprise fintech doit conserver toutes les données à l'intérieur de son propre réseau, une offre SaaS tierce n'était pas envisageable.

Ce que l'entreprise a gagné

  • Contrôle des modèles – Les équipes qui n'ont besoin que d'un modèle à bas coût peuvent y être limitées, empêchant l'utilisation accidentelle de variantes plus coûteuses et plus performantes.
  • Protection du budget – Les tokens ont une limite stricte de tokens. Lorsque la limite est atteinte, la passerelle renvoie une erreur au lieu de consommer silencieusement davantage de crédits.
  • Attribution pour la finance – Un tableau de bord basé sur les journaux d'utilisation montre exactement quelle équipe ou quel service a dépensé combien en IA, transformant une feuille de calcul vague en un rapport transparent.

Le flux de travail opérationnel a également changé. Plus de nouvelles politiques IAM, plus de rotation de secrets, et aucun risque de fuite de clés dans le contrôle de version.

Contre-argument : pourquoi ne pas utiliser un service managé

Une objection courante est que la construction d'une passerelle personnalisée ajoute un effort d'ingénierie et de maintenance. Dans le cas de cette fintech, la nécessité de maintenir tout le trafic IA et les données d'utilisation derrière le pare-feu de l'entreprise l'emportait sur la commodité d'une solution tierce. Le proxy interne a nécessité un week-end de développement, mais il a éliminé des mois de nettoyage de clés et de dépassements de budget qui auraient suivi l'approche naïve de distribution de clés.

À retenir

Distribuer des clés AWS Bedrock est un raccourci qui se transforme rapidement en cauchemar de sécurité et de budget. Une modeste passerelle de type reverse-proxy — construite en un week-end — centralise les identifiants, applique des limites par équipe et fournit la piste d'audit nécessaire à la finance. Pour toute organisation souhaitant permettre à plusieurs groupes d'expérimenter avec les LLM sans perdre le contrôle, l'approche par passerelle s'amortit par l'évitement d'incidents et une meilleure visibilité des dépenses.