Cloudflare annonce le développement de Firewall for AI, une couche de protection qui peut être déployée devant les LLM afin d'identifier les abus avant qu'ils n'atteignent les modèles d'IA

Cloudflare annonce le développement de Firewall for AI, une couche de protection qui peut être déployée devant les LLM afin d'identifier les abus avant qu'ils n'atteignent les modèles d'IA

Cloudflare annonce ce 4 mars le développement de Firewall for AI (Pare-feu pour l'IA), une couche de protection qui peut être déployée devant les grands modèles de langage (LLM) afin d'identifier les abus avant qu'ils n'atteignent les modèles.

Alors que les modèles d'IA, et en particulier les LLM, sont en plein essor, les clients de Cloudflare ont fait part de leur inquiétude quant aux meilleures stratégies pour sécuriser leurs propres LLM. L'utilisation de LLM dans le cadre d'applications connectées à l'internet introduit de nouvelles vulnérabilités qui peuvent être exploitées par des acteurs malveillants.

Certaines des vulnérabilités affectant les applications web et API traditionnelles s'appliquent également au monde des LLM, y compris les injections ou l'exfiltration de données. Cependant, il existe un nouvel ensemble de menaces qui sont maintenant pertinentes en raison de la façon dont les LLM fonctionnent. Par exemple, des chercheurs ont récemment découvert une vulnérabilité dans une plateforme de collaboration en IA qui leur permet de détourner des modèles et d'effectuer des actions non autorisées.

Firewall for AI est un Web Application Firewall (WAF) avancé spécialement conçu pour les applications utilisant des LLM. Il comprendra un ensemble d'outils qui peuvent être déployés devant les applications pour détecter les vulnérabilités et fournir une visibilité aux propriétaires de modèles. Le kit d'outils comprendra des produits qui font déjà partie du WAF, tels que la limitation du débit et la détection des données sensibles, ainsi qu'une nouvelle couche de protection qui est actuellement en cours de développement. Cette nouvelle validation analyse l'invite soumise par l'utilisateur final afin d'identifier les tentatives d'exploitation du modèle pour extraire des données et d'autres tentatives d'abus. Tirant parti de la taille du réseau Cloudflare, Firewall for AI fonctionne au plus près de l'utilisateur, permettant ainsi d'identifier rapidement les attaques et de protéger à la fois l'utilisateur final et les modèles contre les abus et les attaques.


Avant de se pencher sur le fonctionnement de Firewall for AI et sur l'ensemble de ses fonctionnalités, examinons d'abord ce qui rend les LLM uniques et les surfaces d'attaque qu'ils introduisent. Le Top 10 de l'OWASP pour les LLM sera utilisé comme référence.

Pourquoi les LLM sont-ils différents des applications traditionnelles ?

Lorsque l'on considère les LLM comme des applications connectées à Internet, il existe deux différences principales par rapport aux applications web plus traditionnelles.

Premièrement, la manière dont les utilisateurs interagissent avec le produit. Les applications traditionnelles sont déterministes par nature. Pensez à une application bancaire - elle est définie par un ensemble d'opérations (vérifier mon solde, effectuer un virement, etc.). La sécurité des opérations commerciales (et des données) peut être obtenue en contrôlant l'ensemble des opérations acceptées par ces points de terminaison : "GET /balance" ou "POST /transfer".

Les opérations avec les LLM sont non déterministes par conception. Pour commencer, les interactions avec les LLM sont basées sur le langage naturel, ce qui rend l'identification des requêtes problématiques plus difficile que la correspondance des signatures d'attaques. En outre, à moins qu'une réponse ne soit mise en cache, les LLM fournissent généralement une réponse différente à chaque fois, même si la même demande d'entrée est répétée. Il est donc beaucoup plus difficile de limiter la façon dont l'utilisateur interagit avec l'application. Cela représente également une menace pour l'utilisateur, qui risque d'être exposé à des informations erronées qui affaiblissent sa confiance dans le modèle.

Deuxièmement, la façon dont le plan de contrôle de l'application interagit avec les données constitue une grande différence. Dans les applications traditionnelles, le plan de contrôle (code) est bien séparé du plan de données (base de données). Les opérations définies sont le seul moyen d'interagir avec les données sous-jacentes (par exemple, montrez-moi l'historique de mes transactions de paiement). Cela permet aux praticiens de la sécurité de se concentrer sur l'ajout de contrôles et de garde-fous au plan de contrôle et de protéger ainsi indirectement la base de données.

Les LLM sont différents en ce sens que les données d'apprentissage deviennent partie intégrante du modèle lui-même par le biais du processus d'apprentissage, ce qui rend extrêmement difficile le contrôle de la manière dont ces données sont partagées à la suite d'une demande de l'utilisateur. Certaines solutions architecturales sont à l'étude, comme la séparation des LLM en différents niveaux et la séparation des données. Cependant, aucune solution miracle n'a encore été trouvée.

Du point de vue de la sécurité, ces différences permettent aux attaquants de concevoir de nouveaux vecteurs d'attaque qui peuvent cibler les LLM et passer sous le radar des outils de sécurité existants conçus pour les applications web traditionnelles.

Vulnérabilités LLM de l'OWASP

La fondation OWASP a publié une liste des 10 principales classes de vulnérabilités pour les LLM, fournissant un cadre utile pour réfléchir à la manière de sécuriser les modèles de langage. Certaines menaces rappellent le top 10 de l'OWASP pour les applications web, tandis que d'autres sont spécifiques aux modèles de langage.

Comme pour les applications web, certaines de ces vulnérabilités peuvent être traitées au mieux lors de la conception, du développement et de la formation de l'application LLM. Par exemple, l'empoisonnement des données d'apprentissage peut être réalisé en introduisant des vulnérabilités dans l'ensemble des données d'apprentissage utilisées pour former de nouveaux modèles. Les informations empoisonnées sont ensuite présentées à l'utilisateur lorsque le modèle est opérationnel. Les vulnérabilités de la chaîne d'approvisionnement et la conception de plugins non sécurisés sont des vulnérabilités introduites dans les composants ajoutés au modèle, comme les progiciels tiers. Enfin, la gestion des autorisations et des permissions est cruciale lorsqu'il s'agit de traiter les cas d'Excessive Agency, où des modèles non contraints peuvent effectuer des actions non autorisées au sein d'une application ou d'une infrastructure plus large.

Inversement, l'injection d'invites, le déni de service du modèle et la divulgation d'informations sensibles peuvent être atténués par l'adoption d'une solution de sécurité proxy telle que Cloudflare Firewall for AI. Dans les sections suivantes, plus de détails seront donnés sur ces vulnérabilités et sur la façon dont Cloudflare est positionné de manière optimale pour les atténuer.

Déploiements de LLM

Les risques liés aux modèles linguistiques dépendent également du modèle de déploiement. Actuellement, trois approches principales de déploiement sont observées : les LLM internes, publics et de produits. Dans ces trois scénarios, vous devez protéger les modèles contre les abus, protéger les données propriétaires stockées dans le modèle et protéger l'utilisateur final contre les informations erronées ou l'exposition à un contenu inapproprié.

LLM internes : Les entreprises développent des LLM pour aider leurs employés dans leurs tâches quotidiennes. Ils sont considérés comme des actifs de l'entreprise et ne doivent pas être accessibles aux non-employés. Il peut s'agir, par exemple, d'un copilote IA formé aux données de vente et aux interactions avec les clients, utilisé pour générer des propositions personnalisées, ou d'un LLM formé à une base de connaissances interne qui peut être interrogée par les ingénieurs.

LLM publics : Il s'agit de LLM accessibles en dehors des frontières d'une entreprise. Ces solutions ont souvent des versions gratuites que tout le monde peut utiliser et elles sont souvent formées sur des connaissances générales ou publiques. Parmi les exemples, citons GPT d'OpenAI ou Claude d'Anthropic.

LLM de produit : du point de vue de l'entreprise, les LLM peuvent faire partie d'un produit ou d'un service offert à ses clients. Il s'agit généralement de solutions personnalisées auto-hébergées qui peuvent être mises à disposition en tant qu'outil d'interaction avec les ressources de l'entreprise. Parmi les exemples, citons les chatbots de support client ou l'assistant AI de Cloudflare.

Du point de vue du risque, la différence entre les LLM de produit et les LLM publics consiste à déterminer qui subit l'impact des attaques réussies. Les LLM publics sont considérés comme une menace pour les données car les données qui aboutissent dans le modèle peuvent être consultées par pratiquement n'importe qui. C'est l'une des raisons pour lesquelles de nombreuses entreprises conseillent à leurs employés de ne pas utiliser d'informations confidentielles dans les invites de services accessibles au public. Les LLM de produit peuvent être considérés comme une menace pour les entreprises et leur propriété intellectuelle si les modèles ont eu accès à des informations exclusives pendant la formation (par conception ou par accident).

Firewall for AI

Cloudflare Firewall for AI sera déployé comme un WAF traditionnel, où chaque requête API avec une invite LLM est analysée pour rechercher des motifs et des signatures d'attaques possibles.

Firewall for AI peut être déployé devant des modèles hébergés sur la plateforme Cloudflare Workers AI ou des modèles hébergés sur toute autre infrastructure tierce. Il peut également être utilisé avec Cloudflare AI Gateway, et les clients pourront contrôler et configurer Firewall for AI en utilisant le plan de contrôle WAF.


Prévenir les attaques volumétriques

L'une des menaces répertoriées par l'OWASP est le déni de service des modèles. Comme pour les applications traditionnelles, une attaque par déni de service est menée en consommant une quantité exceptionnellement élevée de ressources, ce qui entraîne une réduction de la qualité du service ou une augmentation potentielle des coûts d'exploitation du modèle. Étant donné la quantité de ressources dont les LLM ont besoin pour fonctionner et l'imprévisibilité des entrées des utilisateurs, ce type d'attaque peut être préjudiciable.

Ce risque peut être atténué en adoptant des politiques de limitation de taux qui contrôlent le taux de requêtes provenant de sessions individuelles, limitant ainsi la fenêtre contextuelle. En faisant passer votre modèle par Cloudflare dès aujourd'hui, vous bénéficiez d'une protection contre les attaques DDoS. Vous pouvez également utiliser la limitation de taux et la limitation de taux avancée pour gérer le taux de requêtes autorisées à atteindre votre modèle en définissant un taux maximum de requêtes effectuées par une adresse IP ou une clé API individuelle au cours d'une session.

Identifier les informations sensibles avec la détection des données sensibles

Il existe deux cas d'utilisation des données sensibles, selon que vous êtes propriétaire du modèle et des données ou que vous souhaitez empêcher les utilisateurs d'envoyer des données dans des LLM publics.

Selon la définition de l'OWASP, la divulgation d'informations sensibles se produit lorsque les LLM révèlent par inadvertance des données confidentielles dans les réponses, ce qui entraîne un accès non autorisé aux données, des violations de la vie privée et des failles de sécurité. Une façon d'éviter cela est d'ajouter des validations strictes de l'invite. Une autre approche consiste à identifier le moment où les informations personnelles identifiables (PII) quittent le modèle. C'est le cas, par exemple, lorsqu'un modèle a été formé à l'aide d'une base de connaissances de l'entreprise qui peut contenir des informations sensibles, telles que des PII (comme le numéro de sécurité sociale), des codes propriétaires ou des algorithmes.

Les clients qui utilisent des modèles LLM derrière Cloudflare WAF peuvent utiliser l'ensemble de règles gérées SDD (Sensitive Data Detection) WAF pour identifier certaines PII renvoyées par le modèle dans la réponse. Les clients peuvent consulter les correspondances SDD sur les événements de sécurité du WAF. Aujourd'hui, SDD est proposé sous la forme d'un ensemble de règles gérées conçues pour rechercher des informations financières (telles que les numéros de carte de crédit) ainsi que des secrets (clés API). Dans le cadre de la feuille de route, Cloudflare prévoit de permettre à ses clients de créer leurs propres empreintes digitales personnalisées.

L'autre cas d'utilisation vise à empêcher les utilisateurs de partager des PII ou d'autres informations sensibles avec des fournisseurs LLM externes, tels que OpenAI ou Anthropic. Pour se protéger contre ce scénario, Cloudflare prévoit d'étendre le SDD afin d'analyser l'invite et d'intégrer sa sortie à AI Gateway où, en plus de l'historique de l'invite, certaines données sensibles seront détectées si elles ont été incluses dans la requête. Cloudflare commencera par utiliser les règles SDD existantes, et prévoit d'autoriser les clients à rédiger leurs propres signatures personnalisées. Dans le même ordre d'idées, l'obscurcissement est une autre fonction dont les clients évoquent souvent l'importance. Une fois disponible, le SDD étendu permettra aux clients d'obscurcir certaines données sensibles dans une invite avant qu'elles n'atteignent le modèle. Le SDD sur la phase de requête est en cours de développement.

[SIZE=3]Pr...