Votre IA tourne sur votre serveur. À quoi se connecte-t-elle ?

Vous avez déplacé votre système d’IA sur votre propre serveur Linux. Le modèle tourne sur votre carte graphique, les documents sont stockés dans une base de données que vous contrôlez et l’accès au système est protégé par une authentification.

Une question simple se pose alors : à quels services externes ce système s’est-il connecté hier ?

La réponse n’est pas toujours disponible.

Un système d’IA peut comprendre un serveur de modèles, une interface de chat, un composant de traitement des documents, une plateforme d’automatisation et des outils qui font appel à des services externes. Chaque composant possède ses propres paramètres et peut établir des connexions réseau.

Exécuter le modèle chez vous permet de savoir où ses traitements ont lieu. Pour comprendre où les données peuvent aller, il faut aussi connaître l’activité du reste du système.

Que se passe-t-il avant que les données arrivent au modèle ?

Prenons l’exemple d’un assistant d’analyse de documents qui repose sur un modèle de langage local. Un utilisateur importe un fichier PDF et demande un résumé.

Selon les paramètres, le système peut envoyer des pages numérisées à un service externe de reconnaissance de texte, utiliser un service cloud pour créer des représentations numériques du contenu — Embeddings — ou transmettre une requête à un moteur de recherche. Le modèle peut malgré tout produire la réponse finale sur votre serveur.

C’est un exemple d’architecture possible pour ce type de système. La conséquence est simple : avant même que le document arrive au modèle local, d’autres composants peuvent le traiter ou en transmettre des informations à d’autres services.

Ces possibilités sont parfois détaillées dans la documentation des outils. La documentation d’Ollama précise par exemple que, lorsque le modèle s’exécute localement, Ollama ne voit ni vos requêtes ni vos données. Le logiciel propose aussi des modèles dans le cloud et une recherche sur le Web. Ses paramètres permettent de désactiver les fonctionnalités cloud.

De même, la documentation de n8n décrit une collecte de données d’utilisation et de fonctionnement, activée par défaut même sur une installation auto-hébergée, et explique comment la désactiver. L’envoi de données d’utilisation, le traitement dans le cloud et l’appel à un service externe dans un processus d’automatisation sont des usages différents. Chacun doit être examiné séparément.

Il est utile de savoir lesquelles de ces options sont actives chez vous et si elles correspondent à l’usage que vous aviez prévu pour le système.

Les connexions sortantes doivent elles aussi être sous votre contrôle

Le trafic sortant, ou Egress, est le trafic qui part du serveur, ou d’un service qui s’y exécute, vers une autre destination.

La politique d’accès entrant détermine qui peut se connecter à votre service. En parallèle, il faut décider à quels services externes celui-ci peut se connecter. Même un système dont l’accès est restreint peut établir des connexions sortantes si les paramètres réseau le permettent.

Avec les agents d’IA, cette question prend une dimension supplémentaire. Un agent capable de lire des fichiers, d’accéder à des adresses réseau ou d’exécuter des commandes peut agir sur des systèmes et des données au-delà de la conversation elle-même. L’étendue des dommages qu’une action erronée peut provoquer dépend notamment de ses permissions et des destinations auxquelles il peut accéder.

Les recommandations de l’OWASP sur les permissions et les capacités excessives des agents d’IA expliquent comment l’octroi de capacités inutiles à la tâche peut accroître le risque.

Les restrictions réseau peuvent réduire ce champ d’action. Elles doivent s’accompagner d’un contrôle des permissions dans l’application, de permissions limitées pour les clés d’accès et d’une approbation des actions sensibles. C’est d’autant plus important qu’un service externe autorisé peut lui aussi servir à transmettre des données sensibles.

Le volume total de trafic du serveur ne dit pas tout

Supposons qu’en une heure, votre serveur se soit connecté à un service de stockage, à un dépôt de modèles à télécharger et à une adresse HTTPS que vous ne connaissez pas.

Le volume total de trafic ne vous indique pas quel composant a établi chaque connexion. Pouvoir rattacher une connexion à un service précis permet de mieux cibler la vérification : une sauvegarde planifiée qui accède à un service de stockage est une chose ; un assistant d’analyse de documents qui contacte cette même destination pour la première fois appelle une autre explication.

Une vérification utile doit répondre à quatre questions :

• Quel service a établi la connexion ? Il faut identifier le processus ou le conteneur concerné.
• À quoi s’est-il connecté ? Quelle est l’adresse de destination, et que sait-on de son rôle sur la base d’éléments fiables ?
• Quelle quantité de données a été envoyée ? Il faut distinguer les données envoyées de celles qui ont été reçues.
• Quand la destination a-t-elle été observée pour la première fois ? Était-ce à la suite d’une mise à jour, d’un changement de paramètres ou d’une tâche planifiée ?

Le sens du trafic est particulièrement important lorsqu’on examine son volume. Le téléchargement d’un modèle volumineux fait surtout entrer des données sur le serveur. L’envoi d’une sauvegarde fait surtout sortir des données. Les deux opérations peuvent générer beaucoup de trafic, mais elles n’ont pas la même signification.

Même un transfert de faible volume peut justifier une vérification. Une clé API ou un court document confidentiel n’occupe pas des gigaoctets.

Comment interpréter les résultats ?

Le nom d’un fournisseur connu peut aider à comprendre une connexion, mais les infrastructures partagées servent de nombreux clients. Une adresse IP seule ne révèle pas toujours à quel compte, à quelle ressource ou à quel destinataire précis les données ont été envoyées.

Une connexion récurrente n’est pas non plus nécessairement une connexion que vous avez autorisée. Un composant dont la configuration ne correspond pas à vos intentions peut fonctionner pendant toute la période de suivi et sembler faire partie de l’activité habituelle.

Les données réseau ont aussi leurs limites. Une adresse de destination, une heure de connexion et un nombre d’octets envoyés ne révèlent pas le contenu d’une requête chiffrée. Pour déterminer si des données sensibles ont été exposées, il peut être nécessaire d’examiner aussi les journaux de l’application, ses paramètres ou d’autres sources d’information.

Il faut également comprendre ce que le suivi a pu observer. Si la surveillance n’a pas fonctionné pendant une partie de la période, les observations correspondantes manquent. Lorsque le suivi repose sur un échantillonnage, des connexions brèves peuvent passer inaperçues. Les conclusions tirées du rapport doivent tenir compte de sa couverture.

Vérifier, comprendre, puis modifier

Vous pouvez commencer par un seul service qui traite des données sensibles. Définissez les services externes auxquels il est censé se connecter, puis examinez son activité sur une période couvrant le fonctionnement courant, les tâches planifiées et la maintenance.

Examinez les destinations pour lesquelles vous n’avez pas d’explication claire. Si une connexion indésirable provient d’une option dont vous n’avez pas besoin, commencez par vérifier les paramètres de cette option. Si une restriction réseau est nécessaire, appliquez-la précisément au service et à la destination concernés, vérifiez son effet et assurez-vous de pouvoir l’annuler facilement.

Il est utile de refaire cette vérification après l’ajout d’outils ou la modification de connexions à des services externes. Les besoins réseau du système peuvent changer même si le modèle local reste exactement le même.

Comment nuDefend vous aide-t-il ?

nuDefend permet d’effectuer cette vérification sur le serveur Linux lui-même. Il détecte les outils d’IA pris en charge et affiche les destinations de connexion observées pour chacun, le volume de trafic envoyé et la date à laquelle chaque destination a été observée pour la première fois. Lorsque la destination est identifiée, il affiche aussi des informations qui aident à comprendre son rôle.

Sur un serveur où nuDefend est installé, vous pouvez commencer par les commandes suivantes :

sudo nudefend workloads
sudo nudefend egress
sudo nudefend egress review Ollama

La dernière commande est un exemple de vérification d’un service Ollama détecté sur le système. Ces commandes affichent les résultats sans modifier la politique réseau.

Si vous décidez de restreindre l’accès à une destination, nuDefend permet de la bloquer pour le service concerné, avec un aperçu des effets du blocage et la possibilité de l’annuler. Ce contrôle s’ajoute au blocage automatique des adresses malveillantes connues.

Le suivi des outils dans les conteneurs repose sur un échantillonnage. Des connexions brèves peuvent donc ne pas être détectées. Les interruptions du suivi sont explicitement signalées, et le volume de trafic seul n’est pas considéré comme une fuite de données. Les rapports d’activité et l’historique du trafic sont conservés sur votre serveur. Les fonctionnalités et leur couverture sont détaillées dans la documentation.

Exécuter un système d’IA sur votre propre serveur vous donne le contrôle de l’infrastructure. Le suivi des connexions sortantes aide à exercer ce contrôle et à décider, sur la base d’observations, vers quelles destinations le système peut transmettre des données.

Découvrez à quoi vos outils d’IA se connectent avec nuDefend