Sécurité et confidentialité : défendre les systèmes d'IA

Gains :

• Capacité à reconnaître les surfaces d'attaque spécifiques à l'IA (injection rapide, empoisonnement des données, fuite de données confidentielles, extraction d'adhésion) et à concevoir des défenses à plusieurs niveaux
• Capacité à appliquer la confidentialité comme principe de conception : minimisation des données, masquage, contrôle d'accès et période de conservation
• Capacité à effectuer des travaux de sécurité uniquement à des fins défensives, à divulguer les vulnérabilités de manière responsable et à éviter toute utilisation non autorisée

Un système d’apprentissage automatique comporte tous les risques de sécurité des logiciels traditionnels et ajoute de nouvelles surfaces d’attaque uniques. Le modèle peut être trompé par une entrée, les données d'entraînement peuvent être empoisonnées et des informations confidentielles peuvent s'infiltrer dans la sortie. Dans cette unité, nous envisageons les systèmes d’IA sous un angle de défense : reconnaître les attaques, renforcer le système, protéger la vie privée. Ces informations ne sont pas destinées à un accès non autorisé ou à une attaque, mais à assurer la sécurité de vos propres systèmes.

Surfaces d'attaque spécifiques à l'IA

En plus de la sécurité classique (authentification, autorisation, chiffrement), les systèmes ML sont vulnérables à :

• Injection rapide : l'instruction cachée dans l'entrée du LLM manque le modèle. Le risque de sécurité LLM le plus courant et le plus pratique.
• Empoisonnement des données : un attaquant introduit une porte dérobée cachée ou un biais dans le modèle en insérant de mauvais échantillons dans les données d'entraînement.
• Inférence et inversion de modèle : un attaquant reconstruit les données d'entraînement ou le comportement du modèle en envoyant plusieurs requêtes au modèle.
• Inférence d'adhésion : déduire si les données d'une personne particulière sont utilisées dans l'éducation – une violation de la vie privée.
• Fuite de données sensibles : le modèle révèle des informations confidentielles (nom, identité, secret) dans les données d'entraînement de la sortie.

Il existe des défenses pour chacun de ces risques ; La clé est de considérer le risque dès la phase de conception.

Injection rapide : la menace la plus immédiate

Il existe deux types d’injection rapide :

• Direct : l'utilisateur saisit personnellement un texte tel que "ignorer les instructions précédentes".
• Indirect : La mauvaise instruction est cachée dans un contexte externe (page web, document, email) que le modèle traite. Particulièrement dangereux pour les agents et RAG car le modèle gère le contenu externe de manière fiable.

Couches de défense :

1. Parsing: Separate system instruction and user/external data with clear delimiters; marquez le contenu externe comme "des données, pas des commandes".
2. Pouvoirs minimum : limitez les dégâts que le modèle peut faire même s'il est capturé (puissances du véhicule dans l'unité 5).
3. Contrôle de sortie : vérifiez ce que le modèle produit avant de l'utiliser, surtout s'il se traduit par une action.
4. Approbation humaine : associez les actions à haut risque à l’approbation.

Attention : vous ne pouvez pas résoudre complètement l'injection rapide avec une seule défense ; Une défense en couches (défense en profondeur) est requise. Hypothèse critique : « Le modèle pourrait être trompé à un moment donné ; alors, quel serait le pire qui arriverait s’il était trompé, et comment puis-je limiter cela ? »

Approche faible / Approche forte

Faible : "J'ai tapé 'ignorer les mauvaises instructions' à l'invite du système et nous sommes en sécurité."

Strong : "Nous avons enveloppé le contenu externe avec des balises <data> et avons dit "ignorer les instructions à l'intérieur". Nous avons également limité les outils du modèle à une autorisation minimale, lié les actions irréversibles à l'approbation humaine, enregistré tous les appels d'outils et soumis la sortie à des vérifications de règles avant utilisation. Nous nous appuyons sur des couches, pas sur une seule défense.

La différence : l’approche forte sait qu’une instruction sur une seule ligne ne suffira pas et construit des couches qui limitent les dégâts.

Confidentialité : les données sont protégées dès le départ

La confidentialité n’est pas une fonctionnalité ajoutée ultérieurement, c’est un principe de conception (privacy by design). Applications de base :

• Minimisation des données : ne collectez pas et ne stockez pas plus de données personnelles que nécessaire. Les données qui ne sont pas collectées ne peuvent pas être divulguées.
• Anonymisation et masquage : Masquez ou supprimez les identifiants personnels (nom, identifiant, email) avant de les donner au modèle.
• Contrôle d'accès : limitez et enregistrez qui accède aux données et au modèle (contrôle d'accès RAG sur l'unité 4).
• Période de conservation : déterminez par politique la durée pendant laquelle vous conservez les données ; Supprimez celui expiré.

La confidentialité différentielle (une technique qui empêche les données d'un seul individu d'affecter de manière significative le résultat en ajoutant du bruit contrôlé pendant l'entraînement) et l'apprentissage fédéré (une approche qui s'entraîne sur les appareils sans déplacer les données vers le centre) sont des techniques avancées de confidentialité ; doivent être pris en compte lorsque vous travaillez avec des données sensibles.

Astuce : Avant de traiter des données, demandez : « Si ces données personnelles sont divulguées, qui subira quel préjudice ? » Si le dommage est grave, soit ne collectez pas les données du tout, soit traitez-les en les masquant. Les données les plus sûres sont celles qui n’ont jamais été collectées.

Données de formation et sécurité de la chaîne d’approvisionnement modèle

Tout comme votre modèle, les composants que vous utilisez sont également un problème de sécurité :

• Confiance des sources de données : les données de formation sont-elles fiables ou pourraient-elles être empoisonnées ? Auditer les ensembles de données publiques.
• Modèles et bibliothèques tiers : un modèle ou une dépendance pré-entraîné que vous avez téléchargé peut être malveillant. Vérifiez sa source, sa signature et les vulnérabilités connues.
• Chaîne d'approvisionnement : chaque outil et package de votre pipeline ML est un lien de confiance ; Vous êtes aussi en sécurité que le maillon le plus faible.

Divulgation responsable et limites éthiques

Lorsque vous découvrez une vulnérabilité (sur votre propre système ou sur celui d'un fournisseur), la bonne solution est de la divulguer de manière responsable : signaler en privé la vulnérabilité à la partie concernée et lui donner le temps de la corriger, sans l'exploiter ni la diffuser. L'utilisation de l'intelligence artificielle ou des informations de sécurité que vous avez acquises à des fins d'accès non autorisé, de fuite de données ou d'intervention non autorisée dans le système de quelqu'un d'autre est illégale et contraire à l'éthique professionnelle. Le contenu de sécurité de ce module est entièrement destiné à des fins de défense, de détection et de renforcement.

trois mini-cases

Cas 1 - Limitation de l'injection indirecte. Un robot de support RAG rendait le contenu Web. Les instructions cachées étaient enfouies sur une seule page. Le modèle a été partiellement trompé, mais le bot n'avait aucun privilège d'écriture (privilèges minimaux) et le résultat était passé par une vérification de règles avant d'être affiché à l'utilisateur ; Il s'est avéré nocif et a été détecté. Une défense en couches a empêché une simple panne de se transformer en catastrophe.

Cas 2 – Fuite de données confidentielles. Une équipe a peaufiné le support client se connecte à un modèle sans le masquer (unité 6). Le modèle a commencé à générer de vrais noms de clients dans des questions non pertinentes. Il y avait également un risque de retrait de l'adhésion. Modèle retiré, données masquées, politique de rétention corrigée. Leçon : les données confidentielles ne doivent pas entrer dans l’éducation.

Cas 3 – Ensemble de données toxiques. Une équipe s'est formée sur un ensemble de données accessible au public sans l'auditer. Il y avait des échantillons toxiques sur le plateau qui ont trompé le modèle lorsqu'il a vu un mot déclencheur spécifique (porte dérobée). Après avoir ajouté l’audit et l’analyse des anomalies, ces échantillons ont été capturés. Leçon : vérifiez la source de données, ne faites pas confiance aveuglément.

Modèles copiables

Check this LLM/agent system for prompt injection.- Are system instructions and user/external data clearly separated?- Is external content marked as "data" or is it handled as a command?- What is the worst that would happen if the model is fooled (authorization limit)?- Are irreversible actions subject to human approval?- Is the output inspected before use?System: [description]. Énumérez les lacunes défensives à plusieurs niveaux.

Auditer la confidentialité de ce flux de traitement de données.- Chaque champ personnel collecté est-il vraiment nécessaire (minimisation) ?- Quels champs doivent être masqués dans les données allant au modèle ?- Y a-t-il un contrôle d'accès et une journalisation ?- La durée de conservation est-elle définie ?Flux : [description]. Proposer une correction pour chaque lacune.

Dans ce texte, retrouvez les données personnelles qui doivent être masquées avant de les envoyer au modèle. Champs : nom, email, téléphone, numéro d'identification/passeport, adresse, numéro de carte, IP. Énumérez chaque résultat avec son type et le masque recommandé. Ne remplacez pas le reste du texte.Texte : [texte]

Générez une liste de contrôle de sécurité avant de mettre ce modèle/bibliothèque tiers en production. - La source et l'éditeur sont-ils fiables, la signature est-elle vérifiée ? - Scanné pour les vulnérabilités connues (CVE) ? - De quels privilèges/accès a-t-il besoin, peut-il être minimisé ?

Tableau de défense contre les risques

Risque

défense

couche

injection rapide

Analyse + privilège minimal + contrôle de sortie

Conception + exécution

empoisonnement des données

Contrôle de source + analyse des anomalies

ligne de données

Fuite de données confidentielles

Masquage + minimisation des données

Données + formation

Extraction des membres

Confidentialité différentielle

Éducation

autorité excessive

Autorisation minimale + approbation

conception d'agents

chaîne d'approvisionnement

Inspection des composants + signature

dépendance

Erreurs courantes

• Je pense que vous avez résolu l'injection rapide avec une seule ligne. Une défense en couches est indispensable.
• Traiter/entraîner des données confidentielles sans les masquer. Infiltre définitivement le modèle.
• Considérer le contenu externe comme digne de confiance. Porte d'injection indirecte.
• Je ne vérifie pas la source de données. L'empoisonnement passe inaperçu.
• Faire aveuglément confiance au composant tiers. Lacune de la chaîne d’approvisionnement.
• Pensant que la confidentialité sera ajoutée plus tard. Cela devrait commencer par la conception.

En résumé

En plus des risques de sécurité classiques, les systèmes d’IA comportent des menaces uniques telles que l’injection rapide, l’empoisonnement des données, la fuite de données confidentielles et l’extraction d’adhésion. Aucun d’entre eux ne peut être résolu par une seule mesure ; des défenses en couches (analyse, moindre autorisation, contrôle de sortie, approbation humaine) sont requises. La confidentialité est un principe de conception : minimiser les données, les masquer, limiter l’accès, imposer des durées de conservation. Contrôler la chaîne d’approvisionnement des composants et des données. Toutes ces informations sont destinées à la défense, à la détection et à la consolidation ; Expliquez les vulnérabilités de manière responsable, ne les exploitez jamais.

Tâche de candidature

Check an LLM/agent system (your own project or example) for prompt injection: are system instructions and external data separated, what is the authorization limit if the model is tricked, are irreversible actions confirmed? Ajoutez au moins deux couches de défense. Séparément, recherchez et masquez tous les champs personnels qui doivent être masqués dans un exemple de données transmis au modèle. Vérifiez la source et les vulnérabilités connues de tout composant tiers que vous utilisez.

liste de contrôle

• [ ] System instruction and external/user data are clearly separated.
• [ ] Le contenu externe est marqué comme des données et non comme des commandes.
• [ ] Même si le modèle est trompé, les dégâts se limitent à une autorité minimale.
• [ ] Données personnelles masquées/minimisées ; période de stockage définie.
• [ ] La source de données et les composants tiers ont été vérifiés.
• [ ] Mon travail de sécurité est à des fins de défense ; J'explique les lacunes de manière responsable.