Habr AI révèle comment un port ouvert dans une plateforme LLM a exposé les clés d'API et l'infrastructure

Une histoire tirée d'un audit d'une grande plateforme RAG démontre une conclusion inconfortable pour le marché de l'IA : les incidents les plus coûteux commencent souvent non par une attaque « intelligente » sur le modèle, mais par une simple erreur d'infrastructure. L'équipe a passé deux semaines à chercher des vulnérabilités complexes, mais a finalement obtenu accès aux clés et aux services internes en seulement quelques minutes.

Comment Ils Ont Trouvé l'Accès

Les auditeurs ont testé un service avec des dizaines de milliers d'utilisateurs et ont initialement suivi le chemin attendu pour une pile LLM : ils ont vérifié les SSRF en combinaison avec LangChain, tenté les injections de prompts, analysé le traitement HTTP et recherché les vulnérabilités de désérialisation. La logique est compréhensible : ce sont exactement les domaines généralement discutés lorsqu'on parle de sécurité de RAG, d'agents et d'applications LLM. Mais aucune des longues chaînes d'attaques n'a produit de résultats.

La découverte critique est apparue non pas dans l'application, mais au niveau de l'infrastructure mal sécurisée.

«

Nous avons fait un curl sur un port ouvert — et nous avons obtenu toutes les clés en 5 minutes. »

Cette phrase capture bien le contraste principal. Alors que l'industrie craint les attaques exotiques sur l'orchestration des modèles, les systèmes de production réels ont souvent des interfaces ouvertes où vous pouvez voir les configs, les variables d'environnement, les URLs internes et les tokens pour les APIs externes. Si de tels secrets se trouvent à côté de clés actives, compromettre un service se transforme rapidement en compromettre toute la plateforme.

Pourquoi Cela Se Produit

Les plateformes LLM existent rarement en tant que serveur unique avec un modèle. Généralement, elles consistent en microservices : passerelle API, orchestrateur de chaînes, base de données vectorielle, stockage de fichiers, files d'attente, panneaux d'administration internes, fournisseurs d'embeddings, logging, monitoring et facturation. Chaque nouveau composant ajoute des réseaux, des secrets, des rôles et des points d'intégration. Par conséquent, une équipe peut avoir une interface utilisateur bien configurée et une autorisation de base, mais des ports internes mal isolés, des panneaux de débogage ou des conteneurs avec accès privilégié.

Le problème est aggravé par le fait que les startups d'IA pensent souvent aux menaces au niveau du modèle. Elles discutent longuement des jailbreaks, des fuites de prompts système, des hallucinations et de la protection du contexte RAG, mais reportent l'hygiène classique de DevSecOps. Or, c'est précisément cette hygiène qui détermine si un attaquant peut atteindre les secrets, l'infrastructure cloud ou les clés API valant des centaines de milliers de dollars. Si un service interne écoute le réseau inutilement et que les secrets sont disponibles pour un processus « au cas où », le LLM n'est plus le problème principal — il augmente simplement le coût des conséquences.

Où les Erreurs Surviennent le Plus Souvent

Le matériel est utile car il ramène la conversation sur la sécurité des services d'IA à des questions fondamentales de discipline d'ingénierie. Même si l'application est construite autour d'une chaîne complexe de récupération, d'agents et de plusieurs modèles, un attaquant cherchera presque toujours le chemin le moins coûteux. Et ce chemin passe souvent par les anciennes erreurs familières que toute équipe ayant travaillé avec l'infrastructure cloud et les conteneurs connaît.

• Ports internes ouverts et services sans ACL strict
• Secrets dans les variables d'environnement, les logs ou les configurations accessibles aux services voisins
• Permissions excessives pour les conteneurs, runners et comptes de service
• Absence de segmentation entre la couche RAG, le panneau d'administration et l'infrastructure cloud
• Accent mis sur l'injection de prompts tout en ignorant l'hygiène réseau

Pour un produit, cela signifie que les audits de sécurité ne peuvent pas être réduits à du red teaming de prompts. Vous avez besoin d'un inventaire de tous les composants autour du modèle : quels services sont exposés en externe, quelles clés sont disponibles pour chaque conteneur, où les interfaces de débogage sont activées, comment le trafic entrant et sortant est restreint, qui a accès aux logs et aux snapshots d'environnement. Sans cela, même une protection de qualité de la couche application laisse l'infrastructure vulnérable, et tout compromis se transforme d'un bug local en un incident à grande échelle avec fuites de données, perte de budget et accès compromis aux fournisseurs.

Ce Que Cela Signifie

La conclusion principale est simple : un produit d'IA doit être protégé non comme de la « magie LLM spéciale », mais comme une plate-forme critique ordinaire avec des secrets coûteux et un large rayon d'impact. Si l'infrastructure de base n'est pas sécurisée, aucune discussion sur les attaques complexes contre le modèle n'aidera — une seule porte ouverte s'avérera plus importante que toute votre architecture d'IA.