API gateway, authentification et isolation

Introduction

Un serveur Ollama fraîchement installé écoute par défaut sur 11434, sans authentification, sans chiffrementchiffrementCybersécuritéTransformation d'une donnée lisible en une forme inintelligible à l'aide d'une clé. Le destinataire disposant de la clé peut retrouver le message original. C'est le socle de la confidentialité sur Internet.Voir dans le glossaire, sans limite de débit. Un serveur vLLM lancé avec sa commande la plus simple expose une API compatible OpenAI sur un portportRéseauxNuméro sur 16 bits qui désigne l'application destinataire sur une machine. Les ports 0 à 1023 sont réservés aux services système, comme 443 pour HTTPS.Voir dans le glossaire HTTP nu. Ces choix par défaut sont parfaitement adaptés à un poste de développement isolé. Ils sont incompatibles avec un déploiement en entreprise, où le même moteur va servir plusieurs équipes, transporter des donnéesdonnéesIAEnsemble d'informations structurées ou non utilisées pour entraîner, évaluer ou alimenter un modèle. La qualité, la quantité et la représentativité des données sont les facteurs décisifs pour les performances en apprentissage automatique.Voir dans le glossaire sensibles dans les prompts, et devoir rendre des comptes en cas d'audit.

Ce chapitre traite la question qui vient juste après « comment faire tourner un modèle » : comment le mettre à disposition de manière sûre. Nous verrons pourquoi le moteur d'inférenceinférenceIAUtilisation d'un modèle déjà entraîné sur une donnée nouvelle. Peu coûteuse à l'unité mais répétée à chaque requête, elle constitue le coût récurrent d'exploitation.Voir dans le glossaire ne doit jamais parler directement au réseau, comment construire une façade avec un reverse proxy, quelles options d'authentification retenir selon la taille de l'organisation, comment répartir la charge entre équipes sans qu'une seule ne monopolise le GPUGPUIAProcesseur graphique parallélisant massivement les calculs matriciels ; indispensable à l'entraînement et à l'inférence des modèles de deep learning.Voir dans le glossaire, et comment isoler le tout sur le plan réseau. Nous terminerons par la question sensible de la journalisation des échanges, qui contiennent souvent des informations personnelles.

Le moteur d'inférence (Ollama, vLLM, TGI) est un composant interne. Il ne doit jamais recevoir de trafic directement depuis un poste utilisateur ou une application tierce. Tout accès passe par une couche intermédiaire qui authentifie, limite et journalise.

Pourquoi ne jamais exposer le moteur brut

Trois raisons concrètes justifient cette règle, indépendamment de la taille de l'infrastructure.

La première est l'absence de contrôle d'accès natif. Ollama et vLLM sont conçus pour maximiser la performance d'inférence, pas pour gérer des identités. Aucun des deux ne propose nativement de gestion d'utilisateurs, de rôles ou de journalisation d'accès digne de ce nom. Ajouter cette logique dans le moteur lui-même reviendrait à réinventer un pare-feupare-feuRéseauxÉquipement ou logiciel qui filtre le trafic selon des règles (ports, adresses, états) pour réduire la surface d'attaque.Voir dans le glossaire applicatif à l'intérieur d'un runtime GPU.

La deuxième raison est la stabilité du service. Un moteur d'inférence a une capacité de traitement finie, dictée par la VRAM disponible et le nombre de requêtes concurrentes que le batching peut absorber. Sans limite de débit en amont, une équipe qui lance un script en boucle peut saturer le GPU et dégrader le service pour tout le monde, voire provoquer des out-of-memory qui font planter le processus.

La troisième est la surface d'attaque. Une API OpenAI-compatible exposée sans authentification permet à quiconque atteint le port réseau de consommer de la capacité de calcul, d'extraire des informations sur les modèles chargés, et potentiellement d'exploiter des vulnérabilités du serveur d'inférence lui-même. Les CVE touchant des serveurs d'inférence ne sont pas rares ; une façade limite l'exposition de ces failles.

Publier un port Ollama ou vLLM directement sur une interface réseau accessible (0.0.0.0 sans pare-feu, ou pire, exposé sur Internet via un tunnel rapide type ngrok pour « tester vite ») est une pratique observée en environnement de preuve de concept qui finit parfois oubliée en production. Vérifiez systématiquement les règles de pare-feu après chaque déploiement.

Architecture de référence avec reverse proxy

Le schéma le plus robuste place un reverse proxy — Nginx est le choix le plus répandu, mais Traefik ou Envoy conviennent tout autant — entre les clients et le moteur d'inférence. Ce proxy assure quatre fonctions : terminaison TLSTLSRéseauxProtocole cryptographique assurant confidentialité et intégrité des communications applicatives (notamment HTTPS).Voir dans le glossaire, authentification, limitation de débit, et routage vers le bon backend.

Dans une configuration Nginx typique, le bloc location qui protège une route vers vLLM ressemble à ceci, avant même d'ajouter l'authentification applicative :

location /v1/chat/completions {
    limit_req zone=llm_zone burst=5 nodelay;
    proxy_pass http://vllm_backend;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_read_timeout 300s;
}

Le proxy_read_timeout mérite une attentionattentionIAMécanisme par lequel un modèle pondère l'importance de chaque token du contexte lorsqu'il en traite un autre, quelle que soit la distance qui les sépare.Voir dans le glossaire particulière : la génération de texte peut prendre plusieurs dizaines de secondes sur un modèle volumineux, et le délai par défaut de nombreux proxys (souvent 60 secondes) coupe la connexion en plein streaming si on ne l'augmente pas.

Authentification : clés API ou OIDC

Le choix du mécanisme d'authentification dépend directement de la taille de l'organisation et de l'existant en matière d'identité.

Pour une équipe restreinte ou un premier déploiement, des clés API statiques suffisent. Chaque équipe ou application reçoit une clé unique, stockée côté serveur dans une table (ou un fichier de configuration chiffré), vérifiée par le proxy via un module comme njs pour Nginx ou directement par un service d'authentification léger placé en amont. C'est simple, rapide à mettre en place, mais cela pose un problème de rotation : révoquer une clé compromise exige de la retirer manuellement, et il n'y a pas de granularité fine sur les droits sans développement supplémentaire.

Pour une organisation qui dispose déjà d'un fournisseur d'identité (Azure AD / Entra ID, Okta, Keycloak), OIDC (OpenID Connect) est la voie la plus pérenne. Le reverse proxy délègue la vérification du jeton à un composant comme oauth2-proxy, qui s'intercale avant Nginx :

auth_request /oauth2/auth;
error_page 401 = /oauth2/sign_in;

L'avantage majeur est que l'accès au LLMLLMIAGrand modèle de langage (Large Language Model) entraîné sur d'énormes corpus pour prédire et générer du texte.Voir dans le glossaire interne suit le cycle de vie des comptes existants : un utilisateur désactivé dans l'annuaire perd immédiatement l'accès, sans action manuelle côté plateforme LLMgrand modèle de langageIAModèle entraîné à prédire le token suivant d'une séquence de texte. Toutes ses capacités apparentes — résumer, traduire, coder — découlent de cette unique tâche.Voir dans le glossaire. Les groupes de l'annuaire peuvent aussi être mappés à des rôles applicatifs (accès à tel modèle, quota plus élevé, etc.).

Démarrez avec des clés API si votre déploiement sert quelques équipes techniques qui savent gérer un secret. Migrez vers OIDC dès que le nombre d'utilisateurs dépasse la trentaine ou que des équipes non techniques accèdent au service via une interface web — la friction de gestion des clés devient alors supérieure au coût d'intégration OIDC.

Rate limiting et quotas par équipe

L'authentification répond à la question « qui es-tu ? ». Le rate limiting répond à « combien peux-tu consommer ? ». Les deux sont indissociables dans un contextefenêtre de contexteIAQuantité de texte qu'un modèle peut prendre en compte simultanément : question, documents fournis et historique. Au-delà, les éléments les plus anciens sortent du champ.Voir dans le glossaire multi-équipes : sans quota, la première équipe à lancer un traitement par lots peut saturer le GPU pendant que les autres attendent.

Nginx propose nativement limit_req_zone pour limiter le nombre de requêtes par seconde et par clé d'identification (adresse IPadresse IPRéseauxIdentifiant numérique attribué à une machine sur un réseau, qui permet de l'atteindre depuis n'importe où. Elle tient sur 32 bits en IPv4 et sur 128 bits en IPv6.Voir dans le glossaire, ou mieux, identifiant extrait du jeton d'authentification) :

limit_req_zone $http_x_api_key zone=llm_zone:10m rate=2r/s;

Cela protège contre les pics abusifs, mais reste insuffisant pour des quotas métier — par exemple « l'équipe marketing a droit à 50 000 tokenstokenIAFragment de texte manipulé par un modèle de langage, généralement plus court qu'un mot — trois à quatre caractères en français. La tarification et la limite de contexte se comptent en tokens.Voir dans le glossaire générés par jour ». Ce niveau de granularité demande généralement une couche applicative dédiée, un petit service qui s'intercale entre le proxy et le moteur, tient un compteur (Redis convient bien pour sa rapidité) par équipe et par fenêtre temporelle, et retourne un code 429 Too Many Requests une fois le quota atteint.

Une organisation de taille moyenne applique souvent trois strates cumulées : une limite de débit instantanée (au niveau du proxy, pour éviter les rafales), un quota journalier en nombre de requêtes par équipe (pour répartir équitablement une capacité GPU limitée), et un quota mensuel en tokens consommés par centre de coût (pour le suivi budgétaire et la refacturation interne).

Cette approche a un effet secondaire utile : elle rend visible la consommation réelle de chaque équipe, ce qui facilite les arbitrages sur le dimensionnement matériel futur — faut-il ajouter un GPU, ou l'usage actuel tient-il dans la capacité existante avec une meilleure répartition ?

Isolation réseau : VLAN et mTLS

L'authentification applicative ne dispense pas d'une isolation réseau. Le principe de défense en profondeur veut qu'un attaquant ayant contourné le proxy (ou un service compromis sur le même réseau) ne puisse pas atteindre directement le moteur d'inférence.

En pratique, cela se traduit par un VLANVLANRéseauxRéseau local virtuel qui segmente logiquement un LAN Ethernet sans exiger un câblage physique séparé.Voir dans le glossaire dédié pour les hôtes d'inférence, séparé du réseau bureautique et du réseau des applications métier. Seul le reverse proxy dispose d'une interface routée vers ce VLAN ; les règles de pare-feu n'autorisent que le trafic provenant de son adresse, sur le port du moteur, rien d'autre. Un serveur Ollama ou vLLM compromis via une autre voie ne peut donc pas servir de rebond vers le reste du système d'information, et inversement, une machine compromise ailleurs sur le réseau ne peut pas atteindre le GPU directement.

Quand plusieurs services internes communiquent entre eux (le proxy, un service de quotas, le moteur d'inférence, éventuellement un service de journalisation), le mTLS (TLS mutuel) renforce cette isolation au niveau applicatif : chaque service présente un certificat client, et chaque destinataire vérifie ce certificat avant d'accepter la connexion. Cela empêche qu'un service non autorisé, même s'il atteint le bon port réseau, puisse dialoguer avec le moteur sans détenir le certificat attendu.

Le mTLS complet entre tous les composants a un coût opérationnel réel : gestion du cycle de vie des certificats, rotation, dépannage plus complexe. Pour une infrastructure interne de taille modeste, isoler correctement le VLAN et restreindre les règles de pare-feu au strict nécessaire couvre déjà l'essentiel du risque. Réservez le mTLS complet aux environnements soumis à des exigences de conformité formelles (secteur bancaire, santé, marchés publics sensibles).

Journalisation des prompts et gestion des données personnelles

La journalisation est une nécessité opérationnelle : sans elle, impossible de diagnostiquer un incident, de facturer un usage, ou de répondre à un audit. Mais les prompts envoyés à un LLM interne contiennent fréquemment des données personnelles — noms, adresses e-mail, extraits de contrats, parfois des données de santé si le cas d'usage touche les ressources humaines.

Trois pratiques limitent le risque :

1. Séparer les journaux techniques des journaux de contenu. Les journaux d'accès (qui, quand, quel endpoint, quel code de réponse) peuvent être conservés longtemps sans problème particulier. Les journaux de contenu (le texte du promptpromptIAConsigne ou contexte fourni à un modèle de langage pour orienter sa réponse. La qualité du prompt conditionne souvent la qualité du résultat.Voir dans le glossaire et de la réponse) doivent avoir une politique de rétention beaucoup plus courte et un accès restreint.
2. Appliquer un masquage automatique des PII avant stockage, via une passe de détection (expressions régulières pour les formats structurés comme les e-mails et numéros de téléphone, complétée par un modèle de reconnaissance d'entités nommées pour les noms propres) exécutée dans le pipeline de journalisation, avant écriture sur disque.
3. Documenter la finalité et la durée de conservation dans un registre de traitement, conformément aux obligations RGPDRGPDConformitéRèglement européen sur la protection des données personnelles. Il s'applique dès qu'un système d'IA traite de telles données, et se cumule avec l'AI Act.Voir dans le glossaire si l'organisation opère en Europe — un LLM interne qui traite des données de collaborateurs ou de clients est un traitement de données personnelles au même titre qu'une base de données classique.

La journalisation intégrale des prompts, y compris ceux contenant des informations personnelles, sans base légale ni information des utilisateurs, expose l'organisation aux mêmes obligations RGPD que n'importe quel traitement de données personnelles. Impliquez le délégué à la protection des données avant la mise en production, pas après.

Patterns multi-tenant soft

Quand plusieurs équipes partagent la même infrastructure d'inférence, deux stratégies s'opposent. Le multi-tenant dur déploie une instance de moteur dédiée par équipe, sur des ressources GPU cloisonnées — coûteux mais offrant une isolation maximale. Le multi-tenant soft, plus fréquent en pratique pour des raisons de coût, mutualise le moteur et distingue les tenants au niveau applicatif.

Le pattern le plus courant consiste à faire porter l'identité du tenant par un en-tête HTTP (X-Tenant-ID), injecté par le reverse proxy après authentification — jamais fourni tel quel par le client, pour éviter qu'un utilisateur usurpe l'identité d'une autre équipe. Ce tenant sert ensuite de clé pour : sélectionner le quota applicable, choisir le modèle autorisé si toutes les équipes n'ont pas accès aux mêmes modèles, et étiqueter les journaux pour la facturation interne.

Cette approche a des limites qu'il faut connaître avant de la choisir. La mémoire du GPU est partagée : un pic de charge d'un tenant peut dégrader la latence des autres, même avec des quotas en place, si le batching du moteur mélange les requêtes de plusieurs tenants dans un même lot. vLLM gère cela relativement bien grâce à son ordonnancement continu (continuous batching), mais la garantie n'est jamais absolue. Pour des tenants aux exigences de performance strictes, ou pour des raisons contractuelles (un client externe, par exemple), le passage à une isolation plus stricte — instance dédiée ou au minimum GPU dédié — reste recommandé.

Checklist de mise en production

Avant d'ouvrir l'accès à une plateforme LLM interne au-delà d'un cercle restreint de testeurs, il est utile de vérifier point par point :

• Le moteur d'inférence n'écoute que sur une interface réseau interne, jamais sur une interface publique.
• Le reverse proxy termine le TLS avec un certificat valide, pas un certificat auto-signé oublié depuis les tests.
• Chaque requête est authentifiée, sans route de contournement laissée ouverte pour le debug.
• Des limites de débit sont actives à la fois au niveau réseau (proxy) et au niveau métier (quotas par équipe).
• Le VLAN d'inférence est isolé, avec des règles de pare-feu explicites plutôt qu'une politique par défaut permissive.
• Les journaux de contenu sont séparés des journaux techniques, avec une rétention et un masquage PII définis.
• Le registre de traitement des données personnelles a été mis à jour si des prompts contiennent des données personnelles.
• Un test de charge a validé le comportement du système sous plusieurs tenants simultanés, pas seulement en usage isolé.

Conclusion

Sécuriser un déploiement LLM local n'est pas fondamentalement différent de sécuriser n'importe quel service interne exposant une API sensible : on ne fait jamais confiance au réseau, on authentifie systématiquement, on limite la consommation, et on journalise avec discernement. La spécificité du LLM tient surtout à la nature du contenu échangé — des prompts en langage naturel qui peuvent contenir des données personnelles ou confidentielles sans structure évidente à filtrer — et à la rareté de la ressource protégée, le GPU, qui rend les quotas aussi importants que l'authentification elle-même. Le chapitre suivant s'appuie sur cette base pour aborder le monitoring et l'observabilité de la plateforme en production.