Habr AI détaille comment un seul port ouvert dans une plateforme LLM mène aux clés et à l'infrastructure

L'histoire d'un audit d'une grande plateforme RAG aboutit à une conclusion déplaisante pour le marché de l'IA : les incidents les plus coûteux commencent souvent non par une attaque « intelligente » contre le modèle, mais par une erreur banale d'infrastructure. L'équipe a passé deux semaines à chercher des vulnérabilités sophistiquées, mais a fini par accéder aux clés et aux services internes en quelques minutes à peine.

Comment l'accès a été trouvé

Les auditeurs ont testé un service comptant des dizaines de milliers d'utilisateurs. Ils ont d'abord suivi la route attendue pour une pile LLM : vérification de SSRF combinée à LangChain, tests d'injections de prompt, analyse du traitement HTTP et recherche de vulnérabilités de désérialisation. La logique se comprend : ce sont les pistes que l'on évoque d'ordinaire quand on parle de sécurité des RAG, des agents et des applications LLM. Mais aucune des longues chaînes n'a donné de résultat exploitable. La trouvaille critique est apparue non dans l'application, mais au niveau d'une infrastructure mal verrouillée.

«

Nous avons fait un seul curl vers un port ouvert et récupéré toutes les clés en 5 minutes. »

Cette phrase résume bien le contraste central du texte. Pendant que l'industrie redoute des attaques exotiques contre l'orchestration des modèles, les environnements de production réels conservent souvent des interfaces ouvertes par lesquelles on peut voir des configurations, des variables d'environnement de service, des URL internes et des jetons d'API externes. Si ces secrets se trouvent à côté des clés de production, la compromission d'un service devient vite celle de toute la plateforme.

Pourquoi cela arrive

Les plateformes LLM fonctionnent rarement comme un serveur unique avec un seul modèle. Il s'agit en général d'un ensemble de microservices : passerelle d'API, orchestrateur de chaînes, base vectorielle, stockage de fichiers, files d'attente, interfaces d'administration internes, fournisseurs d'embeddings, journalisation, supervision et facturation. Chaque nouveau composant ajoute du réseau, des secrets, des rôles et des points d'intégration. Résultat : une équipe peut avoir bien configuré l'interface utilisateur et l'autorisation de base, tout en isolant mal les ports internes, les panneaux de débogage ou les conteneurs à accès privilégié.

Le problème s'aggrave parce que les startups d'IA pensent souvent les menaces au niveau du modèle. Elles discutent beaucoup de jailbreak, de fuite du prompt système, d'hallucinations et de protection du contexte RAG, mais repoussent l'hygiène DevSecOps classique. Or c'est elle qui détermine si un attaquant pourra atteindre les secrets, l'infrastructure cloud ou des clés payantes valant des centaines de milliers de dollars. Si un service interne écoute le réseau sans nécessité et que les secrets sont accessibles à un processus « au cas où », le LLM n'est plus le problème principal : il ne fait qu'augmenter le coût des conséquences.

Où l'on se trompe le plus souvent

Ce retour d'expérience est utile parce qu'il ramène le débat sur la sécurité des services d'IA aux fondamentaux de la discipline d'ingénierie. Même si l'application est bâtie autour d'une chaîne de retrieval complexe, d'agents et de plusieurs modèles, l'attaquant cherche presque toujours le chemin le moins coûteux. Et ce chemin passe souvent par de vieilles erreurs bien connues de toute équipe ayant travaillé avec une infrastructure cloud et des conteneurs.

• Ports et services internes ouverts sans ACL strictes
• Secrets dans les variables d'environnement, les logs ou une configuration accessible aux services voisins
• Droits excessifs pour les conteneurs, les runners et les comptes de service
• Absence de segmentation entre la couche RAG, l'interface d'administration et l'infrastructure cloud
• Focalisation sur la prompt injection au détriment de l'hygiène réseau

Pour le produit, cela signifie qu'un audit de sécurité ne peut pas se réduire au red teaming des prompts. Il faut un inventaire de tous les composants autour du modèle : quels services sont exposés vers l'extérieur, quelles clés sont accessibles à chaque conteneur, où des interfaces de débogage sont activées, comment le trafic sortant et entrant est limité, et qui a accès aux logs et aux snapshots de l'environnement. Sans cela, même une bonne protection de la couche applicative laisse l'infrastructure vulnérable, et toute compromission passe d'un bug local à un incident de grande ampleur, avec fuite de données, de budget et d'accès aux fournisseurs.

Ce que cela signifie

La conclusion principale est simple : un produit d'IA doit être protégé non comme une « magie particulière autour d'un LLM », mais comme une plateforme critique ordinaire, avec des secrets coûteux et un grand rayon d'impact. Si l'infrastructure de base n'est pas verrouillée, aucun discours sur les attaques sophistiquées contre le modèle ne sauvera la situation : une porte ouverte pèse plus lourd que toute votre architecture d'IA.