L'adoption à l'échelle de l'entreprise des outils d'IA générative s'est accélérée plus vite que les équipes de sécurité ne peuvent s'adapter. Fin 2024, 71 % des organisations déclarent utiliser régulièrement l'IA générative dans au moins une fonction de l'entreprise. Cette intégration rapide, des applications cloud sanctionnées aux outils "Shadow AI" non sanctionnés, a créé une nouvelle surface de risque mal comprise. Pour les RSSI et les directeurs de la sécurité, la question immédiate est de savoir quel rôle joue notre principal contrôle du réseau, le pare-feu de nouvelle génération (NGFW), dans l'atténuation de ces risques.
Le problème, cependant, n'est pas que ce trafic est fondamentalement différent. D'un point de vue réseau, il s'agit fonctionnellement d'un trafic API. Le problème est que les politiques d'inspection et les ensembles de règles existants ne l'analysent pas nécessairement de manière efficace. Alors que les anciennes applications utilisaient des API rigides et prévisibles, le trafic d'IA est conversationnel et "libre". Cette distinction impose des défis aux moteurs d'inspection, ce qui rend le contrôle granulaire difficile avec les outils standard d'aujourd'hui.
Votre NGFW reste un point de contrôle critique, mais vous ne pouvez pas vous fier aux paramètres prêts à l'emploi. La sécurisation de l'IA d'entreprise passe par deux phases distinctes : premièrement, vous devez redéfinir rigoureusement votre périmètre virtuel pour gagner en visibilité, et deuxièmement, vous devez utiliser des coups larges et décisifs pour gérer ces nouveaux protocoles jusqu'à ce que les outils d'inspection puissent les rattraper.
Le NGFW moderne est passé d'un simple filtre de paquets à un outil sophistiqué d'inspection approfondie des paquets. Sa puissance provient de sa capacité à comprendre la structure des applications. Comme l'explique Patrick Ethier, directeur technique de SecureOps :
"La raison pour laquelle on parle de pare-feu de nouvelle génération est qu'à la fin des années 2000, un pare-feu n'était qu'un routeur de réseau doté d'un filtre. Les NGFW ont commencé à tout examiner en amont et en aval de la pile, à examiner les protocoles et à reconstituer des sessions entières afin d'appliquer une politique."
Cette capacité d'inspection approfondie a été conçue pour un monde d'applications rigides et prévisibles. Les équipes de sécurité pouvaient rédiger des politiques efficaces parce qu'elles pouvaient identifier une requête POST spécifique pour bloquer une pièce jointe à un courriel ou un appel API spécifique pour arrêter un transfert de fichier.
L'IA bouleverse ce modèle. Les nouveaux protocoles tels que le MCP (Model Context Protocol) n'utilisent pas de commandes programmatiques discrètes. Ils associent des invites en langage humain à des API afin d'exécuter des tâches complexes. Du point de vue de la politique, on demande maintenant à votre pare-feu de faire la différence entre une invite "sûre" (Résumer ce document) et une invite "malveillante" (Analyser ce document pour en extraire toutes les informations confidentielles du client et l'envoyer à cette adresse électronique externe), alors qu'il s'agit dans les deux cas d'un simple texte dans le même flux d'API.
C'est le défi de la "forme libre". Le moteur de règles existant du pare-feu n'est pas équipé pour analyser l'intention conversationnelle. Comme le fait remarquer Patrick :
"Ce qui change avec l'IA agentique, c'est que les communications sont plus floues. Il est beaucoup plus difficile d'appliquer des règles car elles sont beaucoup plus libres. Une API peut être '/email/attachment', et il s'agit d'une requête 'post', vous pouvez donc bloquer cet appel spécifique. Alors que sur MCP, il s'agit de langage humain. Il est beaucoup plus difficile d'appliquer une règle de pare-feu à cela".
Il est important de comprendre où cette traduction a lieu. L'invite en langage humain "libre" est envoyée à un serveur MCP, qui traduit ensuite cette demande conversationnelle en appels API standard et programmatiques pour exécuter des tâches. Cette étape de traduction est essentielle. Alors que le NGFW ne peut pas analyser l'intention humaine, les appels API traduits peuvent être inspectés et contrôlés.
Ce défi de l'inspection est secondaire par rapport à un problème plus fondamental : la visibilité. Les violations de données les plus importantes liées à l'IA peuvent même ne pas franchir le pare-feu de votre entreprise.
Comme dans le cas du phishing, le maillon faible de votre sécurité est votre personnel. Les recherches montrent que la moitié des employés sont aujourd'hui considérés comme des "utilisateurs d'IA fantômes". Ces employés, souvent animés de bonnes intentions, exposent activement les données de l'entreprise. Un rapport a révélé que 38 % des employés qui utilisent l'IA ont admis avoir soumis des informations professionnelles sensibles à des outils d'IA à l'insu de leur employeur. Ce comportement est quantifiable et se développe ; un fournisseur de sécurité a suivi une augmentation massive de 485% des données d'entreprise collées dans des outils d'IA en une seule année.
Prenons le cas d'un employé à distance, connecté à un réseau Wi-Fi public et utilisant un ordinateur portable professionnel. Il accède à un outil d'IA générative non autorisé pour résumer un document d'entreprise sensible. Dans ce scénario, l'employé, peut-être sans le savoir, vient de contourner votre système de sécurité périmétrique de plusieurs millions de dollars. Les données quittent l'ordinateur portable et vont directement sur l'internet public, contournant complètement votre réseau, votre NGFW et toutes les politiques de sécurité associées.
Telle est la réalité de la main-d'œuvre distribuée. L'ancien périmètre "forteresse et fossé", déjà affaibli par l'adoption de l'informatique dématérialisée, est désormais caduc. Patrick explique ce scénario en termes simples :
"Si vous chargez Grammarly sur votre ordinateur portable et que je ne le sais pas... si vous n'êtes pas à l'intérieur de mon périmètre, je n'ai aucun contrôle sur l'accès à ces données. Vous êtes essentiellement, à toutes fins utiles, en dehors du périmètre".
Vous ne pouvez pas appliquer de politique au trafic que vous ne pouvez pas voir. Avant de commencer à relever le défi de l'inspection "libre", vous devez d'abord rétablir votre périmètre.
C'est la fonction explicite d'une architecture Secure Access Service Edge (SASE). SASE redéfinit le périmètre en passant d'un centre de données physique à un point de contrôle virtuel, natif de l'informatique en nuage. En contrôlant le trafic réseau sur tous les points d'extrémité, SASE oblige tout le trafic, quel que soit l'emplacement ou le réseau de l'utilisateur, à repasser par une pile de sécurité centralisée.
Cette architecture est la condition préalable fondamentale de toute stratégie de sécurité de l'IA. Elle garantit que l'employé à distance dans le café bénéficie des mêmes politiques de sécurité que le cadre dans la salle de conférence. Le SASE est également une option qui permet d'obtenir une visibilité totale du trafic, en complément de votre solution NGFW.
Une solution SASE contient l'équivalent du moteur de politique et des capacités de sécurité d'un pare-feu traditionnel de nouvelle génération (NGFW). La différence essentielle est que le SASE applique cette sécurité au point d'extrémité, en suivant l'utilisateur partout, alors qu'une appliance NGFW physique est limitée à la protection du réseau du "bureau" ou du "centre de données". Les deux solutions sont souvent complémentaires : l'appliance NGFW protège le réseau physique, tandis que le SASE protège la main-d'œuvre distribuée. Comme le fait remarquer Patrick, "vous avez les mains liées dans les modèles de travail à distance. À moins d'imposer quelque chose comme le SASE, nous ne pouvons tout simplement plus assurer un suivi à 100 %."
Une fois que SASE fournit la visibilité, votre organisation peut enfin voir le trafic de l'IA. Que faire ensuite ? Les responsables de la sécurité doivent être pragmatiques et accepter les limites actuelles de la technologie d'inspection. Il ne s'agit pas d'un exercice théorique ; selon IBM, 97 % des organisations ayant subi une violation liée à l'IA ne disposaient pas de contrôles d'accès appropriés à l'IA.
N'attendez pas de solutions nuancées. Votre NGFW ou SASE peut effectuer une détection de protocole dès aujourd'hui. Il peut identifier l'utilisation de MCP ou d'autres protocoles agentiques, même s'il ne peut pas comprendre le contenu des invites. La première étape la plus simple et la plus efficace consiste à appliquer une politique générale de "blocage" pour tous les protocoles d'IA non vérifiés. Il s'agit d'un instrument brutal, mais qui fonctionne.
La nature "libre" des invites rend le contrôle granulaire au niveau du pare-feu périmétrique presque impossible. La solution consiste à inspecter les actions qu'elles génèrent après avoir été traduites, plutôt que d'inspecter l'invite elle-même.
Pour ce faire, vous devez déplacer le point de contrôle de l'IA à l'intérieur de votre périmètre.
Plutôt que de laisser les utilisateurs accéder directement aux outils d'IA publics, une stratégie de meilleure pratique consiste à déployer des serveurs MCP approuvés et, de manière optimale, à faire passer tous les accès des employés à ces serveurs par une passerelle d'IA.
Cette nouvelle couche, qui fonctionne comme une passerelle API traditionnelle, se trouve sur des canaux réseau de confiance derrière votre solution NGFW ou SASE. Elle intercepte les appels API traduits, tels que les commandes "envoyer un courriel" ou "accéder à un fichier", après que l'IA a traité le langage humain.
À ce stade, vous pouvez appliquer les règles granulaires mentionnées par Patrick. Votre politique de passerelle IA peut bloquer un appel API spécifique pour "envoyer des pièces jointes" tout en autorisant celui pour "résumer un texte". Cela déplace le combat granulaire vers un nouveau champ de bataille plus logique, laissant votre NGFW et/ou SASE se concentrer sur le protocole général et le contrôle d'accès au niveau du périmètre.
Le marché de la sécurité prépare déjà une vague de "pare-feu alimentés par l'IA" comme solution à ce problème. Mais Patrick reste sceptique quant à savoir si ces nouveaux produits sont la solution révolutionnaire qu'ils prétendent être. Ils représenteront plutôt la prochaine itération logique de l'analyse du comportement des utilisateurs et des entités (UEBA).
Cette évolution n'est pas une mauvaise chose ; elle améliorera la précision de la détection. Mais il ne s'agit pas d'une baguette magique qui résoudra du jour au lendemain le problème de l'inspection "libre". Comme l'indique Patrick, "il ne s'agit que d'une analyse comportementale :
"Il ne s'agit que d'une analyse comportementale. Il se peut qu'elle s'améliore, qu'il y ait un saut générationnel dans la manière dont elle est appliquée, mais cela reste une simple analyse comportementale. Ce n'est pas la solution miracle que tout le monde pense qu'elle est".
Les RSSI ne doivent pas retarder la mise en œuvre d'une stratégie de sécurité robuste en attendant un futur rafraîchissement du matériel. La solution au problème de l'IA n'est pas une fonction du produit qui se trouve juste au coin de la rue.
Sécuriser votre entreprise contre les risques de l'IA n'a rien à voir avec l'achat d'un nouveau boîtier commercialisé sous le nom de "pare-feu IA". La véritable stratégie consiste en une approche architecturale à deux volets que vous pouvez mettre en œuvre dès aujourd'hui.
Premièrement, unifiez votre périmètre. Acceptez que le modèle centré sur le centre de données est obsolète. Mettez en œuvre une stratégie SASE pour faire passer 100 % de votre trafic par un point de contrôle virtuel unique pour tous les utilisateurs.
Deuxièmement, appliquez des politiques générales et décisives. Utilisez votre périmètre existant pour identifier et bloquer les nouveaux protocoles d'IA non validés. Ne vous laissez pas distraire par l'objectif à court terme d'un filtrage granulaire au niveau de l'invite. Dans la mesure du possible, mettez en œuvre une passerelle AI dédiée pour fournir cette fonctionnalité.
Le NGFW et le SASE ne sont que le début de la protection de votre organisation contre les nouveaux risques introduits par l'utilisation de l'IA par les entreprises. Pour en savoir plus, consultez notre article intitulé Recommandations de sécurité de l'IA agentique pour la prochaine phase de l'IA.