L'angle mort de l'IA sous Linux : 7 points d'exfiltration invisibles pour votre DLP

Une violation de données sur cinq implique désormais l'IA fantôme (Shadow AI). Pour la plupart des organisations, le risque le plus élevé se situe sur les terminaux Linux (où 78,5 % des développeurs travaillent), qui ne disposent pas d'application des politiques DLP. Les ingénieurs peuvent coller librement du code dans des outils de chat IA, synchroniser des modèles propriétaires vers un stockage cloud personnel et transférer des fichiers via des périphériques amovibles.

Cela s'explique par le fait que les solutions DLP traditionnelles ont été conçues pour les passerelles de messagerie et les réseaux Windows. Les postes de travail d'ingénierie, où les données transitent par des outils d'IA, des partages réseau et des périphériques connectés, n'ont jamais fait partie du modèle de menace initial. Aujourd'hui, 69 % des organisations ont la preuve d'une utilisation non autorisée d'outils GenAI, souvent sans visibilité DLP sur les terminaux macOS et Linux.

Selon le rapport IBM 2026 sur le coût d'une violation de données, 97 % des organisations touchées par des violations liées à l'IA ne disposaient d'aucun contrôle d'accès adéquat. Les cadres HIPAA, PCI DSS, RGPD et CMMC tiennent les organisations responsables des données sensibles, y compris celles transférées vers des outils d'IA tiers. Cette application est légalement obligatoire.

Selon NIST SP 800-53 (MP-7), ISO 27001, PCI DSS et la règle de sécurité HIPAA, les organisations sont formellement tenues de gérer, restreindre ou analyser les supports amovibles. Pourtant, malgré ces mandats réglementaires, la plupart des organisations disposent de contrôles minimaux sur les terminaux Linux. Une violation dans le secteur des services financiers a exposé plus de 300 000 dossiers clients via une clé USB personnelle infectée, et un employé d'un sous-traitant de la défense a transféré plus de 3 600 fichiers propriétaires vers des périphériques de stockage personnels.

Netwrix Endpoint Protector fournit un contrôle granulaire des périphériques sur plus de 20 types d'appareils sous Linux. L'application des politiques bloque ou audite les transferts en temps réel, avec des politiques qui autorisent les transferts légitimes tout en bloquant les transferts non autorisés en fonction de la classification des données. L'action est journalisée, bloquée ou corrigée selon la politique. Cette fonctionnalité offre un contrôle cohérent sur Windows, macOS et Linux depuis un tableau de bord unique.

Les contrôles Bluetooth font rarement partie des stratégies DLP sous Linux. L'hypothèse est que le Bluetooth présente un faible risque, qu'il est personnel, ou que c'est « le problème de quelqu'un d'autre. » Pourtant, MITRE ATT&CK désigne l'exfiltration Bluetooth sous la référence T1011.001, une technique qui contourne entièrement les pare-feux, les proxys et les outils DLP.

Le trafic Bluetooth ne touche jamais les interfaces réseau ni les points d'inspection DLP. Des acteurs de menace avancés, dont Flame (2012) et ScarCruft (2019), ont déjà exploité le Bluetooth pour le vol de données. Sans contrôles au niveau du terminal, ce vecteur d'exfiltration reste généralement non surveillé.

Le DLP traditionnel surveille les e-mails et les téléchargements web, mais l'activité de synchronisation cloud lui échappe souvent entièrement. Les machines Linux peuvent avoir des agents de synchronisation cloud installés, et des outils comme Dropbox, Nextcloud, ownCloud, FileZilla et SFTP sont souvent utilisés sans supervision organisationnelle. La synchronisation se produit en arrière-plan, fichier par fichier, sans la visibilité qu'offrent les passerelles de messagerie.

MITRE ATT&CK désigne cela comme T1567.002 (Exfiltration vers le stockage cloud), une technique que les adversaires exploitent parce que les services cloud offrent une couverture lorsque les organisations communiquent déjà avec eux. Les recherches de Cyberhaven confirment que le téléchargement vers un stockage cloud personnel est l'un des moyens les plus courants par lesquels les données sensibles quittent les organisations. Une fois les données dans un compte cloud personnel, l'organisation n'a plus aucun contrôle sur leur mouvement ou leur persistance.

GitHub a signalé 39 millions de secrets divulgués en 2024, avec 28,65 millions de nouveaux secrets codés en dur ajoutés aux dépôts publics rien qu'en 2025, soit une augmentation de 34 % d'une année sur l'autre. Selon une recherche publiée par l'ESEM, jusqu'à 30 % des projets sont à risque en raison des identifiants codés en dur. Les identifiants codés en dur restent l'une des causes les plus courantes des violations de données.

Ces identifiants disparaissent rarement d'eux-mêmes. Même supprimés des dépôts, les secrets restent indéfiniment dans l'historique Git. Une fois exposés, les attaquants utilisent ces identifiants pour provisionner des infrastructures, accéder à des bases de données et compromettre des systèmes. Sans découverte des données sensibles au niveau du terminal ni surveillance de l'inspection du contenu, ces actifs restent invisibles pour les équipes de sécurité jusqu'à ce que les attaquants les exploitent.

SSH et SCP chiffrent leurs canaux, ce qui rend ce chemin d'exfiltration encore plus difficile à détecter au niveau du réseau. Lors d'une violation dans le secteur manufacturier en 2025, des attaquants ont utilisé SCP sur le port 443 pour exfiltrer des plans propriétaires et des données clients. Cette technique a permis à l'attaquant de déplacer des gigaoctets de propriété intellectuelle sans être détecté. Une fois les données transférées d'un partage centralisé vers un poste de travail individuel, que ce soit via NFS, rsync ou SCP, elles deviennent décentralisées et plus difficiles à surveiller. Quelqu'un peut les synchroniser vers un stockage cloud personnel, ou les données peuvent quitter l'organisation lors de son départ.

Les LLM peuvent mémoriser des données d'entraînement, y compris des informations personnellement identifiables et sensibles, que les attaquants peuvent extraire via des requêtes ciblées. Ce risque s'est déjà concrétisé dans du code généré par des outils comme ChatGPT. En 2023, des ingénieurs de Samsung ont involontairement divulgué du code source confidentiel et des notes de réunions internes lors de trois incidents ChatGPT distincts, et les données soumises ont été conservées par OpenAI pour l'entraînement de modèles, hors du contrôle de Samsung.

Ce risque dépasse ce qu'une seule entreprise peut contenir. Un chercheur en sécurité a découvert plus de 143 000 conversations d'utilisateurs avec Claude, Copilot et ChatGPT accessibles publiquement sur Archive.org. Des recherches de Harmonic Security ont révélé que la version gratuite de ChatGPT était à l'origine d'une exposition importante de données sensibles, avec environ un quart des invites sensibles soumises via des comptes ChatGPT gratuits. Une fois les données entrées dans un système d'IA non géré, les organisations perdent le contrôle de leur persistance et de leur accès.

La plupart des organisations disposent d'un DLP sous Windows, car c'est la base, mais cette protection s'arrête généralement aux terminaux Linux où 78,5 % des développeurs travaillent. C'est le même problème architectural évoqué précédemment : le DLP n'a jamais été conçu en pensant aux postes de travail d'ingénierie, de sorte que les téléchargements vers ChatGPT, les transferts USB, les synchronisations cloud et l'activité des partages réseau transitent tous par des terminaux Linux non inspectés.

• Téléchargez l'ebook : Pourquoi les terminaux Linux sont le point zéro du risque des données liées à l'IA
• Regardez le webinaire : Comment les environnements de développement IA sous Linux mettent en échec les stratégies DLP
• Obtenez la fiche technique : Netwrix Endpoint Protector pour Linux